Compartir a través de

Acceso condicional: recursos de destino

Los recursos de destino (anteriormente aplicaciones en la nube, acciones y contexto de autenticación) son señales clave en una directiva de acceso condicional. Las directivas de acceso condicional permiten a los administradores asignar controles a aplicaciones, servicios, acciones o contexto de autenticación específicos.

  • Los administradores pueden elegir entre la lista de aplicaciones o servicios que incluyen aplicaciones integradas de Microsoft y cualquier aplicación integrada de Microsoft Entra, incluidas las aplicaciones de galería, no galería y aplicaciones publicadas a través del Proxy de aplicación.
  • Los administradores pueden definir una directiva basada en una acción de usuario , como Registrar información de seguridad o Registrar o unir dispositivos, lo que permite que el acceso condicional aplique controles en torno a esas acciones.
  • Los administradores pueden dirigir los perfiles de reenvío de tráfico desde acceso seguro global para mejorar la funcionalidad.
  • Los administradores pueden usar el contexto de autenticación para proporcionar una capa adicional de seguridad en las aplicaciones.

Captura de pantalla de una directiva de acceso condicional y el panel de recursos de destino.

Aplicaciones de nube de Microsoft

Los administradores pueden asignar una política de acceso condicional a las aplicaciones en la nube de Microsoft si la entidad de servicio aparece en su inquilino, excepto para Microsoft Graph. Microsoft Graph funciona como un recurso principal. Use Informes de audiencias para ver los servicios subyacentes y tener como destino esos servicios en las directivas. Algunas aplicaciones como Office 365 y la API de Administración de servicios de Windows Azure incluyen varias aplicaciones o servicios secundarios relacionados. Cuando se crean nuevas aplicaciones en la nube de Microsoft, aparecen en la lista del selector de aplicaciones en cuanto se crea la entidad de servicio en el inquilino.

Office 365

Microsoft 365 ofrece servicios de colaboración y productividad basados en la nube, como Exchange, SharePoint y Microsoft Teams. Los servicios en la nube de Microsoft 365 están profundamente integrados para garantizar experiencias de colaboración fluidas. Esta integración puede provocar confusión al crear directivas porque algunas aplicaciones, como Microsoft Teams, dependen de otras, como SharePoint o Exchange.

La agrupación de aplicaciones de Office 365 permite tener como destino estos servicios a la vez. Se recomienda usar la agrupación de Office 365, en lugar de dirigirse a aplicaciones en la nube individuales para evitar problemas con las dependencias del servicio.

Dirigirse a este grupo de aplicaciones ayuda a evitar problemas que pueden surgir debido a directivas y dependencias incoherentes. Por ejemplo: la aplicación Exchange Online está asociada a datos de Exchange Online tradicionales, como el correo electrónico, el calendario y la información de contacto. Los metadatos relacionados se pueden exponer mediante distintos recursos, como la búsqueda. Para asegurarse de que todos los metadatos están protegidos según lo previsto, los administradores deben asignar directivas a la aplicación de Office 365.

Los administradores pueden excluir todo el conjunto de aplicaciones en la nube de Office 365 o específicas de Office 365 de las directivas de acceso condicional.

Puede encontrar una lista completa de todos los servicios incluidos en el artículo Aplicaciones incluidas en el conjunto de aplicaciones de Office 365 de acceso condicional.

API de Administración de servicios de Windows Azure

Cuando se dirige a la aplicación API de Administración de servicios de Windows Azure, la directiva se aplica para los tokens emitidos a un conjunto de servicios estrechamente enlazados al portal. Esta agrupación incluye los identificadores de aplicación de:

  • Azure Resource Manager
  • Azure Portal, que también cubre el Centro de administración de Microsoft Entra y el Centro de participación de Microsoft
  • Azure Data Lake
  • API de Application Insights
  • API de Log Analytics

Dado que la directiva se aplica al Portal de administración de Azure y a la API, los servicios o clientes que dependen de la API de Azure pueden verse afectados indirectamente. Por ejemplo:

  • Azure CLI
  • Portal de Azure Data Factory
  • Azure Event Hubs
  • Azure PowerShell
  • Azure Service Bus (bus de servicios de Azure)
  • Azure SQL Database
  • Azure Synapse
  • API del modelo de implementación clásica
  • Centro de administración de Microsoft 365
  • Microsoft IoT Central
  • Administración multicliente de Microsoft Defender
  • SQL Managed Instance
  • Portal de administrador de suscripciones de Visual Studio

Precaución

Las directivas de acceso condicional asociadas a la API de Administración de servicios de Windows Azure ya no cubren Azure DevOps.

Note

La aplicación Windows Azure Service Management API se aplica a Azure PowerShell, que accede a la API de Azure Resource Manager. No se aplica a Microsoft Graph PowerShell, que llama a Microsoft Graph API.

Tip

Para Azure Government, debe tener como destino la aplicación de la API de administración de la nube de Azure Government.

Portales de administración de Microsoft

Cuando una directiva de acceso condicional tiene como objetivo la aplicación en la nube Microsoft Admin Portals, la directiva se aplica a los tokens emitidos para los id. de aplicación de los siguientes portales administrativos de Microsoft:

  • Azure portal
  • Centro de administración de Exchange
  • Centro de administración de Microsoft 365
  • Portal de Microsoft 365 Defender
  • Centro de administración de Microsoft Entra
  • centro de administración de Microsoft Intune
  • Portal de cumplimiento de Microsoft Purview
  • Centro de administración de Microsoft Teams

Continuamente añadimos más portales administrativos a la lista.

Otras aplicaciones

Los administradores pueden agregar cualquier aplicación registrada de Microsoft Entra a las directivas de acceso condicional. Estas aplicaciones pueden incluir:

Note

Dado que la directiva de acceso condicional establece los requisitos para acceder a un servicio, no puede aplicarla a una aplicación cliente (pública o nativa). En otras palabras, la directiva no se establece directamente en una aplicación cliente (pública o nativa), pero se aplica cuando un cliente llama a un servicio. Por ejemplo, una directiva establecida en el servicio SharePoint se aplica a todos los clientes que llamen a SharePoint. Así mismo, una directiva establecida en Exchange se aplica al intento de acceder al correo electrónico mediante el cliente de Outlook. Por eso las aplicaciones cliente (públicas o nativas) no están disponibles para la selección en el selector de aplicaciones y la opción Acceso condicional no están disponibles en la configuración de la aplicación para la aplicación cliente (pública o nativa) registrada en el inquilino.

Algunas aplicaciones no aparecen en el selector. La única manera de incluir estas aplicaciones en una directiva de acceso condicional es incluir todos los recursos (anteriormente "Todas las aplicaciones en la nube") o agregar la entidad de servicio que falta mediante el cmdlet New-MgServicePrincipal de PowerShell o mediante Microsoft Graph API.

Descripción del acceso condicional para distintos tipos de cliente

El acceso condicional se aplica a los recursos que no son clientes, excepto cuando el cliente es un cliente confidencial que solicita un token de identificador.

  • Cliente público
    • Los clientes públicos son aquellos que se ejecutan localmente en dispositivos como Microsoft Outlook en el escritorio o aplicaciones móviles como Microsoft Teams.
    • Las directivas de acceso condicional no se aplican a los propios clientes públicos, pero se basan en los recursos que solicitan.
  • Cliente confidencial
    • El acceso condicional se aplica a los recursos solicitados por el cliente y el propio cliente confidencial si solicita un token de identificador.
    • Por ejemplo: si Outlook Web solicita un token para ámbitos Mail.Read y Files.Read, el acceso condicional aplica directivas para Exchange y SharePoint. Además, si Outlook Web solicita un token de identificador, el acceso condicional también aplica las directivas de Outlook Web.

Para ver los registros de inicio de sesión de estos tipos de cliente desde el Centro de administración de Microsoft Entra:

  1. Inicie sesión en el Centro de administración de Microsoft Entra como al menos un Lector de informes.
  2. Vaya a Entra ID>Supervisión y estado>Registros de inicio de sesión.
  3. Agregue un filtro para el tipo de credencial de cliente .
  4. Ajuste el filtro para ver un conjunto específico de registros en función de la credencial de cliente usada en el inicio de sesión.

Para obtener más información, consulte el artículo Cliente público y aplicaciones cliente confidenciales.

Todos los recursos

La aplicación de una directiva de acceso condicional a todos los recursos (anteriormente "Todas las aplicaciones en la nube") sin exclusiones de aplicaciones exige la directiva para todas las solicitudes de token de sitios web y servicios, incluidos los perfiles de reenvío de tráfico de acceso seguro global. Esta opción incluye aplicaciones que no se pueden destinar individualmente en la directiva de acceso condicional, como Windows Azure Active Directory (00000002-0000-0000-c000-000000000000000).

Important

Microsoft recomienda crear una directiva de autenticación multifactor de línea base dirigida a todos los usuarios y todos los recursos (sin exclusiones de aplicaciones), como se explica en Requerir autenticación multifactor para todos los usuarios.

Comportamiento de acceso condicional cuando una directiva de todos los recursos tiene una exclusión de aplicaciones

Si alguna aplicación se excluye de la directiva, con el fin de no bloquear accidentalmente el acceso de los usuarios, determinados ámbitos de privilegios bajos se excluyen de la aplicación de directivas. Estos ámbitos permiten llamadas a las API de Graph subyacentes, como Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) y Microsoft Graph (00000003-0000-0000-c000-000000000000), para acceder a la información de pertenencia a grupos y perfiles de usuario que suelen usar las aplicaciones como parte de la autenticación. Por ejemplo: cuando Outlook solicita un token para Exchange, también solicita el ámbito de User.Read para poder mostrar la información básica de la cuenta del usuario actual.

La mayoría de las aplicaciones tienen una dependencia similar, por lo que estos ámbitos de privilegios bajos se excluyen automáticamente siempre que haya una exclusión de aplicaciones en una directiva Todos los recursos . Estas exclusiones de ámbito de privilegios bajos no permiten el acceso a datos más allá de la información básica del perfil de usuario y del grupo. Los ámbitos excluidos se enumeran de la siguiente manera, el consentimiento sigue siendo necesario para que las aplicaciones usen estos permisos.

  • Los clientes nativos y las aplicaciones de página única (SPA) tienen acceso a los siguientes ámbitos de privilegios bajos:
    • Azure AD Graph: email, offline_access, openid, , profile, User.Read
    • Microsoft Graph: email, offline_access, openid, profile, , , User.ReadPeople.Read
  • Los clientes confidenciales tienen acceso a los siguientes ámbitos de privilegios bajos, si se excluyen de una directiva Todos los recursos :
    • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.AllUser.ReadBasic.All
    • Microsoft Graph: email, , offline_access, openidprofile, User.ReadUser.Read.AllUser.ReadBasic.AllPeople.Read, People.Read.All, , GroupMember.Read.AllMember.Read.Hidden

Para obtener más información sobre los ámbitos mencionados, consulte Referencia de permisos de Microsoft Graph y Ámbitos y permisos en la plataforma de identidad de Microsoft.

Protección de la información del directorio

Si no se puede configurar la directiva MFA de línea base recomendada sin exclusiones de aplicaciones debido a motivos empresariales, y la directiva de seguridad de la organización debe incluir ámbitos de privilegios bajos relacionados con el directorio (User.Read, User.Read.AllUser.ReadBasic.AllPeople.ReadPeople.Read.AllGroupMember.Read.All, Member.Read.Hidden), cree una directiva de acceso condicional independiente destinada Windows Azure Active Directory a (00000002-0000-0000-c0000-000000000000). Windows Azure Active Directory (también denominado Azure AD Graph) es un recurso que representa los datos almacenados en el directorio, como usuarios, grupos y aplicaciones. El recurso de Windows Azure Active Directory se incluye en Todos los recursos , pero puede dirigirse individualmente a directivas de acceso condicional mediante los pasos siguientes:

  1. Inicie sesión en el Centro de administración de Microsoft Entra como administrador de definiciones de atributos y administrador de asignación de atributos.
  2. Vaya a Entra ID>Atributos de seguridad personalizados.
  3. Cree un nuevo conjunto de atributos y una definición de atributo. Para obtener más información, vea Agregar o desactivar definiciones de atributos de seguridad personalizados en Microsoft Entra ID.
  4. Vaya a Entra ID>Aplicaciones empresariales.
  5. Quite el filtro Tipo de aplicación y busque Id . de aplicación que comienza con 00000002-0000-0000-c000-00000000000000000.
  6. Seleccione Atributos deseguridad personalizados> de Windows Azure Active Directory>Agregar asignación.
  7. Seleccione el conjunto de atributos y el valor de atributo que planea usar en la directiva.
  8. Vaya a Entra ID>Acceso condicional>Directivas.
  9. Cree o modifique una directiva existente.
  10. En Recursos de destino>Recursos (anteriormente aplicaciones en la nube)>Incluir, seleccione >Seleccionar recursos>Editar filtro.
  11. Ajuste el filtro para incluir el conjunto de atributos y la definición anteriores.
  12. Guarde la directiva

Note

Configure esta directiva como se describe en la guía anterior. Las desviaciones en la creación de la directiva como se describe (por ejemplo, definir exclusiones de aplicaciones) pueden dar lugar a que se excluyan ámbitos de privilegios bajos y la directiva no se aplique según lo previsto.

Todos los recursos de Internet con Acceso global seguro

La opción Todos los recursos de Internet con acceso seguro global permite a los administradores dirigirse al perfil de reenvío de tráfico de acceso a Internet desde Microsoft Entra Internet Access.

Estos perfiles de Acceso seguro global permiten a los administradores definir y controlar cómo se enruta el tráfico a través de Microsoft Entra Internet Access y Microsoft Entra Private Access. Los perfiles de reenvío de tráfico se pueden asignar a dispositivos y redes remotas. Para obtener un ejemplo de cómo aplicar una directiva de acceso condicional a estos perfiles de tráfico, consulte el artículo Cómo aplicar directivas de acceso condicional al perfil de tráfico de Microsoft 365.

Para obtener más información sobre estos perfiles, consulte el artículo Global Secure Access traffic forwarding profiles (Perfiles de reenvío de tráfico de acceso seguro global).

Todos los recursos del agente (versión preliminar)

La aplicación de una directiva de acceso condicional a todos los recursos del agente hace cumplir la directiva para todas las solicitudes de token a los principales del plano de identidad del agente y a las identidades del agente.

Acciones del usuario

Las acciones del usuario son tareas que realiza un usuario. El acceso condicional admite dos acciones de usuario:

  • Registrar información de seguridad: esta acción de usuario permite a las directivas de acceso condicional aplicar reglas cuando los usuarios intentan registrar su información de seguridad. Para obtener más información, consulte Registro combinado de información de seguridad.

Note

Si los administradores aplican una directiva dirigida a las acciones de los usuarios para el registro de información de seguridad, y la cuenta de usuario es un invitado procedente de una cuenta personal de Microsoft (MSA), el control "Requerir autenticación multifactor" obliga al usuario de MSA a registrar información de seguridad en la organización. Si el usuario invitado procede de otro proveedor, como Google, se bloquea el acceso.

  • Registrar o unir dispositivos: esta acción de usuario permite a los administradores aplicar la directiva de acceso condicional cuando los usuarios registran o unen dispositivos a Microsoft Entra ID. Permite a los administradores configurar la autenticación multifactor para registrar o conectar dispositivos con más granularidad que una directiva a nivel de arrendatario. Existen tres consideraciones principales con esta acción de usuario:
    • Require multifactor authentication y Require auth strength son los únicos controles de acceso disponibles con esta acción de usuario y todos los demás están deshabilitados. Esta restricción evita conflictos con controles de acceso que dependen del registro de dispositivos de Microsoft Entra o que no se pueden aplicar al registro de dispositivos de Microsoft Entra.
      • Las claves de acceso enlazadas a dispositivos y Windows Hello para empresas no se admiten porque esos escenarios requieren que el dispositivo ya esté registrado.
    • Las condiciones Client apps, Filters for devices y Device state no están disponibles con esta acción de usuario, pues dependen del registro de dispositivos de Microsoft Entra para aplicar las directivas de acceso condicional.

Warning

Si una directiva de acceso condicional está configurada con la acción Registrar o unir dispositivos de usuario, establezca Entra ID Devices OverviewDevice Settings> (Configuración del dispositivo de Introducción a los>> - Require Multifactor Authentication to register or join devices with Microsoft Entra en No. De lo contrario, las directivas de acceso condicional con esta acción de usuario no se aplican correctamente. Obtenga más información sobre esta configuración de dispositivo en Configuración de la configuración del dispositivo.

Contexto de autenticación

El contexto de autenticación protege los datos y las acciones en las aplicaciones. Estas aplicaciones incluyen aplicaciones personalizadas, aplicaciones de línea de negocio (LOB), SharePoint o aplicaciones protegidas por Microsoft Defender for Cloud Apps. También se puede usar con Microsoft Entra Privileged Identity Management (PIM) para aplicar directivas de acceso condicional durante la activación del rol.

Por ejemplo, una organización podría almacenar archivos en sitios de SharePoint como un menú de almuerzo o una receta secreta de salsa barbacoa. Todos pueden acceder al sitio del menú del almuerzo, pero los usuarios que acceden al sitio secreto de recetas de salsa barbacoa pueden necesitar usar un dispositivo administrado y aceptar términos de uso específicos. Del mismo modo, un administrador que activa un rol con privilegios a través de PIM puede necesitar realizar la autenticación multifactor o usar un dispositivo compatible.

El contexto de autenticación funciona con usuarios o identidades de carga de trabajo, pero no en la misma directiva de acceso condicional.

Configuración de contextos de autenticación

Para administrar contextos de autenticación, vaya a Entra ID>Acceso condicional>Contexto de autenticación.

Captura de pantalla que muestra la administración de contextos de autenticación.

Seleccione Nuevo contexto de autenticación para crear una definición de contexto de autenticación. Las organizaciones pueden crear hasta 99 definiciones de contexto de autenticación (c1-c99). Configure estos atributos:

  • Nombre para mostrar es el nombre que se utiliza para identificar el contexto de autenticación en Microsoft Entra ID y a través de las aplicaciones que consumen contextos de autenticación. Se recomiendan nombres que se pueden usar entre recursos, como dispositivos de confianza, para reducir el número de contextos de autenticación necesarios. Tener un conjunto reducido limita el número de redireccionamientos y proporciona una mejor experiencia para el usuario final.
  • Descripción proporciona más información sobre las directivas. Esta información la usan los administradores y quienes aplican contextos de autenticación a los recursos.
  • La casilla Publicar en aplicaciones , cuando está activada, anuncia el contexto de autenticación en las aplicaciones y hace que esté disponible para asignarse. Si no está seleccionado, el contexto de autenticación no está disponible para los recursos de bajada.
  • ID es de solo lectura y se utiliza en tokens y aplicaciones para definir contextos de autenticación específicos de la solicitud. Se muestra aquí para casos de uso de solución de problemas y desarrollo.

Añadir a la directiva de acceso condicional

Los administradores pueden seleccionar contextos de autenticación publicados en directivas de acceso condicional; para ello, vaya a Asignaciones>Aplicaciones en la nube o acciones y seleccione Contexto de autenticación en el menú Seleccionar lo que se aplica a esta directiva .

Captura de pantalla que muestra cómo agregar un contexto de autenticación de acceso condicional a una directiva

Eliminación de un contexto de autenticación

Antes de eliminar un contexto de autenticación, asegúrese de que ninguna aplicación la use. De lo contrario, el acceso a los datos de la aplicación no está protegido. Para confirmarlo, compruebe los registros de inicio de sesión en los casos en los que se aplican las directivas de acceso condicional de contexto de autenticación.

Para eliminar un contexto de autenticación, asegúrese de que no tiene directivas de acceso condicional asignadas y no se publica en las aplicaciones. Esto evita la eliminación accidental de un contexto de autenticación que todavía está en uso.

Etiquetado de recursos con contextos de autenticación

Para más información sobre el uso de contextos de autenticación, consulte los artículos siguientes.

Contenido relacionado

  • Last updated on