DLP系统架构：核心组件
做DLP系统对接，你要是只盯着接口文档看，很容易掉进细节里出不来。我个人的习惯是，先搞明白整个系统是怎么拆的——说白了就是那三个引擎：策略引擎、检测引擎、响应引擎。
这三个东西各管一摊，但又必须串起来。你想想看，数据从网络流进来，得先有人判断它是什么类型，属于什么级别，然后决定要不要拦、要不要告警。这一连串动作的背后，就是三个引擎在接力跑。
1. 检测引擎：到底在查什么？
检测引擎是DLP的“眼睛”。它不负责做决定，只管把数据里里外外看个透。我最早对接过一个银行项目，他们的检测引擎跑了一周，结果发现全是误报——后来查到是正则写得太宽了。
检测引擎通常干三件事：
- 内容识别：扫描文档正文、邮件正文、聊天记录里的敏感词。比如身份证号、信用卡号、合同条款。
- 指纹匹配：对已标记的敏感文档做哈希或模糊哈希。你改个标点、换个格式，指纹一比对就露馅。
- 上下文分析：光看“123456”不行，得结合周围文字判断它是不是密码、是不是测试数据。
关键指标：检测引擎的召回率和精准率必须平衡。我见过一个客户把正则写得特别严，结果每天漏报几万条——还不如不用。
2. 策略引擎：谁来拍板？
检测引擎把结果报上来，策略引擎就得拍板了。这玩意儿说白了就是个规则执行器，但规则的编排方式决定了整个系统的灵活性。
策略引擎的核心是策略树。每个策略由条件、动作、优先级三部分组成。比如：
策略示例：
IF 数据分类 == '机密' AND 目标域 == '外网邮箱'
THEN 动作 = '阻断' + '告警' + '审计'
PRIORITY = 100条件可以叠加，优先级决定冲突时听谁的。我做过一个项目，客户部门的策略写重了，低优先级的策略把高优先级的覆盖了——结果机密文件被当作普通文件放行出去。那一次事故后，我要求所有策略必须加冲突检测。
注意：策略引擎的决策必须是幂等的。同样的条件输入，必须得到同样的输出。否则你在测试环境调好的规则，一上线就乱套。
3. 响应引擎：动手干活的
响应引擎是最后执行者。它接到策略引擎的指令后，什么该拦、什么该放、什么该给谁发邮件，都是它的活。
响应动作一般分三级：
| 级别 | 动作 | 典型场景 |
|---|---|---|
| 严重 | 阻断传输 + 强制告警 + 审计 | 涉密文件发往公共邮箱 |
| 警告 | 放行但记录 + 弹窗提醒用户 | 内部资料分享给合作伙伴 |
| 记录 | 仅审计，不干预 | 低敏感度数据常规流转 |
嗯，这里要注意：响应引擎不能成为性能瓶颈。我曾经见过一个案例，响应引擎收到指令后要写数据库，结果数据库IO打满了，导致后续的数据包全部排队——最终用户等了一分钟才收到邮件，业务直接中断。
避坑指南：响应引擎最好支持异步执行。阻断指令可以同步，但审计日志写入一定要异步，否则会拖慢整个链路。
4. 三个引擎怎么协同？
光知道每个引擎干嘛的还不够，你得理解它们之间的数据流。我习惯用一个“三明治”模型来记：
- 检测引擎做上行分析（从数据里提取特征）；
- 策略引擎做中间决策（匹配规则库里有没有命中）；
- 响应引擎做下行执行（根据决策操作数据）。
三个引擎之间靠内部消息总线通信。我做过一个大客户的改造，他们原来用RPC直连，每增加一个检测节点就要改一遍策略引擎的代码。后来换成消息队列，检测引擎只管往队列里扔识别结果，策略引擎从队列里消费，解耦后扩展性直接翻倍。
核心原则：检测引擎无状态，策略引擎有状态（要维护规则版本），响应引擎必须可回滚。你想想看，万一误拦了正常业务，得能快速恢复。
5. 小结
DLP的三个核心组件各司其职，但又紧密耦合。你在对接接口时，一定要先搞清楚当前接口属于哪个引擎的范畴。比如检测引擎的接口通常返回内容标签列表，策略引擎的接口返回决策指令，响应引擎的接口则接收执行结果回调。
我个人建议，在设计对接方案时，先把这三个引擎的边界画清楚。别在检测模块里写策略逻辑，也别在响应模块里做内容分析——责任拆得越清楚，后期维护越省心。