Как вести контроль версий проектов ПЛК в АСУ ТП

Цифровизация производственных процессов сделала программное обеспечение не менее значимым активом, чем само оборудование. Сегодня работу станков, линий и технологических комплексов определяют проекты ПЛК (программируемых логических контроллеров), и любое несанкционированное изменение в их коде может привести не только к аварии и простоям, но и к угрозе безопасности людей. При этом на многих предприятиях до сих пор отсутствует системный контроль версий: рабочие проекты хранятся на отдельных компьютерах или даже на флешках. Такой подход создает высокий риск потерь и ошибок. Поэтому контроль версий в промышленности — это не просто инструмент удобства инженеров, а фундаментальный элемент кибербезопасности.

Специфика и ограничения контроля версий проектов ПЛК в АСУ ТП

Среды разработки проектов ПЛК в АСУ ТП имеют свою специфику, что усложняет использование на предприятиях традиционных систем контроля версий.

Несовместимость с распространенными IT-практиками. Такие известные решения для контроля версий, как Git, к работе с АСУ ТП практически не применимы. Причина простая: каждая среда разработки предполагает свои подходы к хранению и обработке кода.

Проект может храниться, например, в виде набора файлов, либо одного большого бинарного файла, который читает только проприетарная среда разработки. В промышленности почти все проекты ПЛК — это бинарные или полубинарные форматы, завязанные на проприетарные среды, такие TIA Portal от Siemens, Unity Pro от Schneider Electric, CODESYS и другие. Тогда как Git изначально был ориентирован на работу с исходными кодами ядра Linux, то есть с большим количеством небольших текстовых файлов.

Форматами, завязанными на проприетарные среды, продолжают пользоваться многие предприятия, где старые производственные линии остаются на зарубежных решениях. Однако надо отметить, в свете тренда на импортозамещение успешно развиваются и российские среды разработки. Неплохие результаты, например, у  компаний Прософт-Системы, ТРЭИ и некоторых других вендоров. Новые производственные линии сейчас изначально строятся на российских продуктах.

Но мало просто импортозаместить среду разработки АСУ ТП — нужно обеспечить корректную работу с ПЛК и настроить их так, чтобы они поддерживали параметры, критичные для технологического процесса. Это трудоемкая и дорогостоящая задача: любая ошибка в конфигурации может привести к сбою и потребовать повторной настройки, что занимает часы или даже дни. Именно поэтому сейчас в приоритете не расширенные функции, а надежность базового функционала, включая возможность версионирования проектов ПЛК. Система, которая позволяет быстро откатиться к стабильной версии и восстановить работу за несколько минут, становится не просто удобством, а инструментом экономии ресурсов и снижения рисков простоя.
Работа в условиях реальности цеха. В отличие от «классической» разработки, изменения в логике ПЛК в АСУ ТП могут вноситься прямо на производстве и в срочном порядке — в соответствии с текущими задачами, часто без полноценного документирования и тестирования. «Горячие» правки особенно характерны для таких отраслей, как металлургия и пищевая промышленность.

С тестированием в АСУ ТП ситуация принципиально сложнее: невозможно воссоздать все сценарии технологического процесса в эмуляторах, а имеющиеся тестовые стенды редко покрывают полный набор производственных условий. Поэтому надежность и предсказуемость изменений обеспечиваются не столько за счет предварительных проверок, сколько за счет опыта инженеров и строгих процедур восстановления.

При этом риски ошибки в АСУ ТП выше, чем в классическом IT. Стоит допустить ошибку в работе с контроллером, который отвечает за технологический процесс, как техпроцесс начинает идти по неверному сценарию, что может повлечь нежелательные последствия: производственный брак, простой линии, выход из строя оборудования и прочее.

Риски отсутствия централизованного подхода. Вендоры начинают встраивать элементы контроля версий в свои IDE — это позитивный тренд, поскольку централизованного управления изменениями в АСУ ТП до сих пор почти нет. На практике часто используется простая схема: на инженерной станции установлена среда разработки проектов ПЛК, доступ к ней осуществляется через локальную учетную запись с минимальными требованиями к безопасности — без сложных паролей, журналирования и разграничения прав. Любой инженер из службы АСУ ТП может внести изменения в код на свое усмотрение, не сохранив резервную копию в доверенном хранилище. В результате при сбое или конфликте версий невозможно точно определить, кто и какие правки внес, и где находится актуальная копия проекта.

В редких случаях условно централизованный внутренний процесс можно обнаружить на базе кастомизаций. Например, есть общий сетевой ресурс, куда по внутренним инструкциям инженеры отправляют проекты. Обычно такие механизмы разрабатывают сами предприятия с высоким уровнем цифровой зрелости. На это тратится много ресурсов, а у регуляторов могут возникнуть вопросы относительно сертификации и обеспечения безопасности, особенно если критичный процесс реализован на зарубежных ОС.

Технические особенности специализированных решений для ПЛК в АСУ ТП

Эти особенности обусловлены сложностью систем АСУ ТП, многие их них относятся  к объектам критической информационной инфраструктуры.

Хранение «золотых» эталонных конфигураций для быстрого восстановления. При модернизации и импоротзамещении АСУ ТП предприятия часто привлекают интегратора АСУ ТП в качестве подрядчика. Эксперты грамотно выполняют сложный процесс пусконаладки, который, как правило, происходит постепенно, уровень за уровнем, без полной остановки производства. «Золотые копии» работ подрядчика хранятся, чтобы в дальнейшем служба эксплуатация могла разобраться в ходе внесения изменений. Также «золотые копии» помогают максимально быстро восстановить настройки, когда контроллер выходит из строя или надо запустить ранее отлаженный проект на новом контроллере.

Интеграция с Active Directory/LDAP для управления доступом. Персонализированные учетные записи в сегментах АСУ ТП уже появляются, но этот процесс идет медленно. До сих пор инженеры часто работают под одной учетной записью. Интеграция со службой каталогов для управления парольной политикой и разграничения доступа позволяет организовать централизованное управление учетными записями и полномочиями.

Поддержка работы в условиях ограниченной сети. Для сокращения возможных векторов атак объекты КИИ зачастую работают on-premise, без выхода в Интернет. Это касается и АСУ ТП, и  хотя вопрос конфиденциальности стоит не так остро, но вопросы целостности и доступности критически важны.

Влияние контроля версий для ПЛК на промышленную кибербезопасность

Внедрение систем контроля версий проектов ПЛК может значительно повысить информационную безопасность предприятия.

Снижение инсайдерского риска. Значительная часть инцидентов кибербезопасности на предприятиях связана не с внешними атаками, а с действиями сотрудников и подрядчиков. Случается, что внутренний нарушитель — не инсайдер, он что-то перепутал по незнанию или неопытности, но потери от этого не меньше. Организованный контроль версий позволяет выявить, кто и когда внес изменения в проект и загрузил его на контроллер
Цифровой след для расследований. Поскольку версии позволяют отследить значимые действия с проектами ПЛК, они становятся доказательной базой при внутреннем расследовании или при проверке регулятора.

Быстрая реакция на сбои. В случае кибератаки или ошибки инженера, можно быстро восстановить проверенную версию проекта из архива, а не заниматься «археологией по флешкам». Это особенно важно для АСУ ТП, где простой даже на час может обернуться для предприятия потерями в миллионы рублей.

Интеграция с SOC и SIEM. Контроль версий помогает генерировать события ИБ. Если интеграция проведена, то при попытке загрузки нового проекта или внесении изменений в код, система покажет и поможет определить: сделано это в рамках производственной задачи или изменения не задекларированы, произошли вследствие несанкционированного проникновения.

Практическая ценность системы версий проектов ПЛК для предприятия

Управление версиями ПЛК дает предприятиям ряд преимуществ как в части соблюдения требований регуляторов, так и внутренней дисциплины.

Нормативные требования. В IEC 62443 прямо указана необходимость процедур change management, а ФСТЭК России в новых методических рекомендациях акцентирует внимание именно на контроле изменений проектов ПЛК. Требования регуляторов — весомая причина, по которой все больше предприятий переходят от «бумажного соответствия» к практической реализации контроля версий.

Аудиты и проверки. При наличии системы версий можно за минуты показать аудитору историю изменений и регламенты — вместо недельной ручной подготовки. Любая другая отчетность также строится легче и для руководителя, и для инженера, если можно посмотреть, какие практики кода применялись.

Оперативное восстановление. MTTR (mean time to recovery) — ключевой показатель устойчивости киберфизических систем. В любой момент на предприятии что-то может сломаться, пойти не по плану, и это не всегда от зависит от человеческого фактора. Но система контроля версий дает уверенность, что инженеры в любой момент смогут сделать «как два дня назад, когда все работало хорошо».

Дисциплина в команде. Если инженеры знают, что каждый их шаг фиксируется, то они действуют более осторожно и собранно, снижается количество «ночных патчей» на объекте без уведомления. Порой инженеру, который хорошо знает свою линию, не хочется согласовывать работу, есть соблазн быстро внести изменения так, чтобы никого не беспокоить. При наличии контроля такое своеволие постепенно сходит на нет.

Тренд на организацию сквозного процесса управления изменениями. Заказчики все чаще требуют от интеграторов демонстрацию сквозного процесса управления изменениями, а не «коробочных» неадаптированных решений. Они хотят инвестировать в новые бизнес-процессы, которые удобны и понятны, приносят ощутимую пользу сотрудникам и не вызывают саботажа.

Ошибки и риски при отсутствии системы контроля версий

Можно выделить типичные негативные ситуации, которые повторяются на предприятиях, где не ведется контроль версий ПЛК.

Флешка как «единая база данных». До сих пор встречаются объекты, где последний актуальный проект хранится у дежурного инженера на USB-накопителе, на рабочем компьютере сотрудника или сохраняется на неучтенный файловый сервер, который никто не администрирует, на котором нет разграничения прав доступа и резервного копирования.

Конфликтные версии. Когда у предприятия нет процедуры ведения актуальных версий, то изменения могут быть внесены не в актуальную версию, а в одну из предыдущих. При этом те изменения, которые вносились прежде и сформировали актуальную версию, теряются.

Случайные потери. Если на предприятии нет процедуры резервного копирования, в частности, единственный экземпляр проекта может потеряться в процессе обновления, настройки, при выходе из строя жесткого диска.

Подмена или порча файлов проектов. Злоумышленник может подменить файлы проекта, скомпрометировать файловый сервер, а поскольку проекты в АСУ ТП сложные, при подмене файла проект, скорее всего, перестанет корректно работать.

Резюме: контроль версий ПЛК — must have предприятий, не желающих рисковать стабильностью работы АСУ ТП

Практика показывает: довольно большое число инцидентов в АСУ ТП связано  с изменениями в коде ПЛК без фиксации и контроля. Там, где проекты до сих пор хранятся на флешках или на рабочих столах инженеров, риск потери данных или подмены логики — вопрос времени.

Система контроля версий позволяет быстро вернуть проверенную конфигурацию после сбоя, показать полную историю изменений за минуты и зафиксировать, кто именно внес изменения в код контроллера. Это не «дополнительная опция», а инструмент, который снижает среднее время реагирования закрывает все более строгие требования ФСТЭК России и способствует защите производства от простоев и аварий.

Предприятия, которые внедряют решения для контроля версий ПЛК, фактически ставят барьер как для ошибок персонала, так и для атак извне. Все остальные же продолжают играть в лотерею с безопасностью и стабильностью своих процессов.