AWS网络安全弹性：勒索软件和破坏性事件恢复的参考方法

网络安全韧性是指在威胁行为者影响环境后，将工作负载恢复到已知安全状态的能力。预防措施旨在阻止威胁行为者入侵，检测措施则用于快速发现威胁。网络安全韧性聚焦于恢复：当备份、凭证或基础设施部分可能不再安全时，重建值得信赖的运行环境。

对于在AWS上运行关键工作负载的组织，勒索软件、数据勒索和其他破坏性事件已成为恢复规划的核心。恢复策略依赖的恢复环境和备份本身可能成为攻击目标。本文面向构建此类场景恢复能力的团队，通过隔离恢复与生产环境的参考模式、AWS Backup逻辑隔离保险库的删除保护机制、验证备份可恢复性和安全性的流水线，以及包含并行阶段的具体恢复工作流展开。文中还引入Rebuild-Restore-Rotate框架，指导从代码、备份或全新生成中选择恢复方式，并解决如何在最新备份可能携带相同威胁时选择合适恢复点的问题。

隔离恢复与生产环境

网络安全韧性的核心架构理念是：恢复环境（包括其身份、密钥和网络路径）不应与被恢复的环境共享信任边界。若生产凭证被攻破，恢复流程仍需能够独立执行。大多数客户通过AWS Organizations内的独立AWS账户实现这一目标。常见模式采用三个账户角色：

**生产账户**

生产账户运行实际工作负载。确认发生网络安全事件后，这些账户将被隔离以供调查。恢复操作不在此环境执行，因为在某些场景下原地修复可能无法完全重建信任。

**恢复账户**

恢复账户拥有AWS Backup逻辑隔离保险库。大多数原生AWS备份机制生成的恢复点本质上是不可变的。创建后无法修改Amazon Elastic Block Store (Amazon EBS) 快照或Amazon Relational Database Service (Amazon RDS) 快照。逻辑隔离保险库通过删除保护增强安全性。在保留期内，任何主体（包括账户根用户或被攻破的管理员）均无法删除恢复点或缩短其保留时间。该账户的核心作用是保障备份控制的安全性，配置谁可共享保险库、谁可发起恢复操作，以及通过多方审批（Multi-party approval）批准恢复操作。通过服务控制策略限制备份操作的专用账户，确保生产账户被攻破时无法篡改这些控制措施。

**隔离恢复环境（IRE）**

备份在此环境中恢复、验证，并在切换前重建新生产环境。IRE与生产账户完全隔离，若恢复的备份仍携带威胁，可阻止其扩散。IRE与生产账户无信任关系、无VPC对等连接且无面向互联网的资源，确保验证阶段发现的受污染恢复数据仅限于IRE内部，不会回传至生产环境或泄露到互联网。IRE的基础设施部署通过VPC终端节点（AWS PrivateLink）访问AWS服务API，无需互联网连接或与生产环境的VPC对等连接。下图展示了这三个账户角色在AWS Organizations内的关系，包括信任边界和恢复点流动路径。

图1. 确认事件后生产账户被隔离。恢复账户拥有逻辑隔离保险库并通过多方审批控制恢复授权。IRE与生产账户无信任关系或网络路径连接。

AWS Backup逻辑隔离保险库的最佳实践

AWS Backup逻辑隔离保险库是保护备份存储免遭删除的主要AWS原生方案。

该保险库的核心价值在于服务强制执行的删除保护。逻辑隔离保险库始终处于合规模式锁定状态。服务本身强制执行保留规则，因此在保留期内任何主体（包括账户根用户或被攻破的管理员）均无法删除恢复点。这种删除保护确保恢复点在需要时可用。恢复点是否安全使用的问题，将通过下文所述的验证流水线确定。

理解恢复点的存储位置

逻辑隔离的保管库将恢复点存储在AWS服务拥有的账户中。您可以选择使用服务拥有的密钥或AWS密钥管理服务（AWS KMS）客户托管密钥来加密这些恢复点。您恢复账户中的保管库对象是治理和访问边界，用于配置共享、还原授权以及多方审批。这种分离机制使得隔离是逻辑层面的，而非基于网络的。

通过AWS资源访问管理（AWS RAM）共享恢复点以进行还原

您可以通过AWS RAM跨账户共享恢复点。您可以从拥有账户或与您共享保管库的任何账户发起还原操作。这就是恢复账户如何将恢复点提供给隔离恢复环境（IRE）的方式。

为还原配置多方审批

通过IAM Identity Center配置的多方审批（MPA）要求在还原操作开始前获得预定义审批者的一致同意。当源账户可能不再可信时，这一功能尤为重要。

直接将完全托管资源备份到保管库

AWS Backup支持将逻辑隔离的保管库作为主要备份目标，用于完全托管资源（如Amazon S3、Amazon DynamoDB、Amazon EFS），因此备份可以直接写入保管库，无需先暂存到标准保管库。非完全托管资源（如Amazon EBS、Amazon Aurora、Amazon FSx）则通过智能编排路径进行备份，服务会先创建并传输临时快照。

对于不在保管库支持资源列表中的S3数据，Amazon S3对象锁定（合规模式）配合S3版本控制可在S3层提供等效的删除保护。

验证流水线

成功的还原确认备份可读，而验证确认其安全可用。单一检查无法覆盖所有问题，因此验证结合了多层机制：

• 针对勒索软件，还原卷上的恶意软件扫描可识别已知加密工具和指示符。
• 针对长期潜伏的威胁，恶意软件扫描可能不足，因为攻击者可能修改合法代码、配置或数据使其看似正常。这类变化会通过工作负载特定检查暴露，例如数据库一致性检查失败、应用程序不变量被破坏，或与已知良好基线的配置差异。
• 备份窗口期间的日志和审计审查可识别恶意身份或配置变更，这些是恶意软件扫描和工作负载检查单独无法发现的。

常见的验证流水线组合层级：

| 层级 | 功能 | 提供的保障 | |----------------|--------------------------------------------------------------------------|--------------------------------------------------------------------------------| | AWS原生 | AWS Backup还原测试 | 通过PutRestoreValidationResult API的自定义钩子，验证备份可恢复性 | | AWS原生 | Amazon GuardDuty恶意软件防护 | 还原卷的恶意软件扫描 | | AWS合作伙伴 | AWS Marketplace合作伙伴解决方案 | 无需完整还原即可扫描备份内容中的勒索软件 | | 工作负载特定 | 完整性和一致性检查 | 数据库一致性、应用程序不变量、与已知良好基线的配置差异对比 | | 跨层级 | 日志和审计审查 | 通过AWS CloudTrail和工作负载日志，识别备份窗口期间的异常身份或配置变更 |

批准恢复点前，AWS原生验证和工作负载特定验证均需通过。验证在IRE中执行，确保任何问题仅限于隔离环境，不会影响生产环境。由于AWS各服务的备份机制独立运行，不同服务的恢复点可能无法精确时间同步。通过尽可能紧密对齐备份计划，并在验证流水线中加入跨服务一致性检查，可缩小这一差距。

选择安全恢复点

对于大多数运维还原，最近的备份即为最佳选择。对于网络事件和数据损坏问题，最近的可运行副本通常是更优目标。如果攻击者在检测前已存在于环境中，此期间创建的备份可能携带相同问题。

下图展示了如何通过评估恢复点候选与妥协边界的关系，确定可安全使用的最新备份。

图2. 恢复点候选按逆时间顺序从早于事件边界的最近备份开始评估，每个候选需通过验证流水线后才能获得批准。

• 根据 AWS CloudTrail、Amazon Virtual Private Cloud (Amazon VPC) 流日志、Amazon GuardDuty、AWS Security Hub 和工作负载日志构建调查时间线，以识别事件的最早合理指示器。
• 按逆时间顺序评估恢复点候选，从事件窗口之前最近的备份开始。
• 将验证管道运行于每个候选。若验证失败，则回退到下一个候选。
• 记录审批人和选择依据后，批准选定的恢复点。

备份保留应包含早于组织实际检测窗口的恢复点。检测时间因组织和威胁类型差异较大，因此需根据自身的调查能力设定此数值，并随着能力提升进行调整。

恢复工作流

恢复分为五个阶段。其中三个阶段并行执行，因为恢复的最慢路径决定了业务停机时长。调查和验证与基础设施重建并行进行，以便在选择恢复点的同时构建新环境。由于将未验证的数据恢复到新环境会抵消验证的意义，因此需等待最后一步才进行数据恢复。下图展示了哪些阶段并行执行，以及审批门控如何隔离验证与数据恢复。

图3. 阶段1、2和4（调查、验证、基础设施重建）并行执行。阶段3（审批）是验证数据恢复到新环境前的门控。

• 阶段1：建立时间线。通过查询 AWS CloudTrail、Amazon VPC 流日志、Amazon GuardDuty 发现结果、AWS Security Hub 和工作负载日志，确定事件的最早指示器。该时间戳成为事件边界，仅边界之前创建的恢复点为候选。AWS 安全事件响应（SIR） 可为此阶段提供协调支持。
• 阶段2：验证候选。按逆时间顺序对早于事件窗口的恢复点运行验证管道。若最近候选验证失败，则回退到前一个。此阶段与阶段1并行执行，因调查和验证检查彼此不依赖。
• 阶段3：审批。仅批准通过所有验证检查的恢复点。若保险库配置了多方审批，则预定义审批人需授权恢复，且审批操作会自动记录为 AWS CloudTrail 管理事件。在事件管理流程中记录恢复点选择依据：调查结果、验证结果及决策依据。若选定候选验证失败，返回阶段2并选择更早的候选。
• 阶段4：重建与恢复。根据存储在独立版本控制存储库中的基础设施即代码（IaC）模板，在IRE中重建基础设施。此阶段与阶段1、2并行执行。阶段3批准恢复点后，从逻辑隔离的保险库将验证数据恢复到新基础设施。此阶段遵循重建-恢复-轮换框架执行凭证轮换。
• 阶段5：切换流量。将受影响环境的生产流量切换到新环境。使用带有健康检查的DNS记录，确保仅在新环境就绪时转移流量。切换前需识别并更新指向原生产账户的跨账户引用，包括IAM角色信任策略、基于资源的策略、AWS KMS密钥授权和服务集成。IAM访问分析器和AWS Config可帮助识别这些依赖关系。监控过渡过程，并在调查完成前保持受影响的生产账户隔离。

重建-恢复-轮换框架

网络安全恢复需要明确哪些内容需从代码重建、从备份恢复、或全新生成：

_基础设施即代码。数据即备份。凭证需更新。_

| 分类 | 示例 | 原因 | |------------------|-------------------------------------------------------------------------|--------------------------------------------------------------------------| | 从代码重建 | IAM 策略和角色、安全组、Amazon EC2、Amazon VPC、AWS Lambda、CI/CD 管道定义 | 配置来自已审核的版本控制模板，而非可能受污染的备份副本 | | 从备份恢复 | Amazon RDS、Amazon Aurora、Amazon EFS、Amazon EBS、Amazon FSx | 业务数据无法通过代码重建，必须来自经过验证的不可变备份 | | 轮换或重新签发 | IAM 访问密钥、数据库密码、API 密钥、证书、OAuth 令牌、SSH 密钥 | 事件窗口期间可能泄露的任何密钥需替换而非从备份继承 |

Some services sit across two categories. For example, Amazon S3 buckets and Amazon DynamoDB tables have both configuration (rebuilt from code) and data inside them (restored from backup), so recovery treats the two layers separately. Similarly, some credentials are re-issued by AWS rather than rotated by you. For example, consider service-linked roles and STS session tokens. The framework still applies, it’s just AWS that issues them fresh. Other data stores aren’t backed up at all because they are derived from sources that are backed up. Search indexes, analytics tables, caches, and materialized views are common examples. These regenerate from restored data, so they are a recovery dependency rather than a separate recovery category but they must be included in the recovery runbook and sequenced after the data they depend on has been restored. The framework assumes that your source of configuration, including IaC templates, pipelines, and source repositories, wasn’t itself the target of the attack. If it was, recovery starts further upstream with a trusted copy of source before rebuild can begin. Knowing where your known-good source of configuration lives, and how it is protected, is worth thinking through in advance.

For credential rotation, the practical prerequisite is a rotation process that already exists and is exercised. AWS Secrets Manager rotation, IAM Identity Center session revocation, AWS Certificate Manager renewal, and workload-specific rotation hooks are components most customers already have in some form. The cyber recovery capability is the ability to invoke that rotation comprehensively and verify that nothing was missed.

For services not currently supported by the logically air-gapped vault, Cross-Region Replication to a locked bucket or service-native point-in-time recovery can serve as interim options. These are recovery-oriented copies rather than tamper-proof storage and should be treated accordingly when designing around them.

Next steps

The following steps provide a starting point for teams building cyber recovery capability. Each step can be implemented incrementally, but together they form the operational foundation for the recovery workflow described in this post.

1. Create a logically air-gapped vault in a dedicated Recovery Account, and configure Multi-party approval for restore operations.
2. Establish an Isolated Recovery Environment in advance, with no trust relationship to production and no network path into the production environment. Pre-configure the networking, monitoring, and access controls required for recovery operations. Use SCPs to enforce isolation.
3. Enable AWS Backup Restore Testing on a regular schedule, and enable Amazon GuardDuty Malware Protection for backup and volume scanning.
4. Define workload-specific integrity checks for business-critical data (database consistency, application invariants, configuration diffs).
5. Confirm the credential rotation process works end-to-end and can be invoked as part of recovery, not only on a routine schedule. AWS Secrets Manager rotation provides the automation framework for database passwords and API keys.
6. Map cross-account dependencies (IAM role trust policies, resource-based policies, AWS KMS key grants, and service integrations) and maintain the inventory in your recovery runbook.
7. Exercise the full workflow, including investigation, validation, rebuild, restore, and cutover, on a regular schedule.

Conclusion

Cyber resilience on AWS builds on the services and patterns customers already use for recovery, with additions that address the specific concern that the production environment, the backups, or the recovery path itself may not be trustworthy after an event. The reference approach in this post, including isolation of recovery from production, deletion protected backup storage, a validation pipeline, a concrete workflow, and the Rebuild-Restore-Rotate framework, is a starting point. How you adapt it depends on your workloads, your existing recovery posture, and your organizational boundaries.

• * *

About the authors