三、DLP策略体系架构：策略引擎、规则、动作

聊到DLP策略，很多新手第一反应就是写关键词、设正则。但说实话，这只是最表层的东西。真正让策略跑起来、不出乱子的，是它背后的三层架构——策略引擎、规则、动作。

我习惯把这套体系比作“保安系统”。策略引擎是整个保安队的队长，他负责调度；规则是挂在墙上的巡逻路线和禁止事项清单；动作则是保安看到违规时喊的那嗓子，或者直接锁门的那个动作。三层缺一不可。

你想想看，如果只有规则没有引擎，谁来检查这条规则什么时候触发了？如果只有动作没有规则，那锁门锁谁去？所以今天我们先把这个骨架讲清楚。

3.1 核心分层逻辑

DLP策略体系从上到下分三层，每层有明确的职责，互不越界。

3.2 策略引擎 — 核心技术拆解

策略引擎不是一个“大统一”的模块。它内部其实是串行的流水线。我习惯画成三段：输入解析 -> 规则匹配 -> 决策输出。

1. 输入解析：把外发的邮件、HTTP上传、FTP、即时消息拆成元数据+载荷。比如邮件要取出发件人、收件人、主题、正文、附件名和内容。
2. 规则匹配：顺序遍历，直到遇到第一条命中的规则就停下（也有引擎设计成全部遍历加权）。
3. 决策输出：把匹配结果打包成事件，传给动作模块。

你可能会问：为什么不大并发一次匹配所有规则？性能考虑。实际上大部分外发场景流量是连续小包，一个一个处理比批量成本低。我曾在客户现场遇到过一条“对所有附件做全量指纹匹配”的规则，结果把邮件网关CPU直接吃满了——后来改成了先判断附件后缀与大小，再触发指纹，性能才稳住。

3.3 规则的“力度”与“粒度”

规则不是越多越好。我记得有个团队上了500条规则，结果每天告警2万条，运营彻底瘫痪。规则设计讲究两个维度的平衡：力度（宽松 vs 严格）和粒度（粗放 vs 精细）。

就我个人习惯而言，先做粗粒度保底，再逐层加细。比如初期只配一条“所有含‘机密’关键字的外发文件 -> 告警”，跑一个月看看命中率，再考虑按部门加白名单。步子太容易摔。

3.4 动作联动：不止阻断与放行

很多教材说动作只有“阻断”和“告警”。但现在的DLP产品早就扩展了。给你列一下我常用的动作矩阵：

• 阻断：这一步就是不让数据出去。但内部有差别——是直接丢弃包？还是返回客户端一个错误？我个人建议弹提示并记录，因为静默丢弃会让用户莫名其妙，投诉随之而来。
• 告警：分管理员告警和用户告警。管理员告警走邮件、syslog、甚至企微推送；用户告警则是弹窗说明违规原因。
• 加密：适用于外部业务邮件。自动对附件使用S/MIME或PGP加密，既满足合规又不影响正常流程。
• 审批：发入审批池，由上级或数据所有者人工审核后放行。审批流程通常要关联即时通讯工具。
• 沙箱：高级玩法。可疑附件先进入沙箱分析，再决定放不放行。

这里有个坑——动作的执行顺序。比如一条规则同时配了“阻断”和“告警”，那到底是先阻断还是先告警？在多数引擎里，动作是并行触发的，阻断成功后才写日志。但我也见过产品引擎设计成串行，先告警后阻断——万一告警发送失败，阻断也失效了。所以部署前一定跟厂商确认好动作执行模式。

3.5 策略联动：规则之间的“因果关系”

单条规则作用有限，强的是联动。比如：

说白了，这就是状态机。DLP引擎其实维护了一个会话状态表：谁、在什么时间、干了什么、累计多少次。规则可以引用这些状态。你写规则的时候，要把“条件”和“状态”分开，比如：

# 错误示范——把状态写死在规则里
条件: 文件包含"薪资" AND 发送次数 > 3

# 正确示范——使用引擎内置变量
条件: 文件敏感度标签 == "薪资"
动作: 更新发送者计数器
次级规则(当计数器 > 3):
  条件: 上一次已触发告警
  动作: 阻断 + 强制审批

我曾经在甲方环境调试过一套联动策略，结果因为引擎的计数器缓存有效期是5分钟，而用户操作间隔是6分钟，导致阈值永远达不到。最后把缓存改成基于用户维度的redis持久化才解决。嗯，这里要注意：联动依赖的共享状态必须明确持久化策略，否则规则白写。

3.6 策略生命周期管理

策略不是一次配置完就扔那儿不管的。我见过的失败案例，多半是策略上线后没做生命周期维护。给出一个我常用的管理清单：

好了，以上就是DLP策略体系架构的核心拆解。策略引擎是大脑，规则是骨架，动作是手脚。这三层各司其职，顺序思考、并行执行，才能支撑起一个外发场景下的稳定防护体系。接下来的章节我们会深入具体的策略编写，但我建议你先把这张架构图刻在脑子里——以后无论遇到什么产品、什么场景，回到这三层去思考，就不会乱。