Hello Everyone!!

La seguridad de los datos y las identidades es una prioridad fundamental en el mundo digital de hoy en día. Microsoft Entra ID, anteriormente conocido como Azure Active Directory (Azure AD), nos ofrece una poderosa herramienta para gestionar y proteger el acceso a los recursos de nuestra organización.

Una de las funciones clave de Microsoft Entra ID son las políticas de acceso condicional, que nos permiten establecer reglas específicas para controlar quién puede acceder a qué recursos, bajo qué circunstancias y nos permiten una gestión de seguridad muy granular. En este post, vamos a explorar algunas de las políticas de acceso condicional más recomendadas para asegurar nuestro entorno de Microsoft Entra ID y mantener nuestros datos a salvo. Aprenderemos cómo configurar estas políticas de manera efectiva y eficiente, y cómo pueden ayudarnos a fortalecer la postura de seguridad general de nuestra organización. Además, compartiremos algunos consejos y mejores prácticas para sacar el máximo provecho de las capacidades de acceso condicional de Entra ID.

Así que, si estás listo para llevar la seguridad de tu organización al siguiente nivel con Entra ID, ¡sigue leyendo!

Muchos de los problemas que nos encontramos en las organizaciones es que no suelen tener políticas de acceso condicional adecuadamente definidas. bien porque suele haber puntos ciegos, las políticas no cubren todas las aplicaciones, todos los usuarios y todos los escenarios.

Los problemas del mundo real

Muchas organizaciones tenemos definidas políticas de acceso condicional pero, en ciertas ocasiones, no las pensamos de forma adecuada. Esto se debe a que a menudo se dirigen únicamente a aplicaciones o usuarios específicos.

Cuando nos preguntamos por qué la política MFA solo se dirige a Office 365, por ejemplo, la respuesta es que no usamos nada más. O cuando nos preguntamos por qué solo se dirigen a un grupo de usuarios, la respuesta es que otros usuarios no usan los servicios en la nube.

Ese es simplemente el enfoque equivocado. Vamos a cambiar la perspectiva. No estamos protegiendo los servicios de nuestros usuarios de los usuarios, sino de los atacantes. Y sólo porque no usemos nada más que Office 365 no significa que un atacante no lo vaya a utilizar. O simplemente porque algunos de nuestros usuarios no utilicen servicios en la nube no significa que un atacante no pueda explotar esas cuentas.

Si esas aplicaciones o cuentas existen en la nube, debemos protegerlas independientemente de que los usuarios habituales las utilicen o no. Los atacantes buscan los lugares más inseguros, los eslabones más débiles.

De entrada, quiero decir que este artículo no es One Size. Diferentes organizaciones pueden tener diferentes requisitos y expectativas y, por lo tanto, diferentes políticas de acceso condicional establecidas. Por lo tanto, este artículo nos debe servir más como inspiración para pensar si hemos creado sus políticas de acceso condicional de manera correcta y completa.

Cuentas Anti-pánico

Antes de comenzar a crear las políticas de acceso condicional reales, en realidad antes de comenzar con la implantación de una política de seguridad en el tenant, debemos preparar un plan de emergencia. Al aplicar políticas de acceso condicional, es fácil que nos quedemos bloqueados. Por lo tanto, antes de empezar, deberemos crear una política que la aplicaremos a una cuenta de administrador y que nos permita que no perdamos el acceso al tenant.

El soporte de Microsoft nos puede resolver este problema, pero es una complicación importante y definitivamente es mejor prevenirla. Y para eso están las cuentas Anti-pánicos. Las cuentas de anti-pánico las debemos dejar excluidas de todas las políticas de acceso condicional.

Requerir MFA a dispositivos no compatibles

La cobertura de todos los escenarios/situaciones posibles es esencial para las políticas de acceso condicional. es decir, para que no nos queden puntos ciegos. Aplicaciones desprotegidas, usuarios desprotegidos, usuarios en exclusiones, etc. Porque es muy fácil olvidar algo cuando empiezas a crear políticas de forma incremental para diferentes escenarios. Es posible que nos dirijamos a diferentes tipos de usuarios, aplicaciones y plataformas, pero olvidaremos por completo que existen otras aplicaciones, otros tipos de usuarios, otras plataformas, etc. Y los atacantes pueden encontrar y explotar estas brechas de cobertura.

Por eso es una buena practica comenzar con una política básica en la que definamos las bases de la seguridad y apuntemos a todas las aplicaciones, todos los usuarios y todos los escenarios. Esta política básica puede requerir, por ejemplo, autenticación multifactor al acceder desde dispositivos no compatibles. Esta política la aplicaremos a todas las cuentas y a todas las aplicaciones en la nube y requerirá autenticación multifactor si un intento de inicio de sesión determinado no se inicia desde un dispositivo compatible.

Por tanto, esta política la aplicaremos a todos los usuarios y a todas las aplicaciones en la nube. Colocaremos únicamente las cuentas anti-pánico en las exclusiones de usuarios. En Condiciones, nos centraremos en el navegador web y en las aplicaciones móviles y de escritorio, porque Exchange ActiveSync y otros clientes están completamente bloqueados por otra política.

En Filtro para dispositivos, configuraremos esta política para que se aplique a los dispositivos que no están marcados como compatibles. Entonces tomaremos o la propiedad isCompliant , el operador no es igual y el valor es verdadero.

Alguien podría pensar que esto lo deberíamos realizar al revés, es decir, isCompliant es igual a False . Pero esto podría resultarnos potencialmente un punto débil, porque si el estado de cumplimiento no se cargara por cualquier motivo, este requisito se cumpliría y no se requeriría MFA posteriormente. Por lo tanto, si verificamos el estado de cumplimiento como isCompliant Not es igual a True , estamos seguros de que estamos tomando la ruta más segura y cualquier cosa que no cumpla explícitamente requerirá MFA.

Por último, configuraremos Grant Section para que nos requiera MFA. Por lo general, siempre recomiendo usar Authentication Strength en lugar del genérico Require multifactor authentication , porque Authentication Strength nos permite definir qué tipos específicos de autenticación necesitamos.

Requerir MFA para administradores

Otra política básica que deberemos implementar es exigir MFA a los administradores. La diferencia con la política anterior es que la política anterior estaba dirigida a todos los usuarios pero requería MFA solo de dispositivos no compatibles. Esta política estará dirigida únicamente a administradores del tenant, pero requerirá MFA en todo momento, incluso desde dispositivos compatibles.

NOTA DEL AUTOR: Bajo mi criterio, un administrador, nunca deberia poder acceder desde un dispositivo no compatible.

Dado que los administradores poseen cuentas con muchos privilegios, nuestra seguridad debe ser implícitamente mayor que la de los usuarios normales. Por lo tanto, siempre se nos debe requerir MFA.

Por lo tanto, nos centraremos en roles privilegiados dentro de la política. Lo importante aquí es que apuntemos a roles, no a usuarios o grupos de usuarios específicos.

Nuevamente, esto nos puede causar brechas de seguridad en las que asignemos una función de administrador a alguien pero se nos olvida agregar la cuenta a la política. Para eso existen los grupos dinámicos

Al menos deberías seleccionar estos roles:

• Administrador global
• Administrador de aplicaciones
• Administrador de autenticación
• Administrador de facturación
• Administrador de aplicaciones en la nube
• Administrador de acceso condicional
• Administrador de intercambio
• Administrador de la mesa de ayuda
• Administrador de contraseñas
• Administrador de autenticación privilegiado
• Administrador de rol privilegiado
• Administrador de seguridad
• Administrador de SharePoint
• Administrador de usuarios

En general, debemos seleccionar los roles que utilizamos. Si seleccionamos todos los roles, definitivamente no cometeremos ningún error. No olvides que no debemos incluir la cuenta anti-pánico en las exclusiones. En aplicaciones en la nube, seleccione todas las aplicaciones. Y en Conceder , seleccione Requerir solidez de autenticación .

Bloquear Exchange ActiveSync y protocolos de autenticación heredados

Exchange ActiveSync es un protocolo utilizado por algunas aplicaciones de correo alternativas como Apple Mail, Samsung Mail y otras. Las aplicaciones oficiales de Microsoft no utilizan Exchange ActiveSync y por lo tanto, no lo necesitamos para nada. Y es una buena práctica desactivar las cosas que no utilizamos.

La autenticación heredada, denominada “Otros clientes” en las políticas de acceso condicional, son aplicaciones que utilizan POP3, IMAP y SMTP. Estos protocolos no admiten la autenticación moderna en absoluto, por lo que no podemos aplicar la autenticación multifactor en estos protocolos. Incluso los atacantes lo saben, por lo que la gran mayoría de los ataques se dirigen a protocolos de autenticación heredados, porque allí solo necesitan saber/descifrar la contraseña y nada más se interpone en su camino. La autenticación heredada siempre la debemos estar deshabilitada.

En esta política, nuevamente nos dirigiremos a todos los usuarios. En esta política no es necesario incluir la cuenta anti-pánico en las exclusiones, ya que nunca debe usar Exchange ActiveSync o autenticación heredada. También nos centraremos en todas las aplicaciones.

En Condiciones – Aplicaciones cliente, seleccionaremos Clientes Exchange ActiveSync y Otros clientes . En Conceder , seleccionaremos Bloquear acceso .

Bloquear el acceso desde plataformas desconocidas

Las organizaciones tenemos diferentes sistemas operativos que administramos de forma oficial. Suelen ser Windows, macOS, iOS/iPadOS y Android. Otras plataformas tienden a no estar administradas y, por lo tanto, no cuentan con soporte.

Nuevamente, es bueno que desactivemos completamente el material no compatible y esto también lo debemos aplicar a las sistemas operativos. Para ellos crearemos una política de acceso condicional en la que deshabilitaremos todo lo que no figura en la lista anterior. Por supuesto, modificaremos la lista de sistemas operativos que admitimos para adaptarla a nuestras necesidades. Por ejemplo, si no usamos macOS en nuestra organización lo eliminaremos de la lista porque está bloqueado al autenticarse con Microsoft Entra ID.

Dentro de los usuarios, nuevamente nos dirigiremos a todos los usuarios y agregaremos la cuenta anti-panico a las exclusiones. En las aplicaciones en la nube, nos centraremos en todas las aplicaciones en la nube.

En Condiciones , iremos a Plataformas de dispositivos y en Incluir seleccione Cualquier dispositivo y en Excluir seleccionaremos los sistemas operativos que admitamos. En mi caso particular Andoid, iOS, Windows y MacOS. La razón por la que lo hacemos de esta manera es porque queremos bloquear todo excepto los que seleccionamos; es por eso que las plataformas compatibles están en las exclusiones.

Ahora, en Conceder , seleccionaremos Bloquear acceso . Esto nos garantizará que el acceso estará bloqueado desde todas las plataformas excepto aquellas seleccionadas explícitamente en las exclusiones.

Requerir MFA para unir un recurso

Algo que muchas veces nos olvidamos es el registro de recursos. La mayoría de las organizaciones permitimos que todos los usuarios registren recursos en Microsoft Entra ID. Dada la situación actual en la que nos encontramos, el recurso utilizado lo convertimos en un dispositivo compatible en toda la organización, lo que probablemente hará que cumpla algunas políticas de acceso condicional que hemos implantado (revisa, por ejemplo, la política anterior, en MFA para usuarios habituales que no se requieren en dispositivos compatibles. Por lo tanto, será es mucho más fácil atacar otras cuentas dentro de la organización desde dicho recurso.

El registro del recurso por parte de un atacante es algo que vemos muy a menudo durante la respuesta a incidentes por el motivo mencionado anteriormente. Si el proceso de registro del recurso no es seguro (o está completamente deshabilitado) para los usuarios normales, un atacante puede simplemente obtener/descifrar la contraseña de cualquier usuario de la organización, permitiéndole registrar su propio recurso y luego atacar otras cuentas y servicios desde ese recurso con mucha mayor facilidad.

Por lo tanto, esta política la aplicaremos a todos los usuarios. la cuenta anti-pánico no necesita exclusión aquí. En Recursos de destino en el menú desplegable superior, seleccione Acciones de usuario y luego seleccione Registrar o unirse a dispositivos como acción. En Conceder , seleccione Requerir solidez de autenticación para requerir MFA.

Inscripción segura en MFA

Para utilizar MFA, los usuarios primero deben registrarse. Sin embargo, puede surgirnos el problema de que un atacante potencial también pueda registrarse en MFA si ya tiene acceso a la identidad. Nuevamente, esto es algo que vemos de forma habitual durante la respuesta a incidentes: los atacantes registran sus propios métodos de autenticación para que MFA pueda cumplir con el requisito de MFA para acceder a aplicaciones y servicios.

Por lo tanto, también es necesario que garanticemos el proceso real de registro de MFA.

Por lo tanto, crearemos una política de acceso condicional dirigida a todos los usuarios excepto a la cuenta anti-pánico y excepto a los usuarios externos. Aquí es importante que excluyamos a los usuarios externos, ya que es poco probable que puedan cumplir con el requisito de registro en la MFA.

En la sección Recursos de destino , seleccionaremos Acciones del usuario en el menú desplegable y elegiremos Registrar información de seguridad . La pregunta entonces es cómo podemos asegurar de manera realista el proceso de registro de MFA. En general, recomendamos solicitar un dispositivo compatible o MFA. Exigir una MFA puede parecernos un requisito sin sentido cuando se trata del proceso de registro de la MFA, sin embargo, es posible que el usuario ya tenga registrado un método MFA (como un número de teléfono) y simplemente esté agregando otro método (como Microsoft Authenticator).

En la sección Condiciones , seleccionaremos Filtrar para dispositivos y estableceremos Propiedad en isCompliant , Operador en No igual y Valor en Verdadero .

El mismo principio que establecimos en la política que exige MFA para todos los usuarios anteriormente. Y en la sección Conceder , establezca Requerir fuerza de autenticación .

La configuración anterior nos garantizará que si el usuario accede desde un recurso compatible, no será necesario que MFA registre información de autenticación. Si el usuario accede desde un recurso no compatible, le requeriremos que MFA registre información de autenticación adicional.

Requerir dispositivos compatibles para acceder a las aplicaciones

El acceso desde las aplicaciones significa:

• Que la aplicación está registrada y ha recibido un token de actualización principal.
• Que el inicio de sesión en esa aplicación es permanente: no se requiere nueva autenticación.
• Que es probable que la aplicación sincronice algunos datos con el recurso, bien sean archivos a través de OneDrive o correos electrónicos a través de Outlook.

Por todo lo anterior, es deseable que el acceso a las aplicaciones solo sea posible desde dispositivos compatibles (administrados). De lo contrario, corremos el riesgo de que los correos electrónicos o documentos corporativos confidenciales de OneDrive / SharePoint lleguen a un recurso no administrado que desde el departamento de TI no controlamos y no es no debemos permitir tener una cuenta corporativa conectada permanentemente y datos corporativos sincronizados en dicho dispositivo. Por ejemplo, podría tratarse del recurso privado de un usuario, pero también podría ser un recurso compartido dentro de la familia o un recurso completamente extraño.

En general, nuestra recomendación es dividir la política en dos políticas. Con una política nos centraremos en los recursos móviles (probablemente Android e iOS) y con la otra política nos centraremos en las recursos fijos (probablemente Windows y MacOS). Esto lo recomendamos más por razones prácticas y a efectos de presentación de informes, pero podemos incluir tanto los recursos móviles como las recursos fijos en una sola política.

Y si nos preguntamos qué sucederá con los recursos que no son compatibles e intentan conectarse desde una aplicación o que ya tienen una aplicación agregada, entonces la respuesta es que no tenemos nada de qué preocuparnos. Dentro de las aplicaciones oficiales de Microsoft, aparecerá un asistente simple para guiar al usuario a través del proceso de inscripción de ese recurso en Microsoft Intune. Por lo tanto, podemos aplicar esta política con relativa facilidad incluso si ya tenemos recursos que se conectan desde aplicaciones, pero es posible que no todos estén registrados en Intune en este momento.

La nueva política la volveremos a dirigir a todos los usuarios con exclusión de las cuentas de anti-pánico y la volveremos a apuntar a todas las aplicaciones en la nube.

Si nuestra intención es tener una política separada para dispositivos móviles y de escritorio, configuraremos los sistemas operativos del recursos en consecuencia en la sección Condiciones . Si deseamos tener una política común tanto para recursos móviles como para recursos fijos, no necesitamos configurar los sistemas operativos del recurso.

Sin embargo, en la sección Condiciones , es importante que configuremos que la política se dirija a aplicaciones móviles y clientes de escritorio .

En la sección Conceder , estableceremos que se requerirá un dispositivo compatible.

Duración de la sesión para dispositivos no compatibles

Limitar la duración de la sesión en recursos no compatibles es un escenario similar al ejemplo anterior, sólo que en este caso nos dirigimos a los navegadores web en los que queremos limitar cuánto tiempo puede permanecer activa una sesión.

De nuevo, la idea es que, de forma predeterminada, los usuarios puedan permanecer conectados permanentemente al navegador web. Todo lo que tiene que hacer un usuarios es seleccionar la opción “Mantenerme conectado” durante el inicio de sesión, lo que le garantizará que incluso después de cerrar el navegador o reiniciar la computadora, la sesión permanezca conectada de forma permanentemente.

Esto, a todas luces, es un riesgo para la seguridad no solo en la privacidad de los usuarios, recursos, etc., sino que imaginemos por un momento, a un usuario conectado de esta manera, por ejemplo, en el recurso de otro usuario o, peor, en un ordenador compartido en algún vestíbulo de un hotel.

Por lo tanto, es una buena práctica limitar cuánto tiempo un usuario puede permanecer conectado a un navegador web en un recurso no administrado. Después de un período de tiempo determinado, la sesión del usuario la cerraremos de forma automática, con lo que reducimos de forma significativa el riesgo de uso indebido de la cuenta.

Crearemos una nueva política de acceso condicional que nuevamente se dirija a todos los usuarios excepto a la cuenta de anti-pánico.

La política la centraremos en todas las aplicaciones en la nube. En Condiciones – Aplicaciones cliente , seleccione Navegador . Y como solo nos dirigimos a dispositivos no administrados, necesitaremos configurar el Filtro para dispositivos y elegir Propiedad = es compatible , Operador = No es igual y Valor = Verdadero . La misma configuración que varias veces arriba.

En la última sección, abriremos Sesión y configuramos la Frecuencia de inicio de sesión en Reautenticación periódica y seleccionaremos el tiempo después del cual cerraremos la sesión automáticamente en el navegador web en un dispositivo no administrado. Normalmente recomendamos entre 1 y 2 horas, lo que debería ser suficiente para hacer lo mínimo en un dispositivo desconocido. Y por último, marcaremos la opción Sesión de navegador persistente y elegiremos Nunca persistente . Esto significa que el usuario no verá la opción Mantenerme conectado en la pantalla de inicio de sesión y la cuenta se cerrará automáticamente cuando se cierre el navegador web.

NOTA DEL AUTOR: yo recomiendo extender el limite de sesión dispositivos compatible y/o gestionados por el departamento de TI, en este caso ampliaríamos tiempo de cierre de la sesión a, en mi caso, 5 horas.

Otras políticas de acceso condicional

Las políticas anteriores las consideremos elementos básicos en la configuración de cualquier tenant. Otras políticas las ponemos poner bajo la consideración y el escenario específico de la organización.

También va a depender de las licencias si tiene un P1 o P2 de Microsoft Entra ID, ya que las licencias P2 le permiten aplicar políticas de acceso condicional basadas en el riesgo del usuario o el riesgo de la actividad de inicio de sesión.

A continuación se muestra una lista de otras posibles políticas de acceso condicional a considerar:

• Bloquear descargas de archivos en dispositivos no compatibles
• Requerir MFA resistente al phishing para administradores globales
• Requerir dispositivo compatible para administradores
• Requerir MFA resistente al phishing para los portales de administración
• Requerir dispositivo compatible para portales de administración
• Requerir PAW/SAW/CSM para administradores
• Requerir PAW/SAW/CSM para portales de administración
• Requerir MFA cuando se detecta riesgo de inicio de sesión
• Bloquear la autenticación cuando el riesgo de inicio de sesión sea alto
• Establecer la frecuencia de inicio de sesión cada vez que se detecte un riesgo de inicio de sesión
• Requerir cambio de contraseña cuando el riesgo del usuario es alto

Conclusión

Como hemos mencionado desde el principio, las directivas de acceso condicional no son una solución definitiva para todos nuestros problemas, pero el objetivo de este artículo es brindar educación e inspiración sobre las políticas de acceso condicional y la seguridad de la identidad en la nube en general.

Cada organización es individual y requiere enfoques y políticas individuales. Si no estás seguro de cómo afectará una política a tus usuarios, habilítala en modo de solo informe antes de comenzar a aplicarla.

Sin embargo, ten mucho cuidado con las exclusiones. A menudo se ven demasiados usuarios excluidos dentro de las políticas y nadie sabe exactamente por qué. Cada exclusión la debemos tener bien justificada en cualquier momento y, de manera óptima, deberíamos tener alguna otra restricción para cada exclusión. Por ejemplo, ¿necesitamos enviar correos electrónicos desde un servicio mediante SMTP? En caso afirmativo, colocaremos esa cuenta en las exclusiones de la política de autenticación heredada, pero crearemos una nueva política para esa cuenta que restrinja el uso de esa cuenta desde una sola dirección IP específica.

Gracias por leer en Obss, sobre la importancia de las  Políticas de acceso condicional recomendadas para fortalecer la seguridad de la red, proteger los recursos digitales, controlar el acceso a los recursos digitales, proteger contra riesgos internos y cumplir con normativas de seguridad y privacidad de una organización. Esperamos que te hayamos invitado a reflexionar sobre como las políticas pueden ayudarte a prevenir los acceso y prevenir el riesgo.

Si tienes alguna pregunta o necesitas ayuda para configurarlos, no dudes en contactarnos a través de Linkedin o a través de nuestra comunidad de Whatsapp.

Nos vemos en las redes!!