Segmentación de privilegios

1) Por qué se necesita segmentación

La segmentación de privilegios es clave para reducir los errores «blast radius» y el abuso de información privilegiada. Permite limitar con precisión quién y dónde puede realizar qué acciones con qué datos, al tiempo que mantiene la velocidad de las operaciones y el cumplimiento de los requisitos de los reguladores.

• menos incidentes por «derechos superfluos»;
• Agilizar las investigaciones: los accesos son transparentes y explicables;
• cumplimiento de SoD/cumplimiento, auditoría comprobada;
• experimentos seguros y lanzamientos rápidos sin riesgo para el núcleo prod.

2) Principios

Fideicomiso cero: cada acción se verifica contextualmente; no hay «zonas de confianza».
Privilegio Least: derechos mínimos otorgados por un período mínimo (idealmente, JIT).
Context over Role: los derechos dependen no sólo del rol, sino también de los atributos (tenant, región, entorno, riesgo).
Segregación de Duties (SoD): compartimos iniciación, aprobación, ejecución y auditoría.
Policy-as-Code: políticas en código con versionados, pruebas y rugidos.

3) Modelo de madurez de acceso

1. RBAC (roles): inicio - roles fijos (Support, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (attributes): agregamos atributos: tenant, región, jurisdicción, producto, canal, entorno (prod/stage/dev), tiempo, operación de clase riesgo, señales KRI.
3. PBAC (policy-based): políticas centralizadas «quién/qué/dónde/cuándo/por qué» + condiciones (por ejemplo, «en venta - sólo por JIT y con ticket»).

4) Dominios de segmentación (eje a eje)

4. 1 Tenant/cliente

El acceso y las operaciones se limitan a una marca específica/operador/afiliado.
Las actividades cruzadas están prohibidas, excepto las agregaciones estrictamente definidas sin PII.

4. 2 Región/Jurisdicción

Las políticas tienen en cuenta las normas locales de licencias y KYC/AML.
Las operaciones con los datos del jugador se limitan a la geografía de almacenamiento y procesamiento.

4. 3 Entorno (dev/stage/prod)

Prod está aislado: créditos individuales, redes, Bastion/PAM, «sólo por defecto».
Acceso a prod sólo JIT, con ticket y ventanas de cambio.

4. 4 Clase de datos

PII/finanzas/telemetría de juegos/tecnólogos - diferentes niveles de acceso y enmascaramiento.
Exportación de PII: sólo a través de workflow aprobado con cifrado y TTL.

4. 5 Criticidad de las operaciones

Clases de P1/P2/P3: publicación de coeficientes, compensación manual, conclusiones, cambio de routing PSP - requiere control dual.
Las operaciones de bajo riesgo pueden ser auto-apruved por la política.

5) Niveles de privilegio (tiers)

Visor: sólo lectura de agregados y datos enmascarados.
Operador: realizar los procedimientos de ranbooks sin cambiar las configuraciones.
Contributor: cambiar configuraciones en dominios no críticos.
Approver: aprobación de solicitudes y operaciones de alto riesgo (no se combina con la ejecución - SoD).
Admin (JIT): mejora a corto plazo para tareas raras bajo control dual y grabación de sesión.

6) SoD y funciones incompatibles

• Iniciar las conclusiones ≠ aprobar ≠ llevar a cabo finalmente.
• Crear una campaña de bonificación ≠ activar en la venta ≠ cambiar los límites.
• Desarrollar fichu ≠ appruve liberación ≠ puesta en marcha en prod.
• Solicitar la descarga de PII ≠ aprobar ≠ descifrar.

Para cada pareja, una política formalizada de prohibición y exclusión con fecha de revisión.

7) Acceso JIT y PAM

Elevation a petición: se especifica el objetivo/ticket/plazo; después de la expiración - auto-revocación.
Control dual: P1/P2 acciones son dos appruvers de diferentes funciones.
Control de sesión: grabación de sesiones críticas, alertas de anomalías, prohibición de copipasta cuando se trabaja con PII.
Break-glass: acceso de emergencia con límites estrictos y post-auditoría obligatoria.

8) Cuentas de servicio y API-scop

Escopetas mínimas; división por tareas/microservicios; tokens/certificados de vida corta.
La rotación de secretos, la prohibición de los secretos compartidos; prohibición de «god-scope».
Límites en ratios/quotas, claves de idempotencia, firma de webhooks (HMAC).

9) Segmentación a nivel de infraestructura

Redes: aislamiento de segmentos (per-domain/per-tenant), prohibición de egresos por defecto, mTLS.
Kubernetes/Cloud: Neymspace/proyectos de entorno y dominio, Gatekeeper/OPA para prohibir patrones peligrosos.
BD/Caché: broker de acceso (DB proxy/IAM), sólo read-only por defecto, DDL prohibido en la venta fuera de la ventana.
Almacenamiento: diferentes claves/baquetas de datos de clase per con políticas TTL y WORM para auditoría.

10) Políticas como código (PaC)

Políticas en repositorios (Rego/YAML), Ruletas PR, pruebas automáticas (unit/e2e), auditoría diff.
Contexto dinámico: hora del día, ubicación, nivel de KRI, puntuación de riesgo de la operación.
Explicación de la solución allow/deny y referencia a la política en auditoría.

11) Registros y auditorías

Plenitud: quién/qué/dónde/cuándo/por qué, pre/post-valores, ID del ticket.
Inamovible: recopilación centralizada, WORM/immutable, firma de registros.
Conectividad: cadena de la consola de administración → API → DB → proveedores externos.
Auditoría SLA: velocidad de respuesta a las solicitudes de control/regulador.

12) Dashboards y métricas (KPI/KRI)

KPI de acceso: cuota JIT vs derechos permanentes, duración media del privilegio,% de SoD cubiertos, tiempo de procesamiento de solicitudes, cobertura de recertificación.
KRI de abuso: ráfagas de operaciones sensibles, descargas masivas, ubicaciones/relojes atípicos, secuencias de «zayavka→deystviye→otkat».
Exec-dashboard: track status de roles de alto riesgo, break-glass eventos, tendencias.

13) Ejemplos de políticas (bocetos)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

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

Ned. 1-2: inventario de operaciones/roles/datos, matriz SoD, clasificación de datos y dominios de segmentación.
Ned. 3-4: base RBAC, directorio de roles, JIT para consolas prod, inicio de PaC (OPA/Gatekeeper).
Ned. 5-6: ABAC: atributos tenant/región/entorno/clase de datos; División de proyectos/NoSpace.
Ned. 7-8: PAM (JIT-elevation, sesión de grabación, break-glass), prohibición DDL y broker DB, política de exportación PII.
Ned. 9-10: PBAC para operaciones de alto riesgo (conclusiones, bonificaciones, PSP), control dual, alertas KRI.
Ned. 11-12: resertificación trimestral, cobertura de operaciones PaC 100% de alto riesgo, informes y capacitación.

15) Artefactos

Role Catalog: roles, privilegios mínimos, propietarios.
SoD Matrix: funciones/operaciones incompatibles, excepciones, proceso override.
Policy Pack: conjunto de políticas PaC con pruebas y ejemplos de deny/allow.
Formulario de solicitud de acceso: objetivo, fecha límite, objeto (tenant/región/entorno), riesgo-evaluación, appruvers.
Sensitive Ops Register: lista de acciones P1/P2, ventanas, criterios de control dual.
Audit Playbook: recopilar y proporcionar revistas, respuestas SLA, roles.

16) Antipattern

Derechos administrativos permanentes y cuentas generales.
Accesos cruzados «por conveniencia».
Ningún aislamiento prod/stage/dev.
Políticas en papel sin enforce en código/consolas.
Exportar PII mediante arreglo manual sin cifrado y TTL.
Falta de recertificaciones y derechos «dependientes».

17) Resultado

La segmentación de privilegios no es simplemente «roles correctos». Es un aislamiento multidimensional (tenante, región, entorno, datos, criticidad) + contexto dinámico (ABAC/PBAC) + procesos (SoD, JIT, resertificación) + coacción técnica (PaC, PAM, redes/DB). Este circuito reduce drásticamente el riesgo de errores y abusos, acelera los cambios seguros y hace que la plataforma sea resistente a los requerimientos de escala y reguladores.