Seguridad de datos y cifrado

1) Por qué es crítico en iGaming

La plataforma iGaming funciona con PII, datos financieros, sesiones de juego, características de comportamiento, señales antifraude y modelos ML. La filtración o sustitución de estos datos conlleva multas, bloqueos de mercados, daños reputacionales y retroceso de métricas (GGR, retención).

• Confidencialidad (acceso mínimo a PII/finanzas).
• Integridad (protección contra sustitución y datos «sucios»).
• Disponibilidad (SLO de lectura/escritura, planes DR).
• Trazabilidad (quién miró/cambió qué y cuándo).

2) Modelo de amenazas (abreviado)

Externo: compromiso API/integraciones, MITM, ransomware, proveedores (cadena de suministro).
Internos: derechos redundantes, descargas «en la sombra», registros tóxicos, errores de configuración.
Datos y ML: sustitución de eventos/fich, inversión de modelos, inferencia de membership.
Jurisdicciones: restricciones transfronterizas, requisitos locales de almacenamiento y eliminación.

3) Encriptación en tránsito (En tránsito)

TLS 1. 2+/1. 3 solamente, desactivar los cifrados débiles; preferencia TLS 1. 3.
mTLS para S2S (yadro↔dataleyk↔katalog↔fichestor↔provaydery).
PFS (ECDHE) - obligatorio.
Certificate pinning en clientes móviles/de escritorio e integraciones críticas.
API-firma de solicitudes a proveedores/PSP (HMAC-SHA-256) y control de tiempo/repeticiones (nonce, llaves idempotency).

4) Encriptación en almacenamiento (At Nat)

• Encriptación de volúmenes/objetos en la nube/K8s (transparente, pero no protege contra la lectura «legítima» por un servicio comprometido).

• TDE (Transparent Data Encryption) es la capa base.
• AEAD de nivel FLE/Column para campos calientes (correo electrónico, teléfono, tokens PAN): AES-256-GCM o ChaCha20-Poly1305.
• Llaves de nivel de fila para registros especialmente sensibles (VIP, pagos).

• Envelope encryption (KMS-managed DEK, rotación), control de acceso a claves.
• Firma de manifiestos y control de integridad (hash/checksum, Merkle-trees para paquetes).

5) Elección criptográfica (práctica)

Cifrado simétrico: AES-GCM/ChaCha20-Poly1305 (AEAD) con nonce/IV únicos; almacenar 'ciphertext + auth tag'.
Hashing: SHA-256/512 para la integridad; para contraseñas: Argon2id (o bcrypt/scrypt) con parametrización y sal.
Firma: Ed25519/ECDSA P-256 para artefactos/paquetes; HMAC-SHA-256 para la firma API.
Disposiciones clave: ECDH (P-256/Curve25519).

6) Administración de claves (KMS/HSM)

KMS + HSM para generar/almacenar claves maestras; envelope encryption для DEK.
Rotación: regular (calendario) y por evento (incidente). Soporte de lectura dual durante el período de migración.
Separación de tareas (SoD), M-of-N para «break-glass», registro de todas las operaciones.
Split-key/Shamir para secretos especialmente críticos (por ejemplo, la firma pei-out).
Claves geo-scoping: diferentes claves para regiones/marcas.

7) Gestión secreta

Centralizado Secrets Manager (no en las variables del entorno del repositorio).
Secretos JIT (de vida corta), auto-rotación y revisión.
Sidecar/CSI para llevar secretos a las pistas de K8s.
Prohibición de registros/tracks con secretos; detectores de fugas en CI.

8) Integridad y confianza en los datos

Firma de eventos/paquetes (por el productor) y verificación (por el consumer).
Event-idempotent y llaves únicas para anti-replay.
Control de esquemas (Registro de Schema, compatibilidad), Contratos de datos como «límites de confianza».
Almacenamiento de información WORM para registros e informes críticos.

9) Tokenización, enmascaramiento y DLP

Tokenización PII/Finanzas (vault/FPE/DET) - El uso de tokens en logs, vitrinas, fichas.
Enmascaramiento en UI y descargas; Revisión del PII en los textos de tickets/chats (saneamiento NLP).
Políticas DLP: plantillas prohibidas (PAN, IBAN, pasaporte), unidad de descarga, inspección de correo/FTP/S3.

10) Acceso y auditoría

RBAC/ABAC: roles + atributos (país, marca, entorno); Los menos derechos.
Accesos JIT con revocación automática; Cada N días es un rugido de derechos.
mTLS + IP allowlist para paneles de administración y end-points críticos.
Los registros de auditoría son inmutables (WORM/append-only), correlación con SIEM.
Break-glass: roles/claves individuales, post-mortem obligatorio.

11) Copia de seguridad y DR

3-2-1: 3 copias, 2 medios/HSD diferentes, 1 offline/aislado (air-gapped).
Encriptación de backups con sus propias claves (no el proveedor), prueba de recuperación programada.
RPO/RTO para dominios (pagos <X min., eventos de juegos <Y min.).
Replicación regional con aislamiento criptográfico de claves y redes.

12) Privacidad y cumplimiento

Clasificación de datos (Público/Interno/Confidencial/Restringido).
Minimización y ligamento objetivo (KYC, AML, RG, reporting).
Políticas de retención y eliminación: gráficos, Legal Hold, DSAR; cripto-borrado.
Transfronterez: Geosoning y casos de almacenamiento local.

13) Observabilidad de la seguridad de los datos

Zero-PII en logs (métricas de recubrimiento), alertas cuando se activa DLP.
Salud clave: rotaciones, fallos de cifrado, anomalías de KMS/HSM.
Integrity SLI: proporción de paquetes/eventos firmados y checks de señalización verificados.
Latency SLO: p95 tokenización/desintoxicación, cifrado/descifrado.
Access SLO: proporción de solicitudes JIT procesadas en el tiempo objetivo.

14) Herramientas y capas tecnológicas (categorías)

KMS/HSM: claves maestras, envelope, firma.
Secrets Manager: secretos JIT, rotación.
Terminal TLS/mTLS-mesh: ingress/service mesh.
DLP/Masking: inspección, saneamiento.
Schema Registry/Contracts: interoperabilidad, prohibiciones PII.
SIEM/SOAR: correlación de registros de auditoría, reacciones automáticas.
Backup/DR: orquestación de respaldo, prueba de recuperación.

15) Plantillas (listas para usar)

15. 1 Política de cifrado (fragmento)

Algoritmos: AES-256-GCM/ChaCha20-Poly1305; firma Ed25519; hash SHA-256.
Claves: generación en HSM; rotación de 90 días o en caso de incidente; geo-scoped.
Acceso: sólo cuentas de servicio a través de mTLS; Tokens JIT.
Registros: modo WORM; Almacenamiento ≥ N meses.
Excepciones: por decisión CISO/DPO, con acta de justificación.

15. 2 Pasaporte del conjunto de datos protegido

Dominio/tabla: pagos. transactions

Clase: Restringido (finanzas)

Cifrado: FLE (AES-GCM) por los campos 'card _ token', 'iban', 'payer _ id'

Claves: DEK per-field (envelope KMS)

Tokenización: vault tokens para PAN/phone/email

Acceso: ABAC (país, papel de "Payments-Ops'), JIT

Registros: firma de paquetes, WORM, retén de 2 años

15. 3 Lista de comprobación de la versión de datos

• El contrato prohíbe el PII en zonas «grises», los campos marcados con 'pii/tokenized'
• TLS 1. 3 y mTLS en S2S habilitado
• FLE/TDE configurados, claves en KMS/HSM, rotación activa
• Las reglas de DLP y el enmascaramiento de registros pasan las pruebas
• Los backups se cifran, prueba de recuperación verificada
• SIEM recibe registros de auditoría; alertas al intento de desintoxicación fuera de la «zona limpia»

16) Hoja de ruta para la implementación

0-30 días (MVP)

1. Clasificación de datos y mapa de flujos (PII/finanzas/ML).
2. Habilitar TLS 1. 3/mTLS para S2S; Prohibición de las cuentas cifradas débiles.
3. Elevar KMS/HSM; traducir las claves al esquema envelope.
4. Habilitar TDE y FLE para 3 dominios críticos (Pagos/KYC/RG).
5. Enmascaramiento de registros y reglas DLP básicas; Certificación Zero-PII.

30-90 días

1. Tokenización PII/Finanzas (vault/FPE); Acceso JIT y auditoría de desintoxicación.
2. Firma de eventos y cheques integrales en ingestion/ETL.
3. Rotación regular de llaves, split-key para pagos VIP.
4. Backups: 3-2-1, copia offline, día de restore mensual.
5. SLO Dashboards (Zero-PII, Integrity, Key-Health, Latency).

3-6 meses

1. Geo-scoped claves/datos por jurisdicciones; políticas transfronterizas.
2. Almacenamiento de información WORM para auditoría/informes; SOAR playbucks.
3. Cobertura completa con tokens analíticos/ML; Prohibición de PII en las vitrinas.
4. Ejercicios trimestrales: incidente-simulación (ransomware, key leak, data poisoning).
5. Revertición anual y auditoría externa.

17) RACI (ejemplo)

Políticas y control: CISO/CDO (A), DPO (C), SecOps (R), Domain Owners (C).
Ключи/KMS/HSM: Security/Platform (R), CTO (A), Audit (C).
Tokenización/DLP: Plataforma de datos (R), DPO (A), Dominios (C).
Backups/DR: SRE (R), CIO (A).
Monitoreo/incidentes: SecOps (R), SOAR (R), Legal/PR (C).

18) Métricas y SLO de seguridad de datos

Cero-PII en los logs: ≥ 99. 99% de los eventos.
Integrity-pass: ≥ 99. El 9% de los paquetes firmados se validaron correctamente.
Key-hygiene: 100% de rotación oportuna, 0 claves caducadas.
Detokenization SLO: p95 ≤ X min., sólo para solicitudes con justificación.
Backup restore-rate: prueba de recuperación exitosa ≥ 99%.
Revisión de acceso: cerrado ≥ 95% de los derechos superfluos de auditoría trimestral.
Incident MTTR: ≤ el umbral de destino para los tipos de P1/P2.

19) Anti-patrones

TDE «por el bien de la marca» sin FLE y la tokenización de campos sensibles.
Almacenar secretos en variables de entorno/repositorios.
Claves compartidas/pepper para todos los dominios/regiones.
Registros con PII/secretos; dumps de bases prod sin cifrado.
No hay firmas/comprobaciones de integridad en los pipelines.
Administración única en todos los KMS/HSM; no hay SoD y M-of-N.

20) Incidente de playbook (breve)

1. Detalle: SIEM/DLP/auditoría-registro/queja.
2. Estabilización: aislamiento del segmento, retirada de claves/secretos, restos de flujos problemáticos.
3. Evaluación: lo que se filtró/distorsionó, escala, jurisdicciones afectadas.
4. Comunicaciones: Legal/PR/regulador (donde se requiere), socios/jugadores.
5. Mitigaciones: rotaciones, retro-tokenización/cifrado, backfill/verificación de integridad.
6. Post-mortem: razones, lecciones, actualización de políticas/umbrales/pruebas.

21) Secciones relacionadas

Tokenización de datos, Origen y ruta de datos, Ética y privacidad, ML confidencial, Aprendizaje federado, Reducción de sesgos, DSAR/Legal Hold, Observabilidad de datos.

Resultado

La protección de datos confiable es una arquitectura en niveles + disciplina de procesos: criptografía moderna, KMS/HSM riguroso, tokenización, integridad firmada, registros limpios, accesos gestionados y backups verificables. En iGaming, se ganan plataformas donde los datos están protegidos de forma predeterminada y los cambios son transparentes, reproducibles y conformes.