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