Легально и правильно проверяем на кибер‑прочность партнеров по бизнесу

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

Именно здесь появляется слепая зона. Партнер может быть небольшим, работать быстро и стоить дешевле крупного поставщика, но если у него есть доступ к сайту, репозиторию, админке, CRM или файловому хранилищу, его инфраструктура становится частью вашей цепочки риска. В логике NIST такие риски относятся к cyber supply chain risk management — управлению угрозами, возникающими из‑за взаимосвязанности ИКТ‑продуктов, сервисов и поставщиков.

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

Чужие серверы и точка входа в вашу компанию

Бизнес часто воспринимает доступ подрядчика как техническую формальность. Три года назад в материале Forbes приводились данные, что 80% компаний применяют к подрядчикам и поставщикам такие же защитные меры, как к удаленным сотрудникам, но менее 10% оценивают уровень информационной безопасности поставщика, причем такая оценка часто остается формальной. В результате компания может строго проверять собственных сотрудников, но почти вслепую выдавать внешнему партнеру доступ к тем же системам.

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

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

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

В этом же отчете ENISA отдельно отмечено, что в 66% изученных инцидентов злоумышленники фокусировались на коде поставщика, а в 58% случаев целевыми активами клиентов становились данные, включая персональные данные и интеллектуальную собственность. Для бизнеса это означает, что слабый подрядчик может быть не просто «мелким техническим риском», а маршрутом к самым дорогим активам: клиентской базе, коммерческой тайне, исходному коду, финансовым документам и внутренним системам.

Как именно подрядчик превращается в точку входа

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

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

Третий маршрут — атака через поставляемое ПО или обновление. В кейсе SolarWinds злоумышленники скомпрометировали инфраструктуру разработки компании, тайно изменили код Orion и доставили вредоносный компонент клиентам через легитимное обновление. Зараженную версию загрузили около 18 000 пользователей, но дальнейшая активная компрометация, по оценке SolarWinds, затронула менее 100 сетей.

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

Пятый маршрут — облачные учетные записи. Даже самая современная облачная инфраструктура не отменяет базовые риски: слабые пароли, отсутствие MFA, плохой контроль токенов и неотозванные доступы.

Российский рынок уже сталкивался с атаками и утечками, где слабым местом становился не сам заказчик, а внешний участник его цифровой цепочки. В январе 2025 года «Ростелеком» сообщил, что возможная утечка данных могла произойти из инфраструктуры одного из подрядчиков, обслуживавших интернет‑ресурсы компании. По данным РБК, речь шла о ресурсах company.rt.ru и zakupki.rostelecom.ru, а сама компания заявляла, что ранее фиксировала инциденты ИБ у подрядчика, обслуживавшего эти ресурсы.

Другой российский пример — массовые атаки на сайты, использующие «1С‑Битрикс». В 2022 году РБК писал, что среди пострадавших от взломов сайтов были Росреестр, Совет по правам человека, Минстрой и сайты российских вузов; в «1С‑Битрикс» заявляли, что случаи взломов были связаны с отсутствием обновлений на стороне клиентов, а исправления уязвимостей уже были выпущены.

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

Этот вопрос нужно задавать не абстрактно, а применительно к конкретному доступу. Если подрядчик обслуживает лендинг без персональных данных, риск один. Если он имеет доступ к CRM, клиентской базе, платежной инфраструктуре, внутреннему Git, облаку или VPN, риск совсем другой. Один и тот же подрядчик может быть приемлемым для низкорисковой задачи и недопустимым для работы с критичными системами без дополнительных ограничений.

Легальная оценка партнеров через открытые данные

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

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

Есть и второй барьер — закон. Компания не может просто взять и начать активно проверять чужую инфраструктуру так, как проверяет свою. Статья 272 УК РФ предусматривает ответственность за неправомерный доступ к охраняемой законом компьютерной информации, если такое деяние повлекло уничтожение, блокирование, модификацию либо копирование компьютерной информации. Поэтому любые активные действия в чужой сети без согласованного разрешения — сканирование, попытки эксплуатации, подбор доступов, проверка внутренних сервисов — должны рассматриваться не как «инициатива службы безопасности», а как юридический риск.

Именно здесь появляется практичный компромисс: до подписания договора компания не пытается «взломать партнёра на проверку», а оценивает его внешнюю цифровую гигиену по открытым данным.

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

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

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

Что можно увидеть снаружи

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

Первый слой — доменная и почтовая гигиена. Публичные инструменты проверки домена позволяют анализировать SPF, DMARC, DKIM, SSL/TLS, DNSSEC и security headers. Отсутствие SPF, DKIM или DMARC не доказывает, что партнер взломан, но показывает риск подмены почты и фишинга от его имени.

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

Третий слой — базовая веб‑конфигурация. Внешние проверки могут показать наличие или отсутствие HSTS, CSP, X‑Frame‑Options и других security headers. Эти признаки не дают полной картины безопасности, но хорошо показывают, уделяет ли партнер внимание базовой защите публичных сервисов.

Четвертый слой — известные уязвимости и приоритизация риска. CISA KEV описывается как авторитетный перечень уязвимостей, которые уже эксплуатировались в реальных атаках. Если по открытым признакам видно, что партнер использует устаревший публичный продукт, а у него есть уязвимости из KEV, это сильный сигнал риска, хотя подтверждать такие выводы лучше через запрос к самому партнеру, а не через самостоятельную эксплуатацию.

Пятый слой — утечки и компрометация учётных записей. Have I Been Pwned позволяет проверять, попадал ли email или телефон в известные утечки, а доменный поиск HIBP требует подтверждения контроля над доменом. Это важная оговорка для легальности: заказчик может попросить партнера самостоятельно подтвердить домен и предоставить агрегированный результат, но не должен пытаться получать закрытые сведения о чужом домене в обход процедуры.

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

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

Хорошая практическая модель по цветам:

1. Зеленая зона: у партнера нет явных внешних проблем, базовая почтовая и доменная защита настроена, публичные сервисы выглядят аккуратно.
2. Желтая зона: есть отдельные недочеты, но они объяснимы и могут быть устранены до старта работ.
3. Красная зона: обнаружены признаки компрометации, заброшенная инфраструктура, критичные публичные ошибки, отсутствие базовой почтовой защиты или отказ партнера обсуждать вопросы безопасности.

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

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

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

Контролируем не партнера, а его права

Компания не обязана брать на себя безопасность всего подрядчика, но обязана защищать собственную территорию. Если партнер получает доступ к CMS, CRM, Git, облаку, VPN или файловому хранилищу, именно заказчик должен определить границы этого доступа. NIST рассматривает риски поставщиков, сервисов и технологий как часть взаимосвязанной цепочки, а значит, управление риском должно происходить не только «у поставщика», но и на стороне организации, которая его подключает.

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

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

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

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

Отдельное внимание нужно уделить паролям, токенам и VPN‑доступам. Их нельзя передавать через мессенджеры, хранить в письмах или использовать повторно для разных подрядчиков. После завершения работ доступы должны удаляться немедленно, а не «когда‑нибудь после закрытия проекта».

Что делать бизнесу

Первое правило. Доступ подрядчика должен выдаваться под конкретную задачу.

Второе правило. Каждый внешний аккаунт должен иметь срок жизни.

Третье правило. После завершения проекта доступ нужно закрывать так же обязательно, как подписывать акт выполненных работ.

Четвертое правило. Считать ущерб заранее. Если подрядчик дешевле конкурентов, но для работы ему нужен доступ к критичным данным, бизнес должен оценить не только экономию на договоре, но и возможную цену компрометации.

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

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

Заключение

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

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

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