Когда взломали партнера: управление рисками чужой ИТ-инфраструктуры

По данным «Лаборатории Касперского», в первом квартале 2026 года количество обнаруженных и предотвращенных ИБ-инцидентов в российских организациях выросло на 68% по сравнению с аналогичным периодом 2025 года. Растет и доля атак через подрядчиков: по данным УЦСБ SOC, в первом полугодии 2026 года каждая третья компрометация российских компаний происходила через инфраструктуру подрядчиков или сервис-провайдеров, хотя годом ранее — лишь каждая десятая. Можно ли обезопасить бизнес на случай взлома поставщика и как действовать, если утечка уже произошла? Об этом рассказывает Никита Котиков, руководитель продукта CyberRating CICADA8.

Риски взлома: достаточно ли защиты своего ИТ-контура?

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

Первое начинается с простой вещи — не передавать и не хранить на стороне подрядчика больше данных, чем действительно необходимо для его работы (принцип data minimization). Его действие хорошо иллюстрирует недавняя утечка данных клиентов Trezor через fulfillment-партнера ShipMonk. Политика компании ограничивала срок хранения данных у ShipMonk 90 днями. В результате компрометация затронула 13 689 записей именно за трехмесячное окно.

Для сравнения, SafePal практически одновременно раскрыл утечку сопоставимых клиентских данных, но по другому вектору – через уязвимость в плагине отслеживания заказов. Данные о них хранились значительно дольше и в утечку попали 39 798 записей, то есть примерно годовой объем информации.

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

Подрядчику не следует передавать полные исторические выгрузки клиентской базы, если для текущих операций достаточно небольшой ее части, позволять накапливать документы, платежные реквизиты и «сырые» дампы для аналитики. Особого внимания требуют аналитические и BI-контуры: данные там, как правило, хранятся дольше, накапливаются в большем объеме и могут удаляться или обновляться значительно реже, чем в операционных системах.

Но data minimization решает только половину задачи. Вторая — понять, за какими подрядчиками нужно следить особенно внимательно. На практике крупный подрядчик с высоким security rating, у которого хранится полная клиентская база и есть постоянный доступ к API заказчика, может представлять для бизнеса больший риск, чем значительно хуже защищенная типография, печатающая корпоративные визитки.

Вероятность компрометации второго поставщика выше, но потенциальные последствия первого несопоставимо серьезнее.

Опасные связи: признаки низкой защищенности

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

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

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

Наконец, существуют сигналы, которые могут указывать на подготовку атаки или уже произошедшую компрометацию. Появление доменов-двойников нередко предшествует фишинговой кампании против сотрудников подрядчика.

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

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

Произошла утечка: как локализовать риски?

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

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

Внутри компании одновременно запускаются три трека: технический, юридический и коммуникационный.

Технический аспект

Техническая команда прежде всего должна установить реальную зону поражения.

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

Одновременно необходимо собрать все предоставленные поставщику идентификаторы доступа — учетные записи, сервисные аккаунты, API-ключи, OAuth-приложения, VPN-профили и ключи к хранилищам — и понять направление интеграций.

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

Именно это произошло в цепочке Trezor — ShipMonk: точкой компрометации стал не собственный код подрядчика, а сторонняя аналитическая платформа Metabase, развернутая в его инфраструктуре. Злоумышленники эксплуатировали в ней уязвимость нулевого дня (CVE-2026-72898, CVSS 10.0) — неаутентифицированную SQL-инъекцию, позволяющую получить права администратора и доступ ко всем подключенным источникам данных.

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

Неопределенность следует трактовать в худшую сторону: потенциально скомпрометированным считается все, к чему технически имела доступ затронутая учетная запись или система, а не только подтвержденные выгрузки. Активные сессии и токены необходимо инвалидировать, API-ключи и сервисные учетные записи следует ротировать, права доступа — пересмотреть. Однако действовать по принципу «отключить все» не всегда безопасно для самого бизнеса.

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

Юридические и коммуникационные моменты

Параллельно запускается юридический трек.

Необходимо определить, относятся ли затронутые сведения к персональным данным, и учитывать обязательные сроки взаимодействия с регулятором: по 152-ФЗ первичное уведомление Роскомнадзора направляется в течение 24 часов, результаты внутреннего расследования – в течение 72 часов. Об утечке персональных данных также необходимо проинформировать ГосСОПКА: операторы, не подключенные к системе, делают это через то же уведомление на сайте Роскомнадзора, а подключенные (как правило, субъекты КИИ) – напрямую через НКЦКИ.

Принципиально, что отсчет начинается с момента, когда о факте инцидента узнал сам заказчик, а не после завершения расследования подрядчика.

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

Чем меньше в такой ситуации неопределенности, тем меньше пространства остается для слухов, фишинга и социальной инженерии.

Ничего личного: работа с подрядчиком после утечки

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

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

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

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

Инцидент – повод пересмотреть договоры не только с пострадавшим подрядчиком, но и с другими критичными поставщиками. Объем информации, которую заказчик получит во время инцидента, определяется тем, что было закреплено в договоре до него: в момент кризиса переговорная позиция заказчика слабее, чем кажется.

Поэтому заранее стоит закрепить срок уведомления об инциденте (24 часа с момента обнаружения, а не по завершении расследования), обязанность сохранять артефакты и не переустанавливать системы до их фиксации. Заказчик должен получить право на аудит и участие в расследовании, а подрядчик – лишиться возможности закрывать инцидент в одностороннем порядке без письменного заключения.

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

Чек-лист CISO после взлома подрядчика

1. Признать инцидент своим: назначить ответственного и запустить технический, юридический и коммуникационный треки.
2. Ограничить доступы: инвалидировать сессии, ротировать ключи, сузить права.
3. Определить зону поражения: какие данные затронуты, за какой период и через какие интеграции.
4. Закрыть обязательства: уведомить регулятора и клиентов, не дожидаясь окончания расследования подрядчика.
5. Пересмотреть режим: повысить категорию риска подрядчика, определить условия возврата доверия и обеспечить внеплановую проверку других контрагентов.

Контрольные метрики: время от компрометации до уведомления и от уведомления до локализации.