Software testen nur mit Maske

Morten Rohlfes ist Director Testing Modernization bei Micro Focus in Ismaning bei München

Mit jeder bekannt gewordenen Datenpanne wächst in der IT die Sensibilität für sicherheitsrelevante Themen. Offenbar ist die Verwendung von Originaldaten, beispielsweise Kunden-, Mitarbeiter- oder Kreditkartendaten, bei Design, Programmierung und vor allem beim Testen von Applikationen immer noch üblich - selbst bei Banken. Zum Teil werden diese Daten sogar an Dritte weitergegeben - per E-Mail nach Indien beispielsweise - wenn Software-Projekte von externen Entwicklern oder von Sub-Unternehmen übernommen werden.

Vielen Unternehmen scheint gar nicht bewusst zu sein, dass sie so dem Missbrauch der vertraulichen Daten Vorschub leisten. Dabei sind Testdaten besonders gefährdet, nicht zuletzt, weil sie nicht den im operativen Betrieb geltenden Sicherheitsmechanismen unterliegen. Mitunter erstrecken sich die entsprechenden Compliance-Richtlinien auch nicht auf die Software-Entwicklung oder sie werden hier nicht ausreichend wahrgenommen.

Dass viele Unternehmen hier noch nicht über ein ausreichendes Problembewusstsein verfügen, zeigt eine 2009 von Micro Focus beim Ponemon Institute in Auftrag gegebene Umfrage unter 1350 Software-Entwicklern und -Testern: Rund 70 Prozent der Befragten erklärten, sie würden für die Entwicklung und das Testen von Software echte Daten von Kunden, Mitarbeitern, Kreditkarten und andere vertrauliche Informationen verwenden. Fast zwei Drittel rufen diese Daten auf wöchentlicher, rund 90 Prozent auf monatlicher Basis ab. Drei Viertel gaben zudem an, dass sie Testdaten mit mehr als einem Terabyte Umfang verwenden.

Es liegt zwar auf der Hand, dass Software weder mit zufallsgenerierten noch mit verschlüsselten Daten sinnvoll getestet werden kann; eine Postleitzahl, die «9999» oder «4X#Q2» lautet, würde beispielsweise keine Rückschlüsse auf das Laufzeitverhalten einer Index-basierten Suche über dieses Feld erlauben. Ausserdem lassen sich mit Zufallsdaten auch keine sachlichen Zusammenhänge der Daten abbilden: Die PLZ muss beispielsweise auf eine Tabelle mit Ortsnamen verweisen - da käme in diesem Fall nur die Stadt «Xxxxxxxx» in Frage. Dennoch kommt eine Verwendung von Originaldaten für Software-Tests nicht in Frage. Dies stellt eine schwerwiegende Verletzung sämtlicher Sicherheitsstandards und der Vertraulichkeit der Daten dar.

Handelt es sich zudem um personenbezogene Daten, entstehen ausserdem auch noch rechtliche Probleme. Es gilt daher: Originaldaten haben in der Software-Entwicklung definitiv nichts zu suchen - nicht nur beim Outsourcing von Entwicklungsprojekten, sondern generell.

Mit der Datenmaskierung - auch als Anonymisierung, Data Masking, Obfuscation oder De-Identification bezeichnet - steht eine Technologie zur Verfügung, die der Software-Entwicklung Daten liefern kann, die zwar den Originaldaten strukturell entsprechen, aber dennoch keine Rückschlüsse auf die echten Daten erlauben. Die Maskierung von Daten ist allerdings nicht trivial. Denn: Was jeweils strukturell relevant ist, hängt von der jeweiligen Anwendung, von den funktionellen Zusammenhängen und den abgebildeten Prozessen ab. Die Datenmaskierung erfordert daher nicht nur Know-how in der Software-Entwicklung, sondern auch ein Wissen über die den Daten zugrunde liegenden Geschäftsprozesse. Klar ist aber auch: Datenmaskierung kann nicht per Mausklick funktionieren, denn es müssen stets die für die jeweilige Anwendung relevanten Strukturen identifiziert werden.

Eine sichere und dennoch funktionelle Datenmaskierung muss dabei folgende Anforderungen erfüllen:

Irreversibel: Die maskierten Daten dürfen keinerlei Rückschlüsse auf die Originaldaten erlauben; Reverse Engineering muss ausgeschlossen sein.

Repräsentativ: Die maskierten Daten müssen die Strukturen und Zusammenhänge der echten Daten wiedergeben. So sind zwar echte Namen durch fingierte Namen zu ersetzen, diese müssen aber immer noch als Namen erkennbar sein. Gleiches gilt für Altersangaben, Sozialversicherungsnummern,
Rechnungsbeträge, Zinssätze etc. Dabei ist £beispielsweise je nach Aufgabenstellung auch die Altersverteilung der Ausgangsdaten oder deren geografische Verteilung zu berücksichtigen. Welche Kriterien jeweils relevant sind, muss mit den zuständigen Fachabteilungen diskutiert werden.

Referentielle Integrität: Die maskierten Daten müssen die referentielle Integrität der Datentabellen korrekt widerspiegeln. Wird in einer Datenbank beispielsweise eine Kreditkartennummer als primärer Schlüssel verwendet, so muss dieser in maskierter Form auch in den zugeordneten Tabellen verwendet werden.

Maskierungsumfang: Originaldaten, die zuverlässig keine Rückschlüsse auf die Ausgangsdaten erlauben - zum Beispiel Orts- und Strassenverzeichnis - bleiben in der Regel unmaskiert. Es muss aber sicher-gestellt sein, dass keine indirekten Rückschlüsse möglich sind, etwa aus der Verteilung der Daten. Werden beispielsweise nur Namen und Personalnummern maskiert, so lässt sich aus einer Gehalts-tabelle leicht herauslesen, wer der Geschäftsführer ist und über ein gemeinsames Schlüsselfeld in der Folge auch alle unmaskierten Informationen zu diesem Datensatz.

Wiederholbarkeit: Die Maskierung der Daten muss reproduzierbar sein; nur so lassen sich Vergleiche im Laufzeitverhalten der Daten zu unterschiedlichen Zeitpunkten durchführen.

Automatismus: Sind die Anforderungen einmal definiert, müssen sich die maskierten Daten mit den entsprechenden Tools automatisch erzeugen lassen, sodass auch beliebig grosse Datenvolumina generiert werden können. Ausserdem ist auf diese Weise sichergestellt, dass öfter benötigte Testdaten auch in der Praxis den strengen Sicherheitsregeln genügen. Ist die Maskierung hingegen aufwendig, besteht die Versuchung, Ad-hoc-Testdaten zu bilden.

Wenn sich Unternehmen bei der Erstellung von Testdaten an diese Regeln halten, bewegen sie sich grundsätzlich auf der sicheren Seite.

Die Beispiele zeigen, dass die Kunst der Maskierung darin besteht, den Zufall richtig zu kanalisieren, sodass er die richtige Struktur mit fiktiven Daten möglichst exakt nachbildet. Das mag auf den ersten Blick aufwendig erscheinen, auch wenn die für die Datenmaskierung zur Verfügung stehenden Werkzeuge, etwa Data Express von Micro Focus, dem Tester viel Arbeit abnehmen. Allerdings gibt es zur Datenmaskierung gar keine Alternative: Testen ohne Daten ist nicht möglich, Testen mit unstrukturierten Zufallsdaten sinnlos, Testen mit echten Daten wiederum unzulässig. Nur zur Erinnerung: Datenpannen sind nicht nur unangenehm und ärgerlich. Sie können auch richtig teuer werden: Die Kosten für abhanden gekommene oder gestohlene Daten wurden in einer Studie von Ponemon und PGP in den USA auf rund 200 Dollar geschätzt - pro Datensatz!

Datenmaskierung in der Praxis

Die maskierten Daten müssen realistisch sein und das Original möglichst gut repräsentieren, zum Beispiel:

Originale Daten
Frank Virtuseher
Trabantenallee 254
8053 Zürich
Schweiz
Geburtsdatum: 13.7.1967

Maskierte Daten
Tobias Müller
Lieschenweg 4
8032 Zürich
Schweiz
Geburtsdatum: 27.2.1967

Nicht maskiert wurden hier:

- Geburtsjahr: Altersverteilungen sind für die Datenstruktur oft relevant: Ein 60-Jähriger wird eine andere Kundenhistorie haben als ein 18-Jähriger; bei Versicherungs-Software muss das Geburtsdatum noch genauer sein.

- Wohnort und Land: Die geografische Verteilung ist ein wichtiges Strukturelement; alternativ lässt sich der Wohnort maskieren, jedoch muss er in der gleichen Region liegen. Auch hier ist je nach Art der zu maskierenden Daten die Beibehaltung der originalen Verteilung wichtig. Bei der Postleitzahl ist wichtig, dass auch das maskierte Feld eine gültige Postleitzahl enthält.

- Geschlecht: Das aus dem Namen ablesbare Geschlecht bleibt erhalten - aus Frank kann Tobias werden, aber nicht Karin. Diese Zuordnungen können zu diffizilen Bewertungsproblemen führen, wenn beispielsweise aus Namen ethnische Zugehörigkeiten zu erschliessen sind. In der Realität sind die zu maskierenden Daten meist viel komplexer strukturiert, vor allem hinsichtlich der wechselseitigen Abhängigkeiten von Datensätzen. Dazu wieder ein einfaches Beispiel:

Originale Daten

Bankkonto Nummer 1:
Kunden-ID: KU67_25432_1
Konto-ID: KO67_222312_125
Girokonto
Währung: EUR
Dispo-Limit: 5000
Dispo-Zins: 12,5%
Konto: 123423900
BLZ: 400200700

Bankkonto Nummer 2:
Kunden-ID: KU67_25432_1
Konto-ID: KO67_128732_143
Sparkonto
Währung: EUR
Dispo-Limit: 0
Dispo-Zins: 0%
Konto: 645926300
BLZ: 400200750

Maskierte Daten

Bankkonto Nummer 1:
Kunden-ID: U67_12976_2
Konto-ID: KO67_654382_321
Girokonto
Währung: EUR
Dispo-Limit: 4000
Dispo-Zins: 15,5%
Konto: 634528470
BLZ: 400200700

Bankkonto Nummer 2:
Kunden-ID: KU67_12976_2
Konto-ID: KO67_227643_072
Sparkonto
Währung: EUR
Dispo-Limit: 0
Dispo-Zins: 0%
Konto: 765234910
BLZ: 400200750

Die Besonderheiten:

Konstante IDs: Verwendet die interne Datenhaltung der Bank eindeutige IDs, so sind diese unbedingt zu maskieren; es müssen jedoch alle abhängigen Datensätze, also beide Konten, mit dem gleichen maskierten Wert ersetzt werden.

Logische Regeln: Es kann sein, dass der Dispo-Zins und das Limit maskiert werden, sofern ein solches Limit vorhanden ist wie hier beim Girokonto. Bei einem Sparkonto ohne Überziehungsmöglichkeit dürfte man jedoch Limit und Zinssatz gerade nicht durch einen zufälligen anderen Wert ersetzen.

Regel zur Erzeugung von neuen Werten: In obigem Beispiel enthalten die eindeutigen IDs auch das Geburtsjahr (67); maskierte Ersetzungswerte müssen daher die selbe Regel verwenden und dürfen nicht einfach eine Zufallszahlenfolge einsetzen.