Проверка контрагента по открытым данным перед договором: сертификаты, утечки, технические признаки
Контрагент получает доступ к вашим данным или системам, и вы становитесь настолько защищены, насколько защищён он. История подрядчика с утечками в прошлом, просроченный сертификат на сайте, отсутствие защиты почтового домена — всё это видно заранее и без запроса к самому контрагенту. Анкета, которую он заполнит, показывает, что он готов сообщить; открытые данные показывают, что есть на самом деле. Ниже какие источники проверять до подписания договора, как провести пассивную техническую проверку скриптом, как сравнить результаты и какие договоры требуют обязательного согласования с ИБ.
Структурированная оценка поставщиков и анкеты: оценка рисков поставщиков, анкеты TPRM. Договор на обработку ПДн: поручение обработки. Обязательство о неразглашении: NDA.
Порядок проверки
Открытая проверка стоит первой: она занимает час и сразу отсекает слабых или ненадёжных контрагентов, для которых не стоит тратить время на анкеты. Анкета нужна тем, кто прошёл предварительный отбор. Результат фиксируется в заключении, а условия безопасности попадают в договор.
Какие договоры согласуются с ИБ
Не каждая закупка требует проверки. Составьте перечень, где подпись ИБ обязательна, и закрепите его в регламенте взаимодействия с третьими сторонами:
| Тип договора | Почему согласует ИБ |
|---|---|
| Контрагент получает персональные данные или иные данные высокого класса | Нужны поручение обработки, требования защиты, оценка |
| Контрагент получает доступ к вашим системам, сетям, учётным записям | Внешний доступ: шлюз для подрядчиков |
| Облачный сервис или SaaS, куда загружаются данные компании | Размещение данных за периметром: ПДн в облаке |
| Разработка программного обеспечения и интеграции | Код и зависимости попадают в вашу среду |
| Соглашения о неразглашении и о конфиденциальности | Содержание и срок обязательств |
| Хостинг, связь, колокейшн | Физический доступ и доступность |
Для остальных закупок (канцелярия, питание) подпись ИБ не нужна, и это правило тоже полезно: оно не загружает ИБ. Перечень пересматривается раз в год.
Шаг 1. Открытые источники
| Что проверяем | Где | Что считать тревожным |
|---|---|---|
| Существование и возраст юридического лица | Открытые государственные реестры (ЕГРЮЛ на сайте ФНС) | Компания создана недавно, массовый адрес регистрации, смена руководителя перед сделкой |
| Лицензии на деятельность в области защиты информации (если контрагент заявляет такие услуги) | Реестры лицензий регуляторов (ФСТЭК России, ФСБ России) | Лицензия заявлена, но в реестре отсутствует или приостановлена |
| Сертификаты (ISO/IEC 27001 и др.) | Реестр органа по сертификации; проверка номера сертификата на сайте выдавшей организации | Сертификат не находится у органа, истёк срок, область сертификации не охватывает вашу услугу |
| Инциденты и утечки | Новости и отраслевые сообщения, бюллетени, публичные списки утечек | Утечка по вине контрагента за последние годы без публичных выводов |
| Судебные дела и исполнительные производства | Открытые базы судебных дел и ФССП | Серия споров с клиентами о данных или невыполнении обязательств |
| Следы внутренних данных в открытом доступе | Поиск по домену в открытых источниках и публичных репозиториях кода | Секреты, пароли, внутренняя документация в публичных репозиториях |
Пользуйтесь только законными источниками и условиями сервисов: данные, украденные из чужих систем, не используются даже для «проверки». Достаточно публичной информации, и её обычно хватает. Если на вопрос о сертификате контрагент присылает только скан без номера, это само по себе информация.
Шаг 2. Пассивная техническая проверка
Часть признаков защищённости видна снаружи без каких-либо действий против контрагента: записи защиты почтового домена, настройки сертификата сайта, заголовки безопасности. Скрипт ниже делает только обычные запросы к открытым записям DNS и главному сайту, как любой посетитель, и ничего не сканирует.
#!/usr/bin/env bash
# vendor_posture.sh: пассивная проверка открытых признаков защищённости контрагента
# Использование: vendor_posture.sh example.com
d="$1"
echo "== Почтовый домен"
echo -n "MX: "; dig +short MX "$d" | tr '\n' ' '; echo
echo -n "SPF: "; dig +short TXT "$d" | grep -i 'v=spf1' || echo "нет записи SPF"
echo -n "DMARC: "; dig +short TXT "_dmarc.$d" | grep -i 'v=DMARC1' || echo "нет записи DMARC"
echo -n "CAA: "; dig +short CAA "$d" || true
echo "== Сертификат сайта"
echo | openssl s_client -connect "$d:443" -servername "$d" 2>/dev/null | openssl x509 -noout -issuer -subject -enddate
echo "== Заголовки безопасности"
curl -sI --max-time 10 "https://$d" | grep -iE 'strict-transport-security|content-security-policy|x-content-type-options|x-frame-options' || echo "основные заголовки не найдены"
echo "== security.txt (контакт для сообщений об уязвимостях)"
curl -s -o /dev/null -w '%{http_code}\n' --max-time 10 "https://$d/.well-known/security.txt"Ожидаемо: у серьёзного контрагента есть записи SPF и DMARC (желательно с политикой не none), действующий сертификат не от сомнительного удостоверяющего центра с запасом срока, часть заголовков безопасности и, возможно, файл security.txt (код 200). Отсутствие чего-то одного — не приговор, а повод спросить. Отсутствие всего вместе у компании, которая заявляет о защите данных, — тревожный сигнал. Не используйте для проверки активное сканирование портов и поиск уязвимостей: это уже вмешательство, на которое нужно разрешение. Что значат записи: SPF, DKIM, DMARC, dig по DNS и почте.
Шаг 3. Оценка по баллам
Чтобы решение не зависело от настроения, оцените результаты по простой шкале: 0 — тревожно, 1 — есть вопросы, 2 — в порядке.
| Критерий | 0 | 1 | 2 |
|---|---|---|---|
| Юридическое лицо и репутация | Есть серьёзные признаки риска | Мало данных | Давно работает, историю видно |
| Сертификаты и лицензии | Заявлены, но не подтверждены | Нет, но не заявлялись | Подтверждены, охватывают услугу |
| Инциденты и утечки | Утечка без выводов | Данных нет | Нет инцидентов или они разобраны публично |
| Защита почтового домена и сайта | Ничего не настроено | Часть | Настроено |
| Прозрачность при вопросах | Уклоняется от ответов | Отвечает частично | Отвечает по существу и документами |
Ориентиры решения: 8–10 баллов — переходить к анкете и договору, 5–7 — переходить с дополнительными условиями (запросить аудит, ограничить объём данных, срок), меньше 5 — не давать данных, пока ситуация не изменится. Для критичных данных порог выше. Числа условные: подберите под свои риски и держите одинаковыми для всех контрагентов.
Форма заключения
Заключение по контрагенту до заключения договора
Контрагент: ООО «Пример», ИНН ... Дата проверки: 20.10. Проверил: специалист ИБ.
Что передаётся: персональные данные клиентов (категория высокая); доступ к системам: нет.
Открытые источники: юридическое лицо с 2014 года; сертификат ISO 27001 подтверждён в реестре органа сертификации;
публичных инцидентов не найдено; в открытых репозиториях секретов не обнаружено.
Техническая проверка: SPF и DMARC настроены (политика quarantine); сертификат сайта действует до 03.2027; security.txt есть.
Оценка: 9 из 10.
Решение: допустить; в договор включить поручение обработки, требования по защите, право на аудит, срок уведомления об инциденте 24 часа.
Повторная проверка: при продлении договора или инциденте у контрагента. Подпись ИБ.Что вносится в договор
- Обязательства по защите данных и перечень мер (или ссылка на поручение обработки).
- Срок уведомления об инциденте, затрагивающем ваши данные: часы, а не недели.
- Право проверки (аудит) и предоставление подтверждающих документов.
- Порядок возврата и уничтожения данных по окончании договора с подтверждением.
- Запрет передачи данных субподрядчикам без согласия и перечень разрешённых.
- Ответственность за нарушения и обязанность содействовать при проверках регулятора.
Повторные проверки
Проверка при подписании — снимок на один день. Контрагент меняется: сертификат истекает, появляются инциденты. Поэтому ключевых контрагентов проверяйте при продлении договора (не реже раза в год) и сразу после сообщения о его инциденте. Для этого достаточно повторного прогона скрипта и просмотра открытых источников. Результат дописывается в то же заключение с датой.
Какие артефакты хранить
| Что хранить | Что показывает |
|---|---|
| Регламент взаимодействия с третьими сторонами и перечень договоров, требующих согласования с ИБ | Правила работы с контрагентами определены |
| Заключения по результатам проверки контрагентов с датами | Проверка выполняется до начала взаимодействия |
| Вывод скрипта и результаты поиска по открытым источникам для каждого заключения | Анализ публичных данных проведён |
| Подписанные договоры с требованиями по ИБ | Условия безопасности закреплены |
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Договор подписан до проверки | Нет обязательного согласования. Закрепите в регламенте: платёж и доступ не открываются без заключения ИБ |
| Все контрагенты получают 10 баллов | Критерии слишком мягкие или оценка формальная. Опишите, что значит каждое значение, и проверяйте выборочно |
| Скрипт ничего не находит у крупной компании | Домен контрагента отличается от домена сайта или защита вынесена на сторонний сервис. Уточните домен и проверьте для почтового домена отдельно |
| ИБ не успевает проверять всех | Перечень слишком широкий. Оставьте контрагентов с данными и доступом к системам |
| Контрагент отказывается отвечать на вопросы | Это сигнал. Ограничьте объём данных или выберите другого |
Где это в модели зрелости
Материал относится к направлению «Безопасность данных» (хаб: безопасность данных, карта: карта зрелости). На третьем уровне правила взаимодействия с третьими сторонами регламентированы, определены категории договоров, требующих согласования с ИБ, и перечень обязательных проверок безопасности контрагентов; перед началом взаимодействия анализируются публичные данные о кибербезопасности контрагента: утечки, сертификации, репутация. Заключения, перечень договоров и отчёты проверки — подтверждения.
Как проверить
- Есть перечень договоров, требующих согласования с ИБ, утверждённый и известный закупкам.
- Для трёх последних контрагентов с данными есть заключения, датированные до даты договора.
- В заключениях видны результаты открытых источников и вывод скрипта.
- В договорах присутствуют требования по защите данных, срок уведомления и право проверки.
- Для действующего ключевого контрагента есть повторная проверка за последний год.
Источники
- CIS Control 15, управление поставщиками услуг: cisecurity.org/controls.
- NIST SP 800-161 Rev. 1, управление рисками цепочки поставок: csrc.nist.gov. Не закон РФ.
- ISO/IEC 27001, сведения о сертификации: iso.org.
