Hello Everyone!! Querido y apreciado lector de Obss, a partir de 1 de julio de 2024, es decir en menos de quince días, hay unos cambios a los que nos deberemos enfrentar las organizaciones, cuando Microsoft comience la implementación de la aplicación de MFA para las cuentas de usuario (incluidos los usuarios invitados) que usamos en inicios de sesión de administración de Azure. Me he tomado la libertad, de pensar que sería beneficioso revisar los principios para el acceso de emergencia y también analizar cómo construirlo de acuerdo con las últimas recomendaciones. ¡Let´s go!

Vamos a comenzar con los motivos por los cuales es imprescindible poseer una cuenta de acceso de emergencia o denominada de otra manera, de rescate. Vamos a verlo desde diferentes perspectivas para asegurarnos de que todos comprendamos por qué es esencial. También veremos que, incluso si ya tenemos configurado el acceso de emergencia, debemos asegurarnos de tener todo configurado de acuerdo con las últimas recomendaciones.

¿Por qué es imprescindible un acceso de emergencia o rescate?

La razón principal para que implementamos un acceso de emergencia es que debemos tener haber habilitado un plan de respaldo por si se bloquea el acceso administrativo a cuentas personales, sea cual sea el motivo. el departamento de TI, debe tener un plan de continuidad del negocio que nos prepare para una pérdida de acceso administrativo a cualquiera de nuestros entornos digitales.

Existen escenarios conocidos en los que podría ocurrir una pérdida de acceso y abarcan desde errores internos hasta intentos hostiles de adquisición de tenant.

La experiencia me dice que debemos implementar el acceso de emergencia con cariño y mucho cuidado y que debemos pensar un poco en los procesos y la documentación de recuperación del acceso. Hacer lo mínimo para implementarlo puede ser suficiente si la pérdida de acceso se produce internamente, pero desafortunadamente, si hay una perdida de acceso consecuencia de un ciberataque y solo tenemos una cuenta que se detecta fácilmente como cuenta de emergencia y no la tenemos protegida con MFA, es posible que se nos acabe la suerte. Veamos unos posibles escenarios:

• Si tenemos, (sabemos que no, porque le hemos dedicado muchas horas a estas configuraciones, pero por si acaso), una mala configuración en las políticas de acceso condicional de la organización que bloquea el acceso del administrador, la mayoría de las veces, el impacto también afecta a otros usuarios. Por supuesto, cada hora de paro laboral es cara. Si no tenemos cuentas de emergencia para recuperar el acceso al tenant, esas horas se convierten en días rápidamente. En esta situación, debemos establecer un acceso de emergencia que suponga poco esfuerzo y gran recompensa. Los riesgos aquí son mucho más graves que el costo de implementar el acceso de emergencia.
• Si el método de autenticación multifactor para administradores (globales) tiene un corte (si depende de una red móvil o un autenticador de software) y no hay otros administradores que puedan asignarle pases de acceso temporal. Por supuesto, la cuenta de emergencia podría tener el mismo método MFA defectuoso, pero es por eso que se recomienda crear dos o más cuentas, todas con diferentes métodos MFA o varios métodos simultáneos de MFA.
• Puede darse una situación, especialmente en las organizaciones más pequeñas, en las que no haya muchos administradores o solo uno. Supongamos que el único administrador global de la empresa decide desligarse de la empresa y hay mala relación entre él y la organización o sufre un accidente y es hospitalizado y no hay nadie más que pueda ascender repentinamente a un rol de administrador global.
• Adquisición hostil. Hemos decidido utilizar cuentas sincronizadas para el acceso administrativo, incluidas la cuenta de emergencia. Un ciberatacante, de manera aleatoria, pero con éxito, ataca a nuestros usuarios y realiza una apropiación de cuentas y se abre camino en nuestra red, donde, se mueve lateralmente y realiza un volcado de credenciales, después de lo cual completa la escalada de privilegios al administrador del dominio para, en última instancia, obtener el control del dominio. El ciberatacante deshabilita o elimina algunas cuentas administrativas en el Active Directory. Esos cambios se reflejan en Entra ID, ya sea deshabilitando o borrando la cuenta de usuario en la papelera de reciclaje de Entra. El ciberatacante procede a cambiar la contraseña de la cuenta de emergencia en AD que está sincronizada con la nube. La cuenta de emergencia no tenía MFA, por lo que el ciberatacante inicia sesión en ella para descubrir que la cuenta de emergencia tiene una función de administrador global permanente. No ve ninguna otra cuenta de emergencia, lo que lo entusiasma. Ahora ya es su tenant y ya no tenemos acceso a la cuenta de emergencia. Intentamos restablecer la contraseña de la cuenta de emergencia, pero el adversario ya inscribió su propio método MFA y desactivó SSPR en todo el tenant… ¡Jaque mate!

El caso es que hay escenarios, en los que el acceso de emergencia es más valioso que el oro. No podemos predecir todos esos escenarios de antemano. Pero podemos hacer todo lo posible para proteger la cuenta de emergencia.

Hoja de ruta para asegurar el acceso privilegiado

Como referencia, Microsoft recomienda crear una hoja de ruta para asegurar el acceso privilegiado. La hoja de ruta de referencia tiene cuatro etapas según su urgencia, desde la Etapa 1 hasta la Etapa 4.

¿Lo ha visto claro, verdad? Las tareas de la etapa 1 se clasifican como críticas y deben completarse de inmediato. Y resulta que definir y establecer al menos dos cuentas de acceso de emergencia pertenece a la Etapa 1

Pero ya lo tengo configurado. ¿Por qué debería reconfigurarlo?

Si lees el ejemplo de adquisición hostil, habrás notado que se puede configurar el acceso de emergencia, pero no todas las configuraciones son iguales. Algunas tienen más resistencia a los ataques que otras.

 La otra justificación para la reconfiguración es que si la configuración tiene un tiempo las recomendaciones han cambiado y hay un cambio próximo por parte de Microsoft en julio de 2024, lo que requerirá MFA para todas las cuentas de usuario que estén a punto de iniciar sesión en la administración de Azure.

Si estamos absolutamente 100% seguro de que nuestra configuración es óptima, al menos sería bueno que revisemos el proceso documentado que creamos en su día para el uso del acceso de emergencia y quién tiene acceso a las cuentas, la documentación del proceso y cómo se asigna ese acceso.

¿Tenemos un registro de auditoría? Sé que no especialmente gratificante esforzarse intensamente por algo que tal vez nunca suceda, pero si, por desgracia, sucede, estaremos muy orgullosos de nosotros mismos por haberlo hecho de la manera correcta.

¿Cómo deberíamos diseñarlo y construirlo?

Aquí hay algunos consejos de la documentación oficial y mis observaciones y experiencias personales. No existe un modelo exacto que se ajuste a todos, pero hay algunas pautas que yo diría que son fundamentales y deberían incluirse.

El flujo de trabajo de implementación:

1. Crear un grupo y asignarle un rol
2. Crear cuentas
3. Registrar métodos de autenticación para las cuentas
4. Excluir al grupo de TODAS las políticas de acceso condicional
5. Crear fuerza de autenticación personalizada
6. Crear una política de acceso condicional especial para estas cuentas
7. Asociar la autenticación personalizada con una política especial
8. Agregar cuentas como miembros del grupo
9. Crear reglas de alerta de inicio de sesión
10. Probar la configuración técnica
11. Documentar el proceso del plan de emergencia.
12. Autorizar y capacitar a los empleados pertinentes para actuar en caso de emergencia.

Cuentas de emergencia

¿Cuántas debemos tener? Pues depende. Dependerá de la dimensión de la empresa, de la dimensión del departamento de TI, pero, al menos, debemos tener al menos dos cuentas de emergencia. Si la empresa es muy grande y opera a nivel mundial en todo el mundo, podría estar justificado tener más cuentas de emergencia para brindar la posibilidad de acceso de emergencia después de la luz del sol. ¡Simplemente no te excedas!

¿Cómo referenciarlas? Podemos elegir el nombre de la cuenta de acuerdo con las políticas de su empresa, pero debemos considerar si deseamos que el nombre de la cuenta revele el verdadero propósito de la cuenta o no. Si elige utilizar nombres arbitrarios para las cuentas, lo lógico, seria nombrar también el grupo de seguridad de forma arbitraria.

¿Sincronizarlo con el Dominio? ¿Sólo en la nube? Bajo mi perspectiva, las cuentas deben ser solo en la nube y usar el dominio MOERA (*.onmicrosoft.comdominio), no utilizaremos nuestros dominios federados personalizados o sincronizados localmente. No tiene sentido tener estas cuentas en Active Directory y mi recomendación es mantenerlas solo en la nube.

¿Política de Contraseñas? Generaremos contraseñas largas de al menos 40 caracteres o más y por supuesto las guardaremos de forma segura en un papel y lo guardaremos en la caja fuerte. Una versión más rigurosa, de la que yo soy más partidario, consiste en dividir la contraseña por la mitad y almacenar ambas mitades en un lugar distinto.  Más adelante, necesitaremos la autenticación de clave de acceso FIDO que reemplazará a la contraseña. Debemos asegurarnos de que la contraseña no caduque. Si decidimos conservar las contraseñas, deberíamos cambiarlas después de cada uso (y por supuesto, redocumentarlo). También cambiaremos la contraseña periódicamente al menos una vez al año o según este establecido en el Plan de Gestión de Riesgos..

¿Grupo de seguridad? Claro, crearemos un grupo de seguridad con funciones habilitadas que esté mejor protegido contra cambios de que un grupo de seguridad normal. Asignaremos el rol de Administrador global al grupo.

¿Autenticación fuerte? Habilitaremos y configuraremos la autenticación de clave de acceso de hardware FIDO2. Es ideal, bajo mi punto de vista, ya que no necesitamos acceso a la red y no hay ningún software que pueda tener tiempo de inactividad o fallar. Durante el primer inicio de sesión, deberemos configurar Microsoft Authenticator y cambiar la contraseña inicial antes de poder registrar nuestra clave de acceso.

¡Nota! Microsoft recomienda registrar dos métodos de autenticación segura diferentes. No hay nada de malo en eso, pero realmente no veo que sea necesario si usamos la clave de acceso de hardware FIDO2 para la cuenta de emergencia. Pero siempre es mejor prevenir que curar.

Una vez registrado intenta iniciar sesión

Finalmente registre la clave de acceso de hardware (clave de seguridad)

Supervisión

Hay muchas guías para configurar la supervisión del registro de inicio de sesión, por lo que no las vamos a repetir aquí. Lo mejor en estos casos es acudir a la fuente la guía de Microsoft . También hay muchas guías comunitarias para hacer esto. yo personalmente, recomiendo que reenvíenos los registros de inicio de sesión de Entra ID a Azure Log Analytics para obtener una retención de registros más prolongada.

¿Qué más creo que debería controlarse?

• Cambios para el grupo de seguridad “Acceso de emergencia”
• El acceso de emergencia excluye la existencia en todas las demás políticas
• Si tenemos otras herramientas de seguridad con las que podemos etiquetar cuentas VIP, las cuentas de emergencia probablemente deberían marcarse como VIP.

Acceso condicional

El grupo de acceso de emergencia debe excluirse de todas las políticas de acceso condicional, excepto la que se crea específicamente para ellos.

Comenzaremos creando una fuerza de autenticación personalizada que asociaremos con la política. Solo marque la opción Claves de acceso . La razón por la que recomiendo crear una fuerza de autenticación personalizada separada y llamarla “Acceso de emergencia” es que debemos asegurarnos de que ningún otro administrador la edite ni la asocie a ninguna otra política. Menos espacio para las molestias.

Luego continuaremos para crear una política de concesión especial en la que incluya solo su grupo de acceso de emergencia, para requerir su nivel de autenticación personalizado recién creado y configurar controles de sesión:

• Name: “Grant – Emergency Access”
  Users include: “Emergency Access” group
  Users exclude: –
  Target resources: All cloud apps
  Grant: Require authentication strength: “Emergency Access”
  Session: Sign-in frequency: every time
  Session: Persistent browser session: Never persistent
  Enable policy: On

Política de acceso de emergencia

Requiere su nivel de autenticación personalizado

Controles de sesión para la política de acceso de emergencia

De forma opcional, podemos configurar las condiciones de la red y los filtros de dispositivos, pero no serán necesarios ya que aplicaremos el uso de claves de acceso FIDO2 que no pueden ser objeto de phishing. Si no podemos implementar el uso de la clave de acceso FIDO2, debemos considerar restringir el acceso a países conocidos o redes confiables. Si tenemos implementado el concepto de estación de trabajo de acceso privilegiado, es posible que podamos utilizar el filtrado de dispositivos para apuntar a sus PAW. Si ya estamos que los administradores cumplan con el dispositivo durante el inicio de sesión y funciona bien, también puede solicitarlo, pero, si recomendaría no agregar demasiadas condiciones. -Debemos tener en cuenta que los dispositivos pueden no cumplir con los requisitos de cumplimiento establecidos y los rangos de red pueden cambiar con el tiempo y los dispositivos PAW también tienen su ciclo de vida y todas estas cosas adicionales podrían terminar bloqueando el acceso a la cuenta de emergencia.

Proceso

Debemos tener, al menos dos empleados en todo momento (incluidas las vacaciones de temporada, el verano, etc.) que tengan acceso a las claves FIDO2. Si deseamos proteger rigurosamente el acceso de emergencia, es posible que desee mantener los PIN de las claves de seguridad accesibles para distintos empleados, para garantizar que ningún empleado pueda utilizar el acceso de emergencia por sí solo. Si optamos por dividir la clave de seguridad y el acceso al PIN para separar empleados, debe tener dos empleados con acceso a las claves y otros dos con acceso a los PIN, nuevamente, en todo momento. 

No hace falta decirlo, pero las claves de seguridad y sus PIN deben almacenarse en lugares restringidos y seguros. Un incendio no debería poder destruir ambas llaves al mismo tiempo, o un ciberatacante no debería poder robarnos ambas llaves al mismo tiempo. Lo mismo ocurre con los PIN.

El proceso de obtención de acceso y uso de cuentas de emergencia debemos documentarlo, capacitar a los empleados autorizados y probar para ver si el proceso funciona. El acceso a esta documentación debe estar restringido.

Con esto, quiero dejar claro que no estoy expresando desconfianza hacia los administradores, nos estamos asegurando que el incumplimiento tenga un alto coste, al intentar hacerse cargo de estas cuentas de emergencia. También nos estamos asegurando de que cualquier administrador que deje solo no pueda tener toda la información necesaria para usar la cuenta de emergencia.

En mi opinión es necesario revisar el proceso cada vez que:

• Cualquiera de los empleados autorizados abandona la empresa.
• La empresa se muda a una ubicación diferente.
• Hay un nuevo empleado autorizado que también necesita ser capacitado en el proceso.

Opcionalmente, después de usar una contraseña para iniciar sesión:

• Cambiar la contraseña
• Guarde la contraseña de forma segura y similar a como lo hacía antes

Pruebas

Durante el proceso de configuración, deberemos probar los siguientes aspectos:

• Acceso de emergencia a la cuenta del inquilino (solo para saber que funciona)
• Alerta de inicio de sesión y el consiguiente proceso de manejo de incidentes específico para su organización y especificaciones
• Los empleados autorizados acceden a las claves de acceso del hardware FIDO2 y a sus PIN.
• Acceso de los empleados autorizados a la documentación del proceso de emergencia.

Restablecimiento de contraseña

Cuando a las cuentas de emergencia se les asigna la función de Administrador global permanente, obedecen reglas SSPR diferentes a las de las cuentas de usuario normales. Los administradores debemos de tener una política de restablecimiento diferente . A continuación se presentan dos extractos de documentación de Microsoft:

Nota: La política del administrador SSPR no depende de la política del método de autenticación. Por ejemplo, si desactiva los tokens de software de terceros en la política de métodos de autenticación, las cuentas de administrador aún pueden registrar aplicaciones de tokens de software de terceros y utilizarlas, pero solo para SSPR. “ 

De forma predeterminada, las cuentas de administrador están habilitadas para el autoservicio de restablecimiento de contraseña y se aplica una sólida política predeterminada de restablecimiento de contraseña de dos puertas. “

Que significa esto:

De forma predeterminada, SSPR está habilitado para cuentas de emergencia (que tienen función GA permanente)

• De forma predeterminada, aplicaremos una política estricta de “two-gate” para los administradores que requieren dos datos.
• Podemos registrar métodos para SSPR, incluso si no están habilitados en las políticas de métodos de autenticación.
• No debemos permitir preguntas de seguridad para administradores para SSPR
• Un administrador del tenant (por ejemplo, administrador global) no puede cambiar los requisitos de la política de reinicio del administrador.

Incluso si la política de restablecimiento del administrador no se puede cambiar, podemos deshabilitar SSPR para los administradores mediante el cmdlet Update-MgPolicyAuthorizationPolicy Graph. Solo sepa que puede tardar hasta 60 minutos en reflejarse en la cuenta de usuario.

Entonces, ¿la cuenta de emergencia debería tener SSPR habilitado o deshabilitado?

Vamos a analizar los pros y los contras de cada opción.

SSPR habilitado

• Tanto los administradores legítimos como el ciberatacante pueden (técnicamente) restablecer la contraseña utilizando la cuenta de emergencia.
• Si la cuenta de emergencia no tiene ningún método SSPR habilitado
  • En esta situación, SSPR fallará porque no hay métodos SSPR disponibles.
• Si la cuenta de emergencia tiene dos métodos SSPR habilitados
  • SSPR debería funcionar ya que hay una cantidad necesaria de métodos SSPR disponibles.
  • Todavía es muy poco probable que el ciberatacante tenga acceso a ambos métodos. Posible, seguro, pero improbable.
• ¿Existe algún caso de uso para que los administradores legítimos habiliten SSPR y registren dos métodos para cuentas de emergencia?
  • Sólo si hay una pérdida de acceso administrativo, y la cuenta no tiene MFA habilitado y no existe ninguna política de CA que requiera MFA y la contraseña actual es…
    • Perdido
    • No se puede recuperar, por cualquier motivo, por ejemplo, se necesitan dos empleados pero el otro no está disponible
• El escenario anterior es bastante jodido y, con suerte, muy poco probable.
• Si SSPR está habilitado, recomiendo activarlo. Notificaremos a todos los administradores cuando otros administradores restablezcan sus contraseñas para detectar si alguien puede restablecer la contraseña de la cuenta de emergencia

SSPR deshabilitado

• Nadie puede restablecer la contraseña de la cuenta de emergencia sin acceso administrativo a Entra
• En una situación de bloqueo, esto no debería ser un problema para los administradores de la empresa si han configurado la cuenta para usar la clave de acceso de hardware FIDO2.

Por lo tanto,

• Siempre debemos habilitar y configurar claves de acceso de hardware FIDO2 para cuentas de emergencia y exigir que se utilicen durante la autenticación. Si hacemos esto y no configuramos ningún método SSPR ( la clave de acceso FIDO2 no es un método SSPR válido ), no debería importarnos si SSPR está habilitado o no para cuentas de emergencia.

Caducidad de la contraseña

Debemos configurar la contraseña para que nunca caduque en las cuentas de emergencia. Podemos comprobar el estado: Get-MgUser -UserId $uid | Seleccionar-Objeto @{N=”PasswordNeverExpires”;E={$_.PasswordPolicies -contiene “DisablePasswordExpiration”}}

Para deshabilitar la caducidad: Actualización-MgUser -UserId -PasswordPolicies DisablePasswordExpiration

Otras Consideraciones

No recomiendo utilizar Privileged Identity Management para que la cuenta de emergencia sea rol de Administrador Global. Eliminando variables hacemos que el acceso de emergencia sea más seguro. Al agregar más componentes, agregamos más complejidad que podría fallar o las características y la configuración de esos componentes (como PIM) podrían cambiar con el paso de los años, lo que requerirá que revisemos nuestra configuración de acceso de emergencia con más frecuencia.

No es necesario ni debemos asignar licencias a cuentas de emergencia..

Si aún no hemos migrado a políticas de método de autenticación convergente, verificaremos que La política MFA por usuario está deshabilitada para todas las cuentas de emergencia. Solo queremos controlar sus métodos utilizando las políticas del método de autenticación convergente.

Conclusión

El acceso de emergencia es una parte vital de cualquier entorno de nube. Debemos verlos como un seguro: si todo sale mal inesperadamente, tendremos acceso para solucionarlo y salvar el día. Solo recuerda tener calma, respirar profundamente un par de veces para no entrar en pánico y no hacer nada sin pensar. Es bueno comprender que las cuentas de emergencia son una de las cuentas más poderosas del tenant, así que debemos de tener cuidado de monitorearlas y asegurarnos que el acceso a estas cuentas esté adecuadamente restringido. ¡Y por supuesto, no olvides crear y ensayar el proceso de acceso de emergencia!

Nos vemos en las redes!!