离职账号未停用：两年后还在跑定时任务

Fri, 16 Oct 2026 09:00:00 +0800

问题背景

公司 300 人上下，IT 运维 3 个人。账号体系是十几年攒下来的：AD 域账号、VPN、邮件、财务与人事业系统、监控平台、门禁……每个系统各有各的账号库，人员变动时的处理方式基本是"HR 发个消息，谁看到谁去关"。这么多年没出过大事，也就没人觉得这是个问题。

今年公司要过信息安全认证，认证机构的第一条硬要求就打在七寸上：离职人员的账号必须及时停用，且要有记录可查。IT 决定不等外审，先做一次全量账号治理自查，把家底摸清楚——这一摸，摸出了成立以来最大的一笔"账号欠账"。

故障现象

自查结果比预期难看，主要是四类发现：

47 个"无人认领"账号：AD 里处于启用状态，但在 HR 在职花名册里查无此人，最长的一个已离职 26 个月；
那个离职 26 个月的账号，三天前还有登录记录，登录来源是一台批处理服务器；
5 个共享账号（2 个 VPN、2 个监控、1 个报表）：多人共用一个账号，谁在用、什么时候用的记录都对不上人；
13 个休眠账号：90 天以上零登录，仍挂在启用状态。

排查过程

第一步，交叉核对数据源。 把 AD 的启用账号导出，与 HR 在职花名册按工号、姓名做 diff，得到"无人认领"清单。这一步本身就是第一个问题的证据：公司居然没有离职人员的账号处理台账，只能靠反向比对来还原"谁该被停"。

第二步，把无人认领账号的登录记录全部拉出来。 从域控安全日志和 VPN 日志里提取登录事件，看来源 IP 与工作站名，按来源分类：一类来自办公网个人终端，一类来自服务器（2 台应用服务器、1 台批处理服务器），剩下的查不到近期记录。分类之后风险等级完全不同：来自个人终端的，可能是"人走账号没停"；来自服务器的最麻烦——说明有东西在自动化地用它，这类账号不能直接禁用。

第三步，深挖最老的那个账号（离职 26 个月）。 顺着登录来源找到那台批处理服务器，在任务计划里找到了三个财务对账脚本——“运行账户"都是它。再翻脚本配置，连数据库的连接凭据也写在同一套配置里。为确认依赖是真实的，我们在测试环境用同样的配置复现了一遍流程，再把该账号禁用，任务登录立即失败——依赖坐实。也就是说，如果按审计要求直接把这个账号停掉，财务对账会当场断更：清理动作本身会制造一次故障。

第四步，过一遍共享与休眠账号。 共享账号访谈使用部门：6 个人在用，密码换过没有谁都说不清，更回答不了"上周三晚上那次登录是谁”；休眠账号逐个核查时也发现一个反例——其中有 1 个是设备维护商的远程账号，每季度用一次，恰好卡在 90 天窗口之外。机械地按"90 天未登录"一刀切，下次维保就会被卡住。

第五步，清点依赖、确定处置顺序。 把所有待处理账号按"是否被服务或设备依赖"分成三组：无依赖的（可直接停用）、有人使用的（先通知再处理）、有服务依赖的（先拆依赖、验证、再停用）。三类走三条不同的处置路径，顺序不能颠倒。

解决方案

先拆依赖，再停用。 三个对账脚本的凭据从离职者个人账号迁移到专用服务账号：限定只能从批处理服务器发起登录、禁止交互式登录、密码托管到凭据库定期轮换。连续跑满两个对账周期验证稳定后，离职账号才被停用。
共享账号拆分。 两个 VPN 共享账号按部门拆成个人账号并启用多因素认证；监控与报表的共享账号保留，但改为每人独立 API 凭据加只读权限，原密码入凭据库、90 天轮换。
休眠账号分级处置。 确认无人使用的 12 个直接禁用；设备维护商账号改为"按需启用"——维保前由值班开启、事后关闭，并加进变更日历。
流程固化。 与 HR 打通离职流程：离职生效通知自动生成 IT 工单，处理清单覆盖 AD、VPN、邮件、业务系统、门禁与凭据交接，IT 在 1 个工作日内完成并留痕；离职交接单新增一项——“是否有以个人身份运行的服务、脚本或定时任务”。
审计常态化。 沉淀了一个季度审计脚本：启用账号与 HR 花名册 diff（无人认领清单）、90 天未登录清单、共享账号台账核对，三张清单自动生成工单给责任人复核。

根因分析

直接根因是离职账号的停用完全依赖人工记忆和线下沟通：通知到谁、谁去处理、处理没处理，全凭自觉，既没有强制流程，也没有留痕与复核。一个账号能"活"26 个月，靠的不是什么技术漏洞，而是"以为有人会管"。

更深一层，是账号生命周期没有明确归属：HR 管人员状态，各系统管自己的账号库，而"账号状态必须随人员状态变化"这条联动规则，没有落在任何一个岗位的职责里；长期没有审计，欠账只会越滚越大。这次还暴露了一个隐蔽的坑——个人账号一旦被用作服务凭据，就等于拿到了"免死金牌"：任何清理动作前都必须先拆依赖，否则治理本身就是事故源。

预防措施

离职流程与账号停用强制联动：HR 离职单自动派发 IT 工单、逐系统核对、全程留痕，禁止只靠消息通知；
服务凭据个人账号"零引用"：脚本、定时任务、系统对接一律使用专用账号，登记台账并限定登录来源；
共享账号登记制：用途、使用人、轮换周期入册，能拆则拆，不能拆的强轮换并加审计；
季度账号审计常态化：无人认领、长期未登录、共享账号三类清单自动出，处理时限写进工单 SLA；
外部人员（维保商等）账号按需启用、用完即关，不长期挂在启用状态。

总结

这次治理最反直觉的一点是：清理账号这件事本身差点引发故障——离职两年的账号不是"忘了关"，而是被三份没人看的对账脚本"需要着"。账号治理的难度从来不在审计查得多严，而在两件事：把"人走账号停"钉进流程而不是记忆里，以及在动手停用之前，先把隐藏的服务依赖摸干净。前者防欠账，后者防误伤，两件事都做到，账号生命周期管理才算真正闭环。

凭据管理 on Zero Day Notes