强制执行定期账号口令变更需覆盖三类高危账号并落地系统级策略：本地管理员、服务/数据库账户、云平台高权限子账号；通过gpo、pam、数据库插件等强制实施；闭环验证改密真实性；联动iam治理离岗账号。
强制执行定期账号口令变更，不是简单设个90天过期就完事。关键在于策略能落地、不被绕过、不引发运维抵触，同时真正切断长期授权带来的横向渗透和权限滞留风险。
明确哪些账号必须纳入强制轮换范围
不能只盯普通用户。以下三类账号必须100%覆盖：
- 本地管理员账户（RID=500）：包括隐藏的Administrator克隆账户，需通过SID比对+注册表SAM路径交叉验证；
- 服务账户与数据库账户：如SQL Server的sa、MySQL的root、Redis的默认admin、Tomcat后台管理账号等，这些常被忽视但权限极高；
- 云平台高权限子账号：阿里云RAM中拥有“AliyunAdminAccess”或自定义含sts:AssumeRole权限的角色凭证，必须同步轮换其AccessKey及登录密码。
用系统级机制代替人工提醒
依赖员工自觉修改口令等于不设防。应启用底层策略强制阻断：
- Windows域环境：通过组策略（GPO）配置「密码必须符合复杂性要求」「密码最长使用期限=90天」「强制密码历史=5」，并勾选「用户无法更改密码」（仅限服务账户）；
- Linux服务器：在/etc/login.defs中设置PASS_MAX_DAYS 90、PASS_MIN_LEN 12、PASS_WARN_AGE 7，并配合PAM模块pam_pwquality.so校验字符组合；
- 数据库层面：MySQL启用validate_password插件，Redis强制requirepass且禁止空口令，Tomcat conf/tomcat-users.xml中密码字段须经SHA-256哈希存储。
闭环验证改密动作是否真实生效
很多单位扫描显示“已整改”，实则用相同强密码反复覆盖——这仍是弱口令。验证要点：
- 使用wmic useraccount list full + 密码最后修改时间字段，比对两次改密间隔是否真达90天；
- 调用弱口令检测系统（如派拉软件方案），对AD/LDAP/DB做密文比对，确认新密码未落入200万明文库或语义变体库；
- 对关键系统（如核心数据库）执行登录测试：用旧口令尝试失败、新口令一次通过，且会话无缓存复用痕迹。
配套处置离岗与权限交接漏洞
轮岗、离职导致的“僵尸账号”是最大盲区。单靠口令轮换不够，必须联动身份治理：
- 接入IAM系统，账号状态变更（禁用/删除）触发自动清空密码哈希、注销所有活跃会话、回收SSH密钥与API Token；
- 营业网点等多人共机场景，启用xcad终端管控，实现“人走账清”——离岗后自动登出所有业务系统，且下次登录需重新绑定组织角色；
- 审计日志中重点筛查同一账号在不同IP、不同时间段的高频登录行为，识别共享账号或代管行为。
