Скоуп PCI DSS: де насправді закінчуються межі аудиту?

01.09.2026

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

Спершу розберемося, що означають базові терміни PCI DSS:

Скоуп аудиту (межі перевірки) — повний перелік систем, процесів, людей і середовищ організації, які підлягають аудиту. Обсяг скоупу визначає складність, строки та бюджет проєкту сертифікації. Кожна система в межах аудиту передбачає повний набір контролів — наприклад, керування конфігураціями, оновлення, журналювання, контроль доступу, сканування вразливостей.

Системний компонент (system component) — базова технічна одиниця в аудитах PCI DSS, що включається в межі аудиту. Це може бути, наприклад, платіжний застосунок, сервер баз даних, мережевий пристрій, система керування віртуалізацією, хмарні компоненти, принтер, а також робоча станція адміністратора чи мобільний пристрій, з яких здійснюють адміністрування.

CDE (Cardholder Data Environment) — середовище карткових даних. Це сукупність системних компонентів, процесів і персоналу, задіяних у зберіганні, обробці чи передачі карткових даних (CHD) або чутливих автентифікаційних даних (SAD), а також усі неізольовані системи, з’єднані з CDE.

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

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

З чого починається визначення меж аудиту?

Межі аудиту визначаються згідно з керівництвом PCI SSC Guidance for PCI DSS Scoping and Segmentation. Саме на його логіку спирається аудитор під час перевірки повноти визначеного скоупу.

Система потрапляє в межі аудиту, коли виконується хоча б одна з умов:

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

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

Критерії включення не-CDE систем до меж аудиту PCI DSS

Решта критеріїв стосується систем, які не зберігають, не обробляють і не передають карткові дані. Саме тут виникає найбільше розбіжностей з аудитором.

Системи в одному мережевому сегменті з системами, що зберігають, обробляють або передають карткові дані

Файловий сервер бухгалтерії або тестовий стенд в одній підмережі з CDE включається в межі аудиту повністю — з тим самим набором вимог до конфігурацій, оновлень, журналювання й контролю доступу. Через розташування в спільному мережевому сегменті система стає об’єктом аудиту, незалежно від характеру даних, які вона обробляє.

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

Системи, що впливають на безпеку CDE

Системи мають особливий статус, оскільки безпосередньо впливають на захищеність середовища карткових даних. Цей критерій охоплює дві підкатегорії:

1. Системи, що керують доступом, адмініструванням або впливають на безпеку CDE: наприклад, сервери автентифікації та служби каталогів (Active Directory, LDAP, IAM/PAM), робочі станції адміністраторів (PAW / jump-сервери), а також критичні мережеві сервіси (NTP, DNS).
2. Системи, що підтримують виконання вимог стандарту: наприклад, антивірус, DLP (запобігання витокам даних), IPS/IDS (запобігання вторгненням і їхнє виявлення), FIM (контроль цілісності файлів), SIEM (керування подіями та інформацією про безпеку).

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

Системи з прямим підключенням до CDE

Останній критерій охоплює системи, які не включаються до CDE, але мають до нього пряме підключення (наприклад, бастіон-сервери (jump hosts) для віддаленого адміністрування). Вони не зберігають, не обробляють і не передають карткові дані, але компрометація такого сервера через наявний мережевий зв’язок відкриває зловмиснику доступ до CDE.

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

Окремої уваги потребує «правило виключення» (out-of-scope). Система залишається поза межами аудиту лише за одночасного дотримання чотирьох критеріїв (порушення хоча б одного з них автоматично включає систему до скоупу):

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

До меж аудиту потрапляють не лише сховища даних, а й будь-які системні компоненти, здатні вплинути на безпеку CDE.

Робоча станція адміністратора під час роботи з хмарою

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

​Зазвичай заперечення звучить так: «Ми не завантажуємо й не копіюємо карткові дані на ноутбук, тому він не має бути включений до скоупу». Утім, для аудитора відсутність локальних файлів не є підставою для виключення. 

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

Зокрема, аудитор враховує дві критичні загрози:

Таким чином, навіть без збереження карткових даних на диск робоча станція безпосередньо впливає на безпеку CDE через активну сесію керування. Саме через цей вплив (security-impacting) аудитор кваліфікує її як системний компонент у межах скоупу.

Смартфон адміністратора

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

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

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

Наявність сертифіката відповідності (AoC) у хмарного провайдера не звільняє клієнта від проходження сертифікації власного середовища. Щоб розмежувати зони контролю, хмарні провайдери розробляють матрицю розподілу відповідальності (Shared Responsibility Matrix).

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

Репозиторії коду

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

Саме тому стандарт вимагає:

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

Легітимні способи зменшити межі аудиту

Зменшення скоупу — це не спроба приховати системи від аудитора, а цілеспрямована перебудова архітектури, яка усуває підстави для включення некритичних компонентів до меж аудиту. 

Сегментація мережі

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

Наявність VLAN (віртуальної локальної мережі) чи міжмережевого екрана сама по собі не доводить можливість виключення мережі з меж аудиту. Потрібне підтвердження — тестування на проникнення заходів сегментації: раз на 12 місяців (вимога 11.4.5), для сервіс-провайдерів — раз на 6 місяців (вимога 11.4.6), а також після значних змін у структурі мережевої ізоляції, які впливають на сегментацію. Пасивної перевірки конфігурацій недостатньо: фахівець із тестування на проникнення має спробувати обійти контролі захисту, які забезпечують сегментацію.

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

Інтеграційна шина даних

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

Інтеграційна шина даних (ESB) працює як посередник: приймає запит від інформаційної системи, розриває пряме з’єднання, перевіряє дані, виконує логіку й звертається до CDE під власним обліковим записом. Сама шина при цьому повністю включається в межі аудиту, а потоки даних обмежуються на її контрольованих інтерфейсах.

Завдяки відсутності прямого підключення, суміжні сервіси — наприклад, CRM (керування взаємовідносинами з клієнтами) або системи електронного документообігу — можна обґрунтовано вивести за межі скоупу. Утім, коректність такого архітектурного виключення остаточно підтверджує QSA-аудитор.

Чому межі аудиту потребують регулярного перегляду?

Стандарт вимагає документувати й підтверджувати межі перевірки щонайменше раз на 12 місяців (вимога 12.5.2), а для сервіс-провайдерів — раз на 6 місяців (вимога 12.5.2.1). Підтвердити межі — означає перевірити, чи відповідають діаграми, інвентаризація системних компонентів та перелік потоків карткових даних фактичному стану інфраструктури.

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

Оптимізація та точний розрахунок меж PCI DSS із фахівцями IT Specialist

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

Ми забезпечуємо комплексний супровід під час підготовки до сертифікації:

Готуєтеся до сертифікації або маєте сумніви, чи правильно визначено межі аудиту? Зверніться до IT Specialist — обговоримо поточний скоуп і можливі варіанти його скорочення.

Автор статті — Анастасія Кармазіна, провідний аудитор інформаційних технологій