📚 课程目录第4章数据分级方法

数据分级方法：从公开到绝密，级别的定义与标识

聊到数据分级，我问过不少团队一个问题：「你们分了几级？」答案常常是「五级」或者「四级」。但再问一句「哪五级」？就有人开始含糊了，分法五花八门。

我自己的项目经验告诉我：分级不是拍脑门定的。

这一章我们就把面向API设计场景的数据分级方法掰开揉碎。我会从「公开」一路聊到「绝密」，把每个级别的定义、标识、使用场景讲清楚。

为什么至少要分四级？

很多安全规范把数据分成三到五级。我个人习惯至少分四级，原因很简单：三级太少，边界模糊；五级对大多数API团队又过于臃肿。

你看啊——

公开：谁都能看，不需要任何保护。
内部：公司内部可用，但对合作伙伴或外部不能暴露。
敏感：泄露后会带来合规风险或业务损失。
绝密：泄露就是重大安全事故，比如密钥、核心算法。

四级够用，而且每个级别之间的「防控力度」能拉开明显差距。我曾经见过只分三级的团队，结果把「内部」和「敏感」揉到一起，结果审计时被查了个底朝天。

级别定义：从公开到绝密

我们来一个一个过。每个级别我都会贴一个实际项目中用过的标识方式。

L0 – 公开（Public）

定义：完全公开，无保密要求。谁都可以访问，不需要认证，不需要授权，也不需要加密。
典型场景：官网宣传文案、产品白皮书、Demo API的返回示例。
标识方式：在响应Header加X-Data-Level: public，或字段名加前缀pub_。

小技巧： 如果你做的是开放平台，公开数据也建议加个只读标志，防止被误改成敏感字段。

L1 – 内部（Internal）

定义：仅限公司内部员工使用。不能对合作伙伴、客户、公众暴露。但内部员工之间不需要额外审批就可以访问。
典型场景：内部监控大盘、测试环境数据、运维工单信息。
标识方式：字段名加int_，并在API定义文档中用@internal注解标记。响应Header加X-Data-Level: internal。

L2 – 敏感（Sensitive）

定义：泄露后会对用户隐私、公司业务、合规产生实质影响。访问需要审批、加密、审计。
典型场景：用户手机号、家庭住址、企业内部财务报表。
标识方式：字段名加sen_，API网关强制加入权限校验，数据库落地必须加密。
注意：敏感级别不建议走默认缓存。我曾经在Redis里误缓存了用户手机号，差点被合规约谈。

L3 – 绝密（Top Secret）

定义：最高保密级别。泄露会造成重大安全事故、法律诉讼甚至公司倒闭。访问必须双人审批，传输和存储都使用独立加密方案。
典型场景：私钥、支付证书、核心算法模型权重。
标识方式：字段名加top_，响应Header加X-Data-Level: top-secret，且绝密数据不能出现在日志、监控、跟踪系统中。我建议在API网关层直接拦截，不让绝密字段进入业务日志。

  核心原则： 每个级别的访问管控强度必须与风险等级正相关。公开级别允许任何人调用；绝密级别连运维后台查看都需要申请临时权限。

级别的标识方法

定义好级别后，怎么让代码、文档、网关都认得出？

我归纳为三种主流方式：

代码级标识：在DTO、POJO或API定义中用注解/属性标记。例如Java的@DataLevel("sensitive")，或Proto文件的option (data_level) = "internal";。
接口级标识：在OpenAPI (Swagger) 扩展字段里声明。比如：
```
paths:
  /user/profile:
    get:
      x-data-level: sensitive
```
这样API文档和代码生成工具都能读取。
运行时标识：在响应Header或请求参数中携带。我建议接口返回时直接带X-Data-Level，方便下游消费端做校验。

你可能会问：「三种全都要吗？」不一定。我自己喜欢接口级 + 运行时组合。文档里写清楚字段级别，运行时网关根据Header自动拦截，双保险。

⚠️ 避坑提醒： 我曾经遇到一个项目，用代码里注解标识级别，但网关完全不读注解，结果敏感数据直接暴露到公网。记住：运行时拦截必须与代码定义保持一致，不要各搞一套。

级别对比一览

下面这张表方便你快速对照：

级别	名称	访问控制	传输加密	存储加密	日志脱敏
L0	公开	不限制	不要求	不要求	不要求
L1	内部	员工身份	推荐	不要求	不要求
L2	敏感	审批+角色	强制	强制	部分
L3	绝密	双人审批	独立加密	独立加密	完全脱敏

从表里能看出来：每上升一级，安全措施就加码一层。绝密级别的日志甚至不能出现任何信息，连字段名都要替换成***。

实操：怎么快速给现有API分级

摆在你面前的可能是几百个API接口，全用手工梳理？太慢了。我分享一个我在项目里用过的方法：

先扫出所有返回用户隐私字段的接口——这些大概率是敏感或以上。
再筛出只返回公司内部信息的接口——这些定内部。
剩下的公开接口直接标公开。
对确定不了的，和法务/合规过一遍。

你想想看，大部分漏分级的问题出在「我以为这只是普通数据」上。比如一个员工ID，内部看是L1，但如果加上部门和职级，组合起来就可能变成敏感数据。

一个实用建议： 用自动化工具扫描接口文档，自动比对返回字段与敏感词库（手机号、身份证、银行卡等），可以省掉80%的人工精力。

数据分级核心逻辑图

下面这张SVG图汇总了从公开到绝密的定义、标识和管控维度。你可以把它贴在团队Wiki首页当参考。

从图上你能看到：越往右，安全管控越重。别想着L2的数据套L0的加密策略。我见过有人把用户家庭地址当「内部」处理，结果一被爬虫爬走，几百万条数据直接挂外网——这种事一次就够了，千万不要尝试。

常见分级误区

把绝密当成敏感对待：比如私钥和密码只做了一重加密，没做独立密钥管理。出了事很可能连追溯都做不到。
把公开数据标成内部：这会导致内部API网关莫名其妙拒绝第三方合法请求，反而影响业务。
分级只定不维护：我见过一个团队，两年前定了级别，后来服务重构了，新加的字段全没标记。结果审计时发现一堆敏感字段用了内部级别。

建议每半年做一次分级审计，配合API文档自动化扫描，保持级别和实际数据对齐。