数据匿名化指南草案

Guidelines to Anonymize Identity Verification Records

Objective Provide a repeatable, auditable process to produce datasets from identity verification (IDV) systems that do not allow the identification of individuals by any party reasonably likely to access the data, while preserving analytical utility for compliance reporting, risk analytics, and product metrics.

Scope and assumptions

• Typical IDV records include: personal identifiers (name, national ID, document number), contact details, addresses, photos/selfies, document images and MRZ, biometrics or liveness artefacts, device and network identifiers, geolocation, timestamps, verification outcomes, scores, reasons, vendor reference IDs, and operational logs.
• Anonymization target: irreversible removal of identifiability (GDPR Recital 26). Pseudonymized datasets remain personal data (GDPR Art. 4(5)); use only where necessary and under strict controls.
• Applicable frameworks and principles: GDPR (anonymous vs. pseudonymous; data minimization; privacy by design), HIPAA de-identification concepts (safe harbor and expert determination) as design references for field-level removal/generalization, CCPA/CPRA “deidentified” data requirements (cannot reasonably be linked; public commitment not to reidentify; safeguards and contractual controls), ISO/IEC 20889 and ISO/IEC 27559 for de-identification techniques and governance.

Governance prerequisites

1. Define purposes and data minimization

• Enumerate permitted use cases (e.g., aggregated KPI reporting, fraud trend analysis, control effectiveness, model performance monitoring). Disallow operational re-contact or customer support tasks in anonymous datasets.
• Create two tiers of datasets:
  • Anonymous: for broad analytics and sharing within the organization or with partners under de-identification covenants.
  • Pseudonymous: for limited internal analytics that require subject-level linkage; kept in a high-trust enclave with stronger controls.

2. Data inventory and classification

• Catalogue all IDV fields and classify as:
  • Direct identifiers: name, national ID, document number, email, phone, full address, selfie/document images, biometric templates, account IDs that directly identify.
  • Quasi-identifiers: date/time, partial address, geolocation, IP/device IDs, vendor IDs, transaction counts, rare attributes (document type + issuing country + unusual age).
  • Sensitive attributes: biometrics, government IDs, risk flags, watchlist hits.
  • Non-identifying: generic result codes, coarse categories, aggregated counts.

3. Threat model and risk criteria

• Adversaries: internal analysts, external recipients, or attackers with auxiliary data (breach dumps, social media, public records).
• Attack types: singling out, linkability across datasets, attribute inference.
• Success criteria: k-anonymity threshold ≥ 10 for agreed quasi-identifier set, l-diversity for sensitive attributes where applicable, absence of direct identifiers, and documented residual risk assessment.

Anonymization workflow

1. Isolate processing environment

• Perform transformations in a controlled de-identification service or pipeline. Prevent raw PII landing in analytics systems.
• Secrets for tokenization/HMAC must be in a managed KMS; key access restricted and audited.

2. Field-level transformations Apply transformations per field class. The following defaults are conservative; tune to utility requirements while meeting re-identification risk thresholds.

• Names, national IDs, document numbers, emails, phone numbers:

  • Anonymous dataset: drop.
  • Pseudonymous dataset: replace with random, non-derivable surrogate IDs (random UUIDv4). Do not use unhashed or unsalted hashes. If linkage is required across systems, use a keyed HMAC with periodic key rotation; treat as pseudonymization.

• Physical address:

  • Anonymous: remove street and unit; retain only coarse geography (e.g., country; for large countries use state/province; for postal codes use first 3 digits where population is large enough). Suppress rare regions to maintain k-anonymity.
  • Pseudonymous: city and 3–5 digit postal prefix; never exact address.

• Dates/times:

  • Anonymous: reduce precision (e.g., to day or week). Add random jitter within ±12 hours if needed. For sequences, store relative order only.
  • Pseudonymous: bucket to 15–60 minute intervals.

• IP addresses:

  • Anonymous: generalize to /24 (IPv4) or /48 (IPv6) and drop the remainder; alternatively, map to country/ASN only.
  • Pseudonymous: keyed HMAC with truncation plus geography. Avoid plain hashing.

• Device identifiers (IDFA, Android ID, fingerprints):

  • Anonymous: drop. If necessary, keep device class and OS major version only.
  • Pseudonymous: replace with rotating surrogate (e.g., monthly-rotated HMAC). Rotate keys to cap linkage windows.

• Geolocation:

  • Anonymous: round to coarse grids (e.g., ≥20–50 km). Suppress if sparse or outside populous areas.
  • Pseudonymous: city-level only.

• Selfie images, video, audio, biometric templates, liveness frames:

  • Anonymous: delete entirely. Do not include biometric templates or feature vectors; these are high-risk for re-identification.
  • Pseudonymous: not recommended. If retained for model monitoring, keep only binary liveness outcome or quality bands; never store face embeddings in analytics datasets.

• Document images (passport, driver’s license, MRZ):

  • Anonymous: delete images. If business need exists (e.g., document type distribution), keep only document type and issuing country. Do not keep document numbers, MRZ strings, barcodes, signatures, or photos.
  • For rare document types/countries, consider suppression or aggregation.

• Vendor reference IDs, transaction/account IDs:

  • Anonymous: drop.
  • Pseudonymous: replace with internal surrogate IDs; vendor-to-internal mapping stored only in a secure reference system.

• Risk scores, verification outcomes, reason codes:

  • Keep but bin into coarse ranges (e.g., score deciles). Collapse rare reason codes into “Other” to avoid singling out.

• Free-text fields, analyst notes:

  • Run automated PII redaction (NER-based) plus dictionary/regex filters; if risk remains, drop entirely.

• Age and date of birth:

  • Anonymous: convert to age bands (e.g., 18–24, 25–34, …). For extreme ages, widen bands or suppress.
  • Pseudonymous: year of birth only.

3. Record-level and dataset-level protections

• k-anonymity and l-diversity:
  • Define quasi-identifier set appropriate to your data (e.g., {country/state, age band, week, device class, doc type}).
  • Enforce k ≥ 10 by generalizing or suppressing outliers.
• Differential privacy (optional for aggregates):
  • Apply DP mechanisms when releasing aggregate counts or rates externally; add calibrated noise and use privacy budgets.
• Sampling or aggregation:
  • For public sharing, prefer aggregated tables (counts/rates) with minimum cell size thresholds and DP noise.

4. Utility-preserving linkage without identity

• For within-dataset linkage: use session-level or event-level random IDs that do not map back to individuals.
• For cross-period linkage needed for trends but still anonymous: consider time-bounded keyed HMAC subject IDs with scheduled key destruction after analysis. Prior to destruction these are pseudonymous; after destruction, the dataset becomes anonymous and unlinkable going forward.

5. Validation and expert review

• Automated re-identification risk assessment:
  • Compute k-anonymity metrics and equivalence class sizes on the quasi-identifier set.
  • Check l-diversity for sensitive attributes (e.g., verification outcome or fraud flags).
  • Scan for residual PII via pattern matching (emails, phone formats, MRZ regex).
• Attack simulations:
  • Attempt linkage with plausible auxiliary data (e.g., public breach datasets at coarse geography/time).
• Expert determination (where required):
  • For high-stakes releases, obtain a written assessment by a qualified privacy expert documenting methods and residual risk.

6. Documentation and controls

• Data protection impact assessment covering purposes, techniques, residual risk, and mitigations.
• Transformation specifications versioned in code; store data lineage metadata for reproducibility.
• Public commitment

以下指南面向在组织内构建与运营化“训练数据匿名化”治理能力的团队。目标是在确保模型可用性的同时，将再识别风险降至组织可接受水平，并满足适用法规与合同要求。

一、核心原则

• 目的限定与最小化：仅收集与训练目标相关的数据字段；优先选择非个人数据和经合法授权的数据源。
• 合法性与可追溯：数据从采集到匿名化整个链路需具备合法处理依据与完整审计线索。匿名化本身属于一次合法处理活动，需记录处理依据与DPIA（如适用）。
• 风险导向与不可逆：匿名化应以可验证的再识别风险评估为基线，遵循“合理可能的手段”评估标准。可逆的处理（如可还原的映射）仅属于假名化。
• 可用性与可验证：在降低识别风险的同时，保留训练所需的分布特征与统计性质，并通过离线评测与隐私攻击测试验证。

二、关键定义（面向治理）

• 匿名化（Anonymization）：在合理可及手段下不可再识别到个人。匿名化后数据不再受个人数据法规约束，但需防“马赛克效应”与外部链接攻击。
• 假名化（Pseudonymization）：以密钥、表或算法可复原真实身份的替换；在GDPR等框架下仍是个人数据。
• 去标识化（De-identification）：泛称删除或修改直接标识符的处理。其效果可能仅达假名化，需风险评估判定是否达匿名化标准。

三、治理框架与角色

• 数据治理委员会：批准匿名化政策、风险阈值与例外策略。
• 数据保护官/法务：合规评估、跨境与合同限制审阅、DPIA组织与留存。
• 数据管理员（Data Steward）：字段级分类、敏感度分级、质量与可用性验收。
• 隐私工程/安全：技术方案设计（算法、密钥、隔离）、渗透与再识别攻击测试。
• MLOps/数据工程：流水线落地、版本化、可观测与回滚。

四、流程与控制（端到端）

1. 资产盘点与分级

• 建立数据目录与血缘，标注字段级敏感度（直接标识符、准标识符、敏感属性、自由文本、图像/音频、地理位置信息、日志/遥测）。
• 记录来源、合法性（合同、许可、同意、合法利益评估等）、保留期限与跨境限制。

2. 选择隐私模型与风险标准

• 结构化数据：k-匿名（抵御身份识别）、l-多样性与t-接近（缓解属性披露）；或基于差分隐私的噪声发布/合成。
• 非结构化数据：基于NER/正则/规则与模型的实体检测与替换；结合上下文脱敏。
• 确定组织风险阈值与评估方法（例如：再识别攻击场景清单、动机入侵者测试、专家评估）。避免依赖单一数值阈值；采用多方法交叉验证。

3. 技术处理策略（按数据类型）

• 直接标识符（姓名、身份证号、手机号、邮箱等）
  • 首选删除或不可逆替换；如需关联性，使用带密钥的单向HMAC或不可逆令牌；密钥与数据物理与逻辑隔离、轮换与HSM托管。
  • 明确：哈希（无盐）或可逆令牌化不等于匿名化，仅属假名化。
• 准标识符（出生日期、邮编、职业、公司、稀有属性）
  • 泛化（分桶：年龄段、邮编前三位）、抑制（缺失/置空）、微聚合（聚类后用均值/众数替换）。
  • 稀有组合需合并或抑制以提升k值；对长尾与异常值进行聚合或截断。
• 连续/数值型
  • 加噪（拉普拉斯/高斯，依据差分隐私预算）；区间化；四舍五入；尾部截断。
• 文本/代码/日志
  • 实体检测：多引擎（基于规则+模型）识别人名、地址、联系方式、账号、凭证、序列号、地理坐标、时间戳、设备ID等。
  • 替换策略：同类型占位符（如 ）、一致性映射（同一人跨文档同一占位符）、保持格式（邮箱格式校验）；去除文件/消息元数据与嵌入标识。
  • 对对话与指令数据，过滤包含机密/个人数据的样本；必要时合成等价样本。
• 图像/视频
  • 人脸与可识别特征（纹身、车牌、徽章）检测与模糊/像素化/遮挡；去除EXIF/地理元数据。
  • 对姿态、场景、医疗影像：区域化处理，不影响下游任务关键区域。
• 音频/语音
  • 语音伪装/变声；转写后应用文本脱敏；移除背景中可识别环境信息。
• 地理位置
  • 空间泛化（栅格化、行政区级）、随机位移（受控半径）、地理差分隐私（geo-indistinguishability）；限制轨迹长度与分辨率。
• 生物特征
  • 优先避免；必要时采用可撤销模板（cancelable biometrics）或经DP保障的聚合特征；严格访问与隔离。

4. 差分隐私与合成数据

• 训练前数据发布/共享：优先采用差分隐私统计/合成数据；明确ε/δ预算、合成质量与隐私审计报告。
• 模型训练中：对需要防止记忆与提取的任务，采用DP-SGD或教师-学生知识转移等方案；记录隐私预算与影响评估。
• 说明：差分隐私增强匿名化稳健性，但会引入效用损失；需在实验中选取合适预算并做任务级评估。

5. 质量与效用保障

• 定义保真指标：分布相似度（KS检验、Wasserstein 距离）、聚类/重要特征统计保持度、下游模型性能保留率。
• 保持参照完整性：跨表一致令牌化；外键关系不破坏；时间序列趋势保留。
• 记录不可逆处理导致的业务损失并评估替代方案（如特征工程替代、合成数据补偿）。

6. 再识别风险评估与验证

• 攻击面清单：链接公共数据集、长尾组合、稀有事件、外部泄露、模型记忆提取（训练数据提取、成员推断、反演）。
• 测试方法：
  • 动机入侵者测试与红队演练（在合理资源假设下尝试再识别）。
  • 唯一性分析与k-匿名度量；属性披露评估（l-多样性、t-接近）。
  • 文本与生成式模型：嵌入“金丝雀”字符串测试、提示攻击扫描个人数据模式（如身份证/信用卡/电话格式）与泄漏率；成员推断评估。
• 将评估报告、数据样本版本、参数与环境记录在案；不达标则迭代处理策略。

7. 安全与密钥治理

• 将假名化密钥、映射表置于隔离域（HSM/专用密钥库），采用最小权限、双人审批与严格审计。
• 加密静态与传输数据；匿名化前后环境隔离；禁用非生产环境访问原始数据。
• 在数据流与日志中启用DLP（数据泄露防护）以防二次暴露。

8. 文档与可追溯

• 产出并维护以下工件：
  • 匿名化政策与标准（字段级处理规则库、例外与容错标准）。
  • 数据清单、来源合法性与合约限制。
  • DPIA/威胁模型与再识别风险评估报告。
  • 质量与效用评测报告；模型隐私攻击评估。
  • 变更记录与版本控制；审计日志与批准记录。

9. 运营与持续改进

• 监测外部数据生态变化（新数据集发布、泄露事件、可用链接资源）与法规变更，定期复评。
• 设定KPI：再识别测试通过率、泄漏检测告警率、模型泄漏率、匿名化处理SLA与缺陷率、例外申请通过/驳回比。
• 建立异常响应：发现可能再识别风险或泄漏时的停机、隔离、通知与补救流程。

五、合规注意事项（示例性，需结合法务意见）

• GDPR/EEA：匿名化要求“不可再识别，考虑合理可能手段”；假名化仍为个人数据。跨境、用途限制与数据权利在匿名化前适用。
• HIPAA（如涉及医疗数据）：可采用“安全港”或“专家判定”去识别途径；日志与派生数据同样受范围约束，直至达到匿名化。
• 合同与许可：数据使用条款可能要求不可逆匿名化、禁止重识别与二次共享；保留删除、审计与报告义务。

六、常见误区与对策

• 仅删除姓名/电话不足以匿名化：准标识符组合可导致链接识别。
• 单纯哈希或可逆令牌等同匿名化是错误的：属于假名化，仍受监管。
• 忽视少数与极端值：长尾样本最易再识别，应聚合或抑制。
• 忽视模型记忆：即使源数据做过匿名化，不安全的训练可能记忆原文片段；需引入DP/去重/数据清洗与泄漏检测。
• 日志与监控：训练/推理日志、错报样本可能重新收集个人数据，需同等或更强的匿名化与访问控制。

七、与模型训练集成的具体实践

• 训练前
  • 数据契约：源系统输出即按字段规则脱敏；设置质量门禁与PII扫描门。
  • 数据去重与过滤：移除重复与超长文本，降低记忆风险。
  • PII检测+替换流水线：多引擎集成、抽样人工复核、单元与回归测试。
• 训练中
  • 对易泄漏的生成式任务，评估并采用DP-SGD；约束上下文长度与缓存；禁用明文样本可视化。
  • 用保密计算或隔离环境处理残余敏感样本。
• 训练后与部署
  • 红队：训练数据提取与成员推断；金丝雀曝光率测试。
  • 输出过滤：推理时启用PII/机密检测与屏蔽；速率限制与审核。
  • 模型卡与数据卡：记录隐私假设、数据来源、匿名化方法与已知限制。

八、工具与自动化（类别建议）

• 数据目录与血缘：数据发现、分类与追踪。
• PII检测：基于规则/词典/正则/NER模型的混合检测器，覆盖多语种与领域词汇。
• 匿名化引擎：支持泛化、抑制、微聚合、DP噪声、一致令牌化与格式保持。
• 评估工具：唯一性分析、k-匿名检查、分布对齐、再识别模拟、模型泄漏测试。
• 密钥与访问治理：HSM/KMS、零信任访问、细粒度审计。

九、落地清单（简要）

• 定义与批准匿名化政策、字段规则与例外流程。
• 搭建PII扫描与匿名化流水线，纳入CI/CD与数据门禁。
• 建立评估与红队机制；制定风险阈值与处置策略。
• 完成DPIA/法务审阅与合同合规检查。
• 运行监控、度量KPI并持续改进。

通过上述治理与工程并重的框架，组织可以系统性地将训练数据的个人可识别风险降至可接受水平，同时维持模型性能与合规稳健性。