Azure Key Vault: Geheimnis- und Zertifikatsverwaltung für kleine Unternehmen in Berlin

Fest kodierte Anmeldedaten sind eine der häufigsten und vermeidbarsten Ursachen für Cloud-Sicherheitsvorfälle. Ein in einer WordPress-Konfigurationsdatei eingebettetes Datenbankpasswort, ein API-Schlüssel in einem gemeinsamen Passwortmanager, ein SSL-Zertifikat, das abgelaufen ist, weil niemand das Verlängerungsdatum verfolgt hat – das sind die operativen Fehler, die Defender for Cloud und Sicherheitsprüfer immer wieder melden. Azure Key Vault ist Microsofts verwalteter Dienst für Geheimnisse, Schlüssel und Zertifikate, der alle drei Probleme mit einem einzigen, RBAC-gesteuerten, HSM-gestützten Dienst behebt.

Dieser Leitfaden erklärt, was Key Vault verwaltet, wie RBAC und verwaltete Identitäten passwortlosen Zugriff ermöglichen, wie das Zertifikat-Lebenszyklusmanagement funktioniert und wie Berliner Unternehmen fest kodierte Anmeldedaten zu Key Vault migrieren können.

Drei Objekttypen: Schlüssel, Geheimnisse, Zertifikate

Schlüssel

Kryptografische Schlüssel für Verschlüsselung, Entschlüsselung, Signierung und Schlüsselumhüllung. Key Vault unterstützt RSA-Schlüssel (2048, 3072, 4096 Bit) und Elliptische-Kurven-Schlüssel (P-256, P-384, P-521). Im Standard-Tarif sind Schlüssel softwaregeschützt. Im Premium-Tarif werden Schlüssel in nach FIPS 140-2 Level 2 validierten HSMs (Hardware Security Modules) generiert und gespeichert – das private Schlüsselmaterial verlässt niemals die HSM-Grenze.

Azure Disk Encryption, Azure Storage-Verschlüsselung und Azure SQL Transparent Data Encryption können alle kundenverwaltete Schlüssel (CMK) aus Key Vault verwenden, wodurch Sie die Kontrolle über den Verschlüsselungsschlüssel-Lebenszyklus behalten – relevant für DSGVO-Löschungsszenarien, bei denen das Löschen eines Schlüssels verschlüsselte Daten dauerhaft unlesbar macht.

Geheimnisse

Beliebige Zeichenkettenwerte: Datenbank-Verbindungszeichenfolgen, API-Schlüssel, SMTP-Anmeldedaten, SAS-Token, Anwendungspasswörter. Geheimnisse sind versioniert – bei der Rotation eines Geheimnisses wird die neue Version erstellt, während die alte Version zugänglich bleibt, bis sie explizit deaktiviert wird. Anwendungen referenzieren Geheimnisse per URI. Die maximale Geheimnissgröße beträgt 25 KB.

Das Ersetzen fest kodierter Anmeldedaten durch Key-Vault-Geheimnisreferenzen eliminiert das häufigste Konfigurationsdatei-Offenlegungsrisiko: Ein Entwickler committet versehentlich eine Konfigurationsdatei mit Anmeldedaten in ein öffentliches GitHub-Repository. Mit Key Vault enthalten Konfigurationsdateien nur den Key-Vault-URI – keinen Anmeldedatenwert.

Zertifikate

Key Vault verwaltet den vollständigen Zertifikat-Lebenszyklus: Erstellung, Speicherung, automatische Verlängerung und Auslieferung an konsumierende Anwendungen. Zertifikate können selbst signiert (für interne Verwendung) oder von integrierten CAs ausgestellt werden – DigiCert und GlobalSign sind nativ integrierte Partner. Let’s-Encrypt-Zertifikate können über benutzerdefinierte CA-Richtlinien verwaltet werden.

Key Vault überwacht den Zertifikatablauf und sendet Ablaufbenachrichtigungen bei konfigurierbaren Schwellenwerten (typischerweise 30 und 7 Tage vor Ablauf). Mit konfigurierter automatischer Verlängerung über eine integrierte CA verlängern sich Zertifikate automatisch – der „Zertifikat am Sonntagnachmittag abgelaufen“-Vorfall gehört damit der Vergangenheit an.

Zugriffskontrolle: RBAC vs. Legacy-Zugriffsrichtlinien

Key Vault unterstützt zwei Zugriffsmodelle. Das aktuell empfohlene Modell ist Azure RBAC mit integrierten Rollen:

Rolle	Berechtigungen	Typische Zuweisung
Key Vault Administrator	Vollständige Kontrolle: Tresorobjekte erstellen/löschen, Zugriffsrichtlinien verwalten	Plattform-Engineering-Team
Key Vault Secrets Officer	Geheimnisse lesen, schreiben, löschen; keine Schlüssel- oder Zertifikatverwaltung	DevOps-Pipeline-Dienstprinzipale
Key Vault Secrets User	Nur Geheimnisswerte lesen; kein Auflisten, Erstellen oder Löschen	Verwaltete Identitäten von Anwendungen
Key Vault Reader	Nur Metadaten lesen; keine Geheimnisswerte	Auditoren, Überwachungssysteme

Das Legacy-Zugriffsrichtlinienmodell wird zugunsten von RBAC eingestellt. Wenn Sie einen neuen Key Vault erstellen, wählen Sie bei der Erstellung das RBAC-Berechtigungsmodell. RBAC bietet standardmäßiges Azure-Rollenverwaltung mit Entra-ID-PIM-Integration für Just-in-Time-Privilegienzugriff auf die Tresoverwaltung.

Verwaltete Identitäten: Passwortloser Anwendungszugriff

Der operativ sauberste Weg für Azure-Workloads, auf Key Vault zuzugreifen, ist über verwaltete Identitäten – Entra-ID-Dienstprinzipale, deren Anmeldedaten vollständig von Azure verwaltet werden. Keine Client-Geheimnisse zum Rotieren, keine Dienstkontopasswörter zu verwalten, keine Anmeldedaten, die versehentlich in Anwendungsprotokollen auftauchen.

Das Muster für eine WordPress-Anwendung auf einem Azure App Service, die auf Key Vault zugreift:

1. Systemseitig zugewiesene verwaltete Identität im App Service aktivieren: Einstellungen → Identität → Status: Ein
2. Im Key Vault die Rolle Key Vault Secrets User der Objekt-ID der verwalteten Identität des App Service zuweisen
3. In der WordPress-Anwendungskonfiguration den fest kodierten DB_PASSWORD-Wert durch die Key-Vault-Geheimnisreferenz ersetzen: @Microsoft.KeyVault(SecretUri=https://ihr-tresor.vault.azure.net/secrets/wp-db-passwort/)
4. App Service ruft den Geheimnisswert automatisch zur Laufzeit mit der verwalteten Identität ab – keine Anmeldedaten in Konfigurationsdateien, Umgebungsvariablen oder Code-Repositories

Soft-Delete und Löschschutz

Key Vaults Soft-Delete-Funktion behält gelöschte Tresorobjekte für einen konfigurierbaren Aufbewahrungszeitraum (7–90 Tage, Standard 90) in einem wiederherstellbaren Zustand. Das Löschen eines Geheimnisses vernichtet es nicht sofort – es wird in einen „gelöscht“-Zustand verschoben, aus dem es innerhalb des Aufbewahrungsfensters wiederhergestellt werden kann.

Löschschutz, wenn aktiviert, verhindert, dass ein Benutzer – einschließlich Tresoadministratoren und Abonnementbesitzer – ein gelöschtes Tresorobjekt endgültig löscht, bis der Aufbewahrungszeitraum abgelaufen ist. Aktivieren Sie den Löschschutz für Tresore mit Produktionsschlüsseln, die für die Speicherverschlüsselung verwendet werden.

Diagnoseprotokollierung und Sentinel-Integration

Key-Vault-Diagnoseeinstellungen können alle Tresorzugriffsprotokolle – jeden GET-, SET- und DELETE-Vorgang an einem Tresorobjekt, einschließlich der Identität des Anfragers – in einen Log-Analytics-Arbeitsbereich streamen. Mit Microsoft Sentinel, der mit demselben Arbeitsbereich verbunden ist, werden Key-Vault-Audit-Protokolle SIEM-sichtbar.

Diese Protokollierungsposition verbessert direkt den Microsoft Secure Score: Das Aktivieren von Key-Vault-Diagnoseprotokollen und das Konfigurieren von Ablaufrichtlinien für alle Geheimnisse und Schlüssel sind bewertete Verbesserungsmaßnahmen im Azure Security Benchmark. Dieselben Kontrollen sind Verbesserungsmaßnahmen im Microsoft Purview Compliance Manager unter den regulatorischen Vorlagen für ISO 27001 und DSGVO.

Private Endpoint: Öffentliche Netzwerkexponierung eliminieren

Standardmäßig ist Key Vault über das öffentliche Internet zugänglich, geschützt nur durch Entra-ID-Authentifizierung und RBAC. Für Produktionsumgebungen konfigurieren Sie einen Private Endpoint: eine private IP-Adresse in Ihrem Azure-VNet, die auf die Key-Vault-Instanz zeigt. Sobald ein privater Endpunkt konfiguriert ist, können Sie den gesamten öffentlichen Netzwerkzugriff deaktivieren.

Kosten

• Standard-Tarif (softwaregeschützte Schlüssel): ca. 0,03 € pro 10.000 Vorgänge; ca. 3 € pro verwaltetem Zertifikat und Monat
• Premium-Tarif (HSM-geschützte Schlüssel): ca. 1,02 € pro HSM-geschütztem Schlüssel und Monat
• Azure Managed HSM (dedizierter Einzelmandanten-HSM-Cluster): ca. 3.500 €/Monat – geeignet für regulierte Branchen mit FIPS-140-2-Level-3-Anforderung

Für ein Berliner Kleinunternehmen, das eine WordPress-Website betreibt, einige Azure-Ressourcen verwaltet und das Zertifikatsmanagement für 2–3 Domänen durchführt, liegen die Standard-Key-Vault-Kosten typischerweise unter 10 €/Monat.

Migrationsleitfaden: Von fest kodierten Anmeldedaten zu Key Vault

1. Key Vault im Azure-Portal erstellen: Region Deutschland West Mitte, Berechtigungsmodell Azure rollenbasierte Zugriffskontrolle, Soft-Delete und Löschschutz aktivieren
2. Sich selbst die Rolle Key Vault Secrets Officer zuweisen
3. Jede fest kodierte Anmeldedatei als Key-Vault-Geheimnis hinzufügen: Geheimnisse → Generieren/Importieren → Manuell → Name, Wert, Ablaufdatum festlegen
4. Verwaltete Identität für jeden Azure-Workload aktivieren, der die Geheimnisse benötigt
5. Jedem Workload die Rolle Key Vault Secrets User zuweisen
6. Anwendungskonfiguration aktualisieren, um Geheimnisse über Key-Vault-URI zu referenzieren
7. Diagnoseeinstellungen aktivieren: Diagnoseeinstellungen → Hinzufügen → AuditEvent → an Log-Analytics-Arbeitsbereich senden
8. Ablaufbenachrichtigungen einrichten: Ereignisse → Ereignisabonnement hinzufügen → nach CertificateNearExpiry- und SecretNearExpiry-Ereignissen filtern → an E-Mail oder Teams-Webhook weiterleiten

Nach der Migration existiert kein Anmeldedatenwert außerhalb des Key Vault. Die Rotation ist operativ einfach: eine neue Geheimnisversion im Tresor erstellen, die Anwendungsreferenz auf die neue Version aktualisieren und die alte Version deaktivieren – keine Ausfallzeit, keine Anmeldedatenoffenlegung, vollständiges Audit-Trail.