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.

«Naturidentisches» Datenmaterial

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.