2. 数据资产梳理与敏感数据识别

脱敏工程的第一步不是选工具，而是把"要保护什么"说清楚。数据资产梳理与敏感数据识别要回答三个问题：企业有哪些数据、哪些字段属于敏感数据、这些敏感数据从哪里流到哪里。只有把资产清单、敏感判定规则和血缘关系三者对齐，后续的脱敏策略、掩码算法和权限控制才有可靠依据。

一、数据分类分级：先定框架，再定粒度

分类解决"是什么"，分级解决"多重要"。分类维度通常按业务域（客户、订单、财务、人力）、数据形态（结构化、半结构化、非结构化）和数据主体（个人、企业、设备）划分；分级则依据泄露后的影响面，常见做法是四级：L1公开、L2内部、L3敏感、L4核心。

分级不能只靠字段名判断，要结合三个因子：标识强度（能否直接定位到自然人）、组合风险（单字段不敏感但组合后可识别）、合规约束（是否落入个人信息保护法、行业监管的特定类别）。例如"手机号"单独看是 L3，若与"身份证号+银行卡号"同表出现，整表应提升到 L4 管控。分级结果要落到字段级，而不是只标在库表级，否则脱敏时无法精确到列。

二、敏感字段判定规则：从命名到内容

判定规则分三层，逐层收紧：

• 元数据规则：字段名、注释、数据类型匹配关键词库，如 name、phone、id_card、bank_card、email、address、salary。优点是快，缺点是命名不规范时漏判。
• 数据内容规则：用正则或校验算法验证真实值。例如身份证号用 18 位加权校验，手机号用 ^1[3-9]\d{9}$，银行卡用 Luhn 算法。内容规则能纠正"字段名叫 remark 但实际存身份证"的情况。
• 上下文规则：结合表、业务域和关联字段判断。如"病历号"在医疗域是 L3，在测试域可能只是 L1。

实际落地时，建议把规则写成可配置的判定表，每条规则包含：规则 ID、匹配对象（字段名/内容/上下文）、正则或算法、命中后分级、置信度。置信度低于阈值的进入人工复核队列，而不是直接自动定级。

三、元数据与数据血缘采集

元数据采集要覆盖技术元数据（库、表、字段、类型、主外键）、业务元数据（业务含义、负责人、所属域）和管理元数据（分级、密级、生命周期）。采集方式有三种：直连数据库拉取 information_schema、解析 ETL 脚本和 SQL 日志、通过数据地图工具对接调度平台。

血缘采集的关键是拿到字段级映射，而不是只到表级。以一条典型链路为例：

ods.crm_customer.phone
  → dwd.customer_base.mobile_enc
  → dws.customer_profile.contact_phone
  → ads.marketing_list.phone

如果只在 ods 层脱敏，而 dwd 层通过解密还原了明文，血缘就能暴露这个断点。因此血缘图要标注每个节点的脱敏状态（明文/加密/掩码/哈希），才能判断敏感数据是否在链路中被"洗白"。

四、识别工具选型：看场景，不看名气

工具选型要匹配数据规模和治理成熟度。小规模、结构化为主的企业，用开源方案（如 Apache Atlas 做元数据、自研正则脚本做内容扫描）即可；中大型企业涉及多源异构、实时链路时，需要支持字段级血缘、规则热更新和 API 对接的商业或自研平台。选型时重点评估四项能力：

五、人工复核：把误判挡在脱敏之前

自动识别必然有误报和漏报。误报会让正常字段被过度脱敏，影响业务可用性；漏报则直接造成合规风险。复核流程应聚焦三类对象：置信度低于阈值的命中、分级为 L4 的核心字段、以及血缘链路中状态发生变化的节点。

复核不是简单点"通过/拒绝"，而要记录判断依据。建议复核工单包含：字段全路径、命中规则、样本值（脱敏展示）、业务负责人意见、最终分级、是否纳入脱敏、复核人和时间。这些记录本身就是审计证据，也能反向优化规则库——如果某条规则连续多次被人工否决，就应调整其正则或降低权重。

完成本节工作后，企业应得到三份可直接使用的成果：字段级数据资产清单（含分级）、敏感字段判定规则表、以及标注了脱敏状态的字段级血缘图。这三份成果是后续脱敏策略配置和效果验证的输入，也是数据安全审计的基础底稿。