Identité Azure : Quand MFA Ne Suffit Pas

Qu'est-ce que la sécurité des identités Azure ?

La sécurité des identités Azure désigne l'ensemble des contrôles qui protègent les comptes Microsoft Entra ID, les rôles à privilèges, les méthodes d'authentification, l'accès aux applications et les sessions d'administration à travers Microsoft 365, Azure et les applications SaaS connectées. C'est la porte d'entrée du tenant. Si la couche d'identité est faible, un attaquant n'a pas forcément besoin d'exploiter un serveur : un mot de passe volé, un flux d'authentification hameçonnable, une exception mal maîtrisée ou une session à privilèges peuvent suffire.

La MFA fait partie de la réponse, mais elle ne constitue pas à elle seule une stratégie complète de sécurité des identités Azure. Un tenant a également besoin d'une couverture Conditional Access, de méthodes d'authentification robustes pour les rôles à privilèges, d'une réponse basée sur le risque, de contrôles sur les accès d'urgence, d'une gouvernance des applications, et d'une validation que les stratégies s'appliquent réellement aux connexions en conditions réelles.

Les deux défaillances de base qui reviennent le plus souvent sont simples :

des comptes à privilèges sans authentification forte imposée
Security Defaults désactivé sans couverture Conditional Access équivalente

Ces défaillances créent un écart entre ce que les administrateurs pensent être protégé et ce que Microsoft Entra ID applique réellement.

Security Defaults face à Conditional Access

Security Defaults constitue le socle de protections intégrées par défaut de Microsoft, destiné aux organisations qui ont besoin d'un point de départ simple. La documentation Microsoft présente Security Defaults comme adapté aux organisations qui souhaitent améliorer leur sécurité sans savoir par où commencer, ainsi qu'aux organisations utilisant le niveau gratuit de Microsoft Entra ID.

Security Defaults impose à tous les utilisateurs de s'enregistrer pour l'authentification multifacteur, exige des administrateurs qu'ils effectuent une MFA à chaque connexion, invite les autres utilisateurs à effectuer une MFA lorsque Microsoft le juge nécessaire, bloque les protocoles d'authentification hérités, bloque le flux de code d'appareil, et exige la MFA pour les activités à privilèges comme l'accès au portail Azure, au centre d'administration Microsoft Entra, à Azure PowerShell et à Azure CLI. Ce dispositif est volontairement simple et non personnalisable : il s'agit d'un interrupteur activé ou désactivé, sans possibilité de ciblage ni d'exception.

Conditional Access est le moteur de stratégies le plus flexible. Les organisations disposant d'une licence Microsoft Entra ID P1 ou P2 et de besoins plus complexes ont généralement besoin de Conditional Access pour cibler des applications, l'état des appareils, les emplacements, les conditions de risque, les niveaux d'authentification, les contrôles de session et des exceptions ciblées.

L'état dangereux est celui de la transition : Security Defaults est désactivé, mais Conditional Access n'offre pas encore une protection équivalente ou supérieure. Les recommandations de Microsoft pour abandonner Security Defaults indiquent que les organisations doivent activer immédiatement des stratégies Conditional Access pour protéger l'organisation après la désactivation de Security Defaults. Microsoft déploie désormais des stratégies Conditional Access gérées par Microsoft pour couvrir cette transition : bloquer l'authentification héritée, exiger l'authentification multifacteur pour la gestion Azure, exiger l'authentification multifacteur pour les administrateurs, et exiger l'authentification multifacteur pour tous les utilisateurs. Il faut noter leur état par défaut. Microsoft les crée en mode Rapport seul (Report-only), qui évalue et journalise sans rien appliquer, puis les active au plus tard 30 jours plus tard si elles restent dans cet état. Avant ce basculement, une liste de stratégies qui semble complète n'applique en réalité rien — le même piège que celui décrit dans Mode rapport seul de l'accès conditionnel et exclusions obsolètes.

Pourquoi la MFA seule ne suffit pas

La MFA améliore la résistance à la compromission par simple mot de passe, mais toutes les méthodes de MFA n'offrent pas le même niveau de protection. Un tenant peut rester exposé si :

des administrateurs sont exclus des stratégies Conditional Access du tenant pour des raisons de dépannage d'urgence
Conditional Access ne s'applique qu'à certaines applications sélectionnées alors que les portails d'administration restent accessibles
des utilisateurs à privilèges utilisent des méthodes hameçonnables alors que des méthodes plus robustes sont réalisables
des comptes break-glass existent mais ne sont pas surveillés à chaque connexion
l'authentification héritée ou des clients plus anciens restent disponibles pour certains flux de travail
l'enregistrement et la récupération des méthodes d'authentification sont faiblement contrôlés
les sessions et jetons d'actualisation restent valides après un événement à risque

Une de ces failles a depuis été comblée au niveau de la plateforme, ce qui change la manière dont il faut lire le problème des exceptions. Microsoft applique désormais la MFA sur les connexions Azure indépendamment de la configuration du tenant : depuis octobre 2024 pour le portail Azure, le centre d'administration Microsoft Entra et le centre d'administration Microsoft Intune, depuis février 2025 pour le centre d'administration Microsoft 365, et depuis le 1er octobre 2025 pour Azure CLI, Azure PowerShell, l'application mobile Azure, les outils IaC et les points de terminaison REST d'Azure Resource Manager pour les opérations de création, de modification et de suppression. Cette application prime sur l'intention du tenant : Microsoft indique que les exceptions et exclusions Conditional Access ne s'y appliquent plus, et qu'elle couvre tous les comptes utilisateur, comptes break-glass inclus. Elle ne s'étend pas à Microsoft Graph, qui reste régi par vos propres stratégies, et Microsoft ne l'applique pas actuellement dans Azure US Government ni dans les autres clouds souverains. La MFA au niveau plateforme relève le plancher sur une courte liste de surfaces d'administration. Elle ne donne pas au tenant une couverture Conditional Access, une robustesse de méthode, ni des conditions liées aux appareils et au risque.

Les niveaux d'authentification Microsoft Entra (authentication strengths) existent parce que la robustesse de la méthode compte. Un niveau d'authentification Conditional Access peut exiger des combinaisons de méthodes spécifiques, y compris des options résistantes au hameçonnage comme les clés de sécurité passkey/FIDO2 ou l'authentification par certificat, là où elle est déployée et prise en charge.

La chaîne d'attaque

Étape 1 - Trouver le chemin d'identité faible

Un attaquant recherche des comptes pouvant s'authentifier sans contrôles robustes : comptes administrateurs sans MFA, comptes exclus de Conditional Access, comptes obsolètes, comptes d'urgence non surveillés, ou applications disposant de permissions étendues.

Étape 2 - Obtenir un identifiant ou une session valide

L'accès initial peut provenir de la réutilisation de mot de passe, du hameçonnage d'identifiants, du vol de jeton, d'un abus du support technique, ou d'un appareil compromis. La technique précise varie, mais la question de contrôle d'identité reste la même : le tenant exige-t-il une méthode d'authentification plus robuste, un appareil conforme, une connexion à faible risque, ou un chemin d'administration approuvé avant d'accorder l'accès ?

Étape 3 - Atteindre une surface d'administration

Si le compte peut atteindre le portail Azure, le centre d'administration Microsoft Entra, les portails d'administration Microsoft 365, Microsoft Graph ou PowerShell sans les contrôles prévus, le tenant présente un écart entre stratégie prévue et stratégie réellement appliquée.

Étape 4 - Préserver l'accès

Une fois à l'intérieur, l'attaquant peut tenter d'ajouter une méthode d'authentification, de créer un nouvel utilisateur, d'attribuer un rôle, d'enregistrer une application, d'ajouter un identifiant à un principal de service, ou d'affaiblir une stratégie Conditional Access. Ces actions doivent être traitées comme des événements d'audit à fort signal pour les identités à privilèges.

Détection

Signaux de connexion et de stratégie

Examinez les journaux de connexion Microsoft Entra et les résultats Conditional Access à la recherche de :

connexions à privilèges réussies pour lesquelles la MFA n'a pas été exigée alors qu'elle aurait dû l'être
connexions dont la méthode d'authentification ne satisfait pas le niveau de robustesse attendu
accès administrateur depuis des appareils non gérés ou des emplacements inattendus
connexions à risque moyen ou élevé s'étant achevées avec succès
échecs répétés suivis d'une réussite pour un compte administrateur
connexions de comptes d'urgence
utilisation de clients ou protocoles hérités là où ils devraient être bloqués

Signaux dans les journaux d'audit

Surveillez les changements du tenant susceptibles d'affaiblir les contrôles d'identité :

Domaine du changement	Pourquoi c'est important
Mise à jour d'une stratégie Conditional Access	Peut supprimer des exigences de MFA, d'appareil, de risque ou d'application
Mise à jour d'une exclusion Conditional Access	Peut créer un chemin de contournement discret
Modification d'une méthode d'authentification	Peut faciliter la récupération de compte ou la persistance
Attribution de rôle	Peut transformer un seul compte en contrôle du tenant
Modification d'un identifiant d'application	Peut créer une persistance durable basée sur une application
Modification de Security Defaults	Peut supprimer la protection de base si elle n'est pas remplacée

Limites de la détection

Ne déclenchez pas d'alerte sur la seule existence de la MFA. Alertez sur les résultats effectifs. La question n'est pas « le tenant dispose-t-il d'une stratégie MFA ? » mais « cette connexion, à cette ressource, par cette identité, a-t-elle satisfait le contrôle requis ? » Les résultats Conditional Access, les détails d'authentification, le niveau de risque, le rôle utilisateur, l'application, l'appareil et l'emplacement comptent tous.

Remédiation

Le socle sûr consiste soit en Security Defaults pour les tenants simples, soit en une conception Conditional Access complète pour les tenants plus complexes. Se retrouver sans aucun des deux est l'échec évitable.

1. Réactiver Security Defaults ou le remplacer immédiatement

Si le tenant ne dispose pas d'une conception Conditional Access mature, activez Security Defaults. Si l'organisation utilise Conditional Access, documentez le socle de remplacement avant de désactiver Security Defaults et testez-le face à des scénarios de connexion réels.

Au minimum, la conception de remplacement doit couvrir les utilisateurs à privilèges, la gestion Azure, les surfaces d'administration Microsoft 365, les connexions à risque et l'exposition à l'authentification héritée.

2. Exiger une authentification forte pour les rôles à privilèges

Pour les utilisateurs à privilèges standards, exigez la MFA et envisagez des méthodes plus robustes pour les rôles les plus sensibles. Utilisez les niveaux d'authentification Conditional Access pour exiger des méthodes résistantes au hameçonnage là où l'environnement le permet.

Les populations de rôles à forte valeur courantes incluent :

Administrateur général (Global Administrator)
Administrateur de rôle privilégié (Privileged Role Administrator)
Administrateur Conditional Access
Administrateur de la sécurité
Administrateur d'application
Administrateur d'application cloud
Administrateur Exchange et Administrateur SharePoint dans les tenants fortement orientés Microsoft 365

3. Gérer séparément les comptes d'accès d'urgence

Les comptes d'urgence sont nécessaires à la résilience. Microsoft recommande au moins deux comptes d'accès d'urgence cloud uniquement sur le domaine *.onmicrosoft.com, ni fédérés ni synchronisés depuis un environnement sur site. Ces comptes ne doivent pas être utilisés comme identités administrateur du quotidien, et leur modèle de contrôle doit éviter les dépendances susceptibles de faire défaut précisément lors de l'urgence qu'ils sont censés résoudre.

L'authentification résistante au hameçonnage sur ces comptes n'est plus optionnelle. L'application obligatoire de la MFA vaut aussi pour les comptes break-glass, si bien qu'un compte d'urgence protégé par simple mot de passe est désormais un verrouillage en attente. La recommandation actuelle de Microsoft consiste à enregistrer l'une des deux méthodes sans mot de passe qui satisfont l'exigence obligatoire de MFA — une passkey (FIDO2), que Microsoft recommande, ou l'authentification par certificat là où une PKI existe déjà — et à conserver une méthode différente de celle utilisée par vos comptes administrateur habituels. Excluez ces comptes des stratégies Conditional Access qui bloquent ou restreignent la connexion (les stratégies en mode rapport seul n'ont besoin d'aucune exclusion), stockez les identifiants dans des emplacements sécurisés distincts, maintenez l'attribution Administrateur général en permanence active plutôt qu'éligible dans PIM, alertez à chaque connexion, et validez ces comptes au moins tous les 90 jours. Si un compte d'urgence se connecte, l'équipe de sécurité doit le savoir.

4. Supprimer les exceptions inutiles

Passez en revue chaque utilisateur, groupe, emplacement, application et condition d'appareil exclus dans Conditional Access. Les exceptions créées pendant un dépannage deviennent souvent permanentes. Chaque exception doit avoir un responsable, une raison, une date d'expiration ou une fréquence de révision, et une surveillance compensatoire.

5. Associer la sécurité des identités à une réponse basée sur le risque

Security Defaults et la MFA ne remplacent pas une réponse basée sur le risque dans les tenants plus vastes. Utilisez les signaux de risque de Microsoft Entra ID Protection via les conditions de risque de Conditional Access pour exiger une authentification renforcée, une réauthentification, une remédiation du risque ou un blocage lorsqu'un risque est détecté. La recommandation actuelle de Microsoft est d'exiger une remédiation du risque en cas de risque utilisateur élevé, et une MFA associée à une fréquence de connexion « à chaque fois » en cas de risque de connexion moyen ou élevé. Construisez ces mécanismes sous forme de stratégies Conditional Access plutôt que dans le volet ID Protection : les anciennes stratégies de risque configurées au sein de Microsoft Entra ID Protection seront retirées le 1er octobre 2026, les tenants qui les utilisent encore doivent donc recréer les équivalents dans Conditional Access et désactiver les anciennes.

Validation après modification des stratégies

Validez le chemin de stratégie effectif plutôt que de faire confiance à des captures d'écran de configuration :

testez une connexion d'utilisateur à privilèges au portail Azure et confirmez que le contrôle attendu est exigé
testez une connexion d'utilisateur à privilèges à Microsoft Graph ou PowerShell le cas échéant
confirmez que ce même compte n'est pas exclu via un autre groupe, emplacement, application ou condition d'appareil
examinez les journaux de connexion pour confirmer le résultat Conditional Access et les détails de la méthode d'authentification
validez l'alerting des comptes d'urgence en examinant le chemin d'alerte réel, sans présumer qu'il existe
examinez les connexions à risque et confirmez que les stratégies basées sur le risque s'appliqueraient
confirmez que l'authentification héritée est bloquée là où Security Defaults ou Conditional Access devraient la bloquer
vérifiez si les exigences de niveau d'authentification ne sont satisfaites que par les méthodes prévues

Un contrôle qui existe mais ne s'applique pas aux connexions que les attaquants peuvent utiliser n'est pas un contrôle de sécurité des identités.

Comment EtcSec détecte cela

EtcSec audite les contrôles d'identité Azure à chaque analyse de tenant. Les trois vérifications ci-dessous se situent toutes au niveau du tenant : elles établissent si le contrôle existe, ce qui est la condition préalable à la question par connexion qui fait l'objet de cet article.

MFA_NOT_ENFORCED_ADMINS signale un tenant dans lequel aucune stratégie Conditional Access activée ne cible les rôles d'annuaire avec un contrôle d'octroi MFA.

AZ_SECURITY_DEFAULTS_DISABLED signale un tenant dont l'interrupteur Security Defaults est désactivé. Vérifier si un socle Conditional Access équivalent l'a remplacé fait l'objet de la revue distincte décrite dans cet article.

CA_NO_MFA_REQUIREMENT signale un tenant dans lequel aucune stratégie Conditional Access activée n'exige la MFA dans ses contrôles d'octroi, quels qu'ils soient.

La question qui compte n'est pas de savoir si un tenant possède des stratégies sur le papier. C'est de savoir si les connexions à privilèges font réellement face aux contrôles prévus, et si les sessions à risque déclenchent une réponse.

Contrôles associés

Ce contrôle doit être examiné conjointement avec Azure Identity Protection : bloquer les identifiants divulgués, Accès privilégié Azure : trop d'administrateurs généraux, Durcissement du tenant Azure : corriger les paramètres par défaut peu sûrs, Comptes invités Azure : la surface d'attaque oubliée de votre tenant, et Enregistrements d'applications Azure : des applications sur-privilégiées dans le tenant. Une posture MFA faible s'aggrave nettement lorsque ce même tenant présente aussi des privilèges administrateur permanents, un accès invité étendu, des applications à risque, ou une réponse au risque insuffisante.

Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas