На прошлой неделе FireEye и CISA подтвердили: злоумышленники месяцами проникали в сети американских ведомств и корпораций через легитимные обновления платформы мониторинга SolarWinds Orion. Атакующие скомпрометировали сборочный конвейер вендора и встроили бэкдор SUNBURST в подписанный пакет. Жертвы скачивали обновление сами – через штатный механизм, с действительной цифровой подписью. По оценкам, заражённую версию получили около 18 000 организаций. Это не точечный взлом. Это атака на доверие к цепочке поставок ПО, и она бьёт по тем, кто привык доверять подписям и репутации вендора.

Почему периметр не помог

Orion ставят с высокими привилегиями: продукт мониторит сеть, поэтому видит почти всё. Бэкдор унаследовал эти права и из доверенной зоны спокойно ходил наружу. Трафик SUNBURST маскировался под штатный протокол телеметрии SolarWinds, а команды управления шли через легитимно выглядящие домены. Классический периметровый контроль здесь бессилен: соединение инициировал доверенный сервер обновлений, подпись прошла проверку, домен в белом списке.

Вывод неприятный, но прямой: подписанный код от известного вендора – больше не гарантия. Угроза переместилась на уровень выше отдельной компании. Скомпрометировав одного поставщика, атакующий получает доступ ко всем его клиентам разом.

Что это значит для госсектора и крупного бизнеса в РФ

Российские организации редко используют именно Orion, но модель атаки универсальна. Любой агент мониторинга, антивирус, система резервного копирования или библиотека из публичного репозитория – потенциальный канал заражения. Импортозамещение и переход на открытое ПО не снимают риск автоматически: открытый код тоже собирают на чьём-то конвейере и тянут из чужих зеркал. Мы уже подводили IT-итоги 2020 года и отмечали, как быстро растёт зависимость от внешних компонентов.

Для госорганов вопрос острее. Требования ФСТЭК по защите информации и сертификация средств защиты проверяют сам продукт, но не гарантируют, что конкретная сборка не подменена в пути. Цепочка «разработчик – сборка – дистрибуция – обновление» нуждается в отдельном контроле.

Что делать сейчас

Конкретные шаги, которые имеют смысл уже на этой неделе:

  • Инвентаризируйте поставщиков ПО. Составьте список всех продуктов с высокими привилегиями и автообновлением. Именно они – первоочередная мишень.
  • Сегментируйте и ограничивайте исходящий трафик. Сервер мониторинга не должен ходить в интернет напрямую. Контролируйте egress, а не только вход.
  • Проверяйте обновления, а не только подписи. Тестовый контур, контроль контрольных сумм из независимого источника, задержка перед массовым раскатом.
  • Фиксируйте baseline поведения. Аномалия – это когда доверенный сервис вдруг открывает новые соединения. Без эталона вы её не увидите.
  • Защищайте собственный конвейер сборки. Если вы сами разрабатываете и поставляете ПО, ваш CI/CD – такая же мишень. Изолированные сборочные среды, подпись артефактов, контроль зависимостей. Те же принципы изоляции окружений мы применяли при миграции на PostgreSQL, а архитектурные компромиссы клиентских приложений разбирали в материале PWA против нативных приложений.

Чтобы все эти шаги сложились в систему, нужны аудит цепочки поставок, сегментация сети и защита сборочного конвейера, а не разрозненные точечные меры.

Вывод

SolarWinds показал: доверие к вендору – это поверхность атаки, а не защита. Безопасность периметра решает вчерашнюю задачу. Сегодня контролировать нужно то, что вы сами впускаете внутрь по доверенному каналу – обновления, агентов и зависимости. Начните с инвентаризации и ограничения исходящего трафика. Это дёшево и закрывает главный вектор, которым воспользовались атакующие.