Игорь, технический директор компании, которая торгует садовой техникой и запчастями к ней, открывает файл с названием «отчёт_пентест_финал.pdf». Файл весит больше, чем все документы по информационной безопасности, собранные за три года, и разворачивается на восьмидесяти страницах. Первые десять — графики и сводка, дальше список находок, почти каждая помечена как критическая. Игорь читает полчаса и понимает, что не знает, что делать в понедельник.

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

Теперь этот документ лежит перед ним. Примерно половина находок — про версии библиотек, и по формулировкам видно, что их нашла не человек, а программа: «возможно, уязвимая версия», «рекомендуется обновить». Вторая половина — про партнёрский портал и тестовый контур, которые Игорь не считал частью сайта. Кирилл, единственный разработчик, открывает первую «критическую» находку и пытается её повторить; через час открывает десятую — и тоже не может. К вечеру отчёт отправляется в папку для партнёра, а вопрос «мы защищены?» остаётся без ответа.

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

Зачем нужен пентест, если есть аудит и сканер

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

Разница не в инструментах, а в наличии цепочки. Сканер не строит переходов: он находит уязвимость и сообщает о ней, не зная, соединена ли она с чем-то ещё. Между тем реальная атака почти всегда состоит из шагов, каждый из которых по отдельности выглядит безобидно. Форма восстановления пароля позволяет угадать код, код открывает учётную запись, учётная запись даёт выгрузку заказов — и только на третьем шаге становится понятно, что первые два были дверью.

Из этого следует простой критерий подлинности. Если убрать из отчёта название подрядчика и подставить название сканера, а смысл не изменится — значит, вы купили сканирование с человеческим лицом. Звучит резко, но это самый быстрый способ понять, за что заплатили: пентест оставляет следы решений, а не только список совпадений.

Обратное тоже верно, и об этом забывают чаще. Пентест не заменяет аудит: он не проверит, есть ли приказ о доступах, обучают ли сотрудников и хранятся ли журналы достаточно долго. Он показывает, что можно сделать с системой сейчас. Гигиена и нападение — разные работы, и одна не вытекает из другой.

Здесь и возвращается история Игоря. Он просил «проверить сайт», а проверять можно только что-то конкретное. Вопрос звучит иначе: «Может ли человек, получивший доступ к одному личному кабинету, увидеть заказы другого?» На такой вопрос есть ответ «да» или «нет», его можно проверить и предъявить разработчику. Разница между этими формулировками и есть разница между пентестом и папкой с PDF.

Без письменного разрешения это не проверка, а преступление

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

Важно. Без письменного разрешения владельца системы тест на проникновение — не проверка, а неправомерный доступ. Разрешение на словах, «мы же свои» или «хотели как лучше» этого не меняют. Пока бумаги нет, единственный законный вариант — сначала её получить, а потом начинать.

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

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

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

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

Сколько подрядчику знать заранее

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

Это не уровни зрелости, которые нужно проходить по очереди. Каждый режим отвечает на свой вопрос, и выбирать его стоит по вопросу, а не по привычке. Чёрный ящик показывает, что сможет посторонний, у которого нет ничего: так проверяют внешний периметр и всё, что открыто в интернет. Белый ящик показывает, что сломано внутри, — так быстрее находят ошибки в логике, которые снаружи не видны. Серый ближе всего к реальности, потому что у настоящего атакующего почти всегда есть чей-то пароль: сотрудника, подрядчика, клиента.

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

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

Договор: как заранее договориться о результате

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

Практически это выглядит так. К договору прикладывается область работ с точным перечнем систем и учётных записей, правила игры из предыдущего раздела, режим проверки, требования к отчёту, обязательный разбор результатов и повторная проверка после исправлений. Туда же стоит добавить порядок обращения с найденными данными: подрядчик не уносит их к себе, фиксирует сам факт доступа и немедленно сообщает вам. Это не вежливость, а условие, без которого проверка превращается в утечку.

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

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

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

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

Как проверить саму проверку

Отчёт — единственное, что остаётся после проверки, поэтому именно по нему видно, была ли работа. Полезная находка отвечает на четыре вопроса: что именно обнаружено, как это повторить, чем это грозит бизнесу и что с этим делать. Если хотя бы одного ответа нет, находка не работает: её нельзя ни подтвердить, ни опровергнуть, ни поручить разработчику.

Самый важный из четырёх — воспроизведение. Шаги, запросы, учётные записи, скриншоты, время — всё, что позволяет другому человеку пройти тот же путь и увидеть тот же результат. Без этого разработчик оказывается в положении Игоря: он читает «критическая уязвимость доступа к данным заказа», пробует повторить, не может и закрывает пункт как неподтверждённый. Формально работа выполнена, фактически проблема осталась.

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

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

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

Дальше начинается повторная проверка, и здесь чаще всего заканчивается хорошая история. Исправление — это гипотеза, пока кто-то не проверил, что оно работает. Причём проверять нужно не только саму находку, но и класс проблемы: если закрыли доступ к конкретному заказу, а проверка прав на другие объекты осталась прежней, вы исправили симптом. Повторная проверка дешевле и быстрее полного теста, и её стоит заказывать сразу, а не вспоминать через полгода.

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

У Игоря всё это было в одном файле. И где-то в середине отчёта лежала настоящая находка: личный кабинет отдавал заказ по номеру, не проверяя, чей он. Описание занимало три строки, шагов не было.

Кирилл попробовал, не получилось — для проверки нужен был второй аккаунт и правильная последовательность, — и закрыл пункт как «не подтвердилось». Через два месяца клиент увидел в своём кабинете чужой адрес доставки. Отчёт был честным: находка в нём была. Полезным он не был, потому что утонул в шуме.

Главная мысль

Пентест — это не взлом ради отчёта. Это согласованная проверка гипотез: вы формулируете, что именно считаете защищённым, подрядчик пытается это опровергнуть, а границы и формат результата определяют, станет ли ответ доказательством. Без гипотезы проверять нечего, без границ проверка получается мелкой, без формата результата её нельзя ни принять, ни оспорить.

В истории Игоря подрядчик не был мошенником. Он сделал примерно то, о чём его попросили, а попросили ни о чём: три слова в письме и три страницы договора. Восемьдесят страниц оказались точным отражением заказа — много текста, ни одного вопроса. Второй раз компания начинала иначе: список гипотез, приложение с областью, окна и контакты, серый ящик для личного кабинета, формат отчёта с шагами воспроизведения, обязательный разбор и повторная проверка. Отчёт стал в несколько раз короче, и впервые из него можно было что-то починить.

Отсюда вывод, который касается не подрядчиков, а заказчиков. Заказывать пентест — это работа: сформулировать вопрос, очертить границы, договориться о результате и выделить человека, который будет этим заниматься. Подрядчик приносит попытки и доказательства, заказчик — вопрос и готовность разбираться. Без второй половины первая превращается в папку, которую показывают партнёру.

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