Pseudonymisierung von sensiblen Daten in der Cloud – Privacy by Design

Dass die Public Cloud viele Vorzüge hat, wird längst nicht mehr in Frage gestellt. Gerade in Bereichen mit sensiblen Daten kann aber ein flaues Bauchgefühl mitschwingen, wenn die Datenschätze die hermetisch abgesteckten Netzwerk-Grenzen aus der angestammten On-Premises-Welt in Richtung Cloud verlassen. Man stellt sich Fragen wie:

• Wer hat wo Zugriff auf welche sensiblen Daten in der Cloud?
• Welche Informationen könnten ausgelesen und in welchem Umfang missbraucht werden, falls sich jemand Zugriff auf die Daten in der Cloud verschafft?

.

In diesem Artikel werde ich nicht nur diese Fragen beantworten, sondern auch aufzeigen, dank welcher Verfahren diese Bedenken beseitigt werden können. Doch nun erst mal der Reihe nach. Für ein einfaches Verständnis stellen wir uns die folgende Analogie vor:

Ich bin ein Schafhirte (Verantwortlich), der Wolle (Produkt) produziert. Ich weiss, die beste Wolle (Mehrwert) gibt es, wenn ich die Herde Schafe (Daten) aus dem Dorf (On Prem) auf die Alp (Cloud) bringe, weil da die Wiesen saftig und grün sind (As a Service) und rasch nachwachsen (Skalierung, Kosten). Doch mir ist bewusst: Unterwegs (Data in Motion) und vor Ort im grossen Gehege (Big Data, Data at Rest) haben es Wölfe (Hacker) auf meine Schafe abgesehen. Wie kann ich meine Schafe unterwegs und vor Ort schützen? Richtig: mit einem Jäger (Sicherheitsexperte). Doch dieser ist auch nicht rund um die Uhr wach und immer 100% treffsicher. Ich habe da eine Idee: Wir färben die Wolle unserer Schafe grün wie Heidelbeerbüsche ein, sodass sie für die Wildtiere uninteressant werden (Anonymisierung), sie aber trotzdem von der saftigen Weide profitieren können, und ich meine Wollproduktion sicher steigern kann. Nun gibt es aber spezielle Schafe, welche Merinowolle produzieren. Da diese Merinowolle durch meine transparente Lieferkette für meine Kund*innen bis auf das Schaf zurückverfolgar sein muss, werde ich den Schafen jeweils einmalige Rufnamen geben, auf welche nur sie hören (Pseudonymisierung) und die Wölfe nicht verstehen. Die Liste der Namen für die Aufschlüsselung zuhanden der Kunden habe ich sicher im Stall hinterlegt (Key Vault), wo die Wölfe keinen Zugriff haben.

Diese Analogie zeigt verschiedene Use Cases mit Bezug auf den Datenschutz auf, welche je nach Szenario konzeptionell unterschieden werden müssen. In der nachfolgenden Grafik wird am Beispiel der Gesundheitsbranche der Unterschied zwischen Pseudonymisierung und Anonymisierung nochmals verdeutlicht:

 

Personenbezogene Daten

Üblicherweise sind viele Daten in operativen Systemen personenbezogene Daten. Für einen reibungslosen und effizienten Prozessablauf müssen den berechtigten Personen die benötigten Informationen ungehindert zur Verfügung stehen ("Need to Know"-Prinzip). Beispielsweise muss ein Arzt in der Patientendokumentation bei der Schichtübergabe alle benötigten Informationen zum Zustand und der Entwicklung der Patienten während der letzten Schicht einsehen können.

Anonymisierte Daten

Wenn diese Daten nun beispielsweise für analytische Zwecke aus den operativen Kernsystemen in die Cloud exportiert werden, sind sie noch personenbezogen und müssen geschützt werden. Die mit den Daten arbeitenden Data Engineers oder Data Scientists benötigen für ihre Arbeit je nach Anwendungsfall gar keine personenidentifizierenden Informationen. Sie haben den Fokus auf den Algorithmen und Datenrelationen und versuchen damit neue Erkenntnissen zu generieren. Hier kommen Anonymisierung und Pseudonymisierung ins Spiel. Wenn die personen-identifizierenden Daten beim Verlassen der operativen Systeme verschleiert werden, kann risikoreduzierter damit gearbeitet werden, die Fragen nach einem möglichen Missbrauch und Angriffsvektoren reduzieren sich auf die üblichen Sicherheitsmassnahmen. Im Falle einer Anonymisierung werden sämtliche identifizierenden Daten (oder ihre Kombination) in den Datensätzen unkenntlich gemacht oder entfernt. Trotzdem lassen sich mit den Nutzdaten (dh. Datensatz ohne personenidentifizerende Daten) der Datensätze nach wie vor beispielsweise übergreifende Trendanalysen erstellen.

Anwendungsfälle für das Arbeiten mit anonymisierten Daten in der Cloud sind neben dem Gesundheitswesen etwa auch:

• Mustererkennung
• Trenderkennung
• Anomalieerkennung
• Datenmarktplatz (Intern, B2B)
• Statistische Analysen
  
  

Pseudonymisierte Daten

Je nach Use Case ist es allerdings nötig, dass Daten bei der Übertragung und bei der Speicherung zwar geschützt sind, diese aber für individuelle Analysen aufgrund unterschiedlicher Ausgangslagen zwingend wieder aufschlüsselbar sein müssen, damit sich beispielsweise ein Arzt sicher sein kann, dass die mit Hilfe von KI um neue Erkenntnisse angereicherten Daten auch tatsächlich zu Patient X gehören und nicht einfach zu irgendeinem beliebigen Patienten. Das Pseudonymisierungskonzept ist per se etwas komplexer als dasjenige der Anonymisierung, da Informationen zu einem gewissen Zeitpunkt sicher wiederhergestellt werden müssen und nicht einfach entfernt werden können.

Aus der Praxis: Im Kinderhaus AtemReich leben Kinder, die zum Atmen auf die Hilfe von Maschinen angewiesen sind. Zur Unterstützung der Spezialist*innen werden die durch die Maschinen generierten Datenströme erfasst und in der Cloud gespeichert. Eine KI identifiziert dort Anomalien oder erstellt Langzeitanalysen, was ohne die Speicherung in der Cloud nicht möglich wäre. Die Kinder haben aber allesamt unterschiedlicheste Ausgangslagen, medizinische Diagnosen und Behandlungen. Zudem spielt das Alter von wenigen Tagen bis hin zu 18 Jahren eine wichtige Rolle bei den jungen Patient*innen. Aus diesem Grund müssen Spezialist*innen die Datensätze zu gegebener Zeit zweifelsfrei einem/r spezifischen Patient*in zuordnen und ihren Ursprung identifizieren können. Gerade wenn beispielsweise Beatmungsspezialist*innen oder Kardiolog*innen Analysen zum Zustand und zur Entwicklung eines/r spezifischen Patient*in vornehmen möchten, dürfen diese Daten nicht “verwechselt” werden.

Mögliche Anwendungsgebiete für Arbeiten mit pseudonymisierten Daten in der Cloud sind typischerweise individuumbasierte Analysen im Bereich:

• Patientendaten (Gesundheitsbranche, z.B. Behandlungsoptimierungen)
• Kundendaten (Dienstleistungsbranche, z.B. Next Best Action, Betrugserkennung)
• Bürgerdaten (Öffentlicher Sektor, z.B. Steuerhinterziehung)
  
  

Lösungsansatz Pseudonymisierung

Wie aus dem Beispiel des Kinderhauses AtemReich hervorgeht, verwendet Trivadis – Part of Accenture pseudonymisierte Patientendaten, um basierend auf patientenspezifischen Modellen Anomalien in der Beatmung zu identifizieren. Damit die Daten nach dem "Privacy by Design"-Prinzip gesichert sind, werden die Patientenzuordnungen der Gesundheitsdaten “in motion” (d.h. bei ihrer Übertragung) und "at rest" (d.h. wenn sie gespeichert sind) verschleiert. Sie können im Analyseprozess zwar eindeutig jemand Unbekanntem zugeordnet werden, im Falle einer Daten-Kompromitierung kann aber kein Rückschluss auf die dahinterliegenden Person gezogen werden. Da die Daten- und Erkenntnisskonsument*innen am Ende des Prozesses aber sprechende Bezeichnungen (Patientennamen) zwecks Vermeidung von Verwechslung in den Reports sehen müssen, werden die Identifier-zu-Namen-Zuordnungen zur Rückschlüsselung sicher in einem speziell geschützten, separaten Bereich in der Cloud verwahrt. In den Reports selbst sind hierbei keine personenspezifischen Daten gespeichert. Der Zugang zur gesicherten Zuordnungstabelle, welche diese Daten für die Auflösung im Report vorhält, erfolgt zu Laufzeit des Reports über eine konfigurierte Zugriffsberechtigung.

Nachfolgend erläutere ich den Prozess nach einer einführenden Übersicht Schritt für Schritt.

Übersicht über die wesentlichen Komponenten und Akteure im "End-to-end"-Prozess:

 

• In der "Pseudonymisierungszone" (Cloud) befinden sich die geschützten Mapping-Informationen.
• In der Analytischen Zone (Cloud) werden Nutzdaten analysiert und neue Algortihmen erprobt, um neue Erkenntnisse und Prognosen zu generieren.
• In der Nutzungs-Zone (Cloud / OnPrem) werden die Resultate aufgeschlüsselt dargestellt.
  
  

Schritt für Schritt Ablauf der Pseudonymisierung und ihrer Auflösung

Schritt 1 und 2: Pseudonym erstellen

Zu verschleidernde Identifier (etwa Personennamen) werden der Pseudonymisierungsmapping-Tabelle (z.B. in einem Key Vault oder einer Datenbanktabelle) bekanntgemacht und ihr zugewiesener, verschleierter Wert wird zurück übermittelt. Dieser angepasste Wert könnte je nach Möglichkeit direkt auf dem Quellsystem in einer spezifischen Outbound-Zone eingeflochten werden, in der Regel lässt man die Quellsysteme aber möglichst unangetastet. Stattdessen kommt ein kleiner automatisierter "Helper"-Prozess zum Einsatz (vergleiche nachfolgendes Detail-Umsetzungsbeispiel). Dies könnte etwa ein PowerShell-Script sein, welches lokal zwischengespeicherte, frisch exportierte Rohdaten durchgeht und die sensiblen Werte entsprechend ersetzt, bevor sie die "Operative Zone" verlassen.

Detail-Umsetzungsbeispiel
In diesem Detail-Beispiel wird zusätzlich noch ein Personen-Stammdaten-System genutzt, welches federführend für die Personeninformationen ist.

Schritt 3: Pseudonymisierte Nutzdaten übertragen

Die pseudonymisierten Daten und die Nutzdaten werden über einen sicheren Kanal (HTTPS, VPN) in die Cloud übertragen.

Schritt 4 und 5: Daten Analyse und Erkenntnis Anreicherung

Die übertragenen und gespeicherten Daten können durch Spezialist*innen oder Prozesse ausgewertet werden, ohne dass dabei Rückschlüsse auf Personen gemacht werden können.

Schritt 6 und nachfolgende: Resultat (=Aufbereitete Daten und Erkenntnisse) und Nutzung

Die Daten sollen zum Ende des Vorgangs durch eine/n Nutzer*in unverschleiert konsumiert werden können. Hierzu werden einerseits beim Datenaufruf die Nutzdaten eingelesen und parallel dazu zu Laufzeit über einen auf dem Service hinterlegten Schlüssel die entsprechenden Pseudonyme ab der Mapping-Tabelle aufgelöst und angezeigt.