Luka między roszczeniem a architekturą
Każdy dostawca chmury obsługujący wrażliwe dane składa jakąś wersję tego samego roszczenia: "Szyfrujemy Twoje dane." To roszczenie jest niemal zawsze prawdziwe — i niemal zawsze niewystarczające.
Włamanie do LastPass w 2022 roku to definitywne studium przypadku. LastPass szyfrował sejfy z hasłami swoich użytkowników. Użyli szyfrowania. To roszczenie było dokładne. A jednak 25 milionów użytkowników miało swoje szyfrowane sejfy wykradzione, a $438 milionów zostało następnie skradzionych od użytkowników LastPass w wyniku późniejszych kradzieży kryptowalutowych do 2025 roku, według badań Coinbase Institutional.
Brytyjski Urząd Ochrony Danych nałożył na brytyjską jednostkę LastPass karę w wysokości £1,2 miliona w grudniu 2025 roku za "niewdrożenie odpowiednich środków technicznych i organizacyjnych w zakresie bezpieczeństwa." Szyfrowanie istniało. Środki bezpieczeństwa nie spełniały wymaganego standardu.
Dla przedsiębiorstw oceniających narzędzia prywatności w chmurze — w tym platformy anonimizacji PII — precedens LastPass zmienia pytanie dotyczące zakupu. Pytanie nie brzmi "czy szyfrują nasze dane?" lecz "czy mogą odszyfrować nasze dane?"
Cztery pytania dotyczące zerowej wiedzy, które naprawdę mają znaczenie
Podczas oceny roszczenia dostawcy dotyczącego zerowej wiedzy, cztery pytania decydują o tym, czy architektura jest autentyczna:
1. Gdzie odbywa się generowanie kluczy?
W prawdziwej architekturze zerowej wiedzy generowanie kluczy szyfrujących odbywa się po stronie klienta — w przeglądarce lub aplikacji desktopowej — zanim jakiekolwiek dane zostaną przesłane. Wygenerowany klucz jest używany do lokalnego szyfrowania danych. Tylko szyfrowany tekst (ciphertext) trafia na serwery dostawcy.
Jeśli dostawca generuje klucze szyfrujące na swoich serwerach, to on posiada klucze. Jeśli posiada klucze, może odszyfrować. To roszczenie jest technicznie dokładne ("szyfrujemy") ale mylące w swoim implikacji.
2. Czy dostawca kiedykolwiek ma dostęp do tekstu jawnego?
Niektóre narzędzia szyfrują dane w spoczynku, ale odszyfrowują je do przetwarzania — uruchamiania modeli AI, analityki, indeksowania wyszukiwania lub generowania dzienników audytowych. W czasie przetwarzania tekst jawny jest dostępny w infrastrukturze dostawcy. Włamanie w tym czasie ujawnia dane w niezaszyfrowanej formie.
3. Co się dzieje w przypadku postępowania prawnego?
Jeśli agencja rządowa dostarcza wezwanie do dostawcy, jakie dane mogą oni przedstawić? Dostawca z kluczami po stronie serwera może być zmuszony do przedstawienia odszyfrowanej zawartości. Dostawca z architekturą zerowej wiedzy może jedynie przedstawić szyfrowany tekst — nawet pod przymusem prawnym, nie mają nic użytecznego do przekazania.
4. Co ujawnia pełne naruszenie serwera?
W prawdziwej implementacji zerowej wiedzy, całkowite włamanie do infrastruktury dostawcy ujawnia jedynie szyfrowane bloby. Atakujący otrzymuje szyfrowany tekst bez kluczy do jego odszyfrowania. W implementacji z kluczem kontrolowanym przez dostawcę, włamanie do serwera ujawnia klucze wraz z danymi.
Niepowodzenie implementacji LastPass
Włamanie do LastPass ujawniło konkretną lukę w implementacji: starsze konta używały PBKDF2 z tak małą liczbą jak 1 iteracja do generowania kluczy, zamiast zalecanych 600,000 iteracji. Słabsze generowanie kluczy sprawiło, że ataki brute-force na wykradzione sejfy stały się wykonalne obliczeniowo.
To ilustruje, dlaczego ocena roszczeń dotyczących zerowej wiedzy wymaga badania szczegółów implementacji, a nie tylko opisów architektonicznych. Dostawca może używać projektu zerowej wiedzy, jednocześnie słabo go implementując. Odpowiednie pytania do zadania obejmują zarówno architekturę (miejsce generowania kluczy), jak i siłę implementacji (algorytm i liczba iteracji).
Włamanie do Okta: Inny tryb niepowodzenia
W październiku 2023 roku, Okta ujawniła, że w wyniku włamania wyciekło ponad 600,000 rekordów wsparcia klienta. Okta to platforma tożsamości — firma, z której korzysta wiele przedsiębiorstw, aby zabezpieczyć dostęp do swoich innych narzędzi chmurowych. Włamanie do Okta miało inny tryb niepowodzenia niż LastPass: nie było słabością w implementacji zerowej wiedzy, ale kompromitacją infrastruktury wsparcia, która zawierała dane klientów.
Wzrost włamań SaaS o 300% w 2024 roku (AppOmni/CSA) odzwierciedla oba tryby niepowodzenia: słabości architektoniczne jak w LastPass oraz kompromitacje infrastruktury jak w Okta. Architektura zerowej wiedzy odnosi się do architektonicznego trybu niepowodzenia. Nie eliminuje całkowicie ryzyka włamania, ale zapewnia, że nawet całkowita kompromitacja infrastruktury nie ujawnia odszyfrowanych danych klientów.
Jak wygląda prawdziwa ocena
Dla zespołów zakupowych oceniających roszczenia dotyczące zerowej wiedzy, lista kontrolna oceny:
Przegląd architektury:
- Poproś o dokumentację pokazującą, gdzie odbywa się generowanie kluczy (po stronie klienta vs. po stronie serwera)
- Zapytaj o algorytm szyfrowania, długość klucza i liczbę iteracji
- Poproś o potwierdzenie, że tekst jawny nigdy nie jest przesyłany na serwery dostawcy
Testowanie scenariuszy naruszenia:
- Poproś dostawcę o opis, co ujawnia pełne włamanie do serwera
- Jeśli odpowiedź zawiera cokolwiek innego niż "szyfrowany tekst, którego nie możemy odszyfrować," roszczenie nie jest prawdziwą zerową wiedzą
Przegląd procesu prawnego:
- Zapytaj, czy dostawca może spełnić wezwanie do produkcji tekstu jawnego klienta
- Prawdziwi dostawcy zerowej wiedzy nie mogą produkować tego, czego nie mają
Dokumentacja zgodności:
- Poproś o dokumentację zgodności dostawcy z artykułem 32 RODO
- Certyfikacja ISO 27001 (szczególnie kontrola kryptograficzna w Załączniku A) zapewnia zewnętrzną weryfikację praktyk zarządzania kluczami
Kara w wysokości £1,2 miliona nałożona na LastPass przez ICO ustanawia, że dostawcy składający roszczenia dotyczące szyfrowania podlegają ocenie regulacyjnej, czy te roszczenia spełniają wymagany standard. Ta sama struktura oceny, którą stosują organy regulacyjne, jest dostępna dla zespołów zakupowych przed wystąpieniem naruszenia.
Źródła: