Planifier un déploiement d’accès conditionnel

La planification de votre déploiement d’accès conditionnel joue un rôle capital dans la réussite de la stratégie d’accès de votre organisation pour les applications et les ressources. Les stratégies d’accès conditionnel vous offrent une grande flexibilité pour la configuration. Toutefois, cette flexibilité exige une planification minutieuse de votre part afin d’éviter des résultats indésirables.

L’accès conditionnel Microsoft Entra combine des signaux, tels que l’utilisateur, l’appareil et l’emplacement, afin d’automatiser les décisions et d’appliquer les stratégies d’accès propres à l’organisation pour les ressources. Ces stratégies d’accès conditionnel vous aident à équilibrer la sécurité et la productivité, en appliquant des contrôles de sécurité si nécessaire et en évitant d’interférer avec le travail de l’utilisateur dans le cas contraire.

L’accès conditionnel est la base du moteur de stratégie de sécurité Confiance Zéro de Microsoft.

Diagramme montrant une vue d’ensemble de l’accès conditionnel de haut niveau.

Microsoft fournit des paramètres de sécurité par défaut qui garantissent un niveau de sécurité de base activé dans les locataires qui n’ont pas Microsoft Entra ID P1 ou P2. Avec l’accès conditionnel, vous pouvez créer des stratégies qui offrent la même protection que les paramètres de sécurité par défaut, mais avec une granularité. L’accès conditionnel et les paramètres de sécurité par défaut ne sont pas destinés à être combinés, car la création de stratégies d’accès conditionnel empêche d’activer les paramètres de sécurité par défaut.

Prérequis

Communication des modifications

La communication est essentielle à la réussite de toute nouvelle fonctionnalité. Vous devez communiquer de manière proactive avec vos utilisateurs sur ce qui va changer dans leur expérience, à quel moment les changements seront appliqués et comment ils peuvent obtenir de l’aide en cas de problème.

Composants des stratégies d’accès conditionnel

Les stratégies d’accès conditionnel répondent à des questions posées sur les personnes qui peuvent accéder à vos ressources, sur les ressources auxquelles elles peuvent accéder et dans quelles conditions elles peuvent le faire. Les stratégies peuvent être conçues pour octroyer l’accès, limiter l’accès à l’aide de contrôles de session ou bloquer l’accès. Vous créez une stratégie d’accès conditionnel en définissant des instructions if-then comme celles-ci :

Si une attribution est remplie Appliquer les contrôles d’accès
Si vous êtes un utilisateur membre de Finance accédant à l’application Paie Exiger l’authentification multifacteur et un appareil conforme
Si vous n’êtes pas un membre de Finance accédant à l’application Paie Bloquer l’accès
Si le risque utilisateur est élevé Exiger une authentification multifacteur et un changement de mot de passe sécurisé

Exclusions d’utilisateurs

Les stratégies d’accès conditionnel sont des outils puissants. Nous vous recommandons donc d’exclure les comptes suivants de vos stratégies :

  • Accès d’urgence ou comptes de secours pour empêcher le verrouillage en raison d’une configuration incorrecte de la stratégie. Dans le scénario peu probable, tous les administrateurs sont verrouillés, votre compte d’administration d’accès d’urgence peut être utilisé pour se connecter et prendre des mesures pour récupérer l’accès.
  • Comptes de service et principaux de service, tels que le compte Microsoft Entra Connect Sync. Les comptes de service sont des comptes non interactifs qui ne sont liés à aucun utilisateur particulier. Ils sont généralement utilisés par des services back-end autorisant l’accès par programmation aux applications, mais ils le sont également pour une connexion aux systèmes à des fins administratives. Les appels effectués par les principaux de service ne seront pas bloqués par les stratégies d’accès conditionnel destinées aux utilisateurs. Utilisez l’accès conditionnel des identités de charge de travail pour élaborer des stratégies ciblant les principaux de service.
    • Si votre organisation utilise ces comptes dans des scripts ou du code, envisagez de les remplacer par des identités managées.

Poser les bonnes questions

Voici quelques questions courantes sur les affectations et les contrôles d’accès. Documentez les réponses aux questions pour chaque stratégie avant de la créer.

Utilisateurs ou identités de la charge de travail

  • Quels utilisateurs, groupes, rôles d’annuaire ou identités de charge de travail sont inclus ou exclus de la stratégie ?
  • Quels comptes ou groupes d’accès d’urgence doivent être exclus de la stratégie ?

Applications ou actions cloud

Cette stratégie s’applique-t-elle à toute application, action utilisateur ou contexte d’authentification ? Si oui :

  • À quelles applications ou services la stratégie s’appliquera-t-elle ?
  • Quelles actions de l’utilisateur sont soumises à cette stratégie ?
  • À quels contextes d’authentification cette stratégie s’appliquera-t-elle ?
Filtrer sur des applications

Utiliser un filtre pour les applications afin d’inclure ou d’exclure des applications au lieu de les spécifier individuellement permet aux organisations de :

  • Mettre à l’échelle et cibler facilement un nombre illimité d’applications.
  • Gérer facilement les applications avec des exigences de stratégie similaires.
  • Réduire le nombre de stratégies individuelles.
  • Réduire les erreurs lors de la modification des stratégies : il n’est pas nécessaire d’ajouter/supprimer manuellement des applications de la stratégie. Gérer simplement les attributs.
  • Surmonter les contraintes de taille de stratégie.

Conditions

  • Quelles plateformes d’appareils sont incluses ou exclues de la stratégie ?
  • Quels sont les emplacements réseau connus de l’organisation ?
    • Quels emplacements sont inclus ou exclus de la stratégie ?
  • Quels types d’applications clientes sont inclus ou exclus de la stratégie ?
  • Devez-vous cibler des attributs d’appareil spécifiques ?
  • Si vous utilisez Microsoft Entra ID Protection, voulez-vous incorporer les risques de connexion ou d’utilisateur ?

Contrôles d’octroi ou de blocage

Voulez-vous accorder l’accès aux ressources en exigeant un ou plusieurs des éléments suivants ?

  • Authentification multifacteur
  • Appareil marqué comme conforme
  • Utiliser un appareil à jonction hybride Microsoft Entra
  • Utilisation d’une application cliente approuvée
  • Stratégie de protection des applications activée
  • Modification de mot de passe
  • Conditions d’utilisation acceptées

Le blocage d’accès est un contrôle puissant que vous devez appliquer avec les connaissances appropriées. Les stratégies dotées d’instructions de blocage peuvent avoir des effets secondaires inattendus. Des tests et une validation appropriés sont essentiels avant d’activer le contrôle à grande échelle. Les administrateurs doivent utiliser des outils tels que le mode rapport seul d’accès conditionnel et l’outil What If dans l’accès conditionnel lorsqu’ils apportent des modifications.

Contrôles de session

Voulez-vous appliquer les contrôles d’accès suivants sur les applications cloud ?

  • Utiliser les restrictions appliquées par l’application
  • Utiliser le contrôle d’application par accès conditionnel
  • Appliquer la fréquence de connexion
  • Utiliser les sessions de navigateur persistantes
  • Personnaliser l’évaluation continue de l’accès

Combinaison de stratégies

Lorsque vous créez et attribuez des stratégies, vous devez prendre en compte le fonctionnement des jetons d’accès. Les jetons d’accès accordent ou refusent l’accès selon que les utilisateurs effectuant une requête ont ou non été autorisés et authentifiés. Si le demandeur peut prouver qu’il est bien celui qu’il prétend être, il peut accéder aux ressources ou aux fonctionnalités protégées.

Les jetons d’accès sont émis par défaut si une condition de stratégie d’accès conditionnel ne déclenche pas de contrôle d’accès.

Cette stratégie n’empêche pas l’application d’avoir sa propre capacité à bloquer l’accès.

Par exemple, examinez cet exemple de stratégie simplifiée où :

Utilisateurs : GROUPE FINANCE
Accès à : APPLICATION PAIE
Contrôle d’accès : Authentification multifacteur

  • L’utilisateur A se trouve dans le GROUPE FINANCE. Il est tenu d’effectuer l’authentification multifacteur pour accéder à l’APPLICATION PAIE.
  • L’utilisateur B n’est pas dans le GROUPE FINANCE, il reçoit un jeton d’accès et est autorisé à accéder à l’APPLICATION PAIE sans effectuer l’authentification multifacteur.

Pour vous assurer que les utilisateurs en dehors du groupe Finance ne peuvent pas accéder à l’application Paie, vous pouvez créer une stratégie distincte qui bloque tous les autres utilisateurs, comme la stratégie simplifiée suivante :

Utilisateurs : Inclure tous les utilisateurs / Exclure GROUPE FINANCE
Accès à : APPLICATION PAIE
Contrôle d’accès : Bloquer l’accès

Maintenant, lorsque l’utilisateur B tente d’accéder à l’APPLICATION PAIE, il est bloqué.

Recommandations

Sur la base de ce que nous savons sur l’utilisation de l’accès conditionnel et sur la prise en charge d’autres clients, voici quelques recommandations.

Appliquer des stratégies d’accès conditionnel à chaque application

Assurez-vous qu’au moins une stratégie d’accès conditionnel est appliquée à chaque application. Du point de vue de la sécurité, il est préférable de créer une stratégie qui englobe toutes les ressources (anciennement « Toutes les applications cloud ») et d’exclure les applications auxquelles vous ne souhaitez pas que la stratégie s’applique. Cette pratique vous évite d’avoir à mettre à jour les stratégies d’accès conditionnel chaque fois que vous intégrez une nouvelle application.

Conseil

Soyez très prudent lors de l’utilisation des éléments Bloquer et Toutes les applications dans une stratégie unique. Cette opération peut bloquer les administrateurs et les exclusions ne peuvent pas être configurées pour des points de terminaison importants, comme Microsoft Graph.

Réduire le nombre de stratégies d’accès conditionnel

Créer une stratégie pour chaque application n’est pas efficace et entraîne une administration compliquée. L’accès conditionnel a une limite de 195 stratégies par locataire. Cette limite de 195 stratégies inclut les stratégies d’accès conditionnel dans n’importe quel état, y compris celles en mode rapport uniquement, activées ou désactivées.

Nous vous recommandons d’analyser vos applications et de les regrouper par applications qui présentent les mêmes besoins en ressources pour les mêmes utilisateurs. Par exemple, si toutes les applications Microsoft 365 ou toutes les applications de RH présentent les mêmes exigences pour les mêmes utilisateurs, créez une stratégie unique et incluez toutes les applications auxquelles elle s’applique.

Les stratégies d’accès conditionnel sont contenues dans un fichier JSON, et ce fichier a une limite de taille qui, selon nous, ne devrait pas être dépassée par une stratégie unique. Si vous utilisez une longue liste de GUID dans votre stratégie, vous pouvez atteindre cette limite. Si vous rencontrez ces limites, nous vous recommandons d’utiliser les alternatives suivantes :

Configurer le mode Rapport uniquement

Par défaut, chaque stratégie créée à partir d’un modèle est créée en mode Rapport seul. Nous recommandons aux organisations de tester et de superviser l’utilisation, pour s’assurer du résultat escompté, avant d’activer chaque stratégie.

Activer des stratégies en mode Rapport seul. Une fois que vous avez enregistré une stratégie en mode Rapport seul, vous pouvez voir l’effet sur les connexions en temps réel dans les journaux de connexion. Dans les journaux de connexion, sélectionnez un événement et accédez à l’onglet Rapport seul pour voir le résultat de chaque stratégie en mode Rapport seul.

Vous pouvez voir tous les effets de vos stratégies d’accès conditionnel dans le workbook Insights et rapports. Pour accéder au workbook, vous devez avoir un abonnement Azure Monitor et publier en streaming vos journaux de connexions à un espace de travail Log Analytics.

Planifier une interruption

Pour réduire le risque de verrouillage pendant des interruptions imprévues, planifiez des stratégies de résilience pour votre organisation.

Activer les actions protégées

L’activation des actions protégées place une autre couche de sécurité sur les tentatives de création, de modification ou de suppression d’une stratégie d’accès conditionnel. Les organisations peuvent exiger une nouvelle authentification multifacteur ou un autre contrôle d’octroi avant de modifier la stratégie.

Définir des normes de nommage pour vos stratégies

Une convention de nommage vous permet de rechercher des stratégies et de comprendre leurs objectifs sans les ouvrir dans le portail d’administration Azure. Nous vous recommandons de nommer votre stratégie pour faire ressortir :

  • Un numéro de séquence
  • Les applications cloud auxquelles elle s’applique
  • La réponse
  • L’objet auquel elle s’applique (qui)
  • Quand elle doit s’appliquer

Diagramme montrant des exemples de normes de nommage pour les stratégies.

Exemple : Une stratégie qui exige MFA pour les utilisateurs Marketing accédant à l’application Dynamics CRP depuis des réseaux externes peut être formulée de la façon suivante :

Diagramme montrant un exemple de norme de nommage.

Un nom descriptif vous aide à conserver une vue globale de votre implémentation de l’accès conditionnel. Le numéro de séquence est utile si vous devez faire référence à une stratégie dans une conversation. Par exemple, si vous parlez à un administrateur au téléphone, vous pouvez lui demander d’ouvrir la stratégie CA01 pour résoudre un problème.

Normes de nommage pour les contrôles d’accès d’urgence

En plus de vos stratégies actives, implémentez des stratégies désactivées qui agissent comme des contrôles d’accès résilients secondaires dans les scénarios d’urgence ou de panne. Votre norme de nommage pour les stratégies d’urgence doit inclure quelques éléments supplémentaires :

  • ACTIVER EN CAS D’URGENCE au début, pour faire ressortir le nom au milieu des autres stratégies.
  • Le nom d’interruption auquel elle doit s’appliquer.
  • Un numéro de séquence de classement pour aider l’administrateur à savoir dans quel ordre les stratégies doivent être activées.

Exemple : Le nom suivant indique que cette stratégie est la première d’une série de quatre stratégies à activer en cas d’interruption de l’authentification multifacteur :

  • EM01 - ACTIVER EN CAS D’URGENCE : Interruption MFA [1/4] - Exchange SharePoint - Exiger la jonction Microsoft Entra Hybride Pour utilisateurs VIP.

Bloquez les pays/régions à partir desquels vous ne vous attendez jamais à une connexion.

Microsoft Entra ID vous permet de créer des emplacements nommés. Créez la liste des pays/régions autorisés, puis créez une stratégie de blocage réseau avec ces « pays/régions autorisés » comme exclusion. Cette option représente moins de surcharge de temps pour les clients basés dans des zones géographiques plus petites. Veillez à exempter vos comptes d’accès d’urgence de cette stratégie.

Déployer des stratégies d’accès conditionnel

Quand vous êtes prêt, déployez vos stratégies d’accès conditionnel par phases.

Créer vos stratégies d’accès conditionnel

Pour démarrer rapidement, consultez Modèles de stratégies d’accès conditionnel et Stratégies de sécurité courantes pour les organisations Microsoft 365. Ces modèles sont un moyen pratique de déployer des recommandations Microsoft. Assurez-vous que vos comptes d’accès d’urgence sont exclus.

Évaluer l’impact de la stratégie

Nous vous recommandons d’utiliser les outils suivants pour évaluer l’effet de vos stratégies avant et après des modifications. Une exécution simulée vous donne une bonne idée de l’effet d’une stratégie d’accès conditionnel, mais elle ne remplace pas une série de tests réels dans un environnement de développement correctement configuré.

Tester vos stratégies

Veillez à tester aussi les critères d’exclusion d’une stratégie. Par exemple, vous pouvez exclure un utilisateur ou un groupe d’une stratégie qui exige l’authentification multifacteur. Testez si les utilisateurs exclus sont invités à utiliser l’authentification multifacteur, car l’association d’autres stratégies peut exiger l’authentification multifacteur pour ces utilisateurs.

Réalisez chaque test dans votre plan de test, avec des utilisateurs de test. Le plan de test est important pour comparer les résultats attendus et les résultats réels. Le tableau suivant décrit quelques exemples de cas de test. Ajustez les scénarios et les résultats attendus en fonction de la configuration de vos stratégies d’accès conditionnel.

Policy Scénario Résultat attendu
Connexions risquées L’utilisateur se connecte à l’application à l’aide d’un navigateur non approuvé Calcule un score de risque en fonction de la probabilité que la connexion n’ait pas été effectuée par l’utilisateur. Nécessite que l’utilisateur corrige lui-même le problème via l’authentification multifacteur (MFA)
Gestion des appareils L’utilisateur autorisé tente de se connecter à partir d’un appareil autorisé Accès accordé
Gestion des appareils L’utilisateur autorisé tente de se connecter à partir d’un appareil non autorisé Accès bloqué
Changement de mot de passe pour les utilisateurs à risque L’utilisateur autorisé tente de se connecter avec des informations d’identification compromises (connexion à risque élevé) L’utilisateur est invité à changer le mot de passe ou l’accès est bloqué selon votre stratégie

Déployer en production

Une fois que vous avez vérifié l’effet en utilisant le mode Rapport seul, un administrateur peut changer le bouton bascule Activer la stratégie de Rapport seul à Activé.

Restaurer les stratégies

Si vous devez restaurer les stratégies que vous venez d’implémenter, utilisez une ou plusieurs options suivantes :

  • Désactiver la tâche. La désactivation d’une stratégie garantit qu’elle ne s’applique pas quand un utilisateur tente de se connecter. Vous pouvez toujours revenir en arrière et activer la stratégie quand vous voulez l’utiliser.

  • Exclure un utilisateur ou un groupe d’une stratégie. Si un utilisateur ne peut pas accéder à l’application, vous pouvez l’exclure de la stratégie.

    Attention

    Les exclusions sont à utiliser avec parcimonie, et uniquement si l’utilisateur est approuvé. Les utilisateurs doivent être rajoutés dans la stratégie ou le groupe dès que possible.

  • Si une stratégie est désactivée ou n’est plus nécessaire, supprimez-la.

Résoudre les problèmes de stratégie d’accès conditionnel

Si un utilisateur rencontre un problème avec une stratégie d’accès conditionnel, collectez les informations suivantes pour faciliter la résolution du problème.

  • Nom d’utilisateur principal
  • Nom d’affichage de l’utilisateur
  • Nom du système d’exploitation
  • Horodatage (approximation acceptée)
  • Application cible
  • Type d’application cliente (navigateur ou client)
  • ID de corrélation (ID propre à la connexion)

Si l’utilisateur a reçu un message contenant un lien Plus de détails, il peut collecter la plupart de ces informations pour vous.

Dès que vous avez collecté les informations, consultez les ressources suivantes :