UDV Group: Успешный аудит не гарантирует восстановление после сбоя

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

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

Тему контроля версий проектов ПЛК в авторском материале для ITWeek разобрал Владислав Ганжа, директор лаборатории кибербезопасности UDV Group. Он отметил, что дрейф конфигурации становится для промышленности не только техническим, но и управленческим риском: без достоверной истории изменений предприятие может пройти аудит, но оказаться не готовым к реальному восстановлению после сбоя.

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

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

«На промышленных объектах риск часто накапливается не из-за одного грубого нарушения, а из-за рутины. Инженер поправил логику, решил производственную задачу, убедился, что оборудование работает, но не загрузил обновленный проект в хранилище или не описал изменение. Через несколько месяцев уже невозможно понять, какая версия является актуальной и можно ли на нее опереться при восстановлении», - отметил Владислав Ганжа, директор лаборатории кибербезопасности UDV Group.

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

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

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

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

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

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