Key Vault-Audit-Logs: Wer hat welches Secret gelesen?

Kurz gesagt. Lesezugriffe auf Secrets sind nur im Key Vault-Log AuditEvent sichtbar – und nur, wenn eine Diagnoseeinstellung es vor dem Vorfall irgendwohin gesendet hat. Suchen Sie nach SecretGet / SecretList durch einen Prinzipal, der den Tresor nie zuvor berührt hat, nach vielen verschiedenen Secrets, die ein Prinzipal innerhalb einer Stunde liest, und nach einem VaultAccessPolicyChangedEventGridNotification oder Microsoft.KeyVault/vaults/accessPolicies/write kurz davor. Im Modell der Zugriffsrichtlinien kann sich jeder mit Contributor auf dem Tresor selbst Datenzugriff gewähren. Gibt es keine Logs, rotieren Sie jedes Secret, das die Identität erreichen konnte.

In den Key Vault gehen Angreifer, sobald sie mit echten Rechten Fuß gefasst haben, denn dort liegen das Datenbankpasswort, der API-Schlüssel des Zahlungsdienstleisters und die Passphrase der Backup-Verschlüsselung. Die gute Nachricht: Ist die Protokollierung aktiv, gehört das Key Vault-Audit-Log zu den präzisesten Quellen in Azure. Jede Anfrage wird mit Objekt-URI, Identität des Aufrufers und IP erfasst.

Was das AuditEvent-Log erfasst

Die Referenz zur Key Vault-Protokollierung dokumentiert das Schema. Die Felder, die Sie in einer Untersuchung nutzen:

Dieselben Daten landen in der Tabelle AzureDiagnostics (mit abgeflachten identity_claim_*-Spalten) oder in der ressourcenspezifischen Tabelle AZKVAuditLogs in Log Analytics. In einem Speicherkonto werden sie in den Container insights-logs-auditevent geschrieben. Laut Microsoft sind die Einträge spätestens zehn Minuten nach dem Vorgang verfügbar.

Die entscheidenden Operationsnamen

Operationsnamen folgen dem Muster ObjektVerb. Relevant für Diebstahl von Anmeldeinformationen:

Auf der Steuerungsebene erfasst das Activity Log Microsoft.KeyVault/vaults/accessPolicies/write (Änderung der Zugriffsrichtlinie), Microsoft.KeyVault/vaults/write (Tresoreigenschaften, darunter vorläufiges Löschen und Löschschutz) und Microsoft.KeyVault/locations/deletedVaults/purge/action.

Rechteausweitung über die Zugriffsrichtlinie

Key Vault kennt zwei Berechtigungsmodelle. Mit Azure RBAC erfordert die Vergabe von Datenzugriff Owner oder User Access Administrator. Beim älteren Modell der Zugriffsrichtlinien warnt Microsoft, dass Benutzer mit Contributor, Key Vault Contributor oder einer Rolle mit Microsoft.KeyVault/vaults/write sich über eine Zugriffsrichtlinie selbst Zugriff auf die Datenebene gewähren können (Azure RBAC oder Zugriffsrichtlinien).

In der Praxis sieht die Kette so aus, innerhalb weniger Minuten:

1. Activity Log: accessPolicies/write durch Prinzipal X auf Tresor V.
2. Key Vault-Log: VaultAccessPolicyChangedEventGridNotification auf V.
3. Key Vault-Log: SecretList durch X von derselben IP.
4. Key Vault-Log: eine Salve von SecretGet durch X, eines pro Secret.

MITRE ATT&CK führt das Auslesen von Cloud-Secret-Speichern als T1555.006 Cloud Secrets Management Stores.

Was der Analyzer meldet

AZ-KV-002 zählt unterschiedliche Objekte, nicht Anfragen: Eine Anwendung, die stündlich dieselbe Verbindungszeichenfolge liest, löst sie nie aus; ein Skript, das den Tresor durchläuft, schon. Konfigurationslader, die beim Start alle Secrets lesen, sind das bekannte False Positive.

Fragen zur Triage

1. War die Protokollierung aktiv? Prüfen Sie den Abdeckungsblock des Analyzers oder den Verlauf der Diagnoseeinstellungen des Tresors im Activity Log (microsoft.insights/diagnosticSettings/write und /delete). Eine gelöschte Diagnoseeinstellung ist selbst ein Befund (Defense Evasion).
2. Ist der Leser neu? Vergleichen Sie mit der Referenz: Welche Prinzipale haben diesen Tresor letzte Woche gelesen, von welchen IPs, mit welchem Client?
3. Wie viele verschiedene Secrets? Ein Secret, das ein neuer Prinzipal liest, kann ein Onboarding sein. Zwölf in einer Minute aus einem Python-SDK von der IP eines Privatanschlusses sind es nicht.
4. Welcher Client? clientInfo unterscheidet ein Anwendungs-SDK von curl oder einem Ad-hoc-Skript. Es lässt sich fälschen, eine Änderung ist trotzdem aufschlussreich.
5. Abgelehnte Anfragen? Eine Reihe von 403-Antworten vor dem Erfolg ist typisch für einen Angreifer, der herausfindet, was die Identität darf.
6. Was schließen die Secrets auf? Jedes gelesene Secret erweitert den Umfang des Vorfalls: die Datenbank, den Zahlungsdienstleister, den SFTP-Partner.

Behebung

• Rotieren Sie jedes Secret, jeden Schlüssel und jedes Zertifikat, das der verdächtige Prinzipal gelesen hat – und aktualisieren Sie die Systeme, die sie verwenden. Rotation ohne Aktualisierung der Verbraucher verursacht einen Ausfall; stimmen Sie sich ab.
• Entfernen Sie unerwartete Einträge aus den Zugriffsrichtlinien; planen Sie den Wechsel zum Berechtigungsmodell Azure RBAC.
• Stellen Sie sicher, dass vorläufiges Löschen und Löschschutz aktiviert sind.
• Aktivieren Sie die Diagnoseeinstellung AuditEvent jetzt, falls sie fehlte, und schützen Sie sie mit Azure Policy.

FAQ

Zeigt das Activity Log Lesezugriffe auf Key Vault-Secrets?

Nein. Das Lesen eines Secrets ist ein Vorgang der Datenebene. Er erscheint nur im Key Vault-Ressourcenlog AuditEvent – und nur, wenn eine Diagnoseeinstellung dieses Log vor dem Zugriff irgendwohin gesendet hat.

Kann ich Key Vault-Zugriffslogs wiederherstellen, wenn die Protokollierung nicht aktiviert war?

Nein. Eine jetzt aktivierte Diagnoseeinstellung erfasst nur künftige Vorgänge. Gehen Sie davon aus, dass jedes Secret, das die kompromittierte Identität lesen konnte, gelesen wurde, und rotieren Sie alle.

Wie schnell erscheinen Key Vault-Logs?

Laut Microsoft stehen die Protokollinformationen spätestens 10 Minuten nach dem Key Vault-Vorgang zur Verfügung, meist früher.

Verwandte Artikel

• Datenexfiltration aus Azure Storage: SAS-Token und Blob-Logs
• Missbrauch verwalteter Identitäten in Azure
• Defense Evasion in Azure: gelöschte Logs, Defender aus