📚 课程目录第4章数据分类与分级

数据分类与分级：敏感数据识别方法、等级划分标准与自动化策略

很多人问我，数据分类分级到底难在哪？
说实话，技术本身并不复杂。真正麻烦的是——你得先知道哪些数据是敏感的，然后才能谈怎么保护。

我接手过一个银行的项目，客户说“我们数据都分类了”。结果一查，他们把“客户手机号”和“客户平均消费金额”归到了同一个级别。这就出问题了。手机号是典型的个人敏感信息，消费金额可能只是业务指标。混在一起，安全策略怎么定？

所以这一章，我们重点解决三个问题：
怎么识别敏感数据？
怎么划分等级？
怎么让这件事自动化？

  一句话核心：分类分级是数据安全的基石。没有它，DLP、加密、脱敏统统无从下手。

4.1 敏感数据识别方法

敏感数据识别，说白了就是“找茬”。
你得能把藏在数据库、文件共享、云存储里的关键数据揪出来。

我个人习惯把识别方法分为三类：

基于规则的模式匹配——最常用，也最直接
基于机器学习的模型识别——能处理非结构化数据
基于指纹/水印的溯源识别——适合已知样本

先看第一种。正则表达式是基本功。

举个例子，识别信用卡号：

# 简单版正则
\b(?:\d[ -]*?){13,16}\b

# 加强版（带Luhn校验逻辑）
\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13})\b

我在一个项目里遇到过这种情况：
他们用现成的正则库扫描了全库，结果把一批“对公账户编号”也误报成信用卡号了。为什么？因为格式太像。后来我们加了上下文特征，比如“字段名包含credit、card”才压住误报。

所以，纯规则识别有硬伤——
容易误报，也容易漏报。尤其是面对非结构化数据时。

这时候就该上模型了。

识别方法	适用场景	优点	缺点
正则表达式	明文敏感数据（身份证、手机号、银行卡号）	速度快、精准	容易变种，维护成本高
词典/关键词匹配	业务字段、文件名、表注释	实现简单	依赖人工维护词库
机器学习分类	非结构化文档、邮件、聊天记录	泛化能力强	需要训练数据，部署成本高
向量指纹	已知敏感样本的变体检测	抗混淆能力强	需要预建指纹库

实际操作经验：我建议先用规则做第一轮粗筛，把明确的敏感字段标出来；再用模型对“模糊地带”做二次判断。这样效率最高。

4.2 等级划分标准

识别出来之后，怎么定级？
这其实是整个DSPM项目里最难达成共识的一环。
为什么？因为业务和安全视角天生冲突。

业务方觉得“这个数据很重要但有没有那么敏感”，安全方觉得“只要被人看到就有风险”。
你夹在中间怎么办？

我的原则是：参考国标，结合实际。

先看主流的分级模型。我最常用的是四层分级：

L0 - 公开数据：新闻稿、产品手册、联系方式
L1 - 内部数据：组织架构、内部审批流程、非敏感报表
L2 - 敏感数据：员工薪资、客户非敏感信息、业务明细
L3 - 核心敏感数据：身份证号、银行卡号、生物特征、商业机密

但光有分级不够。
你还要明确“什么类型的敏感数据该归到哪一级”。这里我常用一个矩阵。

数据类别	举例	建议等级	核心判断依据
个人基本信息	姓名、性别、年龄	L2	单独不能直接导致身份盗用
个人身份标识	身份证号、护照号	L3	可唯一识别且不可更改
金融账户	银行卡号、交易密码	L3	直接关联资金安全
生物特征	指纹、人脸、声纹	L3	不可撤销的标识
业务统计数据	季度销售额	L1	不涉及个人隐私
健康/医疗数据	病历、诊断结果	L3	高度隐私，泄露后果严重

踩坑提示：我曾经遇到过一个团队，把“客户手机号”全部标为L3。但业务部门反馈说他们每天要用手机号做营销推送，拦截策略一开直接导致业务中断。
所以，分级不能脱离业务场景。同一个数据字段，在订单表里是L3，在脱敏后的分析表里可能降到L1。

4.3 自动化策略

手工分级？别想了。
一个中型企业可能有上千张表、几万个字段，还有数不清的文件和对象存储。人工根本做不完，而且容易出错。

自动化分级，核心靠两个东西：

自动识别引擎——上面讲的那几种方法跑起来
分级策略引擎——识别结果匹配到等级

我做一个简单的策略示例给你看：

# 伪代码：自动化分级策略
for each_data_object in data_inventory:
    # 1. 识别敏感字段
    tags = identify_sensitive_fields(each_data_object)
    
    # 2. 判断最高敏感级别
    if "id_card" in tags:
        level = "L3"
    elif "phone_number" in tags and "real_name" in tags:
        level = "L3"  # 组合字段升级的典型场景
    elif "email" in tags or "address" in tags:
        level = "L2"
    else:
        level = "L1"
    
    # 3. 写入元数据标签
    set_metadata_tag(each_data_object, "data_sensitivity", level)

你注意到没有？
上面这个逻辑里最关键的一行是：组合字段升级的判断。

单独的“手机号”可以算L2。但如果这条记录同时包含了“手机号”和“真实姓名”，合在一起就能唯一锁定一个人，这时候就应该升级到L3。这叫“组合敏感性”，是自动化策略里最容易忽略的地方。

我优化过不止一套自动化策略。我记得有一次，一个客户的策略只顾识别单个字段，结果“HTTP_Referer”字段和“Source_IP”字段放在一起，居然被某个流量分析系统泄露了用户的访问行为轨迹——这件事让我们后来专门增加了一个“关联分析”步骤。

再看一个更完整的自动化流程：

自动化策略配置要点：

先做全量扫描，再做增量扫描
设置定时任务，配合数据变更事件触发
分级结果要写入数据资产目录，不要只存在于安全系统里
保留历史版本，方便回溯审计

最后说一句：自动化不是一次性搞定的。
数据在变，业务在变，法规也在变。你的自动化策略必须能持续迭代。

我见过最惨的案例：
一家公司花三个月做了一套自动分级规则，上线后半年没更新。结果新增加了一批“用户行为轨迹”数据，系统自动分到了L1。直到出了泄露事故才被发现。这时候再回头改，已经晚了。

关键提醒：自动化策略一定要有“人机协同”的回退机制。自动识别结果出来后，必须给人工审核留窗口。尤其是L3级别的定级结果，我建议强制要求人工确认。

嗯，总结一下：
识别方法是基础，分级标准是框架，自动化策略是落地工具。
三者缺一不可。而且，你永远不要指望一套规则用到底。
定期复盘、定期更新，才是数据安全管控的正道。