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 affecter une stratégie d’accès conditionnel aux applications cloud suivantes à partir de Microsoft. Certaines applications comme Office 365 et l’API Gestion des services Windows Azure comprennent plusieurs applications ou services enfants associés. Comme nous ajoutons continuellement d’autres applications, la liste suivante n’est pas exhaustive et est susceptible de changer.

Important

Les applications disponibles pour l’accès conditionnel ont suivi un processus d’intégration et de validation. Cette liste n’inclut pas toutes les applications Microsoft, car nombre d’entre elles sont des services principaux non censés être régis par une stratégie qui leur est directement appliquée. 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 :

  • API du modèle de déploiement Classic
  • Azure PowerShell
  • Azure CLI
  • Azure DevOps
  • Portail Azure Data Factory
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database
  • Instance managée SQL
  • Azure Synapse
  • Portail de l’administrateur d’abonnements Visual Studio
  • Microsoft IoT Central

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. Cela 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. Une fois prêt, Microsoft vous recommande d’utiliser une stratégie exigeant 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 :

Notes

É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 dans le sélecteur d’applications Cloud 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 locataire.

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 applications cloud.

Toutes les applications cloud

L’application d’une stratégie d’accès conditionnel à Toutes les applications cloud entraîne l’application de la stratégie à tous les jetons émis pour des sites web et des services. Cette option inclut les applications qui ne peuvent pas être ciblées individuellement dans la stratégie d’accès conditionnel, par exemple Microsoft Entra ID.

Dans certains cas, une stratégie ciblant toutes les applications cloud peut bloquer par inadvertance l’accès des utilisateurs. Ces cas sont exclus de l’application de la stratégie, et comprennent les points suivants :

  • Services nécessaires pour atteindre la posture de sécurité souhaitée. Par exemple, les appels liés aux inscriptions d’appareils sont exclus de la stratégie de conformité des appareils ciblant toutes les applications cloud.

  • Appels à Azure AD Graph et Microsoft Graph pour accéder aux informations sur le profil utilisateur, l’appartenance aux groupes et les relations, qui sont couramment utilisées par les applications exclues de la stratégie. Les étendues exclues sont listées ci-dessous. Le consentement est toujours nécessaire pour permettre aux applications d’utiliser ces autorisations.

    • Pour les clients natifs :
      • Azure AD Graph : email, offline_access, openid, profile, User.Read
      • Microsoft Graph : email, offline_access, openid, profile, User.Read, People.Read
    • Pour les clients confidentiels/authentifiés :
      • Azure AD Graph : email, offline_access, openid, profile, User.Read, User.Read.All, and 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

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.

Notes

Lors de l’application d’une stratégie ciblant les actions d’un utilisateur pour inscrire des informations de sécurité, si le compte d’utilisateur est un invité d’un compte Microsoft (MSA) personnel, l’utilisation du contrôle « Exiger une authentification multifacteur » nécessite l’inscription par l’utilisateur MSA 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 à 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.
    • Quand une stratégie d’accès conditionnel est activée avec cette action utilisateur, vous devez définir Vue d’ensemble>de l’identité >des appareils>Paramètres d’appareil - Devices to be Microsoft Entra joined or Microsoft Entra registered require multifactor authentication sur Non. Dans le cas contraire, la stratégie d’accès conditionnel avec cette action d’utilisateur n’est pas appliquée correctement. Pour plus d’informations sur ce paramètre d’appareil, consultez Configuration des paramètres d’appareil.

Profils de transfert de trafic

Les profils de transfert de trafic dans Global Secure Access 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.

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