Cyberbezpieczeństwo w ochronie zdrowia.
Jak połączyć pentest, SOC i SIEM, zanim incydent zatrzyma leczenie.
Szpital, przychodnia, laboratorium i dostawca platformy medycznej chronią nie tylko serwery. Chronią ciągłość diagnostyki, dostęp do dokumentacji oraz zaufanie pacjentów. Pokazujemy, jak testy penetracyjne, monitoring SOC/SIEM i przygotowanie na ransomware składają się w jeden program odporności.
W medycynie cyberincydent szybko przestaje być problemem działu IT
Najważniejszy wniosek: pojedynczy audyt zgodności, skaner podatności albo samo uruchomienie SIEM nie wystarczą. Placówka potrzebuje cyklu: rozpoznanie powierzchni ataku, kontrolowany pentest, usunięcie realnych ścieżek włamania, telemetryka z systemów krytycznych, użyteczne reguły detekcji oraz przećwiczone procedury awaryjne.
- Pentest odpowiada na pytanie, czy napastnik może wejść do środowiska, podnieść uprawnienia, przejść pomiędzy segmentami i dotrzeć do danych pacjentów.
- SOC i SIEM pokazują, czy organizacja zauważy te działania wystarczająco wcześnie i czy alert doprowadzi do właściwej reakcji.
- Backup i incident response decydują, czy po ataku placówka utrzyma świadczenia i bezpiecznie odbuduje systemy.
- Zarządzanie dostawcami obejmuje platformy rejestracyjne, telemedycynę, laboratoria, serwis aparatury, chmurę oraz integracje z systemami centralnymi.
Autor: Michał Błaszczak · · BSTA sp. z o.o.
obsłużonych w 2025
do roku
komputerowych
usług
Incydenty MyDr, ALAB i szpitala MSWiA to różne zdarzenia, ale wspólny sygnał
W sierpniu 2026 r. media poinformowały o cyberataku na MyDr. W chwili przygotowania tego materiału organy państwa analizowały, czy doszło do wycieku danych, a jako możliwą skalę wskazywano bazę obejmującą blisko 19 mln osób. To ważne zastrzeżenie: możliwego zakresu incydentu nie należy przedstawiać jako ostatecznie potwierdzonego zakresu wycieku. Przypadek pokazuje jednak koncentrację ryzyka u dostawców obsługujących wiele podmiotów medycznych. Źródło: Bankier.pl — cyberatak na MyDr.
Nie jest to odosobniony temat. Atak ransomware na ALAB został połączony z wyciekiem danych i uruchomił wspólne działania UODO oraz Rzecznika Praw Pacjenta. Z kolei naruszenie infrastruktury szpitala MSWiA w Krakowie w marcu 2025 r. spowodowało pracę placówki w ograniczonym zakresie i wymagało wsparcia CSIRT CeZ, CSIRT NASK oraz służb. Źródła: UODO — sprawa ALAB, MSWiA — komunikat szpitala w Krakowie oraz CSIRT CeZ — pomoc po cyberataku.
Ryzyko nie kończy się na jednej aplikacji. Łańcuch zależności łączy portal pacjenta, API, system gabinetowy, domenę Windows, stacje personelu, aparaturę, konta serwisowe, chmurę i zewnętrznych dostawców. Przejęcie najsłabszego elementu może otworzyć drogę do pozostałych.
Dane CSIRT CeZ potwierdzają skalę problemu. W 2025 r. zespół obsłużył 1441 incydentów w sektorze ochrony zdrowia — o ponad 60% więcej niż rok wcześniej. Dominowały oszustwa komputerowe i podatne usługi, a raport wskazuje również wycieki poświadczeń, szkodliwe oprogramowanie oraz ransomware. Źródło: Raport 2025 CSIRT CeZ.
Poufność danych to tylko jeden z trzech warunków bezpieczeństwa
W ochronie zdrowia klasyczna triada poufność–integralność–dostępność ma bezpośrednie znaczenie operacyjne:
- Poufność: nieuprawniony dostęp do rozpoznań, wyników, recept, skierowań, danych genetycznych, danych kontaktowych i numerów PESEL.
- Integralność: możliwość zmiany dokumentacji, parametrów zlecenia, wyniku, uprawnienia użytkownika lub danych używanych przez personel przy podejmowaniu decyzji.
- Dostępność: brak dostępu do HIS, RIS, PACS, EDM, rejestracji, poczty lub domeny może opóźnić diagnostykę i wymusić pracę w trybie awaryjnym.
Dlatego ryzyka nie wolno priorytetyzować wyłącznie według technicznej punktacji. Podatność o umiarkowanym CVSS może być krytyczna, jeżeli dotyczy systemu wspierającego SOR, diagnostykę obrazową albo ordynację leków. Raport z testu powinien łączyć dowód techniczny z wpływem na proces medyczny.
Co należy objąć testami penetracyjnymi placówki medycznej?
Zakres dobiera się do architektury i ryzyka, a test produkcji prowadzi w uzgodnionych oknach oraz z regułami zatrzymania. Dla procesów szczególnie wrażliwych warto użyć środowiska testowego i danych syntetycznych. Więcej o podejściu BSTA: testy aplikacji webowych, testy bezpieczeństwa API oraz pentest infrastruktury i Active Directory.
Najgroźniejsze błędy nie zawsze mają numer CVE
System medyczny może być aktualny, a mimo to pozwalać pacjentowi odczytać cudzy dokument, rejestratorce wyjść poza przypisaną placówkę lub integracji pobrać dane szersze niż wymagane. Takich problemów nie wykrywa samo skanowanie komponentów.
- BOLA/IDOR: zamiana identyfikatora wizyty, dokumentu, wyniku albo pacjenta zwraca cudzy zasób.
- Błędy ról: uprawnienia lekarza, rejestracji, laboratorium, administratora i integratora nie są egzekwowane spójnie w interfejsie oraz API.
- Eksporty i linki: plik PDF, archiwum, podgląd obrazu lub link udostępniony pozostaje dostępny po zmianie uprawnień.
- Odzyskiwanie konta: proces resetu oparty na łatwo dostępnych danych umożliwia przejęcie profilu pacjenta lub personelu.
- Integracje: token ma zbyt szeroki zakres, nie ma rotacji albo pozwala ominąć reguły obowiązujące w głównej aplikacji.
Zobacz powiązane, zanonimizowane case study portalu pacjenta i medycznego API. Pokazuje ono, dlaczego macierz pacjent–personel–integracja jest ważniejsza niż lista automatycznych alertów.
Pentest powinien sprawdzić, czy jedno konto otwiera całą placówkę
Typowy scenariusz ataku nie kończy się na skrzynce pocztowej lub pojedynczej stacji. Napastnik próbuje zdobyć poświadczenia, rozpoznać domenę, podnieść uprawnienia, wyłączyć zabezpieczenia, odnaleźć serwery kopii zapasowych i przejść do systemów medycznych.
- czy dostęp z sieci użytkowników do serwerów HIS/RIS/PACS jest rzeczywiście ograniczony;
- czy konta serwisowe mają minimalne uprawnienia i nie używają wspólnych haseł;
- czy administratorzy korzystają z oddzielnych kont i stacji uprzywilejowanych;
- czy urządzenia serwisowane zdalnie nie tworzą niekontrolowanej drogi do sieci klinicznej;
- czy backup jest odseparowany, niezmienny i regularnie odtwarzany w ramach testu;
- czy EDR/XDR działa również na serwerach i hostach, które realnie mogą zostać wykorzystane do ruchu bocznego.
CSIRT CeZ rekomenduje m.in. aktualizacje, segmentację, odizolowane kopie zapasowe oraz testowanie procedur odtwarzania. Test penetracyjny weryfikuje, czy te zabezpieczenia faktycznie zatrzymują uzgodnioną ścieżkę ataku.
Nie chodzi o zbieranie wszystkich logów. Chodzi o wykrywanie konkretnych zachowań
SIEM bez zaprojektowanych przypadków użycia staje się drogim archiwum. Dla placówki medycznej priorytetem powinny być zdarzenia powiązane z najważniejszymi ścieżkami ataku i procesami klinicznymi.
Każda reguła powinna mieć właściciela, opis kontekstu, wymagane źródła danych, próg, sposób wzbogacania, playbook i kryterium zamknięcia. Następnie trzeba ją sprawdzić podczas purple teamingu albo kontrolowanego testu detekcji. Szczegółowy zakres: SOC, SIEM i operacje Blue Team.
Personel jest celem, ale odpowiedzialność za bezpieczeństwo nie może spoczywać wyłącznie na nim
Kampanie wykorzystują presję czasu, komunikaty o wynikach, rozliczeniach, grafiku, receptach lub pilnej aktualizacji konta. Szkolenie jest potrzebne, lecz pojedynczy błąd człowieka nie powinien prowadzić do przejęcia domeny.
Ochronę tworzą wspólnie: odporne MFA, filtrowanie poczty, ograniczenie makr i skryptów, EDR/XDR, oddzielne konta administratorów, dostęp warunkowy, najmniejsze uprawnienia oraz szybki proces zgłaszania podejrzanych wiadomości. Kontrolowane testy phishingowe powinny mierzyć nie tylko liczbę kliknięć, ale również czas zgłoszenia, reakcję SOC i możliwość dalszej eskalacji.
Placówka może dobrze chronić własną sieć i nadal dziedziczyć cudze ryzyko
Systemy rejestracji, teleporady, diagnostyka, hosting, serwis aparatury i integratorzy często posiadają dostęp do wielu organizacji. To zwiększa efekt skali potencjalnego incydentu, dlatego umowa i ankieta bezpieczeństwa nie powinny być jedynymi kontrolami.
- spis danych, systemów i uprawnień powierzonych dostawcy;
- oddzielne, imienne konta serwisowe z MFA i ograniczeniem czasowym;
- logowanie działań dostawcy oraz dostęp logów do analizy incydentu;
- wymagania dotyczące zgłoszeń incydentów, kopii zapasowych, retencji i usuwania danych;
- prawo do uzyskania dowodów testów bezpieczeństwa i planów naprawczych;
- procedura odłączenia integracji bez zatrzymania krytycznych świadczeń.
Aktualny incydent MyDr jest dobrym powodem, by sprawdzić nie tylko zabezpieczenia konkretnego dostawcy, lecz cały model koncentracji danych i dostępów w ekosystemie ochrony zdrowia.
Podstawowe problemy z dostępem nadal mają znaczenie
Kontrola NIK w sześciu szpitalach i jednym ośrodku zdrowia wykazała, że w większości badanych jednostek zabezpieczenia nie były w pełni rzetelne lub adekwatne. Dostęp do danych posiadali m.in. niektórzy pracownicy niemedyczni i byli pracownicy placówek. To pokazuje, że zaawansowane narzędzia nie zastąpią cyklicznego przeglądu kont, ról i procesów odejścia pracownika. Źródło: NIK — ochrona danych pacjentów przed cyberatakami.
Od czego może zacząć dyrektor placówki, CIO, CISO lub kierownik IT?
Dni 1–30: obraz ryzyka
- ustalić właścicieli procesów krytycznych i maksymalny akceptowalny czas ich niedostępności;
- zinwentaryzować systemy, integracje, dostawców, konta uprzywilejowane i połączenia zdalne;
- sprawdzić ekspozycję usług internetowych, aktualność systemów i stan kopii zapasowych;
- wybrać najważniejsze scenariusze: ransomware, przejęcie konta personelu, masowy eksport danych, awaria dostawcy.
Dni 31–60: test i ograniczenie ścieżek ataku
- przeprowadzić pentest zewnętrzny, web/API i infrastruktury wewnętrznej w zakresie wynikającym z ryzyka;
- naprawić krytyczne błędy autoryzacji, segmentacji, MFA i kont uprzywilejowanych;
- zweryfikować odtwarzanie backupu oraz możliwość pracy w trybie awaryjnym;
- określić wymagane logi i retencję dla systemów krytycznych.
Dni 61–90: detekcja i ćwiczenie reakcji
- wdrożyć priorytetowe przypadki użycia SIEM oraz playbooki SOC;
- wykonać retest poprawek i kontrolowany test widoczności ataku;
- przeprowadzić ćwiczenie tabletop ransomware z udziałem IT, medyków, kierownictwa, IOD i komunikacji;
- ustalić mierniki: pokrycie logami, czas detekcji, czas eskalacji, skuteczność odtworzenia i zamykanie podatności.
Zgodność powinna być skutkiem działających zabezpieczeń, nie celem samym w sobie
Podmioty ochrony zdrowia mogą podlegać obowiązkom wynikającym z przepisów o krajowym systemie cyberbezpieczeństwa, NIS2, ochronie danych osobowych i dokumentacji medycznej. Konkretne obowiązki zależą od rodzaju podmiotu, jego wielkości, świadczonych usług i roli w systemie. Pentest, monitoring i ćwiczenia reagowania dostarczają dowodów technicznych, ale nie zastępują pełnej analizy prawnej ani audytu zgodności.
Warto oddzielić trzy pytania: czy mamy politykę, czy kontrola jest wdrożona oraz czy rzeczywiście zatrzymuje i wykrywa atak. Dopiero trzecie pytanie daje obraz odporności.
Najczęstsze pytania o cyberbezpieczeństwo placówek medycznych
Jak często wykonywać test penetracyjny szpitala lub przychodni?
Najczęściej co najmniej raz w roku oraz po dużej zmianie aplikacji, infrastruktury, dostawcy, integracji albo architektury dostępu. Systemy internetowe i API rozwijane często warto testować po istotnych wydaniach.
Czy pentest może zakłócić pracę placówki?
Zakres i techniki uzgadnia się przed rozpoczęciem. Dla systemów krytycznych stosuje się okna testowe, reguły zatrzymania, limity intensywności i dane syntetyczne. Ryzykowne scenariusze można przenieść do środowiska odwzorowującego produkcję.
Czy sam SIEM zapewnia bezpieczeństwo danych medycznych?
Nie. SIEM koreluje dane, ale potrzebuje właściwych logów, reguł, kontekstu, obsługi alertów i procedur reakcji. Jego skuteczność należy regularnie testować.
Jakie logi są najważniejsze?
To zależy od scenariuszy ryzyka. Zwykle priorytetem są logowania i MFA, Active Directory/Entra ID, systemy EDM/HIS i ich API, EDR/XDR, firewalle/VPN, serwery plików, backup, poczta, wirtualizacja oraz zdalny dostęp dostawców.
Czy testy pomagają przy KSC/NIS2 i RODO?
Pomagają wykazać techniczną weryfikację zabezpieczeń i ryzyka, lecz nie przesądzają samodzielnie o pełnej zgodności. Zakres wymagań należy ustalić dla konkretnej organizacji.
Co powinien zawierać raport?
Dowód podatności, warunki wykorzystania, wpływ na proces i dane, ocenę ryzyka, priorytet, konkretne zalecenia, mapę ścieżki ataku oraz wynik retestu. Zobacz przykładową strukturę raportu BSTA.
Materiały wykorzystane w artykule
Potwierdź klientom i partnerom, że Twoje systemy przeszły kontrolę bezpieczeństwa
Po wykonaniu testów i pozytywnym zakończeniu uzgodnionej weryfikacji otrzymasz Certyfikat Bezpieczeństwa TestPenetracyjny.pl. Dokument potwierdza przeprowadzenie niezależnej kontroli w określonym zakresie, terminie i dla wskazanych systemów.
- czytelne potwierdzenie wykonania pentestu lub audytu technicznego,
- wsparcie w rozmowach z klientami, partnerami, zarządem i ubezpieczycielem,
- wydanie po usunięciu uzgodnionych podatności krytycznych i wysokich oraz reteście.
To widoczny dowód, że bezpieczeństwo traktujesz poważnie. Certyfikat nie jest gwarancją braku wszystkich podatności ani formalnym certyfikatem zgodności z konkretną ustawą — precyzyjnie opisuje sprawdzony zakres i datę kontroli.
Sprawdźmy, czy placówka zatrzyma i wykryje realny atak
Łączymy testy aplikacji, API i infrastruktury z oceną segmentacji, odporności na ransomware oraz skuteczności SOC/SIEM. Raport zawiera dowody, priorytety i plan naprawczy.
Zapytaj o zakres i wycenę →