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

Почему тема снова актуальна в 2026 году

Еще несколько лет назад атаки через цепочки поставок ассоциировались прежде всего с редкими масштабными инцидентами вроде SolarWinds. В 2026 году компрометация подрядчиков и других звеньев цепочки поставок стала устойчивым сценарием атак: по данным УЦСБ SOC, не менее 30% подтвержденных кибератак в России в 2025 году были совершены через компрометацию подрядчиков.

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

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

Показательный пример — атака через SaaS-интегратора Anodot, о которой стало известно в 2026 году. После компрометации провайдера злоумышленники получили токены аутентификации и использовали их для доступа к данным клиентов Snowflake. Кейс показывает, что современная supply chain-атака может проходить не через VPN, а через уже доверенную SaaS-интеграцию и выданные ей права.

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

• AI-агенты и MCP-интеграции. Компании все чаще предоставляют AI-системам доступ к репозиториям, API, внутренним данным и инструментам. В кампании GTG-1002, которую Anthropic исследовала как пример AI-enabled атаки, агентная система использовала MCP-серверы и выполняла значительную часть тактических операций практически автономно.
• Open source и CI/CD. Злоумышленник может атаковать не конечную организацию, а зависимость, репозиторий, систему сборки или другой компонент процесса разработки. В результате вредоносный код или скомпрометированная конфигурация попадают в продукт еще до его выпуска.
• SaaS и API-интеграции. Постоянные токены, сервисные учетные записи и OAuth-разрешения создают отдельный канал доступа к данным. Если их права не пересматриваются, компрометация внешнего сервиса может превратиться в путь внутрь корпоративной инфраструктуры.
• Субподрядчики и более глубокие уровни цепочки. Компания может контролировать непосредственного поставщика, но не знать, какие организации тот привлекает для разработки, поддержки, хостинга или обработки данных. В результате точка риска оказывается на следующем уровне цепочки, который формально не входит в периметр контроля заказчика.

Таким образом, supply chain — это уже не только вопрос проверки подрядчика перед подписанием договора. Цепочка поставок включает людей, SaaS-сервисы, API, программные зависимости, инфраструктуру разработки и AI-инструменты. Защищать приходится не только собственный периметр, но и те связи с внешними системами, через которые компания получает ПО, данные и сервисы.

Zero Trust как основа защиты от атак через подрядчиков

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

Для supply chain-рисков такой подход особенно опасен. Подрядчик может подключаться к инфраструктуре из внешней сети, использовать собственные устройства и иметь доступ только к отдельным системам, но при компрометации его учетной записи злоумышленник получает те же права. Поэтому задача Zero Trust — не просто проверить партнера перед началом работы, а постоянно подтверждать, что конкретный пользователь, устройство и запрос действительно имеют право на конкретное действие.

Применительно к подрядчикам базовые принципы Zero Trust сводятся к нескольким практическим требованиям:

1. Непрерывная верификация доступа. Прохождение подрядчиком аудита на старте сотрудничества не означает, что его учетная запись остается безопасной. Права, состояние устройства и параметры подключения должны периодически или непрерывно проверяться.
2. Проверка каждого запроса независимо от источника. Доступ не должен считаться безопасным только потому, что запрос поступил из корпоративной сети или от ранее проверенного подрядчика. Каждое обращение к ресурсу необходимо оценивать с учетом пользователя, устройства, контекста и требуемых прав.
3. Минимизация привилегий. Подрядчик получает только те права и доступ к тем системам, которые необходимы для конкретной задачи. Если для работы достаточно доступа к одному серверу или приложению, выдавать доступ ко всему сетевому сегменту не требуется.
4. Контроль устройств и сессий. Подключение с нового, непроверенного или не соответствующего требованиям устройства должно приводить к дополнительной проверке или ограничению доступа. Для привилегированных действий важно также контролировать и журналировать сессии подрядчиков.
5. Ограничение срока действия доступа. Права подрядчика должны автоматически прекращаться после завершения работ или истечения согласованного срока, а не сохраняться до ручного отключения.

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

Борис Соболев
Руководитель экспертного сопровождения BI.ZONE PAM
На практике эффективность zero trust чаще всего снижается из-за ошибок внедрения. Некоторые компании ограничиваются отдельными мерами, например, внедряют многофакторную аутентификацию для VPN, но сохраняют плоскую сеть внутри периметра. В результате злоумышленник, получивший доступ через подрядчика, может беспрепятственно перемещаться по инфраструктуре. Еще одна распространенная ошибка — выдача подрядчикам постоянных, а не временных привилегий, из-за чего доступ сохраняется дольше необходимого.

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

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

Как выстроить требования к подрядчикам «на берегу»

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

В договор и внутренние политики ИБ имеет смысл закладывать несколько обязательных требований:

1. SLA по информационной безопасности. Нужно заранее определить сроки уведомления об инциденте, порядок взаимодействия сторон и время предоставления первичной информации. Формулировок вроде «уведомить оперативно» недостаточно — конкретные сроки позволяют контролировать выполнение обязательств.
2. Право заказчика на аудит. Договор должен позволять проверять, выполняет ли подрядчик согласованные требования ИБ. В зависимости от уровня риска это может быть анализ документов и отчетов, аудит конфигураций, техническая оценка или проверка результатов тестирования на проникновение.
3. Требования к доступу. Для подключения к системам заказчика должны быть обязательными MFA, персональные учетные записи, принцип наименьших привилегий и журналирование действий. При необходимости стоит отдельно определить требования к устройствам, с которых подрядчик подключается к инфраструктуре.
4. Порядок работы с данными. В договоре стоит определить, какие данные подрядчик получает, где они хранятся, кто имеет к ним доступ и что происходит с ними после завершения работ. Для критичных данных необходимо отдельно закрепить требования к их передаче, хранению и удалению.
5. Exit-план. При расторжении договора или завершении проекта подрядчик должен вернуть или удалить данные, передать необходимые журналы и документацию по интеграциям, а также подтвердить отзыв всех выданных учетных записей, токенов, сертификатов и других средств доступа.

Формулировать требования с нуля необязательно. Для управления рисками цепочки поставок можно опираться на международные стандарты и рекомендации, в частности, ISO/IEC 27001 и NIST SP 800-161. При этом конкретные требования к подрядчикам должны определяться с учетом отрасли, критичности систем, типа данных и объема предоставленного доступа.

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

Антон Михайлов
Директор по развитию группы продуктов SASTAV (компания ShiftLeft Security)
В договор нужно включить перечень систем и данных, к которым подрядчик может обращаться, требования к многофакторной аутентификации и защите рабочих устройств, ведению журналов и срокам уведомления об инциденте. Там же стоит закрепить правила привлечения субподрядчиков, обязанность помогать в расследовании, порядок отзыва доступа и удаления данных после завершения работ. Для поставщика ПО добавляются требования к устранению критических уязвимостей, составу компонентов продукта и целостности обновлений. Важно избегать формулировок вроде «уведомить оперативно»: срок и состав передаваемой информации должны быть указаны прямо.

Если свести требования к минимальному чек-листу перед заключением договора с подрядчиком, имеющим доступ к инфраструктуре или данным, получится следующее:

• определены системы и данные, к которым подрядчик получает доступ;
• зафиксированы SLA по уведомлению и реагированию на инциденты;
• закреплено право заказчика на аудит и периодическую проверку;
• MFA, персональные учетные записи и журналирование обязательны для внешнего доступа;
• определены требования к устройствам подрядчика;
• привлечение субподрядчиков требует согласования и распространяет на них те же требования ИБ;
• установлен порядок работы с данными и их удаления после завершения работ;
• доступ предоставляется только через согласованный контур и ограничивается необходимыми ресурсами;
• предусмотрен exit-план с отзывом доступов, передачей необходимой документации и подтверждением удаления данных.

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

Как проверить, что подрядчик реально соблюдает требования, а не просто подписал бумагу

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

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

При этом даже без специализированных платформ есть набор красных флагов, которые стоит замечать при работе с любым партнером:

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

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

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

Чтобы такой контроль не зависел только от ручных проверок, его можно автоматизировать с помощью специализированных инструментов. На практике для разных задач используются несколько классов решений: PAM и IAM управляют доступом и учетными записями, EASM помогает отслеживать внешний периметр подрядчика, а SIEM/XDR — сопоставлять события и выявлять подозрительную активность.

Борис Соболев
Руководитель экспертного сопровождения BI.ZONE PAM
Если подрядчик получает доступ к критичным системам, до начала работ стоит провести техническую оценку его защищенности, а затем периодически повторять ее. Это может быть аудит конфигурации, security assessment или тестирование на проникновение — выбор зависит от уровня доступа и критичности выполняемых работ.

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

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

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

Что делать, если взлом уже произошел

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

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

Следующий шаг — определить масштаб инцидента. По журналам IAM, PAM, VPN, EDR и другим источникам нужно проверить, к каким системам обращалась скомпрометированная учетная запись, какие действия выполняла и были ли попытки повысить привилегии или переместиться в другие сегменты сети. Одновременно стоит проверить, не использовались ли украденные учетные данные для доступа к другим системам.

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

Игорь Юрин
Технический директор, руководитель направления цифровизации и цифровой трансформации, «ГИГАНТ — Компьютерные системы»
Если злоумышленник уже получил доступ к инфраструктуре, сдержать распространение атаки позволяет многоуровневая эшелонированная защита. В своих проектах мы, как правило, используем решения нескольких разработчиков и объединяем сильные стороны разных продуктов.

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

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

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

Типичные ошибки

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

• Излишнее доверие к «крупному» подрядчику. Размер и репутация вендора воспринимаются как гарантия безопасности, хотя масштаб компании и зрелость ее ИБ-процессов — разные вещи. Крупный подрядчик остается потенциальной точкой входа, особенно если обладает широкими привилегиями.

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

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

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

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

• Забытые доступы после окончания сотрудничества. Проект закрыт, а VPN-доступ, токены или учетные записи подрядчика остаются активными, потому что их отключение не включено в процедуру завершения работ.

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

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

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

Что делать частным лицам и малому бизнесу

Все сказанное выше — про корпоративные SLA, аудиты и микросегментацию — может выглядеть как задача для больших компаний с отдельным ИБ-отделом. Но принцип supply chain-риска работает и в меньшем масштабе: у фрилансера, ИП или небольшой команды тоже есть свои внешние сервисы, плагины, расширения и подрядчики.

Базовые меры защиты доступны и без специализированных платформ:

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

• Регулярно пересматривать сторонние интеграции. Подключенное к почте, CRM или облачному хранилищу приложение может получить доступ к данным. Неиспользуемые расширения, приложения и OAuth-подключения стоит отключать.

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

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

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

• Делать резервные копии критичных данных. Если сторонний сервис или учетная запись окажутся скомпрометированы, актуальная резервная копия поможет восстановить данные и снизить последствия инцидента.

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

Чек-лист: защита компании от Supply Chain-атак

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

• Доступ подрядчика проверяется при каждом обращении к защищенному ресурсу, а не только при первичном онбординге.
• Сторонние учетные записи, интеграции и сервисы контролируются независимо от того, кто выполняет действие — человек, программа или AI-агент.
• Доступ ограничен конкретными системами и ресурсами, необходимыми для работы подрядчика.
• Сеть и критичные системы сегментированы, чтобы компрометация одной учетной записи не открывала доступ ко всему контуру.
• Права подрядчиков соответствуют принципу наименьших привилегий и имеют ограниченный срок действия.
• Действия внешних учетных записей журналируются и анализируются на наличие аномалий.
• Внешний доступ осуществляется через контролируемый канал с ограничением по времени, источнику подключения и доступным ресурсам.
• В договоре закреплены требования ИБ, сроки уведомления об инцидентах и право заказчика на аудит.
• MFA и другие обязательные меры защиты определены для всех способов доступа подрядчика.
• Привлечение субподрядчиков требует согласования, а требования ИБ распространяются на всю соответствующую цепочку.
• Плановые аудиты дополнены continuous monitoring внешней инфраструктуры и признаков изменения security posture.
• После завершения работ доступы, токены и другие средства аутентификации подрядчика отзываются по формализованной процедуре.
• Для критичных подрядчиков заранее определен порядок действий при компрометации: блокировка доступа, расследование, изоляция и повторная оценка рисков.

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

В 2026 году supply chain-риски становятся шире традиционной модели «подрядчик подключается к сети». В цепочку входят SaaS-сервисы, программные зависимости, API, CI/CD и AI-инструменты. Поэтому контролировать необходимо не только сотрудников внешней организации, но и все автоматизированные учетные записи и интеграции, через которые сторонние системы получают доступ к данным и инфраструктуре компании.