MyDr x Cybersecurity / NIS2. Studium przypadku #1

Michał Nowakowski · 13 sierpnia 2026

Studium przypadku MyDr w zderzeniu z NIS2

Emocje związane z wyciekiem wrażliwych danych są uzasadnione. Nie możemy jednak zapominać, że to dla nas solidna lekcja, z której powinniśmy wyciągnąć konkretne wnioski. Prawda jest niestety taka (smutna), że dopiero gdy obok nas wybuchnie granat zaczynamy zastanawiać się czy nie może się to wydarzyć także nam.

I dlatego pokusiłem się o "wstępne" studium przypadku związanego z MyDr zderzając to z ustawą o krajowym systemie cyberbezpieczeństwa. Nie po to, aby kogokolwiek oceniać, ale po to, abyśmy sami mogli uniknąć w przyszłości błędów. Możemy "psioczyć" na przepisy, które nakazują nam budowanie solidnych murów i fos, ale prawda jest taka - to nasze bezpieczeństwo. Nasze, naszych pracowników i klientów.

Studium podzielę na kilka części, bo to spory temat, a dodatkowo może się pojawić więcej nowych informacji. Na wstępie ważne zastrzeżenie - bazuję na informacjach zebranych w ramach OSINT, czyli na podstawie powszechnie dostępnych informacji i analiz, które wygenerowały modele AI (Fable 5 odmawia, więc pozostał Opus 4.8) i które zostały przeze mnie sprawdzone na tyle, na ile to możliwe. I jeszcze jedno - nie aspiruję do postrzegania mnie jako technicznego eksperta. Analiza skupia się na wątkach organizacyjnych, na których znam się po prostu lepiej.

Zanim przejdziemy do konkretów jeszcze ogłoszenia drobne:

ruszył newsletter, który jest dostępny na stronie - zapisy znajdziecie m.in. w prawym górnym rogu, ruszyła trzecia edycja szkolenia "Zostań AI Governance Officer'em", która odbędzie się 22 września.

Zaczniemy od profilu celu ataku... MyDr to jeden z największych krajowych dostawców systemu Elektroniczna Dokumentacja Medyczna, która jest - co tutaj istotne - regulowana odpowiednimi przepisami w zakresie informatyzacji ochrony zdrowia. Właścicielem MyDr jest ZnanyLekarz i wchodzi w skład grupy DocPlanner.

Według dostępnych informacji za pośrednictwem MyDr realizowanych jest miesięcznie ok. 3 mln wizyt i 2,7 mln recept miesięcznie. MyDr współpracuje z pokaźną liczbą gabinetów medycznych i przychodni.

MyDr zasadniczo działa nie jako administrator danych z perspektywy RODO, ale podmiot przetwarzający, czyli taki, któremu powierza się "zaopiekowanie" konkretnymi danymi w imieniu np. placówki medycznej. Kwestie związane z RODO zostawiamy jednak na razie na boku.

To co zostało prawdopodobnie pozyskane to m.in. dane osobowe (także dane wrażliwe), w tym blisko 19 mln numerów PESEL i powiązanych danych medycznych. Mowa o 2-2,5 terabajtach danych.

Atak był - prawdopodobnie - doprowadził do skompromitowania zabezpieczeń podmiotu, który przetwarzał dane i skutkował także dostępem do infrastruktury (AWS) i środowiska produkcyjnego MyDr. Innymi słowy, incydent u dostawcy doprowadził do materializacji ryzyka łańcucha dostaw u administratorów.

Z perspektywy prawnej MyDr nie miał jeszcze obowiązków wynikających z ustawy o krajowym systemie cyberbezpieczeństwa (przynajmniej w tym sensie, że terminy na dostosowanie jeszcze nie obowiązywały; to pokazuje też, że przeciąganie tego w nieskończoność jest nomen omen ryzykiem), natomiast pod nowym reżimem NIS2 będzie traktowany jako podmiot kluczowy (a może ważny), pewnie w obszarze zarządzania usługami ICT.

W konsekwencji będzie musiał stworzyć odpowiedni system zarządzania bezpieczeństwem informacji (SZBI) i spełniać konkretne wymogi i realizować konkretne działania, którym poświęcimy więcej miejsca w kolejnych edycjach.

I przejdźmy do osi czasu... Według dostępnych informacji pozyskanych m.in. od Zaufanej Trzeciej Strony, sprawy ataku poinformowali zarząd MyDR o możliwości nabycia "wyników audytu bezpieczeństwa" już 5 sierpnia. Po kilku dniach sprawy skontaktowali się z Z3S i pokazali dowody przeprowadzenia skutecznego ataku. 10 sierpnia MyDr poinformował o incydencie, a 12 sierpnia odbyło się posiedzenie Połączonego Centrum Operacyjnego Cyberbezpieczeństwa. To pokazuje skalę ataku.

Urząd Ochrony Danych Osobowych przypomniał także 12 sierpnia o obowiązkach administratorów danych (de facto gabinetów i placówek) o obowiązkach ciążących na nich w związku z wyciekiem.

No, ale właściwie co się wydarzyło? Tutaj w szczególności musimy zachować ostrożność, bo opieramy się głównie na tym co wiemy od samych sprawców. Nie mamy pewności czy wyglądało to dokładnie tak, ale spróbujmy przez to przejść.

Opracowane na podstawie bazy wiedzy własnej i Opus 4.8 oraz dostępnych informacji - w tym dostępnych od Z3S. Do ataku wykorzystano podatność w warstwie aplikacji, która pozwoliła za pośrednictwem pliku XML "zmanipulować" działanie aplikacji i wymusić przesłanie danych do nieuprawnionego użytkownika. Za pomocą tego wektora ataku udało się dostać do czegoś szalenie istotnego z perspektywy dalszych działań - sekretów (są to np. hasła, ale też klucze dostępowe interfejsów dostępowych). Atakujący mieli możliwość zdalnego wykonania kodu, a to ogromna przewaga atakującego.

W aplikacji był dostępny klucz API, który umożliwił atakującym dostęp do repozytorium kodu źródłowego (nieodpowiednio zabezpieczonego), który dał wgląd w architekturę rozwiązań i pozwolił na uzyskanie kolejnych ścieżek dostępu. W rezultacie atakującym udało się dostać do infrastruktury w AWS (chmura), gdzie sprawcy znaleźli prawdziwy skarb - cenne dane.

Ale to nie koniec. Dzięki temu dostępowi udało się dostać także do Jira czy rozwiązań do zarządzania relacjami z klientami (CRM). Można powiedzieć, że to także tajemnice przedsiębiorstwa, które powodują, że król staje się nagiutki.

Na tym całość się nie zakończyła. Po wyciągnięciu danych atakujący nie dokonali ich zaszyfrowania, ale zaproponowali "deal" w postaci wykupienia wyników audytu, co jest po prostu formą wymuszenia "okupu". Podobno sprawy komunikowali się w j. angielskim, ale istnieje wysokie prawdopodobieństwo, że jednak pochodzili z naszego kraju. To typowe działanie mające pomóc zatrzeć śladu.

Zanim przejdziemy do obowiązków "stricte" dopisanych do podmiotu kluczowego, warto spojrzeć na same podatności z perspektywy ustawy o krajowym systemie cyberbezpieczeństwa.

No to lecimy. To oczywiście wersja "orientacyjna".

Zacznijmy od tego, że punktem wyjścia jest dla nas art. 8, który zakłada, że podmiot kluczowy lub podmiot ważny wdraża system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi przez ten podmiot, zapewniający (...) i tutaj litania obowiązków. Oczywiście rozmawiamy tutaj o hipotetycznej sytuacji, bo przynajmniej w świetle NIS2.PL

Opracowane na podstawie bazy wiedzy własnej i Opus 4.8 oraz dostępnych informacji. Może zawierać drobne błędy w zakresie odniesień.

Gdybyśmy byli podmiotem kluczowym, to naszym obowiązkiem byłoby przede wszystkim odpowiednie zarządzanie ryzykiem cyberbezpieczeństwa (i bezpieczeństwa fizycznego też). Robilibyśmy to w ramach wspomnianego systemu zarządzania bezpieczeństwem informacji, który wymagałby by od nas m.in. zarządzania łańcuchem dostaw (w tym relacjami z naszymi dostawcami/podwykonawcami - pisałem o tym tutaj) czy zapewnienia bezpieczeństwa w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, w tym testowanie systemu informacyjnego. Mało tego musielibyśmy stworzyć odpowiednie mechanizmy tworzenia i wdrażania oprogramowania (sSDLC - zajrzyjcie do tego posta).

Oczywiście to nie wszystko. Jest tego trochę i oceniając to wszystko powinniśmy uwzględniać uznane standardy, jak ISO 27001/22301 czy praktyki (OWASP/MITRE - tutaj znajdziecie matrycę zagrożeń dla AI).

To co mogło nie do końca "pyknąć" (to tylko przypuszczenia, więc traktujcie to jako materiał edukacyjny) w przypadku MyDr to:

nie do końca działający sSDLC, w tym pojawi się pytanie o stosowanie testów SAST/DAST (weryfikacja pod kątem bezpieczeństwa), skuteczność i regularność testów penetracyjnych, złe zarządzanie sekretami i brak skanowania repo(zytoriów) pod kątem sekretów - tutaj z mojej praktyki mogę napisać, że platformy low/no-code do tworzenia oprogramowania dość "frywolnie" do tego podchodzą, niewłaściwe zarządzanie i wdrożenie mechanizmów MFA i SSO dla środowisk deweloperskich i możliwe słabe funkcjonowanie procesów nadawania i odbierania uprawnień, w tym IAM, pewnie mógł nie zadziałać proces monitorowania anomalii w infrastrukturze chmurowej, a także mechanizmy podejmowania działań po wykryciu incydentów, w tym odcinania dostępu i izolacji.

Wszystko to jest w mniejszym lub większym stopniu wymogiem NIS2 / uKSC. Każde działanie możemy sobie zmapować pod kątem samej ustawy, ale także wspomnianych standardów.

Co jednak istotne, to nie dokumentacja normatywna (bo może i takowa była) czy nawet operacyjna będzie decydować o skuteczności naszej ochrony i odporności. To działania, które podejmujemy lub nie. To należyta staranność decyduje o tym czy poradzimy sobie z incydentem, a może jeszcze zanim on nastąpi będziemy w stanie zadziałać.

I o tym porozmawiamy w kolejnym felietonie, który poświęcimy też kwestii środków organizacyjnych.

Do zobaczenia!