Как только в системе появляются банковские карты, появляется и аббревиатура 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», и никогда — номер карты.
Способы приёма и их цена
Как именно карта попадает к провайдеру — главное решение: оно определяет, видит ли ваш код номер вообще, и, как следствие, глубину проверки (какой опросник SAQ вы заполняете).
| Способ приёма | Кто касается номера карты | Скоуп PCI | Опросник | Усилия |
|---|---|---|---|---|
| Редирект на страницу провайдера | только провайдер | минимальный | SAQ A | низкие |
| iframe / hosted fields провайдера | только провайдер (поля — на его домене) | минимальный | SAQ A / A-EP | низкие–средние |
| Своя форма → API провайдера | ваш фронтенд касается PAN транзитом | заметный | SAQ A-EP | средние–высокие |
| Своя форма + собственная обработка/хранение | вы храните и обрабатываете PAN | максимальный | SAQ D + аудит QSA | очень высокие |
Разница между первыми и последними строками — это разница между заполнить анкету на пару страниц и приглашать аудитора. Поэтому по умолчанию берут редирект или hosted fields; своя форма и тем более своё хранение — только когда без этого действительно нельзя.
Требования: что они значат для кода
Формально стандарт — 12 требований; для разработчика они сводятся к нескольким привычкам:
- Не хранить лишнего. PAN — только при доказанной необходимости, маскированный при показе (первые 6 / последние 4), зашифрованный при хранении; SAD — никогда. Проверьте самое коварное место — логи: PAN в логе запроса или в стектрейсе — готовое нарушение. Это тот же принцип, что и с PII в логах.
- Шифрование при передаче: TLS на всех путях карточных данных, включая внутренние.
- Минимальный доступ: роли по принципу «нужно для работы», уникальные учётки (никаких общих админских), MFA для доступа в CDE.
- Журналирование: кто, когда и к каким карточным данным обращался — аудит, защищённый от подмены.
- Безопасная разработка: ревью кода, управление уязвимостями и зависимостями, тестовые среды без прод-данных карт.
В коде это выражается в модели данных: сущность платежа хранит токен, а не номер — тогда PAN негде случайно засветить (в логах, трейсах, дампах БД):
// В сервисе заказов нет ни поля pan, ни cvv — только суррогаты от провайдера.
record Payment(String token, String brand, String last4, Instant paidAt) {}
// Оплата: номер ушёл провайдеру, к нам вернулся токен.
paymentRepo.save(new Payment("tok_1a2b3c", "VISA", "1111", Instant.now()));
// Повторное списание (подписка, доплата) — по токену, не по номеру:
gateway.charge("tok_1a2b3c", amount);
Если PAN всё же проходит транзитом (собственная форма), для показа его маскируют — первые 6 и последние 4, остальное скрыто:
static String maskPan(String pan) {
return pan.replaceAll("(?<=\\d{6})\\d(?=\\d{4})", "*");
}
// 4111111111111111 -> 411111******1111
А главное — PAN и CVV не должны попадать в объекты, которые уходят в логи и в тексты ошибок: их там ищут в первую очередь.
Уровни и проверки
Глубина проверки зависит от объёма транзакций: от ежегодного самоопросника (SAQ) у малых до аудита на площадке сертифицированным аудитором (QSA) у крупных. Практическое следствие для команды: набор SAQ определяется архитектурой приёма платежей — редирект на провайдера, его iframe или собственная форма дают разные списки требований. Решение «как принимаем карты» стоит принимать вместе с тем, кто отвечает за соответствие, — до реализации, а не после.
Коротко
- PCI DSS обязателен для всех, кто хранит, обрабатывает или передаёт карточные данные; это договорное требование платёжных систем со штрафами через банк.
- CVV и прочие SAD не хранятся никогда; PAN — только при необходимости, маскированный и зашифрованный; самое частое нарушение — номер карты в логах.
- Главный ход — сузить CDE: токенизация через платёжного провайдера выводит ваши сервисы из скоупа; при собственной обработке — жёсткая сегментация.
- Для кода это: минимум данных, TLS везде, наименьшие привилегии, аудит доступа, чистые логи и тестовые среды без прод-карт.
- Способ приёма платежей (redirect / iframe / своя форма) определяет глубину аудита — выбирайте его осознанно и заранее.
Что почитать дальше
- PII и секреты — как не размазывать чувствительные данные по логам и конфигам.
- Аудит действий администраторов — журналирование, которого требует и PCI DSS.
- Где какая проверка — слои авторизации вокруг платёжных операций.