Planeamiento de la implementación del acceso condicional

El planeamiento de la implementación del acceso condicional es fundamental para conseguir la estrategia de acceso para las aplicaciones y los recursos de su organización. Las directivas de acceso condicional ofrecen una gran flexibilidad de configuración. Sin embargo, esta flexibilidad también significa que debe planear la configuración cuidadosamente para evitar resultados no deseados.

El acceso condicional de Microsoft Entra combina señales, como el usuario, el dispositivo y la ubicación, para automatizar decisiones y aplicar directivas de acceso de la organización al recurso. Estas directivas de acceso condicional ayudan a equilibrar la seguridad y la productividad, aplicando controles de seguridad cuando sea necesario y manteniéndose fuera del camino del usuario cuando no lo sea.

El acceso condicional es la base del motor de directivas de seguridad de Confianza cero de Microsoft.

Diagrama que muestra información general sobre el acceso condicional de alto nivel.

Microsoft proporciona valores predeterminados de seguridad que garantizan un nivel básico de seguridad habilitado en los inquilinos que no tienen Microsoft Entra IS P1 o P2. Con el acceso condicional, puede crear directivas que proporcionen la misma protección que los valores predeterminados de seguridad, pero con granularidad. Los valores predeterminados de seguridad y acceso condicional no están diseñados para combinarse, ya que la creación de directivas de acceso condicional impiden habilitar los valores predeterminados de seguridad.

Requisitos previos

Comunicación del cambio

La comunicación es fundamental para el éxito de cualquier nueva funcionalidad. Debería comunicar de forma proactiva a los usuarios cómo y cuándo va a cambiar su experiencia, y cómo obtener soporte técnico si experimentan cualquier problema.

Componentes de la directiva de acceso condicional

Las directivas de acceso condicional responden a preguntas sobre quién debe tener acceso a los recursos, a qué recursos deben tener acceso y bajo qué condiciones. Las directivas se pueden diseñar para conceder acceso, limitar el acceso con controles de sesión o para bloquear el acceso. Para crear una directiva de acceso condicional, defina instrucciones if-then como las siguientes:

Si se cumple una asignación Aplicación de los controles de acceso
Si es un usuario del grupo financiero que accede a la aplicación Nómina Solicitar la autenticación multifactor y un dispositivo compatible
Si no es un miembro del grupo financiero que accede a la aplicación Nómina Bloquear acceso
Si el riesgo de usuario es alto Solicitar la autenticación multifactor y el cambio de contraseña segura

Exclusiones de usuarios

Las directivas de acceso condicional son herramientas eficaces, por lo que se recomienda excluir las siguientes cuentas de las directivas:

  • Cuentas de acceso de emergencia para evitarel bloqueo de cuentas en todo el inquilino. En el improbable caso de que todos los administradores estén bloqueados fuera del inquilino, se puede usar la cuenta administrativa de acceso de emergencia se para iniciar sesión en el inquilino y realizar los pasos para recuperar el acceso.
  • Cuentas de servicio y entidades de servicio, como la cuenta de sincronización de Microsoft Entra Connect. Las cuentas de servicio son cuentas no interactivas que no están asociadas a ningún usuario en particular. Los servicios back-end las usan normalmente para permitir el acceso mediante programación a las aplicaciones, pero también se utilizan para iniciar sesión en los sistemas con fines administrativos. Las cuentas de servicio como estas se deben excluir porque MFA no se puede completar mediante programación. Las llamadas realizadas por entidades de servicio no se bloquearán mediante directivas de acceso condicional con ámbito a los usuarios. Use el acceso condicional para las identidades de carga de trabajo para definir directivas destinadas a entidades de servicio.
    • Si su organización usa estas cuentas en scripts o código, piense en la posibilidad de reemplazarlas por identidades administradas. Como solución temporal, puede excluir estas cuentas específicas de la directiva de línea de base.

Hacer las preguntas adecuadas

Estas son algunas preguntas comunes sobre asignaciones y controles de acceso. Documente las respuestas a las preguntas de cada directiva antes de su creación.

Usuarios o identidades de la carga de trabajo

  • ¿Qué usuarios, grupos, roles de directorio o identidades de carga de trabajo se incluyen o excluyen de la directiva?
  • ¿Qué grupos o cuentas de acceso de emergencia deben excluirse de la directiva?

Aplicaciones o acciones en la nube

¿Se aplicará esta directiva a cualquier aplicación, acción de usuario o contexto de autenticación? En caso afirmativo:

  • ¿A qué aplicaciones o servicios se aplicará la directiva?
  • ¿Qué acciones del usuario están sujetas a esta directiva?
  • ¿A qué contextos de autenticación se aplicará esta directiva?
Filtro de aplicaciones

Uso del filtro para que las aplicaciones incluyan o excluyan aplicaciones en lugar de especificarlas individualmente ayuda a las organizaciones:

  • Escale y dirija fácilmente cualquier número de aplicaciones.
  • Administre fácilmente las aplicaciones con requisitos de directiva similares.
  • Reduzca el número de directivas individuales.
  • Reducir errores durante la edición de directivas: No es necesario agregar o quitar aplicaciones manualmente de la directiva. Solo tiene que administrar los atributos.
  • Superar las restricciones de tamaño de directiva.

Condiciones

  • ¿Qué plataformas de dispositivo se incluyen o se excluyen de la directiva?
  • ¿Cuáles son las ubicaciones de red conocidas de la organización?
    • ¿Qué ubicaciones se incluyen o excluyen de la directiva?
  • ¿Qué tipos de aplicaciones se incluyen o excluyen de la directiva?
  • ¿Necesita centrarse en atributos específicos de dispositivo?
  • Si usa Identity Protection, ¿desea incorporar riesgos de inicio de sesión o de usuario?
Riesgo de usuario e inicio de sesión

Para las organizaciones con licencias de Microsoft Entra ID P2, pueden incluir el riesgo de usuario y de inicio de sesión en las directivas de acceso condicional. Estas incorporaciones pueden reducir la discrepancia entre las medidas de seguridad al exigir la autenticación multifactor o el cambio de contraseña segura solo cuando se considere que un usuario o inicio de sesión plantea riesgos.

Para obtener más información sobre el riesgo y su uso en la directiva, consulte el artículo ¿Qué es el riesgo?

Bloqueo o concesión de controles

¿Desea conceder acceso a los recursos requiriendo una o varias de las siguientes condiciones?

  • Autenticación multifactor
  • Dispositivo marcado como conforme
  • Uso de un dispositivo unido híbrido de Microsoft Entra dispositivo
  • Uso de una aplicación cliente aprobada
  • Directiva de protección de aplicaciones implementada
  • Cambio de contraseña
  • Términos de uso aceptados

Bloqueo del acceso es un poderoso control que debe aplicar con los conocimientos adecuados. Las directivas con instrucciones de bloque pueden tener efectos secundarios imprevistos. Las pruebas y la validación adecuadas son vitales antes de habilitar el control a escala. Los administradores deben usar herramientas del acceso condicional como el modo de solo informe y la herramienta What If al realizar cambios.

Controles de sesión

¿Desea aplicar cualquiera de los siguientes controles de acceso en las aplicaciones en la nube?

  • Usar restricciones que exige la aplicación
  • Uso del control de aplicaciones de acceso condicional
  • Aplicar la frecuencia de inicio de sesión
  • Utilizar sesiones del explorador persistentes
  • Personalización de la evaluación continua de acceso

Combinación de directivas

Al crear y asignar directivas, debe tener en cuenta el funcionamiento de los tokens de acceso. Los tokens de acceso conceden o deniegan el acceso en función de si se ha autorizado y autenticado el usuario que hace una solicitud. Si el solicitante puede demostrar que es quien dice ser, puede acceder a los recursos o funcionalidades protegidos.

Los tokens de acceso se emiten de forma predeterminada si una condición de la directiva de acceso condicional no desencadena un control de acceso.

Esta directiva no evita que la aplicación pueda bloquear el acceso.

Por ejemplo, tengamos en cuenta el siguiente ejemplo de directiva simplificada:

Usuarios: GRUPO FINANCIERO
Acceso a: APLICACIÓN NÓMINA
Control de acceso: Autenticación multifactor

  • El usuario A pertenece al GRUPO FINANCIERO, que debe usar la autenticación multifactor para acceder a la APLICACIÓN NÓMINA.
  • El usuario B no está en el GRUPO FINANCIERO, entonces se emite un token de acceso y se le permite acceder a la APLICACIÓN NÓMINA sin efectuar la autenticación multifactor.

Para asegurarse de que los usuarios que no pertenezcan al grupo financiero no tengan acceso a la aplicación Nómina, se podría crear una directiva independiente y bloquear a estos usuarios. Por ejemplo:

Usuarios: Incluir todos los usuarios/Excluir GRUPO FINANCIERO
Acceso a: APLICACIÓN NÓMINA
Control de acceso: Bloquear el acceso

Ahora, cuando el usuario B intente acceder a la APLICACIÓN NÓMINA, el acceso estará bloqueado.

Recomendaciones

Teniendo en cuenta lo que hemos aprendido sobre el uso del acceso condicional y al dar soporte a otros clientes, a continuación ofrecemos algunas recomendaciones.

Aplicación de directivas de acceso condicional a cada aplicación

Asegúrese de que todas las aplicaciones tengan aplicada al menos una directiva de acceso condicional. Desde una perspectiva de seguridad, es mejor crear una directiva que abarque todas las aplicaciones en la nube y, a continuación, excluir las aplicaciones en las que no desea que se aplique la directiva. Este procedimiento garantiza que no sea necesario actualizar las directivas de acceso condicional cada vez que se integre una nueva aplicación.

Sugerencia

Tenga mucho cuidado al usar el bloque y todas las aplicaciones en una sola directiva. Esto podría bloquear a los administradores, y no se pueden configurar exclusiones para puntos de conexión importantes como Microsoft Graph.

Minimización del número de directivas de acceso condicional

Crear una directiva para cada aplicación no es eficaz y conlleva una administración difícil. El acceso condicional tiene un límite de 195 directivas por inquilino. Este límite de directivas de 195 incluye cualquier estado de directivas de acceso condicional, incluyendo los modos de solo informe, activado o desactivado.

Se recomienda analizar las aplicaciones y agruparlas en aplicaciones que tengan los mismos requisitos de recursos para los mismos usuarios. Por ejemplo, si todas las aplicaciones de Microsoft 365 o todas las aplicaciones de recursos humanos tienen los mismos requisitos para los mismos usuarios, cree una sola directiva e incluya todas las aplicaciones a las que se aplique.

Las directivas de acceso condicional están contenidas en un archivo JSON, el cual está enlazado a un límite de tamaño del cual no se espera que una sola directiva crezca. Si usa una lista larga de GUID en la directiva, puede alcanzar este límite. Si encuentra estos límites, se recomiendan alternativas como:

Configuración del modo de solo informe

De forma predeterminada, cada directiva creada a partir de la plantilla se creará en modo de solo informe. Se recomienda a las organizaciones probar y supervisar el uso, para garantizar el resultado previsto, antes de activar cada directiva.

Habilite las directivas en modo de solo informe. Una vez que guarde una directiva en modo de solo informe, podrá observar el efecto que tiene en los inicios de sesión en tiempo real en los registros de inicio de sesión. En los registros de inicio de sesión, seleccione un evento y vaya a la pestaña Solo informe para ver el resultado de cada directiva de solo informe.

Puede ver el efecto agregado de las directivas de acceso condicional en el libro de información detallada e informes. Para acceder al libro, necesita una suscripción de Azure Monitor y tiene que transmitir en secuencias los registros de inicio de sesión a un área de trabajo de Log Analytics.

Planear la interrupción

Para reducir el riesgo de bloqueo durante interrupciones imprevistas, planee estrategias de resistencia para su organización.

Establecer pautas de nomenclatura para sus directivas

La pauta de nomenclatura ayuda a encontrar las directivas y a comprender su propósito sin tener que abrirlas en el portal de administración de Azure. Se recomienda asignar un nombre a la directiva para mostrar:

  • Un número de secuencia
  • Las aplicaciones en la nube a las que se aplica
  • La respuesta
  • A quién se aplica
  • Cuándo se aplica

Diagrama que muestra estándares de nomenclatura de ejemplo para las directivas.

Ejemplo: Una directiva para requerir MFA para los usuarios de marketing con acceso a la aplicación Dynamics CRP desde redes externas podría ser:

Diagrama que muestra un estándar de nomenclatura de ejemplo.

Un nombre descriptivo le ayuda a mantener una visión general de la implementación del acceso condicional. El número de secuencia es útil si necesita hacer referencia a una directiva en una conversación. Por ejemplo, si habla con un administrador por teléfono, puede pedirle que abra la directiva CA01 para resolver una incidencia.

Estándares de nomenclatura para controles de acceso de emergencia

Además de las directivas activas, implemente directivas deshabilitadas que actúen como controles de acceso resistentes para escenarios de interrupción/emergencia secundarios. La pauta de nomenclatura para las directivas de contingencia debe incluir lo siguiente:

  • HABILITAR EN CASO DE EMERGENCIA al principio para resaltar el nombre entre las otras directivas.
  • El nombre de la interrupción a la que se debe aplicar.
  • Un número de secuencia de ordenación para ayudar al administrador a saber en qué orden se deben habilitar las directivas.

Ejemplo: El siguiente nombre indica que esta es la primera de cuatro directivas que se deben habilitar si se produce una interrupción de MFA:

  • EM01 - HABILITAR EN CASO DE EMERGENCIA: Interrupción de MFA [1/4]: Exchange SharePoint: Requerir la unión híbrida de Microsoft Entra para usuarios VIP.

Bloqueo de países o regiones de los que nunca se espera un inicio de sesión

Microsoft Entra ID permite crear ubicaciones con nombre. Crea la lista de países o regiones permitidas y, a continuación, crea una directiva de bloque de red con estos "países o regiones permitidas" como exclusión. Esta opción crea una menor sobrecarga para aquellos clientes que se encuentren en ubicaciones geográficas más pequeñas. Asegúrese de excluir las cuentas de acceso de emergencia de esta directiva.

Implementación de directivas de acceso condicional

Cuando tenga todo preparado, implemente las directivas de acceso condicional por fases.

Creación de directivas de acceso condicional

Consulte los artículos Plantillas de directiva de acceso condicional y Directivas de seguridad comunes para organizaciones de Microsoft 365 para empezar con buen pie. Estas plantillas ofrecen una manera práctica de implementar las recomendaciones de Microsoft. Asegúrese de excluir las cuentas de acceso de emergencia.

Evaluación del impacto de la directiva

Se recomienda emplear las siguientes herramientas para evaluar el efecto de las directivas antes y después de hacer cambios. Una ejecución simulada da idea del efecto que tiene una directiva de acceso condicional, pero no reemplaza una ejecución de prueba real en un entorno de desarrollo correctamente configurado.

Prueba de las directivas

Asegúrese de que se prueban los criterios de exclusión de las directivas. Por ejemplo, puede excluir a un usuario o grupo de una directiva que requiera MFA. Pruebe si a los usuarios excluidos se les solicita MFA, ya que la combinación de otras directivas puede hacer que se exija para esos usuarios.

Realice cada prueba del plan de pruebas con los usuarios de prueba. El plan de pruebas es importante para tener una comparación entre los resultados previstos y los reales. En la siguiente tabla se muestran algunos casos de prueba de ejemplo. Ajuste los escenarios y los resultados previstos en función de la configuración de sus directivas de acceso condicional.

Directiva Escenario Resultado previsto
Inicios de sesión no seguros El usuario inicia sesión en la aplicación usando un explorador no aprobado Calcula una puntuación de riesgo en función de la probabilidad de que el usuario no realice el inicio de sesión. Requiere que el usuario se corrija automáticamente mediante MFA.
Administración de dispositivos El usuario autorizado intenta iniciar sesión desde un dispositivo autorizado El acceso se le concede
Administración de dispositivos El usuario autorizado intenta iniciar sesión desde un dispositivo no autorizado El acceso se le bloquea
Cambio de contraseña en caso de riesgo del usuario El usuario autorizado intenta iniciar sesión con credenciales en peligro (inicio de sesión de alto riesgo) Al usuario se le solicita que cambie la contraseña o se le bloquea el acceso (de conformidad con la directiva)

Implementación en producción

Después de comprobar el efecto del modo de solo informe, un administrador puede cambiar la opción Enable policy de Report-only a On.

Revertir las directivas

En caso de que necesite revertir las directivas recién implementadas, use una o varias de las siguientes opciones:

  • Deshabilite la directiva. Deshabilitar una directiva garantiza que la directiva no se aplique cuando un usuario intente iniciar sesión. Si quiere que se use, siempre puede volver atrás y habilitar la directiva.

  • Excluya un usuario o grupo de una directiva. Si un usuario no puede acceder a la aplicación, puede elegir excluirlo de la directiva.

    Precaución

    Las exclusiones se deben usar con moderación y solo en casos en los que el usuario es de confianza. Los usuarios se deben agregar de nuevo a la directiva o al grupo en cuanto sea posible.

  • Si desactiva una directiva porque ya no es necesaria, elimínela.

Solución de problemas de la directiva de acceso condicional

Si un usuario tiene algún problema con una directiva de acceso condicional, recopile la siguiente información para facilitar la resolución.

  • Nombre principal del usuario
  • Nombre para mostrar del usuario
  • Nombre del sistema operativo
  • Marca de tiempo (aproximado es correcto)
  • Aplicación de destino
  • Tipo de aplicación cliente (explorador frente a cliente)
  • Id. de correlación (este identificador es único para el inicio de sesión)

Si el usuario ha recibido un mensaje con un vínculo Más detalles, podrá recopilar la mayor parte de esta información para usted.

Capturas de pantalla de un mensaje de error de ejemplo y más detalles.

Una vez que haya recopilado la información, consulte los siguientes recursos:

  • Problemas de inicio de sesión con acceso condicional: comprenda los resultados inesperados de inicio de sesión relacionados con el acceso condicional mediante mensajes de error y el registro de inicio de sesión de Microsoft Entra.
  • Uso de la herramienta What-If: comprenda por qué una directiva se ha aplicado o no a un usuario en una circunstancia específica, o bien si una directiva se aplicaría en un estado conocido.