Accès conditionnel : ressources cibles

Les ressources cibles (anciennement les applications cloud, les actions et le contexte d’authentification) sont des signaux clés dans une stratégie d’accès conditionnel. Les stratégies d’accès conditionnel permettent aux administrateurs d’affecter des contrôles à des applications, services, actions ou contexte d’authentification spécifiques.

• Les administrateurs peuvent choisir parmi la liste des applications ou services qui incluent des applications Microsoft intégrées et toutes les applications intégrées Microsoft Entra, notamment la galerie, la non-galerie et les applications publiées via le proxy d’application.
• Les administrateurs peuvent définir une stratégie basée sur une action utilisateur telle que Inscrire des informations de sécurité ou inscrire ou joindre des appareils, ce qui permet à l’accès conditionnel d’appliquer des contrôles autour de ces actions.
• Les administrateurs peuvent cibler les profils de transfert de trafic à partir d’Accès sécurisé global pour bénéficier d’une fonctionnalité améliorée.
• Les administrateurs peuvent utiliser le contexte d’authentification pour fournir une couche supplémentaire de sécurité dans les applications.

Applications cloud Microsoft

Les administrateurs peuvent attribuer une stratégie d'accès conditionnel aux applications cloud Microsoft si le principal de service apparaît dans leur locataire, à l'exception de Microsoft Graph. Microsoft Graph fonctionne comme une ressource parapluie. Utilisez audience Reporting pour afficher les services sous-jacents et cibler ces services dans vos stratégies. Certaines applications telles qu’Office 365 et l’API Gestion des services Windows Azure incluent plusieurs applications ou services enfants associés. Lorsque de nouvelles applications cloud Microsoft sont créées, elles apparaissent dans la liste de sélection d’applications dès que le principal de service est créé dans le locataire.

Office 365

Microsoft 365 offre des services de productivité et de collaboration basés sur le cloud tels qu’Exchange, SharePoint et Microsoft Teams. Les services cloud Microsoft 365 sont profondément intégrés pour garantir des expériences fluides et collaboratives. Cette intégration peut entraîner une confusion lors de la création de stratégies, car certaines applications, telles que Microsoft Teams, dépendent d’autres, telles que SharePoint ou Exchange.

Le regroupement d’applications Office 365 permet de cibler ces services en même temps. Nous vous recommandons d’utiliser le regroupement Office 365, au lieu de cibler des applications cloud individuelles pour éviter les problèmes liés aux dépendances de service.

Le ciblage de ce groupe d’applications permet d’éviter les problèmes pouvant survenir en raison de stratégies et de dépendances incohérentes. Par exemple : l’application Exchange Online est liée à des données Exchange Online traditionnelles, telles que le courrier, le calendrier et les informations de contact. Les métadonnées associées peuvent être exposées par le biais de différentes ressources, telles que la recherche. Pour vous assurer que toutes les métadonnées sont protégées comme prévu, les administrateurs doivent affecter des stratégies à l’application Office 365.

Les administrateurs peuvent exclure l’ensemble de la suite Office 365 ou des applications cloud Office 365 spécifiques des stratégies d’accès conditionnel.

Vous trouverez la liste complète de tous les services inclus dans l’article Applications incluses dans la suite d’applications Office 365 d’accès conditionnel.

API Gestion des services Windows Azure

Lorsque vous ciblez l’application API Gestion des services Windows Azure, la stratégie est appliquée pour les jetons émis à un ensemble de services étroitement liés au portail. Ce regroupement comprend les ID d’application des éléments suivants :

• Azure Resource Manager
• Portail Azure, qui couvre également le Centre d’administration Microsoft Entra et le Centre d’engagement Microsoft
• Azure Data Lake
• API Application Insights
• API Log Analytics

Étant donné que la stratégie est appliquée au portail de gestion Azure et à l’API, tous les services ou clients qui dépendent de l’API Azure peuvent être indirectement affectés. Par exemple:

• Azure CLI
• Portail Azure Data Factory
• Hubs d'événements Azure
• Azure PowerShell
• Azure Service Bus (Bus de service Azure)
• Azure SQL Database
• Azure Synapse
• API du modèle de déploiement Classic
• Centre d’administration Microsoft 365
• Microsoft IoT Central
• La gestion multitenant de Microsoft Defender
• Instance managée SQL
• Portail de l’administrateur d’abonnements Visual Studio

Portails d’administration Microsoft

Lorsqu’une stratégie d’accès conditionnel cible l’application cloud Microsoft Admin Portals, la stratégie est appliquée à des jetons émis pour des ID d’application des portails d’administration Microsoft suivants :

• Azure portal
• Centre d’administration Exchange
• Centre d’administration Microsoft 365
• Portail Microsoft 365 Defender
• Centre d’administration Microsoft Entra
• Centre d’administration Microsoft Intune
• Portail de conformité Microsoft Purview
• Centre d’administration Microsoft Teams

Nous ajoutons continuellement d’autres portails d’administration à la liste.

Autres applications

Les administrateurs peuvent ajouter n’importe quelle application inscrite à Microsoft Entra aux stratégies d’accès conditionnel. Parmi ces applications, citons par exemple :

• Applications publiées via le proxy d’application Microsoft Entra
• Applications ajoutées à partir de la galerie
• Applications personnalisées non dans la galerie
• Applications héritées publiées par le biais de réseaux et de contrôleurs de distribution d’applications
• Applications qui utilisent l’authentification unique basée sur un mot de passe

Certaines applications n’apparaissent pas du tout dans le sélecteur. La seule façon d’inclure ces applications dans une stratégie d’accès conditionnel consiste à inclure toutes les ressources (anciennement « Toutes les applications cloud ») ou à ajouter le principal de service manquant à l’aide de l’applet de commande PowerShell New-MgServicePrincipal ou à l’aide de l’API Microsoft Graph.

Présentation de l’accès conditionnel pour différents types de clients

L’accès conditionnel s’applique aux ressources et non aux clients, sauf lorsque le client est un client confidentiel demandant un jeton d’ID.

• Client public
  • Les clients publics sont ceux qui s’exécutent localement sur des appareils tels que Microsoft Outlook sur le bureau ou les applications mobiles comme Microsoft Teams.
  • Les stratégies d’accès conditionnel ne s’appliquent pas aux clients publics eux-mêmes, mais sont basées sur les ressources qu’ils demandent.
• Client confidentiel
  • L’accès conditionnel s’applique aux ressources demandées par le client et au client confidentiel lui-même s’il demande un jeton d’ID.
  • Par exemple : si Outlook Web demande un jeton pour les étendues Mail.Read et Files.Read, l’accès conditionnel applique des stratégies pour Exchange et SharePoint. En outre, si Outlook Web demande un jeton d’ID, l’accès conditionnel applique également les stratégies pour Outlook Web.

Pour afficher les journaux de connexion pour ces types de clients à partir du Centre d’administration Microsoft Entra :

1. Connectez-vous au Centre d’administration Microsoft Entra en tant que lecteur de rapports au moins.
2. Accédez à Entra ID>Surveillance et santé>Journaux de connexion.
3. Ajoutez un filtre pour le type d'identification client .
4. Ajustez le filtre pour afficher un ensemble spécifique de journaux en fonction des informations d’identification du client utilisées lors de la connexion.

Pour plus d’informations, consultez l’article Client public et applications clientes confidentielles.

Toutes les ressources

L’application d’une stratégie d’accès conditionnel à toutes les ressources (anciennement « Toutes les applications cloud ») sans exclusion d’application applique la stratégie pour toutes les demandes de jetons provenant de sites web et de services, y compris les profils de transfert de trafic d’accès sécurisé global. Cette option inclut les applications qui ne sont pas ciblées individuellement dans la politique d'accès conditionnel, telles que Windows Azure Active Directory (00000002-0000-0000-c000-000000000000).

Comportement de l’accès conditionnel lorsqu’une stratégie s’appliquant à toutes les ressources inclut une exclusion d’application

Si une application est exclue de la stratégie, afin de ne pas bloquer par inadvertance l’accès utilisateur, certaines étendues de privilège faible sont exclues de l’application de la stratégie. Ces étendues permettent d’appeler les API Graph sous-jacentes, comme Windows Azure Active Directory (00000002-0000-0000-c000-0000000000000) et Microsoft Graph (00000003-0000-0000-c000-00000000000000000000) pour accéder aux informations d’appartenance aux utilisateurs et aux groupes couramment utilisées par les applications dans le cadre de l’authentification. Par exemple : quand Outlook demande un jeton pour Exchange, il demande également l’étendue de User.Read pour pouvoir afficher les informations de base du compte de l’utilisateur(-trice) actuel(le).

La plupart des applications ont une dépendance similaire, c’est pourquoi ces étendues de privilèges faibles sont automatiquement exclues chaque fois qu’il existe une exclusion d’application dans une stratégie Toutes les ressources . Ces exclusions d’étendue de privilèges faibles n’autorisent pas l’accès aux données au-delà des informations de base sur le profil utilisateur et le groupe. Les étendues exclues sont répertoriées comme suit, le consentement est toujours requis pour que les applications utilisent ces autorisations.

• Les clients natifs et les applications à page unique (SPAs) ont accès aux étendues de privilège faible suivantes :
  • Graphique Azure AD : email, offline_access, openid, profile, User.Read
  • Microsoft Graph : email, offline_access, openid, profile, User.Read, People.Read
• Les clients confidentiels ont accès aux périmètres de privilège faible suivants, s’ils sont exclus d’une stratégie Toutes les ressources :
  • Graphique Azure AD : email, offline_access, openid, profile, User.Read, User.Read.All, User.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

Pour plus d’informations sur les étendues mentionnées, consultez les informations de référence sur les autorisations Microsoft Graph , ainsi que sur les étendues et les autorisations dans la plateforme d’identités Microsoft.

Protection des informations d’annuaire

Si la stratégie MFA de base de référence recommandée sans exclusions d’application ne peut pas être configurée pour des raisons métier, et que la stratégie de sécurité de votre organisation doit inclure des étendues de privilèges faibles liés à l’annuaire (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), créer une stratégie d'accès conditionnel distincte ciblant Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). Windows Azure Active Directory (également appelé Azure AD Graph) est une ressource représentant les données stockées dans l’annuaire, telles que les utilisateurs, les groupes et les applications. La ressource Windows Azure Active Directory est incluse dans toutes les ressources , mais peut être ciblée individuellement dans les stratégies d’accès conditionnel en procédant comme suit :

1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’administrateur de définition d’attribut et administrateur d’attribution d’attributs.
2. Accédez à Entra ID>Attributs de sécurité personnalisés.
3. Créez un jeu d’attributs et une définition d’attribut. Pour plus d’informations, consultez Ajouter ou désactiver des définitions d’attributs de sécurité personnalisées dans l’ID Microsoft Entra.
4. Accédez à Entra ID>Enterprise apps.
5. Supprimez le filtre de type d’application et recherchez l’ID d’application qui commence par 00000002-0000-0000-c000-000000000000000000.
6. Sélectionnez les attributs >Windows Azure Active Directory>Ajouter une affectation.
7. Sélectionnez l’ensemble d’attributs et la valeur d’attribut que vous envisagez d’utiliser dans la stratégie.
8. Accédez à Entra ID>Accès conditionnel>Stratégies.
9. Créer ou modifier une stratégie existante.
10. Sous Ressources cibles>Ressources (anciennement applications cloud)>Inclure, sélectionnez >Sélectionner les ressources>Modifier le filtre.
11. Ajustez le filtre pour inclure votre ensemble d'attributs et la définition que vous avez définie précédemment.
12. SousContrôles>d’accèsAccorder, sélectionnez Accorder l’accès, Exiger la force d’authentification, sélectionnez Authentification multifacteur, puis sélectionnez Sélectionner.
13. Confirmez vos paramètres et définissez Activer la politique sur Mode rapport uniquement.
14. Sélectionnez Créer pour créer et activer votre politique.

Toutes les ressources Internet avec Global Secure Access

Toutes les ressources Internet avec l’option Accès sécurisé global permettent aux administrateurs de cibler le profil de transfert du trafic internet à partir de Microsoft Entra Internet Access.

Ces profils dans Global Secure Access permettent aux administrateurs de définir et de contrôler la façon dont le trafic est acheminé via Microsoft Entra Internet Access et Microsoft Entra Private Access. Les profils de transfert de trafic peuvent être attribués à des appareils et à des réseaux distants. Pour obtenir un exemple d’application d’une stratégie d’accès conditionnel à ces profils de trafic, consultez l’article Comment appliquer des stratégies d’accès conditionnel au profil de trafic Microsoft 365.

Pour plus d’informations sur ces profils, consultez l’article Profils de transfert de trafic Global Secure Access.

Toutes les ressources de l’agent (aperçu)

L’application d’une stratégie d’accès conditionnel à toutes les ressources de l’agent impose cette stratégie pour toutes les demandes de jetons aux principaux d’agent définis par le modèle d’identité et aux identités d’agent.

Actions utilisateur

Les actions utilisateur sont les tâches qu’un utilisateur effectue. L’accès conditionnel prend en charge deux actions utilisateur :

• Inscrire des informations de sécurité : cette action utilisateur permet aux stratégies d’accès conditionnel d’appliquer des règles lorsque les utilisateurs essaient d’inscrire leurs informations de sécurité. Pour plus d’informations, consultez l’inscription combinée des informations de sécurité.

• Inscrire ou joindre des appareils : cette action utilisateur permet aux administrateurs d’appliquer la stratégie d’accès conditionnel lorsque les utilisateurs inscrivent ou joignent des appareils à Microsoft Entra ID. Il permet aux administrateurs de configurer l’authentification multifacteur pour l’inscription ou la jonction d’appareils avec plus de granularité qu’une stratégie à l’échelle du locataire. Il existe trois points clés à prendre en compte pour cette action utilisateur :
  • Require multifactor authentication et Require auth strength sont les seuls contrôles d’accès disponibles avec cette action utilisateur et tous les autres sont désactivés. Cette restriction empêche les conflits avec les contrôles d’accès qui dépendent de l’inscription d’appareils dans Microsoft Entra ou qui ne s’y appliquent pas.
    • Les clés secrètes liées à l’appareil et Windows Hello Entreprise ne sont pas prises en charge, car ces scénarios nécessitent que l’appareil soit déjà inscrit.
  • Client apps, Filters for devices, et les Device state conditions ne sont pas disponibles avec cette action utilisateur, car elles dépendent de l’enregistrement de l’appareil Microsoft Entra pour appliquer les politiques d’accès conditionnel.

Contexte d’authentification

Le contexte d’authentification sécurise les données et les actions dans les applications. Ces applications incluent des applications personnalisées, des applications métier ,SharePoint ou des applications protégées par Microsoft Defender pour Cloud Apps. Il peut également être utilisé avec Microsoft Entra Privileged Identity Management (PIM) pour appliquer des stratégies d’accès conditionnel lors de l’activation du rôle.

Par exemple, une organisation peut stocker des fichiers dans des sites SharePoint comme un menu déjeuner ou une recette secrète de sauce BARBECUE. Tout le monde peut accéder au site de menu déjeuner, mais les utilisateurs qui accèdent au site secret de recette de sauce BARBECUE peuvent avoir besoin d’utiliser un appareil géré et d’accepter des conditions d’utilisation spécifiques. De même, un administrateur activant un rôle privilégié via PIM peut être nécessaire pour effectuer l’authentification multifacteur ou utiliser un appareil conforme.

Le contexte d’authentification fonctionne avec les utilisateurs ou les identités de charge de travail, mais pas dans la même stratégie d’accès conditionnel.

Configurer des contextes d’authentification

Gérez les contextes d’authentification en accédant à Entra ID>Accès conditionnel>Contexte d'authentification.

Sélectionnez Nouveau contexte d’authentification pour créer une définition de contexte d’authentification. Les organisations peuvent créer jusqu’à 99 définitions de contexte d’authentification (c1-c99). Configurez ces attributs :

• Nom d'affichage est le nom utilisé pour identifier le contexte d’authentification dans Microsoft Entra ID et dans les applications qui consomment des contextes d’authentification. Nous vous recommandons d’utiliser des noms sur plusieurs ressources, comme les appareils approuvés, pour réduire le nombre de contextes d’authentification nécessaires. Le fait de disposer d’un ensemble de contextes réduit limite le nombre de redirections et offre une meilleure expérience utilisateur final.
• La description fournit plus d’informations sur les stratégies. Ces informations sont utilisées par les administrateurs et celles qui appliquent des contextes d’authentification aux ressources.
• La case à cocher Publier sur les applications, lorsqu'elle est sélectionnée, annonce le contexte d'authentification aux applications et le rend disponible pour être assigné. S’il n’est pas sélectionné, le contexte d’authentification n’est pas disponible pour les ressources en aval.
• L’ID est en lecture seule et utilisé dans les jetons et les applications pour les définitions de contexte d’authentification spécifiques à la demande. Éléments répertoriés ici à des fins de résolution des problèmes et de développement.

Ajouter à la stratégie d’accès conditionnel

Les administrateurs peuvent sélectionner des contextes d’authentification publiés dans des stratégies d’accès conditionnel en accédant auxapplications ou actions cloud> et en sélectionnant contexte d’authentification dans le menu Sélectionner ce que cette stratégie s’applique au menu.

Supprimer un contexte d’authentification

Avant de supprimer un contexte d’authentification, assurez-vous qu’aucune application ne l’utilise. Sinon, l’accès aux données d’application n’est pas protégé. Vérifiez cela en vérifiant les journaux de connexion pour les cas où les stratégies d’accès conditionnel du contexte d’authentification sont appliquées.

Pour supprimer un contexte d’authentification, vérifiez qu’il n’a pas de stratégies d’accès conditionnel affectées et qu’il n'est pas publié dans les applications. Cela empêche la suppression accidentelle d’un contexte d’authentification toujours en cours d’utilisation.

Étiqueter des ressources avec des contextes d’authentification

Pour en savoir plus sur l’utilisation de contextes d’authentification, consultez les articles suivants.

• Utiliser des étiquettes de confidentialité pour protéger le contenu dans microsoft Teams, les groupes Microsoft 365 et les sites SharePoint
• Microsoft Defender pour Cloud Apps
• Applications personnalisées
• Privileged Identity Management - Lors de l’activation, nécessitez le contexte d’authentification de l’accès conditionnel Microsoft Entra

Contenu connexe

• Accès conditionnel : conditions : Découvrez comment configurer des conditions pour affiner vos stratégies.
• Stratégies courantes d’accès conditionnel : explorez les modèles de stratégie courants pour commencer rapidement.
• Dépendances d’application cliente : découvrez comment les dépendances affectent les stratégies d’accès conditionnel.