Schlüsselverwaltung in Cloud und Unternehmen: Lebenszyklus nach NIST SP 800-57, KMS vs. HSM vs. KMaaS vs. MPC und eine Checkliste mit 15 Kriterien.
Unternehmensweite Schlüsselverwaltung (Enterprise Key Management) ist die zentrale Verwaltung kryptografischer Schlüssel über alle Anwendungen, Clouds und SaaS-Dienste einer Organisation hinweg. Sie regelt, wie Schlüssel erzeugt, gespeichert, verwendet, rotiert, widerrufen und vernichtet werden, nach einer einzigen Richtlinie und mit einem einzigen Audit-Trail. Die Schlüsselverwaltung in der Cloud ist dabei heute der grösste Teil der Aufgabe, denn die meisten Schlüssel liegen inzwischen bei Cloud- und SaaS-Anbietern. Ein Enterprise Key Management System (EKMS) ist die Software, oft auch die Hardware, die diese Richtlinie durchsetzt.
Den meisten Organisationen fehlt es nicht an Verschlüsselung. Was ihnen fehlt, ist die Kontrolle über die Schlüssel dahinter. Schlüssel sind über Cloud-KMS-Dienste, HSMs, «Customer-Managed Keys» in SaaS-Diensten und Anwendungsgeheimnisse verteilt, jeweils mit eigener Konsole, eigenen Administratoren und eigenen Logs. Fragt eine Aufsichtsbehörde, wer einen bestimmten Datenbestand entschlüsseln kann, ist die Antwort nur mühsam zusammenzutragen.
Dieser Leitfaden richtet sich an Sicherheitsarchitekten und CISOs, die 2026 entscheiden, wie sie Schlüssel verwalten. Er definiert die Begriffe (KMS, HSM, Key Management as a Service, MPC), beschreibt den Schlüssellebenszyklus nach NIST, vergleicht sechs Bereitstellungsmodelle, nennt die relevanten Standards (PKCS#11, KMIP, FIPS 140-3) und schliesst mit einer Bewertungscheckliste mit 15 Kriterien.
Schlüssel liegen typischerweise in Cloud-KMS-Diensten, SaaS-Plattformen, Datenbanken mit Transparent Data Encryption, HSMs vor Ort und Vault-Software. Jeder dieser Orte ist ein eigener Schlüsselspeicher mit eigenem Rotationsplan, eigenem Zugriffsmodell und eigenem Log-Format. Die Folgen:
Die zentrale Kontrolle in der Schlüsselverwaltung lautet: Wer Ihre Daten speichert, sollte nicht zugleich die einzige Partei sein, die den Schlüssel zu deren Entschlüsselung kontrolliert. Erzeugt und hält ein Cloud- oder SaaS-Anbieter den Schlüssel in seinem eigenen KMS, gehören dessen Betriebspersonal, dessen rechtliche Verpflichtungen und dessen Sicherheitsvorfälle zu Ihrem Bedrohungsmodell. Externe Schlüsselverwaltung, oft Hold Your Own Key (HYOK) genannt, bringt den Schlüssel ausserhalb der Kontrolle des Anbieters. Unser Leitfaden zu Hold Your Own Key (HYOK) behandelt die Muster im Detail.
Aufsichtsbehörden für Finanzsektor und kritische Infrastrukturen verlangen zunehmend, dass Unternehmen zeigen, wie kryptografische Schlüssel gesteuert werden, und nicht nur, dass Daten verschlüsselt sind. Einzelheiten finden Sie in unseren Leitfäden zu den Verschlüsselungsanforderungen von DORA, den Verschlüsselungsanforderungen von NIS2 und zur FINMA-Aufsichtsmitteilung 05/2026 für Schweizer Banken. Der gemeinsame Nenner: ein dokumentierter Schlüssellebenszyklus, eingeschränkter und protokollierter Zugriff und die Fähigkeit, Algorithmen im Zuge der Post-Quanten-Migration zu wechseln.
Die Referenz, auf die sich die meisten Prüfer und Rahmenwerke stützen, ist NIST Special Publication 800-57 Part 1 Revision 5, Recommendation for Key Management: Part 1 – General (Mai 2020). Sie gibt allgemeine Hinweise zu Schlüsseltypen, zum Schutz, den jeder Typ benötigt, und zu den zugehörigen Funktionen der Schlüsselverwaltung.
SP 800-57 unterteilt den Lebenszyklus der Schlüsselverwaltung in vier Phasen und ordnet jeden Schlüssel einem von sechs Zuständen zu:
| Phase | Was geschieht | Schlüsselzustände |
|---|---|---|
| Präoperativ | Schlüsselmaterial noch nicht für den normalen Gebrauch verfügbar; Schlüssel erzeugt oder wartet auf Aktivierung | Pre-activation |
| Operativ | Schlüssel verfügbar und im normalen Gebrauch | Active, Suspended |
| Postoperativ | Nicht mehr im normalen Gebrauch, aber weiterhin zugänglich, um bereits geschützte Daten zu verarbeiten (z. B. entschlüsseln, verifizieren); kann archiviert werden | Deactivated, Compromised |
| Vernichtet | Schlüssel nicht mehr verfügbar; Metadaten können aufbewahrt werden | Destroyed |
Zwei Details sind für das Design wichtig: Ein suspendierter Schlüssel kann Daten verarbeiten (zum Beispiel entschlüsseln), aber keinen neuen Schutz anwenden, und nach der Vernichtung dürfen die Metadaten des Schlüssels (Name, Typ, Kryptoperiode, Nutzungszeitraum) als Nachweis aufbewahrt werden.
NIST definiert eine Kryptoperiode als den Zeitraum, in dem ein bestimmter Schlüssel zur Verwendung autorisiert ist. Eine geeignete Kryptoperiode begrenzt, wie viele Daten bei einer Kompromittierung des Schlüssels offengelegt werden, wie viel Material für eine Kryptoanalyse zur Verfügung steht und wie viel Zeit ein Angreifer hat, um die Schutzmassnahmen für den Schlüssel zu umgehen. Wird ein Schlüssel kompromittiert, ist seine Kryptoperiode nicht mehr gültig.
SP 800-57 nennt die Faktoren, die die Länge einer Kryptoperiode bestimmen sollten, darunter die Stärke des Algorithmus und die Schlüssellänge, die Implementierung des Mechanismus (zum Beispiel ein Hardwaremodul gegenüber Software auf einem PC), die Betriebsumgebung, die Personalfluktuation, das Datenvolumen, die Schutzdauer der Daten und das Verfahren für den Schlüsselwechsel. Die Publikation gibt zudem empfohlene Kryptoperioden je Schlüsseltyp an; verwenden Sie diese Werte direkt aus der Publikation statt Faustregeln.
Was das für ein Enterprise Key Management System bedeutet: Es muss Zustände explizit abbilden (nicht nur «aktiviert/deaktiviert»), Kryptoperioden je Schlüsseltyp durchsetzen, Schlüssel nach dem Ende ihrer Verwendung zur Verschlüsselung weiterhin zur Entschlüsselung nutzbar halten und Nachweise über die Vernichtung aufbewahren.
Kurz gesagt: KMS vs. HSM heisst Richtlinien und Lebenszyklus gegenüber sicherer Speicherung und Ausführung. Die meisten Unternehmen brauchen beide Funktionen; die Frage ist, wer welche betreibt und wo das Vertrauen liegt.
| Modell | Wer die Verwahrung hält | Wer technisch auf Schlüssel zugreifen kann | Betriebskosten | Verfügbarkeit | Compliance-Nachweise |
|---|---|---|---|---|---|
| HSM vor Ort | Sie | Ihre HSM-Administratoren | Hoch: Hardware, Rechenzentrum, Fachpersonal, Erneuerungszyklen | Sie planen die Hochverfügbarkeit (Cluster, Standorte) | Starke Hardware-Nachweise; Lebenszyklus- und Zugriffslogs bauen Sie selbst |
| Cloud-HSM | Sie, auf Hardware des Anbieters | Ihre Partitionsbenutzer; der Anbieter betreibt die Hardware | Mittel bis hoch: Preis pro HSM, Clustering und Schlüsseloperationen betreiben Sie | SLA des Anbieters plus Ihr Cluster-Design | Hardware-Nachweise verfügbar; der Anbieter ist Teil der Vertrauenskette |
| KMS des Cloud-Anbieters | Anbieter, nach Ihren Richtlinien | Vom Anbieter verwalteter Dienst; Sie steuern die IAM-Richtlinien | Niedrig: Preis pro Schlüssel und pro Anfrage | SLA des Anbieters, hoch | Gute native Logs, aber je Cloud getrennt; der Anbieter hält den Schlüssel |
| Externes / unabhängiges KMS (selbst betrieben) | Sie | Ihre KMS-Betreiber | Mittel bis hoch: Sie betreiben Software, Hochverfügbarkeit und Backups | Sie planen die Hochverfügbarkeit | Ein Lebenszyklus und ein Audit-Trail über alle Clouds, sofern Integrationen vorhanden sind |
| KMaaS (unabhängig) | Sie (Richtlinien), der Anbieter betreibt den Dienst | Abhängig vom Design: Betriebspersonal des Anbieters erreicht Schlüsselmaterial oder nicht | Niedrig bis mittel: Abonnement | SLA des Anbieters | Zentrales Audit über Clouds und SaaS; prüfen Sie, was der Anbieter sehen kann |
| MPC-basiertes KMS | Verteilt auf unabhängige Shards | Kein einzelner Betreiber oder Host hält einen vollständigen Schlüssel | Niedrig bis mittel als Dienst | Das Schwellenwert-Design toleriert den Ausfall einzelner Knoten | Zentrales Audit; der Verwahrungsnachweis beruht auf der Trennung der Anteile |
Lesen Sie die Tabelle anhand der Frage, die Aufsichtsbehörden stellen: Wer könnte Ihre Daten entschlüsseln, ohne dass Sie davon wissen? Beim KMS des Cloud-Anbieters schliesst die Antwort den Anbieter ein; bei MPC muss ein Angreifer oder Insider mehrere unabhängige Shards kompromittieren, nicht nur einen.
Ein Beispiel für externe Schlüssel in einer Cloud: Ein AWS KMS External Key Store (XKS) stützt sich auf einen externen Schlüsselmanager, den Sie ausserhalb von AWS besitzen. AWS KMS kommuniziert mit ihm nur über einen External Key Store Proxy, «cannot create, view, manage, or delete your keys», und verwendet doppelte Verschlüsselung, sodass weder AWS KMS noch der Besitzer des externen Schlüssels allein entschlüsseln kann. AWS benennt auch den Zielkonflikt klar: Sie übernehmen die Verantwortung für Verfügbarkeit, Dauerhaftigkeit und Latenz der Schlüsseloperationen.
Ein Enterprise-KMS ist nur so nützlich wie die Systeme, an die es sich anbinden lässt. Drei Familien von Schnittstellen decken den Grossteil der Umgebung ab.
PKCS#11 (Cryptoki) ist die C-API, über die Anwendungen, Datenbanken, Webserver und Vault-Software mit einem HSM oder einem HSM-ähnlichen Token kommunizieren. Sie wird von OASIS gepflegt; die aktuelle Version, PKCS #11 Specification Version 3.2, wurde am 3. Juni 2026 zum OASIS Standard. Wenn ein Produkt «HSM-Integration» verspricht, ist meist PKCS#11 gemeint.
Das Key Management Interoperability Protocol ist ein Wire-Protokoll zwischen Schlüsselverwaltungsservern und Clients (Speichersysteme, Datenbanken, Backup-Systeme). KMIP Specification Version 2.1 ist seit dem 14. Dezember 2020 ein OASIS Standard. In KMIP sind die Operationen des Schlüssellebenszyklus (create, register, locate, activate, revoke, destroy) herstellerübergreifend standardisiert.
Hyperscaler, SaaS-Anbieter und Datenbanken bieten eigene Schnittstellen für externe Schlüssel: AWS XKS, Microsoft 365 Double Key Encryption und Customer Key, Snowflake Tri-Secret Secure, Oracle TDE, SQL Server EKM. Diese sind proprietär; der praktische Test für ein Enterprise-KMS ist daher die Liste der Integrationen, die es bereits mitbringt.
FIPS 140-3, Security Requirements for Cryptographic Modules (veröffentlicht am 22. März 2019), definiert vier aufsteigende, qualitative Sicherheitsstufen für kryptografische Module und ist an ISO/IEC 19790:2012 ausgerichtet. Module werden im Cryptographic Module Validation Program (CMVP) validiert, das NIST gemeinsam mit dem Canadian Centre for Cyber Security betreibt; akkreditierte Labore testen das Modul, und das CMVP prüft und validiert das Ergebnis.
Drei praktische Punkte für Käufer:
In einem HSM existiert der vollständige Schlüssel innerhalb einer einzigen manipulationsresistenten Grenze. Diese Grenze ist stark, aber sie ist ein einzelner Vertrauenspunkt: Wer das Gerät, seine Administratoren oder seine Partitionszugangsdaten kontrolliert, kontrolliert den Schlüssel.
Multi-Party Computation beseitigt diesen einzelnen Punkt. Jeder Schlüssel wird in Anteile aufgeteilt, die unabhängige Knoten halten. Signatur oder Entschlüsselung werden gemeinsam aus den Anteilen berechnet, und der vollständige Schlüssel wird nie rekonstruiert. In einem Schwellenwertverfahren muss eine festgelegte Anzahl von Anteilen für jede Operation zusammenwirken. Das ergibt zwei Eigenschaften zugleich:
MPC und HSMs schliessen sich nicht gegenseitig aus: Die Anteile können ihrerseits durch HSMs geschützt werden, und HSMs bleiben die richtige Antwort, wo eine Vorgabe eine validierte Hardwaregrenze verlangt. Einen detaillierten Vergleich von Sicherheitsarchitektur, Leistung und Kosten finden Sie unter MPC vs. HSM in der Schlüsselverwaltung.
| # | Kriterium | Was Sie fragen sollten |
|---|---|---|
| 1 | Verwahrungsmodell | Wer kann einen vollständigen Schlüssel technisch verwenden oder exportieren: Sie, der Anbieter, der Cloud-Anbieter? |
| 2 | Trennung von den Datenhaltern | Wird der Schlüssel ausserhalb des Anbieters gehalten, der die Daten speichert (HYOK)? |
| 3 | Integrationen | Welche Clouds, SaaS-Plattformen und Datenbanken werden heute unterstützt, nicht erst laut Roadmap? |
| 4 | Standardschnittstellen | PKCS#11-Bibliothek? Version des KMIP-Servers? |
| 5 | Lebenszyklusmodell | Sind die Zustände nach SP 800-57 (pre-activation, active, suspended, deactivated, compromised, destroyed) abgebildet? Werden Kryptoperioden durchgesetzt? |
| 6 | Rotation ohne Ausfallzeit | Lassen sich Schlüssel rotieren, während alte Versionen bestehende Daten weiterhin entschlüsseln? |
| 7 | Audit | Wird jede Operation zentral, manipulationssicher und exportierbar in Ihr SIEM protokolliert? |
| 8 | Zugriffskontrolle | Nur RBAC oder auch attributbasierte Richtlinien (ABAC)? Vier-Augen-Prinzip für destruktive Aktionen? |
| 9 | Mandantenfähigkeit | Sind Geschäftsbereiche, Tochtergesellschaften oder Kunden als Mandanten voneinander isoliert? |
| 10 | Hochverfügbarkeit | Was geschieht, wenn ein Knoten, eine Region oder der Anbieter nicht verfügbar ist? Wie lautet das dokumentierte SLA? |
| 11 | Latenz | Wie viel Latenz kommt pro Operation hinzu, für die Dienste, die synchron aufrufen? |
| 12 | PQC-Bereitschaft | Kann es ML-KEM- und ML-DSA-Schlüssel sowie hybride Modi verwalten und Algorithmen per Richtlinie wechseln? |
| 13 | Hardware-Absicherung | Welche Backends halten Schlüssel, und welche haben ein aktuelles FIPS-140-3-Zertifikat? |
| 14 | Ausstieg und Portabilität | Können Sie Schlüssel exportieren, neu verpacken (re-wrap) oder migrieren, wenn Sie den Anbieter wechseln? |
| 15 | Preismodell | Pro Schlüssel, pro Operation, pro Integration oder pauschal? Wie skalieren die Kosten mit dem Wildwuchs der Schlüssel? |
Kriterium 12 verdient 2026 besondere Aufmerksamkeit. Post-Quanten-Schlüsselkapselung verändert Schlüsselgrössen und Handhabung; unser Leitfaden zur ML-KEM-Schlüsselverwaltung zeigt, was sich in der Praxis ändert.
DuoKey beruht auf einer einzigen Idee: Kein Cloud-Anbieter, kein Betreiber und kein kompromittierter Host sollte einen vollständigen Schlüssel halten.
Für alles, was hier nicht aufgeführt ist, etwa Bereitstellungsregionen, Zertifizierungen oder Preise, wenden Sie sich direkt an DuoKey.
Q: Was ist unternehmensweite Schlüsselverwaltung (Enterprise Key Management)?
Unternehmensweite Schlüsselverwaltung ist die zentrale Verwaltung kryptografischer Schlüssel über alle Anwendungen, Clouds und SaaS-Dienste einer Organisation hinweg. Sie umfasst Erzeugung, Speicherung, Verwendung, Rotation, Widerruf und Vernichtung nach einer einzigen Richtlinie und mit einem einzigen Audit-Trail, statt einer eigenen Konsole pro Anbieter.
Q: Was ist Key Management as a Service (KMaaS)?
Key Management as a Service ist ein Key Management System, das als verwalteter Dienst bereitgestellt wird: Der Anbieter verantwortet Verfügbarkeit, Skalierung und Patching, und Sie behalten die Kontrolle über die Schlüsselrichtlinien. Das KMS eines Cloud-Anbieters ist eine Form davon; ein unabhängiges KMaaS läuft ausserhalb des Cloud- oder SaaS-Anbieters, dessen Daten es schützt, und hält so den Schlüssel von den Daten getrennt.
Q: KMS vs. HSM: Was ist der Unterschied?
Ein KMS verwaltet Lebenszyklus und Zugriffsrichtlinien von Schlüsseln über mehrere Systeme und stellt sie über APIs bereit. Ein HSM ist ein manipulationsresistentes Gerät, das Schlüssel speichert und kryptografische Operationen innerhalb einer Hardwaregrenze ausführt. Viele KMS-Installationen nutzen ein HSM als Speicher-Backend; die beiden ergänzen sich also.
Q: Was ist MPC-Schlüsselverwaltung?
MPC-Schlüsselverwaltung teilt jeden Schlüssel in Anteile auf, die unabhängige Knoten halten, und berechnet kryptografische Operationen gemeinsam, sodass der vollständige Schlüssel nie an einem Ort zusammengesetzt wird. Wer einen Knoten, einen Betreiber oder ein Cloud-Konto kompromittiert, erhält einen Anteil, keinen nutzbaren Schlüssel.
Q: Was sagt NIST zum Schlüssellebenszyklus?
NIST SP 800-57 Part 1 Rev. 5 unterteilt den Lebenszyklus in die Phasen präoperativ, operativ, postoperativ und vernichtet, wobei sich Schlüssel in den Zuständen pre-activation, active, suspended, deactivated, compromised oder destroyed befinden. Die Publikation definiert zudem Kryptoperioden, also den Zeitraum, in dem ein Schlüssel zur Verwendung autorisiert ist, und die Faktoren, die diese bestimmen sollten.
Q: Ist FIPS 140-2 im Jahr 2026 noch gültig?
Laut CMVP wandern FIPS-140-2-Validierungen nach dem 21. September 2026 auf die Historical List; danach dürfen Behörden diese Module nur noch in bestehenden Systemen weiterverwenden. Neue Beschaffungen sollten FIPS-140-3-Zertifikate verlangen.
Q: Was sind PKCS#11 und KMIP?
PKCS#11 ist die von OASIS gepflegte API, über die Anwendungen mit HSMs und HSM-ähnlichen Tokens kommunizieren; Version 3.2 wurde im Juni 2026 zum OASIS Standard. KMIP ist das OASIS-Protokoll zwischen Schlüsselservern und Clients wie Speichersystemen und Datenbanken; Version 2.1 ist seit Dezember 2020 ein OASIS Standard.
Q: Brauche ich noch ein HSM, wenn ich ein MPC-basiertes KMS verwende?
Nicht immer. MPC beseitigt den einzelnen Vertrauenspunkt, den ein HSM darstellt, doch manche Vorgaben verlangen eine validierte Hardwaregrenze. Viele Organisationen kombinieren beides: MPC für die verteilte Verwahrung und Vaults mit HSM-Backend dort, wo eine Hardware-Validierung erforderlich ist.
Unternehmensweite Schlüsselverwaltung bedeutet einen Lebenszyklus, ein Zugriffsmodell und einen Audit-Trail über die Schlüsselspeicher, die Sie bereits haben, ohne dass ein einzelner Anbieter, Betreiber oder Host Ihre Daten allein entschlüsseln kann.
Geschrieben von
DuoKey Team
Verwandte Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
