Identity & Access Management

Resumen breve

IAM es un conjunto de procesos, políticas y herramientas que proporcionan quién accede a qué, en qué condiciones y cómo se controla. Objetivos: minimizar el exceso de derechos, reducir la superficie de ataque, acelerar el onboarding y la auditoría, cumplir con los requisitos (PCI DSS, GDPR, etc.) y medir la confiabilidad del acceso.

Conceptos básicos

Identidad (Identity): persona (empleado, contratista), servicio/aplicación, dispositivo.
Autenticación (AuthN): verifique «quién» (contraseña → MFA → esquemas FIDO2/passkeys libres de parolas).
Autorización (AuthZ): solución «lo que está permitido» (RBAC/ABAC/ReBAC, políticas).
Credenciales (Credentials): contraseñas, claves, tokens, certificados (mTLS).
Gestión secreta: KMS/HSM/Vault, rotaciones, TTL cortos, secretos dinámicos.
Ciclo de vida: Joiner-Mover-Leaver (JML) - Crear, cambiar roles, revocar.

Arquitectura IAM de destino

• IdP (proveedor de identidad): SSO, MFA, catálogo, federación (OIDC/SAML), políticas de riesgo.
• PDP/PEP: Decision/Enforcement - Motor de políticas (OPA/Cedar) + Puntos de aplicación (API gateways, proxy, mesh de servicio).
• Directorios/sistema de recursos humanos: fuente de la verdad sobre empleados y roles.
• Providencia: SCIM/Automation para crear/modificar/retirar accesos.
• Auditoría: registros centralizados, UEBA, informes de roles y accesos.

• SSO (+ MFA) → emisión de token (OIDC/JWT/SAML) → PEP verifica el token/contexto → PDP decide por política (rol/atributos/riesgo) → la aplicación emite/deniega el acceso.

Autenticación: de contraseñas a passkeys

Contraseñas: sólo con gestores de contraseñas, un mínimo de 12-14 caracteres, sin rotación «por calendario», pero con obligatoriedad en caso de incidente.
MFA predeterminado: TOTP/WebAuthn/Push; evitar el SMS como factor principal.
Entrada libre de parolas: FIDO2/passkeys para dominios críticos.
AuthN adaptativo: tenga en cuenta la señal de riesgo (geo, ASN, dispositivo, anomalías) → requiera factor/bloqueo adicional.

Autorización: RBAC, ABAC, ReBAC

RBAC: roles que coinciden con las funciones (Support, Finance, DevOps). Simple y comprensible, pero «creciente».
ABAC: reglas por atributos (departamento, nivel de riesgo, tiempo, zona, etiquetas de recursos). Escalable.
ReBAC: una relación de «quién se relaciona con qué» (propietarios de proyectos, miembros de equipos). Conveniente para escenarios multitenantes.

• Combinar RBAC (red básica) + ABAC/ReBAC (contexto/bordes).
• JIT (Just-In-Time): emisión de privilegios temporales a través de solicitud/appruve, revocación automática.
• JEA (Just-Enough Access): derechos mínimos suficientes para la operación.
• PAM: accesos «fuertes» aislados (almirantes de la DB/nube) con un corredor de sesiones, grabación de pantalla/comandos y emisión de créditos de vida corta.

Federación y SSO

Protocolos: OIDC (tokens JWT), SAML 2. 0 (XML assertions) - para proveedores/socios externos.
SSO: punto de entrada único con MFA, reducción de phishing, revocación centralizada.
B2B/B2C: federación con socios, limitación de áreas, políticas de dominio.
mTLS/m2m: para servicios, utilice x.509 de breve duración (SPIFFE/SVID) o OAuth2 Credentials para clientes.

Ciclo de vida (JML) y providencia

Joiner: provisión SCIM automática de cuentas y roles básicos de HR/catálogo.
Mover: los roles cambian automáticamente por atributos (subdivisión, proyecto, ubicación).
Leaver: revocación inmediata de SSO, claves, tokens, accesos a repositorios/nubes/CI/CD.
Procesos: solicitudes de acceso (ITSM), matriz SoD (separación de funciones), revisión periódica de acceso.

Secretos, claves y rotaciones

KMS/HSM: almacene las claves raíz/crítica, active la auditoría de operaciones.
Vault/Secrets-managers: créditos dinámicos (DB, nubes), revoluciones automáticas al completar TTL.
Rotaciones: tokens de OAuth, claves de firma JWT, contraseñas de servicio - según lo programado y en caso de incidentes.
mTLS: certificados de breve duración (horas/días), reinicio automático.

Políticas y motor de soluciones

Declaratividad: almacenar las políticas en Git; compruebe en CI (policy-tests).
Contexto: tiempo/ubicación/ASN/nivel de riesgo/estado del dispositivo (MDM/EDR).

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Monitoreo, SLO y auditoría

• Éxito de AuthN/AuthZ (%), p95 tiempo de inicio de sesión/solución, fracción de MFA/entradas libres de parolas.
• Kol-in escalas JIT/PAM, duración media de los privilegios.
• Cobertura de dispositivos compliant, una fracción de los secretos de vida corta.

• Disponibilidad de SSO/IdP ≥ 99. 95% por mes.
• p95 AuthZ decision ≤ 50 мс.
• 100% desactivación de la cuenta ≤ 15 minutos después de offboarding.
• Auditoría y UEBA: registros inmutables centralizados (accesos, cambios de rol, entradas fallidas, soluciones PDP), análisis de comportamiento y alarmas de anomalías.

Incidente de respuesta en IAM

Compromiso de tokens/claves: revocación inmediata, logout forzado, rotación de claves de firma, re-issue de secretos de vida corta.
Abuso de derechos: suspender la cuenta, bloquear JIT/JEA, realizar una revisión de acceso a entidades vecinas.
IdP no está disponible: modos fuera de línea (validación en caché temporal de tokens con TTL corto), procedimientos de recuperación prioritarios.
Phishing: MFA obligatorio, pruebas de riesgo de sesiones, notificaciones a los usuarios, capacitación.

Nubes y Kubernetes (patrones)

Public Cloud IAM: utilice roles nativos con el principio de privilegio least; en lugar de las claves «eternas», las cargas de trabajo con la federación OIDC hacia la nube (IRSA/Workload Identity).
Kubernetes: RBAC para roles/nymspace, restringir 'cluster-admin'; secretos - a través de gestores externos; mesh de servicio + OPA para políticas L7; Controladores de administración (imágenes firmadas, prohibición «: latest»).
API gateways: verificación de JWT/mTLS, límites de velocidad, firma de solicitudes (HMAC) para endpoints sensibles.

Práctica para iGaming/Fintech

Dominios de acceso: pagos, antifraude, PII, proveedores de contenido - aislar roles y segmentos de red.
SoD: prohibición de combinar roles en conflicto (por ejemplo, creación de promociones + aprobación de pagos).
PAM y JIT: para acceder a PSP/bancos y prod-DB - sólo a través de un corredor de sesiones, con registro y auto-revocación.
Cumplimiento: PCI DSS - MFA, privilegios mínimos, segmentación de zona CHD; El GDPR es un principio de minimización de datos y registros puntuales de acceso a PII.
Socios y proveedores de contenido: federación y política per-tenant; tokens de vida corta y IP/ASN allow-list.

Errores típicos

Claves y tokens «eternos»: no hay rotaciones y TTL → un alto riesgo de fugas.
Offboarding manual: retrasos en la retirada de derechos → accesos «fantasma».
Roles monolitos: un «super-rol» en lugar de composición y atributos.
MFA sólo en administración: MFA debe ser para todas las entradas y operaciones críticas.
Registros «a ninguna parte»: falta centralización y UEBA → detección tardía de incidentes.

Hoja de ruta para la implementación de IAM

1. Inventario de usuarios/servicios/recursos; mapa de datos y sensibilidad.
2. SSO + MFA para todos, incluir factores de resistencia a la física.
3. Modelo de roles: atributos RBAC + básicos (ABAC) para el contexto; matriz SoD.
4. Providencia SCIM: creación automática/modificación/revocación de derechos de HR/catálogo; aplicaciones y apruvas en ITSM.
5. PAM y JIT/JEA: para accesos privilegiados; grabación de sesiones, TTL cortos.
6. Gestión de secretos: rechazar claves estáticas; secretos dinámicos, rotaciones, mTLS con certificados breves.
7. Políticas en Git + CI: pruebas de reglas, control de cambios, implementaciones de políticas canarias.
8. Observabilidad y SLO: dashboards AuthN/AuthZ, alertas, revisiones regulares de acceso.

Ejemplos de artefactos

AWS IAM Policy (mínimo para leer informes S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (desarrollador de namespace-scoped)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: afirmaciones para ABAC (ejemplo)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

La directiva puede requerir que 'device _ compliant = true' y 'tenant' coincidan con el recurso.

Lista de verificación

• SSO está habilitado para todas las aplicaciones; MFA por defecto, passkeys en prioridad.
• RBAC definido; ABAC/ReBAC añaden contexto; implementado por JIT/JEA.
• PAM protege los accesos privilegiados; Se está grabando la sesión.
• Providencia SCIM de HR; offboarding totalmente automatizado.
• Los secretos son dinámicos, con TTL corto; las rotaciones están automatizadas.
• Las políticas se versionan en Git, se prueban en CI; Hay diseños canarios.
• Dashboards y SLO por AuthN/AuthZ; logs centralizados y UEBA.
• Revisiones periódicas de acceso y verificaciones SoD; informes de cumplimiento.

FAQ

¿Necesita ReBAC todo el mundo?
No. Para entornos simples, RBAC + ABAC es suficiente. ReBAC es útil en una compleja jerarquía de propiedad de recursos y multitenencia.

¿Puedo dejar las cuentas locales?
Sólo para scripts break-glass y offline, con restricciones estrictas y validación periódica.

¿Cómo puedo reducir la «explosión de roles»?
Aumentar la granularidad de los recursos, utilizar AVAS/plantillas, automatizar el rugido y abandonar roles no utilizados.

Resultado

La arquitectura IAM madura es SSO + MFA, derechos mínimos necesarios, JML automatizado, políticas centralizadas y observabilidad. Al combinar RBAC con modelos de atributos y relacionales, aplicar JIT/JEA y PAM, y automatizar la provisión y la rotación de secretos, obtiene un acceso gestionado, verificable y escalable que cumple con los requisitos de seguridad y negocios.