Behalten Sie die Kontrolle über Ihre Verschlüsselungsschlüssel in der Cloud

Die Kontrolle über Ihre Verschlüsselungsschlüssel in der Cloud zu behalten bedeutet sicherzustellen, dass Ihre Organisation und nicht der Cloud-Anbieter die Berechtigung hat, die Schlüssel zum Schutz Ihrer Daten zu erstellen, zu rotieren, zu deaktivieren und zu prüfen. Dies ist wichtig, da vom Cloud-Anbieter verwaltete Schlüssel keine unabhängige Protokollierung, keine Widerrufsmöglichkeit und keine Möglichkeit bieten, einer Aufsichtsbehörde nachzuweisen, dass Ihr Anbieter keinen Zugriff auf Ihre Daten hat. Es wird empfohlen, für regulierte Workloads auf kundenverwaltete Schlüssel (BYOK) und für Workloads, bei denen der Cloud-Anbieter vollständig aus der Schlüsselvertrauenskette ausgeschlossen werden muss, auf kundenverwaltete Schlüssel (HYOK) umzusteigen.

Kurzantwort: Was bedeutet Schlüsselverwaltung in der Cloud?

Standardmäßig verschlüsseln alle drei großen Cloud-Anbieter (AWS, Azure, GCP) Ihre ruhenden Daten automatisch. Die Frage ist nicht, ob eine Verschlüsselung stattfindet, sondern wer die Verschlüsselungsschlüssel kontrolliert. Anbieterverwaltete Schlüssel bedeuten, dass der Cloud-Anbieter die Schlüssel in Ihrem Auftrag generiert, speichert und rotiert. Sie können diese nicht selbstständig deaktivieren, einzelne Entschlüsselungsvorgänge bestimmter Identitäten nicht protokollieren und einem Prüfer nicht nachweisen, dass der Anbieter keinen Zugriff auf Ihre Daten hat. Kundenverwaltete Schlüssel (BYOK) ermöglichen Ihnen diese Kontrolle. Clientseitige Verschlüsselung (HYOK) geht noch einen Schritt weiter, indem sie sicherstellt, dass der Schlüssel niemals in die Infrastruktur des Cloud-Anbieters gelangt. Für die meisten regulierten Workloads ist BYOK mit einem FIPS 140-2 Level 3 HSM als Schlüsselgenerierungsquelle der Standard, der die Anforderungen von PCI DSS, HIPAA, FedRAMP und DSGVO erfüllt.

Wichtige Erkenntnisse

• Cloud-Verschlüsselung ist standardmäßig aktiviert; Schlüsselkontrolle ist es nicht: Alle großen Cloud-Anbieter verschlüsseln ruhende Daten automatisch. Die für die Compliance entscheidende Frage ist, wer die Schlüssel kontrolliert, nicht ob eine Verschlüsselung angewendet wird.
• Anbieterverwaltete Schlüssel erfüllen die meisten Compliance-Anforderungen nicht: AWS-eigene, Microsoft-verwaltete Azure- und Google-verwaltete GCP-Schlüssel bieten keine protokollierte Verarbeitung einzelner Vorgänge, keine unabhängige Schlüsselwiderrufung und keine Kontrolle des Kunden über den Schlüssellebenszyklus. Sie sind für Daten, die den Standards PCI DSS, HIPAA, FedRAMP und DSGVO unterliegen, unzureichend.
• BYOK ist der Mindeststandard für regulierte Cloud-Workloads: Bring Your Own Key bietet Ihnen die Möglichkeit, die Herkunft Ihres Schlüssels nachzuweisen (Sie können beweisen, wo der Schlüssel generiert wurde), einen protokollierten Vorgang pro Operation (jede Ver- und Entschlüsselung wird mit Ihrem Schlüssel protokolliert) und die Möglichkeit zum sofortigen unabhängigen Widerruf (deaktivieren Sie den Schlüssel, um den Zugriff auf alle Cloud-Dienste, die ihn verwenden, sofort zu blockieren).
• HYOK ist für Workloads gedacht, bei denen der Cloud-Anbieter vollständig ausgeschlossen werden muss: „Hold Your Own Key“ bedeutet, dass die Cloud ausschließlich verschlüsselte Daten speichert. Der Cloud-Anbieter kann Ihre Daten unter keinen Umständen entschlüsseln. Dies ist erforderlich für Verschlusssachen, nationale Souveränitätsvorgaben und Zero-Trust-Architekturen.
• Die Schlüsselverwaltung in Multi-Cloud-Umgebungen erfordert eine explizite Governance-Architektur: Die KMS-Systeme der einzelnen Clouds sind anbieterspezifisch und nicht auf andere Clouds übertragbar. Multi-Cloud-Organisationen benötigen entweder eine zentrale BYOK-Quelle (ein einzelnes externes HSM, das alle Cloud-KMS-Systeme speist) oder eine einheitliche clientseitige Verschlüsselungsschicht (HYOK), um eine konsistente Schlüsselverwaltung über AWS, Azure und GCP hinweg zu gewährleisten.

Warum von Cloud-Anbietern verwaltete Schlüssel nicht ausreichen

Wenn Sie die Verschlüsselung für einen Cloud-Speicher-Bucket, eine Datenbank oder eine virtuelle Festplatte aktivieren, ohne einen vom Kunden verwalteten Schlüssel anzugeben, wendet der Cloud-Anbieter seine Standardverschlüsselung mit Schlüsseln an, die er in Ihrem Auftrag generiert, speichert und verwaltet. Dies ist zwar besser als gar keine Verschlüsselung, weist aber drei kritische Sicherheitslücken auf, deren Schließung in Compliance-Rahmenwerken ausdrücklich gefordert wird.

Kein Audit-Trail pro Vorgang: Anbieterverwaltete Schlüssel erzeugen keinen Protokolleintrag für jeden einzelnen Verschlüsselungs- oder Entschlüsselungsvorgang, der mit einer authentifizierten Identität verknüpft ist. Sie können weder einem PCI-DSS-QSA noch einem HIPAA-Auditor oder einem FedRAMP-Assessor genau nachweisen, wer welche Daten wann entschlüsselt hat. Kundenverwaltete Schlüssel hingegen generieren dieses Protokoll in CloudTrail (AWS), Azure Monitor (Azure) oder Cloud Audit Logs (GCP) für jeden Verschlüsselungs- und Entschlüsselungsaufruf.

Keine unabhängige Schlüsselwiderrufung: Bei anbieterverwalteten Schlüsseln können Sie den Schlüssel nicht sofort deaktivieren oder widerrufen, um den Zugriff auf Ihre Daten im Falle eines Sicherheitsvorfalls, einer behördlichen Anordnung oder einer Vertragsbeendigung mit einem Cloud-Anbieter vollständig zu unterbinden. Bei kundenverwalteten Schlüsseln hingegen blockiert die Deaktivierung des Schlüssels in KMS, Key Vault oder Cloud KMS sofort und atomar jegliche weitere Ver- und Entschlüsselung über alle Cloud-Dienste hinweg, die diesen Schlüssel verwenden, ohne die Daten zu löschen.

Keine Ausgrenzung des Cloud-Anbieters aus der Schlüsselvertrauenskette: Bei anbieterverwalteten Schlüsseln besitzt und kontrolliert der Cloud-Anbieter die Schlüssel, die Ihre Daten schützen. Selbst bei kundenverwalteten Schlüsseln (BYOK) hat der Cloud-Anbieter operativen Zugriff auf Ihr importiertes Schlüsselmaterial, solange es sich in seinem KMS befindet. Nur HYOK (clientseitige Verschlüsselung vor dem Upload) schließt den Cloud-Anbieter vollständig von der Schlüsselvertrauenskette aus.

Die drei wichtigsten Steuerungsmodelle: Native, BYOK und HYOK

Es gibt drei verschiedene Modelle für die Verwaltung von Verschlüsselungsschlüsseln in der Cloud, die jeweils unterschiedliche Vor- und Nachteile in Bezug auf Sicherheit, Compliance und Betrieb mit sich bringen.

Modell 1: Native Cloud Provider Keys (vom Anbieter verwaltet)

Der Cloud-Anbieter generiert, speichert, rotiert und verwaltet alle Verschlüsselungsschlüssel. Bei AWS handelt es sich dabei um AWS-verwaltete oder AWS-eigene KMS-Schlüssel. Bei Azure sind es Microsoft-verwaltete Schlüssel. Bei GCP sind es Google-verwaltete Verschlüsselungsschlüssel (GMEK). Die Verschlüsselung erfolgt automatisch und ohne zusätzliche Kosten, der Kunde hat jedoch keinerlei Kontrolle über den Schlüssellebenszyklus. Es gibt kein protokolliertes Vorgehen, das mit den Kundenidentitäten verknüpft ist, keine unabhängige Widerrufsmöglichkeit und keine Möglichkeit, einer Aufsichtsbehörde nachzuweisen, dass der Cloud-Anbieter keinen Zugriff auf die Daten hat. Diese Lösung eignet sich nur für nicht regulierte, interne Daten, bei denen die Sicherheitslage des Cloud-Anbieters vollständig innerhalb der Vertrauensgrenzen der Organisation liegt.

Modell 2: BYOK (Bring Your Own Key): Vom Kunden verwaltete Schlüssel

BYOK bedeutet, dass Sie Schlüsselmaterial außerhalb des Cloud-Anbieters mit Ihrem eigenen HSM oder Schlüsselverwaltungssystem generieren und es anschließend in den Schlüsselverwaltungsdienst des Cloud-Anbieters importieren. Es empfiehlt sich, das Schlüsselmaterial in einem FIPS 140-2 Level 3-validierten Hardware-Sicherheitsmodul (HSM) zu generieren . Level 3-HSMs sind so konzipiert, dass Schlüsselmaterial selbst bei physischem Zugriff auf die Hardware nicht im Klartext extrahiert werden kann und bei einem Extraktionsversuch Manipulationsnachweise liefern. Sie behalten das Original-Schlüsselmaterial in Ihrem HSM. Wenn Sie die importierte Kopie aus dem Cloud-KMS löschen, verliert der Cloud-Anbieter sofort die Möglichkeit, Ihre Daten zu verschlüsseln oder zu entschlüsseln.

BYOK bietet Ihnen drei Funktionen, die von Anbietern verwaltete Schlüssel nicht bieten: (1) Nachweis der Schlüsselherkunft: Sie können einem Prüfer nachweisen, dass der Schlüssel in Ihrem FIPS-validierten HSM generiert wurde und nicht vom Cloud-Anbieter; (2) Protokollierung pro Vorgang: Jeder Verschlüsselungs- und Entschlüsselungsaufruf mit Ihrem kundenverwalteten Schlüssel wird mit der anfragenden Identität, dem Zeitstempel und der Schlüsselkennung protokolliert; (3) Sofortiger unabhängiger Widerruf: Durch Deaktivieren des Schlüssels im Cloud-KMS wird der Zugriff auf alle Dienste, die ihn verwenden, ohne die Mitwirkung des Cloud-Anbieters blockiert.

Der entscheidende Nachteil von BYOK: Der Cloud-Anbieter hat weiterhin Zugriff auf das importierte Schlüsselmaterial, solange es in seinem KMS gespeichert ist. Er verwendet Ihren Schlüssel für Ver- und Entschlüsselungsvorgänge innerhalb seiner Infrastruktur. Dies ist kein Mangel des BYOK-Designs, sondern eine systembedingte Eigenschaft des Managed-KMS-Modells. Für Workloads, bei denen selbst dieser operative Zugriff nicht akzeptabel ist, ist HYOK erforderlich.

Modell 3: HYOK (Hold Your Own Key): Clientseitige Verschlüsselung

HYOK bedeutet, dass der Verschlüsselungsschlüssel niemals in die Infrastruktur des Cloud-Anbieters gelangt. Ihre Anwendung oder Datenpipeline verschlüsselt Daten, bevor diese in einen Cloud-Dienst hochgeladen werden. Der Cloud-Anbieter speichert ausschließlich den Chiffretext und kann diesen unter keinen Umständen entschlüsseln, auch nicht bei einer gegen ihn gerichteten rechtlichen Verpflichtung. Dies ist das einzige Modell, das den Cloud-Anbieter vollständig von der Schlüsselvertrauenskette ausschließt.

HYOK wird implementiert, indem Ihre Anwendung bei jedem Ver- und Entschlüsselungsvorgang Ihr externes Schlüsselverwaltungssystem (KMS) direkt aufruft. Jeder Lese- und Schreibvorgang in der Cloud, der sensible Daten betrifft, erfordert einen Aufruf Ihres externen KMS. Daher muss Ihr externes KMS hochverfügbar sein, damit Ihre Anwendungen funktionieren. Geplante oder ungeplante Ausfallzeiten Ihres externen KMS führen zu einer direkten Verfügbarkeitsabhängigkeit für alle Cloud-Workloads, die HYOK-Verschlüsselung verwenden.

HYOK schränkt zudem die Nutzung cloudnativer Datenverarbeitungsfunktionen ein, die den Zugriff des Cloud-Anbieters auf Klartextdaten erfordern: serverseitige Suchindizierung, cloudnative Datentransformation, Analyseabfragen auf verschlüsselten Feldern und KI/ML-Verarbeitung. Jede Cloud-Funktion, die Daten verarbeitet, anstatt sie nur zu speichern, benötigt entweder Klartextzugriff (mit HYOK nicht möglich) oder eine vertrauenswürdige Ausführungsumgebung. Dieser Kompromiss muss für jede Arbeitslast individuell bewertet werden.

GCP unterstützt eine CMEK-integrierte HYOK-Option über den Cloud External Key Manager (Cloud EKM). Dabei rufen CMEK-integrierte Dienste Ihren externen KMS für jede DEK-Verschlüsselungs- und Entschlüsselungsoperation über eine TLS-authentifizierte Verbindung auf. Dies ermöglicht die HYOK-Souveränität für CMEK-integrierte GCP-Dienste, ohne dass eine Verschlüsselung auf Anwendungsebene für jedes Objekt erforderlich ist. AWS bietet keine vergleichbare native EKM-Integration.

BYOK vs. HYOK vs. Native: Entscheidungstabelle

Abmessungen	Native (vom Anbieter verwaltet)	BYOK (Customer-Managed Key in Cloud KMS)	HYOK (Clientseitiger / Externer Schlüssel)
Wer generiert den Schlüssel?	Cloud-Anbieter	Kunde (in Cloud-KMS importiert)	Kunde (tritt nie in die Cloud ein)
Zugriff des Cloud-Anbieters auf Schlüssel	Ja (volle Kontrolle)	Ja (operativer Zugriff während der Nutzung)	Nein
Prüfprotokoll pro Vorgang	Nein	Ja (in den Cloud-KMS-Audit-Protokollen)	Nur externe KMS-Protokolle
Unabhängiger Schlüsselwiderruf	Nein	Ja (Schlüssel im Cloud-KMS deaktivieren/löschen)	Ja (Widerruf bei externem KMS)
Wichtigster Herkunftsnachweis	Nein	Ja (aus Ihrer HSM-Generierungsquelle)	Ja (vollständig vom Kunden kontrolliert)
Automatische Schlüsseldrehung	Ja (Anbieterplan)	Ja (Cloud-KMS-Zeitplan); nicht verfügbar für importiertes Material	Vollständig vom Kunden verwaltet
FIPS 140-2 Level 3 Option	Nein	Ja (über einen HSM-gestützten Schlüsselspeicher oder eine Level-3-Generierungsquelle)	Abhängig von externer KMS-Hardware
Native Cloud-Service-Integration	Ja	Ja	Teilweise (auf Anwendungsebene) oder über Cloud EKM (GCP)
Operative Komplexität	Niedrig	Medium	Hoch
Compliance-Abdeckung	Nicht ausreichend für PCI DSS, HIPAA, FedRAMP und DSGVO	Erfüllt die meisten Anforderungen	Erfüllt die strengsten Souveränitätsanforderungen
Kosten	In den Lagerkosten enthalten	KMS-Schlüsselgebühr + Gebühr pro Vorgang	Kosten für externe KMS-Infrastruktur
Am besten geeignet,	Nicht regulierte interne Daten	Die meisten regulierten Cloud-Workloads	Geheime Daten, Souveränitätsmandate, Zero Trust

Wie BYOK auf AWS, Azure und GCP funktioniert

Alle großen Cloud-Anbieter unterstützen BYOK, aber jede Implementierung hat ihren eigenen Schlüsselverwaltungsmechanismus, Importprozess und eigene Einschränkungen. Das Verständnis der jeweiligen Cloud-spezifischen Gegebenheiten ist unerlässlich für die Entwicklung einer konsistenten Multi-Cloud-Schlüsselverwaltungsarchitektur.

BYOK auf AWS (AWS KMS-Importaufträge): Erstellen Sie einen KMS-Importauftrag für den Zielschlüsselring und laden Sie einen Wrapping-Schlüssel herunter (RSA-2048-öffentlicher Schlüssel oder symmetrischer AES-256-Wrapping-Schlüssel). Generieren Sie Ihr AES-256-Schlüsselmaterial in Ihrem HSM. Wrappen Sie Ihr Schlüsselmaterial mit dem heruntergeladenen Wrapping-Schlüssel. Laden Sie das gekapselte Material in KMS hoch; der Schlüsselursprung ist auf EXTERN gesetzt. AWS KMS entpackt und speichert Ihr Schlüsselmaterial. Sie behalten das Original in Ihrem HSM; das Löschen der importierten Kopie aus KMS entzieht AWS sofort die Berechtigung, diese zu verwenden. Einschränkung: Die automatische Rotation ist für importierte Schlüssel nicht verfügbar. Eine detaillierte Analyse der Vertrauensgrenzen finden Sie in unserem Leitfaden zur AWS KMS-Sicherheit .

BYOK auf Azure (Azure Key Vault-Schlüsselimport): Generieren Sie Ihren RSA-Schlüssel (2048, 3072 oder 4096 Bit) oder AES-Schlüssel in Ihrem HSM. Übertragen Sie den Schlüssel mithilfe des BYOK-Übertragungspakets in Azure Key Vault: Verpacken Sie das Schlüsselmaterial mit dem für Ihren Tresor heruntergeladenen Key Vault-Austauschschlüssel. Laden Sie das BYOK-Paket in Azure Key Vault hoch. Bei hardwaregeschützten Schlüsseln in Key Vault Premium wird das importierte Schlüsselmaterial in einem von Azure verwalteten HSM-Modul gespeichert. Sie behalten das Original in Ihrem eigenen HSM. Wenn Sie den Schlüssel aus Key Vault löschen, kann Azure ihn nicht mehr für alle mit diesem Schlüssel verschlüsselten Ressourcen verwenden.

BYOK auf GCP (Cloud KMS Importaufträge): Erstellen Sie einen Cloud KMS Importauftrag und geben Sie den Zielschlüsselring und den Verschlüsselungsalgorithmus (RSA_OAEP_3072_SHA256 oder AES_256_KWP) an. Laden Sie den Verschlüsselungsschlüssel herunter. Generieren Sie Ihr AES-256-Schlüsselmaterial in Ihrem HSM. Verschlüsseln Sie Ihr Material mit dem Verschlüsselungsschlüssel. Laden Sie das verschlüsselte Material über die Cloud KMS API hoch. Cloud KMS entschlüsselt Ihr Material (innerhalb des HSM-Clusters, falls die Zielschutzstufe HSM ist) und speichert es als Schlüsselversion. Hinweis: Die automatische Rotation ist für Schlüssel mit importiertem Material nicht verfügbar. Die vollständige GCP-Verschlüsselungsarchitektur finden Sie in unserem Leitfaden zu den Datenverschlüsselungsoptionen von Google Cloud .

IAM-Zugriffskontrolle: Wer darf Ihre Schlüssel verwenden und verwalten?

Die Kontrolle über Schlüssel erfordert nicht nur den Besitz des Schlüsselmaterials, sondern auch die Kontrolle darüber, wer den Schlüssel für kryptografische Operationen verwenden und wer seinen Lebenszyklus verwalten darf. Die Zugriffskontrollmodelle der einzelnen Cloud-Anbieter unterscheiden sich dabei.

AWS KMS: Der Zugriff auf KMS-Schlüssel wird über eine obligatorische Schlüsselrichtlinie (die jedem Prinzipal explizit Berechtigungen erteilen muss) und IAM-Identitätsrichtlinien (eine sekundäre Ebene, die Berechtigungen innerhalb der durch die Schlüsselrichtlinie erlaubten Grenzen erteilen kann) gesteuert. Die Schlüsselrichtlinie ist die primäre Steuerung: Ohne eine explizite Berechtigung in der Schlüsselrichtlinie kann kein Prinzipal den Schlüssel verwenden, unabhängig von seinen IAM-Berechtigungen. Trennen Sie Schlüsseladministratorrollen (die den Schlüssel verwalten können) von Schlüsselbenutzerrollen (die verschlüsseln und entschlüsseln können), um zu verhindern, dass eine einzelne Identität den Schlüssel sowohl verwaltet als auch verwendet.

Azure Key Vault: Der Zugriff auf Key Vault-Schlüssel erfolgt entweder über Azure RBAC (empfohlenes Modell) oder über ältere Zugriffsrichtlinien. Mit Azure RBAC trennen Rollen wie Key Vault Crypto Officer (Schlüsselverwaltung), Key Vault Crypto User (Schlüsselverschlüsselung/-entschlüsselung) und Key Vault Reader (Metadaten anzeigen) die Verwaltung von der operativen Nutzung. Weisen Sie Rollen auf Schlüsselebene und nicht auf Tresorebene zu, um ein minimales Zugriffsrecht zu gewährleisten.

GCP Cloud KMS: Der Zugriff auf Cloud-KMS-Schlüssel erfolgt über Google Cloud IAM mit zwei Schlüsselrollen: Cloud-KMS-Administrator (Erstellen, Löschen und Verwalten von Schlüsselrichtlinien) und Cloud-KMS-Verschlüsselungs-/Entschlüsselungsbenutzer (Verwenden von Schlüsseln zum Ver- und Entschlüsseln). Die Rolle „Cloud-KMS-Administrator“ kann keine Schlüssel für kryptografische Operationen verwenden, wodurch die Trennung von Verwaltung und Nutzung gewährleistet wird. Organisationsrichtlinien können spezifische Schlüsselkonfigurationen erfordern und verhindern, dass Dienste Nicht-CMEK-Verschlüsselung verwenden.

Bei allen drei Cloud-Lösungen gilt das gleiche Grundprinzip: Die Schlüsselverwaltung wird von der Schlüsselnutzung getrennt. Der Zugriff erfolgt nach dem Prinzip der minimalen Berechtigungen auf Ebene des einzelnen Schlüssels und nicht auf Ebene des KMS oder Key Vaults. Mithilfe von Audit-Protokollierung werden Zugriffe erkannt, die nicht dem genehmigten Zugriffsmuster entsprechen.

Schlüsselrotation: Aufrechterhaltung der Schlüsselkontrolle über die Zeit

Die Generierung eines kundenseitig verwalteten Schlüssels und dessen einmaliger Import sind der Beginn der Schlüsselkontrolle, nicht deren Ende. Um die Kontrolle langfristig zu gewährleisten, ist ein definierter Rotationsprozess erforderlich, der die Schlüssel aktuell hält und das kryptografische Risiko im Falle einer Kompromittierung eines Schlüssels minimiert.

Für kundenverwaltete Schlüssel mit cloudgenerierten Daten unterstützen alle drei großen Cloud-Anbieter die automatische Schlüsselrotation: AWS KMS unterstützt Rotationsintervalle von 90 Tagen bis 7 Jahren. Azure Key Vault unterstützt konfigurierbare Rotationsrichtlinien mit Benachrichtigungsperioden. GCP Cloud KMS unterstützt konfigurierbare Rotationsintervalle mit einer minimalen Rotationsperiode von 24 Stunden. Bei der Rotation wird eine neue Schlüsselversion zum primären Schlüssel für neue Verschlüsselungsvorgänge, während frühere Versionen zur Entschlüsselung bereits verschlüsselter Daten beibehalten werden. Für die Standard-Schlüsselrotation ist keine erneute Verschlüsselung vorhandener Daten erforderlich.

Für BYOK-Schlüssel mit importiertem Material ist die automatische Rotation durch die KMS-Systeme der Cloud-Anbieter nicht verfügbar (das Cloud-KMS kann keine neuen Versionen Ihres extern erstellten Schlüsselmaterials generieren). Sie müssen die Rotation manuell verwalten: Generieren Sie neues Schlüsselmaterial in Ihrem HSM, importieren Sie es als neue Schlüsselversion, legen Sie es als primäre Version fest und planen Sie den Übergang so, dass der laufende Betrieb abgeschlossen ist, bevor die vorherige Version außer Betrieb genommen wird. Dies ist der betrieblich anspruchsvollste Aspekt der BYOK-Schlüsselverwaltung und muss vor der BYOK-Implementierung, nicht erst danach, geplant werden.

Bei HYOK (clientseitiger Verschlüsselung) erfordert die Rotation die erneute Verschlüsselung aller mit dem alten Schlüssel verschlüsselten Daten mit dem neuen Schlüssel, da der Cloud-Anbieter nur den Chiffretext speichert und die Schlüsselversionierung nicht transparent für Sie durchführen kann. Dies ist ein erheblicher operativer Aufwand für große Datensätze und muss von Anfang an in die HYOK-Architekturplanung einbezogen werden.

Audit-Protokollierung: Nachweis der Schlüsselkontrolle gegenüber den Prüfern

Die Kontrolle über Schlüssel zu behalten, bedeutet mehr als nur den Schlüssel zu besitzen. Es bedeutet, gegenüber Aufsichtsbehörden oder Wirtschaftsprüfern nachweisen zu können, dass Sie kontrolliert haben, wer wann auf den Schlüssel zugegriffen hat. Dies erfordert eine Protokollierung auf zwei Ebenen: Speicherzugriffsprotokolle (wer hat welche Daten gelesen?) und Schlüsselverwaltungsprotokolle (wer hat welchen Schlüssel zur Entschlüsselung verwendet?).

Schlüsselverwaltungs-Audit-Protokolle nach Anbieter:

• AWS KMS + CloudTrail: Jeder KMS-API-Aufruf generiert ein CloudTrail-Ereignis mit dem Schlüssel-ARN, der Operation, der anfragenden IAM-Identität, der Quell-IP-Adresse, der Region und dem Zeitstempel. Management-Ereignisse (Schlüsselerstellung, Richtlinienänderungen, ScheduleKeyDeletion) sind immer aktiviert. Datenereignisse (GenerateDataKey und Decrypt) müssen für regulierte Workloads explizit aktiviert werden und liefern die gemäß PCI DSS Requirement 10 und HIPAA Audit Control (45 CFR 164.312(b)) erforderlichen Nachweise pro Operation.
• Azure Key Vault + Azure Monitor: Die Diagnoseprotokolle von Key Vault erfassen jeden Schlüsselvorgang (Schlüssel verpacken, Schlüssel entpacken, Schlüssel abrufen, Schlüssel erstellen, Schlüssel löschen) mit der anfordernden Identität, dem Zeitstempel und dem Ergebnis. Die Diagnoseeinstellungen müssen so konfiguriert sein, dass die Protokolle an einen Log Analytics-Arbeitsbereich oder ein Speicherkonto weitergeleitet werden. Aktivieren Sie Azure Monitor-Warnungen für die Deaktivierung und Löschung von Schlüsseln sowie für Zugriffe durch unerwartete Dienstprinzipale.
• GCP Cloud KMS + Cloud-Audit-Protokolle: Die Administratoraktivitätsprotokolle (immer aktiv) erfassen die Schlüsselerstellung, Versionsverwaltung, Richtlinienaktualisierungen und Importvorgänge. Die Datenzugriffsprotokolle (müssen explizit aktiviert werden) protokollieren jeden Verschlüsselungs- und Entschlüsselungsaufruf von GCP-Diensten für Ihren CMEK-Schlüssel, einschließlich des anfragenden Dienstkontos und der verwendeten Schlüsselversion. Leiten Sie die Protokolle zur langfristigen Aufbewahrung und zum Schutz vor Manipulationen in ein separates, schreibgeschütztes Projekt weiter.

Unabhängig vom Cloud-Anbieter müssen alle Audit-Logs der Schlüsselverwaltung an ein schreibgeschütztes Ziel in einem separaten Konto oder Projekt weitergeleitet werden, das nicht von der Identität, die die Schlüssel verwaltet, geändert oder gelöscht werden kann. PCI DSS schreibt eine Aufbewahrungsdauer von 12 Monaten für Logs vor, wobei 3 Monate sofort verfügbar sein müssen. Konfigurieren Sie Echtzeitwarnungen für jede Deaktivierung, Löschung oder Entschlüsselung eines Schlüssels durch einen nicht autorisierten Benutzer.

Multi-Cloud-Schlüsselkontrollarchitektur

Die Verwaltung von Schlüsseln in Multi-Cloud-Umgebungen ist komplexer als in Single-Cloud-Umgebungen, da die KMS-Systeme der einzelnen Cloud-Anbieter anbieterspezifisch sind: AWS-KMS-Schlüssel sind nicht mit Azure oder GCP kompatibel; Azure Key Vault-Schlüssel sind nicht mit AWS oder GCP kompatibel; GCP Cloud-KMS-Schlüssel sind nicht mit AWS oder Azure kompatibel. In einem Cloud-KMS generierte Schlüssel können nicht direkt in ein anderes Cloud-KMS übertragen werden. Organisationen, die in mehreren Clouds tätig sind, benötigen eines von drei Architekturmustern, um eine konsistente Schlüsselverwaltung zu gewährleisten.

Muster 1: Kundenseitig verwaltete Schlüssel pro Cloud mit zentralisierter Governance

Nutzen Sie AWS KMS-Kundenschlüssel für AWS-Workloads, Azure Key Vault-Kundenschlüssel für Azure-Workloads und GCP Cloud KMS-Kundenschlüssel für GCP-Workloads. Die Daten jeder Cloud werden durch deren natives KMS geschützt, was native Performance und native Serviceintegration gewährleistet. Eine zentrale Plattform für das Schlüssellebenszyklusmanagement aggregiert Schlüsselbestand, Rotationspläne und Audit-Logs aller drei Anbieter in einer einzigen Governance-Ansicht. Dies ist das betrieblich praktikabelste Modell für die meisten Organisationen und erfordert keine cloudübergreifende Schlüsselverteilung.

Muster 2: Zentralisierte BYOK-Lösung von einer einzigen externen HSM-Quelle

Generieren Sie sämtliche Verschlüsselungsschlüssel aus einem einzigen externen FIPS 140-2 Level 3 HSM oder einem HSM-as-a-Service, der unabhängig von allen Cloud-Anbietern ist. Importieren Sie abgeleitete Schlüssel in AWS KMS für AWS-Workloads (über KMS-Importaufträge), in Azure Key Vault für Azure-Workloads (über BYOK-Transferpaket) und in GCP Cloud KMS für GCP-Workloads (über Cloud-KMS-Importaufträge). Die gesamte Verschlüsselung über alle drei Clouds hinweg lässt sich auf eine einzige autoritative Hardware-Schlüsselquelle zurückführen. Dies gewährleistet Cloud-übergreifende Konsistenz der Schlüsselherkunft und einen zentralen Punkt für den Schlüsselwiderruf: Das gleichzeitige Löschen der Schlüssel aus allen drei Cloud-KMS blockiert den Zugriff im gesamten Multi-Cloud-Umfeld. Der HSM-as-a-Service von Encryption Consulting stellt die externe FIPS 140-2 Level 3 HSM-Infrastruktur für dieses Modell bereit, die gleichzeitig von AWS, Azure und GCP aus ohne Abhängigkeit von einem Cloud-Anbieter zugänglich ist.

Muster 3: HYOK mit einer gemeinsam genutzten clientseitigen Verschlüsselungsschicht

Verschlüsseln Sie Daten auf Anwendungs- oder Pipeline-Ebene, bevor sie einen Cloud-Anbieter erreichen. Verwenden Sie dazu ein einziges, von allen Cloud-Anbietern unabhängiges externes Schlüsselverwaltungssystem (KMS). AWS, Azure und GCP speichern jeweils nur den Chiffretext. Der Cloud-Anbieter ist vollständig von der Schlüsselvertrauenskette für alle drei Clouds gleichzeitig ausgeschlossen. Dies gewährleistet maximale Cloud-übergreifende Datensouveränität, erfordert jedoch, dass alle Anwendungen kryptografische Operationen vor jedem Cloud-API-Aufruf durchführen und Ihr externes KMS die für alle Cloud-Workloads gleichzeitig erforderliche Verfügbarkeit gewährleistet.

Für eine Bestandsaufnahme aller aktuellen Schlüsselkonfigurationen, Rotationsstatus und Zugriffsrichtlinienlücken in einer Multi-Cloud-Umgebung ermittelt CBOM Secure von Encryption Consulting alle KMS-Schlüssel, Verschlüsselungskonfigurationen und Schlüsselverwaltungsrichtlinien in AWS-, Azure- und GCP-Konten und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die Inkonsistenzen und Compliance-Lücken aufzeigt.

Fragen an Ihren Cloud-Anbieter

Bevor Sie sensible Daten in einem Cloud-Dienst bereitstellen, sollten Sie dem Cloud-Anbieter die folgenden Fragen stellen, um sicherzustellen, dass Sie die Kontrolle behalten:

1. Unterstützen Sie kundenverwaltete Schlüssel (BYOK) für den von mir verwendeten Dienst? Die meisten Dienste bieten native Verschlüsselung, die Unterstützung für eigene Schlüssel (BYOK) variiert jedoch je nach Dienst. Nicht jeder Cloud-Dienst unterstützt vom Kunden verwaltete Schlüssel. Prüfen Sie die BYOK-Unterstützung des jeweiligen Dienstes vor der Bereitstellung, nicht erst danach.
2. Welchen FIPS-Validierungsstandard besitzt die Hardware, auf der mein kundenverwalteter Schlüssel gespeichert ist? AWS KMS Standard entspricht Level 2. AWS CloudHSM Custom Key Store entspricht Level 3. Azure Key Vault Premium verwendet HSM-gestützte Schlüssel. GCP Cloud HSM entspricht ebenfalls Level 3. Für FedRAMP High und PCI DSS Anforderung 3.7.1 ist Level 3 erforderlich.
3. Kann ich mein eigenes Schlüsselmaterial importieren und das Original außerhalb Ihrer Infrastruktur aufbewahren? Prüfen Sie, ob die BYOK-Importfunktion unterstützt wird und machen Sie sich mit dem Importprozess, dem Wrapping-Algorithmus und den Einschränkungen vertraut (insbesondere mit der Einschränkung der automatischen Rotation importierter Schlüssel).
4. Wenn ich den kundenseitig verwalteten Schlüssel deaktiviere oder lösche, wie schnell wird der Zugriff auf meine Daten über alle Dienste hinweg, die diesen Schlüssel verwenden, widerrufen? Die Antwort sollte lauten: sofort, ohne jegliche Karenzzeit für den Cloud-Dienst, um auf zuvor entschlüsselte Daten zuzugreifen.
5. Wird jeder Verschlüsselungs- und Entschlüsselungsvorgang für meinen kundenverwalteten Schlüssel mit der anfragenden Identität, der Schlüsselversion und dem Zeitstempel protokolliert? Prüfen Sie, ob Datenzugriffs-Audit-Logs verfügbar sind und wie diese aktiviert werden müssen. Prüfen Sie das Logformat und ob es die Anforderungen von PCI DSS oder HIPAA erfüllt.
6. Können Sie als Cloud-Anbieter auf meine Verschlüsselungsschlüssel zugreifen? Bei einem vom Anbieter verwalteten Schlüssel lautet die Antwort „Ja“. Bei einem vom Kunden verwalteten Schlüssel sollte die Antwort lauten: „Wir können die Schlüsselverwendung erst nach einer authentifizierten API-Anfrage initiieren, die Ihre Schlüsselrichtlinie und IAM-Prüfungen besteht.“ Bei einem HYOK sollte die Antwort lauten: „Nein, wir speichern nur den Chiffretext.“

Konformität: PCI DSS, HIPAA, FedRAMP und DSGVO

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): Anforderung 3.5.1 verlangt den Schutz gespeicherter Karteninhaberdaten durch starke Kryptografie mit Schlüsselverwaltung. Vom Anbieter verwaltete Schlüssel erfüllen diese Anforderung nicht, da die Organisation den Schlüssellebenszyklus nicht kontrolliert. Vom Kunden verwaltete BYOK-Schlüssel erfüllen 3.5.1. Anforderung 3.7.1 verlangt die Schlüsselerzeugung mithilfe eines HSM oder einer branchenüblichen Technologie; ein FIPS 140-2 Level 3 HSM als BYOK-Generierungsquelle erfüllt diese Anforderung. Anforderung 3.7.4 verlangt die regelmäßige Schlüsselrotation; vom Kunden verwaltete Schlüssel mit automatischer Rotation erfüllen diese Anforderung. Anforderung 10 verlangt die Protokollierung aller Zugriffe auf Karteninhaberdaten und zugehörige kryptografische Schlüssel; CloudTrail-Datenzugriffsereignisse für KMS, Azure Key Vault-Diagnoseprotokolle mit UnwrapKey-Ereignissen und GCP Cloud Audit Logs-Datenzugriffsereignisse erfüllen diese Anforderung.

HIPAA: Die technischen Sicherheitsvorkehrungen gemäß HIPAA für die Verschlüsselung und Entschlüsselung (45 CFR 164.312(a)(2)(iv)) schreiben die Verschlüsselung ruhender elektronischer Gesundheitsdaten (ePHI) vor. Kundeneigene BYOK-Schlüssel erfüllen diese Anforderung bei allen großen Cloud-Anbietern, sofern die entsprechende Vereinbarung zur Auftragsverarbeitung (Business Associate Agreement, BAA) besteht. Der Standard für die Überwachung von Zugriffsaktivitäten (45 CFR 164.312(b)) fordert die Protokollierung von Zugriffsaktivitäten auf ePHI. Zugriffsprotokolle für Schlüsselverwaltungsdaten, die jeden Entschlüsselungsaufruf einer anfragenden Identität erfassen, erfüllen diesen Standard.

FedRAMP: FedRAMP Moderate erfordert FIPS 140-2 Level 2-validierte kryptografische Module (SC-12, SC-28); standardmäßige, vom Kunden verwaltete KMS-Schlüssel aller drei großen Cloud-Anbieter erfüllen diese Anforderung. FedRAMP High erfordert FIPS 140-2 Level 3-validierte Module; dies erfordert einen benutzerdefinierten Schlüsselspeicher wie AWS CloudHSM, Azure Key Vault Managed HSM oder GCP Cloud HSM für den vom Kunden verwalteten Schlüssel.

DSGVO: Artikel 32 DSGVO fordert geeignete technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten, einschließlich Verschlüsselung. Kundenseitig verwaltete BYOK-Schlüssel unterstützen das Recht auf Löschung gemäß DSGVO: Durch Deaktivierung oder Vernichtung des kundenseitig verwalteten Schlüssels werden alle damit verschlüsselten Daten effektiv unzugänglich. Dies kann als technische Umsetzung der Löschung für Daten dienen, die nicht auf andere Weise selektiv gelöscht werden können (unveränderliche Speicher, Backups). Kundenseitig verwaltete Schlüssel unterstützen zudem die DSGVO-konforme Datenportabilität, indem sie Unternehmen die Möglichkeit geben, den Zugriff beim Wechsel des Cloud-Anbieters sofort zu widerrufen.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie und Cloud-Sicherheit mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption und Implementierung von Multi-Cloud-Schlüsselverwaltungsarchitekturen – von der ersten Strategie bis hin zur Erstellung der erforderlichen Nachweise.

• Multi-Cloud-Schlüsselkontrollarchitektur: Wir analysieren Ihre aktuelle Cloud-Verschlüsselungsstrategie für AWS, Azure und GCP, identifizieren alle Workloads mit anbieterverwalteten Schlüsseln, für die kundenverwaltete Schlüssel erforderlich sind, entwerfen die Zielarchitektur (BYOK oder HYOK) – inklusive Schlüsselhierarchie, HSM-Infrastruktur, Cloud-spezifischer Importprozess, Rotationsplan, IAM-Zugriffsmodell und Audit-Log-Routing – und setzen den Migrationsplan um. Weitere Informationen finden Sie in unserem Cloud-Beratungsdienste.
• HSM als Service für BYOK und HYOK: Für BYOK-Architekturen, die eine FIPS 140-2 Level 3-Schlüsselgenerierung aus einer von allen Cloud-Anbietern unabhängigen Quelle erfordern, oder für HYOK-Architekturen, die ein externes Schlüsselverwaltungssystem benötigen, bietet Encryption Consulting die passende Lösung. HSM als Service Es bietet eine dedizierte HSM-Infrastruktur, die gleichzeitig über AWS, Azure und GCP zugänglich ist. Die gesamte Verschlüsselung über alle Clouds hinweg lässt sich auf eine einzige, autoritative Hardwarequelle der Stufe 3 zurückführen, die von keinem Cloud-Anbieter betrieben wird.
• CBOM Secure für kryptografische Ermittlung: Organisationen, die ihre Cloud-Nutzung organisch ausgebaut haben, verfügen oft über einen Mix aus anbieterverwalteten Schlüsseln, kundenverwalteten Schlüsseln, importierten Schlüsseln und nicht konfigurierten Diensten in Dutzenden von Konten und Projekten. Encryption Consulting CBOM Secure Erkennt und inventarisiert alle Verschlüsselungskonfigurationen, KMS-Schlüsselkonfigurationen und Zugriffsrichtlinien in AWS, Azure und GCP und generiert eine kryptografische Stückliste im CycloneDX-Format, die Compliance-Lücken aufzeigt und die Dokumentation der PCI DSS v4.0.1 Anforderung 12.3.3 unterstützt.
• Compliance-Beratung (PCI DSS, HIPAA, FedRAMP, DSGVO): Wir gleichen Ihre Multi-Cloud-Schlüsselkontrollarchitektur mit den spezifischen Anforderungen von PCI DSS v4.0.1, HIPAA, FedRAMP High und DSGVO ab. Wir identifizieren Kontrolllücken, entwickeln den Sanierungsplan, erstellen die erforderlichen Nachweise und unterstützen Sie bei Anfragen von QSA, HIPAA-Auditoren und FedRAMP-Assessoren. Weitere Informationen finden Sie hier. Compliance-Beratungsdienste.
• PQC-Bereitschaft: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). NIST IR 8547 deutet darauf hin, dass RSA und ECC für neue Anwendungsfälle um das Jahr 2030 nicht mehr verwendet werden. Die in BYOK-Wrapping-Operationen und asymmetrischen Signaturen in allen drei Clouds verwendeten RSA- und ECC-Schlüssel müssen auf Post-Quanten-Algorithmen umgestellt werden. (Encryption Consulting) PQC-Bereitschaft Der Service ordnet Ihren Multi-Cloud-Kryptografieschlüsselbestand dem Zeitplan der Post-Quantenmigration zu.

Um Ihre Strategie zur Schlüsselverwaltung in Multi-Cloud-Umgebungen zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

Die Kontrolle über Ihre Verschlüsselungsschlüssel in der Cloud zu behalten, ist keine Konfigurationsfrage. Es ist eine grundlegende Architekturentscheidung, die darüber entscheidet, ob Ihr Unternehmen Compliance-Vorgaben erfüllen, auf Sicherheitsvorfälle reagieren, Cloud-Anbieter wechseln und Auditoren nachweisen kann, dass Ihre Daten nach Ihren Bedingungen und nicht nach den Bedingungen des Cloud-Anbieters geschützt sind.

Ausgangspunkt ist die Umstellung von anbieterverwalteten auf kundenverwaltete BYOK-Schlüssel für alle regulierten Workloads. Der Schlüssel sollte in einem FIPS 140-2 Level 3 HSM generiert werden, das von Ihrer Organisation kontrolliert wird. Anschließend wird er mithilfe des BYOK-Importmechanismus des Anbieters in das KMS jeder Cloud importiert und durch ein IAM-Zugriffsmodell geschützt, das Schlüsseladministratoren von Schlüsselbenutzern trennt. Jeder Verschlüsselungs- und Entschlüsselungsvorgang wird in einem Audit-Trail protokolliert, der die anfragende Identität erfasst und an ein von Ihnen kontrolliertes, manipulationsgeschütztes Ziel weitergeleitet wird.

In Multi-Cloud-Umgebungen bietet ein zentralisiertes externes HSM als einzige BYOK-Quelle für alle Clouds sowohl konsistente Schlüsselherkunft als auch die Möglichkeit zum cloudübergreifenden Widerruf von Schlüsseln. Bei besonders sensiblen Workloads schließt HYOK mit clientseitiger Verschlüsselung alle Cloud-Anbieter vollständig von der Schlüsselvertrauenskette aus.

Detaillierte Informationen zur Implementierung der BYOK- und CMEK-Architektur in den einzelnen Cloud-Umgebungen finden Sie in unseren Leitfäden zur AWS KMS-Sicherheit , zur Google Cloud-Datenverschlüsselung und in unserem Vergleich zwischen AWS KMS und CloudHSM.

Häufig gestellte Fragen

Was bedeutet es, die Kontrolle über Verschlüsselungsschlüssel in der Cloud zu behalten?

Das bedeutet, dass Ihre Organisation und nicht der Cloud-Anbieter die Berechtigung hat, die Schlüssel zum Schutz Ihrer Daten zu erstellen, zu rotieren, zu deaktivieren, zu löschen und zu prüfen. Vom Anbieter verwaltete Schlüssel bieten Ihnen keine unabhängige Protokollierung, keine Widerrufsmöglichkeit und keine Möglichkeit, nachzuweisen, dass der Cloud-Anbieter nicht auf Ihre Daten zugreifen kann. Kundenseitig verwaltete Schlüssel (BYOK) und clientseitige Verschlüsselung (HYOK) stellen diese Kontrolle wieder her.

Was ist BYOK (Bring Your Own Key) und wie funktioniert es bei verschiedenen Cloud-Anbietern?

BYOK bedeutet, dass Sie Schlüsselmaterial außerhalb des Cloud-Anbieters mit Ihrem eigenen HSM generieren, es mithilfe des Importmechanismus des Anbieters verpacken und in das Cloud-KMS importieren. Das Original bleibt in Ihrem HSM erhalten; durch das Löschen der importierten Kopie verliert die Cloud sofort die Berechtigung, den Schlüssel zu verwenden. AWS verwendet KMS-Importaufträge (Ursprung: EXTERN), Azure das BYOK-Übertragungspaket für Key Vault und GCP Cloud-KMS-Importaufträge. Alle drei speichern Ihren Schlüssel in ihrem KMS und verwenden ihn für den Betrieb; der Cloud-Anbieter hat operativen Zugriff auf das importierte Material, solange es sich in seinem KMS befindet.

Was ist HYOK (Hold Your Own Key) und wann sollte ich es verwenden?

HYOK bedeutet, dass Ihr Schlüssel niemals in die Infrastruktur des Cloud-Anbieters gelangt. Ihre Anwendung verschlüsselt die Daten vor dem Upload; die Cloud speichert ausschließlich den verschlüsselten Text. Verwenden Sie HYOK, wenn der Cloud-Anbieter vollständig von der Schlüsselvertrauenskette ausgeschlossen werden muss: bei vertraulichen Daten, nationalen Datenschutzbestimmungen oder Zero-Trust-Architekturen, bei denen keinem Dritten Schlüsselmaterial anvertraut wird. HYOK erfordert, dass Ihr externes KMS bei jedem Lese- und Schreibvorgang in der Cloud hochverfügbar ist und schränkt die Nutzung cloudnativer Datenverarbeitungsfunktionen ein, die Klartextzugriff benötigen.

Wie behalte ich die Kontrolle über die Schlüssel bei mehreren Cloud-Anbietern?

Drei Muster: (1) Kundenseitig verwaltete Schlüssel pro Cloud mit einer zentralen Governance-Plattform, die Audit-Logs und Rotationsstatus aggregiert. (2) Ein einzelnes externes HSM oder HSM-as-a-Service als BYOK-Quelle für alle Clouds, sodass die gesamte Verschlüsselung auf einen autoritativen Hardware-Root zurückgeführt werden kann. (3) HYOK mit clientseitiger Verschlüsselung auf Anwendungsebene vor jedem Cloud-API-Aufruf unter Verwendung eines einzelnen externen KMS, unabhängig von allen Cloud-Anbietern.

Erfüllt die Beibehaltung der Schlüsselkontrolle die Anforderungen von PCI DSS und HIPAA?

Ja, bei korrekter Implementierung. Für PCI DSS v4.0.1 erfüllt BYOK mit einer FIPS 140-2 Level 3 HSM-Generierungsquelle die Anforderungen 3.5.1, 3.7.1, 3.7.4 und 10 (bei aktivierter Datenzugriffs-Audit-Protokollierung). Für HIPAA erfüllen kundenverwaltete BYOK-Schlüssel die Verschlüsselungssicherheitsvorkehrungen (45 CFR 164.312(a)(2)(iv)), und die Audit-Protokolle der Schlüsselverwaltung erfüllen den Audit-Control-Standard (164.312(b)). Anbieterverwaltete Schlüssel allein erfüllen keines der beiden Frameworks.

Welche Fragen sollte ich meinem Cloud-Anbieter zur Schlüsselverwaltung stellen?

Fragen: (1) Unterstützen Sie BYOK für den von mir genutzten Dienst? (2) Welches FIPS-Validierungsniveau schützt meinen kundenverwalteten Schlüssel? (3) Kann ich mein eigenes Schlüsselmaterial importieren und das Original außerhalb Ihrer Infrastruktur aufbewahren? (4) Wie schnell wird der Zugriff gesperrt, wenn ich den Schlüssel deaktiviere oder lösche? (5) Wird jeder Verschlüsselungs- und Entschlüsselungsaufruf mit der anfragenden Identität protokolliert? (6) Können Sie als Cloud-Anbieter auf meine Verschlüsselungsschlüssel zugreifen?