Linux в АСУ ТП нельзя обновлять как офисный сервер
Обновление Linux в корпоративной инфраструктуре обычно включает запуск пакетного менеджера, который обращается к репозиторию, получает пакеты, подтягивает зависимости и устанавливает обновления. В случае проблем их решают в рабочем порядке, откатывая пакеты или восстанавливая систему из резервной копии. Однако в промышленном контуре такая логика не работает, поскольку серверы и рабочие станции АСУ ТП часто изолированы от интернета, что исключает прямой доступ к репозиториям разработчиков. Об этом сообщает «Код Дурова».
«В изолированном Linux-контуре АСУ ТП задача состоит не в том, чтобы перенести несколько пакетов на сервер. Нужно заранее собрать зависимости под фактическую версию ОС, проверить совместимость с прикладным ПО, безопасно провести комплект через границу контура и зафиксировать изменение. Иначе обновление превращается в эксперимент на работающей промышленной системе», — сообщает «Код Дурова».
Изоляция промышленной сети — это осознанная архитектурная мера, которая снижает вероятность внешнего воздействия на системы управления и ограничивает неконтролируемые соединения. Однако вместе с интернетом контур теряет привычный способ получения обновлений. Linux-система не существует отдельно от зависимостей, и даже небольшой компонент может требовать библиотеки, системные утилиты и пакеты определенных версий. Если хотя бы один элемент собран не под ту среду, установка может завершиться ошибкой. Хуже, если обновление формально прошло успешно, но позже выяснилось, что отдельная функция стала недоступна, драйвер работает иначе или прикладное ПО начало вести себя нестабильно.
Массовый переход промышленных предприятий на отечественные дистрибутивы Linux сделал задачу еще актуальнее. На значимых объектах КИИ управление обновлениями входит в регулируемый контур защиты. Изменения нужно предварительно проверять, документировать и внедрять так, чтобы сохранялась возможность восстановления системы. Это означает, что доставка пакетов в изолированный сегмент уже не может считаться внутренней технической процедурой службы эксплуатации. Для ИБ и руководства это часть управляемого процесса защиты объекта.
Когда речь заходит о доставке обновлений в изолированный контур, часто кажется, что ручная схема устарела. Архив на флешке, перенос через разрешенный канал, установка на месте — все это выглядит слишком просто для современной инфраструктуры. Но в промышленной среде простое решение не всегда означает незрелое. Если в сегменте десять узлов, которые обновляют пару раз в год, ручная доставка может быть самым практичным вариантом. Она требует дисциплины, но не требует лишней инфраструктуры, которая большую часть времени будет простаивать.
На первый взгляд удобно заранее собрать наборы пакетов для разных дистрибутивов и держать их «на всякий случай». Инженер едет на объект, выбирает подходящий архив, переносит его в контур и устанавливает. На практике эта схема быстро ломается. Различаются релизы ОС, минорные версии, состав уже установленных пакетов, состояние конкретной машины, требования прикладного ПО и локальные доработки. Архив, собранный для другого состояния среды, может потребовать другую версию библиотеки или заменить компонент, от которого зависит промышленное приложение.
Ручная доставка пакетов допустима только до тех пор, пока она не превращается в ручной хаос. Если архивы называются непонятно, документы не фиксируют состав, контрольные суммы не сверяются, носители ходят между объектами без проверки, а установка не отражается в журнале, это уже не простая архитектура. Это потеря контроля.
Обновление не заканчивается сообщением пакетного менеджера об успешной установке. Для промышленной инфраструктуры важно зафиксировать, что именно изменилось. В журнале должны остаться целевая машина, перечень и версии установленных пакетов, дата обновления, ответственный инженер и основание для изменения. Без этих данных предприятие не сможет быстро понять, какие узлы уже обновлены, а какие работают в прежней конфигурации.
Успешная загрузка ОС после обновления ничего не доказывает. Linux может стартовать, пакетный менеджер может показать отсутствие ошибок, службы могут подняться, но прикладной промышленный сценарий все равно может быть нарушен. Проверять нужно то, от чего зависит работа объекта: драйверы, сетевые соединения, обмен по промышленным протоколам, связанные сервисы, работу SCADA, взаимодействие с OPC-сервером, поведение прикладного ПО, доступность функций, которые критичны для операторов и инженеров.
У ручного подхода есть естественный предел. Пока машин мало, обновления редкие, конфигурации понятны, а процедура четко описана, временная машина и проверенный архив могут быть практичнее отдельного репозитория. Но по мере роста парка этот метод начинает создавать задержки и ошибки. Если в изолированном сегменте десятки или сотни однотипных машин, ручная доставка становится слишком трудоемкой. Если обновления выходят регулярно, служба эксплуатации тратит много времени на подготовку комплектов. Если невозможно быстро подтвердить, какие версии установлены на всех узлах, ручной режим уже мешает управлению.
Изоляция АСУ ТП часто воспринимается как сильная мера безопасности. И это верно. Но изолированный контур не должен превращаться в черный ящик, куда изменения заносятся вручную, а потом живут без понятной истории. Предприятие должно знать, какие пакеты установлены, откуда они получены, когда перенесены, кем проверены, на какие узлы поставлены, какие версии изменились и как можно вернуться назад. Иначе изоляция снижает один риск, но создает другой — риск неконтролируемых изменений внутри самого контура.
Главная ошибка — относиться к обновлению Linux в промышленном контуре как к обычной ИТ-операции. В офисной инфраструктуре пакет чаще всего влияет на сервис. В АСУ ТП он может повлиять на систему, которая участвует в управлении оборудованием, обмене с контроллерами, визуализации, сборе данных или выполнении регламентных действий. Поэтому доставка ПО в изолированный контур должна включать весь жизненный цикл изменения: сбор комплекта под фактическую версию ОС, проверка зависимостей, проверка источников, безопасный перенос, контроль носителя, установка в согласованное окно, проверка промышленного сценария, фиксация результата, подготовленный откат.
Подписывайтесь на наш Telegram-канал, чтобы быть в курсе всех новостей и событий Рунета.
