Strona główna » Blog » Bezpieczeństwo informacji

Kategoria: Bezpieczeństwo informacji

UODO twierdzi, że pracodawca nie może weryfikować dokumentów

Ciekawostka z opublikowanego w zeszły czwartek przez Urząd Ochrony Danych Osobowych “Poradnika dla przedsiębiorców“: otóż, pracodawcy NIE WOLNO sprawdzać dokumentów przedłożonych przez kandydata do pracy dzwoniąc do podmiotów, które te dokumenty wystawiły. Czyli NIE WOLNO mu dzwonić do uczelni, aby zweryfikować dyplom, czy do poprzedniego pracodawcy, aby zweryfikować referencje.

To, co pracodawca może, to ewentualnie “mieć podejrzenia” i na ich podstawie złożyć zawiadomienie o możliwości popełnienia przestępstwa z tytułu art 270 Kodeksu Karnego (“Fałszowanie dokumentu i używanie go za autentyczny”).

Konsekwencje uznania adresu e-mail za dane osobowe

Dane osobowe to kłopotliwa sprawa, bo wymagają szczególnej ochrony, gdy są przetwarzane w celach zarobkowych, zawodowych lub statutowych (czyli innych niż prywatne). W związku z tym ich istnienie lub też nagłe zaistnienie w systemie informatycznym pociąga za sobą rozmaite konsekwencje – pojawia się obowiązek wdrożenia zabezpieczeń i funkcjonalności wymaganych przez prawo. Z perspektywy informatyka-wykonawcy oznacza to przede wszystkim dodatkowe nakłady pracy a dla klienta przekłada się to na wzrost kosztu wykonania systemu oraz konieczność prowadzenia wymaganej prawem dokumentacji, ewidencji, nadawania upoważnień. Jak się okazuje, uniknięcie komplikacji jest wcale niełatwe zważywszy na to, że według Głównego Inspektora Ochrony Danych Osobowych już sam adres e-mail może być danymi osobowymi a system przetwarzający adresy e-mail przetwarza właśnie dane osobowe:

„Specyfiką Internetu jest to, że aby zamówić newsletter danego serwisu należy wpisać na jego stronie swój adres e-mail, który w rozumieniu ustawy o ochronie danych osobowych stanowi dane osobowe.” [źródło]


Można znaleźć znacznie szerszy opis zagadnienia klasyfikacji adresów poczty elektronicznej jako danych osobowych w rozmaitych innych publikacjach – np. w „ABC Zagrożeń Bezpieczeństwa Danych Osobowych w Systemach Informatycznych” (rozdział 2.5). Polecam tę lekturę, bo zawiera ona także ciekawe wypowiedzi na temat traktowania adresów IP, loginów i pseudonimów jako danych osobowych.

W wielkim skrócie: adres e-mail dosyć często może być danymi osobowymi, chociaż w wielu przypadkach tak nie jest. W każdym przypadku konieczne jest indywidualne podejście i analiza. Może być też tak, że pewien adres e-mail stanie się danymi osobowymi po upływie czasu – np. gdy korzystający z niego użytkownik tak dalece go rozpowszechni w Internecie, że ktokolwiek posiadając ten adres poczty i korzystając z wyszukiwarki internetowej będzie w stanie w ciągu minut albo nawet sekund dotrzeć do tożsamości jego właściciela.

Dla informatyka-wykonawcy może oznaczać to komplikacje, gdy jego klient zażyczy sobie, aby jego serwis internetowy zawierał np.:

  • Zapis do newslettera;
  • Obsługę newsletterów lub inną funkcjonalność związaną z mass-mailingiem – np. różnego rodzaju wysyłka powiadomień;
  • Rejestrację kont dla użytkowników, którzy dzięki temu będą mieli dostęp do dalszych funkcjonalności, jeżeli wymagany będzie adres e-mail;
  • Mechanizm potwierdzania decyzji użytkownika poprzez wysyłanie e-mailem linków potwierdzających, tymczasowych haseł, kodów lub tokenów;
  • Mechanizm przypominania hasła wysyłający nowe hasło e-mailem;
  • Wymuszanie podania adresu e-mail jako rodzaj zabezpieczenia przy np. komentowaniu artykułów.

Niektóre z wymienionych wyżej funkcjonalności są, niestety, nie tylko popularne, ale mocno wbudowane w dostępne oprogramowanie open-source, co od razu utrudnia informatykowi-wykonawcy bazowanie na gotowych rozwiązaniach. Musiałby on bowiem zadbać o to, aby dany system lub komponent przystosować do zapewniania poufności, integralności i rozliczalności. Te dwa ostatnie atrybuty w szczególności mogą generować tutaj pracę. W kwestii poufności współczesne systemy raczej zapewniają rozmaite formy zabezpieczeń oraz kontroli dostępu, chociaż i tak trzeba w tym zakresie wszystko sprawdzić i doszlifować. Oprócz tego wymogi prawne nakazują nie tylko zbierać pewne dodatkowe informacje (np. data pierwszego wprowadzenia, data sprzeciwu), ale też wymagają, aby system informatyczny oferował funkcjonalność tworzenia stosownych raportów.

Możliwe są jednak takie rozwiązania, które być może ograniczą do pewnego stopnia koszty czasowe i finansowe przystosowywania systemu i jego komponentów. Po pierwsze, korzystając z zapisów Rozporządzenia MSWiA z 29 kwietnia 2004 roku, możliwe jest stosowanie wielu systemów w takim układzie, w którym niektóre z delegują części obowiązków i wymogów do innych – być może lepiej przystosowanych do ich spełnienia. Jeżeli więc klient posiada już u siebie jakieś systemy, które już korzystają z tej samej bazy danych osobowych albo nawet z bazy szerszej wobec której nowy system będzie zawierał jedynie podzbiór, wówczas jest możliwość ograniczenia prac. Przykładem takiej optymalizacji może być ograniczenie prac w zakresie zarządzania użytkownikami w nowo tworzonym systemie jeżeli klient korzysta z serwera LDAP albo Active Directory (pod warunkiem, że te usługi są odpowiednio zabezpieczone). Chodzi tutaj jednak tylko o niektóre obowiązki i wymogi – w dalszym ciągu trzeba włożyć sporo dodatkowej pracy.

Drugi sposób uzyskania optymalizacji kosztów wiąże się ze świadomym porzuceniem pewnych funkcjonalności oraz maksymalnym usunięciu danych osobowych z systemu. Przykładem niech ponownie będzie baza użytkowników serwisu, która zamiast loginu stosuje adres e-mail (dosyć często spotykane rozwiązanie) – możliwe jest przechowywanie takich loginów w postaci wyniku funkcji skrótu (podobnie jak przechowywane są hasła). W takiej formie login/e-mail nie stanowi już danych osobowych. Konsekwencją tego jest jednak to, że takie funkcjonalności jak mechanizm przypominania hasła czy też mass-mailing do użytkowników serwisu albo będą musiały być zmodyfikowane (np. przypominanie hasła poprzez odpowiedź na pytanie a mass-mailing tylko w wewnętrznych systemie komunikatów), albo będą musiałby być zwyczajnie usunięte lub nie wdrożone. Być może da się tutaj uzyskać różne kompromisowe rozwiązania, które jednak musiałby wcześniej ocenić prawnik – np. rozwiązanie takie, że użytkownik chcąc odzyskać hasło wprowadza swój adres e-mail, którego hash jest porównywany z tym w bazie danych i w przypadku zgodności wprowadzony adres jest jednorazowo używany do operacji wysłania hasła (nie jest on jednak nigdzie zapisywany).