9:09
20/5/2020

Niedawny wyciek danych Fortum, polskiego dostawcy energii, zostanie zbadany przez Urząd Ochrony Danych Osobowych. Postępowanie administracyjne w sprawie możliwego naruszenia przepisów zostało wszczęte z urzędu.

O wycieku z Fortum informowaliśmy 21 kwietnia w tekście pt. Numery PESEL i dowodów wyciekły polskiemu dostawcy prądu, gazu i ciepła. Wyciek został wykryty przez badacza Boba Diachenko, który 16 kwietnia natrafił na publicznie dostępny i niechroniony klaster Elasticsearch. Zestaw danych objętych wyciekiem obejmował imię, nazwisko, adresy (korespondencyjne, zameldowania, zamieszkania), numery telefonów, PESELe, informacje o umowach numery dokumentów (np. dowodów osobistych.

W ramach uruchomionego teraz postępowania prezes UODO wezwał Fortum do przedstawienia szczegółowych informacji związanych z naruszeniem ochrony danych osobowych, w tym okoliczności naruszenia oraz  kategorii danych osób, których dotyczy naruszenie. Urząd przypomniał, że wdrożenie odpowiednich środków nie może być działaniem jednorazowym, a powinny one być na bieżąco aktualizowane.

Niezależnie od wszczętego postępowania administracyjnego Prezes UODO skierował do Spółki wystąpienie o podjęcie działań mających na celu niezwłoczne zawiadomienie osób, których dane dotyczą, o naruszeniu ich danych osobowych. Ze złożonego zgłoszenia naruszenia ochrony danych wynikało bowiem, że Spółka nie powiadomiła tych osób o naruszeniu.

Tak naprawdę Fortum informowała o naruszeniu. Wspominaliśmy w artykule, że firma zamieściła komunikat na swojej stronie. Ponadto Czytelnicy informowali nas, że ich bliscy otrzymywali pocztą pisma z powiadomieniem o wycieku.

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.


4 komentarzy

Dodaj komentarz
  1. To wszystko wina ElasticSearcha, MongoDB, Redisa i innych podobnych baz, że w ogóle działają bez autentykacji. Ale Developer Experience taki ważny…

    Spróbujcie postawić PostgreSQL z otwartym dostępem. Da się to manualnie skonfigurować, ale nie jest to oczywiste, i wszędzie są ostrzeżenia, dlaczego nie należy tego robić.

    • Ktoś mi mówił, że w wersji darmowej, do niedawna nie było żadnych opcji kontroli dostępu – chyba, że ktoś na firewallu sobie przyciął dostęp z konkretnych IP. I stąd te wycieki.
      Prawdę mówił, czy cienki bolek?

    • Z racji że administruje bazami PgSQL, robię sobie skrypty które mi liczą ilość połączeń botów i różnego dziadostwa na konkretne porty (iptables). I wiecie jakie są wyniki? Ciekawe…

      Odpytania na MsSQL (kilkaset w skali tygodnia)
      Odpytania na MsSQL (kilkadziesiąt tysięcy w skali tygodnia)
      Odpytania na PgSQL (kilka w skali tygodnia)

      Zatem szansa że jakiś automat przejedzie po PgSQL jest najmniejsza… Bo i baza mało popularna (na szczęście).

  2. @łoku: mhm, ES nie miał kontroli dosŧępu w wersji darmowej. Oczywiście każdy może położyć przed nim revproxy z httpauth i nawet pokusić się o kontrolę dostępu na tym rev. Sam tak robię. Ale do wan nie wystawiam nawet takich konstrukcji :)

Odpowiadasz na komentarz CluelessKiwi

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: