Hotdry.

Article

离职访问撤销延迟：96个政府数据库被删的内部威胁复盘

从双胞胎员工被裁后5分钟内大规模删除数据的真实案例，分析即时权限撤销机制的缺陷与纵深防御策略。

2026-05-13security

2025 年 2 月 18 日下午 4 点 50 分，一对双胞胎兄弟在微软 Teams 会议上被公司当场解雇。六分钟后，其中一人的 Windows 账户已被禁用、VPN 访问已切断 —— 但另一个人的账户被遗漏了。就在这六分钟的时间里，他用DROP DATABASE dhsproddb命令删除了一个美国国土安全部数据库，然后继续在一小时内清除了 96 个政府数据库、下载了 1805 份 EEOC 文件到 U 盘、并顺手窃取了至少 450 人的联邦税务信息。这就是 Muneeb Akhter 和 Sohaib Akhter 案，一个本可预防的内部威胁事件。本文的目的是从这场失败中提炼出可工程化的访问控制缺陷清单与可落地的纵深防御参数。

事件时间线：权限撤销的黄金窗口被浪费了

事件的精确时间线揭示了问题所在。当日下午 4 点 50 分解雇程序启动后，4 点 55 分 Sohaib 尝试连接公司网络，发现自己的 VPN 和 Windows 账户已被立即禁用 —— 这说明公司有能力在解雇时同步执行账户撤销，流程本身并非缺失。然而 4 点 56 分 Muneeb 成功访问了托管在雇主服务器上的政府机构数据库，原因只有一个：他的账户在这轮撤销中被遗漏了。Muneeb 随后连续执行了锁定数据库连接和删除数据库的命令；4 点 58 分他用DROP DATABASE指令清除了 DHS 数据库；4 点 59 分他在 AI 助手中提问 “如何在删除数据库后清除 SQL 服务器的系统日志”。整个攻击在一小时内完成，此时公司安全团队尚不知情。

这一时间线的意义在于：两名员工中有一人的账户被正确及时地撤销了访问权限，另一人则因为流程中的单点遗漏而获得了完整的破坏窗口。这说明问题的本质不是 “是否有能力执行即时撤销”，而是 “撤销流程的可靠性是否存在单点故障”。如果 Muneeb 的账户也在第一分钟内被正确处理，这场损失本不会发生。这个观察直接影响了一个关键工程决策：权限撤销必须被视为一个原子操作，而不能依赖对多个独立系统的串行调用。

根本原因分析：三大访问控制缺陷

从这场事件中可以识别出三个层次分明的访问控制缺陷。第一个是账户撤销流程的单点可靠性问题。Sohaib 的账户在 4 点 55 分被正确禁用，说明公司存在一个解雇时触发账户撤销的机制 —— 可能是 HR 系统与 LDAP/Active Directory 的联动。但 Muneeb 的账户未被处理，暴露出这个机制对多账户场景（同一员工拥有多个系统账户）的处理存在盲区。工程层面，这意味着 HR 系统触发的事件没有对所有关联账户进行完整广播，或者依赖了不保证成功传递的消息队列。

第二个缺陷是缺乏即时权限供应（JIT Access）机制。这家公司采用的显然是静态授权模式：员工入职时获得一组访问权限，这些权限在雇佣关系存续期间持续有效，直到某个手动触发的撤销流程在解雇时执行。静态授权带来的核心风险是：任何时刻授予的权限都可能在任意时刻被滥用，而撤销流程一旦出现遗漏（正如本案），这些权限就成为持续的暴露面。JIT 访问的核心思想是将 “授权” 从一次性事件转化为临时性窗口 —— 员工仅在有事需要处理时获得访问授权，授权在任务完成后自动过期。

第三个缺陷涉及高权限操作缺乏双人授权机制。Muneeb 一人在数分钟内连续删除了 96 个数据库，期间没有系统要求第二个人的批准。如果数据库删除操作需要两名授权管理员分别输入审批码，攻击者就无法独立完成大规模破坏。这个控制看似简单，但现实中大量遗留系统缺乏此类机制，尤其是在快速迭代的承包商环境中。

可落地的工程参数：四项具体改进

针对上述缺陷，有四项具体的工程参数可以直接应用于组织的安全架构评估与改进。

参数一：账户撤销原子性保证。账户撤销不应是一个 “尽力而为” 的异步操作，而应在解雇流程中作为原子事务来处理。工程实现上，建议将 HR 系统的解雇事件建模为 Saga 模式或两阶段提交：第一步在 HR 系统中确认解雇，第二步同步触发所有关联后端系统（AD、VPN、数据库角色、云 IAM）完成撤销，第三步仅在所有确认返回后才向 HR 人员返回 “解雇完成” 信号。如果任何一个后端系统在超时阈值内未确认，系统应触发告警并阻止 HR 人员继续完成解雇流程。合理的超时阈值建议为 30 秒至 2 分钟，考虑到现代云 IAM 的 API 响应速度，这个阈值完全可实现。

参数二：JIT 访问的最小权限窗口。对于持有敏感数据访问权的岗位（本案中为联邦政府承包商），应逐步迁移至 JIT 模式。具体参数上建议：数据库写权限的最大授权窗口设为 4 小时，超时后需要重新申请并说明理由；删除类操作（DROP DATABASE、TRUNCATE TABLE）的授权窗口设为 30 分钟，且必须由第二人审批；VPN 远程访问的授权窗口与具体业务会话绑定，会话结束时立即撤销。这些参数的核心思想是将权限视为 “工具” 而非 “资产”—— 用完即归还。

参数三：破坏性操作的批量限制与速率控制。Muneeb 在一小时内删除了 96 个数据库，这个速率本身就是一个异常信号。数据库操作审计应配置如下阈值：单一账户在 15 分钟内执行超过 5 次删除类操作时触发实时告警并自动暂停该账户；单一账户在 24 小时内执行超过 20 次数据库修改操作时触发安全审查流程；所有数据库删除操作应写入独立的不可篡改日志表（使用触发器而非应用层日志），并配置为 append-only 存储。这些阈值可以在数据库审计插件或云数据库安全服务中配置实现。

参数四：离职设备的即时回收。Muneeb 在三天后与同谋一起重装了公司发放的笔记本电脑操作系统，这一行为之所以可行，是因为设备未在离职时立即被物理回收。工程控制上建议：所有公司发放设备在远程工作场景下应配置 MDM（移动设备管理）锁定，MDM 策略应包括在账户撤销触发后自动锁定设备并显示锁定消息；离职面谈应在 IT 人员在场的情况下当面完成设备回收；设备回收前应执行远程数据擦除而非等待物理归还。这些措施的成本在现代 MDM 方案中已大幅降低，GCP AWS 或 Intune/Jamf 均提供成熟的实现路径。

纵深防御清单：超越单点的分层控制

单一的控制点总会出现遗漏，这正是纵深防御（Defense in Depth）原则的核心价值。对于内部威胁场景，建议构建以下五层防御体系，即使某一层失效也不会导致全面失守。

第一层是身份与访问管理层。这是最基本的边界控制，核心要求包括：多因素认证覆盖所有远程访问路径；账户撤销在解雇触发后 5 分钟内完成；JIT 访问替代静态授权用于高风险权限。

第二层是数据库操作审计层。所有数据库的 DDL 和 DML 操作应记录到独立的审计日志系统，与数据库主实例物理分离。具体要求包括：日志存储使用 WORM（一次写入多次读取）模式防止篡改；审计日志保留期限至少与合规要求对齐（联邦机构通常要求 7 年）；配置机器学习或规则引擎对异常操作模式进行实时检测，检测信号包括非工作时间大量删除、单一会话批量删除、不同寻常的数据导出量。

第三层是备份与恢复层。Muneeb 曾评论 “他们可以从昨天的备份恢复”，这暗示公司有日常备份但可能缺乏不可变备份或跨区域副本。有效的备份策略应包括：每日增量备份保留至最近 30 天；每周全量备份保留至最近 12 个月；至少一份备份副本存储在不可变存储桶中（如 AWS S3 Glacier 或 Azure Immutable Blob），在指定保留期内无法被任何账户删除或修改；定期进行恢复演练以验证备份有效性。

第四层是网络层隔离与分段。96 个数据库分布在 45 个联邦机构中，如果这些数据库之间缺乏网络层隔离，单一账户的过度授权就会导致跨机构的连锁破坏。建议的网络分段策略包括：数据库服务器之间的横向流量通过 VLAN 或安全组规则严格限制；关键数据库部署在独立的网络区域，通过严格的出口控制访问；VPN 访问应基于最小必要原则分配网络权限，不应给予全网段访问。

第五层是人员与背景管理。虽然这是政策层面而非纯技术层面，但它直接影响安全基线。本案中的一个令人不安的事实是：两名被告早在 2015 年就有类似黑客犯罪记录，却仍然获得了敏感政府数据的访问权限。这暴露了背景调查流程中对历史违规行为复核的不足。建议在入职背景调查中增加对候选人在前雇主持有敏感系统访问权限时的行为审计查询机制，并在合同条款中明确禁止向有相关犯罪记录的员工授予特定等级的访问权限。

背景调查悖论与访问最小化原则

本案揭示了一个容易被忽视的安全悖论：背景调查的价值在于降低风险，但过度依赖背景调查反而可能导致安全自信过度。Muneeb 和 Sohaib 的背景检查通过了，尽管他们有 2015 年的入狱记录。这可能是因为背景调查只核对了 “有无犯罪记录”，而没有评估 “犯罪的性质与当前岗位的关联性”。一个曾因入侵政府系统而入狱的人，再次被批准访问政府敏感数据 —— 这个逻辑漏洞值得所有安全审查流程反思。

从访问最小化（Principle of Least Privilege）原则来看，这家承包商（后被确认为 Opexus）的失败尤为明显。两名员工获得了远超其工作所需的系统访问深度 —— 足以在几分钟内触达 96 个数据库、1805 份 EEOC 文件和 450 人的税务记录。这个权限范围显然不是为了 “完成本职工作” 而授予的，更可能是为了简化运维流程而授予的宽泛权限。这种宽泛赋权在承包商环境中很常见，因为承包商员工往往被期望能够 “快速响应各种问题”，但这种灵活性恰恰成为内部威胁的放大器。

总结：权限撤销的三个关键参数

从这场事件中提炼出的最重要教训是：权限撤销不是一次性的行政操作，而是需要工程化保证的实时安全控制。以下三个参数可以直接应用于安全架构评估。

第一个参数是撤销完成时间（SLA）。从解雇触发到所有账户权限撤销完成，建议 SLA 不超过 5 分钟。对于高敏感岗位，这个时间应进一步压缩至 2 分钟，且应包含主动确认机制而非被动超时检测。

第二个参数是最小授权粒度。账户权限不应以 “全部授予” 或 “全部撤销” 的二元方式管理，而应按功能域、数据类型和操作类型细分为独立授权单元。这样即使某个账户因流程遗漏未能及时撤销，过度授权也只限定在有限的范围内。

第三个参数是破坏性操作的审批层级。对于数据库删除、批量数据导出、系统配置修改等高风险操作，应强制要求第二人审批或额外身份验证。这个控制在工程上可以通过数据库特权管理工具（如 Azure SQL Database Threat Detection、AWS RDS IAM Auth）或特权访问管理（PAM）解决方案实现。

这场事件本可避免 —— 不是因为攻击者技术高超，而是因为防御者在最基本的访问控制环节出现了不该有的遗漏。当 Muneeb 在 4 点 56 分访问政府数据库时，如果系统能够验证 “这是一个刚被解雇的员工” 并拒绝访问，后续的一切损失都不会发生。权限撤销的及时性和完整性，是每一个持有敏感数据的组织都应该优先加固的防线。

资料来源

security

内容声明：本文无广告投放、无付费植入。

如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。