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.

do góry

W dniu 2011-05-31 15:34, sielim pisze:

> 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 ?

Tylko że przetwarzanie i archiwizowanie danych osobowych nie podlega
jedynie pod GIODO ale pod inne ustawy. Np. dotyczące rachunkowości,
rozliczeń skarbowych, danych medycznych itd itp.
Klient może żądać zaprzestania przetwarzania danych osobowych w celach
marketingowych, jednak nie może żądać całkowitego przetwarzania danych
osobowych, bo firma może podlegać pod inne ustawy. Z mojego podwórka,
dane o pacjentach muszą być przechowywane przez 5, 26 lub bezterminowo,
z zależności od klasyfikacji pacjenta.

Tak więc zapewne sposób realizacji owego "żądania" zależy od branży w
jakie się obracamy.


pozdrawiam,
Przemek O.

do góry

Użytkownik "Przemek O." <p...@o...eu> napisał w wiadomości
news:is3d5l$jp2$1@news.onet.pl...

> Tylko że przetwarzanie i archiwizowanie danych osobowych nie podlega
> jedynie pod GIODO ale pod inne ustawy. Np. dotyczące rachunkowości,
> rozliczeń skarbowych, danych medycznych itd itp.
> Klient może żądać zaprzestania przetwarzania danych osobowych w celach
> marketingowych, jednak nie może żądać całkowitego przetwarzania danych
> osobowych, bo firma może podlegać pod inne ustawy. Z mojego podwórka, dane
> o pacjentach muszą być przechowywane przez 5, 26 lub bezterminowo, z
> zależności od klasyfikacji pacjenta.
>
> Tak więc zapewne sposób realizacji owego "żądania" zależy od branży w
> jakie się obracamy.

Słuszna uwaga,w moim przypadku widać konflikt z ustawami o rachunkowości
i regulującymi działałność banków. Tym niemniej - zawsze pojawiają się
sytuacje
(jak np. opisywane w linkach, kiedy bank gromadzi dane o osobach,
które nie podpisały umowy kredytowej i nic ich z bankiem nie wiąże), kiedy
jakieś dane osobowe na żądanie/z obowiązku należy z systemu informatycznego
usunąć - a nie możemy sobie pozwolić na usuwanie całych kopii zapasowych.

do góry

W dniu 2011-05-31 20:48, Przemek O. pisze:
> W dniu 2011-05-31 15:34, sielim pisze:
>
>> 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 ?
>
> Tylko że przetwarzanie i archiwizowanie danych osobowych nie podlega
> jedynie pod GIODO ale pod inne ustawy. Np. dotyczące rachunkowości,
> rozliczeń skarbowych, danych medycznych itd itp.
> Klient może żądać zaprzestania przetwarzania danych osobowych w celach
> marketingowych, jednak nie może żądać całkowitego przetwarzania danych
> osobowych, bo firma może podlegać pod inne ustawy. Z mojego podwórka,
> dane o pacjentach muszą być przechowywane przez 5, 26 lub bezterminowo,
> z zależności od klasyfikacji pacjenta.
>
> Tak więc zapewne sposób realizacji owego "żądania" zależy od branży w
> jakie się obracamy.

Z drugiej ręki, więc nie do końca pewne - dla GIODO kilka lat temu
wystarczało, że sytem nie przetwarza danych osób, które żądały usunięcia
ich danych z bazy. Poniważ jednocześnie dane były nabywane od
zewnętrznych podmiotów, to podstawowe dane identyfikujące osobę wręcz
musiały zostać, żeby z zewnętrznych baz odsiewać osoby, które we własnej
kazały się skreślić. Biznesowo chodziło o to, że jeśli osoba nie chce
więcej ulotek, to nie powinna ich dostać, nawet jeśli firma kupiła inną
bazę, w której ta sama osoba wyraziła zgodę (innemu podmiotowi, nawet
z pozwoleniem przekazywania danych dalej).

--
Paweł Kierski
n...@p...net

do góry

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.
>

do góry

On 2011-06-03, Rafal(sxat) <g...@o...pl.usun.to> wrote:
> a ile Ty dni chcesz przechowywać backup? chyba nie dużej niż 1-2-3 miesiące

Zapewne tyle ile trzeba. Nie wiesz na ile czasu do tyłu trzeba backupu.

I dlaczego odpisujesz nad cytatem?

--
Secunia non olet.
Stanislaw Klekot

do góry

Użytkownik "Rafal(sxat)" <g...@o...pl.usun.to> napisał w wiadomości
news:isaasf$ced$1@news.onet.pl...
> a ile Ty dni chcesz przechowywać backup? chyba nie dużej niż 1-2-3
> miesiące

Będziesz miał upierdliwego klienta a za nim sąd - i będzie, że 3 miesiace to
bardzo drastyczne
(i kosztowne) naruszenie ustawy. A są sytuacje, w których dla celów
kontrolnych
(księgowość-skarbówka, jakiekolwiek inne instytucje kontrolne działające w
otoczeniu danego
biznesu) masz obowiązek trzymać odpowiednie dane dużo dłużej.

do góry