RODO a aplikacje: szyfrowanie, anominizacja…

Szyfrowanie, hashowanie, anonimizacja… RODO straszy programistów i właścicieli stron tymi groźnymi pojęciami, w tym wpisie wyjaśniam, na czym one polegają.

Szyfrowanie

Szyfrowanie to działanie polegające na zamianie informacji (ciągu znaków) na inny, niezrozumiały dla osoby postronnej ciąg znaków tak, żeby osoba uprawniona mogła jednak go odczytać. Owo „uprawnienie” najczęściej wiąże się z posiadaniem odpowiedniego klucza, niezbędnego do zdekodowania informacji utajnionej. Możemy mówić o szyfrowaniu symetrycznym i niesymetrycznym.

Szyfrowanie symetryczne zakłada, że istnieje ten sam klucz szyfrujący, który służy do zaszyfrowania i odszyfrowania informacji. Przykładem takiego szyfrowania, które możesz wdrożyć na swojej stronie lub w aplikacji, jest szyfrowanie mechanizmem AES, wspieranym natywnie przez PHP oraz MySql. Przepisy nie nakazują Ci bezwzględnie szyfrowania danych w bazie, ponieważ o stosowanych zabezpieczeniach administrator decyduje indywidualnie. Uważam, że w większości wypadków dobrą praktyką jest jednak szyfrowanie danych osobowych w Twojej bazie, ponieważ w razie, gdyby dostała się w niepowołane ręce, nie będzie mogła być łatwo wykorzystana. Jako twórca strony lub aplikacji dane możesz szyfrować w warstwie aplikacji albo w warstwie bazodanowej.

Szyfrowanie w warstwie aplikacji oznacza, że informacja zostaje zaszyfrowana podczas wykonywania kodu PHP i w postaci zaszyfrowanej trafia do serwera bazodanowego. Może to być korzystne z punktu widzenia poufności danych, ponieważ jeśli serwer bazodanowy jest „oddalony” od serwera www, na którym wykonujesz kod PHP, to podczas transmisji dane będą zaszyfrowane.

Drugim plusem takiego podejścia jest to, że zbiór mechanizmów szyfrujących dostępnych łatwo w PHP jest większy niż w MySql, a co więcej – możesz też prosto implementować całkowicie autorskie metody, nie przejmując się tym, czy MySql je wspiera – po prostu prześlesz do bazy zaszyfrowany ciąg znaków.

Główną wadą jest wydajność, zwłaszcza podczas odczytywania i selekcji informacji z bazy. Nie możesz prosto stosować komend Sql do wyjęcia rekordów zawierających jakiś ciąg znaków. Musisz najpierw wczytać i odszyfrować wszystkie rekordy, a następnie wśród nich poszukiwać odpowiedniej wartości, stosując możliwości języka PHP.

Szyfrowanie niesymetryczne polega na tym, że stosuje się parę kluczy. Klucz służący do szyfrowania informacji jest inny, niż potrzebny do ich odczytania. To podejście jest wykorzystywane w tzw. infrastrukturze klucza publicznego (PKI). Występuje tam klucz prywatny oraz klucz publiczny. Klucz prywatny jest znany wyłączenie nadawcy wiadomości. Klucza tego nie da się łatwo odtworzyć dysponując kluczem publicznym. Danym kluczem publicznym da się odczytać wyłącznie wiadomość zaszyfrowaną pasującym kluczem prywatnym i odwrotnie. Taki zestaw kluczy „pasuje” wyłącznie do siebie nawzajem. W ten – asymetryczny sposób – działają np. certyfikaty SSL, chroniące strony i zapewniające szyfrowanie komunikacji między serwerem i przeglądarką użytkownika. W takim wypadku klucz prywatny jest zainstalowany na serwerze.

W obecnych czasach stosowanie certyfikatów SSL wydaje się absolutną koniecznością, zwłaszcza, że cena certyfikatów jest w obecnych czasach bardzo niska, a czasem są one dostępne wręcz bezpłatnie. SSL to konieczne zabezpieczenie każdej strony lub aplikacji internetowej, przetwarzającej dane osobowe. Pamiętaj jednak, że certyfikat SSL chroni transmisję danych. Certyfikat nie chroni natomiast przed np. skopiowaniem bazy danych z serwera przez osobę nieuprawnioną, np. gdyby weszła w posiadanie hasła do bazy, bo pechowo zapisałeś je w widocznym miejscu na żółtej karteczce 😉 Dlatego polecam Ci przemyślenie opisanego powyżej szyfrowania symetrycznego w warstwie aplikacji lub samej bazy.

Hashowanie

Funkcja hashująca to funkcja, która dowolny ciąg znaków zamienia na inny ciąg znaków o z góry zadanej, stałej długości, w taki sposób, że nawet minimalna zmiana w źródłowym ciągu znaków powoduje dużą zmianę w wyniku tej funkcji. Jest ona w zasadzie – nieodwracalna.

Dla jednego z najbardziej rozpowszechnionych algorytmów hashowania md5 są to zawsze 32 znaki, dla sha1 – 40 znaków. Mając wynik działania tej funkcji, czyli tzw. hash, nie sposób powiedzieć, jaki był pierwotny ciąg znaków, na podstawie którego hash został obliczony. Nie ma tu żadnego „klucza”, który pozwoli łatwo odwrócić ten proces i odczytać pierwotną informację.

Nie jest to zatem metoda zaprojektowana do odczytania informacji. Ważne jednak, że pomijając bardzo niewielkie ryzyko tzw. kolizji, każda informacja ma swoje odzwierciedlenie w unikatowym skrócie, nazywanym hashem. Oznacza to, że można z prawdopodobieństwem graniczącym z pewnością potwierdzić, że dany hash został obliczony na konkretnej informacji. Mając tę informację możemy potwierdzić, czy posiadany skrót był obliczony właśnie z niej. Długość informacji nie ma znaczenia – obojętnie, czy hashujemy kilkuliterowe nazwisko, czy cały rozdział „Pana Tadeusza” – zawsze uzyskujemy ciąg o skończonej i od razu znanej, stałej długości. Łatwo jest zatem projektować w bazie pole, przechowujące taki hash – będzie to zazwyczaj pole o stałej długości znaków, np. typu char(128) dla ciągu 128 znakowego.

Hashowanie jest działaniem jednostronnym. Hasła w dobrze projektowanych systemach są właśnie hashowane, a nie szyfrowane. W bazie po stronie serwera nie zapisujemy Twojego hasła – zapisujemy jedynie jego hash (odcisk, skrót). W ten sposób gdyby baza wpadła w niepowołane ręce – nie da się z niej, co do zasady, odzyskać haseł.

Być może niepokoi Cię w tym miejscu sformułowanie „co do zasady”. Wynika ono stąd, że mając informację jawną – np. jawnie podane hasło, a także informację zahashowaną, można je porównać aby potwierdzić albo zaprzeczyć, że dany hash powstał na bazie danej informacji. Można zatem wyobrazić sobie, że podstawiamy kolejne słowa i sprawdzamy, czy hash obliczony na nich zgadza się z tym w bazie. W ten sposób, jeśli hasło jest trywialne, dysponując odpowiednio dużą mocą obliczeniową, można „odwrócić” taki proces i poznać hasło. Nie jest to dosłownie „odwracanie”, tylko raczej zgadywanie poprzez kolejne podstawienia, wymaga zatem znacznej mocy obliczeniowej. Wiedz jednak, że dla krótkich i trywialnych haseł oraz popularnych metod hashowania istnieją tablice, które zostały już „przeliczone” – przy ich pomocy można dość szybko odgadnąć hasło, jeśli jest krótkie albo trywialne. Istnieją doniesienia, że metoda MD5, przy dzisiejszej mocy obliczeniowej zwykłych komputerów, pozwala na odgadywanie haseł dających określony hash – w ciągu zaledwie kilku minut.

Solenie

Polega na dodawaniu do hashowanego ciągu znaków z góry znanego, jawnego ciągu. Na przykład do hashowanego ciągu dokleja się inny, znany ciąg, powiedzmy „RODO-H88”, a hashuje się cały wynik. Jest on istotnie różny niż wynik hashowania pierwotnej informacji.

Najłatwiej wyjaśnić to na przykładzie. Masz proste hasło, np. „stolik”. Takie hasło łatwo złamać metodą słownikową, obliczając hash na kolejnych słowach ze słownika i sprawdzając, czy się zgadza z Twoim hashem. Wynik hasha md5 na tym słowie to 8e38a1fa88ccb0649b1032cad66f8d84. Włamywacze do systemów informatycznych mają ogromne, przeliczone już tablice z takimi właśnie słowami i odpowiadającymi im hashami, co pozwala im szybko identyfikować brzmienie prostego hasła. Po sklejeniu ciągu z solą otrzymasz ciąg: „stolikRODO-H88”. Hash md5 z takiego ciągu brzmi 5e697a4faacab99233cbb676dc4cdead – całkowicie inaczej! Jednocześnie, nie da się go „zgadnąć” podstawiając metodą słownikową, bo takie słowo nie występuje w żadnym słowniku. Kiedy użytkownik wprowadza hasło logując się do systemu, wpisuje tylko „stolik”, a aplikacja po swojej stronie dokleja sól – w tym wypadku „RODO-H88”, dzieje się to poza użytkownikiem. Aplikacja znając odpowiednią sól skleją ją z hasłem, oblicza hash i porównuje z zapisanym w bazie.

Widzisz teraz, dlaczego trywialne hasła są tak podatne na złamanie. Solenie poprawia nieco sytuację, ale jako użytkownik nigdy nie masz pewności, czy i jakie solenie stosuje operator systemu, do którego się logujesz. Dobre hasło powinno być długie i nietrywialne, a przed zapisaniem go do bazy – jeśli to Ty jesteś twórcą strony – pamiętaj o „soleniu”. Zdecydowanie polecam takie podejście, jeśli chcesz korzystać z dowolnej metody hashowania.

Anonimizacja

Anonimizacja danych osobowych polega na tym, że w zestawie danych, które zawierają dane osobowe, zostają one bezpowrotnie zamazane. Celowo używam słowa „zamazane” – chodzi o to, że nie musimy usuwać wszystkich informacji, a jedynie te, które umożliwiają łączenie danych z konkretną osobą.

Przykładowo, jeśli prowadzisz statystykę dotyczącą liczby opublikowanych postów danego autora, to posty wciąż możesz liczyć, ale nazwisko autora powinno zostać usunięte lub zastąpione losowym ciągiem znaków. Stosowanie szyfrowania nie jest anonimizacją, ponieważ posiadając klucz wciąż można je odczytać. Anonimizacja oznacza wykonanie jednokierunkowej funkcji na danych. Może to być zastąpienie ich pustym ciągiem znaków albo ciągiem losowym.

Pseudonimizacja

Polega na tym, że w danym zbiorze są przechowywane jedynie identyfikatory, które osobom postronnym, w razie uzyskania dostępu do zbioru, nic nie powiedzą o danych osobowych. Administrator danych posiada jednak możliwość dopasowania każdego takiego identyfikatora do konkretnej osoby fizycznej.

Jeśli projektowałeś kiedykolwiek bazę danych to wiesz, że często stosuje się podobne podejście w projektowaniu tabel. Nazwisko nie musi być powtórzone w każdej tabeli, wystarczy, że będzie w jednej, inne zawierają tylko odpowiedni identyfikator rekordu. Idąc tym tropem możemy wyobrazić sobie podobny mechanizm działający w oparciu o całe aplikacje – aplikacja może przetwarzać dane posługując się wyłącznie identyfikatorem, przy pomocy którego „sama”, bez dodatkowych informacji od Administratora Danych, nie jest w stanie identyfikować konkretnej osoby fizycznej.

Podsumowując

Przepisy o ochronie danych osobowych mówią o konieczności stosowania technik kryptograficznych. W tym artykule poznałeś różnicę między szyfrowaniem (odwracalnym) i hashowaniem (nieodwracalnym).

W razie konieczności anonimizacji danych, najbardziej bezpiecznym sposobem postępowania wydaje się nadpisanie danych osobowych losowym lub pustym ciągiem. Taka operacja jest całkowicie nieodwracalna i nie daje w przyszłości możliwości dowiedzenia że konkretna informacja – np. konkretny adres e-mail – została w ten sposób zanonimizowana.

Tego rodzaju potwierdzenie daje stosowanie hasha. Ponieważ jednak, zwłaszcza dla prostych metod hashowania, jak md5, istnieją sposoby pozwalające odgadnąć zapisane informacje, polecam ostrożność w posługiwaniu się hashowaniem. Pozostaje ono natomiast dobrą metodą w odniesieniu do np. rejestru sprzeciwów etc. – aby wykazać, że np. w odniesieniu do danego adresu mailowego zapisano sprzeciw.