Casi todas las propuestas comerciales de herramientas de registro, archivo o auditoría incluyen hoy la palabra «inmutable». Almacenamiento inmutable, logs inmutables, copias de seguridad inmutables. La palabra transmite seguridad, y por eso aparece con tanta frecuencia. El problema es que describe una propiedad del sistema del proveedor, y no lo que un auditor, un regulador o un tribunal necesita ver: una prueba que pueda confirmarse de forma independiente.
Esta guía está dirigida a equipos de seguridad, cumplimiento y compras que necesitan evaluar afirmaciones sobre pistas de auditoría. No pretende restar valor a la inmutabilidad, que es útil y con frecuencia necesaria, sino separar dos preguntas que suelen confundirse: «¿puede alterarse este registro?» y «¿puedo demostrar a un tercero que no se ha alterado?»
Dos propiedades distintas
La inmutabilidad es un control preventivo. Un sistema de almacenamiento WORM (write once, read many), un bloqueo de objetos con período de retención o una base de datos append-only intentan impedir que un registro se modifique o se borre una vez escrito. Si el control funciona como se promete, el registro se mantiene.
La verificabilidad es una propiedad de evidencia. Significa que cualquier parte interesada, con la información adecuada, puede confirmar que un registro es hoy exactamente igual que en un momento determinado, sin tener que fiarse de la palabra de quien lo guarda. La verificación suele basarse en huellas digitales criptográficas (funciones hash), sellos de tiempo y un punto de referencia que no está controlado únicamente por la entidad que produjo el registro.
Las dos propiedades se complementan, pero no se sustituyen. Un sistema puede ser inmutable y, aun así, no ofrecer ninguna forma de demostrarlo fuera del propio sistema. Y un registro puede ser verificable aunque esté guardado en un soporte común, siempre que su huella digital se haya fijado en un lugar independiente.
La inmutabilidad es una promesa sobre el comportamiento de un sistema. La verificabilidad es una prueba que un tercero puede confirmar por sí mismo.
Por qué «inmutable» no basta en una auditoría
La confianza sigue depositada en el operador
Cuando un proveedor afirma que los registros son inmutables, la garantía depende de la configuración correcta del sistema, de los permisos de quien lo administra y de la ausencia de fallos. Muchos mecanismos de retención incluyen modos que permiten a usuarios con privilegios especiales acortar o eliminar la retención. Incluso en los modos más estrictos, la garantía sigue siendo una afirmación sobre un sistema que el auditor no controla.
La inmutabilidad no dice nada sobre lo que se escribió
Un registro inmutable conserva fielmente lo que se colocó en él. Si los datos ya estaban manipulados en el momento de la escritura, si un evento nunca llegó a registrarse o si un proceso automático falló en silencio durante horas, el soporte inmutable conserva esa realidad incompleta con el mismo rigor. La pregunta relevante no es solo «¿se alteró después?», sino también «¿está completo y corresponde al origen?».
La prueba tiene que sobrevivir al sistema
Las auditorías, los litigios y las inspecciones regulatorias pueden producirse años después de los hechos. Para entonces, el proveedor original puede haber sido sustituido, el sistema puede haberse migrado y las personas que lo configuraron pueden ya no estar en la organización. Una afirmación de inmutabilidad rara vez sobrevive a una migración. Una prueba verificable sí, siempre que el método de verificación esté documentado.
Ocho preguntas para hacer a cualquier proveedor
Las siguientes preguntas ayudan a convertir una afirmación genérica en una evaluación concreta. No existe una única respuesta correcta para todas, pero las respuestas vagas deben tratarse como una señal de alerta.
- ¿Quién puede verificar y con qué acceso? ¿Puede un auditor externo confirmar la integridad de un registro sin credenciales de administración y sin pedir ayuda al proveedor?
- ¿Qué se sella exactamente? ¿El archivo completo, cada fila de una tabla, cada evento de log o solo un resumen diario? La granularidad determina qué es posible demostrar.
- ¿Dónde está el punto de referencia? Si la huella digital de referencia está guardada en el mismo sistema que los datos, quien comprometa uno puede comprometer el otro.
- ¿Cómo se trata el tiempo? ¿El sello de tiempo procede del reloj del servidor o de una fuente independiente y verificable? ¿Puede demostrar que un registro existía antes de una fecha determinada?
- ¿Cómo se detecta una omisión? ¿Borrar un registro o dejar de escribirlo deja algún rastro? Mecanismos como las cadenas de hashes o la numeración secuencial permiten detectar lagunas.
- ¿Qué ocurre con los datos personales? Si el contenido tiene que borrarse en virtud del RGPD, ¿sobrevive la prueba de integridad sin exponer el contenido original? Sellar huellas digitales en lugar de datos resuelve esta tensión.
- ¿En qué formato se exporta la prueba? ¿Puede entregarse la evidencia a un regulador en un formato documentado y verificable con herramientas comunes, o solo es legible dentro de la plataforma?
- ¿Cómo evoluciona la criptografía? ¿Existe un plan para sustituir los algoritmos que lleguen a considerarse débiles, sin perder la validez de las pruebas ya emitidas?
Cómo es una verificación independiente en la práctica
El principio es sencillo. En el momento en que se crea o certifica un registro, se calcula su huella digital con una función hash criptográfica, como SHA-256. Esa huella digital, un valor corto y único para ese contenido exacto, se sella con un sello de tiempo en un registro independiente. El contenido original permanece donde siempre ha estado.
Más tarde, para verificar, se recalcula la huella digital del archivo tal como está hoy y se compara con la que se selló. Si son iguales, el contenido no ha cambiado desde el momento del sellado. Si difieren, aunque sea en un solo bit, la alteración se hace evidente. Este proceso no exige confiar en quien guarda el archivo: solo requiere acceso al archivo, al registro de referencia y a un método de cálculo público.
Este diseño es el que hace posible, por ejemplo, un portal de verificación público donde cualquier destinatario de un informe confirma su autenticidad sin tener cuenta en la plataforma de quien lo emitió.
Señales de alerta en una propuesta
- La palabra «inmutable» aparece sin explicar el mecanismo que la garantiza.
- La verificación solo es posible a través de la interfaz del proveedor, con sesión iniciada.
- No está claro qué ocurre con las pruebas si el contrato termina.
- La detección de cambios depende de que alguien se acuerde de comparar manualmente.
- El proveedor no sabe explicar cómo se detectaría la eliminación de un registro.
Ninguno de estos puntos es, por sí solo, eliminatorio. Pero cada uno representa una parte de la cadena de confianza que sigue dependiendo de una promesa en lugar de una prueba.
Cómo ayuda ROOTKey
ROOTKey se ha diseñado en torno a la distinción descrita en este artículo. Cada activo recibe una huella digital única, sellada de forma permanente en un registro público independiente: un registro con sello de tiempo de su estado exacto. Con un despliegue a medida, los datos permanecen en su propia infraestructura; solo se registra la huella digital.
A partir de ese sello, la monitorización continua compara sus datos con el registro y activa una alerta ante cualquier modificación. Cada acción se sella con un sello de tiempo criptográfico, lo que forma una cadena de custodia lista para los auditores y exportable a los reguladores. Y cualquier destinatario puede confirmar la integridad de un documento emitido a través de ROOTKey en el portal público de verificación, sin depender de la palabra de nadie.