Accès conditionnel mode rapport seul, exclusions obsolètes

Accès conditionnel en mode rapport seul et exclusions obsolètes : ce que « appliqué » veut vraiment dire

Le mode rapport seul (report-only) de l'Accès conditionnel et les exclusions obsolètes sont les deux raisons les plus courantes pour lesquelles une stratégie d'Accès conditionnel apparaît « Activée » dans le centre d'administration Microsoft Entra tout en ne bloquant absolument rien. Ces deux situations passent facilement inaperçues lors d'une revue rapide du portail, car la stratégie existe toujours, ses conditions sont toujours correctement configurées, et elle apparaît toujours dans la liste des stratégies :

La stratégie — ou une modification qui lui a été appliquée — se trouve en mode rapport seul, qui évalue les connexions et journalise le résultat, mais n'accorde, ne bloque, ni ne met jamais l'accès au défi.
La stratégie est appliquée, mais sa liste d'exclusions a dépassé la raison précise et documentée pour laquelle elle avait été créée, si bien que les connexions qui comptent le plus lui échappent sans être inquiétées.

Aucune de ces deux situations n'est un bug. Ce sont toutes deux des fonctionnalités Microsoft Entra prises en charge et intentionnelles. L'écart est opérationnel : personne n'a revérifié si l'exception était toujours nécessaire. Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition couvre le périmètre et le paysage de contrôle plus larges — stratégies absentes, identités de charge de travail, authentification héritée. Cet article reste volontairement ciblé : que se passe-t-il après qu'une stratégie existe, quand son état d'application ou sa liste d'exclusions dérive silencieusement de ce que le tenant croit être protégé.

Mode rapport seul : le non-contrôle silencieux

Le mode rapport seul est un état par stratégie dans l'Accès conditionnel. Microsoft le documente comme permettant aux administrateurs de « tester la plupart des stratégies d'Accès conditionnel avant de les activer » — lors de la connexion, le système évalue la stratégie mais n'applique pas les contrôles d'octroi ou de session, et les utilisateurs ne sont jamais invités à effectuer une MFA, à prouver la conformité de leur appareil, ni bloqués par une stratégie en mode rapport seul.

⚠️

⚠️ Avertissement : le mode rapport seul n'est pas une version affaiblie de « Activée ». Il équivaut fonctionnellement à « Désactivée » en matière d'application — la stratégie produit des preuves dans les journaux, pas un contrôle d'accès.

Pourquoi le mode rapport seul dérive d'un état de test vers un état permanent

Le mécanisme qui rend cela dangereux en pratique n'est pas le déploiement initial — la plupart des équipes mettent délibérément en scène leurs nouvelles stratégies en mode rapport seul pour une fenêtre de revue. Le risque survient dans la dérive qui suit : une stratégie appliquée peut être silencieusement repassée en mode rapport seul par quiconque dispose des droits d'administrateur d'Accès conditionnel. La documentation de Microsoft est explicite : le mode rapport seul n'applique jamais les contrôles d'octroi ou de session, quel que soit l'état antérieur de la stratégie : « lors de la connexion, le système évalue les stratégies en mode rapport seul mais ne les applique pas ». Ce simple interrupteur, activé pendant une session de dépannage ou une exception d'accès d'urgence puis jamais réinitialisé, retire silencieusement un contrôle que chaque tableau de bord et chaque liste de stratégies continue pourtant d'afficher comme configuré.

La recommandation de Microsoft consiste à valider les modifications apportées à une stratégie déjà appliquée en la clonant en une copie en mode rapport seul, plutôt qu'en basculant l'interrupteur de la stratégie d'origine — en comparant les résultats de la copie à ceux de la stratégie active, puis en supprimant la copie une fois satisfait. Quand ce schéma n'est pas suivi, c'est la stratégie d'origine elle-même qui finit par rester en mode rapport seul, parfois indéfiniment.

Exclusions obsolètes et excessives : comment la couverture s'érode avec le temps

Les exclusions existent pour de véritables raisons opérationnelles : un bureau distant qui ne peut pas encore satisfaire une exigence de localisation, un appareil hérité en attente de remplacement, un compte d'accès d'urgence (break-glass). Les recommandations de Microsoft sur la gestion des utilisateurs exclus sont explicites : cela commence petit et devient un problème :

« Souvent, lorsque vous configurez une exclusion pour la première fois, il existe une courte liste d'utilisateurs qui contournent la stratégie. Au fil du temps, d'autres utilisateurs sont ajoutés à l'exclusion, et la liste s'allonge. À un moment donné, vous devez revoir la liste et confirmer que chacun de ces utilisateurs reste éligible à l'exclusion. »

Trois façons dont les listes d'exclusion s'aggravent plus qu'il n'y paraît

Les exclusions individuelles d'utilisateurs ou de groupes locaux hérités n'offrent aucune visibilité continue. Les utilisateurs ignorent souvent qu'ils sont exclus, et si l'exclusion utilise un groupe synchronisé depuis l'environnement local ou un groupe dynamique, les administrateurs ont une visibilité limitée sur qui en fait partie et pourquoi.
L'appartenance en libre-service peut transformer une exclusion en moyen de contournement. Si le groupe d'exclusion autorise l'adhésion en libre-service (un schéma légitime pour le scénario de « l'employé en déplacement »), tout utilisateur qui découvre le groupe peut s'y ajouter lui-même.
L'éligibilité n'est jamais revérifiée. Un utilisateur exclu à cause d'un appareil hérité aujourd'hui remplacé, ou une exclusion de prestataire qui a survécu à la fin du contrat, reste exclu indéfiniment car rien ne force une nouvelle revue.

Le contrôle compensatoire : groupes attribués plus revues d'accès récurrentes

Le contrôle compensatoire recommandé par Microsoft consiste à adosser chaque exclusion à un groupe de sécurité Microsoft Entra dédié, à appartenance Attribuée (et non une liste d'utilisateurs individuels, ni un groupe synchronisé hérité), puis à rattacher une revue d'accès récurrente à ce groupe. Le schéma documenté pour une exclusion basée sur la localisation est une revue qui s'exécute chaque semaine, ne se termine jamais, exige une auto-attestation de chaque membre, et retire automatiquement quiconque ne répond pas. Pour une exclusion liée à l'authentification héritée, le schéma recommandé est une revue récurrente avec les propriétaires des unités métier comme réviseurs et application automatique des résultats. Ces deux schémas nécessitent une licence Microsoft Entra ID P2, Microsoft Entra ID Governance, ou Enterprise Mobility + Security E5 — les revues d'accès ne sont pas disponibles sur les niveaux inférieurs.

💡

💡 Astuce : si un groupe d'exclusion n'a aucune revue d'accès rattachée, considérez cela comme le constat lui-même — pas « cette exclusion est-elle raisonnable aujourd'hui », mais « rien dans ce tenant ne reposera jamais cette question ».

Les exclusions ont aussi un angle mort de portée que la plupart des réviseurs ne vérifient pas : les exclusions de ressources sur les stratégies « Toutes les ressources ». Microsoft déploie un changement d'application, à partir du 15 juin 2026, qui comble précisément cet écart. Auparavant, lorsqu'une stratégie « Toutes les ressources » comportait une exclusion de ressource, les connexions qui demandaient uniquement un ensemble restreint de « portées de base » (openid, profile, email, offline_access, User.Read, et quelques portées d'annuaire similaires) étaient silencieusement exemptées de toute application — même si l'administrateur qui avait construit la stratégie pensait que « Toutes les ressources » signifiait vraiment tout. Les clients publics comme Azure CLI ou VS Code, et les applications web confidentielles qui ne demandent que ces portées, passaient sans être mis au défi. Les attaquants qui abusent de flux OAuth demandant des portées minimales, dans un esprit similaire à ce qui se produit dans le device code phishing, sont exactement le type de connexion que cette faille aurait laissé passer sans revue. C'est un cas où la propre télémétrie de Microsoft a confirmé que les exclusions au niveau des ressources produisaient des angles morts de couverture plus larges et non voulus que ce que les tenants croyaient — exactement le même mode de défaillance que celui décrit dans cet article, simplement au niveau de la portée plutôt qu'au niveau de l'utilisateur.

Détection

La détection ici est un exercice de corrélation entre les preuves de connexion et l'historique des modifications de stratégie, pas une simple alerte.

Signal	Où le trouver	Ce qu'il indique
Résultat par stratégie sur l'onglet Rapport seul d'une entrée de journal de connexion	Centre d'administration Entra → détails du journal de connexion	Si cette connexion précise aurait réussi, échoué, ou nécessité une action si la stratégie était appliquée
`appliedConditionalAccessPolicies[].result` via Microsoft Graph	`GET /auditLogs/signIns` (les valeurs rapport seul nécessitent l'en-tête `Prefer: include-unknown-enum-members`)	La version programmatique de l'onglet ci-dessus — valeurs d'énumération : `success`, `failure`, `notApplied`, `notEnabled`, `reportOnlySuccess`, `reportOnlyFailure`, `reportOnlyNotApplied`, `reportOnlyInterrupted`
`enforcedGrantControls` / `enforcedSessionControls` sur le même objet	Microsoft Graph `appliedConditionalAccessPolicy`	Confirme quels contrôles se sont réellement appliqués pour une connexion donnée, par rapport à ceux que la stratégie est configurée pour exiger
Classeur Conditional Access Insights and Reporting	Centre d'administration Entra, nécessite Entra ID P1 + un espace de travail Log Analytics recevant les journaux de connexion	Comparaison agrégée rapport seul vs. appliqué sur une plage de temps, un ensemble d'applications et un ensemble d'utilisateurs — le moyen le plus rapide de repérer une stratégie restée en mode rapport seul bien au-delà d'une fenêtre de test
Vue Impact de stratégie (préversion)	Centre d'administration Entra, rôle Lecteur de sécurité ou supérieur	Instantané sur 24h/7j/1 mois de l'impact potentiel et existant d'une stratégie, sans construire de requête de classeur
Journal d'audit : changements d'état « Enable policy »	Centre d'administration Entra → Journaux d'audit, filtrés sur les mises à jour de stratégies d'Accès conditionnel	L'événement précis sur lequel alerter : toute transition Activée → Rapport seul sur une stratégie précédemment appliquée
Appartenance au groupe d'exclusion + résultats/journaux d'audit des revues d'accès	ID Governance → Revues d'accès → Résultats / Journaux d'audit	Qui a été retiré, approuvé automatiquement, ou n'a jamais répondu — la preuve concrète qu'une exclusion obsolète existait
`membershipType` du groupe d'exclusion	Point de terminaison Microsoft Graph `groups` ou centre d'administration Entra	Signale les groupes d'exclusion synchronisés depuis l'environnement local ou dynamiques plutôt qu'Attribués — le schéma que Microsoft identifie comme réduisant la visibilité

🚨 Danger : une stratégie sans aucun événement reportOnlyFailure ou Failure n'est pas forcément bien réglée. Cela peut tout aussi bien signifier que ses exclusions sont si larges que presque rien n'est réellement évalué contre elle.

Remédiation

Corriger la dérive du mode rapport seul

Extrayez l'état Activé actuel de chaque stratégie et la date de sa dernière modification. Toute stratégie en mode rapport seul sans date de fin de fenêtre de revue documentée est le problème — pas seulement « s'agit-il d'un nouveau test », mais « quelqu'un est-il responsable de la faire passer en mode appliqué ».
Alertez spécifiquement sur les événements de journal d'audit Activée → Rapport seul. Cette transition est rare, délibérée, et dangereuse lorsqu'elle survient sur une stratégie précédemment appliquée — elle ne devrait jamais se produire silencieusement.

Corriger la dérive des exclusions

Remplacez les exclusions d'utilisateurs individuels et de groupes synchronisés hérités par des groupes de sécurité Microsoft Entra dédiés, à appartenance Attribuée. C'est le prérequis de l'étape suivante ; les revues d'accès ciblent des groupes, pas des listes d'utilisateurs ad hoc.
Rattachez une revue d'accès récurrente à chaque groupe d'exclusion, en suivant les schémas documentés par Microsoft : auto-attestation avec retrait automatique pour les exclusions de déplacement/localisation, revue par le propriétaire avec application automatique pour les exclusions d'authentification héritée ou d'appareil. Cela nécessite une licence Entra ID P2 ou Entra ID Governance.
Revoyez chaque stratégie « Toutes les ressources » comportant une exclusion de ressource au regard du déploiement de l'application des portées de base prévu pour le 15 juin 2026. Décidez délibérément — activez la nouvelle application par anticipation via les paramètres des portées de base, ou utilisez « Personnaliser le comportement » pour les applications spécifiques qui ont réellement besoin de l'exemption héritée — plutôt que de laisser le déploiement par défaut de Microsoft décider silencieusement.
Revalidez avec des preuves, pas des intentions. Après toute bascule de rapport seul vers appliqué ou tout nettoyage de groupe d'exclusion, confirmez le résultat dans les journaux de connexion pour des comptes représentatifs, exclus comme inclus, pas uniquement sur l'écran de configuration de la stratégie.

Comment EtcSec détecte cela

Les contrôles Azure/Entra d'EtcSec correspondent directement aux deux modes de défaillance de cet article : CA_POLICY_REPORT_ONLY signale les stratégies d'Accès conditionnel toujours en mode rapport seul, CA_EXCESSIVE_EXCLUSIONS et CA_GROUP_EXCLUSION_LARGE signalent les stratégies dont le périmètre d'exclusion a grandi de façon disproportionnée par rapport à leur intention, et CA_USER_EXCLUSIONS_STALE signale les exclusions au niveau utilisateur qui ne montrent aucune preuve de revue récente. Comme ces deux modes de défaillance concernent une dérive plutôt qu'une erreur de configuration ponctuelle, la valeur réside dans la répétition régulière de l'audit — un tenant qui a réussi ce contrôle il y a six mois peut silencieusement y échouer aujourd'hui sans qu'une seule stratégie n'ait été supprimée ni qu'un seul écran de paramètres n'ait changé.

ℹ️

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

Accès conditionnel mode rapport seul, exclusions obsolètes : ce que « appliqué » veut vraiment dire