数据分级标准体系设计
这章是项目里最容易出幺蛾子的地方，也是后面所有规则的基座。标准没定好，后面所有分级分类都是瞎胡闹。我来掰扯一下我当时踩的坑和攒下的套路。
1. 分级体系的核心要素
说白了，分级就是回答“这个数据出事了影响有多大”。我个人习惯把影响拆成两个维度：影响对象和影响程度。对象可能是国家、企业、个人、业务等；程度就是严重、中等、轻微。
关键点：千万不要只用一个字段定级。很多团队直接写“敏感”“机密”，结果两个部门对同一个词的理解差十万八千里。
我在做某政务项目时就吃过这个亏。客户说“内部数据”，财务的“内部”指财务报表，研发的“内部”指源代码。后来统一按对象+程度拆解，才把标准对齐。
常用的分级模型长这样：
| 级别名称 | 影响对象 | 影响程度 | 典型示例 |
|---|---|---|---|
| 公开 | 无特定对象 | 无 | 官网新闻 |
| 内部 | 企业 | 轻微 | 内部通讯录 |
| 敏感 | 企业/个人 | 中等 | 员工薪资区间 |
| 机密 | 国家/企业 | 严重 | 核心算法、客户身份证 |
小提示：我一般建议先定4-5级，别搞太多。级别多了业务方记不住，落地全是错。
2. 分类标准与方法
分类是管它是什么数据，分级是管它多重要。两者结合才能形成完整的数据分级分类矩阵。
分类维度常见几种：
- 按业务域：财务、人力、研发、营销等
- 按数据主题：客户主数据、交易数据、日志数据等
- 按数据形式：结构化、半结构化、非结构化
- 按来源：内部生成、外部采集、第三方合作
实际上，大部分项目选业务域+数据主题就够了。你想想看，财务部门的报销单和研发部门的源代码，放在一起分类根本没法管。
注意：我曾经见过一个团队把“分类”和“标签”混淆。分类是树形结构，每个数据只能属于一个叶子节点；标签可以多个。设计分类时一定要保证互斥和完全覆盖。
3. 标准设计的实战经验
踩过的坑不少，挑几个典型的说说。
- 坑一：只定级别，不定规则。只写“机密数据包括核心资产”，但核心资产是什么没人说清楚。建议每个级别配上
判定条件表。 - 坑二：忽略合并影响。单个字段可能只是内部，但组合后能推导出机密。比如“工资基数”+“绩效比例”=“个人年薪”。标准里要加
字段组合敏感度。 - 坑三：脱离技术实现。定出的级别在数据库里没法自动化打标。标准里应该有
匹配规则示例，比如“字段名包含id_card且长度=18 → 敏感”。
避坑指南：我曾经因为标准里没写组合规则，导致某项目的开发私自把“姓名+身份证”混在一起存，上线第一天就被审计投诉。后来补了组合敏感度矩阵。
4. 一个完整的示例
下面是一个实际项目里用过的分级分类矩阵片段，你直接参考结构就行。
| 业务域 | 数据主题 | 公开 | 内部 | 敏感 | 机密 |
|---|---|---|---|---|---|
| 人力资源 | 员工基本信息 | ● | |||
| 薪酬数据 | ● | ||||
| 研发 | 需求文档 | ● | |||
| 核心算法源码 | ● |
小提示：空单元格意味着该组合不存在或者不需要定级，不要硬填。保证矩阵尽可能稀疏，只标真正有意义的组合。
5. 体系设计全景图
下面这张图把整个分级分类体系设计的关键要素画在一起。你把它打印出来贴在工位上，设计的时候对着看，不容易漏。
你仔细看这张图：左边是分级维度（影响对象+影响程度+级别映射+组合规则），中间是分类维度（业务域、数据主题、形式、来源），右边是输出产物（矩阵、条件表、脚本、流程）。设计的时候两手抓，同时考虑，才不会漏掉组合敏感度这种坑。
还是那句话：标准体系设计是后面所有自动化打标和审计的前提。别图快，多拉业务方、安全方、开发方一起过一遍。我曾经因为没拉开发评审，定出来的字段匹配规则复杂到SQL跑不动，最后全线重来。血的教训。
嗯，这一章到此为止。该画的图画了，该写的表写了，实战坑也交代了。剩下的就是动手把你们自己的业务域往里套。