Incydent, który zmienił bezpieczeństwo w chmurze
Zaktualizowano w 2026 r.
Naruszenie LastPass z 2022 r. nie dotyczy głównie menedżerów haseł. Dotyczy zaufania. Firmy zaufały dostawcy chmury swoimi danymi. To zaufanie zostało złamane. Przyczyną były ukryte wady, nie lekkomyślność.
LastPass sprzedawał projekt zero-knowledge. W praktyce nim nie był. 25 milionów użytkowników miało skradzione zaszyfrowane sejfy. Atak ujawniono po raz pierwszy w sierpniu 2022 r. LastPass kilkakrotnie rewidował swoje komunikaty. Pełny zakres wyłonił się pod koniec 2022 r.
Dla firm z sektora opieki zdrowotnej, finansów i prawa nie była to odległa historia z gazet. Te sektory ponoszą realną odpowiedzialność za wycieki danych. Sprawa LastPass była wczesnym sygnałem szerszego problemu.
Dwie wady, które umożliwiły atak
Przegląd po incydencie ujawnił dwie kluczowe słabości.
Słaba konfiguracja klucza. LastPass używał PBKDF2 do wyprowadzania klucza. Nowsze konta miały 100 100 iteracji. OWASP zaleca 600 000. Niektóre stare konta miały zaledwie 1 iterację. Mniejsza liczba iteracji sprawia, że ataki siłowe są szybkie i tanie. Atakujący posiadający pliki sejfu mogli testować hasła główne z dużą prędkością.
Metadane w postaci jawnej. Zawartość sejfu była zaszyfrowana. Ale metadane nie. Adresy URL, nazwy użytkowników i nazwy usług były widoczne w skradzionych danych. Atakujący mogli zobaczyć, z jakimi usługami każdy użytkownik miał konta. Umożliwiło to ukierunkowany phishing i credential stuffing. Łamanie sejfu nie było wymagane.
Ta sprawa pokazuje, dlaczego dwa pytania muszą być zadawane osobno. „Czy projekt jest zero-knowledge?" to jedno pytanie. „Czy implementacja jest prawidłowa?" to inne pytanie.
Okta w 2023 r.: inny atak, ten sam wynik
W październiku 2023 r. Okta zgłosiła incydent bezpieczeństwa. Skradzione dane uwierzytelniające dały atakującemu dostęp do systemu obsługi klienta. Atak ujawnił ponad 600 000 rekordów obsługi. Obejmowały one pliki przesłane przez klientów podczas sesji wsparcia.
Okta to platforma bezpieczeństwa tożsamości. Problem nie był wadą projektu. Był to błąd kontroli dostępu. Login inżyniera wsparcia został skradziony. Atakujący użył go, aby dotrzeć do wrażliwych danych.
LastPass i Okta pokazują dwie główne ścieżki do kompromisu dostawcy:
- Awarie projektu — twierdzenia o zerowej wiedzy, które nie zostały prawidłowo zbudowane
- Awarie kontroli dostępu — prawidłowe dane uwierzytelniające użyte do dotarcia do danych, do których nie powinny mieć dostępu
Projekt zero-knowledge zapobiega pierwszemu typowi. Nie zatrzymuje atakującego z prawidłowymi danymi uwierzytelniającymi wsparcia. Ale blokuje mu odczytanie danych klientów. Dostawca nigdy nie przechowuje treści możliwej do odszyfrowania. Więcej informacji na ten temat znajdziesz w naszym przeglądzie bezpieczeństwa i zgodności.
Incydenty bezpieczeństwa SaaS wzrosły o 300% w dwa lata
Obsidian Security odnotowała 300-procentowy wzrost incydentów bezpieczeństwa na platformach SaaS w latach 2022–2024.
To nie jest wzrost o 300% w umiejętnościach atakujących. Dwie siły go napędzały. Wykorzystanie SaaS gwałtownie wzrosło. Atakujący podążyli za danymi. Jeden kompromis dostawcy może jednocześnie ujawnić dane dziesiątek klientów. Ta opłacalność sprzyja atakom na dostawców, a nie atakom na pojedyncze firmy.
Przedsiębiorstwa, które zakładały, że platformy chmurowe są bezpieczne, muszą zaktualizować ten pogląd. Dostawcy SaaS są teraz głównymi celami.
Pytania do każdego dostawcy chmury
Dla zespołów zakupowych i bezpieczeństwa ta lista kontrolna obejmuje kluczowe obszary.
Konfiguracja szyfrowania:
- Poproś o algorytm wyprowadzania klucza, liczbę iteracji i ustawienia pamięci.
- Potwierdź, że liczba iteracji spełnia minimalne wymagania OWASP. To 600 000 PBKDF2-SHA256 lub równoważne Argon2id.
- Zweryfikuj, że wyprowadzanie klucza odbywa się na Twoim urządzeniu, nie na serwerach dostawcy.
Ekspozycja metadanych:
- Zapytaj, jakie metadane są przechowywane w postaci jawnej obok zaszyfrowanej treści.
- Poproś o model danych. Powinien pokazywać, które pola są zaszyfrowane, a które widoczne w przypadku ataku.
Dostęp wsparcia:
- Zapytaj, czy pracownicy wsparcia mogą uzyskać dostęp do danych klientów.
- Potwierdź, że systemy wsparcia nie mogą dotrzeć do danych klientów w postaci jawnej.
Historia incydentów:
- Poproś o wszystkie poprzednie incydenty bezpieczeństwa, w tym te poniżej progów publicznego ujawnienia.
- Oceń, jak kompletne i uczciwe były poprzednie ujawnienia.
Incydent z LastPass był awarią implementacji i awarią zaufania. Dostawcy z konkretnymi odpowiedziami umożliwiają prawdziwą ocenę ryzyka. Dostawcy z nieokreślonymi twierdzeniami pozostawiają ryzyko ukryte. Ryzyko to często ujawnia się dopiero po ataku. Zapoznaj się z naszym przeglądem zgodności, aby uzyskać wskazówki dotyczące oceny dostawców.
anonym.legal stosuje architekturę zero-knowledge do anonimizacji PII. Wyprowadzanie klucza odbywa się przez Argon2id w Twojej przeglądarce lub aplikacji desktopowej. Szyfrowanie następuje przed opuszczeniem danych przez Twoje urządzenie. Serwery przechowują tylko szyfrogram, którego nie mogą odszyfrować. Dowiedz się więcej.