简介《奇安信天擎终端安全管理系统管理员手册》是一份面向终端安全管理员与IT运维人员的官方配套资料旨在帮助读者系统掌握奇安信天擎V10.0的产品架构、核心能力与部署方法解决终端设备及数据面临的安全管理问题。整本手册由1个PDF文件组成压缩包大小约23.07MB体积适中方便下载后离线查阅。目前已有3884人学习适合需要在实际环境中完成终端安全规划、策略配置与运维排查的读者。内容方面这份400页的手册按章节组织开篇介绍产品定位与主要功能涵盖终端安全管理、恶意代码检测、网络攻击防护、数据加密、身份验证等模块随后详解互联网络、隔离网络、多级级联、高级版EDR四类典型部署场景并区分单机与集群部署形态后续还包含更新管理等运维主题。读者可据此快速理解各功能模块的作用并结合自身网络条件选择合理的部署方案为日常终端安全管理提供直接参考。1. 终端安全管理系统到底是干什么的先想清楚再动手接手一个上千台终端的网络时最头疼的不是某台机器中毒而是你根本说不清全网的安全状态哪些机器没装防护、哪些补丁漏了三个月、谁偷偷插过 U 盘。终端安全管理系统就是解决这个问题的一台控制台管所有终端策略统一下发状态集中可见查杀、补丁、外设管控、日志审计都在同一个界面完成。这份系统管理员手册同行们往往只当功能说明书翻但真正决定项目实施成败的是部署架构怎么选、策略参数怎么调、客户端怎么推、出问题时往哪查。这篇笔记就按这个顺序拆一遍新手能照着落地老手能对口自己踩过的坑。下文以一套典型的商用终端安全管理系统为例统一简称「安枢」。它的基本形态是控制台加客户端两级控制台装在服务器上管理员配策略、看告警客户端装在每台终端上执行查杀、上报事件、接收策略。整套体系的难点从来不是安装而是策略配置和覆盖率——客户端装不上去、策略推不下去、误杀把业务搞挂这些才是管理员手册字里行间藏着的真实工作。2. 部署与架构规划控制台、中继、资源盘动手前先算清三笔账2.1 两级与三级架构什么时候必须上中继节点安枢的典型部署形态是控制台加客户端两级。控制台部署在一台服务器上承担策略管理、日志存储、告警展示客户端装在每台终端上负责执行查杀、上报事件、接收策略。两级架构在单办公点、几百台终端时完全够用部署最快、排障最简单所有日志都写控制台数据库不需要额外组件。一旦终端规模上来或者办公点分散两级架构的短板就暴露了。客户端要定期向控制台上报心跳和事件如果终端和控制台之间隔着跨网段链路网络质量差心跳会丢终端在控制台上时上线时离线策略下发也慢。大量终端的日志同时回传还会把链路带宽吃掉。这时候需要加中继节点终端只和中继通信中继把数据批量转给控制台同时缓存策略。链路断了终端依然能拿到最近一次的策略链路恢复后中继把积压的日志补传上去。我判断要不要上中继就看三个条件满足任一条就建议上终端总数超过 1000 台办公点不止一个且站点间链路质量不稳定存在隔离网段终端直连不到控制台。中继节点的配置不用太高CPU 和内存给控制台的一半就够但磁盘要留足因为它要临时缓存日志。部署顺序也有讲究先装控制台再装中继最后推客户端。顺序乱了客户端起来找不到可用的服务器会在日志里刷一堆连接失败看着吓人其实只是时机问题。两级架构下的高可用很多小团队不考虑。但控制台挂了策略下发、告警全部瘫痪终端只能靠本地策略硬撑。如果条件允许数据库单独放到一台机器上和控制台分离——至少数据库崩了不影响控制台重启控制台崩了数据库还在。我见过控制台和数据库装在同一台机器系统盘满了之后两个服务一起挂恢复时谁先启动都费劲。2.2 服务器资源评估CPU、内存、磁盘的实用估算管理员手册里的最低配置一般写得偏保守照那个买跑起来大概率页面卡、报表慢。这里给一组实用值按终端规模分档终端规模CPU内存系统盘独立日志盘建议500 台4 核8 GB100 GB200 GB2000 台8 核16 GB100 GB500 GB5000 台16 核32 GB200 GB1 TB 起磁盘是最容易被低估的。一台终端一天平均产生 200 到 800 条事件包括查杀记录、登录日志、外设操作、补丁状态。按 2000 台终端、每台每天 500 条算一天就是 100 万条单条事件按 500 字节折算一天约 500 MB一个月 15 GB 上下一年日志库轻松到 200 GB 量级。所以日志盘要独立挂载和系统盘分开并在安装时就设置日志保留周期比如 180 天自动清理。数据库建议用独立的数据库实例安装时有几个参数值得提前想清楚。日志库的自动增长设置改成按固定大小增长而不是按百分比避免数据库文件失控膨胀备份策略每天一次差异备份、每周一次全量备份备份文件放另一块磁盘。数据文件放哪、日志文件放哪安装时规划好装完再挪就需要停机操作了。操作系统方面服务端推荐主流 Linux 发行版避免过于冷门的版本否则安装脚本可能缺依赖重启后服务能不能自动拉起也要在装机后验证一次。还有一类容易被忽略的资源是中继所在位置的带宽。终端的事件都从中继过一道中继的出口带宽直接决定日志上报速度。带宽不够客户端上传失败控制台看到的终端状态就会滞后告警也不及时。2.3 最小化部署流程初始化、授权导入与端口放行安装包分服务端和客户端两种服务端常见做法是离线包部署在 Linux 上。下面以最小化部署为例过一遍命令# 1) 解压服务端安装包路径按实际放置位置为准 tar -xzf anshu-console-linux-x86_64.tar.gz -C /opt/anshu cd /opt/anshu # 2) 执行安装脚本核心参数是数据库连接和控制台访问地址 ./install.sh \ --db-host 192.168.10.5 \ --db-port 1433 \ --db-user sa \ --db-password StrongPass_2024 \ --console-ip 192.168.10.10 \ --data-dir /data/anshu # 3) 服务启动后确认关键端口在监听 systemctl start anshu-console systemctl status anshu-console ss -lntp | grep -E :443|:8014参数说明--db-host 和 --db-port 指向数据库实例地址安装脚本会自动建库和初始化表结构--db-password 务必用 12 位以上强口令安装完成后单独修改数据库账号口令--console-ip 是终端要访问的控制台地址必须填终端能路由到的 IP写 127.0.0.1 会导致客户端全部连不上--data-dir 指到独立日志盘不要把数据库文件放在系统盘。端口放行三处443 是管理员浏览器访问控制台用的 HTTPS 端口8014 是客户端与控制台或中继的通信端口终端到控制台这条链路必须放行数据库端口只需要数据库所在服务器向控制台服务器开放不需要暴露给终端。注意先把放行规则加好再推客户端否则客户端起来连不上全部显示离线排查一圈才发现是防火墙的事纯属浪费时间。首次登录用安装时生成的管理员账号。进去后第一件事不是建查杀策略而是按顺序做四件事改掉默认口令、导入产品授权、按部门创建分组、拆分管理员角色。授权不导入部分策略功能会被限制分组不建好客户端注册进来全堆在默认分组之后再一台台挪几千台的量级能挪到怀疑人生。3. 策略配置的三块硬骨头查杀、补丁、外设管控的调参思路3.1 病毒查杀策略实时防护、定时查杀与白名单的顺序问题查杀策略是管理端最常用的模块但不是把实时防护打开就完事。安枢的策略按分组下发不同部门挂不同策略。厂商预设的默认策略是均衡档我一般不建议直接用而是复制一份按自己的环境改改的时候遵循一个顺序先定发现动作再定扫描频率最后加白名单。顺序反了白名单和查杀规则相互打架排查起来很费劲。发现病毒后的动作可选仅记录、隔离、删除。我的建议是选隔离而不是删除。隔离相当于给自己留了后悔药文件还在隔离区误杀能恢复直接删除的话业务程序被误杀就只能重新部署有时候连安装包都找不齐。隔离区的文件建议保留 30 天以上确认不是业务程序后再统一清理。启发式扫描强度也要留意。开太高正常软件的正常行为会被判定成可疑自研软件和第三方绿色工具扎堆的环境尤其容易误报。实时防护里的文档扫描扩展名开关默认可以不开只扫可执行文件格式能少很多误报代价是恶意文档靠行为检测兜底。定时查杀主要调三个参数周期、扫描类型、CPU 上限。全盘扫描很耗资源安排在凌晨业务低谷CPU 上限设 30%避免早上到公司发现夜里全盘扫描把机器卡了一宿。策略导出文件大致长这样{ policyName: 研发部-查杀策略, inheritParent: false, realTimeProtect: { enabled: true, actionOnDetect: 1, enableDocScan: false }, scheduledScan: { enabled: true, cron: 0 2 * * *, scanType: 1, cpuLimitPercent: 30 }, exclusions: [ { type: path, value: D:\\DevTools\\ }, { type: hash, value: c4e0b9d0f6a1e8f2a3b4c5d6e7f8a9b0 } ] }字段说明policyName 建议带部门前缀策略多了一眼能认出来realTimeProtect.enabled 是实时防护开关actionOnDetect 取值 0 仅记录、1 隔离、2 删除enableDocScan 控制是否深度扫描 Office 文档默认 falsescheduledScan.cron 是定时查杀表达式0 2 * * * 表示每天凌晨两点scanType 取值 0 快速扫描、1 全盘扫描cpuLimitPercent 限制扫描时的 CPU 占用exclusions 是白名单数组type 区分路径和 hash。白名单有个隐蔽的坑按目录排除时把整个 D 盘排除D 盘上的查杀和实时防护就全部失效。我最初图省事给某部门配了 D 盘整体排除后来发现 D 盘上的样本文件全被放行排查时想不通为什么扫不出来。正确做法是只排除具体软件目录能用 hash 就不用路径软件更新后重新采集 hash。3.2 补丁管理灰度发布、试点分组与回滚节奏补丁管理模块解决的是漏洞闭环。安枢周期性扫描终端缺失的补丁管理员负责审批和下发。最忌讳的操作是全量直接推送。Windows 补丁和业务软件的兼容性问题说不清翻车率很高尤其驱动类补丁推完一批机器蓝屏的案例不少。我一般按四个步骤走。第一步先跑全网漏洞扫描拿到缺失补丁清单第二步按严重级别分优先级高危漏洞和核心服务器优先第三步建试点分组把补丁推到试点终端观察 24 小时重点看有没有蓝屏、软件报错、驱动异常第四步试点没问题再推全量全量也分批每批间隔一小时边推边看告警。补丁下发的关键参数有四个。静默安装时间设凌晨两点到四点业务低谷重启策略允许用户延迟重启但设上限比如 24 小时否则补丁装了不重启等于白装失败重试次数设 2 次超过 2 次说明补丁和这台机器有兼容性问题再重试也白搭维护窗口如果终端有集中业务时段把安装时间限制在维护窗口内。回滚能力要提前验证。个别补丁在特定硬件上出问题比如显卡驱动补丁导致显示异常要能快速把该补丁从策略里排除。操作路径是找到补丁编号在补丁策略里加入黑名单对受影响终端下发不适用状态再手动卸载已安装的补丁。注意部分补丁不支持卸载所以驱动类补丁我倾向直接跳过不在补丁管理里下发少一事总比多一事好。3.3 外设管控与准入策略先统计、再白名单、后强制外设管控是最容易被抵触的功能因为它直接影响使用习惯。管理员得在安全需求和体验之间找平衡。先给一张常规环境下的配置参考表管控项建议默认值场景说明USB 存储设备只读防止数据被拷走财务等需要写出的岗位单独立策略USB 键鼠放行无线键鼠的接收器也是 USB误拦会导致键鼠失灵蓝牙禁用防止蓝牙传文件、连外部设备无线网卡禁用防止终端绕过有线准入笔记本外出场景单独留策略光驱/刻录只读防止光盘刻录数据带出打印机放行按设备 VID/PID 白名单管理先统计后放行这张表的前提是先做存量统计。上线外设管控之前我习惯先花两天收集全公司的外设型号哪些打印机、哪些 U 盘品牌、哪些无线键鼠接收器。把合法设备的 VID、PID 录进白名单再把管控策略切到强制执行。顺序反了直接开管控全办公室的打印机集体失灵运维电话会被打爆——这是必踩的坑。管控策略注意粒度。安枢支持按用户、按分组、按时段控制比如研发部工作日 9 点到 18 点禁止 USB 写入。建议先按分组做粗粒度管控跑两周没有大量业务反馈再精细化到具体设备类型。一步到位配得太细出问题反而难排查因为不确定是哪条规则拦了哪个设备。最后是策略优先级问题。拦截规则和白名单规则的关系通常白名单优先但同一条策略内多条规则的顺序在某些版本会影响结果。注意配完策略一定拿一台测试终端实际插一下 U 盘验证别只靠策略页面的逻辑推演。验证通过再全量这个习惯能少挨很多骂。4. 客户端分发与终端纳管覆盖率的三个关键环节4.1 三种分发方式怎么选域推送、离线包、手工安装客户端能不能装完直接决定这套系统的覆盖率。覆盖 80% 和覆盖 95%防御效果差一个量级因为漏掉的那 5% 恰恰是最难管的机器。常见分发方式有三种各有适用场景。分发方式前置条件适用场景主要风险域推送终端已加入域全内网统一装机依赖域控稳定性跨站点推送慢离线安装包无隔离网段、无域环境需要人工或配合软件分发平台执行手工安装无服务器、少量终端效率低适合必须现场确认的机器域推送最省力前提是终端都加了域。把安装包放到域控可访问的共享目录通过组策略里的软件安装策略发布终端开机自动装。这种方式不需要逐台操作但依赖域控的稳定性跨站点链路差时安装包下发会超时。另外域推送默认是计算机配置级别的安装用户不能卸载省了防卸载的口舌。离线安装包适合隔离网段。把安装包拷到目标机器执行通过命令行指定服务器地址。在终端多但网络不通的网段我一般配合软件分发平台或批量运维工具来跑纯人肉一台台装几百台要装一整天还容易漏。装完务必在控制台确认注册状态别只看本机进程。手工安装看起来最笨但在服务器场景反而是首选。Windows Server 上装客户端域推送可能因为系统版本兼容性失败静默安装也可能缺运行库手工执行能直观看到报错。装完顺手确认一下服务和进程正常比返工强。服务器数量通常不多手工装的成本完全可以接受。4.2 静默安装与分组绑定一条命令把终端装进指定策略组客户端安装包支持静默安装参数这是批量分发的基础。Windows 下用 msiexec 或安装包自带的静默开关核心参数是服务器地址和分组编码# Windows 客户端静默安装示例 msiexec /i anshu_agent_x64.msi /qn \ SERVER_ADDR192.168.10.10:8014 \ GROUP_CODEdept-rd \ INSTALL_DIRC:\Program Files\AnShuAgent \ UNINSTALL_PWDUninstall2024参数说明SERVER_ADDR 是控制台或中继的地址和端口配成中继地址可以减轻控制台压力GROUP_CODE 是预建分组的编码客户端装上后自动归入该分组并继承策略这一步能让终端刚上线就处在正确的策略保护下INSTALL_DIR 是安装路径建议保持默认改路径会导致隔离区路径对不上恢复文件时找不到UNINSTALL_PWD 是卸载口令防止用户自己卸载客户端。Linux 客户端安装类似脚本支持命令行参数# Linux 客户端静默安装 ./install_agent.sh \ --server 192.168.10.10:8014 \ --group dept-rd \ --silent \ --uninstall-pwd Uninstall2024--server 指定服务器地址--group 指定分组编码--silent 表示不打印交互提示--uninstall-pwd 设置卸载密码。安装完成后建议手动确认守护进程在跑systemctl status anshu-agent。某些 Linux 发行版缺依赖库安装脚本会静默失败看安装目录下 logs 里的报错缺什么库补什么。批量执行时有个细节装完立刻去控制台看注册状态而不是只看本机进程。客户端装了但注册失败控制台里看不到这台终端等于白装。注册失败的常见原因有三个分组编码写错、服务器地址不可达、时间偏差过大导致证书校验失败。4.3 客户端状态异常的排查路径离线、失联、重复纳管控制台里最常看到的告警是终端离线。排查离线有一套固定路径按顺序走能省大量时间不要一上来就重装客户端。第一步看进程和系统服务在终端上确认客户端服务在运行进程列表里有 anshu_agent。服务没起来就先手动启动看是否有报错。第二步测网络连通性从终端到控制台的 8014 端口# 在终端上测试到控制台 8014 端口的连通性 telnet 192.168.10.10 8014 # 或使用 nc nc -zv 192.168.10.10 8014通就说明链路没问题问题大概率在认证或配置层面不通则检查防火墙、路由、端口放行。第三步看客户端本地日志位置一般在安装目录的 logs 下重点搜 connect、timeout、certificate 关键字。第四步确认终端系统时间这个最容易被忽略客户端和服务器之间的通信有证书校验终端时间偏差超过 5 分钟校验失败表现就是离线。校准时间后重启客户端服务即可恢复。还有一类是重复纳管。终端重装系统或换了网卡后重新装客户端注册成了新资产旧资产还在控制台里挂着离线。结果资产列表里出现大量幽灵终端统计数字失真策略覆盖率的百分比也不可信。解决办法是定期在控制台做资产合并或清理过期记录我习惯每个季度清理一次。5. 管理员手册避坑指南5 个高频问题的现象、原因与解决以下 5 个问题是从实际运维里沉淀出来的手册里大多分散在不起眼的角落甚至只在官方知识库里有一句带过。按现象、原因、解决三段式写清楚遇到可以直接对照省得再走一遍弯路。5.1 策略改了不下发终端一直执行旧策略现象在控制台改完查杀策略等了一天终端上的策略版本号还是旧的新加的排除目录完全没生效。终端设置里手动触发策略更新也没反应。原因一般是三个策略没有正确匹配到终端所在分组策略页面点了保存但没点应用或生效按钮终端分组处于继承状态子分组的策略被父分组覆盖。安枢的策略有继承关系子分组没单独配策略时继承父分组但父分组的策略版本更新后子分组终端的更新可能延后。解决先在策略详情页看「已覆盖终端数」如果覆盖数是 0说明策略没挂到任何分组重新绑定分组。再到终端列表确认终端实际所在分组和策略匹配情况。最后对单台终端做一次手动策略更新观察日志里的下发记录。建议每次改完策略先在测试分组里验证再全量应用。5.2 终端显示离线但现场看进程还在运行现象控制台里终端状态是灰的显示离线几个小时跑到终端现场看客户端进程活着界面也能正常打开。原因客户端和控制台的连接断了心跳发不出去。常见诱因是终端 IP 变了、防火墙拦截了出站 8014、终端时间偏差导致证书校验失败。还有一个场景本机装了另一个安全软件抢占了 8014 端口客户端起不来。解决按 4.3 的排查路径走。重点先看时间同步然后 telnet 测端口再看本地日志。如果是端口被占把另一个安全软件卸掉或改端口如果是 IP 变化DHCP 环境下给终端预留固定 IP或者在控制台更新资产的 IP 信息。重置客户端是最后一招能不用就不用因为重装之后终端重新注册策略和分组要重新确认一台两台还好几十台就折腾了。5.3 自研程序被当恶意文件隔离业务直接不可用现象某个业务模块突然打不开控制台告警列表里出现一堆已隔离事件文件路径全是公司自研程序的目录业务方第一时间找运维。原因自研程序没有代码签名行为特征碰了启发式规则的敏感点比如写注册表、注入进程、访问敏感目录。要是发布时用了加壳工具更容易被判定为可疑。解决先从隔离区恢复文件确认文件完好加白名单后再重新放行。白名单按 hash 加最稳但自研程序频繁换版本hash 要反复更新这时候可以按目录加白只排除程序安装目录不要扩大到相邻数据目录。根上的解决方式是让研发给程序做代码签名签名后的程序在绝大部分引擎里默认信任误杀率能降一个量级。我经手的项目里推动自研程序签名这件事的回报率远高于反复调白名单这也是血泪经验换来的。5.4 补丁反复安装失败状态一直停在待重启或失败现象某台终端补丁状态长期显示安装失败手动重推几次还是失败或者提示待重启重启完再看还是失败状态就没干净过。原因多数是 Windows Update 相关服务被禁用很多优化工具会顺手关掉这个服务C 盘剩余空间不足补丁包解压写不进去补丁和已装软件冲突终端策略允许用户无限延迟重启补丁装了但一直不重启生效。解决先在终端上确认 Windows Update 服务为自动并已启动。清 C 盘空间至少留 10 GB 给补丁操作。重启策略改严格不允许无限延迟设置最迟重启时间。手动下载该补丁的独立安装包在终端上执行看具体报错码报错码比系统日志里的状态可靠得多。修完一台就观察同类机型是否有同样问题有的话批量处理别一台一台救火。5.5 日志库磁盘写满控制台响应变得极慢现象控制台页面打开要十几秒登录偶尔超时查询报表直接转圈数据库所在磁盘显示使用率 95% 以上。原因日志保留期设太长或者某段时间全网事件量暴涨。最常见的事件风暴场景是误配置导致全网同时扫描瞬间产生海量记录把磁盘撑满。磁盘满之后数据库写入阻塞控制台的所有操作都被拖住连登录都慢。解决短期的做法是调短日志保留期比如从 365 天调到 90 天触发一次日志清理把历史日志归档到外部存储。长期的做三件事日志盘独立挂载并设监控告警磁盘使用率超过 80% 就通知日志库的自动增长改成固定大小增长避免文件失控对全网扫描类任务设置错峰避免所有终端同一时间点触发从源头压住事件峰值。6. 把手册用出价值的三个进阶技巧SQL 检索、周报和应急响应6.1 直接从日志库查你想要的事件控制台的查询界面能应付日常但想跨表查关联数据、按时间段聚合统计SQL 比界面快得多。安枢的日志落在数据库里字段名在不同版本有差异但表结构大体一致。用只读账号连接数据库安全起见不要用控制台管理员账号跑 SQL免得误操作把配置表改了。-- 查最近 7 天查杀到的恶意文件事件按时间倒序取前 20 条 SELECT TOP 20 MachineName, FilePath, VirusName, DetectTime, ActionTaken FROM MalwareEvent WHERE DetectTime DATEADD(day, -7, CURRENT_TIMESTAMP) ORDER BY DetectTime DESC; -- 查某台终端近 30 天的外设插入记录 SELECT InsertTime, DeviceType, DeviceVID, DevicePID, UserName FROM DeviceControlLog WHERE MachineName PC-DEPT-015 AND InsertTime DATEADD(day, -30, CURRENT_TIMESTAMP) ORDER BY InsertTime;第一条语句用于快速确认全网最近是否有漏网样本第二条适合查违规外设的使用情况比如谁在非白名单时段插过 U 盘。注意字段名要和你实际库里的表结构对齐先跑一条 SELECT 看看列名再写复杂查询这个习惯能避免把时间花在报错上。6.2 自定义报表让安全周报不再靠手工拼周报是管理员和上级沟通的唯一抓手手工从界面导出 Excel 再拼表一周半小时起步。安枢支持自定义报表模板配置好过滤条件和展示字段定时发送到指定邮箱。我建议报表里固定放五个指标离线终端数、查杀事件数、补丁缺失 Top 10、外设告警数、新增资产数。这五个数据能覆盖大部分周报需求。指标的解释比数据本身重要。比如离线终端数上升要备注原因是什么查杀事件数暴增要说明是误报还是真事件。我见过同事把报表原样转发领导看到查杀数涨了十倍以为出了大事其实只是加了一轮全盘扫描任务。报表里的备注字段值得花两分钟写清楚这是向上管理最省力的方式。6.3 应急响应的三个动作隔离、查杀、取证应急响应时控制台上最常用的三个动作是远程隔离、一键查杀、事件取证。发现某台终端有活跃恶意行为第一时间在控制台点击隔离主机让终端脱离网络但保持与控制台通信接着下发快速查杀任务确认样本清除最后导出这台终端近段时间的进程、网络、文件事件留档追踪。隔离前想清楚隔离会把业务断掉如果是一台核心数据库服务器先通知业务方再操作别让安全事件变成业务事故。我自己的习惯是每一次改策略都先在试点组跑 24 小时看日志确认没有异常再全量推。这个习惯让我躲过了好几次把业务系统扫挂的翻车现场。管理员手册讲的是功能和规范真正的操作手感是在试点和排障里练出来的。希望帮到你。本文还有配套的精品资源点击获取
