数据分类与敏感数据识别：找到需要保护的那些字段

说实话，做令牌化防泄漏，第一步不是选工具，也不是定策略。第一步很简单——你得先搞清楚，你到底要保护什么。

我见过不少团队，上来就兴致勃勃地部署数据防泄漏系统，结果发现告警满天飞，该漏的没防住，不该管的管得死死的。为什么？因为数据分类没做好。你想想看，连哪些字段是核心机密都没分清楚，保护策略怎么可能精准？

先说数据分类：别把鸡蛋都放一个篮子里

数据分类，说白了就是把数据按业务价值、机密程度、合规要求分门别类。我最常用的分类维度有三个：

• 业务属性维度：客户数据、员工数据、财务数据、产品数据……先按业务域切一刀，这样后面做访问控制时直接跟业务团队对表。
• 特征分级维度：这是分类的核心，直接决定了令牌化的覆盖范围。我个人习惯分四级：

级别	定义	典型字段示例
L4 - 极度敏感	一旦泄露，会造成严重经济损失、法律诉讼或重大声誉危机	银行卡号（明文）、身份证号、医疗诊断记录、生物识别特征
L3 - 高度敏感	泄露后会导致个人隐私侵害、商业机密外泄	手机号、邮箱+密码组合、财务报表、核心算法参数
L2 - 中度敏感	泄露会造成一定不便，但风险可控	姓名、家庭住址、普通工作邮件、内部培训资料
L1 - 公开/低敏	泄露不影响运营和合规，甚至可对外公开	公司官网信息、公开白皮书、门店地址

我曾经帮一家医疗公司做数据治理，他们把所有患者数据都标成了「高敏感」，结果令牌化成本翻了 3 倍。后来我建议他们把「患者挂号时间、科室编号」这类字段降级到 L2，只对「姓名 + 身份证 + 诊断结果」做 L4 级令牌化。嗯，效果立竿见影。

再说敏感数据识别：怎么把那些字段揪出来

分类是套路，识别是落地。分类定好了级别，接下来要做的是：哪些字段属于哪个级别。

识别敏感字段，我一般分三步走：

1. 自动扫描：用正则表达式、数据字典去扫描数据库表结构、日志文件、配置文件。这步速度快，能覆盖 80% 的常见敏感字段。
2. 人工标注：自动扫完，拉上业务负责人一起过一遍，确认分类是否准确。这一步我最重视，因为自动扫容易漏掉「新创字段」或「跨境传输字段」。
3. 动态采样：从生产环境抽取少量真实数据样本，看字段内容是否跟分类一致。比如，一个字段名叫「user_id」，里面存的是手机号还是 UUID？必须看数据内容。

我习惯把识别到的敏感字段清单做成一张表格，里面至少包含以下字段：

• 数据源名称（比如：核心交易库_oracle19c）
• 表名
• 字段名
• 数据分类级别（L1-L4）
• 识别依据（正则/字典/人工）
• 业务负责人

分级打标：让每一条数据都有身份

分类和识别都做完了，接下来要给数据打标签。打标的作用很简单：让后续的令牌化策略、访问控制策略、审计策略，直接能读到这条数据该不该保护、保护到什么程度。

我推荐用 标签 + 元数据 的方式。标签写安全等级，元数据写业务上下文。比如：

数据标签示例：
{
  "field": "customer_phone",
  "classification": "L3",
  "tokenization": "required",
  "retention_policy": "90_days",
  "business_owner": "CRM_team"
}

这样，后面配置令牌化规则时，直接匹配 classification == "L3" 就能把所有需要保护的手机号字段一次性覆盖到。

一个简单流程，帮你串起来

下面这张图，是我自己项目里用的标准化流程。从数据源到最终打标，一共五步，每一步都对应一个交付物。

落地时你可能会遇到的坑

流程看着不复杂，但实际执行起来，容易翻车的地方不少。我把我遇到的集中问题列一下：

• 分类标准太粗：比如只分「机密」和「公开」两级，结果 90% 的数据都归入机密，等于没分级。
• 忽略了非结构化数据：很多敏感字段藏在 Word、PDF、聊天记录里。单纯扫描数据库是不够的。
• 分类后没人维护：我见过一家公司，分类清单半年更新一次，新上线的业务字段全漏了。

分类结果怎么关联到令牌化

好了，现在你手里有一张完整的敏感字段清单，上面标好了每个字段的级别。接下来，令牌化策略直接按这张清单来配置即可：

• L4 字段：强制全部令牌化，且使用带密钥保护的格式保持型令牌（FPE），不允许存储明文。
• L3 字段：按场景令牌化，比如在开发测试环境做令牌化，生产环境可保留部分明文用于业务查询。
• L2 字段：可考虑不需要令牌化，只做脱敏或访问控制即可。

你看，这样一步步下来，令牌化的范围、令牌类型、加密强度，全有了明确的输入。后面的配置工作，就不会是拍脑袋做决定，而是有据可依的。