RODO dla inżynierów: co zrobić przed majem

25 maja 2018 ogólne rozporządzenie o ochronie danych (RODO) staje się egzekwowalne, a kary są na tyle duże, że nikt go nie ignoruje. Kuszące jest zaszufladkowanie RODO jako „prawne”, ale to błąd: większość tego, czego RODO wymaga, to praca inżynierska, bo dotyczy tego, jak twoje systemy zbierają, przechowują, ujawniają i usuwają dane osobowe. Jeśli budujesz oprogramowanie, część zgodności to twoja robota. Oto pragmatyczny, nieprawniczy przewodnik po tym, co to faktycznie oznacza dla kodu — ze standardowym zastrzeżeniem, że to perspektywa inżynierska, nie porada prawna.

Zacznij od inwentaryzacji danych

Nie ochronisz, nie ujawnisz ani nie usuniesz danych osobowych, których nie potrafisz znaleźć, więc zadaniem fundamentalnym jest inwentaryzacja danych: wiedz, jakie dane osobowe trzymasz, gdzie żyją, dlaczego je masz i jak długo je trzymasz. „Dane osobowe” w RODO są szerokie — imiona, emaile, adresy IP, identyfikatory urządzeń, wszystko, co może zidentyfikować osobę — i ukrywają się w większej liczbie miejsc, niż myślisz:

• Twoje oczywiste kolumny modeli (users.email, users.name).
• Logi (logi żądań pełne IP, trackery błędów przechwytujące parametry).
• Usługi stron trzecich, do których wysłałeś dane (analityka, dostawcy maili, narzędzia wsparcia).
• Backupy, cache, indeksy wyszukiwania i ten eksport CSV, który ktoś zrobił w 2016.

Zmapuj to wszystko. Ten audyt jest nieefektowny i naprawdę odkrywczy — większość zespołów odkrywa dane osobowe w miejscach, o których zapomniała, a nie zastosujesz się do niczego innego, póki nie znasz terytorium.

Minimalizacja danych: najtańsza zgodność

Najskuteczniejsza zasada jest też najprostsza: nie zbieraj ani nie trzymaj tego, czego nie potrzebujesz. Dane, których nigdy nie zebrałeś, nie mogą wyciec, nie mogą być zażądane i nie trzeba ich usuwać. Więc zanim zbudujesz jakąkolwiek maszynerię zgodności, usuń ryzyka:

• Przestań zbierać pola, których faktycznie nie używasz.
• Ustaw polityki retencji i je egzekwuj — czyść stare rekordy, przycinaj logi po rozsądnym oknie, wygaszaj dane potrzebne tylko tymczasowo.
• Anonimizuj lub pseudonimizuj, gdzie możesz — jeśli analityka potrzebuje wzorców, nie tożsamości, zedrzyj tożsamości.

Każde pole, którego nie trzymasz, to pole, którego nie musisz chronić, ujawniać na żądanie ani usuwać. Minimalizacja zamienia dużą powierzchnię zgodności w małą za darmo.

Zgoda i podstawa prawna

RODO wymaga podstawy prawnej przetwarzania danych osobowych, a gdzie tą podstawą jest zgoda, musi być dobrowolna, konkretna i świadoma — co zabija pewne wzorce, które inżynierowie budowali bez zastanowienia:

• Żadnych wstępnie zaznaczonych pól. Zgoda musi być aktywnym opt-in, nie checkboxem, który zaznaczyłeś za nich.
• Granularna, nie zbundlowana. „Zaakceptuj wszystko, by używać strony” nie jest ważną zgodą na, powiedzmy, maile marketingowe; osobne cele potrzebują osobnych zgód.
• Wycofywalna. Wycofanie zgody musi być tak łatwe jak jej udzielenie, a musisz zapisać kiedy i jak zgoda została udzielona — więc modeluj zgodę jako dane (datowane rekordy), nie pojedynczy boolean, który nadpisujesz.

Praktycznie oznacza to model zgody w bazie ze śladem audytowym i UI pytające uczciwie, zamiast dark-patternować się do tak.

Prawa osoby, której dane dotyczą: dostęp i usunięcie

Dwa prawa mają bezpośrednie, konkretne konsekwencje inżynierskie i musisz umieć je spełnić na żądanie:

• Prawo dostępu (przenoszalność danych). Osoba może poprosić o wszystkie dane osobowe, które o niej trzymasz, w użytecznym formacie. Potrzebujesz sposobu na zebranie wszystkiego o jednym użytkowniku przez wszystkie modele i usługi oraz wyeksportowanie tego — co inwentaryzacja umożliwia. Zbuduj to jako prawdziwą funkcję (zadanie eksportu), nie gorączkową ręczną sesję SQL przy każdym żądaniu.
• Prawo do usunięcia („prawo do bycia zapomnianym”). Osoba może poprosić o usunięcie swoich danych osobowych i musisz umieć to zrobić — przez bazę, logi, backupy (w granicach rozsądku) i procesorów stron trzecich. To trudniejsze, niż brzmi: naiwne user.destroy może naruszyć klucze obce, osierocić rekordy albo zepsuć zapisy finansowe, które jesteś prawnie zobowiązany zachować. Wzorcem jest zwykle anonimizacja zamiast twardego usunięcia, gdzie musisz zachować rekord (zamówienie musi przetrwać dla prawa podatkowego, ale może mieć wyczyszczone pola osobowe), i propagacja usunięcia do każdej usługi, do której przekazałeś dane.

Projektuj oba jako świadome operacje na modelu danych, przetestowane, by gdy nadejdzie żądanie, uruchomić znany proces zamiast improwizować.

Prywatność i bezpieczeństwo od projektu

RODO oczekuje, że prywatność będzie wbudowana, nie doczepiona, a kilka praktyk inżynierskich z tego wynika:

• Szyfruj dane osobowe w tranzycie (TLS wszędzie) i wrażliwe dane w spoczynku.
• Ogranicz dostęp — najmniejsze uprawnienia co do tego, kto i co może czytać dane osobowe, w tym narzędzia wewnętrzne i personel.
• Powiadomienie o naruszeniu. RODO wymaga powiadomienia organów o naruszeniu w ciągu 72 godzin, co oznacza, że potrzebujesz monitoringu i logowania, by w ogóle wykryć naruszenie — kolejny powód, dla którego praca nad obserwowalnością ma znaczenie.
• Sprawdzaj swoich procesorów. Każda strona trzecia, do której wysyłasz dane osobowe, to twoja odpowiedzialność; potrzebujesz z nimi umów i wiedzy, że oni też są zgodni.

Werdykt

RODO to nie prawna formalność, którą możesz oddelegować — to zbiór wymagań żyjących w twoim modelu danych, politykach retencji, przepływach zgody i zdolności do eksportu oraz usunięcia danych osoby na żądanie. Praca, po kolei: zinwentaryzuj dane osobowe, które trzymasz (masz ich więcej, w większej liczbie miejsc, niż myślisz); minimalizuj bezwzględnie, bo najtańsze dane do ochrony to dane, których nigdy nie zachowałeś; modeluj zgodę uczciwie ze śladem audytowym; i zbuduj dostęp oraz usunięcie jako prawdziwe, przetestowane funkcje — anonimizując tam, gdzie musisz prawnie zachować rekordy. Traktuj prywatność i bezpieczeństwo jako ograniczenia projektu, nie refleksje po fakcie. Zrobione porządnie, RODO jest mniej ciężarem, a bardziej czynnikiem wymuszającym higienę danych, którą i tak powinieneś był mieć — a majowy deadline to po prostu moment, w którym „powinieneś” stało się „musisz”.