Category Archives: Anonimizator

Konstruowanie obiektów IRandomizer oraz testy (wydajności)

W poprzednim odcinku dokonałem wyabstrahowania interfejsu IRandomization by umożliwić testowanie kodu korzystającego z elementów losowości. W obecnym skupię się na podstawowych obiektach konstrukcyjnych. Kłania się wzorzec fabryki abstrakcyjnej.

public interface IRandomizerBuilder
{
    IRandomizer ConstructDeafultRandomizer();

    IRandomizer ConstructRandomizer(int seed);
}

Continue reading Konstruowanie obiektów IRandomizer oraz testy (wydajności)

Polerowanie interfejsu IRandomization

W poprzednim poście, w którym analizowałem wydajność implementacji generatorów liczb pseudolosowych odkryłem, że w ostatecznym rozrachunku planuję używać systemowego typu Random w celu generowania serii liczb losowych – ma znakomitą wydajność i bardzo dobry rozkład – a przynajmniej dla wywołań zakresowych – GetNext(min, max). W międzyczasie, odkryłem jeszcze istnienie kilku innych opcji, które zamierzam sprawdzić w wolnej chwili. (Będzie ciężko, bo The Division…) Spodziewam się znaleźć coś ciekawego, stąd niniejsza część kodu. Planuję:

  • Opakować generator ustandaryzowanym interfejsem, który w miarę potrzeb będę rozbudowaywał
  • Dorobić klasę proxy, która zapewni te funkcje:
    • Umożliwi serializację stanu generatora, w celu odtworzenia jego stanu
    • Umożliwi śledzenie zdarzeń związanych z generowaniem liczb, przydatne zwłaszcza w projektach growych
  • Przy okazji naprawię odziedziczoną ze starych plików klasę Rnd, która jest napisana dość słabo w stosunku do obecnych standardów :-/

Continue reading Polerowanie interfejsu IRandomization

Na pierwszy ogień – Randomizery

Przy okazji odgruzowywania repozytoriów z Flaksatorem – 2-3 wersje ;-), ta na Githubie może się okazać, że nie jest najlepszą… (Nic to, po drodze się naprawi.) – odgrzebałem rozmaite wersje tzw. “wspólnych bibliotek”, do których w(y)rzucałem przydatne we współdzieleniu klasy i komponenty.

W pierwszej kolejności zająłem się ważnym komponentem generującym losowe wartości. Zwłaszcza, że w pewnych częściach przydatny jest / będzie w kilku moich innych pet-projektach. Ktoś powie – a na grzyba, przecież jest klasa Random?!
I w zasadzie słusznie. Problemy są trzy:

  • Podobno nie jest zbyt szybka
  • Podobno jej rozkład pozostawia wiele do życzenia
  • Nie da się spersystować / serializować jej stanu

Co do ostatniego – to BinaryFormatter powinien sobie z tym łatwo poradzić (Random implementuje interfejs ISerializable, mimo, że publicznych pól nie posiada…) – o tym w kolejnym poście.

W międzyczasie – myślę – warto spróbować zweryfikować dwie pierwsze tezy. Najlepiej móc porównać z czym innym. Idealnym kandydatem wydaje się szeroko rozpowszechniony algorytm Mersenne Twister, którego mam kilka wersji:

Continue reading Na pierwszy ogień – Randomizery

Dane wrażliwe

Dane osobowe to szeroki temat, jakkolwiek szeroko lub wąsko rozumiany – dla wielu wrażliwych jest to temat bardzo drażliwy. Jednak niezależnie od tego jak bardzo dana osoba przejmuje się bezpieczeństwem czy poufnością danych powierzonych innym podmiotom (świadomie czy nie) to jednak ustawa na każdego administratora danych osobowych nakłada obowiązek takiego ich przetwarzania, przechowywania i transmitowania by ich spójność i bezpieczeństwo były gwarantowane (i zgodne z ustawą – bla, bla, bla).

Część danych pozwala na jednoznaczną identyfikację osoby (lub podmiotu), której dotyczą. Są to unikalne identyfikatory typu PESEl, NIP, czy REGON. Mniej oczywiste są identyfikatory typu nazwa / imię i nazwisko – które w skali globalnej wcale nie muszą być unikalne. Podobnie poszczególne fragmenty adresu zamieszkania / korespondencyjnego nie muszą precyzyjnie wskazywać konkretnej osoby lub grupy osób (pomijając nawet zmienność i rozbieżność takich danych w czasie – ludzie i firmy często zmieniają miejsce zamieszkania / prowadzenia działalności– także jeden adres może być współdzielony przez wiele podmiotów) ale już w połączeniu z imieniem i nazwiskiem lub datą urodzenia mogą zawęzić zbiór potencjalnych osób do jednego człowieka.

A nawet jeśli nie – to wskazanie konkretnej grupy osób (np. rodziny) może już być odebrane jako pogwałcenie prywatności. Należy bardzo uważać przy łączeniu danych – może się zdarzyć, że połączenie częściowo zamaskowanego adresu (np. do poziomu nazwy ulicy, ale już bez numerów mieszkań) z samym tylko faktem posiadania ubezpieczenia medycznego w konkretnej firmie może precyzyjnie identyfikować konkretną osobę! (A najprawdopodobniej nazwa firmy ubezpieczeniowej nie będzie podlegać anonimizacji, ze względu na wymagania biznesowe systemu testowego…)

Oczywiście, jeżeli wiemy, że dane w całej bazie zostały zanonimizowane wówczas wiemy, że wszelkie próby statystycznego zestawiania poszczególnych elementów nie mają wielkiego sensu. Pod warunkiem wszakże, że poziom anonimizacji jest wystarczający. Wydaje się, że można próbować wskazać właściwe poziomy minimalne dla poszczególnych danych. W wielu przypadkach okaże się, że można zwiększyć te poziomy, gdyż zbyt szeroki zakres realnych danych nie będzie potrzebny podczas korzystania z bazy de-identyfikowanej (np. adresy pozostaną prawdziwe do poziomu miast, związanego z testowanymi zapytaniami raportowymi). Losowa de-identyfikacja ma jedną zasadniczą wadę – może tworzyć osobowości, które fragmentarycznie odpowiadają prawdziwym podmiotom – imiona, nazwiska czy numery PESEL nie mają jakiejś gigantycznej zmienności. Jednym z wymogów może być, by wylosowane wartości anonimizacyjne były różne od oryginalnych. Ale już sprawienie by nie były identyczne z innymi w systemie – niekoniecznie. Pewnym problemem mogą okazać się indeksy unikalne (np. na PESEL, czy niepoprawny na kombinacji imienia i nazwiska), które uniemożliwią takie duplikaty – aplikacja powinna być przygotowana na taką ewentualność i albo sprawdzać to z góry (konfiguracja) albo przechwytywać stosowny wyjątek i losować nową wartość.

Wróćmy zatem do listy proponowanej przez HIPPA:

Continue reading Dane wrażliwe

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.

Continue reading Anonimizacja vs de-identyfikacja

Anonimizator – Nowy Projekt!

Cel projektu

Sytuacja wygląda tak – potrzebuję dostarczyć do zespołu deweloperskiego bazę produkcyjną aby dokonali na niej pewnych testów i optymalizacji. Występują też jeden czy dwa błędy, których nie daje się zreprodukować w środowisku testowym.

Oczywiście baza zawiera masę danych wrażliwych, które absolutnie nie powinny opuścić serwerów produkcyjnych. Zamazanie danych przypadkowymi śmieciami nie wchodzi w rachubę – rozkład statystyczny indeksów ulegnie zmianie i spora część pracy optymalizacyjnej deweloperów będzie bez sensu. Oczywistym jest, że w takim razie należy dane wrażliwe zastąpić danymi “niewrażliwymi” ale sensownymi, o w miarę naturalnym rozkładzie.

Dodatkowe wymagania

  • Dane w bazie są międzynarodowe – mają różną postać i niektóre także formaty
  • Warto zachować statystyczny rozkład danych
  • Powinna być otwarta na przyszłe formaty bazy – nowe bazy jak i rozbudowę / zmiany w istniejącej. Oraz nowe formaty danych.

Zarys rozwiązania

Swego czasu, podczas jednego z projektów, przygotowałem trochę klas generatorów danych testowych, takich jak dane osobowe, adresy, adresy e-mail. Dane bazowe dla generatorów były wyłącznie polskie a ponadto moduł adresów był potraktowany bardzo po macoszemu. Niewątpliwie jest to jakiś punkt wyjścia, ale zdecydowanie zbyt prymitywny na potrzeby funkcjonalnej anonimizacji. Głównie dlatego, że generatory generowały dane zupełnie przypadkowe (Do pewnego stopnia – np. nr PESEL i imię czy nazwisko były dostosowane do płci osoby, podobnie jak PESEL uwzględniał datę urodzenia osoby – o ile została dostarczona w przeciążonej metodzie.) a w obecnym przypadku musimy mieć możliwość kontroli nad zakresem zmian – np. rok i miesiąc urodzenia pozostają oryginalne a randomizujemy wyłącznie dzień albo losujemy imię o identycznej długości (chociaż to, może już nie spełniać wszystkich wymagań…).
Warto też by aplikacja dostarczała na tyle wygodny interfejs, by mogła z niego korzystać uprawniona osoba (Administrator Danych Osobowych), która prawie na pewno nie będzie programistą… Już na wstępie wydaje się zasadnym taki sposób przygotowania konfiguracji procesu, by rozdzielić opracowanie reguł od ich wykonania, oraz w pełni zabezpieczyć dane w bazie produkcyjnej przed niepowołanym dostępem ale także uchronić je przed celowymi lub przypadkowymi zmianami.

Literatura przedmiotu

  1. Niewątpliwie w pierwszej kolejności warto sięgnąć Ustawa o Ochronie Danych Osobowych.
  2. Ciekawym źródłem przydatnych wskazówek i wytycznych jest stosowna ustawa amerykańska dotycząca między innymi anonimizacji i deidentyfikacji pacjentów (HIPAA) wskazana na stronie Wikipedii – De-identification, i w interesującym zakresie dokładniej omówiona tutaj: Protected health information. Zamierzam dokładniej omówić ten ostatni artykuł w kolejnym poście, gdyż te wytyczne są bardzo istotne dla projektowania architektury systemu.