Table of Contents

Azure Monitor n'est pas seulement un outil de télémétrie de performance, c'est une ligne de défense primaire pour les organisations qui exécutent des charges de travail dans Microsoft Azure. En recueillant et en analysant en permanence les données de tout votre environnement Azure, il permet aux équipes de sécurité de détecter les anomalies, d'enquêter sur les incidents et de réagir aux menaces à la vitesse du cloud.

Comprendre le moniteur Azure

Azure Monitor est un service à l'échelle de la plateforme qui fournit un seul verre pour la surveillance des ressources, des applications et des environnements sur site Azure (via des agents connectés). Son architecture repose sur quatre piliers principaux :

  • Métriques – Données numériques de séries temporelles (p. ex. pourcentage CPU, IOPS disque) qui supportent la détection de tendance en temps quasi réel.
  • Logs – Données textuelles structurées ou libres recueillies à partir de ressources, d'applications et de systèmes d'exploitation, analyzables avec Kusto Query Language (KQL)[.
  • Diagnostic – Registres de niveau plate-forme des services Azure, y compris les registres d'activités (événements de contrôle-plan) et les registres de ressources (événements de data-plane).
  • Insights – Expériences conçues pour la surveillance des applications, des machines virtuelles, des conteneurs et des réseaux.

Pour la détection de sécurité, l'espace de travail Log Analytics est le dépôt central où toutes ces données convergent. Chaque règle d'alerte, de cahier de travail et d'automatisation interagit avec cet espace de travail, faisant de sa configuration la base d'une stratégie efficace de détection de menace.

Comment Azure surveille les différences de la Sentinelle Azure

Alors que Azure Monitor excelle au niveau de la télémétrie au niveau des ressources, Azure Sentinel est une solution dédiée de gestion d'informations et d'événements de sécurité (SIEM) construite sur les journaux Azure Monitor. De nombreuses organisations utilisent les deux : Azure Monitor fournit une surveillance de sécurité opérationnelle et une réponse automatisée pour les modèles connus, tandis que Sentinel ajoute des informations de menace, des analyses de comportement des utilisateurs et des entités (UEBA) et une gestion avancée des incidents.

Principales caractéristiques de la détection des menaces de sécurité

Pour détecter et réagir efficacement aux menaces, vous devez comprendre clairement les caractéristiques de sécurité d'Azure Monitor. Chacun joue un rôle spécifique dans le cycle de vie de détection à réponse.

Log Analytics et KQL

Log Analytics est le moteur de requête qui vous permet de rechercher à travers les téraoctets de données de log en quelques secondes. Par exemple, une requête pour trouver toutes les tentatives de connexion échouées dans la dernière heure pourrait ressembler à ceci:

SigninLogs
| where ResultType == "50057" // User account is disabled
| where TimeGenerated > ago(1h)
| project UserPrincipalName, IPAddress, TimeGenerated

KQL alimente chaque cahier de travail, alerte et tableau de bord dans Azure Monitor. Les analystes de sécurité devraient investir du temps dans l'apprentissage de modèles de requêtes communs pour les tentatives de force brute, les géolocalisations inhabituelles, l'escalade des privilèges et l'exfiltration de données.

Alertes et groupes d'action

Les alertes dans Azure Monitor sont le principal mécanisme de détection des menaces en temps réel. Vous pouvez créer des règles d'alerte basées sur les résultats de recherche de log (Log Alerts), des seuils métriques (Metric Alerts) ou des événements de log d'activité. Chaque règle est liée à un groupe d'action – une collection d'actions de notification et d'automatisation telles que email, SMS, webhook, création de tickets ITSM ou exécution de runbook Azure Automation.

Pour les scénarios de sécurité, utilisez des alertes de journal avec des paramètres de fréquence aussi bas qu'une minute. Par exemple, une alerte qui déclenche lorsque plus de dix connexions ratées de différentes adresses IP se produisent dans les cinq minutes peut indiquer une attaque de pulvérisation de mot de passe distribuée.

Cahiers de travail et tableaux de bord

Un centre d'opérations de sécurité (SOC) peut construire un manuel qui affiche des comptes en temps réel d'alertes de haute gravité, des IP de source supérieure et des graphiques de séries chronologiques de connexions anormales. Les cahiers de travail soutiennent la collaboration de l'équipe et peuvent être partagés entre les abonnements.

Intégration avec Microsoft Defender pour Cloud

Microsoft Defender for Cloud (anciennement Azure Security Center et Azure Defender) envoie ses alertes et recommandations de sécurité directement dans les journaux de surveillance Azure. Cela signifie que vous pouvez écrire des requêtes de ressources croisées qui combinent les résultats de Defender for Cloud (par exemple, -) avec des journaux VM bruts (par exemple, ProcessCreate events).

Comptes d'automatisation et livres de course

Une partie essentielle de la réponse est la vitesse. Les roundbooks Azure Automation (powerShell ou Python scripts) peuvent être déclenchés par des alertes pour agir immédiatement – par exemple, isoler un VM compromis en appliquant une règle de sécurité réseau, ou désactiver un compte utilisateur dans Azure Active Directory. Combinés avec les groupes d'action, les rowbooks permettent des playbooks entièrement automatisés qui s'exécutent en quelques secondes de détection.

Détection des menaces pour la sécurité avec Azure Monitor

La détection efficace des menaces dépend de la collecte des bonnes données et de l'écriture des requêtes intelligentes. Ci-dessous sont les étapes clés et les modèles d'attaque communs que vous pouvez découvrir.

Configuration de la collecte de données

Avant de pouvoir détecter quoi que ce soit, vous devez collecter des journaux auprès de toutes les sources pertinentes:

  • Machines virtuelles – Installez le Agent de monitoring d'Azure[ (AMA) sur Windows et Linux VMs. Activez la collection de journaux d'événements Windows (sécurité, système, application) et Syslog Linux. Pour Linux, envisagez de collecter des journaux audités pour l'activité de l'utilisateur.
  • – Configurer les paramètres de diagnostic pour chaque service (par exemple, Azure SQL Databases, Key Vault, Storage Accounts) pour le flux des journaux dans votre espace de travail Log Analytics.
  • Groupes de sécurité réseau – Activez les journaux de flux NSG et envoyez-les dans l'espace de travail via l'intégration de Network Watcher. Ces journaux révèlent qui est connecté à vos ressources et d'où.
  • Azure Active Directory – Renseignez les journaux de connexion, les journaux de vérification et les registres de fourniture dans l'espace de travail.
  • Applications – Utilisez Application Insights pour collecter des erreurs HTTP, des modèles d'appels de dépendance et un suivi personnalisé des événements.

Écrire des demandes de renseignements de la KQL pour les menaces communes

Une fois les données en circulation, construisez une bibliothèque de requêtes KQL qui ciblent les signaux à haute fidélité. Voici trois exemples pratiques :

Exemple 1 : Attaque de force brute contre le RDP/SSH

Event
| where TimeGenerated > ago(10m)
| where EventID == 4625 // Failed logon on Windows
| summarize FailedAttempts = count() by Account, Computer, SourceIP = IpAddress
| where FailedAttempts > 5

Pour Linux SSHD: combiner les entrées Syslog avec la facilité -auth et le message contenant -Mot de passe échoué.

Exemple 2: Exfiltration de données sortantes par trafic anomal

Combiner les registres de flux NSG avec les indicateurs de renseignements sur les menaces :

AzureNetworkAnalytics_CL
| where FlowType_s == "FlowEvent"
| where FlowDirection_s == "Outbound"
| where FlowStatus_s == "Allowed"
| where TimeGenerated > ago(1h)
| join kind=inner (
 ThreatIntelligenceIndicator
 | where Active == true
 ) on $left.DestinationIP_s == $right.NetworkIP
| project TimeGenerated, SourceIP_s, DestinationIP_s, Bytes_s, NetworkIP, ThreatType

Pour utiliser ce logiciel, configurez les indicateurs de renseignements de menace en utilisant l'API de renseignements de menace – Indicateurs de téléchargement ou intégrez-les à des flux tiers.

Exemple 3: Escalade de privilèges par exécution de PowerShell suspecte

Event
| where TimeGenerated > ago(1d)
| where EventID == 4688 // Process creation
| where CommandLine contains "powershell"
| where CommandLine contains "-EncodedCommand" or CommandLine contains "-WindowStyle Hidden"
| project TimeGenerated, Computer, UserName, CommandLine

Mise en place d'alertes intelligentes

Pour les alertes de log, envisager d'utiliser la recherche de log avec une fréquence de toutes les une ou cinq minutes. Définir les niveaux de sévérité : -Sev 0 , pour les attaques confirmées (par exemple, une alerte qui correspond à un indicateur connu de C2), -Sev 1 , pour les comportements suspects qui nécessitent une enquête (par exemple, 5 connexions ratées en 2 minutes d'une nouvelle IP).

Toujours tester les règles d'alerte dans un espace de travail non-production avant de déployer. Utilisez la fonction avertissement pour voir combien de fois la requête aurait été déclenchée au cours des 24 dernières heures.

Répondre aux menaces à la sécurité

La détection sans réponse n'est que du bruit. Azure Monitor fournit plusieurs moyens de transformer les alertes en action.

Remédiation automatisée via Azure Automation

Créer des runbooks pour les incidents courants. Par exemple, un runbook déclenché par une alerte --Compromisée peut :

  1. Désactiver le compte utilisateur en Azure AD en utilisant le cmdlet.
  2. Supprimer l'utilisateur de tous les groupes privilégiés.
  3. Revoquez tous les jetons de rafraîchissement via l'API graphique.
  4. Enregistrez les actions dans un espace de travail séparé - -Audit.

Relier ce runbook à la règle d'alerte Groupe d'action sous le type d'action -Runbook. Assurez-vous que le compte d'automatisation a les autorisations d'identité gérées correctes pour Azure AD et les opérations de ressources.

Déroulement des enquêtes manuelles

Pour les alertes qui nécessitent un jugement humain, concevoir des cahiers de travail qui guident les analystes par le triage. Un cahier de travail d'investigation typique peut comprendre :

  • Calendrier de la ressource touchée (alertes, logos, démarrage du processus)
  • Carte géographique des IP source
  • La question de corrélation croisée : par exemple, -A-t-il accédé récemment à d'autres ressources sensibles ?
  • Lien pour créer un incident Sentinel (si Sentinel est intégré) ou un ticket dans votre plateforme de gestion de service informatique.

Intégration avec la gestion des services informatiques (GITI)

Azure Monitor , le connecteur ITSM permet aux charges utiles d'alerte de créer automatiquement des tickets dans ServiceNow, Jira, ou d'autres systèmes. Cela garantit que l'équipe SOC , les workflows existants sont respectés.

Analyse après l'incident

Après un incident, utilisez Azure Monitor , rétention (jusqu'à deux ans pour les requêtes interactives, plus longtemps pour les journaux archivés) pour effectuer une analyse de cause racine. Créez un cahier de travail qui rejoue le calendrier de l'événement et identifie les lacunes dans les règles de détection.

Pratiques exemplaires pour l'utilisation du moniteur Azure dans les opérations de sécurité

1. Centraliser les journaux dans un espace de travail unique (ou Hub-and-Spoke)

Pour les grandes organisations, utilisez un espace de travail dédié à la sécurité Log Analytics par environnement (production, non-production). Pour une visibilité totale, envisagez un modèle hub-and-spoke où tous les logs circulent vers un espace de travail central pour la chasse à la cross-subscription, tandis que chaque unité d'affaires conserve un espace de travail régional pour la surveillance opérationnelle.

2. Définir les gravités et les ALS des alertes claires

Documenter ce que signifie chaque niveau de gravité et la rapidité avec laquelle il doit être traité.

  • Sev 0 (Critical): compromis confirmé ou infiltration de données – répondre dans les 15 minutes.
  • Sev 1 (Haut): activité suspecte nécessitant une enquête – répondre dans les 1 heures.
  • Sev 2 (Moyenne): violation de la politique ou anomalie mineure – répondre d'ici le jour ouvrable suivant.

Appliquer ces SLA en utilisant des actions d'escalade automatisées dans vos groupes d'action (par exemple, appeler un ingénieur de garde après 10 minutes d'alerte Sev 0 non reconnue).

3. Utiliser les identités gérées pour la sécurité Runbook

Ne jamais stocker les identifiants dans les runbooks. Utilisez Azure Automation pour autoriser les opérations des identités gérées avec l'authentification AD Azure. N'accordez à l'identité gérée que les autorisations minimales requises (par exemple, Virtual Machine Contributor pour démarrer/arrêter les VM, mais pas Contributor sur l'ensemble de l'abonnement).

4. Tune régulièrement des requêtes et des alertes

Les attaquants changent de tactique et votre environnement évolue. Planifiez un examen mensuel des règles d'alerte : désactivez les règles à faux-positifs, ajustez les seuils et ajoutez une nouvelle logique de détection pour les modèles d'attaque émergents (p. ex., détection de l'utilisation de nouvelles variantes de ransomware via les noms de processus).

5. Activer et examiner les journaux d'activités d'azur

Le journal d'activités enregistre tous les changements de plan de contrôle (par exemple, créer un VM, modifier des groupes de sécurité réseau, supprimer des ressources). Les opérations privilégiées telles que l'arrêt des journaux de sécurité ou la suppression des paramètres de diagnostic sont des drapeaux rouges.

6. Combiner avec Microsoft Defender pour les recommandations Cloud

Le défenseur du Cloud génère des recommandations de sécurité (par exemple, les machines virtuelles devraient être migrées vers de nouvelles ressources Azure ARM). Utilisez Azure Monitor pour suivre les ressources qui ne sont pas conformes. Créez des cahiers de travail personnalisés qui montrent les progrès de restauration des recommandations de haute gravité et déclenchez des runbooks automatisés pour corriger les erreurs communes (par exemple, permettant le cryptage sur les comptes de stockage).

Conclusion

Azure Monitor est bien plus qu'un tableau de bord santé pour votre infrastructure cloud. Lorsqu'il est configuré correctement, il devient un puissant système d'alerte rapide pour les menaces de sécurité – détecter les comportements anormaux, alerter les bonnes personnes et automatiser les réponses immédiates. En centralisant les journaux, en écrivant des requêtes précises KQL, en regroupant la détection avec des runbooks automatisés et en harmonisant régulièrement vos règles, votre organisation peut réduire considérablement le temps moyen de détection (MTTD) et le temps moyen de réponse (MTTR) aux incidents de sécurité.

Commencez par vérifier votre espace de travail actuel Log Analytics : assurez-vous de collecter les journaux qui comptent (signes AAD, événements VM Security, journaux de flux NSG) et que vous avez au moins une réponse automatisée pour un scénario hautement prioritaire. A partir de là, construisez une bibliothèque de requêtes de détection, alignez les seuils d'alerte et intégrez-vous à vos processus de gestion des incidents existants. Azure Monitor est l'épine dorsale d'une posture de sécurité proactive – assurez-vous qu'elle fonctionne pour vous.