勒索软件后的 AWS 灾备：当备份与凭证不再可信时的恢复策略

预计阅读时间：9 分钟

传统灾备防的是地震、断电这类"天灾"，底层逻辑是：基础设施是可信的，只要把数据从异地拉起来，业务就能跑。但勒索软件和恶意破坏是"人祸"——攻击者不仅加密数据，还会刻意污染你的备份、窃取你的高权凭证、在基础设施里植入后门。

网络韧性（Cyber resilience）的核心不是防，也不是查，而是：当备份、凭证和部分基础设施都不再可信时，如何把工作负载恢复到一个已知的安全状态。

信任崩塌的现实

面对勒索软件，很多团队的第一反应是"从备份恢复"。但现实往往更残酷：

备份被删或被加密：攻击者拿到高权凭证后，第一件事就是用同一套凭证去删除或加密 S3 里的备份对象、EBS 快照，甚至销毁备份保管库。
凭证被劫持：恢复过程中使用的 IAM 用户或角色，可能正是攻击者已经掌握的密钥。你一边恢复，攻击者一边重新植入。
基础设施被污染：EC2 实例的启动脚本被篡改、Lambda 层被注入恶意依赖。即便数据恢复了，跑起来的依然是个被控环境。

这意味着，恢复的前提不再是"找到最新的备份"，而是"确认恢复所依赖的一切没有被污染"。

构建攻击者"够不到"的不可变防线

要让恢复成为可能，备份和恢复通道本身必须独立于日常生产环境。AWS 的参考架构给出了三个关键隔离维度：

账户隔离：灾备恢复用的备份保管库、IAM 凭证和编排脚本，必须放在一个完全独立的 AWS 账户中。生产账户的凭证对该账户没有任何权限。
逻辑隔离：使用 AWS Backup 的 Vault Lock 功能，对备份保管库启用合规模式（Compliance Mode）。一旦锁定，即便是 root 用户也无法在保留期内删除或修改备份。
物理隔离：核心备份跨区域复制。攻击者即使控制了主区域，也无法触及跨区域的隔离保管库。

实战配置：跨账户隔离与 Vault Lock 搭建

下面是一个可以直接改造使用的配置流程，演示如何在隔离灾备账户中创建不可变备份保管库，并允许生产账户跨账户写入。

第一步：在灾备账户中创建备份保管库并开启 Vault Lock

在灾备账户（假设 Account ID 为 111122223333）的终端中执行以下命令。--changeable-for-days 0 表示立即进入合规锁定，任何人都无法提前删除备份。

# 创建隔离保管库
aws backup create-backup-vault \
  --backup-vault-name RansomwareRecoveryVault \
  --region us-east-1

# 立即开启 Vault Lock（保留 365 天，不可提前删除）
aws backup put-backup-vault-lock-configuration \
  --backup-vault-name RansomwareRecoveryVault \
  --min-retention-days 365 \
  --max-retention-days 365 \
  --changeable-for-days 0 \
  --region us-east-1

第二步：在灾备账户中配置跨账户信任策略

创建一个 IAM 角色，允许生产账户（假设 Account ID 为 444455556666）的备份服务向这个隔离保管库写入备份，但绝不赋予读取或删除权限。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:root"
      },
      "Action": "backup:CopyIntoBackupVault",
      "Resource": "arn:aws:backup:us-east-1:111122223333:backup-vault:RansomwareRecoveryVault",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "444455556666"
        }
      }
    }
  ]
}

将此策略附加到灾备账户中专门用于接收跨账户备份的 IAM 角色（例如 CrossAccountBackupReceiverRole）。生产账户的备份计划配置 CopyActions 指向该角色和保管库即可。

运行前注意：请替换上述示例中的 Account ID、区域和保管库名称以匹配你的实际环境。Vault Lock 一旦开启不可撤销，请先在测试账户中验证保留期策略。

恢复不是"拉起数据"，而是"清场重建"

当生产环境被攻破，恢复操作绝不能在生产账户内进行。正确的做法是：

冻结生产账户：立即切断生产账户的网络出口，防止攻击者外泄数据或接收新指令。用 SCP（Service Control Policy）在 Organizations 层面限制该账户的大部分 API 调用。
在干净账户中重建：使用隔离灾备账户中受保护的 IaC（基础设施代码，如 Terraform/CloudFormation）和干净的镜像，在一个全新的 AWS 账户中拉起基础设施。
恢复数据：从隔离保管库将数据复制到新账户，而非直接挂载回旧账户。
重置身份体系：旧账户的 IAM 凭证全部作废。新账户的身份体系必须重新建立，使用全新的 SSO 映射或独立的 IAM 用户，并强制启用 MFA。

最关键的一点是：不要试图修补被污染的环境，直接丢弃它。 保留旧账户只是为了事后取证分析，绝不再用于承载生产流量。

落地建议与权衡清单

网络韧性的建设没有银弹，每一层隔离都意味着额外的成本和运维复杂度。在落地时需要做以下权衡：

成本 vs 恢复确定性：跨区域、跨账户的不可变备份存储成本显著高于常规备份。你需要根据数据的关键程度分级，只对核心业务数据（如交易记录、核心配置）启用最高级别的 Vault Lock 隔离。
演练频率 vs 系统稳定性：跨账户恢复流程如果不定期演练，真正发生事件时几乎必定失败。建议每季度在一个完全隔离的沙箱账户中执行一次从零恢复的 GameDay，验证 IaC 和备份的完整性。
IaC 的安全存储：你的 Terraform 状态文件和 CloudFormation 模板同样需要不可变保护。将它们存入开启了 Object Lock 的 S3 桶，并纳入跨账户备份计划。

快速自检清单： - [ ] 核心备份是否开启了 AWS Backup Vault Lock（Compliance Mode）？ - [ ] 备份保管库是否在独立于生产的灾备账户中？ - [ ] 生产账户的凭证是否对灾备账户没有任何删除/修改权限？ - [ ] 是否有脱离生产账户的、受保护的 IaC 代码库和状态文件？ - [ ] 过去 6 个月内，是否进行过从零账户开始的完整恢复演练？

网络韧性不是买一个更贵的备份方案，而是承认"一切皆可被污染"的前提下，设计一条攻击者无法触及的恢复通道。这条通道平时沉默，但在灾难发生时，它是唯一值得信任的起点。