DLP（数据防泄漏）基础
什么是 DLP？核心概念
说实话，我刚接触 DLP 那会儿也觉得它就是个“关键字匹配”工具。后来踩了坑才发现——DLP 本质上是一套围绕数据生命周期的管控体系。我个人习惯把 DLP 拆成三个核心环节：识别、监控、保护。
- 识别：知道数据在哪，长什么样，敏感级别多高。
- 监控：数据流动时，实时判断有没有违规行为。
- 保护：该阻断就阻断，该告警就告警，该加密就加密。
你在项目中最直观的感受就是——DLP 系统就像企业内部的“数据交警”。它盯着每一条出站流量、每一个 USB 拷贝动作、每一份邮件附件。下面这个表格列出了 DLP 的核心组件，我建议你背下来，面试或者做架构设计时经常用得到。
| 组件 | 职责 | 我在项目中遇到的坑 |
|---|---|---|
| 数据发现 | 扫描存储位置，找到敏感数据 | 扫了一周全量数据，性能扛不住 |
| 分类分级 | 给数据打标签，区分机密/内部/公开 | 业务方不认标签标准，吵了好几次 |
| 策略引擎 | 根据规则判断是否违规 | 正则写得太宽，误报率爆炸 |
| 事件响应 | 处理结果：阻断、告警、审计 | 真的阻断后，业务人员投诉流程卡死 |
数据分类分级——DLP 的“眼睛”
你要是没把数据分好级，后边做策略全是瞎蒙。我个人习惯先把业务数据进行分类：比如按部门（财务、研发、HR）、按业务属性（合同、代码、薪酬）、按合规要求（GDPR、等保、PCI-DSS）。然后再定敏感级别。
举个例子，我曾经帮一家金融客户做 DLP 项目。他们把所有文件都标成“机密”，结果策略引擎每天弹几千条告警，运维看得想骂人。后来我们按这个四级模型重新分级，误报率直接从 40% 降到 3%。
| 级别 | 定义 | 示例 | 典型动作 |
|---|---|---|---|
| 公开 | 完全开放，不敏感 | 产品白皮书、官网素材 | 不限制 |
| 内部 | 仅限公司内部使用 | 员工手册、培训材料 | 记录外发行为 |
| 敏感 | 泄漏会产生商业风险 | 客户名单、薪资数据 | 审批后外发 |
| 绝密 | 核心资产，泄漏可致命 | 算法源码、定价模型 | 物理隔离，禁止外发 |
策略引擎——DLP 的“大脑”
策略引擎怎么工作的？说白了就是一条“if-then”链条：
数据内容 → 触发条件（正则/指纹/ML模型） → 匹配规则 → 执行动作（阻断/告警/加密）嗯，这里要注意，很多团队把策略写得又长又绕，一个规则里嵌套七八个条件。我曾经因为这种写法加班到凌晨三点排查误报。我的建议是：每个策略只解决一类场景。
- 正则策略：匹配信用卡号、身份证号、护照号。
- 指纹策略：匹配核心文档的哈希值或局部指纹。
- 机器学习策略：识别结构化数据中的敏感字段（比如用 NLP 检测对话中的机密信息）。
避坑指南：我曾经把一个正则写成
.{16} 匹配任何 16 位数字，结果系统把用户输入的验证码全告警了。后来改成了 Luhn 算法校验信用卡号的正则，误报降了 80%。
传统规则的局限
到了这里，我想聊聊为什么传统 DLP 策略越来越不够用。你想想看，规则引擎本质上就是个“精确匹配”系统。它只能认识你告诉它的模式。一旦数据变了样，它就傻眼了。
- 正则表达式太死板：攻击者把身份证号中间加个空格或换行，正则就失效了。
- 上下文缺失：同一段话“我的银行卡密码是123456”和“图中验证码是123456”—— 传统引擎分不清哪个是真的敏感信息。
- 误报率极高：一个稍微宽泛的规则就能让安全团队每天处理几百条无效告警。
- 维护成本爆炸：业务变了、合规变了，规则就要人肉改，每次上线测试周期长。
我曾经见过最惨的情况：某厂商在生产环境放了 2000 多条正则，每周被新数据打脸一次。团队疲于奔命，最后还是上了机器学习模型才解脱。
所以——传统规则适合做“底线防守”（比如拦截已知的明文银行卡号），真正的威胁往往藏在那些“看起来正常但实际有风险”的行为里。这就是为什么我们后面要用机器学习模型来补充这个短板。