Registros de auditoría y rastros de acceso

1) Propósito y ámbito de aplicación

Objetivo: garantizar la probabilidad de las acciones de los usuarios/servicios, transparencia en las investigaciones, cumplimiento de reguladores y estándares internos (GDPR/AML, contratos con proveedores PSP/KYC, ISO/PCI cuando sea aplicable).
Cobertura: todos los sistemas prod, servicios de plataformas (cuentas, pagos, antifraude, CUS/sanciones, RG), paneles de administración, pasarelas API, DWH/BI, infraestructura (K8s/cloud), integraciones con vendedores.

2) Qué lógica (clases de eventos)

1. Identificación y acceso: inicio de sesión/logout, MFA, cambio de contraseñas/claves, SSO, acceso «break-glass».
2. Acciones administrativas: cambios de roles/derechos, configuraciones, reglas antifraude/sanciones, banderas de fichas.
3. Operaciones con PII/Findans: lectura/exportación/eliminación, descarga, acceso a KYC, visualización de perfiles VIP.
4. Transacciones y dinero: salidas de efectivo/depósitos, cancelaciones, devoluciones, soluciones de charjbacks.
5. Cumplimiento/AML/KYC: resultados del cribado (sanciones/PEP/Adverse Media), decisiones (TP/FP), EDD/AMB/SAR.
6. Incidentes y seguridad: escaladas, cambios en las reglas WAF/IDS, aislamiento de servicios, rotación de secretos.
7. Integraciones/proveedores: llamadas API, errores, temporizaciones, exportaciones, confirmaciones de eliminación/devolución de datos.

3) Campos de evento obligatorios (mínimo)

`event_id` (UUID), `ts_utc`, `ts_local`, `source_service`, `trace_id`/`span_id`

'actor _ type' (usuario/servicio/vendedor), 'actor _ id' (ID persistente), 'actor _ org' (si B2B)

`subject_type` (account/tx/document/dataset), `subject_id`

`action` (e. g., `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `WITHDRAWAL_APPROVE`)

`result` (success/deny/error) и `reason`/`error_code`

'ip', 'device _ fingerprint', 'geo' (país/región), 'auth _ context' (MFA/SSO)

'fields _ accessed '/' scope' (cuando se trabaja con PII/finded) - enmascarado

'purpose '/' ticket _ id' (base: DSAR, incidente, solicitud del regulador, tarea operativa)

4) Inmutabilidad y probabilidad

Almacenamiento WORM para copia «dorada» (immutable buckets/políticas de retención).
Criptopode/hash chain: firma periódica de paquetes de eventos y/o construcción de una cadena de hash (hash chaining) para identificar modificaciones.
Registro de cambios de esquemas/reglas: versionamos el esquema y la política de lógica; cualquier revisión se realiza a través de CAF.
Almacenamiento de dos circuitos: índice en línea (búsqueda) + archivo/immutabilidad.

5) Sincronización de tiempo y seguimiento

Un único NTP/Chrony en todos los entornos; en los logs - 'ts _ utc' como fuente de la verdad.
En cada registro, 'trace _ id '/' span _ id' para el rastreo de consultas de extremo a extremo (correlación entre servicios, vendedores y frente).

6) Privacidad y secretos

Prohibido: contraseñas, fichas completas PAN/CSC, números completos de documentos, biometría «cruda».
Enmascaramiento predeterminado: e-mail/teléfono/IBAN/PAN → tokens/visualización parcial.
Pseudonimización: 'user _ id' → un token estable en analítica; Referencia a ID real: sólo en un bucle protegido.
Compatibilidad con DSAR: posibilidad de extracción selectiva de registros por sujeto sin revelar PII extraños.

7) Tiempos de almacenamiento y niveles (Retench)

8) Acceso y control (RBAC/ABAC)

Los roles de lectura de registros de auditoría están separados de los roles de administración.
Acceso MFA y Just-in-Time (break-glass) con autocontrol/lógica de razones.
Política de «mínimo»: acceso a campos PII/findans sólo por necesidad y con fijación 'purpose'.
Exportaciones/descargas: listas blancas de destinatarios y formatos; firma/hash obligatorio, registro de descargas.

9) Integración con SIEM/SOAR/ETL

El flujo de eventos audit llega al SIEM para las correlaciones (e. g., entrada masiva 'READ _ PII' + desde el nuevo dispositivo).
SOAR playbooks: tickets automáticos cuando se violan políticas (sin 'purpose', volumen anormal, acceso fuera de la ventana).
ETL/DWH: vitrinas 'audit _ access',' pii _ exports', 'admin _ changes' con control de calidad y versionabilidad de circuitos.

10) Calidad de los datos y validadores

Esquemas como código (JSON/Protobuf/Avro): campos obligatorios, tipos, diccionarios; Validadores CI.
Rechace y quarantine-cola para eventos con errores de esquema; métricas de matrimonio.
Deduplicación/idempotencia por '(event_id, trace_id, ts)'; Control de reenvío.

11) RACI

12) SOP: Investigación de acceso a datos

1. Desencadenante: alerta SIEM (anormal 'READ _ PII '/exportación), queja, señal del vendedor.
2. Recolección de artefactos: descarga de eventos por 'actor _ id '/' subject _ id '/' trace _ id', registro 'purpose', logs relacionados (WAF/idP).
3. Comprobación de legalidad: existencia de una base (DSAR/incidente/tarea de servicio), negociación, ventanas de acceso.
4. Evaluación de impacto: volumen/categorías de PII, jurisdicciones, riesgo a las entidades.
5. Solución: incidente-puente (bajo Alto/Crítico), contenido (revocación de accesos, rotación de claves).
6. Informe y CAPA: causas, políticas violadas, medidas (enmascaramiento, capacitación, cambios en RBAC), plazos.

13) SOP: Exportación de datos (regulador/socio/DSAR)

1. Solicitud → verificación de base e identidad (para DSAR) → formación de solicitud en DWH.
2. Despersonalización/minimización predeterminada; la inclusión de PII sólo con fundamento jurídico.
3. Generación de descarga (CSV/JSON/Parquet) → firma/hash → registro de descarga (quién/cuándo/quién/base).
4. Transmisión a través de un canal aprobado (sFTP/Secure link); el período de retención de la copia es por política.
5. Control posterior: confirmación de recepción, eliminación de archivos temporales.

14) Métricas y KRIs/KPIs

Cobertura: porcentaje de sistemas críticos que envían eventos de auditoría ≥ 95%.
Errores DQ: eventos rechazados por el validador, ≤ 0. 5% del flujo.
MTTD pérdida de flujo: ≤ 15 min (alerta en silencio).
Accesos anormales sin 'purpose': = 0 (KRI).
Tiempo de respuesta a la investigación: mediana ≤ 4 h, P95 ≤ 24 h.
Exportaciones con firma/hash: 100%.
Cumplimiento de retén: eliminación/archivos a tiempo ≥ 99%.

15) Requisitos para vendedores y subprocesadores

DPA/SLA: descripción de los registros de auditoría (esquemas, plazos, geografía, formato de exportación), WORM/immutabilidad, notificaciones de incidentes SLA.
Acceso al vendedor: cuentas de servicio con nombre, registros de sus acciones, capacidad de auditoría selectiva.
Offboarding: revocación de claves, exportación/eliminación de registros, acto de cierre, confirmación de destrucción de backups.

16) Seguridad y protección contra la manipulación

División de funciones: administrador de origen ≠ administrador de almacenamiento ≠ auditor.
Firma de agentes/recopiladores, mTLS entre componentes.
Controles anti-tamper: comparación de hashes, controles regulares de integridad, alertas de discrepancias.
Replicación geo de copias WORM y pruebas de recuperación regulares.

17) Errores estándar y anti-patrones

La lógica de valores sensibles (PAN/secretos) → la activación inmediata de redaction-middleware.
Falta 'purpose '/' ticket _ id' al acceder a la PII.
Descarga local «al escritorio» y reenvío por correo electrónico.
La ausencia de un único esquema y validación → campos «mudos», imposibilidad de correlación.
Una sola super-cuenta sin conexión a una persona o servicio.

18) Hojas de cheques

18. 1 Política de inicio/rugido

• Se han aprobado diagramas y diccionarios; campos obligatorios habilitados
• El enmascaramiento y las prohibiciones de secretos están habilitados
• Configurado NTP, 'trace _ id' en todas partes
• Hot/Warm/Cold/WORM capas establecidas
• RBAC/ABAC y break-glass decorados
• SIEM/SOAR integrado, alertas probadas

18. 2 Auditoría mensual

• Muestra de exportaciones: las firmas/registros son correctos
• Verificación de retransmisiones/desinstalaciones/Legal Hold
• métricas DQ son normales, análisis quarantine
• Los registros vendedores están disponibles/completos

19) Hoja de ruta para la aplicación

Semanas 1-2: inventario de sistemas, negociación de esquemas y campos obligatorios, configuración de tiempo y seguimiento.
Semanas 3-4: activación del enmascaramiento, capa WORM, integración con SIEM/SOAR, lanzamiento de registros de exportación.
Mes 2: automatización de validadores/alertas, playbucks de investigación, entrenamiento de equipos.
Mes 3 +: auditorías periódicas, pruebas de integridad de estrés, optimización de valor (tiering), revisiones de vendedores/contratos.

TL; DR

Registros de auditoría fuertes = eventos completos y estructurados + immutabilidad (WORM) y firmas + enmascaramiento PII + acceso rígido y registro de descarga + integración con SIEM/SOAR. Esto acelera las investigaciones, reduce los riesgos y hace probable el cumplimiento.