Сегодня трудно представить себе компанию без связей с внешним миром: клиентами, пользователями, поставщиками, партнерами, подрядчиками, компаниями, предоставляющими аутсорсинговые услуги и/или сервисы. Зачастую именно от того, как выстроены взаимоотношения с контрагентами, зависят успешность деятельности и развитие компании. В связи с этим особую значимость приобретают вопросы информационной безопасности при таком взаимодействии. В рамках данной статьи под контрагентами будем понимать сторонние (внешние) организации, реализующие услуги/работы или поставляющие товары, включая сервисы и программное обеспечение, на основании заключённых договоров.
Supply chain и Trusted Relationship attacks
Существуют следующие векторы кибератак: атака через цепочку поставок (supply chain attack) и атака через доверительные отношения (trusted relationship attack). Оба вектора непосредственно связаны с контрагентами, потому что злоумышленники, атакующие целевую компанию, используют контрагента (его сервис, программный продукт, ИТ-инфраструктуру, пользователей и т.п.) в качестве плацдарма и/или средства развития атаки.
В качестве примеров можно привести известные атаки:
Атака Stuxnet: вредоносный червь, ставший публичным примером применения кибероружия и обозначивший новую веху в кибербезопасности. Он отличался тем, что не просто заражал ПК, а целенаправленно воздействовал на промышленное оборудование через экосистему Siemens (Step7/Simatic), изменяя логику работы контроллеров и нарушая тем самым работу центрифуг по обогащению урана. По одной из версий: начало атаки и первичное заражение пошло от подрядчика.
Атака NotPetya Ransomware: атака червя шифровальщика-стирателя данных, начальным вектором проникновения которого было зараженное легальное обновление программы M.E.Doc (модуль бухгалтерской программы). Среди пострадавших множество украинских компаний, крупный грузоперевозчик Maersk, Роснефть.
Атака на SolarWinds: одна из самых известных атак на цепочку поставок, в которой злоумышленники скомпрометировали процесс выпуска обновлений ПО SolarWinds Orion и доставили вредоносный бэкдор многочисленным клиентам через легитимные апдейты.
Утечка данных из Ростелеком в январе 2025 через его подрядчика.
В недавнем отчете «Code Red 2026. Актуальные киберугрозы для российских организаций» эксперты Positive Technologies отмечают, что в 2026 году ожидается рост атак на цепочки поставок: через подрядчиков и поставщиков услуг злоумышленники смогут проникать в крупные бизнес-системы, а компрометация одного поставщика даст возможность атаковать сразу несколько компаний.
F6 в своем отчете «Киберугрозы в России и Беларуси. Аналитика и прогнозы 2025/26» тоже подчеркивают то, что атаки через цепочку поставок и доверительные отношения являются одним из самых эффективных векторов, и компаниям важно следить не только за состоянием собственной инфраструктуры, но и за киберустойчивостью своих подрядчиков и партнеров.
Компания может иметь хорошую защиту своих сервисов и инфраструктуры от внешних атак, но, если она пренебрегает вопросами безопасности при взаимодействии с контрагентами, то возникают угрозы, которые могут привести к следующим рискам ИБ:
риску компрометации ИТ-инфраструктуры компании через каналы доверенного взаимодействия;
риску утечки/утраты конфиденциальной информации;
риску использования небезопасного ПО/сервиса.
Возможен потенциальный риск, связанный с недоступностью самого контрагента в результате кибератаки.
Если этот контрагент обеспечивает критичный бизнес-процесс компании, то недоступность контрагента окажет негативное влияние на процесс и деятельность компании. Самой верной стратегией для этого риска является резервирование контрагента и/или его функции с возможностью быстрого перехода.
В целях сокращения масштаба и поверхности указанных выше атак на государственном уровне российскими регуляторами также устанавливаются требования и даются рекомендации, направленные на обеспечение безопасности при взаимодействии с контрагентами. В качестве приме��ов можно указать:
Стандарт Банка России от 01 июля 2018 года СТО БР ИББС‑1.4-2018, который устанавливает требования к управлению риском нарушения информационной безопасности при аутсорсинге существенных бизнес-функций финансовых организаций;
Приказ ФСТЭК от 11 апреля 2025 года №117, который устанавливает требования к защите информации, содержащейся в государственных информационных системах, с учетом работы с подрядными организациями.
Жизненный цикл взаимодействия с контрагентами
Для того, чтобы устранить угрозы и, соответственно, уменьшить описанные выше риски требуется строить безопасное взаимодействие с контрагентами по всему жизненному циклу, а меры безопасности рекомендуется внедрять на ранних этапах.
Выделяем следующие этапы жизненного цикла при взаимодействии с контрагентами:
преддоговорная работа;
заключение договора;
реализация договора;
контроль и мониторинг;
прекращение.
Предлагается предварительно ввести классификацию контрагентов в зависимости от способа взаимодействия и доступа к данным/системам компании.
По способу взаимодействия:
Требующие доступа в ИТ-инфраструктуру компании:
внедряют решение/систему;
сопровождают решение/систему;
разрабатывают ПО;
оказывают др. аутсорсинговые услуги.
Ведущие обмен данными с компанией (без доступа в ИТ-инфраструктуру);
Поставляющие ПО и сервисы.
По доступу к данным:
По конфиденциальности (например, персональные данные, коммерческая или банковская тайны);
По объему данных (например, критично от 1000 клиентских записей);
По операциям с данными (просмотр, выгрузка, редактирование).
По доступу к системам:
По критичности системы;
По правам и операциям (административные, специальные, пользовательские).
Пример упрощенной классификации контрагента:
| Доступ к конфиденциальным данным | Доступ к не конфиденциальным данным | Доступ к критичной системе | Доступ к некритичной системе |
Требующие доступа в ИТ-инфраструктуру | Категория 1 | Категория 2 | Категория 1 | Категория 2 |
Ведущие обмен данными | Категория 3 | Категория 4 | - | - |
Поставляющие ПО и сервисы | Категория 5 | Категория 5 | Категория 5 | Категория 5 |
Категория контрагента будет учитываться практически на каждом этапе взаимодействия и нужна для приоритизации (по уровню критичности) и группировки типовых требований/мер безопасности.
Преддоговорная работа
Результатом преддоговорной работы является выбор контрагента, соответствующего потребностям и требованиям компании. Выбор может быть осуществлен в рамках конкурсных процедур, установленных в компании. На данном этапе необходимо оценить контрагента и классифицировать его.
При этом оценка должна охватывать не только вопросы благонадежности контрагента, но и учитывать уровень зрелости ИБ. Не стоит забывать про заключение Соглашения о конфиденциальности (Non-Disclosure Agreement, NDA), в рамках которого начнется и будет дальше вестись обмен информацией.
Рекомендуем разработать специальные опросники, которые можно добавить в конкурсную документацию и учитывать при принятии решения о победителе. Опросники не должны быть большими и тяжелыми для контрагента, но в то же время, информации, заполненной даже на 70%, должно быть достаточно для получения качественной оценки (низкий, средний, высокий) об уровне зрелости ИБ. Важно заранее иметь градацию уровней зрелости в зависимости от заполненных полей опросника. Например:
Пункт опросника | Ответ | Весовой коэффициент |
п.1.1. Наличие лица, ответственного за ИБ | Да | 3 |
п.1.2. Наличие политики ИБ | Да | 3 |
п.1.3. Наличие средств антивирусной защиты | Да | 2 |
п.1.4. Наличие системы ИБ-мониторинга (SIEM/SOC) | Нет | 0 |
… | … | … |
п.3.8. Наличие DR-планов | Да | 3 |
п.3.9. Регулярное тестирование DR-планов | Частично | 1 |
ИТОГО: |
| 25 |
Хорошей практикой является онлайн или офлайн встреча с лицами, ответственными за информационную безопасность в контрагенте. На данной встрече есть возможность проговорить открытые вопросы по заполнению опросника и убедиться в квалификации заполняющих.
Заключение договора
После того как контрагент выбран, заключается договор, в соответствии с которым будет осуществляться дальнейшее взаимодействие. Важно включить в договорную документацию требования и положения ИБ в зависимости от ранее выбранной категории контрагента и с учетом законодательства РФ. Пусть это будет отдельное ИБ-приложение к договору, которое отражает как минимум, следующие важные моменты:
базовые средства/меры ИБ, которые должны выполняться (включая порядок контроля их выполнения);
специфические средства/меры ИБ (в зависимости от категории контрагента);
порядок привлечения субподрядчика;
порядок и сроки уведомления об ИБ-инцидент;
порядок и сроки уведомления об увольнении/переводе работников контрагента (в случае наличия доступа к ИТ-инфраструктуре);
соответствие регуляторным требованиям (например, при доступе к персональным данным).
Совместно с юридическим подразделением можно заранее подготовить шаблоны ИБ-приложений под каждую категорию контрагента. Это ускорит процесс согласования и заключения договоров.
На данном этапе для ведения учета рекомендуется также добавлять контрагента в перечень контрагентов, с которыми компания ведет или планирует взаимодействие. Если вести его в информационной системе (например, SGRC), то появляется возможность для интеграции/обмена данными с другими системами и автоматизации процедур (например, процедуры предоставления/отзыва доступа). Пример перечня контрагентов представлен ниже:
Наименование контрагента | Категория контрагента | Договор (реквизиты, срок) | Куратор контрагента[1] | Представители контрагента | Категория доступных данных | Доступные системы (права/роли) |
ООО Компания1 | Категория 1 | №13 от 02.02.2026 (на год) | Специалист АХО Иванов И. | Петров П. | Персональные данные | 1С (роль специалиста АХО) |
[1] Куратор контрагента – работник компании, ответственный за взаимодействие с контрагентом (представляет подразделение компании, которое непосредственно заинтересовано в контрагенте (его работах/товарах) и ведет коммуникацию с его представителями)
Реализация договора
Договор заключен, приступаем к взаимодействию с контрагентом. Взаимодействие может включать в себя: построение интеграционных каналов (например, через Site-to-Site VPN), пользовательский доступ на регулярной основе (например, через Remote Access VPN), доступ к критичным системам и/или к конфиденциальным данным, размещение/аренда серверов и т.д. Организация безопасного доступа контрагента в ИТ-инфраструктуру компании задача, требующая комплексного подхода с применением инструментов ИБ и построением соответствующих процессов. Об этом мы расскажем подробнее в нашей следующей статье.
Не стоит забывать про то, что взаимодействие может заключаться лишь в обмене информацией между компанией и контрагентом (без прямого доступа в ИТ-инфраструктуру компании). При этом важно понимать категорию данных, которыми планируется обмен, и определить каналы/способы обмена с учетом регуляторных требований.
Если речь идет об использовании сервиса или ПО, закупленного у поставщика, то нужно обращать внимание на следующие моменты:
репутацию поставщика;
встроенные механизмы и функции безопасности сервиса/ПО (наличие, зрелость реализации);
процесс безопасной разработки у поставщика (если он вендор ПО);
готовность и скорость устранения уязвимостей;
готовность и скорость реагирования на инциденты;
зоны разграничения ответственности (в случае сервиса).
При определении и реализации требований/мер ИБ (особенно, специфических для определенной категории) нужно руководствоваться моделью угроз/нарушителя.
Для одной компании важен исходный код, который она разрабатывает для продажи в виде ПО, для другой – клиентские данные, обрабатываемые в системах компании в большом объеме. От объекта защиты будет зависеть цепочка потенциальной атаки и ландшафт угроз/уязвимостей, которые необходимо учитывать.
Контроль и мониторинг
На этапе контроля и мониторинга взаимодействия с контрагентом необходимо вести непрерывный учет (см. выше пример шаблона перечня) и внедрить регулярные процедуры проверки или выверки, к примеру:
учетных данных работников контрагента, которым необходим доступ;
прав доступа (как на сетевом, так и на прикладном уровнях), выданных контрагенту (должен соблюдаться принцип «минимальных привилегий»);
срока действия договоров.
Также важно, при наличии систем ИБ-мониторинга, настроить отдельные (или учесть в уже имеющихся) правила обнаружения инцидентов, связанных с контрагентами, и разработать инструкции по реагированию на подобные инциденты. При настройке правил, к триггерам сработки и нетипичным аномалиям можно отнести: работу в выходные и/или ночные часы, множество событий выгрузки данных, использование управляющих портов/сервисов при интеграционном взаимодействие систем, попытки выполнить недоступные операции, проведение сетевого сканирования со стороны контрагента и др. Для определения нетипичных поведенческих аномалий хорошо бы использовать профиль контрагента, который был сформирован на предыдущих этапах в результате классификации и учета. Рекомендуется периодически тестировать инструкции по реагированию в рамках тестирования на проникновение или при киберучениях (возможно даже совместных с контрагентом).
Прекращение
Хоть и последний этап жизненного цикла, но не менее важный, чем остальные, это этап прекращения взаимодействия с контрагентом. Прекращение взаимодействия может быть временным (например, в случае инцидента – на время его расследования), частичным (например, отзыв доступа только у уволенных работников контрагента) или полным (в связи с завершением договора). В этом случае важно гарантировать:
отзыв прав доступа и блокировку учетной записи;
отзыв криптографических ключей и сертификатов;
прекращение обмена информацией;
безопасное удаление данных в системах контрагента.
Зоны ответственности
В ходе сопровождения взаимодействия с контрагентами по всему жизненному циклу для прозрачности и исключения конфликтов предлагается разграничить зоны ответственности следующим образом:
Роль | Зона ответственности |
Куратор контрагента | Определяет права доступа и каналы обмена, необходимые и достаточные для взаимодействия |
Юридическое подразделение | Формирует шаблоны Договоров/NDA с учетом требований ИБ |
Подразделение по закупкам | Взаимодействует с потенциальными поставщиками |
ИТ-подразделение | Предоставляет оборудование, готовит инфраструктуру, разворачивает ПО |
ИБ-подразделение | Определяет требования ИБ и формат опросника по уровню зрелости ИБ |
Служба безопасности | Оценивает благожелательность контрагента |
Представитель контрагента | Соблюдает правила и требования ИБ |
Итог
Итак, для того, чтобы защититься от киберугроз при взаимодействии с контрагентами необходимо внедрить меры безопасности по всему жизненному циклу, начиная от выбора контрагента и заканчивая отзывом прав доступа. Выстроить правильное и безопасное взаимодействие быстро не всегда получается, поэтому предлагаем начать со следующих шагов:
Провести инвентаризацию контрагентов, прав и полномочий доступа к данным/системам.
Провести инвентаризацию точек и технологий доступа контрагентов в ИТ-инфраструктуру компании.
Провести инвентаризацию каналов обмена данными.
Оценить текущие процессы, связанные с контрагентами (например, предоставления доступа, обмена данными и т.п.), и выявить ключевые проблемы ИБ.
Разработать/скорректировать модель угроз.
Определить категории, формат перечня и категорировать контрагентов.
Разработать опросники и критерии для оценки уровня зрелости ИБ (протестировать их на более «лояльных» контрагентах).
Разработать требования/положения ИБ в договоры.
Зафиксировать порядок и правила безопасного взаимодействия с контрагентами во внутреннем регламенте.
