Ochrona danych i rozwój oprogramowania

Twórcy oprogramowania często spotykają się z przeszkodami związanymi z ochroną danych. Szybko powstaje tu wrażenie, że ochrona danych i rozwój oprogramowania to dwa niekompatybilne tematy.

Dlatego poniżej przedstawiamy krótko punkty orientacyjne dla twórców oprogramowania.

Privacy by Design (Art. 25 I GDPR)

Ograniczenie przechowywania, minimalizacja danych, poufność i integralność to tylko najbardziej oczywiste zasady ochrony danych, które można zintegrować retrospektywnie tylko przy dużym wysiłku. Dlatego kluczem jest działanie prewencyjne. Wysoki standard ochrony danych powinien być już ustalony w architekturze aplikacji IT, aby nie wykraczać poza ramy prawne przy nieskończonych możliwościach technicznych.

Uwzględnienie wszystkich aspektów ochrony danych na wczesnym etapie rozwoju pozwala również zaoszczędzić ogromne kwoty kosztów, które zostałyby poniesione w przypadku konieczności przerobienia gotowego, naruszającego ochronę danych oprogramowania.

Jeżeli oprogramowanie jest opracowane w taki sposób, że użytkownik może wyraźnie zobaczyć, jakie dane są gromadzone i że odbywa się to w sposób przejrzysty, minimalizowany i w określonym celu, to nie tylko zachowuje to ważne zasady ochrony danych (przejrzystość art. 5 I lit. a DSGVO; minimalizacja danych art. 5 I lit. c DSGVO; ograniczenie celu art. 5 I lit. b DSGVO), ale także zwiększa zaufanie użytkownika do oprogramowania. W końcu to znowu stanowi wartość ekonomiczną.

W odniesieniu do przejrzystości należy zauważyć, że wszystkie przepływy danych muszą być przedstawione osobie, której dane dotyczą. Obejmuje to w szczególności przepływy danych do stron trzecich, o których informacje muszą być przedstawione w każdym przypadku (art. 13 GDPR).

Oznacza to, że celem tworzenia oprogramowania powinno być zawsze unikanie gromadzenia danych osobowych w jak największym stopniu, a w przypadku ich gromadzenia - gromadzenie tylko tych danych, które są rzeczywiście niezbędne do realizacji celu. Decyzje w tym zakresie należą zazwyczaj do obowiązków poszczególnych interesariuszy i dlatego muszą być z nimi szczegółowo omówione.

Bezpieczeństwo danych od ich gromadzenia do usunięcia

Bezpieczeństwo danych musi być również zagwarantowane przez cały "cykl życia oprogramowania". Dane muszą być chronione od momentu pobrania, podczas przechowywania i aż do usunięcia. Wyrażone są tu zasady poufności i integralności (art. 5 I lit. f DSGVO).

Z jednej strony należy zapobiegać nieuprawnionemu dostępowi do danych. Wybór odpowiedniego standardu szyfrowania jest równie istotny jak wdrożenie kontroli dostępu. W celu zapewnienia dostępności danych należy również rozważyć tworzenie kopii zapasowych i zapewnienie odporności.

Obowiązek zapewnienia ochrony danych za pomocą takich środków dotyczy zazwyczaj samego twórcy oprogramowania, którego zobowiązania umowne dotyczące tworzenia oprogramowania dla klienta (który jest zazwyczaj stroną odpowiedzialną) są tutaj naruszone.

Prawidłowe usunięcie

W przypadku ustania celu przetwarzania, ale najpóźniej w momencie upływu okresów przechowywania, odpowiednie dane muszą zostać natychmiast usunięte. W przeciwnym razie organy ochrony danych mogą nałożyć wysokie grzywny.

Dlatego również usuwanie danych powinno być uwzględnione na wczesnym etapie planowania oprogramowania. Dobrym pomysłem jest tutaj zautomatyzowany system usuwania danych.

Anonimizacja jako alternatywa dla usuwania danych

Jeżeli usunięcie odpowiednich danych nie jest technicznie możliwe lub uzasadnione, dane te mogą zostać również zanonimizowane. Należy to zrobić w taki sposób, aby nie było już możliwe ustalenie odniesienia osobowego. Anonimizacja jest zazwyczaj łatwiejsza do przeprowadzenia niż usunięcie ze względu na złożoność danych i ich prezentacji.

Należy zauważyć, że pseudonimizacja nie jest do tego wystarczająca. Pseudonimizacja oznacza, że dane nie mają już odniesienia do osoby bez dodania dodatkowych informacji, ale można to ustalić dzięki dodatkowym informacjom. Pseudonimizacja istnieje na przykład wtedy, gdy dane dotyczące danej osoby są przechowywane z indywidualnym numerem identyfikacyjnym (np. numerem klienta) zamiast w powiązaniu z nazwiskiem tej osoby. Nie spełnia to wymogów obowiązku usunięcia, ale rzeczywista anonimizacja tak.

Privacy by Default (Art. 25 II DSGVO)

Jeżeli istnieją podstawowe ramy zgodnie z zasadą "Prywatności w fazie projektowania", należy również uwzględnić zasadę "Prywatności w fazie domyślnej" (tj. ochrony danych poprzez przyjazne dla ochrony danych ustawienia domyślne). Takie ustawienia domyślne mogą zapewnić, że przetwarzane są tylko te dane, które są niezbędne do określonego celu. Ustawienia domyślne muszą zatem zawsze reprezentować najmniejszy możliwy zakres przetwarzania.

Przykłady

W systemie CRM (Customer Relationship Management) różne role użytkowników muszą być zdefiniowane poprzez szczegółowy system uprawnień, tak aby każdy użytkownik miał dostęp tylko do danych wymaganych dla jego obszaru pracy.

Jeśli chodzi o wysyłanie newsletterów lub podobnych, użytkownik musi mieć możliwość zarejestrowania się w tym celu poprzez opcję opt-in. Jeśli użytkownik musi aktywnie dezaktywować tę opcję (opt-out), nie jest to zgodne z ochroną danych.

Wskazówki dotyczące praktyki

Polegaj na tym, co zostało wypróbowane i przetestowane: Ogólnie rozpowszechnione komponenty i frameworki są zwykle bardziej odporne na zewnętrzne kontrole niż te mniej rozpowszechnione. Nie powinno to jednak samo w sobie wykluczać stosowania własnych, porównywalnych komponentów. Szczególnie w takich kategoriach jak szyfrowanie i inne komponenty bezpieczeństwa należy jednak stosować ogólnie obowiązujące standardy.

Komunikacja jest ważna! Jako twórca oprogramowania ważne jest, aby w rozmowach z architektami, interesariuszami i w razie potrzeby innymi twórcami oprogramowania wcześnie wskazywać na wymogi ochrony danych, tak aby były one brane pod uwagę i planowane na wczesnym etapie. Pozwala to zaoszczędzić wiele wysiłku i kosztów oraz ułatwia interakcję między ochroną danych a tworzeniem oprogramowania.