Palcówki niestraszne

Jak widać, zmiana choćby jednego znaku, nieraz bez większego znaczenia, powoduje całkowitą zmianę skrótu i cała idea porównywania rekordów w bazie bierze w łeb. O ile na otwartym tekście można wykonywać operacje porównywania rozmytego (np. bez uwzględnienia wielkości liter czy polskich znaków), o tyle na skrótach jest to niemożliwe.

Aby obejść ten problem, IBM zastosował rozbudowane mechanizmy normalizacji napisów, to znaczy doprowadzania ich do jednolitej postaci, tak by dwa teksty o identycznym znaczeniu wpisane w różny sposób na końcu były zawsze doprowadzone do identycznej postaci. Zajmuje się tym moduł Anonymous Resolution Pre-Processing. Normalizacja obejmuje standaryzację imion i nazwisk, weryfikację adresów wg amerykańskich i międzynarodowych baz danych oraz wiele dodatkowych reguł mających na celu ujednolicenie formatu kodów pocztowych, numerów telefonów i numerów urzędowych, takich jak: amerykański Social Security Number, polski PESEL, NIP itd. Użytkownik może również definiować własne reguły normalizacji poszczególnych pól.

Rezultatem pracy preprocesora normalizującego są dane, które po przepuszczeniu przez funkcję skrótu (Anonymizer) dadzą takie same wyniki, nawet jeśli użytkownik początkowo wpisał dane w nieco różnej postaci. Dane po normalizacji i anonimizacji mogą być przetwarzane dużo liberalniej niż tradycyjne dane osobowe - nie zawierają bowiem informacji narażających na szwank prywatność osób. Rekordy można porównywać i uaktualniać, tak jak w każdej bazie.

Oczywiście, w pewnym momencie pojawia się konieczność uzyskania informacji, kim jest osoba kryjąca się za tajemniczym skrótem "v9nFgEK8Jj94V2E3GdY7q8Y39jw". Tutaj z pomocą przychodzi moduł Anonymous Resolution Resolver, który w oddzielnej bazie przechowuje uprzednio przepuszczone przez funkcję skrótu nazwiska. W uproszczeniu jego działanie polega na wyszukaniu informacji, jakiemu nazwisku odpowiada dany skrót, a następnie zastąpieniu skrótu nazwiskiem. Jest to więc funkcja odwrotna do anonimizacji. Resolver może przetwarzać dane pochodzące z dowolnej liczby modułów Anonymizer.

Kradzież bez sensu

Konsekwencje takiego modelu dla bezpieczeństwa są bardzo ważne. Do tej pory całość informacji była przechowywana w jednej bazie, której kradzież oznaczała utratę kompletu danych kompromitujących opisane w bazie osoby. Wraz z nazwiskiem wyciekała jej data urodzenia, adres, wyniki testu na wirusa HIV, numer karty kredytowej i wiele innych, wrażliwych informacji. DB2 Anonymous Resolution umożliwia operacje na bazie anonimowej - zawiera ona niemal wszystkie wrażliwe informacje potrzebne do pracy aplikacji, ale nie zawiera tych najważniejszych dla złodziei danych, np. nazwisk i adresów.

Przeniesienie tych kluczowych informacji do oddzielnej bazy (Resolver) umożliwia znacznie ściślejszą kontrolę nad ich dystrybucją oraz audytowanie każdego faktu konwersji skrótu na prawdziwe nazwisko, których w praktyce nie będzie aż tak wiele w jednostce czasu. Możliwa jest również drobiazgowa kontrola faktu próby dostępu do Resolvera.

Z technicznego punktu widzenia IBM zaimplementował system zgodnie z obowiązującymi standardami. Dane są przetwarzane w formacie XML, istnieje możliwość konwersji danych tekstowych lub innych baz danych do tego formatu. Anonymizer wykorzystuje silne, kryptograficzne funkcje skrótu (prawdopodobnie SHA1 lub SHA2, choć w dostępnej dokumentacji nie jest to napisane). Pomyślano także o instytucjach, które mają specjalne potrzeby - funkcja skrótu jest modularna i można ją zastąpić własną.

Aby chronić skróty przed atakami słownikowymi, zastosowano tzw. salt, tzn. długi losowy klucz, który jest dodawany do skracanego tekstu, dzięki czemu słowo "test" może dać w wyniku wiele różnych skrótów. "Salt" chroni przed atakami, a także stanowi dodatkowe uwierzytelnienie pomiędzy Anonymizerami a Resolverem - każdy z tych modułów musi znać tajny klucz.

IBM przewiduje, że głównymi odbiorcami systemu będą instytucje mające problemy z przetwarzaniem danych osobowych - banki, służba zdrowia, a także administracja rządowa.