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 informations sur la manière de former et de nommer les stratégies d’accès conditionnel. Vous y trouverez également le point de départ pour créer des stratégies.
Si vous n’utilisez pas de structure comme celle proposée ici, avec notamment un standard de nommage, les stratégies tendent à être créées au fil du temps par différentes personnes de façon ponctuelle. Le risque est que les stratégies se chevauchent. Si la personne qui a créé une stratégie n’est plus dans l’entreprise, il pourra être difficile de connaître la but de la stratégie.
En suivant une structure bien définie, il sera plus facile de comprendre les stratégies. De même, il sera plus facile de couvrir tous les scénarios et d’éviter des conflits difficiles à résoudre entre les stratégies.
Conventions de nommage
Une convention de nommage bien définie vous aide à vous et à vos collègues à mieux comprendre le but d’une stratégie, ce qui facilite la gestion des stratégies et la résolution des problèmes afférents. Votre convention de nommage doit être adaptée à la structure que vous utilisez pour définir vos stratégies.
La stratégie de nommage recommandée dépend des personnages, des types de stratégies et des applications. Elle se présente comme suit :
<NuméroCA>-<Personnage>-<TypeStratégie>-<Application>-<Plateforme>-<ContrôleOctroi>-<DescriptionFacultative>
Les composants de ce nom sont décrits ici :
| Composant de noms | Description/exemple |
|---|---|
| Numéro d’autorité de certification (CA) | Permet d’identifier rapidement l’étendue et l’ordre des types de stratégies. Exemple : CA001-CA099. |
| Personnage | 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 | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| Application | AllApps, O365 (pour tous les services Office 365), EXO (pour Exchange Online). |
| Plateforme | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| Contrôle d’octroi | Block, ADHJ, Compliant, Unmanaged (où unmanaged est spécifié dans la condition d’état de l’appareil). |
| Description | Description facultative du but 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 | Allocation de nombres |
|---|---|
| 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
Les types de stratégie recommandés sont les suivants :
| Type de stratégie | Description/exemples |
|---|---|
| Protection de base | Pour chaque personnage, il existe une protection de base qui est couverte par ce type de stratégie. Pour les utilisateurs d’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 qui s’applique à toutes les applications pour les utilisateurs du personnage 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 : supposez que la protection de base pour le personnage Internes impose 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 pourriez exclure Exchange Online de la stratégie de protection de base et ajouter une stratégie distincte pour Exchange Online dans laquelle vous imposeriez un appareil connu OU l’authentification multifacteur. |
| IdentityProtection | En plus de la protection de base de chaque personnage, vous pouvez utiliser des stratégies d’accès conditionnel en rapport avec l’identité. Exemples : bloquer l’authentification héritée, exiger l’authentification multifacteur en supplément pour un utilisateur ou une connexion à haut risque, imposer un appareil connu pour l’inscription de l’authentification multifacteur. |
| DataProtection | Ce type de stratégie indique des stratégies delta qui protègent les données avec une couche supplémentaire, en plus de la protection de base. Exemples :
|
| AppProtection | Ce type de stratégie est une autre adjonction à la protection de base. Exemples :
|
| AttackSurfaceReduction | L’objectif de ce type de stratégie est d’atténuer les risques de diverses attaques. Exemples :
|
| Conformité | Vous pouvez utiliser une stratégie de conformité pour demander à un utilisateur d’afficher les conditions d’utilisation pour les invités qui accèdent aux services du client. |
Application
Le tableau suivant décrit la composante 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, qu’ils prennent en charge ou non l’accès conditionnel. 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 Microsoft Entra ID adhèrent aussi automatiquement à la stratégie. |
| <AppName> | <AppName > est un espace réservé pour le nom de l’application à laquelle s’adresse la stratégie. Évitez d’utiliser un nom trop long. Exemples de noms :
|
Type de plateforme
Le tableau suivant décrit la composante Plateforme d’un nom de stratégie :
| Type de plateforme | Description |
|---|---|
| AnyPlatform | La stratégie cible n’importe quelle plateforme. Pour la configurer, vous sélectionnez généralement N’importe quel périphérique. (Dans les stratégies d’accès conditionnel, le terme plateforme et le terme appareil sont tous deux utilisés.) |
| iOS | La stratégie cible les plateformes Apple iOS. |
| 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 les plateformes iOS et Android. |
| Unknown | La stratégie cible les plateformes non listées précédemment. Pour la configurer, vous incluez généralement N’importe quel périphérique et excluez toutes les plateformes individuelles. |
Type de contrôle d’octroi
Le tableau suivant décrit la composante Contrôle d’octroi d’un nom de stratégie :
| Type d’autorisation | Description/exemples |
|---|---|
| Bloquer | La stratégie bloque la connexion |
| MFA | La stratégie impose l’authentification multifacteur. |
| Conforme | La stratégie impose un appareil conforme, tel que défini par Endpoint Manager, si bien que l’appareil doit être géré par Endpoint Manager. |
| CompliantorAADHJ | La stratégie impose un appareil conforme OU un appareil avec jonction hybride à Microsoft Entra. Un ordinateur d’entreprise standard joint à un domaine dispose également d’une jonction hybride à Microsoft Entra ID. Les téléphones mobiles et les ordinateurs Windows 10 cogérés ou joints à Microsoft Entra peuvent être conformes. |
| CompliantandAADHJ | La stratégie impose un appareil conforme ET avec jonction hybride à Microsoft Entra. |
| MFAorCompliant | La stratégie impose un appareil conforme OU l’authentification multifacteur s’il n’est pas conforme. |
| MFAandCompliant | La stratégie impose un appareil conforme ET l’authentification multifacteur. |
| MFAorAADHJ | La stratégie nécessite un ordinateur avec jonction hybride à Microsoft Entra OU l’authentification multifacteur dans le cas contraire. |
| MFAandAADHJ | La stratégie impose un ordinateur avec jonction hybride à Microsoft Entra ET l’authentification multifacteur. |
| RequireApprovedClient | La stratégie demande une application cliente approuvée. |
| AppProtection | La stratégie demande une protection de l’application |
| Non géré | La stratégie cible les appareils qui ne sont pas connus de Microsoft Entra ID. 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 pour une utilisation 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 étant plus sécurisés, la mise en œuvre 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 à cet emplacement ou s’ils doivent disposer de leurs propres emplacements nommés.
- Adresses IP approuvées par Citrix. Si vous avez Citrix en local, il peut être utile de configurer des adresses IPv4 sortantes distinctes pour les batteries Citrix si vous avez besoin de pouvoir 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 et transfèrent l’ensemble du trafic vers Internet ou via le cloud Zscaler. Il est donc utile de définir des adresses IP sources Zscaler dans l’accès conditionnel et de faire en sorte que toutes les demandes émises par les appareils non mobiles passent par Zscaler.
- Pays/régions avec lesquels autoriser les affaires. Il peut être utile de diviser les pays/régions en deux groupes distincts : un qui représente les régions du monde où les employés travaillent généralement et un autre qui représente les autres lieux. Cela vous permet d’appliquer des contrôles supplémentaires aux demandes qui viennent de l’extérieur des régions où votre organisation exerce normalement ses activités.
- Lieux où l’authentification multifacteur peut être difficile voire impossible. Dans certains scénarios, le fait d’imposer l’authentification multifacteur peut compliquer la tâche des employés. Par exemple, il peut arriver que le personnel n’ait ni le temps ni la possibilité de répondre aux tests fréquents de l’authentification multifacteur. Ou bien, dans certains lieux, l’analyse RF ou les interférences électriques peuvent rendre difficile l’utilisation d’appareils mobiles. En règle générale, d’autres contrôles sont utilisés dans ces lieux ou ils sont peut-être approuvés.
Les contrôles d’accès basés sur l’emplacement se fient à l’adresse IP source d’une demande pour déterminer l’emplacement de l’utilisateur au moment de la demande. Même s’il n’est pas facile d’effectuer une usurpation d’identité sur l’Internet public, la protection offerte par les limites du réseau peut être considérée comme moins pertinente qu’autrefois. Nous vous déconseillons de vous fier uniquement à l’emplacement comme condition d’accès. Mais pour certains scénarios, il peut s’agir du meilleur contrôle que vous puissiez utiliser, par exemple si vous sécurisez l’accès à partir d’un compte de service utilisé en local dans un scénario non interactif.
Stratégies d’accès conditionnel recommandées
Nous avons créé une feuille de calcul qui contient les 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 compte les cas d’utilisation importants pour votre entreprise. Voici quelques exemples de scénarios qui peuvent rendre des modifications nécessaires :
- Implémentation d’un accès en lecture seule à Exchange Online pour les employés utilisant un appareil non géré basé sur l’authentification multifacteur, la protection d’applications et une application cliente approuvée.
- Implémentation de la protection des informations pour éviter le téléchargement d’informations sensibles sans une protection améliorée fournie par Azure Information Protection.
- Mise en place d’une protection contre la copie et le collage par les invités.
Plusieurs préversions passent actuellement en préversion publique. Attendez-vous donc bientôt à des mises à jour de l’ensemble suggéré de stratégies de démarrage d’accès conditionnel.
Conseils relatifs à l’accès conditionnel
Maintenant que vous disposez de l’ensemble des stratégies d’accès conditionnel pour démarrer, vous devez les déployer de façon 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 commencer par déployer les stratégies pour un petit nombre d’utilisateurs au sein d’un même groupe de personnages. Vous pouvez utiliser un groupe Microsoft Entra associé nommé Persona Ring 0 pour ce déploiement. Après avoir vérifié que tout fonctionne, vous modifiez l’attribution à un groupe, Persona Ring 1, qui compte davantage de membres, et ainsi de suite.
Vous activez ensuite les stratégies en suivant la même approche de boucle (« ring ») jusqu’à ce que toutes les stratégies soient déployées.
En général, vous gérez les membres de Ring 0 et Ring 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 de boucles dans le cadre d’un modèle de déploiement ne se limite pas au déploiement initial. Vous pouvez aussi en utiliser lorsque de nouvelles stratégies sont nécessaires ou que des modifications doivent être apportées aux stratégies existantes.
Une fois le déploiement terminé, vous devez aussi concevoir et implémenter les contrôles de supervision qui ont été abordés dans les principes de l’accès conditionnel.
Outre l’automatisation du déploiement initial, vous pouvez aussi automatiser les modifications au niveau des stratégies à l’aide de pipelines CI/CD. Vous pouvez à cet effet utiliser Microsoft365DSC.
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
- Stratégies d’accès conditionnel
Ressources associées
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour