Planteamiento y alcance
Una plataforma multi-inquilino ya almacena eventos de auditoría, pero su equipo de seguridad necesita una forma independiente de determinar si los registros históricos fueron eliminados, reordenados o recalculados por alguien con acceso a la base de datos principal. Diseñe el protocolo de verificación, enfocándose en la canonicalización, cadenas de hashes segmentadas, firmas, anclajes externos, el resultado del verificador y el manejo de intervalos no verificables.
Los registros de solo anexado (append-only) y las cadenas de hashes permiten detectar ediciones posteriores, pero no prueban que un evento haya sido verídico cuando se escribió por primera vez. Esta pregunta evalúa el modelado de amenazas, la evidencia y las operaciones; el almacenamiento de objetos inmutable por sí solo no es un diseño completo.
Lo que evalúa el entrevistador
Evalúe los campos de evento para actor, objetivo, acción, hora, origen y resultado; el acoplamiento confiable con las transacciones de negocio; cadenas de hashes segmentadas y ancladas; aislamiento de inquilinos, índices, permisos de claves, retención, eliminación y un verificador utilizable.
Preguntas para aclarar antes de responder
- ¿Puede el actor de la amenaza modificar el almacén de eventos, el catálogo de hashes, las claves de firma y el medio de anclaje?
- ¿La verificación debe detectar la eliminación, modificación y reordenamiento, o también dar fe del origen del evento?
- ¿La plataforma, un equipo de seguridad o un auditor externo ejecutarán el verificador?
- ¿Durante cuánto tiempo pueden permanecer los registros sin anclar y cómo deben degradarse los flujos de trabajo de investigación tras una brecha?
Marco de respuesta de 30 segundos
“Definiría un evento canónico inmutable y lo publicaría a través de un outbox después de que la transacción de negocio haga commit. Un escritor aislado agrupa los eventos por inquilino y tiempo, construye cadenas de hashes y ancla periódicamente la cabeza de cada cadena en un almacén de solo anexado independiente o en un registro de transparencia. Las consultas utilizan índices reconstruibles, nunca mutan la evidencia. Un verificador recalcula las cadenas y compara los anclajes. La integridad proviene de la cadena; la veracidad del evento sigue proviniendo de la autorización de negocio y los registros de transacciones.”
Respuesta detallada paso a paso
Paso 1: Definir el modelo de amenazas y el objetivo de la evidencia
Asuma que un administrador de aplicaciones o de bases de datos puede eliminar, reordenar o reescribir registros, y que el servicio de anclaje puede no estar disponible. Decida si el objetivo es detectar eventos faltantes, modificados o reordenados, o probar que un sujeto actuó. Un registro de auditoría no reemplaza el control de acceso.
Paso 2: Diseñar eventos canónicos
Incluya ID de evento, inquilino, actor y origen de identidad, acción, recurso, resúmenes (digests) previos y posteriores, ID de solicitud, hora del evento, secuencia del servidor, resultado y versión de la directiva. Canonicalice JSON y campos similares para que el orden de serialización no cambie los hashes. Almacene únicamente resúmenes o referencias controladas para valores sensibles.
Paso 3: Acoplar las escrituras de negocio y de auditoría
La transacción de negocio escribe en un outbox; un consumidor confiable emite el evento después del commit. No dependa de registros de mejor esfuerzo (best-effort) después de una escritura de negocio. Los reintentos son idempotentes por ID de evento; los fallos van a una cola aislada y generan alertas. La latencia de auditoría puede estar acotada, pero la pérdida no puede ser silenciosa.
Paso 4: Construir cadenas de hashes segmentadas
Almacene el hash anterior, el evento canónico y el hash actual, como H(previous || event || metadata). Rote los segmentos por inquilino, fecha o tamaño y registre el inicio, fin y secuencia del segmento. El orden entre particiones (shards) utiliza la secuencia del servidor y la hora de recepción en lugar de solo los relojes del cliente.
Paso 5: Anclar externamente y gestionar claves
Escriba periódicamente la cabeza de cada segmento en un medio de solo anexado aislado con la hora de anclaje, el ID de segmento y la firma. Mantenga las claves de firma en un servicio de claves controlado; la rotación y revocación son auditadas en sí mismas. Un anclaje independiente evita que un escritor de la base de datos recalcule y reemplace una cadena completa de forma invisible.
Paso 6: Aislar consultas y permisos
Construya índices de actor, recurso, acción y tiempo en un índice de búsqueda o réplica de lectura. Los índices son reconstruibles; la evidencia no es modificable. Aplique comprobaciones de inquilino, rol y propósito, e incluya un resumen de verificación en las exportaciones. Cada lectura, exportación o verificación es un nuevo evento de auditoría.
Paso 7: Manejar retención, eliminación y privacidad
Establezca directivas de retención, WORM o bloqueo de objetos según la regulación. Para la eliminación de datos personales, utilice borrado criptográfico, redacción de campos o resúmenes irreversibles manteniendo al mismo tiempo la prueba de que se produjo la eliminación; nunca reescriba el historial silenciosamente. Alinee la retención de respaldos, cachés y anclajes.
Paso 8: Verificar, recuperar y monitorear
El verificador comprueba la continuidad de la cadena, la secuencia, los hashes canónicos, las firmas y los anclajes externos. Ejecute verificaciones periódicas por muestreo y completas, monitoreando brechas, retraso (lag), duplicados, fallos de anclaje y tiempo de verificación. Recupere reproduciendo el outbox y los segmentos de solo anexado desde el último anclaje confiable, aislando los rangos no demostrables.
Compensaciones y límites más profundos
#### Una sola cadena frente a cadenas segmentadas
Una sola cadena simplifica las consultas pero complica la recuperación y las escrituras concurrentes. Los segmentos permiten el aislamiento de inquilinos, la verificación en paralelo y la gestión de retención, a costa de anclajes de segmento y metadatos de ordenamiento.
#### Cadena de hashes frente a registro firmado
Las cadenas de hashes son económicas y detectan ediciones; las firmas añaden verificación interorganizacional y costos de gestión de claves. Combínelas cuando se requiera prueba externa.
#### Integridad frente a veracidad
Una cadena prueba las relaciones entre registros y la consistencia del anclaje, no que el contenido del evento fuera verídico. La veracidad aún depende de la identidad, autorización, transacciones y evidencia independiente.
Simulacros de fallos y evolución
#### Se elimina un registro intermedio
Elimine un objeto de un segmento y verifique que se reporten una brecha de secuencia y una ruptura de cadena junto con la ubicación del segmento y del anclaje.
#### Un administrador de base de datos recalcula los hashes
Reescriba un segmento y reemplace su cabeza; el anclaje independiente debe rechazar la nueva cadena mientras la cadena anterior sigue siendo recuperable para investigación.
#### El servicio de anclaje no está disponible
Desconéctelo y verifique que los segmentos entren en un estado de anclaje pendiente, los eventos permanezcan durables y los anclajes se agreguen en orden tras la recuperación con una alerta.
Respuesta de muestra de alta calidad
“Primero definiría el límite de verificación: un atacante puede alterar el almacén de eventos y el índice de búsqueda, pero no puede reescribir también un anclaje independiente ni obtener la clave de verificación. El escritor convierte cada evento en una representación canónica determinista, segmenta los registros por inquilino y tiempo, y almacena un número de secuencia, el hash anterior y el hash actual. Firma el final de cada segmento y periódicamente realiza un commit de la cabeza de la cadena en un medio de solo anexado bajo permisos separados.
Un verificador independiente comienza desde un anclaje de confianza, recalcula los hashes canónicos y comprueba la continuidad de la secuencia, los enlaces entre segmentos, las firmas, los tiempos de anclaje y la directiva de retención. La eliminación crea una brecha de secuencia, la modificación genera una discrepancia de hash, el reordenamiento rompe los enlaces predecesores, y un administrador que recalcula un segmento entero aún no puede coincidir con el anclaje externo. El resultado reporta el rango verificado, la primera posición con fallo, la ventana no anclada y las referencias de evidencia en lugar de un único valor booleano. Si un intervalo no se puede verificar, congelo las exportaciones afectadas, preservo los objetos originales y notifico a seguridad. La cadena establece la integridad del registro; la identidad, la autorización y la evidencia de transacciones de negocio todavía son necesarias para establecer la veracidad del evento.”
Errores comunes
- Poner datos en almacenamiento WORM sin definir quién puede escribir o cambiar la retención.
- Calcular el hash de JSON sin procesar sin canonicalizar el orden de los campos, la codificación y las marcas de tiempo.
- Tratar una cadena de hashes válida como prueba de que cada evento fue verídico.
- Reconstruir y reemplazar automáticamente una cadena fallida, destruyendo evidencia de investigación.
Preguntas de seguimiento y respuestas
¿Qué resuelve un anclaje externo?
Evita que un operador con acceso de escritura al almacén principal recalcule silenciosamente un segmento entero y reemplace la cabeza de su cadena. El anclaje necesita permisos y retención separados.
¿Cómo puede el verificador probar que un registro fue eliminado?
Detecta tanto una brecha de secuencia como un hash posterior roto, y luego utiliza los anclajes de confianza más cercanos para delimitar el intervalo faltante. La mera ausencia en un índice de búsqueda no es suficiente.
¿Qué sucede mientras el servicio de anclaje no está disponible?
Se continúa escribiendo segmentos locales secuenciados y se marcan como pendientes. Se envían en orden tras la recuperación. La ventana no anclada debe aparecer en el resultado del verificador y en las alertas, y no puede describirse como totalmente verificada.
¿Cómo se debe manejar un intervalo no verificable?
Ponga en cuarentena las exportaciones afectadas, preserve los objetos originales, las firmas y la evidencia de anclaje, notifique a seguridad y registre la respuesta. La recuperación no debe volver a etiquetar un intervalo desconocido como completo.