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

账号治理自查发现 47 个无人认领账号,离职 26 个月的账号还在跑财务对账脚本。根因是离职流程未联动账号停用、个人账号被用作服务凭据。拆依赖、分批停用、流程与 HR 联动后清账完成。

问题背景

公司 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 天未登录"一刀切,下次维保就会被卡住。

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

解决方案

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

根因分析

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

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

预防措施

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

总结

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

延伸阅读

使用 Hugo 构建
主题 Stack 由 Jimmy 设计