Передача доступу для тестування безпеки: обсяг, облікові записи та відкликання

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

Почніть з авторизації, а не з облікових даних

Перш ніж будь-яка адреса покине вашу пошту, встановіть, кому належать цілі й хто має право схвалювати тестування на них. Перевірте тестувальника через контакт проєкту, який ваша організація вже використовує, а не через людину, що переслала лист. Стосунки з клієнтом не дають права тестувати кожну систему, доступну з облікового запису, а замовлення на закупівлю не є документом про обсяг.

Запишіть схвалену мету одним реченням і тримайте його поряд із передачею. «Оцініть автентифікацію клієнтського порталу» та «оцініть внутрішню мережу» ведуть до зовсім різних пакетів, і різницю треба залагодити до підготовки доступів, а не після появи знахідки. Речення також дає те, на що можна вказати, коли запит зростає посеред роботи.

Якщо на шляху є хостинг-провайдер або інша третя сторона, їхні вимоги йдуть перед вашою зручністю. Тестування чужої інфраструктури без її дозволу — окрема проблема, не пов'язана з тестуванням застосунку, що на ній працює.

Назвіть точку зору та цілі

Точка зору — це питання, на яке намагається відповісти оцінювання, і вона визначає пакет доступу більше, ніж будь-який інструмент, який тестувальник планує використовувати. Публічному неавтентифікованому тесту потрібні URL і часове вікно. Автентифікованому тесту потрібні виділені облікові записи для конкретних ролей в обсязі, а внутрішньому оцінюванню — визначена точка входу з явними діапазонами цілей.

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

Вкажіть ім'я хоста 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 )'

Закрийте будь-які збережені тестові дані, потім відстежуйте виправлення через процес звітності, узгоджений на початку. Звіт має вказувати середовище, рівень доступу, обсяг і обмеження, бо він фіксує знахідки одного оцінювання і не є постійною заявою про безпеку сайту.

Зберігайте запис про відкликання разом із записом про передачу. Коли відкриється наступна робота, ви хочете точно знати, що минулого разу зняли і хто це затвердив, а не відновлювати картину з пам'яті.