第2章 数据分类分级基础
好，我们正式开始聊数据分类分级。你可能会问：为什么非得先折腾这个？说白了，如果你连自己家里有啥资产都不清楚，那谈何保护？数据也是一样的道理。
我个人习惯把分类分级看作整个敏感数据工作的地基。地基没打牢，上面盖的楼（风险评分、策略配置、自动化发现）全得塌。在开始之前，我们先明确一下核心逻辑。
核心认知：数据分类解决的是“数据是什么、属于哪一类”的问题；数据分级解决的是“这个数据如果泄露，后果有多严重”的问题。分类是“分堆”，分级是“定级”。两者缺一不可。
2.1 数据分类的方法论
分类这事儿，其实没有一套放之四海而皆准的模板。我在项目中遇到过很多客户，上来就问：“有没有现成的分类表？我直接套用。”答案是：可以借鉴，但不能照搬。
为什么？因为每个企业的业务属性不同。银行关注交易数据、客户隐私；药企关注临床试验数据、研发配方；互联网公司关注用户行为、日志。分类必须跟着业务走。
常见的分类视角有下面这几种：
- 按业务功能划分：财务数据、人力资源数据、研发数据、市场数据、供应链数据。这是最自然的切分方式，业务部门最容易理解。
- 按数据主体划分：个人数据（客户/员工/合作伙伴）、组织数据（公司内部文档/合同/战略）、公共数据（行业报告/公开资料）。
- 按数据形态划分：结构化数据（数据库表）、半结构化数据（JSON/XML/日志）、非结构化数据（文档/图片/邮件）。
- 按生命周期划分：原始数据、加工数据、分析数据、归档数据。
实用技巧：我个人建议先从“业务功能”和“数据主体”两个维度交叉分类。比如：“客户-PII数据”、“财务-交易明细”、“研发-源代码”。这样交叉出来的类别既清晰，又容易落地到后续风险评分。
在实际搭建分类体系时，你会遇到最头疼的问题：粒度。分得太粗，每类数据量巨大，没法做精细管控；分得太细，类别上百个，标签管理成本爆炸。
我曾经见过一个团队，一口气搞了80多个分类标签，结果一年后维护人员离职，新来的人根本搞不清“研发-实验记录-第三版-草稿”和“研发-实验记录-第三版-定稿”的区别。嗯，这里要注意：分类的粒度控制在20-30个一级标签，每个一级标签下不超过5-10个二级标签。超过这个数，你就该反思是不是分得太细了。
2.2 数据分级标准
分级和分类不一样。分类偏“是什么”，分级偏“有多严重”。我常说一句话：分级决定了安全策略的强度。
一个典型的四级分级体系，长这样：
| 等级 | 名称 | 定义 | 典型示例 | 泄露影响 |
|---|---|---|---|---|
| L1 | 公开 | 可以对外发布，无保密要求 | 产品宣传册、官网新闻、公开财报 | 几乎无影响 |
| L2 | 内部 | 仅限公司内部使用，禁止外传 | 内部流程文档、员工手册、项目管理文件 | 轻微负面影响 |
| L3 | 敏感 | 泄露会对公司或客户造成重大损失 | 客户PII、财务明细、源代码、商业计划 | 严重负面影响 |
| L4 | 绝密 | 泄露将导致公司生存危机或承担法律责任 | 核心算法、关键合成路线、法律诉讼文档 | 灾难性影响 |
你想想看，这个分级最怕什么？最怕“评级膨胀”。所有人都觉得自己管的数据是“绝密”，结果L4的标签贴得到处都是，真正需要重点保护的核心资产反而被淹没了。
避坑指南：我曾经吃过大亏——当时一个客户把所有研发资料都标成了L4绝密，结果安全团队在做数据发现时抓出几万份“绝密”文档。根本没法做优先级排序，投入巨大资源却保护了80%的废纸。记住：级别要有区分度，L3和L4加起来不要超过总量的15-20%。
那么，如何确定一个数据集应该落在哪一级？这里有一个简单的评判矩阵：
- 影响范围：泄露影响多少人？个人（L2）、小团队（L3）、全公司/所有客户（L4）？
- 影响程度：泄露后果是什么？轻微名誉损失（L2）、经济损失/合规罚款（L3）、业务中断/法律诉讼（L4）。
- 法律合规要求：该数据是否受GDPR/PIPL/PCI-DSS等法规约束？如果涉及，至少定到L3。
2.3 分类与分级的衔接
前面说了分类和分级是两个维度，但实际工作中它们必须结合。我用一个简单的例子说明：
同样是“财务报表”，如果是对外公开的财报，级别可能是L1公开；如果是每月的内部管理报告，级别可能是L2内部；如果是未公开的季度损益预测，级别至少要定到L3敏感。
所以，同一个分类下，不同数据资产可以有不同级别。你没必要把整个“财务数据”类全定成L3，那太粗暴了。
实用建议：在实现时，可以给每个分类+分级的组合一个唯一的“安全标签”。比如：“客户-PII-L3”、“财务-交易明细-L3”、“研发-源代码-L4”。这样后续的风险评分、数据发现策略、访问控制策略都能基于这个标签做精确匹配。
2.4 案例实践
我们拿一个实际场景来跑一遍。假设你在一个中型电商公司做数据安全，手里有下面几类数据：
- 客户注册信息：姓名、手机号、邮箱、地址。按主体分：客户数据；按业务分：CRM。应该定L3敏感。
- 商品浏览日志：用户ID、商品ID、浏览时间。按分析属性分：行为数据。级别定L2内部即可。
- 支付交易流水：订单金额、支付方式、卡号后四位。按业务分：财务/交易。涉及金融合规，定L3敏感。
- 内部定价算法：商品定价策略、折扣计算逻辑。按研发分：核心算法。定L4绝密。
你看，这个分类分级打完，安全团队就知道：L4的定价算法需要加密存储+严格访问控制+审计日志；L3的客户信息和交易流水需要脱敏后才能用于开发测试；L2的浏览日志做基本的防泄露监控就行。
# 伪代码示例：自动分类分级的规则引擎片段
def classify_and_grade(data_asset):
# 分类逻辑
if "customer" in data_asset.tags or "pii" in data_asset.tags:
category = "客户数据"
elif "finance" in data_asset.tags or "transaction" in data_asset.tags:
category = "财务数据"
elif "algorithm" in data_asset.tags or "source_code" in data_asset.tags:
category = "研发数据"
else:
category = "内部数据"
# 分级逻辑（依赖于影响评估）
if "payment" in data_asset.tags or "pii" in data_asset.tags:
grade = "L3"
elif "algorithm" in data_asset.tags:
grade = "L4"
else:
grade = "L2"
return {"category": category, "grade": grade}嗯，这段代码其实简化了不少。真正生产环境里，你还要考虑数据量级、存储位置、所有者部门等更多因子。但核心思想没变：先分堆，再定级。
好了，这一章我们就把分类分级的基础打牢了。接下来你就可以基于这个分类分级体系，去搭建数据发现规则和风险评分模型了。