Атака через цепочку поставок: как защититься

Коротко. Атака через цепочку поставок — это атака, при которой злоумышленник попадает в компанию не напрямую, а через того, кому она доверяет: ИТ-подрядчика с удалённым доступом, поставщика программы или обновления, стороннюю библиотеку в коде, облачный сервис с вашими данными. Защита строится на пяти вещах: знать всех поставщиков и их доступы, проверять их до договора, давать минимальный и контролируемый доступ, прописывать требования безопасности в договоре и следить за программными компонентами. Полностью исключить риск нельзя — вы не управляете чужой безопасностью, — но можно сделать так, чтобы взлом поставщика не превращался автоматически во взлом вашей компании.

Для руководителей и ИТ-специалистов компаний, работающих с ИТ-аутсорсом, интеграторами и внешними разработчиками.

Почему атакуют через поставщиков

Крупная компания может хорошо защищать свой периметр, а её подрядчик — нет. Атакующему выгоднее взломать одного поставщика и через него получить доступ сразу ко многим клиентам. Известны случаи, когда через скомпрометированный механизм обновлений популярной системы ИТ-мониторинга атакующие проникли во множество организаций, включая государственные ведомства. Были и инциденты, когда инструменты удалённого управления у поставщика ИТ-услуг использовали для одновременного распространения шифровальщика по его клиентам. А закладку в широко используемой библиотеке для Linux обнаружили почти случайно — до того, как она успела массово распространиться.

Небольшая компания здесь в двойном риске. Её могут атаковать через подрядчика, а она сама может оказаться «поставщиком» для крупного клиента, который будет требовать подтверждений безопасности. ENISA выпускала отдельный обзор угроз, посвящённый атакам на цепочки поставок, — масштабы и долю таких атак для белорусского рынка публично не оценивали.

Четыре пути атаки через цепочку поставок

Шаг 1. Составьте список поставщиков и их доступов

Нельзя защитить то, о чём не знаешь. Соберите в одну таблицу всех, у кого есть доступ к системам или данным: ИТ-аутсорс, разработчики, интеграторы, хостинг, облачные сервисы, маркетинговые агентства с доступом к сайту и рекламным кабинетам, бухгалтерия на аутсорсе, производители программ с удалённой поддержкой.

Для каждого запишите: какие системы и данные, какой тип доступа (постоянный, по запросу, через их программу удалённого управления), кто у вас владелец отношений, когда заканчивается договор. Разделите поставщиков на критичных — чей взлом остановит бизнес или приведёт к утечке — и остальных. Проверять глубоко имеет смысл первых.

Шаг 2. Проверьте поставщика до договора

Проверка идёт в двух плоскостях.

Надёжность компании. Кто владелец, нет ли долгов, банкротства, судебных споров, негативной репутации. Как это сделать по бесплатным реестрам — в статье о проверке контрагента в Беларуси.

Зрелость в безопасности. Короткий опросник на 10–15 вопросов для критичных поставщиков:

• кто у них отвечает за информационную безопасность;
• используют ли двухфакторную аутентификацию для доступа к клиентам;
• у каждого инженера своя учётная запись или общий логин;
• где хранятся пароли от ваших систем;
• как быстро они сообщат вам об инциденте на своей стороне;
• проверяют ли свой код и компоненты на уязвимости;
• кому они передают часть работ;
• есть ли подтверждения: сертификат ISO/IEC 27001, результаты независимого аудита или пентеста.

Ответ «у нас всё безопасно» без подробностей — тоже ответ.

Шаг 3. Ограничьте доступ подрядчика

Здесь закрывается большая часть риска.

• Именные учётные записи для каждого инженера подрядчика, без общего «admin».
• Двухфакторная аутентификация обязательна.
• Доступ по запросу и по времени: учётная запись включается на время работ и выключается после, а не открыта круглосуточно.
• Только через ваш VPN или шлюз удалённого доступа, а не через установленную подрядчиком программу удалённого управления с постоянным подключением.
• Минимальные права: разработчику сайта не нужен доступ к бухгалтерии, интегратору 1С — к контроллеру домена.
• Сегментация: системы, с которыми работает подрядчик, отделены от остальной сети.
• Журналирование и, для критичных систем, запись сессий — чтобы понимать, кто и что сделал.
• Пароли от ваших систем — в вашем хранилище, а не в таблице у подрядчика.

Если подрядчик разместил ваши данные в облаке, проверьте его настройки по модели разделённой ответственности — подробности в статье о безопасности облачных сервисов.

Шаг 4. Пропишите безопасность в договоре

В договор или приложение к нему стоит включить:

• обязанность уведомить вас об инциденте, затрагивающем ваши системы или данные, в конкретный срок;
• минимальные меры защиты: двухфакторная аутентификация, именные учётные записи, хранение паролей;
• запрет передавать работы субподрядчикам без согласования;
• право на проверку или запрос подтверждений безопасности;
• возврат и удаление данных при окончании договора;
• ответственность за инциденты по вине подрядчика.

Если подрядчик обрабатывает персональные данные по вашему поручению, закон № 99-З предъявляет требования к содержанию такого поручения, и формулировки нужно согласовать с юристом.

Шаг 5. Следите за программными компонентами

Для компаний, у которых есть свой сайт, приложение или внутренняя разработка:

• SCA-проверка — автоматический поиск известных уязвимостей в сторонних библиотеках при каждой сборке. Как это встраивается в процесс — в статье о SAST, DAST и SCA.
• Список компонентов (SBOM) — перечень всех библиотек и версий: когда публикуют уязвимость, вы за минуты понимаете, затронуты ли.
• Фиксация версий и обновление зависимостей осознанно, а не автоматически до «последней».
• Проверка целостности — установка пакетов только из доверенных репозиториев с проверкой подписей или контрольных сумм.

Для купленных программ: обновления сначала ставятся на ограниченную группу компьютеров, программы работают с минимально необходимыми правами, а мониторинг замечает необычное поведение — например, новые исходящие соединения после обновления.

У Viviar проверку поставщика закрывают два пакета: «Проверка контрагента» — от 3 500 BYN за 3–5 рабочих дней, и экспресс-аудит ИБ — от 5 200 BYN, в котором разбирают доступы подрядчиков. Аудит собственного продукта с разбором кода и компонентов — «Запуск безопасной разработки» от 20 300 BYN. Все цены — на странице пакетов, направления — в услугах кибербезопасности.

Если атака пришла через подрядчика

1. Немедленно отключите доступ подрядчика: учётные записи, VPN, программы удалённого управления.
2. Свяжитесь с подрядчиком и выясните, что произошло на его стороне и какие ещё клиенты затронуты.
3. Сохраните журналы и не удаляйте учётные записи до окончания разбора.
4. Проверьте системы, к которым у подрядчика был доступ: новые учётные записи, изменения, закладки.
5. Если затронуты персональные данные — уведомите НЦЗПД; записи об инциденте храните не менее года по Указу № 40, а организации из перечня уведомляют Национальный центр кибербезопасности не позднее 1 часа.
6. После восстановления пересмотрите модель доступа — и для этого подрядчика, и для остальных. При окончании работы с поставщиком отзывайте доступы так же, как при увольнении сотрудника.

Чек-лист защиты от атак через поставщиков

• Есть список всех подрядчиков и сервисов с доступом к системам и данным
• Выделены критичные поставщики
• Критичные поставщики проверены как компания и по опроснику безопасности
• У каждого инженера подрядчика своя учётная запись с двухфакторной аутентификацией
• Доступ подрядчиков включается по запросу, а не открыт постоянно
• Подрядчики подключаются через ваш VPN или шлюз, а не через свои программы
• Действия подрядчиков в критичных системах журналируются
• В договорах есть срок уведомления об инцидентах и порядок возврата данных
• Сторонние библиотеки проверяются SCA-сканером
• При окончании договора доступы отзываются по чек-листу

Частые вопросы

Что такое атака через цепочку поставок простыми словами?

Это взлом компании через того, кому она доверяет. Злоумышленник атакует не вас, а вашего ИТ-подрядчика, производителя программы или разработчика библиотеки, а затем использует их доступ, обновление или код, чтобы попасть к вам. Такая атака опасна тем, что приходит по легитимному каналу и не выглядит подозрительной.

Как проверить подрядчика на информационную безопасность?

Сначала проверьте саму компанию по реестрам: собственники, долги, суды, репутация. Затем отправьте критичному подрядчику короткий опросник: кто отвечает за безопасность, используется ли двухфакторная аутентификация, как хранятся пароли клиентов, в какой срок сообщат об инциденте. Попросите подтверждения: сертификат ISO/IEC 27001, результаты аудита или пентеста.

Можно ли давать ИТ-аутсорсеру постоянный удалённый доступ?

Лучше не давать. Постоянный доступ с паролем администратора означает, что взлом подрядчика сразу даёт атакующему вашу сеть. Безопаснее выдавать доступ на время работ, через ваш VPN, с именными учётными записями и двухфакторной аутентификацией. Если постоянный доступ нужен для мониторинга, ограничьте права и журналируйте все действия.

Кто отвечает, если данные утекли через подрядчика?

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

Нужен ли SBOM небольшой компании?

Если у вас есть свой сайт, приложение или внутренние разработки — да, хотя бы в простом виде. Список библиотек и версий позволяет за минуты понять, затронула ли вас новая опубликованная уязвимость, вместо дней ручного поиска. Современные инструменты сборки и SCA-сканеры формируют такой список автоматически, отдельных затрат почти не нужно.

Вывод

Атака через цепочку поставок использует доверие: доступ подрядчика, официальное обновление или популярную библиотеку. Защита — это список поставщиков, проверка до договора, минимальный и контролируемый доступ, требования в договоре и контроль компонентов. Если хотите проверить, насколько безопасно устроены доступы ваших подрядчиков, — напишите нам.

Источники: NIST SP 800-161 Rev. 1 «Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations» (nist.gov); ENISA Threat Landscape for Supply Chain Attacks (enisa.europa.eu); CIS Controls v8, Control 15 «Service Provider Management» (cisecurity.org); OWASP Top 10 (owasp.org); Закон Республики Беларусь от 07.05.2021 № 99-З «О защите персональных данных» (pravo.by); Указ Президента Республики Беларусь от 14.02.2023 № 40 «О кибербезопасности» (pravo.by); цены — публичные пакеты Viviar, действуют с 01.09.2026.