2025 年 2 月 18 日下午 4:50，一场解雇会议结束。
约 6 分钟后，前 IT 承包商 Muneeb Akhter 开始访问并删除其原公司维护的美国政府数据库。政府材料称，大约 1 小时内，约 96 个数据库被删除；他还下载了 1,805 个美国平等就业机会委员会（EEOC）文件，并获取至少 450 人的联邦税务信息。
这件事最反常的地方，不是“被解雇后报复删库”。反常的是，Sohaib Akhter 的 VPN 和 Windows 账号已经停用，Muneeb 的账号却被遗漏。
一个账号没关，整套安全流程就被拖进实战。
6分钟窗口，怎么变成96个数据库被删
Muneeb 与 Sohaib Akhter 是一对双胞胎兄弟。两人并不是第一次卷入计算机犯罪。
2015 年，他们均曾在弗吉尼亚因电信欺诈和计算机相关犯罪认罪并服刑。Muneeb 被判 3 年，Sohaib 被判 2 年。后来，两人重新进入科技行业，并先后受雇于同一家为美国联邦客户提供软件和服务的华盛顿公司。
按政府说法，事发前已有异常信号。
2025 年 2 月 1 日，Muneeb 要求 Sohaib 提供一名 EEOC 公共门户投诉人的明文密码。起诉材料称，Sohaib 通过数据库查询取得密码并交给 Muneeb。材料还称，Muneeb 收集了约 5,400 组用户名和密码，并写 Python 脚本在万豪、DocuSign、航空公司等网站测试登录。
关键节点可以压成一张表：
| 时间 / 节点 | 发生了什么 | 暴露的问题 |
|---|---|---|
| 2015 年 | 两兄弟因电信欺诈和计算机相关犯罪认罪服刑 | 高权限岗位的背景审查和授权边界应更谨慎 |
| 2025 年 2 月 1 日 | 政府称两人涉及获取明文密码、收集账号并测试登录 | 账号、密码和数据库查询权限已有异常使用迹象 |
| 2025 年 2 月 18 日 4:50 pm | 解雇会议结束 | 敏感岗位停权不应等到会后补做 |
| 约 4:56 pm | Muneeb 用仍有效账号访问政府数据库 | 一个漏停账号足以绕过离职流程 |
| 约 1 小时内 | 政府称约 96 个数据库被删除，EEOC 文件和税务信息被获取 | 备份能恢复数据，不等于泄露和停摆不存在 |
这里要区分两件事。
原文提到，Muneeb 曾表示“他们可以从昨天恢复”，指向前一天的日常备份。这说明数据库未必永久丢失。不能把它写成政府数据全部不可恢复。
但也不能因此轻描淡写。
恢复要时间。业务会中断。日志如果被清理，取证成本会上升。文件和税务信息一旦被复制，备份也没法把泄露撤回。
受影响最直接的，是两类人。
一类是政府客户和外包管理团队。他们要回答：承包商为什么能持有这些权限？离职时谁确认权限已经撤完？备份恢复之外，数据外泄怎么通知和补救？
另一类是企业安全与 IT 运维负责人。他们不能只把这事当成别人的事故复盘。只要公司有承包商、有外包运维、有共享数据库权限，同样的洞就可能存在。
AI不是主因，失败的是权限和日志
案件里有个容易跑偏的细节：Muneeb 曾向 AI 工具询问，删除数据库后如何清除 SQL Server 系统日志，以及如何清除 Windows Server 2012 的事件和应用日志。
这不等于“AI 导致删库”。从目前材料看，AI 更像被用来查询清痕方法的工具。真正决定事故规模的，仍然是账号、权限、日志和终端控制。
更具体地说，至少有三道关口没扛住。
| 关口 | 本应怎样 | 案件暴露的风险 |
|---|---|---|
| 解雇停权 | 通知前完成 VPN、Windows、数据库、云平台等账号冻结 | Sohaib 账号停了，Muneeb 账号被遗漏 |
| 最小权限 | 承包商只拿完成任务所需权限，高危操作受限 | 一个账号可连续删除大量数据库 |
| 日志与终端 | 清日志、重装设备、批量导出触发告警和留痕 | 政府称两兄弟随后在未具名共谋者帮助下重装公司笔记本系统 |
这里的现实约束也要讲清。
很多组织的离职流程不是一个按钮。VPN 在一个系统，Windows 域账号在一个系统，数据库账号、云控制台、代码仓库、工单平台又在别处。承包商还可能有临时账号、共享凭据、服务账号和客户环境权限。
难点就在这里。
安全团队不能只相信“人事已经通知 IT”。高权限岗位离职，应该变成一张可核验的变更单。每个系统谁停、何时停、停到什么状态，要能回查。
对运维负责人来说，动作要更具体。
敏感岗位解雇应按“先冻结、再通知、后交接”执行。VPN、Windows、数据库、云控制台、代码仓库、工单系统和备份系统要放进同一张停权清单。
对 SQL Server 这类生产数据库，DROP DATABASE、批量导出文件、清日志、异常脚本登录，都应触发实时告警。高危命令最好需要二次授权，或者走 break-glass 机制，并强制留痕。
这不是多写几条制度的问题。制度如果不能在 4:50 到 4:56 之间生效，就等于没有挡住最关键的 6 分钟。
法律进展要分清，接下来盯三件事
这起案件的法律状态不能混写。
Muneeb 已在 2026 年 4 月签署认罪协议，承认起诉书中的主要指控。Sohaib 选择审判，并在 2026 年 5 月被陪审团裁定共谋实施计算机欺诈、密码交易、禁止持枪人持有枪支等多项罪名成立，等待 9 月量刑。
没有被承认、没有被陪审团裁定成立的内容，仍应按“政府指控”处理。把全部指控都写成最终定罪事实，会失真。
接下来真正该看的是三件事。
| 观察点 | 为什么重要 | 相关人该怎么做 |
|---|---|---|
| 承包商权限如何发放和保留 | 这决定外包团队能碰到哪些生产数据 | 政府客户应要求承包商提交权限矩阵和离职停权记录 |
| 备份恢复之外如何处理泄露 | 数据可恢复，不代表隐私风险消失 | 涉及 EEOC 文件和税务信息时，要评估通知、监测和补救义务 |
| 高危操作能否被实时拦截 | 日志事后可查，不等于事中能挡 | 企业应把删库、清日志、批量导出纳入告警和审批链 |
目前还看不清的，是涉事公司名称、45 个联邦客户的完整名单，以及所有受影响机构范围。没有公开证据时，不该替案件补名单。
但能看清的是方向。
政府客户采购软件和运维服务时，不能只看功能、价格和交付周期。安全条款里要写清楚：承包商员工离职后多久停权，谁负责确认，是否提供审计证据，出现数据外泄如何通报。
企业安全团队也该把“离职停权演练”当成真实能力测试。不是看表格有没有填完，而是随机抽一个高权限人员，核验他在 VPN、数据库、云平台和代码仓库里的权限能否一次性收回。
这起案件的警示不在奇案本身。
删库的人当然要承担法律后果。但对组织来说，更刺眼的是那个没有被及时停掉的账号。千里之堤，溃于蚁穴。这里的蚁穴，就是离职流程里没人兜底的权限。