麒麟V10等保密码策略配置：从PAM到登录锁定完整指南

1. 等保测评到底查什么：先弄清密码策略的“及格线”

干过等保测评这档子事的人都知道，密码策略是每次检查里的“铁打的考点”。测评师打开服务器第一件事，就是看密码策略配了没有、配得够不够，三项硬指标跑不掉：密码长度和复杂度、密码有效期、登录失败处理。你要是拿一台默认安装的麒麟系统直接送检，大概率会被写进整改项，因为默认配置离等保要求确实有明显差距。

先说等保2.0里对密码这块的核心要求。三级系统通常要求密码长度不少于8位，并且同时包含大小写字母、数字和特殊字符中的至少三类；密码有效期建议不超过90天，有的行业标准会要求60天甚至30天；登录失败处理要求连续输错一定次数后锁定账号，比如5次锁定30分钟，同时要有解锁机制。听起来简单，但落到麒麟系统上，涉及的不只是改一个配置文件，而是PAM（可插拔认证模块）、系统账户策略、用户登录流程这好几层的东西，哪一层没照顾到，测评师一测就露馅。

还有个容易被忽略的点，就是“密码不得与用户名相同”和“新密码不得与历史密码相同”。这两条在等保测评里也经常被抽查。测评师会尝试把密码设成用户名、或者把刚改过的密码再改回去，如果系统放行了，这就是一个明显的控制缺失项。所以配置的时候，不光要盯长度和复杂度，历史记录和相似性检查也得一并处理。

说白了，给麒麟服务器配置等保密码策略，本质上就是回答一个问题：当账号被暴力破解、密码被猜中、或者内部人员试图复用旧密码的时候，系统能不能扛得住、拦得下、记下来。把这个问题拆解清楚了，配置思路自然就有了。本文用的环境是麒麟V10 SP1/SP2服务器版，基于ARM64或x86_64架构都适用，操作路径基本一致。

2. 动手前先摸清家底：麒麟系统的PAM体系与配置文件

初次接触麒麟服务器的朋友，最头疼的就是不知道改哪个文件。这里我必须先把麒麟系统和CentOS/RHEL的异同点讲透，因为网上很多教程是基于CentOS 7写的，直接照搬在麒麟上大概率会翻车。

麒麟V10虽然是国产化操作系统，但它的底层确实和RHEL系有很深的血缘关系，很多基础配置思路相通。然而版本不同，PAM模块的调用方式已经发生了变化。老一点的系统用的是pam_cracklib.so，新一点的系统已经默认换成了pam_pwquality.so，麒麟服务器版实测用的是后者。你如果拿着老教程去改cracklib，配置文件虽然也能读，但实际生效的是另一套逻辑，白白浪费排查时间。

需要关注的文件，我整理成一张清单：

注意看这个表里有两个PAM配置文件：system-auth和password-auth。很多教程只改system-auth，结果SSH登录的时候还是老策略，原因就是SSH走的是password-auth。更稳妥的做法是两边保持一致的配置，或者用include方式统一引用。

另外，麒麟系统还兼容/etc/pam.d/common-password这类Debian系的文件路径，但默认不会用到，这里不展开。实际操作中，你只要记住一个判断原则：先看系统版本，再确认PAM模块文件是否存在，最后修改对应的配置文件。

修改之前务必备份。这个动作看似多余，实际是救命稻草。我自己就遇到过因为PAM配置写错导致所有用户都无法登录的情况，最后是靠单用户模式进去改回来的，折腾了快40分钟。所以请务必先执行：

cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak.$(date +%F) cp /etc/pam.d/password-auth /etc/pam.d/password-auth.bak.$(date +%F) cp /etc/security/pwquality.conf /etc/security/pwquality.conf.bak.$(date +%F) cp /etc/login.defs /etc/login.defs.bak.$(date +%F) cp /etc/security/faillock.conf /etc/security/faillock.conf.bak.$(date +%F) cp /etc/security/pwhistory.conf /etc/security/pwhistory.conf.bak.$(date +%F)

还有一个值得提前确认的点：是否已安装pwquality相关模块。麒麟V10默认装了，但如果你是在精简安装模式下部署的服务器，可能没有。检查命令：

rpm -qa | grep pwquality

如果没有输出，用yum install -y libpwquality装上再继续。这一步不提前做，后面配置了pwquality.conf也不会生效，因为PAM模块根本不存在。

3. 手把手配置：从长度复杂度到锁定策略的完整落地

3.1 密码长度与复杂度：核心中的核心

密码长度和复杂度的配置入口是/etc/security/pwquality.conf。这个文件里的每一行默认都是注释状态，意味着使用系统内置的默认值。我们可以通过取消注释并修改参数来定制规则。

我的建议是配置以下内容：

minlen = 12 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 minclass = 3 maxrepeat = 3 difok = 5 enforce_for_root

逐个解释一下这些参数。minlen = 12是密码的最小长度，等保要求至少8位，为什么我建议12？因为如果复杂度要求高，纯8位密码的排列组合在暴力破解下并不安全，而且测评师看了也舒服，直接超出预期。dcredit、ucredit、lcredit、ocredit这四个参数分别控制数字、大写字母、小写字母、特殊字符的最少个数。设成-1表示必须至少包含1个，正数表示最多允许几个，默认逻辑比较绕，记住-1就是“强制包含1个”即可。

这里有个容易踩的坑：很多教程只设定了dcredit = -1，却忘了ucredit、lcredit、ocredit，结果系统只强制数字和字母，复杂度的实际达标程度就不足。等保要求“三类以上”，建议把四类全设为-1，一次性满足最高要求。

minclass = 3表示密码中至少要包含3种字符类别，这是等保的直接对应项。maxrepeat = 3限制连续相同字符不超过3个，比如1111、aaaa这种就会被拒绝。difok = 5表示新密码与旧密码至少要有5个字符不同，这是为了防止用户仅仅在旧密码后面加个“1”就糊弄过去。enforce_for_root这个参数很关键——它强制root用户也遵守同样的密码策略。默认情况下root是不受复杂度限制的，但等保测评会专门测root密码，所以必须加上。

修改完成后，可以用下面这个命令测试密码强度评估器是否正常工作：

echo "Test@12345" | pwscore

如果返回一个分数而不报错，说明模块正常。如果提示password quality check failed，就要回头检查参数格式。

3.2 密码有效期与警告：让密码“会过期”

/etc/login.defs里控制密码老化的参数有四个核心项：PASS_MAX_DAYS、PASS_MIN_DAYS、PASS_MIN_LEN和PASS_WARN_AGE。其中PASS_MIN_LEN在这里已经不太起作用了（长度由PAM的pwquality管），但其余几个仍然非常重要。

建议配置：

PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_MIN_LEN 12 PASS_WARN_AGE 7

PASS_MAX_DAYS 90表示密码最长使用90天，到期必须修改，这是等保对密码有效期的最常见要求。PASS_MIN_DAYS 7表示密码最短使用7天后才能再修改，防止用户一天之内反复修改密码，绕过历史记录检查。PASS_WARN_AGE 7表示密码过期前7天开始提醒用户修改，用户体验会好很多。

只改login.defs不会对已有用户立即生效。这里要特别提醒：login.defs只作用于“新创建的用户”的默认值，已经存在的用户要单独处理。你需要用chage命令逐个调整，或者批量执行：

chage -M 90 -m 7 -W 7 用户名

如果用户数量多，可以用循环批量处理：

for user in $(awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd); do chage -M 90 -m 7 -W 7 "$user" done

这条命令的意思是：遍历/etc/passwd中UID在1000到65534之间的普通用户，把他们的密码有效期、最小修改间隔、提前警告天数统一设置好。执行完可以用chage -l 用户名查看结果，确认配置已生效。

3.3 密码历史与相似性：防止“换汤不换药”

等保测评中有一个点经常被专门测试，就是旧密码复用。测评师会先把密码改成“Test@12345”，然后马上改回“Old@12345”，如果系统接受了，就说明没有配置历史记录检查。

麒麟系统里这个功能由pam_pwhistory.so模块实现。配置文件是/etc/security/pwhistory.conf，建议修改为：

remember = 5 enforce_for_root

remember = 5表示系统记住最近5次的历史密码，新密码不能与这5个中的任意一个相同。enforce_for_root同样是为了让root也遵守规则。

但光改这个文件还不够，关键是确保PAM配置里真的调用了这个模块。检查/etc/pam.d/system-auth和/etc/pam.d/password-auth，确认password字段部分包含类似这样的一行：

password required pam_pwhistory.so use_authtok

如果没有，需要手动加在pam_pwquality.so这一行的前面。PAM模块的执行顺序很重要，pam_pwhistory.so要放在pam_pwquality.so之前，因为先要检查历史记录，再检查密码质量，顺序反了很可能导致模块被跳过。

另外还需要在/etc/security/pwquality.conf里设置difok = 5，也就是前面说的新旧密码至少5个字符不同，这样用户把旧密码从“Abc@12345”改成“Abc@12346”也是不行的，因为差异字符只有1个。历史记录和相似度检查双管齐下，才算是真正堵住了“糊弄式改密”的口子。

3.4 登录失败锁定：给暴力破解装个“刹车”

密码策略配得再严，如果账号可以被无限次尝试密码，等于没锁门。等保要求必须有登录失败处理机制，常规做法是连续失败5次锁定30分钟。麒麟系统使用pam_faillock.so模块实现。

首选项配置文件是/etc/security/faillock.conf，建议配置：

deny = 5 unlock_time = 1800 fail_interval = 900 even_deny_root

含义是：连续5次认证失败后锁定账号，锁定时间1800秒（30分钟），统计窗口900秒（15分钟）。even_deny_root表示root账号也受此限制，这是等保测评的高频检查点，有些单位担心root被锁进不了系统，会选择不加这个参数，但测评的时候可能会被提整改意见。我的建议是加上，因为锁定的只是登录认证，你完全可以通过物理终端、带外管理或者单用户模式进入系统，并不存在真正的“进不去”。

同样地，光改配置不够，必须确认PAM配置里引用了pam_faillock.so。在system-auth和password-auth中，auth段应该有类似这样的三行：

auth required pam_faillock.so preauth auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc

这三行的作用分别是：认证前检查是否已锁定、认证失败时记录失败次数、认证成功时清除失败记录。三个是配套的，缺一个都会导致逻辑不完整。

配置完以后，用faillock --user 用户名可以查看某用户的失败记录，faillock --user 用户名 --reset可以手动清除锁定状态。这在测试和排障时非常有用，比重启服务方便多了。

3.5 检查PAM配置的整体完整性

这一步是最关键也最容易出错的地方。修改完上述配置后，一定要检查/etc/pam.d/system-auth和/etc/pam.d/password-auth两个文件的完整结构。以system-auth为例，password段最终应该是类似这样的：

password requisite pam_pwquality.so try_first_pass local_users_only password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_pwhistory.so use_authtok

注意顺序：pam_pwhistory.so在pam_unix.so之前，pam_pwquality.so在最前面做质量校验。如果顺序乱了，比如pam_unix.so先执行并通过了，后面的历史检查根本不会运行，配置等于白做。

用下面这个命令可以快速检查PAM配置语法是否正确：

pam-config --check 2>/dev/null # 或者直接查看文件内容 cat /etc/pam.d/system-auth

如果麒麟系统没有pam-config命令，直接cat查看内容人工核对也行。修改完PAM配置后，不需要重启服务，因为PAM是每次认证时动态读取配置的。但不建议远程改完马上断开连接，最好先开一个新的SSH会话测试登录，确认没问题再退出当前会话。这一条是无数运维老手用血泪换来的教训。

3.6 强制存量用户马上改密：让策略对所有人都生效

前面提到过，新策略只对新用户生效，老用户如果密码已经不符合要求，就变成了“策略管不到”的漏网之鱼。等保测评时，测评师会专门抽查现有用户的密码属性，发现密码还有200天过期、或者密码强度明显偏弱，那就会记一条整改。

所以配置完策略之后，还有一个重要动作：让所有存量用户在下次登录时强制修改密码。

chage -d 0 用户名

-d 0的意思是把用户的密码最后修改日期设为0，也就是“密码已过期”，用户下次登录时会被强制要求设置新密码。批量执行：

for user in $(awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd); do chage -d 0 "$user" done

执行这条命令之前一定要确认你对所有普通用户都是清楚管理的。如果有某个服务账户、应用程序账户也被强制改密了，可能导致服务起不来。比如有些系统里的oracle用户、mysql用户就是服务账户，把它们也设成-d 0，下次服务重启时就麻烦了。最稳妥的做法是先列出来看看：

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd

逐个确认哪些是真人账户、哪些是服务账户，只对真人账户执行强制改密。这也是为什么我建议在配置文档里维护一张“账户用途对照表”，账户管理规范化之后，很多安全策略的落地都能少走弯路。

4. 验证与排查：配置完了不等于“过检”

4.1 用实测说话：弱密码能不能被拦住

配置工作全部做完之后，一定要实际测试，而不是只看配置文件就算完事。等保测评师最喜欢干的事就是“现场试一遍”，你自己先试，提前发现的问题就不至于在测评现场丢人。

测试方法很简单：新建一个临时测试账户，然后尝试用不符合策略的密码去修改。

useradd testuser passwd testuser

当你输入一个纯数字、或者只有6位的密码时，系统应该弹出类似BAD PASSWORD: The password is shorter than 8 characters的提示，并且修改失败。接着尝试输入符合要求的强密码，应该能成功。

再测试历史记录：把测试用户的密码改成“Abc@12345”，然后马上再改回“Abc@12345”，系统应该拒绝，提示密码已被使用过。如果系统居然接受了，说明pam_pwhistory.so没生效，需要回头检查PAM配置和模块是否存在。

测试完记得清理测试账户：

userdel -r testuser

4.2 登录失败锁定实测：暴力破解能不能被熔断

这个测试建议开一个SSH会话来做，做好被锁的心理准备。连续用错误密码登录5次，系统应该提示账户已锁定。你可以用另一个终端执行faillock --user 用户名查看失败次数，确认达到了5次。

登录失败锁定会带来一个运维上的麻烦：如果你自己的IP被锁了，远程就没法登录了。所以在测试前，建议确认自己有其他方式能进入系统，比如带外管理口、物理控制台，或者另一个管理账号。这也是为什么前面说even_deny_root要酌情开启，很多生产环境就是因为root被锁，运维又只有远程这一条路，最后只能跑机房。

实测时要注意：SSH的失败锁定逻辑会受sshd_config中MaxAuthTries参数影响。如果MaxAuthTries设置过小，比如默认的6次，其实在到达PAM的deny = 5之前，SSH层可能已经断开了连接。这种情况下，攻击者每次连接只能试几次密码，锁定逻辑不会被触发，反而更安全。但如果MaxAuthTries设得很大，比如MaxAuthTries 10，那么PAM的5次锁定会成为真正的拦截点。建议两者配合设置：MaxAuthTries 4+ PAMdeny = 5，这样即使攻击者换了多次TCP连接，总计失败5次后也会被锁定。

4.3 常见的坑和排查实录

整理几个我实际工作中踩过或者见过别人踩的坑：

坑一：改完配置不生效，查了半天发现PAM模块没安装。症状是pwquality.conf里配了minlen，但设置短密码照样成功。解决办法就是检查rpm -qa | grep libpwquality，没装就装上，然后重新配置。

坑二：SSH登录不走system-auth而走password-auth。很多教程只让改system-auth，麒麟系统实测发现SSH密码认证优先读取password-auth。两个文件里的PAM配置必须保持一致，或者优先修改password-auth。

坑三：配置了pam_pwhistory.so但新旧密码还能复用。原因通常是PAM模块顺序不对，pam_unix.so先执行并通过了，后面的检查根本没机会运行。把pam_pwhistory.so放到pam_unix.so之前即可。

坑四：chage -d 0把服务账户也给强制改密了。服务账户通常没有交互式登录权限，被强制改密后服务进程可能无法正常读取密码文件，导致服务起不来。解决办法是提前区分服务账户和真人账户，只对真人账户执行强制改密。

坑五：测试登录失败锁定时，把自己的管理IP锁了。这基本是每个运维都经历过的至暗时刻。解决办法：一是配置faillock.conf的local_users_only参数，让锁定只对本地账户生效；二是在测试前确认有其他通道可以进入系统；三是用fail_interval和unlock_time设置一个合理的窗口，别设成永久锁定。麒麟系统默认支持faillock --user 用户名 --reset，但前提是你还能登录进去执行命令，否则只能在带外管理口操作。

4.4 检查系统日志，确保审计可用

密码策略配置完成后，等保测评还会查“安全审计”这一项。简单来说，就是有人尝试暴力破解、或者发生登录失败事件时，系统要有对应的日志记录。

麒麟系统的认证日志在/var/log/secure，可以用下面的命令检查：

journalctl -u sshd --since today | grep -i fail # 或者 grep "Failed password" /var/log/secure | tail -20

如果有失败记录输出，说明审计日志工作正常。如果/var/log/secure里没东西，要检查rsyslog服务是否正常：

systemctl status rsyslog

日志服务挂了的话，等保测评里“安全审计”这一项会直接归到高风险，密码策略配得再完美也救不回来。另外，等保还要求日志保存时间不少于6个月，这个建议在生产环境通过配置日志转储和远程日志服务器来实现。麒麟系统自带的/etc/logrotate.d/syslog默认按周轮转，如果保存周期不够，要适当调整。

5. 配套加固：时间同步、账户清理一个都不能少

密码策略是等保测评里最显眼的一项，但不是唯一一项。测评师检查的时候，通常会顺带看账户管理、时间同步等基础安全项，而且这些项目里的某些配置，反过来会影响密码策略的测评结果。

时间同步就是一个典型的例子。如果服务器时间和真实时间偏差过大，日志记录的时间戳就没法作为审计证据，密码过期时间的计算也不准确。等保测评里通常会要求配置NTP时间同步。麒麟系统默认可能用的公网时间源，但在内网环境，必须改成指向内网的NTP服务器，否则会存在时间同步失败的风险。

# 编辑chrony配置 vim /etc/chrony.conf # 把server那一行改成内网时间服务器的地址 server 192.168.1.10 iburst # 重启chronyd服务 systemctl restart chronyd systemctl enable chronyd # 检查同步状态 chronyc sources -v

如果等保测评要求使用国密算法或者特定时间源，具体以测评方的要求为准，但至少要做到：时间同步已启用、时间源可达、同步偏差在可接受范围内。这类配置平时没人关心，测评现场一查一个准，所以提前处理好能省掉很多麻烦。

账户管理方面，检查本地账户中是否有长期不用的幽灵账户、是否有空密码账户、是否有UID为0的非root账户。这些都属于等保测评的常见检查项：

# 检查空密码账户 awk -F: '($2 == "" ) {print $1}' /etc/shadow # 检查UID为0的账户 awk -F: '($3 == 0) {print $1}' /etc/passwd # 检查近期未登录的账户 lastlog | head -30

正常输出的应该只有root一个UID 0账户。如果多出来任何一个，都是严重安全隐患，必须立即处理，删除或锁定这些账户。

另外还要检查SSH配置。/etc/ssh/sshd_config里建议确认以下参数，这也是测评师爱看的地方：

PermitRootLogin no PasswordAuthentication yes MaxAuthTries 4

PermitRootLogin no是否设置，要看你们单位的具体要求。有的单位内部运维习惯直接root登录，等保也允许通过堡垒机进行管理。但从安全角度讲，禁掉root直登、改用普通用户加sudo是更规范的做法。如果你们有堡垒机统一纳管，建议配合一起把root直登关掉。

账户锁定这个动作，在faillock里做了之后，还要注意一个细节：/etc/pam.d/system-auth和/etc/pam.d/password-auth里如果active段已经写入了pam_faillock.so，那么SSHD服务也会调用这个模块。但如果你们用的是LDAP或AD域认证，本地锁定策略对域账户可能不生效，那就要考虑在服务端（域控）侧做类似配置。这一点很多文章提都不提，实际部署中常常被忽视。

6. 等保自查清单与实用工具速查

配置做到这里，基本已经覆盖了等保对密码策略的主要要求。实操中建议做成一个自查清单，方便后续巡检和测评前自查时直接用。我整理成表格，你们可以直接抄走当模板：

运维中常用的速查命令也一并整理：

# 查看用户密码过期信息 chage -l 用户名 # 查看所有普通用户密码状态 for user in $(awk -F: '$3>=1000 {print $1}' /etc/passwd); do echo "=== $user ==="; chage -l $user; done # 查看登录失败记录 faillock --user 用户名 # 清除登录失败记录 faillock --user 用户名 --reset # 检查PAM配置里的密码策略 grep -E "password|pam_faillock" /etc/pam.d/system-auth # 测试密码强度 echo "新密码" | pwscore

这些命令在测评现场也是高频使用项。测评师让你现场演示密码强度检测时，你直接敲pwscore，比翻配置文件有说服力得多。

7. 测评现场容易丢分的小细节

等保测评除了看技术配置，还会看流程和管理制度。密码策略相关的制度文档，比如《密码管理制度》《账户管理规范》，测评师会问你们有没有。这个不在技术配置范围内，但很影响整体结果。建议提前和单位的合规部门确认一下，把制度文件补齐。

另一个容易被忽略的点是“特权账户的密码管理”。root、数据库管理员、应用管理员这些高权限账号，等保要求必须设置独立的强密码，并且不能多人共用。有的单位图省事，所有人共用一个root密码，测评师一盘问就露馅。技术上可以通过sudo配合审计来做权限收敛，操作上建议至少做到每个管理员一个独立账号，有操作留痕。

还有一个小细节：/etc/login.defs里有个USERGROUPS_ENAB参数，这个参数影响用户组行为的，等保测评一般不检查，但改的时候容易误碰。配置时要小心，别把不相关的参数也顺带改了，改多了反而容易引入新问题。

关于密码定期修改，还有一个用户引导问题：强制改密后，用户可能因为不会设置强密码而频繁找运维重置，甚至把密码写在便利贴上。给用户做一次简单的密码设置培训，教他们用“短语+特殊字符+数字”的方式记忆强密码，比单纯加严策略更管用。比如让用户取一句中文短语的拼音首字母，搭配数字和特殊符号，既好记又满足复杂度要求。这也是我在实际运维中觉得效果明显的一招。

8. 运维侧的管理建议与个人心得

配置完成只是开始，密码策略是需要长期维护的。运维侧有几件事建议纳入日常管理。

第一件事是配置变更管理。密码策略一旦上线，后续任何修改都建议走变更流程，至少要做记录。我见过一些单位，测评前改一次、测评后偷偷放宽，下次测评再改回来，这种来回折腾的模式，既增加了安全风险，也让测评失去意义。更好的做法是：把密码策略作为“安全基线”的一部分，纳入配置管理工具，比如Ansible、SaltStack，统一分发到所有服务器。这样既能保证全公司策略一致，也能在审计时提供配置变更的可追溯记录。

第二件事是巡检自动化。手工巡检一台两台还行，服务器一多就得靠脚本。可以用简单的shell脚本定期收集各服务器的密码策略配置，对比基线，发现偏差就告警。以麒麟系统为例，巡检脚本至少要检查以下几项：

# 检查PASS_MAX_DAYS grep "^PASS_MAX_DAYS" /etc/login.defs # 检查pwquality配置 grep -E "minlen|dcredit|ucredit|lcredit|ocredit" /etc/security/pwquality.conf # 检查faillock配置 grep -E "deny|unlock_time" /etc/security/faillock.conf # 检查密码过期用户 awk -F: '($3>=1000 && $3<65534) {print $1}' /etc/passwd | while read u; do chage -l $u | grep "密码过期"; done

把这些脚本放到crontab里定期执行，输出纳入日志系统，就能实现策略漂移的快速发现。

第三件事是应急解锁流程。无论策略配得多完善，总会有用户把密码输错被锁的情况。提前准备好运维侧的解锁方案：谁来解锁、怎么验证身份、解锁后如何告知用户，这些流程建议在账号管理制度里明确下来。实际运维中，faillock --user 用户名 --reset这个命令要尽快执行，同时要确认用户当前是否处于可登录状态，免得解锁完用户还是登不上。

我个人在实际操作中的体会是，密码策略配置和等保测评本质上是一个“持续合规”的问题，而不是“一次性整改”的任务。与其每次测评前熬夜改配置，不如一开始就按照基线规范配置好，后续用脚本和巡检机制持续检查，只要策略一直在线，测评时只需要提供配置截图和自查记录就行。麒麟系统这套配置我前前后后部署过不下三十台服务器，流程固定下来之后，每台机器的配置时间基本控制在二十分钟以内，省下来的时间远不止测评前的那些加班。

最后再分享一个小技巧：配置完成后，把本文提到的所有配置项和自查命令整理成一页A4纸的《密码策略配置速查表》，交给负责巡检的同事，后续交接和维护会顺畅很多。服务器运维这行，真正值钱的不是某一次配置，而是把配置固化成团队都能执行的标准动作。