Captura actor, action, target y result
Registra actor, authentication context, operation, target resource, timestamp y outcome. Para cambios, conserva before/after o referencias inmutables suficientes para reconstruir qué cambió.
Incluye privileged y policy-changing actions
Administrative access, role changes, credentials y configuraciones financieras necesitan cobertura explícita. PCI DSS Requirement 10 destaca logging y monitoring de acceso y actividad relevante.
Protege la evidencia
Si quien ejecuta una acción puede reescribir el record, la evidencia pierde valor. Usa almacenamiento append-oriented, retention control, integrity protection y acceso administrativo restringido.
Hazlo queryable para investigaciones
Diseña identifiers y correlation fields para moverse desde customer, payment, API key, user o config change hasta toda la cadena relevante.
Decide qué eventos necesitan calidad de evidencia
Application logs optimizan debugging; audit logs optimizan accountability. No todo debug event necesita retención larga ni todo audit event stack traces. Identifica acciones que cambian access, configuration, financial state, security posture o evidence. Esos eventos necesitan schemas estables y retención acorde a riesgo y regulación.
Ejemplos: cambios de role/permission, lifecycle de API keys, approvals de payout/refund, cambios de routing policy, acceso a sensitive data, overrides, login/security events y acciones administrativas. La lista depende del producto, pero debe ser deliberada.
Registra suficiente context para reconstruir authorization
Saber que user 123 cambió un setting no basta si no se sabe qué tenant, account, policy y resource estaban implicados. Captura actor identity, authentication method cuando aplique, tenant context, action, target, key attributes, result y correlation IDs. En sistemas policy-driven, policy/config version puede ser crítica para explicar por qué se permitió.
Evita sensitive data innecesaria en audit records. La evidencia debe identificar la acción sin convertirse en una copia descontrolada de credenciales o personal data. Usa referencias, hashes o valores redacted cuando basten.
Protege integrity y separación administrativa
Un audit trail es débil si administradores ordinarios pueden editarlo o borrarlo sin dejar evidencia. Usa write paths y storage controls que hagan difícil la modificación silenciosa, limita quién gestiona retention y registra acciones administrativas sobre el propio audit system.
Retention debe ser explícita. Retener indefinidamente aumenta privacy y storage risk; retener poco debilita investigaciones. Alinea con requisitos regulatorios, contractuales y operativos y documenta excepciones.
Diseña investigation queries antes del incidente
Imagina preguntas como: ¿quién cambió esta routing rule, qué transactions afectó y estaba autorizado? ¿qué administradores accedieron a este tenant durante el incidente? Si responder requiere joins manuales sobre logs no estructurados, el audit model no es maduro operacionalmente.
Define correlation IDs e indexed fields según investigaciones probables. Así audit trail se convierte en control útil y no en archivo que existe técnicamente pero no responde a tiempo.
Monitoriza el propio audit system
Auditability no es almacenamiento pasivo. Alerta sobre logging failures, ingestion gaps, caídas anómalas de volumen, cambios de retention y privileged access al audit store. Un sistema que deja de producir evidence durante el incidente crea control failure que uptime normal puede no detectar.
Prueba periódicamente que eventos representativos pueden recuperarse y reconstruirse. Verifica calidad de evidencia antes de necesitarla en un audit o security event real.
Registra actor, acción, recurso, contexto y resultado.
Trata cambios de privilege y policy como first-class events.
Protege la evidencia.
Diseña para investigaciones reales.