Die Diskussion um Datensouveränität dreht sich häufig um rechtliche Fragen: Wem gehören meine Daten in der Cloud? Wer darf sie einsehen? Oft geht dabei unter, dass moderne Cloud‑Dienste bereits technische Möglichkeiten bieten, die eigene Datenhoheit zu wahren. In der Microsoft Azure‑Cloud werden Daten standardmässig mit vom Provider verwalteten Schlüsseln verschlüsselt. Für Branchen mit hohen Sicherheitsanforderungen – etwa Banken, Gesundheitswesen oder Regierungen – ist das aber nicht genug. Sie wollen nicht nur wissen, dass ihre Daten verschlüsselt sind, sondern auch selbst entscheiden, wer den Schlüssel besitzt.

Hier setzt das Konzept Bring Your Own Key (BYOK) an: Unternehmen bringen ihren eigenen Schlüssel mit, verwalten ihn in einem Hardware‑Sicherheitsmodul (HSM)und lassen die Azure‑Dienste damit arbeiten. Dieser Artikel erklärt, was BYOK ist, warum es vor dem Hintergrund von Datensouveränität und Compliance relevant ist und wie es in Azure umgesetzt wird. Darüber hinaus werden Hardware‑Sicherheitsmodule, der FIPS‑140‑Standard und praktische Tipps beleuchtet. Das Ziel: ein verständlicher Leitfaden, der technische Hintergründe anschaulich darstellt und Ihnen hilft, die richtige Entscheidung für Ihre Cloud‑Verschlüsselungsstrategie zu treffen.

Grundbegriffe und Kontext

Bevor wir in BYOK einsteigen, lohnt sich ein Blick auf die grundsätzlichen Bausteine der Verschlüsselung in der Cloud. Beim Speichern von Daten nutzen Azure‑Dienste einen Data Encryption Key (DEK). Dieser Schlüssel verschlüsselt Dateien, Datenbanken oder virtuelle Festplattenblöcke und wird automatisch vom Dienst generiert und verwaltet. Der DEK ist ein symmetrischer Schlüssel, was den Vorteil hat, dass die Ver- und Entschlüsselung sehr effizient abläuft und damit auch bei großen Datenmengen performant genutzt werden kann. Um den DEK wiederum vor unbefugtem Zugriff zu schützen, kann er mit einem Key Encryption Key (KEK) verschlüsselt („wrapped“) werden. Der KEK verschlüsselt also nicht direkt die Daten, sondern den Schlüssel zu den Daten - eine sogenannte Schlüsselhierarchie.

Diese Hierarchie ist entscheidend für Effizienz und Sicherheit: Der innere Schlüssel (DEK) sorgt für schnelle Datenverschlüsselung, während der äussere Schlüssel (KEK) dem Kunden die Kontrolle darüber gibt, ob der DEK verwendet werden darf. Bei BYOK ersetzt der Kunde den Azure‑eigenen KEK durch seinen eigenen, in einem HSM gesicherten Schlüssel. Azure benutzt weiterhin den von Microsoft generierten DEK, verschlüsselt ihn aber mit dem importierten Kunden‑KEK. Dadurch behalten Unternehmen die volle Kontrolle über die Entschlüsselung, ohne die Leistung der Dienste zu beeinträchtigen.

Bring Your Own Key

Bring Your Own Key (BYOK) bedeutet, dass der Kunde einen eigenen Key Encryption Key in die Cloud einbringt und damit den Dienst‑eigenen KEK ersetzt. Diese Änderung verlagert den Kontrollpunkt: Azure verschlüsselt die Daten nach wie vor mit dem von Microsoft generierten Data Encryption Key (DEK), doch der DEK wird nun mit dem Kunden‑KEK verschlüsselt.

Dieser Aufbau hat zwei wichtige Konsequenzen. Erstens kann Microsoft nur dann auf die Daten zugreifen, wenn mit dem Kunden‑KEK der DEK entschlüsselt wird; die Hoheit über die Entschlüsselung bleibt also beim Kunden. Zweitens können Unternehmen im Ernstfall den KEK löschen oder sperren und machen damit alle DEKs unbrauchbar. Diese Fähigkeit, Daten auf Knopfdruck unlesbar zu machen, ist für Branchen mit hohen Compliance‑Anforderungen wie Gesundheitswesen, Verteidigung oder Finanzwesen ein entscheidender Vorteil.

Mit BYOK verlagert sich die Verantwortung für den Schlüsselschutz vom Cloud‑Provider auf den Kunden. Mehr Kontrolle bedeutet mehr Flexibilität: Kunden bestimmen selbst, wann ein KEK erzeugt, rotiert oder gelöscht wird.

Wie funktioniert BYOK in Azure?

Die Microsoft‑Dokumentation beschreibt einen klaren Ablauf, um einen eigenen Schlüssel in Azure zu importieren. Dieser Prozess gliedert sich in vier Schritte. Zunächst wird in Azure Key Vault Premium oder im Managed HSM ein Key Exchange Key erzeugt – ein RSA‑HSM‑Schlüssel, der ausschliesslich für die Operation import vorgesehen ist. Dieser Key Exchange Key fungiert als „Umschlag“ und kann niemals exportiert werden; er bleibt vollständig im HSM.

Im zweiten Schritt lädt man den öffentlichen Teil dieses Key Exchange Keys herunter. Diese Datei ist harmlos, da sie keinen privaten Schlüssel enthält und dient nur dazu, den Kundenschlüssel zu verpacken.

Der dritte Schritt findet ausserhalb der Azure‑Cloud statt: Auf einem Offline‑Rechner mit Zugang zum eigenen HSM wird der eigentliche Kundenschlüssel erzeugt. Mithilfe des vom HSM‑Hersteller bereitgestellten BYOK‑Tools wird der Kundenschlüssel mit dem öffentlichen Key Exchange Key verschlüsselt und in eine BYOK‑Datei verpackt. Der Klartextschlüssel verlässt das lokale HSM zu keinem Zeitpunkt; die BYOK‑Datei enthält ausschliesslich verschlüsseltes Schlüsselmaterial.

Abschliessend wird diese BYOK‑Datei mit dem Befehl az keyvault key import in den Key Vault oder Managed HSM hochgeladen. Im Inneren des Azure‑HSM wird die BYOK‑Datei mit dem privaten Teil des Key Exchange Key entschlüsselt und der Kundenschlüssel sicher abgespeichert. Weder während des Transfers noch im HSM selbst gibt es einen Moment, in dem der Schlüssel im Klartext ausserhalb eines Schutzbereichs vorliegt.

Durch diesen mehrstufigen Prozess bleibt der Schlüssel stets innerhalb eines hardwaregeschützten Bereichs. Nur der Kunde kann den Schlüssel neu verpacken, erneuern oder löschen; Microsoft hat technisch keine Möglichkeit, auf das Schlüsselmaterial zuzugreifen.

DEK und KEK: Effiziente Rotation und Datenschutz

Der Einsatz eines Key Encryption Key über dem Data Encryption Key ist nicht nur ein Sicherheitsmerkmal, sondern auch eine Frage der Effizienz. In Azure wird der DEK weiterhin vom Dienst selbst erzeugt und zum Verschlüsseln der Daten verwendet. Ein Prozess, der hochoptimiert ist und sich eng in die Speichersysteme integriert.

Diese Trennung hat einen entscheidenden Vorteil bei der Schlüsselrotation: Sollte der KEK ausgetauscht werden müssen, reicht es, den DEK mit dem neuen KEK zu entschlüsseln und sofort wieder zu verschlüsseln. Die Daten, die vom DEK verschlüsselt wurden, bleiben davon unberührt. Es müssen also keine Terabytes an Daten erneut durch den Verschlüsselungsprozess laufen, sondern lediglich der vergleichsweise kleine Schlüsselblock. Dadurch können Schlüsselrotationen regelmässig durchgeführt werden, ohne dass langwierige Re‑Encryptions den Betrieb beeinflussen. Gleichzeitig bleibt der DEK zu jedem Zeitpunkt verschlüsselt. Es gibt keinen Moment, in dem Daten ungeschützt vorliegen.

Hardware‑Sicherheitsmodule (HSM) und FIPS140

Ein Hardware‑Sicherheitsmodul ist ein spezialisiertes Gerät zur sicheren Erzeugung, Speicherung und Nutzung kryptographischer Schlüssel. Es bietet einen physisch manipulierungssicheren Bereich, in dem Schlüsselmaterial geschützt bleibt. HSMs werden für sensible Operationen wie digitale Signaturen, Verschlüsselung von Finanztransaktionen oder die Verwaltung von Root‑Zertifikaten eingesetzt.

FIPS 140 und seine Sicherheitsstufen

Der Federal Information Processing Standard (FIPS) 140 ist ein US‑amerikanischer Standard, der Mindestanforderungen an kryptographische Module definiert. Die Prüfung erfolgt durch das Cryptographic Module Validation Program (CMVP). Es gibt vier Sicherheitsstufen:

• Level 1: Minimale Anforderungen; die Hardware muss „produktionsreif“ sein.
• Level 2: Zusätzlich physische Manipulationssicherheit (z. B. tamper‑evident Siegel) und rollenbasierte Authentifizierung.
• Level 3: Erfordert Manipulationsresistenz. Das Gerät muss den Zugriff auf Schlüssel bei physischen Angriffen erschweren, sowie identitätsbasierte Authentifizierung.
• Level 4: Höchster Schutz gegen physische Eingriffe und Umgebungsangriffe.

Viele Cloud‑Provider verwenden FIPS‑140 zertifizierte HSMs, um ein geprüftes Sicherheitsniveau zu garantieren.

HSM‑Optionen in Azure

Azure stellt mehrere HSM‑basierte Dienste bereit und verwendet dafür Hardware von Thales oder Marvell. Wichtig ist dabei, dass Microsoft die Hardware nicht selbst entwickelt; stattdessen kommen zertifizierte HSM‑Module etablierter Hersteller zum Einsatz. Je nach Dienst variiert die Hardware und das Sicherheitsniveau:

Key Vault Premium

Laut Microsoft verwendet KeyVault im Backend eine Mischung aus Thales und Marvell HSM‑Karten; beide sind mindestens FIPS140‑3 Level 3 validiert.
Die HSMs sind in Azure‑Rechenzentren integriert. Kunden verwalten Keys über KeyVault APIs. Microsoft hat keinen Zugriff auf die Schlüsselmaterialien, da sie im HSM verbleiben.

Key Vault Managed HSM

Nutzt Marvell LiquidSecurity Adapter mit FIPS 140‑3 Level 3 Zertifizierung.
Bietet API‑Kompatibilität zu KeyVault, aber der Service ist eigenständig. KEKs und Zielschlüssel werden in diesem HSM generiert oder importiert; der KEK ist nicht exportierbar.

Azure Dedicated HSM

Bereitgestellt als physische Thales Luna 7 HSM‑Appliance (Modell A790) im Kunden‑VNET. Diese Geräte sind nach FIPS 140-2 Level 3 sowie weiteren Standards wie HIPAA, PCI-DSS und eIDAS validiert.
Die HSMs werden direkt im privaten IP‑Raum des Kunden bereitgestellt. Microsoft hat keinen Zugriff auf die kryptografische Funktionalität; der Kunde hat volle administrative Kontrolle.

Sicherheitsaspekte und mögliche Schwachstellen

BYOK mit HSM hebt die Datensouveränität deutlich, doch ein sicheres System entsteht nur durch sorgfältige Umsetzung. Die verschlüsselte Übertragung und Speicherung der Schlüssel schützt sie vor technischen Angriffen, aber Fehleinstellungen können die Sicherheit unterlaufen. Insbesondere die Vergabe von Zugriffsrechten auf den Key Vault oder das HSM muss restriktiv erfolgen; zu weit gefasste Berechtigungen erhöhen das Risiko von Insider‑Angriffen. Zudem ist das Schlüsselmanagement ein Single Point of Failure: Geht der KEK verloren oder wird er versehentlich gelöscht, sind die Daten dauerhaft unlesbar. Eine geeignete Backup‑Strategie ist daher unverzichtbar. Auch die Einhaltung von Compliance‑Vorgaben verlangt regelmässige Audits und nachvollziehbare Prozesse für die Schlüsselrotation.

Praxistipps für die Implementierung

Für einen reibungslosen Einsatz von BYOK sind einige organisatorische und technische Vorkehrungen unerlässlich. Achten Sie darauf, Soft‑Delete und Purge‑Protection zu aktivieren. Key Vaults ohne Soft‑Delete könnten andernfalls einen KEK unwiederbringlich verlieren, wenn ein Angreifer den Schlüssel löscht; mit aktiviertem Soft‑Delete bleibt der Schlüssel hingegen mindestens 90 Tage zur Wiederherstellung im Tresor.

Wählen Sie den Schlüsseltyp und die Schlüssellänge passend zum verwendeten Dienst. Einige Azure‑Services akzeptieren nur bestimmte Längen (beispielsweise 2048‑ oder 3072‑Bit‑RSA‑Schlüssel für Azure SQL).

Definieren Sie die Zugriffsrechte im Key Vault granular. Ein Dienst benötigt in der Regel nur die Operationen Get, Wrap und Unwrap, um den DEK mit dem KEK zu verschlüsseln und zu entschlüsseln. Vermeiden Sie es, breitere Berechtigungen zu vergeben, als nötig sind.

Schliesslich sollten Sie eine Schlüsselrotation planen. Obwohl Sie die Kontrolle über den KEK behalten, muss dieser regelmässig gewechselt werden, um kryptographische Schwachstellen zu vermeiden. Viele HSM‑Hersteller bieten automatisierte Prozesse oder APIs, die die Rotation erleichtern, ohne dass Daten neu verschlüsselt werden müssen.

Fazit

Bring Your Own Key ist kein Allheilmittel, aber ein wirkungsvolles Werkzeug, um die Datensouveränität in der Cloud zu erhöhen. Indem Unternehmen ihre eigenen Schlüssel in Azure nutzen, behalten sie die Kontrolle über die Entschlüsselung ihrer Daten und können im Ernstfall sofort reagieren. Durch den Einsatz von FIPS‑140‑validierten Hardware‑Sicherheitsmodulen werden die Schlüssel nicht nur logisch, sondern auch physisch geschützt. Zudem beruhigt die Tatsache, dass Azure auf zertifizierte HSMs renommierter Hersteller wie Thales oder Marvell setzt und der Provider keine technischen Zugriffsmöglichkeiten besitzt.

BYOK erfordert sorgfältige Planung und ein gutes Schlüsselmanagement. Doch in Zeiten zunehmender Datenschutz‑Regulierungen und gezielter Angriffe bietet es eine selten genutzte Chance, die Kontrolle über die eigenen Daten in der Cloud zurückzuerlangen.