Cuentas de Acceso de Emergencia Break Glass Entra ID: Ausentes, Sin Supervisar, Sin Excluir

Qué es una cuenta de acceso de emergencia Break Glass Entra ID

Una cuenta de acceso de emergencia break-glass Entra ID es una cuenta de Global Administrator mantenida en reserva para el único escenario que todos los demás caminos de administración están diseñados para evitar: el bloqueo total. La propia guía de Microsoft enumera las situaciones para las que existen estas cuentas — una interrupción de federación que deja sin acceso a todos los admins sincronizados, un fallo de dispositivo o servicio MFA que bloquea la activación de un rol, la salida del último Global Administrator activo, un desastre natural que derriba las redes telefónicas, o un bloqueo de aprobación en Privileged Identity Management (PIM) en el que cada asignación elegible de Global Administrator o Privileged Role Administrator necesita un aprobador y ninguno está activo. Para una visión más amplia de cómo las asignaciones PIM y el número de Global Admins permanentes elevan el riesgo del tenant, ver Acceso privilegiado Azure: roles, PIM y administración permanente.

Ninguno de estos casos es exótico. Son los casos límite específicos que "simplemente usa MFA" y "simplemente usa PIM" no cubren, porque el MFA y el PIM son precisamente lo que puede fallar.

La brecha de gobernanza que trata este artículo no es el concepto — la mayoría de los equipos de seguridad ya han oído hablar de las cuentas break-glass. Es que el catálogo de auditoría de Microsoft rastrea tres formas distintas y comunes en que el control falla en tenants reales:

1. No existe ninguna cuenta de acceso de emergencia (PA_NO_EMERGENCY_ACCOUNTS) — el caso base, y según el catálogo de EtcSec la severidad crítica por defecto: cero cobertura break-glass significa cero camino de recuperación si falla el camino de administración principal.
2. La cuenta existe pero no está excluida del Conditional Access (PA_EMERGENCY_NO_EXCLUSION / CA_NO_BREAK_GLASS_EXCLUSION) — de modo que la política pensada para proteger el tenant es exactamente lo que bloquea la cuenta de recuperación durante la emergencia para la que fue creada.
3. La cuenta existe y está excluida, pero nadie la supervisa (PA_EMERGENCY_NO_MONITORING) — de modo que un evento de inicio de sesión que debería activar todas las alarmas (una cuenta Global Admin fuera de los controles CA normales acaba de autenticarse) no genera ninguna alerta.

Una cuarta brecha, relacionada, aparece en la misma familia del catálogo: credenciales obsoletas (PA_EMERGENCY_CREDENTIAL_STALE) — una cuenta de emergencia cuyo método de autenticación o dispositivo no se ha validado en tanto tiempo que nadie sabe realmente si todavía funciona.

Cómo ocurre la brecha en la práctica

Las cuentas break-glass normalmente se crean una sola vez, durante la configuración inicial del tenant o un esfuerzo de cumplimiento, y luego se dejan de lado — lo cual es precisamente el problema, porque "dejarlas de lado" juega en ambos sentidos.

Completamente ausente

Los tenants más pequeños, los tenants migrados desde un proveedor de identidad más antiguo, o los tenants que asumieron que "todos nuestros admins tienen MFA" ya contaba como cobertura, frecuentemente no tienen ninguna cuenta de acceso de emergencia dedicada. Microsoft recomienda crear dos o más cuentas solo en la nube en el dominio predeterminado *.onmicrosoft.com del tenant — no federadas, no sincronizadas desde el entorno local — precisamente para que una interrupción local o de federación no derribe también el camino de recuperación.

No excluida del Conditional Access

Este es el modo de fallo que convierte un control en una trampa. Una política CA que exige un dispositivo compatible, un método MFA específico, o bloquea por ubicación, se aplicará sin problema a la cuenta de emergencia como a cualquier otro Global Administrator — lo que significa que exactamente la política que debía proteger el tenant se convierte en la razón por la que la cuenta de emergencia no puede iniciar sesión durante la interrupción o el bloqueo para el que existe. Microsoft es explícito aquí: excluya las cuentas break-glass de cualquier política CA que bloquee o restrinja el inicio de sesión; las políticas en modo solo informe no bloquean el acceso y no necesitan la exclusión. Este es un caso específico de un patrón más amplio — ver Brechas acceso condicional Entra ID sobre cómo los errores de alcance de exclusión aparecen en las políticas en general.

No supervisada

Incluso con una cuenta correctamente creada y excluida, la mayoría de los tenants no tienen ninguna alerta sobre su uso. Una cuenta break-glass está diseñada para casi nunca iniciar sesión. Esa propiedad hace que la supervisión sea económica y de alta señal: cualquier autenticación desde ella es o un simulacro de validación programado o un incidente activo (una emergencia legítima, o un atacante que encontró y comprometió la única cuenta explícitamente excluida de la aplicación de la política). Sin una alerta permanente, esa señal es invisible hasta que alguien revisa por casualidad los registros de inicio de sesión — lo cual, para la mayoría de los tenants, es raro o nunca ocurre. Este punto ciego se suma a las brechas de señal de riesgo más amplias tratadas en Azure Identity Protection: Políticas de Riesgo.

Detección

Confirme el estado de la cobertura de cuentas de acceso de emergencia break-glass con estas verificaciones, mapeadas a las entradas del catálogo:

Construyendo la consulta de alerta de inicio de sesión

Para la verificación de supervisión en particular, el enfoque documentado por Microsoft es una regla de alerta de log personalizado de Log Analytics contra la tabla SigninLogs, indexada por el Object ID de la cuenta (que se encuentra en Entra ID → Users → [cuenta] → Object ID):

// Alert query — any sign-in from an emergency access account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Configure el valor de umbral de la alerta en 0 (mayor que), la severidad en 0 – Crítico, y adjunte un grupo de acción que envíe correo y SMS a su equipo de seguridad — porque, según la guía de Microsoft, cualquier inicio de sesión desde esta cuenta debería activar una revisión, ya sea un simulacro programado o un incidente real.

También recopile las entradas del registro de auditoría de la cuenta (no solo el registro de inicio de sesión) — los cambios de asignación de rol, los registros de credenciales y los cambios de membresía en políticas CA que afecten a la cuenta son todos eventos que merecen una alerta independientemente de la actividad de inicio de sesión. Si está construyendo este tipo de verificación como parte de una revisión más amplia del tenant en lugar de una acción puntual, Cómo auditar la seguridad de Microsoft Entra ID recorre el alcance completo de revisión en el que se encaja esto.

Remediación

1. Cree al menos dos cuentas de acceso de emergencia. Solo en la nube, dominio *.onmicrosoft.com, no federadas ni sincronizadas. La guía de Microsoft recomienda dos o más para que una sola credencial comprometida o no disponible no elimine por completo la capacidad de recuperación.
2. Use autenticación sin contraseña resistente al phishing. Passkey (FIDO2) es el método recomendado por Microsoft; la autenticación basada en certificados es la alternativa si su organización ya opera una PKI. No reutilice el método MFA que usan sus cuentas admin normales — si el push de Microsoft Authenticator es estándar para los admins, coloque la cuenta de emergencia en una llave de hardware FIDO2 en su lugar, para que una sola interrupción o clase de compromiso no elimine ambos caminos a la vez.
3. Asigne Global Administrator como permanente, activo — no elegible — en PIM. Una cuenta de emergencia bloqueada detrás de un paso de activación de PIM anula el propósito si el propio PIM es parte de la interrupción.
4. Excluya las cuentas de toda política de Conditional Access que bloquee o restrinja el inicio de sesión. Cree un grupo de seguridad dedicado (nombre de ejemplo de Microsoft: EmergencyAccess) y excluya ese grupo de las políticas aplicadas — las políticas solo informe no necesitan la exclusión ya que no pueden bloquear el acceso. Vuelva a verificar la lista de exclusión cada vez que se publique una nueva política CA.
5. Configure la supervisión de inicio de sesión antes de necesitarla. Construya la regla de alerta de Log Analytics anterior, diríjala a un grupo de acción real (correo + SMS, no una bandeja que nadie observa), y establezca la severidad en Crítica.
6. Almacene las credenciales en una ubicación segura y con acceso controlado — almacenamiento físicamente separado y a prueba de fuego para tokens de hardware o certificados CBA, accesible para más de una persona autorizada, no vinculado al dispositivo de un solo empleado.
7. Valide cada 90 días, y después de cualquier cambio en el equipo de administración. Confirme que la cuenta todavía inicia sesión correctamente bajo la configuración CA actual, confirme que la alerta todavía se activa, y confirme que la lista de usuarios autorizados está actualizada. La guía de Microsoft es explícita en que esta validación debe ocurrir al menos cada 90 días y después de cualquier cambio de personal — una cuenta de acceso de emergencia que nadie ha probado en condiciones reales de fallo no es un control funcional, es una suposición.
8. Ejecute un post-mortem en cada activación, simulacro o real, para confirmar que el uso fue autorizado y que las acciones tomadas coincidieron con el incidente.

La cobertura break-glass es una pieza de una base de hardening del tenant más amplia — ver Endurecimiento del tenant Azure: corregir defaults inseguros para las otras brechas de configuración predeterminada que vale la pena cerrar junto con esta.

Cómo lo detecta EtcSec

La auditoría de Entra ID de EtcSec verifica los tres modos de fallo tratados aquí: PA_NO_EMERGENCY_ACCOUNTS señala tenants con cero cuentas de acceso de emergencia calificadas, PA_EMERGENCY_NO_EXCLUSION (junto con CA_NO_BREAK_GLASS_EXCLUSION) señala cuentas todavía dentro del alcance de una política de Conditional Access aplicada, PA_EMERGENCY_NO_MONITORING señala cuentas sin configuración de alerta de inicio de sesión correspondiente, y PA_EMERGENCY_CREDENTIAL_STALE señala cuentas cuyas credenciales no se han validado dentro de la ventana recomendada.