4. 数据分级方法：基于敏感度、影响程度的分级模型

聊到数据分级，很多人第一反应就是“把数据分成绝密、机密、秘密”。这个想法没错，但太粗糙了。

真正的分级，你得回答两个问题：这数据本身多敏感？以及它要是出事了，后果多严重？

前者是“敏感度”，后者是“影响程度”。这两个维度一交叉，分级模型就立起来了。我个人习惯用这个框架，因为它能从两个角度卡死风险，不容易漏掉“看起来不敏感但出事很要命”的数据。

4.1 敏感度与影响程度：两个核心维度

先拆开看这两个东西到底指什么。

4.1.1 敏感度（Sensitivity）

说白了，就是数据本身有多“金贵”。判断标准很直接：如果这数据被不该看到的人看到了，会出多大事？

4.1.2 影响程度（Impact）

这个维度看的是“数据出事之后，对业务、对用户、对公司的影响范围有多大”。

你想想看，有些数据本身不敏感（比如订单金额），但如果被篡改了，公司可能直接损失几百万。这就是影响程度高的典型场景。

4.2 分级矩阵：把两个维度织成一张网

单独看一个维度不够，得把它们组合成矩阵。我通常用 2x2 的矩阵做初步划分，复杂的场景会扩展到 4x4。

下面这张表是我最常用的 3x3 分级矩阵。你注意看，有些格子是黄色的，那是我自己标注的“重点关注区”。

你看，S1敏感度的数据，即使影响程度到了严重（I3），也只会升到2级。而S3敏感度的数据，哪怕影响只有轻微（I1），已经是3级。这个规则背后的逻辑是：敏感度决定了最低等级，影响程度决定了上调空间。

4.3 分级流程：从原始数据到分级结果

知道理论了，怎么落地？我一般走以下几步：

1. 数据打标：给每张表、每个字段打上敏感度标签 S1~S4。
2. 场景分析：分析数据在不同使用场景下的影响程度。比如“只读”和“可写”的影响完全不同。
3. 矩阵映射：根据上述矩阵，查出对应的最终分级。
4. 分级输出：输出一个包含分级、保护策略、负责人信息的清单。

嗯，这里要注意：同一个数据在不同场景下可能拿到不同分级。比如一个客户地址字段，在“客服查询”场景下影响是I2，但在“对外公开报表”场景下影响就是I3。这种情况，我建议取最高分级。

4.4 基于 C-I-A 三要素的分级扩展

除了敏感度和影响程度，很多成熟的企业会引入 C-I-A（保密性、完整性、可用性） 三要素来辅助定级。我的看法是：对于接口数据来说，这三个要素权重不一样。

• C（机密性）：权重最高。接口数据一旦泄露，影响范围往往不可控。我一般给它 50% 的权重。
• I（完整性）：权重中高。接口数据传递过程中，如果数据被篡改，后果可能非常严重。权重 30%。
• A（可用性）：权重相对低。接口挂了可以重试、降级，不一定会直接导致数据泄露。权重 20%。

你可能会问：为什么可用性权重这么低？因为分级模型主要关注的是“数据泄露和滥用”风险，而不是服务中断。可用性问题通常落在“业务连续性”范畴，由另外一套流程管。

4.5 分级结果输出格式

分级不是只分个等级就完了。你得输出一个可落地的东西。我一般会输出类似下面这个表格：

这个表格可以直接作为后续接口设计、加密策略、审计策略的输入。你拿到这个表，就知道哪些接口需要做 校验，哪些要签摘要，哪些要全链路加密。

4.6 分级模型的迭代与维护

最后说一句：分级模型不是一次性的。

我见过的失败案例，都是某个项目经理拉了一堆人开两天会，分完了就结束了。半年后业务变了，数据形态变了，分级模型根本对不上。结果安全部门拿着过时的分级去做接口保护，漏洞百出。

所以我建议，每个季度至少做一次分级核查。核查重点包括：

• 新增接口是否有落入分级盲区？
• 已有接口的数据内容是否有变化？比如原来只存 user_id，现在存了身份证。
• 外部合规要求是否有更新？比如 GDPR 新增了对生物特征数据的保护要求。

说白了，分级模型是一个活的框架。你不动它，它就会慢慢失效。我习惯把这套核查流程做成自动化脚本，每季度定时跑一次，输出差异报告，然后人工确认。这样一来，分级就不会变成“僵尸文档”。