Das Defektieren von *** s ist nicht nur eine Randomisierung



In der Bank gibt es ein Problem: Entwickler und Tester müssen Zugriff auf die Datenbank erhalten. Es gibt viele Kundendaten, die nicht zur Weitergabe an die Entwicklungs- und Testabteilungen gemäß den PCI-DSS-Anforderungen der Zentralbank und den Gesetzen für personenbezogene Daten verwendet werden können.

Es scheint, dass es ausreicht, nur alles in asymmetrische Hashes zu ändern, und alles wird gut.

Also wird es nicht.

Tatsache ist, dass die Datenbank der Bank eine Reihe miteinander verbundener Tabellen ist. Irgendwo sind sie durch Name und Kundenkontonummer verbunden. Irgendwo durch seine eindeutige Kennung. Irgendwo (hier beginnt der Schmerz) durch eine gespeicherte Prozedur, die eine Pass-Through-Kennung basierend auf dieser und der benachbarten Tabelle berechnet. Usw.

Die übliche Situation ist, dass der Entwickler der ersten Version des Systems bereits vor zehn Jahren verstorben ist oder das System verlassen hat und die Kernelsysteme, die im alten Hypervisor im neuen Hypervisor ausgeführt werden (um die Kompatibilität sicherzustellen), noch im Produkt sind.

Das heißt, bevor Sie all dies anonymisieren, müssen Sie zuerst die Datenbank verstehen.



Wer macht Depersonalisierung und warum?


Sie beschäftigen sich mit Depersonalisierung oder Maskierung, weil es Gesetze und Standards gibt. Ja, es ist viel besser, auf einen "Verkaufsschnappschuss" zu testen, aber die Aufsichtsbehörden können eine Lizenz für einen solchen Flug widerrufen. Das heißt, das Geschäft als solches zu vertuschen.

Jede Depersonalisierung ist eine ziemlich teure und ungeschickte Schicht zwischen produktiven Systemen und Entwicklungstests.

Das Ziel von Anonymisierungsprojekten (Maskierungsprojekten) besteht fast immer darin, Testdaten zu erstellen, die den in produktiven Datenbanken gespeicherten realen Daten so ähnlich wie möglich sind. Das heißt, wenn die Daten Fehler enthalten - anstelle einer E-Mail ist das Telefon verstopft, anstelle des kyrillischen Alphabets im lateinischen Nachnamen usw. sollten die getarnten Daten von gleicher Qualität sein, aber bis zur Unkenntlichkeit geändert werden. Das zweite Ziel besteht darin, das Volumen der Datenbanken zu reduzieren, die beim Testen und Entwickeln verwendet werden. Das gesamte Volume bleibt nur für Lasttests übrig, und für den Rest der Aufgaben wird ein bestimmter Datenabschnitt normalerweise nach vordefinierten Regeln ausgeführt - Datenbankabschneidung. Das dritte Ziel besteht darin, verwandte Daten in verschiedenen getarnten und abgeschnittenen Datenbanken abzurufen. Dies bedeutet, dass Daten in verschiedenen Systemen zu unterschiedlichen Zeiten einheitlich anonymisiert werden müssen.

In Bezug auf die Komplexität der Berechnungen entspricht die Depersonalisierung in etwa einigen Datenbankarchiven mit extremer Komprimierung. Der Algorithmus ist ungefähr ähnlich. Der Unterschied besteht darin, dass Archivierungsalgorithmen im Laufe der Jahre weiterentwickelt wurden und nahezu maximale Effizienz erreicht haben. Und Depersonalisierungsalgorithmen sind so geschrieben, dass sie zumindest auf der aktuellen Basis funktionieren und ziemlich universell sind. Und Software nach der Depersonalisierung funktionierte im Allgemeinen. Das ist ein hervorragendes Ergebnis - 40 TB pro Nacht zu mahlen. Es kommt daher vor, dass es für den Kunden billiger ist, die Datenbank eine Woche lang alle sechs Monate auf einem schwachen Server zu depersonalisieren - auch ein Ansatz.



Wie werden Daten ersetzt?


Jeder Datentyp ändert sich gemäß den Regeln, die im Code verwendet werden können. Wenn wir beispielsweise den Namen durch einen zufälligen Hash durch Sonderzeichen und Zahlen ersetzen, führt die allererste Datenüberprüfung sofort zu einem Fehler beim tatsächlichen Testen.

Daher muss das Depersonalisierungssystem zunächst bestimmen, welcher Datentyp im Feld gespeichert ist. Je nach Anbieter werden unterschiedliche Ansätze verwendet, vom manuellen Markup bis hin zu Versuchen, die Datenbank zu ermitteln und automatisch zu erkennen, was dort gespeichert ist. Wir haben die Praxis, alle wichtigen Lösungen auf dem Markt einzuführen. Wir werden eine der Optionen analysieren, wenn ein Assistent versucht, Daten zu finden und zu erraten, welche Art von Daten dort gespeichert sind.



Um mit dieser Software arbeiten zu können, benötigen Sie natürlich Zugriff auf echte Daten (normalerweise ist dies eine Kopie einer kürzlich durchgeführten Sicherung der Datenbank). Nach Bankerfahrung unterschreiben wir zuerst zwei Monate lang eine Tonne Papiere, kommen dann zur Bank, ziehen uns aus, suchen und ziehen uns an, gehen dann in einen separaten Raum, der mit einem Faradayschen Käfig eingesperrt ist, in dem sich zwei Sicherheitspersonal befinden, und atmen warm im Hinterkopf.

Nehmen wir also an, wir sehen nach all dem eine Tabelle, in der sich ein Feld "Name" befindet. Der Assistent hat es bereits für uns als Namen markiert, und wir können nur die Art der Depersonalisierung bestätigen und auswählen. Der Assistent bietet einen zufälligen Ersatz für slawische Namen (es gibt Basen für verschiedene Regionen). Wir sind uns einig und bekommen Ersatz wie Ivan Ivanov Petrenko - Joseph Albertovich Chingachguk. Wenn dies wichtig ist, bleibt das Geschlecht erhalten. Wenn nicht, werden Ersetzungen in der gesamten Datenbank der Namen vorgenommen.

Beispiele für Ersatz:
. ->
->
->
->
-> -
Das nächste Feld ist das Datum in Unixtime. Der Assistent hat dies ebenfalls festgestellt, aber wir müssen die Depersonalisierungsfunktion auswählen. Normalerweise werden Daten verwendet, um die Abfolge der Ereignisse zu steuern, und die Situation, in der ein Kunde zuerst eine Überweisung bei einer Bank vorgenommen und dann ein Konto eröffnet hat, muss niemand wirklich testen. Daher setzen wir ein kleines Delta - standardmäßig innerhalb von 30 Tagen. Es werden weiterhin Fehler auftreten. Wenn dies jedoch kritisch ist, können Sie komplexere Regeln konfigurieren, indem Sie Ihr Skript zur Anonymisierungsverarbeitung hinzufügen.

Die Adresse muss validiert werden, damit die Datenbank der russischen Adressen verwendet wird. Die Kartennummer muss den reellen Zahlen entsprechen und von diesen validiert werden. Manchmal besteht die Aufgabe darin, „alle Visa-Mastercards nach dem Zufallsprinzip zu erstellen“ - dies ist auch mit wenigen Klicks möglich.
Unter der Haube des Assistenten befindet sich die Profilerstellung. Profiling ist eine Suche nach Daten in einer Datenbank nach vordefinierten Regeln (Attribute, Domänen). Tatsächlich lesen wir jede Zelle der Kundendatenbank, wenden eine Reihe von regulären Ausdrücken auf jede Zelle an, vergleichen die Werte in dieser Zelle mit Wörterbüchern usw. Als Ergebnis haben wir eine Reihe von ausgelösten Regeln für die Spalten der Datenbanktabellen. Wir können die Profilerstellung konfigurieren, wir können nicht alle Tabellen in der Datenbank lesen, wir können nur eine bestimmte Anzahl von Zeilen aus der Tabelle oder einen bestimmten Prozentsatz von Zeilen entnehmen.



Was ist drinnen los?


Für jeden Eintrag in der Datenbank gelten die von uns ausgewählten Depersonalisierungsregeln. In diesem Fall werden temporäre Tabellen für die Dauer des Prozesses erstellt, in denen Ersetzungen geschrieben werden. Jeder nachfolgende Datensatz in der Datenbank wird gemäß diesen Ersatzkorrespondenztabellen ausgeführt, und wenn dort eine Korrespondenz vorhanden ist, wird sie auf die gleiche Weise wie zuvor ersetzt. Alles ist tatsächlich etwas komplizierter, abhängig von Ihren Skripten und Mustervergleichsregeln (es kann einen ungenauen Ersatz geben, zum Beispiel für die Geburt oder für das Ersetzen von Daten, die in einem anderen Format gespeichert sind), aber die allgemeine Idee ist, dass.

Wenn es markierte Entsprechungen gibt, „der Name ist kyrillisch - der Name ist lateinisch“, sollten sie in der Entwicklungsphase klar angegeben werden und dann in der Substitutionstabelle einander entsprechen. Das heißt, der Name wird in kyrillischer Sprache anonymisiert, und dann wird dieser anonymisierte Eintrag beispielsweise in das lateinische Alphabet konvertiert. An diesem Punkt entfernen wir uns vom Ansatz „Verbessern Sie nicht die Qualität der Daten im System“. Dies ist jedoch einer der Kompromisse, die Sie eingehen müssen, um eine gewisse Systemleistung zu erzielen. Die Praxis zeigt, dass es nichts gab, wenn stressige Funktionstests keinen Kompromiss in ihrer Arbeit bemerkten. Und hier kommt der wichtige Punkt, dass Depersonalisierung als Ganzes keine Verschlüsselung ist. Wenn Sie ein paar Meter Einträge in der Tabelle haben und in zehn davon die TIN nicht geändert hat, was dann? Nichts, diese zehn Datensätze können nicht gefunden werden.

Nach dem Ende des Prozesses verbleiben die Konvertierungstabellen in der geschützten Datenbank des Depersonalisierungsservers. Die Basis wird abgeschnitten (abgeschnitten) und ohne Konvertierungstabellen an das Testen übergeben, sodass für den Tester die Depersonalisierung irreversibel wird.

Die vollständige anonyme Datenbank wird zum Stresstest an Tester übergeben.

Dies bedeutet, dass während der Arbeit mit der Datenbank die Konvertierungstabelle "anschwillt" (der genaue Betrag hängt von der Auswahl der Ersetzungen und deren Typ ab), die Arbeitsbasis jedoch die ursprüngliche Größe beibehält.

Wie sieht der Prozess in der Bedienoberfläche aus?


Allgemeine Ansicht der IDE am Beispiel eines der Anbieter:



Debugger:



Starten einer Transformation aus der IDE:



Konfigurieren eines Ausdrucks für die Suche nach vertraulichen Daten im Profiler:



Seite mit einer Reihe von Regeln für den Profiler:



Das Ergebnis des Profilers, Webseite mit Datensuche:



Sind alle Daten in der Datenbank maskiert?


Nein. In der Regel wird die Liste der Daten für die Depersonalisierung durch Gesetze und Standards der Sphäre geregelt, und der Kunde hat Vorschläge für bestimmte Bereiche, über die niemand Bescheid wissen sollte.

Die Logik ist, dass wenn wir den Namen des Patienten im Krankenhaus maskieren, Sie die Diagnose maskieren können oder nicht - immer noch wird niemand wissen, von wem er stammt. Wir hatten einen Fall, in dem Notizen zu einer Transaktion in einer Bank einfach in zufälligen Buchstaben maskiert wurden. Es gab Notizen über das Niveau: "Der Kredit wurde abgelehnt, weil der Kunde betrunken kam, er sich an die Bar erbrach." Aus Debugging-Sicht ist es nur eine Zeichenfolge. Nun, lass sie bleiben.

Beispielstrategien:



Eine dynamische Seed-Tabelle ist eine Transcodierungstabelle, in die wir die bereits erfolgte Neucodierung einfügen. Der Hash kann sehr unterschiedlich sein und im Fall derselben TIN wird häufiger eine neue zufällige TIN mit den ersten gespeicherten Zeichen mit Prüfziffern generiert.

Ist es möglich, Daten mit dem DBMS selbst zu ändern?


Ja. Bei der Depersonalisierung von Daten gibt es zwei Hauptansätze: Ändern der Daten in der Datenbank mithilfe der Datenbank selbst oder Organisieren eines ETL-Prozesses und Ändern von Daten mithilfe von Software von Drittanbietern.

Das entscheidende Plus des ersten Ansatzes ist, dass Sie nirgendwo Daten aus der Datenbank entnehmen müssen, keine Netzwerkkosten anfallen und schnelle und optimierte Datenbank-Tools verwendet werden. Das Schlüssel-Minus ist eine separate Entwicklung für jedes System, das Fehlen gemeinsamer Konvertierungstabellen für verschiedene Systeme. Konvertierungstabellen werden für die Reproduzierbarkeit der Depersonalisierung und die weitere Datenintegration zwischen Systemen benötigt.

Der Hauptvorteil des zweiten Ansatzes besteht darin, dass es keine Rolle spielt, um welche Datenbank, welches System, welche Datei es sich handelt oder um welche Art von Webschnittstelle. Sobald Sie eine Regel implementiert haben, können Sie sie überall verwenden. Das Schlüssel-Minus ist, dass Sie Daten aus der Datenbank lesen, mit einer separaten Anwendung verarbeiten und in die Datenbank zurückschreiben müssen.

Die Praxis zeigt, dass, wenn der Kunde über mehrere Systeme verfügt, die eine weitere Integration erfordern, nur der zweite Ansatz für die endgültigen Kosten in Geld sowie für akzeptable Entwicklungszeiten implementiert werden kann.



Das heißt, wir können alles tun, was wir wollen, aber der ETL-Ansatz hat sich im Bankensektor sehr gut bewährt.

Und warum verderben die Daten einfach nicht manuell?


Dies kann einmal durchgeführt werden. Jemand wird drei Tage lang sitzen, eine Reihe von Daten depersonalisieren und eine Datenbank mit 500-1000 Datensätzen erstellen. Die Schwierigkeit besteht darin, dass der Prozess regelmäßig (bei jeder Änderung der Datenbankstruktur und dem Auftreten neuer Felder und Tabellen) und in großen Mengen (für verschiedene Testarten) wiederholt werden muss. Eine häufige Anforderung besteht darin, die ersten 10-50 GB der Datenbank zu depersonalisieren, damit dieser Betrag gleichmäßig auf jede Tabelle fällt.

Was tun, wenn Dokumentenscans in der Datenbank gespeichert sind?


Wenn ein Dokument auf XML reduziert und zurückkonvertiert werden kann (z. B. Office-Dokumente), können Sie sie auch depersonalisieren. Aber manchmal gibt es Binärdateien wie Pass-Scans in PDF / JPG / TIFF / BMP. In diesem Fall besteht die allgemein akzeptierte Praxis darin, ähnliche Dokumente mit einem Skript eines Drittanbieters zu versehen und echte durch Stichproben aus der Basis zufällig generierter Dokumente zu ersetzen. Das Schwierigste ist mit Fotos, aber es gibt Dienste wie diesen , die das Problem auf ungefähr die gleiche Weise lösen.

Wer ist für was verantwortlich?




Beim Aktualisieren nach dem Wechseln der Software oder beim „Aufholen“ sind die Prozesse einfacher.

Aber was ist, wenn bei den Tests etwas schief geht?


Dies passiert normalerweise. Zunächst formulieren Tester nach dem ersten Depersonalisierungslauf die Anforderungen an die Datenbank genauer. Wir können die Regeln der Depersonalisierung ändern oder Aufzeichnungen ablehnen, wie „hier sollten die Aktionen in chronologischer Reihenfolge und nicht chaotisch ablaufen“. Zweitens unterstützen wir je nach Implementierung entweder die Depersonalisierung, wenn sich die Datenbank ändert, oder lassen die gesamte Dokumentation, Beschreibungen der Datenbankstruktur und der Verarbeitungstypen, übertragen den gesamten Verarbeitungscode (Regeln in XML / SQL) und bilden Spezialisten vom Kunden aus.

Wie schaue ich mir eine Demo an?


Am einfachsten ist es, mir eine E-Mail an PSemenov@technoserv.com zu senden.

All Articles