Как только в системе появляются банковские карты, появляется и аббревиатура PCI DSS — и обычно в тревожном контексте: «мы попадаем под PCI?», «аудит через квартал». Разберём стандарт глазами разработчика: когда он вас касается, что реально требует и почему главное архитектурное решение — сделать так, чтобы касался как можно меньше.

Что это и когда касается вас

PCI DSS (Payment Card Industry Data Security Standard) — стандарт безопасности, созданный платёжными системами (Visa, Mastercard и другими). Он обязателен для всех, кто хранит, обрабатывает или передаёт данные платёжных карт. Это не закон государства, а договорное требование: нарушили — штрафы от банка-эквайера и вплоть до запрета принимать карты.

Ключевые термины:

  • PAN (Primary Account Number) — номер карты; главный защищаемый объект;
  • SAD (Sensitive Authentication Data) — CVV, содержимое магнитной полосы, PIN: хранить нельзя вообще, даже зашифрованно, даже «на минутку»;
  • CDE (Cardholder Data Environment) — все системы, которые хранят, обрабатывают или передают карточные данные, плюс всё, что с ними напрямую связано сетью.

Главная стратегия: сузить CDE

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

  • Платёжный провайдер + токенизация. Форма оплаты рисуется провайдером (redirect или его iframe на вашей странице); PAN уходит напрямую провайдеру, вам возвращается токен — суррогат без ценности для вора. Ваши списания идут по токену. Большинство сервисов электронной коммерции живут именно так — их скоуп аудита минимален (самоопросник SAQ A вместо полного аудита).
  • Сегментация. Если карты всё же обрабатываются у вас (платёжный шлюз, процессинг), CDE выделяется в изолированный сетевой сегмент: отдельные сервисы, свой контур доступа, минимум связей наружу. Каждый сервис, добавленный в CDE, — плюс к площади аудита; проектируйте так, чтобы «обычные» сервисы (каталог, заказы, профили) в CDE не входили.

Правило на языке кода: сервис заказов должен знать «оплачено токеном tok_abc», и никогда — номер карты.

Требования: что они значат для кода

Формально стандарт — 12 требований; для разработчика они сводятся к нескольким привычкам:

  • Не хранить лишнего. PAN — только при доказанной необходимости, маскированный при показе (первые 6 / последние 4), зашифрованный при хранении; SAD — никогда. Проверьте самое коварное место — логи: PAN в логе запроса или в стектрейсе — готовое нарушение. Это тот же принцип, что и с PII в логах.
  • Шифрование при передаче: TLS на всех путях карточных данных, включая внутренние.
  • Минимальный доступ: роли по принципу «нужно для работы», уникальные учётки (никаких общих админских), MFA для доступа в CDE.
  • Журналирование: кто, когда и к каким карточным данным обращался — аудит, защищённый от подмены.
  • Безопасная разработка: ревью кода, управление уязвимостями и зависимостями, тестовые среды без прод-данных карт.

Уровни и проверки

Глубина проверки зависит от объёма транзакций: от ежегодного самоопросника (SAQ) у малых до аудита на площадке сертифицированным аудитором (QSA) у крупных. Практическое следствие для команды: набор SAQ определяется архитектурой приёма платежей — редирект на провайдера, его iframe или собственная форма дают разные списки требований. Решение «как принимаем карты» стоит принимать вместе с тем, кто отвечает за соответствие, — до реализации, а не после.

Коротко

  • PCI DSS обязателен для всех, кто хранит, обрабатывает или передаёт карточные данные; это договорное требование платёжных систем со штрафами через банк.
  • CVV и прочие SAD не хранятся никогда; PAN — только при необходимости, маскированный и зашифрованный; самое частое нарушение — номер карты в логах.
  • Главный ход — сузить CDE: токенизация через платёжного провайдера выводит ваши сервисы из скоупа; при собственной обработке — жёсткая сегментация.
  • Для кода это: минимум данных, TLS везде, наименьшие привилегии, аудит доступа, чистые логи и тестовые среды без прод-карт.
  • Способ приёма платежей (redirect / iframe / своя форма) определяет глубину аудита — выбирайте его осознанно и заранее.

Что почитать дальше

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