Microsoft Azure-Dienste – Azure Key Vault

Azure Key Vault ist der Cloud-Dienst von Microsoft zum Speichern und Verwalten des Zugriffs auf kryptografische Schlüssel, Geheimnisse und Zertifikate. Dies ist wichtig, da alle Anmeldeinformationen, die eine Anwendung benötigt (Verschlüsselungsschlüssel, Verbindungszeichenfolgen, TLS-Zertifikate), ein potenzielles Sicherheitsrisiko darstellen, wenn sie im Code oder in Konfigurationsdateien anstatt in einem verwalteten Key Vault gespeichert werden. Empfohlene Vorgehensweise: Verwenden Sie Key Vault standardmäßig mit Azure RBAC und verwalteten Identitäten und reservieren Sie Managed HSM für Workloads mit dokumentierten Anforderungen an dedizierte Hardware.

Veröffentlicht: Februar 2021. Aktualisiert: August 2026. Geprüft vom Cloud Key Management Team von Encryption Consulting.

Wie Azure Key Vault in ein umfassenderes Compliance-Programm passt, erfahren Sie unter „ Wie Sie Unternehmen mit Microsoft Azure konformer machen“ . Einen Vergleich von Key Vault mit den Schlüsselverwaltungsdiensten von AWS und GCP finden Sie unter „AWS KMS vs. Azure Key Vault vs. GCP KMS“ . Informationen zu Cloud-HSM-Optionen im Allgemeinen finden Sie unter „ Vergleich zwischen Cloud-basiertem HSM und lokalem HSM“ , und Informationen zur zertifikatsbasierten Identität in verschiedenen Clouds finden Sie unter „Was ist eine Cloud-basierte PKI-Architektur?“.

Was ist Azure Key Vault?

Azure Key Vault ist ein Cloud-Dienst, der als zentraler, zugriffskontrollierter Speicher für sensible Daten einer Organisation dient. Diese Daten sind in drei Ressourcentypen unterteilt: Geheimnisse (Verbindungszeichenfolgen, Passwörter, API-Schlüssel, jeweils bis zu 10 KB), Schlüssel (kryptografische Schlüssel für Verschlüsselung, Signierung und Key Wrapping, die den sicheren Bereich des Vaults niemals in nutzbarer Form verlassen) und Zertifikate (SSL/TLS X.509-Zertifikate, die Key Vault bereitstellen, erneuern und in integrierten Azure-Diensten verwenden kann). Systembedingt kann selbst Microsoft die Kundenschlüssel weder extrahieren noch einsehen; jeder Vorgang findet innerhalb des Vaults oder des HSM statt und wird zu Prüfzwecken protokolliert.

Wie funktioniert die native im Vergleich zur externen Schlüsselverwaltung in Azure Key Vault?

Azure Key Vault und die zugehörigen Dienste bieten mehrere Stufen der Schlüsselverwaltung, wobei Kosten, Isolation und die letztendliche Kontrolle über das Schlüsselmaterial gegeneinander abgewogen werden:

Schlüsselkontrollebene	Schutzstufe	Optimale Bildschirmwahl
Standardstufe (nativ, Software)	FIPS 140-2 Level 1, Software-Kryptografiemodul.	Standardeinstellung für die meisten Geheimnisse, Schlüssel und Zertifikate.
Premium-Stufe (nativ, HSM-gestützt)	FIPS 140-3 Level 3 auf aktueller HSM Platform 2 Hardware, gemeinsam genutzter Multi-Tenant-Pool.	Workloads, die hardwaregestützte Schlüssel benötigen, ohne dass dafür ein dediziertes HSM anfällt.
Verwaltetes HSM (nativ, dediziert)	FIPS 140-3 Level 3, dedizierter Single-Tenant-HSM-Pool; jeder Schlüssel ist HSM-geschützt, keine Software-Schlüsseloption.	Regulierte Arbeitslasten, die die volle administrative Kontrolle über ein dediziertes HSM erfordern.
Azure Dedicated HSM (vom Kunden gesteuert)	Vom Kunden verwaltete physische HSM-Appliance; Microsoft betreibt sie nicht.	Eine Compliance-Vorgabe, wonach der Cloud-Anbieter das HSM niemals selbst verwalten darf.
BYOK (importiertes Schlüsselmaterial)	Schlüsselmaterial, das außerhalb von Azure, häufig in einem lokalen HSM, generiert und in Key Vault oder Managed HSM importiert wird.	Organisationen, die die Herkunft ihrer Schlüssel nachweisen müssen oder bereits Schlüssel lokal generieren.

Standardmäßig wird Standard oder Premium verwendet, es sei denn, eine bestimmte Anforderung verlangt den dedizierten Pool von Managed HSM oder die vom Kunden verwaltete Hardware von Dedicated HSM; beide sind deutlich teurer und lohnen sich nur, wenn eine spezifische Vorgabe dieses Maß an Isolation erfordert.

Welche grundlegenden Konzepte von Azure Key Vault sollten Sie kennen?

• Geheimnis: ein kleiner Datenblock (bis zu 10 KB), wie z. B. ein Authentifizierungsschlüssel, ein Passwort, ein Token oder eine .pfx-Datei, der von einem autorisierten Aufrufer abgerufen und nicht in den Anwendungscode eingebettet wird.
• Schlüssel: Ein kryptografischer Schlüssel, der für Verschlüsselungs-/Entschlüsselungs-, Ein-/Auspacken- oder Signier-/Verifizierungsvorgänge verwendet wird; im Gegensatz zu Geheimnissen verlässt das Schlüsselmaterial niemals die sicheren Grenzen des Tresors.
• Besitzer des Schlüsseltresors: Der Administrator, der den Tresor erstellt und Benutzer und Anwendungen für bestimmte Vorgänge autorisiert.
• Dienstleiter: Die Identität, die eine Anwendung zur Authentifizierung bei Azure Active Directory (Microsoft Entra ID) und anschließend bei Key Vault verwendet.
• Zugriffsrichtlinie vs. Rollenzuweisung: das veraltete, auf den Tresorbereich beschränkte Berechtigungsmodell im Vergleich zum rollenbasierten Berechtigungsmodell von Azure RBAC, das im Folgenden beschrieben wird.

Wie sollte IAM für Azure Key Vault strukturiert sein?

Azure RBAC ist das von Microsoft empfohlene Berechtigungsmodell für Key Vault und ersetzt das ältere Zugriffsrichtliniensystem auf Vault-Ebene durch die gleichen detaillierten, überprüfbaren Rollenzuweisungen, die im übrigen Azure verwendet werden.

1. Migrieren Sie Tresore, die noch das Legacy-Zugriffsrichtlinienmodell verwenden, zu Azure RBAC, da RBAC mit Conditional Access integriert ist und einen konsistenten Prüfpfad über alle Dienste hinweg erzeugt.
2. Trennen Sie die Schlüsseltresor-Kryptobeauftragter Rolle (Schlüssellebenszyklus: erstellen, rotieren, löschen) von Key Vault Krypto-Benutzer (nur Verschlüsseln/Entschlüsseln/Signieren), wobei jede Berechtigung einer anderen Identität zugewiesen wird.
3. Gewähren Sie Zugriff auf Geheimnisse und Zertifikate über das Äquivalent Schlüsseltresor-Geheimnisse-Benutzer und Schlüsseltresor-Zertifikatsbeauftragter mehrschichtige Aufgaben anstelle einer einzigen umfassenden Key Vault Administrator-Berechtigung.
4. Die Rollenzuweisung sollte auf Tresorebene oder auf Ebene der einzelnen Schlüssel/Geheimnisse/Zertifikate erfolgen, um eine feinere Kontrolle zu ermöglichen, anstatt auf Abonnementebene.
5. Überprüfen Sie die Rollenzuweisungen im gleichen Rhythmus wie andere Zugriffsüberprüfungen in der Produktion, da eine veraltete Krypto-Benutzerberechtigung einer permanenten Entschlüsselungsberechtigung gleichkommt.

Wie authentifiziert man eine Anwendung gegenüber Azure Key Vault?

Microsoft empfiehlt derzeit, Anwendungen mit einer verwalteten Identität anstatt mit einem Dienstprinzipal-Clientgeheimnis zu authentifizieren, da eine verwaltete Identität die Speicherung von Anmeldeinformationen überflüssig macht:

1. Aktivieren Sie eine vom System oder vom Benutzer zugewiesene verwaltete Identität für die Azure-Ressource der Anwendung (App Service, VM, Funktion oder Ähnliches).
2. Gewähren Sie der verwalteten Identität die entsprechende RBAC-Rolle (Krypto-Benutzer, Geheimnis-Benutzer oder Zertifikatsbeauftragter) im Ziel-Vault.
3. Die Anwendung fordert ein Token von Azure Active Directory unter Verwendung ihrer verwalteten Identität an, ohne dass ein Clientgeheimnis verwendet wird.
4. Die Anwendung präsentiert dieses Token dem Key Vault, der es validiert und das angeforderte Geheimnis, das Ergebnis der Schlüsseloperation oder das Zertifikat zurückgibt.
5. Für Anwendungen, die keine verwaltete Identität verwenden können (Multi-Cloud- oder On-Premises-Aufrufer), sollte auf einen Dienstprinzipal mit Zertifikatsberechtigungen anstelle eines Clientgeheimnisses zurückgegriffen und diese Berechtigung nach einem festgelegten Zeitplan rotiert werden.

Wie sollte die Schlüsselrotation in Azure Key Vault gehandhabt werden?

Key Vault unterstützt integrierte automatische Rotationsrichtlinien, mit denen Organisationen einen Rotationszeitraum und optional ein Benachrichtigungsfenster vor Ablauf festlegen können. Wie bei allen gängigen Cloud-Schlüsselverwaltungsdiensten erstellt die Rotation lediglich eine neue Schlüsselversion für zukünftige Operationen. Bereits durch eine vorherige Version geschützte Daten werden nicht erneut verschlüsselt, und die vorherige Version wird nicht automatisch gelöscht. Ein vollständiger Rotationsplan erfordert einen separaten Schritt zur erneuten Verschlüsselung und einen expliziten Zeitplan für die Außerbetriebnahme alter Schlüsselversionen, sobald diese nicht mehr benötigt werden. Zertifikate unterliegen einem eigenen, von der Schlüsselrotation unabhängigen Erneuerungszyklus. Key Vault kann die Erneuerung vor Ablauf automatisch bei einer integrierten Zertifizierungsstelle anfordern.

Was sollten Sie für Azure Key Vault protokollieren?

• Key Vault-Diagnoseprotokolle, an Azure Monitor oder Log Analytics gesendet und protokolliert alle geheimen, Schlüssel- und Zertifikatsvorgänge, die Identität des Aufrufers sowie die verwendete Objektversion.
• Änderungen der Rollenzuweisung auf dem Tresor, da die Vergabe neuer RBAC-Berechtigungen selbst ein sicherheitsrelevantes Ereignis darstellt.
• Veranstaltungen zur Zertifikatserneuerung und zum Zertifikatsablauf, So wird ein fehlgeschlagener automatischer Verlängerungsfehler erkannt, bevor das Zertifikat tatsächlich abläuft.
• Änderungen an Firewall- und Netzwerkregeln im Tresor, da Key Vault auch die Beschränkung des Zugriffs auf bestimmte virtuelle Netzwerke oder private Endpunkte unterstützt.

Was kostet Azure Key Vault?

Die Standard-Tarifstufe wird pro Operation für Geheimnisse, Schlüssel und Zertifikate zu einem niedrigen Preis pro 10,000 Operationen abgerechnet. Die Premium-Tarifstufe beinhaltet zusätzlich zum gleichen Grundpreis eine Gebühr pro HSM-geschützter Schlüsseloperation, um den gemeinsam genutzten HSM-Pool abzudecken. Managed HSM berechnet einen festen Stundensatz pro HSM-Pool zuzüglich Gebühren pro Schlüsselversion und pro Operation. Diese Gebühren sind deutlich höher als bei Standard oder Premium, um dedizierte Hardware für einen einzelnen Mandanten abzudecken. Azure Dedicated HSM wird unabhängig von der Nutzung stündlich pro physischer Appliance abgerechnet. Prüfen Sie die aktuellen Preise pro Einheit auf den Preisseiten von Microsoft, bevor Sie eine Migration zu Managed HSM oder Dedicated HSM planen, da die Kostenunterschiede zwischen den Tarifstufen erheblich sind.

Wie sieht die Schlüsselverwaltung in mehreren Clouds über Azure, AWS und GCP hinweg aus?

Jede der großen Cloud-Plattformen implementiert dieselben konzeptionellen Ebenen: eine kostengünstige, softwaregeschützte Standardebene, eine gemeinsam genutzte, HSM-gestützte Ebene und eine dedizierte HSM-Option für einen einzelnen Mandanten. Die Implementierung erfolgt jedoch unter verschiedenen Bezeichnungen und mit unterschiedlichen FIPS-Validierungshistorien. Eine konsistente Multi-Cloud-Architektur standardisiert die Zugriffskontrolle und die Rotationsrichtlinien für die jeweiligen nativen Schlüsselspeicher der einzelnen Clouds, anstatt einen einzigen Schlüsselverwaltungsdienst für alle drei Plattformen zu betreiben, da keine der drei die Schlüssel der anderen nativ verwaltet.

In unserem Vergleich von AWS KMS, Azure Key Vault und GCP KMS finden Sie eine detaillierte Aufschlüsselung der Unterschiede zwischen diesen drei Systemen hinsichtlich Rotation, IAM und Kosten.

Welche Einschränkungen gibt es bei Azure Key Vault?

• Die softwaregeschützten Schlüssel der Standardstufe verfügen lediglich über eine FIPS 140-2 Level 1-Validierung, die einer Vorgabe, die eine hardwaregestützte Schlüsselaufbewahrung erfordert, nicht genügt.
• Die Migration von Tresoren vom alten Zugriffsrichtlinienmodell auf RBAC erfordert eine sorgfältige Planung, da die beiden Modelle nicht eins zu eins übereinstimmen und eine überstürzte Migration entweder zu viele Zugriffsrechte gewähren oder legitime Zugriffe aussperren kann.
• Managed HSM und Dedicated HSM sind beide wesentlich teurer als Standard oder Premium, was durch eine tatsächliche Compliance-Anforderung gerechtfertigt werden muss.
• Die Rotation verschlüsselt vorhandene Daten nicht automatisch neu; die erneute Verschlüsselung und die Bereinigung alter Versionen obliegen dem Kunden.

Entscheidungscheckliste: Auswahl des richtigen Azure Key Vault-Tarifs

1. Standardmäßig sollte für Geheimnisse und softwaregeschützte Schlüssel der Standard-Tarif verwendet werden; ein Wechsel zum Premium-Tarif ist nur dann erforderlich, wenn für eine Arbeitslast HSM-gestützte Schlüssel benötigt werden.
2. Reservieren Sie Managed HSM oder Dedicated HSM für eine bestimmte Anforderung an dedizierte, mandantenfähige Hardware.
3. Migrieren Sie alle Tresore, die noch das veraltete Zugriffsrichtlinienmodell verwenden, zu Azure RBAC, um die Schlüsselverwaltung von der Schlüsselverwendung zu trennen.
4. Anwendungen werden mit verwalteten Identitäten authentifiziert; auf zertifikatbasierte Dienstprinzipale wird nur bei Bedarf zurückgegriffen.
5. Aktivieren Sie die automatische Rotation und dokumentieren Sie den separaten Re-Verschlüsselungsprozess für bestehende Daten.

Was würde Encryption Consulting empfehlen?

Die meisten von uns analysierten Azure-Umgebungen verwenden immer noch Anwendungen, die sich mit einem langlebigen Dienstprinzipal-Geheimnis anstelle einer verwalteten Identität authentifizieren. Zudem nutzen Tresore noch immer das veraltete Zugriffsrichtlinienmodell, obwohl RBAC bereits seit Jahren empfohlen wird. Die Cloud Key Management Services von Encryption Consulting entwerfen die RBAC-Rollenstruktur und die Migration zu verwalteten Identitäten für Ihre Key Vault-Umgebung. Unser HSM-as-a-Service- Angebot ermöglicht Ihnen die hardwaregestützte Schlüsselverwaltung ohne direkten Betrieb von HSMs. Unser PKI-as-a-Service erweitert dies um das vollständige Zertifikatslebenszyklusmanagement.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen Azure Key Vault Standard und Premium?

Die Standardstufe schützt Schlüssel in Software, validiert nach FIPS 140-2 Level 1; die Premiumstufe schützt Schlüssel innerhalb eines gemeinsam genutzten Hardware-Sicherheitsmodul-Pools, jetzt validiert nach FIPS 140-3 Level 3 auf der aktuellen HSM-Plattform von Microsoft.

Ist Managed HSM dasselbe wie Key Vault Premium?

Nein. Premium ist ein gemeinsam genutzter, mandantenfähiger HSM-Pool innerhalb eines Standard-Key-Vaults; Managed HSM ist ein dedizierter, mandantenfähiger HSM-Pool mit eigenem Verwaltungsmodell, und jeder darin enthaltene Schlüssel ist HSM-geschützt, ohne Option für Software-Schlüssel.

Sollte ich weiterhin Vault-Zugriffsrichtlinien anstelle von Azure RBAC verwenden?

Nein. Azure RBAC ist das derzeit von Microsoft empfohlene Berechtigungsmodell für Key Vault; Zugriffsrichtlinien sind der veraltete Ansatz, und bestehende Tresore sollten migriert werden.

Kann Azure Key Vault mit einem externen Schlüsselmanager wie Thales verwendet werden?

Key Vault unterstützt den Import extern generierter Schlüsselmaterialien über BYOK. In Szenarien, in denen der Cloud-Anbieter niemals nutzbare Schlüsselmaterialien speichern soll, ist Azure Dedicated HSM, das direkt vom Kunden verwaltet wird, die beste Alternative zum HYOK-Modell.

Führt die Schlüsselrotation im Key Vault zu einer erneuten Verschlüsselung der vorhandenen Daten?

Nein. Durch die Rotation wird lediglich eine neue aktive Schlüsselversion für zukünftige Operationen erstellt; Daten, die bereits mit der vorherigen Version verschlüsselt wurden, bleiben von dieser abhängig, bis ein expliziter Neuverschlüsselungsprozess ausgeführt wird.

Benötigen Sie Hilfe bei der Strukturierung von Azure Key Vault RBAC-Rollen und der Migration von Legacy-Zugriffsrichtlinien? Sprechen Sie mit dem Cloud Key Management-Team von Encryption Consulting.

Referenzen

Azure Key Vault – Übersicht – learn.microsoft.com

Informationen zu Schlüsseln in Azure Key Vault (FIPS-Validierungsstufen) – learn.microsoft.com

Informationen zu Schlüsseln in Managed HSM – learn.microsoft.com