Wie sicher sind die Schlüsselverwaltungsdienste von Amazon (AWS KMS)?

AWS Key Management Service (AWS KMS) bildet das Rückgrat der kryptografischen Schlüsselverwaltung für über 100 AWS-Services und ist der weltweit am häufigsten eingesetzte Cloud-KMS. Die Sicherheit jedes verschlüsselten S3-Objekts, EBS-Volumes, jeder RDS-Datenbank und jedes Lambda-Secrets hängt von der Konfiguration der KMS-Schlüssel und deren Kontrolle ab. Für jede Arbeitslast empfehlen wir folgende Vorgehensweise: Prüfen Sie, ob Ihr Compliance-Framework die FIPS-Validierungsstufe erfüllt, stellen Sie sicher, dass kundenseitig verwaltete Schlüssel (und nicht von AWS verwaltete oder AWS-eigene) verwendet werden, aktivieren Sie die CloudTrail-Datenzugriffsprotokolle und entscheiden Sie, ob das standardmäßige Multi-Tenant-KMS-Modell oder ein dedizierter CloudHSM-Cluster Ihrem Bedrohungsmodell entspricht.

Kurzantwort: Wie sicher ist AWS KMS?

AWS KMS bietet für die überwiegende Mehrheit der Unternehmens- und regulierten Workloads kryptografisch hohe Sicherheit. Das Schlüsselmaterial wird in FIPS 140-2 Level 2-validierten HSMs generiert und gespeichert und verlässt die HSM-Grenze niemals im Klartext. Die Schlüssel sind regionsgebunden und können nicht exportiert oder außerhalb der AWS-Region verwendet werden, in der sie erstellt wurden. Jeder kryptografische Vorgang wird in CloudTrail mit der anfragenden Identität, dem Schlüssel-ARN, dem Zeitstempel und der Quell-IP protokolliert. Die wichtigste Sicherheitsmaßnahme besteht darin, dass AWS KMS standardmäßig ein mandantenfähiger Managed Service ist, d. h. AWS betreibt die zugrunde liegende HSM-Hardware. Für Workloads, die keinen operativen Zugriff von AWS auf das Schlüsselmaterial benötigen, sollten BYOK (importiertes Schlüsselmaterial) oder HYOK (clientseitige Verschlüsselung) in Betracht gezogen werden. Für Workloads, die dedizierte Single-Tenant-Hardware gemäß FIPS 140-2 Level 3 erfordern, ist AWS CloudHSM erforderlich.

Wichtige Erkenntnisse

• Standardmäßig verwendet AWS KMS nach FIPS 140-2 Level 2 validierte HSMs: Schlüsselmaterial wird in Multi-Tenant-HSMs generiert und verwendet, die nach FIPS 140-2 Level 2 validiert sind. CloudHSM stellt bei Bedarf Single-Tenant-Hardware der Stufe 3 bereit.
• AWS kann Ihre kundenverwalteten Schlüssel nicht ohne einen authentifizierten API-Aufruf verwenden: Kundenseitig verwaltete KMS-Schlüssel können nur dann für kryptografische Operationen verwendet werden, wenn eine authentifizierte Anfrage sowohl die Schlüsselrichtlinien- als auch die IAM-Richtlinienprüfungen besteht. AWS kann die Schlüsselverwendung nicht in Ihrem Namen initiieren.
• Kundenseitig verwaltete Schlüssel sind der einzige Typ, der eine protokollierte Nachverfolgung jedes einzelnen Vorgangs ermöglicht: Nur vom Kunden verwaltete Schlüssel generieren CloudTrail-Ereignisse für jeden GenerateDataKey- und Decrypt-Aufruf, der mit einer bestimmten IAM-Identität verknüpft ist. Von AWS verwaltete und AWS-eigene Schlüssel bieten diese Granularität nicht.
• BYOK bietet Ihnen die Möglichkeit der Herkunftsnachverfolgung und des sofortigen Widerrufs; HYOK schließt AWS vollständig aus: BYOK (importiertes Schlüsselmaterial) erfüllt die Anforderungen an kundengeneriertes Schlüsselmaterial. HYOK (clientseitige Verschlüsselung vor dem Upload) bedeutet, dass der Schlüssel niemals in AWS gelangt. Es ist das Modell mit der höchsten Souveränität, weist aber auch die größte operative Komplexität auf.
• Der S3 Bucket Key reduziert die KMS-API-Kosten für S3-Workloads um bis zu 99 %: Durch die Aktivierung des S3 Bucket Keys generiert S3 objektbezogene DEKs lokal, anstatt für jeden Lese- und Schreibvorgang eines Objekts den KMS aufzurufen. Dadurch werden das Volumen und die Kosten der KMS-API-Aufrufe drastisch reduziert, ohne dass sich die Sicherheitseigenschaften ändern.

Was ist der AWS Key Management Service (KMS)?

AWS Key Management Service (AWS KMS) ist ein verwalteter Dienst, der kryptografische Schlüssel erstellt und verwaltet , die zum Schutz von Daten in AWS-Services und -Anwendungen verwendet werden. AWS KMS bildet das Rückgrat des Schlüsselmanagements in der AWS-Cloud: Wenn Sie die Verschlüsselung für einen S3-Bucket, ein EBS-Volume, eine RDS-Datenbank oder ein Secrets Manager-Geheimnis aktivieren, generiert, speichert und schützt AWS KMS die Schlüssel, die diese Verschlüsselung ermöglichen.

AWS KMS speichert alle Schlüsseldaten in Hardware-Sicherheitsmodulen (HSMs), die gemäß FIPS 140-2 Level 2 validiert sind. Die in AWS KMS generierten Schlüsseldaten verlassen unter keinen Umständen die HSM-Grenzen im Klartext. AWS KMS ist nativ in über 100 AWS-Services integriert, darunter Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, AWS Secrets Manager, Amazon Redshift und Amazon EFS. Die Speicherung der Schlüssel in mehreren Verfügbarkeitszonen gewährleistet hohe Verfügbarkeit. Der KMS-Service selbst bietet eine Datenbeständigkeit von ca. 99.999 % für die Schlüsseldaten.

AWS KMS-Sicherheitsarchitektur: Was macht sie sicher?

Um zu verstehen, wie sicher AWS KMS ist, muss man die Vertrauensgrenzen verstehen, innerhalb derer es operiert, und die Invarianten, die es durchsetzt.

Hardwaregrenze des HSM: Sämtliches KMS-Schlüsselmaterial wird innerhalb von FIPS 140-2 Level 2-validierten HSMs generiert und verwendet. Die HSMs sind so konzipiert, dass das Schlüsselmaterial von keiner Partei, einschließlich AWS-Mitarbeitern, im Klartext extrahiert werden kann. Schlüsseloperationen (GenerateDataKey, Encrypt, Decrypt, Sign, Verify) werden innerhalb der HSM-Grenze ausgeführt, und nur das Ergebnis wird an den Aufrufer zurückgegeben. Das Schlüsselmaterial im Klartext verlässt niemals das HSM.

Regionsisolation: In einer AWS-KMS-Region erstellte Schlüssel können nicht von einer anderen Region aus verwendet oder abgerufen werden. Ein in us-east-1 erstellter Schlüssel kann beispielsweise nicht zum Entschlüsseln von Daten in eu-west-1 verwendet werden. Diese Regionsisolation ist eine systemweite Invariante, die auf Hardware- und Softwareebene durchgesetzt wird und nicht nur eine Richtlinie darstellt.

Schlüsselrichtlinie als obligatorische Zugriffskontrolle: Jeder vom Kunden verwaltete KMS-Schlüssel verfügt über eine Schlüsselrichtlinie, die den primären und obligatorischen Zugriffskontrollmechanismus darstellt. Wenn die Schlüsselrichtlinie einem Prinzipal nicht explizit die Berechtigung zur Verwendung des Schlüssels erteilt, kann dieser Prinzipal ihn unabhängig von der IAM-Identitätsrichtlinie nicht verwenden. Dies bedeutet, dass selbst ein AWS-Konto-Root-Benutzer einen vom Kunden verwalteten Schlüssel nicht für kryptografische Operationen verwenden kann, es sei denn, die Schlüsselrichtlinie erlaubt dies ausdrücklich.

Was AWS kann und was nicht: AWS betreibt die HSM-Hardware und verwaltet die KMS-Serviceinfrastruktur. AWS kann Ihren kundenverwalteten Schlüssel nicht in Ihrem Namen aufrufen, um kryptografische Operationen durchzuführen. Dazu ist eine authentifizierte API-Anfrage erforderlich, die sowohl die Schlüsselrichtlinie als auch die IAM-Richtlinienprüfung besteht. AWS hat keinen Einblick in den Klartext kundenverwalteter Schlüssel. Als Betreiber der zugrunde liegenden HSM-Hardware ist AWS jedoch für die physische Sicherheit des Schlüsselmaterials verantwortlich. Dies ist der grundlegende Unterschied zwischen Standard-AWS-KMS- und BYOK/HYOK-Architekturen.

AWS KMS-Schlüsseltypen: Kundenseitig verwaltet, AWS-verwaltet und AWS-eigene Schlüssel

AWS KMS unterteilt Schlüssel in drei Typen mit grundlegend unterschiedlichen Sicherheits-, Kontroll- und Compliance-Eigenschaften. AWS benannte die „Customer Master Keys (CMKs)“ im Jahr 2021 in „KMS-Schlüssel“ um, die drei zugrunde liegenden Typen blieben jedoch unverändert.

Kundenseitig verwaltete KMS-Schlüssel werden von Ihnen in Ihrem AWS-Konto erstellt. Sie definieren die Schlüsselrichtlinie, legen fest, wer den Schlüssel verwenden und verwalten darf, konfigurieren die automatische Rotation und können den Schlüssel deaktivieren oder dessen Löschung planen. Jeder Aufruf von `GenerateDataKey` und `Decrypt` erzeugt ein CloudTrail-Ereignis mit dem Schlüssel-ARN und fordert die IAM-Identität, die Quell-IP-Adresse und den Zeitstempel an. Dieses protokollierte Vorgehen ist die Compliance-Funktion, die kundenseitig verwaltete Schlüssel bieten und andere Schlüsseltypen nicht. Kundenseitig verwaltete Schlüssel kosten 1 US-Dollar pro Schlüssel und Monat zuzüglich 0.03 US-Dollar pro 10,000 API-Aufrufe.

AWS-verwaltete KMS-Schlüssel Sie werden von AWS-Diensten automatisch erstellt, sobald Sie die Verschlüsselung zum ersten Mal aktivieren, ohne einen vom Kunden verwalteten Schlüssel anzugeben. Sie folgen dem Aliasmuster. aws/service-name (zum Beispiel, aws/s3, aws/ebsSie können zwar die Metadaten einsehen, aber weder die Schlüsselrichtlinie ändern, die Schlüssel deaktivieren, die Löschung planen noch die Rotation steuern. AWS rotiert sie automatisch alle drei Jahre. Sie generieren nur wenige CloudTrail-Audit-Einträge und bieten nicht den pro Vorgang verknüpften, identitätsbezogenen Audit-Trail, den Compliance-Frameworks erfordern.

AWS-eigene KMS-Schlüssel werden vollständig von AWS verwaltet und von mehreren Kundenkonten gemeinsam genutzt. Sie sind in Ihrem AWS-Konto nicht sichtbar, generieren keine CloudTrail-Ereignisse und Sie haben keinerlei Kontrolle darüber. Sie eignen sich für unkritische Daten, bei denen minimaler Verwaltungsaufwand Priorität hat, sind jedoch für regulierte Workloads ungeeignet.

Hüllverschlüsselung: Wie AWS KMS Daten schützt

AWS KMS verwendet Envelope-Verschlüsselung, um große Datenmengen effizient zu schützen. AWS KMS verschlüsselt Ihre Daten nicht direkt. KMS-Schlüssel können Daten bis zu einer Größe von 4 KB direkt verschlüsseln. Stattdessen nutzt AWS KMS das Envelope-Verschlüsselungsmuster: Ein KMS-Schlüssel (der Schlüsselverschlüsselungsschlüssel, KEK) verschlüsselt einen Datenverschlüsselungsschlüssel (DEK), und der DEK verschlüsselt die eigentlichen Daten.

Schutz des Verschlüsselungsschlüssels: Der DEK wird mit dem KMS-Schlüssel (CMK) verschlüsselt, sodass der verschlüsselte DEK sicher zusammen mit den verschlüsselten Daten gespeichert werden kann. Beide können nicht ohne den jeweils anderen verwendet werden, und der zum Entschlüsseln des DEK benötigte KMS-Schlüssel ist in den KMS-HSMs geschützt.

Effizienz im großen Maßstab: Anstatt KMS für jede einzelne Datenoperation aufzurufen, ruft die Anwendung KMS nur einmal auf, um einen DEK zu generieren und zu verschlüsseln. Anschließend verwendet sie den Klartext-DEK lokal, um potenziell Gigabytes an Daten zu verschlüsseln, und verwirft den Klartext-DEK danach. Nur der verschlüsselte DEK muss zusammen mit den Daten gespeichert werden. Dies reduziert die KMS-API-Aufrufe im Vergleich zur direkten KMS-Verschlüsselung jedes einzelnen Datensatzes drastisch.

Algorithmische Stärke: Die Hüllkurvenverschlüsselung ermöglicht die Kombination symmetrischer und asymmetrischer Algorithmen. Der DEK für die Datenverschlüsselung ist typischerweise AES-256 (schnell und sicher für große Datenmengen). Der KEK im KMS kann für bestimmte Anwendungsfälle ein asymmetrischer RSA- oder ECC-Schlüssel oder für die meisten Anwendungsfälle der Datenverschlüsselung ein symmetrischer AES-256-Schlüssel sein.

Datenschlüssel und Datenschlüsselpaare

Datenschlüssel sind die Verschlüsselungsschlüssel, die zum Verschlüsseln von Daten und anderen Daten verwendet werden. AWS KMS generiert Datenschlüssel, speichert, verwaltet oder verfolgt diese jedoch nicht. Die Verwendung und Verwaltung der Datenschlüssel erfolgt außerhalb von AWS KMS durch die Anwendung oder den AWS-Service.

Erstellen eines Datenschlüssels: Telefon GenerateDataKey Hierbei wird der zu verwendende KMS-Schlüssel als KEK angegeben. KMS liefert zwei Kopien: einen Klartext-Datenschlüssel zur sofortigen Verwendung und einen verschlüsselten Datenschlüssel (umhüllt vom angegebenen KMS-Schlüssel). Der verschlüsselte Datenschlüssel wird gespeichert. Die Anwendung verschlüsselt Daten mit dem Klartext-Schlüssel und löscht diesen anschließend aus dem Speicher.

Datenverschlüsselung mit einem Datenschlüssel: Verwenden Sie den Klartext-Datenschlüssel, um Daten außerhalb von AWS KMS zu verschlüsseln, und löschen Sie anschließend den Klartext-Schlüssel aus dem Speicher. Speichern Sie den verschlüsselten Datenschlüssel zusammen mit dem Chiffretext.

Entschlüsseln von Daten mit einem Datenschlüssel: Ruf den Decrypt Die Operation entschlüsselt den verschlüsselten Datenschlüssel und gibt den Klartextdatenschlüssel zurück. Verwenden Sie den Klartextdatenschlüssel, um die Daten zu entschlüsseln, und entfernen Sie sie anschließend sofort aus dem Speicher.

Datenschlüsselpaare sind asymmetrische Schlüsselpaare (RSA oder ECC), die von AWS KMS für die clientseitige Verschlüsselung, Signierung und Verifizierung außerhalb von AWS KMS generiert werden. Der private Schlüssel jedes Datenschlüsselpaares ist durch einen symmetrischen KMS-Schlüssel geschützt. Unterstützte Spezifikationen für asymmetrische Schlüsselpaare umfassen RSA mit 2048, 3072 und 4096 Bit für die Ver- und Entschlüsselung sowie ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521 und ECC_SECG_P256K1 für die Signierung und Verifizierung.

Verschlüsselung mit einem Datenschlüsselpaar: Der öffentliche Schlüssel verschlüsselt die Daten; der private Schlüssel (entschlüsselt aus der verschlüsselten Form durch KMS) entschlüsselt sie.

Signieren und Verifizieren mit einem Datenschlüsselpaar: Der Klartext-Privatschlüssel (wiedererhalten durch Aufruf von Decrypt auf dem verschlüsselten Privatschlüssel) signiert eine Nachricht. Jeder, der den zugehörigen öffentlichen Schlüssel besitzt, kann die Signatur überprüfen. Der Klartext-Privatschlüssel muss nach Gebrauch aus dem Speicher entfernt werden.

Die folgende Tabelle fasst die kryptografischen Operationen von AWS KMS nach Schlüsseltyp und Schlüsselverwendung zusammen:

Produktion	KMS-Schlüsseltyp	Schlüsselverwendung
Entschlüsseln	Symmetrisch / Asymmetrisch	ENCRYPT_DECRYPT
Encrypt	Symmetrisch / Asymmetrisch	ENCRYPT_DECRYPT
GenerateDataKey	Symmetrisch	ENCRYPT_DECRYPT
GenerateDataKeyWithoutPlaintext	Symmetrisch	ENCRYPT_DECRYPT
GenerateDataKeyPair	Symmetrisch (schützt asymmetrisches Paar)	ENCRYPT_DECRYPT
GenerateDataKeyPairWithoutPlaintext	Symmetrisch (schützt asymmetrisches Paar)	ENCRYPT_DECRYPT
Neu verschlüsseln	Symmetrisch / Asymmetrisch	ENCRYPT_DECRYPT
Schild	Asymmetrisch	SIGN_VERIFY
Verify	Asymmetrisch	SIGN_VERIFY
GenerateMac	HMAC	GENERATE_VERIFY_MAC
VerifyMac	HMAC	GENERATE_VERIFY_MAC

IAM-Modell: Zugriffskontrolle für Schlüsselrichtlinien und Identitätsrichtlinien

Die Zugriffskontrolle von AWS KMS ist der am häufigsten falsch konfigurierte Aspekt von KMS-Bereitstellungen. Fehlkonfigurationen stellen gleichzeitig das häufigste Sicherheitsrisiko für AWS KMS dar: Die HSM-Grenze schützt zwar vor Schlüsselextraktion, aber eine zu permissive Schlüsselrichtlinie oder IAM-Richtlinie kann nicht autorisierten Benutzern die Möglichkeit geben, den Schlüssel für kryptografische Operationen zu verwenden.

Schlüsselrichtlinie (obligatorische ressourcenbasierte Richtlinie): Jeder vom Kunden verwaltete KMS-Schlüssel verfügt über eine Schlüsselrichtlinie. Diese ist der primäre und obligatorische Zugriffskontrollmechanismus. Im Gegensatz zu den meisten AWS-Ressourcenrichtlinien muss die KMS-Schlüsselrichtlinie vorhanden sein und Berechtigungen explizit erteilen. Ohne Schlüsselrichtlinie besteht kein Zugriff. Enthält die Schlüsselrichtlinie die Anweisung, die dem Root-Konto Berechtigungen zur Schlüsselverwaltung gewährt (die standardmäßig in der Konsole erstellte Schlüsselrichtlinie), können IAM-Identitätsrichtlinien in diesem Konto auch Prinzipalen Berechtigungen zur Schlüsselverwaltung erteilen. Ohne diese Root-Delegierungsanweisung können IAM-Richtlinien unabhängig von ihrem Inhalt keinen Zugriff auf den Schlüssel gewähren.

IAM-Identitätsrichtlinie (sekundäre Ebene): Eine einem Benutzer, einer Rolle oder einer Gruppe zugeordnete IAM-Richtlinie kann KMS-Berechtigungen erteilen, jedoch nur, wenn die Schlüsselrichtlinie dies ebenfalls für den Benutzer zulässt. Bei Datenoperationen (Verschlüsseln, Entschlüsseln, Generieren eines Datenschlüssels, Signieren) gilt das Prinzip der minimalen Berechtigungen sowohl in der Schlüsselrichtlinie als auch in der IAM-Identitätsrichtlinie: Erteilen Sie nur die Berechtigungen für die jeweilige Operation, nur für den jeweiligen Schlüssel-ARN und nur dem jeweiligen Dienstkonto, das diese benötigt.

Trennung von Schlüsseladministrator und Schlüsselbenutzer: Das wichtigste IAM-Sicherheitsprinzip für KMS ist die Trennung der Rolle des Schlüsseladministrators (der Schlüsselrichtlinien verwalten, rotieren, deaktivieren und löschen kann) von der Rolle des Schlüsselbenutzers (der die Funktionen „Verschlüsseln“, „Entschlüsseln“ und „Datenschlüssel generieren“ aufrufen kann). Anwendungsdienstkonten sollten nur die für bestimmte Schlüssel erforderlichen kryptografischen Berechtigungen besitzen, niemals Berechtigungen zur Schlüsselverwaltung. Eine Sicherheitsfunktion verwaltet die Schlüssel; Anwendungsdienstkonten verwenden sie.

Service Control Policies (SCPs): Befinden sich Ihre AWS-Konten in einer AWS-Organisation, bieten SCPs eine zusätzliche Sicherheitsebene über IAM. Mit SCPs können Sie beispielsweise das Löschen von KMS-Produktionsschlüsseln verhindern, bestimmte Verschlüsselungsstandards für verschiedene Services festlegen oder die Deaktivierung der KMS-bezogenen CloudTrail-Protokollierung unterbinden. SCPs können keine Berechtigungen erteilen. Sie beschränken lediglich die maximal verfügbaren Berechtigungen für jeden Principal im Konto.

Berechtigungen: Berechtigungen sind temporäre, programmatische Berechtigungen, die erstellt, verwendet und gelöscht werden können, ohne die Schlüsselrichtlinie oder die IAM-Richtlinie zu ändern. Sie sind nützlich, um AWS-Services (wie AWS Lambda oder Amazon S3) die Berechtigung zu erteilen, einen KMS-Schlüssel in Ihrem Namen für einen bestimmten Vorgang oder ein bestimmtes Zeitfenster zu verwenden, ohne die dauerhafte Schlüsselrichtlinie zu ändern. Berechtigungen werden zusammen mit Schlüsselrichtlinien und IAM-Richtlinien in die Zugriffskontrollbewertung einbezogen.

BYOK und HYOK: Wenn natives KMS nicht ausreicht

Das Standard-AWS-KMS-Modell (AWS generiert und verwaltet Schlüsselmaterial in mandantenfähigen HSMs) eignet sich für die meisten regulierten Workloads. Für Organisationen, die stärkere Garantien für die Schlüsselhoheit benötigen, stehen zwei Modelle zur Verfügung.

BYOK (Bring Your Own Key): Sie generieren AES-256-Schlüsselmaterial in Ihrem eigenen HSM oder Schlüsselverwaltungssystem, verschlüsseln es mit einem Schlüssel, der von einem AWS KMS-Importauftrag heruntergeladen wurde, und importieren es in einen KMS-Schlüssel mit der Herkunftsbezeichnung „EXTERNAL“. AWS KMS verwendet Ihr importiertes Schlüsselmaterial für alle kryptografischen Operationen. Sie behalten das Originalschlüsselmaterial in Ihrem eigenen HSM. Durch das Löschen der importierten Kopie aus KMS wird AWS die Berechtigung zur Verwendung des Schlüssels sofort und endgültig entzogen. BYOK bietet Ihnen die Möglichkeit der Schlüsselherkunftssicherung (Sie können nachweisen, dass der Schlüssel in einem von Ihnen kontrollierten, FIPS-validierten HSM generiert wurde) und den sofortigen, unabhängigen Widerruf. AWS hat während der Verwendung weiterhin Zugriff auf das Schlüsselmaterial, und eine automatische Rotation ist für importierte Schlüssel nicht verfügbar.

HYOK (Hold Your Own Key): Der Verschlüsselungsschlüssel gelangt niemals in AWS. Ihre Anwendung verschlüsselt Daten, bevor sie diese in einen AWS-Service hochlädt. AWS speichert ausschließlich den Chiffretext und kann Ihre Daten unter keinen Umständen entschlüsseln, auch nicht im Falle einer rechtlichen Aufforderung an AWS. Dies ist das einzige Modell, das AWS vollständig von der Schlüsselvertrauenskette ausschließt. Jeder Lese- und Schreibvorgang erfordert einen Aufruf Ihres externen Schlüsselverwaltungssystems, das hochverfügbar sein muss. Encryption Consulting bietet mit HSM as a Service die externe FIPS 140-2 Level 3-konforme Schlüsselverwaltungsinfrastruktur für HYOK-Implementierungen auf AWS.

Abmessungen	Natives KMS (AWS-generiert)	BYOK (Importiertes Schlüsselmaterial)	HYOK (Clientseitig, Schlüssel außerhalb von AWS)
Schlüssel generiert von	AWS KMS HSM	Kunden-HSM (in KMS importiert)	Kunde (tritt nie auf AWS zu)
AWS-Zugriff auf den Schlüssel während der Nutzung	Ja (HSM-Grenze für mehrere Mandanten)	Ja (operativer Zugriff)	Nein
CloudTrail-Auditprotokoll	Ja (pro Vorgang)	Ja (pro Vorgang)	Nein (nur externe KMS-Protokolle)
Unabhängiger Widerruf	Schlüssel über die API deaktivieren/löschen	Importiertes Material löschen (sofort)	Widerruf bei externem KMS
Automatische Schlüsseldrehung	Ja (90 Tage bis 7 Jahre)	Nein (manueller Reimport erforderlich)	Vollständig vom Kunden verwaltet
Wichtigster Herkunftsnachweis	AWS bestätigt die Generation in FIPS HSM	Der Kunde kann seine eigene HSM-Generation nachweisen.	Vollständig vom Kunden kontrolliert
FIPS-Niveau	Stufe 2 (Standard) / Stufe 3 (CloudHSM)	Stufe 2 oder 3 (abhängig vom Zielgeschäft)	Abhängig von externem KMS
Operative Komplexität	Niedrig	Medium	Hoch
Am besten geeignet,	Die meisten regulierten Arbeitsbelastungen	Arbeitslasten, die die Herkunft von Kundenschlüsseln erfordern	Geheim, durch staatliche Vorgaben vorgeschrieben, Zero-Trust

CloudTrail-Auditprotokollierung: Der Compliance-Audit-Trail

Die AWS KMS-Integration mit CloudTrail ist eine der stärksten Sicherheitsfunktionen für regulierte Workloads. Jeder AWS KMS-API-Aufruf generiert ein CloudTrail-Ereignis, das den ARN des Schlüssels, die Operation, die anfragende IAM-Identität, die Quell-IP-Adresse, die AWS-Region und den Zeitstempel protokolliert. Dieser operationsspezifische Prüfpfad ermöglicht es Ihnen, einem PCI DSS QSA- oder HIPAA-Auditor genau nachzuweisen, wer wann auf welche Daten zugegriffen hat.

CloudTrail-Verwaltungsereignisse (Schlüsselerstellung, Schlüsselrichtlinienänderungen, Schlüsselrotation, ScheduleKeyDeletion, DisableKey) sind standardmäßig aktiviert und können nicht deaktiviert werden. CloudTrail-Datenereignisse (GenerateDataKey- und Decrypt-Aufrufe pro Objekt und Vorgang) müssen separat aktiviert werden, da sie ein hohes Datenvolumen und damit verbundene Kosten verursachen können. Für regulierte Workloads ist die Aktivierung von KMS-Datenereignissen in CloudTrail obligatorisch: Hierbei handelt es sich um das Protokoll, das jeden Entschlüsselungsvorgang für bestimmte Daten aufzeichnet, der mit der anfragenden Identität verknüpft ist.

Wichtige Sicherheitswarnungen, die über CloudTrail KMS-Ereignisse konfiguriert werden können: Sofortige Benachrichtigung bei ScheduleKeyDeletion und DisableKey für jeden Produktionsschlüssel; Benachrichtigung bei Decrypt-Aufrufen von IAM-Prinzipalen, die nicht in der Liste der für diesen Schlüssel zugelassenen Rollen enthalten sind; Benachrichtigung bei einer hohen Anzahl von Decrypt-Ereignissen, die auf Datenexfiltration hindeuten könnten; und Benachrichtigung bei Änderungen der PutKeyPolicy für jeden Produktionsschlüssel, die den Zugriff erweitern könnten.

Schlüsselrotation in AWS KMS

Die automatische Schlüsselrotation in AWS KMS generiert in einem konfigurierbaren Zeitplan neues kryptografisches Material für einen vom Kunden verwalteten Schlüssel. Das neue Schlüsselmaterial wird zur primären Version für alle neuen Verschlüsselungsvorgänge. Vorherige Schlüsselversionen 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 erfolgt vollständig transparent für Anwendungen. Vorhandene Daten müssen nicht neu verschlüsselt werden.

Die Rotationsperiode ist zwischen 90 Tagen und 7 Jahren konfigurierbar. Für die meisten Compliance-Workloads ist ein Zeitraum von 90 Tagen bis 1 Jahr üblich. PCI DSS-Anforderung 3.7.4 bezieht sich auf periodische symmetrische Schlüssel-Kryptoperioden; wenden Sie sich an Ihren QSA, um die spezifischen Anforderungen in Ihrer Umgebung zu erfahren. Jedes Rotationsereignis generiert eine RotateKey CloudTrail-Ereignis als Nachweis der Compliance. Eine Rotation auf Abruf (außerhalb des automatischen Zeitplans) ist über die RotateKeyOnDemand API, nützlich nach einem vermuteten Schlüsselkompromittierungsfall.

Für BYOK-Schlüssel mit importiertem Material ist keine automatische Rotation verfügbar. Sie müssen neues Schlüsselmaterial in Ihrem externen HSM generieren, es als neue Schlüsselversion importieren und als primäre Version festlegen. Dies muss innerhalb Ihres definierten Kryptoperiodenzeitraums erfolgen, um die Compliance zu gewährleisten.

AWS KMS-Kosten und S3-Bucket-Schlüsseloptimierung

Kundenseitig verwaltete KMS-Schlüssel kosten 1 US-Dollar pro Schlüssel und Monat. Für von AWS verwaltete und AWS-eigene Schlüssel fallen keine Speichergebühren an. Alle KMS-API-Aufrufe kosten 0.03 US-Dollar pro 10,000 Anfragen. Bei hohem Datenaufkommen in S3 mit kundenseitig verwalteten Schlüsseln können die Kosten für KMS-API-Aufrufe pro Objekt (ein GenerateDataKey pro PutObject, ein Decrypt pro GetObject) erheblich steigen.

S3 Bucket Key ist die Lösung. Wenn S3 Bucket Key für einen Bucket aktiviert ist, generiert S3 aus Ihrem KMS-Schlüssel einen kurzlebigen Datenschlüssel auf Bucket-Ebene und verschlüsselt damit die Datenschlüssel einzelner Objekte lokal in S3, anstatt für jedes Objekt KMS aufzurufen. Dadurch werden die KMS-API-Aufrufe für S3-Workloads um bis zu 99 % reduziert. Ein Workload mit 10 Millionen S3-Operationen pro Monat würde normalerweise 10 Millionen KMS-API-Aufrufe (ca. 30 US-Dollar/Monat an KMS-Gebühren) generieren; mit aktiviertem Bucket Key sinken diese KMS-Gebühren auf nahezu null. S3 Bucket Key ändert die Sicherheitseigenschaften der Verschlüsselung nicht: Objekte sind weiterhin durch AES-256-GCM-Verschlüsselung unter einer Schlüsselhierarchie geschützt, die auf Ihren kundenverwalteten KMS-Schlüssel zurückgeführt wird.

Erstellung kundenverwalteter KMS-Schlüssel

Erstellen eines vom Kunden verwalteten symmetrischen KMS-Schlüssels über die AWS Management Console:

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die AWS KMS-Konsole.
2. Wählen Sie die AWS-Region in der oberen rechten Ecke aus.
3. Wählen Sie im Navigationsbereich „Vom Kunden verwaltete Schlüssel“ aus.
4. Wählen Sie „Schlüssel erstellen“.
5. Wählen Sie unter Schlüsseltyp „Symmetrisch“ aus. Wählen Sie unter Schlüsselverwendung „Verschlüsseln und Entschlüsseln“ aus.
6. Weiter klicken.
7. Erstellen Sie einen Alias ​​für den Schlüssel (einen für Menschen lesbaren Namen wie z. B. prod/s3/data-lake).
8. Fügen Sie eine Beschreibung hinzu. (Optional, aber für die Governance empfohlen)
9. Weiter klicken.
10. Fügen Sie Tags für die Kostenverteilung und die Zugriffskontrolle hinzu. (Optional)
11. Weiter klicken.
12. Wählen Sie IAM-Benutzer und -Rollen aus, die den Schlüssel verwalten können (Schlüsseladministratoren, die den Schlüssellebenszyklus verwalten, ihn aber nicht für Datenoperationen verwenden).
13. Wenn Sie nicht möchten, dass Schlüsseladministratoren diesen Schlüssel löschen können, deaktivieren Sie das Kontrollkästchen „Schlüsseladministratoren das Löschen dieses Schlüssels erlauben“.
14. Weiter klicken.
15. Wählen Sie IAM-Benutzer und -Rollen aus, die den Schlüssel für kryptografische Operationen verwenden können (Schlüsselbenutzer, typischerweise Anwendungsdienstkonten).
16. Um anderen AWS-Konten die Verwendung dieses Schlüssels zu ermöglichen, fügen Sie deren Konto-IDs im Abschnitt „Andere AWS-Konten“ hinzu.
17. Weiter klicken.
18. Überprüfen Sie die aus Ihren Auswahlen generierten wichtigsten Richtlinien.
19. Klicken Sie auf „Fertigstellen“, um den Schlüssel zu erstellen.

Die Erstellung eines kundenverwalteten asymmetrischen KMS-Schlüssels erfolgt nach denselben Schritten, mit folgenden Ausnahmen: Wählen Sie in Schritt 5 als Schlüsseltyp „Asymmetrisch“ aus; wählen Sie unter Schlüsselverwendung entweder „Verschlüsseln und Entschlüsseln“ oder „Signieren und Verifizieren“ aus; und wählen Sie unter Schlüsselspezifikation die Algorithmus-Spezifikation (RSA_2048, RSA_3072, RSA_4096, ECC_NIST_P256, ECC_NIST_P384, ECC_NIST_P521 oder ECC_SECG_P256K1) aus.

AWS CloudHSM: Wann FIPS 140-2 Level 3 erforderlich ist

AWS CloudHSM ist ein kundeneigener, mandantenfähiger HSM-Service, der FIPS 140-2 Level 3-validierte Hardware-Sicherheitsmodule innerhalb Ihrer eigenen Amazon VPC bereitstellt. Im Gegensatz zum standardmäßigen AWS KMS, das mandantenfähig ist und vollständig von AWS verwaltet wird, stellt CloudHSM Ihrer Organisation dedizierte physische HSM-Hardware exklusiv zur Verfügung. Die Hardware wird nicht mit den Schlüsseln oder kryptografischen Operationen anderer Kunden geteilt.

Mit CloudHSM verwaltet AWS die physische Infrastruktur (Racks, Netzwerk, Stromversorgung, Firmware-Updates), hat aber keinen Zugriff auf Ihre Schlüssel oder HSM-Partitionen. Sie verwalten die HSM-Software, Partitionen und Schlüssel direkt über die Verwaltungsschnittstelle des HSM mithilfe von Hardware-Tokens (PED) oder Smartcard-Authentifizierung. Dies ist der entscheidende Unterschied zu herkömmlichen KMS: Mit CloudHSM hat AWS selbst im laufenden Betrieb keinen Zugriff auf Ihre Schlüssel.

Anwendungsfälle für CloudHSM umfassen: Schutz privater CA-Schlüssel für PKI-Infrastrukturen, private Schlüssel für die Codesignierung und Dokumentensignatur, Master-Schlüssel für die transparente Datenverschlüsselung (TDE) von Datenbanken, BYOK-Quelle für in KMS oder andere Systeme importierte Schlüssel sowie die Verschlüsselung von Zahlungs-PINs. Der Zugriff auf CloudHSM erfolgt über die APIs von PKCS#11, JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) oder OpenSSL Dynamic Engine.

AWS CloudHSM-Preise: ca. 1.45 US-Dollar pro Stunde pro HSM-Instanz, ca. 2,100 US-Dollar pro Monat für einen HA-Cluster mit zwei Instanzen (empfohlenes Minimum für den Produktiveinsatz).

Benutzerdefinierter Schlüsselspeicher: CloudHSM-gestützte KMS-Schlüssel

Benutzerdefinierte AWS KMS-Schlüsselspeicher kombinieren die KMS-API mit CloudHSM-Hardware der Stufe 3. Beim Erstellen eines KMS-Schlüssels in einem benutzerdefinierten Schlüsselspeicher generiert KMS einen 256-Bit-AES-GCM-Schlüssel innerhalb Ihres CloudHSM-Clusters. Das Schlüsselmaterial ist nicht exportierbar und verlässt die CloudHSM-HSMs niemals im Klartext. Alle kryptografischen Operationen an Schlüsseln in einem benutzerdefinierten Schlüsselspeicher werden innerhalb Ihres CloudHSM-Clusters ausgeführt, nicht in der standardmäßigen KMS-Multi-Tenant-HSM-Infrastruktur.

Benutzerdefinierte Schlüsselspeicher benötigen mindestens zwei aktive HSMs in verschiedenen Verfügbarkeitszonen. Wenn der CloudHSM-Cluster nicht verfügbar ist, kann KMS keine Operationen mit Schlüsseln in diesem benutzerdefinierten Schlüsselspeicher durchführen. Die Verfügbarkeit Ihrer Anwendung hängt von der Verfügbarkeit Ihres CloudHSM-Clusters ab. Benutzerdefinierte Schlüsselspeicher eignen sich für FedRAMP-High-Workloads, die FIPS 140-2 Level 3 erfordern, für eIDAS-qualifizierte Signaturvorgänge oder für Organisationen, die ihre bestehende CloudHSM-Infrastruktur als KMS-Schlüsselbasis nutzen müssen. Weitere Informationen zur Funktionsweise der Schlüsselhierarchie finden Sie in unserem ausführlichen Leitfaden zu AWS KMS .

AWS KMS vs. CloudHSM: Welches System ist das richtige für Sie?

Eigenschaft	AWS KMS (Standard)	AWS CloudHSM
Mietmodell	Mandantenfähig (gemeinsam genutzte HSM-Hardware)	Einzelmandant (dedizierte HSM-Hardware)
FIPS 140-2-Validierung	Level 2	Level 3
AWS-Zugriff auf wichtiges Material	Ja (als HSM-Betreiber)	Nein (Kunde steuert HSM-Partitionen)
Hauptverantwortung für das Management	AWS verwaltet vollständig	Gemeinsame Nutzung: AWS verwaltet die Hardware, der Kunde verwaltet die HSM-Software und die Schlüssel.
API-Integration	AWS KMS API, über 100 native Serviceintegrationen	PKCS#11, JCE, CNG, OpenSSL (nicht nativ für die meisten AWS-Dienste ohne benutzerdefinierten Schlüsselspeicher)
Automatische Schlüsseldrehung	Ja (90 Tage bis 7 Jahre)	Nein (manuell, vom Kunden verwaltet)
Hohe Verfügbarkeit	AWS-verwaltet, integriert	Erfordert mindestens einen 2-HSM-Cluster in mehreren Verfügbarkeitszonen.
CloudTrail-Integration	Ja (vollständige Protokollierung pro Vorgang)	Eingeschränkt (HSM-Operationen werden im HSM-Audit-Protokoll protokolliert, nicht nativ in CloudTrail)
Kosten	1 $/Schlüssel/Monat + 0.03 $/10 API-Aufrufe	~1.45 $/Std. pro HSM (~2,100 $/Monat für einen 2-HSM-HA-Cluster)
Am besten geeignet,	Die meisten regulierten Workloads, verwaltete Compliance, umfassende AWS-Serviceintegration	FIPS-Level-3-Anforderung, PKI-CA-Schlüssel, kein AWS-Schlüsselzugriff, benutzerdefinierte PKCS#11-Anwendungen

Multi-Cloud-Schlüsselverwaltungsarchitektur

AWS KMS ist eine AWS-native Lösung und lässt sich nicht auf Azure, GCP oder lokale Systeme erweitern. Organisationen mit Multi-Cloud-Workloads benötigen eine explizite Schlüsselverwaltungsstrategie über alle Anbieter hinweg. Drei Muster adressieren AWS KMS im Multi-Cloud-Kontext:

• Cloud-natives KMS mit einheitlicher Governance: Nutzen Sie AWS KMS für AWS-Workloads, Azure Key Vault für Azure und GCP Cloud KMS für GCP – mit einer zentralen Plattform für das Schlüssellebenszyklusmanagement, die Inventar, Rotationsstatus und Audit-Logs aller drei Plattformen aggregiert. So bleiben native Performance und Integration erhalten, während gleichzeitig Cloud-übergreifende Compliance-Transparenz gewährleistet wird.
• Zentralisierte BYOK-Steuerung von einem externen HSM: Generieren Sie sämtliche Schlüsselmaterialien von einem einzigen externen HSM oder HSM-as-a-Service, der unabhängig von allen Cloud-Anbietern ist. Importieren Sie abgeleitete Schlüssel in AWS KMS für AWS-Workloads, Azure Key Vault für Azure und GCP Cloud KMS für GCP. Die gesamte Verschlüsselung lässt sich auf eine einzige autoritative Schlüsselquelle zurückführen. (Encryption Consulting) HSM als Service bietet die externe FIPS 140-2 Level 3 HSM-Infrastruktur für dieses Modell, die gleichzeitig von AWS, Azure und GCP aus zugänglich ist.
• Clientseitige Verschlüsselung (HYOK): Verschlüsseln Sie alle Daten, bevor sie einen Cloud-Anbieter erreichen, mit einem Schlüssel aus Ihrem eigenen externen Schlüsselverwaltungssystem. Alle Clouds speichern ausschließlich den verschlüsselten Text. Dies ist das stärkste Multi-Cloud-Souveränitätsmodell, erfordert jedoch, dass Anwendungen alle kryptografischen Operationen clientseitig durchführen und Ihr externes KMS hochverfügbar ist.

Konformität: PCI DSS, FedRAMP, HIPAA und DORA

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): Vom Kunden verwaltete KMS-Schlüssel erfüllen Anforderung 3.5.1 (Schutz gespeicherter PANs durch starke Kryptografie). KMS mit benutzerdefiniertem CloudHSM-Schlüsselspeicher erfüllt Anforderung 3.7.1 (Schlüsselgenerierung mit einem HSM). CloudTrail-Datenzugriffsereignisse für KMS erfüllen Anforderung 10 (Audit-Protokollierung). Die automatische Rotation unterstützt Anforderung 3.7.4 (Verwaltung der Kryptoperioden). Von AWS verwaltete Schlüssel allein erfüllen PCI DSS nicht, da sie kein transaktionsbezogenes, identitätsverknüpftes Audit-Trail und keine Kundenschlüsselkontrolle bieten.

FedRAMP: Standard-AWS-KMS (FIPS 140-2 Level 2) erfüllt die Anforderungen von FedRAMP Moderate SC-12 (Erstellung und Verwaltung kryptografischer Schlüssel). FedRAMP High erfordert FIPS 140-2 Level 3-validierte Module gemäß SC-12 und SC-28; hierfür ist entweder ein benutzerdefinierter CloudHSM-Schlüsselspeicher oder AWS CloudHSM direkt erforderlich. AWS KMS und CloudHSM sind beide im AWS-Autorisierungspaket für FedRAMP High enthalten.

HIPAA: Vom Kunden verwaltete KMS-Schlüssel erfüllen 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 AWS KMS ab und ermöglicht somit die Nutzung von ePHI-Workloads. CloudTrail-Datenzugriffsereignisse erfüllen den HIPAA-Audit-Control-Standard (45 CFR 164.312(b)).

DORA (Digital Operational Resilience Act, gilt für EU-Finanzinstitute ab dem 17. Januar 2025): Artikel 9 und 10 von DORA fordern ein ICT-Risikomanagement und Tests zur operativen Resilienz, einschließlich der Resilienz des Schlüsselmanagements. Die Multi-AZ-Schlüsselreplikation, die automatische Rotationsfunktion und die CloudTrail-Auditprotokollierung von AWS KMS unterstützen die Anforderungen von DORA an das Schlüsselmanagement. EU-Finanzinstitute, die AWS KMS nutzen, sollten sicherstellen, dass sich ihre KMS-Schlüsselregion innerhalb der EU befindet, um die Anforderungen an den Datenstandort zu erfüllen, und gewährleisten, dass CloudTrail-Protokolle in einem EU-Speicher aufbewahrt werden.

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 Bewertung, dem Design, der Implementierung und dem Audit von AWS KMS-Konfigurationen – von der ersten Sicherheitsbewertung bis hin zur kontinuierlichen Erstellung von Compliance-Nachweisen.

• AWS KMS-Sicherheitsbewertung: Wir analysieren Ihre aktuelle AWS KMS-Konfiguration anhand Ihres Bedrohungsmodells und Ihrer Compliance-Anforderungen und identifizieren Schwachstellen (AWS-eigene oder AWS-verwaltete Schlüssel, wo kundenverwaltete Schlüssel erforderlich sind, Schlüsselrichtlinien mit zu weitreichenden Zugriffsrechten, fehlende CloudTrail-Datenzugriffsprotokollierung, fehlende Rotationspläne, S3-Buckets ohne aktivierten Bucket Key). Wir entwerfen die Zielarchitektur inklusive Schlüsselhierarchie pro Dienst und Datenklassifizierung, IAM-Trennung von Administrator und Benutzer, SCP-Schutzmaßnahmen und Audit-Log-Routing. Weitere Informationen finden Sie hier. Cloud-Beratungsdienste.
• HSM als Service für BYOK und HYOK: Für BYOK-Implementierungen, die eine FIPS 140-2 Level 3-Schlüsselgenerierung außerhalb von AWS erfordern, oder für clientseitige 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 sich in AWS KMS-Schlüsselimport-Workflows integriert. Geeignet als BYOK-Quelle für AWS, Azure und GCP gleichzeitig.
• CBOM Secure für AWS KMS Discovery: AWS-Umgebungen mit vielen Konten weisen häufig inkonsistente KMS-Konfigurationen auf: Einige Dienste verwenden AWS-eigene Schlüssel, andere AWS-verwaltete Schlüssel und wieder andere kundenverwaltete Schlüssel mit inkonsistenten Richtlinien. Encryption Consulting CBOM Secure Erkennt und inventarisiert alle KMS-Schlüsselkonfigurationen, Zugriffsrichtlinien, Rotationsstatus und CloudTrail-Protokollierungslücken über AWS-Konten hinweg und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die die Dokumentation zur Einhaltung der PCI DSS v4.0.1 Anforderung 12.3.3 unterstützt.
• PCI DSS- und FedRAMP-Konformitätshinweis: Wir ordnen Ihre AWS KMS-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 für AWS KMS: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). NIST IR 8547 deutet darauf hin, dass RSA und ECC für neue Anwendungsfälle um das Jahr 2030 als veraltet gelten werden. Die für Signierung und Schlüsselaustausch verwendeten asymmetrischen AWS KMS RSA- und ECC-Schlüssel müssen migriert werden. (Encryption Consulting) PQC-Bereitschaft Der Service ordnet Ihren AWS KMS-Schlüsselbestand dem Zeitplan der Post-Quantum-Migration zu und entwirft die Reihenfolge der Schlüsselrotation und des Algorithmusübergangs.

Um Ihre Sicherheitslage oder Compliance-Anforderungen für AWS KMS zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

AWS KMS bietet für die überwiegende Mehrheit der Unternehmens- und regulierten Workloads kryptografisch sichere Sicherheit. Schlüsseldaten verbleiben in FIPS 140-2 Level 2-validierten HSMs und werden niemals im Klartext übertragen. Jeder Vorgang mit einem vom Kunden verwalteten Schlüssel wird in CloudTrail protokolliert. Die Schlüsselrichtlinie und die IAM-Richtlinie gewährleisten eine mehrstufige, obligatorische Zugriffskontrolle, die AWS nicht umgehen kann, um Ihren Schlüssel ohne authentifizierte API-Anfrage zu verwenden.

Die Sicherheitslücken des standardmäßigen AWS KMS sind folgende: Es handelt sich um einen mandantenfähigen Dienst, bei dem AWS die zugrundeliegende Hardware betreibt; ohne einen benutzerdefinierten CloudHSM-Schlüsselspeicher bietet er keine Hardware-Isolation gemäß FIPS 140-2 Level 3; und von AWS verwaltete und im Besitz von AWS befindliche Schlüssel bieten weder ein Audit-Trail pro Operation noch eine Kontrolle der Kundenschlüssel. Für Workloads, bei denen diese Einschränkungen relevant sind (FedRAMP High, klassifizierte Daten, Souveränitätsvorgaben oder Zero-Trust-Architekturen, bei denen der Cloud-Anbieter selbst Teil des Bedrohungsmodells ist), empfiehlt sich CloudHSM, BYOK oder HYOK.

Die Auswahl des Schlüsseltyps, die Gestaltung der Schlüsselrichtlinien, die IAM-Trennung, die CloudTrail-Datenzugriffsprotokollierung und der Rotationsplan von Anfang an korrekt zu implementieren, ist deutlich einfacher, als eine große AWS-Umgebung nach einem Compliance-Audit, bei dem Schwachstellen aufgedeckt wurden, zu sanieren. Für die operative Funktionsweise von AWS KMS, die über die Sicherheitsbewertung hinausgeht, lesen Sie unseren ausführlichen Artikel zum AWS Key Management Service.

Häufig gestellte Fragen

Wie sicher ist AWS KMS?

AWS KMS bietet für die meisten Unternehmens- und regulierten Workloads ein hohes Maß an Sicherheit. Schlüsselmaterial wird in FIPS 140-2 Level 2-validierten Multi-Tenant-HSMs generiert und gespeichert und verlässt das HSM niemals im Klartext. Schlüssel sind regionsgebunden. Jede vom Kunden verwaltete Schlüsseloperation wird in CloudTrail protokolliert. Die wichtigste Sicherheitsbarriere besteht darin, dass AWS die zugrunde liegende HSM-Hardware betreibt und somit ein operativer Akteur in der Schlüsselvertrauenskette ist. Für Workloads, die Single-Tenant-Hardware der Stufe 3 oder keinen AWS-Schlüsselzugriff erfordern, ist CloudHSM oder HYOK erforderlich.

Kann AWS auf meine KMS-Schlüssel zugreifen?

AWS betreibt die HSM-Hardware, die das KMS-Schlüsselmaterial speichert und sich innerhalb der physischen Vertrauensgrenze befindet. AWS kann Ihren kundenverwalteten Schlüssel nicht in Ihrem Namen für kryptografische Operationen aufrufen, ohne eine authentifizierte API-Anfrage zu stellen, die Ihre Schlüssel- und IAM-Richtlinienprüfungen besteht. Für Workloads, bei denen AWS keinen operativen Zugriff auf das Schlüsselmaterial haben darf, sollten Sie BYOK (importiertes Schlüsselmaterial, bei dem Sie das Original außerhalb von AWS aufbewahren und die importierte Kopie löschen können) oder HYOK (clientseitige Verschlüsselung, bei der der Schlüssel niemals in AWS gelangt) verwenden.

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 einen einzelnen Mandanten, die nach FIPS 140-2 Level 3 innerhalb Ihrer VPC validiert ist. AWS verwaltet lediglich die physische Infrastruktur; Sie verwalten die HSM-Software, Partitionen und das Schlüsselmaterial selbst. AWS hat keinen Zugriff auf Ihre CloudHSM-Schlüssel. CloudHSM ist erforderlich, wenn dedizierte Hardware der Stufe 3 vorgeschrieben ist oder wenn AWS von der Schlüsselvertrauensgrenze ausgeschlossen werden soll.

Was ist BYOK in AWS KMS und wie wirkt es sich auf die Sicherheit aus?

BYOK bedeutet, AES-256-Schlüsselmaterial in Ihrem eigenen HSM zu generieren, es mit einem Importjob-Schlüssel zu umschließen und in einen KMS-Schlüssel (Ursprung: EXTERN) zu importieren. AWS verwendet Ihr importiertes Material für alle kryptografischen Operationen. Sie behalten das Original außerhalb von AWS; das Löschen der importierten Kopie aus dem KMS führt sofort zum Entzug des Zugriffs. BYOK bietet Kontrolle über die Schlüsselherkunft und unabhängigen Widerruf, AWS hat jedoch während der Nutzung weiterhin Zugriff auf das Schlüsselmaterial. Eine automatische Rotation für importierte Schlüssel ist nicht verfügbar.

Erfüllt AWS KMS die Anforderungen von PCI DSS und FedRAMP?

Standard-AWS-KMS mit kundenverwalteten Schlüsseln erfüllt die PCI-DSS-v4.0.1-Anforderungen 3.5.1, 3.7.4 und 10, wenn die CloudTrail-Datenzugriffsprotokollierung aktiviert ist. Die PCI-DSS-Anforderung 3.7.1 (HSM-Schlüsselgenerierung) erfordert einen benutzerdefinierten CloudHSM-Schlüsselspeicher (Stufe 3). Für FedRAMP High erfüllt Standard-KMS (Stufe 2) die FIPS-140-2-Anforderung Stufe 3 gemäß SC-12 nicht; ein benutzerdefinierter CloudHSM-Schlüsselspeicher ist erforderlich. AWS KMS und CloudHSM sind beide Bestandteil des AWS-FedRAMP-High-Autorisierungspakets.

Wie funktioniert die Schlüsselrotation in AWS KMS und hat sie Auswirkungen auf bereits verschlüsselte Daten?

Die automatische Rotation generiert in einem von Ihnen konfigurierten Intervall (90 Tage bis 7 Jahre) neues Schlüsselmaterial für einen kundenverwalteten Schlüssel. Das neue Material wird für neue Verschlüsselungsvorgänge primär verwendet. Frühere Versionen bleiben dauerhaft für die Entschlüsselung älterer Daten erhalten. Der Schlüssel-ARN bleibt unverändert; die Rotation erfolgt transparent für Anwendungen und eine erneute Datenverschlüsselung ist nicht erforderlich. Für BYOK-Schlüssel mit importiertem Material ist die automatische Rotation nicht verfügbar; Sie müssen neues Schlüsselmaterial manuell generieren und als neue Schlüsselversion importieren.