Table of Contents
Azure Monitor ist nicht nur ein Performance-Telemetrie-Tool, sondern eine primäre Verteidigungslinie für Unternehmen, die Workloads in Microsoft Azure ausführen. Durch die kontinuierliche Erfassung und Analyse von Daten aus Ihrer gesamten Azure-Umgebung können Sicherheitsteams Anomalien erkennen, Vorfälle untersuchen und mit Cloud-Geschwindigkeit auf Bedrohungen reagieren. Dieser Artikel untersucht, wie Azure Monitor effektiv für die Erkennung und Reaktion von Sicherheitsbedrohungen verwendet wird, von der Konfiguration umfassender Protokollierung bis hin zur Automatisierung von Behebungsworkflows.
Azure Monitor verstehen
Azure Monitor ist ein plattformweiter Dienst, der eine einzige Glasscheibe für die Überwachung von Azure-Ressourcen, Anwendungen und lokalen Umgebungen (über verbundene Agenten) bereitstellt.
- Metriken – Numerische Zeitreihendaten (z. B. CPU-Prozentsatz, Festplatten-IOPS), die eine Trenderkennung in Echtzeit unterstützen.
- Logs – Strukturierte oder freiformige Textdaten, die aus Ressourcen, Anwendungen und Betriebssystemen gesammelt wurden, analysierbar mit Kusto Query Language (KQL).
- Diagnostik – Protokolle auf Plattformebene von Azure-Diensten, einschließlich Aktivitätsprotokolle (Steuerungsebenenereignisse) und Ressourcenprotokolle (Datenebenenereignisse).
- Insights – Zweckgebundene Erlebnisse für die Überwachung von Anwendungen, virtuellen Maschinen, Containern und Netzwerken.
Für die Sicherheitserkennung ist der Log Analytics-Arbeitsbereich das zentrale Repository, in dem all diese Daten zusammenlaufen. Jede Warnung, Arbeitsmappe und Automatisierungsregel interagiert mit diesem Arbeitsbereich und macht seine Konfiguration zur Grundlage einer effektiven Strategie zur Erkennung von Bedrohungen.
Wie sich Azure Monitor von Azure Sentinel unterscheidet
Während Azure Monitor sich auf Ressourcenebene auszeichnet, ist Azure Sentinel eine dedizierte Sicherheitsinformations- und Ereignismanagementlösung (SIEM), die auf Azure Monitor-Protokollen basiert. Viele Organisationen verwenden beides: Azure Monitor bietet operative Sicherheitsüberwachung und automatisierte Reaktion auf bekannte Muster, während Sentinel Bedrohungsinformationen, Benutzer- und Entitätsverhaltensanalysen (UEBA) und erweitertes Incident-Management hinzufügt. Für die Zwecke dieses Artikels konzentrieren wir uns auf Sicherheitsanwendungsfälle, die direkt in Azure Monitor erreichbar sind, wobei Sentinel diese Funktionen bei Bedarf erweitern kann.
Hauptmerkmale für die Erkennung von Sicherheitsbedrohungen
Um Bedrohungen effektiv zu erkennen und darauf zu reagieren, müssen Sie die sicherheitsrelevanten Funktionen von Azure Monitor genau kennen. Jede einzelne Funktion spielt eine spezifische Rolle im Detection-to-Response-Lebenszyklus.
Log Analytics und KQL
Log Analytics ist die Abfrage-Engine, mit der Sie innerhalb von Sekunden über Terabyte an Protokolldaten suchen können.
SigninLogs
| where ResultType == "50057" // User account is disabled
| where TimeGenerated > ago(1h)
| project UserPrincipalName, IPAddress, TimeGenerated
KQL unterstützt jede Arbeitsmappe, Warnung und Dashboard in Azure Monitor. Sicherheitsanalysten sollten Zeit in das Erlernen von gängigen Abfragemustern für Brute-Force-Versuche, ungewöhnliche Geo-Locations, Privilegeskalation und Datenexfiltration investieren.
Alarm- und Aktionsgruppen
Warnungen in Azure Monitor sind der primäre Mechanismus zum Erkennen von Bedrohungen in Echtzeit. Sie können Warnregeln basierend auf Protokollsuchergebnissen (Log Alerts), metrischen Schwellenwerten (Metric Alerts) oder Aktivitätsprotokollereignissen erstellen. Jede Regel ist mit einer Aktionsgruppe verknüpft - einer Sammlung von Benachrichtigungs- und Automatisierungsaktionen wie E-Mail, SMS, Webhook, ITSM-Ticketerstellung oder Azure Automation Runbook-Ausführung.
Für Sicherheitsszenarien verwenden Sie Log Alerts mit Frequenzeinstellungen von nur einer Minute. z. B. kann eine Warnung, die auslöst, wenn mehr als zehn fehlgeschlagene Anmeldungen von verschiedenen IP-Adressen innerhalb von fünf Minuten auftreten, auf einen verteilten Passwortspray-Angriff hinweisen.
Arbeitsmappen und Dashboards
Azure Monitor Workbooks bieten interaktive, parametrisierte Berichte, die Sicherheitsdaten visualisieren. Ein Security Operations Center (SOC) kann eine Arbeitsmappe erstellen, die Echtzeit-Anzahl von Warnmeldungen mit hohem Schweregrad, Top-Source-IPs und Zeitreihendiagramme von anomalen Logins anzeigt. Arbeitsmappen unterstützen die Zusammenarbeit zwischen Teams und können über Abonnements hinweg geteilt werden.
Integration mit Microsoft Defender für Cloud
Microsoft Defender for Cloud (ehemals Azure Security Center und Azure Defender) sendet seine Sicherheitsbenachrichtigungen und -empfehlungen direkt in Azure Monitor Logs. Das bedeutet, dass Sie ressourcenübergreifende Abfragen schreiben können, die Defender for Cloud-Erkenntnisse (z. B. „Verdächtiger Prozess ausgeführt) mit rohen VM-Protokollen (z. B. ProcessCreate-Ereignisse) kombinieren. Die Integration macht Azure Monitor zu einem einheitlichen Jagdgebiet für Infrastrukturgesundheit und Sicherheitslage.
Automatisierungskonten und Runbooks
Ein entscheidender Teil der Antwort ist die Geschwindigkeit. Azure Automation-Laufbücher (PowerShell- oder Python-Skripte) können durch Warnungen ausgelöst werden, um sofortige Maßnahmen zu ergreifen, z. B. durch die Isolierung einer kompromittierten VM durch Anwendung einer Netzwerksicherheitsregel oder die Deaktivierung eines Benutzerkontos in Azure Active Directory. In Kombination mit Aktionsgruppen ermöglichen Runbooks vollautomatische Wiedergabebücher, die innerhalb von Sekunden nach Erkennung ausgeführt werden.
Sicherheitsbedrohungen mit Azure Monitor erkennen
Die effektive Erkennung von Bedrohungen hängt davon ab, die richtigen Daten zu sammeln und intelligente Abfragen zu schreiben.
Konfiguration der Datenerfassung
Bevor Sie etwas entdecken können, müssen Sie Protokolle aus allen relevanten Quellen sammeln:
- Virtuelle Maschinen – Installieren Sie den Azure Monitor Agent (AMA) unter Windows und Linux VMs. Aktivieren Sie die Sammlung von Windows Event Logs (Sicherheit, System, Anwendung) und Linux Syslog. Für Linux sollten Sie das Sammeln von geprüften Protokollen für Benutzeraktivitäten in Betracht ziehen.
- Azure Resources – Konfigurieren Sie die Diagnoseeinstellungen für jeden Dienst (z. B. Azure SQL-Datenbanken, Key Vault, Storage Accounts), um Protokolle in Ihren Log Analytics-Arbeitsbereich zu streamen.
- Netzwerksicherheitsgruppen – Aktivieren Sie NSG-Flow-Logs und senden Sie sie über die Network Watcher-Integration an den Arbeitsbereich.
- Azure Active Directory – Anmeldeprotokolle, Überwachungsprotokolle und Bereitstellungsprotokolle für den Arbeitsbereich streamen.
- Anwendungen – Verwenden Sie Application Insights, um HTTP-Fehler, Abhängigkeitsaufrufmuster und benutzerdefinierte Ereignisverfolgung zu sammeln. Ungewöhnliche Fehlerspitzen können einen DoS- oder Credential-Stuffing-Angriff signalisieren.
Schreiben von KQL-Abfragen für gemeinsame Bedrohungen
Wenn Daten fließen, erstellen Sie eine Bibliothek mit KQL-Abfragen, die auf High-Fidelity-Signale abzielen.
Beispiel 1: Brute-Force-Angriff auf 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
Für Linux SSHD: Kombinieren Sie Syslog-Einträge mit der Einrichtung "auth" und der Nachricht mit "Failed password".
Beispiel 2: Exfiltration ausgehender Daten über anomalen Verkehr
Kombinieren Sie NSG-Flow-Logs mit Threat Intelligence-Indikatoren:
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
Um dies zu verwenden, konfigurieren Sie Threat Intelligence-Indikatoren mithilfe der Threat Intelligence – Upload Indicators API oder integrieren Sie sie in Feeds von Drittanbietern.
Beispiel 3: Privilegeskalation über Suspicious PowerShell Execution
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
Smart Alerts einrichten
Vermeiden Sie Alarmmüdigkeit, indem Sie Ihre Regeln anpassen. Verwenden Sie dynamische Schwellenwerte für metrische Warnungen (z. B. ausgehende Traffic-Spikes mehr als 3 Standardabweichungen über dem Ausgangswert). Für Protokollalarme sollten Sie die benutzerdefinierte Protokollsuche mit einer Häufigkeit von ein oder fünf Minuten verwenden. Legen Sie Schweregrade fest: “Sev 0” für bestätigte Angriffe (z. B. eine Warnung, die mit einem bekannten C2-Indikator übereinstimmt), “Sev 1” für verdächtiges Verhalten, das untersucht werden muss (z. B. 5 fehlgeschlagene Anmeldungen in 2 Minuten von einer neuen IP).
Testen Sie immer Warnregeln in einem nicht-produktionsbezogenen Arbeitsbereich, bevor Sie bereitstellen, und verwenden Sie die Funktion alertvorschau, um zu sehen, wie oft die Abfrage in den letzten 24 Stunden ausgelöst worden wäre.
Reaktion auf Sicherheitsbedrohungen
Erkennung ohne Antwort ist nur Rauschen. Azure Monitor bietet verschiedene Möglichkeiten, Warnungen in Aktion zu verwandeln.
Automatisierte Sanierung über Azure Automation
Erstellen Sie Runbooks für häufige Vorfälle, z. B. ein Runbook, das durch eine Warnung "Kompromittierter Benutzer" ausgelöst wird, kann:
- Deaktivieren Sie das Benutzerkonto in Azure AD mit dem Cmdlet .
- Entfernen Sie den Benutzer aus allen privilegierten Gruppen.
- Widerrufen Sie alle Aktualisierungstoken über Graph API.
- Protokollieren Sie die Aktionen in einem separaten "Audit"-Arbeitsbereich.
Verknüpfen Sie dieses Runbook mit der Aktionsgruppe der Alarmregel unter dem Aktionstyp "Runbook". Stellen Sie sicher, dass das Automatisierungskonto über die richtigen verwalteten Identitätsberechtigungen für Azure AD und Ressourcenoperationen verfügt.
Manuelle Untersuchungs-Workflows
Für Warnungen, die menschliches Urteilsvermögen erfordern, entwerfen Sie Arbeitsmappen, die Analysten durch Triage führen. Eine typische Untersuchungsmappe könnte Folgendes beinhalten:
- Zeitleiste der betroffenen Ressource (Warnungen, Anmelder, Prozessstarts)
- Geo-Map der IP-Quelle
- Querkorrelationsabfrage: z.B. „Hat dieser Benutzer in letzter Zeit auf andere sensible Ressourcen zugegriffen?
- Verknüpfen Sie einen Sentinel-Vorfall (wenn Sentinel integriert ist) oder ein Ticket in Ihrer IT-Service-Management-Plattform.
Integration mit IT Service Management (ITSM)
Der ITSM-Connector von Azure Monitor ermöglicht es Alarm-Nutzlasten, Tickets automatisch in ServiceNow, Jira oder anderen Systemen zu erstellen. Dadurch wird sichergestellt, dass die vorhandenen Workflows des SOC-Teams respektiert werden. Der Connector bildet den Azure Monitor-Schweregrad der ITSM-Dringlichkeit zu und der detaillierte Alarmkontext ist in der Ticketbeschreibung enthalten.
Analyse nach dem Vorfall
Verwenden Sie nach einem Vorfall die Aufbewahrung von Azure Monitor (bis zu zwei Jahre für interaktive Abfragen, länger für archivierte Protokolle), um eine Ursachenanalyse durchzuführen. Erstellen Sie eine Arbeitsmappe, die die Ereigniszeitleiste wiedergibt und Lücken in den Erkennungsregeln identifiziert. Aktualisieren Sie Ihre Warnbibliothek basierend auf den gewonnenen Lektionen.
Best Practices für die Verwendung von Azure Monitor in Sicherheitsoperationen
1. Zentralisieren von Protokollen in einem einzelnen Arbeitsbereich (oder Hub-and-Spoke)
Für große Unternehmen sollten Sie einen dedizierten Log Analytics-Arbeitsbereich für die Sicherheit pro Umgebung (Produktion, Nichtproduktion) verwenden.Bedenken Sie für vollständige Sichtbarkeit ein Hub-and-Speichen-Modell, bei dem alle Protokolle zu einem zentralen Arbeitsbereich für die abonnementübergreifende Jagd fließen, während jede Geschäftseinheit einen regionalen Arbeitsbereich für die operative Überwachung behält.
2. Klare Warnhinweise und Sicherheitsbedenken
Dokumentieren Sie, was jede Schweregrad bedeutet und wie schnell sie angegangen werden muss, z. B.:
- Sev 0 (kritisch): bestätigter Kompromiss oder Datenexfiltration – antworten Sie innerhalb von 15 Minuten.
- Sev 1 (High): verdächtige Aktivität, die eine Untersuchung erfordert – reagieren Sie innerhalb von 1 Stunde.
- Sev 2 (Mittel): Richtlinienverletzung oder kleinere Anomalie - reagieren Sie bis zum nächsten Werktag.
Erzwingen Sie diese SLAs mithilfe automatisierter Eskalationsaktionen in Ihren Aktionsgruppen (z. B. rufen Sie einen Bereitschaftstechniker nach 10 Minuten unbestätigter Sev 0-Benachrichtigung an).
3. Verwaltete Identitäten für Runbook Security verwenden
Speichern Sie niemals Anmeldeinformationen in Runbooks. Verwenden Sie Azure Automation Managed Identitys mit Azure AD-Authentifizierung, um Vorgänge zu autorisieren. Gewähren Sie der Managed Identity nur die minimalen erforderlichen Berechtigungen (z. B. Virtual Machine Contributor zum Starten / Stoppen von VMs, nicht jedoch Contributor für das gesamte Abonnement).
4. Regelmäßige Abstimmung von Abfragen und Warnungen
Angreifer ändern ihre Taktik und Ihre Umgebung entwickelt sich. Planen Sie eine monatliche Überprüfung der Warnregeln: Deaktivieren Sie falsch-positiv-anfällige Regeln, passen Sie Schwellenwerte an und fügen Sie neue Erkennungslogik für auftretende Angriffsmuster hinzu (z. B. Erkennung der Verwendung neuer Ransomware-Varianten über Prozessnamen). Verwenden Sie die integrierte Registerkarte Alert Rule Costs von Azure Monitor, um zu sehen, welche Regeln die meisten Rechenressourcen verbrauchen und optimieren Sie sie.
5. Azure Activity Logs aktivieren und überprüfen
Das Activity Log zeichnet alle Änderungen an Steuerungsebenen auf (z. B. Erstellen einer VM, Ändern von Netzwerksicherheitsgruppen, Löschen von Ressourcen). Privilegierte Operationen wie das Deaktivieren von Sicherheitsprotokollen oder Löschen von Diagnoseeinstellungen sind rote Flaggen. Erstellen einer Warnung, die ausgelöst wird, wenn eine Diagnoseeinstellung aus einer Ressource entfernt wird - dies ist eine gängige "live off the land" -Technik, die von fortgeschrittenen Gegnern verwendet wird.
6. Kombinieren Sie mit Microsoft Defender für Cloud-Empfehlungen
Defender for Cloud generiert Sicherheitsempfehlungen (z. B. „Virtuelle Maschinen sollten auf neue Azure ARM-Ressourcen migriert werden). Verwenden Sie Azure Monitor, um zu verfolgen, welche Ressourcen nicht den Anforderungen entsprechen. Erstellen Sie benutzerdefinierte Arbeitsmappen, die den Fortschritt der Behebung von Empfehlungen mit hohem Schweregrad anzeigen, und lösen Sie automatisierte Runbooks aus, um häufige Fehlkonfigurationen zu beheben (z. B. die Verschlüsselung von Speicherkonten).
Schlussfolgerung
Azure Monitor ist weit mehr als ein Gesundheits-Dashboard für Ihre Cloud-Infrastruktur. Wenn es richtig konfiguriert ist, wird es zu einem leistungsstarken Frühwarnsystem für Sicherheitsbedrohungen - Erkennung von anomalem Verhalten, Alarmierung der richtigen Personen und Automatisierung von Sofortreaktionen. Durch Zentralisierung von Protokollen, Schreiben präziser KQL-Abfragen, Bündelung der Erkennung mit automatisierten Runbooks und regelmäßiges Tuning Ihrer Regeln kann Ihr Unternehmen die mittlere Zeit zur Erkennung (MTTD) und die mittlere Zeit zur Reaktion (MTTR) drastisch reduzieren auf Sicherheitsvorfälle.
Beginnen Sie mit der Überprüfung Ihres aktuellen Log Analytics-Arbeitsbereichs: Stellen Sie sicher, dass Sie die wichtigen Protokolle sammeln (AAD-Anmeldungen, VM Security-Ereignisse, NSG-Flow-Logs) und dass Sie mindestens eine automatisierte Antwort für ein Szenario mit hoher Priorität haben. Von dort aus erstellen Sie eine Bibliothek mit Erkennungsabfragen, stimmen Sie Alarmschwellen ab und integrieren Sie sie in Ihre bestehenden Incident-Management-Prozesse. Azure Monitor ist das Rückgrat einer proaktiven Sicherheitslage - stellen Sie sicher, dass es für Sie funktioniert.