2025 年 2 月 18 日，下午 4 点 50 分，双胞胎兄弟穆尼布・阿赫塔尔和索哈伊布・阿赫塔尔被各自的公司通过微软 Teams 会议当场解雇。这家位于华盛顿特区的 IT 承包商服务于 45 个联邦机构客户，拥有政府数据库的维护权限。解雇程序执行得相当迅速 —— 索哈伊布的 VPN 和 Windows 账户在五分钟后即被禁用。然而，穆尼布的账户却意外地被遗漏了。正是这短短几分钟的账户管理疏漏，导致 96 个政府数据库在随后的一小时内被彻底删除。
这个案例之所以值得深入分析，并非因为它展示了多么复杂高级的攻击手法，而是因为它暴露了政府关键基础设施灾备体系中几个根本性的设计缺陷：当恶意行为者已经获得充分权限且处于高度激愤状态时，灾备系统如何确保数据可恢复？备份策略的 RPO（恢复点目标）和 RTO（恢复时间目标）如何与实际业务影响相匹配？跨部门协调机制在紧急场景下如何有效运转？
备份频率与恢复点目标的根本性错配
穆尼布在删除数据库时曾说了一句耐人寻味的话：“他们可以从昨天的备份恢复。” 这句话揭示了当日备份策略与实际业务连续性需求之间的根本性错配。如果政府关键数据库系统确实仅在每日结束时执行一次备份，那么任何在当日备份之后发生的灾难性事件 —— 无论是恶意的批量删除还是意外的逻辑错误 —— 都将导致最近 24 小时内所有业务数据永久丢失。
对于承载平等就业机会委员会（EEOC）投诉数据、国土安全部运行数据库以及联邦税务信息的系统而言，24 小时的 RPO 显然无法满足业务需求。工程实践中，政府关键数据库的 RPO 设置应当遵循数据敏感度分级原则：涉及个人身份信息和税务数据的核心系统，RPO 应不超过 15 分钟；涉及执法和国土安全的基础数据，RPO 应接近零或通过同步双活架构实现零数据丢失。
从技术实现角度，PostgreSQL 的流复制（Streaming Replication）可以提供秒级的数据同步延迟，MySQL 的 Group Replication 能够实现多主节点间的实时同步，而 Oracle Data Guard 则支持零数据丢失的最大可用模式。这些技术的核心差异在于对网络带宽的依赖程度以及对主库性能的影响幅度。对于政府级数据库系统，强烈建议采用同步复制而非异步复制作为核心数据的保护机制，即便需要为此增加专用的高速内网通道和相应的硬件投入。
账户撤销与批量操作的时间窗口管理
事件时间线揭示了另一个关键问题：解雇执行与账户撤销之间存在一个未被有效管控的时间窗口。下午 4 点 50 分完成解雇程序，但直到 5 分钟后索哈伊布尝试访问网络时才发现账户已被禁用，而穆尼布的账户则完全未被处理。从 4 点 56 分到 5 点 56 分的整整一小时内，穆尼布持续执行删除操作，直到 FBI 在 3 周后执行搜查令时才被发现并制止。
这暴露了传统离职流程中的一个系统性风险：HR 系统、身份与访问管理系统（IAM）以及具体的业务系统权限之间缺乏原子性的同步机制。在许多组织中，HR 系统发出离职通知后，IT 部门需要手动在多个系统中逐一撤销权限，这种串行化的权限撤销流程在高权限账户场景下极其危险。
工程层面的解决方案应当是实施基于零信任架构的即时权限撤销能力。当 HR 系统触发终止流程时，IAM 系统应立即向所有连接的系统和数据库发送原子性的账户禁用命令，并且这个过程应当先于员工实际知晓被解雇的事实。对于持有特权账户的员工，建议采用 "kill before you're told" 模式 —— 即在正式通知前的数小时甚至前夜就已完成所有权限的系统性撤销，解雇会议本身仅作为形式上的确认。
日志保护与审计追踪的独立化设计
穆尼布在 4 点 59 分向 AI 工具询问了如何清除 SQL 服务器的系统日志以及 Windows Server 2012 的事件和应用日志。删除数据库后，他又下载了 1,805 个 EEOC 文件并窃取了至少 450 人的联邦税务信息。这些行为表明攻击者清楚地意识到需要销毁证据，而日志系统恰恰是追踪攻击路径和确定数据泄露范围的关键。
这引出了一个在灾备架构设计中经常被忽视的命题：日志本身应当被视为需要保护的数据资产，并且其保护等级应当高于被审计的业务系统。常见的错误做法是将审计日志与业务数据库存放在同一存储卷或同一存储阵列上，当攻击者获得数据库管理员权限后，可以轻易地一并删除或篡改日志记录。
正确的架构设计应当遵循日志独立化原则。审计日志应通过 syslog、journald 或专用 SIEM 系统实时传输到独立的日志服务器，该服务器应当与生产网络完全隔离，仅允许单向的日志写入操作，拒绝任何读取或管理请求。对于极高敏感级别的系统，可以考虑使用不可变存储（Immutable Storage）技术，确保日志一旦写入即无法被修改或删除，直到预设的保留期满。AWS S3 的 Object Lock 功能或 Azure Immutable Blob Storage 均提供了这种能力。
跨部门协调协议的工程化实现
事件中涉及的政府部门包括国土安全部、平等就业机会委员会以及多个其他联邦机构。当承包商员工删除数据库时，这些部门实际上失去了对自身数据的直接控制权，只能依赖承包商的灾备系统进行恢复。这种情况暴露了政府 IT 采购中的一个结构性问题：数据控制权与数据保管责任被分散在多个实体中，但缺乏清晰的协调协议来应对紧急场景。
工程化的跨部门协调机制应当包含以下几个关键组件。首先，建立跨机构的统一身份联邦体系，使得每个政府部门能够在紧急情况下直接控制与其相关的数据访问权限，而非完全依赖承包商的集中账户管理。其次，制定数据恢复优先级协议，明确规定当灾备事件发生时，各部门数据的恢复顺序和恢复时限，避免承包商单方面决定恢复策略。第三，建立独立的数据完整性验证通道，使各部门能够直接验证其数据的备份状态和可恢复性，而非被动接受承包商提供的信息。
具体而言，当 Opexus 这样的承包商负责维护政府数据库时，建议各政府部门保留独立的只读账户用于定期验证数据备份的完整性和可恢复性。这个账户应当具有执行SELECT查询和VERIFY命令的能力，但不具备任何修改或删除权限。通过独立的验证通道，政府部门可以自主确认备份是否处于健康状态，而无需依赖承包商的报告。
增量恢复窗口与业务影响评估
穆尼布在一个小时内删除了 96 个数据库。即便灾备系统拥有完整的备份数据，将 96 个数据库全部恢复到一致状态所需的时间仍可能远超一个小时。数据库恢复过程不仅包括数据文件的回滚，还包括事务日志的应用、索引的重建以及参照完整性的校验。对于 TB 级别的政府数据库，这个过程可能需要数小时甚至数天。
这意味着灾备架构设计不能仅仅关注数据是否可恢复，还必须评估恢复过程对业务连续性的实际影响。RTO（恢复时间目标）应当基于业务影响分析（BIA）的结果进行分级设置。对于政府核心职能系统，RTO 应不超过 4 小时；对于辅助性系统，RTO 可延长至 24 小时。关键在于，当实际 RTO 超过业务需求时，应当考虑采用双活或多活架构，确保在主节点失效时备用节点可以立即接管服务。
增量备份策略是平衡 RPO 和 RTO 矛盾的关键技术。通过实施频繁的增量备份（如每 15 分钟一次），可以将 RPO 控制在 15 分钟以内，同时避免完整备份对系统性能的影响。当需要恢复时，系统首先恢复最近的全量备份，然后依次应用增量备份，大幅缩短恢复窗口。PostgreSQL 的连续归档（Continuous Archiving）配合pg_basebackup和pg_restore工具可以有效地实现这一策略。
监控指标与异常行为检测
事件中有一个细节值得关注：穆尼布在下午 4 点 56 分开始执行删除操作，但直到 3 周后 FBI 执行搜查令时，承包商才发现数据库被删除。这表明系统层面缺乏足够的异常行为监控和告警机制。当同一用户在短时间内对大量数据库执行管理操作时，应当触发多维度的安全告警。
建议部署的监控指标包括：单一会话内的数据库删除操作数量阈值（建议设置为 3 至 5 个）、非工作时间的批量管理操作（应当禁止或严格审批）、来自同一用户的并发数据库连接数异常增长、以及跨数据库的权限提升行为。当监控指标超过预设阈值时，系统应自动触发告警并暂停相关会话，同时通知安全运营团队进行人工复核。
此外，应当建立数据变更的实时追踪机制。每一次DROP DATABASE操作都应当在独立的审计日志中留下不可篡改的记录，包括执行时间、执行者身份、源 IP 地址以及关联的 SQL 语句。这个审计日志应当实时同步到独立的安全信息与事件管理系统（SIEM），由 SIEM 负责关联分析和异常模式识别，而非依赖本地数据库服务器的日志系统。
面向特权账户的分层防护策略
穆尼布能够执行DROP DATABASE dhsproddb这样的高危命令，说明他的账户拥有远超过日常工作所需的数据库管理权限。这引发了一个根本性的问题：为什么一个承包商员工能够持有删除政府核心数据库的权限？
最小权限原则（Principle of Least Privilege）要求每个账户仅被授予完成其职责所必需的最小权限集合。对于数据库维护工作，通常需要区分数据读取、数据写入、结构变更和高危操作（如删除整个数据库）等不同级别的权限。一个负责应用程序正常运行的开发人员账户，不应当拥有执行DROP DATABASE命令的权限；即使需要执行数据库维护操作的账户，也应当对其可操作的对象范围和可执行的操作类型进行严格限制。
工程实现层面，建议采用基于角色的访问控制（RBAC）结合属性基访问控制（ABAC）的混合模型。RBAC 定义基本的功能性权限集合，ABAC 则在运行时根据上下文属性（如时间、位置、设备状态、请求频率等）进行动态的权限裁决。对于删除整个数据库这类极高危操作，可以要求额外的审批流程或多因素认证，甚至可以将这类操作设置为必须由两人同时授权方可执行的联锁模式。
结论
穆尼布・阿赫塔尔和索哈伊布・阿赫塔尔事件为我们提供了一个审视政府关键基础设施灾备体系的真实案例。它揭示了账户生命周期管理中的原子性同步需求、日志保护的独立化设计、跨部门协调的协议化实现、以及特权账户的最小权限约束等核心工程问题。
灾备架构的最终目标不是防止所有可能的攻击（这在理论上是不可能的），而是确保当灾难性事件发生时，数据可以按照业务需求的 SLA 进行恢复，业务影响可以被控制在可接受的范围内。这要求我们在设计灾备系统时，始终将业务影响评估作为出发点，将 RPO 和 RTO 的设置与实际业务需求相匹配，并通过技术手段确保这些目标能够被自动化地执行和验证。
参考资料
- Ars Technica, "Twin brothers wipe 96 gov't databases minutes after being fired", 2026 年 5 月 12 日（https://arstechnica.com/tech-policy/2026/05/drop-database-what-not-to-do-after-losing-an-it-job/）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。