PCI DSS v4.0: як перейти від формального сканування до керованої безпеки 

06.10.2026

Вимоги PCI DSS щодо сканування раз на 3 місяці недостатньо для побудови комплексної безпеки. 

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

Далі виявлені вразливості потрібно оцінити, усунути та протестувати повторно. Саме на такому циклі ґрунтується підхід PCI DSS до захисту інфраструктури. 

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

Автентифіковане сканування за PCI DSS

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

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

Вимогу щодо автентифікованого внутрішнього сканування закріплено пунктом 11.3.1.2 PCI DSS v4.0. Раніше вона мала рекомендаційний характер, але з 1 квітня 2025 року стала обов’язковою.

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

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

Чим звичайне сканування відрізняється від автентифікованого?

Неавтентифіковане сканування перевіряє систему через мережу без облікових даних.

Зазвичай воно виявляє:

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

Сканер може перевірити встановлене програмне забезпечення, пакети, оновлення безпеки, служби та параметри конфігурації. Водночас самої успішної автентифікації недостатньо: для повної перевірки можуть знадобитися додаткові права.

Неавтентифіковане сканування 
Сканер ───► мережевий інтерфейс ───► доступні сервіси 

Автентифіковане сканування 
Сканер ───► облікові дані ───► ОС ───► локальні дані та перевірки 

Які права потрібні обліковому запису сканера? 

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

Згідно з вимогою 11.3.1.2, права облікового запису мають бути достатніми для збору системних параметрів:

Звичайних прав користувача для цього здебільшого недостатньо. Наприклад, сканер може успішно підключитися до Linux-сервера через SSH, але не мати права запускати адміністративні команди чи читати системні журнали. У такому разі перевірка буде неповною.

Це не означає, що обліковому запису сканера потрібно надавати максимальні права в домені чи операційній системі. Рівень доступу визначають за рекомендаціями виробника сканера, типом ОС і принципом найменших привілеїв.

Головне питання: чи має сканер після автентифікації достатньо прав для збору даних, необхідних для виявлення вразливостей?

Як перевірити фактичне покриття 

Повідомлення «Сканування завершено» означає лише завершення завдання. Воно не підтверджує, що кожну систему справді перевірено та автентифікацію успішно виконано.

Розглянемо приклад середовища PCI DSS зі 100 серверами:

Якщо на частині серверів облікові дані не спрацювали або виникли помилки доступу до файлів, такі системи не можна вважати повністю перевіреними. Потрібно усунути проблему з доступом і провести повторне сканування. 

Коли ризик є, а CVE немає 

Не всі вразливості мають ідентифікатор CVE. Ризик можуть створювати надмірні права доступу, небезпечні параметри конфігурації, зайві активні служби чи неправильні права на файли.

Сканер може класифікувати таку проблему як дефект середнього рівня. Проте цей рейтинг не завжди відображає реальну небезпеку для бізнесу. Базовий бал CVSS показує лише технічну критичність дефекту, але не враховує контекст конкретної інфраструктури. Наприклад, однаковий недолік конфігурації має різний вплив на ізольованому тестовому сервері та в платіжному середовищі PCI DSS.

Наприклад, одна проблема конфігурації може мати різний вплив на тестовому сервері та критичному компоненті середовища PCI DSS.

Вимога 6.3.1 PCI DSS зобов’язує організацію самостійно класифікувати ризики з урахуванням особливостей свого середовища. Звіти сканера дають дані для аналізу, але не замінюють внутрішньої експертизи.

Профілі сканування: вразливості та конфігурація

Сканери можуть перевіряти різні аспекти безпеки:

Ці перевірки не замінюють одна одну. Сканування вразливостей може не виявити небезпечні налаштування, наприклад, зайві служби, слабку політику паролів чи неправильні права на файли.

Водночас відповідність CIS Benchmark не означає, що у встановленому програмному забезпеченні немає відомих вразливостей. Тому результати перевірок вразливостей і конфігурації потрібно аналізувати сукупно.

Застарілі стандарти конфігурацій — прихована проблема 

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

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

У такому разі недостатньо виправити налаштування окремих серверів. Потрібно переглянути внутрішній стандарт посилення конфігурації та оновити його з урахуванням актуальних вимог.

Від процесу сканування — до усунення вразливостей

Сканування фіксує стан систем у конкретний момент, тоді як управління вразливостями охоплює весь цикл:

Виявити → оцінити → визначити пріоритет → усунути → повторно перевірити → підтвердити результат

За вимогою 11.3.1 внутрішнє сканування потрібно проводити щонайменше раз на 3 місяці та після значних змін у середовищі. Критичні та високоризикові вразливості слід ліквідувати у встановлені терміни. Після цього необхідно провести повторне сканування (re-scan), щоб документально підтвердити вирішення проблеми.

Вимога 6.3.3 визначає строк для встановлення критичних патчів — протягом одного місяця з моменту їхнього випуску.

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

На контрольованість середовища вказують:

Знайдіть слабкі місця у процесі управління вразливостями

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

Це допомагає не допустити ситуації, коли одні й ті самі прогалини переходять з одного звіту до іншого.

Фахівці GetPCI проаналізують поточний стан безпеки, виявлять слабкі місця та зберуть необхідні докази для оцінювання PCI DSS. Зверніться до нас вже зараз!