敏感数据识别与分类：从经验到体系
数据分级的第一步，其实是搞清楚我们手里到底有什么。很多人觉得这很简单——不就是把数据分分类吗？真要动手，你会发现比想象中复杂得多。我个人习惯把敏感数据识别分成三个维度：个人信息、商业秘密、核心业务数据。这三个维度不是并列关系，而是交叉关系，同一份数据可能同时属于两类。下面我结合项目经历，把这三个维度拆开讲讲。
个人信息识别
个人信息最容易理解，也最难识别。为什么？因为个人信息藏在各种奇怪的地方。
我在一个电商平台安全审计项目里遇到过一个问题：他们的订单表里有用户姓名、手机号、地址，这些明显是个人信息。但客服备注栏里，客服人员会把用户的身份证号直接写进文本，比如“客户说身份证号是123456...我帮他查一下”。这种非结构化的个人信息最难抓。
识别个人信息，我建议按三个层次来查：
- 显式字段：列名包含 name、phone、id_card、email、address 等。这个用正则或字典匹配就能搞定。
- 隐式字段：列名看不出，但数据内容符合模式，比如连续18位数字（身份证）、11位数字（手机号）。需要模式识别。
- 文本中的嵌套信息：日志、备注、工单描述里混入的个人信息。这个最难，需要NLP模型做实体抽取。
商业秘密识别
商业秘密这个概念比较模糊。法律上有定义，但落到数据层面，我们一般看它是否符合三个特征：秘密性（不为公众所知悉）、价值性（具有商业价值）、保密性（权利方采取了保密措施）。
实际项目中，商业秘密的典型形式包括：
- 源代码和算法模型参数
- 客户名单和供应商清单
- 定价策略和报价方案
- 未公开的产品设计和配方
- 内部财务数据和经营战略
识别商业秘密，不能只用正则。因为商业秘密往往没有固定格式。比如“新产品定价策略”这个PPT，文件名叫“2025Q2_策略.pptx”，它的敏感度比公司年报高得多，但文件命名和内容格式没有统一特征。
我个人习惯的做法是：用数据血缘 + 数据目录打标签。在数据产生源头（比如研发代码仓库、CRM系统）埋点，当数据被创建时自动检测它是否属于某个敏感资产组。例如Git仓库的代码只要推送，就触发扫描是否包含硬编码密钥、API接口文档等。
核心业务数据识别
核心业务数据是公司真正赖以生存的数据。不同公司，核心业务数据可能完全不同。一个支付公司的交易流水是核心；一个医疗公司的患者诊疗记录是核心；一个游戏公司的用户行为日志就是核心。
识别核心业务数据的难点在于：它往往和不核心的数据混在一起。举个例子，在线教育平台的核心业务数据可能是“课程购买记录”和“学习进度数据”，但用户仅仅浏览了课程页面产生的PV日志，虽然也是业务数据，却不核心。
我建议用业务影响分析法来区分：如果这份数据丢失或被篡改，公司还能不能正常运营？如果能，就不算核心；如果不能，就是核心。
| 数据类别 | 典型示例 | 损失后果 | 识别方法 |
|---|---|---|---|
| 个人信息 | 身份证号、手机号、家庭住址 | 合规罚款、用户诉讼、品牌信誉崩塌 | 正则匹配 + NLP实体抽取 |
| 商业秘密 | 源代码、客户清单、算法参数 | 竞争优势丧失、泄露后不可逆 | 数据血缘追踪 + 人工标记 |
| 核心业务数据 | 交易流水、订单数据、诊疗记录 | 业务停摆、收入中断 | 业务影响分析 + 数据字典比对 |
数据分类标签定义
识别出敏感数据之后，必须给它贴上统一的标签。标签定义要够细、够明确，否则后续的权限模型和密钥联动都会出乱子。
我经历过一次惨痛教训：团队之前只定义了“机密”“内部”“公开”三个标签，结果“机密”下面包含从公司战略文档到员工工资表的所有东西，根本没法精细授权。后来我们重新设计了标签体系，采用了三级分类 + 环境限定的方案：
- 一级：数据类别（个人信息、商业秘密、核心业务数据）
- 二级：敏感等级（S1~S4，从公开到绝密）
- 三级：数据子类（比如“身份证号”属于个人信息→S3→身份证类）
- 环境限定：生产环境、预发布环境、测试环境、开发环境
personal_info/S3/phone/prod。同样这条手机号如果被脱敏成138****0000，在测试库里可以标记为 personal_info/S1/phone_anon/test。
有了这种标签体系，后续的权限模型才能做到精确匹配：只有需要查看真实手机号的岗位，才能拿到S3级别的personal_info标签的数据。
自动化识别工具与人工审核结合
光靠人工去识别所有敏感数据是不可能的。一个中型公司的数据库就有几百张表、上千万行数据，人工翻一遍得累死。必须上自动化工具。
我常用的自动化识别工具组合是：
- 数据发现扫描器：类似Apache Atlas、Collibra这类工具，能自动扫描数据源、识别敏感列并打标签。
- 正则 + 关键词字典：对固定的敏感模式（身份证号、手机号、银行卡号）做规则匹配。
- NLP模型：对非结构化文本（工单、邮件、日志）做实体识别。
- 数据血缘分析：跟踪数据的流向，确保标签从源头一直传播到下游。
但是自动化工具不是万能的。我遇到过不少误报和漏报：比如把“手机号码”字段里全是空值但表字段名匹配了正则，导致打上错误标签；或者算法模型把“张三”、“李四”这种普通姓名识别为人名（确实是），但业务上根本不敏感。所以必须引入人工审核作为兜底。
人工审核怎么落地？我的建议是：
- 对自动化识别出的疑似敏感数据，生成评审清单，推送给业务部门的接口人确认。
- 对确实敏感的标签，打上“待确认”状态，直到人工确认后才变为“已确认”。
- 设置定期的复审周期（比如每季度一次），因为业务变化后，旧的敏感数据可能不再敏感，新的敏感数据会冒出来。
嗯，回到整体流程上。有了自动化识别和人工审核的结合，标签的质量才能保证。你可以把它想象成两个闭环：自动化工具做第一轮粗筛，人工做第二轮精调。两个环节缺一不可。
最后说一句：敏感数据识别不是一次性的战役，而是持续性的运营。我见过团队花三个月做了全量扫描，然后就把工具扔一边了。半年后新系统上线，新数据进来，全都不带标签。所以最好把识别流程嵌入到数据生命周期管理里——数据一创建，自动触发识别扫描；业务一变化，自动触发重新评估。这样才不会被动的追着数据跑。