Supply chain: как выстроить кибербезопасность в работе с подрядчиками

Качественный сдвиг

Перенос акцента с классического взлома ИТ-периметра на эксплуатацию доверенных интеграций партнеров и подрядчиков объясняется просто: защищенность компаний, особенно крупного бизнеса, за последние годы заметно выросла. Enterprise-сегмент инвестировал в EDR, SOC, сегментацию, контроль доступа и мониторинг аномалий.

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

По информации Verizon DBIR, доля утечек данных с участием третьих сторон за год выросла вдвое и достигла 30% от всех подтверждённых инцидентов в мире. Российская статистика показывает схожую динамику: по данным центра исследования киберугроз Solar 4RAYS, почти треть всех кибератак хакеры в 2025 году совершали через подрядчиков.

Причины привлекательности

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

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

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

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

Дополнительная проблема заключается в том, что центр реагирования заказчика часто не имеет доступа к внутренним логам и событиям инфраструктуры подрядчика. В результате компрометация партнёра может месяцами оставаться за пределами видимости корпоративной ИБ-службы.

Яркие примеры

Последние атаки на Zara и Vimeo идеально иллюстрируют этот тренд. В обе компании заходили через одного технологического партнёра — платформу аналитики Anodot. Злоумышленники не взламывали инфраструктуру напрямую. Вместо этого они получили доступ к токенам и легитимным интеграционным механизмам подрядчика, а затем начали действовать внутри корпоративных систем от имени доверенного сервиса.

В кейсе Zara злоумышленники использовали токены доступа партнёра для подключения к облачным хранилищам BigQuery и Snowflake. А затем воспользовались возможностью выгружать клиентские данные в штатном режиме. В Vimeo сценарий включал в качестве цели технические метаданные и информацию о видеоконтенте пользователей.

Разница принципиальна: последствия определялись не самим фактом компрометации подрядчика, а тем, насколько глубоко этот подрядчик был интегрирован в инфраструктуру клиента и какие права ему были назначены.

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

Кризис доверенной интеграции

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

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

Проблема усугубляется тем, что рисками подрядчиков многие до сих пор управляют в логике формального комплаенса. Проверка поставщика нередко сводится к заполнению анкет, наличию сертификатов, пунктов в договоре и декларативному соответствию требованиям регуляторов. На бумаге такая модель выглядит убедительно, но на практике она почти ничего не говорит о реальном уровне защищенности партнёра.

Возникает иллюзия безопасности: если подрядчик подтвердил наличие 2FA, SOC, политик ИБ и процедур реагирования, значит риск считается контролируемым. Однако злоумышленники атакуют не документы и не процессы согласования. Они работают с уязвимостями внешнего периметра, плохо защищёнными API, раскрытыми токенами, ошибками конфигурации облачных сервисов и компрометацией инфраструктуры разработки.

Именно поэтому традиционные модели third-party risk management начинают быстро устаревать. Подход к управлению рисками начинает постепенно смещаться от бюрократического контроля к непрерывному технологическому мониторингу.

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

Дефицит видимости

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

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

Многие компании до сих пор недостаточно хорошо понимают, какие именно подрядчики имеют доступ к критичным системам, какие токены и сервисные аккаунты используются в интеграциях, насколько глубоко внешние сервисы встроены в бизнес-процессы и какие данные реально могут быть доступны при компрометации партнёра.

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

Оставьте доверие в прошлом

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

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

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

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

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

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

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