La falsa inmutabilidad de los logs

Introducción

¿Cuántos sistemas hemos diseñado bajo la premisa de que sus logs son inmutables?
Creamos una tabla, deshabilitamos los endpoints PUT o PATCH, añadimos algunas validaciones y asumimos que con eso basta. Nuestros logs son inmutables. O al menos eso creemos.

Sin embargo, impedir modificaciones a nivel de API no equivale a garantizar inmutabilidad real. Cualquier actor con acceso directo a la base de datos y conocimientos básicos de SQL puede modificar registros históricos, alterar su contenido o incluso reescribir estructuras completas. En ese momento, el log deja de ser una fuente fiable de verdad y pasa a depender exclusivamente de la confianza en quien tiene acceso al sistema.

Cuando la trazabilidad es crítica ---ya sea por razones de seguridad, cumplimiento normativo o auditoría--- esta confianza implícita no es suficiente. Necesitamos mecanismos que no solo desalienten la manipulación, sino que la hagan detectable de forma verificable.

El modelo tradicional

En muchos sistemas, los logs siguen una estructura similar a esta:

id: uuid
created_at: datetime
level: enum
message: text

Este modelo es funcional y suficiente para almacenar eventos. Sin embargo, desde el punto de vista de la integridad histórica, no introduce ningún mecanismo que evidencie una modificación posterior.

Si un registro cambia, el sistema no deja ninguna señal estructural de que eso ha ocurrido.

La seguridad del log depende exclusivamente del control de acceso.
Y el control de acceso no es una garantía criptográfica.

Encadenamiento por hash: integridad detectable

Existen mecanismos criptográficos ampliamente conocidos que permiten encadenar registros de forma que cualquier alteración posterior resulte detectable. Uno de ellos consiste en hacer que cada log incluya el hash del log anterior.

La fórmula es sencilla:

hash_n = H(contenido_n + hash_(n-1))

Es decir, el hash de cada registro depende tanto de su contenido como del hash del registro previo.

Ejemplo conceptual

Supongamos el siguiente log:

{
  "hash": "abc123",
  "content": "hola",
  "previous_hash": "cba321"
}

Si queremos insertar un nuevo log con el contenido "buenas tardes", generaremos su hash utilizando:

• El nuevo contenido.
• El hash del log anterior ("abc123").

De esta forma, cada registro queda criptográficamente vinculado al anterior.

¿Qué ocurre si alguien modifica un log?

Si un actor modifica el contenido de un log antiguo, su hash cambia automáticamente, ya que el hash depende del contenido.

Pero al cambiar ese hash, todos los registros posteriores dejan de ser coherentes, ya que su previous_hash ya no coincide con el valor esperado.

Esto no impide que alguien modifique la base de datos.
Lo que hace es mucho más importante: convierte la manipulación en algo detectable.

El sistema deja de basarse en la confianza implícita y pasa a basarse en la verificación criptográfica.

No estamos hablando de inmutabilidad absoluta.
Estamos hablando de integridad verificable.

¿Y qué ocurre si la normativa obliga a borrar logs?

Aquí aparece una tensión interesante entre dos principios:

• Integridad histórica.
• Derecho al borrado o políticas de retención.

Un sistema hash-encadenado no impide eliminar registros, pero hacerlo rompe la cadena de verificación. Por ello, en entornos reales suelen aplicarse estrategias como:

• Retención por bloques temporales (por ejemplo, cadenas mensuales).
• Checkpoints o root hashes periódicos.
• Pseudonimización o cifrado de datos sensibles.
• Borrado criptográfico (eliminando claves de descifrado en lugar de alterar la cadena).

La clave no está en impedir cualquier modificación, sino en diseñar el sistema para que cualquier alteración deje evidencia técnica.

Conclusión

Los logs tradicionales no son inmutables; simplemente están protegidos por convenciones y controles de acceso.

En sistemas donde la trazabilidad es crítica, esto puede no ser suficiente.

El encadenamiento por hash no es una innovación reciente ni una tecnología exclusiva de sistemas distribuidos. Es un principio criptográfico simple que, aplicado correctamente, permite transformar un sistema de logs convencional en un mecanismo de detección de manipulación.

La diferencia es sutil pero fundamental:

No se trata de confiar en que nadie modificará los registros.
Se trata de poder demostrar si alguien lo ha hecho.