Wyciek MyDr: jak 18,8 miliona numerów PESEL trafiło w ręce przestępców i dlaczego zastrzeżenie PESEL to leczenie objawów, nie choroby

10 sierpnia 2026 roku o godzinie 18:30 serwis Zaufana Trzecia Strona opublikował informację, która w ciągu kilku dni przerodziła się w jeden z największych kryzysów bezpieczeństwa danych w historii Polski. Anonimowi sprawcy skontaktowali się z redakcją, twierdząc, że wykradli z systemów firmy MyDr bazę danych obejmującą 18 814 422 unikatowe numery PESEL, o łącznej objętości około 2,5 terabajta. Dwa dni później, 12 sierpnia, wicepremier i minister cyfryzacji Krzysztof Gawkowski potwierdził na konferencji po posiedzeniu Połączonego Centrum Operacji Cyberbezpieczeństwa, że doszło do „nadzwyczajnego wycieku danych sięgającego blisko 19 milionów obywateli polskich”. Dla porównania skali: to dane odpowiadające niemal połowie populacji Polski, wykradzione z jednego dostawcy oprogramowania medycznego, którego nazwy przed sierpniem 2026 roku prawdopodobnie nie znała większość obywateli, których dane akurat przetwarzał.

Piszę ten tekst nie tylko jako komentarz do bieżących wydarzeń, ale jako analizę z perspektywy kogoś, kto przez ponad dwadzieścia jeden lat zajmował się architekturą systemów, DevOps i bezpieczeństwem infrastruktury chmurowej, a od pewnego czasu buduje własne rozwiązanie w obszarze cyberbezpieczeństwa i governance dla systemów AI. Ten przypadek jest dla mnie modelowym studium tego, jak systemowe zaniedbania na styku prawa, biznesu i inżynierii kumulują się w katastrofę o skali krajowej, oraz jak fundamentalnie źle zaprojektowany jest sam mechanizm identyfikacji obywateli, na którym opiera się większość polskiej administracji i sektora finansowego.

Co dokładnie się stało: chronologia i skala

MyDr Sp. z o.o. jest polską firmą dostarczającą oprogramowanie do elektronicznej dokumentacji medycznej dla placówek ochrony zdrowia, z którego korzysta około 12 tysięcy przychodni i gabinetów lekarskich w całej Polsce. Firma należy do grupy Znany Lekarz. Zgodnie z ustaleniami śledczymi przekazanymi przez rzecznika Prokuratury Okręgowej w Warszawie, Piotra Antoniego Skibę, dochodzenie prowadzone przez Centralne Biuro Zwalczania Cyberprzestępczości dotyczy uzyskania przez nieustaloną osobę, nie później niż 6 sierpnia 2026 roku, bez uprawnienia, za pośrednictwem sieci internet, dostępu do całości lub części systemu informatycznego administrowanego przez MyDr, po uprzednim przełamaniu albo ominięciu informatycznych zabezpieczeń tych informacji. Sam materiał informacyjny w mediach branżowych z 9 sierpnia 2026 roku wskazuje na coś znacznie bardziej precyzyjnego: rzekomi atakujący przekazali dziennikarzom Cyberdefence24, że dostali się do systemów firmy, wykorzystując podatność typu XXE, czyli XML External Entity, w mechanizmie obsługi certyfikatów w formacie PKCS#12, co pozwoliło im na zdalne wykonanie kodu, a następnie pozyskali klucz API do repozytorium GitHub, gdzie znaleźli kod źródłowy serwisu. To jest fragment tej historii, który powinien wzbudzić najwięcej niepokoju u każdego inżyniera odpowiedzialnego za bezpieczeństwo systemów przetwarzających dane wrażliwe, ponieważ opisuje klasyczny, dobrze znany od dekady w środowisku bezpieczeństwa łańcuch błędów: podatność w parsowaniu XML w module obsługi certyfikatów, prowadząca do zdalnego wykonania kodu, prowadząca do przejęcia sekretu uwierzytelniającego (klucza API), prowadząca do dostępu do repozytorium kodu źródłowego, a stamtąd, jak można się domyślać na podstawie skali wycieku, do dalszej eskalacji uprawnień w środowisku produkcyjnym.

Ważne zastrzeżenie metodologiczne: informacja o konkretnym wektorze ataku (podatność XXE w obsłudze PKCS#12) pochodzi z deklaracji samych, rzekomych sprawców przekazanej dziennikarzom, a nie z oficjalnego, technicznego raportu post-incydentalnego opublikowanego przez MyDr, CERT Polska czy prokuraturę. Żadna z dotychczasowych publicznych informacji od strony rządowej czy samej firmy nie potwierdziła lub zaprzeczyła tej wersji technicznej w sposób szczegółowy, co jest typowe dla wczesnej fazy takich incydentów, gdy pełny raport techniczny (tak zwany post-mortem) pojawia się zwykle po zakończeniu śledztwa i wewnętrznego audytu, jeśli w ogóle zostaje upublicznony w Polsce, co samo w sobie jest osobnym problemem systemowym, o którym piszę w dalszej części tekstu.

Skala rozbieżności między deklaracjami przestępców a komunikatami rządowymi jest sama w sobie interesująca poznawczo. Sprawcy podają liczbę bardzo precyzyjną: 18 814 422 unikatowe numery PESEL i około 2,5 terabajta danych. Ministerstwo Cyfryzacji mówi o „blisko 19 milionach obywateli” i „ponad 2 terabajtach danych”, czyli liczbie zaokrąglonej i nieco zachowawczej. Ta różnica nie jest przypadkowa: przestępcy, którzy faktycznie mają dostęp do bazy danych, mogą podać dokładną liczbę unikatowych rekordów wynikającą z zapytania SQL typu COUNT DISTINCT, podczas gdy strona rządowa opiera swoje szacunki na informacjach przekazanych przez samą firmę MyDr, która w chwili pisania tego tekstu wciąż prowadzi postępowanie wyjaśniające i deklaruje, że nie jest w stanie precyzyjnie określić zakresu wycieku.

Zakres skradzionych danych obejmuje imiona i nazwiska, numery PESEL, numery telefonów, adresy e-mail, region NFZ, numery i treść wystawionych recept, informacje o skierowaniach, historię wizyt lekarskich, a w niektórych przypadkach treść notatek z wizyt dotyczących przebiegu leczenia i schorzeń pacjenta. To jest kategoria danych, którą RODO klasyfikuje jako dane szczególnej kategorii, czyli dane o stanie zdrowia, podlegające najwyższemu poziomowi ochrony prawnej w całym unijnym systemie ochrony danych osobowych, właśnie z powodu potencjału do wykorzystania w wymuszeniach, dyskryminacji czy szantażu.

Firma MyDr potwierdziła atak z opóźnieniem względem pierwszych doniesień medialnych, wydając oświadczenie 12 sierpnia 2026 roku, dwa dni po tym, jak sprawa trafiła do Zaufanej Trzeciej Strony, i dopiero po tym, jak minister cyfryzacji publicznie potwierdził skalę incydentu na antenie Onetu. W oświadczeniu firma określiła atak jako „zewnętrzne, celowe działanie o charakterze przestępczym”, zastrzegając jednocześnie, że dane objęte incydentem mają najprawdopodobniej charakter archiwalny, pochodzą głównie z 2024 roku i lat wcześniejszych, oraz mogą nie obejmować wszystkich klientów firmy ani wszystkich ich pacjentów. Firma zapewniła również, że jej systemy są w pełni operacyjne i bezpieczne w użyciu, że partnerzy zajmujący się cyberbezpieczeństwem aktywnie monitorują dark web i na moment publikacji komunikatu nie znaleźli dowodów na to, że dane zostały opublikowane lub udostępnione publicznie, oraz że klienci firmy nie muszą obecnie podejmować żadnych działań.

Co istotne, minister Gawkowski dostarczył jeden konkretny, mocny dowód na autentyczność deklaracji przestępców: poinformował, że atakujący, chcąc udowodnić, że faktycznie dysponują skradzioną bazą, przesłali dane jednego z ważnych polskich polityków, w tym jego numer PESEL oraz informacje o wystawionych mu receptach. To jest szczegół, który przecina spekulacje o tym, czy cały incydent może być mistyfikacją albo przesadzoną deklaracją grupy przestępczej chcącej wywołać panikę bez realnych danych w tle. Rząd potwierdził też, że motywacja przestępców ma charakter finansowy, nie polityczny, że nie doszło do naruszenia bezpośrednio państwowego systemu P1 (czyli centralnego systemu e-zdrowia), oraz że obecnie nic nie wskazuje, aby atak został przeprowadzony spoza granic Polski. Śledczy prowadzą postępowanie w kierunku wymuszenia okupu (ransomware/extortion), a nie w kierunku działania obcych służb wywiadowczych.

Dlaczego ten wyciek jest inny niż poprzednie

Polska miała już wcześniej do czynienia z poważnymi wyciekami danych medycznych, w tym z incydentem dotyczącym laboratorium ALAB, do którego niebezpiecznik.pl odnosi się bezpośrednio w swoim komentarzu z 17 sierpnia 2026 roku, przypominając, że część rekomendacji dotyczących postępowania po wycieku była już wcześniej udzielana właśnie po tamtym incydencie. Co odróżnia wyciek MyDr od poprzednich przypadków, to skala: 18,8 miliona unikatowych numerów PESEL to według deklaracji sprawców dane obejmujące niemal połowę populacji Polski, przekraczające pod względem liczby poszkodowanych każdy wcześniejszy, publicznie znany incydent w kraju.

Drugą cechą wyróżniającą jest struktura biznesowa samej firmy MyDr, na którą niebezpiecznik.pl zwrócił uwagę w bardzo ostrym, krytycznym tonie w komentarzach czytelników pod swoim artykułem z 17 sierpnia 2026 roku, wskazując, że MyDr Sp. z o.o. działa z kapitałem założycielskim rzędu 5600 złotych, będąc w całości zależną od zagranicznego, holenderskiego podmiotu, który z kolei jest powiązany kapitałowo z bankiem inwestycyjnym Goldman Sachs, a w prospekcie emisyjnym firmy związanym z planowanym IPO zawarto informację o zamiarze wykorzystania danych medycznych pacjentów do trenowania modeli sztucznej inteligencji. Ten komentarz, choć sformułowany emocjonalnie, trafia w rdzeń problemu systemowego: dane medyczne milionów Polaków, podlegające najwyższej ochronie prawnej w całej Unii Europejskiej, trafiają w praktyce do prywatnych podmiotów o relatywnie niewielkim kapitale rejestrowym, powiązanych kapitałowo z zagranicznymi funduszami, w modelu biznesowym, w którym same dane pacjentów stają się z czasem aktywem o wartości komercyjnej wykraczającej poza pierwotny cel ich zbierania.

Warto przy tym zachować precyzję faktograficzną: nie jest to sytuacja, w której państwo scentralizowało dane medyczne i przekazało je jednemu prywatnemu podmiotowi. Jak trafnie zauważył jeden z komentujących pod tekstem niebezpiecznika, dane trafiły do MyDr niezależnie, z inicjatywy blisko 20 tysięcy poszczególnych przychodni i gabinetów lekarskich, z których każdy podjął własną, indywidualną decyzję o wyborze dostawcy oprogramowania do zarządzania dokumentacją medyczną. To odzwierciedla szerszy, systemowy problem polskiego rynku usług cyfrowych dla sektora ochrony zdrowia: małe i średnie placówki medyczne, nieposiadające własnych zasobów informatycznych ani kompetencji do budowy i utrzymania bezpiecznego systemu zarządzania danymi, w naturalny sposób kupują gotowe rozwiązania od wyspecjalizowanych dostawców takich jak MyDr, co samo w sobie jest racjonalną decyzją biznesową, ale prowadzi do koncentracji ryzyka: skoro tysiące niezależnych placówek korzysta z jednego dostawcy, każdy pojedynczy błąd w zabezpieczeniach tego dostawcy natychmiast staje się błędem systemowym o skali obejmującej całą populację pacjentów tych placówek.

Reakcja państwa: Bezpieczne Dane, zastrzeżenie PESEL i granice tego rozwiązania

Główną, konkretną rekomendacją rządu dla obywateli, powtarzaną przez ministra Gawkowskiego przy każdej okazji medialnej od 10 sierpnia 2026 roku, jest zastrzeżenie numeru PESEL w aplikacji mObywatel, w serwisie mObywatel.gov.pl, osobiście w urzędzie gminy lub w placówce banku. Minister podkreślał, że cała procedura zajmuje w aplikacji około pięciu sekund i nazwał to „podstawową, elementarną higieną cyfrową”. Drugim elementem odpowiedzi instytucjonalnej jest rządowy portal Bezpieczne Dane, dostępny pod adresem bezpiecznedane.gov.pl, do którego po zalogowaniu profilem zaufanym obywatel może sprawdzić, czy jego dane figurują w zgłoszonych incydentach bezpieczeństwa. Warto jednak odnotować istotne zastrzeżenie faktograficzne: w dniu publikacji pierwszych doniesień o wycieku serwis Bezpieczne Dane był przez dłuższy czas niedostępny, a dane związane konkretnie z incydentem MyDr nie zasiliły jeszcze bazy tego serwisu w chwili, gdy powstawały pierwsze relacje medialne. Minister Gawkowski zapowiedział, że dane trafią do systemu sukcesywnie, dopiero po tym, jak firma MyDr faktycznie odtworzy i uporządkuje pełny zakres skradzionych rekordów, co według deklaracji z 13 sierpnia 2026 roku wciąż było w toku.

Zastrzeżenie numeru PESEL, choć jest realnym i wartym wykonania krokiem, chroni przed konkretnym, ograniczonym zestawem zagrożeń: uniemożliwia zawarcie umowy kredytowej, umowy pożyczki, wykonanie duplikatu karty SIM, wypłatę środków z konta bankowego w placówce oraz podpisanie aktu notarialnego na dane zastrzeżonego numeru PESEL bez jego wcześniejszego odblokowania. Nie chroni ono jednak przed całym spektrum ryzyk wynikających z wycieku danych medycznych. Radczyni prawna cytowana przez „Rzeczpospolitą” podkreśla, że zastrzeżenie PESEL powinno być tylko jednym z pierwszych kroków, po którym powinna nastąpić zmiana zagrożonych haseł oraz miesiące wzmożonej czujności na próby phishingu i podszywania się pod zaufane instytucje, ponieważ tego rodzaju wyciek daje przestępcom materiał do przygotowania wiarygodnie wyglądających, spersonalizowanych wiadomości wykorzystujących realne dane o przebytych wizytach, przepisanych lekach czy nazwie placówki medycznej, w której pacjent się leczył.

Krytyczny głos niebezpiecznika w tej sprawie, który cytuję w pełnej rzetelności, wskazuje na poważny, praktyczny problem z samą ideą powszechnego, odgórnego zastrzegania numeru PESEL, o czym minister Gawkowski wspomniał jako o rozważanej opcji w wywiadzie dla Polsat News z 13 sierpnia 2026 roku, mówiąc, że rząd rozważa odgórne zastrzeganie numerów PESEL, żeby wspomóc osoby cyfrowo wykluczone. Niebezpiecznik zwraca uwagę, że mechaniczne, odgórne zastrzeżenie PESEL wszystkim obywatelom nie może zostać po prostu narzucone, ponieważ dotyczy również osób, które nie korzystają z aplikacji mObywatel i mają znacząco ograniczony, praktyczny dostęp do urzędu, gdzie musiałyby to zastrzeżenie odwołać w razie potrzeby, na przykład przy zaciąganiu legalnego kredytu. Cytując dane Głównego Urzędu Statystycznego z 2024 roku, przywołane w dyskusji pod artykułem niebezpiecznika, tylko 61 procent osób w przedziale wiekowym 16 do 74 lat korzystało z usług e-administracji, a wśród osób w wieku 55 do 64 lat zmianę ustawień elektronicznych potrafiło samodzielnie wykonać tylko 25,5 procent, a w grupie 65 do 74 lat odsetek ten spadał do 10,1 procent. To jest realny, praktyczny problem inkluzji cyfrowej, który każda odgórna, powszechna reforma dotycząca PESEL musi rozwiązać, zanim zostanie wdrożona, a nie po fakcie.

Drugi, techniczny problem z zastrzeżeniem PESEL, na który zwraca uwagę dyskusja na niebezpieczniku, dotyczy przenoszenia numeru telefonu między operatorami. Obowiązek weryfikacji zastrzeżenia PESEL dotyczy w polskim prawie telekomunikacyjnym wyłącznie procedury wydania duplikatu karty SIM u tego samego operatora, na podstawie art. 297 ustawy Prawo komunikacji elektronicznej, a nie procedury przeniesienia numeru do innego operatora w ramach nowej umowy, co w praktyce oznacza, że osoba mająca zastrzeżony PESEL wciąż teoretycznie może stać się ofiarą przejęcia numeru telefonu metodą przeniesienia numeru (port-out) do konkurencyjnego operatora, jeśli przestępca dysponuje sfałszowanym dokumentem identyfikacyjnym ofiary. To jest szczegół techniczny, którego nie usłyszy się w oficjalnych komunikatach rządowych zachęcających do zastrzegania PESEL, a który każdy poważny materiał edukacyjny o cyberbezpieczeństwie powinien uwzględniać.

Konsekwencje prawne i finansowe dla ekosystemu ochrony zdrowia

„Rzeczpospolita” w analizie z 12 sierpnia 2026 roku zwraca uwagę na poważne konsekwencje prawne wykraczające poza samą firmę MyDr: kary administracyjne i roszczenia odszkodowawcze mogą dotknąć również tysiące przychodni korzystających z jej systemu, ponieważ to te placówki, jako administratorzy danych osobowych swoich pacjentów w rozumieniu RODO, ponoszą pierwotną odpowiedzialność za wybór odpowiednio zabezpieczonego procesora danych, a MyDr działała w tym modelu jako podmiot przetwarzający na ich zlecenie. Urząd Ochrony Danych Osobowych wskazał wprost, że obowiązek powiadomienia osób poszkodowanych incydentem spoczywa na administratorach, czyli na poszczególnych placówkach medycznych korzystających z usług MyDr, nie na samej spółce MyDr jako procesorze. To oznacza w praktyce, że 12 tysięcy niezależnych przychodni w całej Polsce stoi teraz przed obowiązkiem prawnym powiadomienia własnych pacjentów o wycieku, którego same nie spowodowały i nad którego przyczyną techniczną nie miały bezpośredniej kontroli, co jest kolejnym dowodem na to, jak fundamentalnie nieproporcjonalna jest struktura odpowiedzialności prawnej względem struktury faktycznej kontroli nad bezpieczeństwem systemu w modelu outsourcingu usług IT do jednego, centralnego dostawcy.

UODO rozpoczęło formalną kontrolę w tej sprawie. Śledztwo prowadzi Centralne Biuro Zwalczania Cyberprzestępczości pod nadzorem Prokuratury Okręgowej w Warszawie, a zarzuty w toku postępowania dotyczą nieuprawnionego dostępu do systemu informatycznego po przełamaniu zabezpieczeń oraz nieuprawnionego przetwarzania danych osobowych, w tym danych o stanie zdrowia, poprzez ich przekazanie przez sprawców do redakcji Zaufanej Trzeciej Strony. Wicepremier Gawkowski zapowiedział 13 sierpnia 2026 roku, że nie wyklucza wprowadzenia zmian w prawie po pełnej analizie incydentu, choć na tym etapie nie sprecyzował, jakiego konkretnie obszaru prawa miałyby dotyczyć te zmiany.

Dlaczego PESEL jako mechanizm identyfikacyjny jest architektonicznie przestarzały

W tym miejscu chcę przejść od relacjonowania faktów do własnej, eksperckiej oceny problemu, opartej na dwudziestu jeden latach pracy z architekturą systemów i infrastrukturą bezpieczeństwa. Numer PESEL, wprowadzony w Polsce w 1979 roku, został zaprojektowany w epoce, w której nie istniało pojęcie masowego, cyfrowego wycieku danych, ani ryzyka związanego z automatyzowanym, algorytmicznym wykorzystaniem tożsamości na skalę milionów rekordów jednocześnie. PESEL jest numerem statycznym, przypisanym raz na całe życie, zawierającym w swojej strukturze zakodowaną datę urodzenia i płeć osoby, co samo w sobie jest fundamentalnym błędem projektowym z perspektywy współczesnego bezpieczeństwa informacji: identyfikator, który miał funkcjonować jako sekret uwierzytelniający w praktyce funkcjonuje jako publicznie znany, statyczny, niemożliwy do zresetowania klucz dostępu do tożsamości obywatela, wpisywany rutynowo w setki formularzy papierowych i cyfrowych przez całe życie tej osoby.

Problem architektoniczny sprowadza się do jednej, fundamentalnej wady projektowej: PESEL łączy w sobie dwie zupełnie odrębne funkcje, które w dobrze zaprojektowanym systemie bezpieczeństwa powinny być rozdzielone. Pierwsza funkcja to identyfikator, czyli publiczny numer referencyjny pozwalający jednoznacznie wskazać konkretną osobę w bazie danych, analogiczny do klucza głównego w relacyjnej bazie danych. Druga funkcja to, w praktyce stosowanej przez banki, operatorów telekomunikacyjnych i wiele innych instytucji, quasi-uwierzytelnienie, czyli traktowanie samej znajomości numeru PESEL jako dowodu, że osoba podająca ten numer jest faktycznie tą osobą, do której numer jest przypisany. To jest błąd koncepcyjny identyczny z tym, jaki przez dekady popełniano w systemach bezpieczeństwa IT, traktując numer karty kredytowej czy adres e-mail jednocześnie jako identyfikator i jako sekret autoryzacyjny, aż branża finansowa i technologiczna nauczyła się bolesną drogą, że te dwie funkcje trzeba rozdzielić, wprowadzając kody CVV, uwierzytelnianie dwuczynnikowe i tokenizację.

Zastrzeżenie PESEL, jako mechanizm wprowadzony w Polsce w 2023 roku, jest w istocie łataniem tego fundamentalnego błędu architektonicznego łatką proceduralną, nie naprawą samej architektury. Działa na tej samej logice, co blokada karty kredytowej po jej zgubieniu: chroni przed konkretnym zastosowaniem numeru w konkretnych, z góry określonych procesach (kredyt, duplikat SIM, wypłata gotówki, akt notarialny), ale nie zmienia faktu, że sam numer PESEL wciąż pozostaje statycznym, nieusuwalnym z systemu, publicznie kompromitowanym identyfikatorem, którego znajomość wciąż otwiera drzwi do wielu innych procesów, nieobjętych zakresem zastrzeżenia, takich jak rejestracja w placówce medycznej, o czym zresztą wprost wspominają komentujący pod artykułem niebezpiecznika, zwracając uwagę na praktyczny problem pacjenta, który nie może się w gabinecie lekarskim „przedstawić jako Jan Kowalski”.

Koncepcja, którą uważam za realną alternatywę: rotacyjny, kontekstowy identyfikator tożsamości

Jako ktoś budujący obecnie infrastrukturę dowodową i governance dla systemów przetwarzających dane wysokiego ryzyka, proponuję spojrzeć na problem PESEL nie przez pryzmat łatania kolejnymi mechanizmami proceduralnymi istniejącego, wadliwego numeru statycznego, lecz przez pryzmat architektury, jaką dziś stosuje się w bezpiecznych systemach płatniczych i w zarządzaniu tożsamością cyfrową w najbardziej zaawansowanych wdrożeniach na świecie: tokenizacji kontekstowej.

Koncepcja, którą przedstawiam poniżej, nie jest gotowym projektem legislacyjnym, lecz architektonicznym szkicem tego, jak mogłaby wyglądać modernizacja systemu identyfikacji obywateli w Polsce, oparta na wzorcach już sprawdzonych w innych domenach bezpieczeństwa. Zamiast jednego, statycznego numeru PESEL używanego identycznie w banku, u lekarza, u operatora telekomunikacyjnego i w urzędzie, system oparty na tokenizacji kontekstowej przypisywałby obywatelowi jeden, niezmienny, chroniony identyfikator główny, przechowywany wyłącznie w rejestrze państwowym i nigdy nieudostępniany podmiotom trzecim w postaci jawnej, natomiast każda instytucja korzystająca z identyfikacji obywatela, bank, przychodnia, operator telekomunikacyjny, otrzymywałaby unikalny, matematycznie powiązany z identyfikatorem głównym, ale niemożliwy do odwrócenia bez dostępu do rejestru państwowego, token kontekstowy, analogiczny do mechanizmu tokenizacji numerów kart płatniczych stosowanego dziś powszechnie w systemach Apple Pay czy Google Pay.

W praktyce oznaczałoby to, że wyciek bazy danych z jednej przychodni czy jednego banku ujawniałby jedynie token użyteczny wyłącznie w kontekście tej konkretnej instytucji, bezużyteczny dla przestępcy próbującego wykorzystać go w banku, u innego operatora czy w innej przychodni, ponieważ każdy z tych podmiotów otrzymałby zupełnie inny token, matematycznie niepowiązany z tokenami wydanymi innym instytucjom bez dostępu do centralnego rejestru rządowego dokonującego przeliczenia. Dodatkowym mechanizmem, który uważam za konieczny w takiej architekturze, jest rotacja tokenów kontekstowych w określonych odstępach czasu lub na żądanie obywatela, analogicznie do mechanizmu wygasania i odnawiania tokenów sesyjnych w bezpiecznych systemach uwierzytelniania, co dodatkowo ograniczałoby wartość skradzionego tokena w czasie, nawet gdyby doszło do wycieku konkretnej instytucji.

Rozumiem w pełni, że wdrożenie takiej architektury na poziomie całego państwa jest przedsięwzięciem o skali porównywalnej z pełną cyfrową przebudową rejestrów państwowych, wymagającym lat pracy, ogromnych inwestycji i głębokiej reformy prawa administracyjnego regulującego wymianę danych między instytucjami. Nie proponuję tego jako rozwiązania na następny kwartał. Proponuję to jako kierunek strategiczny, w stronę którego Polska powinna świadomie iść, zamiast kontynuować model łatania kolejnych, punktowych mechanizmów proceduralnych, takich jak zastrzeżenie PESEL, nałożonych na fundamentalnie przestarzałą architekturę identyfikacji z 1979 roku, w świecie, w którym skala i częstotliwość wycieków danych rośnie w tempie wykładniczym, a nie liniowym.

Co powinno się stać już teraz, niezależnie od reformy architektonicznej

Do czasu, gdy taka fundamentalna reforma architektoniczna stanie się realną możliwością polityczną, uważam za konieczne wdrożenie kilku konkretnych, znacznie prostszych w realizacji mechanizmów, które adresują najbardziej dotkliwe słabości ujawnione przez incydent MyDr. Pierwszym jest obowiązek publikacji pełnego, technicznego raportu post-incydentalnego przez każdy podmiot przetwarzający dane wysokiego ryzyka po zakończeniu śledztwa, na wzór praktyki stosowanej w sektorze lotniczym po każdej katastrofie, ponieważ dziś branża technologiczna w Polsce systemowo nie dzieli się szczegółami technicznymi swoich incydentów bezpieczeństwa, co uniemożliwia innym firmom uczenie się na cudzych błędach i systemowo powtarza te same klasy podatności, takie jak podatności XXE znane od ponad dekady w środowisku bezpieczeństwa aplikacji webowych. Drugim jest wprowadzenie realnej, proporcjonalnej do przychodów, a nie do kapitału zakładowego, struktury kar administracyjnych za naruszenia bezpieczeństwa danych wysokiego ryzyka, adresującej wprost problem podniesiony w dyskusji publicznej, w którym mała spółka o niskim kapitale rejestrowym może w praktyce ponieść karę niewspółmiernie niską względem realnej szkody wyrządzonej milionom obywateli. Trzecim jest wprowadzenie obowiązkowego, regularnego audytu bezpieczeństwa przeprowadzanego przez niezależny podmiot trzeci dla każdego dostawcy oprogramowania obsługującego więcej niż określony próg placówek medycznych czy klientów instytucjonalnych, proporcjonalnie do skali ryzyka systemowego, jakie generuje koncentracja danych milionów obywateli w rękach jednego, prywatnego dostawcy technologicznego.

Ten wyciek nie jest anomalią, którą można rozwiązać jednorazową akcją zastrzegania numerów PESEL przez dwadzieścia milionów Polaków. Jest symptomem znacznie głębszego problemu architektonicznego, obejmującego jednocześnie przestarzały mechanizm identyfikacji obywateli, systemową koncentrację ryzyka w rękach niedofinansowanych, prywatnych dostawców IT dla sektora publicznego, oraz brak kultury transparentnego, technicznego raportowania incydentów bezpieczeństwa w polskim ekosystemie technologicznym. Rozwiązanie tego problemu wymaga myślenia infrastrukturalnego, nie proceduralnego, a to jest właśnie różnica, którą staram się konsekwentnie promować w każdym projekcie, który buduję.