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

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

1) Навіщо токенізація і що саме токенізуємо

Мета: виключити звернення до «сирих» персональних даних в операційному контурі та аналітиці, знизити ризик витоків і спростити відповідність вимогам.
PII-приклади: ПІБ, телефон, email, адреса, паспорт/ID, ІПН, IP-адреси, cookie-ID, платіжні ідентифікатори, дата народження та ін.

• не розкриває початкове значення;
• може бути оборотним (через захищений сервіс детокенізації) або незворотним;
• може бути детермінованим (для join/пошуку) або недетермінованим (для максимальної приватності).

2) Модель загроз і цілі контролю

Ризики: витоку БД/логів/бекапів, інсайдерські читання, кореляція за повторюваними значеннями, несанкціонована детокенізація, атаки по словнику/формату (email/телефон), перевикористання секретів.

1. Розділити зони довіри: додаток працює з токенами, вихідні - тільки в токен-сервісі.

2. Гарантувати криптографічну стійкість токенів і керовану детокенізацію.

3. Знизити blast radius за допомогою KMS/HSM, ротації і «крипто-стерилізації».

4. Забезпечити придатність для пошуку/джойнів/аналітики при контрольованому ризику.

3) Типологія токенів

• PII для пошуку/джойнів: оборотні детерміновані, прив'язані до області (tenant/scope), з засувкою на KMS.
• PII для оперативного маскування (UI): оборотні недетерміновані з терміном життя, щоб знижувати ризики повторного використання.
• Для аналітики в «сірій зоні»: незворотні (ключовий НМАС/хеш з сіллю) або DP-агрегації.

4) Архітектура токенізації

4. 1 Компоненти

Tokenization Service (TS): API «tokenize/detokenize/search», зона підвищеної довіри.
Token Vault (TV): захищена мапа'token → оригінал (+ метадані)'.
KMS/HSM: зберігання кореневих ключів (KEK), операції обгортки/підпису.
Policy Engine: хто, де і навіщо може детокенізувати; scope/TTL/rate-limits; mTLS/mTLS+mTLS.
Audit & Immutability: незмінні журнали всіх операцій токенізації/детокенізації.

4. 2 Ієрархія ключів

Root/KEK в KMS/HSM (на організацію/регіон/орендаря).
DEK-PII на домен даних (email/phone/address) і/або dataset.
Ротація: rewrap DEK без перешифрування всього волта; план «компрометація ключа».

4. 3 Потоки

1. Tokenize: клієнт → TS (mTLS + A&A) → нормалізація → обчислення токена → запис в TV → відповідь токеном.
2. Detokenize: клієнт з правами → TS → перевірка політики/підстави → видача вихідного (або відмова).
3. Search/Match: детермінована токенізація дозволяє шукати по токену; для email/телефону - нормалізуємо формат перед токенізацією.

5) Конструкції токенів (крипто-дизайн)

5. 1 Оборотні (рекомендується для операційного контуру)

AES-SIV/AEAD envelope: `cipher = AEAD_Encrypt(DEK, PII, AAD=scope|tenant|field)`; токен ='prefix'nonce'cipher'tag'.
FPE (FF1/FF3-1) для форматів (наприклад, 10-значний телефон без коду країни). Застосовувати з обережністю і правильним доменом (алфавіт/довжина).

5. 2 Незворотні (аналітика/анонімізація на межі)

Keyed НМАС/хеш: `token = HMAC(PII_normalized, key=K_scope)`; сіль/pepper - окрема; на орендаря або датасет.
Ризик колізій мінімізувати вибором функції (SHA-256/512) і доменом.

5. 3 Детермінізм і область дій

Для join використовуйте детерміновану схему з AAD ='{ tenant'purpose'field}'→ різним цілям відповідають різні токени одного значення.
Для анти-кореляції в різних сервісах - різні ключі/області.

5. 4 Мінімізуємо атаки по словнику

Нормалізація (канонізація email/телефону), pepper в KMS, обмеження розмірів домену (не віддавати помилки «не знайдено запис» як сайд-канал), rate-limit і САРТСНА/проксі для публічних точок.

6) Дизайн API і схеми

6. 1 REST/gRPC (варіант)

`POST /v1/tokenize { field, value, scope, tenant_id, purpose } -> { token, meta }`

`POST /v1/detokenize { token, purpose } -> { value }` (mTLS + OIDC + ABAC; «мінімізація» видачі)

'POST/v1/match {field, value} -> {token}'( детермінований шлях для пошуку)

6. 2 Схема зберігання (TV)

Таблица `tokens(field, scope, tenant_id, token, created_at, version, wrapped_key_id, hash_index)`

Індекси: по'token', по'( tenant_id, field, hash_index)'для де-дуплікації/пошуку.
Hash index (HMAC від нормалізованого PII) дозволяє шукати без детокенізації.

6. 3 Конвеєри нормалізації

email: lowercasing, trim, canonical local-part (без агресивного «з'їдання» точок для всіх доменів).
phone: E.164 (з кодом країни), видалення форматуючих символів.
address/name: транслітерація за правилами, trim, collapse spaces.

7) Багатоарендність та ізоляція

Ключі та namespaces на орендаря: KEK/DEK per tenant.
Політики детокенізації: роль + мета + причина + event-аудит.
Крипто-видалення даних орендаря - відгук KEK і знищення DEK → хвиль стає марним (для його записів).

8) Інтеграції

8. 1 Бази даних і кеші

Зберігайте тільки токени в операційних таблицях.
Для рідкісних кейсів потрібна детокенізація «на льоту» через проксі/агент.
Кеші токенів - тільки в пам'яті з коротким TTL, без запису на диск.

8. 2 Аналітика/BI/ML

У DWH/озері - токени або хеші. Join виконується за детермінованими токенами відповідного scope.
Для ML - переважно псевдонімізація і агрегати; уникати відновлення персон.

8. 3 Служби підтримки та антифрод

UI з маскою ('+ 380') і епізодичною детокенізацією з обґрунтованої причини (reason code) + second factor.

9) Ротація, версії та життєвий цикл

Розділяйте ідентифікатор токена і версію шифрування (v1/v2).
Rewrap: змінюємо KEK, не чіпаючи дані.
План інцидентів: компрометація ключів → миттєвий відгук, заборона детокенізації, відкат до «read-only», запуск rewrap.
TTL токенів: з політики - постійні (ідентифікатори) або короткі (одноразові посилання/тимчасові інтеграції).

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

Апаратні прискорення (AES-NI/ARMv8), пули з'єднань до KMS, кеш обернених DEK.
Горизонтальне масштабування TS; розділення read/write шляхів.
Ідempotency-key для повторів tokenize при мережевих флапах.
DR/HA: багатозонність, асинхронна репліка волта, регулярні тести відновлення.
SLO: p99 латентності'tokenize'≤ 50-100 мс;'detokenize'≤ 50 мс; доступність ≥ 99. 9%.

11) Спостережуваність, аудит, комплаєнс

Метрики: QPS за методами, помилки A&A, частка детокенізацій (за ролями/цілями), hit-rate кешу, час KMS-операцій.
Аудит (незмінний): кожна детокенізація з'who/what/why/where', хеш запиту, результат.
Політики зберігання та WORM для журналу (див. «Аудит і незмінні журнали»).
Відповідність: GDPR (мінімізація, право на видалення через крипто-стирання), PCI DSS (для PAN - FPE/псевдонімізація), ISO/SOC звітність.

12) Тестування та безпека

Крипто-юніт-тести: стабільність детермінованих токенів, перевірка AAD і відмова при його невідповідності.
Негативні тести: атаки словником, реверс за форматом, rate-limit, CSRF (для веб-панелей), SSRF на бекенди.
Chaos: недоступний KMS/волт, застарілий ключ, часткова реплікація.
Періодичні Red-team спроби детокенізувати без підстав і по бічних каналах.

13) Міні-рецепти

pii_norm = normalize(value)
aad   = scope          tenant          field dek   = kms. unwrap(kek_id, wrapped_dek_for_field)
token = aead_siv_encrypt (dek, pii_norm, aad) # deterministically store_vault (token, pii_norm, meta)
return token

pii_norm = normalize(value)
pepper  = kms. get_secret("pepper/"+tenant+"/"+field)
token = HMAC_SHA256 (pepper, pii_norm) # deterministically within scope return base64url (token)

allow if role in {SupportL2, Risk, DPO} and purpose in {KYC, Chargeback, DSAR}
and mTLS and OIDC_claims match tenant and reason_code provided and ticket_id linked rate_limit per actor <= N/min

kms. disable_key(kek_tenant)
access to unwrap is blocked → detoxification is not possible schedule_destroy (kek_tenant, hold_days=7)

14) Часті помилки і як їх уникнути

Токени в логах. Маскуйте і самі токени (особливо оборотні) - це чутливі дані.
Єдиний ключ «на все». Діліть по орендарях/полях/цілях; використовуйте AAD.
Нормалізація «як попало». Неузгоджена канонізація ламає пошук/джойни.
Детокенізація без причин/обмежень. Завжди reason code, аудит і rate-limit.
FPE як панацея. Застосовувати тільки при реальній необхідності формату і з правильним доменом/ключами.
Довгоживучі кеші на диску. Кеш тільки в пам'яті з TTL.
Відсутність rewrap-процесу. Ротація KEK без простою обов'язкова.

15) Чек-листи

Перед продом

• Вибрані профілі токенів per поле/мета (оборотність/детермінізм/область).
• Налаштована ієрархія ключів (KEK/DEK), політики KMS, аудит ключових операцій.
• Реалізована нормалізація входів, конвеєр валідації форматів.
• Включені rate-limit, reason-codes, незмінний аудит.
• Тести на словникові атаки/формат/роль-базований доступ пройдені.
• DR/репліка волта і план компрометації ключів.

Експлуатація

• Щомісячний звіт по детокенізаціях (хто/навіщо/скільки).
• Періодична ротація KEK/pepper, rewrap DEK.
• Red-team на несанкціоновану детокенізацію/бічні канали.
• Перегляд нормалізації при появі нових форматів/регіонів.

16) FAQ

В: Токенізація = анонімізація?
О ні. Токенізація - псевдонімізація. Джерело відновимо (або можна порівняти) за наявності ключів/волта. Для виходу зі сфери GDPR потрібна надійна анонімізація.

В: Як шукати по email/телефону без детокенізації?
ПРО: Детемінована токенізація з канонізацією. Для адрес/ПІБ - хеш-індекси/пошукові ключі та допоміжні таблиці.

В: Коли потрібен FPE?
ПРО: Коли зовнішній контракт/схема вимагають формат (довжина/алфавіт). В інших випадках - звичайні AEAD-токени простіше і безпечніше.

В: Чи можна один токен для всіх цілей?
ПРО: Краще різні області (scope/purpose): один і той же PII дає різні токени для різних завдань → знижується ризик кореляції.

В: Як виконати «право на видалення»?
ПРО: Крипто-видалення: відкликаємо KEK/DEK для відповідного набору та/або видаляємо запис у волті + знищуємо ключі поля/партії; в аналітиці - TTL/агрегування/знеособлення.

• «Менеджмент секретів»
• «Шифрування At Rest»
• «Шифрування In Transit»
• «Privacy by Design (GDPR)»
• «Аудит і незмінні журнали»
• «Управління ключами та ротація»