Introduction
Dans les environnements cloud modernes, la protection des identités utilisateur constitue une priorité absolue. Les politiques d'accès conditionnel (Conditional Access) représentent la référence pour renforcer les contrôles d'accès. Cependant, de nombreuses organisations font face à un défi récurrent : leurs employés voyagent fréquemment.
Dans de tels contextes, l'application d'une politique d'accès conditionnel stricte limitant les connexions à un ensemble fixe de pays peut s'avérer impraticable. Néanmoins, cela ne signifie pas que vous devez rester aveugle aux activités suspectes. C'est là qu'intervient la surveillance proactive avec KQL (Kusto Query Language).
Pourquoi cette approche ?
Quand les politiques d'accès conditionnel ne peuvent pas bloquer certains pays, les administrateurs ont toujours besoin de visibilité sur les tentatives de connexion depuis des géographies inattendues, les attaques par force brute et les connexions réussies depuis des emplacements préoccupants.
Cas d'usage et objectifs
Lorsque l'accès conditionnel ne peut être appliqué pour bloquer complètement certains pays, les administrateurs nécessitent une visibilité sur :
- Les tentatives de connexion depuis des géographies inattendues
- Les comptes ciblés par des attaques de force brute ou de pulvérisation de mots de passe
- Les connexions réussies depuis des emplacements devant susciter des inquiétudes
En surveillant continuellement les tentatives de connexion en dehors de votre géographie "de confiance", vous pouvez garder une longueur d'avance et détecter les compromissions potentielles précocement.
Prérequis techniques
Avant d'exécuter cette solution, assurez-vous de disposer des éléments suivants :
Licences requises
- Entra ID P1 ou P2 : Nécessaire pour activer les journaux de connexion et les fonctionnalités avancées de protection d'identité
Infrastructure Azure
- Espace de travail Log Analytics : Centralise l'ingestion et l'interrogation des journaux de connexion
- Journaux Entra ID connectés à Log Analytics
Permissions d'accès
Votre compte administrateur doit disposer au minimum des rôles suivants :
- Lecteur de sécurité ou Administrateur de sécurité dans Azure AD
- Contributeur Log Analytics pour exécuter et gérer les requêtes
Configuration de l'espace de travail Log Analytics
Créer l'espace de travail
Dans le portail Azure, recherchez "Log Analytics Workspaces" et sélectionnez Créer.
Configurer les paramètres
Renseignez les informations suivantes :
- Abonnement : Sélectionnez votre abonnement Azure
- Groupe de ressources : Choisissez ou créez un groupe de ressources
- Nom : Saisissez un nom descriptif (ex. : "SecurityLogs")
- Région : Sélectionnez la région la plus proche de votre organisation
Valider et créer
Revisez la configuration et cliquez sur Créer pour déployer l'espace de travail.
Connexion des journaux Entra ID
Accéder aux paramètres de diagnostic
Rendez-vous dans le centre d'administration Entra ID à l'adresse https://entra.microsoft.com/, puis naviguez vers Surveillance > Paramètres de diagnostic.
Ajouter un paramètre de diagnostic
Cliquez sur Ajouter un paramètre de diagnostic et configurez :
- Sélectionnez SignInLogs et optionnellement AuditLogs
- Cochez Envoyer vers l'espace de travail Log Analytics
- Choisissez l'espace de travail créé précédemment
Sauvegarder la configuration
Enregistrez la configuration. Les journaux SigninLogs apparaîtront dans votre espace de travail dans quelques minutes à une heure, selon l'activité.
Délai d'ingestion
Une fois configuré, vous commencerez à voir les SigninLogs dans votre espace de travail dans un délai de quelques minutes à une heure, selon l'activité de connexion.
Exécution de la requête KQL
Accéder à l'espace de travail
Dans votre espace de travail Log Analytics, sélectionnez Journaux dans le menu de gauche et fermez le hub Requêtes en cliquant sur le 'X'.
Configurer le mode KQL
Sélectionnez le mode KQL dans votre espace de travail Log Analytics.
Exécuter la requête
Copiez et collez la requête KQL suivante pour filtrer les tentatives de connexion depuis des emplacements en dehors du Canada (CA) et des États-Unis (US) :
1// Obtenir la liste de toutes les connexions (réussies, échouées, révoquées, etc.) en dehors du Canada (CA) et des États-Unis (US)2SigninLogs 3| where Location !in ("CA", "US") and isnotempty(Location) // Emplacement différent du CANADA, US4| extend LocalTime = datetime_add('hour', -5, TimeGenerated) // UTC-5 (Heure CANADA)5| project LocalTime, UserPrincipalName, UserDisplayName, Identity, ResourceDisplayName, Location, IPAddress, RiskState, ConditionalAccessStatus, ResultType, ResultSignature, ResultDescription, MfaDetail, RiskDetail6| order by LocalTime descCliquez sur Exécuter pour lancer la requête.
Personnalisation des emplacements
Vous pouvez modifier les emplacements en changeant "CA" et "US" dans la troisième ligne de code et en ajoutant vos emplacements spécifiques.
Les résultats incluront des détails tels que : LocalTime, UserPrincipalName, Location, IPAddress, RiskState, ResultDescription.
Sauvegarde de la requête KQL
Sauvegarder la requête
Cliquez sur le bouton de sauvegarde et renseignez :
- Nom de la requête : "Tentatives de connexion depuis des emplacements inhabituels"
- Description : "Détection des tentatives de connexion depuis des emplacements géographiques suspects"
- Type de ressource : "Espaces de travail Log Analytics"
- Catégorie : "Audit"
Mémorisation
Conservez le nom de la requête dans un bloc-notes, car nous l'utiliserons ultérieurement pour la configuration des alertes.
Configuration des alertes automatisées
Créer une règle d'alerte
Dans l'espace de travail Log Analytics, cliquez sur "..." (trois points) en haut à droite, puis sélectionnez Nouvelle règle d'alerte.
Configurer la condition
Dans la section Condition :
- Nom du signal : "Recherche de journal personnalisée"
- Type de requête : Journaux agrégés
- Collez votre requête KQL dans la zone de texte
Dans la section Mesure :
- Mesure : "Lignes de tableau"
- Type d'agrégation : "Nombre"
- Granularité d'agrégation : "30 minutes"
Définir la logique d'alerte
Configurez les paramètres suivants :
- Opérateur : "Supérieur à"
- Valeur seuil : 0
- Agrégation temporelle : 30 minutes
- Remplacer la plage de temps de la requête : 30 min
Configurer les actions
Dans la section Action :
- Sélectionnez Actions rapides (Aperçu)
- Nom du groupe d'actions : "Notification Email Connexion Suspecte"
- Nom d'affichage : "Conn-Suspecte"
- E-mails de notification : Ajoutez les adresses e-mail qui doivent recevoir l'alerte
Personnalisez l'objet de l'e-mail d'alerte, par exemple : "Alerte - Connexion depuis un emplacement inhabituel".
Finaliser la configuration
Configurez les détails finaux :
- Abonnement Azure : Sélectionnez l'abonnement approprié
- Groupe de ressources : Choisissez le groupe de ressources
- Niveau de gravité : 2 – Avertissement
- Nom descriptif : "Tentatives de connexion depuis des emplacements inhabituels"
- Région : Choisissez la même région que vos autres ressources
Cliquez sur Créer pour finaliser et déployer la règle d'alerte.
Test et validation du système
Pour valider le bon fonctionnement de votre système de détection, vous pouvez simuler une connexion depuis un emplacement inhabituel. Dans l'exemple ci-dessous, une tentative de connexion avec un mot de passe incorrect depuis un VPN localisé au Royaume-Uni génère immédiatement une notification.
Notification par e-mail
Voici un exemple de notification e-mail envoyée au service d'assistance :
Vérification des résultats
Pour vérifier directement les résultats de la requête :
- Retournez dans l'espace de travail Log Analytics
- Sélectionnez "Journaux" dans le menu de gauche
- Tapez le nom de votre requête KQL sauvegardée dans la barre de recherche
- Cliquez sur "Exécuter"
Les résultats détaillés s'affichent dans le tableau :
Optimisations avancées
Ajout aux favoris
Pour un accès rapide à votre requête :
- Tapez le nom de votre requête dans la barre de recherche
- Cliquez sur l'icône étoile pour l'ajouter aux favoris
Exclusion d'adresses IP de confiance
Si vous souhaitez exclure certains emplacements ou adresses IP de confiance (bureaux, adresses IP approuvées), utilisez cette requête KQL modifiée :
1// Adresses IP des bureaux autorisés à exclure du déclenchement2let AllowedIPs = dynamic([ "1.1.1.1", "8.8.8.8" ]);3// Obtenir la liste de toutes les connexions en dehors de la liste de pays + liste d'IP4SigninLogs 5| where Location !in ("CA", "US") and isnotempty(Location) // Emplacement différent du CANADA, US6| where IPAddress !in~ (AllowedIPs) // exclure les adresses IP des bureaux7| extend LocalTime = datetime_add('hour', -5, TimeGenerated) // UTC-5 (Heure CANADA)8| project LocalTime, UserPrincipalName, UserDisplayName, Identity, ResourceDisplayName, Location, IPAddress, RiskState, ConditionalAccessStatus, ResultType, ResultSignature, ResultDescription, MfaDetail, RiskDetail9| order by LocalTime descPersonnalisation des IP
N'oubliez pas de remplacer les adresses IP d'exemple ("1.1.1.1", "8.8.8.8") par les adresses IP réelles de vos bureaux ou adresses de confiance.
Conclusion
Cette solution de surveillance proactive vous permet de maintenir une visibilité sur les activités de connexion suspectes tout en préservant la flexibilité nécessaire pour les employés en déplacement. En combinant KQL, Log Analytics et les alertes Azure, vous disposez d'un système de détection robuste qui complète efficacement vos politiques d'accès conditionnel existantes.
La mise en place de cette surveillance continue constitue une couche de sécurité supplémentaire essentielle dans votre stratégie de protection des identités Microsoft 365.
