Пентест внешним подрядчиком: как выдать и закрыть доступ

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

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

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

Начните с графа доступа, а не с просьбы «создать пользователя для пентеста»

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

Типичная цепочка выглядит так: именной тестировщик → гостевая учётная запись → VPN-сеанс → облачная роль → чтение объектного хранилища → скачанное доказательство. Блокировка гостя может остановить новый вход, но действующий сеанс приложения иногда подчиняется другой политике. Отзыв старого сеанса облачной роли не запрещает принять её заново, пока открыт доверительный путь. Удаление доступа к репозиторию не стирает локальную копию. Архив доказательств может по согласованному правилу храниться дольше интерактивного доступа.

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

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

Определяйте минимальный доступ по сценариям проверки

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

Если такие роли есть в продукте и согласованной проверке, разделите три вида учётных записей:

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

Делегирование в облаке оставляйте под контролем заказчика. Роли AWS дают временный межаккаунтный доступ: политика доверия определяет подрядчика, разрешения — ресурсы и действия. Выданный подрядчиком уникальный ExternalId связывает запрос с клиентом в многоклиентском сервисе; секретом он не является. Для проекта отдельно запишите ограничения сеанса и источника подключения, владельца каждого разрешения и способ запретить получение роли заново.

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

Проверяйте целевые роли, не меняя объём работ незаметно

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

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

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

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

Подготовьте матрицу доказательств до начала тестирования

Матрица превращает каждое право в небольшой приёмочный тест. Вместо общих названий в ней должны стоять конкретные идентификаторы.

Отрицательная проверка должна соответствовать закрываемому пути. Вход через браузер ничего не говорит о токене API. Человеческая учётная запись ничего не говорит о ключе развёртывания. Название роли мало значит, если политика ресурса независимо разрешает тому же субъекту доступ. Записывайте компонент, время, идентичность запроса, цель, решение и конечное состояние.

Закрывайте полномочия в управляемом порядке

У закрытия две задачи: прекратить будущие полномочия и учесть оставшиеся данные. Выполняйте его, пока тестировщики доступны, а события легко сопоставить с журналами.

1. Заморозитьпрекратить новые тесты и зафиксировать итоговый граф доступа и активные работы
2. Отозватьзакрыть выдачу новых прав, отозвать сеансы и удалить независимые ключи
3. Проверитьубедиться, что прежний путь подрядчика отклонён, а независимый контроль заказчика работает
4. Сверитьучесть артефакты, исключения, владельцев, сроки хранения и итоговые доказательства

Сначала остановите новые тесты и сохраните журнал последних обращений. Учтите запущенные задания, обратные вызовы, туннели и очереди; остановите либо завершите их по согласованному плану и проверьте конечное состояние. Отзыв ключа, поставившего задание в очередь, сам по себе не отменяет уже запущенную работу. Затем закройте выпуск новых полномочий: удалите доверие, назначения, членство в группах, согласия приложений, права участника репозитория и сетевые допуски. После этого обработайте уже выданное: сеансы ролей, токены обновления, cookie приложений, VPN-сеансы, персональные токены, SSH-ключи, ключи развёртывания, сертификаты и секреты автоматизации.

Порядок важен. Отзыв сеансов роли AWS IAM может запретить сеансы, выданные до заданного момента, но разрешить новый после него; для общей роли такая операция затронет и других её пользователей. У ролей, созданных из наборов прав AWS IAM Identity Center, отдельный путь отзыва. Удаление пользователя первым иногда лишает администратора удобной возможности завершить его сеансы. Инструкция должна учитывать фактическую цепочку входа и получения прав, а ответственный за аварийный доступ остаётся доступен до успешной проверки.

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

Разделяйте ключи, сеансы, делегирования и артефакты

Удаление учётной записи даёт удобный снимок экрана, но не завершает закрытие само по себе.

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

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

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

Практический пример закрытия проверки SaaS

Представим, что SaaS-компания поручила независимой команде проверить изоляцию арендаторов. Два именных специалиста получили гостевые записи и VPN. Заказчик создал три обычные роли арендатора, ограниченную роль поддержки, облачную роль чтения журналов и чтение двух репозиториев. Отдельная служебная запись подрядчика использовала ключ развёртывания репозитория и загружала результаты сканера в хранилище доказательств.

Во время работ для одного утверждения роли поддержки понадобилось дополнительное диагностическое действие. Заказчик записал изменение, добавил только это право и операцию удаления. Тестировщик доказал, что диагностика работает, а изменение конфигурации арендатора недоступно. Наблюдатель заказчика подтвердил отсутствие отложенной операции после отказа.

При закрытии заказчик сначала заморозил тесты и закрыл новые VPN- и гостевые назначения. Затем удалил доверие облачной роли, отозвал старые сеансы и проверил отказ как существующего сеанса, так и нового принятия роли. Он удалил участников репозиториев, отдельный ключ развёртывания автоматизации, сменил секрет загрузки доказательств и убедился, что ни человек, ни автоматика больше не получают код. Для тестовых пользователей продукта сначала запретили новый вход и выдачу токенов, затем завершили действующие сеансы и проверили отказ при повторном обращении. С прежним ключом загрузки доказательств отправка тоже не прошла; контрольная учётная запись заказчика сохранила доступ.

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

Что заказчику принимать при передаче результата

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

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