Control de acceso a datos

1) Por qué es iGaming

Riesgo y regulación: PII/finanzas, transfronterizos, requisitos RG/AML.
Velocidad y confianza: análisis de autoservicio seguro y ML sin «manuales».
Auditoría y responsabilidad: «quién vio qué y por qué», la probabilidad del principio de derechos mínimos.

2) Principios básicos

1. Least Privilege - sólo lo necesario y por el tiempo adecuado.
2. Segregation of Duties (SoD) es un desarrollador ≠ aprueba el acceso; analista ≠ propietario de datos.
3. Just-in-Time (JIT) - derechos temporales, revocables automáticamente.
4. Defense in Depth - Protección en niveles: red → servicio → tabla → columna → fila → celda.
5. Policy-as-Code - Accesos y máscaras en código/repositorio, rugiendo a través de PR.
6. Provence-aware: las soluciones se basan en el catálogo, la línea, la clasificación y los contratos.

3) Clasificación de datos

Clases: Público/Interno/Confidencial/Restringido (PII/Finanzas).
Etiquetas en diagramas y catálogo: 'pii', 'financial', 'tokenized', 'masking', 'rle' (row-level), 'cle' (column-level), 'geo = EU/TR/...', 'tenant'.

• Restricted: tokens/máscaras en todas partes; desintoxicación sólo en la «zona limpia» según la solicitud.
• Confidential: acceso con máscaras predeterminadas; retiro de máscaras - a través de la justificación y JIT.
• Internal/Public: por roles de dominio, sin PII.

4) Modelos de autorización

RBAC (rol-bazir.) : inicio rápido, directorios de roles ("Marketing-Analyst", "Risk-Ops').
ABAC (atributo-bazir.) : país, marca, entorno (prod/stage), proyecto, propósito del tratamiento, tiempo, nivel de riesgo.
ReBAC (por relación): «propietario del conjunto», «steward del dominio», «revueuer».
Hybrid: RBAC como marco, ABAC especifica las fronteras.

5) Granularidad de acceso

Red/enlace: mTLS, allow-list, enlaces privados.
Servicio/clúster: roles IAM, cuenta de servicio con un mínimo de privilegios.
Almacenes: directorios/esquemas/tablas (GRANT), seguridad de nivel de fila (RLS), seguridad de nivel de columna (CLS).
Enmascaramiento/tokenización: máscaras dinámicas en SQL/BI; tokens en lugar de PII.
Fichastor/ML: acceso sólo a agregados/fichas permitidas; directiva de signos (allow/deny).
Archivos/objetos: enlaces pre-firmados con TTL, cifrado y política de descarga.

6) Patrones para dominios clave

KYC/AML: CLS (sólo tokens visibles), RLS por país del operador; desintoxicación - DPO/Legal por JIT.
Pagos: Restricted, FLE + tokens, acceso a Risk/Payments-Ops a través de JIT; descargas auditadas.
Eventos de juego: Internal/Confidential, RLS por marca/región/tenant, CLS para user_id.
Juego responsable: acceso del equipo RG a las unidades; casos individuales - a solicitud.
BI/ML: vitrinas «doradas» sin PII; ML es una lista de fiches permitidos, una revista de excusas para los polémicos.

7) Procedimientos de acceso

7. 1 Solicitud → negociación → provisiones

Formulario de solicitud: propósito, alcance, fecha límite, función, atributos ABAC, propietario del conjunto.
Verificación automática: ¿clase de datos, SoD, aprendizaje completado? ¿Conflicto de intereses?
RACI: Owner (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и break-glass

JIT: 15 min/2 horas/1 día con auto-retiro; Renovación - por una nueva solicitud.
Break-glass: para incidentes; roles/claves individuales, auditoría reforzada, post-mortem es obligatorio.

7. 3 Rugidos regulares

Revisión trimestral de acceso: los propietarios de dominios confirman roles/atributos.
Desactivación automática de accesos «olvidados» (sin usar 30/60 días).

8) Mecanismos técnicos

Catalog & Contracts: la fuente de la verdad sobre los propietarios, las clases, las máscaras.
Motor de políticas: ORA/equivalente para políticas ABAC/Row/Column.
Masking de datos: máscaras dinámicas en DWH/BI; máscara de seguridad de formato para teléfonos/correo electrónico.
Tokenization: vault/FPE; desintoxicación sólo en la «zona limpia».
Secrets & PAM: administrador secreto, sesiones JIT, grabación de pantallas para accesos de administración.
Audit & SIEM: Registros inmutables (WORM), correlación de eventos de acceso con sesiones y descargas.
Aisladores geo/tenant: fiz/partición lógica (esquemas, directorios, clústeres, claves de cifrado).

9) Consent & DSAR

Los accesos tienen en cuenta el consentimiento del jugador (marketing = off → ocultar los atributos de marketing).
botones DSAR: buscar/descargar/eliminar por token; registro de toda la operación; Se tiene en cuenta a Legal Hold.

10) Monitoreo y SLO

Acceso SLO: p95 tiempo de emisión de acceso JIT (por ejemplo, ≤ 30 min).
Zero-PII in logs: 100% de eventos sin PII.
Anomaly rate: alertas en ráfagas SELECT o atípicas JOIN a Restricted.
Review Coverage: ≥ 95% de los roles rugen a tiempo.
Mask Hit-Rate: porcentaje de consultas donde se activó la máscara/token.
Detokenization MTTR: tiempo medio de tramitación de una solicitud válida.

11) Plantillas

11. 1 Política de acceso (fragmento)

Principio: least privilege + SoD + JIT.
Roles: directorio de roles con descripciones de tareas/escaparates.
Atributos ABAC: 'country', 'brand', 'env', 'purpose', 'retention'.
Máscaras/tokens: de forma predeterminada, están activos en Confidential/Restricted.
Rugir: trimestralmente; Revocación automática de accesos «olvidados».
Infracciones: bloqueo, investigación, entrenamiento.

11. 2 Formulario de solicitud

Quién: FIO/equipo/gerente.
Qué: conjunto/tabla/escaparate/fichas.
Por qué: objetivo, resultado esperado/métricas.
Cuánto tiempo: plazo/horario.
Clase de datos: (se rellena automáticamente desde el directorio).
Firmas: Owner/Steward, DPO o Sec (si está restringido).

11. 3 Directorio de roles (ejemplo)

Marketing-Análisis: escaparates de marketing Internal/Confidential; sin desintoxicación; RLS por marca.
Risk-Ops: Pagos restringidos con máscaras; JIT para desintoxicación; exportar sólo a través de patrones «blancos».
RG-Team: unidades RG, acceso a los casos a solicitud.
DS/ML: fichastor (allow-list fich), sandbox sin PII.

12) Hoja de ruta para la implementación

0-30 días (MVP)

1. Clasificación de datos y etiquetas en esquemas.
2. Directorio de roles + atributos ABAC básicos (país/marca/env).
3. Enmascaramiento/tokenización predeterminados para Confidential/Restricted.
4. Proceso JIT y registro de auditoría; reglamento break-glass.
5. RLS/CLS para pagos, KYC, eventos de juegos; prohibición de 'SELECT' para Restricted.

30-90 días

1. Policy-as-Code en CI (linter de consultas, bloques en caso de infracciones).
2. Integración con Consent/DSAR; informes de acceso SLO.
3. Revisión trimestral de acceso; desactivaciones automáticas.
4. PAM para accesos de administración; Grabación de sesiones; una caja de tiempo.

3-6 meses

1. Aislamiento geo/tenant, claves de encriptación separadas por jurisdicciones.
2. Recomendaciones de rol automático basadas en consultas reales (usage-based).
3. Análisis de comportamiento de acceso (anti-anomalías), SOAR-playbucks.
4. Certificación de procesos y auditoría externa.

13) Anti-patrones

«Superusuario» para todos - sin SoD y JIT.
Descomponer los datos a través de archivos/capturas de pantalla fuera de los canales controlados.
RLS/CLS sólo «en papel»: las máscaras están apagadas en BI.
No hay rugido de derechos y auto-revocación; accesos «eternos».
El directorio/los contratos no se actualizan: las reglas de acceso están obsoletas.
Desintoxicación en aplicaciones «por conveniencia» sin auditoría.

14) RACI (ejemplo)

Políticas/arquitectura: CDO/CISO (A), DPO (C), SecOps (R), Data Platform (R).
Emisión de accesos: IAM/IT (R), Owners (A/R), Stewards (C), Managers (I).
Auditoría/rugido: Owners (R), DPO/Sec (A), Auditoría interna (C).
Incidentes: SecOps (R), Legal/PR (C), Dominios (R).

15) Secciones relacionadas

Gestión de datos, Tokenización de datos, Seguridad de datos y encriptación, Origen y ruta de datos, Ética/DSAR, ML confidencial, Aprendizaje federado.

Resultado

El control de acceso es un sistema de políticas, atributos y automatización que proporciona a los comandos los datos necesarios exactamente en la cantidad y el tiempo deseados, dejando una trazabilidad completa. En iGaming, es la base de la confianza en las métricas, la resistencia a incidentes y la velocidad de toma de decisiones.