3. 数据分类与分级：敏感性分级与分类标签设计

数据分类分级，说白了就是给数据贴标签、定身价。我见过太多团队一上来就搞「全量加密」，结果成本爆炸，业务方天天骂娘。其实你想想看，不是所有数据都值得用最高规格保护的。

这一章，咱们就聊聊怎么把数据分成公开、内部、机密、绝密四个等级，以及怎么设计一套好用的分类标签体系。

3.1 数据敏感性四级模型

我个人习惯把数据敏感性分成四个层级。这个模型在大部分企业里都够用，太细了管不过来，太粗了又容易漏。

等级	定义	典型示例	保护要求
公开	可对外发布，无保密需求	官网新闻、产品白皮书、公开API文档	无特殊保护，但需防篡改
内部	仅限公司内部使用，泄露有轻微影响	内部通讯录、项目排期表、非敏感运维日志	访问控制 + 传输加密
机密	泄露会造成较大商业或法律风险	用户个人信息、核心业务报表、未公开产品设计	强访问控制 + 存储加密 + 审计
绝密	泄露会导致致命损失或违法	支付密钥、用户密码明文、核心算法源码	物理隔离 + 全链路加密 + 专人审批

3.2 分类标签设计方法

光有分级还不够，你得给数据打上可被系统识别的标签。标签设计得好，后续的保留策略、访问控制、审计追溯才能自动化。

3.2.1 标签结构

我建议采用三段式标签结构：[数据域].[敏感等级].[保留类别]。举个例子：

# 用户个人信息标签
user_profile.confidential.retain_3y

# 系统运维日志标签
ops_log.internal.retain_90d

# 财务审计记录标签
finance.top_secret.retain_7y

这种结构的好处是——你可以在数据湖或对象存储的元数据里直接挂标签，然后通过策略引擎自动匹配保留规则。

3.2.2 标签设计原则

• 可枚举：标签值必须是预定义的，不能自由填写。自由填写的标签最后一定变成垃圾数据。
• 可继承：表级标签可以下推到列级。比如整张表是「机密」，但其中「用户ID」列可以继承为「绝密」。
• 可组合：一个数据对象可以挂多个标签。比如一份数据既是「机密」又是「合规审计」。

3.3 分级与标签的落地流程

光有理论不行，得能落地。我一般建议分三步走：

1. 数据资产盘点：先搞清楚你有哪些数据，存在哪里，谁在用。没有这一步，分级就是空中楼阁。
2. 分级评审：由数据Owner、安全团队、业务方一起开会，逐表确认敏感等级。别指望自动化工具能一步到位——工具只能辅助，决策还得靠人。
3. 标签打标：通过ETL脚本或数据治理平台，把标签写入元数据系统。我习惯在数据入库时就打标，而不是事后补标。

3.4 分级与保留策略的映射关系

分级不是终点，它是为保留策略服务的。下面这张表展示了常见的映射关系：

敏感等级	建议保留期限	销毁方式	备份频率
公开	永久保留或按业务需要	无特殊要求	按需备份
内部	1-3年	普通删除	每日增量 + 每周全量
机密	3-7年（按法规要求）	安全擦除（覆写3次）	每日全量 + 异地备份
绝密	按法规上限，到期立即销毁	物理销毁或加密擦除	每日全量 + 异地 + 离线备份

嗯，这里要注意：保留期限不是越长越好。绝密数据留太久，反而增加泄露风险。我见过一个案例，某公司把5年前的支付日志还留着，结果被拖库——那些数据早该销毁了。

3.5 数据分级与分类的核心逻辑图

下面这张图概括了从数据产生到标签落地的完整链路：

这张图我画得比较简洁，但核心链路很清楚：从盘点开始，到分级、设计标签、打标，最后映射到保留策略。每一步都依赖上一步的输出，跳步就会出问题。

3.6 常见问题与避坑

• 「所有数据都标机密」：这是最典型的懒人做法。结果就是真正需要保护的数据反而被淹没在大量低价值数据里。
• 「标签只打一次」：数据是会变的。比如一份内部文档后来被公开了，标签必须跟着更新。我建议每季度做一次标签审计。
• 「分级和标签脱节」：有些团队分级是一套系统，标签是另一套系统，最后对不上。一定要在元数据层面打通。