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 och