Seit der Markeinführung von Libelle DataMasking vor nunmehr sieben Jahren haben wir bereits viele verschiedene und interessante Kundenprojekte durchgeführt. Jedes Projekt stellt uns immer wieder vor neue spannende Herausforderungen. Doch das wären nicht wir, wenn wir diese Herausforderungen nicht annehmen und meistern würden.
In diesem Blogbeitrag habe ich die TOP 10-Fehler bei der Anonymisierung einmal zusammengefasst.
Eines der Key Features von Libelle DataMasking ist die Wahrung der system- und landschaftsübergreifenden Konsistenz der Daten, ganz gleich, ob nur SAP-, nur andere Systeme oder eine Kombination aus beiden Welten im Anonymisierungsprozess Berücksichtigung findet. Diese Funktionalität erfolgt durch die Eingabe des sogenannten Anonymisierungsschlüssels.
Im überwiegenden Teil der Projekte wird auf die Wahrung der system- und landschaftsübergreifenden Konsistenz sehr viel Wert gelegt, weshalb bereits zu einem sehr frühen Zeitpunkt der Projekte ein einheitlicher Anonymisierungsschlüssel festgelegt wird, welcher fortan für alle Beteiligten gilt.
Problematisch wird es, wenn trotz dieser Festlegung plötzlich ein anderer Schlüssel verwendet wird; dabei reicht es, wenn dieser bereits bei nur einem der beteiligten Systeme zum Einsatz kommt. Der Workflow eines Tests kann so schnell ins Stocken geraten, weil relevante Informationen zu einem Testfall nicht mehr gefunden werden können, da die anonymisierten Daten nun auseinanderlaufen.
In relationalen Datenbanken gibt es im Regelfall Abhängigkeiten zwischen den Tabellen auf Basis der referentiellen Integrität, um die Konsistenz und Integrität der Daten sicherzustellen. Diese Abhängigkeiten müssen natürlich auch im Rahmen der Anonymisierung beibehalten werden.
Mit Libelle DataMasking kann eine Reihenfolge definiert werden, in welcher die zu behandelnden Tabellen anonymisiert werden. Die Software bietet dafür bis zu zehn verschiedene Level.
Ein Beispiel: Die Tabellen A und B enthalten zusammengehörende Datensätze.
In einem ersten Schritt (Reihenfolge 0) werden die Felder beider Tabellen unabhängig voneinander anonymisiert. Ein zweiter Schritt soll anschließend dazu dienen, die Zusammengehörigkeit der Datensätze wiederherzustellen. Dies erfolgt mittels eines SQL-SELECT-Statement, durch das die Tabellen miteinander gejoint werden. Der JOIN muss zwangsläufig in einer anderen Reihenfolge (im Beispiel Reihenfolge 1) durchgeführt werden. Andernfalls besteht die Gefahr, dass die Konsistenz verletzt wird. Im Extremfall könnte während des Anonymisierens sogar ein Deadlock erzeugt werden, weil unter Umständen zwei Statements auf dieselben Datensätze zugreifen und diese ändern wollen.
Im Produktumfang von Libelle DataMasking ist die sogenannte Referenzdatenbank enthalten. Sie beinhaltet mögliche Zielwerte, in die anonymisiert werden kann. Neben der Libelle-eigenen Referenzdatenbank können aber auch eigene, kundenspezifische Referenzdateien als Basis genutzt werden. Je nach Konzept des Projekts können die Referenzdateien über einen separaten Workflow bereitgestellt, aber auch mit Hilfe der Software automatisiert generiert werden. Die Fehleranfälligkeit besteht darin, dass die Datei entweder nicht als Referenzdatei registriert oder in der Konfiguration, in der die Datei benötigt wird, nicht aktiviert ist. Eine weitere mögliche Fehlerquelle ist, dass die Datei bei der automatischen Generierung als sogenannte Anonymisierungsaktivität durch die Software nicht erstellt wurde.
Out of the box enthält die Software Libelle DataMasking gegenwärtig 40 Anonymisierungsalgorithmen. Einige Algorithmen kommen ohne zusätzliche Parameter aus. Hierzu zählt zum Beispiel der Vornamensalgorithmus. Andere, wie der Adressalgorithmus, benötigen zusätzliche Parameter. Die Parameter dienen der exakten Spezifizierung, wie ein Feld zu anonymisieren ist.
In unseren Projekten erleben wir es immer wieder, dass Parameter falsch definiert sind oder Parameter angegeben sind, die der jeweilige Algorithmus nicht unterstützt. Hinzu kommt, dass bei ein paar Algorithmen ID-Werte vergeben werden müssen. Beispielsweise bildet bei den Adressen ein Datensatz bestehend aus Straße, Hausnummer, Postleitzahl und Ort eine Gruppe. Diese Gruppe wird über den ID-Wert definiert. Enthält eine Tabelle z.B. den Haupt- und Nebenwohnsitz, also zwei Adressgruppen, muss für jede Gruppe eine eindeutige ID vergeben werden.
Dieses Phänomen zähle ich zu den Klassikern in SAP-spezifischen Projekten. Es ist immer wieder aufs Neue interessant und erstaunlich, wie die Such- und Matchcodefelder in den SAP-Systemen der Kunden gefüllt sind und welche Ausprägungen es haben kann.
Ein recht harmloses Beispiel ist, dass nur das erste Suchfeld gefüllt ist, dann aber mit dem Vor- und Nachnamen. In unseren SAP-Standardtemplates haben wir eine bestimmte Form der Belegung der Felder gewählt. Diese Einstellung muss an die Kundenbedürfnisse angepasst werden.
SAP-Systeme, die noch nicht auf Basis von SAP HANA laufen, enthalten in der Regel neben den transparenten Tabellen zusätzlich noch Cluster- und Pool-Tabellen, die sich dadurch auszeichnen, dass sie nur auf ABAP-Ebene selektierbar sind. Um dies durchzuführen, ist ein Libelle-eigener Funktionsbaustein in die Systeme zu transportieren.
Die Fehleranfälligkeit besteht in diesem Punkt darin, dass die Updates der Software auch Updates des Funktionsbausteins enthalten und der Import des neuen Transportfiles gerne vergessen wird. Libelle DataMasking prüft die Version des Funktionsbausteins und gibt im Falle einer Diskrepanz eine Fehlermeldung aus.
Ein Anonymisierungslauf kann aus den verschiedensten Gründen fehlschlagen. Die Ursachen können auch außerhalb der Software liegen, zum Beispiel ein vollgelaufenes Filesystem oder auch ein vollgelaufener Tablespace. Nach dem Beheben des Fehlers kann die Anonymisierung fortgesetzt werden. Zu beachten ist dabei, ob die Wiederaufsetzpunkte aktiviert sind. Mit ihrer Hilfe kann die Anonymisierung exakt bei dem Datensatz fortgesetzt werden, bei dem zuvor der Fehler aufgetreten war. Sind die Wiederaufsetzpunkte inaktiv, wird die zuletzt behandelte Tabelle erneut anonymisiert, obwohl ein Teil der Daten bereits anonymisiert wurde.
In einigen Projekten erreichen wir einen mitunter recht hohen Grad an Customizing. Diese vom Standard abweichenden Erweiterungen (z.B. Skripte) werden während eines Updates der Software berücksichtigt. Wird die Software jedoch parallel neu installiert, müssen die Customizing-Einstellungen „mühsam“ in die neue Umgebung übernommen werden. D.h. zusätzliche Dateien sind zunächst zu kopieren, zum anderen müssen die Einstellungen auch im Tool selbst wieder angepasst werden.
Auch diesen Fall zähle ich zu den klassischen Fehlern in den Projekten. Es kommt vor, dass Felder anonymisiert werden müssen, die Teil des Primärschlüssels einer Tabelle sind. Ein typisches Beispiel ist die Tabelle TIBAN in SAP. Mit Hilfe unseres Algorithmus berechnen wir in Libelle DataMasking die Werte einer IBAN valide neu. Doch oftmals macht uns die Qualität der ursprünglichen Daten einen Strich durch die Rechnung.
Um bei dem Beispiel zu bleiben: Was immer wieder vorkommt, ist das Fehlen von Prüfziffern. So gibt es in den Systemen Datensätze einmal mit und einmal ohne Prüfziffer. Jedoch berechnet der Algorithmus auch die Prüfziffer valide neu, obwohl sie in einem der Datensätze eigentlich fehlt. Diese Konstellation führt dazu, dass Duplikate erzeugt werden, was zur Folge hat, dass der Primärschlüssel nicht mehr neu angelegt werden kann, der zuvor für die Behandlung dieser Felder gelöscht wurde.
In vielen Projekten wird Wert daraufgelegt, dass Adressdaten nicht willkürlich verfremdet werden, sondern im ursprünglichen Gebiet bleiben, was sich auch mit Libelle DataMasking umsetzen lässt.
Das bedingt aber eine hohe Qualität der ursprünglichen Daten. Sind die Region (z.B. Bundesland) oder das Land nicht sauber gepflegt, landen die anonymisierten Werte in einem völlig anderen Gebiet. Sind die Daten unvollständig im System vorhanden, kann über ein Customizing ein Mapping erfolgen, sodass die Adressen auch nach der Anonymisierung in ihrer ursprünglichen Region bleiben.
Die Libelle IT Group hat hier mit Libelle DataMasking eine Lösung für die erforderliche Anonymisierung und Pseudonymisierung entwickelt. Konzipiert wurde die Lösung zur Herstellung anonymisierter, logisch konsistenter Daten auf Entwicklungs-, Test- und QS-Systemen über alle Plattformen hinweg. Erfahren Sie mehr über unsere Lösungen und sichern Sie sich Ihr kostenloses Whitepaper.