PII數據令牌化

1）為什麼要進行令牌化，究竟是什麼要進行令牌化

目的：避免在操作環節和分析中訪問「原始」個人數據,降低泄漏風險,簡化合規性。
PII示例：FIO，電話，電子郵件，地址，護照/ID，INN，IP地址，Cookie-ID，付款標識符，出生日期等。

• 不透露起始值；
• 可以是可逆的（通過受保護的排毒服務）或不可逆的；
• 可以是確定性的（對於join/search）或非確定性的（對於最大限度的隱私）。

2）威脅模式和控制目標

風險：DB泄漏/日誌/備份，內幕閱讀，重復值相關性，未經授權的排序，字典/格式攻擊（電子郵件/電話），重復使用秘密。

1.共享信任區域：應用程序與令牌一起工作,源代碼僅在令牌服務中運行。

2.保證令牌的密碼穩定性和受控的測序。

3.使用KMS/HSM，旋轉和「加密消毒」來減少爆炸。

4.確保在受控風險下適於搜索/joins/分析。

3）令牌類型

• PII for search/joins：可逆確定性,綁定到區域（tenant/scope）,在KMS上帶有鎖定。
• 用於操作偽裝（UI）的PII：具有壽命的可逆非確定性，以降低重復使用的風險。
• 對於「灰色地帶」中的分析：不可逆的（關鍵的NMAS/鹽哈希）或DP聚集。

4）標記化架構

4.1個組件

Tokenization Service （TS）： 「tokenize/detokenize/search」,高度信任區域。
Token Vault （TV）：受保護的mapa 'token →原始（+元數據）'。
KMS/HSM：根密鑰存儲（KEK），包裝/簽名操作。

政策引擎： 誰，何處和為什麼可以進行分解；scope/TTL/rate-limits;mTLS/mTLS+mTLS.

Audit＆Immutability：所有令牌/排毒操作的不變日誌。

4.2鍵層次結構

KMS/HSM中的Root/KEK（組織/區域/租戶）。
DEK-PII到數據域（電子郵件/phone/address）和/或數據集。
輪換：rewrap DEK不跨越整個狼；「損害鑰匙」計劃。

4.3線程

1.Tokenize：→ TS客戶端（mTLS+A＆A）→令牌的歸一化→計算→ TV →令牌響應記錄。
2.Detokenize：具有TS →權限的客戶端→策略/基礎驗證→源代碼簽發（或拒絕）。
3.搜索/匹配：確定性令牌化允許通過令牌進行搜索；對於電子郵件/電話-在標記化之前將格式標準化。

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-單獨的；租戶或dataset。
沖突風險最小化功能（SHA-256/512）和域的選擇。

5.3決定論和行動領域

對於join，使用AAD='{tenant'purpose'field}的確定性方案→不同目標對應於相同值的不同令牌。
對於不同服務中的反相關性，是不同的密鑰/區域。

5.4盡量減少字典攻擊

規範化（電子郵件/電話的規範化），KMS中的pepper，域大小限制（不要將錯誤「未找到記錄」作為副通道），rate-limit和公共點的SARTSNA/代理。

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索引（來自歸一化PII的HMAC）允許搜索而無需進行分解。

6.3正常化輸送機

電子郵件： lowercasing, trim, canonical local-part（對所有域沒有積極的「食用」點）.

電話：E.164（帶有國家代碼），刪除格式字符。

address/name： 按規則音譯,trim, collapse spaces.

7）多重性和隔離

每個租戶的鑰匙和名稱：KEK/DEK per tenant。
排毒策略：角色+目標+原因+事件審核。
租戶數據的加密刪除-KEK的召回和DEK的破壞→ volt變得無用（對於其記錄）。

8）整合

8.1個數據庫和緩存

僅將令牌存儲在操作表中。
對於罕見的案例，需要通過代理/代理進行「即時」分解。
令牌緩存-僅在具有短TTL的內存中,無需寫入磁盤。

8.2 分析/BI/ML

在DWH/湖中-令牌或哈希。Join是通過相應的scope的確定性令牌執行的。
對於ML，最好是別名和聚合；避免恢復角色。

8.3支持服務和防凍劑

帶有面具（「+380」）的UI和基於合理原因（reason code）+第二因素的情節性排序。

9）輪換、版本和生命周期

共享令牌ID和加密版本（v1/v2）。
Rewrap：我們在不觸摸數據的情況下更改KEK。
事件計劃：鑰匙損害→即時召回，禁止排毒，回滾到「只讀」，啟動重寫。
令牌的TTL：通過策略-永久性（ID）或短期（一次性鏈接/臨時集成）。

10）性能和可靠性

硬件加速（AES-NI/ARMv8），連接到KMS的池以及包裹的DEK緩存。
TS水平縮放；讀取/寫入路徑。
用於網絡閃光燈下的tokenize重復的idempotency-key。
DR/HA：多區域，異步狼復制品，定期恢復測試。

SLO： p99潛伏期「tokenize」 ≤ 50-100毫秒；「detokenize」 ≤ 50毫秒；可用性≥ 99。9%.

11）可觀察性、審計、合規性

度量：方法的QPS，A＆A錯誤，分解比例（按角色/目標），高速緩存的命中率，KMS操作時間。
審計（不變）：每個分解都帶有「who/what/why/where」，請求哈希，結果。
存儲策略和日誌的WORM（請參閱「審核和不可更改的日誌」）。
合規性：GDPR（最小化，通過加密擦除刪除的權利），PCI DSS（用於PAN-FPE/別名），ISO/SOC報告。

12）測試和安全

加密單元測試：確定性令牌的穩定性，AAD驗證以及不匹配時的故障。
負面測試：字典攻擊、格式反向攻擊、限額攻擊、CSRF（用於Web面板）、SSRF攻擊。
混沌：KMS/volt不可用,過時的密鑰,部分復制。
間歇性的紅隊嘗試無緣無故地通過橫向通道進行分解。

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）常見錯誤以及如何避免錯誤

Logs中的令牌。代幣本身（尤其是可逆的）也是敏感數據。
單鍵「全部」。按租戶/領域/目標劃分；使用AAD。
正常化「如何到達」。不協調的封建打破了搜索/喬伊納。
無原因/限制的排毒。始終是reason代碼、審核和rate-limit。
FPE作為靈丹妙藥。僅在實際需要格式且具有正確域/密鑰的情況下應用。
磁盤上的長壽命緩存。緩存僅在具有TTL的內存中。
缺少rewrap進程。無需停機即可輪換KEK。

15）支票單

出售前

• 選擇了per字段/目標令牌配置文件（可逆性/確定性/區域）。
• 已配置密鑰層次結構（KEK/DEK）、KMS策略和關鍵操作審核。
• 實現了輸入規範化、格式驗證管道。
• 包括rate-limit, reason-codes,不可更改的審核。
• 已通過字典攻擊/格式/基於角色的訪問測試。
• DR/Volt復制件和鑰匙妥協計劃。

運營

• 每月排化報告（誰/為什麼/多少）。
• KEK/pepper的周期輪換，rewrap DEK。
• 紅色團隊未經授權的排毒/側面通道。
• 在出現新格式/區域時修改正常化。

16) FAQ

Q： Tokenization=匿名？
哦不令牌化-別名化。如果存在鑰匙/狼，則將恢復（或可比較）原件。要退出GDPR領域，需要可靠的匿名。

問： 如何在沒有排毒的情況下通過電子郵件/電話進行搜索?

答：具有規範化的細化令牌化。對於地址/FIO-哈希索引/搜索密鑰和輔助表。

問： 什麼時候需要FPE?

當外部合同/方案需要格式（長度/字母）時。在其他情況下-常規的AEAD令牌更簡單，更安全。

問： 所有目的都可以使用一個令牌嗎?

答：最好的不同區域（scope/purpose）：相同的PII為不同的任務提供不同的令牌→降低相關性風險。

問：如何執行「刪除權」？
O：加密刪除：召回KEK/DEK進行適當的設置，並且/或刪除Volta+中的條目，銷毀字段/批次密鑰；在分析中-TTL/aggregation/非人格化。

• 「秘密管理」
• 「At Rest加密」
• 「In Transit加密」
• «Privacy by Design (GDPR)»
• 「審核和不變日誌」
• 「密鑰管理和旋轉」