### 4、DLP中的正则匹配需求：敏感数据识别规则编写

正则敏感数据检测与DLP接口集成 - 第4节

4.1 先理一理：DLP到底在“防”什么

很多人一上来就写正则，结果匹配了一堆没用的东西。

说实话，在动手写正则之前，得先搞清楚一件事：

你的DLP系统到底要管哪些敏感数据？

我一般在项目启动时，会拉着业务方一起盘一遍资产。常见的敏感数据类型，基本上可以分成这几类：

类别	典型数据	风险等级
个人身份信息	身份证号、护照号、社保号	高
金融信息	银行卡号、信用卡号、CVV	极高
通信凭证	手机号、座机号、邮箱	中
商业机密	源代码片段、合同金额、财务数据	高
设备标识	IP地址、MAC地址、IMEI	低

你看，风险等级不一样，你写的正则的“松紧”程度也得跟着变。

4.2 敏感数据识别规则怎么写？我的套路

正则看起来只是一串字符，但写好了就是一把精确的刀。

我个人习惯把一条敏感数据识别规则拆成四个部分：

4.2.1 定边界

先问自己：这个东西一般出现在什么场景里？

比如身份证号，它前后大概率是空格、标点或者换行。你不能让它把一串18位数字当成身份证号。

我习惯用 \b 或者 (?<!\d) 来做边界断言。

// 错误：没有边界
\d{18}

// 正确：加了数字边界
(?<!\d)\d{18}(?!\d)

4.2.2 做结构

敏感数据大多有固定结构。比如信用卡号：

• 开头是卡组织标识（如4开头是Visa，5开头是Master）
• 总长度14-19位
• 可能有空格或连字符分隔

我会把这些结构特征全部写进正则里，而不是偷懒用 \d+。

// 信用卡号示例：4位一组，带空格，以4开头
\b4[0-9]{3}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{4}\b

4.2.3 做校验

这里是最有意思的部分。

很多新手只做格式匹配，不做内容校验。但在敏感数据场景里，格式对了可能根本不是真实数据。

我一般在正则之后，再加一层算法校验。比如身份证的最后一位校验码，比如信用卡的Luhn算法。

为什么不写在正则里？因为正则做数学运算太勉强了，性能也差。你用代码做一次校验，稳得多。

4.2.4 设上下文

有些数据单独出现没意义，但放在特定上下文里就很危险。

比如一串16位数字，放在“银行卡号：”后面，和放在“验证码：”后面，意义完全不同。

我习惯在正则里加上关键词前置过滤：

// 匹配“卡号”或“卡号：”后面跟的16位数字
(卡号|Card No)[：: ]?\s*\d{16}

这样做的好处是——减少垃圾匹配，提高命中率。

4.3 实际场景中的常见规则集

项目做多了，你就会发现其实大部分场景的敏感数据类型都差不多。

我整理了一份基础规则集，你可以直接参考：

数据项	正则模式（核心）	备注
中国大陆身份证	[1-9]\d{5}(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]	记得做校验码验证
手机号	1[3-9]\d{9}	国际号码需单独处理
信用卡	\b(4[0-9]{12})(?:[0-9]{3})?\b	需配合Luhn算法
IP地址	\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}	建议加内网IP排除
邮箱	[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}	要避免极端长度

你看，每种数据的正则都不一样。我建议你把每一条规则放到一个单独的规则文件里，方便维护和复用。

4.4 一个特别容易踩的坑：语言和区域差异

我在项目中遇到过一个问题：

一个客户用的是欧美系统，他的正则只匹配了标准美式手机号格式。结果中国分公司的数据全部漏报了。

为什么？

因为中国的手机号是11位纯数字，美国的是10位带括号和空格。你写正则的时候，一定得考虑数据来源的地域性。

4.5 测试你的正则：先跑一遍再说

正则写好以后，千万别直接上生产。

我每次都会做三件事：

1. 正向测试：找10条真实的敏感数据，看看能不能全部命中。
2. 反向测试：找100条普通文本，看看有没有误报。
3. 压力测试：用10000行数据跑一次正则引擎，看看性能是否稳定。

有一次我在测试时发现，一个身份证正则匹配了“12345619900101123x”这种伪造数据——因为我的边界没写对。从那以后，我再也不敢偷懒了。

4.6 总结一下：写敏感数据正则的三个铁律

• 宁可精确，不要宽泛：宽泛的正则只会让你被误报淹没。
• 正则 + 算法 = 最佳组合：格式匹配只是第一关，真正的验证要靠逻辑。
• 上下文比正则本身更重要：知道它是什么，不如知道它在哪里。

最后，我还想提醒一点。

正则不是一劳永逸的。

敏感数据的格式会变，法规要求也在变。我个人的做法是每季度做一次规则审计，看看有没有需要更新或者废弃的规则。团队里最好有一个人专门盯着这块，不然时间一长，规则库就乱了。