Azure Key Vault - Sicherer Zugriff mit Identität & RBAC

Warum Identität hier wichtiger ist als der Tresor selbst

Ein Key Vault ist erst dann wirklich nützlich, wenn klar ist, wer zugreifen darf und wie sich diese Instanz ausweist. Technisch gesprochen spricht Azure von einem Security Principal, also einem Benutzer, einer Gruppe, einem Dienstprinzipal oder einer verwalteten Identität. Genau diese Identität entscheidet, ob ein Secret gelesen, ein Schlüssel genutzt oder ein Zertifikat verwaltet werden darf.

Das klingt banal, ist aber der Kern des Themas. Viele Teams konzentrieren sich auf das Ablegen von Secrets und übersehen den eigentlichen Gewinn: Anwendungen müssen keine Zugangsdaten mehr kennen, solange sie sich sauber gegenüber Azure authentifizieren. Ich plane Key Vault deshalb immer als Teil der Identitätskette, nicht als isolierten Speicher. Erst wenn Authentifizierung und Autorisierung zusammenpassen, reduziert der Tresor das Risiko wirklich statt es nur umzuverteilen.

Für die Praxis heißt das: Menschen greifen anders zu als Maschinen. Menschen arbeiten mit Konten, Gruppen und Rollen. Maschinen sollten möglichst über eine Identität laufen, die von Azure selbst verwaltet wird. Genau an dieser Stelle wird das Berechtigungsmodell wichtig.

Wie Zugriff in Azure wirklich entschieden wird

Azure Key Vault kennt zwei Autorisierungssysteme, die man nicht vermischen sollte, ohne die Folgen zu verstehen: Azure RBAC und Zugriffspolicies. Beide regeln, was eine Identität mit Secrets, Schlüsseln und Zertifikaten tun darf. Der Unterschied liegt darin, wo diese Berechtigungen verwaltet werden und wie gut sie sich im restlichen Azure-Umfeld einordnen lassen.

Ich würde für neue Projekte in der Regel RBAC wählen. Die Zugriffspolicy bleibt zwar ein brauchbares Modell, besonders in Bestandsumgebungen, aber sie wird schnell schwerer zu pflegen, wenn mehrere Teams, Anwendungen oder Umgebungen dazukommen. Ein praktischer Punkt, den viele übersehen: Im Zugriffspolicy-Modell sind bis zu 1024 Einträge möglich. Das klingt viel, reicht aber in wachsenden Organisationen erstaunlich schnell nicht mehr aus, wenn jede Person einzeln eingetragen wird.

Deshalb setze ich möglichst auf Gruppen statt auf Einzelpersonen. Das senkt den Pflegeaufwand und macht Audits deutlich leichter. Wenn die Berechtigungsebene stimmt, lohnt sich der Blick auf die Identität selbst.

Verwaltete Identitäten als Standard für Apps und Dienste

Verwaltete Identitäten sind für mich der entscheidende Schritt, weil sie den klassischen Geheimnis-Tausch aus dem Authentifizierungspfad entfernen. Eine App braucht dann kein Client Secret mehr, um sich bei Key Vault zu melden. Azure stellt die Identität bereit, Microsoft Entra ID authentifiziert sie, und der Zugriff erfolgt nur in dem Umfang, den ich vorher freigegeben habe.

Praktisch gibt es zwei Varianten:

Der Unterschied ist im Alltag wichtiger, als viele denken. Eine system-assigned Identity ist sauber und simpel, solange die zugehörige Ressource eindeutig ist. Eine user-assigned Identity ist flexibler, wenn mehrere Anwendungen auf denselben Vault zugreifen oder wenn du eine stabile Identität über Umzüge, Skalierung oder Neuaufbau hinweg behalten willst. Ich nutze user-assigned Identitäten vor allem dann, wenn die Betriebsrealität wichtiger ist als maximale Einfachheit.

Typische Einsatzfälle sind Web-Apps, Functions, VMs, Pipelines oder Integrationsdienste. Für Azure App Service sind Key-Vault-Referenzen besonders praktisch, weil Secrets dann erst zur Laufzeit aufgelöst werden. So wandern keine sensiblen Werte in Deployments oder App-Settings. Damit lässt sich ein Vault sauber anbinden, ohne zusätzliche Geheimnisse zu verteilen.

So richte ich ein Key-Vault-Zugriffsmodell sauber ein

Wenn ich eine neue Umgebung aufsetze, gehe ich meist in derselben Reihenfolge vor. Das ist nicht spektakulär, aber in der Praxis deutlich stabiler als schnelle Einzellösungen:

1. Autorisierungsmodell festlegen - Für neue Vaults starte ich in der Regel mit RBAC, außer ein bestehendes System zwingt mich bewusst zum Zugriffspolicy-Modell.
2. Workload-Identität aktivieren - Die App oder der Dienst bekommt eine verwaltete Identität, damit keine Secrets für den Vault-Zugriff selbst gespeichert werden müssen.
3. Nur die nötigen Rechte vergeben - Die Identität erhält nur die Rolle oder Berechtigung, die sie wirklich braucht, etwa Lesen von Secrets statt vollständiger Verwaltung.
4. Gruppen bevorzugen - Menschen und administrative Zugriffe laufen über Gruppen, nicht über Einzelkonten.
5. Zugriff testen - Ich prüfe den Abruf eines Secrets direkt aus der Zielumgebung, bevor das System produktiv geht.
6. Protokollierung aktivieren - Ohne Audit-Logs fehlt später die wichtigste Antwort: Wer hat wann worauf zugegriffen?

Wichtig ist dabei die Trennung zwischen Betriebszugriff und Laufzeitzugriff. Admins brauchen nicht automatisch Leserechte auf produktive Secrets, und Anwendungen brauchen keine Vault-Administration. Diese Trennung reduziert den Schaden, wenn ein Konto kompromittiert wird, und sie macht spätere Audits viel einfacher. Die typischen Fehler tauchen trotzdem schnell wieder auf.

Typische Fehler, die ich in Projekten immer wieder sehe

Der häufigste Fehler ist nicht der Tresor selbst, sondern der Umgang mit dem Zugriff darauf. In vielen Umgebungen sehe ich immer noch direkte Client Secrets in App-Registrierungen oder Deployment-Pipelines. Das funktioniert zwar kurzfristig, macht aber jede Rotation und jede Sicherheitsprüfung unnötig schwer. Wenn dann noch einzelne Benutzer statt Gruppen berechtigt werden, wird aus einem Sicherheitsbaustein schnell ein Pflegeproblem.

• Geheimnisse in Konfigurationsdateien - bequem, aber fragil und schlecht kontrollierbar.
• Benutzer statt Gruppen - erzeugt unnötig viele Berechtigungen und erschwert den Nachweis.
• Zu breite Rollen - wer mehr Rechte gibt als nötig, macht den Schutz des Vaults wirkungslos.
• Gemischte Modelle ohne Plan - RBAC und Zugriffspolicies parallel zu pflegen ist möglich, aber oft verwirrend.
• Zu viele Einzelrechte im Zugriffspolicy-Modell - die 1024er-Grenze ist schneller erreicht, als man denkt.
• Kein Audit - ohne Logs bleibt unklar, ob ein Zugriff normal oder verdächtig war.

Besonders problematisch wird es, wenn menschliche Konten für Automatisierung missbraucht werden. Ein Dienst sollte kein Mitarbeiterkonto verwenden, und ein Mitarbeiterkonto sollte nicht dauerhaft wie ein Systemschlüssel funktionieren. Genau deshalb ist die Kombination aus verwalteter Identität, minimalen Rechten und sauberem Logging so wirksam. Aber auch das ersetzt nicht jede andere Sicherheitsmaßnahme.

Was der Tresor nicht ersetzt

Key Vault schützt Secrets, aber er ersetzt keine durchdachte Sicherheitsarchitektur. Er löst nicht automatisch das Rotieren von Schlüsseln, er ersetzt keine Netztrennung und er behebt keine unsaubere Anwendungskonfiguration. Ein System kann technisch korrekt mit Vault angebunden sein und trotzdem unsicher bleiben, wenn die Anwendung zu viele Rechte hat oder wenn Logs nicht ausgewertet werden.

Ich trenne deshalb drei Ebenen klar voneinander: Speicherung, Zugriff und Betrieb. Der Tresor übernimmt die sichere Aufbewahrung. Identität und Berechtigung entscheiden über den Zugriff. Rotation, Monitoring und Change-Prozess gehören in den Betrieb. Wer diese Ebenen vermischt, verliert schnell die Kontrolle darüber, wo ein Risiko wirklich entsteht.

Auch die Netzseite sollte man nicht ignorieren. Ein Vault mit offenen, unkontrollierten Zugriffswegen bleibt angreifbarer als ein sauber segmentiertes Setup. Genau deshalb lohnt sich am Ende ein klarer, schlanker Startpunkt statt einer möglichst komplexen Sonderlösung.

Was ich für neue Umgebungen 2026 empfehle

Wenn ich heute eine neue Azure-Umgebung plane, beginne ich mit einem einfachen Muster, das später erweiterbar bleibt. So vermeide ich, dass Sicherheit und Betrieb gegeneinander arbeiten:

• RBAC zuerst - für neue Vaults ist das meist die wartbarere Wahl.
• Verwaltete Identitäten als Standard - keine zusätzlichen Passwörter für Workloads.
• Gruppen statt Einzelkonten - einfacher zu prüfen und leichter zu pflegen.
• Getrennte Vaults nach Umgebung oder Vertrauensgrenze - Produktion und Test sollten nicht dieselben Secrets teilen.
• Protokollierung von Anfang an - Zugriff muss nachvollziehbar bleiben.
• User-assigned Identitäten gezielt einsetzen - dort, wo Wiederverwendung oder ein stabiler Lebenszyklus wirklich helfen.

Wenn ich ein Setup heute neu bewerte, achte ich vor allem auf drei Fragen: Wer authentifiziert sich, wie eng ist die Berechtigung und wie schnell lässt sich ein Missbrauch erkennen. Genau diese drei Punkte entscheiden in der Praxis stärker über die Sicherheit als der Name des Tresors selbst.