Für Azure Key Vault lohnt sich der Wechsel auf RBAC

Wer schon länger mit Azure Key Vault arbeitet, kennt das Problem. Die klassischen Zugriffsrichtlinien sind zwar schnell eingerichtet, kommen aber gerade in gewachsenen Tenants rasch an ihre Grenzen. In vielen Umgebungen laufen noch Vaults mit diesen pauschalen Berechtigungen, obwohl die Anforderungen an Security und Governance seit Jahren steigen. Um „Azure Key Vault RBAC“ machen viele einen Bogen, weil die Umstellung auf den ersten Blick nach Mehrarbeit aussieht. Wer sich aber die Schwächen der Access Policies und die Vorteile von RBAC genauer ansieht, erkennt schnell, dass sich die Migration auszahlt.

Klassische Access Policies kennen nur den ganzen Vault

Access Policies in Key Vault funktionieren im Grunde nach dem Prinzip „alles oder nichts“. Rechte für Zertifikate, Schlüssel und Secrets lassen sich nur für den gesamten Vault vergeben – gezielt für ein einzelnes Secret oder eine bestimmte Operation geht das nicht. Dazu kommt, dass sich Nutzer mit Contributor-Rechten auf den Key Vault ganz legal selbst neue Zugriffsrichtlinien einräumen können. Für die Governance ist das ein ernstes Problem. PIM (Privileged Identity Management) sowie temporäre und auditierbare Rechte lassen sich mit den alten Policies schlicht nicht abbilden. Damit verfehlt man die Sicherheitsanforderungen, die mir in praktisch jedem Projekt begegnen.

Azure Key Vault RBAC erlaubt Rechte bis auf einzelne Secrets

Mit dem RBAC-Modell (Role-Based Access Control) bekommt Key Vault endlich die Flexibilität und Kontrolle, die wir von anderen Azure-Ressourcen gewohnt sind. Berechtigungen kann ich damit auf Vault-Ebene vergeben, bei Bedarf aber auch gezielt für einzelne Secrets, Keys oder Zertifikate. Microsoft liefert vordefinierte Rollen wie „Key Vault Secrets User“, „Key Vault Crypto User“, „Key Vault Administrator“ und „Key Vault Reader“ mit, die sich Gruppen, Usern oder Service Principals/Managed Identities zuweisen lassen. Am meisten schätze ich, dass ich mit PIM jetzt auch für Key Vaults „eligible“ Admin-Rechte mit Genehmigungsworkflow und Zeitbegrenzung einrichten kann. Wer wann welche Rechte bekommen und genutzt hat, zeigen die Entra Audit Logs und das Azure Activity Log (Sicherheitsfunktionen von Key Vault).

Die Migration läuft am sichersten über parallele Rollenzuweisungen

Ins Blaue hinein muss beim Umstieg niemand arbeiten. Microsoft beschreibt das Vorgehen in diesem Leitfaden recht konkret. Als Erstes ordne ich die vorhandenen Access Policies den passenden RBAC-Rollen zu. Die Managed Identities produktiver Anwendungen kommen dabei zuerst an die Reihe, denn sie müssen auch nach dem Wechsel an ihre Secrets oder Keys herankommen. Danach vergebe ich die ermittelten Rollen parallel, also zusätzlich zu den weiterhin aktiven Access Policies. Erst wenn ich alle Anwendungen und Nutzer getestet habe, stelle ich das Berechtigungsmodell des Vaults auf Azure RBAC um. Das kostet etwas mehr Zeit, erspart mir aber böse Überraschungen im Livebetrieb.

Das folgende Diagramm zeigt den Ablauf der Migration in vereinfachter Form:

graph TD
    A["Access Policies auslesen"] --> B["RBAC-Rollen zuweisen"]
    B --> C["Rollen für Apps/Identities testen"]
    C --> D["Key Vault auf RBAC-Modell umstellen"]
    D --> E["Rollenzuweisungen fertigstellen & Policy entfernen"]

Abbildung: So läuft die Migration auf Azure Key Vault RBAC typischerweise ab

Praxistipp: Bevor ich das Modell eines Vaults umstelle, dokumentiere ich die alten Access Policies immer gründlich. Fehlt später irgendwo ein Recht, kann ich jede Rolle nachvollziehen und gezielt nachbessern.

Rollen weise ich meistens per PowerShell zu. Bei mehreren Vaults oder vielen Managed Identities geht das deutlich schneller als im Azure Portal:

New-AzRoleAssignment -ObjectId <ManagedIdentity-ObjectId> -RoleDefinitionName "Key Vault Secrets User" -Scope "/subscriptions/<SubId>/resourceGroups/<RG>/providers/Microsoft.KeyVault/vaults/<VaultName>"

Soft-Delete, Purge Protection und Netzwerkschutz gehören ebenfalls dazu

RBAC allein reicht nicht aus. Soft-Delete und Purge Protection setze ich in jedem Vault als selbstverständlich voraus, weil Secrets sonst versehentlich oder mutwillig gelöscht werden können. Trotzdem stoße ich in vielen Tenants noch auf Vaults ohne diesen Schutz. Ebenso gehören Private Endpoints und Firewalls dazu, damit der Zugriff auf das Nötigste beschränkt bleibt. Über Azure Policy lassen sich außerdem alle Key Vaults auditieren, die noch das klassische Zugriffsmodell verwenden, sodass Nachzügler schnell auffallen (RBAC-Leitfaden).

RBAC ist für Key Vaults heute Pflichtprogramm

Als optionale Verbesserung sehe ich die Migration auf Azure Key Vault RBAC längst nicht mehr. Die klassischen Access Policies sind überholt und können in einer modernen Azure-Umgebung schnell zum Risiko werden. Wer jetzt umstellt, gewinnt an Sicherheit und Nachvollziehbarkeit und bringt das Berechtigungsmanagement zugleich auf den Stand der übrigen Azure-Ressourcen. Zusammen mit PIM und Azure Policy entsteht ein einheitliches, auditierbares Modell, das sich wesentlich feiner steuern lässt. Und wer bei dieser Gelegenheit auch die übrigen Schutzmechanismen (Soft-Delete, Firewall, Endpoints) überprüft, ist mit seinem Key Vault für die kommenden Jahre gut aufgestellt.

Weitere Praxistipps zu Azure Security und Governance finden Sie hier im Blog, etwa zu Best Practices für Conditional Access oder dazu, wie man die Azure-Kosten im Griff behält.