GH GambleHub

PII数据令牌化

🚨 Check Alignment of PII Data Tokenization

1）为什么要进行令牌化，究竟是什么要进行令牌化

目的：避免在操作环节和分析中访问"原始"个人数据,降低泄漏风险,简化合规性。
PII示例：FIO，电话，电子邮件，地址，护照/ID，INN，IP地址，Cookie-ID，付款标识符，出生日期等。

想法：使用令牌而不是原始值-安全的替代品，其中：
  • 不透露起始值；
  • 可以是可逆的（通过受保护的排毒服务）或不可逆的；
  • 可以是确定性的（对于join/search）或非确定性的（对于最大限度的隐私）。

2）威胁模式和控制目标

风险：DB泄漏/日志/备份，内幕阅读，重复值相关性，未经授权的排序，字典/格式攻击（电子邮件/电话），重复使用秘密。

目标是：

1.共享信任区域：应用程序与令牌一起工作,源代码仅在令牌服务中运行。

2.保证令牌的密码稳定性和受控的测序。

3.使用KMS/HSM，旋转和"加密消毒"来减少爆炸。

4.确保在受控风险下适于搜索/joins/分析。

3）令牌类型

属性备选方桉为什么
可逆性可逆的/不可逆的客户关怀vs分析师
决定论确定性/不确定性join/重复数据消除 vs反相关性
格式FPE（格式保护）/任意遵守口罩（电话/BIN） vs随机行
区域per-tenant/per-dataset/全局隔离和管理冲突
寿命持续/短暂的生活长期链接vs一次性令牌
推荐配置文件：
  • 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）迷你食谱

确定性可逆令牌（AEAD SIV，伪代码）： 

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
不可逆分析令牌（HMAC）： 

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)»
  • "审核和不变日志"
  • "密钥管理和旋转"
Contact

联系我们

如需任何咨询或支持，请随时联系我们。我们随时准备提供帮助！

Telegram
@Gamble_GC
开始集成

Email — 必填。Telegram 或 WhatsApp — 可选。

您的姓名 可选
Email 可选
主题 可选
消息内容 可选
Telegram 可选
@
如果填写 Telegram，我们也会在 Telegram 回复您。
WhatsApp 可选
格式：+国家代码 + 号码（例如：+86XXXXXXXXX）。

点击按钮即表示您同意数据处理。