PCI DSS: що це, кому потрібно виконувати стандарт і які 12 вимог він містить

Що таке PCI DSS і хто його встановлює

PCI DSS (Payment Card Industry Data Security Standard) це стандарт безпеки даних платіжних карток. Його розробляє і підтримує PCI Security Standards Council, організація, яку заснували великі платіжні системи, зокрема Visa, Mastercard, American Express, Discover і JCB. Чинна версія стандарту PCI DSS v4.0.1 опублікована в червні 2024 року. Вона уточнила формулювання версії 4.0 без додавання нових вимог.

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

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

Кому потрібно виконувати PCI DSS

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

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

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

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

12 вимог PCI DSS v4.0.1

Стандарт організований у шість цілей і дванадцять основних вимог. Кожна вимога містить десятки підвимог з детальними процедурами перевірки. Ось короткий перелік:

• 1. Встановлювати і підтримувати засоби контролю мережевої безпеки.
• 2. Застосовувати безпечні конфігурації до всіх системних компонентів.
• 3. Захищати збережені дані облікових записів.
• 4. Захищати дані власників карток сильною криптографією під час передавання відкритими публічними мережами.
• 5. Захищати всі системи і мережі від шкідливого програмного забезпечення.
• 6. Розробляти і підтримувати безпечні системи та програмне забезпечення.
• 7. Обмежувати доступ до системних компонентів і даних за принципом службової необхідності.
• 8. Ідентифікувати користувачів і автентифікувати доступ до системних компонентів.
• 9. Обмежувати фізичний доступ до даних власників карток.
• 10. Реєструвати та відстежувати весь доступ до системних компонентів і даних.
• 11. Регулярно тестувати безпеку систем і мереж.
• 12. Підтримувати інформаційну безпеку організаційними політиками і програмами.

Що змінилося після 31 березня 2025 року

Версія 4.0 містила понад п'ятдесят нових вимог, позначених як перспективні (future-dated). До 31 березня 2025 року вони вважалися найкращою практикою, а з цієї дати стали обов'язковими. Саме вони сьогодні найчастіше стають причиною невідповідностей.

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

Окремо варто згадати підхід до валідації. Версія 4 дозволяє, крім традиційного визначеного підходу, використовувати індивідуальний підхід (customized approach), коли організація досягає мети вимоги власним способом і доводить це. Цей шлях вимагає зрілих процесів і детальної документації, тому малому бізнесу він зазвичай не підходить.

Рівні, SAQ і QSA: як підтверджується відповідність

Спосіб підтвердження залежить від рівня, який визначає платіжна система за обсягом транзакцій. Великі торговці і постачальники послуг зазвичай проходять щорічну перевірку кваліфікованим аудитором безпеки (QSA) і отримують звіт про відповідність (Report on Compliance, ROC) та атестацію (Attestation of Compliance, AOC). Деякі організації можуть використовувати внутрішнього аудитора, що пройшов навчання PCI SSC (ISA).

Менші торговці заповнюють опитувальник самооцінки (Self-Assessment Questionnaire, SAQ). Тип SAQ залежить від того, як ви приймаєте платежі:

• SAQ A: усі функції обробки карток повністю передано сертифікованому провайдеру, наприклад через переадресацію або iframe.
• SAQ A-EP: сайт торговця впливає на безпеку платежу, наприклад формує платіжну форму, хоча дані надходять безпосередньо провайдеру.
• SAQ B і B-IP: автономні термінали або термінали з IP-підключенням без електронного зберігання даних.
• SAQ C і C-VT: платіжні застосунки, підключені до інтернету, або ручне введення через віртуальний термінал.
• SAQ P2PE: використання валідованого рішення з наскрізним шифруванням.
• SAQ D: усі інші випадки, окремі версії для торговців і для постачальників послуг.

Що перевіряє аудитор: приклади доказів

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

Найчастіше запитують такі матеріали:

• Схема мережі та діаграма потоків даних власників карток з позначеними межами середовища.
• Інвентар системних компонентів у межах обсягу і стандарти їх безпечної конфігурації.
• Звіти квартальних сканувань ASV з успішним результатом і звіти внутрішніх сканувань.
• Звіт про тестування на проникнення, включно з перевіркою ефективності сегментації.
• Налаштування MFA і списки користувачів з доступом до середовища даних карток.
• Записи про перегляд журналів подій і реагування на сповіщення.
• Інвентар скриптів платіжної сторінки з обґрунтуванням потреби кожного скрипта.
• Атестації відповідності від постачальників послуг і матриця розподілу відповідальності.
• План реагування на інциденти і записи про навчання персоналу з обізнаності щодо безпеки.

Типові помилки, через які компанія не проходить перевірку

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

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

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

Як підготуватися: практичний порядок дій

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

Далі визначте свій рівень і тип SAQ разом з еквайром, отримайте атестації від постачальників, складіть матрицю розподілу відповідальності і закрийте прогалини: сегментацію, MFA, журналювання, скрипти платіжної сторінки, сканування ASV. Після цього заповніть SAQ або підготуйтеся до аудиту QSA. Пам'ятайте, що PCI DSS вимагає постійного виконання, а не разової підготовки: перегляди, сканування і тестування мають відбуватися за графіком протягом усього року.

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

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