 |
UDV Group: Контроль версий проектов ПЛК в АСУ ТП
Работу станков, линий и технологических комплексов определяют проекты ПЛК, и любое несанкционированное изменение в их коде может привести не только к аварии и простоям, но и к угрозе безопасности людей. При этом на многих предприятиях до сих пор отсутствует системный контроль версий: рабочие проекты хранятся на отдельных компьютерах или даже на флешках.
Автор: Владислав Ганжа, руководитель производственного направления лаборатории кибербезопасности UDV Group
Контроль версий в промышленности – это не просто инструмент удобства инженеров, а фундаментальный элемент кибербезопасности. Однако есть сложности в использовании на предприятиях традиционных систем контроля версий, ведь среды разработки проектов ПЛК в АСУ ТП имеют свою специфику. Рассмотрим этот вопрос подробнее.
Несовместимость с ИТ-практиками
Такие известные решения для контроля версий, как Git, к работе с АСУ ТП практически не применимы. Причина простая: каждая среда разработки предполагает свои подходы к хранению и обработке кода. Проект может храниться, например, в виде набора файлов, либо одного большого бинарного файла, который умеет читать только проприетарная среда разработки. В промышленности почти все проекты ПЛК – это бинарные или полубинарные форматы, завязанные на проприетарные среды, такие как TIA Portal от Siemens, Unity Pro от Schneider Electric, CODESYS и др. Тогда как Git изначально был ориентирован на работу с исходными кодами ядра Linux, то есть с множеством небольших текстовых файлов.
Форматами, завязанными на проприетарные среды, продолжают пользоваться многие российские предприятия, где старые производственные линии остаются на зарубежных решениях. Однако надо отметить, что в свете тренда на импортозамещение успешно развиваются и российские среды разработки. Неплохие результаты, например, у компаний "Прософт-Системы", ТРЭИ и некоторых других. Новые производственные линии сейчас изначально строятся на российских продуктах.
Но мало просто импортозаместить среду разработки АСУ ТП – нужно обеспечить ее корректную работу с ПЛК и настроить так, чтобы она поддерживала параметры, критичные для технологического процесса. Это трудоемкая и дорогостоящая задача: любая ошибка в конфигурации может привести к сбою и потребовать повторной настройки, а это отнимет часы или даже дни. Именно поэтому сейчас в приоритете не расширенные функций, а повышение надежности базового функционала, включая возможность версионирования проектов ПЛК. Система, которая позволяет быстро откатиться к стабильной версии и восстановить работу за несколько минут, становится не просто удобством, а инструментом экономии ресурсов и снижения рисков простоя.
Работа в условиях реальности цеха
В отличие от классической ИТ-разработки, изменения в логике ПЛК в АСУ ТП могут вноситься прямо на производстве и в срочном порядке – в соответствии с текущими задачами, часто без полноценного документирования и тестирования. Горячие правки особенно характерны для металлургии и пищевой промышленности.
С тестированием в АСУ ТП ситуация принципиально сложнее: невозможно воссоздать все сценарии технологического процесса в эмуляторах, а имеющиеся тестовые стенды редко покрывают полный набор производственных условий. Поэтому надежность и предсказуемость изменений обеспечиваются не столько за счет предварительных проверок, сколько за счет опыта инженеров и строгих процедур восстановления.
При этом риски ошибок в АСУ ТП выше, чем в классическом ИТ. Стоит допустить неточность в работе с контроллером, как соответствующий техпроцесс начинает идти по неверному сценарию. А это – производственный брак, простой линии, выход из строя оборудования и пр.
Отсутствие централизованного подхода
Вендоры начинают встраивать элементы контроля версий в свои IDE – это позитивный тренд, поскольку централизованного управления изменениями в АСУ ТП до сих пор почти нет. На практике часто используется простая схема: на инженерной станции установлена среда разработки проектов ПЛК, доступ к ней осуществляется через локальную учетную запись с минимальными требованиями к безопасности – без сложных паролей, журналирования и разграничения прав. Любой инженер из службы АСУ ТП может внести изменения в код на свое усмотрение, не сохранив резервную копию в доверенном хранилище. В результате при сбое или конфликте версий невозможно точно определить, кто какие правки внес и где находится актуальная копия проекта.
В редких случаях условно централизованный внутренний процесс можно обнаружить на базе кастомизаций. Например, есть общий сетевой ресурс, куда по внутренним инструкциям инженеры отправляют проекты. Обычно такие механизмы разрабатывают предприятия с высоким уровнем цифровой зрелости. На это тратится много ресурсов, однако у регуляторов могут возникнуть вопросы относительно сертификации и обеспечения безопасности, особенно если критичный процесс реализован на зарубежных ОС.
Технические особенности решений для ПЛК в АСУ ТП
Эти особенности обусловлены сложностью систем АСУ ТП, многие их них относятся к объектам критической информационной инфраструктуры.
1. Хранение золотых эталонных конфигураций для быстрого восстановления. При модернизации и импортозамещении АСУ ТП предприятия часто привлекают интегратора АСУ ТП в качестве подрядчика. Эксперты грамотно выполняют сложный процесс пусконаладки, который, как правило, происходит постепенно, уровень за уровнем, без полной остановки производства. Золотые копии работ подрядчика хранятся, чтобы в дальнейшем служба эксплуатация могла разобраться в ходе внесения изменений. Золотые копии также помогают максимально быстро восстановить настройки, если контроллер выходит из строя или надо запустить ранее отлаженный проект на новом контроллере.
2. Интеграция с Active Directory/LDAP для управления доступом. Персонализированные учетные записи в сегментах АСУ ТП уже появляются, но этот процесс идет медленно. До сих пор инженеры часто работают под одной учетной записью. Интеграция со службой каталогов для управления парольной политикой и разграничения доступа позволяет организовать централизованное управление учетными записями и полномочиями.
3. Поддержка работы в условиях ограниченной сети. Для сокращения возможных векторов атак объекты КИИ зачастую работают on-premise, без выхода в Интернет. Это касается и АСУ ТП, и хотя вопрос конфиденциальности стоит не так остро, но вопросы целостности и доступности критически важны.
Внедрение систем контроля версий проектов ПЛК может значительно повысить информационную безопасность предприятия.
• Значительная часть инцидентов кибербезопасности на предприятиях связана не с внешними атаками, а с действиями сотрудников и подрядчиков. Случается, что внутренний нарушитель – не инсайдер, он что-то перепутал по незнанию или неопытности. Ущерб, впрочем, от этого меньше не становится. Организованный контроль версий позволяет выявить, кто и когда внес изменения в проект и загрузил его на контроллер.
• Поскольку версии позволяют отследить значимые действия с проектами ПЛК, они становятся доказательной базой при внутреннем расследовании или при проверке регуляторов.
• В случае кибератаки или ошибки инженера можно быстро восстановить проверенную версию проекта из архива, а не заниматься археологией по флешкам. Вспомним, что даже часовой простой АСУ ТП может обернуться для предприятия потерями в миллионы рублей.
• Контроль версий помогает генерировать события ИБ. Если проведена интеграция с SIEM и SOC, то при попытке загрузки нового проекта или внесении изменений в код система покажет и поможет определить: сделано это в рамках производственной задачи или изменения не задекларированы, произошли вследствие несанкционированного проникновения.
•
Практическая ценность управления версиями
Управление версиями ПЛК дает предприятиям ряд преимуществ как в части соблюдения требований регуляторов, так и внутренней дисциплины.
• В IEC 62443 прямо указана необходимость процедур Change Management, а ФСТЭК России в новых методических рекомендациях акцентирует внимание именно на контроле изменений проектов ПЛК. Требования регуляторов – весомая причина, по которой все больше предприятий переходят от бумажного соответствия к практической реализации контроля версий.
• При наличии системы версий можно за минуты показать аудитору историю изменений и регламенты – вместо недельной ручной подготовки. Любая другая отчетность строится легче и для руководителя, и для инженера, если можно посмотреть, какие практики кода применялись.
• MTTR (Mean Time to Recovery) – ключевой показатель устойчивости киберфизических систем. В любой момент на предприятии что-то может сломаться, пойти не по плану, и это не всегда зависит от человеческого фактора. Но система контроля версий дает уверенность, что инженеры в любой момент смогут сделать "как два дня назад, когда все работало хорошо".
• Если инженеры знают, что каждый их шаг фиксируется, они действуют более осторожно и собранно, снижается количество ночных патчей на объекте без уведомления. Порой инженеру, который хорошо знает свою линию, не хочется согласовывать работы. И есть соблазн быстро внести изменения так, чтобы никого не беспокоить. При наличии контроля такое своеволие постепенно сходит на нет.
•
Заказчики все чаще требуют от интеграторов демонстрацию сквозного процесса управления изменениями, а не коробочных неадаптированных решений. Они хотят инвестировать в бизнес-процессы, которые удобны и понятны, приносят ощутимую пользу сотрудникам и не вызывают саботажа.
Можно выделить типичные негативные последствия, которые повторяются на предприятиях, где не ведется контроль версий ПЛК.
• До сих пор встречаются объекты, где последний актуальный проект хранится у дежурного инженера на USB-накопителе, на рабочем компьютере сотрудника или сохраняется на неучтенный файловый сервер, который никто не администрирует, на котором нет разграничения прав доступа и резервного копирования.
• Когда у предприятия нет процедуры ведения актуальных версий, то изменения могут быть внесены не в актуальную версию, а в одну из предыдущих. При этом те изменения, которые вносились прежде и сформировали актуальную версию, теряются.
• Если на предприятии не предусмотрены процедуры резервного копирования, единственный экземпляр проекта может потеряться в процессе обновления, настройки, при выходе из строя жесткого диска.
• Злоумышленник может подменить файлы проекта, скомпрометировать файловый сервер, а поскольку проекты в АСУ ТП сложные, при подмене файла проект, скорее всего, перестанет корректно работать.
Вывод
Вывод простой: контроль версий ПЛК – обязательный элемент для предприятий, не желающих рисковать стабильностью работы АСУ ТП
Практика показывает, что довольно большое число инцидентов в АСУ ТП связано с изменениями в коде ПЛК без фиксации и контроля. Там, где проекты до сих пор хранятся на флешках или на рабочих столах инженеров, риск потери данных или подмены логики – вопрос времени.
Система контроля версий позволяет быстро вернуть проверенную конфигурацию после сбоя, показать полную историю изменений за минуты и зафиксировать, кто именно внес изменения в код контроллера. Это не дополнительная опция, а инструмент, который снижает среднее время реагирования закрывает все более строгие требования ФСТЭК России и способствует защите производства от простоев и аварий.
Источник: https://www.itsec.ru/articles/kontrol-versij-plk-v-asu-tp
Контактное лицо: UDV Group
Компания: UDV Group
Добавлен: 20:56, 23.12.2025
Количество просмотров: 270
Страна: Россия
| Индид расширила возможности облачного сервиса Indeed MFA, Индид, 21:46, 12.03.2026, Россия70 |
| Компания «Индид», российский разработчик комплекса решений в области защиты айдентити, представила обновление облачного сервиса многофакторной аутентификации Indeed MFA. Среди ключевых изменений — гибкое управление правилами предварительной аутентификации, расширенная поддержка RADIUS-атрибутов, улучшенный контроль синхронизации каталога пользователей и возможность назначения приоритетного токена. |
| «ДиалогНаука» выполнила тест на проникновение для КБ «Москоммерцбанк» (АО), АО ДиалогНаука, 21:08, 12.03.2026, Россия72 |
| Компания «ДиалогНаука», системный интегратор в области информационной безопасности, провела аудит информационной безопасности инфраструктуры КБ «Москоммерцбанк» (АО). Был проведен тест на проникновение, позволяющий определить степень защищённости автоматизированных систем банка от внешних и внутренних атак со стороны потенциальных злоумышленников. |
|
|
