Zero-knowledge a RODO i naruszenie danych: co się zmienia

Dlaczego w rozmowie o naruszeniu danych architektura ma znaczenie

Gdy organizacja wykrywa incydent bezpieczeństwa, pierwsza fala pytań zwykle jest bardzo praktyczna. Co wyciekło? Kto miał dostęp? Czy trzeba zgłosić sprawę do organu nadzorczego? Czy trzeba powiadomić osoby, których dane dotyczą? Właśnie tu architektura systemu zaczyna mieć znaczenie większe niż marketingowe deklaracje o bezpieczeństwie. RODO nie pyta wyłącznie o to, czy ktoś dotknął serwera. Pyta przede wszystkim, jaki był rzeczywisty wpływ zdarzenia na poufność danych osobowych.

W klasycznym modelu odpowiedź jest często niekorzystna. Jeśli system przechowuje pliki i wiadomości w czytelnej formie albo ma po stronie serwera klucz, który pozwala je odtworzyć, naruszenie infrastruktury bardzo szybko zamienia się w pytanie o ekspozycję konkretnych danych osobowych. To oznacza cięższą analizę pod art. 33 i 34 RODO, większe ryzyko konieczności zgłoszenia i większy problem komunikacyjny wobec klientów, pacjentów albo pracowników.

Model zero-knowledge nie zwalnia z odpowiedzialności i nie daje automatycznego immunitetu regulacyjnego, ale zmienia punkt wyjścia. Jeśli system przechowuje jedynie szyfrogram, a klucz deszyfrujący nie znajduje się po stronie dostawcy, to nawet skuteczne włamanie do warstwy przechowywania nie daje atakującemu czytelnych danych. Otrzymuje on zaszyfrowane obiekty, których nie da się użyć bez dodatkowego materiału kryptograficznego. To nie jest drobny detal techniczny. To okoliczność, która wpływa na ocenę ryzyka dla osób, których dane dotyczą.

Właśnie dlatego temat zero-knowledge RODO warto rozpatrywać nie tylko jako element prewencji, ale też jako część przygotowania do reakcji na incydent. Jeśli chcesz najpierw uporządkować podstawy, zobacz również jak działa szyfrowanie zero-knowledge oraz jak fragment URL chroni klucz szyfrowania.

Co realnie zmienia się przy ocenie incydentu pod art. 33 RODO

Artykuł 33 RODO mówi o obowiązku zgłoszenia naruszenia ochrony danych osobowych, chyba że jest mało prawdopodobne, aby skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. To sformułowanie jest ważne, bo nie każdy incydent infrastrukturalny automatycznie oznacza identyczny poziom ryzyka. Jeżeli organizacja potrafi wykazać, że atakujący uzyskał dostęp wyłącznie do zaszyfrowanych danych bez klucza, jej pozycja analityczna jest mocniejsza niż w sytuacji, w której baza zawierała tekst jawny albo dostawca mógł samodzielnie odszyfrować zawartość.

Wyobraź sobie dwa scenariusze. W pierwszym kancelaria korzysta z narzędzia do wymiany dokumentów, które przechowuje czytelne pliki lub ma po stronie serwera pełny dostęp do ich odszyfrowania. Włamanie do takiej usługi może oznaczać, że umowy, dowody osobiste i pełnomocnictwa były od początku dostępne w formie nadającej się do natychmiastowego wykorzystania. W drugim scenariuszu ta sama kancelaria używa modelu zero-knowledge. Atakujący kradnie obiekty ze warstwy przechowywania, ale bez klucza widzi jedynie szyfrogram. Analiza incydentu nadal jest obowiązkowa, lecz rozmowa o rzeczywistym ryzyku wygląda już zupełnie inaczej.

To samo dotyczy danych HR, raportów medycznych, materiałów zarządczych czy dokumentów finansowych. Kluczowe pytanie brzmi nie tylko, czy doszło do nieautoryzowanego dostępu, ale również, czy uzyskany materiał był dla atakującego użyteczny w sensie treściowym. Właśnie tu szyfrowanie może działać jako środek realnie ograniczający skutki incydentu, a nie tylko jako checkbox w polityce bezpieczeństwa.

Oczywiście zero-knowledge nie rozwiązuje wszystkiego. Organizacja nadal musi zbadać zakres zdarzenia, możliwy wpływ na metadane, ekspozycję kont użytkowników, logów czy procesów biznesowych. Jeśli ktoś przejął pełny link z kluczem albo punkt końcowy użytkownika, sama architektura warstwy przechowywania już nie wystarczy. Ale w bardzo wielu przypadkach zero-knowledge przesuwa ocenę z poziomu wyciekły dane w postaci czytelnej na poziom naruszono dostęp do zaszyfrowanych obiektów bez zdolności ich odczytu. To jest różnica o ogromnym znaczeniu praktycznym.

W organizacjach regulowanych warto z góry przygotować taki model oceny. Oznacza to dokumentowanie, gdzie powstaje klucz, które systemy nigdy go nie widzą oraz jak można wykazać, że naruszony zasób był wyłącznie szyfrogramem. Taka dokumentacja przyspiesza pracę IOD oraz zespołów prawnych i bezpieczeństwa w pierwszych godzinach po zdarzeniu.

Jak wykorzystać ten model w praktyce compliance

Najrozsądniejsze podejście polega na tym, żeby nie czekać z interpretacją do momentu incydentu. Organizacja powinna już wcześniej wiedzieć, które procesy opierają się na zero-knowledge, jakie dane są w nich przesyłane i w jaki sposób można wykazać brak dostępu dostawcy do klucza. Dzięki temu zespół reagowania nie zaczyna od zgadywania, lecz od sprawdzenia konkretnych faktów technicznych.

W praktyce dobrze działa prosty zestaw pytań. Czy treść była szyfrowana po stronie klienta? Czy dostawca miał kiedykolwiek dostęp do klucza? Czy klucz mógł znaleźć się w logach, proxy, systemach supportowych albo backupach? Czy incydent dotyczył samej warstwy przechowywania, czy także endpointu użytkownika? Taka lista kontrolna pozwala szybko odróżnić naruszenie warstwy infrastrukturalnej od zdarzenia, które rzeczywiście mogło ujawnić dane osobowe w czytelnej formie.

Dla mbox.pl to oznacza przewagę nie tylko w codziennym bezpiecznym udostępnianiu, ale również w rozmowie z IOD, działem compliance i prawnikami klienta. Jeśli narzędzie zostało zbudowane tak, by operator nie mógł odczytać treści, organizacja może oprzeć analizę incydentu na faktach technicznych, a nie na miękkich zapewnieniach dostawców. To szczególnie istotne tam, gdzie jedna ekspozycja mogłaby objąć dane pracownicze, zdrowotne albo dokumenty transakcyjne.

W praktyce warto tu mieć także gotowe odniesienia do konkretnych procesów. Jeśli dział HR wysyła dokumenty kadrowe przez model zero-knowledge, a kancelaria przekazuje projekty pism przez kontrolowany link, obie organizacje mogą szybciej wykazać, że naruszenie warstwy przechowywania nie był równoznaczny z utratą czytelnego tekstu jawnego. To właśnie zamienia architekturę w argument compliance, a nie tylko techniczną cechę produktu.

Zero-knowledge nie wyłącza obowiązku zgłaszania incydentów wtedy, gdy ryzyko jest realne. Nie usuwa też obowiązku analizy. Daje natomiast dużo mocniejszy punkt startowy: naruszony zasób może okazać się bezużyteczny dla atakującego bez dostępu do klucza. A to często jest dokładnie ta różnica, która rozstrzyga, czy organizacja mierzy się z poważnym naruszeniem poufności, czy z incydentem technicznym o ograniczonym wpływie na prawa i wolności osób.