数据分级标准与方法
数据分级这事儿，说白了就是给数据“定个级别”，好决定谁能碰、怎么碰。我早期做安全合规的时候，发现很多团队要么不分级直接一把锁，要么分得特别细最后没人执行。今天咱们把标准、维度、流程串起来聊一聊。
2.1 国内外常用分级标准
国内最常参考的是 GB/T 35273《个人信息安全规范》，主要针对个人信息。它把个人信息分成个人敏感信息和个人一般信息，敏感信息又按影响范围细分成几个等级。国外呢，ISO 27001 更偏向“基于风险评估”的通用框架，不强制你分几级，而是让你自己根据业务场景定。
我记得有个项目，客户既要过等保又要做ISO 27001认证，两边标准都得对上。当时我拉了个对比表，发现 GB/T 35273 的等级定义偏具体，ISO 27001 则更灵活。后来我们做了个映射，两边都认。
| 维度 | GB/T 35273 | ISO 27001 |
|---|---|---|
| 适用范围 | 个人信息（具体到字段） | 所有信息资产（通用） |
| 分等级数 | 4级（S1~S4，敏感度递增） | 建议3~5级，企业自定 |
| 核心依据 | 对主体权益的影响 | 机密性、完整性、可用性损失程度 |
| 示例 | 身份证号 → S4（极高敏感） | 核心数据库 → 机密性等级高 |
2.2 分级维度：CIA三元组
为什么分级要盯着机密性、完整性、可用性？你想想看，一个数据就算再机密，如果丢了也能重建（比如日志），那它的可用性需求可能比机密性更高。反过来，像用户密码这种，机密性一丢基本就完了。
我个人习惯用下面这个矩阵来评估每个数据的三个维度，然后综合定级：
| CIA维度 | 定义 | 分级影响 | 真实场景 |
|---|---|---|---|
| 机密性 (Confidentiality) | 数据只被授权的人访问 | 泄露级别决定等级上限 | 客户身份信息、密钥材料 |
| 完整性 (Integrity) | 数据不被篡改或破坏 | 篡改后果决定等级 | 交易记录、合同文件 |
| 可用性 (Availability) | 数据在需要时能拿到 | 业务中断时长定级 | 支付系统、实时监控数据 |
具体评估时，我会给每个维度打1~5分，然后取最高分或加权平均（看你业务偏好）。比如一个客户的身份证号，机密性5分，完整性3分（改不了ID，但关联数据可能被改），可用性2分（丢了能走线下补录）→整体等级可以定4级。
2.3 分级流程与评估方法
流程这块，很多文档写得很复杂，但核心就四步：识别 → 分类 → 打标 → 审批调整。我习惯再加一个“持续监控”，因为数据会变。
- 识别数据资产：先把所有数据源盘点一遍。注意，不是只查数据库，还有配置文件、日志、备份、API返回。我曾经漏了某个中间件日志，里面夹着用户的敏感ID，后来被审计揪出来才补上。
- 分类定级：根据CIA维度打分，参考标准里的等级定义。这里可以用定性法或定量法。定性法：专家开会拍脑袋（快但有偏见）；定量法：用风险矩阵算期望损失（准但耗时）。我建议第一阶段用定性法快速跑通，再逐步迭代定量模型。
- 打标标识：在元数据里加分级标签。比如数据库字段加
classification: "L4"，或在文件名的后缀加_topsecret。注意，打标本身也要安全，别让标签泄漏。 - 审批与调整：定级结果要给数据Owner和安全管理组审批。遇到业务变化（比如新法规出台）要重新走一遍评估。
// 一个简单的分级规则示例（伪JSON）
{
"dataId": "user-phone",
"CIA": { "confidentiality": 5, "integrity": 2, "availability": 3 },
"finalLevel": "L4",
"standardMapping": {
"GBT35273": "S4",
"ISO27001": "high"
},
"owner": "infosec-team"
}
评估方法我推荐“风险矩阵+专家校准”。先用矩阵把CIA损失程度和发生概率交叉，得到一个初步等级；再请业务方和安全专家调参。这样做出来的分级，既不会过高让业务抱怨，也不会过低让安全漏风。
最后补充一点：分级不是一次性的。我手头有个持续运营的项目，每季度都会跑一遍“分级健康度巡检”，用自动化工具扫描新数据、新字段，触发重新评估。这样才不会出现“去年分完了，今年数据翻了一倍却没更新”的尴尬。