undefinedWenn man die aktuelle Presse verfolgt kann man zu dem Schluss kommen, dass bei allen Servern die im Internet stehen der Verlust von Daten nur noch eine Frage der Zeit ist. Tatsächlich ist die IT-Infrastruktur vieler Unternehmen inzwischen offenbar so komplex, dass Lücken unentdeckt bleiben und damit schon leichte Fahrlässigkeit oder fehlende Patches umgehend zu großen Datenverlusten führen. Durch zunehmendes Cloud-Hosting sind viele der Systeme heute öffentlich zugänglich, was die Wahrscheinlichkeit von Angriffen weiter erhöht.

Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!

 

Gibt es unkritischen Datenverlust?

Zuerst mag die Frage absurd erscheinen, doch nicht alle Datenverluste sind automatisch auch tragisch oder schädlich. Selbst Röntgenbilder, Medikamentenpläne, Lohnabrechnungen oder Kontoauszüge sind dann unkritisch, wenn jeweils kein Name, Adresse und Geburtsdatum darauf vermerkt sind. Dann sind diese Daten für den Finder uninteressant. Es lässt sich damit niemand erpressen oder schädigen.

Pseudonymisierung

Klick für VollbildEine mögliche Lösung kann die Pseudonymisierung der Daten sein. Man betrachtet die Daten hierbei als mehrteilig. Zum einen sind da die erfassten Nutzdaten (Content) und zum anderen die Zuordnungsdaten zu einer Person oder Organisation (Identification Data). Im Gegensatz zur Anonymisierung wird die Zuordnung bei einer Pseudonymisierung nicht irreversibel vernichtet sondern nur getrennt und bei Bedarf wieder zusammengeführt. Das erlaubt es, mit den Daten auch produktiv zu arbeiten. Typische Anwendungen sind das Teilen von Nutzdaten zu Forschungszwecken, ohne die Zuordnungsdaten zu übermitteln. Das garantiert den Personen oder Organisationen eine risikolose Verarbeitung ihrer und auch fremder Daten.

Die Idee ist nicht neu, aber leider wird Pseudonymisierung heute meist erst viel zu spät in der Prozesskette angewendet. Die Daten sind längst verknüpft und liegen Gemeinschaftlich in einem Datentopf. Die Pseudonymisierung wird oft erst angewendet, wenn die Daten mit dritten geteilt werden. Die Gefahr eines schädlichen Datenverlustes besteht bei diesen Diensten weiterhin.

Honeypot

In der Szene sind Datensammlungen, in denen Daten mit Wert oder Potential liegen, gerne als Honeypot bezeichnet. Dabei ist teilweise auch eine Falle für Datendiebe gemeint, aber alle haben gemeinsam, dass die Daten begehrenswert sind. Fast alle medizinischen Datensammlungen sind heute solche Honeypots. Wer die Daten in die Hände bekommt, kann damit Geld erpressen oder anderen Unfug treiben.

Pseudonymisierung als Daten-Impfung

Vaccinator - Klick für VollbildDie Daten-Impfung verfolgt das selbe Prinzip der Trennung zwischen Nutzdaten und Zuordnungsdaten. Allerdings erfolgt diese Trennung bereits bei der Erfassung oder Generierung dieser Daten. Beispielsweise wird ein Röntgenbild nicht mehr mit Name und Geburtsdatum gekennzeichnet abgelegt, sondern nur noch mit einer Identifizierungsnummer. Name und Geburtsdatum werden dagegen separat erfasst und ebenfalls mit dieser Identifizierungsnummer verknüpft.

Der Service-Dienstleister, der die Anwendung verfügbar macht, speichert und verwaltet jetzt nur die Nutzdaten. Die Zuordnungsdaten werden direkt über einen externen Impf-Service abgelegt. In der Anwendung beim Endnutzer (zB Arzt, Bankmitarbeiter, HR-Abteilung etc) werden diese Daten zusammengeführt und dort ist von der Trennung effektiv nichts zu spüren. Aber die Zuordnungsdaten verlassen die Geräte nur zum externen Impf-Service. Durch Verschlüsselung wird sichergestellt, dass der Service Dienstleister und auch der Impf-Service diese Zuordnungsdaten nicht lesen können.

Vorteile der Daten-Impfung

Durch die Trennung der Zuordnungsdaten von den Nutzdaten ist ein Verlust dieser Datentöpfe nicht weiter tragisch. Ein Finder kann die Daten keiner Person zuordnen bzw die Person keinen Daten. Natürlich bedeutet das nicht, dass der Service Dienstleister oder der Impf-Service die Daten nicht angemessen schützen. Dennoch ist ein nicht abwendbarer Datenverlust bei weitem nicht so schädlich.

Die Service Dienstleister werden nicht mehr als lohnenswertes Ziel für Angriffe gesehen, denn die vorliegenden Daten sind nicht zugeordnet.

Die pseudonymisierten Daten können leichter geteilt werden, denn eine versehentliche Zuordnung zum Patient oder Organisation ist nicht Möglich.

Im Notfall ist eine nachträgliche Zuordnung der Nutzdaten durch Mithilfe des Endnutzers durchaus Möglich. So können, falls Anwendbar, auch Patienten und Organisationen von gemeinschaftlicher Forschung an den Nutzdaten profitieren.

APP-ID

Damit der Betreiber des Impf-Service die Nutzdaten nicht kennt, kann der Inhalt verschlüsselt gespeichert werden. So kennt nur die Endanwendung die Personendaten. Da hier alle Zuordnungen verloren gehen wenn das Passwort vergessen oder verloren wird, ist es wichtig ein Passwort zu nutzen das im Zweifelsfall wieder hergestellt werden kann. Eine Idee ist ein APP-ID-Service der jemandem ein Passwort erstellt und gegebenenfalls auch wieder mitteilt. So lange dieser Dienst unabhängig vom Service-Dienstleister oder Impf-Service ist, ist es eine recht unkritische Sache.

Lösung als Open-Source

Um einen solchen Service erfolgreich anzubieten, muß es einen einfachen und günstigen Zugang zu einem Impf-Service geben. Nur so kann eine Verbreitung als Standard erfolgen. Denn ohne die Mitwirkung von Software-Anbietern wird das nicht passieren.

Daher habe ich mich entschlossen, in meiner Freizeit einen solchen Service als Open-Source-Software zu entwickeln (Vaccinator). Sobald es dazu neues gibt, werde ich die Links und Informationen hier nachführen. Eventuell mache ich das selbe für einen APP-ID-Service? Mal sehen...

Updates

Jan 2020

Ich habe einen Vaccinator-Service in PHP/MySQL entwickelt. Den Sourcecode und die zugehörige Dokumentation für das Protokoll und die Funktionen findet ihr auf meinem GitHub Account:

https://github.com/Kukulkano/dataVaccinator

Im Ordner /examples/ findet Ihr ein Beispiel zu einer PHP-Implementation auf Seite eines Service-Provider.

Um das ganze lokal zu nutzen, habe ich auch eine Vaccinator JavaScript-Klasse entwickelt, die lokal beim Endanwender verwendet werden kann. Sie bietet alle Funktionen zur Nutzung und befreit Entwickler davon sich mit dem Protokoll und der Verschlüsselung beschäftigen zu müssen. Die zugehörige Dokumentation ist ebenfalls im Repository:

https://github.com/Kukulkano/vaccinatorJSClient