Upoważnienia i uprawnienia

Artykuł 37 dotąd obowiązującej ustawy o ochronie danych osobowych określał, że do przetwarzania danych mogą być dopuszczone wyłącznie osoby posiadające upoważnienie nadane przez administratora danych. Upoważnienie takie pełniło kilka istotnych funkcji – stanowiło uprawnienie (zezwolenie) do przetwarzania danych osobowych i pozwalało sprawować kontrolę nad tym, kto ma dostęp do danych i w jakim zakresie.

Forma zatrudnienia ani stosunek prawny między podmiotem a osobą upoważnianą nie miał w zasadzie znaczenia. Takie upoważnienia wydawane były najczęściej przez pracownika działu personalnego lub przez administratora bezpieczeństwa informacji na podstawie stosownego pełnomocnictwa. Patrząc z perspektywy czasu, były to nierzadko dokumenty bez rzeczywistego praktycznego znaczenia, gdyż upoważnienie stanowiło zadośćuczynienie wymaganiom ustawy, a „prawdziwe” uprawnienia do przetwarzania były nadawane odrębnie.

Oprócz wydawania upoważnień ustawa o ochronie danych osobowych nakazywała prowadzić ewidencję osób upoważnionych.

Rozporządzenie upraszcza te kwestie, ale nie wprowadza żadnych rozwiązań, które byłyby sprzeczne, zatem nie stoi nic na przeszkodzie, aby organizacja zachowała obecne procesy bez zmian. Kwestie upoważnienia do przetwarzania danych osobowych RODO reguluje w artykule 29:

Podmiot przetwarzający oraz każda osoba działająca z upoważnienia administratora lub podmiotu przetwarzającego i mająca dostęp do danych osobowych przetwarzają je wyłącznie na polecenie administratora, chyba że wymaga tego prawo Unii lub prawo państwa członkowskiego.

 

oraz w artykule 32 ust. 4:

Administrator oraz podmiot przetwarzający podejmują działania w celu zapewnienia, by każda osoba fizyczna działająca z upoważnienia administratora lub podmiotu przetwarzającego, która ma dostęp do danych osobowych, przetwarzała je wyłącznie na polecenie administratora, chyba że wymaga tego od niej prawo Unii lub prawo państwa członkowskiego.

 

W rozporządzeniu nie wspomina się o „posiadaniu” upoważnień (a więc nie ma obowiązku wydawania upoważnień), nigdzie też nie mówi się o ewidencji osób upoważnionych, natomiast podkreśla się znaczenie przetwarzania „wyłącznie na polecenie” przez osoby fizyczne „działające z upoważnienia”. Chodzi o to, aby każda upoważniona osoba (np. pracownik), która ma dostęp do danych osobowych, przetwarzała je wyłącznie zgodnie z poleceniami administratora (np. pracodawcy).

Z treści zapisów rozporządzenia jasno wynika, kto ma upoważniać pracowników podmiotu przetwarzającego (zleceniobiorcy) – jest to sam podmiot przetwarzający.

Upoważnienie nie musi być nadane na piśmie, ale mimo wszystko trzeba je dobrze udokumentować. Można włączyć je w zakres obowiązków pracownika, ewentualnie stworzyć odrębny szablon. Poniżej przedstawiono przykładowe upoważnienie do przetwarzania danych.

Upoważniam Panią do przetwarzania danych osobowych zgromadzonych w zbiorach danych posiadanych przez RODO sp. z o.o. w zakresie niezbędnym dla wykonywania obowiązków służbowych na zajmowanym stanowisku oraz odpowiadającym przydzielonym dostępom do systemów informatycznych. Niniejsze upoważnienie traci moc najpóźniej z dniem rozwiązania lub wygaśnięcia umowy o pracę.

Jeśli chodzi o wnioski o nadanie uprawnień w systemach informatycznych, to każdy wniosek jest indywidualną kwestią i jego zawartość zależy od tego, w jaki sposób przebiegają procesy nadawania uprawnień w danej organizacji.

 

Uprawnienia w systemach informatycznych

Jeśli chodzi o uprawnienia w systemach informatycznych, to wyróżnić należy kilka procesów:

  • zakładanie kont użytkowników,
  • nadawanie, zmiany i odbieranie uprawnień,
  • usuwanie (zawieszanie) kont,
  • przegląd uprawnień.

Zwykło się jeszcze uwzględniać odrębny proces związany z zarządzaniem kontami administratorów, ponieważ mają najwyższe poziomy dostępu do danych.

W zarządzaniu uprawnieniami trzeba pamiętać o kilku podstawowych zasadach:

  • Identyfikatory użytkowników muszą być unikalne i przypisane określonej osobie – to będzie gwarantować rozliczalność działań.
  • Powinno zabronić się używania „grupowych” kont lub kont wbudowanych, bo np. jeśli dostęp do konta „administrator” ma kilkanaście osób, to gdy coś się stanie, nie uda się wskazać osoby odpowiedzialnej.
  • W procesie zarządzania użytkownikami powinien brać udział dział personalny, który jest źródłem najbardziej wiarygodnych informacji o pracowniku, jego stanowisku, zakresie obowiązków, przełożonym, dacie zatrudnienia i zwolnienia.
  • przyznaniu dostępu do danego systemu powinien decydować jego tzw. właściciel biznesowy; przykładowo, żądanie nadania uprawnień do systemu kadrowego musi być zaakceptowane przez szefa działu personalnego.
  • Przegląd nadanych uprawnień do systemów informatycznych powinien zostać dokonany przez każdego właściciela biznesowego.

 

W przypadku kont administratorów proces powinien być bardziej sformalizowany. Konta administracyjne (określane mianem kont uprzywilejowanych) powinny być przyznawane tylko wtedy, kiedy jest to niezbędne. Wszystkie nadane uprzywilejowane dostępy powinny zostać udokumentowane.

Każdy uprzywilejowany dostęp powinien zostać przypisany do tego konta, na którym się pracuje. Przykładowo, jeśli administrator na co dzień posługuje się kontem kepal, to do uprawnień specjalnych powinienem mieć jeszcze jedno konto o nazwie kepal_adm.

Korzystanie z wbudowanych kont, takich jak root czy administrator, powinno zostać zabronione i jeśli się da – monitorowane. Zamiast tego należy korzystać z indywidualnych kont. To pozwoli na zachowanie rozliczalności – jeżeli np. coś zostanie zmienione, to jeśli z rejestru zdarzeń będzie widać, że akcję wykonał kepal_adm, to będzie można w stosunku do tego użytkownika wyciągnąć konsekwencje. Jeśli natomiast będzie użyte konto systemowe (np. administrator), a dostęp do tego konta miało wiele osób, to niezbyt wiele da się zrobić.

 

RBAC model

Tam, gdzie tylko to możliwe, warto stosować model kontroli dostępu opartej na rolach (ang. role based acces scontrol, RBAC). W takim modelu uprawnienia dostępu do zasobów zamiast kontom użytkowników przypisane są bezpośrednio rolom.

Główną przyczyną powstania takiego modelu jest to, że najczęściej uprawnienia, jakie są przydzielane pracownikom w organizacji, wiążą się z funkcją (rolą), jaką pełnią. Dostęp do zasobów jest regulowany poprzez przynależność do konkretnej roli. Uprawnienia, które są przydzielane danej osobie, zmieniają się znacznie częściej (z powodu np. zmiany stanowiska pracy, zakresu obowiązków itd.) niż uprawnienia, które są przydzielone danej roli. Zatem prawa dostępu do zasobów powinny głównie zależeć od funkcji, jaką pełni pracownik. Przykładem typowych ról w banku są kasjer i doradca.

 

Poziom dostępu

W zarządzaniu dostępami warto stosować zasadę wiedzy koniecznej (ang. need-to-know principle) – użytkownik powinien mieć takie dostępy, które są mu do pracy konieczne. Nie powinno nadawać się dostępów „na zapas”. Bardzo złą praktyką jest tzw. klonowanie kont, spotykane w niedojrzałych organizacjach. Polega to na tym, że nowy pracownik otrzymuje „takie same uprawnienia jak pan Sławomir”. Zazwyczaj organizacja nie ma pojęcia, jakie uprawnienia ma pan Sławomir, zakłada jednak, że skoro wykonuje swoje obowiązki, to ma wszystko, co niezbędne.  Sklonowanie uprawnień może jednak prowadzić do naruszenia bezpieczeństwa, bo może się okazać, że akurat  pan Sławomir ma dostępy do systemów, do których inni  nie powinni mieć dostępu.

W RODO mówi się, że dane osobowe muszą być adekwatne, stosowne oraz ograniczone do tego, co niezbędne do celów, w których są przetwarzane (»minimalizacja danych«). Odnosząc to do zasady wiedzy koniecznej, można by powiedzieć, że stanowi ona swojego rodzaju odzwierciedlenie koncepcji minimalizacji, z tym że nie chodzi o dane, ale o uprawnienia dostępu, które powinny być „odpowiednie, stosowne, ograniczone do tego, co niezbędne”.

 

Przegląd kont

Po pewnym czasie zmieniają się obowiązki pracowników, przestają oni wykonywać pewne zadania i dostają nowe, a wówczas okazuje się, że mają wiele niepotrzebnych uprawnień. Dlatego regularnie należy dokonywać przeglądu nadanych uprawnień, aby upewnić się, czy określone osoby mają odpowiednie uprawnienia.

Niezależnie od tego warto dokonywać też przeglądu kont pod kątem osób, które już w organizacji nie pracują – polega to na okresowym porównaniu listy osób, które już przestały pracować, z listą aktywnych kont użytkowników w systemach komputerowych. Ma to szczególne znaczenie wtedy, gdy w organizacji używa się systemów dostępnych przez Internet. Konta powinny być blokowane natychmiast, gdy umowa z pracownikiem zostaje rozwiązana. Taki okresowy przegląd jest dodatkowym narzędziem kontrolnym – pozwala sprawdzić, czy podstawowy proces działa prawidłowo i zablokować konta, których przez omyłkę, błąd czy zapomnienie nie zablokowano wcześniej.