3. 数据资产梳理与分类分级
数据安全治理的第一步不是买设备、上加密，而是回答一个更基础的问题：我们到底有哪些数据、它们在哪里、谁在用、值多少钱、该按什么级别保护。如果连数据资产都说不清，后续的脱敏、加密、访问控制、审计都会变成"盲人摸象"。本节围绕数据资产梳理与分类分级这条主线，讲清数据发现、资产测绘、分类分级标准、标签体系以及落地工具选型五个环节如何衔接。
一、数据发现：先找到"看不见的数据"
数据发现（Data Discovery）的目标是识别组织内数据的分布与内容特征，尤其是那些未被登记、被复制、被遗忘的"影子数据"。常见发现手段有三类：
- 网络流量发现：通过镜像流量或代理，识别数据库协议（MySQL、Oracle、PostgreSQL、Redis 等）与 HTTP 接口中传输的敏感字段，适合发现"正在被访问"的数据。
- 扫描探测发现：对 IP 段、端口、数据库实例进行主动扫描，识别存活的数据源及其版本、库表结构，适合发现"存在但未被登记"的数据源。
- 内容识别发现：对文件系统、对象存储、数据库字段做抽样或全量扫描，用正则、字典、机器学习模型识别身份证号、手机号、银行卡号、地址等敏感内容。
以内容识别为例，一个可用的身份证号识别规则通常包含：18 位数字、末位可为 X、前 6 位为行政区划码、第 7–14 位为出生日期且合法。实际工程中会先用正则粗筛，再用校验位算法（ISO 7064:1983 MOD 11-2）做二次确认，把误报率压下来。示例规则如下：
# 身份证号识别（示例规则，非实测结果）
pattern: ^[1-9]\d{5}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$
校验: 前17位加权求和 mod 11，映射校验码表 [1,0,X,9,8,7,6,5,4,3,2]
命中示例: 11010119900307XXXX（示例，非真实数据）
发现阶段的关键输出不是"扫到了多少条"，而是数据源清单 + 敏感字段清单 + 数据量级 + 访问主体。没有这四类信息，后续测绘和分级就缺少输入。
二、资产测绘：把"点"连成"图"
数据发现给出的是零散的点，资产测绘（Data Asset Mapping）要把这些点组织成可管理的资产视图。测绘的核心是建立"数据源—库—表—字段—业务系统—责任人"的关联关系，并标注数据流向。一个实用的测绘模型通常包含四层：
- 物理层：IP、端口、实例名、存储引擎、部署位置（IDC/云/混合）。
- 逻辑层：库、表、字段、视图、存储过程、接口。
- 业务层：所属业务系统、业务用途、数据 Owner、数据 Steward。
- 流动层：数据从哪来、到哪去、经过哪些系统、是否出境、是否共享给第三方。
测绘不是一次性动作，而是持续过程。建议以"数据源台账"为基线，每次新增系统、变更接口、迁移上云时同步更新。台账字段可参考：数据源名称、类型、IP/域名、端口、所属业务、数据量级、敏感字段数、责任人、最近扫描时间、分级结果。
三、分类分级标准：从"是什么"到"多重要"
分类解决"数据属于哪个业务类别"，分级解决"数据有多敏感、需要多强的保护"。两者常被混为一谈，实际应分开设计。
分类建议按业务域划分，例如：用户数据、交易数据、营销数据、运营数据、财务数据、研发数据、人事数据。分类维度要稳定，避免随组织架构频繁变动。
分级建议按影响程度划分。以《数据安全法》和常见行业实践为参考，可采用四级：
| 级别 | 判定依据（示例） | 典型数据 | 保护要求（示例） |
|---|---|---|---|
| L1 公开 | 泄露不造成影响 | 公开产品介绍、公告 | 常规访问控制 |
| L2 内部 | 泄露造成轻微影响 | 内部制度、一般运营数据 | 身份认证 + 日志审计 |
| L3 敏感 | 泄露造成较大影响 | 手机号、地址、交易明细 | 加密存储 + 脱敏展示 + 最小权限 |
| L4 核心 | 泄露造成严重/重大影响 | 身份证号、银行卡、生物特征、核心算法 | 强加密 + 动态脱敏 + 双人审批 + 全链路审计 |
分级判定不能只靠字段名。同一个"手机号"字段，在营销系统中可能是 L3，在公开客服系统中可能只是 L2。因此分级要结合数据内容 + 业务场景 + 访问范围 + 法规要求综合判断，并保留人工复核通道。
四、标签体系：让分级结果"可执行"
分级结果如果只停留在表格里，就无法被技术系统消费。标签体系的作用是把分类分级结果转成机器可读的元数据，挂载到字段、表、接口、文件等对象上。一个可落地的标签体系通常包含：
- 分类标签：如
业务域=用户、数据主题=联系方式。 - 分级标签：如
敏感级别=L3、法规属性=个人信息。 - 处理标签：如
脱敏策略=手机号掩码、加密算法=SM4、保留期限=3年。 - 责任标签：如
Owner=用户中心、Steward=张三。
标签要能随数据流动。例如一条 L3 的手机号从生产库同步到测试库时，标签应自动继承并触发脱敏策略，而不是依赖人工重新标注。
五、落地工具选型：按能力矩阵而非品牌选
工具选型容易陷入"比功能清单"的误区。更实用的做法是按能力矩阵评估，重点看五类能力：
- 发现能力：支持的数据源类型、扫描性能、敏感识别规则可自定义程度、误报率控制手段。
- 测绘能力：能否自动建立数据血缘、能否与 CMDB/数据目录对接、能否展示数据流向。
- 分级能力：是否支持自定义分级模型、是否支持人工复核、是否支持分级结果版本管理。
- 标签能力：标签能否下发到数据库、网关、API 网关、大数据平台等执行点。
- 集成能力：是否有开放 API、能否与现有 SIEM、IAM、DLP、数据平台联动。
六、五个环节如何衔接
数据发现、资产测绘、分类分级、标签体系、工具选型不是五个独立项目，而是一条链：发现提供输入，测绘建立关联，分级给出判断，标签让判断可执行，工具让整条链可持续运转。任何一环缺失，都会导致"分级结果落不了地"或"标签发了没人用"。
最后强调一点：分类分级的价值不在于"分得多细"，而在于分级结果能否被技术系统自动执行。如果 L4 数据在测试环境仍然明文可见，那分级就只是纸面工作。因此，从第一天起就要把"标签下发到执行点"作为验收标准，而不是等平台建完再补集成。