Directivas de acceso y segmentación

1) Objetivos y principios

Objetivo: minimizar el riesgo de fugas/fraudes y consecuencias regulatorias a través de un estricto control de «quién, a qué y por qué tiene acceso», con probabilidad para la auditoría.
Principios: Privilegio Least (mínimo de derechos), Need-to-Know, Zero Trust, Segregation of Duties (SoD), Just-in-Time (JIT), trazabilidad y retroalimentación de acceso con un solo clic.

2) Clasificación de datos y niveles de protección

3) Modelo de acceso: RBAC + ABAC

RBAC (roles): matriz básica «rol → resolución».
ABAC (atributos): reglas de contexto (jurisdicción del jugador/operador, segmento de entorno, sensibilidad de marcado, cambio/tiempo, dispositivo, nivel de verificación KYC, tarea de servicio/purpose).

• El analista de marketing sólo puede leer las tablas de 'events _' para países donde hay consentimiento para el análisis, solo en la semana 08: 00-21: 00, sólo desde la red corporativa/dispositivo MDM, sin campos PII (enmascaramiento habilitado).

4) SoD - separación de responsabilidades (antifraude y cumplimiento)

5) JIT, break-glass и PAM

JIT (Just-in-Time): los derechos aumentados se emiten por intervalo limitado (15-120 min) para una tarea específica y se retiran automáticamente.
Break-glass: acceso de emergencia a través de un procedimiento separado (MFA + segunda confirmación + indicación de purpose obligatoria), grabación completa de la sesión y revuelo post-factum.
PAM: para cuentas de administración - almacenamiento de contraseñas, análisis de comportamiento, rotación de claves/secretos, proxy de sesión con registro.

6) Segmentación: entorno, red y lógica

6. 1 Miércoles: 'prod' ≠' stage '≠' dev '. Los datos de prod no se copian en stage/dev; se utilizan conjuntos sintéticos o pseudonimizados.

• Edge/WAF/CDN → Zona de aplicaciones → Zona de datos (DWH/DB) → Secrets/KMS.
• El perímetro de pago (PSP/tarjetas) está aislado del prod total; El CCA/sanciones es un segmento separado.
• 6. 3 Segmentación lógica: espacios de nombres (K8s), tenant-IDs, diagramas DB/directorio de datos, claves de cifrado individuales per tenant/región.
• 6. 4 Geo-segmentación: almacenamiento/tratamiento según ubicación (EC/UK/...); Enrutamiento de guidas y llaves por región.

7) Acceso de vendedores y socios

Mecánica: tenantes/cuentas B2B individuales, API-scop mínimo, mTLS, allow-list IP, tiempo-ventana.
Contratos: DPA/SLA (revistas, plazos de almacenamiento, geografía, incidentes, subprocesadores).
Offboarding: revocación de claves, confirmación de eliminación, acto de cierre.
Monitoreo: alertas a volúmenes anómalos, prohibición de exportaciones masivas.

8) Procesos (SOP)

8. 1 Solicitud/Cambio de acceso

1. Solicitud en IDM/ITSM con púrpura y plazo.
2. Verificación automática de SoD/jurisdicción/clase de datos.
3. Aprobación por el propietario del dominio + Security/Compliance (si Restringido +).
4. Emisión de JIT/acceso permanente (conjunto mínimo).
5. Registro: quién/cuándo/qué se emite; fecha de revisión.

8. 2 Revisión periódica (recertificación)

Trimestralmente: los propietarios confirman los derechos de los grupos; salida automática de los derechos no utilizados (> 30/60 días).

8. 3 Exportar datos

Sólo a través de pipelines/escaparates aprobados, por listas blancas de formatos (CSV/Parquet/JSON), enmascaramiento predeterminado, firma/hash, registro de descargas.

9) Política de dispositivos y contexto

MDM/EMM: acceso a Restricted/Highly Restricted sólo desde dispositivos administrados.
Señales contextuales: geo, dispositivo de riesgo, hora del día, estado MFA, reputación IP - como atributos ABAC.
Extensiones de navegador/captura de pantalla: control y registro, prohibición para consolas sensibles.

10) Ejemplos de políticas (fragmentos)

10. 1 YAML (pseudo) - ABAC para análisis de marketing

yaml policy: read_analytics_no_pii subject: role:marketing_analyst resource: dataset:events_
condition:
consent: analytics == true data_class: not in [Restricted, HighlyRestricted]
network: in [corp_vpn, office_mdm]
time: between 08:00-21:00 workdays effect: allow masking: default logging: audit_access + fields_scope

10. 2 enmascaramiento SQL (idea)

sql
SELECT user_id_hash,
CASE WHEN has_priv('pii_read') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

11) Monitoreo, registros y alertas

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `BREAK_GLASS`, `PAYMENT_APPROVE`.
KRIs: accesos sin 'purpose' = 0; Intentos de Highly Restricted fuera de la ventana; la proporción de verificaciones SoD fallidas; descargas anormales.
KPI:% de solicitudes con JIT ≥ 80%; Tiempo medio de acceso ≤ 4 horas; cobertura re-certificación 100%.
SOAR playbucks: revocación automática en caso de amenazas, tickets para investigar.

12) Cumplimiento (tarjeta breve)

GDPR/UK GDPR: minimización, Need-to-Know, compatibilidad DSAR, auditoría PII.
AML/KYC: acceso a CUS/sanciones - sólo para roles entrenados, registro de decisiones.
PCI DSS (si corresponde): segregación de área de pago, prohibición de almacenamiento PAN/CSC, claves/alojamiento individuales.
ISO/ISMS: políticas de acceso formalizadas, auditorías anuales y pruebas.

13) PACI

14) Métricas de madurez

Cobertura de las reglas ABAC de conjuntos de datos críticos ≥ 95%.
Sesiones JIT/todas las mejoras de derechos ≥ 90%.
Tiempo de retirada de acceso por offboarding ≤ 15 min.
0 incidentes «función ≠ función» (SoD).
100% de los registros de acceso están disponibles y verificados (firma/hash).

15) Hojas de cheques

15. 1 Antes de emitir el acceso

• Se ha definido purpose, fecha límite y propietario de los datos
• Verificación de SoD/jurisdicciones pasadas
• Scop/enmascaramiento mínimo habilitado
• MFA/MDM/condiciones de red cumplidas
• El registro y la fecha de revisión están configurados

15. 2 Revisión trimestral

• Conciliación de grupos y roles con la estructura orgánica
• Autorizar los derechos «colgantes»
• Verificación de exportaciones anormales y break-glass
• Aprendizaje y alertas de prueba

16) Escenarios y medidas modelo

A) Nuevo rol de «administrador VIP»

Acceso a perfiles VIP (enmascarado), prohibición de exportación, JIT para ver KYC una sola vez a través de un ticket.

B) Auditoría vendedora de BI

sólo lectura a escaparates sin PII, VPN temporal + allow-list, prohibición de guardar localmente, registro de descargas.

C) Acceso de emergencia de DevOps a prod-DB

break-glass ≤ 30 min, sesión de grabación, post-rugido con DPO/Compliance, CAPA en caso de irregularidades.

17) Hoja de ruta para la aplicación

Semanas 1-2: inventario de datos/sistemas, clases de datos, matriz RBAC básica, SoD.
Semanas 3-4: implementar ABAC (primeros atributos: entorno, geo, clase de datos), flujos IDM, JIT/break-glass, PAM.
Mes 2: segmentación de pago y perímetro KYC, claves individuales/KMS, registros de exportación, alertas SOAR.
Mes 3 +: re-certificaciones trimestrales, ampliación de atributos (dispositivo/riesgo), automatización del enmascaramiento, ejercicios regulares.

TL; DR

Modelo de acceso fiable = clasificación de datos → RBAC + ABAC → SoD + JIT/PAM → segmentación rígida → registros y alertas. Esto reduce la probabilidad de fugas y abusos, acelera la auditoría y mantiene la plataforma dentro de los límites del GDPR/AML/PCI y los estándares internos.