Cyberbezpieczeństwo polskiej ochrony zdrowia pod presją.
Sektor ochrony zdrowia stał się jednym z najbardziej atrakcyjnych celów dla cyberprzestępców. Powód jest prosty: systemy medyczne przechowują ogromne ilości informacji, których wartość jest znacznie większa niż typowych danych wykorzystywanych w handlu elektronicznym.
Imię i nazwisko, numer PESEL, adres, telefon czy adres e-mail to dopiero początek. Dokumentacja medyczna może zawierać informacje o chorobach, diagnozach, lekach, receptach, wynikach badań, zabiegach, zdrowiu psychicznym czy historii leczenia.
Ostatnie tygodnie pokazały, że zagrożenie nie jest już wyłącznie hipotetyczne. W Polsce doszło do kilku poważnych incydentów związanych z dostawcami oprogramowania medycznego i podmiotami ochrony zdrowia. Największym i najlepiej udokumentowanym przykładem jest sprawa MyDr, a we wrześniu 2026 r. pojawiły się informacje o kolejnym incydencie dotyczącym systemu Medyc/Qbusoft.
Skala problemu jest tym większa, że atak na jednego dostawcę oprogramowania może potencjalnie oddziaływać jednocześnie na tysiące placówek.

1. MyDr – jeden z największych wycieków danych medycznych w Polsce.
   W sierpniu 2026 r. ujawniono incydent dotyczący firmy MyDr, dostarczającej oprogramowanie wykorzystywane przez gabinety i placówki medyczne.
   Ministerstwo Cyfryzacji poinformowało, że doszło do nieuprawnionego dostępu do **historycznych danych – sięgających kwietnia 2024 r. Według informacji przedstawionych przez administrację państwową incydent może dotyczyć około 8,8 mln osób oraz ponad 12 tys. placówek medycznych. ([Gov.pl][1]).
   Nie oznacza to jednak włamania do centralnego systemu e-zdrowia.
   Ministerstwo Zdrowia wyraźnie wskazało, że incydent MyDr nie naruszył centralnych usług e-zdrowia i nie wpłynął na dostęp pacjentów do świadczeń czy recept w publicznym systemie ochrony zdrowia. ([Gov.pl][2]). To bardzo ważne rozróżnienie.
   Problem znajdował się w infrastrukturze prywatnego dostawcy oprogramowania, z którego korzystały placówki medyczne.
   Postawmy sobie za tym pytanie „Jakie dane mogły zostać ujawnione?”.
   Prokuratura Okręgowa w Warszawie poinformowała, że postępowanie dotyczy nieuprawnionego dostępu do danych obejmujących m.in.:

• imiona i nazwiska,
• numery PESEL,
• numery telefonów,
• adresy e-mail,
• informacje dotyczące stanu zdrowia,
• notatki z wizyt lekarskich,
• informacje dotyczące wystawionych recept.
  Z punktu widzenia cyberbezpieczeństwa mamy więc do czynienia z połączeniem danych identyfikacyjnych i danych dotyczących zdrowia. To szczególnie niebezpieczna kombinacja.

2. Dlaczego dane medyczne są tak cenne?
   Cyberprzestępca, który uzyska dostęp do samego adresu e-mail, ma ograniczone możliwości.
   Jeżeli jednak posiada:

imię + nazwisko + PESEL + numer telefonu + adres + informacje medyczne, to otrzymuje znacznie bardziej kompletny profil ofiary.
Taki zestaw może zostać wykorzystany do:
• Kradzieży tożsamości
PESEL i dane osobowe mogą zostać wykorzystane do prób:

• zaciągnięcia zobowiązań,
• założenia kont,
• przejęcia istniejących usług,
• podszywania się pod ofiarę.
  Dlatego po incydencie MyDr służby zalecały m.in. zastrzeżenie numeru PESEL. ([CBZC Cyberprzestępczość][4]).
  • Spear phishingu
  Dane medyczne pozwalają przygotować znacznie bardziej wiarygodną wiadomość.
  Zamiast: „Twoja recepta jest gotowa. Kliknij tutaj”, przestępca może stworzyć komunikat odnoszący się do konkretnej placówki, lekarza lub procesu leczenia. Im więcej informacji posiada atakujący, tym łatwiej stworzyć socjotechnikę opartą na prawdziwych danych.
  • Oszustw telefonicznych
  Wyobraźmy sobie telefon:
  „Dzwonię z przychodni. W związku z ostatnią wizytą konieczne jest potwierdzenie danych…”
  Jeżeli osoba dzwoniąca zna nazwę placówki, nazwisko lekarza oraz termin wizyty, ofiara może uznać rozmowę za autentyczną.

3. Medyc/Qbusoft – kolejny niepokojący incydent
   We wrześniu 2026 r. pojawiły się informacje o kolejnym poważnym incydencie dotyczącym oprogramowania Medyc, tworzonego przez firmę Qbusoft.
   Prezes Urzędu Ochrony Danych Osobowych poinformował 25 września o planowanej kontroli firmy Qbusoft. Jednocześnie UODO zaznaczył, że skala potencjalnego naruszenia nie została jeszcze w pełni ustalona. W przestrzeni publicznej pojawia się liczba nawet 5 mln osób, ale nie jest ona obecnie oficjalnie potwierdzonym wynikiem dochodzenia. ([UODO][5]).
   To rozróżnienie jest niezwykle istotne.
   W analizach cyberbezpieczeństwa należy oddzielać:
   fakty potwierdzone → ustalenia śledztwa → informacje medialne → deklaracje potencjalnych sprawców.
   Nie każda liczba pojawiająca się w Internecie jest potwierdzonym rozmiarem wycieku.
4. SQL Injection jako przykład klasycznego problemu.
   W jednym z publicznie dostępnych zawiadomień placówki medycznej dotyczących incydentu Medyc opisano wykorzystanie podatności SQL Injection.
   Według tego komunikatu nieuprawniona osoba miała w dniach 22–23 sierpnia 2026 r. wykorzystać błąd bezpieczeństwa w interfejsie aplikacji, co doprowadziło do wytransferowania archiwum bazy danych poza środowisko dostawcy. Incydent został wykryty dopiero 8–9 września. ([Ośrodek Psychiatryczny Odwykowy][6]).
   Z punktu widzenia bezpieczeństwa jest to niezwykle interesujący przypadek.
   SQL Injection nie jest nową techniką. Jest jednym z klasycznych problemów bezpieczeństwa aplikacji internetowych. Jeżeli jednak podatność występuje w systemie centralnym, który obsługuje dane wielu placówek, jej konsekwencje mogą być ogromne.
   Można to przedstawić w uproszczeniu:
   podatna aplikacja→ uzyskanie dostępu do warstwy danych→ eskalacja dostępu do bazy→ eksfiltracja danych→ próba monetyzacji lub szantażu.
   To pokazuje, że problemem nie zawsze jest zaawansowane malware czy zero-day.
   Czasami wystarczy klasyczna podatność aplikacji internetowej, która nie została odpowiednio wykryta i zabezpieczona.
5. Największym problemem jest koncentracja danych
   Współczesna placówka medyczna korzysta z dziesiątek systemów.
   Mogą to być:
    system EDM,
    portal pacjenta,
    system rejestracji,
    system laboratoryjny,
    system obrazowania,
    system recept,
    system płatności,
    system komunikacji SMS,
    system archiwizacji,
    usługi chmurowe.
   Problem pojawia się wtedy, gdy wiele placówek korzysta z jednego dostawcy. Wtedy mamy do czynienia z tzw. efektem koncentracji ryzyka. Jeżeli jedna mała przychodnia zostanie zaatakowana, skutki są lokalne. Jeżeli jednak zostanie zaatakowany dostawca obsługujący kilka tysięcy placówek, pojedynczy incydent może stać się problemem ogólnokrajowym. MyDr jest właśnie przykładem takiego modelu ryzyka.
6. Nie tylko poufność – zagrożona jest również ciągłość działania
   Cyberatak na sektor medyczny może naruszać trzy podstawowe elementy bezpieczeństwa informacji:
   • Confidentiality – poufność
   Nieuprawniona osoba uzyskuje dostęp do danych pacjentów.
   • Integrity – integralność
   Dane mogą zostać zmodyfikowane.
   Przykładowo nieuprawniona zmiana informacji dotyczącej:

• dawkowania leku,
• historii leczenia,
• wyniku badania,
• danych pacjenta
  może mieć konsekwencje znacznie poważniejsze niż typowa utrata danych biznesowych.
  • Availability – dostępność
  System przestaje działać.
  Ten element jest szczególnie ważny w przypadku ransomware.
  Placówka może posiadać kopie zapasowe, ale jeżeli nie ma dostępu do:
• EDM,
• rejestracji,
• wyników badań,
• systemu laboratoryjnego, jej funkcjonowanie może zostać poważnie utrudnione.

7. Ransomware – drugi scenariusz zagrożenia
   Wyciek danych nie jest jedynym problemem.
   Coraz większe znaczenie ma model:
   Data Theft + Ransomware czyli:
   1.włamanie,
   2.kradzież danych,
   3.szyfrowanie systemów,
   4.żądanie okupu,
   5.groźba publikacji danych.
   To znacznie bardziej niebezpieczny model niż klasyczny ransomware. Dlaczego?
   Bo nawet jeśli administrator odtworzy system z backupu, napastnik może nadal posiadać skradzione dane. Backup rozwiązuje więc problem dostępności, ale niekoniecznie problem poufności.
8. Dane medyczne mogą być wykorzystywane do bardzo zaawansowanej socjotechniki
   To jeden z najpoważniejszych aspektów całej sytuacji.
   Załóżmy, że przestępca posiada:

• imię i nazwisko,
• PESEL,
• telefon,
• e-mail,
• nazwę przychodni,
• nazwisko lekarza,
• informację o recepcie,
• informacje o diagnozie.
  Może stworzyć praktycznie idealny scenariusz ataku.
  Przykładowo: SMS → telefon → fałszywy konsultant → phishing → przejęcie konta lub:
  e-mail → fałszywa recepta → strona logowania → kradzież danych uwierzytelniających.
  Dlatego po incydencie MyDr, służby szczególnie podkreślały konieczność zachowania ostrożności wobec wiadomości SMS, e-maili i telefonów podszywających się pod placówki medyczne, banki czy instytucje publiczne. ([CBZC Cyberprzestępczość][4]).

9. Problem zaczyna się już na poziomie dostawcy
   Incydenty MyDr i Medyc pokazują jeszcze jeden bardzo ważny problem:
   • cyberbezpieczeństwo placówki medycznej nie kończy się na jej własnej sieci.
   Jeżeli przychodnia korzysta z zewnętrznego dostawcy EDM, to bezpieczeństwo pacjentów zależy również od:

• architektury dostawcy,
• konfiguracji chmury,
• bezpieczeństwa API,
• bezpieczeństwa aplikacji webowej,
• zarządzania kontami administratorów,
• segmentacji sieci,
• backupów,
• monitoringu,
• procesu patchowania,
• zarządzania podatnościami,
• procedur reagowania na incydenty.
  W praktyce oznacza to konieczność stosowania podejścia: Third-Party Risk Management.
  Placówka powinna wiedzieć nie tylko co kupuje, ale także jak dostawca zabezpiecza przetwarzane dane.

10. Skala problemu jest większa niż pojedyncze incydenty
    Według raportu CSIRT CeZ za 2025 r. zespół obsłużył 1441 incydentów bezpieczeństwa, co oznacza wzrost o ponad 60% rok do roku. Wśród istotnych kategorii znalazły się m.in.:

• 580 przypadków oszustw komputerowych,
• 344 przypadki podatnych usług,
• 148 wycieków poświadczeń,
• 146 przypadków malware.
  Dwie pierwsze kategorie stanowiły łącznie 64% odnotowanych zdarzeń. ([Centrum e-Zdrowia][7]).
  Raport pokazuje więc, że MyDr i Medyc nie powinny być traktowane jako całkowicie odizolowane wydarzenia. Są elementami szerszego problemu bezpieczeństwa cyfrowego sektora ochrony zdrowia.

11. Problemem pozostają podstawowe zabezpieczenia
    Raport CSIRT CeZ zwraca uwagę na istotne luki organizacyjne.
    Chociaż 76% ankietowanych jednostek deklarowało wdrożenie systemu zarządzania bezpieczeństwem informacji, ponad 28% nie posiadało opublikowanej polityki bezpieczeństwa, a około 29% dyrektorów nie wykonywało regularnych przeglądów oceny ryzyka. ([Centrum e-Zdrowia][7]). To pokazuje bardzo ważną rzecz:
    • posiadanie systemu bezpieczeństwa nie oznacza jeszcze posiadania skutecznego bezpieczeństwa.
    Można mieć:

• firewall,
• EDR,
• antywirusa,
• SIEM,
• backup,
• MFA, a jednocześnie pozostawić krytyczną aplikację internetową z podatnością umożliwiającą dostęp do bazy danych.

12. Co powinny zrobić placówki medyczne?
    1.MFA wszędzie, gdzie jest to możliwe.
    Szczególnie dla:

• administratorów,
• pracowników IT,
• dostępu do chmury,
• systemów EDM,
• VPN,
• poczty elektronicznej.
  
  2. Segmentacja sieci.
  Systemy medyczne nie powinny znajdować się w jednej płaskiej sieci z komputerami użytkowników. Warto stosować segmentację: User VLAN→ Application VLAN→ Database VLAN→ Management VLAN. Każdy poziom powinien posiadać odpowiednio ograniczone reguły komunikacji.
  Regularny vulnerability management Nie wystarczy jednorazowy skan. Proces powinien obejmować: Discover → Scan → Validate → Prioritize → Patch → Verify
  
  Testy aplikacji webowych, szczególnie:

• OWASP Top 10,
• SQL Injection,
• XSS,
• authentication bypass,
• broken access control,
• IDOR,
• SSRF,
• insecure API,
• błędna konfiguracja.
  
  Ochrona baz danych
  Baza danych nie powinna być bezpośrednio dostępna z Internetu. Należy stosować:
• restrykcyjne ACL,
• segmentację,
• szyfrowanie,
• monitoring,
• minimalne uprawnienia,
• rotację sekretów,
• audyt dostępu.

13. Dostawcy oprogramowania medycznego powinni działać jak operatorzy infrastruktury krytycznej
    Dostawca systemu medycznego powinien przyjąć założenie: „Jeżeli moja aplikacja zostanie zaatakowana, skutki mogą dotknąć milionów pacjentów”. To oznacza konieczność zastosowania znacznie bardziej rygorystycznego modelu bezpieczeństwa.
    Minimalny zestaw powinien obejmować:

• Secure SDLC,
• code review,
• SAST,
• DAST,
• dependency scanning,
• SBOM,
• regularne pentesty,
• bug bounty lub odpowiedzialne zgłaszanie podatności,
• SIEM,
• EDR/XDR,
• SOC,
• 24/7 monitoring,
• MFA,
• PAM,
• secrets management,
• segmentację,
• immutable backup,
• disaster recovery,
• regularne testy odtwarzania.

14. Szczególnie istotne są backupy
    W przypadku danych medycznych należy odejść od modelu: „Mamy backup, więc jesteśmy bezpieczni”. Backup musi być odporny na atak. W praktyce warto stosować zasadę 3-2-1:
    • 3 kopie danych
    • 2 różne nośniki
    • 1 kopia offline/off-site
    W przypadku szczególnie krytycznych systemów dodatkowym zabezpieczeniem powinny być kopie niemodyfikowalne (immutable backup). Równie ważne jak wykonanie backupu jest jego regularne odtwarzanie testowe. Backup, którego nigdy nie odtworzono, nie jest gwarancją odzyskania systemu.
15. Co powinien zrobić pacjent?
    Po informacji o możliwym wycieku danych medycznych warto podjąć kilka działań.
    • Zastrzec PESEL. To jedno z podstawowych działań ochronnych rekomendowanych przez służby. ([CBZC Cyberprzestępczość][4]).
    • Zmienić hasła. Zwłaszcza jeżeli to samo hasło było wykorzystywane w kilku serwisach.
    • Włączyć MFA. Tam, gdzie jest dostępne.
    • Uważać na SMS-y i telefony. Szczególnie wiadomości dotyczące:

• recept,
• refundacji,
• wyników badań,
• wizyt,
• płatności,
• potwierdzenia danych pacjenta.
  • Nie klikać w podejrzane linki. Zwłaszcza jeśli wiadomość wykorzystuje informacje, które rzeczywiście dotyczą naszego leczenia. To właśnie czyni phishing po wycieku danych medycznych tak niebezpiecznym.

16. Największa lekcja z MyDr i Medyc.
    Oba przypadki pokazują coś znacznie ważniejszego niż sam fakt włamania. Problemem nie jest wyłącznie: czy haker włamał się do serwera?”. Prawidłowe pytanie brzmi: „Jak wiele innych organizacji i pacjentów może zostać dotkniętych, jeśli zaatakowany zostanie jeden dostawca?”.
    To zmienia sposób postrzegania ryzyka. W tradycyjnym modelu bezpieczeństwa analizujemy:
    placówka → jej sieć → jej serwery → jej dane. W nowoczesnym modelu trzeba analizować:
    pacjent → placówka → dostawca → chmura → API → podwykonawcy → backup → administratorzy.
    Każdy z tych elementów może stać się punktem wejścia.
17. Czy czeka nas fala kolejnych wycieków?
    Nie można na podstawie obecnych danych stwierdzić, że kolejne incydenty na pewno wystąpią. Można jednak wskazać czynniki zwiększające ryzyko:

• szybka cyfryzacja ochrony zdrowia,
• duża koncentracja danych u dostawców,
• rosnąca liczba aplikacji webowych,
• integracje API,
• usługi chmurowe,
• niedobór specjalistów cyberbezpieczeństwa,
• phishing skierowany do personelu,
• ransomware,
• podatności w aplikacjach,
• zależność od zewnętrznych dostawców.
  Dlatego ochrona danych medycznych powinna być traktowana jako proces ciągły, a nie projekt wykonywany raz na kilka lat.

Podsumowanie
Ostatnie incydenty pokazują zmianę charakteru zagrożeń dla polskiej ochrony zdrowia. Atakujący nie muszą już atakować każdej przychodni osobno. Znacznie bardziej atrakcyjnym celem może być dostawca oprogramowania obsługujący tysiące placówek. Przypadek MyDr pokazał potencjalną skalę sięgającą 18,8 mln osób i ponad 12 tys. placówek, natomiast najnowszy incydent związany z Medyc pokazuje, że zagrożenie nadal występuje i obejmuje również klasyczne podatności aplikacyjne, takie jak SQL Injection. W przypadku Medyc ostateczna skala naruszenia pozostaje przedmiotem ustaleń. ([Gov.pl][1]).
Najważniejszy wniosek jest prosty:
bezpieczeństwo danych pacjentów nie może być traktowane wyłącznie jako problem działu IT. Jest to problem organizacyjny, prawny, technologiczny i przede wszystkim problem bezpieczeństwa pacjenta. Dane medyczne, raz wykradzione, mogą być wykorzystywane przez wiele lat. PESEL można zastrzec, hasło można zmienić, kartę płatniczą można zablokować. Nie można jednak zmienić historii własnego leczenia. I właśnie dlatego ochrona dokumentacji medycznej powinna należeć do najbardziej rygorystycznie zabezpieczanych obszarów polskiej cyberprzestrzeni. Stan informacji: 26 września 2026 r. W przypadku Medyc część informacji o skali incydentu nadal ma charakter niepotwierdzonych doniesień, oficjalne ustalenia organów mogą się jeszcze zmienić.

Żródła
[1]:https://www.gov.pl/web/cyfryzacja/komunikat-po-spotkaniu-polaczonego-centrum-operacyjnego-cyberbezpieczenstwa?utm_source=chatgpt.com. Komunikat po spotkaniu Połączonego Centrum Operacyjnego Cyberbezpieczeństwa – Ministerstwo Cyfryzacji – Portal Gov.pl.
[2]:https://www.gov.pl/web/zdrowie/informacja-w-zwiazku-z-incydentem-dotyczacym-firmy-mydr?utm_source=chatgpt.com. Informacja w związku z incydentem dotyczącym firmy MyDr – Ministerstwo Zdrowia – Portal Gov.pl.
[3]:https://www.gov.pl/web/po-warszawa/postepowania-przygotowawcze-w-sprawie-bezprawnego-uzyskania-danych-wrazliwych-z-systemu-my-dr-sp-z-oo-i-ich-bezprawnego-przetwarzania?utm_source=chatgpt.com. Postępowania przygotowawcze w sprawie bezprawnego uzyskania danych wrażliwych z systemu My DR sp. z o.o. i ich bezprawnego przetwarzania – Prokuratura Okręgowa w Warszawie – Portal Gov.pl.
[4]:https://www.cbzc.policja.gov.pl/bzc/aktualnosci/1013%2CKomunikat-dot-wycieku-danych-pacjentow-z-systemu-informatycznego.html?utm_source=chatgpt.com. Komunikat dot. wycieku danych pacjentów z systemu informatycznego – Aktualności Centralne Biuro Zwalczania Cyberprzestępczości.
[5]:https://uodo.gov.pl/pl/138/4585?utm_source=chatgpt.com/ . Aktualności – UODO.
[6]:https://terapia-inowroclaw.pl/komunikat-medyc/?utm_source=chatgpt.com.Zawiadomienie o naruszeniu ochrony danych osobowych (Medyc) – Odwykowy Psychiatryczny Ośrodek Leczniczy.
[7]:https://cez.gov.pl/pl/page/o-nas/aktualnosci/raport-2025-csirt-cez-krajobraz-cyberbezpieczenstwa-w-sektorze-ochrony?utm_source=chatgpt.com. Raport 2025 CSIRT CeZ „Krajobraz cyberbezpieczeństwa w sektorze ochrony zdrowia” | Centrum e-Zdrowia.

Autor: Tomasz Szepelak
Ekspert z wieloletnim doświadczeniem w branży IT, posiadający obszerną wiedzę techniczną obejmującą Cyberbezpieczeństwo w środowiskach Windows i Linux, znajdowanie podatności na stronach internetowych oraz udzielanie zaleceń dotyczących zamykania znalezionych podatności. Jest odpowiedzialny za wsparcie użytkowników końcowych, instalację, wdrożenie i utrzymanie różnych komponentów LAN/WAN w środowisku korporacyjnym w strukturach firmy międzynarodowej. Uczestniczy w różnorodnych projektach, jako niezależny lider projektu, pracuje nad wdrożeniami nowych rozwiązań. Może pochwalić się również szeroką wiedzą w zakresie procesów IT i tytułem ITIL® Expert.