Accès Conditionnel : contrôle d'identité Zero Trust

L'accès conditionnel est un mécanisme de contrôle d'accès Zero Trust qui évalue un ensemble de conditions avant d'autoriser une connexion à une ressource. Dans Azure AD et Microsoft Entra ID, l'accès conditionnel repose sur des politiques qui croisent plusieurs signaux : identité de l'utilisateur, conformité de l'appareil, localisation réseau (Named Locations), application cible et niveau de risque calculé par Identity Protection. Chaque tentative d'authentification déclenche une évaluation en temps réel de ces signaux. Selon le résultat, la politique peut autoriser l'accès, le bloquer, ou exiger une vérification supplémentaire comme le MFA ou l'inscription de l'appareil dans Intune. Ce modèle rompt avec le périmètre réseau traditionnel en assumant que l'identité est le nouveau plan de contrôle. Son intérêt opérationnel réside dans sa granularité : une politique peut cibler un groupe d'utilisateurs spécifique, une plage IP déclarée sensible, ou un niveau de risque de connexion élevé détecté automatiquement. Une mauvaise configuration, comme l'oubli d'un compte de break-glass dans les exclusions ou une condition mal ordonnée, peut entraîner un lockout total ou une surface d'attaque exploitable.

La détection des anomalies liées à l'accès conditionnel s'appuie principalement sur les journaux de connexion Azure AD, accessibles via Entra ID sous 'Sign-in logs'. Chaque entrée contient le champ 'Conditional Access' avec le statut de chaque politique évaluée : 'Success', 'Failure' ou 'Not Applied'. Un nombre élevé d'entrées 'Not Applied' sur des comptes sensibles peut indiquer une exclusion abusive ou une politique contournée. Les événements de type 'Interrupted' avec code d'erreur 53003 signalent un blocage par accès conditionnel, tandis que le code 50097 indique un blocage lié à la conformité de l'appareil. Côté SIEM, les règles de corrélation doivent surveiller les connexions réussies depuis des Named Locations non déclarées, les connexions hors plage horaire habituelle, et les authentifications MFA satisfaites depuis des pays inhabituels. Microsoft Sentinel propose des workbooks dédiés à l'analyse des politiques d'accès conditionnel. L'outil 'What If' dans Entra ID permet de simuler l'évaluation d'une politique sur un scénario donné, utile pour valider la couverture des règles. Un compte exclu de toutes les politiques actives sans justification documentée constitue un indicateur de compromission fort à surveiller en priorité.

Côté Red Team, les politiques d'accès conditionnel sont une cible à cartographier avant toute tentative de mouvement latéral ou d'exfiltration. L'outil AADInternals permet d'énumérer les politiques en vigueur sur un tenant via des appels API authentifiés. Une technique classique consiste à identifier les comptes exclus des politiques, souvent des comptes de service ou des comptes break-glass non durcis. Le contournement du MFA est parfois possible via un token refresh replay si la politique n'impose pas de fréquence de réévaluation stricte (sign-in frequency). Les attaques de type device code phishing (RFC 8628) exploitent le flux OAuth 2.0 pour obtenir un token valide sans déclencher de challenge MFA, car l'appareil est considéré comme déjà validé. Pour le durcissement, il est recommandé d'activer la 'Continuous Access Evaluation' (CAE) afin de révoquer les tokens en temps réel lors d'un changement de contexte. Les politiques doivent couvrir tous les utilisateurs sans exception non documentée, avec une révision trimestrielle des exclusions. L'activation du mode 'Report-Only' avant déploiement permet d'identifier les faux positifs. Enfin, les comptes break-glass doivent être explicitement exclus, mais leur utilisation doit déclencher une alerte immédiate dans le SIEM.