Datenmaskierung - Data masking
Datenmaskierung oder Datenverschleierung ist der Vorgang, bei dem sensible Daten so modifiziert werden, dass sie für unbefugte Eindringlinge keinen oder nur geringen Wert haben und dennoch von Software oder autorisiertem Personal verwendet werden können.
Der Hauptgrund für die Maskierung eines Datenfelds besteht darin, Daten zu schützen, die als personenbezogene Daten, sensible personenbezogene Daten oder wirtschaftlich sensible Daten klassifiziert sind. Die Daten müssen jedoch für die Durchführung gültiger Testzyklen verwertbar bleiben. Es muss auch echt aussehen und konsistent erscheinen. Es ist üblicher, die Maskierung auf Daten anzuwenden, die außerhalb eines Unternehmensproduktionssystems dargestellt werden. Also dort, wo Daten zum Zwecke der Anwendungsentwicklung, der Erstellung von Programmerweiterungen und der Durchführung verschiedener Testzyklen benötigt werden . Im Enterprise Computing ist es gängige Praxis, Daten aus den Produktionssystemen zu entnehmen, um die Datenkomponente zu füllen, die für diese Nicht-Produktionsumgebungen erforderlich ist. Diese Praxis ist jedoch nicht immer auf Nicht-Produktionsumgebungen beschränkt. In einigen Organisationen können Daten, die Callcenter-Betreibern auf den Terminalbildschirmen angezeigt werden, dynamisch maskiert werden, basierend auf Benutzersicherheitsberechtigungen (z. B. Verhindern, dass Callcenter-Betreiber Kreditkartennummern in Abrechnungssystemen anzeigen).
Das Hauptanliegen aus Sicht der Corporate Governance besteht darin, dass das Personal, das Arbeiten in diesen Nicht-Produktionsumgebungen ausführt, nicht immer über eine Sicherheitsfreigabe verfügt, um mit den in den Produktionsdaten enthaltenen Informationen zu arbeiten. Diese Praxis stellt eine Sicherheitslücke dar, bei der Daten von nicht autorisiertem Personal kopiert werden können und Sicherheitsmaßnahmen, die mit Standardkontrollen auf Produktionsebene verbunden sind, leicht umgangen werden können. Dies stellt einen Zugangspunkt für eine Datensicherheitsverletzung dar .
Die allgemeine Praxis der Datenmaskierung auf organisatorischer Ebene sollte eng mit der Testmanagement-Praxis und der zugrunde liegenden Methodik gekoppelt sein und Prozesse für die Verteilung von maskierten Testdaten-Untergruppen beinhalten.
Hintergrund
Daten, die an einer Datenmaskierung oder -verschleierung beteiligt sind, müssen auf mehreren Ebenen aussagekräftig bleiben:
- Die Daten müssen für die Anwendungslogik aussagekräftig bleiben. Wenn beispielsweise Adresselemente verschleiert werden sollen und Städte und Vororte durch Ersatzstädte oder Vororte ersetzt werden, dann muss diese Funktion, wenn es in der Anwendung eine Funktion gibt, die die Postleitzahl- oder Postleitzahl-Suche validiert, weiterhin ohne Fehler und funktionieren wie erwartet. Dasselbe gilt auch für die Überprüfung des Kreditkartenalgorithmus und die Überprüfung der Sozialversicherungsnummer .
- Die Daten müssen genügend Änderungen erfahren, damit nicht offensichtlich ist, dass die maskierten Daten aus einer Produktionsdatenquelle stammen. Zum Beispiel kann es in einem Unternehmen allgemein bekannt sein, dass es 10 Senior Manager gibt, die alle mehr als 300.000 US-Dollar verdienen. Wenn eine Testumgebung des HR-Systems der Organisation auch 10 Identitäten in derselben Einkommensklasse umfasst, könnten andere Informationen zusammengefügt werden, um eine reale Identität zurückzuentwickeln. Wenn die Daten offensichtlich maskiert oder verschleiert sind, wäre es theoretisch vernünftig, anzunehmen, dass jemand, der einen Datenschutzverstoß beabsichtigt, Identitätsdaten zurückentwickeln könnte, wenn er ein gewisses Maß an Wissen über die Identitäten im Produktionsdatensatz hätte. Dementsprechend gilt die Datenverschleierung oder -maskierung eines Datensatzes so, dass Identität und sensible Datensätze geschützt sind – nicht nur die einzelnen Datenelemente in diskreten Feldern und Tabellen.
- Die maskierten Werte müssen möglicherweise über mehrere Datenbanken innerhalb einer Organisation hinweg konsistent sein, wenn die Datenbanken jeweils das spezifische zu maskierende Datenelement enthalten. Anwendungen können zunächst auf eine Datenbank zugreifen und später auf eine andere zugreifen, um zugehörige Informationen abzurufen, bei denen der Fremdschlüssel maskiert wurde (z Datenbanken mit sehr unterschiedlichen Finanzprodukten.) Dies erfordert, dass die angewendete Maskierung wiederholbar ist (derselbe Eingabewert für den Maskierungsalgorithmus ergibt immer den gleichen Ausgabewert), aber nicht durch Reverse Engineering wieder auf den ursprünglichen Wert zurückgeführt werden kann. Abhängig von den beteiligten Datenelementen können auch zusätzliche Einschränkungen gelten, wie oben in (1) erwähnt. Wenn unterschiedliche Zeichensätze in den Datenbanken verwendet werden, die in diesem Szenario verbunden werden müssen, muss ein Schema zum Konvertieren der ursprünglichen Werte in eine gemeinsame Darstellung angewendet werden, entweder durch den Maskierungsalgorithmus selbst oder vor dem Aufrufen des Algorithmus.
Techniken
Auswechslung
Die Substitution ist eine der effektivsten Methoden, um Datenmaskierung anzuwenden und das authentische Erscheinungsbild der Datensätze zu erhalten.
Es ermöglicht, dass die Maskierung auf eine solche Weise durchgeführt wird, dass ein anderer authentisch aussehender Wert für den vorhandenen Wert ersetzt werden kann. Es gibt mehrere Datenfeldtypen, bei denen dieser Ansatz einen optimalen Vorteil bietet, um den gesamten Datenteilsatz dahingehend zu verschleiern, ob es sich um einen maskierten Datensatz handelt oder nicht. Wenn es sich beispielsweise um Quelldaten handelt, die Kundendatensätze enthalten, kann der reale Nachname oder Vorname zufällig aus einer bereitgestellten oder angepassten Nachschlagedatei ersetzt werden. Wenn der erste Durchlauf der Substitution die Anwendung eines männlichen Vornamens auf alle Vornamen ermöglicht, muss der zweite Durchlauf die Anwendung eines weiblichen Vornamens auf alle Vornamen ermöglichen, bei denen das Geschlecht gleich "F" ist. Mit diesem Ansatz könnten wir problemlos den Geschlechtermix innerhalb der Datenstruktur beibehalten, Anonymität auf die Datensätze anwenden, aber auch eine realistisch aussehende Datenbank pflegen, die nicht ohne weiteres als eine Datenbank aus maskierten Daten identifiziert werden könnte.
Diese Substitutionsmethode muss für viele der Felder angewendet werden, die sich in DB-Strukturen auf der ganzen Welt befinden, wie Telefonnummern , Postleitzahlen und Postleitzahlen sowie Kreditkartennummern und andere Kartentypnummern wie Sozialversicherungsnummern und Medicare- Nummern, wobei diese Zahlen müssen tatsächlich einem Prüfsummentest des Luhn-Algorithmus entsprechen .
In den meisten Fällen müssen die Substitutionsdateien ziemlich umfangreich sein, daher sollten große Substitutions-Datasets sowie die Möglichkeit, benutzerdefinierte Data-Substitutionssets anzuwenden, ein Schlüsselelement der Bewertungskriterien für jede Datenmaskierungslösung sein.
Mischen
Die Shuffling-Methode ist eine sehr verbreitete Form der Datenverschleierung. Sie ähnelt der Ersetzungsmethode, leitet jedoch den Ersetzungssatz aus derselben Datenspalte ab, die maskiert wird. In sehr einfachen Worten werden die Daten innerhalb der Spalte zufällig gemischt. Bei isolierter Verwendung kann jedoch jeder, der die Originaldaten kennt, ein "Was-wäre-wenn"-Szenario auf den Datensatz anwenden und dann eine echte Identität wieder zusammensetzen. Das Umordnungsverfahren kann auch umgekehrt werden, wenn der Umordnungsalgorithmus entschlüsselt werden kann.
Das Mischen hat jedoch in bestimmten Bereichen einige echte Stärken. Wenn zum Beispiel die Jahresendzahlen für Finanzinformationen in einer Testdatenbank stehen, kann man die Namen der Lieferanten maskieren und dann den Wert der Konten durch die maskierte Datenbank mischen. Es ist sehr unwahrscheinlich, dass irgendjemand, selbst jemand mit genauer Kenntnis der Originaldaten, einen echten Datensatz auf seine ursprünglichen Werte zurückführen könnte.
Nummern- und Datumsabweichung
Die numerische Varianzmethode ist sehr nützlich für die Anwendung auf finanz- und datumsgesteuerte Informationsfelder. Tatsächlich kann ein Verfahren, das diese Art der Maskierung verwendet, immer noch einen sinnvollen Bereich in einem Finanzdatensatz wie der Gehaltsabrechnung hinterlassen. Wenn die angewendete Varianz etwa +/- 10 % beträgt, ist dies immer noch ein sehr aussagekräftiger Datensatz in Bezug auf die Gehaltsspannen, die an die Empfänger gezahlt werden.
Gleiches gilt auch für die Datumsangaben. Wenn der Gesamtdatensatz die Integrität der demografischen und versicherungsmathematischen Daten bewahren muss, würde die Anwendung einer zufälligen numerischen Varianz von +/- 120 Tagen bis heute die Datumsverteilung beibehalten, aber immer noch die Rückverfolgbarkeit zu einer bekannten Entität basierend auf ihrer bekannten tatsächliches Datum oder Geburtsdatum oder ein bekannter Datumswert für den maskierten Datensatz.
Verschlüsselung
Die Verschlüsselung ist oft der komplexeste Ansatz zur Lösung des Datenmaskierungsproblems. Der Verschlüsselungsalgorithmus erfordert oft , dass ein „Schlüssel“ , um die Daten auf Benutzerrechte basierend anzuzeigen angewandt werden. Das klingt oft nach der besten Lösung, aber in der Praxis kann der Schlüssel dann an Personal ohne die entsprechenden Rechte zum Einsehen der Daten ausgegeben werden. Dies verfehlt dann den Zweck der Maskierungsübung. Alte Datenbanken können dann mit den ursprünglichen Zugangsdaten des mitgelieferten Schlüssels kopiert werden und das gleiche unkontrollierte Problem besteht weiter.
In letzter Zeit wurde das Problem der Verschlüsselung von Daten unter Wahrung der Eigenschaften der Entitäten anerkannt und von den Anbietern und der Wissenschaft neu erworben. Eine neue Herausforderung brachte Algorithmen hervor, die eine formaterhaltende Verschlüsselung durchführen . Sie basieren auf dem anerkannten algorithmischen AES-Modus, der sie von NIST erkennt .
Nullung oder Löschung
Manchmal wird ein sehr vereinfachter Ansatz für die Maskierung verwendet, indem einem bestimmten Feld ein Nullwert zugewiesen wird. Der Nullwertansatz ist wirklich nur sinnvoll, um die Sichtbarkeit des Datenelements zu verhindern.
In fast allen Fällen verringert es den Grad der Datenintegrität , der im maskierten Datensatz aufrechterhalten wird. Dies ist kein realistischer Wert und schlägt dann bei jeder Anwendungslogikvalidierung fehl, die möglicherweise in der Front-End-Software des zu testenden Systems angewendet wurde. Es zeigt auch jedem, der Identitätsdaten zurückentwickeln möchte, dass die Datenmaskierung bis zu einem gewissen Grad auf den Datensatz angewendet wurde.
Ausmaskieren
Das Verschlüsseln oder Ausblenden von Zeichen aus bestimmten Feldern ist auch eine weitere einfache, aber sehr effektive Methode, um zu verhindern, dass sensible Informationen angezeigt werden. Es ist wirklich eine Erweiterung der vorherigen Methode zum Nullen, aber es wird mehr Wert darauf gelegt, die Daten echt zu halten und nicht alle zusammen vollständig zu maskieren.
Dies wird häufig auf Kreditkartendaten in Produktionssystemen angewendet. Zum Beispiel könnte ein Operator in einem Callcenter einen Artikel über die Kreditkarte eines Kunden abrechnen. Sie geben dann eine Abrechnungsreferenz für die Karte mit den letzten 4 Ziffern von XXXX XXXX xxxx 6789 an. Als Betreiber können sie nur die letzten 4 Ziffern der Kartennummer sehen, aber sobald das Abrechnungssystem die Daten des Kunden für die Aufladung übermittelt, wird die vollständige Nummer wird den Zahlungs-Gateway-Systemen bekannt gegeben.
Dieses System ist für Testsysteme nicht sehr effektiv, aber für das oben beschriebene Abrechnungsszenario sehr nützlich. Es ist auch allgemein als dynamisches Datenmaskierungsverfahren bekannt.
Zusätzliche komplexe Regeln
In jede Maskierungslösung können auch zusätzliche Regeln einfließen, unabhängig davon, wie die Maskierungsverfahren aufgebaut sind. Produktunabhängige Whitepapers sind eine gute Informationsquelle, um einige der komplexeren Anforderungen für Enterprise-Maskierungslösungen zu untersuchen, darunter zeileninterne Synchronisierungsregeln, tabelleninterne Synchronisierungsregeln und Tabelle-zu-Tabellen-Synchronisierungsregeln.
Verschiedene Typen
Datenmaskierung ist eng mit Gebäudetestdaten gekoppelt. Zwei Haupttypen der Datenmaskierung sind die statische und die spontane Datenmaskierung.
Statische Datenmaskierung
Statische Datenmaskierung wird normalerweise auf der goldenen Kopie der Datenbank durchgeführt, kann aber auch auf Werte in anderen Quellen, einschließlich Dateien, angewendet werden. In DB-Umgebungen laden Produktions-DBAs normalerweise Tabellensicherungen in eine separate Umgebung, reduzieren den Datensatz auf eine Teilmenge, die die für eine bestimmte Testrunde erforderlichen Daten enthält (eine Technik namens "Teilmenge"), wenden Datenmaskierungsregeln an, während Daten vorhanden sind stasis, notwendige Codeänderungen aus der Quellcodeverwaltung anwenden und/oder Daten in die gewünschte Umgebung übertragen.
Deterministische Datenmaskierung
Deterministische Maskierung ist der Vorgang, bei dem ein Wert in einer Spalte durch denselben Wert ersetzt wird, egal ob in derselben Zeile, derselben Tabelle, derselben Datenbank/dem selben Schema und zwischen Instanzen/Servern/Datenbanktypen. Beispiel: Eine Datenbank hat mehrere Tabellen mit jeweils einer Spalte mit Vornamen. Bei deterministischer Maskierung wird der Vorname immer durch den gleichen Wert ersetzt – aus „Lynne“ wird immer „Denise“ – wo auch immer „Lynne“ in der Datenbank steht.
Verschleierung statistischer Daten
Es gibt auch Alternativen zur statischen Datenmaskierung, die auf stochastischen Störungen der Daten beruhen, die einige der statistischen Eigenschaften der Originaldaten beibehalten. Beispiele für Methoden zur Verschleierung statistischer Daten sind der differenzielle Datenschutz und die DataSifter- Methode.
On-the-fly-Datenmaskierung
Die On-the-Fly-Datenmaskierung erfolgt beim Übertragen von Daten von Umgebung zu Umgebung, ohne dass die Daten dabei die Festplatte berühren. Die gleiche Technik wird auf die "Dynamische Datenmaskierung" angewendet, jedoch jeweils ein Datensatz. Diese Art der Datenmaskierung ist am nützlichsten für Umgebungen, die kontinuierliche Bereitstellungen durchführen, sowie für stark integrierte Anwendungen. Organisationen, die Continuous Deployment- oder Continuous Delivery- Praktiken anwenden, haben nicht die erforderliche Zeit, um ein Backup zu erstellen und es in die goldene Kopie der Datenbank zu laden. Daher ist es wichtig, kontinuierlich kleinere Teilmengen (Deltas) von maskierten Testdaten aus der Produktion zu senden. In stark integrierten Anwendungen erhalten Entwickler gleich zu Beginn der Entwicklung Feeds von anderen Produktionssystemen, und die Maskierung dieser Feeds wird entweder übersehen und erst später budgetiert, wodurch Unternehmen nicht mehr konform sind. Die On-the-Fly-Datenmaskierung wird unerlässlich.
Dynamische Datenmaskierung
Die dynamische Datenmaskierung ähnelt der On-the-Fly-Datenmaskierung, unterscheidet sich jedoch darin, dass es sich bei der On-the-Fly-Datenmaskierung um das Kopieren von Daten von einer Quelle in eine andere Quelle handelt, damit diese gemeinsam genutzt werden können. Die dynamische Datenmaskierung erfolgt zur Laufzeit, dynamisch und bei Bedarf, sodass keine zweite Datenquelle vorhanden sein muss, in der die maskierten Daten dynamisch gespeichert werden.
Die dynamische Datenmaskierung ermöglicht mehrere Szenarien, von denen sich viele um strenge Datenschutzbestimmungen drehen, zB die Singapore Monetary Authority oder die Datenschutzbestimmungen in Europa.
Die dynamische Datenmaskierung ist attributbasiert und richtliniengesteuert. Zu den Richtlinien gehören:
- Ärzte können die Krankenakten der ihnen zugeordneten Patienten einsehen (Datenfilterung)
- Ärzte können das SSN-Feld in einer Krankenakte nicht einsehen (Datenmaskierung).
Dynamische Datenmaskierung kann auch verwendet werden, um Werte im laufenden Betrieb zu verschlüsseln oder zu entschlüsseln, insbesondere wenn eine formaterhaltende Verschlüsselung verwendet wird .
In den letzten Jahren sind mehrere Standards entstanden, um dynamische Datenfilterung und -maskierung zu implementieren. Beispielsweise können XACML- Richtlinien verwendet werden, um Daten in Datenbanken zu maskieren.
Es gibt sechs mögliche Technologien, um die dynamische Datenmaskierung anzuwenden:
- In der Datenbank: Die Datenbank empfängt die SQL und wendet das Umschreiben auf die zurückgegebene maskierte Ergebnismenge an. Gilt für Entwickler und DBAs, aber nicht für Anwendungen (da Verbindungspools, Anwendungs-Caching und Datenbus die Anwendungsbenutzeridentität vor der Datenbank verbergen und auch eine Beschädigung der Anwendungsdaten verursachen können).
- Netzwerk-Proxy zwischen der Anwendung und der Datenbank: Erfasst die SQL und wendet das Umschreiben auf die Auswahlanforderung an. Anwendbar für Entwickler & DBAs mit einfachen 'Auswahl'-Anfragen, aber nicht für gespeicherte Prozeduren (die der Proxy nur die Exec zu einer Beschädigung der Anwendungsdaten führen).
- Datenbank-Proxy: ist eine Variante des Netzwerk-Proxys. Der Datenbank-Proxy wird normalerweise zwischen Anwendungen/Benutzern und der Datenbank bereitgestellt. Anwendungen und Benutzer stellen über den Datenbanksicherheitsproxy eine Verbindung zur Datenbank her. Es gibt keine Änderungen an der Art und Weise, wie Anwendungen und Benutzer eine Verbindung zur Datenbank herstellen. Der Agent muss auch nicht auf dem Datenbankserver installiert werden. Die SQL-Abfragen werden neu geschrieben, aber wenn diese Art der dynamischen Datenmaskierung implementiert ist, wird sie auch innerhalb von Store-Prozeduren und Datenbankfunktionen unterstützt.
- Netzwerk-Proxy zwischen dem Endbenutzer und der Anwendung: Identifizieren von Textzeichenfolgen und Ersetzen dieser. Diese Methode ist für komplexe Anwendungen nicht anwendbar, da sie leicht zu Beschädigungen führen kann, wenn die Echtzeit-String-Ersetzung unbeabsichtigt angewendet wird.
- Codeänderungen in den Anwendungen & XACML: Codeänderungen sind in der Regel schwer durchzuführen, unmöglich zu warten und für gepackte Anwendungen nicht anwendbar.
- Innerhalb der Anwendungslaufzeit: Durch die Instrumentierung der Anwendungslaufzeit werden Richtlinien definiert, um das von den Datenquellen zurückgegebene Resultset neu zu schreiben, während der Anwendungsbenutzer volle Transparenz hat. Diese Methode ist die einzig anwendbare Möglichkeit, komplexe Anwendungen dynamisch zu maskieren, da sie die Kontrolle über die Datenanforderung, das Datenergebnis und das Benutzerergebnis ermöglicht.
- Unterstützt durch ein Browser-Plugin: Bei SaaS oder lokalen Webanwendungen können Browser-Add-Ons so konfiguriert werden, dass sie Datenfelder entsprechend präziser CSS-Selektoren maskieren . Dies kann entweder durch das Markieren sensibler Felder in der Anwendung erfolgen, beispielsweise durch eine HTML-Klasse, oder durch das Auffinden der richtigen Selektoren, die die zu verschleiernden oder zu maskierenden Felder identifizieren.
Datenmaskierung und die Cloud
In den letzten Jahren entwickeln Unternehmen ihre neuen Anwendungen immer häufiger in der Cloud, unabhängig davon, ob die endgültigen Anwendungen in der Cloud oder vor Ort gehostet werden. Mit den Cloud-Lösungen können Unternehmen ab sofort Infrastructure as a Service , Platform as a Service und Software as a Service nutzen . Es gibt verschiedene Möglichkeiten, Testdaten zu erstellen und von lokalen Datenbanken in die Cloud oder zwischen verschiedenen Umgebungen innerhalb der Cloud zu verschieben. Die dynamische Datenmaskierung wird in der Cloud noch wichtiger, wenn Kunden PII-Daten schützen müssen, während sie sich auf Cloud-Anbieter verlassen, um ihre Datenbanken zu verwalten. Die Datenmaskierung wird in SDLC unweigerlich zu einem Teil dieser Prozesse, da die SLAs der Entwicklungsumgebungen normalerweise nicht so streng sind wie die SLAs der Produktionsumgebungen, unabhängig davon, ob die Anwendung in der Cloud oder lokal gehostet wird.