Auditoría y registros sin cambios

Auditoría y registros sin cambios

1) Por qué es necesario

El objetivo de la auditoría es fijar «quién, qué, dónde, cuándo y por qué» con integridad probada para mantener la seguridad, las investigaciones, los estados financieros y el cumplimiento.
Registro inmutable: formato y almacenamiento donde los eventos sólo se escriben agregando (append-only) y la modificación/eliminación posterior no es posible o es detectable por los medios criptográficos y las políticas de retención.

2) Modelo de amenazas y objetivos de control

• Edición/eliminación intencional de eventos por parte del iniciador.
• Sustitución de tiempo/origen (replay/backdating).
• Silencioso apagar la lógica en el nodo.
• Pérdida de parte del registro en accidentes/migraciones.
• Exceso de cobro de PII y discordia con la privacidad.

1. Integridad: probada por protección contra modificaciones/eliminaciones.

2. Plenitud: cierre de flujos clave (control plane, data plane, accesos, dinero).

3. Precisión de tiempo: tiempo reproducible, sincronizado.

4. Disponibilidad: leer y buscar dentro de SLO.

5. Privacidad: mínimo PII, tokenización/encriptación, legalidad de uso.

3) Taxonomía y prioridades de eventos

• Control Plane: autenticación/autorización, cambios de configuración, operaciones de claves (KMS), administración de secretos, cambio de políticas.
• Plan de datos: acceso a objetos/registros/cheques/pagos; lectura/creación/eliminación.
• Administración y DevOps: SSH/consola, CI/CD, cambios de infraestructura/IaC, escalamiento de derechos.
• Productos: transacciones, facturación, transacciones de clientes.
• Sistema/red: núcleo/agentes/proxy/balanceadores, corredores, DB.
• Seguridad: IDS/IPS/EDR, WAF, anti-DDoS, antifraude, DLP.

Para cada clase, fijamos: criticidad, esquema, campos obligatorios, vida útil, requisitos de inmutabilidad.

4) Campos y formato obligatorios

Los identificadores de correlación son: 'trace _ id', 'span _ id', 'request _ id', 'actor _ id' (usuario/servicio), 'tenant _ id', 'resource _ id'.
Contexto A&A: modo de autenticación, rol/política en el momento de la acción.
Tiempo: RFC3339/UTC, milisegundos/nanosegundos; fuente de sincronización.
Acción y resultado: tipo de operación, objetivo, estado, número de objetos afectados.
Integridad: registros HMAC locales, número de secuencia (sequence), hash-prev.
Esquema: JSON con un modelo estable (por ejemplo, compatible con diccionarios de eventos comunes).

Prohibido: secretos, claves, tokens llenos de PAN, contraseñas, claves privadas. PII - sólo por necesidad, con enmascaramiento/tokenización.

5) Tiempo y sincronización

Fuente de tiempo: al menos dos fuentes independientes (NTP/PTP) + monitoreo de desplazamiento.
Firmas de tiempo críticas: utilice los servicios de marca de tiempo de confianza (TSA) o el servicio de tiempo de sellado interno para paquetes de eventos.
Reglas: no hay zonas horarias locales, sólo UTC; lógica y desplazamiento/calidad del tiempo.

6) Arquitectura de flujo de registros

Agentes → Buffer → Transporte → Landing → Hash Chain/firma → Frío/Archivo → Índice para buscar.

Recogida en el nodo: agentes ligeros (daemonset/sidecar) con buffer en disco (back-pressure).
Transporte: canal seguro (TLS/mTLS), entrega garantizada (at-least-once), idempotent-ingest.
Zona de carga: almacén de objetos en forma «cruda» (lotes por fecha/tenante/tipo).
Índice: motor de búsqueda/análisis para consultas en línea (capa caliente).
Archivo (WORM): baquetas/cintas inmutables con políticas de retención y hold legal.
Anchor/Seal: «sellado» periódico de paquetes de hash (ver más abajo).

7) Inmutabilidad criptográfica

7. 1 Cadenas de hashes (append-only)

Cada entrada contiene: 'hash _ curr = H (record)', 'hash _ prev' de la entrada anterior, 'seq'. Cualquier edición rompe la cadena.

prev = GENESIS for record in stream:
payload = canonical_json(record_without_integrity_fields)
h = H(payload          prev.hash          record.seq)
store(record + {hash_prev: prev.hash, hash_curr: h})
prev = {hash: h}

7. 2 Firma de paquetes y sello de tiempo

Cada N segundos/MB formamos un bloque: la raíz de Merkl de todos los 'hash _ curr'.
Firmamos el bloque con una clave de auditoría (almacenada constantemente en KMS/HSM).
Agregamos la marca de tiempo TSA y publicamos el «Directorio de bloques» (Transparency Log).
Opcional: periódicamente el hash de anclaje de raíz en un espacio externo probado (por ejemplo, una revista independiente o un repositorio público inmutable).

7. 3 Administración de claves de auditoría

Claves de firma - en KMS/HSM, rotación gráfica, acceso multifactorial, control dual para exportación.
Revocación de clave → nueva rama de confianza; las firmas antiguas siguen siendo verificables.

8) Políticas de retención y WORM

WORM/immutabilidad: incluye contenedores/baquetas inmutables con las políticas Retention y Legal Hold para las clases de P0/P1.
Versificación: habilitada; Eliminación: sólo por procedimientos retrasados (prohibición de la purgación instantánea).
Retención: caliente (7-30 días), caliente (3-6 meses), frío/archivo (1-7 años o más - dependiendo del regulador/contrato).
Multiarrendamiento: espacios de nombres separados/cuentas/claves de cifrado por arrendatario; informes de acceso a registros.

9) Privacidad y minimización

Recolección por principio de necesidad: no lógicamos el exceso.
Tokenización/pseudonimización de campos sensibles, hash con sal para identificadores.
Cifre los campos del lado del productor (AEAD) cuando se almacenan en un almacén de objetos compartido.
Derecho de eliminación (en su caso): se ejerce a través de la encriptación-borrado de las claves de los campos/lotes, sin alterar la inmutabilidad del contenedor (planeado durante el diseño).

10) Acceso, funciones y auditoría de la propia auditoría

Separación: producers ≠ readers ≠ admins.
Sólo lectura de WORM; cambiar las políticas de retención - a través de roles separados y un procedimiento con aprobación.
Todas las operaciones de lectura/exportación se registran en un registro secundario (meta-auditoría).
Exportar para efecto/cumplimiento - en forma cifrada con el directorio de bloques hash y la cadena de confianza.

11) Observabilidad y SLO

Métricas: velocidad del higo, valor del índice, porcentaje de tiempo perdido/repetido, proporción de tiempo no sincronizado, errores de firma/anclaje, relleno de búferes.
SLO: ≥99. 9% de los eventos entregados ≤ X segundos al índice caliente; 0 inexplicables «agujeros» en las secuencias; El 100% de los bloques están firmados y marcados con tiempo.
Alertas: pausa de higo> N minutos, crecimiento invalid-hash, discrepancia de cadena, fracaso de firma/timestamp, desplazamiento de tiempo más allá del umbral.

12) Pruebas y verificación

Pruebas Red/Blue: intentar editar/eliminar un registro en diferentes etapas; comprobación de detección.
Chaos: deshabilitar el agente en el nodo, romper la red, desbordar el búfer, «reemplazar el tiempo».
Crypto-check: validación regular de cadenas, verificación de raíces y sellos de Merkl.
Forenzika: reproducir guiones de investigación de revistas de fin a fin.

13) Explotación y procedimientos

Runbook «comprobación de integridad» (on-demand y según lo programado).
Procedimiento de hold legal y «congelación» temporal de lotes.
Procedimiento de descubrimiento y exportación con el mantenimiento de la cadena de confianza.
Plan de rotación de claves de auditoría y respuesta de compromiso (nueva rama de confianza, pluma-firma de bloques, notificaciones).

14) Mini recetas

records = read_partition(ts_window)
leaves = [H(canonical_json(r)) for r in records]
root  = merkle_root(leaves)
sig   = KMS.sign(root          ts_now)
tsa   = TSA.timestamp(sig)
store_block({root, sig, tsa, count=len(leaves), window})
append_transparency_log(H(root          sig          tsa))

for i in 1..N:
assert rec[i].hash_prev == rec[i-1].hash_curr assert rec[i].hash_curr == H(canonical_json(rec[i]_no_hash)          rec[i].hash_prev          rec[i].seq)

• Control/Data plane P0: caliente 30 días → cálido 6 meses → archivo 7 años (WORM).
• DevOps: caliente 14 días → cálido 3 meses → archivo 1 año.
• Señales de Security: caliente 90 días (para investigaciones), luego 1-3 años.

15) Errores frecuentes

«Los registros son texto sin esquema». Sin el esquema, no hay integridad determinista y búsqueda; JSON canónico y campos fijos son obligatorios.
No hay correlación. La ausencia de 'trace _ id' rompe las investigaciones.
Hora local. Sólo UTC y control de desplazamiento.
Escribir en volúmenes modificados. Sin WORM, cualquier inmutabilidad es una ficción.
Las lecturas no son lógicas. La lectura de datos sensibles es importante para fijar no menos que la escritura.
Los secretos están en las guaridas. Incluya los saneadores antes del envío, las «listas rojas» de los patrones.
Una llave para todo. Las claves de firma y encriptación son separadas, con papel y rotación.

16) Cumplimiento y regulación

Los requisitos para los períodos de retención/inmutabilidad dependen del dominio (finanzas, pagos, telecomunicaciones, etc.).
Probabilidad: disponibilidad de protocolos WORM/retención, informes de validación de circuitos, registros de acceso a registros, procedimientos legales de hold y exportación.

17) Hojas de cheques

Antes de la venta

• Se ha aprobado la taxonomía de eventos y el esquema (campos obligatorios).
• Agentes configurados, búferes, transporte seguro, back-pressure.
• Incluido: hashes cadenas, firma de bloques, sello de tiempo, registro de transparencia.
• El almacenamiento WORM/Retence está habilitado; prueba de la imposibilidad de sobrescribir/eliminar.
• Enmascaramiento/tokenización de campos sensibles.
• Sincronización de tiempo y monitoreo de desplazamiento.
• Plan de rotación y almacenamiento de claves de auditoría en KMS/HSM.

Explotación

• Validación semanal de cadenas y bloques (+ informe).
• Alertas para rotura de cadena/error de firma/desplazamiento de tiempo.
• Pruebas periódicas de sustitución/eliminación de equipo rojo.
• Review regular de retén y costos.

18) FAQ

P: ¿Es suficiente simplemente «solo-añadir» a nivel de DB?
Oh no. Se necesitan garantías criptográficas (cadenas de hashes, firmas de bloques, sellos de tiempo) y políticas WORM.

P: ¿Cómo puedo estar con el derecho a eliminar datos?
R: Diseñe la encriptación (eliminación de claves) para campos/lotes, manteniendo la inmutabilidad del medio y la probabilidad de los registros.

P: ¿Necesita una clave separada para firmar bloques?
R: Sí. Separe las claves de firma de bloque de las claves de cifrado de almacenamiento; almacene en KMS/HSM, con rotación y auditoría.

P: ¿Se puede «anclar» en un espacio público?
R: Opcional. Esto refuerza la verificabilidad y cortará la «reescritura de la historia» dentro del circuito.

• «Encriptación de At Nat»
• «Encriptación In Transit»
• «Gestión de secretos»
• «Administración de claves y rotación»
• «Firma y verificación de solicitudes»