4. DLP策略核心概念：内容识别、规则引擎、动作执行

做DLP，特别是要跟TLS加密通道打交道的时候，有三大块是绕不开的：内容识别、规则引擎和动作执行。这三个东西说白了就是DLP策略的骨架，少了任何一个，策略就是废纸一张。

我刚开始接触DLP那会儿，以为只要在出口做个关键词匹配就完事了。结果呢？流量一上TLS，全糊了。嗯，后来才明白，加密通道下，这三个环节都得重新设计。

4.1 内容识别：你得知道在“看”什么

内容识别是DLP的眼睛。没有它，你连数据长什么样都不知道。传统的识别手段包括：

• 关键词/正则匹配：比如身份证号、银行卡号、合同编号。
• 文件指纹：精确匹配已知敏感文档的哈希或内容片段。
• 机器学习分类：用模型判断文档类型或敏感等级。
• 结构化数据识别：识别数据库表、CSV列名等。

但在TLS加密通道里，这些手段有一个前置动作——解密。不解密，你看到的全是乱码。我见过不少项目，策略写得天花乱坠，结果一上HTTPS，全部失明。所以，内容识别在TLS下的第一步不是匹配，而是脱密。

我个人习惯把内容识别分为两个层级：

层级	识别对象	是否依赖解密	示例
元数据层	SNI、证书Subject/Issuer、TLS版本、IP	否	阻止特定域名的流量
载荷层	HTTP内容、文件内容、数据库查询	是	在解密后的POST请求中识别信用卡号

你可能觉得元数据层够用了？其实不然。很多敏感数据就藏在加密的API请求里，只看SNI根本抓不住。我建议，只要法规允许、成本可控，尽量做载荷层识别。

4.2 规则引擎：把识别结果变成判断逻辑

规则引擎是做决策的脑子。内容识别产出一堆“这个流量里有疑似敏感数据”的信号，规则引擎要把它们组合起来，输出一个最终动作。

你想想看，规则引擎的核心要素有哪些？

• 条件组合：AND、OR、NOT、阈值比较、时间窗口。
• 优先级：多条规则命中时，谁说了算？
• 上下文关联：比如同IP、同用户、同会话内的行为。
• 状态维持：有些规则需要跨包、跨连接关联。

我曾经在一个金融客户那里踩过一个坑：他们写了一条规则，识别PDF里的“工资单”关键字就告警。结果HR系统每天发几千封PDF工资单到员工邮箱，全被拦截。为什么？规则没加“出境”这个条件。规则引擎如果不结合方向、用户角色、时间，很容易误杀。

在TLS场景下，规则引擎还得额外处理几个变量：

• 加密协商状态：TLS握手是否完成？使用的密码套件是否弱？
• 证书有效性：证书是否自签名、是否过期、是否被吊销。
• 解密失败处理：如果解密失败，是放行还是阻断？

我习惯把规则引擎的流程画成一个决策树。嗯，下面这张图能帮你更直观地理解：

4.3 动作执行：光识别不动作等于零

动作执行是DLP的“手脚”。规则引擎给出了“该做什么”的结论，动作执行模块就得做到位。

常见的动作有：

• 放行：不做干预，但记录日志。
• 告警：发送告警给管理员，同时放行或阻断。
• 阻断：拒绝连接，或者注入RST包。
• 隔离：把文件移到隔离区，或重定向到审批流程。
• 改写/脱敏：在加密通道中，这个很麻烦——你需要在解密后修改内容再重新加密。

对于TLS加密通道，动作执行有几个特殊之处：

1. 阻断时机：最好在TLS握手阶段就拒绝，而不是等数据传了一半再断。否则客户端可能重试或缓存。
2. 绕过防护：如果只做TCP RST，攻击者可以复用TLS session ID继续发。我建议在TLS代理层直接关闭会话。
3. 日志完整性：记录未解密前的元数据和解密后的识别结果。万一合规审计，能还原现场。

4.4 三者的协同关系

内容识别、规则引擎、动作执行，不是串行三段论那么简单。它们之间有反馈回路：

• 动作执行的结果（比如某个文件被阻断）要能反馈给规则引擎，用来调整后续判分。
• 内容识别的手段（比如ML模型）也要根据规则引擎的误报/漏报情况做迭代。
• 在TLS场景下，解密网关的状态还会影响识别优先级——比如密码套件太弱，可能直接触发阻断，不需要等载荷识别。

我把这三者的协同关系总结成一个“闭环三角”：

模块	输入	输出	反馈给谁
内容识别	原始流量（加密/未加密）	结构化特征（关键词命中、指纹等）	规则引擎、ML模型优化
规则引擎	特征 + 上下文 + 规则	动作指令（放行/阻断）	动作执行、内容识别阈值
动作执行	动作指令	网络操作 + 日志	审计系统、规则引擎统计

说白了，这三个环节就是DLP策略的“眼睛-大脑-手脚”。加密通道只是让眼睛多了一层雾，但只要你把脱密做在前面，规则引擎写得够细，手脚干净利落，策略就能真正落地。

最后说一句：别把DLP想得太复杂。核心就是这三个东西，搞懂了它们之间的关系，剩下的全是工程细节。而工程细节，后面的章节我会一个个跟你们掰开聊。