Czy planujesz stworzyć aplikację? Dowiedz się, jak powinien wyglądać proces rozwoju aplikacji zgodnie z wytycznymi RODO z bardziej pragmatycznego punktu widzenia.

Z artykułu dowiesz się:

• o współpracy między prawnikami, audytorami bezpieczeństwa i architektami systemu;
• jaką aplikację można uznać za zgodną z RODO;
• o prawach, które mają zagwarantowane użytkownicy w ramach Rozporządzenia;
• w jaki sposób aplikacje mogą zapewniać Prawo do Zapomnienia i Prawo do Sprzeciwu;
• o najczęstszych błędach podczas tworzenia oprogramowania;
• czym są zasady Privacy by Design i Privacy by Default;
• o najczęstszych błędach popełnianych w momencie przetwarzania danych.

W maju 2018 r. wszyscy mówili o przygotowaniach firm i organizacji do przestrzegania Rozporządzenia o Ochronie Danych Osobowych, RODO - nowej unijnej ustawy o ochronie danych. Celem tego artykułu nie jest straszenie przed ewentualnymi skutkami niezgodności z Rozporządzeniem, lecz pokazanie z bardziej pragmatycznego punktu widzenia, jak aplikacja powinna być rozwijana z uwzględnieniem wytycznych RODO.

5 zasad tworzenia aplikacji zgodnej z RODO

Poniższe wskazówki powinny być wzięte pod uwagę w momencie planowania nowej aplikacji lub dostosowywania już istniejącej do RODO i do standardów związanych z cyberbezpieczeństwem.

1. Wykonujmy zadania, w których jesteśmy ekspertami

Zdarza się, że ludzie zapominają, że prawnicy nie są programistami i na odwrót. Nie wystarczy wynająć kancelarię prawną lub prawnika, który sprawdzi Ogólne Warunki Świadczenia Usług, aby aplikacja była zgodna z zasadami RODO. W całym procesie tworzenia aplikacji zgodnej z Rozporządzeniem potrzebny jest programista, a dla niego wszystko stanowi dane. Programiści nie zwracają wystarczającej uwagi na rodzaj informacji, poziom ich poufności lub wrażliwości. Warto pamiętać, że istnieją specjalne kategorie danych, takie jak te z Art. 9, mówiące o pochodzeniu rasowym lub etnicznym, poglądach politycznych, przekonaniach religijnych lub filozoficznych, które powinny podlegać zwiększonej ochronie.

Z drugiej strony, prawnicy nie mają pojęcia o architekturze systemu, podziale odpowiedzialności (z ang. separation of concerns), wzorcach projektowych (z ang. design patterns) itd., czyli o rzeczach, którymi programiści zajmują się na co dzień. To, co mogą zrobić prawnicy, to np.: przygotować procedury i polityki bezpieczeństwa, jednak zawsze pozostaje kwestia sprawdzenia, czy architektura aplikacji jest w stanie prawidłowo je obsłużyć i czy wszystkie przepisy dotyczące RODO zostaną spełnione podczas korzystania z aplikacji. Należy unikać takich sytuacji, w których system nie aktualizuje zgód użytkowników, gdy zaistnieje ich modyfikacja system, lub nie monitoruje, z którymi podmiotami dochodzi do wymiany danych.

Podsumowując, im prędzej prawnicy i programiści będą współdziałać ze sobą w procesie tworzenia aplikacji, tym łatwiej stworzyć im będzie mocną drużynę, która konsultuje każdy problem i dzieli się wiedzą z zakresu prawa oraz technologii.

2. Zasada Privacy by Design zachowana od samego poczatku tworzenia aplikacji

Privacy by Design z pewnością nie może być postrzegana w kategoriach dodatku czy wtyczki do produktu cyfrowego. Zgodnie z Art. 25 RODO, aplikacje powinny być tworzone zgodnie z zasadą Privacy by Design, czyli poszanowania prywatności od samego początku. Jest to sposób programowania aplikacji, w którym uwzględnia się aspekt bezpieczeństwa już na etapie procesu twórczego, designu, tworzenia pierwszych makiet lub prototypów. Możesz zastosować szyfrowanie danych i posiadanej bazy, przechowywać ją w zabezpieczonej infrastrukturze, wprowadzić Utwardzenie systemu (z ang. system hardening). Jednak wszystkie Twoje wysiłki są bezużyteczne, jeśli hakerzy wciąż mogą przeniknąć do aplikacji, ponieważ posiadany REST API ma podatność Server Side Request Forgery (SSRF), czyl rodzaj błędu bezpieczeństwa, który pozwala na manipulację działaniami serwera. W takiej sytuacji oprogramowanie staje się najsłabszym ogniwem; naraża firmę na utratę reputacji i zaufanie klientów.

Gdy architekci systemu projektują architekturę aplikacji, powinni wziąć pod uwagę mechanizmy bezpieczeństwa w formie pseudonimizacji i anonimizacji lub podział danych pomiędzy wiele miejsc przechowywania. Dzięki temu zmniejsza się możliwość przeprowadzenia infiltracji zgromadzonych informacji. Nie tylko dane, ale także bezpieczeństwo aplikacji mogą zostać znacznie polepszone, kiedy zostaną wdrożone kolejne rozwiązania z zakresu cyberbezpieczeństwa, np.:

• Uwierzytelnianie Wielopoziomowe (z ang. Multi-factor Authentication);
• Zarządzanie Tożsamością i Dostępem (z ang. Identity and Access Management);
• Pojedyncze logowanie (z ang. Single Sign On);
• Tożsamość federacyjna (z ang. Federated Identity).

Ważne jest również, aby tworzona aplikacja została dokładnie zweryfikowana przez specjalistę w postaci audytora bezpieczeństwa lub pentestera. Mogą oni sprawdzić, czy system spełnia istotne standardy bezpieczeństwa: OWASP, ASVS, OSSTMM, NIST. W ramach audytu bezpieczeństwa powstają rekomendacje oraz zalecenia, które należy wdrożyć jak najszybciej dla zachowania wysokiego poziomu ochrony, a następnie ponownie skontrolować aplikację.

3. Wygoda programisty i zgodność z zasadą Privacy by Default

Inna zasada, o której mowa w Art. 25 RODO to Privacy by Default. Jest to nic innego jak tworzenie aplikacji, które od samego początku zakładają domyślne ustawienia prywatności użytkowników i przetwarzają tylko te dane osobowe, które są niezbędne do realizacji określonego celu (np. wykonania usługi, dokonania zakupu towaru).

Programiści bardzo często używają takich wygodnych dla ich pracy rozwiązań, jak np. Mapowanie obiektowo-relacyjne (z ang. Object-Relational Mapping), które skutecznie upraszcza proces przesyłania informacji z bazy danych do aplikacji. Zdarza się, że omawiane rozwiązanie pobiera wszystkie informacje z powiązanych tabel, a przez to programista załadowuje cały zbiór uzyskanych informacji o użytkowniku, zamiast pojedynczej wyodrębnionej danej. Informacje te obejmują: imię, nazwisko, datę urodzenia, numery telefonów, adresy. Czasem są to dane wrażliwe, takie jak informacje biometryczne lub związane z orientacją seksualną. W następnym kroku programista przesyła informacje do systemu, z którym muszą być one zintegrowane. Dzięki temu możliwe jest np. generowanie raportów lub przetwarzanie statystyk. Programiści zawsze podkreślają, że lepszą sytuacją jest ta, gdy zostaje przesłane do systemu zbyt wiele danych, niż gdy jest ich za mało.

W takim przypadku deweloper powinien - dla celów biznesowych i ochrony danych - uwzględnić wymagania dotyczące domyślnej prywatności i zasadę Privacy by Default. Aby to się stało, powinni dodać kilka linijek kodu, który pozwala na jednoznaczne określenie, jakie dane są wymagane do przeprowadzenia procesu w ramach aplikacji (np. dokonania zakupu). Uniknięcie zdarzeń związanych z nadużyciem danych jest również możliwe dzięki zastosowaniu mechanizmu projekcyjnego dostępnego w każdym przyzwoitym narzędziu mapowania obiektowego. Można również zastosować widoki z bazy danych, które mogą zmusić programistów do wyodrębnienia podzbioru informacji koniecznego do przetworzenia.

4. Międzykanałowe zachowania użytkowników, które mnożą trudności

Dynamicznie zmieniające się trendy w marketingu powodują, że zachowanie zgodności aplikacji z RODO staje się coraz trudniejsze. Każdego dnia użytkownicy korzystają z wielu aplikacji równocześnie i za pośrednictwem różnych urządzeń przenośnych (takich jak laptop, tablet, smartfon, smartwatch, telewizor). Najlepszym przykładem firmy podążającej za trendami jest Google, która kompleksowo reaguje na potrzeby swoich klientów i oferuje im Gmail, Kalendarz, Dysk, filmy i TV oraz wiele innych rozwiązań dostępnych na różnych platformach. Użytkownicy aplikacji mają różne nawyki i zachowania, a firmy naprawdę chcą pozostać blisko nich w czasie „podróży klienta” (z ang. Customer Journey), bez względu na urządzenia, z których korzystają. W Marketingu Technologicznym zjawisko, w którym firma jest obecna w każdej przestrzeni konsumenckiej - w trybie online lub offline - nazywa się Omnichannel.

Wyobraźmy sobie sytuację, w której użytkownicy zarejestrowali się i założyli konta w różnych aplikacjach. Aplikacje często mają różne zasady ochrony prywatności oraz bazują na innych Ogólnych Warunkach Świadczenia Usług. Wspomniane wcześniej Warunki mogą mieć różne wersje i podlegać licznym zmianom w czasie. Nigdy nie masz pewności, jacy użytkownicy zarejestrowali się i w jakich aplikacjach oraz na co wyrazili zgodę. Jak można się domyślać, wszystkie informacje są ze sobą wymieszane, a przed właścicielem aplikacji stoi wyzwanie, aby dowiedzieć się, co może zrobić z tymi danymi, a czego nie może (zwłaszcza w kwestii przetwarzania danych w celu świadczenia usług lub profilowania). Ponadto każda aplikacja może przetwarzać dane w nieco innych celach, np. YouTube prowadzi proces profilowania, a następnie poleca swoim użytkownikom filmy, które mogą być dla nich interesujące. Profilowanie bazuje na historii dokonanych wyborów, np.: ulubionych kategoriach lub długości filmów. Zatem nie chodzi tylko o gromadzenie danych, ale także o ich generowanie i tworzenie dodatkowej „wiedzy” o użytkownikach.

Aby zwizualizować wyzwanie stojące przed właścicielami aplikacji, wyobraźmy sobie zdarzenie, w którym prowadzisz usługi podobne do tych oferowanych przez serwis YouTube, a jeden z Twoich użytkowników nagle wykorzystuje Prawo do Sprzeciwu. Co to oznacza dla Ciebie i Twojego biznesu? Prawo do Sprzeciwu stanowi ważną część Rozporządzenia RODO; zabrania Ci ono przetwarzania niektórych informacji, które zostały Ci wcześniej przekazane, np. do celów marketingowych czy reklamowych. W tej sytuacji absolutną koniecznością jest weryfikacja, które aplikacje wykorzystują te informacje i w jaki sposób, a następnie ograniczyć proces przetwarzania lub całkowicie go zatrzymać.

To brzmi jak zadanie, którego nie da się zrobić w sekundę, jednak wszystko staje się całkiem proste, gdy posiadasz centralny system zarządzania zgodami użytkowników. W takim systemie można przechowywać udzielone zgody użytkowników i wyrażone sprzeciwy w formie historii. To sprawia, że zanim podejmiesz działania związane z przetwarzaniem danych osobowych, w pierwszej kolejności będzie można przeanalizować w systemie stan zgody użytkownika. W ten sposób można uniknąć chaosu informacyjnego oraz kar nakładanych w ramach RODO za lekceważenie Prawa do Sprzeciwu.

5. Nie tak łatwo być zapomnianym

Jest jeszcze jedno ważne Prawo, które zostało włączone do Rozporządzenia. W Art. 17. RODO zostało wprowadzone Prawo do bycia zapomnianym, dzięki któremu użytkownik może zmusić Cię do usunięcia wszystkich danych osobowych z systemu. Wówczas działania deweloperów, w których używają loginów/e-maili jako identyfikatorów, zaczynają być problematyczne, bowiem można je uznać za dane osobowe. Wyobraźmy sobie częstą sytuację, w której platforma e-commerce, aby mogła poprawnie funkcjonować, musi przechowywać informacje związane z historią transakcji. Dane przechowywane są w bazie danych w postaci zestawów zawierających, np.: e-mail użytkownika oraz szczegóły dokonanej transakcji (np. datę, cenę, listę zakupionych produktów/usług).

Więc w sytuacji, gdy użytkownik chce zastosować Prawo do bycia zapomnianym, właściciel platformy jest zmuszony usunąć wszelkie dane, nawet jeżeli są one aktywnie używane przez sklep e-commerce (np. adres e-mail użytkownika) i niewskazane jest ich całkowite pozbycie się. Historia transakcji zakupowej jest tylko jednym z wielu przypadków, w których stosowane są dane osobowe. Innymi przykładami są np. numery telefonów wykorzystywane do masowych powiadomień SMS, listy adresowe, systemy służące do przechowywania informacji o dacie urodzenia klienta (aby pamiętać, kiedy należy mu wysłać np. kartkę urodzinową). Jako przykład, w Polsce miało miejsce zdarzenie, w którym kobieta nie chciała, aby jej dane osobowe były przetwarzane przez bank, lecz mimo to dostała od niego kartkę bożonarodzeniową. Jak można się domyślić, bank został ukarany za naruszenie bezpieczeństwa danych. Jeśli w sposób nieodpowiedzialny i bez zgody podmiotu używasz danych osobowych, w pewnym momencie możesz znaleźć się w trudnej sytuacji i narazić swój biznes na utratę reputacji lub kary finansowe.

Najlepszą rzeczą, jaką można zrobić w tej sytuacji, jest przechowywanie wszystkich przekazanych danych osobowych w jednym systemie, a następnie zmuszenie innych powiązanych systemów do używania losowo wygenerowanych pseudonimów. Dzięki temu, gdy użytkownik poprosi Cię o usunięcie danych osobowych, wystarczy, że usuniesz je z jednego miejsca, a w innych systemach pozostawisz je w formie pseudonimów niemożliwych do zidentyfikowania. Ważne jest zagwarantowanie spójności podczas realizacji tego procesu oraz, aby system zawierający dane osobowe był wysoce bezpieczny. Aby tak się stało, system powinien zostać zweryfikowany zarówno pod kątem oprogramowania, jak i infrastruktury; posiadać różne miejsca zapisywania informacji; stosować szyfrowanie, pseudonimizację i anonimizację.

Stworzenie aplikacji zgodnej z RODO (mobile, web, server-side) nie musi być skomplikowane. Wszystko zależy od podejścia do jego rozwoju na wczesnym etapie (późniejsze modyfikacje nie należą do najtańszych). Współpraca pomiędzy architektami systemów i audytorami bezpieczeństwa oraz prawnikami jest jak najbardziej wskazana, aby uzyskać najlepsze wyniki oraz zapewnić bezproblemowy przebieg całego procesu rozwoju aplikacji.