Grundprinzipien der dynamischen Maskierung
Einführung
Dieses Dokument beschreibt, wie DataSunrise sensible Daten in Echtzeit maskiert und wie die Maskierung für SQL- und NoSQL-Datenbanktypen durchgeführt wird.
Prinzipien der Datenmaskierung
Beginnen wir am Anfang und machen uns vertraut mit den zwei Grundprinzipien der Datenmaskierung in der Datenbank:
- Maskierungsmethode basierend auf der Modifikation von Abfrageergebnissätzen
- Maskierungsmethode basierend auf der Modifikation von SQL-Abfragen
DataSunrise verwendet beide Ansätze für verschiedene Arten von DBMS. DataSunrise modifiziert eine SQL-Abfrage selbst, wo dies möglich ist, und in denjenigen DBMSs, die recht viele Sprachfunktionen haben (zum Beispiel NoSQL-Datenbanken), wird die Modifikation des Ergebnissatzes verwendet.
Werfen wir einen Blick auf die Vor- und Nachteile beider Maskierungsmethoden.
Maskierungsmethode basierend auf der Modifikation von Abfrageergebnissätzen
Mit diesem Ansatz erhält die Datenbank die ursprüngliche Abfrage und gibt die Daten zurück, wie es üblicherweise passiert:
Alles sieht einfach und logisch genug aus. Jetzt wollen wir uns die Details dieses Ansatzes genauer ansehen:
Wie sollen die von der Funktion zurückgegebenen Daten verarbeitet werden? Zum Beispiel:
SELECT anyFunction(email) FROM customers;
Verwandte Methoden zur String-Modifikation wie Verknüpfung oder Umwandlung eines Strings in Klein-/Großbuchstaben, Erhalt eines Teilstrings usw. gehören auch zu diesem Fall.
Es gibt keine Möglichkeit, Daten zu verschleiern, die nicht an die Client-Anwendung zurückgegeben wurden. Zum Beispiel:
CREATE TABLE demotest.democust AS SELECT * FROM demotest.customers;
oder
INSERT INTO demotest.democust SELECT * FROM demotest.customers;
In diesen Abfragen werden die Quelldaten in den erstellten Tabellen gespeichert, was zu einem Datenleck führt.
Weit verbreitete Client-Anwendungen verwenden selten isolierte Abfragen. In der Regel werden Abfragen nacheinander ausgeführt und das Ergebnis der ersten Abfrage wird in einer zweiten Abfrage und so weiter verwendet. Wenn wir einen solchen Fall betrachten, in dem das Schlüsselfeld maskiert ist, wird für das korrekte Arbeiten der Anwendung eine Abfragemodifikation notwendig. Zum Beispiel erhält eine Anwendung eine Liste von maskierten E-Mail-Adressen, die als Bedingung zum Abrufen von Daten verwendet wird:
SELECT * FROM demotest.customers WHERE email=’[email protected]’;
SELECT * FROM demotest.customers WHERE email=?; -- ? steht für gebundene Variable
Da die Tabelle solche E-Mail-Werte nicht enthält, wird die Programmlogik der Client-Anwendung unterbrochen. Da eine Client-Anwendung auf die Information durch den zuvor vom Client erhaltenen Schlüsselwert wartet.
Aus den beschriebenen Situationen kann man abschliessen, dass es eine komplizierte (und manchmal sogar unmögliche) Aufgabe ist, eine Datenmaskierungsmethode zu liefern, die den Arbeitsprozess einer Client-Anwendung nicht beeinflusst.
Maskierungsmethode basierend auf SQL-Abfragemodifikation
In diesem Ansatz wird der Text der SQL-Abfrage modifiziert. Spezielle Konstrukte werden in die Abfrage eingebaut, die die Extraktion von sensiblen Daten aus der Datenbank verhindern:
Im einfachsten Fall sieht die Umwandlung so aus:
SELECT email FROM customers -> SELECT ‘masked’ FROM customers;
Daher verlassen sensible Daten, die maskiert werden sollen, die Datenbank nicht. Dies löst auch alle Hauptprobleme der Datenverschleierung:
Bereits verschleierten Daten werden an Funktionen bereitgestellt:
SELECT anyFunction(‘masked’) FROM customers;
SELECT anyFunction(maskFunction(email)) FROM customers;
Die gleiche Art der Datenverschleierung ist möglich für Operationen, die intern in der Datenbank ausgeführt werden:
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
Es gibt auch die Möglichkeit, die Spalten zu maskieren, die nicht nur im select-Teil der Abfrage, sondern auch im Bedingungsteil der Abfrage z.B. where/join angegeben wurden. Damit wird die Arbeitslogik der Client-Anwendung nicht beeinträchtigt.
Hauptabschnitte der Regel für dynamische Datenmaskierung
In diesem Abschnitt zeigen wir Screenshot-Beispiele dafür, wie sich diese Parameter auf den Arbeitsprozess mit der Datenbank auswirken, wenn die dynamische Maskierungsregel aktiv ist.
Stellen wir uns die Situation vor, in der wir möchten, dass jemand, der mit der Datenbank und der Kundentabelle arbeitet, die in der Tabelle enthaltenen Kreditkartendaten nicht sehen kann.
Um dieses Szenario durchzuführen, verwenden wir unsere Testtabelle, die verschiedene Informationen über Kunden enthält:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD
--------- ---------- --------- --------------------- ----- -------- ------------------- -------------------
1,121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] 4024-0071-8423-6700
4,667 Alma Wade Green Lane, Newport NE 21771 [email protected] 6011-0551-9875-8094
3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] 4024-4392-7160-9980
3 rows selected.
Wie Sie sehen können, haben wir 8 Spalten. Entsprechend unserem Szenario soll die “card”-Spalte maskiert werden. Um dies zu tun, wird eine Dynamische Maskierungsregel erstellt. In der Konfiguration der dynamischen Maskierungsregel wird festgelegt, dass die Card-Spalte mit der eingebauten Maskierungsmethode für Kreditkarten maskiert wird. Werfen wir einen kurzen Blick auf die Einstellungen der Regel. Es gibt Abschnitte der Regel:
Hauptabschnitt. Name der Regel, Datenbanktyp und Datenbank selbst werden hier angegeben.
Aktionsabschnitt. Dieser Abschnitt enthält Optionen, die in der Liste erwähnt wurden. Wir werden diese Optionen im Laufe des Szenarios ändern und verfolgen, wie sich die Änderungen auf die Ergebnisse und die Ausführung der Abfragen zur Kundentabelle auswirken. Am Anfang werden alle Optionen als Standard belassen.
Sitzungsfilterabschnitt und Maskierungseinstellungen. Wenn irgendwelche Filter angegeben sind, wird die Regel nur ausgelöst, wenn die Bedingung die Anforderungen erfüllt. In allen anderen Fällen wird die Regel nicht ausgelöst. Da wir keine Filter spezifiziert haben, wird die Regel immer arbeiten, bei jeder Abfrage, die auf die Kundentabelle abzielt.
Ausserdem ist die Kreditkarten-Maskierungsmethode für die Spalte der Kundentabelle ausgewählt.
Jetzt, wo die Regel konfiguriert ist, versuchen wir die gleiche Abfrage auszuführen, um alle Spalten aus der Kundentabelle auszuwählen:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card FROM demotest.democust; ORDER_ID FIRST_NAME LAST_NAME ADDRESS STATE ZIP EMAIL CARD --------- ---------- --------- --------------------- ----- -------- ------------------- ------------------- 1,121 Kathy Abrams High Street, Wheeling MO 132068 [email protected] XXXX-XXXX-XXXX-6700 4,667 Alma Wade Green Lane, Newport NE 21771 [email protected] XXXX-XXXX-XXXX-8094 3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980 3 rows selected.Wie Sie auf dem Screenshot sehen können, wurde die Card-Spalte entsprechend der Konfiguration der Regel maskiert.
Hauptoptionen der dynamischen Datenmaskierungsregel
Spalten zur Maskierung
Es ist einfach, dieser Parameter ist dafür verantwortlich, welche Spalten maskiert werden sollen.
Maskierungsalgorithmus
Dies ist der Algorithmus, der bei der Maskierung von Spalten verwendet wird. Der gewählte Algorithmus beeinflusst direkt den Wert, der beim Versuch, die Werte von maskierten Spalten abzurufen, zurückgegeben wird.
Hier ist eine beispielhafte Liste von Maskierungsalgorithmen, die mit DataSunrise verwendet werden könnten (um sich über andere Maskierungsalgorithmen zu informieren, beziehen Sie sich bitte auf unserem Benutzerhandbuch S. 148, wo Sie eine detaillierte Erklärung dazu finden):
Kreditkartennummer – der Algorithmus dient zur Maskierung von Kreditkartennummern. Er zeigt die letzten vier Ziffern einer Kreditkartennummer an, andere Zeichen werden durch “X” ersetzt. Zum Beispiel: XXXXXXXX-XXXX-1234.
E-Mail-Maskierung – der Benutzername und der Domainbereich von E-Mail-Adressen werden durch “*”, außer das erste und das letzte in einer Reihe, ersetzt. Zum Beispiel: a***@**.**m.
Fester String – STRING-type Werte werden durch einen vom Benutzer vordefinierten String ersetzt.
DataSunrise Security Suite unterstützt auch benutzerdefinierte Funktionen (Funktionen, die in der Datenbank angegeben sind), die als Maskierungsmethode verwendet werden können, sowie LUA-Skripte, die direkt in der DataSunrise WebUI-Umgebung erstellt wurden.
Sitzungsfilter
Dieser Parameter kann festgelegt werden, um das Verhalten der dynamischen Maskierungsregel entsprechend verschiedenen Bedingungen zu konfigurieren. Hier ist die Liste der Bedingungsparameter:
Anwendung – Name der Client-Anwendung
Anwendungsbenutzer – Name des Anwendungsbenutzers
DB Benutzer – Name des DB-Benutzers
Host– IP-Adresse oder Alias, von wo aus der Benutzer oder die Anwendung zur Datenbank verbindet
OS Benutzer – Name des Betriebssystembenutzers
Proxy – DataSunrise Proxy, auf dem die Regel arbeiten soll, falls mehrere Proxies konfiguriert wurden
Wenn Sie zum Beispiel Daten für den DB-Gastbenutzer maskieren möchten und Daten für den DB-Admin-Benutzer nicht maskieren möchten, was verständlich ist, geben Sie einfach DB-Benutzer Equals Guest an und die Maskierungsregel wird nur ausgelöst, wenn der Gastbenutzer Abfragen zu den maskierten Spalten der Tabelle durchführt.
Erhalte Zeilenanzahl
Diese Option ist verantwortlich für die Maskierung von Werten, die in Where, Join usw. Klauseln der Abfragen verwendet werden:
Wenn deaktiviert, werden die Werte der Felder, die maskiert werden sollen, auch maskiert, wenn sie in der WHERE/JOIN-Klausel verwendet werden.
Wenn aktiviert, wird die Maskierung von Werten, die in den erwähnten Klauseln verwendet werden, deaktiviert. Das zurückgegebene Ergebnis wird die gleiche Anzahl von Zeilen enthalten, wie sie zurückgegeben würde, wenn keine Maskierungsregel angewendet wurde. Diese Option hilft, die gleiche Zeilenzahl zu erhalten, auch wenn Daten maskiert sind, weil ihre tatsächlichen Werte in den WHERE/JOIN-Klauseln der Abfrage verwendet werden können.
Um die Situation besser zu verstehen, nehmen wir an, dass ich den Teil einer Kartennummer kenne und dieser lautet 4024. Wir haben zwei Kunden, deren Kreditkartenummer diese Nummer enthält:
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Werfen wir einen Blick darauf, was passiert, wenn die Option deaktiviert ist: Die Abfrage gibt keine Ergebnisse zurück, da die Ergebnisse maskiert sind und die Anwendung solche Felder nicht finden kann. Sehen wir uns an, was passiert, wenn die Option aktiviert ist: Wie Sie hier sehen können, können wir immer noch 4024 verwenden, um Karten zu finden, die diesen Teil enthalten, aber wir können ihn im Ergebnissatz nicht sehen. Dieser Parameter ist dafür verantwortlich, nur SELECT-Teile einer Abfrage zu maskieren. Wenn diese Option aktiv ist, werden nur die Spalten maskiert, die nach der SELECT-Anweisung stehen und in der Regel spezifiziert sind. Diese Option ist auch wichtig für diejenigen, die Client-Anwendungen verwenden, die automatisch generierte Abfragen für z.B. UPDATE TABLE Anweisungen durchführen. Denn alle Operationen mit den Daten der maskierten Tabelle werden in keiner Weise beeinflusst, sondern werden maskiert angezeigt, wenn die Daten ausgewählt werden. Das Ziel dieses Parameters wird durch seinen Namen erklärt. Es handelt sich auch um ein Kontrollkästchen, das standardmäßig beim Erstellen einer dynamischen Maskierungsregel aktiviert ist. Falls eine Abfrage an den DataSunrise-Proxy geht und die Abfrage darauf abzielt, den Wert in der maskierten Spalte zu ändern, wird eine solche Abfrage blockiert. Lassen Sie uns versuchen, eine Abfrage auszuführen, die dazu bestimmt ist, eine Kartennummer zu modifizieren, mit der nächsten Abfrage: Wie Sie sehen, wird als Ergebnis “Die Abfrage wurde blockiert” zurückgegeben. Die Funktion der dynamischen Maskierung ist eine der nützlichsten Funktionen unseres Produkts. Diese Funktion hilft, sensible Daten der geschützten Datenbank entsprechend der vom Benutzer festgelegten Regelnkonfiguration zu maskieren. DataSunrise verwendet die geeignetsten Ansätze zur Maskierung sensibler Daten, indem die beste Lösung sowohl für SQL-basierte Datenbanken als auch für NoSQL-Datenbanken gewählt wird. Dynamische Maskierungsregeln haben viele Optionen, die vom Benutzer konfiguriert werden können. Die wichtigsten davon sind:
SQL> SELECT order_id, first_name, last_name, state, zip, card
FROM demotest.democust
WHERE card LIKE '%4024%';
keine Zeilen ausgewählt.
SQL> SELECT order_id, first_name, last_name, state, zip, card
FROM demotest.democust
WHERE card LIKE '%4024%';
ORDER_ID FIRST_NAME LAST_NAME STATE ZIP CARD
--------- ---------- --------- ------------------- -------- -------------------
1,121 Kathy Abrams 4024-0071-8423-6700 132068 XXXX-XXXX-XXXX-6700
3,427 Mary Evans 4024-0071-2955-9980 10950 XXXX-XXXX-XXXX-9980
2 Zeilen ausgewählt.
Maskiere nur SELECTs
Blockiere eine Abfrage, wenn die maskierte Spalte auf eine Datenänderung bezogen ist
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%';
ERROR at line 1:
SQL Error [42501]: Die Abfrage wurde blockiert
Schlussfolgerung