Datenverarbeitende Software testet man mit Daten. In den meisten Testumgebungen dürfen Tester nicht mit Produktionsdaten arbeiten, darum verwenden sie meistens einen Datensatz, der speziell zu Testzwecken erstellt wurde. Hier besteht ein Spannungsfeld zwischen Brauchbarkeit und Sicherheit. Je realistischer die Testdaten, desto eher verhält sich die Software beim Testen wie in einer Produktionsumgebung, aber auch desto grösser ist das Risiko, dass der Testsatz Daten enthüllt, die nicht in eine Testumgebung gehören.

Wie macht man einen realistischen und doch sicheren Testsatz? Wie geht man mit kommerziell sensiblen Daten um? Und wie mit datenschutzsensiblen Informationen? Sind Sie gerade dabei, Testdaten zu erstellen oder möchten Sie wissen, wie Data eXcellence damit umgeht, dann lesen Sie bitte weiter.

Einleitung

Organisationen, die Daten speichern und verarbeiten, treffen Maßnahmen, um die Sicherheit ihrer sensiblen Daten zu garantieren. Sensible Daten sind Daten, die strategisch oder kommerziell datenschutzsensibel sind. Im letzten Fall formuliert die DSGVO die Anforderungen an die Erfassung und Verarbeitung personenbezogener Daten (siehe https://www.eugdpr.org/ und https://hulpbijprivacy.nl/).

Die Sicherheit von sensiblen Daten fordert eine Zugriffsbeschränkung und eine genaue Administration für alle Systeme, in denen Benutzer mit diesen Daten arbeiten. Dadurch werden Daten beispielsweise nur für eine ausgewählte Gruppe von Mitarbeitern in einer abgeschirmten Umgebung zugänglich, wobei das System jede Aktion wie das Konsultieren, Bearbeiten und Löschen, protokolliert.

In einem Entwicklungsumfeld sind solche Maßnahmen teuer und erschweren die Arbeit. Aus diesem Grund verwenden Entwickler und Tester der Datenverarbeitungssoftware sogenannte Testdaten. Das sind Daten, die – versehentlich „auf der Straße" gelandet – keine Datenschutzprobleme verursachen, keine Betriebsgeheinisse enthüllen und der Organisation keinen Imageschaden zufügen können.

Testdaten kann man erzeugen, indem fiktive Daten in das System eingegeben werden, mit dem getestet werden soll. Diese Methode hat jedoch ihre Nachteile:

  • Verunreinigung: Der Ansatz funktioniert nur, wenn eine separate Umgebung verfügbar ist (Applikationen, Datenbank), wo Testdaten eingegeben werden können, sonst wird das System durch andere Daten „verunreinigt“.
  • Zeitraubend. Die Eingabe eines Testsatzes von größerem Umfang ist zeitraubend.
  • Arbeitsintensiv. Die Eingabe eines realistischen Verlaufs ist arbeitsintensiv. Zum Beispiel Hypothekarkredite oder Altersvorsorgen, die seit Jahren laufen (oder gerade beendigt wurden), inklusive Transaktionsverlauf. Oder etwa in der Vergangenheit stattgefundene Zinsänderungen.
  • Unzureichende Variation.Es ist schwierig, dem Portfolio genügend Variationen hinzuzufügen. Es sollte von allen „Geschmacksrichtungen" ein Beispiel gesetzt werden.
  • Alterung. Ein Testsatz altert schnell.
  • Manchmal nicht möglich. Im Falle von Datenkonvertierungen ist die beabsichtigte Zielumgebung oft noch unvollständig, wodurch das Eingeben von Testdaten nicht oder nur in begrenztem Umfang möglich ist.

Dieser Artikel befasst sich mit dem Anonymisieren von Daten: dem Bearbeiten von vorhandenen Produktionsdaten auf derartige Weise, dass Entwickler und Tester in einer nicht gesicherten Umgebung damit arbeiten dürfen. Dann sprechen wir von strukturierten Daten in Datenbanken. Unstrukturierte Daten als PDF-Dateien, Scans oder Dokumente werden in diesem Artikel nicht berücksichtigt.

Bei Datenkonvertierungen wird die Anonymisierung von Daten aus den Quellsystemen durchgeführt. Durch die Anonymisierung eines solchen Datensatzes und dem anschließenden ‚Füttern‘ der Konvertierungssoftware mit den anonymen Daten, wird ein anonymer Testsatz im Format des Zielsystems erstellt:

Im Folgenden gehe ich zunächst auf die Anonymisierung von strategisch oder kommerziell sensiblen Daten ein. Hier gebe ich Tipps, wie man einen Testsatz macht, der genügend Variationen aufweist, ohne dass sensible Informationen preisgegeben werden.

Als nächstes werde ich auf die Anonymisierung datenschutzsensibler Daten eingehen. Hier geht es vor allem über die Balance zwischen Realismus und Sicherheit.

Anonymisierung von strategisch oder kommerziell sensiblen Daten

Unter “strategischer oder kommerzieller Sensibilität” verstehen wir Daten, die für sich alleine unschuldig scheinen, die jedoch in ihrer Gesamtheit wichtige Informationen über die Organisation preisgeben: wie viele Kunden hat die Organisation, wie hoch ist das gesamt investierte Kapital, wie hoch ist der Deckungsgrad von Sicherheiten, welche Produkte verkauft die Organisation, wie ist der Finanzrahmen aufgeteilt, wieviel Provision erhält eine Zwischenperson, welche Gewinnspanne hat ein Produkt, usw.

Die strategische oder kommerzielle Sensibilität von Daten kann auf effektive Weise aufgehoben werden, indem eine Selektion vorgenommen wird: aus der gesamten Datensammlung wird ein Teilsatz zusammengestellt. Dieser Teilsatz enthält eine große Streuung der gemeinsamen Werte, aber die Zusammensetzung des originalen Satzes lässt sich nicht daraus ableiten.

Wie wird eine Selektion vorgenommen?

Das Erstellen eines Testsatzes mit größtmöglicher Variation bei einer so klein wie möglichen Datenmenge kann komplex sein. Oft genügt die folgende Vorgehensweise:

  1. Bestimmen Sie zwei oder drei Eigenschaften, die für die Variation des Datensatzes wichtig sind (beispielsweise die Art der Deckung bei einer Versicherung, der Produkttyp bei einem Sparprodukt, die Art der Hypothekrückzahlung). Analysieren Sie, welche Erscheinungsformen von diesen Eigenschaften im Datensatz vorhanden sind (zum Beispiel bei der Eigenschaft: Art der Hypothekrückzahlung: jährlich, linear, tilgungsfrei, sparen, anlegen).  
  2. Stellen Sie fest, welche Entität die zentrale Entität im Datensatz ist. In einer Hypothekenadministration würde dies zum Beispiel ein Darlehen sein, in einer Kundenadministration der Kunde. Das wird als Hauptentität bezeichnet.
  3. Selektieren Sie willkürlich eine Reihe von Vorkommnissen von dieser Hauptentität für jede Eigenschaft, die unter Punkt 1 definiert ist. Achten Sie darauf, dass von jeder dieser Eigenschaften alle Varianten vorhanden sind. Zum erwähnten Vorbild der Hypothekenrückzahlung: Selektieren Sie willkürlich Darlehen, sodass alle Rückzahlungsarten - jährlich, linear, tilgungsfrei, sparen und anlegen – vorkommen. Die Wahl der Anzahl der Vorkommnisse der Hauptentität ist von der Variation im gesamten Datensatz abhängig. Ein guter Ausgangspunkt ist 500 bis 1000 Stück.
  4. Machen Sie den Datensatz konsistent. Wählen Sie aus allen Tabellen jene Daten, die zu den selektierten Hauptentitäten gehören. Zum Beispiel: Aus dem gesamten Satz an Buchungen werden nur jene Buchungen selektiert, die zu einer selektierten Hauptentität gehören. Auf diese Weise wird der konsistente Datensatz mit einer großen Variation an Eigenschaften gewählt, worin die strategisch oder kommerziell sensiblen Informationen nicht mehr gefunden werden können.

Später können dann noch spezifische Daten hinzugefügt oder entfernt werden, wenn dies für Testzwecke erforderlich ist. Die Selektion wird also langsam, aber stetig verbessert. Man kann zum Beispiel fehlerhafte Werte, die in den Produktionsdaten vorhanden sind, bewusst in die Selektion aufnehmen und testen, ob die Software mit diesen Fehlern umgehen kann.

Führen Sie die Selektion regelmäßig erneut aus, damit der Testsatz immer auf aktuellen Produktionsdaten basiert. Es ist wichtig, dass die Testdaten gänzlich automatisiert werden. Dadurch kann der Testsatz nach Bedürfnis erstellt werden – manuell oder im Rahmen eines automatisierten Tests.

Data eXcellence verwendet für die Durchführung der Selektion ihre eigene Software. Diese Software selektiert eine minimale Datenmenge mit einer maximalen Variation für die konfigurierten Eigenschaften.

Anonymisieren von datenschutzsensiblen Daten

Datenelemente, die auf bestimmte Personen oder Organisationen zurückgeführt werden können, dürfen nicht in die Hände von Unbefugten geraten. Daher ersetzt man solche Elemente durch andere willkürliche Daten.

Welche Datenelemente müssen substituiert werden?

Ein Datenelement muss dann substituiert werden, wenn dieses Datenelement allein oder in Kombination mit anderen Daten jene Personen oder Organisationen preisgibt, die sich in der Administration befinden.

Je weniger Elemente substituiert werden, desto realistischer wird sich der Datensatz verhalten, wodurch die Testzwecke brauchbarer werden. Im Gegensatz dazu führt eine geringe Substitution zu Sicherheitsrisiken. Diese Überlegung wird gemeinsam mit dem Dateneigentümer durchgeführt. Als Faustregel gilt: ersetze all jene Elemente, die ein Risiko darstellen, aber nicht mehr.

WENIG SUBSTITUIEREN

+ Erhöhte Brauchbarkeit der Datensätze
- Unsicher

VIEL SUBSTITUIEREN

+ Sicher
- Datensatz weniger brauchbar oder sogar völlig unbrauchbar

Zu viel Substitution kann zu einem unbrauchbaren Datensatz führen. Die Daten werden untereinander inkonsistent oder entsprechen nicht mehr den Erfordernissen des für sie bestimmten Systems: jemand mit einem Jugendsparkonto, das laut anonymisiertem Geburtsdatum 60 Jahre alt ist oder ein Darlehen, das laut anonymisiertem Eingangsdatum drei Jahre läuft, aber einen Transaktionsverlauf von 20 Jahren aufweist. Deshalb ist es wichtig, um pro Datenelement sorgfältig abzuschätzen, ob eine Substitution nötig ist oder nicht.

Data eXcellence verwendet eine eigen Software, die in Datenbanken gewisse Muster als Kreditkarten-, IBAN-, Sozialversicherungs- oder Kontonummer erkennt. Das ist bei der Bestimmung der Liste mit den zu ersetzenden Datenelementen sehr hilfreich. Auf dieser Liste kommen die folgenden Elemente fast immer vor:

  • Nachname
  • Straßenname
  • Postleitzahl
  • Wohnort
  • Anmerkungen (die häufig datenschutzsensible Notizen enthalten: Telefonnummern, E-Mail-Adressen, Namen der Partner, Kontonummern usw.)
  • Beschreibung einer Transaktion oder Zahlung
  • Sozialversicherungsnummer
  • Firmenname
  • Handelskammernummer
  • IBAN oder Kontonummer
  • Kreditkartennummer

(Informationen finden Sie auch hier: https://en.wikipedia.org/wiki/Personally_identifiable_information)

Die folgenden Element müssen nicht unbedingt ersetzt werden:

  • Geburtsdatum (jeden Tag werden in den Niederlanden hunderte Menschen geboren – durch ein Datum kann eine spezielle Person nicht hergeleitet werden)
  • Sterbedatum (idem)
  • Hausnummernzusatz
  • Infix
  • Anrede
  • Geschlecht
  • Titel (ausgenommen, er führt zu einer spezifischen Person)
  • Daten oder Transaktionen finanzieller und operationeller Natur, die nicht zu einer natürlichen Person oder Organisation rückzuführen sind: Beträge, Prozentsätze, Transaktionsarten
  • Unterstützende Daten, die benötigt werden, damit das System funktioniert.

Zu besprechen sind Datenelemente, die theoretisch zu einem Datenschutzproblem werden können:

  • Vorname: ein seltener Vorname könnte erkennbar sein, in der Praxis kann nur der Vorname nicht  auf eine bestimmte natürliche Person zurückführen
  • Initialen: eine seltene Kombination von Initialen kann erkennbar sein, allerdings ist es zweifelhaft, ob dies wirklich geschieht.
  • Haunummer: es gibt exotische Nummern, die nicht oft vorkommen, die Frage bleibt, ob so eine Hausnummer ohne weitere Adressdaten wirklich zu einer spezifischen Adresse zurückzuführen ist.

Die Bedeutung eines Elements bestimmt, ob eine Substitution nötig ist oder nicht. Eine Kreditnummer kann in dem einen System ein bedeutungsloser technischer Schlüssel sein (Substitution nicht erforderlich) und in einem anderen System eine Konto- oder IBAN-Nummer (Substitution erforderlich).

Weiters gibt es Daten, die, abhängig von der Rolle im System ersetzt oder nicht ersetzt werden müssen. Die Daten eines Notariats, das bei einer Bank ein Geschäftsdarlehen hat, müssen anonymisiert werden (das Notariat ist ein Kunde). Wenn aber ein Notariat Urkunden erstellt oder Hypotheken übergibt, ist es nicht nötig, die entsprechenden Daten zu anonymisieren. Schließlich ist es kein Geheimnis, dass ein Notar derartige Aktivitäten ausführt (das Notariat ist ein dienstausführender Dritter).

Anonymisierungsvereinbarung

Die Anonymisierungsvereinbarung legt fest, welche Datenelemente anonymisiert werden. Es handelt sich um eine Festlegung des oben beschriebenen Prozesses. Werden die Vereinbarungen später verändert, dann wird auch dies festgelegt. Auf diese Weise ist immer deutlich, wie die aktuellen Vereinbarungen lauten.

Die Anonymisierungssoftware erstellt einen Bericht, der die anonymisierten Elemente enthält. Dieser Bericht dient als Beweis, dass die Anonymisierung wie vereinbart ausgeführt wurde.

Auf welche Weise werden Daten substituiert?

Je „ordentlicher” die Daten ersetzt werden, desto realistischer ist das Ergebnis.  Grundsätzlich können Sie jedes alphanumerische Datum durch eine willkürliche Buchstabenfolge ersetzen, allerdings kann das die Brauchbarkeit des Testsatzes herabsetzen: wenn alle Namen, Adressen etc. aussehen wie „Test” oder „xxxx”, dann sind einzelne Daten kaum erkennbar, was das Testen erschwert. Auf der anderen Seite: wenn Daten sehr realistisch ersetzt werden, dann ist es schwierig zu erkennen, ob es sich um anonymisierte Daten handelt oder nicht. Vielleicht arbeiten dann die Tester aus Versehen doch mit den Produktionsdaten.

Eine gute Lösung besteht darin, die Daten durch ähnliche Daten zu ersetzen, die jedoch sofort als Testdaten zu erkennen sind. Zum Beispiel: in einem Datensatz eines niederländischen Kreditgebers kann man alle Namen durch englische Namen und alle Ortsnamen durch ausländische Städtenamen ersetzen.

Schlüsselwerte bekommen eine Spezialbehandlung. Um die referenzielle Integrität des anonymen Satzes zu gewährleisten, ersetzt man gleiche Werte im gesamten Datensatz durch dieselben anonymen Werte. Zum Beispiel: wenn die Kreditnummer 123456 in einer bestimmten Tabelle durch 100001 ersetzt wird, muss die Kreditnummer 123456 auch in allen anderen Tabellen, wo dieser Wert vorkommt, durch 100001 ersetzt werden.

Schließlich muss man die möglichen Datenqualitätsanforderungen des Systems berücksichtigen, wofür der Testsatz bestimmt ist. Viele Systeme kontrollieren das Format bestimmter Felder. Beispiele dafür sind eine niederländische Postleitzahl, Sozialversicherung und IBAN. Wenn solche Kontrollen durchgeführt werden, müssen die ersetzten Daten den Regeln entsprechen.

Welche Software steht zur Verfügung?

Für die Durchführung der Substitution stehen mehrere Softwarepakete zur Verfügung.
Data eXcellence verwendet für diesen Zweck den SQL Data Generator von Red Gate (https://www.redgate.com/products/sql-development/sql-data-generator/index) sowie Privacy von Datprof (https://www.datprof.com). Eine weitere bekannte Lösung bietet ARX (http://arx.deidentifier.org/). Wer auch nur kurz sucht wird entdecken, dass die Auswahl sehr groß ist.

Schlussfolgerung

Durch Anonymisierung werden die Produktionsdaten aus einem Datensatz zu leicht nutzbaren Testdaten. Anhand der Beispiele und Verweisungen in diesem Artikel kann jeder sofort loslegen. Es lohnt sich, einmalig in einen automatisierten Prozess zu investieren – und diesen Prozess regelmäßig durchzuführen. Dadurch bleibt der Testsatz auf dem neuesten Stand und spiegelt damit die Realität wider. Protokollieren Sie gründlich die Vereinbarungen mit dem Eigentümer der Daten.

Mehr erfahren?

Kontakt DX