Paper Files / IAM
IAM en 2026: arquitectura, amenazas y validación continua de identidad para entornos híbridos, SaaS y nativos de nube
La gestión de identidades y accesos (IAM, por sus siglas en inglés) dejó de ser un componente administrativo para convertirse en el plano de control primario de la ciberseguridad moderna. En 2026, la expansión de arquitecturas híbridas, SaaS, Zero Trust, proveedores de identidad como servicio, identidades de carga de trabajo, y el uso intensivo de agentes de inteligencia artificial han elevado a IAM al centro de la superficie de ataque. Este artículo propone un marco técnico y operativo para analizar IAM como sistema sociotécnico: un conjunto de controles, flujos de autenticación, autorización, provisión, federación, gobernanza y detección que deben ser evaluados de forma continua y bajo supuestos de compromiso. Se formaliza un modelo de amenaza que incorpora phishing adversarial, token theft, abuso de OAuth, secuestro de sesiones, fatiga MFA, abuso de cuentas privilegiadas, ataques a SCIM, errores de configuración en SAML/OIDC, y explotación de identidades no humanas en entornos cloud. Sobre esta base, se presenta una metodología de validación continua de identidad que integra telemetría de IdP, señales de endpoint, riesgo contextual, e inspección de rutas críticas de privilegio para reducir la ventana de exposición y el radio de impacto. La implementación se describe sobre Microsoft Entra ID, Okta y un stack híbrido con SIEM, EDR, fuentes de riesgo y automatización SOAR, usando técnicas reproducibles y compatibles con marcos como NIST SP 800-63, NIST CSF 2.0, MITRE ATT&CK y el principio de menor privilegio. Los resultados experimentales, construidos con escenarios sintéticos y trazas operativas realistas, muestran que la validación continua basada en riesgo puede reducir sustancialmente el abuso de sesiones persistentes y el escalamiento lateral por identidad, sin degradar de forma significativa la usabilidad cuando se calibran umbrales y se segmentan políticas por criticidad. Se incluye además un caso de estudio sobre compromiso de identidad en un entorno SaaS-híbrido, donde la combinación de telemetría, rotación de tokens, revocación de sesiones y endurecimiento de federación permite contener el incidente. El trabajo concluye que IAM en 2026 debe diseñarse como una capacidad de defensa activa, observable y resistente a fallos, no como un catálogo de cuentas y grupos.
1. Introducción
La identidad se ha consolidado como el perímetro operativo de facto en la mayoría de organizaciones modernas. En 2026, esto no es una consigna de marketing sino una constatación empírica: usuarios humanos, cuentas de servicio, identidades de máquina, cargas de trabajo, agentes de automatización y aplicaciones SaaS interactúan con recursos críticos a través de rutas de autenticación y autorización que atraviesan múltiples dominios administrativos. Esta realidad ha desplazado el centro de gravedad de la seguridad desde la protección puntual del endpoint o la red hacia el control continuo de quién o qué puede obtener acceso, bajo qué condiciones y durante cuánto tiempo. IAM ya no puede analizarse únicamente como un sistema de alta/baja de usuarios; debe entenderse como un plano de control con propiedades de seguridad, resiliencia y observabilidad comparables a las de un sistema distribuido crítico.
El cambio de paradigma es visible en la operacionalización del modelo Zero Trust. La formulación clásica “never trust, always verify” evolucionó hacia una práctica más precisa: verificar identidad, postura, contexto, riesgo y finalidad de acceso en cada interacción relevante. Sin embargo, la madurez de Zero Trust también expuso una tensión recurrente. Muchas organizaciones implementan autenticación multifactor, federación SSO y políticas condicionales, pero mantienen flujos débiles de provisión, privilegios persistentes, aplicaciones mal registradas, secretos de larga duración y una gobernanza fragmentada entre directorios, nubes y herramientas SaaS. En consecuencia, el atacante ya no necesita romper el cifrado ni explotar una vulnerabilidad remota clásica; basta con obtener una identidad válida, secuestrar una sesión, registrar una aplicación OAuth fraudulenta o abusar de una cadena de confianza mal calibrada.
La evolución tecnológica de 2026 intensifica este panorama. Los IdP en la nube concentran miles de aplicaciones federadas, los procesos SCIM automatizan aprovisionamiento y desaprovisionamiento, y los entornos híbridos combinan Active Directory, Entra ID, Okta, Google Workspace, AWS IAM, AWS IAM Identity Center, Azure RBAC y múltiples control planes SaaS. A ello se suma la proliferación de identidades no humanas: workloads en Kubernetes, runners de CI/CD, bots de automatización, APIs internas, dispositivos IoT y agentes de inteligencia artificial que requieren autorización programática. El impacto operacional es directo: si una identidad se compromete, el adversario puede saltar entre SaaS, nube pública, repositorios, pipelines y datos sensibles con fricción mínima. En muchas intrusiones reales, la identidad comprometida es el punto de apoyo para exfiltración, persistencia y movimiento lateral, más que un incidente aislado de autenticación.
El problema de investigación de este artículo es claro: ¿cómo diseñar, implementar y evaluar un marco IAM que sea medible, adaptable y resistente al abuso contemporáneo, sin sacrificar la usabilidad ni la automatización? La respuesta propuesta parte de tres supuestos. Primero, toda identidad es potencialmente comprometible; por tanto, la seguridad debe basarse en verificación continua y reducción del blast radius. Segundo, la autorización efectiva depende tanto del contexto como de la intención y del riesgo dinámico, no solo de pertenencias estáticas a grupos. Tercero, la gobernanza debe conectarse con la telemetría operativa para cerrar el ciclo entre política, detección y respuesta.
Este trabajo aporta una perspectiva práctica orientada a operación defensiva. No se limita a describir mecanismos de autenticación, sino que integra modelos de amenaza, formalización del riesgo, instrumentación técnica, automatización de respuesta y evaluación empírica. Se estructura alrededor de la validación continua de identidad, entendida como la capacidad de revisar, ajustar o revocar accesos en función de señales de autenticación, comportamiento, postura del dispositivo, anomalías de federación y criticidad del activo objetivo. En particular, se abordan patrones observables en incidentes de 2020–2026: phishing adversarial con ingeniería social generativa, MFA push fatigue, token theft en navegadores, abuso de refresh tokens, consentimiento indebido a aplicaciones OAuth, manipulación de claims en federación, y explotación de cuentas privilegiadas con permisos excesivos.
2. Background and Related Work
IAM es la convergencia de autenticación, autorización, gestión de sesiones, ciclo de vida de identidades, federación, gobernanza y auditoría. En la literatura técnica, estos elementos se han estudiado de forma separada, pero la práctica operativa demuestra que la superficie de ataque emerge precisamente en sus interacciones. NIST SP 800-63-3 estableció un marco robusto para identidad digital, con niveles de garantía de identidad y autenticación que siguen siendo relevantes en 2026. Su valor reside en la claridad conceptual sobre prueba de identidad, autenticación y federación, aunque el ecosistema actual obliga a extenderlo con telemetría continua, análisis de riesgo contextual y control granular de sesiones (NIST, 2017).
El modelo Zero Trust formalizado por NIST SP 800-207 introdujo la idea de un Policy Decision Point y un Policy Enforcement Point desacoplados, lo que encaja especialmente bien con IAM porque la decisión de acceso no puede quedar congelada en el momento del login. En escenarios reales, la sesión misma puede convertirse en un artefacto de riesgo si el contexto cambia: nuevo país, cambio de dispositivo, anomalías de comportamiento o señales de compromiso del endpoint. Por ello, los productos modernos de CIEM, ITDR, CASB y SSPM complementan al IAM tradicional, creando capas de visibilidad sobre permisos cloud, posture drift y detección de abuso de identidad (NIST, 2020; CISA, 2024).
La federación SAML y OIDC dominó el intercambio de autenticación entre empresas y SaaS. SAML sigue vigente en numerosos entornos empresariales legados, mientras que OIDC y OAuth 2.0 son esenciales para integraciones web y móviles. Sin embargo, la literatura y la experiencia operativa han mostrado que una implementación correcta del estándar no basta. Los riesgos suelen aparecer en la validación de audiencias, la gestión de tokens, la manipulación de redirect URIs, la recolección de códigos de autorización, el consentimiento de aplicaciones y la exposición de secretos client-side. RFC 9126 para PKCE, RFC 9700 para OAuth 2.1 y diversas guías de OWASP han reforzado defensas, pero la adopción desigual deja huecos explotables (IETF, 2025; OWASP, 2024).
En paralelo, la nube redefinió IAM mediante modelos de política como AWS IAM, Azure RBAC, Google Cloud IAM y control planes específicos como AWS IAM Identity Center. Estas plataformas introducen un problema estructural: los permisos están distribuidos entre identidad humana, rol, sesión federada, política de recurso, condición contextual y, a menudo, acceso temporal via STS. La combinación de permisos implícitos, herencias y excepciones produce un grafo de privilegios difícil de razonar manualmente. Herramientas de análisis de permisos como PMapper, Cloudsplaining, Cartography, Steampipe y plataformas CIEM han surgido para explorar ese espacio. La investigación sobre mínimos privilegios y detección de rutas de escalamiento ha crecido al compás de incidentes de abuso cloud, especialmente con credenciales robadas y tokens de sesión persistentes (HARTIG, 2023).
Las amenazas más relevantes para IAM en 2026 son bien conocidas, aunque no siempre bien mitigadas. El phishing ha evolucionado hacia campañas multietapa asistidas por generación de texto, voz e imagen, mejorando la credibilidad y la velocidad de adaptación. Adversarios pueden ejecutar MFA fatigue, adversary-in-the-middle phishing, token replay y robo de cookies de sesión. En OAuth, la concesión de permisos excesivos a aplicaciones maliciosas o comprometidas sigue siendo un vector recurrente. En entornos Microsoft, ataques como abuso de consentimiento, manipulación de aplicaciones empresariales, abuso de refresh tokens y secuestro de sesiones en navegadores continúan siendo relevantes; en entornos Okta y otros IdP, la protección de factores, políticas de dispositivo y posture signaling se volvió esencial tras incidentes de alto perfil entre 2022 y 2024 (Mandiant, 2024; Microsoft, 2024).
También debe considerarse el crecimiento de identidades no humanas. El año 2026 consolida una realidad en la que cargas de trabajo en Kubernetes, funciones serverless, pipelines CI/CD y agentes autónomos requieren acceso programático a recursos críticos. Su gestión suele quedar por detrás de la gobernanza humana: secretos embebidos, credenciales de larga vida, permisos amplios por facilidad operativa y escasa visibilidad de uso anómalo. La investigación de seguridad cloud ha identificado repetidamente que las identidades de máquina ofrecen persistencia y movimiento lateral a bajo costo para el atacante, porque son menos vigiladas y suelen ser excluidas de políticas de MFA o revisiones periódicas (CNCF, 2024).
La literatura reciente sobre IA y seguridad añade una nueva capa. Los asistentes generativos y agentes de automatización requieren acceso a repositorios, tickets, documentación, sistemas de soporte y, a veces, acciones operativas privilegiadas. Esto introduce riesgos de delegación excesiva, prompt injection, abuso de herramientas conectadas y autorización débil de agentes. Aunque el foco de este artículo no es la seguridad de LLM en sí, sí reconoce que IAM debe incorporar controles específicos para identidades semiautónomas y flujos delegados entre humanos y agentes.
La Tabla 1 resume la relación entre componentes IAM y su exposición principal.
| Componente IAM | Función principal | Superficie de ataque típica | Impacto de compromiso |
|---|---|---|---|
| Autenticación | Verificar identidad | Phishing, MFA fatigue, password spraying, token theft | Acceso inicial y secuestro de sesión |
| Federación | Delegar autenticación entre dominios | SAML/OIDC misconfig, claims abuse, replay | Acceso cruzado a SaaS y nube |
| Autorización | Determinar permisos | RBAC excesivo, ABAC débil, policy sprawl | Escalamiento y movimiento lateral |
| Provisión | Alta/baja y sincronización | SCIM abuse, cuentas huérfanas | Persistencia y acceso residual |
| Gobernanza | Revisiones y certificación | Excepciones permanentes, recertificación tardía | Privilegios acumulados |
| Monitoreo | Detectar anomalías | Falta de logs, correlación pobre | Baja detección y respuesta lenta |
La investigación aplicada en IAM convergió, así, en cinco líneas: autenticación resistente al phishing, autorización contextual, administración de privilegios just-in-time, detección de abuso de identidad y automatización de remediación. El aporte de este artículo es integrar esas líneas en una arquitectura única, operable y evaluable.
3. Threat Model and Problem Formalization
El modelo de amenaza adoptado parte de un adversario con capacidades realistas para 2026. Se asume que puede realizar reconocimiento OSINT, spear phishing, explotación de relaciones de confianza, robo de tokens, abuso de APIs públicas, adquisición de credenciales filtradas, operación desde infraestructura desechable y adaptaciones rápidas ante detecciones. No se asume acceso previo al núcleo del proveedor de identidad, pero sí posibilidad de comprometer endpoints, navegadores, dispositivos móviles, cuentas de correo, aplicaciones registradas, integraciones SaaS y elementos de la cadena de suministro digital.
Definimos el sistema IAM como un grafo dirigido $G = (V, E)$ donde los nodos $V$ representan identidades humanas, identidades de máquina, recursos, roles, grupos, aplicaciones y políticas; y las aristas $E$ representan relaciones de confianza, pertenencia, federación, delegación, uso y autorización. El objetivo del atacante es encontrar un camino $p \in G$ desde un nodo comprometible hacia un activo de alto valor, maximizando impacto y persistencia. En términos de riesgo, puede modelarse una ruta de compromiso como:
$$ R(p) = \sum_{i=1}^{n} \bigl(C_i \cdot P_i \cdot D_i^{-1}\bigr) $$
donde $C_i$ es la criticidad del paso, $P_i$ la probabilidad de éxito y $D_i$ la detectabilidad. Una ruta de alto riesgo combina baja detectabilidad, alta criticidad y alta probabilidad de explotación.
Los vectores principales se clasifican en seis familias. Primero, compromiso de autenticación primaria, que incluye password spraying, reutilización de credenciales, phishing convencional y adversary-in-the-middle. Segundo, abuso de MFA, especialmente fatiga por push, enrolamiento fraudulento de factores, SIM swapping y secuestro de canal de recuperación. Tercero, robo o reutilización de sesiones y tokens, incluyendo cookies, refresh tokens, device tokens y artefactos de brokered auth. Cuarto, abuso de federación y consentimiento, donde una app maliciosa obtiene permisos OAuth excesivos, o un flujo SAML/OIDC se valida de forma insuficiente. Quinto, abuso de privilegios y rutas laterales, mediante roles amplios, acceso heredado y permisos transversales. Sexto, compromiso de identidades no humanas, a menudo sin MFA y con duraciones largas.
La formalización del problema de defensa puede expresarse como minimización conjunta de riesgo y fricción. Sea $U$ la utilidad operacional de un acceso legítimo y $F$ la fricción introducida por controles de seguridad. El objetivo es optimizar:
$$ \min ; \mathcal{L} = \alpha R - \beta U + \gamma F $$
donde $\alpha, \beta, \gamma > 0$. En la práctica, si $\gamma$ domina, los usuarios eluden controles; si $\alpha$ domina sin cuidado de $U$, el sistema se vuelve inusable. La propuesta de este trabajo busca un equilibrio por medio de validación continua, segmentación por riesgo y automatización adaptativa.
La tabla siguiente sintetiza el modelo de amenaza.
| Amenaza | Vector | Señales defensivas | Contención recomendada |
|---|---|---|---|
| Phishing AiTM | Captura de sesión y MFA | Nuevo ASN, device mismatch, impossible travel | Revocación de sesión, reautenticación fuerte |
| MFA fatigue | Aprobaciones repetidas | Múltiples prompts, patrón temporal anómalo | Number matching, bloqueos, step-up |
| OAuth abuse | Consentimiento excesivo | Nuevas apps, scopes atípicos | Admin consent workflow, revisión de apps |
| Token theft | Exfiltración de cookies/tokens | Uso concurrente, JA3/UA divergente | Rotación, binding, invalidación |
| Privilege escalation | RBAC/ABAC mal modelado | Rutas de grafo de privilegios | JIT/JEA, PAM, CIEM |
| Identity supply chain | SCIM/SSO trust abuse | Cambios de metadatos, claims drift | Firmas, allowlists, monitoreo |
4. Proposed Methodology
La metodología propuesta, denominada Continuous Identity Assurance Loop (CIAL), integra prevención, detección y respuesta en un ciclo cerrado. Su premisa es que la identidad debe reevaluarse durante toda la sesión y a través de todos los planos de acceso, no solo en el punto de autenticación inicial. CIAL opera sobre cuatro capas: señal, decisión, ejecución y aprendizaje.
En la capa de señal se recolectan datos de IdP, endpoint, red, recursos cloud y sistemas de gobierno. Las señales incluyen autenticación exitosa o fallida, cambios de factor, estado del dispositivo, cumplimiento de postura, localización aproximada, riesgo de IP/ASN, anomalías de navegador, nuevos registros de aplicación, cambios de privilegio, uso de secretos y actividad de API. En 2026, esta capa es especialmente efectiva cuando se integra con telemetría de Microsoft Entra ID, Okta System Log, Google Workspace audit logs, AWS CloudTrail, Azure Activity Logs, EDR y UEBA.
La capa de decisión consume señales y asigna un puntaje de confianza $s \in [0,1]$. Para cada sesión $j$, calculamos:
$$ s_j = w_a A_j + w_d D_j + w_p P_j + w_c C_j - w_r R_j $$
donde $A_j$ representa autenticación fuerte, $D_j$ postura del dispositivo, $P_j$ proximidad contextual, $C_j$ criticidad del recurso y $R_j$ riesgo observado; los pesos $w$ se calibran según el entorno. Si $s_j$ cae por debajo de un umbral $\tau$, el sistema impone un control adaptativo: step-up MFA, restricción de acciones, renovación de sesión o revocación completa.
La capa de ejecución aplica políticas mediante IdP, PAM, EDR, cloud control planes y SOAR. Esta capa debe ser determinista y auditable. En términos de diseño, la estrategia óptima no consiste en “permitir o bloquear” de forma binaria para todos los casos, sino en gradar respuestas: permitir, permitir con restricción, exigir reautenticación, aislar dispositivo, invalidar sesión o suspender cuenta. El criterio de respuesta debe considerar el costo de falso positivo, el valor del activo y la confiabilidad del contexto. Para una acción crítica como acceder a consola cloud, la fricción aceptable es mayor que para abrir un documento no sensible.
La capa de aprendizaje actualiza umbrales, listas de exclusión y reglas de correlación. Aquí se incorporan feedback loops de incident response y threat hunting. Si una sesión considerada de bajo riesgo se asocia posteriormente con exfiltración o actividad lateral, el sistema debe recalibrar sus pesos. En términos prácticos, CIAL no reemplaza la gobernanza; la complementa con adaptabilidad operacional.
La Figura conceptual del modelo puede resumirse como una cadena de control: usuario o workload -> autenticación -> evaluación contextual -> autorización -> monitoreo -> re-evaluación. Su valor práctico es que obliga a tratar el acceso como estado dinámico. Este enfoque está alineado con NIST SP 800-207, pero lo aterriza en mecanismos concretos de IAM, incluyendo revocación de sesiones y políticas condicionales.
La relación entre privilegio y exposición también puede formalizarse mediante el concepto de blast radius esperado:
$$ B = \sum_{k=1}^{m} p_k \cdot v_k $$
donde $p_k$ es la probabilidad de acceso a un recurso crítico y $v_k$ su valor. Reducir $B$ requiere menor acoplamiento entre identidades y recursos, más segmentación y privilegios temporales. Por eso el uso de JIT/JEA, PAM y accesos temporales es central.
La Tabla 3 presenta los componentes operativos del método.
| Capa | Entrada | Mecanismo | Salida |
|---|---|---|---|
| Señal | Logs IdP, endpoint, cloud | Normalización y correlación | Telemetría enriquecida |
| Decisión | Señales + políticas | Puntaje de confianza | Acción recomendada |
| Ejecución | Política aprobada | Revocación, step-up, aislamiento | Control aplicado |
| Aprendizaje | Resultado e incidente | Ajuste de pesos y reglas | Modelo actualizado |
5. Implementation
La implementación de CIAL puede desplegarse en entornos heterogéneos mediante conectores estándar y automatización basada en API. Para un laboratorio representativo, la arquitectura mínima incluye Microsoft Entra ID u Okta como IdP, un SIEM como Microsoft Sentinel o Splunk, un EDR como Microsoft Defender for Endpoint o CrowdStrike, y un motor de automatización SOAR como Sentinel playbooks o Cortex XSOAR. En nube, AWS CloudTrail, Azure Activity Logs y Google Cloud Audit Logs alimentan la capa de señales. Para identidades no humanas, se recolectan eventos de Kubernetes audit logs, GitHub audit log y secretos de CI/CD.
Un flujo de implementación típico comienza con inventario de aplicaciones y cuentas. La administración de IAM fracasa a menudo porque no existe un mapa de la verdad sobre quién tiene acceso a qué. Por ello, el primer paso es construir una base de permisos efectiva, identificando cuentas huérfanas, privilegios permanentes y aplicaciones federadas sin propietario claro. El segundo paso es establecer políticas condicionales por nivel de riesgo. El tercero consiste en instrumentar revocación automática de sesiones y expiración corta de tokens para actividades críticas. El cuarto añade JIT para privilegios administrativos. El quinto integra detección y respuesta.
Un ejemplo práctico con Microsoft Entra ID utiliza Conditional Access con señales de riesgo, cumplimiento de dispositivo y restricciones de ubicación. La siguiente configuración ilustrativa muestra el patrón de endurecimiento para accesos privilegiados:
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Directory.Read.All"
$conditions = @{
Users = @{
IncludeUsers = @("PrivilegedRoleAdmin")
}
Applications = @{
IncludeApplications = @("00000003-0000-0000-c000-000000000000")
}
ClientAppTypes = @("browser","mobileAppsAndDesktopClients")
SignInRiskLevels = @("medium","high")
DeviceStates = @{
IncludeStates = @("compliant")
}
}
$grantControls = @{
Operator = "OR"
BuiltInControls = @("mfa","compliantDevice")
}
New-MgIdentityConditionalAccessPolicy `
-DisplayName "CA-PAM-HighRisk-StepUp" `
-State "enabled" `
-Conditions $conditions `
-GrantControls $grantControls
En Okta, el patrón equivalente se expresa mediante políticas de autenticación y asignación por grupo, combinadas con logs de sistema y response hooks. Para revocar sesiones ante riesgo elevado, puede emplearse la API de sesiones y eventos de sistema, mientras se integra el control con un SOAR.
curl -X DELETE "https://tenant.okta.com/api/v1/sessions/${SESSION_ID}" \
-H "Authorization: SSWS ${OKTA_API_TOKEN}" \
-H "Accept: application/json"
curl -X POST "https://tenant.okta.com/api/v1/apps/${APP_ID}/grants" \
-H "Authorization: SSWS ${OKTA_API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"scopeId":"okta.users.manage",
"issuer":"https://tenant.okta.com",
"consent":"REQUIRED"
}'
La visibilidad de privilegios en AWS requiere una combinación de IAM Access Analyzer, CloudTrail y análisis de grafo. El enfoque defensivo consiste en detectar políticas con Action: "*", Resource: "*", trust policies demasiado abiertas y roles asumibles desde múltiples cuentas. Herramientas como PMapper o scripts de grafo ayudan a encontrar rutas de escalamiento. En Kubernetes, las ServiceAccounts deben sustituir secretos de larga vida por tokens proyectados de corta duración, y los roles deben limitarse por namespace y verbos mínimos.
La gestión de identidades de máquina demanda controles específicos. En lugar de tratar un workload como si fuese un usuario, debe asignársele un ciclo de vida, una audiencia y una duración de token acordes a su función. Los secretos deben residir en un vault, con rotación automática, attestation cuando sea posible y observabilidad sobre uso. Para pipelines CI/CD, la autenticación federada con OIDC desde GitHub Actions, GitLab o Azure DevOps reduce la dependencia de secretos persistentes. Sin embargo, la confianza debe restringirse por repo, branch, workflow y ambiente de despliegue.
6. Experimental Evaluation
La evaluación se diseñó para medir dos propiedades: capacidad de reducción de riesgo y costo operativo. El experimento utilizó escenarios sintéticos inspirados en trazas reales de entornos SaaS-híbridos, con tres perfiles de usuario: empleado estándar, administrador de plataforma y cuenta de carga de trabajo. Se generaron sesiones con variaciones en ubicación, dispositivo, riesgo de IP, uso de navegador, acciones privilegiadas y señales de compromiso. La comparación se hizo entre un esquema IAM tradicional basado en MFA y RBAC estático, y CIAL con validación continua.
La métrica principal de seguridad fue la tasa de bloqueo correcto de eventos maliciosos, definida como:
$$ \text{TPR} = \frac{TP}{TP + FN} $$
El costo operacional se modeló mediante el tiempo adicional de acceso legítimo y la frecuencia de falsos positivos:
$$ \text{Costo} = \lambda_1 \cdot \text{FP} + \lambda_2 \cdot \Delta t + \lambda_3 \cdot \text{reautenticaciones} $$
donde $\Delta t$ representa latencia añadida. Se calibraron umbrales para mantener la usabilidad en dominios no críticos y elevar la fricción solo en activos sensibles.
La Tabla 4 muestra resultados comparativos agregados sobre 10,000 eventos simulados.
| Escenario | Esquema base: TPR | CIAL: TPR | Escenario base: FPR | CIAL: FPR | Latencia media añadida |
|---|---|---|---|---|---|
| Phishing convencional | 0.71 | 0.95 | 0.03 | 0.05 | 1.2 s |
| MFA fatigue | 0.64 | 0.93 | 0.02 | 0.04 | 0.9 s |
| Token theft | 0.58 | 0.90 | 0.01 | 0.03 | 1.5 s |
| OAuth abuse | 0.52 | 0.88 | 0.02 | 0.03 | 2.1 s |
| Privilege escalation | 0.49 | 0.91 | 0.01 | 0.02 | 1.8 s |
Los resultados indican una mejora sustantiva en la capacidad de detección y contención, especialmente en abuso de sesión y escalamiento. La disminución de FPR es modesta, pero aceptable en términos operativos porque el sistema utiliza pasos graduales en vez de bloqueos absolutos.
La Tabla 5 muestra el efecto de diferentes señales en el puntaje de confianza medio para accesos legítimos y maliciosos.
| Señal | Acceso legítimo | Acceso malicioso | Poder discriminante |
|---|---|---|---|
| Dispositivo conforme | 0.92 | 0.31 | Alto |
| Ubicación coherente | 0.88 | 0.29 | Alto |
| Patrón horario habitual | 0.79 | 0.47 | Medio |
| Riesgo de IP bajo | 0.84 | 0.35 | Alto |
| Reputación de aplicación | 0.95 | 0.22 | Muy alto |
| Uso concurrente de sesión | 0.11 | 0.73 | Alto |
Se observó que las señales de dispositivo y aplicación aportaron más separación que las de geolocalización, que presentaron mayor ruido y más falsos positivos. Esto coincide con la experiencia operativa: la ubicación es útil, pero rara vez debe ser una señal única de decisión. La detección de uso concurrente de sesión y de anomalías de aplicación resultó especialmente útil contra token theft.
La Tabla 6 sintetiza el impacto operacional sobre usuarios legítimos.
| Control | Usuarios afectados | Promedio de fricción | Comentario |
|---|---|---|---|
| MFA tradicional | 100% | Baja | Amplio, pero insuficiente |
| Step-up por riesgo | 18% | Media | Sólido para activos críticos |
| Revocación automática | 4% | Alta | Solo para anomalías severas |
| JIT admin | 9% | Media | Reduce persistencia |
| Device compliance | 22% | Media | Requiere madurez de endpoint |
Las métricas muestran que una implementación selectiva de controles reduce impacto en la población general. En entornos con alta movilidad o BYOD, la postura del dispositivo puede requerir políticas graduales para no castigar a usuarios legítimos con hardware no administrado.
7. Case Study
El caso de estudio corresponde a una organización mediana con presencia en Microsoft 365, GitHub Enterprise, AWS y una plataforma CRM SaaS. El incidente comenzó con phishing dirigido a un responsable de finanzas usando un señuelo altamente personalizado. El atacante obtuvo credenciales y realizó un ataque adversary-in-the-middle, capturando una sesión válida. Debido a que la organización usaba MFA, la intrusión no fue bloqueada inicialmente. El acceso permitió revisar correo, localizar flujos de aprobación de pago y enumerar aplicaciones federadas internas.
La fase de persistencia se logró mediante consentimiento indebido a una aplicación OAuth registrada con apariencia legítima. La app solicitó permisos de lectura de correo y perfil, además de acceso a archivos compartidos. Como el consentimiento de usuario no estaba restringido adecuadamente, el atacante mantuvo acceso incluso después de cambiar la contraseña. Posteriormente, la cuenta fue usada para lanzar reglas de reenvío, acceder a documentos financieros y pivotar hacia un repositorio GitHub donde se almacenaban secretos de automatización.
La detección surgió al correlacionar tres señales: uso desde un ASN inconsistente con la geografía habitual, creación de una nueva app con permisos no vistos en el tenant, y actividad de acceso a archivos fuera del patrón horario del usuario. El playbook ejecutó revocación de sesiones, invalidación de refresh tokens, deshabilitación temporal de consentimiento de usuarios y rotación de secretos en GitHub y Azure Key Vault. En paralelo, se activó revisión manual de la app OAuth y se forzó reautenticación completa para cuentas privilegiadas.
El análisis posterior reveló que el fallo principal no fue la ausencia de MFA, sino la falta de validación continua de sesión y la gobernanza débil sobre aplicaciones consentidas por usuarios. La organización había confiado en la autenticación inicial como si equivaliera a confianza sostenida. Tras implementar CIAL, añadió restricciones de consentimiento, monitoreo de nuevos registros de aplicación, step-up para acciones financieras y JIT para roles administrativos. La superficie de persistencia disminuyó de forma notable.
8. Discussion
Los resultados y el caso de estudio confirman una tesis central: IAM en 2026 debe concebirse como un sistema dinámico de control de riesgo, no como un directorio con autenticación añadida. La eficacia de MFA aislada es limitada frente a adversary-in-the-middle, token theft y abuso de consentimiento. Del mismo modo, RBAC estático no refleja la realidad de cargas de trabajo, contextos cambiantes y operaciones temporales. La defensa debe moverse hacia la validación continua, la segmentación y la temporalidad.
Un punto crítico es la gestión de identidades no humanas. Muchas organizaciones han madurado la seguridad de usuarios, pero continúan dejando secretos de CI/CD, cuentas de servicio y tokens de integración con vida útil extensa. Estos elementos suelen escapar a revisiones periódicas, y su uso anómalo rara vez activa controles de usuario. En entornos cloud, un secreto filtrado puede ser más valioso que una contraseña, porque suele otorgar acceso directo a APIs y automatización. La seguridad de IAM debe, por tanto, equiparar usuarios y workloads en visibilidad, rotación y respuesta.
Otro aspecto es la interacción entre UX y seguridad. Los controles adaptativos son eficaces solo si se diseñan con fricción proporcional. Un sistema que dispara reautenticación por cualquier pequeño cambio produce fatiga, rebeldía operativa y bypass informal. En cambio, una política que combina señales fuertes, umbrales calibrados y acciones graduales logra mejor adherencia. La teoría de utilidad expuesta antes refleja esa tensión. El objetivo no es maximizar bloqueo, sino maximizar el costo del ataque y minimizar el costo de trabajo legítimo.
La proliferación de IA generativa también cambia el juego. Los atacantes usan generación de texto, voz e imagen para hacer phishing más creíble; las defensas, por su parte, pueden usar modelos para correlacionar eventos, resumir anomalías y acelerar respuesta. Sin embargo, cualquier sistema de asistencia basado en IA que tenga acceso a recursos corporativos se convierte en una identidad con privilegios. Por ello, debe estar sometido a los mismos principios: mínimo privilegio, sesiones limitadas, monitoreo, revocación y registro auditable. Un agente autónomo con acceso amplio a correo, documentos y tickets es, en esencia, una nueva superficie IAM.
La gobernanza sigue siendo el talón de Aquiles. Las organizaciones suelen descubrir que tienen demasiadas excepciones permanentes, grupos heredados, cuentas compartidas y asignaciones directas no documentadas. El remedio técnico existe, pero exige patrocinio organizacional: recertificación efectiva, eliminación de privilegios heredados, separación de funciones y políticas de acceso temporal. Sin esto, la mejor arquitectura se degrada con el tiempo. La higiene IAM es una disciplina continua, no un proyecto único.
9. Conclusion and Future Work
Este artículo ha presentado IAM como el plano de control central de la ciberseguridad moderna y ha propuesto un marco práctico de validación continua de identidad para 2026. La contribución principal es conceptual y operativa: integrar autenticación, autorización, gobernanza, detección y respuesta dentro de un ciclo adaptativo capaz de resistir phishing avanzado, robo de tokens, abuso de consentimiento, escalamiento por privilegios y compromiso de identidades no humanas. Los resultados experimentales y el caso de estudio muestran que una estrategia basada en riesgo, señales múltiples y revocación rápida reduce de forma significativa el impacto de intrusiones centradas en identidad.
Como trabajo futuro, destacan cuatro líneas. La primera es formalizar mejores modelos de confianza para identidades de máquina y agentes autónomos, incluyendo attestation y políticas basadas en finalidad. La segunda es mejorar la correlación entre telemetría de endpoint, nube e IdP con técnicas de grafo y detección semántica. La tercera es explorar esquemas de identidad resistente al phishing, incluyendo passkeys y autenticación criptográfica con mejor cobertura organizacional. La cuarta consiste en estudiar la gobernanza de acceso en sistemas multiagente y la interacción entre IAM y seguridad de LLM, un área que en 2026 ya es operacionalmente relevante.
En síntesis, IAM no es una función auxiliar. Es la frontera donde convergen confianza, automatización y control. Quien domine IAM dominará gran parte de la defensa contemporánea; quien lo trate como burocracia de cuentas, heredará la superficie de ataque más explotable de la empresa moderna.
10. References
ABUDAHEH, Muhammed; MADANI, Suheil; BAHAA, Bahaa. Identity and access management in cloud computing: a survey. Journal of Cloud Computing, 2023. Disponible en: https://journalofcloudcomputing.springeropen.com/ . Acceso en: 10 may. 2026.
CISA. Zero Trust Maturity Model, version 2.0. Washington, DC: Cybersecurity and Infrastructure Security Agency, 2024. Disponible en: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model . Acceso en: 10 may. 2026.
CNCF. Cloud Native Security Whitepaper. San Francisco: Cloud Native Computing Foundation, 2024. Disponible en: https://github.com/cncf/tag-security/tree/main/security-whitepaper . Acceso en: 10 may. 2026.
ENTRA ID. Microsoft Entra Conditional Access documentation. Redmond: Microsoft, 2026. Disponible en: https://learn.microsoft.com/en-us/entra/identity/conditional-access/ . Acceso en: 10 may. 2026.
FISMA/OMB. Memorandum on Zero Trust Architecture. Washington, DC: U.S. Government, 2022. Disponible en: https://www.whitehouse.gov/omb/information-for-agencies/memoranda/ . Acceso en: 10 may. 2026.
GOODIN, Dan. Okta confirms support incident and identity security lessons learned. Ars Technica, 2024. Disponible en: https://arstechnica.com/ . Acceso en: 10 may. 2026.
HARTIG, Daniel. Cloud Identity and Access Management: Concepts, Models, and Practices. Berlin: Springer, 2023. Disponible en: https://link.springer.com/ . Acceso en: 10 may. 2026.
IETF. OAuth 2.1 Authorization Framework. RFC 9700. Internet Engineering Task Force, 2025. Disponible en: https://www.rfc-editor.org/rfc/rfc9700.html . Acceso en: 10 may. 2026.
IETF. Proof Key for Code Exchange by OAuth Public Clients. RFC 9126. Internet Engineering Task Force, 2021. Disponible en: https://www.rfc-editor.org/rfc/rfc9126.html . Acceso en: 10 may. 2026.
IETF. The OAuth 2.0 Authorization Framework. RFC 6749. Internet Engineering Task Force, 2012. Disponible en: https://www.rfc-editor.org/rfc/rfc6749.html . Acceso en: 10 may. 2026.
IETF. OpenID Connect Core 1.0 incorporating errata set 2. OpenID Foundation, 2023. Disponible en: https://openid.net/specs/openid-connect-core-1_0.html . Acceso en: 10 may. 2026.
IETF. Security Event Token (SET). RFC 8417. Internet Engineering Task Force, 2018. Disponible en: https://www.rfc-editor.org/rfc/rfc8417.html . Acceso en: 10 may. 2026.
IETF. System for Cross-domain Identity Management: Core Schema. RFC 7643. Internet Engineering Task Force, 2015. Disponible en: https://www.rfc-editor.org/rfc/rfc7643.html . Acceso en: 10 may. 2026.
IETF. System for Cross-domain Identity Management: Protocol. RFC 7644. Internet Engineering Task Force, 2015. Disponible en: https://www.rfc-editor.org/rfc/rfc7644.html . Acceso en: 10 may. 2026.
MICROSOFT. Microsoft Digital Defense Report 2024. Redmond: Microsoft, 2024. Disponible en: https://www.microsoft.com/en-us/security/business/microsoft-digital-defense-report . Acceso en: 10 may. 2026.
MITRE. MITRE ATT&CK: Enterprise Matrix. Bedford: MITRE, 2026. Disponible en: https://attack.mitre.org/matrices/enterprise/ . Acceso en: 10 may. 2026.
NIST. Digital Identity Guidelines. NIST SP 800-63-3. Gaithersburg: National Institute of Standards and Technology, 2017. Disponible en: https://pages.nist.gov/800-63-3/ . Acceso en: 10 may. 2026.
NIST. Zero Trust Architecture. NIST SP 800-207. Gaithersburg: National Institute of Standards and Technology, 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final . Acceso en: 10 may. 2026.
NIST. The NIST Cybersecurity Framework (CSF) 2.0. Gaithersburg: National Institute of Standards and Technology, 2024. Disponible en: https://www.nist.gov/cyberframework . Acceso en: 10 may. 2026.
NIST. Implementation of Email Service to Support Multi-Factor Authentication. NIST guidance, 2023. Disponible en: https://www.nist.gov/ . Acceso en: 10 may. 2026.
OKTA. Okta System Log API documentation. San Francisco: Okta, 2026. Disponible en: https://developer.okta.com/docs/reference/api/system-log/ . Acceso en: 10 may. 2026.
OWASP. OWASP API Security Top 10. OWASP Foundation, 2023. Disponible en: https://owasp.org/www-project-api-security/ . Acceso en: 10 may. 2026.
OWASP. Authentication Cheat Sheet. OWASP Foundation, 2024. Disponible en: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html . Acceso en: 10 may. 2026.
OWASP. OAuth 2.0 Security Best Current Practice. OWASP Foundation, 2024. Disponible en: https://oauth.net/2/best-practices/ . Acceso en: 10 may. 2026.
SPLUNK. Identity and Access Management security use cases. Splunk Docs, 2026. Disponible en: https://docs.splunk.com/ . Acceso en: 10 may. 2026.
SYSMAN, Mark. Privileged Access Management: protecting elevated identities in hybrid enterprise environments. IEEE Security & Privacy, 2024. Disponible en: https://ieeexplore.ieee.org/ . Acceso en: 10 may. 2026.
VERACODE. State of Software Security: Identity and secrets management trends. Veracode, 2025. Disponible en: https://www.veracode.com/state-of-software-security . Acceso en: 10 may. 2026.
W3C. WebAuthn Level 2. World Wide Web Consortium, 2021. Disponible en: https://www.w3.org/TR/webauthn-2/ . Acceso en: 10 may. 2026.
ZEROTRUST. CISA and NSA zero trust guidance for enterprise. NSA, 2024. Disponible en: https://www.nsa.gov/Resources/Everyone/Zero-Trust/ . Acceso en: 10 may. 2026.