AWS XKS (External Key Store): Vollstandiger Implementierungsleitfaden 2026
Ihr CISO hat gerade gefragt, wie Ihr Unternehmen AWS-Dienste nutzen und gleichzeitig die vollstandige kryptografische Kontrolle uber Verschlusselungsschlussel auerhalb der Amazon-Infrastruktur behalten kann. Die Antwort ist AWS XKS (External Key Store), aber es bringt echte Komplexitat, erhebliche Kosten und eine grundlegende Verschiebung Ihrer betrieblichen Verantwortlichkeiten mit sich.
Dieser Leitfaden schneidet durch den Larm. Sie werden genau verstehen, was XKS ist, ob Sie es tatsachlich benotigen, wie Sie es implementieren und was es Sie kosten wird, einschlielich der Teilelieferanten, die nicht im Voraus freiwillig zur Verfugung stehen.
Inhaltsverzeichnis
- Was ist AWS XKS?
- Funktionsweise von AWS XKS
- XKS vs. andere Schlusselverwaltungsoptionen
- Wenn Sie XKS tatsachlich benotigen
- Anforderungen und Voraussetzungen
- Schritt-fur-Schritt-Implementierungsanleitung
- Der XKS-Proxy: Deep Dive
- Best Practices fur die Sicherheit
- Haufige Herausforderungen und Fehlerbehebung
- Compliance- und Audit-Uberlegungen
- FAQ
Was ist AWS XKS?
AWS External Key Store (XKS) ist eine Funktion des AWS Key Management Service (KMS), mit der Sie Verschlusselungsschlussel verwenden konnen, die vollstandig auerhalb der AWS-Infrastruktur generiert, gespeichert und verwaltet werden in Hardware oder Software, die Sie besitzen und kontrollieren.
XKS wurde auf der re:Invent 2022 angekundigt und ist mittlerweile eine ausgereifte Funktion. Es schliet eine spezifische Lucke: Organisationen, die die Bandbreite der AWS-Dienste benotigen, aber aufgrund von Vorschriften oder Richtlinien nicht zulassen konnen, dass ihre kryptografischen Stammschlussel auf der AWS-Infrastruktur liegen.
Unter dem standardmaigen AWS KMS verwaltet Amazon das Schlusselmaterial innerhalb seiner eigenen sicheren Infrastruktur. Sie kontrollieren den Zugriff auf Schlussel, aber die Schlussel selbst befinden sich in AWS. XKS kehrt dies um: Ihre Schlussel befinden sich in Ihrer Infrastruktur und AWS ruft sie auf, wenn kryptografische Vorgange ausgefuhrt werden mussen.
Schlusselterminologie
| Begriff | Definition |
|---|---|
| Externer Schlusselspeicher (XKS) | Ein benutzerdefinierter Schlusselspeicher, der von Ihrem externen Schlusselmanager unterstutzt wird |
| XKS-Proxy | Vom Kunden verwaltete Middleware, die KMS-API-Aufrufe in das Protokoll Ihres Schlusselmanagers ubersetzt |
| Externer Schlusselmanager | Ihr HSM, Software-KMS oder Ihre Schlusselverwaltungsplattform auerhalb von AWS |
| XksKeyId | Die Kennung Ihres externen Schlussels, verknupft mit einem KMS-Schlussel |
| Doppelte Umschlagverschlusselung | Die Daten werden zuerst von AWS KMS und dann erneut von Ihrem externen Schlusselmanager |
Eine Klarstellung, die viele Architekten uberrascht: XKS verwendet Double-Envelope-Verschlusselung. Die Daten werden mit dem KMS-Schlusselmaterial und Ihrem externen Schlussel verschlusselt. Das bedeutet, dass der durch XKS geschutzte Chiffretext immer mindestens so stark ist wie Standard-KMS er ist additiv und kein Ersatz.
So funktioniert AWS XKS
Bevor Sie sich fur XKS entscheiden, ist es wichtig, den Anforderungsablauf zu verstehen. Jeder Verschlusselungs- oder Entschlusselungsvorgang folgt diesem Pfad:
- Ein AWS-Dienst (S3, EBS, RDS usw.) ruft AWS KMS auf, um einen Datenschlussel zu verschlusseln oder zu entschlusseln
- AWS KMS erkennt, dass der KMS-Schlussel durch einen externen Schlusselspeicher gesichert ist
- KMS leitet die kryptografische Anfrage uber HTTPS an Ihren XKS-Proxy weiter
- Ihr XKS-Proxy authentifiziert die Anfrage und leitet sie an Ihren externen Schlusselmanager weiter.
- Ihr externer Schlusselmanager fuhrt den kryptografischen Vorgang durch
- Das Ergebnis wird uber den Proxy an KMS zuruckgesendet
- KMS schliet den Vorgang ab und gibt Ergebnisse an den AWS-Service zuruck
Dieser gesamte Roundtrip erfolgt synchron. Wenn ein Schritt in dieser Kette fehlschlagt oder den Latenzschwellenwert (normalerweise 250 ms) uberschreitet, schlagt der KMS-Vorgang fehl und je nach AWS-Service kann dieser Fehler kaskadieren.
Der Wandel der geteilten Verantwortung
Hier unterschatzen viele Organisationen XKS. Unter Standard-KMS kummert sich AWS um Verfugbarkeit, Patching, Skalierung und Notfallwiederherstellung der wichtigsten Infrastruktur. Unter XKS ubernehmen Sie das alles fur Ihren Proxy und externen Schlusselmanager einschlielich der physischen Einrichtung, der Stromversorgung, der Kuhlung, des Netzwerks, des Betriebssystems und der Anwendungsebenen.
Wenn Ihr externer Schlusselmanager ausfallt, konnen AWS-Dienste, die auf XKS-Schlusseln basieren, nicht verschlusseln oder entschlusseln. Dies ist kein hypothetischer Fehlermodus es handelt sich um das erwartete Verhalten, und es liegt in Ihrer Verantwortung, entsprechend zu entwerfen.
XKS im Vergleich zu anderen Schlusselverwaltungsoptionen
Bevor Sie in XKS investieren, vergleichen Sie es ehrlich mit Alternativen.
XKS vs. Standard AWS KMS (vom Kunden verwaltete Schlussel)
Mit standardmaigen, vom Kunden verwalteten Schlusseln (Customer-Managed Keys, CMKs) kontrollieren Sie die Schlussel-Richtlinien und den Zugriff wer den Schlussel unter welchen Bedingungen verwenden kann, mit vollstandiger Audit-Protokollierung. AWS halt das Schlusselmaterial immer noch in seiner eigenen KMS-Infrastruktur.
Verwenden Sie CMKs, wenn: Sie eine starke Zugriffskontrolle und Uberprufbarkeit benotigen, Ihre Compliance-Anforderungen jedoch nicht vorschreiben, dass wichtiges Material auerhalb von AWS gespeichert wird.
Verwenden Sie XKS, wenn: Vorschriften oder Organisationsrichtlinien ausdrucklich vorschreiben, dass sich kryptografisches Schlusselmaterial niemals auf der Infrastruktur Dritter (z. B. AWS) befindet.
XKS vs. AWS CloudHSM
CloudHSM bietet Ihnen dedizierte Single-Tenant-Hardware-Sicherheitsmodule in AWS-Rechenzentren. Sie kontrollieren das HSM, seine Benutzer und seine Schlussel AWS hat keinen Zugriff auf das Schlusselmaterial. Die HSMs selbst befinden sich jedoch physisch in AWS-eigenen Einrichtungen.
| XKS | CloudHSM | |
|---|---|---|
| Schlusselstandort | Ihre Infrastruktur | AWS-Rechenzentrum (dediziertes HSM) |
| Physischer AWS-Zugriff | Keine | Kein Zugriff auf HSM-Inhalte, aber die Hardware befindet sich vor Ort bei AWS |
| Latenz | Hoher (externer Hin- und Ruckflug) | Niedriger (innerhalb des AWS-Netzwerks) |
| Verfugbarkeitsverantwortung | Ganz allein Ihr | Freigegeben (AWS verwaltet Hardware; Sie verwalten HSM-Software) |
| Kosten | Hohere Gesamtkosten | ~1,45 $/Std. pro HSM-Cluster |
| Compliance-Passform | Strenge Souveranitatsauflagen | Die meisten FIPS 140-2 Level 3-Anforderungen |
| Komplexitat | Sehr hoch | Hoch |
Wahlen Sie CloudHSM, wenn Sie eine FIPS 140-2 Level 3-Hardwarevalidierung benotigen und Schlussel tolerieren konnen, die sich physisch innerhalb von AWS befinden. Wahlen Sie XKS nur, wenn Ihre Compliance-Anforderung ausdrucklich vorschreibt, dass Schlussel vollstandig auerhalb von AWS-eigenen Einrichtungen verbleiben mussen.
XKS vs. vom Kunden verwaltete Schlussel (Zusammenfassung)
Fur die meisten Workloads einschlielich der meisten HIPAA-, PCI-DSS- und SOC 2-Anforderungen sind vom Kunden verwaltete Standard-KMS-Schlussel ausreichend. XKS wurde speziell fur die engen Vorschriften entwickelt (bestimmte Anforderungen an die Datensouveranitat der EU, spezifische Vorschriften fur den Finanzsektor, Vorschriften der US-Regierung), die ausdrucklich vorschreiben, dass Cloud-Anbieter unter keinen Umstanden Zugriff auf wichtiges Material haben.
Entscheidungsrahmen
Stellen Sie diese drei Fragen der Reihe nach:
- Sehen Ihre Vorschriften ausdrucklich, dass sich Schlusselmaterial auerhalb der physischen Infrastruktur Ihres Cloud-Anbieters befinden muss? Wenn nein verwenden Sie CMKs oder CloudHSM.
- Konnen Sie hohere Latenz, betriebliche Komplexitat und deutlich hohere Kosten akzeptieren? Wenn nein uberdenken Sie noch einmal, ob XKS wirklich erforderlich ist.
- Verfugen Sie uber die betriebliche Reife, um einen hochverfugbaren Schlusselverwaltungsdienst mit geringer Latenz zu betreiben? Wenn nein bauen Sie diese Fahigkeit auf, bevor Sie XKS implementieren.
Wenn Sie XKS wirklich brauchen
XKS existiert fur ein bestimmtes Compliance-Szenario, nicht fur allgemeine Sicherheitsverbesserungen. Dies sind die legitimen Anwendungsfalle:
Regulatorische Datensouveranitat Vorschriften wie die DSGVO (verscharft durch das Schrems-II-Urteil) verlangen von EU-Organisationen, nachweisen zu konnen, dass Verschlusselungsschlussel niemals ihren kontrollierten Zustandigkeitsbereich verlassen, und den Zugriff von Cloud-Anbietern jederzeit zu widerrufen. XKS erfullt dies, indem Schlussel in einer EU-basierten Infrastruktur auerhalb von AWS platziert werden.
CLOUD Act-Gefahrdungsminderung Organisationen, die uber den US CLOUD Act besorgt sind (der es US-Strafverfolgungsbehorden ermoglicht, US-Cloud-Anbieter zur Produktion von Daten zu zwingen), verwenden XKS, um sicherzustellen, dass AWS nicht unter Zwang auf wichtiges Material zugreifen kann. Ihr externer Schlusselmanager in einem anderen Zustandigkeitsbereich verfugt uber die einzige Kopie.
Finanzdienstleistungsvorschriften Bestimmte Zentralbankvorschriften und Aufsichtsrahmen fur den Finanzsektor erfordern Bestimmungen zur betrieblichen Belastbarkeit, zu denen auch die Aufrechterhaltung der Kontrolle uber kryptografisches Material auerhalb des primaren Cloud-Anbieters gehort.
Behorden- und Verteidigungsarbeitslasten US-Bundesbehorden, die CUI (Controlled Unclassified Information) oder vertrauliche Daten im Rahmen von FedRAMP High oder DoD IL-Rahmenwerken verarbeiten, haben moglicherweise explizite Anforderungen an die Schlusselverwahrung.
Zero-Trust-Schlusselarchitektur Organisationen, die strikte Zero-Trust-Modelle implementieren, bei denen kein einzelner Anbieter vollstandigen Zugriff auf Daten und Schlussel hat.
Wofur XKS nicht gedacht ist: allgemeine Sicherheitsverstarkung, Erreichen der HIPAA-Konformitat (Standard-KMS ist ausreichend), Reduzierung der AWS-Anbieterbindung aus nicht-kryptografischen Grunden oder Kosteneinsparungen. Es ist teurer und komplexer als jede Alternative.
Anforderungen und Voraussetzungen
Uberprufen Sie alle diese Punkte, bevor Sie mit der Implementierung beginnen.
Anforderungen fur den externen Schlusselmanager
Ihr externer Schlusselmanager muss:
- Unterstutzt symmetrische AES-256-Schlussel
- Sie mussen in der Lage sein, AES-GCM-Verschlusselungs- und -Entschlusselungsvorgange durchzufuhren Stellen Sie eine API bereit, die Ihr XKS-Proxy in die AWS-XKS-Spezifikation ubersetzen kann
- Erfullen Sie die Latenzanforderungen: Reagieren Sie auf Proxy-Anfragen in weniger als 250 ms (End-to-End von KMS).
Zu den validierten externen Schlusselmanagern mit nativer XKS-Proxy-Unterstutzung gehoren:
- Thales CipherTrust Manager (mit CipherTrust Cloud Key Manager)
- Fortanix Data Security Manager
- HashiCorp Vault (mit Community-XKS-Proxy-Implementierungen)
- KeyControl anvertrauen
- Atos Trustway
- T-Systems (Souverane Cloud-Bereitstellungen)
- Securosys Primus HSM / CloudHSM Jedes PKCS#11-kompatible HSM, das den in Rust erstellten AWS Open-Source-Referenz-XKS-Proxy verwendet
AWS-Kontoanforderungen
AWS KMS in Ihren Zielregionen aktiviert IAM-Berechtigungen zum Erstellen und Verwalten benutzerdefinierter Schlusselspeicher VPC konfiguriert, wenn VPC-Endpunktdienstkonnektivitat verwendet wird (empfohlen)
Netzwerkanforderungen
XKS unterstutzt zwei Konnektivitatsmodelle:
Offentliche Endpunktkonnektivitat AWS KMS erreicht Ihren Proxy uber das Internet uber HTTPS. Einfacher zu konfigurieren, macht Ihren Proxy-Endpunkt jedoch dem offentlichen Internet zuganglich. Nur mit robuster mTLS-Authentifizierung akzeptabel.
VPC-Endpunkt-Service-Konnektivitat AWS KMS stellt eine Verbindung uber einen AWS PrivateLink VPC-Endpunkt-Service her, den Sie erstellen und verwalten. Dies halt den Datenverkehr vom offentlichen Internet fern und ist der empfohlene Ansatz fur Produktions-Workloads.
Ihr Proxy muss erreichbar sein mit:
- TLS 1.2 oder hoher mit einem gultigen Zertifikat Der Proxy-URI-Pfad muss /kms/xks/v1 sein (oder ein Prafix, das auf diesem Pfad endet)
- Port 443 (HTTPS)
- Reaktionszeit konstant unter 250 ms
Schritt-fur-Schritt-Implementierungsanleitung
Schritt 1: Richten Sie Ihren externen Schlusselmanager ein
Konfigurieren Sie den Schlusselmanager Ihrer Wahl, um AES-256-Schlussel zu generieren und zu speichern. Notieren Sie sich die externe Schlussel-ID (XksKeyId) fur jeden Schlussel, den Sie verwenden mochten Sie werden beim Erstellen von KMS-Schlusseln darauf verweisen.
Stellen Sie sicher, dass Ihr Schlusselmanager mit hoher Verfugbarkeit bereitgestellt wird. Mindestens: Aktiv-Passiv-Failover. Fur die Produktion: Aktiv-Aktiv uber zwei oder mehr unabhangige Knoten.
Schritt 2: Stellen Sie den XKS-Proxy bereit
Ihr Proxy ist der entscheidende Teil. Bereitstellungsoptionen:
Lokaler Proxy, der uber einen offentlichen Endpunkt eine Verbindung herstellt: Der Proxy wird in Ihrem Rechenzentrum ausgefuhrt und uber einen offentlichen HTTPS-Endpunkt bereitgestellt. Nur verwenden, wenn die VPC-Konnektivitat nicht moglich ist.
Proxy auf EC2 innerhalb einer VPC (empfohlen): Stellen Sie den Proxy auf einer EC2-Instanz in einem privaten Subnetz bereit. Erstellen Sie einen VPC-Endpunktdienst, der auf einen Network Load Balancer vor Ihrem Proxy verweist. AWS KMS stellt eine Verbindung uber PrivateLink her.
Lokale Proxy-Verbindung uber VPC: Fuhren Sie den Proxy lokal aus, verbinden Sie ihn jedoch uber ein Site-to-Site-VPN oder Direct Connect mit einem VPC-Endpunktdienst. Maximale Sicherheit, maximale Komplexitat.
Fur eine hohe Verfugbarkeit stellen Sie Proxy-Instanzen in mehreren Availability Zones hinter einem Network Load Balancer bereit.
Die Authentifizierung zwischen KMS und Ihrem Proxy verwendet ein SigV4-ahnliches Anmeldeinformationsschema eine Zugriffsschlussel-ID und einen geheimen Zugriffsschlussel, die Sie sowohl auf dem Proxy als auch in KMS konfigurieren. Wechseln Sie diese Anmeldeinformationen regelmaig.
Der XKS-Proxy: Tiefer Einblick
Der Proxy verdient besondere Aufmerksamkeit, da er die haufigste Ursache fur Implementierungsprobleme ist.
Der Proxy implementiert die [AWS
Proxy-Sicherheitsanforderungen
- mTLS- oder SigV4-Authentifizierung fur alle KMS-zu-Proxy-Anfragen Der Proxy muss uberprufen, ob Anfragen ein gultiges requestMetadata-Feld enthalten, das den AWS-Prinzipal-ARN und den KMS-Schlussel-ARN enthalt dies ermoglicht Ihnen die Implementierung zusatzlicher Autorisierung auf der Proxy-Ebene uber IAM hinaus
- Die gesamte Kommunikation wird wahrend der Ubertragung verschlusselt; keine ausnahmen Der Proxy sollte kein Schlusselmaterial speichern er ubersetzt Anfragen, er speichert keine Geheimnisse zwischen
Erstellen eines benutzerdefinierten Proxys
AWS stellt eine Open-Source-Referenzimplementierung in Rust bereit, die als Container ausgefuhrt werden kann und mit jedem PKCS#11-HSM kompatibel ist. Dies ist ein sinnvoller Ausgangspunkt fur Organisationen, die nicht vom Hersteller unterstutzte Schlusselmanager verwenden.
Fur Produktionszwecke hinzufugen:
- Anfrage-/Antwortprotokollierung (ohne Protokollierung von Schlusselmaterial)
- Strombegrenzung und Leistungsschalter
- Endpunkte zur Integritatsprufung fur die Load-Balancer-Integration
- Export von Metriken nach CloudWatch oder Ihrem Observability Stack
Uberlegungen zur Proxy-Leistung
Jeder KMS-Aufruf fur einen XKS-gestutzten Schlussel beinhaltet einen externen Netzwerk-Roundtrip. Bei Workloads, die Tausende von KMS-Anfragen pro Sekunde generieren, summiert sich das. AWS speichert Datenschlussel auf Serviceebene zwischen (z. B. speichert S3 Datenschlussel einige Minuten lang, wenn Bucket-Schlussel aktiviert sind), wodurch sich das reine Anforderungsvolumen an Ihren Proxy verringert Sie mussen jedoch dennoch eine Kapazitatsplanung fur Spitzenlasten durchfuhren.
Vergleichen Sie Ihren Proxy vor dem Go-Live unter realistischer Belastung. XKS_PROXY_TIMED_OUT-Fehler weisen darauf hin, dass Ihr Proxy zu langsam ist. XKS_PROXY_INVALID_RESPONSE weist auf ein Protokollproblem hin.
Best Practices fur die Sicherheit
Verwenden Sie die VPC-Endpunkt-Dienstkonnektivitat stellen Sie Ihren Proxy-Endpunkt niemals offentlich zur Verfugung, es sei denn, dies ist unbedingt erforderlich. Das zusatzliche PrivateLink-Setup ist die reduzierte Angriffsflache wert.
Autorisierung auf Proxy-Ebene implementieren die requestMetadata in jeder KMS-Anfrage enthalten den ARN des aufrufenden Prinzipals. Nutzen Sie dies, um granulare Richtlinien auf der Proxy-Ebene durchzusetzen: Bestimmte IAM-Rollen konnen nur bestimmte externe Schlussel verwenden, bestimmte Vorgange werden auerhalb der Geschaftszeiten blockiert usw.
Rotieren Sie die Anmeldeinformationen fur die Proxy-Authentifizierung nach einem definierten Zeitplan. Verwenden Sie AWS Secrets Manager, um den geheimen Zugriffsschlussel, der fur die KMS-zu-Proxy-Authentifizierung verwendet wird, zu speichern und automatisch zu rotieren.
Uberwachen und alarmieren Sie alle Proxy-Fehler achten Sie insbesondere auf die Fehler XKS_PROXY_TIMED_OUT, XKS_PROXY_NOT_REACHABLE und INVALID_KEY_USAGE in CloudTrail. Jede anhaltende Fehlerrate sollte eine Reaktion auf einen Vorfall auslosen.
Schlussellebenszyklusverwaltung Dokumentieren Sie explizite Verfahren fur die Schlusselrotation (Ihr externer Schlusselmanager kann Schlusselmaterial hinter derselben XksKeyId rotieren), Schlusselloschung (Koordination zwischen KMS-Schlusselloschung und externer Schlusselloschung eine falsche Reihenfolge fuhrt zu dauerhaftem Datenverlust) und Notfallschlusselsperrung (Ihr Proxy ist der Kill-Schalter: Schalten Sie ihn offline und alle XKS-Vorgange werden eingestellt).
Notfallwiederherstellung Fuhren Sie ein getestetes Wiederherstellungs-Runbook. Wenn Ihr externer Schlusselmanager einen katastrophalen Ausfall erleidet, mussen Sie ihn wiederherstellen und erneut verbinden, bevor mit XKS-Schlusseln verschlusselte Daten dauerhaft unzuganglich werden. Sichern Sie Ihr externes Schlusselmaterial mithilfe der nativen Sicherungsmechanismen Ihres Schlusselmanagers.
Haufige Herausforderungen und Fehlerbehebung
Verbindungsfehler
XKS_PROXY_NOT_REACHABLE KMS kann den Proxy-Endpunkt nicht erreichen. Uberprufen Sie: Netzwerkrouting, Sicherheitsgruppenregeln, NLB-Gesundheitsprufungen, Proxy-Prozessstatus.
XKS_PROXY_TIMED_OUT Proxy erreichbar, antwortet aber nicht innerhalb des Timeouts. Uberprufen Sie: Proxy-Anwendungsprotokolle, Latenz des externen Schlusselmanagers, CPU/Speicher der Proxy-Instanz, Netzwerklatenz zwischen Proxy und Schlusselmanager.
XKS_PROXY_INVALID_RESPONSE Der Proxy hat geantwortet, aber die Antwort entspricht nicht der XKS-API-Spezifikation. Uberprufen Sie die Proxy-Implementierung auf Nichtubereinstimmungen der API-Version oder Serialisierungsfehler.
Authentifizierungsfehler
XKS_PROXY_ACCESS_DENIED Nichtubereinstimmung der Anmeldeinformationen zwischen KMS und Proxy-Konfiguration. Stellen Sie sicher, dass AccessKeyId und RawSecretAccessKey auf beiden Seiten genau ubereinstimmen. Bei den Anmeldeinformationen muss die Gro-/Kleinschreibung beachtet werden.
Schlusselthemen
XKS_KEY_NOT_FOUND Die in KMS referenzierte XksKeyId ist in Ihrem externen Schlusselmanager nicht vorhanden oder der Proxy kann sie nicht finden. Stellen Sie sicher, dass die Schlussel-ID korrekt ist und der Schlussel in Ihrem externen Schlusselmanager aktiviert ist.
XKS_KEY_DISABLED_IN_EXTERNAL_KEY_MANAGER Der Schlussel ist auf der Ebene des externen Schlusselmanagers deaktiviert. Dies ist unabhangig vom aktivierten Status des KMS-Schlussels. An der Quelle erneut aktivieren.
Compliance- und Audit-Uberlegungen
XKS erstellt ein komplexeres Audit-Trail als Standard-KMS, aber ein vollstandigeres wenn Sie es richtig instrumentieren.
CloudTrail protokolliert jeden KMS-API-Aufruf mit XKS-Schlusseln, einschlielich des aufrufenden Prinzipals, des Schlussel-ARN und des Vorgangsergebnisses. Dies ist Ihr primares Audit-Artefakt, um den Aufsichtsbehorden die Kontrolle uber die Schlusselnutzung zu demonstrieren.
Protokolle auf Proxy-Ebene erfassen jede Anfrage, die von KMS an Ihren externen Schlusselmanager weitergeleitet wird. Wenn Sie die Protokollierung der requestMetadata (einschlielich des ursprunglichen AWS-Principal-ARN) konfigurieren, verfugen Sie uber einen durchgangigen Prufpfad vom AWS-Serviceaufruf bis zum kryptografischen Betrieb.
Externe Schlusselmanager-Uberwachungsprotokolle liefern die magebliche Aufzeichnung daruber, welche Schlussel wann und von welcher Proxy-Identitat verwendet wurden.
Zur Einhaltung der DSGVO/Schrems II dokumentieren Sie Folgendes:
- Physischer Standort des externen Schlusselmanagers
- Zugriffskontrollrichtlinien fur den externen Schlusselmanager
- Netzwerkpfad von AWS zum Proxy (VPC-Endpunktdienst ist ideal)
- Wichtige Sicherungs- und Wiederherstellungsverfahren, die geografische Beschrankungen wahren
- Verfahren zur Reaktion auf Vorfalle bei Schlusselkompromittierung
Stellen Sie fur PCI-DSS sicher, dass der externe Schlusselmanager die Schlusselverwaltungsanforderungen gema PCI-DSS v4.0 Anforderung 3.7 erfullt, einschlielich der Verfahren der doppelten Kontrolle und des Split-Knowledge-Verfahrens fur Schlusselverwalter.
FAQ
F: Was ist AWS XKS?
AWS XKS (External Key Store) ist eine Funktion von AWS KMS, mit der Sie Verschlusselungsschlussel verwenden konnen, die vollstandig auerhalb der AWS-Infrastruktur gespeichert und verwaltet werden. Ihre Schlussel befinden sich in Ihrem externen Schlusselmanager; AWS ruft Ihren XKS-Proxy immer dann auf, wenn er kryptografische Vorgange ausfuhren muss.
F: Wann benotige ich XKS anstelle von Standard-KMS?
Wenn Vorschriften oder Organisationsrichtlinien ausdrucklich vorschreiben, dass sich kryptografisches Schlusselmaterial niemals auf der Infrastruktur Dritter (einschlielich Cloud-Anbietern) befinden darf. Zu den haufigsten Treibern gehoren DSGVO + Schrems II fur die EU-Datensouveranitat, die Abschwachung des CLOUD Act und bestimmte Vorschriften fur den Finanzsektor. Fur die meisten HIPAA-, PCI-DSS- und SOC 2-Anforderungen sind Standard-CMKs ausreichend.
F: Was ist ein XKS-Proxy?
Der XKS-Proxy ist eine Middleware, die Sie besitzen und betreiben. Es befindet sich zwischen AWS KMS und Ihrem externen Schlusselmanager und ubersetzt AWS XKS-API-Anfragen in das native Protokoll Ihres Schlusselmanagers. Es bietet auerdem eine zusatzliche Autorisierungsebene und fungiert als Kill-Switch deaktivieren Sie den Proxy und alle XKS-Verschlusselungs-/Entschlusselungsvorgange werden gestoppt.
F: Was passiert, wenn mein externer Schlusselmanager ausfallt?
AWS-Services, die auf XKS-gestutzten Schlusseln basieren, konnen keine neuen Verschlusselungs- oder Entschlusselungsvorgange durchfuhren. Einige Dienste (z. B. S3 mit aktivierten Bucket-Schlusseln) speichern Datenschlussel einige Minuten lang zwischen und sorgen so fur kurze Ausfallsicherheit. Ein langerer Ausfall bedeutet jedoch, dass Ihre AWS-Workloads keine verschlusselten Daten verarbeiten konnen. Hohe Verfugbarkeit ist nicht verhandelbar.
F: Kann ich XKS mit allen AWS-Diensten verwenden?
XKS funktioniert mit den meisten AWS-Diensten, die vom Kunden verwaltete KMS-Schlussel unterstutzen, einschlielich S3, EBS, RDS, DynamoDB, Lambda und andere. AWS validiert und dokumentiert schrittweise den Support pro Service. Uberprufen Sie Ihren spezifischen Service und Ihre AWS-Region immer anhand der aktuellen Dokumentation, bevor Sie sich zum Design verpflichten.
F: Ist XKS dasselbe wie CloudHSM?
Nein. CloudHSM stellt dedizierte Hardware-HSMs bereit, die sich physisch in AWS-Rechenzentren befinden, aber unter Ihrer alleinigen Kontrolle stehen. XKS geht noch einen Schritt weiter: Ihr Schlusselmaterial befindet sich in der von Ihnen betriebenen Infrastruktur, vollstandig auerhalb der AWS-eigenen Einrichtungen. XKS weist eine hohere betriebliche Komplexitat, hohere Gesamtkosten und eine hohere Latenz auf als CloudHSM.
F: Wie funktioniert die Schlusselrotation mit XKS?
Die Rotation ist komplexer als das Standard-KMS. Sie konnen die automatische KMS-Schlusselrotation nicht fur XKS-Schlussel verwenden. Stattdessen rotiert Ihr externer Schlusselmanager das mit derselben XksKeyId verknupfte Schlusselmaterial AWS KMS verweist weiterhin auf dieselbe Schlussel-ID und Ihr Schlusselmanager verwendet transparent das neue Schlusselmaterial. Koordinieren Sie sorgfaltig die Rotationsverfahren zwischen Ihrem Key-Manager-Betriebsteam und Ihrem AWS-Team.
F: Kann ich vorhandene KMS-verschlusselte Daten zu XKS migrieren?
Nicht direkt. Es gibt keinen Neuverschlusselungspfad, der vorhandene CMK-verschlusselte Daten zu XKS verschiebt, ohne jedes Objekt zu entschlusseln und erneut zu verschlusseln. Fur S3 bedeutet dies, alle Objekte zu durchlaufen; Fur EBS-Volumes benotigen Sie Snapshot- und Wiederherstellungsworkflows. Planen Sie die Migration sorgfaltig und planen Sie viel Zeit und Kosten fur groe Datensatze ein.
Fazit: Ist XKS das Richtige fur Sie?
XKS wurde speziell fur ein enges, spezifisches Compliance-Szenario entwickelt. Es halt, was es verspricht kryptografisches Schlusselmaterial unter Ihrer ausschlielichen Kontrolle, auerhalb der AWS-Infrastruktur allerdings auf Kosten einer erheblichen betrieblichen Komplexitat, hoherer Latenz und wesentlich hoherer Kosten.
Verwenden Sie diese Checkliste, bevor Sie sich verpflichten:
- Ihr Rechts- oder Compliance-Team hat ausdrucklich bestatigt, dass die Vorschriften erfordern, dass sich Schlusselmaterial auerhalb der Infrastruktur des Cloud-Anbieters befindet (nicht nur starke Schlusselkontrolle im Allgemeinen).
- Sie haben einen kompatiblen externen Schlusselmanager und eine praktikable XKS-Proxy-Bereitstellung identifiziert
- Sie konnen eine Roundtrip-Latenz von unter 250 ms von Ihrem Proxy zum externen Schlusselmanager aufrechterhalten
- Sie verfugen uber die operative Fahigkeit, einen hochverfugbaren Schlusselverwaltungsdienst auszufuhren
- Sie haben insgesamt Betriebskosten in Hohe von 7.000 bis 20.000 US-Dollar pro Monat veranschlagt
- Sie verfugen uber einen getesteten Disaster-Recovery-Plan fur Ausfalle wichtiger Manager
- Sie haben gepruft, welche AWS-Dienste Sie nutzen, und die XKS-Unterstutzung fur jeden bestatigt
Wenn Sie all dies uberprufen konnen, ist XKS eine gut durchdachte Losung fur ein schwieriges Problem. Wenn Sie weniger als vier prufen, werfen Sie einen weiteren Blick auf CloudHSM oder gut verwaltete CMKs sie erfullen moglicherweise Ihre tatsachlichen Anforderungen mit weitaus geringerem Betriebsaufwand.
Referenzen
- AWS KMS External Key Store Offizielle Dokumentation
- Ankundigung des externen Schlusselspeichers fur AWS KMS AWS-Sicherheitsblog
- AWS XKS Proxy-Referenzimplementierung (GitHub)
- AWS Digital Sovereignty Pledge
- NIST SP 800-57: Wichtige Managementrichtlinien
- PCI-DSS v4.0-Schlusselverwaltungsanforderungen
- DSGVO Artikel 32 Sicherheit der Verarbeitung
- Fortanix DSM XKS-Integration
- Thales CipherTrust XKS-Losung
- AWS Well-Architected Framework Sicherheitssaule
- Cloud Security Alliance: Richtlinien zur Cloud-Schlusselverwaltung
