Häufig gestellte Fragen zum AWS Key Management Service

AWS KMS erzwingt die Verwendung der von Ihnen definierten Management-Richtlinien. Sie können auswählen, welche IAM-Benutzer und -Rollen in Ihrem Konto oder anderen Konten Ihre Schlüssel verwenden und verwalten dürfen.

AWS KMS ist so aufgebaut, dass niemand, auch keine Angestellten von AWS, Ihre KMS-Schlüssel im Klartext aus dem Service abrufen kann. AWS KMS verwendet Hardware-Sicherheitsmodule (HSMs), die gemäß FIPS 140-2 validiert wurden oder derzeit validiert werden, um die Vertraulichkeit und Integrität Ihrer Schlüssel zu schützen. Ihre Klartext-KMS-Schlüssel verlassen nie die HSMs, werden zu keiner Zeit auf die Festplatte geschrieben, sondern lediglich für die Dauer der von Ihnen angeforderten kryptografischen Operation im flüchtigen Speicher der HSMs verwendet. Aktualisierungen der Software auf den Service-Hosts und der AWS-KMS-HSM-Firmware werden durch eine Mehrparteien-Zugangskontrolle gesteuert, die von einer unabhängigen Gruppe innerhalb von Amazon sowie einem NIST-zertifizierten Labor gemäß FIPS 140-2 geprüft und überprüft wird.

Weitere Einzelheiten zu diesen Sicherheitskontrollen finden Sie im technischen Dokument zu den kryptografischen Details von AWS KMS. Sie können auch das FIPS-140-2-Zertifikat für AWS-KMS-HSMs zusammen mit der zugehörigen Sicherheitsrichtlinie lesen, um weitere Informationen darüber zu erhalten, wie AWS-KMS-HSMs die Sicherheitsanforderungen von FIPS 140-2 erfüllen. Sie können auch eine Kopie des Berichts System and Organization Controls (SOC) von AWS Artifact herunterladen, um mehr über die Sicherheitskontrollen zu erfahren, die der Service zum Schutz Ihrer KMS-Schlüssel verwendet.

Sie müssen nichts tun. Alle AWS-KMS-Schlüssel werden unabhängig von ihrem Erstellungsdatum oder ihrer Herkunft automatisch mithilfe von HSMs geschützt, die gemäß FIPS 140-2 Security Level 3 validiert wurden oder derzeit validiert werden.

Nach FIPS 140-2 Sicherheitsstufe 3 validierte HSMs werden in allen AWS-Regionen eingesetzt, in denen AWS KMS angeboten wird.
HINWEIS: Aufgrund von Vorschriften kann AWS KMS in den chinesischen Regionen keine NIST FIPS-HSMs verwenden und verwendet stattdessen vom chinesischen Office of the State Commercial Cryptographic Administration (OSCCA) zertifizierte HSMs.

AWS KMS ist ein zweistufiger Service. Die API-Endpunkte erhalten Clientanforderungen über eine HTTPS-Verbindung. Dabei werden ausschließlich TLS-Ciphersuites verwendet, die Perfect Forward Secrecy unterstützen. Diese API-Endpunkte authentifizieren und autorisieren die Anforderung, bevor diese für eine kryptografische Operation an die HSMs von AWS KMS oder Ihren AWS CloudHSM-Cluster (falls Sie den benutzerdefinierten Schlüsselspeicher von KMS verwenden) übergeben wird.

Sie konfigurieren Ihre Anwendungen so, dass sie eine Verbindung zu den einzigartigen regionalen FIPS 140-2-validierten HTTPS-Endpunkten herstellen. Die FIPS 140-2-validierten HTTPS-Endpunkte in AWS KMS basieren auf dem OpenSSL FIPS Object Module. Sie können die Sicherheitsrichtlinien für das OpenSSL-Modul hier einsehen. FIPS 140-2-validierte API-Endpunkte sind in allen Handelsregionen verfügbar, in denen AWS KMS erhältlich ist.

Ja. AWS KMS verfügt nachweislich über die Funktionalität und Sicherheitskontrollen, die die Einhaltung der Anforderungen an Verschlüsselung und Schlüsselverwaltung (hauptsächlich festgelegt in den Abschnitten 3.5 und 3.6) des PCI DSS 3.2.1 ermöglichen.

Weitere Informationen über PCI-DSS-konforme Services in AWS finden Sie im Bereich Häufig gestellte Fragen zu PCI DSS.

Sie können die Generierung von Datenschlüsseln durch AWS KMS anfordern und sie zur Verwendung in Ihrer eigenen Anwendung ausgeben. Die Datenschlüssel sind unter einem Stammschlüssel verschlüsselt, den Sie in AWS KMS definieren, sodass Sie den verschlüsselten Datenschlüssel gefahrlos mit Ihren verschlüsselten Daten speichern können. Ihre verschlüsselten Datenschlüssel (und folglich Ihre Quelldaten) können nur durch Benutzer entschlüsselt werden, die zur Verwendung des ursprünglichen Stammschlüssels zur Entschlüsselung des Datenschlüssels berechtigt sind.

Nein. AWS KMS-Schlüssel werden nur innerhalb des Services erstellt und verwendet, um ihre Sicherheit zu überprüfen, Ihre Richtlinien konsequent durchzusetzen und ein zentrales Protokoll ihrer Verwendung zu erstellen.

Ein von AWS KMS generierter KMS-Schlüssel für eine einzelne Region wird nur in der Region gespeichert und verwendet, in der er erstellt wurde. Mit AWS KMS-Schlüsseln für mehrere Regionen können Sie einen Primärschlüssel für mehrere Regionen in mehrere Regionen innerhalb derselben AWS-Partition replizieren.

Protokolle in AWS CloudTrail zeigen alle AWS-KMS-API-Anforderungen, einschließlich Verwaltungsanfragen (z. B. Erstellen, Rotieren, Deaktivieren, Bearbeitung von Richtlinien) und Verschlüsselungsanforderungen (z. B. Verschlüsselung/Entschlüsselung). Aktivieren Sie CloudTrail in Ihrem Konto, um diese Protokolle anzuzeigen.

CloudHSM stellt Ihnen einen validierten Single-Tenant-HSM-Cluster in Ihrer Amazon Virtual Private Cloud (VPC) zur Speicherung und Nutzung Ihrer Schlüssel bereit. Sie besitzen durch einen von AWS unabhängigen Authentifizierungsmechanismus die alleinige Kontrolle darüber, wie Ihre Schlüssel verwendet werden. Sie interagieren mit Schlüsseln in Ihrem CloudHSM-Cluster ähnlich wie mit Ihren Anwendungen, die in Amazon EC2 ausgeführt werden. Sie können CloudHSM zur Unterstützung diverser Anwendungsfälle einsetzen, darunter Digital Rights Management (DRM), Public Key Infrastructure (PKI), Dokumentensignierung und kryptografische Funktionen unter Verwendung von PKCS#11-, Java JCE- oder Microsoft CNG-Schnittstellen.
 

AWS KMS hilft Ihnen die Verschlüsselungsschlüssel, die Ihre Anwendungen und unterstützte AWS-Services in mehreren Regionen auf der ganzen Welt verwenden, von einer einzigen Konsole aus zu erstellen und zu kontrollieren. Der Service verwendet ein FIPS-HSM, das gemäß FIPS 140-2 validiert wurde oder derzeit validiert wird, um die Sicherheit Ihrer Schlüssel zu gewährleisten. Die zentrale Verwaltung aller Ihrer Schlüssel in AWS KMS hilft Ihnen festzulegen, wer Ihre Schlüssel unter welchen Bedingungen verwenden darf, wann sie rotiert werden und wer sie verwaltet. Aufgrund der Integration von AWS KMS in CloudTrail können Sie zur Unterstützung Ihrer gesetzlichen und Compliance-Maßnahmen die Verwendung Ihrer Schlüssel überwachen. Sie interagieren mit AWS KMS in Ihren Anwendungen entweder durch das AWS SDK, wenn Sie die Service-APIs direkt aufrufen möchten, durch andere, in AWS KMS integrierte AWS-Services oder durch Verwendung des AWS-Verschlüsselungs-SDK, wenn Sie eine clientseitige Verschlüsselung durchführen möchten.

Bei AWS KMS zahlen Sie nur für das, was Sie auch tatsächlich nutzen. Es fallen keine Mindestgebühren an. Sie können mit der Verwendung dieses Service beginnen, ohne dass Ihnen Einrichtungsgebühren oder sonstige Verpflichtungen entstehen. Nach Ende eines Monats wird Ihre Kreditkarte automatisch mit den Nutzungsgebühren für den betreffenden Monat belastet.

Für alle KMS-Schlüssel, die Sie erstellen, und für API-Anfragen, die Sie monatlich an den Dienst richten, fallen Gebühren an, die über eine kostenlose Stufe hinausgehen.
 

Aktuelle Preisinformationen finden Sie auf der Preisseite von AWS KMS.

Ja. Mit dem kostenlosen AWS-Kontingent können Sie AWS KMS in allen Regionen kostenlos* verwenden. Von AWS verwaltete AWS-KMS-Schlüssel, die in Ihrem Auftrag von AWS-Services erstellt wurden, können Sie kostenlos in Ihrem Konto speichern. Es gibt ein kostenloses Kontingent für die Nutzung, das für jeden Monat eine bestimmte Anzahl kostenloser Anforderungen an den Service bereitstellt. Aktuelle Informationen zu den Preisen, einschließlich des kostenlosen Kontingents, finden Sie auf der Preisseite von AWS KMS.

*API-Anforderungen mit asymmetrischen KMS-Schlüssel und API-Anforderungen an die GenerateDataKeyPair- und GenerateDataKeyPairWithoutPlaintext-APIs sind vom kostenlosen Kontingent ausgeschlossen.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, u. a. MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. Weitere Informationen finden Sie hier.

Ja. Sie können eine Kopie Ihres Schlüssels aus Ihrer eigenen Infrastruktur für die Schlüsselverwaltung nach AWS KMS importieren und mit allen integrierten AWS-Services sowie innerhalb Ihrer eigenen Anwendungen verwenden.

Sie können einen importierten Schlüssel verwenden, um eine bessere Kontrolle über die Erstellung, das Lebenszyklusmanagement und die Dauerhaftigkeit Ihres Schlüssels in AWS KMS zu erhalten. Importierte Schlüssel sollen Ihnen dabei helfen, Ihre Compliance-Anforderungen zu erfüllen. Dazu kann die Möglichkeit gehören, eine sichere Kopie des Schlüssels in Ihrer Infrastruktur zu erzeugen oder aufrechtzuerhalten, und die Möglichkeit, die importierte Kopie des Schlüssels sofort aus der AWS-Infrastruktur zu löschen.

Sie können symmetrische Schlüssel, asymmetrische Schlüssel (RSA und elliptische Kurve) und HMAC-Schlüssel importieren.

Während des Importvorgangs muss Ihr Schlüssel durch einen von AWS KMS bereitgestellten öffentlichen Schlüssel mit dem unterstützten Wrapping-Algorithmus verschlüsselt werden. Damit wird sichergestellt, dass Ihr verschlüsselter Schlüssel nur von AWS KMS entschlüsselt werden kann.

Es gibt zwei Hauptunterschiede:
 

1. Sie sind für die Aufbewahrung einer Kopie Ihrer importierten Schlüssel in Ihrer Schlüsselverwaltungsinfrastruktur verantwortlich, damit Sie sie jederzeit erneut importieren können. AWS überprüft jedoch die Verfügbarkeit, Sicherheit und Zuverlässigkeit der Schlüssel, die von AWS KMS für Sie erstellt wurden, bis Sie die Schlüssel zum Löschen freigeben.
2. Sie können für einen importierten Schlüssel ein Ablaufdatum festlegen. AWS KMS löscht das Schlüsselmaterial automatisch nach der Ablaufzeit. Sie können importiertes Schlüsselmaterial auch bei Bedarf löschen. In beiden Fällen wird das Schlüsselmaterial selbst gelöscht, aber die KMS-Schlüssel-Referenz in AWS KMS und verknüpften Metadaten wird beibehalten, damit das Schlüsselmaterial in Zukunft erneut importiert werden kann. Von AWS KMS erzeugte Schlüssel haben keine Ablaufzeit und können nicht sofort gelöscht werden. Es gibt eine obligatorische Wartezeit von 7 bis 30 Tagen. Alle kundenverwalteten KMS-Schlüssel, unabhängig davon, ob das Schlüsselmaterial importiert wurde, können manuell deaktiviert oder zur Löschung bestimmt werden. In diesem Fall wird der KMS-Schlüssel selbst gelöscht, nicht nur das zugrundeliegende Schlüsselmaterial.

Sie können Ihre Kopie des Schlüsselmaterials mit einem gültigen Ablaufzeitraum unter dem ursprünglichen AWS-KMS-Schlüssel erneut in AWS KMS importieren, damit es verwendet werden kann.

Ja. Nachdem Sie Ihren Schlüssel in einen AWS-KMS-Schlüssel importiert haben, erhalten Sie alle paar Minuten eine CloudWatch-Metrik, die die Zeit bis zum Ablauf des importierten Schlüssels herunterzählt. Sie erhalten außerdem ein CloudWatch-Ereignis, sobald der importierte Schlüssel unter Ihrem AWS-KMS-Schlüssel abläuft. Sie können eine Logik erstellen, die aufgrund dieser Metriken oder Ereignisse aktiv wird und den Schlüssel automatisch mit einer neuen Ablaufzeit re-importiert, um Risiken im Hinblick auf die Verfügbarkeit zu vermeiden.

AWS KMS unterstützt 256-Bit-Schlüssel bei der Erstellung eines KMS-Schlüssels für die Verschlüsselung und Entschlüsselung. Generierte Datenschlüssel, die an den Aufrufer zurückgegeben werden, können 256-Bit- oder 128-Bit-Schlüssel sein oder einen beliebigen Wert von bis zu 1 024 Bytes aufweisen. Wenn AWS KMS für Sie einen 256-Bit-KMS-Schlüssel verwendet, wird der AES-Algorithmus im Galois-Zähler-Modus (AES-GCM) verwendet.

AWS KMS unterstützt die folgenden asymmetrischen Schlüsseltypen: RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521, und ECC SECG P-256k1. AWS KMS unterstützt die Verschlüsselungsalgorithmen RSAES_OAEP_SHA_1 und RSAES_OAEP_SHA_256 mit den Schlüsseltypen RSA 2048, RSA 3072 und RSA 4096. Verschlüsselungsalgorithmen können nicht mit den Schlüsseltypen der elliptischen Kurve (ECC NIST P-256, ECC NIST P-384, ECC NIST-521 und ECC SECG P-256k1) verwendet werden.

Bei der Verwendung von Schlüsseltypen mit elliptischen Kurven unterstützt AWS KMS die ECDH-Schlüsselvereinbarungsalgorithmen.

Bei Verwendung von RSA-Schlüsseltypen unterstützt AWS KMS die Signieralgorithmen RSASSA_PSS_SHA_256, RSASSA_PSS_SHA_384, RSASSA_PSS_SHA_512, RSASSA_PKCS1_V1_5_SHA_256, RSASSA_PKCS1_V1_5_SHA_384 und RSASSA_PKCS1_V1_5_SHA_512. Bei der Verwendung von Schlüsseltypen mit elliptischer Kurve unterstützt AWS KMS die Signieralgorithmen ECDSA_SHA_256, ECDSA_SHA_384 und ECDSA_SHA_512.

Der öffentliche Teil des asymmetrischen Schlüsselmaterials wird in AWS KMS generiert und kann durch Aufruf der „Verify“-API für die Überprüfung digitaler Signaturen oder durch Aufruf der „Encrypt“-API für die Verschlüsselung öffentlicher Schlüssel verwendet werden. Der öffentliche Schlüssel kann auch außerhalb von AWS KMS zur Überprüfung oder Verschlüsselung verwendet werden. Sie können die GetPublicKey-API aufrufen, um den öffentlichen Teil des asymmetrischen KMS-Schlüssel abzurufen.

Das Größenlimit beträgt 4 KB. Wenn Sie Daten, die größer als 4 KB sind, digital signieren möchten, können Sie einen Nachrichtenauszug der Daten erstellen und an AWS KMS senden. Die digitale Signatur wird über den Auszug der Daten erstellt und zurückgegeben. Sie geben als Parameter in der Sign-API-Anforderung an, ob Sie die vollständige Nachricht oder einen Nachrichtenauszug senden. Alle Daten, die an die Verschlüsselungs-, Entschlüsselungs- oder Wiederverschlüsselungs-APIs übermittelt werden und asymmetrische Operationen erfordern, müssen ebenfalls weniger als 4 KB groß sein.

In der Konsole verfügt jeder Schlüssel über ein neues Feld namens Schlüsseltyp. Es hat den Wert asymmetrischer Schlüssel oder symmetrischer Schlüssel. Die DescribeKey-API gibt ein KeyUsage-Feld zurück, das angibt, ob der Schlüssel zum Signieren oder Verschlüsseln verwendet werden kann.

Nein. Automatisches Rotieren wird für asymmetrische oder HMAC-KMS-Schlüssel nicht unterstützt. Im Allgemeinen kann die Rotation von asymmetrischen Schlüsseln oder HMAC-Schlüsseln Ihre bestehende Workload erheblich beeinträchtigen, da Sie alle Schlüsselinstances, die Sie in der Vergangenheit mit anderen Parteien geteilt haben, außer Betrieb nehmen und ersetzen müssen. Falls erforderlich, können Sie sie manuell drehen, indem Sie einen neuen KMS-Schlüssel erstellen und einen vorhandenen Schlüsselalias vom alten KMS-Schlüssel auf den neuen KMS-Schlüssel abbilden.

Nein. Beim Erstellen eines KMS-Schlüssels müssen Sie angeben, ob der Schlüssel für Verschlüsselungs- oder Signiervorgänge verwendet werden soll. Ein RSA-Schlüsseltyp kann für Signier- oder Verschlüsselungsvorgänge verwendet werden, aber nicht für beides. Schlüsseltypen für elliptische Kurven können nur für Signiervorgänge verwendet werden.

Ja. Die Limits für Anfragen pro Sekunde unterscheiden sich je nach Schlüsseltyp und Algorithmus. Weitere Informationen finden Sie auf der Seite zu Grenzwerte von AWS KMS.

Nein. Sie können die benutzerdefinierte Schlüsselspeicherfunktion nicht mit asymmetrischen Schlüsseln verwenden.

Nicht direkt. AWS KMS kann keine digitalen Zertifikate mit von AWS KMS erstellten asymmetrischen KMS-Schlüssel speichern oder zuordnen. Sie können allerdings eine Zertifizierungsstelle wie AWS Private Certificate Authority verwenden, um ein Zertifikat für den öffentlichen Teil des asymmetrischen KMS-Schlüssel auszustellen. Auf diese Weise können die Entitäten, die Ihren öffentlichen Schlüssel nutzen, prüfen, ob der öffentliche Schlüssel tatsächlich Ihnen gehört.

Die Funktion benutzerdefinierte Schlüsselspeicher von AWS KMS kombiniert die Konfigurationsmöglichkeiten von CloudHSM mit der Integration und Benutzerfreundlichkeit von AWS KMS. Sie können Ihren eigenen CloudHSM-Cluster konfigurieren und AWS KMS autorisieren, diesen als dedizierten Schlüsselspeicher für Ihre Schlüssel anstatt des standardmäßigen AWS KMS-Schlüsselspeichers zu verwenden. Wenn Sie Schlüssel in AWS KMS erstellen, können Sie das Schlüsselmaterial auf Wunsch in Ihrem CloudHSM-Cluster generieren. KMS-Schlüssel, die in Ihrem benutzerdefinierten Schlüsselspeicher erzeugt werden, verlassen die HSMs im CloudHSM-Cluster nie als Klartext und alle AWS-KMS-Vorgänge, die diese Schlüssel verwenden, werden nur in Ihren HSMs durchgeführt. In jeder anderen Hinsicht entsprechen in Ihrem benutzerdefinierten Schlüsselspeicher gespeicherte KMS-Schlüssel anderen AWS-KMS-Schlüssel.

Zusätzliche Anleitung dazu, ob die Verwendung eines benutzerdefinierten Schlüsselspeichers für Sie sinnvoll ist, finden Sie in diesem Blog.

Da Sie die Kontrolle über Ihren CloudHSM-Cluster haben, können Sie den Lebenszyklus Ihrer KMS-Schlüssel unabhängig von AWS KMS verwalten. Es gibt vier Gründe, warum ein benutzerdefinierter Schlüsselspeicher für Sie nützlich sein könnte. Erstens besitzen Sie möglicherweise Schlüssel, die explizit in einer Einzelmandanten-HSM oder in einer HSM geschützt werden müssen, über die Sie direkte Kontrolle haben. Drittens müssen Sie möglicherweise in der Lage sein, Schlüsselmaterial sofort aus AWS KMS zu entfernen und einen unabhängigen Nachweis darüber zu erbringen. Schließlich müssen Sie womöglich die gesamte Verwendung Ihrer Schlüssel unabhängig von AWS KMS oder CloudTrail überprüfen können.

Es gibt zwei Unterschiede bei der Verwaltung von Schlüsseln in einem benutzerdefinierten Schlüsselspeicher, der von CloudHSM unterstützt wird, im Vergleich zu dem standardmäßigen AWS KMS-Schlüsselspeicher. Sie können Schlüsselmaterial nicht in Ihren benutzerdefinierten Schlüsselspeicher importieren und AWS KMS kann Schlüssel nicht automatisch für Sie rotieren. In jeder anderen Hinsicht, einschließlich der Art der Schlüssel, die generiert werden können, der Art und Weise, wie Schlüssel Aliase verwenden und wie Richtlinien definiert werden, werden Schlüssel, die in einem benutzerdefinierten Schlüsselspeicher gespeichert sind, auf dieselbe Weise verwaltet wie alle anderen von AWS KMS-Kunden verwalteten KMS-Schlüssel.

Nein, nur kundenverwaltete KMS-Schlüssel können in einem benutzerdefinierten Schlüsselspeicher von AWS KMS unterstützt von CloudHSM gespeichert und verwaltet werden. Von AWS verwaltete KMS-Schlüssel, die in Ihrem Auftrag von anderen AWS-Services zur Verschlüsselung Ihrer Daten erstellt werden, werden stets im standardmäßigen AWS-KMS-Schlüsselspeicher generiert und gespeichert.

Nein, API-Anfragen an AWS KMS zur Verwendung eines KMS-Schlüssels für die Ver- und Entschlüsselung von Daten werden identisch behandelt. Die Authentifizierungs- und Autorisierungsprozesse werden unabhängig davon ausgeführt, wo der Schlüssel gespeichert wird. Sämtliche Aktivitäten unter Verwendung eines Schlüssels in einem benutzerdefinierten Schlüsselspeicher unterstützt von CloudHSM werden auch identisch in AWS CloudTrail protokolliert. Die tatsächlichen Kryptografievorgänge geschehen jedoch exklusiv im benutzerdefinierten Schlüsselspeicher oder im standardmäßigen AWS-KMS-Schlüsselspeicher.

Neben den Aktivitäten, die durch AWS KMS in CloudTrail protokolliert werden, bietet ein benutzerdefinierter Schlüsselspeicher drei weitere Prüfungsmechanismen. Erstens protokolliert CloudHSM auch alle API-Aktivitäten in CloudTrail, wie das Erstellen von Clustern und das Hinzufügen oder Entfernen von HSMs. Zweitens erfasst jeder Cluster auch seine eigenen lokalen Protokolle zur Aufzeichnung von Benutzer- und Schlüsselverwaltungsaktivitäten. Drittens kopiert jede CloudHSM-Instance die lokalen Benutzer- und Schlüsselaktivitätsprotokolle auf AWS CloudWatch.

Durch die Verwendung eines benutzerdefinierten AWS-KMS-Schlüsselspeichers können Sie selbst dafür sorgen, dass Ihre Schlüssel für die Verwendung durch AWS KMS verfügbar sind. Konfigurationsfehler in CloudHSM und die versehentliche Löschung von Schlüsselmaterial in einem CloudHSM-Cluster können sich auf die Verfügbarkeit auswirken. Die Anzahl der verwendeten HSMs und Ihre Auswahl der Availability Zones (AZs) können sich ebenfalls auf die Resilienz Ihres Clusters auswirken. Wie bei jedem Schlüsselverwaltungssystem ist es wichtig, zu verstehen, sich die Verfügbarkeit von Schlüsseln auf die Wiederherstellung verschlüsselter Daten auswirken kann.

Die Rate, mit der Schlüssel, die in einem von CloudHSM unterstützten benutzerdefinierten AWS-KMS-Schlüsselspeicher gespeichert sind, über AWS-KMS-API-Aufrufe verwendet werden können, ist geringer als bei Schlüsseln, die im standardmäßigen AWS-KMS-Schlüsselspeicher gespeichert sind. Weitere Informationen zu den aktuellen Leistungsgrenzen finden Sie im Entwicklerhandbuch für AWS KMS.

Die Preise für AWS KMS bleiben bei der Verwendung eines benutzerdefinierten Schlüsselspeichers unverändert. Jeder benutzerdefinierte Schlüsselspeicher erfordert jedoch, dass Ihr AWS CloudHSM-Cluster mindestens zwei HSMs enthält. Diese HSMs werden zu den standardmäßigen AWS-CloudHSM-Preisen abgerechnet. Für die Verwendung eines benutzerdefinierten Schlüsselspeichers fallen keine zusätzlichen Gebühren an.

AWS KMS-Anwender, die einen benutzerdefinierten Schlüsselspeicher verwenden möchten, müssen weiterhin einen AWS-CloudHSM-Cluster einrichten, HSMs hinzufügen, die Benutzer der HSMs verwalten und möglicherweise HSMs aus Datensicherungen wiederherstellen. Dies sind sicherheitsempfindliche Aufgaben und Sie können überprüfen, dass die angemessenen Ressourcen und Organisationskontrollen vorhanden sind.

Nein, die Möglichkeit, Ihr eigenes Schlüsselmaterial in einen benutzerdefinierten Schlüsselspeicher von AWS KMS zu importieren, wird nicht unterstützt. Schlüssel, die in einem benutzerdefinierten Schlüsselspeicher gespeichert werden, können nur in den HSMs generiert werden, die Ihren CloudHSM-Cluster bilden.

Nein, die Möglichkeit, Schlüssel zwischen den unterschiedlichen Typen von AWS KMS-Schlüsselspeichern zu migrieren, wird aktuell nicht unterstützt. Alle Schlüssel müssen in dem Schlüsselspeicher erstellt werden, in dem sie verwendet werden sollen, es sei denn, Sie importieren Ihr eigenes Schlüsselmaterial in den standardmäßigen AWS KMS-Schlüsselspeicher.

Die Möglichkeit, Schlüsselmaterial in einem benutzerdefinierten Schlüsselspeicher von AWS KMS automatisch zu rotieren, wird nicht unterstützt. Die Schlüsselrotation muss manuell erfolgen, indem Sie neue Schlüssel erstellen und von Ihrem Anwendungscode verwendete AWS-KMS-Schlüsselaliasnamen neu zuweisen, um die neuen Schlüssel für zukünftige Verschlüsselungsvorgänge zu verwenden.

Ja, AWS KMS erfordert keinen exklusiven Zugang zu Ihrem CloudHSM-Cluster. Wenn Sie bereits einen Cluster besitzen, können Sie ihn als benutzerdefinierten Schlüsselspeicher verwenden und für andere Anwendungen einsetzen. Wenn Ihr Cluster jedoch intensive AWS-KMS-fremde Workloads unterstützt, werden Sie möglicherweise einen reduzierten Durchsatz für Vorgänge mit KMS-Schlüsseln in Ihrem benutzerdefinierten Schlüsselspeicher verzeichnen. Gleichermaßen kann sich eine hohe AWS-KMS-Anforderungsrate an Ihren benutzerdefinierten Schlüsselspeicher auf andere Anwendungen auswirken.

Auf der AWS-CloudHSM-Website finden Sie einen Überblick über den Service. Weitere Informationen zur Konfiguration und Nutzung des Services finden Sie im Benutzerhandbuch für AWS CloudHSM.

Ein externer Schlüsselspeicher ist ein benutzerdefinierter Schlüsselspeicher, der von einer externen Schlüsselverwaltungsinfrastruktur unterstützt wird, die Sie außerhalb von AWS besitzen und verwalten. Alle Ver- oder Entschlüsselungsvorgänge, die einen KMS-Schlüssel in einem externen Schlüsselspeicher verwenden, werden in Ihrem Schlüsselmanager mit kryptografischen Schlüsseln und Operationen durchgeführt, die unter Ihrer Kontrolle stehen und für AWS physisch unzugänglich sind.

XKS kann Ihnen helfen, Regeln oder Vorschriften einzuhalten, die verlangen, dass Verschlüsselungsschlüssel außerhalb von AWS unter Ihrer Kontrolle gespeichert und verwendet werden.

Anfragen an AWS KMS von integrierten AWS-Services in Ihrem Namen oder von Ihren eigenen Anwendungen werden an eine Komponente in Ihrem Netzwerk, den XKS-Proxy, weitergeleitet. Der XKS Proxy ist eine Open-Source-API-Spezifikation, die Ihnen und Ihrem Schlüsselverwaltungsanbieter hilft, einen Service zu entwickeln, der diese Anfragen annimmt und sie an Ihre Schlüsselverwaltungsinfrastruktur weiterleitet, um deren Schlüssel für die Ver- und Entschlüsselung zu verwenden.

Thales, Entrust, Atos, Fortanix, DuoKey, Securonix, Utimaco, Salesforce, T-Systems und HashiCorp verfügen über Lösungen, die sich in die XKS-Proxy-Spezifikation integrieren lassen. Informationen zur Verfügbarkeit, zu den Preisen und zur Verwendung der Lösungen dieser Anbieter finden Sie in der jeweiligen Dokumentation. Wir ermutigen Sie und Ihren Schlüsselmanagement-Infrastrukturpartner, die Open-Source-Spezifikation von XKS Proxy zu nutzen, um eine Lösung zu entwickeln, die Ihren Anforderungen entspricht. Die API-Spezifikation für XKS Proxy ist hier veröffentlicht.

Externe Schlüssel unterstützen die folgenden symmetrischen Verschlüsselungsoperationen: Verschlüsseln, Wiederverschlüsseln, Entschlüsseln und Generieren von Datenschlüsseln.

Sie können XKS-Schlüssel verwenden, um Daten in jedem AWS-Service zu verschlüsseln, der mit AWS KMS integriert ist, indem Sie vom Kunden verwaltete Schlüssel verwenden. Sehen Sie sich die Liste der unterstützten Services hier an. AWS-Services rufen die AWS-KMS-GenerateDataKey-API auf, um einen eindeutigen Klartext-Datenschlüssel zur Verschlüsselung Ihrer Daten anzufordern. Der Datenschlüssel im Klartext wird zusammen mit einer verschlüsselten Kopie des Datenschlüssels an den Service zurückgesendet, die zusammen mit Ihren verschlüsselten Daten gespeichert wird. Um die verschlüsselte Kopie des Datenschlüssels zu erstellen, wird der Klartext-Datenschlüssel zunächst mit einem Schlüssel verschlüsselt, der in AWS KMS gespeichert ist und nur für Ihr AWS-Konto gilt. Dieser verschlüsselte Datenschlüssel wird dann an Ihre XKS-Proxy-Implementierung weitergeleitet, die mit Ihrem externen Schlüsselmanager verbunden ist, um ein zweites Mal unter dem Schlüssel verschlüsselt zu werden, den Sie in Ihrem externen Schlüsselmanager definieren. Der resultierende doppelt verschlüsselte Datenschlüssel wird in der Antwort auf die API-Anfrage GenerateDataKey zurückgegeben.

Die Netzwerkverbindung zwischen AWS KMS, Ihrer XKS Proxy-Implementierung und Ihrem externen Schlüsselmanager sollte mit einem Punkt-zu-Punkt-Verschlüsselungsprotokoll wie TLS geschützt sein. Um jedoch Ihre Daten zu schützen, die AWS KMS verlassen, bis sie Ihren externen Schlüsselmanager erreichen, verschlüsselt AWS KMS sie zunächst mit einem intern verwalteten KMS-Schlüssel in Ihrem Konto, der für jeden in Ihrem externen Schlüsselspeicher definierten KMS-Schlüssel spezifisch ist. Der resultierende Chiffriertext wird an Ihren externen Schlüsselmanager weitergeleitet, der ihn mit dem Schlüssel in Ihrem externen Schlüsselmanager verschlüsselt. Die doppelte Verschlüsselung bietet die Sicherheitskontrolle, dass kein verschlüsselter Text jemals entschlüsselt werden kann, ohne das Schlüsselmaterial in Ihrem externen Schlüsselmanager zu verwenden. Es bietet auch die Sicherheitskontrolle, dass der Chiffriertext, der das AWS-Netzwerk verlässt, mit den FIPS 140 zertifizierten AWS KMS HSMs verschlüsselt wird. Da Ihr externer Schlüsselmanager zum Entschlüsseln der Daten verwendet werden muss, werden Ihre verschlüsselten Daten unzugänglich, wenn Sie den Zugriff auf AWS KMS widerrufen.

Ja. XKS-Schlüssel können auch innerhalb Ihrer eigenen Anwendungen verwendet werden, wenn Sie eine clientseitige symmetrische Verschlüsselungslösung verwenden, die AWS KMS als Schlüsselanbieter nutzt. AWS-Open-Source-clientseitige Verschlüsselungslösungen wie das AWS Encryption SDK, S3 Encryption Client und DynamoDB Encryption Client unterstützen XKS-Schlüssel.

Alle XKS-Schlüssel müssen als neue Schlüssel in KMS erstellt werden. Sie können bestehende KMS-Schlüssel nicht in XKS-Schlüssel migrieren, die in Ihrem externen Schlüsselmanager gehostet werden.

Sie können vorhandene Daten unter neu generierten XKS-Schlüsseln erneut verschlüsseln, vorausgesetzt, der AWS-Service oder Ihre eigene Anwendung unterstützt diese Aktion. Viele AWS-Services helfen Ihnen dabei, eine verschlüsselte Ressource zu kopieren und einen neuen KMS-Schlüssel zu bestimmen, mit dem die Kopie verschlüsselt wird. Sie können den XKS-Schlüssel im COPY-Befehl konfigurieren, der vom AWS-Service bereitgestellt wird. Sie können client-seitig verschlüsselte Daten in Ihren eigenen Anwendungen wieder verschlüsseln, indem Sie die KMS ReEncrypt API aufrufen und den XKS-Schlüssel konfigurieren.

Wie alle kundenverwaltete Schlüssel kosten auch die XKS-Schlüssel 1 USD pro Monat und Schlüssel, bis sie gelöscht werden. Anfragen unter XKS-Schlüsseln werden zum gleichen Tarif wie alle anderen symmetrischen AWS KMS-Schlüssel berechnet. Weitere Informationen zu den Preisen finden Sie auf der AWS-KMS-Preisseite.

Ja. Die automatische Schlüsselrotation wird von der XKS-Spezifikation unterstützt und ist eine Funktion, die von den meisten Anbietern bereitgestellt wird, die XKS unterstützen. Die automatische Rotation für XKS-Schlüssel erfolgt vollständig im externen Schlüsselmanager und funktioniert ähnlich wie die automatische Schlüsselrotation für AWS-KMS-Schlüssel, die innerhalb von KMS erstellt und verwaltet werden. Wenn Sie einen rotierten KMS XKS-Schlüssel zur Verschlüsselung von Daten verwenden, verwendet Ihr externer Schlüsselmanager das aktuelle Schlüsselmaterial. Wenn Sie den rotierten XKS-Schlüssel zum Entschlüsseln von Geheimtext verwenden, verwendet Ihr externer Schlüsselmanager die Version des Schlüsselmaterials, mit der er verschlüsselt wurde. Solange frühere XKS-Schlüssel, die zur Erstellung früherer Geheimtexte verwendet wurden, noch im externen Schlüsselmanager aktiviert sind, können Sie unter diesen Versionen Ihrer XKS-Schlüssel erfolgreich eine Entschlüsselungs-API-Anfrage stellen.

Bei Services, die keine Schlüssel zwischenspeichern, schlägt der nächste API-Aufruf, der diesen XKS-KMS-Schlüssel verwendet, fehl. Einige Services implementieren das Zwischenspeichern von Datenschlüsseln oder andere Verfahren zur Schlüsselableitung aus Gründen der Leistung, der Latenz oder der KMS-Kostenverwaltung. Die Zwischenspeicherung dieser Schlüssel kann zwischen 5 Minuten und 24 Stunden variieren. Jede geschützte Ressource, die gerade in Gebrauch ist (z. B. eine RDS-Datenbank oder eine EC2-Instance), wird anders reagieren, nachdem Sie den Zugriff auf den Schlüssel verweigert haben. Einzelheiten finden Sie in der entsprechenden AWS-Service-Dokumentation.

Um sich bei Ihrem externen Schlüsselspeicher-Proxy zu authentifizieren, signiert AWS KMS alle Anfragen an den Proxy mit AWS SigV4-Anmeldeinformationen, die Sie auf Ihrem Proxy konfigurieren und an KMS weitergeben. AWS KMS authentifiziert Ihren externen Schlüsselspeicher-Proxy mit serverseitigen TLS-Zertifikaten. Optional kann Ihr Proxy gegenseitiges TLS aktivieren, um zusätzlich sicherzustellen, dass er nur Anfragen von AWS KMS annimmt.

Alle üblichen AWS KMS-Autorisierungsmechanismen – IAM-Richtlinien, AWS KMS-Schlüsselrichtlinien, Zuweisungen –, die Sie mit anderen KMS-Schlüsseln verwenden, funktionieren auf die gleiche Weise für KMS-Schlüssel in externen Schlüsselspeichern.

Darüber hinaus haben Sie und/oder Ihre externen Schlüsselverwaltungspartner die Möglichkeit, eine zweite Ebene von Autorisierungskontrollen zu implementieren, die auf Anfrage-Metadaten basieren, die in jeder von AWS KMS an den XKS Proxy gesendeten Anfrage enthalten sind. Diese Metadaten umfassen den aufrufenden AWS-Benutzer/die aufrufende AWS-Rolle, den ARN des KMS-Schlüssels und die spezifische KMS-API, die angefordert wurde. Damit können Sie eine differenzierte Autorisierungsrichtlinie für die Verwendung eines Schlüssels in Ihrem externen Schlüsselmanager anwenden, die über das einfache Vertrauen in jede Anfrage von AWS KMS hinausgeht. Die Wahl der Durchsetzung von Richtlinien mit Hilfe dieser Anfrageattribute bleibt Ihren individuellen XKS-Proxy-Implementierungen überlassen.

Die eindeutige ID, die für jede an AWS KMS gerichtete Anfrage mit XKS-Schlüsseln generiert wird, wird auch an den XKS-Proxy weitergeleitet. Sie können die Protokolldaten (falls verfügbar) von Ihrem XKS-Proxy oder externen Schlüsselmanager verwenden, um die an AWS KMS gestellten Anfragen mit denen an Ihren externen Schlüsselmanager abzugleichen. Mit diesem Feature können Sie überprüfen, ob alle Anfragen zur Verwendung von Schlüsseln in Ihrem externen Schlüsselmanager von einem Anruf stammen, den Sie entweder direkt oder über einen integrierten AWS-Service an AWS KMS gerichtet haben.

Verfügbarkeitsrisiko: Sie sind verantwortlich für die Verfügbarkeit des XKS Proxy und des externen Schlüsselmaterials. Dieses System muss hochverfügbar sein, um sicherzustellen, dass AWS KMS immer dann, wenn Sie einen XKS-Schlüssel zum Entschlüsseln einer verschlüsselten Ressource oder zum Verschlüsseln neuer Daten benötigen, erfolgreich eine Verbindung zum XKS-Proxy herstellen kann, der seinerseits eine Verbindung zu Ihrem externen Schlüsselmanager herstellen kann, um die erforderliche kryptografische Operation mit dem Schlüssel durchzuführen. Angenommen, Sie haben ein EBS-Volume mit einem XKS-Schlüssel verschlüsselt und möchten nun eine EC2-Instance starten und dieses verschlüsselte Volume anhängen. Der EC2-Service gibt den eindeutigen verschlüsselten Datenschlüssel für dieses Volume an AWS KMS weiter, um ihn zu entschlüsseln, damit er im flüchtigen Speicher der Nitro-Karte bereitgestellt werden kann, um Lese-/Schreibvorgänge auf dem Volume zu entschlüsseln und zu verschlüsseln. Wenn Ihr XKS Proxy oder externer Schlüsselmanager nicht verfügbar ist, um den Volume-Schlüssel zu entschlüsseln, kann Ihre EC2-Instance nicht gestartet werden. Bei dieser Art von Fehlern gibt AWS KMS eine KMSInvalidStateException zurück, die besagt, dass der XKS-Proxy nicht verfügbar ist. Es liegt nun an Ihnen, anhand der von KMS gelieferten Fehlermeldungen festzustellen, warum Ihr XKS Proxy und Ihr Schlüsselmanager nicht verfügbar sind.

Haltbarkeitsrisiko: Da Schlüssel in Systemen außerhalb von AWS unter Ihrer Kontrolle stehen, sind Sie allein für die Haltbarkeit aller externen Schlüssel verantwortlich, die Sie erstellen. Wenn der externe Schlüssel für einen XKS-Schlüssel dauerhaft verloren geht oder gelöscht wird, ist der gesamte unter dem XKS-Schlüssel verschlüsselte Geheimtext nicht wiederherstellbar.

Leistungsrisiko: Sie sind dafür verantwortlich, dass Ihre XKS-Proxy- und externe Schlüsselspeicher-Infrastruktur mit ausreichenden Leistungsmerkmalen ausgestattet ist, um Ihre Anforderungen zu erfüllen. Da jede Anfrage mit XKS-Schlüsseln eine Verbindung zu Ihrem externen Schlüsselspeicher erfordert, kann Ihr XKS-Proxy zu einem Engpass werden, wenn die Anfragerate von AWS KMS die Anfragerate übersteigt, die Ihr XKS-Proxy oder externer Schlüsselmanager unterstützen kann. Wenn die verstrichene Zeit einer einzelnen Anfrage (einschließlich eines Wiederholungsversuchs) von AWS KMS an Ihren XKS-Proxy mehr als 500 ms* beträgt, gibt AWS KMS einen 400-Fehler an den aufrufenden Client zurück und teilt damit mit, dass Ihr XKS-Schlüssel nicht verfügbar ist und der aufrufende Client es nicht erneut versuchen sollte. Dieses Verhalten soll das Risiko minimieren, dass vorgelagerte AWS-Services oder Ihre eigenen Anwendungen auf sporadisch auftretende übermäßige Latenzzeiten reagieren müssen, die durch Verbindungsprobleme zu Ihrer Infrastruktur verursacht werden.

*AWS KMS wird bei jeder Anfrage, die 250ms dauert, einen einmaligen Wiederholungsversuch unternehmen. Wenn die Wiederholungsanfrage ebenfalls mehr als 250 ms dauert, wird ein 400-Fehler an den aufrufenden Client zurückgegeben.

Da AWS die umfassende Verfügbarkeit der Verbindung zwischen AWS KMS und Ihrer externen Schlüsselspeicherinfrastruktur nicht kontrollieren kann, schließen wir die Verwendung von XKS in unserem öffentlichen KMS-Verfügbarkeits-SLA ausdrücklich aus. Außerdem sind XKS-Schlüssel in der Verfügbarkeits-SLA für jeden AWS-Service ausgeschlossen, in dem ein XKS-Schlüssel von Ihnen zur Verschlüsselung von Daten innerhalb des Services konfiguriert wurde.