Wie man für den Datenschutz sorgen kann : Teil 1

In der heutigen Gesellschaft kann man sich kaum eine Domäne vorstellen, die nicht von Informationssystemen beeinflusst worden ist.

Sei es die Kommunikation unter Menschen, die Optimierung von Geschäftsprozessen oder sogar die eigene Steuererklärung, ist heute der Eingriff von Computersystemen fast unabdingbar. Computersysteme haben nicht nur existierende Bereiche optimiert, sondern auch neue Anwendungsbereiche geprägt. Diese Systeme arbeiten meist nicht isoliert, sondern kommunizieren oft mit anderen Systemen. Die Entwicklung des IoT ist zudem auf diese Allgegenwart von Computersystemen zurückzuführen. Fast jedes Objekt dient in dieser Weltanschauung als Informationsquelle bzw. -senke.

Weiterhin hat man erst in den letzten Jahrzehnten angefangen, das verborgene Potenzial von gigantischen Datenmengen wirklich auszuschöpfen (s. auch Data Mining). Dadurch konnte man eine erhöhte Effizienz von den obengenannten Prozessen erzielen oder manchmal neue Einblicke in Datenmengen gewinnen, die zuvor nicht wahrgenommene Möglichkeiten ans Licht gebracht haben.

Zur Einleitung stelle ich im folgenden eine Beispieldatenmenge vor, die einen Ausschnitt medizinischer Daten darstellen sollte.

UIDNameM/FGeburtsdatumAdresseEthnizitätFamilienstandProblem
Z7RE8LU8 Kyle Lippard M 2005-04-29 Sapphire Lane 23, 30100 Deutsch ledig Herzprobleme
VHB8SDTT Burt Buntin M 1975-03-17 Ranger Way 2, 30100 Deutsch ledig Herzprobleme
LGFJW3FC Hilda Embrey F 1986-12-16 Greenfield Street 14, 30107 Spanisch verheiratet Hautallergien
UT2VFDR0 Araceli Stiller F 1969-01-12 Maple Passage 7, 30102 Deutsch verheiratet Brustkrebs
BWU94HR0 Erasmo Lennon M 1978-11-17 Onyx Street 27, 30107 Italienisch verheiratet Herzprobleme
V6NFXLSE Idella Murr F 1996-07-07 Hope Lane 13, 30111 Spanisch ledig Wasserbürtige Krankheiten
14UCCGEO Gabriele Hilton F 1984-07-14 Main Avenue 28, 30102 Französisch verheiratet Erkältung/Grippe
94CK4A6D Pete Entwistle M 1966-03-07 Garden Street 5, 30111 Deutsch verheiratet Wasserbürtige Krankheiten
CX658UGC Valerie Rients F 1989-03-20 Gold Way 10, 30111 Spanisch ledig Wasserbürtige Krankheiten
8XWIMLDW Reina Hertzog F 1996-07-16 Mount Avenue 28, 30112 Russisch ledig Erkältung/Grippe
SCC2NYHI Kali Burgess F 1972-06-09 Castle Street 19, 30111 Italienisch verheiratet Wasserbürtige Krankheiten
6614BNB2 Winona Vore F 1967-12-22 Starfall Route 5, 30112 Russisch ledig Brustkrebs
NDQUSRLS Regine Provenza F 1989-05-31 Arch Avenue 8, 30112 Russisch verheiratet Erkältung/Grippe
VZDFL32F Ambrose Kingsberry M 2004-06-12 Shadow Boulevard 19, 30110 Italienisch ledig Herzprobleme
6CMGUTRK Willodean Elsasser F 1983-10-16 Grove Lane 23, 30107 Französisch verheiratet Erkältung/Grippe
WVO2QEN4 Terrie Gunn F 1968-02-15 Lower Row 21, 30100 Deutsch ledig Erkältung/Grippe
JF9JAUGY Freda Keane F 1970-06-16 Fountain Passage 22, 30100 Deutsch ledig Hautallergien
9I8J8MOI Allen Stevie M 1964-12-01 Cross Passage 21, 30112 Russisch verheiratet Herzprobleme
ERM8SOLB Verlie Brzozowski F 1960-09-12 Fair Lane 24, 30100 Deutsch ledig Brustkrebs
L7MDI78R Chester Marty M 1983-01-26 Heritage Row 17, 30110 Französisch ledig Erkältung/Grippe
FP2KNSPG Arlinda Mcie F 1969-01-07 Gem Way 22, 30107 Russisch verheiratet Erkältung/Grippe
70J7CF20 Michal Selders M 1979-04-02 Park Route 23, 30112 Russisch ledig Hautallergien
WYHTWM9G Marcel Tyndall M 1985-11-03 Justice Way 25, 30112 Russisch ledig Herzprobleme
RY2LSWOY Angle Dempster F 1987-09-22 Crimson Way 9, 30110 Deutsch ledig Hautallergien
SGHTB5X8 Allena Kuhlmann F 1991-04-29 Ember Passage 5, 30107 Russisch verheiratet Erkältung/Grippe

Tabelle 1

Diese Daten sehen auf dem ersten Blick chaotisch aus, verwendet man aber inzwischen übliche Data-Mining Techniken, so kann man die Bedingungen für bestimmte Krankheiten analysieren. Die Einzelheiten der Generierung eines Klassifikators, z.B. warum ein Klassifikator nicht zu 100% den Trainingsdaten entspricht (Hinweis: Overfitting), werden hier nicht behandelt.

Hier ein generierter Klassifikator (Entscheidungsregeln) für Krankheiten für diese Daten.

Klassifikator Entscheidungsregeln

Anhand des Klassifikators (in dem interessanterweise das Attribut "Name" nicht auftaucht) lassen sich interessante Erkenntnisse über die Tabelle gewinnen, und die Datenmenge sieht nicht mehr so komplex aus.

Hier ist bemerkenswert, dass man im Datenerhebungsschritt (a priori) nicht wusste, dass die Postleitzahl z.B. bestimmen würde, ob ein Patient aufgrund wasserbürtigen Krankheiten ins Krankenhaus gekommen ist. Im Nachhinein weist sowas auf die möglicherweise mangelnde Trinkwasserqualität in dieser Region hin. Die Erhebung der Postleitzahl hat also nicht nur die Daten besser (wenigere komplexe Regeln) erklären können, sondern hat auch zu einem wichtigen unerwartetem Ergebnis geführt.

Ausserdem sind in diesen Daten auch andere interessante Muster kaschiert.

Man stellt zum Beispiel fest, dass alle Einwohner der Postleitzahl 30107 verheiratet sind, und dass alle Einwohner der Postleitzahl 30100 bzw. 30112 deutsche bzw. russische Herkunft haben.

Hier wusste man wieder a priori nicht, dass

  • man in Zukunft anhand der medizinischen Daten vielleicht demographische Analysen machen möchte.
  • sich die Erhebung dieser Attribute für die demographische Analyse als nützlich erweisen würde.

Um die eigene Wissensbasis in unvorhersehbare Richtungen flexibel zu erweitern, ist es also üblich geworden, intuitiv fast jede mikroskopische Transaktion bzw. Aktion jedes Menschen ohne Rücksicht auf ihren Datenschutz zu erheben und zu speichern.

Weniger ist doch nicht mehr

Ich werde versuchen, die obige Intuition zu rechtfertigen.

Generell gilt die Aussage, dass Datenmengen mit mehr Informationsgehalt für Analysen nützlicher sind.
Andersrum gesagt, Tabellen die wenig Information beinhalten, haben wenig Information zu bieten.
Darüber sollte man sich im Klaren sein, auch wenn es etwas offensichtlich klingt. Die Aussage hat andererseits große Konsequenzen, auch wenn die Darstellung und das Beispiel hier absichtlich einfach gehalten sind.

Was soll man aber unter "mehr Information" verstehen? Gibt es einen formalen Weg diesen Begriff zu beschreiben?
Und was hat das mit Datenschutz zu tun?

Um sich das klar zu machen, macht man sich Gedanken über den Entropiebegriff von Shannon (1948).

Sei H die Entropie einer Tabelle T, pt die Auftrittswahrscheinlichkeit eines Zeilentupels t und It sein Informationsgehalt.Dann gilt 

Tabelle1

Eine frequentistische Interpretation dieser Definition ist, dass man den Informationsgehalt jedes Datensatzes aus der Tabelle aufsummiert und durch die Größe der Tabelle teilt, um den Durchschnittsinformationsgehalt einer Zeile zu gewinnen.

H stellt also intuitiv den Informationsgehalt einer zufällig gewählten Zeile aus der Tabelle dar. Das Problem haben wir bis jetzt nur noch verschoben, weil sich jetzt wiederum die Frage stellt, was der Informationsgehalt einer Zeile ist.

Der Informationsgehalt einer Zeile wird über die Aussagekraft ihrer Wertebelegung definiert.

Tabelle2

Unwahrscheinliche Wertebelegungen zeichnen eine Zeile aus. Spaltenwerte, die in Kombination sehr wahrscheinlich sind, liefern bereits bekannte Informationen und bieten daher einen geringeren Informationsgehalt.

Damit eine Analyse auf einer Tabelle kräftigere Aussagen ausliefern kann, müssen sich noch mehr Zeilen dieser Tabelle von den anderen Zeilen unterscheiden.
Um das auf einfachem Weg zu erzielen, ohne die Daten zu fälschen, ist es sinnvoll mehr Attribute zu erheben, die vorher (fast) identische Zeilentupeln von einander abgrenzen können.

FamilienstandProblem
ledig Herzprobleme
ledig Herzprobleme
verheiratet Hautallergien
verheiratet Brustkrebs
verheiratet Herzprobleme
ledig Wasserbürtige Krankheiten
verheiratet Erkältung/Grippe
verheiratet Wasserbürtige Krankheiten
ledig Wasserbürtige Krankheiten
ledig Erkältung/Grippe
verheiratet Wasserbürtige Krankheiten
ledig Brustkrebs
ledig Herzprobleme
verheiratet Erkältung/Grippe
verheiratet Erkältung/Grippe

 

M/FEthnizitätFamilienstandProblem
M Italienisch ledig Herzprobleme
M Deutsch ledig Herzprobleme
F Spanisch verheiratet Hautallergien
F Deutsch verheiratet Brustkrebs
M Italienisch verheiratet Herzprobleme
F Spanisch ledig Wasserbürtige Krankheiten
F Französisch verheiratet Erkältung/Grippe
M Deutsch verheiratet Wasserbürtige Krankheiten
F Spanisch ledig Wasserbürtige Krankheiten
F Russisch ledig Erkältung/Grippe
F Italienisch verheiratet Wasserbürtige Krankheiten
F Russisch ledig Brustkrebs
M Deutsch ledig Herzprobleme
F Russisch verheiratet Erkältung/Grippe
F Französisch verheiratet Erkältung/Grippe

Die untere Tabelle enthält offensichtlich "mehr Information" als die obere Tabelle. Allerdings haben wir den Begriff formal gefasst und können die Aussage begründen.
Innerhalb dieser Tabelle unterscheiden sich mehr Zeilen von einander, weil es mehr Spalten gibt, deren Werte die Zeilen von einander trennen. Dazu betrachte man jeweils die ersten (oder letzten) zwei Einträge.

Vergleicht man die untere Tabelle mit Tabelle 1, so ist klar, dass in Tabelle 1 die UID ausreicht, um alle Zeilen von einander zu unterscheiden. Deswegen hat Tabelle 1 mehr Entropie. Der höhere Informationsgehalt würde sich beispielsweise darin wiederspiegeln, dass man mit Tabelle 1 mehrfache Krankenhausbesuche einer Person ausschließen bzw. feststellen könnte.

Auf diese Weise erhält man flexible bzw. verfügbare Daten, die sogar für unvorhersehbare Anwendungen sinnvolle Ergebnisse liefern können, wenn man bei der Stichprobe mehr Daten erhebt, und selbst Attribute aufnimmt, mit denen man heute nichts anfangen kann.

Diese einfachen Formeln haben aber als Konsequenz, dass man überall Sparkarten, Cashback-Karten und Coupons bekommt, mit denen man die eigenen Daten gegen einen Preiserlass tauscht. Das No-Free-Lunch Theorem gilt allerdings immernoch.
Es ist nicht unüblich, dass man beim Supermarkt ab und zu gebeten wird, die eigene Postleitzahl an der Kasse mitzuteilen. Auch bei "kostenfreien" Apps zahlt man in einer Form oder der anderen.

"Wir machen kein Stalking, wir sammeln nur Entropie."

In den kommenden Artikeln werde ich zeigen, welche Gefahren für den Betroffenen bei der Verarbeitung von Personendaten bestehen können und warum Datenschutz wichtig ist, selbst wenn man "nichts zu verbergen hat". Zudem wird auch gezeigt, wie die DSGVO versucht, diese Risiken zu minimieren, was das BDSG zu sagen hat.

Darüber hinaus wird erklärt, welche Techniken Unternehmen einsetzen können, um nicht nur ihre gesetzlichen Pflichten zu erfüllen, sondern auch um tatsächlich personenbezogene Daten zu beschützen, ohne auf die durch Datenmengen realisierten Möglichkeiten zu verzichten.

Zum Schluß wird auch beschrieben, wie Data-Analytics erstaunlicherweise sogar von diesen Maßnahmen in manchen Fällen profitieren kann, was ein zusätzlicher Anreiz sein kann, sich über Informationssicherheit Gedanken zu machen.

Lesen Sie auch die Fortsetzung: Wie man für Datenschutz sorgen kann: Teil 2

Bharat Ahuja
Bharat Ahuja
Oracle Consultant
Competence Center Oracle
T.: +49 511 61 68 04 -320
E.: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Hinterlassen Sie Ihre Kommentare

0
Bedingungen.
Cookies erleichtern die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklären Sie sich damit einverstanden, dass wir Cookies verwenden.
Weitere Informationen Ok