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配置文件虽然也能读但实际生效的是另一套逻辑白白浪费排查时间。需要关注的文件我整理成一张清单文件路径作用优先级/生效范围/etc/login.defs定义全局密码老化规则有效期、最小天数、提醒天数对所有本地用户生效/etc/security/pwquality.conf定义密码质量规则长度、复杂度、相似性被PAM调用时生效/etc/pam.d/system-auth系统级PAM配置是密码策略的核心入口大多数认证场景会引用/etc/pam.d/password-auth密码认证PAM配置SSH密码登录时尤其相关登录场景引用/etc/security/faillock.conf登录失败锁定参数需要配合pam_faillock模块使用/etc/security/pwhistory.conf密码历史记录参数需要配合pam_pwhistory模块使用注意看这个表里有两个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 Test12345 | 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 7PASS_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: $31000 $365534 {print $1} /etc/passwd); do chage -M 90 -m 7 -W 7 $user done这条命令的意思是遍历/etc/passwd中UID在1000到65534之间的普通用户把他们的密码有效期、最小修改间隔、提前警告天数统一设置好。执行完可以用chage -l 用户名查看结果确认配置已生效。3.3 密码历史与相似性防止“换汤不换药”等保测评中有一个点经常被专门测试就是旧密码复用。测评师会先把密码改成“Test12345”然后马上改回“Old12345”如果系统接受了就说明没有配置历史记录检查。麒麟系统里这个功能由pam_pwhistory.so模块实现。配置文件是/etc/security/pwhistory.conf建议修改为remember 5 enforce_for_rootremember 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个字符不同这样用户把旧密码从“Abc12345”改成“Abc12346”也是不行的因为差异字符只有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 [defaultdie] 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: $31000 $365534 {print $1} /etc/passwd); do chage -d 0 $user done执行这条命令之前一定要确认你对所有普通用户都是清楚管理的。如果有某个服务账户、应用程序账户也被强制改密了可能导致服务起不来。比如有些系统里的oracle用户、mysql用户就是服务账户把它们也设成-d 0下次服务重启时就麻烦了。最稳妥的做法是先列出来看看awk -F: $31000 $365534 {print $1} /etc/passwd逐个确认哪些是真人账户、哪些是服务账户只对真人账户执行强制改密。这也是为什么我建议在配置文档里维护一张“账户用途对照表”账户管理规范化之后很多安全策略的落地都能少走弯路。4. 验证与排查配置完了不等于“过检”4.1 用实测说话弱密码能不能被拦住配置工作全部做完之后一定要实际测试而不是只看配置文件就算完事。等保测评师最喜欢干的事就是“现场试一遍”你自己先试提前发现的问题就不至于在测评现场丢人。测试方法很简单新建一个临时测试账户然后尝试用不符合策略的密码去修改。useradd testuser passwd testuser当你输入一个纯数字、或者只有6位的密码时系统应该弹出类似BAD PASSWORD: The password is shorter than 8 characters的提示并且修改失败。接着尝试输入符合要求的强密码应该能成功。再测试历史记录把测试用户的密码改成“Abc12345”然后马上再改回“Abc12345”系统应该拒绝提示密码已被使用过。如果系统居然接受了说明pam_pwhistory.so没生效需要回头检查PAM配置和模块是否存在。测试完记得清理测试账户userdel -r testuser4.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 4PermitRootLogin no是否设置要看你们单位的具体要求。有的单位内部运维习惯直接root登录等保也允许通过堡垒机进行管理。但从安全角度讲禁掉root直登、改用普通用户加sudo是更规范的做法。如果你们有堡垒机统一纳管建议配合一起把root直登关掉。账户锁定这个动作在faillock里做了之后还要注意一个细节/etc/pam.d/system-auth和/etc/pam.d/password-auth里如果active段已经写入了pam_faillock.so那么SSHD服务也会调用这个模块。但如果你们用的是LDAP或AD域认证本地锁定策略对域账户可能不生效那就要考虑在服务端域控侧做类似配置。这一点很多文章提都不提实际部署中常常被忽视。6. 等保自查清单与实用工具速查配置做到这里基本已经覆盖了等保对密码策略的主要要求。实操中建议做成一个自查清单方便后续巡检和测评前自查时直接用。我整理成表格你们可以直接抄走当模板检查项对应配置文件等保要求自查结果密码最小长度/etc/security/pwquality.conf不少于8位minlen12密码复杂度/etc/security/pwquality.conf至少3类字符dcredit/ucredit/lcredit/ocredit-1密码有效期/etc/login.defs不超过90天PASS_MAX_DAYS90密码历史/etc/security/pwhistory.conf不少于5次remember5登录失败锁定/etc/security/faillock.conf5次锁定30分钟deny5, unlock_time1800root纳入策略/etc/security/pwquality.conf等所有用户一致enforce_for_root存量账户改密chage -d 0全员定期改密已验证运维中常用的速查命令也一并整理# 查看用户密码过期信息 chage -l 用户名 # 查看所有普通用户密码状态 for user in $(awk -F: $31000 {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: ($31000 $365534) {print $1} /etc/passwd | while read u; do chage -l $u | grep 密码过期; done把这些脚本放到crontab里定期执行输出纳入日志系统就能实现策略漂移的快速发现。第三件事是应急解锁流程。无论策略配得多完善总会有用户把密码输错被锁的情况。提前准备好运维侧的解锁方案谁来解锁、怎么验证身份、解锁后如何告知用户这些流程建议在账号管理制度里明确下来。实际运维中faillock --user 用户名 --reset这个命令要尽快执行同时要确认用户当前是否处于可登录状态免得解锁完用户还是登不上。我个人在实际操作中的体会是密码策略配置和等保测评本质上是一个“持续合规”的问题而不是“一次性整改”的任务。与其每次测评前熬夜改配置不如一开始就按照基线规范配置好后续用脚本和巡检机制持续检查只要策略一直在线测评时只需要提供配置截图和自查记录就行。麒麟系统这套配置我前前后后部署过不下三十台服务器流程固定下来之后每台机器的配置时间基本控制在二十分钟以内省下来的时间远不止测评前的那些加班。最后再分享一个小技巧配置完成后把本文提到的所有配置项和自查命令整理成一页A4纸的《密码策略配置速查表》交给负责巡检的同事后续交接和维护会顺畅很多。服务器运维这行真正值钱的不是某一次配置而是把配置固化成团队都能执行的标准动作。