弱口令清单出来了，先改哪一个

结论先行：弱口令与明文口令的检测能力已经普及，出一张清单不难；难的是改。清单上的几百条不是同一类东西：人员使用的口令可以要求改，服务与中间件使用的口令被写在配置文件和脚本里，设备的默认口令改错了直接失联。按这三类分开排次序，先做「不改变业务行为」的那一批，整改才有可能一次做完。

本文只谈弱口令与明文口令的整改次序与操作前提，不谈检测工具怎么选，也不谈漏洞补丁怎么排期。

清单上的条目，其实是三类东西

三类混在一张表里排序，就会得出「按风险等级从高到低改」的结论。但风险等级只说这件事有多严重，没说改起来会不会出事。真正可行的排序要在风险之前加一个条件：改这个动作本身会不会中断业务。

服务口令：问题从来不是密码本身

服务口令之所以长期不改，原因很具体：它被写在不止一个地方。配置文件里有、启动脚本里有、另一台机器的定时任务里有、某个已经没人维护的批处理里也有。改了一处，跑起来一切正常；漏掉的那一处，只在特定时间触发。

可行的做法分四步，顺序不能调。

• 先找齐。在改之前做一次引用检索：按旧口令的字符串去查所有可访问的配置与脚本，得到一份引用清单。这份清单必须包含那台「没人记得它还在跑」的机器。
• 再申请双口令窗口。在服务端同时保留新旧两个口令一段时间，让各调用方逐步切换。这一步是让「漏掉一处」的后果从服务中断变成一条登录失败记录。
• 然后逐处替换并核对清单。每换一处，在清单上标记，标记完再进下一处。清单是这次改动的进度依据。
• 最后关掉旧口令，观察一个完整业务周期。周期要覆盖月末、批处理、对账这些低频动作——它们不在日常流量里，只在特定日子出现。

这四步的价值不在于技术难度，而在于它把一次不可控的改动，变成了一次可以中断、可以回退、可以清点的过程。

设备默认口令：改之前先确认退路

带外管理口、存储管理界面、网络设备这几类，风险等级通常很高，因为它们一旦暴露就是入口。但它们的整改代价也最高：口令改错、认证方式改错、管理地址改错，都可能直接失去访问。

操作前要确认三件事：现场有没有人能到机房里接显示器、有没有备用管理通道、当前配置有没有导出。三件事缺一件，就应当把这条排在有人值守的时段，而不是远程批量执行。批量脚本在这类设备上是风险放大器——它会把一次失误同时复制到几十台设备。

人员口令：难点在重置成本

这一类技术上最简单，但组织成本最高。改动之后，重置求助会集中出现，占满服务台。可行的做法是把范围缩小到真正需要的账号：先把长期未登录的账号停用，把共用账号拆开或取消，剩下的才要求集中改。范围缩小一半，求助量就会明显下降。

共用账号值得单独说。它的口令通常没人愿意改，因为改了要通知一群人，且改完之后没人知道新口令是什么。处理方式不是反复改口令，而是把它拆成一人一号——这件事的技术成本低，阻力全在习惯上，需要管理动作配合，不靠技术手段解决。

改完之后，怎么证明改到位了

整改报告里只写「已完成整改」是没有说服力的。可验证的交付物有三样：整改前后的清单对照（哪些改了、哪些申请了例外）、引用清单的关闭记录（每一处引用都指向新口令）、以及一次覆盖低频动作的复测结果。

例外也要留记录。确实无法整改的对象——比如厂商封闭、不支持修改口令的专用设备——应当单独列出，写明补偿性措施（网络层隔离、访问来源限制、操作留痕），而不是从清单里悄悄删掉。检查时被发现漏项，比主动申报一项例外要麻烦得多。

落地清单

• 清单先按「改动的业务影响」分成人员、服务、设备三类，再在各组内按风险排序。
• 服务口令改动前先做引用检索，产出引用清单，改完逐条关闭。
• 服务端保留新旧双口令的过渡窗口，让漏改的后果表现为登录失败而不是业务中断。
• 设备默认口令改动安排在有人值守时段，准备备用管理通道并导出当前配置。
• 人员口令先缩范围：停用长期未登录账号、拆开共用账号，再统一要求改。
• 无法整改的条目单列为例外，写明补偿性措施。
• 复测覆盖月末与批处理等低频动作，不只测日常流量。

边界与前提

三点说明。其一，本文关于口令类脆弱性检测与整改清单的描述，取自通用终端与资产安全方案的公开说明，属对行业通行做法的一般性梳理，不针对任何具体产品与项目。其二，各类设备与系统对口令长度、复杂度、双口令并存的支撑程度不同，具体操作以本项目环境实测为准。其三，整改过程涉及生产系统变更，应纳入变更流程并按前文所述的留痕要求执行。

深圳市奇摩计算机有限公司做的是服务这一端，这类整改通常作为合规类项目的一部分交付：清单、引用关系、例外记录、复测结果四项一起交，不停在「已整改」三个字上。预约咨询，可以先拿一份现有清单按这三类分一遍。