第2章 数据分级标准体系：国内外分级标准对比与理解
做数据分级接口开发，第一关就是搞懂标准体系。说实话，我刚入行时觉得这玩意就是文档里写写，实际开发按自己感觉分就完了。直到有一次——嗯，我负责对接一个跨境数据交换项目，国内合规审了半天说“分级不匹配”，海外客户又拿GDPR来质疑……两边都不认账。那次之后我才认认真真把标准撸了一遍。
一句话总结：数据分级不是拍脑袋定的，需要同时对齐法律、行业和业务层。偷懒跳过这一步，后面接口排查会让你哭。
2.1 国内标准：等级保护（等保）
等保是国内最硬的分级框架，全称《信息安全等级保护管理办法》。它把数据从1级到5级定级，主要依据“一旦出事后对社会、国家的影响”。
| 等级 | 定级条件（简要） | 典型场景 |
|---|---|---|
| 1级 | 损害公民、法人权益 | 普通业务日志、公开信息 |
| 2级 | 损害社会秩序、公共利益 | 企业内部员工个人信息 |
| 3级 | 严重损害公共利益，或损害国家安全 | 政务服务平台核心数据 |
| 4级 | 特别严重损害国家安全 | 关键信息基础设施数据 |
| 5级 | 极端严重损害国家安全 | 绝密级国防/外交数据 |
我习惯把等保理解成“红线思维”——你接口如果处理的是3级及以上数据，传输加密、日志审计、访问控制都是硬性要求，少一个都过不了等保测评。记得有个做政务系统的项目，我们刚开始只用了基本HTTPS，评审时直接被批“不符合3级接口防护要求”，后来补了双向证书和国密算法才算过关。
避坑指南：别把等保等级等同于“敏感程度”。等保更关心的是“损害后果”，而不是“数据本身多值钱”。比如一份公开的政策文件，在特定时间点可能被定到2级甚至3级，别按常识猜，去看定级备案表。
2.2 国际标准：GDPR
如果你跟海外公司对接接口，GDPR是绕不开的。GDPR没有像等保那样分1～5级，而是用了另一种逻辑——数据分类+处理风险。
- 一般个人数据：姓名、电话、地址……这些基本个人信息，可以依法处理但需要合法依据。
- 敏感数据（特殊类别）：种族、政治观点、宗教信仰、基因数据、健康数据、性生活或性取向。这类数据原则上禁止处理，除非有特定豁免。
- 刑事定罪相关数据：单独列为一类，管控更苛刻。
实际接口设计时，GDPR关注的不只是数据流，还有“目的限制”和“数据最小化”。我参与过一个欧洲电商项目，对方审计直接要求我们解释“每个接口字段为什么必须要传”，答不上来的字段直接砍掉。说白了，GDPR逼你重新审视接口设计——能少传就少传。
重要提醒：GDPR没有明说“3级数据要加密传输”，但DPIA（数据保护影响评估）中会要求根据数据类型给出加密强度。我见过一个团队照搬等保的加密方案，结果被DPA质疑“为什么用国密而不说明等效性”——跨境项目尤其要注意标准互认。
2.3 行业规范
不同行业的细化标准往往比通用标准更“接地气”。我做过的两个典型行业：
- 金融行业：《个人金融信息保护规范》（JR/T 0171）把个人信息分成C3、C2、C1三档，C3最敏感（如支付密码、银行卡磁道数据），接口必须走硬件加密机。我之前对接第三方支付时，C3数据连日志里都不能出现明文。
- 医疗行业：《健康医疗大数据安全标准》把健康医疗数据分为五级，从“完全公开”到“涉及国家安全”，其中病历、基因组数据一般归到4级以上，接口需要支持分段加密和访问令牌时效限制。
还有一个容易忽略的——企业内部的业务分级。很多公司会自己搞一套“密级”：公开、内部、敏感、绝密。这跟外部标准可能有冲突。我建议接口设计时至少保留一个标准映射层，比如把内部“敏感”映射到等保3级或GDPR敏感数据，这样不管对接哪个审计都能快速对齐。
2.4 核心对比
为了让你一眼看明白，我画了一张对比框架。别看它简单，实际项目里我拿它给新同事讲了三分钟就理解了。
2.5 如何选择适用的标准？
这个问题我太有教训了。早些年在做一个B2B平台，数据只在境内流转，我就只按等保做了分级，接口也都按3级防护上。结果美国合作伙伴要求签Data Processing Agreement，说必须满足GDPR条款，我们连夜拉了一张映射表，发现敏感字段定义根本对不上——比如GDPR把“设备指纹”明确列为个人数据，但等保2级以下根本没提。
我的建议分三步：
- 先定管辖域：数据处理涉及哪些国家/地区？只要有欧盟数据主体，就必须考虑GDPR；涉及国内政务系统，等保不能少。
- 再定行业属性：金融、医疗等强监管行业，行业规范优先于通用标准。接口设计时要预留行业扩展字段和加密级别。
- 最后做标准映射：把不同标准里的“敏感度”统一映射到接口分级矩阵（L1~L5）。我习惯用一张枚举表，每个字段标注“等保级”、“GDPR分类”、“行业密级”，开发阶段直接按最高级别处理。
一个小技巧：如果你拿不准用哪个标准，就画一个上面SVG那样的“三列对比图”，让合规团队和开发团队一起过一遍，漏项就一目了然。反正我现在每个新接口启动前都这么干，再也没翻过车。
对了，还有一个容易踩的坑——标准的时效性。等保2.0在2019年才全面实施，GDPR的指南也年年更新。我建议你的接口配置里加一个“标准版本号”字段，万一审计问起来，直接说“此接口按GB/T 22239-2019 3级要求设计”，比含糊说“按等保”靠谱得多。
总结一句话：别把标准当教条，它本质是帮你定位“这个接口到底需要多安全”的参照系。看得懂标准，才能设计出过关的接口。