📚 课程目录第3章数据分类方法

数据分类方法：基于内容、上下文、标签的分类技术

做DLP系统，最核心的问题就一个：你怎么知道这份数据是敏感的还是不敏感的？

说实话，我在刚接触DLP那会儿，觉得这事儿挺简单。写几个关键词，匹配到了就拦截呗。结果上线第一天，法务部发来的合同被误拦了二十多次，销售部的报价单反而全放过去了。嗯，从那以后我才明白——数据分类没那么简单。

我个人习惯把分类方法分成三派：基于内容的、基于上下文的、基于标签的。这三派各有各的绝活，也各有各的短板。你想想看，一个成熟DLP系统，其实三样都得用上。

基于内容的分类

说白了，就是看数据本身长什么样。这是最直觉的方法，也是大多数团队入门DLP时的首选。

怎么做呢？无非三种路子：

关键词匹配：像"机密"、"保密"、"内部文件"这些词，命中即告警。简单粗暴，但误报率不低。
正则表达式：身份证号、信用卡号、手机号这些有固定格式的数据，用正则一把抓。我在项目中遇到过一个大坑——正则写得太松，把订单编号也识别成身份证了，一天告警两万条。
指纹/哈希：把敏感文档算个指纹存下来，以后遇到内容一样的就命中。适合合同、设计图纸这种不变的文件。

注意：千万不要只依赖关键词匹配。你想想看，一份合同里把"机密"改成"敏感"，关键词就失效了。指纹识别虽然准，但文件改几个字指纹就变了。所以基于内容的方法往往需要组合使用。

来，看一段实际可用的正则分类代码：

import re

# 常见的敏感数据匹配规则
SENSITIVE_PATTERNS = {
    "身份证号": r"\b[1-9]\d{5}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]\b",
    "信用卡号": r"\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9]{2})[0-9]{12})\b",
    "手机号": r"\b1[3-9]\d{9}\b",
}

def classify_content(text):
    """基于内容的数据分类引擎"""
    matched_types = []
    for label, pattern in SENSITIVE_PATTERNS.items():
        if re.search(pattern, text):
            matched_types.append(label)
    if matched_types:
        return {"level": "sensitive", "types": matched_types}
    return {"level": "normal", "types": []}

这段代码我一直在用。它不复杂，但足够应对七八成的明文敏感数据识别场景。注意正则的边界符 \b，不加的话"12345678901"这种普通数字串也会被误认成手机号。

基于上下文的分类

只看内容本身，有时候会误判。举个真实的例子：一份名为"薪资调整说明.xlsx"的文件，内容里没有任何关键词，但它的存放路径是 \\财务共享\\薪资\\2025年\\，创建者是HR总监，修改时间是凌晨两点。这些上下文信息远比内容本身更能说明问题。

我习惯把上下文分成这几类：

上下文维度	典型特征	敏感判定示例
位置上下文	文件路径、数据库表名、API端点	含"salary"、"finance"、"confidential"路径
用户上下文	角色、部门、权限等级	HR、财务、法务人员创建/访问的文件
行为上下文	操作时间、频次、设备	凌晨批量下载、异常高频访问
关联上下文	同目录文件类型分布、历史行为基线	目录下80%文件带"机密"标签

我记得有一次帮一家银行做数据分类优化。他们的DLS系统用关键词匹配，把"不良贷款率"这个词当成了敏感词，结果所有风控报表全被拦截了。后来我加了上下文规则——只有"不良贷款率"出现在对外报告模板中才告警，内部报表直接放行。告警量下降了87%，业务终于不骂人了。

我的一个小技巧：上下文分类最好做成"加分项"而不是"一票否决"。比如内容分类打了60分，上下文再给它加30分，总分超过阈值再告警。这样比单一规则灵活得多。

基于标签的分类

标签分类跟前两种不太一样。它不靠猜，而是靠"标记"。说白了就是事先告诉系统：这份文件是绝密，那份是公开。系统记住了，以后遇到就知道怎么处理。

标签的来源主要有三种：

用户手动标记：用户在创建文档时选择分类级别。好处是准确，坏处是——人往往会漏标、忘标、乱标。
自动标记引擎：系统通过内容+上下文分析，自动给数据打标签。我建议优先用这种方式，它既可以兜底，又可以修正人工标记的错误。
策略继承：数据从哪个系统来的，就继承那个系统的标签。比如从CRM导出的客户数据，自动继承"客户敏感"标签。

标签分类最怕什么？标签爆炸。我曾经在一个客户现场看到，他们的标签系统里有3000多个自定义标签，很多标签之间没有层级关系，分类策略根本写不下去。最后我帮他们合并成5个一级标签、20个二级标签，策略一下子就清晰了。

避坑指南：标签的继承和传播要小心。我曾经见过一个案例：A文件带"机密"标签，被复制了一份，副本的标签竟然掉了，结果副本被当普通文件发到了外网。所以标签一定要做到"附着式继承"——不管怎么复制、转存、改名，标签始终跟着内容走。

三种方法怎么选

没有银弹。每种方法都有它的主场：

方法	优点	短板	适合场景
基于内容	见效快、规则直观、无需历史数据	误报率高、容易被绕过、性能开销大	明文敏感数据、合规审计、DLP初期建设
基于上下文	准确率高、误报率低、能发现隐形风险	依赖元数据质量、需要行为基线	异常行为检测、数据外发监控、内部威胁防护
基于标签	精确可控、策略可追溯、管理成本低	依赖前期标记、标签维护有工作量	结构化数据管理、数据分级治理、长期稳定的分类体系

核心要点：成熟的DLP系统从来不只用一种方法。我通常的搭法是——先用内容分类做第一道筛子，把明显敏感的数据拦住；再用上下文分类减少误报；最后用标签分类做精细化管控，把分类结果沉淀下来反哺给前两种方法。形成一个闭环。

实战中的组合策略

拿我最近做的一个项目来说吧。客户是做在线教育的，有大量的学生资料、课程视频和内部教研文档要保护。

我是这么搭的：

学生身份证号、银行卡号 → 基于内容（正则匹配），直接命中就告警，这个不能含糊。
教研团队共享的设计稿 → 基于上下文（目录路径+用户角色），只有"课程研发部"的人访问才算正常，其他部门访问就要告警。
已经定密的教学大纲 → 基于标签（手动标记+自动继承），打上"教研机密"标签，不管文件走到哪都认这个标签。

三层叠加，漏报和误报都控制在了0.5%以内。你想想看，如果只靠其中一种，能做到这个精度吗？难。

所以我的观点一直是：不要纠结哪种方法最好，而是考虑你的场景里哪几种方法搭配最合适。