CLOUD Act vs. DSGVO

Verschlüsselung und Tokenisierung reichen nicht!

| Autor / Redakteur: Mark Neufurth / Peter Schmitz

Absolute Sicherheit bieten weder Verschlüsselung noch Tokenisierung. Die Kombination beider Technologien bietet dagegen schon ein akzeptables Schutzniveau.
Absolute Sicherheit bieten weder Verschlüsselung noch Tokenisierung. Die Kombination beider Technologien bietet dagegen schon ein akzeptables Schutzniveau. (Bild: gemeinfrei / Pixabay)

Der CLOUD Act stellt Unternehmen in Europa vor Herausforderungen. US-Behörden dürfen auf Daten zugreifen, die auf Servern in Europa liegen, solange sie von US-Hostern oder Cloud-Anbietern bzw. deren ausländischen Ablegern verarbeitet oder gespeichert wurden. US-Anbieter empfehlen daher, Daten technisch zu verschleiern. Doch schützt das die Daten vor dem Zugriff?

Neben den Anbietern selbst, weist auch die Datenschutz-Grundverordnung in Art. 32 darauf hin, personenbezogene Daten entweder zu verschlüsseln oder zu pseudonymisieren. Beide Möglichkeiten stellen für Daten in der Cloud eine Herausforderung dar.

Verschlüsselung: Wo liegt der Schlüssel?

Bei einer Ver- bzw. Entschlüsselung muss immer ein Schlüssel bereitgehalten werden, der geheim gehalten werden sollte. Stellt sich die Frage: Wie kann ein solcher Schlüssel sicher in die Cloud übertragen bzw. sicher verwaltet werden? Hier konkurrieren zwei Ansätze.

Faktencheck zum CLOUD Act

Grundsatz der Verhältnismäßigkeit

Faktencheck zum CLOUD Act

22.07.19 - Zum Thema CLOUD Act gibt es unterschiedliche Ansichten und Auslegungen: die einen warnen eindringlich vor der möglichen Kollision mit regionalen Gesetzgebungen wie GDPR und DSGVO, die anderen winken ab und sagen, alles alter Hut: international übergreifende Kooperationen der Exekutive, teils auch der Legislative gibt es schon seit Jahrzehnten, wurden jetzt nur upgedatet, auf neue Technologien angepasst und somit auf den aktuellen Stand gebracht. Ja, was stimmt denn nun? lesen

Bring Your Own Key: Hinter dem Begriff Bring Your Own Key (BYOK) steht das Konzept, dass der Kunde Daten auf der Plattform eines Cloud-Anbieters verschlüsselt ablegt und selbst den Schlüssel dazu erzeugt. Im Idealfall kann nur der Kunde selbst auf den Schlüssel zugreifen. Eine reine BYOK-Lösung weist jedoch Schwachstellen auf, denn der Cloud-Provider verfügt über die eingesetzte Verschlüsselungssoftware und damit über die Möglichkeit, sich selbst einen Masterkey zu generieren. Damit kann er verschlüsselte Daten entschlüsseln. Möglicherweise muss er sogar Behörden des Landes, in dem er seinen Sitz hat, Einblick in den Verschlüsselungscode gewähren.

Der CLOUD Act schreibt Cloud-Providern nicht explizit vor, Daten entschlüsseln zu müssen, verbietet es jedoch auch nicht ausdrücklich. Ansonsten würde der Schutzzweck dieser Norm – nämlich an bestimmte Daten zu gelangen – wirkungslos. Wirkt der Provider bei der Entschlüsselung mit, so verstößt er nicht gegen den CLOUD Act.

Der Cloud-Anbieter verfügt zudem über die zum Speichern eingesetzte Server-Hardware. Sobald Daten in der Cloud entschlüsselt werden, müssen sowohl Schlüssel als auch die zu verarbeitenden Daten zwangsläufig in den Arbeitsspeicher des Servers übertragen werden. Jeder, der Zugriff auf den Server, die Virtualisierung oder das Betriebssystem hat, kann den Arbeitsspeicher kopieren und entschlüsselte Daten auslesen bzw. den Schlüssel herausfischen.

Bring Your Own Encryption: Einen Schritt weiter geht Bring Your Own Encryption (BYOE). Hier generiert der Kunde nicht nur den Schlüssel. Zusätzlich besorgt er sich selbst einen passenden Kryptoalgorithmus und verwaltet diesen auch. Die Verschlüsselung obliegt hier nicht mehr dem Cloud-Anbieter. Kommerzielle Lösungen zur Verschlüsselung haben jedoch einen Pferdefuß: Ihr Source Code wird in der Regel nicht offenbart. Niemand weiß, ob nicht Hintertüren in diesen kommerziellen Lösungen eingebaut sind – sogenannte Backdoors.

Verwendet man Open Source zur Verschlüsselung, so finden Kunden zumindest meist sauberen Code vor. Allerdings lässt sich feststellen, dass Open Source-Tools zur Encryption meist nur Einzelplatzlösungen bieten. Sie lassen keine Gruppen oder Verwaltung unterschiedlicher Schlüssel zu. Zudem sind sie oft nicht so einfach und integriert anzuwenden, wie es die DSGVO für ‘Privacy-by-Design’ vorschreibt.

Fazit: In der Praxis gibt es derzeit keine Ideallösung für alle Anforderungen der Verschlüsselung in der Cloud. Hinzu kommt, dass einige Regulatoren Verschlüsselung in der Cloud als nicht akzeptabel einstufen, da sie grundsätzlich mathematisch reversibel ist und in der Cloud Datenstrecken abgehört werden können.

Tokenisierung: Tokenisierung ist verglichen mit Verschlüsselung ein grundlegend anderer Pseudonymisierungsansatz. Hier werden den Originalwerten per Zufall pseudonymisierte Werte zugeordnet und somit nur diese verfremdeten Daten statt des Originals in die Cloud übertragen. So fällt die primäre Gefahr der Entschlüsselung erst einmal geringer aus, zumal es keinen mathematischen Zusammenhang zwischen Original- und Verschlüsselungswert gibt. Die eigentlichen Daten sowie die Übersetzungstabelle lagern dann in der Regel im physischen Herrschaftsbereich des Unternehmens mit Verschleierungsbedarf.

Auf den zweiten Blick wird dieses Vorgehen jedoch zum Pferdefuß. Ohne Übersetzungstabelle, oft Look-up Vault genannt, kann aus Tokens niemals mehr eine Zuordnung von pseudonymisierten und originalen Daten abgeleitet werden. Wer also diese Übersetzungstabelle kapert, kann die Zuordnung verfälschen bzw. dort dann selbst Daten verknüpfen.

Eine Verschlüsselung dieser Übersetzungstabelle erhöht deren relative Sicherheit. Spätestens dann jedoch leiden Geschwindigkeit und Komfort der Datenverarbeitung. SaaS- oder IoT-Anwendungen können auf diese Weise kaum betrieben werden. Und egal ob verschlüsselt oder per Token verschleiert: Metadaten, die um die Datenverarbeitung herum entstehen, sind immer auslesbar.

Abgeschirmt: Cloud Access Security Broker (CASB)

Sicherheit in der Multi-Cloud-Ära

Abgeschirmt: Cloud Access Security Broker (CASB)

19.11.18 - Konventionelle Cloud-Access-Security-Lösungen stoßen schnell an ihre Grenzen in Multi-Cloud-Umgebungen. Cloud Access Security Broker können Abhilfe schaffen. lesen

Lösung: Der richtige Cloud-Anbieter

Absolute Sicherheit bieten weder Verschlüsselung noch Tokenisierung. Die Kombination beider Technologien, also das richtige Schlüssel-Handling gepaart mit Token-Einsatz bietet schon ein akzeptables Schutzniveau. Eine Voraussetzung muss hier jedoch auch gegeben sein: Der Kunde sollte einen Hosting- oder Cloud-Dienstleister wählen, der nicht gesetzlich gezwungen werden kann, pseudonymisierte Daten lesbar zu machen. Der US-CLOUD Act untersagt es US-Cloud-Anbietern beispielsweise nicht, Daten zu entschlüsseln – in welchem Auftrag auch immer. Dass sich US-Behörden nicht scheuen, ausländische Soft- und Hardware auszusperren, zeigt übrigens der aktuelle Fall Huawei. Deutsche und europäische Provider wie 1&1 IONOS müssen hier merklich mehr im Sinne des Kunden handeln. Und die DSGVO zwingt hier als alleinige rechtliche Regelung alle datenverarbeitenden Unternehmen zu größtmöglicher Sorgfalt im Interesse des Kunden.

Über den Autor: Mark Neufurth ist Senior Strategy Manager bei 1&1 IONOS. Mark Neufurth begann seine berufliche Laufbahn bei 1&1 Internet. Als Assistent des CEO führte er Marktanalysen durch, entwickelte Geschäftsstrategien und bereitete M&As mit vor. Danach betreute er als Produktmanager Internetzugangs- sowie Hostingprodukte wie 1&1 My Website und 1&1 Do-it-yourself. Seit 2012 konzentriert er sich auf den Cloud B2B-Markt und erstellt Marktanalysen für das Enterprise Cloud Geschäft von 1&1 IONOS.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46034908 / Compliance und Datenschutz )