等保测评安全计算环境高风险判定实操指南

干过测评的同行都知道，等保测评高风险判定是整个报告里最让人头大的一环。测评结论最终合不合格，很大程度上就看高风险项能不能清零或者给出让人信服的整改计划。安全计算环境这一块，覆盖了网络设备、安全设备、主机设备，是现场设备数量最多、问题最密集的部分。很多单位整改到最后，剩下的高危项基本都集中在设备弱口令、明文管理、日志不开启、默认共享这类“老面孔”上。这篇文章就结合我自己做现场核查和复测的经验，把安全计算环境里高风险判定的思路、判定尺度、现场操作和容易踩的坑完整理一遍，给准备迎检的甲方、做整改的乙方和刚入行的测评工程师做个参考。

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 hotfixid

Linux主机核查常用：

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 判定研判速查表

我把安全计算环境里常见的判定场景整理成一个表格，方便现场对照使用。这个表不一定覆盖所有情形，但基本代表了我平时的主力判定口径：

这张表不能当标准答案用，它更多是一种经验参考。每个项目都要结合系统级别、网络环境和补偿措施综合判断，千万不要对着表格机械打钩。

4.4 高风险项报告书写要点

高风险判定最终要落到报告里，报告书写直接决定结论是否站得住。一个合格的高风险项描述，至少要包含四个部分：现状描述、判定依据、风险分析、整改建议。

现状描述要客观具体，不能只写“口令强度不足”，要写清楚是哪台设备的哪个账户，口令长度、组成是什么，远程登录路径是什么。判定依据要写明白引用了等保2.0的哪个条款，以及对应的判定指引内容。风险分析是报告的灵魂，要说明攻击者从哪个位置出发、通过什么路径、能拿到什么权限、造成什么后果。整改建议要具备可操作性，不是泛泛的“加强口令管理”，而是给出具体的配置命令或策略建议。

很多刚入行的测评师写报告时，现状描述写得很多，风险分析却一笔带过，这是很可惜的。整改方看到报告时，最关心的就是“为什么判我高风险”，如果风险分析写得透彻，整改方向就清晰了，复测时双方沟通也会顺畅很多。

5. 常见争议项与整改复测心得

5.1 争议高频场景的真实判定口径

先列几个我在现场被反复追问的场景：

日志留存不足6个月是不是一定判高？不一定。首先要看主机是否有审计功能开启，如果审计根本没开，又没有集中日志平台，那判高比较稳妥。如果审计已开启，日志集中到了平台，只是部分设备还没有接入到6个月的存储，那就按不符合或部分符合记录，可结合整改情况评估。

内网弱口令算不算高风险？要看网络隔离程度和系统重要性。如果一个三级核心系统，虽然在内网，但内网有大量终端、存在横向移动风险，弱口令和Windows默认共享结合，很容易被攻击者横向打穿，判高合理。反过来，一个二级小系统，物理隔离在专门机房，能接触到的只有两名管理员，弱口令就可能只记中风险。核心问题还是“路径可达性”。

没装杀毒软件但系统在封闭网段，算不算高？这取决于封闭网段是不是真的封闭。有的单位自称封闭，实际却和办公网连着，定期还有外部运维接入，那就不能说完全封闭。所以测评师不能只听口头介绍，要自己验证网络隔离措施。物理隔离、网闸隔离、严格的VLAN加ACL，是三种可信度不同的隔离方式，判定时要区分对待。

5.2 无效整改的高发原因

复测的时候，我经常看到一些“无效整改”，就是单位觉得已经改了，但复查依然不通过。最常见的原因有几个。

第一，只改了一台设备，其他设备没有同步。同一个批次的主机，往往存在同一口令、同一个配置问题，整改时只处理了抽查的那几台，复查时抽查到另一台，问题就原形毕露。所以我一直建议客户按设备类型统一整改，而不是按现场抽查名单整改。

第二，协议没换干净。比如把telnet的账号密码改了，但telnet服务本身还开着，或者SSH虽然装了但telnet没禁。整改报告上写着“已改为SSH”，实际设备配置里telnet仍在监听，复测时命令一输，立刻见真章。

第三，日志平台搭好了但数据没上去。常见现象是日志服务器地址配置了，但设备没重启，配置没生效；或者采集器只接入了网络设备，主机日志根本没往里推。这种情况平台页面上查不到对应时间段的日志，跟没整改没有区别。

第四，防病毒软件装了，但病毒库长期不更新。很多单位装上杀软就再也不管，签名库半年没动。测评时看病毒库版本和最后更新时间，一眼就能看出问题。整改不是“装个样子”，是让防护措施真正持续运转。

5.3 高风险整改的优先级建议

给乙方和甲方说句实在话，整改资源有限，不要眉毛胡子一把抓。按照我的经验，高风险整改优先级应该这么排：先处理对外暴露的设备和系统，优先改弱口令、关闭明文服务；再处理内网核心服务器，补齐补丁、禁用默认共享、加固远程登录；然后建立或完善日志集中留存机制，把审计平台打通；最后才是杀软部署、配置加固、策略优化这类工作。

这样排序的道理很简单：外部暴露面是最快被打穿的口子，先把它堵上；内网核心资产是攻击的第二目标，在横向移动阶段需要重点防；日志审计属于事后追溯和合规兜底，越早建越好，但相比前两件事，它不直接阻止攻击发生。很多单位一上来就买日志平台，花了不少钱，但弱口令还没改，等于把消防通道做好了，灭火器没买。

另外，整改之后一定要留证据。配置截图、命令输出、日志平台上的查询记录、补丁安装列表，能留的都留好。复测时测评师一扫这些证据就能确认，不需要重新跑一遍全量检查，整个流程会快很多，争议也少很多。

写在最后的经验之谈

做测评这几年，我最深的体会是：百分之八十的高风险项并不来自什么高深漏洞，而是基础配置缺失。一个口令台账、一份配置模板、一个真正生效的日志平台，就能把绝大多数高风险项消掉。测评发现问题只是第一步，关键是让被测评单位在整改过程中把日常运维习惯改过来。否则复测过了，半年之后再看，大部分问题还会卷土重来。这也是为什么我一直建议整改不只是改设备，更要改流程：把变更审批里加上“是否影响等保合规”的检查项，把新设备上线前的基线核查变成硬性动作，才是高风险项真正清零的办法。