Übersicht – AWS KMS und CloudHSM

AWS bietet zwei Dienste für die kryptografische Schlüsselverwaltung in der Cloud an: AWS Key Management Service (AWS KMS) und AWS CloudHSM. Beide schützen Verschlüsselungsschlüssel, unterscheiden sich jedoch grundlegend hinsichtlich FIPS-Validierungsstufe, Mandantenmodell, Hardwarekontrolle und den jeweils erfüllbaren Compliance-Anforderungen. Für die meisten Workloads empfiehlt sich AWS KMS mit kundenverwalteten Schlüsseln als Ausgangspunkt. CloudHSM ist nur erforderlich, wenn dedizierte Hardware gemäß FIPS 140-2 Level 3 oder der Verzicht auf AWS-Schlüsselzugriff zwingend vorgeschrieben ist.

Kurzantwort: AWS KMS vs. CloudHSM im Überblick

AWS KMS ist ein vollständig verwalteter, mandantenfähiger Schlüsselverwaltungsdienst mit FIPS 140-2 Level 2-validierten HSMs, nativer Integration mit über 100 AWS-Services, automatischer Schlüsselrotation und CloudTrail-Audit-Protokollierung pro Operation. Er ist der ideale Ausgangspunkt für die meisten AWS-Verschlüsselungs-Workloads. AWS CloudHSM ist ein dedizierter Single-Tenant-HSM-Service mit FIPS 140-2 Level 3-validierter Hardware in Ihrer eigenen VPC, in der AWS keinen Zugriff auf Ihre Schlüssel hat. CloudHSM ist erforderlich für FIPS Level 3-Vorgaben, klassifizierte Workloads oder Anwendungen, die direkten PKCS#11/JCE/CNG/OpenSSL-API-Zugriff benötigen. Die beiden Services lassen sich auch kombinieren: Ein CloudHSM-basierter, benutzerdefinierter KMS-Schlüsselspeicher bietet Ihnen gleichzeitig Hardware-Schutz der Stufe 3 und native KMS-Serviceintegration.

Wichtige Erkenntnisse

• KMS ist mandantenfähig (Level 2); CloudHSM ist mandantenfähig (Level 3): AWS KMS verwendet FIPS 140-2 Level 2-validierte HSMs, die von mehreren Kunden gemeinsam genutzt und logisch isoliert werden. AWS CloudHSM bietet dedizierte physische HSM-Hardware, die nach FIPS 140-2 Level 3 validiert ist und auf die kein anderer Kunde Zugriff hat.
• AWS befindet sich innerhalb der KMS-Vertrauensgrenze, aber außerhalb der CloudHSM-Schlüsselvertrauensgrenze: Bei KMS betreibt AWS die HSM-Hardware und ist ein operativer Akteur in der Schlüsselkette. Bei CloudHSM verwaltet AWS die physische Infrastruktur, hat aber zu keinem Zeitpunkt Zugriff auf Ihr Schlüsselmaterial oder Ihre HSM-Partitionen.
• KMS integriert sich nativ in AWS-Dienste; CloudHSM erfordert benutzerdefinierte API-Aufrufe oder einen benutzerdefinierten KMS-Schlüsselspeicher: AWS KMS ist nativ mit S3, EBS, RDS, Lambda und über 100 weiteren Diensten kompatibel. CloudHSM lässt sich nicht nativ in diese Dienste integrieren, es sei denn, es wird mit einem benutzerdefinierten KMS-Schlüsselspeicher kombiniert.
• Der maßgeschneiderte Schlüsselspeicher schlägt die Brücke zwischen beiden Welten: Ein benutzerdefinierter KMS-Schlüsselspeicher, der von einem CloudHSM-Cluster unterstützt wird, bietet Hardware-Schutz der Stufe 3 für Schlüssel, die über die Standard-KMS-API und alle nativen AWS-Serviceintegrationen verwendet werden. Dies ist die gängige Produktionsarchitektur, wenn sowohl Schutz der Stufe 3 als auch die native AWS-Integration erforderlich sind.
• Der Kostenunterschied ist groß; wählen Sie nach den Anforderungen, nicht nach Ihren Vorlieben: KMS kostet 1 US-Dollar pro Schlüssel und Monat zuzüglich 0.03 US-Dollar pro 10.000 API-Aufrufe. Ein CloudHSM-Cluster mit zwei HSMs kostet etwa 2,100 US-Dollar pro Monat. CloudHSM sollte nur dann gewählt werden, wenn eine zwingende Compliance- oder technische Anforderung die Kosten und den Betriebsaufwand rechtfertigt.

AWS Key Management Service (AWS KMS): Überblick

AWS Key Management Service (AWS KMS) ist ein vollständig verwalteter Dienst, der kryptografische Schlüssel erstellt, speichert und verwaltet, die zum Schutz von Daten in AWS-Diensten und Kundenanwendungen verwendet werden. KMS ist nativ in über 100 AWS-Dienste integriert, darunter Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda und AWS Secrets Manager. Wenn Sie die Verschlüsselung für einen dieser Dienste aktivieren, generiert, speichert und schützt KMS die Verschlüsselungsschlüssel, die diese Verschlüsselung wirksam machen.

Sämtliches AWS KMS-Schlüsselmaterial wird in FIPS 140-2 Level 2-validierten Hardware-Sicherheitsmodulen (HSMs) generiert und gespeichert . Das Schlüsselmaterial verlässt unter keinen Umständen die HSM-Grenzen im Klartext. AWS KMS betreibt die HSMs als Mandantendienst, d. h. die Schlüssel mehrerer Kunden teilen sich dieselbe physische Hardware, sind aber logisch voneinander isoliert. Schlüssel, die in einer bestimmten AWS-Region erstellt wurden, können nicht in einer anderen Region verwendet oder abgerufen werden.

AWS KMS unterteilt Schlüssel in drei Typen: kundenverwaltete Schlüssel (die Sie erstellen, kontrollieren und nach einem benutzerdefinierten Zeitplan rotieren lassen), AWS-verwaltete Schlüssel (die von AWS-Services automatisch erstellt werden, wenn Sie die Verschlüsselung aktivieren, ohne einen Schlüssel anzugeben) und AWS-eigene Schlüssel (die von mehreren Kundenkonten gemeinsam genutzt werden und in Ihrem Konto nicht sichtbar sind). Für regulierte Workloads bieten nur kundenverwaltete Schlüssel den für PCI DSS, HIPAA und FedRAMP erforderlichen CloudTrail-Audit-Trail pro Operation und die unabhängige Schlüsselkontrolle. AWS hat die „Customer Master Keys (CMKs)“ im Jahr 2021 in „KMS-Schlüssel“ umbenannt; die zugrunde liegende Funktionalität bleibt unverändert.

AWS KMS unterstützt symmetrische AES-256-Schlüssel für die Datenverschlüsselung und -entschlüsselung, asymmetrische RSA-Schlüssel (2048, 3072, 4096 Bit) und ECC-Schlüssel (NIST P-256, P-384, P-521 und SECG secp256k1) für die Signatur und asymmetrische Verschlüsselung sowie HMAC-Schlüssel für die Nachrichtenauthentifizierung. Alle symmetrischen und privaten asymmetrischen Schlüssel verlassen die KMS-HSMs niemals im Klartext; nur öffentliche Schlüssel können aus KMS exportiert werden.

Eine detaillierte Sicherheitsbewertung von AWS KMS, einschließlich der Vertrauensgrenzenanalyse, des IAM-Modells und des Compliance-Mappings, finden Sie in unserem Leitfaden „ Wie sicher sind die Key-Management-Dienste von Amazon (AWS KMS)?“.

AWS KMS: Zusammenfassung der Kryptoeigenschaften

Eigenschaft	AWS-KMS
Mietmodell	Mandantenfähig (gemeinsame HSM-Hardware, logische Isolation)
FIPS 140-2-Validierung	Level 2
Unterstützte Schlüsseltypen	Symmetrisch (AES-256), Asymmetrisch (RSA 2048/3072/4096, ECC NIST/SECG), HMAC
Schlüsseltypen	Kundenseitig verwaltet, von AWS verwaltet, im Besitz von AWS
API-Zugriff	AWS SDK / AWS KMS API
Zugriffskontrolle	IAM-Identitätsrichtlinien + KMS-Schlüsselressourcenrichtlinie (obligatorisch)
Wichtige Zugänglichkeit	Regional (in einer Region erstellte Schlüssel können nicht in einer anderen Region verwendet werden)
Hohe Verfügbarkeit	AWS-verwaltet, integriert (keine Kundenkonfiguration erforderlich)
Audit-Fähigkeit	CloudTrail-Verwaltungsereignisse (immer aktiv) + Datenereignisse (muss aktiviert werden)
Automatische Schlüsseldrehung	Ja (90 Tage bis 7 Jahre für vom Kunden verwaltete Schlüssel mit von AWS generiertem Material)
BYOK-Unterstützung	Ja (über KMS-Importaufträge; Ursprung: EXTERN)
Kosten	1.00 $/Schlüssel/Monat + 0.03 $/10 API-Aufrufe

AWS CloudHSM: Überblick

AWS CloudHSM ist ein cloudbasierter Hardware-Sicherheitsmodul- Service, der dedizierte, mandantenfähige physische HSM-Hardware in Ihrer eigenen Amazon Virtual Private Cloud (VPC) bereitstellt. CloudHSM ist nach FIPS 140-2 Level 3 validiert, dem höchsten kommerziell verfügbaren FIPS-Validierungsniveau für HSM-Hardware. Im Gegensatz zu AWS KMS, wo AWS die HSMs als gemeinsam genutzten Service verwaltet, stellt CloudHSM Ihrer Organisation exklusiv dedizierte Hardware zur Verfügung.

AWS verwaltet die physische Infrastruktur für CloudHSM (Racks, Netzwerk, Stromversorgung, Hardwareaustausch und Firmware-Updates), hat aber zu keinem Zeitpunkt Zugriff auf Ihre HSM-Software, Ihre Schlüssel oder Ihre HSM-Benutzeranmeldeinformationen. Sie verwalten die HSM-Softwareebene, die HSM-Benutzer- und Partitionseinstellungen sowie die Schlüssel selbst mithilfe von Hardware-Authentifizierungsmechanismen, die von AWS IAM getrennt sind. Das bedeutet, dass AWS selbst bei rechtlicher Verpflichtung nicht auf Ihre Schlüssel zugreifen kann, da AWS tatsächlich nicht über die HSM-Authentifizierungsdaten oder die Schlüssel verfügt.

CloudHSM wird über branchenübliche kryptografische APIs angesprochen: PKCS#11 (der am weitesten verbreitete Standard unter HSM-Anbietern), JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) und OpenSSL Dynamic Engine. Dadurch ist CloudHSM mit einer Vielzahl von Anwendungen kompatibel, die HSM-gestützte kryptografische Operationen benötigen, darunter der Schutz privater Schlüssel durch Zertifizierungsstellen für Public-Key-Infrastrukturen (PKI) , Codesignierung, transparente Datenverschlüsselung (TDE) für Datenbanken, der Schutz privater Schlüssel durch TLS/SSL, die Verschlüsselung von Zahlungs-PINs und das digitale Rechtemanagement (DRM).

CloudHSM-Cluster können sich über mehrere Verfügbarkeitszonen innerhalb einer AWS-Region erstrecken und so eine hohe Verfügbarkeit gewährleisten. Jedes HSM im Cluster verwaltet eine synchronisierte Kopie aller Schlüsseldaten. Für Produktionsworkloads sind mindestens zwei HSMs in separaten Verfügbarkeitszonen erforderlich, um sicherzustellen, dass kein Hardwareausfall die kryptografischen Operationen beeinträchtigt.

AWS CloudHSM: Zusammenfassung der Kryptoeigenschaften

Eigenschaft	AWS CloudHSM
Mietmodell	Einzelmandant (dedizierte physische HSM-Hardware)
FIPS 140-2-Validierung	Level 3
Unterstützte Schlüsseltypen	Symmetrisch: AES (CBC-, GCM-, ECB-Modus); Asymmetrisch: RSA, ECC; Hashing: SHA-256, SHA-512, ECDSA
Hauptschlüssel	Der Hauptschlüssel wird im HSM-Hardwaresystem gespeichert und geschützt.
API-Unterstützung	PKCS#11, JCE (Java), OpenSSL Dynamic Engine, Microsoft CNG
Zugriffskontrolle	HSM-Benutzeranmeldeinformationen (Quorum-basierte K-of-N-Authentifizierung, getrennt von AWS IAM)
Wichtige Zugänglichkeit	Über VPC-Peering über mehrere VPCs innerhalb der Region erreichbar.
Hohe Verfügbarkeit	Fügen Sie HSMs in verschiedenen Verfügbarkeitszonen innerhalb des Clusters hinzu.
Audit-Fähigkeit	CloudTrail (Infrastrukturereignisse), CloudWatch (Metriken), HSM-Audit-Protokoll (wichtige Operationen), MFA-Unterstützung
Automatische Schlüsseldrehung	Nein (vom Kunden verwaltet, muss extern implementiert werden)
AWS-Zugriff auf Schlüssel	Keine (AWS kann nicht auf HSM-Partitionen oder Schlüsselmaterial zugreifen)
Kosten	~1.45 $/Std. pro HSM (~1,050 $/Monat pro HSM; ~2,100 $/Monat für einen 2-HSM-HA-Cluster)

BYOK und HYOK: Wichtige Souveränitätsoptionen

Sowohl AWS KMS als auch CloudHSM unterstützen Bring Your Own Key (BYOK)-Muster, aber die Mechanismen und Souveränitätsgarantien unterscheiden sich wesentlich.

BYOK mit AWS KMS: Sie generieren AES-256-Schlüsselmaterial in Ihrem eigenen HSM oder Schlüsselverwaltungssystem außerhalb von AWS. Anschließend verschlüsseln Sie das Material mit einem Schlüssel, den Sie über einen KMS-Importauftrag heruntergeladen haben, und laden das verschlüsselte Material in KMS hoch. Der KMS-Schlüsselursprung ist auf EXTERN eingestellt. AWS KMS verwendet Ihr importiertes Material für alle kryptografischen Operationen. Sie behalten das Original außerhalb von AWS; durch das Löschen der importierten Kopie aus KMS wird AWS die Berechtigung zur Verwendung des Schlüssels sofort und endgültig entzogen. AWS hat weiterhin Zugriff auf das importierte Schlüsselmaterial, solange es sich in KMS befindet. Eine automatische Rotation für importierte Schlüssel ist nicht verfügbar.

BYOK mit CloudHSM (als Generierungsquelle): Sie generieren Schlüsselmaterial in Ihrem CloudHSM-Cluster und verwenden dieses Material als BYOK-Quelle für Schlüssel, die in AWS KMS oder andere Schlüsselverwaltungssysteme importiert werden. Der Schlüssel wurde auf FIPS 140-2 Level 3-konformer Hardware generiert, die Sie kontrollieren. Dadurch erhalten Sie einen Level-3-Nachweis der Schlüsselherkunft. Nach dem Import in KMS ist die KMS-Kopie ein importierter Schlüssel (Ursprung: EXTERN); Ihr CloudHSM behält die autoritative Kopie.

HYOK (Hold Your Own Key) mit CloudHSM: Für ein Höchstmaß an Schlüsselsouveränität verschlüsseln Ihre Anwendungen Daten mit Schlüsseln, die sich in Ihrem CloudHSM-Cluster befinden und diesen niemals verlassen. AWS-Services speichern ausschließlich den Chiffretext. AWS hat unter keinen Umständen Zugriff auf den Klartext oder den Verschlüsselungsschlüssel. Dieses Muster erfordert, dass Ihre Anwendungen die CloudHSM-APIs für jede kryptografische Operation direkt aufrufen, und Ihr CloudHSM-Cluster muss hochverfügbar sein, damit alle Anwendungsoperationen erfolgreich sind.

Abmessungen	Natives KMS (AWS-generiert)	BYOK in KMS (Importiert)	CloudHSM (Schlüssel bleiben im HSM)
Schlüssel generiert von	AWS KMS HSM	Kunden-HSM (in KMS importiert)	Kunde (bleibt in CloudHSM)
AWS-Zugriff auf den Schlüssel während der Nutzung	Ja (Multi-Tenant-HSM-Betreiber)	Ja (operativer Zugriff während der Nutzung von KMS)	Nein
CloudTrail-Auditprotokoll	Ja (pro Operation über die KMS-API)	Ja (pro Operation über die KMS-API)	Nur HSM-Audit-Protokoll (nicht nativ in CloudTrail für wichtige Operationen)
Unabhängiger Widerruf	Schlüssel im KMS deaktivieren/löschen	Importiertes Material löschen (sofort)	Schlüssel im HSM-Cluster zerstören
Automatische Schlüsseldrehung	Ja (90 Tage bis 7 Jahre)	Nein (erneuter Import erforderlich)	Nein (vom Kunden verwaltet)
FIPS-Validierungsstufe	Level 2	Stufe 2 (in KMS); die Generierungsquelle kann Stufe 3 sein.	Level 3
Native AWS-Serviceintegration	Ja (über 100 Dienstleistungen)	Ja (über die KMS-API)	Nur über einen benutzerdefinierten Schlüsselspeicher
Operative Komplexität	Niedrig	Medium	Hoch

IAM-Zugriffskontrollmodell

AWS KMS und CloudHSM verwenden grundlegend unterschiedliche Zugriffskontrollmechanismen. Dies ist einer der wichtigsten Unterschiede, die man bei der Auswahl zwischen den beiden Systemen verstehen muss.

Die Zugriffskontrolle von AWS KMS basiert auf dem AWS IAM-Modell: einer Kombination aus Schlüsselressourcenrichtlinien (der primären, obligatorischen Kontrolle für jeden vom Kunden verwalteten Schlüssel) und IAM-Identitätsrichtlinien (einer sekundären Ebene). Eine Schlüsselrichtlinie muss vorhanden sein und jedem Prinzipal explizit die Berechtigung zur Verwendung des Schlüssels erteilen. IAM-Identitätsrichtlinien können zusätzliche KMS-Berechtigungen gewähren, jedoch nur im Rahmen der durch die Schlüsselrichtlinie festgelegten Berechtigungen. Service Control Policies (SCPs) auf AWS-Organisationsebene können zusätzliche Sicherheitsvorkehrungen über IAM hinaus hinzufügen. Das wichtigste IAM-Sicherheitsprinzip für KMS ist die Trennung von Schlüsseladministratoren (die Schlüsselrichtlinien, -rotation und -löschung verwalten können) und Schlüsselbenutzern (die die Funktionen „Verschlüsseln“, „Entschlüsseln“ und „Datenschlüssel generieren“ aufrufen können). Kein Prinzipal sollte beide Rollen für denselben Schlüssel innehaben. Ausführliche Informationen zum IAM-Modell finden Sie in unserem Leitfaden zur AWS KMS-Sicherheit.

Die Zugriffskontrolle von CloudHSM nutzt das eigene Benutzer- und Partitionsverwaltungssystem des HSM, das vollständig von AWS IAM getrennt ist. CloudHSM kennt drei Benutzerkategorien: den Precrypto Officer (PRECO, ein temporärer Benutzer, der nur für die erstmalige HSM-Initialisierung verwendet wird), Crypto Officers (COs, die HSM-Benutzer erstellen und löschen sowie Benutzeranmeldeinformationen verwalten können) und Crypto Users (CUs, die kryptografische Operationen mit Schlüsselmaterial durchführen). CloudHSM unterstützt die Quorum-basierte Man-of-N-Authentifizierung. Das bedeutet, dass sich eine Mindestanzahl von Crypto Officers authentifizieren muss, bevor sensible Operationen (wie das Löschen eines Schlüssels oder das Ändern einer Richtlinie) ausgeführt werden können. AWS IAM hat keinen Einfluss auf die Schlüsseloperationen von CloudHSM. Diese Authentifizierungsebene wird vollständig von Ihnen verwaltet, unabhängig von AWS-Konten oder IAM-Berechtigungen.

Dieser Unterschied im Zugriffsmodell hat erhebliche Sicherheitsauswirkungen: Bei AWS KMS ist eine fehlerhafte Konfiguration der Schlüsselrichtlinie oder der IAM-Richtlinie die häufigste Schwachstelle in der Praxis. Bei CloudHSM hingegen umfasst das Risikomodell fehlerhaft konfigurierte HSM-Benutzeranmeldeinformationen, zu niedrig eingestellte Quorumschwellenwerte oder unzureichende physische und logische Zugriffskontrollen für die HSM-Verwaltungstools.

Schlüsselrotation

AWS KMS-Schlüsselrotation Die Rotation von kundenverwalteten Schlüsseln mit AWS-generiertem Material erfolgt automatisch und ist zwischen 90 Tagen und 7 Jahren konfigurierbar. Bei der Rotation generiert KMS neues Schlüsselmaterial und legt dieses als primäre Version für neue Verschlüsselungsvorgänge fest. Frühere Schlüsselmaterialversionen bleiben dauerhaft erhalten, sodass damit verschlüsselte Daten weiterhin entschlüsselt werden können. Der Schlüssel-ARN und alle Aliase bleiben unverändert; die Rotation ist für Anwendungen transparent. Die Rotation kann bedarfsgesteuert über die RotateKeyOnDemand API. Bei BYOK-Schlüsseln mit importiertem Material ist die automatische Rotation nicht verfügbar; Sie müssen neues Material extern generieren und als neue Schlüsselversion erneut importieren.

AWS CloudHSM verfügt über keinen integrierten automatischen Rotationsmechanismus für Schlüssel. Sie sind für die Entwicklung und Durchführung des Rotationsprozesses verantwortlich: Generierung neuer Schlüssel im HSM, Aktualisierung der Referenzen in allen Anwendungen und Diensten, die den alten Schlüssel verwenden, gegebenenfalls erneute Verschlüsselung oder Migration von Daten und Stilllegung der alten Schlüssel. Dies führt im Vergleich zu KMS zu einer deutlich höheren betrieblichen Komplexität, insbesondere in Umgebungen mit vielen Schlüsseln oder Anwendungen. Für Compliance-Workloads, die eine regelmäßige Rotation kryptografischer Schlüssel erfordern (PCI DSS-Anforderung 3.7.4, NIST SP 800-57-Richtlinien zur Kryptoperiode), muss der Rotationsprozess für CloudHSM-Schlüssel vor der Produktionsbereitstellung konzipiert und getestet werden.

Audit-Protokollierung

Die AWS KMS CloudTrail-Integration ist eine der wichtigsten Compliance-Funktionen von KMS. Jeder KMS-API-Aufruf generiert ein CloudTrail-Ereignis, das die Operation, den Schlüssel-ARN, die anfragende IAM-Identität, die Quell-IP-Adresse, die Region und den Zeitstempel protokolliert. Management-Ereignisse (Schlüsselerstellung, Änderungen der Schlüsselrichtlinie, geplante Schlüssellöschung, deaktivierter Schlüssel) sind immer aktiviert. Datenereignisse (Generierung des Datenschlüssels, Entschlüsselung pro Objektoperation) müssen für regulierte Workloads separat aktiviert werden und stellen den pro Operation erforderlichen, identitätsverknüpften Audit-Trail gemäß PCI DSS Requirement 10, HIPAA Audit Control (45 CFR 164.312(b)) und FedRAMP AU-Kontrollen bereit.

Die Audit-Protokollierung von AWS CloudHSM funktioniert anders. Ereignisse auf Infrastrukturebene (HSM-Clustererstellung, Hinzufügen/Entfernen von HSM-Instanzen, Clusterlöschung) werden in CloudTrail angezeigt. Schlüsseloperationen innerhalb des HSM (Schlüsselerstellung, Verschlüsselung, Signierung, Entschlüsselung innerhalb der HSM-Partition) werden jedoch im internen Audit-Protokoll des HSM und nicht in CloudTrail protokolliert. Das HSM-Audit-Protokoll kann zur Aufbewahrung und Analyse in CloudWatch Logs oder einen S3-Bucket exportiert werden, bietet aber nicht die gleiche native CloudTrail-Integration wie KMS. In Umgebungen, in denen der Auditor für jede kryptografische Operation CloudTrail-Nachweise erwartet, sind zusätzliche Tools erforderlich, um das CloudHSM-Audit-Protokoll zu aggregieren und im gleichen Format darzustellen.

Benutzerdefinierter Schlüsselspeicher: Nutzung beider Dienste zusammen

Die Funktion „Benutzerdefinierter Schlüsselspeicher“ von AWS KMS ermöglicht die Kombination der einfachen Bedienung von KMS mit der FIPS 140-2 Level 3-konformen Hardware-Isolation von CloudHSM. Durch die Konfiguration eines benutzerdefinierten Schlüsselspeichers verbinden Sie Ihren CloudHSM-Cluster mit AWS KMS. Die in diesem benutzerdefinierten Schlüsselspeicher erstellten KMS-Schlüssel werden innerhalb Ihres CloudHSM-Clusters generiert, anstatt in der standardmäßigen KMS-Multi-Tenant-Infrastruktur. Die Schlüsseldaten sind nicht exportierbar und verlassen Ihren CloudHSM-Cluster niemals im Klartext.

Der praktische Vorteil: Alle über 100 AWS-Serviceintegrationen funktionieren weiterhin über die gewohnte KMS-API. S3 SSE-KMS, EBS-Verschlüsselung, RDS-Verschlüsselung, Secrets Manager-Verschlüsselung und alle anderen KMS-integrierten Dienste können einen Schlüssel verwenden, der von Ihrem CloudHSM-Cluster unterstützt wird. Aus Sicht der Anwendung und des AWS-Services handelt es sich lediglich um einen KMS-Schlüssel; die CloudHSM-Unterstützung ist transparent.

Wichtige Einschränkungen für benutzerdefinierte Schlüsselspeicher: Es werden mindestens zwei aktive HSMs in unterschiedlichen Verfügbarkeitszonen benötigt. Wenn Ihr CloudHSM-Cluster nicht verfügbar ist, kann KMS keine Operationen an den Schlüsseln in diesem benutzerdefinierten Schlüsselspeicher durchführen. Dies bedeutet, dass alle Anwendungen und AWS-Dienste, die diese Schlüssel verwenden, so lange fehlschlagen, bis der Cluster wiederhergestellt ist. Diese Verfügbarkeitsabhängigkeit stellt das größte Betriebsrisiko der Architektur für benutzerdefinierte Schlüsselspeicher dar. Konzipieren Sie Ihren CloudHSM-Cluster so, dass er dasselbe Verfügbarkeitsziel aufweist wie die Anwendungen, deren Verschlüsselungsschlüssel er speichert.

Für alle Details zur Funktionsweise der benutzerdefinierten Key-Store-Integration und der KMS-Schlüsselhierarchie siehe unseren AWS KMS Deep Dive.

So wählen Sie aus: Entscheidungsrahmen für AWS KMS vs. CloudHSM

Nutzen Sie dieses Entscheidungsmodell, um den richtigen Service für Ihre Arbeitslast auszuwählen:

Anforderung	Empfohlener Service
Verschlüsseln Sie S3, EBS, RDS, DynamoDB oder andere AWS-Dienste mit minimaler Konfiguration	AWS KMS (native Integration)
Eine Validierung nach FIPS 140-2 Level 2 ist akzeptabel.	AWS-KMS
Für FIPS 140-2 Level 3 ist dedizierte Hardware erforderlich.	AWS CloudHSM (oder ein benutzerdefinierter KMS-Schlüsselspeicher, der von CloudHSM unterstützt wird)
AWS muss vollständig von der Vertrauensgrenze ausgeschlossen werden.	AWS CloudHSM (HYOK/clientseitige Verschlüsselung)
CloudTrail-Audit-Protokoll pro Vorgang über die native AWS-Integration	AWS-KMS
Automatischer Schlüsselwechsel nach einem konfigurierbaren Zeitplan	AWS-KMS
PKCS#11-, JCE-, CNG- oder OpenSSL-API-Zugriff auf das HSM	AWS CloudHSM
Schutz des privaten CA-Schlüssels für eine PKI-Zertifizierungsstelle	AWS CloudHSM
TLS/SSL-Offload, Zahlungs-PIN-Verschlüsselung, Datenbank-TDE-Masterschlüssel	AWS CloudHSM
BYOK mit kundenkontrollierter Schlüsselgenerierungsquelle auf Stufe 3	In CloudHSM generieren; in KMS importieren (oder in CloudHSM behalten)
FedRAMP Moderat	AWS KMS (vom Kunden verwaltete Schlüssel)
FedRAMP High (FIPS 140-2 Level 3 erforderlich gemäß SC-12)	CloudHSM-benutzerdefinierter Schlüsselspeicher oder AWS CloudHSM direkt
PCI DSS v4.0.1 (die meisten Anforderungen)	AWS KMS mit kundenverwalteten Schlüsseln + CloudTrail-Datenereignissen
PCI DSS-Anforderung 3.7.1 (Schlüsselgenerierung im HSM)	CloudHSM-eigener Schlüsselspeicher oder CloudHSM als BYOK-Quelle
Niedrigster Betriebsaufwand	AWS-KMS
Günstigster Preis für eine kleine Anzahl von Schlüsseln	AWS KMS (1 US-Dollar/Schlüssel/Monat im Vergleich zu ca. 2,100 US-Dollar/Monat für einen CloudHSM-Cluster mit 2 HSMs)

Kostenvergleich

Die Kosten für AWS KMS betragen 1.00 US-Dollar pro kundenverwaltetem Schlüssel und Monat. Für von AWS verwaltete und AWS-eigene Schlüssel fallen keine Speichergebühren an. API-Aufrufe kosten 0.03 US-Dollar pro 10,000 Anfragen (symmetrische Operationen). Bei hohem S3-Aufkommen reduziert der S3 Bucket Key das API-Aufrufvolumen von KMS um bis zu 99 % und senkt so die Kosten pro Operation erheblich. Bei den meisten Workloads liegen die KMS-Kosten im Bereich von einigen zehn Dollar pro Monat, nicht in Hunderten.

Die Kosten für AWS CloudHSM betragen ca. 1.45 US-Dollar pro Stunde und HSM-Instanz (Preisänderungen vorbehalten; aktuelle Preise finden Sie unter aws.amazon.com). Ein einzelnes HSM kostet ca. 1,050 US-Dollar pro Monat. Die minimale Produktionskonfiguration (zwei HSMs in separaten Availability Zones für Hochverfügbarkeit) kostet ca. 2,100 US-Dollar pro Monat. Für CloudHSM-Operationen fallen keine Gebühren pro API-Aufruf an. Größere Cluster für einen höheren kryptografischen Durchsatz kosten zusätzlich ca. 1,050 US-Dollar pro HSM und Monat.

Die Kostendifferenz ist erheblich. Ein einzelner, vom Kunden verwalteter KMS-Schlüssel kostet etwa 12 US-Dollar pro Jahr. Ein CloudHSM-Cluster mit zwei HSMs kostet hingegen etwa 25,200 US-Dollar pro Jahr. CloudHSM ist wirtschaftlich sinnvoll, wenn ein hohes Volumen kryptografischer Operationen hohe KMS-API-Aufrufe verursachen würde, die die Fixkosten von CloudHSM übersteigen, oder wenn Hardwareanforderungen der Stufe 3 oder dedizierte Mandanten den Einsatz von CloudHSM unabhängig von den Kosten betrieblich zwingend erforderlich machen.

Compliance-Mapping

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): AWS KMS mit kundenverwalteten Schlüsseln erfüllt Anforderung 3.5.1 (starke Kryptografie für gespeicherte PANs) und Anforderung 3.7.4 (Schlüsselrotation) mit aktivierter automatischer Rotation. CloudTrail-Datenzugriffsereignisse erfüllen Anforderung 10. Für Anforderung 3.7.1 (Schlüsselgenerierung mit einem HSM) ist ein benutzerdefinierter CloudHSM-Schlüsselspeicher oder CloudHSM als BYOK-Generierungsquelle erforderlich, da Standard-KMS nicht auf Level 3 validiert.

FedRAMP: Standard AWS KMS (FIPS 140-2 Level 2) erfüllt die FedRAMP Moderate SC-12- und SC-28-Anforderungen. FedRAMP High erfordert FIPS 140-2 Level 3-validierte Module für die kryptografische Schlüsselverwaltung; hierfür ist entweder AWS CloudHSM oder ein benutzerdefinierter KMS-Schlüsselspeicher mit CloudHSM-Unterstützung notwendig. Sowohl AWS KMS als auch CloudHSM sind im AWS FedRAMP High-Autorisierungspaket enthalten.

HIPAA: AWS KMS mit kundenverwalteten Schlüsseln erfüllt die technischen Sicherheitsvorkehrungen von HIPAA für die Ver- und Entschlüsselung (45 CFR 164.312(a)(2)(iv)) von ruhenden elektronischen Gesundheitsdaten (ePHI). Die Vereinbarung zur Auftragsverarbeitung (Business Associate Agreement, BAA) von AWS deckt sowohl KMS als auch CloudHSM ab. CloudTrail-Datenzugriffsereignisse erfüllen den Standard für die Auditkontrolle (45 CFR 164.312(b)). Für Organisationen, deren HIPAA-Risikoanalysen dedizierte Hardware oder einen Schlüsselzugriff ohne Cloud-Anbieter erfordern, erfüllt CloudHSM beide Anforderungen.

DORA (Gesetz zur digitalen Betriebsresilienz, gilt für EU-Finanzinstitute seit dem 17. Januar 2025): Artikel 9 und 10 des DORA fordern ein effektives IT-Risikomanagement und operative Resilienz, einschließlich der Resilienz des Schlüsselmanagements. Sowohl KMS (Multi-AZ-Schlüsselreplikation, automatische Rotation) als auch CloudHSM (Multi-AZ-Clusterkonfiguration) erfüllen die Resilienzanforderungen des DORA bei korrekter Konfiguration.

Multi-Cloud-Schlüsselverwaltungsarchitektur

Weder AWS KMS noch AWS CloudHSM lassen sich nativ auf Azure-, GCP- oder On-Premises-Umgebungen erweitern. Organisationen, die mit mehreren Cloud-Anbietern zusammenarbeiten, benötigen eine explizite Strategie für die Verwaltung kryptografischer Schlüssel, die über die Grenzen von AWS hinausgeht.

• Cloud-natives KMS mit zentralisierter Steuerung: Nutzen Sie AWS KMS für AWS-Workloads, Azure Key Vault für Azure und GCP Cloud KMS für GCP. Eine zentrale Plattform für das Schlüssellebenszyklusmanagement aggregiert Inventar, Rotationsstatus und Audit-Logs aller drei Anbieter. Die Daten jeder Cloud werden durch deren natives KMS geschützt, ohne dass Latenzzeiten zwischen den Clouds entstehen. Dies ist das betrieblich effizienteste Modell für Multi-Cloud-Umgebungen.
• CloudHSM als gemeinsam genutzte BYOK-Generierungsquelle: Generieren Sie sämtliche Schlüsselmaterialien aus einem CloudHSM-Cluster, der cloudübergreifend zugänglich ist. Importieren Sie abgeleitete Schlüssel in AWS KMS für AWS-Workloads, Azure Key Vault für Azure-Workloads und GCP Cloud KMS für GCP-Workloads. Die gesamte Verschlüsselung lässt sich auf eine einzige autoritative Hardwarequelle der Stufe 3 zurückführen. (Encryption Consulting) HSM als Service Stellt die externe FIPS 140-2 Level 3 HSM-Infrastruktur für dieses Modell bereit, wenn eine unabhängige (nicht-AWS) HSM-Quelle bevorzugt wird.
• Externes HSM als Service für HYOK über alle Clouds hinweg: Verschlüsseln Sie Daten auf Anwendungs- oder Pipeline-Ebene, bevor sie einen Cloud-Anbieter erreichen, mithilfe von Schlüsseln, die in einem externen HSM-as-a-Service gespeichert sind. Alle Clouds speichern ausschließlich den verschlüsselten Text. Dies gewährleistet maximale Cloud-übergreifende Datensouveränität und schließt alle drei Cloud-Anbieter aus der Schlüsselvertrauenskette aus, allerdings auf Kosten höherer Anwendungskomplexität und erhöhter Anforderungen an die Verfügbarkeit des externen HSM.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein auf angewandte Kryptografie spezialisiertes Unternehmen mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Evaluierung, dem Design und der Implementierung von AWS KMS- und CloudHSM-Architekturen – von der ersten Serviceauswahl bis hin zur kontinuierlichen Erstellung von Compliance-Nachweisen.

• AWS KMS- und CloudHSM-Architekturdesign: Wir analysieren Ihre Compliance-Anforderungen, Ihr Bedrohungsmodell, Ihre Betriebskapazität und Ihre Workload-Charakteristika, um die optimale Kombination aus KMS, CloudHSM und benutzerdefiniertem Schlüsselspeicher zu empfehlen. Wir entwerfen die Schlüsselhierarchie, das IAM-Schlüsselrichtlinienmodell, den Rotationsplan und das Audit-Log-Routing für jeden Dienst. Weitere Informationen finden Sie hier. Cloud-Beratungsdienste.
• HSM als Dienstleistung: Für BYOK-Implementierungen, die eine FIPS 140-2 Level 3-Schlüsselgenerierung außerhalb von AWS erfordern, oder für HYOK-Architekturen, die ein externes Schlüsselverwaltungssystem benötigen, bietet Encryption Consulting die passende Lösung. HSM als Service Bietet eine dedizierte HSM-Infrastruktur, die gleichzeitig über AWS, Azure und GCP zugänglich ist. Dient als CloudHSM-Alternative für Organisationen, die Hardware der Stufe 3 benötigen, ohne die operative Komplexität der Verwaltung eines CloudHSM-Clusters in Kauf nehmen zu müssen.
• CBOM Secure für AWS Cryptographic Discovery: AWS-Umgebungen weisen häufig inkonsistente KMS-Konfigurationen auf: eine Mischung aus AWS-eigenen, AWS-verwalteten und kundenseitig verwalteten Schlüsseln mit unterschiedlichen Richtlinien und Rotationsplänen. Encryption Consulting CBOM Secure Erkennt und inventarisiert alle KMS-Schlüsselkonfigurationen, CloudHSM-Cluster und Schlüsselzugriffsrichtlinien über AWS-Konten hinweg und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die Compliance-Lücken aufzeigt und die Dokumentation der PCI DSS v4.0.1 Anforderung 12.3.3 unterstützt.
• PCI DSS- und FedRAMP-Konformitätshinweis: Wir ordnen Ihre AWS KMS- und CloudHSM-Konfiguration den spezifischen Anforderungen von PCI DSS v4.0.1, FedRAMP High, HIPAA, DORA und NIST SP 800-53 Rev. 5 zu. Wir identifizieren Kontrolllücken, erstellen die erforderlichen Nachweise zur Konformität und unterstützen Sie bei Anfragen von QSA und Gutachtern. Weitere Informationen finden Sie hier. Compliance-Beratungsdienste.
• PQC-Bereitschaft: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). Laut NIST IR 8547 sollten RSA und ECC für neue Anwendungsfälle um das Jahr 2030 als veraltet gelten. Sowohl KMS- als auch CloudHSM-RSA/ECC-asymmetrische Schlüssel müssen migriert werden. (Encryption Consulting) PQC-Bereitschaft Der Service ordnet Ihren AWS-Schlüsselbestand dem Zeitplan der Post-Quantum-Migration zu.

Um Ihre AWS KMS- und CloudHSM-Architektur oder Ihre Compliance-Anforderungen zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

AWS KMS und AWS CloudHSM erfüllen unterschiedliche Rollen im AWS-Stack für kryptografisches Schlüsselmanagement. KMS ist die optimale Standardlösung für die meisten AWS-Verschlüsselungs-Workloads: Es ist vollständig verwaltet, integriert sich nativ in alle wichtigen AWS-Services, bietet automatische Schlüsselrotation, liefert ein CloudTrail-Audit-Protokoll pro Operation und erfüllt die meisten regulatorischen Anforderungen gemäß FIPS 140-2 Level 2. CloudHSM ist die richtige Wahl, wenn eine strikte Anforderung dedizierte Hardware gemäß FIPS 140-2 Level 3 vorschreibt, AWS vollständig von der Schlüsselvertrauenskette ausgeschlossen werden muss oder eine Anwendung direkten PKCS#11/JCE/CNG/OpenSSL-Zugriff auf ein HSM benötigt.

Die benutzerdefinierte Schlüsselspeicherarchitektur verbindet beide Dienste: Hardware-Schutz der Stufe 3 für Schlüssel, die über die vollständige KMS-API und alle nativen AWS-Serviceintegrationen verwendet werden. Für die meisten Organisationen, die zukünftig CloudHSM-Funktionen benötigen, ist der benutzerdefinierte Schlüsselspeicher die Architektur, die beides bietet, ohne dass eine Migration von KMS erforderlich ist.

Eine detailliertere Betrachtung der Sicherheitsbewertung und der Vertrauensgrenzen von AWS KMS finden Sie in unserem Leitfaden „ Wie sicher sind die Key Management Services von Amazon (AWS KMS)?“. Informationen zu den Betriebsmechanismen von KMS, einschließlich Workflows zur Schlüsselerstellung, Envelope-Verschlüsselung und Datenschlüsselmustern, finden Sie in unserem AWS KMS Deep Dive.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen AWS KMS und AWS CloudHSM?

AWS KMS ist ein vollständig verwalteter, mandantenfähiger Schlüsselverwaltungsdienst mit FIPS 140-2 Level 2-validierten HSMs. AWS verwaltet die Hardware. Sie steuern die Schlüsselrichtlinien und die Schlüsselrotation. AWS CloudHSM bietet dedizierte, physische HSM-Hardware für Einzelnutzer, die gemäß FIPS 140-2 Level 3 in Ihrer VPC validiert ist. AWS verwaltet die physische Hardware, hat aber keinen Zugriff auf Ihre Schlüssel oder HSM-Partitionen. Sie verwalten HSM-Benutzer, Schlüsselmaterial und Authentifizierung separat von AWS IAM.

Wann sollte ich AWS KMS anstelle von CloudHSM verwenden?

Nutzen Sie AWS KMS, wenn Sie eine native Integration mit S3, EBS, RDS, Lambda oder anderen AWS-Services benötigen, eine automatische Schlüsselrotation und CloudTrail-Auditprotokollierung pro Operation wünschen und FIPS 140-2 Level 2 Multi-Tenant-Hardware akzeptabel ist. KMS deckt die meisten regulierten Workloads ab, darunter HIPAA, PCI DSS (mit kundenverwalteten Schlüsseln und Datenereignisprotokollierung) und FedRAMP Moderate. Beginnen Sie mit KMS, es sei denn, eine spezielle Anforderung zwingt Sie zu CloudHSM.

Wann sollte ich AWS CloudHSM anstelle von KMS verwenden?

Verwenden Sie CloudHSM, wenn dedizierte Single-Tenant-Hardware gemäß FIPS 140-2 Level 3 (FedRAMP High, eIDAS) erforderlich ist, wenn AWS vollständig von der Schlüsselvertrauenskette ausgeschlossen werden muss oder wenn eine Anwendung direkten PKCS#11-, JCE-, CNG- oder OpenSSL-API-Zugriff auf das HSM benötigt (z. B. CA-Privatschlüsselschutz, TLS-Offloading, Zahlungs-PIN-Operationen, Datenbank-TDE). CloudHSM verursacht einen erheblichen Betriebsaufwand und kostet für eine minimale HA-Konfiguration ca. 2,100 US-Dollar pro Monat.

Was ist BYOK in AWS KMS und wie unterscheidet es sich von CloudHSM BYOK?

BYOK in KMS bedeutet, dass Sie Schlüsselmaterial extern generieren, es verpacken und in einen KMS-Schlüssel importieren (Ursprung: EXTERN). AWS verwendet Ihr importiertes Material; das Original bleibt außerhalb von AWS erhalten; durch das Löschen des Imports verliert AWS sofort die Berechtigung, es zu verwenden. AWS hat weiterhin Zugriff auf den Schlüssel, solange er sich in KMS befindet, und eine automatische Rotation ist nicht verfügbar. CloudHSM BYOK bedeutet, dass der Schlüssel in Ihrem CloudHSM-Cluster verbleibt; AWS greift niemals darauf zu. CloudHSM kann auch als Quelle für die Generierung von Schlüsseln der Stufe 3 dienen, die in KMS importiert werden.

Können AWS KMS und CloudHSM zusammen verwendet werden?

Ja, über die Funktion „Benutzerdefinierter KMS-Schlüsselspeicher“. Ein benutzerdefinierter Schlüsselspeicher verbindet Ihren CloudHSM-Cluster mit KMS. Die im benutzerdefinierten Schlüsselspeicher erstellten KMS-Schlüssel werden in Ihrem CloudHSM-Cluster generiert und gespeichert (FIPS 140-2 Level 3), während alle über 100 nativen AWS-Serviceintegrationen weiterhin über die normale KMS-API funktionieren. Dadurch erhalten Sie gleichzeitig Hardware-Schutz der Stufe 3 und native AWS-Serviceintegration. Der Nachteil: Die Verfügbarkeit Ihres CloudHSM-Clusters wirkt sich direkt auf die Verfügbarkeit der KMS-Schlüssel aus.

Was kosten AWS KMS und CloudHSM?

AWS KMS: 1.00 $ pro kundenverwaltetem Schlüssel und Monat, zuzüglich 0.03 $ pro 10,000 API-Aufrufe. Für von AWS verwaltete und AWS-eigene Schlüssel fallen keine Speichergebühren an. AWS CloudHSM: ca. 1.45 $ pro Stunde und HSM (ca. 1,050 $ pro Monat und HSM). Eine minimale HA-Produktionskonfiguration (2 HSMs) kostet ca. 2,100 $ pro Monat bzw. 25,200 $ pro Jahr. Für CloudHSM-Operationen fallen keine Gebühren pro API-Aufruf an. Ein einzelner KMS-Schlüssel kostet ca. 12 $ pro Jahr; ein CloudHSM-Cluster mit 2 HSMs kostet ca. 25,200 $ pro Jahr.