Cadena de auditoría
Cada acción relevante para la seguridad, encadenada criptográficamente. Inviolable por diseño.
Encadenamiento HMAC-SHA256 a nivel de fila, triggers append-only en base de datos y secuencia monótona por inquilino. Tres señales de manipulación independientes integradas en el esquema, no añadidas a posteriori.
POR QUÉ ESTO NO ES UNA FUNCIÓN
Nuestro registro de auditoría está encadenado criptográficamente a nivel de fila
Un atacante con acceso de escritura total a la base de datos sigue sin poder falsificar ni borrar una fila sin dejar evidencia. La misma primitiva de hash chain que usan los libros mayores blockchain, aplicada a nivel de fila, con un secreto HMAC en lugar de un protocolo de consenso.
7 años. 2.555 días. Cada acción relevante para la seguridad de cada usuario, capturada y verificable.
CÓMO FUNCIONA
Tres campos convierten cada fila en evidencia
Cada fila de audit_logs lleva tres campos protectores. La tabla no es nada del otro mundo; la disciplina está en lo que se calcula y firma en cada inserción.
sequence
Entero monótonamente creciente, por inquilino. Un hueco en la secuencia significa que se borró una fila, y el verificador marca el primer número que falta.
prev_hash
Apunta al row_hash de la fila anterior. Cadena rota significa fila reordenada o insertada fuera de procedimiento.
row_hash
HMAC-SHA256 sobre la serialización canónica de {tenant_id, sequence, prev_hash, actor_id, action, resource_type, resource_id, payload, created_at}, firmado con AUDIT_HMAC_KEY que custodia la aplicación, no la base de datos.
TRES SEÑALES DE MANIPULACIÓN
Qué detectamos y cómo
| Ataque | Qué detectamos | Cómo |
|---|---|---|
| Mutación de fila | El row_hash almacenado ya no coincide con el HMAC recalculado. | El verificador recorre la cadena y recalcula cada fila desde su payload canónico. |
| Borrado de fila | Aparece un hueco de secuencia y el prev_hash de la fila superviviente ya no coincide con su predecesor real. | Comprobación de secuencia más comprobación de cadena; cualquiera de las dos basta para detectarlo. |
| Inserción o reordenamiento de fila | La fila insertada no puede referenciar un prev_hash real, por lo que la cadena falla en la fila insertada o en la siguiente. | El recorrido de la cadena capta la discontinuidad en el primer hash inválido. |
DEFENSA EN PROFUNDIDAD
Tres capas, separadas a propósito
Aplicación append-only
Un trigger de PostgreSQL bloquea cualquier DELETE contra audit_logs. El borrado solo es posible dentro de una transacción con SET LOCAL app.audit_retention_cleanup = on, un flag que solo posee el barrido de retención. SET LOCAL es de ámbito de transacción, así que el flag se borra al commit o rollback y no puede filtrarse a sentencias posteriores.
Separación de claves
El secreto HMAC vive en la configuración de la aplicación, no en la base de datos. Un compromiso de solo lectura de la base no puede forjar filas válidas. Un compromiso de escritura es detectado por la siguiente ejecución del verificador, que usa el secreto HMAC para recalcular cada fila y expone los fallos como eventos de auditoría propios.
Independencia del verificador
El verificador recorre la cadena de cada inquilino de extremo a extremo usando el secreto HMAC custodiado por la aplicación. Sus resultados son a su vez entradas en la cadena, por lo que una ejecución deshabilitada u omitida es visible en el momento en que ocurre.
QUÉ SE REGISTRA
Todo evento que toca el registro operativo
- 01 Toda autenticación: login, logout, alta de MFA, cambio de contraseña, restablecimiento de contraseña
- 02 Toda autorización: cambios de rol, concesiones de permisos, creación y revocación de claves API
- 03 Toda acción administrativa sensible: ajustes de inquilino, cambios de retención, overrides de contexto RLS
- 04 Todas las firmas de órdenes de trabajo, con el SHA-256 del payload de firma
- 05 Todos los eventos de suscripción y facturación: recepción de webhook, cambio de plan, sesión de portal de cliente
- 06 Todos los cambios de configuración de fuentes de ingesta
- 07 Todos los cambios de configuración SSO
- 08 Todas las exportaciones: CSV, PDF, entregas programadas de informes
- 09 Todas las eliminaciones en lote y ejercicios de derecho de supresión
RETENCIÓN
2.555 días. Independiente de la retención operativa.
RetentionConfig.AUDIT_LOG_DAYS mantiene la cadena durante siete años. Tenant.data_retention_days está diseñado para controlar los datos operativos por separado, de modo que la telemetría puede purgarse en una ventana configurable mientras la cadena de auditoría sigue cubriendo la ventana de evidencia SOC 2 CC2.2 y las normas de retención adyacentes a las financieras.
MAPEADO DE CUMPLIMIENTO
A qué responde la cadena
SOC 2 CC6.1 y CC7.2
Registro inviolable y el rastro de evidencia para la gestión del cambio. La cadena es lo que recorre su auditor SOC 2 durante el periodo de observación para satisfacer CC6.1 (acceso lógico) y CC7.2 (monitorización del sistema).
ISO 27001 A.12.4
Registro de eventos e integridad de logs de operador. Cada acción administrativa y excepción aterriza en la cadena con marca temporal, atribución y el payload canónico sobre el que se actuó.
FDA 21 CFR Part 11 §11.10(e)
Pistas de auditoría seguras, generadas por ordenador y con sello temporal para registros electrónicos. Cada evento firmado es atribuible, contemporáneo, original, exacto y sellado en el tiempo, apoyando el esfuerzo de validación 21 CFR Part 11 del cliente.
RGPD Artículo 30
Registro de actividades de tratamiento. Su DPO puede extraer bajo demanda una porción de auditoría por inquilino. Los datos personales dentro de audit_logs se limitan a identificadores de usuario y direcciones IP; los payloads más ricos solo llevan el contexto mínimo necesario para reconstruir el evento.
Directiva NIS2 de la UE
Evidencia para investigación de incidentes. Los CSIRT de los Estados miembros y su propio equipo forense pueden reconstruir exactamente quién hizo qué y cuándo, con una cadena cuya integridad no depende de la confianza en el administrador de base de datos.
EL VERIFICADOR
Verificación de auditoría auditada
La verificación recalcula cada fila desde su payload canónico usando el secreto HMAC del inquilino y devuelve PASS con el recuento de filas o FAIL en el primer número de secuencia roto. Los resultados del verificador son a su vez entradas de la cadena.
Cadencia
Hoy bajo demanda desde el endpoint de verificación administrativa. La verificación diaria programada llega con la versión GA de la plataforma.
Resultado
PASS con el recuento de filas, o FAIL con el primer número de secuencia donde la cadena se rompió. La fila se conserva como evidencia.
Código fuente
El código del verificador está disponible para que su auditor lo recorra. Nos sentamos en la sala mientras lo hace.
POR QUÉ ESTO SUPERA A "TENEMOS LOGS DE AUDITORÍA"
Los logs estándar no sobreviven a un operador decidido
Tabla de auditoría plana
Amigable con el append pero mutable. Cualquiera con acceso de escritura a la base puede cambiar una fila, borrar una fila o insertar una. Sin señal matemática de que haya ocurrido.
Almacenamiento WORM
Ayuda contra el borrado, menos contra la inserción o reordenamiento. La integridad a nivel de almacenamiento no atrapa una fila que nunca debió estar ahí.
Log encadenado por hash (este)
Inviolable en sentido matemático. Detecta mutación, borrado e inserción a nivel de fila, con el hash padre como ancla de integridad.
PREGUNTAS FRECUENTES
¿Qué ocurre con la cadena si un hash no coincide?
El verificador devuelve FAIL con el primer número de secuencia donde la cadena se rompió. La fila no se elimina, conservamos la evidencia. El fallo se registra como una entrada propia de la cadena y aflora a través del flujo de incidentes de la plataforma.
¿Puede el administrador de base de datos manipular la cadena?
No, salvo que (a) rompa el trigger append-only, (b) obtenga el secreto HMAC que vive fuera de la base y (c) reescriba cada fila posterior del inquilino afectado. Los tres pasos dejarían su propia evidencia forense.
¿Pueden borrar una fila por el derecho de supresión del RGPD?
Los datos personales en audit_logs ya están minimizados a user_id e IP. El derecho de supresión sobre el usuario no elimina la historia de auditoría, ya que ese tratamiento se apoya en el artículo 6(1)(c) obligación legal y (f) interés legítimo. Podemos pseudonimizar la referencia user_id si su DPO lo exige.
¿Ralentiza la cadena las escrituras?
Cada inserción calcula un HMAC y lee una fila previa, ambas indexadas. Coste despreciable en cargas típicas, y el verificador corre fuera de la ruta crítica.
