Sécuriser Microsoft Entra ID : Conditional Access, MFA et Bonnes Pratiques

1. Introduction : l'identité comme nouveau périmètre de sécurité

Dans un monde où le périmètre réseau traditionnel a volé en éclats sous l'effet du cloud, du travail hybride et de la multiplication des terminaux, l'identité est devenue le plan de contrôle central de toute stratégie de sécurité. Microsoft Entra ID (anciennement Azure Active Directory) se positionne au coeur de cet écosystème pour plus de 720 millions d'utilisateurs dans le monde. Chaque authentification, chaque accès conditionnel, chaque jeton émis constitue une décision de sécurité critique.

Les chiffres sont éloquents : selon le rapport Microsoft Digital Defense 2025, plus de 80 % des compromissions impliquent un vecteur identité -- credential stuffing, phishing de tokens, abus de consentement OAuth, ou exploitation de comptes à privilèges non protégés. Le rapport Verizon DBIR 2025 confirme cette tendance : les identifiants volés restent le vecteur d'accès initial numéro un, devant l'exploitation de vulnérabilités et le phishing classique.

Face à cette réalité, la sécurisation d'Entra ID ne relève plus d'un simple paramétrage technique : elle constitue un programme stratégique qui engage l'architecture Zero Trust, la gouvernance des accès et la capacité de détection de l'organisation. Ce guide explore en profondeur les mécanismes de protection disponibles -- Conditional Access, MFA avancé, Identity Protection, Privileged Identity Management -- et propose une méthodologie de durcissement applicable immédiatement.

L'objectif est double : d'une part, fournir aux architectes sécurité et administrateurs M365 un référentiel technique complet ; d'autre part, proposer aux RSSI et décideurs une vision structurée des contrôles à prioriser. Chaque section intègre des recommandations concrètes, des exemples de configuration et des liens vers les articles connexes de notre base de connaissances. Nous abordons également les erreurs fréquentes observées lors de nos audits -- des configurations qui semblent sécurisées mais qui laissent des failles exploitables par un attaquant déterminé.

Point clé : La sécurisation d'Entra ID est un processus continu. Microsoft déploie en moyenne 15 à 20 nouvelles fonctionnalités de sécurité par trimestre. Rester à jour n'est pas optionnel -- c'est une obligation pour maintenir une posture défensive efficace.

2. Architecture de Microsoft Entra ID

2.1 Concepts fondamentaux : tenants, objets et annuaire

Microsoft Entra ID repose sur une architecture multi-tenant où chaque organisation dispose d'un tenant -- une instance dédiée et isolée de l'annuaire. Ce tenant constitue la frontière de confiance (trust boundary) : tous les objets qu'il contient -- utilisateurs, groupes, applications, service principals, appareils -- partagent le même espace de noms et les mêmes politiques de sécurité.

La structure hiérarchique d'un tenant Entra ID se distingue fondamentalement d'un Active Directory on-premises. Là où AD DS utilise des Unités d'Organisation (OU) et des GPO pour organiser et contrôler les objets, Entra ID s'appuie sur un modèle plat avec des Administrative Units pour la délégation, des groupes dynamiques pour l'organisation logique et des politiques Conditional Access pour le contrôle. Cette différence architecturale est souvent sous-estimée lors des migrations et peut conduire à des erreurs de modélisation des accès.

Chaque objet dans le tenant possède un Object ID (GUID unique) et un ensemble d'attributs. Les utilisateurs se voient attribuer un UserPrincipalName (UPN) qui sert d'identifiant principal. Les groupes peuvent être de type Security ou Microsoft 365, avec une membership statique ou dynamique basée sur des règles d'attributs. Les Service Principals représentent l'identité des applications au sein du tenant et constituent un vecteur d'attaque fréquemment négligé -- nous l'avons détaillé dans notre article sur les applications enregistrées Azure AD.

2.2 Protocoles d'authentification : OAuth 2.0, OIDC et SAML

Entra ID implémente trois protocoles d'authentification principaux, chacun répondant à des cas d'usage distincts :

Protocole	Usage principal	Format du jeton	Surface d'attaque
OAuth 2.0	Autorisation d'accès aux API (Graph, etc.)	Access Token (JWT)	Consent phishing, token theft, excessive permissions
OpenID Connect (OIDC)	Authentification des utilisateurs (SSO)	ID Token (JWT)	Nonce replay, redirect URI manipulation
SAML 2.0	Fédération avec apps legacy et SaaS	Assertion XML signée	Golden SAML, XML signature wrapping

Le flux OAuth 2.0 le plus courant dans l'écosystème Microsoft est le Authorization Code Flow avec PKCE (Proof Key for Code Exchange). L'utilisateur s'authentifie auprès d'Entra ID, reçoit un code d'autorisation, que l'application échange ensuite contre un access token et un refresh token. Le access token, au format JWT, contient les claims (revendications) définissant l'identité et les permissions de l'utilisateur. Sa durée de vie par défaut est de 60 à 90 minutes, configurable via les Token Lifetime Policies.

Un point critique souvent négligé : les refresh tokens. Avec une durée de vie pouvant atteindre 90 jours (et renouvelable indéfiniment dans certaines configurations), un refresh token compromis offre un accès persistant au compte. C'est pourquoi le Continuous Access Evaluation (CAE) -- que nous détaillerons dans la section Conditional Access -- est devenu un contrôle indispensable. Pour approfondir les vecteurs d'attaque sur OAuth, consultez notre article dédié sur la sécurité OAuth.

2.3 Les rôles Entra ID et le modèle RBAC

Entra ID utilise un modèle RBAC (Role-Based Access Control) avec plus de 90 rôles intégrés. Les plus critiques du point de vue sécurité sont :

• Global Administrator : accès total au tenant. Ce rôle doit être limité à 2-4 comptes maximum, protégés par MFA résistant au phishing et PIM.
• Privileged Role Administrator : peut gérer les attributions de rôles dans Entra ID. Aussi sensible que le Global Admin dans la pratique.
• Security Administrator : gère les politiques de sécurité, Identity Protection, Conditional Access. Rôle critique mais souvent surattribué.
• Application Administrator : gère toutes les inscriptions d'applications et les service principals. Peut créer des credentials pour n'importe quelle application, un vecteur d'attaque majeur.
• Exchange Administrator / SharePoint Administrator : accès aux données métier. La compromission de ces rôles donne accès à l'ensemble des communications et documents de l'organisation.

L'erreur la plus fréquente que nous observons en audit : l'attribution permanente de rôles Global Administrator à 10, 15, voire 20 comptes. Chaque compte GA permanent est une cible de choix pour un attaquant. La solution : Privileged Identity Management (PIM), que nous détaillerons en section 6.

3. Conditional Access : le moteur décisionnel Zero Trust

3.1 Le modèle Signaux - Décision - Enforcement

Le Conditional Access (CA) est le moteur décisionnel central de la sécurité Entra ID. Chaque tentative d'accès à une ressource protégée passe par l'évaluation des politiques CA, qui fonctionnent selon un modèle en trois phases :

Phase 1 -- Collecte des signaux : Au moment de l'authentification, Entra ID collecte un ensemble de signaux contextuels : l'identité de l'utilisateur (rôle, groupe, attributs), la localisation réseau (IP publique, pays, named location), le terminal utilisé (plateforme, état de conformité Intune, jonction au domaine), l'application cible (Exchange Online, SharePoint, etc.), le niveau de risque calculé par Identity Protection (risque utilisateur et risque de connexion), et le type de client (navigateur, application mobile, client legacy).

Phase 2 -- Évaluation et décision : Les politiques CA sont évaluées de manière additive. Si un accès correspond aux conditions de plusieurs politiques, tous les contrôles requis doivent être satisfaits. Il n'existe pas de politique "Allow" qui outrepasserait une politique "Block" -- le blocage est toujours prioritaire. C'est un point fondamental qui différencie CA des GPO Active Directory.

Phase 3 -- Application (Enforcement) : La décision peut être : Block (refus total), Grant (accès accordé sous conditions : MFA, terminal conforme, etc.), ou Session (accès accordé avec des restrictions de session : fréquence de ré-authentification, limitations Defender for Cloud Apps, etc.).

3.2 Les politiques Conditional Access essentielles

Sur la base de nos audits et des recommandations Microsoft, voici les politiques CA que toute organisation devrait implémenter en priorité :

Politique 1 : MFA obligatoire pour tous les utilisateurs

C'est la politique fondamentale. Elle doit cibler tous les utilisateurs (à l'exception d'un compte break-glass exclu), toutes les applications cloud, et exiger le contrôle Grant "Require multifactor authentication". Depuis 2025, Microsoft recommande d'utiliser les Authentication Strengths plutôt qu'un simple "Require MFA" pour pouvoir exiger spécifiquement des méthodes résistantes au phishing.

// Pseudo-configuration CA Policy - MFA pour tous
Assignments:
  Users: All users
  Exclude: BreakGlass-GA-01, BreakGlass-GA-02
  Cloud apps: All cloud apps
  Conditions: All platforms, All locations
  
Grant:
  Require authentication strength: "Phishing-resistant MFA"
  
Session:
  Sign-in frequency: 7 days (for low-risk)
  Continuous access evaluation: Enabled

Politique 2 : Blocage des protocoles d'authentification legacy

Les protocoles legacy (IMAP, POP3, SMTP Auth, Exchange ActiveSync legacy) ne supportent pas le MFA et constituent un vecteur d'attaque privilégié pour le password spraying et le credential stuffing. Une politique de blocage strict est indispensable :

// Pseudo-configuration CA Policy - Block Legacy Auth
Assignments:
  Users: All users (aucune exclusion)
  Cloud apps: All cloud apps
  Conditions:
    Client apps: Exchange ActiveSync, Other clients
    
Grant:
  Block access

Politique 3 : Exiger des terminaux conformes pour les applications sensibles

Pour les applications contenant des données sensibles (Exchange Online, SharePoint, Teams), l'accès devrait être limité aux terminaux gérés par Intune et conformes aux politiques de sécurité (chiffrement disque, antivirus à jour, OS patché). Cette politique combine les contrôles "Require device to be marked as compliant" et "Require Hybrid Azure AD joined device" en mode OR (l'un ou l'autre suffit) pour couvrir à la fois les terminaux cloud-only et les postes joints au domaine.

Politique 4 : Renforcement basé sur la localisation

Les Named Locations permettent de définir des réseaux de confiance (IP ranges du siège, VPN, datacenters) et des pays autorisés. Une politique efficace combine :

• Blocage des pays non autorisés : bloquer tout accès depuis les pays où l'organisation n'a aucune activité. Cela stoppe une grande partie des attaques par password spraying originaires de certaines régions.
• MFA renforcé hors réseau de confiance : exiger un MFA phishing-resistant pour tout accès ne provenant pas d'une named location de confiance.
• Attention au GPS spoofing : les locations basées sur l'IP sont plus fiables que la géolocalisation GPS. Combiner avec la conformité du terminal pour une protection plus robuste.

Politique 5 : Politiques basées sur le risque (Risk-based CA)

L'intégration avec Identity Protection permet de créer des politiques réactives qui adaptent les contrôles au niveau de risque détecté :

• Sign-in risk = Medium/High : exiger MFA phishing-resistant. Couvre les scénarios d'impossible travel, proxy anonyme, token anomalies.
• User risk = High : bloquer l'accès et forcer un changement de mot de passe. Déclenché par la détection de credentials leakées ou de comportements compromis.
• User risk = Medium : exiger MFA + changement de mot de passe sécurisé. Permet une remédiation sans bloquer totalement l'utilisateur.

3.3 Mode Report-Only et déploiement progressif

Toute nouvelle politique CA doit être déployée en mode Report-Only pendant au minimum 7 à 14 jours avant activation. Ce mode journalise les décisions sans les appliquer, permettant d'identifier les impacts potentiels via les Sign-in logs (colonne "Conditional Access" avec le statut "Report-only: Success" ou "Report-only: Failure").

Le processus de déploiement recommandé en quatre phases :

1. Conception et documentation : définir la politique, les conditions, les exclusions. Valider avec les équipes métier.
2. Report-Only (7-14 jours) : déployer en mode simulation. Analyser les logs quotidiennement. Identifier les faux positifs.
3. Activation progressive : activer d'abord pour un groupe pilote (IT, Security team), puis élargir par vagues.
4. Full enforcement : activation pour tous les utilisateurs. Maintenir un monitoring renforcé pendant 30 jours.

3.4 Continuous Access Evaluation (CAE)

Le CAE est une avancée majeure qui résout le problème fondamental des tokens : leur durée de vie statique. Traditionnellement, un access token reste valide jusqu'à son expiration (60-90 min), même si le compte est compromis et désactivé entre-temps. Le CAE crée un canal de communication en temps réel entre Entra ID et les services Microsoft (Exchange, SharePoint, Teams, Graph) pour révoquer les tokens quasi instantanément.

Les événements qui déclenchent une réévaluation CAE :

• Désactivation du compte : révocation immédiate des tokens actifs.
• Changement de mot de passe ou révocation de refresh token : force une ré-authentification.
• Changement de localisation réseau : réévaluation si l'utilisateur sort d'une named location de confiance.
• Changement de politique CA : les nouvelles conditions sont appliquées aux sessions existantes.

4. MFA avancé : au-delà du simple push notification

4.1 Évolution des méthodes MFA dans Entra ID

Le MFA (Multi-Factor Authentication) est unanimement reconnu comme l'un des contrôles de sécurité les plus efficaces : Microsoft estime qu'il bloque 99,9 % des attaques automatisées sur les comptes. Cependant, toutes les méthodes MFA ne se valent pas face aux attaquants sophistiqués. L'évolution des techniques de phishing avancé (adversary-in-the-middle, device code phishing) a rendu certaines méthodes MFA vulnérables.

Entra ID supporte un spectre large de méthodes d'authentification, classées par niveau de résistance :

Méthode	Facteur	Résistant au phishing	Recommandation
Passkeys FIDO2	Possession + Biométrie	Oui	Privilégier pour les admins et comptes sensibles
Windows Hello for Business	Possession + Biométrie/PIN	Oui	Standard pour les postes Windows gérés
Certificate-based Auth (CBA)	Possession (certificat)	Oui	Excellente pour les environnements PKI existants
Authenticator + Number Matching	Possession + Connaissance	Partiel	Acceptable pour les utilisateurs standard
TOTP (Authenticator code)	Possession + Connaissance	Non	Vulnérable au phishing AitM -- à éviter si possible
SMS / Appel vocal	Possession	Non	À proscrire -- vulnérable au SIM swapping

4.2 Microsoft Authenticator : number matching et contexte additionnel

Depuis mai 2023, Microsoft a rendu le number matching obligatoire pour toutes les notifications push Authenticator. Cette mesure combat directement la fatigue MFA (MFA bombing) -- une technique où l'attaquant déclenche des dizaines de notifications push jusqu'à ce que l'utilisateur, excédé, accepte par erreur. Avec le number matching, l'utilisateur doit saisir le nombre à deux chiffres affiché sur l'écran de connexion, ce qui requiert une interaction active avec le flux d'authentification légitime.

Le contexte additionnel (additional context) enrichit la notification Authenticator avec des informations sur la demande : l'application qui requiert l'authentification et la localisation approximative de la requête. Cela permet à l'utilisateur de détecter une demande suspecte (par exemple, une connexion depuis un pays étranger alors qu'il est au bureau).

Malgré ces améliorations, les notifications push Authenticator restent vulnérables aux attaques adversary-in-the-middle (AitM) de type EvilGinx, Modlishka ou Muraena. Un proxy inverse intercepte la session et relaie les interactions MFA en temps réel. Le number matching ne protège pas contre ce scénario car le proxy contrôle le flux complet. C'est pourquoi les passkeys FIDO2 représentent la prochaine étape indispensable.

4.3 Passkeys FIDO2 : le MFA résistant au phishing

Les passkeys basées sur le standard FIDO2/WebAuthn offrent une résistance native au phishing grâce à la liaison à l'origine (origin binding). La clé cryptographique est liée au domaine exact du service (par exemple, login.microsoftonline.com). Même si l'utilisateur clique sur un lien de phishing et arrive sur un site imitant la page de connexion Microsoft, la passkey refusera de s'activer car le domaine ne correspond pas. C'est la meilleure protection disponible contre les attaques AitM. Pour une analyse approfondie des limites et contournements possibles, consultez notre article sur le bypass FIDO2 et passkeys.

Entra ID supporte trois types de passkeys :

• Clés de sécurité matérielles (YubiKey, Feitian, etc.) : recommandées pour les administrateurs et comptes à haut privilège. Résistantes à la compromission du terminal.
• Passkeys liées à la plateforme (platform authenticators) : Windows Hello, Touch ID/Face ID, Android biometrics. Idéales pour le déploiement à grande échelle sur les terminaux gérés.
• Passkeys synchronisées (synced passkeys) : synchronisées via iCloud Keychain, Google Password Manager, ou Microsoft Authenticator. Plus pratiques mais avec un modèle de confiance élargi (la sécurité dépend du compte Apple/Google).

4.4 Temporary Access Pass (TAP) et scénarios d'onboarding

Le Temporary Access Pass résout un dilemme classique : comment enregistrer une méthode MFA phishing-resistant quand l'utilisateur ne peut pas encore s'authentifier avec MFA ? Le TAP est un code temporaire (durée configurable, de 10 minutes à 30 jours) avec un nombre d'utilisations limité (par défaut une seule utilisation).

Les cas d'usage principaux :

• Onboarding d'un nouvel employé : le service IT génère un TAP qui permet au nouvel utilisateur de s'authentifier une première fois et d'enregistrer sa passkey FIDO2 ou son Windows Hello.
• Récupération après perte de device : lorsque l'utilisateur a perdu toutes ses méthodes MFA (téléphone et clé de sécurité), un TAP permet la réinitialisation sans compromettre la sécurité.
• Migration vers le passwordless : TAP comme pont temporaire pendant la transition des comptes vers l'authentification sans mot de passe.

4.5 Authentication Strengths : piloter la granularité du MFA

Les Authentication Strengths (forces d'authentification) permettent de définir précisément quelles combinaisons de méthodes MFA sont acceptables pour chaque politique Conditional Access. Trois niveaux prédéfinis existent :

• MFA strength : accepte toute combinaison de deux facteurs (Authenticator push, TOTP, SMS, etc.).
• Passwordless MFA strength : requiert des méthodes sans mot de passe (Windows Hello, Authenticator passwordless, passkeys FIDO2).
• Phishing-resistant MFA strength : le niveau le plus élevé, restreint aux méthodes résistantes au phishing (FIDO2, Windows Hello for Business, Certificate-based authentication).

Il est possible de créer des Authentication Strengths personnalisées pour des scénarios spécifiques. Par exemple, pour les administrateurs Global Admin, vous pouvez créer une force qui n'accepte que les clés FIDO2 matérielles d'un fabricant spécifique (en filtrant par AAGUID), excluant ainsi les passkeys synchronisées ou les platform authenticators potentiellement moins sécurisés dans votre contexte.

// Exemple de requête Graph pour créer une Authentication Strength personnalisée
POST /beta/policies/authenticationStrengthPolicies
{
  "displayName": "Admin FIDO2 Hardware Only",
  "description": "Clés FIDO2 matérielles uniquement pour les admins",
  "allowedCombinations": [
    "fido2"
  ],
  "combinationConfigurations": [{
    "@odata.type": "#microsoft.graph.fido2CombinationConfiguration",
    "allowedAAGUIDs": [
      "cb69481e-8ff7-4039-93ec-0a2729a154a8",  // YubiKey 5
      "ee882879-721c-4913-9775-3dfcce97072a"   // YubiKey 5 NFC
    ]
  }]
}

5. Protection des identités : détecter et remédier automatiquement

5.1 Entra ID Identity Protection : fonctionnement et détections

Entra ID Identity Protection est le moteur d'analyse comportementale et de détection des risques intégré à Entra ID. Il s'appuie sur les signaux de plus de 720 millions d'utilisateurs et des trillions d'authentifications quotidiennes pour alimenter ses modèles de machine learning. Chaque authentification est évaluée en temps réel pour déterminer un niveau de risque de connexion (sign-in risk) et un niveau de risque utilisateur (user risk).

Le sign-in risk évalue la probabilité qu'une tentative de connexion spécifique ne soit pas légitime. Les détections incluent :

• Impossible travel : connexion depuis deux localisations géographiquement incompatibles dans un laps de temps trop court (par exemple, Paris à 14h puis Tokyo à 14h30). Attention : les VPN peuvent générer des faux positifs, d'où l'importance de déclarer vos VPN en named locations.
• Anonymous IP address : connexion via un proxy anonyme, un réseau Tor ou un VPN commercial connu. Détection utile mais peut impacter les utilisateurs légitimes utilisant un VPN personnel.
• Anomalous token : détection de tokens avec des caractéristiques inhabituelles (durée de vie anormale, claims modifiés). Cible les attaques de vol et modification de tokens.
• Token issuer anomaly : le token a été émis par un fournisseur d'identité inhabituel, indiquant potentiellement une compromission de la fédération (Golden SAML).
• Unfamiliar sign-in properties : combinaison inhabituelle de terminal, navigateur et localisation pour cet utilisateur spécifique.
• Malicious IP address : l'adresse IP est connue pour une activité malveillante (botnets, serveurs C2).
• Suspicious browser : détection de navigateurs headless ou de frameworks d'automatisation (Selenium, Playwright) utilisés pour des attaques automatisées.

Le user risk évalue la probabilité qu'un compte soit compromis. Ce risque persiste entre les sessions et s'accumule. Les détections incluent :

• Leaked credentials : les identifiants de l'utilisateur ont été trouvés dans une fuite de données (dark web, paste sites, bases de données compromises). Microsoft achète et analyse activement ces bases.
• Password spray : détection de tentatives de password spraying ciblant le compte (multiples échecs depuis des IP différentes avec un pattern caractéristique).
• Anomalous user activity : le compte présente un comportement inhabituel (accès à des ressources jamais consultées, horaires anormaux, volume d'actions élevé).
• Possible attempt to access Primary Refresh Token (PRT) : tentative d'accès au PRT stocké sur le terminal, un vecteur d'attaque avancé permettant de détourner la session SSO complète.
• Suspicious API traffic : utilisation anormale des API Microsoft Graph depuis le compte, suggérant une exploitation post-compromission.

5.2 Politiques de risque et auto-remédiation

La puissance d'Identity Protection réside dans sa capacité d'auto-remédiation. En couplant les détections de risque aux politiques Conditional Access, l'organisation peut automatiser la réponse aux compromissions sans intervention humaine :

Scénario de risque	Action automatique	Impact utilisateur
Sign-in risk = Medium	Exiger MFA	L'utilisateur complète son MFA et continue. Si c'est un attaquant sans le second facteur, il est bloqué.
Sign-in risk = High	Exiger MFA phishing-resistant	Seules les clés FIDO2 / WHfB sont acceptées. Bloque les attaques AitM.
User risk = Medium	Exiger MFA + changement de mot de passe	L'utilisateur doit prouver son identité via MFA puis changer son mot de passe.
User risk = High	Bloquer l'accès	Le compte est bloqué jusqu'à intervention d'un administrateur qui enquête et remédie manuellement.

5.3 Investigation et tuning des détections

Identity Protection nécessite un tuning continu pour réduire les faux positifs sans affaiblir la détection. Les actions clés :

• Déclarer les Named Locations : les IP de VPN, les plages des bureaux et des datacenters doivent être déclarées comme trusted locations pour éviter les alertes "Unfamiliar sign-in properties" et "Impossible travel" sur les accès légitimes via VPN.
• Exclure les service accounts : les comptes de service utilisés pour l'automatisation (Graph API, PowerShell) peuvent générer des alertes "Anomalous token" ou "Suspicious API traffic". Utilisez des managed identities quand c'est possible, ou excluez ces comptes des politiques de risque utilisateur (tout en les surveillant par d'autres moyens).
• Revue régulière des utilisateurs à risque : planifiez une revue hebdomadaire du rapport "Risky users" pour investiguer les comptes en état "At risk" et confirmer ou dismiss les détections.
• Corrélation avec le SIEM : exportez les détections Identity Protection vers votre SIEM (Sentinel, Splunk, etc.) pour corréler avec d'autres sources de données (logs réseau, EDR, proxy).

6. Privileged Identity Management (PIM) : le Just-in-Time pour les admins

6.1 Le principe du moindre privilège appliqué aux rôles Entra ID

Privileged Identity Management (PIM) est la réponse de Microsoft au problème des privilèges permanents. Le principe est simple mais puissant : aucun utilisateur ne devrait avoir un rôle administrateur actif en permanence. Au lieu de cela, les administrateurs sont rendus eligible pour un rôle et doivent l'activer explicitement quand ils en ont besoin, pour une durée limitée.

Ce modèle Just-in-Time (JIT) réduit drastiquement la fenêtre d'exposition. Un attaquant qui compromet le compte d'un administrateur Global Admin "eligible" ne dispose d'aucun privilège tant que le rôle n'est pas activé. Et l'activation peut être protégée par des contrôles additionnels : MFA, justification, approbation par un pair, notification aux équipes sécurité.

6.2 Configuration recommandée de PIM

Pour les rôles les plus critiques (Global Administrator, Privileged Role Administrator, Security Administrator), voici la configuration PIM recommandée :

Paramètre	Global Admin	Security Admin	Autres rôles
Durée d'activation max	1 heure	4 heures	8 heures
MFA à l'activation	Oui (phishing-resistant)	Oui	Oui
Justification requise	Oui (ticket obligatoire)	Oui	Recommandé
Approbation requise	Oui (par un autre GA)	Optionnel	Non
Notification à l'activation	Admins + SOC	Admins	Admins
Eligible max duration	6 mois (renouvellement)	1 an	1 an

6.3 Access Reviews : la gouvernance continue

Les Access Reviews (revues d'accès) complètent PIM en ajoutant une couche de gouvernance périodique. Elles permettent de vérifier régulièrement que les attributions de rôles et d'accès sont toujours justifiées. Les configurations recommandées :

• Revue des rôles PIM : tous les 90 jours pour les rôles GA, tous les 180 jours pour les autres rôles. Les reviewers sont les propriétaires de rôle ou les managers directs.
• Revue des groupes d'accès : trimestrielle pour les groupes donnant accès aux données sensibles (sites SharePoint confidentiels, boîtes aux lettres partagées de direction).
• Auto-apply des résultats : configurer la suppression automatique des accès non confirmés après la période de revue, avec un rappel préalable de 3 jours au reviewer.
• Revue des guest accounts : mensuelle pour les comptes B2B invités. Les utilisateurs externes inactifs depuis plus de 90 jours devraient être signalés pour suppression.

Le couple PIM + Access Reviews forme le socle de la gouvernance des identités à privilèges. Sans ces mécanismes, l'accumulation progressive de privilèges (privilege creep) est inévitable, et chaque compte sur-privilégié est un point d'entrée potentiel pour un attaquant. L'audit régulier de ces configurations est un point clé de nos missions d'évaluation M365.

7. Monitoring et détection : surveiller l'identité en temps réel

7.1 Sign-in logs et audit logs : les deux piliers

La visibilité sur les événements d'authentification est le fondement de toute capacité de détection. Entra ID produit deux types de journaux essentiels :

Sign-in logs : chaque tentative d'authentification est journalisée avec un détail remarquable -- utilisateur, application, terminal, localisation, résultat (succès/échec), politiques CA évaluées, méthode MFA utilisée, niveau de risque. Ces logs sont le premier endroit où investiguer en cas de suspicion de compromission. La rétention par défaut est de 30 jours (P1/P2), extensible à 2 ans avec le Diagnostic Settings vers un Log Analytics Workspace ou un Storage Account.

Audit logs : tracent les modifications d'objets et de configuration dans le tenant -- création/suppression d'utilisateurs, changements de rôles, modification de politiques CA, consentement d'applications, modifications de groupes. C'est ici que vous détecterez les actions de persistance d'un attaquant (ajout d'un rôle, création d'un service principal, modification des redirect URIs d'une application).

7.2 Intégration SIEM et alertes critiques

L'export des logs Entra ID vers un SIEM est indispensable pour une détection efficace. Microsoft Sentinel offre l'intégration la plus native via le connecteur Entra ID (anciennement Azure AD), mais des connecteurs existent pour Splunk, QRadar, Elastic, et tout SIEM compatible CEF/Syslog.

Les règles de détection critiques à implémenter en priorité :

• Connexion réussie d'un compte break-glass : alerte CRITIQUE immédiate. Toute utilisation d'un break-glass en dehors d'un test planifié doit déclencher une investigation.
• Attribution de rôle Global Administrator (permanent) : alerte HAUTE. Doit passer par PIM -- une attribution permanente directe est suspecte.
• Ajout de credentials à un service principal : alerte HAUTE. Un attaquant ajoute souvent un secret ou un certificat à une application existante pour maintenir son accès.
• Modification d'une politique Conditional Access : alerte MOYENNE. Vérifier que le changement est autorisé et documenté.
• Consentement admin-wide à une application : alerte HAUTE. Le consent phishing est un vecteur d'attaque majeur documenté dans notre article sur les applications enregistrées Azure AD.
• Volume anormal d'échecs de connexion depuis une même IP : alerte MOYENNE. Indicateur de password spraying.
• Désactivation du MFA pour un utilisateur à privilèges : alerte HAUTE. Peut indiquer une tentative de préparation d'attaque.
• Création d'une règle de transfert Exchange ou d'une règle inbox : alerte MOYENNE. Technique classique de BEC (Business Email Compromise).

// Exemple de requête KQL pour Sentinel - Détection d'attribution Global Admin
AuditLogs
| where TimeGenerated > ago(1h)
| where OperationName == "Add member to role"
| where TargetResources[0].modifiedProperties[0].newValue 
    contains "Global Administrator"
| where Result == "success"
| project TimeGenerated, InitiatedBy.user.userPrincipalName, 
    TargetResources[0].userPrincipalName, OperationName
| sort by TimeGenerated desc

7.3 Workbooks et tableaux de bord

Microsoft fournit des Workbooks prédéfinis dans le portail Entra ID et dans Sentinel pour visualiser la posture de sécurité identitaire. Les tableaux de bord essentiels à surveiller quotidiennement :

• Sign-in failure analysis : volume et motifs des échecs d'authentification. Un pic soudain d'échecs "Invalid password" peut indiquer un password spray en cours.
• Conditional Access insights : nombre de connexions bloquées par politique, connexions en report-only qui auraient été bloquées, méthodes MFA les plus utilisées.
• Risky users / Risky sign-ins : tableau de bord Identity Protection avec les comptes à risque nécessitant une investigation ou une remédiation.
• Application consent audit : historique des consentements accordés aux applications, avec focus sur les consentements admin-wide et les applications à permissions élevées (Mail.ReadWrite, Directory.ReadWrite.All, etc.).

8. Checklist de durcissement : 20 points essentiels

Cette checklist synthétise les 20 contrôles de sécurité les plus importants pour durcir un tenant Entra ID. Chaque point est classé par priorité (P1 = critique, P2 = important, P3 = recommandé) et par effort de mise en oeuvre.

Détaillons les points les plus fréquemment manqués lors de nos audits :

Point 5 : comptes break-glass

Plus de 40 % des organisations que nous auditons n'ont pas de procédure break-glass documentée et testée. En cas de panne d'Entra ID, de corruption des politiques CA, ou de compromission des comptes admins, l'absence de break-glass peut entraîner un verrouillage total du tenant -- un scénario catastrophique qui peut prendre des jours à résoudre avec le support Microsoft.

Point 12 : consentement des applications

Par défaut, les utilisateurs peuvent consentir à des applications OAuth demandant des permissions déléguées à faible impact. Cependant, le consent phishing exploite cette capacité pour obtenir un accès persistant aux boîtes mail et fichiers. La recommandation : configurer un Admin Consent Workflow qui redirige toutes les demandes de consentement vers une équipe d'approbation, tout en maintenant une liste d'applications pré-approuvées pour minimiser la friction.

Point 16 : audit des service principals

Les service principals sont le point aveugle numéro un de la plupart des tenants. Un tenant M365 typique contient des centaines de service principals, dont beaucoup avec des permissions excessives (Directory.ReadWrite.All, Mail.ReadWrite) accordées il y a des mois ou des années et jamais revues. Chaque service principal avec un secret ou un certificat est un vecteur d'accès potentiel qui ne nécessite pas de MFA. Planifiez un audit complet avec Get-MgServicePrincipal et Get-MgServicePrincipalAppRoleAssignment.

Point 17 : self-service app registration

Par défaut, tout utilisateur peut enregistrer des applications dans le tenant. Cela signifie qu'un utilisateur compromis peut créer une application, lui ajouter des credentials, et l'utiliser comme backdoor persistante. Désactivez cette capacité via Users can register applications = No dans les User Settings, et déléguez la création d'applications à un rôle dédié (Application Developer).

9. Conclusion : la sécurité identitaire comme programme continu

La sécurisation de Microsoft Entra ID n'est pas un projet ponctuel avec une date de fin -- c'est un programme continu qui doit évoluer au rythme des menaces et des fonctionnalités. Les attaquants adaptent constamment leurs techniques : le password spraying cède la place au AitM phishing, le vol de mots de passe se transforme en vol de tokens, les attaques manuelles deviennent des campagnes automatisées alimentées par l'IA.

Les organisations qui réussissent leur posture de sécurité identitaire partagent trois caractéristiques :

1. Une approche layered : elles ne comptent pas sur un seul contrôle mais sur la combinaison Conditional Access + MFA phishing-resistant + Identity Protection + PIM + monitoring. Chaque couche compense les faiblesses potentielles des autres.
2. Une gouvernance active : les Access Reviews sont réellement effectuées, les alertes SIEM sont investiguées, les politiques CA sont régulièrement révisées. La dette technique de sécurité est traitée avec la même rigueur que la dette technique applicative.
3. Une culture de la sécurité : les utilisateurs comprennent pourquoi le MFA est nécessaire, les administrateurs savent utiliser PIM, et le RSSI a la visibilité et le soutien de la direction pour implémenter les contrôles nécessaires.

En implémentant les 20 points de la checklist présentée dans cet article, et en s'appuyant sur les mécanismes de détection et de réponse automatique d'Identity Protection, votre organisation sera significativement mieux protégée contre les 80 % de compromissions qui passent par l'identité. Le chemin vers le Zero Trust commence ici -- par la maîtrise de votre plan de contrôle identitaire.