Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués

Qu'est-ce qu'Azure Identity Protection ?

Microsoft Entra ID Identity Protection est une couche de sécurité basée sur le risque qui évalue continuellement les signaux de connexion et de risque utilisateur pour détecter la compromission de credentials, le voyage impossible, les patterns d'authentification anormaux et les outils d'attaquants — en temps réel.

Sans politiques Identity Protection, ces signaux sont visibles dans les logs mais ne génèrent aucune réponse automatisée. Un attaquant utilisant un credential volé depuis une base de données de brèche, s'authentifiant depuis un nœud de sortie Tor à 3h du matin, réussira — même si le score de risque de connexion est "élevé" — à moins qu'une politique soit configurée pour bloquer l'accès.

Identity Protection ferme la brèche entre la détection et la réponse au niveau de la couche identité.

Comment ca Fonctionne

Identity Protection évalue deux types de risques :

Risque de connexion — la probabilité qu'une authentification spécifique ne provienne pas de l'utilisateur légitime :

• Adresse IP anonyme (Tor, VPN)
• Voyage atypique (deux connexions géographiquement impossibles en quelques heures)
• Propriétés de connexion inhabituelles (nouvel appareil, nouvelle localisation)
• Patterns de spray de mots de passe
• Anomalies de token (indicateurs de phishing AiTM)

Risque utilisateur — la probabilité qu'un compte utilisateur soit compromis :

• Credentials divulgués (Microsoft surveille les bases de données de brèches)
• Patterns d'activité suspects sur le temps
• Utilisation anormale de token

La Chaine d'Attaque (Sans Politiques de Risque)

Scénario 1 - Credentials Divulgués

# L'attaquant trouve des credentials corp.com dans une base de données de brèche publique
# Identity Protection détecte et définit le risque utilisateur = Élevé
# Sans politique : l'attaquant s'authentifie avec succès
# Avec politique : utilisateur à risque élevé → changement de mot de passe requis → attaquant bloqué

Scénario 2 - Phishing AiTM

# L'attaquant exécute un proxy AiTM Evilginx2
# La victime entre credentials + code MFA sur le faux site
# L'attaquant capture le token de session (contourne le MFA)
# Identity Protection détecte : anomalie de token, propriétés suspectes
# Sans politique : l'attaquant utilise le token volé librement
# Avec politique : session à risque élevé exige re-authentification → attaquant bloqué

Scénario 3 - Spray de Mots de Passe

# L'attaquant spraye des mots de passe courants sur des comptes M365
# Identity Protection détecte le pattern de spray — incrémente le risque de connexion
# Sans politique : un spray réussi passe inaperçu
# Avec politique : connexion à risque moyen exige MFA — le spray ne donne rien d'utilisable

Détection

Détections de Risque (Logs de Connexion Entra ID)

Requete SIEM (Elastic KQL)

azure.signinlogs.properties.risk_level_during_sign_in: ("high" OR "medium") AND
azure.signinlogs.properties.status.error_code: 0

azure.auditlogs.operation_name: "Risky user detected" AND
azure.auditlogs.properties.additional_details: "*leakedCredentials*"

💡 Conseil : Alertez sur toute connexion à risque élevé qui réussit. Ce sont des indicateurs quasi-certains d'attaque active ou de compromission de credentials.

Remédiation

💡 Action Rapide : Activez les politiques de risque utilisateur et de connexion dans Identity Protection aujourd'hui. Les deux peuvent être configurées en moins de 5 minutes.

1. Configurer la Politique de Risque de Connexion

Entra ID > Sécurité > Identity Protection > Politique de risque de connexion :
Utilisateurs : Tous les utilisateurs
Risque de connexion : Moyen et supérieur
Accès : Exiger le MFA
Activer : Oui

2. Configurer la Politique de Risque Utilisateur

Entra ID > Sécurité > Identity Protection > Politique de risque utilisateur :
Utilisateurs : Tous les utilisateurs
Risque utilisateur : Élevé
Accès : Autoriser + Exiger le changement de mot de passe
Activer : Oui

3. Examiner et Remédier les Utilisateurs Signalés

Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All", "IdentityRiskyUser.ReadWrite.All"

# Lister tous les utilisateurs à risque élevé
Get-MgRiskyUser -Filter "riskLevel eq 'high'" |
    Select-Object UserPrincipalName, RiskLevel, RiskLastUpdatedDateTime

# Confirmer la compromission
Invoke-MgConfirmRiskyUserCompromised -UserIds @("id-utilisateur-compromis")

4. Configurer les Notifications de Risque

Entra ID > Sécurité > Identity Protection > Notifications :
Alertes pour utilisateurs à risque détectés : Résumé hebdomadaire à l'équipe sécurité

Comment EtcSec Détecte Cela

EtcSec audite votre configuration Identity Protection lors de chaque scan Azure.

La catégorie Risk Protection vérifie si les politiques de risque de connexion et de risque utilisateur sont configurées et appliquées — une lacune critique qui laisse votre tenant sans réponse automatisée.

Les résultats incluent : pas de politique de risque, politiques en mode "rapport uniquement" (détectant mais pas appliquant), et notifications manquantes.

ℹ️ Note : EtcSec audite la configuration Identity Protection automatiquement. Lancez un audit gratuit pour voir si votre tenant Azure dispose de contrôles de réponse basés sur le risque.

Articles connexes : Failles d'Accès Conditionnel Azure | Accès Privilégié Azure

Priorites de Revue

Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués doit etre traite comme une exposition reelle dans votre tenant Entra ID et Azure, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels admins, comptes invites, service principals, app registrations, exclusions de politiques et comptes break-glass sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre tenant Entra ID et Azure, il ne s'arrete presque jamais au premier point faible. Autour de Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, il cherche en general a enchainer avec auth legacy, gouvernance invite insuffisante, consentements trop larges, comptes d'urgence obsoletes et roles jamais revises. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez journaux de connexion, journaux d'audit, changements de roles, evenements de consentement, rotations de secrets et signaux de risque, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre tenant Entra ID et Azure. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi auth legacy, gouvernance invite insuffisante, consentements trop larges, comptes d'urgence obsoletes et roles jamais revises, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez Conditional Access, PIM, moindre privilege, access reviews, validation des owners applicatifs, workflows d'approbation et MFA fort comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue operationnelle hebdomadaire et revue de durcissement mensuelle.

Validation apres chaque changement

Apres toute modification liee a Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur journaux de connexion, journaux d'audit, changements de roles, evenements de consentement, rotations de secrets et signaux de risque, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.

Lectures Associees

Pour traiter ce sujet correctement, comparez-le aussi avec Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas, Failles d'Accès Conditionnel Azure : Contournement du MFA, Acces Privilegie Azure : Trop d'Admins Globaux, Durcissement du Tenant Azure : Corriger les Configs à Risque et Comptes Invités Azure : Risques du Tenant. Ensemble, ces articles montrent comment les memes faiblesses d'identite s'enchainent dans une vraie evaluation de securite.

• Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas
• Failles d'Accès Conditionnel Azure : Contournement du MFA
• Acces Privilegie Azure : Trop d'Admins Globaux
• Durcissement du Tenant Azure : Corriger les Configs à Risque
• Comptes Invités Azure : Risques du Tenant

Ces liens internes permettent de verifier si vous corrigez un symptome isole ou un chemin d'exposition complet.

Verification des Exceptions et de l'Escalade

Une politique de risque n'est utile que si les exceptions restent strictement gouvernees. Verifiez qui peut approuver une exclusion, combien de temps elle reste active, quelles preuves sont exigees et comment les equipes d'exploitation sont prevenues lorsqu'un utilisateur a risque est autorise malgre tout. Cette couche de gouvernance evite qu'une bonne politique devienne un simple cadre que l'on contourne trop facilement.

Azure Identity Protection : validation avant clôture

Une revue solide de Azure Identity Protection doit se terminer par des preuves de production, pas par l'hypothèse que le chemin risqué a disparu. Avant de clôturer le constat, revalidez les attributions de rôles, la portée des politiques, les permissions applicatives ou les paramètres guest, les preuves de connexion, d'audit ou de risque sur le tenant réel et le chemin d'exception qui pourrait recréer l'exposition. Confirmez que l'état plus sûr s'applique bien au périmètre qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif ou le chemin de délégation et de confiance qu'un attaquant pourrait réellement exploiter. Documentez le propriétaire technique, la dépendance métier et la condition de retour arrière afin que le prochain cycle sache si l'état plus sûr a été maintenu.

Utilisez une checklist de clôture courte :

• vérifier que l'état risqué a disparu du point de vue attaquant, pas seulement dans une capture d'écran admin
• conserver un export avant/après ou un échantillon de log prouvant que la portée concernée a changé
• documenter le propriétaire et la décision d'exception si le contrôle ne peut pas être appliqué complètement

Pour les expositions adjacentes, recoupez le résultat avec Audit de sécurité Active Directory : checklist pratique, Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique, Acces Privilegie Azure : Trop d'Admins Globaux, et Failles d'Accès Conditionnel Azure : Contournement du MFA. Le même défaut de contrôle réapparaît souvent dans des chemins d'identité voisins, des manques de journalisation ou des délégations trop larges, d'où l'importance de cette validation finale.

Azure Identity Protection : preuves à conserver pour le prochain cycle

Le prochain relecteur ne devrait pas avoir à reconstruire le dossier de mémoire. Conservez la preuve qui justifiait le constat initial, la preuve que le changement a été appliqué, et la note qui explique pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'export ou la capture montrant la portée réellement concernée, les logs de connexion, d'audit ou la preuve de politique confirmant l'application du contrôle et le propriétaire, l'approbation et la note d'exception sur l'état final. Ce paquet compact accélère fortement les revues trimestrielles ou après changement et permet d'expliquer si le problème a été supprimé, réduit ou accepté formellement.

Si un changement d'admin, de politique ou d'application rouvre plus tard le chemin, cet historique permet aussi de démontrer précisément ce qui a dérivé. C'est ce qui transforme Azure Identity Protection en processus d'assurance répétable plutôt qu'en contrôle ponctuel.