Ochrona danych w spoczynku i ruchu
Aplikacje bazodanowe, które aktualizują i wysyłają zapytania do tabel, mogą wymagać zabezpieczenia danych wchodzących do tych tabel lub z nich pobieranych. Wrażliwe dane muszą być chronione w drodze do stołu, raz w tabeli lub w drodze. W każdym przypadku celem jest uniemożliwienie nieautoryzowanym osobom dostępu do niektórych wartości wierszy lub kolumn uważanych za wrażliwe.
W przypadku danych w postaci normalnej (ustrukturyzowanych) w relacyjnych bazach danych autonomiczne narzędzie maskowania danych IRI FieldShield lub jego kompatybilna biblioteka wywoływanych funkcji maskujących może uwzględnić powyższe scenariusze, zapewniając wiele opcji zarówno statycznych (trwałe, w spoczynku), jak i dynamiczne (w -transit) opcje maskowania danych. Jeśli masz również wartości PII/PHI pływające losowo w pół- i nieustrukturyzowanych kolumnach RDB (takich jak tekst, C/BLOB, XML/JSON), zapoznaj się z tym artykułem na temat podejścia IRI DarkShield.
W tym artykule omówimy jednak opcje FieldShield, ponieważ większość użytkowników RDB zajmuje się znajdowaniem i maskowaniem stałych wartości kolumn. Użytkownicy FieldShield mogą klasyfikować, lokalizować i maskować dane w tabelach DB, a dla użytkowników aplikacji uruchamiać poprzez:
- statyczne maskowanie danych w tabelach produkcyjnych i dynamiczne demaskowanie przez autoryzowanych użytkowników aplikacji
- funkcje maskowania osadzone w zadaniach przekształcania, czyszczenia lub raportowania zgodnych z metadanymi
- system dynamicznej redakcji danych oparty na proxy
- za pośrednictwem interfejsu API SDK lub systemu, wywołanie z programu
- in-situ, za pomocą procedur SQL przy użyciu niestandardowej biblioteki
Jeśli Twoje dane znajdują się w bazach danych NoSQL, takich jak MongoDB, Cassandra, Elasticsearch lub MarkLogic, FieldShield obsługuje kolekcje strukturalne, podczas gdy DarkShield obsługuje zarówno kolekcje strukturalne, jak i niestrukturalne.
Domyślnie — i sposób, w jaki interfejs graficzny IRI Workbench przedstawia FieldShield użytkownikom końcowym i administratorom baz danych — jedna lub więcej pełnych tabel jest zazwyczaj zabezpieczonych funkcjami maskowania danych statycznych (takich jak szyfrowanie, redakcja, pseudonimizacja) zgodnie z regułami biznesowymi. Wybór każdej „osłony pola (kolumny)” powinien opierać się na bezpieczeństwie, realizmie, odwracalności i być może względach dotyczących procesora lub pamięci masowej.
Podejście statyczne działa dobrze, gdy dane są w spoczynku. Można chronić tabelę źródłową lub utworzyć nową tabelę docelową lub plik z zastosowanymi zabezpieczeniami. Aplikacje pobierające chronione dane nie muszą martwić się o bezpieczeństwo, ponieważ ich źródła danych były wcześniej chronione. Programy FieldShield zaprojektowane do ochrony danych w spoczynku można również planować lub wywoływać w zadaniach wsadowych w celu regularnych aktualizacji.
Jednak w środowisku czasu rzeczywistego, w którym zaktualizowane wiersze wymagają dynamicznej ochrony, funkcje FieldShield muszą być zintegrowane z przepływem danych aplikacji. Należy rozważyć kilka podejść:
1) Twój program wywołuje FieldShield
Baza danych i inne programy, które pobierają lub wysyłają nowe lub zmienione dane do tabel, mogą przekazywać je do funkcji interfejsu API szyfrowania, mieszania, kodowania lub redakcji FieldShield w języku C, Java lub .NET. Możesz również przekazać dane w ruchu do samodzielnego programu FieldShield za pomocą potoku lub procedury wejściowej. Każda z tych metod może wypełniać cele z zastosowanymi funkcjami ochrony (lub ujawnienia) na poziomie kolumny.
2) FieldShield chroni tylko aktualizacje
Programy FieldShield można również dostosować za pomocą funkcji /QUERY i /UPDATE lub warunkowo filtrować tylko nowe rekordy, w przypadku których chronione wiersze spełniają określone kryteria, takie jak nowość. Wywołania interfejsu API pozwolą na jeszcze bardziej szczegółową logikę biznesową i ułatwią więcej warunków „szybkości” danych (lub opóźnień) — na przykład więcej maskowania danych w czasie rzeczywistym — ponieważ te potrzeby można wyrazić za pomocą aplikacji i zdefiniować przez jej logikę. Zobacz ten przykład PL/SQL maskowania w czasie rzeczywistym w oparciu o wyzwalacz.
3) Przechwytywanie i ochrona różnic w CoSort (FieldShield Parent)
Zadania zmiany przechwytywania danych (CDC) można również zaprogramować w języku Sort Control Language (SortCL) firmy CoSort, dzięki czemu tylko wybrane wstawki, aktualizacje, usunięcia lub niezmienione wiersze mogą być przekazywane do tabel lub plików z zastosowanymi zabezpieczeniami kolumn. Użytkownicy CoSort mają do dyspozycji wszystkie funkcje ochrony FieldShield, więc możliwe jest maskowanie tylko zmienionych danych w tym modelu zbiorczego raportowania.
4) Przechwytywanie zapytań oparte na proxy
IRI udostępnia teraz specjalny sterownik „JDBC SQL Trail” dla aplikacji, który filtruje zapytania bazy danych dla autoryzowanych użytkowników oraz określonych tabel i kolumn. Osoby, które nie są zwolnione z definicji zasad DDM, zobaczą tylko całkowicie lub częściowo zredagowane wartości w locie do tej specjalnie podłączonej aplikacji z bazy danych, która w spoczynku pozostaje niemaskowana.
5) Integracje niestandardowe
IRI może współpracować z administratorem baz danych lub programistą aplikacji w celu zaprojektowania rozwiązania na zamówienie, które obejmuje elementy powyższe, lub w celu dostarczenia bibliotek FieldShield, które Twoje procedury SQL mogą wywoływać in situ w celu ochrony lub ujawnienia (szyfrowania lub odszyfrowywania) zapytań wyniki, tabele zapytań, widoki zmaterializowane itd.
Skontaktuj się, aby uzyskać pomoc w integracji funkcji dynamicznego maskowania danych, takiej jak redakcja lub format z zachowaniem szyfrowania w Twojej aplikacji.
