Artykuł pochodzi z wydania: Styczeń 2026
Środowiska OT przestały być zamkniętymi wyspami. Systemy DCS, SCADA, sterowniki PLC i cała automatyka zakładowa zaczęły już dawno korzystać z Ethernetu, TCP/IP, serwerów z Windowsem czy Linuksem i standardowego sprzętu sieciowego. Z tego powodu admini i specjaliści cyberbezpieczeństwa IT nie mogą już traktować szafy z PLC jako kawałka nieswojej sieci, do którego zagląda tylko inżynier pracujący w zakładzie dłużej niż suma lat życia wszystkich w dziale IT.
To, co kiedyś było odizolowaną instalacją z RS-ami i protokołem znanym tylko konkretnemu vendorowi, dziś bardzo często jest kolejną podsiecią w infrastrukturze korporacyjnej. Warto zatem odpowiedzieć sobie na pytanie, jak połączyć klasyczną logikę segmentacji LCN, CLAN i DMZ z obecnymi wymaganiami związanymi z zagrożeniami dla OT ze strony ransomware, atakami na łańcuchy dostaw, wymogami IEC 62443 i NIS 2. Należy również ustalić, jaka powinna być rola SOC, co powinien widzieć w strefach automatyki przemysłowej, a także co zrobić i jak kontrolować zdalny dostęp serwisantów.
> ICS, SCADA, DCS – PERSPEKTYWA BEZPIECZEŃSTWA
W typowym zakładzie przemysłowym funkcjonuje kilka elementów technologicznych, które dla bezpieczeństwa mają inne znaczenie niż zwykłe serwery. PLC i RTU to lokalne sterowniki, które odczytują sygnały z czujników i wystawiają komendy na zawory, napędy czy przekaźniki. Z punktu widzenia bezpieczeństwa to sprzęt z długoletnim cyklem życia, w którym firmware jest rzadko aktualizowany. Brak też standardowych mechanizmów hardeningu. Nierzadko spotkamy się ze specyficznymi protokołami. Natomiast DCS, czyli Distributed Control System, jest zintegrowanym systemem sterowania procesem technologicznym. Zawiera serwery procesowe, stacje operatorskie, inżynierskie i sieć procesową. Z praktycznego punktu widzenia jest centrum sterowania produkcji, a jego zatrzymanie bardzo szybko przekłada się na przestój instalacji.
SCADA pełni zwykle rolę nadzorczą nad większym obszarem, z wieloma obiektami rozproszonymi, spiętymi przez różnego typu łącza, w tym WAN czy GSM. To rozwiazanie koncentruje się raczej na monitoringu i raportowaniu, z zachowaniem możliwości sterowania. Nad tym wszystkim czuwają stacje operatorskie HMI, zazwyczaj z systemem Windows i aplikacją vendora. To na nich operator widzi stany pomiarów, potwierdza alarmy i wydaje polecenia. Jeżeli HMI przestaje działać, operator nie może kontrolować procesu.
Tradycyjnie sieć sterowania, określana jako Local Control Network (LCN), była odseparowana od sieci biurowej Corporate LAN (CLAN). LCN miał być możliwie prosty, natomiast CLAN mógł zawierać całą domenę AD, pocztę, internet, systemy biznesowe. Wiele zakładów nadal tak myśli o swojej architekturze, ale w praktyce granica między LCN i CLAN coraz bardziej się rozmywa i coraz trudniej wprowadzać generalną zasadę wszystkiego na deny lub politykę uciętych kabelków łączących LCN z CLAN. Dzisiaj LCN nadal nie jest tym samym co CLAN, jednak prosty podział na dwa segmenty sieci przestaje wystarczać. Zamiast jednego LCN-u i jednego CLAN-u potrzebujemy myślenia w kategoriach stref i kanałów komunikacyjnych. Najlepiej zerknąć do normy IEC 62443, która dodatkowo pozwoli odpowiedzieć na wymagania NIS 2. Uzyskanie faktycznej segmentacji, z realnymi przepływami i kontrolowaną rolą SOC wraz z monitorowaniem sieci, wymaga przemyślanej architektury, dobrych procedur i funkcji wymuszających zgodność na poziomie technicznym.
> OD LCN/CLAN DO ZARZĄDZANIA STREFAMI I KANAŁAMI
Często możemy spotkać się jeszcze z prostą architekturą (uzasadnianą w wielu przypadkach kosztami), w ramach której w sieci OT umiejscowione są systemy DCS, SCADA, HMI, stacje operatorskie i inżynierskie wraz ze sterownikami. Do tego (rzadziej) DMZ OT z serwerem historian, raportowaniem i integracją do MES czy ERP. Z drugiej strony sieci sieć biurowa z userami, systemami biznesowymi i dostępem do internetu. Całość podzielona jednym firewallem, z nawet rozsądną konfiguracją reguł (i z listą wyjątków rosnącą co roku). Aktualne podejście, jeśli chcemy w ogóle mówić o implementacji IEC 62443, wymaga większej precyzji. Zamiast jednej wielkiej sieci OT potrzebujemy wyraźnie zdefiniowanych stref: osobnej dla core’u DCS/SCADA, warstwy PLC, DMZ OT i usług pomocniczych. Te ostatnie to backupy, serwery licencji czy serwery z usługami bezpieczeństwa. Między tymi strefami powinny istnieć zdefiniowane kanały komunikacyjne, w których określamy, jakie protokoły przepuszczamy, w którym kierunku oraz co i jak będziemy kontrolować oraz monitorować.
W praktyce najczęściej sprawdza się model z dwoma firewallami. Pierwszy stoi pomiędzy siecią korporacyjną a DMZ OT i przepuszcza wyłącznie połączenia z CLAN do usług w DMZ OT, takich jak raportowanie, webowe panele czy API do integracji. Wyjątkiem jest ruch z DMZ OT do rozwiązań takich jak SIEM czy XDR, a także do innych narzędzi SOC-a wewnętrznego i zewnętrznego. Taki ruch jest zwykle inicjowany od strony DMZ OT. Drugi firewall stoi pomiędzy DMZ OT a strefami OT. Jego reguły są znacznie bardziej restrykcyjne i obejmują tylko niezbędne kanały, np. ruch serwera historian do serwerów procesowych lub połączenia z hosta przesiadkowego do stacji inżynierskich. Niestety w wielu organizacjach mamy jeszcze do czynienia z pojedynczym firewallem z forwardami ruchu pomiędzy CLAN i LCN, bez wydzielonej DMZ OT. Z punktu widzenia IEC 62443 jest to sieć płaska. Niestety taką architekturę bezpieczeństwa sieci wykorzystuje często ransomware lub inny malware wchodzący z IT do OT, który może dzięki temu zyskać prostą drogę na znajdujące się w OT stacje, serwery czy HMI.
[…]
Artur Cieślik
Autor jest audytorem wiodącym norm ISO/IEC 27001, ISO 22301 oraz Certified Information Systems Auditor (CISA). Specjalizuje się w audycie bezpieczeństwa informacji, projektowaniu i wdrażaniu Systemów Zarządzania Bezpieczeństwem Informacji. Redaktor naczelny miesięcznika „IT Professional”, a także członek Stowarzyszenia Inspektorów Ochrony Danych i rady programowej kwartalnika „ABI Expert”.
