Журнал "Information Security/ Информационная безопасность" #5, 2025

Контроль версий в промышленно- сти – это не просто инструмент удобства инженеров, а фундаментальный эле- мент кибербезопасности. Однако есть сложности в использовании на пред- приятиях традиционных систем контро- ля версий, ведь среды разработки про- ектов ПЛК в АСУ ТП имеют свою спе- цифику. Рассмотрим этот вопрос под- робнее. Несовместимость с ИТ-практиками Такие известные решения для конт- роля версий, как Git, к работе с АСУ ТП практически не применимы. При- чина простая: каждая среда разработ- ки предполагает свои подходы к хра- нению и обработке кода. Проект может храниться, например, в виде набора файлов, либо одного большого бинар- ного файла, который умеет читать только проприетарная среда разра- ботки. В промышленности почти все проекты ПЛК – это бинарные или полубинарные форматы, завязанные на проприетарные среды, такие как TIA Portal от Siemens, Unity Pro от Schneider Electric, CODESYS и др. Тогда как Git изначально был ориен- тирован на работу с исходными кодами ядра Linux, то есть с множеством небольших текстовых файлов. Форматами, завязанными на проприе- тарные среды, продолжают пользоваться многие российские предприятия, где старые производственные линии остают- ся на зарубежных решениях. Однако надо отметить, что в свете тренда на импортозамещение успешно развивают- ся и российские среды разработки. Неплохие результаты, например, у ком- паний "Прософт-Системы", ТРЭИ и неко- торых других. Новые производственные линии сейчас изначально строятся на российских продуктах. Но мало просто импортозаместить среду разработки АСУ ТП – нужно обес- печить ее корректную работу с ПЛК и настроить так, чтобы она поддержива- ла параметры, критичные для техноло- гического процесса. Это трудоемкая и дорогостоящая задача: любая ошибка в конфигурации может привести к сбою и потребовать повторной настройки, а это отнимет часы или даже дни. Имен- но поэтому сейчас в приоритете не рас- ширенные функций, а повышение надеж- ности базового функционала, включая возможность версионирования проектов ПЛК. Система, которая позволяет быстро откатиться к стабильной версии и вос- становить работу за несколько минут, становится не просто удобством, а инструментом экономии ресурсов и снижения рисков простоя. Работа в условиях реальности цеха В отличие от классической ИТ-разра- ботки, изменения в логике ПЛК в АСУ ТП могут вноситься прямо на производ- стве и в срочном порядке – в соответ- ствии с текущими задачами, часто без полноценного документирования и тести- рования. Горячие правки особенно характерны для металлургии и пищевой промышленности. С тестированием в АСУ ТП ситуация принципиально сложнее: невозможно воссоздать все сценарии технологиче- ского процесса в эмуляторах, а имею- щиеся тестовые стенды редко покры- вают полный набор производственных условий. Поэтому надежность и пред- сказуемость изменений обеспечиваются не столько за счет предварительных проверок, сколько за счет опыта инже- неров и строгих процедур восстановле- ния. При этом риски ошибок в АСУ ТП выше, чем в классическом ИТ. Стоит допустить неточность в работе с конт- роллером, как соответствующий техпро- цесс начинает идти по неверному сце- нарию. А это – производственный брак, простой линии, выход из строя оборудо- вания и пр. Отсутствие централизованного подхода Вендоры начинают встраивать эле- менты контроля версий в свои IDE – это позитивный тренд, поскольку цент- рализованного управления изменения- ми в АСУ ТП до сих пор почти нет. На практике часто используется простая схема: на инженерной станции уста- новлена среда разработки проектов ПЛК, доступ к ней осуществляется через локальную учетную запись с минималь- ными требованиями к безопасности – без сложных паролей, журналирования и разграничения прав. Любой инженер из службы АСУ ТП может внести изме- нения в код на свое усмотрение, не сохранив резервную копию в доверен- ном хранилище. В результате при сбое или конфликте версий невозможно точно определить, кто какие правки внес и где находится актуальная копия проекта. В редких случаях условно централи- зованный внутренний процесс можно обнаружить на базе кастомизаций. Например, есть общий сетевой ресурс, куда по внутренним инструкциям инже- неры отправляют проекты. Обычно такие механизмы разрабатывают предприятия с высоким уровнем цифровой зрелости. На это тратится много ресурсов, однако у регуляторов могут возникнуть вопросы относительно сертификации и обеспече- ния безопасности, особенно если кри- тичный процесс реализован на зару- бежных ОС. Технические особенности решений для ПЛК в АСУ ТП Эти особенности обусловлены слож- ностью систем АСУ ТП, многие их них относятся к объектам критической информационной инфраструктуры. 56 • СПЕЦПРОЕКТ Контроль версий проектов ПЛК в АСУ ТП аботу станков, линий и технологических комплексов опреде- ляют проекты ПЛК, и любое несанкционированное изменение в их коде может привести не только к аварии и простоям, но и к угрозе безопасности людей. При этом на многих пред- приятиях до сих пор отсутствует системный контроль версий: рабочие проекты хранятся на отдельных компьютерах или даже на флешках. Р Владислав Ганжа, руководитель производственного направления лаборатории кибербезопасности UDV Group Фото: UDV Group