Dominando las políticas de acceso condicional de Microsoft Entra ID: una guía completa

Hello EveryOne!! Querido y estimado lector de Obss, diseñar una implementación sólida de acceso condicional (CA) es básico aparte de fundamental para proteger nuestras aplicaciones y nuestros recursos, lo más protegido posible .

Las políticas de CA de Microsoft Entra ID nos ofrecen amplias opciones de configuración, lo que nos va a permitir a los departamentos de TI personalizar los controles de acceso con precisión. Sin embargo, esta flexibilidad requiere una planificación meticulosa, de nuestra parte, para evitar consecuencias no deseadas.

Si quieres profundizar en las políticas CA te dejo unos enlaces que te van a resultar muy productivos.

• 8 políticas de CA que todo profesional debe conocer.
• Implementación efectiva de políticas de CA en entornos Microsoft 365

Comencemos explorando las políticas de CA en profundidad

Qué son las CA?

El perímetro de seguridad moderno ahora incluye identidades de usuarios y recursos, lo que requiere señales basadas en identidades para el control de acceso. Microsoft Entra CA centraliza todas estas señales para aplicar las políticas de la organización, lo que forma la columna vertebral del motor de políticas Zero Trust Architecture de Microsoft.

Si quieres profundizar en la arquitectura ZTA te dejo la Guía Fortaleciendo la Seguridad: Guía Práctica de Arquitectura de Confianza Cero

Las políticas de CA funcionan con una lógica simple de if-then, es decir, si un usuario desea acceder a un recurso, debe realizar una acción específica, como la autenticación multifactor.

Los CIO / CISO, tenemos dos grandes objetivos principales en nuestro guideline de trabajo:

• Potenciar la productividad de los usuarios
• Proteger los recursos de la organización.

Las CA nos van a ayudar a lograrlo aplicando los controles adecuados en el momento adecuado, equilibrando la seguridad con la productividad (usabilidad vs seguridad).

Las CA van a devenir en fundamentales para el marco de confianza cero de Microsoft. Si bien los valores predeterminados de seguridad de Entra ID nos brindan protección básica, las CA nos ofrecen un control granular, lo que nos va a permitir una seguridad personalizada más allá de las configuraciones predeterminadas.

Es muy importante comprender que las políticas de CA se aplican después de que se completa el primer factor de autenticación. Si bien las CA no están diseñado para ser la defensa principal contra situaciones como ataques de denegación de servicio (DoS), podemos utilizar señales de dichos eventos para fundamentar decisiones de acceso.

Requisitos previos para una eficaz implementación de políticas CA

Para configurar políticas de CA, debemos de asegurarnos de cumplir los siguientes requisitos previos:

• Tenant de Microsoft Entra: Debemos disponer de un inquilino activo con Microsoft Entra ID P1, P2 o una licencia de prueba. Microsoft Entra ID P2 es esencial para integrar el riesgo de protección de Microsoft Entra ID en las políticas de acceso condicional
• Roles administrativos:
  • Administrador global o administrador de CA: para crear o modificar políticas.
  • Lector de seguridad:  para leer políticas y configuraciones. (Opcionalmente, para revisión de políticas sin calificación de roles con privilegios altos)
• Usuarios o  Grupos: para identificarse y para orientar las asignaciones o exclusiones de políticas

Cuáles son los componentes básicos de las políticas de CA.

Las políticas de CA funcionan, como hemos comentado con anterioridad, según el principio de escenarios if-then:

• Si se cumple la asignación : aplicamos los controles de acceso.
• Ejemplo: si un usuario del departamento de administración intenta acceder a la aplicación de RR.HH. , se le va a requerir  autenticación multifactor (MFA) y un recurso compatible .
• Ejemplo: Si un usuario no es miembro de RR.HH. y accede a la aplicación de RR.HH., de forma automática se bloquea el acceso .

Podemos diseñar políticas para otorgar acceso, aplicar controles de sesión o bloquear el acceso según estas condiciones.

Que son la exclusiones y que debemos tener en cuenta:

Una exclusión en una política de CA es una configuración técnica que especifica ciertas condiciones bajo las cuales, las reglas de la política no se aplican, permitiendo así que usuarios, recursos o aplicaciones específicos accedan a los recursos sin cumplir con los requisitos de seguridad establecidos en la política principal.

Es importante notar que mientras las exclusiones proporcionan flexibilidad, también nos representan potenciales vulnerabilidades si no las gestionamos adecuadamente.

Desde un punto de vista técnico, las exclusiones en CA funcionan de la siguiente manera:

• Definición de excepciones: Se especifican criterios precisos para identificar entidades (usuarios, grupos, dispositivos, aplicaciones) que estarán exentas de las restricciones de la política.
• Evaluación prioritaria: El sistema evalúa las exclusiones antes de aplicar las reglas principales de la política, permitiendo un bypass eficiente para las entidades excluidas.
• Granularidad: Las exclusiones pueden configurarse a varios niveles:
  • A nivel de usuario o grupo de usuarios
  • Por tipo de recurso o estado del recurso
  • Para aplicaciones o servicios específicos
  • Basadas en ubicación de red o dirección IP
• Condiciones temporales: Pueden establecerse exclusiones con limitaciones de tiempo, activándose solo durante períodos específicos o en situaciones de emergencia.
• Integración con sistemas de identidad: Las exclusiones suelen aprovechar los atributos y metadatos almacenados en directorios como Azure AD o Active Directory on-premises.
• Logging y auditoría: Las acciones realizadas bajo una exclusión, deben registrarse separadamente para facilitar la monitorización y cumplimiento normativo.
• Herencia y precedencia: En entornos con múltiples políticas, se definen reglas claras sobre cómo las exclusiones en una política interactúan o anulan las reglas en otras.
• Scope de aplicación: Las exclusiones pueden limitarse a ciertos recursos o aplicaciones, permitiendo un acceso selectivo mientras se mantienen otras restricciones.
• Factores de riesgo: Algunas implementaciones avanzadas permiten exclusiones dinámicas basadas en el nivel de riesgo calculado en tiempo real.
• Failsafe mechanisms: Se pueden implementar exclusiones como mecanismo de seguridad para garantizar el acceso de administradores críticos en caso de mal funcionamiento de la política principal.
• API y automatización: Las exclusiones pueden gestionarse programáticamente a través de APIs, permitiendo una gestión dinámica basada en eventos del sistema o procesos de negocio.

Por lo tanto, al crear políticas de CA potentes, debe excluir:

• Cuentas de acceso de emergencia: esenciales para recuperar el acceso en caso de un bloqueo de todo el tenant.
• Cuentas de servicio: generalmente no interactivas y no pueden completar MFA.

Debemos considerar reemplazar estas cuentas con identidades administradas o excluirlas temporalmente de nuestras políticas de CA de referencia del tenant.

Mejores prácticas para el acceso condicional en Entra ID

• Aplicar políticas a todas las aplicaciones: crearemos políticas integrales para todas las aplicaciones en la nube y excluiremos las excepciones. Esto nos garantiza una aplicación uniforme y nos reducirá la sobrecarga administrativa.
• Minimizar la cantidad de políticas: evitaremos crear políticas individuales excesivas. Es necesario agrupar las aplicaciones con requisitos similares en políticas únicas para no exceder el límite de 195 políticas y simplificar la administración.
• Utilizar el modo de solo informes: probaremos las políticas utilizando el modo de solo informes para evaluar el impacto antes de la implementación completa. Aprovecharemos los registros de inicio de sesión y la información del acceso condicional para la evaluación.
• 4. Establecer estándares de nombres para sus políticas:  Utilizaremos un estándar de nombres coherente que nos facilite la identificación de políticas y la comprensión de su función sin necesidad de abrirlas en el portal de administración de Entra ID. Microsoft sugiere que los nombres de sus políticas incluyan: un número de secuencia, las aplicaciones en la nube, la política a la que se aplica, la respuesta prevista, los usuarios o grupos de destino y las condiciones en las que se aplica.

Cuáles son las principales políticas de CA

CA001-Requerir MFA para administradores

Las cuentas con derechos administrativos son los principales objetivos de los ciberatacantes. Es necesario que implementemos una autenticación multifactor (MFA) para estas cuentas, ya que es una forma sencilla de que reduzcamos el riesgo de vulneración. Microsoft recomienda aplicar la MFA al menos para los siguientes 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 Exchange
• Administrador de soporte técnico
• Administrador de contraseñas
• Administrador de autenticación con privilegios
• Administrador de roles con privilegios
• Administrador de seguridad
• Administrador de SharePoint
• Administrador de usuarios

Exclusiones de usuarios:

• Cuentas de acceso de emergencia para evitar un bloqueo en todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Estas son cuentas no interactivas que no están asociadas con ningún usuario específico.

Las llamadas realizadas por las entidades de servicio no están bloqueadas por las políticas de CA dirigidas a los usuarios. Para proteger las entidades de servicio, use el CA para identidades de carga de trabajo, que requiere una licencia de identidades de carga de trabajo de Entra ID, para definir políticas dirigidas a estas identidades.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto nos garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA002-Requerir autenticación multifactor resistente a phishing para administradores

Como hemos explicado en el CA001, las cuentas asignadas a roles administrativos privilegiados suelen ser los principales objetivos de los ciberatacantes. Implementando una autenticación multifactor (MFA) resistente al phishing para estas cuentas reduciremos el riesgo de vulneración. Microsoft recomienda aplicar una MFA resistente al phishing al menos para los siguientes 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 Exchange
• Administrador del Helpdesk
• Administrador de contraseñas
• Administrador de autenticación privilegiada
• Administrador de roles privilegiados
• Administrador de seguridad
• Administrador de SharePoint
• Administrador de usuarios

Los departamentos de TI podemos optar por personalizar estas recomendaciones, incluyendo o excluyendo roles según nuestras necesidades específicas. Estas políticas es posible combinarlas de manera eficaz con funciones como la gestión de identidades privilegiadas (PIM), que nos permite que se requiera la autenticación multifactor al activar un rol.

Requerimiento de MFA en la activación de roles

Podemos mejorar la seguridad al exigir que los usuarios que cumplen los requisitos para un rol se autentiquen mediante MFA en Microsoft Entra ID (PIM) antes de activar su rol. MFA nos agrega una capa crítica de seguridad al requerir una segunda forma de autenticación, lo que protege el acceso a datos y aplicaciones confidenciales.

Sin embargo, es posible que no se les solicite a los usuarios la MFA si ya se han autenticado con credenciales seguras o han completado la MFA anteriormente en la sesión.

Para garantizar que los usuarios se autentiquen durante la activación de roles, podemos aprovechar las CA con contexto de autenticación y fortalezas de autenticación . Esto nos va a garantizar que los usuarios se autentiquen con un método diferente al que usaron para iniciar sesión en la máquina.

Por ejemplo, si los usuarios inician sesión con Windows Hello para empresas, podemos exigir un inicio de sesión sin contraseña con Microsoft Authenticator para la activación de roles. Una vez que los usuarios se autentiquen con Microsoft Authenticator, no necesitaremos que los usuarios se autentiquen nuevamente para las activaciones posteriores en la misma sesión, ya que la autenticación ya forma parte de su token de sesión.

Si quieres tener acceso a una guía de Configuración de FIDO2 pulsa en el siguiente enlace.

Exclusiones de usuarios 

• Acceso de emergencia o cuentas de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y directores de servicio

Las llamadas realizadas por las entidades de servicio no están bloqueadas por las políticas de CA dirigidas a los usuarios. Para proteger las entidades de servicio, use el CA para identidades de carga de trabajo, que requiere una licencia de identidades de carga de trabajo de Entra ID, para definir políticas dirigidas a estas identidades.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto nos garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA003-Permitir el registro de información de seguridad desde todas las ubicaciones de confianza

La protección del proceso de registro para la autenticación multifactor de Microsoft Entra ID y el restablecimiento de contraseñas por cuenta propia se puede gestionar mediante acciones del usuario dentro de una política de acceso condicional.

Esta capacidad está disponible para las organizaciones que han habilitado el registro combinado. Nos permite tratar el proceso de registro como cualquier otra aplicación dentro de una política de acceso condicional, aprovechando la gama completa de características de acceso condicional para proteger la experiencia del usuario. Esta política también es aplicable a los usuarios que inician sesión en la aplicación Microsoft Authenticator o que habilitan el inicio de sesión telefónico sin contraseña.

Hasta ahora, existían organizaciones que dependían de ubicaciones de red confiables o de la conformidad de los dispositivos para garantizar la seguridad de la experiencia de registro. Sin embargo, con la introducción del Pase de acceso temporal en Microsoft Entra ID, los administradores ahora podemos emitir credenciales limitadas en el tiempo que permiten a los usuarios registrarse desde cualquier dispositivo o ubicación. Estas credenciales de Pase de acceso temporal cumplen con los requisitos de acceso condicional para la autenticación multifactor, lo que garantiza un proceso de registro seguro y flexible.

Nota: Los administradores debemos emitir credenciales de Pase de acceso temporal a los nuevos usuarios para que puedan satisfacer los requisitos de autenticación multifactor para registrarse.

Nota: Los departamentos de TI podremos optar por exigir otros controles de concesión junto con o en lugar de  Requerir autenticación multifactor . Al seleccionar varios controles, asegúrese de seleccionar el botón de opción apropiado para exigir  Para varios controles

• Requerir todos los controles seleccionados
• Requerir uno de los controles seleccionados

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA004-Bloquear el registro de información de seguridad de usuarios invitados o externos fuera de redes confiables

Para los usuarios invitados que necesiten registrarse para la autenticación multifactor en su directorio, es posible que desee bloquear el registro desde ubicaciones de red confiables externas. Tenga en cuenta que el Pase de acceso temporal no se aplica a los usuarios invitados.

CA005-Bloquear la autenticación heredada

Debido a los mayores riesgos asociados con los protocolos de autenticación heredados, Microsoft recomienda que bloqueemos las solicitudes de autenticación que utilizan estos protocolos y apliquen en su lugar la autenticación moderna.

Los siguientes protocolos de mensajería se basan en la autenticación heredada:

• SMTP autenticado: se utiliza para enviar mensajes de correo electrónico autenticados.
• Detección automática: ayuda a los clientes de Outlook y Exchange ActiveSync (EAS) a localizar y conectarse a buzones de correo en Exchange Online.
• Exchange ActiveSync (EAS): se utiliza para conectarse a buzones de correo en Exchange Online.
• PowerShell de Exchange Online: se conecta a Exchange Online con PowerShell remoto. Si la autenticación básica está bloqueada para PowerShell de Exchange Online, se debe utilizar el módulo PowerShell de Exchange Online. 
• Servicios web de Exchange (EWS): una interfaz de programación utilizada por Outlook, Outlook para Mac y aplicaciones que no son de Microsoft.
• IMAP4: Utilizado por clientes de correo electrónico IMAP.
• MAPI sobre HTTP (MAPI/HTTP): el protocolo de acceso al buzón principal utilizado por Outlook 2010 SP2 y versiones posteriores.
• - Libreta de direcciones sin conexión (OAB): una copia descargable de las colecciones de listas de direcciones utilizadas por Outlook.
• - Outlook Anywhere (RPC sobre HTTP): un protocolo de acceso a buzones de correo heredado compatible con todas las versiones actuales de Outlook.
• - POP3: Utilizado por clientes de correo electrónico POP.
• - Servicios web de informes: recupera datos de informes en Exchange Online.
• - Outlook universal: utilizado por la aplicación Correo y Calendario en Windows 10.

Exclusiones de usuarios 

Cuentas de servicio y entidades de servicio (que utiliza cualquier aplicación heredada), como la cuenta de retransmisión de correo electrónico de la aplicación. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Si utilizamos políticas de CA independientes, el acceso a las cuentas de servicio solo se debe permitir desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados. 

CA006-Requerir autenticación multifactor para el acceso de invitados

Exigir que los usuarios invitados realicen una autenticación multifactor al acceder a los recursos de su organización.

CA007-Requerir MFA para todos los usuarios

La autenticación multifactor es esencial para nuestros usuarios porque añade una capa adicional de seguridad más allá de una simple contraseña. Las contraseñas se pueden vulnerar fácilmente mediante phishing, ataques de fuerza bruta u otros métodos, pero la autenticación multifactor requiere un paso de verificación adicional, como un código de una aplicación móvil o un escaneo biométrico.

Esto hace que sea mucho más difícil para los atacantes obtener acceso no autorizado, lo que protege nuestros datos y sistemas confidenciales de las infracciones. En la actualidad, confiar únicamente en las contraseñas, simplemente, no es suficiente para que garantizemos la seguridad de nuestros usuarios y nuestra organización.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

 Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

Exclusión de aplicaciones

Las organizaciones que utilizan la función de Activación de suscripción para permitir que los usuarios actualicen de una versión de Windows a otra e implementen políticas de CA para controlar el acceso deben excluir la siguiente aplicación en la nube de sus políticas de CA mediante la opción “ Seleccionar aplicaciones en la nube excluidas “. 

• Tienda Windows para Empresas, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f.

Esta exclusión es fundamental porque, si un dispositivo permanece sin conexión durante un período prolongado, es posible que no se reactive automáticamente sin esta exclusión de acceso condicional. Garantizando esta exclusión permitimos que la activación de la suscripción funcione sin problemas y sin interrupciones.

De manera similar, para garantizar que los escenarios de inscripción automática de dispositivos funcionen correctamente, Microsoft Intune y la inscripción automática de Microsoft Intune también deben excluirse de las políticas de CA. Esta exclusión es necesaria para una inscripción automática de dispositivos sin inconvenientes.

Nota: A partir de Windows 11, versión 23H2 con KB5034848 o posterior, se les solicitará a los usuarios que se autentiquen mediante una notificación cuando la activación de la suscripción requiera una reactivación. La notificación muestra el siguiente mensaje:

“Su cuenta requiere autenticación. Inicie sesión en su cuenta de trabajo o escuela para verificar su información”.

Además, el panel de Activación puede mostrar el siguiente mensaje:

“Inicie sesión en su cuenta laboral o escolar para verificar su información”.

CA008: Requerir MFA para la administración de Azure

Las organizaciones a menudo utilizan varios servicios de Azure y los administran a través de herramientas basadas en Azure Resource Manager, como:

• Portal de Azure
• PowerShell de Azure
• CLI de Azure

Estas herramientas nos otorgan un acceso altamente privilegiado a los recursos, lo que permite a los usuarios realizar cambios significativos, incluidos:

• Modificación de configuraciones a nivel de suscripción
• Ajuste de la configuración del servicio
• Gestión de la facturación de suscripciones

Para proteger estos recursos confidenciales, Microsoft recomienda exigir la autenticación multifactor (MFA) a cualquier usuario que acceda a ellos.

En Microsoft Entra ID, estas herramientas se agrupan en la suite API de administración de servicios de Windows Azure. Para Azure Government, la suite equivalente es la aplicación API de administración de la nube de Azure Government .

Cuando utilizamos la aplicación API de administración de servicios de Windows Azure, la política se aplica a los tokens emitidos a un conjunto de servicios estrechamente integrados con el portal, que incluye los identificadores de aplicación para:

• Administrador de recursos de Azure
• Portal de Azure, incluido el centro de administración de Microsoft Entra
• Lago de datos de AzureAPI de información sobre aplicaciones
• API de análisis de registros

Dado que esta política se aplica al portal de administración y a la API de Azure, podemos afectar indirectamente a los servicios o clientes que dependen de la API de Azure. Por ejemplo:

• CLI de Azure
• Portal de Azure Data Factory
• Azure DevOps
• Centros de eventos de Azure
• PowerShell de Azure
• Bus de servicio de Azure
• Base de datos SQL de Azure
• Sinapsis de Azure
• API del modelo de implementación clásico
• Centro de administración de Microsoft 365Centro de IoT de Microsoft
• Instancia administrada de SQL
• Portal del administrador de suscripciones de Visual Studio

Nota: La aplicación API de administración de servicios de Windows Azure se aplica a Azure PowerShell, que interactúa con la API de Azure Resource Manager. Sin embargo, no se aplica a Microsoft Graph PowerShell, que interactúa con la API de Microsoft Graph.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA009-Inicio de sesión con autenticación multifactor basada en riesgos

En la mayoría de los casos, los usuarios muestran un comportamiento constante que es posible rastrear. Sin embargo, cuando un usuario se desvía de esta norma, puede resultar muy peligroso que le permitamos iniciar sesión sin una verificación adicional. En tales situaciones, podemos considerar bloquear al usuario o exigirle que complete la autenticación multifactor (MFA) para confirmar su identidad.

Un riesgo de inicio de sesión refleja la probabilidad de que el propietario legítimo de la identidad no realice un intento de autenticación específico. Para las organizaciones con licencias Microsoft Entra ID P2 , se pueden crear políticas de acceso condicional que incorporen las detecciones de riesgo de inicio de sesión de Microsoft Entra ID Protection .

Las políticas de inicio de sesión basadas en riesgos ayudan a proteger a los usuarios al evitar que se registren para MFA durante sesiones de riesgo. Si los usuarios no se han registrado para MFA, bloqueamos sus inicios de sesión de riesgo, lo que generará un mensaje de error AADSTS53004 .

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA010-Cambio de contraseña en función del riesgo del usuario

Microsoft colabora con investigadores, fuerzas de seguridad, equipos de seguridad interna y otras fuentes de confianza para identificar combinaciones de nombres de usuario y contraseñas filtradas. Mediante las licencias Microsoft Entra ID P2 podemos aprovechar esta información creando políticas de acceso condicional que incorporen detecciones de riesgo de usuario proporcionadas por Microsoft Entra ID Protection.

Microsoft Entra ID Protection nos proporciona a los departamentos de TI información valiosa sobre actividades sospechosas dentro de nuestro inquilino, lo que nos permite armar respuestas rápidas para evitar riesgos adicionales. Estas detecciones de riesgos son una herramienta poderosa, capaz de identificar actividades sospechosas o anómalas relacionadas con las cuentas de usuario en el directorio.

Con las detecciones de riesgo de usuario podemos marcar una cuenta legítima como de riesgo si un ciberatacante compromete las credenciales o si detectamos una actividad inusual del usuario. Las detecciones de riesgo de inicio de sesión lo que hacen es calcular la probabilidad de que el propietario legítimo de la cuenta no realice un intento de autenticación. La capacidad de detectar riesgos tanto a nivel de usuario como de inicio de sesión es crucial para que los departamentos de TI protejamos eficazmente a nuestros usuarios .

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA011-Bloquear el acceso a usuarios con riesgo interno

Como hemos reflejado en el punto anterior, la mayoría de los usuarios presentan un comportamiento predecible que se puede monitorizar. Sin embargo, cuando un usuario se desvía de su patrón normal, puede representar un riesgo de seguridad. Para gestionar esto, podemos optar por bloquear al usuario o exigirle que revise una política de términos de uso específica. Con Microsoft Purview podemos mejorar las decisiones de control de acceso al proporcionar señales de riesgo interno a CA , lo que nos puede ser especialmente valioso para gestionar posibles amenazas internas.

La gestión de riesgos internos de Microsoft Purview (incluida en la licencia M365 E5), debe estar habilitada para usar sus señales en el CA , tiene en cuenta la gobernanza de datos, la seguridad de los datos y las configuraciones de cumplimiento.

Estas señales, basadas en factores como el comportamiento del usuario, los patrones históricos y la detección de anomalías, nos permiten crear políticas de CA que respondan a los riesgos internos bloqueando el acceso, exigiendo una autenticación más sólida o imponiendo la aceptación de los términos de uso .

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA012-Requiere dispositivo compatible

Microsoft Intune y Microsoft Entra colaboran para mejorar la seguridad de nuestra organización mediante el uso de políticas de cumplimiento de dispositivos y CA.

Las políticas de cumplimiento de dispositivos en Intune son herramientas esenciales para que podamos garantizar que los recursos de los usuarios cumplan con los estándares de configuración necesarios antes de acceder a los servicios protegidos.

Mediante estas políticas imponemos una serie de requisitos mínimos, entre otros, configuraciones de seguridad, versiones de SO, etc., que se verifican cuando los usuarios intentan acceder a servicios regidos por políticas de CA.

Para que las políticas de CA funcionen como esperamos, es fundamental contar con una política de cumplimiento en Microsoft Intune. Sin ella, es posible que la política de CA no aplique los controles necesarios. Por lo tanto, se recomienda crear primero una política de cumplimiento y asegurarse de que al menos un dispositivo cumpla con las normas antes de continuar con las configuraciones de acceso condicional.

Incluso si configuramos la política de CA en Requerir que el dispositivo esté marcado como compatible para todos los usuarios y todas las aplicaciones en la nube, no bloquearemos la inscripción de nuevos dispositivos en Intune.

Esto significa que aún podemos inscribir recursos en Intune, lo que nos permitirá cumplir con las normas y, por lo tanto, garantizar que cumplan con los requisitos de seguridad implantados antes de obtener acceso a recursos confidenciales.

Al configurar e integrar correctamente las políticas de cumplimiento de Intune con Microsoft Entra CA, podemos mantener una postura de seguridad sólida, lo que nos garantiza que solo los dispositivos que cumplen con las normas puedan acceder a los recursos críticos. Este enfoque proporciona una experiencia de usuario segura y sin inconvenientes, al mismo tiempo que protege los datos de su organización.

Una muy buena práctica es comprobar como actuaria la política con la herramienta What If. Accede a la guía de uso de la herramienta.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA013-Requiere dispositivo compatible o híbrido unido a Microsoft Entra para administradores

Las cuentas con derechos administrativos son los principales objetivos de los ciberatacantes, por motivos obvios. Para reducir nuestra superficie de ataque, es una mejor práctica que los usuarios con estos roles altamente privilegiados realicen acciones solo desde recursos que estén marcados como compatibles o unidos a Microsoft Entra híbrido:

• 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 Exchange
• Administrador del Helpdesk
• Administrador de contraseñas
• Administrador de autenticación privilegiada
• Administrador de roles privilegiados
• Administrador de seguridad
• Administrador de SharePoint
• Administrador de usuarios

Los departamentos de Ti tenemos la flexibilidad de incluir o excluir roles según sea necesario para adaptarse mejor a sus requisitos de seguridad.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA014-Bloquear el acceso a plataformas de dispositivos desconocidos o no compatibles

A los usuarios se les impide acceder a los recursos de la empresa si su tipo de recursos es desconocido o no es compatible.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA015-Requerir aplicaciones de cliente aprobadas o una política de protección de aplicaciones

Los usuarios son suelen utilizar sus dispositivos móviles para tareas personales y laborales. Si bien es muy importante que garanticemos que el personal siga siendo productivo, los departamentos de TI también debemos evitar la pérdida de datos de las aplicaciones en recursos que no se pueden administrar por completo.

Con las CA, los departamentos de TI podemos restringir el acceso a las aplicaciones cliente aprobadas que admiten la autenticación moderna mediante políticas de protección de aplicaciones de Intune.

En el caso de las aplicaciones cliente más antiguas que no admiten políticas de protección de aplicaciones, los administradores podemos limitar el acceso solo a las aplicaciones aprobadas. Las políticas de protección de aplicaciones son compatibles con iOS y Android para las aplicaciones que cumplen requisitos específicos. En Windows, estas políticas están actualmente en versión preliminar y solo son compatibles con el navegador Microsoft Edge.

Es importante tener en cuenta que no todas las aplicaciones compatibles como aplicaciones aprobadas o aquellas que admiten políticas de protección de aplicaciones aplicarán la opción  Requerir uno de los controles seleccionados  en los controles de concesión. Esta opción funciona como una cláusula OR dentro de la política, lo que permite a los usuarios acceder a las aplicaciones que admiten los controles de concesión Requerir política de protección de aplicaciones  o  Requerir aplicación cliente aprobada. La opción  Requerir política de protección de aplicaciones se aplica cuando la aplicación admite este control de concesión específico.

Exclusión de aplicaciones

La aplicación de inscripción de Microsoft Intune/Intune debe excluirse de esta política.

CA016-Requerir una política de protección de aplicaciones en dispositivos Windows

Las políticas de protección de aplicaciones aplican a la gestión de aplicaciones móviles (MAM) específicas en un recurso, lo que nos va a a permitir el manejo seguro de datos dentro de una aplicación, en particular en escenarios BYOD.

Este enfoque nos permite habilitar el acceso MAM protegido a los datos de la organización a través de Microsoft Edge en dispositivos Windows personales, una capacidad conocida como Windows MAM. 

MAM aprovecha las políticas de configuración de aplicaciones (ACP) de Intune, las políticas de protección de aplicaciones (APP) de Intune, la defensa contra amenazas del cliente del Centro de seguridad de Windows y las CA a la protección de aplicaciones para proteger los datos en recursos no administrados. Si un recurso ya está administrado, se bloqueará la inscripción en Intune MAM y no se aplicarán las configuraciones de la aplicación.

De manera similar, si un recurso pasa a ser administrado después de la inscripción en MAM, las configuraciones de la aplicación dejarán de aplicarse.

Existen dos categorías principales de configuraciones de políticas de protección de aplicaciones para Windows:

• Protección de datos
• Controles de salud

A la redacción de este artículo, esta política de MAM se aplica al navegador Microsoft Edge en recursos que ejecutan Windows 11 y Windows 10 versión 20H2 o superior con KB5031445. Esto incluye la configuración de políticas de protección de aplicaciones dirigidas específicamente a dispositivos Windows.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA017 Requerir nueva autenticación y deshabilitar la persistencia del navegador en recursos no administrados

Para proteger el acceso de los usuarios en recursos no administrados, configuraremos el navegador para evitar que las sesiones permanezcan iniciadas después de cerrarlo y configuraremos la frecuencia de inicio de sesión para que requiera una nueva autenticación cada hora o el tiempo que se estime.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA018-Requiere un dispositivo compatible, dispositivo híbrido unido a Microsoft Entra para todos los usuarios

Los departamentos de Ti que implementamos Microsoft Intune podemos usar la información del dispositivo para identificar aquellos que cumplen con requisitos de cumplimiento específicos, como:

• Requerir un PIN para desbloquear el dispositivo
• Requerir cifrado del dispositivo
• Imponer una versión mínima o máxima del sistema operativo
• Asegurarse de que el dispositivo no esté jailbreakeado ni rooteado

Esta información de cumplimiento es enviada a Microsoft Entra ID, donde las CA determinan si se debe otorgar o bloquear el acceso a los recursos.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA019-Uso de restricciones impuestas por la aplicación (EXO, SPO, OFB) para recursos no administrados

Bloquear o limitar el acceso al contenido de SharePoint, OneDrive y Exchange desde dispositivos no administrados.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA020-Requerir autenticación multifactor para el registro del dispositivo

Vamos a aprovechar la acción de usuario de CA para aplicar políticas cuando los usuarios registren o unan dispositivos a Microsoft Entra ID. Este control nos va a permitir una configuración más granular de la autenticación multifactor específicamente para el registro o la unión de recursos, en lugar de aplicar una política general para todo el inquilino. Podemos adaptar esta política para cumplir con los requisitos de seguridad específicos implementados.

Al configurar una política de CA con la acción de usuario Registrar o unir dispositivos, es importante que tengamos configurado Identidad > Dispositivos > Descripción general > Configuración del dispositivo: Requerir autenticación multifactor para registrar o unir dispositivos con Microsoft Entra en No. De lo contrario, las políticas de acceso condicional vinculadas a esta acción de usuario no se aplicarán correctamente.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA021-Bloquear el acceso según la ubicación de la red

La CA de ubicación en el acceso condicional nos va a permitir administrar el acceso a nuestras aplicaciones en la nube en función de la ubicación de red de un usuario. Esta condición la vamos a utilizar para bloquear el acceso desde países o regiones desde donde nuestra organización no espera tráfico.

Nota: Las políticas de CA se aplican después de que se completa la autenticación de primer factor. Si bien el CA no está diseñado como la defensa principal contra situaciones como ataques de denegación de servicio (DoS), podemos utilizar señales de dichos eventos para fundamentar las decisiones de acceso.

Siga estos pasos para configurar ubicaciones con nombre

Iniciaremos sesión en el centro de administración de Microsoft Entra con al menos privilegios de administrador de CA.

Vaya a Protección > Acceso condicional > Ubicaciones con nombre

Seleccioneremos el tipo de ubicación que desea crear:

Ubicación de países/regiones  -> Nombra tu ubicación

o ubicación de rangos de IP 

Introduciremos los rangos de IP o seleccione los países/regiones para la ubicación especificada.

Si seleccionamos rangos de IP, tendremos la opción de marcarlos como una ubicación confiable.

Si elegimos Países/Regiones, también podemos optar por incluir áreas desconocidas.

Por último, haremos clic en Crear .

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA022-Requerir un nivel de autenticación alto para usuarios externos

La fortaleza de la autenticación es un control de CA que nos va a permitir especificar una combinación de métodos de autenticación multifactor (MFA) que los usuarios externos deben completar para acceder a sus recursos.

Este control es particularmente útil para proteger aplicaciones confidenciales del acceso externo. Por ejemplo, podemos crear una política de CA que requiera una fortaleza de autenticación resistente a la suplantación de identidad y aplicarla a invitados y usuarios externos.

Microsoft Entra ID ofrece tres niveles de autenticación integrados:

• Fortaleza de autenticación multifactorial
• Fortalecimiento de MFA sin contraseña
• Fortalecimiento de MFA resistente a phishing.

Podemos elegir una de estas fortalezas integradas o podemos inclinarnos por crear una personalizada según los métodos de autenticación requeridos.

Para los usuarios externos, los métodos de autenticación multifactor aceptables varían según si el usuario realiza la autenticación multifactor en su inquilino local o en el inquilino.

Actualmente, las políticas de solidez de la autenticación se aplican solo a los usuarios externos que se autentican con Microsoft Entra ID. Para los usuarios que usan códigos de acceso de un solo uso por correo electrónico, SAML/WS-Fed o la federación de Google, utilizaremos el control de concesión de autenticación multifactor en su lugar.

Las políticas de fortaleza de la autenticación funcionan con la configuración de confianza de MFA en la configuración de acceso entre inquilinos para determinar dónde y cómo los usuarios externos realizan la MFA. Cuando un usuario externo inicia sesión con su cuenta en su inquilino local y luego intenta acceder a sus recursos, Microsoft Entra ID verifica la política de CA de fortaleza de la autenticación y la configuración de confianza de MFA:

• Si la confianza de MFA está habilitada, Microsoft Entra ID verifica si la sesión de inquilino local del usuario tiene una reclamación de que se completó la MFA.
• Si la confianza de MFA está deshabilitada, el inquilino del recurso requiere que el usuario complete la MFA en el inquilino del recurso utilizando un método aprobado.

Antes de crear una política de CA, debemos revisar nuestra configuración de acceso entre inquilinos para asegurarnos de que nuestras configuraciones de confianza de MFA entrante estén configuradas correctamente.

Para crear una fortaleza de autenticación, iniciaremos sesión en el centro de administración de Microsoft Entra con privilegios de administrador de acceso condicional. Nos dirigiremos a;: 

Protección > Métodos de autenticación > Niveles de autenticación .

Revisaremos las fortalezas de autenticación integradas disponibles para determinar si alguna satisface nuestras necesidades.

Si necesitamos una combinación diferente de métodos de autenticación, crearemos una fortaleza de autenticación personalizada.

CA023-Requerir que se acepten los términos de uso antes de acceder a los portales de administración de Microsoft

Es posible que los departamentos de TI exijamos a los usuarios o administradores que acepten los términos de uso (ToU) antes de acceder a aplicaciones específicas dentro de nuestro entorno. Crearemos una política que requiera que los administradores acepten los términos de uso durante el proceso de inicio de sesión inicial en cualquier portal de administración de Microsoft.

Nota: Puede agregar hasta 40 términos de uso por inquilino.

Crearemos un nuevo documento de términos de uso y lo guardaremos como un archivo PDF. Iniciaremos sesión en el centro de administración de Microsoft Entra con  privilegios mínimos de administrador de acceso condicional. Nos dirigiremos a: 

Protección > Acceso condicional > Condiciones de uso .

Haremos clic en Nuevos términos en la parte superior del menú.

Introduciremos un nombre para nuestra política de términos de uso en el cuadro de texto Nombre .

Subiremos el archivo PDF de términos de uso .

Seleccionaremos el idioma predeterminado.

En el cuadro de texto  Nombre para mostrar, introduciremos el nombre que desemos que se muestre.

Estableceremos Requerir que los usuarios amplíen los términos de uso  en Activado .

Para aplicar con plantillas de políticas de acceso condicional , seleccionaremos Crear política de acceso condicional más tarde

Haremos clic en  Crear para finalizar nuestra política.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA024-Bloquear flujos de código de dispositivo para todos los usuarios

Para mejorar nuestra postura de seguridad, Microsoft recomienda bloquear o restringir el flujo de código del dispositivo siempre que sea posible. Lo ideal sería que los departamentos de TI implementáramos un bloqueo casi universal del flujo de código del recurso. Es recomendable crear una política para auditar el uso actual del flujo de código del dispositivo y evaluar su necesidad.

Microsoft Entra ID admite una amplia gama de flujos de autenticación y autorización para garantizar una experiencia fluida en distintas aplicaciones y tipos de dispositivos. Sin embargo, algunos de estos flujos suponen un mayor riesgo que otros.

Para dar a los departamentos de TI más control sobre nuestra postura de seguridad, Microsoft presenta la capacidad de administrar flujos de autenticación específicos a través del CA, comenzando con el flujo de código del recurso.

El flujo de código de dispositivo se utiliza habitualmente para iniciar sesión en recursos que carecen de dispositivos de entrada locales, como dispositivos compartidos o señalización digital. Sin embargo, se considera un flujo de autenticación de alto riesgo y es posible que pueda ser explotado en ataques de phishing o para acceder a recursos corporativos desde recursos no administrados.

Podemos configurar el control de flujo de código de dispositivo dentro de sus políticas de CA junto con otros controles de seguridad. Por ejemplo, si el flujo de código de dispositivo es necesario para recursos de salas de conferencias basados ​​en Android, podemos bloquearlo de forma universal, excepto para dispositivos Android dentro de una ubicación de red específica.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

CA025-Bloquear flujos de transferencia de autenticación para todos los usuarios

La transferencia de autenticación es un nuevo flujo que permite a los usuarios transferir sin problemas su estado autenticado de un recurso a otro.

Por ejemplo, los usuarios pueden escanear un código QR en la versión de escritorio de Outlook con su dispositivo móvil para transferir su sesión autenticada al dispositivo móvil, lo que proporciona una experiencia de usuario fluida e intuitiva.

La capacidad de controlar la transferencia de autenticación se encuentra actualmente en versión preliminar. Podemos administrar esta función mediante la condición Flujos de autenticación en CA.

Nota: A partir de principios de septiembre de 2024, Microsoft aplicará políticas de flujo de autenticación en el Servicio de registro de dispositivos, pero solo para políticas que apunten a todos los recursos del selector de recursos. Si nuestra organización utiliza el Flujo de código de dispositivo para el registro de dispositivos y tenemos una política dirigida a todos los recursos, deberemos excluir el Servicio de registro de dispositivos para evitar interrupciones.

Para excluir el Servicio de registro de dispositivos en la configuración de acceso condicional, vaya a Recursos de destino -> Excluir -> Seleccionar aplicaciones en la nube excluidas -> Servicio de registro de dispositivos . Si está usando una API, actualice su política excluyendo el ID de cliente para el Servicio de registro de dispositivos: 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 .

Si no estás seguro de si se utiliza el flujo de código de dispositivo con el servicio de registro de dispositivos, podemos consultar los registros de inicio de sesión de Microsoft Entra. Filtraremos por el ID de cliente del servicio de registro de dispositivos en el filtro de ID de recurso y utilizaremos la opción Código de dispositivo dentro del filtro Protocolo de autenticación para identificar cualquier uso relevante.

Exclusiones de usuarios 

• Cuentas de acceso de emergencia o de emergencia para evitar el bloqueo de todo el inquilino.
• Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Se trata de cuentas no interactivas que no están asociadas a ningún usuario específico.

Al utilizar políticas de CA independientes, el acceso a las cuentas de servicio solo debe permitirse desde ubicaciones de red confiables donde los servicios se autentican de manera genuina. Esto garantiza que las cuentas de servicio solo puedan conectarse desde entornos seguros y verificados.

Las políticas de CA son la base de una arquitectura Zero Trust efectiva. ¿Cómo lo estás implementando en tu organización?

25 Políticas de Acceso Condicional

• Requerir MFA para administradores

  • Usuarios o identidades de carga de trabajo: Roles de directorio
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ninguno
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir MFA resistente a phishing para administradores

  • Usuarios o identidades de carga de trabajo: Roles de directorio
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ninguno
  • Controles de acceso: Otorgar acceso. Requerir fuerza de autenticación. MFA resistente a phishing
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Asegurar el registro de información de seguridad

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Todas las cuentas de acceso de emergencia para invitados y usuarios externos
  • Recursos de destino: Acciones del usuario: Registrar información de seguridad
  • Condiciones: Ubicaciones: Configurar Sí. Incluir: Cualquier ubicación. Excluir: Todas las ubicaciones confiables
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Bloquear el registro de información de seguridad de usuarios externos o invitados fuera de redes confiables

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Usuarios y grupos que requieren autenticación heredada. Al menos una cuenta para evitar el bloqueo
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ubicaciones: Configurar Sí. Incluir: Cualquier Ubicación. Excluir: Todas las ubicaciones confiables
  • Controles de acceso: Bloquear el acceso
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Bloquear la autenticación heredada

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Usuarios y grupos que requieren autenticación heredada.
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Aplicaciones cliente: Configurar Sí. Marcar: Clientes Exchange ActiveSync, Otros clientes
  • Controles de acceso: Bloquear el acceso
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir MFA para usuarios invitados y externos

  • Usuarios o identidades de carga de trabajo: Todos los usuarios invitados y externos
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia. Aplicaciones que no requieren MFA
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ninguno
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir MFA para todos los usuarios

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia. Aplicaciones que no requieren MFA
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ubicaciones: Configurar Sí. Incluir: Cualquier ubicación. Excluir: Todas las ubicaciones confiables (opcional)
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir MFA para la administración de Azure

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Seleccionar aplicaciones: API de administración de servicios de Windows Azure
  • Condiciones: Ninguno
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Autenticación multifactorial basada en riesgos de inicio de sesión

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Riesgo de inicio de sesión: Configurar Sí. Niveles: Alto y Medio
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor
  • Sesión: Frecuencia de inicio de sesión: cada vez
  • Habilitar política: Solo informe

• Cambio de contraseña en función del riesgo del usuario

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Riesgo del usuario: Configurar Sí. Nivel: Alto
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor. Requerir cambio de contraseña
  • Sesión: Frecuencia de inicio de sesión: cada vez
  • Habilitar política: Solo informe

• Bloquear el acceso a usuarios con riesgo interno

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia. Usuarios de conexión directa B2B. Usuarios de proveedores de servicios. Otros usuarios externos
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Riesgo del usuario: Riesgo interno: Configurar Sí. Nivel: Elevado
  • Controles de acceso: Bloquear el acceso
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requiere dispositivo compatible

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ninguno
  • Controles de acceso: Requerir que el dispositivo esté marcado como compatible
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requiere dispositivo compatible o híbrido unido a Microsoft Entra para administradores

  • Usuarios o identidades de carga de trabajo: Roles de directorio
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ninguno
  • Controles de acceso: Requerir que el dispositivo esté marcado como compatible. Requerir dispositivo híbrido unido a Microsoft Entra. Requerir uno de los controles seleccionados
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Bloquear el acceso a plataformas de dispositivos desconocidos o no compatibles

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia, Android, iOS, Windows y macOS
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Plataformas de dispositivos: Configurar Sí. Incluir: Cualquier dispositivo. Excluir: Android, iOS, Windows, macOS
  • Controles de acceso: Bloquear el acceso
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir aplicaciones de cliente aprobadas o una política de protección de aplicaciones

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia. Al menos una cuenta para evitar el bloqueo
  • Recursos de destino: Todas las aplicaciones en la nube.
  • Condiciones: Plataformas del dispositivo: Configurar Sí. Incluir: Android, iOS
  • Controles de acceso: Otorgar acceso. Requerir aplicación cliente aprobada. Requerir política de protección de la aplicación. Requerir uno de los controles seleccionados
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir una política de protección de aplicaciones en dispositivos Windows

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Office 365
  • Condiciones: Plataformas del dispositivo: Configurar Sí. Incluir: Windows. Aplicaciones de cliente: Configurar Sí. Seleccionar: Solo navegador
  • Controles de acceso: Otorgar acceso. Requerir política de protección de aplicaciones. Requerir que el dispositivo esté marcado como compatible. Requerir uno de los controles seleccionados
  • Sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir nueva autenticación y deshabilitar la persistencia del navegador en dispositivos no administrados

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Filtro para dispositivos: Configurar Sí. Sintaxis de la regla: device.trustType -ne “ServerAD” -or device.isCompliant -ne True
  • Controles de acceso: Frecuencia de inicio de sesión: Reautenticación periódica.
    Sesión de navegador persistente: Nunca persistente
  • Sesión: Frecuencia de inicio de sesión: 1 hora
  • Habilitar política: Solo informe

• Requiere un dispositivo compatible, dispositivo híbrido unido a Microsoft Entra para todos los usuarios

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia. Aplicaciones específicas (si es necesario)
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Ninguna (a menos que se excluyan aplicaciones específicas)
  • Controles de acceso: Otorgar acceso. Requerir autenticación multifactor. Requerir que el dispositivo esté marcado como compatible. Requerir dispositivo híbrido unido a Microsoft Entra. Requerir uno de los controles seleccionados
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Utilice restricciones impuestas por la aplicación (EXO, SPO, OFB) para dispositivos no administrados

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Seleccionar aplicaciones: Office 365
  • Condiciones: Ninguna
  • Controles de acceso: Utilice restricciones impuestas por la aplicación
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir autenticación multifactor para el registro del dispositivo

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Acciones del usuario: Registrar o unir dispositivos
  • Condiciones: Ninguna
  • Controles de acceso: Otorgar acceso. Requerir fortaleza de autenticación. Requerir autenticación multifactor
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Bloquear el acceso según la ubicación de la red

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Todas las aplicaciones en la nube
  • Condiciones: Red: Configurar Sí. Incluir: Redes y ubicaciones seleccionadas. Seleccionar: Ubicación bloqueada.
  • Controles de acceso: Bloquear el acceso.
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir un nivel de autenticación alto para usuarios externos

  • Usuarios o identidades de carga de trabajo: Usuarios invitados o externos
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Seleccionar aplicaciones: Aplicaciones seleccionadas o todas las aplicaciones (según sea necesario)
  • Condiciones: Red: Ninguna
  • Controles de acceso: Otorgar acceso. Requerir fortaleza de autenticación. Seleccionar: Fortaleza de autenticación personalizada o incorporada.
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Requerir que se acepten los términos de uso antes de acceder a los portales de administración de Microsoft

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Seleccionar aplicaciones: Portales de administración de Microsoft
  • Condiciones: Red: Ninguna
  • Controles de acceso: Otorgar acceso. Requerir la aceptación de los términos de uso
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Bloquear flujos de código de dispositivo para todos los usuarios

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Seleccionar aplicaciones: Todas las aplicaciones en la nube o aplicaciones seleccionadas
  • Condiciones: Red: Flujos de autenticación: Configurar Sí. Flujo de código del dispositivo
  • Controles de acceso: Bloquear el acceso
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Solo informe

• Bloquear flujos de transferencia de autenticación para todos los usuarios

  • Usuarios o identidades de carga de trabajo: Todos los usuarios
  • Usuarios o identidades de carga de trabajo excluidos: Cuentas de acceso de emergencia.
  • Recursos de destino: Seleccionar aplicaciones: Todas las aplicaciones en la nube o aplicaciones seleccionadas
  • Condiciones: Red: Flujos de autenticación: Configurar Sí. Transferencia de autenticación
  • Controles de acceso: Bloquear el acceso
  • Sesión: Frecuencia de inicio de sesión: Ninguno
  • Habilitar política: Activado

A tener muy en cuenta:

• Las exclusiones de cuentas de usuario/grupo/servicio requeridas deben agregarse a la plantilla según las necesidades de la organización.
• Las ubicaciones de red requeridas deben incluirse según sea necesario.
• Se deben configurar las exclusiones de aplicaciones obligatorias.
• Se pueden crear y personalizar fortalezas de autenticación según los requisitos de la organización.
• Se deben excluir un mínimo de al menos 2 cuentas de emergencia de la política de acceso condicional. Accede a la Guía de configuración
• Los documentos de Términos de Uso deben prepararse según los estándares de la organización y actualizarse en la política de Acceso Condicional.

La herramienta What if, disponible en la página de Acceso condicional, se puede utilizar para validar el impacto de la política antes de su aplicación total.

La seguridad digital define la solidez de nuestra organización, implementar políticas de CA es mucho más que una estrategia tecnológica, es una promesa de protección y confiabilidad. Hoy hemos recorrido las 25 mejores políticas, cada una diseñada no solo para bloquear amenazas, sino para empoderar a nuestros equipos con acceso seguro, sin fricciones.

Pero no es solo sobre tecnología, se trata de confianza: la confianza de nuestros usuarios, la confianza de nuestros partners y sobre todo, la confianza de cada uno de nuestros clientes.

Al fin y al cabo, nuestras acciones fortalecen los cimientos de una organización segura, resiliente y lista para el futuro.

Implementar estas políticas es un compromiso con la integridad de los datos, con la eficiencia operativa y, en última instancia, con la innovación continua. Nos estamos preparando para lo que viene, estamos construyendo el mañana hoy. Las CA se convertirán en un pilar de nuestra evolución.

Porque en cada acceso autorizado, en cada amenaza bloqueada, estamos marcando la diferencia. es que seguirán nuestro camino.

Nos vemos en la Redes!!