Kundeneigene vs. kundengemanagte Verschlüsselungsschlüssel: Was ist der Unterschied und warum ist er wichtig?

Wer kontrolliert die Schlüssel, mit denen Ihre sensiblen Daten entschlüsselt werden? Diese Frage entscheidet, ob Ihr Unternehmen echte Datenschutzsouveränität erreicht – oder nur eine Illusion von Sicherheit schafft. Cloud-Anbieter bieten standardmäßig Verschlüsselung an, und viele Unternehmen gehen davon aus, dass ihre Daten geschützt bleiben, solange Dateien verschlüsselt sind. Doch die Stärke der Verschlüsselung ist weit weniger entscheidend als die Kontrolle über die Schlüssel, wenn Cloud-Anbieter technisch in der Lage sind, auf Ihre Schlüssel zuzugreifen und Ihre Daten ohne Ihr Wissen oder Ihre Zustimmung zu entschlüsseln.

Es gibt drei unterschiedliche Modelle für das Management von Verschlüsselungsschlüsseln: vom Anbieter verwaltete Schlüssel, vom Kunden verwaltete Schlüssel (BYOK) und vom Kunden gehaltene Schlüssel (HYOK). Jedes Modell bietet unterschiedliche Kontrollstufen darüber, wer auf Ihre verschlüsselten Daten zugreifen kann. Der Unterschied zwischen Schlüsselverwaltung und Schlüsselbesitz wird besonders dann kritisch, wenn Behörden Vorladungen ausstellen, Compliance-Vorgaben einen nachweisbaren Datenschutz verlangen oder Unternehmen beweisen müssen, dass selbst ihr Cloud-Anbieter keinen Zugriff auf vertrauliche Informationen hat.

Executive Summary

Kernaussage: Vom Kunden verwaltete Verschlüsselungsschlüssel (BYOK) verbleiben in der Umgebung des Cloud-Anbieters, wo dieser darauf zugreifen kann – etwa bei behördlichen Anfragen. Vom Kunden gehaltene Schlüssel (HYOK) bleiben ausschließlich unter Kontrolle des Kunden und verhindern jeglichen Zugriff des Anbieters.

Warum das wichtig ist: Unternehmen, die auf vom Anbieter verwaltete oder BYOK-Verschlüsselung setzen, sind Datenschutzrisiken durch behördliche Zugriffsanfragen nach dem CLOUD Act, Insider-Bedrohungen beim Anbieter und Compliance-Verstöße bei Vorgaben wie DSGVO nach Schrems II oder CMMC Level 3 ausgesetzt.

5 wichtige Erkenntnisse

1. Vom Kunden verwaltete Schlüssel (BYOK) und vom Kunden gehaltene Schlüssel (HYOK) stehen für grundlegend unterschiedliche Sicherheitsmodelle – trotz ähnlicher Bezeichnungen. Bei BYOK werden vom Kunden generierte Schlüssel im Key Management Service des Anbieters gespeichert, wo dieser weiterhin technischen Zugriff hat. HYOK hingegen hält die Schlüssel ausschließlich unter Kontrolle des Kunden – etwa in On-Premises-HSMs oder privater Infrastruktur.

2. Der CLOUD Act ermöglicht es US-Behörden, Cloud-Anbieter zur Entschlüsselung von Kundendaten weltweit zu verpflichten – oft ohne Benachrichtigung des Kunden. Dieses rechtliche Rahmenwerk bedeutet, dass BYOK-Verschlüsselung keinen Schutz vor behördlichem Zugriff über den Cloud-Anbieter bietet, unabhängig vom physischen Speicherort der Daten.

3. Datenschutzsouveränität und Datenschutz sind unterschiedliche Konzepte, die verschiedene technische Maßnahmen erfordern. Die Speicherung von Daten in einer bestimmten geografischen Region (Souveränität) verhindert nicht den Zugriff des Cloud-Anbieters, wenn dieser die Verschlüsselungsschlüssel kontrolliert. Schlüsselbesitz ist daher essenziell für echten Datenschutz.

4. Compliance-Vorgaben verlangen zunehmend vom Kunden gehaltene Verschlüsselungsschlüssel nach dem Schrems-II-Urteil. DSGVO, NIS2, CMMC Level 3 und FedRAMP High fordern inzwischen Verschlüsselungsmodelle, bei denen Anbieter keinen Zugriff auf Kundendaten haben.

5. Die operativen Kompromisse von HYOK betreffen Komplexität und Kosten, nicht Sicherheit oder Funktionalität. Unternehmen können mit HYOK die gleiche Verschlüsselungsstärke und Anwendungsperformance erzielen und gewinnen echten Datenschutz hinzu – allerdings erfordert das Schlüsselmanagement zusätzliche Infrastruktur und Fachwissen.

Die drei Modelle des Verschlüsselungs-Schlüsselmanagements

Was sind vom Anbieter verwaltete Verschlüsselungsschlüssel?

Vom Anbieter verwaltete Verschlüsselung ist das Standardmodell, bei dem Cloud-Anbieter sämtliche Schlüssel innerhalb ihrer Infrastruktur generieren, speichern und verwalten.

Wenn Unternehmen Daten in die Cloud hochladen, verschlüsselt der Anbieter diese automatisch mit Schlüsseln, die er kontrolliert. Dieses Vorgehen erfordert keine Konfiguration durch den Kunden und läuft transparent ab. Der Anbieter übernimmt Schlüsselrotation, Backups und das gesamte Lebenszyklusmanagement. Kunden erhalten verschlüsselten Speicher, ohne Verschlüsselungsexpertise oder eigene Schlüsselmanagement-Infrastruktur zu benötigen.

Dieses Modell schafft jedoch grundlegende Datenschutzrisiken. Der Anbieter besitzt sowohl die verschlüsselten Daten als auch die Schlüssel zur Entschlüsselung – er kann also jederzeit auf Kundendaten zugreifen oder dazu verpflichtet werden. Strafverfolgungsbehörden können den Anbieter zur Entschlüsselung und Herausgabe von Daten zwingen. Berechtigte Mitarbeiter des Anbieters können verschlüsselte Informationen einsehen. Sicherheitsvorfälle beim Anbieter gefährden gleichzeitig Daten und Schlüssel.

Wann vom Anbieter verwaltete Schlüssel akzeptabel sind:

• Nicht sensible Daten ohne regulatorische Anforderungen
• Interne Entwicklungs- und Testumgebungen
• Öffentliche Informationen, bei denen nur Integritätsschutz erforderlich ist
• Unternehmen, die dem Sicherheits- und Compliance-Niveau ihres Cloud-Anbieters voll vertrauen

Was ist Bring Your Own Key (BYOK)?

BYOK-Verschlüsselung ermöglicht es Kunden, Verschlüsselungsschlüssel in ihrer eigenen Umgebung zu generieren und in den Key Management Service des Cloud-Anbieters hochzuladen.

Kunden erstellen Schlüssel mit eigenen kryptografischen Tools und übertragen diese dann in die KMS-Infrastruktur des Anbieters, wie AWS KMS, Azure Key Vault oder Google Cloud KMS. Der Anbieter speichert Kundenschlüssel getrennt von eigenen Schlüsseln und setzt zusätzliche Zugriffskontrollen um. Kunden können Schlüssel widerrufen oder aus dem KMS des Anbieters löschen, sodass ihre Daten unlesbar werden. Dieses Modell gibt Kunden mehr Kontrolle über den Schlüssel-Lebenszyklus, während der Anbieter die operative Komplexität der Schlüsselverwaltung übernimmt.

Die entscheidende Einschränkung: BYOK-Schlüssel liegen in der Umgebung des Anbieters. Alle Verschlüsselungs- und Entschlüsselungsvorgänge laufen über die Systeme des Anbieters – dieser muss also Zugriff auf das Schlüsselmaterial haben. Anbieter setzen zwar strenge Zugriffskontrollen und Audit-Trails ein, behalten aber die technische Möglichkeit, Kundenschlüssel zu nutzen. Behörden können Anbieter zur Entschlüsselung von Kundendaten mit BYOK-Schlüsseln zwingen. Administratoren mit ausreichenden Rechten können auf das Schlüsselmaterial zugreifen. Sicherheitsvorfälle im KMS des Anbieters können Kundenschlüssel kompromittieren.

BYOK-Implementierungsprozess:

1. Kunde generiert Verschlüsselungsschlüssel mit lokalen kryptografischen Tools oder HSMs
2. Kunde überträgt Schlüssel sicher über verschlüsselte Kanäle an das KMS des Anbieters
3. Anbieter speichert Schlüssel in seiner KMS-Infrastruktur mit kundenspezifischen Zugriffspolicies
4. Alle Verschlüsselungs-/Entschlüsselungsvorgänge erfolgen in der Anbieterumgebung mit Kundenschlüsseln
5. Kunde kann Schlüssel über die Management-Oberfläche des Anbieters rotieren, widerrufen oder löschen

BYOK-Einschränkungen beim Datenschutz:

• Schlüssel werden im KMS des Anbieters gespeichert
• Anbieter kann Schlüssel für Compliance, Administration oder bei Kompromittierung nutzen
• CLOUD Act ermöglicht behördlichen Zugriff über den Anbieter ohne Kundenbenachrichtigung
• Berechtigte Anbieter-Mitarbeiter können Schlüssel zur Entschlüsselung nutzen

Was ist Hold Your Own Key (HYOK)?

HYOK hält Verschlüsselungsschlüssel ausschließlich unter Kontrolle des Kunden – in On-Premises-Hardware-Sicherheitsmodulen oder privater Cloud-Infrastruktur, auf die der Anbieter nie Zugriff hat.

Kunden generieren und speichern Schlüssel in eigenen HSMs oder Schlüsselmanagement-Systemen. Wenn Cloud-Anwendungen Daten verschlüsseln oder entschlüsseln müssen, senden sie Anfragen an die Schlüsselmanagement-Infrastruktur des Kunden – nicht an Anbieter-Schlüssel. Die Schlüssel verlassen nie die Umgebung des Kunden, der Anbieter hat technisch keinen Zugriff. Diese Architektur ermöglicht Zero-Knowledge-Systeme, bei denen der Anbieter Kundendaten selbst auf behördliche Anordnung nicht entschlüsseln kann.

HYOK bietet echten Datenschutz, weil Anbieter keinen Zugriff auf die Entschlüsselung vertraulicher Informationen haben. Vorladungen an den Anbieter führen nicht zur Herausgabe entschlüsselter Daten, da dieser keine Schlüssel besitzt. Sicherheitsvorfälle beim Anbieter gefährden das Schlüsselmaterial nicht. Administratoren des Anbieters können – unabhängig von ihren Rechten – keine verschlüsselten Inhalte einsehen. Nur das Kundenunternehmen entscheidet, wann und wie Schlüssel genutzt werden.

HYOK-Implementierungsansätze:

• On-Premises-HSMs, integriert mit Cloud-Workloads
• Private Cloud-Bereitstellung mit vollständiger Kundenkontrolle
• Hybride Architekturen mit eigenen Key-Servern und Anbieter-Compute-Ressourcen
• Air-Gap-Systeme für maximale Sicherheitsanforderungen

HYOK-Vorteile für den Datenschutz:

• Schlüssel verlassen nie die Kontrolle des Kunden
• Anbieter hat keine technische Möglichkeit zur Entschlüsselung
• Schutz vor behördlichem Zugriff über den Anbieter
• Kunde steuert den gesamten Schlüssel-Lebenszyklus ohne Anbieterbeteiligung

Warum Anbieterzugriff auf Schlüssel Datenschutz zerstört

Wie ermöglicht der CLOUD Act behördlichen Zugriff ohne Wissen des Kunden?

Der Clarifying Lawful Overseas Use of Data (CLOUD) Act erlaubt es US-Behörden, amerikanische Technologieunternehmen zur Herausgabe von Daten zu verpflichten – unabhängig davon, wo diese physisch gespeichert sind.

Der 2018 verabschiedete CLOUD Act löste einen Rechtsstreit darüber, ob US-Unternehmen Daten auf ausländischen Servern herausgeben müssen. Das Gesetz legt fest, dass US-basierte Cloud-Anbieter jedem gültigen US-Rechtsverfahren für alle von ihnen kontrollierten Daten nachkommen müssen – der physische Speicherort ist irrelevant, wenn der Anbieter die Schlüssel besitzt. Behörden können einen Durchsuchungsbefehl oder eine Vorladung erwirken, die den Anbieter zur Entschlüsselung und Herausgabe von Kundendaten verpflichtet – egal, ob die Server in Europa, Asien oder anderswo stehen.

National Security Letters enthalten oft Geheimhaltungsanordnungen, die Anbieter daran hindern, Kunden über den Zugriff zu informieren. Kunden, die auf vom Anbieter verwaltete oder BYOK-Verschlüsselung setzen, erfahren möglicherweise nie, dass Behörden ihre sensiblen Informationen entschlüsselt und eingesehen haben. Der Anbieter besitzt die technische Möglichkeit zur Schlüsselverwendung, die Behörden die rechtliche Befugnis dazu – und Kunden haben keine technische Kontrolle, um den Zugriff zu verhindern.

Dieses Rahmenwerk bedeutet: Maßnahmen wie die Speicherung von Daten in bestimmten Regionen bieten keinen Datenschutz, solange Anbieter die Schlüssel kontrollieren. Europäische Daten auf europäischen Servern bleiben für US-Behörden zugänglich, wenn ein amerikanischer Cloud-Anbieter die Schlüssel hält.

Folgen des CLOUD Act für Verschlüsselungsmodelle:

• Vom Anbieter verwaltete Schlüssel: Anbieter kann Daten nach rechtlicher Anordnung entschlüsseln
• BYOK-Schlüssel im KMS des Anbieters: Anbieter kann Kundenschlüssel zur Entschlüsselung nutzen, wenn er dazu verpflichtet wird
• HYOK-Schlüssel unter Kundenkontrolle: Anbieter kann Daten nicht entschlüsseln, da ihm die Schlüssel fehlen

Was ist der SHIELD Act und warum reicht er nicht aus?

Der Securing and Handling of Internet and Electronic Data (SHIELD) Act – vorgeschlagen, aber noch nicht verabschiedet – soll verhindern, dass ausländische Regierungen über Cloud-Anbieter auf US-Daten zugreifen.

Das Gesetz würde Cloud-Anbietern verbieten, ausländischen Behörden ohne US-Gerichtsbeschluss Zugriff auf Daten von US-Personen zu gewähren. Es zielt auf reziproke Schutzmechanismen ab, ähnlich wie der CLOUD Act US-Behörden Zugriff auf im Ausland gespeicherte Daten verschafft. Selbst bei Verabschiedung würde der SHIELD Act jedoch den Zugriff der US-Regierung auf Kundendaten nicht einschränken, die technische Entschlüsselungsfähigkeit der Anbieter nicht beseitigen und das grundlegende Datenschutzproblem von Anbieter-Schlüsseln nicht lösen.

Unternehmen, denen Datenschutz wichtig ist, können sich nicht auf Gesetzesinitiativen verlassen, die möglicherweise nie verabschiedet werden und das Kernproblem des Anbieterzugriffs nicht adressieren. Technische Maßnahmen wie vom Kunden gehaltene Schlüssel bieten zuverlässigen Schutz – unabhängig von gesetzlichen Änderungen.

Warum Gesetzesinitiativen technische Maßnahmen nicht ersetzen können:

• Gesetze können geändert oder aufgehoben werden
• Durchsetzung variiert je nach Rechtsraum und politischer Lage
• Geheimhaltungsanordnungen verhindern, dass Kunden von Zugriffen erfahren
• Technische Maßnahmen wie HYOK beseitigen die Anbieterfähigkeit zum Datenzugriff – unabhängig vom Rechtsrahmen

Wie hat Schrems II die Anforderungen an Datenschutzsouveränität verändert?

Das Schrems-II-Urteil des Europäischen Gerichtshofs von 2020 hat das Privacy-Shield-Abkommen für US-Unternehmen zur Übertragung von EU-Daten in die USA für ungültig erklärt.

Das Gericht stellte fest, dass US-Überwachungsgesetze – insbesondere FISA Section 702 und Executive Order 12333 – keinen ausreichenden Schutz für die Daten von EU-Bürgern bieten. Amerikanische Cloud-Anbieter unterliegen US-Recht und können nicht garantieren, dass EU-Daten vor US-Zugriff geschützt bleiben. Das Urteil betonte, dass US-Recht Geheimdiensten Zugriff auf Daten von US-Unternehmen ermöglicht – ohne ausreichende gerichtliche Kontrolle oder Rechtsmittel für EU-Bürger.

Diese Entscheidung hat die Herangehensweise europäischer Unternehmen an Cloud-Verschlüsselung grundlegend verändert. Die reine Speicherung von Daten in EU-Regionen genügt den DSGVO-Anforderungen nicht, wenn amerikanische Anbieter die Schlüssel kontrollieren und zur Entschlüsselung gezwungen werden können. Das Urteil verlangt technische Maßnahmen, die den Zugriff des Anbieters verhindern – und lenkt Unternehmen auf HYOK-Modelle oder private Bereitstellungen.

Schrems-II-Folgen für das Schlüsselmanagement:

• EU-Unternehmen können sich nicht allein auf vertragliche Datenschutzvereinbarungen verlassen
• Technische Maßnahmen zur Verhinderung des Anbieterzugriffs sind für US-EU-Datenübertragungen jetzt Pflicht
• Vom Kunden gehaltene Schlüssel ermöglichen DSGVO-Compliance, da der Anbieter keinen Zugriff auf Daten hat
• Die NIS2-Richtlinie verstärkt die Anforderungen für Unternehmen in kritischen Sektoren

Welche Compliance-Rahmen verlangen Kundenschlüsselbesitz?

Regulatorische Vorgaben verlangen zunehmend Verschlüsselungsmodelle, bei denen Anbieter keinen Zugriff auf Kundendaten haben – insbesondere für Regierungsauftragnehmer, kritische Infrastrukturen und Unternehmen, die EU-Personenbezogene Daten verarbeiten.

CMMC Level 3 für Auftragnehmer im Verteidigungsbereich, die mit CUI umgehen, verlangt kryptografische Mechanismen zum Schutz vor unbefugter Offenlegung während der Übertragung und im ruhenden Zustand. Der Fokus auf CUI-Schutz und die Ausrichtung an NIST 800-172 erfordern faktisch kundengesteuerte Schlüssel, die Anbieterzugriff auf vertrauliche Informationen verhindern.

FedRAMP High und DoD Impact Level 5 Workloads verlangen kryptografische Schutzmaßnahmen, die Cloud-Anbietern den Zugriff auf Kundendaten verwehren. Diese Rahmen gehen davon aus, dass Daten, die von Bundesbehörden oder Verteidigungssystemen verarbeitet werden, vor allen Parteien außerhalb des Kundenunternehmens – auch dem Hosting-Anbieter – geschützt werden müssen.

DSGVO Artikel 32 verlangt angemessene technische Maßnahmen zur Datensicherheit. Nach Schrems II reicht Verschlüsselung allein nicht aus, wenn Anbieter die Schlüssel kontrollieren und zur Entschlüsselung nach ausländischem Recht gezwungen werden können. Unternehmen, die EU-Personenbezogene Daten in Länder ohne angemessene Datenschutzgesetze übertragen, müssen zusätzliche Maßnahmen ergreifen – vom Kunden gehaltene Schlüssel sind eine der wenigen technischen Lösungen, die diese Anforderung erfüllen.

Compliance-Rahmen, die Kundenschlüsselbesitz bevorzugen:

• CMMC Level 3 für CUI-Schutz in der Verteidigungslieferkette
• FedRAMP High und DoD IL5 für Bundesbehördendaten
• DSGVO für EU-Personenbezogene Datenübertragung in Drittländer nach Schrems II
• NIS2 für wesentliche und wichtige Unternehmen in kritischen Sektoren
• Deutsches BDSG und französische Datenschutzsouveränitätsanforderungen

Technische Umsetzung: Wie funktionieren die Modelle?

Wie setzen Cloud-Anbieter BYOK um?

Cloud-Anbieter implementieren BYOK über Key Management Services, die vom Kunden generierte Schlüssel akzeptieren, während sie die Kontrolle über die Verschlüsselungsinfrastruktur behalten.

Kunden generieren Schlüssel mit lokalen Tools wie OpenSSL, Anbieter-CLIs oder Hardware-Sicherheitsmodulen. Anschließend laden sie das Schlüsselmaterial über sichere API-Aufrufe mit TLS-Verschlüsselung in das KMS des Anbieters hoch. Der Anbieter speichert Kundenschlüssel in seiner KMS-Infrastruktur, häufig in FIPS-140-2-zertifizierten HSMs, mit Zugriffskontrollen, die festlegen, welche Kundenkonten und Dienste den jeweiligen Schlüssel nutzen dürfen.

Wenn Anwendungen Daten verschlüsseln müssen, rufen sie die KMS-API des Anbieters auf. Das KMS nutzt den Kundenschlüssel zur Verschlüsselung und gibt den Chiffretext zurück. Die Entschlüsselung erfolgt analog: Die Anwendung sendet den Chiffretext an das KMS, das mit dem Kundenschlüssel entschlüsselt und den Klartext zurückgibt. Alle kryptografischen Operationen laufen in der Infrastruktur des Anbieters mit Kundenschlüsseln, die in dessen Systemen liegen.

BYOK-Workflow:

1. Kunde generiert Schlüssel mit lokalen kryptografischen Tools
2. Kunde lädt Schlüssel per verschlüsseltem API-Aufruf ins KMS des Anbieters
3. Anbieter speichert Schlüssel im KMS mit kundenspezifischen Zugriffspolicies
4. Anwendungen fordern Verschlüsselungs-/Entschlüsselungsvorgänge beim KMS des Anbieters an
5. KMS des Anbieters führt kryptografische Operationen mit dem Kundenschlüssel aus
6. Anbieter gibt das Ergebnis an die Anwendung zurück

Wie hält HYOK die Kontrolle beim Kunden?

HYOK-Implementierungen speichern Verschlüsselungsschlüssel in kundenkontrollierter Infrastruktur und führen kryptografische Operationen außerhalb der Anbieterumgebung aus.

Kunden betreiben On-Premises-HSMs oder Schlüsselmanagementsysteme, die niemals Schlüssel mit der Infrastruktur des Anbieters synchronisieren. Wenn Cloud-Anwendungen Daten verschlüsseln oder entschlüsseln müssen, verbinden sie sich über sichere Netzwerke mit dem Schlüsselmanagementsystem des Kunden. Die Infrastruktur des Kunden führt die kryptografische Operation aus und gibt das Ergebnis zurück – die Schlüssel verlassen nie die Kontrolle des Kunden. Einige Implementierungen setzen auf private Cloud-Bereitstellung, bei der der Kunde den gesamten Infrastruktur-Stack kontrolliert, sodass Anbieterzugriff technisch unmöglich ist.

Fortschrittliche HYOK-Architekturen nutzen Verschlüsselung auf Anwendungsebene: Daten werden bereits auf Client-Geräten verschlüsselt, bevor sie in die Cloud übertragen werden. Der Cloud-Anbieter erhält nur Chiffretext und hat keine Möglichkeit zur Entschlüsselung. So entstehen Zero-Knowledge-Systeme, bei denen der Anbieter technisch keinen Zugriff auf Kundendaten hat – selbst bei behördlicher Anordnung.

HYOK-Workflow:

1. Kunde betreibt HSM oder Schlüsselmanagementsystem in seiner Infrastruktur
2. Kunde generiert und speichert alle Schlüssel lokal
3. Cloud-Anwendungen verbinden sich mit dem Schlüsselmanagementsystem des Kunden
4. Kundensystem führt Verschlüsselungs-/Entschlüsselungsvorgänge aus
5. Schlüssel verlassen nie die Kontrolle des Kunden oder gelangen in die Anbieterumgebung
6. Anbieter erhält nur verschlüsselte Daten und kann diese nicht entschlüsseln

Auswirkungen auf Sicherheit und Compliance

Welche Bedrohungen verhindert Kundenschlüsselbesitz?

Vom Kunden gehaltene Verschlüsselungsschlüssel eliminieren ganze Bedrohungskategorien, die bei vom Anbieter verwalteten oder BYOK-Modellen bestehen bleiben.

Behördlicher Zugriff über Anbieter-Compliance entfällt, wenn Anbieter keine Entschlüsselungsmöglichkeit haben. Vorladungen und Durchsuchungsbefehle an den Anbieter führen nicht zur Herausgabe entschlüsselter Daten, da er keine Schlüssel besitzt. Geheimdienste können Anbieter nicht zur Überwachung zwingen, wenn diese technisch keinen Zugriff auf Kundendaten haben. Dieser Schutz gilt unabhängig davon, welche Regierung die Anfrage stellt und welcher Rechtsrahmen gilt.

Böswillige Insider beim Cloud-Anbieter können nicht auf Kundendaten zugreifen, wenn die Schlüssel außerhalb der Anbieterinfrastruktur bleiben. Sicherheitsvorfälle beim Anbieter, die Administrationssysteme, KMS-Infrastruktur oder Backups kompromittieren, gefährden weder Schlüssel noch ermöglichen sie die Entschlüsselung von Daten. Unabhängige Prüfer, Managed Service Provider und andere Parteien mit Zugriff auf Anbietersysteme können Kundendaten nicht entschlüsseln.

Bedrohungen, die durch Kundenschlüsselbesitz entschärft werden:

• Behördlicher Zugriff über Anbieter-Compliance (CLOUD-Act-Szenarien)
• Insiderzugriff beim Anbieter auf verschlüsselte Daten
• Sicherheitsvorfälle beim Anbieter, die Daten und Schlüssel kompromittieren
• Grenzüberschreitender Datenzugriff, der Datenschutzsouveränität umgeht
• Drittparteienzugriff über Anbietersysteme oder Partnerschaften

Welche operativen Kompromisse gibt es?

Vom Kunden gehaltene Verschlüsselungsschlüssel erhöhen die operative Komplexität und Kosten – diese müssen Unternehmen gegen die Datenschutz- und Compliance-Vorteile abwägen.

Die Performance-Auswirkungen hängen vom Implementierungsansatz ab. HYOK-Lösungen, die Netzwerkverbindungen zum Schlüsselmanagementsystem des Kunden erfordern, verursachen zusätzliche Latenz bei Verschlüsselungsvorgängen im Vergleich zu Anbieter-KMS. Unternehmen müssen eine zuverlässige Netzwerkanbindung zwischen Cloud-Workloads und On-Premises-Schlüsselmanagement sicherstellen. Private Bereitstellungsmodelle, bei denen Kunden die gesamte Infrastruktur kontrollieren, eliminieren die Netzwerk-Latenz und erhalten dennoch den Schlüsselbesitz.

Verfügbarkeit und Notfallwiederherstellung werden komplexer, wenn Kunden die Schlüssel selbst verwalten. Unternehmen müssen HSM-Redundanz, Backup-Prozesse und Wiederherstellungsmechanismen ohne Anbieter-Lösungen implementieren. Schlüsselmanagement erfordert spezielles Fachwissen, das viele Unternehmen nicht im Haus haben. Die Kosten für HSM-Hardware, sichere Standorte und qualifiziertes Personal übersteigen die Nullkosten von Anbieter-Verschlüsselung.

Operative Überlegungen:

• Performance: Mögliche Latenz bei netzwerkübergreifenden Schlüsseloperationen vs. Anbieter-KMS
• Verfügbarkeit: Kunde ist für Redundanz und Notfallwiederherstellung der Schlüsselinfrastruktur verantwortlich
• Komplexität: Erfordert Verschlüsselungsexpertise und Prozesse für den Schlüssel-Lebenszyklus
• Kosten: HSM-Hardware, Standorte, Personal vs. kostenlose Anbieter-Verschlüsselung

Wann ist HYOK oder private Bereitstellung Pflicht?

Bestimmte Compliance-Anforderungen, Bedrohungsmodelle und Datenklassifizierungen machen vom Kunden gehaltene Schlüssel zur Pflicht.

Unternehmen, die CUI für Verteidigungsaufträge auf CMMC Level 3 verarbeiten, müssen Anbieterzugriff verhindern, um die erhöhten Sicherheitsanforderungen zu erfüllen. Bundesbehörden mit Impact Level 5-Daten oder FedRAMP High benötigen kryptografische Schutzmaßnahmen, bei denen Anbieter keine Informationen entschlüsseln können. Europäische Unternehmen, die personenbezogene Daten an US-Anbieter übertragen, müssen nach Schrems II technische Maßnahmen ergreifen, die US-Zugriff über Anbieter-Compliance verhindern.

Zero-Trust-Architekturen, die alle Netzwerksegmente und Dienstleister als potenziell kompromittiert betrachten, erfordern vom Kunden gehaltene Schlüssel. Unternehmen in adversen Bedrohungsumgebungen, in denen Staaten Anbieter zur Zusammenarbeit zwingen könnten, benötigen Verschlüsselungsmodelle, bei denen Anbieter technisch nicht helfen können. Kritische Infrastrukturen unter NIS2 müssen nachweisen, dass essenzielle Dienste auch bei Sicherheitsvorfällen oder rechtlicher Anordnung beim Cloud-Anbieter geschützt bleiben.

Szenarien, die Kundenschlüsselbesitz erfordern:

• CMMC Level 3 CUI-Schutz für Verteidigungsauftragnehmer
• FedRAMP High und DoD IL5 für Bundesbehörden-Workloads
• DSGVO-konforme EU-US-Datenübertragungen nach Schrems II
• Behörden- und Verteidigungssysteme mit klassifizierten Informationen
• Finanzdienstleister mit geistigem Eigentum und Handelsalgorithmen
• Gesundheitssysteme zum Schutz der Patientendaten vor externen Parteien

Ihre Datenschutzanforderungen stehen über allen anderen Schlüsselvariablen und -entscheidungen

Die Unterscheidung zwischen vom Kunden verwalteten und vom Kunden gehaltenen Verschlüsselungsschlüsseln entscheidet, ob Unternehmen echten Datenschutz erreichen oder nur eine Scheinsicherheit schaffen. BYOK-Modelle, bei denen vom Kunden generierte Schlüssel in der Infrastruktur des Anbieters gespeichert werden, ermöglichen weiterhin Anbieterzugriff – sowohl bei rechtlicher Anordnung als auch bei Sicherheitsvorfällen. Der CLOUD Act und ähnliche Gesetze machen den physischen Speicherort der Daten bedeutungslos, wenn Anbieter die Schlüssel kontrollieren und zur Entschlüsselung gezwungen werden können – ohne Benachrichtigung des Kunden.

Vom Kunden gehaltene Schlüssel durch HYOK-Implementierung oder private Bereitstellung sind das einzige Modell, das vor behördlichem Zugriff über den Anbieter, Insider-Bedrohungen beim Anbieter und Compliance-Verstößen schützt, wenn Anbieter auf verschlüsselte Daten zugreifen können. Unternehmen, die CMMC Level 3, FedRAMP High oder DSGVO-Anforderungen nach Schrems II unterliegen, stellen zunehmend fest, dass Kundenschlüsselbesitz von einer optionalen Sicherheitsmaßnahme zur Pflicht geworden ist.

Die operativen Kompromisse betreffen Komplexität und Kosten – nicht Sicherheit oder Funktionalität. Unternehmen können mit vom Kunden gehaltenen Schlüsseln die gleiche Verschlüsselungsstärke und Anwendungsmöglichkeiten beibehalten und gewinnen den Datenschutz, den Compliance-Rahmen heute verlangen. Kiteworks bietet diese Fähigkeit durch private Bereitstellungsoptionen, die Kunden vollständige Kontrolle über Verschlüsselungsschlüssel geben, Anbieterzugriff auf sensible Daten ausschließen und echte Datenschutzsouveränität ermöglichen, die selbst strengste regulatorische Anforderungen erfüllt.

Wie Kiteworks kundengesteuerte Verschlüsselung ermöglicht

Kiteworks implementiert vom Kunden gehaltene Verschlüsselung durch private Bereitstellungsoptionen, die Unternehmen vollständige Kontrolle über Verschlüsselungsschlüssel und Datenzugriff geben.

Die Private Data Network-Architektur wird On-Premises, in privaten Cloud-Umgebungen oder in Air-Gap-Netzwerken bereitgestellt, in denen Kunden den gesamten Infrastruktur-Stack kontrollieren. AES-256-Verschlüsselung schützt alle Daten im ruhenden Zustand mit Schlüsseln, die nie die Kundeninfrastruktur verlassen. Kiteworks-Mitarbeiter und Support-Personal haben keinen Zugriff auf Kundenschlüssel oder können Kundendaten entschlüsseln – das ermöglicht eine echte Zero-Knowledge-Architektur.

Die Integration von Hardware Security Modules bietet FIPS 140-2 Level 3-Schutz für Verschlüsselungsschlüssel mit manipulationssicherer Hardware unter exklusiver Kundenkontrolle. Unternehmen können eigene Schlüsselmanagement-Prozesse, Rotationspläne und Zugriffskontrollen umsetzen – ohne Beteiligung von Kiteworks. Die Plattform unterstützt sowohl On-Premises-HSM-Appliances als auch vom Kunden verwaltete Cloud-HSM-Services.

Private Bereitstellung beseitigt die Datenschutzrisiken, die in Multi-Tenant-Cloud-Architekturen inhärent sind. Vorladungen von Strafverfolgungsbehörden können Kiteworks nicht zur Entschlüsselung von Kundendaten zwingen, da Kiteworks technisch dazu nicht in der Lage ist. Der CLOUD Act ist irrelevant, wenn der Dienstleister nie Zugriff auf Kundenschlüssel hat. Unternehmen erreichen echte Datenschutzsouveränität, die die Anforderungen der DSGVO nach Schrems II erfüllt.

Die Plattform vereint sichere E-Mail, Filesharing, Managed File Transfer und Web-Formulare in einer einheitlichen Umgebung mit konsistenter Verschlüsselung und Zugriffskontrolle. Dadurch werden Sicherheitslücken vermieden, die entstehen, wenn Unternehmen für verschiedene Kommunikationskanäle unterschiedliche Einzellösungen mit verschiedenen Schlüsselmanagement-Modellen einsetzen.

Erfahren Sie mehr darüber, wie Sie mit vom Kunden gehaltenen Verschlüsselungsschlüsseln maximalen Datenschutz erreichen – vereinbaren Sie eine individuelle Demo.

Weitere Ressourcen

• Blog Post
  Public vs. Private Key Encryption: Eine ausführliche Erklärung
• Blog Post
  Wichtige Best Practices für die Datenverschlüsselung
• eBook Top 10 Trends bei der Datenverschlüsselung: Eine detaillierte Analyse zu AES-256
• Blog Post
  E2EE im Praxiseinsatz: Beispiele für Ende-zu-Ende-Verschlüsselung
• Blog Post
  Ultimativer Leitfaden zu AES-256-Verschlüsselung: Datensicherheit auf höchstem Niveau