Подрядчик в АСУ ТП меняет не файлы, а производство

На промышленном объекте подрядчик часто появляется в самый напряженный момент.

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

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

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

Журнал доступа не показывает, что осталось в контроллере

В корпоративной ИТ-среде контроль подрядчиков часто строится вокруг доступа. Кто подключился, когда, с какого адреса, к какому серверу, по какой заявке. Это важно и для АСУ ТП, но недостаточно. Промышленный контур живет не только учетными записями. Он живет программной логикой контроллеров.

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

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

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

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

Импортозамещение увеличило число вмешательств

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

В такой среде подрядчиков становится больше, а сами работы - сложнее. Один исполнитель поддерживает унаследованное оборудование, другой внедряет российское решение, третий настраивает шлюз, четвертый сопровождает SCADA, пятый отвечает за сеть. У каждого свой проект, свои библиотеки, свой ноутбук, своя инженерная среда и свое понимание актуальной версии.

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

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

Для промышленности это плохая модель. Память инженера не должна быть единственным источником правды о состоянии технологической системы.

Проект ПЛК стал самостоятельным объектом риска

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

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

MITRE отдельно описала подтехнику T0873.001 - Siemens Project File Format в базе ATT&CK for ICS. Она касается заражения проектов Siemens Step 7 и WinCC с последующей загрузкой в ПЛК штатными средствами разработки. Для рынка это важный сигнал: атакующий может работать не только через вредоносный исполняемый файл, но и через инженерный проект, который затем попадет в контроллер обычным промышленным способом.

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

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

«Считать из контроллера» не значит восстановить проект

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

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

Похожая логика встречается и на других платформах. В TIA Portal можно загрузить программу из контроллера, но это не гарантирует получение полного исходного проекта со всеми инженерными артефактами, сертификатами и зависимостями. Для Schneider Electric Modicon восстановление редактируемого проекта тоже зависит от того, какие данные были сохранены. Для российских ПЛК на базе CODESYS, ISaGRAF, MasterSCADA 4D и других платформ состав полноценного комплекта будет отличаться.

Файл с названием final, project_last или backup не решает задачу сам по себе. Для восстановления нужен проверенный комплект: проект, версия инженерной среды, компилятор, библиотеки, профили устройств, прошивки, аппаратные ревизии модулей, сетевые параметры и предыдущие подтвержденные версии для критичных элементов.

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

Наряд разрешает работу, но не подтверждает качество изменения

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

Запись «скорректирована программа управления» выглядит нейтрально. За ней может стоять изменение одного коэффициента, правка аварийной логики, замена библиотеки, обновление прошивки или полная загрузка проекта. Для документа это одна строка. Для производства - совершенно разные уровни риска.

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

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

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

Приемка должна быть общей

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

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

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

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

Такой подход снижает две крайности. С одной стороны, предприятие не ограничивается актом и доверием по умолчанию. С другой - не парализует производство согласованиями вокруг каждой мелкой настройки.

Эталон - это не архив, а возможность восстановиться

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

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

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

«Эталонная конфигурация - это не архив с удачным названием и не файл, который кто-то положил в сетевую папку. Это проверенный комплект, из которого систему действительно можно восстановить на установленном оборудовании. Если после работ подрядчика такой эталон не обновлен, предприятие не управляет изменением, а просто надеется, что нужная версия найдется в момент сбоя», - подчеркивает Владислав Ганжа, директор лаборатории кибербезопасности UDV Group.

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

Это неприятное открытие, но лучше сделать его до аварии.

Доверие к подрядчику должно быть проверяемым

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

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

Если такой цепочки нет, любая подрядная работа становится черным ящиком. Внутри него могло произойти все что угодно: нормальная правка, лишний доступ, забытая учетная запись, несогласованный online change, обновление библиотеки или изменение параметра, которое проявится только через месяц.

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

Подрядчик уходит, ответственность остается

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

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

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

Для завода это и есть зрелый контроль подрядчиков. Не тотальный запрет и не слепое доверие, а проверяемая цепочка изменений, в которой понятно, что было, что изменилось и как вернуться назад без импровизации на остановленной линии.