简介 - AWS 安全事件响应 用户指南
开始前的准备工作AWS 事件响应概述

简介

安全是 AWS 的重中之重。AWS 客户受益于专为满足大多数安全敏感型组织的要求而打造的数据中心和网络架构。AWS 采用责任共担模式：AWS 负责云的安全，客户则负责云中的安全。这意味着您可以完全控制自身的安全实施，例如使用多种工具和服务助您实现安全目标。这些功能可以帮助您为在 AWS 云 中运行的应用程序建立安全基准。

如果偏离基准，例如由于配置错误或外部因素变化，则需做出响应并进行调查。要成功做到这一点，您需要了解 AWS 环境中安全事件响应的基本概念，并了解在安全问题发生之前做好准备以及向云团队传授知识并开展培训的相关要求。您需要了解可以使用的控制措施和功能，查看用于解决潜在问题的主题示例，并掌握利用自动化提高响应速度与一致性的补救方法。此外，您还应了解相关的合规性规定和法规，因为这些规定和法规与制定安全事件响应计划以满足上述要求相关。

安全事件响应可能较为复杂，因此我们建议您采用迭代方法：从核心安全服务开始，构建基础的检测和响应能力，而后制定行动手册以创建初始的事件响应机制库，并在此基础上进行迭代和改进。

开始前的准备工作

在开始了解 AWS 中的安全事件响应之前，请先熟悉 AWS 安全和事件响应的相关标准和框架。这些基础知识将有助于您理解本指南中介绍的概念和最佳实践。

AWS 安全标准和框架

首先，我们建议您查看《安全、身份与合规性的最佳实践 – AWS Well-Architected Framework》以及《AWS Cloud Adoption Framework（AWS CAF）概览》白皮书中的“安全视角”。

AWS CAF 会提供指南，促进向云迁移的组织中不同部门之间的协调。AWS CAF 指南分为几个重点领域（称为视角），这些领域与构建基于云的 IT 系统有关。安全视角描述了如何跨工作流实施安全计划，其中之一便是事件响应。本文档是我们与客户合作的经验成果，旨在帮助他们建立有效的安全事件响应计划与高效的安全事件响应能力。

行业事件响应标准和框架

本白皮书遵循美国国家标准与技术研究院（NIST）制定的《计算机安全事件处理指南 SP 800-61 r2》中的事件响应标准和最佳实践。阅读并理解 NIST 提出的概念是有益的先决条件。本白皮书将把该 NIST 指南中的概念和最佳实践应用于 AWS 技术。但是，本地事件场景不在本指南的讨论范围内。

AWS 事件响应概述

首先，了解云中的安全运营和事件响应有何不同至关重要。要构建 AWS 中的有效事件响应能力，需要了解其与传统本地响应的差异，以及这些差异对事件响应计划的影响。本节将详细介绍这些差异以及 AWS 事件响应的核心设计原则。

AWS 事件响应的各个方面

组织内的所有 AWS 用户都应对安全事件响应流程有基本的了解，并且安全人员应了解如何响应安全问题。教育、培训和经验对于成功的云事件响应计划至关重要，最好在处理可能发生的安全事件之前提前实施。云中成功的事件响应计划的基础在于准备工作、操作和事件后活动。

要了解其中的各个方面，请考虑以下描述：

  • 准备工作：让事件响应团队做好准备，以便在 AWS 中检测和响应事件，方法是启用检测性控制措施，并确保对必要的工具和云服务拥有适当的访问权限。此外，还应通过人工和自动化的方式准备必要的行动手册，以确保可靠且一致的响应。

  • 操作：按照 NIST 的事件响应阶段（检测、分析、遏制、根除和恢复）对安全事件和潜在事件采取相应操作。

  • 事件后活动：对安全事件和模拟的结果进行迭代，以提高响应的有效性，从响应和调查中获得更多价值，并进一步降低风险。您必须从事件中吸取经验教训，并对改进活动占有很大的所有权。

本指南将探讨这些方面并逐一进行详细介绍。下图显示了这些方面的流程，与前面提到的 NIST 事件响应生命周期一致，但操作包括检测、分析、遏制、根除和恢复。

图中显示了 AWS 事件响应的各个方面

AWS 事件响应的各个方面

AWS 事件响应原则和设计目标

尽管事件响应的一般流程和机制（例如《NIST SP 800-61 计算机安全事件处理指南》中定义的流程和机制）依然有效，但我们建议您评估这些与云环境中的安全事件响应相关的特定设计目标：

  • 建立响应目标：与利益相关者、法律顾问和组织领导合作，以确定事件响应目标。一些共同的目标包括遏制和缓解问题、恢复受影响的资源、保留数据为便取证、恢复已知安全运营，以及最终从事件中吸取教训。

  • 利用云进行响应：在云中（即事件和数据的发生地）实施响应模式。

  • 了解所拥有和需要的证据：通过复制日志、资源、快照和其他证据并将其存储在一个集中的响应专用云账户中来保存这些内容。使用标签、元数据和保留策略实施机制。您需要了解自己使用了哪些服务，然后确定调查这些服务的要求。为了帮助您了解自己的环境，您还可以使用标记（本文档后面的制定和实施标记策略一节将对此进行介绍）。

  • 使用重新部署机制：如果安全异常可归因于一个配置错误，那么可能只需使用适当的配置重新部署资源来删除差异，即可完成修复。如果发现可能存在漏洞，请核实您重新部署时是否包括成功且经过验证的根本原因缓解措施。

  • 尽可能自动化：当问题出现或事件重复发生时，建立机制，以程序化方式对常见事件进行分类和响应。对于自动化程度不足的独特、复杂或敏感事件，使用人工响应。

  • 选择可扩展的解决方案：尽量让组织采用方法的可扩展性与云计算能力相匹配。实施可在您环境中扩展的检测和响应机制，有效地缩短检测与响应之间的时间差。

  • 了解并改进流程：主动找出流程、工具或人员的不足，并实施计划来弥补这些不足。模拟是找出不足并改进流程的妥善方法。有关如何对流程进行迭代的详细信息，请参阅本文档的事件后活动一节。

这些设计目标会提醒您审查架构实施情况，确定是否同时具备事件响应能力和威胁检测能力。在规划云端实施时，应考虑如何应对事件，最好使用具备司法有效性的响应方法。在某些情况下，这意味着您可能需要专门为这些响应任务设置多个组织、账户和工具。这些工具和功能应通过部署管道提供给事件响应者。它们不应该是静态的，因为这会导致更大的风险。

云安全事件域

要进行有效准备并响应 AWS 环境中的安全事件，您需要了解常见的云安全事件类型。在客户责任范围内，有三个可能发生安全事件的域：服务域、基础设施域和应用程序域。不同的域需要不同的知识、工具和响应流程。请考虑以下域：

  • 服务域：服务域中的事件可能会影响您的 AWS 账户、AWS Identity and Access Management（IAM）权限、资源元数据、账单或其他方面。服务域事件是指仅使用 AWS API 机制进行响应的事件，或者是其根本原因与配置或资源权限相关，且可能包含相关的服务导向型日志记录的事件。

  • 基础设施域：基础设施域中的事件包括与数据或网络相关的活动，例如 Amazon Elastic Compute Cloud（Amazon EC2）实例上的进程和数据、虚拟私有云（VPC）内流向 Amazon EC2 实例的流量，以及容器或其他未来服务等其他方面。对基础设施域事件的响应通常需要获取与事件相关的数据，以进行取证分析。这可能包括与实例操作系统进行交互，并且在不同情况下，还可能涉及与 AWS API 机制交互。在基础设施域中，可在来宾操作系统（例如专门用于执行取证分析和调查的 Amazon EC2 实例）中组合使用 AWS API 和数字取证/事件响应（DFIR）工具。基础设施域事件可能涉及分析网络数据包捕获、Amazon Elastic Block Store（Amazon EBS）卷上的磁盘块或从实例获取的易失性存储器。

  • 应用程序域：应用程序域中的事件通常发生在应用程序代码或部署到服务或基础设施的软件中。该域应包含在您的云威胁检测和响应行动手册中，并且还可能包含基础设施域中的类似响应。您可以借助适当且周密的应用程序架构，使用云工具，通过自动获取、恢复和部署来管理该域。

在这些域中，请考虑可能对 AWS 账户、资源或数据执行操作的行为者。无论是内部行为者还是外部行为者，都应使用风险框架来确定组织面临的具体风险，并做好相应的准备。此外，您还应该开发威胁模型，这有助于您规划事件响应和构建周密架构。

AWS 中事件响应的主要差异

无论是在本地还是在云中，事件响应都是网络安全战略不可或缺的一部分。最低权限和深度防御等安全原则旨在保护本地数据与云中数据的机密性、完整性和可用性。随之诞生的，是支持这些安全原则的几种事件响应模式，包括日志保留、来自威胁建模的警报选择、行动手册制定以及安全信息和事件管理（SIEM）集成。当客户开始在云中架构和设计这些模式时，差异便开始显现。以下是 AWS 中事件响应的主要差异。

差异 #1：安全性的责任共担

安全性和合规性是 AWS 与客户共同承担的责任。这种责任共担模式可以减轻客户的运营负担，因为 AWS 会运营、管理和控制从主机操作系统和虚拟化层组件，一直到服务运营所在物理设施的安全性。有关责任共担模式的更多详细信息，请参阅责任共担模式文档。

随着您在云中的共担责任发生变化，事件响应选项也会随之改变。规划并了解这些权衡取舍，使其与您的治理需求相匹配，是事件响应的关键一步。

除了与您直接相关的 AWS 外，可能还有其他实体在特定责任模式中承担责任。例如，可能有内部组织单元，负责您运营的某些方面。此外，您也可能与开发、管理或运营部分云技术的其他各方有关系。

制定并测试与运营模式相匹配的适当事件响应计划和相应的行动手册至关重要。

差异 #2：云服务域

由于云服务中存在安全责任差异，因此需要一个新的安全事件域：服务域（该域已在之前的事件域一节中进行说明）。服务域包括客户的 AWS 账户、IAM 权限、资源元数据、账单及其他方面。由于您的响应方式不同，该域在事件响应方面亦有所不同。服务域内的响应通常通过查看和发出 API 调用实现，并非基于主机和基于网络的传统响应。在服务域中，您不会与受影响资源的操作系统进行交互。

下图显示了服务域中基于架构反模式的安全事件示例。在此事件中，未经授权的用户将获取 IAM 用户的长期安全凭证。IAM 用户拥有 IAM 策略，该策略允许其从 Amazon Simple Storage Service（Amazon S3）存储桶检索对象。要响应此安全事件，可以使用 AWS API 来分析 AWS 日志（例如 AWS CloudTrail 和 Amazon S3 访问日志）。您还可以使用 AWS API 来遏制事件并从中恢复。

服务域示例图

服务域示例

差异 #3：用于预置基础设施的 API

另一个差异源于云按需自助服务的特性。主要设施客户通过 RESTful API 与 AWS 云 交互，这些 API 经由全球诸多地理位置可用的公有和私有端点提供。客户可以使用 AWS 凭证访问这些 API。与本地访问控制措施不同，这些凭证不一定受网络或 Microsoft Active Directory 域的约束。与之相反，这些凭证与 AWS 账户内的 IAM 主体相关联。这些 API 端点可以在企业网络之外进行访问，在对预期网络或地理位置之外使用凭证的事件进行响应时，理解这一点非常重要。

由于 AWS 基于 API 的特性，响应安全事件的一个重要日志源是 AWS CloudTrail，它会跟踪 AWS 账户中发出的管理 API 调用，您可以在其中找到有关 API 调用源位置的信息。

差异 #4：云的动态特性

云是动态的；支持您快速创建和删除资源。借助自动扩展，您可以根据流量增加情况启动和终止资源。由于基础设施生命周期短且变化快速，您正在调查的资源可能已不复存在或已被修改。理解 AWS 资源的短暂性以及如何跟踪 AWS 资源的创建和删除对于事件分析至关重要。您可以使用 AWS Config 来跟踪 AWS 资源的配置历史记录。

差异 #5：数据访问

云中的数据访问也有所不同。您无法通过接入服务器收集安全调查所需的数据。数据将通过线路和 API 调用进行收集。您需要实践并了解如何通过 API 执行数据收集，以便为这种转变做好准备，并确保进行了适当存储以实现有效收集和访问。

差异 #6：自动化的重要性

为了让客户充分意识到云采用的优势，其运营策略必须采用自动化。基础设施即代码（IaC）是一种高效的自动化环境模式，在这种环境中，AWS 服务通过代码（由原生 IaC 服务如 AWS CloudFormation 或第三方解决方案提供支持）进行部署、配置、重新配置和销毁。这可提供高度自动化的事件响应实施方式，有助于避免人为错误，尤其是在处理证据时。尽管本地环境也采用自动化，但在 AWS 云 中，自动化不可或缺，而且可以更轻松地实现。

应对差异

要应对这些差异，请按照下一节概述的步骤进行操作，以确保涉及人员、进程和技术的事件响应计划准备充分。