So funktioniert AWS KMS External Key Store (XKS): Proxy-Setup mit CLI, 250-ms- und 35-ms-Grenzen, Fehlercodes und wann XKS besser passt als CloudHSM.
AWS External Key Store (XKS) ist ein benutzerdefinierter Schlüsselspeicher von AWS KMS, hinter dem ein Schlüsselmanager steht, den Sie ausserhalb von AWS betreiben. AWS-Dienste rufen AWS KMS wie gewohnt auf, aber jede Ver- und Entschlüsselung unter einem XKS-Schlüssel braucht zusätzlich Ihren externen Schlüssel, erreichbar über einen XKS-Proxy, den Sie betreiben. AWS KMS kann diesen Schlüssel weder erstellen noch einsehen noch löschen, und wenn Sie den Proxy trennen, kann AWS die Daten nicht mehr entschlüsseln (AWS KMS Developer Guide).
Diese Kontrolle hat ihren Preis: zusätzliche Komplexität und eine Verschiebung der betrieblichen Verantwortung. Dieser Leitfaden erklärt, was der AWS External Key Store ist, ob Sie ihn brauchen, wie Sie XKS-Proxy und Schlüsselspeicher Schritt für Schritt einrichten, welche Latenz- und Verfügbarkeitsgrenzen AWS setzt, welche Fehlercodes Ihnen begegnen und was das alles über die KMS-Rechnung hinaus kostet.
AWS External Key Store (XKS) ist eine Funktion des AWS Key Management Service (KMS), mit der Sie Verschlüsselungsschlüssel verwenden, die vollständig ausserhalb der AWS-Infrastruktur erzeugt, gespeichert und verwaltet werden, in Hardware oder Software, die Sie besitzen und kontrollieren.
XKS wurde auf der re:Invent 2022 angekündigt und ist heute eine ausgereifte Funktion. Sie schliesst eine konkrete Lücke: Organisationen brauchen die Bandbreite der AWS-Dienste, dürfen aber aufgrund von Regulierung oder interner Richtlinie ihre kryptografischen Stammschlüssel nicht auf AWS-Infrastruktur ablegen.
Beim Standard-AWS-KMS verwaltet Amazon das Schlüsselmaterial in der eigenen Infrastruktur. Sie kontrollieren den Zugriff auf die Schlüssel, die Schlüssel selbst liegen aber bei AWS. XKS kehrt das um: Ihre Schlüssel liegen in Ihrer Infrastruktur, und AWS ruft sie auf, wenn eine kryptografische Operation nötig ist.
| Begriff | Definition |
|---|---|
| External Key Store (XKS) | Ein benutzerdefinierter Schlüsselspeicher, hinter dem Ihr externer Schlüsselmanager steht |
| XKS-Proxy | Vom Kunden betriebene Middleware, die KMS-Aufrufe in das Protokoll Ihres Schlüsselmanagers übersetzt |
| Externer Schlüsselmanager | Ihr HSM, Software-KMS oder Ihre Schlüsselverwaltungsplattform ausserhalb von AWS |
| XksKeyId | Die Kennung Ihres externen Schlüssels, verknüpft mit einem KMS-Schlüssel |
| Doppelte Verschlüsselung | Die Daten werden zuerst von AWS KMS und dann erneut von Ihrem externen Schlüsselmanager verschlüsselt |
Eine Klarstellung, die viele Architekten überrascht: XKS nutzt doppelte Verschlüsselung. Jeder XKS-gestützte KMS-Schlüssel hat zwei zugrunde liegende Schlüssel: KMS-Schlüsselmaterial, das in den HSMs von AWS KMS erzeugt wird, und Ihren externen Schlüssel. Die Daten werden mit dem ersten verschlüsselt, das Ergebnis dann mit dem zweiten. Ein XKS-Chiffretext ist damit immer mindestens so stark wie ein Standard-KMS-Chiffretext, und weder AWS KMS noch der Inhaber des externen Schlüssels können ihn allein entschlüsseln (AWS: Double encryption).
(AWS KMS Developer Guide: External key stores)
Bevor Sie sich für XKS entscheiden, sollten Sie den Ablauf einer Anfrage kennen. Jede Ver- oder Entschlüsselung folgt diesem Pfad:
Dieser Roundtrip läuft synchron. Laut Proxy-API-Spezifikation bricht KMS einen Aufruf ab, wenn der XKS-Proxy nicht innerhalb von 250 ms antwortet, und die Ping-Latenz zwischen AWS-Region und Ihrem Schlüsselmanager sollte höchstens 35 ms betragen (XKS Proxy API Specification). Schlägt ein Schritt fehl, schlägt die KMS-Operation fehl, und je nach AWS-Dienst kann sich der Fehler fortpflanzen.
Der Klartext-Datenschlüssel wird nie an den Proxy gesendet: AWS KMS schickt den Chiffretext, den es mit seinem eigenen Schlüsselmaterial erzeugt hat, und Ihr Schlüsselmanager verschlüsselt diesen.
Hier unterschätzen viele Organisationen XKS. Beim Standard-KMS kümmert sich AWS um Verfügbarkeit, Patches, Skalierung und Disaster Recovery der Schlüsselinfrastruktur. Bei XKS übernehmen Sie all das für Proxy und externen Schlüsselmanager, einschliesslich Rechenzentrum, Strom, Kühlung, Netzwerk, Betriebssystem und Anwendung.
Fällt Ihr externer Schlüsselmanager aus, können AWS-Dienste mit XKS-Schlüsseln weder ver- noch entschlüsseln. Das ist kein theoretischer Fehlerfall, sondern das vorgesehene Verhalten, und es ist Ihre Aufgabe, dagegen vorzusorgen.
Bevor Sie in XKS investieren, vergleichen Sie es ehrlich mit den Alternativen.
Mit kundenverwalteten Schlüsseln (CMKs) kontrollieren Sie Richtlinien und Zugriff: wer den Schlüssel unter welchen Bedingungen nutzen darf, mit vollständiger Protokollierung. Das Schlüsselmaterial liegt aber weiterhin in der KMS-Infrastruktur von AWS.
CMKs passen, wenn Sie starke Zugriffskontrolle und Nachvollziehbarkeit brauchen, Ihre Compliance aber nicht verlangt, dass das Schlüsselmaterial ausserhalb von AWS liegt.
XKS passt, wenn Regulierung oder Richtlinie ausdrücklich verlangen, dass kryptografisches Schlüsselmaterial nie auf der Infrastruktur eines Dritten (also AWS) liegt.
CloudHSM bietet dedizierte Single-Tenant-HSMs in AWS-Rechenzentren. Sie kontrollieren das HSM, seine Benutzer und seine Schlüssel, AWS hat keinen Zugriff auf das Schlüsselmaterial. Die HSMs stehen aber physisch in Einrichtungen von AWS.
| XKS | CloudHSM | |
|---|---|---|
| Schlüsselstandort | Ihre Infrastruktur | AWS-Rechenzentrum (dediziertes HSM) |
| Physischer Zugriff durch AWS | Keiner | Kein Zugriff auf HSM-Inhalte, aber die Hardware steht bei AWS |
| Latenz | Höher (externer Roundtrip) | Niedriger (im AWS-Netzwerk) |
| Verantwortung für Verfügbarkeit | Vollständig bei Ihnen | Geteilt (AWS verwaltet Hardware, Sie die HSM-Software) |
| Kosten | KMS-Schlüsselpreis plus Schlüsselmanager, Proxy und Netzwerk | Pro HSM und Stunde, plus KMS-Schlüsselpreis |
| Compliance-Eignung | Strenge Souveränitätsvorgaben | Vorgaben für dedizierte, validierte HSMs |
| Komplexität | Sehr hoch | Hoch |
Wählen Sie CloudHSM, wenn Sie dedizierte Single-Tenant-HSMs brauchen und akzeptieren, dass die Schlüssel physisch bei AWS liegen. Wählen Sie XKS nur, wenn Ihre Compliance ausdrücklich verlangt, dass Schlüssel vollständig ausserhalb von AWS-Einrichtungen bleiben. Einen direkten Vergleich beider Schlüsselspeichertypen finden Sie unter AWS KMS Custom Key Store: CloudHSM vs XKS.
Für die meisten Workloads, einschliesslich der meisten HIPAA-, PCI-DSS- und SOC-2-Anforderungen, reichen kundenverwaltete Standard-KMS-Schlüssel. XKS ist für die wenigen Vorgaben gebaut (bestimmte EU-Souveränitätsanforderungen, einzelne Finanzmarktregeln, US-Behördenvorgaben), die keinerlei Zugriff des Cloud-Anbieters auf Schlüsselmaterial verlangen.
Stellen Sie diese drei Fragen der Reihe nach:
XKS ist für ein bestimmtes Compliance-Szenario gedacht, nicht als allgemeine Sicherheitsverbesserung. Typische legitime Fälle:
Regulatorische Datensouveränität: Die DSGVO, verschärft durch das Schrems-II-Urteil, verlangt von EU-Organisationen den Nachweis, dass Schlüssel ihre kontrollierte Rechtsordnung nicht verlassen und dass sie dem Cloud-Anbieter den Zugriff jederzeit entziehen können. XKS erfüllt das, indem die Schlüssel in EU-Infrastruktur ausserhalb von AWS liegen.
Risiko aus dem CLOUD Act: Organisationen, die den US CLOUD Act berücksichtigen müssen, nutzen XKS, damit AWS auch unter Zwang keinen Zugriff auf Schlüsselmaterial hat. Ihr externer Schlüsselmanager in einer anderen Rechtsordnung hält die einzige Kopie.
Vorgaben im Finanzsektor: Bestimmte Aufsichtsrahmen verlangen operative Resilienz, einschliesslich der Kontrolle über kryptografisches Material ausserhalb des primären Cloud-Anbieters.
Behörden und Verteidigung: US-Behörden mit CUI oder eingestuften Daten unter FedRAMP High oder DoD IL können ausdrückliche Vorgaben zur Schlüsselverwahrung haben.
Zero-Trust-Schlüsselarchitektur: Organisationen, in denen kein einzelner Anbieter gleichzeitig Daten und Schlüssel vollständig kontrollieren darf.
Wofür XKS nicht gedacht ist: allgemeine Härtung, HIPAA-Compliance (Standard-KMS reicht), Abbau von Lock-in aus nicht kryptografischen Gründen oder Kostensenkung. XKS ist teurer und komplexer als jede Alternative.
Prüfen Sie vor der Umsetzung alle folgenden Punkte.
Ihr externer Schlüsselmanager muss:
Der externe Schlüsselmanager kann ein physisches HSM, ein virtuelles HSM oder ein Software-Schlüsselmanager mit oder ohne HSM-Komponente sein, vor Ort oder in einer beliebigen Cloud (AWS). Die Optionen für den Proxy davor vergleicht der Abschnitt XKS-Proxy-Optionen.
XKS unterstützt zwei Konnektivitätsmodelle:
Öffentlicher Endpunkt: AWS KMS erreicht Ihren Proxy per HTTPS über das Internet. Einfacher einzurichten, aber Ihr Proxy-Endpunkt ist öffentlich erreichbar.
VPC-Endpunktdienst: AWS KMS verbindet sich über einen AWS-PrivateLink-VPC-Endpunktdienst, den Sie erstellen und betreiben. Der Verkehr bleibt ausserhalb des öffentlichen Internets; das ist der empfohlene Weg für Produktion.
Ihr Proxy muss erreichbar sein mit:
/kms/xks/v1 (oder einem Präfix, das auf diesen Pfad endet)Konfigurieren Sie Ihren Schlüsselmanager so, dass er AES-256-Schlüssel erzeugt und speichert. Notieren Sie die externe Schlüssel-ID (XksKeyId) jedes Schlüssels, den Sie verwenden wollen; Sie brauchen sie beim Erstellen der KMS-Schlüssel.
Betreiben Sie den Schlüsselmanager hochverfügbar. Mindestens Aktiv-Passiv-Failover, für Produktion Aktiv-Aktiv über zwei oder mehr unabhängige Knoten.
Der Proxy ist das kritische Element. Bereitstellungsoptionen:
Proxy vor Ort über öffentlichen Endpunkt: Der Proxy läuft in Ihrem Rechenzentrum und ist über einen öffentlichen HTTPS-Endpunkt erreichbar. Nur, wenn VPC-Konnektivität nicht möglich ist.
Proxy auf EC2 in einer VPC (empfohlen): Der Proxy läuft auf einer EC2-Instanz in einem privaten Subnetz. Ein VPC-Endpunktdienst zeigt auf einen Network Load Balancer vor dem Proxy, AWS KMS verbindet sich über PrivateLink.
Proxy vor Ort, angebunden über VPC: Der Proxy läuft vor Ort und ist über Site-to-Site-VPN oder Direct Connect mit einem VPC-Endpunktdienst verbunden. Höchste Sicherheit, höchste Komplexität.
Für Hochverfügbarkeit verteilen Sie Proxy-Instanzen über mehrere Availability Zones hinter einem Network Load Balancer.
Die Authentifizierung zwischen KMS und Proxy nutzt eine SigV4-Proxy-Anmeldeinformation: eine Access Key ID und einen Secret Access Key, die Sie auf dem Proxy und in KMS hinterlegen. Verwenden Sie dafür nie IAM-Anmeldeinformationen. AWS empfiehlt, dass der Proxy mindestens zwei gültige Anmeldeinformationen akzeptiert, damit Sie ohne Unterbrechung rotieren können, und stellt dafür die CloudWatch-Metrik XksProxyCredentialAge bereit (AWS).
Erstellen Sie den externen Schlüsselspeicher mit der AWS CLI:
# Create external key store with VPC endpoint service connectivity
aws kms create-custom-key-store \
--custom-key-store-name "MyExternalKeyStore" \
--custom-key-store-type EXTERNAL_KEY_STORE \
--xks-proxy-connectivity "VPC_ENDPOINT_SERVICE" \
--xks-proxy-uri-endpoint "https://myproxy-private.xks.example.com" \
--xks-proxy-uri-path "/kms/xks/v1" \
--xks-proxy-vpc-endpoint-service-name "com.amazonaws.vpce.us-east-1.vpce-svc-0example" \
--xks-proxy-authentication-credential \
AccessKeyId=ABCDE12345670EXAMPLE,RawSecretAccessKey=supersecretkeyvalue
Schlüsselspeicher verbinden:
aws kms connect-custom-key-store \
--custom-key-store-id cks-1234567890abcdef0
Verbindungsstatus prüfen:
aws kms describe-custom-key-stores \
--custom-key-store-id cks-1234567890abcdef0
Eine gesunde Antwort zeigt "ConnectionState": "CONNECTED".
aws kms create-key \
--custom-key-store-id cks-1234567890abcdef0 \
--xks-key-id "your-external-key-id" \
--description "XKS-backed key for S3 bucket encryption" \
--key-usage ENCRYPT_DECRYPT
Hängen Sie eine Schlüsselrichtlinie an, die den benötigten Diensten und Prinzipalen Zugriff gibt:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Enable KMS key administration",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/KeyAdminRole"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*"
],
"Resource": "*"
},
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/AppRole"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
Testen Sie die Verbindung ausdrücklich, bevor Sie den Schlüsselspeicher produktiv nutzen:
# Test encrypt/decrypt round-trip
aws kms generate-data-key \
--key-id "arn:aws:kms:us-east-1:123456789012:key/your-key-id" \
--key-spec AES_256
Testen Sie Ausfallszenarien: Nehmen Sie den Proxy offline und prüfen Sie, ob die AWS-Dienste den Fehler sauber behandeln und sich nach der Rückkehr des Proxys erholen. Überspringen Sie diesen Test in Staging nie.
Der Proxy verdient besondere Aufmerksamkeit, denn er ist die häufigste Ursache für Probleme bei der Umsetzung.
Der Proxy implementiert die AWS KMS External Key Store Proxy API Specification, eine REST-API über HTTPS mit vier Operationen:
| Proxy-API | Was AWS KMS anfragt | Ausgelöst durch |
|---|---|---|
GetKeyMetadata | Typ (AES_256), Verwendung und Status des externen Schlüssels | CreateKey |
Encrypt | Verschlüsseln mit dem externen Schlüssel (AES-GCM) | Encrypt, GenerateDataKey, ReEncrypt |
Decrypt | Entschlüsseln mit dem externen Schlüssel (AES-GCM) | Decrypt, ReEncrypt |
GetHealthStatus | Zustand von Proxy und Schlüsselmanager: Active, Degraded oder Unavailable | Erstellen oder Verbinden des Schlüsselspeichers |
requestMetadata mit dem ARN des AWS-Prinzipals und dem ARN des KMS-Schlüssels auswerten; damit können Sie auf Proxy-Ebene zusätzlich zu IAM autorisierenAWS stellt eine Open-Source-Referenzimplementierung in Rust bereit, die als Container läuft und mit jedem PKCS#11-HSM zusammenarbeitet. Ein sinnvoller Ausgangspunkt für Schlüsselmanager ohne Herstellerunterstützung.
Für die Produktion ergänzen Sie:
Jeder KMS-Aufruf mit einem XKS-Schlüssel bedeutet einen externen Netzwerk-Roundtrip. Bei Tausenden KMS-Anfragen pro Sekunde summiert sich das. AWS-Dienste cachen Datenschlüssel teilweise (z. B. S3 mit Bucket Keys für einige Minuten), was das Anfragevolumen am Proxy senkt; planen Sie die Kapazität trotzdem für Lastspitzen.
Testen Sie den Proxy vor dem Go-live unter realistischer Last. XKS_PROXY_TIMED_OUT zeigt, dass der Proxy zu langsam ist; XKS_PROXY_INVALID_RESPONSE deutet auf ein Protokollproblem hin. AWS stellt zudem einen Test-Client bereit, der einen Proxy gegen die Spezifikation prüft.
Jeder AWS External Key Store braucht genau einen XKS-Proxy. AWS erlaubt, ihn anhand der offenen Spezifikation selbst zu bauen oder von einem Anbieter zu kaufen; der Proxy kann auch Teil des Schlüsselmanagers sein (AWS).
| Option | Was Sie bekommen | Was Sie betreiben |
|---|---|---|
| AWS-Beispielproxy (aws-kms-xks-proxy) | Open-Source-Referenzimplementierung in Rust, die per PKCS#11 mit einem HSM spricht | Proxy, Hochverfügbarkeit, TLS, Anmeldeinformationen, Logging und das HSM dahinter |
| Proxy eines HSM- oder Schlüsselmanagement-Anbieters | Ein in Appliance oder Dienst des Anbieters integrierter Proxy. Thales (CipherTrust), Fortanix, Entrust und Securosys veröffentlichen XKS-Integrationen | Appliance oder Cluster des Anbieters bzw. dessen gehosteten Dienst |
| DuoKey XKS Proxy | In DuoKey Cockpit integriert; jeder Endpunkt ist an einen Tresor und einen AES-256-Schlüssel gebunden | Nichts zu installieren; siehe unten |
Fragen an jeden Anbieter vor der Wahl:
requestMetadata (aufrufender Prinzipal, KMS-Schlüssel-ARN) durchsetzen?DuoKey für AWS XKS implementiert die XKS-Proxy-Spezifikation als eingebaute Funktion von DuoKey Cockpit. Es gibt keinen separaten Proxy zu installieren: Sie stellen einen XKS-Endpunkt in derselben Cockpit-Oberfläche bereit wie Ihre anderen Apps und Schlüssel, und jeder Endpunkt ist an den gewählten Tresor und Schlüssel gebunden (DuoKey Docs: AWS XKS).
Zur Abwägung zwischen eigener Schlüsselhaltung und Schlüsselhaltung beim Anbieter siehe Hold Your Own Key (HYOK).
VPC-Endpunktdienst nutzen: Stellen Sie den Proxy-Endpunkt nur öffentlich bereit, wenn es nicht anders geht. Der zusätzliche PrivateLink-Aufwand lohnt sich durch die kleinere Angriffsfläche.
Autorisierung auf Proxy-Ebene: Die requestMetadata jeder KMS-Anfrage enthalten den ARN des aufrufenden Prinzipals. Nutzen Sie das für feingranulare Regeln: Bestimmte IAM-Rollen dürfen nur bestimmte externe Schlüssel verwenden, bestimmte Operationen sind ausserhalb der Geschäftszeiten gesperrt usw.
Proxy-Anmeldeinformationen rotieren: nach festem Plan. Speichern und rotieren Sie den Secret Access Key für die KMS-zu-Proxy-Authentifizierung zum Beispiel mit AWS Secrets Manager.
Alle Proxy-Fehler überwachen und alarmieren: Achten Sie besonders auf XKS_PROXY_TIMED_OUT, XKS_PROXY_NOT_REACHABLE und Fehler bei der Schlüsselnutzung in CloudTrail. Jede anhaltende Fehlerrate sollte einen Incident auslösen.
Schlüssellebenszyklus: Dokumentieren Sie Verfahren für Rotation (Ihr Schlüsselmanager kann das Material hinter derselben XksKeyId rotieren), Löschung (KMS-Schlüssel und externen Schlüssel koordiniert löschen; die falsche Reihenfolge führt zu dauerhaftem Datenverlust) und Notfallsperrung (der Proxy ist der Notschalter: offline nehmen, und alle XKS-Operationen stoppen).
Disaster Recovery: Halten Sie ein getestetes Wiederherstellungs-Runbook bereit. Fällt Ihr externer Schlüsselmanager katastrophal aus, müssen Sie ihn wiederherstellen und neu verbinden, bevor XKS-verschlüsselte Daten dauerhaft unzugänglich werden. Sichern Sie das externe Schlüsselmaterial mit den Backup-Mechanismen Ihres Schlüsselmanagers.
XKS_PROXY_NOT_REACHABLE: KMS erreicht den Proxy-Endpunkt nicht. Prüfen Sie Routing, Security-Group-Regeln, NLB-Health-Checks und den Proxy-Prozess.
XKS_PROXY_TIMED_OUT: Proxy erreichbar, antwortet aber nicht innerhalb des Timeouts. Prüfen Sie Proxy-Logs, Latenz des Schlüsselmanagers, CPU und Speicher der Proxy-Instanz sowie die Netzwerklatenz zwischen Proxy und Schlüsselmanager. Liegt der Roundtrip zwischen Region und Schlüsselmanager über 35 ms, empfiehlt AWS, den Schlüsselspeicher in einer näheren Region anzulegen oder den Schlüsselmanager näher an AWS zu bringen.
XKS_PROXY_INVALID_RESPONSE: Der Proxy antwortet, aber nicht spezifikationskonform. Prüfen Sie die Implementierung auf abweichende API-Versionen oder Serialisierungsfehler.
XKS_PROXY_ACCESS_DENIED: Die Anmeldeinformationen in KMS und auf dem Proxy stimmen nicht überein. AccessKeyId und RawSecretAccessKey müssen auf beiden Seiten exakt gleich sein; Gross- und Kleinschreibung zählen.
XksKeyNotFoundException: Die bei CreateKey übergebene XksKeyId existiert im externen Schlüsselmanager nicht, oder der Proxy findet sie nicht. Prüfen Sie, ob es die Kennung ist, die der Proxy für diesen Schlüssel verwendet.
XksKeyInvalidConfigurationException: GetKeyMetadata hat einen Schlüssel geliefert, der nicht AES_256 ist, nicht für [ENCRYPT, DECRYPT] nutzbar ist oder im Schlüsselmanager DISABLED ist. Das ist unabhängig vom Status des KMS-Schlüssels. Beheben Sie es an der Quelle.
KMSInvalidStateException bei Ver- oder Entschlüsselung: Kryptografische Operationen von AWS KMS liefern diese Ausnahme für jeden Fehler, der mit Konfiguration oder Verbindung des externen Schlüsselspeichers zusammenhängt. Die Ursache steht im Text der Fehlermeldung (AWS: Troubleshooting external key stores).
# Check connection state and error codes
aws kms describe-custom-key-stores \
--custom-key-store-id cks-1234567890abcdef0
# CloudTrail -- filter for XKS-related errors
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventSource,AttributeValue=kms.amazonaws.com \
--start-time 2026-01-01T00:00:00Z
Aktivieren Sie das Zugriffslogging auf dem Proxy und korrelieren Sie Proxy-Logs und CloudTrail-Ereignisse über das Feld requestId, das in beiden vorkommt.
XKS erzeugt einen komplexeren Audit-Trail als Standard-KMS, aber einen vollständigeren, wenn Sie ihn richtig instrumentieren.
CloudTrail protokolliert jeden KMS-API-Aufruf mit XKS-Schlüsseln, einschliesslich aufrufendem Prinzipal, Schlüssel-ARN und Ergebnis. Das ist Ihr wichtigster Nachweis gegenüber Aufsichtsbehörden.
Proxy-Logs erfassen jede Anfrage, die KMS an Ihren externen Schlüsselmanager weiterleitet. Wenn Sie die requestMetadata (inklusive ARN des ursprünglichen AWS-Prinzipals) mitprotokollieren, haben Sie einen durchgängigen Pfad vom AWS-Dienstaufruf bis zur kryptografischen Operation.
Audit-Logs des externen Schlüsselmanagers sind die massgebliche Aufzeichnung, welche Schlüssel wann von welcher Proxy-Identität genutzt wurden.
Für DSGVO und Schrems II dokumentieren Sie:
Für PCI DSS muss der externe Schlüsselmanager die Schlüsselverwaltungsanforderungen von PCI DSS v4.0, Anforderung 3.7, erfüllen, einschliesslich Dual Control und Split Knowledge für Schlüsselverwalter.
F: Was ist AWS XKS?
AWS XKS (External Key Store) ist eine Funktion von AWS KMS, mit der Sie Schlüssel nutzen, die vollständig ausserhalb der AWS-Infrastruktur gespeichert und verwaltet werden. Ihre Schlüssel liegen in Ihrem externen Schlüsselmanager; AWS ruft Ihren XKS-Proxy auf, wann immer eine kryptografische Operation nötig ist.
F: Wann brauche ich XKS statt Standard-KMS?
Wenn Regulierung oder interne Richtlinie ausdrücklich verlangen, dass kryptografisches Schlüsselmaterial nie auf der Infrastruktur Dritter, auch nicht des Cloud-Anbieters, liegt. Häufige Treiber sind DSGVO und Schrems II, der CLOUD Act und bestimmte Vorgaben im Finanzsektor. Für die meisten HIPAA-, PCI-DSS- und SOC-2-Anforderungen reichen Standard-CMKs.
F: Was ist ein XKS-Proxy?
Der XKS-Proxy ist Middleware, die Sie besitzen und betreiben. Er sitzt zwischen AWS KMS und Ihrem externen Schlüsselmanager und übersetzt XKS-API-Anfragen in dessen Protokoll. Er bietet ausserdem eine zusätzliche Autorisierungsebene und dient als Notschalter: Proxy deaktivieren, und alle XKS-Ver- und -Entschlüsselungen stoppen.
F: Was passiert, wenn mein externer Schlüsselmanager ausfällt?
AWS-Dienste mit XKS-Schlüsseln können keine neuen Ver- oder Entschlüsselungen ausführen. Einige Dienste (z. B. S3 mit Bucket Keys) cachen Datenschlüssel für einige Minuten und überbrücken kurze Ausfälle. Ein längerer Ausfall bedeutet, dass Ihre AWS-Workloads keine verschlüsselten Daten verarbeiten können. Hochverfügbarkeit ist Pflicht.
F: Kann ich XKS mit allen AWS-Diensten nutzen?
Laut AWS unterstützen alle Dienste, die kundenverwaltete Schlüssel für symmetrische Verschlüsselung unterstützen, auch KMS-Schlüssel in einem externen Schlüsselspeicher, darunter S3, EBS und RDS. Prüfen Sie Ihren Dienst und Ihre Region immer in der aktuellen Dokumentation, bevor Sie sich festlegen.
F: Kostet XKS mehr als ein Standard-KMS-Schlüssel?
Nicht auf der AWS-Rechnung: AWS KMS berechnet Schlüssel in einem externen Schlüsselspeicher wie Standard-KMS-Schlüssel. Die Mehrkosten entstehen bei allem, was Sie selbst betreiben: externer Schlüsselmanager, XKS-Proxy, Load Balancing, Netzwerkanbindung und das Team, das sie betreibt.
F: Welche Latenz braucht ein AWS External Key Store?
Der XKS-Proxy muss jeden Aufruf innerhalb von 250 ms beantworten, sonst bricht AWS KMS ab, und die Spezifikation verlangt höchstens 35 ms Ping-Latenz zwischen AWS-Region und Schlüsselmanager. Legen Sie den Schlüsselspeicher in der Region an, die Ihrem Schlüsselmanager am nächsten liegt.
F: Welche Anbieter bieten einen XKS-Proxy an?
Sie können einen anhand der offenen AWS-Spezifikation und des Rust-Beispiels selbst bauen oder einen Anbieter-Proxy nutzen. Thales, Fortanix, Entrust und Securosys veröffentlichen XKS-Integrationen, und DuoKey liefert einen in DuoKey Cockpit integrierten XKS-Proxy mit einem MPC-Tresor als eines der Backends. Siehe XKS-Proxy-Optionen.
F: Ist XKS dasselbe wie CloudHSM?
Nein. CloudHSM bietet dedizierte Hardware-HSMs in AWS-Rechenzentren unter Ihrer alleinigen Kontrolle. XKS geht weiter: Ihr Schlüsselmaterial liegt in Infrastruktur, die Sie betreiben, vollständig ausserhalb von AWS-Einrichtungen. XKS hat höheren Betriebsaufwand, höhere Gesamtkosten und höhere Latenz als CloudHSM.
F: Ist XKS dasselbe wie BYOK mit importiertem Schlüsselmaterial?
Nein. Bei importiertem Schlüsselmaterial erzeugen Sie den Schlüssel und importieren ihn; danach hält und verwendet AWS KMS ihn in eigenen HSMs. Das ist BYOK. Bei XKS verlässt das Schlüsselmaterial Ihren externen Schlüsselmanager nie, und jede Operation läuft über Ihren Proxy: das Hold-Your-Own-Key-Modell. Siehe Was ist BYOK? und den HYOK-Leitfaden.
F: Wie funktioniert die Schlüsselrotation mit XKS?
Komplexer als bei Standard-KMS. Die automatische KMS-Schlüsselrotation ist für XKS-Schlüssel nicht verfügbar, und die XksKeyId eines KMS-Schlüssels lässt sich nicht ändern. Stattdessen rotiert Ihr externer Schlüsselmanager das Schlüsselmaterial hinter derselben XksKeyId; AWS KMS verweist weiter auf dieselbe ID, und Ihr Schlüsselmanager nutzt transparent das neue Material. Stimmen Sie die Rotation sorgfältig zwischen Schlüsselmanager-Betrieb und AWS-Team ab.
F: Kann ich bestehende KMS-verschlüsselte Daten zu XKS migrieren?
Nicht direkt. Es gibt keinen Weg, CMK-verschlüsselte Daten ohne Ent- und Neuverschlüsselung jedes Objekts zu XKS zu verschieben. Für S3 heisst das, alle Objekte zu durchlaufen; für EBS-Volumes brauchen Sie Snapshot- und Restore-Abläufe. Planen Sie bei grossen Datenmengen viel Zeit und Budget ein.
XKS ist für ein enges, spezifisches Compliance-Szenario gebaut. Es hält sein Versprechen, kryptografisches Schlüsselmaterial unter Ihrer alleinigen Kontrolle ausserhalb von AWS, um den Preis erheblicher Betriebskomplexität, höherer Latenz und deutlich höherer Kosten.
Nutzen Sie diese Checkliste, bevor Sie sich festlegen:
Wenn Sie alles abhaken können, ist XKS eine durchdachte Lösung für ein schwieriges Problem. Wenn es weniger als vier Punkte sind, prüfen Sie CloudHSM oder gut verwaltete CMKs: Sie erfüllen Ihre tatsächlichen Anforderungen möglicherweise mit viel weniger Aufwand.
Geschrieben von
Nagib Aouini
Ähnliche Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
