Dyrektywa NIS2 i regulacja CRA a cyberbezpieczeństwo systemów automatyki. Astraada One i CODESYS: dobre praktyki dla inżyniera automatyka

Dyrektywa NIS2 jednoznacznie wskazuje, że cyberbezpieczeństwo infrastruktury przemysłowej przestaje być opcją – staje się obowiązkiem organizacyjnym i technicznym. Dotyczy to w szczególności systemów automatyki przemysłowej (OT), w których sterowniki PLC, panele HMI i oprogramowanie inżynierskie są integralną częścią procesów krytycznych. Sterowniki Astraada One, oparte o środowisko CODESYS, zostały zaprojektowane zgodnie z zasadą security by design i defense in depth, co oznacza wielowarstwowe podejście do ochrony systemu – od sprzętu, przez system operacyjny, aż po aplikację użytkownika.

Zgodnie z normą IEC 62443 sterowniki PLC są zdefiniowane na poziomie podstawowej ochrony przed przypadkowym lub nieumyślnym naruszeniem bezpieczeństwa SL 1.

W tym artykule zostanie przedstawiony zestaw rekomendacji aplikacyjnych, które – prawidłowo wdrożone – znacząco ułatwiają spełnienie wymagań NIS2 oraz podnoszą realny poziom bezpieczeństwa instalacji, z perspektywy użytkownika sterowników Astraada One.

Do artykułu dołączony został dokument Security Guideline, który szczegółowo opisuje zagadnienia związane z cyberbezpieczeństwem urządzeń opartych na Astraada One. Dokument ten obejmuje zarówno podstawowe koncepcje bezpieczeństwa, takie jak wcześniej wymienione model CIA i strategia Defense in Depth, jak i bardzo praktyczne aspekty konfiguracji systemów – w tym zabezpieczanie portów komunikacyjnych, zarządzanie dostępem zdalnym, aktualizacje oprogramowania, wykorzystanie narzędzi serwisowych oraz dobre praktyki w zakresie tworzenia i utrzymania aplikacji sterujących.

Dokument Astraada One Security Guideline w formacie PDF

Regulacja CRA – kompleksowe wymagania dotyczące cyberbezpieczeństwa produktów z funkcjami cyfrowymi

Cyber Resilience Act (CRA) jest rozporządzeniem Unii Europejskiej, które porządkuje temat cyberbezpieczeństwa urządzeń. Jego głównym celem jest wprowadzenie jednego, spójnego poziomu ochrony dla wszystkich produktów cyfrowych dostępnych na rynku UE.

W praktyce oznacza to, że każdy produkt wyposażony w oprogramowanie i komunikację sieciową – od sterowników PLC przez systemy embedded aż po aplikacje chmurowe – musi być projektowany i utrzymywany z myślą o bezpieczeństwie. CRA obejmuje więc zdecydowaną większość nowoczesnych rozwiązań automatyki i Przemysłu 4.0.

Najważniejsza zmiana polega na tym, że cyberbezpieczeństwo przestaje być dodatkiem, a staje się wymaganiem „od początku do końca”. Producent musi uwzględnić je już na etapie projektowania (tzw. security by design), a następnie dbać o nie przez cały cykl życia produktu. Oznacza to konieczność analizy ryzyka, eliminowania podatności, stosowania bezpiecznych konfiguracji oraz dostarczania aktualizacji – także długo po wdrożeniu u klienta.

CRA wprowadza również konkretne obowiązki operacyjne. Firmy muszą mieć proces zarządzania podatnościami, a w przypadku wykrycia poważnej, aktywnie wykorzystywanej luki – zgłosić ją do ENISA w ciągu 24 godzin. Dodatkowo spełnienie wymagań będzie powiązane z oznaczeniem CE, co oznacza, że bez zgodności z CRA produkt może nie zostać dopuszczony do rynku.

Z perspektywy automatyka oznacza to jedną kluczową zmianę: projektowanie systemów sterowania będzie coraz bardziej łączyć świat OT i IT. Oprócz funkcjonalności i bezpieczeństwa maszyn trzeba będzie zadbać o odporność na cyberzagrożenia, dokumentację procesów i długoterminowe wsparcie systemów.

Kiedy CRA wchodzi w życie?

Przyjęcie przez Parlament Europejski: marzec 2024

Publikacja w Dzienniku Urzędowym UE: 2024

Okres przejściowy: 36 miesięcy

Obowiązkowe stosowanie: od grudnia 2027 roku

Model CIA i Defense in Depth w automatyce przemysłowej – fundamenty cyberbezpieczeństwa

Współczesne systemy automatyki przemysłowej przestały być izolowanymi wyspami. Integracja z systemami IT, chmurą oraz zdalnym dostępem sprawia, że klasyczne podejście „zamkniętej sieci” już nie wystarcza. W tym kontekście szczególnego znaczenia nabierają dwa fundamentalne podejścia do bezpieczeństwa: model CIA oraz strategia Defense in Depth. To one stanowią podstawę projektowania bezpiecznych systemów OT.

Model CIA – trzy filary bezpieczeństwa

Model CIA (Confidentiality, Integrity, Availability) jest jedną z najbardziej podstawowych koncepcji bezpieczeństwa informacji. Określa on trzy główne cele, które powinny być realizowane w każdym systemie: poufność, integralność oraz dostępność. Choć pochodzenie tej koncepcji wywodzi się z IT, jej zastosowanie w automatyce przemysłowej jest nie tylko możliwe, ale wręcz konieczne.

Poufność (Confidentiality)

Poufność oznacza, że dostęp do danych mają wyłącznie osoby i systemy do tego uprawnione. Oznacza to ochronę takich informacji, jak receptury produkcyjne, parametry procesów technologicznych czy konfiguracje sterowników. Jeśli poufność zostanie naruszona, może to prowadzić nie tylko do utraty przewagi konkurencyjnej, ale również do poważnych zagrożeń operacyjnych. Przykładowo, osoba nieuprawniona, mając dostęp do ustawień technologicznych, może uzyskać wiedzę pozwalającą na manipulację procesem produkcyjnym. Zapewnienie poufności sprowadza się do stosowania mechanizmów uwierzytelniania użytkowników (login + hasło), kontroli dostępu, segmentacji sieci oddzielnie OT od IT oraz szyfrowania komunikacji jak np. https czy VPN.

Integralność (Integrity)

Integralność odnosi się do pewności, że dane i systemy nie zostały zmodyfikowane w sposób nieautoryzowany. W automatyce ma to kluczowe znaczenie, ponieważ każda zmiana może wpływać bezpośrednio na proces produkcyjny. Aspekt ten jest szczególnie ważny, ponieważ nawet niewielka zmiana w logice sterowania może mieć poważne konsekwencje dla procesu, maszyn, a nawet bezpieczeństwa ludzi. Naruszenie integralności może objawiać się poprzez nieautoryzowaną zmianę programu PLC, modyfikację parametrów pracy urządzenia lub ingerencję w dane pomiarowe. W praktyce ochrona integralności polega na stosowaniu kontroli wersji oprogramowania, podpisów cyfrowych, zarządzania użytkownikami (np. w postaci braku kont anonimowych) oraz szczegółowego logowania zmian. Kluczowe jest również ograniczenie dostępu do narzędzi inżynierskich takich jak środowiska programistyczne PLC (np. oprogramowanie CODESYS).

Dostępność (Availability)

Dostępność oznacza, że system i dane są dostępne wtedy, gdy są potrzebne. W systemach przemysłowych to często najważniejszy aspekt – przestój oznacza realne straty finansowe. W przypadku zakładów produkcyjnych brak dostępności bardzo szybko przekłada się na realne straty finansowe wynikające z przestojów. Ataki typu ransomware, awarie systemów czy błędy konfiguracji mogą skutecznie zablokować działanie instalacji przemysłowej. Dlatego zapewnienie dostępności wymaga stosowania redundancji, monitoringu systemów, regularnych aktualizacji oraz mechanizmów tworzenia kopii zapasowych.

Warto podkreślić, że trzy filary modelu CIA pozostają ze sobą w pewnym napięciu i wymagają kompromisu. Zbyt restrykcyjne podejście do bezpieczeństwa może utrudnić dostęp serwisowy i spowolnić pracę, natomiast nadmierna dostępność bez odpowiednich zabezpieczeń prowadzi do zwiększonego ryzyka ataku. Zadaniem inżyniera automatyka jest znalezienie równowagi pomiędzy tymi aspektami.

Defense in Depth – podejście warstwowe

Podczas gdy model CIA definiuje, co należy chronić, strategia Defense in Depth odpowiada na pytanie, jak to zrobić skutecznie. Podejście to zakłada, że pojedyncze zabezpieczenie nigdy nie jest wystarczające. Zamiast tego buduje się wielowarstwowy system ochrony, w którym każda warstwa pełni określoną funkcję i stanowi dodatkową barierę dla potencjalnego atakującego.

Pierwszą i najbardziej podstawową warstwą jest warstwa fizyczna, która bywa niedoceniana, mimo że stanowi jedno z najważniejszych zabezpieczeń. Oznacza to przede wszystkim właściwe zabezpieczenie szafy sterowniczej. Dostęp do sterownika, portów USB czy resetu nie powinien być możliwy dla przypadkowych osób. Często spotykana jest sytuacja, gdzie gniazdo USB jest dostępne z zewnątrz szafy lub łatwy jest dostęp do panelu operatorskiego. Tymczasem z poziomu USB możliwe jest wgranie konfiguracji, aktualizacji czy nawet zmiana aplikacji PLC. Dlatego fizyczne zamknięcie szafy, stosowanie zamków oraz kontrola dostępu do pomieszczeń technicznych to absolutna podstawa. Istotne jest również ograniczenie możliwości podłączenia laptopa serwisowego bez kontroli – fizyczne bezpieczeństwo to pierwszy filtr, który może zatrzymywać najprostsze ataki.

Kolejną warstwą jest warstwa sieciowa, która w nowoczesnych systemach automatyki odgrywa kluczową rolę. Sterowniki Astraada One mogą komunikować się poprzez Ethernet, co automatycznie czyni tę warstwę jednym z głównych wektorów ataku. Istotnym aspektem jest konieczność segmentacji sieci i wyraźnego oddzielenia środowiska OT od IT. Sterownik nie powinien znajdować się w tej samej podsieci, co komputery biurowe. Wdrożenie VLAN-ów, firewalli przemysłowych czy nawet prostych reguł filtrujących ruch sieciowy znacząco ogranicza ryzyko. W kontekście CODESYS szczególnie istotne jest ograniczenie dostępu do portów programistycznych – jeżeli port komunikacyjny środowiska inżynierskiego jest otwarty w całej sieci, każdy użytkownik mający dostęp do tej sieci może potencjalnie połączyć się ze sterownikiem. Dlatego dobrym podejściem jest dopuszczanie komunikacji tylko z wybranych adresów IP lub wyłącznie przez VPN.

Następna warstwa to warstwa systemowa, która obejmuje konfigurację samego urządzenia. Dotyczy to świadomego zarządzania usługami systemowymi – wyłączanie FTP, SSH czy VNC, jeśli nie są potrzebne, oraz odpowiednie zabezpieczenie ich, jeśli muszą pozostać aktywne. Domyślnie wiele z tych usług jest dostępnych, co wynika z wygody użytkownika, ale w środowisku produkcyjnym powinno być traktowane jako potencjalne ryzyko. Z punktu widzenia inżyniera ważne jest, aby traktować sterownik nie tylko jako urządzenie automatyki, ale jako pełnoprawny system IT z systemem operacyjnym. To oznacza konieczność aktualizacji, kontroli konfiguracji oraz świadomego zarządzania usługami. Często spotykanym błędem jest pozostawienie aktywnego SSH czy FTP „bo może się kiedyś przydać”, co znacząco zwiększa powierzchnię ataku.

Warstwa aplikacyjna jest miejscem, w którym szczególnie widoczna staje się rola CODESYS. To tutaj chroniona jest logika sterowania, czyli serce całego systemu. W tym środowisku programistycznym niezwykle istotne jest włączenie mechanizmów zarządzania użytkownikami i wymuszenie logowania przy próbie połączenia ze sterownikiem. Dzięki temu każda próba dostępu do aplikacji PLC jest kontrolowana i możliwa do prześledzenia. W praktyce oznacza to odejście od pracy „na otwartym sterowniku”, gdzie każdy może się podłączyć i wgrać zmiany. Kolejnym istotnym elementem tej warstwy jest kontrola wersji aplikacji oraz ograniczenie możliwości wgrywania programu tylko do autoryzowanych użytkowników. W przypadku Astraada One i CODESYS warto również zadbać o odpowiednią strukturę projektu i jasno zdefiniowane uprawnienia, tak aby operator nie miał takich samych możliwości jak inżynier utrzymania ruchu.

Bezpośrednio powiązana z tym jest warstwa użytkownika, która bardzo często stanowi najsłabsze ogniwo systemu. Nawet najlepiej zabezpieczona infrastruktura nie będzie bezpieczna, jeśli użytkownicy posługują się prostymi hasłami lub współdzielą konta. W systemach wykorzystujących Astraada One oraz CODESYS kluczowe jest wprowadzenie zasad zarządzania użytkownikami – przypisanie ról, wymuszanie zmiany haseł oraz eliminacja kont współdzielonych. Oznacza to, że każdy użytkownik powinien mieć swoje indywidualne konto, a jego uprawnienia powinny być ograniczone do niezbędnego minimum. Takie podejście nie tylko zwiększa bezpieczeństwo, ale również pozwala na pełną identyfikowalność działań w systemie.

Ostatnią, ale niezwykle ważną warstwą jest monitoring i rejestracja zdarzeń. W kontekście Defense in Depth nie chodzi tylko o zapobieganie atakom, ale również o ich wykrywanie i reagowanie. Sterowniki Astraada One oparte o CODESYS oferują możliwość logowania zdarzeń takich, jak próby logowania, zmiany konfiguracji czy błędy systemowe. Zazwyczaj funkcja ta jest pomijana lub ograniczona do minimum. Tymczasem regularna analiza logów może pozwolić na wykrycie nieautoryzowanych prób dostępu, zanim doprowadzą one do poważniejszych incydentów. W bardziej zaawansowanych systemach logi mogą być dodatkowo przesyłane do centralnych systemów monitoringu, co umożliwia ich korelację i analizę na poziomie całego zakładu.

Defense in Depth powinniśmy rozumieć jako budowanie systemu, w którym każda z tych warstw działa niezależnie, ale jednocześnie wspiera pozostałe. Jeśli ktoś uzyska fizyczny dostęp do urządzenia, nadal napotka zabezpieczenia sieciowe. Jeśli ominie zabezpieczenia sieciowe, będzie musiał zmierzyć się z kontrolą dostępu. A nawet jeśli uda mu się zalogować, jego działania będą ograniczone uprawnieniami i zapisane w logach.

Każdy port to potencjalne zagrożenie – jak bezpiecznie zarządzać interfejsami komunikacyjnymi ?

W załączonym dokumencie Security Guideline można odczytać m.in. że porty komunikacyjne są bardzo istotnym ostrzeżeniem dla każdego inżyniera automatyki: każdy interfejs, niezależnie od tego, czy jest używany w danej aplikacji czy pozostaje nieaktywny, stanowi potencjalne miejsce ataku i powinien być traktowany jako element wymagający świadomego zarządzania bezpieczeństwem. W praktyce oznacza to konieczność przyjęcia podejścia, w którym wszystkie porty i interfejsy są analizowane, ograniczane i zabezpieczane już na etapie projektowania systemu, a nie dopiero po jego uruchomieniu.

Szczególne znaczenie w tym kontekście ma interfejs Ethernet, który pełni rolę głównego kanału komunikacji w nowoczesnych sterownikach. To właśnie przez Ethernet realizowany jest dostęp do interfejsu webowego, konfiguracji systemu, środowiska programistycznego takiego jak CODESYS, a także usług takich jak SSH czy FTP. Z tego powodu Ethernet staje się jednym z najczęściej wykorzystywanych wektorów ataku. Nie wystarczy jedynie uruchomić komunikacji sieciowej – konieczne jest jej świadome ograniczenie. Sieć sterowników powinna być odseparowana od sieci firmowej przy użyciu firewalla, a dostęp do niej powinien być możliwy wyłącznie z kontrolowanych punktów. W praktyce oznacza to tworzenie wydzielonych podsieci lub VLAN-ów oraz stosowanie zasad filtrowania ruchu. Dodatkowo istotne jest monitorowanie sieci w poszukiwaniu nieznanych urządzeń oraz ograniczenie fizycznego dostępu do punktów sieciowych, na przykład poprzez zamknięcie ich w szafie sterowniczej. Kluczowym elementem jest również stosowanie szyfrowania komunikacji wszędzie tam, gdzie jest to możliwe, co znacząco podnosi poziom ochrony przed manipulacją danymi.

W przypadku interfejsów takich jak EtherCAT, dokument podkreśla, że choć są one zazwyczaj wykorzystywane w zamkniętych systemach sterowania, to nie oznacza to, że są one bezpieczne same z siebie. EtherCAT, podobnie jak wiele protokołów przemysłowych czasu rzeczywistego, nie został zaprojektowany z myślą o cyberbezpieczeństwie. W związku z tym jedyną skuteczną metodą ochrony pozostaje ograniczenie dostępu do całej sieci oraz zabezpieczenie fizyczne infrastruktury. W praktyce oznacza to, że sieć EtherCAT powinna być dostępna wyłącznie w strefie kontrolowanej, a wszelkie elementy infrastruktury, takie jak przewody czy wyspy I/O, powinny być chronione przed nieautoryzowanym dostępem.

Podobna filozofia dotyczy interfejsów szeregowych, takich jak RS232 czy RS485, które mimo długiej historii użytkowania nadal są szeroko stosowane w wielu instalacjach. Ich problem polega na tym, że praktycznie nie posiadają mechanizmów bezpieczeństwa, co oznacza, że każdy, kto uzyska fizyczny dostęp do magistrali, może potencjalnie komunikować się z urządzeniem. Dlatego dokument zaleca maksymalne ograniczenie dostępności tych interfejsów oraz ich wyłączanie, jeśli nie są potrzebne. Jeśli komunikacja musi być utrzymana, warto rozważyć implementację dodatkowych mechanizmów ochrony na poziomie aplikacji, takich jak autoryzacja lub szyfrowanie danych.

Analogiczne zagrożenia dotyczą magistrali CAN, która również nie posiada natywnych mechanizmów zabezpieczających. W tym przypadku szczególnie niebezpieczna jest możliwość dołączenia nieautoryzowanego urządzenia do sieci i generowania ramek danych, które mogą wpływać na działanie całego systemu. Dlatego tak istotne jest fizyczne zabezpieczenie dostępu do magistrali oraz ograniczenie możliwości podłączania nowych urządzeń. W praktyce oznacza to stosowanie zamkniętych szaf sterowniczych oraz kontrolę dostępu do infrastruktury.

Jednym z najbardziej wrażliwych interfejsów jest port USB. Choć z punktu widzenia użytkownika jest to wygodny sposób aktualizacji systemu, wgrywania aplikacji PLC czy zbierania danych, to jednocześnie stanowi on jeden z najprostszych wektorów ataku. USB umożliwia bowiem fizyczne dostarczenie złośliwego oprogramowania bez konieczności posiadania dostępu do sieci. Z tego względu dostęp do portu USB powinien być ściśle kontrolowany i ograniczony do autoryzowanego personelu. Dokument zaleca również korzystanie wyłącznie z oficjalnych pakietów aktualizacyjnych oraz unikanie udostępniania własnych paczek w sposób niekontrolowany. Istotne jest również wyłączenie automatycznych operacji wykonywanych po podłączeniu nośnika oraz stosowanie mechanizmów zapobiegających przypadkowym aktualizacjom. Dodatkowym zagrożeniem jest możliwość wykorzystania adapterów USB-Ethernet, które mogą stworzyć nieautoryzowane połączenie sieciowe i ominąć istniejące zabezpieczenia.

W kontekście USB dokument zwraca również uwagę na funkcje związane z logowaniem danych. Przechowywanie danych na nośnikach zewnętrznych wiąże się z ryzykiem ich utraty lub nieautoryzowanego dostępu, dlatego zalecane jest stosowanie szyfrowania oraz unikanie automatycznego zapisu danych bez dodatkowej autoryzacji. Istotnym elementem jest także identyfikacja używanych nośników, co pozwala ograniczyć ryzyko użycia nieznanych urządzeń.

Ostatnim elementem poruszonym w załączonym dokumencie jest slot karty SD, który często traktowany jest jako element drugorzędny, a w rzeczywistości może stanowić poważne zagrożenie. Nawet jeśli karta SD nie jest aktywnie wykorzystywana do przechowywania danych, może zostać użyta jako nośnik startowy systemu, co otwiera możliwość ingerencji w oprogramowanie urządzenia. Dlatego dostęp do slotu SD powinien być zabezpieczony fizycznie, najlepiej poprzez umieszczenie go w zamkniętej obudowie.

Całość prowadzi do bardzo jednoznacznego wniosku: bezpieczeństwo systemów automatyki nie wynika z pojedynczych funkcji czy mechanizmów, lecz z konsekwentnego podejścia do wszystkich interfejsów komunikacyjnych. Każdy port, niezależnie od jego przeznaczenia, powinien być traktowany jako potencjalne źródło zagrożenia, a jego użycie musi być świadomie zaplanowane, ograniczone i zabezpieczone zarówno na poziomie logicznym, jak i fizycznym.

Rekomendacje ogólne dla systemów i infrastruktury

Rekomendacje dla bezpieczeństwa aplikacji