Что такое PCI DSS и зачем он платёжному проекту

Что такое PCI DSS и кого он касается
PCI DSS (Payment Card Industry Data Security Standard) — это стандарт безопасности, который описывает, как организация должна хранить, обрабатывать и передавать данные платёжных карт. Его поддерживает совет PCI SSC, созданный международными платёжными системами Visa, Mastercard, American Express, Discover и JCB. Формально это не закон, а контрактное требование: банк-эквайер и платёжные системы обязывают вас соответствовать стандарту, если вы хотите принимать карты.
В Узбекистане у многих проектов возникает иллюзия, что PCI DSS их не касается, потому что они работают с локальными системами Uzcard и Humo. Но как только вы начинаете принимать международные карты Visa или Mastercard напрямую — через собственную форму оплаты, мобильное приложение или серверную интеграцию — вы попадаете в зону действия стандарта. Банк-эквайер просто не подключит вас без подтверждения соответствия.
Уровни мерчантов: куда вы попадаете
Объём требований зависит от количества карточных транзакций в год. Платёжные системы делят мерчантов на четыре уровня:
- Уровень 1 — более 6 млн транзакций в год. Самый строгий: обязательный ежегодный аудит на месте от внешнего аудитора QSA с отчётом ROC.
- Уровень 2 — от 1 до 6 млн транзакций. Как правило, опросный лист самооценки SAQ, иногда с участием QSA.
- Уровень 3 — от 20 тыс. до 1 млн онлайн-транзакций. SAQ и ежеквартальное ASV-сканирование внешнего периметра.
- Уровень 4 — менее 20 тыс. онлайн-транзакций или до 1 млн всех. Чаще всего SAQ и сканирование.
Подавляющее большинство стартапов и средних проектов в Узбекистане — это Уровень 3 или 4. Это хорошая новость: вам, скорее всего, не нужен дорогой выездной аудит, достаточно правильно заполненного SAQ и регулярных сканирований.
12 требований стандарта
PCI DSS сводится к 12 требованиям, сгруппированным в шесть целей. Если убрать формулировки, по сути это здравая инженерная гигиена:
- Сетевая защита: межсетевые экраны, сегментация, запрет хранения данных в открытом сегменте.
- Отказ от заводских паролей и небезопасных настроек по умолчанию.
- Защита хранимых карточных данных: шифрование, маскирование, запрет хранить CVV вообще.
- Шифрование передачи данных по открытым сетям (TLS).
- Антивирусная защита и управление уязвимостями.
- Безопасная разработка и регулярное закрытие уязвимостей в коде.
- Ограничение доступа к данным по принципу минимальных привилегий.
- Уникальная идентификация каждого, кто имеет доступ к системам.
- Физическая защита оборудования и носителей.
- Логирование и мониторинг всех обращений к данным.
- Регулярное тестирование систем безопасности (сканы, пентесты).
- Поддержка политики информационной безопасности.
Актуальная версия стандарта — PCI DSS 4.0.1. Ряд новых требований из ветки 4.0 стал обязательным после марта 2025 года: усиленная аутентификация, контроль скриптов на платёжных страницах, более частая проверка прав доступа. Если вы стартуете проект сейчас — закладывайте сразу 4.0.1, а не устаревшую 3.2.1.
Токенизация: как сократить нагрузку
Токенизация — это замена номера карты на бессмысленный для злоумышленника токен. Реальный PAN хранится в защищённом хранилище провайдера, а в вашей базе лежит ссылка, по которой нельзя восстановить карту. Это ключевой приём, чтобы вывести свои серверы из области аудита.
Шифрование защищает данные, но они остаются у вас — а значит, ваши серверы остаются в scope PCI DSS со всеми требованиями.
Токенизация переносит ответственность за хранение карты на сертифицированного провайдера. У вас остаётся токен, который сам по себе не является карточными данными — и объём проверки резко падает.
На практике это означает: используйте hosted-формы, redirect-оплату или iframe от провайдера, который уже прошёл сертификацию. Тогда карта никогда не проходит через ваш бэкенд. Для большинства узбекских проектов, интегрирующихся через локальные PSP, это и есть рабочая модель — карточные данные физически не попадают на вашу инфраструктуру.
Как готовиться и какие сроки закладывать
Подготовка к соответствию идёт по понятному маршруту:
- Определить scope: где карточные данные появляются, хранятся и передаются. Рисуется data-flow диаграмма.
- Сократить scope через токенизацию и сегментацию сети.
- Выбрать правильный тип SAQ под вашу архитектуру.
- Закрыть технические разрывы: TLS, логирование, MFA, управление доступом, патчинг.
- Провести ASV-сканирование внешнего периметра (для Уровней 3-4 — ежеквартально).
- Заполнить SAQ и AOC, при необходимости — пройти ROC с QSA.
Реалистичные сроки: если архитектура изначально проектировалась с токенизацией и hosted-оплатой, подготовка занимает от нескольких недель до пары месяцев. Если проект уже хранит карты и его нужно перестраивать — закладывайте от трёх до шести месяцев, плюс время на устранение замечаний после первого сканирования. Сертификация не разовая: SAQ обновляется ежегодно, ASV-сканы — ежеквартально, поэтому соответствие лучше встраивать в процессы, а не делать авралом раз в год.
Вывод
PCI DSS — это не бюрократический барьер, а способ не потерять и деньги, и доверие пользователей при первом же инциденте. Самый дешёвый PCI DSS — тот, который заложен в архитектуру с самого начала: токенизация, hosted-формы и грамотная сегментация сокращают объём проверки в разы. Если вы запускаете платёжный проект в Узбекистане и хотите спроектировать интеграцию так, чтобы карточные данные не попадали на вашу инфраструктуру, — обсудите архитектуру с командой OneDev до того, как написан первый платёжный модуль.
Нужен ли PCI DSS, если мы работаем только через Payme, Click или Uzum?
Чем отличается шифрование от токенизации?
Можно ли хранить CVV для повторных списаний?
Какой уровень мерчанта у типичного узбекского стартапа?
Сколько времени занимает подготовка к соответствию?
Какую версию стандарта использовать в новом проекте?
Нужна похожая система или хотите обсудить проект?
Опишите задачу — предложим архитектуру, технический подход и план работ. Часто для старта достаточно короткого звонка.
Обсудить проект