Dowiedz się więcej na temat naszych produktów. Zobacz nasz blog
  • EN
  • PL
  • Czy wiesz, w jaki sposób skutecznie zarządzać procesem retencji danych?
    Kiedy pomyśleć o automatyzacji tego procesu?
    Jak wygląda proces retencji danych od strony IT i jakie wyzwania mogą się z nim wiązać?

    W trzecim już artykule z cyklu “RODO w IT” wspólnie z Mirkiem pochylimy się nad tematem wyzwań związanych z retencją danych.

    Z artykułu dowiesz się m.in.:

    Zapraszamy do lektury!

    Artur Żórawski, Founder i CTO Wizadrs

    Architekt IT z ponad 20 letnim stażem, autor pomysłów na rozwiązania IT do detekcji, anonimizacji i retencji danych. 

     i

    dr Mirosław Gumularz, Radca Prawny GKK Gumularz Kozik

    Audytor wewnętrzny systemu zarządzania bezpieczeństwem informacji wg normy ISO 27001:2013. Członek Grupy Roboczej ds. Ochrony Danych Osobowych przy Ministerstwie Cyfryzacji.

    ———————————————————

    Skuteczne zarządzanie procesem retencji danych

    Mirosław Gumularz (MG): W poprzednich dwóch artykułach opowiadaliśmy o tym, co RODO zmieniło w branży IT, a także o anonimizacji, temacie, który do tej pory zdecydowanie był bliższy osobom po tej “technicznej” stronie. Kolejnym  z wymogów RODO, z którym mierzy się dziś większość firm, a w szczególności działy compliance, jest ograniczenie przechowywania danych osobowych, czyli retencja danych. Oczywiście łączy się to z omawianą poprzednio kwestią anonimizacji, która jest środkiem realizacji wymogu czasowego ograniczenia przechowywania danych osobowych i alternatywą dla „fizycznego” usunięcia danych.

    Faktem jest, że RODO nie pozwala przetwarzać danych osobowych w nieskończoność. Zazwyczaj nie mówi nam też, ile czasu możemy przetwarzać te dane. Nawet tam, gdzie przepisy prawa, co jest raczej rzadkością, definiują jak długo można przetwarzać dane, na ogół jest cała masa wyjątków. To jest zadanie właśnie dla działów compliance. To one znając cele i kategorie danych, określają okresy ich retencji, czyli przechowywania.

    Tutaj sprawa zaczyna się komplikować od strony technicznej, a konkretnie w zakresie kontrolowania procesu usuwania danych z systemów zgodnie z zebranymi zgodami. Niezależnie od długości przetwarzania ustalonej przez osoby odpowiedzialne za compliance, osoby techniczne muszą wiedzieć, że bez względu na to, jak długi ten okres będzie, muszą zmierzyć się z tym, że kiedyś dane będą musiały być usunięte.

    Przetwarzanie danych przy założeniu, że nie będziemy mieć narzędzi do ich usuwania, może naruszać regułę zawartą w art. 25 ust. 1 RODO, tj. privacy by design. Ciekawy w tym kontekście jest problem usuwania danych przetwarzanych przy wykorzystaniu technologii Blockchain, który właśnie taki przypadek obrazuje. Pojawia się pytanie, czy można przetwarzać dane skoro wiemy, że kiedyś tam w przyszłości może być problem całkowitego ich usunięcia. Polecam w tym zakresie rekomendację CNIL (francuski organ nadzorczy): Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data.

    Podsumowując. Chcąc skutecznie zarządzać procesem retencji, trzeba oczywiście dbać o stronę formalno-prawną. To jednak nie wystarczy. Musimy również wiedzieć dokładnie:

    W praktyce oznacza to, że trzeba wiedzieć, jak te dane usunąć i mieć pomysł na to, w jaki sposób to robić w zależności od celów ich przetwarzania.

    Dlaczego to jest ważne?

    Przykładowo może okazać się, że ta sama kategoria danych (np. nr pesel, ID użytkownika) przetwarzana przy wykorzystaniu tego samego systemu, lub różnych systemów, w zależności od celu przetwarzania będzie mieć różny okres retencji (usuwania danych).

    Co więcej może być tak, że w ramach jednego procesu różne kategorie dane mogą mieć różne cele i okresy retencji np. dane zbierane poprzez formularz rejestracji użytkownika. Może być tak, że część z tych danych jest niezbędna do realizacji celu zawarcia umowy, a część z nich np. służy do weryfikacji tożsamości co nie zawsze jest niezbędne do zawarcia umowy.

    Artur Żórawski (AŻ): Dodatkowo od strony technicznej jest to o tyle wyzwanie, że często w jednej organizacji jest wielu dostawców rozwiązań informatycznych. Wiele osób uczestniczy tym samym w procesie wytwarzania i rozwijania oprogramowania. Z rozmów z naszymi Klientami wiemy, że często w związku z tym problematyczne staje się zlokalizowanie wszystkich danych użytkowników we wszystkich systemach oraz ich kompleksowa retencja zgodnie z wymogami RODO.

    MG: Warto jeszcze dodać, że jednym z wymogów RODO jest podanie na żądanie informacji o źródle danych, czy celu przetwarzania danych osobowych, co w wielu przypadkach jest w tym kontekście problematyczne zwłaszcza, jeśli chodzi o podanie źródła. Pojęcie źródła danych jest bardzo szeroko zdefiniowane w RODO i nie można wykluczyć takiego kierunku wykładni, która obejmuje także “narzędzie”, system wykorzystywany do przetwarzania danych. Dla przykładu w kontekście przetwarzania danych medycznych RODO wskazuje, że:

    „Do danych osobowych dotyczących zdrowia należy zaliczyć wszystkie dane o stanie zdrowia osoby, której dane dotyczą, ujawniające informacje o (…)

    niezależnie od ich źródła, którym może być na przykład lekarz lub inny pracownik służby zdrowia, szpital, urządzenie medyczne lub badanie diagnostyczne in vitro”.

    Kiedy warto zacząć myśleć o  automatyzacji procesu?

    MG: Dochodzimy w tym momencie do pytania: w jaki sposób najlepiej tym procesem zarządzić? Faktem jest, że im większa organizacja, tym większym problemem staje się  brak odpowiednich narzędzi ułatwiających zarządzanie retencją danych na przykład poprzez automatyzację procesu.

    : To prawda. Pytanie tylko, kiedy na taką automatyzację się zdecydować. Jeżeli chodzi o retencje danych w większych organizacjach trzeba zauważyć, że problem usuwania danych i retencji rośnie wykładniczo wraz ze wzrastającą ilością systemów.

    MG: Mówiąc o tym poruszyłeś tak naprawdę kolejny problem. Nie wystarczy ustalić, że technicznie dane można usunąć np. „ręcznie”. Należy ustalić, czy ten sposób usuwania danych jest wystarczający, czy w praktyce będzie wystarczająco efektywny. Jeżeli ten brak efektywności może zrodzić ryzyko dla ludzi, którego źródłem jest naruszenie wymogu usuwania danych (np. ktoś nie zostanie dopuszczony do określonej usługi, bo system go “rozpozna”), sam w sobie może być naruszeniem zasady privacy by design.

    Retencja danych z punktu widzenia działów IT


    MG: W mojej opinii kwestia retencji, backupu, czy długości przechowywania danych to największe wyzwania na styku IT i compliance. Na ogół prawnicy stawiają bardzo sztywne wymagania. Wszystkie dane kategorii X ze względu na upływ czasu Y mają być usunięte/zaanonimizowane.  Niestety w praktyce proces usuwania danych jest dużo bardziej wymagający niż może nam się wydawać.

    : Dokładnie. Stanowisko w tej sprawie zajęło Ministerstwo Cyfryzacji tworząc “RODO – Poradnik dla sektora FINTECH”, gdzie wykazało, że nieusuwanie danych z kopii zapasowych może być uzasadnione:

    “W przypadku kopii zapasowych i żądania usunięcia danych na podstawie art. 17 RODO, może realnie zdarzyć się, że nie będzie technicznie możliwe usuniecie danych zawartych w kopii zapasowej lub koszty i wysiłek organizacyjny takiego selektywnego usunięcia danych będą w sposób rażący niewspółmierne do ryzyka naruszenia praw i wolności podmiotu danych. Ponadto selektywne usunięcie danych osobowych z kopii narusza integralność kopii danych a zatem może powodować ryzyko dla praw i wolności innych osób, których dane są przechowywane w ramach tej samej kopii danych.”

    Problem, który jednak nadal występuje jest związany z procedurami disaster recovery. Chcąc zobrazować tę kwestię, opowiem o wyzwaniu z zakresu odtwarzania backupu, przed którym stanęliśmy projektując rozwiązanie do retencji danych.

    Możemy wyobrazić sobie sytuację, w której dane osobowe Jana Kowalskiego ulegają retencji i są usuwane z bazy danych trzech systemów, w których były przetwarzane. Okazuje się, że jeden z tych systemów już po usunięciu danych ulega katastrofie. W związku z tym musimy odtworzyć jego backup. W efekcie mamy sytuację, w której w  systemach dane Jana Kowalskiego zostały usunięte, ale w jednym, tym drugim który uległ awarii dane Jana Kowalskiego nadal istnieją ze względu na konieczność przywrócenia danych sprzed retencji.

    Jest to moment, w którym może okazać się, że zapomnimy o konieczności usunięcia danych, które powinny być skasowane.

    Projektując rozwiązanie musieliśmy przewidzieć, że takie katastrofy mają szansę się wydarzyć. W takim wypadku, w ramach realizacji procesu retencji danych konieczne jest monitorowanie systemu, a konkretnie sprawdzanie, czy  nie rozpoczyna się proces odtwarzania backupu, w wyniku którego przywrócone zostałyby usunięte przez nas dane.

    MG: Kolejnym aspektem, który warto w tym kontekście omówić jest prawo do zapomnienia.Mechanizm retencji, z którego korzystamy musi uwzględniać dwa aspekty usuwania danych:

    AŻ: Tak, wspominaliśmy już o tym nieco powyżej. Jest to wyzwanie zwłaszcza dla dużych organizacji, które w momencie, gdy takie żądanie wpłynie, muszą ustosunkować się do niego i powiedzieć, które dane mogą usunąć zgodnie z prawem, a co do usunięcia których takich podstaw nie ma. Dodatkowo musimy także potwierdzić usunięcie danych.

    MG: W przypadku niektórych umów np. umowy o pracę nie jest to takie proste. Dane często nie są ustrukturyzowane.

    Dodatkowo dane tej samej osoby mogą znajdować się w innych naszych systemach. Mogą być przetwarzane dla różnych celów i w oparciu o różne podstawy. W jednej sytuacji może to być wspomniana realizacja umowy o pracę, w innej działania promocyjne w oparciu o zgodę dla celów marketingowych, etc. To kolejna sytuacja, w której nasze IT staje przed wyzwaniem. 

    Co istotne, nie chodzi o to, żeby (tylko) znać cele przetwarzania. Bo to jest stosunkowo proste. Chodzi o to, żeby być w stanie powiązać te cele z konkretnym rekordem. Zwłaszcza, gdy dane nie są przetwarzane w sposób ustrukturyzowany.

    Bardzo często zapomina się, że retencji powinny podlegać nie tylko dane podane nam aktywnie np. przez użytkownika systemu ale także te które on wygenerował korzystając z systemu (np. dane w logach) tzw. dane „zaobserwowane” oraz dane które sami wytworzyliśmy na jego temat wnioskując o jego przyszłym zachowaniu (profilowanie).

     AŻ: Chcąc zobrazować to wyzwanie wyobraźmy sobie ekosystem połączonych ze sobą wielu systemów informatycznych, które ze sobą współpracują i wymieniają się danymi osobowymi, gdzie jedna osoba może być przetwarzana na wiele sposobów.

    Gdzieś w nich są rozsiane te dane, przetwarzane na różnych podstawach, które z kolei są również przechowywane w różnych systemach. Robi nam się z tego całkiem spora sieć zależności. Rozwiązaniem jest jeden, zbiorczy system, który jest w stanie zagregować wszystkie zgody, które dana osoba podpisała.

    MG: Myśląc o procesie retencji powinniśmy także pamiętać o polityce uwzględniającej wyjątki. Może być np. tak, że zgodnie z procedurą retencji dane Y są automatycznie usuwane po okresie X. Jednocześnie w tym czasie wszczęta jest sprawa sądowa wymagająca dłuższego przetwarzania danych.

    AŻ: Dokładnie. Taką sytuację mieliśmy podczas jednego z naszych wdrożeń. Pomimo tego, że umowy wygasły i powinna w tym momencie nastąpić retencja danych Klienta, pojawiła się podstawa prawna, która ten proces uniemożliwiła. Okazało się, że podstawą był pozew sądowy i postępowanie wszczęte wobec właściciela danych. W takiej sytuacji dane osobowe były traktowane jako dowód w rozprawie. Jest to przypadek, który pokazuje, że powinniśmy uwzględniać wszelkie podstawy prawne, nie tylko wynikające bezpośrednio ze zgód.

    ABC retencji danych

    MG: Podsumowując, jeżeli chodzi o retencję, rozporządzenie RODO wymaga od nas, żebyśmy usuwali dane niezależnie od żądania usunięcia na podstawie wewnętrznie określonych okresów retencji, w powiązaniu z:

    Powinniśmy również uwzględniać możliwość wystąpienia specyficznych przypadków, o których mowa powyżej.

    AŻ: Projektując, lub wdrażając u siebie narzędzia do retencji danych osobowych zadbajmy o to, żeby:

    —————————————————-

    Odpowiadasz za techniczny lub prawny aspekt ochrony danych osobowych, ochronę bezpieczeństwa danych osobowych lub wrażliwych w swojej organizacji? A może w obszarze, którym się zajmujesz?

    Przed nami ostatni z cyklu “RODO w IT” artykuł, w którym porozmawiamy o tym, jak realizować projekty z zakresu sztucznej inteligencji w kontekście privacy&security.

    Masz dodatkowe pytania, chcesz wymienić się doświadczeniami, dowiedzieć się więcej o anonimizacji, detekcji i retencji danych osobowych, cykl życia produktów IT w kontekście RODO, w tym privacy by design, a także posłuchać o ciekawych case studies związanych np. z definicją danych osobowych, lub kolejnych etapach wdrażania RODO w Polsce.

    Zapisz się już dziś na nasz webinar RODO W IT.

    Śledź nasz profil na LinkedIn.

    Do usłyszenia!

    Artur i Mirek

    Borykasz się z problemem zwiększonego ryzyka wycieku danych osobowych podczas pracy zdalnej?
    Chcesz ograniczyć dostęp do wrażliwych danych w swojej firmie?
    Chcesz dowiedzieć się więcej na temat procesu anonimizacji danych?
    A może zastanawiasz się, czy proces anonimizacji, który masz wdrożony w swojej firmie można usprawnić?

    Jeśli tak, ten artykuł jest dla Ciebie. Wspólnie z Mirkiem Gumularzem, Radcą Prawnym zajmującym się zagadnieniami związanymi z RODO, postanowiliśmy poruszyć temat poprawnej, szybkiej i bezpiecznej anonimizacji danych osobowych.

    Z artykułu dowiesz się m.in.:

    Zapraszamy do lektury!

    Artur Żórawski, Founder&CTO Wizards
    i Mirosław Gumularz, Radca Prawny w GKK Gumularz Kozik

    Zapraszamy,

    Artur Żórawski, Founder i CTO Wizadrs

    Architekt IT z ponad 20 letnim stażem, autor pomysłów na rozwiązania IT do detekcji, anonimizacji i retencji danych. 

     i

    dr Mirosław Gumularz, Radca Prawny GKK Gumularz Kozik

    Audytor wewnętrzny systemu zarządzania bezpieczeństwem informacji wg normy ISO 27001:2013. Członek Grupy Roboczej ds. Ochrony Danych Osobowych przy Ministerstwie Cyfryzacji.

    ———————————

    Anonimizacja a pseudonimizacja

    Mirosław Gumularz (MG): W ostatnim artykule mówiliśmy sporo na temat zmian, które zaszły wraz z RODO w podejściu do zapewnienia zgodności z ochroną danych. Jednym ze sposobów, w jaki możemy o dane dbać jest anonimizacja, lub pseudonimizacja danych, czyli odpowiednio: zerwanie lub ograniczenie identyfikowalności osób fizycznych.

    Mówiąc o anonimizacji i pseudonimizacji widzę duży problem w rozróżnieniu obu pojęć. Wiele osób uważa, że zrealizowało wymogi co do ochrony danych (np. ich usuwania), bo zanonimizowało dane. W praktyce okazuje się często, że to nie jest anonimizacja, tylko pseudonimizacja, czyli nie zerwanie, a  odwracalne ograniczenie identyfikowalności, ponieważ cały czas istnieje jakiś rodzaj powiązania (chociażby poprzez zebranie dodatkowych danych ze źródeł publicznie dostępnych np. strony rejestrów publicznych, takich jak np. geoportal). Nie wiem, jak to z Waszej perspektywy wygląda, osób technicznych?

    Artur Żórawski (AŻ): Mam podobne obserwacje. Jest to związane pewnie z tym, że przeprowadzenie anonimizacji przy zachowaniu odpowiedniej jakości charakterystyki bazy, nie jest taką banalną sprawą. Podstawową wartością anonimizacji jest jej nieodwracalność. Jeśli udało się ją osiągnąć, to to oznacza właśnie dobrze zrobioną anonimizację. Możemy mieszać, maskować, ale rezultat powinien być jeden: brak możliwości zidentyfikowania konkretnej osoby. Z pseudonimizacją jest inaczej. Pseudonimizacja zakłada posiadanie klucza, za pomocą którego możemy odwrócić anonimizację i odzyskać dane. W efekcie nie tracąc ich.

    MG: Tak, dokładnie. To, na co warto zwrócić uwagę to fakt,  że od strony prawnej nie ma czegoś takiego, jak wymóg anonimizacji/pseudonimizacji. Są to narzędzia do realizacji określonych celów/wymogów np. bezpieczeństwa, czy ograniczenia czasowego przechowywania danych. Oba pojęcia dotyczą identyfikacji osoby fizycznej, czyli najogólniej rzecz ujmując – powiązania informacji z wyodrębnioną osobą fizyczną.

    W praktyce, dane speudonimizowane są cały czas danymi osobowymi. Oznacza to, że przetwarzając je, musimy zapewnić realizację wszystkich wymogów, o których mówiliśmy w pierwszym tekście, m.in. co do czasu przetwarzania danych, ograniczenia celu i minimalizacji.

    Nie mniej RODO traktuje pseudonimizację przede wszystkim jako środek do realizacji wymogu bezpieczeństwa według prostego rozumowania: jak wyciekną dane pseudonimizowane, to ryzyko dla osób fizycznych jest mniejsze, bo identyfikacja będzie utrudniona, lub wręcz niemożliwa (dla uzyskującego dostęp do części danych bez tego “klucza”, o którym mowa w definicji).

    Korzyści wynikające z anonimizacji


    MG: Wiemy już, jaka jest różnica między anonimizacją a pseudonimizacją. Zastanówmy się teraz, po co w ogóle anonimizować dane? Z punktu widzenia RODO anonimizacja ułatwia przede wszystkim „obejście” problemu celu przetwarzania. To z pozoru bardzo ogólny wymóg, który ma bardzo konkretne konsekwencje techniczne. Jeśli w trakcie przetwarzania chcemy zmienić cel przetwarzania, (np. wykorzystać te dane do rozwoju „uczenia” sztucznej inteligencji) to możemy w tym zakresie mieć kłopot z zalegalizowaniem tej zmiany celu. Wprawdzie RODO tego nie wyklucza, ale zawiera szereg obostrzeń m.in. obowiązek informowania o tym osób, których dane dotyczą. Anonimizacja rozwiązuje ten problem. Dane anonimowe nie podlegają RODO.

    AŻ: Tak, masz rację. Jakiś czas temu braliśmy udział w projekcie z zakresu sztucznej inteligencji i uczenia maszynowego, w ramach których wnioskowaliśmy i uczyliśmy algorytmy w oparciu o zbiór danych. Jednym z wyzwań była anonimizacja tego zbioru w taki sposób, że dane osób i w efekcie cały zbiór miały zachowywać charakterystykę i swoją tożsamość. Dane miały być w pełni wartościowe. Musieliśmy wymyśleć, jak to zrobić. Biorąc wszystkie te wszystkie wymogi pod uwagę można zażartować, że najlepiej tak naprawdę to tych danych nie mieć, ale w biznesie jest to praktycznie niemożliwe.

    MG: Masz rację. Trzeba pamiętać że sensie prawnym anonimizacja jest równoznaczna z fizycznym usunięciem danych. W obu przypadkach nie mamy danych osobowych (oczywiście o ile ten proces nastąpił w sposób prawidłowy). Dlatego anonimizacja ma także znaczenie przy realizacji wymogu ograniczenia czasowego przetwarzania, czyli jednego z fundamentów RODO. W tym wypadku anonimizacja oznacza wykonanie pewnego procesu, który powoduje, że informacja, która wcześniej dotyczyła zidentyfikowanej, lub możliwej do identyfikacji osoby, teraz już jej nie dotyczy. Stała się daną anonimową. Dlatego anonimizacja (jako metoda przetworzenia informacji) może być pomocna, gdy fizyczne usuwanie danych zgodnie z terminami przyjętymi w wewnętrznych politykach organizacji nie jest faktycznie możliwe (np. ze względu na realizację pomiędzy bazami danych).

    MG: Anonimizacja pozwala zrealizować także wymogi bezpieczeństwa w zakresie poufności danych. To  jest tym bardziej istotne w przypadku:

    Anonimizując dane, ograniczamy ryzyko ich wycieku. Anonimizacja spowoduje, że osoba niepożądana, która zyska dostęp do baz danych, nie zyska tym samym dostępu do danych osobowych, a jedynie do ich zanonimizowanej wersji.  Jest to szczególnie gorący temat w kontekście obecnej pandemii COVID-19, który wymusił na firmach wysłanie zdecydowanie większej ilości pracowników na pracę zdalną, niż to było do tej pory. Praca zdalna na danych anonimowych nie rodzi ryzyka związanego z naruszeniem RODO.

    AŻ: Anonimizacja z punktu widzenia programisty, architekta w takim przypadku daje możliwość spokojnego skupienia się na tym, na czym znamy się najlepiej – programowaniu i projektowaniu.

    Ja widzę jeszcze kilka korzyści z punktu widzenia IT.

    Systemy informatyczne nie lubią usuwania danych. Większość systemów preferuje gromadzenie dużych ilości danych, ponieważ w niektórych przypadkach fizyczne ich usunięcie może wpłynąć na efektywność systemu. Konieczność usuwania pojawia się w momencie, w którym użytkownik zażąda usunięcia jego danych osobowych, z których my akurat korzystamy. Z tego też względu tam, gdzie można oczywiście usuwamy te dane. W miejscach gdzie byłoby to kłopotliwe, dane ulegają anonimizacji. Oznacza to, że pod względem RODO dane znikają, ale nie są usuwane fizycznie.

    Miejscem, gdzie anonimizacja jest jeszcze stosowana w kontekście systemów informatycznych są testy. Wiemy, że zapewnienie odpowiedniej jakości testów też jest bardzo ważne. Przygotowanie testowych danych osobowych często jest trudne ze względu na ilość oraz charakter tych danych. W tym przypadku można wykorzystać te dane produkcyjne, które przeszły przez proces anonimizacji, dzięki czemu przestają podlegać RODO. Dzięki temu systemy mogą być testowane nie tylko pod względem funkcjonalności, ale mogą być również testowane pod kątem obciążeń – kontroli, czy dany system informatyczny będzie w stanie wytrzymać ruch i obciążenie systemu przez wszystkich użytkowników. Jest to ważne bo przecież nikt nie podpisuje zgód na wykorzystanie jego danych osobowych do testowania systemu.

    AŻ: Jeżeli chodzi o korzyści biznesowe, to jest ich kilka. Na przykład jedna firma prosi inną firmę o rozwój swojego systemu i w związku z tym dochodzi do przekazania danych osobowych. Ze względu na to, że system już istnieje trzeba go utrzymywać i w takim przypadku może dojść do przekroczenia danych osobowych między dwoma organizacjami. Dzięki anonimizacji baz danych będziemy w stanie przekazać jakościowe dane, lecz bez prawdziwych danych osobowych.

    Należy pamiętać, że żadna firma nie są samotną wyspą, dlatego w dzisiejszym biznesie dane dość swobodnie pływają pomiędzy podmiotami bez żadnych dodatkowych umów, czy obostrzeń. Mimo tego świadomość na temat danych osobowych w organizacji jest niska. Z doświadczenia mogę powiedzieć, że jedną z wątpliwości, którą często słyszę podczas spotkań w związku z wdrożeniem narzędzi anonimizacji danych jest brak wiedzy na temat przechowywania i przetwarzania danych osobowych. Dopiero gdy poznamy ten proces, możemy się zastanawiać się nad tym, co powinniśmy zmienić w systemach informatycznych i jakie procedury informatyczne oraz narzędzia powinny zostać wdrożone.

    Ryzyka związane z anonimizacją

    MG: Anonimizacja to korzyści, ale również ryzyka.Trzeba pamiętać, że proces anonimizacji może rodzić ryzyko dla ludzi, którego źródłem jest błąd i brak zerwania powiązania informacji z osobą fizyczną. W zakresie mierzenia tego ryzyka polecam dwa dokumenty:

    1. Opinia Grupy Roboczej art. 29 6/2013 dostępna pod linkiem: https://archiwum.giodo.gov.pl/pl/1520167/6944
    2. Rekomendacje ICO https://ico.org.uk/media/1061/anonymisation-code.pdf

    Oba dokumenty zawierają przykłady błędów, dobre praktyki oraz kryteria szacowania ryzyka, którego źródłem może być nieprawidłowa anonimizacja. Więcej o tych dokumentach będziemy mówić również na webinarium.

    W obu dokumentach podkreśla się, że granica pomiędzy danymi prawidłowo zanonimizowanymi jest płynna. Zresztą RODO wskazuje, że te same informacje w zależności od kontekstu (i możliwości zestawienia z innymi danymi przez dany podmiot) mogą być danymi anonimowymi, lub danymi osobowymi.

    Zgodnie z motywem 26 rodo:

    „(…) aby stwierdzić, czy dana osoba fizyczna jest możliwa do zidentyfikowania, należy wziąć pod uwagę wszelkie rozsądnie prawdopodobne sposoby (w tym wyodrębnienie wpisów dotyczących tej samej osoby), w stosunku do których istnieje uzasadnione prawdopodobieństwo, iż zostaną wykorzystane przez administratora lub inną osobę w celu bezpośredniego lub pośredniego zidentyfikowania osoby fizycznej. Aby stwierdzić, czy dany sposób może być z uzasadnionym prawdopodobieństwem wykorzystany do zidentyfikowania danej osoby, należy wziąć pod uwagę wszelkie obiektywne czynniki, takie jak koszt i czas potrzebne do jej zidentyfikowania, oraz uwzględnić technologię dostępną w momencie przetwarzania danych, jak i postęp technologiczny. Zasady ochrony danych nie powinny więc mieć zastosowania do informacji anonimowych, czyli informacji, które nie wiążą się ze zidentyfikowaną lub możliwą do zidentyfikowania osobą fizyczną, ani do danych osobowych zanonimizowanych w taki sposób, że osób, których dane dotyczą, w ogóle nie można zidentyfikować lub już nie można zidentyfikować”.

    Powyższy cytat oznacza, że pojęcie danych osobowych obejmuje informacje o różnym stopniu powiązania z wyodrębnioną osobą fizyczną, a granica pomiędzy danymi osobowymi oraz danymi anonimowymi jest często trudna do wytyczenia.

    W związku z tym można wyróżnić następujące sytuacje:

    1. Identyfikacja jest możliwa w oparciu o dane, którymi dysponuje administrator, nawet jeżeli identyfikacja wymaga ich zestawienia (np. dane w różnych bazach danych, przetwarzane lokalnie na urządzeniach, w usługach chmurowych). W tej kategorii mieszczą się także dane spseudonimizowane.
    2. Identyfikacja jest utrudniona (np. wymaga pozyskania dodatkowych danych), ale możliwa bez nadmiernych trudności.
    3. Zidentyfikowanie osoby fizycznej chociaż potencjalnie możliwe, jest nadmiernie uciążliwe (biorąc pod uwagę kryteria z motywu 26 RODO). 
    4. Zidentyfikowanie osoby fizycznej nie jest możliwe nawet po uzyskaniu dodatkowych informacji (biorąc pod uwagę kryteria z motywu 26 rodo)

    Oznacza to, że ustalenie czy określona informacja jest daną osobową wymaga oceny. Jak wskazują przytoczone dokumenty należy ocenić ryzyko, którego źródłem jest błąd na etapie anonimizacji prowadzący do re-identyfikacji. Chcąc oszacować to ryzyko należy:

    Niezwykle trudne jest oszacowanie prawdopodobieństwa ryzyka re-identyfikacji. Jeśli chcemy to zrobić idąc w ślad za rekomendacjami, warto posłużyć się testem tzw. zmotywowanego intruza. Na czym on polega?

    Test zmotywowanego intruza

    MG: Polega on głównie na rozważeniu, czy „intruz” byłby w stanie dokonać re-identyfikacji, gdyby był do tego zmotywowany. Podejście to zakłada, że ​​„zmotywowany intruz” jest kompetentny i ma dostęp do zasobów współmiernych do motywacji, jaką może mieć do ponownej identyfikacji.

    Niektóre rodzaje danych będą bardziej atrakcyjne dla „zmotywowanego intruza” niż inne. Na przykład intruz może być bardziej zmotywowany do re-identyfikacji danych osobowych, jeśli takie dane:

    AŻ: Tutaj poruszyłeś też bardzo ważny temat. Bezpieczeństwo danych to nie tylko RODO. Dane finansowe, tajemnice firmowe to są wszystko kategorie danych, które chcemy ochronić przed osobami nieuprawnionymi. W tym kontekście zabezpieczenie danych za pomocą anonimizacji jest znacznie szersze. Niektóre z naszych projektów bezpośrednio dotyczyły anonimizacji systemów finansowych i przetargowych, gdzie kwestie związane z danymi osobowymi praktycznie nie występowały, aczkolwiek zabezpieczenie danych finansowych oraz informacji powierzonych przez firmy trzecie było kluczowe dla działania całej organizacji.

    Jeśli zainteresował Was temat anonimizacji oraz warunków, jakie muszą być spełnione, żeby mówić o dobrej jakości anonimizacji, zerknijcie również na jeden z moich wcześniejszych artykułów: https://wizards.io/2020/02/anonimizacja/

    Znajdziecie tam m.in. rozwinięcie każdego z pojęć wykorzystanych przeze mnie w poniższym wykresie:

    ———————————————

    Odpowiadasz za techniczny lub prawny aspekt ochrony danych osobowych, ochronę bezpieczeństwa danych osobowych lub wrażliwych w swojej organizacji? A może w obszarze, którym się zajmujesz?

    Przez kolejne 2 tygodnie będziemy publikować na blogu Wizards nowe artykuły z cyklu RODO w IT, z których dowiesz się kolejno:

    Masz dodatkowe pytania, chcesz wymienić się doświadczeniami, dowiedzieć się więcej o anonimizacji, detekcji i retencji danych osobowych, cykl życia produktów IT w kontekście RODO, w tym privacy by design, a także posłuchać o ciekawych case studies związanych np. z definicją danych osobowych, lub kolejnych etapach wdrażania RODO w Polsce.

    Zapisz się już dziś na nasz webinar RODO W IT.

    Śledź nasz profil na LinkedIn.

    Do usłyszenia!

    Artur i Mirek

    Zaczynamy cykl publikacji na temat RODO w IT, który zakończymy webinarem, na który już dziś serdecznie zapraszamy. Skąd taki pomysł?

    Z RODO mamy do czynienia na co dzień, w różnych wymiarach. Z jednej strony w zakresie współpracy z firmami od strony prawnej, z drugiej z punktu widzenia wieloletniej pracy w branży IT. Obaj obserwujemy z zupełnie różnych perspektyw to, jak firmy radzą sobie z tematem RODO (ochroną prywatności))i z jakimi wyzwaniami muszą mierzyć się każdego dnia.

    Zapraszamy,

    Artur Żórawski, Founder i CTO Wizadrs

    Architekt IT z ponad 20 letnim stażem, autor pomysłów na rozwiązania IT do detekcji, anonimizacji i retencji danych. 

     i

    dr Mirosław Gumularz, Radca Prawny GKK Gumularz Kozik

    Audytor wewnętrzny systemu zarządzania bezpieczeństwem informacji wg normy ISO 27001:2013. Członek Grupy Roboczej ds. Ochrony Danych Osobowych przy Ministerstwie Cyfryzacji.

    ———————————————

    Relacje pomiędzy RODO i IT

    Artur Żórawski (AŻ): Wejście RODO wstrząsnęło światem IT i narzuciło nowe reguły gry. Okazało się, że jednym z głównych naszych obowiązków stała się odpowiednia ochrona danych osobowych (prywatności) i jest to coś, za co każdy kto pracuje w branży nowych technologii musi brać odpowiedzialność. Dlaczego?

    Mirosław Gumularz (MG): Zdecydowanie. O tej odpowiedzialności IT za ochronę danych osobowych możemy rozmawiać z punktu widzenia RODO w czterech kontekstach:

    Definicja danych osobowych wg RODO

    Artur Żórawski: Co więcej, nie tylko musieliśmy zmienić podejście do ochrony danych osobowych, ale także na nowo zrozumieć to pojęcie. Do tej pory nie było jasnych definicji, także często korzystaliśmy z amerykańskich standardów, takich jak PII (Personal Identifiable Information) oraz PHI, w ramach których definicja danych osobowych była w porównaniu z RODO dosyć ograniczona.

    Wszyscy mieliśmy świadomość, że trzeba dbać o podstawowe dane, takie jak imię i nazwisko, adresy, dane przestrzenne. To dbanie sprowadzało się jednak głównie do zapewnienia im bezpieczeństwa. Teraz RODO mówi o danych osobowych znaczenie szerzej, przewidując jak ich postrzeganie może zmienić się w przyszłości.

    MG: Tak, to prawda pojęcie danych osobowych w kontekście RODO jest niezwykle szerokie. W zasadzie w ramach każdego narzędzia informatycznego, czy usługi IT dochodzi do przetwarzania danych osobowych. Trudno mi sobie wyobrazić narzędzie, w którego funkcjonowaniu nie trzeba uwzględniać wymogów RODO. Mogłoby to dotyczyć np. danych statystycznych, ale także tutaj z pewnością w jakiejś “warstwie” systemu (np. logów) dane osobowe pojawiłyby się. 

    Praktycznie każdy system opiera się na jakiś kategoriach użytkowników, dostępów i w każdym systemie odkłada się nasza aktywność w logach.

    Cała masa danych w systemie np.:

    to są wszystko dane osobowe.

    Na tym gruncie dochodzi często do przekłamań. Za dane osobowe uznawane są często jedynie dane zostawiane przez użytkownika (np. stworzony login/username). Prawda jest jednak taka, że wszystkie informacje, chociażby potencjalnie możliwe do przypisania do wyodrębnionej osoby fizycznej, są danymi osobowymi.

    Wymogi RODO w pigułce

    MG: Co jeszcze warto wiedzieć dziś o RODO pracując w IT?  Na pewno to, że można identyfikować wymogi RODO w ramach dwóch głównych obszarów: bezpieczeństwa (security) oraz prywatności (privacy). Nie jest to podział do końca poprawny, bo bezpieczeństwo służy zapewnieniu również prywatności, ale chodzi mi tutaj o podkreślenie, że bezpieczeństwo to tylko jeden z aspektów ochrony danych, który jest naprawdę dobrze rozpoznany przez IT. Często osoby z branży IT wręcz utożsamiają prywatność z bezpieczeństwem. Problem jest z całą sferą pozostałych wymogów (privacy).

    AŻ: Tak, to prawda. W tematach security poruszamy się w wielu przypadkach bardzo sprawnie. Potrafimy zabezpieczyć od strony organizacji nasze sieci, systemy, komputery. Potrafimy zapobiec utracie danych i kontrolować dostęp do nich. W tych obszarach mamy jasność i wiemy, co musimy zrobić po naszej stronie.

    MG: Omówmy w takim razie pokrótce wszystkie wymogi RODO, a w szczególności ten mniej rozpoznany przez IT obszar prywatności (privacy). Poniżej znajdziecie wykres przedstawiający kluczowe dla zrozumienia RODO obszary z podziałem na te bardziej i mniej rozpoznane przez IT obszary.

    Oczywiście powyższe obszary nie wyczerpują szczegółowych wymogów RODO, ale moim zdaniem zrozumienie ich jest kluczowe. Dlaczego? Ponieważ obserwuję, często w praktyce, że dyskusja w kontekście zgodności skupia się na szczegółowych wymaganiach, pomijając zupełnie fundamenty, które powinny być brane pod uwagę w pierwszej kolejności.

    Wnioski z początków wdrażania RODO

    AŻ: Masz rację.Podsumowując.Minęły już prawie dwa lata od czasu wdrożenia RODO. Z mojego punktu widzenia duża zmianą jest to, że jako IT zaczęliśmy bardziej zastanawiać się nad tym, co właściwie przetwarzamy i przechowujemy, a przechowujemy dużo, bo systemy kochają gromadzić dane. Wcześniej nie musieliśmy zadawać pytań o rodzaj danych i cel przetwarzania, na bazie których je przechowujemy. Systemy w jednej organizacji mogły dowolnie wymieniać się danymi, ponieważ nie był dobrze zdefiniowany cel przetwarzania. Jakie wyzwania Twoim zdaniem mamy jeszcze przed sobą?

    MG: Z mojej perspektywy pierwszy okres funkcjonowania RODO pokazuje, że o ile środki organizacyjne (np. procedury, szkolenia) są punktem wyjścia realizacji wymogów RODO, to na ogół bez uwzględnienia technologii, czy też zmian w tym zakresie, nie da się w pełni zrealizować wymogów RODO (np. w kontekście usuwania danych).

    Moją drugą obserwacją jest to, że identyfikacja ryzyk związanych z funkcjonowaniem technologii wymaga wzajemnego zrozumienia ról pomiędzy osobami technicznymi (np. deweloperami) oraz pracownikami z działu compliance, czy działu prawnego, którego teraz często brakuje.
    Punktem wyjścia do wypracowania tego zrozumienia jest dialog i wzajemne przeszkolenie. Z jednej strony w zakresie wymogów i obowiązków stawianych przez RODO, a także metod oraz środków, którymi te wymogi można wdrażać. Z drugiej w zakresie specyfiki pracy IT i zmian w systemach informatycznych, które te ryzyka mogą rodzić.

    Co więcej zapewnienie zgodności wymaga czujności przez cały “cykl” życia narzędzia IT (np. aplikacji webowej), a nie tylko na początku (privacy by design). Moim zdaniem kluczem jest zarządzanie zmianą. Bardzo często informacja o istotnych zmianach wymagających oceny prawnej nie dociera do właściwych osób i zamyka się w kręgu speców od IT. Ale o tym, jak sobie poradzić z tymi kwestiami opowiemy więcej na webinarze.

    ———————————————

    Odpowiadasz za techniczny lub prawny aspekt ochrony danych osobowych, ochronę bezpieczeństwa danych osobowych lub wrażliwych w swojej organizacji? A może w obszarze, którym się zajmujesz?

    Przez kolejne 3 tygodnie będziemy publikować na blogu Wizards nowe artykuły z cyklu RODO w IT, z których dowiesz się kolejno:

    Masz dodatkowe pytania, chcesz wymienić się doświadczeniami, dowiedzieć się więcej o anonimizacji, detekcji i retencji danych osobowych, cykl życia produktów IT w kontekście RODO, w tym privacy by design, a także posłuchać o ciekawych case studies związanych np. z definicją danych osobowych, lub kolejnych etapach wdrażania RODO w Polsce.

    Zapisz się już dziś na nasz webinar RODO W IT.

    Śledź nasz profil na LinkedIn.

    Do usłyszenia!

    Artur i Mirek

    Niedługo minie dwadzieścia lat od momentu, kiedy dołączyłem do świata IT. Przez ten okres obserwowałem, jak zmienia się to środowisko, jak rozwijają się procesy wytwórcze i jakie nowe narzędzia są wykorzystywane. Z czasem wiele procesów, m.in. powtarzalne zadania, ulegało automatyzacji. Firmy wdrażały Continuous Integration i Continuous Delivery. Wszystkiemu przewodziła jedna myśl: pozwolić twórcom oprogramowania skupić się na rozwoju systemów i biznesie.

    Wejście RODO

    Wejście RODO wstrząsnęło światem IT i narzuciło nowe reguły gry. Proces wytwórczy stał się bardziej skomplikowany, operowanie na danych osobowych stało się dużym ryzykiem, które trzeba było zaadresować. Pracując w software house widzieliśmy te problemy wyraźnie, ponieważ występowały w każdym z naszych projektów. Teoretycznie byliśmy przygotowani na wejście RODO. Byliśmy po odpowiednich kursach, firma zbroiła się w dokumenty i rejestry. W praktyce okazało się, że obostrzenia prawne i niepewność związana z wejściem w życie tego rozporządzenia, wpłynęły na naszą codzienną pracę. Mój sen o developmencie bez przeszkód, gdzie możemy skupić się tylko na produkcji oprogramowania, prysnął. 

    Krótko po wdrożeniu RODO rozpoczęło się szukanie rozwiązań. Narzędzia, które udawało nam się znaleźć, nie odpowiadały na nasze potrzeby projektowe, ponieważ na co dzień rozwijaliśmy całe, zintegrowane, tworzone w różnych technologiach ekosystemy wymieniające się danymi osobowymi. Obsługa każdego przypadku, ręcznie i z osobna, była dla mnie nie do przyjęcia. Czułem się tak, jakbym cofnął się o dwie dekady.

    Zmiana status quo

    Ostatecznie w firmie wyłoniła się grupa ludzi, która postawiła sobie za cel zmianę status quo. Wiedzieliśmy, czego potrzebujemy i jak możemy ten plan zrealizować. Z takim wyzwaniem nigdy wcześniej się nie mierzyliśmy. Wspólnie jednak udało nam się stworzyć zestaw narzędzi, który był dla nas wybawieniem. 

    Anonimizacja danych

    Zaczęliśmy od anonimizacji danych na środowiskach testowych. Stworzyliśmy narzędzie, które było w stanie obsłużyć wiele aplikacji na raz, wziąć pod uwagę polską specyfikę i wykonać swoją pracę wydajnie.

    Wytworzone rozwiązanie miało obsługiwać wszystkie nasze projekty, dlatego priorytetem była wysoka konfigurowalność i możliwość dostosowania do różnych wymogów. Anonimizację włączyliśmy w procesy Continuous Integration i szybko wdrożyliśmy je w naszych projektach. Okazało się, że te najbardziej bolesne dla nas aspekty RODO są obsługiwane automatycznie i przestały spędzać sen z powiek zespołowi developerskiemu. Zupełnie tak, jakby ten obszar RODO przestał nas dotyczyć.

    Retencja danych osobowych

    Kolejnym krokiem była retencja danych osobowych, która jest niezbędna w prawie każdym systemie. Zadbanie o ten aspekt w pojedynczej aplikacji jest łatwe. Wykonanie retencji danych w dziesięciu zintegrowanych systemach jest znacznie trudniejsze, a przy stu – już praktycznie niemożliwe. Było dla nas jasne, że nie chcemy powtarzać tej samej funkcjonalności we wszystkich systemach, które wytwarzamy. W ten sposób narodziło się kolejne narzędzie, które zdejmowało z nas kolejny problem.

    Wszystko wróciło na dobre tory, tak jak sobie wymarzyłem. Na szczęście RODO okazało się być jedynie wybojem na drodze w naszych projektach.

    Wizards

    Z tą też myślą założyliśmy startup. Doszliśmy do wniosku, że problemy, z którymi borykaliśmy się do tej pory dotyczą wielu zespołów developerskich, a my mamy klucz do ich rozwiązania. Dlatego też postanowiliśmy stworzyć nocturno i oblivio, o których już wkrótce więcej przeczytacie m.in. na naszym firmowym profilu Wizards.

    Artur Żórawski, Founder&CTO Wizards

    Dobrej jakości testy wymagają dobrych danych – najlepiej odzwierciedlających dane rzeczywiste. Bardzo często wykorzystywana w tym celu jest kopia danych produkcyjnych. Takie dedykowane środowisko testowe używane jest do reprodukowania zgłoszeń, debugowania problemów z danymi i realizowania testów obciążeniowych. Pomijając już to, że taka praktyka jest najczęściej niezgodna z RODO, to o ile środowisko produkcyjne jest monitorowane i audytowane niczym forteca, a dostęp do niego mają nieliczne osoby, to środowiska nieprodukcyjne są traktowane już zdecydowanie mniej restrykcyjnie. Grono osób mających do nich dostęp (nie licząc użytkowników) jest też zdecydowanie większe. Wiele poważnych wycieków danych osobowych to nie były włamania do fortecy, a wykorzystanie właśnie tych tzw. „niebronionych osad”.

    W obszarze danych testowych najczęściej występują dwie skrajności – dane osobowe przetwarzane są przez testerów i deweloperów w kopiach baz produkcyjnych, lub czekamy pół roku na odświeżenie testowych środowisk sztucznymi danymi, najczęściej kiepsko przygotowanymi. Rozwiązaniem tego problemu może być wdrożenie anonimizacji, jednak okazuje się, że nie jest to łatwe zadanie.

    Wyzwania związane z projektowaniem procesu anonimizacyjnego

    Proste maskowanie danych może sprawdzać się w prostych przypadkach, jednak szybko można zauważyć, że nie jest to wystarczające dla zastosowań, z którymi zazwyczaj stykamy się na co dzień. Z drugiej strony, przeglądając istniejące rozwiązania zauważyliśmy, że nie spełniają naszych potrzeb – najczęściej nie wspierają mechanizmów pozwalających zachować spójność danych pomiędzy różnymi bazami danych. Trudno też znaleźć rozwiązanie wspierające automatyzację procesu anonimizacyjnego. Najbardziej popularne narzędzia nie pozwalają na definiowanie własnych generatorów nie tylko dotyczących pojedynczego wiersza, ale także uwzględniających rozkład danych. Implementując samemu rozwiązanie spełniające te założenia szybko można natknąć się na przeszkody:

    Złoty środek

    Istnieje jednak złoty środek – zapewnienie swobodnego dostępu do wysokiej jakości danych odzwierciedlających charakterystykę danych produkcyjnych, przy jednoczesnym zapewnieniu bezpieczeństwa rozwiązania i zgodności z regulacjami prawnymi. Ten złoty środek to Nocturno – narzędzie do anonimizacji danych, który zaprojektowaliśmy wspólnie z zespołem. Pracując nad tym rozwiązaniem postanowiliśmy zadbać o:

    Co zyskujemy wdrażając dobrej jakości anonimizację?

    Wdrażając anonimizację jesteśmy w stanie znacząco zmniejszyć liczbę osób posiadających dostęp do danych osobowych do absolutnego minimum. Dzięki dobrej jakości zanonimizowanych danych, wykorzystywanie ich w celach wytwórczych oprogramowania jest transparentne i zgodne z RODO. Proces oparty o Nocturno jest łatwo konfigurowalny i utrzymywalny przez deweloperów – może być równolegle rozwijany w tym samym codebase co aplikacja.

    Nocturno wspiera dwa główne scenariusze wdrożeniowe:

    Rys. miejsce Nocturno w automatycznym procesie dostarczania zanonimizowanych kopii baz danych

    Więcej na temat Nocturno znajdziecie pod tym linkiem: https://wizards.io/nocturno/. W przypadku pytań na temat procesu anonimizacji, zachęcam do kontaktu.

    Marcin Gorgoń, Senior Software Engineer

    Mało kogo ominęły przepastne artykuły na temat RODO i przeróżnych, często przerażających sankcji za jej nieprzestrzeganie. Niewielu za to zagłębia się w takie istotne szczegóły, jak znacznie anonimizacji czy retencji, które pozwalają uniknąć tych wyżej wspomnianych sankcji oraz znacząco ułatwić pracę deweloperów. Z tego też względu postanowiliśmy w przystępny sposób wyjaśnić, czym są anonimizacja i retencja danych osobowych oraz pokazać, dlaczego ich właściwe wykonanie ma takie znaczenie w procesie wytwarzania oprogramowania. Dzisiaj na warsztat bierzemy anonimizację.

    Czym jest anonimizacja?

    Anonimizacja to proces pozwalający na trwałe usunięcie powiązań między danymi osobowymi, a osobą, której dotyczą. W ten sposób informacje, które przed anonimizacją były danymi osobowymi, przestają nimi być.

    Jak to wygląda w praktyce?

    Powyższa definicja staje się mniej zagmatwana jeśli wesprzemy ją przykładem. Wyobraźmy sobie np. Supermana – komiksowego bohatera pochodzącego z Kryptonu, który chce ukryć swoją tożsamość i wtopić się w tłum. 

    NazwaSuperman
    ZawódBohater
    PochodzenieKrypton

    Podczas procesu anonimizacji Superman wchodzi do budki telefonicznej, zakłada okulary, tweedowy garnitur i staje się w tym momencie Clarkiem Kentem, reporterem z Kansas.

    NazwaClark Kent
    ZawódReporter
    PochodzenieKansas, USA

    W procesie anonimizacji dane Supermana zamieniły się na dane Clarka Kenta, co więcej nie ma żadnego powiązania między tymi dwiema osobami. To dane fikcyjne, które mogą być bezpiecznie wykorzystywane np. na środowiskach testowych.

    Powyższy przykład obrazuje, na czym polega sam proces anonimizacji. Zastanówmy się teraz, dlaczego ważne jest, żeby anonimizacja była dobrej jakości.

    Nieodwracalność

    Fundamentem anonimizacji jest jej nieodwracalność. Na podstawie zanonimizowanych danych nigdy nie powinniśmy dociec, jak wyglądały dane oryginalne. Współpracownicy Clarka nie powinni odkryć jego prawdziwej tożsamości. 

    Kiedy zbiór danych poddajemy anonimizacji, to zazwyczaj zmianie ulega jedynie fragment danych. Musimy jednak zadbać o to, aby dane niezanonimizowane nie pozwoliły na odwrócenie procesu anonimizacji dla całego zbioru. W naszym przykładzie nie musielibyśmy zmieniać ulubionego koloru Supermana. Jeżeli jednak nie anonimizujemy jego pochodzenia, to z pewnością wzbudzimy sensację.

    Realność

    Istotną miarą jakościową anonimizacji jest też jej realność i to, jak dobrze odwzorowuje rzeczywistość. Jeżeli Superman i wszystkie inne osoby w zbiorze danych zostaną zanonimizowane w następujący sposób:

    NazwaX
    ZawódY
    PochodzenieZ

    to nie mamy wątpliwości, że proces jest nieodwracalny, jednak jego przydatność jest wątpliwa. Pan X nie wygląda na człowieka z krwi i kości, a charakter danych oryginalnych nie został zachowany. Długości nazw nie zostały zachowane, a same dane wyglądają na niewiarygodne i wszystkie osoby nazywają się tak samo. W przypadku systemów informatycznych tester wykorzystując takie dane miałby sporo problemów, nie byłby w stanie nawet rozróżnić osób.

    Powtarzalność

    Kolejną cechą dobrej anonimizacji jest jej powtarzalność. Anonimizując zbiór danych chcemy mieć pewność, że za każdym razem zbiór danych zostanie zanonimizowany w taki sam sposób. Chcemy, aby Superman zawsze stawał się Clarkiem Kentem, niezależnie czy jest to pierwsza, czy dziesiąta anonimizacja. Jest to szczególnie ważne z punktu widzenia Quality Assurance. Testerzy często tworzą przypadki testowe opierając się na konkretnych danych. Gdybyśmy je zmieniali za każdym razem, z pewnością praca testera byłaby trudniejsza!

    Zintegrowane systemy

    Dzisiejszy świat informatyki to systemy połączone. Prawie żadna aplikacja nie jest samotną wyspą. Systemy łączą się ze sobą, wymieniają danymi, korzystają ze swoich usług. Z tego też względu podchodząc do anonimizacji, musimy myśleć o procesie nie dla jednego, ale dla wielu systemów na raz. Wyzwaniem jest, aby zanonimizowane dane były spójne w całym ekosystemie. Oznacza to, że jeżeli Daily Planet (miejsce pracy Clarka) posiada system kadrowy oraz bloga, to w obu tych aplikacjach Superman stanie się Kentem.

    Wydajność

    Ostatnim z mojego punktu widzenia, kluczowym parametrem mającym wpływ na jakość anonimizacji jest wydajność. Systemy informatyczne przetwarzają olbrzymie zbiory danych liczonych w gigabajtach czy terabajtach. Anonimizacja takich baz danych może być czasochłonna w związku z czym musimy zapewnić nie tylko bezpieczeństwo, ale również szybkość procesu anonimizacji. Jedną z rzeczy, którą nauczył się Superman po przybyciu na Ziemię, jest to, że czas to pieniądz. To powiedzenie jest jeszcze bardziej prawdziwe w przypadku nowoczesnego IT.

    Wszystkich zainteresowanych tematem retencji danych zapraszam do przeczytania kolejnego mojego artykułu, który planuję opublikować już niedługo.

    Artur Żórawski, Founder&CTO Wizards