Az Ansible használata a SCADA-szerverek ellenőrzött módosításaihoz

Az Ansible szabványosíthatja az ismételhető módosításokat a SCADA-alkalmazáskiszolgálókon, a történetadatbázis-kiszolgálókon, a mérnöki munkaállomásokon és a támogató hálózati eszközökön. Nem szabad úgy tekinteni rá, mint ami felhatalmazást ad a vezérlési eszközök korlátozás nélküli automatizálására. A mérnöki feladat annak meghatározása, hogy mi, hol és hogyan módosítható, valamint hogy a telephely miként tudja igazolni az eredményt.

Ez az útmutató a SCADA-rendszer környezetében végrehajtott, ellenőrzött infrastruktúra-módosításokra összpontosít. Nem javasolja a PLC-logika lecserélését vagy az üzemi eljárások megkerülését. A legbiztonságosabb kiindulópont általában egy tesztkörnyezet és egy szűk körű, szerveroldali feladat.

Az Ansible helye az OT-architektúrában

Az Ansible leltárakat használ a kezelt gépek azonosítására, a playbookok pedig a kívánt feladatokat írják le. A hivatalos Ansible-leltár útmutató ismerteti, hogyan határozzák meg a gépek, csoportok és változók az automatizálási célpontokat.

Egy ipari telephelyen ezek a célpontok lehetnek SCADA-kiszolgálók, ugrógépek, javítási tárházak, biztonsági mentési kiszolgálók és kezelt hálózati berendezések. A PLC-k és a biztonsági rendszerek külön felülvizsgálatot igényelnek. A gyártói támogatás, a protokollok működése és a módosításkezelés eltér a szokásos szerveradminisztrációtól.

A gyakorlatban az Ansible vezérlőcsomópontját kezelt zónában kell elhelyezni. Nem rendelkezhet korlátozás nélküli eléréssel a teljes vezérlőhálózathoz. A tűzfalszabályoknak, a névvel rendelkező fiókoknak és a jóváhagyott hitelesítő adatoknak minden playbookot a rendeltetése szerinti rendszerekre kell korlátozniuk.

A szélesebb architektúrát áttekintő olvasók a PLC ProTech Tudástárát és a Kommunikáció és hálózatépítés gyűjteményét használhatják a kapcsolódó vezérlési és hálózati háttér megismeréséhez.

Kezdje szűk körű, visszafordítható felhasználási esettel

A jó első feladatok egyértelmű bemenetekkel és egyszerű visszaállítással rendelkeznek. Ilyen például egy ellenőrzött konfigurációs fájl másolása, egy szolgáltatás állapotának ellenőrzése, verzióadatok begyűjtése vagy egy biztonsági mentés meglétének megerősítése.

Ne firmware-frissítéssel, vezérlőletöltéssel, biztonsági konfigurációval vagy kiterjedt tűzfalmódosításokkal kezdjen. Ezek a tevékenységek megváltoztathatják az üzemi működést. Emellett erősebb gyártói alátámasztást és a telephelyre jellemző tesztelést igényelnek.

Minden feladathoz határozza meg a várt állapotot, mielőtt megírná a playbookot. Rögzítse, hogy mely fájlok, szolgáltatások, portok, fiókok és függőségek érintettek. Határozza meg azt is, hogy minek kell változatlannak maradnia.

Válassza külön a leltárt funkció és kockázat szerint

Ne helyezze az összes OT-gépet egyetlen, megkülönböztetés nélküli leltárba. Csoportosítsa a rendszereket telephely, funkció, környezet és következmény szerint. A fejlesztési SCADA-kiszolgálók célzási mintája ne legyen azonos az éles kiszolgálókéval.

Használjon kifejezett gépcsoportokat minden jóváhagyott módosítási időablakhoz. A gépváltozókat verziókezelés alatt kell tartani. A leltár módosításait ugyanolyan gondossággal vizsgálja felül, mint a playbookok módosításait. Egy helyes feladat is hibának számít, ha rossz gépre küldik.

A dinamikus leltár hasznos lehet, de újabb adatforrást vezet be. A mérnököknek meg kell erősíteniük, hogyan kerülnek a gépek a leltárba, illetve hogyan kerülnek ki onnan. Egy elavult eszköznyilvántartás az automatizálást kivont vagy újrahasznosított berendezések felé irányíthatja.

Tervezzen idempotens playbookokat

Az idempotens feladat minden futtatáskor eléri a szükséges állapotot anélkül, hogy szükségtelen módosításokat végezne. Ez átláthatóbbá teszi az ismételt végrehajtást, és csökkenti a felesleges újraindításokat.

Használjon célplatformra készült modulokat, ha azok támogatják a kívánt rendszert. A parancsértelmező-parancsok elrejthetik a mellékhatásokat, és kétértelmű eredményeket adhatnak. Ha egy parancs elkerülhetetlen, határozza meg a feltételeit, az elfogadott visszatérési kódokat és a visszaállítás módját.

A kezelők csak akkor indítsák újra a szolgáltatásokat, ha a kapcsolódó konfiguráció módosult. A soros végrehajtás korlátozhatja az érintett csomópontok számát. A kis kötegméret a megfigyelést és a visszaállítást is kezelhetőbbé teszi.

Éles végrehajtás előtt ellenőrizzen

A szintaktikai ellenőrzés kiszűri a szerkezeti hibákat, de nem bizonyítja, hogy egy módosítás biztonságos. Az Ansible ellenőrzési módja szimulálja a támogatott feladatokat, míg a különbségmód megjelenítheti a javasolt fájlmódosításokat. A hivatalos ellenőrzési és különbségmód-dokumentáció azok korlátait is ismerteti.

Egyes modulok nem támogatják teljes mértékben az ellenőrzési módot. A regisztrált változók és a feltételes feladatok szimuláció közben eltérően viselkedhetnek. A különbségkimenet titkokat is felfedhet. Ezeket az eszközöket egy átfogóbb tesztelési folyamat részeként kezelje.

Először egy reprezentatív tesztgépen futtassa a playbookot. Ezután használjon korlátozott éles próbagépet vagy próbacsoportot. Az érintett célcsoport bővítése előtt ellenőrizze az alkalmazás állapotát, a riasztásokat, a kommunikációt, a történetadatok gyűjtését, az időszinkronizálást és a kezelői láthatóságot.

Védje a hitelesítő adatokat és a naplókat

Minimálisan szükséges jogosultságokkal rendelkező, névhez kötött szolgáltatásfiókokat használjon. Kerülje a megosztott rendszergazdai hitelesítő adatokat. A titkokat jóváhagyott titokkezelőben tárolja, és akadályozza meg, hogy a playbook kimenete jelszavakat, tokeneket, tanúsítványokat vagy privát kulcsokat fedjen fel.

A naplóknak azonosítaniuk kell a kérelmezőt, a felülvizsgálót, a playbook verzióját, a leltárt, a kezdési időpontot, az eredményt és a módosított elemeket. A rekordokat védett helyre küldje. A vezérlőcsomóponton tárolt helyi naplók önmagukban nem elegendők, ha az adott csomópont meghibásodik.

Építse be a visszaállítást a módosításba

A visszaállításnak konkrétabbnak kell lennie annál, hogy „állítsa vissza a biztonsági mentést”. A végrehajtás előtt rögzítse a pontos fájlokat, csomagokat, szolgáltatásállapotokat és alkalmazásverziókat. A helyreállítási útvonalat egy reprezentatív rendszeren tesztelje.

Egyes módosítások éles környezetben nem állíthatók vissza biztonságosan. Gyakori példák erre az adatbázisséma-módosítások és a firmware-frissítések. Ezekhez karbantartási leállásra, gyártói útmutatásra és helyreállítási adathordozóra van szükség.

Üzemeltetési ellenőrzőlista

• Erősítse meg a playbook felelősét, felülvizsgálóját és a jóváhagyott módosítási jegyet.
• Korlátozza a leltárt a megnevezett gépekre és a megfelelő környezetre.
• A végrehajtás előtt ellenőrizze a biztonsági mentéseket és a helyreállítási utasításokat.
• Futtasson szintaktikai ellenőrzést, ellenőrzési módot és – ahol támogatott – próbát tesztgépen.
• Használjon soros kötegeket és meghatározott leállítási feltételeket.
• Figyelje a SCADA-szolgáltatásokat, a kommunikációt, a riasztásokat és az adatgyűjtést.
• Archiválja a playbook verzióját, a naplókat, az eredményeket és a visszaállítás bizonyítékait.

Összegzés

Az Ansible csökkentheti a konfigurációeltéréseket és a kézi munkából eredő változatosságot a SCADA-infrastruktúra környezetében. Értékét az ismételhető bizonyítékok adják, nem az, hogy gyorsabban hajt végre több módosítást. Kezdjen korlátozott szerverfeladatokkal, különítse el a leltárakat kockázat szerint, teszteljen minden playbookot, és őrizzen meg egy kipróbált helyreállítási útvonalat.