Datenschutzkonforme SaaS-Nutzung

Verschleierte Daten

30. November 2015, 7:00 Uhr | Oliver Keizers/wg, Regional Business Director bei Blue Coat Systems, www.bluecoat.com,

Das Safe-Harbor-Urteil des Europäischen Gerichtshofs hat einige Wellen geschlagen - je nach Interpretation aber an der Sachlage für Unternehmen wenig verändert. Diese waren auch zuvor gefordert, den Schutz sensitiver Daten beim Cloud-Einsatz zu garantieren, konnten sich juristisch jedoch mit dem Safe-Harbor-Abkommen relativ sicher wähnen. Nun gilt es, Mittel und Wege zu finden, Cloud-Services weiter nutzen zu können.

Dass die Übermittlung und Verarbeitung kritischer und personenbezogener Daten in der Cloud der Gefahr eines unberechtigten Zugriffs unterliegt, ist hinreichend kommuniziert. Entsprechend haben sich nationale, internationale und branchenspezifische Institutionen daran gemacht, Richtlinien zu entwickeln und vorzuschreiben. Das Bekanntwerden der Zugriffe auch staatlicher Stellen auf private und Unternehmensdaten hat aus der Thematik ein Politikum werden lassen. Nicht nur in Deutschland und Europa, sondern auch in Ländern wie etwa Russland oder Kanada verlangen Gesetzgeber die strikte Einhaltung des Datenschutzes oder geben Residenzpflichten für Daten vor. Der Wegfall von Safe Harbor hat einem bekannten Problem nun neue Dynamik gegeben.
Unternehmen stehen seither vor einem Dilemma: Auf der einen Seite verspricht die Nutzung von Cloud-Anwendungen ein hohes Maß an Flexibilität und Effizienz, verbunden mit geringeren Investitions- und Betriebskosten, auf der anderen Seite schränken die damit verbundenen Maßnahmen und Unsicherheiten den Enthusiasmus deutlich ein. Software as a Service (SaaS), wie dies zum Beispiel Salesforce oder Servicenow bieten, verliert an Attraktivität, wenn die Schutzanforderungen nicht zu erfüllen sind. Manche Analysten halten die Fragen des Datenschutzes für den Hauptgrund vieler Unternehmen, von einer Hinwendung zu SaaS Abstand zu nehmen.
 
Daten im Klartext keine Option
In Anbetracht der Residenz- und Compliance-Anforderungen besteht die Herausforderung darin, eine Balance zwischen dem Schutz sensitiver Daten und den Vorzügen der Nutzung von SaaS zu finden. Es ist offensichtliche keine Option, Daten als Klartext in die Cloud zu stellen in dem Vertrauen, dass der Provider schon die notwendigen Maßnahmen trifft. Selbst bei der Garantie der physischen Datenspeicherung an einem vermeintlich sicheren Standort ist damit noch lange nicht der Zugriff etwa durch Mitarbeiter und Administratoren des Anbieters unterbunden. Und die Feststellung des EuGHs, dass nationale Interessen etwa der USA stärker wirken als Datenschutzvereinbarungen mit der EU, hebelt dies weiter aus.
Der einzig gangbare Weg, die Cloud zu nutzen, ohne auf Compliance zu verzichten, liegt in der Verschleierung der kritischen Daten. Dazu stehen zwei Techniken zur Verfügung: erstens Verschlüsselung und zweitens Pseudonymisierung, auch Tokenisierung genannt. Beide Verfahren sind auch im BDSG hinreichend beschrieben, somit auch juristisch akzeptabel.
Obgleich Verschlüsselung ein altbewährtes Verfahren ist, um Daten dem unberechtigten Zugriff zu entziehen, so hat die praktische Anwendung in der Cloud durchaus noch Herausforderungen anderer Art, wie die Snowden-Affäre bewiesen hat. Cloud-Provider, Verschlüsselungsanbieter und Anwenderorganisationen arbeiten allerorts an geeigneten Lösungen für Umgebungen, in denen sich die Applikation, die Daten und die Schlüssel nicht an einem Ort, aber unter voller Kontrolle des Unternehmens befinden. Gesucht ist ein effizientes Verfahren, um einerseits die Klartextinformationen zu verbergen, andererseits die Funktionalität der SaaS-Anwendung zu erhalten. Hierzu haben sich unterschiedliche Ansätze herausgebildet.
Eine verbreitete Methode ist die Verschlüsselung der gesamten Datenbasis eines Anwenders. Auch wenn dieser Ansatz die Daten vor unberechtigtem Zugriff durch Dritte schützt und viele Compliance-Anforderungen erfüllt, so ist er doch suboptimal für SaaS-Anwendungen in der Public Cloud - allein schon durch die Tatsache, dass die Verschlüsselung auf Datenbankebene die Funktionalität der SaaS-Applikation einschränkt. Es ist zum Beispiel nicht ohne Weiteres möglich, verschlüsselte Werte zu suchen oder zu sortieren. Hier bieten unterschiedliche Anbieter verschiedene Lösungswege an, sodass zum Beispiel mit einem Suchindex auf einem Datenschutz-Gateway auch diese Funktionen sichergestellt sind.
Die feldspezifische Verschlüsselung bietet bei geeigneter Implementierung demgegenüber die Möglichkeit einer starken Verschlüsselung. Bei dieser Methode werden lediglich diejenigen Datenfelder verschlüsselt, die kritische Daten enthalten. Auf der anderen Seite ist weiterhin etwa die Suche nach einem verschlüsselten Wert in der Cloud nicht oder nur bedingt möglich. Um dieses Problem zu umgehen, verändern manche Hersteller die Encryption-Algorithmen, was allerdings die Stärke der Verschlüsselung beeinträchtigt.
In der Praxis gibt es derzeit keine Ideallösung für alle Anforderungen der Verschlüsselung in der Cloud. Jedes Unternehmen muss für sich die Anforderungen definieren. Dies gilt für den allgemeinen Verschlüsselungsansatz, die anzuwendende Verschlüsselungsstärke oder das Schlüssel-Handling.
Die Frage der Schlüsselkontrolle ist so lange kein Problem, wie sich alle Elemente innerhalb des eigenen Rechenzentrums befinden. Dies ändert sich, sobald die Daten in die Cloud wandern: Dem SaaS-Provider die Kontrolle über einen Schlüssel zu geben, etwa um die Suche in einer Datenbank zu ermöglichen, kann prinzipiell Gesetze oder interne Richtlinien verletzen. Aus diesem Grunde ist anzustreben, dass der Kunde jederzeit die Kontrolle über sämtliche Schlüssel behält. Allerdings liegt damit auch das Schlüssel-Management in der Verantwortung des Kundenunternehmens.
 
Ersatzwerte in die Cloud
Viele Unternehmen setzen deshalb auf Tokenisierung als Technik der Wahl, um die Komplexität in Verbindung mit dem Schlüssel-Management zu umgehen und insgesamt gar keine Daten in die Cloud auszulagern. Tokenisierung ist gegenüber der Verschlüsselung eine grundlegend andere Technik, die im Umfeld der Bezahldienste zur Erfüllung der Anforderungen des PCI-Standards entstanden ist. Während bei der Verschlüsselung prinzipiell die Klartextdaten mittels eines mathematischen Prozesses sichtbar gemacht werden können, wird bei der Tokenisierung oder Pseudonymisierung ein Ersatzwert ("Token") erzeugt und zufällig zugewiesen. Das Token ist irreversibel, es lässt in keiner Weise - weder inhaltlich oder in der Form - Rückschlüsse auf das Ursprungsdatum zu.
In der am meisten verbreiteten Form, der "Lookup-Tokenisierung", werden die erzeugten und zufällig zugewiesenen Ersatzwerte in einer hochsicheren Tabelle innerhalb des Unternehmensnetzes gespeichert. Es gibt keine mathematische Relation zwischen Klartext und Token oder zwischen Tokens untereinander. Selbst wenn ein Wert kompromittiert wurde, können Angreifer daraus keine Schlüsse auf andere Werte ziehen. Tokenisierung gilt entsprechend als stärkste Form der Verschleierung.
 
Irreversibles Token
Bei der Nutzung von SaaS-Anwendungen werden lediglich die sensitiven (zum Beispiel die personenbezogenen) Daten mittels Tokens pseudonymisiert, bevor sie in die Cloud zur Verarbeitung oder Speicherung übermittelt werden. Die echten Daten werden im "Token Vault" (einer abgesicherten Datenbank) gespeichert, der wiederum selbst verschlüsselt ist und sich im Rechenzentrum des Unternehmens befindet - oder aber bei einem anderen Cloud-Provider, der die Sicherheits- und Residenzanforderungen erfüllt. Insbesondere in Ländern mit hohen gesetzlichen Anforderungen hinsichtlich Privatsphäre und Datenresidenz ist dieser Ansatz gut geeignet, um die Vorschriften zu erfüllen.
Viele Unternehmen haben beispielsweise Datenschutz-Anforderungen, die sich aus der Residenzpflicht für Daten ergeben, so beispielsweise in Russland. Hier ist seit September 2015 ein Gesetz in Kraft, das die Anbieter verpflichtet, die Daten russischer Bürger in einer primären Datenbank in Russland zu speichern und zu verarbeiten. Dies ist durch Verschlüsselung nicht gegeben und nur durch Tokenisierung erreichbar. Hierbei wird die Token-Datenbank in Russland vorgehalten, womit die gesetzlichen Anforderungen erfüllt sind.
Es gibt jedoch keine allgemeingültige Empfehlung hinsichtlich der Frage, welche Technik der Verschleierung für das jeweilige Unternehmen am besten geeignet ist. Zudem stehen Verschlüsselung und Tokenisierung nicht notwendigerweise in Konkurrenz zueinander, sondern lassen sich im Rahmen hybrider Ansätze parallel einsetzen. Die wichtigen Kriterien für die Erarbeitung eines gangbaren Weges sind ein starker Sicherheitsstandard, die weitestgehende Erhaltung der Funktionalität, die Bereitstellung eines hohen Maßes an Flexibilität sowie der Einsatz einer technischen Plattform, die einen holistischen Ansatz ermöglicht, indem sie beide Formen der Verschleierung für multiple SaaS-Clouds ermöglicht und nicht anbietergebunden ist.
Im Hinblick auf die praktische Herangehensweise für ein Unternehmen empfiehlt sich ein dreistufiger Ansatz aus Discovery, Richtlinienerstellung und Schutz: Im ersten Schritt erfolgt die Analyse der bereits genutzten Cloud-Services, seien diese offiziell oder im Rahmen von Schatten-IT im Unternehmen vorhanden. Anschließend definiert und etabliert die IT-Organisation strikte Richtlinien für die Nutzung oder das Verbot dieser Cloud-Services. Abschließend implementiert sie bei den genehmigten Cloud-Services die geeignete Lösung für den Datenschutz.

Tokenisierung übersetzt die Klartextdaten in irreversible Zufallswerte, hier am Beispiel eines Salesforce-Interfaces gezeigt. Bild: Blue Coat

Bei der Tokenisierung verlassen die Klartextdaten das Unternehmensnetzwerk nicht. Sie sind also weder unterwegs ("in transit"), noch gespeichert ("at rest") oder während der Nutzung ("in use") angreifbar. Bild: Blue Coat
LANline.

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu b.com Computer AG

Weitere Artikel zu 2ndsoft

Matchmaker+