Область пентеста: как определить scope, SOW и Rules of Engagement
Область пентеста — согласованные границы проверки, а не просто перечень IP-адресов. Она связывает бизнес-цель с активами, ролями, методами, временными окнами, ограничениями и ожидаемыми результатами. Письменная область тестирования должна быть согласована с действительной авторизацией и Rules of Engagement: без этого команда рискует проверить не те системы, выйти за полномочия или подготовить отчёт, который не отвечает вопросу заказчика.
Содержание
Ключевые выводы
| Пункт | Детали |
|---|---|
| Область тестирования (scope) | Перечень целей, сценариев, ограничений, допущений и результатов, согласованный до начала технических действий. |
| Модель доступа | Black box, grey box и white box описывают предоставленные знания и доступ, но не заменяют перечень целей и разрешений. |
| Авторизация и RoE | Письменное разрешение задаёт полномочия, а RoE — порядок, ограничения, контакты, условия остановки и обработку данных. |
| Веб-приложения и API | Нужно перечислить хосты, версии API, роли, интеграции, тестовые данные, среды и допустимые изменения состояния. |
| Оценка проекта | Срок и состав команды рассчитывают по площади поверхности, глубине, средам, ролям, ограничениям и формату отчёта. |
Из чего состоит область пентеста
Область тестирования описывает, что именно команда проверяет и при каких условиях. Удобно разделять её на цели, разрешённые методы и временные рамки, а также отдельно фиксировать роли доступа, данные, сторонние активы, логистику и требуемые результаты. Конкретная структура документа зависит от договора и процесса организации.
На стартовой встрече переводят бизнес-цель в проверяемый перечень активов и сценариев. Если область меняется, её не расширяют устно в ходе работ: сначала оценивают влияние на разрешение, риск, сроки и бюджет, затем выпускают согласованное изменение SOW или RoE.
Целевые активы определяют системы, сети, приложения и интерфейсы, которые разрешено тестировать. Укажите:
точные IP-адреса, диапазоны CIDR, домены и владельцев активов;
URL, версии API, мобильные клиенты, среды production/staging и связанные внешние службы;
явные исключения, особенно системы подрядчиков и общую инфраструктуру, на которую разрешение заказчика не распространяется;
сетевые устройства, сегменты, облачные ресурсы, регионы и идентификаторы аккаунтов;
тестовые учётные записи, роли, источники трафика и точки подключения команды.
Разрешённые методы определяют глубину проверки и допустимое влияние. Формулировка «полный пентест» недостаточна: эксплуатацию, повышение привилегий, перемещение по сети, доступ к данным, социальную инженерию, физические действия и тесты отказоустойчивости согласовывают отдельно.
эксплуатация уязвимостей и предел минимального доказательства влияния;
нагрузочные тесты и DoS — только при отдельном разрешении, лимитах, мониторинге и плане восстановления;
социальная инженерия — целевые группы, каналы, данные, уведомления HR и правила немедленной остановки;
физический доступ — площадки, помещения, пропуска, временные окна и запрещённые зоны;
повышение привилегий, lateral movement, persistence и работа с данными — только в явно разрешённых пределах.
Временные рамки задают часовой пояс, разрешённые окна, периоды запрета, срок действия разрешения и доступность контактов для эскалации. Дополнительно укажите, когда можно запускать активное сканирование и как поступать, если действие продолжается за пределами окна или система становится нестабильной.
Методологии пентеста помогают структурировать работу, но ни одна из них не заменяет конкретную область, авторизацию и правила взаимодействия для данного проекта.
Как black box, grey box и white box меняют исходные данные теста
Эти модели описывают объём информации и доступа, предоставленный тестировщику. Они влияют на глубину, скорость и распределение времени, но не определяют область автоматически: одинаковое приложение можно проверять в любой из моделей с разными целями и ограничениями.
В документации укажите не только название модели, но и конкретные исходные данные: учётные записи, роли, код, архитектуру, диапазоны адресов, тестовые данные и доступ к журналам.
| Модель | Знания тестировщика | Типичные исходные данные и область | Влияние на планирование | Практическая ценность |
|---|---|---|---|---|
| Black box | Минимум сведений сверх согласованных целей и точки входа | Внешняя поверхность в пределах перечисленных доменов, адресов и исключений | Больше времени на обнаружение, но срок зависит от размера и глубины | Показывает поверхность, доступную при заданной внешней позиции |
| Grey box | Часть контекста: тестовые роли, схема сети или ограниченная документация | Конкретные функции и роли плюс согласованная внешняя поверхность | Время распределяется между обнаружением и углублённой проверкой | Позволяет сочетать внешнюю перспективу с проверкой внутренних функций |
| White box | Код, архитектура, конфигурации, роли и необходимые журналы | Те же согласованные активы с доступом к внутренним доказательствам | Обычно повышает глубину за единицу времени, но не гарантирует короткий проект | Улучшает покрытие и анализ причин при защите переданных материалов |
Практические различия моделей:
Black box не означает неограниченную разведку. Команда получает минимум контекста, но всё равно работает по перечню разрешённых целей, источников трафика, методов и временных окон.
Grey box предоставляет отдельные роли или часть архитектуры. В scope нужно точно указать выданные аккаунты, разрешённые переходы между ролями и способ обращения с данными.
White box даёт код, конфигурации или полную документацию, но не превращает весь технологический стек в цель. Перечислите репозитории, ветки, компоненты, среды и границы анализа.
Специальное оборудование требуется по интерфейсу и сценарию, а не по названию black box, grey box или white box.
Авторизация, SOW и Rules of Engagement
Письменные границы — не формальность. До активных действий команда должна получить разрешение от стороны, которая вправе авторизовать тест каждого включённого актива, и убедиться, что условия облачного провайдера, подрядчиков и общей инфраструктуры не требуют отдельного согласования.
Отсутствие действительной авторизации создаёт риск несанкционированного доступа, нарушения договора, простоя и неправомерной обработки данных. Конкретную правовую квалификацию определяют применимое право и факты, поэтому статья не заменяет проверку договора и консультацию компетентной юридической службы.
SOW (Statement of Work) и RoE (Rules of Engagement) часто используются совместно, но их содержание и названия не стандартизированы для всех организаций. Важно, чтобы весь комплект документов однозначно охватывал следующее:
SOW обычно описывает объём и результат работ: цели, исключения, этапы, deliverables, сроки, допущения и порядок изменений. Технические границы могут находиться здесь или в приложении.
RoE обычно задаёт порядок выполнения: разрешённые и запрещённые действия, источники трафика, окна, контакты, условия остановки, правила доказательств и обращение с данными.
Не существует универсального правила, кто именно подписывает каждый документ. Организация должна проверить полномочия подписанта для всех активов и действий, согласовать договор, SOW, авторизацию и RoE без противоречий и передать команде актуальную утверждённую версию.
Практический совет: попросите письменное подтверждение полномочий авторизующей стороны и отдельно проверьте активы третьих лиц, облако, телекоммуникационные услуги и физические площадки. Должность в IT сама по себе не доказывает право разрешить все действия.
Контрольный порядок согласования области:
сопоставьте бизнес-цель с владельцами и точным перечнем включённых активов и исключений;
зафиксируйте разрешённые и запрещённые методы, предел доказательства и требования к безопасности;
укажите часовой пояс, окна, периоды запрета, источники трафика и доступность команды реагирования;
согласуйте условия остановки, немедленную эскалацию критических находок и восстановление;
утвердите комплект документов уполномоченными сторонами и ведите контролируемый процесс изменений.
Методология проведения пентеста помогает связать эти договорённости с этапами технической проверки и отчётностью.
Как определить область веб-приложения и API
Для приложения одного доменного имени недостаточно. Современная система включает API, роли, мобильный клиент, службы идентификации, хранилища, сторонние интеграции и фоновые процессы. Scope должен показывать, что именно включено и какие зависимости разрешено затрагивать.
Границы задают на уровне хостов, путей и версий API, ролей, функций и потоков данных. Отдельно согласуют аутентификацию, авторизацию, бизнес-логику, изменение состояния и взаимодействие между тестовыми аккаунтами.
Область веб-приложения или API обычно включает:
URL и эндпоинты API: домены, субдомены, пути, версии, GraphQL/WebSocket-интерфейсы, мобильные бэкенды и конкретные среды production или staging
Роли и идентичности: анонимный пользователь, несколько владельцев объектов, обычные и привилегированные роли, service accounts и границы между организациями или tenant'ами
Тестовые данные: предоставленные аккаунты, допустимые записи, запрещённые категории данных, очистка после теста и правила минимизации доказательств
Ограничения среды: допустимая нагрузка, отправка сообщений, платежи, фоновые задания, внешние интеграции, резервирование и порядок восстановления
Приоритетные сценарии: не только OWASP Top 10, но также авторизация, бизнес-логика, многоарендность, конфигурация и риски конкретного процесса
Одна роль не покрывает модель доступа. Для горизонтальной авторизации обычно нужны как минимум два тестовых пользователя одной роли, а для вертикальной — роли с разными полномочиями. Если административная панель или служебный API не вошли в область, это ограничение должно быть явно отражено в отчёте.
Практический совет: перечислите все пути аутентификации и восстановления доступа, включая MFA, SSO, OAuth/OIDC, API keys и машинные учётные записи. Для каждого определите роли, тестовые идентичности и допустимые изменения.
Руководство по тестированию веб-приложений и API должно дополнять scope выбранными идентификаторами проверок и явными исключениями, а не заменять его общей ссылкой на OWASP.
Как область влияет на оценку трудозатрат и сроков
Цена и график зависят не только от числа адресов. На оценку влияют технологии, роли, функции, глубина ручной проверки, количество сред, ограничения production, повторная проверка, формат доказательств и доступность команды заказчика. Поэтому универсальные сроки без инвентаризации вводят в заблуждение.
Более широкая или глубокая область обычно требует больше работы, но зависимость нелинейна. Один сложный поток авторизации может потребовать больше анализа, чем десятки однотипных IP-адресов.
| Тип заказа | Оценка после инвентаризации | Состав команды | Основные факторы оценки |
| Внешний тест (сеть) | Зависит от числа диапазонов, сервисов и окон | Один или несколько специалистов по технологиям | Площадь внешней поверхности, фильтрация, облако, ручная валидация |
| Тест веб-приложения | Зависит от функций, ролей, API и сред | Специалисты по приложению и нужным технологиям | Бизнес-логика, роли, интеграции, ручные сценарии, повторный тест |
| Внутренний тест (сеть) | Зависит от числа узлов, сегментов и уровня доступа | Состав по технологиям и требуемому покрытию | Сегментация, Active Directory, ограничения production, журналирование |
| Команда Red Team | Определяется целями, окнами и длительностью сценария | Междисциплинарная команда по согласованным векторам | Цели операции, OPSEC, инфраструктура, социальные сценарии, контроль риска |
| Полный пентест (веб + сеть + red team) | Оценивается как набор отдельных областей и зависимостей | Команда по требуемым специализациям | Координация областей, доказательства, отчётность и повторная проверка |
Дополнительные факторы трудозатрат:
Исключения: сложные границы и общая инфраструктура требуют дополнительных проверок цели перед каждым активным действием.
Готовность среды: staging может потребовать настройки, тестовых данных и проверки соответствия production; production требует более строгих ограничений и наблюдения.
Отчётность: глубина доказательств, несколько аудиторий, разбор результатов и повторный тест нужно оценивать отдельно; универсальной надбавки в процентах не существует.
Специализированные интерфейсы: Wi-Fi, USB/HID, Ethernet tap, RFID/NFC, SDR или физический доступ могут требовать оборудования, площадки и отдельного специалиста.
Планируйте ресурсы по измеримому перечню целей и результатов, а не по одному названию услуги.
Типичные ошибки при согласовании границ
Главная проблема scope — перевод общих ожиданий в технически однозначные и разрешённые действия. Фразы «проверьте всё» или «полный аудит» не определяют активы, глубину, данные, влияние и критерий завершения.
Расхождение между ожиданиями и результатом часто возникает из-за неполной области или противоречивых RoE. Это проверяют совместным walkthrough до старта: каждая бизнес-цель должна иметь актив, сценарий, метод, ограничение и ожидаемый результат.
Заказчик формулирует цель языком бизнеса, а команда переводит её в хосты, роли, потоки и проверки. Важно подтвердить этот перевод с владельцами процессов: термин «вся система» может скрывать внешнего провайдера, физическую площадку или приложение, которое техническая команда не считает своим.
RoE должны содержать условия остановки и немедленной эскалации: нестабильность системы, доступ к неожиданным данным, критическая находка, выход за область или отсутствие ответственного контакта. Для каждого условия укажите действие команды и лицо, принимающее решение о продолжении.
Владельцы бизнес-процессов помогают определить критичные функции, допустимые последствия и окна. Их участие не заменяет техническую инвентаризацию, а дополняет её; неподтверждённые проценты выручки или критичности не следует переносить в scope как факт.
Практический совет: проведите сессию scope с владельцем бизнеса, владельцами активов, безопасностью, операциями и при необходимости юридической службой. Завершите её таблицей «цель — актив — сценарий — разрешение — результат».
Шаблоны SOW и RoE полезны как контрольный список, но их нужно адаптировать. После утверждения применяйте версионирование, единый канал изменений и короткий бриф всей команды перед техническими действиями.
Когда в области требуется специальное оборудование
Оборудование выбирают после определения интерфейса и доказательства. Большинство веб- и API-проверок выполняется программными средствами; отдельные устройства нужны для USB/HID, беспроводной связи, Ethernet inline, SDR или физического доступа. Само наличие устройства не расширяет разрешённую область.
Bash Bunny Hak5 подходит для согласованных сценариев USB/HID и Ethernet ECM/RNDIS на контролируемых конечных точках. Packet Squirrel Mark II — двухпортовое inline-устройство для разрешённого захвата, анализа и изменения сетевого трафика. Инструменты для пентеста веб-приложений выбирают по конкретным интерфейсам и методике; ни один набор автоматически не обеспечивает «полное покрытие OWASP». SAPSAN доставляет оборудование в страны ЕС и США.
Часто задаваемые вопросы
Что такое область пентеста?
Это согласованное описание целей, активов, ролей, методов, ограничений, временных окон и результатов проверки. Scope должен соответствовать письменной авторизации и RoE.
Почему область нужно определять точно?
Точные границы помогают направить работу на бизнес-цель, избежать непроверенных ожиданий, контролировать влияние и не выходить за предоставленные полномочия.
Как black box, grey box и white box влияют на scope?
Они задают исходные знания и доступ тестировщика. Black box даёт минимум контекста, grey box — часть ролей или документации, white box — код и архитектуру. Во всех моделях цели и разрешённые действия перечисляют отдельно.
Что включить в область веб-приложения или API?
Укажите хосты, пути и версии API, роли и тестовые идентичности, среды, интеграции, данные, допустимые изменения состояния, лимиты нагрузки и приоритетные сценарии бизнес-логики и авторизации.
Как scope влияет на цену и срок?
Оценка зависит от площади поверхности, технологий, числа ролей и сред, глубины ручной проверки, ограничений, доказательств, отчётности и повторного теста. Универсальные сроки по одному типу услуги недостоверны.