Grundprinzipien der dynamischen Maskierung
Einführung
Dieses Dokument beschreibt, wie DataSunrise sensible Daten on-the-fly maskiert und wie die Maskierung für SQL- und NoSQL-Datenbanktypen durchgeführt wird.
Datenmaskierungsprinzipien
Lassen Sie uns von Anfang an beginnen und uns mit zwei grundlegenden Prinzipien der Datenmaskierung in der Datenbank vertraut machen:
- Maskierungsmethode basierend auf der Modifikation von Abfrageergebnisssätzen
- Maskierungsmethode basierend auf der Modifikation von SQL-Abfragen
DataSunrise verwendet beide Ansätze für verschiedene Arten von DBMS. DataSunrise ändert eine SQL-Abfrage selbst, wo es möglich ist, und in den DBMS, die ziemlich 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 normalerweise der Fall ist:
Alles sieht einfach und logisch genug aus. Jetzt werfen wir einen Blick auf die Details dieses Ansatzes:
Wie soll man Daten verarbeiten die durch die Funktion zurückgegeben werden? Z.B. Fall:
SELECT anyFunction(email) FROM customers;
Zu diesem Fall gehören auch verschiedene Methoden zur Modifikation von Zeichenketten wie Konkatenation oder Umwandlung einer Zeichenkette in Klein-/Großbuchstaben, das Erhalten eines Teilstrings usw.
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 Originaldaten in den erstellten Tabellen gespeichert, was zu einem Datenverlust führt.
Weit verbreitete Client-Anwendungen verwenden selten isolierte Abfragen. Normalerweise werden Abfragen nacheinander ausgeführt und das Ergebnis der ersten Abfrage wird in einer zweiten Abfrage usw. verwendet. Wenn wir einen solchen Fall betrachten, bei 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 einen solchen E-Mail-Wert nicht enthält, wird die Logik der Client-Anwendung zerbrechen. Denn eine Client-Anwendung wird auf die Information durch den Schlüsselwert warten, den eine Client-Anwendung zuvor erhalten hat.
Als Schlussfolgerung können Sie aus den beschriebenen Situationen sehen, dass es eine komplizierte (und manchmal sogar unmögliche) Aufgabe ist, die Datenmaskierungsmethode bereitzustellen, die den Arbeitsprozess einer Client-Anwendung 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;
Daher verlassen sensible Daten, die maskiert werden sollen, die Datenbank nicht. Es löst auch alle Hauptprobleme der Datenverschleierung:
Bereits verschleierte Daten werden an Funktionen geliefert:
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 durchgeführt werden:
CREATE TABLE customers2 AS SELECT maskFunction(email) FROM customers;
Es besteht auch die Möglichkeit, Spalten zu maskieren, die nicht nur im select Teil der Abfrage, sondern auch im bedingten Teil der Abfrage wie z. B. where/join angegeben wurden. So wird die Arbeitslogik der Client-Anwendung nicht beeinträchtigt.
Hauptabschnitte einer Regel zur dynamischen Datenmaskierung
In diesem Abschnitt werden wir Screenshot-Beispiele dafür geben, wie diese Parameter den Arbeitsprozess mit der Datenbank beeinflussen, wenn die Regel zur dynamischen Maskierung aktiv ist.
Stellen Sie sich die Situation vor, in der wir wollen, dass jemand, der mit der Datenbank und der Kundentabelle arbeitet, die Kreditkartendaten, die in der Tabelle enthalten sind, nicht sehen kann.
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 Spalte “card” maskiert werden. Um dies zu tun, wird eine Regel für die dynamische Maskierung erstellt. In der Konfiguration der dynamischen Maskierungsregel wird eingestellt, dass die Spalte “Card” mit der eingebauten Methode zur Maskierung von Kreditkarten maskiert wird. Werfen wir einen schnellen Blick auf die Einstellungen der Regel. Es gibt Abschnitte der Regel:
Hauptabschnitt. Der Name der Regel, der Datenbanktyp und die Datenbank selbst werden hier angegeben.
Aktionsabschnitt. Dieser Abschnitt enthält Optionen, die in der Liste erwähnt wurden. Wir werden diese Optionen im Verlauf des Szenarios ändern und nachverfolgen, wie die Änderungen die Ergebnisse und die Leistung der Abfragen zur Kundentabelle beeinflussen. Am Anfang bleiben alle Optionen standardmäßig.
Sitzungsfilterabschnitt und Maskierungseinstellungen. Wenn irgendwelche 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 arbeiten, bei jeder Abfrage, die auf die Kundentabelle abzielt.
Außerdem ist die Kreditkartenmaskierungsmethode für die Spalte der Kundentabelle ausgewählt.
Jetzt, wo die Regel konfiguriert ist, versuchen wir die gleiche Abfrage durchzufü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 Kartenkolonne entsprechend der Konfiguration der Regel maskiert.
Hauptoptionen der Regel zur dynamischen Datenmaskierung
Spalten zur Maskierung
Dies ist einfach, dieser Parameter ist verantwortlich für die Spalten, die maskiert werden.
Maskierungsalgorithmus
Dies ist der Algorithmus, der bei der Maskierung von Spalten verwendet wird. Der gewählte Algorithmus beeinflusst direkt den zurückgegebenen Wert beim Versuch, die Werte der maskierten Spalten abzurufen.
Hier ist eine Beispiel-Liste von Maskierungsalgorithmen, die mit DataSunrise verwendet werden können (um Informationen über andere Maskierungsalgorithmen zu erhalten, ziehen Sie bitte unseren Benutzerleitfaden S. 148 heran, in dem eine detaillierte Erläuterung dazu zu finden ist):
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 Domain-Bereich von E-Mail-Adressen werden durch “*”, bis auf den ersten und den letzten in einer Reihe, ersetzt. Zum Beispiel: a***@**.**m.
Feste Zeichenkette – Zeichenkettenwerte vom Typ STRING werden durch eine vom Benutzer vordefinierte Zeichenkette ersetzt.
DataSunrise Security Suite unterstützt auch benutzerdefinierte Funktionen (Funktionen, die in der Datenbank angegeben sind), die als Maskierungsmethode verwendet werden können und LUA-Skripte, die direkt in der DataSunrise WebUI-Umgebung erstellt werden.
Sitzungsfilter
Dieser Parameter kann angegeben werden, um das Verhalten einer dynamischen Maskierungsregel gemäß den unterschiedlichen 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 dem aus der Benutzer oder die Anwendung sich mit der Datenbank verbindet
Betriebssystem-Benutzer – Name des Betriebssystem-Benutzers
Proxy – DataSunrise-Proxy, in dem die Regel arbeiten soll, falls mehrere Proxies konfiguriert wurden
Zum Beispiel wollen Sie Daten für den DB Gastbenutzer maskieren und Sie wollen nicht Daten für DB Admin Benutzer maskieren, was verständlich ist. In diesem Fall geben Sie nur an, dass DB-Benutzer “Gast” gleich sind und die Maskierungsregel wird nur dann ausgelöst, wenn der Gastbenutzer Abfragen zu den Maskierungsspalten der Tabelle durchführt.
Beibehaltung der Zeilenzahl
Diese Option ist verantwortlich für die Maskierung von Werten, die in wo, join usw. Klauseln der Abfragen verwendet werden:
wenn deaktiviert, werden die Werte der Felder maskiert, die maskiert werden sollen, auch wenn sie in der WHERE/JOIN-Klausel verwendet werden.
wenn aktiviert, wird die Maskierung von Werten, die in den genannten Klauseln verwendet werden, deaktiviert. Der zurückgegebene Ergebnissatz wird die gleiche Zeilenzahl enthalten, wie sie zurückgegeben worden wäre, wenn keine Maskierungsregel angewendet worden wäre. Diese Option hilft dabei, die gleiche Zeilenzahl zu erhalten, auch wenn Daten maskiert sind, weil ihre realen Werte in WHERE/JOIN-Klauseln der Abfrage verwendet werden können.
Um die Situation genauer zu verstehen, gehen wir davon aus, dass ich einen Teil einer Kreditkartennummer kenne und es ist 4024. Wir haben zwei Kunden, deren Kreditkartennummer diese Nummer enthält:
Kathy Abrams 4024-0071-8423-6700
Mary Evans 4024-0071-2955-9980
Sehen wir uns an, was passiert, wenn die Option deaktiviert ist: Die Abfrage liefert keine Ergebnisse, 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 sehen können, obwohl die Ergebnisse maskiert sind, können wir immer noch 4024 verwenden, um Karten zu finden, die einen solchen Teil enthalten, können ihn aber nicht im Ergebnissatz sehen. Dieser Parameter ist dafür verantwortlich, nur Teile der Abfrage auszuwählen. Wenn diese Option aktiv ist, werden nur diejenigen Spalten maskiert, die nach dem SELECT-Statement stehen und in der Regel angegeben sind. Diese Option ist auch wichtig für diejenigen, die Client-Anwendungen verwenden, die automatisch generierte Abfragen für z.B. UPDATE TABLE-Aussagen erstellen. Denn alle Operationen mit den Daten des maskierten Tabellen werden in keiner Weise betroffen sein, aber sichtbar gemacht werden, wenn 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 Regel zur dynamischen Maskierung 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. Versuchen wir, eine Abfrage durchzuführen, die darauf abzielt, eine Kartennummer zu ändern, mit der folgenden Abfrage: Wie das Ergebnis zurückgegeben wurde, ist “Die Abfrage ist blockiert”. 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 vom Benutzer festgelegten Regelkonfiguration zu maskieren. DataSunrise verwendet die geeignetsten Ansätze, um sensible Daten zu maskieren, indem es die beste Lösung sowohl für SQL-basierte Datenbanken als auch für NoSQL-Datenbanken wählt. Regeln zur dynamischen Maskierung 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 Reihen ausgewählt.
Maskieren Sie nur SELECTs
Abfrage blockieren, wenn die maskierte Spalte mit einer Datenänderung verbunden ist
SQL> UPDATE demotest.democust SET card = '1234' WHERE card LIKE '%6700%';
FEHLER in Zeile 1:
SQL-Fehler [42501]: Die Abfrage ist blockiert
Schlussfolgerung