Grenzen der Azure-Logforensik: Aufbewahrung und Lücken
Das Azure Activity Log wird 90 Tage aufbewahrt, Ressourcenlogs sind standardmäßig aus. Was jedes Log nicht verrät und wie Sie ein ehrliches Fazit formulieren.
Kurz gesagt. Azure bewahrt das Activity Log 90 Tage auf und löscht es dann. Ressourcenlogs – Key Vault, Storage und der Großteil der Aktivität auf der Datenebene – sind standardmäßig aus und existieren erst ab dem Moment, in dem eine Diagnoseeinstellung angelegt wurde. Flow-Logs müssen je NSG oder VNet aktiviert werden. Mandantenweite Ereignisse wie elevateAccess fehlen in Abonnement-Exporten. Regeln sind Heuristiken mit Schwellenwerten und Lernzeiträumen. Nichts davon macht Azure-Forensik aussichtslos; es macht es aber wichtig, genau festzuhalten, was vorlag, und die Schlussfolgerungen entsprechend zu formulieren.
Jeder Azure-Bericht, den ich schreibe, hat einen Abschnitt „Umfang und Grenzen“. Das ist kein Textbaustein. Dort erfährt der Leser, ob „kein Hinweis auf Datenzugriff“ bedeutet „wir haben geprüft und nichts ist passiert“ oder „es gab nichts zu prüfen“.
Aufbewahrung: die 90-Tage-Uhr
Laut Microsoft bewahrt Azure die Ereignisse des Aktivitätsprotokolls 90 Tage auf und löscht sie dann (Aktivitätsprotokoll in Azure Monitor). Die REST-API verlangt, dass beide Enden Ihres Zeitraums in diesem Fenster liegen. Die Folgen:
- Ein am Tag 100 entdeckter Einbruch hat seine ersten zehn Tage Verlauf der Steuerungsebene verloren – es sei denn, eine Diagnoseeinstellung hat das Activity Log an Log Analytics (konfigurierbare Aufbewahrung, laut Microsoft bis zu 12 Jahre), ein Speicherkonto oder Event Hubs exportiert.
- Der Ersteller einer Ressource wird nur im Activity Log erfasst. Nach 90 Tagen ohne Export bleibt „Wer hat diese VM erstellt?“ womöglich unbeantwortet.
- Früh zu exportieren ist die wertvollste Maßnahme der ersten Stunde (Exportleitfaden).
Ressourcenlogs haben gar keine Plattform-Aufbewahrung: Sie liegen dort, wohin die Diagnoseeinstellung sie sendet, mit der Aufbewahrung dieses Ziels.
Fehlende Quellen: Protokollierung, die nie an war
| Frage | Benötigtes Log | Standardmäßig an? | Falls es aus war |
|---|---|---|---|
| Wer hat was in Azure geändert? | Activity Log | Ja (90 Tage) | — |
| Wer hat welches Key Vault-Secret gelesen? | Key Vault AuditEvent | Nein | Nicht beantwortbar; jedes erreichbare Secret rotieren |
| Welche Blobs wurden heruntergeladen? | StorageRead / StorageBlobLogs | Nein | Aus Azure nicht beantwortbar; Inhalt des Kontos als offengelegt betrachten |
| Hat eine VM mit dem Angreifer gesprochen? | NSG-/VNet-Flow-Logs | Nein | Die VM selbst, Firewall- oder Proxy-Logs prüfen |
| Wie wurde die Identität kompromittiert? | Entra ID-Anmelde- und Überwachungsprotokolle | Ja (Aufbewahrung je nach Lizenz) | Eigene Untersuchung (m365forensics.com) |
| Was lief auf der VM? | Logs des Gastbetriebssystems, Datenträger | Abhängig von der VM | Datenträgerforensik |
Der Abdeckungsblock des Analyzers macht das explizit: Quellen „nicht bereitgestellt“, Regeln, die „nicht laufen konnten“, und warum. Übernehmen Sie ihn in Ihren Bericht.
Lücken, die der Angreifer schafft
Gelöschte Diagnoseeinstellungen erzeugen ab dem Zeitstempel der Löschung eine Lücke; deaktivierte Defender-Pläne stoppen Erkennungen; gelöschte Log-Blobs entfernen Verlauf aus einem Archiv. Das ist etwas anderes als „nie aktiviert“: Die Löschung selbst ist ein Beleg und steht im Activity Log. Siehe Defense Evasion.
Blinde Flecken der Logs selbst
Selbst wenn alle Logs aktiv sind:
- Der Inhalt von Run-Command-Skripten steht in der Regel nicht im Activity Log (Run Command-Angriffe).
- Die Erstellung einer SAS, clientseitig signiert, wird nirgends protokolliert; Microsoft zufolge lässt sich die Generierung von SAS-Token nicht überwachen (SAS-Übersicht).
- Flow-Logs enthalten keine Nutzdaten und sehen keine Internet-Clients, die direkt mit PaaS-Endpunkten sprechen (Flow-Logs).
- Lesevorgänge auf der Steuerungsebene (Ressourcen auflisten, Konfiguration lesen) stehen in der Regel nicht im Activity Log; Aufklärung bleibt weitgehend unsichtbar.
- Mandantenweite Ereignisse wie
elevateAccessliegen im mandantenweiten Log, nicht in Abonnement-Exporten. - Latenz. Microsoft nennt 3 bis 20 Minuten bis zur Verfügbarkeit im Activity Log und bis zu 10 Minuten für Key Vault-Logs; ein Export während eines laufenden Vorfalls kann die letzten Minuten verpassen.
- Groß-/Kleinschreibung in Log Analytics. Microsoft weist darauf hin, dass Werte in
AzureActivityunterschiedlich geschrieben sein können; Zeichenkettenvergleiche müssen die Schreibung ignorieren.
Grenzen des Analyzers
Ehrlich auch beim Werkzeug:
- Er sieht nur, was Sie laden. Kein API-Zugriff auf Ihren Mandanten – absichtlich.
- Erstauftreten-Regeln brauchen mehr als 72 Stunden Verlauf vor der verdächtigen Aktivität. Bei einem kurzen Export können
AZ-KV-001,AZ-ID-001,AZ-ID-002undAZ-VM-004nicht laufen. - Schwellenwerte lassen sich umgehen. Ein Massendownload erfordert 50 verschiedene Blobs in einer Stunde von einer Identität und IP; die Secret-Enumeration 8 verschiedene Objekte in einer Stunde. Ein geduldiger Angreifer bleibt darunter.
- Legitime Automatisierung löst Regeln aus. Jede Regel dokumentiert ihre bekannten False Positives.
- Formate. Avro (Event Hubs Capture) und Parquet werden nicht gelesen; die Portal-CSV nach bestem Bemühen; UTF-16 muss konvertiert werden.
- Anzeigegrenze. Ab 100.000 Ereignissen listet die Tabelle nicht weiter, jedes Ereignis wird aber trotzdem analysiert und gezählt.
- Entra ID liegt außerhalb des Umfangs. Identität gehört zu m365forensics.com.
Das Fazit formulieren
Formulierungen, die ich je nach verfügbaren Daten verwende:
| Situation | Belastbare Formulierung |
|---|---|
| Key Vault-Logs für den ganzen Zeitraum vorhanden, keine verdächtigen Zugriffe | „Kein Hinweis auf Secret-Zugriffe durch die kompromittierte Identität in den Key Vault-Audit-Logs für <Zeitraum>.“ |
| Key Vault-Logs fehlen | „Die Key Vault-Audit-Protokollierung war nicht aktiviert; Secret-Zugriffe lassen sich nicht bestimmen. Alle für die Identität erreichbaren Secrets gelten als offengelegt.“ |
| Logs während des Vorfalls gelöscht | „Die Key Vault-Protokollierung wurde vom Angreifer um <Uhrzeit> deaktiviert; Aktivität danach lässt sich nicht bestimmen.“ |
| Urteil Unauffällig, vollständige Abdeckung | „In <Quellen> für <Zeitraum> hat keine Erkennung gegriffen. Aktivität unterhalb der Erkennungsschwellen ist damit nicht ausgeschlossen.“ |
Das Urteil eines automatischen Werkzeugs ist der Anfang dieses Absatzes, nicht sein Schluss.
FAQ
Wie lange bewahrt Azure das Activity Log auf?
90 Tage. Danach löscht Azure die Ereignisse. Für eine längere Aufbewahrung braucht es eine Diagnoseeinstellung, die das Activity Log an einen Log Analytics-Arbeitsbereich, ein Speicherkonto oder Event Hubs sendet.
Bekomme ich Key Vault- oder Storage-Zugriffslogs für einen Zeitraum, in dem die Protokollierung aus war?
Nein. Ressourcenlogs werden nur geschrieben, solange eine Diagnoseeinstellung sie irgendwohin sendet. Eine jetzt angelegte Einstellung füllt die Vergangenheit nicht auf.
Bedeutet das Urteil Unauffällig, dass das Abonnement nicht kompromittiert war?
Nein. Es bedeutet, dass in den bereitgestellten Logs keine Erkennungsregel gegriffen hat. Prüfen Sie, welche Quellen vorhanden waren, welche Regeln nicht laufen konnten und ob das Aufbewahrungsfenster den verdächtigen Zeitraum abdeckt.