敏感数据定义与分类分级：先搞清楚你要保护什么
聊DLP之前，有个问题必须回答：你到底要防什么？
我见过不少团队，一上来就部署规则、调模型，结果漏报一堆，误报更多。为什么？说白了——连敏感数据的边界都没划清楚。
这一章我们就来干这件事：把敏感数据定义清楚，再做分类分级。这是后续所有识别、联动、处置的根基。
2.1 什么是敏感数据？
敏感数据这个概念，不同行业、不同法规定义不太一样。我个人习惯把它拆成三类：
- 个人身份信息（PII）：姓名、身份证号、手机号、家庭住址、生物特征等。
- 金融与财务数据：银行卡号、交易记录、信用报告、股票持仓等。
- 医疗健康数据：病历、诊断结果、基因数据、医保信息等。
除此之外还有商业秘密、知识产权、政务数据等等。我在项目中遇到过最头疼的不是技术，而是业务方说“我这行数据都重要，你全保护吧”——那等于没保护。
核心原则：敏感数据的定义必须与法规（如 GDPR、PIPL、HIPAA）、行业标准、企业安全策略对齐。不能拍脑袋。
2.2 分类分级：从“一堆数据”到“结构化资产”
你想想看，如果所有数据都盖上“敏感”的章，DLP 要么全拦（业务崩了），要么全放（等于没装）。所以必须分级。
我常用的分类分级框架分两步走：
第一步：横向分类——按类型分
| 类别 | 典型数据示例 | 合规驱动 |
|---|---|---|
| 个人身份 | 身份证号、手机号、住址 | PIPL / GDPR |
| 金融数据 | 银行卡号、支付记录 | PCI-DSS / 银保监 |
| 医疗健康 | 病历、基因序列 | HIPAA / 卫健委 |
| 商业秘密 | 源代码、产品规划 | 反不正当竞争法 |
第二步：纵向分级——按敏感程度分
分级的目的是给不同等级的数据配上不同力度的管控策略。我推荐至少分三级：
- L3 极度敏感：泄露会造成重大声誉或财务损失。例如：核心算法源码、高管个人数据。策略：禁止外发、强加密、全量审计。
- L2 较敏感：泄露会带来中等风险。例如：内部项目文档、非公开财报。策略：审批外发、加密传输、抽样审计。
- L1 一般敏感：泄露影响可控。例如：员工通讯录、公开项目计划。策略：仅标记、不做硬拦截。
我的经验：分级不是一次性的。随着业务变化、法规更新，需要定期审视。我曾经因为没及时更新分级，导致某新业务产生的海量客户数据被归为L1，差点出事。
2.3 分类分级落地：从标准到正则
定义完框架，接下来要把它翻译成机器能理解的东西。常见的做法是做“数据指纹”和“正则模式”。
举个例子，中国大陆身份证号的规则：18位，前6位地区码，接着8位生日，最后4位校验码。我们可以写一个正则：
// 中国大陆身份证号匹配示例
const idCardPattern = /^[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]$/;
但正则只能解决格式固定的场景。对于非结构化文本（比如聊天记录里的“叫张三，13612345678”），还得靠机器学习模型。
注意：不要迷信正则的准确率。测试样本里的身份证号几乎都能命中，但线上可能误伤“客服说：我姓张，工号12345678”。域内测试和灰度验证是必须的。
2.4 知识结构图：敏感数据识别与分类分级体系
2.5 踩坑指南：我曾经…
我曾经帮一家金融公司做数据分类，他们把“客户姓名+银行卡号”定为L3，但忘了把“客户姓名+身份证号”也纳入。结果员工通过邮件发送的身份证信息完全没被拦住。后来补了一个组合规则才堵上。
所以，定义敏感数据时，一定要考虑组合场景。一条数据可能不敏感，但两条数据放一起就是高危。
最佳实践：每次定义新敏感数据类型，先做一个头脑“攻击树”：假设你是攻击者，你会怎样从现有数据里拼出敏感信息？然后用这个视角反推分类。
嗯，这一章先到这。搞清楚“什么是敏感”“敏感到啥程度”，后面我们才好谈怎么实别、怎么联动。别急，基础打牢了，后面的活才快。