Юридические и регуляторные требования РФ (PCI-DSS)

Проект с приёмом банковских карт почти всегда несёт обязательства, которые не сводятся к «сделать checkout». Заметка закрывает вопрос как системному аналитику формализовать платёжный контур: PCI DSS через договоры с эквайерами и брендами, параллельно с точечной стыковкой 152-ФЗ, 149-ФЗ, 161-ФЗ и регламентов НСПК — в scope, НФТ, интеграционные контракты и трассировку до 02.04.02 Критерии приёмки (Acceptance Criteria). Это не обзор всей e-commerce-регуляторики РФ и не замена юриста или QSA.

1. Суть темы

PCI DSS (Payment Card Industry Data Security Standard) — набор требований PCI SSC (Payment Card Industry Security Standards Council) к защите account data: данных держателя карты (CHD, Cardholder Data) и чувствительных аутентификационных данных (SAD, Sensitive Authentication Data). Актуальная линейка — PCI DSS v4.0; конкретная версия и сроки перехода зависят от даты оценки и политики платёжных брендов — их фиксируют в контракте, а не «по умолчанию».

Для аналитика PCI DSS — регуляторный и договорной слой поверх НФТ — в духе трассируемых требований 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148). Он определяет:

• CDE (Cardholder Data Environment) — людей, процессы и технологии, которые хранят, обрабатывают или передают CHD/SAD либо влияют на их безопасность;
• scope — границу систем и процессов, попадающих под оценку соответствия;
• роль организации — merchant (торговец) или service provider (поставщик услуг), от чего зависит глубина контролей и формат отчётности (SAQ vs ROC).

Российский контекст накладывает параллельные обязательства — для каждой рамки SA фиксирует не «знаем закон», а артефакт и проверяемое требование (см. §3):

Соответствие 152-ФЗ не означает PCI compliance и наоборот — нужна согласованная матрица требований (структура — в §3). Общие принципы ИБ — в 08.07 Основы кибербезопасности для системного аналитика; здесь — платёжный контур и его формализация в артефактах анализа.

Граница темы — что внутри и что сознательно вне заметки:

flowchart TB
    subgraph layers [Параллельные слои требований]
        direction TB
        subgraph legal [Юридический и договорной]
            FZ149[149-ФЗ КИИ]
            FZ152[152-ФЗ ПДн]
            FZ161[161-ФЗ НПС]
            ACQ[Договор эквайера]
            NSPK[Регламенты НСПК]
        end
        subgraph pci [PCI DSS]
            CDE[CDE и scope]
            CHD[CHD / SAD]
            CTRL[12 требований / 6 целей]
        end
    end
    subgraph sa [Роль SA — сквозная формализация]
        DFD[DFD и C4]
        NFR[НФТ и AC]
        TRACE[Матрица трассировки]
    end
    legal --> TRACE
    pci --> TRACE
    sa --> DFD
    sa --> NFR
    DFD --> TRACE
    NFR --> TRACE

152-ФЗ и 149-ФЗ действуют независимо от PCI и часто шире CDE — SA трассирует их в одной матрице, а не выстраивает «сначала PCI, потом законы».

2. Ключевые понятия

Данные и среда

Роли и оценка соответствия

Merchant level (уровень 1–4) задаёт бренды по объёму транзакций; для Level 1 merchant, как правило, обязателен ROC (не SAQ). Точные пороги — в merchant program и service provider program бренда и в договоре эквайера; SA фиксирует целевой уровень и формат отчётности в BRD до разработки.

Выбор SAQ — не формальность: неверный тип — частая причина несоответствий на аудите. Упрощённая логика для discovery (детали — в SAQ Instructions PCI SSC; финальное решение — с QSA/ИБ):

Структура PCI DSS (логика для декомпозиции)

12 требований сгруппированы в 6 целей — рамка для разбиения на НФТ. Generic-контроли (RBAC, MFA, патчи, pen test) — в 08.07 Основы кибербезопасности для системного аналитика; здесь — payment-specific акценты:

В PCI DSS v4.0 часть требований имеет тип defined approach (шаблонная формулировка в SAQ), часть допускает customized approach (альтернативный контроль с обоснованием). Для SA в матрице трассировки полезна колонка «тип контроля v4.0»:

SA не подменяет ИБ в TDA, но помечает строки, где без артефакта ИБ приёмка требования невозможна.

PCI и смежные рамки — не путать

Сценарии приёма в РФ: «Мир» vs международные карты

3. Как применяется в работе аналитика

Откуда требования попадают в SDLC

Регуляторика не «появляется на этапе SRS» — её извлекают на старте:

1. Договор эквайера и приложения (security schedule, SLA, ограничения на хранение) — 02.02.03 Наблюдение и анализ документов; сверка с 10.04 Чеклист аналитика перед стартом разработки.
2. Карта стейкхолдеров: compliance банка, DPO, архитектор PSP, ИБ, DevOps — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).
3. Discovery-сессия с PSP — вопросы ниже; результат фиксируется в BRD до проектирования checkout.

Инициация и discovery

На старте зафиксируйте модель приёма платежей — без этого scope будет «плыть»:

• on-us / off-us, hosted payment page, redirect, API, mobile/in-app SDK, marketplace, подписки, recurring, возвраты и частичные refund;
• кто storage / processing / transmission для CHD;
• есть ли subcontractors (PCI service providers) — процессинг, хостинг, call-center, аналитика;
• какие схемы карт (см. таблицу в §2) и целевой SAQ/ROC.

Вопросы к PSP на discovery (дополните своим чеклистом):

• Актуальный AOC и тип SAQ/ROC провайдера; listed program для tokenization/P2PE.
• Data flow diagram провайдера: где PAN, кто subprocessors, где логи.
• Целевая версия PCI DSS и merchant level по брендам.
• Recurring / COF: кто хранит payment credential, MIT vs CIT, срок жизни токена.
• Refund API: какие идентификаторы проходят (token vs PAN), reconciliation, идемпотентность.
• Security schedule в договоре: обязанности merchant vs PSP, сроки уведомления об инцидентах.

Постройте контекстную диаграмму — 03.01.02 Моделирование контекста системы (Context Diagram) — и DFD с явной границей CDE: 03.04.02 Диаграмма потоков данных (DFD). Дополните 06.03.05 C4-модель: container-диаграмма покажет, какие сервисы «видят» PAN.

Целевое правило для спецификации: не хранить SAD; минимизировать CHD — только то, что нужно бизнесу и разрешено стандартом. На staging/test — только PCI test PAN ranges из документации брендов/эквайера, не prod-данные.

Recurring, подписки и stored credentials

Если в discovery есть recurring / подписки, scope почти всегда шире, чем у разового checkout:

Возвраты и частичные refund

В спецификации refund-потока явно укажите:

• передаётся token или снова PAN (второе расширяет CDE);
• reconciliation между order service, payment gateway и ledger;
• запрет логирования идентификаторов платежа в cleartext — те же правила, что для capture API (10.01.04 Шаблон спецификации REST API).

Российская регуляторика в артефактах SA

149-ФЗ и приказы ФСТЭК/ФСБ

SA не назначает класс защиты вместо аттестующего органа, но обязан зафиксировать в Vision&Scope / BRD:

• относится ли система с платёжным контуром к значимому объекту КИИ или иной категории по 149-ФЗ;
• перечень обязательных мер как НФТ со ссылкой на применимый приказ ФСТЭК/ФСБ (формулировки — согласование с ИБ);
• границу: меры 149-ФЗ могут шире CDE (вся ИС), PCI — только cardholder data environment.

152-ФЗ в платёжном контуре

В платёжном контуре SA выделяет только пересечение с checkout: PAN как ПДн, правовое основание обработки, локализация первичной БД при хранении, маскирование в UI, трассировка инцидента с ПДн в процесс (параллельно с PCI incident SLA). Трансграничная передача, уведомления Роскомнадзора, полный правовой режим — 11.06 Этические и правовые аспекты.

161-ФЗ и НСПК — что выписать из договора с банком

Согласованная матрица: PCI + 152-ФЗ + договор

Оформите по 10.01.15 Шаблон матрицы трассировки — одна таблица, без «двух правд» в разных документах:

Пример заполненной строки:

Декомпозиция PCI в требования

PCI переводится в проверяемые НФТ — см. 10.01.12 Шаблон нефункциональных требований (NFR) и 02.03.01 Классификация требований (БТ, ФТ, НФТ):

Для интеграций в user stories и API-спецификациях — 10.01.04 Шаблон спецификации REST API:

• запрет логирования PAN/CVV в application logs, APM, support-чатах;
• PCI-aware error messages — без утечки внутренних деталей CDE;
• маскирование в отчётах и UI.

В BRD или приложении к контракту — shared responsibility с PSP (Payment Service Provider):

• кто проходит SAQ/ROC;
• кто предоставляет AOC;
• инциденты с картами: SLA уведомления эквайера/брендов, эскалация, сохранение доказательств; параллельно — уведомление оператора ПДн по 152-ФЗ (сроки и роли — юрист + DPO, SA трассирует в 03.02.02 Диаграмма деятельности (Activity Diagram) и AC);
• какие данные остаются у merchant, какие — у провайдера.

Трассировка и риски

Свяжите регуляторику с реализацией через 10.01.15 Шаблон матрицы трассировки и 02.03.04 Трассировка требований (концепция):

Источник (PCI / 152-ФЗ / 149-ФЗ / договор) → НФТ → функция → AC / тест-кейс

Типовые риски на этапе анализа — 08.05 Управление рисками на этапе анализа:

• scope creep — новый микросервис «просто кэширует» PAN; см. 02.05.03 Управление объёмом (Scope Creep) и ожидания;
• копии prod-БД с CHD на staging без обезличивания (вместо них — test PAN ranges);
• support-доступ к prod CDE без процедуры и логирования;
• service provider без due diligence и AOC.

Проверка полноты — 08.03 Тестирование требований (статическое тестирование) и 08.04 Рецензирование и инспекции (техники Фейгана): рецензент с компетенцией ИБ задаёт вопрос «где в DFD проходит PAN?».

Артефакты и роли

SA не заменяет QSA или ИБ-офицера, но обеспечивает полноту, непротиворечивость и проверяемость требований — без «дыр» между бизнес-сценарием оплаты и тем, что попадёт в оценку соответствия.

Примеры потоков

Redirect vs own checkout:

sequenceDiagram
    participant User as Пользователь
    participant Shop as Магазин (merchant)
    participant PSP as PSP / hosted page

    User->>Shop: Оформление заказа
    Shop->>PSP: Redirect на hosted payment
    User->>PSP: Ввод PAN (CHD)
    PSP->>Shop: Token / статус платежа
    Note over Shop: PAN не проходит через сервер магазина — scope уже, но SAQ и MPS всё равно анализируются

При own checkout с JavaScript на домене merchant CHD может проходить через приложение или браузерные скрипты — scope шире, SAQ другой (часто A-EP или D), требования к MPS и CSP обязательны в спецификации.

Marketplace / split payments / несколько merchant ID:

• Платформа принимает оплату от покупателя, затем расщепляет выплату селлерам — у каждого селлера свой MID или sub-merchant ID.
• SA фиксирует цепочку ролей: кто merchant of record, кто service provider, чьи системы попадают в CDE каждого участника.
• В матрице — отдельные строки на платформу и на типового селлера; AOC процессинга платформы не снимает обязанностей селлера, если его backend «видит» PAN.
• Типовая ошибка: один SAQ на всю платформу при том, что часть селлеров ведёт own checkout — scope creep ролей; см. 02.01.04 Определение границ решения (Scope Modelling).

4. Типовые ошибки и ограничения

Ограничения

• PCI DSS — минимальный отраслевой базис. Банк или эквайер может требовать строже; в ТЗ указывайте целевую версию (v4.0 vs 3.2.1) и merchant level по контракту.
• Scope определяется фактом обработки, а не архитектурным лозунгом. Hosted-модель и mobile WebView не снимают анализа SAQ-типа и сценариев redirect/MPS.
• Tokenization сужает scope только при listed program PCI и AOC провайдера; самописный токен — не автоматический выход из CDE.
• «Только Мир» без международных брендов — PCI может не требоваться брендами, но банк часто навязывает PCI или security annex; снимайте из scope только по пункту договора.
• Пересечение с 152-ФЗ требует согласования с юристами — детали ПДн в 11.06 Этические и правовые аспекты.
• Реализация контролей (pentest, ASV, HSM, содержание TDA) — зона ИБ и DevOps; SA фиксирует интерфейсы, критерии и границы, а не подменяет экспертизу.
• 149-ФЗ / приказы ФСТЭК — SA фиксирует применимость и трассировку; выбор конкретных средств защиты — ИБ.

Типичные ошибки

Критерий качества спецификации: по документам можно ответить — где появляется PAN, кто storage/processing/transmission, какой SAQ/ROC обоснован, какие строки матрицы ведут к PCI, 152-ФЗ и договору эквайера, кто уведомляется при инциденте.

Связи с другими разделами базы

• Извлечение требований из договора эквайера на старте проекта — 02.02.03 Наблюдение и анализ документов: security schedule и SLA до проектирования checkout.
• Стейкхолдеры compliance-контура — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map): банк, DPO, PSP, ИБ.
• Payment-impacting change в релизном контуре — 07.06 CICD и конвейеры — влияние на требования, 05.04 DevOps и непрерывная поставка — влияние на анализ: gate перед деплоем checkout и payment API.
• Чеклист старта проекта с картами — 10.04 Чеклист аналитика перед стартом разработки: не пропустить scope и договорные обязательства.

Источники и дополнительные материалы

Стандарты и нормативные акты

• PCI Security Standards Council — PCI DSS: https://www.pcisecuritystandards.org/standards/pci-dss/
• PCI SSC — Document library (PCI DSS v4.0, SAQ, guidance): https://www.pcisecuritystandards.org/document_library/
• PCI SSC — Glossary of Terms, Abbreviations, and Acronyms: https://www.pcisecuritystandards.org/glossary/
• PCI SSC — SAQ Instructions and Guidelines: https://www.pcisecuritystandards.org/document_library/?document=saq
• PCI SSC — Merchant and Service Provider Programs (merchant level, AOC, due diligence): https://www.pcisecuritystandards.org/standards/
• Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации»: https://www.consultant.ru/document/cons_doc_LAW_61798/
• Федеральный закон № 152-ФЗ «О персональных данных»: http://www.consultant.ru/document/cons_doc_LAW_61801/
• Федеральный закон № 161-ФЗ «О национальной платёжной системе»: https://www.consultant.ru/document/cons_doc_LAW_102146/

Официальные ресурсы РФ

• Банк России — раздел «Национальная платёжная система»: https://www.cbr.ru/finmarkets/nps/
• Банк России — аналитика по НПС: https://www.cbr.ru/analytics/nps/
• НСПК (платёжная система «Мир»): https://www.nspk.ru/ — при сбое TLS-доступа используйте корпоративное зеркало или раздел ЦБ выше

Договорная документация (классы документов)

• Договор эквайринга / процессинга и приложение Security Schedule / Information Security Requirements — типовой источник PCI-версии, SAQ/ROC, SLA инцидентов и ограничений на хранение CHD (конкретные формулировки — у вашего банка, без универсального URL).

Перед публикацией перепроверьте актуальную редакцию PCI DSS v4.0, перечень SAQ, merchant level вашего эквайера и требования НСПК по официальным источникам.