Control de acceso a operaciones

1) Por qué es necesario

El control del acceso a las operaciones evita pérdidas financieras, abusos e irregularidades regulatorias. Limita los errores «blast radius» y las amenazas de información privilegiada, acelera las investigaciones y hace que los cambios sean rastreables. Para iGaming, esto es crítico en los dominios de pago, la oposición al frod, los programas de bonificación y la gestión de contenido de juegos/ratios.

2) Principios básicos

Fideicomiso cero: no confíe en el valor predeterminado; comprueba cada acción.
Privilegio Least: derechos mínimos necesarios por tiempo limitado.
Need-to-know: acceso a datos/funciones sólo para un propósito válido.
Segregation of Duties (SoD): división de roles «solicitud → aprobación → ejecución → auditoría».
Accountability: cada acción es sobre un sujeto con nombre con responsabilidad personal/delegada.
Composabilidad: el acceso está formado por políticas que se pueden validar y versionar como código.

3) Modelo de control de acceso

3. 1 Modelos de roles y atributos

RBAC: roles básicos por función (Support, Risk, Payments, Trading, Ops, Dev, SRE, Compliance).
ABAC: atributos tenant/región/jurisdicción/canal/producto/entorno (prod/stage/dev).
PBAC/Policy-as-Code: reglas en OPA/Rego o análogas: quién/qué/dónde/cuándo/por qué + contexto (KRI, tiempo, nivel de riesgo de cirugía).

3. 2 Matriz SoD (ejemplo)

Pagos/conclusiones: iniciar ≠ aprobar ≠ llevar a cabo.
Bonos: crear una campaña ≠ activar en la venta ≠ cambiar los límites.
Coeficientes/línea: modelado ≠ publicación ≠ retroceso.
Datos/PII: solicitud de descarga ≠ aprobación ≠ acceso al descifrado.
Lanzamientos: el desarrollador ≠ el appruver de lanzamiento ≠ el operador de salida.

4) Esquema de identificación y federación

SSO/MFA: punto de entrada único con MFA obligatorio, soporte de FIDO2.
Just-In-Time (JIT) Provisioning: permite emitir roles al iniciar sesión por atributos y grupo de riesgo.
SCIM/HR-driven: cesión/revocación automática de derechos sobre eventos HR (hire/move/exit).
Cuentas de servicio: fichas/certificados de breve duración, rotación de secretos, scope limitado.

5) Acceso privilegiado (PAM)

JIT-elevation: mejora temporal de los privilegios, indicando la causa y el ticket.
Control dual (4-eyes): las operaciones de alto riesgo (P1/P2) requieren dos appruvers de diferentes funciones.
Control de sesión: grabación/keylogue de sesiones críticas, alertas de anomalías, prohibición de copipasto/intercambio de archivos si es necesario.
Break-glass: acceso de emergencia con límites estrictos, post-auditoría obligatoria y revocación automática.

6) Control de acceso a datos

Clasificación: PII/financiera/técnica/pública.
Masking de datos: enmascaramiento por roles, tokenización de identificadores.
Rutas de acceso: la analítica lee los agregados; acceso a PII en bruto - sólo a través de un workflow aprobado con una ventana de tiempo objetivo.
Exportación/línea: todas las descargas están firmadas por solicitud/ticket, almacenadas en forma cifrada con TTL.

7) Control de las operaciones de dominio de iGaming

Retiros de fondos: límites por cantidad/hora/día, approw de 2 factores, factores de parada automática (puntuación de riesgo, velocity).
Bonificaciones/giros gratis: cap en presupuesto/tenant, sandbox, dos niveles de aprobación.
Coeficientes/líneas de mercado: los períodos promocionales requieren doble verificación, registro de publicaciones, retroceso rápido.
KYC/AML: acceso a documentos - por propósito y ticket, prohibición de descargas masivas.
Rutas de pago: cambiar las reglas PSP - sólo a través de change-management con review de comisiones/conversiones.
Acciones de sapport: congelar la cuenta, cargar/cargar - sólo a través de la plantilla de playbook, con la creación automática del caso.

8) Acceso a la infraestructura

Segmentación del entorno: prod está aislado; acceso prod - a través de bastión con certificados SSH/MTLS cortos.
Kubernetes/Cloud: Políticas de nonymspace/neutro prohibidas por defecto, PodSecurityPolicies/OPA Gatekeeper.
BD/caché: corredores de acceso (DB proxy, IAM-on-level-request), «read-only predeterminado», prohibición de DDL en la venta sin ventana de cambio.
Secretos: gestor de secretos, rotación automática, prohibición de secretos en las variables del entorno sin cifrado.

9) Procesos de solicitud y apruves

Directorio de acceso: descripciones de roles, atributos, clase de riesgo de operaciones, SLO de consideración.
Solicitud: justificación, plazo, objeto (tenante/región/entorno), volumen de operaciones previsto.
Apruve: line manager + data/ops owner; para los de alto riesgo - Compliance/Payments/Risk.
Resertificación (Access Review): trimestralmente: los propietarios confirman que los derechos son correctos; desactivación automática de los accesos «bloqueados».

10) Políticas como código (Policy-as-Code)

Centralización: OPA/Rego/webhooks en CI/CD y consolas de administración.
Versificación: procesos de PR, rugidos y pruebas de políticas, auditoría de diff.
Contexto dinámico: hora del día, KRI, geo, puntuación de riesgo del jugador/operación.
Probabilidad: cada solución allow/deny corresponde a una política explicable y una entrada en la auditoría.

11) Registros y auditorías (tamper-evident)

Inamovible: colección centralizada (almacenamiento WORM/immutable), firma de registros.
Plenitud: quién, qué, dónde, cuándo, por qué (ID de ticket), pre/post-significados.
Conectividad: operación de Trail a través de la consola → API → DB → proveedores externos.
Auditoría SLA: disponibilidad de registros, tiempo de respuesta a la solicitud de control/regulador.

12) Monitoreo y alerting

KPI de acceso:% de accesos JIT, tiempo de vida promedio del privilegio, fracción break-glass, derechos no utilizados> N días.
KRI de abuso: spikes de acción sensible, descargas masivas, relojes/ubicaciones atípicas, secuencias de «aplicación → acción → retroceso».
alertas de tiempo real: para las operaciones P1/P2 - en el canal on-call y SecOps.

13) Pruebas y control de calidad

Tabletop/pentest stori: scripts de iniciador, token robado, abuso de roles de sapport, errores de configuración intencionales.
Chaos-access: forzar la revocación de derechos durante el cambio activo, comprobando la sostenibilidad de los procesos.
Pruebas DR: falla SSO/PAM, acceso por break-glass, restablecimiento del bucle normal.

14) Hoja de ruta para la implementación (8-12 semanas)

Ned. 1-2: inventario de operaciones/roles/datos, evaluación de riesgos y matriz SoD primaria.
Ned. 3-4: SSO/MFA en todas partes, directorio de accesos, JIT para consolas de administración, políticas básicas de OPA.
Ned. 5-6: PAM: JIT-elevation, sesión de grabación, break-glass con post-auditoría. Enmascarar PII y flujo de trabajo en las descargas.
Ned. 7-8: segmentación prod/stage/dev, modelo bastion, broker de acceso DDL, prohibición DDL.
Ned. 9-10: operación de alto riesgo con control dual; alertas de KRI de abuso; las primeras enseñanzas tabletop.
Ned. 11-12: automovigilancia/SCIM, revisión trimestral de acceso, seguimiento completo de auditoría y métricas de rendimiento.

15) Artefactos y patrones

Role Catalog: rol, descripción, privilegios mínimos, atributos ABAC, propietario.
SoD Matrix: funciones/operaciones incompatibles, excepciones, proceso temporal override.
Sensitive Ops Register: lista de acciones P1/P2, criterios de control dual, ventanas de ejecución.
Formulario de solicitud de acceso: objetivo, fecha límite, objeto, ticket, evaluación de riesgo, appruvers.
Paquete de políticas (PaC): conjunto de políticas de rego con pruebas y ejemplos de deny/allow.
Audit Playbook: cómo recopilar una cadena de eventos, SLA de respuesta, quién comunica con el regulador.

16) Funciones de KPI

% de las operaciones cubiertas por SoD y control dual

Tiempo medio de vida de privilegios elevados (objetivo: horas, no días)

Porcentaje de accesos permanentes JIT- vs

Tiempo de cierre de solicitudes y% de apruves automáticos por plantillas de bajo riesgo

Número/frecuencia de incidentes donde el acceso ha sido un factor clave

Exhaustividad de la auditoría (% de eventos relacionados con ticket/causa)

17) Antipatternas

«Admin para siempre» y cuentas generales.
Acceso a los datos prod a través de BI/ad-hoc sin enmascaramiento ni registro.
Políticas en papel sin enforce en código/consolas.
Break-glass sin post-mortem y revocación automática.
Descargas manuales PII «por buena voluntad».
Mezcla de papeles de sapport y appruvers financieros.

Resultado

El control efectivo del acceso a las operaciones es una combinación de principios estrictos (Zero Trust, Least Privilege, SoD), medios técnicos (SSO/MFA, PAM, PaC, segmentación, brokers de BD), procesos de gestión (catálogo de roles, aplicaciones/apruvas, resertificación) y auditorías auditables. Este circuito hace que la infraestructura y las operaciones comerciales sean sostenibles, reduce la probabilidad de abuso y acelera la respuesta a incidentes, con un cumplimiento probado de los reguladores y socios.