Представьте типовой звонок в диспетчерскую. Ничего не взорвалось, насосы крутятся, давление держится. Но приходит письмо от службы безопасности или регулятора: «Подтвердите управляемость поставок и план замены зависимых компонентов. Укажите, какие части АСУ ТП и ИТ-ландшафта могут быть остановлены из-за санкций, прекращения поддержки, отзыва лицензий или компрометации цепочки поставок». И внезапно выясняется, что импортозамещение в критической инфраструктуре – это не про «поменяли бренд в спецификации», а про выживаемость процессов, ремонтопригодность и доказуемую безопасность.
В мире эта логика давно закрепилась в требованиях к устойчивости. В ЕС NIS2 расширяет круг «существенных» отраслей и усиливает ответственность за киберустойчивость и управление рисками, включая цепочки поставок. В США после громких инцидентов упор сделали на безопасность софта и поставок, в том числе через практики вроде SBOM (перечня компонент ПО) в контексте Executive Order 14028. В промышленности это прямо ложится на реальность: любой контроллер, любая SCADA, любой шлюз удаленного доступа – это не железка и не «программа на сервере», а часть длинной цепочки, где слабое звено почти всегда находится не там, где его ищут.
Почему «импортозамещение» стало мировым термином про устойчивость, а не про политику
Если отбросить лозунги, импортозамещение в критической инфраструктуре – это стратегия снижения зависимости от внешних факторов, которые вы не контролируете. И факторы эти бывают разными.
Первый – прекращение поддержки. Когда вендор снимает продукт с линии, закрывает обновления, перестает выпускать патчи или меняет условия лицензирования, у вас остается «вечный» узел, который нельзя трогать, потому что страшно. Это почти всегда заканчивается тем, что трогать придется, но уже ночью и в аврале.
Второй – цепочка поставок. Мир увидел, как «доверенный» апдейт может стать каналом атаки: кейс SolarWinds стал учебником по supply chain компрометации. Для промышленности это особенно неприятно, потому что последствия выходят за рамки утечки данных. Когда атакуют ИТ, вы теряете письма и документы. Когда атакуют OT, вы рискуете режимами и безопасностью процесса.
Третий – «геополитическая погода». Сегодня поставка есть, завтра логистика рушится, послезавтра платежи не проходят, потом меняются правила экспортного контроля. Суть не в конкретной стране, а в том, что критическая инфраструктура не должна зависеть от непредсказуемых решений за пределами контура управления.
Поэтому правильная рамка разговора такая: импортозамещение – это частный случай более широкой дисциплины, которую на Западе называют resilience, supply chain risk management и cyber resilience. Просто у нас это слово звучит иначе, а проблемы те же.
Критическая инфраструктура отличается тем, что «переустановить» нельзя
В корпоративной ИТ-среде можно сказать: «Окей, выкатим новый образ, откатим, поднимем кластер». В АСУ ТП такие фразы звучат как шутка, особенно на непрерывных производствах.
У критической инфраструктуры есть три особенности, которые ломают привычные подходы:
Первая – длительный жизненный цикл. Оборудование живет 10–20 лет, а иногда дольше. На этом горизонте меняются поколения ОС, протоколов, криптографии, подходов к безопасности и даже людей, которые помнят, как оно было собрано.
Вторая – физические последствия. История Stuxnet стала символом того, что вредоносный код может менять режимы и приводить к физическому ущербу, потому что цель находится в контроллерах и инженерных станциях, а не в бухгалтерии. Позже Triton/Trisis показал еще более неприятный класс: атака на системы функциональной безопасности.
Третья – «нельзя останавливать». В энергетике, водоканалах, транспорте, химии, добыче, теплогенерации простой – это не просто деньги. Это общественные риски. Поэтому любая миграция должна быть инженерным проектом с управлением рисками, а не закупкой.
Главный миф: «достаточно заменить железку»
Импортозамещение часто пытаются представить как замены по каталогу: «было A, стало B». Но в критической инфраструктуре важнее не железо, а экосистема вокруг него.
Контроллер – это среда разработки, библиотеки, диагностика, способы резервирования, работа со временем, журналы, механика обновлений, инструменты для инженера на объекте. SCADA – это не только мнемосхемы, но и историзация, управление пользователями, разграничение прав, интеграция с доменом или без домена, политика патчей, бэкапы, планы восстановления.
А еще есть протоколы и совместимость на «стыках»: Modbus, OPC UA, Profinet, EtherNet/IP, IEC 60870-5-104, DNP3, проприетарные драйверы. Каждый «стык» – потенциальная точка боли, потому что именно на стыках обычно держатся старые системы.
Поэтому честный ответ на вопрос «что замещаем?» звучит так: замещаем не устройство, а зависимость. Иногда это зависимость от конкретного вендора. Иногда – от конкретной операционной системы на инженерной станции. Иногда – от одного единственного драйвера, который больше никто не поддерживает.
Как это делают в мире: давление регуляторов и практики доказуемости
Во многих странах критическая инфраструктура живет в режиме «докажи». Докажи, что ты знаешь свои активы. Докажи, что управляешь уязвимостями. Докажи, что цепочка поставок контролируема.
Отсюда растут практики, которые еще недавно казались бюрократией, а теперь стали нормой:
SBOM как инвентаризация компонент ПО. В США эта тема получила импульс на уровне государства, в том числе через NIST в контексте EO 14028. В промышленности SBOM становится полезен даже без «моды»: он помогает быстро понять, затронула ли вас очередная уязвимость в библиотеке, которая зашита в продукт.
Управление рисками цепочки поставок. ENISA прямо публикует практики по supply chain cybersecurity и увязывает их с международными стандартами и контекстом NIS2.
Secure by Design. CISA продвигает идею, что производители должны закладывать безопасность в продукт, а не перекладывать ее на эксплуатацию. Для промышленности это особенно важно: когда у вас контроллер в шкафу на удаленной площадке, «потом настроите MFA» звучит как фантастика.
IEC 62443 как общий язык между ИТ-безопасностью и OT. Это не «волшебный стандарт», но он задает понятные рамки: зоны, каналы, требования к компонентам и процессам.
Смысл этих практик один: импортозамещение должно быть не декларацией, а доказуемым состоянием системы.
Где чаще всего рвется импортозамещение: не техника, а процесс
Самые болезненные провалы редко связаны с тем, что «новый контроллер плохой». Чаще ломается управляемость проекта.
Нет единого владельца зависимости. Эксплуатация считает, что это про надежность. ИБ считает, что это про угрозы. Закупки считают, что это про цену и сроки. Проектировщики считают, что это про ТЗ. А в итоге никто не отвечает за целостную картину: что именно мы замещаем, какой риск закрываем, как будем обслуживать и обновлять.
Замещают «по верхам». Меняют сервер, но оставляют старую инженерную станцию без патчей. Меняют SCADA, но оставляют старый драйвер через костыльный шлюз. И через год получают систему, которую невозможно сопровождать без двух «уникальных специалистов», уехавших в отпуск одновременно.
Не считают стоимость владения. В критической инфраструктуре цена железки – это маленькая часть. Дорого стоят простои, обучение, регламенты, запасные части, стенды, диагностическое оборудование, согласования изменений и, главное, время инженеров.
Не проектируют режим возврата. Любой переход должен иметь понятный «план Б»: как вы откатываетесь, если в новом контуре всплывает эффект, который не ловится на стенде.
Реальные мировые примеры, которые научили отрасль осторожности
Есть несколько историй, которые промышленники по всему миру вспоминают не из любви к драме, а потому что это готовые уроки.
Stuxnet показал, что цепочка «Windows + инженерное ПО + PLC» – не абстракция, а реальная поверхность атаки. Ключевая мысль там даже не про конкретный объект, а про класс: вредонос может жить в инженерной среде и незаметно менять логику управления.
Triton/Trisis стал страшным маркером: атаковать можно не только управление, но и безопасность, то есть защитные системы, которые должны спасать людей и оборудование при авариях.
Industroyer2 в Украине напомнил, что специализированные инструменты для атак на энергетику существуют здесь и сейчас, и они развиваются, а не остаются в «легендах нулевых».
SolarWinds сделал supply chain угрозы «официальной» темой в кабинетах регуляторов и CISО: компрометировать можно не вас напрямую, а вашего поставщика.
Если перевести это на язык импортозамещения, то урок такой: зависимость опасна не только тем, что «не привезут». Она опасна тем, что вы можете не понимать, чем именно вы пользуетесь и где у этого есть скрытые двери.
Практическая стратегия: как замещать без героизма
Звучит скучно, но лучший импортозамещающий проект похож на проект по надежности: сначала учет, потом архитектура, потом пилот, потом масштабирование.
Сначала делается инвентаризация зависимостей: не просто список оборудования, а карта «что от чего зависит». Какая версия прошивки, какая версия среды, какие лицензии, какие драйверы, какие каналы связи, какие учетные записи, где ключи и кто имеет доступ. Это неприятная работа, но без нее вы управляете слухами.
Затем определяется критичность. Не все узлы одинаковы. Есть то, что можно заменить в плановое окно. Есть то, что трогать нельзя без реконструкции. Есть то, что можно изолировать и «обложить» компенсирующими мерами: сегментацией, контролем доступа, мониторингом.
Потом появляется пилот. Причем пилот в критической инфраструктуре – это не «поставили один контроллер и посмотрели». Это проверка эксплуатационной реальности: диагностика, журналы, замена модуля в перчатках на морозе, восстановление после сбоя питания, обновление прошивки по регламенту, резервирование, работа с архивом и отчетами, реакция персонала. Один раз упомяну нативно: когда компании делают такие пилоты на реальном объекте и хотят быстро получить железо под испытания и обратную связь по эксплуатации, удобно, если производитель дает возможность бесплатного тестирования в боевых условиях, как это практикуется у СТАБУР в формате тест-драйва.
Дальше строится дорожная карта миграции: где замена точечная, где нужна модернизация сети, где придется менять шкафы, где затронется функциональная безопасность, где потребуется новая аттестация или пересогласование.
И последняя часть, о которой забывают чаще всего: план сопровождения. Импортозамещение считается успешным не когда вы подписали акт, а когда через год у вас спокойно обновляются компоненты, воспроизводятся сборки, лежат бэкапы, работает мониторинг, а аварийная бригада знает, что делать, если ночью «потухло».
Компромиссы: что можно локализовать быстро, а что потребует времени
Чтобы не превращать статью в чек-лист, покажу смысл на простой таблице. Это не «единственно верно», но хорошо объясняет, почему у проектов разные сроки.
Тут важно не «что легче», а что дает максимальный эффект по рискам. Иногда замена одной инженерной станции и наведение порядка в доступах снижает угрозы сильнее, чем покупка новых контроллеров.
Безопасность и импортозамещение связаны плотнее, чем кажется
Есть соблазн развести темы: мол, импортозамещение – про поставки, а безопасность – про киберугрозы. В реальности они про одно: контроль.
Если вы переходите на новые компоненты, у вас есть шанс пересобрать архитектуру «как надо»: сегментация, журналы, управление учетными записями, обновления, резервирование. И наоборот, если вы просто заменили один бренд на другой, но оставили «всем известный пароль», доступ по TeamViewer «для подрядчика», отсутствие мониторинга и хаос в сетях, вы импортозаместились только на бумаге.
Мировая регуляторика подталкивает именно к этой взрослой трактовке. NIS2 и похожие режимы говорят не «купите правильное», а «управляйте риском и отвечайте за это». А инициативы вроде Secure by Design подчеркивают: часть ответственности должна быть у производителя, а не только у эксплуатации.
Итог: зрелое импортозамещение выглядит скучно, и это хороший знак
Если импортозамещение в критической инфраструктуре выглядит как героический забег с «успели к дедлайну», значит, вы заплатили будущими рисками. Нормальный сценарий всегда более прозаичный: инвентаризация, архитектура, пилот, поэтапная миграция, сопровождение, аудит.
Это работа, где ценится не «смелость», а дисциплина. Вы не обязаны менять все сразу. Но вы обязаны понимать, где ваша зависимость критична, чем она вам грозит, и какой у вас план, если внешний мир снова поменяет правила.
И да, самый неприятный вывод тоже честный: импортозамещение не отменяет инженерной культуры. Оно ее требует.