Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition

Failles acces conditionnel Entra ID : c'est le nom le plus direct pour decrire l'ecart entre des policies qui paraissent larges dans l'admin center et des controles qui evaluent vraiment les users, guests, apps, protocols et workload identities qui comptent en production. Un tenant peut afficher une couverture Conditional Access qui semble propre tout en laissant une exposition reelle via des exclusions, des protocoles legacy, des chemins guest ou des service principals qui n’ont jamais ete dans le bon scope.

Cet article traite Conditional Access comme un probleme de preuve, pas comme un probleme de capture d’ecran. L’objectif est d’expliquer ce qui constitue une vraie faille, quels signaux Microsoft permettent de la demontrer, comment la corriger sans provoquer de lockout metier, puis comment valider que l’etat plus sur est bien applique apres le changement. Pour la revue plus large du tenant, commencez par Comment auditer la securite Microsoft Entra ID (Azure AD) : guide pratique.

Failles acces conditionnel Entra ID : qu’est-ce qu’une vraie faille ?

Une faille de Conditional Access est tout decalage entre la policy que vous pensez imposer et les sign-ins que Microsoft Entra evalue reellement. Microsoft decrit Conditional Access comme un moteur de policy qui combine des signaux, applique des assignments et des conditions, puis accorde, bloque ou restreint l’acces. Le mecanisme est puissant, mais il n’est pas auto-probant. Une policy ne reduit le risque que si elle cible les bonnes identites et les bonnes resources, evalue le bon chemin de protocole et laisse des preuves dans les sign-in logs et les audit logs.

En pratique, une faille apparait generalement dans l’un des cas suivants :

• une policy manque completement pour un scope sensible
• une policy existe mais exclut les users ou les roles qui comptent le plus
• une policy protege les users mais pas les workload identities
• une policy cible les mauvaises resources ou les mauvais chemins client
• une policy applique un grant trop faible pour la resource concernee
• une policy reste en report-only et ne passe jamais a l’enforcement

Microsoft rappelle aussi que Conditional Access est evalue apres le premier facteur d’authentification. Il ne faut donc pas presenter Conditional Access comme un controle magique “avant authentification”. C’est une couche de decision autour d’un sign-in, et la qualite de cette decision depend du scope, de la telemetry et du design de la policy.

Pourquoi Conditional Access Peut Quand Meme Laisser Une Exposition Reelle

Beaucoup d’equipes raisonnent sur Conditional Access comme sur un etat binaire : active ou non active. L’exposition reelle est plus complexe. Microsoft Entra evalue toutes les policies applicables a un sign-in, et l’utilisateur doit satisfaire toutes les exigences applicables avant que l’acces soit accorde. Le vrai probleme est que beaucoup de sign-ins qui devraient etre gouvernes ne deviennent jamais “applicables” en pratique.

Le premier exemple est la derive de scope. Les equipes securite pensent souvent qu’une policy large couvre tout le monde parce qu’elle cible All users. Microsoft documente que All users inclut les B2B guests, ce qui est utile, mais cela ne veut pas dire que tous les chemins d’identite sont couverts. Les workload identities sont une classe d’assignation distincte, et les policies scopees pour les users ne gouvernent pas automatiquement les service principals. Si le tenant repose sur des app registrations, de l’automatisation ou des integrations backend, il faut revoir cela avec le meme niveau de serieux que les users humains.

Le second exemple est la difference entre un grant large et un grant fort. Require multifactor authentication et Require authentication strength ne sont pas le meme controle. Si l’objectif metier est une authentification resistante au phishing pour les roles admin ou les applications sensibles, un simple requirement MFA peut etre plus faible que l’intention ecrite. C’est aussi pour cela que Securite des Identites Azure : Pourquoi le MFA Seul ne Suffit Pas et MFA Fatigue : detection et prevention dans Microsoft Entra ID sont souvent lies a la revue Conditional Access.

Le dernier probleme recurrent est la derive de validation. Les policies accumulent des exclusions, des brouillons en report-only, des templates qui se recouvrent et des exceptions d’urgence. Le portail affiche toujours beaucoup de policies, mais les sign-ins qui comptent peuvent continuer a passer sans challenge ou etre evalues par des chemins plus faibles que prevu.

Failles de Scope : Users, Guests, Roles, Resources et Workload Identities

Users, directory roles et exclusions

La premiere etape de revue consiste a cartographier qui est vraiment cible par les policies. Conditional Access peut inclure ou exclure tous les users, des users et groups selectionnes, des directory roles, des guests et external users, ainsi que des workload identities. Un tenant avec une bonne couverture user peut quand meme laisser des roles privilegies ou des exclusions privilegiees sous-gouvernes. C’est particulierement vrai si l’acces privilegie est deja trop large, comme dans Acces Privilegie Azure : Trop d'Admins Globaux.

Les emergency access accounts sont l’exemple le plus clair d’exclusion intentionnelle. Microsoft recommande de les exclure des policies Conditional Access pour eviter un lockout du tenant, mais cette recommandation ne justifie pas des exclusions de confort. Chaque exclusion doit avoir une raison etroite, un owner et une supervision active. Si le meme break-glass sert a l’administration normale, la faille est operationnelle, pas theorique.

Guests et external users

L’acces guest et externe merite sa propre revue, pas une hypothese rapide du type All users a tout resolu. Microsoft Entra permet de cibler des types precis de guests et d’external users, et le comportement externe depend aussi des cross-tenant trust settings. Par exemple, quand vous utilisez les authentication strengths pour les external users, Microsoft documente que le resource tenant evalue aussi la confiance MFA du home tenant. Cela veut dire que la couverture guest n’est pas seulement une question d’existence de policy. C’est une question de scope et de trust. C’est une des raisons pour lesquelles Comptes Invites Azure : Risques du Tenant doit souvent etre relu en meme temps.

Resources, apps et user actions

Une autre faille de scope consiste a viser le mauvais ensemble de resources. Les policies peuvent etre assignees a toutes les resources ou a des resources selectionnees. Si le tenant protege les admin portals Microsoft mais pas les applications metier ou SaaS que les users atteignent vraiment en premier, l’histoire de controle reste incomplete. Le meme probleme apparait quand une equipe se contente d’une capture sur un cloud app au lieu de verifier le vrai resource path qu’un attaquant reutiliserait apres un vol de credentials ou de session. Les attaques qui exploitent des sessions valides ou des chemins OAuth se chainent souvent avec ces failles, d’ou l’interet de Device Code Phishing : comment le flux OAuth compromet les comptes Entra ID.

Workload identities

Les service principals et les workload identities sont le point aveugle le plus frequent dans des tenants pourtant matures. Microsoft documente que les appels emis par des service principals ne sont pas bloques par des policies Conditional Access scopees sur les users, et qu’il faut utiliser Conditional Access pour les workload identities quand ces identites doivent etre traitees par des policies. En pratique, cela veut dire qu’un tenant peut montrer une bonne couverture MFA user tout en laissant les identites d’automatisation et d’application hors du modele Conditional Access.

Cela ne veut pas dire que toutes les workload identities doivent recevoir la meme policy. Cela veut dire que le tenant doit prouver qu’il sait quelles workload identities existent, lesquelles sont exclues par design et lesquelles dependent encore de patterns plus faibles qu’il faudrait remplacer par des managed identities quand c’est possible.

Failles de Controle : MFA, Authentication Strengths, Legacy Authentication et Risk Policies

La couverture MFA n’est pas la meme chose qu’un design d’authentification fort

Un tenant peut avoir beaucoup de policies qui exigent MFA tout en laissant des acces de forte valeur sur des methodes plus faibles que prevu. Microsoft documente les authentication strengths comme un controle Conditional Access qui limite les combinaisons de methodes autorisees pour acceder a une resource. Cette distinction compte chaque fois que l’objectif de policy est plus fort que “n’importe quel MFA suffit”. Pour les roles admin ou les applications sensibles, la difference entre un grant MFA large et une exigence resistante au phishing ou passwordless doit etre explicite.

La legacy authentication reste une vraie faille quand elle est encore atteignable

La legacy authentication doit etre traitee avec precision parce qu’elle est souvent decrite trop vaguement. Microsoft indique que les protocoles legacy ne supportent pas MFA et ne transmettent pas l’etat de l’appareil. Microsoft recommande aussi de bloquer les requests d’authentification qui utilisent ces protocoles et note que ces chemins restent fortement utilises dans les campagnes de password spraying et de credential stuffing.

La formulation defensable est donc la suivante : la legacy authentication est une faille lorsque ces protocoles restent atteignables pour des identites ou des resources que le tenant croit protegees par des exigences Conditional Access modernes. Certains tenants ferment cette faille avec une policy de blocage dediee. D’autres s’appuient sur des grants plus larges qui s’appliquent a tous les client apps. La bonne revue ne consiste pas a recopier un template. Elle consiste a prouver, avec les sign-in logs, que les clients legacy sont bloques ou absents. Si le tenant examine deja la faiblesse du premier facteur, rattachez ce sujet a Password Spraying : detection et prevention dans Active Directory et Entra ID.

Les risk policies ne sont pas implicites dans une bonne maturite Conditional Access

Un tenant sans policies de sign-in risk ou de user risk n’est pas automatiquement mal configure, parce que ces policies dependent des capacites Microsoft Entra ID Protection et du niveau de licence approprie. En revanche, si le discours securite pretend que l’acces est adapte au risque, le tenant doit prouver que ces controles existent et sont appliques. Microsoft documente les sign-in risk policies separement et rend explicite la dependance au niveau P2. Si le tenant ne licencie pas ou n’utilise pas cette capacite, il faut le dire clairement plutot que d’insinuer un controle absent. Voir aussi Azure Identity Protection : Automatiser la Reponse aux Credentials Divulgues.

Detection

La detection des failles d’acces conditionnel Entra ID est un exercice de correlation, pas une alerte fondee sur un champ unique.

Revoir d’abord les preuves de sign-in

Les sign-in logs Microsoft Entra sont la source de preuve principale. Pour les sign-ins interactifs et non interactifs, examinez au minimum les dimensions suivantes :

La nuance importante est la suivante : un sign-in reussi avec conditionalAccessStatus = notApplied ne suffit pas a lui seul. La vraie question est de savoir si ce sign-in aurait du etre gouverne selon le design meme du tenant.

Revoir les audit logs pour la derive de policy

Les audit logs sont la deuxieme source de preuve. Utilisez-les pour revoir la creation de policies, les mises a jour, les changements d’enablement, les passages en report-only, les changements d’exclusions et les suppressions. Si un tenant modifie sans cesse le scope de Conditional Access sans garder de preuve du pourquoi, la vraie faille est autant une derive de gouvernance qu’un probleme de design.

Revoir l’etat des policies, pas seulement leur texte

Le mode report-only et l’outil What If sont utiles, mais ils repondent a des questions differentes. report-only aide a evaluer l’impact sans enforcement. What If aide a simuler quelles policies s’appliqueraient a un sign-in de user ou de service principal. Aucun des deux ne remplace la preuve de production. Une revue mature utilise les deux, puis confirme le resultat dans de vrais sign-in logs.

Remediation

La remediation doit d’abord fermer les failles de scope et de controle qui ont le plus d’impact.

1. Etablir une baseline large pour les users et les resources. Le tenant doit pouvoir montrer les policies de base qui protegent l’acces utilisateur normal sur les resources qui comptent, pas seulement sur un admin portal ou une application favorite.

2. Revoir les exclusions avant d’ajouter de nouvelles policies. Si les exclusions cachent deja des administrateurs, des guests ou des groupes de forte valeur, de nouvelles policies peuvent donner une illusion de progression tout en laissant l’exposition reelle intacte.

3. Bloquer ou eliminer les chemins de legacy authentication. Quand Conditional Access est disponible, utilisez le scope de policy et la validation pour bloquer la legacy authentication. Quand des dependances de service ou d’application existent encore, documentez-les explicitement et traitez-les comme des exceptions a retirer, pas comme des hypotheses permanentes de design.

4. Separrer la couverture user de la couverture workload identity. Si le tenant s’appuie sur des service principals, de l’automatisation ou des identites d’application, il faut une voie de revue distincte pour les workload identities. N’imaginez pas que les policies users ont fait ce travail a votre place.

5. Utiliser les authentication strengths quand l’objectif d’acces est plus fort qu’un MFA generique. Les applications sensibles, les acces externes et les roles privilegies demandent souvent plus qu’un simple grant MFA.

6. Ajouter des risk policies seulement si le tenant sait vraiment les exploiter. Si l’evaluation du risque fondee sur P2 fait partie de l’histoire securite, la preuve doit le montrer. Si ce n’est ni licencie ni deploye, l’article doit le traiter comme une limite consciente, pas comme une maturite cachee.

Validation Apres Changement de Policy

C’est a ce stade que le travail sur Conditional Access echoue le plus souvent.

Commencez par utiliser What If pour verifier l’application attendue des policies sur des users representatifs, des roles admin, des guests et des service principals. Utilisez ensuite report-only quand c’est approprie pour comprendre le blast radius avant enforcement. Enfin, confirmez le resultat reel dans les sign-in logs apres l’activation de la policy.

Cette validation doit repondre a des questions concretes :

• les users vises passent-ils bien par les bonnes policies ?
• les comptes exclus restent-ils volontairement exclus et surveilles ?
• les sign-ins guest empruntent-ils le chemin de policy attendu ?
• les workload identities restent-elles hors des controles scopees sur les users ?
• les tentatives via client legacy echouent-elles desormais ou disparaissent-elles ?
• si des authentication strengths ont ete introduites, les sign-ins concernes montrent-ils bien le niveau de force attendu ?

Un tenant qui ne sait pas repondre a ces questions avec des preuves de sign-in et d’audit n’a pas fini sa remediation.

Preuves a Conserver Entre Deux Revues

Conditional Access derive discretement, donc le pack de preuve compte.

C’est cet ensemble de preuves qui permet a la revue suivante de mesurer la derive au lieu de repartir de captures eparses. Si le tenant a aussi besoin d’un cadrage plus large pour la conformite, Exigences NIS2 pour la securite des identites : ce que les equipes AD et Entra doivent prouver est le bon article complementaire, pas un substitut a cette revue technique.

Comment EtcSec Aide a Mesurer les Failles d’Acces Conditionnel

Ici, EtcSec doit etre positionne de facon etroite : non pas comme un detecteur magique de sign-ins, mais comme un moyen de re-mesurer dans le temps des conditions structurelles de faille Conditional Access.

Pour cet article, les findings vraiment pertinents sont ceux qui correspondent deja a de vrais problemes de design de policy :

• CA_NO_MFA_REQUIREMENT
• CA_NO_LEGACY_AUTH_BLOCK
• CA_NO_RISK_BASED_SIGNIN
• LEGACY_AUTH_ALLOWED

Cette correspondance est utile parce qu’elle soutient une revue recurrente. Le tenant peut re-auditer apres ses changements de policy et verifier si les memes failles structurelles existent encore, au lieu de traiter Conditional Access comme un simple setup initial.

References Primaires

• What is Conditional Access?
• Conditional Access: Users, groups, agents, and workload identities
• How to use conditions in Conditional Access policies
• Block legacy authentication with Conditional Access
• Troubleshoot Conditional Access policies with the What If tool
• Analyze Conditional Access policy impact with report-only mode
• How Conditional Access authentication strengths work
• Conditional Access authentication strength for external users
• Conditional Access for workload identities
• Manage emergency access administrative accounts in Microsoft Entra ID
• Require multifactor authentication for elevated sign-in risk
• What are Microsoft Entra sign-in logs?
• signIn resource type - Microsoft Graph v1.0
• Audit logs in Microsoft Entra ID