Un audit trail que no se altera en silencio.
Audit trail
Cada decisión de admission recibe su hash al escribirse y queda sellada bajo checkpoints firmados que se encadenan hasta el primero. La clave de firma está en un Secret de su cluster, no en la base de datos, así que reescribir la historia exige dos accesos distintos.
Cada documento de evidencia vuelve a comprobar el ledger completo e indica si está intacto. Los cambios hechos desde la consola, de ediciones de policy y break-glass a triage y exportaciones de evidencia, se guardan aparte en un registro de auditoría, con quién y cuándo.
Paso a paso.
Un hash por registro
El operator calcula el SHA-256 de su contenido al escribirlo.
Registros sellados
Cada hora por defecto, o cada 10.000 registros: una Merkle root firmada.
Sellos encadenados
Cada checkpoint lleva el hash del anterior.
Cada documento recomprueba
Cadena, hashes de registros, roots y recuentos, firmas.
Manipulación señalada
Un registro editado aparece por su id.
El resultado de la comprobación del ledger, intacto o no y por qué, es una sección de cada paquete de evidencia.
- DORA4 requisitos
- NIST SP 800-1904 requisitos
- NIST SSDF4 requisitos
- NIST SP 800-535 requisitos
- ISO/IEC 270015 requisitos
- RGPD artículo 323 requisitos
- PCI DSS3 requisitos
- MAS TRM7 requisitos
- Essential Eight2 requisitos
- ISMAP10 requisitos
- ISMS-P10 requisitos
57 requisitos de 11 frameworks citan lo que registra esta función.
Instálelo usted mismo.
Cree una cuenta, confirme su correo con el código que le enviamos, obtenga la clave Community gratuita en la página Licences e instale con Helm.
Crear una cuenta