第4章：DLP接口定义与分类——检测、策略、告警

老哥们，咱们聊了这么久的多活架构，终于要动真格的了。DLP这东西，说白了三件事：你能看到什么（检测），你打算怎么办（策略），出了事怎么喊人（告警）。

这三件事，在异地多活架构下，接口设计上稍不留神，就会把整个系统搞崩。我记得几年前有个项目，就是因为告警接口没做去重设计，结果一个事件在三个数据中心同时触发，运维同学的手机直接被打爆了——短信费都比服务器租金贵了。

这一章，咱们就掰开揉碎了讲清楚这三个接口各自是干嘛的，怎么设计才靠谱。

4.1 检测接口：数据采集的入口

检测接口，也叫数据采集接口。它负责把网络流量、文件、邮件、终端行为这些原始数据，送进DLP引擎去做分析。

你想想看，异地多活场景下，每个数据中心都有可能产生需要检测的数据。如果每个点都往一个中心节点发数据，那网络带宽一下就炸了。所以，检测接口的设计，核心就两个字——就近。

具体的接口形式，我归纳了几种常见的：

• 流量镜像接口：旁路部署，通过交换机的端口镜像将流量引入DLP设备。接口通常是标准的pcap格式，或者NetFlow/IPFIX的流数据。
• 文件上传接口：业务系统通过REST API或文件共享协议（如SMB、NFS）将文件提交给DLP。这个接口一般用HTTPS POST，返回JSON。
• SMTP/IMAP代理接口：邮件服务器将邮件转发到DLP过滤，再决定放行或拦截。接口要兼容SMTP协议扩展。
• API拦截接口：微服务架构下，通过Agent或Sidecar捕获HTTP/RPC请求体，发送到DLP引擎。

拿文件上传接口举个例子，核心数据模型一般长这样：

{
  "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "sourceRegion": "cn-beijing",
  "tenantId": "tenant_001",
  "fileName": "合同草案_v3.docx",
  "fileHash": "sha256:...",
  "fileSize": 2048576,
  "content": "base64编码的内容或文件URL",
  "context": {
    "user": "张三",
    "department": "法务部",
    "appId": "oa_system"
  }
}

注意看，我刻意把sourceRegion和tenantId放在了顶层。为什么？因为这是多活架构下做数据分片和路由的关键字段。没有它，你后续的策略匹配和告警归属都会乱套。

4.2 策略接口：决策下发的通道

检测数据进来之后，DLP引擎要根据规则做出判断。这个规则谁来管？就是策略接口。说白了，它负责把安全管理员配好的策略，从管理端同步到各个数据中心的执行引擎上。

异地多活架构下，策略接口最怕什么？怕不一致。北京新加了一条“禁止外发源代码”的策略，上海那边可能因为网络延迟或者接口没调通，还用的是旧策略。结果用户从上海发走一份代码，系统没拦住，背锅的还是我们。

所以，策略接口的设计要点是：

1. 全量+增量同步：启动时拉全量，运行时只推送变更的增量。
2. 版本号机制：每条策略带一个单调递增的版本号。执行引擎本地缓存策略版本号，每次请求都带上版本号去策略服务校验。版本号不一致，就触发重新拉取。
3. 消息队列广播：策略变更时，通过MQ广播到所有数据中心的策略服务节点，保证“发布-订阅”逻辑。

策略的配置结构，我习惯用这样的层次：

层级	包含字段	说明
策略组	groupId, groupName, priority	一组相关规则的集合，比如“研发数据保护组”
规则	ruleId, ruleName, expressions (and/or), actions	具体的检测逻辑，比如“内容匹配关键词'机密'且发送到外部邮箱”
动作	actionType (block/warn/log/review), riskLevel	命中规则后的处理方式

接口示例，更新一条规则的REST调用：

PUT /api/v2/policies/rules
{
  "ruleId": "rule_10086",
  "ruleName": "检测外部邮件含敏感词",
  "enabled": true,
  "version": 42,
  "expressions": [
    {"field": "messageType", "op": "eq", "value": "SMTP"},
    {"field": "toDomain", "op": "notIn", "value": ["company.com"]},
    {"field": "contentMatch", "op": "regex", "value": "(机密|绝密|商业秘密)"}
  ],
  "actions": [
    {"type": "block", "riskLevel": "high"},
    {"type": "notify", "role": "security_admin"}
  ],
  "effectiveRegions": ["cn-beijing", "cn-shanghai", "us-west-2"]
}

4.3 告警接口：事件的出口

检测、判断都做完了，如果真发现了违规行为，接下来就是告警接口的活儿了。它负责把安全事件推送到SOC平台、SIEM系统或者直接通知到人。

异地多活下，告警接口最大的陷阱就是告警风暴。同一个恶意文件，可能在北京、上海、硅谷三个数据中心都被检测到了。如果不做合并，你会收到三条几乎一模一样的告警，但就是这“几乎一样”最坑人——因为时间戳不同、来源区域不同，运维同学会以为是三个不同的攻击。

我的建议是，告警接口要干三件事：

• 归一化：所有数据中心的告警统一到一个标准格式。
• 去重：基于文件HASH、用户ID、策略ID的组合做一次全局去重。只有真正新的违规事件才发告警。
• 聚合：短时间内的同类告警，合并成一条聚合告警，附带数量和时间窗口。

告警接口的数据模型：

POST /api/v2/alerts
{
  "alertId": "alert_20231001_001",
  "summary": "用户张三尝试外发含敏感词的邮件",
  "severity": "critical",
  "detectedAt": "2024-01-15T10:30:00Z",
  "sourceRegion": "cn-beijing",
  "dedupKey": "sha256_hash+user_id+rule_id",
  "eventCount": 1,
  "rawEventIds": ["evt_001"],
  "mitigationRef": "rule_10086_action_01"
}

4.4 三者的关系与部署要点

检测、策略、告警，这三条接口不是孤立的。它们组成了DLP的数据流闭环。我画了张图，帮你直观理解它们怎么配合。

你看看这张图就明白了。数据从左到右：先过检测接口，到DLP引擎；引擎从策略接口拿到规则库；做出判断后，通过告警接口把结果发给下游。

部署的时候，我强调三个要点：

1. 每条接口都要做到无状态。这样任何数据中心挂了，别的中心可以无缝接管。
2. 接口的超时和熔断必须独立配置。检测接口可以容忍稍高的延迟（比如10秒），但告警接口必须秒级响应，否则会阻塞事件处理流水线。
3. 全链路带上TraceId。从检测接口进来的请求，一路带上TraceId直到告警接口。出了线上问题，你才能快速定位到底是哪一步挂了。