Zarządzany przełącznik Ethernet w sieci SCADA lub DCS to coś więcej niż zwielokrotniacz portów. Kontroluje ścieżki ruchu, udostępnia funkcje diagnostyczne i może zarówno ograniczyć, jak i zwiększyć skutki błędu konfiguracji.

Celem inżynieryjnym nie jest maksymalne wykorzystanie funkcji. Chodzi o przewidywalną komunikację, ograniczony dostęp administracyjny oraz wystarczającą ilość danych do diagnozowania awarii bez zakłócania procesu.

Warstwowa architektura oddziela sterowanie polowe, systemy nadzorcze, operacje zakładowe i wymianę danych z systemami przedsiębiorstwa.

Zacznij od ruchu sieciowego i konsekwencji

Przed zmianą ustawień przełącznika zinwentaryzuj każdy sterownik, panel HMI, system archiwizacji danych, stację inżynierską, bramę oraz ścieżkę zdalnego dostępu. Zapisz wymagane protokoły, urządzenia równorzędne, częstotliwości aktualizacji, sposób obsługi multicastu oraz oczekiwania dotyczące przywracania działania.

Ta inwentaryzacja przekształca segmentację w decyzję inżynieryjną. Sama sieć VLAN nie jest granicą bezpieczeństwa, dopóki routing i reguły zapory nie egzekwują zamierzonych ścieżek komunikacji.

NIST SP 800-82 Rev. 3 opisuje bezpieczeństwo OT w kontekście wydajności, niezawodności i bezpieczeństwa. Wytyczne CISA również podkreślają segmentację oraz kontrolowaną wymianę danych między systemami krytycznymi a usługami przedsiębiorstwa.

Oddziel zarządzanie od ruchu procesowego

Umieść interfejsy zarządzania przełącznikami w wydzielonej sieci zarządzania. Zezwalaj na dostęp wyłącznie z autoryzowanych hostów administracyjnych za pośrednictwem zdefiniowanych zapór lub list kontroli dostępu.

Wyłącz nieużywane usługi zarządzania. Jeśli przełącznik je obsługuje, preferuj SSH i HTTPS. Unikaj Telnetu oraz nieszyfrowanego HTTP, ponieważ dane uwierzytelniające i sesje mogą zostać ujawnione.

Zmień domyślne dane uwierzytelniające, używaj imiennych kont i stosuj uprawnienia oparte na rolach. Uwierzytelnianie centralne może poprawić rozliczalność, ale zakład potrzebuje również udokumentowanej metody odzyskiwania dostępu na wypadek niedostępności usługi uwierzytelniania.

Chroń dostęp lokalny

Dostęp przez konsolę pozostaje cenny podczas uruchamiania i awarii sieci. Dostęp fizyczny powinien być zatem kontrolowany, a lokalnych danych uwierzytelniających nie należy udostępniać bez uzasadnienia.

Zapisana konfiguracja nie może zawierać haseł demonstracyjnych ani domyślnych danych dostawcy. Dane uwierzytelniające do odzyskiwania dostępu przechowuj zgodnie z zatwierdzonym w zakładzie procesem dostępu.

Stosuj segmentację dopasowaną do operacji

Grupuj urządzenia według funkcji, konsekwencji i potrzeb komunikacyjnych. Przykłady obejmują cele sterowników, systemy zabezpieczeń, serwery nadzorcze, urządzenia związane z bezpieczeństwem oraz dostęp serwisowy.

Nie twórz płaskiej sieci VLAN dla całego zakładu tylko dlatego, że wszystkie urządzenia korzystają z przemysłowego Ethernetu. W takiej sytuacji zaatakowana stacja robocza lub burza rozgłoszeniowa może dotrzeć do urządzeń, które nigdy nie potrzebowały bezpośredniej komunikacji.

Sieć VLAN zarządzania powinna być dostępna wyłącznie za pośrednictwem zatwierdzonych ścieżek administracyjnych.

Jeśli używane są protokoły multicast, sprawdź funkcję IGMP snooping, rozmieszczenie urządzeń querier oraz działanie redundancji. Nieprawidłowa architektura multicastu może przeciążyć porty lub przerwać działanie wejść/wyjść, nawet gdy zwykłe testy unicastu zakończą się pomyślnie.

Odpowiednie interfejsy i urządzenia infrastruktury sieciowej można znaleźć w kolekcji Komunikacja i sieci. Platformy sterowników są zgrupowane w sekcji systemy PLC i PAC.

Projektuj redundancję jako system

Łącza redundantne wymagają udokumentowanego protokołu i sprawdzonego czasu konwergencji. Dodanie równoległych przewodów bez ochrony przed pętlami może wywołać burzę rozgłoszeniową zamiast zapewnić odporność.

Sprawdź, czy sieć korzysta z Rapid Spanning Tree, firmowego protokołu pierścieniowego, Media Redundancy Protocol czy innej metody. Potwierdź zgodność między wszystkimi uczestniczącymi przełącznikami.

Przetestuj awarię przewodu, utratę zasilania przełącznika, przywracanie zablokowanego portu oraz powrót do normalnego działania. Zapisuj utratę pakietów i zachowanie sterowników, a nie tylko deklarowany przez przełącznik czas konwergencji.

Rejestrowanie zdarzeń i synchronizacja czasu wspierają diagnostykę

Jeśli jest to praktyczne, wysyłaj zdarzenia z przełączników do chronionego systemu rejestrowania. Przydatne zdarzenia obejmują zmiany stanu łączy, nieudane uwierzytelnianie, zmiany konfiguracji, zmiany topologii oraz alarmy zasilania.

Spójny czas ma kluczowe znaczenie. Bez zsynchronizowanych zegarów operator nie może wiarygodnie powiązać zmiany stanu przełącznika z usterkami PLC, alarmami HMI lub zdarzeniami zapory.

SNMP należy konfigurować świadomie. Ogranicz stacje zarządzające i korzystaj z uwierzytelnianych, szyfrowanych wersji, jeśli są obsługiwane. Unikaj udostępniania szerokiego dostępu do zapisu.

Uruchamiaj zmiany bez tworzenia ukrytego ryzyka

Przed rozpoczęciem prac wykonaj kopię zapasową działającej konfiguracji. Zapisz model przełącznika, wersję oprogramowania układowego, aktywną konfigurację, podłączone porty oraz metodę wycofania zmian.

Wprowadzaj zmiany w zatwierdzonym oknie serwisowym. Po każdym większym kroku sprawdź komunikację procesową, dostarczanie alarmów, aktualizacje systemu archiwizacji danych, redundancję, dostęp zdalny oraz synchronizację czasu.

Aktualizacje oprogramowania układowego wymagają takiej samej dyscypliny jak zmiany w sterownikach. Przeanalizuj komunikaty dostawcy, przetestuj docelową wersję w laboratorium i potwierdź dostępność obrazu odzyskiwania.

Opinia autora: zarządzane przełączniki tworzą wartość, gdy ich konfiguracja jest zrozumiała i możliwa do odtworzenia. Złożona architektura bez jasno określonej odpowiedzialności, kopii zapasowych i sprawdzonego zachowania podczas awarii jest trudniejsza w obsłudze niż prostsza, udokumentowana sieć.