Testen oder Datenschutz, das ist hier die Frage

Testdaten: Eine Falle der DSGVO?

Elmar Eperiesi-Beck

© Shutterstock / stockwerk-fotodesign

Seit nun beinahe zwei Jahren ist die Europäische Datenschutz Grundverordnung (EU-DSGVO) in Kraft. Die meisten Unternehmen haben sich inzwischen auf die Verordnung eingestellt und fühlen sich vor möglichen Strafzahlungen geschützt. Man kann sagen, die Geschäftswelt habe sich mit der DSGVO arrangiert. Wie so häufig, steckt der Teufel vor allem im Detail und Unternehmen könnten an unerwarteter Stelle, ohne es zu wissen, gegen die EU-DSGVO verstoßen. Ich rede von der Verwendung sensibler Daten für Testzwecke.

Unternehmen müssen für die Entwicklung, den Test und die Schulung von Software auf realistische Daten zurückgreifen. Nehmen sie beispielsweise Änderungen ihrer CRM-Systeme oder Personalsoftware vor, müssen diese zunächst getestet werden, bevor sie in den Produktivsystemen zum Einsatz kommen können. Allerdings greift die DSGVO auch hier: Sensible Informationen dürfen nur für die Zwecke verwendet werden, zu denen sie erhoben wurden. Daher lassen sich Produktionsdaten nicht einfach so in einer Entwicklungsumgebung einsetzen. Geschieht das dennoch, können saftige Strafen drohen.

Die besondere Herausforderung bei Testdaten besteht darin, dass sie die gleiche Struktur und das gleiche Format wie Produktivdaten haben müssen, um die gleichen Fehler zu provozieren, die später auftreten können, wenn Produktionsdaten in die Anwendung gelangen. Die Herausforderung kann sogar noch größer sein, wie der Fall eines Schweizer Finanzdienstleisters zeigt: Dieser Dienstleister, der auch Kreditkarten ausstellt, muss seine eigene Software regelmäßig testen – eine komplexe Eigenentwicklung, die strengsten Regulierungen und gesetzlichen Vorgaben wie dem Payment Card Industry Data Security Standard (PCI-DSS) unterliegt. Daher muss er dafür sorgen, dass die Testdaten aus 16-stelligen Kreditkartennummern bestehen, die mit entsprechenden Prüfziffern, Codierungen und Steuerinformationen verknüpft sind. Die aus den Originaldaten generierten anonymen Testdaten dürfen dabei keinerlei Rückschlüsse auf die echten Daten zulassen. Trotzdem müssen sie natürlich, um reale Fehler simulieren zu können, die gleiche Struktur und das gleiche Format wie die Produktivdaten ausweisen. Kurz gesagt: Die besondere Herausforderung bestand in diesem Fall darin, dass die Lösung zur Datenanonymisierung mit dem Unternehmenssystem kompatibel sein musste und sowohl Webanwendungen, Dateien sowie Datenbanken wie DB2 und Oracle unterstützte.

Pseudonymisierung – Tokenisierung – Anonymisierung

Aber auch derart komplexe Anforderungen lassen sich mit der richtigen Technik lösen. Wo aber liegen die Unterschiede der einzelnen Techniken? Pseudonymisierung, bezeichnet die Verarbeitung personenbezogener Daten auf eine Weise, dass die personenbezogenen Daten „ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können“ (Art. 4, Abs. 5 DSGVO). Das bedeutet bspw., dass ein Originalwert durch einen anderen Wert ersetzt wird und die Zuordnung in einer entsprechenden Tabelle gespeichert. Bei Bedarf kann das Original so wieder rekonstruiert werden. Die Zuordnungstabelle kann getrennt von den Systemen, Anwendungen und Datenbanken aufbewahrt werden.

Als Tokenisierung bezeichnet man hierbei die Erzeugung von Ersatzwerten für bestimmte Originalwerte. Bei fortschrittlichen Lösungen werden die Originalwerte nach der Tokenisierung verschlüsselt und erst dann in der in der eigenen Token-Datenbank abgelegt. Das sorgt für zusätzliche Sicherheit und Wahrung der DSGVO.

Für die Erzeugung von Testdaten rate ich allerdings dazu, noch einen Schritt weiter zu gehen und Daten zu anonymisieren. Warum? Anonymisierung ist einfach noch eine Stufe strikter als die Pseudonymisierung: Denn in diesem Fall werden personenbezogene Daten dergestalt gespeichert und verarbeitet, „dass die betroffene Person nicht oder nicht mehr identifiziert werden kann“ (Vorwort 26 DSGVO). Im Gegensatz zur Pseudonymisierung schließt die Anonymisierung also das Speichern des Originalwertes und der Zuordnungstabelle aus. Durch die strenge Datenschutzauffassung eignet sich die Anonymisierung damit bestens für die Bereitstellung von Testdaten, denn es sind keine Rückschlüsse mehr auf die Originaldaten möglich.

Weil der gesamte Prozess der Pseudonymisierung bzw. Anonymisierung für Testdaten alles andere als trivial ist und von den meisten Unternehmen nicht mit Bordmitteln geleistet werden kann, können entsprechende Gateways eingesetzt werden, die über diese Funktion verfügen.

Wie der Fall des oben erwähnten Schweizer Finanzdienstleisters verdeutlicht, lassen sich diese Schritte auch in komplexen Umgebungen ausführen. Auch wenn sich die Erzeugung von Testdaten bisher vielleicht weitgehend im „toten Winkel“ der Diskussion um die DSGVO abgespielt hat – technisch gesehen haben Unternehmen jedenfalls keine Ausrede mehr, wenn sie im Falle der Erzeugung von Testdaten gegen die Verordnung verstoßen sollten. Und dass die Zeit für Ausreden tatsächlich vorbei ist, sollte sich langsam herumgesprochen haben, nachdem die Behörden jetzt auch in Deutschland mehr und mehr ‚blaue (DSGVO-) Briefe‘ aussenden.

Geschrieben von
Elmar Eperiesi-Beck

Elmar Eperiesi-Beck ist Founder und CEO der eperi GmbH.

Kommentare

1
Hinterlasse einen Kommentar

avatar
4000
1 Kommentar Themen
0 Themen Antworten
0 Follower
 
Kommentar, auf das am meisten reagiert wurde
Beliebtestes Kommentar Thema
1 Kommentatoren
Adam Knoop Letzte Kommentartoren
  Subscribe  
Benachrichtige mich zu:
Adam Knoop
Gast

Ich glaube, die einzige Lösung für das Testen mit persönlichen Daten besteht darin, diese Testdaten zu synthetisieren.