Datenverschlüsselung in der Cloud - BYOK, BYOE, HYOK und Tokenisierung

Datenverschlüsselung in der Cloud

BYOK, BYOE, HYOK und Tokenisierung

Tomaso Vasella
von Tomaso Vasella
am 05. November 2020
Lesezeit: 15 Minuten

Keypoints

So funktioniert Verschlüsselung in der Cloud

  • Der Europäische Gerichtshof hat den Privacy Shield mit sofortiger Wirkung aufgehoben (Schrems II)
  • Das Grundproblem unerwünschter Datenzugriffe kann nicht durch Verträge alleine gelöst werden
  • Zugriffsschutz mittels Datenverschlüsselung ist eine grundlegende technische Massnahme
  • Es ist wichtig, Begriffe wie Bring Your Own Key (BYOK), Double Key Encryption und Tokenisierung zu kennen und ihre Bedeutung zu verstehen
  • Die Umsetzung muss die individuellen Bedürfnisse berücksichtigen

Europa hat eine lange Tradition des Datenschutzes: Die Datenschutzrichtlinie war 1995 erlassen worden und mehr als 20 Jahre in Kraft, bevor sie durch die Datenschutz-Grundverordnung (DSGVO, engl. GDPR) abgelöst wurde. Ein regionaler Datenschutz kann aber nicht zulassen, dass Personendaten schrankenlos in Gebiete mit schwächerem Schutz fliessen. Die DSGVO erlaubt Übermittlungen in Länder ohne angemessenen Schutz nur unter Auflagen, das heisst, der Datenexporteur muss geeignete Vorkehrungen treffen.

Die EU und die USA hatten deshalb ein Abkommen getroffen: Datenimporteure in den USA konnten sich nach den Vorgaben des Safe Harbor-Abkommens zertifizieren und galten dann als sichere Empfänger. Durch ein Urteil des Europäischen Gerichtshofs wurde dieses aber aufgehoben, auf Klage von Max Schrems hin, eines österreichischen Datenschutz-Aktivisten (“Schrems I”-Urteil). Die EU und die USA ersetzten es durch ein verbessertes Abkommen, den Privacy Shield. Die Schweiz ist jeweils nachgezogen, weshalb es auch einen CH-US-Privacy-Shield gab, der Übermittlungen aus der Schweiz an zertifizierte Empfänger in den USA erlaubte.

Der Europäische Gerichtshof hat den Privacy Shield mit seinem Urteil im Juli 2020 mit sofortiger Wirkung aufgehoben (“Schrems II”-Urteil). Er kam zum Schluss, das US-Recht erlaube zu weitgehende Zugriffe auf Daten mit zu schwachem Rechtsschutz.

Als Alternative zum Privacy Shield konnten der Exporteur und der Importeur Datenübermittlungsverträge schliessen, fast immer auf Basis eines von der EU anerkannten Vertragswerks, der sogenannten Standardvertragsklauseln (oder Model Clauses). Diese Klauseln hat der Europäische Gerichtshof nicht aufgehoben. Aber er hat schwere Bedenken angemeldet, denn eine Vereinbarung mit einem US-Importeur kann den Zugriff durch Behörden nicht verhindern. Diese Bedenken betreffen auch alle anderen unsicheren Staaten und auch der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) ist der Auffassung, dass diese Klauseln nur noch in Ausnahmefällen genügen können.

Es ist klar, dass das Grundproblem unerwünschter Datenzugriffe nicht durch Verträge alleine gelöst werden kann. Im Fokus stehen deshalb technische Massnahmen, die solche Datenzugriffe ausschliessen oder wenigstens erschweren. Der Zugriffsschutz mittels Datenverschlüsselung ist eine der wichtigsten Massnahmen und ist weit verbreitet. Auch der EDÖB wies ausdrücklich auf BYOK (Bring Your Own Key) und BYOE (Bring Your Own Encryption) hin. Dieser Beitrag geht auf die gängigsten Begriffe und Massnahmen im Zusammenhang mit der Verschlüsselung von Daten in der Cloud bzw. ausserhalb der eigenen Infrastruktur ein.

Datenverschlüsselung in der Cloud

Für die nachfolgenden Abschnitte ist es nützlich, sich einige Grundlagen der Datenverschlüsselung zu vergegenwärtigen. Vereinfacht gesagt ist im vorliegenden Zusammenhang das Ziel der Datenverschlüsselung, die Daten vor unautorisiertem Zugriff zu schützen. Erreicht wird dies durch Umwandlung der Daten in eine unleserliche Form, so dass diese unleserliche Form nur von vordefinierten Parteien gelesen, beziehungsweise in die lesbare Form umgewandelt werden kann. Die Sprache der Kryptographie verwendet dafür folgende Begriffe:

Bezeichnung Begriff Beschreibung
Daten Klartext, Cleartext, Plaintext Bezeichnung für Daten in ihrer ursprünglichen, lesbaren Form. Der Begriff steht für jegliche unverschlüsselten Daten, nicht nur für Text.
Umwandlung der Daten Verschlüsselung, Encryption Verschlüsselung mit einem Algorithmus unter Verwendung eines Schlüssels. Es gibt symmetrische Algorithmen, die denselben Schlüssel für die Ver- und Entschlüsselung verwenden und asymmetrische Algorithmen, die dafür ein Schlüsselpaar verwenden. Die verschlüsselten Daten, also das Ergebnis des Verschlüsselungsvorgangs, werden Ciphertext genannt.
Umwandlung in lesbare Form Entschlüsselung, Decryption Entschlüsselung des Ciphertexts mit einem Algorithmus unter Verwendung eines geheimen Schlüssels. Unter der Annahme, dass der verwendete Algorithmus keine ausnutzbaren Schwächen besitzt, kann der Ciphertext ohne Kenntnis des Schlüssels nicht entschlüsselt werden.

Daten können an einem Ort abgelegt sein (ruhende Daten, Data at Rest), sich in Verarbeitung befinden (Data in Use) oder sie können transportiert werden (Daten in Bewegung, Data in Motion). Letzteres erfordert natürlich ebenfalls angemessenen Schutz, z.B. in Form von Transportverschlüsselung. Im Weiteren wird nicht weiter auf die Transportverschlüsselung eingegangen, da sich entsprechende Massnahmen wie die Verwendung von TLS oder von VPNs auch unabhängig von der Cloud gut etabliert haben.

Dass die Daten nur durch vorgesehene Parteien gelesen werden können wird erreicht, indem der zur Entschlüsselung nötige Schlüssel nur den berechtigten Parteien zugänglich gemacht wird. Die Verwaltung und der Schutz der kryptografischen Schlüssel sind deshalb äusserst wichtig. Nur schon diese kurze Betrachtung lässt erahnen, dass damit einige praktische Schwierigkeiten verbunden sind:

Neben den Herausforderungen der Schlüsselverwaltung sind noch folgende Tatsachen für die weiteren Betrachtungen wichtig:

Hardware-Sicherheitsmodul (Hardware Security Module, HSM)

Kryptografische Prozesse werden häufig in Software ausgeführt, also innerhalb einer Anwendung oder in einem Betriebssystem. Damit kann keine vollständige Isolation dieser Vorgänge von anderen Prozessen auf demselben System erreicht werden. Ein Systemadministrator kann auf den Speicher zugreifen und den kryptografischen Prozess beeinflussen oder die Daten oder den verwendeten Schlüssel lesen. Um diese Angriffsfläche zu verkleinern, können Hardware-Sicherheitsmodule verwendet werden.

Ein HSM ist ein spezialisiertes Hardwaregerät für kryptographische Anwendungen. Eine Applikation kann über eine Schnittstelle mit dem HSM kommunizieren und so dessen kryptographische Funktionen verwenden. Hauptsächlich sind dies die sichere Erzeugung und Verwaltung kryptografischer Schlüssel sowie alle Vorgänge, bei denen diese Schlüssel verwendet werden. Wesentlich ist hierbei, dass die geheimen Schlüssel im HSM erzeugt werden und dieses niemals verlassen. HSMs verfügen deshalb über entsprechende Schutzvorkehrungen.

Verschiedene Cloud-Anbieter ermöglichen ihren Kunden die Verwendung von HSMs. Dabei wird das HSM selbst durch den Cloud-Anbieter verwaltet; der Kunde kann aber dessen Funktionalitäten verwenden und so beispielsweise ein HSM-basiertes Schlüsselmanagement in der Cloud realisieren. Verlässt man sich auf die Schutzwirkung eines HSM muss man sich auch darauf verlassen können, dass die geschützten Schlüssel tatsächlich nie das HSM verlassen. Es ist deshalb ratsam, für jede Anwendung genau zu prüfen, wie die Schlüssel erzeugt, verwaltet und verwendet werden.

Bring Your Own Key (BYOK)

Der Begriff BYOK bezeichnet ein Modell, bei dem der Kunde bzw. der Dateninhaber seine eigenen kryptografischen Schlüssel erzeugt und verwendet und möglichst auch alleinigen Zugriff darauf hat. Das Modell BYOK weist allerdings Schwachstellen und praktische Herausforderungen auf, über die sich der Anwender im Klaren sein muss:

Bring Your Own Encryption (BYOE)

Ein reines BYOK-Modell erlaubt zwar Kontrolle über die Schlüssel, nicht aber über die eingesetzten Algorithmen. Das Modell der eigenen Verschlüsselung (BYOE) unterscheidet sich davon durch die zusätzliche Möglichkeit, auch die verwendeten kryptografischen Algorithmen selbst zu verwalten. Es gibt ebenfalls Lösungen, in denen auch noch die kryptografischen Funktionalitäten selbst eingebracht werden können. Aus Sicherheitssicht spielen diese zusätzlichen Kontrollmöglichkeiten aber nur eine unwesentliche Rolle und die obigen Punkte treffen grösstenteils auch bei einem BYOE-Modell zu.

Hold Your Own Key (HYOK)

Auch die Anbieter von Cloud-Diensten sind sich der obigen Schwächen bewusst und haben noch weiter gehende Modelle entwickelt. Eines davon nennt sich Hold Your Own Key (HYOK) und bezeichnet ein Verfahren, bei dem die Daten bereits vor dem Eintritt in die Cloud verschlüsselt werden. Dementsprechend wird das eigene Schlüsselmaterial nicht zur Cloud übertragen.

Das Ziel dieses Modells besteht darin zu verhindern, dass die Daten jemals im Klartext in die Cloud gelangen. Eine saubere Umsetzung vorausgesetzt, ist dies unbestritten ein sicheres Vorgehen zur Verhinderung ungewollter Datenzugriffe, bedeutet aber gravierende Einbussen bei der Funktionalität. Weil für den Cloudanbieter die Dateninhalte komplett unzugänglich sind (sogenannte Undurchsichtigkeit der Daten oder Data Opacity), funktionieren die meisten Anwendungen nur teilweise oder gar nicht. Aus diesem Grund wird dieses Verfahren nur für wenige, ausgewählte Datenbereiche angewendet, beispielsweise für einzelne Dokumente oder für sensitive Felder in einer Datenbank. Hingegen bietet es sich an, nur in der Cloud gespeicherte und nicht auch verarbeitete Daten in der Cloud schon vor dem Transfer zu verschlüsseln, wie im Fall von verschlüsselten Cloud Backups.

Double Key Encryption

Double Key Encryption ist der Begriff für ein von Microsoft angebotenes Modell, bei dem zwei verschiedene Schlüssel eingesetzt werden. Einer davon befindet sich unter der Kontrolle von Microsoft, der andere wird alleine durch den Cloudanwender kontrolliert. Aus Sicherheitssicht unterscheidet sich dieses Modell nur geringfügig vom Modell HYOK. Auch hier besteht die Herausforderung darin, dass die Cloudanwendungen die Dateninhalte nicht lesen können und deshalb nur teilweise oder gar nicht funktionieren.

Tokenisierung

Bei der Tokenisierung werden die zu schützenden Daten durch irreversible, nicht sensitive Platzhalter (Token) ersetzt. Im Unterschied zur Verschlüsselung ist die Tokenisierung kein mathematisches Verfahren. Mit der Tokenisierung kann erreicht werden, dass die ersetzten Daten dieselbe Länge und denselben Typ aufweisen wie die ursprünglichen Daten. Dies ist ein entscheidender Vorteil gegenüber der Datenverschlüsselung, weil tokenisierte Daten im Unterschied zu verschlüsselten Daten von Cloudanwendungen verarbeitet werden können. Diesem Vorteil stehen aber auch Nachteile gegenüber. Die Tokenisierung kann zwar recht gut für strukturierte Datenfelder wie beispielsweise Kreditkartennummern verwendet werden, eignet sich aber schlecht für unstrukturierte Daten wie beispielsweise ganze Dokumente.

Für die Umwandlung der Daten zu Token und umgekehrt wird im Unterschied zur Verschlüsselung kein mathematischer Algorithmus mit einem Schlüssel verwendet, sondern eine Zuordnungstabelle. Diese Zuordnungstabellen (Token Vault oder Token-Datenbank) können je nach Anwendungsfalls gross werden und sich negativ auf die Performance auswirken. Token können nur durch Zugriff auf die Zuordnungstabelle in die Originaldaten zurück transformiert werden, hingegen ist bei verschlüsselten Daten nur der richtige Schlüssel zur Entschlüsselung erforderlich. Daher können tokenisierte Daten weniger gut für den Austausch mit autorisierten Parteien geeignet sein als verschlüsselte Daten.

Die Tokenisierung wird in der Regel durch den Einsatz spezieller On-Premise-Lösungen implementiert. Damit Anwendungen tokenisierte Daten korrekt verarbeiten können, muss die Tokenisierungslösung die jeweiligen Anwendungen spezifisch unterstützen.

Übersicht der Verschlüsselungsmodelle

Die folgende Tabelle fasst die Eigenschaften der beschriebenen Modelle bei korrekter Implementation zusammen.

Modell Hold You Own Key Double Key Encryption Bring Your Own Encryption Schlüsselverwaltung Cloudanbieter Tokenisierung
Daten sind durch den Cloudanbieter lesbar nein nein ja ja nein
Vollständige Cloud-Lösung nein nein ja ja nein
Eigenes HSM erforderlich ja ja ja* nein n.a.

* Die Schlüssel könnten auch ohne eigenes HSM erzeugt und anschliessend in die Cloud transferiert werden, dies würde aber deren Geheimhaltung stark beeinträchtigen.

Fazit

Bei korrekter Verwendung können alle beschriebenen Modelle zur Steigerung des Schutzes von Daten in der Cloud beitragen. Sie bieten aber keinen hundertprozentigen Schutz vor Zugriffen durch Dritte und können zu massiven Einbussen bei der Funktionalität der Cloudanwendungen führen. Es ist deshalb nötig, die Bedrohungsszenarien und die Akteure, vor denen man sich schützen will genau zu analysieren und auf dieser Grundlage das geeignetste Modell zu wählen. Beispielsweise kann ein Bring Your Own Key Szenario zuverlässig vor unautorisierten Datenzugriffen auf gespeicherte Daten schützen, Zugriffe durch den Cloudanbieter können damit aber nicht verhindert werden. Der umfassende Schutz von Daten erfordert praktisch immer eine Kombination verschiedener Massnahmen und muss sich über den gesamten Lebenszyklus der Daten erstrecken.

Abgesehen von bestimmten spezifischen Szenarien wie Datenablage in der Cloud sind der Einsatz von Cloudanwendungen und der vollständige Schutz der Daten vor Zugriffen durch Dritte zwei nicht gänzlich vereinbare Ziele. Deshalb sollte den Marketingversprechungen kein blindes Vertrauen geschenkt werden. Stattdessen braucht es einen risikobasierten Ansatz mit einem bewusst gewählten Gleichgewicht zwischen Funktionalität und Schutz der Daten.

Über den Autor

Tomaso Vasella

Tomaso Vasella hat seinen Master in Organic Chemistry an der ETH Zürich abgeschlossen und ist seit 1999 im Bereich Cybersecurity aktiv. Positionen als Berater, Engineer, Auditor und Business Developer zählen zu seinen Erfahrungen. (ORCID 0000-0002-0216-1268)

Links

Herausforderung Datenschutz-Grundverordnung DSGVO?

Unsere Spezialisten kontaktieren Sie gern!

×
Offerten erstellen

Offerten erstellen

Tomaso Vasella

Microsoft Teams Security

Microsoft Teams Security

Tomaso Vasella

Schweregrade und Risiken

Schweregrade und Risiken

Tomaso Vasella

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv