adatbiztonsag-gyartasi-rendszerekben
Adatbiztonság és integráció

Adatbiztonság gyártási rendszerekben 7 lépésben

Egy gyártósor leállásának nem feltétlenül maga a géphiba az első jele. Elég lehet egy elérhetetlenné vált mérnöki munkaállomás, egy kieső MES szerver vagy egy rosszul kezelt távoli hozzáférés. Az adatbiztonság a gyártási rendszerekben ezért nem kizárólag informatikai kontrollkérdés: közvetlenül befolyásolja a termelési kapacitást, a minőségbiztosítás hitelességét és a kiszállítási képességet.

A probléma különösen érzékeny ott, ahol az ERP, a MES, a SCADA, a WMS és az ipari vezérlők adatai már összekapcsolódnak. Ez üzletileg értékes átláthatóságot ad, de a korábban elszigetelt üzemtechnológiai környezetet is jobban kiteszi hibáknak és támadásoknak. A cél nem az, hogy minden rendszert elzárjunk egymástól, hanem hogy a szükséges adatáramlás ellenőrizhető, helyreállítható és üzembiztos legyen. A gyártási rendszerek biztonsága ugyanis nem a teljes elszigetelést, hanem a kontrollált működést jelenti.

Miért más az adatbiztonság a gyártási rendszerekben?

Egy irodai rendszer biztonsági incidensénél gyakran az adatok bizalmassága az első kérdés. A termelésben a rendelkezésre állás sokszor legalább ilyen súlyú. Ha egy zsarolóvírus titkosítja a fájlkiszolgálót, a kár jelentős. Ha ugyanez megakadályozza a receptúrák elérését, a termelési utasítások kiadását vagy a gépek felügyeletét, percek alatt leállási és biztonsági kockázattá válhat. Ezért az ipari kiberbiztonságban a termelés folytonossága legalább olyan fontos szempont, mint az adatok védelme.

Az OT-környezetben – vagyis az üzemtechnológiában – ráadásul sok rendszer hosszú életciklusú. Ez az OT-biztonság szempontjából külön kihívást jelent, mert egy PLC, egy HMI vagy egy ipari PC akár tíz-tizenöt éve működik és nem feltétlenül frissíthető ugyanúgy, mint egy vállalati laptop. A frissítés termelési kiesést igényelhet, egy régi alkalmazás pedig nem biztos, hogy kompatibilis az új operációs rendszerrel. Emiatt a gyártásban nem mindig alkalmazható változtatás nélkül az az IT-környezetben megszokott gyakorlat, hogy minden frissítést azonnal telepíteni kell. Az OT-rendszereknél a javítás módját és időzítését a termelési és biztonsági kockázatok együttes mérlegelése alapján kell meghatározni.

Az adatbiztonság gyártási rendszerekben ezért kockázatalapú megközelítést igényel: előbb azt kell tisztázni, mely eszközök és adatkapcsolatok befolyásolják közvetlenül a biztonságos termelést, a minőséget vagy a szállítási határidőt. Ezután lehet eldönteni, hol indokolt a frissítés, hol célszerű hálózati elkülönítést alkalmazni, és hol kell inkább a hozzáférést szigorítani.

Hol keletkezik a valódi kitettség?

A legtöbb gyárban nem egyetlen látványos technikai hiba okozza a legnagyobb kockázatot. Gyakrabban több kisebb hiányosság kapcsolódik össze. Egy külső szervizes állandó távoli elérést kap, ugyanazt a felhasználót több műszakban használják, a mentések pedig ugyanazon a hálózaton maradnak, mint az éles rendszerek.

Kiemelt figyelmet érdemelnek az IT és OT közötti kapcsolódási pontok, amelyek az IT/OT biztonság egyik legfontosabb területét jelentik. Az ERP-ből a MES-be érkező gyártási rendelés, a SCADA-ból az adatgyűjtő platformra továbbított gépadat vagy a WMS és az automata raktár közötti integráció üzleti szempontból indokolt lehet. Minden ilyen kapcsolatnál azonban tisztázni kell, ki indít adatforgalmat, milyen adatok mozognak, milyen jogosultsággal, és mi történik kapcsolatkimaradás esetén.

Nem szabad megfeledkezni az adatintegritásról sem. Egy hibás vagy manipulált paraméter nem mindig állítja le a sort. Előfordulhat, hogy a gyártás folytatódik, csak éppen rossz címke kerül a termékre, eltér a receptúra, vagy hiányos lesz a visszakövethetőségi rekord. Ez különösen szabályozott iparágakban, illetve autóipari beszállítói láncokban okozhat aránytalanul nagy következményt.

Adatbiztonság gyártási rendszerekben: 7 gyakorlati lépés

Az adatbiztonság gyártási rendszerekben nem egyetlen IT beállítással javítható, ezért a fejlesztést érdemes nem egy nagy, kizárólag IT projektként, hanem fokozatos üzemképességi programként kezelni. A következő hét lépés jó kiindulópont lehet.

  1. Készítsenek valós eszköz- és kapcsolati leltárt. Ne csak a szerverek és laptopok szerepeljenek benne. Kerüljenek fel a PLC-k, HMI-k, ipari PC-k, hálózati eszközök, kamerák, mérlegek, adatgyűjtők és távoli karbantartási kapcsolatok is. Sok üzem csak egy incidens után szembesül azzal, hogy nem tudja pontosan, mi csatlakozik a hálózatára.
  2. Azonosítsák a kritikus termelési folyamatokat. Nem minden rendszer egyformán fontos. Egy gyártócella leállása, egy központi receptúrakezelő kiesése és egy nem kritikus riportkészítő alkalmazás eltérő üzleti hatással jár. A prioritásokat a leállási költség, a munkabiztonság, a minőségi következmény és a helyreállítási idő alapján érdemes felállítani.
  3. Válasszák szét érdemben az IT- és OT-hálózatot. Az ipari hálózatbiztonság egyik alapja, hogy egy irodai fertőzés ne tudjon akadálytalanul eljutni a termelési vezérlésekig. A hálózati szegmentáció nem egyszerűen külön VLAN-ok létrehozása. Az átjáróknál szabályozott, naplózott és a szükségesre korlátozott kommunikációra van szükség.
  4. Rendezzék a jogosultságokat és a távoli hozzáférést. A közös, jelszóval védett „karbantartó” fiók kényelmes, de incidens esetén nem visszakövethető. A dolgozóknak, rendszergazdáknak és külső partnereknek névre szóló hozzáférés kell, a munkájukhoz szükséges legkisebb jogosultsággal. A beszállítói távkapcsolat legyen időben korlátozott, jóváhagyott és naplózott.
  5. Teszteljék a mentések visszaállítását. A mentés megléte nem azonos a helyreállíthatósággal. A gyár számára az a kérdés, hogy egy kiesés után mennyi idő alatt áll vissza a MES, a receptúra-adatbázis, a SCADA konfiguráció vagy egy kritikus PLC-program. A kritikus mentések között legyen olyan, a termelési hálózattól megfelelően elkülönített vagy offline példány is, amelyhez egy hálózati fertőzés nem tud hozzáférni.
  6. Alakítsanak ki incidenskezelési forgatókönyvet műszaki és üzleti szereplőkkel. Egy kibertámadás idején nem elég az IT-t értesíteni. Tudnia kell a termelési vezetőnek, a minőségügynek, a karbantartásnak és az ügyvezetésnek is, ki dönt a biztonságos leállításról, hogyan történik az alternatív adatgyűjtés, és ki kommunikál a vevőkkel. Ezt asztali gyakorlatban is érdemes kipróbálni.
  7. Érvényesítsék a biztonsági szempontokat már minden új projekt tervezési szakaszában. Egy új MES, WMS, IIoT-platform vagy raktárautomatizálási projekt esetén a jogosultságkezelés, a naplózás, a mentés, az interfészek és a távoli támogatás feltételei már a specifikáció részét kell képezzék. Utólag beépíteni ezeket rendszerint drágább és konfliktusosabb.

A technológia önmagában kevés

A biztonsági fejlesztések gyakori hibája, hogy a vállalat megvesz egy eszközt, majd változatlanul hagyja a működési fegyelmet. Egy korszerű tűzfal sem oldja meg, ha a külső partnernek nincs egyértelmű hozzáférési folyamata, vagy ha a műszakvezető nem tudja, hova jelezze a gyanús rendellenességet.

A termelési és IT csapat együttműködése ezért alapfeltétel. Az IT pontosan érti a hálózati és hozzáférési kockázatokat, az operáció viszont azt tudja, melyik gép állhat le biztonságosan, melyik nem, és milyen manuális kerülőfolyamatok tarthatók fenn. Ha az egyik oldal a másik nélkül tervez, a végeredmény vagy túl kockázatos, vagy a gyakorlatban megkerülhető szabályrendszer lesz.

Érdemes a külső integrátorokat és gépszállítókat is partnerként kezelni, de szerződéses és műszaki elvárásokkal. Legyen egyértelmű, hogy ki frissít, ki fér hozzá a rendszerhez, milyen idő alatt reagál incidensnél, és milyen formában adja át a konfigurációs mentéseket, a dokumentációt, valamint a rendszergazdai ismereteket. A gyár ne maradjon kiszolgáltatott egyetlen személy vagy szolgáltató tudásának.

Miből látszik, hogy a fejlesztés üzletileg is működik?

Az adatbiztonsági beruházás eredményét nem célszerű kizárólag blokkolt támadások számával mérni. Sokkal beszédesebb, ha a vállalat tudja a kritikus rendszerek helyreállítási célidejét, rendszeresen teszteli a mentéseket, átlátja a külső hozzáféréseket, és csökkenti azokat a pontokat, ahol egyetlen hiba teljes termelési kiesést okozhat.

A jó állapot nem azt jelenti, hogy incidens biztosan nem történik. Azt jelenti, hogy a szervezet felismeri a rendellenességet, képes korlátozni a hatását, és a termelést kontrolláltan indítja újra. Ez a képesség a vevői auditoknál, a beszállítói bizalomnál és egy váratlan leállás költségénél is valódi versenyelőnnyé válik.

A következő digitalizációs projektnél ezért érdemes egy egyszerű kérdéssel kezdeni: ha ez a rendszer holnap nem elérhető vagy hibás adatot ad, pontosan mi áll le a gyárban, és mennyi idő alatt tudunk biztonságosan visszatérni a normál működéshez? A válasz rendszerint kijelöli a legjobb első lépést.

Cikk interaktív űrlapjai