脱敏策略制定与数据分级

说实话，我在不少项目里见过这种情况：团队上来就买了一套脱敏工具，然后一股脑把所有字段都脱成同一个强度。结果呢？业务部门骂翻天了，说查询效率掉了80%，关键数据反而没保护到。根本问题不是工具不行，是策略没跟上。

脱敏策略，说白了就是回答三个问题：脱什么、脱到什么程度、怎么脱。而回答这些问题的前提，是你得先摸清家底——也就是数据分级。

数据分级：一切策略的起点

我个人的习惯是，先别急着写脱敏规则。你先拉一张清单，把你系统里所有涉及个人身份、财务、健康、认证相关的字段全列出来。然后按敏感度排个序。

分级模型很多，但万变不离其宗。我一般会套用下面这个四层分级法，简单实用：

分级之后，怎么做策略映射？

有了分级表，下一步是给它配上「脱敏动作」。这个映射关系决定了每个字段在什么时候、用什么方法脱。

下面这张图，是我在早期项目里自己画的一套映射逻辑，后来成了我给团队培训的标准材料。你先看看：

这张图展示了最核心的决策流程：从字段到分级，再到算法选择，最后绑定到策略模板。注意中间的「按字段-场景-用户角色」那一步，很多人会漏掉。同样的身份证号，在登录日志里和风控查询里，脱敏强度是不一样的。

制定策略时的三个关键决策

我在课上经常跟学员说，策略制定不是技术题，而是选择题。下面这三个点，你提前想清楚，能省一半的返工时间。

1. 场景区分：生产 vs 非生产

生产环境的数据，你根本不敢乱动。性能要求高，业务链路不能断。这时候优先级是动态脱敏 + 性能绕过。我曾在银行项目中遇到过，一个实时交易查询接口，在脱敏层卡了20毫秒，整个交易就超时了。后来我调了策略：把高频查询的L2字段移到预处理缓存中脱敏，而不是每次都实时算。

非生产环境，比如开发测试、BI分析，就可以上静态脱敏。甚至可以用全量遮盖，性能不是第一考虑。这里有个小技巧：测试环境的数据要保留分布特性，但值可以完全替换。比如「张三」变成「测试用户」，但年龄分布、地区比例要和线上一致，不然测试出来的SQL执行计划会不准。

2. 角色授权：谁看什么

这不是脱敏工具的事，是策略定义的事。但脱敏系统要能读懂角色的标签。举个例子：

• 客服岗：可以看手机号后4位，但不能看全部。
• 风控岗：需要完整身份证号做模型验证，但操作行为需审计。
• 运营岗：只看聚合后的脱敏数据，比如分桶后的年龄，不看具体出生日期。

这种策略在配置层面，其实就是一张角色-字段-脱敏级别的映射表。我习惯把它维护在配置中心里，而不是硬编码到应用里。

3. 一致性要求：同一客户ID散列在同一值

这是个大坑。很多团队做完脱敏才发现，两张表里同一个用户的手机号，因为脱敏算法每次生成不同的随机值，导致关联查询全废了。

策略模板化：让规则可管理

策略不写成死代码。我推荐的做法是模板化。用JSON或者YAML把每条规则定义清楚，然后丢到策略引擎里去解释执行。下面是一段我常用的策略模板结构：

{
  "policy_id": "POL_L3_MOBILE",
  "description": "手机号脱敏规则 - 高度敏感",
  "field_pattern": ".*mobile.*|.*phone.*",
  "sensitivity_level": "L3",
  "scenes": [
    {
      "env": "production",
      "roles": ["customer_service", "support"],
      "algorithm": "dynamic_masking",
      "config": {
        "mask_type": "保留前3后4",
        "format": "188****1234"
      }
    },
    {
      "env": "production",
      "roles": ["risk_control", "compliance"],
      "algorithm": "ff1_encryption",
      "config": {
        "key_id": "key_mobile_hmac_v2",
        "output_format": "encrypted_mobile"
      }
    },
    {
      "env": "non_production",
      "roles": ["*"],
      "algorithm": "static_replacement",
      "config": {
        "replacement_value": "138****0000",
        "preserve_first_three": true
      }
    }
  ]
}

看到没？一个字段的脱敏规则，被环境、角色、算法三层条件拆开。这样做的好处是：新增场景不需要改代码，改策略模板重新加载就行。

策略表：落地前的最后一步检查

理论扯了一堆，最后落到一张可执行的策略表里。我一般在项目里会用类似下面这张表，拿给所有相关方（业务、安全、DBA）签个字，再进开发。

一点总结

策略制定这件事，看上去是「定几个规则」，其实背后是整个数据治理的体系。我建议你从最小的业务场景开始试点，比如只做用户手机号和身份证号的L3级脱敏。跑通流程之后，再逐步接入新的字段和场景。别一上来就想把几千个字段全脱了，那不是策略，那是给自己挖坑。

数据分级就是你的地图。地图画清楚了，脱敏策略这条路上的弯弯绕绕，你才能看明白。