Hier kommen neue Tipps zum Maskieren: Denn die EU-Datenschutzgrundverordnung DSGVO fordert Sie und Ihr Unternehmen auf, alle (Zitat) erforderlichen technischen und organisatorischen Maßnahmen zu ergreifen und die zum Zeitpunkt der Verarbeitung verfügbare Technologie und technologischen Entwicklungen zu berücksichtigen. Wie können Sie diesem Anspruch in der Praxis gerecht werden? Im ersten Teil haben wir Feldinhalte anonymisiert oder durch Pseudonyme ersetzt. Das kann, muss aber nicht ausreichen. Daher beschäftigen wir uns heute mit Beta-Funktionen (dem Königsweg der Pseudonymisierung), durchgerutschten Personendaten und der spannenden Frage …

Wie zufällig darf Ihre Geburt sein?

Der exakte Tag Ihrer Geburt ist Ihnen wichtig, naturgemäß. Der Analytiker Ihrer Daten hingegen wird eh nicht zum Geburtstag gratulieren dürfen („Opt-in?!“). Ihn interessiert grob das Alter, vielleicht sogar nur das Jahrzehnt. Jener SQL-Code aus Teil 1 verschiebt den Tag zufällig plus/ minus um fünf Tage – ein Kenner Ihres Geburtsdatums wird also im gestohlenen Datenexport vergeblich nach Ihrem Satz suchen: Datenschutz-Gefahr gebannt!

Aber auch das sollte man besser mal prüfen … so im Sinne des geforderten Nachweises jener „angemessenen Maßnahmen“, Stichwort Clustergröße: In unserem Beispiel gibt es bei den gut 5.000 VIP-Kunden plötzlich nur einen in den Zwanzigern, dessen Postleitzahl mit einer Eins beginnt. Der für die „indirekte Bestimmbarkeit erforderliche Zeitaufwand“ (EWG 21 DSGVO) dürfte hier gering sein. Juristisch schlimmstenfalls zu gering.

Die Beta-Funktion: Königsweg der Pseudonymisierung

In EWG 29 DSGVO ist glücklicherweise auch formuliert, was uns hier hilft, dieses Problem in den Griff zu bekommen: Jene zum Personenzuordnen nötige Information wird einfach gesondert aufbewahrt. Das kann ein Schlüssel sein oder eine mathematische Funktion, also ein Makro mit einem „geheimen“ Algorithmus, den ich nur benutze, ich aber nicht kenne. Wie „knifflig“ dessen Logik sein muss, dazu sagt das Gesetz nichts. Diese sogenannte Beta-Funktion sollte aus analytischer Sicht zwei Nebenbedingungen genügen:

• sie muss umkehrbar sein (ein „Hash“ ist das beispielsweise nicht),
• und das Ergebnis der Maskierung möge bitte monoton sein, meint: hoher Originalwert = hoher neuer Wert (eine „Encryption“ tut das eben nicht).

Wieso? Nun, die analytischen Modelle sollten bloß nicht zu stark beeinträchtigt werden – idealerweise liefert die Funktion also etwas Lineares oder leicht Exponentielles … Hier ein bewusst einfaches √2-Beispiel:

proc fcmp outlib= SH.DSGVO.BETA;
     function BETA1( Typ $, Wert );
          if Typ = 'ALTER1' then return(Wert*sqrt(2));
          if Typ = 'DATUM1' then return(Wert+floor(3650*sqrt(2)));
     endsub;
     function BETA1I( Typ $, Wert );
          if Typ = 'ALTER1' then return(Wert/sqrt(2));
          if Typ = 'DATUM1' then return(Wert-floor(3650*sqrt(2)));
     endsub;
run;

Das ist mathematisch eine Koordinatentransformation – oder man kann es sich vereinfacht wie bei „Star Trek“ vorstellen: Einige Personen werden quasi auf einen anderen, Ihnen unbekannten Planeten „gebeamt“. Dort herrscht eine von der Erde abweichende Schwerkraft (ein anderes Koordinatensystem), gilt aber für alle gleichermaßen – also leichtgewichtige Besucher können dort weiterhin höher hüpfen als ihre gewichtigen Kollegen. Selbiges gelte diskret für das Alter.

proc DS2;
     package DSGVO / overwrite=yes language='fcmp' table='SH.DSGVO';
     run;
data  pdp_de_demo.data.crm_kundenbasis_ds2_beta(type=view overwrite=yes 
     keep=(Geburtsdatum Geburtsdatum_Nach_Beta Alter Alter_nach_Beta));
     dcl package DSGVO p();
     dcl date Geburtsdatum_Nach_Beta having format ddmmyyp10.;
     dcl double Alter;
     dcl double Alter_nach_Beta;
     method run();
          set pdp_de_demo.data.CRM_KUNDENBASIS;
	   Alter = round((today()-to_double(Geburtsdatum))/365.25,1);
	   Alter_nach_Beta = round(p.BETA1('ALTER1',Alter),1);
	   Geburtsdatum_Nach_Beta = to_date(p.BETA1('DATUM1',to_double(Geburtsdatum)));
     end;
     enddata;
run; quit;

Beim Anwenden auf das Geburtsdatum oder das Alter weiß ich als Analytiker gar nicht, wie genau hier solch „Beamen“ technisch funktioniert, vertraue aber beim Modellentwickeln (und später beim Scoren), dass sich am Verhalten nichts ändert. Übrigens: Computer & Korrelation ist das eh egal – beide haben keinerlei Vorstellung vom „Alter“. Fühlt sich nur für den Menschen ein wenig merkwürdig an.

Das „echte“ Alter geht uns nicht verloren. Es kann über eine Beta-Funktion zurück gerechnet werden: Diese sogenannte „Inverse“ steht aber nur autorisierten Mitarbeitern zur Verfügung – um beispielsweise bei Betrugsfällen oder Datenschutz-Klagen auskunftsfähig zu sein. Ihr Kunde wird dann quasi „wieder auf die Erde zurückgebeamt“.

Einwände meines Büronachbarn

„Wie aber erkläre ich dem Chef mein Modellverhalten solch 300-Jähriger?!“ … Nun, in Zeiten von Machine Learning sind neuronale Netze in zunehmender Verbreitung ebenso trennscharf wie unerklärlich. Hier bei uns ist zumindest die Entscheidung noch nachvollziehbar; nur liegt nicht mehr der gesamte Code inklusive heißer Kundendaten auf Ihrem PC – wegen Datenschutz. Gut so.

Finaler Aspekt: Die Daten relevanter Spalten sind nun smart maskiert, die Logik liegt zentral und wirkt im Geheimen. Was aber ist mit vermeintlich harmlosen Feldern weit hinten, meist nichtssagend bis leer, die dann als Vertriebshinweis oder Notiz doch plötzlich den Namen der Ehefrau preisgeben, die Zweit-E-Mail oder den alten Arbeitgeber offenbaren? Weil der erfassende Autor das „höchst praktisch“ fand; weil er auf der Vertragserfassungsmaske sonst nichts fand, es einzutippen und zu speichern.

(CASE WHEN ( SYSPROC.DQ.DQUALITY.DQEXTRACT ( A.FREITEXTFELD, 'PDP - Personal Data (Core)', 'Individual','DEDEU' ) ne '' )
          THEN '* * *' ELSE A.FREITEXTFELD END)
     AS Freitextfeld_ohne_Namen,
SYSPROC.DQ.DQUALITY.DQIDENTIFY ( A.ANMERKUNG, 'PDP - Personal Data (Core)', 'DEDEU' )
     AS ANMERKUNG_IDENTIFY

SAS Data Quality hat vorgefertigte, einsehbare Regelwerke zum Selber-Tunen, die viele jener Fälle heuristisch aufspüren. Das ist unverzichtbar, denn: Was ich nicht kenne, kann ich nicht schützen. (Kripo-Weisheit: Habe ich das kleine Kellerfenster übersehen beim Sensoreinbau, wird der Einbrecher nicht höflich die Vordertür aufhebeln!).

Das ist Voraussetzung für eine Inventur des Datenhaushalts, die Schätzung des DSGVO-Implementierungsaufwandes – hier aber eine zusätzliche Sicherheit. Denn im Code oben wird dieser Filter noch auf die Daten gelegt: Rutscht hier der Name einer natürlichen Person durch, dann werden beim Lesen nur Sternchen geliefert. Das Feld „Anmerkung“ wird immer ersetzt durch die Bezeichnung der Kategorie, im Sinne: „Hier steht eine Telefonnummer! Nach Freigabe durch den Datenschutzbeauftragten dürfen Sie die auch sehen – vorher aber nicht.“

Disclaimer (Haftungsausschluss): Der Autor dieses Blogs ist kein Jurist. Jegliche Aussage im Text stellt keine Rechtsberatung dar und kann auch keine Rechtsberatung ersetzen. Alle Code-Beispiele dienen einzig der Illustration.