Введение

PCI-DSS — единственная регуляция в периметре SwiftRide, где термин «CDE» (Cardholder Data Environment) конфликтует с термином «CDE» в смысле enterprise data governance (Critical Data Element). Это лексическая ловушка одновременно для авторов и аудиторов. В этом уроке «CDE-PCI» = Cardholder Data Environment; «CDE» без модификатора = Critical Data Element. Этот урок — фиксация PCI-DSS v4.0.1 (Jun 2024) с фокусом на следствия для данных и интеграцию в enterprise CDE programme.

Версии и effective dates

• v3.2.1 retired 31 Mar 2024.
• v4.0 published 31 Mar 2022, applicable 31 Mar 2024.
• v4.0.1 published June 2024; все новые assessments с 1 Jan 2025 используют v4.0.1.
• 51 из 64 future-dated requirements обязательны 31 Mar 2025.

Scope — что входит в CDE-PCI

CHD (Cardholder Data) — основной scope:

• PAN (Primary Account Number).
• Cardholder name.
• Expiry date.
• Service code.

SAD (Sensitive Authentication Data) — никогда не хранится post-authorization:

• Full track data (magnetic stripe / chip equivalent).
• CVV / CVC / CID (security code).
• PIN / PIN block.

Правило scope: люди, процессы, технологии, которые хранят / обрабатывают / передают CHD или SAD. Connected-to systems + security-impacting systems — также в периметре (например, AD, аутентифицирующий доступ к CDE-PCI).

Merchant levels (Visa / Mastercard)

SAQ типы: A, A-EP, B, B-IP, C-VT, C, P2PE, SPoC, D-Merchant, D-SP.

Новое в v4.x — материальные изменения

Customised Approach (Req. 12.3.2)

Альтернатива «defined approach»; entity может удовлетворить objective через alternative control, если задокументировано. Требует Targeted Risk Analysis (TRA). Не разрешено для SAQs. Полезно, когда defined control технически невыполним (например, legacy system) или альтернатива даёт equal-or-better protection.

Targeted Risk Analysis (TRA)

Entity задаёт frequency для recurring controls (например, quarterly user-access review может быть растянут до annual, если TRA оправдывает). Обязательно для customised control.

MFA в CDE-PCI (Req. 8.4 / 8.5)

Расширен с remote-only на все виды доступа (не только remote). Обязателен после 31 Mar 2025. Весь non-console administrative access + весь доступ к CDE-PCI требует MFA.

Password length (Req. 8.3.6)

Минимум 12 символов (8 только если система не поддерживает 12 — задокументировано).

Magecart controls (Req. 6.4.3 + 11.6.1)

Инвентарь скриптов payment-page + детектирование изменений / tamper. Драйвер — атаки e-skimming (кластер актёров Magecart). Subresource Integrity (SRI), client-side monitoring, JavaScript inventory + change-detection — все техники.

Scope-анализ SwiftPay

SwiftPay = внутренний кошелёк водителей + пассажиров; payouts через bank-partner. Вопрос — какие компоненты SwiftPay в scope CDE-PCI.

В периметре (хранение / обработка / передача CHD):

• Payment-page (если SwiftRide хостит checkout UI, принимающий card data) — CDE-PCI в периметре.
• Tokenisation service, принимающий CHD на ingress.
• Settlement reconciliation systems, обрабатывающие атрибуты card data.

Connected-to systems в периметре:

• Active Directory / Okta, аутентифицирующий пользователей CDE-PCI.
• Logging system, принимающая audit logs CDE-PCI.
• Backup systems, хранящие данные CDE-PCI.

Вне периметра (если правильно сегментировано):

• Мобильное приложение SwiftRide для пассажиров (использует tokenised card reference, не PAN).
• Marketing analytics (использует tokenised customer ID).
• Ride-matching service (использует driver / rider IDs, не CHD).

Стратегии сокращения scope:

• Hosted payment page (Stripe / PayPal Checkout) — аутсорс ingress CHD; SwiftRide обрабатывает tokens.
• Устройство P2PE (point-to-point encryption) — driver-side card reading encrypted device-to-acquirer.
• Network segmentation — VLAN CDE-PCI изолирован; firewall rules задокументированы; segmentation audited ежегодно.

Зрелый подход SwiftRide: Stripe-hosted checkout (CDE-PCI минимизирован); SwiftRide хранит только tokens + last-4 + BIN + expiry-month (для fraud + customer service); annual SAQ A scope (если объём e-commerce позволяет) или SAQ A-EP, если iframe hosted.

CDE-PCI vs enterprise CDE — различение

CDE PCI Council = Cardholder Data Environment = люди / процессы / технологии, хранящие / обрабатывающие / передающие CHD + connected-to systems.

Enterprise CDE = Critical Data Element (этот курс) = data element с материальным финансовым / регуляторным / операционным impact при ошибке.

Практически: у SwiftRide есть оба. PCI-DSS scope diagram = артефакт; CDE registry = артефакт; ссылки между ними. Cards-related CDE в enterprise registry помечены pci-relevant для поддержки двусторонней связи.

Anti-patterns

1. «Tokenisation = вне scope PCI-DSS» — частично верно; токены сами вне scope, но token-to-PAN mapping vault = в периметре; ingress point, обрабатывающий PAN до tokenisation, = в периметре.
2. «SOC 2 от вендора = PCI compliance» — разные frameworks; SOC 2 = Trust Services Criteria; PCI-DSS = specific requirements. У вендора должен быть AOC (Attestation of Compliance) PCI-DSS, не только SOC 2.
3. «P2PE устраняет весь PCI scope» — P2PE значительно сокращает scope, но не устраняет. P2PE device + key-management + decryption point = в периметре (обычно vendor managed).
4. «v3.2.1 ещё применяется для legacy assessments» — v3.2.1 retired 31 Mar 2024; все новые assessments используют v4.0.1.

Резюме

• PCI-DSS v4.0.1 published Jun 2024; v3.2.1 retired 31 Mar 2024; 51 из 64 future-dated requirements обязательны 31 Mar 2025.
• Scope — CHD (PAN, name, expiry, service code) + SAD (track, CVV, PIN). Connected-to + security-impacting systems также в периметре.
• Merchant levels L1–L4 — объём транзакций; L1 = annual ROC от QSA.
• SAQ типы A до D-SP в зависимости от модели обработки.
• Новые материальные требования v4.x — Customised Approach + TRA; MFA для всего доступа к CDE-PCI; 12-char passwords; Magecart controls (6.4.3 + 11.6.1).
• Стратегия SwiftPay — Stripe-hosted checkout (минимальный scope), хранятся токены + last-4 + BIN + expiry.
• CDE-PCI ≠ enterprise CDE — разные концепции; CDE-PCI = scope diagram; CDE = registry. Поддерживать двусторонние ссылки.