AWS XKS (External Key Store): Vollständiger Implementierungsleitfaden 2026

Ihr CISO hat gerade gefragt, wie Ihr Unternehmen AWS-Dienste nutzen und gleichzeitig die vollständige kryptografische Kontrolle über Verschlüsselungsschlüssel ausserhalb der Amazon-Infrastruktur behalten kann. Die Antwort ist AWS XKS (External Key Store), aber es bringt echte Komplexität, erhebliche Kosten und eine grundlegende Verschiebung Ihrer betrieblichen Verantwortlichkeiten mit sich.

Dieser Leitfaden schneidet durch den Lärm. Sie werden genau verstehen, was XKS ist, ob Sie es tatsächlich benötigen, wie Sie es implementieren und was es Sie kosten wird, einschliesslich der Teilelieferanten, die nicht im Voraus freiwillig zur Verfügung stehen.

---

Inhaltsverzeichnis

1. Was ist AWS XKS?
2. Anforderungen und Voraussetzungen
3. Schritt-für-Schritt-Implementierungsanleitung
4. Best Practices für die Sicherheit
5. Häufige Herausforderungen und Fehlerbehebung
6. Compliance- und Audit-Überlegungen
7. FAQ

---

Was ist AWS XKS?

AWS External Key Store (XKS) ist eine Funktion des AWS Key Management Service (KMS), mit der Sie Verschlüsselungsschlüssel verwenden können, die vollständig ausserhalb der AWS-Infrastruktur generiert, gespeichert und verwaltet werden – in Hardware oder Software, die Sie besitzen und kontrollieren.

XKS wurde auf der re:Invent 2022 angekündigt und ist mittlerweile eine ausgereifte Funktion. Es schliesst eine spezifische Lücke: Organisationen, die die Bandbreite der AWS-Dienste benötigen, aber aufgrund von Vorschriften oder Richtlinien nicht zulassen können, dass ihre kryptografischen Stammschlüssel auf der AWS-Infrastruktur liegen.

Unter dem standardmässigen AWS KMS verwaltet Amazon das Schlüsselmaterial innerhalb seiner eigenen sicheren Infrastruktur. Sie kontrollieren den Zugriff auf Schlüssel, aber die Schlüssel selbst befinden sich in AWS. XKS kehrt dies um: Ihre Schlüssel befinden sich in Ihrer Infrastruktur und AWS ruft sie auf, wenn kryptografische Vorgänge ausgeführt werden müssen.

Schlüsselterminologie

Eine Klarstellung, die viele Architekten überrascht: XKS verwendet Double-Envelope-Verschlüsselung. Die Daten werden mit dem KMS-Schlüsselmaterial und Ihrem externen Schlüssel verschlüsselt. Das bedeutet, dass der durch XKS geschützte Chiffretext immer mindestens so stark ist wie Standard-KMS – er ist additiv und kein Ersatz.

---

So funktioniert AWS XKS

Bevor Sie sich für XKS entscheiden, ist es wichtig, den Anforderungsablauf zu verstehen. Jeder Verschlüsselungs- oder Entschlüsselungsvorgang folgt diesem Pfad:

1. Ein AWS-Dienst (S3, EBS, RDS usw.) ruft AWS KMS auf, um einen Datenschlüssel zu verschlüsseln oder zu entschlüsseln
2. AWS KMS erkennt, dass der KMS-Schlüssel durch einen externen Schlüsselspeicher gesichert ist
3. KMS leitet die kryptografische Anfrage über HTTPS an Ihren XKS-Proxy weiter
4. Ihr XKS-Proxy authentifiziert die Anfrage und leitet sie an Ihren externen Schlüsselmanager weiter.
5. Ihr externer Schlüsselmanager führt den kryptografischen Vorgang durch
6. Das Ergebnis wird über den Proxy an KMS zurückgesendet
7. KMS schliesst den Vorgang ab und gibt Ergebnisse an den AWS-Service zurück

Dieser gesamte Roundtrip erfolgt synchron. Wenn ein Schritt in dieser Kette fehlschlägt oder den Latenzschwellenwert (normalerweise 250 ms) überschreitet, schlägt der KMS-Vorgang fehl – und je nach AWS-Service kann dieser Fehler kaskadieren.

Der Wandel der geteilten Verantwortung

Hier unterschätzen viele Organisationen XKS. Unter Standard-KMS kümmert sich AWS um Verfügbarkeit, Patching, Skalierung und Notfallwiederherstellung der wichtigsten Infrastruktur. Unter XKS übernehmen Sie das alles für Ihren Proxy und externen Schlüsselmanager – einschliesslich der physischen Einrichtung, der Stromversorgung, der Kühlung, des Netzwerks, des Betriebssystems und der Anwendungsebenen.

Wenn Ihr externer Schlüsselmanager ausfällt, können AWS-Dienste, die auf XKS-Schlüsseln basieren, nicht verschlüsseln oder entschlüsseln. 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 Schlüsselverwaltungsoptionen

Bevor Sie in XKS investieren, vergleichen Sie es ehrlich mit Alternativen.

XKS vs. Standard AWS KMS (vom Kunden verwaltete Schlüssel)

Mit standardmässigen, vom Kunden verwalteten Schlüsseln (Customer-Managed Keys, CMKs) kontrollieren Sie die Schlüssel-Richtlinien und den Zugriff – wer den Schlüssel unter welchen Bedingungen verwenden kann, mit vollständiger Audit-Protokollierung. AWS hält das Schlüsselmaterial immer noch in seiner eigenen KMS-Infrastruktur.

Verwenden Sie CMKs, wenn: Sie eine starke Zugriffskontrolle und Überprüfbarkeit benötigen, Ihre Compliance-Anforderungen jedoch nicht vorschreiben, dass wichtiges Material ausserhalb von AWS gespeichert wird.

Verwenden Sie XKS, wenn: Vorschriften oder Organisationsrichtlinien ausdrücklich vorschreiben, dass sich kryptografisches Schlüsselmaterial 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 Schlüssel – AWS hat keinen Zugriff auf das Schlüsselmaterial. Die HSMs selbst befinden sich jedoch physisch in AWS-eigenen Einrichtungen.

Wählen Sie CloudHSM, wenn Sie eine FIPS 140-2 Level 3-Hardwarevalidierung benötigen und Schlüssel tolerieren können, die sich physisch innerhalb von AWS befinden. Wählen Sie XKS nur, wenn Ihre Compliance-Anforderung ausdrücklich vorschreibt, dass Schlüssel vollständig ausserhalb von AWS-eigenen Einrichtungen verbleiben müssen.

XKS vs. vom Kunden verwaltete Schlüssel (Zusammenfassung)

Für die meisten Workloads – einschliesslich der meisten HIPAA-, PCI-DSS- und SOC 2-Anforderungen – sind vom Kunden verwaltete Standard-KMS-Schlüssel ausreichend. XKS wurde speziell für die engen Vorschriften entwickelt (bestimmte Anforderungen an die Datensouveränität der EU, spezifische Vorschriften für den Finanzsektor, Vorschriften der US-Regierung), die ausdrücklich vorschreiben, dass Cloud-Anbieter unter keinen Umständen Zugriff auf wichtiges Material haben.

Entscheidungsrahmen

Stellen Sie diese drei Fragen der Reihe nach:

1. Sehen Ihre Vorschriften ausdrücklich, dass sich Schlüsselmaterial ausserhalb der physischen Infrastruktur Ihres Cloud-Anbieters befinden muss? Wenn nein – verwenden Sie CMKs oder CloudHSM.
2. Können Sie höhere Latenz, betriebliche Komplexität und deutlich höhere Kosten akzeptieren? Wenn nein – überdenken Sie noch einmal, ob XKS wirklich erforderlich ist.
3. Verfügen Sie über die betriebliche Reife, um einen hochverfügbaren Schlüsselverwaltungsdienst mit geringer Latenz zu betreiben? Wenn nein – bauen Sie diese Fähigkeit auf, bevor Sie XKS implementieren.

---

Wenn Sie XKS wirklich brauchen

XKS existiert für ein bestimmtes Compliance-Szenario, nicht für allgemeine Sicherheitsverbesserungen. Dies sind die legitimen Anwendungsfälle:

Regulatorische Datensouveränität – Vorschriften wie die DSGVO (verschärft durch das Schrems-II-Urteil) verlangen von EU-Organisationen, nachweisen zu können, dass Verschlüsselungsschlüssel niemals ihren kontrollierten Zuständigkeitsbereich verlassen, und den Zugriff von Cloud-Anbietern jederzeit zu widerrufen. XKS erfüllt dies, indem Schlüssel in einer EU-basierten Infrastruktur ausserhalb von AWS platziert werden.

CLOUD Act-Gefährdungsminderung – Organisationen, die über den US CLOUD Act besorgt sind (der es US-Strafverfolgungsbehörden ermöglicht, 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 Schlüsselmanager in einem anderen Zuständigkeitsbereich verfügt über die einzige Kopie.

Finanzdienstleistungsvorschriften – Bestimmte Zentralbankvorschriften und Aufsichtsrahmen für den Finanzsektor erfordern Bestimmungen zur betrieblichen Belastbarkeit, zu denen auch die Aufrechterhaltung der Kontrolle über kryptografisches Material ausserhalb des primären Cloud-Anbieters gehört.

Behörden- und Verteidigungsarbeitslasten – US-Bundesbehörden, die CUI (Controlled Unclassified Information) oder vertrauliche Daten im Rahmen von FedRAMP High oder DoD IL-Rahmenwerken verarbeiten, haben möglicherweise explizite Anforderungen an die Schlüsselverwahrung.

Zero-Trust-Schlüsselarchitektur – Organisationen, die strikte Zero-Trust-Modelle implementieren, bei denen kein einzelner Anbieter vollständigen Zugriff auf Daten und Schlüssel hat.

Wofür XKS nicht gedacht ist: allgemeine Sicherheitsverstärkung, Erreichen der HIPAA-Konformität (Standard-KMS ist ausreichend), Reduzierung der AWS-Anbieterbindung aus nicht-kryptografischen Gründen oder Kosteneinsparungen. Es ist teurer und komplexer als jede Alternative.

---

Anforderungen und Voraussetzungen

Überprüfen Sie alle diese Punkte, bevor Sie mit der Implementierung beginnen.

Anforderungen für den externen Schlüsselmanager

Ihr externer Schlüsselmanager muss:

• Unterstützt symmetrische AES-256-Schlüssel
• Sie müssen in der Lage sein, AES-GCM-Verschlüsselungs- und -Entschlüsselungsvorgänge durchzuführen Stellen Sie eine API bereit, die Ihr XKS-Proxy in die AWS-XKS-Spezifikation übersetzen kann
• Erfüllen Sie die Latenzanforderungen: Reagieren Sie auf Proxy-Anfragen in weniger als 250 ms (End-to-End von KMS).

Zu den validierten externen Schlüsselmanagern mit nativer XKS-Proxy-Unterstützung gehören:

• 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 (Souveräne 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 Schlüsselspeicher VPC konfiguriert, wenn VPC-Endpunktdienstkonnektivität verwendet wird (empfohlen)

Netzwerkanforderungen

XKS unterstützt zwei Konnektivitätsmodelle:

Öffentliche Endpunktkonnektivität – AWS KMS erreicht Ihren Proxy über das Internet über HTTPS. Einfacher zu konfigurieren, macht Ihren Proxy-Endpunkt jedoch dem öffentlichen Internet zugänglich. Nur mit robuster mTLS-Authentifizierung akzeptabel.

VPC-Endpunkt-Service-Konnektivität – AWS KMS stellt eine Verbindung über einen AWS PrivateLink VPC-Endpunkt-Service her, den Sie erstellen und verwalten. Dies hält den Datenverkehr vom öffentlichen Internet fern und ist der empfohlene Ansatz für Produktions-Workloads.

Ihr Proxy muss erreichbar sein mit:

• TLS 1.2 oder höher mit einem gültigen Zertifikat Der Proxy-URI-Pfad muss /kms/xks/v1 sein (oder ein Präfix, das auf diesem Pfad endet)
• Port 443 (HTTPS)
• Reaktionszeit konstant unter 250 ms

---

Schritt-für-Schritt-Implementierungsanleitung

Schritt 1: Richten Sie Ihren externen Schlüsselmanager ein

Konfigurieren Sie den Schlüsselmanager Ihrer Wahl, um AES-256-Schlüssel zu generieren und zu speichern. Notieren Sie sich die externe Schlüssel-ID (XksKeyId) für jeden Schlüssel, den Sie verwenden möchten – Sie werden beim Erstellen von KMS-Schlüsseln darauf verweisen.

Stellen Sie sicher, dass Ihr Schlüsselmanager mit hoher Verfügbarkeit bereitgestellt wird. Mindestens: Aktiv-Passiv-Failover. Für die Produktion: Aktiv-Aktiv über zwei oder mehr unabhängige Knoten.

Schritt 2: Stellen Sie den XKS-Proxy bereit

Ihr Proxy ist der entscheidende Teil. Bereitstellungsoptionen:

Lokaler Proxy, der über einen öffentlichen Endpunkt eine Verbindung herstellt: Der Proxy wird in Ihrem Rechenzentrum ausgeführt und über einen öffentlichen HTTPS-Endpunkt bereitgestellt. Nur verwenden, wenn die VPC-Konnektivität nicht möglich 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 über PrivateLink her.

Lokale Proxy-Verbindung über VPC: Führen Sie den Proxy lokal aus, verbinden Sie ihn jedoch über ein Site-to-Site-VPN oder Direct Connect mit einem VPC-Endpunktdienst. Maximale Sicherheit, maximale Komplexität.

Für eine hohe Verfügbarkeit stellen Sie Proxy-Instanzen in mehreren Availability Zones hinter einem Network Load Balancer bereit.

Die Authentifizierung zwischen KMS und Ihrem Proxy verwendet ein SigV4-ähnliches Anmeldeinformationsschema – eine Zugriffsschlüssel-ID und einen geheimen Zugriffsschlüssel, die Sie sowohl auf dem Proxy als auch in KMS konfigurieren. Wechseln Sie diese Anmeldeinformationen regelmässig.

Der XKS-Proxy: Tiefer Einblick

Der Proxy verdient besondere Aufmerksamkeit, da er die häufigste Ursache für Implementierungsprobleme ist.

Der Proxy implementiert die [AWS

Proxy-Sicherheitsanforderungen

• mTLS- oder SigV4-Authentifizierung für alle KMS-zu-Proxy-Anfragen Der Proxy muss überprüfen, ob Anfragen ein gültiges requestMetadata-Feld enthalten, das den AWS-Prinzipal-ARN und den KMS-Schlüssel-ARN enthält – dies ermöglicht Ihnen die Implementierung zusätzlicher Autorisierung auf der Proxy-Ebene über IAM hinaus
• Die gesamte Kommunikation wird während der Übertragung verschlüsselt; keine ausnahmen Der Proxy sollte kein Schlüsselmaterial speichern – er übersetzt Anfragen, er speichert keine Geheimnisse zwischen

Erstellen eines benutzerdefinierten Proxys

AWS stellt eine Open-Source-Referenzimplementierung in Rust bereit, die als Container ausgeführt werden kann und mit jedem PKCS#11-HSM kompatibel ist. Dies ist ein sinnvoller Ausgangspunkt für Organisationen, die nicht vom Hersteller unterstützte Schlüsselmanager verwenden.

Für Produktionszwecke hinzufügen:

• Anfrage-/Antwortprotokollierung (ohne Protokollierung von Schlüsselmaterial)
• Strombegrenzung und Leistungsschalter
• Endpunkte zur Integritätsprüfung für die Load-Balancer-Integration
• Export von Metriken nach CloudWatch oder Ihrem Observability Stack

Überlegungen zur Proxy-Leistung

Jeder KMS-Aufruf für einen XKS-gestützten Schlüssel beinhaltet einen externen Netzwerk-Roundtrip. Bei Workloads, die Tausende von KMS-Anfragen pro Sekunde generieren, summiert sich das. AWS speichert Datenschlüssel auf Serviceebene zwischen (z. B. speichert S3 Datenschlüssel einige Minuten lang, wenn Bucket-Schlüssel aktiviert sind), wodurch sich das reine Anforderungsvolumen an Ihren Proxy verringert – Sie müssen jedoch dennoch eine Kapazitätsplanung für Spitzenlasten durchführen.

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 für die Sicherheit

Verwenden Sie die VPC-Endpunkt-Dienstkonnektivität – stellen Sie Ihren Proxy-Endpunkt niemals öffentlich zur Verfügung, es sei denn, dies ist unbedingt erforderlich. Das zusätzliche PrivateLink-Setup ist die reduzierte Angriffsfläche 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 können nur bestimmte externe Schlüssel verwenden, bestimmte Vorgänge werden ausserhalb der Geschäftszeiten blockiert usw.

Rotieren Sie die Anmeldeinformationen für die Proxy-Authentifizierung nach einem definierten Zeitplan. Verwenden Sie AWS Secrets Manager, um den geheimen Zugriffsschlüssel, der für die KMS-zu-Proxy-Authentifizierung verwendet wird, zu speichern und automatisch zu rotieren.

Überwachen 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 auslösen.

Schlüssellebenszyklusverwaltung – Dokumentieren Sie explizite Verfahren für die Schlüsselrotation (Ihr externer Schlüsselmanager kann Schlüsselmaterial hinter derselben XksKeyId rotieren), Schlüssellöschung (Koordination zwischen KMS-Schlüssellöschung und externer Schlüssellöschung – eine falsche Reihenfolge führt zu dauerhaftem Datenverlust) und Notfallschlüsselsperrung (Ihr Proxy ist der Kill-Schalter: Schalten Sie ihn offline und alle XKS-Vorgänge werden eingestellt).

Notfallwiederherstellung – Führen Sie ein getestetes Wiederherstellungs-Runbook. Wenn Ihr externer Schlüsselmanager einen katastrophalen Ausfall erleidet, müssen Sie ihn wiederherstellen und erneut verbinden, bevor mit XKS-Schlüsseln verschlüsselte Daten dauerhaft unzugänglich werden. Sichern Sie Ihr externes Schlüsselmaterial mithilfe der nativen Sicherungsmechanismen Ihres Schlüsselmanagers.

---

Häufige Herausforderungen und Fehlerbehebung

Verbindungsfehler

XKS_PROXY_NOT_REACHABLE – KMS kann den Proxy-Endpunkt nicht erreichen. Überprüfen Sie: Netzwerkrouting, Sicherheitsgruppenregeln, NLB-Gesundheitsprüfungen, Proxy-Prozessstatus.

XKS_PROXY_TIMED_OUT – Proxy erreichbar, antwortet aber nicht innerhalb des Timeouts. Überprüfen Sie: Proxy-Anwendungsprotokolle, Latenz des externen Schlüsselmanagers, CPU/Speicher der Proxy-Instanz, Netzwerklatenz zwischen Proxy und Schlüsselmanager.

XKS_PROXY_INVALID_RESPONSE – Der Proxy hat geantwortet, aber die Antwort entspricht nicht der XKS-API-Spezifikation. Überprüfen Sie die Proxy-Implementierung auf Nichtübereinstimmungen der API-Version oder Serialisierungsfehler.

Authentifizierungsfehler

XKS_PROXY_ACCESS_DENIED – Nichtübereinstimmung der Anmeldeinformationen zwischen KMS und Proxy-Konfiguration. Stellen Sie sicher, dass AccessKeyId und RawSecretAccessKey auf beiden Seiten genau übereinstimmen. Bei den Anmeldeinformationen muss die Gross-/Kleinschreibung beachtet werden.

Schlüsselthemen

XKS_KEY_NOT_FOUND – Die in KMS referenzierte XksKeyId ist in Ihrem externen Schlüsselmanager nicht vorhanden oder der Proxy kann sie nicht finden. Stellen Sie sicher, dass die Schlüssel-ID korrekt ist und der Schlüssel in Ihrem externen Schlüsselmanager aktiviert ist.

XKS_KEY_DISABLED_IN_EXTERNAL_KEY_MANAGER – Der Schlüssel ist auf der Ebene des externen Schlüsselmanagers deaktiviert. Dies ist unabhängig vom aktivierten Status des KMS-Schlüssels. An der Quelle erneut aktivieren.

Compliance- und Audit-Überlegungen

XKS erstellt ein komplexeres Audit-Trail als Standard-KMS, aber ein vollständigeres – wenn Sie es richtig instrumentieren.

CloudTrail protokolliert jeden KMS-API-Aufruf mit XKS-Schlüsseln, einschliesslich des aufrufenden Prinzipals, des Schlüssel-ARN und des Vorgangsergebnisses. Dies ist Ihr primäres Audit-Artefakt, um den Aufsichtsbehörden die Kontrolle über die Schlüsselnutzung zu demonstrieren.

Protokolle auf Proxy-Ebene erfassen jede Anfrage, die von KMS an Ihren externen Schlüsselmanager weitergeleitet wird. Wenn Sie die Protokollierung der requestMetadata (einschliesslich des ursprünglichen AWS-Principal-ARN) konfigurieren, verfügen Sie über einen durchgängigen Prüfpfad vom AWS-Serviceaufruf bis zum kryptografischen Betrieb.

Externe Schlüsselmanager-Überwachungsprotokolle liefern die massgebliche Aufzeichnung darüber, welche Schlüssel wann und von welcher Proxy-Identität verwendet wurden.

Zur Einhaltung der DSGVO/Schrems II dokumentieren Sie Folgendes:

• Physischer Standort des externen Schlüsselmanagers
• Zugriffskontrollrichtlinien für den externen Schlüsselmanager
• Netzwerkpfad von AWS zum Proxy (VPC-Endpunktdienst ist ideal)
• Wichtige Sicherungs- und Wiederherstellungsverfahren, die geografische Beschränkungen wahren
• Verfahren zur Reaktion auf Vorfälle bei Schlüsselkompromittierung

Stellen Sie für PCI-DSS sicher, dass der externe Schlüsselmanager die Schlüsselverwaltungsanforderungen gemäss PCI-DSS v4.0 Anforderung 3.7 erfüllt, einschliesslich der Verfahren der doppelten Kontrolle und des Split-Knowledge-Verfahrens für Schlüsselverwalter.

---

FAQ

F: Was ist AWS XKS?

AWS XKS (External Key Store) ist eine Funktion von AWS KMS, mit der Sie Verschlüsselungsschlüssel verwenden können, die vollständig ausserhalb der AWS-Infrastruktur gespeichert und verwaltet werden. Ihre Schlüssel befinden sich in Ihrem externen Schlüsselmanager; AWS ruft Ihren XKS-Proxy immer dann auf, wenn er kryptografische Vorgänge ausführen muss.

F: Wann benötige ich XKS anstelle von Standard-KMS?

Wenn Vorschriften oder Organisationsrichtlinien ausdrücklich vorschreiben, dass sich kryptografisches Schlüsselmaterial niemals auf der Infrastruktur Dritter (einschliesslich Cloud-Anbietern) befinden darf. Zu den häufigsten Treibern gehören DSGVO + Schrems II für die EU-Datensouveränität, die Abschwächung des CLOUD Act und bestimmte Vorschriften für den Finanzsektor. Für 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 Schlüsselmanager und übersetzt AWS XKS-API-Anfragen in das native Protokoll Ihres Schlüsselmanagers. Es bietet ausserdem eine zusätzliche Autorisierungsebene und fungiert als Kill-Switch – deaktivieren Sie den Proxy und alle XKS-Verschlüsselungs-/Entschlüsselungsvorgänge werden gestoppt.

F: Was passiert, wenn mein externer Schlüsselmanager ausfällt?

AWS-Services, die auf XKS-gestützten Schlüsseln basieren, können keine neuen Verschlüsselungs- oder Entschlüsselungsvorgänge durchführen. Einige Dienste (z. B. S3 mit aktivierten Bucket-Schlüsseln) speichern Datenschlüssel einige Minuten lang zwischen und sorgen so für kurze Ausfallsicherheit. Ein längerer Ausfall bedeutet jedoch, dass Ihre AWS-Workloads keine verschlüsselten Daten verarbeiten können. Hohe Verfügbarkeit ist nicht verhandelbar.

F: Kann ich XKS mit allen AWS-Diensten verwenden?

XKS funktioniert mit den meisten AWS-Diensten, die vom Kunden verwaltete KMS-Schlüssel unterstützen, einschliesslich S3, EBS, RDS, DynamoDB, Lambda und andere. AWS validiert und dokumentiert schrittweise den Support pro Service. Überprüfen 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 Schlüsselmaterial befindet sich in der von Ihnen betriebenen Infrastruktur, vollständig ausserhalb der AWS-eigenen Einrichtungen. XKS weist eine höhere betriebliche Komplexität, höhere Gesamtkosten und eine höhere Latenz auf als CloudHSM.

F: Wie funktioniert die Schlüsselrotation mit XKS?

Die Rotation ist komplexer als das Standard-KMS. Sie können die automatische KMS-Schlüsselrotation nicht für XKS-Schlüssel verwenden. Stattdessen rotiert Ihr externer Schlüsselmanager das mit derselben XksKeyId verknüpfte Schlüsselmaterial – AWS KMS verweist weiterhin auf dieselbe Schlüssel-ID und Ihr Schlüsselmanager verwendet transparent das neue Schlüsselmaterial. Koordinieren Sie sorgfältig die Rotationsverfahren zwischen Ihrem Key-Manager-Betriebsteam und Ihrem AWS-Team.

F: Kann ich vorhandene KMS-verschlüsselte Daten zu XKS migrieren?

Nicht direkt. Es gibt keinen Neuverschlüsselungspfad, der vorhandene CMK-verschlüsselte Daten zu XKS verschiebt, ohne jedes Objekt zu entschlüsseln und erneut zu verschlüsseln. Für S3 bedeutet dies, alle Objekte zu durchlaufen; Für EBS-Volumes benötigen Sie Snapshot- und Wiederherstellungsworkflows. Planen Sie die Migration sorgfältig und planen Sie viel Zeit und Kosten für grosse Datensätze ein.

---

Fazit: Ist XKS das Richtige für Sie?

XKS wurde speziell für ein enges, spezifisches Compliance-Szenario entwickelt. Es hält, was es verspricht – kryptografisches Schlüsselmaterial unter Ihrer ausschliesslichen Kontrolle, ausserhalb der AWS-Infrastruktur – allerdings auf Kosten einer erheblichen betrieblichen Komplexität, höherer Latenz und wesentlich höherer Kosten.

Verwenden Sie diese Checkliste, bevor Sie sich verpflichten:

• Ihr Rechts- oder Compliance-Team hat ausdrücklich bestätigt, dass die Vorschriften erfordern, dass sich Schlüsselmaterial ausserhalb der Infrastruktur des Cloud-Anbieters befindet (nicht nur starke Schlüsselkontrolle im Allgemeinen).
• Sie haben einen kompatiblen externen Schlüsselmanager und eine praktikable XKS-Proxy-Bereitstellung identifiziert
• Sie können eine Roundtrip-Latenz von unter 250 ms von Ihrem Proxy zum externen Schlüsselmanager aufrechterhalten
• Sie verfügen über die operative Fähigkeit, einen hochverfügbaren Schlüsselverwaltungsdienst auszuführen
• Sie haben insgesamt Betriebskosten in Höhe von 7.000 bis 20.000 US-Dollar pro Monat veranschlagt
• Sie verfügen über einen getesteten Disaster-Recovery-Plan für Ausfälle wichtiger Manager
• Sie haben geprüft, welche AWS-Dienste Sie nutzen, und die XKS-Unterstützung für jeden bestätigt

Wenn Sie all dies überprüfen können, ist XKS eine gut durchdachte Lösung für ein schwieriges Problem. Wenn Sie weniger als vier prüfen, werfen Sie einen weiteren Blick auf CloudHSM oder gut verwaltete CMKs – sie erfüllen möglicherweise Ihre tatsächlichen Anforderungen mit weitaus geringerem Betriebsaufwand.

---

Referenzen

• AWS KMS External Key Store – Offizielle Dokumentation
• Ankündigung des externen Schlüsselspeichers für AWS KMS – AWS-Sicherheitsblog
• AWS XKS Proxy-Referenzimplementierung (GitHub)
• AWS Digital Sovereignty Pledge
• NIST SP 800-57: Wichtige Managementrichtlinien
• PCI-DSS v4.0-Schlüsselverwaltungsanforderungen
• DSGVO Artikel 32 – Sicherheit der Verarbeitung
• Fortanix DSM XKS-Integration
• Thales CipherTrust XKS-Lösung
• AWS Well-Architected Framework – Sicherheitssäule
• Cloud Security Alliance: Richtlinien zur Cloud-Schlüsselverwaltung