Według Simsona L. Garfinkela z Laboratorium Technologii Informacyjnych NIST Information Access Division,
Deidentyfikacja nie jest pojedynczą techniką, ale zbiorem podejść, algorytmów i narzędzi, które można zastosować do różnych rodzajów danych z różnymi poziomami skuteczności. Ogólnie rzecz biorąc, ochrona prywatności poprawia się, gdy stosowane są bardziej agresywne techniki deidentyfikacji, ale wynikowy zestaw danych pozostaje mniej użyteczny.
-De-identyfikacja danych osobowych, NISTIR 8053
Maskowanie danych statycznych (SDM) to uznany w branży termin określający różne sposoby deidentyfikacji elementów danych w spoczynku. Elementami są zazwyczaj wartości kolumn bazy danych lub pól pliku prostego, które są uważane za wrażliwe; w branży medycznej określa się je mianem kluczowych identyfikatorów. Szczególnie zagrożone są dane osobowe (PII), chronione informacje zdrowotne (PHI), podstawowe numery kont (PAN), tajemnice handlowe lub inne wrażliwe wartości.
IRI FieldShield — „punkt startowy” — produkt bezpieczeństwa zorientowany na dane — lub produkt IRI CoSort i platforma IRI Voracity, które oferują te same możliwości — zapewniają wiele funkcji wykrywania danych i SDM dla wielu źródeł danych. Dostępne funkcje maskowania poszczególnych pól/kolumn obejmują:
- wiele, zgodnych z NSA Suite B i FIPS algorytmów szyfrowania (i deszyfrowania), w tym zachowania formatu szyfrowanie
- Hashowanie SHA-1 i SHA-2
- De-ID ASCII (szyfrowanie bitowe)
- kodowanie i dekodowanie binarne
- rozmycie danych lub grupowanie (anonimizacja)
- losowe generowanie lub wybór
- redakcja (zaciemnianie znaków)
- odwracalna i nieodwracalna pseudonimizacja
- logika wyrażenia niestandardowego (obliczanie/losowanie)
- warunkowe/częściowe filtrowanie lub usuwanie wartości (pominięcie)
- zastępowanie wartości niestandardowej
- przesuwanie bajtów i funkcje ciągów
- tokenizacja (dla PCI)
Możesz także „ustawić własną” funkcję maskowania danych zewnętrznych. Pozwala to na wywoływanie w czasie wykonywania niestandardowej procedury na poziomie pola zamiast wbudowanej.
Pozostaje pytanie, jakiej funkcji maskowania powinienem użyć (na każdym przedmiocie)? Zależy to od potrzeb i zasad Twojej firmy, a także obowiązujących przepisów dotyczących prywatności danych. Na poziomie technicznym zwykle oznacza to podjęcie decyzji, jak ma wyglądać wynikowy szyfrogram (dane zamaskowane), czy ma być odwracalny lub niepowtarzalny, jak jest bezpieczny i ewentualnie jakiego rodzaju zasoby obliczeniowe i czas są dostępne dla procesu . Przyjrzyjmy się szczegółowo tym powszechnym kryteriom decyzyjnym:
Wygląd (realizm)
Czy nowo zamaskowane dane powinny wyglądać mniej więcej jak oryginalne dane? A co z jego rozmiarem i formatem? Pseudonimizacja i szyfrowanie z zachowaniem formatu to dwa najczęstsze sposoby
zachować wygląd i styl odpowiednio rzeczowników własnych i alfa-cyfrowych numerów kont lub telefonów. Ale maskowanie podciągów (a/k/a częściowa redakcja pola, np. XXX-XX-1234) może być w porządku dla rzeczy takich jak SSN. Pomyśl o trwałości i wyświetlaniu danych do analizy itp.
W związku z tym wygląd i realizm zaszyfrowanego tekstu może również decydować o użyteczności wyników. Cele aplikacji i tabel bazy danych (narzędzia ładowania) mogą wymagać, aby format danych był nie tylko zgodny ze wstępnie zdefiniowanymi strukturami, ale także kontynuował pracę w zapytaniach lub innych kontekstach operacyjnych.
Innymi słowy, jeśli wymagane są zamaskowane dane, które są ładne i/lub funkcjonalne, nie stosuj pełnej redakcji, randomizacji, mieszania lub prostego szyfrowania (które poszerza i zaciemnia wyniki). Być może uda ci się uniknąć drobnych poprawek, takich jak starzenie się i manipulacja podciągami, ale rozważ wpływ tych wyborów na inne kryteria decyzyjne…
Odwracalność (ponowna identyfikacja)
Potrzebujesz przywrócenia oryginalnych danych? Odpowiedź na to pytanie może zależeć od tego, czy zostawiasz dane źródłowe w spokoju, jak w przypadku dynamicznego maskowania danych, czy też zapisujesz zamaskowane dane do nowych celów. W takich przypadkach odpowiedź brzmi nie.
Jeśli odpowiedź brzmi „nie”, nadal możesz potrzebować realizmu, w którym to przypadku nieodwracalna pseudonimizacja może być najlepszym rozwiązaniem. Jeśli tak nie jest, a wygląd nie ma znaczenia, idź z redakcją postaci. A jeśli nie jest to prawdą, rozważ całkowite usunięcie kolumny źródłowej z celu.
Jeśli odpowiedź brzmi „tak”, wskazane są funkcje maskowania danych IRI, takie jak szyfrowanie, odwracalna pseudonimizacja lub tokenizacja, kodowanie lub re-ID ASCII (szyfrowanie bitów). W bardziej zaawansowanych przypadkach użycia może być również potrzebne odwrócenie różnicowe; tj. gdy różni odbiorcy tego samego celu są upoważnieni do oglądania różnych rzeczy w tym samym zbiorze danych. W takich przypadkach można wdrożyć prywatne klucze szyfrowania, specyficzne dla użytkownika skrypty zadań ujawniania, a nawet niestandardowe aplikacje.
Wyjątkowość (spójność)
Czy ta sama pierwotna wartość zawsze musi być zastąpiona tą samą, ale inną wartością zastępczą? Czy dane zostaną połączone lub pogrupowane według wartości zastępczych? Jeśli tak, wybrany algorytm zastępowania musi dawać wyniki, które są unikalne i powtarzalne, aby zachować integralność referencyjną pomimo maskowania, które miało miejsce.
Można to osiągnąć poprzez szyfrowanie, gdy ten sam algorytm i hasło (klucz) są używane wobec tego samego tekstu jawnego. Kreatory klasyfikacji danych i ochrony między tabelami w IRI Workbench IDE dla FieldShield, Voracity itp. ułatwiają to poprzez zastosowanie między tabelami (lub bardziej globalnie) dopasowanej reguły maskowania. W ten sposób ta sama wartość w postaci zwykłego tekstu zawsze otrzymuje ten sam wynik w postaci zaszyfrowanego tekstu, niezależnie od jej lokalizacji.
Pseudonimizacja jest tu jednak trudniejsza z powodu braku unikalnych nazw zastępczych, duplikatów nazw oryginalnych i zmian ( wstawia, aktualizuje lub usuwa) do oryginalnych wartości w tabelach lub plikach źródłowych. IRI zajęło się kwestią spójnej pseudonimizacji między tabelami w tym przykładzie przepływu pracy Vorality.
Siła (bezpieczeństwo)
Spojrzenie na algorytmy w każdej funkcji może pomóc określić ich względną „podatność na pękanie” i ocenić to w porównaniu z innymi względami zaszyfrowanymi, takimi jak wygląd i szybkość. Na przykład funkcja AES256 IRI jest silniejsza niż opcja AES128, SHA2 jest silniejsza niż SHA1, a wszystkie są silniejsze niż funkcje kodowania/dekodowania base64 oraz funkcje de-ID/re-ID ASCII.
Z definicji funkcje odwracalne są zwykle słabsze niż te, których nie można odwrócić. Na przykład nieodwracalna metoda pseudonimizacji IRI (zagraniczny zestaw wyszukiwania) jest bezpieczniejsza niż jej odwracalna (zaszyfrowany zestaw oryginalnych zestawów) metoda pseudonimizacji. To powiedziawszy, algorytm szyfrowania AES-256 może być bardzo trudny do złamania, gdy klucz zostanie zgubiony.
Jeszcze silniejsze zabezpieczenia to oczywiście pominięcie, a następnie zaciemnienie znaków (redakcja), które są nieodwracalne. Ale minusem jest brak użyteczności. W kontekście bezpiecznej przystani HIPAA usuwanie identyfikatorów kluczy jest zgodne. Jeśli jednak potrzebujesz użyć jakiejkolwiek części danych źródłowych do analizy, badań, marketingu lub demonstracji, będziesz potrzebować funkcji maskowania i eksperta, aby ustalić (i poświadczyć), że twoja technika (techniki) ma niski poziom statystyczny prawdopodobieństwo ponownej identyfikacji.
Chociaż jesteśmy przy temacie dezidentyfikacji HIPAA, pamiętaj, że może istnieć również ryzyko związane z tak zwanymi pseudoidentyfikatorami (takimi jak kod pocztowy i wiek). Wartości te mogą być używane w połączeniu z innymi zestawami danych w celu ustalenia śladu ponownej identyfikacji, a zatem w wielu przypadkach warto je zamaskować; czy i jak podlegają tym samym rozważaniom.
Obliczenia (wydajność)
Jedną z miłych rzeczy w podejściu do maskowania danych — nawet w przypadku algorytmów szyfrowania wymagających dużej mocy obliczeniowej — jest to, że jego obciążenie w porównaniu z szyfrowaniem szerokopasmowym (całej sieci, bazy danych, plików/systemu, dysku) jest znacznie niższe. Tylko te elementy danych (wartości kolumn), które wyznaczysz do ochrony, muszą być pozyskiwane, przetwarzane i zwracane przez funkcję maskującą.
Ogólnie rzecz biorąc, im bardziej złożony (i silniejszy) algorytm, tym dłużej trwa jego zastosowanie. Prędkości maskowania danych będą również zależeć od liczby zastosowanych funkcji, liczby kolumn i wierszy bazy danych, liczby ograniczeń wyszukiwania, których należy przestrzegać w procesie (w celu zapewnienia integralności referencyjnej), przepustowości sieci, pamięci RAM, we/wy, procesów współbieżnych oraz wkrótce.
Poniższy nienaukowy wykres przedstawia większość atrybutów opisanych powyżej dla wygodnego odniesienia, dla niektórych (ale nie wszystkich!) obsługiwanych danych IRI maskujących kategorie funkcjonalne i ogólnie tylko w kategoriach względnych. Nie trzeba dodawać, że IRI zrzeka się jakiejkolwiek gwarancji przydatności lub odpowiedzialności za tę tabelę!
Funkcje maskowania danych IRI (w FieldShield i żarłoczności)
Niezależnie od tego, czy używasz wbudowanych funkcji maskowania danych IRI, czy funkcji niestandardowych, które definiujesz, chodzi o to, aby zastosować je w oparciu o reguły biznesowe do określonych wierszy lub kolumn i/lub między tabelami. Zrobisz to za pomocą reguł maskowania danych, które możesz zdefiniować, przechowywać i ponownie wykorzystywać. Możliwe jest również (i zalecane) zastosowanie tych funkcji maskowania danych do automatycznie sklasyfikowanych danych jako reguł zapewniających wygodę i spójność. Możesz też wykorzystać kilka z nich w aplikacjach do dynamicznego maskowania danych za pomocą wywołania interfejsu API.
Użytkownicy FieldShield (lub Voracity) mogą tworzyć, uruchamiać i zarządzać zadaniami maskowania danych w bezpłatnym, najnowocześniejszym graficznym interfejsie użytkownika, zbudowanym na Eclipse.™. Mogą też edytować i uruchamiać zgodne, samodokumentujące się skrypty 4GL definiujące ich dane źródłowe/docelowe oraz funkcje maskujące i uruchom te skrypty w wierszu poleceń.
Aby uzyskać więcej informacji, wejdź na https://www.iri.com/solutions/data-masking lub skontaktuj się z przedstawicielem IRI.
