BYOK und HYOK im Cloud-Vertrag: Verschlüsselungsschlüssel, Zugriffsrechte und Notfallzugriff richtig regeln

Ein Cloud-Anbieter bestätigt im Vertriebsgespräch, dass deine Daten „selbstverständlich verschlüsselt“ seien. Erst kurz vor Vertragsabschluss fragt die Informationssicherheit nach: Wer kann die Schlüssel tatsächlich nutzen? Kann der Anbieter bei einem Supportfall entschlüsseln? Was passiert, wenn euer HSM ausfällt oder ein Administrator das Unternehmen verlässt? Genau an diesen Punkten entscheidet sich, ob BYOK oder HYOK echte Kontrolle schafft oder nur ein technisches Etikett bleibt.

BYOK und HYOK gewinnen an Bedeutung, weil Unternehmen sensible Geschäfts-, Personen- und Entwicklungsdaten in Cloud-Diensten verarbeiten. Das gilt besonders für SaaS-Anwendungen mit KI-Funktionen, für regulierte Branchen und für Organisationen, die Abhängigkeiten von einzelnen Anbietern begrenzen wollen. Im Cloud-Vertrag reichen allgemeine Aussagen zur Verschlüsselung nicht aus. Du musst Schlüsselverwaltung, Rollen, Notfallmechanismen und den Exit konkret regeln.

Infografik zu BYOK und HYOK im Cloud-Vertrag: Verschlüsselungsschlüssel, Zugriffsrechte und Notfallzugriff richtig regeln (KI-generiert).

Was BYOK und HYOK tatsächlich unterscheiden

BYOK steht für „Bring Your Own Key“. Du oder dein Unternehmen erzeugt und verwaltet einen Schlüssel, den ihr in einen vom Cloud-Anbieter unterstützten Schlüsselverwaltungsdienst einbringt. Häufig geschieht das über einen Cloud-KMS oder ein angebundenes Hardware Security Module, kurz HSM. Der Anbieter stellt die technische Umgebung bereit, du steuerst jedoch wesentlich, welcher Schlüssel zur Verschlüsselung verwendet wird und wann er rotiert oder deaktiviert wird.

Die Kontrolle ist bei BYOK allerdings nicht automatisch vollständig. Entscheidend ist die konkrete Architektur:

• Liegt der Schlüssel in einem KMS des Cloud-Anbieters, betreibt der Anbieter weiterhin wesentliche Teile der Schlüsselplattform.
• Werden Schlüsselmaterial und Schlüsseloperationen in einem kundeneigenen HSM kontrolliert, kann dein Einfluss deutlich größer sein.
• Dürfen Dienste des Anbieters den Schlüssel automatisiert verwenden, ohne dass ein menschlicher Zugriff erfolgt, bleibt zu prüfen, welche Berechtigungen und Protokolle bestehen.
• Können Supportmitarbeitende, Unterauftragnehmer oder Behördenzugriffe technische Entschlüsselung ermöglichen, muss der Vertrag diese Fälle erfassen.

HYOK bedeutet „Hold Your Own Key“. Im engeren Verständnis verbleibt der Schlüssel ausschließlich unter deiner Kontrolle, etwa in einem eigenen oder von dir beauftragten externen Schlüsselmanagementsystem. Die Cloud-Anwendung fordert für eine Entschlüsselungsoperation eine Freigabe bei deinem Schlüsselservice an. Ist dieser nicht verfügbar oder verweigerst du die Freigabe, können die geschützten Daten nicht genutzt werden.

HYOK bietet also potenziell mehr Souveränität, kann aber die Verfügbarkeit, Integration und Supportfähigkeit einschränken. Nicht jede Cloud-Funktion unterstützt HYOK. Funktionen wie Volltextsuche, Datenanalyse, Backup, KI-gestützte Verarbeitung oder mobile Offline-Nutzung können technische Ausnahmen erfordern. Deshalb darf eine Vertragsklausel nicht nur „HYOK“ nennen. Sie muss festlegen, für welche Daten, Dienste, Regionen und Verarbeitungsvorgänge das Modell gilt.

Den Schutzgegenstand präzise definieren

Der Vertrag sollte zuerst klar beschreiben, welche Daten und Systeme mit kundenseitig kontrollierten Schlüsseln geschützt werden. Eine pauschale Formulierung wie „sämtliche Kundendaten“ führt schnell zu Streit, wenn Protokolldaten, Metadaten, Sicherungskopien oder Telemetrie ausgenommen bleiben.

Klärungsbedürftig sind insbesondere:

• Primärdaten in Datenbanken, Dateispeichern und Collaboration-Systemen
• Backups, Replikate und Archive
• Suchindizes, Caches und temporäre Verarbeitungsspeicher
• Metadaten wie Nutzerkennungen, Zeitstempel und Zugriffsprotokolle
• Daten, die für Diagnose, Support oder Sicherheitsüberwachung verarbeitet werden
• Datenflüsse zu verbundenen Diensten, APIs und Unterauftragnehmern
• Trainings-, Eingabe- und Ausgabedaten von KI-Funktionen

Gerade bei KI-gestützten SaaS-Diensten kann eine Verschlüsselung im Ruhestand allein unzureichend sein. Werden Inhalte zur Verarbeitung entschlüsselt, musst du klären, welche Komponente darauf zugreift, ob Daten gespeichert werden und ob sie in andere Mandanten- oder Modellprozesse gelangen können. Ergänzend hilft unser Beitrag zu KI-SaaS-Verträgen, Trainingsdaten, Output-Rechten und AI-Act-Pflichten.

Schlüsselhierarchie und HSM vertraglich beschreiben

Technische Begriffe wie „AES-Verschlüsselung“ sagen noch wenig über die tatsächliche Kontrolle aus. Wesentlich ist die Schlüsselhierarchie. Üblich sind Datenverschlüsselungsschlüssel, die Daten direkt schützen, und übergeordnete Schlüssel, die diese Schlüssel absichern. Der Cloud-Anbieter kann Datenverschlüsselungsschlüssel automatisiert erzeugen, während ein von dir kontrollierter Hauptschlüssel deren Nutzung absichert.

Der Vertrag oder eine technische Anlage sollte mindestens festhalten:

• wo Schlüsselmaterial erzeugt wird und wer den Erzeugungsprozess auslöst
• ob und in welcher Form Schlüssel importiert werden
• welches HSM oder welcher KMS eingesetzt wird
• ob das HSM mandantenfähig oder ausschließlich für dich reserviert ist
• welche Zertifizierungen oder Sicherheitsstandards der Anbieter für das HSM zusichert
• in welchen Regionen Schlüssel und verschlüsselte Daten verarbeitet werden
• ob Schlüsselmaterial jemals außerhalb der vereinbarten Umgebung gespeichert, gespiegelt oder exportiert wird
• wie Schlüsselversionen verwaltet und dokumentiert werden

Vermeide unklare Zusagen wie „branchenübliche Sicherheitsmaßnahmen“. Besser ist eine nachvollziehbare Leistungsbeschreibung mit Architekturdiagramm, Schnittstellenbeschreibung und Verantwortlichkeitsmatrix. Diese Unterlagen sollten Vertragsbestandteil sein und nicht bloß unverbindliche Produktdokumentation.

Providerzugriff, Rollen und Notfallzugriff begrenzen

Ein zentraler Irrtum lautet: Wenn der Anbieter die Daten nicht dauerhaft entschlüsseln kann, gibt es kein Zugriffsrisiko. In der Praxis entstehen Risiken über administrative Rollen, privilegierte Servicekonten, Supportzugänge und temporäre Freigaben.

Regle deshalb, wer Schlüsseloperationen ausführen darf. Dazu gehören die Aktivierung eines Schlüssels, die Änderung von Berechtigungen, Rotation, Exportversuche, Löschung und die Freigabe einer Entschlüsselung. Benenne dabei mindestens folgende Rollen:

• eure fachlich und technisch verantwortlichen Schlüsseladministratoren
• Sicherheitsadministratoren mit Kontroll- und Freigaberechten
• automatisierte Dienstidentitäten der Cloud-Plattform
• Supportpersonal des Anbieters
• Unterauftragnehmer und deren administrative Zugriffe
• Revisoren oder externe Prüfer mit ausschließlich lesendem Zugriff auf Nachweise

Für Anbieterzugriffe empfiehlt sich ein ausdrückliches Verbot, soweit der Zugriff nicht für eine klar definierte technische Leistung erforderlich ist. Ist ein Zugriff notwendig, sollte er nur zeitlich begrenzt, personengebunden, protokolliert und möglichst von dir vorab freigegeben sein. Für kritische Operationen kann ein Vier-Augen-Prinzip vereinbart werden.

Ein „Break-Glass“-Zugang für Notfälle darf keine Hintertür sein. Der Vertrag sollte den Auslöser, die berechtigten Personen, die maximale Dauer, die Protokollierung und die nachträgliche Information regeln. Zudem muss klar sein, ob ein Notfallzugriff tatsächlich eine Entschlüsselung erlaubt oder lediglich den Betrieb der Schlüsselplattform wiederherstellt.

Rotation, Sperrung und Wiederherstellung realistisch planen

Schlüsselrotation ist kein Selbstzweck. Sie soll die Folgen eines möglichen Schlüsselverlusts begrenzen und organisatorische Veränderungen abbilden. Eine starre Frist ist nur sinnvoll, wenn sie zur Architektur passt. Entscheidend ist, wie eine Rotation technisch erfolgt, ob Daten neu verschlüsselt werden und welche Auswirkungen auf Verfügbarkeit und Kosten entstehen.

Vereinbare einen dokumentierten Prozess für diese Situationen:

Situation	Vertraglich zu regelnde Punkte
Planmäßige Rotation	Zuständigkeit, Vorlaufzeit, Testverfahren, Auswirkungen auf Backups und Wiederherstellung
Verdacht auf Kompromittierung	Meldeweg, Sofortmaßnahmen, Sperrung, forensische Sicherung, Ersatzschlüssel
Verlust von Administratorrechten	Identitätsprüfung, Mehrpersonenfreigabe, Wiederherstellungsweg, Protokollierung
Ausfall des KMS oder HSM	Verfügbarkeitsziel, Redundanz, Failover, zulässige Wartezeiten und Kommunikation
Fehlbedienung oder versehentliche Löschung	Schutzfristen, Wiederherstellungsmöglichkeiten, Freigabeprozess und Haftungsfolgen

Besondere Aufmerksamkeit verlangt die Wiederherstellung. Wenn nur ein einzelner Administrator oder ein einzelnes Hardware-Token einen Schlüssel wiederherstellen kann, schafft HYOK eine gefährliche Abhängigkeit. Plane mehrere berechtigte Personen, getrennte Aufbewahrung und ein getestetes Verfahren. Das Verfahren darf allerdings nicht dazu führen, dass der Cloud-Anbieter eigenständig Ersatzschlüssel erzeugen oder auf deine Daten zugreifen kann.

Sicherheitsvorfälle und Betriebsstörungen überschneiden sich häufig. Für die operative Seite solltest du auch Support-Level und Störungsklassen sauber abgrenzen. Bei Angriffsszenarien sind zudem Regelungen zur Ransomware-Notfallhilfe im IT-Supportvertrag wichtig.

SLA und Haftung an die Schlüsselarchitektur anpassen

Eine HYOK-Architektur kann die Verfügbarkeit eines Cloud-Dienstes unmittelbar beeinflussen. Ist dein externer Schlüsselservice nicht erreichbar, kann auch die Anwendung ausfallen. Der Cloud-Anbieter wird für diesen Fall regelmäßig keine uneingeschränkte Verantwortung übernehmen wollen. Das ist nachvollziehbar, darf aber nicht zu einer pauschalen Freizeichnung führen.

Trenne die Verantwortungsbereiche:

• Der Anbieter haftet für die Verfügbarkeit und korrekte Integration seiner Cloud-Dienste, Schnittstellen und vereinbarten Schlüsselanbindung.
• Du verantwortest den Betrieb der von dir kontrollierten Schlüsselkomponenten, soweit diese außerhalb der Anbieterleistung liegen.
• Für gemeinsam verursachte Störungen braucht es ein abgestimmtes Analyse- und Eskalationsverfahren.
• Der Anbieter muss nachvollziehbare Diagnoseinformationen bereitstellen, damit du Fehler in der Schlüsselanbindung prüfen kannst.

Lege fest, ob Nichtverfügbarkeit durch eine fehlerhafte Schlüsselanbindung als Ausfallzeit im SLA zählt. Auch Messpunkt, Wartungsfenster, Ausschlüsse und Servicegutschriften müssen dazu passen. Grundlagen dafür findest du in unserem Beitrag Service Level Agreements richtig vereinbaren. Bei Schäden durch unberechtigten Zugriff, fehlerhafte Schlüsseloperationen oder verlorene Daten sollte die Haftungsregelung diese Risiken ausdrücklich erfassen. Eine allgemeine Klausel zur Haftungsbegrenzung reicht selten aus, wie wir in Haftung im IT-Vertrag sinnvoll begrenzen erläutern.

Exit: Schlüsselentzug allein genügt nicht

Beim Vertragsende ist das Sperren oder Löschen eines Hauptschlüssels ein wirksames Mittel, um Daten unzugänglich zu machen. Es ersetzt jedoch keine Exit-Regelung. Du brauchst weiterhin eine lesbare Datenherausgabe, eine Bestätigung zur Löschung beim Anbieter und Klarheit über Backups, Replikate sowie gesetzliche Aufbewahrungspflichten.

Der Vertrag sollte für den Exit bestimmen:

• in welchem Format und über welchen sicheren Übertragungsweg du Daten und zugehörige Metadaten erhältst
• wie lange der Zugang zur Datenexportfunktion besteht
• welche Schlüssel oder Schlüsselreferenzen für die Übergabe erforderlich sind
• wann Schlüssel deaktiviert und wann sie endgültig gelöscht werden
• wie der Anbieter mit verschlüsselten Backups und verbleibenden Kopien umgeht
• welche Lösch- und Vernichtungsnachweise du erhältst
• ob und wie eine Migration zu einem anderen KMS oder HSM unterstützt wird

Die Datenrückgabe muss vor der endgültigen Schlüsselvernichtung abgeschlossen sein. Sonst hast du zwar den Zugriff des Anbieters beendet, aber möglicherweise auch deinen eigenen Zugang zu geschäftskritischen Informationen verloren. Für die umfassende Planung lies auch unseren Beitrag zur Exit-Strategie und Datenrückgabe beim Cloud-Anbieter.

Checkliste für deine Vertragsverhandlung

Prüfe vor der Unterschrift, ob du diese Fragen mit „ja“ beantworten kannst:

• Ist für jeden relevanten Dienst klar, ob BYOK, HYOK oder ein anbieterverwalteter Schlüssel gilt?
• Sind Datenarten, Speicherorte, Backups, Metadaten und KI-Verarbeitungen erfasst?
• Kennst du die Schlüsselhierarchie und die Rolle von KMS und HSM?
• Sind Providerzugriffe technisch und vertraglich auf das Notwendige begrenzt?
• Gibt es einen kontrollierten, protokollierten Notfallzugriff?
• Sind Rotation, Sperrung, Verlust und Wiederherstellung getestet und dokumentiert?
• Passen SLA, Incident-Prozess und Haftungsregeln zur gewählten Architektur?
• Ist der Zugriff auf deine Daten auch während des Exit gesichert, bevor Schlüssel gelöscht werden?

BYOK und HYOK sind keine Standardklauseln, die du ohne technische Prüfung übernehmen solltest. Lass IT-Sicherheit, Fachbereich, Einkauf und Recht gemeinsam festlegen, welche Kontrolle notwendig und betrieblich tragfähig ist. Passende Seminare und Termine findest du bei uns auf cmt.de.