¿Qué es una cuenta Break Glass?

Una cuenta Break Glass, denominada por Microsoft cuenta de acceso de emergencia, es una identidad administrativa excepcional que permite recuperar el control de un tenant de Microsoft Entra ID cuando los mecanismos normales de autenticación o administración han dejado de funcionar.

El término procede de la expresión inglesa “break glass in case of emergency”: romper el cristal únicamente cuando ocurre una emergencia.

Microsoft recomienda disponer de dos o más cuentas de acceso de emergencia, no solamente una, para evitar que la propia cuenta de recuperación se convierta en un único punto de fallo.

1. El problema fundamental que resuelve

Partamos de una necesidad básica:

Una organización debe poder administrar su entorno incluso cuando su sistema normal de acceso esté averiado.

Un tenant suele depender de varios componentes:

Administrador
    ↓
Sistema de identidad
    ↓
Métodos de autenticación
    ↓
Acceso condicional
    ↓
Privileged Identity Management
    ↓
Microsoft Entra ID

Cada componente añade seguridad, pero también introduce una posible dependencia.

Por ejemplo:

• El sistema habitual de autenticación podría no estar disponible.
• La federación del dominio podría fallar.
• El servicio de autenticación multifactor podría sufrir una interrupción.
• Una política de acceso condicional podría estar mal configurada.
• Todos los administradores podrían quedar bloqueados.
• Privileged Identity Management podría exigir una aprobación que nadie puede conceder.
• El último administrador operativo podría abandonar la organización.
• La red corporativa o los dispositivos administrados podrían no estar disponibles.

Cuando varias de estas dependencias fallan, puede producirse un bloqueo administrativo completo del tenant.

La cuenta Break Glass proporciona una ruta de acceso alternativa:

Cuenta de emergencia
        ↓
Autenticación directa en Microsoft Entra ID
        ↓
Rol Administrador global activo
        ↓
Recuperación del tenant

2. Definición desde primeros principios

Una cuenta Break Glass debe cumplir cuatro propiedades fundamentales.

Independencia

No debe depender de los mismos sistemas que podrían provocar el bloqueo.

Por ello, debería ser:

• una cuenta creada directamente en Microsoft Entra ID;
• una cuenta solo en la nube;
• una cuenta con un dominio tenant.onmicrosoft.com;
• una cuenta no sincronizada desde Active Directory local;
• una cuenta no dependiente de la federación del dominio corporativo;
• una cuenta con métodos de autenticación independientes de los utilizados habitualmente.

El objetivo es que pueda autenticarse directamente contra Microsoft Entra ID aunque fallen otros componentes de identidad, sincronización o autenticación.

Autoridad suficiente

La cuenta debe tener permisos suficientes para reparar el problema.

Estas cuentas deben disponer del rol:

Administrador global

Además, si se utiliza Privileged Identity Management, el rol debería estar asignado como:

Activo y permanente

No debería ser una asignación elegible que requiera activación, autenticación adicional, aprobación o justificación, porque cualquiera de esas dependencias podría no estar disponible durante la emergencia.

Disponibilidad

La cuenta debe poder utilizarse cuando todo lo demás falla.

Eso implica que:

• sus credenciales no deben expirar inesperadamente;
• el método de autenticación no debe quedar eliminado por falta de uso;
• no debe depender del teléfono personal de un único administrador;
• las credenciales deben estar disponibles para varias personas autorizadas;
• debe existir un procedimiento documentado de acceso;
• los elementos físicos necesarios deben estar localizables y en buen estado.

Uso excepcional

No es una cuenta administrativa ordinaria.

No debe utilizarse para:

• administrar usuarios diariamente;
• conectarse habitualmente a servicios de Microsoft 365;
• ejecutar scripts periódicos;
• consultar informes;
• navegar por Internet;
• recibir correo;
• registrarse en aplicaciones;
• realizar cambios planificados normales.

Su uso debe limitarse a:

1. emergencias reales;
2. simulacros controlados;
3. validaciones periódicas.

3. ¿Cuándo se utilizaría?

Fallo del sistema habitual de autenticación

Los administradores no pueden iniciar sesión porque el sistema utilizado normalmente para validar su identidad está fuera de servicio o presenta errores.

La cuenta de emergencia, al autenticarse directamente contra Microsoft Entra ID, permite recuperar el acceso administrativo.

Fallo de la federación

El dominio corporativo está federado y el proceso de redirección o autenticación federada no funciona correctamente.

Una cuenta bajo el dominio onmicrosoft.com, no federada, puede iniciar sesión directamente contra Microsoft Entra ID.

Fallo del método MFA habitual

Los administradores dependen de un método que no está disponible, como:

• una aplicación móvil;
• telefonía;
• SMS;
• servicios externos;
• certificados no accesibles;
• dispositivos corporativos.

La cuenta Break Glass utiliza un método independiente y resistente a la suplantación de identidad.

Error en acceso condicional

Una nueva política podría bloquear accidentalmente:

• a todos los administradores;
• todas las ubicaciones;
• todos los dispositivos;
• determinados clientes o aplicaciones;
• todos los métodos de autenticación disponibles;
• el acceso desde fuera de la red corporativa.

La cuenta de emergencia debe estar excluida de las políticas que puedan bloquear o restringir su inicio de sesión.

Bloqueo producido por Privileged Identity Management

Todos los roles administrativos podrían estar configurados como elegibles, pero:

• no hay aprobadores disponibles;
• los aprobadores fueron eliminados;
• la activación requiere un control que no funciona;
• el servicio necesario para la activación no está accesible.

La cuenta Break Glass conserva permanentemente activo el rol de Administrador global.

Incidente grave o desastre

También puede ser necesaria cuando no están disponibles:

• la red corporativa;
• los dispositivos habituales;
• la telefonía;
• las instalaciones;
• los sistemas de sincronización;
• el personal que administra normalmente el servicio.

4. Diseño recomendado

Una implementación conceptual adecuada sería:

Tenant Microsoft Entra ID
│
├── Administradores normales
│   ├── Identidades nominativas
│   ├── MFA
│   ├── Acceso condicional
│   ├── Dispositivos administrados
│   └── Privileged Identity Management
│
└── Cuentas de emergencia
    ├── cuenta-emergencia-01@tenant.onmicrosoft.com
    └── cuenta-emergencia-02@tenant.onmicrosoft.com
        ├── Solo en la nube
        ├── No sincronizadas
        ├── No federadas
        ├── Administrador global activo
        ├── Autenticación independiente
        ├── Excluidas de políticas bloqueantes
        ├── Credenciales custodiadas
        └── Actividad monitorizada

Los nombres anteriores son ejemplos conceptuales.

Desde el punto de vista de seguridad, puede no ser conveniente utilizar nombres demasiado evidentes como:

breakglass@
emergencyadmin@
adminemergencia@

Un nombre fácilmente identificable puede facilitar a un atacante la localización de una cuenta altamente privilegiada.

5. Autenticación de la cuenta

La autenticación debe ser:

• fuerte;
• independiente;
• resistente al phishing;
• utilizable durante una emergencia;
• verificable periódicamente.

Entre los métodos adecuados pueden encontrarse:

• claves de seguridad FIDO2;
• passkeys asociadas a dispositivos o llaves físicas;
• autenticación basada en certificados, cuando exista una infraestructura adecuada.

La cuenta de emergencia debería utilizar un mecanismo diferente del utilizado por las cuentas administrativas normales.

Por ejemplo:

Administradores normales → Método corporativo habitual
Cuentas Break Glass      → Claves FIDO2 custodiadas

Así, el fallo del método normal de autenticación no afecta también a la vía de recuperación.

Excluir una cuenta de determinadas políticas de acceso condicional no significa dejarla protegida únicamente mediante una contraseña débil.

La exclusión reduce dependencias que podrían impedir el acceso, pero la autenticación debe continuar siendo robusta.

6. Relación con acceso condicional

Las cuentas de emergencia deben excluirse de las políticas de acceso condicional que puedan bloquear o restringir su inicio de sesión.

Entre otras:

• exigir dispositivo compatible;
• exigir dispositivo híbrido unido;
• limitar el acceso a una red corporativa;
• bloquear países o ubicaciones;
• exigir un método de autenticación que pudiera no estar disponible;
• exigir términos de uso;
• bloquear determinados tipos de dispositivo;
• exigir un nivel de riesgo concreto;
• bloquear por riesgo de usuario;
• bloquear por riesgo de inicio de sesión;
• exigir controles externos;
• restringir clientes o plataformas;
• limitar el acceso a rangos de direcciones IP concretos.

Una práctica habitual consiste en crear un grupo de seguridad específico para las cuentas de acceso de emergencia y excluirlo de las políticas que podrían impedir su utilización.

Las políticas configuradas en modo Solo informe no bloquean el inicio de sesión y, por tanto, no requieren la misma exclusión operativa.

El principio fundamental es:

Ningún control diseñado para proteger el acceso ordinario debe poder eliminar también la última vía de recuperación administrativa.

Las exclusiones deben documentarse y revisarse. No debería excluirse a estas cuentas de controles que no interfieran con su capacidad de recuperación, especialmente los relacionados con auditoría, registro y monitorización.

7. ¿No se convierte en una puerta trasera?

Potencialmente sí. Esa es la principal tensión de diseño.

Una cuenta Break Glass combina:

Privilegios máximos
+
Menos dependencias de acceso
+
Uso infrecuente

Por ello, puede ser un objetivo muy valioso para un atacante.

La solución no consiste en aplicarle exactamente todas las mismas restricciones que al resto de cuentas, porque entonces dejaría de cumplir su función.

La solución consiste en aplicar controles compensatorios:

• autenticación resistente al phishing;
• credenciales almacenadas de forma segura;
• custodia física de las claves;
• separación de responsabilidades;
• acceso limitado a personal expresamente autorizado;
• uso desde estaciones de trabajo administrativas seguras;
• alerta ante cualquier inicio de sesión;
• revisión de todas las operaciones realizadas;
• pruebas periódicas;
• procedimiento formal de autorización;
• rotación de credenciales cuando sea necesario;
• actualización de los custodios cuando cambia el personal;
• revisión de pertenencias, roles y exclusiones.

La cuenta debe estar disponible, pero altamente vigilada.

8. Custodia de las credenciales

Las credenciales de una cuenta Break Glass no deberían depender de una sola persona.

Un modelo de custodia puede incluir:

• almacenamiento de las claves físicas en una caja fuerte;
• sobres de seguridad o mecanismos equivalentes;
• custodia separada de la contraseña y del segundo factor;
• registro de acceso a las credenciales;
• autorización de dos personas para su retirada;
• inventario de llaves y dispositivos;
• copias de respaldo almacenadas en ubicaciones diferentes;
• procedimiento de devolución después de cada uso.

Debe evitarse:

• guardar la contraseña en un documento compartido sin protección;
• utilizar el gestor de contraseñas habitual si este pudiera quedar inaccesible;
• vincular la cuenta al teléfono personal de una única persona;
• dejar las claves conectadas permanentemente a un equipo;
• compartir las credenciales mediante correo electrónico;
• mantener copias no controladas.

El procedimiento debe equilibrar dos necesidades:

Acceso rápido durante una emergencia
+
Protección frente a accesos no autorizados

9. Monitorización

Cualquier inicio de sesión de una cuenta Break Glass debe considerarse un evento crítico.

El modelo de monitorización debería ser:

Inicio de sesión
      ↓
Alerta inmediata
      ↓
Notificación al equipo de seguridad
      ↓
Validación de la autorización
      ↓
Revisión de acciones administrativas
      ↓
Informe posterior al incidente

La monitorización debería cubrir:

• inicios de sesión correctos;
• intentos de inicio de sesión fallidos;
• cambios de contraseña;
• registro o eliminación de métodos de autenticación;
• asignación o retirada de roles;
• cambios de pertenencia a grupos;
• modificación de políticas de acceso condicional;
• deshabilitación de la cuenta;
• modificación de propiedades;
• creación de credenciales o secretos;
• operaciones administrativas realizadas durante la sesión.

Puede realizarse mediante:

• registros de inicio de sesión de Microsoft Entra ID;
• registros de auditoría;
• Azure Monitor;
• Microsoft Sentinel;
• otra plataforma SIEM;
• sistemas de gestión de alertas e incidentes.

Tras cada utilización debe comprobarse si se trató de:

• una validación planificada;
• una emergencia real;
• un uso erróneo;
• un intento de acceso;
• un acceso no autorizado.

Una alerta sobre una cuenta Break Glass no debería perderse entre alertas administrativas ordinarias. Debe tener una prioridad alta y destinatarios claramente definidos.

10. Validación periódica

Una cuenta de emergencia que nunca se prueba puede no funcionar cuando sea necesaria.

Puede haber ocurrido que:

• la clave FIDO2 esté dañada;
• la batería o el dispositivo necesario no funcione;
• la política de acceso condicional ya no la excluya;
• la cuenta esté deshabilitada;
• la contraseña haya sido modificada;
• las credenciales no estén disponibles;
• se haya aplicado una política nueva;
• el rol haya sido retirado;
• el procedimiento esté desactualizado;
• las personas autorizadas hayan cambiado;
• las alertas no se estén generando;
• la ubicación física de las claves haya cambiado;
• el navegador o dispositivo utilizado para la prueba no sea compatible.

La validación debe realizarse periódicamente y también después de cambios relevantes en:

• políticas de acceso condicional;
• métodos de autenticación;
• roles administrativos;
• dominios y federación;
• personal autorizado;
• sistemas de monitorización;
• licencias;
• procedimientos de emergencia.

La prueba no debería limitarse a comprobar la contraseña. Debe verificar:

1. que la cuenta está habilitada;
2. que puede autenticarse;
3. que el método de autenticación funciona;
4. que puede acceder al centro de administración;
5. que conserva el rol necesario;
6. que no está bloqueada por acceso condicional;
7. que puede ejecutar una acción administrativa controlada;
8. que se genera la alerta correspondiente;
9. que la alerta llega a los destinatarios previstos;
10. que las credenciales siguen bajo la custodia correcta;
11. que el procedimiento está actualizado;
12. que el uso queda registrado en auditoría.

Después de la prueba debe documentarse:

• fecha;
• participantes;
• cuenta utilizada;
• resultado;
• alertas recibidas;
• incidencias detectadas;
• medidas correctivas;
• fecha prevista para la siguiente revisión.

11. Diferencia frente a una cuenta administrativa normal

12. Qué no debe hacerse

Una cuenta Break Glass no debería:

• sincronizarse desde Active Directory local;
• utilizar un dominio federado como única identidad;
• depender de un único dispositivo;
• tener una contraseña conocida por muchas personas;
• utilizarse para operaciones diarias;
• tener buzón de correo para uso normal;
• emplearse para automatizaciones;
• tener credenciales almacenadas en scripts;
• estar vinculada a aplicaciones;
• utilizar autenticación basada únicamente en SMS;
• carecer de alertas;
• quedar sin probar durante largos periodos;
• depender de una aprobación de PIM;
• estar sujeta a una política que pueda bloquearla;
• quedar fuera de los registros de auditoría;
• ser la única cuenta de emergencia del tenant.

13. Qué debe hacerse después de utilizarla

Tras utilizar una cuenta Break Glass en una emergencia real deben realizarse varias acciones.

Documentar el motivo

Debe quedar registrado:

• qué ocurrió;
• quién autorizó el uso;
• quién accedió;
• a qué hora;
• desde qué dispositivo;
• qué acciones se realizaron;
• cuándo terminó la intervención.

Revisar las acciones

Deben analizarse los registros de:

• inicio de sesión;
• auditoría;
• cambios de configuración;
• roles;
• acceso condicional;
• métodos de autenticación.

Recuperar el funcionamiento normal

La cuenta de emergencia debe utilizarse únicamente para reparar el acceso habitual, no para mantener indefinidamente la operación administrativa.

Proteger nuevamente la cuenta

Después del incidente puede ser necesario:

• cambiar la contraseña;
• reemplazar o volver a registrar las claves;
• revisar los métodos de autenticación;
• comprobar los roles;
• revisar las exclusiones;
• actualizar la custodia;
• verificar las alertas.

Realizar una revisión posterior

Debe analizarse por qué fue necesario utilizarla y qué medidas evitarían que la misma situación se repitiera.

Conclusión

Una cuenta Break Glass no es simplemente otro Administrador global.

Es un mecanismo de continuidad y recuperación del control administrativo diseñado para sobrevivir al fallo de los sistemas de identidad, autenticación y autorización utilizados normalmente.

Su diseño puede resumirse de esta forma:

Independencia
+ privilegios suficientes
+ autenticación fuerte
+ custodia segura
+ monitorización inmediata
+ pruebas periódicas
= acceso administrativo de emergencia

Los requisitos más importantes son que estas cuentas no dependan de:

• Active Directory local;
• los sistemas de sincronización;
• la federación del dominio corporativo;
• el método de autenticación utilizado habitualmente;
• un único dispositivo;
• una única persona;
• Privileged Identity Management con aprobación;
• políticas de acceso condicional que puedan bloquearlas.

Aunque coloquialmente se hable de “la cuenta Break Glass”, la práctica recomendada es mantener al menos dos cuentas de acceso de emergencia.

La idea fundamental es sencilla:

Cuando todos los mecanismos normales de acceso fallan, debe seguir existiendo una vía segura, independiente, controlada y comprobada para recuperar el tenant.