等保2.0计算环境安全测评详解：从身份鉴别到数据备份的实战指南

1. 开头：一次真实测评中，客户对“计算环境”的误读

之前接一个三级系统测评项目时，客户信息安全负责人跟我说：“计算环境安全测评，是不是就是看看服务器杀毒软件有没有装、密码有没有改？”我当时笑了笑，没多说什么。等真到现场，光身份鉴别一个控制点，就翻出了十来个问题——某个数据库超级管理员账户口令为空、运维终端共享账号、审计日志保留不足30天。那一刻我知道，不少单位其实都没真正理解“计算环境”这四个字的边界。

这篇文章想讲的，就是等保测评里“计算环境安全测评”到底测什么、怎么测、为什么这样测。内容主要面向三类人：一是刚入行的等保测评人员，需要一个能落地的检查思路；二是负责系统整改的运维和安全工程师，希望知道哪些问题最容易扣分、怎么补最有效；三是正在准备等保测评的甲方安全负责人，看完你能提前自查，少踩一些我们见惯了的坑。我不堆条文，尽量用现场的真实案例说话。

2. 计算环境在等保2.0中的定位：从“入门口”到“家门口”

2.1 计算环境的三层含义

等保2.0的通用安全要求分成了安全物理环境、安全通信网络、安全区域边界、安全计算环境等几个层面。很多人以为计算环境就是“服务器本身”，这个理解方向对，但不够完整。在测评语境下，计算环境覆盖的范围是承载业务的所有计算载体，包括但不限于：操作系统（Windows Server、Linux发行版）、数据库（MySQL、Oracle等）、中间件（Tomcat、Nginx）、应用系统、虚拟化平台，以及网络设备上的管理接口和终端操作系统。

如果打个比方，安全通信网络关注的是“道路”是否安全，安全区域边界关注的是“小区大门”是否有门禁，而安全计算环境关注的则是“每家每户的门锁、防盗窗和屋内保险柜”。边界防得再好，一旦攻击者进入内网，计算环境就是最后一道防线。这也解释了为什么测评机构在计算环境的检查项往往最多、最细，扣分也最频繁。

2.2 测评对象的选择不是随便抽两台机器

测评对象清单的确定是有讲究的。按照测评标准，系统分为两级、三级、四级等不同等级，不同等级的检查要求不同。以三级系统为例，通常采用抽查方式，要求覆盖承载核心业务的重要服务器。实操中，测评师会结合网络拓扑图、设备清单、业务重要程度来确定范围。

我见过不少甲方在这块栽跟头：提供的设备清单里只写IP没写业务角色，有些还漏掉了测试环境和开发环境。一旦测评机构按清单抽检，发现核心业务服务器根本没在清单里，就只能临时补充，拖慢整个项目节奏。建议提前把设备清单按“业务角色、操作系统版本、数据库/中间件类型、是否面向互联网、资产价值”五列整理清楚，这既是配合测评，也是对自己资产的一次盘点。

2.3 测评依据与判定逻辑

计算环境安全测评的主要依据是GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》。在实际测评中，我们不会只对照条文做最简单的“有没有”判断，而是结合访谈、文档审查、配置核查和测试验证四种手段。判定结果分为符合、部分符合、不符合、不适用。一个控制点里如果多个要求项有缺失，通常整体判定为部分符合或不符合。

判定逻辑里有一点容易被忽略：测评不是“签字画押”，而是结合资产价值、威胁可能性和脆弱性做风险分析。举个例子，一台只在内网跑测试的后台服务器，如果缺少入侵检测能力，风险等级可能属于“中低”；但如果是面向互联网的对外应用服务器，同一项缺失很可能直接判定为高风险。所以后续整改建议也一样，越重要的系统，越要优先处理高风险项。

3. 身份鉴别与访问控制：两个最基础、也最常翻车的控制点

3.1 身份鉴别不只“改个密码”这么简单

计算环境中的身份鉴别，核心要求是“用户的身份标识具有唯一性，鉴别信息有复杂度要求并定期更换”，到了三级，还必须采用两种或两种以上组合的鉴别技术。这就意味着：密码加短信验证码、密码加UKEY、密码加动态令牌，都属于常见做法，但如果只有密码一种，三级系统直接判定为不符合。

我在现场检查Linux服务器时，第一步就是看几个文件：

• /etc/login.defs：看PASS_MAX_DAYS、PASS_MIN_LEN等参数，判断口令有效期和最短长度；
• /etc/pam.d/system-auth或/etc/pam.d/password-auth：看复杂度模块pam_pwquality是否启用，是否有pam_tally2或pam_faillock做登录失败处理；
• /etc/ssh/sshd_config：看PermitRootLogin是否设置为no，是否关闭了空口令登录。

有一次，某单位的管理员信誓旦旦说已经配置了密码复杂度策略，命令行敲chage -l也确实显示用户密码90天有效。但当我打开/etc/pam.d/password-auth，发现根本没有启用pam_pwquality，也就是说密码复杂度模块压根没生效。这种情况下，策略文件写得再漂亮也没有意义。这类“配置了但没生效”的问题，是测评现场最常见的扣分点。

Windows上同样如此，检查secpol.msc里的密码策略和账户锁定策略。“账户锁定阈值”设为0次是默认状态，但等保要求必须启用登录失败处理功能，比如连续5次输错锁定30分钟。很多管理员怕麻烦，故意把锁定阈值设成0，结果测评现场直接就亮了红灯。

3.2 双因素认证到底是“加分项”还是“必选项”

这里要专门说一下双因素。等保2.0三级要求身份鉴别采用“口令、密码技术、生物技术等两种或两种以上组合”进行鉴别认证。注意措辞是“应”，不是“宜”，所以对三级系统来说，多因素认证是硬性要求。

实测中，双因素的实现方式五花八门：有的是堡垒机加动态令牌，有的是Windows域账号配合智能卡，有的是业务系统内置TOTP动态口令。测评师不会强制你使用某一种，核心在于“鉴别手段确实有两种，且两种独立”。最怕的是甲方说“我们有动态口令”，但现场去看，动态口令模块根本没启用，或者管理员为了省事把动态口令和密码存在同一个位置，那就是形同虚设。

另外要注意，双因素通常针对远程登录和管理员账户。如果只有普通用户登录业务系统时才需要验证码，而管理员远程登录服务器用单一密码，这项照样判定不符合。所以测评前第一件事，就是把所有管理入口（SSH、远程桌面、数据库管理端口、堡垒机）全部过一遍，确保每个入口都有两种鉴别方式。

3.3 默认账户和多余账户：为什么扣分总是从这里开始

访问控制第一件事是“重命名或删除默认账户，修改默认账户默认口令”。Windows里的Administrator、Guest，Linux里的root、lp、sync等系统默认用户，还有MySQL里的root空密码、Redis服务默认无认证，都是测评机构重点检查的目标。

检查命令不算复杂：cat /etc/passwd、cat /etc/shadow、lastlog、net user。但真正难的是判断哪些账户属于“多余账户”。我在统计时，除了看账户枚举情况，还会翻最近一次登录时间、账户归属部门和离职交接记录。碰到长期未登录但归属不明的账户，整改建议一般是先停用观察一个月，确认不影响业务再删除。真要一上来就删，很可能第二天业务系统就报错了——这种情况不是没发生过。

还有一个高频问题：业务账户用root跑服务。开发人员图省事，用root直接启动Tomcat或Java应用，等于让应用程序拥有了系统最高权限。一旦应用存在漏洞被利用，攻击者拿到的就是root权限。测评整改建议里，我会明确要求新建专用服务账户，并限制该账户只拥有对应目录和配置文件的权限。

3.4 权限分离：三员分立怎么落地

权限分离的控制点分为两部分：一是“授予管理用户所需的最小权限”，二是“实现管理用户的权限分离”。很多单位的做法是，系统管理员、安全管理员、审计管理员都用一个账号，或者把三员权限集中在一个超级管理员身上，这在三级系统测评中直接被判不符合。

落地起来不太复杂：Linux上用visudo配置多个管理账号，只给各自需要的命令权限，比如安全管理员只能看审计日志，审计管理员只能审查不能修改；Windows上在本地安全策略的“用户权限分配”里做同样的事。更重要的是一套流程，比如管理员的每次操作要通过申请审批，并保留操作记录。否则，即便账户做了分离，实际上还是一个人操作所有账户，和没分离没有本质区别。

4. 安全审计与入侵防范：日志有没有用，漏洞补没补，一看便知

4.1 安全审计要求的核心是两个“全”

安全审计的控制点，一是审计覆盖要全，二是审计记录要全。“审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计”，意思是普通用户登录、管理员执行敏感命令、权限变更、登录失败等事件都应该出现在日志里。

很多Linux服务器的日志只开了syslog，但默认配置不会记录用户的命令执行细节，这就要靠auditd。用auditctl可以针对关键目录和命令配置审计规则，比如对/etc/passwd、/etc/shadow的写入行为全部记录，对/usr/bin/su、/usr/bin/sudo的执行记录审计。Windows则对应本地安全策略中的“审核策略”，至少应覆盖登录事件、账户管理、对象访问、策略更改。实测中我常常发现，Windows服务器默认审核策略虽然开着，但审核粒度不够，修改文件时没有详细记录是谁改的。

“审计记录应包含事件的日期、时间、用户、事件类型、事件结果”这句话，对日志集中管理系统是天然需求。一台服务器上的日志如果只有7天保存量，基本不可能满足等保对审计记录保存时间的要求（通用实践为6个月以上）。我见过最典型的案例：Linux服务器上/var/log/messages只有几兆大小，一看就是默认轮转策略，日志保留不到一周。整改方向是调大日志文件大小、延长保留周期，并配合集中日志平台把日志统一汇聚到独立的存储服务器上，同时做时间同步。日志时间不统一的坑也要注意，如果服务器时间偏差过大，审计记录作为证据的可用性会大打折扣，测评师在报告中也会写风险。

4.2 入侵防范：最小安装和高危端口检查

入侵防范控制点里的第一项是“遵循最小安装的原则，仅安装需要的组件和应用程序”。检查方法很直接：systemctl list-unit-files --type=service、chkconfig --list、netstat -ano或ss -lntp，挨个核对服务和端口是否与业务相关。最常见的扣分项是Windows服务器默认共享没关闭（C$、ADMIN$等），Linux服务器开启了Telnet或FTP明文协议，还有装了一堆与业务无关的组件。

远程管理限制是我一直强调的检查项。等保要求“通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制”。也就是说，远程管理不能对所有来源IP开放，应限制在运维专网或特定IP白名单内。SSH的sshd_config里可以配置AllowUsers和Match Address，Windows防火墙也可以限制远程管理的来源地址。有的单位直接把数据库的3306端口暴露到公网，这是测评中的高风险问题，整改起来也相对简单——数据库服务只绑定内网IP，或者通过运维跳板机访问。

输入有效性校验这一项，很多人觉得是纯开发层的事，但测评会检查应用系统是否能抵抗SQL注入、跨站脚本等注入攻击。落到纸上，通常通过代码走查或渗透测试来验证。等保测评本身不完全等同于渗透测试，但会结合测试结果分析应用层脆弱性。

4.3 漏洞管理：补丁“及时更新”怎么判断

“应能发现可能存在的已知漏洞，并在经过充分测试评估后及时修补漏洞”这一项，测评现场一般结合扫描结果判断。通用的做法是使用漏洞扫描工具对内网资产做一轮扫描，再结合厂商安全公告记录确认补丁修复情况。

这个控制点最常见的争议是“什么算及时”。行业通常参照风险级别，高危漏洞建议在发现后1个月内修复，中危建议3个月内修复，低危可以在一个维护周期内处理。如果漏洞扫描发现某台Web服务器存在已知高危漏洞，但补丁已经安装了，只是没来得及更新到扫描报告里，这种可以和测评师沟通补充证据。反过来，如果扫描报告显示大量高危漏洞且存在时间超过半年，这一项基本就是“不符合”。整改建议里，除了打补丁，还要建立常态化的漏扫机制，比如每季度做一次扫描，每次重大安全通告后做一次针对性检查，并把结果留档，这本身就是测评证据的一部分。

5. 恶意代码防范与可信验证：不显眼，但关系到纵深防御

5.1 防恶意代码软件不是“装上就完事”

服务器的防恶意代码检查，和终端防病毒不一样。很多单位给办公终端装了杀毒软件，但服务器上什么都没装，理由是“服务器没有外网访问，不会中毒”。这个想法在测评视角下站不住脚——内网横向传播的勒索病毒、挖矿木马，正是通过未安装防护的服务器扩散的。

检查项的重点有三处：防病毒软件是否安装、病毒库是否更新、是否定期扫描。实操中我会看版本号和病毒库发布日期，如果病毒库停留在三个月前，这项通常会判为部分符合。Linux服务器常用的免费方案是ClamAV，配合crontab做定时全盘扫描，并通过freshclam定时更新病毒库。更重要的是配置实时监控和定时任务，而不是装完就忘。Windows服务器的Windows Defender默认开启时还勉强凑合，但如果被禁用又没有其他替代方案，那就是明显的安全缺口。

5.2 可信验证：三级系统里的“可选项”，但建议认真对待

可信验证是等保2.0新增的控制点，表述为“可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证”。注意关键词是“可”，也就是三级系统里允许采用“可验证”的方式。四级则升级为“应”，变成强制要求。

测评实践中，很多单位对这个点一头雾水。常见实现是基于可信平台控制模块的可信服务器，配合BIOS/UEFI的可信启动，加上对引导程序、内核模块的度量验证。如果单位确实上了可信计算产品，我会检查设备是否启用了可信度量功能，有没有对应的日志管理平台。如果没上，这一项通常记为“不适用”，但在风险分析中会提示“系统引导和核心配置完整性缺乏校验机制”。我的建议是三级系统如果预算许可，可以逐步纳入可信计算试点；就算暂时不做，也要保证关键文件的完整性监测工具，比如Tripwire或AIDE，算是一个补充方案。

5.3 入侵检测与报警：重要节点必须能看到攻击痕迹

等保三级要求“应能检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警”。这里的“检测”不等同于必须部署昂贵的企业级入侵检测系统，但至少要具备入侵行为检测手段。实践中常见做法包括：启用系统自身的审计日志并结合集中告警平台，部署可检测异常行为的终端检测响应产品（EDR）、主机入侵检测产品（HIDS），或者在关键网络节点部署入侵检测系统（IDS）。

检查时会关注事件告警规则是否配置、告警是否有人响应。有些单位买了安全产品，但告警邮件没人看，这从测评角度来说就是“有工具、无闭环”。整改方向是建立值班和告警响应流程，把邮箱告警换成短信或即时通讯通知，并定期对告警记录做复盘。如果单位规模很小，哪怕用免费的OSSEC或Wazuh做主机侧检测，也比完全没有强，测评师至少能看到你的检测能力是真实可用的。

6. 数据完整性与备份恢复：三级系统拉开差距的地方

6.1 传输和存储的完整性与保密性，靠密码技术落地

等保二级对数据安全的要求相对基础，三级开始明确要求“采用密码技术保证重要数据在传输过程中的完整性和保密性，同时保证重要数据在存储过程中的完整性和保密性”。这句话落地到测评就是两件事：传输链路加密和存储数据加密。

传输层面的检查很好做：看业务是否使用HTTPS/SSH/IPSec，看是否强制跳转HTTPS，看数据库连接是否走加密协议。有的系统平时用HTTP，只在登录页套了一层HTTPS，登录后的会话直接明文传输，这种在风险分析和渗透测试中基本是一抓一个准。还有的业务系统连接数据库时，配置文件里的口令是BASE64编码，这根本不算加密，测评报告中会明确指出算法强度不足。

存储层面会看数据库是否启用了透明加密（TDE）、磁盘是否全盘加密（LUKS/BitLocker）、备份文件是否加密。更重要的是完整性校验，比如文件哈希校验、日志文件的签名保护。我听某位客户讲过，他们给备份磁带做了加密，但数据库文件本身在磁盘上还是明文存储，测评时被提示“核心数据库数据可被直接读取”。整改方式通常是给核心数据库启用TDE，或者对存放数据文件的目录做应用层加密。这类改动对性能有影响，需要做好评估和回滚方案。

6.2 备份恢复：从“本地一份”到“异地+热冗余”

备份恢复控制点在不同等级下的要求差异非常明显。二级系统要求本地数据备份与恢复，备份数据至少保存一份，恢复范围至少包括系统盘和应用盘。三级系统在保留本地备份的基础上，还要求利用通信网络将重要数据定时批量传送至备用场地，也就是异地备份，并且主要数据处理系统要提供热冗余以保证高可用性。

现场检查时，我最常发现的三个问题：

• 备份内容不全：只备份了数据库，没备份系统配置、应用配置和关键脚本，真要恢复，系统未必起得来；
• 备份介质与服务器同处一地：其实从等保角度看，只要备份存储和主数据存储物理位置不同，才算真正的异地；有的单位把备份数据放在同一台服务器的另一块硬盘上，只能算本地备份；
• 缺乏恢复演练：备份策略写了一大堆，但恢复演练记录一张纸都拿不出来。

针对三级系统整改，异地备份建议用rsync或者备份软件做定时批量传输，数据量大的可以考虑增量同步；热冗余则根据业务重要性选择双机热备、负载均衡集群或数据库主从模式。恢复演练别光做桌面推演，要定期做真实的还原测试，并保留演练报告。测评机构看的是“可恢复”，不是“应该能恢复”。

6.3 剩余信息保护：删除不等于彻底清除

剩余信息保护是测评时大家关注较少但很容易出问题的一个点。它要求鉴别信息和敏感数据所在的存储空间，在释放或再分配给其他用户之前必须被完全清除。为什么会有这条要求？因为大多数文件系统和数据库的“删除”只是删除索引或标记，数据本身还残留在磁盘上，用专业工具可以直接恢复。

测评现场的检查思路是这样：看有没有完整清除工具，比如Linux下的shred、Windows下的磁盘擦除工具；看有没有自动清除策略，比如数据库重建表空间、日志文件定期清理；看虚拟机镜像和快照里的敏感数据是否处理到位。有一次，某单位因为服务器退租，没有做磁盘擦除就把机器退还给了供应商，个人敏感信息和业务配置都留在磁盘上，这在测评中被判定为高风险项。整改方向：在设备退役和存储介质报废流程里增加数据擦除步骤，并对擦除过程保留记录。

7. 测评师现场经验清单：这些坑你已经踩过

最后这部分，是我在多轮测评项目里复盘出来的一套自查清单，很多话不写在标准里，但现场几乎都会看。

7.1 测评报告里的“部分符合”往往来自不一致

同一控制点下，如果两台服务器一台达标一台不达标，测评师通常会根据重要系统的状态综合判级。以身份鉴别为例，核心业务服务器完全符合要求，但测试服务器密码策略缺失，最终结论可能是“部分符合”。整改优先级永远是把核心生产系统放在第一位，因为测评报告的风险排序是跟着资产价值走的。

7.2 测评前准备什么材料，能显著加快进度

做过测评的人都知道，材料准备得越全，现场工作时间越短。一次测评通常需要提供：网络拓扑图、设备清单（含操作系统和业务角色）、安全产品清单（防火墙、堡垒机、防病毒、漏扫工具等）、账号权限管理台账、审计日志保留策略说明、备份与恢复策略和演练记录、应急预案、补丁管理流程、上一轮测评报告和整改记录。

还有一个容易忽略的点：测评机构进场前会发一份《测评准备材料清单》，千万别等到场了再翻。有的单位材料零散存放在不同人手里，临时找要花一两天。建议指定一位熟悉整体系统的接口人，统一收集、统一提交，交流效率能高一大截。

7.3 测评结束后，不要把报告锁进抽屉

按我个人经验，测评报告里给出的整改建议往往比分数更有价值。分数只是当前状态的快照，能把报告里的高风险项逐项落地，才是真正提升计算环境安全水平的过程。尤其要注意：有一部分高分系统在做完测评后半年内就没落了，原因很简单——整改落地没有责任人、没有时间节点，也没有后续复核。如果你的单位正在准备测评，不妨从今天就开始整理设备清单、检查口令策略、拉一次日志保留周期的数据，这半小时投入，可能比你最终整改时少花一周时间。