
干过等保测评的人都有体会Windows 主机测评是整个项目里最“细碎”的一块。它不像渗透测试那样有一条攻击链可以顺着走也不像机房物理检查那样翻一遍门禁记录就能收工。测评组拿着一张检查表逐项对照 Windows 里的安全配置每一项都要给出“符合、部分符合或不符合”的结论最后还要解释清楚为什么这么判。这篇文章专门聊等保 2.0 框架下 Windows 主机测评这件事以 Windows Server 2016/2019/2022 为主也兼顾 Win10/11 终端。我会把测评前必须想清楚的定级和边界问题、身份鉴别、访问控制、安全审计、入侵防范这几个高频检查域以及整改复测时最容易被忽略的细节按现场执行顺序拆开讲。文章里给出的命令、策略路径和判定逻辑都是可以直接拿去用的。适合准备做等保自评的乙方工程师、正在整理测评材料的安全管理员以及想提前给 Windows 服务器做合规加固的运维同学参考。1. 测评前的三个关键判断定级差异、边界划定和工具准备1.1 二级还是三级定级直接决定检查力度等保 2.0 国家标准 GB/T 22239-2019 按定级结果确定了安全要求Windows 主机测评大量工作集中在“安全计算环境”这个层面而二级和三级在同一个检查项上的力度差别很大。先说最常见的影响。二级系统在身份鉴别方面要求口令有复杂度、能定期更换具备登录失败处理功能即可三级系统在二级基础上明确要求“采用两种或两种以上组合的鉴别技术”也就是常说的双因素认证如果没有部署动态令牌、数字证书、堡垒机二次认证之类的机制这个控制点直接判不符合。安全审计也一样。二级要求开启审计功能能记录用户行为和重要安全事件三级不仅要求审计还要求“审计记录留存时间不少于六个月”并且对分散在服务器上的审计数据进行集中收集和分析。这就意味着三级系统如果只靠 Windows 本地事件日志存几天没有日志服务器或平台收集审计这一项就会被打回。入侵防范层面的差距更大。三级系统需要有入侵检测和告警能力现在通行的做法是安装主机安全 Agent、态势感知插件或 EDR如果只靠 Windows Defender 裸奔测评组基本不会认可这一项符合。所以在测评进场前第一件事不是开检查表而是确认系统定级。同一个 Windows 主机二级和三级要准备的证据完全不同材料提交阶段没有搞清楚后期会因为一个控制点反复补交记录。1.2 “主机”的测评边界到底划到哪里边界问题看着简单实际操作中经常引发分歧。一台 Windows 服务器测评对象是操作系统本身还是连同上面的应用、数据库、中间件都算按等保通则应用系统层面的组件如果属于业务系统要分别按中间件、数据库的测评要求执行主机测评更多聚焦在操作系统、补丁状态、账号与权限、审计、防病毒和基线配置。有一类情况需要特别留意Windows 主机是虚拟机。虚拟机所在的宿主机、虚拟化平台、存储网络通常属于“安全物理环境”或“安全通信网络”的范畴如果定级对象的物理环境由云平台承载那么宿主机侧的安全责任由云服务商承担租户侧的 Windows 主机仍需按本篇文章覆盖的技术点测评。边界不清会让整改范围无限扩大建议测评前和测评机构确认清单把“操作系统层”和“虚拟化层”分开列清楚。另外如果主机上安装了 Web 服务、数据库服务但本次测评对象只是服务器本身那么测评报告里需要注明“测评范围不含应用层组件”否则会留下超出范围的扣分点。1.3 用命令验证不要用截图糊弄等保测评机构对证据的要求越来越严格。一个检查项只提供图形界面截图测评人员通常无法确认截图是否来自本机、是否在测评周期内。更好的做法是准备一台带管理员权限的终端用命令导出真实配置命令输出自带主机名和操作时间可信度比截图高得多。现场常用的验证命令大致如下# 导出本地安全策略包含密码策略和账户锁定策略 secedit /export /cfg C:\secpol.cfg # 查看实际生效的审计策略 auditpol /get /category:* # 查看安全日志配置 wevtutil gl Security # 查看当前共享资源 net share # 查看管理员组和用户 net localgroup administrators net user # 查看补丁安装情况 wmic qfe list brief Get-HotFix # 查看远程桌面服务启用状态 reg query HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server /v fDenyTSConnections这些命令在普通命令提示符或 PowerShell 下都能运行。建议按检查项逐条执行把输出保存到文本文件再配上whoami、hostname、date /t这样的上下文信息形成一份可供复测的“证据包”。测评单位的检查表会逐项核对这些证据证据充分性直接决定最终判定。2. 身份鉴别项口令、锁定、超时和双因素逐条检查的套路2.1 口令策略检查不要只看图形界面用命令读取生效值身份鉴别是等保测评里最先查、也最容易出结论的大类。Windows 上主要看四个子项口令复杂度、口令有效期、账户锁定策略、登录超时与远程管理鉴权方式。口令策略在“本地安全策略 - 账户策略 - 密码策略”里设置包括密码必须符合复杂性要求、密码长度最小值、密码最长使用期限、强制密码历史等。测评组一般按三级要求建议长度不少于 8 位、复杂度启用、最长有效期不超过 90 天、密码历史保留不少于 5 个。需要特别强调的是本地安全策略面板里显示的值不一定是这台机器真正生效的值。如果 Windows 主机已加入域域策略会覆盖本地策略密码策略以域策略为准。正确做法是先执行gpresult /r看是否有域策略在生效再执行secedit /export查看导出文件的PasswordComplexity、MinimumPasswordLength、MaximumPasswordAge等字段。我遇到过一台 Windows Server 2019管理员明确表示刚设置了 16 位复杂密码策略但secedit导出结果是PasswordComplexity 0原因是域策略未刷新本地策略修改后没有强制刷新组策略就重启了服务。这种情况必须用命令确认否则表面合规实际不合规。secedit /export /cfg C:\secpol.cfg type C:\secpol.cfg | findstr /i Password2.2 登录失败处理账户锁定阈值是现场最高频问题账户锁定策略在“本地安全策略 - 账户策略 - 账户锁定策略”包含三个参数账户锁定阈值、账户锁定时间、重置账户锁定计数器。按等保对“登录失败处理功能”的要求连续失败次数应有限制通常建议阈值不超过 5 次锁定时间不低于 30 分钟。这里的检查不能只看策略是否配置还要实际验证。方法是用一个测试账号连续输入错误密码超过阈值后观察该账号是否被锁定。验证完成后从安全日志里能看到事件 ID 4740账户被锁定。这套操作需要在非业务时段进行且必须使用测试账号绝对不能拿正在使用的管理员账号去试否则会把生产账号锁死影响业务。还有一个高频遗漏项登录超时自动退出。Windows 的本地控制台默认不会因为空闲而自动锁屏远程桌面服务如果不设置会话时间限制管理员断开连接后会话会一直保持。测评组对“登录连接超时自动退出”这一项通常会检查“计算机配置 - 管理模板 - Windows 组件 - 远程桌面服务 - 远程桌面会话主机 - 会话时间限制”里是否配置了活动空闲会话限制。常用的注册表验证路径reg query HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services /v MaxIdleTimeMaxIdleTime以毫秒为单位常见配置为 90000015 分钟。如果该项没配置远程会话可以长期挂住测评判定会落在“部分符合”或“不符合”。2.3 双因素认证三级系统的硬门槛落地方式要提前想清楚等保 2.0 三级标准对身份鉴别的要求里最让企业头疼的就是双因素认证。对 Windows 主机而言单纯的使用“口令 堡垒机”是否算双因素不同测评机构的理解存在差异。目前比较稳妥的落地方式有几种第一种通过堡垒机统一管理服务器登录堡垒机开启动态口令或短信验证码运维人员访问主机时先通过堡垒机的双因素认证再由堡垒机代理登录 Windows第二种在 Windows 层面对接 AD 域环境结合智能卡或 USB Key 登录第三种使用云厂商的主机安全产品开启运维审计和双因子登录。测评组认可哪种要在测评前问清楚避免花大力气部署完却不符合对方预期。如果是二级系统这一项基本不查双因素但建议账号本身满足唯一性和复杂度即可。三级系统如果暂时没有条件部署先给出整改计划测评结论最多给“部分符合”不能直接提交虚假材料。3. 访问控制项默认账号、权限分配和敏感资源 ACL3.1 特权账号最小化Administrators 组里到底有谁访问控制首先要确认特权账号范围。Windows 虚拟机或物理机上本地 Administrators 组的成员就是这台主机的“最高权限持有者”。如果本地管理员组里混入了长期不用的离职账号、第三方外包账号、甚至几个普通业务账号这一项基本就是不符合。检查命令很简单net localgroup administrators wmic group where nameadministrators get name, sid等保要求权限分离和最小权限管理员账号不能和普通账号混用。平时运维人员登录服务器用普通域账号需要提权时再切换到独立的管理员账号这个“最小化”过程要有实际配置支撑不能只在制度文件里描述。如果主机是域成员本地管理员组里通常会有“Domain Admins”这本身合理但要去核对 Domain Admins 小组成员是否精简。3.2 Guest 账户、默认管理员和隐藏共享三个老问题Windows 主机的 Guest 账户默认禁用部分装机工具或业务部署脚本会擅自把它启用。用net user guest可以看到账户状态如果显示“Active”说明账户处于启用状态必须立即禁用。Administrator 账户建议重命名。等保测评中常要求内置管理员名称不能使用默认的 Administrator即使启用了账户锁定功能自定义名称也能减少被针对性暴力破解的可能。检查时用wmic useraccount list brief查看账户名称和 SID不需要手动猜测。默认共享问题也很常见。Windows 默认会有C$、D$、ADMIN$、IPC$这类管理共享。如果业务架构中并不需要通过管理共享做远程运维建议直接关闭或把共享权限限制到必要的管理员组和来源 IP。测评组会用net share检查共享列表发现开放无必要的管理共享时会按“访问控制不到位”扣分。这里有一个真实场景某台业务服务器为了方便文件分发把 C 盘根目录共享给内部所有人权限是完全控制结果等保测评时这项被单独提出来要求限期整改。共享权限这件事测的是最小授权原则不是能不能共享而是权限边界和范围是否可控。3.3 文件系统和注册表 ACL容易被忽略的高危开口访问控制里最容易被忽略的是文件系统 ACL 和注册表 ACL。测评组会抽查 C 盘根目录、Windows 系统目录、程序安装目录的权限如果普通 Users 组对系统目录有写权限攻击者就可以通过修改 DLL 或配置文件实现持久化。用 PowerShell 快速检查Get-Acl C:\ Get-Acl C:\Windows\System32\config正常情况下Users 组对 C 盘根目录只有读取和执行权限对 system32 下大部分目录没有写权限。如果发现异常 write 权限需要进一步定位到具体目录和授权来源。注册表 ACL 检查同样重要。部分软件安装后会给 Everyone 或 Users 开放注册表项的完全控制这类问题通常出现在第三方软件安装目录和自启动项注册表路径下。由于注册表内容量巨大现场测评一般抽查高风险的 Run 键、服务项、Winlogon 键整改建议是安装软件后统一做一次注册表权限加固。4. 安全审计项审计策略和日志留存最容易被低估的部分4.1 auditpol 验证审计策略是否真正生效安全审计这一项很多主机表面看起来配置了实际却什么都没记录。测评组会打开“本地安全策略 - 本地策略 - 审核策略”查看审核账户登录事件、审核登录事件、审核账户管理、审核对象访问、审核策略更改、审核特权使用等子项。三级系统的常用配置是账户登录事件、登录/注销事件、账户管理、策略更改、特权使用、系统事件全部记录成功和失败对象访问记录成功必要时记录失败。Windows 10/Server 2016 后更推荐使用“高级审核策略配置”来细化子类目比如登录事件要区分交互式登录、网络登录、远程桌面登录。验证实际审计策略是否生效用这个命令auditpol /get /category:*重点看 Logon/Logoff、Account Logon、Account Management、Policy Change、Privilege Use、System 这几个类别确认失败和成功都被记录。很多机器图形界面明明勾选了但实际输出里是 “No Auditing”说明设置没有保存或组策略覆盖异常。4.2 日志大小、覆盖策略和六个月留存的量化计算Windows 事件日志默认最大大小有限制安全日志如果满了系统会选择覆盖旧事件或停止记录。等保三级要求审计记录留存不少于六个月如果只靠单机存储必须把日志容量计算清楚。安全日志大小建议单独提升。常见做法是设置 200MB 以上并通过“日志属性 - 日志满时存档不覆盖事件”来保留所有记录。检查命令wevtutil sl Security /ms:209715200 wevtutil gl Security输出里要关注maxSize和retention。如果 retention 表示“覆盖最旧事件”在日志量大的情况下早于六个月的记录会被自动清理这一项直接不符合。实操中更稳的是部署集中日志平台把安全日志实时转发到日志服务器或 SIEM由平台统一保存六个月以上。这样即使本机日志容量不足集中平台也能兜底。测评时会检查是否安装日志采集 Agent以及采集是否正常。4.3 通过事件 ID 判断审计是否真的在记录测评现场有个快速判断方法直接查询安全事件日志看看关键事件是否在持续产生。wevtutil qe Security /q:*[System[(EventID4624)]] /c:10 /rd:true /f:text wevtutil qe Security /q:*[System[(EventID4625)]] /c:10 /rd:true /f:text事件 ID 4624 表示登录成功4625 表示登录失败4720 表示创建用户4732 表示成员加入安全组4740 表示账户被锁定。如果查询不到任何登录事件说明审计记录没有覆盖用户行为测评判定就是不符合。另外日志中还要包含时间、用户、行为和结果这四个要素。Windows 安全日志本身就具备这些字段但应用层日志往往只有简单记录如果测评对象包含安装在 Windows 上的业务组件还要检查业务日志是否具备同等要素。5. 入侵防范和恶意代码防范补丁、防病毒、端口和基线加固核查5.1 补丁状态区分“配置了自动更新”和“已经安装”等保要求及时修补高危漏洞。测评组对 Windows 主机的补丁检查不只是看 Windows Update 是否开启还要确认最近是否安装了安全公告中披露的高危补丁。用下面的命令提取已安装补丁wmic qfe list brief /format:table Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10检查时通常关注最近 3 到 6 个月内的高危补丁是否安装。很多运行中的生产服务器长期不更新常见的理由是为了兼容业务软件但测评层面的结论就是不符合需要在报告中说明风险。如果服务器处于隔离网络无法直接连接微软更新服务器必须确认是否有 WSUS 或内部补丁分发系统并提供最近一次补丁分发记录。没有内部更新通道且长期不更新属于高风险不符合项。5.2 防病毒和主机安全 Agent安装不等于运行运行不等于在保护Windows Server 2016 之后的系统自带 Windows Defender但很多人装了第三方杀毒后Defender 会被自动禁用而第三方杀毒又因为授权过期或版本老旧停止防护。测评时先确认防护软件运行状态再检查病毒库日期。如果是 Windows Defender用 PowerShell 检查Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated如果是第三方 EDR 或主机安全 Agent检查对应的系统服务是否处于 Running 状态并让厂商提供最近一周的告警和拦截记录证明这个组件不是摆设。三级系统如果能提供主机安全 Agent 的集中管理平台截图、告警记录入侵防范这一块会拿分很稳。安装状态不是运行状态这是测评和整改中最常见的“纸面合规”。有的服务器上确实装了 Agent但服务已经被手动停止事件查看器里还有 Agent 启动失败的报错测评组只要查服务就能发现。5.3 端口和服务最小化高危端口开着再强的口令也白搭端口和服务最小化属于入侵防范的开放要求。检查正在监听的端口netstat -ano | findstr LISTENING高危端口包括 135、139、445、3389 等。如果 3389 对所有地址开放等于把远程桌面直接暴露在网络上如果 445 开放且未做防火墙限制则可能被勒索病毒利用。测评组会评估这些端口是否存在且是否对来源 IP 做了白名单限制。针对远程桌面建议在 Windows 防火墙里配置“作用域”或“远程地址”限制只允许堡垒机或管理网段连接。即使不依赖防火墙也要通过安全组、网络 ACL 限制来源。服务最小化方面检查是否有 telnet、FTP、SNMP 默认字符串等不必要服务。特别是有大量默认配置的第三方运维工具它们会安装 SNMP 服务并使用常见 community string等于给外部提交了一个管理通道。5.4 安全基线CIS 基线、加固脚本和误杀风险的平衡很多企业的 Windows 主机做了所谓“安全加固”实际就是跑了一遍网上找的加固脚本完全没有验证加固后的兼容性。测评时一查会发现某些加固项把远程桌面的 TLS 版本降级或是禁用了 WinRM反而导致运维工具不可用。推荐做法是参考 CIS Benchmark 的 Windows Server 基线逐项比对但每一项修改前先评估业务影响。重点优先关注口令策略、账户锁定、审计策略、防火墙规则、SMB 签名、不安全协议的禁用、本地管理员密码保护。如果企业环境通过金蝶和用友之类的大型业务应用修改安全选项和加密协议时需要格外谨慎建议先在测试环境验证再推生产。测评整改时间通常有限优先改等保检查项里的高危项再补加固基线的“加分项”。6. 整改、复测与证据闭环让测评结论经得起复核6.1 高频发现和快速整改清单结合以往经验Windows 主机测评的高频不符合项通常集中在以下几个方面整改优先级也按这个顺序排比较合理。检查项常见问题整改方法整改耗时口令复杂度、有效期密码策略未启用或长度不足本地安全策略或域策略设置10 分钟账户锁定阈值锁定阈值为 0可无限尝试开启锁定策略阈值不建议超过 510 分钟Guest 账户、默认 Administrator未禁用或未重命名禁用 Guest、重命名内置管理员5 分钟默认共享开放过多管理共享删除非必要共享或限制访问15 分钟审计策略未开启或只记录成功auditpol 开启关键类别15 分钟安全日志大小默认值太小无法长期留存提升日志容量配置不覆盖10 分钟日志集中留存无集中日志平台部署 Syslog/SIEM/日志服务按平台而定补丁更新长期未更新配置 WSUS 或定期打补丁按补丁量而定防病毒/EDR服务停止或病毒库过期恢复服务并更新病毒库30 分钟高危端口3389、445 任意地址开放防火墙限制来源 IP20 分钟整改时注意不要在业务高峰期动账户锁定策略和远程桌面相关配置。开启了账户锁定策略后运维人员如果连续输错密码管理员账号可能被锁定需要准备解锁预案。6.2 证据记录要形成闭环不能只留配置截图测评整改完成后机构会安排复测。复测时最尴尬的情况是当初的不符合项明明改好了结果因为拿不出过程记录测评人员不认可整改效果。我建议按检查项建一个整改台账每一行包含四个字段检查项名称、不符合原因、整改内容、整改结果验证命令输出。例如账户锁定策略的整改记录可以这样组织整改前net accounts输出“Lockout threshold: 0”整改后执行secedit /export并展示导出文件中的LockoutBadCount 5再附上触发一次误登录测试的事件 ID。复测前不要只凭印象说“已经改好了”按测评机构检查表逐项过一遍原始命令。很多整改项在 GUI 里看着已经生效但通过gpresult或auditpol读取仍可能显示旧值原因是没有强制刷新组策略或主机重启后策略未应用。执行gpupdate /force后再次验证。6.3 域环境和本地策略并存时的复测注意事项对于域成员机器复测时最容易踩的坑是策略覆盖。整改时改了本地安全策略但域策略仍在覆盖它那么net accounts读出来的还是域策略设置测评判定依然不符合。这种情况有两种解决思路一是把整改措施同步到域策略层面通过 GPO 下发二是如果域策略确实无法调整对该主机单独组织 OU 并配置策略阻止继承。域环境下还涉及密码策略归属。本地管理员账户走本地安全策略域用户账户走域密码策略。如果整改只做了一侧另一侧仍不合格现场要分清楚测评对象是本地账号还是域账号避免复查时再手忙脚乱。根据个人实际经验Windows 主机测评真正麻烦的往往不是某一个技术配置没做而是三类问题没有提前对齐域策略和本地策略到底谁说了算、双因素认证用哪种方案落地、日志集中留存平台是否已经跑起来。这三块属于一次性建设建议企业在测评进场前先解决。测评机构的检查表只是触发条件真正让整改周期可控的是平时把账号、补丁、审计、防病毒这几条基线当成常态化运维项来维护。