Кибербезопасность часто обсуждают в контексте крупных западных атак, но следующий ‘взрывной’ Supply Chain Attack — по масштабам сопоставимый с инцидентом с SolarWinds — произойдёт в российской ИТ-экосистеме. Это связано не с недостатком технических навыков, а с уникальным стечением экономических факторов, регуляторного давления и технологических паттернов, сложившихся в последние годы. Заглушённая в публичном поле подготовительная активность уже ведётся, а цель атаки — не классические госорганы, а узкая прослойка компаний-системных интеграторов и поставщиков в сфере критической информационной инфраструктуры. https://seberd.ru/5242
Солнечная буря и российская экосистема: схожесть и различие
Атака на SolarWinds, раскрытая в конце 2020 года, стала классикой жанра компрометации цепочки поставок (Supply Chain Attack). Вредоносный код был внедрён в обновление Orion, популярной платформы для мониторинга сетей и инфраструктуры. Десятки тысяч организаций по всему миру, включая правительственные структуры и крупные корпорации, установили это обновление, легитимно подписанное разработчиком. Злоумышленники получили доступ к самым защищённым сетям через доверенный канал.
В России принято считать, что такие сценарии нас не касаются — у нас свой софт, свои продукты, своя экосистема. Это иллюзия. Механизм атаки повторится, но движущие силы будут другими. Там, где в случае с SolarWinds ключевым фактором была глобальность популярного коммерческого продукта, в России триггером станут три фактора: массовая импортозаместительная миграция на отечественное ПО, сжатые сроки и фрагментарная экспертиза по безопасности на стороне разработчиков.
Уязвимость переносится из плоскости технологий в плоскость процесса. Когда сотни государственных и коммерческих организаций в авральном режиме переводят ключевые системы на новые, часто менее зрелые, отечественные аналоги, они вынужденно снижают порог требований к безопасности. Проверки на наличие бэкдоров и уязвимостей в исходном коде проводятся формально или не проводятся вовсе, потому что главная задача — выполнить план по импортозамещению в срок.
Точки приложения: интеграторы, а не вендоры
В России редко встречаются монопольные коммерческие продукты уровня Orion, которые установлены повсеместно. Вместо этого роль системного элемента цепочки исполняют не столько производители ПО, сколько компании-системные интеграторы. Именно они берут на себя создание, адаптацию и внедрение комплексных решений, включая сборку дистрибутивов операционных систем, установку и настройку СУБД, разработку надстроек и скриптов автоматизации.
Эти интеграторы работают одновременно с десятками заказчиков из одного сегмента, например, со всеми крупными банками или предприятиями топливно-энергетического комплекса региона. Если злоумышленник скомпрометирует инфраструктуру такого интегратора, он может внедрить вредо.сный код в стандартный образ системы или конфигурационный пакет, который затем будет развёрнут на площадках всех клиентов. Канал распространения получается не массовым, но целенаправленным и высокоэффективным.
Примером может служить автоматизированный скрипт развёртывания, который интегратор использует для настройки серверов баз данных у заказчиков. Подмена одной команды в таком скрипте на всех проектах интегратора даст злоумышленнику точку входа в инфраструктуру сразу нескольких стратегически важных организаций.
Регуляторика как катализатор уязвимости
Российская регуляторика, в частности 152-ФЗ о персональных данных и законы в области КИИ, создаёт дополнительные риски для безопасности цепочки поставок. Требования ФСТЭК и ФСБ часто сфокусированы на формальном соответствии: наличие сертифицированных СЗИ, аттестованных средств защиты, правильно заполненных документов. Это порождает «бумажную» безопасность, где реальная проверка целостности ПО и его происхождения отходит на второй план.
Например, при аттестации информационной системы по требованиям регуляторов основное внимание уделяется конфигурации развёрнутой системы, но почти никогда — процессу её сборки и поставки. Нет обязательных требований к использованию защищённых репозиториев, верификации цифровых подписей на всех этапах сборки дистрибутивов или аудиту кода сторонних библиотек, которые включаются в отечественные решения.
Более того, сертификация самих средств защиты информации (СЗИ) может создать ложное чувство безопасности. Организация, установившая сертифицированный межсетевой экран, считает свой периметр защищённым, но если бэкдор был внедрён на этапе создания образа сервера прикладного уровня внутри этого периметра, все эти меры окажутся бесполезны.
Проблема «доверенного» поставщика
Регуляторные акты и внутренние политики компаний часто требуют закупки ПО и услуг только у «доверенных» или «проверенных» поставщиков, аккредитованных Минцифры или входящих в определённые реестры. Эта практика, призванная снизить риски, на самом деле создаёт концентрацию риска. Атакующий, нацелившийся на такого поставщика, получает ключ ко множеству систем одновременно. Само понятие «доверенный» в данном контексте начинает работать против безопасности.
Экономические и кадровые предпосылки
Экономические санкции и уход иностранных вендоров создали огромный пласт работы для российских разработчиков и интеграторов. Однако кадровый голод в сфере безопасной разработки (Security by Design, DevSecOps) остаётся критическим. Многие отечественные команды вынуждены работать в режиме жёстких дедлайнов, где выпуск функциональности приоритетнее, чем аудит безопасности, внедрение практик контроля зависимостей или анализ на уязвимости.
Это приводит к нескольким типичным сценариям:
- Использование непроверенных сторонних библиотек с публичных репозиториев в критическом отечественном ПО.
- Отсутствие практики подписания релизных артефактов (сборок, образов) цифровой подписью, что не позволяет заказчику проверить их целостность.
- Слабая сегрегация сред разработки, сборки и поставки, когда один компрометированный аккаунт разработчика даёт доступ к каналу дистрибуции.
Злоумышленник, в отличие от случайного хакера, ведёт целенаправленную подготовку. Он анализирует не столько исходный код популярных решений, сколько публичную информацию о компаниях-интеграторах: их клиентах, используемых технологических стеках, упоминаниях в тендерах. Даже открытые вакансии компании могут рассказать о её внутренних процессах и потенциальных слабых местах.
Сценарий атаки «по-русски»
Как может выглядеть атака, сопоставимая по масштабу воздействия с SolarWinds, но адаптированная под российские реалии?
- Разведка и выбор цели. Группа злоумышленников выбирает не крупного вендора, а среднего системного интегратора, специализирующегося на внедрении решений для, например, энергетических компаний. Они изучают его клиентскую базу, технологии и, возможно, находят уязвимость в его корпоративном портале для сотрудников.
- Первичное проникновение. Через уязвимость в портале или через целевую фишинговую атаку на сотрудника отдела разработки/тестирования злоумышленники получают доступ во внутреннюю сеть интегратора.
- Горизонтальное перемещение и поиск артефактов. Внутри сети они ищут репозитории с исходным кодом, серверы непрерывной интеграции (CI), хранилища готовых образов виртуальных машин или контейнеров, которые поставляются заказчикам.
- Внедрение вредоносного кода. На этапе сборки или непосредственно в готовый образ внедряется малозаметный бэкдор. Это может быть изменённая библиотека, модифицированный системный демон или скрипт инициализации. Код подписывается легитимными ключами интегратора.
- Распространение. Заражённые артефакты автоматически попадают к заказчикам через стандартные каналы поставки — загрузку с портала, автоматическое обновление или физическую доставку.
- Активация и выполнение задачи. На стороне заказчика бэкдор активируется, устанавливает связь с командным сервером и выполняет задачу: сбор конфиденциальных данных, дистанционное управление или подготовка к разрушительным действиям.
Особенность такого сценария — его скрытность и долгосрочность. Поскольку обновления и поставки от интегратора, это рутинный процесс, атака может оставаться незамеченной месяцами.
Что можно сделать?
Предотвращение подобного сценария требует смещения фокуса с периметральной защиты на безопасность процессов разработки и поставки. Меры должны быть комплексными и касаться как регуляторов, так и бизнеса.
- Для регуляторов (ФСТЭК, Роскомнадзор): Введение в требования по защите информации (в том числе для КИИ) обязательных практик для разработчиков и интеграторов. Например, требований к использованию доверенных репозиториев, обязательной верификации цифровых подписей на всех этапах жизненного цикла ПО, проведения независимого аудита безопасности кода для систем, внедряемых на объектах КИИ.
- Для заказчиков: Необходимо включать в технические задания и договоры с интеграторами конкретные требования по информационной безопасности процессов поставки. Запрашивать и проверять Software Bill of Materials (SBOM) — список всех компонентов ПО с их версиями, чтобы знать о всех используемых зависимостях. Организовать собственный «чистый комнатный» процесс приёмки и развёртывания критического ПО с проверкой хэш-сумм и цифровых подписей.
- Для разработчиков и интеграторов: Внедрение практик DevSecOps. Сегрегация прав доступа к средам сборки и релиза. Обязательное подписывание всех релизных артефактов. Регулярный аудит используемых сторонних библиотек на наличие уязвимостей. Повышение осведомлённости сотрудников о рисках компрометации цепочки поставок.
Российская ИТ-экосистема не изолирована от глобальных угроз, она трансформирует их под свои условия. Следующая крупная атака через цепочку поставок не придёт извне в виде обновления зарубежного продукта. Она созреет внутри, как побочный эффект ускоренного импортозамещения, регуляторного формализма и экономического давления. Её эпицентром станут не широко известные вендоры, а менее заметные, но критически важные звенья — системные интеграторы.
Понимание этой специфики — первый шаг к выстраиванию адекватной защиты. Без смещения акцента с проверки конфигураций на аудит процессов сборки и дистрибуции ПО любая, даже самая строгая, регуляторика будет лишь симуляцией безопасности, за которой последует неизбежный инцидент.