Zero Trust w środowisku przemysłowym: rola VPN i szyfrowania w ochronie OT

Środowisko OT pod lupą: czym różni się od klasycznego IT

Warstwy i komponenty typowego systemu przemysłowego

Środowisko OT (Operational Technology) składa się z kilku warstw, które rządzą się innymi prawami niż klasyczne IT. W typowym zakładzie przemysłowym spotyka się strukturę przypominającą model Purdue: od urządzeń polowych, przez sterowniki, aż do systemów biznesowych. Zrozumienie tej struktury jest konieczne, zanim zacznie się mówić o Zero Trust, VPN czy szyfrowaniu.

Na samym dole znajdują się urządzenia polowe: czujniki, siłowniki, przetworniki, napędy. Komunikują się one ze sterownikami (PLCs, RTUs) przy użyciu protokołów przemysłowych, często przez magistrale szeregowe lub sieci przemysłowe Ethernet. To tutaj każdy dodatkowy milisekundowy narzut może mieć znaczenie dla stabilności procesu.

Wyżej pracują sterowniki PLC/RTU i panele HMI. Ich głównym zadaniem jest realizacja logiki sterowania, a nie bezpieczeństwo komunikacji. Wiele z nich powstało w czasach, gdy komunikacja była fizycznie odseparowana, a protokoły nie miały wbudowanych mechanizmów uwierzytelniania czy szyfrowania. Te urządzenia często działają bez aktualizacji przez 10–20 lat.

Kolejna warstwa to systemy SCADA/DCS, serwery zbierające dane, wizualizacje, archiwizację historyczną. Powyżej funkcjonują systemy MES i ERP, które integrują dane produkcyjne z biznesem. Pomiędzy światem produkcji a światem biurowym powinna znaleźć się strefa pośrednia (DMZ przemysłowe), która pełni rolę bufora i kontrolera przepływu danych.

Ten wielowarstwowy układ nie jest wyłącznie teorią z dokumentów ISA/IEC 62443. To konkretne decyzje o tym, gdzie umieścić serwery VPN, jak prowadzić tunelowanie, gdzie kończy się ruch szyfrowany, a gdzie zaczynają się stare, niechronione protokoły. Jeżeli te warstwy są pominięte i „wszyscy mają dostęp do wszystkiego”, wdrażanie Zero Trust będzie tylko marketingowym hasłem.

Różne priorytety: dostępność procesu kontra poufność danych

W klasycznym IT przez lata dominuje myślenie: poufność danych jest priorytetem, później integralność, a na końcu dostępność. W OT kolejność bywa odwrotna: ciągłość i bezpieczeństwo procesu są ważniejsze niż poufność. Zatrzymanie pieca hutniczego albo linii chemicznej to nie tylko koszt, ale też realne zagrożenie dla ludzi i środowiska.

To powoduje, że każdy pomysł na zaostrzenie polityk bezpieczeństwa trzeba zestawić z wpływem na dostępność i deterministyczną komunikację. Tunel VPN, który od czasu do czasu „przytnie” pakiety albo wprowadzi nieregularne opóźnienia, jest akceptowalny dla zdalnego serwisu, ale może być nieakceptowalny dla krytycznej pętli regulacji w czasie rzeczywistym.

Zero Trust w OT nie może oznaczać „wszystko szyfrujemy i wszędzie wprowadzamy dynamiczne polityki w czasie rzeczywistym”. Często rozsądniejsze jest ograniczenie zasięgu zmian: przed krytycznym segmentem stawiamy warstwę, która wprowadza szyfrowanie, silne uwierzytelnianie i segmentację, ale sam ruch w pętli sterowania pozostawiamy na sprawdzonej, niezmienianej technologii – za to dobrze odizolowanej.

Konflikt priorytetów widać szczególnie przy planowaniu okien serwisowych. W IT zmiana polityki VPN czy wdrożenie nowej bramy TLS to często kwestia wieczornego okna. W OT w wielu zakładach jedyne większe okno serwisowe istnieje raz lub dwa razy w roku. To mocno ogranicza tempo wdrażania rozwiązań Zero Trust – i lepiej założyć to na początku, niż obiecywać nierealistyczne harmonogramy.

Długie cykle życia i „beton” sprzętowy

Sterowniki PLC, RTU, panele HMI, napędy, starsze switche przemysłowe – to urządzenia z cyklem życia liczonym w dekadach, nie w latach. Wiele z nich nie ma możliwości aktualizacji firmware’u, a jeśli takowa istnieje, to jej przeprowadzenie wiąże się z ryzykiem zatrzymania procesu lub utraty certyfikacji linii technologicznej.

Dla Zero Trust oznacza to, że większość zabezpieczeń trzeba dobudować na zewnątrz:

• stosując bramy / routery przemysłowe z obsługą VPN i szyfrowania,
• tworząc segmenty sieciowe i kontrolując ruch na poziomie IP/port/protokół,
• stosując dodatkowe firewalle przemysłowe z inspekcją protokołów OT, jeśli to możliwe,
• uzupełniając ochronę o systemy detekcji anomalii w ruchu OT.

Nie ma co liczyć, że każdy „stary” PLC dostanie nagle aktualizację z obsługą TLS 1.3. Czasem producent wprost deklaruje: urządzenie jest „end of life”, żadnych aktualizacji nie będzie. W takich sytuacjach jedyną realną drogą jest zamknięcie tego sprzętu w możliwie najmniejszej, kontrolowanej strefie i pilnowanie, aby komunikował się tylko z ściśle określonymi punktami – na przykład z jednym serwerem SCADA, do którego ruch już jest szyfrowany.

Protokoły przemysłowe projektowane bez bezpieczeństwa

Protokoły takie jak Modbus/TCP, Profinet, DNP3, EtherNet/IP w oryginalnej postaci powstały na założeniu zaufanej, odseparowanej sieci. Nie przewidywano scenariusza, w którym ktoś z Internetu spróbuje wysłać do nich złośliwe ramki sterujące. Brak uwierzytelniania, brak szyfrowania, często brak jakichkolwiek mechanizmów kontroli integralności ponad to, co daje sama warstwa TCP.

W praktyce oznacza to, że:

• każdy, kto ma dostęp do sieci, może czytać i w wielu przypadkach modyfikować wartości procesowe,
• protokół często nie odróżnia „uprawnionego” SCADA od nieautoryzowanego klienta,
• ataki typu replay, injection czy spoofing są banalne, jeśli ruch jest niesegmentowany.

Nowsze standardy, jak OPC UA czy rozszerzenia bezpieczeństwa dla DNP3, próbują to nadrobić, dodając szyfrowanie i uwierzytelnianie. Ale ogromna baza zainstalowanych systemów wciąż działa na starych wersjach protokołów. Bez dodatkowego szyfrowania (np. w tunelu VPN) i bez segmentacji, zastosowanie koncepcji Zero Trust będzie czysto teoretyczne. Zaufanie do urządzeń i ruchu sieciowego musi być wymuszane dodatkowymi warstwami ochrony.

Przykład: zdalny serwis „na szybko postawionym” VPN

Typowy scenariusz, który pojawia się w zakładach, wygląda tak: nowa linia technologiczna, dostawca wymaga zdalnego serwisu. Aby przyspieszyć uruchomienie, administrator sieci zestawia prosty tunel VPN z routera dostawcy do sieci produkcyjnej. Dostawca ma od razu dostęp do całej podsieci z PLC, HMI i serwerami SCADA. Po rozruchu tunel zostaje, bo „przyda się do wsparcia”.

Na pierwszy rzut oka wszystko jest „bezpieczne”, bo przecież „jest VPN i wszystko jest szyfrowane”. W praktyce powstaje jednak bezpośredni by-pass wszystkich innych zabezpieczeń:

• dostawca ma zbyt szerokie uprawnienia – często „widzi” całą sieć OT,
• brak jest granularnej kontroli, do których urządzeń może się logować,
• brakuje centralnego logowania i egzekwowania tożsamości konkretnych serwisantów,
• tunel bywa współdzielony przez kilku pracowników dostawcy,
• nie ma jasnej procedury wyłączania dostępu po zakończeniu prac.

Ten przykład dobrze pokazuje, że samo istnienie VPN nie ma nic wspólnego z Zero Trust. Dopiero odpowiednie zaprojektowanie zakresu dostępu, silne uwierzytelnianie, segmentacja oraz rejestrowanie działań zbliża się do sensownej realizacji tego podejścia.

Założenia Zero Trust w realiach przemysłowych – co da się przenieść, a co jest teorią

Kluczowe zasady Zero Trust i ich interpretacja w OT

Zero Trust bazuje na kilku prostych, ale rygorystycznych zasadach: nie ufaj domyślnie, weryfikuj ciągle, dawaj tylko minimalny potrzebny dostęp, traktuj sieć jak wrogą, nawet jeśli jest wewnętrzna. W świecie biurowym przekłada się to na ciągłą weryfikację tożsamości użytkowników, urządzeń, kontekstu oraz dynamiczne polityki dostępu.

W OT część z tych zasad jest jak najbardziej sensowna:

• minimalny dostęp – ograniczenie zdalnego serwisu do pojedynczych PLC zamiast całego segmentu,
• brak domyślnego zaufania – każda nowa komunikacja między strefami wymaga uzasadnienia i reguły firewall,
• ciągła weryfikacja – monitoring ruchu OT, detekcja anomalii, alertowanie przy nowych wzorcach ruchu.

Jednak inne elementy, jak bardzo dynamiczne polityki w czasie rzeczywistym, mogą wprowadzać niestabilność. Jeżeli reguły dostępu do PLC zmieniają się co kilka minut w zależności od scoringu ryzyka, łatwo o nieprzewidziany efekt uboczny – przerwanie połączenia w krytycznym momencie.

W OT rozsądniejszym celem jest „Zero Trust w granicach przewidywalności procesu”: polityki są restrykcyjne, ale przewidywalne i rzadko zmieniane. Ciągła weryfikacja odbywa się głównie poprzez monitorowanie i alertowanie, a nie nagłe, automatyczne zrywanie komunikacji. Wyjątki można zarezerwować dla ewidentnie szkodliwych działań, np. próby zapisu konfiguracji z nietypowego adresu.

Co zwykle działa w OT: fundamenty, nie fajerwerki

W praktyce przemysłowej realnie da się zastosować kilka filarów Zero Trust:

• segmentacja sieci przemysłowych zgodna z ISA/IEC 62443 – wydzielenie stref (linie, komórki produkcyjne, strefy bezpieczeństwa funkcjonalnego) i ściśle kontrolowane interfejsy między nimi,
• kontrola zdalnych połączeń – centralne punkty zdalnego dostępu (bastion, brama VPN), zamiast dziesiątek bezpośrednich tuneli do różnych podsieci,
• uwierzytelnianie i autoryzacja – przypisywanie uprawnień do ról (inżynier, serwisant zewnętrzny, operator) i egzekwowanie ich zarówno na poziomie VPN, jak i systemów SCADA,
• monitoring i rejestrowanie – zbieranie logów z bram VPN, firewalli, serwerów SCADA oraz ich korelacja; analiza zmian w konfiguracji PLC, jeśli to możliwe.

Rozwiązania, które często dobrze wyglądają w prezentacjach, ale gorzej w realnym zakładzie, to np. hiperdynamiczne polityki oparte o scoring ryzyka użytkownika albo pełna inspekcja ruchu szyfrowanego z rozpakowywaniem TLS na każdym kroku. W OT dodatkowe opóźnienia, jitter i złożoność mogą być bardziej niebezpieczne niż potencjalne zagrożenie, które mają zwalczać.

Dlatego lepiej skupić się na mniejszej liczbie, ale za to konsekwentnie wdrożonych zasad, niż na rozpraszaniu się zaawansowanymi funkcjami, których zakład nie będzie w stanie utrzymać.

Zero Trust jako architektura, a nie produkt

Znacząca część rynku traktuje Zero Trust jako naklejkę marketingową na nową wersję firewalla, brokera dostępu lub systemu IAM. W OT takie podejście bywa szczególnie groźne, bo może zbudować złudne poczucie bezpieczeństwa: „kupiliśmy rozwiązanie Zero Trust, więc temat mamy załatwiony”.

Realne Zero Trust w OT jest projektem architektury bezpieczeństwa, a nie jedną technologią. Obejmuje:

• analizę przepływów procesu (kto/co z kim musi rozmawiać, jakie są czasy odpowiedzi),
• wydzielenie stref i kondujtów (zgodnie z ISA/IEC 62443),
• dobór miejsc kończenia tuneli VPN,
• definicję, które połączenia muszą być szyfrowane, a które są zabezpieczane innymi środkami (segregacja fizyczna, oddzielna infrastruktura),
• standardy uwierzytelniania użytkowników i urządzeń,
• procedury utrzymania i reagowania na incydenty.

Produkty (VPN, firewalle, systemy IAM, platformy OT security) są tylko narzędziami. Bez projektu architektury ryzyko jest takie, że VPN zostanie dołożony „gdzie się zmieści”, szyfrowanie będzie włączone „tam, gdzie akurat jest łatwo”, a polityki dostępu będą mieszaniną wyjątku do wyjątku. Z takiego układu nie powstanie żaden sensowny Zero Trust.

Powiązanie z ISA/IEC 62443 i NIST

Podejście Zero Trust nie zastępuje standardów branżowych, tylko je uzupełnia. ISA/IEC 62443 opisuje koncepcję stref (zones) i kondujtów (conduits) – logicznych i fizycznych granic bezpieczeństwa. NIST SP 800-82 skupia się na bezpieczeństwie ICS/SCADA. Zero Trust nadaje im bardziej rygorystyczny charakter: każda strefa jest traktowana jak potencjalnie wroga wobec innej, a każdy kondukt wymaga ściśle zdefiniowanych zasad dostępu i monitorowania.

Łączenie tych podejść w praktyce wygląda np. tak:

• strefy produkcyjne (np. linia pakowania) dostają własne segmenty sieci (VLAN, VRF),
• pomiędzy strefą produkcyjną a strefą SCADA stoi firewall z jasno zdefiniowanymi regułami,

Przeniesienie zasad Zero Trust na łańcuch dostaw i integratorów

Środowisko OT rzadko jest w pełni pod kontrolą jednego właściciela. W praktyce uczestniczy w nim wielu integratorów, dostawców OEM, firmy serwisowe i producentzy komponentów. Każdy z nich chce mieć „szybki, stały dostęp” do swoich urządzeń, a to stoi w jawnej sprzeczności z filozofią Zero Trust.

O ile wewnętrznych użytkowników można objąć wspólnymi zasadami IAM i politykami bezpieczeństwa, o tyle w relacjach zewnętrznych dominuje podejście „bierzemy to, co daje producent” – czyli dedykowane routery serwisowe, chmurowe portale dostępu z własnym agentem, własne VPN-y. Skutek jest taki, że w jednej fabryce może pracować kilka równoległych, niespójnych mechanizmów zdalnego dostępu, których nikt centralnie nie ogarnia.

Próba wpisania tego w Zero Trust oznacza zwykle konieczność zmiany relacji z dostawcami. Zamiast akceptować dowolny „czarny pudełek” do zdalnego serwisu, zakład definiuje własny standard zdalnego dostępu:

• zdalne połączenia muszą przechodzić przez centralną bramę VPN/OT,
• uwierzytelnianie jest po stronie zakładu (np. federacja IdP, osobne konta gościnne),
• ruch jest ograniczany regułami firewall na poziomie konkretnych adresów/portów,
• dostęp jest domyślnie wyłączony i uruchamiany na czas konkretnego zlecenia serwisowego.

Producenci często opierają swoje rozwiązania serwisowe na własnych chmurach. Z perspektywy Zero Trust nie jest to automatycznie problem, ale wymaga kilku warunków: jasnej widoczności tego ruchu (logi, adresy docelowe, protokoły), możliwości wymuszenia dwuskładnikowego uwierzytelniania oraz powiązania sesji z konkretną osobą, a nie ogólnym kontem „service”. Tam, gdzie to niemożliwe, lepszym rozwiązaniem bywa separacja fizyczna (osobny modem LTE dla danego OEM, odcięty od głównej sieci) niż nieudawany Zero Trust na papierze.

Tożsamość w OT: użytkownicy vs urządzenia

W Zero Trust dużo mówi się o tożsamości użytkownika. W OT równie istotna, a często trudniejsza, jest tożsamość urządzenia. Klasyczne podejście „adres IP = zaufane urządzenie” nie wystarcza, bo IP można spoofować, a port switcha przełączyć na inne gniazdo.

Próby wdrożenia typowych mechanizmów korporacyjnych (np. 802.1X z certyfikatami na każdym końcówce) napotykają od razu bariery: wiele sterowników PLC nie wspiera 802.1X, nie mówiąc o klientach EAP czy bezpiecznym przechowywaniu kluczy. Zamiast tego częściej stosuje się hybrydę:

• kontrola portów na przełącznikach – porty do PLC są przypisane na stałe, każde przepięcie kabla wymaga zmiany konfiguracji lub zgłoszenia,
• monitorowanie zachowania – systemy IDS/monitoringu OT wychwytują anomalie w komunikacji z danego adresu (inny typ ruchu, nowe protokoły, zmiana częstości zapytań),
• silniejsze uwierzytelnianie na bramach – tam, gdzie kończą się VPN-y i gdzie ruch OT „wchodzi” z systemów inżynierskich do sieci sterowania, wymuszane jest certyfikatowe uwierzytelnianie klienta lub przynajmniej mocna kontrola dostępu do samego hosta inżynierskiego.

Docelowy model, w którym każde urządzenie OT ma swój certyfikat i jest objęte centralnym PKI, jest nadal wyjątkiem, spotykanym głównie w nowych instalacjach i w branżach o najwyższych wymaganiach (energetyka, chemia krytyczna). W większości zakładów bardziej realistyczne jest stopniowe uszczelnianie: najpierw dostęp użytkowników, potem segmentacja ruchu, a dopiero na końcu indywidualna tożsamość urządzeń.

Rola VPN w Zero Trust dla OT – narzędzie, nie magiczna tarcza

Jakiego typu VPN ma sens w OT

Pod wspólną nazwą „VPN” kryje się kilka zupełnie różnych technologii, o różnej przydatności w środowiskach przemysłowych:

• VPN site-to-site (IPsec, czasem GRE+IPsec) – zestawia stały tunel między dwoma lokalizacjami lub sieciami; najczęściej stosowany do łączenia zakładów, serwerowni, czasem chmur,
• VPN remote access (SSL VPN/IPsec dla użytkowników) – klient na laptopie serwisanta lub inżyniera, który po uwierzytelnieniu dostaje dostęp do wybranych zasobów,
• „VPN OEM” w urządzeniach serwisowych – często tunel zestawiany inicjatywnie z zakładu do chmury dostawcy, a dopiero stamtąd ruch każe spływa do serwisanta.

W kontekście Zero Trust kluczowe jest, aby tunel VPN nie oznaczał „wszystko do wszystkiego”. VPN ma zapewniać poufność i integralność ruchu, ale o tym, kto z kim może rozmawiać, powinny decydować polityki na końcach tuneli – firewalle, systemy kontroli dostępu, segmentacja logiczna.

Najczęstsze błędy przy projektowaniu VPN w OT

W praktyce da się wyróżnić kilka wzorców, które regularnie podważają sens Zero Trust:

• stawianie serwera VPN bezpośrednio w sieci PLC – skutecznie omija wszystkie inne strefy i ochronę; tunel kończy się tuż przy sterownikach, a dalej jest już pełna dowolność,
• brak różnicowania profili dostępu – każdy użytkownik VPN widzi to samo; nie ma rozróżnienia między serwisantem od linii pakowania a integratorem od systemu energetycznego,
• tunel „full tunnel” z domu do zakładu – po połączeniu cały ruch z laptopa serwisanta idzie przez sieć OT, razem z aktualizacjami systemu, Netflixem w tle i innymi niespodziankami,
• brak wiązania logów VPN z tożsamością – wspólne konta, brak MFA, brak rejestrowania, kto i kiedy łączył się do którego segmentu.

Jeżeli VPN jest wymagany głównie do zdalnego serwisu i dostępu inżynierskiego, lepszym wzorcem jest koncentrator VPN w strefie DMZ dla OT, połączony z wydzielonym bastionem (jump hostem). Użytkownik po zalogowaniu do VPN nie ma bezpośredniego ruchu do PLC, tylko najpierw do bastionu, na którym dopiero uruchamia narzędzia inżynierskie. To ogranicza powierzchnię ataku i pozwala lepiej rejestrować działania.

Integracja VPN z segmentacją i firewallami

Sam tunel IPsec czy SSL niewiele zmienia, jeśli na jego końcu stoi router z konfiguracją „any-any”. W modelu Zero Trust miejsca zakończenia tuneli są krytycznymi punktami kontroli. To na nich należy:

• mapować użytkownika/rolę VPN na odpowiednią strefę bezpieczeństwa,
• stosować reguły „allowlist” – zezwalać tylko na konkretne IP/porty/protokoły,
• odseparować ruch administracyjny (np. RDP/SSH do serwerów SCADA) od ruchu procesowego (Modbus, Profinet) i traktować je różnymi zasadami.

Efektywnie sprowadza się to do założenia, że tunel VPN kończy się zawsze w strefie o wyższym poziomie zaufania niż źródłowa, ale niższym niż docelowa. Przykład: serwisant łączy się z laptopa (niska kontrola) przez VPN do DMZ (średnia kontrola), a dopiero z DMZ ściśle filtrowany ruch przechodzi do strefy sterowania (wysoka kontrola). W ten sposób pojedynczy błąd konfiguracyjny po stronie klienta VPN nie musi od razu oznaczać kompromitacji PLC.

VPN a wymogi ciągłości działania

W procesach ciągłych lub w liniach, gdzie liczy się każda sekunda, aspekt dostępności bywa ważniejszy niż kryptograficzna perfekcja. Zbyt agresywne ustawienia renegocjacji kluczy, krótkie czasy sesji, skomplikowane scenariusze HA koncentratorów VPN – wszystko to może wprowadzać krótkie, ale zauważalne przerwy.

Jeżeli przez VPN idzie wyłącznie zarządzanie (np. połączenia inżynierskie, serwis), a ruch procesowy jest lokalny, skutki są zwykle akceptowalne: serwisant musi się po prostu ponownie zalogować. Gorzej, gdy tunelem przesyłany jest czasowo krytyczny ruch sterujący pomiędzy rozproszonymi lokalizacjami. Wtedy nadmierny rygoryzm kryptograficzny może w praktyce zaszkodzić bezpieczeństwu funkcjonalnemu (SIL), prowadząc do fałszywych zadziałań lub opóźnień.

Dobry kompromis to rozdzielenie ról VPN:

• stabilne, dobrze przetestowane tunele IPsec dla ruchu między lokalizacjami, z parametrami dobranymi do wymagań procesu (dłuższe czasy renegocjacji, konfiguracja pod kątem minimalnego jittera),
• bardziej restrykcyjne, krótkotrwałe VPN-y użytkowników do zarządzania, gdzie priorytetem jest kontrola dostępu, a nie milisekundy opóźnień.

Szyfrowanie w sieciach przemysłowych: wymagania, ograniczenia, kompromisy

Dlaczego samo „dołóż TLS” zwykle nie działa

W IT odpowiedź na problem podsłuchu jest prosta: włączyć TLS wszędzie, gdzie się da. W OT takie podejście zderza się z kilkoma twardymi barierami:

• sprzętową – starsze PLC mają ograniczoną moc obliczeniową; dodanie szyfrowania może znacząco wydłużyć czas odpowiedzi,
• protokolarną – wiele protokołów przemysłowych nie przewiduje natywnie szyfrowania; próba „doklejenia” TLS w dziwnych miejscach kończy się zrywaniem kompatybilności,
• organizacyjną – obsługa certyfikatów, rotacja kluczy, monitorowanie wygasania to nie jest coś, czym standardowo zajmują się automatycy.

Dlatego w praktyce szyfrowanie w OT częściej realizuje się na poziomie kanału komunikacyjnego (VPN, tunel IPsec, linki MACsec) niż wprost na każdym protokole aplikacyjnym. To podejście nie jest idealne z perspektywy Zero Trust, ale bywa jedynym realnym rozwiązaniem dla istniejących instalacji.

Gdzie szyfrować: na brzegu, w rdzeniu, czy „wszędzie”?

Decyzja, w którym miejscu w architekturze włączyć szyfrowanie, jest jednym z kluczowych kompromisów. Typowe opcje to:

• szyfrowanie tylko na styku zewnętrznym – VPN między zakładem a chmurą, centralą, dostawcami; sieć wewnętrzna OT pozostaje nieszyfrowana, ale mocno segmentowana i monitorowana,
• szyfrowanie między strefami wewnątrz zakładu – IPsec/MACsec między kluczowymi przełącznikami lub firewallami, ruch w obrębie strefy pozostaje nieszyfrowany,
• end-to-end – np. OPC UA z TLS od klienta SCADA do serwera, nawet jeśli cała trasa biegnie po tej samej fizycznej sieci.

Model end-to-end jest najbliższy „czystemu” Zero Trust, ale w obecnym krajobrazie OT często możliwy tylko dla nowych systemów, gdzie od początku wybierano komponenty z obsługą nowoczesnych protokołów. W modernizowanych zakładach zwykle kończy się na kombinacji: szyfrowane konduity między zaufanymi punktami plus selektywne szyfrowanie aplikacyjne tam, gdzie pozwalają na to urządzenia.

Wpływ szyfrowania na diagnostykę i monitoring

Szyfrowanie komplikuje analizę problemów – to oczywiste, ale w OT bywa lekceważone do momentu pierwszej większej awarii. Gdy ruch jest zaszyfrowany od końca do końca, narzędzia typu sniffer w środku trasy widzą tylko pakiety, nie ich treść. Diagnostyka „dlaczego PLC nie odpowiada na komendę” staje się znacznie trudniejsza.

Dlatego przy projektowaniu szyfrowania w OT trzeba z góry przewidzieć punkty widoczności:

• na granicach stref, gdzie i tak stoi firewall/IDS, można terminować szyfrowanie (np. TLS offload) i tam prowadzić inspekcję,
• w przypadku VPN-ów pełne logowanie metadanych (adresów, portów, objętości ruchu, czasu trwania sesji) bywa cenniejsze niż próba „rozpakowania” treści,
• trzeba określić procedury „trybu serwisowego”, w którym tymczasowo dopuszcza się wyłączenie szyfrowania lub dodatkowe tapy testowe przy zachowaniu rozsądnego poziomu ochrony.

Brak takiego planu często prowadzi do reakcji obronnej: przy pierwszym poważnym incydencie „dla ułatwienia diagnostyki” szyfrowanie jest wyłączane i nigdy nie wraca.

Klucze, certyfikaty i PKI w środowisku OT

Nawet najlepszy algorytm szyfrowania nie pomoże, jeśli klucze i certyfikaty są zarządzane byle jak. W OT typowe problemy to:

• certyfikaty wygasające po kilku latach, o których nikt nie pamięta,
• klucze prywatne trzymane w otwartych udziałach sieciowych lub kopiowane między urządzeniami „żeby działało”,
• brak centralnego rejestru tego, jakie certyfikaty są gdzie używane.

Budowa praktycznej infrastruktury klucza zaufania

W OT mały, pragmatyczny PKI często działa lepiej niż „idealna” korporacyjna hierarchia certyfikatów, której nikt na hali nie rozumie. Zwykle sprawdza się model trójwarstwowy:

• root CA offline – generowana na osobnym, odizolowanym systemie; wyciągana z szafy tylko przy wydawaniu/odnawianiu CA pośrednich,
• pośrednia CA dla OT – z czytelnie zdefiniowanym zakresem: wyłącznie certyfikaty dla urządzeń i usług w strefach OT,
• lokalne punkty rejestracji (RA) – osoby/role w dziale automatyki, które mogą zgłaszać i zatwierdzać wydawanie certyfikatów według jasnych kryteriów.

Bez takiego podziału wszystko ląduje pod jedną, ogólną CA IT, co praktycznie uniemożliwia utrzymanie porządku i rozwiązywanie incydentów. Granica między IT a OT w PKI musi odpowiadać granicom stref i odpowiedzialności – inaczej każdy błąd w jednym świecie natychmiast wpływa na drugi.

Drugim elementem jest katalog minimalnych profili certyfikatów. Zamiast tworzyć nowy szablon przy każdym projekcie, lepiej zdefiniować kilka typów: np. „VPN-gateway-OT”, „OPC-UA-server”, „device-management”. Dzięki temu automatycy i integratorzy mają jasną instrukcję, a audytorzy – spójne kryteria oceny.

Rotacja i wygasanie kluczy bez zatrzymywania produkcji

W klasycznym IT częstą radą jest „skrócić ważność certyfikatów”. W OT taka rekomendacja brzmi dobrze na slajdzie, ale w zderzeniu z serwerem SCADA aktualizowanym raz na kilka lat szybko wychodzi, że agresywne okresy ważności są po prostu nierealne.

Przy planowaniu rotacji kluczy w OT lepiej zastosować kilka prostych zasad niż próbować kopiować politykę z data center:

• rozróżnienie klas urządzeń – inne okresy ważności dla bram VPN czy serwerów aplikacyjnych (krótsze), inne dla długo działających HMI/PLC, gdzie każda aktualizacja jest operacją wysokiego ryzyka,
• okresy nakładania się certyfikatów – tak konfigurować urządzenia, aby przez pewien czas akceptowały zarówno stary, jak i nowy certyfikat; umożliwia to rotację „w locie” bez planowanych postojów,
• synchronizacja z oknami serwisowymi – odświeżanie kluczy nie może żyć własnym życiem; powinno być wpisane w cykle przeglądów, remontów, zmian wersji oprogramowania.

W praktyce częściej dochodzi do sytuacji odwrotnej: certyfikat wygasa w środku tygodnia, bo pierwotnie planowano krótki okres ważności „dla bezpieczeństwa”. Efektem jest awaryjne, pełne ryzyka omijanie zabezpieczeń, żeby „uruchomić linię”. Zdrowszym podejściem jest dłuższa ważność plus twardy proces wczesnego ostrzegania i planowanej wymiany niż krótkie terminy i wieczny tryb gaszenia pożarów.

Ochrona kluczy i minimalizacja skutków wycieku

Złamany algorytm szyfrowania to rzadkość. Znacznie częściej problemem jest skopiowany gdzieś po cichu plik z kluczem prywatnym. W OT źródła takich incydentów bywają trywialne: pendrive użyty do wymiany konfiguracji, obraz dysku bastionu z kopiowanym katalogiem certyfikatów, wspólne konta serwisowe.

Kilka praktycznych reguł, które ograniczają skutki wycieku:

• rozróżnienie kluczy dla administracji i dla procesu – inne klucze/certyfikaty do zarządzania urządzeniem, inne do komunikacji procesowej; wyciek jednego zestawu nie powinien od razu umożliwiać ingerencji w logikę produkcji,
• hardware’owe magazyny kluczy tam, gdzie ma to sens – HSM-y na koncentratorach VPN, moduły TPM lub dedykowane chipy w nowych sterownikach, jeśli dostawca to wspiera,
• procedura „odcięcia” – z góry zdefiniowany sposób unieważniania kompromitowanych certyfikatów (CRL/OCSP), zsynchronizowany z możliwością szybkiej dystrybucji nowych certyfikatów do kluczowych węzłów.

Bez działającego procesu odwoływania certyfikatów PKI staje się systemem „jednorazowym”: wszystko działa do pierwszego poważniejszego incydentu, po którym nikt nie ma odwagi niczego odciąć, bo nie wiadomo, co przestanie działać.

Architektura Zero Trust dla OT z użyciem VPN i segmentacji

Warstwowe podejście do „braku zaufania”

Zero Trust w OT nie oznacza wzięcia diagramu z działu IT i przyklejenia go do hali produkcyjnej. Bardziej realistyczny jest model warstwowy, w którym różne zasady obowiązują na poszczególnych poziomach architektury:

• wierzchnie warstwy (IT, chmura, zdalny serwis) – pełne podejście Zero Trust: silna tożsamość użytkownika, uwierzytelnianie wieloskładnikowe, ciągła ocena ryzyka sesji, granularne reguły dostępu,
• strefy pośrednie (DMZ, serwery SCADA, systemy raportujące) – restrykcyjne listy dozwolonego ruchu, segmentacja mikro-strefami logicznymi (VLAN, VRF, konteksty firewalli), kontrola aplikacyjna,
• rdzeń OT (PLC, napędy, czujniki) – często brak pełnej obsługi Zero Trust na poziomie urządzeń; rolę kontrolną przejmują bramy, proxy protokołów, firewalle L3/L4 lub specjalizowane IPS/IDS przemysłowe.

W efekcie „brak zaufania” realizuje się nie tyle na pojedynczych czujnikach, ile na punktach wymiany ruchu między warstwami. To one stają się miejscem, gdzie łączy się segmentacja, VPN i polityki bezpieczeństwa.

Strefy i konduity w praktyce Zero Trust

Koncept stref i konduity znany z norm takich jak ISA/IEC 62443 dobrze składa się z założeniami Zero Trust, ale tylko pod warunkiem, że konduity nie są „czarnymi rurami”. Za każdą logiczną rurą musi stać konkretna polityka:

• z kim (tożsamość użytkownika, grupa, urządzenie, lokalizacja),
• dokąd (strefa, adresy, funkcje protokołu – np. tylko odczyt rejestrów, bez zapisu),
• w jakim celu (serwis, zmiana konfiguracji, odczyt danych procesowych).

Przykładowo: konduity między DMZ a strefą sterowania mogą być fizycznie jednym łączem światłowodowym, ale logicznie to trzy odseparowane tunele: dla ruchu SCADA, dla zdalnej diagnostyki producenta i dla replikacji logów. Każdy tunel ma inny profil VPN, inne reguły firewall i inny sposób monitorowania.

Rola VPN jako „konduitu z polityką”

VPN w architekturze Zero Trust dla OT nie jest tylko „bezpiecznym kablem”. Jest elementem, który przenosi kontekst tożsamości z warstw zewnętrznych do stref pośrednich. Dobrze zaprojektowany tunel niesie informacje, które można dalej wykorzystać w politykach:

• kto się łączy (użytkownik, urządzenie, kombinacja jednego i drugiego),
• z jakiej klasy środowiska (zaufany laptop serwisowy, domowy komputer, maszynowy gateway w innej lokalizacji),
• w jakim trybie (tymczasowy dostęp serwisowy, stałe połączenie pomiędzy zakładami, sesja awaryjna).

Ten kontekst można mapować na role w firewallach lub na wirtualne segmenty. Dzięki temu nie powstaje jedna wspólna „chmura VPN”, tylko zestaw kontrolowanych, rozdzielonych przestrzeni, do których przypisana jest logiczna polityka. Dla serwisanta z zewnątrz DMZ staje się jedynym widocznym światem; dostęp głębiej wymaga dodatkowych kroków, np. logowania na bastion i uzyskania zgody dyspozytora.

Mikrosegmentacja w sieciach przemysłowych – teoria kontra praktyka

Hasło „mikrosegmentacja” bywa nadużywane. W data center da się rozdzielać ruch między wirtualnymi maszynami w ramach jednego serwera. W klasycznym OT stopień granularności determinują zwykle możliwości przełączników, routerów i firewalli oraz tolerancja organizacji na złożoność.

Typowy, wykonalny w większości zakładów poziom to:

• segmentacja według linii/obszarów produkcji – osobne VLAN-y i strefy dla każdej linii lub klas urządzeń (np. energetyka, HVAC, bezpieczeństwo funkcjonalne),
• wydzielone strefy dla krytycznych systemów – osobne segmenty dla systemów bezpieczeństwa (SIS), systemów jakości, magazynów receptur,
• logiczne mikrosegmenty za pośrednictwem firewalli – np. grupowanie PLC różnych linii w osobne „grupy bezpieczeństwa”, nawet jeśli fizycznie wiszą na tym samym przełączniku.

Próba odwzorowania „hiper-szczegółowej” mikrosegmentacji z IT w istniejącej sieci przemysłowej często skutkuje lawiną wyjątków, statycznych tras i reguł, których nikt nie nadąża dokumentować. Z punktu widzenia Zero Trust lepsze są mniej liczne, ale jasno zdefiniowane strefy niż gąszcz mikrosegmentów utrzymywanych ręcznie.

Proxy protokołów i bramy aplikacyjne jako „tłumacze zaufania”

Starsze protokoły przemysłowe nie znają pojęcia użytkownika ani tożsamości urządzenia w sensie kryptograficznym. W takim środowisku funkcję „tłumacza” między światem Zero Trust a światem Modbusa czy Profinetu mogą pełnić:

• proxy protokołów – pośrednicy, którzy przyjmują ruch z warstwy zewnętrznej (np. OPC UA z TLS) i przekładają go na prosty protokół do PLC wewnątrz strefy,
• data diody i bramy jednokierunkowe – tam, gdzie dopuszczalny jest wyłącznie przepływ danych w jedną stronę (np. z produkcji do raportowania),
• aplikacyjne firewalle przemysłowe – sprzęty rozumiejące specyfikę protokołu i pozwalające np. na blokowanie komend zapisu przy jednoczesnym dopuszczeniu odczytu.

Zero Trust w takim układzie realizuje się nie na PLC, ale na bramie. To na niej sprawdzana jest tożsamość, a do wewnętrznej sieci trafia już wyłącznie ruch „spłaszczony” do minimalnego, akceptowalnego zbioru funkcji. Jeżeli jedna brama obsługuje wiele stref, izolacja logiczna w jej konfiguracji staje się krytyczna. Pojedyncza konfiguracja „allow-any” potrafi unieważnić cały wysiłek segmentacji.

Integracja z systemami monitoringu i detekcji anomalii

Architektura Zero Trust z VPN i segmentacją bez porządnego monitoringu jest ślepa. Z drugiej strony, w pełni zaszyfrowane konduity potrafią skutecznie „oślepić” klasyczne IDS-y sieciowe. Trzeba zatem pogodzić ochronę treści z możliwością rozpoznawania nadużyć.

Do rozsądnych kompromisów należą m.in.:

• zbieranie telemetryki z końców tuneli – logi z koncentratorów VPN, firewalli i bram aplikacyjnych (sesje, objętość ruchu, odchylenia od typowych wzorców),
• monitoring na poziomie aplikacji – logi z SCADA, systemów MES, serwerów OPC; w nich często widać anomalie (nietypowe komendy, masowe zmiany parametrów), których nie da się łatwo wychwycić na samej warstwie sieciowej,
• punktowe „okna inspekcji” – miejsca w architekturze, gdzie ruch jest odszyfrowywany i może być analizowany przez systemy IDS/IPS, z jednoczesnym ograniczeniem liczby tych punktów dla zmniejszenia powierzchni ataku.

Samo „wrzucenie” SIEM-a czy narzędzia typu UEBA niczego nie załatwia, jeśli nie zepnie się go z informacjami z warstwy VPN/segmentacji. Dopiero korelacja: „kto, skąd, jakim tunelem, do której strefy i co potem zrobił” pozwala mówić o sensownej detekcji nadużyć w modelu Zero Trust.

Modelowanie ryzyka przy projektowaniu architektury Zero Trust OT

Zero Trust bywa przedstawiane jako uniwersalny sposób na wszystkie problemy. W środowisku przemysłowym kluczowe jest jednak wkomponowanie go w istniejący model ryzyka. Inaczej zamiast poprawy bezpieczeństwa powstaje skomplikowana, mało zrozumiała konstrukcja, którą w praktyce wszyscy starają się omijać.

Rozsądny proces projektowy zwykle obejmuje kilka kroków:

1. Identyfikacja krytycznych ścieżek procesu – które połączenia sieciowe są absolutnie niezbędne do utrzymania bezpieczeństwa funkcjonalnego i ciągłości produkcji.
2. Wyznaczenie „twardych” granic stref – miejsca, gdzie ingerencja w ruch (segmentacja, szyfrowanie, inspekcja) jest akceptowalna z punktu widzenia opóźnień i niezawodności.
3. Określenie wektorów ataku – zdalny serwis, integracje z IT/chmurą, połączenia między zakładami, dostęp wykonawców utrzymania ruchu.
4. Dobranie technik kontroli – gdzie użyć VPN, gdzie wystarczy filtracja na firewallu, a gdzie potrzebna jest brama aplikacyjna lub fizyczne rozdzielenie.
5. Włączenie wymagań utrzymaniowych – jakie zasoby i kompetencje są dostępne lokalnie, a jakie tylko centralnie; co da się realnie utrzymać w długim horyzoncie.

Najczęściej zadawane pytania (FAQ)

Na czym polega różnica między IT a OT w kontekście Zero Trust i VPN?

W IT głównym celem jest ochrona danych – poufność i integralność są zwykle ważniejsze niż krótkie przerwy w działaniu systemów. W OT priorytet jest odwrotny: ciągłość i bezpieczeństwo procesu technologicznego mają pierwszeństwo przed poufnością transmisji. Zatrzymanie linii czy pieca jest znacznie poważniejszym problemem niż wyciek pojedynczego raportu.

Zero Trust i VPN w OT trzeba więc wdrażać ostrożniej. Każda zmiana, która może wprowadzić opóźnienia, jitter lub ryzyko restartu urządzeń, powinna być testowana i planowana w wąskim oknie serwisowym. To, co w IT da się „przeklikać wieczorem”, w środowisku produkcyjnym bywa realnie możliwe raz–dwa razy w roku.

Czy VPN w sieci OT jest konieczny, skoro zakład ma separację fizyczną?

Fizyczna separacja pomaga, ale rzadko jest pełna. W praktyce większość zakładów ma jakieś połączenia z siecią biurową, dostęp zdalny dla serwisu, integrację z MES/ERP, a czasem także dostęp z chmury. Każde takie „okienko” jest potencjalną drogą ataku, zwłaszcza przy protokołach OT pozbawionych szyfrowania i uwierzytelniania.

VPN nie zawsze musi sięgać aż do każdego PLC. Często rozsądniej jest kończyć szyfrowanie na serwerze w DMZ przemysłowej lub na dedykowanej bramie, a sieć głębiej w OT dodatkowo segmentować i pilnować na poziomie adresów, portów i protokołów. Kluczowe jest świadome dobranie punktu zakończenia tunelu, a nie samo „włączenie VPN”.

Gdzie umieścić serwer VPN w architekturze przemysłowej (model Purdue)?

Najczęściej serwery VPN umieszcza się w strefie pośredniej – DMZ przemysłowej – pomiędzy siecią biurową / Internetem a właściwą siecią OT. Tunel kończy się w DMZ, a ruch z VPN jest dalej przepuszczany wyłącznie do ściśle zdefiniowanych segmentów (np. tylko do serwera SCADA, a nie do całej podsieci PLC).

Bezpośrednie terminowanie VPN w głębokiej warstwie OT (blisko PLC i HMI) bywa uzasadnione tylko w specyficznych przypadkach, np. przy izolowanym, małym obiekcie z jedną linią i dobrze opisanymi ścieżkami dostępu. Regułą powinno być jednak takie projektowanie, aby z tunelu nie dało się „zobaczyć” całego środowiska OT, nawet jeśli użytkownik posiada poprawne dane logowania.

Czy wszystkie protokoły przemysłowe trzeba szyfrować (np. Modbus, Profinet, DNP3)?

W idealnym świecie – tak, ale realia są inne. Ogromna część zainstalowanych urządzeń nie obsługuje żadnego natywnego szyfrowania ani uwierzytelniania. Próba „uszczęśliwienia” ich na siłę może skończyć się niestabilnością procesu albo wymaganiem kosztownej modernizacji całej linii.

Praktyczny kompromis wygląda zwykle tak: krytyczne segmenty sterowania pozostają przy sprawdzonym, nieszyfrowanym protokole, ale są mocno odizolowane i komunikują się wyłącznie z zaufanymi punktami. Szyfrowanie wprowadza się na granicach stref – np. między SCADA a zdalnym serwisem, między zakładem a centralą lub chmurą – używając VPN lub protokołów typu OPC UA z wbudowanym bezpieczeństwem.

Jak zabezpieczyć „stare” PLC i HMI, które nie obsługują TLS ani aktualizacji?

W większości przypadków nie da się „dograć” im nowoczesnego bezpieczeństwa. Dlatego podchodzi się do nich jak do sprzętu o niezmiennych możliwościach i buduje ochronę dookoła. Typowy zestaw to: przemysłowe routery/bramy z VPN, segmentacja VLAN, listy kontroli dostępu oraz firewalle OT z inspekcją protokołów tam, gdzie to możliwe.

Dobrym wzorcem jest „zamykanie” takich urządzeń w minimalnej, kontrolowanej strefie: PLC rozmawia tylko z jednym serwerem SCADA, a ten serwer to jedyny punkt, który ma prawo wyjść dalej (już po szyfrowanym kanale). Każde dodatkowe „tymczasowe” połączenie – np. laptop serwisowy wpięty w losowy switch na hali – znacząco podnosi ryzyko, nawet gdy reszta sieci wygląda poprawnie.

Dlaczego klasyczny VPN do zdalnego serwisu często nie spełnia założeń Zero Trust?

Najczęstszy błąd polega na traktowaniu VPN jako magicznej tarczy: „jest tunel, więc jest bezpiecznie”. W praktyce wiele takich wdrożeń daje dostawcy pełny wgląd w całą podsieć OT, bez granularnej kontroli, kto i do czego może się logować. Dostęp bywa współdzielony, słabo logowany, a uprawnienia utrzymują się latami po zakończeniu projektu.

Podejście bliższe Zero Trust wymaga kilku dodatkowych elementów: silnego uwierzytelniania indywidualnych osób (nie jednego „konta serwisu”), ograniczenia zakresu sieci i urządzeń widocznych przez tunel, kontroli czasu dostępu (np. tylko na czas konkretnej interwencji) oraz centralnego rejestrowania działań. Bez tego VPN staje się po prostu szeroką bramą do całego OT, tyle że zaszyfrowaną.

Czy wdrożenie Zero Trust w OT da się zrobić szybko?

W większości zakładów – nie. Długie cykle życia sprzętu, ograniczone okna serwisowe i wymagania certyfikacyjne powodują, że każda większa zmiana musi być rozłożona na etapy. Zwykle zaczyna się od inwentaryzacji, segmentacji i uporządkowania istniejących dostępów zdalnych, a dopiero potem dokłada się kolejne warstwy: nowe bramy, VPN, uwierzytelnianie, monitoring anomalii.

Obietnice typu „pełne Zero Trust w pół roku” w złożonym zakładzie przemysłowym są mało realistyczne. Rozsądniej jest przyjąć, że pewne obszary (szczególnie najstarsze linie) zostaną na dłużej w trybie „kontrolowanej legacy” – dobrze odizolowane, z minimalną liczbą dróg dostępu – zamiast na siłę wpychać je w najnowsze wzorce bezpieczeństwa kosztem ryzyka przestoju.