Una cuenta break-glass (o credencial de emergencia) es el último recurso para recuperar acceso administrativo cuando el acceso normal está bloqueado: IdP caído, MFA corporativo indisponible, políticas mal aplicadas o un incidente que obliga a aislar sistemas.
El matiz importante es operativo: una break-glass no es “otra cuenta admin”. Es una excepción deliberada al flujo habitual (SSO, MFA centralizado, workflows de aprobación) y por eso mismo requiere controles distintos y una disciplina más estricta. Si se deja vivir como una cuenta más, se convierte en un bypass estable a todo lo que cuesta mantener.
Qué es realmente una break-glass (y por qué existe)
En empresas con SSO, políticas condicionales y administración delegada, es relativamente fácil construir un castillo… y también bloquearte dentro. He visto despliegues donde un cambio de política (por ejemplo, exigir un método de MFA que el equipo no puede registrar por un fallo del proveedor) deja a operaciones sin capacidad de revertir. La break-glass existe para ese tipo de escenario: restaurar el control sin depender del sistema que se acaba de romper.
También existe por presión de continuidad: durante una respuesta a incidentes puede ser necesario acceder a consola o a privilegios elevados cuando el IdP está aislado por contención, o cuando el canal habitual de aprobaciones se congela para frenar el impacto. En esos minutos, una credencial de emergencia bien diseñada reduce el “tiempo a recuperar” y evita decisiones improvisadas (como compartir credenciales por chat) que luego son imposibles de auditar.
El riesgo es que su propósito es excepcional pero su existencia es permanente. Si nadie define cuándo se usa, cómo se autoriza y qué evidencia deja, la “cuenta de emergencia” acaba siendo “la cuenta cómoda”. Ese cambio cultural sucede más rápido de lo que parece, especialmente en entornos con guardias, presión de SLA y rotación de personal.
Qué salió mal en casos de abuso: patrones que se repiten
Los abusos rara vez empiezan como un ataque espectacular. Empiezan con un atajo: “solo hoy entro con la break-glass porque el SSO va lento” o “necesito saltarme el approval para aplicar un hotfix”. Cuando eso se normaliza, la cuenta deja de ser un último recurso y se convierte en una ruta paralela sin fricción, y ahí aparece el problema real: pérdida de trazabilidad y control efectivo.
En incidentes internos (malicia o negligencia), la break-glass es atractiva por dos razones: suele tener privilegios amplios y suele estar fuera de los mecanismos que disparan alertas (por ejemplo, fuera del IdP, fuera del PAM, fuera del flujo de tickets). He visto escenarios donde alguien usa la break-glass para elevar permisos, crear una nueva identidad persistente y luego “volver a cerrar” la puerta; el daño no es el acceso puntual, sino la persistencia plantada.
- Credenciales compartidas entre varias personas
- Uso sin registro formal (sin ticket, sin aprobación, sin justificación)
- Exención silenciosa de MFA o factores débiles “por emergencia”
Cuando una break-glass es compartida, cualquier auditoría posterior se degrada a suposiciones: se puede saber qué hizo la cuenta, pero no quién la operó. Y en la práctica esto frena decisiones duras: si no puedes atribuir, es difícil corregir comportamientos o cerrar brechas culturales.
El uso sin registro formal suele ser el preludio de la dependencia. La organización se acostumbra a resolver rápido, pero el coste llega después: incidentes sin timeline confiable, incapacidad de demostrar control ante auditoría, y un “shadow admin” que nadie quiere tocar porque “si la rompes, nos quedamos fuera”.
La exención de MFA es el punto de no retorno. Muchas brechas modernas no requieren sofisticación si existe una credencial de alto privilegio con autenticación débil. Y aunque tenga MFA, si el segundo factor vive en el mismo sitio que el password (un gestor compartido sin controles, una bóveda sin separación de funciones), el riesgo vuelve a ser sistémico.
Señales tempranas de que tu break-glass ya es una puerta trasera
La mayoría de organizaciones no “pierden” una break-glass en un día: la degradación es gradual. La primera señal suele ser social, no técnica: cuando alguien menciona la cuenta como solución estándar (“si falla, usamos la de emergencia”) en lugar de como excepción que se teme usar.
La segunda señal es operacional: si se usa para tareas repetibles (altas de usuarios, cambios rutinarios de IAM, despliegues), significa que el modelo de acceso normal está fallando o que es demasiado friccionante. Y entonces el equipo empieza a optimizar alrededor de la excepción, no alrededor del control.
- Actividad fuera de ventanas de emergencia
- Inicios de sesión desde ubicaciones o redes “improbables” para un rescate
- Cambios que aumentan superficie: nuevas keys, nuevos roles, desactivación de logs
La actividad fuera de una ventana de emergencia no siempre es malicia; muchas veces es deuda operativa. Pero debe disparar revisión obligatoria, porque si no se corrige, la excepción se normaliza. Un criterio simple es exigir que cada uso tenga una “historia” verificable: qué se rompió, qué se hizo, cómo se restauró el flujo normal y qué acción se tomó para que no se repita.
Ubicaciones o redes improbables suelen indicar que la credencial está más difundida de lo que crees o que alguien la está usando desde un contexto no controlado (dispositivo personal, red doméstica, salto por VPN de terceros). En emergencias reales, el patrón de acceso suele ser muy consistente (equipos concretos, IPs conocidas, bastiones), y por eso las desviaciones son una señal potente.
Y los cambios que aumentan superficie (crear access keys, elevar privilegios, tocar logging) son el verdadero foco: una break-glass debería usarse para restaurar control, no para debilitar el sistema. Si ocurre, es un indicador de que tu “rescate” se está usando para construir persistencia.
Cómo hacerlo en la práctica: guardrails que sí funcionan (con ejemplo en AWS)
Operar una break-glass bien no es ponerla en una bóveda y olvidarla; es diseñar un procedimiento completo: creación, custodia, activación, evidencias, y cierre. En cloud, además, necesitas asumir que el control real es quién puede usarla y qué queda registrado, porque el perímetro es difuso.
En AWS, un patrón habitual es tener un usuario o rol de emergencia con privilegios altos, protegido por MFA, y con credenciales guardadas en una bóveda corporativa con control de acceso y logging. Lo importante: no depender exclusivamente del IdP si el IdP es el punto de fallo que estás mitigando, pero sí obligar a que el uso deje rastro en CloudTrail y en el sistema de gestión de secretos.
Acciones concretas que puedes ejecutar:
- Crear una identidad de emergencia separada y mínima
- Configurar MFA fuerte y custodia con dual control
- Forzar trazabilidad y revisión post-uso
Crear una identidad separada significa que no debe compartir email, dispositivo, ni ciclo de vida con administradores normales. En AWS, si usas usuario IAM, evita access keys permanentes salvo que tengas una razón extremadamente justificada; prioriza acceso interactivo con MFA. Si usas rol, define claramente el camino de asunción y qué entidad puede asumirlo en emergencia (y que ese camino también esté gobernado).
Para MFA y custodia, funciona el enfoque de dual control: que nadie pueda extraer y usar la credencial sin que otra persona lo habilite. En la práctica, esto se implementa con una bóveda que registre quién accede, aprobación de dos personas (o dos grupos) y tiempos de expiración de acceso a la credencial. Si la organización no puede sostener dual control 24/7, al menos exige aprobación explícita y registra el motivo, porque lo que no se registra acaba siendo costumbre.
Para trazabilidad, en AWS valida que CloudTrail está habilitado en todas las regiones, que los logs se envían a un bucket con protección contra borrado (por ejemplo, políticas que impidan DeleteObject salvo break-glass específica, y aun así con alarmas) y que existe detección de uso: alertas por ConsoleLogin del usuario break-glass o por AssumeRole del rol de emergencia. La verificación práctica aquí no es “creo que está”: es revisar eventos recientes, simular un login controlado y confirmar que la alerta llega al canal correcto (SOC/on-call) con contexto suficiente.
Un anti-patrón muy común es “guardar el password en un documento cifrado en un drive compartido”. Aunque haya buena intención, en la práctica no hay separación de funciones, no hay auditoría útil y la distribución se vuelve incontrolable. La consecuencia típica es que, tras una rotación de personal o un incidente, ya no sabes quién sigue teniendo acceso.
Recomendaciones para entornos corporativos
La break-glass no es negociable en organizaciones reales: los sistemas fallan, los proveedores caen y las políticas mal aplicadas existen. Lo que sí es negociable (y crítico) es convertir esa necesidad en un mecanismo operativo controlado, con un “circuito de uso” que sea más estricto que el acceso normal, no más laxo.
Si hoy tu cuenta de emergencia se usa para trabajo rutinario, si sus credenciales se comparten sin atribución o si no puedes demostrar (con logs y evidencias) quién la usó, cuándo, por qué y qué cambió, entonces ya no tienes una break-glass: tienes una puerta trasera. Volver a un estado sano requiere disciplina: custodiar con control, alertar cada uso y obligar a una revisión post-uso que cierre el bucle y evite recurrencia.
Cuando se opera bien, la cuenta de emergencia cumple su función sin erosionar el modelo de seguridad. Cuando se opera “para salir del paso”, se convierte en el bypass preferido y, tarde o temprano, en el punto más débil de todo el entorno.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.