# AWS 安全事件响应 技术指南
**Topics**
+ [摘要](#abstract)
+ [您的架构是否良好？](#are-you-well-architected)
+ [简介](introduction.md)
+ [准备](preparation.md)
+ [操作](operations.md)
+ [事件后活动](post-incident-activity.md)
+ [结论](conclusion.md)
+ [贡献者](contributors.md)
+ [附录 A：云功能定义](appendix-a-cloud-capability-definitions.md)
+ [附录 B：AWS 事件响应资源](appendix-b-incident-response-resources.md)
+ [版权声明](notices.md)
## 摘要
本指南概述了在客户 Amazon Web Services（AWS）云环境中响应安全事件的基础知识。它概述了云安全和事件响应概念，并确定了响应安全问题的客户可以使用的云功能、服务和机制。
本指南面向担任技术角色的用户，假定您熟悉信息安全的一般原则、对当前本地环境中的安全事件响应有基本了解，并且对云服务有一定了解。
## 您的架构是否良好？
当您在云端构建系统时，[AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 可帮助您了解所做决策的利弊。利用此框架的六个支柱，您可以了解到设计和运行可靠、安全、高效、经济有效且可持续的系统的架构最佳实践。您可以使用 [AWS Well-Architected Tool 控制台](https://console.aws.amazon.com/wellarchitected)中免费提供的 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/)，回答与每个支柱相关的一组问题，即可根据这些最佳实践检查自己的工作负载。
有关云架构的更多专家指导和最佳实践（参考架构部署、图表和白皮书），请参阅 [AWS 架构中心](https://aws.amazon.com/architecture/)。
# 简介
安全是 AWS 的重中之重。AWS 客户受益于专为满足大多数安全敏感型组织的要求而打造的数据中心和网络架构。AWS 采用责任共担模式：AWS 负责*云的*安全，客户则负责*云中*的安全。这意味着您可以完全控制自身的安全实施，例如使用多种工具和服务助您实现安全目标。这些功能可以帮助您为在 AWS 云 中运行的应用程序建立安全基准。
如果偏离基准，例如由于配置错误或外部因素变化，则需做出响应并进行调查。要成功做到这一点，您需要了解 AWS 环境中安全事件响应的基本概念，并了解在安全问题发生之前做好准备以及向云团队传授知识并开展培训的相关要求。您需要了解可以使用的控制措施和功能，查看用于解决潜在问题的主题示例，并掌握利用自动化提高响应速度与一致性的补救方法。此外，您还应了解相关的合规性规定和法规，因为这些规定和法规与制定安全事件响应计划以满足上述要求相关。
安全事件响应可能较为复杂，因此我们建议您采用迭代方法：从核心安全服务开始，构建基础的检测和响应能力，而后制定行动手册以创建初始的事件响应机制库，并在此基础上进行迭代和改进。
## 开始前的准备工作
在开始了解 AWS 中的安全事件响应之前，请先熟悉 AWS 安全和事件响应的相关标准和框架。这些基础知识将有助于您理解本指南中介绍的概念和最佳实践。
### AWS 安全标准和框架
首先，我们建议您查看[《安全、身份与合规性的最佳实践 – AWS Well-Architected Framework》](https://aws.amazon.com/architecture/security-identity-compliance/)以及[《AWS Cloud Adoption Framework（AWS CAF）概览》白皮书中的“安全视角”](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)。
AWS CAF 会提供指南，促进向云迁移的组织中不同部门之间的协调。AWS CAF 指南分为几个重点领域（称为视角），这些领域与构建基于云的 IT 系统有关。安全视角描述了如何跨工作流实施安全计划，其中之一便是事件响应。本文档是我们与客户合作的经验成果，旨在帮助他们建立有效的安全事件响应计划与高效的安全事件响应能力。
### 行业事件响应标准和框架
本白皮书遵循美国国家标准与技术研究院（NIST）制定的《[计算机安全事件处理指南 SP 800-61 r3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)》中的事件响应标准和最佳实践。阅读并理解 NIST 提出的概念是有益的先决条件。本白皮书将把该 NIST 指南中的概念和最佳实践应用于 AWS 技术。但是，本地事件场景不在本指南的讨论范围内。
## AWS 事件响应概述
首先，了解云中的安全运营和事件响应有何不同至关重要。要构建 AWS 中的有效事件响应能力，需要了解其与传统本地响应的差异，以及这些差异对事件响应计划的影响。本节将详细介绍这些差异以及 AWS 事件响应的核心设计原则。
### AWS 事件响应的各个方面
组织内的所有 AWS 用户都应对安全事件响应流程有基本的了解，并且安全人员应了解如何响应安全问题。教育、培训和经验对于成功的云事件响应计划至关重要，最好在处理可能发生的安全事件之前提前实施。云中成功的事件响应计划的基础在于*准备工作*、*操作*和*事件后活动*。
要了解其中的各个方面，请考虑以下描述：
+ **准备工作**：让事件响应团队做好准备，以便在 AWS 中检测和响应事件，方法是启用检测性控制措施，并确保对必要的工具和云服务拥有适当的访问权限。此外，还应通过人工和自动化的方式准备必要的行动手册，以确保可靠且一致的响应。
+ **操作**：按照 NIST 的事件响应阶段（检测、分析、遏制、根除和恢复）对安全事件和潜在事件采取相应操作。
+ **事件后活动**：对安全事件和模拟的结果进行迭代，以提高响应的有效性，从响应和调查中获得更多价值，并进一步降低风险。您必须从事件中吸取经验教训，并对改进活动占有很大的所有权。
本指南将探讨这些方面并逐一进行详细介绍。下图显示了这些方面的流程，与前面提到的 NIST 事件响应生命周期一致，但操作包括检测、分析、遏制、根除和恢复。
![\[图中显示了 AWS 事件响应的各个方面\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/images/aspects-of-incident-response.png)
### AWS 事件响应原则和设计目标
尽管事件响应的一般流程和机制（例如《[NIST SP 800-61 计算机安全事件处理指南](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)》中定义的流程和机制）依然有效，但我们建议您评估这些与云环境中的安全事件响应相关的特定设计目标：
+ **建立响应目标**：与利益相关者、法律顾问和组织领导合作，以确定事件响应目标。一些共同的目标包括遏制和缓解问题、恢复受影响的资源、保留数据为便取证、恢复已知安全运营，以及最终从事件中吸取教训。
+ **利用云进行响应**：在云中（即事件和数据的发生地）实施响应模式。
+ **了解所拥有和需要的证据：**通过复制日志、资源、快照和其他证据并将其存储在一个集中的响应专用云账户中来保存这些内容。使用标签、元数据和保留策略实施机制。您需要了解自己使用了哪些服务，然后确定调查这些服务的要求。为了帮助您了解自己的环境，您还可以使用标记（本文档后面的[制定和实施标记策略](develop-and-implement-tagging-strategy.md)一节将对此进行介绍）。
+ **使用重新部署机制**：如果安全异常可归因于一个配置错误，那么可能只需使用适当的配置重新部署资源来删除差异，即可完成修复。如果发现可能存在漏洞，请核实您重新部署时是否包括成功且经过验证的根本原因缓解措施。
+ **尽可能自动化**：当问题出现或事件重复发生时，建立机制，以程序化方式对常见事件进行分类和响应。对于自动化程度不足的独特、复杂或敏感事件，使用人工响应。
+ **选择可扩展的解决方案**：尽量让组织采用方法的可扩展性与云计算能力相匹配。实施可在您环境中扩展的检测和响应机制，有效地缩短检测与响应之间的时间差。
+ **了解并改进流程**：主动找出流程、工具或人员的不足，并实施计划来弥补这些不足。模拟是找出不足并改进流程的妥善方法。有关如何对流程进行迭代的详细信息，请参阅本文档的[事件后活动](post-incident-activity.md)一节。
这些设计目标会提醒您审查架构实施情况，确定是否同时具备事件响应能力和威胁检测能力。在规划云端实施时，应考虑如何应对事件，最好使用具备司法有效性的响应方法。在某些情况下，这意味着您可能需要专门为这些响应任务设置多个组织、账户和工具。这些工具和功能应通过部署管道提供给事件响应者。它们不应该是静态的，因为这会导致更大的风险。
### 云安全事件域
要进行有效准备并响应 AWS 环境中的安全事件，您需要了解常见的云安全事件类型。在客户责任范围内，有三个可能发生安全事件的域：服务域、基础设施域和应用程序域。不同的域需要不同的知识、工具和响应流程。请考虑以下域：
+ **服务域**：服务域中的事件可能会影响您的 AWS 账户、[AWS Identity and Access Management](https://aws.amazon.com/iam/)（IAM）权限、资源元数据、账单或其他方面。服务域事件是指仅使用 AWS API 机制进行响应的事件，或者是其根本原因与配置或资源权限相关，且可能包含相关的服务导向型日志记录的事件。
+ **基础设施域**：基础设施域中的事件包括与数据或网络相关的活动，例如 [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/)（Amazon EC2）实例上的进程和数据、虚拟私有云（VPC）内流向 Amazon EC2 实例的流量，以及容器或其他未来服务等其他方面。对基础设施域事件的响应通常需要获取与事件相关的数据，以进行取证分析。这可能包括与实例操作系统进行交互，并且在不同情况下，还可能涉及与 AWS API 机制交互。在基础设施域中，可在来宾操作系统（例如专门用于执行取证分析和调查的 Amazon EC2 实例）中组合使用 AWS API 和数字取证/事件响应（DFIR）工具。基础设施域事件可能涉及分析网络数据包捕获、[Amazon Elastic Block Store](https://aws.amazon.com/ebs/)（Amazon EBS）卷上的磁盘块或从实例获取的易失性存储器。
+ **应用程序域**：应用程序域中的事件通常发生在应用程序代码或部署到服务或基础设施的软件中。该域应包含在您的云威胁检测和响应行动手册中，并且还可能包含基础设施域中的类似响应。您可以借助适当且周密的应用程序架构，使用云工具，通过自动获取、恢复和部署来管理该域。
在这些域中，请考虑可能对 AWS 账户、资源或数据执行操作的行为者。无论是内部行为者还是外部行为者，都应使用风险框架来确定组织面临的具体风险，并做好相应的准备。此外，您还应该开发威胁模型，这有助于您规划事件响应和构建周密架构。
### AWS 中事件响应的主要差异
无论是在本地还是在云中，事件响应都是网络安全战略不可或缺的一部分。最低权限和深度防御等安全原则旨在保护本地数据与云中数据的机密性、完整性和可用性。随之诞生的，是支持这些安全原则的几种事件响应模式，包括日志保留、来自威胁建模的警报选择、行动手册制定以及安全信息和事件管理（SIEM）集成。当客户开始在云中架构和设计这些模式时，差异便开始显现。以下是 AWS 中事件响应的主要差异。
#### 差异 \$11：安全性的责任共担
安全性和合规性是 AWS 与客户共同承担的责任。这种责任共担模式可以减轻客户的运营负担，因为 AWS 会运营、管理和控制从主机操作系统和虚拟化层组件，一直到服务运营所在物理设施的安全性。有关责任共担模式的更多详细信息，请参阅[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)文档。
随着您在云中的共担责任发生变化，事件响应选项也会随之改变。规划并了解这些权衡取舍，使其与您的治理需求相匹配，是事件响应的关键一步。
除了与您直接相关的 AWS 外，可能还有其他实体在特定责任模式中承担责任。例如，可能有内部组织单元，负责您运营的某些方面。此外，您也可能与开发、管理或运营部分云技术的其他各方有关系。
制定并测试与运营模式相匹配的适当事件响应计划和相应的行动手册至关重要。
#### 差异 \$12：云服务域
由于云服务中存在安全责任差异，因此需要一个新的安全事件域：服务域（该域已在之前的[事件域](#cloud-security-incident-domains)一节中进行说明）。服务域包括客户的 AWS 账户、IAM 权限、资源元数据、账单及其他方面。由于您的响应方式不同，该域在事件响应方面亦有所不同。服务域内的响应通常通过查看和发出 API 调用实现，并非基于主机和基于网络的传统响应。在服务域中，您不会与受影响资源的操作系统进行交互。
下图显示了服务域中基于架构反模式的安全事件示例。在此事件中，未经授权的用户将获取 IAM 用户的长期安全凭证。IAM 用户拥有 IAM 策略，该策略允许其从 [Amazon Simple Storage Service](https://aws.amazon.com/s3/)（Amazon S3）存储桶检索对象。要响应此安全事件，可以使用 AWS API 来分析 AWS 日志（例如 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 和 Amazon S3 访问日志）。您还可以使用 AWS API 来遏制事件并从中恢复。
![\[服务域示例图\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/images/service-domain-example.png)
#### 差异 \$13：用于预置基础设施的 API
另一个差异源于[云按需自助服务的特性](https://csrc.nist.gov/publications/detail/sp/800-145/final)。主要设施客户通过 RESTful API 与 AWS 云 交互，这些 API 经由全球诸多地理位置可用的公有和私有端点提供。客户可以使用 AWS 凭证访问这些 API。与本地访问控制措施不同，这些凭证不一定受网络或 Microsoft Active Directory 域的约束。与之相反，这些凭证与 AWS 账户内的 IAM 主体相关联。这些 API 端点可以在企业网络之外进行访问，在对预期网络或地理位置之外使用凭证的事件进行响应时，理解这一点非常重要。
由于 AWS 基于 API 的特性，响应安全事件的一个重要日志源是 AWS CloudTrail，它会跟踪 AWS 账户中发出的管理 API 调用，您可以在其中找到有关 API 调用源位置的信息。
#### 差异 \$14：云的动态特性
云是动态的；支持您快速创建和删除资源。借助自动扩展，您可以根据流量增加情况启动和终止资源。由于基础设施生命周期短且变化快速，您正在调查的资源可能已不复存在或已被修改。理解 AWS 资源的短暂性以及如何跟踪 AWS 资源的创建和删除对于事件分析至关重要。您可以使用 [AWS Config](https://aws.amazon.com/config/) 来跟踪 AWS 资源的配置历史记录。
#### 差异 \$15：数据访问
云中的数据访问也有所不同。您无法通过接入服务器收集安全调查所需的数据。数据将通过线路和 API 调用进行收集。您需要实践并了解如何通过 API 执行数据收集，以便为这种转变做好准备，并确保进行了适当存储以实现有效收集和访问。
#### 差异 \$16：自动化的重要性
为了让客户充分意识到云采用的优势，其运营策略必须采用自动化。基础设施即代码（IaC）是一种高效的自动化环境模式，在这种环境中，AWS 服务通过代码（由原生 IaC 服务如 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 或第三方解决方案提供支持）进行部署、配置、重新配置和销毁。这可提供高度自动化的事件响应实施方式，有助于避免人为错误，尤其是在处理证据时。尽管本地环境也采用自动化，但在 AWS 云 中，自动化不可或缺，而且可以更轻松地实现。
#### 应对差异
要应对这些差异，请按照下一节概述的步骤进行操作，以确保涉及人员、进程和技术的事件响应计划准备充分。
# 准备
要想及时、有效地应对事件，为事件做好准备至关重要。“准备工作”涉及三个领域：
+ **人员**：要让员工做好应对安全事件的准备，需要确定事件响应的利益相关者，并对他们进行事件响应和云技术方面的培训。
+ **进程**：为安全事件做好进程准备，包括记录架构、制定全面的事件响应计划，以及创建行动手册，以便对安全事件做出一致响应。
+ **技术**：为安全事件做好技术准备，包括设置访问权限、汇总和监控必要的日志、实施有效的警报机制，以及培养响应和调查能力。
对有效的事件响应而言，每个领域都同等重要。没有这三项，任何事件响应计划都不完整或无效。您需要在人员、流程和技术方面做好准备，并将其紧密集成，以便为应对事件做好准备。
# People
要响应安全事件，您需要确定支持安全事件响应的利益相关者。此外，确保他们接受过 AWS 技术及 AWS 环境方面的相关培训，这对于实现有效响应至关重要。
# 定义角色和职责
处理安全事件需要在整个组织中落实纪律要求和行动意愿。在您的组织结构中，发生事件时，负责、追责、咨询或者告知信息等各个环节会涉及到不同的人员，例如人力资源（HR）、高管团队和法律部门的代表。请考虑这些角色和职责，以及是否必须有第三方参与。请注意，许多地区的当地法律都规定了，哪些事能做，哪些事不能做。尽管为安全响应计划建立一个负责、问责、咨询和知情（RACI）的图表可能显得过于繁文缛节，但这样做有利于快速直接地进行沟通，并清楚地概述在事件不同阶段负责的领导层。
在事件发生期间，让受影响应用程序和资源的负责人和开发人员参与进来非常关键，因为这些人员是主题专家（SME），可以提供信息和背景情况来协助衡量影响。您应该先练习并与开发人员和应用程序负责人建立关系，然后才能依靠他们的专业知识进行事件响应。应用程序负责人或 SME，如云管理员或工程师，可能需要在不熟悉环境、面临复杂情况或响应人员没有访问权限的情况下采取行动。
最后，值得信赖的关系可以参与到调查或响应中，因为他们可以提供额外的专业知识和宝贵的审查工作。当您自己的团队缺乏具备这些技能的人员时，您可能需要聘请外部人员寻求帮助。
# 培训事件响应人员
对事件响应人员进行有关其组织所使用技术的培训，对于其能否充分响应安全事件至关重要。如果相关人员不了解底层技术，响应时间可能会延长。除了传统的事件响应概念外，了解 AWS 服务及其 AWS 环境同样重要。用于培训事件响应人员的传统机制有很多，例如在线培训和课堂培训。但是，您还应该考虑将开展 GameDay 活动或进行模拟作为其中一种培训机制。有关如何进行模拟的详细信息，请参阅本文档的[定期进行模拟](run-regular-simulations.md)一节。
# 了解 AWS 云 技术
要减少依赖性并缩短响应时间，请确保您的安全团队和响应人员接受过云服务相关培训，并且有机会在组织所使用的特定云环境中进行实操演练。事件响应人员要想高效工作，了解 AWS 基础知识、IAM、AWS Organizations、AWS 日志记录与监控服务以及 AWS 安全服务至关重要。
AWS 提供在线安全讲习会（请参阅 [AWS Security Workshops](https://workshops.aws/categories/Security)），您可以通过其获得有关 AWS 安全与监控服务的实操经验。AWS 还提供多种培训选项和学习路径，包括数字培训、课堂培训、AWS 培训合作伙伴和认证。要了解更多信息，请参阅 [AWS 培训和认证](https://aws.amazon.com/training/)。
AWS 提供免费培训和基于订阅的培训，支持多个角色和重点领域。请访问 [AWS Skillbuilder](https://skillbuilder.aws/) 了解更多信息。
# 了解 AWS 环境
除了了解 AWS 服务、其使用案例及其集成方式外，了解组织 AWS 环境的实际架构以及所实施的操作流程也同样重要。通常情况下，此类内部知识没有文档记录，且仅由少数领域专家掌握，这可能会产生依赖项、阻碍创新并减慢响应时间。
为避免产生这些依赖性并缩短响应时间，应记录有关 AWS 环境的内部知识，形成文档，便于安全分析师访问和理解。要了解完整云足迹，需要安全利益相关者与相关云管理员进行协作。针对事件响应流程进行准备的一部分内容包括记录并集中管理架构图（本白皮书中的[记录并集中管理架构图](document-and-centralize-architecture-diagrams.md)一节将对此进行介绍）。然而，从人员角度来看，重要的是分析师能够访问并理解与 AWS 环境相关的架构图和操作流程。
# 了解 AWS 响应团队和支持
## 支持
[支持](https://aws.amazon.com/premiumsupport/) 包含一系列计划，这些计划旨在让您能够运用各种工具和专业知识来为成功部署和正常实施 AWS 解决方案提供支持。如果您需要技术支持及更多资源来规划、部署和优化 AWS 环境，则可以选择最符合 AWS 使用案例的支持计划。
考虑将[支持中心](https://console.aws.amazon.com/support)（在 AWS 管理控制台中，需要登录）作为中心联系点，为影响您 AWS 资源的问题获取支持。对 支持 的访问由 IAM 控制。有关获取对 AWS 支持功能的访问权限的更多信息，请参阅 [Getting started with 支持](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support)。
此外，如果您需要举报滥用行为，请联系 [AWS 信任与安全团队](https://aws.amazon.com/forms/report-abuse)。
## 安全事件响应工程师
安全事件响应工程师是一支专业的 AWS 全球团队，全天候向客户提供支持，协助客户解决根据 [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)应由客户一方负责的安全事件。
安全事件响应工程师为您提供的支持，是就 AWS 上出现的安全事件提供分级和恢复方面的协助。他们将使用 AWS 服务日志来协助分析根本原因，并为您提供恢复建议。他们还将提供安全建议和最佳实践，从而让您以后能够避免出现安全事件。
AWS 客户可以通过 [AWS 支持案例](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)与安全事件响应工程师互动。
+ **所有客户**：
1. 账户和计费
1. 服务：账户
1. 类别：安全
1. 严重性：一般问题
+ **使用开发人员版 支持 计划的客户**：
1. 账户和计费
1. 服务：账户
1. 类别：安全
1. 严重性：重要问题
+ **使用 Business 版 支持 计划的客户**：
1. 账户和计费
1. 服务：账户
1. 类别：安全
1. 严重性：影响业务的紧急问题
+ **使用 Enterprise 版 支持 计划的客户**：
1. 账户和计费
1. 服务：账户
1. 类别：安全
1. 严重性：关键业务风险问题
+ **使用 AWS 安全事件响应订阅的客户**：在 https://console.aws.amazon.com/security-ir/ 上打开安全事件响应控制台
## DDoS 响应支持
AWS 提供 [AWS Shield](https://aws.amazon.com/shield/)，这是一项托管的分布式阻断服务（DDoS）保护服务，可保护在 AWS 上运行的 Web 应用程序。AWS Shield 提供不间断检测和自动化内嵌缓解措施，可以最大限度地减少应用程序停机时间和延迟，因此无需与 支持 交流即可从 DDoS 保护中受益。AWS Shield 提供两个等级：Shield Standard 和 Shield Advanced。要了解这两个级别之间的区别，请参阅《[Shield 功能文档](https://aws.amazon.com/shield/features/)》。
## AWS Managed Services（AMS）
[AWS Managed Services](https://aws.amazon.com/managed-services/)（AMS）可持续管理您的 AWS 基础设施，让您可以专注于应用程序。AMS 实施最佳实践来维护您的基础设施，让您能够降低运营开销和风险。AMS 可以自动执行常见活动 (例如更改请求、监控、补丁管理、安全性和备份服务)，并可以提供全生命周期服务来预置、运行和支持您的基础设施。
AMS 负责部署一套安全检测性控制措施，并每天提供对警报的第一线响应。启动警报后，AMS 遵循一组标准的自动和手动行动手册，验证是否有一致的响应。这些行动手册在功能部署期间与 AMS 客户共享，这样客户就能够开发并与 AMS 协调响应措施。
# 流程
要想成功实现可扩展的事件响应计划，制定全面且明确定义的事件响应流程是关键。在发生安全事件时，明确的步骤和工作流程有助于您及时做出响应。您可能已经有事故响应流程。无论您当前的状态如何，定期更新、迭代和测试事件响应流程都很重要。
# 制定并测试事件响应计划
为事件响应制定的第一个文档是*事件响应计划*。事件响应计划旨在为您的事件响应计划和战略奠定基础。事件响应计划是一份高级文档，通常包括以下部分：
+ **事件响应团队概述**：概述事件响应团队的目标和职能
+ **角色和职责**：列出事件响应利益相关者，并详细说明他们在发生事件时的角色
+ **沟通计划**：详细介绍联系人信息，以及在事件发生期间如何进行沟通
此时的最佳实践是采用带外通信，作为事件沟通的后备。[AWS Wickr](https://aws.amazon.com/wickr/) 就是一个提供安全的带外通信渠道的应用程序示例。
+ **事件响应阶段和应采取的行动：**列举事件响应的各个阶段（例如，检测、分析、根除、遏制和恢复），包括在这些阶段中要采取的高级别操作
+ **事件严重性和优先级定义：**详细说明如何对事件的严重性进行分类，如何确定事件的优先级，然后详细说明严重性定义对上报程序有何影响
尽管这些内容部分在各种规模和行业的公司中很常见，但每个组织的事件响应计划都是独一无二的。您将需要制定最适合贵组织的事件响应计划。
# 记录并集中管理架构图
为了快速准确地响应安全事件，您需要了解系统和网络的架构方式。了解这些内部架构模式不仅对事件响应至关重要，而且对于验证遵循最佳实践构建这些模式的应用程序之间的一致性也同样重要。您还应确保本文档保持最新，并根据新的架构模式定期更新。您应建立文档和内部存储库，详细说明以下项目：
+ **AWS 账户结构**：需要了解：
+ 您有多少个 AWS 账户？
+ 这些 AWS 账户是如何组织的？
+ AWS 账户的业务负责人是谁？
+ 您是否使用服务控制策略（SCP）？ 如果是，通过 SCP 实施了哪些组织护栏？
+ 您是否限制了可使用的区域和服务？
+ 业务部门和环境（开发/测试/生产）之间存在哪些差异？
+ **AWS 服务模式**
+ 您使用了哪些 AWS 服务？
+ 使用最广泛的 AWS 服务有哪些？
+ **架构模式**
+ 您使用了哪些云架构？
+ **AWS 身份验证模式**
+ 您的开发人员通常如何向 AWS 进行身份验证？
+ 您使用的是 IAM 角色还是用户（或两者兼而有之）？ 您的 AWS 身份验证是否连接到身份提供者（IdP）？
+ 如何将 IAM 角色或用户映射到员工或系统？
+ 当某人不再获得授权时，如何撤销其访问权限？
+ **AWS 授权模式**
+ 您的开发人员使用了哪些 IAM 策略？
+ 您是否使用了基于资源的策略？
+ **日志记录和监控**
+ 您使用了哪些日志源？它们存储在何处？
+ 您是否聚合 AWS CloudTrail 日志？ 如果是，它们存储在何处？
+ 如何查询 CloudTrail 日志？
+ 您是否启用了 Amazon GuardDuty？
+ 如何访问 GuardDuty 调查发现（例如控制台、工单系统、SIEM）？
+ 调查发现或事件是否聚合在 SIEM 中？
+ 是否会自动创建工单？
+ 进行日志调查分析时，使用了哪些工具？
+ **网络拓扑**
+ 网络上的设备、端点和连接在物理上或逻辑上是如何排列的？
+ 您的网络如何与 AWS 连接？
+ 不同环境之间的网络流量是如何过滤的？
+ **外部基础设施**
+ 面向外部的应用程序是如何部署的？
+ 哪些 AWS 资源可以公开访问？
+ 哪些 AWS 账户包含面向外部的基础设施？
+ 部署了哪些 DDoS 或外部过滤措施？
记录内部技术图表和流程能够减轻事件响应分析师的工作负担，帮助他们快速获得必要的机构知识以响应安全事件。全面记录内部技术流程不仅可以简化安全调查，还可以根据流程的合理性和评估进行调整。
# 制定事件响应行动手册
准备事件响应流程的关键环节是制定行动手册。事件响应行动手册提供了一系列规范性指南和步骤，供发生安全事件时遵循。清晰的结构和步骤可简化响应，减少发生人为错误的可能性。
# 应针对哪些事件场景创建行动手册
应针对以下事件场景创建行动手册：
+ **预期事件**：应针对预期的事件创建行动手册。这包括拒绝服务（DoS）、勒索软件和凭证泄露等威胁。
+ **已知的安全调查发现或警报**：应针对已知的安全调查发现和警报（如 GuardDuty 调查发现）创建行动手册。您可能会收到一个 GuardDuty 调查发现，然后想：“现在怎么办？” 为防止错误处理 GuardDuty 调查发现或忽略调查发现，应针对每个可能的 GuardDuty 调查发现创建行动手册。有关补救细节和指导的信息可在 [GuardDuty 文档](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)中找到。需要注意的是，默认情况下并不会启用 GuardDuty，而且需要付费。有关 Guarduty 的更多信息，请参阅附录 A：云功能定义 – [可见性和警报](visibility-and-alerting.md)。
# 行动手册应包含的内容
行动手册应包含安全分析师需要完成的技术步骤，以便充分调查和应对潜在的安全事件。
行动手册中应包括的项目有：
+ **行动手册概述**：本行动手册针对哪些风险或事件场景？ 本行动手册的目标是什么？
+ **先决条件**：此事件场景需要哪些日志和检测机制？ 预期的通知是什么？
+ **利益相关者信息**：涉及哪些人员？其联系人信息是什么？ 每个利益相关方的责任是什么？
+ **响应步骤**：在事件响应的各个阶段，应采取哪些战术性措施？ 分析师应该进行哪些查询？ 应该运行什么代码才能达到预期的结果？
+ **检测**：如何检测事件？
+ **分析**：如何确定影响范围？
+ **遏制**：如何隔离事件来限制其影响范围？
+ **根除**：如何从环境中消除威胁？
+ **恢复**：受影响的系统或资源将如何恢复生产？
+ **期望结果**：运行查询和代码后，行动手册的期望结果是什么？
为确保每个行动手册中的信息一致，创建一个行动手册模板供其他安全行动手册参考会很有帮助。先前列出的某些项目，例如利益相关者信息，可以在多个行动手册中共享。在这种情况下，您可以为这些信息创建集中管理的文档，并在行动手册中引用，然后在行动手册中明确列举出差异。如此一来，您无需在所有单独的行动手册中更新相同的信息。通过创建模板并识别行动手册中的通用或共享信息，您可以简化并加速行动手册的制定过程。最后，行动手册可能会随着时间推移而演变；您确认步骤一致后，这便构成了自动化的需求基础。
# 示例行动手册
有关大量示例行动手册，请参阅附录 B 中的[行动手册资源](appendix-b-incident-response-resources.md#playbook-resources)。此处的示例可用于指导您创建哪些行动手册以及行动手册应包含哪些内容。然而，至关重要的是，所制定的行动手册应涵盖与您的业务最相关的风险。您需要确认行动手册中的步骤和工作流程是否包含相关技术和流程。
# 定期进行模拟
随着组织不断发展壮大，威胁形势也会不断变化，因此，必须持续评估组织的事件响应能力。模拟便是可用于执行这种评估的一种方法。模拟过程使用现实世界中的安全事件场景，旨在模仿威胁主体采取的战术、技术和程序（TTP），让组织通过响应现实中可能发生的模拟网络事件，来练习和评估自己的事件响应能力。
模拟有多种好处，包括：
+ 检验网络准备情况，有助于事件响应人员树立信心。
+ 测试工具和工作流程的准确性和有效性。
+ 完善沟通和上报环节，使之与您的事件响应计划相吻合。
+ 提供机会来应对不太常见的攻击载体。
# 模拟类型
模拟主要分为三种类型：
+ **桌面演练**：桌面演练模拟方法严格来说是一种基于讨论的研讨会，让各个事件响应利益相关者参与进来，练习角色和职责，以及练习使用既定的沟通工具和行动手册。通常是用一整天的时间在虚拟场地和/或实地中协调完成演练。由于桌面演练以讨论为基础的特性，因而其侧重于流程、人员和协作。在讨论中，技术是必不可少的一部分，但事件响应工具或脚本的实际使用通常不包括在桌面演练中。
+ **紫队演练**：紫队演练可提高事件响应人员（*蓝队*）和模拟威胁行为者（*红队*）之间的协作能力。蓝队通常由安全运营中心（SOC）的成员组成，但也可以包括在实际网络事件中会参与进来的其他利益相关者。红队通常由渗透测试团队或接受过攻击安全培训的关键利益相关者组成。在设计场景时，红队会与演练协调员相互协作，以确保场景的准确性与可行性。在紫队演练中，主要的关注点是支持事件响应工作的检测机制、工具和标准操作程序（SOP）。
+ **红队演练**：在红队演练中，进攻方（*红队*）模拟进行攻击，以在预定范围内实现特定目标或一系列目标。防御方（*蓝队*）不一定知道演练的范围和持续时间，如此，可以更真实地评估他们应对真实事件的能力。由于红队的演练可能是侵入性测试，因此务必谨慎行事，并实施控制措施，以确保该演练不会对环境造成实际破坏。
**注意**
AWS 要求客户在进行紫队或红队演练之前，先查看[渗透测试网站](https://aws.amazon.com/security/penetration-testing/)上提供的渗透测试策略。
表 1 总结了这几类模拟的一些主要差异。值得注意的是，这些定义通常视为宽泛定义，可根据组织需求进行自定义。
*表 1 – 模拟类型*
| | 桌面演练 | 紫队演练 | 红队演练 |
| --- | --- | --- | --- |
| 总结 | 此类演练基于文档，专注于一个特定的安全事件场景。可以是高级别的，也可以是技术性的，并通过一系列书面预设场景推动演练进程。 | 相较于桌面演练，此类演练更贴近现实。紫队演练期间，协调员需要与参与者协作，以提升演练参与度，并在必要时提供培训。 | 此类演练通常提供更高级别的模拟形式。具有高度的隐蔽性，参与者可能并不知晓演练的所有细节。 |
| 所需资源 | 所需技术资源较少 | 需要多方利益相关者参与，且需要高水平的技术资源 | 需要多方利益相关者参与，且需要高水平的技术资源 |
| 复杂性 | 低 | 中 | 高 |
请考虑定期协调开展网络模拟。对于参与者和整个组织而言，每种演练类型都可以带来独特的好处，因此您可以选择从不太复杂的模拟类型（例如桌面演练）入手，然后再慢慢过渡到较为复杂的模拟类型（红队演练）。您应根据自身的安全成熟度、资源和期望结果选择模拟类型。由于红队演练的复杂性和成本，一些客户可能不会选择进行红队演练。
# 演练生命周期
无论您选择哪种模拟类型，模拟通常都遵循以下步骤：
1. **定义核心演练要素**：定义模拟场景和模拟要达成的目标。这两者都应该得到领导层的认同。
1. **确定关键利益相关者**：演练至少需要演练协调员和参与者。根据具体的场景，可能会涉及其他利益相关方，例如法务、通信或行政等领域的领导层。
1. **构建和测试场景**：如果有特定要素不可行，则可能需要在构建时重新定义该场景。本阶段的期望结果是最终确定的场景。
1. **协调开展模拟**：采用的模拟类型决定了所需的协调工作（书面讨论场景对比高技术含量的模拟场景）。协调员应根据演练目标调整其协调战术，并应尽可能让所有演练参与者都参与进来，以实现最大利益。
1. **撰写事后报告（AAR）**：确定哪些方面进展较为顺利、哪些方面需要改进以及可能存在的差距。AAR 应衡量模拟的有效性，并记录团队对模拟事件的响应情况，以便在将来的模拟中可以不断跟踪进度。
# Technology
如果您在安全事件发生之前开发并采用适当的技术，事件响应人员将能够及时进行调查、了解范围并采取行动。
# 创建 AWS 账户结构
[AWS Organizations](https://aws.amazon.com/organizations/) 有助于您随着 AWS 资源的增长和扩展，集中管理和监管 AWS 环境。AWS 组织会整合您的 AWS 账户，这样您就能够将这些账户作为一个单元进行管理。您可以使用组织单元 (OU)，将账户分组到一起，作为一个单元管理。
对于事件响应，拥有一个支持事件响应功能的 AWS 账户结构（包括*安全组织单元*和*取证组织单元*）会很有帮助。在安全 OU 中，您应该拥有以下账户：
+ **日志存档**：将日志聚合到日志存档 AWS 账户中。
+ **安全工具**：将安全服务集中在安全工具 AWS 账户中。此账户以安全服务的委托管理员身份运行。
在取证 OU 中，您可以选择实施单一取证账户，也可以为您运营的每个区域实施账户，具体取决于哪种账户最适合您的业务和运营模式。以根据区域创建账户方法为例，如果您只在美国东部（弗吉尼亚州北部）(us-east-1) 和美国西部（俄勒冈州）(us-west-2) 运营，那么您将在取证组织单元中拥有两个账户：一个用于 us-east-1，另一个用于 us-west-2。由于预置新账户需要时间，因此必须在事件发生前创建和分析取证账户，以便响应人员能够做好准备，有效地使用这些账户进行响应。
下图显示了一个账户结构示例，其中包括一个取证 OU，涵盖了根据每个区域创建的取证账户：
![\[用于响应事件而根据区域创建的账户结构示意图\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/images/incident-response-account-structure.png)
# 制定和实施标记策略
要获取围绕 AWS 资源的业务场景和相关内部利益相关方的背景信息，可能很困难。要做到这一点，可以采用标签的形式，标签为 AWS 资源分配元数据，并由用户定义的键和值组成。您可以创建标签，按照用途、所有者、环境、处理的数据类型以及您选择的其他标准对资源进行分类。
采用一致的标记策略可以让您快速识别和辨别 AWS 资源的背景信息，从而加快响应速度。标签还可以充当启动自动响应的机制。有关要标记内容的更多信息，请参阅文档 [AWS 资源标记方法](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。首先，您需要定义要在组织内实施的标签。之后，实施并强制执行这一标记策略。有关实施和强制执行的详细信息，请参阅 AWS 博客《[Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)》。
# 更新 AWS 账户联系人信息
对于每个 AWS 账户，提供准确且最新的联系人信息至关重要，这样才能确保正确的利益相关者收到来自 AWS 的安全性、账单和运营等主题的重要通知。对于每个 AWS 账户，需设置一位主要联系人以及多位负责安全性、账单和运营的备用联系人。有关这些联系人之间的区别，请参阅《[AWS Account Management Reference Guide](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate)》。
有关管理备用联系人的详细信息，请参阅[有关添加、更改或删除备用联系人的 AWS 文档](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html#manage-account-payment-alternate-contacts)。如果您的团队负责处理账单、运营和安全性相关问题，使用电子邮件通讯组列表是一种最佳实践。电子邮件通讯组列表可以消除对某一成员的依赖，避免因其不在办公室或离开公司而造成工作停滞。您还应确保电子邮件和账户联系人信息（包括电话号码）得到充分保护，以避免根账户密码重置和多重身份验证（MFA）重置。
对于使用 AWS Organizations 的客户，组织管理员可以使用管理账户或委托管理员账户，集中管理成员账户的备用联系人，而无需每个 AWS 账户的凭证。但是，您还需确保新创建的账户提供了准确的联系人信息。请参阅博客文章《[Automatically update alternate contacts for newly created AWS 账户](https://aws.amazon.com/blogs/mt/automatically-update-alternate-contacts-for-newly-created-aws-accounts/)》。
# 准备 AWS 账户访问权限
在事件发生期间，事件响应团队必须有权访问事件中涉及的环境和资源。在事件发生之前，确保团队具有履行其职责的适当访问权限。为此，您应了解团队成员所需的访问级别（例如，他们可能采取哪些行动），且应提前预置最低访问权限。
要实施和配置此访问权限，您应与组织的云架构师确定并讨论 AWS 账户策略和云身份策略，以了解配置了哪些身份验证和授权方法。由于这些凭证的特权性质，在实施过程中，您应考虑使用审批流程，或从保管库或保险箱中检索凭证。实施后，您应在事件发生之前尽早记录并测试团队成员的访问权限，确保他们能够立即做出响应。
最后，专门创建用于响应安全事件的用户通常具有特权，以便提供足够的访问权限。因此，应当限制并监控这些凭证的使用，不得将其用于日常活动。
# 了解威胁形势
## 开发威胁模型
通过开发威胁模型，组织能够先于未经授权的用户识别威胁并制定缓解措施。有多种威胁建模策略和方法可供选择；请参阅博客文章《[How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)》。对于事件响应，威胁模型有助于识别威胁行为者在事件发生期间可能使用的攻击向量。理解您需要防御的对象对于及时响应至关重要。您也可以使用 AWS Partner 进行威胁建模。要查找 AWS 合作伙伴，请使用 [AWS Partner Network](https://partners.amazonaws.com/)。
## 整合和利用网络威胁情报
网络威胁情报是指关于威胁行为者意图、机会及能力的数据和分析。获取和利用威胁情报有助于尽早检测到事件并更好地了解威胁行为者的行为。网络威胁情报包括静态指标，例如 IP 地址或恶意软件的文件哈希值。它还包括高级别信息，例如行为模式和意图。您可以从多家网络安全供应商和开源存储库收集威胁情报。
要为 AWS 环境整合并最大限度地利用威胁情报，您可以使用一些开箱即用功能，并整合自己的威胁情报列表。Amazon GuardDuty 使用 AWS 内部及第三方威胁情报源。其他 AWS 服务，例如 DNS 防火墙和 AWS WAF 规则，也接收来自 AWS 高级威胁情报组的输入。部分 GuardDuty 调查发现映射到 [MITRE ATT&CK 框架](https://attack.mitre.org/)，该框架可提供有关攻击者策略和技术的实际观察信息。
# 选择并设置用于分析和报警的日志
在安全调查期间，您需要能够查看相关日志，以便记录并了解事件的来龙去脉和时间线。生成警报时也需要日志，因为日志可以指示某些相关操作已经发生。选择、启用、存储、设置查询和检索机制以及设置警报至关重要。本节将回顾上述每个操作。有关更多详细信息，请参阅 AWS 博客文章《[Logging strategies for security incident response](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)》。
# 选择并启用日志源
进行安全调查之前，您需要捕获相关日志，以便以回溯方式重建 AWS 账户中的活动。选择并启用与其 AWS 账户工作负载相关的日志源。
AWS CloudTrail 是一项日志记录服务，可跟踪针对 AWS 账户捕获 AWS 服务活动所进行的 API 调用。它在默认情况下启用，管理事件保留 90 天，可以使用 AWS 管理控制台、AWS CLI 或 AWS SDK [通过 CloudTrail 事件历史记录工具检索](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)这些事件。为了更长久地保留和了解数据事件，您需要[创建 CloudTrail 跟踪](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)并将其与 Amazon S3 存储桶关联，也可以选择与 CloudWatch 日志组关联。或者，您可以创建 [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html)，这可保留 CloudTrail 日志最多七年，并提供基于 SQL 的查询工具。
AWS 建议使用 VPC 的客户分别使用 [VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)和 [Amazon Route 53 Resolver 查询日志](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)启用网络流量和 DNS 日志，并将其流式传输到 Amazon S3 存储桶或 CloudWatch 日志组。您可以为 VPC、子网或网络接口创建 VPC 流日志。对于 VPC 流日志，您可以选择启用流日志的方式和位置，以降低成本。
AWS CloudTrail 日志、VPC 流日志和 Route 53 解析器查询日志是支持 AWS 中安全调查的*基本日志记录三要素*。
AWS 服务可以生成基本日志记录三要素未捕获到的日志，如弹性负载均衡日志、AWS WAF 日志、AWS Config 记录器日志、Amazon GuardDuty 调查发现、Amazon Elastic Kubernetes Service（Amazon EKS）审计日志，以及 Amazon EC2 实例操作系统和应用程序日志。有关日志记录和监控选项的完整列表，请参阅[附录 A：云功能定义](appendix-a-cloud-capability-definitions.md)。
# 选择日志存储
日志存储的选择通常与您使用的查询工具、保留能力、熟悉程度和成本有关。启用 AWS 服务日志时，需要提供存储工具；通常是 Amazon S3 存储桶或 CloudWatch 日志组。
Amazon S3 存储桶提供持久且经济高效的存储，并具有可选的生命周期策略。可以使用 Amazon Athena 等服务本地查询存储在 Amazon S3 存储桶中的日志。CloudWatch 日志组通过 CloudWatch Logs Insights 提供持久存储和内置查询工具。
# 确定适当的日志保留
使用 S3 存储桶或 CloudWatch 日志组存储日志时，必须为每个日志源建立足够的生命周期，以优化存储和检索成本。客户通常可以查询三个月到一年的日志，日志保留期最多七年。可用性和保留时长的选择应与您的安全要求以及法律法规和业务授权的综合因素相一致。
# 选择和实施日志查询机制
在 AWS 中，可以用来查询日志的主要服务包括 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)（用于查询存储在 CloudWatch 日志组中的数据）和 [Amazon Athena](https://aws.amazon.com/athena/) 和 [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/)（用于查询存储在 Amazon S3 中的数据）。您还可以使用第三方查询工具，如安全信息和事件管理（SIEM）。
选择日志查询工具的过程中，应考虑安全运营的人员、流程和技术方面。选择一款能够满足运营、业务和安全要求并可长期使用和维护的工具。请记住，当要扫描的日志数量保持在工具的限制范围内时，日志查询工具的工作状态最佳。由于成本或技术限制，客户拥有多款查询工具的情况并不罕见。例如，客户可能会使用第三方 SIEM 对过去 90 天的数据执行查询，但由于 SIEM 的日志提取成本较高，会使用 Athena 来执行 90 天以上的查询。无论采用何种实施方式，都要验证您的方法能够尽可能地减少充分提高运营效率所需的工具数量，尤其在安全事件调查期间。
# 使用日志发出警报
AWS 通过 Amazon GuardDuty、[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) 和 AWS Config 安全服务，自身就能提供警报功能。您也可以使用自定义警报生成引擎来处理这些服务未涵盖的安全警报或与环境相关的特定警报。本文档的[检测](detection.md)一节介绍了如何构建这些警报和检测。
# 构建取证能力
在发生安全事件之前，可以考虑构建取证能力来支持安全事件调查工作。NIST 发布的《[Guide to Integrating Forensic Techniques into Incident Response](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-86.pdf)》提供了此类指导。
# AWS 取证
传统本地取证的概念适用于 AWS。博客文章《[Forensic investigation environment strategies in the AWS 云](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)》提供了关键信息，便于您开始将取证专业知识迁移到 AWS。
设置好取证的环境和 AWS 账户结构后，需要确定在以下四个阶段有效执行可靠取证方法所需的技术：
+ **收集**：收集相关的 AWS 日志，例如 AWS CloudTrail、AWS Config、VPC 流日志和主机级日志。收集受影响的 AWS 资源的快照、备份和内存转储。
+ **检查**：通过提取和评测相关信息来检查收集到的数据。
+ **分析**：分析收集到的数据，以便了解事件并从中得出结论。
+ **报告**：提供分析阶段得出的信息。
# 捕获备份和快照
为关键系统和数据库建立备份对于从安全事件中恢复和取证至关重要。有了备份，您就能够将系统恢复到以前的安全状态。在 AWS 上，您可以创建各种资源的快照。快照为您提供这些资源的时间点备份。有许多 AWS 服务能够在备份和恢复方面为您提供支持。有关这些服务以及备份和恢复方法的详细信息，请参阅 [Backup and Recovery Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html)。有关更多详细信息，请参阅博客文章《[Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/)》。
特别是遇到勒索软件等情况时，妥善保护备份至关重要。有关保护备份的指导，请参阅博客文章《[Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/)》。除了确保备份安全外，您还应当定期测试备份和还原流程，从而确保现有的技术和流程按预期运行。
# AWS 上的取证自动化功能
在安全事件发生期间，您的事件响应团队必须能够快速收集和分析证据，同时保持事件相关时间段的准确性。对于事件响应团队来说，在云环境中手动收集相关证据既具有挑战性又很耗时，尤其是在存在大量实例和账户的情况下。此外，手动收集容易出现人为错误。出于这些原因，客户应该开发和实现取证自动化功能。
AWS 提供了大量用于取证的自动化资源，这些资源已整合到附录的[取证资源](appendix-b-incident-response-resources.md#forensic-resources)中。这些资源是我们开发并由客户实施的取证模式示例。虽然这些资源可能是有用的参考架构，但可以考虑根据您的环境、要求、工具和取证流程对资源进行修改，或者创建新的取证自动化模式。
# 准备项目总结
要实现及时有效的事件响应，为响应安全事件做好充分准备至关重要。事件响应准备涉及人员、流程和技术。就响应准备而言，这三个领域都同等重要。因此，您应该针对这三个领域准备和完善事件响应计划。
表 2 总结了本节中详述的准备项目。
*表 2 – 事件响应准备项目*
| 域： | 准备项目 | 操作项 |
| --- | --- | --- |
| 人员 | 定义角色和职责。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 人员 | 对事件响应人员进行 AWS 培训。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 人员 | 了解 AWS 支持选项。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 流程 | 制定事件响应计划。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 流程 | 记录并集中管理架构图。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 流程 | 制定事件响应行动手册。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 流程 | 定期进行模拟。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 规划 AWS 账户结构。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 制定和实施标记策略，帮助响应人员确定调查发现的所有权和背景情况。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 更新 AWS 账户联系人信息。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 准备 AWS 账户访问权限。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 了解威胁形势。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 选择并设置日志。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
| 技术 | 开发取证能力。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/preparation-summary.html) |
建议采用迭代方法进行事件响应准备。所有这些准备项目皆无法一蹴而就；您应该制定计划，从小处着手，随着时间的推移不断提升事件响应能力。
# 操作
“操作”是执行事件响应的核心。这是响应和修复安全事件的操作发生的地方。“操作”包括以下五个阶段：*检测*、*分析*、*遏制*、*根除*和*恢复*。表 3 提供了这些阶段和目标的描述。
*表 3 – 操作阶段*
| 阶段 | 目标 |
| --- | --- |
| 检测 | 识别潜在的安全事件。 |
| 分析 | 确定安全事件是否为意外事件，并评估事件的影响范围。 |
| 遏制 | 尽量减小和限制安全事件的影响范围。 |
| 根除 | 移除与安全事件相关的未经授权的资源或构件。实施可消除安全事件的缓解措施。 |
| 恢复 | 将系统恢复到已知安全状态并监控这些系统，确认威胁不会再次出现。 |
在应对和处理安全事件时，应将这些阶段作为指导，以便有效且可靠地进行响应。采取的实际操作会因事件而异。例如，涉及勒索软件的事件要遵循的响应步骤与涉及公共 Amazon S3 存储桶的事件不同。此外，这些阶段不一定按顺序发生。在遏制和根除之后，您可能需要重新分析，了解操作是否有效。
# 检测
警报是检测阶段的主要组成部分。它会根据需要关注的 AWS 账户威胁活动生成通知，以启动事件响应流程。
确保警报准确性颇具挑战性；因为通常无法完全确定事件是否已经发生、正在进行还是将在未来发生。原因如下：
+ 检测机制基于基准偏差、已知模式以及来自内部或外部实体的通知。
+ 由于技术和人员（分别指安全事件的*手段*和*行为者*）的不可预测性，基准会随着时间的推移而变化。新型或经过修改的威胁行为者*战术*、*技术*和*程序*（TTP）会导致新的恶意模式出现。
+ 对人员、技术和流程的更改不会立即纳入事件响应流程。部分变更是在调查过程中发现的。
# 警报源
您应考虑使用以下源来定义警报：
+ **调查发现**：AWS 服务，例如 [Amazon GuardDuty](https://aws.amazon.com/guardduty/)、[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)、[Amazon Macie](https://aws.amazon.com/macie/)、[Amazon Inspector](https://aws.amazon.com/inspector/)、[AWS Config](https://aws.amazon.com/config/)、[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) 和[网络访问分析器](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html)等，可以生成用于制作警报的调查发现。
+ **日志**：存储在 Amazon S3 存储桶和 CloudWatch 日志组中的 AWS 服务、基础设施和应用程序日志，在经过解析和关联之后，可以生成警报。
+ **账单活动**：如果账单活动突然发生变化，则表示发生了安全事件。请按照文档[创建账单警报以监控 AWS 预估费用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)进行监控。
+ **网络威胁情报**：如果您订阅了第三方网络威胁情报源，则可将该信息与其他日志记录和监控工具关联起来，以确定事件的潜在指标。
+ **合作伙伴工具**：AWS Partner Network（APN）中的合作伙伴可提供助您实现安全目标的顶级产品。对于事件响应，具备端点检测与响应（EDR）或 SIEM 的合作伙伴产品可助您实现事件响应目标。有关更多信息，请参阅[安全能力合作伙伴](https://aws.amazon.com/security/partner-solutions/)和[AWS Marketplace 中的安全解决方案](https://aws.amazon.com/marketplace/solutions/security)。
+ **AWS 信任和安全**：如果我们发现滥用或恶意活动，支持 可能会联系客户。
+ **一次性联系渠道**：由于注意到异常情况的可能是客户、开发人员或组织中的其他员工，因此确立一种广为人知的安全团队联系方式至关重要。常见选择包括工单系统、联系人电子邮件地址和网页表单。如果组织与公众协同合作，则可能还需要一个面向公众的安全联系机制。
有关调查阶段可以使用的云功能的更多信息，请参阅本文档中的[附录 A：云功能定义](appendix-a-cloud-capability-definitions.md)一节。
# 检测属于安全控制措施工程的一部分
检测机制是制定安全控制措施不可或缺的一部分。定义*指令性*控制措施和*预防性*控制措施时，应同时设立相关的*检测性*控制措施和*响应性*控制措施。例如，某组织设立了与 AWS 账户根用户相关的指令性控制措施，该控制措施仅应用于明确定义的特定活动。组织将其与通过 AWS 组织的服务控制策略（SCP）实施的预防性控制措施相关联。如果根用户活动超出预期基准，通过 EventBridge 规则和 SNS 主题实施的检测性控制措施将向安全运营中心（SOC）发出警报。响应性控制措施则要求 SOC 选择适当的行动手册、执行分析，并持续工作直至事件解决。
安全控制措施最好通过对 AWS 中运行的工作负载进行威胁建模来定义。检测性控制措施的严重程度需要查看特定工作负载的业务影响分析（BIA），据此确定。检测性控制措施生成的警报不会按接收顺序处理，而会根据其初始严重程度进行处理，以便在分析期间进行调整。虽然设定的初始严重程度有助于排列优先顺序，但发生警报的具体环境决定了真正的严重程度。例如，组织将 Amazon GuardDuty 用作检测性控制措施的组成部分，用于保护属于工作负载的 EC2 实例。此时，将生成调查发现 `Impact:EC2/SuspiciousDomainRequest.Reputation`，告知您工作负载中列出的 Amazon EC2 实例正在查询疑似恶意的域名。默认情况下，此警报会设置为低严重性，但随着分析阶段的深入，确定未经授权的行为者部署了数百个 `p4d.24xlarge` 类型 EC2 实例，导致组织运营成本激增。在这种情况下，事件响应团队决定将此警报的严重程度调整为*高*，从而提升紧迫感并加快进一步的行动。请注意，GuardDuty 调查发现的严重性无法更改。
# 实施检测性控制措施
了解检测性控制措施的实施方式至关重要，因为这有助于确定警报将如何用于特定事件。检测性技术控制措施主要有两种实施方式：
+ **行为检测**依赖于通常称为机器学习（ML）或人工智能（AI）的数学模型。检测基于推断进行；因此，警报不一定反映实际事件。
+ **基于规则的检测**是确定性的；客户可以设定需要发出警报的确切活动参数，结果是确定的。
现代检测系统 [例如入侵检测系统（IDS）] 的实现通常同时包含这两种机制。以下是使用 GuardDuty 进行基于规则的检测和行为检测的一些示例。
+ 调查发现 `Exfiltration:IAMUser/AnomalousBehavior` 生成后，将通知您，“在您的账户中观察到异常的 API 请求。” 当您进一步查阅文档时，将提示您“机器学习模型会评估您账户中的所有 API 请求，并识别与攻击者所用技术相关的异常事件”，这表明该调查发现具有行为检测的特性。
+ 对于调查发现 `Impact:S3/MaliciousIPCaller`，GuardDuty 会分析 CloudTrail 中来自 Amazon S3 服务的 API 调用，将 `SourceIPAddress` 日志元素与包含威胁情报源的公有 IP 地址表进行比对。发现直接匹配的条目后，便会生成调查发现。
我们建议混合使用行为警报和规则警报，因为针对威胁模型中的每项活动发出基于规则的警报并非总是可行。
# 基于人员的检测
至此，我们讨论的都是基于技术的检测。另一个重要的检测源来自客户组织内部或外部的人员。*内部人员*可定义为员工或承包商，*外部人员*则包括安全研究人员、执法机构、新闻媒体和社交媒体等实体。
尽管基于技术的检测可以进行系统性配置，但基于人员的检测形式多种多样，包括电子邮件、工单、邮件、新闻文章、电话以及面对面交流。基于技术的检测通知有望近乎实时地发送，但对于基于人员的检测，则没有明确的时间预期。安全文化必须接纳、促进并充分发挥基于人员的检测机制的作用，以实现深度防御的安全方法。
# 摘要
在检测方面，将基于规则的警报与行为驱动的警报结合使用非常重要。此外，应构建相应机制，便于内部人员和外部人员就安全问题提交工单。工作人员可能是安全事件最宝贵的来源之一，因此制定供工作人员上报疑虑的流程至关重要。您应利用针对环境的威胁模型来着手构建检测机制。威胁模型将帮助您基于与环境最相关的威胁来生成警报。最后，您可以借助 MITRE ATT&CK 等框架来了解威胁行为者的战术、技术和程序（TTP）。MITRE ATT&CK 框架可作为一种通用语言，促进您对各种检测机制的理解。
# 分析
日志、查询功能与威胁情报是分析阶段所需的一些支持性组成部分。检测阶段使用的许多相同日志同样适用于分析，但需要接入并配置查询工具。
# 验证警报、限定警报范围并评估其影响
在分析阶段，将执行全面的日志分析，旨在验证警报、定义范围并评估潜在入侵的影响。
+ 警报*验证*是分析阶段的入口点。事件响应人员将查找来自各种源的日志条目，并直接联系受影响工作负载的所有者。
+ 下一步是*限定范围*，在此过程中会清点所有涉及的资源，并在利益相关者一致认为不太可能是误报后，调整警报的严重性。
+ 最后，*影响分析*会详细说明实际的业务中断情况。
确定受影响的工作负载组件后，便可将范围限定结果与相关工作负载的恢复点目标（RPO）和恢复时间目标（RTO）相关联，同时考虑调整警报严重性，这将启动资源分配以及后续的所有活动。并非所有事件都会直接中断支持业务流程的工作负载运营。敏感数据泄露、知识产权盗窃或资源劫持（例如用于加密货币挖矿）等事件可能不会立即停止或削弱业务流程，但可能在后期导致严重后果。
# 完善安全日志与调查发现
## 利用威胁情报和组织背景进行完善
在分析过程中，需要对值得关注的可观测对象进行完善，以提升警报的背景关联性。如“准备”一节所述，整合并利用网络威胁情报有助于更深入地了解安全调查发现。威胁情报服务可用于为公有 IP 地址、域名和文件哈希值分配信誉和属性所有权。这些工具既提供付费服务，也提供免费服务。
采用 Amazon Athena 作为日志查询工具的客户，可以利用 AWS Glue 作业的优势，将威胁情报信息加载为表格。威胁情报表可用于 SQL 查询，以关联 IP 地址和域名等日志元素，为待分析数据提供丰富视图。
AWS 不会向客户直接提供威胁情报，但 Amazon GuardDuty 等服务会利用威胁情报进行完善并生成调查发现。您也可以根据自己的威胁情报，将自定义威胁列表上传到 GuardDuty。
## 利用自动化进行完善
自动化是 AWS 云 治理不可或缺的一部分，可应用于事件响应生命周期的各个阶段。
在检测阶段，基于规则的自动化会匹配日志中威胁模型的关注模式，并采取相应的操作，例如发送通知。分析阶段可利用检测机制，将警报正文转发给能够查询日志和完善可观测对象以进行事件背景关联的引擎。
警报正文的基本形式由*资源*和*身份*组成。例如，您可以自动查询 CloudTrail，以了解警报正文的身份或资源在警报生成前后执行的 AWS API 活动，进而提供更多见解，例如已识别 API 活动的 `eventSource`、`eventName`、`SourceIPAddress` 和 `userAgent` 等等。通过执行这些自动化查询，响应人员可在分类期间节省时间，并获取更多背景情况，有助于做出更明智的决策。
请参阅博客文章《[How to enrich AWS Security Hub findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/)》，了解有关如何利用自动化功能完善安全调查发现并简化分析的示例。
# 收集和分析取证证据
如本文档[准备](preparation.md)一节所述，取证是在事件响应期间收集和分析构件的过程。在 AWS 上，它不仅适用于基础架构域资源，例如网络流量数据包捕获、操作系统内存转储，也适用于服务域资源，例如 AWS CloudTrail 日志。
取证过程具有以下基本特征：
+ **一致性**：严格遵循所记录的确切步骤，没有偏差。
+ **可重复性**：对同一个构件重复执行操作时，会产生完全相同的结果。
+ **惯用性**：会公开记录并被广泛采用。
维护事件响应期间所收集构件的监管链至关重要。除了将构件存储在只读存储库外，使用自动化并生成此收集过程的自动文档也会有所帮助。应仅对所收集构件的精确副本进行分析，以保持完整性。
# 收集相关构件
牢记这些特性，基于相关警报以及对其影响范围的评估，需要收集与进一步调查和分析相关的数据。可能与调查相关的各类数据及其来源包括：服务/控制面板日志（CloudTrail、Amazon S3 数据事件、VPC 流日志）、数据（Amazon S3 元数据和对象）以及资源（数据库、Amazon EC2 实例）。
可收集服务/控制面板日志以进行本地分析，或者理想情况下，使用 AWS 原生服务直接查询（如适用）。可直接查询数据（包括元数据）以获取相关信息或获取源对象；例如，使用 AWS CLI 以获取 Amazon S3 存储桶和对象元数据，并直接获取源对象。必须按照与资源类型及预期分析方法相符的方式收集资源。例如，可通过以下方式收集数据库：创建运行数据库的系统的副本/快照、创建整个数据库本身的副本/快照，或查询并提取数据库中与调查相关的特定数据和日志。
对于 Amazon EC2 实例，应收集一组特定数据，同时应遵循特定的收集顺序，以获取和保留最多数据以供分析和调查。
具体而言，从 Amazon EC2 实例获取和保留最多数据的响应顺序如下：
1. **获取实例元数据**：获取与调查和数据查询相关的实例元数据（实例 ID、类型、IP 地址、VPC/子网 ID、区域、亚马逊机器映像（AMI）ID、附加的安全组、启动时间）。
1. **启用实例保护和标签**：启用实例保护，例如终止保护、将关闭行为设为停止（如果设为终止）、禁用附加 EBS 卷的“终止时删除”属性，以及应用适当的标签以用于视觉标记和可能的响应自动化（例如，在应用名称为 `Status`、值为 `Quarantine` 的标签时，执行数据取证获取并隔离实例）。
1. **获取磁盘（EBS 快照）**：获取附加 EBS 卷的 EBS 快照。每个快照包含将数据（拍摄快照时的数据）还原到新 EBS 卷所需的信息。如果您使用的是实例存储卷，请参阅执行实时响应/构件收集的步骤。
1. **获取内存**：由于 EBS 快照只能捕获已写入 Amazon EBS 卷的数据（可能会排除应用程序或操作系统存储或缓存在内存中的数据），因此必须使用合适的第三方开源或商业工具获取系统内存映像，这样才能获取系统中的可用数据。
1. **（可选）执行实时响应/构件收集**：仅在无法通过其他方式获取磁盘或内存，或存在有效的业务或操作原因时，才能通过系统上的实时响应执行针对性数据收集（磁盘/内存/日志）。执行此操作将修改重要的系统数据和构件。
1. **停用实例**：将实例与自动扩缩组分离、从负载均衡器注销实例，并调整或应用具有最低权限或无权限的预构建实例配置文件。
1. **隔离或遏制实例**：通过终止和阻止当前及未来与该实例的双向连接，验证实例是否已与环境中的其他系统和资源有效隔离。有关详细信息，请参阅本文档的[遏制](containment.md)一节。
1. **响应人员选择**：根据具体情况和目标，选择下列选项之一：
+ 停用并关闭系统（建议）。
获取可用证据后关闭系统，以确保缓解措施是否最有效，防止实例将来可能会对环境造成的影响。
+ 在配备监控工具的隔离环境中继续运行实例。
尽管不建议将其作为标准方法，但如果存在需要对实例进行持续观测的情况（例如需要其他数据或指标以对实例进行全面调查和分析时），可以考虑关闭实例，创建实例的 AMI，然后在已预置为完全隔离且配备检测工具（例如 VPC 流日志或 VPC Traffic Mirroring）的沙盒环境中，使用专用的取证账户重新启动该实例，以便近乎持续地监控该实例。
**注意**
必须在执行实时响应活动、系统隔离或关闭之前捕获内存，这样才能捕获可用的易失性（且宝贵的）数据。
# 编写叙述
在分析和调查期间，需记录所采取的操作、执行的分析以及确定的信息，以供后续阶段使用，并生成最终报告。这些叙述应当简洁准确，确认包含相关信息以验证对事件的有效理解，并维护准确的时间线。与核心事件响应团队之外的人员交流时，这些叙述也很有帮助。示例如下：
****
*市场销售部门于 2022 年 3 月 15 日收到一封勒索信函，要求支付加密货币，否则将公开发布潜在敏感数据。SOC 发现，属于市场销售部门的 Amazon RDS 数据库在 2022 年 2 月 20 日处于公开访问状态。SOC 查询了 RDS 访问日志，发现有人通过属于网站开发人员之一的 *Major Mary* 的凭证 `mm03434`，于 2022 年 2 月 20 日使用了 IP 地址 198.51.100.23。SOC 进一步查询了 VPC 流日志，发现约 256 MB 数据在同一天（时间戳 2022-02-20T15:50\$100Z）外流至同一 IP 地址。SOC 通过开源威胁情报确定，该凭证目前在公共存储库 `https[:]//example[.]com/majormary/rds-utils` 中以纯文本形式提供。*
# 遏制
就事件响应而言，遏制的一种定义是：在处理安全事件期间，为最大限度地缩小安全事件的范围并控制环境中未经授权使用的影响，所采取的策略执行或实现过程。
遏制策略取决于众多因素，不同组织在遏制战术的应用、时机和目的方面可能各不相同。《[NIST SP 800-61 计算机安全事件处理指南](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)》概述了确定适当遏制策略的几个标准，其中包括：
+ 资源可能遭受损害甚至被窃取
+ 需要保留证据
+ 服务可用性（网络连接、向外部提供的服务）
+ 实施策略所需的时间与资源
+ 策略有效性（部分遏制或完全遏制）
+ 解决方案持续时间（应急方案需在四小时内删除，临时方案需在两周内删除，以及永久方案）
然而，对于 AWS 上的服务，基本的遏制步骤可归纳为三类：
+ **源遏制**：使用筛选和路由功能，阻止来自特定源的访问。
+ **技术与访问遏制**：删除访问权限，阻止对受影响资源的未经授权的访问。
+ **目标遏制**：使用筛选和路由功能，阻止对目标资源的访问。
# 源容器
源遏制是指在环境中应用筛选和路由功能，阻止来自特定源 IP 地址或网络范围的资源访问。此处重点介绍了使用 AWS 服务进行源遏制的示例：
+ **安全组**：创建隔离安全组并将其应用于 Amazon EC2 实例，或从现有安全组中删除规则，有助于遏制流向 Amazon EC2 实例或 AWS 资源的未经授权的流量。请务必注意，更改安全组不会中断现有的已跟踪连接，新安全组只会有效阻止未来的流量（有关已跟踪和未跟踪连接的更多信息，请参阅 [Incident Response Playbook](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md) 和[安全组连接跟踪](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)）。
+ **策略**：可配置 Amazon S3 存储桶策略，以阻止或允许来自 IP 地址、网络范围或 VPC 端点的流量。策略能够屏蔽可疑地址并阻止对 Amazon S3 存储桶进行访问。有关存储桶策略的更多信息，请参阅[使用 Amazon S3 控制台添加存储桶策略](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)。
+ **AWS WAF**：可在 AWS WAF 上配置 Web 访问控制列表（Web ACL），以便对资源所响应的 Web 请求进行精细控制。可将 IP 地址或网络范围添加到 AWS WAF 上配置的 IP 集中，并对该 IP 集应用匹配条件（如“阻止”）。如果原始流量的 IP 地址或网络范围与 IP 集规则中配置的 IP 地址或网络范围相匹配，则这将阻止资源的 Web 请求。
如下图的源遏制示例所示，事件响应分析师修改了 Amazon EC2 实例的安全组，以限制仅允许特定 IP 地址的新连接。如前文安全组要点所述，更改安全组不会中断现有的已跟踪连接。
![\[图中显示了源遏制示例\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/images/source-containment-example.png)
**注意**
安全组和网络 ACL 不会筛选发往 Amazon Route 53 的流量。在遏制 EC2 实例时，如果想阻止其联系外部主机，请确保同时显式阻止 DNS 通信。
# 技术与访问遏制
通过限制功能和 IAM 主体对资源的访问权限，防止未经授权使用资源。这包括限制有权访问资源的 IAM 主体的权限；也包括撤销临时安全凭证。此处重点介绍了使用 AWS 服务进行技术与访问遏制的示例：
+ **限制权限**：分配给 IAM 主体的权限应遵循[最低权限原则](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)。但是，在活跃的安全事件期间，可能需要进一步限制特定 IAM 主体对目标资源的访问。在这种情况下，可以删除需遏制的 IAM 主体对资源的访问权限，以实现访问遏制。这是通过 IAM 服务完成的，可使用 AWS 管理控制台、AWS CLI 或 AWS SDK 进行操作。
+ **撤销密钥**：IAM 主体使用 IAM 访问密钥来访问或管理资源。*这些是长期静态凭证，用于签署对 AWS CLI 或 AWS API 的编程请求，以前缀 AKIA* 开头（有关更多信息，请参阅 [IAM 标识符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)中的*了解唯一 ID 前缀*部分）。如果 IAM 访问密钥已遭泄露，可停用或删除该访问密钥以遏制 IAM 主体访问。请务必记住以下事项：
+ 可以重新激活已停用的访问密钥。
+ 访问密钥一经删除，将无法恢复。
+ 在给定的任何时间，IAM 主体最多可拥有两个访问密钥。
+ 密钥停用或删除后，使用该访问密钥的用户或应用程序将失去访问权限。
+ **撤销临时安全凭证**：组织可使用临时安全凭证来控制对 AWS 资源的访问权限，此类凭证以前缀 *ASIA* 开头（有关更多信息，请参阅 [IAM 标识符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)中的*了解唯一 ID 前缀*部分）。临时凭证通常由 IAM 角色使用，因其生命周期有限，因此无需轮换或显式撤销。若在临时安全凭证到期前发生了涉及该凭证的安全事件，则可能需要更改现有临时安全凭证的有效权限。这可[借助 AWS 管理控制台 中的 IAM 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)完成。临时安全凭证也可签发给 IAM 用户（与 IAM 角色相对）；然而，截至本文撰写时，尚无法在 AWS 管理控制台 中撤销 IAM 用户的临时安全凭证。如果发生某位用户的 IAM 访问密钥被创建临时安全凭证但未经授权的用户泄露的安全事件，可通过两种方法撤销临时安全凭证：
+ 将内联策略附加到 IAM 用户，根据安全令牌签发时间阻止访问（有关更多详细信息，请参阅[禁用临时安全凭证的权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html)中的*拒绝访问在特定时间之前签发的临时安全凭证*部分）。
+ 删除访问密钥遭泄露的 IAM 用户。如有必要，可重新创建用户。
+ **AWS WAF**：未经授权的用户所用的某些技术包括常见的恶意流量模式，例如包含 SQL 注入和跨站脚本攻击（XSS）的请求。可配置 AWS WAF，利用 AWS WAF 内置的规则语句匹配和拒绝使用这些技术的流量。
如下图技术与访问遏制示例所示，事件响应人员正在轮换访问密钥或删除 IAM 策略以阻止 IAM 用户访问 Amazon S3 存储桶。
![\[图中显示了技术与访问遏制示例\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/images/technique-and-access-containment.png)
# 目标遏制
目标遏制是指在环境中应用筛选和路由功能，阻止对目标主机或资源的访问。在某些情况下，目标遏制还涉及某种形式的弹性，以确保对合法资源进行复制以保障可用性；应将资源与这些形式的弹性分离，以实现隔离和遏制。使用 AWS 服务进行目标遏制的示例包括：
+ **网络 ACL**：可在包含 AWS 资源的子网上配置的网络 ACL，还可以添加拒绝规则。这些拒绝规则可用于阻止对特定 AWS 资源的访问；但应用网络访问控制列表将影响子网上的所有资源，而不仅仅是正被未经授权访问的资源。网络 ACL 中列出的规则按自上而下的顺序进行处理，因此应将现有网络 ACL 中的首条规则配置为拒绝未经授权的流量流向目标资源和子网。或者，可以创建一个全新的网络 ACL，仅包含一条入站和出站流量的拒绝规则，并将其与包含目标资源的子网相关联，从而通过这个新的网络 ACL 阻止对子网的访问。
+ **关闭**：完全关闭资源可以有效遏制未经授权使用所造成的影响。但关闭资源也会阻止业务所需的合法访问，并妨碍获取易失性取证数据，因此这应是一个审慎的决定，并需根据组织的安全策略进行判断。
+ **隔离 VPC**：隔离 VPC 可用于有效遏制资源，同时允许访问合法流量 [例如需要访问互联网或外部管理控制台的防病毒（AV）或 EDR 解决方案]。在安全事件发生之前，可预置隔离 VPC，以允许有效的 IP 地址和端口。而在活跃的安全事件期间，可将目标资源立即移至该隔离 VPC，从而在遏制资源的同时，允许其在事件响应后续阶段发送和接收合法流量。使用隔离 VPC 的一个重要方面是，EC2 实例等资源需要先关闭，然后在新的隔离 VPC 中重新启动才能使用。现有 EC2 实例无法移至其他 VPC 或其他可用区。为此，请按照[如何将我的 Amazon EC2 实例移动到其他子网、可用区或 VPC？](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/)中概述的步骤操作。
+ **自动扩缩组和负载均衡器**：作为目标遏制程序的一部分，应分离并取消注册附加到 自动扩缩组和负载均衡器的 AWS 资源。可使用 AWS 管理控制台、AWS CLI 和 AWS SDK，分离并取消注册 AWS 资源。
如下图目标遏制示例所示，事件响应分析师向子网添加了网络 ACL，以阻止来自未经授权的主机的网络连接请求。
![\[图中显示了目标遏制示例\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/images/destination-containment.png)
# 摘要
遏制是事件响应流程中的一个步骤，可以手动完成，也可以自动执行。总体遏制策略应与组织的安全策略和业务需求保持一致，并确保在根除和恢复阶段之前尽可能有效地减轻负面影响。
# 根除
就安全事件响应而言，根除是指清除可疑或未经授权的资源，以使账户恢复到已知安全状态。根除策略取决于多种因素，而这些因素取决于组织的业务需求。
《[NIST SP 800-61 计算机安全事件处理指南](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)》提供了几个根除步骤：
1. 识别并缓解所有被利用的漏洞。
1. 清除恶意软件、不当材料及其他组件。
1. 如果发现更多受影响的主机（例如，新的恶意软件感染），则重复检测和分析步骤以识别所有其他受影响的主机，然后为其遏制和根除事件。
对于 AWS 资源，可通过可用日志或自动化工具（例如 CloudWatch Logs 和 Amazon GuardDuty）来检测和分析事件，进一步完善根除工作。应基于这些事件确定应当采取的补救措施，以将环境正确恢复到已知安全状态。
根除的第一步是确定 AWS 账户内哪些资源受到了影响。这可通过分析可用的日志数据来源、资源和自动化工具来实现。
+ 识别账户中 IAM 身份采取的未经授权的操作。
+ 识别对账户进行的未经授权的访问或更改。
+ 识别创建的未经授权的资源或 IAM 用户。
+ 识别存在未经授权的更改的系统或资源。
确定资源列表后，应对每项资源进行评估，以确定删除或恢复资源会产生的业务影响。例如，如果 Web 服务器托管业务应用程序，删除它会导致停机，那么在删除受影响的服务器之前，应考虑从经验证的安全备份中恢复资源，或者从纯净 AMI 重新启动系统。
完成业务影响分析后，应基于日志分析中的事件，进入账户并执行适当的补救措施，例如：
+ 轮换或删除密钥：此步骤可使行为者无法继续在账户中执行活动。
+ 轮换可能未经授权的 IAM 用户凭证。
+ 删除无法识别或未经授权的资源。
**重要**
如果出于调查需要必须保留资源，请考虑将这些资源备份。例如，如果出于监管、合规或法律原因必须保留 Amazon EC2 实例，请在删除该实例前[创建 Amazon EBS 快照](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)。
+ 对于恶意软件感染，可能需要联系 AWS Partner 或其他供应商。AWS 不提供用于恶意软件分析或删除的原生工具。但是，如果您使用的是适用于 Amazon EBS 的 GuardDuty 恶意软件模块，则提供的调查发现可能会包含相关建议。
在根除确定的受影响资源后，AWS 会建议您对账户进行安全审查。这可以借助 AWS Config 规则、Prowler 和 ScoutSuite 等开源解决方案，或通过其他供应商来完成。还应考虑对面向公众（互联网）的资源执行漏洞扫描，以评估残余风险。
根除是事件响应流程中的一个步骤，可以手动完成，也可以自动执行，具体取决于事件和受影响的资源。总体策略应与组织的安全策略和业务需求保持一致，并确保在删除不当资源或配置后减轻负面影响。
# 恢复
恢复是指将系统恢复到已知安全状态的流程，在此期间，需要在恢复之前确认备份是否安全或未受事件影响，然后进行测试以确认系统在恢复后正常运行，以及解决与安全事件相关的漏洞。
恢复顺序取决于组织的要求。作为恢复流程的一部分，需要进行业务影响分析，至少确定：
+ 业务或依赖项的优先级
+ 恢复计划
+ 身份验证和授权
《NIST SP 800-61 计算机安全事件处理指南》提供了几个系统恢复步骤，包括：
+ 从纯净备份恢复系统。
+ 在将备份恢复到系统之前，需确认是否对备份进行评估，排除感染情况，防止安全事件卷土重来。
作为灾难恢复测试的一部分，应定期评估备份，以确认备份机制是否正常运行以及数据完整性是否符合恢复点目标。
+ 如果可能，请使用在根本原因分析中确定的第一个事件时间戳之前的备份。
+ 从头开始重建系统，包括使用自动化工具从可信来源重新部署（有时需要在新 AWS 账户中进行）。
+ 将受损文件替换为纯净版本。
执行此操作时应格外小心。必须完全确定要恢复的文件处于已知安全状态，且未受事件影响
+ 安装补丁。
+ 更改密码。
+ 这包括可能已被滥用的 IAM 主体的密码。
+ 如果可能，建议采用适用于 IAM 主体和联合身份验证的角色，作为最低权限策略的一部分。
+ 加强网络周边安全（防火墙规则集、周边路由器访问控制列表）。
资源恢复后，必须总结经验教训，以更新事件响应策略、程序和指南。
总之，必须实施恢复已知安全运营的恢复流程。恢复可能需要很长时间，并且需要密切结合遏制策略，以平衡业务影响和再次感染的风险。恢复程序应当包括恢复资源和服务、IAM 主体的步骤，以及对账户进行安全审查以评估残余风险的步骤。
# 结论
每个运营阶段都有其独特的目标、技术、方法和策略。表 4 总结了这些阶段以及本节涵盖的一些技术和方法。
*表 4 – 运营阶段：目标、技术和方法*
| 阶段 | 目标 | 技术和方法 |
| --- | --- | --- |
| 检测 | 识别潜在的安全事件。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/operations-conclusion.html) |
| 分析 | 确定安全事件是否为意外事件，并评估事件的影响范围。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/operations-conclusion.html) |
| 遏制 | 尽量减小和限制安全事件的影响。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/operations-conclusion.html) |
| 根除 | 移除与安全事件相关的未经授权的资源或构件。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/operations-conclusion.html) |
| 恢复 | 将系统恢复到已知安全状态并监控这些系统，以确保威胁不会再次出现。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/security-ir/latest/userguide/operations-conclusion.html) |
# 事件后活动
威胁形势在不断变化，您的组织必须具备同样的动态性，才能有效保护自己的环境。持续改进的关键在于对事件和模拟的结果进行迭代，以提高有效检测、响应和调查潜在安全事件的能力，从而减少潜在漏洞，缩短响应时间，最终恢复安全运营。以下机制有助于验证您的组织是否已经准备就绪，可以利用最新的功能和知识有效应对任何情形。
# 建立从事件中吸取经验教训的框架
实施*经验教训总结*框架和方法不仅有助于提高事件响应能力，还有助于防止事件再次发生。通过从每次事件中吸取教训，您可以避免重复同样的错误、泄露或错误配置，这不仅可以改善您的安全态势，还可以最大限度地减少因可预防的情况而损失的时间。
重要的是要实现一个经验教训总结框架，大体上确立并实现以下几点：
+ 何时总结经验教训？
+ 总结经验教训的过程涉及什么？
+ 如何总结经验教训？
+ 谁参与了这个过程，具体情况如何？
+ 如何确定需要改进的领域？
+ 如何确保有效跟踪和实施改进措施？
除了这些列出的大体上的成果外，重要的是要确保提出正确的问题，以便从流程中获得最大价值（可以带来切实可行的改进的信息）。请考虑以下问题，以便于您启动经验教训讨论：
+ 发生了什么事件？
+ 何时首次发现该事件？
+ 是如何发现的？
+ 哪些系统针对该活动发出了警报？
+ 涉及哪些系统、服务和数据？
+ 具体发生了什么？
+ 哪些地方做得好？
+ 哪些地方做得不好？
+ 哪些流程或程序出现问题或未能扩展以应对事件？
+ 以下方面有哪些地方有待改进：
+ **人员**
+ 需要联系的人是否真的可以联系上，联系名单是否是最新名单？
+ 相应人员是否缺少有效应对和调查事件所需的培训或能力？
+ 相应的资源是否已就绪并随时可用？
+ **流程**
+ 是否遵循了流程和程序？
+ 是否针对这种事件记录并提供了流程和程序？
+ 是否缺少必要的流程和程序？
+ 响应人员是否能够及时获得所需的信息来处理问题？
+ **技术**
+ 现有警报系统是否能有效识别活动并发出警报？
+ 现有警报是否需要改进，或者是否需要针对这种事件设置新的警报？
+ 现有工具是否允许对事件进行有效调查（搜索/分析）？
+ 怎样才能更快地识别这种事件？
+ 如何防止这种事件再次发生？
+ 谁是改进计划的负责人，如何检验改进计划的执行情况？
+ 实施和测试额外监控/预防性控制机制/流程的时间表是怎样的？
此列表并非详尽无遗；旨在作为一个起点，确定组织和业务需求是什么，以及如何分析这些需求，以便最有效地从事件中吸取经验教训，并不断改进您的安全态势。最重要的是，该列表开始将经验教训作为事件响应流程、文档和利益相关方期望的标准组成部分。
# 设立成功指标
指标对于有效衡量、评估和提高事件响应能力至关重要。没有指标，就没有参考，无法准确衡量甚至确定组织表现的好坏。事件响应有几个常见指标，对于希望建立卓越运营期望和相关基准的组织而言，是很好的入手点。
# 平均检测时间
*平均检测时间*是指发现潜在安全事件所需的平均时间。具体而言，这是从首次出现漏洞指标，到初步识别或生成警报之间的时间。
您可以使用此指标来跟踪检测和警报系统的有效性。有效的检测和警报机制是确保潜在安全事件不会在环境中持续存在的关键。
平均检测时间越长，就越需要建立更多或更有效的警报和机制来识别和发现潜在安全事件。平均检测时间越短，表明检测和警报机制运行得越好。
# 平均确认时间
*平均确认时间*是指确认潜在安全事件并确定其处理优先级所需的平均时间。具体而言，这是从生成警报，到 SOC 成员或事件响应人员识别警报并确定其优先级以进行处理之间的时间。
您可以使用此指标来跟踪团队处理警报和确定其优先级的效率。如果团队无法有效识别警报并确定其优先级，响应将会延迟甚至无效。
平均确认时间越长，就越需要确保团队拥有充足资源并且接受了适当培训，能够快速确认潜在安全事件并确定其优先级以进行响应。平均确认时间越短，表明团队的安全警报响应能力越强，因为这说明他们准备充分且能有效确定警报优先级。
# 平均响应时间
平均响应时间是指开始对潜在安全事件做出初始响应所需的平均时间。具体而言，这是从首次发出警报或发现潜在安全事件，到采取首个响应行动之间的时间。这与平均确认时间类似，不同之处在于其衡量的是具体的响应行动（例如，获取系统数据、遏制系统），而不仅仅是对情况的简单识别或确认。
您可以使用此指标来跟踪您在响应安全事件方面的准备情况。如前所述，充分准备是有效响应的关键。请参阅本文档的[准备](preparation.md)一节。
平均响应时间越长，就越需要确保团队接受过充分的响应培训，从而使响应流程得到有效记录和运用。平均响应时间越短，表明团队越擅长针对已识别的警报确定适当的响应措施，并执行必要的响应行动以启动恢复安全运营的进程。
# 平均遏制时间
*平均遏制时间*是指遏制潜在安全事件所需的平均时间。具体而言，这是从首次发出警报或发现潜在安全事件，到完成有效阻止攻击者或受损系统造成进一步危害的响应行动之间的时间。
您可以使用此指标来跟踪团队在缓解或遏制潜在安全事件方面的能力。如果无法快速有效地遏制潜在安全事件，将增加其影响范围，并可能导致进一步危害。
平均遏制时间越长，就越需要积累知识和提升能力，以便快速有效地缓解和遏制遇到的安全事件。平均遏制时间越短，表明团队越擅长理解和采取必要措施来缓解和遏制已确定的威胁，从而减少其影响范围，并降低业务风险。
# 平均恢复时间
*平均恢复时间*是指从潜在安全事件完全恢复安全运营所需的平均时间。具体而言，这是从首次发出警报或发现潜在安全事件，到业务恢复正常、安全运营且不再受事件影响之间的时间。
您可以使用此指标来跟踪团队在安全事件发生后使系统、账户和环境恢复安全运营的有效性。无法迅速或有效地恢复安全运营，不仅会影响安全性，还会增加对业务及其运营造成的影响及相关成本。
平均恢复时间越长，就越需要让团队和环境做好准备，建立适当的机制（例如，失效转移流程以及用于重新部署安全纯净系统的 CI/CD 管道），以最大限度地减少安全事件对运营和业务的影响。平均恢复时间越短，表明团队在最大限度减少安全事件对运营和业务影响方面越有效。
# 攻击者驻留时间
*攻击者驻留时间*是指未经授权的用户访问系统或环境的平均时间。这与平均遏制时间类似，不同之处在于其时间范围始于攻击者首次获得系统或环境访问权限的时间，该时间可能早于首次发出警报或发现潜在安全事件的时间。
您可以使用此指标来跟踪多个系统与机制的协同工作情况，以缩短攻击者或威胁影响环境的时间、访问权限及机会。缩短攻击者驻留时间应是团队和业务的首要任务。
攻击者驻留时间越长，就越需要确定事件响应流程中哪些部分需要改进，以确保团队能够最大限度地减少威胁或攻击对环境的影响范围。攻击者驻留时间越短，表明团队在最大限度减少威胁或攻击者在环境中的时间和机会方面做得越好，最终降低了运营风险和对业务的影响。
# 指标汇总
通过建立和跟踪事件响应指标，您可以有效地衡量、评估和提高事件响应能力。为此，本节重点介绍了一些常见的事件响应指标。表 5 将这些指标进行了汇总。
*表 5 – 事件响应指标*
| 指标 | 说明 |
| --- | --- |
| 平均检测时间 | 发现潜在安全事件所需的平均时间 |
| 平均确认时间 | 确认潜在安全事件（并确定其优先级）所需的平均时间 |
| 平均响应时间 | 开始对潜在安全事件做出初始响应所需的平均时间 |
| 平均遏制时间 | 遏制潜在安全事件所需的平均时间 |
| 平均恢复时间 | 从潜在安全事件完全恢复安全运营所需的平均时间 |
| 攻击者驻留时间 | 攻击者访问系统或环境的平均时间 |
# 使用漏洞指标（IOC）
*漏洞指标*（IOC）是在网络、系统或环境中观察到的一种构件，它可以（以高置信度）识别恶意活动或安全事件。IOC 能够以多种形式存在，包括 IP 地址、域、网络级构件（例如 TCP 标志或有效载荷）、系统或主机级构件（例如可执行文件、文件名和哈希值、日志文件条目或注册表条目等）。IOC 也可以是项目或活动的组合，例如系统中存在的特定项目或构件（某个文件或一组文件及注册表项）、按特定顺序执行的操作（从特定 IP 登录系统后执行特定异常命令）、或网络活动（进出特定域的异常入站或出站流量），这些组合能够指示特定的威胁、攻击或攻击者手法。
在迭代改进事件响应计划的过程中，应实施一个框架来收集、管理和利用 IOC，以此作为持续构建和改进检测与警报的机制，同时提高调查速度和有效性。首先，您可以将收集与管理 IOC 纳入事件响应流程的分析和调查阶段。通过主动识别、收集和存储 IOC，并将其作为流程的标准部分，您可以构建数据存储库（作为更全面的威胁情报计划的一部分），该存储库反过来又可以用于改进现有的检测和警报、构建额外的检测和警报、识别某个构件之前出现的位置和时间、构建和参考涉及匹配 IOC 的既往调查方式的文档等等。
# 继续教育和培训
教育和培训是不断发展、持续改进的，应当有目的地规划并坚持。有多种机制可用于确认团队是否保持着与不断发展的技术状态以及威胁形势相称的认知、知识和能力。
一种机制是将继续教育作为团队目标和运营的标准组成部分。如“准备”一节所述，必须对事件响应人员和利益相关者进行有效培训，使其掌握在 AWS 中检测、响应和调查事件的能力。然而，教育不是一个可以“一蹴而就”的工程。必须持续开展教育，以确认团队始终了解新的技术进步、更新和改进（这些信息可用于提高响应的有效性和效率），以及可用于改进调查和分析的数据新增或更新内容。
另一种机制是确保定期进行模拟（例如每季度一次），并侧重于实现特定的业务成果。请参阅本文档的[定期进行模拟](run-regular-simulations.md)一节。
尽管进行初始桌面演练是建立改进初始基准的好办法，但是对于实现持续改进以及确保得到对当前运营状态最新的精确反映而言，持续测试才是关键。针对最新、最关键的安全情况以及最重要或最新的响应能力进行测试，并将总结的经验教训重新纳入教育、运营和流程/程序中，将确保您能够持续改进整个响应流程和计划。
# 结论
在继续云之旅的过程中，考虑适用于 AWS 环境的基本安全事件响应概念至关重要。您可以结合使用可用控制措施、云功能及修复选项，以提高云环境的安全性。您也可以从小处着手，在采用可提高响应速度的自动化功能时进行迭代，以便在发生安全事件时做好更充分的准备。
# 贡献者
本文档的当前及过往贡献者包括：
+ Anna McAbee，Amazon Web Services 高级安全解决方案架构师
+ Freddy Kasprzykowski，Amazon Web Services 高级安全顾问
+ Jason Hurst，Amazon Web Services 高级安全工程师
+ Jonathon Poling，Amazon Web Services 首席安全顾问
+ Josh Du Lac，Amazon Web Services 安全解决方案架构高级经理
+ Paco Hope，Amazon Web Services 首席安全工程师
+ Ryan Tick，Amazon Web Services 高级安全工程师
+ Steve de Vera，Amazon Web Services 高级安全工程师
# 附录 A：云功能定义
AWS 提供 200 多种云服务和数千种功能。其中许多功能可提供本机检测、预防和响应功能，而其他功能则可用于构建自定义安全解决方案。本节包含与云中事件响应最相关的部分服务。
**Topics**
+ [日志记录和事件](logging-and-events.md)
+ [可见性和警报](visibility-and-alerting.md)
+ [自动化](automation-1.md)
+ [安全存储](secure-storage.md)
+ [未来与自定义安全功能](custom.md)
# 日志记录和事件
[https://aws.amazon.com/cloudtrail/](https://aws.amazon.com/cloudtrail/)：AWS CloudTrail 服务支持对 AWS 账户进行治理、合规、运营审计和风险审计。借助 CloudTrail，您可以记录、持续监控和保留与跨 AWS 服务操作相关的账户活动。CloudTrail 提供 AWS 账户活动的事件历史记录，包括通过 AWS 管理控制台、AWS SDK、命令行工具和其他 AWS 服务执行的操作。该事件历史记录简化了安全分析、资源变更跟踪和故障排除工作。CloudTrail 记录了两种不同类型的 AWS API 操作：
+ **CloudTrail 管理事件**（也称为控制面板操作）会显示对 AWS 账户内的资源执行的管理操作。这包括创建 Amazon S3 存储桶和设置日志记录等操作。
+ **CloudTrail 数据事件**（也称为数据面板操作）显示在 AWS 账户内的资源上或资源内执行的资源操作。这些操作通常是大规模活动。这包括 Amazon S3 对象级 API 活动（例如 `GetObject`、`DeleteObject` 和 `PutObject` API 操作）以及 Lambda 函数调用活动等操作。
[https://aws.amazon.com/config/](https://aws.amazon.com/config/)：AWS Config 服务使客户能够评测、审计和评估 AWS Config 资源的配置。AWS 可以持续监控和记录客户的 AWS 资源配置，并让其能够依据配置需求自动评估记录的配置。借助 AWS Config，客户可以手动或自动查看配置更改以及 AWS 资源之间的关系、详细的资源配置历史记录，并判断配置在整体上是否符合客户指南中所指定的配置要求。这可以简化合规性审核、安全性分析、变更管理和操作故障排除。
[https://aws.amazon.com/eventbridge/](https://aws.amazon.com/eventbridge/)：Amazon EventBridge 可提供近乎实时的系统事件流，这些系统事件描述了 AWS 资源中的更改，或者 AWS CloudTrail 发布 API 调用的时间。通过使用可快速设置的简单规则，您可以匹配事件并将事件路由到一个或多个目标函数或流。EventBridge 可在发生操作更改时感知到这些更改。EventBridge 可以响应这些操作更改并在必要时采取纠正措施，方式是发送消息以响应环境、激活函数、进行更改并捕获状态信息。一些安全服务（如 Amazon GuardDuty），以 EventBridge 事件的形式生成输出。许多安全服务还提供向 Amazon S3 发送输出的选项。
**Amazon S3 访问日志**：如果敏感信息存储在 Amazon S3 存储桶中，客户可以启用 Amazon S3 访问日志来记录相关数据的每次上传、下载和修改。该日志独立于 CloudTrail 日志（并作额外补充），CloudTrail 日志可用于记录存储桶本身的更改（例如更改访问策略和生命周期策略）。需要注意的是，访问日志记录会以最大努力进行传输。针对已正确配置了日志记录的存储桶的大多数请求会导致传输一条日志记录。因此不能保证服务器日志记录的完整性和即时性。
[https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)：客户可以通过 Amazon CloudWatch Logs 代理监控、存储和访问来自 Amazon EC2 实例上运行的操作系统、应用程序和其他来源的日志文件。CloudWatch Logs 可以作为 AWS CloudTrail、Route 53 DNS 查询、VPC 流日志、Lambda 函数等的目的地。客户随后可以从 CloudWatch Logs 中检索关联的日志数据。
[https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)：VPC 流日志使客户能够捕获有关在 VPC 中传入和传出网络接口的 IP 流量的信息。启用流日志后，可以将其流式传输到 Amazon CloudWatch Logs 和 Amazon S3。VPC 流日志可帮助客户完成诸多任务，例如排查特定流量无法到达实例的原因、诊断过于严格的安全组规则，以及将其用作监控 EC2 实例流量的安全工具。使用最新版本的 VPC 流日志记录可获取最全面的字段信息。
[https://aws.amazon.com/waf/](https://aws.amazon.com/waf/)：AWS WAF 支持完整记录该服务检查的所有 Web 请求。客户可将其存储在 Amazon S3 中，以满足合规和审计要求，以及用于调试和取证。这些日志可帮助客户确定规则触发和 Web 请求被阻止的根本原因。日志可与第三方 SIEM 和日志分析工具集成。
[https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-query-logs.html)：Route 53 Resolver 查询日志便于您记录 Amazon Virtual Private Cloud（Amazon VPC）内资源发出的所有 DNS 查询。无论是 Amazon EC2 实例、AWS Lambda 函数还是容器，只要其位于 Amazon VPC 中且发出 DNS 查询，此功能都会将其记录下来；之后您就能够探索并更好地理解应用程序的运行情况。
**其他 AWS 日志**：AWS 将持续为客户发布包含新日志记录和监控功能的服务特性与功能。有关每项 AWS 服务可用功能的信息，请参阅我们的公共文档。
# 可见性和警报
[https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)— AWS 安全事件响应 是一项综合服务，通过将自动化功能与专业人力支持相结合，帮助组织在整个生命周期中处理安全事件。该服务利用自动监控和调查功能来腾出组织资源，同时保持警惕的安全监督，当安全事件发生时，它有助于加快利益相关者之间的沟通和协调，从而加快响应时间。该服务支持多种使用案例，包括安全事件的准备和模拟、对活动事件的响应以及简化的事后报告和分析，确保组织有能力应对每个阶段的安全挑战。
[https://aws.amazon.com/security-hub/](https://aws.amazon.com/security-hub/)：AWS Security Hub CSPM 可为客户提供跨 AWS 账户的高优先级安全警报与合规状态的全面视图。Security Hub CSPM 可以聚合、组织来自 AWS 服务（例如 Amazon GuardDuty、Amazon Inspector、Amazon Macie）和 AWS Partner解决方案的威胁调查发现并确定优先级。通过包含可操作图表和表格的集成控制面板，对调查发现进行直观汇总。您还可以基于 AWS 最佳实践及组织所遵循的行业标准，使用自动化合规性检查对环境进行持续监控。
[https://aws.amazon.com/guardduty/](https://aws.amazon.com/guardduty/)：Amazon GuardDuty 是一项托管的威胁检测服务，可以持续监控恶意或未经授权的行为，从而帮助客户保护 AWS 账户和工作负载。Amazon GuardDuty 可以监控异常的 API 调用或可能未经授权的部署等活动，这些活动表明 Amazon EC2 实例、Amazon S3 存储桶的账户或资源可能遭到破坏或者有恶意行为者正在进行侦察。
GuardDuty 通过集成的威胁情报源识别可疑的不良行为者，利用机器学习检测账户和工作负载活动中的异常情况。检测到潜在威胁后，该服务便会向 GuardDuty 控制台和 CloudWatch Events 发送详细的安全警报。这样一来，警报将具有可操作性，并且能轻松集成到现有的事件管理和工作流程系统中。
GuardDuty 还提供两个附加组件，用于监控特定服务的威胁：用于保护 Amazon S3 的 Amazon GuardDuty 以及用于保护 Amazon EKS 的 Amazon GuardDuty。Amazon S3 防护使 GuardDuty 能够监控对象级 API 操作，以识别 Amazon S3 存储桶中数据的潜在安全风险。Kubernetes 保护有助于 GuardDuty 检测 Amazon EKS 中 Kubernetes 集群的可疑活动和潜在漏洞。
[https://aws.amazon.com/macie/](https://aws.amazon.com/macie/)：Amazon Macie 是一项人工智能驱动的安全服务，通过自动发现、分类和保护存储在 AWS 中的敏感数据来防止数据丢失。Macie 利用机器学习（ML）来识别敏感数据，例如个人身份信息（PII）或知识产权，为其分配业务价值，并提供关于这些数据存储位置及其在组织中使用情况的见解。Amazon Macie 会持续监控数据访问活动是否存在异常情况，并在检测到未经授权的访问或无意的数据泄露风险时发出警报。
[https://aws.amazon.com/config/](https://aws.amazon.com/config/)：AWS Config 规则代表资源的首选配置，会根据 AWS Config 记录的相关资源配置更改进行评估。您可以在控制面板上查看针对资源配置评估规则的结果。借助 AWS Config 规则，您可以从配置角度评估总体合规性和风险状态，查看一段时间内的合规性趋势，并找出哪些配置更改导致资源违反规则。
[https://aws.amazon.com/premiumsupport/technology/trusted-advisor/](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)：AWS Trusted Advisor 是一种在线资源，可通过优化 AWS 环境来帮助您降低成本、提高性能和增强安全性。Trusted Advisor 可提供实时指南，帮助您按照 AWS 最佳实践预置资源。全套 Trusted Advisor 检查（包括 CloudWatch Events 集成）可供商业和企业支持计划的客户使用。
[https://aws.amazon.com/cloudwatch/](https://aws.amazon.com/cloudwatch/)：Amazon CloudWatch 是一项针对 AWS 云 资源以及您在 AWS 运行的应用程序的监控服务。您可以使用 CloudWatch 收集和跟踪指标、收集和监控日志文件、设置警报并自动对 AWS 资源中的更改做出反应。CloudWatch 可以监控 AWS 资源，例如 Amazon EC2 实例、Amazon DynamoDB 表和 Amazon RDS 数据库实例，以及您的应用程序和服务生成的自定义指标以及您的应用程序生成的任何日志文件。您可以通过使用 Amazon CloudWatch 全面地了解资源利用率、应用程序性能和运行状况。使用这些分析结果，您可以及时做出相应反应，保证应用程序顺畅运行。
[https://aws.amazon.com/inspector/](https://aws.amazon.com/inspector/)：Amazon Inspector 是一项自动安全评估服务，有助于提高部署在 AWS 上的应用程序的安全性与合规性。Amazon Inspector 会自动评估应用程序的漏洞以及偏离最佳实践的情况。执行评估后，Amazon Inspector 将生成按严重性级别优先排序的安全调查发现详细列表。这些调查发现可以直接查看，也可以作为详细评估报告的一部分进行查看，报告则可通过 Amazon Inspector 控制台或 API 获取。
[https://aws.amazon.com/detective/](https://aws.amazon.com/detective/)：Amazon Detective 是一项安全服务，可自动从 AWS 资源收集日志数据，并利用机器学习、统计分析和图形理论构建一组关联数据，以帮助您更快、更高效地进行安全调查。Detective 可分析来自多个数据来源（例如 VPC 流日志、CloudTrail 和 GuardDuty）的数万亿个事件，并自动创建统一的交互式视图，供您了解资源、用户及此类行为随时间推移的相互作用。借助此统一视图，在一个位置就能查看所有细节和背景情况，以确定调查发现的根本原因，深入探究相关的历史活动，并快速确定根本原因。
# 自动化
[https://aws.amazon.com/lambda](https://aws.amazon.com/lambda)：AWS Lambda 是一项无服务器计算服务，可运行代码来响应事件并为您自动管理底层计算资源。您可以使用 Lambda 通过自定义逻辑扩展其他 AWS 服务，或创建您自己的按 AWS 规模、性能和安全性运行的后端服务。Lambda 会在可用性高的计算基础设施上运行您的代码，并为您执行计算资源的管理工作。这包括服务器和操作系统维护、容量预置、自动扩展、代码和安全补丁部署以及代码监控和日志记录。您只需提供代码即可。
[https://aws.amazon.com/step-functions/](https://aws.amazon.com/step-functions/)：AWS Step Functions 让您通过可视工作流程，轻松协调分布式应用程序和微服务的组件。Step Functions 提供图形控制台，您可以排列应用程序的组件，并将其直观地展示为一系列步骤。这样就可以轻松构建和运行多步骤应用程序。Step Functions 可以自动开始和跟踪各个步骤，并在出现错误时重试，因此您的应用程序能够按照预期顺序运行。
Step Functions 会记录每个步骤的状态，这样在出现错误时，您就能够迅速诊断并调试问题。您无需编写代码即可更改和添加步骤，因而可以更快地改进应用程序并进行创新。AWS Step Functions 是 AWS Serverless 的一部分，可以轻松编排无服务器应用程序中的 AWS Lambda 函数。您还可以使用 Step Functions，借助 Amazon EC2 和 Amazon ECS 等计算资源进行微服务编排。
[https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/)：AWS Systems Manager 让您能够查看和控制 AWS 上的基础设施。Systems Manager 可以提供一个统一的用户界面，供您查看多种 AWS 服务的运行数据，并且便于您在 AWS 资源上自动执行操作任务。借助 Systems Manager，您可以按应用程序对资源进行分组，查看用于监控和故障排除的操作数据，并对资源组执行操作。Systems Manager 可以使实例保持预先设定状态，执行按需更改（例如更新应用程序或运行 shell 脚本），以及执行其他自动化和修补任务。
# 安全存储
[https://aws.amazon.com/s3/](https://aws.amazon.com/s3/)：Amazon S3 是一种对象存储，旨在从任何地方存储和检索任意数量的数据。它可提供 99.999999999% 的持久性，并为各行各业市场领导者所使用的数百万个应用程序存储数据。Amazon S3 可提供全面的安全保护，旨在帮助您满足监管要求。它为客户提供了灵活的数据管理方法，可实现成本优化、访问控制和合规性。此外，Amazon S3 可提供就地查询功能，便于您直接对 Amazon S3 中的静态数据进行强大的分析。Amazon S3 是一项得到广泛支持的云存储服务，集成了由第三方解决方案、系统集成商合作伙伴和其他 AWS 服务组成的其中一个最大社区。
[https://aws.amazon.com/s3/storage-classes/glacier/](https://aws.amazon.com/s3/storage-classes/glacier/)：Amazon Glacier 是一项安全、持久且成本极低的云存储服务，适用于数据存档和长期备份。它可提供 99.999999999% 的持久性以及全面的安全保护，旨在帮助您满足监管要求。Amazon Glacier 可提供就地查询功能，便于您直接静态存档数据进行强大的分析。为了降低成本同时满足不同的检索需求，Amazon Glacier 提供了三种存档访问选项，用时从几分钟到几小时不等。
# 未来与自定义安全功能
上述服务和功能并非详尽列表。AWS 正在不断添加新功能。有关更多信息，我们建议您查看 [AWS 的新功能](https://aws.amazon.com/new/) 与 [AWS 云安全性](https://aws.amazon.com/security/)页面。除了 AWS 作为原生云服务提供的安全服务外，您可能还有兴趣基于 AWS 服务构建自己的安全功能。
尽管我们建议在账户中启用一组基本的安全服务（如 AWS CloudTrail、Amazon GuardDuty 和 Amazon Macie），但您最终可能希望扩展这些功能，以从日志资产中获得更多价值。有多款合作伙伴工具可供选择，例如 APN 安全能力计划中列出的工具。您可能还想编写自己的查询来搜索日志。没问题，借助 AWS 提供的大量托管服务，这将变得前所未有的简单。许多其他 AWS 服务也可帮助您进行调查，但这些服务不在本文的讨论范围之内，例如 Amazon Athena、Amazon OpenSearch Service、Amazon Quick、Amazon Machine Learning 和 Amazon EMR。
# 附录 B：AWS 事件响应资源
AWS 会发布资源以帮助客户构建事件响应能力。有关大多数示例代码和程序，请参阅 AWS 外部 GitHub 公共存储库。以下是一些可以提供如何执行事件响应示例的资源。
## 行动手册资源
+ [事件响应行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework)：一个示例框架，供客户在使用 AWS 服务时创建、制定和集成安全行动手册，为潜在的攻击场景做好准备。
+ [事件响应行动手册样本](https://github.com/aws-samples/aws-incident-response-playbooks)：该行动手册涵盖了 AWS 客户面临的常见场景。
+ [AWS 宣布开放五场公开讲习会](https://aws.amazon.com/blogs/security/aws-cirt-announces-the-release-of-five-publicly-available-workshops/)。
## 取证资源
+ [自动事件响应和取证框架](https://github.com/awslabs/aws-automated-incident-response-and-forensics)：一种提供标准数字取证流程的框架和解决方案，涉及以下阶段：遏制、采集、检查和分析。它利用 AWS Λ 函数，以自动化、可重复的方式触发事件响应流程。它可提供分割账户，以操作自动化步骤、存储工件和创建取证环境。
+ [适用于 Amazon EC2 的自动取证编排工具](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/)：此实施指南提供了一种自助服务解决方案，用于在检测到潜在安全问题时捕获和检查来自 EC2 实例及附加卷的数据，以进行取证分析。此外，还提供用于部署解决方案的 AWS CloudFormation 模板。
+ [如何在 AWS 中自动实施取证磁盘收集](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)：此 AWS 博客文章详细介绍了如何设置自动化工作流程以捕获磁盘证据用于分析，从而确定潜在安全事件的范围和影响。此外，还提供用于部署解决方案的 AWS CloudFormation 模板。
# 版权声明
客户有责任对本文档中的信息进行单独评测。本文档：(a) 仅供参考，(b) 代表当前的 AWS 产品和实践，如有更改，恕不另行通知，以及 (c) 不构成 AWS 及其附属公司、供应商或许可方的任何承诺或保证。AWS 产品或服务“按原样”提供，不附带任何明示或暗示的保证、陈述或条件。AWS 对其客户承担的责任和义务受 AWS 协议制约，本文档不是 AWS 与客户直接协议的一部分，也不构成对该协议的修改。
© 2024，Amazon Web Services, Inc. 或其附属公司。保留所有权利。