A HMI/SCADA-alkalmazások kiberbiztonságot szem előtt tartó tervezése – olyan alapelvek, amelyek már a tervezési szakaszban csökkentik a kockázatot

A HMI/SCADA-alkalmazások biztonsága jóval korábban dől el, mint a védelmi mechanizmusok kiválasztásának szakaszában. Hogy a rendszer mennyire lesz ellenálló a tévedésekkel, a visszaélésekkel és a folyamatállapot ellenőrizetlen megváltozásával szemben, azt elsősorban a tervezés során elfogadott alapfeltevések határozzák meg: a szerepkörök felosztása, a bizalmi határok kijelölése, a felületről elérhető funkciók köre, valamint a szerviz és a távoli hozzáférés megszervezésének módja. Ha ezeket a kérdéseket másodlagosnak tekintik, az alkalmazás a kockázat csökkentése helyett annak beépülését fogja erősíteni. Ezért a HMI/SCADA tervezését kiberbiztonsági szempontból mérnöki feladatként kell kezelni: először meg kell határozni, mely műveletek kritikusak, milyen következményekkel járhatnak, és valójában kinek szabad ezeket végrehajtania, és csak ezután érdemes kialakítani a képernyőket, a riasztásokat és a kezelési kényelmet.

A kiberbiztonság a tervezésnél kezdődik

A HMI/SCADA-rendszerekben a kiberbiztonság nem egy kész vizualizációhoz utólag hozzáadott elem. A korábban meghozott döntésekből következik: az alkalmazás architektúrájából, a jogosultsági modellből, a vezérléssel való kommunikáció módjából és a szervizre vonatkozó alapelvekből. Ennek különös jelentősége van, mert a HMI/SCADA-alkalmazás egyszerre kapcsolódási pont az ember, a folyamat és az infrastruktúra között. Egy tervezési hiba ezért nem áll meg az informatikai kockázat szintjén. Egyidejűleg hatással lehet a kezelő reakciójára, a funkcionális biztonságra, az üzemi kockázatra és a termelés folytonosságára.

Tervezési szempontból ezért az alapvető kérdés nem az, hogy a végén milyen védelmet kell még hozzáadni, hanem az, hogy mely korai döntések csökkentik már a kezdetektől a támadási felületet. A legnagyobb problémák rendszerint nem egyetlen mechanizmus hiányából adódnak, hanem abból, hogy az alkalmazásba túlzott bizalom épül be. A gyakorlatban ez közös felhasználói fiókokat, széles körű és állandó szervizhozzáférést, a kezelő, a karbantartás és az integrátor szerepköreinek elválasztása nélküli működést, valamint a kezelői réteg és a vezérlés közötti túl szabad kommunikációt jelent. Az üzembe helyezés szakaszában az ilyen megoldások kényelmesnek tűnnek, mert gyorsítják a munkát és megkönnyítik a diagnosztikát. Később azonban a környezet tartós jellemzőivé válnak, és növelik a visszaélés, a tévedés vagy a folyamatállapot ellenőrizetlen megváltozásának kockázatát.

Ezért a képernyők tervezése előtt érdemes nemcsak azt meghatározni, mit kell látnia a felhasználónak, hanem mindenekelőtt azt is, hol húzódnak a bizalmi határok, mely műveletek kritikusak, és mely pontokon válhat a felület a hiba vagy az eljárások megkerülésének eszközévé. Ez a sorrend rendezi a későbbi döntéseket is: a HMI kizárólag vizualizációs réteg legyen-e, vagy egyben a konfiguráció, a diagnosztika és a receptúraváltás helye is; a szervizfunkciók folyamatosan működjenek-e, vagy csak tudatos aktiválás után; a kezelő kizárólag a folyamat működtetéséhez férjen-e hozzá, vagy olyan műveletekhez is, amelyek a paramétereket és az adatelőzményeket módosítják.

A hiányosságok gyakorlati költsége rendszerint csak akkor válik láthatóvá, amikor az alkalmazás már összekapcsolódik a receptúrákkal, a riasztásokkal, a jelentéskészítéssel, az archiválással és a karbantartási eljárásokkal. Ilyenkor még egy látszólag egyszerű korrekció is – például a fiókok szétválasztása, egy kritikus művelet jóváhagyási útvonalának módosítása vagy a távoli hozzáférés eseti használatra korlátozása – már nem pusztán a képernyők módosítását jelenti. A logika átalakítását, a riasztáskezelés újbóli tesztelését, a felelősségi körök tisztázását, és gyakran a telephelyen belüli szervezeti változtatásokat is igényli.

A gyakorlatban a legésszerűbb kiindulópont egy munkaváltozatként kezelt térkép a felhasználói szerepkörökről és azok kritikus műveletekre vonatkozó jogosultságairól, egy lista azokról a funkciókról, amelyek a folyamat állapotát, a konfigurációt vagy a receptúrákat módosítják, valamint a külső kapcsolatok jegyzéke, beleértve a szervizt, a jelentéskészítést, a felsőbb szintű rendszereket és a távoli hozzáférést. Erre alapozva lehet csak érdemben megtervezni a zónák és kapcsolatok architektúráját, valamint előkészíteni a későbbi kockázatelemzést. Ez a megközelítés összhangban van mind a mérnöki gyakorlattal, mind a felelősségi körök rendezésére, a funkciók szétválasztására és a kommunikáció ellenőrzésére vonatkozó követelményekkel az ipari környezetekben.

Hol nő meg valójában a költség és a kockázat

A HMI/SCADA-alkalmazásokban a legnagyobb költség és kockázat nem pusztán abból fakad, hogy a rendszerek össze vannak kapcsolva, hanem abból, hogy az alkalmazás egyes funkciói milyen folyamatbeli és szervezeti következményeket váltanak ki. A legérzékenyebb pontok azok, amelyek lehetővé teszik a beállítások gyors módosítását, egy megkerülés bevezetését, egy riasztás elnémítását, a receptúra megváltoztatását vagy a kézi vezérlés végrehajtását teljes technológiai kontextus nélkül. Ha a terv ezeket a műveleteket a termelési képernyőről, rutinszerű üzemmódban is megengedi, a kockázat azért nő meg, mert egyetlen felhasználói döntés vagy egyetlen átvett munkamenet közvetlenül megváltoztathatja a folyamat állapotát.

Ez azt jelenti, hogy a kritikus műveletek jegyzékét a biztonsági architektúra részeként kell kezelni, nem pusztán a kezelőfelület ergonómiájának kérdéseként. Ugyanez a logika érvényesül a műveletek elszámoltathatóságánál is. A közös bejelentkezések, a műszak által megosztva használt fiókok, az olvasási, vezérlési, konfigurációs és adminisztrációs jogosultságok szétválasztásának hiánya, valamint a hiányos eseménynaplózás azt eredményezik, hogy egy incidens után nehéz megbízhatóan megállapítani, tévedés, eljárásmegkerülés, szervizhozzáféréssel való visszaélés vagy jogosulatlan beavatkozás történt-e. A probléma nem merül ki az okok kivizsgálásában. A felhasználói műveletek hiteles nyoma nélkül az eljárások hatékonysága sem értékelhető, a jogosultságok sem kezelhetők ésszerűen, és az üzemeltetési döntések sem védhetők meg belső audit, ügyfélelvárások vagy elfogadott biztonsági szabályzatok előtt. A gyakorlatban itt a műveletek elszámoltathatóságáról és a nyomonkövethetőségi útvonalról van szó, nem csupán az események rögzítéséről.

Ugyancsak rendkívül költséges tervezési hiba, amikor az eredetileg üzembe helyezéshez vagy az integrátor támogatásához készített, összetett szerviz- és diagnosztikai képernyőket változtatás nélkül átviszik a termelési környezetbe. Ezek a nézetek gyakran széles körű hozzáférést adnak belső változókhoz, állapotok kényszerítéséhez, reteszelések törléséhez és paraméterek módosításához, noha normál üzemben legfeljebb csak alkalomszerűen van rájuk szükség. Ha nem kapnak további korlátozásokat, a szokásos operátori útvonalon kívüli folyamatbeavatkozás legrövidebb útjává válnak. Ésszerű megoldás, ha a karbantartás számára szükséges diagnosztikát elválasztják a működési logikába beavatkozást lehetővé tevő funkcióktól, és külön döntenek arról is, hogy a gépgyártó diagnosztikája helyben, távolról vagy csak feltételesen, tudatos aktiválás után és a teljes munkamenet rögzítésével legyen elérhető.

Hasonlóan kell kezelni az adatbázisokkal, a jelentéskészítéssel, a táv támogatással és az irodai rendszerekkel való integrációt is. Minden ilyen kapcsolat javítja a munkavégzés kényelmét, ugyanakkor növeli azoknak a függőségeknek a számát, amelyek belépési úttá, zavarforrássá vagy a felelősségi viszonyok átláthatatlanságának okává válhatnak. Egy köztes szolgáltatás meghibásodása, hibás időszinkronizáció, a felsőbb szintű rendszerrel folytatott ellenőrizetlen adatcsere vagy egy nyitva hagyott szervizcsatorna nemcsak a riportok elérhetőségére lehet hatással, hanem az operátor által meghozott döntésekre is.

Ezért már a tervezés során érdemes nemcsak a képernyők rendelkezésre állását mérni, hanem egyszerűbb és hasznosabb mutatókat is: a termelési HMI-ről elérhető kritikus műveletek számát, az aktív külső kapcsolatok számát, a privilegizált fiókok számát, valamint az auditnyom által lefedett események körét. Egy ilyen áttekintés később rendszerezi az eseménynaplózást, a paraméterváltozások ellenőrzését és a távoli hozzáférés szabályait.

A riasztáskezelés külön figyelmet igényel. Ezen a területen a látszólagos teljesség gyakran a tényleges kontroll hiányát fedi el. A rosszul megtervezett riasztások és eseménytörténet nemcsak túlterhelik az operátort, hanem meg is fosztják attól a képességétől, hogy megkülönböztesse a kritikus jelzéseket a technikai zajtól. Ha egy riasztás indoklás nélkül könnyen elnémítható, az okra való hivatkozás nélkül visszaigazolható, vagy elveszik a diagnosztikai üzenetek tömegében, az alkalmazás megszűnik támogatni a folyamat biztonságát. Ezért a riasztási prioritásoknak az emberekre, a gépre és a termelés minőségére gyakorolt tényleges hatásból kell következniük, és összhangban kell maradniuk a visszaigazolások, megkerülések és beállításmódosítások rögzítésének szabályaival. Ez az a pont, ahol a kockázatelemzés megszűnik pusztán formális dokumentum lenni, és elkezdi alakítani a kezelőfelületet.

Hogyan tervezzünk úgy, hogy korlátozzuk a hibák és a visszaélések következményeit

A kiindulópont egyszerű: a HMI/SCADA alkalmazás nem épülhet arra a feltételezésre, hogy minden felhasználó mindig helyesen és a folyamat megfelelő kontextusában jár el. A tervezést a funkciók szétválasztásával kell kezdeni, nem a képernyők rajzolásával. A csapatnak először azt kell meghatároznia, hogy az operátor mit láthat csak, mit igazolhat vissza, min változtathat a normál munkamenet során, és mely műveleteket kell szervizmódba áthelyezni, további jogosításhoz kötni, vagy teljesen elkülönített eszközre vagy állomásra kiszervezni.

Ez a döntés rendezi a teljes hozzáférési architektúrát: a szerepköröket, a jogosultságok körét, a műveletek naplózásának módját és a távoli támogatás feltételeit. A gyakorlatban jól működik a valós feladatkörökre épülő szerepkörmátrix, amely megkülönbözteti az operátort, a műszakvezetőt, a karbantartást, a technológust, az integrátort és az adminisztrátort. Ez nem formalitás. Ha a szervizfunkciók ugyanazon a képernyőn és ugyanazon a fiókon maradnak, mint a folyamatkezelés, akkor az alkalmazás maga teremt utat a tévedéshez, az eljárás megkerüléséhez vagy a jogosultságokkal való visszaéléshez.

A jó HMI/SCADA csökkenti annak lehetőségét, hogy veszélyes műveletet véletlenül hajtsanak végre, de nem lassítja szükségtelenül a rutinfeladatokat. Ehhez egyértelmű munkakörnyezet szükséges: a felhasználónak látnia kell, mely objektumon dolgozik, milyen állapotban van a folyamat, helyben vagy távolról működik-e, illetve hogy a rendszer automatikus, kézi vagy szerviz üzemmódban van-e. A megerősítéseknek a kockázathoz kell igazodniuk, nem lehetnek minden műveletnél azonosak. Ott, ahol a hiba következménye visszafordítható és korlátozott, általában elegendő egyetlen jóváhagyás. A kritikus műveletek további ellenőrzést igényelnek: második megerősítést, újbóli hitelesítést, a folyamat állapotától való függést vagy fizikai átlépést egy elkülönített kezelőfelületre.

A feltételes zárolások szintén lényegesek. Ha az alkalmazás lehetővé teszi a beállítás módosítását, a jel kényszerítését vagy a kézi módba lépést a berendezés állapotától függetlenül, akkor a kockázat a tervezésből az operátorra hárul át. Itt látszik igazán, hogy a kezelőfelület helyes kialakítása nem pusztán a könnyű használatról szól, hanem arról is, hogy a beépített korlátok csökkentsék a hibák következményeit. Sok esetben ez a szemlélet közel áll ahhoz, ahogyan a Poka-Yoke a gyártósorokon működik.

A hozzáférés többrétegű kialakításának arra is ki kell terjednie, hogyan használják a jogosultságokat időben. Az egyéni fiókok mindenütt szükségesek, ahol elvárás a műveletek visszakövethetősége. A közös fiók megszünteti annak lehetőségét, hogy meg lehessen állapítani, ki hozta meg ténylegesen a döntést. A minimális jogosultsági kör azt jelenti, hogy a felhasználó csak azokat a funkciókat kapja meg, amelyekre az aktuális munkájához szüksége van, a jogosultságok emelése pedig csak ideiglenesen és ellenőrzött feltételek mellett történik. Ez különösen igaz a karbantartásra, az integrátorra és a gyártó távoli támogatására. Az állandóan nyitott szervizelérési út csak látszólag kényelmes, mert megszünteti az üzemeltetés és a szerviz közötti természetes bizalmi határt. Biztonságosabb megoldás az igény szerint aktivált hozzáférés, amely időben korlátozott, konkrét személyhez rendelt, és szerepel az eseménytörténetben. Ez a megközelítés jól illeszkedik a minimális jogosultság elvéhez és a hozzáférés szegmentálásához.

Ugyanebben a szellemben kell eldönteni azt is, hogy a szervizfunkciók elérhetők legyenek-e a munkahelyi HMI-ről, vagy kizárólag külön állomásról, illetve hogy engedélyezettek legyenek-e a cserélhető adathordozók, valamint az adatok helyi importja vagy exportja az operátori panelről. Ezek nem mellékes döntések. Tőlük függ, hogy a rendszer karbantarthatósága ellenőrzött módon valósul-e meg, vagy eseti kerülőmegoldásokkal.

Incidens vagy üzemeltetési vita esetén önmagában a kezelőfelület nem elegendő. Az alkalmazásnak olyan nyomot kell hagynia, amely lehetővé teszi a döntési folyamat rekonstruálását. Az eseménytörténetnek, a rendszernaplóknak és a változások rögzítésének együtt nemcsak arra kell választ adnia, hogy mi történt, hanem arra is, hogy ki, mikor, honnan és a folyamat milyen állapotában hajtotta végre az adott műveletet. Az események minimális köre, amelyet általában érdemes naplózni, magában foglalja a bejelentkezést, a jogosultságok módosítását, a paraméterek változtatását, a kézi módba lépést, a riasztás nyugtázását és a konfiguráció importját. Kulcsfontosságú, hogy a bejegyzés technológiai kontextushoz kapcsolódjon, mert az objektum állapota nélküli puszta változásinformáció gyakran használhatatlan.

Jó példa erre egy sok bevezetésben tipikus eset: a riasztási küszöb módosítása a technológus által megengedhető lehet, de csak az előírt módba lépés után, a felhasználó, az állomás, az időpont, a korábbi és az új érték rögzítésével, valamint annak megerősítésével, hogy a berendezés nem volt kritikus állapotban. Az ilyen nyomvonal a biztonság és az ipari alkalmazások változáskezelése szempontjából egyaránt jelentős.

Az utolsó réteg a karbantarthatóság a védelmek megkerülése nélkül. Ha a frissítés, a konfiguráció visszaállítása vagy a diagnosztika a hozzáférés-ellenőrzés kikapcsolását, közös jelszó használatát vagy auditnyom nélküli munkavégzést igényel, akkor a probléma a tervezésben van, nem a személyzet fegyelmében. Az alkalmazásnak előre meghatározott változtatási folyamattal kell rendelkeznie: kérelem, hatásértékelés, teszt, bevezetés, megerősítés és visszaállítási terv. Emellett legalább logikailag el kell különítenie az üzemi és a szervizkörnyezetet, ahol pedig ez indokolt, szervezeti és műszaki szinten is. A konfigurációs mentések elkészítésének és visszaállításának ellenőrzött módon kell történnie, nem pedig az operátori panelről végzett eseti exporttal „biztos, ami biztos” alapon. Ez a megközelítés összhangban van az OT-ben alkalmazott minimális jogosultság elvével, valamint a hozzáférés-ellenőrzésre, a műveletek visszakövethetőségére és a változáskezelésre vonatkozó követelményekkel, amelyek terjedelmét mindig a rendszer architektúrájához és az elfogadott felelősségmegosztáshoz kell igazítani.

A bevezetés gyakorlata és a követelményekhez való viszony

A legtöbbet nem az adja, ha a projekt végén további védelmi mechanizmusokat építünk be, hanem az, ha az alkalmazást az átvétel vagy a korszerűsítés előtt rendszerezetten felülvizsgáljuk. Ez az a pillanat, amikor a rendszer működési módja még viszonylag alacsony költséggel korrigálható, ahelyett hogy később kiegészítő eljárásokkal kellene körülvenni a hibás alapfeltevéseket. Az ilyen felülvizsgálatot vegyes csapatnak kell végeznie: tervezés, karbantartás, üzemeltetés, automatizálási szakember és a biztonságért felelős személyek részvételével.

Az értékelés tárgya nem kizárólag a műszaki konfiguráció, hanem az is, hogy az alkalmazás valóban elkülöníti-e a szerepköröket, védi-e a kritikus műveleteket, indokolt esetekre korlátozza-e a távoli hozzáférést, biztosítja-e a riasztások egyértelmű kezelését, megőrzi-e a változások előzményeit, valamint lehetővé teszi-e a mentések és vészhelyzeti eljárások végrehajtását a védelmek megkerülése nélkül. Éppen egy ilyen felülvizsgálatból kell következnie a FAT/SAT ellenőrzőlistájának, valamint az átvételbe, a szerviztervbe és a megvalósulási dokumentációba bekerülő követelményeknek.

Ez a megközelítés a hangsúlyt magukról a védelmi megoldásokról azokra a tervezési döntésekre helyezi át, amelyek később meghatározzák az emberek és a berendezések működését. Ha már a tervezési szakaszban nem rögzítik, ki módosíthatja a receptúraparamétereket, ki hagyja jóvá a szervizmódot, hogyan dokumentálják az integrátor beavatkozását, és milyen feltételek mellett engedélyezett a telephelyen kívüli hozzáférés, akkor az indulás után a rendszer kivételekre és szóbeli megállapodásokra fog épülni.

Ugyanezért érdemes eldönteni azt is, hogy az alkalmazás értékelése a gép vagy a gyártósor korszerűsítésének részeként történjen-e, vagy külön OT-felülvizsgálatként. Az első megközelítés jobban összekapcsolja a biztonságot a folyamat funkciójával, a második pedig megkönnyíti a rendszerek közötti függőségek, valamint a fiókokkal, jogosultságokkal és a tevékenységek naplózásával kapcsolatos felelősségi körök feltárását. Ez egyben a kockázat előzetes elemzésének természetes helye is: a kritikus műveletek, a bizalmi határok, valamint a kezelői hiba vagy visszaélés következményeinek azonosítására. A gyakorlatban ebben hasznos lehet a projekt kockázatelemzése is.

• a felhasználói szerepkörök és a bejelentkezés módja,
• a kritikus műveletek és azok megerősítésének szabályai,
• a távoli hozzáférés és a szervizfunkciók,
• a riasztások, a módosítások naplózása és a műveletek elszámoltathatósága,
• a mentések, a helyreállítás és a vészhelyzeti eljárások.

Az üzemben ritkán hoz jó eredményt, ha egyszerre sok eszközt vezetnek be. Általában sokkal fontosabb néhány olyan rendszerszintű kockázat megszüntetése, amelyeket éveken át praktikusnak tartottak. A HMI/SCADA alkalmazás korszerűsítése kezdődhet a közös fiókok megszüntetésével, a szerviz- és kezelői funkciók szétválasztásával, a külső kapcsolatok ellenőrzött útvonalakra korlátozásával, valamint a paramétermódosítások nyomon követésének bevezetésével, konkrét személyhez vagy szerepkörhöz rendelve. Egy ilyen változásnak nem kell rontania a ipari automatizálás üzemeltetését, sem a karbantartás vagy az integrátor munkáját, feltéve hogy a szervizmódot, a jogosítás szabályait és a módosítások reprodukálható menetét már a kezdetektől megtervezték.

Az üzemeltetés során ezután nem egy elvont biztonsági szintet érdemes mérni, hanem működés szempontjából hasznos mutatókat: a rendszerben megmaradt közös fiókok számát, az aktív távoli hozzáférés körét, a módosítási naplók teljességét, a konfiguráció helyreállításának idejét, valamint a hivatalos eljáráson kívül végrehajtott beavatkozások számát. Az ilyen mérőszámok alapján megítélhető, hogy a projekt valóban csökkentette-e a kockázatot, vagy csak a mindennapi gyakorlatba helyezte át.

A lengyel és uniós környezetben egyre nehezebb megvédeni azt a megközelítést, amely szerint a HMI/SCADA kiberbiztonsága kizárólag az IT-részleg ügye. A felelősség megoszlik a tervezés, az üzemeltetés, a karbantartás, a beszállítók és az integrátorok között, az ágazati és szerződéses követelmények pedig csak akkor bírnak valódi jelentőséggel, ha a szervezet konkrétumokat tud felmutatni: milyen tervezési döntések születtek, hogyan történik a jogosultságok kiosztása, milyen nyoma van a tevékenységeknek, és ki felügyeli a változtatásokat. A szabványokra, belső szabályzatokra vagy szerződéses kikötésekre való puszta hivatkozás nem helyettesíti annak bizonyítását, hogy az alkalmazást úgy tervezték meg és úgy vették át, hogy az lehetővé tegye a biztonságos üzemeltetést.

A legfontosabb következtetés gyakorlati jellegű. A kockázat csökkentésének legolcsóbb és leghatékonyabb időszaka továbbra is az alkalmazás tervezése és átvétele. Ekkor lehet a legkisebb ráfordítással meghatározni a bizalmi határokat, a szerepköröket, a hozzáférési feltételeket, a tevékenységek nyomkövetését és a változtatások kezelésének módját. Ha ezeket a követelményeket ellenőrizhető elvárásokká alakítják a beszállítóval és az integrátorral szemben, akkor a HMI/SCADA többé nem csupán kényelmes, de túlságosan bizalomra építő felület lesz, hanem a folyamat biztonságos üzemeltetésének eszközévé válik.