Алексей Петрухин: «Для промышленности важны не скорость изменений, а их предсказуемость»
О том, как в этой системе координат выстраивать архитектуру, мониторинг, взаимодействие ИТ, АСУТП и ИБ, рассказывает Алексей Петрухин, руководитель управления ИТ-инфраструктуры и технической поддержки крупной производственной компании.
У вас в контуре три завода в разных регионах. Насколько вообще сегодня возможно управлять такой инфраструктурой как единой системой, а не как набором отдельных площадок?
Вполне возможно. И нужно понимать, что единая инфраструктура не всегда означает централизованное управление. Тут мы имеем много факторов, влияющих на конечный результат. На практике я видел несколько сценариев.
Сценарий нового производства, когда в компании несколько объектов, еще нет локальных «устоев», принципов, все процессы формируются в одном ключе. В этой ситуации применению стандартизированных подходов и создание единой системы практически не вызывает сложностей.
Разберем более интересный и часто встречающийся сценарий объединения нескольких существующих инфраструктур в единый контур, например, при объединении компаний. Тут все намного сложнее и даже не всегда реализуемо в полной мере. Сложности образуются не только на техническом уровне (разное оборудование, разное ПО, самописные системы управления) но и на административном (отличается оргструктура, отличаются регламенты, бизнес-процессы). Но нужно признать, что не все площадки должны быть одинаковыми. В этом случае мы можем выстраивать какие-либо единые правила, например, единые формы учета информационных систем и оборудования, принципы предоставления доступа, управления изменениями, триггеры для систем мониторинга, принципы резервирования, реагирование на инциденты. При этом локальная специфика уже может жить внутри этого каркаса.
Для меня единая система — это система, в которой, разобравшись в инфраструктуре одного предприятия, я могу без проблем понять принцип организации инфраструктуры любого другого предприятия в контуре. Где я могу увидеть перечень активов и критичных активов, понять, где проходят границы контуров ответственности, кто является владельцем сервиса и какова последовательность действий в случае инцидента. Также показателем может служить возможность сравнивать инфраструктуры без существенного преобразования и переработки информации.
Если предприятие относится к субъектам КИИ, создание единой системы становится уже не просто желательным, а необходимым. Нужны системные подходы к документированию и регламентации объектов, единые средства мониторинга, единые подходы к защите объектов и правила реагирования на инциденты.
Такие подходы экономят ресурсы на каждой площадке, исключая дублирование операций.
Что в распределенной промышленной инфраструктуре сложнее всего? Поддерживать единые стандарты, обеспечивать доступность, быстро устранять сбои на местах или учитывать специфику каждой площадки?
Самое сложное — удержать баланс между едиными стандартами и спецификой конкретной площадки. Конечно, всегда хочется все унифицировать, написать регламенты, которые закрепят эту унификацию, но на практике на один завод это ложится идеально, второй оказывается обросшим наследием, где «исторически» одни и те же сотрудники ИТ обслуживают и корпоративный сегмент, и АСУТП, заведя серверы и АРМ АСУТП в тот же корпоративный домен Active Directory, а на третьем обнаруживаются АРМ с устаревшей ОС, участвующие в критичных процессах и настолько чувствительные, что любое изменение в ОС — обновление, установка или удаление компонентов — приходится проводить буквально хирургическим методом. Но если выбирать что-то одно, я бы поставил на первое место именно учет специфики каждой площадки.
Чем менее унифицирована инфраструктура, тем больше человеческих ресурсов она требует для обслуживания и тем сложнее разрабатывать общие изменения, потому что в промышленности инфраструктурный сбой приводит к отклонениям в выпуске продукции, браку, простоям оборудования, а иногда и к угрозам для здоровья. Здесь как раз и проявляется главное отличие промышленной инфраструктуры от классической корпоративной: требования к надежности, непрерывности и предсказуемости изменений здесь выше, а свободы для быстрых изменений меньше.
Где проходит граница между централизацией и автономией заводов? Какие решения должны приниматься из единого центра, а что разумнее оставлять на уровне площадок?
Я бы провел эту границу так: все, что формирует общую устойчивость группы, должно определяться из головного офиса. Все, что требует глубокого знания конкретных технологических процессов, должно оставаться на площадке, но в рамках единых правил.
В головном офисе должны определяться архитектурные стандарты, требования к уровню информационной безопасности, мониторингу, резервированию, журналированию событий на оборудовании, АРМ и серверах, управлению изменениями, логика сегментации сетей, используемое базовое ПО, ПО для администрирования, антивирусное ПО. А на заводах должны приниматься решения по фактической организации применения этих параметров, планированию работ в доступные окна, выстраиванию локальных приоритетов с учетом особенностей систем, оценке рисков применения настроек и установки ПО, а в случае невозможности — вырабатываться дополнительные компромиссные решения.
Если говорить о сегментах КИИ, а тем более о ЗОКИИ, такой подход еще полезнее. Потому что при централизованном управлении мы можем действовать превентивно. Например, как это делаем мы: подготовившись к проверке регулятора на одном заводе и успешно, или не совсем успешно, ее пройдя, а затем устранив замечания, мы тиражируем эти требования на все остальные заводы и добиваемся их применения на местах. Это позволяет повысить лояльность регулятора, избежать серьезных нарушений и как минимум заблаговременно подготовить инфраструктуру и документацию к последующим проверкам, а не устранять замечания после проверки в авральном режиме.
Если говорить о приоритетах инфраструктурного развития, что для промышленной компании сегодня важнее всего?
В российской промышленности сегодня важнее всего нащупать ту самую грань, на которой приходится балансировать между полным соблюдением регуляторных требований (в том числе к КИИ и импортозамещению), бесперебойностью производства и внедрением инноваций на базе пока еще формирующейся отечественной экосистемы. Компании с большим бюджетом могут позволить себе с головой уйти в импортозамещение, но пока я вижу это скорее как эксперимент. Среднестатистические компании стараются делать в этом направлении минимальные шаги, чтобы не навредить производству и в то же время соответствовать базовым требованиям регуляторов.
Насколько сильно на инфраструктурные решения влияет производственная специфика? Что в промышленности принципиально отличается от классического корпоративного ИТ?
Производственная специфика достаточно сильно влияет на подходы, иногда они различаются диаметрально. В корпоративном ИТ упор делается на удобство эксплуатации, а в промышленном — на непрерывность производственного процесса. В корпоративной среде мы можем достаточно часто устанавливать обновления систем и прошивок оборудования, где возможная нестабильность в работе, как правило, влечет за собой лишь недовольство сотрудников и финансовые потери.
В промышленной среде интервалы как выпуска обновлений, так и их установки значительно больше. Изменения в системы вносятся реже.
Существенно жестче и требования к обеспечению информационной безопасности. Например, на предприятии в корпоративном сегменте парольная политика может допускать для административной учетной записи пять попыток ввода пароля до блокировки на 10 минут, с минимальной длиной пароля 12 символов и требованиями к сложности. В промышленном сегменте — всего две попытки с блокировкой на 60 минут и минимальной длиной пароля 15 символов.
Принципиально отличаются и требования к «чистоте» сетевого эфира, и используемые сетевые протоколы. В этих условиях применение классического антивирусного ПО нежелательно из-за вероятности влияния на производственный процесс, скорость отклика и задержки при обработке данных.
Классический антивирус в промышленном сегменте не запрещен, но он рассчитан на логику корпоративного ИТ. Его проблемы в АСУТП — это возможная нагрузка на CPU и диски, необходимость частых обновлений, перезагрузок и активного сканирования, что в технологической среде часто недопустимо.
Поэтому в случае с популярным решением «Лаборатории Касперского» для промышленной среды используют специализированный KICS (Kaspersky Industrial CyberSecurity). KICS for Nodes предназначен для защиты хостов в АСУТП — операторских АРМ, SCADA-серверов, historian и шлюзов — с учетом промышленной специфики, совместимости и более аккуратной работы в чувствительной среде. KICS for Networks используется для пассивного анализа зеркалированного трафика в самой промышленной сети. Он дает видимость всех хостов, сетевых взаимодействий между ними, аномалий и угроз без вмешательства в технологические коммуникации.
Какие инфраструктурные проблемы чаще всего недооценивают те, кто не работал с производственными площадками? Например, устаревшие системы, длинный жизненный цикл оборудования, невозможность остановки процессов, сложность изменений?
Чаще всего недооценивают как раз не одну проблему, а их сочетание. Это и длинный жизненный цикл оборудования, и то, насколько сложно бывает доказать необходимость закупки промышленных ПК для горячего резерва: пока все работает, на этот риск предпочитают не обращать внимания. Это и старые ОС, и прикладные системы, которые все еще остаются критичными. И зависимость от подрядчиков, и от «исторически проверенных» конфигураций. И нехватка окон обслуживания достаточной продолжительности. Также недооценивают очень высокую цену даже небольшого изменения.
Еще, как мне кажется, часто недооценивают накопление исключений, костылей и времянок. Например, с точки зрения ИБ это могут быть десятки мелких компромиссов: временно выданный доступ из корпоративного сегмента в АСУТП, забытый маршрут, не выведенный из эксплуатации сервер, АРМ с избыточными правами локального администратора, неактуальная схема подключений. Комбинация этих факторов легко может позволить злоумышленнику реализовать свой сценарий. Поэтому инвентаризация прав, контроль конфигурации и управление изменениями здесь важны не меньше, чем сами средства защиты. Для значимых объектов КИИ это вообще часть обязательной модели — и через требования к системе безопасности, и через модель угроз.
Как вы выстраиваете единую архитектурную логику для разных заводов, если на местах могут быть разные уровни зрелости, разные команды и разное наследие?
Я начинаю с каркаса — с того, что должно быть единообразным при любом уровне зрелости. Например, это правила адресации, структура сегментов DMZ, модель доступа, требования к резервному копированию, подход к организации системы мониторинга и так далее. Во время обсуждений и мозговых штурмов по применению этого каркаса я оцениваю применимость тех или иных правил. Затем мы принимаем решение об очередности изменений. Где-то можно двигаться быстро, лишь корректируя действия локальных администраторов. А где-то сначала требуются подготовительные работы и помощь со стороны головного офиса.
Я также продвигаю принцип наставничества. Если локальной команде не хватает компетенций, а на смежном заводе или в головном офисе такие компетенции есть, коллеги делятся опытом, помогая развернуть системы, настроить правила, организовать сегменты сети. Да, сложности с персоналом и доверием встречаются. Особенно если коллеги проработали на заводе несколько лет и, возможно, ревностно относятся ко всем нововведениям.
В прошлом году вы завершили проект сегментации заводских сетей, отделив АСУТП от корпоративного сегмента, но сохранив передачу метрик из производственного контура. Если смотреть на этот проект не только как на меру безопасности, а шире, то какую управленческую или инфраструктурную задачу он в первую очередь решал?
Об управленческой задаче говорить сложно, потому что сегментация действительно в большей степени относится к вопросам безопасности и инфраструктуры. Но, наверное, я бы все же отметил задачу соответствия требованиям регуляторов, которая тоже тесно связана с обеспечением безопасности на производстве.
Помимо вопросов информационной безопасности, проект решил задачу разграничения зон ответственности, а также инфраструктурную задачу по ограничению зон распространения доменов и DHCP. В корпоративном сегменте за маршрутизацию, доступ в интернет и к общим сетевым ресурсам в ЦОД может отвечать администратор головного офиса, а за все, что находится внутри сегмента АСУТП, — администратор на заводе. Теперь у заводского администратора нет возможности по ошибке ввести АРМ оператора в корпоративный домен или использовать этот АРМ для выхода в интернет. Кроме того, в корпоративном и промышленном сегментах теперь используются разные физические серверы.
Какую роль сегодня играет мониторинг в промышленной инфраструктуре?
Очень важную. Но я бы сказал, что его задача не в том, чтобы собрать вообще все по максимуму, а в том, чтобы обрабатывать критические события и вовремя показывать, что что-то идет не так. В производстве это особенно важно, потому что серьезный инцидент часто начинается с чего-то не очень заметного: нетипичного поведения администратора, нового, нехарактерного направления обмена, странного поведения АРМ, резкого роста трафика, новой связи между сегментами, инициализации удаленного подключения подрядчика вне технологического окна и т. п.
При отсутствии штатных диспетчеров хорошо зарекомендовал себя внешний SOC, который обеспечивает оповещение о потенциальном инциденте и требует либо подтверждения легитимности действий, либо создания инцидента. Как правило, во внешних SOC достаточно хорошо прописаны алгоритмы выявления подозрительного поведения, но это требует тонкой настройки логирования и очистки от мусорных данных.
Как выстроено взаимодействие между ИТ, производственными службами, АСУТП-специалистами и ИБ? Есть ли в таких компаниях рабочая модель, при которой это единая система?
Да, сейчас мы достигли определенного баланса во взаимодействии корпоративного ИТ, ИТ АСУТП и ИБ, но этот баланс — результат длительной работы со всеми сотрудниками этих служб. Сложнее всего убедить всех, что мы делаем одно большое дело и нам необходимо общаться, собираться, проговаривать проблемы. Нужно перестать спорить, чей это вопрос — ИТ, ИБ или производства, а собираться всем вместе, анализировать ситуацию и понимать, кому и что нужно сделать для устранения проблемы либо как найти компромиссное решение.
Я вижу рабочую схему так. ИТ отвечает за инфраструктурную основу: сети, серверы, каналы связи, ПО, резервное копирование, базовый доступ. ИБ отвечает за правила, ограничения, требования к глубине хранения логов, обязательным метрикам мониторинга, журналированию, управлению доступом и контролю. Специалисты АСУТП и производственные службы отвечают за технологическую критичность, допустимость изменений, окна работ и последствия для процесса. И когда речь идет о производственном контуре, решение нельзя принимать без участия всех этих сторон. В логике КИИ это особенно важно: система безопасности значимого объекта и модель угроз не могут быть корректно описаны, если их составляет одна функция в отрыве от остальных.
Как вы подходите к вопросам импортозамещения в инфраструктуре промышленной компании? Насколько сегодня реально для промышленной компании не просто заменить отдельные решения, а сохранить при этом привычный уровень надежности и управляемости?
Пока ответить сложно. Будем откровенны: российские разработки пока еще находятся на достаточно низком уровне. Как бы мы ни хотели, но решениям того же Siemens нам пока нечего противопоставить. Да, разработки ведутся, какие-то решения начинают появляться, но пока сохраняются большие сложности с совместимостью протоколов между российскими ПЛК и зарубежными SCADA. Это крайне сложный процесс перепроектирования системы.
Кроме того, необходимо учитывать, что отечественные решения в силу своей незрелости могут иметь проблемы с совместимостью даже между однотипным оборудованием разных ревизий. Простой пример: российские коммутаторы одного производителя, но разных моделей могут использовать разные команды для выполнения одного и того же действия. В случае с элементами АСУТП такие различия недопустимы, так как могут потребовать перепроектирования системы. Поэтому заменить такие решения без потери функциональности, управляемости, совместимости и стабильности работы сегодня практически невозможно.
В распределенной инфраструктуре очень многое упирается в людей. Насколько остро вы ощущаете дефицит кадров на местах и можно ли его компенсировать централизацией, автоматизацией и едиными инструментами?
Да, я ощущаю дефицит кадров. Хороших специалистов с опытом работы в серьезных промышленных компаниях не так много. В основном приходится идти на компромисс: брать менее опытных сотрудников и заниматься передачей опыта от старших коллег. Ситуация на местах осложняется ветхими участками инфраструктуры, которые требуют к себе повышенного внимания. Зачастую приходится выезжать «в поля», а из-за расстояний это происходит не так быстро.
Можно ли это компенсировать? Частично — да. Централизация, автоматизация, единые инструменты мониторинга, учета активов, управления доступом и изменениями очень помогают. Они снижают зависимость от ручного хаоса и от знаний конкретных сотрудников, позволяют быстрее тиражировать практические решения и делают среду более предсказуемой.
Например, мы уже внедрили систему мониторинга на двух из трех заводов, а также в головном офисе и ЦОД. В случае возникновения проблем со связью администраторы на местах, глядя на дашборд, сразу видят проблемное оборудование или участок сети. Раньше же приходилось вслепую по очереди перебирать и проверять оборудование.
Внедряемая централизованная система CMDB содержит исчерпывающую информацию обо всем оборудовании и соединениях между ними. А в связке с общим трекером проектных задач и базой WIKI она практически полностью нивелирует зависимость от конкретных сотрудников: теперь они могут спокойно уходить в отпуск.
В части работы с объектами КИИ, ОКИИ и ЗОКИИ мы централизованно выпускаем единые регламенты, стандарты и планы реагирования на инциденты, дополняя их локальными нормативными документами заводов. Это позволяет всем двигаться в одном направлении и одновременно снимает часть нагрузки с персонала на местах.
Я хочу сказать, что в текущих реалиях централизация позволяет нам не столько сократить численность персонала, сколько высвободить время и направить его на решение проектных задач.
Опубликовано 27.03.2026
