数据安全治理实战指南：分类分级规范怎么定、怎么落、怎么持续运营

安全事件往往从"不知道自己有什么数据"开始

每次数据泄露事后复盘，几乎都会发现同一个问题：出事的系统，从一开始就没搞清楚里面存了什么。一份包含用户身份证号的 CSV 被同步到了测试环境，没人知道；一个 S3 bucket 里存着未脱敏的交易流水，权限却是 public-read；某个内部 API 返回了完整的手机号和地址，调用方只是一个运营后台的导出功能。

这些问题的根因不是技术能力不足，而是缺乏一套可执行的数据分类分级体系。你连数据是什么级别都不知道，怎么定访问策略？怎么配加密规则？怎么做审计？

这篇文章把分类分级这件事从头到尾走一遍：标准怎么定、技术上怎么落地、日常怎么运营。

什么是数据分类分级：四级模型

分类（Classification）回答"这是什么类型的数据"——个人信息、财务数据、业务指标、技术文档。分级（Level）回答"这数据有多敏感"——泄露后影响有多大。

实践中最常用的四级模型：

级别	定义	典型数据示例
公开（L1）	可对外公开，无保密要求	产品介绍、公开 API 文档、官网内容
内部（L2）	仅限公司内部使用，不可外传	内部 Wiki、组织架构图、内部工具源码
敏感（L3）	泄露会造成业务损失或合规风险	用户手机号、订单明细、合同条款、薪资数据
机密（L4）	泄露会造成重大损失，需最高级别保护	核心算法、用户身份证号、加密密钥、未公开财务数据

注意：分级不是越多越好。四级已经足够覆盖大多数场景，超过四级会导致一线员工分不清、懒得标，反而形同虚设。

怎么定你自己的分类分级标准

不要从零发明。先看三个东西：

行业参考标准：

金融行业看 JR/T 0197《金融数据安全数据安全分级指南》
政务领域看 GB/T 37988《数据安全能力成熟度模型》
通用企业参考 GB/T 35273《个人信息安全规范》里的个人信息分类

监管要求：

《数据安全法》第二十一条明确要求"建立数据分类分级保护制度"
《个人信息保护法》对敏感个人信息有单独的认定标准
行业监管机构（银保监、证监、卫健委等）通常有细化要求

企业自身业务：

和业务方一起梳理核心数据资产清单
按数据泄露后的影响面定级：影响用户？影响营收？影响合规？影响国家安全？
同一类型数据在不同上下文中级别可能不同：汇总后的销售报表是 L2，逐条的交易记录是 L3

最终输出一份《数据分类分级规范》文档，包含：分类维度表、分级定义、判定规则、争议仲裁流程。这份文档需要法务、安全、业务三方会签。

技术落地：自动打标、元数据驱动、DLP 联动

标准写得再好，如果全靠人工标注，三个月后就废了。技术落地的核心是让分类分级信息跟着数据走。

自动打标（Auto-Tagging）：

在数据写入时就完成分级标注。常见做法：

数据库层面：在 schema 元数据里加 data_classification 字段，建表时必填
数据湖层面：Hive Metastore / Glue Catalog 的 table properties 里标记级别
文件存储层面：对象存储的 object tagging 或目录命名规范（如 /data/sensitive/、/data/public/）

元数据驱动（Metadata-Driven）：

建一个中心化的数据目录（Data Catalog），把所有数据资产的分类分级信息汇总。工具选型：

开源：Apache Atlas、DataHub、OpenMetadata
商业：Collibra、Alation、阿里云数据地图

核心能力：自动发现新数据源、基于规则或 NLP 识别敏感字段、提供血缘追踪。

DLP 联动：

分类分级信息输出给 DLP（数据防泄漏）系统，实现策略联动：

L3 以上数据禁止通过邮件外发
L4 数据禁止导出到个人设备
跨环境同步时自动触发脱敏

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 示例：基于分级的 DLP 策略配置
dlp_policies:
  - name: block-l4-email
    condition: "data_level == 'L4'"
    action: block
    channels: [email, im]
  - name: mask-l3-export
    condition: "data_level == 'L3'"
    action: mask
    channels: [database_export, api_response]

按分级定访问控制策略

分类分级的最终目的是让不同级别的数据有不同的保护强度。以下是典型的访问控制矩阵：

控制维度	L1 公开	L2 内部	L3 敏感	L4 机密
访问审批	无需审批	部门主管审批	数据 Owner + 安全审批	VP 级 + 安全委员会审批
认证要求	基础认证	MFA	MFA + 设备信任	MFA + 硬件密钥
加密	可选	传输加密	传输 + 存储加密	字段级加密 + 密钥隔离
审计日志	异常告警	全量记录	全量记录 + 每日审计	实时审计 + 异常熔断
数据导出	允许	审批后允许	脱敏后允许	原则上禁止
第三方共享	允许	签署 NDA	NDA + 数据处理协议	原则上禁止

这张表不是模板，你需要根据自己的业务场景调整。关键是：每一级都比上一级多一层控制，而且每层控制都有明确的技术实现手段，不是"加强管理"这种空话。

持续运营：定期复核、新数据接入、事件响应

分类分级不是一次性项目，是持续运营。三个核心流程：

定期复核（Periodic Review）：

每季度由数据 Owner 确认其负责数据的分级是否仍然准确
业务变化可能导致级别变化：内部孵化项目上线后变成核心产品，数据从 L2 升到 L3
法规变化也要触发复核：某类数据被新法规定义为敏感个人信息，需要批量调整

新数据接入（Onboarding）：

新系统上线前，必须完成数据资产登记和分级标注，作为上线 checklist 的硬卡点
新接入的第三方数据源，在接入评审时就要确定分级
CI/CD 流水线里加入 schema 变更检查：新增字段如果没有 classification 标记，阻断发布

事件响应（Incident Response）：

安全事件发生时，第一时间通过数据目录确认涉及数据的级别
L3 以上数据泄露触发合规上报流程（72 小时内通知监管机构）
事件复盘时检查：分级是否准确？控制措施是否到位？是否需要调整标准？

常见反模式与修正

反模式	问题	修正方案
全部标为"敏感"	分级失去意义，安全措施无法差异化	强制分布：L3+L4 占比不超过 30%，倒逼精确判定
只靠人工标注	覆盖率低，三个月后退化	自动化打标为主，人工复核为辅
标准只存在于文档	一线员工不知道、不执行	集成到开发工具链：建表时必填、PR review 检查项
分级和控制脱节	标了 L4 但访问策略和 L2 一样	分级结果必须联动 IAM/DLP/加密策略
没有数据 Owner	出了问题没人负责，复核没人做	每个数据集指定 Owner，写入数据目录，纳入绩效
一次性项目思维	做完验收就没人管了	建立运营指标：覆盖率、准确率、复核完成率，纳入安全度量

分类分级是所有数据安全控制的基石

回头看你做过的安全控制——加密、脱敏、访问控制、审计、DLP——哪一个不需要先知道数据的敏感程度？没有分类分级，这些控制要么一刀切（成本高、体验差），要么凭感觉配（漏了就是事故）。

分类分级不是一个安全团队的内部项目，它是一个组织级的数据治理能力。需要业务参与定标准，需要工程团队做技术落地，需要管理层给资源和授权。做对了，后续所有的安全控制都有了依据；做不好，后面的一切都是在沙子上建楼。

先把家底摸清楚，再谈保护。