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 à partir de la liste des applications ou des services qui comprend des applications Microsoft intégrées et des application Microsoft Entra intégrée, y compris des applications de la galerie et hors galerie ainsi que des applications publiées par le biais du Proxy d’application.
  • Les administrateurs peuvent choisir de définir une stratégie qui n’est pas 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, autorisant l’accès conditionnel à appliquer des contrôles autour de ces actions.
  • Les administrateurs peuvent cibler des profils de transfert de trafic à partir de Global Secure Access pour des fonctionnalités améliorées.
  • Les administrateurs peuvent utiliser un contexte d’authentification pour fournir une couche supplémentaire de sécurité à l’intérieur des applications.

Capture d’écran montrant la stratégie d’accès conditionnel et le panneau des 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 comme Office 365 et l’API Gestion des services Windows Azure API 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 formuler 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. Pour éviter les problèmes de dépendances de service, nous vous conseillons d’utiliser la nouvelle suite Office 365 plutôt que de cibler les applications cloud individuellement.

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 des services inclus dans l’article Applications incluses dans l’accès conditionnel pour la suite d’applications Office 365.

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

Dans la mesure où la stratégie est appliquée au portail de gestion Azure et à l’API, les services ou les clients ayant une dépendance de service d’API Azure peuvent être indirectement impactés. Par exemple :

  • Azure CLI
  • Portail Azure Data Factory
  • Azure DevOps
  • Azure Event Hubs
  • Azure PowerShell
  • Azure Service Bus
  • Azure SQL Database
  • Azure Synapse
  • API du modèle de déploiement Classic
  • Centre d’administration Microsoft 365
  • Microsoft IoT Central
  • SQL Managed Instance
  • 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 façon de configurer 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. Quand vous êtes prêt(e), Microsoft recommande d’utiliser une stratégie exigeant que les administrateurs effectuent toujours une 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. Le seul moyen 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 visualiser les journaux de connexion pour ces types de clients depuis le centre d’administration Microsoft Entra :

  1. Connectez-vous au centre d’administration Microsoft Entra en tant que Lecteur de rapports.
  2. Parcourez jusqu'à Identité>Surveillance et intégrité>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 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 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).

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 faibles privilèges sont automatiquement exclues chaque fois qu'une application est exclue dans une politique 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 privilèges de faible niveau 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 Informations de référence sur les autorisations Microsoft Graph et Étendues et autorisations dans la plateforme d’identités Microsoft.

Protection des informations d’annuaire

Si la stratégie MFA recommandée sans exclusions d’application ne peut pas être configurée pour des raisons professionnelles, et 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 (0000000002-0000000000000000000000000000000000). 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 de Microsoft Entra en tant qu'administrateur(-trice) de définition d'attributs et administrateur(-trice) d'attribution d'attributs.
  2. Naviguez jusqu'à Protection>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’attribut de sécurité personnalisées dans Microsoft Entra ID.
  4. Accédez à Identité>Applications>Enterprise applications.
  5. Supprimez le filtre type d’application et recherchez l'ID d’application qui commence par 00000002-0000-0000-c000-000000000000.
  6. Sélectionnez attributs de sécurité personnalisés>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. Parcourez Protection des données>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 des 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 global sécurisé permettent aux administrateurs de cibler le profil de transfert du trafic internet à partir de l’Accès Internet Microsoft Entra.

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 un exemple de la façon d'appliquer 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 :

  • Enregistrer les informations de sécurité : cette action utilisateur permet d’appliquer la stratégie d’accès conditionnel lorsque les utilisateurs pour lesquels l’inscription combinée est activée tentent d’enregistrer leurs informations de sécurité. Vous trouverez plus d’informations dans l’article Enregistrement des informations de sécurité combinées.

Remarque

Lorsque les administrateurs appliquent une stratégie ciblant les actions des utilisateurs pour enregistrer des informations de sécurité, si le compte d'utilisateur est un compte invité à partir d'un compte personnel Microsoft (MSA), l'utilisation du contrôle « Exiger l'authentification multifacteur » obligera l'utilisateur du MSA à enregistrer des informations de sécurité auprès de l'organisation. Si l’utilisateur(-trice) invité(e) 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 à Microsoft Entra ID. 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 utilisateur Inscrire ou joindre des appareils, vous devez définir Identité>Appareils>Vue d’ensemble>Paramètres de l’appareil - Require Multifactor Authentication to register or join devices with Microsoft Entra sur Non. 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 Configuration des paramètres d’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 stratégie d’accès conditionnel.

Configurer des contextes d’authentification

Les contextes d’authentification sont managés sous le contexte d’authentification>de l’accès conditionnel>de la protection des données.

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

Créez des 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 :

  • Le Nom d’affichage est le nom utilisé pour identifier le contexte d’authentification dans Microsoft Entra ID et dans les applications qui utilisent des contextes d’authentification. Nous recommandons de choisir des noms utilisables dans des ressources, comme appareils de confiance, afin de réduire le nombre de contextes d’authentification requis. 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 des informations supplémentaires sur les stratégies utilisées par les administrateurs et les personnes qui appliquent des contextes d’authentification à des ressources.
  • La case à cocher Publier sur les applications, quand elle est activée, publie le contexte d’authentification sur les applications et rend celle-ci disponibles pour affectation. Si elle n’est pas activée, le contexte d’authentification n’est pas disponible pour les ressources en aval.
  • L’ ID, en lecture seule, est utilisé dans des jetons et des applications pour des définitions de contexte d’authentification spécifiques d’une 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>Applications ou actions cloud et en sélectionnant Contexte d’authentification depuis le menu Sélectionner ce à quoi cette stratégie s’applique.

Capture d’écran montrant l’ajout d’un contexte d’authentification de l’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