Azure Activity Log und Ressourcenlogs exportieren

Kurz gesagt. Bevorzugen Sie für eine Untersuchung JSON gegenüber dem Portal-CSV. Verwenden Sie az monitor activity-log list mit explizitem --start-time, --end-time und --max-events – die Standardwerte sind ein Zeitfenster von 6 Stunden und 50 Ereignisse. Exportieren Sie das mandantenweite Log (Directory Activity) separat mit az rest: Dort wird elevateAccess protokolliert. Senden Diagnoseeinstellungen die Logs bereits an ein Speicherkonto, kopieren Sie die insights-*-Container unverändert. Lassen Sie die Originale unangetastet; öffnen und speichern Sie sie nie in Excel.

Eine Azure-Untersuchung ist nur so gut wie ihr Export. Ich habe mehr Fälle an einer abgeschnittenen CSV scheitern sehen als an einem geschickten Angreifer. Hier die praktische Checkliste, Quelle für Quelle, mit dem, was jedes Format bewahrt und verliert.

Die richtige Quelle für jedes Log wählen

Activity Log mit der Azure CLI

Die CLI liefert das REST-Schema: Claims, httpRequest.clientIpAddress, properties.requestbody, wenn vorhanden. Genau das brauchen Sie.

az login
az account set --subscription <subscription-id>
az monitor activity-log list \
  --start-time 2026-08-01T00:00:00Z \
  --end-time   2026-09-15T00:00:00Z \
  --max-events 100000 \
  > activity-<subscription-id>.json

Zwei Standardwerte verdienen eine Warnung. Laut der Referenz zu az monitor activity-log ist --max-events standardmäßig 50 und --offset 6h. Lassen Sie beides weg, erhalten Sie eine saubere, gültige JSON-Datei, die fast nichts enthält. Prüfen Sie immer den ersten und letzten eventTimestamp der Ausgabe gegen das angefragte Zeitfenster.

Wiederholen Sie das für jedes Abonnement. Die CLI listet die neuesten Ereignisse zuerst; die Reihenfolge ist für den Analyzer egal, er sortiert und entfernt Duplikate.

Das mandantenweite Log

Einige der wichtigsten Ereignisse stehen in keinem Abonnement-Log. Die Zugriffserhöhung etwa wird auf Mandantenebene protokolliert. Microsoft dokumentiert den Abruf mit az rest gegen den mandantenweiten Endpunkt (Protokolleinträge zur Zugriffserhöhung):

az rest --method get \
  --url "https://management.azure.com/providers/Microsoft.Insights/eventtypes/management/values?api-version=2015-04-01&\$filter=eventTimestamp ge '2026-08-01T00:00:00Z'" \
  > activity-tenant.json

Dieselbe Seite weist darauf hin, dass Einträge zur Zugriffserhöhung auch in den Microsoft Entra-Überwachungsprotokollen erscheinen (zum Zeitpunkt des Schreibens als Vorschaufunktion).

Activity Log aus dem Portal

Monitor → Activity log, Timespan auf das Vorfallsfenster setzen, Standardfilter entfernen, dann Download as CSV. Microsoft warnt, dass große Exporte langsam sind, und empfiehlt, den Zeitraum einzugrenzen (Aktivitätsprotokoll in eine Datei exportieren). Die CSV taugt für einen schnellen Blick, verliert aber Details gegenüber JSON; der Analyzer liest sie nach bestem Bemühen anhand der Anzeigenamen.

Exporte aus Log Analytics

Leiten Diagnoseeinstellungen die Logs bereits in einen Arbeitsbereich, ist das die bequemste Quelle, weil die Aufbewahrung dort deutlich länger als 90 Tage sein kann.

AzureActivity
| where TimeGenerated between (datetime(2026-08-01) .. datetime(2026-09-15))

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where TimeGenerated between (datetime(2026-08-01) .. datetime(2026-09-15))

StorageBlobLogs
| where TimeGenerated between (datetime(2026-08-01) .. datetime(2026-09-15))

Exportieren Sie alle Spalten als CSV oder verwenden Sie az monitor log-analytics query -w <workspace-id> --analytics-query "…" > out.json. Microsoft weist darauf hin, dass Werte in AzureActivity unterschiedlich groß- und kleingeschrieben sein können; filtern Sie in KQL also ohne Beachtung der Groß-/Kleinschreibung. Der Abgleich des Analyzers ignoriert die Groß-/Kleinschreibung.

Exporte in Speicherkonten (Diagnoseeinstellungen)

Eine Diagnoseeinstellung, die in ein Speicherkonto archiviert, schreibt einen Blob pro Stunde in einen dokumentierten Verzeichnisbaum. Für das Activity Log:

insights-activity-logs/resourceId=/SUBSCRIPTIONS/{sub}/y=2026/m=09/d=14/h=02/m=00/PT1H.json

Ressourcenlogs folgen demselben Muster in einem eigenen Container, etwa insights-logs-auditevent für Key Vault (Key Vault-Protokollierung). Kopieren Sie ganze Container mit Azure Storage Explorer oder AzCopy:

azcopy copy "https://<account>.blob.core.windows.net/insights-activity-logs?<SAS>" ./export --recursive

Behalten Sie die Ordnerstruktur bei. Der Analyzer liest den resourceId=/…/PT1H.json-Baum direkt aus einem Ordner oder ZIP. Liegt derselbe Tag sowohl im Speicherexport als auch in einem CLI-Export vor, werden Duplikate zusammengeführt.

Eine Vorsichtsmaßnahme, wenn Sie im betroffenen Abonnement arbeiten: Die SAS, die Sie für die Kopie erstellen, ist selbst ein Ereignis (listAccountSas oder listServiceSas, wenn über ARM erzeugt). Notieren Sie Uhrzeit und IP, damit Sie später nicht gegen sich selbst ermitteln.

Ressourcenlogs von Key Vault und Storage

Beide müssen ausdrücklich aktiviert werden. Unter Key Vault → Diagnostic settings muss die Kategorie AuditEvent irgendwohin gesendet werden; Speicherkonten brauchen StorageRead, StorageWrite und StorageDelete auf der Unterressource blob. Microsoft zufolge sind Key Vault-Logs spätestens zehn Minuten nach dem Vorgang verfügbar.

Gab es vor dem Vorfall keine Diagnoseeinstellung, stellt das Aktivieren jetzt keine vergangenen Lesezugriffe wieder her. Aktivieren Sie sie trotzdem für das, was noch kommt, und halten Sie es im Bericht fest. Der Key Vault-Artikel und der Storage-Artikel erklären, was diese Logs belegen.

NSG- und VNet-Flow-Logs

Unter Network Watcher → Flow logs sehen Sie, welches Speicherkonto sie empfängt. Laden Sie nur die relevanten Stunden und Subnetze herunter; Flow-Logs sind groß. NSG-Flow-Logs landen in insights-logs-networksecuritygroupflowevent, VNet-Flow-Logs in insights-logs-flowlogflowevent. Microsoft hat angekündigt, dass NSG-Flow-Logs am 30. September 2027 eingestellt werden und neue nicht mehr angelegt werden können; VNet-Flow-Logs sind der Ersatz. Der Artikel zu Flow-Logs beschreibt die Tupelformate.

Warnungen von Defender for Cloud

Entweder Security alerts → auswählen → Download CSV report oder die REST-API:

az rest --method get \
  --url "https://management.azure.com/subscriptions/<id>/providers/Microsoft.Security/alerts?api-version=2022-01-01" \
  > defender-alerts.json

Welche Formate der Analyzer liest (und welche nicht)

Der Azure Forensics Analyzer akzeptiert JSON Lines, {"records": […]}-Hüllen, JSON-Arrays, CSV mit Zeilenumbrüchen in Anführungszeichen, .gz-Dateien, Ordner und ZIPs. Jede übersprungene Datei wird begründet. Zwei Formate werden nicht unterstützt: Avro (Event Hubs Capture) und Parquet – exportieren Sie stattdessen JSON oder CSV. UTF-16-Dateien (manchmal durch PowerShell-Umleitung unter Windows erzeugt) müssen als UTF-8 neu gespeichert werden.

Beweiskette in Kürze

• Bilden Sie für jede exportierte Datei einen Hash (sha256sum / Get-FileHash) und notieren Sie, wer sie wann mit welchem Konto exportiert hat.
• Bearbeiten Sie nie die Originale. Arbeiten Sie mit Kopien.
• Excel schreibt Zeitstempel und lange Zahlen stillschweigend um. Öffnen und speichern Sie keine Log-CSV.
• Dokumentieren Sie Zeitraum und Filter jedes Exports: „keine Ereignisse“ bedeutet nichts, wenn der Filter falsch war.

Verwandte Artikel

• Azure-Abonnement kompromittiert? Leitfaden zur Reaktion
• Azure Activity Log Schritt für Schritt analysieren
• Grenzen der Azure-Logforensik: Aufbewahrung und Lücken