La seguridad de nuestros sistemas es un punto crítico en nuestro día a día, para ello una buena práctica es limitar al máximo las cuentas con permisos y establecer toda una serie de mecanismos para asegurar su uso (MFA, acceso condicional,etc...) Pero todo esto puede acabar provocando, aunque andemos con cuidado, que nos veamos fuera del sistema. Es por ello que es crítico crear cuentas de acceso de emergencia, vamos a ver qué características deben tener estás cuentas.
Hablaremos en este caso concretamente de Azure, pero lo podéis extrapolar a otros servicios similares, es vital evitar quedarnos sin acceso a Azure AD. Esto podría parecer a priori algo achacable solo a un administrador irresponsable, pero como veremos puede ser debido también a factores que escapan totalmente de nuestro control, es por ello la necesidad de disponer de al menos un par de estas cuentas de acceso de emergencia.
Qué son las cuentas de acceso de emergencia
Se trata de cuentas con los máximos privilegios y que no están asignadas a personas en concreto. Estas cuentas solo han de utilizarse en situaciones en las que ninguna otra cuenta de administrador pueda usarse y deben tener por lo tanto un acceso controlado y restringido.
¿Por qué son necesarias?
Algunas de las situaciones que nos pueden dejar fuera de nuestro Azure AD pueden ser:
- Tener las cuentas de usuario federadas y que este servicio esté caído. Por lo tanto al querer autenticarnos el sistema será incapaz de verificar nuestras credenciales contra el proveedor de identidad y no podremos entrar.
- Tener todas las cuentas de administrador con el MFA activado y que ninguno de los dispositivos de MFA esté disponible, que el propio servicio de Microsoft este caído o que el servicio de telefonía esté caído lo que provocaría que no podamos recibir ni sms, ni llamadas de verificación.
- Que la última persona con administrador global abandone la empresa - Cuando un usuario abandona la empresa lo habitual es dar de baja estas cuentas, aunque Azure AD impide eliminar la última cuenta de administrador global, esta misma puede ser desactivada o eliminada en el AD contra el que esté federado (no lo probéis en casa ^^) por lo que podemos quedarnos a oscuras.
- Desastres naturales o caídas generalizadas - estos pueden provocar que las redes telefónicas a través de las que verificamos MFA no estén disponibles.
Cómo deben ser las cuentas de acceso de emergencia.
No servirá de nada crear clones de nuestras cuentas de administrador global si al final las vamos a seguir ligando a factores que puedan impedirnos la autenticación de la misma manera que lo hacen con nuestras propias cuentas. Estas cuentas de acceso de emergencia deben tener unas características básicas que siempre hemos de respetar.
- Tenemos que crear 2 o más cuentas de acceso de emergencia.
- Las cuentas deben estar solo en cloud, no depender de ninguna federación con servidores o servicios on-premises.
- Estas cuentas deben usar únicamente el dominio por defecto de omicrosoft.com
- Las cuentas no se deben asociar a ningún usuario en concreto.
- Las cuentas no deben estar nunca conectadas, MFA hablando, con ningún dispositivo entregado a algún empleado que pudiera abandonar las instalaciones. Hablamos de teléfonos, tokens de hardware..
- En el caso que ligáramos nuestra cuenta, por MFA, a algún dispositivo siempre presente en la empresa, este debe tener múltiples maneras de conectarse con Azure AD. No sirve decir tengo wifi a través de 2 ISP que al final salen por el mismo tubo a la calle o que acaban en el mismo rack dependiendo de la misma fuente eléctrica..
- Como decíamos hay que crear 2 o más cuentas de acceso de emergencia, pero entre ellas no deben compartir un mismo mecanismo de autenticación. No podemos tener ambas por ejemplo bajo Azure AD MFA, ya que si este servicio falla, estamos en las mismas..
- Al menos una de estas cuentas debe no tener un MFA por vía telefónica (llamada o sms)
- Debemos excluir estas cuentas de políticas generales como la que posiblemente tengamos activada de requerir MFA para todas las cuentas de administrador
- Las contraseñas de estas cuentas no deben tener caducidad, ni entrar dentro de ningún filtro de borrado de cuentas sin uso.
- Obviamente estas cuentas deben tener asignado un rol permanente de administrador global, en este caso nada de asignárselo dinámicamente.
- Al menos una de estas cuentas debe estar excluida completamente de cualquier política de acceso condicional en Azure.
Monitorización y alertas
Una vez tenemos creadas esas cuentas y verificado que podríamos acceder en situaciones concretas, es también vital monitorizarlas y articular un sistema de alertas cuando sean utilizadas, que recordemos deber ser nunca (salvo en caso de emergencia o en tests controlados).
Debemos monitorizar cualquier login a las mismas y auditar todas las acciones que se realicen con ellas, habilitando notificaciones automáticas, en forma de email y SMS, al resto de administradores. Para todo esto usaremos el Azure Log Analytics.
Pruebas programadas
Dentro de las políticas de ciberseguridad debemos incluir el testeo periódico de estas cuentas. En estas pruebas deberemos al menos probar los siguientes puntos:
- Validar que la información para acceder a las cuentas es correcta y que a través de estos usuarios podríamos realizar las tareas administrativas necesarias.
- Revisar que las cuentas de emergencia siguen sin tener ningún sistema de verificación ligado a dispositivos personales, ni para el acceso ni para la recuperación de contraseña. En el caso que alguna de las cuentas utilicen MFA que el dispositivo de verificación en caso de ser un teléfono pueda ser capaz de recibir esa verificación a través de al menos 2 redes diferentes. (4G y WiFi por ejemplo)
- Asegurarnos que el sistema de monitorización y alerta funciona correctamente y que se nos avisa de cualquier actividad de esas cuentas.
- Revisar que los procesos de emergencia estén bien documentados y que las personas que pudieran necesitar usar estas cuentas estén al tanto de los mismos.
Conclusiones
Todo este proceso y sus requerimientos puede parecer tedioso o excesivo, pero nos asegura si lo ejecutamos y revisamos correctamente que en caso de "catástrofe" tengamos una manera de seguir operando con nuestro tenant para limitar los problemas, además de ser parte esencial de un plan de ciberseguridad que os exigirán en muchos de vuestros puestos de trabajo. Espero que os sea de utilidad.