Witam,
rzucam taki temat: ustawa o przetwarzaniu danych osobowych formułuje kilka
wymogów dot.
systemów informatycznych, w skrócie:
A. obowiązek informowania o przetwarzaniu danych osobowych
B. obowiązek tworzenia historii udostępnienia danych osobowych
C. obowiązek respektowania prawa osoby do odmowy przetwarzania jej danych
osobowych, w szczególności obowiązek realizacji żądania zaprzestania
przetwarzania
jej danych osobowych.

Punkt B jest stosunkowo 'prosty' - należy ewidencjonować dostępy do danych
osobowych,
mieć kontrolę nad tym, komu dane osobowe powierzamy.

Przy punkcie A nie ma problemu, jeśli klient własnoręcznie podpisuje na
miejscu
odpowiednie zgody, ale problemy pojawiajasię, kiedy klient daje nam dane
osobowe
osób trzecich, co wcale nie jest sytuacją rzadką. Typowe przykłady:
- przy zakupie polisy ubezpieczeniowej klient podaje listę osób
uposażonych - np.
podaje dane swojej żony i swoich dzieci. Powstaje dylemat: czy
ubezpieczyciel jest
w tym momencie zobowiazany do:
- poinformowania tych osób, że rozpoczął przetwarzanie ich danych osobowych
?
lub gorzej:
- uzyskania zgody tych osób na przetwarzanie ich danych ?
Jeszcze lepiej sytuacja wygląda w systemach finansowych, zajmujących się
realizacją
przelewów. Potencjalnie każdy przelew od lub do odbiorcy 'spoza systemu' to
rozpoczęcie przetwarzanai jego danych osobowych bez jego zgody (dane są
wystarczajace,
by go jedoznacznie zidentyfikować).

Ale przejdźmy do punktu C, bo na tym chciałbym się skupić, bardziej
technicznie.
Z punktem C wiąże się typowy problem usuwania danych osobowych z backupów
- co jest bardzo kosztowne. Jednak wychodzi na to, że należy to robić. Można
np.
poczytać o wyroku sądu i dyskusjach:
Sygn. Akt. II SA/Wa 1801/07
http://www.ipcasebook.tbsp.pl/upload/IP%20Casebook%2
0-%20orzeczenie%202%20-%20dr%20Kaliński.doc

http://www.goldenline.pl/forum/321468/usuwanie-danyc
h-z-kopii-zapasowych
http://prawnik.net.pl/content/view/103/6/
Jak się spojrzy, to sprawa wydaje się trochę 'beznadziejna', chciałbym
jednak
podyskutować na temat takiego pomysłu technicznego, który wydaje się
całkowicie rowiązywać
problem:
1. Każdy klient, którego dane są przechowywane w systemie dostaje unikalny
identyfikator
i jest dla niego generowany unikalny klucz szyfrujacy (niech będzie to dla
prostoty szyfrowanie
symetryczne, czyli jeden klucz do szyfrowania i deszyfrowania)
2. Klucze szyfrujące są trzymane w oddzielnej bazie danych
3. W procedury tworzące backupy wbudowujemy szyfrowanie wybranych danych
osobowych
i w backupach są one przechowywane wyłącznie w postaci zaszyfrowanej.
Skupiamy
się stricte na komplecie danych osobowych, tj. imię, nazwisko, dane
teleadresowe,
pesel, nip, nr dowodu. Być moze coś jeszcze - ale generalnie zbiór ten jest
dość stały.
Technicznie kopia bazy danych (a wręcz jednej tabeli) z kluczami może być
wbudowana
w bazę backupowaną, ale musi być wyłączona z backupów.
4. W procedury odtwarzające bazy danych z backupów:
- w celach nieprodukcyjnych nie dokonujemy deszyfracji uzyskując dane
zanonimizowane,
- w celach produkcyjnych dokonujemy deszyfracji zgodnie z dostępnymi
kluczami. Dane
dla których klucze nie istnieją pozostawiamy w postaci niezanonimizowanej.
5. Uczulamy systemy na to, że mogą się w nich pojawiać dane zanonimizowane,
np. formatki
wyświetlajace imię i nazwisko powiny sobie dawać radę z wyświetleniem ich w
postaci
zaszyfrowanej (można spróbować zapewnić, by w wyniku szyfrowania powstawały
dane
alfanumeryczne), procedura walidacji numeru PESEL powinna rozpoznać, że ma
do czynienia
z zawartością zanonimizowaną i nie zgłaszać błędów itp itd. - moze to być
istotne przede
wszystkim z punktu widzenia serwisowania systemu, testowania go na danych
zanonimizowanych
itp.
6. Na żądanie usuniecia danych osobowych ograniczamy się wyłącznie do
usuniecia
odpowiedniego klucza - z bazy podstawowej oraz ew. z wszystkich jej kopii
roboczych
w systemach, jeśli takie istnieją.
Jeśli z naszego 'biznesu' wynika, że baza danych z kluczami musi być
archiwizowana
w dłuższym okresie (np. musimy przechowywać kopie baz z wielu miesięcy) to
mamy do rozwiazania problem usuniecia kluczy z tych backupów - co w sposób
oczywisty jest o niebo lżejsze, niż usuwanie jakichkolwiek danych z backupów
ciężkich baz produkcyjnych.

Czy ktoś może widział/realizował podobne rozwiązanie w praktyce ? Może ma
jakieś uwagi
do powyższego pomysłu ?
Słyszałem, że taka idea jest stosowana m.in. w aplikacji IBM Lotus Notes,
tzn. można włączyć
funkcję, gdzie dane pracowników, ich poczta itp. są szyfrowane. Mamy nawet
szyfrowanie
asymetryczne, tj. pracownik na swoim komputerze trzyma klucz prywatny, a
udostępnia
klucz publiczny, z pomocą którego wszystko, co jest do niego adresowane jest
szyfrowane.