Accès conditionnel : ressources cibles
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.
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.
- Office 365
- Azure Analysis Services
- Azure DevOps
- Explorateur de données Azure
- Azure Event Hubs
- Azure Service Bus
- Azure SQL Database et Azure Synapse Analytics
- Common Data Service
- Microsoft Application Insights Analytics
- Microsoft Azure Information Protection
- API Gestion des services Windows Azure
- Microsoft Defender for Cloud Apps
- Portail de contrôle des accès aux outils de Microsoft Commerce
- Service d’authentification des outils Microsoft Commerce
- Microsoft Forms
- Microsoft Intune
- Inscription à Microsoft Intune
- Planificateur Microsoft
- Microsoft Power Apps
- Microsoft Power Automate
- Recherche Microsoft Bing
- Microsoft StaffHub
- Microsoft Stream
- Microsoft Teams
- Exchange Online
- SharePoint
- Yammer
- Office Delve
- Office Sway
- Outlook Groups
- Service Power BI
- Project Online
- Skype Entreprise Online
- Réseau privé virtuel (VPN)
- Windows Defender ATP
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 :
- 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. 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 :
- Applications publiées par le biais du proxy d’application de Microsoft Entra
- Des applications ajoutées à partir de la galerie
- Des applications personnalisées qui ne se trouvent pas dans la galerie
- Des applications héritées qui sont publiées par le biais de réseaux et de contrôleurs de livraison d’applications
- Des applications qui utilisent l’authentification unique par mot de passe
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. 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 ») .
Toutes les ressources
L’application d’une stratégie d’accès conditionnel à toutes les ressources (anciennement « Toutes les applications cloud ») entraîne l’application de la stratégie pour tous les jetons émis sur les sites web et les services, y compris les profils de transfert de trafic d’accès sécurisé global. 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 Toutes les ressources (anciennement « Toutes les applications cloud ») peuvent bloquer par inadvertance l’accès utilisateur. 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 d’inscription d’appareil sont exclus de la stratégie d’appareil conforme ciblée sur toutes les ressources.
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
- Pour les clients natifs :
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 Accès Internet Microsoft Entra.
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 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.
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
etDevice 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.
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.
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.
- Utiliser des étiquettes de confidentialité pour protéger le contenu dans Microsoft Teams, les groupes Microsoft 365 et les sites SharePoint
- Microsoft Defender for Cloud Apps
- Applications personnalisées