做终端安全产品的同行经常会被问你们的客户端是不是就装个服务、定时上报数据——还真不是。一个能在生产环境稳定跑几年的终端安全 Agent要跨 Windows 7 到 11、要和老业务软件共存、要扛住对抗卸载、要把 CPU 占用压到用户无感工程上的坑远比想象中多。这篇文章把这些年趟过的路整理一遍权当抛砖引玉。1. 为什么终端安全绕不开 AgentC/S 架构是终端安全的必然选择管控策略要从平台下发到几千台分散的终端终端上的资产、行为、安全事件数据要持续回传这中间必须有一个驻留进程作为神经末梢。但 Agent 的处境很尴尬它运行在别人地盘上用户和恶意软件都想干掉它它要保证业务无感HIS、ERP 这些老系统崩了算它的它要长期稳定装上去三年不能成为新的故障源。所以 Agent 的设计目标可以概括为一句话高内聚、低耦合、可自证——自身模块化不互相拖累对外部环境侵入最小且能证明自己还活着、没被篡改。2. 总体架构一个进程但内部分层生产级的 Agent 一般采用系统服务 用户态组件 一组可选内核驱动的结构winlogon / 用户登录 │ ┌─────┴──────────────────────────────┐ │ 用户态 │ │ ┌────────────┐ ┌───────────────┐ │ │ │ UI 组件 │ │ 策略引擎 │ │ │ └────────────┘ └───────────────┘ │ │ ┌────────────────────────────────┐ │ │ │ 核心服务进程 modules 插件化 │ │ │ │ 资产管理 │ 补丁 │ 外设 │ 审计 │ │ │ └────────────────────────────────┘ │ │ ┌────────────┐ ┌───────────────┐ │ │ │ 通信模块 │ │ 自我保护模块 │ │ │ └────────────┘ └───────────────┘ │ └─────┬──────────────────────────────┘ │ FltMgr / WDM / Callbacks ┌─────┴──────────────────────────────┐ │ 内核层 │ │ minifilter文件加密/防勒索审计 │ │ USB 过滤驱动外设管控 │ │ 进程/注册表回调自我保护 │ └────────────────────────────────────┘几个关键决策单进程多模块而不是多进程。所有管控能力作为模块加载进同一个服务进程共享配置与状态。模块间用消息总线通信一个模块崩溃可以隔离重启但不会拖死整机。这比每个功能一个 exe的方案在资源占用和状态一致性上强太多。用户态与内核态职责严格划分。内核驱动只做不得不做的事文件加解密判定、外设拦截、进程保护。所有策略解析、日志聚合、网络通信都在用户态——驱动里出 bug 是蓝屏用户态出 bug 顶多重启服务这个边界一定要守住。策略本地化缓存。平台下发的策略在终端落盘缓存平台断连时 Agent 按最近一次策略继续执行而不是失联即失控。恢复连接后增量同步策略版本。3. 通信层稳字当头通信模块负责和平台维持长连接、接收指令、上报数据。生产环境的要求很朴素不能丢、不能重、不能撑爆带宽。实践中的几个要点心跳与指令分通道心跳保活用轻量包指令与文件分发走独立队列本地持久化队列上报数据先写本地SQLite 或自定义文件队列发送成功再删除——进程崩溃、断网重启都不丢数据增量与压缩资产、补丁这类大对象只传差异策略文件走压缩断点续传补丁包、Agent 升级包按分块下载失败重传只补缺失块升级自保Agent 自升级先下载到临时目录校验签名再通过服务启动脚本切换失败自动回滚到旧版本。升级逻辑是 Agent 最危险的操作必须做成原子的。4. 管控层几个内核模块的实现要点4.1 文件透明加密minifilter基于 FltMgr 的微过滤驱动挂在文件系统栈上在读写路径上判定进程是否授信// 简化示意PreRead 判定 FLT_PREOP_CALLBACK_STATUS PreRead(...) { if (!IsTrustedProcess(Data-Iopb-TargetFp)) { // 非授信进程返回密文由应用自行处理 } return FLT_PREOP_SUCCESS_WITH_CALLBACK; }工程上的坑主要不在原理而在性能加解密必须在内核里做零拷贝优化敏感目录如系统盘、业务缓存目录要配排除清单否则老机器上打开大文件肉眼可见地卡白名单粒度按路径签名进程哈希三要素判定防止有人改名伪装。白名单必须最小化只放行真实业务进程——这是透明加密方案最大的实际风险点兼容矩阵内存映射文件、某些 CAD/医学影像软件的非常规 IO 方式会绕过常规拦截路径要靠灰度测试积累兼容清单。4.2 外设管控USB 过滤驱动在 USB 存储设备的设备栈上注册 UpperFilter在设备打开和写入路径做判定。要点授权标识用设备实例 ID 硬件序列号卷标是可以随便改的信不得权限分三档禁用 / 只读 / 读写只读在写入路径直接拒绝 IRP审计要做到文件级哪个序列号的盘、哪个账号、读了写了哪些文件。4.3 自我保护这是 Agent 的防弹衣常用组合ObRegisterCallbacks注册句柄回调拒绝非白名单进程打开关键进程句柄内核态拦截对关键服务的删除/停止请求卸载入口校验平台签发的离线授权码管理员没授权本地卸载不了驱动文件本身加校验防止被替换。对抗再往上是 BYOVD加载有漏洞的签名驱动来终止防护进程——防护方要维护已知漏洞驱动黑名单在加载阶段就拦截。这是一场持续对抗没有终点。4.4 截屏管控别只 Hook 一个 PrintScreen截屏通道之多超乎想象系统PrintScreen、WinShiftS 截图工具、第三方截图软件、远程桌面协议本身……只处理系统 API 等于裸奔。务实的做法是逐通道封堵 屏幕水印兜底水印带上姓名工号时间物理拍照通道防不住但能做到必可溯源。5. 策略引擎设备 × 用户二维求值传统策略只管设备但一机多人场景医院窗口、客服工位下审计必须定到人。策略引擎要做成二维矩阵有效策略 f(设备组策略, 用户组策略, 登录上下文)登录时向 AD/LDAP 或本地账户体系确认身份按设备组 × 用户组计算策略集动态加载。审计日志同时打上终端与账号双标签——这个设计改动很小但让追责到人从口号变成查询语句。6. 兼容性真正的深水区功能都能实现难的是在客户现场活着。几个血泪经验PatchGuard 红线64 位 Windows 禁止内核钩取系统调用任何绕 PatchGuard 的方案都是在给客户埋雷——未来某次更新蓝屏给你看。所有 hook 都走微软官方机制minifilter、回调注册这是底线与杀软共存卡巴、赛门铁克这些厂商的驱动栈和你挤在同一条路径上加载顺序、Altitude 值要精心规划Altitud e 冲突是老司机才知道的坑灰度发布纪律任何驱动级变更先 5% 终端灰度观察两周再全量。一次心急的全量推送可能换来几百台蓝屏性能预算量化常态 CPU 3%、内存 200MB 是用户容忍线写代码时这个预算要分配给每个模块超限就要砍功能而不是硬上Dump 分析能力必备现场蓝屏不可能复现windbg 客户 minidump 是唯一的调试手段驱动的每处内存访问都要经得起静态检查。7. 看一个成熟产品怎么做上面这些模块如果各自为战就是防病毒一个 Agent、加密一个 Agent、审计一个 Agent的拼盘——资源占用叠加、状态互相矛盾、冲突难排查。成熟的做法是收拢一套 Agent、一个数据底座、一个控制台。以迪康端点安全一体化管理系统为例它的客户端把资产采集、补丁、外设管控、透明加密、屏幕水印、行为审计做成同一进程内的模块共享同一套策略引擎与审计通道平台侧统一做策略分发、审批流和日志检索。这样做的好处是工程上可预期的Agent 只有一份性能预算审计数据天然同源查一台机器上某个人在某个时间做了什么是一条查询而不是一次跨系统考古。对想自研或选型的人来说这个对照价值在于评估终端安全方案时先问 Agent 有几个、数据底座有几个比先问功能清单实在得多。8. 总结终端安全 Agent 是个看起来简单、做起来要命的工种内核驱动决定能力上限工程细节决定生存下限。几个可带走的结论内核只做不得不在内核做的事其余全部用户态所有高危操作升级、卸载、策略变更走授权与审计兼容性矩阵和灰度纪律和写代码同等重要一体化不是功能堆叠而是共享 Agent 与数据底座的架构选择。如果你在终端安全方向有实践或不同见解欢迎留言讨论。 
长河君 · 2026/10/14 19:12:51 · 阅读 1.2k 迪康终端安全管理 Agent 的设计与实现：架构、驱动与踩坑实录
做终端安全产品的同行经常会被问你们的客户端是不是就装个服务、定时上报数据——还真不是。一个能在生产环境稳定跑几年的终端安全 Agent要跨 Windows 7 到 11、要和老业务软件共存、要扛住对抗卸载、要把 CPU 占用压到用户无感工程上的坑远比想象中多。这篇文章把这些年趟过的路整理一遍权当抛砖引玉。1. 为什么终端安全绕不开 AgentC/S 架构是终端安全的必然选择管控策略要从平台下发到几千台分散的终端终端上的资产、行为、安全事件数据要持续回传这中间必须有一个驻留进程作为神经末梢。但 Agent 的处境很尴尬它运行在别人地盘上用户和恶意软件都想干掉它它要保证业务无感HIS、ERP 这些老系统崩了算它的它要长期稳定装上去三年不能成为新的故障源。所以 Agent 的设计目标可以概括为一句话高内聚、低耦合、可自证——自身模块化不互相拖累对外部环境侵入最小且能证明自己还活着、没被篡改。2. 总体架构一个进程但内部分层生产级的 Agent 一般采用系统服务 用户态组件 一组可选内核驱动的结构winlogon / 用户登录 │ ┌─────┴──────────────────────────────┐ │ 用户态 │ │ ┌────────────┐ ┌───────────────┐ │ │ │ UI 组件 │ │ 策略引擎 │ │ │ └────────────┘ └───────────────┘ │ │ ┌────────────────────────────────┐ │ │ │ 核心服务进程 modules 插件化 │ │ │ │ 资产管理 │ 补丁 │ 外设 │ 审计 │ │ │ └────────────────────────────────┘ │ │ ┌────────────┐ ┌───────────────┐ │ │ │ 通信模块 │ │ 自我保护模块 │ │ │ └────────────┘ └───────────────┘ │ └─────┬──────────────────────────────┘ │ FltMgr / WDM / Callbacks ┌─────┴──────────────────────────────┐ │ 内核层 │ │ minifilter文件加密/防勒索审计 │ │ USB 过滤驱动外设管控 │ │ 进程/注册表回调自我保护 │ └────────────────────────────────────┘几个关键决策单进程多模块而不是多进程。所有管控能力作为模块加载进同一个服务进程共享配置与状态。模块间用消息总线通信一个模块崩溃可以隔离重启但不会拖死整机。这比每个功能一个 exe的方案在资源占用和状态一致性上强太多。用户态与内核态职责严格划分。内核驱动只做不得不做的事文件加解密判定、外设拦截、进程保护。所有策略解析、日志聚合、网络通信都在用户态——驱动里出 bug 是蓝屏用户态出 bug 顶多重启服务这个边界一定要守住。策略本地化缓存。平台下发的策略在终端落盘缓存平台断连时 Agent 按最近一次策略继续执行而不是失联即失控。恢复连接后增量同步策略版本。3. 通信层稳字当头通信模块负责和平台维持长连接、接收指令、上报数据。生产环境的要求很朴素不能丢、不能重、不能撑爆带宽。实践中的几个要点心跳与指令分通道心跳保活用轻量包指令与文件分发走独立队列本地持久化队列上报数据先写本地SQLite 或自定义文件队列发送成功再删除——进程崩溃、断网重启都不丢数据增量与压缩资产、补丁这类大对象只传差异策略文件走压缩断点续传补丁包、Agent 升级包按分块下载失败重传只补缺失块升级自保Agent 自升级先下载到临时目录校验签名再通过服务启动脚本切换失败自动回滚到旧版本。升级逻辑是 Agent 最危险的操作必须做成原子的。4. 管控层几个内核模块的实现要点4.1 文件透明加密minifilter基于 FltMgr 的微过滤驱动挂在文件系统栈上在读写路径上判定进程是否授信// 简化示意PreRead 判定 FLT_PREOP_CALLBACK_STATUS PreRead(...) { if (!IsTrustedProcess(Data-Iopb-TargetFp)) { // 非授信进程返回密文由应用自行处理 } return FLT_PREOP_SUCCESS_WITH_CALLBACK; }工程上的坑主要不在原理而在性能加解密必须在内核里做零拷贝优化敏感目录如系统盘、业务缓存目录要配排除清单否则老机器上打开大文件肉眼可见地卡白名单粒度按路径签名进程哈希三要素判定防止有人改名伪装。白名单必须最小化只放行真实业务进程——这是透明加密方案最大的实际风险点兼容矩阵内存映射文件、某些 CAD/医学影像软件的非常规 IO 方式会绕过常规拦截路径要靠灰度测试积累兼容清单。4.2 外设管控USB 过滤驱动在 USB 存储设备的设备栈上注册 UpperFilter在设备打开和写入路径做判定。要点授权标识用设备实例 ID 硬件序列号卷标是可以随便改的信不得权限分三档禁用 / 只读 / 读写只读在写入路径直接拒绝 IRP审计要做到文件级哪个序列号的盘、哪个账号、读了写了哪些文件。4.3 自我保护这是 Agent 的防弹衣常用组合ObRegisterCallbacks注册句柄回调拒绝非白名单进程打开关键进程句柄内核态拦截对关键服务的删除/停止请求卸载入口校验平台签发的离线授权码管理员没授权本地卸载不了驱动文件本身加校验防止被替换。对抗再往上是 BYOVD加载有漏洞的签名驱动来终止防护进程——防护方要维护已知漏洞驱动黑名单在加载阶段就拦截。这是一场持续对抗没有终点。4.4 截屏管控别只 Hook 一个 PrintScreen截屏通道之多超乎想象系统PrintScreen、WinShiftS 截图工具、第三方截图软件、远程桌面协议本身……只处理系统 API 等于裸奔。务实的做法是逐通道封堵 屏幕水印兜底水印带上姓名工号时间物理拍照通道防不住但能做到必可溯源。5. 策略引擎设备 × 用户二维求值传统策略只管设备但一机多人场景医院窗口、客服工位下审计必须定到人。策略引擎要做成二维矩阵有效策略 f(设备组策略, 用户组策略, 登录上下文)登录时向 AD/LDAP 或本地账户体系确认身份按设备组 × 用户组计算策略集动态加载。审计日志同时打上终端与账号双标签——这个设计改动很小但让追责到人从口号变成查询语句。6. 兼容性真正的深水区功能都能实现难的是在客户现场活着。几个血泪经验PatchGuard 红线64 位 Windows 禁止内核钩取系统调用任何绕 PatchGuard 的方案都是在给客户埋雷——未来某次更新蓝屏给你看。所有 hook 都走微软官方机制minifilter、回调注册这是底线与杀软共存卡巴、赛门铁克这些厂商的驱动栈和你挤在同一条路径上加载顺序、Altitude 值要精心规划Altitud e 冲突是老司机才知道的坑灰度发布纪律任何驱动级变更先 5% 终端灰度观察两周再全量。一次心急的全量推送可能换来几百台蓝屏性能预算量化常态 CPU 3%、内存 200MB 是用户容忍线写代码时这个预算要分配给每个模块超限就要砍功能而不是硬上Dump 分析能力必备现场蓝屏不可能复现windbg 客户 minidump 是唯一的调试手段驱动的每处内存访问都要经得起静态检查。7. 看一个成熟产品怎么做上面这些模块如果各自为战就是防病毒一个 Agent、加密一个 Agent、审计一个 Agent的拼盘——资源占用叠加、状态互相矛盾、冲突难排查。成熟的做法是收拢一套 Agent、一个数据底座、一个控制台。以迪康端点安全一体化管理系统为例它的客户端把资产采集、补丁、外设管控、透明加密、屏幕水印、行为审计做成同一进程内的模块共享同一套策略引擎与审计通道平台侧统一做策略分发、审批流和日志检索。这样做的好处是工程上可预期的Agent 只有一份性能预算审计数据天然同源查一台机器上某个人在某个时间做了什么是一条查询而不是一次跨系统考古。对想自研或选型的人来说这个对照价值在于评估终端安全方案时先问 Agent 有几个、数据底座有几个比先问功能清单实在得多。8. 总结终端安全 Agent 是个看起来简单、做起来要命的工种内核驱动决定能力上限工程细节决定生存下限。几个可带走的结论内核只做不得不在内核做的事其余全部用户态所有高危操作升级、卸载、策略变更走授权与审计兼容性矩阵和灰度纪律和写代码同等重要一体化不是功能堆叠而是共享 Agent 与数据底座的架构选择。如果你在终端安全方向有实践或不同见解欢迎留言讨论。