–

前言：等保测评时身份鉴别最容易被扣分

在等保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.defs
PASS_MAX_DAYS   90    # 密码90天过期
PASS_MIN_DAYS   1     # 最短1天才能改
PASS_WARN_AGE   14    # 到期前14天警告

---

条款 8.1.3.1 - b

“应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。”

测评关注点：

• 失败N次是否锁定账号
• 空闲多久是否自动注销

典型整改动作：

# Linux - /etc/security/faillock.conf
deny = 5              # 失败5次锁定
unlock_time = 300     # 锁定5分钟后自动解锁
fail_interval = 900   # 15分钟内统计失败次数

# SSH超时退出 - /etc/ssh/sshd_config
ClientAliveInterval 300    # 5分钟无操作
ClientAliveCountMax 3      # 超过3次无响应断开

# Windows - 通过组策略配置
# 计算机配置 → Windows设置 → 安全设置 → 账户策略 → 账户锁定策略
# 账户锁定阈值: 5次
# 账户锁定时间: 30分钟

---

条款 8.1.3.1 - c ⭐（最容易被扣分）

“当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听。”

测评关注点：

• 是否禁用了 Telnet、FTP 等明文协议
• SSH 是否配置了强加密算法
• Windows 远程桌面（RDP）是否启用了 NLA

典型整改动作：

# 禁用Telnet
systemctl disable telnet
systemctl stop telnet

# SSH加密算法加固 - /etc/ssh/sshd_config
Protocol 2
Ciphers 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双因素为例）

在双因素认证管理平台上的操作：

1. 添加目标服务器（IP / 机器名）
2. 为服务器上的运维账号绑定OTP种子
3. 设置强制策略：该服务器所有远程登录必须双因素

用户端体验：

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.so

SSH 配置调整

# /etc/ssh/sshd_config
# 开启键盘交互认证（PAM OTP需要此选项）
ChallengeResponseAuthentication yes
UsePAM yes

# 重启SSH服务
systemctl restart sshd

验证双因素是否生效

# 尝试SSH登录
ssh admin@192.168.1.50
admin@192.168.1.50's password:   ← 第一步：输入SSH密码
Verification code:                 ← 第二步：输入OTP动态码
Last login: Thu May 21 09:00:00 2026 from 192.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条——双因素认证。很多企业完成了前三条基线加固，却在双因素认证上没有行动，结果测评结论写"不符合"。

合规改造的核心建议：

1. 优先对有远程登录权限的账号强制双因素，覆盖80%的风险
2. 利用 PAM + Credential Provider 机制，无需替换认证体系，改造成本低
3. 离线工业场景不是借口，离线TOTP + 本地代理完全可以解决

---

💬 话题讨论：你们公司的服务器登录现在用什么认证方式？等保测评时身份鉴别项有没有踩过坑？欢迎评论区交流。