Anonimizacja vs de-identyfikacja

W pierwszej kolejności należałoby się zapoznać z różnicami między anonimizacją i de-identyfikacją.
Wg definicji (De-identification):

Anonymization
refers to irreversibly severing a data set from the identity of the data contributor in a study to prevent any future re-identification, even by the study organizers under any condition.
De-identification
is the process used to prevent a person’s identity from being connected with information. Common uses of de-identification include human subject research for the sake of privacy for research participants. Common strategies for de-identifying datasets are deleting or masking personal identifiers, such as name and social security number, and suppressing or generalizing quasi-identifiers, such as date of birth and zip code. The reverse process of defeating de-identification to identify individuals is known as re-identification.

Jak należy to rozumieć?

Anonimizacja
odnosi się do NIEODWRACALNEGO pozbawienia zbioru danych wszelkich wskazówek pozwalających na re-identyfikację osoby, której dotyczą.
De-identyfikacja

to usunięcie z danych wszelkich informacji OSOBISTYCH bezpośrednio lub pośrednio wskazujących na konkretną osobę, ale pozostawienie identyfikatora umożliwiającego ewentualne połączenie z oryginalnym zbiorem i osobą.

Generalnie, najlepiej by przedmiotowe dane pozbawić wszelkich możliwych powiązań z oryginalnymi danymi (pełna anonimizacja). Pytanie – czy jest to wykonalne?
Na pierwszy rzut oka – nie wydaje się to możliwe. Pracując na kopii danych, którą będziemy poddawali procesowi de-identyfikacji raczej pozostawimy w stanie niezmienionym wszelkie systemowe identyfikatory – klucze oraz klucze obce – odbudowanie wszelkich relacji o nie opartych wydaje się zadaniem zarówno skomplikowanym jak i wyjątkowo zasobożernym (bazy produkcyjne mają to do siebie, że zazwyczaj są duże). Może nie być to wskazane również ze względów operacyjnych – jeżeli anonimowa baza była używana do naprawy błędów – może zajść konieczność re-identyfikacji oryginalnych rekordów i ich naprawa.
Wniosek 1. W celu realizacji niektórych wymagań organizacji, aplikacja musi umożliwiać pozyskanie kopii danych poddanych jedynie procesowi de-identyfikacji. Musi być możliwość powiązania (przez osoby uprawnione, mające dostęp do oryginalnej bazy) wierszy oryginalnych i anonimowych.
Wniosek 2. Jednakże, na podstawie dowolnej analizy danych zawartych w przetworzonej kopii, bez posiadania dostępu do bazy oryginalnej, re-identyfikacja nie powinna być w żaden sposób możliwa.
Reasumując – jedynymi danymi umożliwiającymi re-identyfikację powinny zostać wewnętrzne identyfikatory z oryginalnego systemu, tj. identyfikatory nadane unikalnie przez ten system a nie pochodzące z innych systemów takie jak np. PESEL.

Załóżmy jednak, że nie potrzebujemy zachować tych identyfikatorów. Czy jesteśmy w stanie zamazać również je? Odpowiedź nie jest do końca oczywista…

Oczywiście – możemy dokonać brutalnego nadpisania kluczy głównych. Rodzi to jednak kilka poważnych konsekwencji:

  1. Aby nadpisać identyfikatory w bazie, która dokonywała ich auto generacji / auto inkrementacji – musimy:
    1. Zmodyfikować definicje samych tabel – może mieć wpływ na ewentualne testy przeprowadzane następnie na tej bazie.
    2. Dostarczyć zastępczy mechanizm generowania identyfikatorów
    3. Po zakończeniu przetwarzania danych – przywrócić mechanizmy automatyczne – co może być bardzo problematyczne – np. MS SQL Server w takiej sytuacji musi przebudować całą tabelę, co dla bardzo dużych tabel może być mocno kłopotliwe…
  2. To nie rozwiązuje problemu kluczy obcych. Jeżeli te identyfikatory były gdziekolwiek używane (w innych tabelach / dokumentach) należy je odpowiednio zaktualizować podczas przetwarzania…
    1. Samo pozyskanie statycznej informacji o tych relacjach może być kłopotliwe. Pół biedy, jeśli baza posiada takie informacje – MS SQL umożliwia pozyskanie ich. Ale co w przypadku baz dokumentowych (Mongo, MarkLogic – tu jest jeszcze inny problem do opracowania – obiekty wielopoziomowe, nie da się tego załatwić zwykłym DataTable / DataSet – prawdopodobnie logika pracy z nimi będzie musiała być zupełnie odmienna.)? Tam pieczę nad relacjami trzyma aplikacja z nich korzystająca. Należałoby manualnie zbudować schemat tych relacji – pracochłonne, kłopotliwe i podatne na błędy.
    2. W jaki sposób zbuforować nieraz ogromne ilości danych zależnych by zapamiętać pary identyfikatorów? Można próbować przechować je w tablicy mieszającej. Niestety w przypadku relacji wielo-tabelowych takie mechanizmy mogą już zawieść – zarówno złożonością jak i zajętością pamięci.
    3. Można próbować jednoczesnego, tymczasowego przechowywania kluczy oryginalnych i starych, ale wymaga to ponownie ingerencji w struktury bazy (teraz już nie tylko tabel ale i relacji – np. tymczasowe wyłączenie wymagalności istnienia powiązania) oraz co gorsza – zapewne wielokrotnego przeglądania i modyfikowania tych samych wierszy.
  3. Kopiowanie i przetwarzanie danych w locie chyba można sobie także w ogóle darować – również trudne i czasochłonne.
  4. Czyli proces nie tylko skomplikowany, niewygodny – ale też bardzo czaso- i zasobo-chłonny.

Czy jednak konieczny? Uważam, że nie.

Jeżeli jedynym sposobem re-identyfikacji osoby jest dostęp do danych oryginalnych, to takie dane można chyba uznać za poddane procesowi pełnej anonimizacji. Te identyfikatory nie pozwalają na pozyskanie większej ilości informacji osobowych, niż da się uzyskać poprzez dostęp do danych oryginalnych, który jest w tym przypadku jedyną metodą re-identyfikacji.

Wniosek 3. W związku z tym, w dalszej części tej serii artykułów będę się posługiwał właśnie takim rozumieniem terminu anonimizacja – rozumianej jako głęboka de-identyfikacja.
UWAGA: baza zde-identyfikowana powinna być w jasny sposób oznaczona jako taka – losowo generowane dane mogą bez większego problemu odpowiadać rzeczywistym osobom (Raczej fragmentarycznie – dość mało prawdopodobnym jest spójne wygnerowanie realnej kombinacji imienia, nazwiska, daty urodzenia i PESELu – ale nie jest to niemożliwe!) i prowadzić do fałszywej re-identyfikacji. Jasne oznaczenie bazy przez odpowiednią nazwę, dokumentację bądź nawet dodanie pustej tabeli o nazwie „DataBaseIsFullyAnonymysed” powinno podnieść poziom zrozumienia sytuacji przez osoby mające do niej dostęp.

Jedna myśl na temat “Anonimizacja vs de-identyfikacja”

Możliwość komentowania jest wyłączona.