焦秀文做网络安全等级保护测评这些年，我有个很直观的感受：主机安全永远是等保三级项目里扣分密度最高、整改周期最长的一块。而主机安全七八个测评点中，身份鉴别又是被卡得最狠的关口——尤其是“双因素认证”“登录失败处理”“远程管理加密”这三条，基本上十台被测服务器里有六七台都不达标。这篇文章就围绕主机安全（三级）测评来写，重点把身份鉴别相关的逻辑讲透，顺便把访问控制、安全审计、入侵防范这些连带考点一并过一遍。适合正要报测评的单位运维，也适合刚入行的测评人员对照着梳理检查项。
1. 主机安全（三级）测评的整体思路与关键逻辑
1.1 主机安全为什么是等保三级里的“重灾区”
实际工作中，很多单位在网络层面舍得投入，防火墙、上网行为管理、核心交换机都做得不错，但一到主机层面就露馅。原因很简单：网络设备是“买来即用”，主机却是一台台从老环境迁移过来的，里面积攒了各种历史账户、临时脚本、默认配置，很多服务器自装机那天起就没做过加固。等保三级测评里，主机安全控制点数量多且都要求“应”实现，任何一项不符合都会形成风险项，尤其身份鉴别类问题很容易被定性为高风险，直接影响最终测评结论。
我在测评时最怕遇到那种“业务重要但历史包袱极重”的服务器：一台机器上跑了三四个业务系统，运维账号二十几个，谁都能登root，审计日志老早就被循环覆盖。这种环境不是靠买一台新设备能解决的，必须逐台梳理、逐项整改。主机安全之所以是重灾区，就是因为它不光是技术问题，更考验单位对账号、权限、日志这些“日常琐事”的管理颗粒度。
1.2 三级主机安全的测评依据与控制点
等级保护2.0标准里，主机安全对应的是“安全计算环境”中的主机部分，核心依据是GB/T 22239-2019。三级系统的主机安全主要覆盖以下控制点：
| 控制点 | 三级要求强度 | 测评关注重点 |
|---|---|---|
| 身份鉴别 | 应 | 双因素认证、登录失败处理、远程管理加密、身份标识唯一性 |
| 访问控制 | 应 | 权限分离、默认账户处理、最小权限、默认共享收敛 |
| 安全审计 | 应 | 审计策略覆盖范围、日志留痕与保护、时钟同步 |
| 入侵防范 | 应 | 最小安装、服务端口收敛、漏洞管理、完整性检测 |
| 恶意代码防范 | 应 | 防恶意代码软件、统一管理与特征库更新 |
| 可信验证 | 宜 | 可信根对引导程序、系统程序进行验证，非硬性门槛 |
| 数据完整性 | 应 | 重要配置、日志数据完整性校验 |
| 剩余信息保护 | 应 | 鉴别信息存储空间释放、虚拟内存数据残留 |
这个表不是标准原文，是我按测评实操整理的重点。对测评人员来说，身份鉴别永远是检查流程的第一步，因为它决定了后面的访问控制、审计是否有意义。身份都验证不了，后面全是空谈。
1.3 从“身份”到“行为”的主机安全链路
我习惯把主机安全理解成一条流水线：身份标识（你是谁）→身份鉴别（怎么证明是你）→访问控制（你能干什么）→安全审计（你干了什么）→入侵防范（有没有人在搞破坏）→恶意代码防范（有没有木马在跑）。身份鉴别是这条流水线最前端的闸口，前端一旦失效，后面所有安全措施都等于在给一个未知身份的人开门。
等保三级为什么对身份鉴别提那么高要求？因为三级系统本身价值高、影响面大，攻击者一旦拿到合法身份，比花力气挖漏洞省事得多。我一个做应急响应的朋友说过，大量服务器被入侵的起点就是弱口令撞库或账号共用，而不是什么高深漏洞。所以这篇博文把“身份”两个字放在标题C位，不是没道理的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 身份鉴别：等保三级主机安全的第一道门
2.1 双因素认证：三级身份鉴别最重要的门槛
三级标准原文要求：“应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。”这句话是等保三级身份鉴别里最容易被误读的一条。很多单位看到“用户名+密码”就以为满足了身份鉴别，其实在2.0标准里，用户名只是“身份标识”，密码只是“一种鉴别因素”，两者加在一起仍然只是单因素。测评时如果只有账号口令，这项直接判不符合。
所以要满足双因素，至少要在口令之外再叠一种鉴别手段，而且最好包含密码技术类认证，比如动态口令（OTP）、USBKey证书、CA数字证书。这里我提醒一句：短信验证码在部分测评机构那里认可度并不统一，有条件还是优先上OTP或USBKey。实操中最顺手的方案是统一部署堡垒机，把服务器账号统一托管，堡垒机上启用OTP动态口令，形成“静态口令+动态口令”的组合；也可以直接在Linux上使用google-authenticator的PAM模块做SSH登录的二次校验，Windows上则通过支持TOTP的认证网关来实现。需要注意的是，双因素要区分“人”和“设备”，如果只是给终端绑MAC或固定IP，这不算双因素。
2.2 登录失败处理、超时退出与来源限制
三级要求“应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施”。常见不达标表现包括：Windows账户锁定阈值为0（永不锁定）、Linux的pam_faillock没有配置、SSH连接成功后无操作挂一整天等。
整改动作如下：
- Windows在“本地安全策略→账户策略→账户锁定策略”里设置账户锁定阈值为5次，锁定时间30分钟，重置锁定计数器30分钟。实测下来，这个配置对暴力破解有明显抑制作用。
- Linux在/etc/pam.d/system-auth和password-auth的auth段加入pam_faillock.so，参数deny=5、unlock_time=1800，同时在account段加上pam_faillock.so的预检查。
- 会话超时：Windows组策略里设置“Microsoft网络服务器：暂停会话前所需的空闲时间”为15分钟；Linux在/etc/profile里export TMOUT=600，让用户闲置10分钟自动登出。
- SSH探活：在/etc/ssh/sshd_config里设置ClientAliveInterval 300、ClientAliveCountMax 3，每300秒探活一次，连续3次无响应就断开连接。
- 来源限制：远程管理服务应当限定可信来源IP或网段，Linux可以用AllowUsers或者防火墙规则，Windows可以在“用户权限分配”里限制允许通过远程桌面登录的用户。
给个重磅提醒：改完PAM或sshd_config，必须先用sshd -t验证语法，再开一个全新的连接测试，确认没问题再退出当前会话。我在项目里见过不止一次，运维改完配置直接断连，自己把自己锁在服务器外面，最后只能去机房控制台处理，特别耽误事。
2.3 远程管理加密：SSH、RDP网关与堡垒机
这条对应标准“应能对服务器进行远程管理时采取密码技术等防护措施，防止鉴别信息在网络传输过程中被窃听”。我在测评中最常见的老问题就是telnet还是开着的，或者把远程桌面3389直接暴露在公网IP上。Windows自带的RDP虽然传输层经过加密，但不等于安全基线合规——尤其是没有做来源限制、没有做登录保护的情况下，RDP映射公网基本等于给攻击者送入口。
这里给出一个方案阶梯：
- 能走堡垒机就走堡垒机。把服务器远程管理端口统一收敛到内网，堡垒机本身启用双因素认证，既解决远程加密又解决身份鉴别。
- Linux服务器把sshd_config里PermitRootLogin设为no，限制只能用普通用户登录后再sudo提权。
- Windows服务器在有条件时用RDP网关（RD Gateway）前置转发3389端口，或者用具有加密能力的代理统一接入，不要直接暴露到不可信网络。
- 关停telnet、rlogin、rsh、tftp这些明文协议服务。检查方法很简单：Linux用netstat -an | grep 23看看有没有23端口常驻，Windows到“启用或关闭Windows功能”里确认Telnet客户端和服务器是否处于未安装状态。
2.4 身份标识唯一性、默认账号与口令策略
三级要求里身份标识的唯一性经常被忽略。测评现场常见的问题包括：服务器root或administrator账号没有分配唯一身份，所有人都知道密码，密码一改大家都不爽；业务系统共用一个服务账号，运维离职了账号还在；Windows Server把Administrator改名为Admin但没做登录限制，也没禁用Guest。
整改动作：
- 给每个运维人员创建独立账号，账号命名规则建议“部门缩写+姓名拼音”（比如ops_zhangsan），账号归个人，密码按策略自行修改。
- Windows设置“账户：管理员账户状态”为已启用、把“账户：来宾账户状态”设为禁用；对重命名后的Administrator设置强口令，并限定谁能使用。
- Linux的root无法删除，但可以设置“PermitRootLogin no”禁止远程直接登录，本地控制台保留root入口。
- 服务账号要单独管理，用独立用户跑服务，不给交互式登录权限，防止服务账号变成后门。
- 口令策略建议：密码长度至少10位以上，包含大小写字母、数字、特殊字符中三类以上，最长使用期限90天，强制密码历史5个以上。Linux里在/etc/login.defs和pam_pwquality.so中配置，Windows在“密码策略”里设置。
我把身份鉴别常见的检查点和整改动作整理成一个速查表，方便测评人员和运维使用：
| 检查点 | 常见不符合表现 | 整改动作 |
|---|---|---|
| 双因素认证 | 只有账号口令 | 部署堡垒机、OTP、CA证书等第二因素 |
| 登录失败处理 | 账户锁定阈值为0、无失败锁定 | 配置锁定阈值≤5次，解锁时间30分钟 |
| 会话超时 | 连接空闲不退出 | 设置TMOUT、RDP空闲会话限制 |
| 远程管理加密 | telnet、明文协议 | 改用SSH、RDP网关、堡垒机 |
| 身份标识唯一 | 多人共用账号 | 一人一号，账号归属到个人 |
| 默认账号 | guest启用、默认admin未限制 | 禁用、重命名、设置强口令 |
| 口令策略 | 密码过于简单、长期不更换 | 长度≥10，复杂度三类以上，90天更换 |
3. 访问控制：权限分离与最小权限在主机层的落地
3.1 权限分离不是“分组”就完事
标准里三级访问控制要求“应对登录的用户分配账户和权限”“应授予管理用户所需的最小权限，实现管理用户的权限分离”。我遇到不少单位把域管理员、本地管理员、业务管理员全塞在一个账号里，运维要装软件只能用管理员，写脚本也是管理员，结果日常操作权限和核心管理权限完全没有区分。
整改思路是：把用户分为“系统管理员”“安全审计员”“普通运维/业务用户”三类，管理员不用于日常业务操作；在敏感服务器上，甚至可以给同一人分配两个账号，一个用于日常巡检只读，一个用于变更操作。Linux下用sudo来收口，不再所有人都能su到root，而是在/etc/sudoers里按需授权，例如允许某用户仅执行systemctl restart nginx这类命令。Windows下通过本地用户组和“用户权限分配”策略实现类似效果。
3.2 文件权限、默认共享与关键目录加固
访问控制还有一个容易忽略的维度：文件系统权限和共享资源。Windows服务器上，C$、ADMIN$、IPC$这类默认共享如果没做收敛，内网里任何一个普通域用户都可能通过管理共享探到系统信息；Linux服务器上，/etc/shadow、/etc/ssh、数据库数据目录的权限如果过大，就会造成敏感信息泄露。我曾经在测评中见过MySQL数据目录设成755，导致系统上任何用户都能读取整个数据库文件，这个风险级别直接拉满。
整改时重点做这几件事：
- Windows关闭不必要的默认共享，通过注册表设置RestrictNullSessAccess=1，限制空会话枚举。
- Linux检查关键文件权限：/etc/shadow应保持600或640，属主root，属组shadow；/etc/ssh/sshd_config应保持644，属主root。
- 设置合理的umask，建议022或027，避免新建文件默认全局可写。
- 数据库、中间件数据目录严格限制属主和属组，禁止其他账户读取。
- 顺带提一下剩余信息保护：Windows开启“关机：清除虚拟内存页面文件”，Linux在删除敏感文件时考虑用shred或配置swap清理，避免鉴别信息和业务数据残留。
3.3 Linux和Windows访问控制检查清单
测评现场我一般会按下面这份清单快速过一遍，运维整改时也可以直接对照：
Linux：
- 查看UID为0的账号：awk -F: '$3==0{print $1}' /etc/passwd，如果出现非root的UID0账号，就是严重问题。
- 检查可登录用户列表和home目录权限，确认没有.rhosts、.netrc这类历史遗留文件。
- 检查sudoers配置：cat /etc/sudoers，确认不是所有用户都NOPASSWD执行所有命令。
- 检查监听端口：ss -tlnp，找出对外开放的高危端口和未知服务。
- 定期扫描全局可写文件：find / -perm -0002 -type f。
Windows：
- 查看本地用户和组：lusrmgr.msc，排查可疑账号、过期账号、密码永不过期的账号。
- 本地安全策略里“用户权限分配”，确认不是人人都有“作为服务登录”“允许通过远程桌面服务登录”权限。
- 检查默认共享状态：net share，确认不必要的共享已关闭。
- 检查关键目录C:\Windows\System32\config的访问权限是否被放宽。
- 检查登录会话和计划任务，避免存在隐藏后门账号。
4. 安全审计与入侵防范：别让日志成为摆设
4.1 三级审计要求与常见的“假审计”
三级审计要求核心是：“应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；应保护审计记录，避免受到未预期的删除、修改或覆盖；审计记录至少保存6个月。”
我最常见到的“假审计”有四种：一是Windows只开了“审核登录事件”，没开“审核账户管理”“审核进程跟踪”，后期根本查不出谁改过权限；二是Linux只依赖history命令，而history是用户级shell记录，无法覆盖系统调用和特权操作；三是事件日志被管理员手动清空而无从发现；四是日志没同步到集中平台，服务器一旦重装，历史审计全没了。
正经做法是：Windows在审核策略里把“审核登录事件”“审核账户登录事件”“审核对象访问”“审核策略更改”等设置为“成功和失败”都审核；Linux启用auditd服务，配置规则跟踪关键文件和目录，例如：
bash复制auditctl -w /etc/passwd -p wa -k user-file
auditctl -w /etc/shadow -p wa -k shadow-file
然后用ausearch -k user-file查询审计记录。审计日志要定期备份并保留至少6个月，最稳妥的方式是发到集中日志平台，避免单机日志被覆盖。
4.2 时钟同步与审计数据集中化
审计日志的时间戳如果不一致，大型攻击溯源时就乱了。测评时我会检查主机时间与标准时间的偏差，如果某台服务器时间差了十几分钟，日志对不上，问题很难定位。所以主机必须配置统一的时钟同步源，Windows用w32time服务，Linux用chronyd或systemd-timesyncd，建议指向内网统一的时钟服务器。
审计数据集中化是另一个关键点。单台服务器日志即使保留6个月，一旦磁盘满或系统崩溃，照样拿不出来。我建议通过rsyslog或syslog-ng把主机日志实时转发到日志中心，Windows用Event Log转发或第三方日志平台统一收集。堡垒机本身也有会话审计功能，但系统层面的安全日志仍然需要单独留存。这个钱不能省，真出事的时候，日志就是还原现场的唯一证据。
4.3 入侵防范：最小安装、补丁管理与完整性校验
三级入侵防范要求包括：遵循最小安装原则，仅安装需要的组件和应用程序；关闭不需要的系统服务、默认共享和高危端口；能发现已知漏洞并及时修补；对重要系统和关键程序具备完整性检测能力。
检查时我最喜欢用的几个命令是：
bash复制systemctl list-units --type=service --state=running
ss -tlnp
ps aux --sort=-%cpu | head -20
通过这三个命令能快速发现多余服务、异常端口、可疑进程。很多服务器被挖矿木马入侵后，CPU占用会异常飙升，top里能看到陌生进程名。补丁管理方面，建议每季度至少做一次漏洞扫描，高危漏洞在一个月内完成修复，如果业务无法停机，要有临时缓解措施和社会化补偿方案。完整性检测方面，Linux可以使用AIDE初始化文件基线，定期执行aide --check对比；Windows可以借助文件服务器资源管理器或专业EDR的完整性监控模块，检测到关键文件被篡改时能告警并恢复。
恶意代码防范也是这一层的内容：装防恶意代码软件，病毒库统一管理、定期更新，服务器至少每月做一次全盘扫描。如果因为性能或兼容性原因没装，要在测评时说明补偿措施，比如通过白名单机制和网络层防护来弥补，但这条在三级里通常还是要求装上。