2、EDR架构设计：Agent架构、云端架构、混合架构

聊EDR架构之前，我先说个真实经历。几年前我参与一个金融客户的EDR选型，对方安全负责人上来就问：“你们是Agent架构还是云端架构？”我当时一愣——这问题其实没那么简单。后来我花了整整两周，帮他们梳理了三种主流架构的优劣，才把方案定下来。

今天我就把这三种架构掰开揉碎了讲给你听。你想想看，架构选错了，后面所有功能设计都是白搭。

2.1 Agent架构：终端上的哨兵

Agent架构，说白了就是在每台终端上装一个“小哨兵”。它独立运行，不依赖云端。我最早接触EDR时，用的就是纯Agent架构。

2.1.1 数据采集层

Agent的数据采集，我习惯把它分成三个维度：

• 进程维度：创建、终止、注入、句柄操作
• 文件维度：创建、删除、修改、重命名
• 网络维度：连接建立、DNS请求、HTTP流量

嗯，这里要注意。采集不是越多越好。我在项目中遇到过，有个客户把所有API调用都hook了，结果终端CPU直接飙到80%。后来我们只保留了关键事件，性能才降下来。

2.1.2 本地分析引擎

Agent本地跑分析引擎，常见的有两种：

引擎类型	原理	我踩过的坑
规则引擎	基于YARA、Sigma规则匹配	规则太多，内存占用高
行为分析引擎	基于进程行为图谱	误报率偏高，需要调参

我个人习惯，在Agent上只放轻量级规则。复杂分析交给云端。为什么？因为终端资源有限，你想想看，一个办公电脑上跑着Office、浏览器、VPN，再塞个重型分析引擎，用户不骂你才怪。

2.1.3 本地响应能力

Agent架构最大的优势，就是响应快。我记得有一次，客户内网断网了，但勒索病毒还在传播。纯Agent架构的EDR照样能杀进程、隔离文件。这就是本地响应的价值。

2.2 云端架构：大脑在云上

云端架构，就是终端只负责采集，分析全在云端。现在很多SaaS EDR都走这条路。

2.2.1 数据上传策略

数据怎么上传？这是个大学问。我曾经见过一个产品，把所有事件实时上传，结果带宽被吃光。后来我们改成了这样：

// 伪代码：数据上传策略
if (事件优先级 == 高) {
    立即上传
} else if (事件优先级 == 中) {
    缓存5秒，批量上传
} else {
    缓存30秒，压缩后上传
}

为什么要这么做？因为高优先级事件（比如进程注入）需要实时分析。而低优先级事件（比如文件创建），晚几秒处理完全没问题。

2.2.2 云端分析能力

云端能做的事情，比Agent多太多了：

• 关联分析：把上千台终端的事件串起来
• 机器学习：训练异常检测模型
• 威胁情报：实时匹配IOC
• 历史回溯：保存90天甚至更久的数据

说白了，云端架构就是“用算力换能力”。你想想看，Agent上跑个深度学习模型？不现实。但在云端，GPU集群随便跑。

2.3 混合架构：取长补短

混合架构，是我个人最推荐的方式。它把Agent和云端的优势结合起来。

2.3.1 分层处理逻辑

混合架构的处理逻辑，我习惯画成三层：

你看这个图，三层架构各司其职。Agent处理紧急事件，边缘节点做区域关联，云端做深度分析。我曾经在项目中这样设计，效果非常好。

2.3.2 数据分流策略

混合架构里，数据怎么分流？我总结了一个口诀：

• 紧急事件：本地处理，不上传
• 可疑事件：上传云端，同时本地缓存
• 普通事件：压缩后批量上传
• 低价值事件：丢弃或只保留摘要

2.3.3 离线模式设计

混合架构必须考虑离线场景。我的做法是：

// 离线模式逻辑
if (网络连通) {
    正常上传数据
} else {
    启用本地缓存队列
    本地规则升级为“严格模式”
    网络恢复后，批量同步
}

为什么要升级为严格模式？因为离线时云端帮不上忙，Agent必须自己扛。严格模式会降低误报容忍度，宁可错杀，不可放过。

2.4 三种架构对比

最后，我做个对比表格，方便你选型时参考：

维度	Agent架构	云端架构	混合架构
部署复杂度	低	中	高
响应速度	快（毫秒级）	慢（依赖网络）	快（本地+云端）
分析深度	浅	深	最深
资源消耗	中	低（终端）	中
离线能力	强	无	强
运维成本	高（每台都要管）	低	中

嗯，选型没有银弹。我个人习惯，先看客户网络环境，再看安全团队能力，最后看预算。三者平衡，才能选出最合适的架构。