Iluzja szyfrowania
Zaktualizowano w 2026 r.
W grudniu 2022 r. LastPass poinformował użytkowników o naruszeniu bezpieczeństwa. Komunikat był spokojny: hasła były „zaszyfrowane”. Zawartość skarbców była „zabezpieczona”.
Do 2025 r. ze „bezpiecznych” skarbców LastPass skradziono ponad 438 milionów dolarów.
Jak to możliwe? LastPass trzymał klucze.
Zespół ds. bezpieczeństwa musi znać tę historię przed wyborem narzędzia chmurowego. Dotyczy każdego narzędzia obsługującego wrażliwe pliki — w tym platform do anonimizacji danych osobowych (PII).
Szyfrowanie po stronie serwera a architektura zero-knowledge
Większość narzędzi chmurowych twierdzi, że „szyfruje Twoje pliki”. W rzeczywistości stosują szyfrowanie po stronie serwera (SSE). Oto co to oznacza:
| Właściwość | Szyfrowanie po stronie serwera | Architektura zero-knowledge |
|---|---|---|
| Gdzie przebiega szyfrowanie | Na serwerze dostawcy | Na Twoim urządzeniu (przeglądarka/komputer) |
| Kto posiada klucze | Dostawca | Wyłącznie Ty |
| Dostawca może odczytać Twoje treści | Tak | Nie |
| Naruszenie serwera ujawnia pliki | Tak | Nie (tylko zaszyfrowany tekst) |
| Dostawca może być zmuszony do udostępnienia treści | Tak | Nie (nie posiada tych danych) |
| Dostęp organów ścigania | Przez dostawcę | Niemożliwy bez Twojego klucza |
LastPass posiadał klucze. To był fatalny błąd. Atakujący włamali się i uzyskali zarówno zaszyfrowany tekst, jak i narzędzia do jego złamania. Zastosowali inżynierię społeczną, ataki brute-force na słabe hasła i stare metadane kont.
Dlaczego ma to znaczenie dla art. 25 RODO
Art. 25 RODO (Privacy by Design) jest jednoznaczny. Administratorzy muszą stosować „odpowiednie środki techniczne i organizacyjne” wbudowane od samego początku.
Europejska Rada Ochrony Danych (EROD) dodała, że obejmuje to kryptograficzną minimalizację danych. System sam w sobie musi blokować dostęp do danych. Same kontrole dostępu nie są wystarczające.
Dostawca posiadający Twoje klucze nie może w pełni spełnić wymogów art. 25. Oto dlaczego:
- Naruszenie jego systemu może ujawnić Twoje dane.
- Nakaz sądowy wobec dostawcy może przekazać Twoje treści.
- Nieuczciwy pracownik może przeglądać Twoje pliki.
- Atak na łańcuch dostaw może ujawnić wszystko.
Niemiecka Federalna Komisarz ds. Ochrony Danych (BfDI) wydała wytyczne w tej sprawie. Podobnie uczyniła austriacka Datenschutzbehörde. Obie wskazują architekturę zero-knowledge jako najlepszy wybór techniczny dla przetwarzania wysokiego ryzyka.
Rzeczywistość naruszeń w SaaS
Raport AppOmni / Cloud Security Alliance z 2024 r. odnotował wzrost liczby naruszeń SaaS o 300% w latach 2022–2024. Kluczowe fakty:
- Czas do naruszenia: 9 minut (wcześniej mierzony w godzinach)
- Rola stron trzecich w naruszeniach: podwoiła się rok do roku (Verizon DBIR 2025)
- Naruszenie Conduent: ujawniono 25,9 mln rekordów (numery PESEL, dokumentacja zdrowotna)
- Naruszenie dostawcy NHS: ujawniono dane 9 mln pacjentów
Deklaracje w dokumentach nie wystarczą. Solidna architektura to dziś minimum. Dotyczy to całego przetwarzania wysokiego ryzyka.
Jak wygląda prawdziwa architektura zero-knowledge
Prawdziwy system zero-knowledge posiada następujące cechy:
1. Derywacja klucza po stronie klienta Twój klucz pochodzi z Twojego hasła. Funkcja KDF odporna na pamięć (Argon2id, bcrypt lub scrypt) działa na Twoim urządzeniu. Klucz nigdy go nie opuszcza.
2. Szyfrowanie po stronie klienta Twoje treści są szyfrowane zanim opuszczą Twoją przeglądarkę lub aplikację. Serwer otrzymuje wyłącznie zaszyfrowany tekst. Bez klucza jest on bezużyteczny.
3. Brak przechowywania kluczy po stronie serwera Dostawca nie przechowuje żadnych kluczy, ich fragmentów ani kopii zapasowych. Do odzyskania dostępu służy własna fraza odzyskiwania.
4. Weryfikowalność kryptograficzna System musi być dobrze udokumentowany i otwarty na audyt. Niejasne twierdzenia o „szyfrowaniu end-to-end” bez szczegółów technicznych są sygnałem ostrzegawczym.
Implementacja zero-knowledge w anonym.legal
anonym.legal stosuje architekturę zero-knowledge opartą na:
- Derywacja klucza Argon2id: 64 MB pamięci, 3 iteracje — wybór OWASP dla aplikacji wysokiego bezpieczeństwa
- Szyfrowanie AES-256-GCM: działa całkowicie w przeglądarce lub aplikacji desktopowej przed wysłaniem jakichkolwiek treści
- 24-wyrazowa fraza odzyskiwania BIP39: jedyna metoda przywrócenia dostępu — nieprzechowywana przez anonym.legal
- Zerowy dostęp do kluczy po stronie serwera: serwery anonym.legal otrzymują wyłącznie zaszyfrowany tekst AES-256-GCM, którego nie mogą odszyfrować
Nawet pełne naruszenie serwerów anonym.legal ujawniłoby wyłącznie zaszyfrowane bloki danych. Bez klucza każdego użytkownika — który istnieje tylko na jego urządzeniu — są one bezużyteczne.
Zobacz nasze omówienie bezpieczeństwa i zgodności oraz dokumentację compliance po pełne szczegóły.
Lista kontrolna oceny dostawcy
Przy wyborze narzędzia chmurowego do obsługi wrażliwych danych zadaj te pytania:
Pytania architektoniczne:
- Gdzie przebiega szyfrowanie — na Twoim urządzeniu czy na serwerze dostawcy?
- Kto generuje klucze?
- Gdzie są przechowywane klucze?
- Czy dostawca może przekazać zwykły tekst Twoich treści na podstawie nakazu sądowego?
- Co dzieje się z Twoimi plikami, jeśli dostawca zostanie przejęty?
Pytania o odporność na naruszenia:
- Jeśli system dostawcy zostanie w pełni naruszony, jakie dane zostaną ujawnione?
- Jeśli pracownik dostawcy okaże się nieuczciwy, do jakich treści ma dostęp?
- Jeśli dostawcę dotknął atak na łańcuch dostaw, co zostaje ujawnione?
Pytania regulacyjne:
- Czy dostawca może przedstawić dokumentację dotyczącą art. 25 RODO?
- Czy zewnętrzny audytor zweryfikował system?
- Czy istnieje certyfikat ISO 27001 lub SOC 2 obejmujący szyfrowanie?
Każdy dostawca, który nie może odpowiedzieć „zero — treści są szyfrowane przed opuszczeniem urządzenia” na pytania o naruszenia, stosuje szyfrowanie po stronie serwera. Sprawdź nasze FAQ i słowniczek po więcej definicji.
Studium przypadku: Niemiecka kasa chorych
Inspektor compliance w dużej niemieckiej kasie chorych (Krankenkasse) potrzebował narzędzia chmurowego do anonimizacji. Zadanie: przetwarzanie dzienników skarg ubezpieczonych. Inspektor ochrony danych (IOD) miał cztery wymagania:
- Dostawca nie może mieć dostępu do dokumentacji ubezpieczonych
- Żadne przetwarzanie poza Niemcami
- Udokumentowane środki techniczne wymagane przez art. 32 RODO
- Minimalizacja ryzyka naruszenia podlegającego zgłoszeniu do UODO
Duży amerykański SaaS do anonimizacji nie spełnił pierwszego kryterium — jego zespół wsparcia mógł resetować skarbce użytkowników, co dowodzi dostępu do kluczy po stronie serwera. Drugie narzędzie przechowywało przetworzone teksty przez 30 dni jako „ścieżkę audytu” — również dostęp po stronie serwera.
anonym.legal spełniło wszystkie cztery kryteria. IOD mógł zapisać: „Nawet pełne naruszenie dostawcy nie ujawni żadnych danych ubezpieczonych — klucze istnieją wyłącznie na naszych stacjach roboczych.” Dokumentacja art. 32 RODO została ukończona w cztery godziny.
Zobacz nasze studia przypadków po więcej przykładów z rzeczywistości.
Precedens egzekucyjny ICO
W grudniu 2025 r. brytyjski Urząd Komisarza ds. Informacji (ICO) ukarał podmiot LastPass UK grzywną w wysokości 1,2 mln funtów. Powód: „brak wdrożenia odpowiednich technicznych i organizacyjnych środków bezpieczeństwa”.
Grzywna nie dotyczyła samego naruszenia, lecz decyzji architektonicznych, które uczyniły skutki naruszenia tak poważnymi. Słabe ustawienia KDF, ujawnione metadane i przechowywanie kluczy po stronie serwera — wszystko to odegrało rolę.
Regulatorzy pytają teraz: czy system ograniczył skutki naruszenia? Architektura zero-knowledge odpowiada na to pytanie jednoznacznie. Jest najlepszym dowodem takiego zamiaru.
Kiedy architektura zero-knowledge nie jest właściwym rozwiązaniem
Szyfrowanie zero-knowledge wiąże się z kompromisami istotnymi dla niektórych przypadków użycia:
Złożoność odzyskiwania: jeśli użytkownicy utracą klucze, ich pliki przepadają bezpowrotnie. Nie ma tylnych drzwi. Wysoka rotacja personelu lub słabe nawyki zarządzania kluczami są realnym ryzykiem.
Trudności we współpracy: zaszyfrowane treści można udostępniać tylko wtedy, gdy druga strona posiada właściwe narzędzia deszyfrowania. Jest to wolniejsze niż zwykłe udostępnianie linku w standardowych aplikacjach chmurowych.
Przypadki graniczne regulacyjne: niektóre jurysdykcje wymagają dostępu organów ścigania do danych na podstawie nakazu sądowego. Systemy zero-knowledge blokują to z założenia, co może powodować problemy prawne w sektorze finansowym lub telekomunikacyjnym, gdzie obowiązują przepisy o legalnym przechwytywaniu.
Narzut obliczeniowy: derywacja klucza Argon2id i szyfrowanie AES-256-GCM dodają opóźnienie, które najbardziej odczuwa się przy przetwarzaniu w czasie rzeczywistym i dużych wolumenach.
Dla zespołów przetwarzających miliony dokumentów dziennie lepszym rozwiązaniem może być podejście hybrydowe — szyfruj tylko najbardziej wrażliwe pola, pozostawiając metadane otwarte. Zobacz plany cenowe po informacje o wolumenach.
Podsumowanie
„Szyfrujemy Twoje pliki” to nie obietnica bezpieczeństwa — to hasło marketingowe wymagające weryfikacji.
Prawdziwe pytania są proste. Kto posiada klucze? Gdzie przebiega szyfrowanie? Co zostaje ujawnione przy naruszeniu systemów dostawcy?
Dla zespołów przetwarzających wrażliwe dane w ramach RODO, HIPAA lub podobnych przepisów te decyzje architektoniczne kształtują zarówno ryzyko prawne, jak i realne skutki naruszenia.
LastPass szyfrował treści swoich użytkowników. Architektura zero-knowledge sprawiłaby, że naruszenie z 2022 r. nie miałoby żadnych skutków. 438 milionów dolarów skradzionych użytkownikom to koszt skrótu architektonicznego.
anonym.legal stosuje architekturę zero-knowledge do anonimizacji PII. Derywacja klucza Argon2id działa w Twojej przeglądarce lub aplikacji desktopowej. Szyfrowanie AES-256-GCM przebiega zanim jakiekolwiek treści opuszczą Twoje urządzenie. Serwery anonym.legal przechowują wyłącznie zaszyfrowany tekst, którego nie mogą odszyfrować. Dowiedz się więcej na naszej stronie o założycielu lub zapoznaj się z systemem tokenów.