Anonimizacja danych

Wykorzystywanie na „testówkach” danych rzeczywistych lub danych słabo znanonimizowanych może być zmorą niejednego ABI'ego. Zazwyczaj dokładamy wszelkich starań aby zmobilizować informatykę do prawidłowego zabezpieczenia „produkcji” a jak się może okazać największa słabość/niezgodność może być tam gdzie tego się najmniej spodziewamy.

W prawidłowo zbudowanym środowisku informatycznym powinna być wprowadzona rozdzielność środowisk na: produkcyjne, testowe i deweloperskie. Jednym z powodów wprowadzenia takiej rozdzielności jest konieczność prawidłowego zabezpieczenia danych osobowych, które powinny być przetwarzane tylko w środowiskach produkcyjnych.

Środowiska testowe i deweloperskie służą zazwyczaj do prac związanych z rozwojem systemu, często mają do nich dostęp przypadkowi użytkownicy czy też pracownicy podmiotów zewnętrznych (np. dostawcy aplikacji). Nikt też raczej nie dokłada szczególnych starań aby posiadały zaimplementowane zabezpieczenia wymagane przez ustawodawcę - nie jest to konieczne.

Sporym zagrożeniem dla bezpieczeństwa danych osobowych może być ich skopiowanie z „produkcji” na „testówkę” bez anonimizacji lub ich słabe „zamazanie”. Anonimizacja danych to nie tylko modyfikacja numeru pesel, to również zmiana danych adresowych, kontaktowych czy też dodatkowych pytań autoryzujących klienta podczas kontaktu z firmą.

Na tym polu ABI powinien się wykazać rolą doradczą (jak poprawnie zanonimizować) ale również rolą nadzorczą aby informatyka nie narażała danych osobowych na ujawnienie osobom nieupoważnionym.

Odpowiedzi

Portret użytkownika Leszek Kepa

To fakt. Generalnie, dla niewtajemniczonych, w firmie, w której rozwija się (pisze się) program (np. do obsługi klientów) jest kilka baz danych:

  • developerska - na której się tworzy program (tu można robić wszystko) - tu nie powinno być danych klientów, nie są do niczego potrzebne
  • testowa - baza do testowania czy napisany program działa prawidłowo - tu powinny być jakieś dane, aby można było testować program
  • produkcyjna - uzywana na codzień do pracy (w tej bazie lepiej nie testować, bo jak sie coś zepsuje, to firma stanie w miejscu).

Zmiany przechodzą następująco developerska->testowa->produkcyjna. Największym problemem jest ta "środkowa" baza danych. Musi być w strukturze identyczna z produkcyjną, więc często jest tak, że robi się kopię bazy produkcyjnej, zniekształca (anonimizuje) dane i można na niej testować. Testują pracownicy, ale tez bywa i firmy zewnętrzne. Największą bolączką tych baz jest przede wszystkim prawidłowa anonimizacja danych, co wcale nie jest łatwe. Nie zawsze da się przecież zamienić wszystkie numery PESEL na np. identyczne (0000000000), bo może się zdarzyć, że musza być unikalne. Pesele się walidują ("sprawdzają") z datą urodzin i płcią (więcej o tym http://wipos.p.lodz.pl/zylla/ut/pesel.html) - to kolejny problem, bo dokonując anonimizacji trzeba te trzy wartości ze sobą "zsynchronizować". Anonimizacja zazwyczaj zajmuje trochę czasu, nic więc dziwnego, że czasami kusi, aby ją "usprawnić" (nie wszystko anonimizować), albo nawet zrezygnować z niej...

A jaki jest formalny wymóg anonimizacji ? Czy jeśli dostęp do środowisk testowych (np. UAT) jest ściśle kontrolowany, a wszyscy użytkownicy mają podpisane odpowiednie kwity, to co stoi na przeszkodzie, żeby trzymać tam czyste dane z produkcji?

Portret użytkownika admin

Formalnego wymogu anonimizacji nie ma. Ustawa o ochronie danych osobowych uznaje anonimizację za jedną z form "usuwania" danych osobowych.

Zgadza się - jeśli środowiska "rozwojowe" mają odpowiednie "zabezpieczenia", to nie ma konieczności anonimizować. w praktyce środowiska takie są mniej chronione. Ponieważ są rozwojowe, to być może posiadają błędy, które mogą umożliwiać wyciek danych i dlatego utarło się anonimizować dane. W niektórych branżach jest to szczególnie istotne np. w bankach.