Cet article décrit une architecture d’accès conditionnel qui respecte les principes de confiance zéro. L’architecture utilise une approche basée sur des personnages pour former une infrastructure d’accès conditionnel structurée.
Architecture de confiance zéro de l’accès conditionnel
Vous devez d’abord choisir une architecture. Nous vous recommandons d’envisager une architecture d’accès conditionnel à confiance zéro ou ciblée. Ce diagramme montre les paramètres correspondants :
L’architecture d’accès conditionnel Confiance Zéro est celle qui convient le mieux aux principes de 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 uniquement aux points de terminaison et aux applications qui prennent en charge l’accès conditionnel. Il s’applique à tout point de terminaison avec lequel l’utilisateur interagit.
Un exemple est un point de terminaison de flux de connexion d’appareil utilisé dans différents nouveaux outils PowerShell et Microsoft Graph. Le flux de connexion d’appareil permet d’autoriser la connexion à partir 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 donné et un code s’affiche à 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 réussit sur l’appareil IoT dans ce contexte utilisateur.
La difficulté avec cette connexion est qu’elle ne prend pas en charge l’accès conditionnel basé sur les appareils. Cela signifie que personne ne peut utiliser les outils et les commandes si vous appliquez une stratégie de base qui nécessite un utilisateur connu et un appareil connu pour toutes les applications cloud. Il existe d’autres applications qui présentent le même problème avec l’accès conditionnel basé sur l’appareil.
L’autre architecture, la ciblée une, repose sur le principe que vous ciblez uniquement les applications individuelles que vous souhaitez protéger dans les stratégies d’accès conditionnel. Dans ce cas, la connexion d’appareil pour les points de terminaison précédemment couverts par toutes les applications cloud, telles que les appels de graphe à l’ID Microsoft Entra, n’est pas protégée par les stratégies d’accès conditionnel, afin qu’elles continuent de fonctionner.
Lorsque vous utilisez device-login comme exemple pour différencier les deux architectures, vous pouvez vous authentifier avec device-login. La connexion d’appareil peut potentiellement être autorisée pour une ou plusieurs applications individuelles, étant donné que chaque application est ciblable et peut ainsi être exclue dans une stratégie d’accès conditionnel qui nécessite une connexion basée sur l’appareil.
Le défi avec l’architecture ciblée est que vous pourriez oublier de protéger toutes vos applications cloud. Même si vous choisissez toutes les applications sélectionnables dans les stratégies d’accès conditionnel. Vous laissez l’accès aux applications qui ne peuvent pas être sélectionnées sans protection. Les exemples incluent l’accès au portail Office, au portail Azure EA (Contrat Entreprise) et au portail d’informations de sécurité, qui sont tous des portails très sensibles.
Une autre considération est que le nombre d’applications Office 365 et Microsoft Entra augmente au fil du temps, car Microsoft et les partenaires publient de nouvelles fonctionnalités et que vos administrateurs informatiques intègrent différentes applications à l’ID Microsoft Entra. L’accès à toutes ces applications est protégé uniquement si vous disposez d’un mécanisme qui détecte toute nouvelle application prenant en charge l’accès conditionnel et qui applique automatiquement une stratégie à celle-ci. La création et la maintenance d’un tel script peuvent être difficiles.
En outre, le nombre maximal d’applications prises en charge pour une stratégie d’accès conditionnel est d’environ 250. Vous pouvez peut-être ajouter jusqu’à 600 applications avant d’obtenir une erreur sur la charge utile dépassée, mais ce nombre n’est pas pris en charge.
Personas d’accès conditionnel
Il existe de nombreuses façons de structurer des stratégies d’accès conditionnel. Une approche consiste à structurer des stratégies en fonction de la sensibilité de la ressource accessible. Dans la pratique, cette approche peut être difficile à implémenter d’une manière qui protège toujours l’accès aux ressources pour différents utilisateurs.
Par exemple, vous pouvez définir une stratégie d’accès conditionnel qui nécessite un utilisateur connu et un appareil connu pour accéder à une ressource sensible qui doit être accessible à la fois par les invités et les employés. Lorsque les invités tentent d’accéder à partir d’un appareil géré, la demande d’accès ne fonctionnera pas. Vous devrez ajuster la stratégie d’accès conditionnel pour répondre aux deux exigences, ce qui entraînerait généralement une stratégie qui répond aux exigences moins sécurisées.
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. Cette approche peut entraîner de nombreuses stratégies d’accès conditionnel et peut être inmanageable.
Une meilleure approche consiste à structurer des stratégies liées aux besoins d’accès courants et à regrouper un ensemble de besoins d’accès dans un personnage pour un groupe d’utilisateurs ayant les mêmes besoins. Les personas sont des types d’identité qui partagent des attributs d’entreprise courants, des responsabilités, des expériences, des objectifs et un accès.
Comprendre comment les ressources et ressources d’entreprise sont accessibles par différents personnages est essentielle au développement d’une stratégie de confiance Zéro complète.
Voici quelques suggestions de personnages d’accès conditionnel de Microsoft :
Microsoft recommande également de définir une personne distincte pour les identités qui ne font pas partie d’un autre groupe de personnes. C’est ce que l’on appelle le personnage global. Global est destiné à appliquer des stratégies pour les identités qui ne se situent pas dans un groupe de personnages et des stratégies qui doivent être appliquées pour tous les personnages.
Les sections suivantes décrivent certaines personnes recommandées.
global
Global est un persona/espace réservé pour les stratégies qui sont générales dans la nature. Il est utilisé pour définir des stratégies qui s’appliquent à tous les personnages ou qui ne s’appliquent pas à une personne spécifique. Utilisez-la pour les stratégies qui ne sont pas couvertes par d’autres personnes. Vous avez besoin de cette personne pour protéger tous les scénarios pertinents.
Par exemple, supposons que vous souhaitez utiliser une 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 qui peuvent être différentes pour différentes personnes.
Autre exemple : vous souhaitez bloquer un compte ou un utilisateur donné à partir d’applications spécifiques, et l’utilisateur ou le compte ne fait partie d’aucun des personnages. Par exemple, si vous créez une identité cloud dans le locataire Microsoft Entra, cette identité ne fait partie d’aucun des autres personnages, car elle n’est affectée à aucun rôle Microsoft Entra. Vous pouvez toujours empêcher l’identité d’accéder aux services Office 365.
Vous souhaiterez peut-être bloquer tous les accès à partir d’identités qui ne sont pas couvertes par un groupe de personnages. Vous pouvez également simplement appliquer l’authentification multifacteur.
Administrateurs
Dans ce contexte, un administrateur est toute identité non invitée, cloud ou synchronisée, qui a un ID Microsoft Entra ou un autre rôle d’administrateur Microsoft 365 (par exemple, dans Microsoft Defender pour Cloud Apps, Exchange, Defender pour point de terminaison ou Gestionnaire de conformité). Étant donné que les invités qui ont ces rôles sont couverts dans une autre personne, les invités sont exclus de cette personne.
Certaines entreprises ont des comptes distincts pour les rôles d’administrateur sensibles dont cette personne est basée. De façon optimale, les administrateurs utilisent ces comptes sensibles à partir d’une station de travail à accès privilégié (PAW). Toutefois, nous voyons souvent que les comptes d’administrateur sont utilisés sur les stations de travail standard, où l’utilisateur bascule simplement entre les comptes sur un seul appareil.
Vous souhaiterez peut-être différencier en fonction de la sensibilité des rôles d’administrateur cloud et attribuer des rôles Azure moins sensibles au personnage Interne plutôt que d’utiliser des comptes distincts. Vous pouvez ensuite utiliser une élévation juste-In-Time (JIT) à la place. Dans ce cas, un utilisateur est ciblé par deux ensembles de stratégies d’accès conditionnel, une pour chaque personne. Si vous utilisez des PW, vous pouvez également introduire des stratégies qui utilisent des filtres d’appareil dans l’accès conditionnel pour restreindre l’accès afin que les administrateurs soient autorisés uniquement sur les PW.
Développeurs
Le personnage des développeurs contient des utilisateurs qui ont des besoins uniques. Ils sont basés sur des comptes Active Directory synchronisés avec l’ID Microsoft Entra, mais ils ont besoin d’un accès spécial aux services tels qu’Azure DevOps, les pipelines CI/CD, le flux de code d’appareil et GitHub. Les développeurs peuvent inclure des utilisateurs qui sont considérés comme internes et d’autres considérés comme externes, mais une personne ne doit être dans qu’un seul des personnages.
internes
Les internes contiennent tous les utilisateurs qui ont un compte Active Directory synchronisé avec l’ID 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 des utilisateurs internes qui sont des développeurs à la personne des développeurs.
externals
Cette personne contient tous les consultants externes qui ont un compte Active Directory synchronisé avec Microsoft Entra ID. Nous vous recommandons d’ajouter des utilisateurs externes qui sont des développeurs à la personne des développeurs.
invités
Les invités contiennent tous les utilisateurs disposant d’un compte invité Microsoft Entra qui a été invité au client.
GuestAdmins
Le persona GuestAdmins contient tous les utilisateurs disposant d’un compte invité Microsoft Entra affecté à l’un des rôles d’administrateur mentionnés précédemment.
Microsoft365ServiceAccounts
Cette personne contient des comptes de service basés sur l’utilisateur (Microsoft Entra ID) cloud utilisés pour accéder aux services Microsoft 365 lorsqu’aucune autre solution ne répond au besoin, comme l’utilisation d’une identité de service managée.
azureServiceAccounts
Cette personne contient des comptes de service basés sur l’utilisateur (Microsoft Entra ID) cloud utilisés pour accéder aux services Azure (IaaS/PaaS) lorsqu’aucune autre solution ne répond au besoin, comme l’utilisation d’une identité de service managée.
CorpServiceAccounts
Ce personnage contient des comptes de service basés sur l’utilisateur qui ont toutes ces caractéristiques :
- Provient d’Active Directory local.
- Sont utilisés à partir d’un ordinateur virtuel local ou d’une machine virtuelle IaaS dans un autre centre de données (cloud), comme Azure.
- Sont synchronisés avec une instance Microsoft Entra qui accède à n’importe quel service Azure ou Microsoft 365.
Ce scénario doit être évité.
WorkloadIdentities
Cette personne contient des identités d’ordinateur, telles que les principaux de service Microsoft Entra et les identités managées. 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 pour chaque personne fournit une entrée pour la création des stratégies d’accès conditionnel spécifiques pour chaque personne.
Conseils sur l’accès conditionnel
Passez en revue une framework d’accès conditionnel qui inclut une approche structurée pour le regroupement de stratégies basées sur les 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 d’identité et d’accès
- Qu’est-ce que l’accès conditionnel ?
- stratégies d’accès conditionnel courantes
Ressources associées
- vue d’ensemble de l’accès conditionnel
- principes de conception et dépendances d’accès conditionnel
- framework et stratégies d’accès conditionnel