Wyciek danych

Incydent, w którym poufne lub osobowe dane zostają ujawnione, skradzione lub udostępnione osobom nieuprawnionym, najczęściej w wyniku ataku lub błędu.

Wyciek danych (ang. data breach) to sytuacja, w której poufne informacje — dane logowania, numery kart, dokumenty czy dane osobowe klientów — trafiają w ręce osób, które nie powinny mieć do nich dostępu. Czasem to spektakularny atak, a czasem zwykła wpadka: ktoś wystawił bazę do internetu bez hasła albo wrzucił plik z sekretami do publicznego repozytorium na GitHubie. Efekt jest ten sam — dane, które miały być prywatne, przestają takie być.

Wbrew filmowym wyobrażeniom większość wycieków nie wygląda jak włamanie z neonowym kodem na ekranie. Najczęstsze przyczyny to wykradzione lub słabe hasła, phishing (ktoś podał dane na podrobionej stronie), niezałatane podatności w aplikacji albo źle skonfigurowana infrastruktura. Klasyk gatunku to bucket S3 ustawiony jako publiczny albo baza wystawiona na świat bez uwierzytelniania. Atakujący nie musi nic „łamać” — wystarczy, że zna adres.

Jak to wygląda w praktyce

Załóżmy, że twoja aplikacja webowa ma podatność na SQL injection. Atakujący wstrzykuje zapytanie w pole formularza i pobiera całą tabelę users razem z hasłami. Jeśli były hashowane słabym algorytmem (albo, o zgrozo, trzymane plaintextem), po wycieku trafiają do narzędzi typu hashcat, które łamią je offline. Stąd prosta droga do credential stuffing — ten sam login i hasło atakujący testuje na dziesiątkach innych serwisów, licząc, że gdzieś je powtórzyłeś.

Czy twój adres figuruje w znanym wycieku, sprawdzisz na serwisie Have I Been Pwned. Ma też API — pojedyncze konto odpytasz tak:

curl -H "hibp-api-key: TWOJ_KLUCZ" https://haveibeenpwned.com/api/v3/breachedaccount/[email protected]

Częste błędy i mity

  • „Mamy firewall, więc jesteśmy bezpieczni” — firewall nie pomoże, gdy baza jest publicznie dostępna albo pracownik kliknął w phishing.
  • Mylenie wycieku z naruszeniem RODO — to bywa to samo zdarzenie, ale wyciek danych osobowych w UE trzeba zgłosić organowi nadzorczemu zwykle w ciągu 72 godzin od wykrycia.
  • „Hasła były hashowane, więc nic się nie stało” — przy słabym algorytmie (np. niesolony MD5) hash łamie się błyskawicznie. Liczy się jak, nie samo „hashowanie”.
  • Sekrety w kodzie — klucze API i hasła w repo to jeden z najczęstszych źródeł wycieków. Trzymaj je w zmiennych środowiskowych albo menedżerze sekretów.

Pojęcia powiązane: phishing, SQL injection, credential stuffing, hashowanie haseł, szyfrowanie, RODO/GDPR, zarządzanie sekretami, uwierzytelnianie dwuskładnikowe (2FA).