Токенізація даних

1) Що це і навіщо

Токенізація - заміна чутливих значень (PII/фінансових) несекретними токенами, з яких неможливо відновити джерело без доступу до окремого сервісу/ключів. В iGaming токенізація знижує радіус впливу витоків і вартість комплаєнсу, спрощує роботу з PSP/KYC-провайдерами і дозволяє аналітиці і ML працювати з даними без прямої PII.

• Мінімізувати зберігання «сирих» PII/фінансових даних.
• Обмежити доставку PII по сервісах і логах.
• Спростити відповідність вимогам (KYC/AML, платежі, приватність, локальні закони).
• Зберегти придатність даних для аналітики/ML через стабільні токени і детерміновані схеми.

2) Токенізація vs шифрування

Шифрування: оборотне перетворення; захищає при зберіганні/транзиті, але секрет залишається в даних (потрібен ключ).
Токенізація: оригінал замінюється посилальним ідентифікатором (token); оригінал зберігається окремо (vault) або взагалі не зберігається (vaultless FPE/DET).
Комбінування: PII → токен, оригінал в сейфі шифрується з HSM/KMS; токен в продуктах/логах, детокенізація тільки в «чистій зоні».

3) Види токенізації

1. Vault-based (класична):

Сховище відповідностей «оригінал ↔ токен».
Плюси: гнучкість форматів, простота детокенізації, контроль доступів і аудиту.
Мінуси: залежність від сейфа (latency/SPOF), масштабування і DR вимагають дисципліни.

2. Vaultless/криптографічна (FPE/DET):

Форматозберігаюче шифрування (FPE) або детерміноване шифрування (DET) без таблиць відповідностей.
Плюси: немає сейфа, висока продуктивність, стабільні токени для джойнів.
Мінуси: складніше ротація ключів і відгук, тонке налаштування криптопараметрів.

3. Хеш-токени (з сіллю/pepper):

Одностороннє перетворення для зіставлень (match/link) без оборотності.
Плюси: дешево і швидко; добре для de-dup в MDM.
Мінуси: немає детокенізації; колізії і атаки без надійної солі.

На практиці часто застосовують гібрид: PII токенізують через vault/FPE, додаючи солоні хеші для швидких джойнів і дедуплікації.

4) Об'єкти токенізації в iGaming

KYC: паспорт/ID, номер документа, дата народження, адреса, телефон, email, селфі-біометрика (шаблон або ID зберігання у вендора).
Платежі: PAN/IBAN, гаманці, крипто-адреси (з урахуванням чеків сум/формату).
Аккаунт/контакти: повне ім'я, адреса, телефон, e-mail, IP/Device ID (із застереженнями).
Операційна аналітика: скарги, тікети, чати - текстові поля проходять редакцію/маскування + токенізацію в посиланнях.
Логи/трейси: блокуємо PII; допускаємо токени/хеші.

5) Архітектурні патерни

5. 1 Зони і маршрути

Чиста зона (Restricted): сейф токенів, HSM/KMS, детокенізація, суворе RBAC/ABAC.
Сірі зони (Confidential/Internal): бізнес-сервіси, аналітика/ML; працюють тільки з токенами/агрегатами.
Крайова зона (Edge/PSP/KYC): інтеграції; PII потрапляє або відразу в сейф, або залишається «у вендора» і замінюється референс-токеном постачальника.

5. 2 Контракти та схеми

Data Contracts описують: де PII заборонена, де допускається токен, тип токена (формат, довжина, FPE/UUID), правила валідації і сумісності версій.
Schema Registry: мітки'pii:true`, `tokenized:true', «клас чутливості» поля.

5. 3 Детермінованість і джойни

Для стабільних джойнів між доменами використовуйте детерміновані токени (FPE/DET) або стійкі хеші з pepper.
Для UI/саппорта - рандомні opaque-токени + аудит запитів на зворотне перетворення.

6) Ключі, сейфи та детокенізація

Сховище ключів: KMS/HSM, ротація, розмежування прав, подвійний контроль.
Сейф токенів: відмовостійкий кластер, реплікації між регіонами, «break-glass» процедура з багатофакторним підтвердженням.
Детокенізація: тільки в «чистій зоні», за принципом найменших прав; тимчасові токени доступу (Just-In-Time) і обов'язковий аудит.
Ротація: розклад для ключів (crypto-shredding для відкликання), політики пере-токенізації, «dual-read» період.

7) Інтеграції: KYC/AML, PSP, провайдери

KYC-провайдери: зберігайте у себе тільки токени на їх записи/файли; вихідні скани - або у вендора, або в офлайн-сховище «чистої зони».
PSP: PAN ніколи не потрапляє в ядро; використовуйте токен PSP + свій внутрішній токен для крос-системних зв'язків.
AML/санкційні списки: матчі через PSI/MPC або через хеші з узгодженими солями у регулятора/партнера (по політиці).

8) Токенізація та аналітика/ML

Фічі будуються за токенами/агрегатами (приклад: частота депозитів на токен-платнику, гео по токен-IP, повторні KYC по токен-ID).
Для текстів: NLP-редакція PII + entity-заміни.
Для розмітки і A/B: реєстр фіч позначає неприпустимі PII-ознаки; policy-as-code в CI блокує PR з PII у вітринах.

9) Політики доступу та аудит

RBAC/ABAC: роль, домен, країна, мета обробки, «на який термін»; детокенізація тільки за заявкою з обґрунтуванням.
Журнали: хто і коли запросив детокенізацію, в якому контексті, на який обсяг.
DSAR/видалення: по токену знаходимо пов'язані сутності; при видаленні - «crypto-shred» ключів і чистка сейфа/бекапів за графіком.

10) Продуктивність і масштаб

Hot-path: синхронна токенізація на вході (КУС/платежі), кеш токенів з TTL в «сірих» зонах.
Bulk-path: асинхронна ретро-токенізація історичних даних; «dual-write/dual-read» режим на період міграції.
Надійність: актив-актив сейф, гео-реплікації, бюджет латентності, graceful-degradation (тимчасові маски замість детокенізації).

11) Метрики та SLO

Coverage: частка полів з'pii:true', які токенізовані.
Zero PII in logs: відсоток логів/трейсів без PII (мета - 100%).
Detokenization MTTR: середній час виконання валідної заявки (SLO).
Key hygiene: своєчасність ротації ключів, унікальність pepper по доменах.
Incidents: число порушень PII-політик і їх час закриття.
Perf: p95 латентності токенізації/детокенізації; доступність сейфа/агрегатора.
Analytics fitness: частка вітрин/моделей, які успішно перейшли на токени без деградації якості.

12) RACI (приклад)

Policy & Governance: CDO/DPO (A), Security (C), Domain Owners (C), Council (R/A).
Сейф/ключі: Security/Platform (R), CISO/CTO (A), Auditors (C).
Інтеграції (KYC/PSP): Payments/KYC Leads (R), Legal (C), Security (C).
Data/ML: Data Owners/Stewards (R), ML Lead (C), Analytics (C).
Операції та аудит: SecOps (R), Internal Audit (C), DPO (A).

13) Шаблони артефактів

13. 1 Політика токенізації (витримка)

Область дії: які класи даних підлягають токенізації; виключення та обґрунтування.
Тип токена: vault/FPE/DET/хеш; формат і довжина.
Доступ: хто може детокенізувати; процес заявки, журналювання, термін життя доступу.
Ротація: графік ключів, crypto-shred, backfill/dual-read.
Логи: заборона PII; штрафні заходи та інцидент-плейбук.

13. 2 Паспорт токенізованого поля

Поле/домен: `customer_email` / CRM

Клас даних: PII/Restricted

Тип токена: DET-FPE (домен збережений), довжина 64

Призначення: дедуп/джойни, комунікації через проксі

Детокенізація: заборонена; дозволена тільки для DPO по кейсу DSAR

Пов'язані артефакти: контракт, схема, DQ-правила (маска, формат)

13. 3 Чек-лист запуску

• Контракти та схеми позначені'pii '/' tokenized '
• Сейф/HSM розгорнуті, плани DR/BCP готові
• CI-лінтери блокують PII в коді/SQL/логах
• Набір тестів: відсутність PII в логах/витяжках, коректність формат-масок
• Дашборди Coverage/Zero-PII/Perf налаштовані
• Навчені команди (KYC/Payments/Support/Data/ML)

14) Дорожня карта впровадження

0-30 днів (MVP)

1. Інвентаризація PII/фінансових полів і потоків; Класифікація.
2. Вибір критичних шляхів (KYC, платежі, логи) і типу токенів (vault/FPE).
3. Розгорнути сейф з HSM/KMS, впровадити токенізацію на вході KYC/PSP.
4. Увімкнути лінтери/маскування логів; моніторинг Zero-PII.
5. Політика токенізації та процес детокенізації (заявки, аудит).

30-90 днів

1. Ретро-токенізація історій в CRM/білінг/тікети; dual-read.
2. Детерміновані токени/хеші для MDM і аналітики; адаптація джойнів.
3. Ротація ключів за графіком; дашборди Coverage/Perf/SLO.
4. Інтеграція з DSAR/видаленням (по токену і графу).
5. Плейбук інцидентів і навчання (table-top).

3-6 місяців

1. Розширення на провайдерів/партнерські канали; референс-токени зовнішніх постачальників.
2. Включення PSI/MPC для санкційних матчів без PII.
3. Повне покриття вітрин/ML на токенах; відмова від PII в прод-логах і трейсах.
4. Аудит відповідності та щорічна пересертифікація процесів.

15) Анти-патерни

«Токени в логах, оригінали - теж в логах»: логування без масок/фільтрів.
Детокенізація на стороні додатків «для зручності» без аудиту.
Єдиний ключ/pepper на всі домени і регіони.
Відсутність ротації ключів і плану crypto-shred.
FPE без контролю формату/алфавіту → збої в сторонніх системах.
Токенізація без змін в аналітиці/ML → зламані джойни і метрики.

16) Зв'язок з сусідніми практиками

Data Governance: політика, ролі, каталоги, класифікація.
Походження та шлях даних: де токени створюються/детокенізуються, траса PII.
Конфіденційне ML/Federated Learning: навчання на токенах/агрегатах, DP/TEE.
Етика і зниження упередженості: виключення проксі-PII, прозорість.
DSAR/Legal Hold: видалення/заморожування за токенами і ключами.
Спостережуваність даних: Zero-PII в логах, свіжість токен-потоків.

Підсумок

Токенізація - це не «косметика», а базовий шар безпеки і комплаєнсу. Правильна архітектура (зони, сейф/HSM, детерміновані токени для аналітики), строгі процеси (доступи, аудит, ротація) і дисципліна в логах роблять платформу стійкою до витоків, а дані - корисними без зайвих ризиків.