Použití Ansible pro řízené změny serveru SCADA

Ansible může standardizovat opakovatelné změny na aplikačních serverech SCADA, historizačních serverech, inženýrských pracovních stanicích a podpůrných síťových zařízeních. Nemělo by být považováno za oprávnění k automatizaci řídicích prostředků bez stanovených hranic. Úkolem inženýrů je definovat, co se smí změnit, kde se to smí změnit a jak může pracoviště prokázat výsledek.

Tato příručka se zaměřuje na řízené změny infrastruktury v okolí systému SCADA. Nenavrhuje nahrazování logiky PLC ani obcházení podnikových postupů. Nejbezpečnějším začátkem je obvykle testovací prostředí a úzce vymezená úloha na straně serveru.

Jaké místo má Ansible v architektuře OT

Ansible používá inventáře k identifikaci spravovaných hostitelů a playbooky k popisu požadovaných úloh. Oficiální příručka inventáře Ansible vysvětluje, jak hostitelé, skupiny a proměnné definují cíle automatizace.

V průmyslovém provozu mohou tyto cíle zahrnovat servery SCADA, skokové hostitele, repozitáře záplat, zálohovací servery a spravovaná síťová zařízení. PLC a bezpečnostní systémy vyžadují samostatné posouzení. Podpora dodavatele, chování protokolů a řízení změn se liší od běžné správy serverů.

Praktická architektura udržuje řídicí uzel Ansible ve spravované zóně. Neměl by mít neomezený přístup napříč řídicí sítí. Pravidla firewallu, pojmenované účty a schválené přihlašovací údaje by měly omezit každý playbook na zamýšlené systémy.

Čtenáři, kteří posuzují širší architekturu, mohou využít knihovnu znalostí PLC ProTech a kolekci Komunikace a sítě pro související kontext řízení a sítí.

Začněte úzce vymezeným a vratným případem použití

Dobré první úlohy mají jasné vstupy a snadný návrat k předchozímu stavu. Mezi příklady patří zkopírování ověřeného konfiguračního souboru, kontrola stavu služby, shromáždění údajů o verzích nebo ověření existence zálohy.

Nezačínejte aktualizacemi firmwaru, nahráváním programů do řídicích jednotek, bezpečnostní konfigurací ani rozsáhlými změnami firewallu. Tyto činnosti mohou změnit chování výroby. Vyžadují také důkladnější podklady od dodavatele a testování specifické pro daný provoz.

U každé úlohy definujte požadovaný stav ještě před napsáním playbooku. Zaznamenejte, kterých souborů, služeb, portů, účtů a závislostí se týká. Uveďte, co má zůstat beze změny.

Oddělte inventáře podle funkce a rizika

Neumisťujte všechny OT hostitele do jednoho nerozlišeného inventáře. Seskupujte systémy podle pracoviště, funkce, prostředí a možných dopadů. Vývojové servery SCADA by neměly používat stejný vzor cílů jako produkční servery.

Pro každé schválené servisní okno používejte explicitní skupiny hostitelů. Proměnné hostitelů uchovávejte pod správou verzí. Změny inventáře kontrolujte stejně pečlivě jako změny playbooků. Správná úloha odeslaná nesprávnému hostiteli je stále selháním.

Dynamický inventář může být užitečný, ale zavádí další zdroj dat. Inženýři by měli ověřit, jak hostitelé do inventáře vstupují a jak z něj odcházejí. Zastaralý záznam o majetku může nasměrovat automatizaci k vyřazenému nebo znovu využitému zařízení.

Navrhujte idempotentní playbooky

Idempotentní úloha dosáhne požadovaného stavu, aniž by při každém spuštění prováděla zbytečné změny. Opakované spouštění je tak srozumitelnější a snižuje počet zbytečných restartů.

Pokud podporují cílovou platformu, používejte moduly určené pro konkrétní účel. Příkazy shellu mohou skrývat vedlejší účinky a vracet nejednoznačné výsledky. Pokud se příkazu nelze vyhnout, definujte jeho podmínky, očekávané návratové kódy a chování při návratu zpět.

Obslužné rutiny by měly restartovat služby pouze při změně související konfigurace. Sériové provádění může omezit počet ovlivněných uzlů. Malá velikost dávky také usnadňuje monitorování a návrat k předchozímu stavu.

Ověřte změnu před spuštěním v produkci

Ověření syntaxe odhalí strukturální chyby, ale neprokazuje bezpečnost změny. Režim kontroly Ansible simuluje podporované úlohy, zatímco režim rozdílů může zobrazit navrhované změny souborů. Oficiální dokumentace k režimu kontroly a rozdílů rovněž upozorňuje na jejich omezení.

Některé moduly režim kontroly plně nepodporují. Registrované proměnné a podmíněné úlohy se mohou během simulace chovat odlišně. Výstup rozdílů může odhalit tajné údaje. Považujte tyto nástroje za jeden z podkladů v rámci širšího testovacího procesu.

Nejprve spusťte playbook na reprezentativním testovacím hostiteli. Poté použijte omezený produkční pilot. Než rozšíříte skupinu cílů, ověřte stav aplikace, alarmy, komunikaci, sběr dat historizátorem, synchronizaci času a viditelnost pro operátory.

Chraňte přihlašovací údaje a protokoly

Používejte pojmenované servisní účty s minimálními potřebnými oprávněními. Vyhněte se sdíleným účtům správce. Tajné údaje ukládejte do schváleného trezoru a zabraňte tomu, aby výstup playbooku odhalil hesla, tokeny, certifikáty nebo soukromé klíče.

Protokoly by měly uvádět žadatele, kontrolora, verzi playbooku, inventář, čas zahájení, výsledek a změněné položky. Záznamy odesílejte do chráněného umístění. Lokální protokoly na řídicím uzlu nestačí, pokud tento uzel selže.

Začleňte návrat k předchozímu stavu přímo do změny

Návrat k předchozímu stavu musí být konkrétnější než „obnovit zálohu“. Před spuštěním zachyťte přesné soubory, balíčky, stavy služeb a verze aplikací. Postup obnovy otestujte na reprezentativním systému.

Některé změny nelze v produkci bezpečně vrátit zpět. Běžnými příklady jsou změny databázového schématu a aktualizace firmwaru. V těchto případech plán vyžaduje odstávku, pokyny dodavatele a média pro obnovu.

Provozní kontrolní seznam

• Potvrďte vlastníka playbooku, kontrolora a schválený požadavek na změnu.
• Omezte inventář na pojmenované hostitele a správné prostředí.
• Před spuštěním ověřte zálohy a pokyny k obnově.
• Proveďte kontrolu syntaxe, režim kontroly a tam, kde je to podporováno, zkoušku na testovacím hostiteli.
• Používejte sériové dávky a definované podmínky zastavení.
• Monitorujte služby SCADA, komunikaci, alarmy a sběr dat.
• Archivujte verzi playbooku, protokoly, výsledky a důkazy o možnosti návratu.

Hlavní závěr

Ansible může omezit konfigurační odchylky a ruční rozdíly v infrastruktuře SCADA. Jeho přínos spočívá v opakovatelných důkazech, nikoli v rychlejším provádění většího počtu změn. Začněte jasně ohraničenými úlohami na serverech, oddělte inventáře podle rizika, každý playbook otestujte a zachovejte ověřenou cestu k obnově.