PLC-programok és vezérlőkonfigurációk mentése

Egy kiégett vezérlőmodult néhány óra alatt ki lehet cserélni, ha van raktáron tartalék. A gépsor attól még nem indul el: az új modulba a programot, a hardverkonfigurációt és a működéshez szükséges adatokat is vissza kell tölteni. Ugyanez a helyzet zsarolóvírus-támadás, egy elrontott módosítás vagy egy illetéktelen programváltoztatás után. Ilyenkor derül ki, hogy a legutóbbi működő változat megvan-e, és megnyitható-e még.

Az IT-rendszerekben a mentés általában központi, ütemezett és felügyelt folyamat. Egy OT-környezetben a vezérlők programjai jellemzően kézi munkával, a mérnöki szoftverből kerülnek ki, és sokszor ott maradnak, ahol utoljára dolgoztak velük. Az IEC 62443-3-3 szabvány a vezérlőrendszer mentését (SR 7.3) és helyreállítását (SR 7.4) külön biztonsági követelményként kezeli.

Mi tartozik egy vezérlő mentéséhez

A PLC mentésén a legtöbben a programot értik, a visszaállításhoz azonban ennél több kell. Érdemes különválasztani a projektfájlt és azt, ami a vezérlőben ténylegesen fut.

A projektfájl és a vezérlő tartalma

A mérnöki szoftver projektfájlja tartalmazza a programot a megjegyzésekkel, a szimbólumnevekkel és a változótáblával, a hardverkonfigurációt és gyakran a hálózati beállításokat is. A vezérlőből visszatöltött program ehhez képest platformtól függően hiányos lehet: több rendszer a megjegyzéseket és a szimbólumokat nem tárolja a vezérlőben, így a visszatöltött kód működik, de alig olvasható. A teljes projektfájl ezért külön mentendő, a vezérlőből vett másolat legfeljebb kiegészíti.

Ami a programon kívül esik

• Hardverkonfiguráció. A rack felépítése, a modulok típusa és sorrendje, a kommunikációs modulok és a terepi buszok paraméterei.
• Tárolt adatok. A receptek, alapjelek, kalibrációs értékek és számlálók a vezérlő megmaradó (remanens) memóriájában élnek. A program újratöltése a platformtól függően ezeket a kezdőértékekre állíthatja vissza, ezért az aktuális értékeket külön kell menteni.
• Operátori panelek. A HMI saját projektje, a riasztási szövegek, a felhasználók és a receptkezelés beállításai.
• Hajtások és terepi eszközök. A frekvenciaváltók, szervóhajtások, mérőátalakítók és robotvezérlők paraméterkészletei és programjai, amelyek az eszközben vagy annak memóriakártyáján vannak.
• Biztonsági vezérlők. A funkcionális biztonsági program mellett az ellenőrzőösszege és a jóváhagyott (validált) állapot dokumentációja, mert visszaállítás után ezzel kell egyeznie.
• Hálózati eszközök. A menedzselt ipari kapcsolók, átjárók és tűzfalak konfigurációja, amelyről a konfigurációmentés szócikk ír.
• Firmware és szoftververziók. A vezérlő és a modulok firmware-verziója, valamint a mérnöki szoftver pontos verziója és a szükséges kiegészítők. Egy régebbi projekt sokszor csak az eredeti vagy egy közeli szoftververzióval nyitható meg.

Ha valamelyik elem nincs meg, a visszaállítás a helyszínen lassul le: a technikus a program helyett a hajtásparamétereket vagy egy rég elfelejtett IP-címet keresi.

Hol vannak ma a programok: mérnöki állomások, laptopok, beszállítók

Egy működő üzemben a programok jellemzően több helyen, több változatban léteznek egyszerre. Mielőtt mentési rendet lehetne kialakítani, érdemes felmérni, hol vannak.

• Mérnöki munkaállomás. Az üzemi hálózaton lévő gép, amelyről a vezérlőket programozzák. Gyakran itt van a legtöbb projekt, de nem biztos, hogy a legfrissebb.
• Karbantartói laptopok. A hibaelhárítás közben, a gép mellett végzett módosítás sokszor csak azon a laptopon marad meg, amelyről feltöltötték.
• Beszállítók és integrátorok. Egy gépsor programját a gépgyártó vagy a rendszerintegrátor írta, és a végleges változat náluk van. Ha a szerződés nem rendezi a forrásprojekt átadását, az üzem csak a vezérlőben futó, hiányos példányra támaszkodhat.
• Memóriakártyák és adathordozók. Sok vezérlő cserélhető memóriakártyán tárolja a programot. A kártya másolata hasznos tartalék, de nem mindig azonos a projektfájllal, és egy fiókban tartott USB-meghajtó sem mentési rendszer.
• E-mail és fájlmegosztás. A beszállító által küldött frissítések gyakran levélmellékletként érkeznek, és a postafiókban maradnak.

A felmérés eredménye egy lista: vezérlőnként hol van a legfrissebb ismert projekt, ki módosította utoljára, és mikor. Ez a lista jól kapcsolható az eszközleltárhoz. Ha az adott ipari protokollt a figyelőeszköz értelmezni tudja, a passzív forgalomfigyelés azt is megmutathatja, melyik gépről érkezett programletöltés egy vezérlőre. Ennek részleteiről a passzív OT-eszközleltárról szóló cikk ír.

A beszállítói munkánál két dolgot érdemes előre rögzíteni: hogy minden beavatkozás után a módosított projekt az üzemhez kerül, és hogy a gyártó a saját védett (zárolt) programrészeiről milyen formában ad tartalékot. Egy zárolt blokkot az üzem megnyitni nem tud, visszatölteni viszont platformtól függően igen, ha a lefordított példány megvan.

Verziókezelés és változáskövetés

Egy mappába gyűjtött, dátummal elnevezett projektfájlokból egy idő után nem derül ki, melyik volt a jóváhagyott állapot, és melyik csak egy félbehagyott próbálkozás. A verziókezelés célja, hogy minden vezérlőhöz legyen egy egyértelmű, elfogadott változat.

Egy használható rendhez nem kell bonyolult eszköz, elég, ha minden mentett változathoz tartozik:

• a vezérlő vagy gépsor azonosítója, ahogy a leltárban szerepel,
• a módosítás ideje, végzője és rövid leírása,
• a hozzá tartozó munkalap vagy változtatási kérelem száma,
• a mérnöki szoftver verziója, amellyel készült,
• az állapota: próba, üzembe helyezett vagy jóváhagyott.

A NIST SP 800-82 Rev. 3 (2023) OT-biztonsági útmutatója a konfigurációk változáskezelését a javasolt üzemeltetési gyakorlatok között tárgyalja. A gyakorlatban ez azt jelenti, hogy a módosítás előtt menteni kell a futó állapotot, utána a módosítottat, és a kettő közötti különbséget a munkalapon röviden leírni.

A szoftverfejlesztésből ismert verziókezelő rendszerek a projektfájlokat is tárolni tudják, de a legtöbb mérnöki szoftver bináris formátumban ment. Ilyenkor a rendszer annyit mutat, hogy a fájl megváltozott, azt nem, hogy melyik programsorban. A különbség pontos megjelenítéséhez a mérnöki szoftver saját összehasonlító funkciója vagy egy szöveges exportformátum kell. Vezérlőprogramokhoz létezik szabványos XML csereformátum is (IEC 61131-10, 2019), ennek támogatása platformonként eltér. Léteznek kifejezetten OT-környezetre készült változáskezelő eszközök is, amelyek a vezérlőkből ütemezetten mentenek és összehasonlítanak. Ezek a fenti rendet automatizálják, kiváltani nem tudják.

A futó és a mentett program összevetése

A mentés csak akkor ér valamit, ha megegyezik azzal, ami a vezérlőben fut. A legtöbb vezérlő lehetővé teszi a program módosítását futás közben (online módosítás), leállás nélkül. Ha a karbantartó ezután nem menti el a projektet, vagy egy másik gépen dolgozik tovább, a változás csak a vezérlőben létezik. A következő letöltés a régi projektből észrevétlenül visszaírja a korábbi állapotot.

Hogyan lehet összevetni

• Online/offline összehasonlítás. A mérnöki szoftverek többsége a megnyitott projektet blokkonként összeveti a vezérlő tartalmával, és megmutatja az eltérő részeket.
• Ellenőrzőösszeg és változásszámláló. Sok vezérlő ellenőrzőösszeget vagy változásszámlálót tart a programról. Ha ezt az értéket a mentéssel együtt rögzítik, egy későbbi lekérdezésnél programbetöltés nélkül is kiderül, változott-e valami.
• Ütemezett összevetés. Az automatizált eszközök rendszeresen kiolvassák a vezérlőket, és jelzik, ha a futó változat eltér az utolsó jóváhagyottól.

Az összevetésnél a programlogikát és a konfigurációt érdemes nézni. A változók aktuális értékei üzem közben természetes módon változnak, ezek eltérése nem jelent módosítást.

Mit jelent egy eltérés

Egy eltérés mögött gyakran egy dokumentálatlan, jó szándékú javítás áll. Ilyenkor a futó változatot kell elmenteni, és a változtatást utólag rögzíteni. Ha viszont senki nem tud a módosításról, az eset biztonsági kérdés: egy illetéktelen programváltoztatás közvetlenül a fizikai folyamatba avatkozik be. Ilyenkor az eltérő példányt a vizsgálathoz is meg kell őrizni, mielőtt bárki felülírná a jóváhagyott változattal.

Mentések tárolása és védelme

A vezérlőmentések kis méretűek, de egy támadónak értékesek. A projektfájlokból kiolvasható a gépsor működése, a hálózati címek, és platformtól függően akár a vezérlők jelszavai vagy hozzáférési adatai is. A tárolásnál ezért egyszerre kell számolni az elvesztés és az illetéktelen hozzáférés kockázatával.

• Több példány, külön helyen. A mérnöki munkaállomás egyetlen merevlemeze nem mentés. Az IT-ból ismert elv itt is érvényes: több példány, eltérő adathordozón, egy példány a telephelyen kívül vagy hálózatról leválasztva. A szabály részleteiről a 3-2-1 mentési szabályról szóló cikk ír.
• Megváltoztathatatlan példány. Egy zsarolóvírus a hálózaton elérhető mentéseket is titkosíthatja. Legalább egy példány legyen megváltoztathatatlan vagy offline, amelyet a támadó a hálózatról nem tud felülírni.
• Sértetlenség. A mentett fájlokhoz rögzített hash érték megmutatja, hogy a fájl a tárolás alatt nem változott meg. Ez a beszállítótól kapott frissítéseknél is hasznos.
• Hozzáférés. A mentési tárolót csak azok érjék el, akiknek a munkájukhoz szükséges, és ne legyen az irodai tartomány része úgy, hogy egy ott ellopott fiók is olvashassa vagy törölhesse.
• A visszaállítás eszközei. A projektfájlok mellett a mérnöki szoftver telepítőkészletét, a licencinformációkat, a firmware-fájlokat és a szükséges kommunikációs illesztőprogramokat is meg kell őrizni.

A régebbi változatokat is érdemes megtartani. Ha egy módosítás vagy egy fertőzés csak hetek múlva derül ki, a legutóbbi mentés már a hibás állapotot tartalmazhatja.

Visszaállítási próba és dokumentáció

Egy mentésről csak a visszaállítás mutatja meg, hogy használható. A próbán derül ki, hogy a projekt megnyílik-e a meglévő szoftverrel, hogy a licenc érvényes-e, és hogy a hardverkonfiguráció illeszkedik-e a raktárban tartott tartalék modulhoz.

Hogyan lehet próbát tartani

A próbát nem a termelő gépsoron kell végezni. Erre egy tartalék vezérlő, egy tesztpad vagy a mérnöki szoftver szimulátora alkalmas. A szimulátor a program megnyitását és futtatását ellenőrzi, a hardverillesztést és a kommunikációs beállításokat csak valódi eszközön lehet kipróbálni. Egy tervezett leállás, például egy éves karbantartás, alkalmat ad arra is, hogy egy kisebb, nem kritikus gépen a teljes folyamatot végigvigyék.

Mi kerüljön a visszaállítási leírásba

1. Melyik mentés a hiteles forrás, és hol található.
2. Milyen szoftver, verzió, licenc, kábel vagy illesztő kell hozzá.
3. A sorrend: firmware, hardverkonfiguráció, program, majd a tárolt adatok és receptek.
4. A hálózati beállítások: IP-cím, állomásnév, a terepi busz címei.
5. Az ellenőrzés: online/offline összevetés, az ellenőrzőösszeg egyezése, biztonsági vezérlőnél a validált állapottal való egyezés.
6. Az indítás feltételei: ki hagyja jóvá a gépsor újraindítását, és milyen próbák után.

A próba során mért idő is fontos adat. Ha egy vezérlő visszaállítása a próbán fél napig tart, a helyreállítási célidőt (RTO) is ehhez kell igazítani, vagy a folyamatot kell gyorsítani. A célidők meghatározásáról az RTO-ról és RPO-ról szóló cikk ír.

A leírás akkor használható, ha egy incidens alatt olyan kolléga is végre tudja hajtani, aki az adott gépet nem ismeri. Ezért érdemes az üzem incidenskezelési forgatókönyveihez csatolni, és a mentési listával együtt frissíteni minden jelentős módosítás után.

Kapcsolódó szolgáltatás: OT incidenskezelési protokoll →