Передача доступа для тестирования безопасности: охват, учётные записи и отзыв
Тестировщику, который просит учётные данные VPN, нужна передача с очерченным охватом, а не запасной логин. Проверьте авторизацию шлюзом, назовите цели, выдайте учётные записи, затем отзовите.
Тестировщик просит адрес шлюза, сведения о внутреннем DNS и учётные данные VPN, и запрос пересылают вам с темой «нужен доступ». Сам по себе запрос не говорит, идёт ли речь о внутренней оценке, тесте приложения с аутентификацией или работе с публичным сайтом, где кто-то неверно понял охват. Проведите передачу как последовательность с воротами на каждом шаге и остановитесь на первых воротах, которые не открываются. Так расплывчатый запрос превращается в то, что можно авторизовать, выдать и позже отозвать.
Начните с авторизации, а не с учётных данных
Прежде чем какой-либо адрес покинет ваш ящик, установите, кому принадлежат цели и кто вправе одобрять тестирование на них. Проверьте тестировщика через контакт по проекту, который ваша организация уже использует, а не через человека, переславшего письмо. Отношения с клиентом не дают права тестировать каждую систему, доступную из учётной записи, а заказ на закупку не является документом об охвате.
Запишите одобренную цель одним предложением и держите её рядом с передачей. «Оцените аутентификацию клиентского портала» и «оцените внутреннюю сеть» ведут к совершенно разным пакетам, и разницу нужно урегулировать до подготовки доступов, а не после того, как придёт находка. Предложение также даёт то, на что можно указать, когда запрос разрастается посреди работы.
Если на пути есть хостинг-провайдер или другая третья сторона, их требования идут впереди вашего удобства. Тестирование чужой инфраструктуры без её разрешения — отдельная проблема, не связанная с тестированием приложения, которое на ней работает.
Назовите точку зрения и цели
Точка зрения — это вопрос, на который пытается ответить оценка, и она определяет пакет доступа больше, чем любой инструмент, который тестировщик планирует использовать. Публичному неаутентифицированному тесту нужны URL и временное окно. Аутентифицированному тесту нужны выделенные учётные записи для конкретных ролей в охвате, а внутренней оценке — определённая точка входа с явными диапазонами целей.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
То, куда входит туннель, — не тот же факт, что и приложение, стоящее за ним, и это никоим образом не даёт права исследовать точку входа. Скажите это прямо в передаче, потому что фраза «ты дал мне доступ к той подсети» появляется быстро, как только находку начинают оспаривать. Письменный список целей — единственное, что решает это потом.
Укажите имя хоста TLS вместе с URL. Голый IP-адрес заставляет тестировщика угадывать имя, а угаданное имя порождает ошибки сертификата, которые сообщают как находки, а не как ошибку передачи.
Выдайте выделенные идентичности со сроком действия
Подготовьте учётные записи, которые существуют только для этой работы; не одалживайте повседневный логин сотрудника. Настройте сетевую доступность и разрешения приложения под согласованные задачи, организуйте регистрацию аутентификации поддерживаемым путём и укажите срок действия с названным лицом, ответственным за отзыв. Передайте учётные данные по согласованному защищённому каналу, отдельно от документа об охвате, который пересылают по кругу.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Записывайте, кто что получил и когда. Эта запись — разница между контролируемой передачей и общим паролем, который никто не может отследить, и это первое, что просят после инцидента. Храните её вместе с документом об охвате, а не в переписке, и отмечайте канал передачи рядом с получателем. Строка с отметкой времени всегда лучше воспоминания.
Поле срока действия — это последняя страховка, а не план. Кто-то всё равно должен снять сетевой путь и роль приложения в конце, потому что истёкший логин в сети, которая всё ещё доступна, не является отозванным доступом.
Докажите, что передача работает, прежде чем откроется окно
Прогоните первый шаг тестировщика сами, из позиции как можно ближе к его. Разрешите имя, проверьте идентичность сертификата и убедитесь, что путь ведёт к нужному адресу, а не к соседнему.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
Если путь не достигает цели, остановитесь и согласуйте передачу, а не позволяйте тестировщику обнаружить альтернативный маршрут. Импровизированная доступность — это способ, которым оценка тихо выходит за свои рамки, и об этом почти никогда не пишут задним числом.
Отправьте вместе с учётными данными оперативный контакт, разрешённые часы, исключённые действия и условия остановки. Тестировщик, который в 02:00 не может никому дозвониться, примет решение, которое вы не авторизовали, и это решение будет описано в отчёте так, будто оно было в охвате.
NIST SP 800-115 описывает техническую оценку как плановое тестирование с последующим анализом и снижением риска, и именно этой форме следует настоящая передача. Ворота выше — редакционные дизайнерские решения для инженера поддержки, а не контрольный список, цитируемый из этой публикации.
Закройте работу, сняв доступ
Отзывайте в обратном порядке относительно подготовки: роли приложения, затем сетевой доступ, затем сама идентичность. Подтверждайте каждый шаг, а не предполагайте, что консоль сделала обещанное кнопкой. Заблокируйте учётную запись, прежде чем убивать её сеансы, иначе сеанс просто заново аутентифицируется по старому пути. Затем ещё раз проверьте установленные соединения, прежде чем объявить всё закрытым.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Уладьте любые сохранённые тестовые данные, затем отслеживайте исправление через процесс отчётности, согласованный в начале. В отчёте должны быть указаны среда, уровень доступа, охват и ограничения, потому что он фиксирует находки одной оценки и не является постоянным заявлением о безопасности сайта.
Храните запись об отзыве вместе с записью о передаче. Когда откроется следующая работа, вы хотите точно знать, что было снято в прошлый раз и кто это утвердил, а не восстанавливать картину по памяти.