Infrastructure et stratégies d’accès conditionnel
Cet article propose une structure d’implémentation d’une architecture d’accès conditionnel basée sur des personnages, telle que celle décrite dans Architecture d’accès conditionnel Confiance Zéro. Dans cet article, vous trouverez des détails sur la façon de former et de nommer les stratégies d’accès conditionnel. Il existe également un point de départ pour la création de stratégies.
Si vous n’utilisez pas de framework comme celui fourni ici, y compris une norme de nommage, les stratégies ont tendance à être créées au fil du temps par différentes personnes d’une manière ad hoc. Cela peut entraîner des stratégies qui se chevauchent. Si la personne qui a créé une stratégie n’est plus disponible, il peut être difficile pour d’autres personnes de connaître l’objectif de la stratégie.
Suivre un cadre structuré facilite la compréhension des politiques. Il permet également de couvrir plus facilement tous les scénarios et d’éviter les stratégies en conflit difficiles à résoudre.
Conventions d’affectation de noms
Une convention d’affectation de noms correctement définie vous aide et vos collègues à comprendre l’objectif d’une stratégie, ce qui facilite la gestion et la résolution des problèmes de stratégie. Votre convention d’affectation de noms doit correspondre au framework que vous utilisez pour structurer vos stratégies.
La stratégie de nommage recommandée est basée sur les personnages, les types de stratégie et les applications. Il ressemble à ceci :
<NuméroCA>-<Personnage>-<TypeStratégie>-<Applications>-<Plateforme>-<ContrôleOctroi>-<DescriptionFacultative>
Les composants de ce nom sont décrits ici :
| Composant de noms | Description/exemple |
|---|---|
| Numéro d’autorité de certification | Permet d’identifier rapidement l’étendue et l’ordre du type de stratégie. Exemple : CA001-CA099. |
| Persona | Global, Administrateurs, Internes, Externes, Utilisateurs invités, Administrateurs invités, Comptes de service Microsoft 365, Comptes de service Azure, Comptes de service d’entreprise. |
| Type de stratégie | Protection de base, Protection d'applications, Protection des données, Protection d'identité, Réduction de la surface d'attaque, Conformité. |
| Application | AllApps, O365 (pour tous les services Office 365), EXO (pour Exchange Online). |
| Plateforme | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| Accorder le contrôle | Block, ADHJ, Compliant, Unmanaged (où unmanaged est spécifié dans la condition d’état de l’appareil). |
| Description | Description facultative de l’objectif de la stratégie. |
Schéma de numérotation
Pour faciliter l’administration, nous vous suggérons ce schéma de numérotation :
| Groupe de personnages | Répartition des numéros |
|---|---|
| CA-Personnage-Global | CA001-CA099 |
| CA-Personnage-Administrateurs | CA100-CA199 |
| CA-Personnage-Internes | CA200-CA299 |
| CA-Personnage-Externes | CA300-CA399 |
| CA-Personnage-Utilisateurs invités | CA400-CA499 |
| CA-Personnage-Administrateurs invités | CA500-CA599 |
| CA-Personnage-Comptes de service M365 | CA600-CA699 |
| CA-Personnage-Comptes de service Azure | CA700-CA799 |
| CA-Personnage-Comptes de service d’entreprise | CA800-CA899 |
| CA-Personnage-Identités de charge de travail | CA900-CA999 |
| CA-Personnage-Développeurs | CA1000-CA1099 |
Types de stratégie
Voici les types de stratégie recommandés :
| Type de stratégie | Description/exemples |
|---|---|
| BaseProtection | Pour chaque personne, il existe une protection de base couverte par ce type de stratégie. Pour les utilisateurs sur des appareils gérés, il s’agit généralement d’un utilisateur connu et d’un appareil connu. Pour les invités externes, il peut s’agir d’un utilisateur connu et de l’authentification multifacteur. La protection de base est la stratégie par défaut pour toutes les applications des utilisateurs dans le profil donné. Si une application spécifique doit avoir une stratégie différente, excluez cette application de la stratégie de protection de base et ajoutez une stratégie explicite qui cible uniquement cette application. Exemple : supposons que la protection de base pour les internes consiste à exiger un utilisateur connu et un appareil connu pour toutes les applications cloud, mais que vous souhaitez autoriser Outlook sur le web à partir de n’importe quel appareil. Vous pouvez exclure Exchange Online de la stratégie de protection de base et ajouter une stratégie distincte pour Exchange Online, où vous avez besoin d’une authentification multifacteur ou d’appareil connu. |
| Protection d'Identité | En plus de la protection de base pour chaque personne, vous pouvez avoir des stratégies d’accès conditionnel liées à l’identité. Exemples : Bloquer l’authentification héritée, exiger une authentification multifacteur supplémentaire pour un risque élevé d’utilisateur ou de connexion, exiger un appareil connu pour l’inscription à l’authentification multifacteur. |
| Protection des Données | Ce type de stratégie indique les stratégies delta qui protègent les données en tant que couche supplémentaire au-dessus de la protection de base. Exemples:
|
| AppProtection | Ce type de stratégie est un autre ajout à la protection de base. Exemples:
|
| AttackSurfaceReduction | L’objectif de ce type de stratégie est d’atténuer diverses attaques. Exemples:
|
| Conformité | Vous pouvez utiliser une stratégie de conformité pour exiger qu’un utilisateur affiche les conditions d’utilisation des invités qui accèdent aux services client. |
Application
Le tableau suivant décrit le composant Application d’un nom de stratégie :
| Nom de l’application | Description/exemples |
|---|---|
| AllApps | AllApps indique que toutes les applications cloud sont ciblées dans la stratégie d’accès conditionnel. Tous les points de terminaison sont couverts, y compris ceux qui prennent en charge l’accès conditionnel et ceux qui ne le font pas. Dans certains scénarios, le ciblage de toutes les applications ne fonctionne pas correctement. Nous vous recommandons de cibler toutes les applications dans la stratégie de base afin que tous les points de terminaison soient couverts par cette stratégie. Les nouvelles applications qui apparaissent dans l’ID Microsoft Entra adhèrent également automatiquement à la stratégie. |
| <AppName> | <AppName> est un espace réservé pour le nom d’une application que la stratégie adresse. Évitez d’utiliser un nom trop long. Exemples de noms :
|
Type de plateforme
Le tableau suivant décrit le composant Plateforme d’un nom de stratégie :
| Type de plateforme | Description |
|---|---|
| AnyPlatform | La stratégie cible n’importe quelle plateforme. Vous configurez généralement cela en sélectionnant Tout appareil. (Dans les stratégies d’accès conditionnel, le mot plateforme et le mot appareil sont utilisés.) |
| Ios | La stratégie cible les plateformes iOS Apple. |
| Android | La stratégie cible les plateformes Google Android. |
| Windows | Cette stratégie cible la plateforme Windows. |
| Linux | Cette stratégie cible les plateformes Linux. |
| WindowsPhone | La stratégie cible les plateformes Windows Phone. |
| macOS | La stratégie cible les plateformes macOS |
| iOSAndroid | La stratégie cible à la fois les plateformes iOS et Android. |
| Inconnu | La stratégie cible n’importe quelle plateforme non répertoriée précédemment. Pour la configurer, vous incluez généralement N’importe quel périphérique et excluez toutes les plateformes individuelles. |
Accorder des types de contrôle
Le tableau suivant décrit le composant Grant Control d’un nom de stratégie :
| Type d’octroi | Description/exemples |
|---|---|
| Bloquer | La politique bloque la connexion |
| MFA | La stratégie nécessite une authentification multifacteur. |
| Conforme | La stratégie nécessite un appareil conforme, tel que déterminé par Endpoint Manager, de sorte que l’appareil doit être géré par Endpoint Manager. |
| CompliantorAADHJ | La stratégie impose un appareil conforme OU un appareil à jonction Microsoft Entra hybride. Un ordinateur d’entreprise standard joint à un domaine est également à jonction Microsoft Entra ID hybride. Les téléphones mobiles et les ordinateurs Windows 10 qui sont cogérés ou joints à Microsoft Entra peuvent être conformes. |
| CompliantandAADHJ | La stratégie impose un appareil conforme ET à jonction Microsoft Entra hybride. |
| MFAorCompliant | La politique nécessite soit un appareil conforme, soit une authentification multifacteur si l'appareil n'est pas conforme. |
| MFAandCompliant | La politique exige un appareil conforme ET une authentification multifacteur. |
| MFAorAADHJ | La stratégie nécessite un ordinateur joint à Microsoft Entra hybride OU une authentification multifacteur s'il ne s'agit pas d'un ordinateur joint à Microsoft Entra hybride. |
| MFAandAADHJ | La stratégie nécessite un ordinateur joint de manière hybride à Microsoft Entra ET une authentification multifacteur. |
| RequireApprovedClient | La stratégie nécessite une application cliente approuvée. |
| AppProtection | La stratégie nécessite une protection des applications |
| Non géré | La stratégie cible les appareils qui ne sont pas connus par l’ID Microsoft Entra. Par exemple, vous pouvez utiliser ce type d’octroi pour autoriser l’accès à Exchange Online à partir de n’importe quel appareil. |
Emplacements nommés
Nous vous recommandons de définir ces emplacements standard à utiliser dans les stratégies d’accès conditionnel :
- Adresses IP approuvées / Réseaux internes. Ces sous-réseaux IP représentent des emplacements et des réseaux qui ont des restrictions d’accès physique ou d’autres contrôles en place, tels que la gestion du système informatique, l’authentification au niveau du réseau ou la détection des intrusions. Ces emplacements sont plus sécurisés, de sorte que l’application de l’accès conditionnel peut être assouplie. Déterminez si Azure ou d’autres emplacements de centre de données (IP) doivent être inclus dans cet emplacement ou avoir leurs propres emplacements nommés.
- Adresses IP approuvées par Citrix. Si vous disposez de Citrix en local, il peut être utile de configurer des adresses IPv4 sortantes distinctes pour les batteries de serveurs Citrix, si vous devez être en mesure de vous connecter aux services cloud à partir de sessions Citrix. Dans ce cas, vous pouvez exclure ces emplacements des stratégies d’accès conditionnel si nécessaire.
- Emplacements Zscaler, le cas échéant. Les ordinateurs disposent d’un agent ZPA installé et transfèrent tout le trafic vers Internet vers ou via le cloud Zscaler. Il vaut donc la peine de définir des adresses IP sources Zscaler dans l’accès conditionnel et d’exiger que toutes les demandes d’appareils non mobiles passent par Zscaler.
- Pays/régions avec lesquels autoriser les entreprises. Il peut être utile de diviser les pays/régions en deux groupes d’emplacements : l’un qui représente des régions du monde où les employés travaillent généralement et l’un qui représente d’autres emplacements. Cela vous permet d’appliquer des contrôles supplémentaires aux demandes provenant de l’extérieur des zones où votre organisation fonctionne normalement.
- Emplacements où l’authentification multifacteur peut être difficile ou impossible. Dans certains scénarios, la nécessité d’une authentification multifacteur peut rendre difficile pour les employés de faire leur travail. Par exemple, le personnel n’a peut-être pas le temps ou la possibilité de répondre aux défis fréquents liés à l’authentification multifacteur. Ou, dans certains endroits, le filtrage RF ou l’interférence électrique peuvent rendre l’utilisation des appareils mobiles difficiles. En règle générale, vous utiliseriez d'autres contrôles à ces emplacements, ou ils pourraient être considérés comme fiables.
Les contrôles d’accès basés sur l’emplacement s’appuient sur l’adresse IP source d’une requête pour déterminer l’emplacement de l’utilisateur au moment de la requête. Il n'est pas facile de réaliser une usurpation d'identité sur Internet public, mais les mesures de protection offertes par les frontières du réseau peuvent être considérées comme moins pertinentes qu'auparavant. Nous vous déconseillons de nous appuyer uniquement sur l’emplacement en tant que condition d’accès. Toutefois, pour certains scénarios, il peut s’agir du meilleur contrôle que vous pouvez utiliser, comme si vous sécurisez l’accès à partir d’un compte de service local utilisé dans un scénario non interactif.
Stratégies d’accès conditionnel recommandées
Nous avons créé une feuille de calcul qui contient des stratégies d’accès conditionnel recommandées. Vous pouvez télécharger cette feuille de calcul ici.
Utilisez les stratégies suggérées comme point de départ.
Vos stratégies changeront probablement au fil du temps pour prendre en charge les cas d’usage importants pour votre entreprise. Voici quelques exemples de scénarios susceptibles de nécessiter des modifications :
- Implémentez l’accès en lecture seule à Exchange Online pour les employés utilisant n’importe quel appareil non géré en fonction de l’authentification multifacteur, de la protection des applications et d’une application cliente approuvée.
- Implémentez la protection des informations pour vous assurer que les informations sensibles ne sont pas téléchargées sans amélioration de la protection fournie par Azure Information Protection.
- Fournissez une protection contre la copie et le collage par les invités.
Plusieurs aperçus sont actuellement en préversion publique, donc attendez-vous à ce que les mises à jour de l’ensemble suggéré de stratégies initiales d’accès conditionnel (CA) soient bientôt disponibles.
Conseils sur l’accès conditionnel
Maintenant que vous disposez d’un ensemble de stratégies d’accès conditionnel, vous devez les déployer de manière contrôlée et progressive. Nous vous suggérons d’utiliser un modèle de déploiement.
Voici une approche :
L’idée est de déployer d’abord des stratégies sur un petit nombre d’utilisateurs au sein d’un groupe de personnes. Vous pouvez utiliser un groupe Microsoft Entra associé appelé Persona Ring 0 pour ce déploiement. Après avoir vérifié que tout fonctionne, vous modifiez l’affectation en groupe, Persona Ring 1, qui a plus de membres, etc.
Vous activez ensuite les stratégies à l’aide de la même approche en anneau jusqu’à ce que toutes les stratégies soient déployées.
En général, vous gérez les membres de l'anneau 0 et de l'anneau 1 manuellement. Un groupe Ring 2 ou 3 qui contient des centaines voire des milliers d’utilisateurs peut être géré via un groupe dynamique qui est basé sur un pourcentage des utilisateurs contenus dans un personnage donné.
L’utilisation des anneaux dans le cadre d’un modèle de déploiement n’est pas seulement destinée au déploiement initial. Vous pouvez également l’utiliser lorsque de nouvelles stratégies ou des modifications apportées aux stratégies existantes sont requises.
Avec un déploiement terminé, vous devez également concevoir et implémenter les contrôles de surveillance abordés dans les principes d’accès conditionnel .
En plus d’automatiser le déploiement initial, vous pouvez automatiser les modifications apportées aux stratégies à l’aide de pipelines CI/CD. Vous pouvez utiliser Microsoft365DSC pour cette automatisation.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Claus Jespersen | Consultant principal 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
- stratégies d’accès conditionnel
Ressources associées
- vue d’ensemble de l’accès conditionnel
- Principes de conception et dépendances de l’accès conditionnel
- conception d’accès conditionnel basée sur la confiance zéro et les personnages