Paszporty, numery PESEL i dane o zdrowiu dostępne dla innych użytkowników. Czego uczy incydent w Łódzkiem?

Błąd w łódzkim systemie stypendialnym pozwalał zalogowanym osobom pobierać cudze dokumenty. Sprawdzamy, czego może nauczyć się każdy urząd.

Zalogowanie do urzędowego systemu nie gwarantuje bezpieczeństwa, jeżeli aplikacja nie sprawdza, czy dana osoba ma prawo zobaczyć konkretny plik. W systemie stypendialnym Województwa Łódzkiego taki błąd umożliwiał użytkownikom otwieranie i pobieranie dokumentów innych osób. Wśród plików, do których uzyskano dostęp, były między innymi skany paszportów, zaświadczenia o numerze PESEL, dokumenty medyczne i orzeczenia o niepełnosprawności.

To nie była klasyczna publikacja niezanonimizowanego dokumentu w BIP. Dla samorządów płynie z tej sprawy równie ważna lekcja: dokument z danymi osobowymi trzeba chronić od momentu wpływu do urzędu aż po jego archiwizację, udostępnienie lub publikację.

Co wydarzyło się w łódzkim systemie stypendialnym?

8 września 2026 roku na stronie programu „Młodzi Zawodowcy” opublikowano komunikat o incydencie bezpieczeństwa IT. Program jest realizowany przez Województwo Łódzkie, a stroną zarządza Urząd Marszałkowski Województwa Łódzkiego.

Z komunikatu wynika, że aplikacja nie weryfikowała, czy zalogowany użytkownik ma uprawnienia do wskazanego dokumentu. Osoba, która rozpoznała sposób budowania adresów do plików, mogła otworzyć i pobrać dokument należący do innego użytkownika.

Analiza potwierdziła, że 4 i 5 czerwca 2026 roku dwie osoby pobrały dokumenty, które ich nie dotyczyły. 8 czerwca zgłosiły problem nauczycielom, dyrektorowi szkoły oraz inspektorowi ochrony danych. Według oświadczeń przekazanych administratorowi pliki zostały usunięte i nie były dalej udostępniane.

System wyłączono, a dostawca zadeklarował usunięcie błędu. Po ponownym uruchomieniu podobna podatność została jednak zgłoszona 23 lipca. Późniejsza analiza wykazała, że pierwsza poprawka nie usunęła przyczyny problemu. System ponownie wyłączono z publicznego dostępu.

Jakie dokumenty i dane były zagrożone?

Według oficjalnego komunikatu nie można odtworzyć pełnego zakresu incydentu, ponieważ system nie rejestrował wszystkich operacji pobierania dokumentów, a dostępne logi obejmowały tylko część okresu jego działania.

Eksperci ustalili jednak kategorie dokumentów, które z pewnością pobrano. Były to między innymi:

Zdarzenie dotyczyło przede wszystkim uczniów i ich opiekunów. W dokumentach mogły znajdować się także informacje o sytuacji rodzinnej i materialnej. W przypadku nauczycieli zagrożone były między innymi dane identyfikacyjne, kontaktowe, miejsce zatrudnienia i informacja o pełnieniu funkcji opiekuna ucznia w projekcie.

Administrator ocenił prawdopodobieństwo nieuprawnionego wykorzystania danych jako niskie, ale jednocześnie uznał, że samo zdarzenie wiąże się z wysokim ryzykiem naruszenia praw i wolności. Incydent zgłoszono Prezesowi UODO oraz CERT Polska.

Zalogowany nie znaczy uprawniony

Mechanizm opisany w komunikacie przypomina podatność określaną jako IDOR — niebezpieczne bezpośrednie odwołanie do obiektu. W praktyce użytkownik jest poprawnie zalogowany, lecz system nie sprawdza przy każdym żądaniu, czy wolno mu pobrać wskazany plik.

Przykład: adres jednego dokumentu kończy się identyfikatorem 101. Po zmianie tej liczby na 102 aplikacja nie powinna wyświetlić cudzego dokumentu. Musi sprawdzić uprawnienia po stronie serwera i odmówić dostępu, niezależnie od tego, czy użytkownik zna lub odgadł adres pliku.

CERT Polska w materiale o nieprawidłowej kontroli dostępu zaleca między innymi weryfikowanie uprawnień do każdego zasobu, stosowanie zasady najmniejszych uprawnień, domyślne odmawianie dostępu oraz rejestrowanie prób dostępu w logach bezpieczeństwa.

Trzy warstwy ochrony dokumentów

Sprawa pokazuje, że bezpieczeństwa dokumentów nie można sprowadzić do jednego narzędzia lub jednego etapu kontroli.

1. Kontrola dostępu

System powinien sprawdzać nie tylko to, czy użytkownik jest zalogowany, lecz także czy może wykonać konkretną operację na konkretnym pliku. Uprawnienia należy egzekwować po stronie serwera przy każdym otwarciu, pobraniu, podglądzie lub eksporcie.

2. Rejestrowanie operacji

Logi pozwalają ustalić, kto, kiedy i do jakiego dokumentu uzyskał dostęp. Bez pełnej historii pobrań administrator może nie być w stanie wiarygodnie określić liczby osób objętych naruszeniem ani zakresu ujawnionych danych. W tym przypadku właśnie brak pełnych zapisów technicznych utrudnił odtworzenie zdarzenia.

3. Minimalizacja i anonimizacja

System nie powinien gromadzić kopii dokumentów ani zakresu danych szerszego, niż wymaga tego cel postępowania. Gdy dokument ma zostać udostępniony poza pierwotnym procesem — na przykład opublikowany w BIP, przekazany w odpowiedzi na wniosek lub wykorzystany do konsultacji — warto przygotować jego odrębną, trwale zanonimizowaną wersję.

Anonimizacja nie naprawi błędnej kontroli dostępu. Może jednak ograniczyć skutki pomyłki na etapie późniejszego udostępniania dokumentu. Te zabezpieczenia uzupełniają się, a nie zastępują.

Co urząd powinien sprawdzić po tej sprawie?

Warto przejrzeć nie tylko systemy dostępne publicznie, ale również portale mieszkańca, platformy naborowe, systemy stypendialne i repozytoria dokumentów dla pracowników oraz podmiotów zewnętrznych.

Krótka lista kontrolna:

  1. Czy uprawnienia są sprawdzane po stronie serwera dla każdego dokumentu i każdej operacji?
  2. Czy zmiana identyfikatora w adresie lub żądaniu może prowadzić do cudzego pliku?
  3. Czy system zapisuje otwarcia, podglądy, pobrania, eksporty i nieudane próby dostępu?
  4. Czy wiadomo, jak długo przechowywane są logi i kto może je analizować?
  5. Czy po wdrożeniu poprawki wykonuje się niezależny test potwierdzający usunięcie przyczyny błędu?
  6. Czy urząd rzeczywiście potrzebuje pełnych skanów paszportów, orzeczeń i zaświadczeń, czy wystarczy weryfikacja wybranych informacji?
  7. Czy przed udostępnieniem lub publikacją dokument przechodzi kontrolę danych osobowych, również w warstwie tekstowej, metadanych i załącznikach?

Co zrobić po wykryciu podobnego incydentu?

Pierwszym krokiem powinno być ograniczenie dalszego dostępu i zabezpieczenie dostępnych logów. Następnie trzeba ustalić rodzaje dokumentów, kategorie danych, możliwe osoby odbierające oraz okres działania podatności. Do oceny zdarzenia należy od początku włączyć inspektora ochrony danych i zespół odpowiedzialny za bezpieczeństwo IT.

Administrator powinien udokumentować analizę ryzyka oraz ocenić obowiązki dotyczące zgłoszenia naruszenia organowi nadzorczemu i zawiadomienia osób, których dane dotyczą. Jeżeli za system odpowiada dostawca, nie warto poprzestawać na jego deklaracji, że błąd został poprawiony — potrzebny jest test potwierdzający, że zamknięto rzeczywistą przyczynę podatności.

Więcej o pierwszych krokach po ujawnieniu danych piszemy w artykule Dane trafiły do BIP bez anonimizacji. Co urząd powinien zrobić?.

Wniosek: dokument trzeba chronić przez cały jego cykl życia

Incydent w łódzkim systemie stypendialnym nie wynikał z publikacji źle zanonimizowanego PDF-u. Wynikał z tego, że aplikacja wydawała pliki osobom, które nie powinny ich otrzymać. Skutek dotyczył jednak dokładnie tego samego dobra: poufności danych zapisanych w dokumentach.

Dla samorządu bezpieczny proces oznacza więc jednocześnie właściwe uprawnienia, pełne logowanie operacji, ograniczenie zakresu zbieranych danych i przygotowywanie bezpiecznych kopii do udostępnienia. Dopiero połączenie tych elementów zmniejsza ryzyko, że dokument trafi do niewłaściwej osoby albo zostanie opublikowany z informacjami, które powinny pozostać chronione.

Redakt wspiera etap przygotowania dokumentu do bezpiecznego udostępnienia lub publikacji: pomaga wykrywać dane osobowe i tworzyć trwale zanonimizowane wersje plików. Nie zastępuje kontroli dostępu, audytu bezpieczeństwa ani oceny inspektora ochrony danych — uzupełnia je tam, gdzie urząd musi udostępnić treść bez ujawniania nadmiarowych informacji. Wypróbuj Redakt na własnym dokumencie.

Materiał ma charakter informacyjny i nie stanowi porady prawnej. Każde naruszenie należy oceniać indywidualnie z udziałem inspektora ochrony danych.

Najczęstsze pytania

Czy w łódzkim systemie potwierdzono pobranie cudzych dokumentów?

Tak. Oficjalny komunikat potwierdza, że dwie osoby pobrały dokumenty innych użytkowników 4 i 5 czerwca 2026 roku. Osoby te same zgłosiły błąd i oświadczyły, że usunęły pliki oraz ich nie rozpowszechniały. Nie znaleziono dowodów na wykorzystanie błędu przez inne osoby, ale z powodu niepełnych logów nie można tego całkowicie wykluczyć.

Jakie dane mogły zostać ujawnione?

Wśród potwierdzonych kategorii dokumentów były skany paszportów, zaświadczenia o numerze PESEL, orzeczenia o niepełnosprawności, zaświadczenia lekarskie, świadectwa szkolne, Karty Dużej Rodziny, wnioski stypendialne oraz urzędowe oceny wniosków.

Czy była to błędna anonimizacja dokumentów?

Nie. Opisany incydent wynikał z niewłaściwej kontroli dostępu w aplikacji. Anonimizacja jest osobnym zabezpieczeniem stosowanym wtedy, gdy treść dokumentu ma zostać udostępniona bez części danych osobowych.

Czy samo logowanie chroni dokumenty przed nieuprawnionym dostępem?

Nie. Po zalogowaniu system nadal musi sprawdzać, czy użytkownik ma prawo do konkretnego dokumentu i konkretnej operacji. Samo posiadanie konta nie może otwierać dostępu do zasobów innych osób.

Źródła

Przetestuj anonimizację w systemie Redakt

Redakt to aplikacja internetowa MWC do anonimizacji PDF i skanów. AI wskazuje dane do sprawdzenia, a po Twoim zatwierdzeniu system trwale usuwa wybrane treści z dokumentu.

Wypróbuj Redakt bezpłatnie Poznaj funkcje systemu

Powiązane publikacje

Wróć do publikacji

Producent: MWC Sp. z o.o., ul. Kowalewicka 12, 60-002 Poznań, NIP 7831678932. Kontakt: info@mwc.pl.