Hello EveryOne! Hace unos días mientras charlaba sobre ciberseguridad con varios colegas, salía un tema de forma recurrente, todos teníamos un nexo en común, las Políticas de Acceso Condicional (PAC). Durante el transcurso de la charla, convinimos que frecuentemente hablamos sobre las políticas de acceso, pero no es mucha la gente que habla sobre qué políticas son importantes para los clientes.

A pesar de que para gustos los colores y que cada rol implicado en la seguridad de la organización tiene su propia opinión, lanzo las reglas que bajo mi criterio son un must dentro de la política de Autenticación y Gestión de identidades.

Hoy, hablaré precisamente sobre estas políticas:

• MFA para TODOS
• Flujo de código del dispositivo de bloqueo
• Bloqueo de la autenticación heredada
• Cómo hacer cumplir la normativa de los dispositivos en todos los dispositivos
• Requerimiento de MFA para la inscripción en Intune
• Requerimiento de autenticación de resistencia a phishing para portales de administración
• Protección de tokens para dispositivos administrados
• Exigir MFA resistente al phishing para dispositivos confiables

Aunque dentro de mi blog, he hablado largo y tendido sobre este tema, vamos a comenzar por lo básico.

¿Qué es el acceso condicional de Entra?

Podemos coincidir, querido lector, en que las PAC de Microsoft Entra ID reúnen las señales para tomar decisiones y aplicar las directivas establecidas en el seno de la organización. El acceso condicional es el motor de directivas de Confianza cero de Microsoft que tiene en cuenta señales de varios orígenes al aplicar decisiones de directivas.

Para más información puedes descárgate mi libro sobre Arquitectura Zero Trust Fortaleciendo la Seguridad: Guía Práctica de Arquitectura de Confianza Cero

La siguiente imagen nos muestra que es el acceso condicional de Entra:

Cuando analizamos las PAC, de forma automática recordamos, por analogía,  las declaraciones If then. Tomando esta afirmación como valida, se puede establecer que las señales son los If en las declaraciones, que son esencialmente el qué/quién que queremos evaluar. Las señales pueden ser, entre otras:

• Los Usuarios, Grupos con derecho o Unidades Administrativas
• La red de donde se origina el tráfico
• Dispositivos o aplicaciones
• Ubicación
• Condiciones como riesgo del usuario, riesgo de inicio de sesión, flujos de autenticación, plataformas entre otros.

La segunda parte, los then, son las decisiones. Este es el aspecto fundamental de las PAC. Nos centramos en las decisiones de permitir o bloquear acciones en función de varios criterios. Algunas de las opciones más populares son:

• Dispositivo en conformidad
• Autenticación multifactor
• Fuerza de autenticación
• Requerimiento híbrido
• Requerir aplicaciones aprobadas

La gestión de identidades y accesos adquiere una dimensión más sofisticada al incorporar decisiones dinámicas de sesión. Estas capacidades avanzadas permiten un control más preciso y adaptativo de la seguridad, mejorando significativamente la protección de los recursos digitales.

• Aplicación de la protección de tokens
• Cambiar la frecuencia de inicio de sesión
• Control de aplicaciones de acceso condicional (le permite bloquear descargas para ciertas aplicaciones en la nube)
• Desactivar la resiliencia (detener el acceso a ciertas aplicaciones si Entra deja de funcionar)

Estas decisiones nos llevan a la aplicación efectiva de la PAC, que puede consistir en ejecutar un bloqueo, exigir a los usuarios que inicien sesión en el correo electrónico con mayor frecuencia o aplicar la autenticación multifactor.

En su totalidad, el acceso condicional de Microsoft Entra ID es increíblemente poderoso.

Comencemos pues con mi propuesta de políticas básicas.

MFA para todos los usuarios

Esta es relativamente fácil. La autenticación multifactor (MFA) se ha convertido en un estándar de oro en la ciberseguridad. En general, es una buena idea aplicar la autenticación multifactor a todos los usuarios en todo momento. La autenticación multifactor es la clave de las PAC. Al exigir a los usuarios que presenten dos o más formas de identificación para acceder a una cuenta, la MFA crea una barrera adicional que dificulta significativamente a los ciberdelincuentes comprometer las cuentas

Accedemos a las directivas de acceso condicional y si no queremos modificar la directiva original, siempre podemos duplicar la existente.

A partir de aquí, simplemente asignamos a Todos los usuarios o bien mediante grupos de acceso e implementamos la política. Solo por recordar, la fuerza de autenticación multifactor consiste en la combinación de varias if.

Algo que debes tener en cuenta en esta política, son las cuentas de servicio o los proveedores externos. En este escenario, es necesario crear un rango de red de confianza para ellos específicamente para eximir a esas cuentas de la política, por ejemplo:

Lo esencial es que necesitamos auditar y observar los dispositivos que no autenticamos de manera óptima y tenerlo en cuenta en nuestra política. Otro buen ejemplo son las cuentas de invitados, que puedes excluir:

Es posible que la cuenta de invitado estándar no pueda funcionar con esta política. Es necesario, crear un grupo de Entra ID de usuarios invitados de confianza para este propósito en lugar de un enfoque descontrolado.

Flujo de código del dispositivo de bloqueo

La primera pregunta que nos viene a la cabeza es: ¿Qué es un flujo de código del dispositivo?

El flujo de código del dispositivo se utiliza al iniciar sesión en dispositivos que podrían carecer de una entrada local, como un dispositivo compartido, señalización digital, etc. Es como cuando inicias sesión en Netflix en tu televisor en casa.

No es necesario recordar, que el flujo de código del dispositivo es de alto riesgo y se puede utilizar para realizar phishing o acceder a aplicaciones corporativas en un dispositivo no administrado. Por lo tanto, debemos armar una buena política para controlar el flujo de código del dispositivo y asegurarnos de que esté bien configurada.

Si hay lugares en los que lo necesitas, como en las salas de conferencias, hay muchas formas para excluir nuestros dispositivos clave. Podemos configurar esto con bastante facilidad, como puedes ver a continuación. Lo dirigimos a todos los usuarios/todas las aplicaciones, al flujo de código del dispositivo y Bloqueamos el acceso:

Ahora bien, si necesitamos excluir algo como su VLAN o AV, la recomendación es que aprovechemos las exclusiones de red como muestro a continuación. Pero también podemos excluirlo con filtros de dispositivos o grupos de usuarios, según el caso de uso:

Bloqueo de la autenticación heredada

La autenticación heredada siempre es un elemento interesante. Principalmente, queremos asegurarnos de que los protocolos heredados, como POP, IMAP, etc., no se puedan usar para la autenticación básica.

Es posible que ni siquiera necesitemos activar la política, ya que la mayoría de estos elementos ahora están bloqueados de forma predeterminada, pero es mejor prevenir que curar. Además, aprovechando la PAC de Microsoft Entra ID, es una política muy fácil de configurar.

Lo aplicamos a todos los usuarios y aplicaciones, al tiempo que aprovechamos las condiciones para bloquear el acceso a los clientes de autenticación heredados, como podemos ver a continuación:

Una vez que hemos comprobado mediante la activación de solo informe, que todo es correcto, podemos pasar a activado.

Cómo hacer cumplir la normativa de los dispositivos en todos los dispositivos

Este es un tema que me preocupa de forma especial. He estado en muchas reuniones donde la norma era permitir a todo tipo de personas acceder a Office 365/ Entra ID en dispositivos no administrados (BYOD o cualquier dispositivo familiar/amigos, etc.).

Me rebelo. ¡BASTA YA! Es un gran desafío para los departamentos de TI, porque hay que invertir en hardware, pero es muy importante para la seguridad.

Básicamente, podemos ofrecer opciones a las personas (registrar su propio dispositivo, PC en la nube, PC físico, etc.). A partir de ahí, debemos analizar y asegurarnos de que nuestras políticas de cumplimiento sean alcanzables.

En Windows, lo mantengo bastante básico, ya que nos centramos en las características de seguridad del dispositivo como TPM, Firewall, VPN, etc. La parte más importante es implementar la política y ver qué no está creando problemas de coherencia. Una vez que nos cercioremos de la conformidad del dispositivo, habremos construido la base para nuestras PAC:

De manera similar, en iOS te centras en una política que sabes que es alcanzable:

Aquí también es fácil configurar su política. Analizamos todo, establecemos una condición para todos los tipos de dispositivos y otorgamos acceso solo si un dispositivo cumple con las normas. La estrategia comienza y termina con la creación de las políticas de cumplimiento adecuadas. Solo queremos bloquear a las personas que realmente deben ser bloqueadas

Una consecuencia de esta política es que quizás queramos bloquear las descargas en dispositivos no administrados. Podemos crear filtros de exclusión y bloquear las descargas de dispositivos no compatibles desde OneDrive, por ejemplo.

Un aspecto clave que hay que tener en cuenta aquí es que se trata de políticas de Defender for Cloud Apps, que requieren una licencia E5 o la licencia de aplicaciones en la nube independientes.

Requerimiento de MFA para la inscripción en Intune

Otro elemento clave en el que me quiero detener es la exigencia de MFA para las inscripciones de Intune.

Exigir MFA para la inscripción en Intune es una medida de seguridad proactiva que refuerza considerablemente la postura de seguridad de una organización.

Cuando un usuario intenta inscribir un dispositivo en Intune, se le solicitará que proporcione una segunda forma de autenticación además de su contraseña. Esto puede ser a través de una aplicación de autenticación, un mensaje de texto, una llamada telefónica o un dispositivo de seguridad física

La otra mitad de la política establece la concesión para Requerir autenticación multifactor y requerir que el dispositivo esté marcado como compatible junto con la frecuencia de inicio de sesión en cada ocasión.

Con todas estas políticas, debemos evaluar si preferimos aprovechar la solidez de la autenticación. A veces, esto nos brinda más de lo que estamos buscando.

Exigir autenticación resistente a phishing para portales de administración

Otra then importante es implementar una autenticación multifactor resistente a la suplantación de identidad (MFA) para todos los portales de administración. Algunos aspectos clave que se deben mencionar son:

• Alto valor: Los portales de administración suelen contener información confidencial y herramientas para realizar cambios críticos en la infraestructura de una organización.
• Objetivo principal de los atacantes: Los atacantes saben que al comprometer una cuenta de administrador, pueden obtener acceso a todo el sistema.
• Evita el phishing tradicional: Los métodos de MFA tradicionales, como los códigos enviados por SMS o correo electrónico, pueden ser vulnerables a ataques de phishing

Las MFA resistentes a la suplantación de identidad (phishing) son elementos como Windows Hello para empresas, claves de acceso y certificados. A menudo no nos damos cuenta de que WH4B no es tan simple como Inicié sesión con mi PC, así que ya estoy seguro, ¿no?

Significa que te autenticaste en esa aplicación con ella. Por lo tanto, para aquellos de nosotros que tenemos IDP, crearemos un nivel de autenticación personalizado.

De lo contrario, esta política es muy sencilla. Solo nos dirigimos a la aplicación Microsoft Admin Portals y usamos nuestra autenticación personalizada, ¡y listo!

Protección de tokens para dispositivos administrados

Esta política necesita un poco más de explicación. La función de protección de tokens es conocida como vinculación de tokens de forma generalizada. Esta protección nos va a ayudar a reducir los ataques de robo de tokens al hacer que un token solo pueda ser utilizado por ese dispositivo administrado. Como recordatorio, necesitará tener licencias de Entra P2 para admitir esta increíble capacidad.

Los ciberatacantes, ahora usan con frecuencia varios ataques como el secuestro o la reproducción para hacerse pasar por usuarios. La protección de tokens crea un vínculo criptográfico seguro entre el token y el dispositivo, lo que hace que el token sea inútil en cualquier otro dispositivo. Este vínculo se crea en la unión de Entra ID, lo que le brinda excelentes protecciones. Solo quiero mencionar de forma rápida los requisitos:

• Windows 10+ que estén unidos a Entra, unidos a un sistema híbrido o registrados en Entra.
• Cliente de sincronización de OneDrive 22.217+
• Equipos 1.6.00.1331+
• Power BI Desktop 2.117.841.0+
• Visual Studio 2022+ con agente de autenticación de Windows
• No hay soporte para clientes perpetuos de Office

Estos flujos interrumpirán elementos como módulos PS, PowerQuery en Excel, cliente Teams 2.1, Windows Server, Surface Hub y MTR. Por lo tanto, debemos asegurarnos de excluir esos tipos de dispositivos según corresponda.

En primer lugar, podemos apuntar a dos aplicaciones (Exchange y SharePoint):

A continuación, filtramos los dispositivos unidos a Entra ID (también puedes agregar a elementos híbridos aquí):

Solo seleccionamos Aplicaciones móviles y clientes de escritorio

La última pieza que nos resta es exigir la protección mediante token para las sesiones de inicio de sesión. Tenemos que hacerlo de esta manera porque durante la vista previa podemos encontrarnos con algunos problemas diferentes:

• Los servicios web de Teams que utilizan MSAL.js pueden quedar bloqueados
• Si intenta utilizar otras aplicaciones además de SPO y EOL, es probable que experimentemos fallos y problemas en general.

Exigir MFA resistente al phishing para dispositivos confiables

La última PAC que quiero mencionar se refiere a un ataque reciente. Recientemente, nos enteramos de que los atacantes pueden eludir la autenticación segura de Windows Hello, como puede leer aquí .

Una buena forma de combatir este problema es con esta política, que utiliza nuestro mismo filtro de dispositivo:

Tomaremos todos los dispositivos unidos a Entra ID y aplicará/requerirá una autenticación resistente a phishing:

Básicamente, esta PAC nos va a ayudar a garantizar que cualquier dispositivo unido a Entra ID aproveche la autenticación resistente al phishing (o lo que dicte nuestra política de fortaleza de autenticación) para ayudar a protegerse contra estos ataques.

Tabla Comparativa de Políticas

Política	Complejidad de Implementación	Impacto en Seguridad	Impacto en Usuarios
MFA para Todos	Media	Alta	Media
Bloqueo de Flujo de Código	Baja	Media	Baja
Bloqueo Auth. Heredada	Baja	Alta	Baja
Cumplimiento de Dispositivos	Alta	Alta	Media
MFA para Intune	Media	Media	Baja
Auth. Resistente a Phishing	Alta	Alta	Baja
Protección de Tokens	Alta	Alta	Baja
MFA Resistente al Phishing	Media	Alta	Baja

El Poder de la Simplicidad en la Seguridad de la información

Las PAC son la columna vertebral de una estrategia de ciberseguridad robusta. Sin embargo, su verdadero poder radica en la simplicidad y la implementación cuidadosa. Recuerda:

• La seguridad no es un destino, sino un viaje continuo.
• Cada política implementada es un paso hacia una organización más segura.
• La flexibilidad y la adaptabilidad son tus mejores aliados en este camino.

No te dejes intimidar por la complejidad. Comienza con lo básico, prueba, ajusta y evoluciona. Con cada política que implementes, estarás construyendo una fortaleza digital más sólida. La ciberseguridad efectiva no se trata de tener todas las respuestas, sino de hacer las preguntas correctas y actuar con determinación.

Una buena herramienta es What If. Accede desde aquí a su funcionamiento Lo más importante es que sea simple. No te vuelvas loco. Cuando nos complicamos y nos desviamos demasiado, es cuando terminamos bloqueándonos y corriendo a buscar nuestras cuentas de emergencia.

Para finalizar, a modo de conclusión, espero que esto haya sido útil. La realidad con las PAC de Entra ID es que probablemente tendremos algunos altibajos. Debemos asegurarnos de enfatizar la necesidad de aprovechar la opción Solo informes y monitorear para comprobar y analizar cómo funcionan nuestras políticas y cómo afectan en el día a día de nuestra Gestión de Identidades.

Sobre todo, muy importante, que al activar una política no nos quedemos sin acceso y no tengamos una cuenta de emergencia.

Nos vemos en las Redes!!