Крупнейшие утечки через поставщиков: разбор кейсов

Утечки через поставщиков – это класс инцидентов, при которых компрометация происходит через третьи стороны, имеющие легитимный доступ к данным, системам или инфраструктуре организации. Это могут быть ИТ-интеграторы, SaaS-провайдеры, аутсорсеры, сервисные компании – любой внешний участник, которому компания открыла доступ к своим ресурсам.

По данным вице-президента «Ростелеком» по ИБ, приведённым в интервью ТАСС в декабре 2025 года, 23% всех атак на компанию происходят не напрямую, а через подрядные организации. Злоумышленники целенаправленно охотятся за теми, кто что-то разрабатывает или обслуживает для крупного заказчика.

В 2025 году в открытом доступе появилась информация о компрометации веб-ресурсов крупной телекоммуникационной компании (условно назовём её «Маяк»). Злоумышленники заявили о получении доступа к базам данных отдельных информационных систем и опубликовали часть информации в качестве подтверждения. В опубликованных материалах содержались пользовательские данные, включая контактную информацию и сведения из обращений через формы обратной связи. Объём опубликованной информации составлял значительное количество записей, относящихся к предыдущим периодам работы сервисов.

Компания «Маяк» подтвердила факт инцидента и сообщила, что причиной стал внешний доступ с использованием легитимных учётных записей подрядной организации. Внешний поставщик выполнял работы по сопровождению отдельных интернет-ресурсов и обладал необходимыми правами доступа для выполнения своих задач. Роскомнадзор сообщил, что уведомления об инциденте не получал – нарушение требований 152-ФЗ об обязательном уведомлении в течение 24 часов. Регулятор впоследствии попытался привлечь Компанию «Маяк» к ответственности, однако суд в штрафе отказал: утечка была квалифицирована как произошедшая на стороне подрядчика.

В 2022 году в открытом доступе появилась база данных одной из крупных логистических организаций (условно назовём её «Орбита»), содержащая информацию о клиентских операциях. В опубликованной выгрузке содержались различные категории данных: сведения об отправлениях, контактная информация пользователей, данные получателей и технические параметры операций. Хакер, опубликовавший фрагмент базы, заявлял, что полный дамп охватывает данные всех клиентов компании. Роскомнадзор направил запрос с требованием предоставить детальную информацию о произошедшем.

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

В 2022 году данные пользователей одного из крупных онлайн-сервисов (условно назовём его «Горизонт») оказались опубликованы в открытом доступе. В опубликованной информации содержались сведения о пользовательских операциях, включая контактные данные, адресную информацию и параметры заказов. После публикации данных, злоумышленники создали интерактивную карту с данными клиентов. Адреса были нанесены вплоть до номера квартиры. Это многократно усилило репутационный ущерб инцидента. Первая версия компании: к утечке привели недобросовестные действия одного из сотрудников сервиса. Роскомнадзор составил административный протокол, суд назначил штраф более 50 тысяч рублей.

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

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

По данным Positive Technologies, ИТ-подрядчики становятся стратегической целью именно потому, что их периметры зачастую защищены слабее, чем инфраструктура заказчиков. Компрометация одного поставщика открывает доступ сразу к нескольким организациям-клиентам. Для компаний это означает, что модель «закрыть свой периметр» перестаёт работать в той мере, в которой бизнес зависит от внешних поставщиков.

Атаки через третьи стороны не представляют собой единый метод – это класс техник, объединённых общей логикой: использование доверенного доступа как вектора проникновения. MITRE ATT&CK выделяет несколько техник, которые чаще всего фигурируют в подобных инцидентах.

T1195 – Supply Chain Compromise. Компрометация на уровне цепочки поставок: злоумышленник встраивается в процесс разработки, обслуживания или поставки программного обеспечения. Например, внедрение вредоносного кода в обновление легитимного продукта, которое затем автоматически устанавливается у сотен заказчиков. В российской практике этот вектор реализуется чаще через компрометацию подрядчика, имеющего доступ с правами администратора к инфраструктуре клиента, а не через модификацию кода.

T1078 – Valid Accounts. Использование легитимных учётных записей, именно этот вектор зафиксирован в первом и втором рассмотренном случае. Злоумышленник не взламывает защиту напрямую. Он использует уже существующие учётные данные: украденные через фишинг, полученные из утечки у самого подрядчика или купленные на теневых рынках. Сложность обнаружения таких атак в том, что действия злоумышленника неотличимы от штатной активности подрядчика.

T1199 – Trusted Relationship. Эксплуатация доверенных отношений между организацией и третьей стороной. Подрядчик, имеющий VPN-доступ, прямое подключение к внутренним системам или привилегированную учётную запись, фактически становится частью доверенного периметра заказчика. VPN-туннель между внешним хостингом и внутренней сетью не был выделен в изолированный сегмент. После взлома хостинга доступ немедленно распространился вглубь инфраструктуры. Именно этот сценарий был реализован в третьем рассмотренном случае.

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

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

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

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

2. Кто несёт ответственность, если данные утекли через подрядчика?
По 152-ФЗ ответственность за защиту персональных данных несёт оператор – компания, которая их собирает и обрабатывает. В 2025 году Верховный суд подтвердил это в деле Минтруда: ведомство пыталось переложить ответственность на подрядчика, имевшего доступ к данным, но суд указал, что именно оператор обязан контролировать подрядчиков.

3. С чего начать выстраивание контроля над рисками третьих сторон?
Первый шаг – инвентаризация: кто из подрядчиков имеет доступ к данным или системам компании и в каком объёме. Далее, приоритизация по уровню риска и базовая оценка зрелости ИБ у ключевых поставщиков. Требования к безопасности подрядчика должны быть закреплены в договоре.