W tym artykule opisano metodę dynamicznego maskowania danych (DDM) dostępną w witrynach premium IRI FieldShield, która korzysta z systemu proxy do przechwytywania zapytań aplikacji do baz danych połączonych za pomocą JDBC. Jest to jedno z kilku podejść do maskowania danych w locie, które użytkownicy FieldShield mogą rozważyć.
Inne opcje IRI DDM obejmują:funkcje FieldShield wywoływane przez API wbudowane w programy C/C++/C#, Java lub .NET; funkcje FieldShield działające w czasie rzeczywistym osadzone w procedurach SQL, które tworzą zamaskowane widoki; oraz dynamiczne odmaskowanie tabel maskowanych statycznie dla autoryzowanych użytkowników.
Przedstawiony tutaj system oparty na proxy wykorzystuje dopasowany do celu, specyficzny dla bazy danych sterownik „JDBC SQL Trail” w połączeniu z konfiguracyjną i zarządzającą aplikacją internetową o nazwie SQL Sharp (SQL#). Ten diagram przedstawia architekturę systemu przed i po wdrożeniu:
Ta aplikacja obsługuje obecnie następujące platformy relacyjnych baz danych:
- Oracle 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
i wymaga następujących komponentów innych firm:
- MS Windows 7,10 lub Server 2012 i nowsze (testowane).
- Java JDK i JRE 1.8 lub nowszy.
- Tomcat 8.5 lub nowszy do uruchomienia serwera WWW SQL#.
- Nowoczesna przeglądarka internetowa, taka jak:
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
- Oracle lub PostgreSQL jako baza danych repozytorium do przechowywania:
- Konfiguracja użytkownika i grupy SQL#
- Dostęp do bazy danych i kontrola aktywności
- Zasady dynamicznego maskowania danych
- Dzienniki audytu SQL
Jak to działa?
W aplikacji internetowej SQL# tworzysz zasady maskowania danych w celu redagowania wartości kolumn w locie dla wszystkich oprócz autoryzowanych użytkowników łączących się z bazą danych za pomocą sterownika JDBC SQL Trail. Musisz zainstalować i skonfigurować ten sterownik dla każdej instancji bazy danych, którą chcesz chronić.
Zasady DDM określają, które tabele i kolumny należy zamaskować, oraz sposób wyświetlania maskowanych wartości. Po prawidłowym skonfigurowaniu systemu wszystkie zapytania połączone przez sterownik będą podlegać polityce maskowania.
Możliwe jest również zdefiniowanie polityk, aby zablokować użytkownikom możliwość logowania i niektórych działań SQL. Tworzony jest pełny dziennik kontroli logowania i aktywności SQL, który można wyświetlić w SQL#.
Sterownik nie rozróżnia użytkowników aplikacji do celów blokowania, maskowania lub audytu. Możesz jednak autoryzować konkretnie nazwanych użytkowników — nawiązując alternatywne połączenia serwera aplikacji z bazą danych za pośrednictwem tego samego sterownika — aby zobaczyć zdemaskowane dane.
Tworzenie polityki maskowania
Aby utworzyć politykę maskowania w SQL#, użyj Zasady maskowania zakładka Zarządzanie wykonywaniem SQL# ekran. Wybierz + Ikona (Dodaj) po prawej stronie Listy reguł maskowania etykieta.
Nadaj regule maskowania nazwę i opcjonalny opis. Następnie możesz wybrać typ maski, która zostanie zastosowana z Masing Regex: menu rozwijane w Dodaj regułę maskowania okno dialogowe.
Pierwsze trzy opcje są wstępnie zdefiniowane, podczas gdy Regex pozwala zdefiniować niestandardowy format maskowania. Kliknij + Ikona (Dodaj) po prawej stronie TAB/COL label, aby dodać jedną lub więcej kombinacji tabeli i kolumny, aby określić, które wartości danych będą maskowane.
Po utworzeniu każdej kombinacji tabeli i kolumn kliknij przycisk Dodaj w środku okna dialogowego, aby umieścić je na liście. Po zakończeniu określania lokalizacji tabeli i kolumn kliknij przycisk Dodaj na dole, aby dodać lokalizacje do Dodaj regułę maskowania okno dialogowe.
Na koniec kliknij Zapisz na dole Dodaj regułę maskowania okno dialogowe po zakończeniu z regułą maskowania. W tym momencie wszyscy użytkownicy, którzy mają dostęp do danych, zobaczą zamaskowane wartości podczas łączenia się przez sterownik proxy JDBC SQL Trail.
Aby umożliwić użytkownikowi przeglądanie niezamaskowanych danych, musisz dodać je do Listy zdemaskowanych użytkowników , jak opisano poniżej.
Przyznawanie uprawnień użytkownikom
W ramach tej samej Zasad maskowania zakładka Zarządzanie wykonywaniem SQL# ekran. Kliknij + Ikona (Dodaj) po prawej stronie Listy zdemaskowanych użytkowników etykieta. Spowoduje to wyświetlenie Użytkownika wyszukiwania okno dialogowe, w którym możesz wybrać jednego lub więcej użytkowników, dla których zapytania do wybranych kolumn i tabel nie będą maskowane.
Kliknij Zapisz na dole okna dialogowego po zakończeniu wybierania użytkowników.
Korzystanie z SQL# i SQL Trail z aplikacji DB
W tym przykładzie naszą aplikacją bazy danych będzie IRI Workbench, front-endowe środowisko projektowania zadań Eclipse dla Voracity, FieldShield i innych produktów oprogramowania IRI.
Aby umożliwić aplikacjom sterowanie SQL i dynamiczne maskowanie danych za pomocą serwera proxy SQL# i sterownika JDBC SQL Trail, należy aktywować SQL# za pośrednictwem serwera Tomcat i jego serwera proxy. Należy również skonfigurować sterownik JDBC SQL Trail w widoku Eksploratora źródeł danych IRI Workbench, a także zasady DDM w SQL#, jak opisano powyżej.
Oto widok instancji Oracle połączonej przez sterownik JDBC SQL Trail.
Należy zauważyć, że wszystkie normalne operacje na bazie danych i kreatory zadań IRI będą nadal działać za pośrednictwem tego połączenia. Oznacza to również, że każda nieautoryzowana aktywność z IRI Workbench zostanie zablokowana, a wszystkie polecenia SQL wydane stąd do połączonej bazy danych zostaną zapisane w dzienniku audytu SQL#.
To jest zapytanie Workbencha w tabeli ORDERS, która została skonfigurowana zgodnie z zasadami DDM w SQL#:
w porównaniu z tym samym zapytaniem uruchomionym przez autoryzowanego użytkownika, który wyświetla oryginalne niemaskowane dane:
Tymczasem z powrotem w sekcji logowania aplikacji SQL# możesz zobaczyć nasz rekord zapytania:
z adresu IP IRI Workbench.
