Cet article décrit une architecture d’accès conditionnel qui respecte les principes de la Confiance Zéro. L’architecture utilise une approche basée sur les personnages pour former une infrastructure d’accès conditionnel structuré.
Architecture d’accès conditionnel Confiance Zéro
Vous devez commencer par choisir une architecture. Nous vous recommandons de considérer une architecture d’accès conditionnel ciblée ou Confiance Zéro. Ce diagramme montre les paramètres correspondants :
L’architecture d’accès conditionnel Confiance Zéro est celle qui correspond le mieux aux principes de la Confiance Zéro. Si vous sélectionnez l’option Toutes les applications cloud dans une stratégie d’accès conditionnel, tous les points de terminaison sont protégés par les contrôles d’octroi fournis, tels que l’utilisateur connu et l’appareil connu ou conforme. Mais la stratégie ne s’applique pas seulement aux points de terminaison et aux applications qui prennent en charge l’accès conditionnel. Elle s’applique à n’importe quel point de terminaison avec lequel l’utilisateur interagit.
Tel est le cas par exemple d’un point de terminaison de flux de connexion d’appareil utilisé dans plusieurs nouveaux outils PowerShell et Microsoft Graph. Le flux de connexion d’appareil permet d’autoriser la connexion d’un appareil sur lequel il n’est pas possible d’afficher un écran de connexion, comme un appareil IoT.
Une commande de connexion basée sur l’appareil est exécutée sur l’appareil en question et un code est présenté à l’utilisateur. Ce code est utilisé sur un autre appareil. L’utilisateur accède à https://aka.ms/devicelogin et spécifie son nom d’utilisateur et son mot de passe. Après la connexion à partir de l’autre appareil, la connexion s’opère sur l’appareil IoT dans le contexte de cet utilisateur.
La difficulté avec cette connexion est qu’elle ne prend pas en charge l’accès conditionnel basé sur l’appareil. Cela signifie que personne ne peut utiliser les outils et les commandes si vous appliquez une stratégie de référence qui impose un utilisateur connu et un appareil connu pour toutes les applications cloud. D’autres applications rencontrent le même problème avec l’accès conditionnel basé sur l’appareil.
L’architecture ciblée, quant à elle, repose sur le principe de cibler uniquement les applications individuelles à protéger dans les stratégies d’accès conditionnel. Dans ce cas, la connexion aux appareils pour les points de terminaison précédemment couverts par toutes les applications cloud, tels que les appels de graphe à Microsoft Entra ID, n’est pas protégée par les stratégies d’accès conditionnel afin qu’elles continuent de fonctionner.
Lorsque vous utilisez la connexion aux appareils comme exemple pour différencier les deux architectures, vous pouvez vous authentifier avec la connexion aux appareils. La connexion aux appareils peut potentiellement être autorisée pour une ou plusieurs applications individuelles, étant donné que chaque application peut être ciblée et peut ainsi être exclue dans une stratégie d’accès conditionnel qui nécessite une connexion basée sur l’appareil.
Avec cette architecture ciblée, le risque est que vous omettiez de protéger toutes vos applications cloud. Même ainsi, vous choisiriez toutes les applications sélectionnables dans les stratégies d’accès conditionnel. Vous laissez sans protection l’accès aux applications qui ne peuvent pas être sélectionnées. Les exemples incluent l’accès au portail Office, au portail Azure EA (Accord Entreprise) et au portail des informations de sécurité, qui sont tous des portails très sensibles.
Un autre élément à prendre en considération est le nombre d’applications Office 365 et Microsoft Entra qui s’accroît au fil du temps, à mesure que Microsoft et ses partenaires lancent de nouvelles fonctionnalités et que vos administrateurs informatiques intègrent différentes applications à Microsoft Entra ID. L’accès à toutes ces applications n’est protégé que si vous disposez d’un mécanisme capable de détecter toute nouvelle application prenant en charge l’accès conditionnel et de lui appliquer automatiquement une stratégie. Créer et tenir à jour un tel script peut s’avérer difficile.
Par ailleurs, le nombre maximal d’applications pris en charge pour une stratégie d’accès conditionnel est d’environ 250. Il se peut que vous obteniez une erreur indiquant un dépassement de charge utile après avoir ajouté 600 applications, mais ce nombre n’est pas pris en charge.
Personnages d’accès conditionnel
Il existe diverses manières de structurer les stratégies d’accès conditionnel. Par exemple, une approche consiste à structurer les stratégies en fonction de la sensibilité de la ressource faisant l’objet de l’accès. Dans la pratique, il peut être difficile d’implémenter cette approche de telle manière que l’accès aux ressources continue d’être protégé pour divers utilisateurs.
Par exemple, si vous définissez une stratégie d’accès conditionnel qui exige un utilisateur connu et un appareil connu pour l’accès à une ressource sensible à laquelle les invités et les employés doivent pouvoir accéder, la demande d’accès n’aboutira pas quand les invités tenteront d’y accéder à partir d’un appareil géré. Vous devez ajuster la stratégie d’accès conditionnel de telle sorte qu’elle réponde aux deux exigences. Or, le plus souvent, la stratégie répondra au final à l’exigence la moins sécurisée.
Une autre approche consiste à essayer de définir des stratégies d’accès en fonction de l’emplacement d’un utilisateur dans l’organisation. Avec cette approche, vous risquez de vous retrouver avec un grand nombre de stratégies d’accès conditionnel, ce qui sera ingérable.
Une meilleure approche consiste à structurer les stratégies par rapport à des besoins d’accès communs et à grouper un ensemble de besoins d’accès dans un personnage représentant un groupe d’utilisateurs ayant les mêmes besoins. Les personnages sont des types d’identité qui partagent des attributs d’entreprise, des responsabilités, des expériences, des objectifs et un accès communs.
Il est essentiel de comprendre la façon dont les divers personnages accèdent aux ressources d’entreprise pour élaborer une stratégie de Confiance Zéro exhaustive.
Voici quelques personnages d’accès conditionnel suggérés par Microsoft :
Microsoft recommande également de définir un personnage distinct pour les identités qui ne font partie d’aucun autre groupe de personnages. Ce personnage est appelle Global. Le personnage Global est destiné à appliquer des stratégies pour les identités qui ne se trouvent pas dans un groupe de personnages ainsi que les stratégies qui doivent s’appliquer pour tous les personnages.
Les sections suivantes décrivent certains personnages recommandés.
Global
Global est un personnage/espace réservé destiné aux stratégies de nature générale. Il sert à définir des stratégies qui s’appliquent à tous les personnages ou qui ne s’appliquent pas à un personnage en particulier. Utilisez-le pour les stratégies qui ne sont pas couvertes par d’autres personnages. Vous avez besoin de ce personnage pour protéger tous les scénarios entrant en ligne de compte.
Par exemple, supposez que vous voulez utiliser une même stratégie pour bloquer l’authentification héritée pour tous les utilisateurs. Vous pouvez en faire une stratégie globale au lieu d’utiliser un groupe de stratégies héritées potentiellement différentes pour les divers personnages.
Autre exemple : vous voulez bloquer un compte ou un utilisateur donné pour des applications spécifiques, et l’utilisateur ou le compte ne fait partie d’aucun personnage. Par exemple, si vous créez une identité cloud dans le locataire Microsoft Entra, cette identité ne fait partie d’aucun autre personnage, car aucun rôle Microsoft Entra ne lui est attribué. Vous pouvez toujours empêcher l’identité d’accéder aux services Office 365.
Vous pouvez éventuellement bloquer tous les accès aux identités qui ne sont couvertes par un groupe de personnages. Vous pouvez même choisir simplement d’appliquer l’authentification multifacteur.
Administrateurs
Dans ce contexte, un administrateur est une identité non invitée, cloud ou synchronisée, qui a un rôle d’administrateur Microsoft Entra ID ou Microsoft 365 (par exemple, dans Microsoft Defender pour les applications cloud, Exchange, Defender pour point de terminaison ou le Gestionnaire de conformité). Étant donné que les invités qui ont ces rôles sont couverts par un autre personnage, les invités sont exclus de ce personnage.
Certaines entreprises disposent de comptes distincts pour les rôles d’administrateur sensibles sur lesquels ce personnage est basé. Idéalement, les administrateurs utilisent ces comptes sensibles à partir d’une station de travail à accès privilégié. Or, nous constatons souvent que les comptes d’administrateur sont utilisés sur des stations de travail standard, où l’utilisateur bascule simplement entre les comptes sur un même appareil.
Vous souhaiterez peut-être établir une différenciation en fonction de la sensibilité des rôles d’administrateur cloud et attribuer des rôles Azure moins sensibles au personnage internes au lieu d’utiliser des comptes distincts. Vous pouvez alors opter plutôt pour une élévation juste-à-temps (JAT). Dans ce cas, un utilisateur est ciblé par deux ensembles de stratégies d’accès conditionnel, un pour chaque personnage. Si vous utilisez des stations de travail à accès privilégié, vous pouvez aussi mettre en place des stratégies qui utilisent des filtres pour appareils mobiles dans un accès conditionnel pour restreindre l’accès afin que les administrateurs soient autorisés uniquement sur les stations de travail à accès conditionnel.
Développeurs
Le personnage Développeurs contient des utilisateurs qui ont des besoins uniques. Ils sont basés sur des comptes Active Directory synchronisés avec Microsoft Entra ID, mais ils ont besoin d’un accès spécial à des services comme Azure DevOps, aux pipelines CI/CD, au flux de code d’appareil et à GitHub. Le personnage Développeurs peut comporter des utilisateurs considérés comme internes et d’autres considérés comme externes, mais une personne ne doit se trouver que dans un seul de ces personnages.
Internes
« Internes » contient tous les utilisateurs qui possèdent un compte Active Directory synchronisé avec Microsoft Entra, qui sont des employés de l’entreprise, et qui travaillent dans un rôle d’utilisateur final standard. Nous vous recommandons d’ajouter les utilisateurs internes qui sont développeurs au personnage Développeurs.
Externes
Ce personnage contient tous les consultants externes qui possèdent un compte Active Directory synchronisé avec Microsoft Entra ID. Nous vous recommandons d’ajouter les utilisateurs externes qui sont développeurs au personnage Développeurs.
Invités
« Invités » contient tous les utilisateurs qui possèdent un compte invité Microsoft Entra et qui ont été invités au locataire du client.
GuestAdmins
« Administrateurs invités » contient tous les utilisateurs qui possèdent un compte invité Microsoft Entra auquel l’un des rôles d’administrateur mentionnés précédemment a été attribué.
Comptes de service Microsoft 365
Ce personnage comprend les comptes de service basés sur l’utilisateur (Microsoft Entra ID) cloud qui servent à accéder aux services Microsoft 365 quand aucune autre solution ne répond aux besoins, comme utiliser une identité de service géré.
Comptes de service Azure
Ce personnage comprend les comptes de service basés sur l’utilisateur (Microsoft Entra ID) cloud qui servent à accéder aux services Azure (IaaS/PaaS) quand aucune autre solution ne répond aux besoins, comme utiliser une identité de service géré.
Comptes de service d’entreprise
Ce personnage contient les comptes de service basés sur l’utilisateur qui présentent toutes les caractéristiques suivantes :
- Origine Active Directory local.
- Utilisation locale ou à partir d’une machine virtuelle IaaS dans un autre centre de données (cloud), comme Azure.
- Synchronisés avec une instance Microsoft Entra qui accède à un service Azure ou Microsoft 365.
Ce scénario est à éviter.
Identités de charge de travail
Ce personnage contient des identités d’ordinateur, comme des principaux de service et des identités gérées Microsoft Entra. L’accès conditionnel prend désormais en charge la protection de l’accès aux ressources à partir de ces comptes, avec certaines limitations en ce qui concerne les conditions et les contrôles d’octroi disponibles.
Cartes de modèle d’accès
Nous vous recommandons d’utiliser des cartes de modèle d’accès pour définir les caractéristiques de chaque personnage. Voici un exemple :
La carte de modèle de chaque personnage fournit l’entrée pour créer les stratégies d’accès conditionnel spécifiques pour chaque personnage.
Conseils relatifs à l’accès conditionnel
Examinez une infrastructure d’accès conditionnel qui inclut une approche structurée pour le regroupement de stratégies en fonction des personnages créés.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Claus Jespersen | Principal Consultant ID&Sec
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Parcours d'apprentissage : Implémenter et gérer les identités et les accès
- Qu’est-ce que l’accès conditionnel ?
- Stratégies d’accès conditionnel courantes