PCI DSS: рівні та відповідність

1) Що таке PCI DSS і кому він потрібен

• приймаєте платежі за картками (прямо або через PSP/шлюз),
• обробляєте/зберігаєте/передаєте карткові дані (PAN, термін, CVV) або їх укорочені/шифровані форми,
• є провайдером послуг для інших мерчантів (хостинг, процесинг, анти-фрод, платіжна оркестрація тощо), якщо ви можете вплинути на безпеку даних карток.

Версія та терміни: актуальна версія - PCI DSS v4. 0. Вимоги v3. 2. 1 виведені з ужитку; «future-dated» пункти v4. 0 тепер діють. Нове в v4. 0: посилена MFA, «Customized Approach», таргетований ризик-аналіз частоти процедур, уточнення по сегментації і шифрування.

2) Рівні відповідності: мерчанти та провайдери послуг

2. 1 Мерчанти (торговці)

• Level 1: > 6 млн транзакцій/рік або була компрометація. Потрібно щорічний ROC (Report on Compliance) від QSA або внутрішній ISA при узгодженні, + квартальні ASV-скани.
• Level 2: ~ 1-6 млн/рік. Зазвичай - SAQ (самооцінка) + ASV-скани; деякі схеми/еквайєри можуть вимагати ROC.
• Level 3: ~ 20k-1 млн e-commerce/рік. Зазвичай - SAQ + ASV-скани.
• Level 4: нижче порогів L3. SAQ; вимоги можуть варіюватися по банку-еквайєру.

2. 2 Провайдери послуг (Service Providers)

Зазвичай 2 рівня; для Level 1 (великий об'єм/критична роль в ланцюжку) обов'язковий ROC від QSA, для Level 2 - SAQ-D SP (іноді - ROC на вимогу контрагентів/схем). У iGaming багато PSP/шлюзи/хостинг-партнери - SP Level 1.

3) SAQ vs ROC: Як вибрати

• SAQ A - тільки редирект/iframe/hosted fields; немає обробки/передачі/зберігання карт у вас.
• SAQ A-EP - e-commerce, де ваш сайт впливає на безпеку сторінки оплати (наприклад, хостит скрипти), але PAN вводиться в середовищі провайдера.
• SAQ B/B-IP - термінали/імпринтери без електронного зберігання; B-IP - підключені термінали.
• SAQ C-VT/C - віртуальні термінали/невеликі середовище обробки, без зберігання.
• SAQ P2PE - тільки PCI-сертифіковане P2PE-рішення.
• SAQ D (Merchant/Service Provider) - «широкий» варіант при будь-якій обробці/передачі/зберіганні, кастомних інтеграціях, оркестраторах і т.п.

Практика для iGaming: цільовий шлях - SAQ A/A-EP за рахунок PAN-safe потоків, токенізації та хостед-полів. Якщо у вас власні платіжні сервіси/вальт - зазвичай SAQ D або ROC.

4) Скопінг: що входить в CDE і як його звузити

CDE (Cardholder Data Environment) - системи, де обробляються/зберігаються/передаються карткові дані, і всі з'єднані/впливові сегменти.

• Hosted fields/iframe/TSP: введення PAN поза вашим доменом.
• Токенізація і network tokens: ваші сервіси оперують токенами, а не PAN.
• P2PE: шифрування «кінець-в-кінець» з сертифікованим рішенням.
• Сегментація мережі: жорсткі ACL, ізоляція CDE від решти середовища.
• Обов'язковий DLP і маскування логів, заборона дампів з PAN/CVV.

У v4. 0 додана гнучкість методів досягнення цілей, але докази ефективності і таргетований ризик-аналіз обов'язкові.

5) «12 вимог» PCI DSS v4. 0 (смислові блоки)

1. Мережеві захисту та сегментація (файрволи, ACL, ізоляція CDE).
2. Безпечна конфігурація хостів/пристроїв (харднінг, базові лінії).
3. Захист даних власників карток (зберігання PAN - тільки при необхідності, сильна криптографія).
4. Захист даних при передачі (TLS 1. 2 + та еквіваленти).
5. Антивірус/anti-malware і контроль цілісності.
6. Безпечна розробка і зміна (SDLC, SAST/DAST, контроль бібліотек).
7. Доступ за необхідністю (least privilege, RBAC).
8. Ідентифікація та автентифікація (MFA для адмін-і віддаленого доступу, паролі по v4. 0).
9. Фізична безпека (дата-центри, офіси, термінали).
10. Логування та моніторинг (централізація логів, незмінюваність, алерти).
11. Тестування безпеки (ASV-скани щоквартально, пентести щорічно і після змін, тест сегментації).
12. Управління політиками та ризиками (процедури, навчання, інцидент-респонс, ризик-оцінки, «Customized Approach» документи).

6) Обов'язкові активності та періодичність

ASV-скани (зовнішні) - щоквартально і після значущих змін.
Вразливості/патчинги - регулярні цикли (частоти обґрунтовуються TRA - targeted risk analysis).
Пентести (внутр ./зовн.) - щороку і після значущих змін; перевірка сегментації обов'язкова.
Журнали і моніторинг - безперервно, з ретенцією і захистом від модифікацій.
Навчання персоналу - при наймі і далі регулярно.
МФА - для всього адмінського і віддаленого доступу до CDE.
Інвентар систем/потоків даних - актуалізувати постійно.

7) SAQ-матриця вибору (коротко)

Тільки iframe/редирект, без PAN у вас → SAQ A.
E-commerce, ваш сайт впливає на сторінку оплати → SAQ A-EP.
Термінали/імпринтери → SAQ B/B-IP.
Віртуальний термінал → SAQ C-VT.
Невелика «карткова» мережа без зберігання → SAQ C.
P2PE-рішення → SAQ P2PE.
Інше/складне/зберігання/обробка → SAQ D (або ROC).

8) Артефакти та докази для аудиту

• Діаграми мережі та потоків даних, реєстр активів, реєстр постачальників, реєстр обліків/доступів.
• Політики/процедури: безпечна розробка, управління змінами, логування, інциденти, уразливості, ключі/крипто, віддалений доступ, резервні копії.
• Звіти: ASV, пентести (сегментація включно), скани вразливостей, результати поправок.
• Журнали/алерти: централізована система, незмінюваність, розбір інцидентів.
• Крипто-управління: KMS/HSM процедури, ротації, інвентар ключів/сертифікатів.
• Докази «Customized Approach» (якщо застосовували): цілі контролю, метод, метрики ефективності, TRA.
• Контури відповідальності від третіх осіб: AoC партнерів (PSP, хостинг, CDN, анти-фрод), матриця Shared Responsibility.

9) Проект досягнення відповідності (покроково)

1. Скопінг і GAP-аналіз: визначити CDE, суміжні сегменти, поточні розриви.
2. Швидкі виграші: PAN-safe потік (iframe/hosted fields), токенізація, заборона PAN в логи, закрити «зовнішні» крит-вразливості.
3. Сегментація та мережа: ізолювати CDE, mTLS, firewall-ACL, доступи по least-privilege, MFA.
4. Спостережуваність: централізоване логування, ретенція/ланцюжок збереження, алерти.
5. Управління вразливостями та кодом: SAST/DAST, патчі, SBOM, контроль залежностей.
6. Тести: ASV-скани, внутрішні/зовнішні пентести, перевірка сегментації.
7. Документи та навчання: процедури, IR-плейбуки, тренінги, записи навчання.
8. Вибір форми атестації: SAQ (тип) або ROC; узгодити з еквайєром/брендами.
9. Щорічний цикл: підтримка, докази, перегляд ризиків/частот, перепроходження.

10) Інтеграція з архітектурою iGaming

Платіжний оркестратор працює тільки з токенами; PAN не бачить.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC від кожного PSP.
Event-driven шина/DWH: ніяких PAN/CVV; маскування останніх 4 цифр; DLP-гейти в CI/CD.
Чеки за 3DS/SCA: зберігати тільки необхідні артефакти (ідентифікатори транзакцій), без чутливих даних.

11) Часті помилки

Логування PAN/CVV і невалідні маски.
«Тимчасова» прокладка PAN через внутрішні API/шини.
Відсутність тесту сегментації при пентесті.
Необгрунтована частота процедур (немає TRA по v4. 0).
Залежність від одного PSP без AoC і без fallback.
Невраховані «впливові» сегменти (адмін-jump-hosts, моніторинг, бекапи).

12) Чек-лист швидкого старту (iGaming)

• Перейти на hosted fields/iframe; прибрати введення PAN з ваших форм.
• Включити токенізацію/мережеві токени; виключити PAN з подій/логів.
• Провести скопінг CDE та ізоляцію сегмента (MFA, RBAC, mTLS).
• Налаштувати централізовані логи і алерти (незмінюваність, ретенція).
• Запустити ASV-скани, усунути критичні/високі.
• Провести пентести (внутр ./зовн.) + тест сегментації.
• Підготувати політики/процедури і докази виконання.
• Узгодити форму атестації з еквайєром (SAQ тип/ROC).
• Отримати і зберігати AoC всіх крит-постачальників.
• Вбудувати PCI-контролі в релізний цикл (SDLC, IaC-харднінг, DLP в CI/CD).

13) FAQ коротко

Чи потрібен QSA? Для ROC - так. Для SAQ часто достатньо самосертифікації, але багато еквайєрів/брендів можуть вимагати QSA/ASV-партнера.
Якщо ми не зберігаємо PAN? Все одно підпадаєте під PCI DSS, якщо приймаєте карти. Намагайтеся досягти SAQ A/A-EP.
3DS вирішує PCI? Ні, ні. 3DS - про автентифікацію; PCI - про захист даних.
Достатньо TLS? Ні, ні. Потрібні всі релевантні вимоги v4. 0, в тому числі процеси і докази.

14) Резюме

Для iGaming оптимальна стратегія - мінімізувати скоуп (PAN-safe, токенізація, hosted fields, P2PE там, де можливо), жорстко сегментувати CDE, автоматизувати логування/вразливості/пентести, зібрати повний пакет артефактів і вибрати коректну форму підтвердження (SAQ або ROC) за вашим рівнем. Це знижує ризик, прискорює інтеграції з PSP і підтримує стабільну конверсію і монетизацію при дотриманні вимог брендів карт.