企业官网建设流程全解析

简介：深信服终端安全管理系统EDR用户手册是一份面向企业安全管理员、IT运维人员及终端安全初学者的官方技术文档，帮助读者系统掌握EDR的部署流程、日常运维与安全防护逻辑，应对恶意攻击、数据泄露等终端风险。资源包为1个PDF文件，共约98.99MB，内容涵盖产品概述、关键特性、首次上线前的环境准备与部署步骤、产品安装配置、使用指南及安全注意事项等模块，结构完整，适合对照实操。目前已有775人学习，是理解深信服EDR终端安全体系的重要参考。手册对威胁检测、事件响应、资产管理等功能逐一展开，并对危险、警告、注意等安全标识作出明确说明，能够指导用户规范使用系统、规避操作风险，适合企业安全建设与日常终端管理场景。

1. 深信服EDR用户手册应该怎么读：先看运营链路再看菜单

刚接手一套终端安全管理系统时，最容易被那份几百页的深信服终端安全管理系统EDR用户手册带偏节奏：从控制台首页开始一页页翻，翻到中间发现前面的功能还没用上，后面的高级策略又看不懂该不该开。这份手册的核心价值其实不在某个按钮的位置，而在于把「终端检测与响应（EDR）」这件事的组织方式讲清楚了——控制台负责策略与告警，客户端负责采集与执行，中间通过一连串检测引擎和历史基线串起来。对刚接手的运维或安全管理员来说，最合理的读法是先看部署规划、再看策略模块、最后看处置流程，而不是按页数顺序啃。

2. 部署前先搞懂组件逻辑：控制台、客户端与授权边界怎么对应

2.1 角色分工：哪些工作在控制台，哪些工作在客户端

整个系统的分工可以简化成一句话：控制台是大脑，客户端是手脚。控制台负责策略下发、告警汇总、威胁处置、报表呈现和资产管理；客户端负责文件监控、进程行为采集、漏洞与合规检查这类终端本地事件，并把结果发回控制台。两者的通信是长连接心跳模式，心跳丢了，控制台就会显示终端离线。

这份手册里反复出现的几个模块，对应的职责范围大致如下：

理解这个分工有两个直接好处。一是排查问题时能快速定位：如果某台终端的行为数据不显示，优先怀疑客户端采集链路而不是控制台；如果策略改了终端没反应，优先检查策略绑定范围和下发状态。二是部署选型时知道先买什么、后补什么——授权数量对应的是客户端，不是控制台。

2.2 部署形态与网络要求：先想清楚再动手

深信服EDR控制台支持多种部署方式，选型依据是终端规模和网络情况。小规模环境用单机部署，控制台和数据存储在一台服务器上；规模大或者对可靠性有要求的场合，考虑HA（高可用）甚至多级部署。所谓多级部署，就是上级区域放一个总控制台，下级区域各自部署子控制台，子控制台将数据汇总给上级，适合网络分段明确、跨地域带宽有限的场景。

网络要求这块是最容易在实施当天才发现问题的环节。控制台需要放通管理端口和Agent回连端口，终端与控制台之间的心跳流量必须在防火墙策略里明确定位。部署前建议至少确认三条链路：

• 浏览器访问控制台的链路（管理面）
• Agent向控制台回连的链路（数据面）
• 客户端升级病毒库与策略版本的链路（升级面）

我见过不少实施项目把前两条放通了，升级流量没放通，导致客户端装上了，病毒库一直是旧的。手册里的网络规划章节会有端口清单，实际动手前对照公司网络策略逐条勾对，能省掉大量后续排障时间。

提示：如果终端分布在多个网段且之间有严格ACL，最好把各网段到控制台所在网段的策略一次性梳理完，不要等部署到一半再补。

2.3 最小闭环：导入授权、安装客户端、绑定策略

部署的第一步是导入授权。控制台初始化的流程，通常包含设置管理员账号、导入授权文件、修改默认端口这几个动作。授权文件决定了两件事：一是能管理多少终端，二是能使用哪些功能模块。授权导入后，建议先在「终端管理」里建好分组——按部门分、按系统类型分、按网络区域分都可以。分组是后续所有策略绑定的基础，建得合理，策略管理就顺畅；建得随意，后面每改一次策略都要跟终端重新确认归属。

客户端安装有三种常见方式：Web控制台生成安装包手动装、通过域策略推送批量安装、使用离线安装包在无外网环境部署。离线安装包适合内网隔离环境，但病毒库更新也要走离线通道，这一步最容易被忽略。安装时客户端会要求填写控制台地址，地址填错是后续「终端离线」的常见原因之一。

我一般会在正式批量安装前，先拿一台测试机走一遍完整流程：安装客户端 → 控制台看到在线 → 绑定一条基础查杀策略 → 用测试文件验证检测与处置。闭环跑通后再批量推送，批量过程中盯住控制台的「未安装终端」列表，就能看到每一台是安装失败还是未被策略覆盖。

3. 上手后的运营三件事：查杀、主动防御与隔离处置怎么配

3.1 病毒查杀的三个必调参数：扫描类型、资源占用、处置动作

部署完成不代表安全能力生效，真正决定效果的是查杀策略的参数组合。手册里查杀策略通常分为实时防护和定期扫描两类。实时防护负责文件落地、进程启动时的即时检查，主要牺牲一部分终端性能换取快速响应；定期扫描负责兜底，覆盖那些实时防护没碰过的历史文件和压缩包内文件。

这三组参数是我每次配置都反复确认的，因为它们直接决定查杀效果和业务影响：

扫描时段同样值得花心思。办公PC建议放在午休或下班后；数据库服务器、ERP系统这类7x24业务，建议先做资源限制，再做错峰扫描，甚至直接排除掉特定目录。排除目录这件事要克制，只在确认某个目录确实是业务数据且体积巨大、扫描收益低时才用，排除范围越小越好。

定时任务配置时，我习惯把「扫描结果通知」打开，让安全管理员能收到扫描完成通知，而不是每天进控制台翻报告。这属于很小但能显著降低运营负担的设置。

3.2 主动防御与专项防护：哪些策略建议全开，哪些要按业务调

主动防御是EDR区别于传统杀毒软件的核心部分。传统杀毒靠特征库识别已知威胁，EDR在此基础上增加行为检测能力，即使样本从没见过，只要行为模式符合恶意特征——比如进程尝试枚举大量文件、修改引导区、批量加密文件——就能触发拦截。深信服这套产品的主动防御通常包含恶意软件行为检测、脚本行为检测、WebShell检测这些模块。

对大多数企业环境，恶意软件行为检测建议全开，检测到后处置动作选择「隔离」或「终止进程」，这两种动作比「仅记录」可控，比「自动清除」稳妥。WebShell检测建议聚焦在Web服务器目录，并用白名单排除正常业务脚本，否则误报率会干扰运营人员判断。

勒索防护是这几年关注度最高的模块，它会在终端目录里放置诱饵文件，靠监控诱饵文件的被访问行为来判断勒索活动，同时结合文件批量加密行为的特征识别。配置勒索防护时有两点需要提醒：一是备份策略要跟EDR配合，终端本地备份不能替代业务系统的异地备份；二是处理勒索告警时，第一动作是断网隔离，不是立即清除——勒索样本通常带有自删除和反取证逻辑，先保留现场对溯源有价值。

这里要特别说下「违规外联检测」这类策略。很多企业采购EDR时把它当作合规工具在用，要求在检测到终端违规连接外部网络时自动阻断。这类策略在部署时要评估误判风险，尤其是员工使用个人热点、手机USB共享网络等场景，误判会造成「看起来联网正常但业务系统全不通」的诡异故障。遇到这种情况，先看告警类型和证据链，再决定是否调整策略动作，不要为了压制告警数而关闭模块。

3.3 告警分级与终端处置：看到告警后按下哪个按钮

告警处置是手册的另外一个重点区域。控制台会把检测到的威胁按严重程度分级，常见的是严重、高、中、低四档。运营人员拿到告警后最核心的任务是回答两个问题：这个告警是误报还是真实威胁？如果是真实威胁，应该隔离还是清除？

建议的处置链路是这样：先看威胁详情页里的文件路径、文件哈希、行为链，再判断终端角色和业务影响。办公终端上发现恶意软件，按隔离处理，同时检查同网段范围内是否还有其它终端存在相同哈希；服务器上发现WebShell，优先确认web目录下的文件变更时间线，把最近变更的脚本文件一并排查。

隔离操作分文件隔离和终端隔离两种。文件隔离只把恶意文件移入隔离区，不影响终端使用；终端隔离则是把整台终端从网络中隔离出来，阻断横向移动，但保留与控制台的通信。判断依据很简单：如果告警只涉及单个文件且行为链清晰，文件隔离就够；如果已经观察到大面积文件操作或横向探测行为，直接做终端隔离。

处置中心有一个容易被低估的功能：批量处置。当同一哈希值在大量终端被检出时，一条批量隔离命令远比一台一台操作高效。这也是为什么我建议在告警详情页先看「受影响终端数」再决定处置粒度。

4. EDR落地避坑指南：离线、误报、资源占用的五个排查路径

4.1 终端装了客户端，控制台却一直显示离线

现象：客户端安装过程无报错，进程也在运行，但控制台终端列表里状态始终是灰色离线。

原因：最常见的是网络链路问题，其次是客户端配置的控制台地址不可达。安装包里的控制台地址一旦填错，客户端会反复尝试建立心跳连接直到超时。部分环境里，还有安全软件把Agent程序进程当作可疑程序杀掉的情况，也会导致心跳中断。

解决：先确认Agent进程存活，再检查回连地址。Linux终端可以用这条命令确认进程状态：

# 查看EDR相关进程是否在运行，进程名以实际安装版本为准 ps aux | grep -i edr-agent # 确认端口监听状态是否正常，替换成实际服务端口 ss -ant | grep <端口号>

如果进程不在，优先查看系统服务状态，并确认启动项是否被其它安全软件禁用；如果进程在但心跳不通，在终端上用telnet确认到控制台对应端口的连通性，再沿着防火墙和ACL逐层排查。这类问题实战中六成是网络策略，三成是地址配置错误，一成才是程序本身异常。

4.2 全盘扫描把业务服务器扫到卡顿甚至宕机

现象：配置了全盘扫描后，业务系统反馈响应变慢，CPU或磁盘IO长期处于高位，严重时服务直接不可用。

原因：扫描策略使用了默认的高性能模式，没有开启资源限制，也没有设置业务静默时段。服务器上的杀毒扫描对IO的消耗比对CPU更明显，尤其是数据库、文件服务器这类随机读写密集型的业务。

解决：停掉当前扫描任务，修改策略——开启资源限制，把CPU占用阈值调到业务可以承受的范围，同时开启IO限制；将扫描时段调整到业务低谷期，数据库服务器推荐用增量扫描而不是周期全盘扫描；对明确不需要扫描的目录做排除。修改完成后先在测试机上观察一轮完整扫描的资源曲线，确认峰值可控再应用到生产分组。

等一个完整扫描周期跑完，去控制台看扫描结果报表，确认没有因为资源限制导致大量文件漏检。这个平衡点需要根据业务类型多试几次，没有一套参数能适配所有环境。

4.3 检测引擎把公司内部开发工具隔离了

现象：运维反馈某台终端的内部编译工具或脚本被隔离，业务无法正常运行。控制台告警显示该文件的检测原因是「风险工具」或「PUA软件」。

原因：这是典型的误报场景。EDR的检测引擎除了特征库，还有启发式分类机制，开发工具常常因为具备敏感行为（比如修改进程内存、加载驱动、执行命令行）被判为可疑。

解决：先到隔离区找到对应文件，确认文件来源和签名信息，确认是内部可信文件后执行恢复操作。恢复后将该文件或目录加入信任区，并补充填写信任理由和业务归属人。这里有一个关键细节：信任区策略要绑定到正确的分组，别把个人PC和业务服务器放在同一个策略里，否则信任范围会被放大。处理完毕后，把该文件上传给厂商分析团队复核，减少后续同类误报。

误报处置的原则是：恢复动作要快，分析要慢。恢复优先保障业务，分析是为了避免下次再踩同一个坑。

4.4 威胁处置完又出现，像是杀不干净

现象：终端已经执行了清除或隔离操作，过一段时间同一路径、同一哈希的威胁又出现，甚至告警数量不减反增。

原因：病毒母体通常不在单独的可执行文件里，而是写入计划任务、服务项、注册表启动项或其它持久化位置。简单清除掉落地文件，母体在下一次触发时又会重新释放。办公终端的U盘、网络共享目录也可能成为反复感染的来源。

解决：处置动作从「隔离文件」调整为「清除并修复」这类带持久化清理能力的动作（不同版本名称略有差异），它会额外检查计划任务、启动项和服务注册。清理完成后马上安排一次全盘快速扫描，确认没有残留。如果仍然反复，把终端隔离出网络，进入安全模式手工排查计划任务和最近新增服务，同时在整个终端列表里搜索同一文件哈希，检查是否是全网范围内的传播。

4.5 策略改了，但客户端就是按旧策略执行

现象：修改了查杀策略参数，或者新增了一条白名单规则，控制台显示已下发，但终端行为没有变化，告警依旧产生。

原因：策略生效需要完成「保存-下发-客户端本地刷新」三个环节。常见漏掉的是保存后没有点「立即下发」，或者只保存到了策略草稿；还有终端本地策略版本没有刷新，客户端仍然沿用缓存的旧策略。

解决：在控制台策略编辑页面确认保存后自动下发已触发，然后到终端管理找到目标终端检查其「策略版本号」是否已更新。如果策略版本号没变，手动在终端右键下发策略或让客户端执行一次策略更新。下面这条命令用于Linux环境主动触发客户端策略拉取：

# 在终端上手动触发一次策略重新获取（具体命令以实际安装为准，常见有update/pull参数） systemctl restart <edr-agent服务名>

重启用不了的情况下，也有客户端目录下的命令行工具支持手动同步，具体路径看对应版本的卸载与升级说明。

注意：改策略的时候留意策略优先级。很多EDR支持多策略叠加，并配置优先级顺序，被更高优先级策略覆盖的低优先级策略即使内容改了也不会生效。遇到策略不生效，先看目标终端到底命中了哪条策略。

5. 让EDR从「装了」进化到「有效」：验证链路、日志留痕与运营节奏

5.1 验证不是装完就结束：跑一遍闭环测试

客户端全部上线后，我建议做一次有效性验证，而不是直接信任控制台的「在线率100%」。验证方式很简单：用测试工具的已知威胁样本或无害的验证文件，放到办公终端和服务器上，确认实时防护能否在文件落地或执行时触发告警；再确认这条告警是否在控制台正确展示，处置动作能否完整执行。如果某些终端在线却检测不到，多半是实时防护关闭、策略绑定缺失或客户端版本过旧。

这一步的价值在于把「装了」和「有效」区分开。在线率只说明客户端活着，不说明安全能力可用。

5.2 日志留痕：给事后溯源留足材料

EDR运营里最容易忽略的是告警与处置日志的留存。控制台的告警记录通常有保存时限，建议按周或按月导出告警清单和处置记录归档保存。企业安全运营里，很多问题不是当场发现，而是业务异常发生后回溯排查时才发现需要翻历史记录。日常留档能让你在需要复盘时有据可查。

导出的内容至少包含：告警时间、终端信息、文件路径、文件哈希、检测类型、处置人和处置动作。这个习惯我保持了几年，帮我在多次事件排查里快速还原了时间线。

5.3 运营节奏：把EDR变成例行事务

EDR不是部署完就结束的静态系统，它需要持续的运营节奏来保持效果。我一般会按日、周、月三个周期安排固定工作。

这些事务性工作听起来枯燥，但真正让EDR体系稳定的恰恰是这些例行操作。系统上线期的新鲜感过去后，坚持这个节奏的团队，在威胁真正出现时大多能快速响应而不是临时翻手册。

我自己在早期运维里吃过最大的亏，是过度信任控制台的自动化能力，忽视了策略变更和告警闭环这类人为环节。现在每次改策略、每次处置告警，我都会顺手把操作记录和截图归档到运营台账里——这个习惯帮我攒下了大量可复用的处置经验。最后补一句：这套EDR的价值上限取决于有没有人把它当成一件需要持续投入的事来做，而不是装完就不管了。希望帮到你。

本文还有配套的精品资源，点击获取