Política de retención de registros y eventos

1) Objetivo y alcance

Objetivo: proporcionar almacenamiento legal, seguro y económico de registros/eventos, apoyar investigaciones, auditorías, informes AML/KYC y sostenibilidad de la plataforma.

Cobertura: todos los entornos (prod/stage/dev), aplicaciones y microservicios, antifraude y pagos, CUS/sanciones, RG, infraestructura (K8s/cloud/CDN/WAF), socios/vendedores (PSP, KYC, antifraude, analítica)

2) Clases de registro y composición mínima de campos

1. Seguridad (SecOps/Identity): autenticación, señales ATO/antifraude, cambios de roles y políticas, acceso PII.

Поля: `actor`, `subject`, `action`, `result`, `ip`, `device`, `geo`, `risk_score`, `trace_id`.

2. Transacciones/pagos: depósitos/retiros, chargebacks, reglas antifraude.

Поля: `tx_id`, `amount`, `currency`, `psp`, `status`, `rule_hits[]`, `evidence_ref`.
3. CUS/sanciones/RR: iniciaciones, resultados, proveedor/versión de listas, soluciones (verdadero/falso positivo).
4. Operaciones/SRE: métricas de SLO, lanzamientos, autocat, incidentes, alertas.
5. Marketing/CRM (opcional): eventos de consentimiento/baja, campañas (sin PII innecesario).
6. Auditoría de acceso a datos: lectura/exportación/eliminación de conjuntos con PII; enlaces a casos DSAR/AML.

3) Tiempos de almacenamiento y niveles de almacenamiento (Hot/Warm/Cold/WORM)

4) Sincronización de tiempo y rastreabilidad

Base única temporal: NTP/Chrony, almacenar 'ts _ utc' (UTC) + 'ts _ local' (para informar).
Correlación: en cada registro incluye 'trace _ id '/' span _ id' y 'source _ service'.
Zonas horarias: informes/exportaciones - con indicación explícita de TZ.

5) Acceso, cifrado y separación de funciones

Encriptación: at nat (KMS; rotación de llaves al menos 90 días para espacios secretos) y en tránsito (TLS 1. 2+).
RBAC/ABAC: acceso al mínimo; roles individuales para leer registros de auditoría.
Break-glass: acceso temporal con autorización multifactorial y cierre automático.
Segmentación: registros con PII/finanzas - índices/depósitos separados, claves separadas.
Registros de acceso a logs: todas las lecturas/exportaciones se registran y rugen.

6) Privacidad y enmascaramiento

Está estrictamente prohibido la lógica: contraseñas, tokens, PAN (en su totalidad), CVV/CVC, números completos de documentos, datos biométricos «crudos».
Enmascaramiento predeterminado: email → 'p @ domain. com`; teléfono → '+ XXX123'; IBAN/PAN → tokens/últimos 4 dígitos.
Pseudonimización: reemplaza 'user _ id' por un token persistente en los logotipos analíticos/de marketing.
Cookies/SDK: lógica sólo los identificadores técnicos con consentimiento (CMP) y sin pegamento con PII, a menos que haya una base legal.
Compatibilidad DSAR: almacena la referencia al origen del conjunto y la capacidad de extracción/eliminación selectiva.

7) Calidad de datos (Calidad de datos) y formato

Diagrama-como-código: diagramas/protocolos de eventos JSON centralizados, versionados.
Validaciones: not null/rangos/regex; eventos rechazados - en una cola quarantina con una etiqueta de causa.
Deduplicación: por '(trace_id, ts, source)'; niveles de idempotencia para retraídas.
Enriquecimiento: estrictamente determinista; atributos geo/device - especificando la versión de los diccionarios.

8) Arquitectura y niveles de almacenamiento

Hot: repositorios indexables/clústeres de búsqueda (investigaciones operativas, SIEM).
Warm: almacenamiento de objetos con índices de acceso/acceso acelerado.
Cold: almacenamiento de objetos/archiving (glacier-class/análogo), consultas vía batch.
WORM/Legal Hold: baquetas/políticas de retén y «retención legal» inmutables con imposibilidad de eliminación/modificación antes de la expiración del plazo.

9) Eliminación, Archiving y Legal Hold (SOP)

1. El planificador diario calcula los candidatos por plazos.
2. Verificación de incidentes activos/investigaciones/Legal Hold.
3. Archiving: transfiere a Cold/WORM si es necesario.
4. Eliminación: limpieza segura + registro ('dataset', 'range', 'actor', 'hash _ before/after').
5. Informe en Compliance/Data una vez completado el batch.

10) Integración con cumplimiento (GDPR/AML/PCI/ISO)

GDPR: minimización, objetivos/bases en RoPA; Disponibilidad DSAR; Las notificaciones de 72 horas se basan en los registros de auditoría.
AML: almacenamiento de registros de inspecciones sancionadoras, links AMB/SAR; períodos de 5 a 10 años (por país).
PCI DSS (si corresponde): prohibición de datos de autenticación sensibles; segregación de los registros perimetrales de pago.
ISO 27001/ISMS: política de lógica como documento vinculante; auditorías y pruebas anuales.

11) Vendedores y subprocesadores

DPA/SLA: especificar tiempos de almacenamiento, geografía, TOMs, formato de exportación, WORM/Legal Hold, tiempo de reacción al incidente.
Auditoría: cuestionarios, registros selectivos de acceso a PII, prueba de incidente/notificación.
Offboarding: eliminación/devolución de registros, acto de cierre, confirmación de destrucción de copias/backups.

12) Monitoreo y alertas

KRIs: crecimiento de fallas de validación> X%, lags de ingestión> Y, fallas ETL <99%, intentos de acceso fuera de la ventana.
KPI: cobertura por lógica ≥ 95% de los servicios; MTTD falla la paipline ≤ 15 min; Porcentaje de solicitudes a Hot completadas ≤ 2 segundos - ≥ 95%.
SOAR: tickets automáticos cuando se viola la retransmisión/accesos/enmascaramiento.

13) RACI

14) Exportación y presentación de informes

Listas blancas de destinatarios y formatos (CSV/Parquet/JSON) con despersonalización predeterminada.
Firma/hash de cada archivo, registro de descargas.
Plantillas de informes regulatorios: resúmenes de sanciones/RER, KYC, alertas AML, accesos PII, incidentes.

15) Requisitos de desarrollo y operación

Lógica con sentido: acciones/soluciones clave, no todo el tráfico.
Estándares de nivel: 'DEBUG' prohibido en prod; 'INFO' para eventos empresariales; 'WARN/ERROR' para anomalías.
Redaction-middleware: una sola capa de enmascaramiento en gateways/SDK.
Entornos de prueba: datos sintéticos o pseudonimización; prohibición de copias de prod-logs en dev.
Lanzamientos: Lista de comprobación de lógica/enmascaramiento en AMB; banderas de función para la lógica extendida.

16) Hojas de cheques

16. 1 Control semanal

• Sincronización de tiempo sin deriva
• Errores de ingestión
• No hay PII/secretos directos en los samples
• Los accesos/roles están actualizados
• El éxito de ETL ≥ 99%

16. 2 Auditoría mensual

• Comprobación de retransmisión/desinstalación
• Muestra aleatoria de exportaciones (firma/hash aprox)
• Revue de vendedores (registros de accesos, incidentes)
• Actualización de diagramas/guías

16. 3 Antes de la eliminación/archivo

• No Legal Hold/Incidente
• Exportación de artefactos relacionados (si es necesario)
• Protocolo de destrucción

17) Incidentes de lógica (playbook rápido)

PII/secretos detectados en los logs → activar inmediatamente las reglas de redacción, restringir el acceso, iniciar la limpieza/rotación de claves, evaluar la escala (DPO/Legal), y notificaciones si es necesario.
Fallas en la pipeline de los registros → cambio a búfer, alerta SRE, ingeniería restart, post-mortem.

18) Hoja de ruta para la implementación

Semanas 1-2: inventario de fuentes, negociación de plazos, matriz básica de retenche, diagrama-como-código.
Semanas 3-4: introducción de enmascaramiento/revisión, separación de índices con PII, identificadores NTP/trace, WORM para conjuntos críticos.
Mes 2: automatización de eliminación/archivado, KRIs/KPIs y alertas, SOARs.
Mes 3 +: auditoría de vendedores, optimización de valor (tiering), rugidos trimestrales de plazos y requerimientos de las jurisdicciones.

TL; DR

Política de registro único = matriz de tiempo clara + enmascaramiento y cifrado + RBAC y auditoría de acceso + WORM/Legal Hold + calidad y sincronización de tiempo. Esto reduce los riesgos (GDPR/AML/PCI), abarata el almacenamiento y acelera las investigaciones.