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 и поддерживает стабильную конверсию и монетизацию при соблюдении требований брендов карт.