Проект

Общее

Профиль

Действия
История

Sidebar »

PCI DSS

Введение

Среди всех стандартов, рассматриваемых в этом курсе, PCI DSS занимает особое место: это единственный стандарт, нарушение которого влечёт прямые финансовые санкции — вплоть до полного лишения права принимать платёжные карты. Для интернет-магазина или банка это означает прекращение бизнеса.

PCI DSS не выбирают как ISO 27001 — его применяют обязательно все, кто хранит, обрабатывает или передаёт данные платёжных карт. Аудит по PCI DSS — это не подтверждение зрелости, а допуск к работе с платёжной инфраструктурой.

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности данных платёжной индустрии, разработанный Советом PCI SSC (основатели — Visa, Mastercard, American Express, Discover, JCB). Текущая версия — PCI DSS v4.0.1 (2022), пришедшая на смену v3.2.1. Переходный период завершился в марте 2025 года.

Эта тема опирается на методологию аудита из тем ISO 19011 и Методы проведения аудита, на технический аудит из темы Технический аудит и пентест — пентест в PCI DSS обязателен и строго регламентирован. Таблица соответствия PCI DSS ↔ ISO 27001 ↔ COBIT приведена в теме COBIT.

История стандарта

С 1988 по 1998 год Visa и MasterCard отчитались о потерях в 750 млн долларов из-за мошеннических операций с картами. Сумма казалась терпимой на фоне сотен миллиардов ежегодного оборота — до появления интернета. Чем больше магазинов подключало онлайн-оплату, тем легче злоумышленникам было похищать платёжные данные с плохо защищённых систем.

В октябре 1999 года Visa запустила CISP — первый отраслевой стандарт безопасности для торговых точек, принимающих онлайн-транзакции. По данным CyberSource, к 2000 году потери от карточного мошенничества в интернете достигли 1,5 млрд долларов (утроение за десятилетие), а в 2001-м уровень онлайн-мошенничества уже в четыре раза превышал уровень по обычным транзакциям.

В июле 2004 года атаки на веб-инфраструктуру (IIS и другое уязвимое ПО) распространились повсеместно: злоумышленники внедряли кейлоггеры и трояны для кражи платёжных данных. 15 декабря 2004 года пять крупнейших платёжных брендов — Visa, MasterCard, American Express, JCB и Discover — опубликовали PCI DSS, первый унифицированный стандарт безопасности, поддержанный всей индустрией.

Одновременно была создана независимая организация PCI SSC, которой передали дальнейшее развитие стандарта. С тех пор вышло несколько мажорных версий:

Версия Год Ключевые изменения
1.0 2004 Первая публикация
1.1 2006 Требование 6.6: WAF или code review для веб-приложений
2.0 2010 Уточнение области, виртуализация
3.0 2013 Управление рисками как непрерывный процесс
3.2 2016 MFA для административного доступа к CDE
3.2.1 2018 Устаревание TLS 1.0/1.1
4.0 2022 Гибкий подход к выполнению требований, усиление аутентификации, новые требования к e-commerce
4.0.1 2024 Корректировки и уточнения к версии 4.0

Текущая актуальная версия — PCI DSS v4.0.1 (2024). Версия 3.2.1 официально выведена из действия в марте 2024 года.

Серия стандартов PCI SSC

PCI SSC выпускает несколько стандартов, охватывающих весь процесс обработки данных платёжных карт:

Стандарт Расшифровка Область применения
PCI DSS Data Security Standard Безопасность инфраструктуры и процессов при хранении, обработке и передаче данных карт
PCI SSF Software Security Framework Безопасная разработка платёжных приложений (заменил PA-DSS)
PCI PTS PIN Transaction Security Проектирование аппаратного обеспечения/устройств, защита от несанкционированного вмешательства и криптографические функции.
PIN Security PIN Security Requirements Операционные меры контроля, сетевая безопасность и безопасное управление ключами.
PCI 3DS 3-D Secure Безопасность протокола 3-D Secure для аутентификации плательщика
PCI ASV Approved Scanning Vendor Требования к поставщикам услуг внешнего сканирования уязвимостей
PCI P2PE Point-to-Point Encryption Шифрование данных карты от точки приёма до процессора
PCI TSP Token Service Provider Безопасность токенизации карточных данных

PCI SSF

SSF пришёл на смену PA-DSS в 2019 году и состоит из двух стандартов:
  • SSS — требования к безопасной разработке платёжных приложений (SDL, управление уязвимостями, защита данных на уровне кода).
  • SLC — требования к процессам SDLC организации-разработчика.

PCI PTS

PTS распространяется на физические устройства приёма платежей: POS-терминалы, банкоматы, устройства незащищённого ввода PIN (UPID). Стандарт определяет требования к физической защите, криптографии и ключевому менеджменту.

PIN Security

PIN Security Requirements — отдельный стандарт для организаций, обрабатывающих PIN-коды в сети: требования к генерации, распределению, хранению и уничтожению криптографических ключей (управление ключами HSM).

PCI 3DS

Распространяется на серверы трёхдоменного протокола (3DS Server, Directory Server, ACS) — компоненты, обеспечивающие аутентификацию держателя карты при онлайн-платеже через одноразовые пароли, push-уведомления или биометрию. Версия протокола 3-D Secure 2.x существенно улучшила UX по сравнению с первой версией (redirect на страницу банка заменён нативным вызовом).

ASV

ASV-сканирование — автоматизированная проверка всех точек подключения информационной инфраструктуры к сети Интернет с целью выявления уязвимостей. Согласно требованиям PCI DSS, такую процедуру следует выполнять ежеквартально силами сертифицированного вендора. ASV — не аудитор, а поставщик сервиса сканирования; его сертификация проводится PCI SSC по отдельной программе.

Как устроена платёжная карта: BIN, структура номера и алгоритм Луна

Структура номера карты

PAN — номер платёжной карты, как правило, от 13 до 19 цифр (наиболее распространён 16-значный формат). Номер несёт в себе три информационных блока:

  1. MII + BIN/IIN (6 цифр). Первая цифра — MII — указывает на индустрию эмитента. Первые 6 цифр в совокупности образуют BIN, также называемый IIN. По BIN процессинг определяет, в какой банк направить авторизационный запрос. С 2022 года PCI SSC переходит на 8-значный BIN.
  2. Индивидуальный номер счёта (9 или 12 цифр) — уникальный идентификатор карты у конкретного эмитента.
  3. Контрольная цифра (последняя цифра) — вычисляется по алгоритму Луна; позволяет быстро обнаружить опечатку в номере.

Алгоритм Луна

Алгоритм Луна (алгоритм mod 10) — простой метод контрольной суммы, предложенный учёным IBM Хансом Петером Луном в 1954 году. Используется для первичной проверки корректности номера карты ещё до отправки запроса эмитенту, то есть на стороне клиента или торговой точки.

Алгоритм не является криптографическим: он выявляет случайные ошибки ввода, но не защищает от намеренной подделки.

Порядок проверки:
  1. Начать с последней цифры (контрольной) и двигаться влево.
  2. Каждую вторую цифру (считая от контрольной) умножить на 2; если результат ≥ 10 — вычесть 9.
  3. Сложить все цифры.
  4. Если сумма делится на 10 без остатка — номер прошёл проверку Луна.

Важно для области PCI DSS: PAN является защищаемым элементом CHD. Даже усечённый PAN (первые 6 + последние 4 цифры) требует защиты в соответствии с требованиями стандарта.

Область применения: концепция CDE

Что такое CDE

CDE — среда данных держателей карт. Это совокупность людей, процессов и технологий, которые хранят, обрабатывают или передают данные держателей карт или чувствительные аутентификационные данные.

CHD включает:
  • PAN (номер карты) — основной защищаемый элемент;
  • имя держателя карты;
  • срок действия карты;
  • сервисный код.
SAD включает:
  • полные данные магнитной полосы (трек 1, трек 2);
  • PIN и PIN-блоки;
  • CVV2 / CVC2 / CAV2 / CID (трёхзначный код с обратной стороны карты).

Критически важное правило: SAD запрещено хранить после авторизации транзакции — даже в зашифрованном виде. CHD можно хранить, но только при выполнении всех требований PCI DSS к защите.

Что входит в scope

В область применения PCI DSS попадают все системные компоненты, которые:
  • хранят, обрабатывают или передают CHD / SAD — прямо входят в CDE;
  • подключены к системам CDE — могут влиять на её безопасность;
  • обеспечивают безопасность CDE: серверы аутентификации, межсетевые экраны, системы мониторинга.
Конкретные категории компонентов:
  • Сетевые компоненты: файрволы, коммутаторы, маршрутизаторы, WAF, точки беспроводного доступа.
  • Серверы: веб, приложений, БД, аутентификации, DNS, NTP, почтовые, прокси.
  • Конечные устройства: POS-терминалы, банкоматы, АРМ операторов.
  • Компоненты виртуализации: гипервизоры, виртуальные коммутаторы, контейнеры.
  • Приложения: платёжные, внутренние системы учёта, ПО для обработки транзакций.
  • Облачные сервисы, если в них обрабатываются данные карт.

Сегментация и её влияние на область аудита

Правильная сегментация сети позволяет изолировать CDE от остальной инфраструктуры и тем самым сократить область аудита PCI DSS. Если CDE надёжно изолирована, проверяется только она, а не вся сеть организации.

Неэффективная сегментация — одна из наиболее частых значительных находок при аудите PCI DSS. Формально сегментация задокументирована, но технически трафик между CDE и остальной сетью не ограничен должным образом.

Наиболее распространённые подходы к сегментации:
  • Выделенный VLAN / сеть для платёжных систем с запрещающими правилами на межсетевом экране.
  • Токенизация — замена PAN на случайный токен, который не представляет ценности за пределами системы-эмитента токена.
  • P2PE — шифрование данных карты с момента ввода в терминале; процессинг получает только зашифрованный блок, и промежуточные системы не видят CHD.

Аудитор обязан проверить эффективность сегментации — это одно из ключевых требований PCI DSS v4.0.1. Способы проверки: сканирование из-за пределов CDE в сторону CDE (допустимый трафик должен быть строго ограничен), тестирование на проникновение с попыткой преодолеть сегментацию, анализ правил межсетевых экранов.

Схема платёжной транзакции

Транзакция по карте проходит через три домена:

  • Домен эмитента — банк, выпустивший карту, и держатель карты.
  • Домен взаимодействия — торговая точка (мерчант) и международная платёжная система (МПС: Visa, Mastercard, «Мир»).
  • Домен эквайера — банк, обслуживающий расчётный счёт мерчанта, и платёжный шлюз / процессор.

Упрощённый порядок авторизации (стрелки ① – ⑧ на схеме):

  1. ① Держатель карты предъявляет карту / вводит данные на сайте.
  2. ② Мерчант (POS-терминал или платёжный шлюз) формирует авторизационный запрос и направляет его эквайеру.
  3. ③ Эквайер передаёт запрос через сеть МПС.
  4. ④ МПС маршрутизирует запрос в банк-эмитент.
  5. ⑤ Эмитент проверяет карту, лимиты, риски и возвращает ответ (approve / decline).
  6. ⑥ Ответ возвращается через МПС к мерчанту.
  7. ⑦ Мерчант получает подтверждение и выдаёт покупателю чек.
  8. ⑧ В конце операционного дня проходит клиринг — взаиморасчёты между эмитентом и эквайером через МПС.

Время авторизации в современных системах — менее 1–2 секунд. Клиринг и расчёт (фактическое перемещение денег) занимают, как правило, 1–3 рабочих дня.

Ключевые участники с точки зрения PCI DSS: мерчант, эквайер, процессор, платёжный шлюз, поставщик услуг — каждый обязан соблюдать требования стандарта в части, касающейся его.

Требования PCI DSS

PCI DSS v4.0.1 содержит 12 требований, сгруппированных в 6 целей. Версия 4.0 добавила более 60 новых и изменила более 50 существующих требований.

ЦЕЛЬ ГРУППЫ ТРЕБОВАНИЙ PCI DSS
Создание и поддержка защищённой сети и систем Требование 1
Установить и поддерживать сетевые средства защиты
Требование 2
Применять безопасные конфигурации ко всем системным компонентам
Защита данных держателей карт Требование 3
Защищать хранимые данные держателей карт
Требование 4
Защищать данные держателей карт при передаче по открытым публичным сетям
Управление уязвимостями Требование 5
Защищать все системы и сети от вредоносного ПО
Требование 6
Разрабатывать и поддерживать безопасные системы и ПО
Меры контроля доступа Требование 7
Ограничивать доступ к системным компонентам и данным карт по принципу необходимости
Требование 8
Идентифицировать пользователей и аутентифицировать доступ к системным компонентам
Требование 9
Ограничивать физический доступ к системным компонентам
Мониторинг и тестирование Требование 10
Вести журналы и мониторинг всего доступа к сетевым ресурсам и данным держателей карт
Требование 11
Регулярно тестировать безопасность систем и сетей
Управление информационной безопасностью Требование 12
Обеспечивать информационную безопасность с помощью организационных политик и программ

Пример требований с детализацией

Требование 8: Аутентификация — детали

Требование 6: Безопасная разработка — детали

Подход «Customized» в v4.0

PCI DSS 4.0 вводит два пути соответствия:
  • Defined approach — классический путь: выполнить требование точно так, как оно сформулировано.
  • Customized approach — альтернативный путь: организация самостоятельно определяет контрмеры, достигающие той же цели безопасности. Требует более глубокого документирования и согласования с аудитором.

Кто обязан соблюдать стандарт

Главное правило: если организация хранит, обрабатывает, передаёт данные держателей карт или влияет на их безопасность — PCI DSS обязателен.

Все организации делятся на две категории:

Торгово-сервисное предприятие (ТСП или мерчант) — организация, принимающая платёжные карты в оплату товаров и услуг (магазины, рестораны, интернет-магазины, АЗС и пр.).
Поставщик услуг — организация, оказывающая услуги, связанные с обработкой транзакций (дата-центры, хостинг-провайдеры, платёжные шлюзы, процессоры, МПС и т. д.).

Уровни мерчантов

Уровень Критерий (транзакций Visa/MC в год) Форма подтверждения
Level 1 > 6 млн Ежегодный аудит QSA + ежеквартальный ASV
Level 2 1–6 млн Ежегодный SAQ + ежеквартальный ASV
Level 3 20 000 – 1 млн (e-commerce) Ежегодный SAQ + ежеквартальный ASV
Level 4 < 20 000 (e-commerce) или до 1 млн (прочие) Ежегодный SAQ, ASV — по усмотрению банка

Уровни поставщиков услуг

Уровень Критерий Форма подтверждения
Level 1 > 300 000 транзакций в год или признан МПС системно значимым Ежегодный аудит QSA + ежеквартальный ASV
Level 2 < 300 000 транзакций в год Ежегодный SAQ + ежеквартальный ASV

Формы подтверждения соответствия

Существуют три типа подтверждения:

Форма Кто проводит Результат
QSA Внешняя аудиторская организация, сертифицированная PCI SSC Отчёт о соответствии ROC
ISA Внутренний аудитор, прошедший обучение и сертификацию по программе PCI SSC; только если QSA-аудит уже был проведён ROC внутренней подготовки
SAQ Самостоятельно; различных типов в зависимости от среды обработки данных Заполненный лист самооценки SAQ + AOC

Типы SAQ

SAQ делится на несколько типов в зависимости от схемы обработки карт:

Тип SAQ Кому применяется
SAQ A Мерчанты, полностью отдавшие приём карт на аутсорс (iframe, редирект); CHD не проходит через их системы
SAQ A-EP Мерчанты с собственной страницей оплаты, использующей внешний процессор через JavaScript
SAQ B Мерчанты с физическими терминалами (imprinter или dial-up), без хранения электронных данных
SAQ B-IP Мерчанты с IP-терминалами, подключёнными к процессору
SAQ C Мерчанты с платёжными приложениями, подключёнными к Интернету
SAQ C-VT Мерчанты, вводящие данные вручную через веб-интерфейс процессора
SAQ D Все остальные мерчанты и поставщики услуг (полный набор требований)
SAQ P2PE Мерчанты, использующие сертифицированные P2PE-решения

ASV-сканирование — автоматизированная проверка всех точек подключения информационной инфраструктуры к сети Интернет с целью выявления уязвимостей. Согласно требованиям PCI DSS, такую процедуру следует выполнять ежеквартально.

Документация по результатам аудита PCI DSS

ROC

ROC — полный отчёт о соответствии, составляемый QSA по итогам аудита уровня 1. Это не произвольный документ, а строго структурированный отчёт по шаблону PCI SSC (ROC Reporting Template), обязательному для всех QSA-компаний.

Структура ROC охватывает все 12 требований PCI DSS. Для каждой из более чем 250 тестовых процедур аудитор заполняет стандартизированную карточку:

Поле Содержание
Метод тестирования Один или несколько из трёх: Examine (изучить), Interview (интервью), Observe (наблюдать)
Что проверялось Конкретный документ, система, сотрудник или процесс
Результат In Place / Not In Place / Not Applicable / Not Tested
Свидетельства Ссылка на конкретное доказательство: имя файла, скриншот, имя интервьюируемого
Примечания Детализация, исключения, применение Customized Approach

Например, для тестовой процедуры 8.4.2 «MFA для всего доступа в CDE» карточка может выглядеть так: метод — Examine + Interview; что проверялось — конфигурация Azure AD, список учётных записей с доступом в CDE, интервью с администратором IAM; результат — Not In Place (три сервисные учётные записи без MFA); свидетельства — скриншот консоли Azure AD от 12.05.2025, Приложение 14.

Компоненты ROC:

Исполнительное резюме — краткий обзор для руководства и платёжных систем: область аудита, дата, итоговый вердикт, критические несоответствия.

Описание проверяемой среды — детальная карта CDE: сетевые диаграммы, перечень всех компонентов, схема потоков данных карт (Cardholder Data Flow Diagram). Именно этот раздел подтверждает, что аудитор правильно определил область и не пропустил системы, обрабатывающие CHD.

Детальные результаты по всем требованиям — основной массив ROC, занимающий сотни страниц для крупной организации. Каждое из 12 требований разбито на под-требования и далее на тестовые процедуры. Аудитор документирует каждую процедуру независимо — нельзя написать «требование 8 выполнено» без детального подтверждения каждой тестовой процедуры.

Перечень компенсирующих мер — если организация применяет компенсирующие меры вместо отдельных требований, каждая из них документируется в отдельном рабочем листе (Compensating Control Worksheet) с обоснованием, почему стандартное требование технически или операционно невыполнимо, и описанием альтернативной меры.

Документация Customized Approach — для каждого требования, выполненного через персонализированный подход, прилагается Customized Approach Worksheet с целевым анализом рисков и описанием альтернативных контролей.

После подписания ROC аудитором и руководством организации документ передаётся банку-эквайеру или непосредственно платёжной системе. Сами платёжные системы (Visa, Mastercard) ROC, как правило, не получают — только AOC.

ROC — конфиденциальный документ. Он содержит детальную карту всей платёжной инфраструктуры организации, включая уязвимости и несоответствия. Передача ROC третьим сторонам возможна только с явного согласия проверяемой организации.

AOC

AOC — краткое официальное подтверждение соответствия. Занимает несколько страниц, в отличие от ROC объёмом в сотни страниц.

AOC подписывается двумя сторонами: QSA (подтверждает, что аудит проведён по методологии PCI DSS и выводы корректны) и уполномоченным представителем проверяемой организации (подтверждает достоверность предоставленных сведений).

AOC содержит: идентификационные данные организации и QSA-компании; область аудита (перечень проверенных систем и подразделений); итоговый статус соответствия — Compliant / Non-Compliant; дату и срок действия сертификата соответствия; список платёжных приложений и поставщиков услуг в области аудита.

Именно AOC — а не ROC — является публичным документом соответствия. Банк-эквайер хранит AOC в деле мерчанта; при заключении новых договоров эквайринга мерчант предоставляет AOC партнёрам. В отличие от ROC, AOC не раскрывает деталей инфраструктуры.

SAQ

Самооценка для организаций уровней 2–4, где независимый аудит QSA не требуется. Форма SAQ определяется способом приёма платежей — подробная таблица с типами SAQ приведена выше в разделе об уровнях соответствия.

Независимо от выбранной формы, по итогам SAQ также составляется AOC — только подписывается не QSA, а уполномоченным представителем организации, берущим на себя ответственность за корректность самооценки.
Аудитор при проверке SAQ-организации проверяет корректность выбранной формы SAQ: часто организации выбирают более простую форму, не соответствующую их реальным процессам.

Специфика сбора свидетельств в PCI DSS

PCI DSS v4.0 вводит три официальных метода тестирования, которые аудитор обязан использовать и документировать для каждой тестовой процедуры.

Examine (Изучить) — анализ документов, конфигураций, журналов, отчётов. Эквивалент «анализа документов» по ISO 19011.

Interview (Провести интервью) — опрос персонала для подтверждения понимания процедур и их фактического выполнения. Эквивалент «интервью» по ISO 19011.

Observe (Наблюдать) — непосредственное наблюдение за выполнением процессов и состоянием систем. Эквивалент «наблюдения» по ISO 19011.

Для каждой тестовой процедуры ROC указывается, какие методы применялись и что конкретно было изучено, с кем проведено интервью, что наблюдалось. Это прямое воплощение принципа доказательного подхода из ISO 19011.

PCI DSS и российский контекст

Международные платёжные системы. Организации, принимающие Visa, Mastercard, American Express на территории России, обязаны соответствовать PCI DSS. Требования предъявляются банком-эквайером как условие договора эквайринга.

НСПК «Мир». Национальная система платёжных карт имеет собственные требования безопасности, разработанные с учётом PCI DSS, но не идентичные ему. Аудит по требованиям НСПК проводится по отдельным правилам.

Совмещение с другими стандартами. Финансовые организации часто проходят одновременно аудит по PCI DSS и оценку по ГОСТ 57580. Требования частично перекрываются, особенно в части управления уязвимостями, мониторинга и контроля доступа. При совмещённом аудите используется матрица соответствия требований.

Последствия несоответствия

Несоответствие PCI DSS не является нарушением закона само по себе, однако влечёт серьёзные последствия через договорные отношения с платёжными системами:

  • Штрафы от МПС — от 5 000 до 100 000 долларов в месяц за несоответствие; размер зависит от уровня организации и длительности нарушения.
  • Повышенные interchange-комиссии — МПС вправе поднять ставку комиссии для организаций, не подтвердивших соответствие.
  • Компенсации при утечке данных — в случае инцидента организация несёт расходы на forensic-расследование (проводится QSA), замену карт, компенсации банкам-эмитентам.
  • Отзыв права приёма карт — крайняя мера: МПС может лишить мерчанта или поставщика права работать с картами.

Что дальше

PCI DSS охватывает специфический контекст — платёжные данные. Следующие темы рассматривают российскую регуляторную базу, обязательную для широкого круга отечественных организаций.

Список литературы и стандартов

Обновлено С. Антошкин 11 дня назад · 23 изменени(я, ий)