等保2.0操作系统基线检查：身份鉴别从静态密码到双因素认证的完整合规升级路径
–
前言：等保测评时身份鉴别最容易被扣分
在等保2.0三级系统测评中，身份鉴别是最高频失分项之一。
测评专家进入机房，拿起一台服务器做基线核查，敲几个命令看账号配置，如果发现仍是"用户名+静态密码"单因素认证，结果写入报告的那一刻，整改就不可避免。
更麻烦的是，这不是一两台服务器的问题——大多数企业有几十到几百台服务器，全部改造的工作量可想而知。
本文把等保2.0三级系统身份鉴别要求逐条拆解，再给出Windows 和 Linux 两套改造方案，以及离线工业场景的特殊处理方式，最后附上可直接执行的整改 Checklist。
一、等保2.0身份鉴别：4条原文要求逐条解读
等保2.0三级系统（GB/T 22239-2019）对安全区域边界和安全计算环境的"身份鉴别"要求如下：
条款 8.1.3.1 - a
“应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。”
测评关注点：
- 每个账号是否唯一对应一个人（禁止共用账号）
- 密码是否满足复杂度（长度、大小写、数字、特殊字符）
- 密码是否有有效期，是否有历史密码限制
典型整改动作：
# Linux - 配置密码策略（/etc/security/pwquality.conf）minlen=12# 最短12位dcredit=-1# 至少1个数字ucredit=-1# 至少1个大写字母lcredit=-1# 至少1个小写字母ocredit=-1# 至少1个特殊字符# /etc/login.defsPASS_MAX_DAYS90# 密码90天过期PASS_MIN_DAYS1# 最短1天才能改PASS_WARN_AGE14# 到期前14天警告条款 8.1.3.1 - b
“应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。”
测评关注点：
- 失败N次是否锁定账号
- 空闲多久是否自动注销
典型整改动作：
# Linux - /etc/security/faillock.confdeny=5# 失败5次锁定unlock_time=300# 锁定5分钟后自动解锁fail_interval=900# 15分钟内统计失败次数# SSH超时退出 - /etc/ssh/sshd_configClientAliveInterval300# 5分钟无操作ClientAliveCountMax3# 超过3次无响应断开# Windows - 通过组策略配置# 计算机配置 → Windows设置 → 安全设置 → 账户策略 → 账户锁定策略# 账户锁定阈值: 5次# 账户锁定时间: 30分钟条款 8.1.3.1 - c ⭐（最容易被扣分）
“当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听。”
测评关注点：
- 是否禁用了 Telnet、FTP 等明文协议
- SSH 是否配置了强加密算法
- Windows 远程桌面（RDP）是否启用了 NLA
典型整改动作：
# 禁用Telnetsystemctl disable telnet systemctl stop telnet# SSH加密算法加固 - /etc/ssh/sshd_configProtocol2Ciphers aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512,hmac-sha2-256 KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256条款 8.1.3.1 - d ⭐⭐（核心要求，最多失分）
“应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。”
测评关注点：
- 系统登录是否有第二因素
- 第二因素是否满足"密码技术"要求（OTP TOTP算法、USBKey数字签名均满足）
- 是否所有运维账号都纳入了双因素
这一条是绝大多数企业的整改重点。
二、双因素认证技术选型：3种路径对比
| 方案 | 第二因素类型 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| OTP动态口令 | TOTP软件令牌（手机APP） | 成本低、部署快、无硬件 | 手机丢失风险、需联网校时 | 互联网企业、中小型系统 |
| USBKey硬件令牌 | 硬件数字签名（PKI） | 私钥不可导出、抗克隆 | 有硬件成本、需安装驱动 | 金融、政务、高安全系统 |
| 硬件OTP令牌 | 独立设备显示动态码 | 无手机依赖、离线可用 | 硬件成本较高、分发管理 | 工业离网场景 |
三、Windows 服务器双因素改造方案
改造原理
Windows 登录认证通过Credential Provider（凭据提供程序）机制扩展，双因素认证的实现就是在原有密码 Provider 基础上叠加一个 OTP/UKey 验证层。
用户登录 → 输入用户名+密码 → Windows原生CP验证密码 → → 弹出第二因素验证界面 → 输入OTP / 插入USBKey → → 双因素CP验证通过 → 登录成功本地账号 + 域账号均支持
双因素认证覆盖范围 ├── 本地账号登录（控制台/RDP） ├── 域账号登录（AD域成员服务器） ├── RDP远程登录（支持NLA模式） └── 批量登录策略（组策略推送，无需逐台配置）关键配置示例（以OTP双因素为例）
在双因素认证管理平台上的操作：
- 添加目标服务器（IP / 机器名）
- 为服务器上的运维账号绑定OTP种子
- 设置强制策略：该服务器所有远程登录必须双因素
用户端体验：
RDP连接 192.168.1.100 → 第一步：输入 Windows 用户名 + 密码 → 第二步：弹窗提示"请输入动态口令" → 打开手机认证APP，输入当前6位动态码 → 登录成功四、Linux 服务器双因素改造方案
改造原理
Linux 的认证通过PAM（Pluggable Authentication Modules，可插拔认证模块）框架实现，双因素认证通过安装 PAM 模块扩展：
SSH登录 → sshd → PAM框架 → ├── pam_unix.so（验证密码） └── pam_otp.so（验证OTP动态码）← 新增模块PAM 配置示例
# /etc/pam.d/sshd# 在密码认证之后追加OTP验证auth required pam_unix.so auth required pam_otp.so# 新增：OTP二次验证account required pam_unix.so session required pam_unix.soSSH 配置调整
# /etc/ssh/sshd_config# 开启键盘交互认证（PAM OTP需要此选项）ChallengeResponseAuthenticationyesUsePAMyes# 重启SSH服务systemctl restart sshd验证双因素是否生效
# 尝试SSH登录sshadmin@192.168.1.50 admin@192.168.1.50's password: ← 第一步：输入SSH密码 Verification code: ← 第二步：输入OTP动态码 Last login: Thu May2109:00:002026from192.168.0.1五、离线工业场景：无网络时如何保证双因素正常工作
工厂车间、地铁系统、化工厂等场景普遍存在网络隔离要求，这给双因素认证带来了特殊挑战。
挑战分析
| 挑战 | 原因 | 影响 |
|---|---|---|
| OTP时间同步 | 设备离网，NTP无法同步 | 时间漂移导致OTP失效 |
| 认证服务可达性 | RADIUS/认证服务器无法访问 | 认证超时，无法登录 |
| 令牌补发 | 员工令牌损坏无法联系服务器 | 无法紧急补发 |
解决方案：离线双因素认证
核心思路：将部分认证逻辑下沉到本地，无需实时连接中央服务器。
离线双因素认证架构 ┌────────────────────────────────────────────┐ │ 工控服务器（离线） │ │ │ │ 本地认证代理（Local Auth Agent） │ │ ├── 缓存：用户账号白名单（定期同步） │ │ ├── 缓存：OTP种子（加密存储，定期更新） │ │ └── 本地验证：密码验证 + OTP验证（离线TOTP） │ │ │ │ ↓ 每天凌晨（网络窗口期）同步一次 │ │ │ │ 中央身份认证服务器（联网区） │ │ ├── 账号变更推送 │ │ └── 密钥/种子分发 │ └────────────────────────────────────────────┘关键技术点：
- TOTP（基于时间的OTP）只需时钟同步，不需要联网；离线环境保证服务器时钟精度即可
- 本地代理定期（每晚）与中央服务器同步账号变更
- 紧急情况下，管理员可通过带外通道（U盘/序列口）更新本地账号
六、等保整改 6 步 Checklist
□ Step 1 【摸底】盘点所有服务器（IP、OS、负责人、账号清单） 工具：nmap -sV 192.168.0.0/24 □ Step 2 【密码策略】所有服务器配置密码复杂度+有效期 Windows：组策略批量推送 Linux：修改 /etc/security/pwquality.conf + /etc/login.defs □ Step 3 【失败锁定】配置登录失败锁定策略 Windows：组策略账户锁定阈值=5次 Linux：配置 faillock.conf □ Step 4 【禁用明文协议】禁用 Telnet、FTP，启用 SSH/RDP-TLS 验证：ss -tlnp | grep 23 （结果应为空） □ Step 5 【部署双因素】对所有运维账号启用第二因素认证 优先级：高权限账号 > 普通账号 Windows: 安装 Credential Provider + 绑定OTP Linux: 安装 PAM 模块 + 配置 /etc/pam.d/sshd □ Step 6 【测评材料整理】 ✓ 双因素认证截图（登录时弹出OTP输入框） ✓ 认证日志导出（含时间戳、用户名、IP） ✓ 密码策略配置截图 ✓ 失败锁定测试记录七、测评时检查人员会问什么
根据实际等保测评经验，检查人员在身份鉴别项通常会做以下操作：
1. 现场演示登录（最重要）
“能否演示一下登录这台服务器的过程？”
他们需要亲眼看到第二因素认证界面弹出。只有系统配置截图是不够的，必须现场可演示。
2. 查账号清单
“能否导出所有账号的列表？是否有共用账号？”
# Linux：导出账号列表cat/etc/passwd|grep-v"nologin\|false"|cut-d:-f1# Windows：查询账号net user# 结合AD账号管理截图3. 查认证日志
“最近30天有没有认证失败的记录？失败次数超过5次的账号有哪些？”
# Linux SSH认证日志grep"Failed password\|Invalid user"/var/log/auth.log|tail-50# 双因素认证平台应能导出认证成功/失败报告4. 测试失败锁定
“我来尝试多次错误密码，看能否触发锁定。”
总结
等保2.0对身份鉴别的要求其实并不难理解，核心就是四条：唯一标识 + 复杂密码 + 防窃听 + 双因素。
最容易被忽视、也最容易被扣分的是第d条——双因素认证。很多企业完成了前三条基线加固，却在双因素认证上没有行动，结果测评结论写"不符合"。
合规改造的核心建议：
- 优先对有远程登录权限的账号强制双因素，覆盖80%的风险
- 利用PAM + Credential Provider机制，无需替换认证体系，改造成本低
- 离线工业场景不是借口，离线TOTP + 本地代理完全可以解决
💬 话题讨论：你们公司的服务器登录现在用什么认证方式？等保测评时身份鉴别项有没有踩过坑？欢迎评论区交流。