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:

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:

• Wer erzeugt diese Schlüssel?
• Wie werden sie auf sichere Weise den Berechtigten zugestellt, ohne dass andere sie lesen können?
• Wie kann man Schlüssel auch während ihrer Verwendung geheim halten?
• Was ist zu tun, wenn ein Schlüssel doch einmal in falsche Hände gerät oder verloren geht?

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

• Die Ver- und Entschlüsselung von Daten geschieht immer unter Verwendung eines Schlüssels. Finden diese Vorgänge in der Cloud statt, muss die entsprechende Cloudanwendung bzw. die Verschlüsselungsfunktion auf den Schlüssel zugreifen können.
• Die Verarbeitung von verschlüsselten Daten in der Cloud folgt immer dem Prinzip verschlüsselte Daten lesen → Daten entschlüsseln → Daten verarbeiten → Daten verschlüsseln und speichern. Die Daten, die verschlüsselt oder entschlüsselt werden, liegen während dieser Vorgänge im Klartext im Speicher des Systems vor, das diese Vorgänge ausführt.
• Verschlüsselte Daten können nicht inhaltlich ausgewertet werden (das ist der Zweck der Verschlüsselung), deshalb kann eine Cloudanwendung in der Regel auch keine verschlüsselten Daten verarbeiten.

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:

• Die Erzeugung von Schlüsselmaterial ausserhalb des Cloud-Anbieters erfordert einen sicheren Transport in die entsprechende Cloud-Anwendung. Verschiedene Hersteller von HSMs bieten Lösungen an, die versprechen, dass das transportierte und in der Cloud importierte Schlüsselmaterial während dieses gesamten Vorgangs stets zuverlässig geschützt ist. Dies setzt aber voraus, dass man vom Cloudanbieter unterstützte Hardware einsetzt und bedeutet zusätzlichen administrativen Aufwand.
• Die Daten befinden sich zum Zeitpunkt der Verarbeitung im Klartext im Speicher der verarbeitenden Systeme. Jemand mit Zugriff auf den Speicher kann diese Daten deshalb lesen, also insbesondere die Systemadministratoren des Cloud-Anbieters. Dies gilt auch beim Einsatz eines HSM, denn dort werden die Daten zwar verschlüsselt und entschlüsselt, die inhaltliche Verarbeitung erfolgt aber ausserhalb davon.
• Ohne den Einsatz eines HSM liegt auch der Schlüssel selbst im Speicher des Systems vor und kann ebenfalls durch Zugriff darauf ausgelesen werden.
• Auch wenn ein HSM eingesetzt wird, kann eine Anwendung dieses auf unsichere Weise verwenden, beispielsweise indem das Schlüsselmaterial nicht nur innerhalb des HSM verwendet wird.
• Der eigentliche Verschlüsselungsvorgang, sei dies mit oder ohne HSM, findet in der Cloud statt, d.h. innerhalb von Systemen, die vom Cloud-Anbieter verwaltet werden. Die Kontrolle darüber liegt deshalb beim Cloud-Anbieter, so dass dieser auch Hintertüren für den unautorisierten Datenzugriff einbauen oder seine eigenen Schlüssel verwenden könnte.

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.

* 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 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

• https://docs.microsoft.com/en-us/azure/information-protection/configure-adrms-restrictions
• https://docs.microsoft.com/en-us/microsoft-365/compliance/double-key-encryption