Häufig gestellte Fragen zum AWS Key Management Service

Die folgenden häufig gestellten Fragen gelten nicht für AWS Key Management Service (KMS) in der Region AWS China (Peking), die von Sinnet betrieben wird, sowie in der Region AWS China (Ningxia), die von NWCD betrieben wird. Informationen bezüglich dieser beiden Regionen in China finden Sie unter diesem Link zu häufig gestellten Fragen.

AWS KMS ist ein verwalteter Service, der Ihnen hilft, die für kryptografische Vorgänge verwendeten Schlüssel problemloser zu erstellen und zu steuern. Der Service bietet eine hochverfügbare Schlüsselgenerierungs-, Speicherungs-, Verwaltungs- und Überwachungslösung zum Verschlüsseln oder digitalen Signieren von Daten innerhalb Ihrer eigenen Anwendungen und zur Steuerung der Verschlüsselung von Daten in AWS-Services.

Wenn Sie für das Sichern von Daten in AWS-Services verantwortlich sind, sollten Sie AWS KMS für die zentrale Verwaltung der Verschlüsselungsschlüssel verwenden, die den Zugriff auf Ihre Daten steuern. Wenn Sie Entwickler sind und Daten in Ihren Anwendungen verschlüsseln müssen, sollten Sie das AWS Encryption SDK mit AWS KMS verwenden, damit die symmetrischen Verschlüsselungsschlüssel in Ihrem Code problemloser generiert, verwendet und geschützt werden können. Wenn Sie als Entwickler Daten mithilfe asymmetrischer Schlüssel digital signieren oder verifizieren müssen, sollten Sie den Service verwenden, um die benötigten privaten Schlüssel zu erstellen und zu verwalten. Wenn Sie nach einer skalierbaren Schlüsselverwaltungs-Infrastruktur suchen, die Ihre Entwickler und die wachsende Anzahl von deren Anwendungen unterstützt, sollten Sie den Service verwenden, um Ihre Lizenzgebühren und den betrieblichen Aufwand zu reduzieren. Wenn Sie für das Sicherstellen der Datensicherheit für gesetzliche oder Compliance-Zwecke verantwortlich sind, sollten Sie den Service verwenden, da er dazu beiträgt, den konsistenten Schutz Ihrer Daten sicherzustellen. Er kann außerdem für verschiedene branchenspezifische und regionale Compliance-Systeme eingesetzt werden.

Für einen einfachen Einstieg in die Nutzung von AWS KMS wählen Sie am besten die Verschlüsselung Ihrer Daten innerhalb des unterstützten AWS-Service mit AWS-eigenen Stammschlüsseln, die automatisch von jedem Service erstellt werden. Wenn Sie die volle Kontrolle über die Verwaltung Ihrer Schlüssel wünschen, einschließlich der Möglichkeit, den Zugriff auf Schlüssel über Konten oder Dienste hinweg zu teilen, können Sie Ihre eigenen AWS-KMS-Kunden verwalteten Schlüssel in AWS KMS erstellen. Sie können die erstellten KMS-Schlüssel auch direkt in Ihren eigenen Anwendungen verwenden. Sie können auf AWS KMS über die KMS-Konsole zugreifen, die unter Sicherheit, Identität und Compliance auf der AWS-Services-Startseite der AWS-KMS-Konsole gruppiert ist. Sie können auf AWS KMS-APIs auch direkt über die AWS KMS Command Line Interface (CLI) oder, für einen programmgesteuerten Zugriff, über das AWS SDK zugreifen. AWS KMS-APIs können auch indirekt verwendet werden, um Daten innerhalb Ihrer eigenen Anwendungen mithilfe des AWS Encryption SDK zu verschlüsseln. Weitere Informationen finden Sie auf der Seite Erste Schritte.

Die Verfügbarkeit ist auf unserer globalen Seite Produkte und Services nach Region aufgelistet.

Sie können die folgenden Schlüsselverwaltungs-Features ausführen:

• Erstellen symmetrischer, asymmetrischer und HMAC-Schlüssel, bei denen das Schlüsselmaterial ausschließlich innerhalb des Services verwendet wird
• Erstellen Sie symmetrische Schlüssel, bei denen das Schlüsselmaterial in einem benutzerdefinierten Schlüsselspeicher unter Ihrer Kontrolle generiert und verwendet wird, der entweder durch AWS CloudHSM oder in Ihrem eigenen externen Schlüsselmanager, außerhalb von AWS, gesichert ist.
• Importieren Sie Ihr eigenes symmetrisches, asymmetrisches und HMAC-Schlüsselmaterial zur Verwendung in unterstützten AWS-Services und Ihrer eigenen Anwendung
• Legen Sie fest, welche AWS-Identity-and-Access-Management-(IAM)-Benutzer und -Rollen Schlüssel verwalten können
• Definieren, welche IAM-Benutzer und -Rollen Schlüssel zur Ver- und Entschlüsselung von Daten verwenden dürfen
• Auswählen, dass Schlüssel, die vom Service generiert wurden, automatisch jährlich rotiert werden
• Vorübergehendes Deaktivieren von Schlüsseln, sodass niemand sie verwenden kann
• Reaktivieren deaktivierter Schlüssel
• Zeitliches Planen der Löschung nicht mehr verwendeter Schlüssel
• Überwachen der Verwendung von Schlüsseln durch Prüfung der Protokolle in AWS CloudTrail

Sie können die Verwendung des Service durch Anfordern der Erstellung eines AWS-KMS-Schlüssel starten. Sie kontrollieren den Lebenszyklus jedes vom Kunden verwalteten KMS-Schlüssels und wer ihn verwenden oder verwalten kann. Sobald Sie einen KMS-Schlüssel erstellt haben, können Sie Daten direkt an den Service AWS KMS übermitteln, um sie zu verschlüsseln, zu entschlüsseln, zu signieren, zu verifizieren oder um einen HMAC mit diesem KMS-Schlüssel zu erzeugen oder zu verifizieren. Sie legen Nutzungsrichtlinien für diese Schlüssel fest, die bestimmen, welche Benutzer welche Aktionen unter welchen Bedingungen ausführen können.

AWS-Services und clientseitige Toolkits, die in AWS KMS integriert sind, verwenden zum Schutz Ihrer Daten eine Methode namens Umschlagsverschlüsselung. Mithilfe dieser Methode generiert AWS KMS Datenschlüssel, die verwendet werden, um Daten lokal im AWS-Service oder in Ihrer Anwendung zu verschlüsseln. Die Datenschlüssel sind selbst unter einem von Ihnen definierten AWS-KMS-Schlüssel verschlüsselt. Datenschlüssel werden von AWS KMS nicht aufbewahrt oder verwaltet. AWS-Services verschlüsseln Ihre Daten und speichern eine verschlüsselte Kopie des Datenschlüssels zusammen mit den verschlüsselten Daten. Wenn ein Service Ihre Daten entschlüsseln muss, fordert er AWS KMS zur Entschlüsselung des Datenschlüssels mithilfe des KMS-Schlüssels an. Wenn der Benutzer, der die Daten vom AWS-Service anfordert, zur Entschlüsselung im Rahmen des KMS-Schlüssels berechtigt ist, empfängt der AWS-Service den entschüsselten Datenschlüssel von AWS KMS. Damit kann der AWS-Service dann Ihre Daten entschlüsseln und als Klartext zurückgeben. Alle Anforderungen zur Verwendung Ihrer KMS-Schlüssel werden in CloudTrail protokolliert, sodass Sie immer herausfinden können, wer welchen Schlüssel wann und in welchem Kontext verwendet hat.

In der Regel gibt es drei Szenarien zur Datenverschlüsselung mit AWS KMS. Erstens können Sie AWS KMS-APIs direkt zur Ver- und Entschlüsselung von Daten mithilfe Ihrer im Service gespeicherten KMS-Schlüssel verwenden. Zweitens können Sie Ihre Daten von AWS-Services mithilfe der im Service gespeicherten KMS-Schlüssel verschlüsseln lassen. In diesem Fall werden Daten mit Datenschlüsseln verschlüsselt, die durch Ihre KMS-Schlüssel geschützt werden. Drittens können Sie das AWS Encryption SDK verwenden, das in AWS KMS integriert ist, um Ihre eigenen Anwendungen zu verschlüsseln, unabhängig davon, ob sie in AWS betrieben werden oder nicht.

AWS KMS ist nahtlos in die meisten anderen AWS-Services integriert, um das Verschlüsseln von Daten in diesen Services einfacher zu gestalten. In einigen Fällen werden Daten standardmäßig mit Schlüsseln verschlüsselt, die in AWS KMS gespeichert sind, sich aber im Besitz des jeweiligen AWS-Service befinden und von diesem verwaltet werden. In vielen Fällen sind die AWS-KMS-Schlüssel in Ihrem Besitz und werden von Ihnen innerhalb Ihres Kontos verwaltet. Bei einigen Services haben Sie die Wahl, ob Sie die Schlüssel selbst verwalten wollen oder ob Sie den Service mit der Verwaltung der Schlüssel beauftragen wollen. Hier finden Sie die Liste der AWS-Services, die aktuell in AWS KMS integriert sind. Weitere Informationen darüber, wie integrierte Services AWS KMS verwenden, finden Sie im AWS-KMS-Entwicklerhandbuch.

AWS KMS unterstützt zwar die direkte Verschlüsselung der gesendeten Daten bis zu 4 KB, die Umschlagverschlüsselung bietet jedoch erhebliche Leistungsvorteile. Die Daten, die Sie direkt mit AWS KMS verschlüsseln, müssen im Netzwerk übertragen werden. Die Umschlagsverschlüsselung reduziert die Netzwerklast, da nur die Anforderung und Lieferung des weitaus kleineren Datenschlüssels über das Netzwerk übertragen werden. Der Datenschlüssel wird lokal in Ihrer Anwendung oder vom verschlüsselnden AWS-Service verwendet. Damit entfällt die Übertragung des gesamten Datenblocks an AWS KMS und die damit verbundene Netzwerklatenz.

Sie können auswählen, welchen KMS-Schlüssel ein AWS-Service verwenden soll, wenn er Daten für Sie verschlüsselt. Diese werden als kundenverwaltete KMS-Schlüssel bezeichnet, über die Sie die volle Kontrolle haben. Sie definieren die Zugangssteuerung und Nutzungsrichtlinie für jeden Schlüssel und können anderen Konten und Services Berechtigungen zur Nutzung gewähren. Zusätzlich zu den vom Kunden verwalteten Schlüsseln bietet AWS KMS auch zwei Arten von Schlüsseln, die von AWS verwaltet werden: (1) AWS-verwaltete KMS-Schlüssel sind Schlüssel, die in Ihrem Konto erstellt, aber von AWS verwaltet werden, und (2) AWS-eigene Schlüssel sind Schlüssel, die vollständig von AWS-Konten aus verwaltet werden. Sie können von AWS verwaltete Schlüssel in Ihrem Konto verfolgen. Die gesamte Nutzung wird in CloudTrail protokolliert, Sie haben aber keine direkte Kontrolle über die Schlüssel selbst. AWS-eigene Schlüssel sind am stärksten automatisiert und ermöglichen die Verschlüsselung Ihrer Daten innerhalb von AWS, bieten jedoch keine Richtlinienkontrollen oder CloudTrail-Protokolle über ihre Schlüsselaktivitäten.

Mit der Erstellung Ihres eigenen KMS-Schlüssels haben Sie mehr Kontrolle als mit von AWS verwalteten KMS-Schlüsseln. Wenn Sie einen symmetrischen, vom Kunden verwalteten KMS-Schlüssel erstellen, können Sie wählen, ob Sie von AWS KMS generiertes Schlüsselmaterial verwenden, das innerhalb eines AWS-CloudHSM-Clusters oder eines externen Schlüsselmanagers (über den benutzerdefinierten Schlüsselspeicher) generiert wurde, oder ob Sie Ihr eigenes Schlüsselmaterial importieren. Sie können einen Alias und eine Beschreibung für den Schlüssel festlegen und auswählen, ob der Schlüssel einmal im Jahr automatisch rotiert werden soll, wenn er von AWS KMS erzeugt wurde. Sie können auch alle Berechtigungen für den Schlüssel festlegen und so steuern, wer den Schlüssel verwenden oder verwalten darf. Bei asymmetrischen kundenverwalteten KMS-Schlüsseln gibt es eine Reihe von Vorsichtsmaßnahmen bezüglich der Verwaltung: Das Schlüsselmaterial kann nur innerhalb von AWS-KMS-HSMs generiert werden. Außerdem ist keine automatische Schlüsselrotation möglich.

Ja. Sie können auswählen, dass AWS KMS KMS-Schlüssel automatisch jährlich rotiert, solange diese Schlüssel innerhalb von AWS-KMS-HSMs generiert wurden. Die automatische Schlüsselrotation wird nicht für importierte Schlüssel, asymmetrische Schlüssel oder Schlüssel unterstützt, die mithilfe der AWS KMS-Funktion für benutzerdefinierte Schlüsselspeicher in einem CloudHSM-Cluster generiert wurden. Wenn Sie sich dafür entscheiden, Schlüssel in AWS KMS oder asymmetrische Schlüssel zu importieren oder einen benutzerdefinierten Schlüsselspeicher zu verwenden, können Sie diese 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.

Wenn Sie sich dafür entscheiden, dass AWS KMS die Schlüssel automatisch rotiert, müssen Sie Ihre Daten nicht erneut verschlüsseln. AWS KMS bewahrt frühere Schlüsselversionen automatisch auf, sodass auch unter einer älteren Schlüsselversion verschlüsselte Daten entschlüsselt werden können. Alle neuen Verschlüsselungsanfragen für einen Schlüssel in AWS KMS werden mit der neuesten Version des Schlüssels verschlüsselt. Wenn Sie Ihre importierten oder benutzerdefinierten Schlüsselspeicherschlüssel manuell rotieren, müssen Sie Ihre Daten möglicherweise erneut verschlüsseln, je nachdem, ob Sie sich dafür entscheiden, alte Versionen von Schlüsseln verfügbar zu halten.

Wenn Sie Ihre importierten oder benutzerdefinierten Schlüsselspeicherschlüssel manuell rotieren, müssen Sie Ihre Daten möglicherweise erneut verschlüsseln, je nachdem, ob Sie alte Versionen der Schlüssel verfügbar halten wollen.

Ja. Sie können einen Zeitplan zur Löschung für einen AWS-KMS-Schlüssel, den Sie in AWS KMS erstellt haben, und verknüpfte Metadaten festlegen, und zwar mit einer konfigurierbaren Wartezeit von 7 bis 30 Tagen. Diese Wartezeit hilft Ihnen, die Auswirkungen des Löschens eines Schlüssels auf Ihre Anwendungen und Benutzer, die davon abhängig sind, zu überprüfen. Die standardmäßige Wartezeit beträgt 30 Tage. Sie können die Schlüssellöschung während der Wartezeit stornieren. Wenn ein Schlüssel zur Löschung vorgesehen ist, kann er erst wieder verwendet werden, wenn die Löschung während der Wartezeit storniert wird. Der Schlüssel wird am Ende der konfigurierbaren Wartezeit gelöscht, wenn Sie die Löschung nicht stornieren. Nachdem der Schlüssel gelöscht wurde, können Sie ihn nicht mehr verwenden. Unter einem gelöschten Stamm-Schlüssel geschützte Daten sind nicht mehr zugänglich.

Für Kunden-AWS-KMS-Schlüssel mit importiertem Schlüsselmaterial können Sie das Schlüsselmaterial auf zwei Arten löschen, ohne die AWS-KMS-Schlüssel-ID oder die Metadaten zu löschen. Erstens können Sie Ihr importiertes Schlüsselmaterial nach Belieben ohne eine Wartezeit löschen. Zweitens können Sie beim Importieren des Schlüsselmaterials in den AWS-KMS-Schlüssel eine Ablaufzeit festlegen, wie lange AWS Ihr importiertes Schlüsselmaterial verwenden kann, bevor es gelöscht wird. Sie können Ihr Schlüsselmaterial erneut in den AWS-KMS-Schlüssel importieren, wenn Sie es erneut verwenden müssen.

Ja. AWS KMS wird in AWS SDKs, im AWS-Verschlüsselungs-SDK, bei der clientseitigen Verschlüsselung von Amazon DynamoDB und im Amazon-Simple-Storage-Service-Verschlüsselungsclient (S3) unterstützt. Das erleichtert die Verschlüsselung von Daten in Ihren eigenen Anwendungen, unabhängig davon, wo diese ausgeführt werden. Besuchen Sie die Webseiten AWS Crypto Tools und Entwickeln auf AWS für weitere Informationen.

Sie können bis zu 100 000 KMS-Schlüssel pro Konto und Region erstellen. Da sowohl aktivierte als auch deaktivierte KMS-Schlüssel hinsichtlich des Limits berücksichtigt werden, sollten Sie deaktivierte Schlüssel, die Sie nicht mehr verwenden, löschen. Für Sie zur Verwendung in unterstützten AWS-Services erstellte, von AWS verwaltete KMS-Schlüssel zählen bei dieser Beschränkung nicht mit. Die Anzahl der Datenschlüssel, die von einem KMS-Schlüssel abgeleitet und in Ihrer Anwendung oder für Sie von AWS-Services zur Verschlüsselung von Daten verwendet werden, ist nicht beschränkt. Eine Erhöhung des Limits für KMS-Schlüssel können Sie im AWS Support Center anfordern.

Nein. Alle KMS-Schlüssel oder der private Teil eines asymmetrischen KMS-Schlüssels kann nicht aus den HSMs in Klartext exportiert werden. Nur der öffentliche Teil eines asymmetrischen KMS-Schlüssel kann aus der Konsole oder durch Aufrufen der „GetPublicKey“-API exportiert werden.

Ja. Die symmetrischen Datenschlüssel können mithilfe der GenerateDataKey-API oder der GenerateDataKeyWithoutPlaintext-API exportiert werden. Außerdem können der private und der öffentliche Teil asymmetrischer Datenschlüsselpaare aus AWS KMS mithilfe der GenerateDataKeyPair-API oder der GenerateDataKeypairWithoutPlaintext-API exportiert werden.

Der symmetrische Datenschlüssel oder der private Teil des asymmetrischen Datenschlüssels wird unter dem symmetrischen KMS-Schlüssel verschlüsselt, den Sie definieren, wenn Sie die Generierung des Datenschlüssels durch AWS KMS anfordern.

Der Hauptgrund für das Verwenden des AWS-Private-CA-Service ist die Bereitstellung einer öffentlichen Schlüsselinfrastruktur (PKI), um Entitäten zu identifizieren und Netzwerkverbindungen zu sichern. PKI stellt Prozesse und Mechanismen bereit, vor allem unter Verwendung von X.509-Zertifikaten, um kryptografische Vorgänge für öffentliche Schlüssel mit einer Struktur zu umgeben. Zertifikate stellen eine Zuordnung zwischen einer Identität und einem öffentlichen Schlüssel bereit. Der Zertifizierungsprozess, in dem eine Zertifizierungsstelle ein Zertifikat ausgibt, ermöglicht der vertrauenswürdigen Zertifizierungsstelle die Überprüfung der Identität einer anderen Entität durch Signieren eines Zertifikats. PKI stellt Identität, dezentrale Vertrauensstellung und Schlüssellebenszyklus-Verwaltung sowie den Zertifikatsstatus bereit, der durch Widerruf weitergegeben wird. Durch diese Funktionen werden den zugrunde liegenden asymmetrischen kryptografischen Schlüsseln und Algorithmen, die durch AWS KMS bereitgestellt werden, wichtige Prozesse und Infrastrukturen hinzugefügt.

AWS Private CA hilft Ihnen das Ausstellen von Zertifikaten zum Identifizieren von Web- und Anwendungsservern, Service-Meshes, VPN-Benutzern, internen API-Endpunkten und AWS-IoT-Core-Geräten. Zertifikate helfen Ihnen die Identität dieser Ressourcen einzurichten und verschlüsselte TLS-/SSL-Kommunikationskanäle zu erstellen. Falls Sie erwägen, asymmetrische Schlüssel für die TLS-Terminierung auf Web- oder Anwendungsservern, Elastic Load Balancers, API-Gateway-Endpunkten, Amazon-Elastic-Compute-Cloud-Instances (EC2) oder Containern zu verwenden, sollten Sie AWS Private CA zum Ausstellen von Zertifikaten und Bereitstellen einer PKI-Infrastruktur verwenden.

Im Gegensatz dazu hilft Ihnen AWS KMS asymmetrische Schlüssel für digitale Signier- und/oder Verschlüsselungsvorgänge, die keine Zertifikate benötigen, zu generieren, zu verwalten und zu verwenden. Während Zertifikate die Überprüfung der Identitäten von Sender und Empfänger unter nicht vertrauenswürdigen Parteien ermöglichen können, ist die Art der grundlegenden asymmetrischen Vorgänge, die von AWS KMS angeboten wird, normalerweise dann hilfreich, wenn Sie über andere Mechanismen zum Überprüfen von Identitäten verfügen oder diese nicht überprüft werden müssen, um den gewünschten Sicherheitsvorteil zu erhalten.

AWS KMS stellt keine systemeigene Integration für andere kryptografische API-Anbieter bereit. Sie müssen AWS-KMS-APIs direkt oder durch das AWS SDK verwenden, um Signier- und Verschlüsselungsfunktionen in Ihren Anwendungen zu integrieren.

Ja. Das AWS KMS SLA sieht eine Service-Gutschrift vor, wenn Ihr monatlicher Verfügbarkeitsprozentsatz in jedem Abrechnungszyklus unter unserer Service-Verpflichtung liegt.

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 HSM-Cluster mit einem einzelnen Mandanten 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 verwenden, um eine Vielzahl von Anwendungsfällen zu unterstützen, z. B. 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. Am Monatsende 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 AWS-KMS-Preisseite.

*API-Anforderungen mit asymmetrischen KMS-Schlüsseln und API-Anfragen an die APIs GenerateDataKeyPair und GenerateDataKeyPairWithoutPlaintext sind von der kostenlosen Stufe ausgeschlossen.

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, darunter 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 erneut 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 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 AWS-KMS-Limits.

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.

Der benutzerdefinierte Schlüsselspeicher von AWS KMS kombiniert die Konfigurationsmöglichkeiten vonCloudHSM 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 Ratschläge 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 AWS-KMS-Entwicklerhandbuch.

DiePreise 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-Benutzer, die einen benutzerdefinierten Schlüsselspeicher verwenden möchten, müssen einen AWS-CloudHSM-Cluster einrichten, HSMs hinzufügen, HSMs-Benutzer verwalten und möglicherweise HSMs aus einem Backup wiederherstellen. Diese Aufgaben sind sicherheitsrelevant, und Sie können überprüfen, ob Sie über die entsprechenden Ressourcen und organisatorischen Kontrollen verfügen.

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-Websitefinden Sie einen Überblick über den Service. Weitere Informationen zur Konfiguration und Nutzung des Services finden Sie im AWS- CloudHSM-Benutzerhandbuch. 

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.

Risiko der Dauerhaftigkeit: Da die Schlüssel in Systemen außerhalb von AWS unter Ihrer Kontrolle stehen, sind Sie allein für die Haltbarkeit aller von Ihnen erstellten externen Schlüssel verantwortlich. 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 End-to-End-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.