Cuando un sistema crítico falla, esperar al circuito ordinario de permisos puede prolongar una incidencia. Pero mantener una cuenta de administrador compartida «por si acaso» crea el problema contrario: nadie sabe quién la usó, con qué motivo ni qué cambió. Un acceso de emergencia, también llamado break-glass, permite recuperar la operación fuera del proceso habitual si es excepcional, limitado y revisable.
La automatización y la IA pueden reunir contexto, comprobar condiciones y preparar el expediente. No deben decidir por sí solas que existe una emergencia, revelar secretos ni ejecutar cambios irreversibles. La responsabilidad técnica y de negocio sigue siendo humana.
Qué problema resuelve una cuenta break-glass
El objetivo no es disponer de una segunda vía cómoda de administración. Es contar con un mecanismo de último recurso cuando el acceso normal no funciona: caída del proveedor de identidad, indisponibilidad de la gestión de privilegios, bloqueo accidental de administradores o un incidente que exige contener un servicio.
Define qué activos lo justifican: por ejemplo, el directorio corporativo, la plataforma de copias de seguridad, un entorno de producción o una pasarela que deja sin soporte a una operación. Si un activo puede recuperarse mediante el proceso habitual dentro del impacto aceptable, quizá no necesita una excepción permanente.
Separa la emergencia del acceso privilegiado ordinario
Una cuenta break-glass no sustituye a las identidades nominales ni a la elevación temporal de privilegios. El acceso habitual debe seguir usando cuentas personales, permisos mínimos y aprobaciones según el riesgo. La cuenta de emergencia solo se activa cuando esa ruta no está disponible o no permite responder a tiempo.
- Acceso ordinario: tareas planificadas, cambios aprobados y administración diaria.
- Acceso urgente: un incidente que requiere respuesta rápida dentro del proceso de guardia.
- Acceso de emergencia: imposibilidad o fallo del mecanismo normal, con motivo, alcance y revisión obligatoria.
Diseña la activación como un expediente, no como una contraseña
Para cada uso, crea un registro antes o inmediatamente después de activar el acceso si la urgencia lo impide. Debe incluir el sistema afectado, el incidente o síntoma observado, quien solicita el uso, quien lo autoriza cuando sea viable, la hora de inicio y el objetivo concreto.
Datos mínimos que conviene capturar
- Identificador de incidencia o enlace al parte operativo.
- Activo, entorno y privilegio estrictamente necesarios.
- Motivo por el que no puede emplearse el acceso ordinario.
- Responsable técnico y responsable de la decisión.
- Ventana máxima de uso y criterio de cierre.
Un flujo puede precompletar estos campos desde la herramienta de incidencias y avisar al equipo responsable. Si se usa IA para resumir alertas o proponer una clasificación, conserva enlaces a las evidencias originales y exige confirmación humana.
Limita el alcance técnico antes de necesitarlo
Una sola cuenta con control total sobre todos los sistemas aumenta el daño posible y dificulta investigar un incidente. Diseña accesos separados por dominio crítico cuando sea razonable, con permisos limitados a la recuperación prevista. Evita que una credencial de contingencia permita modificar datos comerciales, desactivar registros o acceder a información no necesaria para restaurar el servicio.
Protege el secreto con controles independientes del proveedor de identidad que podría fallar. El método depende de la arquitectura: custodia con doble control, recuperación dividida entre responsables o un almacén de secretos con procedimiento alternativo. No publiques contraseñas, claves de recuperación ni instrucciones que permitan eludir controles.
Registra acciones y preserva evidencia
El registro de inicio de sesión por sí solo no basta. Para sistemas de mayor impacto, activa registros de sesión, comandos o cambios administrativos cuando la tecnología lo permita. Relaciona esa evidencia con el expediente de activación y conserva una línea temporal: solicitud, acceso, intervención, recuperación, cierre y revisión.
Si los registros dependen del mismo sistema afectado, envíalos también a un destino separado. La evidencia debe responder a preguntas concretas: quién accedió, durante cuánto tiempo, qué hizo, qué resultado obtuvo y qué cambios se deben revertir o regularizar.
Automatiza controles, no la excepción completa
Una automatización útil puede comprobar que el activo está en la lista aprobada, crear una ventana de uso, abrir una tarea de revisión y notificar a seguridad. También puede bloquear una segunda activación simultánea o recordar la rotación posterior. Sin embargo, no debería liberar una credencial de emergencia basándose únicamente en una alerta o en un texto generado.
La decisión humana es imprescindible cuando existen alternativas, el impacto es alto, se solicita ampliar privilegios o la intervención puede afectar a datos, clientes o terceros. KMOOPS puede ayudar a definir y automatizar controles operativos conectados con la gestión de identidades e incidencias.
La revisión posterior es parte del control
Todo uso debe terminar con una revisión en un plazo definido. Sirve para confirmar que el servicio se recuperó, identificar los cambios realizados, revocar el acceso temporal y corregir la causa que hizo necesario recurrir a la excepción.
Preguntas para el cierre
- ¿Se restauró el acceso ordinario y se eliminó cualquier elevación temporal?
- ¿Hay cambios que deben documentarse, revertirse o pasar por control de cambios?
- ¿La cuenta o secreto requiere rotación tras su uso?
- ¿La causa revela una dependencia única, una falta de monitorización o un procedimiento incompleto?
Una revisión que se retrasa indefinidamente convierte una excepción en un riesgo oculto. Configura recordatorios y escalado, pero asigna un propietario que confirme el cierre.
Prueba el procedimiento sin esperar a una incidencia
Un acceso de emergencia que nadie ha probado es una hipótesis. Realiza ejercicios controlados con un alcance acordado: simula la caída del acceso normal, comprueba quién puede activar el mecanismo, valida los registros y mide si se puede volver al estado ordinario. La prueba no debe consistir en compartir la credencial ni en deshabilitar controles en producción sin una evaluación previa.
Criterios para decidir si implantarlo
El mecanismo está justificado cuando coinciden tres factores: un activo es realmente crítico, la pérdida del acceso normal tiene un impacto que no admite espera y se puede limitar y auditar la excepción. Si falta alguno, prioriza mejorar el acceso ordinario, la redundancia o el proceso de incidencias.
Empieza por uno o dos escenarios de alto impacto, define el expediente y prueba el cierre completo. Si necesitáis revisar la arquitectura de accesos, las dependencias de identidad y los flujos de aprobación sin frenar la operación, contactad con KMOOPS.