A kiberrezilienciáról szóló rendelet a gépgyártók számára a Bizottság 2026. július 27-i iránymutatásai után. Mit kell valójában bevezetni?

Éveken át a gépek kiberbiztonságát három lépésben le lehetett írni: márkás vezérlő, VPN „mert így szokás”, és a klasszikus „a vevő majd megvédi a hálózatot”. Ha pedig valaki még egy tűzfalat is betett a szekrénybe, a kérdést gyakran lezártnak tekintették — legalább addig, amíg valaki meg nem próbálta megnézni, mi történik egy valódi támadás után, nem csak egy prezentációban.

Csakhogy a kiberbiztonság nem a PROFINET-en „érkezik”. Az egyes komponenseknek lehetnek tanúsítványai, megfelelőségi nyilatkozatai és „secure by design” ígéretei a marketinganyagokban, de a gép mint egész ettől még ugyanúgy lehet olyan módon kiszámítható, amelynek semmi köze a biztonsághoz. Ahogy egy biztonsági relé sem teszi önmagában biztonságossá a rendszert, ha a vezérlési logika lehetővé teszi a megkerülését, ugyanúgy egy „biztonságos” HMI sem oldja meg az architektúra, az integráció, a jogosultságok, a frissítések és annak a problémáját, mi történik akkor, amikor valaki már nem kér engedélyt.

A CRA (Cyber Resilience Act, az Európai Parlament és a Tanács (EU) 2024/2847 rendelete) nem az IT kiegészítője. Ez egy termékszabályozás, amely a gép életciklusába úgy lép be, hogy ehhez nem kéri ki az automatizálási részleg hozzájárulását. Kiterjed a vezérlés tervezésére, a kockázatértékelésre, az ellátási láncra, a konfigurációra, a frissítésekre, valamint a termék fenntartására jóval azután is, hogy a FAT-et aláírták, és a gép elhagyta a gyártócsarnokot. És nem, az az érv, hogy „nem tesszük ki az internetre”, nem zárja le a kérdést. A gyakorlatban elég egy szervizlaptop, egy pendrive, egy „csak ideiglenes” távdiagnosztika vagy egy üzemi rendszerrel való integráció ahhoz, hogy az elszigeteltség és a kitettség közötti határ megszűnjön létezni.

A Bizottság 2026. július 27-i iránymutatásai magát a rendeletet nem változtatták meg, de hatékonyan leszűkítették azt az értelmezési mozgásteret, amely korábban lehetővé tette, hogy a kiberbiztonságot opcionális rétegként kezeljék. Pontosították többek között a termék határait, a távoli adatfeldolgozás szerepét, a szállítás utáni módosításokért viselt felelősséget, valamint azt is, hogy az a hozzáállás, miszerint „a FAT után ez már nem a mi problémánk”, többé nem tekinthető biztonságos feltételezésnek.

A legfontosabb változás azonban még ennél is alapvetőbb: a kibertámadás megszűnik kizárólag IT-esemény lenni, és a gép funkcionális biztonságát befolyásoló forgatókönyvvé válik. Ha egy jogosulatlan programmódosítás tengelymozgást, reteszelésmegkerülést, a folyamatparaméterek megváltozását vagy a biztonsági funkciók elvesztését okozhatja, akkor már nem „hálózati incidensről” beszélünk. Hanem a gép potenciálisan ellenőrizetlen viselkedéséről — függetlenül attól, hogy a kiváltó ok konfigurációs hiba, szoftversérülékenység vagy szándékos beavatkozás volt.

Ebben az összefüggésben az egyszeri, FAT előtti penteszt már nem a megfelelőség bizonyítéka, hanem csupán pillanatfelvétel a rendszer adott időpontbeli állapotáról. A CRA folyamatos megközelítést követel meg: a tervezéstől a gyártáson és az üzembe helyezésen át egészen a frissítésekig, a sérülékenységkezelésig, az incidensekre adott reakcióig és a fenntartásig a deklarált támogatási időszak teljes tartama alatt.

A gyakorlatban ez azt jelenti, hogy a „kész = biztonságos” gondolkodásmódtól el kell mozdulni a „fenntartott = ellenőrzés alatt tartott” szemlélet felé. Annak az illúziója nélkül, hogy a szekrénybe épített tűzfal, a VPN és egy komponens tanúsítványa lezárja a kérdést. És annak feltételezése nélkül is, hogy a kiberbiztonság az átvételi jegyzőkönyv aláírásának pillanatában véget ér.

Ebben a cikkben azt bontjuk ki, hogy a CRA iránymutatásai a valóságban mit változtatnak a gépgyártók, integrátorok és korszerűsítést végző vállalkozások számára — anélkül, hogy az egész témát arra az egyszerű jelszóra redukálnánk, hogy „változtassuk meg a jelszót, és tegyünk be egy cybersecurity jelölőnégyzetet”.

1. Ahhoz, hogy egy gép ne tartozzon a CRA alá, szinte már csak kontaktorokból kellene állnia

Sok projektben a CRA hatályát egyetlen kérdéssel próbálják eldönteni:

Csatlakozik majd a gép az internethez?

Nem.

Akkor a kérdés le van zárva.

A kapcsolási rajzon van PLC, HMI, néhány hajtás, decentralizált be- és kimenetek, szelepsziget, biztonsági szkenner, valamint egy port a program feltöltéséhez. A vezérlő PROFINET-en kommunikál a kezelőpanellel, a hajtásokkal vezérlő- és állapotszavakat cserél, az érzékelők pedig IO-Linken továbbítják az adatokat.

Csak éppen nincs benne SIM-kártyás router.

Mint tudjuk, az adatok csak akkor válnak igazán adatokká, ha elhagyják a gyártócsarnokot.

Csakhogy a CRA nem azt kérdezi, hogy a gép hozzáfér-e az internethez.

Azt kérdezi, hogy a rendeltetése vagy az ésszerűen előre látható használata magában foglalja-e az eszközhöz vagy hálózathoz való közvetlen vagy közvetett, logikai vagy fizikai adatkapcsolatot. Ennek nem kell felhőkapcsolatnak, gyártói szerverhez való csatlakozásnak vagy nyilvános internetelérésnek lennie. Megvalósulhat vezetéken, rádiós kapcsolaton, programozási interfészen keresztül vagy egy nagyobb rendszer részeként.

És itt jön a kulcskérdés: egy tipikus gépben valójában mi továbbít adatot?

Az HMI kiolvassa a PLC állapotait és visszaírja a beállításokat?

A PLC küld a hajtásnak vezérlőszót, és cserébe sebességet, állapotot és hibakódot kap vissza?

A be- és kimeneti sziget továbbítja a folyamatképet?

Az IO-Link érzékelő mérési értéket, eszközazonosítót és diagnosztikai adatokat küld?

A safety PLC PROFIsafe-en keresztül kommunikál a modulokkal?

A programot, a hardverkonfigurációt vagy a firmware-t szervizlaptopról töltik fel?

A receptek, jelentések vagy frissítések USB-n keresztül átvihetők?

Ha a válasz akár csak egyszer is „igen”, akkor nagy valószínűséggel adatkapcsolatról beszélünk.

És ezen az sem változtat, hogy:

• a gép helyi hálózatban működik,
• nincs nyilvános IP-címe,
• az Ethernet-portot csak az üzembe helyezés során használják,
• a laptopot kizárólag a szerviz csatlakoztatja,
• a kommunikáció kizárólag a vezérlőrendszeren belül zajlik,
• az ügyfél megígérte, hogy a gépet soha nem csatlakoztatja az internethez.

A CRA nemcsak a használati útmutatóban alapvetőként leírt használatot fedi le, hanem az ésszerűen előre látható használatot is. Ezért egy szervizport attól még nem szűnik meg adatot továbbítani, hogy a rajzon odaírták mellé: „SERVICE ONLY”.

A Bizottság 2026. július 27-i iránymutatása ugyanakkor fontos különbségtételt vezet be.

Nem minden vezeték és nem minden villamos jel minősül adatkapcsolatnak.

Ha egy jel kizárólag egy adott funkció bekapcsolására, kikapcsolására vagy tápellátására szolgál, és nem továbbít digitálisan kódolt információt, akkor önmagában két villamos állapot megléte még nem elegendő ahhoz, hogy adatkapcsolatnak tekintsük.

Egy gomb, amely feszültséget ad a mágneskapcsoló tekercsére, attól még nem válik digitális interfésszé, hogy az állapota leírható nullaként vagy egyesként.

Hasonlóképpen, egy klasszikus végálláskapcsoló, amely relé-mágneskapcsolós áramkörbe van kötve, csak megszakíthatja vagy zárhatja az áramkört. Nem továbbít eszközazonosítót, folyamatértéket, diagnosztikai kódot, firmware-verziót vagy több információt tartalmazó telegramot.

De ha ugyanez az állapot intelligens eszközbe kerül, ott kódolják, buszon továbbítják, diagnosztikához kapcsolják, és a vevő információként értelmezi, akkor a helyzet már más.

A határ tehát nem az „online” és az „offline” gépek között húzódik.

Hanem az egyszerű vezérlőjel és a digitálisan kódolt információ cseréje között.

Ezért a gyakorlatban egy olyan gépnek, amely kizárólag az adatkapcsolat hiánya miatt maradna a CRA hatályán kívül, inkább egy klasszikus, nyomógombokból, végálláskapcsolókból, relékből és mágneskapcsolókból álló rendszerre kellene hasonlítania, mint egy korszerű, TIA Portalban megnyitható projektre.

Ez természetesen nem a mágneskapcsolókra vonatkozó törvényi kivétel.

Lehet egyszerű gépet építeni PLC-vel, amely részletes elemzés után nem felel meg a hatályi kritériumnak. És egy mágneskapcsolós rendszerhez is hozzá lehet adni digitális szabályozót, szervizinterfészt vagy kommunikációs modult, amellyel pontosan a határ másik oldalára kerülünk.

Az alkatrész neve nem dönti el a kérdést.

Az számít, hogy a termék ténylegesen mit csinál, és mivel cserél adatot.

Ezért mielőtt válaszolnánk arra a kérdésre, hogy egy adott gépre vonatkozik-e a CRA, meg kell határozni:

• hol húzódik az értékelt termék határa,
• mely eszközök és szoftverelemek tartoznak bele,
• milyen fizikai és logikai interfészekkel rendelkezik,
• milyen információkat továbbítanak ezeken keresztül,
• mely kapcsolatok közvetlenek, és melyek valamilyen nagyobb rendszeren keresztül valósulnak meg,
• melyek fordulnak elő normál működés, üzembe helyezés, diagnosztika, frissítés vagy szerviz során,
• milyen használati módok ésszerűen előre láthatók, még akkor is, ha a gyártó inkább nem számolna velük.

Amíg ezekre a kérdésekre nem válaszolunk, nem tudjuk, hogy a gép valóban kívül marad-e a CRA hatályán.

Legfeljebb van egy kényelmes mondatunk:

„A gép nincs csatlakoztatva az internethez.”

Csakhogy ez válasz egy olyan kérdésre, amelyet a CRA nem tesz fel.

A PROFINET nem internet. A CRA szempontjából egyáltalán nem is kell annak lennie.

2. A kiberbiztonság nem terjed át PROFINET-en

Sok projektben a gép megfelelőségének kérdése már a beszerzési szakaszban felmerül.

PLC egy elismert gyártótól.
HMI aktuális firmware-rel.
Menedzselhető switch.
Ipari router VPN-nel.
Hajtások biztonsági funkciókkal.
Safety PLC megfelelő tanúsítvánnyal.

Minden eszközhöz megfelelőségi nyilatkozat, használati útmutató és néhány dokumentum a „secure”, „encrypted” és „defence in depth” kifejezésekkel.

A kapcsolási rajzon minden professzionálisnak tűnik.

Csakhogy ebből még mindig nem derül ki, hogy a teljes gép kiberbiztonsági szempontból valóban biztonságos-e.

Mert a kiberbiztonság nem „megy át” PROFINET-en.

Ez kicsit olyan, mint az ajtózár esete:
lehet minden szobán nagyon jó zár, tanúsított, bevizsgált, kiváló dokumentációval és „secure” hologrammal, de ez még mindig nem garantálja a biztonságot, ha valaki a bejárati ajtót tárva-nyitva hagyta, „mert így gyorsabb volt az üzembe helyezésnél”.

És pontosan ugyanez történik itt is: az alkatrészek lehetnek mintaszerűek, a rendszer mégis lehet… kreatívan nyitott.

A PLC nem „adja tovább” a biztonságot a HMI-nek.
A tűzfal nem „javítja ki” az alkalmazási logikát.
A switch nem „rendezi el” a felhasználói hozzáféréseket.
És attól, hogy minden elem rendelkezik tanúsítvánnyal, a teljes gép még lehet egyetlen nagy, udvariasan dokumentált sérülékenység.

A PROFINET adatot továbbít.

Felelősséget nem továbbít.
És sajnos a józan észt sem.

A CRA egyaránt kiterjed a teljes termékekre és a külön forgalomba hozott komponensekre. Ez azt jelenti, hogy a vezérlő, a kezelőpanel vagy a kommunikációs modul külön is értékelhető. A gép gyártójának azonban továbbra is igazolnia kell, hogy az egész rendszer biztonságosan működik az ügyfélnél kialakított valós konfigurációban — vagyis abban a változatban, amelyről valaki azt mondja: „ehhez már biztosan senki nem nyúlt hozzá… ugye?”.

És itt jelenik meg a leggyakoribb hiba.

Pontosan ugyanaz a mechanizmus ez, amelyet évek óta ismerünk a gépbiztonság területéről.

A fényfüggöny PL e szintű.
A Safety PLC SIL 3 szintű.
A hajtás rendelkezik STO funkcióval.

Ez azt jelenti, hogy az egész gép automatikusan ugyanezen a szinten van?

Ahogy az sem garantálja a teljes szerkezet stabilitását, hogy az állványzat minden egyes eleme megfelel a biztonsági szabványoknak.

Nem.

Mert továbbra is ellenőrizni kell, hogyan működik mindez együtt — vagyis azt a kevésbé népszerű „rendszerszintű gondolkodás” nevű lépést, amelyhez sajnos nincs „auto-certify” gomb.

A kiberbiztonságban pontosan ugyanez a helyzet.

Lehetnek „biztonságos” elemeid, de a gyakorlatban:

• az operátor több adatot lát és módosíthat, mint amennyire ténylegesen szüksége van, mert „így volt kényelmesebb”,
• ugyanaz a szervizjelszó működik minden gépen, mert „a szerviz úgyis tudja, mit csinál”,
• a szervizport „biztos, ami biztos” alapon elérhető, vagyis gyakorlatilag bármilyen esetre,
• a távoli hozzáférés az egész hálózatra kiterjed, mert valaki egyszer azt mondta, hogy „ez csak diagnosztika”,
• a frissítések ellenőrzés nélkül feltölthetők, mert „eddig soha semmi nem romlott el”,
• az eszközök korlátozás nélkül „megbíznak egymásban”, mert a bizalom olcsóbb, mint a szegmentálás,
• az integráció pedig abból indul ki, hogy senki sem hibázik soha, ami — ahogy a történelem mutatja — a mérnöki gyakorlat egyik legoptimistább feltételezése.

Minden egyes elem külön-külön lehet rendben.

De a rendszer egésze ezekből a helyes elemekből is képes olyasmit felépíteni, ami működik… csak nem feltétlenül úgy, ahogyan eredetileg tervezték.

És ez a lényeg: a kockázat nem az eszközökben van, hanem azok összekapcsolásában, konfigurációjában és a legendás „ideiglenesen nyitva hagyott” hozzáférésben.

A CRA a gép gyártójától többet követel meg annál, mint hogy nyilatkozatokat gyűjtsön, mintha trófeák lennének. Azt követeli meg, hogy ellenőrizze: a komponensekből összeállított megoldás egészként is biztonságos maradt-e — nem csak azt, hogy „jól mutat a megfelelőségi táblázatban”.

A gyakorlatban ez egyszerű, üzleti szempontú kérdéseket jelent:

• minden felhasználó csak ahhoz a hozzáféréshez jut-e, amire valóban szüksége van, és nem azért, mert „hátha egyszer még jól jön”,
• a távoli hozzáférés a minimálisan szükséges mértékre van-e korlátozva, vagy inkább a maximális kényelemre,
• a szerviznek nincs-e „teljes joga mindenhol”, csak azért, mert valaki úgy gondolta, hogy így egyszerűbb az élet,
• a hálózat nem egyetlen közös felületként működik-e, mert a szegmentálás „bonyolítja a projektet”,
• a frissítések ellenőrzötten történnek-e, vagy inkább „feltöltjük, aztán reménykedünk”,
• gyorsan azonosítható-e, hogy mely gépek érintettek, vagy inkább „majd az incidens után megnézzük”,
• egy elem hibája nem nyitja-e meg az egész rendszert, mert „így sikerült az integráció”.

Ezek nem technikai kérdések „a nehéz dolgokkal foglalkozó mérnököknek”.

Ezek üzleti kockázati kérdések: leállások, költségek, felelősség, és az a kis részlet, hogy a termelésnek azért működnie kell.

Ezért nem elég azt mondani:

„minden komponens megfelel”

Mert ez továbbra sem válaszolja meg a kérdést:

az egész gép biztonságos-e a valós használat során, vagy csak a projektfelülvizsgálati PowerPointban?

A beszállítói nyilatkozat fontos.

De csak egyetlen elemre vonatkozik — arra, amelyet éppen laboratóriumi körülmények között vizsgáltak, nem pedig olyan környezetben, mint „valahol a csarnokban, VPN-nel, USB-vel és időnyomás alatt”.

Nem terjed ki arra, hogyan használták.
Nem terjed ki a konfigurációra.
Nem terjed ki az integrációra.
Nem terjed ki azokra a döntésekre, amelyeket „gyorsan, az üzembe helyezés közben hoztak meg, mert a vevő várt”.
Nem terjed ki arra sem, mi történik évek üzemeltetése után, amikor már senki sem emlékszik, miért maradt valami „ideiglenesen nyitva”.

Ezért az értékelés nem érhet véget az eszközlista áttekintésénél.

A rendszert egészként kell vizsgálni:

• kinek van hozzáférése és miért (nem pedig azért, mert „mindig is volt”),
• mi az, amire valóban szükség van, és mi az, amit csak „ott hagytak, mert nem zavart”,
• hol kerülhetnek ki az adatok az ellenőrzés alól, mert valaki úgy vélte, hogy „ez csak diagnosztika”,
• mi történik akkor, ha valaki jogszerű hozzáférést jogellenes módon használ fel (vagyis pontosan úgy, ahogyan a támadások működnek),
• milyen gyorsan lehet reagálni, ha probléma merül fel, és nem csak „a negyedéves felülvizsgálat után”.

Amíg ezekre a kérdésekre nincs válasz, addig csak egy nagyon korrekt komponenskészletünk van.

Még nincs biztonságos gépünk.

A komponensek megfelelősége nem hozza létre automatikusan a rendszer megfelelőségét. A gép megfelelőségét meg kell tervezni, ellenőrizni kell, és — ami a legnehezebb — fenn is kell tartani annak a csábításnak ellenére, hogy „inkább ne nyúljunk hozzá, mert működik”.

3. Ne írd hozzá a kibertámadást a veszélyek listájához. A két elemzést a megfelelő ponton kell összekapcsolni

A gépiparban a kiberbiztonsági kockázat formális elemzése továbbra is inkább kivétel, mint a projekt szokásos része.

Leggyakrabban van ipari router.

Van VPN.

Van jelszó a PLC-hez.

Néha van menedzselhető switch is, amelyet később már senki sem menedzsel.

Az ambiciózusabb változatban a gyártó kap a beszállítótól egy „defence in depth” prezentációt, és úgy tekinti, hogy ezzel a teljes gép kiberbiztonsági kockázatelemzése le is zárult.

Pedig nem zárult le.

Vett néhány technikai védelmi intézkedést.

Ez még nem elemzés.

Ezért nincs értelme úgy leírni a problémát, mintha minden projektben két professzionális értékelés készülne — az egyik az ISO 12100 szerinti kockázatértékelés, a másik pedig a kiberbiztonságra vonatkozó értékelés —, amelyeket csak véletlenül nem kapcsoltak össze egymással.

Leggyakrabban egy készül.

A gép kockázatértékelése.

A termék kiberbiztonsági elemzése viszont sokszor egyáltalán nem készül el.

A gép ISO 12100 szerinti kockázatértékelése nem abból áll, hogy egy táblázatba beírjuk:

érzékelőhiba → váratlan mozgás → összezúzás.

Ez lehet egy konkrét forgatókönyv részlete, de nem ez a kiindulópont.

Először a gép korlátait kell meghatározni.

Mi a rendeltetése?

Melyek az életciklus fázisai?

Kik fogják használni?

Milyen feladatokat végeznek a szállítás, összeszerelés, üzembe helyezés, gyártás, beállítás, tisztítás, elakadáselhárítás, karbantartás, diagnosztika és szétszerelés során?

Milyen üzemmódokban működhet a gép?

Hol tartózkodik az ember ezeknek a műveleteknek az egyes szakaszaiban?

A gép mely részei maradnak ilyenkor feszültség alatt, nyomás alatt, terhelés alatt vagy mozgásban?

Mely használati módok nem felelnek meg az utasításnak, de ésszerűen továbbra is előre láthatók?

Csak ezután lehet egy adott feladathoz vagy művelethez azonosítani többek között:

• a veszélyforrást,
• a veszély típusát,
• a veszélyzónát,
• az érintett személyt,
• a veszélyhelyzetet,
• a veszélyes eseményt, ha az adott forgatókönyvben előfordul,
• a lehetséges következményeket és a sérülés jellegét.

Így néz ki a gép kockázatelemzése.

Nem az alkatrészből indulunk ki.

Hanem abból az emberből, aki egy meghatározott feladatot végez egy adott állapotban lévő gépen. Az ISO 12100 pontosan ezt a módszertant határozza meg a veszélyek azonosítására, valamint a kockázat becslésére és értékelésére a gép életciklusának megfelelő fázisaiban.

Vegyünk egy egyszerű példát.

A kezelő eltávolít egy beszorult munkadarabot a raklapozó cella belsejéből.

Tehát adott:

Feladat: az elakadás megszüntetése.

Használati fázis: üzemeltetés, beavatkozás a folyamat leállítása után.

Üzemmód: kézi vagy szerviz üzemmód.

Érintett személy: kezelő vagy karbantartó munkatárs.

Veszélyzóna: a cella belső tere, különösen a megfogó, a munkadarab és a gépszerkezet közötti tér.

Veszélyforrás: a robot, a lineáris tengely vagy a pneumatikus megfogó mechanikai energiája.

Veszélyhelyzet: az ember a veszélyzónában tartózkodik, miközben a mozgás végrehajtása továbbra is lehetséges.

Veszélyes esemény: a tengely váratlan mozgása, a megfogó záródása vagy a tárolt energia felszabadulása.

Lehetséges következmény: ütés, összezúzás, csonttörés vagy amputáció.

Csak most lehet a kockázatot értékelni és meghatározni a csökkentésére szolgáló intézkedéseket.

Szükség lehet védőburkolat-reteszelésre.

Szükség lehet biztonságos leállításra.

Szükség lehet a váratlan elindulás megelőzésére.

Előfordulhat, hogy a pneumatikus energiát le kell vezetni.

Az is lehet, hogy kézi üzemmódban a mozgás csak engedélyező készülékkel és biztonságosan korlátozott sebességgel történhet.

Ez továbbra is a gép klasszikus kockázatértékelése.

Hol jelenik meg ebben a kiberbiztonság?

Nem új tételként a mechanikai, villamos és hőveszélyek mellett.

„A hacker” nem mechanikai veszélyforrás

Ha az ISO 12100 táblázatába felveszünk egy ilyen sort:

Veszély: kibertámadás

az nem sokat ad hozzá.

A kibertámadás nem forgó tengely, nem éles perem, nem magas hőmérséklet és nem pneumatikus energia.

Nem külön veszélyzóna sem.

A kezelő nem egy CVE-sérülékenységtől szenved összezúzást.

Hanem a gép valamely elemétől, amely mozgást végzett, miközben az ember nem megfelelő helyen tartózkodott.

A kibertámadás viszont megváltoztathatja a vezérlőrendszer állapotát, az adatokat, a programot, a konfigurációt vagy a védelmi intézkedés működését.

Így tehát lehet:

• a veszélyes esemény oka,
• egy további út, amely veszélyhelyzethez vezet,
• a kockázatcsökkentő intézkedés hatékonyságának elvesztéséhez vezető ok,
• vagy a biztonsági funkció tervezése során elfogadott feltételezések megkerülésének módja.

És ez a valódi kapcsolódási pont.

Nem a veszélyek listája.

Hanem a gép viselkedése.

A kiberbiztonsági elemzést külön kell elkészíteni

Egy gép vagy automatizálási rendszer esetében a kiberbiztonsági elemzés felépítése más lesz, mint az ISO 12100 szerinti kockázatértékelésé.

Ipari automatizálási rendszerhez a legtermészetesebb keretet az IEC 62443-3-2 adja.

A szabvány többek között megköveteli:

• az elemzés alá vont rendszer, vagyis a SUC meghatározását,
• a rendszer zónákra és kommunikációs csatornákra bontását,
• az egyes zónákra és csatornákra vonatkozó kockázatértékelést,
• a célzott biztonsági szintek, azaz az SL-T meghatározását,
• a biztonsági követelmények dokumentálását.

Ez teljesen más kiindulópont, mint az ISO 12100 esetében.

Az IEC 62443-ban többek között ezeket a kérdéseket tesszük fel:

Mi tartozik pontosan az elemzett rendszerhez?

Milyen eszközöket kell védeni?

Milyen berendezések, alkalmazások és interfészek találhatók a rendszerben?

Mely elemeknek kell ugyanabba a zónába tartozniuk?

Hogyan zajlik a kommunikáció a zónák között?

Ki férhet hozzá?

Melyik helyről?

Milyen interfészen keresztül?

Milyen sérülékenységek használhatók ki?

Mely adatok, funkciók vagy komponensek módosíthatók?

Milyen útvonalon juthat el a támadó a szervizroutertől a PLC-hez, a HMI-hez, a hajtáshoz vagy a mérnöki állomáshoz?

Milyen következményekkel jár a bizalmasság, az integritás vagy a rendelkezésre állás elvesztése?

Milyen védelmi intézkedésekre van szükség?

A termék biztonságos fejlesztési folyamatához és magukra a komponensekre vonatkozó követelmények szempontjából a sorozat más részei is fontosak, különösen az IEC 62443-4-1 és az IEC 62443-4-2. Az IEC 62443-3-3 ezzel szemben rendszerszinten rendezi a műszaki biztonsági követelményeket.

A CRA ma még nem írja elő a gyártónak, hogy az elemzés borítójára azt írja: „IEC 62443 szerint készült”.

Az IEC 62443 ugyanakkor nem helyettesíti a CRA követelményeinek való megfelelés igazolását sem.

Ipari automatizálási rendszer esetén azonban sokkal logikusabb viszonyítási pont, mint néhány hackertámadási forgatókönyv utólagos beillesztése egy ISO 12100 szerinti kockázatértékelési táblázatba.

Mert a két módszertan más-más kérdésekre ad választ.

ISO 12100:

Melyik feladat során, hol, milyen forrásból és milyen esemény következtében érheti az embert károsodás?

IEC 62443:

Ki, milyen úton és mely sérülékenység kihasználásával tud hatni a rendszerre, annak adataira vagy funkcióira?

Csak ezután kell ellenőrizni, hogy a második elemzésből kapott válasz módosítja-e az elsőből ismert forgatókönyvet.

Ugyanaz a forgatókönyv, két különböző elemzés

Térjünk vissza ahhoz a kezelőhöz, aki az elakadt alkatrészt távolítja el.

Az ISO 12100 szerinti elemzés kimutatta, hogy az ember olyan zónába lép be, ahol a robot vagy a megfogó mozgása összezúzhatja.

A kockázatcsökkentő intézkedés egy reteszelt védőburkolat, egy biztonságos leállítási funkció, valamint egy helyi reset, amelyet a veszélyzónán kívül helyeztek el.

Most elvégezzük a rendszer kiberbiztonsági elemzését.

Azonosítjuk a következőket:

• a távoli szervizeléshez használt router,
• a szervizfiók,
• a mérnöki laptop,
• a HMI,
• a szabványos PLC,
• a safety PLC,
• a hajtások,
• a programozási interfész,
• a PROFINET hálózat és a PROFIsafe kommunikáció,
• a programfeltöltési és konfigurációs mechanizmusok.

A következő forgatókönyvet vizsgáljuk:

A szervizfiók kompromittálása lehetővé teszi a távoli hozzáférést a szabványos PLC-hez, és mozgásparancs küldését akkor, amikor ember tartózkodik a cellában.

Ez a forgatókönyv vezet-e veszélyes eseményhez?

Erre nem lehet pusztán a PLC feletti irányítás átvételének tényéből válaszolni.

Meg kell vizsgálni a biztonsági funkció architektúráját.

Ha a burkolat nyitását a safety PLC felügyeli, a funkció biztonságosan lekapcsolja a hajtások nyomatékát, a reset kizárólag helyben végezhető el, és a szabványos PLC a biztonsági funkció állapotától függetlenül nem tudja visszaállítani a mozgást, akkor a szabványos vezérlő átvétele leállíthatja a termelést vagy károsíthatja a folyamatot.

De nyitott burkolat mellett nem szabad mozgást okoznia.

Ilyenkor a kiberelemzés támadást mutat ki.

A gép kockázatértékelése mechanikai veszélyt mutat ki.

A helyesen megtervezett biztonsági funkció azonban megszakítja a kettő közötti kapcsolatot.

És most nézzük a második változatot.

A szervizmód kiválasztása a hagyományos HMI-ről történik.

A korlátozott sebesség értéke a szabványos PLC-ből származik.

A távoli szervizes resetet tud végrehajtani.

Ugyanaz a mérnöki fiók lehetővé teszi a szabványos program és a safety konfiguráció módosítását.

A safety program másolata nincs konkrét gépverzióhoz rendelve.

Beavatkozás után senki sem ellenőrzi az ellenőrzőösszeget.

A hajtás paraméterei távolról módosíthatók.

Ebben az architektúrában a fiók kompromittálása már nem csupán a bizalmasság elvesztését vagy rövid leállást jelent.

Megváltoztathatja azokat a feltételeket, amelyekre a kockázatcsökkentés épült.

A következőkhöz vezethet:

• nem megfelelő üzemmód kiválasztásához,
• a biztonságos mozgás paraméterének módosításához,
• jogosulatlan resethez,
• nem jóváhagyott konfiguráció feltöltéséhez,
• vagy annak a funkciónak a gyengítéséhez, amelynek a váratlan elindulást kellett volna megakadályoznia.

És ekkor a kiberforgatókönyvet össze kell kapcsolni a gépbiztonság konkrét forgatókönyvével:

elakadás megszüntetésének feladata → ember a veszélyzónában → a vezérlőrendszer vagy a védelmi funkció jogosulatlan módosítása → váratlan mozgás → összezúzás.

A veszélyforrás nem változott meg.

Továbbra is a gép mechanikai energiája az.

A veszélyzóna sem változott meg.

Továbbra is a cellán belül található.

A lehetséges következmény sem változott meg.

Továbbra is a kezelő sérülése az.

Az változott meg, hogy milyen út vezet a veszélyes eseményhez.

Nem minden sérülékenység kerül be az ISO 12100 szerinti elemzésbe

Ez a megkülönböztetés ugyanilyen fontos.

Tegyük fel, hogy a HMI egyik sérülékenysége lehetővé teszi a korábbi gyártási adatok kiolvasását.

Ez a CRA szempontjából lényeges probléma lehet.

Sértheti az adatok bizalmasságát.

Frissítést, hatásvizsgálatot, a felhasználókat érintő intézkedéseket, meghatározott körülmények között pedig jelentéstételt is szükségessé tehet.

De ha nincs hatással a gép viselkedésére, nem módosít védelmi intézkedést, és nem vezethet veszélyhelyzethez, akkor nincs értelme beleerőltetni az ISO 12100 szerinti kockázatértékelésbe.

Hasonlóképpen, egy olyan támadás, amely kizárólag a gyártási jelentések elérhetetlenségét okozza, üzleti problémát és a CRA-nak való megfelelés szempontjából is gondot jelenthet.

Ugyanakkor nem feltétlenül jelent kockázatot a kezelő számára.

Másfelől egy ártalmatlannak tűnő lehetőség egyetlen beállított érték módosítására csekély jelentőségű lehet az adatok bizalmassága szempontjából, ugyanakkor óriási jelentősége lehet a fizikai biztonságra nézve.

Például akkor, ha ez az érték a következőt határozza meg:

• a tengely maximális sebességét,
• a leszorító erőt,
• a folyamat hőmérsékletét,
• a nyomást,
• a megállási pozíciót,
• a szelep nyitási idejét,
• vagy a nyitott védőburkolat melletti működés megengedett határértékét.

Ezért a kiberfenyegetést nem aszerint soroljuk be, hogy technikailag mennyire „komolyan hangzik”.

Azt vizsgáljuk, valójában mit tehet a géppel.

A gépekről szóló rendelet kikényszeríti ezt a kapcsolatot

Ez az összekapcsolás nem pusztán jó mérnöki gyakorlat.

A gépekről szóló rendelet III. mellékletének 1.2.1 pontja előírja, hogy a vezérlőrendszereket úgy kell megtervezni és kialakítani, hogy megelőzzék a veszélyhelyzetek kialakulását, beleértve a harmadik felek ésszerűen előre látható, rosszindulatú kísérleteinek következményeit is.

A CRA ezzel szemben arra mutat rá, hogy alapvető kiberbiztonsági követelményei többek között a gépekről szóló rendelet 1.1.9 és 1.2.1 követelményeinek való megfelelés igazolását is támogathatják.

Ez azonban nem történik meg automatikusan.

A gyártónak ezt az összefüggést a kockázatértékelés alapján kell igazolnia. A CRA szerinti megfelelőségértékelés és a gépekről szóló rendelet szerinti megfelelőségértékelés továbbra is különálló folyamat marad.

Vagyis nem elég elkészíteni:

• az ISO 12100 szerinti kockázatértékelést,
• az IEC 62443 szerinti elemzést,
• két külön jelentést,
• és abban bízni, hogy a szabványszámok hasonlósága majd auditnyomot teremt közöttük.

Kapcsolódásra van szükség.

Minden lényeges kiberforgatókönyv esetében meg kell határozni:

1. mely elem vagy funkció vehető át vagy módosítható,
2. ez milyen gépviselkedést válthat ki,
3. ez a viselkedés vezet-e veszélyhelyzethez vagy veszélyes eseményhez,
4. mely feladatot és mely veszélyzónát érinti,
5. milyen lehetséges következményt azonosítottak az ISO 12100 szerinti értékelésben,
6. mely kockázatcsökkentő intézkedésnek kell megszakítania a forgatókönyv kibontakozását,
7. és ez az intézkedés hatékony marad-e a megtámadott elem átvétele után is.

Ez az utolsó pont a legfontosabb.

Mert ha a támadás és a védelem ugyanattól függ:

• ugyanattól a vezérlőtől,
• ugyanattól a felhasználói fióktól,
• ugyanattól a hálózattól,
• ugyanattól a mérnöki munkaállomástól,
• vagy ugyanattól a programtól,

akkor lehet, hogy nincs két független védelmi rétegünk.

Hanem egyetlen rétegünk van, amelyet két dokumentum ír le.

Ezért nincs szükségünk egyetlen hatalmas táblázatra ezzel a címmel:

„safety & cybersecurity kockázatértékelés”.

Két helyes, a megfelelő módszerekkel elvégzett elemzésre van szükségünk, valamint egy ellenőrzött kapcsolódási pontra közöttük.

Az ISO 12100 feladata, hogy leírja az embert, a feladatot, a veszélyforrást, a zónát, a veszélyhelyzetet, a veszélyes eseményt és a lehetséges kárt.

Az IEC 62443 feladata, hogy segítsen leírni a rendszert, annak zónáit, kommunikációs csatornáit, erőforrásait, fenyegetéseit, sérülékenységeit, támadási útvonalait és a szükséges védelmi intézkedéseket.

A gyártónak pedig azt kell igazolnia, hogy a második elemzésben szereplő forgatókönyv kiválthatja-e az elsőben szereplő forgatókönyvet, vagy megszüntetheti-e annak az intézkedésnek a hatékonyságát, amelynek azt kellett volna megállítania.

A kibertámadásnak nem kell új veszélyt létrehoznia. Elég, ha új utat nyit egy régi balesethez.

4. A FAT előtti pentest pillanatfelvétel. A CRA filmet követel meg

Sok projektben a kiberbiztonság két héttel a FAT előtt kerül elő.

Megrendelnek egy pentestet.

Elkészül a jelentés.

A kritikus sérülékenységeket javítják, a közepeseket elfogadják, a dokumentum pedig bekerül a projektmappába.

A gép kiberbiztonsági szempontból rendben van.

A következő keddig.

A pentest nagyon értékes ellenőrzési elem lehet. Ugyanakkor egy adott termékverzió állapotát mutatja meg, egy adott konfigurációban és meghatározott tesztforgatókönyvek alkalmazásával.

Arra a kérdésre viszont nem ad választ, hogy a gyártó később mit fog tenni.

A CRA pedig a termék teljes életciklusára vonatkozik. A kiberbiztonsági kockázatértékelésnek hatással kell lennie a termék tervezésére, kialakítására, fejlesztésére, gyártására, szállítására és karbantartására. Piacra helyezés után a gyártónak a sérülékenységeket a vállalt támogatási időszak alatt kezelnie kell.

Térjünk vissza a zöldségcsomagoló géphez.

A gép átment a FAT-en.

A pentest nem tárt fel kritikus sérülékenységeket.

Nyolc hónappal később a szervizrouter gyártója közzétesz egy tájékoztatást egy olyan sérülékenységről, amely lehetővé teszi az eszköz átvételét.

És itt kezdődik az igazi munka.

Mely leszállított gépekben van ez a routermodell?

Az egyes példányokba a firmware melyik verzióját telepítették?

Aktív-e a távoli hozzáférés?

A sérülékenység kihasználható-e a tényleges konfigurációban?

A router átvétele kizárólag a diagnosztikához ad hozzáférést, vagy a HMI-hez, a PLC-hez, a hajtásokhoz és a safety PLC-hez is?

Csak adatolvasás lehetséges, vagy a program, illetve a paraméterek módosítása is?

A támadás hatással lehet-e a biztonsági funkcióra?

A beszállító kiadott javítást?

A router frissítése megváltoztatja-e a tanúsítványokat, a kommunikációs szabályokat vagy az alagút felépítésének módját?

Szükséges-e a frissítés után ismét ellenőrizni a távoli szervizelést, a kommunikációt és a biztonsági funkciók egy részét?

Mely ügyfeleket kell értesíteni?

És vajon a helyzet megfelel-e az aktívan kihasznált sérülékenység vagy a súlyos incidens bejelentési feltételeinek?

A FAT előtti pentesztről készült jelentés ezek közül egyik kérdésre sem ad választ.

Olyan gépet ír le, amely már nem létezik.

Mert a vizsgálat óta megváltoztak a szoftververziók, a konfigurációk, a felhasználói környezet és a sérülékenységekkel kapcsolatos ismeretek.

Ezért a gyártónak nem csupán egy tesztre, hanem egy folyamatra van szüksége:

• az egyes leszállított példányokban használt hardver-, firmware- és szoftververziók azonosítására,
• a sérülékenységekre vonatkozó információk nyomon követésére,
• azok kihasználhatóságának értékelésére a tényleges architektúrában,
• a folyamatra és a gép biztonságára gyakorolt lehetséges hatások ellenőrzésére,
• a frissítések előkészítésére és tesztelésére,
• a felhasználók tájékoztatására,
• a meghozott döntések dokumentálására,
• az előírt bejelentések kezelésére.

2026. szeptember 11-től a gyártók kötelesek jelenteni a digitális elemeket tartalmazó termékek biztonságát érintő, aktívan kihasznált sérülékenységeket és a súlyos incidenseket. Az előzetes figyelmeztetést 24 órán belül, a teljes bejelentést pedig 72 órán belül kell megtenni.

Ez azt jelenti, hogy a probléma észlelése után már nem lesz idő elkezdeni a keresgélést:

„Ki gyártotta egyáltalán ezt a routert, és hol van azoknak a gépeknek a listája, amelyekbe beépítettük?”

Az IEC 62443-4-1 jól mutatja az egyszeri termékvédelem és a biztonságos termékfejlesztési életciklus közötti különbséget. Nemcsak a tervezést és az ellenőrzést foglalja magában, hanem a hibák, a javítások és a termék életciklusának végének kezelését is.

A FAT tehát lezárhat egy projektfázist.

De nem zárja le a termék életciklusát.

Nem zárja le a támogatási időszakot.

Nem vet véget a sérülékenységek nyomon követésének.

És nem jelenti azt sem, hogy az átvétel napján érvényes konfiguráció a következő tizenöt évre változatlanul rögzül.

A gép hosszú időn át csomagolhat zöldséget a szupermarketek számára.

A gyártó azonban nem csomagolhatja be a kiberbiztonságát a használati útmutató mellé, nem fóliázhatja le, és nem tekintheti úgy, hogy azt egyszer s mindenkorra leszállította.

A penteszt lezárhat egy pontot a FAT-listán. A CRA viszont egy olyan folyamatot nyit meg, amely a termék támogatási időszakának végéig tart.