Защита почти всегда выглядит крепче на схеме, чем под атакой. На диаграмме видны межсетевые экраны, двухфакторная аутентификация, VPN и политики доступа. Во время проверки всплывают старые панели администрирования, лишние права в домене, забытые API и сервисные учетные записи, которыми давно никто не управлял. пентест нужен как раз для такого столкновения с реальностью.
Тестирование на проникновение показывает не абстрактную уязвимость, а рабочий путь атаки. Команда пытается пройти к данным, деньгам, почте, домену или облаку так, как действовал бы внешний злоумышленник или человек, уже попавший внутрь сети после фишинга, заражения ноутбука или компрометации учетной записи подрядчика. После такой проверки разговор об ИБ перестает крутиться вокруг общих слов и переходит к маршрутам, срокам и исправлениям.
Для российского рынка тема давно перестала быть факультативной. Давление со стороны регуляторов выросло, а инфраструктура у многих компаний стала сложнее: гибридные контуры, срочные миграции, импортозамещение, новые подрядчики, публикация внешних сервисов и постоянные изменения доступа. Чем быстрее меняется инфраструктура, тем легче в ней остаются дыры.
Важно: пентест проводят только с письменного разрешения владельца ресурсов, в заранее согласованных границах, сроках и правилах остановки. Без такого допуска проверка превращается уже не в аудит, а в прямой правовой риск.
Что именно проверяет пентест и где заказчики чаще всего ошибаются
Главная ошибка начинается в тот момент, когда заказчик путает пентест со сканированием уязвимостей. Сканер полезен, сканер нужен, сканер быстро показывает подозрительные места. Только сканер почти никогда не отвечает на главный вопрос: сможет ли живой атакующий превратить найденные слабости в захват системы. Пентест как раз строится вокруг такой связки.
Одна ошибка в приложении может выглядеть умеренной. В цепочке с неправильной настройкой авторизации, лишними правами сервисной учетной записи и слабой сегментацией сети та же находка превращается уже в путь к базе клиентов, панели администратора или файловому хранилищу. По этой причине сильный отчет всегда показывает не просто перечень CVE, а маршрут атаки с шагами, достигнутыми правами и приоритетом исправлений.
Объект проверки бывает разным. Одной компании нужен внешний пентест для веба, API, VPN и почтовых сервисов. Другой компании важнее внутренняя сеть, Active Directory, доступ к критичным папкам, перемещение между сегментами и повышение привилегий. Третья компания проверяет мобильное приложение, серверную часть и облачную конфигурацию. Универсального шаблона здесь нет, поэтому хороший подрядчик сначала выясняет, что именно для бизнеса болезненнее всего.
Пентест обычно заказывают перед запуском нового внешнего сервиса, после миграции в облако, после объединения сетей, перед аттестацией, после инцидента или перед крупным пересмотром прав доступа. В такие периоды архитектура меняется быстрее обычного, а шанс пропустить старый хост, временную учетную запись или лишний маршрут до внутреннего ресурса заметно растет.
Среднему бизнесу такая проверка часто нужна не меньше, чем банку или оператору связи. У крупной структуры обычно есть отдельная ИБ-команда, мониторинг, процессы управления доступом и внутренние аудиты. У средней компании картина жестче: несколько критичных систем, один или два администратора, быстрые релизы и постоянная нехватка времени. В такой среде слабое место почти гарантированно найдется. Вопрос упирается только в то, кто доберется первым.
Как проходит работа и на какие методологии смотреть
Проект начинается не с инструментов, а с рамок. Заказчик и исполнитель фиксируют список систем, допустимые методы, окна для шумных проверок, контакты на случай аварии, стоп-факторы и перечень действий, которые запрещены. Без такого документа даже полезная проверка может закончиться аварией в продакшене или конфликтом по объему работ.
Следом выбирают формат. Внешний пентест моделирует действия нарушителя из интернета. Внутренний показывает, что произойдет после компрометации рабочей станции, подрядчика или сотрудника. По объему вводных используют режимы черного, серого и белого ящика. Черный ящик ближе к реальной атаке снаружи. Белый ящик дает больше глубины, потому что команда получает документацию, тестовые доступы и иногда исходный код. Серый ящик часто становится разумным компромиссом.
Дальше начинается ручной анализ. Команда собирает карту поверхности атаки, проверяет авторизацию, роли, загрузку файлов, бизнес-логику, API, облачные объекты, доменную инфраструктуру, маршруты повышения привилегий и доступ к данным. Работа выглядит не как киношный взлом, а как длинная серия аккуратных проверок, где каждую находку нужно подтвердить, воспроизвести и задокументировать.
Если подрядчик говорит о методологии, разговор сразу становится предметнее. Для веба и API полезно смотреть, опирается ли команда на OWASP Web Security Testing Guide. Для общей структуры работ и отчетности обычно всплывают NIST SP 800-115 и PTES. Заказчику не нужна религиозная война между аббревиатурами. Заказчику нужен понятный ответ: как формируют объем, как описывают сценарии атаки, как ранжируют риск и как проводят ретест после исправлений.
Сильный отчет состоит из двух частей. Техническая часть нужна инженерам и разработчикам: там фиксируют шаги атаки, уязвимые узлы, ошибки конфигурации и рекомендации по исправлению. Управленческая часть нужна руководству: там показывают достигнутые цели, влияние на бизнес и очередность работ. Без ретеста польза резко падает. Исправление, которое не перепроверили, слишком часто оказывается исправлением только в тикете.
| Инструмент | Что дает | Где ограничение |
|---|---|---|
| Сканирование уязвимостей | Быстро находит известные слабые места и ошибки конфигурации | Почти не показывает цепочки атаки и влияние на бизнес |
| Пентест | Показывает рабочий маршрут до критичных систем и данных | Требует четкого объема, времени и ручной работы |
| Bug bounty | Дает поток внешних находок и оплату за подтвержденный результат | Не заменяет внутренний пентест, контроль объема и формальную отчетность |
Кто проводит пентест в России и что важно по праву
Среди заметных игроков рынка можно назвать Positive Technologies, «Солар», BI.ZONE, Angara Security, «Информзащиту» и «Инфосистемы Джет».
Для выбора исполнителя громкий бренд значит меньше, чем совпадение опыта с нужным контуром. Одна команда сильнее в вебе и API, другая глубже копает внутреннюю инфраструктуру и домен, третья лучше чувствует банковский или промышленный сегмент. Заказчику полезно спрашивать не только про список клиентов, но и про типовые маршруты атак, формат отчетности, подход к ретесту и состав реальной команды, а не только отдела продаж.
Для российского права важна еще одна развилка. Если проект касается КИИ, госструктур, крупных массивов конфиденциальной информации или компаний, работающих под усиленными отраслевыми требованиями, подрядчика нельзя выбирать как обычного поставщика услуг. Здесь проверяют договорные рамки, режим доступа к данным, порядок хранения артефактов, правила допуска специалистов и профильные лицензии там, где такие лицензии действительно требуются.
Лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации для многих заказчиков остается базовым фильтром. Если проект затрагивает криптографические средства и работы из сферы лицензирования ФСБ, к отбору добавляют и требования по линии ФСБ. Универсальной волшебной лицензии для любого пентеста не существует, поэтому юридический блок всегда проверяют под конкретный контур, а не по общему списку из презентации подрядчика.
Отдельный разговор касается КИИ и организаций, живущих в зоне усиленного государственного внимания к ИБ. Для значимых объектов КИИ требования заметно жестче, а тема тестирования на проникновение уже давно не выглядит экзотикой. После Указа № 250 и дальнейшего ужесточения регулирования заказчики все чаще хотят видеть не красивую самооценку, а проверку, которая показывает, выдержит ли система живую атаку в пределах согласованного сценария.
Сколько стоит пентест, где работает bug bounty и что выбрать бизнесу
Честной фиксированной цены у пентеста нет. Бюджет считают от состава контура и глубины работ. На смету влияют количество внешних сервисов, число IP и хостов, количество веб-приложений и API, число ролей в системе, сложность авторизации, наличие исходного кода, объем внутренней сети, необходимость проверки подрядчиков или сотрудников, срочность проекта и обязательный ретест после исправлений.
По срокам разброс тоже большой. Небольшой веб-сервис иногда укладывается в несколько дней. Корпоративная сеть с доменом, филиалами, облаком и несколькими точками входа может занимать недели. Экономия чаще всего бьет по ручной части и по ретесту. После такого урезания заказчик получает толстый документ, но не получает ясного ответа, насколько контур выдержит реальную атаку.
Bug bounty в России уже нельзя считать редкой экзотикой. На крупных платформах идут десятки программ, а модель оплаты за подтвержденный результат выглядит для многих компаний привлекательной. Такой формат особенно полезен для внешних веб-сервисов, публичных приложений и постоянного поиска новых находок после релиза. Но bug bounty не закрывает все задачи классического пентеста. Публичная программа не заменит внутреннюю проверку домена, контролируемый сценарий атаки, формальный отчет для аудита и жестко заданный объем исследования.
Лучший выбор зависит от зрелости компании. Если бизнесу нужен ответ на вопрос, сможет ли атакующий пройти от внешнего периметра к данным или деньгам, начинают с нормального пентеста. Если внешний сервис уже зрелый, релизы идут постоянно, а команда умеет быстро принимать и чинить внешние находки, к пентесту добавляют bug bounty. Если защита только собирается по кускам, сначала наводят базовую гигиену, а уже потом платят за глубокую ручную проверку.
Хорошая статья про пентест заканчивается не советом срочно купить услугу, а более неприятной мыслью. Маршрут атаки почти всегда уже существует. Вопрос упирается в то, кто увидит такой маршрут первым: команда защиты в рамках согласованной проверки или злоумышленник в день, когда компании будет совсем не до экспериментов.
