Grundlegende Prinzipien der dynamischen Maskierung
Einführung
Dieses Dokument beschreibt, wie DataSunrise die Prinzipien der dynamischen Datenmaskierung für sensible Daten im laufenden Betrieb umsetzt und wie die Maskierung für SQL– und NoSQL-Datenbanktypen durchgeführt wird.
Prinzipien der Datenmaskierung
Lassen Sie uns von vorne beginnen und sich mit zwei grundlegenden Prinzipien der Datenmaskierung in der Datenbank vertraut machen:
- Maskierungsmethode basierend auf der Modifikation von Abfrageergebnismengen
- Maskierungsmethode basierend auf der SQL-Abfragemodifikation
DataSunrise verwendet beide Ansätze für verschiedene Arten von DBMS. DataSunrise modifiziert eine SQL-Abfrage selbst, wo es möglich ist, und in denjenigen DBMSs, die nur wenige Sprachmerkmale haben (zum Beispiel NoSQL-Datenbanken), wird die Modifizierung der Ergebnismenge verwendet.
Lassen Sie uns die Vor- und Nachteile beider Maskierungsmethoden betrachten.
Maskierungsmethode basierend auf der Modifikation von Abfrageergebnismengen
Bei diesem Ansatz erhält die Datenbank die ursprüngliche Abfrage und gibt die Daten wie gewohnt zurück:
Alles sieht einfach und logisch genug aus. Lassen Sie uns nun die Details dieses Ansatzes betrachten:
Wie verarbeitet man von der Funktion zurückgegebene Daten? Zum Beispiel folgendes Szenario:
SELECT anyFunction(email) FROM customers;
Verschiedene Zeichenkettenmodifikationsmethoden wie Verkettung oder Casting einer Zeichenkette in Klein-/Großbuchstaben, Erhalten eines Teilstrings, etc. stehen ebenfalls im Zusammenhang mit diesem Fall.
Es gibt keine Möglichkeit, Daten zu verschleiern, die nicht an die Clientanwendung 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 Quelldaten in den erstellten Tabellen gespeichert, was zu einem Datenleck führt.
Weit verbreitete Clientanwendungen verwenden selten isolierte Abfragen. Normalerweise werden Abfragen eine nach der anderen ausgeführt, und die Ergebnismenge der ersten Abfrage wird in einer zweiten Abfrage und so weiter verwendet. Wenn wir einen solchen Fall betrachten, bei dem das Schlüsselfeld maskiert ist, dann wird es notwendig, die Abfrage zu modifizieren, damit die Anwendung weiterhin korrekt funktioniert. Zum Beispiel empfängt eine Anwendung eine Liste maskierter E-Mail-Adressen, die als Bedingung zur Datenabrufung verwendet wird:
SELECT * FROM demotest.customers WHERE email=’[email protected]’;
SELECT * FROM demotest.customers WHERE email=?; -- ? steht für gebundene Variable
Da die Tabelle einen solchen E-Mail-Wert nicht enthält, wird die Logik einer Clientanwendung unterbrochen. Weil eine Clientanwendung auf die Informationen durch den Schlüsselwert warten wird, den eine Clientanwendung zuvor erhalten hat.
Fazit: Aus den beschriebenen Situationen können Sie sehen, dass es ein kompliziertes (und manchmal sogar unmögliches) Ziel ist, die Datenmaskierungsmethode bereitzustellen, die den Arbeitsprozess einer Clientanwendung nicht beeinflusst.
Maskierungsmethode basierend auf der SQL-Abfragemodifikation
Bei diesem Ansatz wird der Text der SQL-Abfrage modifiziert. Spezielle Konstrukte werden in die Abfrage eingebaut, die die Extraktion sensibler Daten aus der Datenbank verhindern:
Im einfachen Fall sieht die Umwandlung so aus:
SELECT email FROM customers -> SELECT ‘masked’ FROM customers;
Auf diese Weise verlassen sensible Daten, die maskiert werden sollen, nicht die Datenbank. Es löst auch alle Hauptprobleme der Datenverschleierung:
Bereits verschleierte Daten werden den Funktionen zur Verfügung gestellt:
SELECT anyFunction(‘masked’) FROM customers;
SELECT anyFunction(maskFunction(email)) FROM customers;
Auf die gleiche Weise ist die Datenverschleierung auch für Operationen möglich, die intern in der Datenbank durchgeführt werden:
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
Es besteht auch die Möglichkeit, die Spalten zu maskieren, die nicht nur im Select-Teil der Abfrage, sondern auch im bedingten Teil der Abfrage z.B. Where/Join angegeben wurden. So wird die Arbeitslogik der Client-Anwendung nicht beeinträchtigt.
Hauptabschnitte der dynamischen Datenmaskierungsregel
In diesem Abschnitt bieten wir Screenshot-Beispiele dafür, wie diese Parameter den Arbeitsprozess mit der Datenbank beeinflussen, 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 sieht.
Um ein solches Szenario durchzuführen, werden wir unsere Testtabelle verwenden, 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. Gemäß unserem Szenario sollte die „Karte“-Spalte maskiert werden. Dazu wird eine dynamische Maskierungsregel erstellt. In der Konfiguration der dynamischen Maskierungsregel wird festgelegt, dass die „Karte“-Spalte mit der integrierten Kreditkartenmaskierungsmethode maskiert wird. Werfen wir einen kurzen Blick auf die Einstellungen der Regel. Es gibt Abschnitte der Regel:
Hauptabschnitt. Hier werden Name der Regel, Datenbanktyp und die Datenbank selbst angegeben.
Aktionsabschnitt. Dieser Abschnitt enthält die in der Liste genannten Optionen. Wir werden diese Optionen ändern, während wir das Szenario durchgehen und nachvollziehen, wie sich Änderungen auf die Ergebnisse und die Leistung der Abfragen zur Kundentabelle auswirken. Zu Beginn werden alle Optionen als Standard belassen.
Sitzungsfilterabschnitt und Maskierungseinstellungen. Wenn Filter angegeben sind, wird die Regel nur ausgelöst, wenn die Bedingung die Anforderungen erfüllt. In jedem anderen Fall wird die Regel nicht ausgelöst. Da wir keine Filter angegeben haben, wird die Regel immer funktionieren, bei jeder Abfrage, die auf die Kundentabelle abzielt.
Auch die Kreditkartenmaskierungsmethode wird für die Spalte der Kundentabelle ausgewählt.
Nun, da die Regel konfiguriert ist, lassen Sie uns versuchen, 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 „Karte“-Spalte gemäß der Regelkonfiguration maskiert.
Hauptoptionen der dynamischen Datenmaskierungsregel
Spalten zur Maskierung
Es ist einfach, dieser Parameter ist für die Spalten verantwortlich, die maskiert werden.
Maskierungsalgorithmus
Dies ist der Algorithmus, der bei der Spaltenmaskierung verwendet wird. Der gewählte Algorithmus hat direkten Einfluss auf den Wert, der bei dem Versuch, maskierte Spaltenwerte abzurufen, zurückgegeben wird.
Hier ist die beispielhafte Liste der mit DataSunrise möglicherweise verwendeten Maskierungsalgorithmen (um weitere Informationen zu anderen Maskierungsalgorithmen zu erhalten, lesen Sie bitte unser Benutzerhandbuch auf S. 148, wo Sie eine detaillierte Erklärung dazu finden):
Kreditkartennummer – Algorithmus ist darauf ausgelegt, Kreditkartennummern zu maskieren. Es 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 Domain-Abschnitt von E-Mail-Adressen werden mit “*” ersetzt, außer dem ersten und letzten Zeichen in einer Reihe. Zum Beispiel: a***@**.**m.
Feste Zeichenkette – STRING-Typ-Werte werden mit einer benutzerdefinierten Zeichenkette ersetzt.
Die DataSunrise Security Suite unterstützt auch benutzerdefinierte Funktionen (Funktionen, die in der Datenbank angegeben sind) als Maskierungsmethode sowie LUA-Skripte, die direkt in der DataSunrise-WebUI-Umgebung erstellt werden.
Sitzungsfilter
Dieser Parameter kann spezifiziert werden, um das Verhalten einer dynamischen Maskierungsregel entsprechend verschiedenen Bedingungen zu konfigurieren. Hier ist die Liste der Bedingungsparameter:
Anwendung – Name der Clientanwendung
Anwendungsbenutzer – Name des Anwendungsbenutzers
DB-Benutzer – Name des DB-Benutzers
Host – IP-Adresse oder Alias von wo der Benutzer oder die Anwendung sich mit der Datenbank verbindet
OS-Benutzer – Name des Betriebssystembenutzers
Proxy – DataSunrise-Proxy, wo die Regel funktionieren soll, falls viele Proxies konfiguriert wurden
Zum Beispiel möchten Sie Daten für den DB-Gastbenutzer maskieren und keine Daten für den DB-Admin-Benutzer maskieren, was verständlich ist. In diesem Fall geben Sie einfach an, dass der DB-Benutzer “Gast” ist und die Maskierungsregel wird nur ausgelöst, wenn der Gastbenutzer Abfragen zu maskierten Spalten der Tabelle ausführt.
Zeilenanzahl beibehalten
Diese Option ist verantwortlich für die Maskierung von Werten, die in where, join etc. Klauseln der Abfragen verwendet werden:
wenn deaktiviert, werden die Felderwerte, die maskiert werden sollen, maskiert, selbst wenn sie in der WHERE/JOIN-Klausel verwendet werden.
wenn aktiviert, wird die Maskierung der in den genannten Klauseln verwendeten Werte deaktiviert. Die zurückgegebene Ergebnismenge wird die gleiche Anzahl von Zeilen enthalten, wie sie zurückgegeben würde, wenn keine Maskierungsregel angewendet wurde. Diese Option hilft dabei, dieselbe Zeilenanzahl zu erhalten, selbst wenn Daten maskiert sind, da ihre realen Werte in der WHERE/JOIN-Klausel der Abfrage verwendet werden können.
Um die Situation besser zu verstehen, nehmen wir an, dass ich einen Teil einer Kartennummer kenne und er lautet 4024. Wir haben zwei Kunden, deren Kreditkartennummer diese Nummer enthält:
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Lassen Sie uns sehen, was passiert, wenn die Option deaktiviert ist: Die Abfrage wird keine Ergebnisse zurückgeben, da die Ergebnisse maskiert sind und die Anwendung solche Felder nicht finden kann. Lassen Sie uns sehen, was passiert, wenn die Option aktiviert ist: Wie Sie hier sehen können, auch wenn die Ergebnisse maskiert sind, können wir immer noch 4024 verwenden, um Karten zu finden, die diesen Teil enthalten, aber wir können es nicht im Ergebnisset sehen. Dieser Parameter ist dafür verantwortlich, die Werte bestimmter Spalten NUR zu maskieren, wenn die Daten durch den Abfragetyp SELECT abgerufen werden. Lassen Sie uns sehen, wie das funktioniert: Wie Sie hier sehen können, wurden die Kartenwerte durch eine SELECT-Anweisung abgerufen und gemäß der Regel ist die Spalte “Karte” maskiert. Jetzt lassen Sie uns versuchen, die nächste Abfrage auszuführen und sehen, was passiert: Im Ergebnis enthält die Spalte „State“ nun die echten Werte der maskierten „Karte“-Spalte, da keine SELECT-Abfragetyp ausgeführt wurde. Wird jedoch eine SELECT-Abfrage für die maskierte Spalte ausgeführt, wird sie weiterhin maskiert sein. Das Ziel dieses Parameters wird durch seinen Namen erklärt. Es ist auch ein Kontrollkästchen, das standardmäßig beim Erstellen einer dynamischen Maskierungsregel aktiviert ist. Falls es eine Abfrage an den DataSunrise-Proxy geht und eine Abfrage darauf abzielt, den Wert in der maskierten Spalte zu ändern, wird eine solche Abfrage blockiert. Lassen Sie uns versuchen, eine Abfrage auszuführen, deren Ziel es ist, eine Kartennummer mit der nächsten Abfrage zu ändern: Im Ergebnis wird “Die Abfrage ist blockiert” zurückgegeben. Die Funktion der dynamischen Maskierung ist eine der am häufigsten verwendeten Funktionen unseres Produkts. Diese Funktion hilft dabei, sensible Daten der geschützten Datenbank gemäß der von Benutzern festgelegten Regelkonfiguration zu maskieren. DataSunrise verwendet die geeignetsten Ansätze, um sensible Daten zu maskieren, indem die beste Lösung sowohl für SQL-basierte als auch für NoSQL-Datenbanken gewählt wird. Dynamische Maskierungsregeln haben viele Optionen, die von einem Benutzer konfiguriert werden können. Die wichtigsten davon sind:
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card
FROM demotest.democust
WHERE card LIKE '%4024%';
no rows selected.
SQL> SELECT order_id, first_name, last_name, address, state, zip, email, card
FROM demotest.democust
WHERE card LIKE '%4024%';
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
3,427 Mary Evans 13 The Limes, Leighton OR 10950 [email protected] XXXX-XXXX-XXXX-9980
2 rows selected.
Nur SELECTs maskieren
SQL> SELECT card FROM demotest.democust;
CARD
-------------------
XXXX-XXXX-XXXX-6700
XXXX-XXXX-XXXX-8094
XXXX-XXXX-XXXX-9980
3 rows selected.
SQL> UPDATE demotest.democust SET state = card;
3 rows updated.
SQL> SELECT order_id, first_name, last_name, state, zip, card FROM demotest.democust;
ORDER_ID FIRST_NAME LAST_NAME STATE ZIP CARD
--------- ---------- --------- ------------------- -------- -------------------
1,121 Kathy Abrams 4024-0071-8423-6700 132068 XXXX-XXXX-XXXX-6700
4,667 Alma Wade 6011-0551-9875-8094 21771 XXXX-XXXX-XXXX-8094
3,427 Mary Evans 4485-4392-7160-9980 10950 XXXX-XXXX-XXXX-9980
3 rows selected.
Eine Abfrage blockieren, wenn die maskierte Spalte sich auf eine Datenänderung bezieht
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%';
ERROR at line 1:
SQL Error [42501]: The query is blocked
Fazit