Metafinanz Data Masking

Viele Unternehmen unterschätzen die Risiken von Softwaretests und Data Mining: Oft kommen hier ungeschützte Geschäftsdaten zum Einsatz, und meist wandern diese sogar in ferne Ländern zum Outsourcing-Partner. Dabei lassen sich solche enormen Geschäfts- und Datenschutzrisiken einfach beseitigen – durch Verschleierung mittels Data-Masking-Tools.

ufsehenerregende Datenschutzskandale häufen sich in jüngster Zeit – ob es um die Kunden-CD der Telekom ging, die Kreditkartendaten der Citigroup oder den Angriff auf Sonys Playstation-Netzwerk. Für Großkonzerne kann der daraus entstehende Schaden enorm sein. Zum einen drohen vielfältige Kosten von der Fehlerbehebung über Kundenentschädigungen bis zu möglichen Strafzahlungen. Aber auch der längerfristige Reputationsverlust dürfte sich auf Dauer in den Bilanzen niederschlagen. Neben solchen weitgehend bekannten Datenschutzrisiken existieren aber auch bis heute unterschätzte Angriffsflächen, über die viele Unternehmen empfindlich getroffen werden können: So gilt als immer noch weitgehend unbekannt, dass beim Software-Testing und Data Mining immer noch überwiegend ungeschützte Unternehmensdaten zum Einsatz kommen.

Geschäftsanwendungen müssen vor ihrer Einführung auf Herz und Nieren geprüft werden, bevor sie bei hunderten oder tausenden Mitarbeitern in den Live-Betrieb übergeben werden können. Damit diese Tests unter realistischen Bedingungen ablaufen, verwenden Entwickler und Tester am liebsten echte Kundendaten und Geschäftszahlen – und erhalten diese auch erstaunlich oft von der IT. So fand das Ponemon-Institut bereits vor einigen Jahren in einer Studie heraus, dass drei Viertel aller deutschen Unternehmen ihre Kundendaten für Testzwecke missbrauchen. Zum Einsatz kommen dabei alle Arten von sensiblen Informationen wie Kunden- und Kreditkartennummern, Angaben zur Sozialversicherung, Zahlungsinformationen sowie Daten von Mitarbeitern und Lieferanten. Erschwerend kommt hinzu, dass etwa 60 Prozent dieser Tests von Outsourcing-Partnern durchgeführt werden, wobei die ungeschützten Daten an externe Standorte wandern. Für die Partnerunternehmen bleibt übrigens das Risiko recht gering, denn auch bei externer Vergabe haftet der Auftraggeber vollständig.

Aber selbst wenn die ungeschützten Datenbanken nur innerhalb der Unternehmensmauern verwendet werden, lauern etliche Gefahren bei einem laxen Umgang mit Produktionsdaten. So landen etwa Dumps von Datenbanken erfahrungsgemäß recht oft auf persönlichen Laufwerken oder den lokalen Festplatten der Mitarbeiter und nicht selten verlassen sie per Laptop schließlich auch das Unternehmensareal. Während derart leichtsinniges Verhalten nicht zwingend zu Datenverlust führen muss, sollte gleichzeitig die Gefahr vorsätzlicher Datendiebstähle nicht unterschätzt werden. Eine von Symantec beauftragte Studie etwa deckte auf, dass rund die Hälfte aller entlassenen Mitarbeiter Firmendaten mitgehen lassen – von E-Mails bis zu Datenbankinhalten. An dieser Stelle darf ein Hinweis auf die rechtlichen Aspekte beim Umgang mit Kundendaten nicht fehlen. So unterliegt nämlich spätestens seit der Einführung des Bundesdatenschutzgesetzes die Nutzung von Produktivdaten strengen Regeln, die auch die Weitergabe von Daten außerhalb der EU betreffen. Hinzu kommen besondere Publikationspflichten bei Datenschutzverstößen, die am Ende zu einer unerwünschten Publicity führen könnten.

Unternehmen insbesondere in der Finanz- und Versicherungswirtschaft befinden sich vor diesem Hintergrund in einem Dilemma: Einerseits müssen sie sorgfältiger als andere Branchen mit ihren Geschäftsdaten umgehen, da die Risiken in diesem Business ungleich höher sind als in anderen Märkten. Auf der anderen Seite lebt kaum ein Geschäft so sehr von IT-Innovationen wie die Banken- und Assekuranzbranche. Innovative Software bildet hier den Schlüssel zu neuen Geschäftschancen, indem beispielsweise mittels Data-Mining immer neue Erkenntnisse aus Kunden- und Geschäftsdaten gewonnen werden. Gefragt sind hier also Lösungen, die den Spagat meistern helfen zwischen maximalem Schutz der Daten auf der einen und optimaler Ausnutzung der Datenressourcen auf der anderen Seite. Entsprechende Lösungen hat die Softwareindustrie parat – das Stichwort lautet Data Masking.

Data Masking nutzt Verfahren der Datenverschleierung, um geschäftliche Daten so zu verändern, dass sich weiterhin für realistische Tests und Auswertungen eignen. Dabei werden jedoch alle Bezüge zu realen Personen oder Geschäftsentitäten zuverlässig entfernt, so dass keinerlei datenschutzrechtliches Risiko mehr besteht. Richtig eingesetzt versetzt Data Masking also ein Unternehmen in die Lage, jederzeit risikolos Kunden- und Geschäftsdaten für Tests und Analysen weiterzugeben – ob an interne Mitarbeiter oder externe Partner

Beim Data Masking kommen folgende zwei Produkte häufig zum Einsatz: Net 2000 und Oracle Data Masking. Das Grundprinzip dieser Werkzeuge ist recht einfach erklärt: Soll eine Datenbank für Testing oder Data Mining zur Verfügung gestellt werden, durchsucht ein solches Tool zuvor alle definierten Spalten und löscht oder verfremdet die Inhalte nach festgelegten Methoden. Grundsätzlich lässt sich eine solche Aufgaben auch ohne Zusatzprodukte bewältigen, doch ersparen diese Programme mühselige Eigenentwicklung und Handarbeit.

Die Vorgehensweise bei einem Data-Masking-Projekt beginnt üblicherweise damit, dass im ersten Schritt geklärt wird, welche Felder oder Spalten maskiert werden müssen. Prinzipiell könnten alle Datenbankinhalte maskiert werden, doch übersteigt der erforderliche Aufwand schnell den zu erwartenden Nutzen. Als grober Leitfaden gilt deshalb: So wenig maskieren wie möglich, aber so viel maskieren wie nötig. Die aus Data-Masking-Projekten gewonnene Erfahrung besagt, dass das richtige Maß letztlich immer in enger Zusammenarbeit mit dem Kunden gefunden werden muss.

Beim Maskieren von Feldern finden unterschiedliche Methoden Verwendung. Die einfachste Variante ist das Austauschen von Zeichenketten gegen Zufallszahlen. In der Regel genügt das jedoch nicht den Anforderungen, weil die zu testenden Anwendungen, die auf die maskierten Datenbanken zugreifen, die gelieferten Daten auf Plausibilität, Format oder Kontext prüfen. Als Beispiel wären Kreditkartennummern zu nennen: Sobald die Anwendung mit einer Prüfroutine Kreditkartennummer auf Gültigkeit checkt, erfordert die Maskierung die Verwendung plausibler Zahlenkombinationen, die validen Kreditkartennummern entsprechen. Die Tool-Anbieter liefern für solche Fälle stets eine eigene Maskierungsdatenbank mit, die plausible, aber künstliche Kreditkartennummern, Adressen oder Namen zum Austauschen bereitstellt. Ein weiterer Beispielfall, bei dem konsistente Zahlen gefordert sind, wären Produktpreise. Sollen beispielsweise Produktkataloge im Zuge von Datamining durchforstet werden, könnte die Anforderung lauten, dass zuvor die Verkaufspreise verfremdet werden sollen, um Rückschlüsse auf konkrete Einzelprodukte zu verhindern. Damit dabei dennoch brauchbare Analyseergebnisse herauskommen, bietet sich in diesem Fall eine dezente Abänderung der Preise in vordefinierten Bereichen an.

Eine andere Möglichkeit der Verschleierung ist das Durchmischen von Feldinhalten, das sogenannte Shuffeln. Auch auf diese lassen sich jegliche Bezüge auf reale Personen und anderen Geschäftsentitäten verwischen, wobei hier eine gewisse Vorsicht geboten ist. So funktioniert Shuffeln nur zuverlässig ab einer höheren Zahl an Datensätzen, die eine Rekonstruktion der ursprünglichen Anordnung sehr unwahrscheinlich macht. Zu beachten ist beim Shuffeln außerdem, dass in Datenbanken manchmal mehrere Felder zueinander in Bezug stehen. Um beim Testen der Anwendung Fehlermeldungen zu vermeiden, muss also auch die Relation solcher Felder untereinander mit berücksichtigt werden.

Die wirksamste Verschleierungsmethode ist natürlich das Löschen von Feldinhalten. Doch auch dabei empfiehlt sich ein wohlüberlegtes Vorgehen. Zunächst muss einmal ermittelt werden, auf welche Inhalte beim Testen oder Analysieren problemlos verzichtet werden kann. Und auch hier lauern potenzielle Stolperfallen – etwa in Form von Freitextfeldern, die nicht immer auf Anhieb als relevant erkannt werden. So könnten etwa über den Weg von Bestellformularen oder Banküberweisungen in solchen Freitextfelder vertrauliche Informationen landen, die möglicherweise bei der Maskierungskonfiguration übersehen werden.

Wie bereits deutliche wurde, verlangt Data Masking eine gründliche Planung sowie eine koordinierte Vorgehensweise, bei der die IT und die zuständigen Fachbereiche eng zusammenarbeiten müssen. Metafinanz hat dazu ein fünfstufiges Vorgehensmodell entwickelt. Zunächst setzen sich in einem Workshop die IT, die Fachabteilung und der Datenschutzbeauftragte zusammen und definieren Anforderungen, Datenmodell, Maskierungsarten sowie die geeigneten Tools. In der Konzeptphase kümmert sich die IT um die Maskierung, den Prozess und die Blueprints. Im nächsten Schritt erarbeiten beim Review alle Beteiligten gemeinsam ein Qualitätssicherungskonzept. Die Umsetzung obliegt wiederum der IT, die sich um Infrastruktur, Implementierung und Tool-Schulung kümmert. Den Schlusspunkt bildet schließlich die Qualitätssicherung, bei der die Güte der gesamten Maskierungs-Schritte noch einmal überprüft wird und die Abnahme durch die IT, die Fachabteilung und den Datenschutzbeauftragten erfolgt.

Abschließend lässt sich feststellen, dass beim Data Masking wie bei vielen Sicherheitsthemen der Grundsatz gilt: »There is no free lunch« – Sicherheit kostet Geld. Dieses ist aber beim Data Masking gut angelegt, weil beim Testing und der Datenanalyse die Kronjuwelen eines Unternehmens auf dem Spiel stehen können.

Carsten Herbe, Project Manager Business Intelligence, metafinanz Informationssystme GmbH

Was ist Data Masking?

Data Masking ist eine Methode, bei der strukturell ähnliche, aber nicht-authentische Unternehmensdaten erzeugt werden. Derart veränderte Daten kommen in Softwaretests, Data Mining und Benutzertrainings zum Einsatz. Ziel von Data Masking ist, den potenziellen Missbrauch von Originaldaten zu unterbinden. Bei der Modifikation kommen mehrere Verfahren zum Einsatz, wobei zu den häufigsten die Verschlüsselung, die Zeichenvermischung und das Austauschen von Zeichen und Wörtern zählen. Bei Data Masking wird auch stets darauf geachtet, dass eine Erkennung oder Rekonstruktion der Ursprungsdaten ausgeschlossen ist.

Data Masking – die wichtigsten Techniken

Ersetzen

Eine gängige Technik beim Data Masking ist das Ersetzten von Tabelleninhalten durch ähnliche Daten, die völlig ohne Bezug zu den Ursprungsdaten stehen. Nachnamen in einer Kundendatenbank können beispielsweise ausgetauscht werden durch Namen aus einer zufällig generierten Liste. Hauptvorteil beim Ersetzen sind realistisch wirkende Datensätze. Der Nachteil dabei ist, dass große Mengen an Ersatzdaten benötigt werden, um bei Bedarf auch große Datenbanken maskieren zu können. Das gilt auch beim Austausch von Telefonnummern oder Kreditkartennummern.

Vermischen

Vermischen (Shuffling) ähnelt dem Ersetzen, jedoch kommen hier die Ersatzdaten aus derselben Tabellenspalte. Das Vermischen birgt gewisse Risiken. So könnten Unbefugte in einer Lieferantentabelle gezielt nach der Existenz eines bestimmten Namens suchen. Möglich ist das prinzipiell, da die Originaldaten weiterhin vorhanden sind. Je größer die Datenmenge ist, desto sicherer sind die vermischten Daten gegen Rekonstruktion geschützt. Als Vorteil des Shuffelns gilt das realistische »Look-and-Feel« der Daten.

Zahlen- und Datenstreuung
Zahlenstreuung ist nützlich bei numerischen oder Datumsinformationen. Dabei modifiziert ein Algorithmus jede Zahl oder jeden Datumswert einer Spalte um einen festgelegten Prozentsatz. Somit wird eine gute Verschleierung erzielt, gleichzeitig bleiben aber der Bereich und die Verteilung der Werte in einer Spalte innerhalb eines gewünschten, realitätsnahen Bereichs.

Verschlüsselung

Verschlüsseln von Tabelleninhalten ermöglicht eine originalgetreue Weitergabe der Daten, da jeder Schlüsselinhaber vollen Zugriff darauf hat. Für Testdatenbanken eignet sich die Verschlüsselung nur unter bestimmten Umständen. So ist zu berücksichtigen, dass, wenn der Schlüssel einmal abhandengekommen ist, alle Daten kompromittiert sind.

Copyright © 2003-2012 ap Verlag GmbH