干过测评的同行都知道等保测评高风险判定是整个报告里最让人头大的一环。测评结论最终合不合格很大程度上就看高风险项能不能清零或者给出让人信服的整改计划。安全计算环境这一块覆盖了网络设备、安全设备、主机设备是现场设备数量最多、问题最密集的部分。很多单位整改到最后剩下的高危项基本都集中在设备弱口令、明文管理、日志不开启、默认共享这类“老面孔”上。这篇文章就结合我自己做现场核查和复测的经验把安全计算环境里高风险判定的思路、判定尺度、现场操作和容易踩的坑完整理一遍给准备迎检的甲方、做整改的乙方和刚入行的测评工程师做个参考。1. 先弄懂高风险判定的底层逻辑1.1 判定不是“扣分”而是看风险后果刚入行的时候我一度以为高风险判定就是对照条款打个分不符合就扣分分低了算高。干过几次就发现完全不是这个逻辑。等保测评的高风险判定本质上是一个面向后果的评估一个问题被利用之后会不会对系统造成严重伤害伤害是否难以接受如果答案是肯定的而且没有其他控制措施兜底那就倾向判高风险。举个例子一台亮着公网IP的Web服务器用的是默认口令攻击者匿名就能拿到管理员权限这就是典型高风险。同样是这台服务器如果它被放在严格隔离的运维网段里只有特定工位的跳板机能访问外部流量进不来那么配置上同样有问题但在综合判定时风险等级就可能降下来。这不是测评放水而是安全的本质就是“路径能力”的组合。孤立的配置缺陷在多层防护下可能被抵消但那些一通到底的问题才是必须揪出来的高风险。所以我的建议是无论是测评机构还是被测单位拿到一个不符合项不要急着问“能不能算高风险”先问三个问题这个弱点威胁到哪些资产弱点和威胁之间的路径是否可达被利用后造成的数据泄露、业务中断或权限失控有多严重这三个问题想明白了判定结果往往是顺理成章的。1.2 判定依据的层级与地方口径差异高风险判定看着是技术活实际上也是合规活。直接的依据是等保2.0的《信息安全技术 网络安全等级保护基本要求》GB/T 22239-2019配套的有《信息安全技术 网络安全等级保护测评要求》GB/T 28448-2019。在这两个国标之上各地和各行业还有细化的高风险判定指引把具体的不符合项映射到风险等级上。实际工作中我一直提醒团队不要只抱着一个标准硬套。等级保护管理平台上有统一口径行业主管单位也可能下发针对性的判定细则。不同级别的系统同一个问题判法不完全一样。比如弱口令在一个二级系统里如果系统本身在内网、网络边界控制也严格很可能判中风险但同样的弱口令出现在三级核心业务系统上即使在内网也经常被往高风险方向带因为核心系统的横向攻击面大单一弱口令能撬动的数据价值完全不同。这就是为什么测评报告里同一个问题在不同项目里结论可能不同。不少甲方拿两家测评机构的报告做对比发现判定不一致以为有一家不专业。其实只要判定逻辑清晰、分析过程完整口径差异是可以解释的。作为测评工程师不要追求“一个结论走天下”而要确保自己的每个高风险判定都有清楚的分析路径和依据链条。1.3 设备和网络为什么是高风险高发地带安全计算环境这个层面核查对象包括网络设备、安全设备、主机设备顺带还有数据库、中间件和应用系统但网络设备和主机设备往往是重灾区。数量大是一方面更重要的问题是配置复用。很多单位的网络设备从核心到接入配置模板是同一份密码也是同一个几十台服务器镜像部署默认账号没改口令策略没调。测评时只要抽到其中几台发现问题基本可以断定整个批次都有问题。另一方面设备类对象的管理通道天生暴露面大。交换机、路由器、防火墙都需要远程运维很多单位图省事直接开telnet和HTTP管理或者把管理口挂在业务网段里SNMP团体名还是public。这些问题在安全计算环境里几乎是“一键触发高风险”的按钮。主机端也一样Windows默认共享、Linux允许root直接SSH、杀毒软件欠装、漏洞补丁长期缺失每一条单独看不致命但组合在一起攻防路径就变得非常短。这个部分想说明一个核心观点高风险项不是测评机构“挑毛病”挑出来的而是系统真实暴露面过大、防护能力不足的直接体现。理解了这句话后面的所有判定细节才有意义。2. 网络设备与安全设备的判定红线2.1 弱口令和明文管理最常见的两条红线网络设备身份鉴别这一块弱口令是绝对的高风险触发源。常见的场景包括出厂默认口令未修改、管理账号使用admin/123456这类简单口令甚至空口令。我见过不少单位的边界防火墙上Web管理界面开着口令是厂商默认的管理员以为内网没人知道其实稍微扫一下就能发现。这里要特别注意判高风险不只看口令本身还要看网络可达性。弱口令存在的设备如果同时满足以下两个条件基本就是高风险一是可以通过网络远程登录二是管理地址没有做来源限制潜在攻击者能触达。比如一台核心交换机的管理IP配置在业务VLAN里任何业务用户都能尝试登录口令又是弱口令那风险就非常明确。远程管理协议是第二条红线。telnet、HTTP这些明文协议账号口令和数据包在网上裸奔抓包就能看到。测评时如果发现设备开启telnet且无任何加密隧道保护结合设备的重要程度通常直接记为高风险或重点核查项。尤其是核心交换机和防火墙这类设备一旦被劫持整个网络的控制权就丢了。反过来如果设备只开放SSH、HTTPS就算其他方面有瑕疵身份鉴别这个控制点也相对安全很多。2.2 默认账户、管理地址与权限边界访问控制层面网络设备的高风险主要集中在三个点。第一个是默认账户未处理。很多设备出厂自带admin、super、manage这类特权账号生产环境里直接拿来用密码还不变。就算密码改了默认账户的存在本身就是一个攻击向量因为账户名是公开的攻击者只需要猜密码。按等保要求默认账户应该删除、禁用或者改名不能直接暴露在管理通道里。第二个是管理地址没有限制。我在现场见过不少核心设备远程管理的来源地址是any整个网段都能访问。正确的做法一般是通过ACL限定只有运维网段、跳板机地址能访问管理口这是性价比非常高的加固手段。如果管理口对全网开放配合弱口令那这个系统基本等于把钥匙挂在了门上。第三个是权限边界不清晰。一些设备上普通运维账号拥有管理员级权限或者多个管理员共用一个超级账号出了问题说不清是谁的操作。权限边界在高风险判定里不一定单独拔高但它是审计追踪的基础。权限不清日志审计就跟着失效所以测评时通常会一起记录作为审计不足的佐证。2.3 日志审计、无用服务和SNMP团体名安全审计这一项网络设备经常出现的问题是日志没有集中留存。很多交换机和路由器默认不把日志推到外部的日志服务器只在本地缓存一点点设备一重启关键日志就没了。这种情况在三级系统测评里容易判高因为等保2.0明确要求审计记录留存不少于6个月本地缓存显然达不到。如果单位已经建了集中日志平台但设备没接入同样算不符合接入了但日志时间不对、级别不够也会被记录为部分符合。入侵防范方面网络设备的高频问题是不必要的服务没关。telnet服务算一个HTTP管理服务也算还有一个经常被漏掉的SNMP。SNMP默认团体名是public或private而且没有限制管理站地址那设备的系统信息、接口流量、部分配置都能被探测到。早期很多网络攻击就是从SNMP信息收集开始的。所以现场核查时SNMP的团体名和管理限制一定要看不要因为它不起眼就漏掉。对安全设备来说日志审计还有一层特殊含义。防火墙、IPS、抗D设备本身就是安全防线它们记录的攻击日志是事后追溯的核心证据。如果这些设备的日志没有落地长期存储攻击行为发生之后很难还原。测评复测时我最常核对的就是这些设备的日志留存情况存了、能查、时间对得上才算真正通过。3. 主机设备的高风险判定细节3.1 主机口令与远程登录的判定尺度主机的身份鉴别和网络设备逻辑一致但细节更多。Windows和Linux两套系统判定的侧重点还不一样。Windows系统主要看本地管理员口令是否为空或弱口令是否启用了自动登录Guest账户是否禁用远程桌面是否允许弱口令直接登录。我遇到过一个比较典型的案例某台Windows服务器开着远程桌面Administrator口令是机器名加年份攻击者一旦进入内网用常见密码字典就能直接登进来。这种场景下弱口令加可远程访问直接判高风险没有任何争议。Linux系统主要看是否存在空口令或无口令账户是否允许root用户直接通过SSH远程登录口令复杂度和定期更换策略是否配置。很多单位为了方便直接允许root远程SSH密码还设得很简单。从等保角度讲root远程登录本身不是绝对禁止但通常建议通过sudo加普通用户登录同时限制登录来源。如果root直接远程登录加上弱口令基本就是一个高风险。另外登录失败处理功能也很关键。连续输错几次密码之后应该锁定账户或来源IP一段时间。很多主机根本没有这个配置或者锁定了但时间太短暴力破解工具跑一会儿就能重新尝试。这个点在高风险判定时不一定单独占一条但它会放大弱口令的风险让攻击更容易得手。3.2 Windows与Linux的访问控制坑点访问控制这里Windows有一个非常典型的问题默认共享。C$、ADMIN$、IPC$这类默认共享系统装完就自动开启。在内网环境下如果口令又弱攻击者可以直接通过共享访问整个磁盘。测评时发现默认共享开启同时系统所在网络不具备严格隔离条件配合口令问题判高风险是比较常见的口径。Linux的访问控制问题也不遑多让。常见的高频问题包括系统中存在除root之外具有UID 0权限的账户某些账户没有设置密码或密码过期应用服务以root身份运行临时文件目录权限过宽/etc/shadow文件权限异常。这些配置上的“小漏洞”单个看不致命但它们共同构成了权限提升和横向移动的土壤。测评师在现场不可能把每一个账户都翻一遍但至少要抽查关键服务器把异常账户和服务运行权限看清。还有一个容易被忽略的访问控制点远程管理终端和跳板机的权限。如果运维人员用个人电脑直接管理服务器没有经过堡垒机那主机端的访问控制再严格也扛不住运维终端中毒后被窃取凭据。这一块在安全计算环境里不一定算主机设备的条款但它直接影响主机风险的最终裁定做整改时建议一并纳入考虑。3.3 审计策略和6个月留存怎么查主机审计策略是等保测评里的“常客”也是现场最容易快速验证的一项。Windows系统的默认状态下很多安全策略并不完善尤其是“审核策略”中的登录事件、账户管理、对象访问等子项经常是未配置或者只记录成功不记录失败。等保2.0要求对重要行为进行审计包括用户登录、权限变更、系统操作等。如果审核策略没开登录失败和提权操作都不会产生日志安全事件发生后连线索都没有这就是典型的审计缺失。现场核查时一条命令就能确认auditpol /get /category:*看到未配置的类别基本就可以记录不符合。Linux系统主要看rsyslog或journald的配置以及是否设置了远程日志服务器。常见问题包括syslog服务没开、日志轮转时间太短、系统没有把日志发给集中的日志平台。等保对日志留存6个月的要求在主机本地很难完全做到所以大多数合规做法是把日志集中到独立的日志审计平台由平台统一留存。测评时我一般会先看配置再抽查几台主机确认平台上的日志确实能对应上不是只配了没生效。这里提醒一下不要只看日志服务器上有没有数据还要看日志的时间戳是否准确。主机时间和日志服务器时间差几个小时甚至几天说明NTP同步没做日志可信度大打折扣。这个问题在复测中经常暴露。3.4 补丁、杀软与主机防火墙入侵防范和恶意代码防范是主机层面高风险项的另一大来源。补丁管理这块最典型的高风险场景是操作系统存在严重远程代码执行漏洞且系统直接暴露在互联网或高风险网络。比如一个对外提供服务的Windows主机长期不打补丁漏洞扫描一把就能扫出一堆高危漏洞这类系统在测评中很容易拿到高风险结论。Linux服务器同理内核漏洞、SSH漏洞、Web中间件漏洞如果长期不修复风险同样很高。恶意代码防范方面问题更普遍。不少Linux生产环境因为担心性能或者业务兼容性不装任何防病毒软件这在等保测评中会被记为不符合。但是不是算高风险要看系统所处网络环境。如果主机部署在严格隔离的内网有终端安全管控和准入控制兜底单独一条杀软缺失未必拔高。反过来如果主机面向外部用户又没有其他补偿措施那杀软缺失和漏洞组合在一起就会推高风险。主机防火墙也是一个高频遗漏项。Windows防火墙被“省事”关闭或者Linux的firewalld/iptables规则为空主机上开的服务全部暴露给网络。即使前面有边界防火墙主机防火墙仍然是最后一道防线。等保测评里主机防火墙策略缺失一般会单独记录如果主机上还开着高危险服务这个组合就比较危险了。3.5 资源控制与异常行为监测资源控制这一块主机层面的要求包括登录连接数限制、会话超时、访问时限等。Windows和Linux默认都不做连接数限制SSH和RDP的连接长时间挂着不断开这也是不符合项。不过资源控制在高风险判定上通常不会单独拔高更多是作为综合评估的一部分。但有一种情况要特别留意如果核心业务系统没有设置会话超时运维人员离开工位后远程会话一直开着被路过的人直接利用了这就是真实事故场景。测评时碰到这种我会建议客户把会话超时策略尽快补上虽然它未必单独判高但和弱口令、开放管理端口组合起来风险就会被放大。异常行为监测在主机层面有时候被归到入侵防范里。比如是否部署了HIDS、EDR等主动监测能力。对于三级以上的系统通常会建议部署这类工具。但测评的核心还是看已有措施是否有效而不是单纯看有没有装产品。装了EDR但策略不生效、告警没人看和没装没有本质区别这类“无效安全措施”我在现场见过太多次了。4. 现场测评与判定的实操流程4.1 测评前的资料准备现场测评的第一步不是跑命令而是先收集资料。需要准备的东西包括信息系统的网络拓扑图、设备清单、IP地址规划表、定级报告和备案证明、上一年度的测评报告及整改记录、运维和安全管理制度的文档。这些资料有问题现场工作会很痛苦。设备清单是最容易对不上的。客户提供的清单往往漏掉一半设备或者写的是旧服务器的hostname实际在线设备完全不是那么回事。测评机构在进场前应该先做一次“资产梳理”哪怕通过登录设备查看ARP表、路由表、邻居信息把存活设备摸一遍也比拿着旧清单直接开始强。资产不清测评范围就是一盘糊涂账高风险判定更是无从谈起。另外访谈也很重要。测评师要问清楚哪些设备是核心的哪些是测试环境哪些直接对外开放这些信息决定了后续判定时的权重大小。访谈记录写不清楚报告里的风险分析就缺乏支撑。4.2 现场核查的常用命令现场核查时我会按设备类型快速执行一套基本检查命令。Windows主机核查常用net user net share systeminfo auditpol /get /category:* wmic qfe get hotfixidLinux主机核查常用cat /etc/passwd cat /etc/shadow cat /etc/ssh/sshd_config ss -tlnp systemctl status firewalld iptables -L -n网络设备核查常用不同厂商有差异思科和华为不完全一样show running-config display current-configuration show ssh server display ssh server status show snmp community display snmp-agent community show telnet server这些命令测下来设备的基本配置画像就有了。不过这里有个细节不要只看输出结果就下结论还要结合网络拓扑看设备位置。同一台设备在边界和在内网同样配置问题的风险结论会不同。所以现场要一边跑命令一边对照拓扑图确认设备角色。4.3 判定研判速查表我把安全计算环境里常见的判定场景整理成一个表格方便现场对照使用。这个表不一定覆盖所有情形但基本代表了我平时的主力判定口径判定场景典型表现倾向性结论弱口令远程可达管理口对业务网段开放口令可猜解高风险明文远程管理telnet/HTTP管理无加密高风险倾向管理地址无限制任何IP可访问管理口高风险倾向默认账户未处理出厂admin/super账户存在中高风险看配套SNMP默认团体名public/private无管理站限制高风险倾向审计完全缺失审核策略关闭且无集中日志高风险Windows默认共享弱口令C$/ADMIN$开启口令弱高风险root直连SSH弱口令Linux远程登录无限制高风险高危漏洞公网暴露远程代码执行漏洞且无法打补丁高风险杀软缺失无补偿系统面向外部无终端防护中高风险主机防火墙关闭高危端口直接暴露中风险结合暴露面会话超时未设置SSH/RDP连接长期挂起中风险一般不单独拔高这张表不能当标准答案用它更多是一种经验参考。每个项目都要结合系统级别、网络环境和补偿措施综合判断千万不要对着表格机械打钩。4.4 高风险项报告书写要点高风险判定最终要落到报告里报告书写直接决定结论是否站得住。一个合格的高风险项描述至少要包含四个部分现状描述、判定依据、风险分析、整改建议。现状描述要客观具体不能只写“口令强度不足”要写清楚是哪台设备的哪个账户口令长度、组成是什么远程登录路径是什么。判定依据要写明白引用了等保2.0的哪个条款以及对应的判定指引内容。风险分析是报告的灵魂要说明攻击者从哪个位置出发、通过什么路径、能拿到什么权限、造成什么后果。整改建议要具备可操作性不是泛泛的“加强口令管理”而是给出具体的配置命令或策略建议。很多刚入行的测评师写报告时现状描述写得很多风险分析却一笔带过这是很可惜的。整改方看到报告时最关心的就是“为什么判我高风险”如果风险分析写得透彻整改方向就清晰了复测时双方沟通也会顺畅很多。5. 常见争议项与整改复测心得5.1 争议高频场景的真实判定口径先列几个我在现场被反复追问的场景日志留存不足6个月是不是一定判高不一定。首先要看主机是否有审计功能开启如果审计根本没开又没有集中日志平台那判高比较稳妥。如果审计已开启日志集中到了平台只是部分设备还没有接入到6个月的存储那就按不符合或部分符合记录可结合整改情况评估。内网弱口令算不算高风险要看网络隔离程度和系统重要性。如果一个三级核心系统虽然在内网但内网有大量终端、存在横向移动风险弱口令和Windows默认共享结合很容易被攻击者横向打穿判高合理。反过来一个二级小系统物理隔离在专门机房能接触到的只有两名管理员弱口令就可能只记中风险。核心问题还是“路径可达性”。没装杀毒软件但系统在封闭网段算不算高这取决于封闭网段是不是真的封闭。有的单位自称封闭实际却和办公网连着定期还有外部运维接入那就不能说完全封闭。所以测评师不能只听口头介绍要自己验证网络隔离措施。物理隔离、网闸隔离、严格的VLAN加ACL是三种可信度不同的隔离方式判定时要区分对待。5.2 无效整改的高发原因复测的时候我经常看到一些“无效整改”就是单位觉得已经改了但复查依然不通过。最常见的原因有几个。第一只改了一台设备其他设备没有同步。同一个批次的主机往往存在同一口令、同一个配置问题整改时只处理了抽查的那几台复查时抽查到另一台问题就原形毕露。所以我一直建议客户按设备类型统一整改而不是按现场抽查名单整改。第二协议没换干净。比如把telnet的账号密码改了但telnet服务本身还开着或者SSH虽然装了但telnet没禁。整改报告上写着“已改为SSH”实际设备配置里telnet仍在监听复测时命令一输立刻见真章。第三日志平台搭好了但数据没上去。常见现象是日志服务器地址配置了但设备没重启配置没生效或者采集器只接入了网络设备主机日志根本没往里推。这种情况平台页面上查不到对应时间段的日志跟没整改没有区别。第四防病毒软件装了但病毒库长期不更新。很多单位装上杀软就再也不管签名库半年没动。测评时看病毒库版本和最后更新时间一眼就能看出问题。整改不是“装个样子”是让防护措施真正持续运转。5.3 高风险整改的优先级建议给乙方和甲方说句实在话整改资源有限不要眉毛胡子一把抓。按照我的经验高风险整改优先级应该这么排先处理对外暴露的设备和系统优先改弱口令、关闭明文服务再处理内网核心服务器补齐补丁、禁用默认共享、加固远程登录然后建立或完善日志集中留存机制把审计平台打通最后才是杀软部署、配置加固、策略优化这类工作。这样排序的道理很简单外部暴露面是最快被打穿的口子先把它堵上内网核心资产是攻击的第二目标在横向移动阶段需要重点防日志审计属于事后追溯和合规兜底越早建越好但相比前两件事它不直接阻止攻击发生。很多单位一上来就买日志平台花了不少钱但弱口令还没改等于把消防通道做好了灭火器没买。另外整改之后一定要留证据。配置截图、命令输出、日志平台上的查询记录、补丁安装列表能留的都留好。复测时测评师一扫这些证据就能确认不需要重新跑一遍全量检查整个流程会快很多争议也少很多。写在最后的经验之谈做测评这几年我最深的体会是百分之八十的高风险项并不来自什么高深漏洞而是基础配置缺失。一个口令台账、一份配置模板、一个真正生效的日志平台就能把绝大多数高风险项消掉。测评发现问题只是第一步关键是让被测评单位在整改过程中把日常运维习惯改过来。否则复测过了半年之后再看大部分问题还会卷土重来。这也是为什么我一直建议整改不只是改设备更要改流程把变更审批里加上“是否影响等保合规”的检查项把新设备上线前的基线核查变成硬性动作才是高风险项真正清零的办法。