Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.

Aktualne wydanie

Polecamy

Bezpieczeństwo danych osobowych. Praktyczny przewodnik

Bezpieczeństwo danych osobowych. Praktyczny przewodnik
 

Katarzyna Ułasiuk, Michał Sztąberek

Cena: 148,00 zł

Zamów

Polecamy

Realizacja praw osób, których dane dotyczą, na podstawie rodo

Realizacja praw osób, których dane dotyczą, na podstawie rodo
 

Marlena Sakowska-Baryła, Bogdan Fischer

Cena: 128,00 zł

Zamów

Współpraca ABI z zespołami programistycznymi

05-12-2017 Autor: Piotr Siemieniak

Na ABI i przyszłych IOD spoczywa odpowiedzialność za prawidłowy przebieg procesu przetwarzania danych osobowych. Przepisy uodo i rodo gwarantują im niezależność wykonywania swojej funkcji oraz bezpośrednią podległość wyłącznie najwyższemu kierownictwu.

 

Możliwość sprawowania omawianej funkcji jest uzależniona przede wszystkim od posiadania odpowiedniej wiedzy fachowej. Zakres i poziom wymaganej wiedzy wobec ABI jest uzależniony od wielu czynników, np. sektora działalności, rodzaju, ilości, zakresu lub sposobu przetwarzania danych osobowych. Często funkcję ABI pełnią osoby, które nie posiadają wystarczającej wiedzy technicznej. W konsekwencji może to prowadzić do sytuacji, w których ABI nie będzie w stanie samodzielnie ocenić zasadności stosowanych rozwiązań technologicznych w procesie przetwarzania danych osobowych.

ABI, rozpoczynający współpracę z zespołem programistycznym, powinien posiadać na tyle szeroką wiedzę, aby zadbać o zgodność przetwarzania z przepisami o ochronie danych osobowych z punktu widzenia prawnego i teleinformatycznego.

Wybór rozwiązań technologicznych

Unijny prawodawca w art. 25 rodo wprowadza obowiązek uwzględnienia ochrony danych na etapie projektowania. Administrator danych zarówno w procesie określania sposobów przetwarzania, jak i w samym procesie przetwarzania danych osobowych musi wdrożyć właściwe środki techniczne i organizacyjne z uwzględnieniem czynników, takich jak m.in.:

  • stan wiedzy technicznej,
  • koszt wdrażania,
  • charakter,
  • zakres,
  • kontekst,
  • cele przetwarzania,
  • ryzyko naruszenia praw lub wolności osób fizycznych, o różnym prawdopodobieństwie wystąpienia i wadze zagrożenia wynikającej z przetwarzania.

Świadomy wybór odpowiednich rozwiązań technologicznych jest szczególnie istotny z punktu widzenia prawidłowości i bezpieczeństwa przetwarzania danych osobowych. Zespoły programistyczne często decydują się na skorzystanie z gotowych i zazwyczaj darmowych rozwiązań określonych problemów w postaci już opracowanych aplikacji, baz danych, bibliotek, frameworków (szkieletów rozwiązań), co jest jak najbardziej zasadne z uwagi na to, że społeczności przez wiele lat rozwoju rozwiązały już różnorodne problemy programistyczne oraz mogły wdrożyć odpowiednie mechanizmy bezpieczeństwa.

W niektórych młodych zespołach programistycznych może powstać pomysł budowy własnego frameworka. Najczęściej takie podejście nie jest dobrym pomysłem z uwagi na to, że wybierając jedno z gotowych i stale rozwijanych rozwiązań (frameworków), nie będzie potrzebne budowanie różnych mechanizmów bezpieczeństwa od podstaw, co jest oszczędnością czasu, pieniędzy i umożliwi uniknięcie wielu błędów. Przykładowo różnorodne frameworki stworzone dla różnych języków programowania (np. Django, Flask, CherryPy dla języka Python czy też Laravel, Falcon, Symfony dla języka PHP) często mogą zawierać dużo ciekawych mechanizmów bezpieczeństwa, jak ochrona przed cross-site request forgery (CSRF), ochrona przed cross-site scripting (XSS), ochrona przed SQL injection czy też domyślne ustawienia związane z hashowaniem haseł. W procesie wyboru odpowiedniego narzędzia ABI powinien mieć choćby minimalny udział związany z określeniem kryteriów wyboru danego rozwiązania technologicznego z punktu widzenia bezpieczeństwa przetwarzania danych osobowych.

ABI zawsze powinien pamiętać o tym, że nie wszystkie rozwiązania teleinformatyczne mają domyślnie włączone „bezpieczne” ustawienia.

Często zdarza się, że niektóre rozwiązania mają stały zestaw domyślnych haseł lub zezwalają na publiczną rejestrację, co może umożliwić osobom trzecim łatwy dostęp do określonych informacji. Przykładem może być narzędzie o nazwie Sentry, które służy do logowania błędów aplikacji. Posiada ono właśnie domyślnie włączoną publiczną rejestrację. Oznacza to, że jeżeli zespół nie wprowadzi odpowiednich zmian w konfiguracji, to praktycznie każdy, kto będzie znał adres instalacji oprogramowania, będzie mógł się zarejestrować i zapoznać się z nieprzeznaczonymi dla niego informacjami. Drugim ciekawym przykładem jest nierelacyjna baza danych MongoDB. Domyślnie zezwala ona na zdalne połączenie (jeżeli port bazy danych był otwarty), co prowadzi do możliwości całkowitego przejęcia bazy danych. Warto również zwrócić uwagę na to, że niektóre rozwiązania domyślnie są pozostawione w tzw. trybie debug, co może zmniejszyć wydajność tych rozwiązań oraz obniżyć poziom bezpieczeństwa.

[...]

Autor prowadzi firmę upsecure.pl, zajmującą się ochroną danych osobowych i wytwarzaniem oprogramowania oraz jest asystentem na Wydziale Prawa i Administracji Uniwersytetu Gdańskiego.

 


Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

Zapraszamy do składania zamówień na prenumeratę.


 

______________________________________________________________________________________________________________________________________

Informacje o cookies © 2017 PRESSCOM Sp. z o.o.