a ile Ty dni chcesz przechowywać backup? chyba nie dużej niż 1-2-3 miesiące



Użytkownik "sielim" <s...@t...tez.wp.pl> napisał w wiadomości
news:4de4ee72$0$2501$65785112@news.neostrada.pl...
> 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.
>