Токенизация 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): обратимые недетерминированные со сроком жизни, чтобы снижать риски повторного использования.
• Для аналитики в «серой зоне»: необратимые (ключевой HMAC/хэш с солью) или 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 HMAC/хэш: `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 и CAPTCHA/прокси для публичных точек.

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)»
• «Аудит и неизменяемые журналы»
• «Управление ключами и ротация»