Wer sich mit Azure Key Vault beschäftigt, stellt bald fest, dass zur Key-Vault-Härtung deutlich mehr gehört, als Access Policies auf RBAC umzustellen. In vielen Tenants, die ich prüfe, regelt zwar ein Rollenmodell den Zugriff, der Vault selbst ist aber weiterhin aus jedem Netz erreichbar. Manchmal ist es noch schlimmer: Entwickler haben die Firewallregeln gelockert, um „erst mal irgendwas zum Laufen zu bringen“. Gerade beim Schutz von Schlüsseln und Geheimnissen gibt es dafür keine Ausrede mehr. Die nötigen Werkzeuge stehen bereit, man muss sie nur richtig einsetzen.

Firewall oder Private Endpoint sperren den Vault wirksam nach außen ab

Nach der RBAC-Umstellung kommt der wichtigste Härtungsschritt, und zwar im Key-Vault-Menü unter Einstellungen → Netzwerk. Mit der Option „Öffentlicher Netzwerkzugriff: deaktivieren“ kann niemand mehr von außen auf den Vault zugreifen, solange kein Private Endpoint besteht – selbst mit einem gestohlenen Admin-Token nicht. Wer aus bestimmten Subnetzen zugreifen muss, legt dafür explizite Firewallregeln an. In der Praxis finde ich allerdings häufig die Ausnahme „Vertrauenswürdige Microsoft-Dienste zulassen“ aktiviert, weil sonst etwa Azure Automation oder Logic Apps ihren Dienst verweigern. Wie weit man diesen Diensten im jeweiligen Umfeld trauen will, muss man im Einzelfall abwägen. Wer den Vault vollständig isolieren möchte, kommt an Private Endpoints nicht vorbei.

Diese bringen allerdings ihre eigenen Tücken mit, vor allem bei der Namensauflösung. Ist die private DNS-Zone privatelink.vaultcore.azure.net nicht korrekt eingerichtet, laufen Anfragen aus dem VNet schnell ins Leere. Welche DNS-Fallen bei Private Endpoints in Azure lauern, habe ich ausführlich in Private Endpoints DNS in Azure: Die tückischsten Fehler beschrieben. Bei konsequenter Key-Vault-Härtung sieht der Netzwerkzugriff so aus:

flowchart TD
    Client["Client im VNet"] --> DNS["DNS-Auflösung privatelink.vaultcore"]
    DNS --> PrivateEndpoint["Private Endpoint"]
    PrivateEndpoint --> KeyVault["Azure Key Vault"]
    Extern["externer Client"] -->|"Zugriff blockiert"| Firewall["Key Vault Firewall"]
    Firewall -.->|"kein Zugriff"| KeyVault

Abbildung: Netzwerkfluss bei Key-Vault-Härtung mit Private Endpoint und Firewall

Soft Delete und Purge Protection verhindern das endgültige Löschen

Den Löschschutz unterschätzen viele bei der Key-Vault-Härtung. Seit 2022 ist Purge Protection für alle neu angelegten Vaults zwingend aktiviert und lässt sich nicht mehr abschalten. Soft Delete stellt sicher, dass ein gelöschter Vault mitsamt seinem Inhalt erst nach Ablauf der Aufbewahrungsfrist endgültig entfernt werden kann. Purge Protection blockiert das endgültige Löschen sogar dann, wenn ein Admin-Konto kompromittiert wurde. In den letzten Monaten werde ich öfter gefragt, wie man „versehentlich gelöschte“ Secrets rasch wiederherstellt. Solange der Soft-Delete-Zeitraum noch läuft, geht das ohne Weiteres, etwa per Azure CLI oder REST API. Wie sich Soft Delete im Detail verhält und worauf man achten sollte, beschreibt Microsoft im offiziellen Artikel (https://learn.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview).

AuditEvent-Daten gehören in einen Log-Analytics-Workspace

Solange niemand nachvollziehen kann, wer auf den Vault zugreift, bleibt jede Key-Vault-Härtung unvollständig. Die Diagnoseeinstellungen des Vaults (Azure-Portal → Key Vault → Diagnoseeinstellungen) sollten deshalb auf einen Log-Analytics-Workspace verweisen, denn nur dort lassen sich die AuditEvent-Daten direkt durchsuchen. Je nach gewählter Option landen die Logs in der Tabelle AzureDiagnostics oder in der spezifischeren AZKVAuditLogs. Für kleinere Umgebungen genügt meist die erste, bei großen Vaults oder mehreren davon behält man mit der zweiten leichter den Überblick. Um beispielsweise alle fehlgeschlagenen Zugriffe zu finden, genügt unter Log Analytics Workspace → Logs folgende Abfrage:

// Voraussetzung: Rolle Log Analytics Reader auf Workspace, Diagnoseeinstellung AuditEvent aktiv
AZKVAuditLogs
| where OperationName == "SecretGet" and Status != "Success"
| project TimeGenerated, Caller, Resource, Status, ResultReason

Praktischer Tipp: Für produktive Vaults lohnt sich ein Alert, der bei mehreren fehlgeschlagenen Zugriffsversuchen pro Stunde anschlägt. Kompromittierte Accounts oder fehlerhafte Anwendungen fallen so frühzeitig auf.

Weitere Details zur Netzwerkabsicherung stehen übrigens im entsprechenden Artikel in Microsoft Docs (https://learn.microsoft.com/en-us/azure/key-vault/general/network-security).

Azure Policy und Defender for Key Vault übernehmen die laufende Kontrolle

Wer für viele Key Vaults verantwortlich ist, sollte auf die integrierten Azure-Policy-Definitionen (Built-ins) zurückgreifen. Damit lässt sich etwa erzwingen, dass Public Network Access deaktiviert ist oder jeder Vault über einen Private Endpoint erreichbar ist. In großen Subscription-Landschaften spart das enorm viel Arbeit. Die Policy „Azure Key Vault should have firewall enabled and public network access disabled“ weise ich standardmäßig zu, damit niemand versehentlich eine Lücke aufreißt. Zusammen mit Microsoft Defender for Key Vault (Lizenz: Defender for Cloud, Plan 2 oder Key Vault Add-on) kommen Warnungen bei verdächtigen Zugriffsmustern hinzu, zum Beispiel wenn Secrets massenhaft ausgelesen werden oder Zugriffe aus ungewöhnlichen Quellen stammen.

Wie es bei der Umstellung von Access Policies auf RBAC weitergeht, beschreibe ich in meinem Erfahrungsbericht Azure Key Vault RBAC: Migration von Zugriffsrichtlinien.

Die Härtung eines Key Vault ist nie wirklich abgeschlossen

Für mich zeigt die Key-Vault-Härtung sehr gut, wie Cloud-Sicherheit im Alltag funktioniert. Es sind viele Einzelheiten, die jede für sich etwas bewirken und gemeinsam aus „es läuft“ ein „es ist sicher“ machen. Vor allem DNS bei Private Endpoints wird gern unterschätzt und verursacht immer wieder Ausfälle, die sich hätten vermeiden lassen. Nach wie vor begegnen mir Vaults, die aus Bequemlichkeit oder Unwissen öffentlich erreichbar sind. Wer dagegen Netzwerk, Protokollierung und Löschschutz sauber eingerichtet hat, hat beim Key Vault das Wesentliche bereits geschafft. Die Werkzeuge werden zwar laufend besser, über die Sicherheit entscheidet aber weiterhin die gründliche Umsetzung im Tenant.