第4章：数据分类维度与方法归纳总结

数据分级分类，听起来是个挺大的题目。

我刚开始做这个项目时，也有点懵。到底按什么分？分几级？用业务属性还是安全属性？

说白了，这背后就是一套维度和方法的组合。你选对了，后面落地就顺。选错了，就会像我在一个项目中那样——返工三次，被业务部门追着骂。

业务维度：先搞清楚“谁的”、“什么”

我最习惯的切入点，是业务维度。为什么呢？因为业务部门最熟悉数据。

• 数据所有者：这个数据属于哪个部门？财务、人力、还是研发？
• 数据域：客户信息、财务账务、供应链参数……不同域敏感性不同。
• 数据形态：是结构化表格？半结构化日志？还是非结构化的文档？

我记得有一次，客户把“订单金额”和“订单备注”放在同一个域里。结果金额要加密，备注里全是客服对话，又涉及用户隐私。嗯，这就是维度没拆细的坑。

安全维度：敏感度是核心

安全维度决定了数据的“保护强度”。

你怎么判断一个数据有没有“敏感度”？经验就三点：泄露后果、合规要求、内部知情范围。

我通常会先问自己几个问题：

• 这数据丢了，公司会不会赔钱？（比如GDPR罚款）
• 这数据被员工同事看到，会不会引发投诉？
• 这数据流出到外网，竞争对手会不会笑死？

如果三个问题里有两个“是”，那这数据至少得标个“内部敏感”。当然，更严格的企业会引入“密级”概念：公开、内部、敏感、绝密。

管理维度：所有权与生命周期

还有一个维度很容易被忽略，就是管理维度。说白了，这关系到“谁该负责”和“该管多久”。

管理属性	说明	我的实践建议
数据所有者	业务负责人，决定数据怎么用	必须落实到具体人名，不看岗位
数据管理人	IT或安全团队，管存储与权限	明确责任边界，避免扯皮
生命周期阶段	生成、存储、使用、归档、销毁	不同阶段，分类标签可能变化
存储位置	本地、云上、第三方	位置不同，脱敏策略不同

你想想看，如果数据都归档三年了，还按“绝密”管着，消耗的资源是巨大的。根据生命周期调整等级，才是聪明的做法。

分类方法实践：怎么组合才不“打架”

有了维度，下一步就是方法。我见过最蠢的做法，就是只按单一维度分类。比如“只按敏感度”，结果两份同级别的数据，一份需要高合规审计，一份完全不需要，政策没法执行。

我个人习惯用“两阶段法”：

1. 粗分类：先按业务域和数据所有者，打上初步的业务标签。
2. 精分级：再由数据治理委员会，基于安全维度复查一遍，确定最终密级。

这样可以避免盲目提级或降级。举个例子，人事部门说“员工住址要标绝密”，安全团队一看，实际合规要求只是“内部敏感”就够了。两方碰撞一下，结果更合理。

常见“坑”与避坑

干这行久了，有些错真的看太多。我挑几个最坑的说。

• 分类维度太多：我曾经遇到一个客户，搞了二十多个维度，结果每个人都不知道自己的数据该归哪类。后来被我砍到四个，反而好用了。维度不在多，在精。
• 完全依赖自动工具：一些AI工具会通过关键词和元数据分析，帮你打标签。但它是盲人摸象。比如“风险报告”，工具可能标成“风险管控”，实际上那是“员工绩效评分信息”。你必须要有人审核。
• 忽略“数据派生”：原始数据分类是A，经过加工后派生出了新数据，可能变成B。比如“用户姓名”是内部敏感，但“匿名化的用户ID”可能只是公开级别。这种变化，很多人忘了跟踪。

知识体系框架图

下面这张SVG图，总结了数据分类的核心维度与方法逻辑。你可以对照着看，自己在实际项目里到底覆盖了哪些环节。

这张图里，你可以看到三个维度最终都汇聚到具体实践。没有哪个维度是独立的。两阶段法、矩阵、派生跟踪，就是我在多个项目里验证过最实用的落地方式。

说到底，分类维度与方法不是什么高深的理论。它就是一次“数据摸底”的执行手册。选对维度，用对方法，后面分级才能站得住脚。