Атаки через цепочки поставок: почему подрядчик — самое слабое звено в вашей безопасности
По данным исследования Yandex Cloud, 54% атак на корпоративную инфраструктуру в первом полугодии 2025 года были связаны с использованием легитимных учётных данных. Не уязвимостей в коде, не дыр в периметре — а паролей, которые кто-то получил и использовал по назначению. Просто этот «кто-то» не должен был их иметь.
Значительная часть этих случаев — подрядчики. IT-интегратор с доступом к серверной инфраструктуре. Аудиторская компания, которой открыли финансовые системы на время проверки. Разработчик, которому скинули логин от тестовой среды в Telegram три месяца назад. Работы давно закончены — доступ активен до сих пор.
Атаки через цепочки поставок (supply chain attacks) в 2026 году называют одним из главных векторов. И это не потому что злоумышленники стали умнее. Это потому что мы сами создаём для них удобную точку входа — каждый раз, когда передаём подрядчику доступ без контроля и забываем его отозвать.
Почему цепочки поставок становятся главным вектором атак
Прямая атака на крупную компанию с выстроенной защитой — это сложно. Фаервол, EDR, SOC, сегментация сети. Злоумышленник понимает: пробиться напрямую дорого и долго.
Подрядчик — другое дело. У него есть легитимный доступ к нужным системам. Его учётные данные не вызывают подозрений — это обычный рабочий логин. Его активность выглядит нормально — он же должен здесь работать. И при этом его собственная защита, как правило, значительно слабее: меньше ресурсов на ИБ, личные устройства, корпоративные пароли в личных менеджерах.
Схема простая: скомпрометировать подрядчика, получить его учётные данные, использовать их для входа в инфраструктуру заказчика. Целевая атака через нецелевое звено.
Именно это произошло в громкой атаке на SolarWinds в 2020 году — через обновление ПО подрядчика были скомпрометированы тысячи организаций по всему миру, включая государственные структуры США. В России паттерн повторяется: атаки через IT-интеграторов, через подрядчиков по обслуживанию АСУ ТП, через компании, имеющие привилегированный доступ к инфраструктуре КИИ.
Как выглядит типичный сценарий атаки через подрядчика
Проследим механику изнутри. Это не теория — это реконструкция типичного инцидента по характерным паттернам.
Шаг 1. Получение доступа подрядчиком. IT-интегратор приходит настраивать инфраструктуру. Ему нужен доступ к серверам, сетевому оборудованию, системам мониторинга. Инженер заказчика скидывает пароли в Telegram: «Вот логины, работайте». Пароли сохраняются в переписке — навсегда.
Шаг 2. Компрометация на стороне подрядчика. Через несколько недель один из инженеров подрядчика попадается на фишинг. Его рабочий ноутбук заражён инфостилером, который собирает все сохранённые пароли и передаёт их злоумышленникам. В числе украденных — учётные данные от инфраструктуры заказчика.
Шаг 3. Вход в инфраструктуру заказчика. Злоумышленники авторизуются в системах заказчика под легитимными учётными данными подрядчика. Для систем мониторинга это выглядит как обычная рабочая сессия. Никаких тревожных сигналов — если нет системы обнаружения аномалий.
Шаг 4. Разведка и подготовка. Используя доступ подрядчика, злоумышленники изучают инфраструктуру, ищут критические системы, повышают привилегии там где возможно. Этот этап может длиться неделями.
Шаг 5. Основная атака. Шифровальщик, кража данных, вывод из строя критических систем — в зависимости от целей. К этому моменту следы заметены, а причинно-следственную связь с подрядчиком установить сложно.
Что важно: на шагах 3–5 работы подрядчика давно закончены. Доступ просто не отозвали. Вся атака стала возможной из-за одного незакрытого аккаунта.
Пять причин почему подрядчики — системная уязвимость
1. Пароли передаются небезопасно
Telegram, WhatsApp, электронная почта — стандартные каналы передачи учётных данных подрядчикам. Пароль, отправленный в мессенджере, остаётся там навсегда: в истории переписки, в облачной синхронизации, на всех устройствах участников чата. Это не паранойя — это факт хранения данных мессенджеров.
2. Доступы не отзываются вовремя
Исследования показывают: в среднем доступы внешних подрядчиков остаются активными ещё несколько месяцев после окончания работ. Никто не отвечает за отзыв — HR занимается только штатными сотрудниками, IT-отдел не всегда знает что работы закончены.
3. Права выдаются с избытком
«Дайте администраторский доступ, чтобы не было проблем» — стандартная практика при работе с подрядчиками. Принцип минимальных привилегий игнорируется ради удобства. В результате внешний человек имеет доступ к значительно большему объёму систем, чем нужно для конкретной задачи.
4. Активность подрядчиков не мониторится
Штатные сотрудники работают в корпоративных системах регулярно — их паттерны активности известны, аномалии заметны. Подрядчик появляется эпизодически, его активность нерегулярна по определению. Это создаёт слепое пятно: нетипичное поведение сложно распознать на фоне нерегулярной активности.
5. Ответственность размыта
Когда утечка происходит через подрядчика, первый вопрос — кто виноват. Ответ с точки зрения закона однозначный: оператор персональных данных несёт ответственность вне зависимости от того, кто фактически допустил утечку. Ukids пострадала через Битрикс24 — штраф получила сама школа. Ответственность оператора не снимается тем, что доступ имел подрядчик.
Регуляторный контекст: что требует новый приказ ФСТЭК №117
С 1 марта 2026 года вступил в силу приказ ФСТЭК №117, заменивший приказ №17 от 2013 года. Требования к управлению доступами подрядчиков в нём существенно усилены.
Ключевые новые требования применительно к внешним пользователям:
УПД.1 — управление учётными записями. Требования к созданию, ведению и своевременному удалению учётных записей распространяются теперь явно на подрядчиков и временных пользователей. Учётная запись подрядчика должна создаваться только под конкретную задачу и удаляться по её завершении.
УПД.5 — минимизация привилегий. Принцип минимальных привилегий теперь обязателен для всех категорий пользователей без исключений, включая внешних. Выдать подрядчику «администраторский доступ для удобства» — прямое нарушение.
РСБ.1 — журналирование действий. Все действия внешних пользователей должны фиксироваться с той же детальностью, что и действия штатных сотрудников. Отсутствие журнала действий подрядчика — нарушение.
ЗТС.3 — контроль подключений. Требования к контролю удалённых подключений подрядчиков к инфраструктуре. Включая обязательную идентификацию и аутентификацию при каждом подключении.
Помимо ФСТЭК, при работе с подрядчиками, имеющими доступ к персональным данным, 152-ФЗ обязывает заключить договор поручения обработки с чётким разграничением ответственности. Без этого договора компания не сможет взыскать убытки с подрядчика, если утечка произойдёт по его вине.
Как правильно организовать доступы подрядчиков
Правильная система доступов для подрядчиков строится на пяти принципах.
Принцип 1. Никогда не передавать пароли напрямую
Пароль, который знает подрядчик — это пароль, который вышел за пределы вашего контроля. Правильный подход: подрядчик получает доступ через защищённую систему, где его действия фиксируются, а сам пароль он может использовать, но не забрать с собой.
Как это решает BearPass. Функция Shared Links создаёт временную защищённую ссылку на конкретный пароль с заданным сроком действия — час, день, неделя или одноразовое использование. Подрядчик переходит по ссылке, использует учётные данные — но пароль остаётся в хранилище компании. После истечения срока ссылка перестаёт работать автоматически. В мессенджере — только ссылка, которая уже нерабочая.
Принцип 2. Отдельная учётная запись для каждого подрядчика
Никаких общих логинов «для подрядчиков» или передачи учётных данных штатного сотрудника. Каждый внешний человек — отдельная учётная запись с явно ограниченными правами.
Как это решает BearPass. Создаёте временную учётную запись для подрядчика, добавляете его только в нужные папки с нужным уровнем прав. Подрядчик видит исключительно то, что необходимо для работы. Все его действия фиксируются под его учётной записью — атрибуция точная.
Принцип 3. Срок действия доступа с первого дня
Доступ подрядчика должен быть временным не по напоминанию, а архитектурно. Срок истёк — доступ закрылся автоматически. Никаких «напомни закрыть когда закончат».
Как это решает BearPass. При создании учётной записи или выдаче прав задаётся срок действия. По истечении — автоматическая деактивация без участия администратора. Подрядчик завершил работы раньше срока — немедленный отзыв одним кликом через Kill Switch.
Принцип 4. Журнал всех действий
Каждое действие подрядчика в системе фиксируется: авторизации, просмотры паролей, изменения, экспорт. С IP-адресом и точным временем.
Как это решает BearPass. Журнал событий накапливает полную историю действий каждого внешнего пользователя. При любом инциденте или вопросе регулятора — хронология действий подрядчика восстанавливается за минуты. Это и доказательная база, и инструмент мониторинга аномалий.
Принцип 5. Изоляция данных подрядчика
Если у вас несколько подрядчиков, работающих с разными проектами, — их данные не должны пересекаться. Подрядчик проекта А не должен видеть ничего связанного с проектом Б.
Как это решает BearPass. Модуль «Пространства» (версия 2.26.0) создаёт изолированные контуры внутри одной установки. Каждый подрядчик работает только в своём пространстве — данные других проектов для него физически не существуют.
Что проверить прямо сейчас: быстрый аудит доступов подрядчиков
Прежде чем выстраивать новые процессы, стоит понять что происходит сейчас. Вот пять вопросов, которые дадут честный ответ.
1. Вы знаете полный список подрядчиков, имеющих доступ к вашим системам прямо сейчас? Не тех, кому должны были выдать — а тех, у кого доступ активен. Если ответ «примерно знаем» — это проблема.
2. Когда последний раз каждый из них заходил в систему? Подрядчик не заходил шесть месяцев, но доступ активен — классический «призрак», который ждёт использования.
3. К каким конкретно системам у них есть доступ? Часто оказывается, что подрядчику выдали доступ к нескольким системам «заодно», и этот доступ значительно шире необходимого.
4. Где хранятся пароли, которые вы передавали подрядчикам? Если в переписке — эти пароли нужно сменить. Независимо от того, продолжает ли подрядчик работать с вами.
5. Есть ли журнал действий каждого подрядчика за последние полгода? Если нет — при любом инциденте у вас не будет доказательной базы.
Ответственность: кто платит если подрядчик допустил утечку
Этот вопрос задают часто — и ответ неприятный.
По российскому законодательству, оператор персональных данных несёт ответственность за утечку вне зависимости от того, кто фактически её допустил. Ukids пострадала через Битрикс24 — штраф получила школа, не Битрикс. Это прямо следует из 152-ФЗ: оператор отвечает за безопасность данных при их обработке, включая обработку через подрядчиков.
Размер штрафов по новой редакции КоАП: от 3 до 15 млн рублей при первой утечке, от 1 до 3% годовой выручки при повторной.
Единственный способ переложить ответственность на подрядчика — заключить договор поручения обработки персональных данных с чётким разграничением ответственности. Тогда при утечке по вине подрядчика можно предъявить к нему регрессный иск. Но это не снимает ответственности с оператора перед регулятором — только даёт инструмент для последующего взыскания убытков.
Что реально смягчает ответственность при инциденте через подрядчика: документально подтверждённые технические меры защиты, ведение журнала действий подрядчика, своевременное обнаружение инцидента и уведомление Роскомнадзора в течение 24 часов.
Дело РЖД в феврале 2026 года — показательный прецедент: апелляция отменила штраф именно потому, что компания смогла документально подтвердить принятые меры защиты и факт целенаправленной внешней атаки. Наличие журнала событий и настроенных технических мер стало аргументом в суде.
Чеклист: безопасная работа с подрядчиками
Итог
Атаки через цепочки поставок эффективны не потому что сложны технически. Они эффективны потому что мы сами создаём точку входа — каждый раз когда передаём пароль в мессенджере, выдаём избыточные права «для удобства» и забываем отозвать доступ после окончания работ.
Закрыть этот вектор технически проще, чем кажется. Нужны четыре вещи: пароли не передаются напрямую — только через временные защищённые ссылки; каждый подрядчик работает в изолированном контуре с минимальными правами; срок доступа ограничен и истекает автоматически; все действия фиксируются в журнале.
Приказ ФСТЭК №117, вступивший в силу в марте 2026 года, теперь обязывает выполнять эти требования. Но даже без регуляторного давления это просто здравый смысл: партнёр, которому вы доверяете, не застрахован от компрометации на своей стороне. Ваша задача — сделать так, чтобы его компрометация не стала вашей.
Часто задаваемые вопросы
Что такое атака через цепочку поставок? Supply chain attack — взлом целевой организации через её подрядчиков или поставщиков ПО. Злоумышленник компрометирует менее защищённое звено, которое имеет легитимный доступ к инфраструктуре цели.
Почему подрядчики — самое уязвимое звено? Им передают пароли в мессенджерах, выдают избыточные права, не отзывают доступы после завершения работ и не мониторят их активность так же тщательно как штатных сотрудников. При этом их собственная защита слабее.
Кто несёт ответственность за утечку через подрядчика? По 152-ФЗ — оператор персональных данных, то есть ваша компания. Единственный способ переложить убытки на подрядчика — заключить договор поручения обработки с чётким разграничением ответственности.
Как правильно передать доступ подрядчику? Через временные защищённые ссылки с ограниченным сроком действия — никаких паролей в мессенджерах. Отдельная учётная запись с минимальными правами для каждого подрядчика. Срок доступа задаётся заранее и истекает автоматически.
Что требует новый приказ ФСТЭК №117 в части подрядчиков? Обязательное ведение учётных записей временных пользователей, соблюдение принципа минимальных привилегий для внешних пользователей, журналирование всех их действий и контроль удалённых подключений.