Szyfrowanie i VPN w utrzymaniu ruchu: procedury dla audytu bezpieczeństwa technicznego

Przez
Filip Witkowski
-
0
50
4/5 - (1 vote)

Nawigacja:

Kontekst utrzymania ruchu a bezpieczeństwo szyfrowania i VPN

Dlaczego zdalny dostęp w utrzymaniu ruchu jest krytyczny

Utrzymanie ruchu bez zdalnego dostępu do maszyn i systemów sterowania praktycznie nie istnieje. Serwis producenta, dozór centralny, zdalne wsparcie inżyniera w nocy – to standard, a nie wyjątek. Jednocześnie każde nowe połączenie to kolejna brama, którą może wykorzystać atakujący. Jak to wygląda u ciebie: masz jasną listę kanałów zdalnego dostępu, czy raczej „kto potrzebuje, ten sobie coś organizuje”?

Typowe scenariusze, w których szyfrowanie i VPN grają kluczową rolę w utrzymaniu ruchu, to przede wszystkim:

  • zdalny serwis OEM – producent linii lub robota łączy się z twoją siecią, aby zdiagnozować usterkę albo wykonać modyfikację programu PLC;
  • wsparcie 24/7 – wewnętrzny inżynier automatyki lub administrator OT loguje się z domu, aby zrestartować serwer SCADA czy zmienić konfigurację urządzenia brzegowego;
  • nadzór parametrów linii – systemy zbierania danych (Historian, MES, systemy predykcyjnego utrzymania ruchu) raportują parametry do centrali lub do chmury.

W każdym z tych przypadków zdalny dostęp dotyka bezpośrednio infrastruktury OT, od której zależy ciągłość produkcji. Zastanów się: co jest dziś kryterium przy dopuszczaniu nowych rozwiązań zdalnego dostępu – wygoda, szybkość wdrożenia, czy spełnienie wymogów szyfrowania i polityki VPN?

Bezpieczny zdalny dostęp nie polega tylko na „posiadaniu VPN-a”. Kluczowe są szczegóły: kto może się łączyć, w jakim trybie (split / full tunnel), do jakich segmentów sieci, z jakim poziomem uprawnień. To właśnie te szczegóły powinny stać się osią audytu bezpieczeństwa technicznego w obszarze szyfrowania i VPN.

Różnice pomiędzy IT a OT w podejściu do szyfrowania

W klasycznym IT priorytetem jest poufność danych – wyciek dokumentów, danych osobowych czy informacji finansowych to temat wrażliwy w mediach i dla zarządu. W OT (Operational Technology) najboleśniejsza jest utrata dostępności: zatrzymanie linii, awaria pieca, brak możliwości bezpiecznego zatrzymania procesu. Jak to przekłada się na szyfrowanie i VPN w utrzymaniu ruchu?

W środowisku IT można sobie pozwolić na ostrzejsze polityki: wymuszanie najnowszych protokołów, częste rotacje kluczy, agresywne ograniczanie starszych urządzeń. W OT masz często stare sterowniki, panele HMI, systemy, które działają, ale nie wspierają nowoczesnych mechanizmów bezpieczeństwa. Pytanie brzmi: czy twoje procedury bezpieczeństwa są skopiowane z IT, czy zostały świadomie dostosowane do ograniczeń OT?

Różnica w podejściu do szyfrowania objawia się m.in. w:

  • akceptowalnym czasie przerwy – w IT kilka minut niedostępności serwera WWW przejdzie bez echa, w OT kilkusekundowy przestój może oznaczać produkcję odpadów lub uszkodzenie maszyny;
  • tolerancji na zmiany – aktualizacja klienta VPN na laptopach biurowych jest prosta; aktualizacja oprogramowania bramy komunikacyjnej w sieci produkcyjnej wymaga zaplanowania przestoju;
  • różnicy kompetencji – administratorzy IT zwykle dobrze rozumieją TLS, IPsec, certyfikaty; technicy utrzymania ruchu operują raczej na poziomie „działa / nie działa”, „jest połączenie / nie ma połączenia”.

Dlatego audyt szyfrowania i VPN w utrzymaniu ruchu musi uwzględniać, że część urządzeń nie obsługuje natywnie silnego szyfrowania. Zamiast próbować „dokręcać śrubę” w samych sterownikach, lepiej czasem wprowadzić segregację sieci i bezpieczne bramy pośredniczące, a ruch do nich chronić VPN-em.

Czy twoje obecne zasady są zorientowane na realne ryzyko w OT, czy jedynie kopiują „best practice” z korporacyjnych sieci biurowych?

Powierzchnie ataku typowe dla działu utrzymania ruchu

Utrzymanie ruchu żyje „tymczasówkami”. Tymczasowe modemy GSM, tymczasowe mosty Wi-Fi, tymczasowe konta serwisowe. Problem w tym, że tymczasowe rozwiązania bardzo często zostają na zawsze. W kontekście szyfrowania i VPN najgroźniejsze są:

  • zdalne pulpity – RDP, VNC czy inne narzędzia dostępowe skonfigurowane bez właściwego tunelu VPN, nierzadko wystawione bezpośrednio do Internetu albo spięte przez prywatne TeamViewery;
  • nieautoryzowane modemy i routery – inżynier ustawił sobie dostęp „na szybko”: modem LTE w szafie sterowniczej, domyślne hasła, brak szyfrowania lub tunelu VPN, brak logowania połączeń;
  • „tymczasowe” połączenia – port forwarding na routerze, otwarcie portu VPN bez wpisania tego w rejestr, przejściowy dostęp producenta do linii automatycznej, który trwa już trzeci rok.

Wyobraź sobie sytuację: przestój linii, producent zdalnie diagnozuje problem przez swoje chmurowe rozwiązanie. Czy wiesz dokładnie, jak ten tunel wygląda od strony twojej sieci? Czy ruch jest szyfrowany od końca do końca, czy tylko między serwerem producenta a jego inżynierem, a u ciebie w fabryce idzie już czysty ruch po VLAN-ie OT?

Audyt ma za zadanie odpowiedzieć nie tylko na pytanie „czy jest VPN”, ale jakie są realne ścieżki komunikacji i na których odcinkach szyfrowanie faktycznie działa. Bez tej wiedzy polityka bezpieczeństwa pozostaje życzeniowa.

Cele audytu technicznego szyfrowania i VPN w utrzymaniu ruchu

Co audyt ma odpowiedzieć, a czego nie rozwiąże za ciebie

Audyt techniczny szyfrowania i VPN w utrzymaniu ruchu to narzędzie diagnostyczne. Dobrze przeprowadzony odpowie na konkretne pytania i da ci materiał do decyzji. Z czym chcesz wyjść po audycie? Z listą luk, z propozycją architektury docelowej, czy z oboma elementami?

Kluczowe odpowiedzi, których należy oczekiwać od audytu, to m.in.:

  • jak wygląda rzeczywisty podział ruchu szyfrowanego i nieszyfrowanego w sieciach związanych z utrzymaniem ruchu;
  • czy istnieją „dzikie” kanały zdalnego dostępu – prywatne TeamViewery, hotspoty GSM, stare serwery VPN, o których nikt już oficjalnie nie pamięta;
  • na ile obecne rozwiązania są spójne z polityką bezpieczeństwa firmy i normami branżowymi (ISO 27001, ISA/IEC 62443);
  • które obszary są krytycznie narażone i powinny być zabezpieczone w pierwszej kolejności.

Audyt nie zrobi jednak za ciebie kilku rzeczy. Nie rozwiąże konfliktów organizacyjnych między IT a utrzymaniem ruchu. Nie zastąpi decyzji, że stare urządzenia trzeba wymienić, bo nie wspierają szyfrowania. Nie zagwarantuje też bezpieczeństwa, jeśli po audycie wnioski zostaną odłożone na półkę.

Przy definiowaniu zakresu audytu odpowiedz sobie szczerze: czy celem jest tylko „szukanie dziur”, żeby odhaczyć compliance, czy zbudowanie modelu docelowego, do którego będziesz dążyć etapami? Od tej odpowiedzi zależy głębokość analizy i to, jak wiele energii włożysz w dokumentowanie procedur.

Ustalenie faktycznego stanu ruchu szyfrowanego i nieszyfrowanego

Teoretycznie wszystkie połączenia z zewnątrz powinny przechodzić przez firmowy VPN. Praktyka pokazuje, że im bardziej rozproszona i złożona jest infrastruktura OT, tym więcej wyjątków. Audyt ma za zadanie zweryfikować, jak naprawdę wygląda ruch sieciowy w obszarach, które dotyka utrzymanie ruchu.

Kluczowe kroki to:

  • zidentyfikowanie wszystkich bram komunikacyjnych, routerów, firewalli, przez które może przechodzić ruch zdalny;
  • przegląd reguł firewalli i konfiguracji VPN – kto ma dostęp, z jakich adresów, do jakich sieci, jakimi protokołami;
  • analiza ruchu sieciowego w reprezentatywnych punktach (mirroring portów, TAP-y sieciowe) pod kątem obecności nieszyfrowanych protokołów – Modbus/TCP, HTTP, Telnet, stare wersje SMB, protokoły producentów PLC.

Czy wiesz, jaki procent ruchu z/do segmentu OT idzie dziś w formie zaszyfrowanej, a jaki „plain text”? Jeśli nie, jednym z pierwszych celów audytu powinna być próba jak najdokładniejszej odpowiedzi na to pytanie. Nie po to, żeby wszystkie protokoły natychmiast „opakować” w VPN, ale żeby świadomie zdecydować, które wymagają dodatkowych zabezpieczeń, a które są akceptowalne tylko w zamkniętych, fizycznie odseparowanych segmentach.

Wykrycie „dzikich” tuneli i nieformalnych rozwiązań

Wiele incydentów bezpieczeństwa w środowisku produkcyjnym nie zaczyna się od złamania „oficjalnych” procedur, ale od wykorzystania bocznej furtki. W utrzymaniu ruchu taką furtką może być prywatny TeamViewer na laptopie technika, modem LTE zamontowany w szafie automatyki czy stary serwer VPN po dawnym integratorze.

Podczas audytu trzeba założyć, że nie wszystkie ścieżki dostępu są znane i udokumentowane. Dlatego oprócz analizy konfiguracji warto wykonać kilka ruchów „miękkich”:

  • rozmowy z technikami, mistrzami, inżynierami – pytanie wprost: „czego używacie, gdy trzeba szybko połączyć się z maszyną albo poprosić serwis?”;
  • przegląd laptopów serwisowych – lista zainstalowanych programów zdalnego dostępu, konfiguracje klientów VPN, zapisane połączenia RDP;
  • skanowanie sieci lokalnych pod kątem nieznanych modemów, routerów Wi-Fi, urządzeń z dostępem zewnętrznym;
  • sprawdzenie logów firewalli pod kątem nietypowych połączeń wychodzących (np. stałe sesje do chmurowych serwerów producenta maszyn).

Zadaj sobie pytanie: gdyby ktoś zapytał cię dziś o pełną listę rozwiązań stosowanych przez służby techniczne do zdalnego dostępu, czy potrafiłbyś ją wypisać bez wahania? Jeśli nie – audyt musi mieć silny komponent wykrywania tego typu „shadow IT/OT”.

Określenie priorytetów i modelu docelowego

Audyt bez priorytetyzacji generuje tylko długą listę problemów. W utrzymaniu ruchu gdzie każda zmiana może oznaczać ryzyko dla produkcji, kluczowe jest jasne określenie, co zabezpieczyć najpierw, a co może poczekać. Jak zwykle: masz ograniczone zasoby – ludzi, budżet, czas postoju.

Priorytety można wyznaczać m.in. według kryteriów:

  • wpływ na bezpieczeństwo ludzi i środowiska – systemy odpowiedzialne za bezpieczeństwo procesowe (SIS), zabezpieczenia maszyn;
  • wpływ na ciągłość produkcji – kluczowe linie, których awaria powoduje duże straty;
  • poziom ekspozycji na świat zewnętrzny – systemy z bezpośrednim lub pośrednim dostępem przez Internet, chmurę, sieci dostawców;
  • stan aktualny – obszary, w których brak jest jakiejkolwiek kontroli nad zdalnym dostępem i szyfrowaniem.

Dobre podejście to zdefiniowanie modelu docelowego architektury zdalnego dostępu i szyfrowania, a potem „mapowanie” do niego obecnego stanu. W ten sposób z audytu powstaje nie tylko raport, ale także plan migracji: od sytuacji „każdy robi po swojemu” do spójnej polityki VPN i szyfrowania w środowisku utrzymania ruchu.

Inwentaryzacja środowiska: systemy, połączenia, sprzęt

Mapowanie zasobów OT i IT kluczowych dla utrzymania ruchu

Żaden audyt szyfrowania i VPN nie będzie rzetelny, jeśli nie wiadomo dokładnie, co ma być chronione. Utrzymanie ruchu operuje na styku IT i OT: sięga do serwerów Windows, baz danych i jednocześnie do sterowników PLC, HMI i urządzeń polowych. Jak szeroko dziś widzisz swoje środowisko?

Podstawą jest utworzenie możliwie pełnej listy zasobów, które:

  • obsługują proces produkcyjny (systemy OT);
  • są zarządzane lub używane przez utrzymanie ruchu (laptopy serwisowe, serwery inżynierskie, stacje diagnostyczne);
  • mają jakikolwiek związek ze zdalnym dostępem lub transferem danych na zewnątrz.

Minimalny zakres inwentaryzacji po stronie OT powinien obejmować:

  • sterowniki PLC różnych producentów (z wersjami firmwaru, obsługiwanymi protokołami, trybem komunikacji);
  • panele HMI i panele operatorskie z interfejsami sieciowymi;
  • systemy SCADA, Historian, MES, systemy monitoringu stanu maszyn;
  • przemysłowe switche i routery, serwery czasu, firewalle przemysłowe;
  • stacje inżynierskie, serwery licencji, serwery backupu konfiguracji sterowników.

Po stronie IT (w zakresie, w jakim dotyczy utrzymania ruchu) w inwentaryzacji znajdą się m.in.:

  • serwery aplikacyjne z dostępem do danych produkcyjnych;
  • usługi katalogowe, serwery VPN, systemy uwierzytelniania;
  • systemy SIEM, loggery, które zbierają zdarzenia z urządzeń OT;

    • Identyfikacja ścieżek komunikacji i zależności między systemami

    Lista urządzeń to za mało. Dla audytu szyfrowania i VPN kluczowe są ścieżki komunikacji między tymi elementami. Zadaj sobie pytanie: czy wiesz, którędy dokładnie „płynie” sygnał od zdalnego serwisanta do konkretnego sterownika, krok po kroku?

    Praktyczne podejście to budowa mapy zależności, choćby w prostej formie diagramu sieci:

  • zaznaczenie wszystkich segmentów: biuro (IT), DMZ, OT (sieć sterowników, HMI, urządzeń polowych), sieci serwisowej;
  • wskazanie punktów styku: routery, firewalle, serwery pośredniczące, bramy do chmury;
  • opisanie typowych ścieżek: zdalny serwis → VPN → DMZ → SCADA → PLC lub technik UR → laptop serwisowy → Wi-Fi w hali → switch OT → sterownik.

Zadbaj o to, aby na mapie pojawiły się także:

  • połączenia do systemów dostawców (monitoring predykcyjny, portale serwisowe, chmury producentów);
  • połączenia między zakładami tej samej firmy (MPLS, SD-WAN, site-to-site VPN);
  • trasy awaryjne, np. łącza zapasowe GSM wykorzystywane przy awarii łącza głównego.

Jeśli dziś masz tylko „rysunek z projektu sprzed uruchomienia”, zapytaj: jak bardzo zdążyła się zmienić infrastruktura od tego czasu? Ile „dołożeń na szybko” dokonało utrzymanie ruchu lub integratorzy?

Zbieranie danych o konfiguracjach komunikacyjnych

Sam diagram logiczny to dopiero warstwa koncepcyjna. Audyt szyfrowania i VPN wymaga zejścia niżej: do konfiguracji urządzeń i usług. Bez tego nie ocenisz, czy ruch między dwoma punktami faktycznie jest szyfrowany.

Zgromadź w jednym miejscu (repozytorium audytowe) co najmniej:

  • konfiguracje routerów i switchy brzegowych w segmentach OT i DMZ;
  • konfiguracje firewalli (reguły, obiekty, strefy, profile bezpieczeństwa);
  • konfiguracje serwerów VPN (profile, grupy, szyfry, metody uwierzytelniania);
  • konfiguracje dostępu zdalnego w systemach SCADA, inżynierskich, serwerach licencji.

Dobrym pytaniem na tym etapie jest: gdzie dziś trzymasz konfiguracje urządzeń sieciowych i systemów OT? Czy w ogóle masz centralne repozytorium, czy wszystko zależy od tego, czy „Staszek ma jeszcze backupy na laptopie”?

Jeżeli konfiguracje nie są zebrane i zorganizowane, audyt jest okazją, by zacząć ten porządek. Same backupy konfiguracji, z datami i opisami, stają się jednym z kluczowych artefaktów bezpieczeństwa.

Inwentaryzacja kanałów zdalnego dostępu dla dostawców i serwisu

Najwięcej tuneli szyfrujących pojawia się przy dostępie zewnętrznym: serwis maszyn, nadzór producenta, konsultacje z integratorami. Tu też jest najwięcej wyjątków i „tymczasowych obejść”. Zadaj sobie pytanie: czy posiadasz pełną listę wszystkich podmiotów, które mają (lub miały) dostęp zdalny do twojej infrastruktury?

Podczas inwentaryzacji skup się na:

  • aktywnej liście dostawców i integratorów wraz z zakresem dostępu (które maszyny, linie, systemy);
  • stosowanych technologiach: VPN klient–serwer, VPN site-to-site, bramy zdalnego dostępu producenta, pulpity zdalne, dostęp przez chmurę;
  • punktach końcowych: jakie adresy IP przypisywane są zdalnym serwisantom, do jakich sieci mają trasę;
  • mechanizmach konta: loginy imienne, konta współdzielone, tymczasowe konta gościnne, dostęp na wezwanie.

Warto przejść przez logi serwera VPN i firewalli za ostatnie miesiące: kto się łączy, kiedy, do jakich zasobów. Czy widzisz ciągłe, „wiecznie otwarte” tunele, których nikt dziś świadomie nie potrzebuje?

Ocena dojrzałości dokumentacji i właścicielstwa zasobów

Nawet najlepiej przeprowadzona inwentaryzacja szybko się zestarzeje, jeśli nikt nie jest za nią odpowiedzialny. W utrzymaniu ruchu częsty jest scenariusz: „wszyscy się tym opiekują, ale nikt nie jest formalnym właścicielem”. Jak jest u ciebie?

Przy okazji audytu spójrz na:

  • czy każdy kluczowy system i segment sieci ma przypisanego właściciela biznesowego i technicznego;
  • czy istnieją procedury aktualizacji dokumentacji po każdej zmianie (MOC – Management of Change);
  • czy dla systemów krytycznych istnieją aktualne schematy sieci, listy interfejsów, opis zależności.

Jeśli dokumentacja istnieje tylko w głowach dwóch doświadczonych techników bliskich emerytury, audyt techniczny szyfrowania i VPN pokaże to bardzo wyraźnie. To dobry moment, by zadać pytanie: co się stanie z twoim bezpieczeństwem, jeśli jedna z tych osób jutro nie przyjdzie do pracy?

Polityki i standardy: na czym oprzeć procedury audytowe

Przegląd istniejących polityk bezpieczeństwa i standardów firmowych

Audyt techniczny nie działa w próżni. Kontrolujesz nie tylko „czy jest szyfrowanie”, ale na ile praktyka odpowiada przyjętym zasadom. Najpierw więc potrzebna jest odpowiedź: jakie zasady w ogóle obowiązują?

Zbierz i przeanalizuj:

  • politykę bezpieczeństwa informacji / cyberbezpieczeństwa na poziomie całej organizacji;
  • standardy i procedury dla sieci, zdalnego dostępu, zarządzania tożsamością i hasłami;
  • instrukcje dla utrzymania ruchu: jak wygląda „oficjalny” sposób kontaktu z serwisem, jak trzeba rejestrować połączenia;
  • wytyczne korporacyjne (jeśli należysz do grupy kapitałowej) dotyczące OT security, segmentacji, VPN.

Porównaj to z rzeczywistością. Czy zasady, które masz na papierze, były w ogóle konsultowane z utrzymaniem ruchu? Jeśli nie – ile jest w nich martwych zapisów, które w praktyce nigdy nie zadziałały?

Odniesienie do norm i dobrych praktyk (ISO 27001, ISA/IEC 62443, NIST)

Jeśli tworzysz procedury audytowe, wygodnie jest oprzeć je na uznanych standardach. Nie chodzi o ślepe wdrażanie każdej kontrolki, ale o ramę odniesienia. Zastanów się: czy twój audyt ma być elementem szerszego programu zgodności (compliance), czy przede wszystkim narzędziem poprawy bezpieczeństwa w praktyce?

Przydatne punkty odniesienia:

  • ISO/IEC 27001 i 27002 – definiują ogólne wymagania dla bezpieczeństwa informacji, w tym:
    • kontrole dotyczące kryptografii (dobór algorytmów, zarządzanie kluczami);
    • bezpieczeństwo sieci (segmentacja, kontrola dostępu, monitorowanie);
    • bezpieczne zarządzanie dostępem zdalnym.
  • ISA/IEC 62443 – skupia się na środowisku OT:
    • modele stref i kanałów (zones & conduits) – bardzo użyteczne przy mapowaniu VPN-ów i tuneli;
    • wymagania bezpieczeństwa dla komponentów (PLC, HMI, bramy komunikacyjne);
    • rozróżnienie poziomów bezpieczeństwa (SL) – pomocne przy priorytetyzacji.
  • NIST SP 800-82 – przewodnik po zabezpieczaniu systemów przemysłowych, z konkretnymi rekomendacjami dla protokołów i architektury.

Dobrym krokiem jest przygotowanie macierzy powiązań: wymaganie standardu → kontrola techniczna → punkt audytu. Na przykład: „Komunikacja zdalna powinna być szyfrowana i uwierzytelniana” → „Wszystkie połączenia z Internetu do sieci OT przechodzą przez centralny VPN z MFA” → „Sprawdzenie konfiguracji serwera VPN, logów i rzeczywistego ruchu na firewallu”.

Definiowanie wymagań minimalnych dla szyfrowania i VPN

Żeby audyt był konkretny, potrzebne są mierzalne kryteria. Jak inaczej ocenisz, czy dane rozwiązanie jest „wystarczająco dobre”? Zadaj sobie pytanie: jakie są u ciebie dziś minimalne wymagania dla szyfrowania w ruchu zdalnym i wewnątrz zakładu?

Przykładowe obszary, dla których warto zdefiniować minimum:

  • Algorytmy i długości kluczy – np. TLS 1.2/1.3, zakaz użycia przestarzałych szyfrów (DES, 3DES, RC4), minimalna długość klucza RSA/ECC;
  • Protokoły tunelowania – preferowane: IPsec (IKEv2), OpenVPN, WireGuard; zakaz używania PPTP, L2TP bez IPsec itd.;
  • Uwierzytelnianie – wymagane MFA dla dostępu zewnętrznego, loginy imienne zamiast kont współdzielonych, integracja z katalogiem (AD);
  • Zasady dostępu – „need-to-know” i „least privilege”: dostawca ma dostęp tylko do swoich maszyn, nie do całego segmentu;
  • Logowanie i monitoring – minimalny zestaw logów (kto, skąd, kiedy, do czego), wymagany czas przechowywania, integracja z SIEM.

Te minimalne wymagania stają się checklistą audytową. Na ich podstawie przeprowadzisz ocenę: spełnia/nie spełnia, wymaga usprawnienia, „akceptowane odstępstwo” (jeśli jest formalnie zatwierdzone).

Łączenie wymogów bezpieczeństwa z realiami utrzymania ruchu

Największą sztuką jest pogodzenie teorii z praktyką. Można napisać politykę, która idealnie odpowiada ISO i NIST, ale jest nierealna na hali, bo każda sesja serwisowa wymaga wdrożenia skomplikowanej procedury. Jak jest u ciebie – bezpieczeństwo blokuje serwis, czy raczej odwrotnie: serwis chodzi „na skróty”, ignorując polityki?

Przy projektowaniu wymagań szyfrowania i VPN dla UR warto:

  • włączyć w dyskusję mistrzów, techników i inżynierów – to oni najlepiej wiedzą, jak naprawdę wygląda praca i gdzie polityka może przeszkadzać;
  • zdefiniować scenariusze „tryb normalny” i „tryb awaryjny” – w awarii inne są priorytety, ale i tak można zachować minimum bezpieczeństwa (np. skrócenie ścieżki akceptacji, ale nie rezygnacja z VPN);
  • zaplanować szkolenia i wsparcie – jeśli wprowadzasz nowe narzędzia (np. centralny bastion zdalnego dostępu), zadaj sobie pytanie: kto nauczy ludzi ich używać i kto będzie im pomagał przy pierwszych trudnościach.

Dobra polityka dla szyfrowania i VPN w UR jest prosta do wytłumaczenia technikowi o 3 w nocy w trakcie awarii. Jeśli nie jesteś w stanie tego zrobić jednym-dwoma zdaniami, być może zasady są zbyt skomplikowane.

Audyt szyfrowania w praktyce: metody i obszary kontroli

Analiza konfiguracji protokołów szyfrowania i usług VPN

Gdy masz już zmapowane systemy, ścieżki i polityki, przychodzi czas na sedno: sprawdzenie, jak w praktyce skonfigurowane są mechanizmy szyfrowania. Od czego zacząć?

Pierwszym krokiem jest przegląd konfiguracji serwerów i bram VPN:

  • jakie profile VPN są zdefiniowane (dla użytkowników, dla dostawców, dla połączeń między lokalizacjami);
  • jakie protokoły i szyfry są dopuszczone;
  • jak wygląda polityka rekeyingu (co ile czasu odświeżany jest klucz sesji);
  • jakie są metody uwierzytelniania (certyfikaty, hasła, MFA, integracja z AD);
  • jakie sieci są dostępne po zestawieniu tunelu.

Równolegle warto przyjrzeć się konfiguracjom usług HTTPS, SSH, SFTP i innych protokołów szyfrowanych w systemach OT/IT (SCADA, serwery plików, systemy raportowe). Zwróć uwagę na:

  • wersje TLS – czy wciąż działa TLS 1.0/1.1, czy stare SSL;
  • obsługiwane zestawy szyfrów (cipher suites);
  • czy wymuszono szyfrowanie, czy jest ono opcjonalne (np. HTTP obok HTTPS);
  • czy wyłączono stare, podatne protokoły (np. Telnet, FTP, rlogin).

Na tym etapie zadaj sobie pytanie: czy twoje wymagania minimalne są naprawdę zaimplementowane w konfiguracjach, czy tylko w dokumentach?

Testy ruchu sieciowego: co jest naprawdę szyfrowane

Konfiguracje mówią, jak powinno być. Ruch sieciowy pokazuje, jak jest. Dlatego analiza realnego ruchu jest kluczowym elementem audytu.

Praktyczne podejście obejmuje:

  • uruchomienie mirroringu portów lub TAP-ów w wybranych punktach sieci (np. między DMZ a OT, przy serwerze SCADA, przy bramie VPN);

    • Identyfikacja nieszyfrowanej komunikacji i „wycieków” z tuneli

    Po zebraniu zrzutów ruchu przychodzi moment prawdy: co faktycznie idzie „w otwartym tekście”, a co rzeczywiście przechodzi przez szyfrowane kanały? Najpierw zadaj sobie pytanie: czy potrafisz dziś wskazać choć jeden krytyczny strumień danych, który na pewno nie jest szyfrowany? Jeśli nie – to pierwszy cel audytu.

    Praktyczny zestaw kroków może wyglądać tak:

  • przeskanowanie zrzutów pod kątem typowych niezabezpieczonych protokołów (HTTP, Telnet, FTP, Modbus/TCP, niezaszyfrowane SMTP);
  • oznaczenie strumieni, które dotyczą systemów krytycznych (SCADA, sterowniki, serwery raportowe) – nawet jeśli używają „branżowych” protokołów bez szyfrowania;
  • wyszukanie ruchu, który „omija” tunel VPN, chociaż zgodnie z założeniami powinien przechodzić przez bramę;
  • sprawdzenie, czy ruch z laptopów serwisowych faktycznie w całości leci przez tunel, czy jednak część pakietów wysyłana jest bezpośrednio (tzw. split tunneling).

Dopiero na tym poziomie widać, realne „dziury” w szyfrowaniu. Typowy przypadek: oficjalnie serwis ma łączyć się z linią przez centralny VPN, ale w praktyce część ruchu do PLC idzie po lokalnej, nieszyfrowanej sieci, bo ktoś kiedyś „tymczasowo” wstawił dodatkowy router.

Dla każdej zidentyfikowanej nieszyfrowanej ścieżki zadaj trzy pytania:

  • jakie dane płyną tym kanałem (parametry procesu, receptury, loginy, pliki konfiguracyjne);
  • kto może mieć do niego dostęp (tylko lokalna hala, cały zakład, świat przez Internet);
  • jaki wpływ miałaby modyfikacja lub podsłuchanie tych danych na bezpieczeństwo ludzi i ciągłość produkcji.

To pozwoli od razu przypisać priorytety. Nie zaszyfrujesz wszystkiego jednocześnie, ale możesz bardzo świadomie zdecydować: od czego zaczynasz?

Weryfikacja zarządzania kluczami kryptograficznymi

Dobrze skonfigurowany VPN czy TLS to połowa sukcesu. Druga połowa to bezpieczne zarządzanie kluczami. Jak dziś tworzysz, przechowujesz i rotujesz klucze w środowisku UR?

Podczas audytu przyjrzyj się kilku obszarom:

  • Generowanie kluczy – czy klucze generowane są na zaufanych urządzeniach (HSM, serwerach, kontrolerach domeny), czy na przypadkowym laptopie dostawcy;
  • Przechowywanie – czy prywatne klucze są zaszyfrowane, gdzie leżą pliki .pfx/.key, kto ma do nich dostęp;
  • Dystrybucja – w jaki sposób przekazywane są certyfikaty i klucze do serwerów, sterowników, bram VPN; czy robione jest to przez bezpieczny kanał;
  • Rotacja i wygasanie – jak wygląda proces przedłużania certyfikatów; czy masz alerty przed wygaśnięciem; kto odpowiada za ich aktualizację na urządzeniach OT;
  • Unieważnianie – czy w ogóle funkcjonuje mechanizm CRL/OCSP, czy stosujesz listy unieważnionych certyfikatów w praktyce.

Zapytaj siebie i zespół: jeśli jutro zgubisz laptop serwisowy, po ilu minutach jesteś w stanie unieważnić powiązane certyfikaty i konta VPN? Jeśli odpowiedzią jest „to skomplikowane”, audyt powinien to wyeksponować jako istotny problem.

Ocena implementacji szyfrowania w systemach OT

W wielu zakładach szyfrowanie kończy się na bramie VPN i firewallu. W środku segmentu OT panuje „zaufana wyspa”. Jak jest u ciebie? Czy kontrolery, panele HMI, serwery receptur mają choćby opcjonalne mechanizmy szyfrowania?

Przy analizie komponentów OT skup się na:

  • obsługiwanych wersjach protokołów (np. Modbus/TCP vs Modbus Secure, OPC DA vs OPC UA);
  • dostępnych opcjach szyfrowania i uwierzytelniania w firmware (często są, ale nikt ich nie włączył);
  • aktualności firmware’u – starsze wersje bywają pozbawione podstawowych funkcji bezpieczeństwa;
  • sposobie zdalnego programowania PLC/HMI – czy wykorzystywane są zabezpieczone kanały (np. bezpieczne tunelowanie narzędzia inżynierskiego przez VPN), czy ruch leci „gołym” Ethernetem.

Audyt w tym obszarze warto połączyć z rozmową z dostawcami maszyn: jakie minimum szyfrowania jesteście w stanie realnie włączyć bez utraty wsparcia? Bywa, że producent udostępnia nowsze obrazy firmware lub zalecane konfiguracje, o których utrzymanie ruchu nigdy nie zostało poinformowane.

Kontrola dostępu do tuneli VPN i sesji zdalnych

Samo szyfrowanie nie rozwiązuje problemu, jeśli każdy może wejść w tunel. Kolejny obszar audytu to weryfikacja, kto i na jakich zasadach nawiązuje połączenia VPN do środowiska UR i OT.

Kluczowe pytania diagnostyczne:

  • czy istnieje centralna lista aktywnych kont VPN (dla pracowników, integratorów, serwisów producentów);
  • kiedy ostatni raz ją weryfikowano pod kątem osób, które już nie pracują lub nie świadczą usług;
  • czy każde konto jest imienne, czy wciąż funkcjonują „serwis1”, „vendor”, „utrzymanie”;
  • czy włączono MFA dla dostępu z zewnątrz, także dla dostawców;
  • czy istnieją różne profile dostępu (np. inny dla UR, inny dla IT, inny dla serwisu producenta linii).

W praktyce dobrze sprawdzają się bastiony zdalnego dostępu, które po zestawieniu VPN nie wpuszczają użytkownika od razu do sieci OT, lecz prezentują mu ograniczoną pulę systemów lub pulpitów zdalnych. Audyt powinien ocenić, czy takie rozwiązanie funkcjonuje i jak jest skonfigurowane:

  • czy sesje są nagrywane (tam, gdzie jest to prawnie i organizacyjnie dopuszczalne);
  • czy można w czasie rzeczywistym podejrzeć trwającą sesję serwisową;
  • czy każda sesja ma zdefiniowany kontekst: kto, do czego, w jakim celu.

Zadaj zespołowi proste pytanie: gdybyś dziś chciał zobaczyć, co robił w zeszłym tygodniu serwis producenta mieszalnika, masz jakiekolwiek logi lub nagrania? Odpowiedź pokaże gotowość organizacji na poważniejszy incydent.

Spójność logów, korelacja zdarzeń i ślad audytowy

Szyfrowanie i VPN bez śladu audytowego to czarna skrzynka. Audyt powinien sprawdzić, czy jesteś w stanie odtworzyć historię połączeń na tyle, by zrozumieć, co wydarzyło się w krytycznym momencie.

Przyjrzyj się kilku elementom:

  • Źródła logów – bramy VPN, firewalle, bastiony, serwery RDP, kontrolery domeny, kluczowe systemy OT (jeśli logują dostęp);
  • Synchronizacja czasu – czy wszystkie urządzenia korzystają z tego samego NTP, z poprawną strefą czasową; bez tego korelacja logów jest bardzo trudna;
  • Centralizacja – czy logi są zbierane do SIEM lub przynajmniej do scentralizowanego sysloga;
  • Zakres logowania – czy rejestrowane są same loginy, czy również informacje o tym, co zostało wykonane (komendy, zmiany konfiguracji, przesłane pliki);
  • Czas retencji – jak długo przechowywane są logi związane z zdalnym dostępem i szyfrowaniem.

Dobrą praktyką jest zrobienie próby odtworzeniowej: wybierz jedno prawdziwe zdarzenie (np. sesję serwisową sprzed kilku dni) i spróbuj – korzystając z logów – odpowiedzieć na pytania: kto, kiedy, skąd, gdzie, przez jaki kanał, z jakim rezultatem. Jeśli potrzebujesz na to kilku godzin i pięciu osób, wniosek z audytu nasuwa się sam.

Ocena procedur awaryjnych: szyfrowanie w trybie „pożaru”

Normalny dzień to jedno, awaria krytycznej linii to zupełnie inny świat. Jak wyglądają twoje procedury szyfrowanego dostępu w sytuacjach nagłych? Czy istnieje osobny tryb „awaryjny”, czy po prostu każdy może „na szybko” ominąć zabezpieczenia?

Podczas audytu przeanalizuj:

  • czy procedury awaryjne dopuszczają downgrade bezpieczeństwa (np. dostęp bez VPN, użycie prostych haseł), a jeśli tak – kto może o tym zdecydować i jak jest to dokumentowane;
  • czy istnieją przygotowane awaryjne konta dostępu lub tokeny, przechowywane w bezpieczny sposób (np. sejf, system zarządzania tajemnicami) – i kto ma do nich dostęp;
  • jak wygląda logowanie w trybie awaryjnym – czy nadal rejestrujesz, kto i do czego się podłącza;
  • czy po zakończeniu awarii wykonywany jest przegląd sesji awaryjnych i cofane są wszelkie tymczasowe wyjątki (dodatkowe reguły firewall, otwarte porty, konta).

Zadaj dyspozytorowi lub mistrzowi proste pytanie: co robisz, gdy o 2:30 w nocy dzwoni producent maszyny i mówi, że musi wejść na sterownik „od razu, bo produkcja stoi”? To, jaką odpowiedź usłyszysz, jest lepszym testem procedur niż najładniejszy dokument.

Audyt dostępu dostawców i integratorów w kontekście szyfrowania

Środowisko UR w dużym stopniu opiera się na zewnętrznych firmach. Każdy dostawca, który ma zdalny dostęp, wnosi własne ryzyka. W audycie dobrze wyodrębnić ten obszar jako osobny moduł.

Skup się na kilku zagadnieniach:

  • Umowy i SLA – czy w kontraktach z dostawcami zapisane są wymagania dotyczące szyfrowania, VPN, MFA, logowania i poufności;
  • Onboarding – jak nowy dostawca otrzymuje dostęp: kto akceptuje, jakie testy przechodzi, czy podpisuje zobowiązania dot. bezpieczeństwa;
  • Offboarding – co dzieje się z dostępami po zakończeniu projektu lub kontraktu; czy konta są kasowane, certyfikaty unieważniane;
  • Standard narzędzi – czy wymuszasz korzystanie z twojej infrastruktury (centralny VPN, bastion), czy dostawcy mogą stosować własne narzędzia zdalne (TeamViewer, AnyDesk, własne bramy VPN);
  • Separacja dostawców – czy każdy ma odrębne profile i sieci docelowe, czy wszyscy lądują w jednej „piaskownicy” z szerokimi uprawnieniami.

Dobrym ćwiczeniem jest wylistowanie wszystkich firm, które mogą dziś połączyć się z twoimi maszynami, a następnie sprawdzenie: dla ilu z nich masz aktualne dane kontaktowe, podpisane umowy, jasno zdefiniowane zakresy odpowiedzialności i techniczne parametry połączeń. Wynik tego ćwiczenia często zaskakuje.

Przegląd procesów zmiany konfiguracji szyfrowania i VPN

Konfiguracja VPN i mechanizmów szyfrowania to nie jest coś, co ustawia się raz na 10 lat. Technologia się zmienia, dochodzą nowe maszyny, nowe lokalizacje, nowe wymagania klientów. Kluczowe pytanie brzmi: jak zarządzasz zmianami w tym obszarze?

Podczas audytu przeanalizuj:

  • czy zmiany w konfiguracji VPN, firewalli, certyfikatów przechodzą przez formalny proces (RFC, CAB, choćby prostą akceptację mailową);
  • kto ma prawo wprowadzać zmiany i na jakim poziomie (reguły firewall, nowe profile VPN, aktualizacja firmware bram);
  • czy istnieje środowisko testowe do weryfikacji większych zmian, zanim trafią na produkcję;
  • jak wygląda dokumentowanie zmian: czy po roku można odtworzyć, kto i dlaczego otworzył dodatkowy port lub dodał nowy tunel;
  • czy zmiany są regularnie przeglądane pod kątem „tymczasowych” wyjątków, które stały się stałe.

Dobrym narzędziem jest tu przegląd kwartalny konfiguracji – łączysz wyniki audytu z logami zmian i weryfikujesz: które wyjątki nadal są potrzebne, a które można wycofać. To prosty sposób na redukcję „technicznego długu bezpieczeństwa”.

Ocena świadomości i praktyk użytkowników końcowych

Najlepsze mechanizmy szyfrowania i VPN można łatwo obejść złymi nawykami. Jak twoi ludzie podchodzą do tematu bezpieczeństwa zdalnego dostępu? Nie chodzi o ogólne „czy wszyscy przeszli szkolenie e-learningowe”, tylko o realną praktykę.

W trakcie audytu:

  • przeprowadź krótkie rozmowy z technikami, mistrzami, inżynierami UR – jak faktycznie łączą się z maszynami, czego używają, co ich najbardziej irytuje w obecnych rozwiązaniach;
  • zapytaj o typowe „obejścia” – czasami usłyszysz szczere: „VPN jest tak wolny, że szybciej jest podpiąć się bezpośrednio do switcha na hali”;

    • Najczęściej zadawane pytania (FAQ)

    Na czym polega bezpieczny zdalny dostęp w utrzymaniu ruchu – czy sam VPN wystarczy?

    Sam fakt „posiadania VPN-a” nie oznacza jeszcze bezpiecznego zdalnego dostępu. Kluczowe są szczegóły: kto może się łączyć, skąd, w jakim trybie (split czy full tunnel) i do jakich segmentów sieci OT ma realnie dostęp. Zastanów się: czy twoje obecne reguły dostępu jesteś w stanie narysować na kartce, czy raczej „wszyscy mają wszystko”?

    Bezpieczny model zakłada:

    • centralny, udokumentowany punkt wejścia (brama VPN / jump server),
    • dostęp przydzielany per rola i zadanie, a nie „hurtowo” do całej sieci produkcyjnej,
    • logowanie sesji i działań (kto, kiedy, skąd, do czego się łączył),
    • zastosowanie szyfrowanych protokołów także wewnątrz tunelu (np. SSH zamiast Telnet).

    Jeśli dziś nie wiesz dokładnie, jakimi ścieżkami ruch idzie do sterowników i serwerów SCADA, audyt techniczny szyfrowania i VPN powinien to w pierwszej kolejności uporządkować.

    Czym różni się podejście do szyfrowania w IT i OT i dlaczego ma to znaczenie przy audycie?

    W IT priorytetem jest poufność danych – typowy strach to wyciek dokumentów czy danych osobowych. W OT najboleśniejsza jest utrata dostępności: zatrzymanie linii, awaria pieca, brak możliwości bezpiecznego zatrzymania procesu. Dlatego polityki „skopiowane z IT” potrafią sparaliżować produkcję, gdy bezrefleksyjnie wdrożysz je w sterownikach czy systemach SCADA.

    Podczas audytu szyfrowania i VPN w OT trzeba szukać kompromisu: jak podnieść poziom ochrony, nie rozwalając dostępności. Zadaj sobie pytanie: które urządzenia realnie są w stanie obsłużyć nowoczesne szyfrowanie, a dla których lepiej zbudować bezpieczną bramę pośredniczącą i odseparować je sieciowo, zamiast „dokręcać śrubę” wprost na nich?

    Jakie są najczęstsze luki w zdalnym dostępie utrzymania ruchu (modemy, TeamViewer, RDP)?

    W utrzymaniu ruchu największy problem to „tymczasówki”, które zostają na zawsze. Typowe przykłady z audytów: modem LTE w szafie sterowniczej z domyślnymi hasłami, prywatny TeamViewer technika spięty z panelem HMI, port RDP wystawiony do Internetu „na weekend”, a otwarty trzeci rok. Jak wiele takich „skrótów” masz dziś w swoich liniach?

    Z perspektywy szyfrowania i VPN krytyczne są:

    • zdalne pulpity (RDP, VNC) dostępne bez tunelu VPN lub z niekontrolowanego narzędzia chmurowego,
    • nieautoryzowane modemy GSM / routery z własnym dostępem do Internetu,
    • „chwilowe” tunelowanie portów i konta serwisowe, których nikt potem nie kasuje.

    Audyt techniczny powinien te elementy wyłapać, skatalogować i zaproponować alternatywy: centralny system zdalnego dostępu, standard na modemy serwisowe, procedurę zakładania i zamykania dostępu producentom.

    Jak przeprowadzić audyt ruchu szyfrowanego i nieszyfrowanego w sieci OT?

    Na początek potrzebujesz odpowiedzi na proste pytanie: jaki procent ruchu z/do segmentu OT idzie dziś „wprost” (plain text), a jaki jest tunelowany i szyfrowany? Jeśli nie masz choćby przybliżonego obrazu, audyt zacznij od inwentaryzacji punktów styku OT–IT i możliwych dróg zdalnego dostępu.

    Praktyczne kroki to:

    • identyfikacja wszystkich bram, routerów, firewalli prowadzących do OT,
    • przegląd konfiguracji VPN (kto, skąd, do czego) i reguł firewalli,
    • analiza ruchu na wybranych punktach (port mirroring, TAP), pod kątem nieszyfrowanych protokołów: Modbus/TCP, HTTP, Telnet, stare SMB, protokoły producentów PLC.

    Dopiero na tej podstawie możesz zdecydować, czy najpierw uszczelniasz istniejące tunele VPN, czy zamykasz konkretny, nieszyfrowany ruch w krytycznych segmentach.

    Jak bezpiecznie zorganizować zdalny serwis OEM i dostęp 24/7 do linii produkcyjnych?

    Podstawowe pytanie brzmi: kto kontroluje tunel – ty czy producent? Popularny scenariusz to chmurowe rozwiązanie OEM, gdzie szyfrowanie działa między serwerem producenta a jego inżynierem, ale w twojej sieci ruch z serwera OEM do PLC czy HMI bywa już „goły”. Przy awariach liczy się czas, ale czy chcesz płacić za to pełnym zaufaniem do infrastruktury, nad którą nie masz kontroli?

    Bezpieczniejszy model to:

    • zdalny serwis OEM zawsze przez twoją bramę VPN albo jump server w DMZ OT,
    • stały, wąski zakres adresów i portów dostępnych dla danego producenta,
    • dostęp czasowy – uruchamiany na zgłoszenie i zamykany po zakończeniu prac,
    • pełne logi sesji (czas, zakres, ewentualnie nagranie pulpitu przy krytycznych ingerencjach).

    Wewnętrzny dostęp 24/7 (inżynier z domu) powinien być traktowany podobnie: firmowy VPN, MFA, ograniczone sieci docelowe, a nie „całe OT po zdalnym pulpicie”.

    Jak pogodzić wymagania norm (ISO 27001, ISA/IEC 62443) z realiami starych urządzeń w OT?

    Normy branżowe wskazują kierunek: segmentacja, kontrolowany zdalny dostęp, szyfrowanie, zarządzanie dostępem. Nie mówią jednak, że masz z dnia na dzień wymienić wszystkie stare sterowniki. Pytanie, które warto sobie zadać: gdzie muszę spełnić wymóg „twardo”, a gdzie mogę zastosować środek kompensujący (np. strefę pośrednią, dodatkowy firewall, jump host)?

    Typowe podejście etapowe:

    • krok 1 – inwentaryzacja urządzeń, które nie wspierają nowoczesnych mechanizmów szyfrowania,
    • krok 2 – odseparowanie ich w wydzielonych segmentach OT z jasno zdefiniowanymi ścieżkami dostępu,
    • krok 3 – ochrona tych ścieżek mocnym VPN-em i kontrolą dostępu,
    • krok 4 – plan wymiany najbardziej ryzykownych urządzeń, rozłożony na lata.

    Audyt techniczny powinien pomóc zbudować taki plan, a nie tylko „odhaczyć” brak TLS na sterowniku jako pojedynczą lukę bez kontekstu.

    Co powinno być konkretnym wynikiem audytu technicznego szyfrowania i VPN w utrzymaniu ruchu?

    Najważniejsze wnioski

  • Zdalny dostęp w utrzymaniu ruchu jest krytyczny dla ciągłości produkcji, ale każda nowa ścieżka połączenia (OEM, wsparcie 24/7, systemy Historian/MES) tworzy dodatkową bramę dla atakującego – czy masz ich pełny, aktualny rejestr?
  • Sam fakt „posiadania VPN-a” niewiele znaczy; kluczowe są szczegóły: kto się łączy, jakim trybem (split/full tunnel), do jakich segmentów OT i z jakimi uprawnieniami, bo to one powinny być osią audytu technicznego.
  • OT ma inne priorytety niż IT – tu centrum ciężkości jest na dostępności i bezpieczeństwie procesu, dlatego polityki szyfrowania nie mogą być bezrefleksyjnie skopiowane z biurowej sieci, tylko świadomie dopasowane do ograniczeń sterowników, HMI i bram komunikacyjnych.
  • Część urządzeń OT nie obsługuje silnego szyfrowania, więc lepszym podejściem bywa segmentacja sieci i stosowanie bezpiecznych bram pośredniczących chronionych VPN-em niż próba „dokręcenia śruby” bezpośrednio na starych sterownikach – jak dziś rozwiązujesz takie kompromisy?
  • Najgroźniejsze powierzchnie ataku w utrzymaniu ruchu wynikają z „tymczasówek”, które zostają na stałe: zdalne pulpity bez VPN, prywatne TeamViewery, modemy LTE z domyślnymi hasłami, port forwarding skonfigurowany „na szybko” i nigdzie nieudokumentowany.

Polecane dla Ciebie: