Maskierung von Daten für Softwaretests

Softwareentwicklung nur mit Maske
Kommentare

Noch immer werden für Softwaretests Originaldaten verwendet – ein riskantes Vorgehen, weil auch im Bereich der Softwareentwicklung Datenpannen nicht auszuschließen sind. Da realistische Testdaten unverzichtbar sind, führt an einer systematischen Datenmaskierung kein Weg vorbei. Hier müssen Softwarehersteller eine zuverlässige Anonymisierung mit einer strukturellen Übereinstimmung verbinden.

In einer Zeit, in der fast wöchentlich neue gravierende Datenpannen bekannt werden, wächst in der IT die Sensibilität gegenüber sicherheitsrelevanten Themen. So ist im Zusammenhang mit einer Datenpanne bei einem renommierten Finanzdienstleister auch die Verwendung von echten Daten für die Softwareentwicklung wieder in den Fokus der Aufmerksamkeit gerückt. Offenbar ist die Verwendung von Originaldaten, beispielsweise Kunden-, Mitarbeiter- oder Kreditkartendaten bei Design, Programmierung und vor allem beim Test von Applikationen immer noch üblich. Zum Teil werden diese Daten sogar an Dritte weitergegeben, beispielsweise wenn Softwareprojekte von externen Entwicklern oder von Subunternehmen ü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 Softwareentwicklung oder sie werden hier nicht ausreichend wahrgenommen.
Dass viele Unternehmen hier noch nicht über ein ausreichendes Problembewusstsein verfügen, zeigt auch eine 2009 von Micro Focus beim Ponemon Institute in Auftrag gegebene Umfrage unter 1350 Softwareentwicklern 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, von Kreditkarten und andere vertrauliche Informationen verwenden. Fast zwei Drittel rufen diese Daten auf wöchentlicher – und rund 90 Prozent auf monatlicher Basis ab. Drei Viertel gaben zudem an, dass sie Testdaten mit mehr als einem Terabyte Umfang verwenden. Die Verwendung von Originaldaten in der Softwareentwicklung erfolgt also nicht nur gelegentlich, sondern regelmäßig und in großem Umfang.
Bemerkenswert ist auch eine Diskussion, die sich im Anschluss an die Veröffentlichung dieser Umfrage im Web entwickelte: Während die einen meinten, die Verwendung von echten Daten würde überhaupt kein Problem darstellen, weil man die Entwickler eine Vertraulichkeitserklärung unterschreiben lassen könne, meinten andere, alles sei noch viel schlimmer, weil in der Praxis originale Testdaten sogar per E-Mail an Programmierer in Indien geschickt werden würden. Wieder andere vertraten die Auffassung, dass das alles zwar höchst bedenklich sei, es zur Verwendung von Originaldaten in der Softwareentwicklung jedoch gar keine Alternative gäbe, weil nur die echten Daten die zu testenden Strukturen korrekt abbilden könnten.
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 indexbasierten Suche über dieses Feld erlauben. Außerdem lassen sich mit Zufallsdaten nicht die 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 „Xxx“ in Frage.
Dennoch kommt eine Verwendung von Originaldaten für Softwaretests nicht in Betracht – dies würde eine schwerwiegende Verletzung sämtlicher Sicherheitsstandards und der Vertraulichkeit der Daten darstellen. Handelt es sich zudem um personenbezogene Daten, würden außerdem rechtliche Probleme entstehen. Es gilt daher: Originaldaten haben in der Softwareentwicklung definitiv nichts zu suchen, und zwar nicht nur beim Outsourcing von Entwicklungsprojekten, sondern generell.

Maskierung ohne Alternative

Mit der Datenmaskierung – seltener auch als „Anonymisierung“, „Data Masking“, „Obfuscation“ oder „De-Identification“ bezeichnet – steht eine Technologie zur Verfügung, die der Softwareentwicklung Daten liefern kann, die zwar den Originaldaten strukturell entsprechen, die 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 Know-how nicht nur seitens der Softwareentwicklung, sondern auch ein Wissen über die den Daten zugrunde liegenden Geschäftsprozesse. Datenmaskierung „requires not just database specialists, but also business experts, application programmers and testers, as well as security, auditing, and compliance professionals“, so Joseph Feiman von der Gartner-Group. 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:

Irreversibilität: Die maskierten Daten dürfen keinerlei Rückschlüsse auf die Originaldaten erlauben – Reverse Engineering muss ausgeschlossen sein.

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

Maskierungsumfang: Originaldaten, die zuverlässig keine Rückschlüsse auf die Ausgangsdaten erlauben – z. B. ein Orts- und Straßenverzeichnis – bleiben in der Regel unmaskiert. Es muss aber sichergestellt sein, dass keine indirekten Rückschlüsse möglich sind, beispielsweise aus der Verteilung der Daten. Werden z. B. nur Namen und Personalnummern maskiert, so lässt sich aus einer Gehaltstabelle 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 beispielsweise 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 große Datenvolumina generiert werden können. Außerdem wird auf diese Weise sichergestellt, dass öfter benötigte Testdaten auch in der Praxis den strengen Sicherheitsregeln genügen – ist die Maskierung hingegen aufwändig, besteht die Versuchung, Ad-hoc-Testdaten zu bilden.

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

Aufmacherbild: Internet crime technology security concept with digital binary code von Shutterstock / Urheberrecht: Lightspring

[ header = Datenmaskierung in der Praxis]

Datenmaskierung in der Praxis

Wie die Datenmaskierung in der Praxis aussieht, zeigen die folgenden Beispiele. Das Maskieren einzelner, unabhängiger Datensätze ist im Allgemeinen technisch unproblematisch (Tabelle 1).

Originaldaten

Maskierte Daten

Frank Virtuseher

Trabantenallee 254

80354 München

Deutschland

Geburtstag: 13.7.1967

Tobias Müller

Lieschenweg 4

80336 München

Deutschland

Geburtstag: 27.2.1967

Tabelle 1: Ein maskierter Datensatz

Aber auch in einem solchen einfachen Fall muss sichergestellt werden, dass die maskierten Daten realistisch sind und die Originaldaten möglichst gut repräsentieren. Im Beispiel wurde daher nicht maskiert:

  • Geburtsjahr: Altersverteilungen sind für die Datenstruktur häufig relevant, denn ein 60-jähriger Kunde wird vermutlich eine andere Kundenhistorie haben als ein 18-jähriger – bei Versicherungssoftware wird man das Geburtsdatum sogar noch genauer erhalten müssen.
  • Wohnort und Land: Die geografische Verteilung ist ebenfalls ein wichtiges Strukturelement – alternativ lässt sich der Wohnort maskieren, jedoch muss der maskierte Wohnort in gleicher Region liegen. Auch hier ist je nach Art der zu maskierenden Daten die Beibehaltung der originalen Verteilung wichtig. Bei der Postleitzahl muss wiederum sichergestellt werden, dass auch das maskierte Feld weiterhin eine gültige Postleitzahl enthält.
  • Geschlecht: Das aus dem Originalnamen ablesbare Geschlecht bleibt ebenfalls erhalten – aus Frank kann Tobias werden, aber nicht Karin.

Diese Zuordnungen können auch zu diffizilen Bewertungsproblemen führen, wenn beispielsweise aus Namen ethnische Zugehörigkeiten zu erschließen 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 sehr einfaches Beispiel in Tabelle 2.

Originaldaten

Maskierte Daten

Kunden-Stammdaten:

Kunden-ID: KU67_25432_1

Frank Virtuseher

Trabantenallee 254

80354 München

Deutschland

Geburtstag: 13.7.1967

 

Bankkonto #1:

Kunden-ID: KU67_25432_1

Konto-ID: KO67_222312_125

Girokonto

Währung: €

Dispo-Limit: 5.000

Dispozins: 12,5 %

Konto: 123423900

BLZ: 400200700

 

Bankkonto #2:

Kunden-ID: KU67_25432_1

Konto-ID: KO67_128732_143

Sparkonto

Währung: €

Dispo-Limit: 0

Dispozins: 0 %

Konto: 645926300

BLZ: 400200750

Kunden-Stammdaten:

Kunden-ID: KU67_12976_2

Tobias Müller

Lieschenweg 4

83453 München

Deutschland

Geburtstag: 27.2.1967

 

Bankkonto #1:

Kunden-ID: KU67_12976_2

Konto-ID: KO67_654382_321

Girokonto

Währung: €

Dispo-Limit: 4.000

Dispozins: 15,5 %

Konto: 634528470

BLZ: 400200700

 

Bankkonto #2:

Kunden-ID: KU67_12976_2

Konto-ID: KO67_227643_072

Sparkonto

Währung: €

Dispo-Limit: 0

Dispozins: 0 %

Konto: 765234910

BLZ: 400200750

Tabelle 2: Wechselseitige Abhängigkeiten in Datensätzen

Kontostand und Kontobewegungen der beiden Konten können in weiteren untergeordneten Datensätzen dargestellt werden. Die Besonderheiten in diesem Beispiel sind:

  • 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 die beiden Konten, mit dem gleichen maskierten Wert ersetzt werden.
  • Logische Regeln: Es kann sein, dass der Dispozins 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 das Limit und Zinssatz gerade nicht durch einen zufälligen anderen Wert ersetzen.
  • Regel zur Erzeugung von neuen Werten: Im obigen Beispiel enthalten die eineindeutigen IDs auch das Geburtsjahr (67) – maskierte Ersetzungswerte müssen daher dieselbe Regel verwenden und dürfen nicht einfach eine Zufallszahlenfolge einsetzen.
Micro Focus Data Express

Mit Data Express stellt Micro Focus den Entwicklern ein Werkzeug zur Verfügung, mit dem sie für Testzwecke umfangreiche Subsets aus großen Datenbeständen bilden können. Data Express erzeugt automatisch Testdaten, die die Struktur der Originaldaten abbilden, verändert sie zugleich aber so, dass keine Rückschlüsse auf die ursprünglichen Daten möglich sind. Die von Data Express verwendeten Regeln für die Maskierung der Daten lassen sich entsprechend der jeweiligen Compliance-Anforderungen anpassen. Durch den Einsatz von Data Express können Unternehmen ihre Softwaretests deutlich verbessern, ohne dabei gegen Datenschutzrichtlinien zu verstoßen. Durch die Reduzierung der notwendigen Testdaten auf etwa zehn Prozent der Originaldaten werden zudem das Management der Daten vereinfacht und die Dauer von Tests verringert sowie die Kosten drastisch gesenkt. Data Express kann auf Großrechnern sowie auf verteilten Systemen wie Windows, Unix oder Linux eingesetzt werden.

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 aufwändig erscheinen, auch wenn die für die Datenmaskierung zur Verfügung stehenden Werkzeuge, wie etwa Data Express von Micro Focus, dem Tester wieder 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 ist wiederum unzulässig. Nur zur Erinnerung: Datenpannen sind nicht nur unangenehm und ärgerlich. Sie können auch richtig teuer werden – die Kosten für abhandengekommene oder gestohlene Daten wurden in den USA auf rund 200 Dollar geschätzt – pro Datensatz.

Links & Literatur

[1] Data Masking Best Practices – Gartner RAS Core Research Note G00165705
[2] Data-breach Costs Rising, Study Finds, networkworld.com
[3] The Five Laws of Data Masking, Securiosis
[4] Data Privacy and Compliance, Micro Focus
[5] Productive and Secure Application Testing, Micro Focus
[6] Why Data Security for Non-Production Computer Systems is Important, ITSecurityJournal.com

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -