📚 课程目录第3章数据分类与敏感数据识别

数据分类与敏感数据识别：自动分类策略、敏感字段标签、元数据管理

数据分类这东西，说白了就是给数据贴“身份证”。你不给数据分好类，后面的隐私增强全是瞎忙活。我刚做平台工程那会儿，有个项目直接拿全量数据去脱敏，结果把公开的日志也给加密了，业务查询直接崩掉。嗯，从那以后我才真正理解——分类是隐私增强的第一道关卡。

为什么非得先做分类？

你想啊，隐私计算的本质是“该保护的坚决保护，该开放的顺畅流动”。没有分类，你根本不知道哪些字段该加密、哪些该脱敏、哪些可以原样输出。我见过太多团队一上来就上差分隐私或同态加密，结果发现性能扛不住，回头一查，加密的数据里 80% 是公开的电话区号。这成本白花了。

所以，分类识别的核心目标就三个：

范围界定——明确哪些数据属于个人敏感信息（PII）、财务信息、医疗信息等。
分级治理——按敏感等级决定保护策略（比如 L1 公开、L2 内部、L3 机密、L4 绝密）。
元数据驱动——让保护策略能够自动适配数据变化，而不是写死规则。

关键认知：数据分类不是一次性的静态工作，而是随着业务和数据演进而持续的动态过程。自动分类策略 + 敏感字段标签 + 元数据管理，三者缺一不可。

自动分类策略：三种主力方式

我最早做分类时全是手写正则，后来数据量一大，发现根本写不过来。现在主流的自动分类策略有三种，我挨个说说。

策略类型	核心原理	优点	缺点
基于规则	正则表达式 + 关键词 + 数据模式（如身份证 18 位）	准确率高、可解释、执行快	维护成本高、难以覆盖变种
基于机器学习	文本分类模型（如 BERT、FastText）或聚类	泛化强、能发现未知敏感模式	需要标注数据、模型更新频繁
混合模式	规则做粗筛 + ML 做精判 + 人工兜底	兼顾精度与覆盖率	架构复杂，需协调管线

我的经验：推荐从混合模式起步。先拿规则覆盖 80% 常见敏感字段（比如手机号、邮箱、身份证），再用 ML 模型处理那些“像但又不太像”的字段。我有个项目用 FastText 做词语嵌入，把“客户社保账号”“税号”这类变体全抓出来了，效果比纯正则好不少。

具体怎么做？拿基于规则来说，你可以在数据流入时跑一个扫描器。比如下面这个伪代码思路：

// 数据分类扫描器核心逻辑
def classify_field(value, field_name):
    # 规则优先级：精确模式 -> 正则模式 -> ML预测
    if value in PREDEFINED_DICT:            # 精确匹配敏感词库
        return "L4", "SENSITIVE_KEYWORD"
    if re.match(r'^\d{17}[\dXx]$', value):  # 身份证正则
        return "L4", "ID_CARD"
    if re.match(r'^1[3-9]\d{9}$', value):   # 手机号
        return "L3", "PHONE"
    # 其他规则...
    if ml_model.predict(value) > THRESHOLD: # ML兜底
        return "L3", "ML_SENSITIVE"
    return "L1", "PUBLIC"

注意，规则引擎里一定要加白名单。我吃过一次亏：把测试数据里的“张三”当成真实 PII 给标记了，结果大量正常查询被拦截。嗯，从那以后我强制所有规则先过一遍白名单，再走敏感匹配。

敏感字段标签：你该怎么贴标签？

字段标签就是给每一个数据列或字段打上分类档位。标签体系设计得好，后续隐私策略引擎才能精准生效。

我个人习惯使用“分类-合规-技术”三级标签：

分类标签：PII（个人身份）、PHI（医疗健康）、PCI（支付卡）、FIN（财务）、PUB（公开）
合规标签：GDPR、CCPA、PIPL、HIPAA 等法规定义
技术标签：STRING、NUMERIC、DATE、BLOB 以及长度、格式

看一个实际标签示例：

{
  "field": "user_id_card",
  "classification": "PII",
  "compliance": ["PIPL", "GDPR"],
  "technical": {
    "data_type": "STRING",
    "length": 18,
    "format": "regex:^\\d{17}[\\dXx]$"
  },
  "sensitivity_level": "L4",
  "protection_policy": "AES-256加密"
}

这样的标签结构，让下游的脱敏服务、加密引擎、审计系统都能直接消费。我曾经遇到一个团队把标签存成 JSON 字符串挂在列注释里，结果血缘变化后标签忘了更新，差点酿成数据泄漏。所以标签一定要跟元数据系统联动，不能手工维护。

避坑指南：我曾经把敏感标签直接写死在后端配置文件中，结果业务改了字段名，标签却没同步。线上跑了一周才发现隐私策略全失效了。所以标签必须由元数据平台统一管理，并通过事件驱动自动刷新。

元数据管理：让分类活起来

数据分类不是贴完标签就完事了。数据在流动，表结构在变更，新字段不断冒出来。没有元数据管理，你的标签库就是一份过时的“考古报告”。

我建议平台工程团队至少要做好三件事：

元数据血缘追踪——记录数据从哪里来、经过哪些转换、流到哪个目标。一旦源字段标签变更，所有派生字段都要自动重新分类。
标签版本控制——每次分类规则或标签内容更新，都要产生新版本，并且能回溯。审计时最怕“说不清楚过去某个时间点是什么分类”。
自动重新扫描——元数据平台应定期或事件触发地对新接入的数据表执行分类扫描，并把结果写回标签存储。

下面是元数据管理模块的简化设计表：

能力	实现手段	我踩过的坑
血缘采集	使用 OpenLineage + Spark/Flink 插件	没处理视图和临时表，血缘不完整
标签存储	使用 MySQL 或 Neo4j 存储标签图	用 HashMap 放内存，一重启全丢
版本管理	标签表加 start_time / end_time 字段	忘了记录变更人，审计出问题
自动扫描	CDC 监听新表 + 触发分类 Job	没加限流，把数据库扫挂了

一句话总结：数据分类 = 自动策略做扫描 + 标签体系做表达 + 元数据管理做持续保鲜。三者闭环，才能为隐私计算提供可靠的“数据地图”。

你想想看，如果连自己手里哪些数据是敏感的都搞不清楚，后面的加密、脱敏、审计全是在打哑谜。把分类识别做好，后面每一步都能跑得更稳。我在团队里经常说：分类花的功夫，后面至少十倍收益。别嫌麻烦，这一步值得砸时间。