Ce que vous saurez faire
- Décomposer une politique CA : affectations (utilisateurs, apps, conditions) → contrôles (grant / session).
- Utiliser les named locations et l'exigence d'appareil conforme (lien Intune).
- Déployer sûrement : report-only mode, What If, comptes break-glass exclus.
- Construire 5 politiques types : blocage legacy auth, MFA admins, MFA tous, appareil conforme pour apps sensibles, geo-blocking.
- Situer les templates baseline recommandés par Microsoft.
Compétences transférées depuis l'AD classique
| L'admin AD réutilise | L'admin AD doit désapprendre |
|---|---|
| Logique de règles et d'exceptions | « La sécurité vient du réseau/pare-feu » — ici, elle vient de l'identité + du contexte |
| Rigueur sur les comptes admins | Aucun équivalent GPO au CA : c'est un moteur de décision par connexion |
| Notion de « conditions » | « Bloquer une fois = bloqué partout » — le CA évalue chaque connexion |
Le moteur de décision par connexion
1. Anatomie d'une politique CA
Le Conditional Access (CA) est le cœur de la sécurité Entra. À chaque tentative de connexion, il évalue un contexte (qui, quoi, où, comment, quel risque) et décide : autoriser, bloquer, ou autoriser sous condition (MFA, appareil conforme…).
Une politique CA se lit comme une phrase : SI [affectations] ALORS [contrôles].
SI utilisateurs = [qui]
ET application/action = [quoi]
ET conditions = [plateforme, emplacement, risque, état de l'appareil...]
ALORS accorder l'accès EN EXIGEANT [MFA / appareil conforme / app approuvée...]
OU bloquer l'accèsDeux grands blocs :
- Affectations (assignments) — à qui / quoi / dans quel contexte la politique s'applique.
- Contrôles d'accès (access controls) :
- Grant : bloquer, ou accorder sous exigence(s) (MFA, appareil conforme, app cliente approuvée, conditions d'utilisation). Combinables en ET/OU.
- Session : limiter la session (fréquence de ré-authentification, restrictions app imposées, contrôle par Defender for Cloud Apps).
Rien en AD DS n'évalue le contexte d'une connexion pour exiger de la MFA. Le plus proche (et très partiel) : restrictions d'horaires ou de postes de connexion.
Le CA est un concept nouveau à intégrer : moteur de décision, dynamique, évalué à chaque connexion.
2. Signaux & conditions
Les affectations combinent identité, ressource et contexte. C'est la richesse de la donnée disponible qui rend le CA puissant.
| Affectation | Exemples |
|---|---|
| Utilisateurs / groupes / rôles | Tous, un groupe, un rôle d'annuaire (ex : tous les rôles admin), invités |
| Ressources cibles | Applications cloud (M365, une app SaaS), actions utilisateur (enregistrement d'infos de sécurité), contextes d'authentification |
| Conditions — plateformes | Windows, iOS, Android, macOS |
| Conditions — emplacements | Named locations (IP / pays) |
| Conditions — client apps | Navigateur, apps mobiles / desktop, clients d'authentification legacy |
| Conditions — état de l'appareil | Conforme (Intune), joint hybride Entra |
| Conditions — risque (P2) | Risque utilisateur, risque de connexion (module 07) |
Aucun équivalent direct. Les GPO ciblent des postes/utilisateurs mais n'évaluent pas dynamiquement le contexte d'une connexion (risque, appareil conforme, geo). Il faut vraiment intégrer un modèle mental différent.
3. Named locations & device compliance
- Named locations : plages IP publiques ou pays que vous nommez (« Siège », « France »). Servent à conditionner ou exclure (ex : ne pas redemander la MFA depuis le siège — à manier avec prudence).
- Appareil conforme : la conformité est évaluée par Intune (module 06) et consommée par le CA via le contrôle « Require device to be marked as compliant ». C'est le pont identité ↔ poste.
Filtrer par IP relevait du pare-feu / VPN, séparé de l'identité.
Emplacement et conformité de poste = signaux parmi d'autres, combinés dans une même règle.
Votre direction propose : « on bloque simplement les connexions depuis l'étranger, ça devrait suffire ». Que répondez-vous ?
Un VPN place l'attaquant dans un pays autorisé en quelques secondes. Le geo est un signal parmi d'autres. Il faut le combiner avec MFA, blocage de la legacy auth et exigence d'appareil conforme. La défense en profondeur repose sur plusieurs contrôles indépendants, pas sur un seul filtre facile à contourner.
4. Contrôles disponibles
Les contrôles sont l'action que la politique déclenche quand ses conditions sont réunies.
| Contrôle | Effet | Cas typique |
|---|---|---|
| Bloquer | Interdiction sèche | Legacy auth, pays non autorisés |
| Exiger la MFA | Second facteur demandé | Le plus courant, pour admins ou tous |
| Appareil conforme / joint hybride | Réserve l'accès aux postes gérés | Apps sensibles, messagerie |
| App cliente approuvée / MAM | Mobile : app approuvée uniquement | Outlook mobile, protection d'app |
| Session (sign-in frequency) | Force la ré-auth périodique | Postes partagés, invités |
Les contrôles se combinent : « exiger la MFA ET un appareil conforme ». La combinaison ET est plus forte que OU — à manier selon la criticité de la ressource.
5. Déploiement sûr
Le CA peut verrouiller tout le monde dehors en une politique mal calibrée. Trois garde-fous obligatoires :
- Report-only : la politique est évaluée mais pas appliquée. Les sign-in logs indiquent ce qu'elle aurait fait. On démarre toujours une nouvelle politique en report-only.
- What If : outil qui simule le résultat pour un utilisateur / app / contexte donné, sans attendre une vraie connexion.
- Comptes break-glass : 2 comptes d'urgence (Global Admin cloud-only, mot de passe long, exclus de toutes les politiques CA), pour ne jamais se verrouiller dehors. Surveillés par alerte.
6. Templates recommandés (baseline Microsoft)
Microsoft fournit des templates de politiques (dans le portail, à la création) et une baseline « Zero Trust » à viser. Les incontournables :
- Bloquer l'authentification legacy — POP, IMAP, SMTP AUTH, anciens clients : protocoles qui ne supportent pas la MFA.
- MFA pour les administrateurs — tous les rôles à privilèges. Non négociable.
- MFA pour tous les utilisateurs.
- Exiger un appareil conforme pour les applications sensibles (messagerie, RH, finance).
- Bloquer l'accès depuis des pays non autorisés (geo-blocking, en complément).
- Exiger la MFA pour l'enregistrement des méthodes de sécurité (security info registration).
Sources Microsoft Learn
- Vue d'ensemble Conditional Access
- Composants d'une politique
- Report-only mode
- Outil What If
- Comptes break-glass
- Bloquer la legacy auth
- Templates courants
Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.
Construire 3 politiques CA en report-only
Partie A — Créer les comptes break-glass (30 min)
1. Créer 2 utilisateurs cloud-only
Portail : Entra admin center > Users > New user > Create new user
break-glass-01@votretenant.onmicrosoft.combreak-glass-02@votretenant.onmicrosoft.com
Mot de passe long (16+ caractères) généré et stocké hors ligne (coffre physique, KeePass air-gapped). Pas de MFA imposée à ces comptes.
2. Attribuer le rôle Global Administrator
Portail : Roles & admins > Global Administrator > Add assignments
3. Poser une alerte de connexion
Portail : Microsoft Sentinel ou Entra ID Audit logs. Toute connexion break-glass doit générer un mail à l'équipe sécurité.
Partie B — Créer 3 politiques CA en report-only (90 min)
Pour chaque politique : affectations claires, exclusion des 2 break-glass, Enable policy = Report-only.
Politique 1 — CA-Block-LegacyAuth
- Users : All users, exclude break-glass-01, break-glass-02.
- Cloud apps : All cloud apps.
- Conditions > Client apps : Exchange ActiveSync clients + Other clients.
- Grant : Block access.
Politique 2 — CA-MFA-Admins
- Users : Directory roles = Global Administrator, Security Administrator, Exchange Administrator (et autres rôles à privilèges), exclude break-glass.
- Cloud apps : All cloud apps.
- Grant : Require multi-factor authentication.
Politique 3 — CA-MFA-AllUsers
- Users : All users, exclude break-glass.
- Cloud apps : All cloud apps.
- Conditions : aucune (MFA partout).
- Grant : Require multi-factor authentication.
Valider avec What If
Portail : Conditional Access > Policies > What If. Testez au moins 3 scénarios : un admin, un utilisateur standard, un break-glass. Vérifiez que les break-glass ne sont jamais bloqués et n'ont pas de MFA imposée.
Partie C — Analyser et basculer (30 min)
Portail : Sign-in logs > Conditional Access. Après quelques connexions test (via un navigateur privé, un compte non-admin), examinez ce qui aurait été bloqué / demandé en MFA. Cochez qu'aucun break-glass n'est concerné et qu'aucun utilisateur légitime n'aurait été verrouillé.
Une fois convaincu, passez une seule politique (la plus prioritaire : legacy auth) de Report-only à On. Attendez 24-48h. Puis la suivante.
5 réflexes qui verrouillent tout le monde dehors
Testez vos acquis
Une évaluation interactive qui vous donne le badge Acquis (≥60%) ou Maîtrisé (≥80%).
Cas pratique — La demande de la direction
Contexte : la direction demande : « Tous les administrateurs doivent faire de la MFA, la vieille authentification doit être coupée, et l'accès à la messagerie doit être réservé aux postes gérés. On ne veut surtout pas se retrouver bloqués dehors. »
Questions :
- Quelles politiques CA créez-vous (nom + contrôle) ?
- Dans quel ordre de déploiement et avec quels garde-fous ?
- Quelle dépendance technique conditionne la politique « messagerie sur postes gérés » ?
Démarche attendue
- Trois politiques :
- CA-MFA-Admins — require MFA, ciblée sur les rôles d'annuaire à privilèges.
- CA-Block-LegacyAuth — block, client apps = Exchange ActiveSync + Other clients.
- CA-CompliantDevice-Exchange — require compliant device, ciblée sur Exchange Online.
- Ordre & garde-fous : créer d'abord 2 comptes break-glass exclus de toutes les politiques. Déployer chaque politique en report-only, valider avec What If et les sign-in logs, vérifier l'enrôlement MFA des admins, puis basculer en On une par une (jamais toutes d'un coup).
- Dépendance : la politique « messagerie sur postes gérés » exige des postes enrôlés et évalués conformes par Intune (module 06). Sans Intune, aucun appareil n'est « compliant » et la politique bloquerait tout le monde — d'où le report-only jusqu'à ce qu'Intune soit en place.