数据分级原则与方法：敏感度评估归纳总结
数据分级这事儿，我在不少项目里都踩过坑。说白了，就是给数据贴个标签——哪些是“命根子”，哪些是“公开信息”，必须分清楚。分不好，密钥配得再强也没用，因为你压根不知道该保护什么。
我记得刚带团队那会儿，大家一股脑把所有数据都打上“机密”标签。结果呢？密钥管理成了噩梦，日常查询卡得要死。后来我才明白：分级不是为了划分等级高低，而是为了匹配差异化的保护成本。
2.1 敏感度评估的三大维度
评估数据敏感度，我习惯从下面三个角度去切。你想想看，任何一条数据都能在这三个维度上找到坐标。
| 维度 | 说明 | 典型例子 |
|---|---|---|
| 保密性 | 数据泄露后会造成多大损失 | 用户密码、信用卡号、商业机密 |
| 完整性 | 数据被篡改后影响多严重 | 交易流水、审计日志、合约条款 |
| 可用性 | 数据不可用时的业务损失 | 实时风控模型、支付系统索引 |
这三个维度不是孤立的。我在一次金融项目中遇到过，某条交易记录同时满足高保密（涉及大客户隐私）和高完整（直接决定结算金额）。那我们就得在分级表里给它一个更高的综合等级。
2.2 常见的分级模型
不同行业的分级模型五花八门，但核心骨架逃不出下面几种。我个人推崇四层模型——简单、好理解、落地不费劲。
- 公开 (Public)：谁都能看，无需保护。比如产品介绍、官网新闻。
- 内部 (Internal)：仅限公司内部使用，泄露影响有限。比如内部通讯录、项目周报。
- 敏感 (Sensitive)：泄露会造成中等损失，必须加密保护。比如员工薪资、客户联系方式。
- 极敏感 (Critical)：泄露或丢失会带来灾难，需要最强的密钥控制。比如用户支付密码、核心算法源码。
我的习惯：实际落表时，我会给每个等级绑定一个数字权重（1~4），后续的密钥策略（加密算法强度、密钥轮换周期、访问控制粒度）直接按权重来选。这样不会出现“明文存敏感数据”这种低级错误。
2.3 分级流程：从定性到定量
光有模型不够，得有一套可执行的流程。我曾经在某个电商公司帮他们梳理过，流程大致分六步：
- 资产盘点：列出所有数据资产（库表、文件、消息等）。别忘了日志和备份——很多人在这里栽跟头。
- 初始评估：业务方给每个资产打上初步敏感度标签。
- 安全复核：安全团队从合规、对抗风险角度调整。嗯，这里经常会出现分歧。
- 影响量化：用表格里的三维度打分，算出综合分数。
- 等级映射：分数落到四层模型上，形成最终分级。
- 持续复审：数据使用场景变了，等级也要跟着变。我见过一个项目因为没做复审，把已经公开的API文档当极敏感数据保护，白白浪费资源。
下面这张图是我在这个章节里最想让你记住的东西——整个分级的核心逻辑。
2.4 实操：给一张表分级
纸上谈兵没意思，来点实在的。假设我们要对电商系统的用户订单表做分级，我通常会这么干：
场景：用户订单表，包含字段 user_id、real_name、phone、address、product_id、price、payment_card_last4。
评估：
- real_name + phone + address → 高保密（PII，泄露就违规）→ 保密性得分 4
- price + payment_card_last4 → 中等保密（风险可控）→ 保密性得分 3
- product_id → 公开 → 保密性得分 1
最终综合得分按最高字段取：4 → 极敏感 (Critical)。
那你问，为什么不取平均？因为木桶效应——一个字段漏了就全完了。我的经验是，取最大值更安全，成本也可控。
2.5 避坑指南
这些年见过不少翻车案例，挑三个最常见的说说：
- 分级脱离业务场景：同一个字段，在测试环境是内部级，在生产环境就是敏感级。我曾经吃过亏——测试环境的用户表没加密，测试数据被误导入生产，差点出问题。
- 只分级不复审：数据是活的，业务会变。比如一款产品从内测转公开发布，它的描述信息就从内部级变成公开级。不做复审，策略就会僵化。
- 混淆分级与分类：分级是“保护强度”，分类是“业务用途”。我见过团队把“客户数据”和“订单数据”分成两个类别，然后每个类别都打上同样的S级别，结果密钥策略没差异，等于没分。
警告：千万别让业务方单独定级。安全团队必须参与复核，否则会出现“我把公司代码仓库设成公开级”这种荒唐事。我亲眼见过某公司员工为了方便，给内部源代码仓库设了“公开”权限，还好审计及时发现。
2.6 分级与密钥策略的映射关系
有了等级，下一步就要选密钥策略。我习惯用下面这个映射表：
| 数据等级 | 推荐加密算法 | 密钥轮换周期 | 访问控制粒度 |
|---|---|---|---|
| 公开 | 不加密或 AES-128 | 不需要 | 全员可读 |
| 内部 | AES-256 | 1年 | 部门级 |
| 敏感 | AES-256-GCM | 6个月 | 角色级 + 审计 |
| 极敏感 | SM4 / AES-256-GCM + HSM | 3个月 | 用户级 + 细粒度 + 双人审批 |
嗯，这里有个小技巧：轮换周期不是越短越好。我见过有人设置每天轮换，结果密钥管理压力爆炸，系统还频繁出错。合理做法是：根据敏感度确定轮换频率，同时配合密钥生命周期自动化工具来执行。
总而言之，数据分级不是贴标签就完事——它是密钥控制的起点。你分得越清楚，后面的密钥策略就越精准，保护效果也就越好。下一段我们来聊聊具体怎么把分级结果落地到密钥管理系统中。不过那都是后话了，先把今天的分级原则吃透再说。