简介奇安信天擎终端安全管理系统管理员手册是一份面向企业安全管理员、系统运维人员的官方操作指南旨在帮助读者快速掌握终端安全管理体系的部署、配置与运维方法。手册内容涵盖产品定位与核心功能包括终端安全管理、恶意代码检测、网络攻击防护、数据加密、身份验证等同时重点介绍了互联网络、隔离网络、多级级联、高级版EDR四种典型部署场景以及单机部署与集群部署两种形态适合从方案规划到落地实施全流程参考。资源为单个PDF文件约23.07MB页数达400页目录结构清晰便于按需检索。目前已有3884人学习下载对于需要系统了解奇安信天擎V10.0安全能力、制定终端安全策略或完成内网部署上线的技术人员具有较强的实用价值。1. 终端安全管理系统管理员手册为什么说拿到手册只是入场券很多公司拿到这套终端安全管理系统时第一反应是把它当杀毒软件用服务端装上、客户端一铺、全盘扫描一跑就觉得“安全了”。但半个月后再看离线终端一大片业务软件被隔离审计报表没人看漏洞补丁越堵越多。问题出在哪出在管理员手册本身。它把一套系统的部署、策略、运维、排查都写得很全但没人告诉你“先做哪一步、后做哪一步”也没人告诉你哪些坑是配置阶段就能避开的。这套系统能管的事很多病毒查杀、漏洞修复、外设管控、软件分发、网络访问控制。管理者靠它落地安全基线运维靠它批量处理终端问题交付工程师靠它给客户做合规验收。适合谁适合正在部署这套系统、或者刚接手这台“安全中控”的人。读这份手册的关键不是背命令而是把“策略怎么配、终端怎么分、出了事怎么查”这三件事串起来。今天我按这个顺序把手册里的关键环节拆开讲。2. 跑通服务端从单机试点到终端上线照着手册做不迷路部署这套系统第一道选择题就是架构。手册里通常会画好几种拓扑但现实里最常走的只有两条路先盖一间房还是先盖一栋楼。我会先讲怎么选再讲初始化最后讲客户端怎么铺。顺序错了后面会反复返工。2.1 部署架构怎么选单机试点还是分区分域常见做法是先单机试点再按网络分区扩成多级中心。单机模式适合终端量在五百点以内、只有一个办公网段的场景一台服务器装完所有组件管理端、数据库、控制台都在这台机器上适合验证流程和跑通策略。多级中心则适合跨地域、多分支的公司父级中心管理总策略子级中心缓存策略和补丁终端就近接入。我一般会按这张表来定而不是凭感觉拍板部署模式适用规模管理复杂度容灾能力单机模式500点以内试点低无主备模式千点级中中多级中心跨区域多点高高注意选型不要只看终端数更要看网络质量。如果分公司到总部的链路本来就不稳硬把几千个终端都接到总部中心策略下发和补丁分发都会变成灾难。这种情况下把子级中心部署在分公司让终端先就近注册再靠子级中心向上同步是更可靠的路径。多级中心还有一个隐性好处子级中心能缓存补丁包办公终端从本地拉取补丁跨区域的带宽压力会小很多。选完架构手册里的下一步就是装服务端。这里有个原则先装中心服务再装数据库最后装控制台登录组件顺序反了会在初始化时报各种依赖缺失。用 systemd 管理的常见服务端初始化流程通常是这样# 以常见的管理中心服务为例服务名请按实际安装包替换 systemctl start sec-center.service # 启动中心服务 systemctl enable sec-center.service # 设置开机自启 systemctl status sec-center.service # 确认状态为 active (running) tail -f /opt/sec-center/logs/server.log # 观察组件注册日志这套命令的逻辑很简单start先把服务拉起来enable保证重启后不手动干预status用来确认进程状态tail则用来盯注册过程。日志里出现 “component registered” 类似的关键字说明该组件注册完成如果一直卡在数据库连接优先检查数据库服务有没有起来端口是不是被占用。2.2 服务端初始化从导入许可到登录控制台服务端装完第一次登录前要做的常规动作是导入许可文件、建管理员账号、配置补丁分发源。许可文件一般在安装包里自带申请模板按机器码去换许可文件导入路径在控制台的“系统设置—授权管理”里。这块没什么玄学但别等到快到期了再换给商务留足够时间走流程。管理员账号建议建两个一个日常管理员一个紧急管理员。紧急账号只做登录和查看日常账号配置策略分开的好处是万一日常账号被锁或权限被改还能有人能登进控制台查状态。登录方式上多数版本支持本地账号和外部认证对接对接目录服务时注意账号同步字段别把几百个离职账号也同步进来。登录后第一步建议做一次“终端接入参数”检查包括终端回连的服务端地址域名还是IP、端口、是否需要验证码注册。这里我吃过亏客户端装完后一直显示“待审核”排查了半天发现是服务端地址写成了内网IP而终端所在网段访问不到这个IP。换成域名后再等心跳就正常了。所以初始化阶段就把接入域名定下来后续所有终端的安装包都用这个域名不要用会变的IP。主备模式下还要额外做一件事把备机的配置同步做完整。否则主故障时切换过去备机没有许可文件也没有管理员的访问策略等于没有容灾。建议每季度做一次主备切换演练看看备机接管后终端能不能正常回连、策略是不是最新版本。2.3 客户端批量下发静默安装参数与控制台审核客户端铺装有三种常见路径控制台自带的分发中心、企业现有的软件分发系统、或者把安装包放到共享目录后脚本推送。我优先用控制台自带的分发中心因为它会把安装成功、失败、待审核的状态回传方便在控制台直接看结果。下面是一次静默安装的常见写法# 常见做法Windows 安装包用 msiexec 静默装 msiexec /i TSCMClient.msi /quiet /norestart \ TSMC_SERVERsec.example.internal \ TSMC_PORT4430 \ INSTALL_DIRC:\Program Files\TSCMClient \ INITIAL_GROUP待审核终端这里每个参数都有讲究/quiet表示静默不弹安装向导/norestart表示装完不重启否则办公终端半夜自动重启会引发投诉TSMC_SERVER是服务端地址建议用域名TSMC_PORT是服务端监听端口INITIAL_GROUP是终端上线后的初始分组。把初始分组设成“待审核终端”是为了不让新机器一上来就继承高风险策略。装完以后去控制台的“终端管理—待审核终端”里确认。重点看三列终端名、IP地址、最后心跳时间。如果最后心跳时间是空的多半是终端连不上服务端在终端上检查一下 DNS 设置或者确认防火墙是否放行了对应端口。另外不要把安装包直接发给员工让他们自己装人一多就容易装错参数最后离线终端满天飞。客户端上线后不要急着全量下发策略先让它们留在待审核分组里观察一天确认心跳和版本都正常再移入正式分组。这一步能过滤掉大部分“装完就崩溃”的终端也方便查安装失败的共性原因比如某批机器缺运行库、某台机器磁盘空间不足。把这些失败原因归类记到手册里下次批量铺终端的时候能省一半时间。3. 把策略配明白终端分组、病毒查杀与漏洞管理的关键参数系统跑起来只是第一步管理员手册真正花大篇幅讲的是策略。我把策略分成三层先按业务重要性分好组再配查杀和补丁策略最后才轮到外设和分发。顺序不对的话后面改策略会一直在“误杀—加白—又误杀”的循环里转根本退不出来。3.1 终端分组与策略继承先分业务域再配策略分组的粒度很关键。常见错误是只按部门分把市场部和研发部放一个组。正确思路是先按业务重要性和风险容忍度分大组再在大组内按部门建子组。原因是策略里“是否允许隔离”“是否允许插U盘”“补丁是否自动装”这些选项直接和业务风险挂钩和部门组织架构没有必然关系。我常用的分组模型是这样分组策略基调覆盖项核心业务服务器群严格保护实时监控全开、隔离自动处理、补丁人工审核研发办公终端宽松观察查杀只告警不隔离、外设先审计、补丁延时灰度普通办公终端默认合规自动隔离、U盘只读、补丁自动安装测试终端高风险放行扩大免杀范围、加强行为审计怎么判断一台终端该进哪个组我的标准是“这台机器上的数据丢了公司一个月内能不能补回来”。核心业务服务器的数据补不回来所以策略最严测试终端装了各种未知软件策略太严反而天天误报。分组定下来之后后面所有策略都挂在组上终端只会属于一个组不要试图把策略直接绑到单台机器上否则终端一多就乱套。策略继承的规则一般是“子组继承父组子组可覆盖”。做权限分离的时候父组只放公共策略比如“全体终端禁止运行危险脚本”子组再放差异项比如研发组“允许安装开发者工具”。这样以后调整公共基线只需要改父组一次不用每个子组都动一遍。3.2 病毒查杀策略实时监控、扫描时机与白名单边界实时监控不要一上来就开“隔离处置”。我建议先开“仅告警”模式跑三到五天让误报暴露出来再决定哪些路径要加白、哪些动作要自动隔离。尤其是制造业、设计行业这些机器上装了特殊驱动的直接开自动隔离风险比不装杀毒还大——业务停摆的损失远大于病毒本身。扫描时机设置上避开业务高峰是底线。全盘扫描放在午休或下班时段实时监控的 CPU 占用上限设到 50% 以下避免跟编译任务抢资源。查杀引擎的多引擎开关测试环境可以全开生产环境先开一个主引擎确认性能损耗可接受再逐步叠加。判断标准是终端日常操作无感用户不投诉卡顿就算合格。白名单要分层。目录白名单适合用完即弃的临时目录文件白名单适合固定的业务程序。恶意行为拦截里“勒索行为检测”“脚本混淆检测”这两个开关建议保持开启这是拦截加密勒索的关键。白名单设置错了只会影响查杀效率但“自动隔离”设置错了会影响业务连续性。所以每条隔离规则后面都要配一个“隔离前通知”选项给业务留出反馈时间。3.3 漏洞修复策略补丁灰度与例外清单补丁管理做不好比不打补丁还糟。常见做法是把补丁分三个通道测试通道、普通通道、紧急通道。测试通道先覆盖测试终端和少量办公终端观察 24 小时没有蓝屏或软件崩溃再进普通通道全量下发。紧急通道用于漏洞激活期的应急修复可以越过测试但必须选在业务低峰期。例外清单是补丁策略里最容易漏的一块。有些老旧终端打上新补丁会出兼容性问题必须用例外清单把这些终端钉在旧补丁版本上。同时给补丁分发设置带宽上限尤其多级中心模式下补丁包在子级中心缓存一次终端从子级中心拉取能节省大量跨区域带宽。查杀策略和补丁策略配完别急着全量。把新策略先绑定到“待审核终端”分组让一小批终端先跑一个晚上第二天看策略生效状态和补丁安装成功率没问题再逐组切换。这个过程在手册里叫“策略灰度”我自己的使用习惯是任何策略变更宁可慢一天不可快一分钟。改一次策略容易但轰掉一批终端的生产环境要花一周来收拾。4. 让管控真正落地外设、软件分发与网络访问控制的实操边界查杀和补丁解决的是“已知问题”外设管控、软件分发和网络访问控制解决的才是“管理边界”。这三块也是管理员手册里最容易读得懂、但做起来最容易翻车的部分。前面讲的是引擎能力这一章讲的是策略边界。4.1 外设管控USB白名单与审计记录外设管控的第一原则是先审计后禁用。直接全线切断 USB 存储会把财务的 CA 证书、设计部的加密狗、产线的烧录工具全干掉。正确顺序是先用审计模式记录一周看看哪些 USB 设备是业务真实在用的根据记录做白名单再把白名单之外的 USB 存储设备设成禁止写入或完全禁止。常见的管控维度包括 USB 存储、打印机、光驱、蓝牙、串口。注意禁用 USB 存储不等于禁用 USB 口USB 口的键鼠、加密狗、烧录器要走例外名单放行否则全公司工位上没人能用无线鼠标。审计日志至少保留三个月外设拷贝行为的记录要能查到设备ID和文件路径这是事后追溯的基础。我一般建议开启“文件外发审计”把拷贝出去的文件名、大小、目标设备都记下来哪怕不禁也能在出事时往回查。管控对象审计模式禁用模式适用场景USB存储记录读写禁止写入财务、研发打印机记录放行全员光驱、蓝牙记录禁止涉密区域这套表的好处是边界清晰审计是默认状态禁用是例外动作。等审计数据跑了一周你会发现很多“看起来必须用U盘”的需求其实是可以在文件服务器上解决的。到那时候再收紧禁用范围业务部门也拿得出数据来支撑自己的诉求。4.2 软件分发静默安装与卸载的边界软件分发功能容易出问题的不是安装而是卸载和升级。给业务软件分发新版本前先做两件事确认旧版本可以静默卸载确认升级后配置文件不丢失。否则分发出去了一堆终端软件坏了运维得一台台去救。分发中心的任务状态回执字段要选“失败详情”而不是只看成功数。分发任务的状态怎么看我一般会在服务端命令行查任务详情常见做法是这样# 查看分发任务详情常见命令格式 sec-center task show --name 更新业务客户端 --detail # 输出中包含每个分组的 完成/失败/超时 数量 sec-center task list --failed-only --last-24h这条命令的价值在于把失败原因显性化。失败原因通常分几类目标终端离线、安装包路径不存在、被杀毒策略拦截、需要重启后才能继续。看到“策略拦截”这类原因时不要强行重推先加白或调整策略再重新分发。重推次数多了会造成终端负载升高用户那边就是“风扇狂转、电脑卡死”的体验。软件分发的另一个边界是“卸载控制”。禁止终端用户自行卸载办公软件和控制类客户端把卸载密码纳入保密范围。分发中心里“强制卸载”的动作要二次确认因为一旦卸错几百台终端要重新装回来。我在分发前会先做二十台终端的小批量验证确认安装参数、配置文件、权限都没问题再走全量分发。这个习惯帮我躲过好几次大范围装错版本的翻车。4.3 网络访问控制应用识别与恶意回连处置网络访问控制要管的是两件事终端上的应用有没有去访问不该访问的地址以及终端有没有主动回连恶意服务器。做这项管控时优先开“记录”和“告警”确认规则能把正常业务的流量特征都认出来再切换成“阻断”。阻断规则一旦误伤业务系统影响面会比查杀误报还大。应用识别规则里把重点放在“定时任务”“脚本宿主”这类容易被恶意利用的组件上给它们建立独立的管控策略。恶意回连检测要联动查杀引擎当某个终端同时出现“异常网络行为”和“可疑文件”两个线索时可以自动触发处置动作例如隔离该终端并通知管理员。这里的关键词是“联动”单看网络行为或单看文件都不够准确。需要特别提醒的是网络访问控制一定要基于“恶意地址库”和“业务白名单”双向收敛不要试图穷举所有可访问的应用。把可信应用和可信目标地址放行其余默认告警这才是可持续的运维方式。如果一开始就设成全阻断第三天就会被业务人员的求助电话淹掉。先告警两周把正常业务流学习完再逐渐收敛阻断范围我这边落地时基本没有投诉。5. 管理员手册的排查专题三个最容易翻车的环节与修复流程策略配好只是“纸面合规”。日常运维里离线、误杀、策略不生效这三个问题会反复出现。我把遇到过的现象、原因和解决思路整理在下面你可以直接对着排查。5.1 客户端大面积离线现象、原因与三步定位法现象控制台“终端管理”里一批终端最后心跳时间停在几小时前告警列表刷屏。原因常见有三类。一是终端所在网段到服务端的链路中断比如交换机策略变更或 DHCP 分配了新的网段二是服务端资源耗尽数据库连接池满心跳请求排不上队三是客户端本地服务异常多数是安装时被其他安全软件干扰。解决先做三步定位。第一步在服务端查离线终端清单确认是“全部离线”还是“某个网段离线”第二步挑一台离线终端检查本地客户端服务状态第三步核对终端到服务端的网络连通性。三句话的排查路径如下# 第一步控制台或命令行导出离线终端 sec-center client list --offline-only --last-24h # 第二步在离线的终端上检查客户端服务 systemctl status sec-client-agent # 第三步在终端上探测到服务端的端口连通性 nc -vz sec.example.internal 4430这里要重点解释第二步。终端本地服务如果显示 exited通常是安装时没装干净卸载重装即可如果显示 active但心跳还是断了问题大概率在网络或服务端。第三步的端口探测要在终端上执行不要只在服务端上测试双向探测才准确。等恢复后我建议给服务端多配一条备用心跳通道避免单点故障拖垮整片终端。如果离线终端里面包含核心业务服务器还要第一时间评估数据是否还被保护着必要时先人工介入处置。5.2 业务程序被误杀隔离区恢复与信任体系建立现象业务反馈“某个软件启动就报错”控制台告警里显示某程序的子文件被隔离或者某个脚本被当作恶意脚本拦截。原因查杀引擎对带数字签名的程序通常放行但很多自研软件没有签名且行为特征与恶意软件相似比如释放临时文件后修改注册表、开机自启动正好命中了引擎的“可疑行为”规则于是被隔离。解决去隔离区找到被隔离文件确认是业务文件后执行恢复然后把该程序加入白名单。但这只是止血真正要做的是建立信任体系给业务软件目录设置白名单目录给启动它的父进程设置“可信任程序”标记最后把该业务软件关联到一个“只告警不隔离”的策略组。注意恢复隔离文件后一定要重新做一次手动扫描确认没有真实威胁被夹带恢复。白名单别宽泛只加必要路径加得越多后续查杀盲区越大。5.3 策略不生效版本号对不上时先看下发链路现象控制台已经改了策略并“下发”但终端的行为没变化比如 U 盘依然可写或告警模式没变成阻断模式。原因策略变更后终端并不是实时拉取而是按心跳周期去同步。如果终端心跳异常或者策略版本下发顺序错误就会出现“控制台显示已下发、终端显示旧版本”的情况。解决先在终端本地查看当前策略版本确认与控制台版本是否一致。如果不一致检查下发任务状态是否停留在“待发送”然后手动触发一次策略更新。更新后等一到两个心跳周期再复查终端策略状态。避免这类问题我习惯在控制台建一个“策略版本表”每次变更记录版本号、变更内容、目标分组、下发时间、生效确认时间。复杂度不高但能省掉大量“到底发了没有”的争论。5.4 终端自保护与软件卸载拉锯现象运维想卸载某台终端的客户端结果提示需要管理员密码或者卸载后残留服务重新安装时冲突。原因终端安全系统自带自保护模块防止恶意软件卸载它。这是功能特性但也带来运维上的不便。卸载时要么通过控制台下发的“卸载许可”操作要么在终端上输入管理员授权码直接强删文件会导致服务残留。解决统一走控制台“终端卸载”功能先解除自保护再卸载。如果已经出现残留先停止残留服务再清理注册表之后重新安装。我建议在部署之初就定好客户端卸载密码由专人保管并记录在手册的应急页里否则人员变动后可能谁也卸不掉。这些坑单独看都不大但连在一起就会消耗大量运维工时。把排查路径提前写在手册里比每次出问题都翻聊天记录要可靠得多这也是管理员手册真正值钱的地方。6. 把手册用活事件回溯、报表验证与灰度回滚6.1 事件回溯把一次告警从头查到尾查到告警后不要只盯着进程名。我会按这个链查终端是谁、在哪个分组、机器上有哪些最近安装的软件、这个进程的父进程是谁、触发过哪些查杀动作。手册里的事件回溯模块会把“文件—进程—网络行为—处置动作”串成一条时间线按时间线反查比一条条日志更直观。验证效果时我每月挑一条真实告警从头到尾走一遍回溯流程看时间和动作链能不能对得上。对不上说明日志采集有缺口要趁早补别等安全事件来了才发现啥也查不到。6.2 先验证再全量策略灰度与回滚习惯所有策略变更都走灰度先绑一个试点分组观察 24 小时看告警数、隔离数、业务投诉数有没有异常再往全量推。回滚就是切回上一版策略版本控制台一般保留最近几个版本回滚通常在一分钟内完成。我自己会把“回滚步骤”打印出来贴在显示器边上真到出问题时脑子是懵的照着步骤点比现场想快得多。说说我自己的教训有一次调整外设管控没做灰度直接全量下发结果产线烧录器全部被禁停工两小时。从那以后我给自己定了个规矩任何管控类策略先试点再铺开任何查杀规则先告警再隔离任何补丁先测试再全量。这套思路补齐了管理员手册里没写出来的“操作顺序”也建议你把它写进自己的运维 checklist。希望帮到你。本文还有配套的精品资源点击获取