Тестирование на проникновение: где инфраструктура даёт сбой
Уязвимости инфраструктуры редко выглядят как ошибка в коде. Чаще сбой приходит со стороны, которую никто не считал боевой: тестовый стенд, опубликованный наружу «на время», панель администрирования с конфигурацией по умолчанию, порт, открытый для отладки и забытый после релиза. Формально всё работает, но внешний контур шире, чем предполагает команда.
Устаревшие учётные записи — самый частый класс скрытых точек входа. Сервисный аккаунт, которым пользовался ушедший подрядчик, ключ, не отозванный после переезда, роль с правами администратора у учётки, которой достаточно читать метрики. Такие записи не видны в инвентаризации и не мешают продукту — они просто ждут, пока их найдут.
Со стороны внешнего контура это выглядит не как взлом, а как цепочка: сканирование находит открытый сервис, сервис принимает учётные данные, которые никто не менял, дальше движение идёт внутри сети по доверенным связям. Периметр сети при этом считается защищённым, потому что список правил формально закрыт — расхождение между схемой и реальностью и есть предмет проверки.
Цена сбоя — не только утечка. Продукт деградирует незаметно: часть запросов уходит на скомпрометированный узел, журналы собираются не полностью, восстановление затягивается, потому что актуальной карты связей нет ни у кого. Тестирование на проникновение проводят не ради отчёта, а чтобы сверить реальные точки входа с тем, что команда считает своим периметром — разбираем, как это закрывается.
Что меняется после проверки контуров и прав доступа
После проверки контуров и прав доступа работа не заканчивается отчётом: каждое расхождение превращается в изменение конфигурации сервисов или регламента. Проверку ведём по методикам OWASP и фиксируем не только уязвимость, но и класс отказов, который она открывает.
Окно уязвимости сокращается с недель до часов
Раньше критичное обновление ждало ближайшего окна обслуживания, и окно уязвимости растягивалось на две-три недели. Теперь сервисы с внешним доступом попадают в срочный порядок, а срок закрытия фиксируется для каждого контура.
Доля успешных попыток входа падает
Отзываем общие учётные записи, сокращаем права доступа до необходимого минимума и ограничиваем срок жизни ключей. Входы из нетипичных мест перестают быть успешными, легитимные сценарии работают.
Время реакции измеряется минутами
Событие приходит дежурному с контекстом: учётная запись, источник, серия попыток. Регламент реакции описывает первый шаг и владельца — без созвонов и уточнений.
| Класс риска | Что проверяем | Что меняется |
|---|---|---|
| Внешний контур | опубликованные сервисы | лишний доступ закрываем |
| Права доступа | избыточные привилегии и общие учётки | сужаем до необходимого |
| Сегментация | достижимость критичных узлов | правила сужаем до нужных направлений |
| Реакция | наличие регламента и владельца | назначаем владельца и класс отказов |
Итог — не список замечаний, а изменённая конфигурация и работающий регламент: окно уязвимости измеряется часами, а не неделями.
Форматы работ: внешний контур, внутренняя сеть, веб-приложения
Проверка на проникновение начинается не с набора инструментов, а с выбора границ: одни и те же методики дают разный результат снаружи и изнутри сети. Ниже — варианты, между которыми реально выбирают, и то, чем каждый из них ограничен.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Внешний контур | Есть публичные адреса и сервисы, доступные из интернета | Проверку видят системы защиты и мониторинг: нужны согласованные окна и точный перечень адресов |
| Внутренняя сеть | Нужно понять, что доступно атакующему после компрометации одной рабочей станции | Требуется точка входа в сегмент и отдельный доступ; есть риск задеть продуктивные сервисы |
| Веб-приложения | Продукт с личным кабинетом, платежами, загрузкой файлов | Нужны тестовые учётные записи всех ролей и копия данных; разрушительные проверки исключаем |
| Программные интерфейсы | Сервисы обмениваются данными и отдают их внешним потребителям | Часть логики скрыта от наблюдателя; нужны ключи и лимит на число запросов |
| Мобильные клиенты | Есть приложение под мобильные платформы | Нужна тестовая сборка и стенд; отдельно проверяем хранение данных на устройстве |
Внешний периметр
Здесь задача — увидеть организацию глазами того, у кого нет никакого доступа. До старта согласуем адреса, временные окна и контакт дежурной смены: тогда проверка не превращается в ночной инцидент, а находки сразу получают приоритет по достижимости извне.
Внутренние сегменты
Работы внутри начинаются с модели нарушителя: какую учётную запись и какие права считаем скомпрометированными. Дальше смотрим сегментацию, доверительные отношения между доменами и доступ к хранилищам — то, что снаружи не видно, а при развитии атаки решает исход.
Этапы: от согласования границ до передачи отчёта
Работа идёт последовательными этапами: каждый следующий опирается на артефакт предыдущего, поэтому результат воспроизводим и не зависит от того, какой инженер ведёт проект. Ниже — порядок, по которому мы проводим тестирование на проникновение.
Порядок работ
- Аудит контуров: инвентаризация внешних адресов, внутренних подсетей и точек интеграции — карта поверхности атаки с владельцем на каждом узле.
- Согласование границ: диапазоны адресов, окна работ, запрет на разрушающие сценарии, контакт дежурного — всё фиксируем письменно.
- План проверки: сценарии раскладываем по классам риска и переносим копию конфигураций на тестовый стенд, где проверяем опасные гипотезы.
- Работа в продуктивной среде — по согласованным сценариям внутри разрешённого окна, с фиксацией времени и результата каждого шага.
- Верификация находок: каждую гипотезу подтверждаем вторым независимым способом, иначе в отчёт попадает ложное срабатывание.
- Повторная проверка: после устранения возвращаемся к тем же точкам по тому же сценарию и убеждаемся, что уязвимость закрыта.
- Передача отчёта с приоритетами, шагами воспроизведения и рекомендациями, отдельно — что осознанно осталось вне проверки.
Верификация и повторная проверка
Письменные границы, план и подтверждённые находки дают воспроизводимый маршрут: проверку можно повторить и сравнить срезы, а не полагаться на память участников.
Артефакты проверки: отчёт, доказательства, план устранения
Тестирование на проникновение считается завершённым не тогда, когда находки найдены, а когда у команды заказчика остаётся комплект документов, по которому их можно закрыть без участия проверяющих. Вот что мы передаём по итогам работ.
- Отчёт о проверке — находки с вектором эксплуатации, затронутым контуром и оценкой критичности; каждая привязана к конкретному узлу, а не к общим советам.
- Доказательства — последовательности запросов и ответов, логи, дампы состояния: по ним находку можно воспроизвести и подтвердить факт исправления.
- Схема контуров — карта сегментов, точек входа и доверенных связей между сервисами, собранная по факту, а не по проектной документации.
- Политики доступа — правила для сервисных учёток, административных доступов и межсегментных маршрутов с пометкой, где нарушен принцип наименьших привилегий.
- План устранения — приоритеты: что закрывается конфигурацией, что требует изменения архитектуры, что — организационных мер.
- Регламент повторных проверок — периодичность и триггеры: смена периметра, крупный релиз, ротация доступов.
Читаемость для инженеров. Каждая позиция описана в четырёх блоках: находка, воспроизведение, влияние, исправление — этого хватает, чтобы завести задачу без уточнений у проверяющих. Для руководителя отдельно идёт сводка по критичности и матрица трассировки, где видно, какая именно проверка подтвердила закрытие.
Кейс: как закрыли класс отказов в контуре интеграций
Заказчик — платформа с распределённым контуром интеграций: внешние интерфейсы для партнёров, очередь событий, сервисные учётки, уведомления от внешних систем. Тестирование на проникновение до этого делали раз в год и только по внешнему периметру, а связки между сервисами внутри считались закрытыми сетевой сегментацией. Кейс внедрения начался с инвентаризации: на карту легли все точки входа, включая тестовые стенды и админские интерфейсы, оставшиеся от прежних релизов.
Метрики до и после
По прошлой проверке в отчёте значились 4 находки, и закрыли из них около половины — правки упирались в согласования, а срок реакции на новую находку измерялся неделями. После инвентаризации точек входа стало 34, из них 9 с подтверждённой возможностью выйти за границы сервиса. Устранение уязвимостей шло по приоритету: ротация ключей сервисных учёток, разграничение прав между сервисами, вынос админских интерфейсов в отдельный сегмент. Повторный тест не подтвердил ни одной из 9, а время реакции на находку сократилось с недель до нескольких дней.
Почему находки не чинят в один проход
Часть уязвимостей тянет за собой изменение схемы взаимодействия: правка авторизации в одном сервисе ломает вызовы у двух других. Такие изменения идут волнами — сначала то, что закрывается настройками, затем правки в коде, потом отключение устаревших точек входа. Разметку находок вели по OWASP, чтобы приоритеты не зависели от того, кто читает отчёт. Долю закрытых считали не по самому отчёту, а по повторной проверке — она же показала, что осталось за пределами контура.
Чем тестирование на проникновение отличается от сканирования
Сканирование уязвимостей отвечает на вопрос «что в нашей поверхности выглядит известным и устаревшим». Сканер сверяет отклики служб с базой сигнатур, проходит сотни узлов за минуты и отдаёт список — без контекста, что из этого реально достижимо снаружи. Он не отличает тестовый стенд от продуктивного контура, не видит, что форма входа закрыта вторым фактором, и не связывает находки между собой.
Ручная проверка начинается там, где заканчивается сигнатура. Инженер работает с бизнес-логикой: можно ли перебором кода сброса сменить пароль чужого пользователя, обходится ли ограничение роли прямым вызовом метода, ведёт ли цепочка из открытого сервиса, слабой учётной записи и переиспользованного секрета доступа к базе. Методическую рамку задаёт OWASP, но результат даёт не список проверок, а гипотеза о конкретной системе и её данных.
Ложные срабатывания — основная цена автоматизации. Отчёт на несколько сотен строк быстро перестают читать, вместе с ним теряются и настоящие находки. При ручной проверке каждая гипотеза либо подтверждается воспроизводимым сценарием, либо снимается — в отчёте остаётся то, что эксплуатируется и требует исправления. Глубина проверки тоже разная: сканер сообщает о единичной уязвимости, инженер показывает, до каких данных она доводит.
Различается и частота проверок. Сканирование разумно держать в конвейере выпуска — оно не занимает инженеров и ловит регрессии гигиены. Тестирование на проникновение запускают по значимым изменениям: новая внешняя интеграция, смена модели ролей, переезд контура, крупный релиз. На практике их совмещают — регулярный фон плюс глубокая ручная работа по цели, с обязательной перепроверкой закрытых находок.
Ограничения и риски: что уточняем до старта работ
До старта фиксируем письменно границы проверки: перечень адресов и сервисов, окно работ, исключения и стоп-правила. Отдельно согласуем режим проверки — насколько агрессивно можно воздействовать на продуктивную среду, какие сценарии исключены (массовый перебор, обрыв соединений, изменение данных) и кто со стороны заказчика имеет право остановить работы одним звонком.
Влияние на продуктивную среду обычно ограничивается окном низкой нагрузки и лимитом интенсивности, а для узлов без запаса мощности согласуем копию контура. Конфиденциальность отчёта и доступ к результатам — часть договора: круг лиц, защищённый канал передачи, срок хранения, пометка о неразглашении.
Проверка уронит продуктивный сервис?
Ведём контроль метрик во время работ: время ответа и доля ошибок. При выходе за согласованные пороги работы останавливаются, состояние фиксируется, изменения откатываются. Риск деградации закладываем заранее — тогда проверка не превращается в незапланированный простой.
Что делать с находками, которые нельзя закрыть сразу?
Разделяем их на две группы. Первые закрываются настройкой или обновлением в ближайшем релизе. Вторые требуют переработки архитектуры или обновления от внешнего поставщика — на время до исправления подбираем компенсирующие меры: правило фильтрации, ограничение доступа, дополнительный контроль на входе.
Кому доступны результаты проверки?
Отчёт передаём ограниченному кругу лиц по защищённому каналу, храним в закрытом хранилище с журналом доступа. Для руководства готовим выжимку без деталей эксплуатации — она не даёт готового сценария атаки, если попадёт не туда.
Обсудим задачу: что нужно для оценки и плана
Чем точнее исходные данные, тем меньше допущений в оценке объёма — и тем меньше сюрпризов в ходе работ. Начинаем с обсуждения задачи: какие контуры попадают в проверку на проникновение, что уже проверяли раньше и какие результаты наследуем, чтобы не дублировать закрытые находки.
Чтобы вернуться с планом работ, а не с уточняющими вопросами, нужен такой минимум:
- Схема контуров: что считаем внешним периметром, что внутренним, есть ли промежуточные среды.
- Состав сервисов: веб-интерфейсы, программные интерфейсы, админ-панели, мобильные клиенты, интеграции с подрядчиками.
- Ограничения по времени: доступные окна работ, периоды пиковой нагрузки, запретные часы.
- Ответственный за решения: кто согласует объём, кто подтверждает находки, кто выдаёт доступы.
- Точки контакта: дежурный инженер на вашей стороне и наш ведущий специалист, согласованный канал связи.
- Действующие артефакты: прошлые отчёты, политики, регламенты реагирования на инциденты.
- Границы допустимого: что разрешено, а что исключаем — социальную инженерию, физический доступ, нагрузочные сценарии.
Если части данных пока нет — это не стоп: уточним в разговоре и зафиксируем допущения прямо в плане. На выходе вы получаете этапы, их длительность по неделям, состав отчёта и то, что потребуется от вашей команды на каждом шаге.
