Analiza bezpieczeństwa sieci OT: co sprawdzić przed podłączeniem maszyn do internetu?

Podłączenie maszyny przemysłowej do internetu może rozwiązać realny problem: ułatwić diagnostykę, przyspieszyć reakcję serwisu albo przesyłać dane do systemu nadrzędnego. Ten sam krok może jednak otworzyć drogę do nieautoryzowanej zmiany programu PLC, zatrzymania linii, utraty danych procesowych lub przejęcia konta serwisowego.

Największym błędem nie jest samo wykorzystanie internetu w środowisku OT. Błędem jest podłączenie urządzenia bez ustalenia, jaki dostęp jest potrzebny, kto go użyje, do czego ma prowadzić i jak szybko można go odłączyć. Analiza bezpieczeństwa sieci OT powinna poprzedzać konfigurację routera, reguł zapory i tunelu VPN.

Decyzja nie powinna brzmieć wyłącznie: „czy maszyna może być online?”. Trafniejsze pytania są bardziej szczegółowe:

• czy potrzebne jest połączenie wychodzące, czy także przychodzące;
• czy dostęp ma dotyczyć danych, aplikacji operatorskiej, komputera przemysłowego czy sterownika;
• czy połączenie będzie stałe, czy uruchamiane tylko na czas serwisu;
• czy urządzenie jest wspierane, możliwe do odtworzenia i objęte monitoringiem;
• czy po awarii da się szybko wrócić do bezpiecznego trybu lokalnego.

Czy maszyna OT rzeczywiście musi mieć dostęp do internetu?

Internet jako potrzeba operacyjna, nie domyślna konfiguracja

Maszyna nie powinna otrzymywać dostępu do internetu tylko dlatego, że ma kartę sieciową albo producent oferuje panel chmurowy. Najpierw trzeba opisać konkretną potrzebę. Inaczej wygląda wymaganie „przesyłamy temperaturę i liczniki produkcji”, inaczej „serwis ma czasem połączyć się z komputerem HMI”, a jeszcze inaczej „producent musi zarządzać sterownikiem z dowolnego miejsca”. Każdy z tych scenariuszy wymaga innej architektury i niesie inne ryzyko.

W praktyce często wystarczy ruch wychodzący z kontrolowanego urządzenia pośredniczącego. Brama IIoT może pobierać określone dane z maszyny i przekazywać je do systemu raportowego, bez udostępniania PLC bezpośrednio w internecie. Jeżeli potrzebne jest wsparcie serwisowe, dostęp można uruchamiać na żądanie, po akceptacji osoby odpowiedzialnej za linię.

Trzeba odróżnić kilka pojęć, które bywają używane zamiennie:

• dostęp wychodzący — urządzenie lub brama inicjuje połączenie do wskazanego serwera;
• zdalny serwis — uprawniony użytkownik otrzymuje dostęp do wybranych zasobów na określony czas;
• połączenie z chmurą — dane, zdarzenia lub konfiguracje są wymieniane z usługą dostawcy;
• zdalny pulpit — użytkownik steruje sesją na komputerze przemysłowym;
• pełna ekspozycja urządzenia — maszyna lub jej usługa jest osiągalna z internetu, często przez publiczny adres albo przekierowanie portu.

Ostatni wariant powinien być traktowany jako sygnał alarmowy. Bezpośrednie wystawienie HMI, serwera SCADA, panelu webowego albo sterownika do internetu zwiększa powierzchnię ataku i utrudnia kontrolę nad tym, kto oraz z jakiego miejsca próbuje się połączyć. Sam fakt, że urządzenie wymaga hasła, nie oznacza, że taka architektura jest akceptowalna.

Kiedy podłączenie ma sens, a kiedy lepiej go uniknąć

Połączenie ma sens, gdy istnieje jasno opisany cel biznesowy lub techniczny, a właściciel procesu rozumie konsekwencje. Przykładem może być zdalna diagnostyka kosztownego urządzenia, którego producent jest jedynym podmiotem zdolnym do analizy awarii. Innym scenariuszem jest przesyłanie danych o wydajności do systemu nadrzędnego, jeżeli dane są potrzebne do planowania produkcji.

Decyzja „tak” powinna być warunkowa. Połączenie jest uzasadnione dopiero wtedy, gdy można ograniczyć je do konkretnych systemów, protokołów, adresów, użytkowników i przedziałów czasowych. Dodatkowo musi istnieć sposób na natychmiastowe odłączenie kanału bez zatrzymywania całej infrastruktury albo — jeżeli zatrzymanie jest nieuniknione — z użyciem zatwierdzonej procedury. ^[3]

Lepsza odpowiedź brzmi „jeszcze nie”, gdy urządzenie jest niewspierane, nie ma kompletnej dokumentacji, korzysta z domyślnych kont albo znajduje się w płaskiej sieci razem z komputerami biurowymi. Podobnie należy odłożyć projekt, jeżeli nikt nie potrafi wskazać właściciela dostępu, nie ma kopii konfiguracji i nie wiadomo, jakie inne urządzenia komunikują się z maszyną.

Typowy przykład to producent potrzebujący zdalnego dostępu kilka razy w roku. Stałe połączenie VPN z szerokim dostępem nie jest wtedy konieczne. Bezpieczniejszy może być kanał uruchamiany na czas konkretnej interwencji, z zatwierdzeniem, kontem imiennym, rejestrowaniem sesji i automatycznym wyłączeniem po zakończeniu okna serwisowego.

Tabela decyzyjna: kiedy tak, a kiedy nie

Najpierw inwentaryzacja: co dokładnie ma zostać podłączone?

Zidentyfikuj urządzenia, systemy i zależności

Nie da się rzetelnie ocenić bezpieczeństwa sieci OT, jeżeli wiadomo jedynie, że „do internetu zostanie podłączona linia produkcyjna”. Linia może obejmować kilkadziesiąt elementów o różnym poziomie krytyczności: PLC, moduły wejść i wyjść, HMI, komputery przemysłowe, serwery SCADA, przełączniki, routery, punkty dostępowe, bramy IIoT, stacje inżynierskie i urządzenia dostawców.

Minimalna inwentaryzacja powinna zawierać nazwę urządzenia, producenta, model, numer seryjny lub identyfikator, lokalizację, adresację sieciową, wersję systemu i oprogramowania, właściciela oraz funkcję w procesie. Dobrze zapisać także sposób administracji, zależności od innych urządzeń, źródło czasu i informację o tym, czy urządzenie może zostać wymienione bez przebudowy całej linii.

Właściciel techniczny nie zawsze jest właścicielem ryzyka. Automatyk może odpowiadać za konfigurację PLC, dział IT za firewall, a kierownik produkcji za skutki postoju. Przed podłączeniem trzeba wyznaczyć osoby odpowiedzialne za decyzję, zatwierdzenie okna serwisowego, reakcję na alarm i odłączenie połączenia.

Każde urządzenie należy przypisać do poziomu krytyczności. Inaczej traktuje się komputer służący wyłącznie do wizualizacji, inaczej sterownik odpowiadający za sekwencję procesu, a jeszcze inaczej system związany z bezpieczeństwem ludzi lub ochroną środowiska. Ocena powinna uwzględniać: ^[1]

• wpływ awarii na bezpieczeństwo pracowników;
• wpływ na ciągłość produkcji i jakość wyrobu;
• możliwość przejścia na sterowanie ręczne;
• czas potrzebny na odtworzenie działania;
• dostępność części zamiennych, kopii programu i dokumentacji;
• zależność od konkretnego dostawcy lub starszego systemu operacyjnego.

Sprawdź, z czym komunikuje się maszyna

Sama lista urządzeń nie wystarcza. Potrzebna jest mapa przepływów: źródło, cel, protokół, port, kierunek, częstotliwość i uzasadnienie biznesowe. W przypadku zdalnego dostępu trzeba dopisać użytkownika, metodę uwierzytelnienia, zakres uprawnień oraz warunki rozpoczęcia i zakończenia sesji.

Przykładowy wpis może opisywać, że brama danych pobiera określone zmienne z PLC, przekazuje je do serwera pośredniego, a ten wysyła zagregowane informacje do systemu raportowego. Inny wpis może dotyczyć stacji serwisowej, która łączy się z HMI przez kontrolowany bastion wyłącznie w czasie zatwierdzonego okna.

W czasie przeglądu często ujawniają się połączenia, o których nie ma dokumentacji: modem LTE pozostawiony przez instalatora, router serwisowy, bezprzewodowy punkt dostępowy, usługa zdalnego pulpitu, udział plików albo konto producenta używane od lat. Każdy taki element powinien zostać potwierdzony, opisany i przypisany do właściciela. Nieznane połączenie nie jest neutralne — oznacza brak kontroli nad fragmentem architektury.

Aktywne skanowanie wymaga ostrożności. Współczesne narzędzia bezpieczeństwa są przydatne, ale starsze sterowniki, moduły komunikacyjne i urządzenia o ograniczonych zasobach mogą reagować na nietypowy ruch niestabilnością. Przed testem należy sprawdzić zalecenia producenta, uzgodnić okno, wykonać kopie konfiguracji i rozważyć pasywne rozpoznanie ruchu.

Oceń stan wsparcia i możliwość utrzymania

Urządzenie może działać poprawnie lokalnie, a jednocześnie nie nadawać się do podłączenia do internetu. Krytyczne pytania dotyczą wsparcia producenta, dostępności poprawek, dokumentacji, kompatybilności z nowoczesnym uwierzytelnianiem i możliwości odtworzenia konfiguracji.

Ryzyko rośnie, gdy system wymaga starego systemu operacyjnego, nie obsługuje szyfrowania, używa domyślnych kont albo ma nieusuwalne konto serwisowe. Nie oznacza to automatycznie, że urządzenie trzeba natychmiast wycofać. Oznacza natomiast, że trzeba je mocniej odizolować i nie udostępniać mu szerszego dostępu, niż jest absolutnie potrzebny.

Przed zmianą konfiguracji trzeba ustalić, czy aktualizacja może zostać przetestowana poza produkcją. Jeżeli nie, potrzebny jest przynajmniej plan powrotu: kopia programu PLC, eksport konfiguracji HMI, kopia ustawień sieciowych, obraz dysku komputera przemysłowego lub dostęp do sprawdzonej części zamiennej. Sama kopia pliku nie wystarczy, jeśli nikt nie wie, jak ją przywrócić.

Sygnałem ostrzegawczym jest również brak procedury po utracie łączności. Maszyna powinna zachować przewidywalne zachowanie po awarii internetu, VPN, serwera DNS, usługi chmurowej albo bramy pośredniczącej. Utrata połączenia zewnętrznego nie może automatycznie prowadzić do niebezpiecznego stanu procesu.

Analiza ryzyka OT: co może pójść nie tak po otwarciu połączenia?

Poufność nie jest jedynym priorytetem

W sieci biurowej pierwszym skojarzeniem z incydentem bywa wyciek dokumentów. W środowisku OT równie istotne, a często ważniejsze, są dostępność procesu, integralność ustawień i przewidywalne działanie urządzeń. Zmiana parametrów, zatrzymanie HMI albo przeciążenie sieci może wywołać skutki fizyczne, których nie da się naprawić samym odtworzeniem plików.

Ocena ryzyka powinna obejmować nie tylko możliwość przejęcia konta. Trzeba rozważyć, co stanie się po błędnej zmianie receptury, wyłączeniu alarmów, usunięciu programu PLC, podmianie konfiguracji napędu, utracie synchronizacji czasu lub opóźnieniu komunikatów między sterownikami.

Skutki warto opisywać w kilku wymiarach:

• bezpieczeństwo fizyczne — ryzyko dla operatorów, utrzymania ruchu i osób postronnych;
• ciągłość produkcji — zatrzymanie pojedynczego stanowiska, linii albo całego zakładu;
• jakość — produkcja poza specyfikacją, utrata partii lub nieprawidłowe parametry;
• środowisko — uwolnienie substancji, przekroczenie parametrów lub awaria instalacji pomocniczej;
• odtwarzalność — czas i zasoby potrzebne do powrotu do pracy.

Nie należy zakładać, że system bezpieczeństwa procesu „ochroni wszystko”. Mechanizmy safety mają określone granice i nie zastępują segmentacji, kontroli dostępu ani procedur. Podobnie kopia zapasowa nie chroni przed chwilowym zatrzymaniem linii, błędną recepturą ani fizyczną awarią spowodowaną nieprawidłowym sterowaniem.

Dobrym uzupełnieniem tego tematu jest także poradnik: Aktualizacje w tle – jak je kontrolować?.

Typowe scenariusze zagrożeń

Jednym ze scenariuszy jest przejście ransomware z sieci IT do segmentu produkcyjnego. Może do niego dojść przez wspólne konto administratora, udział plików, zbyt szeroką trasę między sieciami, stację inżynierską albo urządzenie, które jednocześnie obsługuje system biurowy i OT. Nie trzeba wystawiać PLC bezpośrednio do internetu, aby doszło do incydentu — wystarczy słaba kontrola na styku stref.

Inny przypadek dotyczy dostawcy. Konto serwisowe pozostaje aktywne po zakończeniu prac, hasło jest współdzielone przez wiele osób, a tunel VPN pozwala dotrzeć do całego segmentu. Jeżeli połączenie nie ma limitu czasu i nie jest rejestrowane, trudno ustalić, kto wykonał zmianę oraz czy była ona uzgodniona.

Urządzenie wystawione bezpośrednio do internetu będzie prawdopodobnie wykrywane przez automatyczne skanery. Próby logowania, rozpoznawanie usług i wykorzystanie znanych błędów nie muszą być skierowane przeciwko konkretnemu zakładowi. Wystarczy, że publiczny adres odpowiada na niepotrzebny port albo panel administracyjny używa przestarzałego mechanizmu.

Ryzyko może powstać także bez złośliwego działania. Automatyczna aktualizacja, zmiana certyfikatu, modyfikacja reguły firewall albo błędna konfiguracja usługi chmurowej może przerwać komunikację. W OT problemem jest nie tylko atak, lecz także nieprzetestowana zmiana w systemie, który powinien działać stabilnie przez długi czas.

Kryteria akceptacji ryzyka

Akceptacja ryzyka nie powinna być skrótem dla braku działań. Przed jej zatwierdzeniem trzeba sprawdzić, czy ryzyka nie da się obniżyć przez zmianę architektury, ograniczenie dostępu, wymianę urządzenia, wprowadzenie bramy pośredniej albo rezygnację z funkcji, która nie jest naprawdę potrzebna.

Decyzja powinna mieć właściciela. Powinna również wskazywać warunki, po których spełnieniu połączenie może zostać uruchomione, oraz zdarzenia powodujące jego natychmiastowe wyłączenie. Przykładem może być wykrycie nieznanego użytkownika, utrata możliwości logowania, brak aktualnych kopii konfiguracji lub zmiana dostawcy usługi.

Projekt należy odłożyć, gdy nie ma segmentacji, nie wiadomo, co jest podłączone, brak kopii programu, nikt nie odpowiada za dostęp, a producent nie potrafi opisać wymagań technicznych. W takiej sytuacji „tymczasowe” podłączenie często staje się stałym elementem infrastruktury, którego później nikt nie chce wyłączyć z obawy przed zatrzymaniem procesu.

Dobrym kryterium jest pytanie: czy zakład może bezpiecznie funkcjonować po odłączeniu internetu? Jeżeli odpowiedź brzmi „nie”, trzeba szczególnie dokładnie sprawdzić zależności od chmury, DNS, zewnętrznego serwera licencji, zdalnego uwierzytelniania i usług producenta.

Architektura dostępu: jak połączyć OT z internetem bez wystawiania maszyn?

Najbezpieczniejsza decyzja architektoniczna polega na tym, aby internet nie miał bezpośredniej trasy do sterownika, panelu operatorskiego ani stacji inżynierskiej. Dostęp zewnętrzny powinien kończyć się na kontrolowanym punkcie pośrednim, a komunikacja z siecią OT musi być ograniczona do konkretnych systemów, portów, kierunków i przedziałów czasowych.

W praktyce warto projektować połączenie warstwowo. Zamiast jednego routera z przekierowaniem portu należy rozdzielić funkcje: ochronę granicy, segmentację, pośredniczenie w wymianie danych, zdalny dostęp serwisowy, uwierzytelnianie i rejestrowanie zdarzeń. Dzięki temu awaria lub kompromitacja jednego elementu nie daje automatycznie dostępu do całej infrastruktury.

Podziel sieć na strefy i ustal dozwolone przepływy

Podstawą jest podział na odrębne strefy bezpieczeństwa. Ich dokładny układ zależy od zakładu, ale często obejmuje:

• sieć biurową IT;
• strefę pośrednią DMZ;
• sieć sterowania i nadzoru;
• odseparowane segmenty linii lub komórek produkcyjnych;
• wydzieloną stację lub serwer do obsługi dostępu serwisowego.

Reguły między strefami powinny wynikać z opisanych przepływów, a nie z zasady „zezwól na wszystko i obserwuj”. Jeżeli system raportowy potrzebuje danych z produkcji, należy dopuścić wyłącznie konkretną komunikację do wyznaczonego pośrednika. Jeżeli dostawca musi wykonać czynność na HMI, nie oznacza to, że powinien otrzymać dostęp do całej podsieci sterowników.

Warto stosować regułę domyślnej blokady. Każdy przepływ powinien mieć określone źródło, cel, protokół, port, kierunek, właściciela i uzasadnienie. Reguły tymczasowe muszą mieć datę wygaśnięcia, aby nie pozostały w firewallu po zakończeniu prac.

Wykorzystaj DMZ i bramy pośrednie

Strefa DMZ może pełnić funkcję bufora między internetem, siecią IT i OT. Umieszcza się w niej na przykład serwer pośredniczący, bramę wymiany danych, broker komunikatów, serwer aktualizacji poddawanych kontroli albo system obsługujący sesje serwisowe. Urządzenia w DMZ nie powinny być traktowane jako część zaufanej sieci produkcyjnej. Ich zadaniem jest ograniczenie kontaktu i kontrolowanie wymiany, a nie zapewnienie wygodnego skrótu między strefami.

W przypadku danych produkcyjnych lepiej sprawdza się model, w którym brama pobiera lub publikuje tylko określony zestaw wartości, zamiast udostępniać cały interfejs sterownika. Można przekazywać dane jednokierunkowo, okresowo albo po wcześniejszej walidacji. Jeżeli odbiorca zewnętrzny potrzebuje wyłącznie raportu, nie powinien otrzymywać możliwości wysyłania poleceń do urządzenia wykonawczego.

Przykładowo: system chmurowy może odbierać z DMZ zagregowane informacje o liczbie wyprodukowanych sztuk, czasie pracy i alarmach. Nie musi mieć dostępu do adresacji PLC, panelu HMI ani programu sterownika. Jeżeli wymagane jest sterowanie, należy potraktować je jako odrębny, znacznie bardziej ryzykowny przypadek i objąć dodatkowymi zatwierdzeniami.

Oddziel dostęp serwisowy od zwykłej komunikacji

Zdalny serwis powinien być realizowany przez bastion, bramę dostępową lub dedykowaną stację serwisową, a nie przez bezpośrednie przekierowanie RDP, VNC, SSH albo panelu webowego do urządzenia OT. Punkt pośredni ogranicza liczbę systemów dostępnych z zewnątrz i pozwala zastosować dodatkowe mechanizmy kontroli.

Dobrze zaprojektowany dostęp serwisowy powinien obejmować:

• imienne konto dla każdej osoby, bez współdzielonych loginów;
• uwierzytelnianie wieloskładnikowe, szczególnie dla dostępu spoza zakładu;
• zatwierdzenie konkretnego zgłoszenia przez właściciela procesu;
• ograniczenie sesji do wskazanego urządzenia lub segmentu;
• automatyczne wygaśnięcie uprawnień po określonym czasie;
• rejestrację logowania, poleceń, zmian i zakończenia sesji;
• możliwość natychmiastowego przerwania połączenia przez uprawnioną osobę.

Jeżeli producent potrzebuje jedynie podglądu, nie należy nadawać mu uprawnień administracyjnych. Jeżeli musi zmienić program, warto wymagać osobnego zatwierdzenia tej czynności, a po zakończeniu pracy sprawdzić, co zostało zmodyfikowane i czy utworzono aktualną kopię konfiguracji.

VPN uruchamiany na żądanie, nie stały tunel

Stały tunel VPN między zakładem a siecią dostawcy może być wygodny, ale zwiększa zakres zaufania i utrudnia ocenę, czy połączenie jest nadal potrzebne. Zwykle bezpieczniejszy jest tunel uruchamiany na żądanie: aktywuje go uprawniony pracownik dla określonego zgłoszenia, na ustalony czas i do konkretnego celu.

Sam fakt użycia VPN nie rozwiązuje problemu. Trzeba sprawdzić, dokąd tunel prowadzi, jakie trasy są rozgłaszane, czy możliwa jest komunikacja między niepotrzebnymi podsieciami oraz czy dostawca może poruszać się dalej niż wymagane urządzenie. VPN powinien być punktem wejścia do kontrolowanego bastionu, a nie przepustką do całej sieci produkcyjnej. ^[4]

Uważaj, gdy dostawca wymaga stałego połączenia „na wszelki wypadek”, używa jednego konta dla całego zespołu albo nie akceptuje rejestrowania sesji. Warto rozważyć rozwiązanie, w którym dostęp jest domyślnie wyłączony, a jego aktywacja wymaga dwóch niezależnych czynności: zgody właściciela procesu i uruchomienia sesji przez administratora infrastruktury.

Kontroluj kierunek ruchu i zakres komunikacji

W architekturze OT kierunek ruchu ma znaczenie równie duże jak jego treść. Ruch wychodzący z bramy do usługi zewnętrznej nie powinien automatycznie oznaczać możliwości połączenia zwrotnego do urządzenia. Tam, gdzie jest to możliwe, należy preferować komunikację jednokierunkową lub model, w którym urządzenie pośrednie inicjuje połączenie do określonego odbiorcy.

Dobrym uzupełnieniem tego tematu jest także poradnik: Gotowy harmonogram konserwacji systemu na cały rok.

Reguły firewall powinny ograniczać nie tylko adresy, lecz także porty, protokoły i czas działania. Nie należy zastępować kontroli regułą typu „cały segment OT może łączyć się z internetem”. Jeżeli urządzenie potrzebuje synchronizacji czasu, należy wskazać konkretny serwer czasu. Jeżeli pobiera aktualizacje, trzeba ustalić dozwolone źródło, sposób weryfikacji pakietu i procedurę zatwierdzenia. ^[2]

Warto również zablokować ruch boczny między segmentami, jeśli nie jest konieczny. Awaria lub przejęcie jednego komputera nie powinny umożliwiać automatycznego skanowania wszystkich sterowników, napędów i paneli operatorskich w zakładzie.

Uwierzytelnianie i monitoring muszą działać razem

Każdy dostęp zewnętrzny powinien być powiązany z konkretną tożsamością. Wspólne hasło administratora, konto producenta używane przez wiele osób i brak informacji o czasie logowania uniemożliwiają rzetelną analizę zdarzenia. Jeżeli starsze urządzenie nie obsługuje nowoczesnego logowania, uwierzytelnianie można przenieść na bastion, a samo urządzenie dodatkowo odizolować.

Monitoring powinien obejmować co najmniej:

• próby logowania i ich wynik;
• uruchomienie oraz zakończenie tunelu VPN;
• zmiany reguł zapory i tras;
• aktywację dostępu serwisowego;
• połączenia do urządzeń OT i nietypowe porty;
• zmiany konfiguracji na bastionie i bramach;
• utratę komunikacji z kluczowym urządzeniem.

Logi muszą trafiać do miejsca, do którego osoba wykonująca zmianę nie może ich swobodnie usunąć. Należy też ustalić, kto analizuje alarmy i w jakim czasie reaguje. Samo zapisywanie zdarzeń bez właściciela i procedury reakcji daje ograniczoną wartość.

Zaprojektuj szybkie odłączenie

Każde połączenie z internetem powinno mieć wyraźny mechanizm odcięcia. Może to być wyłączenie konkretnej reguły firewall, dezaktywacja tunelu, odłączenie bramy, przełączenie routera w tryb bez dostępu zewnętrznego albo fizyczne rozpięcie łącza. Decyzja o odłączeniu nie powinna wymagać szukania nieudokumentowanego kabla ani oczekiwania na administratora, który jest dostępny tylko w godzinach pracy.

Mechanizm odcięcia trzeba wcześniej przetestować. Należy potwierdzić, że połączenie zewnętrzne rzeczywiście zanika, a proces lokalny pozostaje w stanie bezpiecznym. Test powinien również sprawdzić powrót do pracy: kto może ponownie uruchomić komunikację, jakie warunki muszą być spełnione i czy po ponownym połączeniu nie zostaną automatycznie przywrócone stare sesje.

Końcowa rekomendacja jest prosta: jeżeli połączenie jest potrzebne, podłączaj najpierw usługę lub bramę pośrednią, a nie samą maszynę. Zastosuj segmentację, DMZ, dostęp przez bastion, VPN uruchamiany na żądanie, silne uwierzytelnianie, monitoring i sprawdzony mechanizm odcięcia. Jeżeli nie da się spełnić tych warunków, bezpieczniejszą decyzją jest pozostawienie urządzenia bez bezpośredniego dostępu do internetu i poszukanie rozwiązania, które ograniczy zakres wymaganej łączności.

Checklista wdrożeniowa przed uruchomieniem połączenia

Przed aktywacją łącza warto przejść przez krótką checklistę z osobami odpowiedzialnymi za automatykę, IT, utrzymanie ruchu i bezpieczeństwo. Jej celem nie jest potwierdzenie, że „internet działa”, lecz sprawdzenie, czy działa wyłącznie to, co zostało zaplanowane.

• Cel połączenia: opisano, po co jest potrzebna łączność i jaki jest minimalny wymagany zakres funkcji.
• Zakres urządzeń: wskazano konkretną maszynę, bramę, serwer lub aplikację, która ma komunikować się poza zakładem.
• Przepływy: zapisano adresy źródłowe i docelowe, porty, protokoły, kierunek oraz częstotliwość komunikacji.
• Odpowiedzialność: wyznaczono właściciela procesu, właściciela systemu i osobę zatwierdzającą zmiany.
• Uprawnienia: ustalono, kto może uruchomić dostęp, kto może go zakończyć i kto analizuje zdarzenia.
• Odporność: sprawdzono, jak maszyna zachowa się po utracie internetu, DNS, usługi chmurowej lub serwera pośredniego.
• Aktualizacja: określono, skąd będą pobierane pakiety, jak zostaną zweryfikowane i kto zatwierdzi ich instalację.
• Dokumentacja: zapisano konfigurację początkową, zależności, reguły dostępu i sposób powrotu do poprzedniego stanu.
• Test odłączenia: wskazano konkretną czynność, która przerwie komunikację, oraz osobę uprawnioną do jej wykonania.

Jeżeli któregokolwiek punktu nie da się uzupełnić, nie należy traktować tego jako formalnego braku do nadrobienia po uruchomieniu. Nieznany właściciel, nieudokumentowana zależność albo nieprzetestowane zachowanie po utracie łącza mogą bezpośrednio wpłynąć na bezpieczeństwo procesu.

Testy przed dopuszczeniem maszyny do pracy

Odbiór architektury powinien odbywać się w kontrolowanym oknie serwisowym, najlepiej na urządzeniu testowym lub podczas postoju produkcji. Testy należy wykonywać według przygotowanego scenariusza, a wyniki zapisywać razem z datą, osobą wykonującą próbę i konfiguracją obowiązującą w chwili testu.

Sprawdź, co jest osiągalne z zewnątrz

W pierwszej kolejności należy potwierdzić, że z internetu nie da się bezpośrednio odnaleźć ani otworzyć interfejsów maszyny. Test powinien obejmować publiczne adresy, nazwy DNS, używane porty oraz przypadki błędnego logowania. Nie wystarczy sprawdzić jednego komputera w sieci zakładowej, ponieważ dostęp może być możliwy inną trasą, przez zapomnianą regułę albo dodatkowy interfejs routera.

Wynik powinien jednoznacznie wskazywać:

• które adresy są widoczne z internetu;
• które porty odpowiadają i dlaczego jest to wymagane;
• czy interfejs administracyjny nie jest dostępny z niewłaściwej strefy;
• czy próby skanowania i logowania są rejestrowane;
• czy dostęp przez dozwolony punkt pośredni działa tylko w określonym zakresie.

Zweryfikuj komunikację dozwoloną i zablokowaną

Dla każdego zatwierdzonego przepływu należy wykonać test pozytywny, czyli potwierdzić, że wymagana komunikacja działa. Następnie trzeba wykonać test negatywny: sprawdzić, czy podobny ruch z niewłaściwego adresu, do niewłaściwego portu albo w przeciwnym kierunku zostaje odrzucony.

Przykładowo, jeśli brama ma wysyłać dane produkcyjne do usługi zewnętrznej, test powinien potwierdzić zarówno dostarczenie właściwych wartości, jak i brak możliwości nawiązania przez tę usługę niezatwierdzonej sesji do sterownika. Warto również sprawdzić, czy zmiana adresu docelowego lub próba użycia innego protokołu nie omija przyjętych ograniczeń.

Przetestuj utratę zależności zewnętrznych

Maszyna nie powinna przechodzić w niebezpieczny stan tylko dlatego, że usługa zewnętrzna chwilowo nie odpowiada. Należy kontrolowanie przerwać kolejne zależności i obserwować zachowanie procesu:

• odłączyć dostęp do internetu;
• zablokować rozwiązywanie nazw DNS;
• zatrzymać komunikację z brokerem lub usługą chmurową;
• opóźnić odpowiedzi serwera;
• przerwać działanie bramy pośredniej;
• zakończyć aktywną sesję serwisową.

Podczas testu trzeba sprawdzić alarmy, lokalne sterowanie, zapis danych, zachowanie kolejki komunikatów i możliwość bezpiecznego wznowienia pracy. Szczególnie istotne jest ustalenie, czy brak odpowiedzi powoduje zatrzymanie kontrolowane, utrzymanie ostatniej bezpiecznej wartości czy nieprzewidywalną próbę ponawiania połączeń.

Odbiór dostępu serwisowego i zmian konfiguracyjnych

Dostęp serwisowy należy odebrać osobno od zwykłej wymiany danych. Osoba testująca powinna wykonać pełny cykl: zgłoszenie potrzeby, zatwierdzenie, uruchomienie sesji, próbę dostępu do dozwolonego zasobu, próbę wyjścia poza zakres oraz zakończenie uprawnień.

W dokumentacji odbiorowej warto potwierdzić:

• czy każde logowanie wskazuje konkretną osobę;
• czy wymagane uwierzytelnianie działa także po ponownym połączeniu;
• czy sesja wygasa automatycznie po ustalonym czasie;
• czy użytkownik nie może przejść do innych segmentów;
• czy rejestrowane są rozpoczęcie, przebieg i zakończenie sesji;
• czy odebranie uprawnienia rzeczywiście kończy dostęp;
• czy zmiana konfiguracji pozostawia ślad możliwy do odtworzenia.

Jeżeli podczas prac serwisowych modyfikowany jest program sterownika, receptura albo konfiguracja napędu, odbiór powinien obejmować porównanie stanu przed i po zmianie. Należy także sprawdzić, czy kopia konfiguracji jest możliwa do odtworzenia i czy nie została nadpisana bez zachowania poprzedniej wersji.

Jak udokumentować decyzję i późniejsze przeglądy?

Dokumentacja nie musi być obszerna, ale powinna pozwalać innej osobie odtworzyć powód podłączenia, zakres komunikacji i sposób wycofania rozwiązania. Minimalny pakiet powinien zawierać diagram połączeń, tabelę przepływów, listę wyjątków, wynik testów, właścicieli oraz datę kolejnego przeglądu.

Przegląd trzeba zaplanować nie tylko po incydencie. Powinien odbywać się również po zmianie dostawcy, wymianie sterownika, aktualizacji firmware’u, zmianie adresacji, rozbudowie linii lub wprowadzeniu nowej usługi chmurowej. Po każdym takim zdarzeniu należy sprawdzić, czy pierwotne uzasadnienie dostępu nadal jest aktualne.

Dobrym kryterium jakości jest możliwość udzielenia w krótkim czasie odpowiedzi na cztery pytania: co komunikuje się z internetem, dlaczego to robi, kto może zmienić ten stan oraz jak odłączyć komunikację bez zgadywania. Jeśli odpowiedź wymaga przeszukiwania nieaktualnych konfiguracji lub kontaktu z nieobecną osobą, architektura nie jest jeszcze gotowa do bezpiecznej eksploatacji.

Najczęściej zadawane pytania (FAQ)

Czy każda maszyna przemysłowa musi mieć dostęp do internetu?

Nie. Dostęp powinien wynikać z jasno określonej potrzeby operacyjnej lub technicznej. Jeżeli wystarczy przesyłanie danych, bezpieczniejsza może być dedykowana brama IIoT zamiast bezpośredniego połączenia maszyny z internetem.

Czy bezpośrednie wystawienie PLC do internetu jest bezpieczne?

Bezpośredni dostęp do PLC należy traktować jako rozwiązanie zasadniczo niewłaściwe. Bezpieczniejszą alternatywą jest dostęp przez bastion lub stację serwisową w kontrolowanej strefie, z ograniczeniem użytkowników, czasu i zakresu uprawnień.

Jakie informacje trzeba zebrać przed podłączeniem urządzenia OT?

Warto zinwentaryzować urządzenie, jego model, wersję oprogramowania, adresację, właściciela, funkcję w procesie, zależności oraz sposób administracji. Należy także opisać przepływy danych: źródła, cele, protokoły, porty i kierunki ruchu.

Czy zdalny serwis powinien działać stale?

Nie zawsze. Jeżeli serwis jest potrzebny sporadycznie, lepszy może być dostęp uruchamiany na żądanie i tylko na czas zatwierdzonego okna. Powinien wykorzystywać konta imienne, MFA, rejestr sesji oraz automatyczne wyłączenie po zakończeniu prac.

Co zrobić, gdy urządzenie ma domyślne hasło albo nie jest już wspierane?

Nie należy podłączać go bez dodatkowych działań. Trzeba usunąć krytyczne słabości lub zaplanować wymianę urządzenia. Do czasu modernizacji można zastosować izolację i lokalny, kontrolowany dostęp.

Kluczowe Wnioski

• Podłączenie maszyny OT do internetu powinno wynikać z konkretnej potrzeby, a nie z samej dostępności interfejsu sieciowego lub usługi chmurowej.
• Przed konfiguracją połączenia trzeba zinwentaryzować urządzenia, zależności, właścicieli i przepływy komunikacji.
• Bezpośrednie wystawianie PLC, HMI, SCADA lub panelu webowego do internetu zwiększa powierzchnię ataku i powinno być traktowane jako rozwiązanie alarmowe.
• Bezpieczniejszą architekturę zapewniają między innymi brama IIoT, serwer pośredni, strefa DMZ, bastion oraz ograniczenie ruchu do określonych systemów, protokołów i adresów.
• Zdalny serwis warto uruchamiać na żądanie, z kontami imiennymi, MFA, rejestrowaniem sesji i limitem czasu.
• Urządzenia niewspierane, korzystające z domyślnych kont lub pozbawione możliwości odtworzenia konfiguracji nie powinny być podłączane bez wcześniejszego ograniczenia ryzyka.
• Przed wdrożeniem trzeba zapewnić kopie konfiguracji, monitoring oraz procedurę szybkiego odłączenia połączenia i powrotu do bezpiecznego trybu lokalnego.

Źródła

• [1] NIST – Guide to Operational Technology (OT) Security — NIST SP 800-82 Rev. 3 ↑
• [2] CISA – Internet Exposure Reduction Guidance ↑
• [3] NIST – Guide to Industrial Control Systems (ICS) Security — NIST SP 800-82 Rev. 2 ↑
• [4] NIST – CSWP 28: Security Segmentation in a Small Manufacturing Environment ↑