PCI DSS: контроль и сертификация
1) Что такое PCI DSS и почему это важно для iGaming
PCI DSS — стандарт безопасности индустрии платежных карт (Visa/Mastercard/Amex/Discover/JCB). Для оператора iGaming он определяет технические и организационные меры защиты данных держателей карт (CHD), включая PAN и чувствительные аутентификационные данные (SAD). Несоответствие грозит штрафами, повышенными межбанковскими тарифами, отзывом мерчант-аккаунта и репутационным ущербом.
2) Роли, уровни и тип сертификации
Роли
Merchant (мерчант): принимает карты от игроков.
Service Provider: обрабатывает/хостит/хранит CHD для мерчантов (включая хостинг, платежную платформу, токенизацию).
Уровни (high level)
Уровни мерчанта 1–4: по годовым транзакциям; Level 1 обычно требует ROC (Report on Compliance) от QSA.
Уровни провайдера услуг 1–2: Level 1 — обязательный ROC.
Форматы оценки
ROC + AOC: полноценный отчет аудитора (QSA/ISA).
SAQ: самооценка по одному из типов (см. ниже), плюс внешний ASV-скан.
3) Область (Scope) и CDE: как сузить и управлять
CDE (Cardholder Data Environment) — любые системы/сети/процессы, которые хранят, обрабатывают или передают CHD/SAD.
Стратегии минимизации
1. Редирект/Hosted Payment Page (HPP): форма на стороне PSP → SAQ A (минимальный скоуп).
2. Direct Post/JS + your page (A-EP): ваша страница влияет на безопасность сбора → SAQ A-EP (шире).
3. Токенизация: обмен PAN на токен PSP/ваш токен-вальт; PAN у вас не хранится.
4. Сегментация сети: изолируйте CDE (VLAN/файрволы/ACL), сведите трафик к минимуму.
5. “No storage” политика: не хранить PAN/SAD; исключения — строго обоснованы.
4) Типы SAQ (сводно)
5) PCI DSS v4.0: ключевые темы
Customized Approach: допускает альтернативные контроли при доказанной эквивалентности (план, TRA, тестовое обоснование).
Targeted Risk Analysis (TRA): точечный риск-анализ для “гибких” требований (частоты процессов, мониторингов).
Аутентификация: MFA для админ- и удаленного доступа; сильные пароли/пасфразы; блокировки/таймауты.
Уязвимости и пэчи: регулярные сканы (внутр./внешние), ежеквартальный ASV, пентесты ежегодно и после значимых изменений.
Шифрование: в транзите (TLS 1.2+) и at rest; управление ключами (KMS/HSM), ротации, разделение ролей.
Логи и мониторинг: централизованные логи, защита от изменений (WORM/подпись), ежедневный обзор событий безопасности.
Сегментация/фаерволы/WAF: формальные правила, review, документированные топологии.
SDLC/изменения: dev/test/prod разделены, SAST/DAST/депенденси-сканы, управление секретами.
Инциденты: формальный IRP, учения, роли и контакт-лист, взаимодействие с PSP/банком-эквайером.
6) Данные карт: что можно/нельзя
CHD: PAN (+ необяз. имя, срок, сервис-код).
SAD (запрещено хранить после авторизации): CVV/CVC, полные магнитные дорожки, PIN-блоки.
Маскирование: отображение PAN с маской (обычно первые 6 и последние 4).
Токенизация/хранение: если храните PAN → шифрование, доступ по Need-to-Know, ключи отдельно, жесткие журналы.
7) Контрольные домены (практический чек-лист)
1. Сегментация CDE — отдельные подсети, deny-by-default, egress-контроль.
2. Инвентарь активов — все системы в CDE и связанные.
3. Харднинг — безопасные конфиги, отключение по умолчанию, базовые стандарты.
4. Уязвимости/патчи — процессы, SLA, подтверждения развертывания.
5. Журналирование — синхронизация времени, централизованные логи, WORM/подписи.
6. Доступы — RBAC/ABAC, MFA, SoD, JIT/PAM, offboarding ≤ 15 минут.
7. Криптография — TLS, KMS/HSM, ротация, раздельные роли crypto-custodians.
8. Разработка — SAST/DAST/DS/IaC, секрет-сканы, pipeline-подписи.
9. Сканирование ASV — ежеквартально и после изменений, “Pass” статусы хранить.
10. Пентесты — внеш./внутр. сеть и прилож., как минимум ежегодно.
11. IR-план — учения, war-room с PSP/эквайером, таймлайны.
12. Обучение — фишинг, secure coding, PCI-awareness для ролей.
13. Документы/процедуры — политика хранения/удаления PAN, журнал экспортов.
8) Взаимодействие с PSP/вендорами
Контракты: SLA по доступности/безопасности, DPIA/TPRM, право аудита, инцидент-уведомления ≤ 72 ч.
Техинтеграция: HPP/редирект по TLS, подписанные вебхуки, mTLS/ключи в KMS, ротации.
Ежеквартальный мониторинг: отчеты PSP (Attestation, сертификаты), ASV/пентест-выдержки, изменения SDK.
9) Документы соответствия
ROC (Report on Compliance): полный отчет QSA.
AOC (Attestation of Compliance): подтверждение соответствия (приложение к ROC/SAQ).
SAQ: выбранный тип самооценки (A, A-EP, D и т.д.).
ASV-отчеты: внешний скан сертифицированным провайдером.
Политики/процедуры: версии, владельцы, журналы изменений.
Доказательства: схемы сети, логи WORM, результаты тестов, тикеты.
10) Роли и RACI
11) Метрики (KPI/KRI)
ASV Pass Rate: 100% квартальных отчетов — “pass”.
Patch SLA High/Critical: ≥ 95% в срок.
Pentest Findings Closure: ≥ 95% High закрыто ≤ 30 дней.
MFA Coverage админов: 100%.
Log Integrity: 100% критичных систем с WORM/подписями.
Scope Reduction: доля платежей через редирект/токенизацию ≥ 99%.
Incidents: PCI-инциденты с уведомлением в срок — 100%.
12) Дорожная карта (8–12 недель до SAQ/ROC)
Недели 1–2: выбор модели приема платежей (HPP/токенизация), картирование CDE, схема сети, план сегментации, выбор SAQ/ROC.
Недели 3–4: харднинг, MFA, логи WORM, SDLC-сканы, ключи/KMS, политика хранения PAN (по умолчанию — не хранить).
Недели 5–6: ASV-скан #1, исправления; пентест (веб/сеть/вебхуки), IR-учение с PSP, финализация документации.
Недели 7–8: SAQ заполнение или аудит QSA (Stage-интервью, выборки), закрытие находок, подготовка AOC/ROC.
Недели 9–12 (опц.): “Customized Approach” и TRA, оптимизация сегментации, интеграция дашбордов KPI/KRI.
13) Чек-листы
Перед стартом приема карт
- Выбран путь без хранения PAN/SAD
- Редирект/iframe PSP или токенизация настроены
- Сегментация CDE, deny-by-default, WAF
- MFA/IGA/JIT/PAM для админов
- Логи (WORM, подписи, NTP) и дашборды
- ASV-скан пройден, пентест закрыт
- IR-план и контакты PSP/банка
Для ежегодной аттестации
- Обновлены схемы и список систем в CDE
- Пройдено 4 квартальных ASV, “pass” сохранены
- Пентест ≤ 12 мес. и после изменений
- Политики/процедуры актуальны, версии/владельцы
- Заполнен SAQ/получен ROC, выдан AOC
14) Частые ошибки и как их избежать
Сбор PAN на своей странице без должной защиты → SAQ A-EP/D. Используйте HPP/iframe от PSP.
Логи без защиты от изменений. Включите WORM/подписи и ежедневный обзор.
Нет сегментации — “вся сеть в CDE”. Жестко изолируйте платежный контур.
Хранение CVV/SAD. Запрещено после авторизации.
Неполные ASV/пентесты. Делайте после изменений и храните отчеты/ремедиации.
15) Интеграция с остальными разделами wiki
Связанные страницы: Парольная политика и MFA, RBAC/Least Privilege, Политика логов, Инциденты и утечки, TPRM и SLA, ISO 27001/27701, SOC 2 — для маппинга контролей и единого набора evidence.
TL;DR
Успех PCI DSS v4.0 = минимальный скоуп (HPP/токенизация) + жесткая сегментация CDE + MFA/логи WORM/шифрование/KMS + ASV ежеквартально, пентест ежегодно и после изменений + готовые документы SAQ/ROC/AOC. Это снижает затраты на аудит, ускоряет интеграции с PSP и делает платежный контур доказуемо безопасным.