Dlaczego infrastruktura krytyczna jest dziś na celowniku
Co faktycznie jest infrastrukturą krytyczną
Infrastruktura krytyczna to nie tylko ogromne elektrownie i ogólnokrajowe sieci przesyłowe. W ujęciu prawnym i praktycznym obejmuje wszystkie systemy, których zakłócenie może poważnie uderzyć w bezpieczeństwo państwa, zdrowie ludzi, gospodarkę lub porządek publiczny. Mowa o sektorach: energia, gaz, ciepło, wodociągi i kanalizacja, transport kolejowy i lotniczy, telekomunikacja, szpitale i ratownictwo medyczne, bankowość, systemy rozliczeń, administracja publiczna czy gospodarka odpadami.
Z punktu widzenia cyberbezpieczeństwa infrastruktura krytyczna to przede wszystkim połączenie technologii: klasycznych systemów IT (poczta, ERP, CRM, systemy kadrowo‑płacowe) oraz systemów OT/ICS – automatyki przemysłowej, systemów sterowania, elektroniki zabezpieczeniowej i pomiarowej. Na styku tych dwóch światów powstaje środowisko o ogromnej złożoności i równie ogromnych konsekwencjach w przypadku awarii lub ataku.
Dodatkowo, obok wielkich operatorów, do kategorii „krytycznej” coraz częściej zaliczają się średnie podmioty: lokalne spółki wodociągowe, ciepłownie, operatorzy transportu publicznego, miejskie wysypiska czy prywatne placówki medyczne. Ich systemy są mniej chronione, ale ich zatrzymanie potrafi sparaliżować całe miasto – co czyni je wygodnym celem.
Nowy profil zagrożeń: od awarii do celowych cyberataków
Przez lata głównym problemem dla infrastruktury krytycznej były awarie techniczne, błędy ludzkie, zużycie sprzętu czy błędna konfiguracja. Dziś do tego katalogu dochodzą zorganizowane, często długotrwałe kampanie cyberataków. Przestępcy nie szukają już tylko szybkiego zysku z kradzieży danych. Coraz częściej chcą:
- wymuszać okup (ransomware blokujące systemy szpitalne, wodociągowe, energetyczne),
- prowadzić sabotaż – destabilizować usługi podstawowe,
- zbierać dane wywiadowcze o infrastrukturze na czas późniejszego konfliktu,
- wywierać presję polityczną lub gospodarczą na państwo czy miasto.
Ataki typu APT (Advanced Persistent Threat) potrafią trwać miesiącami. Zaczynają się niewinnie – od kompromitacji pojedynczego konta poczty, laptopa dostawcy czy zapomnianego serwera WWW – a kończą pełnym dostępem do systemów sterowania. Kluczowe jest to, że granica między atakami „cyberprzestępców” a działaniami sponsorowanymi przez państwa zaciera się, a infrastruktura krytyczna jest oczywistym celem w obu scenariuszach.
Realne konsekwencje skutecznego ataku
Skuteczny cyberatak na infrastrukturę krytyczną nie kończy się na komunikacie o „incydencie technicznym” w mediach. Najczęstsze konsekwencje to:
- przerwy w dostawach prądu, wody, gazu lub ciepła dla tysięcy odbiorców,
- koszty operacyjne związane z przywracaniem systemów, pracą w trybie ręcznym, dodatkowymi zmianami,
- utrata zaufania społecznego i reputacji – mieszkańcy długo pamiętają zimne kaloryfery lub brak wody w kranie,
- odpowiedzialność prawna zarządzających – za zaniedbania, brak zabezpieczeń czy niezgłoszenie incydentu,
- ryzyko wtórnych strat – wypadki na drogach, opóźnione zabiegi medyczne, straty w produkcji firm zależnych.
Warto też dostrzec efekt „kuli śnieżnej”: jeśli padnie system rozliczeń, cierpią dostawcy; jeśli padnie telekomunikacja, cierpią służby ratunkowe i transport; jeśli wodociągi muszą przejść na tryb awaryjny, cierpi przemysł, gastronomia, szkoły i szpitale. Ochrona infrastruktury krytycznej nie jest więc tylko problemem jednej spółki – to inwestycja w stabilność całego otoczenia.
Dlaczego średni gracze i podwykonawcy też są celem
Średnie podmioty często żyją w złudzeniu: „Jesteśmy zbyt mali, aby ktoś się nami interesował”. Tymczasem atakujący uwielbiają właśnie takie organizacje. Działają w łańcuchu dostaw, posiadają połączenia z siecią dużego operatora, mają dostęp do systemów serwisowych, a ich poziom zabezpieczeń jest zwykle dużo niższy. W praktyce stają się „słabym ogniwem” prowadzącym prosto do głównego celu.
Klasyczny scenariusz to kompromitacja firmy serwisującej systemy HVAC lub automatykę. Atakujący przejmują jej konto VPN lub dostęp do systemu zdalnego wsparcia, a potem – powoli, cierpliwie – przenikają do sieci OT dużego klienta. Zdarza się, że pierwsze logi wskazujące na obecność intruza są odnotowywane w małej spółce komunalnej, a prawdziwy atak na operatora systemu energetycznego następuje wiele miesięcy później.
Krótki przykład z praktyki energetycznej
W jednym z europejskich krajów dostawca energii regionalnej stracił kontrolę nad częścią systemu dystrybucyjnego po tym, jak atakujący wykorzystali słaba zabezpieczenia w zdalnym dostępie do podstacji. Loginy i hasła do systemu SCADA były współdzielone przez kilku inżynierów, bez uwierzytelniania wieloskładnikowego, a połączenia realizowano z prywatnych laptopów. Seria nieautoryzowanych przełączeń spowodowała wyłączenia linii i chwilową utratę zasilania na kilku obszarach.
Organizacja poradziła sobie z incydentem, ale skutki były dotkliwe: konieczność przeglądu całej architektury dostępu, wielomiesięczne audyty, presja regulatora, a także ogrom pracy operacyjnej. Ten jeden przypadek pokazał zarządowi, że cyberbezpieczeństwo systemów przemysłowych musi być traktowane jak inwestycja w ciągłość biznesu, a nie jedynie „koszt IT”. Im szybciej takie wnioski zostaną wyciągnięte, tym mniej boleśnie będzie wyglądało starcie z kolejnymi zagrożeniami.
Świadome podejście do skali ryzyka to pierwszy krok, by przesunąć budżet i uwagę z „gadżetów IT” na prawdziwą odporność infrastruktury krytycznej – warto go wykonać od razu, zanim zrobi to za nas regulator lub awaria.

Fundamenty: jak rozumieć środowisko IT, OT, ICS i SCADA
IT kontra OT – dwa światy, które muszą się dogadać
W klasycznym świecie IT celem jest poufność i integralność danych oraz ciągłość działania systemów biurowych. W świecie OT (Operational Technology) priorytetem jest bezpieczeństwo ludzi, środowiska oraz ciągłość procesów technologicznych – często za cenę kompromisów w kwestii aktualności oprogramowania czy szyfrowania danych. To fundamentalna różnica, która sprawia, że podejście „skopiujmy politykę z IT do OT” zazwyczaj kończy się konfliktem.
Systemy IT to m.in. serwery plików, systemy ERP, CRM, poczta elektroniczna, serwisy WWW, systemy HR. Systemy OT/ICS obejmują sterowniki PLC, systemy DCS, systemy SCADA, panele HMI, zabezpieczenia przekaźnikowe, liczniki inteligentne, systemy telemetrii i tysiące czujników rozsianych w terenie. Każdy z tych elementów pracuje często w czasie rzeczywistym, w trudnych warunkach i musi współpracować ze sprzętem o bardzo długim cyklu życia.
Typowe komponenty ICS i SCADA
Aby skutecznie zabezpieczyć infrastrukturę krytyczną przed cyberatakami, trzeba dokładnie wiedzieć, co w niej działa. W typowym zakładzie przemysłowym, elektrociepłowni, oczyszczalni ścieków czy stacji wodociągowej znajdziemy:
- SCADA – system nadzorujący i zbierający dane z całego obiektu lub sieci obiektów, często z centralną wizualizacją procesów, alarmami i funkcjami sterowania,
- PLC i RTU – sterowniki programowalne oraz moduły zdalne, które bezpośrednio sterują zaworami, pompami, przełącznikami, przekształtnikami,
- HMI – panele operatorskie na liniach i w stacjach, służące do obsługi lokalnej i podglądu parametrów,
- sieci przemysłowe – Ethernet przemysłowy, Modbus, Profibus, OPC UA, DNP3, IEC 60870-5-104 i inne protokoły, często projektowane pierwotnie bez bezpieczeństwa wbudowanego,
- systemy pomocnicze – monitoring wizyjny, systemy kontroli dostępu, HVAC, systemy przeciwpożarowe, które coraz częściej są zintegrowane z siecią IT/OT.
Każdy z tych elementów jest potencjalnym punktem wejścia dla atakującego, szczególnie gdy urządzenia mają stare oprogramowanie, domyślne hasła, otwarte porty serwisowe lub są podłączone do Internetu „na skróty”, aby ułatwić sobie zdalny serwis.
Specyfika OT: długie cykle życia i trudne aktualizacje
Infrastruktura krytyczna działa w cyklach, które z punktu widzenia IT wydają się kosmiczne. Sterowniki PLC pracują 10–20 lat, linie produkcyjne jeszcze dłużej, a systemy SCADA są modernizowane co wiele lat, niekiedy z zachowaniem starych komponentów. W takim środowisku „regularne aktualizacje co miesiąc” są często niewykonalne – każdy restart, każda zmiana oprogramowania może powodować przerwy w działaniu procesu lub ryzyko błędów technologicznych.
Z tego powodu bezpieczeństwo w OT opiera się nie tyle na szybkim łataniu wszystkiego, co na architekturze, segmentacji i kontrolach dostępu. Łata się to, co naprawdę krytyczne i przetestowane, a resztę chroni się dodatkowymi warstwami: izolacją sieciową, filtracją ruchu, monitoringiem anomalii, silnym uwierzytelnianiem użytkowników oraz ograniczeniem zdalnych połączeń.
Mosty IT–OT: gdzie zwykle wchodzi atakujący
Najbardziej newralgiczne miejsca to punkty styku systemów IT i OT. W praktyce to:
- serwery komunikacyjne przenoszące dane z SCADA do systemów raportowych i BI,
- stacje inżynierskie z jednoczesnym dostępem do sieci biurowej i sterowników PLC,
- serwery zdalnego dostępu dla dostawców i serwisantów (VPN, RDP, TeamViewer i podobne),
- systemy AD/LDAP używane równocześnie w IT i OT,
- stacje operatorskie z dostępem do poczty, Internetu lub klienckich aplikacji biznesowych.
To właśnie tam złośliwe oprogramowanie najczęściej przeskakuje z IT do OT. Przejęty laptop inżyniera, który raz dziennie łączy się z siecią produkcyjną, by wgrać nową recepturę, bywa dla atakującego cenniejszy niż dobrze chroniony serwer SCADA. Dlatego szczególna uwaga należy się kontom uprzywilejowanym, stacjom inżynierskim i mechanizmom zdalnego dostępu.
Ramy prawne i standardy – co naprawdę trzeba mieć na radarze
Kluczowe regulacje: NIS2, krajowe ustawy i wytyczne
Operatorzy infrastruktury krytycznej nie działają w próżni. Oprócz zdrowego rozsądku wiążą ich konkretne przepisy. Na poziomie Unii Europejskiej centralną rolę odgrywa dyrektywa NIS2, która znacznie podnosi poprzeczkę wymagań wobec podmiotów kluczowych i ważnych. W Polsce obowiązuje ustawa o krajowym systemie cyberbezpieczeństwa, regulacje sektorowe (np. energetyczne, telekomunikacyjne) oraz szczegółowe wytyczne dla operatorów usług kluczowych i infrastruktury krytycznej.
W praktyce regulacje te przekładają się na obowiązki:
- wdrożenia minimalnych środków bezpieczeństwa technicznych i organizacyjnych,
- opracowania i utrzymywania planów ciągłości działania oraz odtwarzania po awarii,
- zgłaszania incydentów do odpowiednich krajowych CSIRT-ów,
- regularnego audytowania i weryfikowania skuteczności zabezpieczeń,
- szkolenia personelu i budowania świadomości zagrożeń.
Naruszenie tych obowiązków grozi nie tylko karami finansowymi, ale również sankcjami wobec kadry zarządzającej – włącznie z odpowiedzialnością osobistą, jeśli wykaże się rażące zaniedbania. Świadomy zarząd coraz częściej traktuje przepisy jako narzędzie budowania przewagi: firma z dobrze poukładanym cyberbezpieczeństwem ma mniej przestojów, szybciej reaguje na kryzysy i jest wiarygodniejszym partnerem dla klientów oraz regulatora.
Standardy i dobre praktyki: jak się nie zgubić
Na rynku funkcjonuje wiele standardów i ram odniesienia, które pomagają zaplanować ochronę infrastruktury krytycznej:
- ISO/IEC 27001 – system zarządzania bezpieczeństwem informacji, dobry szkielet dla całej organizacji,
- ISO/IEC 27019 – rozszerzenie ISO 27001 dla sektora energetycznego i systemów kontroli procesów przemysłowych,
Specyficzne normy dla OT i ICS
Bezpośrednio do świata automatyki i systemów sterowania odnoszą się normy i wytyczne, które precyzują, jak chronić procesy przemysłowe, a nie tylko dane. Najważniejsze z nich to:
- IEC 62443 – rodzina standardów dla systemów automatyki przemysłowej (IACS), obejmująca wymagania wobec operatorów, integratorów i producentów; to dziś złoty standard dla OT,
- NIST SP 800-82 – przewodnik bezpieczeństwa dla systemów ICS, bardzo praktyczny materiał do projektowania architektury i segmentacji,
- ISO 22301 – zarządzanie ciągłością działania, kluczowe przy planowaniu reakcji na incydenty w infrastrukturze krytycznej,
- normy branżowe – np. IEC 61850 (energetyka), IEC 60870-5, wytyczne ENTSO-E, rekomendacje krajowych regulatorów i operatorów sieci przesyłowych.
Te dokumenty mogą wydawać się na początku przytłaczające, ale pełnią ważną rolę: pomagają przełożyć ogólne hasła „cyberbezpieczeństwo OT” na konkretne wymagania projektowe, listy kontrolne i mierzalne cele. Zamiast wymyślać własne podejście od zera, lepiej oprzeć się na sprawdzonych wzorcach i dopasować je do realiów zakładu.
Dobrym krokiem jest wybranie jednego głównego szkieletu (np. ISO 27001 + IEC 62443) i na nim budowanie pozostałych polityk, procesów oraz wymagań zakupowych. Mniej chaosu, więcej konsekwencji – i łatwiej przekonać zarząd, że to spójny program, a nie kolekcja nieskoordynowanych inicjatyw.
Jak używać standardów w praktyce, zamiast „robić certyfikat dla certyfikatu”
Standardy najwięcej dają wtedy, gdy traktuje się je jak narzędzie do porządkowania rzeczywistości, a nie wyłącznie przepustkę do ramki z certyfikatem. Zamiast celować od razu w pełną zgodność, sensownie jest podejść do tematu etapami:
Na koniec warto zerknąć również na: Prawne konsekwencje ataków DDoS — to dobre domknięcie tematu.
- Ocena luk – szybkie porównanie obecnego stanu z wymaganiami normy (gap analysis), najlepiej prowadzone wspólnie przez IT, OT i bezpieczeństwo,
- Priorytetyzacja – wybranie tych wymagań, które realnie wpływają na odporność (np. segmentacja, zarządzanie dostępami, monitoring), a nie tylko na „ładne dokumenty”,
- Plan dojścia – rozpisanie zmian na realne kroki projektowe i utrzymaniowe, rozłożone w czasie,
- Włączenie do życia organizacji – zadbanie, by procedury nie leżały w szafie, ale były powiązane z KPI, premiami, przeglądami technicznymi i audytami wewnętrznymi.
Takie podejście przekłada abstrakcyjne normy na konkret: listę zmian w konfiguracji, zakres prac dla integratorów, wymagania w umowach z dostawcami i harmonogram testów. Im szybciej standardy zostaną zaszyte w codzienne działania, tym mniej bolesne będą przyszłe audyty zewnętrzne.

Analiza ryzyka dla infrastruktury krytycznej: od inwentaryzacji do priorytetów
Zaczyna się od wiedzy: inwentaryzacja zasobów OT i powiązań
Nie da się sensownie chronić czegoś, czego nie widać. Pierwszy krok to rzetelna inwentaryzacja zasobów OT i ICS – nie tylko w arkuszu Excela, ale także poprzez automatyczne narzędzia pasywnego skanowania sieci przemysłowych. W praktyce chodzi o odpowiedzi na kilka prostych pytań:
- jakie sterowniki, systemy SCADA, HMI, serwery i urządzenia sieciowe faktycznie działają w zakładzie,
- jakie mają wersje firmware’u, systemów operacyjnych i pakietów aplikacyjnych,
- jak są ze sobą połączone (topologia logiczna i fizyczna),
- które z nich mają połączenia do sieci biurowej, Internetu lub sieci dostawców.
Dobrą praktyką jest połączenie wywiadu z personelem (automatycy, utrzymanie ruchu, energetycy, telemetria) z danymi z sieci i dokumentacji projektowej. Same narzędzia skanujące nie pokażą np. manualnych procedur obejścia zabezpieczeń czy drogi „awaryjnego dostępu” używanej przez serwisanta raz na pół roku.
Identyfikacja scenariuszy zagrożeń i skutków
Gdy wiadomo, co działa i jak się łączy, można przejść do scenariuszy zagrożeń. Tu najwięcej wnosi wspólna praca zespołów OT i bezpieczeństwa. Zamiast pisać ogólne formułki o „utracie poufności”, lepiej nazwać rzeczy po imieniu:
- niekontrolowane otwarcie zaworu w instalacji chemicznej,
- zakłócenie pracy zabezpieczeń w stacji elektroenergetycznej,
- wstrzymanie pracy pomp w stacji wodociągowej,
- przestawienie parametrów pracy linii produkcyjnej, skutkujące wadliwym produktem lub uszkodzeniem maszyn,
- masowe zaszyfrowanie serwerów i stacji operatorskich SCADA.
Każdy scenariusz należy powiązać z konkretnymi skutkami: wpływem na życie i zdrowie ludzi, środowisko, ciągłość dostaw, umowy z kluczowymi klientami, wizerunek. IT może pomóc w analizie środków technicznych, ale to inżynierowie procesu wiedzą, które odchylenia parametrów są niebezpieczne.
Ocena prawdopodobieństwa i wpływu – prosto, ale uczciwie
Nie trzeba od razu wdrażać skomplikowanych metodyk ilościowych. Ważniejsze jest uczciwe, wspólne oszacowanie, które scenariusze są najbardziej prawdopodobne i najgroźniejsze. Często wystarczy:
- kilkustopniowa skala wpływu (niski, średni, wysoki, katastrofalny),
- kilkustopniowa skala prawdopodobieństwa (rzadkie, możliwe, prawdopodobne),
- macierz ryzyka, która pozwala ustawić priorytety.
Zbyt matematyczne podejście szybko gubi sens, jeśli i tak wszyscy wiedzą, że np. przerwa w pracy pomp w ujęciu wody to zdarzenie, którego trzeba unikać za wszelką cenę, bez liczenia dziesiętnych części procenta. Liczy się to, żeby na końcu powstała jasna lista ryzyk wysokich, do których przypisuje się konkretne działania.
Mapa ryzyka i decyzje: co chronimy w pierwszej kolejności
Dobrze przygotowana analiza ryzyka prowadzi do prostego pytania: co jest naprawdę krytyczne. Odpowiedzią może być mapa ryzyka, gdzie:
- główny proces produkcyjny lub przesyłowy dostaje najwyższy priorytet ochrony,
- kluczowe węzły OT (np. stacje nadrzędne SCADA, serwery bazy danych pomiarowych, kluczowe PLC) są wskazane jako obiekty wymagające szczególnej uwagi,
- systemy pomocnicze (np. HVAC, CCTV) są klasyfikowane w zależności od wpływu na bezpieczeństwo,
- punkty styku IT–OT są zaznaczone jako miejsca, gdzie trzeba dołożyć kontroli.
Na tej podstawie można podjąć decyzje: gdzie inwestować w segmentację, gdzie w monitoring, gdzie w modernizację sprzętu, a gdzie wystarczy wzmocnić procedury i świadomość personelu. Im bardziej mapa ryzyka jest połączona z realnymi procesami (a nie tylko z listą serwerów), tym łatwiej bronić budżetu przed zarządem.
Analiza ryzyka nie ma sensu, jeśli kończy w szufladzie – wykorzystaj ją jako kompas przy każdej większej inwestycji i zmianie w OT.
Cykl życia ryzyka: aktualizacja przy każdej zmianie w OT
Środowisko OT rzadko zmienia się co tydzień jak systemy biurowe, ale każda modernizacja linii, nowy sterownik, upgrade SCADA czy podłączenie zdalnego monitoringu zmienia profil ryzyka. Dlatego analiza ryzyka nie powinna być jednorazowym projektem „pod audyt”, tylko:
- aktualizowana przy każdej istotnej zmianie infrastruktury,
- przeglądana regularnie (np. raz w roku) z udziałem OT i bezpieczeństwa,
- powiązana z procesem zarządzania zmianą – bez oceny wpływu na ryzyko zmiana nie powinna przejść.
To podejście wymaga dyscypliny, ale szybko się zwraca: znacznie trudniej wtedy „przemycić” rozwiązanie, które otwiera nowy wektor ataku, bo ktoś chciał mieć „szybki zdalny dostęp, by było wygodniej”.
Architektura bezpieczeństwa: segmentacja, strefy i zasady dostępu
Model stref i kondujtów – fundament odpornej architektury OT
W świecie OT bardzo dobrze sprawdza się koncepcja stref i kondujtów (z IEC 62443). W praktyce chodzi o to, aby:
- podzielić środowisko na strefy – logiczne obszary o podobnym profilu ryzyka i podobnych wymaganiach bezpieczeństwa (np. strefa sterowania, strefa nadzoru, strefa biurowa, strefa zdalnych dostępów),
- ściśle kontrolować kondukty – czyli połączenia pomiędzy strefami (firewalle, bramy aplikacyjne, serwery pośredniczące).
Zamiast jednego „wielkiego płaskiego ethernetu” w zakładzie powstaje architektura warstwowa. Nawet jeżeli malware pojawi się w jednej strefie, trudniej mu będzie rozlać się na całą infrastrukturę. Typowy model może obejmować m.in.:
- strefę korporacyjną IT (biura, systemy ERP, poczta),
- strefę DMZ OT – z serwerami pośredniczącymi, historią danych, serwerami raportowymi,
- strefę systemów SCADA i serwerów nadrzędnych,
- strefy poszczególnych linii lub obiektów (PLC, HMI, I/O),
- strefę zdalnego serwisu i dostępu dostawców.
Ten podział można realizować etapami, np. zaczynając od wydzielenia DMZ OT i rozdzielenia ruchu IT–OT w sposób kontrolowany. Każda kolejna „ścianka ogniowa” ogranicza zasięg potencjalnego incydentu.
Segmentacja sieci OT krok po kroku
W wielu zakładach segmentacja brzmi jak ambitny projekt, który „może kiedyś”. W praktyce da się go zrealizować iteracyjnie:
- Inwentaryzacja połączeń – zidentyfikowanie wszystkich tras komunikacji między IT, OT i zewnętrznymi partnerami; spisanie, jaki ruch jest naprawdę potrzebny,
- Wydzielenie DMZ OT – umieszczenie serwerów SCADA raportujących do IT, serwerów OPC, systemów zbierania danych w wydzielonej strefie z firewallami po obu stronach,
- Rozdzielenie linii/obiektów – podział sieci produkcyjnej na podsieci per linia, hala, obiekt lub proces, z kontrolą ruchu między nimi,
- Segmentacja logiczna – nawet tam, gdzie fizycznie nic nie da się szybko przebudować, można zastosować VLAN-y, ACL-e i listy kontroli ruchu na przełącznikach.
Kluczowe jest, by nie blokować krytycznego ruchu technologicznego. Dlatego zmiany trzeba poprzedzać analizą i testami, najlepiej we współpracy z inżynierami automatyki oraz dostawcami systemów. Zespół OT nie może dowiedzieć się o nowym firewallu dopiero wtedy, gdy linia stanie.
Zasady dostępu: od „wszyscy wszystko” do minimum uprawnień
Kolejny filar odpornej architektury to kontrola dostępu. W wielu zakładach wciąż funkcjonują wspólne konta „operator”, „inżynier”, hasła wpisywane na kartkach i loginy, które znają wszyscy od 10 lat. To idealne środowisko dla agresora – albo dla przypadkowych błędów.
Zamiast tego warto przejść na:
- indywidualne konta użytkowników (również w systemach SCADA, HMI i narzędziach inżynierskich),
- zasadę minimum uprawnień – każdy ma dostęp tylko do tego, czego potrzebuje do swojej roli,
- rozsądne rozdzielenie ról – inne uprawnienia dla operatora, inne dla inżyniera automatyka, inne dla administratora systemu,
- silne uwierzytelnianie dla kont uprzywilejowanych (MFA, tokeny, klucze sprzętowe),
- rejestrowanie i przegląd logów działań kont uprzywilejowanych.
W jednym z zakładów przemysłowych dopiero po wdrożeniu indywidualnych kont i prostego systemu zatwierdzania zmian w konfiguracji sterowników okazało się, jak często „na szybko” ktoś dogrywał zmiany, nie zostawiając po sobie śladu. Po uporządkowaniu dostępu spadła liczba nieplanowanych przestojów – nie dzięki magii, tylko dzięki temu, że zmiany były wreszcie kontrolowane.
Świadome zrozumienie własnego środowiska – gdzie kończy się klasyczne IT, a zaczyna OT, jakie komponenty ICS i SCADA naprawdę są używane – pozwala projektować ochronę infrastruktury krytycznej jako całość, a nie zbiór przypadkowych „łat”. Jeśli potrzebne jest głębsze zanurzenie się w temat, dobrym punktem wyjścia są serwisy branżowe opisujące więcej o cyberbezpieczeństwo z perspektywy technologii i biznesu.
Zarządzanie zdalnym dostępem i dostawcami
Kontrola dostępu zdalnego krok po kroku
Zdalny dostęp do OT jest dziś często koniecznością – serwis dostawcy, wsparcie 24/7, praca kilku zakładów z jednego centrum. Problem zaczyna się wtedy, gdy „tymczasowo” otwarty tunel VPN zostaje na stałe, a login serwisowy znają wszyscy. Bez uporządkowania tego obszaru cała segmentacja traci sens.
Praktyczne podejście do zdalnego dostępu obejmuje kilka jasnych zasad:
- brak bezpośrednich połączeń z internetu do sieci OT – zdalne sesje przechodzą przez bezpieczną bramę (jump server, bastion) umieszczoną w DMZ OT,
- tymczasowe, przydzielane na żądanie dostępy – na określony czas, do konkretnych systemów, z zatwierdzeniem przez odpowiedzialną osobę,
- pełna rejestracja sesji zdalnych (kto, kiedy, do jakiego hosta, jakie komendy),
- silne uwierzytelnianie (MFA) dla wszystkich kont zdalnych, również dostawców,
- oddzielenie dostępu administracyjnego od użytkowego – inne kanały, inne konta, inne poziomy zabezpieczeń.
Dobrą praktyką jest zastosowanie rozwiązań klasy PAM (Privileged Access Management) dla dostępu uprzywilejowanego. System taki:
- pośredniczy w połączeniu (dostawca nie zna bezpośrednich haseł do sterowników czy SCADA),
- umożliwia nagrywanie sesji – przy incydencie można prześledzić, co faktycznie zostało zrobione,
- pozwala na wymuszanie rozdzielenia obowiązków – jedna osoba zatwierdza, inna realizuje.
Po wdrożeniu kontrolowanego zdalnego dostępu w jednym z centrów dystrybucyjnych liczba „nagłych” nocnych telefonów od dostawców znacząco spadła. Zamiast chaosu: jasna procedura, okno serwisowe, logi. Wygrywa i bezpieczeństwo, i komfort pracy zespołu.
Jeśli w Twojej infrastrukturze „tymczasowe” VPN-y działają od lat, to jest świetny kandydat na pierwszy projekt porządkowy.
Bezpieczna współpraca z dostawcami i integratorami
Dostawcy systemów OT, automatyki i SCADA są nieodłącznym elementem krajobrazu infrastruktury krytycznej. Jednocześnie bywają najsłabszym ogniwem – często to oni przynoszą malware na laptopach serwisowych albo korzystają z przestarzałych kont technicznych.
Zamiast traktować ich jako „gości specjalnych”, lepiej wdrożyć przejrzyste zasady:
- umowy serwisowe zawierają wymagania cyberbezpieczeństwa (szyfrowanie, aktualizacje, sposób logowania, czas przechowywania logów, procedury incydentowe),
- osobne konta dla każdego dostawcy / firmy, bez współdzielonych „serwis”, „vendor”,
- czasowo ograniczone uprawnienia – dostęp jest aktywowany tylko na okres wykonywania prac,
- wymóg aktualnego oprogramowania ochronnego na laptopach serwisowych (AV/EDR, aktualny system, szyfrowanie dysku),
- obowiązek zgłaszania incydentów – jeśli dostawca ma wyciek haseł czy ransomware, musi poinformować o tym operatora.
Dobrym narzędziem są checklisty wejścia na obiekt dla ekip serwisowych: jakie urządzenia mogą wpiąć do sieci, jakie oprogramowanie mogą instalować, z kim konsultują zmiany w konfiguracji. Kilka stron precyzyjnych zasad ratuje potem tygodnie walki ze skutkami „niewinnej” aktualizacji.
Jeśli dostawca twierdzi, że „inaczej się nie da”, negocjuj – masz prawo oczekiwać takiego modelu serwisu, który nie rozwala Twojej strategii bezpieczeństwa.
Bezpieczne aktualizacje i zmiany konfiguracyjne
W OT aktualizacje bywają traktowane jak zło konieczne. „Działa, nie ruszaj” to szybka droga do sytuacji, w której sterownik czy serwer SCADA nie jest łatany przez dekadę. Z drugiej strony, niekontrolowany patch może zatrzymać linię. Potrzebny jest świadomy kompromis.
Praktyczne elementy takiego podejścia:
- plan aktualizacji – lista systemów OT z określoną częstotliwością przeglądu poprawek (np. raz na kwartał),
- środowisko testowe lub pilotażowe – choćby w minimalnym zakresie, aby sprawdzić, czy łatka nie psuje kluczowej funkcji,
- okna serwisowe – uzgodnione z produkcją, najlepiej w godzinach najmniejszego obciążenia,
- procedura wycofania zmian (rollback) – zdefiniowana przed wdrożeniem, z kopią konfiguracji i planem powrotu,
- rejestr zmian – kto, kiedy, jaki patch, na jaki system; przy incydencie to często złoto.
Część systemów OT może nie pozwalać na regularne łatki systemowe. W takich przypadkach trzeba „opakować” je dodatkowymi warstwami zabezpieczeń:
- ściśle kontrolować ruch sieciowy wokół nich (microsegmentacja, reguły „allow-list”),
- wyłączyć wszystkie zbędne usługi i porty,
- ograniczyć dostęp administracyjny do minimum,
- stosować whitelisting aplikacji – tylko zatwierdzony kod może się wykonać.
Każda zaplanowana, przetestowana aktualizacja to jeden problem mniej w przyszłości – nawet jeśli dziś wymaga to dodatkowego wysiłku.
Monitorowanie i wykrywanie zagrożeń w OT
Nawet najlepsza segmentacja i kontrola dostępu nie zastąpią świadomości tego, co faktycznie dzieje się w sieci. W OT wyzwanie polega na tym, że klasyczne rozwiązania IT (np. agresywne skanery) mogą zakłócić pracę urządzeń. Potrzebne są narzędzia i metody dostosowane do świata sterowników i protokołów przemysłowych.
Podstawą jest:
- zbieranie logów z kluczowych komponentów OT (serwery SCADA, stacje inżynierskie, firewalle, systemy zdalnego dostępu),
- monitoring ruchu sieciowego w trybie pasywnym – sonda podłączona np. do portu SPAN na przełączniku, bez ingerencji w ruch,
- korelacja zdarzeń w systemie SIEM lub wyspecjalizowanej platformie OT, aby wykrywać anomalie, a nie tylko pojedyncze alerty.
Coraz większą rolę odgrywają rozwiązania NDR/IDS dla OT, które „rozumieją” Modbus, PROFINET, DNP3, IEC 60870-5-104 i inne protokoły przemysłowe. Potrafią:
Jeśli interesują Cię konkrety i przykłady, rzuć okiem na: Jak dbać o bezpieczeństwo fizyczne serwerowni?.
- zbudować bazową mapę ruchu – kto z kim, jakimi komendami, jak często,
- wykrywać anomalie – nagłe zmiany wzorców, nieznane urządzenia, nietypowe komendy do PLC,
- sygnalizować podejrzane próby skanowania lub brute-force na interfejsach OT.
W jednym z przedsiębiorstw energetycznych pierwsze wdrożenie sondy OT pokazało „cichego bohatera” – stary laptop automatyka, który po każdym podłączeniu wysyłał w sieć broadcasty z archaicznym protokołem, powodując losowe opóźnienia. Źródłem nie był atak, ale realny problem stabilności. Monitoring pomógł i w bezpieczeństwie, i w niezawodności.
Jeżeli dziś nikt nie patrzy na bieżąco na zachowanie sieci OT, pierwszym krokiem może być choćby dedykowany dashboard z kilku kluczowych punktów – to już ogromny skok jakościowy.
Integracja monitoringu IT i OT
Atak rzadko zaczyna się od razu w sterowniku. Częściej napastnik najpierw zdobywa przyczółek w IT – przez phishing, słabe hasło VPN, podatny serwer WWW – a dopiero potem szuka drogi do OT. Dlatego oddzielne „silosy” monitoringu powodują, że nikt nie widzi całego obrazu.
Przydatne elementy integracji:
- wspólny SIEM lub minimum mechanizm wymiany zdarzeń między systemami IT i OT,
- uzgodnione wzorce korelacji – np. logowanie z konta administratora z nietypowej lokalizacji + anomalie w ruchu do DMZ OT,
- wspólne procedury reagowania – SOC IT wie, kiedy musi zadzwonić do inżyniera OT, a zespół OT wie, jakie alerty z IT są dla nich krytyczne,
- regularne ćwiczenia z udziałem obu zespołów – choćby raz w roku symulacja scenariusza „atak z IT przechodzi do OT”.
Nawet jeśli technicznie korzystasz z dwóch różnych platform, kluczowe jest, by odpowiednie alerty trafiały do jednego stołu – tam, gdzie siedzą ludzie podejmujący decyzje.
Bezpieczeństwo stacji roboczych i serwerów OT
Stacje inżynierskie, serwery SCADA, komputery HMI – to często najbardziej wrażliwe elementy OT, bo łączą „świat Windowsa” z krytycznym procesem. Na nich pojawiają się pendrive’y, kopiowane są projekty sterowników, przeglądane są strony dostawców.
Kilka praktycznych zasad:
- dedykowane stacje OT – nieużywane do poczty, internetu, biurowych aplikacji,
- twarde hardeningi systemu – wyłączenie zbędnych usług, blokada automatycznego uruchamiania nośników, ograniczenie praw lokalnych,
- kontrola nośników wymiennych – skanowanie w specjalnym „kiosku” AV w strefie buforowej przed wpięciem do OT,
- ochrona typu EDR dostosowana do wymogów OT (tryb monitoringu, testy przed wdrożeniem, wyłączone agresywne funkcje, które mogą wywołać przestój),
- regularne kopie zapasowe maszyn i konfiguracji – z testem odtwarzania, nie tylko samym „robieniem backupu”.
Na wielu obiektach wystarczyło odseparować stacje inżynierskie od internetu i wdrożyć prosty proces skanowania pendrive’ów, aby zlikwidować większość incydentów związanych z malware. To szybkie działania o dużym wpływie.
Backup i odtwarzanie po incydencie w OT
Kopie zapasowe w OT to coś więcej niż backup plików. Liczą się obrazy całych systemów, konfiguracje PLC, receptury, projekty sterowników. Bez nich nawet najlepszy plan reagowania zamieni się w tygodnie „odbudowy z niczego”.
Przy planowaniu kopii zapasowych w infrastrukturze krytycznej przydaje się kilka prostych pytań:
- czy posiadamy aktualne kopie konfiguracji wszystkich kluczowych PLC/HMI/SCADA?,
- gdzie są przechowywane – czy jest izolowana kopia offline (np. nośnik w sejfie, odłączony system backupowy)?,
- kto i jak często testuje odtwarzanie – choćby na jednym sterowniku czy serwerze?,
- czy mamy udokumentowaną procedurę odtwarzania krok po kroku – również dla sytuacji, gdy część personelu jest niedostępna?
Warto rozdzielić:
- backup operacyjny – z którego odtwarza się dane procesowe, raporty, logi,
- backup awaryjny – minimalny zestaw obrazów i konfiguracji potrzebnych do przywrócenia sterowania i możliwości uruchomienia procesu.
Naprawdę skuteczny jest tylko taki backup, który był już choć raz przetestowany w boju – w kontrolowanych warunkach, zanim zrobi to za nas prawdziwy incydent.
Szkolenia i ćwiczenia dla personelu OT i operatorskiego
Technologia nie wystarczy, jeśli ludzie na zmianie nie wiedzą, co zrobić, gdy „coś dziwnego” dzieje się na ekranie HMI czy w rozdzielni. W infrastrukturze krytycznej czas reakcji i jasność decyzji decydują, czy atak skończy się na kilku godzinach zamieszania, czy na realnym kryzysie.
Program budowania kompetencji powinien obejmować:
- szkolenia podstawowe dla całego personelu OT i utrzymania ruchu – rozpoznawanie symptomów ataku, zasady zgłaszania, bezpieczne korzystanie z kont i nośników,
- szkolenia specjalistyczne dla inżynierów automatyki i administratorów – analityka zdarzeń, narzędzia monitoringu, procedury odcięcia segmentów sieci,
- ćwiczenia scenariuszowe (table-top) – wspólne przejście przez hipotetyczny incydent: co robimy, kto decyduje, kiedy zatrzymujemy proces, jak komunikujemy się z zewnętrznymi służbami,
- proste materiały „na ścianę” – schemat kontaktów, numery alarmowe, krótkie „ABC incydentu” przy panelach HMI i w sterowni.
Najczęściej zadawane pytania (FAQ)
Co dokładnie zalicza się do infrastruktury krytycznej w cyberbezpieczeństwie?
Infrastruktura krytyczna to wszystkie systemy, których zakłócenie realnie uderza w bezpieczeństwo państwa, zdrowie ludzi, gospodarkę lub porządek publiczny. Chodzi m.in. o energetykę, gaz, ciepłownictwo, wodociągi i kanalizację, transport, telekomunikację, służbę zdrowia, bankowość, administrację publiczną czy gospodarkę odpadami.
Z perspektywy cyberbezpieczeństwa to połączenie klasycznych systemów IT (poczta, ERP, CRM, systemy kadrowo‑płacowe) z systemami OT/ICS – automatyką przemysłową, sterowaniem, zabezpieczeniami i pomiarami w terenie. Im lepiej rozumiesz, jakie elementy są naprawdę „krytyczne”, tym łatwiej ustawisz priorytety ochrony.
Dlaczego cyberprzestępcy atakują infrastrukturę krytyczną?
Ataki na infrastrukturę krytyczną dają przestępcom silny efekt: mogą wymusić wysoki okup, sparaliżować miasto lub region, wywrzeć presję polityczną albo zebrać dane na czas przyszłego konfliktu. To już nie tylko szybka kradzież danych, ale długotrwałe kampanie (APT), które potrafią rozwijać się miesiącami, zaczynając od jednego słabego punktu.
Dodatkowy magnes to fakt, że wiele tych systemów jest przestarzałych, łączy IT z OT i bywa źle nadzorowanych. Dla atakującego to idealne środowisko: wysoka stawka, a jednocześnie sporo luk. Im szybciej to zaakceptujesz, tym szybciej zaczniesz wzmacniać najsłabsze miejsca, zamiast liczyć na szczęście.
Jakie są realne skutki cyberataku na infrastrukturę krytyczną?
Najbardziej odczuwalne skutki to przerwy w dostawach prądu, wody, gazu czy ciepła dla tysięcy odbiorców. Pojawiają się dodatkowe koszty operacyjne: awaryjne tryby pracy, nadgodziny, wynajmowanie sprzętu zastępczego. Do tego dochodzi utrata zaufania społecznego oraz presja regulatora i organów nadzoru.
Trzeba brać pod uwagę efekt domina: awaria systemu rozliczeń uderza w dostawców, problemy w telekomunikacji – w służby ratunkowe, a kłopoty wodociągów – w przemysł, gastronomię, szkoły i szpitale. Każdy krok w stronę lepszej ochrony to nie tylko „bezpieczniejsza sieć IT”, ale mniej kryzysów organizacyjnych i wizerunkowych.
Czy małe i średnie firmy też mogą być celem ataków na infrastrukturę krytyczną?
Tak, i to bardzo często. Średnie spółki komunalne, lokalne wodociągi, ciepłownie, operatorzy transportu czy prywatne placówki medyczne coraz częściej są „krytyczne” w praktyce, nawet jeśli formalnie nie mają takiego statusu. Ich systemy są zazwyczaj słabiej zabezpieczone, ale ich zatrzymanie potrafi sparaliżować całe miasto.
Atakujący chętnie wykorzystują je jako słabe ogniwo łańcucha dostaw – np. przez przejęcie konta VPN firmy serwisującej automatykę. Z ich sieci infiltrują stopniowo systemy dużego operatora. Jeśli jesteś „średnim graczem”, traktuj swoje cyberbezpieczeństwo jak tarczę, która chroni nie tylko ciebie, ale też twoich największych klientów.
Od czego zacząć zabezpieczanie systemów OT/ICS i SCADA przed cyberatakami?
Pierwszy krok to pełna inwentaryzacja: jakie systemy działają (SCADA, PLC, RTU, HMI, czujniki), jak są połączone i kto ma do nich dostęp. Bez tej wiedzy każda inwestycja w bezpieczeństwo będzie strzelaniem na oślep. Kolejny krok to rozdzielenie i segmentacja sieci IT i OT oraz ograniczenie dostępu tylko do niezbędnych ścieżek.
W praktyce ogromny efekt dają proste działania: indywidualne konta zamiast współdzielonych loginów, wieloskładnikowe uwierzytelnianie do zdalnego dostępu, zakaz korzystania z prywatnych laptopów do łączenia się z SCADA, stałe monitorowanie logów oraz testy incydentowe. Wybierz 2–3 obszary o najwyższym ryzyku i zacznij wzmacniać je od razu.
Jak pogodzić wymagania bezpieczeństwa IT z ciągłością pracy systemów OT?
W świecie IT priorytetem jest poufność i integralność danych, w OT – bezpieczeństwo ludzi, środowiska i nieprzerwany proces technologiczny. Bez zrozumienia tej różnicy każda „kopiuj‑wklej polityka z IT” wywoła konflikt z utrzymaniem ruchu. Zamiast tego potrzebny jest wspólny model ryzyka, w którym obie strony jasno definiują, co jest nienaruszalne.
Dobrym podejściem jest stopniowe podnoszenie poziomu bezpieczeństwa OT: testowanie aktualizacji na bliźniakach systemu, planowane okna serwisowe, dodatkowe warstwy ochrony sieciowej (strefy, firewalle, diody danych) i procedury awaryjnego przejścia na tryb ręczny. Gdy IT i OT wspólnie planują zmiany, rośnie zarówno poziom bezpieczeństwa, jak i komfort pracy zespołów.
Jakie konkretne działania minimalizują ryzyko ataku typu APT na infrastrukturę krytyczną?
Przy kampaniach APT kluczowe są: kontrola dostępu (szczególnie zdalnego), segmentacja sieci, monitoring anomalii oraz szybka reakcja na drobne sygnały (dziwne logowania, nieznane połączenia z zewnątrz). Takie ataki rozwijają się powoli, więc twoim atutem jest wykrycie ich na wczesnym etapie, zanim dotrą do systemów sterowania.
W praktyce warto wdrożyć kilka filarów: silne uwierzytelnianie, zasada najmniejszych uprawnień, regularne audyty konfiguracji, szkolenia dla personelu technicznego oraz jasno przećwiczony plan reagowania na incydenty. Każdy z tych elementów to dodatkowa przeszkoda dla atakującego i większa szansa, że to ty zakończysz jego kampanię, zanim on zrealizuje swój cel.
Najważniejsze wnioski
- Infrastruktura krytyczna to nie tylko elektrownie, ale cały ekosystem usług podstawowych – od wodociągów, przez szpitale i transport, po bankowość i gospodarkę odpadami – a jej zakłócenie uderza bezpośrednio w bezpieczeństwo i komfort życia mieszkańców.
- Nowoczesna infrastruktura krytyczna to połączenie systemów IT z systemami OT/ICS, co tworzy złożone środowisko, w którym błąd konfiguracyjny albo pojedynczy wyciek hasła może skończyć się realnymi przerwami w dostawach prądu, wody czy ciepła.
- Profil zagrożeń przesunął się z prostych awarii na zorganizowane, długotrwałe kampanie cyberataków (APT), ukierunkowane na okup, sabotaż, szpiegostwo i presję polityczno-gospodarczą – a granica między grupami przestępczymi a atakami sponsorowanymi przez państwa praktycznie się zaciera.
- Skuteczny atak na infrastrukturę krytyczną wywołuje efekt domina: od przerw w dostawach mediów i utraty zaufania społecznego, przez odpowiedzialność prawną zarządzających, po wtórne szkody jak wypadki, opóźnione zabiegi czy zatrzymanie produkcji u zależnych firm.
- Średnie przedsiębiorstwa i podwykonawcy są wygodnym celem, bo działają w łańcuchu dostaw dużych operatorów, mają słabsze zabezpieczenia i często korzystają z prostych, współdzielonych dostępów zdalnych, które otwierają atakującym drogę do sieci krytycznych.





