OT-kiberbiztonsági pilot – miről fog szólni ez a sorozat

Címkék: #NIS2
2026-07-16

Az elmúlt években rengeteg gyártóüzemben jártunk, és sok termelési rendszert láttunk belülről. Az egyik visszatérő kép a következő: egy megbízhatóan működő PLC, mellette egy teljesen jogos üzleti igény – „legyen látható a termelési adat az IT-ben” –, és a kettő közé húzott kábel, amelyről utólag már senki nem tudja pontosan megmondani, mit is enged meg valójában.

Ezek a megoldások általában nem rossz szándékból születnek. Egyszerűen a leggyorsabb utat választották, és a biztonsági, dokumentációs és auditálhatósági kérdések akkor még nem tűntek sürgősnek. Ma viszont – a NIS2 nyomán bevezetett hazai kiberbiztonsági szabályozás mellett – ezek a kérdések már nem halogathatók.

Ebben a cikksorozatban nem elméletet írunk le. Fogtunk egy kicsi, valós mintarendszert, és pilot projektként végigvittünk rajta egy teljes OT-kiberbiztonsági felkészítést: a felméréstől a kockázatértékelésen, az architektúratervezésen, a megvalósításon és a rendszer szigorításán át egészen a validációig és az audit-előkészítésig. A sorozatban lépésről lépésre megmutatjuk, hogyan gondolkodunk az egyes állomásokon.

Egy fontos kiindulási pont: nincs egyetlen helyes út

Mielőtt bármibe belekezdenénk, tisztázzunk valamit, ami a teljes sorozat alapja. Az OT- és IT-rendszerek biztonságos összekötésének nincs egyetlen, mindenkire érvényes receptje. Ugyanazt a célt sokféle, egyaránt védhető módon el lehet érni: más architektúrával, más eszközökkel, más hangsúlyokkal – a rendszer méretétől, a kockázatoktól, a meglévő infrastruktúrától és számos más tényezőtől függően.

Amit ebben a sorozatban bemutatunk, az tehát a sok lehetséges megközelítés közül az egyik – az, amelyet ennél a konkrét mintarendszernél, a konkrét feltételek mellett választottunk és megindokoltunk. Nem azt állítjuk, hogy „így kell csinálni”. Azt mutatjuk meg, hogy hogyan lehet felelősen, kockázatalapon és bizonyíthatóan végiggondolni egy ilyen feladatot. Egy másik mérnök más döntéseket hozhat – és az is helyes lehet, ha a saját kontextusában ugyanígy végig van gondolva és dokumentálva.

Honnan hová jutunk el?

A kiindulópont az a bizonyos „nyitott kábel”: egy termelési rendszer, amelynek az adatai kellenek az IT-nek, de amelynél a hozzáférés nem kontrollált és nem dokumentált. A végpont egy olyan elrendezés, amelyben:

  • a termelési oldal a saját, védett zónájában marad;
  • az adat kizárólag olvasásra, egyirányban, kontrolláltan jut ki;
  • az IT-hálózatot alapból nem megbízhatónak kezeljük;
  • és minden fontos állítást – például hogy „az IT nem tudja írni a PLC-t” – nem ígérettel, hanem teszttel és bizonyítékkal támasztunk alá.

A kettő között pedig ott a munka: a felmérés, a kockázati kép felállítása, több architektúra mérlegelése, a megvalósítás, a szigorítás és a validáció. A sorozat éppen ezt az utat járja végig.

Kinek szól ez a sorozat?

Elsősorban azoknak a vezetőknek, műszaki és IT-felelősöknek, üzemeltetőknek és compliance-szakembereknek, akik a saját gyártásukban szembesülnek ezzel a kérdéssel. Nem az a célunk, hogy „házilagos” megvalósítási útmutatót adjunk – a konkrét mérnöki lépéseket tudatosan nem részletezzük. A cél, hogy egy döntéshozó a sorozat végén lássa, mit jelent valójában egy ilyen felkészítés: mennyi mérlegelést, milyen döntéseket és mennyi bizonyítékot igényel.

Kezdjük is

A következő részben ott folytatjuk, ahol a legtöbb probléma kezdődik: annál a bizonyos közvetlen kábelnél az IT és a PLC között. Megnézzük, miért tűnik jó ötletnek – és miért nem az.