Compartir a través de

Acceso condicional: recursos de destino

Los recursos de destino (anteriormente aplicaciones, acciones y el contexto de autenticación en la nube) son señales clave en una directiva de acceso condicional. Las directivas de acceso condicional permiten que los administradores asignen controles a determinadas aplicaciones, acciones o contextos de autenticación.

  • 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 la galería, la no galería y las aplicaciones publicadas a través del proxy de aplicación.
  • Los administradores pueden optar por definir directivas no basadas en una aplicación en la nube, sino 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 el 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 que muestra una directiva de acceso condicional y el panel de recursos de destino.

Aplicaciones de nube de Microsoft

Los administradores pueden asignar una directiva de acceso condicional a las aplicaciones en la nube de Microsoft siempre que la entidad de servicio aparezca en su tenant (inquilino), con la excepción de 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.

Oficina 365

Microsoft 365 proporciona 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 producir confusión a la hora de crear directivas, ya que algunas aplicaciones, como Microsoft Teams, dependen de otras, como SharePoint o Exchange.

El conjunto de Office 365 hace posible dirigirse a todos estos servicios a la vez. Se recomienda usar el nuevo conjunto de aplicaciones 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 Office 365.

Los administradores pueden excluir todo el conjunto de Office 365 o las aplicaciones en la nube de Office 365 específicas de la directiva 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 abarca el centro de administración de Microsoft Entra
  • 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 DevOps
  • 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
  • SQL Managed Instance
  • Portal de administrador de suscripciones de Visual Studio

Nota

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.

Para más información sobre cómo configurar una directiva de ejemplo para la API de administración de servicios de Windows Azure, consulte Acceso condicional: Requerir MFA para la administración de Azure.

Sugerencia

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:

  • Portal de Azure
  • 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.

Nota

La aplicación Microsoft Admin Portals solo se aplica a inicios de sesión interactivos en los portales de administración enumerados. Los inicios de sesión en los recursos o servicios subyacentes, como Microsoft Graph o las API de Azure Resource Manager, no están cubiertos por esta aplicación. Esos recursos están protegidos por la aplicación api de Administración de servicios de Windows Azure . Esta agrupación permite a los clientes desplazarse por el recorrido de adopción de MFA para los administradores sin afectar a la automatización que se basa en las API y PowerShell. Cuando esté listo, Microsoft recomienda usar una directiva que requiera que los administradores realicen MFA siempre para una protección completa.

Otras aplicaciones

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

Nota

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 al propio cliente público, pero se aplican en función de los recursos solicitados por los clientes públicos.
  • 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 da lugar a que se aplique 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).

Importante

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.Read, People.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, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.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 política MFA de configuración básica recomendada sin exclusiones de aplicaciones debido a motivos empresariales, y la política de seguridad de la organización debe incluir ámbitos de bajo nivel de privilegios relacionados con el directorio (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), la alternativa es crear una política de acceso condicional independiente dirigida a Windows Azure Active Directory (00000002-0000-0000-c000-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

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 en acceso seguro global permiten a los administradores definir y controlar cómo se enruta el tráfico a través de Acceso a Internet de Microsoft Entra y Acceso privado de Microsoft Entra. 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).

Acciones del usuario

Las acciones del usuario son tareas que realiza un usuario. Actualmente, el Acceso condicional admite dos acciones del usuario:

  • Registrar información de seguridad: esta acción de usuario permite que la directiva de acceso condicional se aplique cuando los usuarios que están habilitados para el registro combinado intentan registrar su información de seguridad. Puede encontrar más información en el artículo Registro de información de seguridad combinado.

Nota

Cuando los administradores aplican una directiva que se dirige a las acciones del usuario para registrar información de seguridad, si la cuenta de usuario es un invitado de una cuenta personal de Microsoft (MSA), al utilizar el control "Requerir autenticación multifactor", el usuario de MSA debe registrar información de seguridad con 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. Proporciona granularidad en la configuración de la autenticación multifactor para registrar o unir dispositivos en lugar de la directiva para todo el inquilino que existe actualmente. Existen tres consideraciones principales con esta acción de usuario:
    • Require multifactor authentication es el único control de acceso disponible con esta acción del 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 condiciones Client apps, Filters for devices y Device state no están disponibles con esta acción de usuario, ya que dependen del registro de dispositivos de Microsoft Entra para aplicar las directivas de acceso condicional.

Advertencia

Cuando se configura una directiva de acceso condicional con la acción de usuario Registrar o unir dispositivos, debe establecer Entra ID>Dispositivos>Visión general>Configuración de dispositivos - Require Multifactor Authentication to register or join devices with Microsoft Entra a No. De lo contrario, las directivas de acceso condicional con esta acción de usuario no se aplican correctamente. Puede encontrar más información sobre esta configuración de dispositivo en Configurar la configuración del dispositivo.

Contexto de autenticación

El contexto de autenticación se puede usar para proteger aún más los datos y acciones de las aplicaciones. Estas aplicaciones pueden ser sus propias aplicaciones personalizadas, aplicaciones de línea de negocio (LOB) personalizadas, aplicaciones como SharePoint o aplicaciones protegidas por Microsoft Defender para aplicaciones en la nube.

Por ejemplo, una organización puede conservar archivos en sitios de SharePoint como, por ejemplo, el menú de comidas o la receta secreta de su salsa barbacoa. Todos los usuarios pueden acceder al sitio del menú de comidas, pero es posible que para acceder al sitio de la receta secreta de la salsa barbacoa tengan que utilizar un dispositivo administrado y aceptar condiciones de uso específicas.

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

Los contextos de autenticación se administran bajo Entra ID>Acceso condicional>Contexto de autenticación.

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

Cree nuevas definiciones de contexto de autenticación seleccionando Nuevo contexto de autenticación. Las organizaciones se limitan a un total de 99 definiciones de contexto de autenticación c1-c99. Configure los siguientes 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 es utilizada por los administradores y por quienes aplican contextos de autenticación a los recursos.
  • Cuando está activada la casilla Publicar en aplicaciones, anuncia el contexto de autenticación a las aplicaciones y hace que estén disponibles para asignarlas. Si no está activada, el contexto de autenticación no está disponible para los recursos de nivel inferior.
  • 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 sus directivas de acceso condicional en Asignaciones>Aplicaciones en la nube o acciones y seleccionar 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

Al eliminar un contexto de autenticación, asegúrese de que no hay ninguna aplicación que siga usándolo. De lo contrario, el acceso a los datos de la aplicación ya no está protegido. Para confirmar este requisito previo, compruebe en los registros de información de inicio de sesión si hay casos en los que se aplican las directivas de acceso condicional del contexto de autenticación.

Para eliminar un contexto de autenticación, no debe tener asignadas directivas de acceso condicional y no debe publicarse en aplicaciones. Este requisito ayuda a evitar 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 del contexto de autenticación en las aplicaciones, consulte los artículos siguientes.

Pasos siguientes