Identidad no es sesión: qué ocurre con los tokens y credenciales ya emitidos en Azure, AWS y Google Cloud, y por qué el offboarding debe ir más allá de deshabilitar una cuenta.
Hay una idea que parece intuitiva, pero que en entornos federados puede ser peligrosamente incompleta:
Si deshabilito al usuario en el proveedor de identidad, ya no debería poder acceder al cloud.
Eso es cierto para los nuevos intentos de autenticación. Pero no necesariamente para las sesiones que ya existen.
Lo comprobamos de forma muy clara al cerrar uno de los entornos de formación que ha servido de base para esta serie. Los usuarios se deshabilitaron en Microsoft Entra ID y se revocaron sus sesiones en el IdP, pero eso no significaba que todas las sesiones emitidas previamente en los distintos proveedores cloud desapareciesen de forma instantánea.
La razón es sencilla:
centralizar la identidad no significa centralizar el ciclo de vida de todas las sesiones.
Y esa diferencia es especialmente importante en procesos de offboarding, respuesta ante incidentes y cuentas comprometidas.
Cuatro cosas distintas: identidad, autenticación, autorización y sesión
En los artículos anteriores de esta serie hemos ido separando conceptos que a menudo se mezclan.
Identidad
↓
Autenticación
↓
Autorización
↓
Sesión / credenciales temporalesLa identidad responde a quién es el usuario.
La autenticación verifica esa identidad.
La autorización determina qué puede hacer.
La sesión es el resultado operativo que permite continuar accediendo durante un periodo de tiempo sin repetir todo el proceso desde cero.
Cuando deshabilitamos una identidad estamos actuando sobre la primera capa. Pero las capas posteriores pueden haber generado ya sus propios tokens, cookies o credenciales temporales.
Figura 1. Deshabilitar una identidad impide nuevas autenticaciones, pero las sesiones ya emitidas pueden mantener su propio ciclo de vida en Azure, AWS y Google Cloud.
Qué ocurre realmente cuando deshabilitamos un usuario en Entra ID
En Microsoft Entra ID podemos deshabilitar una cuenta y revocar sus sesiones.
La operación revokeSignInSessions invalida los refresh tokens emitidos al usuario y las cookies de sesión de Entra ID. El objetivo es que el usuario no pueda seguir renovando silenciosamente su acceso y tenga que autenticarse de nuevo.
Microsoft Graph — revokeSignInSessions
Sin embargo, Microsoft documenta expresamente que los tokens de acceso ya emitidos pueden seguir siendo válidos hasta que caduquen, salvo que el recurso soporte mecanismos como Continuous Access Evaluation.
Microsoft Entra ID — Revoke user access
Por tanto, deshabilitar el usuario y revocar sus sesiones es una parte fundamental del proceso, pero no garantiza por sí sola que cada aplicación o proveedor externo haya invalidado también todas sus sesiones locales.
Azure: el caso más cercano a Entra ID
Azure es el proveedor donde la relación entre identidad y control de acceso resulta más directa, porque Microsoft Entra ID es también la base de autenticación del propio ecosistema Azure.
Aun así, sigue existiendo una diferencia entre invalidar la capacidad de obtener nuevos tokens y hacer desaparecer todos los tokens ya emitidos.
Microsoft indica que, en el modelo tradicional, un access token puede seguir siendo aceptado hasta su expiración. En aplicaciones que soportan Continuous Access Evaluation (CAE), eventos críticos como la deshabilitación de una cuenta o la revocación de sesiones pueden propagarse casi en tiempo real.
Microsoft Entra ID — Continuous Access Evaluation
La lección no es que Azure sea inseguro. La lección es que incluso dentro del mismo ecosistema debemos distinguir entre identidad deshabilitada y credencial ya emitida.
AWS: aquí la separación se ve de forma muy clara
En AWS, con un proveedor de identidad externo y IAM Identity Center, pueden coexistir varias capas de sesión:
Microsoft Entra ID
↓
Sesión del IdP
↓
AWS IAM Identity Center
↓
Sesión del AWS access portal
↓
Sesión de rol IAM
↓
AWS Console / CLI / CloudShellDeshabilitar el usuario en Entra ID impide que vuelva a autenticarse correctamente a través del IdP.
Finalizar su sesión en IAM Identity Center impide que continúe utilizando el portal de acceso para crear nuevas sesiones.
Pero AWS documenta una diferencia importante: terminar la sesión activa de IAM Identity Center no finaliza automáticamente las sesiones de rol IAM ya emitidas.
AWS IAM Identity Center — View and end active sessions
Las sesiones de rol continúan hasta que alcanzan la duración configurada en el Permission Set. Esa duración puede llegar hasta 12 horas.
AWS IAM Identity Center — Session duration for AWS accounts
Revocar la sesión de IAM Identity Center no equivale a revocar una sesión de rol IAM ya emitida.
Este detalle es especialmente relevante si el usuario tiene privilegios elevados o si la revocación responde a un incidente de seguridad.
¿Y si necesito cortar el acceso a AWS inmediatamente?
AWS tiene un procedimiento específico para escenarios en los que no podemos esperar a que expire una sesión de rol.
La recomendación documentada consiste en combinar la revocación de acceso con una política explícita de Deny que bloquee las acciones del usuario mientras las sesiones existentes terminan de expirar.
AWS IAM Identity Center — Use a Deny policy to revoke active user permissions
Es un buen ejemplo de una idea general:
cuando una credencial ya existe, impedir nuevas autenticaciones puede no ser suficiente; puede ser necesario bloquear también la autorización.
Google Cloud: SAML tampoco implica volver a Entra ID en cada petición
En el caso descrito en el artículo anterior, Google Cloud utiliza Cloud Identity para representar a los usuarios y SAML para delegar la autenticación en Entra ID.
Eso no significa que cada operación de Google Cloud vuelva a consultar a Entra ID.
Una vez que el usuario ha iniciado sesión, Google mantiene sus propias sesiones y credenciales. Por eso existen controles específicos de duración de sesión y reautenticación.
Google Cloud — Session controls for reauthentication
Google también ofrece un mecanismo administrativo para cerrar las sesiones web y de dispositivo de un usuario y restablecer sus cookies de inicio de sesión.
Google Admin SDK — users.signOut
De nuevo, la lógica es la misma: el IdP central controla la capacidad de autenticarse, pero el proveedor cloud controla el ciclo de vida de las sesiones que ya ha emitido.
El problema no es la federación
Puede parecer que esta complejidad es una desventaja de utilizar identidad federada. En realidad, no lo es.
Sin federación tendríamos el mismo problema, pero además tendríamos que gestionar cuentas, contraseñas y credenciales independientes en cada proveedor.
La federación mejora enormemente el control del ciclo de vida de la identidad.
Lo que no hace es convertir todos los clouds en una única plataforma de sesiones.
Una identidad central
≠
Una única sesión globalOffboarding no es un único botón
Un proceso de baja correctamente diseñado debería actuar sobre varias capas.
1. Deshabilitar la identidad de origen
↓
2. Revocar sesiones y refresh tokens del IdP
↓
3. Finalizar sesiones en los proveedores cloud
↓
4. Retirar grupos, asignaciones y permisos
↓
5. Bloquear sesiones activas si el riesgo lo exige
↓
6. Verificar que el acceso ha desaparecidoEn un entorno normal, algunos de estos pasos pueden ejecutarse de forma automática mediante aprovisionamiento, SCIM o workflows de identidad.
En una situación de compromiso, sin embargo, debemos asumir que el usuario puede tener una sesión activa y que el objetivo es reducir al mínimo el tiempo durante el cual esa sesión sigue siendo útil.
La duración de las sesiones es una decisión de seguridad
Una sesión de ocho o doce horas puede ser cómoda para un usuario.
También puede significar varias horas de exposición si una credencial temporal cae en manos equivocadas.
Por eso la duración de las sesiones no debería elegirse solo por comodidad.
En los laboratorios de formación he preferido sesiones relativamente cortas precisamente porque permiten un buen equilibrio entre usabilidad y control.
Cuanto mayor sea el privilegio, menos sentido tiene una sesión innecesariamente larga.
Qué automatizaría en producción
En un diseño real, el offboarding ideal no debería depender de que un administrador recuerde una lista manual de pasos.
Un workflow podría reaccionar a la deshabilitación de una identidad y ejecutar automáticamente las acciones necesarias en cada proveedor:
Evento en Entra ID
↓
Workflow de offboarding
├── Revocar sesiones Entra
├── Finalizar sesiones AWS Identity Center
├── Retirar asignaciones y grupos
├── Cerrar sesiones Google
└── Generar evidencia de verificaciónPara cuentas privilegiadas, además, tendría sentido disponer de un procedimiento específico de emergencia que pueda aplicar controles de Deny o equivalentes mientras expiran las credenciales temporales existentes.
La prueba final: ¿puede seguir haciendo algo?
Un buen proceso de offboarding no debería terminar cuando la consola muestra que el usuario está deshabilitado.
Debería terminar cuando hemos comprobado que:
- no puede volver a autenticarse;
- no puede crear nuevas sesiones;
- las sesiones existentes han terminado o han quedado bloqueadas;
- las asignaciones y permisos han sido retirados;
- y los logs muestran que el acceso ha cesado.
Ese último paso convierte el offboarding en algo verificable y auditable.
La idea que cierra la serie
Esta serie empezó con una arquitectura sencilla de explicar:
Una persona, una identidad, tres nubes.
Pero una arquitectura de identidad madura necesita una segunda frase:
Una identidad central no implica una única sesión central.
Microsoft Entra ID puede ser el origen de identidad para Azure, AWS y Google Cloud.
AWS puede recibir usuarios y grupos mediante SCIM y autenticar mediante SAML.
Google Cloud puede utilizar Cloud Identity como representación local y delegar la autenticación.
Y cada proveedor puede conservar su modelo nativo de autorización.
Pero cuando llega el momento de retirar el acceso, debemos recordar que los tokens y sesiones ya emitidos tienen vida propia.
Diseñar correctamente la identidad es importante.
Diseñar correctamente la revocación lo es tanto o más.
Referencias
Microsoft Entra ID — Revoke user access
Documentación oficial de Microsoft
Microsoft Graph — revokeSignInSessions
Documentación oficial de Microsoft
Microsoft Entra ID — Continuous Access Evaluation
Documentación oficial de Microsoft
AWS IAM Identity Center — Understanding authentication sessions
Documentación oficial de AWS
AWS IAM Identity Center — Revoke user access
Documentación oficial de AWS
Google Cloud — Session controls for reauthentication
Documentación oficial de Google Cloud
Google Admin SDK — users.signOut
Documentación oficial de Google
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.
Francisco Sepúlveda
Instructor de Cloud Computing y Ciberseguridad, Diseñador de Experiencias Formativas
Instructor y consultor en Cloud Computing, Ciberseguridad e IA, con más de 25 años de experiencia en entornos empresariales reales. Diseño e imparto programas de formación técnica combinando experiencia profunda en la materia con diseño de experiencias formativas, para que los conceptos complejos de seguridad realmente se queden. Comparto análisis técnico aplicado en Cloud Security in Practice.
Conoce más →