Как работает шифрование данных в платёжных системах

Платёжные системы оперируют самыми чувствительными данными — PAN (номер карты), срок действия, CVV/CVC, 3-DS токены, банковские реквизиты, идентификаторы кошельков. Их утечка — штрафы, отзыв мерчанта у банков/PSP и прямая финансовая потеря. Защита строится многослойно: шифрование в канале (TLS), шифрование и/или токенизация на хранении, строгий менеджмент ключей и аппаратные доверенные модули (HSM). Ниже — весь «конвейер» безопасности простым языком.

Базовые кирпичики

Симметричная криптография

Алгоритмы: AES-GCM/CTR/CBC (в платёжках де-факто стандарт — AES-GCM).

Плюсы: высокая скорость, компактные ключи.

Минусы: нужно безопасно договориться о ключе и IV/nonce.

Асимметричная криптография

Алгоритмы: RSA-2048/3072, ECC (P-256/384, Ed25519).

Использование: обмен/обёртка ключей, подписи, PKI, TLS-сертификаты.

Плюсы: не требует общего секрета заранее.

Минусы: медленнее, чем симметричное шифрование.

Идея Perfect Forward Secrecy (PFS)

Сессийные ключи договариваются эффемерным ECDHE. Даже если приватный ключ сервера когда-то утечёт, прошлые сессии останутся недешифруемыми.

Шифрование «в пути»: TLS 1.2/1.3

1. Рукопожатие (TLS handshake): клиент и сервер соглашают версии/шифры, сервер предъявляет сертификат (PKI), обмениваются эфемерными ключами (ECDHE) → рождается сессионный симметричный ключ.

2. Данные: передаются в AEAD-режимах (AES-GCM/ChaCha20-Poly1305) с аутентификацией.

3. Оптимизации: TLS 1.3 сокращает раунды, поддерживает resumption; 0-RTT используют осторожно (только идемпотентные запросы).

4. Практика для платёжек: запрещаем SSLv3/TLS1.0/1.1, включаем TLS1.2/1.3, OCSP stapling, HSTS, строгие заголовки безопасности.

💡 Внутренние вызовы (PSP → мерчант, мерчант → процессинг, вебхуки) часто дополнительно защищают mTLS: обе стороны показывают взаимные сертификаты.

Шифрование «на хранении»: at rest

Варианты

Полное шифрование томов/БД (TDE): быстро вводится, защищает от «холодного» доступа к носителю, но не от утечки через скомпрометированное приложение.

Побитовое/поле-уровня (FLE): шифруются отдельные поля (PAN, IBAN). Гранулярно, но сложнее в реализации и индексации.

Форматосохраняющее шифрование (FPE): полезно, когда нужен вид «16 цифр как 16 цифр».

Токенизация: PAN заменяется токеном (бессмысленной строкой); настоящий PAN хранится в token vault под усиленной защитой. При оплате/возврате используется токен → мерчант не обрабатывает «сырые» карты.

Ключевая идея

На хранении важнее не «какой алгоритм», а где лежат ключи и кто может детокенизировать. Поэтому…

Менеджмент ключей: KMS, HSM и конверты

Иерархия ключей (envelope encryption)

Root/KEK (Key Encryption Key): высокий класс защиты, хранится и исполняется в HSM.

DEK (Data Encryption Key): шифрует конкретные данные/партии/таблицы; сам зашифрован KEK’ом.

Ротация: регламенты плановой и внеплановой (при инциденте) ротации KEK/DEK; версия ключей указывается в метаданных шифротекста.

HSM (Hardware Security Module)

Аппаратный модуль, сертифицированный (например, FIPS 140-2/3), который хранит и выполняет операции с ключами внутри себя.

Не выдаёт приватные ключи наружу, поддерживает лимиты/политику использования, аудит.

Используется для: генерации ключей, обёртки DEK, 3-DS серверных ключей, EMV-ключей, PIN-операций, подписи сообщений.

KMS

Централизует политику ключей, версионирование, доступы, журналы и API.

В связке с HSM реализует envelope encryption и автоматическую ротацию.

Карточные стандарты и отраслевые специфики

PCI DSS (и логика минимизации)

Главная идея: не хранить CVV, минимизировать зону обработки PAN (scope).

Где возможно — отдавать ввод PAN на Hosted Fields/Iframe PSP → у мерчанта нет доступа к сырым данным.

Логи, бэкапы, дампы — те же правила, что и прод: маскирование, шифрование, ретенция.

EMV, PIN и POS

EMV чип/контакт-less: криптограммы на уровне карты/терминала, защита от клонирования маг-полосы.

PIN-блоки и ISO 9564: PIN шифруется от пина-пэда до процессинга, работает с HSM (пин-переводы, ключевые зоны).

DUKPT (Derived Unique Key Per Transaction): на POS каждый платеж шифруется уникальным ключом, производным от BDK → компрометация одного сообщения не тянет за собой другие.

PCI P2PE: сертифицированная «сквозная» схема шифрования от пина-пэда до провайдера расшифровки.

3-D Secure (2.x)

Аутентификация держателя карты → меньше фрода/чарджбеков.

Криптография используется для подписей сообщений, обмена ключами ACS/DS/3DS Server; приватные ключи обычно в HSM.

Типовые архитектуры защиты данных

Вариант A (онлайн-мерчант с PSP):

Браузер → HTTPS → Hosted Fields PSP (PAN не попадает к мерчанту).
PSP возвращает payment token.
В БД мерчанта хранится токен + последние 4 цифры и BIN (для UX и правил).
Возвраты/повторы — только по токену.
Секреты/ключи — в KMS, приватные ключи TLS/3-DS — в HSM.

Вариант B (кошелёк/платёжка):

Приложение ↔ API — TLS/mTLS.
Чувствительные поля — FLE/FPE или токенизация; vault изолирован.
Доступ к детокенизации — только по сервисным ролям с «четырёхглазием», операции — через HSM.

Вариант C (офлайн-POS):

Пин-пэд → DUKPT/P2PE → процессинг.
Ключи загрузки терминала — через защищённые ключевые инжекторы/ХSM.
Журналирование, anti-tamper защиты устройств.

Ротация, аудит и инциденты

Ротация ключей: планово (раз в X мес.) и по событию (компрометация). DEK rewrap под новым KEK без расшифровки пользовательских данных.

Неизменяемые журналы: кто и когда получал доступ к детокенизации/ключам; подпись логов.

Runbook компрометации: немедленный revoke/rotate, перевыпуск сертификатов, блок API-ключей, уведомление партнёров, ретроспектива.

Частые ошибки и как их избежать

1. «Мы шифруем БД, значит всё ок».

Нет. Скомпрометированное приложение читает данные в открытую. Нужны токенизация/FLE и принцип наименьших прав.

2. Хранение CVV.

Нельзя. CVV не хранится никогда, даже зашифрованным (по PCI DSS).

3. Ключи рядом с данными.

Нельзя. Ключи — в KMS/HSM, доступ — по ролям, минимум привилегий, отдельные аккаунты.

4. Нет ротации/версий.

Всегда версионируйте ключи, храните `key_version` в метаданных шифротекста.

5. TLS только на периметре.

Шифруйте за CDN/WAF и внутри дата-плана (сервис→сервис, вебхуки).

6. Токенизация «для вида».

Если detokenize может любой сервис — это не защита. Ограничьте до узкого круга и аудитируйте вызовы.

7. Неучтённые бэкапы/аналитические выгрузки.

Шифрование и маскирование должны распространяться на бэкапы, снапшоты, BI-витрины, логи.

Чек-лист внедрения (кратко)

Канал

TLS 1.2/1.3, PFS, mTLS для внутренних и вебхуков, HSTS, строгие security-headers.

Хранение

Токенизация PAN, запрет хранения CVV.

FLE/FPE для критичных полей; TDE как базовый слой.

Ключи

KMS + HSM, envelope encryption (KEK/DEK), ротация/версии, неизменяемые журналы.

Архитектура

Hosted Fields/SDK PSP, минимизация зоны PCI.

Разделение ролей/сетей, zero trust, секреты — только через секрет-менеджер.

Операции

Pentest/Red Team по периметру и бизнес-логике.

DLP/CTI-мониторинг сливов, обучение персонала.

Runbook на compromise: revoke/rotate/notify.

Мини-FAQ

Что лучше для PAN: шифрование или токенизация?

В проде — токенизация (минимизирует scope). В vault — шифрование с HSM/KMS.

Нужен ли EV-сертификат для платёжного домена?

Не обязателен. Важнее корректный TLS-профиль, mTLS, ключи в HSM и дисциплина.

Можно ли использовать 0-RTT в TLS 1.3 для платежей?

Для идемпотентных GET — да. Для POST лучше выключить или ограничить.

Как хранить «последние 4» и BIN?

Отдельно от PAN; это не чувствительные данные при правильной изоляции, но соблюдайте маскирование в логах/BI.

Шифрование в платёжных системах — это не один тумблер, а экосистема: TLS/PFS в канале, токенизация и/или FLE на хранении, строгий менеджмент ключей через KMS+HSM, отраслевые стандарты (PCI DSS, EMV, 3-DS), ротация и аудит. Такая многослойная архитектура делает утечку карточных данных крайне маловероятной, упрощает прохождение аудитов и — главное — сохраняет доверие банков, платёжных партнёров и пользователей.