Cuentas break-glass de Entra ID que funcionan cuando nada más lo hace

Un tenant puede bloquearse a sí mismo sin necesidad de ningún atacante. Si todas las asignaciones de Global Administrator y Privileged Role Administrator son elegibles, la activación requiere aprobación y no se ha seleccionado ningún aprobador, nadie puede aprobar nada. Los administradores activos son los aprobadores por defecto, y no hay ninguno. Dos cuentas break-glass exclusivamente en la nube, configuradas y ensayadas de antemano, son la salida.

Cuándo las necesitará

La guía de acceso de emergencia de Microsoft enumera los casos. La federación está caída porque ha fallado el host de su proveedor de identidad. Todos los administradores registraron únicamente llamadas de teléfono y SMS como MFA, y la red móvil no funciona. La última persona con acceso de Global Administrator abandona la empresa y su cuenta se deshabilita o se elimina en el entorno local, algo que Entra ID no impide.

Cree las cuentas

Cree al menos dos cuentas. Deben ser exclusivamente cloud, en el dominio *.onmicrosoft.com, sin federar y sin sincronizar desde el entorno local. Asigne a cada una el rol Global Administrator.

En Privileged Identity Management (PIM), haga que esa asignación sea activa permanente, no elegible. Los administradores del día a día deben usar acceso just-in-time, pero estas cuentas no pueden depender de un paso de activación, porque ese paso puede ser justamente lo que no esté disponible. PIM requiere Microsoft Entra ID P2 o Entra ID Governance.

Las fuentes no tratan los tenants sin PIM, así que esta parte es razonamiento propio. El ajuste de activa frente a elegible reside en PIM y allí no es aplicable. Las cuentas siguen necesitando una asignación directa y permanente de Global Administrator, por el mismo motivo: nada debería tener que activarse.

Para la autenticación, elija un método sin contraseña que cumpla el requisito de MFA:

• Passkey (FIDO2), que es el que recomienda Microsoft.
• Autenticación basada en certificados, si ya dispone de una PKI.

Utilice un método distinto del de sus administradores habituales. Si ellos usan la aplicación Microsoft Authenticator, dé a las cuentas de emergencia una llave de seguridad FIDO2. No vincule cuentas compartidas a una persona ni a un dispositivo aportado por un empleado, como un teléfono. Microsoft también permite crear cuentas de emergencia individuales para cada administrador, lo que facilita la trazabilidad de responsabilidades y permite usarlas desde ubicaciones remotas. Elija un modelo de forma deliberada.

Guarde las llaves en cajas fuertes ignífugas, en ubicaciones seguras y separadas, accesibles para las personas autorizadas a usarlas. Utilice una estación de trabajo segura designada, como una Privileged Access Workstation, siempre que alguien inicie sesión con estas cuentas.

Exclúyalas de Conditional Access

Una política aplicada que exija MFA, un dispositivo conforme u otro control puede dejar la cuenta inutilizable durante la emergencia. Lo que protege la cuenta es la credencial resistente al phishing, así que exclúyala de cualquier política que bloquee o restrinja el inicio de sesión. Conditional Access requiere Entra ID P1.

Cree un grupo de seguridad dedicado, por ejemplo EmergencyAccess, incluya en él las dos cuentas y excluya el grupo de esas políticas. Las políticas en modo solo informe no bloquean el acceso y no necesitan exclusión.

Un grupo por sí solo no basta, porque las nuevas políticas las escriben personas que quizá no recuerden que estas cuentas existen. Abra todas las políticas habilitadas y compruebe que su sección Exclude contiene el grupo. Vuelva a revisar las políticas en modo solo informe antes de que alguien las active. Añada la pregunta «¿está EmergencyAccess excluido?» a la lista de verificación de revisión de toda política nueva, y pruebe un inicio de sesión después de cada cambio significativo.

Alerte de cada inicio de sesión

Estas cuentas solo deberían iniciar sesión en simulacros y en emergencias reales, de modo que cualquier inicio de sesión merece una alerta. El ejemplo de Microsoft utiliza Azure Monitor y exige enviar antes los registros de inicio de sesión de Entra a un workspace de Log Analytics.

1. En el centro de administración de Entra, como mínimo con el rol User Administrator, vaya a Entra ID > Users, abra cada cuenta de emergencia y copie su Object ID.
2. En el portal de Azure, como mínimo con el rol Monitoring Contributor, abra Monitor > Alerts y seleccione + Create > Alert rule.
3. En la pestaña Scope, seleccione su workspace de Log Analytics.
4. En la pestaña Condition, elija Custom log search como nombre de la señal y Aggregated logs como tipo de consulta.
5. Introduzca una consulta con ambos Object ID:

SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

1. En Measurement, seleccione la medida, el tipo de agregación y la granularidad de agregación. En Split by dimensions, seleccione la columna Resource ID.
2. En Alert logic, establezca el tipo de umbral en Static, el operador en Greater than y el valor del umbral en 0. Fije la frecuencia de evaluación según la rapidez con la que quiera enterarse.
3. Dirija la alerta por correo electrónico y SMS a varios administradores, no a uno solo.

Microsoft muestra también una consulta por UserPrincipalName. Nosotros usamos el Object ID por costumbre, ya que una consulta construida sobre un nombre depende de que ese nombre no cambie. Por cada cuenta adicional, añada otra cláusula or UserId == "ObjectGuid".

Si nadie de su equipo vigila las alertas fuera del horario laboral, un servicio de monitorización gestionada puede encargarse de esa parte.

Pruébelas y revise cada uso

Valide las cuentas al menos cada 90 días. Un simulacro debe cubrir la lista de usuarios autorizados, un inicio de sesión real con la llave de seguridad y una tarea administrativa. Debe confirmar que las cuentas siguen pudiendo iniciar sesión con su configuración actual de Conditional Access, y que cada llave o certificado está presente, no ha caducado y no ha sido eliminado por una limpieza automatizada.

Cada simulacro debe activar su alerta. Repita la prueba después de cualquier cambio en el workspace o en los ajustes de diagnóstico que lo alimentan. Mantenga un registro breve:

Tras cualquier uso real, celebre un análisis posterior. Determine si el uso estaba autorizado y si las acciones realizadas fueron adecuadas. Las organizaciones reguladas pueden presentar este registro, junto con los logs y el registro de simulacros, como evidencia de que el acceso de emergencia está gobernado. Si desea una revisión externa, nuestro equipo de consultoría puede revisar la configuración.

Por dónde empezar

1. Liste sus Global Administrators en el centro de administración de Entra y compare su número con la recomendación de Microsoft de menos de cinco. Averigüe si alguna cuenta está ya destinada a emergencias.
2. Cree dos cuentas .onmicrosoft.com exclusivamente cloud con una asignación activa y permanente de Global Administrator, y registre una llave FIDO2 distinta para cada una.
3. Cree el grupo EmergencyAccess y exclúyalo de todas las políticas de Conditional Access que bloqueen o restrinjan el inicio de sesión.
4. Envíe los registros de inicio de sesión a Log Analytics y construya la regla de alerta con un umbral mayor que 0 sobre ambos Object ID.
5. Guarde las llaves en ubicaciones ignífugas separadas, nombre a los usuarios autorizados y compruebe que ninguna credencial caduca ni queda dentro del alcance de una limpieza automatizada.
6. Inicie sesión con cada cuenta, confirme que se dispara la alerta, rellene la primera fila del registro de simulacros y programe el siguiente simulacro en el calendario dentro de los próximos 90 días.