Pendant longtemps, l’administration de Microsoft Entra Conditional Access a reposé sur un principe relativement simple : une stratégie correspond à un ensemble de conditions et de contrôles d’accès. Mais à mesure qu’un environnement Microsoft 365 gagne en maturité, cette simplicité apparente peut devenir une difficulté opérationnelle.
Une organisation peut rapidement se retrouver avec plusieurs dizaines de stratégies : MFA pour les administrateurs, MFA pour les utilisateurs, blocage de l’authentification héritée, contrôle des appareils, restrictions géographiques, protection des utilisateurs à risque, protection des connexions à risque ou encore accès aux applications sensibles.
Microsoft expérimente désormais une nouvelle approche dans Microsoft Entra : Conditional Access | Policy plans (Preview). L’objectif semble être de ne plus seulement administrer une succession de stratégies indépendantes, mais de pouvoir les regrouper autour d’une intention de sécurité commune.
Vue d’ensemble de Conditional Access Policy Plans (Preview).
Conditional Access : le moteur de décision de Microsoft Entra
Avant de parler des Policy Plans, rappelons le rôle essentiel de Conditional Access. Ce mécanisme combine différents signaux, notamment l’identité, l’appareil, la localisation, l’application demandée et, lorsque les licences le permettent, le niveau de risque.
À partir de ces informations, Microsoft Entra peut autoriser l’accès, imposer une authentification plus forte, exiger certaines conditions ou bloquer la tentative. Conditional Access constitue ainsi bien davantage qu’un simple mécanisme imposant le MFA : il devient le moteur de décision d’accès de l’environnement Microsoft 365.
Le problème : l’accumulation des stratégies
Lorsque l’on commence à déployer Conditional Access, l’administration reste relativement simple. Mais dans un environnement mature, le nombre de stratégies augmente et leur articulation devient progressivement plus difficile à comprendre.
Le problème n’est donc plus seulement de créer les bonnes stratégies. Il faut également être capable d’en comprendre la finalité, leurs relations, leurs exclusions et les effets produits par plusieurs politiques participant au même objectif de sécurité.
| Stratégie | Objectif |
| CA01 | MFA Administrateurs |
| CA02 | MFA Utilisateurs |
| CA03 | Blocage de l’authentification héritée |
| CA04 | Appareil conforme |
| CA05 | User Risk High |
| CA06 | Applications sensibles |
Qu’est-ce qu’un Conditional Access Policy Plan ?
Les premières observations publiques de la fonctionnalité montrent que Policy Plans permet de regrouper différentes exigences Conditional Access correspondant à une même intention de sécurité.
À l’intérieur d’un Plan, les politiques sont représentées sous forme de Rules. Certaines propriétés communes peuvent également être définies au niveau du Plan et être héritées par les règles qu’il contient.
On passe donc d’une organisation relativement plate à une structure dans laquelle les contrôles sont regroupés par objectif : MFA, protection des appareils, Identity Protection, accès externes ou applications sensibles.
Une approche fondée sur l’intention de sécurité
Dans le modèle traditionnel, l’administrateur raisonne principalement en stratégies : « Quelle policy dois-je créer ? » Avec les Policy Plans, il devient possible de raisonner davantage en objectifs : « Quel risque voulons-nous couvrir ? ».
Prenons l’exemple de la protection des comptes privilégiés. Un même Plan pourrait réunir plusieurs règles relatives au MFA, aux appareils, aux restrictions d’accès et au niveau de risque. La finalité générale devient immédiatement plus lisible pour les équipes sécurité et gouvernance.
Des propriétés communes aux différentes règles
Policy Plans introduit aussi la notion de propriétés partagées ou héritées. Lorsqu’un même périmètre, une même ressource ou une même condition doit être appliqué à plusieurs règles, la configuration commune peut être portée au niveau du Plan.
Cette approche peut réduire les répétitions et rendre plus visible ce qui est commun à l’ensemble des règles. Elle impose toutefois une gouvernance rigoureuse : une propriété modifiée au niveau supérieur peut avoir un effet sur plusieurs règles.
La migration des stratégies existantes
La Preview fait apparaître un mécanisme intitulé « Migrate to Conditional Access Policy plans ». Il vise à sélectionner plusieurs stratégies Conditional Access existantes afin de les intégrer dans un Plan.
Les conditions communes peuvent être remontées dans la partie partagée du Plan, tandis que chaque stratégie sélectionnée devient une règle distincte. Cette logique montre que Microsoft envisage la fonctionnalité pour les tenants déjà équipés d’un patrimoine Conditional Access, et pas uniquement pour les nouvelles configurations.
Quel intérêt pour les grandes organisations ?
L’intérêt devient particulièrement évident lorsque plusieurs équipes participent à la sécurité du tenant : exploitation, identité, sécurité opérationnelle, gouvernance et architecture.
Une organisation peut structurer ses Plans autour de domaines cohérents : protection des administrateurs, protection des identités, protection des appareils, accès externes et applications sensibles. La valeur n’est donc pas uniquement technique. Elle concerne aussi la lisibilité, la délégation et la gouvernance.
Policy Plans ne change pas la philosophie de Conditional Access
Policy Plans ne signifie pas que Microsoft abandonne Conditional Access. Le principe reste identique : analyser des signaux, évaluer des conditions, prendre une décision et appliquer un contrôle d’accès.
La nouveauté réside surtout dans la manière d’organiser plusieurs règles autour d’une intention de sécurité commune. Policy Plans apporte donc une couche de structuration, et non un nouveau moteur d’autorisation indépendant.
Attention : il s’agit encore d’une Preview
L’interface indique explicitement « Policy plans (Preview) ». Le fonctionnement, les interfaces, les autorisations et les modalités de migration peuvent donc encore évoluer.
Pour un environnement Microsoft 365 critique ou institutionnel, la démarche prudente consiste à observer la fonctionnalité, la documenter et la tester en laboratoire. Il serait prématuré de restructurer immédiatement toutes les stratégies de production uniquement pour adopter cette nouvelle présentation.
Une évolution intéressante pour la gouvernance Zero Trust
L’apparition des Policy Plans traduit une évolution importante : les organisations ne doivent plus seulement raisonner en listes de policies, mais en objectifs de sécurité démontrables.
Cette logique est cohérente avec une démarche Zero Trust. Les mécanismes techniques doivent servir une intention clairement définie, compréhensible par les administrateurs comme par les responsables sécurité et audit.
Recommandations pratiques
- Tester la fonctionnalité dans un tenant de laboratoire ou sur un périmètre non critique.
- Exporter et documenter les stratégies existantes avant toute tentative de migration.
- Vérifier les propriétés partagées et les règles héritées afin d’éviter un élargissement involontaire du périmètre.
- Conserver les comptes d’accès d’urgence et les exclusions documentées dans le scénario de test.
- Valider le résultat avec le mode Report-only, l’outil What If et les journaux de connexion avant toute activation.
Avec Conditional Access Policy Plans, Microsoft expérimente une évolution potentiellement importante de l’administration des accès conditionnels. L’enjeu n’est pas simplement de modifier l’interface : il s’agit surtout d’organiser plusieurs règles autour d’une intention de sécurité commune et de rendre l’architecture plus lisible.
Pour les petites infrastructures possédant quelques stratégies, le bénéfice peut sembler limité. Pour les grandes organisations et les environnements réglementés, cette approche pourrait rendre Conditional Access plus structuré, plus facilement gouvernable et plus compréhensible lors des audits.
