3. 脱敏需求分析与策略设计
脱敏工程最容易失败的地方，不是算法不够强，而是需求没定清楚。业务方说“手机号要脱敏”，安全方说“必须不可逆”，数据方说“脱敏后还要能关联分析”，三方各说各话，最后交付的脱敏结果要么不可用，要么不安全。本节的核心任务，是把模糊的业务诉求翻译成可执行的字段级策略：先明确用途，再定强度、可用性与一致性三条约束，最后落到字段策略、角色权限矩阵和审批流程上。
一、从业务用途反推脱敏需求
脱敏强度不是越高越好，而是由“谁、在什么场景、用这份数据做什么”决定的。同一个手机号字段，在客服工单场景需要保留后四位以便核对身份，在营销画像场景只需要保留号段用于地域统计，在对外数据交换场景则必须完全遮蔽。因此需求分析的第一步是收集用途清单，而不是直接讨论算法。
建议按“数据使用场景登记表”的方式收集，每个场景至少记录：使用方角色、数据范围、使用目的、使用方式（查询/导出/建模/共享）、保留期限、是否允许关联到个人。下表给出一个示例登记片段（示例数据，仅用于说明结构）：
| 场景编号 | 使用方 | 字段范围 | 用途 | 使用方式 | 可接受强度 |
|---|---|---|---|---|---|
| S-01 | 客服坐席 | 手机号、姓名 | 身份核验 | 在线查询 | 保留后四位，姓名保留姓氏 |
| S-02 | 数据分析师 | 手机号、地区、消费额 | 区域消费分析 | 离线建模 | 号段保留，其余遮蔽 |
| S-03 | 外部合作方 | 手机号、身份证号 | 联合建模 | 数据交换 | 不可逆假名化 |
| S-04 | 测试环境 | 全量客户表 | 功能验证 | 库表复制 | 格式保留、值随机 |
登记完成后，把每个场景映射到具体字段，形成“字段—场景—强度”的对应关系。这一步是后续所有设计的输入，缺了它，策略就只能靠猜。
二、三条约束：强度、可用性、一致性
脱敏强度描述的是还原难度。工程上通常分四档：可逆加密（授权可还原）、不可逆哈希（固定盐或加盐）、假名化（可关联但不可识别）、遮蔽/泛化（部分字符替换或区间化）。强度越高，安全收益越大，但可用性损失也越大。
可用性描述脱敏后数据还能支持哪些操作。常见判断点包括：是否需要精确匹配、是否需要范围查询、是否需要分组统计、是否需要跨表关联。例如手机号若用于“按号段统计”，则保留前三位即可；若用于“同一用户跨表关联”，则必须保证同一原始值在多次脱敏后得到相同结果，这就对一致性提出了要求。
一致性包含两层：一是同一字段在不同表、不同批次中脱敏结果稳定，避免关联断裂；二是同一字段在不同场景下若使用不同强度，需要明确是否允许交叉比对。实践中常用“加盐哈希 + 固定盐值”保证跨表一致，用“场景独立盐值”阻断跨场景关联，两者不可混用。
三、字段级脱敏策略
字段级策略是脱敏工程的执行单元。每个字段应明确：敏感级别、脱敏方式、参数、适用场景、例外条件。下面给出一个可直接参考的策略表结构（示例参数，需按实际合规要求调整）：
字段: 手机号
敏感级别: L3
默认方式: 遮蔽
参数: 保留前3后4，中间以*替代
例外场景: S-01 客服核验 -> 保留后4位
一致性要求: 同一用户跨表关联时使用固定盐哈希
校验规则: 输出长度=11，字符集为数字与*
字段: 身份证号
敏感级别: L4
默认方式: 不可逆哈希
参数: SHA-256 + 固定盐，输出截断为16位十六进制
例外场景: 无
一致性要求: 全库统一盐值
校验规则: 输出长度=16，仅含0-9a-f
字段: 客户姓名
敏感级别: L2
默认方式: 泛化
参数: 仅保留姓氏，名以*替代
例外场景: S-01 客服核验 -> 保留全名
一致性要求: 不要求跨表一致
校验规则: 输出长度=原长度，首字符为汉字策略表写完后，必须做一次“反向验证”：拿每个场景去套策略，看是否出现“该遮的没遮”或“该留的没留”。例如 S-02 需要按号段统计，若手机号被完全哈希，则统计失效；S-03 需要联合建模，若手机号仅遮蔽，则合作方可直接看到真实号段，存在泄露风险。这类冲突要在设计阶段暴露，而不是上线后才发现。
四、角色权限矩阵与审批流程
脱敏策略解决“数据变成什么样”，权限矩阵解决“谁能看到什么形态的数据”。矩阵的行是角色，列是字段或字段组，单元格填写该角色可访问的脱敏形态。例如：
| 角色 | 手机号 | 身份证号 | 姓名 | 消费金额 |
|---|---|---|---|---|
| 客服坐席 | 保留后四位 | 完全遮蔽 | 全名 | 可见 |
| 数据分析师 | 号段保留 | 哈希 | 姓氏保留 | 可见 |
| 外部合作方 | 哈希 | 哈希 | 泛化 | 区间化 |
| 测试人员 | 随机替换 | 随机替换 | 随机替换 | 随机替换 |
矩阵确定后，任何超出矩阵范围的访问都必须走审批。审批流程不宜过长，但必须包含三个关键判断：申请人角色是否与场景匹配、申请字段是否超出该场景最小必要范围、脱敏形态是否满足用途且不降低安全等级。一个可落地的审批流如下：
- 申请人提交场景编号、字段清单、使用期限、脱敏形态需求。
- 数据Owner核对场景登记表，确认用途真实且字段最小必要。
- 安全岗核对策略表，确认脱敏形态不低于该字段默认强度，若低于则要求补充说明或拒绝。
- 审批通过后，系统按“角色+场景+字段”生成临时授权，到期自动回收。
五、需求到策略的闭环示意
下图把本节的核心关系压缩为一条可追踪的链路：业务用途驱动强度、可用性、一致性三条约束，三条约束共同决定字段级策略，字段级策略再与角色权限矩阵、审批流程对接，最终形成可执行、可审计的脱敏方案。
这张图的关键在于“回写”那条虚线：审计发现的例外、偏差和回收记录，必须反向修正字段策略和权限矩阵，否则脱敏方案会随着业务变化逐渐失真。实际落地时，建议把策略表、矩阵和审批记录都纳入版本管理，每次变更留痕，这样在合规检查或安全事件复盘时，才能快速回答“谁在什么时候、以什么形态、访问了哪些字段”。
最后提醒一点：脱敏需求分析不是一次性的文档工作，而是持续校准的过程。业务用途会变，合规要求会变，数据分布也会变。把“用途—约束—策略—矩阵—审批—审计”这条链路固定下来，并保持可追踪、可回写，脱敏工程才具备长期可维护性。