Datenschutz und der Bedarf, an der Nutzung „echter“ Daten für Testzwecke
Testsysteme müssen wie ihre Live-Pendants mit Daten über Kunden und Zahlungsinformationen arbeiten können. Der Datenschutz ist dabei allerdings ein wichtiges Thema, welches auch mit der Datenschutzgrundverordnung im nächsten Jahr neue Fahrt aufnimmt. Doch natürlich ist auch schon das momentan gültige Gesetz einzuhalten – dafür soll dieser Artikel einen Einstieg bieten.
Bei Neu- und Weiterentwicklungen von Software ist es wichtig, realistische Testdaten zu haben, an denen die Use Cases / Anwendungsfälle getestet werden können. Denn wenn die Testdaten die echten Daten nicht ersetzen können, kann es zu kritischen Fehlern kommen, die erst nach der Veröffentlichung auffallen. Daher wird in vielen Fällen auch mit Echtdaten getestet.
Um dem Datenschutz gerecht zu werden, muss aber beachtet werden, dass personenbezogene Daten von echten Kunden meist nicht genutzt werden dürfen. Da die Aufnahme der personenbezogenen Daten immer zweckgebunden im Sinne des Bundesdatenschutzgesetzes (BDSG) sein soll, muss man sich die Verwendung in anderen Bereichen gut überlegen oder absichern. Einfach gesprochen: wenn Kontodaten für den Zweck der Abwicklung von Rechnungen aufgenommen wurden, dürfen sie nicht ohne Weiteres für Testzwecke von Neuentwicklungen genutzt werden.
Hierzu von den Kunden eine eigens dafür formulierte Einwilligung für alle Datensätze einzuholen, ist sehr aufwändig und muss – wie die anderen Einwilligungen zum Datenschutz auch – nachhaltig archiviert werden.
Oftmals sind die Softwareentwicklungen zusätzlich auch outgesourct, so dass hier generell über Verträge von Auftragsdatenverarbeitung (ADV) gesprochen werden müsste, die Kunden informiert werden müssten, und vieles mehr – je nach Anwendungsfall kann dies zu einem deutlichen, teureren Mehraufwand führen.
Es bleibt also, dass Testdaten keine echten Kundendaten enthalten sollten. Hier gibt es nun zwei verschiedene Ansätze, um Testdaten zu erzeugen:
Es wäre zum einen möglich, die Daten komplett künstlich zu erzeugen: aus einer Liste an gültigen Vornamen, Nachnamen und einem Pool an „formal gültigen, aber falschen“ Telefonnummern, Kontonummern etc. werden verschiedene, zufällig oder nach Regeln basierte Daten herausgezogen, und zu einem Testkunden zusammengesetzt.
Andererseits kann eventuelle eine Anonymisierung der echten Daten ein Ansatz sein. Dies bedeutet, dass die Anteile, die eine Person identifizieren können, aus den echten Daten so verändert werden, dass kein Bezug mehr zu einer echten Person mehr hergestellt werden kann.
Das künstliche Neu-erzeugen von Daten ist sicherlich sehr aufwändig, da auch die systemeigenen Regeln dabei beachtet werden müssen. IDs und Querverweise in den Datenbanken sollten gültig sein, zum Teil nur einfach vorkommen, so dass eine komplett zufällige Erzeugung innerhalb der Datenbank sehr unwahrscheinlich funktionieren wird. Es müsste also ein Tool erzeugt werden, welches die gesamte Fachlichkeit kennt und diese bei der Erzeugung der Daten beachten kann. Die Anonymisierung ist hier eine valide Alternative, da technische Bezüge im System in vielen Fällen erhalten bleiben können und man sich auf die „problematischen“ Datenfelder konzentrieren kann.
Was sind denn aber personenbezogene Daten? Gemäß §3 BDSG sind dies „Einzelangaben über persönliche oder sachliche Verhältnisse von bestimmten oder bestimmbaren natürlichen Personen.“[1] Dieses Spektrum reicht von den eindeutigen Fällen (zum Beispiel Namen, Adressen, Telefon- und Kontonummern) auch zu den Fällen, die nicht sofort ins Auge stechen: Die Seriennummer eines angemieteten WLAN-Routers wird bei einem TK-Unternehmen zu den „personenbeziehbaren“ Daten gehören und müsste eventuell ebenso anonymisiert werden. Die Kundennummer, die Vertragsnummer – alles Daten, die auch in den technischen Systemen als eindeutige Identifizierer genutzt werden können und evtl. nicht einfach ausgetauscht werden können. Hier kommt es aber immer auf den Einzelfall an, denn die Verhältnismäßigkeit des Aufwandes einer Anonymisierung ist auch ein beitragender Faktor.
Die wichtigste Eigenschaft der Anonymisierung ist, dass sie nicht rückgängig gemacht werden können soll[2] – selbst, wenn man den verwendeten Algorithmus kennt. Denn wenn jemand weiß, dass aus einem echten „Peter Müller“ immer ein „Christian Schneider“ in den Testdaten wird, hat er oder sie die Anonymisierung schon überwunden. Dem kann durch die Verwendung von zufälligen Elementen Abhilfe geschaffen werden. Sei es, dass für jede Testversion neue Testdaten erzeugt werden, oder dass die Zufallsbasis (der „Seed“) nach Verwendung verworfen wird, so dass keine Rückführbarkeit mehr möglich ist.
Egal, welchen Weg man wählt, der schmale Grat zwischen technisch händelbar und so wenig wie möglich sollte immer rechtskonform sein – hier hilft die ständige Beteiligung des eigenen oder eines externen Datenschutzbeauftragten, die Auffrischung der Datenschutzkenntnisse nach der ab Mai 2018 gültigen Datenschutz-Grundverordnung (DSGVO) sowie eine ständige Sensibilisierung der eigenen Mitarbeiter.
Bei einem unserer Kundenprojekte in einem TK-Unternehmen wurde die Anonymisierung von echten Daten gewählt, da der Datenumfang für eine künstliche Neuerzeugung zu groß war. Einerseits, da die logischen und technischen Möglichkeiten zu komplex waren, um bei einer Neuerzeugung alle Grenzfälle abzudecken – und andererseits, da die Abhängigkeiten zwischen den Daten sehr komplex waren. Beispielsweise sollte nach der Anonymisierung niemand mit einem DSL-Anschluss einen Kabelrouter im Vertrag stehen haben. Die existierenden, tausenden Testfälle sollten weiterhin durchführbar sein.
Dafür wurden bei allen betroffenen Datenfeldern aus mehreren Systemen Abwägungen gemacht, ob eine Anonymisierung rechtlich nötig und technisch umsetzbar war. Das Ziel war, insbesondere auch verzweigte Rückschlüsse zu vermeiden und den Begriff „personenbeziehbar“ sehr sehr streng auszulegen. Besondere Herausforderung hierbei waren Felder, die über die Unternehmensgrenzen hinaus Verwendung fanden, etwa Auftragsnummern bei Drittfirmen, Hardware-Seriennummern in technischen Datenbanken und Telefonnummern aus dem internen Bereich, die in Testfällen über die Systemgrenzen (wie etwa Integrationstests und fachlichen Endnutzertests) auch gültig sein sollten.
Telefon- und Adressdaten mussten „logisch schlüssig sein“ (etwa sollte eine Kölner Telefonnummer auch nach der Anonymisierung mit der Kölner Vorwahl 0221 beginnen), daher war ein einfaches Austauschen aller Zahlen oder ein reines Zufallsverfahren nicht anwendbar.
Da das jahrzehntelang gewachsene System im Hintergrund auch noch viele Redundanzen aufwies, war der Umfang des Projektes dann deutlich größer als Anfangs erwartet. Es wurden sowohl externe Tools als auch interne Lösungen für Grenzfälle verwendet.
Das größte Lob, welches nach solch einem Projekt geäußert werden kann, ist der Satz „Wir haben gar nicht gemerkt, dass sich etwas verändert hat“. Wenn im Hintergrund Adressdaten, Namen und Hardwarelisten, Vertragsnummern und vieles mehr nicht mehr echten Daten entspricht, aber das System dennoch funktioniert – dann wurde dieses Ziel erfolgreich erreicht. Im nächsten Schritt wurden die Möglichkeiten der Automatisierung so weit als möglich ausgeschöpft, da die mehrstufige Anonymisierung mehrmals pro Jahr angewendet werden muss und dabei insbesondere in der Integration in den Betrieb noch kleine Details angepasst werden müssen. Außerdem ist es natürlich notwendig, Neuentwicklungen und Änderungen der Daten mit in die Anonymisierung zu integrieren – so dass das Projekt zwar erfolgreich abgeschlossen wurde, das Thema aber intern weiter begleitet wird.
So wurden und werden nun nach Projektabschluss mehrere Millionen Kundendaten erfolgreich anonymisiert, um den Testern möglichst realistische und dennoch datenschutzrechtlich einwandfreie Testdaten zur Verfügung zu stellen.