Conditional Access Policy Plans : simplifier Entra ID

Avec le temps, l’accès conditionnel a tendance à se multiplier. On commence avec quelques règles de base, puis on en ajoute une par plateforme, une par population, une par scénario, et on arrive vite à plusieurs dizaines de règles. La plupart reprennent pourtant les mêmes ciblages et les mêmes exclusions, notamment les comptes de secours (break-glass).

Pour régler ce problème, Microsoft introduit les Conditional Access Policy Plans dans Microsoft Entra ID. Cette fonctionnalité est actuellement en préversion publique.

Qu’est-ce qu’un Policy Plan ?

Un Policy Plan regroupe plusieurs règles d’accès conditionnel autour d’un même objectif de sécurité : exiger des appareils conformes, protéger les utilisateurs d’un site ou encore sécuriser l’activité des agents IA. Les éléments communs sont définis une seule fois au niveau du plan. Chaque règle se concentre ensuite sur son propre scénario.

Un plan se compose de trois éléments :

• Les détails du plan : nom, description, étiquettes facultatives et propriétaires. Le propriétaire indique qui est responsable du plan, mais ne donne aucune permission sur celui-ci.
• Les conditions partagées : utilisateurs, ressources, conditions et exclusions qui s’appliquent à toutes les règles du plan.
• Les règles : chacune a ses propres conditions et contrôles d’accord ou de session. Un plan doit contenir au moins une règle.

Concrètement, une règle est une stratégie d’accès conditionnel classique qui hérite des conditions partagées de son plan.

Comment fonctionne l’héritage ?

Les conditions du plan s’ajoutent à celles de chaque règle. Une règle peut ajouter ses propres exclusions, mais elle ne peut ni réduire le ciblage du plan, ni supprimer une exclusion définie au niveau du plan. Dans l’éditeur de règle, ces paramètres hérités sont verrouillés.

C’est ce fonctionnement à sens unique qui fait l’intérêt des plans. Si vous ajoutez le groupe des comptes d’accès d’urgence aux exclusions du plan, toutes les règles en bénéficient automatiquement. Aucune règle ne peut l’oublier.

À noter : les options« Tous les utilisateurs » et« Toutes les ressources » peuvent être sélectionnées dans une règle, mais pas au niveau du plan.

Que se passe-t-il au moment de la connexion ?

Le moteur d’application ne change pas. Lors d’une connexion, chaque règle est évaluée séparément et apparaît comme une entrée distincte dans les journaux de connexion.

Les plans ne remplacent pas les stratégies existantes. Les stratégies classiques et les règles des plans sont évaluées ensemble, et toutes celles qui s’appliquent doivent être satisfaites pour que l’accès soit accordé. Les plans changent donc la façon d’organiser les contrôles, pas la façon de les appliquer.

Pourquoi utiliser les Policy Plans ?

1. Réduire le nombre de stratégies

Prenons un cas fréquent : quatre stratégies distinctes pour Windows, macOS, iOS et Android, qui ciblent les mêmes utilisateurs avec les mêmes exclusions. Avec un plan, le ciblage commun est défini une seule fois et chaque plateforme devient une règle.

2. Supprimer les exclusions en double

Les comptes d’urgence, les comptes de service et les postes privilégiés apparaissent dans les exclusions de nombreuses stratégies. Une exclusion oubliée est une cause classique de blocage involontaire. Avec un plan, ces exclusions sont centralisées.

3. Gérer Global Secure Access à grande échelle

Les organisations qui déploient Global Secure Access peuvent avoir besoin de centaines de règles liées au réseau, qui ciblent souvent les mêmes utilisateurs et les mêmes applications. Le plan regroupe ce ciblage commun et chaque règle ne gère que son périmètre réseau.

4. Sécuriser les agents IA

Un plan peut définir une condition commune, comme un risque agent élevé, puis utiliser des règles distinctes pour deux cas : les agents qui agissent au nom d’un utilisateur et les agents autonomes.

Comment créer un Policy Plan ?

Les plans se trouvent dans le centre d’administration Microsoft Entra, sous Entra ID > Conditional Access > Policy plans (Preview).

1. Définir l’objectif de sécurité du plan, par exemple exiger des appareils conformes.
2. Partir d’un modèle (template) ou créer le plan de zéro. Les modèles contiennent déjà des conditions partagées et des règles pour les scénarios courants, y compris la sécurisation des agents.
3. Configurer les conditions partagées : ajoutez seulement ce qui s’applique à tous les scénarios, notamment les exclusions des comptes d’urgence et de service.
4. Ajouter les règles : chaque variante de l’objectif devient une règle avec ses propres contrôles.
5. Tester en mode Report-only, puis activer les règles une fois le comportement validé.

Prérequis : vous devez avoir le rôle Conditional Access Administrator pour créer, modifier ou supprimer un plan.

Bonnes pratiques

• Commencer petit : faites un premier plan sur un périmètre limité avant de réorganiser toutes vos stratégies.
• Mettre les exclusions critiques au niveau du plan : comptes break-glass et comptes de service.
• Toujours passer par le mode Report-only avant l’activation.
• Vérifier les journaux de connexion pour vous assurer que chaque règle s’applique comme prévu.
• Ne pas migrer la production trop tôt : la fonctionnalité est en préversion et n’a peut-être pas encore toutes les capacités de la version finale.

Conclusion

Les Conditional Access Policy Plans ne modifient pas la façon dont l’accès conditionnel est appliqué. Ils permettent en revanche de le structurer, de le gouverner et de le faire évoluer beaucoup plus facilement. En regroupant les règles par objectif de sécurité et en centralisant les exclusions, ils réduisent à la fois la charge d’administration et le risque d’erreur de configuration. C’est particulièrement utile dans les environnements réglementés, où la traçabilité et la cohérence des stratégies de sécurité sont essentielles.

Tags : Microsoft Entra ID, Conditional Access, Accès conditionnel, Policy Plans, Zero Trust, Sécurité Microsoft 365, Global Secure Access, Agent ID, Identité, Gouvernance

Questions Réponses autour des Conditional Access Policy Plans

1. Qu’est-ce qu’un Conditional Access Policy Plan ?

C’est un nouvel objet de l’accès conditionnel qui regroupe plusieurs règles autour d’un même objectif de sécurité, comme exiger des appareils conformes ou sécuriser l’activité des agents IA. Le ciblage commun et les exclusions sont définis une seule fois au niveau du plan. Chaque règle traite ensuite son propre scénario. La fonctionnalité est actuellement en préversion publique.

2. Comment un plan est-il organisé ?

Un plan comporte trois parties :

• Les détails du plan : nom, description, étiquettes et propriétaires. Le propriétaire indique qui est responsable du plan, mais ne donne aucun droit sur celui-ci.
• Les conditions partagées (facultatives) : utilisateurs, ressources et conditions qui s’appliquent à toutes les règles.
• Les règles : chacune a ses propres conditions et ses contrôles d’accord ou de session. Un plan doit contenir au moins une règle.

3. Qu’est-ce qui peut être défini au niveau du plan, et qu’est-ce qui reste dans les règles ?

Certains paramètres ne peuvent pas être partagés :

• « Tous les utilisateurs » et« Toutes les ressources » ne peuvent être sélectionnés que dans une règle.
• Les contrôles d’accord et de session existent uniquement dans les règles.
• Un plan ne peut pas cibler à la fois des utilisateurs et des identités de charge de travail au niveau du plan. Pour couvrir les deux, ces identités doivent être ciblées dans les règles.

4. Comment fonctionne l’héritage entre le plan et ses règles ?

Les conditions du plan s’ajoutent à celles de chaque règle. Une règle hérite du ciblage et des exclusions du plan, et peut ajouter ses propres exclusions. En revanche, elle ne peut ni réduire le ciblage du plan, ni retirer une exclusion définie au niveau du plan. Ces paramètres hérités sont verrouillés dans l’éditeur de règle. C’est ce qui protège les comptes d’urgence : si leur exclusion est ajoutée au plan, aucune règle ne peut l’oublier.

5. Les Policy Plans remplacent-ils les stratégies d’accès conditionnel existantes ?

Non. Les stratégies existantes et les règles des plans sont évaluées ensemble. Pour que l’accès soit accordé, toutes les stratégies et toutes les règles qui s’appliquent doivent être satisfaites. Les plans changent la façon d’organiser les contrôles, pas la façon de les appliquer.

6. Comment cohabitent concrètement les anciennes stratégies et les règles d’un plan lors d’une connexion ?

Lors d’une connexion, chaque règle d’un plan est évaluée séparément, comme une stratégie classique, et apparaît comme une entrée distincte dans les journaux de connexion. Les logiques habituelles restent valables : les contrôles s’additionnent et un blocage l’emporte toujours. Si une stratégie existante et une règle de plan couvrent le même scénario, les deux s’appliquent.

7. Comment migrer des stratégies existantes vers un plan ?

Microsoft fournit un assistant de migration intégré :

1. Connectez-vous au centre d’administration Microsoft Entra avec au minimum le rôle Conditional Access Administrator.
2. Allez dans Entra ID > Conditional Access > Policies.
3. Dans la bannière Migrate to Conditional Access Policy plans (Preview), cliquez sur Get started.
4. Sélectionnez les stratégies à regrouper, puis cliquez sur Merge policies into a plan.

L’outil analyse les stratégies sélectionnées, identifie leurs conditions communes et propose une structure de plan à vérifier avant validation.

8. Que deviennent les stratégies d’origine après la migration ?

Elles ne sont pas modifiées pendant la migration. Elles continuent à être évaluées indépendamment. Pendant la période de transition, une même exigence peut donc être appliquée à la fois par l’ancienne stratégie et par la nouvelle règle.

C’est pourquoi il faut :

• créer ou laisser les règles du plan en Report-only ;
• comparer leurs résultats avec ceux des anciennes stratégies dans les journaux de connexion ;
• activer le plan et désactiver les anciennes stratégies au même moment, pour éviter les doublons comme les trous de couverture.

9. Quelles stratégies faut-il regrouper dans un même plan ?

Microsoft conseille de sélectionner des stratégies qui ont le même objectif, avec trois approches de regroupement :

• Par ressource protégée : des stratégies qui protègent les mêmes applications.
• Par population : des stratégies qui ciblent les mêmes utilisateurs avec des contrôles différents. Le ciblage passe au niveau du plan et chaque contrôle devient une règle.
• Par condition : des stratégies qui partagent déjà une condition, comme un niveau de risque, une plateforme ou un emplacement réseau.

Il est aussi recommandé de migrer progressivement, en commençant par un petit groupe de stratégies bien connues.

10. Quelles précautions prendre avant de migrer en production ?

• Préversion : la fonctionnalité n’a peut-être pas encore toutes les capacités d’une version finale.
• Rôle requis : le rôle Conditional Access Administrator est nécessaire pour créer ou modifier un plan.
• Exclusions critiques : vérifiez que les comptes d’urgence, les comptes de service et les postes privilégiés sont exclus au bon niveau, dans le plan ou dans la règle.
• Sauvegarde : exportez vos stratégies actuelles avant toute réorganisation. Certains experts recommandent aussi de sauvegarder les plans eux-mêmes.
• Validation : passez par le mode Report-only et analysez les journaux de connexion avant toute bascule.

À retenir : la migration vers les Policy Plans ne change pas l’application des règles. Elle permet de les rassembler de manière plus lisible, sans risque pour les stratégies existantes tant que vous n’avez pas basculé.