Gdzie realnie boli: produkcja staje przez sieć biurową
Typowe objawy przed segmentacją
Operatorzy skarżą się, że panele HMI reagują z opóźnieniem po godzinie 9:00. Aktualizacja Windows w biurze powoduje nagły skok ruchu w całym zakładzie i niewytłumaczalne restarty sterowników. Zdalny serwisant loguje się na PLC po zwykłym VPN-ie, a dział IT nie ma pojęcia, jakie porty i protokoły właśnie przepuszcza. Środowisko testowe MES w biurze przypadkiem łączy się z produkcyjną bazą danych. Po incydencie ransomware w dziale księgowości linia pakująca staje, bo serwer licencji OEM stał w tej samej podsieci. To codzienne sygnały, że sieć OT i IT przenikają się bez kontroli.
Co chcesz osiągnąć minimalnym wysiłkiem
Celem jest oddzielenie produkcji od biura tak, aby:
- awarie i aktualizacje w biurze nie dotykały linii;
- ruch między strefami był mierzony, filtrowany i ograniczony do niezbędnych protokołów;
- udokumentować, kto i kiedy ma dostęp do urządzeń OT oraz jak;
- wdrażać zmiany bez przestoju, etapami i z planem powrotu.
Pięć pytań, na które potrzebujesz szybkich odpowiedzi
- Jakie urządzenia i systemy muszą się komunikować między OT a IT, i po jakich portach/protokołach?
- Gdzie dziś jest fizyczna granica między halą a biurem (przełączniki, routery, łącza)?
- Który element jest kluczowy dla dostępności (PLC, SCADA, serwery licencji, Historian) i czego absolutnie nie można restartować w godzinach pracy?
- Jak zapewnić dostęp serwisantom i dostawcom bez dawania im pełnego VPN-a do wszystkiego?
- Czy budżet i czas pozwalają na wdrożenie od razu firewalli z DPI dla protokołów OT, czy zaczynamy od VLAN-ów i list ACL?
Skąd biorą się kłopoty z mieszaniem OT i IT
Przyczyna 1: Inny model zaufania i inne protokoły
Świat IT zakłada, że usługi są wymienialne, użytkownicy rotują, a systemy można łatwo odtworzyć. Świat OT to urządzenia, które działają latami, często bez patchy i z oczekiwaniem „dotykaj jak najrzadziej”. Dodatkowo protokoły OT (Modbus/TCP, EtherNet/IP, PROFINET, DNP3) nie mają natywnych mechanizmów bezpieczeństwa. Gdy te dwa światy współistnieją w jednej płaskiej sieci, każde skanowanie portów, agresywne systemy EDR czy standardowe discovery z IT potrafią destabilizować urządzenia produkcyjne.
Przyczyna 2: Dostępność ważniejsza niż poufność
W biurze przerwa w dostępie do dysku sieciowego to niedogodność. Na linii przerwa to realny koszt przestoju. Z tego powodu zmiany w sieci bez planu okna serwisowego są ryzykowne: nieprzemyślany restart agregującego przełącznika może wyłączyć kilka stref produkcyjnych na raz.
Przyczyna 3: Dziedzictwo i vendor lock-in
Wiele rozwiązań OT to starsze systemy, z twardo zakodowanymi adresami IP, bez wsparcia 802.1X czy nowych szyfrowań. Często producent wymaga „pełnego dostępu” do zdalnej diagnostyki. Bez segmentacji oznacza to otwarcie całej sieci na zewnętrzny dostęp lub stosowanie doraźnych obejść, które później nikt nie dokumentuje.
Model docelowy: segmentacja bez zatrzymywania pracy
Strefy i obszary zgodnie z ISA/IEC 62443
Sprawdzony schemat to podział na strefy (o podobnym profilu ryzyka) i kanały komunikacji między nimi. Minimalnie wyodrębniasz:
- Strefę OT-Process: PLC, HMI, sieć polowa, urządzenia krytyczne.
- Strefę OT-Services: SCADA, Historian, serwer licencji, backup offline.
- Przemysłową DMZ: serwery pośredniczące, repozytoria aktualizacji, jump hosty.
- Strefę IT-Office: użytkownicy biurowi, usługi korporacyjne.
Każdy przepływ między strefami jest jawnie zdefiniowany i egzekwowany przez zaporę L3/L7, najlepiej z inspekcją protokołów OT. Dzięki takiej konstrukcji nie musisz od razu wymieniać całej infrastruktury: wprowadzasz bramę między światem produkcji a biura i porządkujesz ruch krok po kroku.
Przemysłowa DMZ, czyli bufor i punkt kontrolny
DMZ oddziela wrażliwe urządzenia od ruchu użytkowników. Umieszczasz w niej:
- serwer Historian i/lub replikę danych do ERP/MES;
- repozytorium podpisanych aktualizacji i białą listę narzędzi inżynierskich;
- serwer zdalnego dostępu (jump host) z MFA i nagrywaniem sesji;
- proxy dla usług (HTTP/HTTPS), brokera MQTT/AMQP, ewentualnie diodę jednokierunkową dla krytycznych instalacji.
Taki bufor pozwala na ściśle kontrolowany przepływ danych (np. tylko telemetryka z OT do IT), a jednocześnie separuje ruch użytkowników od urządzeń na hali.
Zero Trust po przemysłowemu
Zero Trust w OT nie oznacza kilku nowych licencji. To zasada: „nikt i nic nie ma dostępu, dopóki nie jest to potrzebne do pracy”. W praktyce:
- kontrola tożsamości urządzeń (NAC/MAB/802.1X dla sprzętu, certyfikaty dla systemów);
- najmniejszy możliwy zestaw portów między strefami, kierunek jednokierunkowy, jeśli się da;
- jump host jako jedyna droga administracji, bez routingu biuro → PLC;
- telemetria i alerting w czasie rzeczywistym zamiast pojedynczych logów na końcu miesiąca.
Trzy ścieżki wdrożenia zależnie od budżetu i czasu
Minimum na start: VLAN + ACL na L3 + prosty firewall
Najtańszy wariant, który często można wdrożyć w tydzień, bez wymiany sprzętu:
- Wyodrębnij VLAN dla OT-Process, osobny dla OT-Services i osobny dla DMZ. Zablokuj routing biuro ↔ OT-Process.
- Na routerze L3/przełączniku dystrybucyjnym skonfiguruj listy ACL przepuszczające tylko ruch konieczny (np. OT-Process → OT-Services, porty dla SCADA/OPC).
- Postaw prosty firewall między DMZ a IT-Office i ogranicz dostęp do usług pośrednich.
Efekt: 80% ryzyka usunięte małym kosztem. Ograniczenie: brak głębokiej inspekcji protokołów OT oraz słabsza widoczność. W praktyce jednak to najlepszy „pierwszy krok”, gdy budżet jest napięty, a przestoje niedopuszczalne.
Wariant zrównoważony: firewall z DPI OT + jump host + NAC na kluczowych portach
Dla średniego budżetu:
- Dedykowany firewall przemysłowy z obsługą DPI dla protokołów OT między OT-Process/OT-Services a DMZ.
- Jump host w DMZ z MFA, nagrywaniem sesji i białą listą narzędzi inżynierskich.
- NAC w trybie monitor lub MAB na portach w newralgicznych szafach, blokujący nieautoryzowane urządzenia.
Efekt: kontrola treści protokołów i dobry wgląd w ruch. Koszt wyższy, ale nadal bez wymiany całej warstwy dostępowej.
Wariant zaawansowany: mikrosegmentacja i SDN, diody jednokierunkowe
Dla instalacji krytycznych lub rozbudowanych kampusów:
- Mikrosegmentacja host-based (agent) dla serwerów OT-Services i DMZ, polityki aplikacyjne.
Wariant zaawansowany: mikrosegmentacja i SDN, diody jednokierunkowe (ciąg)
- Segmentacja sieciowa z VRF/VXLAN i sterowaniem ruchem (policy-based routing) pomiędzy strefami i obszarami linii.
- Diody jednokierunkowe lub bramy jednokierunkowe dla przepływów telemetrycznych OT → IT w instalacjach o najwyższej krytyczności.
- Parowane zapory w HA z planem przełączeń i testami w oknach serwisowych.
- Dedykowana sieć out-of-band do zarządzania przełącznikami, firewallami i serwerami OT-Services.
- System detekcji anomalii/IDS z regułami dla protokołów przemysłowych, podpięty do portów SPAN lub TAP-ów.
Efekt: pełna kontrola tras i zawartości ruchu plus separacja zarządzania. Ograniczenie: wyższy CAPEX i OPEX oraz potrzeba dyscypliny zmian (change management).
Jak dobrać poziom segmentacji do ryzyka i budżetu
Nie rób wszystkiego naraz. Dobierz wariant do ryzyka przestoju i dojrzałości zespołu.
- Jeśli linia nie może stanąć ani na minutę – inwestuj w DMZ + firewall z DPI już na starcie; VLAN-y i ACL-e zostaw jako wsparcie, nie jako jedyne zabezpieczenie.
- Jeśli główny problem to „biuro zalewa OT ruchem” – wystarczy VLAN + ACL oraz blokada biuro → OT-Process, a administrację przenieś na jump host.
- Jeśli masz wielu dostawców zdalnych – priorytetem jest jump host z MFA i rozdzielenie ścieżek dostępu od zwykłego VPN.
- Jeśli twój zespół nie ma stałej obserwowalności – dołóż choć SPAN + prosty NDR/IDS, żeby widzieć skutki polityk.
Szybka ścieżka decyzji
- Budżet niski, czas krótki: VLAN + ACL + prosty firewall + jump host.
- Budżet średni, ryzyko średnie/wysokie: firewall z DPI OT + NAC (monitor) + DMZ z repozytoriami.
- Ryzyko bardzo wysokie/krytyczna infrastruktura: mikrosegmentacja + HA + diody jednokierunkowe + out-of-band.
Wykorzystaj to, co już masz
- Na przełącznikach włącz port-security, DHCP snooping, storm-control – tanie i skuteczne ograniczenie „przypadkowych” podłączeń.
- Jeśli nie masz NAC: użyj MAB i białych list MAC na portach w szafach sterowniczych.
- Monitorowanie bez zakupów: skonfiguruj SPAN do kolektora logów/IDS i zacznij od podstawowych metryk.
Wdrożenie etapami bez przestoju
Plan minimalistyczny, który zwykle mieści się w 1–2 tygodniach roboczych bez zatrzymywania linii:
- Inwentaryzacja pasywna: SPAN na uplinku OT, zrzut ruchu 48–72 h. Spisz adresy, protokoły, kierunki.
- Wydzielenie VLAN-ów w warstwie dostępowej bez zmiany adresacji (najpierw tagi, potem stopniowe przepięcia portów).
- ACL-e na L3: zablokuj biuro → OT-Process; przepuść tylko znane przepływy do OT-Services/DMZ.
- Postaw DMZ: wprowadź jump host z MFA, repozytorium plików i proxy do usług.
- Przenieś administrację na jump host; wyłącz bezpośredni routing biuro → PLC/HMI.
- Dodaj firewall między OT a DMZ; zacznij w trybie monitor, potem enforcement.
- NAC/MAB na wybranych portach w szafach, zacznij od najkrytyczniejszych.
- Testy regresyjne poza produkcją i krótko po wdrożeniu: czasu cyklu PLC, opóźnienia HMI, kompletność danych w Historianie.
Dostęp serwisowy bez pełnego VPN
- Jump host w DMZ jako jedyna brama administracyjna (RDP/SSH), MFA i ograniczenie narzędzi do białej listy.
- Konta JIT (na czas) z automatycznym wygaśnięciem, separacja per-dostawca i per-projekt.
- Reguły per-urządzenie: sesja z jump hosta tylko do konkretnego PLC/HMI, bez ruchu rozgłoszeniowego.
- Jeśli budżet minimalny: wydziel osobny VPN tylko do DMZ, a z DMZ dalej wyłącznie przez jump host.
Jak sprawdzić, że segmentacja działa
- Spadek ruchu biuro → OT-Process do zera poza wyjątkami w ACL.
- Brak wzrostu czasu cyklu PLC i stałe opóźnienia HMI po godzinie 9:00.
- Kompletne dane w Historianie, stabilne czasy zapisu/odczytu po wdrożeniu firewalli.
- Logi: widoczne, regularne odrzucenia nieautoryzowanych połączeń oraz alerty z IDS.
- Sesje serwisowe wyłącznie przez jump host, z pełnym zapisem i rozliczalnością.
Pułapki, które zjadają budżet
- „Tymczasowe wyjątki” w firewallu, które zostają na stałe i znoszą segmentację.
- Mieszanie zarządzania sprzętem z ruchem procesu w tej samej strefie/VLAN-ie.
- Zmiany adresacji IP bez potrzeby – zacznij od VLAN-ów, adresację ruszaj na końcu, jeśli w ogóle.
- Brak bufora DMZ i wpychanie ERP/MES bezpośrednio w OT-Services.
- Wspólne konta „serwis” bez MFA – brak rozliczalności i trudna forensyka.
Krótki przykład z praktyki
Zakład miał jedną płaską podsieć, a HMI lagowały w szczycie biurowym. W pierwszym tygodniu wydzielono VLAN OT-Process i OT-Services, zablokowano routing biuro → OT-Process, a administrację przeniesiono na jump host w DMZ. Efekt po wdrożeniu ACL: stabilne HMI, a aktualizacje w biurze przestały wpływać na linię. Dopiero po miesiącu dołożono firewall z DPI dla lepszej widoczności – bez przestoju.
Rekomendacja dla decydenta o ograniczonym budżecie
Jeżeli potrzebujesz szybkiego, mierzalnego efektu: zrób VLAN + ACL i jump host w DMZ w pierwszej kolejności. To daje największy spadek ryzyka za najmniejsze pieniądze. Gdy sytuacja się ustabilizuje i będzie czas na obserwację, dołóż firewall z DPI pomiędzy OT a DMZ oraz NAC/MAB na kluczowych portach.
Na koniec: najczęstszy błąd, który zatrzymuje produkcję
Wprowadzenie zapory i nowych polityk bez wcześniejszego zmapowania przepływów oraz uruchomienia trybu monitorowania. Skutek to zablokowanie nieudokumentowanych, ale krytycznych komunikacji (np. serwera licencji albo synchronizacji SCADA), co kończy się przestojem. Najpierw pasywna inwentaryzacja i logowanie, dopiero potem egzekwowanie reguł – inaczej segmentacja zamieni się w sabotaż własnej dostępności.
Reguły ruchu w pigułce – szybkie wzorce, które działają
Zamiast setek wyjątków, trzy proste zasady porządkują 90% polityki:
- Domyślna blokada dla ruchu IT → OT-Process. Wyjątki tylko do sprawdzonych usług w OT-Services/DMZ.
- Ruch sterujący jednokierunkowy: master → urządzenie (SCADA/serwer inżynierski do PLC/HMI), bez ruchu peer-to-peer między liniami.
- Telemetria wychodzi z OT: dane i logi są wypychane do DMZ/IT (pull z DMZ lub broker w DMZ), nie odwrotnie.
Najczęstsze przepływy, które przepuszczasz celowo
- OT-Process → OT-Services: SCADA/Historian/serwery licencji; tylko konkretne adresy i porty, bez ruchu rozgłoszeniowego.
- OT-Services → DMZ: raporty, zrzuty zdarzeń, backupy; SFTP/HTTPS z wzajemną weryfikacją certyfikatów.
- DMZ → IT: jedynie interfejsy konsumpcyjne (API/ETL), bez bezpośrednich zapytań ERP/MES do PLC.
- NTP i syslog: z dedykowanych źródeł w OT-Services do urządzeń w OT-Process, nie z IT.
Co ścinasz do zera bez żalu: LLMNR/NetBIOS, SMB wprost do PLC, broadcasty i mDNS przez granice L3, auto-discovery spoza strefy.
Segmentacja bez psucia sieci deterministycznych
Problem: po wdrożeniu ACL/VRF HMI zaczyna „gubić” aktualizacje, a sterowniki gubią pakiety. Przyczyna zwykle jest prosta: zablokowany multicast/broadcast, zbyt wąskie okna portów lub dodatkowa latencja na granicy stref.
Jak to rozwiązać w praktyce
- Wyspy L2 dla czasu rzeczywistego: zostaw komunikację IRT/TSN w jednej domenie L2 wewnątrz komórki produkcyjnej; segmentację rób na wyjściu z komórki.
- IGMP snooping + querier na przełącznikach w OT-Process zamiast „open flood” multicastu przez L3.
- Precyzyjny czas: PTP jako boundary/transparent clock w szafach; nie przenoś PTP do IT.
- Bufor na granicy: na firewallu/Router ACL nie rób NAT dla ruchu sterującego; trzymaj stałe mapy portów i adresów.
- Test latencji: przed egzekwowaniem reguł zmierz jitter w cyklu PLC i odczytach HMI; jeśli > określonego progu, cofnij zmianę i rozbij ruch jeszcze bliżej źródła.
Krótki przykład: po włączeniu DPI dla EtherNet/IP zniknęły sporadyczne pakiety. Rozwiązanie: wyłączyć inspekcję na strumieniach real-time i zostawić ją jedynie na ruchu serwisowym tej samej strefy.
Bezpieczny transfer plików i aktualizacji bez USB
Pendrive w szafie to proszenie się o kłopoty. Minimalny, tani wzorzec:
- Strefa plików w DMZ: SFTP/HTTPS z IT do DMZ, następnie skan dwoma silnikami AV i kontrola hash.
- „Pull” z OT-Services: serwer w OT sam pobiera paczki z DMZ o określonych godzinach (okna serwisowe), bez stałych połączeń inicjowanych z IT.
- Repozytorium offline: mirror WSUS/yum/apt w DMZ, a w OT tylko wybrane, podpisane paczki; automaty aktualizacji wyłączone.
- Quarantine i wersjonowanie: każda paczka z tagiem zmiany i właścicielem; rollback trzymany lokalnie w OT-Services.
Kiedy dostawca musi dostarczyć plik „na już”, niech wrzuci go do DMZ, a Ty uwolnisz go dalej po skanie i potwierdzeniu sumy kontrolnej – zajmuje to minuty, a nie otwiera wprost drogi do PLC.
Utrzymanie polityk bez długu konfiguracyjnego
Reguły działają dziś, ale za pół roku toną w wyjątkach. Źródło problemu: brak właściciela i daty ważności reguły. Rozwiązanie to prosty cykl życia zmian.
Cykl życia wyjątku, który się sam „sprząta”
- TTL dla każdej reguły tymczasowej (np. 7–30 dni) z automatycznym wygaszeniem.
- Tagi: strefa, system, cel, numer zgłoszenia, właściciel biznesowy.
- Tryb monitor na start: loguj trafienia wyjątku tydzień, dopiero potem egzekwuj.
- Przegląd kwartalny: raport top 20 wyjątków według liczby trafień i czasu życia; „kill list” na jednej sesji CAB.
Mini-checklista przed każdą zmianą w regułach
- Czy istnieje zrzut ruchu potwierdzający potrzebę (źródło → cel → port)?
- Czy ruch przechodzi przez DMZ, jeśli wychodzi poza OT?
- Czy jest okno serwisowe i plan cofnięcia (rollback)?
- Czy monitoring (syslog/IDS) złapie i opisze skutki reguły?
DMZ „na start” – trzy klocki i minimum integracji
Nie trzeba budować katedralnej DMZ, by odseparować produkcję. Wystarczy prosty zestaw:
- Jump host z MFA i nagrywaniem sesji; dostęp tylko po wcześniej zatwierdzonych grupach.
- Repozytorium plików z podwójnym AV, kontrolą hash i workflow akceptacji.
- Broker danych (OPC UA gateway/MQTT bridge), który buforuje i publikuje do IT; żadnych zapytań z ERP do PLC wprost.
Jeśli budżet jest ciasny, postaw to na dwóch serwerach wirtualnych i jednym firewallu z trzema interfejsami. Z czasem dołożysz HA – bez zmiany wzorca ruchu.
Kiedy fizyczna separacja ma sens, a kiedy jest przesadą
Fizyczny podział kablami lub diodą jednokierunkową bywa najlepszy, ale nie wszędzie.
- Tak: systemy bezpieczeństwa (SIS), linie z wymaganiami certyfikacyjnymi lub z niedojrzałym patchowaniem.
- Nie: standardowe linie, gdzie potrzebny jest stały przepływ danych do MES/BI; tu lepsza jest DMZ z kontrolowanymi kanałami.
Jeśli rozważasz „twarde” rozcięcie, podejdź do tego jak do inwestycji w ryzyko, nie w sprzęt. Fizyczna separacja ma sens, gdy: okna patchowania są rzadkie lub zerowe, dostawca nie chce brać odpowiedzialności za aktualizacje, a pojedyncze naruszenie mogłoby zatrzymać produkcję na długo. Po drugiej stronie szali są koszty: dodatkowe okablowanie, osobne przełączniki, monitoring i utrzymanie dwóch światów. „Air gap” bywa pozorny: jedno LTE do zdalnego wsparcia albo pendrive „na szybko” i cały model bezpieczeństwa się sypie.
