Lacunes de Couverture Accès Conditionnel dans Entra ID

Les lacunes de couverture politique de base accès conditionnel Entra ID que portent les tenants sont la forme la plus élémentaire d'échec de l'Accès Conditionnel qui soit : non pas une politique mal configurée, non pas une exclusion trop large, mais aucune politique du tout couvrant les rôles admin, tous les utilisateurs, toutes les applications cloud ou la conformité des appareils. Un tenant peut avoir une douzaine de politiques d'Accès Conditionnel dans le centre d'administration — blocages de l'authentification héritée, règles de connexion basées sur le risque, exceptions spécifiques aux applications — et n'avoir malgré tout aucune couverture sur l'une ou l'autre de ces quatre bases. Failles d'Accès Conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition couvre la dérive de périmètre, les exclusions et l'authentification héritée à l'intérieur des politiques existantes. Cet article porte sur la question qui précède tout cela : une politique de base existe-t-elle seulement ?

Lacunes de Couverture Politique de Base Accès Conditionnel Entra ID : Les Quatre Angles Morts

Les recommandations de déploiement de l'Accès Conditionnel de Microsoft sont explicites : un tenant devrait pouvoir s'appuyer sur un petit ensemble de politiques de base qui s'appliquent largement, et non sur un empilement d'exceptions étroites. Comme le formule Microsoft dans son guide de planification de déploiement, les organisations devraient créer une politique qui cible tous les utilisateurs, toutes les ressources sans exclusion d'application, et qui exige l'authentification multifacteur — car cela « garantit de ne pas avoir à mettre à jour les politiques d'Accès Conditionnel à chaque intégration d'une nouvelle application ». Un tenant auquel il manque l'une des quatre lacunes ci-dessous n'a pas atteint cette base, quel que soit le nombre d'autres politiques qu'il a configurées.

Aucune politique ciblant les rôles admin (CA_NO_POLICY_ADMINS)

La politique d'Accès Conditionnel courante de Microsoft pour les administrateurs recommande d'exiger une MFA résistante au phishing sur au moins quatorze rôles hautement privilégiés au minimum : Administrateur Général, Administrateur de Rôle Privilégié, Administrateur de la Sécurité, Administrateur de l'Accès Conditionnel, Administrateur des Utilisateurs, et d'autres ayant un impact à l'échelle du tenant. Sans une politique ciblant spécifiquement ces rôles d'annuaire — plutôt que de s'appuyer sur une politique MFA générique pour tous les utilisateurs qui pourrait être exclue ou sous-dimensionnée pour les connexions admin — un identifiant administrateur compromis ne rencontre absolument aucun contrôle d'accès supplémentaire.

Aucune politique ciblant tous les utilisateurs (CA_NO_POLICY_ALL_USERS)

Une politique qui cible des groupes ou des applications spécifiques n'équivaut pas à une politique qui cible Tous les utilisateurs. La documentation Microsoft sur l'affectation des utilisateurs en Accès Conditionnel précise que Tous les utilisateurs dans une affectation d'Accès Conditionnel inclut les invités B2B aussi bien que les membres — c'est précisément là le problème : une couverture utilisateur partielle, construite groupe par groupe, tend à oublier le type de compte que personne n'a pensé à ajouter (voir Comptes Invités Azure : Risques du Tenant sur ce point spécifique). Un tenant avec une MFA solide sur son équipe marketing et rien sur les prestataires ou le personnel récemment intégré présente cette lacune, même si la liste des politiques paraît complète.

Aucune couverture de toutes les applications cloud (CA_NO_ALL_APPS_COVERAGE)

Le guide de déploiement de l'Accès Conditionnel de Microsoft indique clairement que « d'un point de vue sécurité, il est préférable de créer une politique qui inclut Toutes les ressources (anciennement « toutes les applications cloud ») » précisément parce qu'un périmétrage application par application signifie que chaque nouvelle application SaaS intégrée démarre non protégée jusqu'à ce que quelqu'un pense à l'ajouter à une politique. Un tenant qui n'a rédigé une politique d'Accès Conditionnel que pour Exchange Online et le portail Azure a laissé toutes les autres ressources — y compris les applications OAuth tierces et Microsoft Graph — en dehors de toute évaluation d'Accès Conditionnel, puisque les connexions vers des ressources non ciblées ne sont régies par rien.

Aucune exigence de conformité des appareils (CA_NO_DEVICE_COMPLIANCE)

Microsoft documente une politique d'Accès Conditionnel qui exige que les appareils accédant aux ressources soient marqués conformes aux politiques de conformité Intune de l'organisation, ou joints en hybride à Microsoft Entra. Sans cela, des connexions ayant satisfait la MFA depuis des appareils non gérés, non corrigés ou personnels atteignent les mêmes ressources que des connexions depuis un poste professionnel durci et vérifié conforme — la MFA prouve qui se connecte, pas que l'appareil utilisé est sûr pour faire confiance à la session.

⚠️

⚠️ Avertissement : Ces quatre lacunes sont indépendantes les unes des autres. Un tenant peut exiger la MFA pour tous les utilisateurs et n'avoir malgré tout aucune politique spécifique aux admins, ou couvrir chaque application cloud pour la MFA tout en n'exigeant nulle part la conformité des appareils. Chacune doit être vérifiée séparément — en valider une n'implique pas que les autres soient couvertes.

Pourquoi « Nous Avons l'Accès Conditionnel » Ne Signifie Pas Que la Couverture de Base Existe

Deux éléments donnent régulièrement aux tenants une fausse confiance que ces quatre lacunes de base sont comblées alors qu'elles ne le sont pas.

Security Defaults n'est pas un substitut, et disparaît dès qu'une politique personnalisée est créée. Microsoft active automatiquement Security Defaults pour les nouveaux tenants afin de fournir une base MFA minimale, mais Security Defaults et les politiques d'Accès Conditionnel sont mutuellement exclusifs — ils ne peuvent pas être activés en même temps. Le piège : un administrateur qui crée une seule politique d'Accès Conditionnel étroite (par exemple, bloquer l'authentification héritée pour un seul département) désactive silencieusement Security Defaults à l'échelle du tenant dans le même mouvement, alors même que cette politique unique ne couvre en rien les rôles admin, tous les utilisateurs, toutes les applications ou la conformité des appareils. Le tenant se retrouve avec moins de protection de base qu'auparavant, tandis que le centre d'administration continue d'afficher « Accès Conditionnel : configuré ». Durcissement du Tenant Azure : Corriger les Configs à Risque couvre ce piège et d'autres pièges de paramètres par défaut dans les nouveaux tenants.

Les politiques gérées par Microsoft couvrent un périmètre plus étroit que ce que « base » laisse entendre, et démarrent en mode rapport seul. Depuis fin 2023, Microsoft déploie automatiquement un ensemble de politiques d'Accès Conditionnel gérées par Microsoft vers les tenants éligibles, y compris des exigences MFA pour les admins et pour tous les utilisateurs. C'est une amélioration réelle, mais deux limites comptent pour cet article : premièrement, la politique gérée axée sur les admins cible spécifiquement les connexions vers les portails d'administration Microsoft (portail Azure, centre d'administration Microsoft 365, centre d'administration Entra, et similaires), et non les connexions de rôles admin vers des applications métier arbitraires ; deuxièmement, Microsoft crée ces politiques en mode rapport seul par défaut, ce qui évalue mais n'applique pas. Un tenant qui s'appuie sur la politique gérée sans jamais vérifier si elle est sortie du mode rapport seul a la même exposition pratique que s'il n'avait aucune politique — un mode de défaillance distinct mais adjacent à la dérive en mode rapport seul couverte dans Failles d'Accès Conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition.

Détection

Détecter les lacunes de couverture de base signifie recenser ce qui existe réellement dans l'ensemble des politiques d'Accès Conditionnel du tenant — pas ce que le tenant avait l'intention de configurer.

Signal	Où vérifier	Ce que cela révèle
Périmètre `conditions.users` de la politique sur l'ensemble des politiques	Microsoft Graph `GET /identity/conditionalAccess/policies`, ou `Get-MgIdentityConditionalAccessPolicy` (`Policy.Read.All`)	Si une politique activée inclut `All` (tous) utilisateurs/rôles plutôt que seulement des groupes spécifiques — la vérification directe pour `CA_NO_POLICY_ALL_USERS` et `CA_NO_POLICY_ADMINS`
`conditions.users.includeRoles` de la politique renseigné avec les ID des rôles d'annuaire admin	Même requête Graph, filtrée sur l'état activé	Confirme qu'une politique cible spécifiquement les rôles d'annuaire privilégiés, et non simplement une règle MFA générique pour tous les utilisateurs qui pourrait être exclue pour les admins
Valeur `conditions.applications.includeApplications` de la politique	Même requête Graph	`All` signifie que la couverture Toutes les ressources/Toutes les applications cloud existe ; toute autre valeur signifie que la politique est limitée à des applications spécifiques et que chaque application non listée est non protégée
`grantControls` de la politique contenant `compliantDevice` ou `domainJoinedDevice`	Même requête Graph	Confirme si une politique appliquée exige réellement la conformité des appareils ou la jonction hybride, par opposition à la seule MFA
Valeur `state` de la politique (`enabled` vs `enabledForReportingButNotEnforced`)	Même requête Graph, ou l'onglet Rapport seul dans le centre d'administration	Distingue une politique appliquée d'une politique gérée par Microsoft ou personnalisée encore en mode rapport seul — une politique en mode rapport seul ne comble pas la lacune
Classeur d'analyse des lacunes d'Accès Conditionnel	Centre d'administration Entra → Surveillance et intégrité → Classeurs → section Accès Conditionnel (nécessite Lecteur de rapports et un espace de travail Log Analytics)	Conçu spécifiquement pour révéler les utilisateurs, applications et emplacements nommés sans aucune politique d'Accès Conditionnel appliquée, à partir de preuves de connexion réelles plutôt que du texte des politiques
Champ `conditionalAccessStatus` sur les entrées des journaux de connexion	Journaux de connexion du centre d'administration Entra, ou `GET /auditLogs/signIns`	`notApplied` sur une connexion d'un rôle admin, d'un utilisateur standard ou d'un appareil non géré est la confirmation en conditions réelles que la lacune de base correspondante est réelle, et non théorique

💡

💡 Astuce : Revue des politiques avant revue des connexions. Un classeur d'analyse des lacunes ou une requête sur les journaux de connexion ne montre de preuves que pour les identités et applications s'étant effectivement connectées durant la fenêtre d'observation. Recenser d'abord l'ensemble des politiques via Graph indique de manière définitive si les quatre politiques de base existent, indépendamment du fait que quelqu'un ait déclenché ou non la lacune ce jour-là.

Remédiation : corriger les lacunes de couverture

Déployez d'abord une politique MFA dédiée aux rôles admin. Ciblez l'ensemble documenté des rôles hautement privilégiés (Administrateur Général, Administrateur de Rôle Privilégié, Administrateur de la Sécurité, Administrateur de l'Accès Conditionnel, et le reste de la liste des rôles admin de la politique courante Microsoft), exigez la MFA ou une force d'authentification supérieure, et n'excluez que les comptes break-glass — voir Comptes d'Accès d'Urgence Break Glass Entra ID avant de créer cette exclusion.
Déployez une politique de base pour tous les utilisateurs, ciblant Tous les utilisateurs et Toutes les ressources. Évitez un périmétrage application par application ou groupe par groupe pour la couche de base ; ajoutez des politiques plus étroites et plus fortes par-dessus pour des applications spécifiques à forte valeur plutôt que d'essayer d'énumérer chaque application ayant besoin de la base.
Ajoutez une exigence de conformité des appareils ou de jonction hybride pour, au minimum, le même ensemble de rôles admin et de ressources sensibles couvert ci-dessus, en utilisant les politiques de conformité Intune comme source d'application.
Vérifiez si des politiques gérées par Microsoft existent et si elles sont encore en mode rapport seul. Si c'est le cas, soit faites-les passer en mode appliqué après une fenêtre de revue validée, soit remplacez-les par des politiques détenues par le tenant qui couvrent le périmètre plus large décrit dans cet article, plutôt que les seuls portails d'administration Microsoft.
Si Security Defaults a été désactivé silencieusement par une politique étroite antérieure, ne le réactivez pas simplement — remplacez-le par les politiques de base explicites ci-dessus ; Security Defaults et l'Accès Conditionnel personnalisé restent mutuellement exclusifs, et le réactiver supprimerait la politique plus étroite qui avait motivé la question au départ.
Validez avec l'outil What If et le classeur d'analyse des lacunes pour un compte admin représentatif, un utilisateur standard représentatif et un appareil non géré représentatif avant de considérer la lacune comme comblée — la configuration de la politique et son application confirmée ne sont pas la même preuve.

Comment EtcSec Détecte Cela

Les contrôles Azure/Entra d'EtcSec correspondent directement aux quatre lacunes de cet article : CA_NO_POLICY_ADMINS et CA_NO_POLICY_ALL_USERS signalent l'absence de toute politique activée ciblant respectivement les rôles admin ou tous les utilisateurs, CA_NO_ALL_APPS_COVERAGE signale l'absence d'une politique couvrant toutes les applications cloud/ressources, et CA_NO_DEVICE_COMPLIANCE signale l'absence de tout contrôle d'octroi de conformité des appareils. AZ_SECURITY_DEFAULTS_NO_CA détecte le piège spécifique décrit ci-dessus : Security Defaults désactivé sans base d'Accès Conditionnel compensatoire en place.

ℹ️

ℹ️ Note : EtcSec vérifie automatiquement cette vulnérabilité lors de chaque audit AD/Azure. Lancez un audit gratuit pour vérifier votre environnement.

Lacunes de Couverture Politique de Base Accès Conditionnel Entra ID : Aucune Politique pour les Admins, Tous les Utilisateurs ou Toutes les Applications