Как защитить код на ПЛК: 3 настройки CODESYS до первого инцидента

Автор: Владислав Иванов, старший инженер АСУ ТП компании UDV Group

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

CODESYS используется в миллионах устройств разных производителей, включая контроллеры, которые работают на российских промышленных объектах. Встроенные механизмы защиты там уже есть: шифрование соединения между IDE и контроллером, подпись и шифрование приложения, ролевая модель доступа. Проблема в том, что на реальных объектах эти настройки часто оставляют «на потом», потому что ПЛК уже запущен, линия работает, а любое изменение кажется лишним риском.

В этой статье разберем три настройки CODESYS, которые стоит проверить до первого инцидента: только шифрованное соединение с ПЛК, запрет загрузки неподписанного кода, шифрование приложения и разграничение прав. Отдельно покажем, почему перед изменениями нужен пилотный контур, резервная копия проекта и понятный сценарий восстановления.

Сначала важное предупреждение

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

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

Почему одного пароля недостаточно

Начиная с CODESYS V3.5.17.0 управление пользователями включается принудительно по умолчанию: перед первым успешным подключением нужно активировать user management и создать администратора. Это правильная отправная точка, но пароль не закрывает все вопросы безопасности.

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

В 2026 году Nozomi Networks Labs показала, почему это не теоретический риск. Исследователи разобрали цепочку уязвимостей в CODESYS Control Runtime for Raspberry Pi SL: CVE-2025-41658, CVE-2025-41659 и CVE-2025-41660. В связке они позволяли пользователю с низкими привилегиями получить доступ к криптографическим материалам, работать с резервной копией приложения и заменить программу на контроллере.

CODESYS закрыла эти уязвимости в обновлениях и добавила настройку, которая запрещает передачу неподписанного приложения для пользователей Service-группы в новых установках. Но обновление исполняемой среды не отменяет вопрос для действующих объектов: включены ли на конкретных ПЛК защитные механизмы, которые были доступны и раньше.

Из этого следует простой практический вывод: защиту ПЛК нельзя сводить к логину и паролю. Нужно ограничить канал связи, происхождение загружаемого кода и права пользователей.

Где обычно возникает риск

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

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

Третья зона риска: сертификаты и восстановление. Подпись кода и шифрование приложения требуют порядка: кто выдает сертификат, где хранится закрытый ключ, кто имеет право подписывать проект, как отзывается доступ при смене подрядчика или увольнении инженера. Если такого порядка нет, защиту часто не включают не из-за незнания интерфейса, а потому что сертификаты воспринимаются как риск для обслуживания. Не менее опасна обратная ситуация, когда ключ потерян и предприятие само не может быстро восстановить собственный проект.

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

Что требует регулятор

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

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

Три настройки, которые нельзя оставлять на потом

Первый базовый шаг: включить только шифрованное соединение между средой разработки и ПЛК. В CODESYS это режим Enforce encrypted communication. При его включении обмен с контроллером идет по защищенному каналу, а разработчик отдельно предупреждает, что отключать шифрованную коммуникацию не рекомендуется, особенно при включенном user management.

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

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

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

Третий шаг: включить шифрование приложения и нормально настроить роли. Шифрование ограничивает возможность прочитать или разобрать загружаемый код. Это защита не только от атаки, но и от утечки инженерного know-how: в логике ПЛК часто зашиты режимы работы, ограничения, последовательности, аварийные сценарии и особенности конкретной линии. CODESYS описывает сценарий, при котором boot application передается в нечитаемом виде, а для загрузки на контроллер используется подходящий сертификат.

Ролевая модель решает другую задачу: ограничивает ущерб от ошибки или компрометации учетной записи. Оператору не нужны права на изменение логики. Подрядчику не нужен постоянный административный доступ. Инженеру обслуживания не всегда нужен полный набор прав на файловую систему и конфигурацию. CODESYS позволяет управлять пользователями и группами на уровне устройства, поэтому общие логины и максимальные права «для удобства» лучше заменить индивидуальными учетными записями и понятными ролями.

Практический чек-лист для инженера

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

1. Включить только шифрованное соединение с ПЛК. В CODESYS это настраивается через Device, Change Runtime Security Policy, Communication, Enforced encryption. Альтернативный путь: Device Security Settings, CmpSecureChannel, значение ONLY_ENCRYPTED. После применения политики текущая сессия может разорваться, это нормальное поведение. Следующее подключение IDE к контроллеру должно идти уже по защищенному каналу.
2. Запретить загрузку неподписанного кода. Для этого в Device Security Settings нужно найти раздел CmpApp и перевести EnforceSignedCode в значение YES. После включения политики контроллер должен отклонять приложение без валидной цифровой подписи. Это защищает от ситуации, когда на ПЛК загружается код, происхождение которого предприятие не может подтвердить.
3. Настроить сертификаты для подписи и шифрования приложения. Публичный сертификат нужно добавить в доверенные на ПЛК через View, Security Screen, Devices, Trusted Certificates. В среде разработки на вкладке User нужно выбрать сертификат для цифровой подписи и включить принудительное подписание и шифрование downloads, online changes и boot applications.
4. Включить шифрование приложения. В дереве проекта нужно открыть свойства объекта Application, перейти на вкладку Security, выбрать Protection, Encryption with certificates, добавить сертификат для шифрования и включить Digitally sign application code. После этого проект при загрузке будет шифроваться и подписываться, а ПЛК сможет проверить подпись перед запуском.
5. Настроить роли и убрать лишние права. В редакторе устройства нужно открыть Users and Groups, синхронизироваться с ПЛК, создать индивидуальные учетные записи и распределить пользователей по ролям. Администратор должен управлять конфигурацией и доступами, инженер или сервисный специалист работать с логикой и обслуживанием, пользователь уровня просмотра только наблюдать параметры. Anonymous нужно отключить или максимально ограничить там, где анонимный доступ не нужен.
6. Проверить восстановление. После включения подписи и шифрования важно убедиться, что предприятие сможет восстановить проект при аварии, замене оборудования или потере инженерной станции. Для этого нужны актуальные резервные копии проекта, сертификатов и понятный порядок доступа к закрытым ключам.

Эта проверка занимает меньше времени, чем расследование изменения, которое невозможно привязать к конкретному пользователю или версии проекта. Но сам по себе чек-лист не заменяет полноценную защиту OT. ПЛК остается частью более широкого контура: сети, инженерных станций, удаленного доступа, мониторинга, журналирования и управления версиями логики.

Что остается за пределами настроек CODESYS

После включения шифрования, подписи приложения и ролевой модели остается еще один практический вопрос: какая версия логики сейчас реально работает на контроллере. CODESYS помогает ограничить доступ к ПЛК, защитить канал связи и запретить загрузку неподписанного приложения. Но эти настройки сами по себе не показывают, чем текущая логика отличается от предыдущей, кто внес изменение, когда его загрузили на ПЛК и можно ли быстро откатиться к рабочей версии.

На промышленном объекте логика контроллера редко остается неизменной после пусконаладки. Ее дорабатывают после изменения технологического процесса, замены оборудования, сервисных работ, аварийных правок или замечаний от эксплуатации. Если проекты хранятся только на инженерных станциях или в папках с названиями вроде final, final_new и final_2, предприятие быстро теряет уверенность в том, какой файл считается актуальным.

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

Здесь важно не смешивать две задачи. Настройки CODESYS отвечают за то, кто может подключиться к контроллеру и какой код он имеет право загрузить. Контроль версий отвечает за историю самой логики: что изменили, зачем изменили, кто согласовал правку и какая версия должна считаться рабочей. Без этого ответ на вопрос «что сейчас загружено в ПЛК» часто остается в памяти инженера, который последним подключался к контроллеру.

Как внедрять без риска для производства

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

После этого лучше выбрать пилотный участок: один тип контроллера, понятный сценарий обслуживания, ограниченный круг пользователей. На нем можно проверить, как шифрование влияет на работу инженерной станции, как будет устроена подпись приложения, кто станет владельцем сертификатов и какие права действительно нужны инженерам, операторам и подрядчикам.

Затем настройки нужно закрепить в регламенте. Новые контроллеры вводятся с принудительным шифрованием. Загрузка неподписанного кода запрещается. Приложения шифруются сертификатами. У каждого пользователя есть собственная учетная запись. Административные права выдаются под конкретные задачи. Доступ подрядчика ограничивается сроком работ. Anonymous отключается или жестко ограничивается. После изменения конфигурации проводится проверка, а не просто делается запись в документе.

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

Вывод

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

В CODESYS уже есть механизмы, которые закрывают часть базовых рисков на уровне контроллера. Но они работают только тогда, когда становятся частью эксплуатации: при вводе ПЛК, смене подрядчика, обновлении Runtime, переносе проекта, расширении участка и расследовании инцидентов.

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