{"id":26038,"date":"2026-06-30T14:53:56","date_gmt":"2026-06-30T12:53:56","guid":{"rendered":"https:\/\/www.astor.com.pl\/poradnikautomatyka\/?p=26038"},"modified":"2026-06-30T14:53:58","modified_gmt":"2026-06-30T12:53:58","slug":"dyrektywa-nis2-i-regulacja-cra-a-cyberbezpieczenstwo-systemow-automatyki-astraada-one-i-codesys-dobre-praktyki-dla-inzyniera-automatyka","status":"publish","type":"post","link":"https:\/\/www.astor.com.pl\/poradnikautomatyka\/dyrektywa-nis2-i-regulacja-cra-a-cyberbezpieczenstwo-systemow-automatyki-astraada-one-i-codesys-dobre-praktyki-dla-inzyniera-automatyka\/","title":{"rendered":"Dyrektywa NIS2 i regulacja CRA a cyberbezpiecze\u0144stwo system\u00f3w automatyki. Astraada One i CODESYS: dobre praktyki dla in\u017cyniera automatyka"},"content":{"rendered":"\n
<\/div>\n\n\n\n

Dyrektywa NIS2 jednoznacznie wskazuje, \u017ce cyberbezpiecze\u0144stwo infrastruktury przemys\u0142owej przestaje by\u0107 opcj\u0105 \u2013 staje si\u0119 obowi\u0105zkiem organizacyjnym i technicznym. Dotyczy to w szczeg\u00f3lno\u015bci system\u00f3w automatyki przemys\u0142owej (OT), w kt\u00f3rych sterowniki PLC, panele HMI i oprogramowanie in\u017cynierskie s\u0105 integraln\u0105 cz\u0119\u015bci\u0105 proces\u00f3w krytycznych. Sterowniki Astraada One, oparte o \u015brodowisko CODESYS, zosta\u0142y zaprojektowane zgodnie z zasad\u0105 security by design<\/em> i defense in depth<\/em>, co oznacza wielowarstwowe podej\u015bcie do ochrony systemu \u2013 od sprz\u0119tu, przez system operacyjny, a\u017c po aplikacj\u0119 u\u017cytkownika.<\/strong><\/p>\n\n\n\n

Zgodnie z norm\u0105 IEC 62443 <\/strong>sterowniki PLC s\u0105 zdefiniowane na poziomie podstawowej ochrony przed przypadkowym lub nieumy\u015blnym naruszeniem bezpiecze\u0144stwa SL 1<\/strong>.<\/p>\n\n\n\n

W tym artykule zostanie przedstawiony zestaw rekomendacji aplikacyjnych<\/strong>, kt\u00f3re \u2013 prawid\u0142owo wdro\u017cone \u2013 znacz\u0105co u\u0142atwiaj\u0105 spe\u0142nienie wymaga\u0144 NIS2 oraz podnosz\u0105 realny poziom bezpiecze\u0144stwa instalacji, z perspektywy u\u017cytkownika sterownik\u00f3w Astraada One<\/strong>.<\/p>\n\n\n\n

Do artyku\u0142u do\u0142\u0105czony zosta\u0142 dokument Security Guideline<\/a><\/em><\/strong>, kt\u00f3ry szczeg\u00f3\u0142owo opisuje zagadnienia zwi\u0105zane z cyberbezpiecze\u0144stwem urz\u0105dze\u0144 opartych na Astraada One. Dokument ten obejmuje zar\u00f3wno podstawowe koncepcje bezpiecze\u0144stwa, takie jak wcze\u015bniej wymienione model CIA<\/em> i strategia Defense in Depth<\/em>, jak i bardzo praktyczne aspekty konfiguracji system\u00f3w \u2013 w tym zabezpieczanie port\u00f3w komunikacyjnych, zarz\u0105dzanie dost\u0119pem zdalnym, aktualizacje oprogramowania, wykorzystanie narz\u0119dzi serwisowych oraz dobre praktyki w zakresie tworzenia i utrzymania aplikacji steruj\u0105cych.<\/p>\n\n\n\n

\r\n\t\t\t\t\t\t\t\"arrow\"\r\n\t\t\t\t\t\t\t<\/a>\r\n\t\t\t\t\t\t\t

Dokument Astraada One Security Guideline<\/a> w formacie PDF<\/p>\n<\/div>\r\n\t\t\t\t\t<\/div>\r\n\t\n\n\n\n

<\/div>\n\n\n\n

Regulacja CRA \u2013 kompleksowe wymagania dotycz\u0105ce cyberbezpiecze\u0144stwa produkt\u00f3w z funkcjami cyfrowymi<\/h2>\n\n\n\n

Cyber Resilience Act (CRA) jest rozporz\u0105dzeniem Unii Europejskiej, kt\u00f3re porz\u0105dkuje temat cyberbezpiecze\u0144stwa urz\u0105dze\u0144. Jego g\u0142\u00f3wnym celem jest wprowadzenie jednego, sp\u00f3jnego poziomu ochrony dla wszystkich produkt\u00f3w cyfrowych dost\u0119pnych na rynku UE.<\/p>\n\n\n\n

W praktyce oznacza to, \u017ce ka\u017cdy produkt wyposa\u017cony w oprogramowanie i komunikacj\u0119 sieciow\u0105 \u2013 od sterownik\u00f3w PLC przez systemy embedded a\u017c po aplikacje chmurowe \u2013 musi by\u0107 projektowany i utrzymywany z my\u015bl\u0105 o bezpiecze\u0144stwie. CRA obejmuje wi\u0119c zdecydowan\u0105 wi\u0119kszo\u015b\u0107 nowoczesnych rozwi\u0105za\u0144 automatyki i Przemys\u0142u 4.0.<\/p>\n\n\n\n

Najwa\u017cniejsza zmiana polega na tym, \u017ce cyberbezpiecze\u0144stwo przestaje by\u0107 dodatkiem, a staje si\u0119 wymaganiem \u201eod pocz\u0105tku do ko\u0144ca<\/em>\u201d. Producent musi uwzgl\u0119dni\u0107 je ju\u017c na etapie projektowania (tzw. security by design<\/em>), a nast\u0119pnie dba\u0107 o nie przez ca\u0142y cykl \u017cycia produktu. Oznacza to konieczno\u015b\u0107 analizy ryzyka, eliminowania podatno\u015bci, stosowania bezpiecznych konfiguracji oraz dostarczania aktualizacji \u2013 tak\u017ce d\u0142ugo po wdro\u017ceniu u klienta.<\/p>\n\n\n\n

CRA wprowadza r\u00f3wnie\u017c konkretne obowi\u0105zki operacyjne. Firmy musz\u0105 mie\u0107 proces zarz\u0105dzania podatno\u015bciami, a w przypadku wykrycia powa\u017cnej, aktywnie wykorzystywanej luki \u2013 zg\u0142osi\u0107 j\u0105 do ENISA w ci\u0105gu 24 godzin. Dodatkowo spe\u0142nienie wymaga\u0144 b\u0119dzie powi\u0105zane z oznaczeniem CE, co oznacza, \u017ce bez zgodno\u015bci z CRA produkt mo\u017ce nie zosta\u0107 dopuszczony do rynku.<\/p>\n\n\n\n

Z perspektywy automatyka oznacza to jedn\u0105 kluczow\u0105 zmian\u0119: projektowanie system\u00f3w sterowania b\u0119dzie coraz bardziej \u0142\u0105czy\u0107 \u015bwiat OT i IT. Opr\u00f3cz funkcjonalno\u015bci i bezpiecze\u0144stwa maszyn trzeba b\u0119dzie zadba\u0107 o odporno\u015b\u0107 na cyberzagro\u017cenia, dokumentacj\u0119 proces\u00f3w i d\u0142ugoterminowe wsparcie system\u00f3w.<\/p>\n\n\n\n

\r\n\t\t\t\t\t\t\t\"arrow\"\r\n\t\t\t\t\t\t\t<\/a>\r\n\t\t\t\t\t\t\t

<\/p>\n

Kiedy CRA wchodzi w \u017cycie?<\/strong><\/p>\n

<\/p>\n

Przyj\u0119cie przez Parlament Europejski: marzec 2024<\/strong><\/p>\n

<\/p>\n

Publikacja w Dzienniku Urz\u0119dowym UE: 2024<\/strong><\/p>\n

<\/p>\n

Okres przej\u015bciowy: 36 miesi\u0119cy<\/strong><\/p>\n

<\/p>\n

Obowi\u0105zkowe stosowanie: od grudnia 2027 roku<\/strong><\/p>\n<\/div>\r\n\t\t\t\t\t<\/div>\r\n\t\n\n\n\n

<\/div>\n\n\n\n

Model CIA i Defense in Depth w automatyce przemys\u0142owej \u2013 fundamenty cyberbezpiecze\u0144stwa<\/h2>\n\n\n\n

Wsp\u00f3\u0142czesne systemy automatyki przemys\u0142owej przesta\u0142y by\u0107 izolowanymi wyspami. Integracja z systemami IT, chmur\u0105 oraz zdalnym dost\u0119pem sprawia, \u017ce klasyczne podej\u015bcie \u201ezamkni\u0119tej sieci\u201d ju\u017c nie wystarcza. W tym kontek\u015bcie szczeg\u00f3lnego znaczenia nabieraj\u0105 dwa fundamentalne podej\u015bcia do bezpiecze\u0144stwa: model CIA<\/strong> oraz strategia Defense in Depth<\/strong>. To one stanowi\u0105 podstaw\u0119 projektowania bezpiecznych system\u00f3w OT.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Model CIA \u2013 trzy filary bezpiecze\u0144stwa<\/h3>\n\n\n\n
<\/div>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n

Model CIA (Confidentiality, Integrity, Availability<\/em>) jest jedn\u0105 z najbardziej podstawowych koncepcji bezpiecze\u0144stwa informacji. Okre\u015bla on trzy g\u0142\u00f3wne cele, kt\u00f3re powinny by\u0107 realizowane w ka\u017cdym systemie: poufno\u015b\u0107, integralno\u015b\u0107<\/em> oraz dost\u0119pno\u015b\u0107<\/em>. Cho\u0107 pochodzenie tej koncepcji wywodzi si\u0119 z IT, jej zastosowanie w automatyce przemys\u0142owej jest nie tylko mo\u017cliwe, ale wr\u0119cz konieczne.<\/p>\n\n\n\n

Poufno\u015b\u0107 (Confidentiality)<\/strong><\/p>\n\n\n\n

Poufno\u015b\u0107 oznacza, \u017ce dost\u0119p do danych maj\u0105 wy\u0142\u0105cznie osoby i systemy do tego uprawnione. Oznacza to ochron\u0119 takich informacji, jak receptury produkcyjne, parametry proces\u00f3w technologicznych czy konfiguracje sterownik\u00f3w. Je\u015bli poufno\u015b\u0107 zostanie naruszona, mo\u017ce to prowadzi\u0107 nie tylko do utraty przewagi konkurencyjnej, ale r\u00f3wnie\u017c do powa\u017cnych zagro\u017ce\u0144 operacyjnych. Przyk\u0142adowo, osoba nieuprawniona, maj\u0105c dost\u0119p do ustawie\u0144 technologicznych, mo\u017ce uzyska\u0107 wiedz\u0119 pozwalaj\u0105c\u0105 na manipulacj\u0119 procesem produkcyjnym. Zapewnienie poufno\u015bci sprowadza si\u0119 do stosowania mechanizm\u00f3w uwierzytelniania u\u017cytkownik\u00f3w (login + has\u0142o), kontroli dost\u0119pu, segmentacji sieci oddzielnie OT od IT oraz szyfrowania komunikacji jak np. https czy VPN.<\/p>\n\n\n\n

Integralno\u015b\u0107 (Integrity)<\/strong><\/p>\n\n\n\n

Integralno\u015b\u0107 odnosi si\u0119 do pewno\u015bci, \u017ce dane i systemy nie zosta\u0142y zmodyfikowane w spos\u00f3b nieautoryzowany. W automatyce ma to kluczowe znaczenie, poniewa\u017c ka\u017cda zmiana mo\u017ce wp\u0142ywa\u0107 bezpo\u015brednio na proces produkcyjny. Aspekt ten jest szczeg\u00f3lnie wa\u017cny, poniewa\u017c nawet niewielka zmiana w logice sterowania mo\u017ce mie\u0107 powa\u017cne konsekwencje dla procesu, maszyn, a nawet bezpiecze\u0144stwa ludzi. Naruszenie integralno\u015bci mo\u017ce objawia\u0107 si\u0119 poprzez nieautoryzowan\u0105 zmian\u0119 programu PLC, modyfikacj\u0119 parametr\u00f3w pracy urz\u0105dzenia lub ingerencj\u0119 w dane pomiarowe. W praktyce ochrona integralno\u015bci polega na stosowaniu kontroli wersji oprogramowania, podpis\u00f3w cyfrowych, zarz\u0105dzania u\u017cytkownikami (np. w postaci braku kont anonimowych) oraz szczeg\u00f3\u0142owego logowania zmian. Kluczowe jest r\u00f3wnie\u017c ograniczenie dost\u0119pu do narz\u0119dzi in\u017cynierskich takich jak \u015brodowiska programistyczne PLC (np. oprogramowanie CODESYS).<\/p>\n\n\n\n

Dost\u0119pno\u015b\u0107 (Availability)<\/strong><\/p>\n\n\n\n

Dost\u0119pno\u015b\u0107 oznacza, \u017ce system i dane s\u0105 dost\u0119pne wtedy, gdy s\u0105 potrzebne. W systemach przemys\u0142owych to cz\u0119sto najwa\u017cniejszy aspekt \u2013 przest\u00f3j oznacza realne straty finansowe. W przypadku zak\u0142ad\u00f3w produkcyjnych brak dost\u0119pno\u015bci bardzo szybko przek\u0142ada si\u0119 na realne straty finansowe wynikaj\u0105ce z przestoj\u00f3w. Ataki typu ransomware, awarie system\u00f3w czy b\u0142\u0119dy konfiguracji mog\u0105 skutecznie zablokowa\u0107 dzia\u0142anie instalacji przemys\u0142owej. Dlatego zapewnienie dost\u0119pno\u015bci wymaga stosowania redundancji, monitoringu system\u00f3w, regularnych aktualizacji oraz mechanizm\u00f3w tworzenia kopii zapasowych.<\/p>\n\n\n\n

Warto podkre\u015bli\u0107, \u017ce trzy filary modelu CIA pozostaj\u0105 ze sob\u0105 w pewnym napi\u0119ciu i wymagaj\u0105 kompromisu. Zbyt restrykcyjne podej\u015bcie do bezpiecze\u0144stwa mo\u017ce utrudni\u0107 dost\u0119p serwisowy i spowolni\u0107 prac\u0119, natomiast nadmierna dost\u0119pno\u015b\u0107 bez odpowiednich zabezpiecze\u0144 prowadzi do zwi\u0119kszonego ryzyka ataku. Zadaniem in\u017cyniera automatyka jest znalezienie r\u00f3wnowagi pomi\u0119dzy tymi aspektami.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Defense in Depth \u2013 podej\u015bcie warstwowe<\/h3>\n\n\n\n
<\/div>\n\n\n
\n
\"\"
Wielowarstwowa ochrona systemu<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n

Podczas gdy model CIA definiuje, co nale\u017cy chroni\u0107, strategia Defense in Depth odpowiada na pytanie, jak to zrobi\u0107 skutecznie. Podej\u015bcie to zak\u0142ada, \u017ce pojedyncze zabezpieczenie nigdy nie jest wystarczaj\u0105ce. Zamiast tego buduje si\u0119 wielowarstwowy system ochrony, w kt\u00f3rym ka\u017cda warstwa pe\u0142ni okre\u015blon\u0105 funkcj\u0119 i stanowi dodatkow\u0105 barier\u0119 dla potencjalnego atakuj\u0105cego.<\/p>\n\n\n\n

Pierwsz\u0105 i najbardziej podstawow\u0105 warstw\u0105 jest warstwa fizyczna<\/strong>, kt\u00f3ra bywa niedoceniana, mimo \u017ce stanowi jedno z najwa\u017cniejszych zabezpiecze\u0144. Oznacza to przede wszystkim w\u0142a\u015bciwe zabezpieczenie szafy sterowniczej. Dost\u0119p do sterownika, port\u00f3w USB czy resetu nie powinien by\u0107 mo\u017cliwy dla przypadkowych os\u00f3b. Cz\u0119sto spotykana jest sytuacja, gdzie gniazdo USB jest dost\u0119pne z zewn\u0105trz szafy lub \u0142atwy jest dost\u0119p do panelu operatorskiego. Tymczasem z poziomu USB mo\u017cliwe jest wgranie konfiguracji, aktualizacji czy nawet zmiana aplikacji PLC. Dlatego fizyczne zamkni\u0119cie szafy, stosowanie zamk\u00f3w oraz kontrola dost\u0119pu do pomieszcze\u0144 technicznych to absolutna podstawa. Istotne jest r\u00f3wnie\u017c ograniczenie mo\u017cliwo\u015bci pod\u0142\u0105czenia laptopa serwisowego bez kontroli \u2013 fizyczne bezpiecze\u0144stwo to pierwszy filtr, kt\u00f3ry mo\u017ce zatrzymywa\u0107 najprostsze ataki.<\/p>\n\n\n\n

Kolejn\u0105 warstw\u0105 jest warstwa sieciowa<\/strong>, kt\u00f3ra w nowoczesnych systemach automatyki odgrywa kluczow\u0105 rol\u0119. Sterowniki Astraada One mog\u0105 komunikowa\u0107 si\u0119 poprzez Ethernet, co automatycznie czyni t\u0119 warstw\u0119 jednym z g\u0142\u00f3wnych wektor\u00f3w ataku. Istotnym aspektem jest konieczno\u015b\u0107 segmentacji sieci i wyra\u017anego oddzielenia \u015brodowiska OT od IT. Sterownik nie powinien znajdowa\u0107 si\u0119 w tej samej podsieci, co komputery biurowe. Wdro\u017cenie VLAN-\u00f3w, firewalli przemys\u0142owych czy nawet prostych regu\u0142 filtruj\u0105cych ruch sieciowy znacz\u0105co ogranicza ryzyko. W kontek\u015bcie CODESYS szczeg\u00f3lnie istotne jest ograniczenie dost\u0119pu do port\u00f3w programistycznych \u2013 je\u017celi port komunikacyjny \u015brodowiska in\u017cynierskiego jest otwarty w ca\u0142ej sieci, ka\u017cdy u\u017cytkownik maj\u0105cy dost\u0119p do tej sieci mo\u017ce potencjalnie po\u0142\u0105czy\u0107 si\u0119 ze sterownikiem. Dlatego dobrym podej\u015bciem jest dopuszczanie komunikacji tylko z wybranych adres\u00f3w IP lub wy\u0142\u0105cznie przez VPN.<\/p>\n\n\n\n

Nast\u0119pna warstwa to warstwa systemowa<\/strong>, kt\u00f3ra obejmuje konfiguracj\u0119 samego urz\u0105dzenia. Dotyczy to \u015bwiadomego zarz\u0105dzania us\u0142ugami systemowymi \u2013 wy\u0142\u0105czanie FTP, SSH czy VNC, je\u015bli nie s\u0105 potrzebne, oraz odpowiednie zabezpieczenie ich, je\u015bli musz\u0105 pozosta\u0107 aktywne. Domy\u015blnie wiele z tych us\u0142ug jest dost\u0119pnych, co wynika z wygody u\u017cytkownika, ale w \u015brodowisku produkcyjnym powinno by\u0107 traktowane jako potencjalne ryzyko. Z punktu widzenia in\u017cyniera wa\u017cne jest, aby traktowa\u0107 sterownik nie tylko jako urz\u0105dzenie automatyki, ale jako pe\u0142noprawny system IT z systemem operacyjnym. To oznacza konieczno\u015b\u0107 aktualizacji, kontroli konfiguracji oraz \u015bwiadomego zarz\u0105dzania us\u0142ugami. Cz\u0119sto spotykanym b\u0142\u0119dem jest pozostawienie aktywnego SSH czy FTP \u201ebo mo\u017ce si\u0119 kiedy\u015b przyda\u0107\u201d, co znacz\u0105co zwi\u0119ksza powierzchni\u0119 ataku.<\/p>\n\n\n\n

Warstwa aplikacyjna<\/strong> jest miejscem, w kt\u00f3rym szczeg\u00f3lnie widoczna staje si\u0119 rola CODESYS. To tutaj chroniona jest logika sterowania, czyli serce ca\u0142ego systemu. W tym \u015brodowisku programistycznym niezwykle istotne jest w\u0142\u0105czenie mechanizm\u00f3w zarz\u0105dzania u\u017cytkownikami i wymuszenie logowania przy pr\u00f3bie po\u0142\u0105czenia ze sterownikiem. Dzi\u0119ki temu ka\u017cda pr\u00f3ba dost\u0119pu do aplikacji PLC jest kontrolowana i mo\u017cliwa do prze\u015bledzenia. W praktyce oznacza to odej\u015bcie od pracy \u201ena otwartym sterowniku\u201d, gdzie ka\u017cdy mo\u017ce si\u0119 pod\u0142\u0105czy\u0107 i wgra\u0107 zmiany. Kolejnym istotnym elementem tej warstwy jest kontrola wersji aplikacji oraz ograniczenie mo\u017cliwo\u015bci wgrywania programu tylko do autoryzowanych u\u017cytkownik\u00f3w. W przypadku Astraada One i CODESYS warto r\u00f3wnie\u017c zadba\u0107 o odpowiedni\u0105 struktur\u0119 projektu i jasno zdefiniowane uprawnienia, tak aby operator nie mia\u0142 takich samych mo\u017cliwo\u015bci jak in\u017cynier utrzymania ruchu.<\/p>\n\n\n\n

Bezpo\u015brednio powi\u0105zana z tym jest warstwa u\u017cytkownika<\/strong>, kt\u00f3ra bardzo cz\u0119sto stanowi najs\u0142absze ogniwo systemu. Nawet najlepiej zabezpieczona infrastruktura nie b\u0119dzie bezpieczna, je\u015bli u\u017cytkownicy pos\u0142uguj\u0105 si\u0119 prostymi has\u0142ami lub wsp\u00f3\u0142dziel\u0105 konta. W systemach wykorzystuj\u0105cych Astraada One oraz CODESYS kluczowe jest wprowadzenie zasad zarz\u0105dzania u\u017cytkownikami \u2013 przypisanie r\u00f3l, wymuszanie zmiany hase\u0142 oraz eliminacja kont wsp\u00f3\u0142dzielonych. Oznacza to, \u017ce ka\u017cdy u\u017cytkownik powinien mie\u0107 swoje indywidualne konto, a jego uprawnienia powinny by\u0107 ograniczone do niezb\u0119dnego minimum. Takie podej\u015bcie nie tylko zwi\u0119ksza bezpiecze\u0144stwo, ale r\u00f3wnie\u017c pozwala na pe\u0142n\u0105 identyfikowalno\u015b\u0107 dzia\u0142a\u0144 w systemie.<\/p>\n\n\n\n

<\/div>\n\n\n
\n
\"\"
Zarz\u0105dzanie u\u017cytkownikami i ich uprawnieniami w CODESYS, okno User Management<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n
<\/div>\n\n\n
\n
\"\"
Zarz\u0105dzanie u\u017cytkownikami i ich uprawnieniami w CODESYS, okno Access rights<\/em><\/figcaption><\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n

Ostatni\u0105, ale niezwykle wa\u017cn\u0105 warstw\u0105 jest monitoring i rejestracja zdarze\u0144<\/strong>. W kontek\u015bcie Defense in Depth nie chodzi tylko o zapobieganie atakom, ale r\u00f3wnie\u017c o ich wykrywanie i reagowanie. Sterowniki Astraada One oparte o CODESYS oferuj\u0105 mo\u017cliwo\u015b\u0107 logowania zdarze\u0144 takich, jak pr\u00f3by logowania, zmiany konfiguracji czy b\u0142\u0119dy systemowe. Zazwyczaj funkcja ta jest pomijana lub ograniczona do minimum. Tymczasem regularna analiza log\u00f3w mo\u017ce pozwoli\u0107 na wykrycie nieautoryzowanych pr\u00f3b dost\u0119pu, zanim doprowadz\u0105 one do powa\u017cniejszych incydent\u00f3w. W bardziej zaawansowanych systemach logi mog\u0105 by\u0107 dodatkowo przesy\u0142ane do centralnych system\u00f3w monitoringu, co umo\u017cliwia ich korelacj\u0119 i analiz\u0119 na poziomie ca\u0142ego zak\u0142adu.<\/p>\n\n\n\n

Defense in Depth powinni\u015bmy rozumie\u0107 jako budowanie systemu, w kt\u00f3rym ka\u017cda z tych warstw dzia\u0142a niezale\u017cnie, ale jednocze\u015bnie wspiera pozosta\u0142e. Je\u015bli kto\u015b uzyska fizyczny dost\u0119p do urz\u0105dzenia, nadal napotka zabezpieczenia sieciowe. Je\u015bli ominie zabezpieczenia sieciowe, b\u0119dzie musia\u0142 zmierzy\u0107 si\u0119 z kontrol\u0105 dost\u0119pu. A nawet je\u015bli uda mu si\u0119 zalogowa\u0107, jego dzia\u0142ania b\u0119d\u0105 ograniczone uprawnieniami i zapisane w logach.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ka\u017cdy port to potencjalne zagro\u017cenie \u2013 jak bezpiecznie zarz\u0105dza\u0107 interfejsami komunikacyjnymi ?<\/h2>\n\n\n\n

W za\u0142\u0105czonym dokumencie Security Guideline<\/a> mo\u017cna odczyta\u0107 m.in. \u017ce porty komunikacyjne s\u0105 bardzo istotnym ostrze\u017ceniem dla ka\u017cdego in\u017cyniera automatyki: ka\u017cdy interfejs, niezale\u017cnie od tego, czy jest u\u017cywany w danej aplikacji czy pozostaje nieaktywny, stanowi potencjalne miejsce ataku i powinien by\u0107 traktowany jako element wymagaj\u0105cy \u015bwiadomego zarz\u0105dzania bezpiecze\u0144stwem. W praktyce oznacza to konieczno\u015b\u0107 przyj\u0119cia podej\u015bcia, w kt\u00f3rym wszystkie porty i interfejsy s\u0105 analizowane, ograniczane i zabezpieczane ju\u017c na etapie projektowania systemu, a nie dopiero po jego uruchomieniu.<\/p>\n\n\n\n

<\/div>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
<\/div>\n\n\n\n

Szczeg\u00f3lne znaczenie w tym kontek\u015bcie ma interfejs Ethernet<\/strong>, kt\u00f3ry pe\u0142ni rol\u0119 g\u0142\u00f3wnego kana\u0142u komunikacji w nowoczesnych sterownikach. To w\u0142a\u015bnie przez Ethernet realizowany jest dost\u0119p do interfejsu webowego, konfiguracji systemu, \u015brodowiska programistycznego takiego jak CODESYS, a tak\u017ce us\u0142ug takich jak SSH czy FTP. Z tego powodu Ethernet staje si\u0119 jednym z najcz\u0119\u015bciej wykorzystywanych wektor\u00f3w ataku. Nie wystarczy jedynie uruchomi\u0107 komunikacji sieciowej \u2013 konieczne jest jej \u015bwiadome ograniczenie. Sie\u0107 sterownik\u00f3w powinna by\u0107 odseparowana od sieci firmowej przy u\u017cyciu firewalla, a dost\u0119p do niej powinien by\u0107 mo\u017cliwy wy\u0142\u0105cznie z kontrolowanych punkt\u00f3w. W praktyce oznacza to tworzenie wydzielonych podsieci lub VLAN-\u00f3w oraz stosowanie zasad filtrowania ruchu. Dodatkowo istotne jest monitorowanie sieci w poszukiwaniu nieznanych urz\u0105dze\u0144 oraz ograniczenie fizycznego dost\u0119pu do punkt\u00f3w sieciowych, na przyk\u0142ad poprzez zamkni\u0119cie ich w szafie sterowniczej. Kluczowym elementem jest r\u00f3wnie\u017c stosowanie szyfrowania komunikacji wsz\u0119dzie tam, gdzie jest to mo\u017cliwe, co znacz\u0105co podnosi poziom ochrony przed manipulacj\u0105 danymi.<\/p>\n\n\n\n

W przypadku interfejs\u00f3w takich jak EtherCAT<\/strong>, dokument podkre\u015bla, \u017ce cho\u0107 s\u0105 one zazwyczaj wykorzystywane w zamkni\u0119tych systemach sterowania, to nie oznacza to, \u017ce s\u0105 one bezpieczne same z siebie. EtherCAT, podobnie jak wiele protoko\u0142\u00f3w przemys\u0142owych czasu rzeczywistego, nie zosta\u0142 zaprojektowany z my\u015bl\u0105 o cyberbezpiecze\u0144stwie. W zwi\u0105zku z tym jedyn\u0105 skuteczn\u0105 metod\u0105 ochrony pozostaje ograniczenie dost\u0119pu do ca\u0142ej sieci oraz zabezpieczenie fizyczne infrastruktury. W praktyce oznacza to, \u017ce sie\u0107 EtherCAT powinna by\u0107 dost\u0119pna wy\u0142\u0105cznie w strefie kontrolowanej, a wszelkie elementy infrastruktury, takie jak przewody czy wyspy I\/O, powinny by\u0107 chronione przed nieautoryzowanym dost\u0119pem.<\/p>\n\n\n\n

Podobna filozofia dotyczy interfejs\u00f3w szeregowych, takich jak RS232 czy RS485<\/strong>, kt\u00f3re mimo d\u0142ugiej historii u\u017cytkowania nadal s\u0105 szeroko stosowane w wielu instalacjach. Ich problem polega na tym, \u017ce praktycznie nie posiadaj\u0105 mechanizm\u00f3w bezpiecze\u0144stwa, co oznacza, \u017ce ka\u017cdy, kto uzyska fizyczny dost\u0119p do magistrali, mo\u017ce potencjalnie komunikowa\u0107 si\u0119 z urz\u0105dzeniem. Dlatego dokument zaleca maksymalne ograniczenie dost\u0119pno\u015bci tych interfejs\u00f3w oraz ich wy\u0142\u0105czanie, je\u015bli nie s\u0105 potrzebne. Je\u015bli komunikacja musi by\u0107 utrzymana, warto rozwa\u017cy\u0107 implementacj\u0119 dodatkowych mechanizm\u00f3w ochrony na poziomie aplikacji, takich jak autoryzacja lub szyfrowanie danych.<\/p>\n\n\n\n

Analogiczne zagro\u017cenia dotycz\u0105 magistrali CAN<\/strong>, kt\u00f3ra r\u00f3wnie\u017c nie posiada natywnych mechanizm\u00f3w zabezpieczaj\u0105cych. W tym przypadku szczeg\u00f3lnie niebezpieczna jest mo\u017cliwo\u015b\u0107 do\u0142\u0105czenia nieautoryzowanego urz\u0105dzenia do sieci i generowania ramek danych, kt\u00f3re mog\u0105 wp\u0142ywa\u0107 na dzia\u0142anie ca\u0142ego systemu. Dlatego tak istotne jest fizyczne zabezpieczenie dost\u0119pu do magistrali oraz ograniczenie mo\u017cliwo\u015bci pod\u0142\u0105czania nowych urz\u0105dze\u0144. W praktyce oznacza to stosowanie zamkni\u0119tych szaf sterowniczych oraz kontrol\u0119 dost\u0119pu do infrastruktury.<\/p>\n\n\n\n

Jednym z najbardziej wra\u017cliwych interfejs\u00f3w jest port USB<\/strong>. Cho\u0107 z punktu widzenia u\u017cytkownika jest to wygodny spos\u00f3b aktualizacji systemu, wgrywania aplikacji PLC czy zbierania danych, to jednocze\u015bnie stanowi on jeden z najprostszych wektor\u00f3w ataku. USB umo\u017cliwia bowiem fizyczne dostarczenie z\u0142o\u015bliwego oprogramowania bez konieczno\u015bci posiadania dost\u0119pu do sieci. Z tego wzgl\u0119du dost\u0119p do portu USB powinien by\u0107 \u015bci\u015ble kontrolowany i ograniczony do autoryzowanego personelu. Dokument zaleca r\u00f3wnie\u017c korzystanie wy\u0142\u0105cznie z oficjalnych pakiet\u00f3w aktualizacyjnych oraz unikanie udost\u0119pniania w\u0142asnych paczek w spos\u00f3b niekontrolowany. Istotne jest r\u00f3wnie\u017c wy\u0142\u0105czenie automatycznych operacji wykonywanych po pod\u0142\u0105czeniu no\u015bnika oraz stosowanie mechanizm\u00f3w zapobiegaj\u0105cych przypadkowym aktualizacjom. Dodatkowym zagro\u017ceniem jest mo\u017cliwo\u015b\u0107 wykorzystania adapter\u00f3w USB-Ethernet, kt\u00f3re mog\u0105 stworzy\u0107 nieautoryzowane po\u0142\u0105czenie sieciowe i omin\u0105\u0107 istniej\u0105ce zabezpieczenia.<\/p>\n\n\n\n

W kontek\u015bcie USB dokument zwraca r\u00f3wnie\u017c uwag\u0119 na funkcje zwi\u0105zane z logowaniem danych. Przechowywanie danych na no\u015bnikach zewn\u0119trznych wi\u0105\u017ce si\u0119 z ryzykiem ich utraty lub nieautoryzowanego dost\u0119pu, dlatego zalecane jest stosowanie szyfrowania oraz unikanie automatycznego zapisu danych bez dodatkowej autoryzacji. Istotnym elementem jest tak\u017ce identyfikacja u\u017cywanych no\u015bnik\u00f3w, co pozwala ograniczy\u0107 ryzyko u\u017cycia nieznanych urz\u0105dze\u0144.<\/p>\n\n\n\n

Ostatnim elementem poruszonym w za\u0142\u0105czonym dokumencie jest slot karty SD<\/strong>, kt\u00f3ry cz\u0119sto traktowany jest jako element drugorz\u0119dny, a w rzeczywisto\u015bci mo\u017ce stanowi\u0107 powa\u017cne zagro\u017cenie. Nawet je\u015bli karta SD nie jest aktywnie wykorzystywana do przechowywania danych, mo\u017ce zosta\u0107 u\u017cyta jako no\u015bnik startowy systemu, co otwiera mo\u017cliwo\u015b\u0107 ingerencji w oprogramowanie urz\u0105dzenia. Dlatego dost\u0119p do slotu SD powinien by\u0107 zabezpieczony fizycznie, najlepiej poprzez umieszczenie go w zamkni\u0119tej obudowie.<\/p>\n\n\n\n

Ca\u0142o\u015b\u0107 prowadzi do bardzo jednoznacznego wniosku: bezpiecze\u0144stwo system\u00f3w automatyki nie wynika z pojedynczych funkcji czy mechanizm\u00f3w, lecz z konsekwentnego podej\u015bcia do wszystkich interfejs\u00f3w komunikacyjnych. Ka\u017cdy port, niezale\u017cnie od jego przeznaczenia, powinien by\u0107 traktowany jako potencjalne \u017ar\u00f3d\u0142o zagro\u017cenia, a jego u\u017cycie musi by\u0107 \u015bwiadomie zaplanowane, ograniczone i zabezpieczone zar\u00f3wno na poziomie logicznym, jak i fizycznym.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Rekomendacje og\u00f3lne dla system\u00f3w i infrastruktury<\/h2>\n\n\n\n
<\/div>\n\n\n\n
Nr<\/strong><\/th>Obszar<\/strong><\/th>Opis<\/strong><\/th>Przyk\u0142ad (Astraada One \/ CODESYS)<\/strong><\/th><\/tr><\/thead>
1<\/td>Wzmacnianie konfiguracji (hardening)<\/td>Podstaw\u0105 bezpiecze\u0144stwa jest odpowiednia konfiguracja system\u00f3w i urz\u0105dze\u0144. Nale\u017cy aktywowa\u0107 dost\u0119pne mechanizmy zabezpiecze\u0144 oraz wy\u0142\u0105czy\u0107 zb\u0119dne porty, us\u0142ugi i funkcje, kt\u00f3re mog\u0105 stanowi\u0107 potencjalny punkt wej\u015bcia dla atakuj\u0105cego.<\/td>Na sterowniku wy\u0142\u0105cz FTP i SSH, je\u015bli nie s\u0105 u\u017cywane, oraz ogranicz dost\u0119p do portu CODESYS tylko z wybranych adres\u00f3w IP.<\/td><\/tr>
2<\/td>Aktualizacje i zarz\u0105dzanie podatno\u015bciami<\/td>Regularne stosowanie poprawek bezpiecze\u0144stwa oraz aktualizacja sygnatur system\u00f3w ochronnych (np. antywirus\u00f3w) znacz\u0105co ogranicza ryzyko wykorzystania znanych podatno\u015bci.<\/td>Aktualizuj firmware Astraada One oraz runtime CODESYS do najnowszych publikowanych wersji.<\/td><\/tr>
3<\/td>Whitelisting i kontrola dost\u0119pu<\/td>Wdra\u017canie bia\u0142ych list aplikacji i urz\u0105dze\u0144 pozwala dopuszcza\u0107 wy\u0142\u0105cznie zaufane komponenty, minimalizuj\u0105c ryzyko uruchomienia nieautoryzowanego oprogramowania.<\/td>Na firewallu dopuszcza si\u0119 komunikacj\u0119 do PLC tylko z komputer\u00f3w in\u017cynierskich z zaufanym adresem IP.<\/td><\/tr>
4<\/td>Segmentacja sieci<\/td>Oddzielenie poszczeg\u00f3lnych obszar\u00f3w infrastruktury za pomoc\u0105 firewalli ogranicza propagacj\u0119 atak\u00f3w i umo\u017cliwia skuteczniejsze zarz\u0105dzanie politykami bezpiecze\u0144stwa.<\/td>Umie\u015b\u0107 sterownik w osobnym VLAN-ie i blokuj dost\u0119p z sieci biurowej poza VPN.<\/td><\/tr>
5<\/td>Ograniczenie sieci bezprzewodowych<\/td>Sieci Wi-Fi powinny by\u0107 stosowane tylko tam, gdzie s\u0105 niezb\u0119dne, oraz odpowiednio zabezpieczone przy u\u017cyciu nowoczesnych metod uwierzytelniania i szyfrowania.<\/td>Nie pod\u0142\u0105czaj sterownika do sieci Wi-Fi; je\u015bli konieczne (np. serwis), stosuj WPA3 i dost\u0119p tymczasowy.<\/td><\/tr>
6<\/td>Kontrola dost\u0119pu do interfejs\u00f3w<\/td>Dost\u0119p do interfejs\u00f3w serwisowych (USB) i konfiguracyjnych musi by\u0107 ograniczony wy\u0142\u0105cznie do autoryzowanego personelu, a wszelkie pr\u00f3by narusze\u0144 powinny by\u0107 blokowane.<\/td>Zablokuj fizyczny dost\u0119p do portu USB sterownika lub zabezpiecz go w szafie zamkni\u0119tej na klucz.<\/td><\/tr>
7<\/td>Bezpiecze\u0144stwo fizyczne<\/td>Nale\u017cy wdro\u017cy\u0107 \u015brodki zapobiegaj\u0105ce fizycznej manipulacji urz\u0105dzeniami \u2013 od kontroli dost\u0119pu po monitoring i zabezpieczenia sprz\u0119towe.<\/td>Zamknij szaf\u0119 ze sterownikiem oraz switchami przemys\u0142owymi \u2013 brak dost\u0119pu dla operator\u00f3w.<\/td><\/tr>
8<\/td>Bezpieczne u\u017cycie no\u015bnik\u00f3w zewn\u0119trznych<\/td>Ka\u017cdy no\u015bnik USB powinien by\u0107 weryfikowany przed u\u017cyciem, aby wyeliminowa\u0107 ryzyko wprowadzenia z\u0142o\u015bliwego oprogramowania.<\/td>Ka\u017cdy pendrive u\u017cywany do aktualizacji PLC powinien by\u0107 sprawdzony na dedykowanym komputerze serwisowym.<\/td><\/tr>
9<\/td>Szyfrowanie danych<\/td>Dane wra\u017cliwe, logi i komunikaty b\u0142\u0119d\u00f3w powinny by\u0107 szyfrowane z u\u017cyciem aktualnych standard\u00f3w kryptograficznych.<\/td>Korzystaj z HTTPS w webserwerze Astraada One oraz komunikacji VPN przy dost\u0119pie zdalnym.<\/td><\/tr>
10<\/td>Ochrona interfejs\u00f3w sieciowych<\/td>Interfejsy Ethernet powinny by\u0107 zabezpieczone przed nieautoryzowanym dost\u0119pem, np. poprzez kontrol\u0119 port\u00f3w, uwierzytelnianie i monitoring ruchu.<\/td>Skonfiguruj firewall tak, aby port programistyczny CODESYS (np. TCP) by\u0142 dost\u0119pny tylko z jednego hosta in\u017cynierskiego.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Rekomendacje dla bezpiecze\u0144stwa aplikacji<\/h2>\n\n\n\n
<\/div>\n\n\n\n
Nr<\/strong><\/th>Obszar<\/strong><\/th>Opis<\/strong><\/th>Przyk\u0142ad (Astraada One \/ CODESYS)<\/strong><\/th><\/tr><\/thead>
1<\/td>Zarz\u0105dzanie u\u017cytkownikami i uprawnieniami<\/td>Ka\u017cda aplikacja powinna posiada\u0107 wielopoziomowy system r\u00f3l i uprawnie\u0144. Dost\u0119p do funkcji musi by\u0107 przydzielany zgodnie z zasad\u0105 najmniejszych uprawnie\u0144 (least privilege).<\/td>W CODESYS \u201eUser Management<\/em>\u201d  utw\u00f3rz role: Operator (tylko HMI), Serwis (diagnostyka), Admin (pe\u0142ny dost\u0119p).<\/td><\/tr>
2<\/td>Polityka hase\u0142<\/td>Wymagane jest stosowanie silnych hase\u0142, ich regularna zmiana oraz eliminacja sta\u0142ych hase\u0142 dla kont uprzywilejowanych. Nale\u017cy r\u00f3wnie\u017c ogranicza\u0107 czas wa\u017cno\u015bci hase\u0142 i stosowa\u0107 centralne zarz\u0105dzanie. Dobr\u0105 praktyk\u0105 jest wdro\u017cenie uwierzytelniania wielosk\u0142adnikowego.<\/td>Zmie\u0144 domy\u015blne has\u0142a na sterowniku oraz w CODESYS i wymu\u015b ich rotacj\u0119 co 90 dni.<\/td><\/tr>
3<\/td>Ochrona przed nieautoryzowanym dost\u0119pem<\/td>Powtarzaj\u0105ce si\u0119 b\u0142\u0119dne pr\u00f3by logowania powinny skutkowa\u0107 czasow\u0105 blokad\u0105 konta lub urz\u0105dzenia, co ogranicza skuteczno\u015b\u0107 atak\u00f3w typu brute-force.<\/td>Skonfiguruj blokad\u0119 konta po 3 nieudanych pr\u00f3bach logowania do CODESYS lub interfejsu WWW.<\/td><\/tr>
4<\/td>Bezpieczna konfiguracja aplikacji<\/td>Aplikacje powinny by\u0107 wdra\u017cane w spos\u00f3b bezpieczny ju\u017c na etapie konfiguracji \u2013 z wy\u0142\u0105czonymi funkcjami testowymi, domy\u015blnymi kontami oraz zb\u0119dnymi interfejsami.<\/td>Usu\u0144 tryby debug\/test w aplikacji PLC przed wdro\u017ceniem produkcyjnym.<\/td><\/tr>
5<\/td>Rejestrowanie i audyt zdarze\u0144<\/td>Ka\u017cda zmiana konfiguracji powinna by\u0107 logowana, a logi regularnie analizowane, szczeg\u00f3lnie podczas prac serwisowych. Zaleca si\u0119 r\u00f3wnie\u017c szyfrowanie log\u00f3w w celu ochrony przed manipulacj\u0105.<\/td>W\u0142\u0105cz logowanie zmian w projekcie CODESYS oraz analizuj logi przy ka\u017cdym serwisie.<\/td><\/tr>
6<\/td>Zarz\u0105dzanie danymi<\/td>Aplikacje powinny przechowywa\u0107 wy\u0142\u0105cznie niezb\u0119dne dane zgodnie z zasad\u0105 minimalizacji. Informacje wra\u017cliwe musz\u0105 by\u0107 przechowywane w formie zaszyfrowanej.<\/td>Nie przechowuj hase\u0142 wprost w kodzie PLC \u2013 u\u017cywaj zmiennych zabezpieczonych lub zewn\u0119trznych system\u00f3w.<\/td><\/tr>
7<\/td>Aktualizacja i rotacja danych uwierzytelniaj\u0105cych<\/td>Regularna zmiana danych dost\u0119powych oraz ograniczenie ich okresu wa\u017cno\u015bci zmniejsza ryzyko ich nieautoryzowanego wykorzystania.<\/td>Po zako\u0144czeniu prac serwisowych zmie\u0144 has\u0142a do PLC i dost\u0119p\u00f3w VPN.<\/td><\/tr>
8<\/td>Zgodno\u015b\u0107 z aktualnymi standardami bezpiecze\u0144stwa<\/td>Nale\u017cy stosowa\u0107 aktualne dobre praktyki i standardy bran\u017cowe (np. IEC 62443) oraz regularnie weryfikowa\u0107 stosowane strategie bezpiecze\u0144stwa.<\/td>Projektuj architektur\u0119 sterowania zgodnie z IEC 62443<\/td><\/tr>
9<\/td>Minimalizacja powierzchni ataku<\/td>Ograniczenie liczby dost\u0119pnych funkcji, interfejs\u00f3w i punkt\u00f3w integracji zmniejsza liczb\u0119 potencjalnych wektor\u00f3w ataku.<\/td>Je\u015bli nie korzystasz z WebVisu w CODESYS, wy\u0142\u0105cz serwer webowy ca\u0142kowicie.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
<\/div>\n\n\n\n
\n
\n
\n

Newsletter Poradnika Automatyka<\/h3><\/div>\n

Czytaj trendy i inspiracje, podstawy automatyki, automatyk\u0119 w praktyce<\/p>\n<\/div>\n

\n
\n