Как подготовиться
к тесту на проникновение
Всё, что определяется до первого дня, — охват, доступы, правила, контакты — и почему каждый пропущенный пункт стоит оплаченного дня проверки.
Пентест оплачивается днями специалиста. Сколько из этих дней уйдёт в саму проверку, а сколько на ожидание доступа, уточнение охвата и поиск того, кто может что-то согласовать, — решается до старта. Это руководство проходит по тому, что нужно подготовить, в порядке значимости.
1. Определите цель, а не только охват
Проверка, заказанная «чтобы был отчёт», и проверка, заказанная «чтобы узнать, может ли кто-то добраться до данных клиентов», выглядят по-разному с первого дня. Сформулируйте цель одним предложением: соответствие конкретной системе, валидация релиза, ответ на требование клиента или измерение способности обнаружения. Исполнитель строит план вокруг этого предложения.
2. Определите охват письменно и полностью
- Список доменов, поддоменов и IP-адресов, включённых — и явно исключённых.
- Приложения и API в охвате, с версией и средой, где они работают.
- Кому принадлежит каждая система: если хостинг у стороннего провайдера, нужно его согласие.
- Интегрированные сторонние системы — платёжные провайдеры, сервисы идентификации, — которые нельзя проверять без их согласия.
3. Выберите среду: продакшн или копия
Проверка в продакшне даёт реальные результаты, но требует мер предосторожности и согласованного окна. Предпродакшн-копия снимает риск при условии идентичной конфигурации — иначе вы проверяете несуществующую систему. Выбрав копию, проверьте три вещи: те же версии, те же правила межсетевого экрана, та же конфигурация аутентификации.
Данные важны не меньше: тестовая среда с тремя записями не позволяет проверить авторизацию между клиентами. Подготовьте реалистичный обезличенный набор данных.
4. Подготовьте учётные записи и доступ
- По две учётные записи на каждую роль — авторизацию между пользователями одного уровня можно проверить только двумя учётками.
- Учётные записи, которые не истекают и не блокируются после нескольких неудачных попыток.
- Многофакторная аутентификация решена заранее — иначе первый день уйдёт на SMS-коды.
- VPN-доступ или разрешённые адреса в межсетевом экране, если проверка внутренняя.
- Документация: схема архитектуры, спецификация API, список ролей. Не обязательно красиво — обязательно точно.
5. Зафиксируйте правила взаимодействия
Правила взаимодействия — документ, описывающий, что тестировщику можно и что нельзя. Это не формальность: без него законное действие проверки может запустить процедуру инцидента или, хуже, создать договорную проблему с хостинг-провайдером.
| Пункт | Что согласуется | Почему это важно |
|---|---|---|
| Окно проверки | Дни и часы, когда можно проверять | Исключает влияние на пользователей в пик нагрузки |
| Исключённые техники | Обычно DoS, удаление данных, атаки на сотрудников вне рабочего времени | Защищает непрерывность и людей |
| Критерии остановки | Что вызывает немедленную остановку и кто решает | Реальный инцидент во время проверки нужно отличить от неё |
| Немедленное уведомление | Какой уровень сообщается сразу, а не в итоговом отчёте | Критичная уязвимость не ждёт две недели |
| Адреса тестировщиков | IP-адреса, с которых идёт трафик проверки | Позволяет команде отделить проверку от реальной атаки |
| Обращение с данными | Какие данные можно извлекать, как хранятся, когда удаляются | Обязанность по GDPR, а не опция |
6. Назначьте людей
Нужны три роли с именами и телефонами: технический контакт, способный разблокировать доступ в тот же день; принимающий решения, который может согласовать расширение охвата или остановку; и аварийный контакт, доступный вне рабочих часов. Решите также, уведомляется ли операционная команда — если нет, проверка измеряет и обнаружение, но кто-то в руководстве должен знать.
Чек-лист коротко
- Цель проверки, записанная одним предложением.
- Полный охват с явными исключениями и согласием хостинг-провайдеров.
- Среда выбрана и подтверждена идентичной продакшну, с реалистичными данными.
- По две учётки на роль, без истечения, с решённой MFA.
- Документация архитектуры и спецификация API, отправленные до старта.
- Подписанные правила взаимодействия, с критериями остановки и IP тестировщиков.
- Три названных контакта с доступностью вне рабочих часов.
- Окно устранения и дата повторной проверки, согласованные заранее.
Частые вопросы
Сколько занимает подготовка к пентесту?
Обычно от одной до трёх недель от подписания до первого дня, и большая часть уходит на создание учётных записей и получение согласий внешних хостинг-провайдеров. Если охват уже описан, учётки готовы, а правила согласованы, начать можно за несколько дней.
Нужно ли сообщать внутренней команде о проверке?
Зависит от цели. Если вы хотите измерить и способность обнаружения и реагирования, операционную команду не уведомляют — иначе результат ничего не скажет о реакции на настоящую атаку. Если цель строго в поиске уязвимостей, уведомление экономит время и избавляет от ложных тревог. В обоих случаях хотя бы один человек в руководстве и аварийный контакт должны знать.
Проверка идёт на продакшне или в тестовой среде?
Оба варианта допустимы с разными компромиссами. Продакшн даёт реальные результаты, но требует согласованного окна и мер предосторожности. Предпродакшн снимает операционный риск, но только если идентичен продакшну по версиям, конфигурации межсетевого экрана и механизмам аутентификации — иначе вы проверяете несуществующую систему. Данные важны не меньше: среда с тремя записями не позволяет проверить авторизацию между клиентами.
Зачем тестировщику по две учётные записи на роль?
Чтобы проверить авторизацию между пользователями одного уровня — класс дефектов, где один клиент может просмотреть или изменить данные другого, поменяв идентификатор в запросе. Это одна из самых частых и дорогих проблем в реальных приложениях, и её нельзя проверить одной учёткой, сколько бы времени у тестировщика ни было.
Что происходит после сдачи отчёта?
Дальше три этапа, которые стоит запланировать заранее: разбор, где техническая команда может напрямую задать вопросы тестировщикам; окно устранения, под которое вы уже зарезервировали ресурсы разработки; и повторная проверка, письменно подтверждающая закрытие. Без последнего этапа досье соответствия остаётся неполным, а устранение — утверждением.
Связанные руководства
- Сколько стоит пентест — что определяет цену, как оценивается трудоёмкость и что делает предложения сопоставимыми.
- DORA и TLPT — цифровая операционная устойчивость в финансах и тестирование на основе угроз.
- ISO 27001 и SOC 2 — какие меры требуют технической проверки и какие доказательства принимает аудитор.
- Закон 48/2023 (Молдова) — национальная система кибербезопасности: на кого распространяется и какие обязанности вводит.
- OWASP Top 10 — десять категорий веб-рисков с примерами и тем, что проверяется в каждой.
- PCI DSS 4.0 — требования 11.3 и 11.4, проверка сегментации и что это значит для платёжных провайдеров.
- Пентест против сканирования уязвимостей — что находит каждый, что упускает и что аудиторы принимают как доказательство.
Материал носит информационный характер. Конкретные требования к подготовке зависят от типа проверки и среды организации.
Готовы начать?
Запишитесь на бесплатную консультацию: пройдём чек-лист вместе и зафиксируем охват, правила и график.