Ihre Datenbank ist verschlüsselt. Der Verkäufer spricht von „integriertem KMS“. Dann ein Vorfall: Wer hat um 2 Uhr morgens das Test-Backup entschlüsselt? Niemand weiß es – KMS-Protokolle werden nicht exportiert, der Host-Administratorzugriff ist nicht korreliert und im Vertrag steht nur „Verschlüsselung aktiviert“.
Ein Key Management Service ist keine weitere technische Option. Hier erfolgt die nachweisbare Trennung zwischen demjenigen, der die Daten speichert und dem, der sie lesen kann. Gut gestaltet, liefert es Beweise. Es ist schlecht konzipiert und fügt eine Ebene Fachjargon hinzu, ohne das Vertrauensmodell zu ändern.
Architektur: Wo Schlüssel und Daten leben
Das Prinzip ist einfach: Die verschlüsselten Daten bleiben auf der Festplatte oder dem Objekt; Die Hauptschlüssel befinden sich woanders, in einer speziellen Abteilung mit strengen Zugangsrichtlinien.
In der Praxis sind bei europäischen Gastgebern drei Muster üblich:
Cloud-natives KMS. Ein Schlüssel pro Projekt, Region oder Ressource. Automatische Drehung möglich. „Decrypt“-Aufrufe werden protokolliert – sofern Sie Zugriff auf die Protokolle haben.
Externes KMS oder Client-HSM. Sie bringen den Schlüssel mit; Der Host speichert nur Referenzen (Envelope-Verschlüsselung). Verstärkte Kontrolle, erhöhte Komplexität der Verfügbarkeit.
Gemeinsames KMS ohne IAM-Isolation. Mehrere Clients teilen sich eine Instanz; Die Schlüssel sind logisch getrennt, aber die Plattformadministratoren bleiben mächtig. Ist explizit zu dokumentieren.
| Element | Zu stellende Frage | Gesundes Signal |
|---|---|---|
| Schlüsselbereich | Ein Schlüssel pro Umgebung? | Separate Produktion/Staging/Backup |
| Drehung | Automatisch oder manuell? | Datierte Police + Post-Rotationstest |
| KMS-Protokolle | Exportierbar nach SIEM? | Aufbewahrung ≥ Auditdauer |
| Glasbruch | Notfallverfahren? | Geschrieben, getestet, geplottet |
Die Trennung von Schlüsseln und Daten ist nutzlos, wenn dasselbe Administratorkonto beide beeinflussen kann.
IAM und Gewaltenteilung
KMS scheitert selten am Algorithmus. Es schlägt fehl, wer welche API aufrufen kann.
Stellen Sie sicher, dass sich beim Gastgeber – oder bei Ihnen vor Ort – niemand unkontrolliert ansammelt:
- Erstellung/Löschung von Schlüsseln;
- Entschlüsselung von Produktionsdaten;
- Löschung der Schlüsselnutzungsprotokolle.
Die geringste Berechtigung gilt sowohl für KMS als auch für Server. Idealerweise: zwei Personen für destruktive Operationen, Warnungen bei massiver „Entschlüsselung“, Korrelation mit Vorfallstickets.
Zeigen Sie für ein ISO-Audit oder eine Kundenbefragung einen anonymisierten Protokollauszug vor, der beweist, dass ein Schlüsselzugriff einer dokumentierten Änderung entspricht – und nicht einer mündlichen Zusage.
Häufige Projektfehler
Ein Schlüssel für alles. Produktion, Backups und Analysen verwenden denselben Hauptschlüssel. Ein Leak oder Widerruf legt alles lahm.
Rotation ohne Wiederherstellungstest. Der Schlüssel dreht sich; Alte Backups werden aufgrund fehlender Versionsdokumentation unlesbar.
KMS in einer Region, Daten in einer anderen. Latenz, Compliance und Verfügbarkeit weichen voneinander ab. Regionsübergreifende Kopien enthalten manchmal replizierte Schlüssel, ohne dass der DPO davon weiß.
Völlige Abhängigkeit vom Ausgabe-Host-KMS. Ohne Schlüsselexport oder Übergangszeitraum wird die Reversibilität zu einem einseitigen Hebel.
Jeder Fehler wird durch eine Karte korrigiert: Welche Ressource verwendet welchen Schlüssel, wer kann ihn widerrufen, wie lange werden die Protokolle aufbewahrt?
Der Gipfel: Das KMS ersetzt nicht den Vertrag
Folgendes wird in den Folien zum Thema „Cloud-Sicherheit“ ausgelassen.
Der Höhepunkt der Analyse: Es ist ein Trennungsnachweis erforderlich, kein Akronym. Bei einer Krisenbesprechung müssen Sie wissen, wer innerhalb einer Stunde den Zugang zu den Schlüsseln sperren kann – und ob sich diese Person bei Ihnen zu Hause oder bei ihnen aufhält.
Entscheide dich und gehe ohne blinden Fleck voran
Listen Sie die verschlüsselten Ressourcen auf (Basen, Buckets, Volumes, Backups). Notieren Sie sich jeweils die Schlüssel-ID, die KMS-Region, den IAM-Besitzer und die Rotationsfrequenz.
Fragen Sie zwei in die engere Wahl gezogene Hosts: Export von KMS-Protokollen über 30 Tage, Rotationsrichtlinie, Widerrufsszenario. Querverweis mit unserem Vergleicher und dem Leitfaden Verschlüsselung im Ruhezustand, um Schlüssel und Daten abzugleichen.
Testen Sie eine Rotation beim Staging und dann eine veraltete Archivwiederherstellung. Ohne diesen Test bleibt die KMS-Richtlinie theoretisch.
Häufig gestellte Fragen
Was ist ein KMS im Hosting-Kontext?
Ein Schlüsselverwaltungsdienst zentralisiert die Erstellung, Speicherung, Rotation und Prüfung der Verwendung von Verschlüsselungsschlüsseln. Es trennt Schlüssel logisch von verschlüsselten Daten – vorausgesetzt, die Zugriffsrechte sind ordnungsgemäß isoliert.
Vom Host verwaltetes KMS oder externes KMS?
Das KMS des Hosts vereinfacht die Integration, hat jedoch häufig denselben operativen Umfang. Ein externes KMS (HSM, Sovereign Cloud, On-Premise) stärkt die Unabhängigkeit, wenn Sie Verfügbarkeit und Latenz kontrollieren.
Wie kann ich nachweisen, dass ein Schlüssel nicht missbräuchlich verwendet wurde?
Über API-Aufrufprotokolle (Decrypt, GenerateDataKey), korreliert mit IAM-Identitäten, mit ausreichender Aufbewahrung und Lesezugriff, der Ihrem Sicherheitsteam oder dem Prüfer vorbehalten ist.
Was passiert, wenn das KMS nicht verfügbar ist?
Dienste, die davon abhängen, verweigern möglicherweise den Start oder das Lesen von Daten. Dies ist der Kontrollkompromiss: Hochverfügbarkeit dokumentieren, Sicherungsschlüssel und das Break-Glass-Verfahren.
Ein KMS ist nur das wert, was Ihre Protokolle und Rechte beweisen können – nicht das, was das Produktblatt verspricht.