Ce que vous saurez faire
- Énoncer les principes Zero Trust (verify explicitly, least privilege, assume breach) et les traduire en réglages Entra.
- Configurer Identity Protection (P2) : politiques basées sur le risque utilisateur / risque de connexion.
- Comparer les méthodes MFA et passwordless (FIDO2, Windows Hello for Business, Authenticator) et prioriser les plus sûres.
- Situer Defender for Identity et Defender for Cloud Apps comme à connaître, non déployables en E3+P2, et connaître leurs alternatives.
Compétences transférées depuis l'AD classique
| L'admin AD réutilise | L'admin AD doit désapprendre |
|---|---|
| Culture du moindre privilège | « Le réseau interne est de confiance » — Zero Trust rejette ce présupposé |
| Gestion des méthodes d'authentification | « Le mot de passe est la base » — viser le passwordless |
| Analyse d'incidents | Détection basée sur le risque calculé par le cloud — aucun équivalent AD |
Architecture Zero Trust
1. Zero Trust : les principes
Le modèle AD classique repose sur un présupposé : le réseau interne est de confiance. Zero Trust renverse ce présupposé. Trois principes :
- Verify explicitly — toujours authentifier et autoriser à partir de tous les signaux disponibles (identité, appareil, emplacement, risque), à chaque accès.
- Least privilege — accès juste suffisant, juste-à-temps (JIT / PIM), juste-assez (JEA).
- Assume breach — partir du principe que la compromission est possible : segmenter, chiffrer, surveiller, limiter le rayon d'explosion.
| Principe | Mise en œuvre Entra |
|---|---|
| Verify explicitly | Conditional Access (signaux), MFA, appareil conforme |
| Least privilege | PIM, Access Reviews, rôles ciblés (module 05) |
| Assume breach | Identity Protection (risque), logs & alertes (module 09), segmentation |
Confiance implicite au périmètre réseau : dès qu'on est sur le LAN, on est « à l'intérieur ». Ce présupposé rendait le mouvement latéral facile pour un attaquant qui avait franchi le pare-feu.
2. Identity Protection (P2)
Identity Protection (IP) calcule un risque à partir de signaux Microsoft (renseignement sur les menaces, comportements) :
- Risque de connexion (sign-in risk) — cette connexion précise est-elle suspecte ? Voyage impossible, IP anonyme / Tor, adresse liée à des attaques, etc.
- Risque utilisateur (user risk) — ce compte est-il probablement compromis ? Identifiants divulgués détectés, activités anormales, etc.
On agit via des risk-based policies, appliquées par le Conditional Access :
- Sign-in risk policy — si risque de connexion ≥ moyen → exiger la MFA (ou bloquer).
- User risk policy — si risque utilisateur ≥ élevé → exiger un changement de mot de passe sécurisé (self-remediation via SSPR) ou bloquer.
Prérequis notable : la détection « identifiants divulgués » nécessite Password Hash Sync en contexte hybride (module 03).
3. Méthodes MFA & passwordless
| Méthode | Niveau | Commentaire |
|---|---|---|
| SMS / appel téléphonique | Faible | Vulnérable au SIM swapping / interception — à éviter, à retirer |
| Authenticator (notification + numéro à saisir) | Bon | Number matching obligatoire (anti-MFA fatigue) |
| Windows Hello for Business | Fort | Passwordless, biométrie + TPM, lié à l'appareil |
| FIDO2 (clés de sécurité / passkeys) | Fort | Passwordless, résistant au phishing |
| Certificat (CBA) | Fort | Authentification par certificat, cas spécifiques |
Objectif Zero Trust : viser le passwordless résistant au phishing (FIDO2, WHfB) et retirer progressivement le SMS.
La carte à puce (smart card logon) était le passwordless historique via PKI.
FIDO2 / Windows Hello généralisent le passwordless sans PKI lourde.
Empiler des méthodes faibles « pour la disponibilité ». Chaque méthode faible active est un point d'entrée : le niveau réel est celui du maillon le plus faible.
Vous voulez basculer votre PME en passwordless. Quelle méthode active-t-on et laquelle retire-t-on en priorité ?
WHfB pour les postes gérés (biométrie + TPM lié à l'appareil), FIDO2 pour les usages sensibles ou multi-postes (clés physiques ou passkeys). Le SMS reste vulnérable au SIM swapping et à l'interception : tant qu'il est actif, il annule le bénéfice du passwordless. Retirer progressivement, en s'assurant que chaque utilisateur a au moins une méthode forte enrôlée.
4. Defender for Identity — À CONNAÎTRE, NON DÉPLOYABLE EN L'ÉTAT
Microsoft Defender for Identity (MDI) est une solution qui surveille les contrôleurs de domaine on-prem (via des capteurs) pour détecter les attaques d'identité : reconnaissance, mouvement latéral, Pass-the-Hash / Ticket, DCSync, etc.
5. Defender for Cloud Apps (aperçu)
Microsoft Defender for Cloud Apps (MDA, un CASB) découvre et contrôle l'usage des apps SaaS : shadow IT, sessions à risque, DLP cloud.
Sources Microsoft Learn
- Zero Trust
- Identity Protection
- Politiques basées sur le risque
- Méthodes d'authentification
- Passwordless (FIDO2 / WHfB)
- Defender for Identity (à connaître)
- Defender for Cloud Apps (aperçu)
Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.
Risk-based policies + passwordless
Partie A — Sign-in risk policy en report-only (45 min)
Portail : Entra admin center > Protection > Conditional Access > Create new policy.
- Name : CA-Risk-SignIn-MFA.
- Users : All users, exclude break-glass.
- Cloud apps : All cloud apps.
- Conditions > Sign-in risk : Medium, High.
- Grant : Require multi-factor authentication.
- Enable policy : Report-only.
Créer aussi CA-Risk-User-PasswordChange : User risk = High, Grant = Require password change. En report-only.
Vérifier dans Sign-in logs les détections des jours suivants ; ajuster les seuils avant de basculer en On.
Partie B — Passwordless via Windows Hello for Business (45 min)
Portail : Entra admin center > Protection > Authentication methods > Policies.
- Activer Windows Hello for Business : Enable = Yes, Target = All users.
- Activer FIDO2 security key : Enable = Yes, Target = un groupe pilote (ex :
grp-passwordless-pilot). - Sur Authenticator : activer Number matching et Show additional context.
- Sur les postes joints Entra + Intune, WHfB s'auto-configure au 1er login (PIN + biométrie).
- Publier un guide utilisateur (portail
myaccount.microsoft.com> Security info) pour l'ajout d'une clé FIDO2.
5 réflexes à corriger en sécurité
Testez vos acquis
Une évaluation interactive qui vous donne le badge Acquis (≥60%) ou Maîtrisé (≥80%).
Cas pratique — Passer au Zero Trust
Contexte : la direction veut « passer au Zero Trust » et supprimer les mots de passe. Le SI est E3 + P2, encore hybride (PHS actif).
Questions :
- Quelles briques Entra assemblez-vous pour matérialiser les 3 principes Zero Trust ?
- Quelle trajectoire vers le passwordless, et quelles méthodes visez-vous ?
- La direction demande Defender for Identity : que répondez-vous, et quelle alternative ?
- Quel garde-fou avant d'activer les politiques basées sur le risque ?
Démarche attendue
- Verify explicitly → Conditional Access (MFA, appareil conforme, signaux). Least privilege → PIM + Access Reviews (module 05). Assume breach → Identity Protection (risk policies) + supervision / alertes (module 09) + segmentation des accès.
- Trajectoire passwordless : activer Authenticator (number matching), déployer Windows Hello for Business et FIDO2 / passkeys, communiquer, enrôler, puis retirer le SMS. Viser le passwordless résistant au phishing (FIDO2 / WHfB).
- Defender for Identity n'est pas déployable en E3+P2 (E5 / add-on). À connaître pour les scénarios d'attaque on-prem. Alternative : Identity Protection (détection basée risque côté cloud) + sign-in / audit logs Entra (module 09). Argument supplémentaire pour réduire la dépendance à l'AD DS (module 08).
- Garde-fou : déployer les risk policies en report-only d'abord, s'assurer que SSPR est configuré (pour la remédiation user-risk) et que les break-glass sont exclus, avant toute bascule en « On ».