Як підготуватися до пентесту: що має зробити замовник?

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

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

Коротко

• Межі перевірки (scope, тобто що саме тестуємо) мають бути на папері: системи, адреси, середовища, ролі користувачів і що залишається поза тестом.
• Дозвіл і правила роботи підписує людина, яка має право вирішувати за компанію. Без цього документа активні дії не починаються.
• AWS, Microsoft Azure і Google Cloud станом на жовтень 2026 року не вимагають попереднього погодження звичайного пентесту ваших ресурсів, але в кожного є свої заборони. Звичайний хостинг має свої правила.
• Перед стартом зробіть свіжу резервну копію і переконайтеся, що вона відновлюється.
• Звіт корисний лише тоді, коли в кожної знахідки є відповідальний і строк. Ретест (повторна перевірка після виправлень) показує, що закрито насправді.

Що підготувати: таблиця для замовника

Межі перевірки: системи, середовища, ролі

Почніть із переліку того, що є: доменні імена, адреси API, IP адреси серверів, мобільні застосунки, адмінпанелі. Біля кожного пункту напишіть, навіщо він бізнесу і які дані там лежать. Тоді виконавець зрозуміє, де глибина важливіша, а де достатньо поверхневої перевірки.

Окремо опишіть ролі користувачів: клієнт, менеджер, адміністратор, партнер. Для кожної ролі створіть принаймні два тестові акаунти. Так тестувальник перевірить найчастішу проблему вебзастосунків: чи може один клієнт побачити замовлення або документи іншого.

Назвіть і те, що поза межами. Платіжний провайдер, CRM у хмарі чи сервіс розсилок належать іншим компаніям, і їх не можна тестувати без дозволу їхнього власника. NCSC радить, щоб у визначенні меж брали участь власники ризиків, технічні люди і представник команди тестування. ^[5]

Письмовий дозвіл і правила роботи

Дозвіл захищає обидві сторони: вас від шкоди, виконавця від звинувачення в незаконному доступі. Правила роботи (rules of engagement, тобто як саме поводяться під час тесту) зазвичай містять:

• які системи і з яких IP адрес тестувальників можна перевіряти;
• дати й години, коли дозволені активні дії;
• що заборонено: навантажувальні атаки, видалення даних, листи реальним клієнтам;
• кого кликати, якщо сайт почав гальмувати, і як зупинити тест;
• що робить виконавець, якщо знайшов критичну проблему: пише одразу, а не чекає звіту.

NIST у посібнику з тестування безпеки окремо описує планування і правила проведення перевірок. ^[4] Підписує документ людина, яка справді має право давати доступ до систем компанії.

Хмара і хостинг: чи треба когось повідомляти

Правила великих хмар станом на жовтень 2026 року:

• AWS. Попереднє погодження не потрібне для сервісів зі списку дозволених. Заборонені атаки на відмову в обслуговуванні (DoS, коли сервіс перевантажують запитами) і кілька інших дій. Для прихованих симуляцій атак і серверів керування (C2) потрібна окрема заявка щонайменше за два тижні. ^[1]
• Microsoft Azure. Повідомляти Microsoft не потрібно, але діють правила Microsoft для пентесту хмари: тестувати лише свої ресурси, DoS заборонено. ^[2]
• Google Cloud. Повідомляти Google не потрібно. Тести мають зачіпати лише ваші проєкти і відповідати правилам використання Google Cloud. ^[3]

Звичайний хостинг і VPS живуть за власними умовами. На спільному хостингу поруч із вами інші клієнти, тож тестують лише ваш сайт. Прочитайте договір або напишіть у підтримку заздалегідь. Якщо сайт стоїть за WAF (фільтром вебзапитів) чи CDN, вирішіть, чи додавати адреси тестувальників у виняток: інакше захист може блокувати перевірку, і ви отримаєте результат про фільтр, а не про сайт.

Правила провайдерів змінюються. Перед стартом відкрийте актуальну сторінку свого провайдера, а не покладайтеся на статтю, навіть цю.

Резервні копії, тестове чи робоче середовище

Тестове середовище (staging, копія системи для перевірок) безпечніше: там можна пробувати агресивніші сценарії. Але воно має бути схожим на робоче: та сама версія коду, ті самі налаштування доступів. Частина проблем живе лише в робочій системі, наприклад помилки конфігурації сервера чи зайві відкриті сервіси. Часто глибоко тестують staging, а робочий периметр перевіряють обережно і в погоджені години.

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

Що сказати команді

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

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

Як читати звіт і що з ним робити

Добрий звіт має короткий висновок для керівництва і технічні деталі для команди. Як оцінити його якість, я описав у статті про вибір виконавця. Коли звіт прийшов:

1. Прочитайте висновок і переконайтеся, що розумієте, чим кожна критична знахідка загрожує бізнесу.
2. Призначте кожній знахідці відповідального і строк. Критичне закривають першим.
3. Виправляйте причину, а не одне поле форми: подібна помилка часто є і в сусідніх місцях.
4. Якщо щось вирішили не виправляти, запишіть це як прийнятий ризик із підписом.

NCSC нагадує, що рішення про ризики і виправлення залишаються за замовником, а не за тестувальниками. ^[5]

Ретест

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

Чекліст підготовки

• Перелік систем, адрес і середовищ узгоджено письмово.
• Записано, що поза межами тесту, включно зі сторонніми сервісами.
• Для кожної ролі створено щонайменше два тестові акаунти.
• Підписано NDA і дозвіл із правилами роботи.
• Узгоджено дати, години і канал для термінових повідомлень.
• Є контакт із нашого боку, який може зупинити тест.
• Перевірено правила хостингу або хмари на актуальній сторінці провайдера.
• Вирішено, що робити з WAF і CDN під час тесту.
• Зроблено резервну копію, відновлення перевірено.
• Попереджено підтримку, адміністраторів і моніторинг.
• Призначено відповідального за звіт і виправлення.
• Ретест і його строки прописано в договорі.

Завантажити чекліст підготовки (PDF)PDF · A4

FAQ

Скільки часу займає підготовка?

Якщо системи описані, а доступи видає одна людина, зазвичай вистачає кількох робочих днів. Найдовше чекають підпису дозволу і створення тестових акаунтів, тому почніть із них.

Чи можна тестувати лише робочу систему без staging?

Можна, якщо правила це враховують: обережніші перевірки, погоджені години, свіжа резервна копія і людина на зв'язку. Агресивні сценарії краще залишити для тестового середовища.

Чи треба давати пентестерам паролі адміністратора?

Залежить від мети. Для перевірки «ззовні» доступи не потрібні. Для перевірки прав доступу потрібні тестові акаунти з різними ролями. Справжні паролі працівників не передавайте ніколи.

Чи треба повідомляти AWS, Azure або Google Cloud?

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

Що робити, якщо під час тесту знайшли критичну проблему?

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

Посилання

1. AWS: Penetration Testing aws.amazon.com
2. Microsoft Cloud Penetration Testing Rules of Engagement microsoft.com
3. Google Cloud Security FAQ support.google.com
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. NCSC: Penetration testing ncsc.gov.uk