Registros de auditoría de operaciones

(Sección: Operaciones y Gestión)

1) Nombramiento y principios

El registro de auditoría es la fuente principal de la verdad sobre quién, qué, dónde, cuándo y por qué lo hizo, con la capacidad de probar la inmutabilidad y autenticidad de los registros.

• Exhaustividad: se cubren las acciones de personas, servicios y socios externos.
• Inmutabilidad: las entradas no se pueden reescribir/eliminar sin una huella visible.
• Atribución: la acción se relaciona con el sujeto, el rol, el contexto, los artefactos.
• Reproducibilidad: el evento se puede reproducir en un informe/disputa.
• Minimización de PII: solo lo necesario, con mascarilla y fichas.

2) Áreas de cobertura

Acciones personalizadas: inicio de sesión/SSO/MFA, cambio de roles/límites, operaciones PII.
Operaciones privilegiadas: sesiones JIT/PAM, break-glass, consola de administración.
Finanzas: listas de precios/impuestos/FX publicaciones, pagos/pagos, depósitos, cargos/devoluciones.
Configuraciones/versiones: fichflags, migraciones de esquemas, deploy/reversión, claves/certificados.
Integraciones: webhooks, firmas, recibos, llaves idempotency.
Datos: leer/exportar PII, crear/eliminar artefactos, cambiar políticas.

3) Arquitectura e inmutabilidad

Puerta de enlace de ingest con autenticación, cuotas y validación de esquema.
Almacenamiento WORM (immutable buckets/append-only): versión, Retention Lock, Legal Hold.
Criptoquitancias: para eventos críticos, se forma una firma 'receipt _ hash' y DSSE.
Cadenas Merkle: periódicamente se construyen cortes (checkpoint), se publica un hash raíz.
Cadena de custodia: seguimiento del movimiento de artefactos (quién accedió, cuándo, en qué base).
Time Sync: NTP/PTP, etiquetas 'event _ time' e 'ingest _ time', ajuste 'skew'.

4) Esquema de eventos (referencia)

audit_event {
id, event_time, ingest_time, producer, subject {
id, type: human    service    partner, roles[], mfa?, device_posture?
},
action: CREATE    READ    UPDATE    DELETE    EXECUTE    PUBLISH    APPROVE    ROLLBACK,
target { type, id, version?, region?, tenant? },
context { ip/asn, user_agent, env, trace_id, request_id },
policy_version, sod_check: pass    fail, justification?, ticket_ref?,
result: success    deny    error, error_code?,
diff_hash?, payload_hash?, receipt_hash?, dsee_signature?,
pii_classification: none    aggregated    tokenized    sensitive,
retention_class, labels[]
}

Opcional: para finanzas - 'fx _ version/tax _ rule _ version/pricelist _ version'; para webhooks - 'webhook _ id', 'idempotency _ key'.

5) Modelo de datos y zonas

Hot (operación): 7-30 días, consultas rápidas/dashboards.
Warm (OLAP): 6-24 meses, análisis/búsquedas.
Cold (archivo/WORM): hasta 7-10 años (según la regulación).
Clases de retención: 'operacional', 'financiera', 'seguridad', 'legal _ hold'.
Versificación de directivas: todos los eventos están marcados con 'policy _ version'; cambio de directiva - evento de auditoría independiente.

6) Accesos y privacidad

RBAC/ABAC/ReBAC: visibilidad por rol/tenante/región/caso (caso).
Enmascaramiento PII: tokenización de identificadores, salida primaria - sólo a través de jobs aprobados.
Prohibición de eliminación directa: sólo 'tombstone' + Legal Hold; «muelles» explanables con una revista separada.
Auditoría de la auditoría en sí: quién miró/descargó los registros - también es lógico.

7) Calidad, consistencia, tomas

Contratos de datos: esquema estricto y validación lambda en la entrada.
Idempotency & dedoop: '(event_id, productor)'; «seen-cache» + KV.
Corrección de tiempo: marcas de agua (watermarks) para eventos posteriores.
Control de integridad: comparación de contadores de origen y métricas de ingest.

8) Dashboards y consultas

Operativo: acciones privilegiadas, violaciones de SoD, levantamientos de derechos JIT, acceso PII.
Finanzas: publicaciones FX/Tax/PriceList, discrepancias quote↔checkout, firmas clave.
Integraciones: recibos de webhooks, trucos, retraídas, tomas.
Liberaciones/confecciones: quién/cuándo/qué activó/retrocedió, relación con incidentes.
Scripts de búsqueda: 'trace _ id', 'subject. id`, `target. id ', hora/región/tenant,' policy _ version '.
Exportación: descargas por lotes bajo petición con recibo (manifiesto firmado).

9) API y webhooks

'POST/audit/ingest' - recepción de eventos (autenticación, límites, esquema).
'GET/audit/search' - filtros, paginación, límite por resultado.
'GET/audit/trace/{ trace _ id}' es un conjunto de eventos por cadena.
'POST/audit/receipt/verify' - verificación del recibo/DSSE.
Вебхуки: `SoDViolation`, `PrivilegedSession`, `PIIAccess`, `PolicyChanged`, `FinancialArtifactPublished`.

10) SLO/métricas de calidad de auditoría

Ingest Availability: ≥ 99. 95%.
Freshness (operativa): trae ≤ 30 con p95.
Completeness: ≥ 99. El 5% de las fuentes enviaron los datos a la ventana.
Correctness: discrepancia de las cantidades de control ≤ 0. 1%.
Tamper-evidence: 100% de los períodos están certificados por Merkle-roots/firmas.
PII Hygiene: 100% de eventos con clase sensible - con máscara/token.

11) Playbucks e incidentes

Sospecha de sustitución de registros: verificación inmediata de raíces Merkle, comprobación de recibos DSSE, aislamiento de acceso, Legal Hold.
Filtración PII: búsqueda de eventos/exportaciones afectados, auditoría de acceso, notificaciones de DPO/regulador por plazos.
Violación de SoD: bloqueo de la operación, retirada temporal del rol, investigación y ajuste de políticas.
Fallo ingest: búfer, modo de degradación, repetición después de la recuperación, control de duplicados.

12) Extracto legal y cumplimiento

Retención por jurisdicciones: finanzas/impuestos - 5-10 años; seguridad - por política; datos personales - plazo mínimo necesario.
Legal Hold: congelación de la eliminación por caso/solicitud del regulador.
Artefactos informativos: índice de períodos, hashes raíz, lista de firmantes, inventario de fuentes.
Indeleble: criptopodescriptores, timestamping independiente (TSA interno).

13) Especificidad de iGaming/fintech

Pagos/pagos: seguimiento completo de autorizaciones, compensación, denegaciones, chargeback; correlación con recibos bancarios.
RTP/límites: publicaciones de perfiles, cambios observados por RTP y soluciones de límites con firmas y versiones.
Afiliados: recepción de webhooks, dedoop de conversiones, objeciones/escrow - sólo por artefactos firmados.
Listas de precios/impuestos/FX: versión del artefacto en cada pedido; devoluciones - con recibos.

14) RACI

15) Riesgos y anti-patrones

Registros editables sin rastro → no soporte legal.
No hay sincronización de tiempo → las líneas de tiempo no coincidentes.
Exportaciones de sombras sin recibos → fugas/disputas.
Secretos en las guaridas → compromiso.
No hay conexión con SLO/incidentes → «cementerio de datos» sin beneficio.

16) Lista de verificación de implementación

• Identificar áreas de cobertura y policy_version.
• Despliegue ingest con autenticación, esquemas y cuotas.
• Habilitar WORM, Cortes de Merkle, Firmas DSSE, TSA.
• Configurar las retencias por clase y el Legal Hold.
• Introducir RBAC/ABAC/ReBAC y auditoría de acceso a registros.
• Construir dashboards: privilegios, PII, finanzas, lanzamientos/confecciones.
• Habilitar playbucks: tamper, PII-fugas, fallo de ingest, infracción de SoD.
• Pruebe el replay y el dedoup en el kit de prueba.
• Establecer exportaciones con recibos y registro de solicitudes.
• Auditar trimestralmente las métricas de calidad (freshness/completeness/tamper).

17) FAQ

¿Se puede almacenar todo en un CD normal?
Para la operación, sí, pero los registros críticos deben duplicarse en WORM/append-only con firmas y cortes Merkle.

¿Cada lectura de datos necesita ser lógica?
Lectura del PII/Finanzas - obligatorio; el resto es por política y costo.

¿Cómo probar la inmutabilidad?
Hashes raíz, firmas DSSE, TSA independiente y procedimientos de verificación reproducibles.

¿Qué hacer con el «derecho de eliminación» (GDPR)?
Quitar la primaria en los sistemas de procesamiento; en los registros de auditoría: almacene los tokens/hashes sin PII recuperable y mantenga Legal Hold si es necesario.

Resumen: Los registros de auditoría no son «registros en S3», sino un historial de acción criptográficamente probado con una política clara, almacenamiento inmutable, acceso controlado y disponibilidad para la revisión de disputas/regulaciones. Construya contratos de ingest, firme eventos críticos, mantenga los cortes de Merkle y los dashboards, y tendrá una sólida base de confianza, seguridad y cumplimiento.