Як працює шифрування даних в платіжних системах

Платіжні системи оперують найчутливішими даними - 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/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 і всередині дата-плану (servis→servis, вебхуки).

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), ротація і аудит. Така багатошарова архітектура робить витік карткових даних вкрай малоймовірним, спрощує проходження аудитів і - головне - зберігає довіру банків, платіжних партнерів і користувачів.