Qu'est-ce qu'Azure Identity Protection ?
Azure Identity Protection, désormais Microsoft Entra ID Protection, est la couche de détection et de réponse au risque pour les identités Microsoft Entra. Elle évalue les signaux pouvant indiquer une compromission de compte et les expose sous forme de risque utilisateur, de risque de connexion, d'utilisateurs à risque et de détections de risque.
Le point opérationnel important est que la détection seule ne contient pas une attaque. Un tenant peut afficher des utilisateurs à risque et des connexions à risque dans le portail tout en laissant l'attaquant poursuivre si aucune politique n'exige de remédiation, d'authentification multifacteur, de réauthentification, de changement de mot de passe ou de blocage. Cet article porte sur cet écart : le risque est visible, mais la réponse du tenant est absente, incomplète ou trop restreinte.
Les recommandations actuelles de Microsoft placent les contrôles basés sur le risque dans l'Accès Conditionnel. Les politiques de risque héritées d'Identity Protection existent encore dans certains tenants, mais la documentation Microsoft indique que les politiques héritées de risque utilisateur et de risque de connexion doivent être migrées vers l'Accès Conditionnel et que leur retrait est prévu pour le 1er octobre 2026.
Comment Fonctionne Azure Identity Protection
Identity Protection utilise deux concepts de risque étroitement liés :
Le risque de connexion est la probabilité qu'une demande d'authentification spécifique ne soit pas effectuée par le propriétaire légitime de l'identité. Il est évalué au moment de la connexion et peut être utilisé comme condition dans une politique d'Accès Conditionnel.
Le risque utilisateur est la probabilité que le compte utilisateur lui-même soit compromis. Il peut persister au-delà d'une seule connexion et peut nécessiter un changement de mot de passe, une révocation de session, une investigation par un administrateur ou un rejet.
Microsoft documente des détections de risque telles que les identifiants divulgués, l'adresse IP anonyme, le voyage atypique, les propriétés de connexion inhabituelles, l'adresse IP malveillante, les règles suspectes de manipulation de boîte de réception, le spray de mots de passe, le jeton anormal, ainsi que d'autres signaux. Certaines détections sont en temps réel, tandis que d'autres sont calculées hors ligne et peuvent apparaître plus tard. Ce délai a une importance opérationnelle : un événement de risque peut apparaître après que l'authentification d'origine a déjà été effectuée.
Pourquoi les Politiques de Risque Échouent en Pratique
Identity Protection sous-performe lorsque les équipes traitent le tableau de bord comme le contrôle lui-même. Les modes d'échec courants incluent :
- aucune politique d'Accès Conditionnel n'utilise les conditions de risque de connexion ou de risque utilisateur
- les politiques restent en mode rapport uniquement après les tests
- les politiques de risque couvrent les utilisateurs pilotes mais pas les utilisateurs privilégiés ni la population générale
- les comptes d'urgence sont exclus sans surveillance compensatoire
- les utilisateurs hybrides ne peuvent pas terminer l'auto-remédiation car l'écriture différée du mot de passe (password writeback) n'est pas disponible là où elle est nécessaire
- les notifications d'utilisateurs à risque sont envoyées à une boîte mail que personne ne consulte
- les analystes peuvent rejeter un risque sans norme de preuve documentée
- les service principals sont confondus avec une couverture d'Accès Conditionnel ciblant les utilisateurs
Ce dernier point est important. Les politiques de risque utilisateur et de risque de connexion ciblent les connexions des utilisateurs. Le risque des identités de charge de travail et des service principals nécessite un modèle de contrôle différent et ne doit pas être présumé couvert par les politiques de risque utilisateur destinées aux humains.
La Chaîne d'Attaque Sans Réponse au Risque
Scénario 1 - Identifiants Divulgués
Les identifiants d'un utilisateur apparaissent dans des données de brèche ou sont autrement évalués comme risqués. Identity Protection élève le risque utilisateur, mais aucune politique de risque utilisateur n'exige de remédiation. Le compte reste utilisable jusqu'à ce qu'un autre contrôle bloque l'attaquant.
Scénario 2 - Une Connexion à Risque qui Aboutit Quand Même
Une connexion présente un risque moyen ou élevé en raison de signaux tels qu'une infrastructure anonyme, des propriétés de connexion inhabituelles ou un voyage atypique. Si aucune politique de risque de connexion ne s'applique, la session peut quand même aboutir. Une entrée de journal existe, mais l'attaquant a déjà obtenu l'accès.
Scénario 3 - Spray de Mots de Passe Contre des Comptes Cloud
Une campagne de spray de mots de passe génère un bruit d'authentification étendu et peut produire des détections risquées. Si les connexions réussies ne sont pas forcées vers une authentification renforcée (step-up) ou bloquées selon la politique, l'attaquant conserve les sessions réussies.
Scénario 4 - Risque Rejeté Sans Investigation
Un utilisateur à risque est rejeté parce que l'alerte est gênante ou bruyante. Si le processus de rejet n'exige pas de preuve, le tenant peut normaliser une compromission réelle et supprimer le signal dont les défenseurs avaient besoin.
Détection
Signaux de Risque à Surveiller
| Signal | Ce qu'il Indique | Usage Opérationnel |
|---|---|---|
| Identifiants divulgués | Des identifiants associés au compte ont été trouvés dans des données compromises connues | À traiter comme une preuve de compromission de compte jusqu'à revue |
| Adresse IP anonyme | La connexion provient d'une infrastructure d'anonymisation | Corréler avec l'appareil, la localisation et l'historique utilisateur |
| Voyage atypique | La géographie de connexion est incohérente avec l'activité récente | Vérifier les schémas de voyage impossibles ou suspects |
| Propriétés de connexion inhabituelles | La connexion diffère du comportement normal de l'utilisateur | Utile combiné au contexte de l'appareil et de la localisation |
| Adresse IP malveillante | L'infrastructure source est associée à une activité malveillante | Urgence accrue pour les utilisateurs privilégiés |
| Spray de mots de passe | Un comportement étendu de devinette de mot de passe est détecté | Corréler avec les verrouillages, échecs et connexions réussies |
| Jeton anormal | Le comportement du jeton semble suspect | Vérifier l'activité de session et révoquer si nécessaire |
Événements et Rapports à Examiner
La détection doit inclure :
- le rapport des utilisateurs à risque
- le rapport des détections de risque
- les journaux de connexion avec le niveau et le détail du risque
- les résultats d'Accès Conditionnel pour les connexions à risque
- les journaux d'audit pour le rejet de risque, la réinitialisation de mot de passe, les changements de politique et les actions administratives
- le contexte de rôle privilégié pour les identités concernées
Une connexion à risque élevé pour un administrateur général n'a pas la même priorité opérationnelle qu'un événement à faible risque pour un compte de test dormant. L'alerte doit inclure le rôle, l'appareil, la localisation, l'application, le résultat de la politique et l'issue de la session.
Remédiation
Identity Protection devient utile lorsque le risque déclenche une réponse. Un tableau de bord sans Accès Conditionnel appliqué n'est qu'une visibilité.
1. Configurer des Politiques de Risque Séparées
Les recommandations Microsoft déconseillent de combiner les conditions de risque utilisateur et de risque de connexion dans la même politique d'Accès Conditionnel. Créez des politiques séparées afin que chaque condition de risque dispose d'un chemin de réponse clair.
Pour le risque de connexion, Microsoft recommande d'exiger l'authentification multifacteur pour un risque moyen et élevé. Pour le risque utilisateur, Microsoft recommande d'exiger la remédiation du risque lorsque le risque utilisateur est élevé. Les organisations peuvent choisir des seuils plus stricts, mais elles doivent équilibrer sécurité, faux positifs et interruption utilisateur.
2. Utiliser le Mode Rapport Uniquement, Puis Appliquer
Le mode rapport uniquement est utile pour le déploiement. Ce n'est pas un état final. Vérifiez quels utilisateurs, applications et scénarios seraient affectés, corrigez les ruptures attendues, puis passez la politique en Activé. Conservez un enregistrement daté du déploiement afin que les politiques en mode rapport uniquement ne deviennent pas des vestiges permanents.
3. Faire Fonctionner l'Auto-Remédiation
L'auto-remédiation dépend de prérequis. Les utilisateurs doivent être inscrits à l'authentification multifacteur Microsoft Entra avant de pouvoir satisfaire une remédiation basée sur le MFA. Les utilisateurs hybrides peuvent nécessiter l'écriture différée du mot de passe pour les scénarios de changement de mot de passe sécurisé. Si ces prérequis manquent, les utilisateurs peuvent être bloqués et nécessiter une intervention administrateur.
4. Définir le Flux de Travail de l'Analyste
Une politique de risque ne remplace pas l'investigation. Définissez qui peut :
- confirmer la compromission d'un utilisateur
- rejeter un risque utilisateur
- réinitialiser des mots de passe
- révoquer des sessions
- débloquer des utilisateurs
- approuver des exclusions
- mettre à jour les seuils de risque de l'Accès Conditionnel
Chaque action doit avoir une norme de preuve. Rejeter un risque parce que l'utilisateur affirme avoir voyagé n'équivaut pas à valider l'appareil, l'IP, la méthode d'authentification et l'activité de session.
5. Examiner les Exclusions et les Comptes de Service
Les comptes d'accès d'urgence peuvent nécessiter un traitement spécial, mais les exclusions doivent être peu nombreuses et fortement surveillées. Les comptes de service et les identités de charge de travail ne doivent pas être silencieusement exclus de la conversation sur le risque ; ils peuvent nécessiter un Accès Conditionnel pour identités de charge de travail, des identités managées, une rotation des identifiants ou une surveillance différente.
Séquence de Déploiement Sécurisée
Un déploiement sécurisé ne commence pas par bloquer l'ensemble du tenant sans preuve. Commencez par des politiques en mode rapport uniquement pour la population visée, examinez l'impact de la politique, corrigez les prérequis d'inscription et d'écriture différée du mot de passe, puis appliquez la politique par étapes. Les identités privilégiées doivent être priorisées, car une connexion à risque réussie pour un administrateur a un rayon d'impact bien plus élevé que le même événement sur un compte à faible privilège.
Gardez le déploiement mesurable. Suivez combien de connexions à risque auraient été bloquées ou mises au défi, combien d'utilisateurs ont pu s'auto-remédier, quels comptes sont exclus et quels incidents ont nécessité une action administrateur. Ces chiffres aident à distinguer un programme de protection fonctionnel d'une politique qui existe mais ne peut pas être appliquée en toute sécurité.
Validation Après Activation de la Réponse au Risque
Validez le contrôle à la fois depuis le portail et depuis la perspective de l'attaquant :
- confirmez que les politiques de risque de connexion et de risque utilisateur sont activées, pas seulement configurées
- confirmez que les utilisateurs ciblés incluent les identités privilégiées et les utilisateurs normaux dans le périmètre
- confirmez que les utilisateurs exclus sont documentés et surveillés
- examinez les connexions à risque récentes et vérifiez que le résultat de politique prévu s'est appliqué
- confirmez que les connexions à risque élevé réussies sont rares, explicables et investiguées
- confirmez que les administrateurs peuvent confirmer une compromission, rejeter un risque, révoquer des sessions et réinitialiser des identifiants selon des flux de travail documentés
- testez le routage des alertes pour que les notifications d'utilisateurs à risque atteignent l'équipe de réponse
- examinez si les identités de charge de travail nécessitent un Accès Conditionnel ou une surveillance séparés
Si le tenant détecte le risque mais permet aux utilisateurs à risque de continuer sans remédiation, le contrôle est incomplet.
Comment EtcSec Détecte Cela
EtcSec audite si les détections de risque sont liées à un chemin de réponse appliqué.
La catégorie Risk Protection met en évidence l'absence de politique de risque de connexion, l'absence de politique de risque utilisateur, et une réponse de tenant faible où l'activité risquée est visible mais où l'application est absente ou incomplète.
C'est précisément l'écart opérationnel qui concerne cet article : des détections de risque sans confinement.
Contrôles Associés
Identity Protection fonctionne mieux lorsqu'elle est associée à Sécurité des Identités Azure : Pourquoi le MFA Seul ne Suffit Pas, Failles d'Accès Conditionnel Azure : Contournement du MFA, Accès Privilégié Azure : Trop d'Admins Globaux, Comptes Invités Azure : Risques du Tenant, et Applications Azure Sur-Privilégiées dans Votre Tenant. Sinon, le tenant peut détecter le risque tout en laissant les chemins de privilège et d'application adjacents faciles à exploiter.
Références Principales
Explorez les pages identité liées à ce sujet