Si alguna vez has gestionado un tenant de Microsoft Entra ID, seguro que te has hecho esta pregunta incómoda: «¿Qué pasa si un día no puedo entrar como administrador?» Para ese escenario existen las cuentas break glass en Entra ID: cuentas de emergencia diseñadas para que nunca te quedes completamente fuera de tu propio directorio, ni siquiera cuando falla el MFA, caiga la federación o una política de Conditional Access mal configurada te bloquea a ti mismo.
En este post repasamos por qué estas cuentas son importantes, cuáles son las buenas prácticas actuales recomendadas por Microsoft y, para cerrar, montamos un pequeño laboratorio para monitorizar su actividad con Azure Monitor.
¿Qué es una cuenta break glass?
Una cuenta break glass en Entra ID es una cuenta de Global Administrator creada exclusivamente para escenarios de emergencia, cuando las cuentas administrativas «normales» no se pueden usar. El nombre viene de la típica caja de cristal de las alarmas de incendio: «rómpase en caso de emergencia».
No es una cuenta más de administrador. Es tu último recurso cuando todo lo demás falla.
¿Por qué son tan importantes?
Microsoft documenta varios escenarios reales en los que una organización puede quedarse fuera de su propio tenant:
- Caída de la federación: si usas ADFS u otro proveedor de identidad federado y este se cae, los usuarios no pueden autenticarse porque Entra ID los redirige a un proveedor que no responde.
- Fallo de MFA: los administradores no pueden completar la autenticación multifactor (dispositivo perdido, sin cobertura, servicio caído).
- Salida del último Global Administrator: Entra ID impide borrar la última cuenta con este rol desde el propio Entra ID, pero nada impide que se deshabilite o elimine en local si hay sincronización con on-premises.
- Desastres naturales o cortes de red que dejan inutilizados los métodos de autenticación habituales.
- PIM mal configurado: todos los roles de Global Administrator están como «Eligible» (no activos), la activación requiere aprobación… y no queda ningún aprobador activo en el directorio. Resultado: nadie puede aprobar nada y la administración del tenant queda bloqueada.
En cualquiera de estos casos, sin una cuentas break glass en Entra ID correctamente configurada, la única salida es abrir un ticket de soporte con Microsoft y esperar, con la incertidumbre añadida de tener que demostrar la propiedad del tenant.
Buenas prácticas recomendadas por Microsoft
Esto es lo que Microsoft recomienda actualmente para configurar y mantener estas cuentas:
- Ten al menos dos cuentas: Una sola cuenta break glass es un punto único de fallo. Microsoft recomienda un mínimo de dos, para tener redundancia si una queda inaccesible (contraseña olvidada, token perdido, etc.).
- Cuentas Cloud-only, nunca federadas: Deben ser cuentas creadas directamente en el dominio *.onmicrosoft.com, sin sincronización desde on-premises ni dependencia de ningún proveedor de identidad externo. Si tu federación se cae, no quieres que tu plan B dependa de la misma pieza rota.
- Autenticación passwordless y resistente al phishing: El método recomendado hoy en día ya no es «contraseña larga + SMS», sino métodos passwordless resistentes a phishing:
- Passkey (FIDO2) — opción recomendada por Microsoft.
- Autenticación basada en certificados, si ya dispones de una PKI en la organización.
- Es clave que el método de autenticación de las cuentas break glass sea distinto al que usan tus administradores habituales. Si tus admins normales usan Microsoft Authenticator, usa una llave FIDO2 para las cuentas de emergencia; así un fallo o compromiso de un método no afecta al otro.
- No las ates a ninguna persona ni dispositivo personal: No deben depender del móvil, del token o de ningún credential de un empleado concreto. Si esa persona está de vacaciones, ha cambiado de número o ha dejado la empresa, tu emergencia se convierte en una emergencia dentro de la emergencia.
- Excluidas de Conditional Access que bloquee o restrinja el acceso: Deben quedar excluidas de cualquier política de Conditional Access que pueda bloquear el inicio de sesión (MFA obligatoria, dispositivo compliant, ubicaciones, etc.). El método de autenticación resistente a phishing ya protege la cuenta; una política enforced podría dejarte fuera justo en el escenario para el que existe la cuenta. Las políticas en modo report-only no bloquean, así que no requieren exclusión. La práctica recomendada es crear un grupo de seguridad dedicado (p. ej. EmergencyAccess) y excluir ese grupo de las políticas que puedan bloquear el acceso.
- Rol de Global Administrator activo y permanente en PIM: Si usas Privileged Identity Management, la asignación del rol Global Administrator para estas cuentas debe ser activa y permanente, no «eligible». No tiene sentido que tu cuenta de emergencia necesite activar un rol para poder usarse.
- Sin caducidad ni limpieza automática: Estas cuentas no deben caducar o quedar sujetos a procesos automáticos de limpieza por inactividad. Es normal que estas cuentas no se usen durante meses.
- Estación de trabajo dedicada: Idealmente, el acceso a estas cuentas se realiza desde un dispositivo dedicado y controlado, tipo Privileged Access Workstation (PAW), para reducir la superficie de ataque.
- Almacenamiento seguro de credenciales: Guarda las credenciales en cajas fuertes ignífugas, en ubicaciones físicas separadas, accesibles solo para el personal autorizado. Si usas TOTP como parte del proceso, guarda también el seed/QR junto con las credenciales.
- Sin licencia (por defecto): No necesitan licencia para funcionar como cuenta de emergencia. Si necesitas que reciban notificaciones por correo, puedes configurar métodos alternativos de notificación sin asignarles buzón.
- Monitorización y alertado de cada uso: Toda actividad de estas cuentas —inicios de sesión y acciones administrativas— debe generar una alerta. El objetivo no es prevenir su uso, sino detectarlo en el momento en que ocurre (lo veremos en el laboratorio).
- Validación periódica (drills): Como mínimo cada 90 días, y también tras cambios relevantes de personal de IT o del propio tenant:
- Verifica que las cuentas pueden iniciar sesión y realizar tareas administrativas.
- Revisa la lista de personas autorizadas a usarlas.
- Confirma que las alertas de monitorización se disparan correctamente.
- Cambia las combinaciones de las cajas fuertes tras cualquier baja de personal con acceso.
- Validación posrt-morten tras cada uso: Cada vez que se dispare una alerta, hay que conservar los logs y revisar si el uso fue un drill planificado, una emergencia real o un uso no autorizado, y qué acciones se realizaron con la cuenta.
Laboratorio: monitorizando la actividad de una cuenta break glass
Vamos a montar un sistema básico de detección: cada vez que una de nuestras cuentas break glass inicie sesión, queremos recibir una alerta por correo casi en tiempo real.
Requisitos previos
- Un tenant de Entra ID con, al menos, una cuenta break glass ya creada (Global Administrator, cloud-only, con passkey/FIDO2 configurado).
- Una suscripción de Azure con un Log Analytics Workspace.
- Los Sign-in logs de Entra ID enviados a ese workspace (Entra admin center → Monitoring → Diagnostic settings → enviar categoría SignInLogs al Log Analytics Workspace).
Envío de los registros de inicio de sesión de Microsoft Entra a Azure Monitor
Vamos a usar diagnostics settings de Microsoft Entra ID para integrar los registros con Azure Monitor para que la actividad de inicio de sesión y demás información de auditoría de los cambios en el tenant se puedan analizar junto con otros datos de Azure.
Creación de un área de trabajo de Log Analytics
Envío de registros a Azure Monitor
Obtención del ID de objeto de cuenta de acceso de emergencia
Para ello, accederemos al panel de administración de Entra ID y en el panel de usuarios buscaremos nuestra cuenta de acceso de emergencia. Accederemos a su ficha y anotaremos el atributo Object ID:
Este proceso habrá que hacerlo con la segunda cuenta de acceso de emergencia.
Creación de una regla de alerta
A continuación, crearemos una regla de alerta, de modo, que cuando se cree un registro dentro de nuestro espacio de trabajo de log Analytics, que haga referencia a cualquiera de nuestras cuentas de acceso de emergencia se dispare una alerta.
Probando nuestro laboratorio
A continuación, generaremos actividad sobre una de nuestras cuentas de emergencia, por ejemplo, iniciando sesión en ella y comprobaremos como la alerta se dispara:
Resumen
Las cuentas break glass en Entra ID no son «una cuenta más de admin con contraseña guardada en un Excel». Son una pieza crítica de tu estrategia de resiliencia de identidad, y como tal necesitan diseño (cloud-only, autenticación independiente y resistente a phishing, exclusión de Conditional Access), disciplina operativa (validación cada 90 días, credenciales bajo llave) y, sobre todo, visibilidad: si no monitorizas cuándo se usan, no sabrás si fue un drill, una emergencia real… o un incidente de seguridad.
Fuentes
- Microsoft Learn — Manage emergency access accounts in Microsoft Entra ID (documentación oficial; base de las buenas prácticas, la checklist de security guardrails y las consultas KQL del laboratorio).
- Microsoft Learn — Plan a Conditional Access deployment
- Microsoft Learn — Create a resilient access control management strategy
Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.