Entra ID Protection : bien exploiter le risque de connexion et le risque utilisateur
Entra ID Protection évalue en continu la probabilité qu'une connexion ou un compte soit compromis. Beaucoup d'organisations disposent de la licence nécessaire sans exploiter ces signaux, ou les exploitent sans processus pour traiter les alertes. Les deux situations sont risquées.
Deux notions de risque distinctes
Le risque de connexion concerne une authentification précise : cette connexion est-elle vraisemblablement effectuée par le titulaire du compte ? Il est calculé en temps réel ou a posteriori. Le risque utilisateur porte sur le compte lui-même : ses identifiants ont-ils fuité, son comportement général trahit-il une compromission ? Un risque utilisateur persiste tant qu'il n'a pas été corrigé.
Les détections
Parmi les détections courantes figurent l'adresse IP anonyme, le voyage atypique, les propriétés de connexion inhabituelles, la pulvérisation de mots de passe, les identifiants divulgués ou encore les anomalies de jeton. Certaines ne sont disponibles qu'avec Entra ID P2 ; sans cette licence, la visibilité est très réduite.
AADUserRiskEvents | where TimeGenerated > ago(30d) | summarize Detections = count() by RiskEventType, RiskLevel | sort by Detections desc
Les stratégies basées sur le risque
Le risque devient utile lorsqu'il déclenche une réaction automatique dans l'accès conditionnel. Microsoft recommande désormais de configurer ces stratégies dans l'accès conditionnel plutôt que dans les anciennes stratégies d'Identity Protection. Un point de départ classique :
- risque de connexion moyen ou élevé : exiger une MFA, qui corrige le risque si elle réussit ;
- risque utilisateur élevé : exiger un changement de mot de passe sécurisé, précédé d'une MFA ;
- pour les administrateurs : des seuils plus stricts, voire un blocage.
Pour les utilisateurs sans mot de passe, le changement de mot de passe n'a pas de sens ; vérifiez les options de remédiation actuellement proposées par Microsoft pour ce cas.
Environnements hybrides. Si les mots de passe sont gérés dans AD, la remédiation par changement de mot de passe suppose l'écriture différée des mots de passe, ou le paramètre qui permet à un changement effectué en local de réinitialiser le risque. Sans cela, les utilisateurs restent bloqués.
Traiter les alertes : confirmer, ignorer, corriger
Chaque utilisateur à risque doit faire l'objet d'une décision. Les administrateurs peuvent confirmer la compromission, ce qui élève le risque et alimente le modèle, ignorer le risque après vérification, ou confirmer qu'une connexion est sûre. Ignorer en masse pour « nettoyer » le tableau de bord efface des signaux qui pouvaient être réels.
Les faux positifs
Les VPN d'entreprise, les passerelles de sécurité, les postes de travail virtuels hébergés dans le cloud ou les utilisateurs très mobiles génèrent des détections légitimes mais trompeuses. Plutôt que d'exclure des utilisateurs des stratégies, déclarez les sorties Internet de l'entreprise en emplacements nommés approuvés et affinez les seuils.
En résumé
Identity Protection n'a de valeur que si trois conditions sont réunies : des stratégies de risque actives dans l'accès conditionnel, une remédiation en libre-service réellement possible (MFA enregistrée, écriture différée des mots de passe si nécessaire) et une personne chargée de traiter les utilisateurs à risque restants. Sans ce dernier point, le tableau de bord se transforme en simple liste d'alertes ignorées.