Привет, Хабр! Меня зовут Алиса, я методолог информационной безопасности в Ozon. Я занимаюсь построением и улучшением процессов ИБ начиная от регламентов и требований до внедрения практических контролей в работу команд. Один из сложных участков в ИБ — работа с контрагентами. Компании используют внешние сервисы, подрядчиков, аутсорсинг, облака, интеграции и внешнюю разработку. При этом далеко не всегда понятно, кто отвечает за безопасность этих связей и с чего вообще начинать.
В различных прогнозах (Gartner, IBM) трендов угроз информационной безопасности продолжают оставаться угрозы, связанные с цепочками поставок. Но компании не всегда понимают, с каких шагов начинать управление ИБ-рисками при работе с контрагентами. При этом игнорировать такие риски нельзя: инциденты у поставщиков могут затронуть данные, процессы и инфраструктуру компании. В статье я расскажу, как по шагам выстраивать безопасную работу с цепочками поставок — от базовых требований в договорах до анкетирования, контроля доступов и участия ИБ в согласовании критичных контрактов.
Сразу оговорюсь, что у разных компаний разная зависимость от контрагентов и, соответственно, в вашем конкретном случае приоритеты могут быть расставлены по-другому, но общий метод останется тем же. Порядок работ в этой статье основан на том, как процессы протекают в больших компаниях, где внедрение изменений может идти долго и сложно.
Давайте определимся с двумя вещами: кого мы рассматриваем как контрагента и каков жизненный цикл контрагента.
Кто такой контрагент?
В качестве контрагента стоит рассматривать всех, кто работает с компанией и при этом не является штатным работником. Почему? Потому что штатные работники обязаны выполнять ваши локальные нормативные акты, а все остальные — нет. Также мы не будем рассматривать как контрагентов клиентов компании, условия работы с ними должны формироваться в рамках работы с продуктами и услугами компании.
Итак, под термин «контрагент» могут подпадать:
Контрагенты по основным направлениям бизнеса — на маркетплейсах это, например, крупные селлеры, с которыми идёт обмен данными по API.
Поставщики бэк-офиса — например, арендодатель офиса, со СКУД которого у вас есть интеграция.
«Работники по ГПХ», самозанятые, ИП, которые оказывают вам услуги, — дизайнеры, ресёрчеры и прочие индивидуальные исполнители, работающие по заданиям.
Аутсорсинговые компании — похожи на предыдущий пункт, но контракт у вас не с индивидуальным исполнителем, а с другим юрлицом. Некоторые небольшие компании отдают на аутсорсинг целые направления — например, бухгалтерию, рекрутинг.
Разработчики и поддержка сервисов и ПО, которые использует ваша компания, например облачная почта и видеозвонки.
ЦОДы и хостинги, где размещены ваши сайты, собственная инфраструктура.
Государственные органы и организации, сервисами которых вы пользуетесь или с которыми вы интегрируетесь, например Госуслуги (ЕСИА), ФНС.
Иными словами, контрагентом можно считать почти любого внешнего участника, с кем у вас есть взаимоотношения по договору, оферте и по соглашению о взаимодействии.
Это не значит, что вам нужно заниматься сразу всеми, — вы можете расставлять приоритеты в зависимости от рисков в вашей компании, учитывая:
зависимость вашей компании от конкретного типа контрагентов (например, облачные провайдеры для основных функций в компании — почты, звонков, CRM-систем и т. д.);
наличие у контрагентов административных доступов к системам или инфраструктуре, доступов к критичным данным (исходный код, финансовая информация, базы данных);
сложность замены поставщика (интеграции, кастомизации, отсутствие конкурентов);
наличие регуляторных рисков при взаимодействии с поставщиком (юрисдикции, обмен персональными данными, влияние на КИИ).
Жизненный цикл контрагента
Чтобы управлять рисками, полезно смотреть на контрагента не как на запись в договорной системе, а как на участника процесса с жизненным циклом. Условно цикл можно разделить на несколько этапов.
До договора. На этом этапе компания формулирует потребность, анализирует возможных поставщиков и выбирает контрагента.
Заключение договора. Здесь анализируются продукт или услуга, согласуются условия договора и требования по безопасности.
Действующий договор. На этом этапе предоставляются доступы, контролируется качество и безопасность услуг, идёт взаимодействие по инцидентам и контролируется выполнение требований.
Продление или изменение сотрудничества. Нужно проверять, остаются ли условия актуальными и соответствует ли контрагент требованиям безопасности.
Завершение сотрудничества. Здесь важно отозвать доступы, принять результаты работ, зафиксировать причины завершения и убедиться, что у контрагента не осталось лишних прав или данных.
Помимо этапов жизненного цикла, есть два сквозных направления, которые нужно учитывать постоянно:
регламентация и документирование процедур работы с контрагентами;
анализ рисков взаимодействия с контрагентами.
Теперь перейдём к практике. Представим ситуацию, что в компании раньше не занимались безопасностью взаимодействия с контрагентами. С чего начать?
Этап 1 — Быстрые меры: договоры, NDA и критичные поставщики
Так за что же хвататься? Как ни странно — за «бумажки».
Первым делом обеспечьте, чтобы во всех новых договорах с контрагентами, которые имеют доступы в ваши системы или с которыми будут интеграции, появились требования по информационной безопасности на бумаге. За основу вы можете взять публичные стандартные оговорки любой компании, например Ozon.
Также стоит уточнить у ваших юристов:
со всеми ли контрагентами заключаются NDA;
есть ли у вас формы поручений на обработку персональных данных;
включаются ли в договоры требования по защите информации;
предусмотрена ли ответственность за нарушение требований ИБ, NDA и поручений на обработку данных.
Если их нет, напишите их и договоритесь с юристами, чтобы их добавляли во все новые и пролонгируемые договоры.
Почему это важно? Взаимоотношения между юридическими лицами базируются на договорах. Если чего-то не было в договоре — нет и ответственности. Договор возлагает эту ответственность на вашего контрагента. Только договорами, конечно, не спастись, и об этом мы поговорим дальше.
Следующий шаг — получить доступ к системе, где хранятся договоры с контрагентами. Для чего он нужен?
В случае инцидента у других компаний у команды ИБ будет возможность быстро проверить, есть ли у вашей компанией взаимоотношения с компанией, в которой произошёл инцидент, и оценить, может ли он задеть вас.
Проверить, есть ли требования по ИБ в договорах с самыми критичными контрагентами.
Для работы по инцидентам выделите специалиста, который будет помогать команде реагирования по инцидентам у контрагентов, запросите для него доступ к договорам и проинструктируйте коллег звать этого человека в случаях инцидентов и подозрений на инциденты у контрагентов.
Определите топ-5–10 (в зависимости от размеров вашей компании и количества поставщиков) самых критичных поставщиков для вашего бизнеса, ИБ которых важна для вашей компании. Это могут быть, например:
ЦОД или облака, где хостится ваша инфраструктура;
облачные системы, без которых остановится бизнес, — CRM, ERP, почтовые сервисы, облачные хранилища, финансовые и платёжные системы;
внешняя разработка ваших основных систем.
Просмотрите договоры с ними: есть ли там требования по безопасности и надёжности предоставляемых услуг? Есть ли поручения обработки ПДн и NDA? Если их нет, зафиксируйте, чего не хватает, и сообщите ответственным за эти договоры в компании. Обсудите с ними, чем грозят вашей компании инциденты у этих поставщиков и что можно сделать: заключить дополнительные соглашения или, если откажутся, искать других поставщиков.
И напоследок — инициируйте ревизию учётных записей и доступов контрагентов. Эта задача может оказаться разной степени сложности в зависимости от зрелости ИБ и ИТ в вашей компании, поэтому универсальных советов мы тут не дадим. Но опираться нужно на следующие принципы:
если договор уже не действует или его не было, действующих учёток и доступов у контрагента быть не должно,
одна учётка — один человек, и для каждой учётки должно быть известно, кому она принадлежит, не должно быть групповых и обезличенных учёток;
неиспользуемые учётки должны быть отключены, как и учётки уволившихся работников контрагента;
доступы должны соответствовать услугам в договоре и быть минимально необходимыми для их выполнения;
все выданные права должны быть выданы по заявке и согласованы в установленном в компании порядке.
На этом моменте можно выдохнуть и оглянуться назад: вы подняли безопасность взаимодействия с поставщиками на один уровень выше. Появились контроли на этапах «заключение договора» и «действующий договор», проведён разовый анализ по направлению «завершение сотрудничества». Ещё не процессы, но есть за что ухватиться в случае инцидента или спорной ситуации.
Этап 2 — КУСь для контрагентов: анкеты, учётные записи и базовый регламент
Договоры дают вам информацию о том, что вам поставляют или какие услуги оказывают. Но они не говорят о том, какой уровень ИБ у контрагента, насколько он в состоянии выполнять ваши требования по ИБ, а ещё в договорах, скорее всего, нет контактов на случай инцидентов ИБ. Здесь вам поможет анкетирование.
Создайте базовую анкету с вопросами о сути планируемых взаимоотношений, необходимости доступов в вашу инфраструктуру, интеграций, передаче конфиденциальной информации и о контактах людей, ответственных за безопасность. Определите перечень типов контрагентов, их услуг, особенностей взаимодействия, по которым необходимо запрашивать анкету до договора. Договоритесь с отделом закупок, что это обязательный этап для контрагентов, которые участвуют в конкурсах или с которыми планируется заключить договор. Мы в Ozon называем анкетирование контрагентов «Кусь» от KYC — know your contractor.
Определите признаки критичных контрагентов, о состоянии безопасности которых вам нужно знать больше. Проблемы с безопасностью у этих контрагентов могут нести наибольшие риски для вашей компании. Сделайте для них расширенную анкету. Попросите закупки информировать вас о заполнении расширенных анкет.
Что дальше? Помните, как вы искали учётки контрагентов на прошлом этапе? Определите правила создания таких учёток: их должно быть просто отличить от учёток штатных сотрудников (например, добавьте маркер в логин) и должны оставаться следы их заведения, например тикет с указанием контрагента и номера договора.
На этом этапе также пора выделить отдельную роль сотрудника ИБ, который будет организовывать работу по направлению безопасности контрагентов. В большой компании задач хватит на полную занятость, и даже не одного специалиста, а в меньших эти задачи могут быть совмещены с другими организационными задачами по ИБ.
И уже можно зафиксировать результаты вашей работы в виде небольшого регламента. Будет это регламент на внутренней вики или локальный нормативный акт, зависит от внутренней культуры вашей компании. В регламенте пропишите:
анкетирование потенциальных контрагентов, место хранения анкет;
необходимость заключения NDA, включения требований ИБ в договоры;
требования к учётным записям контрагентов, принцип минимальных доступов;
требования к безопасному обмену информацией;
отзыв доступов при окончании договоров;
зоны ответственности внутреннего заказчика договора, закупок, юристов, ИБ (включая роль ответственного за безопасность контрагентов).
Можно зачесть себе +1 уровень — прокачку по направлениям «до договора», «действующий договор», «регламентация и документирование». И вот уже по каждому направлению есть понятная точка опоры для дальнейшего развития.
Этап 3 — Встраиваем ИБ в процессы
Первые два этапа обычно дают быстрый эффект. Вы закрываете очевидные пробелы: договоры, NDA, анкеты, критичных поставщиков, учётные записи.
Дальше начинается более сложная часть. Нужно не просто проверять уже случившиеся взаимодействия, а встраивать ИБ в процессы выбора контрагентов, согласования договоров, выдачи доступов и приёмки результатов работ.
Главное, о чём можно задуматься, — согласование доступов контрагентов со стороны ИБ. Что проверять ИБ в таких заявках на доступ?
Наличие договора и NDA с контрагентом.
Соответствие запрашиваемых доступов предмету договора, поручению на обработку ПДн. Достаточность требований по ИБ для запрашиваемых доступов — например, предупреждён ли контрагент, что у него будет доступ к коммерческой тайне, ознакомлен ли с правилами работы в конкретной системе.
Допустимо ли в вашей компании выдавать эти доступы нештатным сотрудникам — например, если запрашивается административный доступ, доступ к коммерческой тайне, к специальным категориям персональных данных и т. п.
Здесь проблема может быть в первую очередь в том, что обработка таких заявок занимает немало времени у специалиста ИБ и вы не сможете поручить эту работу стажёру, здесь нужен человек с некоторым опытом в ИБ. То есть вам нужно найти постоянный ресурс на такой процесс. Вторая проблема может возникнуть, если вы на этом этапе начнёте отклонять заявки на доступы, которые нужны для выполнения договора, и менеджерам придётся либо искать другие пути выполнения договора, либо разрывать договор.
Вы также можете включить ИБ в процесс создания учётных записей для контрагентов, проверяя наличие договора и NDA на этом этапе. Такую работу можно поручить менее квалифицированным специалистам, и она предотвратит доступ контрагентов в вашу сеть до оформления отношений с ними, но без согласования доступов у вас всё ещё не будет контроля за тем, какие доступы есть у контрагентов и не избыточны ли они.
По-хорошему вам нужно также включиться в процесс согласования проектов договоров с критичными контрагентами, чтобы предотвращать ситуации проблем с безопасностью, когда договор уже подписан. Это менее тривиальная задача, поскольку:
Договор надо было заключить ещё вчера, а это значит, что у вас будет сжатый SLA на согласование и часто будут требовать сделать ещё быстрее.
Компетенций одного специалиста ИБ может не хватить на анализ всего проекта — вам может потребоваться и специалист от комплаенса, и аппсек (AppSec), и инфраструктурный инженер для комплексной оценки. А это значит, что они должны иметь возможность бросить другие задачи и переключиться на согласование.
Вам надо объяснить закупкам, юристам, по каким признакам вас необходимо звать согласовывать проект, — это им будет неочевидно, поскольку для закупок может быть «договор маркетинговых услуг», а для вас это «разработка лендинга, который будет хоститься за рубежом и собирать персональные данные», — и договориться, что они действительно будут это делать.
Закупки не смогут определить состав специалистов ИБ — они должны звать кого-то конкретного от ИБ, кто уже будет звать других ИБ-специалистов. У этого человека должна быть замена на время отпуска. Если на прошлом этапе вы не выделили отдельного сотрудника, который отвечает за безопасность контрагентов, здесь без него уже не обойтись.
Вам нужно будет продумать, что делать в тех случаях, когда ваши требования откажутся включать в договор.
Здесь может помочь решение браться не за все критичные договоры сразу, а постепенно, начав с одного типа — например, внешней разработки. Постройте процесс на маленьком объёме и дальше потихоньку включайте новые типы контрагентов и услуг.
По мере согласования договоров собирайте базу требований и условий, по которым они будут включаться в ТЗ, — это поможет сократить затраты времени на формирование требований к следующим проектам.
В случаях когда у вас есть требования ИБ к результату выполнения работ — например, при внешней разработке — логично будет проводить приёмку результатов работ и проверку выполнения предъявленных требований. Здесь самое важное, чтобы требования, которые вы хотите проверить, были включены в договор или ТЗ на работы в приложении к нему, иначе у вас юридически не будет оснований отказать в приёмке результатов и заставить разработчика доработать результат. Убедитесь, что по договору у вас есть достаточно времени на проверку результата. Но даже если у вас его достаточно, ваши коллеги-заказчики не дадут вам долго проверять результат — он всё-таки нужен для задач бизнеса. В особенности проблемы могут возникнуть с маркетинговыми проектами, которые завязаны на какие-то даты, события, других людей и компании, — их часто могут начать делать ещё до заключения договора.
Немаловажно организовать безопасный обмен данными с контрагентами. Проанализируйте процессы взаимодействия с контрагентами. Есть ли у ваших сотрудников возможность пересылать конфиденциальную информацию любым контрагентам? Есть ли у контрагентов возможность пересылать вам информацию безопасно? Хватает ли этого канала передачи информации для всех проектов — нет ли процессов, где нужно передать несколько гигабайтов информации? Найдите и опишите способы передачи конфиденциальной информации, включите их в шаблоны договоров и/или NDA. Напишите инструкции для ваших сотрудников и разошлите им. Проинструктируйте их, что просто пересылка по почте — это не безопасно и что, если они не знают, как переслать информацию безопасно, им нужно обратиться в ИБ.
Что дальше?
Действия, которые я описала в статье, — это база, которая универсальна для всех компаний. Дальнейшее развитие будет зависеть от особенностей конкретной компании, количества контрагентов, связанных с обработкой информации, зависимости бизнеса компании от них, типов услуг и т. д.
Проще говоря, действия будут зависеть от рисков компании и риск-аппетита руководства — готовности принимать риски для того, чтобы реализовывать сотрудничество. То есть на этом этапе вам уже не обойтись без анализа рисков взаимодействия с контрагентами и принятия решений по их обработке.
Но я предложу несколько направлений, куда можно двигаться дальше:
По направлению «до договора» следующим логичным шагом будет получение влияния на то, с какими контрагентами компания может заключить договоры. То есть не только собирать информацию обо всех, с кем будет заключён договор, но и давать фидбэк, который будет учитываться при принятии решения по закупке.
Также можно ввести скоринг и/или детальный анализ рисков по конкретным контрагентам. Рекомендую внедрять эти активности только при возможности хотя бы частичной автоматизации или только в отношении отдельных типов контрагентов либо взаимодействий, а ещё до внедрения оценить, действительно ли ваш новый процесс будет влиять на принимаемые решения, иначе перегрузитесь, а фактического влияния на безопасность не получите.
Обеспечьте, чтобы пролонгация договоров с критичными контрагентами не проходила мимо вашего внимания, — чтобы не оказалось, что в 2026 году в договорах с постоянными поставщиками автоматически оставались формулировки из 2016 года.
Обратите внимание на внешнее ПО, которое использует ваша компания и ваши работники. Если ПО закупает компания, договоры на него должны попадать к вам по процессу согласования договоров. Но его может закупать не компания, а сотрудники сами за свои средства. Или оно может быть бесплатным или условно бесплатным, но иметь свои особенности и ограничения в лицензиях и соглашениях и влиять на безопасность вашей компании.
Внешнее ПО — это не только то, что можно установить на рабочую станцию или сервер, но и облачные системы и сервисы. Узнайте, какими внешними сервисами пользуются в вашей компании. Не забудьте о таких сервисах, как Госуслуги, банк-клиенты и социальные сети. Определите правила заведения и получения доступов к внешним кабинетам, чтобы эти кабинеты всегда были под контролем компании, а не личных учёток работников, а также правила отзыва этих доступов при увольнении.
Если вы чувствуете в себе силы, вы можете начать проводить аудиты ИБ критичных контрагентов.
Не только запрашивайте анкеты при первом контакте с контрагентом, но и актуализируйте анкеты действующих контрагентов.
Не забывайте обновлять регламент по безопасности контрагентов при всех нововведениях.
Если ваш бизнес не только в РФ, постройте аналогичные процессы и в других странах присутствия.
Отдельно стоит учитывать регуляторные требования: персональные данные, КИИ, отраслевые нормы и требования юрисдикций, в которых работает компания.
Что получается в итоге
Безопасность взаимодействия с контрагентами невозможно построить одной анкетой или одним пунктом в договоре. Это процесс, который постепенно охватывает весь жизненный цикл поставщика — от выбора и заключения договора до выдачи доступов, контроля работ, продления и завершения сотрудничества.
Если начинать с нуля, не стоит пытаться сразу построить идеальную систему. Лучше двигаться поэтапно.
Главное — не воспринимать контрагента только как строку в договорной системе. Любой внешний поставщик может стать частью вашей инфраструктуры, процесса или цепочки обработки данных. А значит, безопасность взаимодействия с ним должна быть управляемой, понятной и встроенной в нормальную работу компании.