Използване на Ansible за контролирани промени по SCADA сървъри

Ansible може да стандартизира повтаряеми промени на сървъри за SCADA приложения, историански системи, инженерни работни станции и поддържащи мрежови устройства. Не бива да се разглежда като разрешение за автоматизиране на средства за управление без ограничения. Инженерната задача е да се определи какво може да се променя, къде може да се променя и как обектът може да докаже резултата.

Това ръководство се съсредоточава върху контролирани инфраструктурни промени около SCADA система. То не предлага замяна на логиката на PLC или заобикаляне на процедурите в предприятието. Най-безопасната отправна точка обикновено е тестова среда и ограничена задача от страна на сървъра.

Къде се вписва Ansible в OT архитектурата

Ansible използва инвентари за идентифициране на управляваните хостове и плейбуци за описване на желаните задачи. Официалното ръководство за инвентара на Ansible обяснява как хостовете, групите и променливите определят целите на автоматизацията.

В индустриален обект тези цели може да включват SCADA сървъри, междинни хостове, хранилища за корекции, сървъри за архивиране и управлявано мрежово оборудване. PLC и системите за безопасност изискват отделен преглед. Поддръжката от производителя, поведението на протоколите и контролът на промените се различават от обичайното администриране на сървъри.

Практичната архитектура разполага контролния възел на Ansible в управлявана зона. Той не бива да има неограничен достъп до контролната мрежа. Правилата на защитната стена, именуваните акаунти и одобрените идентификационни данни трябва да ограничават всеки плейбук до предвидените системи.

Читателите, които преглеждат архитектурата в по-широк план, могат да използват библиотеката със знания на PLC ProTech и колекцията „Комуникации и мрежи“ за свързан контекст относно управлението и мрежите.

Започнете с ограничен, обратим сценарий

Добрите първи задачи имат ясни входни данни и лесно възстановяване. Примери са копиране на проверен конфигурационен файл, проверка на състоянието на услуга, събиране на данни за версиите или потвърждаване, че съществува резервно копие.

Избягвайте да започвате с актуализации на фърмуер, изтегляния към контролери, конфигурация на системи за безопасност или мащабни промени по защитната стена. Тези дейности могат да променят поведението на производството. Те също така изискват по-сериозни доказателства от производителя и специфично за предприятието тестване.

За всяка задача определете очакваното състояние, преди да напишете плейбука. Запишете кои файлове, услуги, портове, акаунти и зависимости са засегнати. Посочете какво трябва да остане непроменено.

Разделяйте инвентара по функция и риск

Не поставяйте всички OT хостове в един неразграничен инвентар. Групирайте системите по обект, функция, среда и последствия. SCADA сървърите за разработка не бива да споделят същия модел на целеви хостове като производствените сървъри.

Използвайте изрични групи хостове за всеки одобрен прозорец за промени. Съхранявайте променливите за хостовете под контрол на версиите. Преглеждайте промените в инвентара със същото внимание като промените в плейбуците. Правилно изпълнена задача, изпратена към грешния хост, все пак е повреда.

Динамичният инвентар може да бъде полезен, но въвежда още един източник на данни. Инженерите трябва да потвърдят как хостовете се добавят към инвентара или се премахват от него. Неактуален запис за актив може да насочи автоматизацията към изведено от експлоатация или преназначено оборудване.

Проектирайте идемпотентни плейбуци

Идемпотентната задача достига необходимото състояние, без да извършва ненужни промени при всяко изпълнение. Това улеснява разбирането на повторното изпълнение и намалява ненужните рестартирания.

Използвайте специализирани модули, когато поддържат целевата платформа. Командите на обвивката могат да прикрият странични ефекти и да връщат нееднозначни резултати. Ако дадена команда е неизбежна, определете нейните условия, очакваните кодове за връщане и поведението при възстановяване.

Обработващите задачи трябва да рестартират услуги само когато свързаната конфигурация се промени. Последователното изпълнение може да ограничи броя на засегнатите възли. Малкият размер на партидите също улеснява наблюдението и възстановяването.

Валидирайте преди изпълнение в производствена среда

Проверката на синтаксиса открива структурни грешки, но не доказва, че дадена промяна е безопасна. Режимът за проверка на Ansible симулира поддържаните задачи, а режимът за разлики може да покаже предложените промени по файловете. Официалната документация за режимите за проверка и разлики също отбелязва техните ограничения.

Някои модули не поддържат напълно режима за проверка. Регистрираните променливи и условните задачи може да се държат различно по време на симулация. Резултатът от режима за разлики може да разкрие тайни. Разглеждайте тези инструменти като доказателства в рамките на по-широк процес на тестване.

Първо изпълнете плейбука върху представителен тестов хост. След това използвайте ограничен производствен канарен хост. Потвърдете изправността на приложението, алармите, комуникациите, събирането на данни от историана, синхронизацията на времето и видимостта за операторите, преди да разширите целевата група.

Защитете идентификационните данни и журналите

Използвайте именувани служебни акаунти с минимално необходимите права. Избягвайте споделени администраторски идентификационни данни. Съхранявайте тайните в одобрен трезор и не допускайте изходът от плейбука да разкрива пароли, токени, сертификати или частни ключове.

Журналите трябва да идентифицират заявителя, проверяващия, версията на плейбука, инвентара, началния час, резултата и променените елементи. Изпращайте записите в защитено местоположение. Локалните журнали на контролния възел не са достатъчни, ако този възел се повреди.

Вградете възстановяването в промяната

Възстановяването трябва да бъде по-конкретно от „възстановяване на резервното копие“. Заснемете точните файлове, пакети, състояния на услугите и версии на приложенията преди изпълнението. Тествайте пътя за възстановяване върху представителна система.

Някои промени не могат да бъдат безопасно отменени по време на производство. Често срещани примери са промените в схемата на базата данни и актуализациите на фърмуера. При тях планът трябва да включва престой за поддръжка, указания от производителя и носители за възстановяване.

Оперативен контролен списък

• Потвърдете собственика на плейбука, проверяващия и одобрената заявка за промяна.
• Ограничете инвентара до именуваните хостове и правилната среда.
• Проверете резервните копия и инструкциите за възстановяване преди изпълнението.
• Изпълнете проверки на синтаксиса, режима за проверка и проба върху тестов хост, когато се поддържат.
• Използвайте последователни партиди и определени условия за спиране.
• Наблюдавайте SCADA услугите, комуникациите, алармите и събирането на данни.
• Архивирайте версията на плейбука, журналите, резултатите и доказателствата за възстановяване.

Обобщение

Ansible може да намали отклоненията в конфигурацията и ръчните различия около SCADA инфраструктурата. Стойността му идва от повторяемите доказателства, а не от това да изпълнява повече промени по-бързо. Започнете с ограничени задачи от страна на сървъра, разделяйте инвентарите според риска, тествайте всеки плейбук и поддържайте проверен път за възстановяване.