Договор на оказание услуг пентеста: границы, правила работы и приёмка

Договор оказания услуг пентеста должен ещё до первого тестового запроса отвечать на практический вопрос: кто вправе выполнять какие именно действия, с какой версией какого актива, в какое время и какие доказательства будут означать, что работа выполнена? Одного рамочного договора для этого обычно недостаточно. Рабочий пакет закупки объединяет юридические условия, техническое задание или Statement of Work (SOW), письменную авторизацию и оперативные правила проведения тестирования — Rules of Engagement (ROE).

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

Подписывайте комплект документов, а не расплывчатую заявку

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

ROE нужно подписать или прямо включить в договор до начала тестирования. В нём указывают организацию, выдающую письменное разрешение, команду исполнителя, ответственных лиц, включённые и исключённые системы, источники тестового трафика, даты и часы, разрешённые и запрещённые действия, меры защиты рабочей среды, порядок остановки и возобновления, обращение с доказательствами и отчётность. Приложение B к NIST SP 800-115 (2008) даёт контрольный список для ROE. Его нужно адаптировать к проекту и актуальным правилам платформы: это не исчерпывающий современный перечень технических тестов.

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

Зафиксируйте границы и объём работ: актив, среда, версия и учётная запись

Одного доменного имени недостаточно. Для каждого актива укажите владельца, среду, устойчивый идентификатор, сетевую границу, версию приложения или API, релевантный номер сборки или коммита, клиентскую организацию (тенант) либо облачный аккаунт/проект, при необходимости регион и роли учётных записей, выданных для теста. Добавьте IP-адреса источников или другие признаки, по которым защитники отличат разрешённый трафик. Зафиксируйте зависимости, которые могут получить запросы, даже если они не являются прямыми целями.

Границы работ должны определять модель теста — без внутренней информации, с частичным знанием системы или с полным доступом; доступность исходного кода и архитектуры; пользовательские роли и тенанты; разрешение на социальную инженерию, подбор паролей, закрепление, загрузку файлов, изменение данных, боковое перемещение и разрушительные техники. Явный список исключений столь же важен, как список включений. Фраза «вся инфраструктура компании» опасна, когда используются сторонние SaaS, общий хостинг, управляемые сервисы, API партнёров или системы другой компании группы.

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

Планировщик области Pentest.red поможет превратить первичный перечень в документ для обсуждения, но владельцы и одобрение всё равно должны быть указаны явно. Если заказчик ещё выбирает исполнителя, используйте отдельное сравнение подрядчиков по проверяемым признакам, а не пытайтесь поместить критерии выбора в ROE.

Отдельно проверьте разрешения облака и третьих лиц

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

Актуальные правила крупных провайдеров показывают, почему формулировка «тестирование облака разрешено» не работает. В рамках стандартной политики пентеста AWS допускает оценку без предварительного согласования только для перечисленных клиентских сервисов, запрещает тестировать инфраструктуру и сервисы AWS как таковые, требует предварительного разрешения для тестов с Command and Control и запрещает DoS; симуляции регулируются отдельными правилами провайдера. Microsoft разрешает тестировать принадлежащие заказчику ресурсы Azure без предварительного согласования, но сторонний тестировщик должен получить явное письменное разрешение владельца, а работа подчиняется ROE Microsoft; при переходе к уязвимости самого сервиса Microsoft или чужим данным тест нужно остановить. Google Cloud не требует уведомлять о тесте собственного проекта, но обязывает соблюдать Acceptable Use Policy и Terms of Service и не затрагивать проекты или приложения других клиентов.

Эти различия могут меняться. В SOW лучше предусмотреть проверку правил с датой непосредственно перед стартом, а не копировать нынешний список сервисов в многолетний договор. Для SaaS, управляемого сервиса, реселлера, партнёрской интеграции или инфраструктуры другой компании группы получите разрешение соответствующего владельца либо исключите цель. Зафиксируйте, кто подаёт уведомления провайдеру и кто хранит ответ.

Для продакшена нужен настоящий путь остановки и возобновления

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

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

1. ПодписьОформите договор, SOW, разрешение владельца и ROE; проверьте ограничения третьих лиц и платформ.
2. Фиксация областиЗапишите активы, версии, роли, исключения, источники, методы, окно и контакты.
3. РаботаНаблюдайте за продакшеном, сохраняйте быстрый путь остановки и явно утверждайте изменения или рестарт.
4. ПриёмкаПроверьте покрытие, доказательства, ограничения и качество результатов без подсчёта уязвимостей.
5. РетестПроверьте согласованные находки на именованной исправленной сборке и выдайте вывод с явно указанными условиями проверки.

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

Контролируйте доказательства от сбора до удаления

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

Запросите реестр доказательств, связывающий каждую находку с активом и условиями теста без лишнего чувствительного содержимого. Решите, являются ли результатами сырые выгрузки инструментов, скриншоты, proof-of-concept, пары запрос/ответ, логи и тестовые аккаунты или остаются рабочими материалами исполнителя. Если используются субподрядчики или внешние системы совместной работы, отразите эти маршруты в юридических условиях и правилах данных. При закрытии отзовите доступы, удалите тестовые аккаунты и файлы, очистите артефакты у заказчика и получите согласованное подтверждение уничтожения.

Передавайте отчёт по контролируемому каналу, а не обычным вложением к письму. Заказчик назначает получателей и владельца эталонной копии. До финализации SOW полезно посмотреть пример отчёта о пентесте и руководство о том, что содержит полезный отчёт.

Принимайте качество и покрытие, а не количество уязвимостей

Количество находок — плохой критерий приёмки. Сильный тест может обоснованно дать мало находок; слабый способен раздуть счёт дублями и информационным шумом. Не связывайте оплату с минимальной квотой уязвимостей, обещанной критической проблемой или «чистым» результатом. Приёмка оценивает, выполнена ли согласованная работа и получены ли пригодные, прослеживаемые доказательства. Отчёт без находок тоже может соответствовать этим критериям, но не доказывает отсутствия уязвимостей.

Определите срок проверки и единый цикл консолидированных комментариев. Критерии могут требовать: правильные активы и зафиксированные версии; запись покрытия со статусами «проверено», «не применимо», «заблокировано», «не проверено»; даты и исполнители; методы и существенные ограничения; управленческое резюме; дедуплицированные находки с активом, предусловиями, доказательством, влиянием, обоснованием критичности, воспроизведением и рекомендациями; записи срочных уведомлений; статус передачи и удаления артефактов. Руководство OWASP по отчётности поддерживает разделение управленческого резюме, параметров и ограничений теста, находок и деталей устранения.

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

Определите ретест с оговорёнными условиями

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

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

Пример закупки: Northstar Tickets

Следующий сценарий полностью вымышлен и приведён только как иллюстрация. Northstar Tickets закупает тест перед релизом. В пакет входят действующий рамочный договор и условия обработки данных, SOW проекта, письменное разрешение владельца названных ресурсов и приложенный ROE. В объём работ включены рабочая среда portal.example.invalid релиза 2026.10-rc3, рабочая среда api.example.invalid со схемой API 3.14.2 и кандидат Android в тестовой среде, определённый именем пакета и хэшем сборки. Реестр также содержит два тестовых тенанта, выданные заказчиком роли клиента и поддержки, адреса исполнителя и конкретные аккаунты AWS с ресурсами приложения. Корпоративный сайт, платёжный провайдер, SaaS поддержки, инфраструктура сервисов AWS, фишинг сотрудников, DoS и все остальные тенанты исключены.

Разрешены ручные проверки веб-приложения и API, ограниченное автоматическое обнаружение с согласованной частотой, проверка разграничения доступа между ролями, загрузка файлов, неразрушительное доказательство влияния, а также ручная проверка локального хранилища, глубоких ссылок и взаимодействия указанной сборки Android с включённым в объём API. Запрещены закрепление, извлечение реальных клиентских записей, массовая проверка часто используемых паролей, изменение данных реальных клиентов в рабочей среде, боковое перемещение за пределы указанных аккаунтов приложения и нарушение доступности. Загрузку файлов проверяют только на искусственных данных внутри двух разрешённых тестовых тенантов; порядок очистки согласуют заранее. Руководитель инцидента заказчика и ведущий тестировщик могут немедленно остановить работу; возобновить её письменно может только руководитель инцидента или его представитель после заполнения записи о возобновлении.

На старте продуктовая команда предлагает добавить beta-api.example.invalid. Его нет в письменном разрешении, и он развёрнут отдельно. Исполнитель не делает «быструю проверку», а заказчик создаёт запрос на изменение с владельцем, сборкой, классификацией данных, границей AWS, методами, лимитом запросов, дополнительными трудозатратами и новым графиком. Тест начинается только после обновления области и ROE уполномоченным лицом.

Результаты: реестр области и покрытия, срочные уведомления о существенных находках, черновик, встреча по результатам, финальный отчёт, реестр доказательств и одна записка о ретесте. В этом примере Northstar получает пять рабочих дней для консолидированных комментариев. Отчёт принимается, если активы и версии верны, заблокированные и непроверенные части видны, каждую находку можно воспроизвести по маскированному доказательству, критичность обоснована, а файлы пригодны. Минимального количества находок нет. Пробелы в документации исправляются; спор о влиянии фиксируется отдельно и не блокирует весь результат.

Один ретест можно заказать в течение тридцати календарных дней после финального отчёта при наличии идентификаторов развёрнутых исправленных сборок и рабочих аккаунтов. Он охватывает находки отчёта и согласованные варианты через тот же механизм контроля. Новый мобильный релиз или несвязанная конечная точка API требуют изменения. Записка называет точную сборку и условия и не превращает узкую проверку в гарантию отсутствия других уязвимостей.

Обсудите приёмку до предоставления доступа

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

Pentest.red может обсудить предлагаемую область и услугу тестирования на проникновение, если независимая проверка соответствует задаче заказчика. До планирования письменно согласуйте активы, версии, операционные границы, результаты, приёмку и условия ретеста. Итогом должен быть управляемый проект и полезные доказательства, а не обещание, что конечный тест обнаружит все возможные уязвимости.