Partager via

Accès conditionnel : ressources cibles

  • Article

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

  • Les administrateurs peuvent choisir parmi la liste des applications ou des services qui incluent les applications Microsoft intégrées, ainsi que toutes les applications intégrées de Microsoft Entra, notamment les applications en galerie, hors galerie, et les applications publiées via l'Application Proxy.
  • Les administrateurs peuvent choisir de définir une stratégie non basée sur une application cloud, mais 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 des fonctionnalités améliorées.
  • Les administrateurs peuvent utiliser le contexte d’authentification pour fournir une couche supplémentaire de sécurité dans les applications.

Capture d’écran montrant une stratégie d’accès conditionnel et le panneau ressources cibles.

Applications cloud Microsoft

La plupart des applications cloud Microsoft existantes sont incluses dans la liste des applications à partir de laquelle vous pouvez effectuer votre sélection.

Les administrateurs peuvent attribuer une stratégie d'accès conditionnel à ces applications Microsoft en cloud. Certaines applications telles qu’Office 365 et l’API Gestion des services Windows Azure incluent plusieurs applications ou services enfants associés.

Important

Les applications disponibles pour l’accès conditionnel suivent un processus d’intégration et de validation. Ces applications n’incluent pas toutes les applications Microsoft. De nombreuses applications sont des services principaux qui ne sont pas destinés à leur appliquer directement une stratégie. Si vous recherchez une application manquante, vous pouvez contacter l’équipe d’application spécifique ou effectuer une demande sur UserVoice.

Office 365

Microsoft 365 fournit des services de collaboration et de productivité informatiques comme 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, ont des dépendances par rapport à d’autres, comme SharePoint ou Exchange.

La suite Office 365 permet de cibler tous ces services en même temps. Nous vous recommandons d’utiliser la nouvelle suite 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 susceptibles de se produire à cause 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 risquent d’ê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’intégralité de la suite Office 365 ou des applications cloud Office 365 spécifiques de la stratégie 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
  • 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 (Interface de ligne de commande Azure)
  • Portail Azure Data Factory
  • Azure DevOps
  • 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
  • Instance managée SQL
  • Portail de l’administrateur d’abonnements Visual Studio

Remarque

L’application API Gestion des services Windows Azure s’applique à Azure PowerShell, qui appelle l’API Azure Resource Manager. Elle ne s’applique pas à Microsoft Graph PowerShell, qui appelle l’API Microsoft Graph.

Pour plus d’informations sur la configuration d’un exemple de stratégie pour l’API Gestion des services Windows Azure, consultez Accès conditionnel : Exiger l’authentification multifacteur pour la gestion Azure.

Conseil

Pour Azure Government, vous devez cibler l’application de l’API de gestion Cloud Azure Government.

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 :

  • Portail Azure
  • 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.

Remarque

L’application Microsoft Admin Portals s’applique uniquement aux connexions interactives aux portails d’administration répertoriés. Les connexions aux ressources ou services sous-jacents, tels que des API Microsoft Graph ou Azure Resource Manager, ne sont pas couvertes par cette application. Ces ressources sont protégées par l’application API Gestion des services Windows Azure . Ce groupement permet aux clients de suivre le parcours d’adoption de l’authentification multifacteur pour des administrateurs sans affecter l’automatisation qui s’appuie sur des API et PowerShell. Lorsque vous êtes prêt, Microsoft recommande d’utiliser une stratégie nécessitant que les administrateurs effectuent toujours l’authentification multifacteur pour une protection complète.

Autres applications

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

Remarque

Étant donné que la stratégie d’accès conditionnel définit les conditions requises pour accéder à un service, vous n’êtes pas en mesure de l’appliquer à une application cliente (publique/native). En d’autres termes, la stratégie n’est pas définie directement sur une application cliente (publique/native), mais elle est appliquée lorsqu’un client appelle un service. Par exemple, une stratégie définie sur un service SharePoint s’applique à tous les clients qui appellent SharePoint. Une stratégie définie sur Exchange s’applique à la tentative d’accès à la messagerie à l’aide du client Outlook. C’est pourquoi les applications clientes (publiques/natives) ne sont pas disponibles pour la sélection dans le sélecteur d’application et l’option d’accès conditionnel n’est pas disponible dans les paramètres d’application pour l’application cliente (publique/native) inscrite dans votre abonné.

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 ») .

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 au client public lui-même, mais s’appliquent en fonction des ressources demandées par les clients publics.
  • 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 dans la connexion.

Pour plus d’informations, consultez l’article Sur les applications clientes publiques et 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 entraîne l’application de la stratégie pour toutes les demandes de jeton à partir 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).

Important

Microsoft recommande de créer une stratégie d’authentification multifacteur de référence ciblant tous les utilisateurs et toutes les ressources (sans exclusions d’application), comme celle expliquée dans Exiger l’authentification multifacteur pour tous les utilisateurs.

Comportement de l'accès conditionnel lorsqu'une stratégie pour toutes les ressources a 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 référence recommandée sans exclusions d’application ne peut pas être configurée pour des raisons liées aux activités de l'entreprise, et que la stratégie de sécurité de votre organisation doit inclure des étendues à 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), l’alternative consiste à 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 >de sécurité personnalisésWindows 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 auxstratégiesd’accès> conditionnel d’Entra ID>.
  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. Enregistrer la politique

Toutes les ressources Internet avec l’Accès global sécurisé

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 de transfert de trafic dans l’accès global sécurisé permettent aux administrateurs de définir et de contrôler la façon dont le trafic est acheminé via Accès Internet Microsoft Entra et Accès privé Microsoft Entra. 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.

Actions utilisateur

Les actions utilisateur sont des tâches que peut effectuer un utilisateur. Actuellement, l’accès conditionnel prend en charge deux actions utilisateur :

  • Inscrire des informations de sécurité : cette action utilisateur permet d’appliquer la stratégie d'accès conditionnel lorsque des utilisateurs habilités à une inscription combinée tentent d'inscrire leurs informations de sécurité. Pour plus d’informations, consultez l’article sur l’inscription combinée des informations de sécurité.

Remarque

Lorsque les administrateurs appliquent une stratégie visant les actions des utilisateurs pour enregistrer des informations de sécurité, si le compte d'utilisateur est un invité à partir d'un compte personnel Microsoft (MSA), utiliser le contrôle « Exiger une authentification multifacteur » obligera l'utilisateur MSA à enregistrer des informations de sécurité auprès de l’organisation. Si l’utilisateur invité provient d’un autre fournisseur tel que Google, l’accès est bloqué.

  • 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 à l’ID Microsoft Entra. Elle apporte de la granularité à la configuration de l’authentification multifacteur pour l’inscription ou la jonction d’appareils au lieu d’une stratégie à l’échelle du locataire telle qu’elle existe actuellement. Il existe trois points clés à prendre en compte pour cette action de l’utilisateur :
    • Require multifactor authentication est le seul contrôle d’accès disponible avec cette action utilisateur. 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 Microsoft Entra ou ne s’y appliquent pas.
    • Les conditions Client apps, Filters for devices et Device state ne sont pas disponibles avec cette action de l’utilisateur, car elles dépendent de l’inscription d’appareil Microsoft Entra pour appliquer les stratégies d’accès conditionnel.

Avertissement

Lorsqu'une stratégie d'accès conditionnel est configurée avec l'action Inscrire ou joindre des appareils, vous devez définir Entra ID sur Non dans Paramètres des appareils de Vue d'ensemble des Appareils. Dans le cas contraire, les stratégies d’accès conditionnel ne sont pas appliquées correctement avec cette action utilisateur. Pour plus d’informations sur ce paramètre d’appareil, consultez Configurer les paramètres de l’appareil.

Contexte d'authentification

Un contexte d’authentification permet de renforcer la sécurité des données et des actions dans des applications. Il peut s’agir de vos propres applications personnalisées, d’applications métier personnalisées, d’applications telles que SharePoint, ou d’applications protégées par Microsoft Defender for Cloud Apps.

Par exemple, une organisation peut conserver dans des sites SharePoint des fichiers tels que le menu du déjeuner ou sa recette secrète de sauce barbecue. Tout le monde aura probablement accès au site du menu du déjeuner, mais les utilisateurs qui ont accès au site de la recette secrète de sauce barbecue risquent de devoir y accéder à partir d’un appareil géré et d’accepter des conditions d’utilisation spécifiques.

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

Configurer des contextes d’authentification

Les contextes d’authentification sont gérés sous Entra ID>, l'accès conditionnel> et le contexte d’authentification.

Capture d’écran montrant la gestion des contextes d’authentification.

Créez de nouvelles définitions de contexte d’authentification en sélectionnant Nouveau contexte d’authentification. Les organisations sont limitées à un total de 99 définitions de contexte d’authentification c1-c99. Configurez les attributs suivants :

  • 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.
  • Description fournit plus d’informations sur les stratégies 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 cochée, publie le contexte d’authentification pour les applications et les rend disponibles à affecter. Si elle n’est pas activée, 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. Il est indiqué 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 leurs stratégies d’accès conditionnel sous Affectations>d’applications cloud ou d’actions , puis sélectionner le contexte d’authentification dans le menu Sélectionner ce que cette stratégie s’applique au menu.

Capture d’écran montrant comment ajouter un contexte d’authentification d’accès conditionnel à une stratégie

Supprimer un contexte d’authentification

Lorsque vous supprimez un contexte d’authentification, vérifiez qu’aucune application ne l’utilise encore. Sinon, l’accès aux données d’application n’est plus protégé. Vous pouvez confirmer ce prérequis 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, celui-ci ne doit pas avoir de stratégies d’accès conditionnel affectées et ne doit pas être publié dans les applications. Cette condition requise permet d’éviter la suppression accidentelle d’un contexte d’authentification qui est toujours en cours d’utilisation.

Étiqueter des ressources avec des contextes d’authentification

Pour plus d’informations sur l’utilisation d’un contexte d’authentification dans des applications, consultez les articles suivants.

Étapes suivantes