Podstawa prawna naruszenia

Art. 5 ust. 1 lit. f), art. 32 ust 1 UK RODO.

Niewystarczające środki techniczne i organizacyjne zapewniające bezpieczeństwo informacji.

Przyczyna naruszenia

Przyczyną naruszenia w LastPass był splot zaniedbań w zakresie bezpieczeństwa systemów i nieprzestrzegania dobrych praktyk zarządzania dostępem. Spółka umożliwiła swoim pracownikom, w tym osobom o wysokich uprawnieniach, korzystanie z niezabezpieczonych urządzeń prywatnych i łączenie kont prywatnych z biznesowymi pod jednym hasłem. To w połączeniu z niewystarczającym nadzorem nad kluczami szyfrowania i opóźnioną reakcją na alerty bezpieczeństwa pozwoliło atakującym przejąć dane. Brak jasnego oddzielenia sfery służbowej i prywatnej oraz niedoskonałe procedury reagowania na incydenty sprawiły, że naruszenie miało szeroki zakres i objęło ponad 1,6 mln użytkowników.

Opis wydarzeń

1. Niepozorne ostrzeżenie: 11 sierpnia 2022 r. system AWS GuardDuty wykrył nietypowe polecenia w środowisku LastPass. SOC organizacji wszczął śledztwo, a dzień później zaproszono do współpracy specjalistów z Mandiant. Szybko ustalono, że komputer dewelopera został zainfekowany, co pozwoliło napastnikowi uzyskać dostęp do repozytoriów kodu źródłowego i wydobyć z nich zaszyfrowany klucz SSE‑C odpowiadający za szyfrowanie backupu bazy danych. Na tym etapie intruzi nie przejęli jednak danych klientów, gdyż brakowało im drugiego klucza i hasła administratora, a LastPass przystąpił do rotacji haseł i wymiany dotkniętego urządzenia.
2. Wykorzystanie prywatnego sprzętu: Zaledwie dzień po pierwszym incydencie, 12 sierpnia 2022 r., atakujący wykorzystali lukę w niezaktualizowanym oprogramowaniu „Plex” na prywatnym komputerze starszego inżyniera DevOps. Instalacja keyloggera pozwoliła im pozyskać „master password”, które otwierało zarówno konto prywatne, jak i firmowe, a dzięki przejętemu plikowi cookie zaufanego urządzenia udało się obejść uwierzytelnianie wieloskładnikowe. W sejfie hasłowym inżyniera znajdował się klucz deszyfrujący oraz AWS Access Key, co w połączeniu z zaszyfrowanym kluczem SSE‑C umożliwiło odszyfrowanie i pobranie kopii zapasowej bazy klientów z chmury AWS.
3. Eskfiltracja danych i opóźniona reakcja: Między 19 sierpnia a 22 września atakujący wielokrotnie logowali się na konto inżyniera i pobierali dane. W październiku system GuardDuty ponownie wygenerował alerty, lecz lista dystrybucyjna powiadomień była niekompletna, co spowodowało, że odpowiedni zespół zapoznał się z nimi dopiero po 18 dniach. Dopiero 15 grudnia AWS potwierdził, że intruzi skopiowali backup zawierający nazwiska, adresy e‑mail, numery telefonów i inne dane kontaktowe klientów. Szyfrowane hasła pozostały zaszyfrowane dzięki architekturze „zero knowledge”.
4. Reakcja LastPass: Spółka opublikowała komunikaty informujące użytkowników o incydencie i podkreślała, że hasła w sejfach nie zostały odszyfrowane. Jednocześnie wprowadziła zmiany w politykach: w maju 2023 r. zakazała łączenia kont osobistych i służbowych, wyposażyła pracowników w firmowe urządzenia i wdrożyła sprzętowe klucze uwierzytelniające. Te działania były jednak spóźnione, bo naruszenie już miało miejsce i skutkowało wizerunkowym i finansowym ryzykiem.
5. Kara finansowa: W następstwie opisanych incydentów brytyjski organ nadzorczy wydał 20 listopada 2025 r. formalne zawiadomienie o nałożeniu kary. Na jego mocy LastPass UK Ltd musi zapłacić 1 228 283 GBP za naruszenie. Brytyjski organ nadzorczy uznał, że taka wysokość kary adekwatnie oddaje powagę naruszeń i stanowi skuteczną, proporcjonalną oraz odstraszającą sankcję. Kara została ustalona po uwzględnieniu m.in. czasu trwania naruszeń, liczby poszkodowanych osób (ponad 1,6 mln użytkowników) oraz faktu, że spółka jako dostawca menedżera haseł powinna była stosować najwyższe standardy bezpieczeństwa.

Źródło

Pełna treść decyzji organu nadzorczego

Aby uniknąć podobnych naruszeń, zalecamy:

1. Wyodrębnij środowisko służbowe od prywatnego: Organizacje powinny opracować i egzekwować politykę BYOD, która jasno precyzuje minimalne wymagania techniczne dla prywatnych urządzeń i zakazuje łączenia kont osobistych i służbowych. UODO przypomina, że nawet gdy pracownik korzysta z własnego sprzętu, administrator danych odpowiada za jego bezpieczeństwo i musi wykazać wdrożenie adekwatnych środków bezpieczeństwa. W praktyce warto udostępnić pracownikom firmowe laptopy i telefony z prekonfigurowanym oprogramowaniem oraz wprowadzić kontenery MDM na urządzeniach mobilnych. Taki podział minimalizuje ryzyko, że zainfekowana aplikacja prywatna przejmie dane firmowe.

2. Stosuj silne i wielowarstwowe uwierzytelnianie: Obowiązkowe jest użycie uwierzytelniania wieloskładnikowego w całym ekosystemie, ale nie powinno się ograniczać do generatora kodów TOTP. Warto przejść na bezpieczne klucze FIDO2/WebAuthn oraz jednorazowe certyfikaty, które są odporne na phishing i nie mogą zostać ominięte poprzez przejęcie sesji czy cookie. Ponadto hasła główne muszą spełniać wymagania a administrator powinien regularnie monitorować zagrożenia zewnętrzne i dostosowywać parametry zgodnie z aktualnymi rekomendacjami ENISA.

3. Usystematyzuj zarządzanie kluczami kryptograficznymi i dostępami uprzywilejowanymi: Wrażliwe klucze, takie jak AES SSE‑C, muszą być przechowywane w systemach HSM (Hardware Security Module) z dostępem ograniczonym do wybranego grona pracowników. Firma powinna prowadzić dziennik dostępu do kluczy i wymuszać ich rotację, szczególnie po każdej zmianie personelu lub incydencie. Dostępy uprzywilejowane (administratorzy IT, DevOps) powinny być zarządzane poprzez dedykowane systemy PAM (Privileged Access Management), które umożliwiają kontrolę i audyt działań.

4. Buduj świadomość i odpowiedzialność personelu: Obowiązki szkoleniowe powinny być realizowane regularnie. Szkolenia powinny obejmować m.in. rozpoznawanie phishingu, zasady korzystania z menedżerów haseł, wymagania dotyczące aktualizacji oprogramowania oraz procedury zgłaszania incydentów. Warto podkreślać pracownikom, że instalowanie nieautoryzowanych aplikacji na urządzeniach służbowych lub używanych do pracy stanowi realne zagrożenie. Dobre praktyki sugerowane przez CNIL i UODO obejmują prowadzenie testów socjotechnicznych (phishing simulations) i utrwalanie kultury bezpieczeństwa.

5. Usprawnij mechanizmy detekcji i reakcję na incydenty: Firmy powinny w czasie zbliżonym do rzeczywistego monitorować logi systemowe, używać narzędzi SIEM i reagować na alerty z systemów chmurowych jak AWS GuardDuty. Konieczne jest zdefiniowanie list powiadomień z jasno określonymi rolami i odpowiedzialnościami, aby uniknąć sytuacji, w której alert „zagubi się” w organizacji. Warto też prowadzić regularne ćwiczenia z reagowania na incydenty oraz opracować plany ciągłości działania obejmujące procedury komunikacji z organami nadzorczymi i informowania osób, których dane dotyczą.

6. Respektuj zasady minimalizacji i retencji danych: Regularnie przeglądaj bazę przechowywanych danych i usuwaj lub anonimizuj informacje, które nie są niezbędne do realizacji celu. Ograniczenie zbieranych i przechowywanych danych zmniejsza potencjalny skutek wycieku.

7. Aktualizuj oprogramowanie i przeprowadzaj testy bezpieczeństwa: Systemy, aplikacje i biblioteki muszą być regularnie aktualizowane. Administratorzy powinni monitorować publikowane CVE i reagować na nie w odpowiednim czasie. Warto wprowadzić procedury „patch management” zgodne z normą ISO 27001 i przeprowadzać okresowe testy penetracyjne i audyty code review.

Jeśli potrzebujesz wsparcia w zakresie ochrony danych osobowych, zapraszamy do kontaktu