Що таке пентест і чим він відрізняється від сканера вразливостей
Тест на проникнення (пентест) — це контрольована атака на вашу інфраструктуру, яку проводить фахівець із дозволом власника системи, а не зловмисник. Мета проста: знайти реальний шлях всередину раніше, ніж це зробить хтось сторонній. Це не те саме, що автоматичний сканер вразливостей — сканер видає список потенційних дір за версіями ПЗ, а пентестер перевіряє, чи можна ці діри реально використати, зв'язати кілька дрібних недоліків у один робочий ланцюжок атаки і дістатися до бази даних, адмінки чи внутрішньої мережі.
Різниця відчутна на практиці. Сканер може написати «застаріла версія nginx» і зупинитися. Пентестер піде далі: перевірить, чи ця версія дійсно вразлива у вашій конфігурації, чи є робочий експлойт, і що станеться, якщо ним скористатися. Саме тому звіт із пентесту — це не список CVE-номерів, а історія: як саме, крок за кроком, стороння людина може дістатися до критичних даних компанії. Для бізнесу це різниця між «нам сказали, що є ризики» і «нам показали, як саме нас можна зламати сьогодні».
Навіщо бізнесу взагалі це потрібно
Найчастіша причина замовити пентест — не «хочеться», а конкретна подія: вихід на новий ринок, вимога партнера чи страхової компанії, підготовка до сертифікації, або просто відчуття, що інфраструктура виросла і ніхто давно не перевіряв, що там насправді відбувається під капотом.
- Відповідність вимогам. Партнери, банки та страхові дедалі частіше просять підтвердження, що інфраструктура перевірена незалежно, а не «ми самі подивились і начебто все ок».
- Зниження вартості інциденту. Простій, відновлення даних, комунікація з клієнтами після витоку і репутаційні втрати коштують у рази дорожче за сам тест.
- Умова кіберстрахування. Частина страхових продуктів вимагає свіжого звіту про тестування безпеки як передумову виплати при інциденті.
- Реальна картина замість припущень. Внутрішня команда звикає до своєї системи і не бачить очевидного для стороннього фахівця — це нормально, так працює свіжий погляд.
Оцінка захищеності — це ще й аргумент у перемовинах. Коли великий клієнт запитує, як ви захищаєте його дані, свіжий звіт вагоміший за загальні слова про «серйозне ставлення до кібербезпеки».
Важливо розуміти масштаб: пентест — не окрема послуга у вакуумі, а частина ширшої роботи з аудиту інформаційної безпеки, куди входять контроль доступу, моніторинг загроз і робота з конфігураціями хмарної та мережевої інфраструктури. Знайти діру недостатньо — важливо ще й закрити її, перевірити результат і вбудувати ці перевірки в постійний процес. Саме тому інтегратори на кшталт Senseti поєднують сам тест на проникнення з подальшим управлінням виявленими вразливостями, а не зупиняються на звіті.
Типи пентесту: black box, grey box і white box
Перше, що узгоджують перед тестом на проникнення, — обсяг знань, який отримує пентестер про систему. Від цього залежить і сценарій атаки, і глибина покриття, і ціна. Розрізняють три підходи.
Black box — «чорна скринька»
Фахівець не має жодної інформації, окрім назви компанії чи адреси сайту — рівно те, з чим стартує реальний зловмисник ззовні. Такий тест найкраще показує, наскільки міцний зовнішній периметр, але коштує дорожче за час: багато зусиль іде на розвідку, і частина внутрішніх вразливостей може лишитися поза увагою просто тому, що до них не встигли дістатися.
Grey box — «сіра скринька»
Пентестер отримує обмежений доступ: обліковий запис звичайного користувача, документацію на API чи схему мережі. Це моделює найпоширенішу реальну загрозу — атаку від людини, яка вже має якийсь легальний доступ (співробітник, підрядник, скомпрометований акаунт). Для більшості компаній це оптимальний баланс глибини й вартості.
White box — «біла скринька»
Максимальна прозорість: фахівець має доступ до вихідного коду, конфігурацій, архітектури й привілейованих облікових записів. Тут пентест перетинається з поглибленим аудитом і дає найповніше покриття вразливостей — включно з логічними помилками в коді, які ззовні майже неможливо знайти. Такий формат обирають для критичних систем, де ціна пропущеної діри надто висока.

Внутрішній чи зовнішній пентест: що обрати
Окремо від рівня знань є питання точки, з якої моделюється атака. Зовнішній тест перевіряє, що бачить і може атакувати людина без жодного доступу — з інтернету, як реальний зловмисник. Внутрішній моделює ситуацію, коли атака вже почалась зсередини: скомпрометований ноутбук співробітника, шкідливий USB-накопичувач, підключення через захоплену Wi-Fi-точку.
Для більшості компаній має сенс поєднання обох підходів: зовнішній периметр і внутрішня мережа зламуються різними способами, і закрити тільки один із них — залишити половину картини невідомою. Класичний сценарій сучасної атаки саме такий: зловмисник проривається через одну зовнішню діру (наприклад, фішинг), а далі рухається всередині мережі — і якщо внутрішня сегментація слабка, один скомпрометований ноутбук відкриває доступ до всього.
Ця логіка «прорив плюс рух усередині» лежить в основі концепції нульової довіри (Zero Trust): кожен запит перевіряється незалежно від того, звідки він прийшов — ззовні чи з уже «своєї» мережі. Саме тому зовнішній і внутрішній тести доповнюють один одного, а не замінюють.
Етапи пентесту: що насправді відбувається
Класичний тест на проникнення проходить через кілька послідовних етапів, і пропуск будь-якого з них перетворює перевірку на формальність. Ця послідовність не вигадана «на око»: технічну методологію тестування безпеки описує окремий стандарт NIST — SP 800-115, на який спираються фахівці по всьому світу.
1. Розвідка (reconnaissance)
Збір публічної інформації про компанію: піддомени, IP-адреси, технологічний стек, витік облікових даних у відкритих базах, згадки в соцмережах співробітників. Зловмисник саме так і починає — з речей, які вже видно ззовні без жодного «злому».
2. Сканування та аналіз поверхні атаки
Автоматизоване й ручне сканування відкритих портів, сервісів, версій ПЗ, конфігурацій серверів і застосунків. Тут формується карта: що зовні доступно, які сервіси застаріли, де є явно зайві відкриті порти.
3. Експлуатація
Найважливіший етап. Фахівець намагається реально використати знайдені слабкі місця: провести SQL-ін'єкцію, обійти автентифікацію, підібрати слабкий пароль, отримати доступ через незакритий адмін-панель. Саме тут стає зрозуміло, які вразливості «теоретичні», а які відкривають реальний доступ до системи.
4. Пост-експлуатація та підвищення привілеїв
Якщо доступ отримано — перевіряється, наскільки далеко можна просунутися: чи можна з одного скомпрометованого сервера дістатися до інших, підвищити права до адміністратора, отримати доступ до бази клієнтів. Це відповідає на головне питання бізнесу: «а що станеться, якщо зламають одну точку?».
5. Звіт і рекомендації
Фінальний документ описує кожну знайдену вразливість, доказ експлуатації (proof of concept), рівень критичності та конкретні кроки для усунення — не «оновіть систему безпеки» загальною фразою, а точний перелік: який компонент, яка версія, яке налаштування змінити.
Чек-лист вразливостей, які найчастіше знаходять на пентесті
Список нижче — не вичерпний, але охоплює категорії, які реально закривають більшість інцидентів у бізнесі малого й середнього розміру.
Вразливості вебзастосунків
- SQL-ін'єкція — можливість вставити шкідливий запит через форму на сайті й отримати прямий доступ до бази даних.
- XSS (міжсайтовий скриптинг) — виконання чужого коду в браузері користувача через незахищені поля вводу.
- Слабка автентифікація та контроль сесій — токени, що не закінчуються, передбачувані ідентифікатори сесій, відсутність багатофакторної автентифікації.
- Небезпечні прямі посилання на об'єкти — коли, змінивши число в URL, користувач бачить чужий рахунок чи документ.
Мережеві та інфраструктурні вразливості
- Відкриті порти без потреби — сервіси, доступні ззовні, хоча мали б бути видимі лише у внутрішній мережі.
- Невиправлені CVE — публічно відомі вразливості в конкретних версіях ПЗ, для яких давно вийшов патч, але його не встановили.
- Слабка сегментація мережі — коли компрометація одного сервера відкриває шлях до всієї внутрішньої мережі без додаткових бар'єрів.
- Незашифрований трафік — передача даних без TLS там, де це критично: форми входу, платіжні дані, внутрішні API.
Конфігураційні помилки
- Дефолтні облікові дані — адмін-паролі виду «admin/admin», які так і не змінили після встановлення обладнання чи ПЗ.
- Зайві права доступу — коли рядовий співробітник технічно має права адміністратора бази даних.
- Відкриті хмарні сховища — публічно доступні S3-бакети чи аналогічні сховища з внутрішніми документами.
- Застарілі або невикористовувані облікові записи — доступи звільнених співробітників чи тестові акаунти, які ніхто не видалив.
Людський фактор
- Фішинг — листи, що імітують керівництво чи партнерів і провокують перехід за посиланням або передачу пароля.
- Соціальна інженерія по телефону — дзвінок «зі служби підтримки», який просить продиктувати код підтвердження.
- Відсутність процедури реагування — співробітники не знають, кому повідомити про підозрілий лист чи дивну поведінку системи.
Категорії вразливостей із цього чек-листа узгоджуються з класифікацією OWASP Top 10 — відкритим міжнародним переліком найпоширеніших ризиків вебзастосунків, на який орієнтуються фахівці з безпеки по всьому світу.

Регуляторний контекст: коли пентест — вимога, а не побажання
Для багатьох компаній оцінка захищеності перестала бути питанням доброї волі й перетворилася на пункт у вимогах стандартів і законів. Розуміти цей контекст важливо, бо часто саме він визначає обсяг і періодичність тестування.
- ISO/IEC 27001. Найпоширеніший стандарт системи управління інформаційною безпекою. Прямо «пентест раз на рік» він не диктує, але вимагає регулярної оцінки технічних вразливостей — і аудитори очікують побачити документально підтверджене тестування як доказ, що процес працює, а не існує на папері.
- NIS2. Директива ЄС про кібербезпеку (огляд ENISA) суттєво розширює коло компаній, зобов'язаних керувати кіберризиками й тестувати заходи безпеки. Для українського бізнесу, що працює з європейськими партнерами чи виходить на ринок ЄС, це стає практичною вимогою з боку контрагентів.
- GDPR. Регламент про захист персональних даних вимагає «регулярного тестування, оцінювання та вимірювання ефективності» технічних заходів захисту. Пентест — один із очевидних способів показати регулятору, що ви це робите, а не декларуєте.
- Галузеві вимоги. Для тих, хто обробляє платіжні картки, стандарт PCI DSS прямо вимагає регулярного тестування на проникнення. У фінансовому й медичному секторах вимоги ще жорсткіші.
Регулятор чи аудитор перевіряє не факт «у нас є антивірус», а докази, що захист реально працює. Звіт про тестування безпеки — саме такий доказ, який складно замінити словами.
Скільки триває пентест і як часто його повторювати
Тривалість залежить від масштабу периметра: тест невеликого вебзастосунку може зайняти кілька днів, повноцінна перевірка інфраструктури середньої компанії — від двох до чотирьох тижнів разом зі звітом. Періодичність — не разова акція: розумний мінімум це раз на рік, плюс позаплановий тест після будь-якої суттєвої зміни інфраструктури — нового застосунку, міграції в хмару, злиття систем після придбання компанії.
Важливий нюанс: пентест показує стан на конкретний момент часу. Через півроку після нового реліза чи оновлення системи картина може бути зовсім іншою, тому разовий звіт «на всі часи» — це поширена й дорога помилка. Кібербезпека — це процес, а не подія: між повними тестами має працювати постійний моніторинг і управління вразливостями.
Як обрати виконавця пентесту
Ринок неоднорідний: під вивіскою «тест на проникнення» іноді продають звичайний автоматичний скан, роздрукований у PDF. Щоб не заплатити за галочку, варто дивитися на кілька практичних ознак.
- Ручна робота, а не лише сканер. Запитайте, яка частка тесту виконується вручну. Якщо весь результат — це вивід сканера без перевірки експлуатації, це не пентест, а сканування вразливостей під іншою назвою.
- Приклад звіту. Хороший виконавець покаже знеособлений зразок: як описано знахідку, чи є доказ експлуатації, наскільки конкретні рекомендації щодо усунення.
- Чіткий скоуп і правила гри. До старту мають бути письмово узгоджені межі тесту, вікна робіт, недоторканні системи й порядок дій, якщо буде знайдено критичну діру просто зараз.
- Повторна перевірка після виправлень. Серйозний підхід передбачає ретест: виконавець перевіряє, що знайдені вразливості дійсно закриті, а не просто позначені як «виправлено».
- Досвід і сертифікації команди. Профільні сертифікати (наприклад, OSCP) і реальні кейси самі по собі якості не забезпечують, але слугують базовим фільтром проти випадкових виконавців.
Окремий сигнал якості — коли виконавець не зникає зі звітом, а супроводжує процес усунення й може підказати, як вибудувати захист системно: контроль доступу, сегментацію, реагування на інциденти. Оцінка захищеності має бути входом у постійну роботу з кібербезпеки, а не фінальною точкою.

Часті помилки при замовленні пентесту
- Обмежений скоуп «для галочки». Тестується лише один сайт-візитка, а критична внутрішня система залишається поза перевіркою.
- Звіт без пріоритизації. Список із 40 знахідок без позначення критичності змушує команду хапатися за все одразу замість того, щоб спершу закрити три найнебезпечніші.
- Відсутність повторної перевірки. Вразливості «виправили» на словах, але ніхто не підтвердив це повторним тестом.
- Пентест замість базової гігієни. Немає сенсу платити за складний тест на проникнення, якщо паролі за замовчуванням досі не змінені — спершу базові речі, потім глибша перевірка.
Що робити з результатами пентесту
Готовий звіт — це не кінець роботи, а її початок. Практичний порядок дій: спершу закрити критичні вразливості з прямим доступом до даних, потім — високого рівня ризику, паралельно виправляючи дрібні конфігураційні недоліки. Після виправлень варто провести хоча б часткову повторну перевірку саме тих місць, де були знахідки — щоб переконатися, що патч дійсно закрив діру, а не просто змінив повідомлення про помилку.
Пентест, після якого нічого не змінилося в інфраструктурі, — це витрачені гроші. Цінність тесту не в самому факті перевірки, а в тому, наскільки послідовно команда закриває знайдені прогалини.
Поширені запитання
Чим пентест відрізняється від аудиту безпеки?
Аудит зазвичай ширший і перевіряє процеси, документацію та відповідність стандартам, тоді як пентест — це вузько сфокусована практична перевірка: чи можна реально зламати систему. Часто вони йдуть у парі: аудит показує загальний стан, пентест — конкретні технічні дірки.
Чи може пентест «покласти» робочі системи?
Ризик є, тому серйозні виконавці узгоджують вікна тестування, виключають найбільш чутливі продакшн-системи з активної фази експлуатації або працюють на тестовому середовищі-копії, якщо ризик простою критичний для бізнесу.
Скільки коштує тест на проникнення для малого бізнесу?
Вартість залежить від розміру периметра — кількості застосунків, серверів, підмереж — і глибини тесту. Невеликий вебзастосунок обійдеться суттєво дешевше за повноцінний тест інфраструктури з внутрішньою мережею й хмарними сервісами.
Який тип пентесту обрати — black, grey чи white box?
Для перевірки зовнішнього периметра ближче black box, для оцінки ризику від внутрішнього порушника — grey box, для критичних систем із доступом до коду — white box. На практиці багато компаній комбінують формати під різні частини інфраструктури.
Чи достатньо одного пентесту «раз і назавжди»?
Ні. Інфраструктура змінюється, з'являються нові CVE, оновлюється код — тому пентест має бути регулярною практикою, а не одноразовою подією перед перевіркою чи тендером.



