📚 课程目录第3章数据分类分级与资产地图

3. 数据分类分级与资产地图

数据分类分级是数据安全治理的起点，它回答两个基本问题：这条数据“是什么”（分类），以及它一旦泄露、篡改或损毁会造成多大影响（分级）。分类解决语义归属，分级解决保护强度，二者共同决定后续加密、脱敏、访问控制与审计策略的基线。没有可靠的分级，任何安全控制都只能凭经验拍板。

一、分类分级标准与方法论

落地时通常采用“行业标准 + 企业细则”的双层结构。以《数据安全法》《个人信息保护法》为上位依据，金融、电信、医疗等行业再叠加各自监管要求。企业侧常见的分级模型是四级制：L1 公开、L2 内部、L3 敏感、L4 核心。分级不是拍脑袋，而是沿两个维度打分：影响对象（个人、组织、社会、公共利益）与影响程度（轻微、严重、特别严重）。

分类维度则更贴近业务。常见做法是按“业务域 + 数据主体 + 敏感属性”三维打标，例如“客户域 / 个人 / 身份证号”归入个人信息中的敏感个人信息。分类与分级是正交的：同一分类下可以有不同级别，同一级别也可以横跨多个分类。实践中建议先定分类树（3～4 层足够），再对叶子节点逐一定级，避免在中间层反复纠结。

分级判定建议保留“判定依据”字段，记录命中了哪条规则、依据哪条法规，便于后续审计与申诉。

二、自动化分类分级技术

纯人工打标无法应对 PB 级数据资产，自动化是必选项。主流技术路线有三类：

规则/正则匹配：对结构化字段名（如 id_card、phone）和值模式（18 位身份证、11 位手机号）做匹配，准确率高、可解释，但覆盖有限。
机器学习分类：用已标注样本训练文本分类器，对字段注释、表名、样例值做特征提取，适合非结构化与半结构化数据。
大模型语义识别：对字段上下文、业务描述做语义理解，能识别“客户标识”“账户主体”这类同义表达，召回率更高，但需控制成本与误报。

工程上通常采用“规则打底 + 模型补充 + 人工复核”的混合流水线：规则先覆盖高置信度字段，模型处理长尾，低置信度结果进入人工队列。置信度阈值建议设在 0.85 以上自动通过，0.6～0.85 人工确认，低于 0.6 直接丢弃或重新采样。

三、数据资产测绘与元数据管理

分类分级的前提是“知道自己有什么数据”。数据资产测绘通过采集元数据来构建资产台账，采集对象包括：库表结构、字段类型与注释、数据量、更新频率、血缘关系、访问日志。元数据管理平台负责统一存储这些信息，并维护技术元数据（库、表、字段）、业务元数据（业务含义、负责人）和操作元数据（ETL 任务、调度周期）三类视图。

血缘关系是资产地图的骨架。字段级血缘能回答“这个身份证号从哪张源表来、经过哪些加工、流向哪些下游报表”，一旦某张表被定为 L4，其下游衍生数据也应继承相应级别。这种“级别传播”规则是自动化分级能否闭环的关键。

四、数据地图构建

数据地图是资产测绘的可视化产物，通常以“主题域—数据域—实体—字段”的层级组织，并叠加分级标签、负责人、访问热度等属性。一张好的数据地图应支持三种检索：按业务名称搜、按分级筛、按血缘追。它既是安全团队的治理底图，也是数据开发找数、用数的入口。

构建顺序建议为：先接入元数据源（Hive、MySQL、对象存储），再做字段解析与打标，然后生成血缘，最后渲染地图。地图不是一次性交付物，需要随元数据变更增量刷新。

五、实战：设计并实现一个数据分类分级原型系统

下面给出一个可运行的最小原型设计，技术栈为 Python + SQLite + 正则/关键词规则，目标是完成“采集—打标—分级—输出地图”的闭环。

1. 元数据采集。从 Hive Metastore 或 information_schema 拉取表名、字段名、字段注释、样例值。示例输入：

table: dwd_customer_info
columns:
  - name: cust_name,   comment: 客户姓名, sample: 张三
  - name: id_card,     comment: 身份证号, sample: 110101199001011234
  - name: phone,       comment: 手机号,   sample: 13800138000
  - name: reg_date,    comment: 注册日期, sample: 2023-05-12

2. 规则打标。定义规则库，每条规则包含字段名关键词、值正则、分类、分级、置信度。示例规则：

RULES = [
  {"kw": ["id_card","身份证"], "regex": r"^\d{17}[\dXx]$",
   "category": "个人信息/敏感", "level": "L4", "conf": 0.95},
  {"kw": ["phone","手机"], "regex": r"^1[3-9]\d{9}$",
   "category": "个人信息/敏感", "level": "L3", "conf": 0.92},
  {"kw": ["name","姓名"], "regex": None,
   "category": "个人信息/一般", "level": "L3", "conf": 0.80},
  {"kw": ["date","日期"], "regex": r"^\d{4}-\d{2}-\d{2}$",
   "category": "业务数据", "level": "L2", "conf": 0.88},
]

3. 分级判定。对每个字段依次匹配规则，取最高置信度结果；若字段名与样例值同时命中，置信度加权 +0.05。未命中任何规则的字段默认 L2 内部，并标记“待人工确认”。

4. 级别传播。解析 SQL 血缘，若上游字段为 L4，则下游直接派生字段继承 L4；若下游做了聚合或脱敏（如只保留手机号前 3 位），可降一级，但需人工确认。

5. 输出数据地图。将结果写入 SQLite，字段包括：表名、字段名、分类、分级、置信度、判定依据、负责人。前端按主题域聚合展示，支持按分级筛选。

示例运行结果（合理假设）：id_card 命中身份证正则，判定 L4，置信度 0.95；phone 判定 L3，置信度 0.92；cust_name 判定 L3，置信度 0.80，进入人工复核队列；reg_date 判定 L2，置信度 0.88。最终该表整体级别取最高值 L4，并在地图中以红色标签标注。

原型系统仅用于验证流程，生产环境需补充权限控制、审计日志、规则版本管理与误报反馈闭环，避免规则漂移导致分级失真。

判断原型是否达标，可看三个指标：高置信度字段自动通过率是否超过 70%，人工复核队列是否可控（单表不超过 5 个字段），以及级别传播后下游标签是否与上游一致。若一致率低于 90%，说明血缘解析或传播规则需要修正。