Define un registro de auditoría de solo anexado con una cadena hash o almacenamiento WORM, campos obligatorios actor-objeto-razón, un almacenamiento separado de la base de datos de la aplicación y una retención que perdura más allá del borrado ordinario excepto cuando se documenta una excepción legal.
Estado del paquete: contexto de referencia listo para revisión humana. El contrato y los escenarios de prueba están completos, pero no se afirma que una implementación adoptante los haya superado.
Decisión
Las acciones relevantes para la seguridad escriben un registro de auditoría de solo anexado en un almacenamiento que no es la base de datos OLTP de la aplicación. Cada registro nombra al actor, el objeto y una razón legible por máquina. La integridad se proporciona mediante una cadena hash por registro, un bloqueo WORM o ambos. La retención sigue una clase nombrada. Los trabajos ordinarios de derecho al borrado no eliminan registros que aún están dentro de esa clase a menos que se aplique una excepción legal documentada.
Alcance
- Cambios de autorización, sesiones de emergencia (break-glass), exportaciones de datos y otras acciones del plano de control listadas en
event-catalog.yaml. - APIs de escritura, trabajos de verificación de cadena, banderas de retención legal y el límite con los flujos de trabajo de borrado.
- Fuente de reloj y algoritmo de resumen usados para la verificación de la cadena.
Fuera de este bloque
- Analítica de producto, registros de depuración o trazas de solicitudes que no sean evidencia de seguridad.
- Elegir un producto WORM de un proveedor específico más allá del perfil de adopción.
- Orquestación completa del borrado, que pertenece al bloque relacionado de cumplimiento de privacidad.
Contrato
- Para clases de eventos marcadas explícitamente como
fail_closed: trueen el catálogo, el escritor de auditoría se niega a completar la acción a menos que estén presentes el identificador del actor, el identificador del objeto y el código de razón. Otros eventos siguen su política de disponibilidad declarada en lugar de una prohibición global de mutación. - Los registros almacenados no pueden ser actualizados ni eliminados por credenciales de la aplicación; solo se permite anexar.
- Cada registro almacena
record_sha256sobre bytes canónicos yprev_record_sha256; un trabajo de verificación falla cerrado ante una ruptura. - La restauración, truncado o eliminación de filas en la base de datos de la aplicación no elimina los registros de auditoría correspondientes.
- La clase de retención y
keep_daysse almacenan en el registro; los trabajos de borrado omiten esas filas y emiten un puntero a la clase. - Un identificador de retención legal extiende la retención más allá de
keep_dayshasta que el titular nombrado libera la retención.
Guía de implementación
- Proporcione a los servidores de la aplicación credenciales de solo anexado para un clúster de auditoría separado.
- Canonicalice los bytes antes de hashear; nombres desconocidos en el catálogo fallan cerrado.
- Los códigos de razón son obligatorios; el texto libre es un comentario opcional.
Manejo de fallos y salvaguardas
- Si el almacenamiento de auditoría está caído, solo los eventos del catálogo clasificados explícitamente como alta integridad y
fail_closed: truebloquean la acción asociada; otros eventos usan su cola o ruta de degradación documentada. - Las rupturas en la cadena congelan al escritor sospechoso y alertan a seguridad.
- Los trabajadores de borrado sin un mapeo de clase de retención no deben eliminar filas de auditoría.
Verificación y operaciones
- Verifique las últimas
verify_batch_sizeregistros cada noche contra el resumen de cabeza. - Después de restaurar OLTP, pruebe que la auditoría aún cubre esa ventana.
- Rastree omisiones de borrado y revise a los titulares de retención legal trimestralmente.
Los ejemplos con apariencia ejecutable en este paquete son fixtures y contratos de aceptación. Ejecute
python tools/validate.py desde la raíz de la colección para verificar la estructura y metadatos del paquete; luego
implemente y ejecute los escenarios en el repositorio objetivo.
Suposiciones de adopción
- Los nombres y valores numéricos en
example.yamlson un perfil de adopción, no valores predeterminados universales. - El equipo adoptante debe mapear actores, clases de datos, vocabulario de errores y propiedad a su sistema.