Dieser Artikel beschreibt eine dynamische Datenmaskierungsmethode (DDM), die für Premium-Websites von IRI FieldShield verfügbar ist und ein Proxy-basiertes System zum Abfangen von Anwendungsabfragen an mit JDBC verbundene Datenbanken verwendet. Dies ist einer von mehreren Ansätzen zum Maskieren von Daten im Flug, die FieldShield-Benutzer in Betracht ziehen können.
Weitere IRI-DDM-Optionen umfassen:API-aufrufbare FieldShield-Funktionen, die in C/C++/C#-, Java- oder .NET-Programme eingebettet sind; Echtzeit-FieldShield-Funktionen, die in SQL-Prozeduren eingebettet sind, die maskierte Ansichten erstellen; und dynamisches Demaskieren von statisch maskierten Tabellen für autorisierte Benutzer.
Das hier vorgestellte Proxy-basierte System verwendet einen zweckmäßigen, datenbankspezifischen „JDBC SQL Trail“-Treiber in Verbindung mit einer Konfigurations- und Verwaltungs-Webanwendung namens SQL Sharp (SQL#). Dieses Diagramm zeigt die Systemarchitektur vor und nach der Implementierung:
Diese Anwendung unterstützt derzeit die folgenden relationalen Datenbankplattformen:
- Oracle 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
und erfordert die folgenden Komponenten von Drittanbietern:
- MS Windows 7,10 oder Server 2012 und höher (getestet).
- Java JDK und JRE 1.8 oder höher.
- Tomcat 8.5 oder höher zum Ausführen des SQL#-Webservers.
- Ein moderner Webbrowser, wie zum Beispiel:
- Google Chrome
- Mozilla Firefox
- Apple-Safari
- Microsoft Edge
- Oracle oder PostgreSQL als zu speichernde Repository-Datenbank:
- SQL# Benutzer- und Gruppenkonfiguration
- DB-Zugriffs- und Aktivitätskontrollen
- Dynamische Datenmaskierungsrichtlinien
- SQL-Audit-Logs
Wie funktioniert es?
Innerhalb der SQL#-Webanwendung erstellen Sie Datenmaskierungsrichtlinien, um Spaltenwerte während der Übertragung für alle außer autorisierten Benutzer zu entfernen, die über den JDBC SQL Trail-Treiber eine Verbindung zur Datenbank herstellen. Sie müssen diesen Treiber für jede zu schützende Datenbankinstanz installieren und konfigurieren.
Die DDM-Richtlinien definieren, welche Tabellen und Spalten maskiert werden und wie die maskierten Werte angezeigt werden. Sobald das System richtig konfiguriert ist, unterliegen alle über den Treiber verbundenen Abfragen der Maskierungsrichtlinie.
Es ist auch möglich, Richtlinien zu definieren, um Benutzer von der Anmeldung und bestimmten SQL-Aktivitäten abzuhalten. Ein vollständiges Anmelde- und SQL-Aktivitätsüberwachungsprotokoll wird erstellt und kann in SQL# angezeigt werden.
Der Treiber unterscheidet nicht zwischen Anwendungsbenutzern für Blockierungs-, Maskierungs- oder Überwachungszwecke. Sie können jedoch speziell benannte Benutzer autorisieren, die alternative Anwendungsserververbindungen zur DB über denselben Treiber herstellen, um Daten unmaskiert anzuzeigen.
Erstellen einer Maskierungsrichtlinie
Um eine Maskierungsrichtlinie in SQL# zu erstellen, verwenden Sie die Maskierungsrichtlinie Registerkarte der SQL#-Ausführungsverwaltung Bildschirm. Wählen Sie + Symbol (Hinzufügen) rechts neben der Liste der Maskierungsregeln Bezeichnung.
Geben Sie der Maskierungsregel einen Namen und optional eine Beschreibung. Sie können dann den Typ der anzuwendenden Maske aus Masing Regex: auswählen Drop-down-Menü unter Maskierungsregel hinzufügen Dialog.
Die ersten drei Optionen sind vordefiniert, während Sie mit Regex ein benutzerdefiniertes Maskierungsformat definieren können. Klicken Sie auf das + (Hinzufügen) rechts neben TAB/COL label, um eine oder mehrere Tabellen- und Spaltenkombinationen hinzuzufügen, um anzugeben, welche Datenwerte maskiert werden.
Nachdem jede Kombination aus Tabelle und Spalten erstellt wurde, klicken Sie auf Hinzufügen Schaltfläche in der Mitte des Dialogs, um sie in die Liste aufzunehmen. Wenn Sie mit der Angabe der Tabellen- und Spaltenpositionen fertig sind, klicken Sie auf Hinzufügen Schaltfläche unten, um die Standorte zur Maskierungsregel hinzufügen hinzuzufügen Dialog.
Klicken Sie abschließend auf Speichern am Ende von Maskierungsregel hinzufügen Dialogfeld, wenn Sie mit der Maskierungsregel fertig sind. An diesem Punkt sehen alle Benutzer, die für den Zugriff auf die Daten konfiguriert sind, maskierte Werte, wenn sie eine Verbindung über den JDBC SQL Trail-Proxy-Treiber herstellen.
Damit ein Benutzer nicht maskierte Daten anzeigen kann, müssen Sie ihn zur Liste der nicht maskierten Benutzer hinzufügen , wie unten beschrieben.
Benutzern Autorisierung erteilen
Innerhalb derselben Maskierungsrichtlinie Registerkarte der SQL#-Ausführungsverwaltung Bildschirm. Klicken Sie auf das + (Hinzufügen)-Symbol rechts neben der Unmaskierte Benutzerliste Etikette. Dadurch wird der Benutzer suchen angezeigt Dialogfeld, in dem Sie einen oder mehrere Benutzer auswählen können, für die Abfragen in den ausgewählten Spalten und Tabellen nicht maskiert werden.
Klicken Sie auf Speichern unten im Dialogfeld, wenn Sie mit der Auswahl der Benutzer fertig sind.
Verwendung von SQL# und SQL-Trail von DB-Anwendungen
In diesem Beispiel ist unsere Datenbankanwendung IRI Workbench, die Eclipse-Front-End-Job-Design-Umgebung für Voracity, FieldShield und andere IRI-Softwareprodukte.
Um Ihre Anwendungen für die SQL-Steuerung und dynamische Datenmaskierung mit dem SQL#-Proxyserver und dem JDBC-SQL-Trail-Treiber zu aktivieren, müssen Sie SQL# über Tomcat und seinen Proxyserver aktivieren. Sie müssen auch den JDBC SQL Trail-Treiber in der Datenquellen-Explorer-Ansicht von IRI Workbench sowie die DDM-Richtlinien in SQL# wie oben beschrieben konfigurieren.
Hier ist eine Ansicht der Oracle-Instanz, die über den JDBC SQL Trail-Treiber verbunden ist.
Beachten Sie, dass alle normalen Datenbankoperationen und IRI-Job-Wizards weiterhin über diese Verbindung funktionieren. Das bedeutet auch, dass jede nicht autorisierte Aktivität von IRI Workbench blockiert wird und alle SQL-Befehle, die von hier an die verbundene Datenbank ausgegeben werden, im SQL#-Audit-Log aufgezeichnet werden.
Dies ist eine Workbench-Abfrage für die Tabelle ORDERS, die für DDM in SQL#:
richtlinienkonfiguriert wurde
im Vergleich zu derselben Abfrage, die von einem autorisierten Benutzer ausgeführt wurde und die ursprünglichen unmaskierten Daten anzeigt:
In der Zwischenzeit können Sie im Protokollierungsabschnitt der SQL#-Anwendung unseren Abfragedatensatz sehen:
von der IP-Adresse der IRI Workbench.
