Introduction
Les stratégies Conditional Access de Microsoft Entra ID permettent de contrôler les conditions dans lesquelles un utilisateur peut accéder aux ressources Microsoft 365. Il est notamment possible de définir des restrictions en fonction de la localisation réseau.
Bloquer une connexion constitue cependant seulement une partie du dispositif de sécurité.
Pour une équipe de sécurité ou un SOC, il peut être tout aussi important de détecter qu’une tentative de connexion a eu lieu, y compris lorsque Microsoft Entra Conditional Access a correctement refusé l’accès.
Dans cet article, nous allons voir comment utiliser Microsoft Entra ID, Azure Monitor et Log Analytics afin de détecter les tentatives de connexion provenant de certains pays et générer automatiquement une alerte.
Microsoft permet d’intégrer les journaux d’activité Entra à Azure Monitor afin d’analyser les authentifications dans un espace de travail Log Analytics.
Pourquoi surveiller les connexions provenant de certains pays ?
Prenons un exemple. Une entreprise a défini une stratégie Conditional Access interdisant les connexions provenant de plusieurs pays dans lesquels elle ne considère qu’aucun de ses collaborateurs ne devrait normalement se trouver. Dans notre exemple, nous allons surveiller les pays suivants :
- Chine
- Afghanistan
- Corée du Nord
- Iran
- Yémen
- Syrie
Cette liste n’a évidemment rien d’universel. Il s’agit ici d’un exemple de politique interne de surveillance géographique. Chaque organisation doit déterminer les zones à surveiller en fonction de sa propre analyse de risques, de ses implantations et des déplacements de ses utilisateurs.
Imaginons maintenant qu’un attaquant dispose du mot de passe d’un utilisateur et tente de s’authentifier depuis une adresse IP située dans l’un des pays surveillés.
Conditional Access peut correctement identifier les conditions de connexion et bloquer l’accès.
D’un point de vue purement préventif, le mécanisme a fonctionné. Mais pour une équipe SecOps, une autre question se pose : Souhaitons-nous être informés qu’une telle tentative a eu lieu ?. Dans beaucoup d’environnements sensibles, la réponse sera oui.
Une tentative répétée peut notamment justifier une investigation portant sur le compte concerné, l’adresse IP source, l’application ciblée ou les autres événements associés à l’utilisateur.
L’approche consiste donc à séparer deux fonctions :
- Conditional Access protège et bloque l’accès ;
- Azure Monitor et Log Analytics détectent les événements et génèrent des alertes.
Étape 1 : disposer d’un Log Analytics Workspace
Pour pouvoir exploiter les journaux d’authentification avec KQL, il faut disposer d’un Log Analytics Workspace. Microsoft indique notamment qu’un espace de travail Log Analytics et les autorisations correspondantes sont nécessaires pour analyser les journaux d’activité Microsoft Entra avec Log Analytics.
Si aucun Workspace n’existe encore, ouvrez le portail Azure, recherchez Log Analytics workspaces, puis sélectionnez Create.
Il faudra notamment sélectionner :
- la souscription Azure ;
- le Resource Group ;
- le nom du Workspace ;
- la région Azure.
Microsoft détaille également la création du Workspace dans son tutoriel consacré à l’analyse des Sign-in Logs. Dans notre exemple, le Workspace utilisé porte le nom AzureMonitor.
Étape 2 : envoyer les Sign-in Logs Microsoft Entra vers Log Analytics
La deuxième étape consiste à demander à Microsoft Entra d’envoyer ses journaux d’authentification vers le Workspace Log Analytics.
Depuis le Microsoft Entra admin center, naviguez vers :
Entra ID → Monitoring & health → Diagnostic settings. Si un Diagnostic setting existe déjà, sélectionnez Edit setting.
Dans le cas contraire, sélectionnez Add diagnostic setting.
Microsoft permet effectivement de créer une nouvelle configuration ou de modifier une configuration existante.
Étape 3 : activer la collecte des SignInLogs
Dans la configuration du Diagnostic setting, sélectionnez au minimum la catégorie : SignInLogs
Dans Destination details, activez ensuite : Send to Log Analytics workspace
Sélectionnez votre souscription Azure puis votre Workspace Log Analytics.
Dans notre exemple : Log Analytics workspace : AzureMonitor
Microsoft décrit explicitement la sélection d’AuditLogs et SigninLogs, puis l’envoi de ces journaux vers un Log Analytics Workspace. En fonction des besoins de supervision, vous pouvez naturellement collecter d’autres catégories de journaux.
Cliquez enfin sur Save.
Microsoft précise que les journaux sélectionnés peuvent nécessiter jusqu’à 15 minutes avant d’être disponibles dans le Workspace après la configuration.
Étape 4 : vérifier que les Sign-in Logs arrivent correctement
Avant de créer la moindre alerte, vérifions que les données sont correctement disponibles.
Depuis Microsoft Entra, accédez à : Entra ID → Monitoring & health → Log Analytics
Dans l’éditeur de requêtes, saisissez :
KQL
SigninLogs
| take 20
Cliquez ensuite sur Run.
Si des événements apparaissent, cela confirme que Log Analytics reçoit bien les Sign-in Logs.
Étape 5 : identifier les pays présents dans les journaux
Avant de chercher uniquement les pays que nous souhaitons surveiller, il est intéressant de regarder les codes pays effectivement présents dans les données.
Utilisez la requête suivante :
KQL
SigninLogs
| summarize Nombre=count()
by Country=tostring(LocationDetails.countryOrRegion)
| order by Nombre desc
Cette requête permet d’obtenir une vue synthétique des valeurs contenues dans la propriété LocationDetails.countryOrRegion. Elle constitue également un excellent moyen de vérifier que les informations de localisation sont effectivement présentes dans votre environnement.
Étape 6 : rechercher les connexions provenant des pays surveillés
Nous pouvons maintenant créer notre requête de détection.Dans notre exemple, nous allons utiliser les codes pays suivants :
- CN : Chine
- AF : Afghanistan
- KP : Corée du Nord
- IR : Iran
- YE : Yémen
- SY : Syrie
La requête KQL devient :
KQL
SigninLogs
| where tostring(LocationDetails.countryOrRegion) in (« CN », »AF », »KP », »IR », »YE », »SY »)
| project
TimeGenerated,
UserPrincipalName,
UserDisplayName,
IPAddress,
Country=tostring(LocationDetails.countryOrRegion),
City=tostring(LocationDetails.city),
AppDisplayName,
ResultType,
ResultDescription,
ConditionalAccessStatus
| order by TimeGenerated desc
La recherche permet ainsi de faire ressortir différentes informations particulièrement intéressantes pour une investigation :
- date et heure de la tentative ;
- utilisateur ;
- User Principal Name ;
- adresse IP ;
- pays ;
- ville ;
- application ciblée ;
- résultat de la connexion ;
- résultat de Conditional Access.
Étape 7 : ne pas rechercher uniquement les connexions réussies
Il s’agit probablement du point le plus important de toute la configuration. Il serait tentant de ne générer une alerte que lorsqu’une authentification provenant d’un pays surveillé réussit. Mais ce serait se priver d’une information de sécurité particulièrement intéressante.
Si un attaquant tente d’utiliser les identifiants d’un utilisateur depuis un pays surveillé et que Conditional Access bloque correctement la connexion, l’équipe de sécurité peut tout de même vouloir être informée de cette tentative. Notre recherche doit donc conserver aussi bien les événements réussis que les événements échoués.
L’objectif est de répondre à deux questions distinctes :
Un utilisateur a-t-il tenté de s’authentifier depuis l’un des pays surveillés ?
et :
Cette tentative a-t-elle réussi ou a-t-elle été bloquée ?
Cette distinction est particulièrement intéressante dans le cadre d’une surveillance SecOps.
Étape 8 : tester la détection sur un seul pays
Si la requête précédente ne retourne aucun résultat, cela ne signifie pas nécessairement qu’elle est incorrecte. Il est possible qu’aucun événement correspondant n’existe dans la période interrogée.
Une bonne méthode consiste à commencer par tester un seul pays.
Par exemple, pour la Chine :
KQL
SigninLogs
| where tostring(LocationDetails.countryOrRegion) == « CN »
| order by TimeGenerated desc
Vous pouvez également compter les événements et les utilisateurs distincts par pays :
KQL
SigninLogs
| summarize
Connexions=count(),
Utilisateurs=dcount(UserPrincipalName)
by Country=tostring(LocationDetails.countryOrRegion)
| order by Connexions desc
Cela permet de vérifier facilement le fonctionnement de la détection avant de créer l’alerte.
Étape 9 : préparer la requête destinée à l’alerte
Une fois les tests terminés, nous pouvons utiliser une version simplifiée de la requête pour notre future alerte :
KQL
SigninLogs
| where tostring(LocationDetails.countryOrRegion) in (« CN », »AF », »KP », »IR », »YE », »SY »)
| project
TimeGenerated,
UserPrincipalName,
IPAddress,
Country=tostring(LocationDetails.countryOrRegion),
AppDisplayName,
ResultType,
ConditionalAccessStatus
L’objectif est simple : dès qu’un événement correspondant à l’un des pays surveillés apparaît dans les Sign-in Logs, la requête retourne un résultat susceptible d’être utilisé par notre mécanisme d’alerte.
Étape 10 : créer l’alerte Azure Monitor
Une fois la requête KQL testée, rendez-vous dans Azure Monitor, puis ouvrez la partie Alerts afin de créer une nouvelle règle d’alerte.
Microsoft décrit également un scénario dans lequel le Log Analytics Workspace constitue la ressource surveillée et une recherche personnalisée dans les journaux sert de condition à l’alerte.
Sélectionnez comme Scope le Log Analytics Workspace qui reçoit les Sign-in Logs.
Dans notre exemple, il s’agit de : AzureMonitor. Pour la condition, utilisez la recherche dans les journaux et la requête KQL précédemment validée.
La logique recherchée est la suivante : si la requête retourne un événement correspondant aux critères définis, une alerte doit être générée.
Adaptez ensuite les paramètres d’évaluation et de déclenchement à la politique de supervision de votre organisation.
Étape 11 : configurer la notification
L’étape suivante consiste à déterminer comment l’équipe de sécurité sera informée. La règle d’alerte peut être associée à un Action Group Azure Monitor. Dans un environnement d’entreprise, on pourra par exemple utiliser une boîte fonctionnelle dédiée : secops@entreprise.fr. Un nom explicite permettra également de faciliter le traitement de l’alerte. Par exemple :
ENTRA – Sign-in depuis un pays surveillé
Le message destiné aux équipes de sécurité devrait idéalement permettre d’identifier rapidement :
- l’utilisateur concerné ;
- la date et l’heure ;
- l’adresse IP ;
- le pays détecté ;
- l’application concernée ;
- le résultat de l’authentification ;
- le résultat de Conditional Access.
L’objectif est de fournir suffisamment de contexte pour permettre à l’équipe SecOps de déterminer rapidement si une investigation supplémentaire est nécessaire.
Étape 12 : tester le dispositif avant sa mise en production
Une alerte de sécurité ne devrait jamais être considérée comme opérationnelle sans validation. Je recommande de réaliser au minimum trois contrôles.
Vérifier la collecte
Exécutez :
KQL
SigninLogs
| take 20
Cette requête valide que les événements Microsoft Entra arrivent correctement dans le Workspace.
Vérifier les données géographiques
Exécutez :
KQL
SigninLogs
| summarize Nombre=count()
by Country=tostring(LocationDetails.countryOrRegion)
| order by Nombre desc
Cette requête permet de vérifier que les valeurs utilisées pour la détection géographique sont effectivement présentes dans les données.
Vérifier la détection finale
Exécutez :
KQL
SigninLogs
| where tostring(LocationDetails.countryOrRegion) in (« CN », »AF », »KP », »IR », »YE », »SY »)
La dernière étape consiste ensuite à vérifier que la règle Azure Monitor produit effectivement la notification attendue lorsqu’un événement correspondant à ses conditions est rencontré.
Attention à la géolocalisation des connexions
Il est important de ne pas considérer la localisation comme un signal de sécurité isolé. Lors d’une investigation, l’équipe SecOps gagnera à corréler le pays détecté avec d’autres informations contenues dans les Sign-in Logs et les autres signaux de sécurité disponibles.
Par exemple :
- l’utilisateur concerné ;
- l’adresse IP ;
- l’application sollicitée ;
- le résultat de l’authentification ;
- le résultat Conditional Access ;
- les éventuels signaux de risque disponibles dans Microsoft Entra.
L’objectif n’est donc pas simplement d’envoyer une notification supplémentaire, mais de fournir suffisamment de contexte à l’équipe de sécurité pour qualifier l’événement.
Conditional Access et Azure Monitor : deux fonctions complémentaires
Cette architecture permet finalement de clairement séparer deux responsabilités.
- Microsoft Entra Conditional Access applique la politique d’accès et peut bloquer une authentification lorsque les conditions définies sont réunies.
- Azure Monitor et Log Analytics permettent d’exploiter les journaux Microsoft Entra afin de rechercher les événements correspondant aux critères de supervision.
Cette distinction est importante : une tentative bloquée peut néanmoins constituer un événement de sécurité intéressant. La combinaison de Conditional Access avec une surveillance des Sign-in Logs permet donc de passer d’une logique uniquement préventive à une approche combinant prévention, visibilité et détection.
Conclusion
Microsoft Entra Conditional Access constitue un mécanisme essentiel pour contrôler les conditions dans lesquelles les utilisateurs peuvent accéder aux ressources Microsoft 365. Mais une stratégie efficace ne consiste pas uniquement à bloquer les accès non autorisés. Il est également nécessaire de savoir qu’une tentative a eu lieu.
L’association de Microsoft Entra ID, Diagnostic Settings, Azure Monitor, Log Analytics et KQL permet d’exploiter les journaux d’authentification afin de détecter certaines situations définies par l’organisation et de les intégrer dans son dispositif de supervision. Microsoft prend en charge l’intégration de ces journaux à Azure Monitor et leur analyse dans Log Analytics.
Dans notre scénario, cela permet de compléter une stratégie Conditional Access bloquant certaines zones géographiques par un dispositif capable de détecter les tentatives correspondantes et d’en informer les équipes chargées de la sécurité.
Une connexion peut donc être bloquée par Conditional Access et simultanément devenir un signal exploitable par la SecOps.
