# 事件响应
<a name="a-incident-response"></a>

**Topics**
+ [SEC 10  如何预测、响应事件以及从事件中恢复？](w2aac19b7c15b5.md)

# SEC 10  如何预测、响应事件以及从事件中恢复？
<a name="w2aac19b7c15b5"></a>

准备工作对于及时有效地调查、响应安全事件以及从安全事件中恢复至关重要，可以尽可能减少对组织的破坏。

**Topics**
+ [SEC10-BP01 确定关键人员和外部资源](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 制定事件管理计划](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 准备取证能力](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 自动控制功能](sec_incident_response_auto_contain.md)
+ [SEC10-BP05 预置访问权限](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 预先部署工具](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 执行实际试用](sec_incident_response_run_game_days.md)

# SEC10-BP01 确定关键人员和外部资源
<a name="sec_incident_response_identify_personnel"></a>

 确定能够帮助您的组织响应事件的内部和外部人员、资源、以及法律义务。 

当您与其他团队（例如法律顾问、领导、业务利益相关者、AWS Support 服务等）一起在云中定义您的事件响应方法时，您必须确定关键人员、利益相关者和相关联系人。为了降低依赖性并缩短响应时间，请确保为您的团队、专家安全团队和响应者开展培训，以使他们了解您使用的服务并有机会练习动手实践。

我们鼓励您寻找外部 AWS 安全合作伙伴，他们应当能够为您带来外部专业知识和不同的视角，以增强您的响应能力。您的可靠安全合作伙伴可以帮助您发现您可能并不熟悉的潜在风险或威胁。

 **未建立此最佳实践暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  确定组织中的关键人员：制定联系人列表，列出组织内需要参与意外事件响应和恢复的人员。 
+  确定外部合作伙伴：根据需要联系能够帮助您响应意外事件并从中恢复的外部合作伙伴。 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS 意外事件响应指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **相关视频：** 
+  [准备和响应 AWS 环境中的安全意外事件 ](https://youtu.be/8uiO0Z5meCs)

 **相关示例：** 

# SEC10-BP02 制定事件管理计划
<a name="sec_incident_response_develop_management_plans"></a>

 制定计划，以帮助您响应事件、在事件期间进行沟通以及从事件中恢复。例如，您可以根据您的工作负载和组织中最可能遇到的情况开始制定事件响应计划。在计划中说明如何在内部和外部进行沟通和上报。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>

 对于响应、缓解安全事件的潜在影响并从中恢复来说，事件管理计划是至关重要的。事件管理计划是一个结构化的过程，用于及时地确定、补救和响应安全事件。

 云的许多操作角色和要求都与本地环境中的相同。在创建事件管理计划时，应考虑最符合业务成果和合规性要求的响应和恢复策略，这一点非常重要。例如，如果您在 AWS 中运行在美国符合 FedRAMP 标准的工作负载，则遵守 [《NIST SP 800-61 计算机安全处理指南》会很有帮助](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf)。同样，在使用欧洲 PII（Personally Identifiable Information，个人身份信息）数据运行工作负载时，请考虑如何根据 [欧盟通用数据保护条例（GDPR，General Data Protection Regulation）](https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-does-general-data-protection-regulation-gdpr-govern_en)。

 在为 AWS 中运行的工作负载构建事件管理计划时，请首先使用 [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)，以便构建针对事件响应的深度防御方法。在此模式中，AWS 负责管理云本身的安全，云内部的安全则由您负责。这意味着您将保留控制权，并对选择实施的安全控制机制负责。此 [AWS 安全事件响应指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 详细介绍了构建以云为中心的事件管理计划的关键概念和基本指南。

 必须不断地迭代有效的事件管理计划，使其与您的云运营目标保持一致。在创建和改进事件管理计划时，请考虑使用下面详述的实施计划。 
+  **针对事件响应进行的培训和训练：** 当与定义的基线存在偏差（例如，部署错误或配置错误）时，您可能需要做出响应并展开调查。要成功做到这一点，您必须了解可用于 AWS 环境中的安全事件响应的控制机制和功能，以及准备、培训和训练参与事件响应的云团队时要考虑的流程。 
  +  [行动手册](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) 和 [运行手册](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 是有效机制，用于在训练如何应对事件时建立一致性。首先，在事件响应期间构建经常运行的过程的初始列表，并在学习或使用新过程时继续迭代。
  +  通过计划的 [实际试用](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_incident_response_run_game_days.html)，将行动手册和运行手册社交化。在实际试用期间，在受控环境中模拟事件响应，帮助您的团队回顾如何进行响应，以及验证参与事件响应的团队是否熟悉工作流。审查模拟事件的结果以明确改进措施，并确定有关进一步的训练或其他工具的需求。
  +  在安全方面，人人有责。通过让通常运行工作负载的所有人员参与进来，建立事件管理流程的集体性知识。这项工作应该涵盖业务的所有方面，即运营、测试、开发、安全性、业务运营和业务部门的负责人均应参与其中。 
+  **将事件管理计划归档：** 将一些工具和过程归档，而这些工具和过程用于记录、处理、传达进度，以及提供有关活动事件的通知。事件管理计划旨在确保尽快恢复正常操作、将业务影响降至最低并始终通知所有相关方。事件示例包括（但不限于）网络连接丢失或降级、进程或 API 无响应、计划的任务未执行（例如，修补失败）、应用程序数据或服务不可用、因安全事件导致计划外服务中断、凭证泄露或错误配置。 
  +  确定负责解决事件的主要所有者，例如工作负载所有者。清楚地指明负责处理事件的人员以及沟通方式。当有多方（例如外部供应商）参与事件解决过程时，请考虑构建 *责任（RACI）矩阵*，详细说明参与事件解决过程的各个团队或人员的角色和职责。

     RACI 矩阵详述了以下各方的职责： 
    +  **R：** *责任（Responsible）* 方，负责完成任务。
    +  **A：** *负责（Accountable）* 方或利益相关者，负责最终裁定是否已成功完成特定任务。
    +  **C：** *咨询（Consulted）* 方，将向其征求意见，通常是主题专家。
    +  **I：** *告知（Informed）* 方，将告知其进度，通常仅在任务完成或有可交付结果时才告知。
+  **对事件进行分类：** 通过根据严重性和影响分数来定义事件并为其分类，可以使用结构化方法来分类和解决事件。以下建议说明了一个用于量化事件的 *影响-解决紧急矩阵* 。例如，影响小且紧急程度低的事件被视为严重性较低的事件。 
  +  **高（H）：** 您的业务将受到重大影响。与 AWS 资源相关的应用程序的关键功能不可用。它们将被预留给对生产系统影响最大的事件。由于补救具有时效性，事件的影响会迅速扩大。 
  +  **中（M）：** 与 AWS 资源相关的商业服务或应用程序会受到一定程度的影响，并且处于降级状态。有助于实现服务等级目标（SLO，Service Level Objective）的应用程序在服务等级协议（SLA，Service Level Agreement）限制内受到影响。系统可以在性能降低的情况下运行，而不会对财务和声誉产生很大影响。 
  +  **低（L）：** 与 AWS 资源相关的商业服务或应用程序的非关键功能受到影响。系统可以在性能降低的情况下运行，对财务和声誉产生的影响极小。 
+  **使安全控制机制标准化：** 使安全控制机制标准化的目标是实现操作结果的一致性、可追溯性和可重复性。加快实施对事件响应至关重要的关键活动的标准化，例如： 
  +  **身份和访问权限管理：** 建立用于控制对数据的访问以及管理人类和机器身份的权限的机制。将您自己的身份和访问权限管理扩展到云，并使用具有单点登录和基于角色的权限的联合安全性来优化访问权限管理。有关标准化访问权限管理的最佳实践建议和改进计划，请参阅《安全性支柱》白皮书的 [“身份和访问权限管理”部分](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html) 。
  +  **漏洞管理：** 建立机制来识别 AWS 环境中的漏洞，攻击者可能会利用这些漏洞来破坏和滥用您的系统。将预防性和检测性控制机制用作安全机制，以响应安全事件并缓解安全事件可能带来的影响。将威胁建模等流程标准化，使之成为基础设施构建和应用程序交付生命周期的一部分。
  +  **配置管理：** 对于在 AWS 云 中部署资源，定义标准配置，并使其过程实现自动化。通过实施基础设施和资源预置的标准化，有助于降低因错误部署或意外的人为错误配置而带来的错误配置风险。请参阅《卓越运营支柱》白皮书的 [“设计原则”部分](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-principles.html) ，以获取实施此控制机制的指南和改进计划。
  +  **用于审计控制机制的日志记录和监控：** 实施一些机制来监控资源的故障、性能下降和安全问题。通过使这些控制机制标准化，还对系统中发生的活动进行审计跟踪，有助于及时对问题进行分类和补救。SEC04 [（“您如何检测和调查安全事件？”）](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) 下的最佳实践提供了有关实施此控制机制的指南。
+  **使用自动化：** 利用自动化，可以及时地大规模解决事件。AWS 提供了多种服务，以在事件响应策略的上下文中实施自动化。请专注于在自动化和人工干预之间找到适当的平衡。您在行动手册和运行手册中构建事件响应时，系统会自动执行可重复的步骤。使用 AWS Systems Manager Incident Manager 等 AWS 服务 [更快地解决 IT 事件](https://aws.amazon.com/blogs/aws/resolve-it-incidents-faster-with-incident-manager-a-new-capability-of-aws-systems-manager/)。使用 [开发人员工具](https://aws.amazon.com/devops/) 提供版本控制，并自动实施 [Amazon Machine Images (AMI)](https://aws.amazon.com/amis/) 和基础设施即代码（IaC）部署，而无需人工干预。在适用的情况下，使用 Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、AWS Config 和 Amazon Macie 等托管服务，来自动实施检测和合规性评估。使用 Amazon DevOps Guru 等机器学习服务来优化检测功能，在异常操作模式问题出现之前检测出它们。
+  **进行根本原因分析并汲取经验教训：** 实施一些机制，以在事件后响应审查过程中记录经验教训。当事件的根本原因揭示出更大的缺陷、设计缺陷、配置错误或再次发生的可能性时，它就会被归类为问题。在这种情况下，请分析并解决问题，最大程度地减小对正常操作的中断。 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS 安全事件响应指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [ NIST：计算机安全事件处理指南 ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)

 **相关视频：** 
+  [在 AWS 中自动化事件响应和取证 ](https://youtu.be/f_EcwmmXkXk)
+ [ 运行手册、事件报告和事件响应 DIY 指南 ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [ 准备和响应 AWS 环境中的安全事件 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **相关示例：** 
+  [实验室：使用 Jupyter 的事件响应行动手册 – AWS IAM](https://www.wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html) 
+ [ 实验：使用 AWS 控制台和 CLI 的事件响应 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP03 准备取证能力
<a name="sec_incident_response_prepare_forensic"></a>

 对于意外事件响应者来说，了解取证调查在什么情况下、如何适合您的响应计划非常重要。您的组织应定义要收集的证据以及收集过程中使用的工具。确定并准备适当的取证调查能力，包括外部专家、工具和自动化。您应预先做出的一个关键决定是，是否从实时系统中收集数据。如果系统断电或重新启动，某些数据（例如，易失性内存或活动网络连接的内容）将会丢失。 

您的响应团队可以结合使用 AWS Systems Manager、Amazon EventBridge 和 AWS Lambda 等工具，在操作系统和 VPC 流量镜像中自动运行取证工具以捕获网络数据包，从而收集非持久化证据。使用定制取证工作站以及可供响应者访问的工具，在专用安全账户中进行其他活动，例如日志分析或分析磁盘镜像。

定期将相关日志发送到数据存储，实现高持久性和完整性。响应者应有权访问这些日志。AWS 提供了多种工具来简化日志调查，例如 Amazon Athena、Amazon OpenSearch Service（OpenSearch Service）和 Amazon CloudWatch Logs Insights。此外，使用 Amazon Simple Storage Service（Amazon S3）Object Lock 安全地保留证据。该服务遵循 WORM（一次写入多次读取，write-once-read-many）模型，防止对象在定义的时段内被删除或覆盖。由于取证调查技术需要专家培训，因此您可能需要聘请外部专家。

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  确定取证能力：分析组织的取证调查能力、可用工具和外部专家。 
+  [自动化事件响应和取证 ](https://youtu.be/f_EcwmmXkXk)

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [如何在 AWS 中自动实施取证磁盘收集](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) 

# SEC10-BP04 自动控制功能
<a name="sec_incident_response_auto_contain"></a>

自动控制意外事件并从意外事件中恢复，以缩短响应时间和减少对组织的影响。

当您从行动手册中创建并练习流程和工具之后，您可以将此逻辑解构到基于代码的解决方案中，很多响应者可以将此逻辑用作工具来自动进行响应，因此消除了响应者的分歧或猜测。这样可以加快响应的生命周期。下一个目标是允许此代码被警报或事件自身而不是被人类响应者调用以实现完全自动化，从而创建由事件驱动的响应。这些过程还应自动将相关数据添加到您的安全系统中。例如，涉及来自不需要的 IP 地址的流量的意外事件可以自动填充 AWS WAF 阻止列表或 Network Firewall 规则组，从而防止进一步的活动。

![\[AWS architecture diagram showing WAF WebACL logs processing and IP address blocking flow between accounts.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/aws-waf-automate-block.png)


*图 3：AWS WAF 自动阻止已知的恶意 IP 地址。*

使用由事件驱动的响应系统，检测性机制会触发一个响应机制，以自动修复事件。您可以使用由事件驱动的响应能力，以缩短检测机制与响应机制之间的价值实现时间。要创建这个由事件驱动的架构，您可以使用 AWS Lambda，这是一项无服务器计算服务，可运行您的代码以响应事件并为您自动管理底层计算资源。例如，假设您有一个 AWS 账户并为其启用了 AWS CloudTrail 服务。如果已禁用 AWS CloudTrail（通过 `cloudtrail:StopLogging` API 调用），则您可以使用 Amazon EventBridge 监控特定的 `cloudtrail:StopLogging` 事件，并通过调用 AWS Lambda 函数来调用 `cloudtrail:StartLogging` 以重新启动日志记录功能。

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>

 自动控制功能。 

## 资源
<a name="resources"></a>

 **相关文档：** 
+ [AWS 意外事件响应指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 

 **相关视频：** 
+  [准备和响应 AWS 环境中的安全意外事件](https://youtu.be/8uiO0Z5meCs) 

# SEC10-BP05 预置访问权限
<a name="sec_incident_response_pre_provision_access"></a>

确保事件响应者将正确的访问权限预置到 AWS 中，以缩短调查到恢复所需的时间。

 **常见反模式：** 
+  使用根账户进行事件响应。 
+  变更现有用户账户。 
+  在提供实时权限提升时直接操作 IAM 权限。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>

AWS 建议尽可能减少或消除对长期有效凭证的依赖，转而使用临时凭证和 *实时* 权限提升机制。长期有效的凭证容易带来安全风险，并且会增加运营开销。对于大多数管理任务以及事件响应任务，建议您对管理访问实施 [身份联合验证](https://docs.aws.amazon.com/identity/federation/) 以及 [临时上报](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。在此模型中，用户请求提升到更高级别的权限（例如事件响应角色），如果用户符合提升条件，则会向审批者发送请求。如果请求获得批准，用户将收到一组临时的 [AWS 凭证](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) ，可用于完成用户任务。在这些凭证过期后，用户必须提交新的提升请求。

 在大多数事件响应场景中，建议使用临时权限提升。执行此操作的正确方法是使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) 和 [会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) 来限定访问范围。 

 在一些场景中，联合身份不可用，例如： 
+  与被盗用的身份提供者（IdP）相关的中断。 
+  导致联合访问管理系统损坏的错误配置或人为错误。 
+  恶意活动，例如分布式拒绝服务（DDoS，Distributed Denial of Service）事件或导致系统不可用的活动。 

 在上述情况下，应配置紧急 *Break Glass* 访问，以允许调查事件并及时给予补救。我们建议您使用 [具有适当权限的 IAM 用户，](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) 来执行任务和访问 AWS 资源。请仅将根凭证用于 [需要根用户访问权限的任务](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。要确认事件响应者对 AWS 和其他相关系统是否具有正确的访问权限级别，建议预置专用的用户账户。用户账户需要特许的访问权限，并且必须受到严格的控制和监视。在构建账户时，必须使用执行必要任务所需的最少权限，并且访问级别应基于作为事件管理计划的一部分创建的行动手册。 

 最好使用专门构建的专用用户和角色。通过添加 IAM 策略来临时提升用户或角色的访问权限，既会导致无法清楚地了解用户在事件期间拥有哪些访问权限，又会带来无法撤销提升的权限的风险。 

 请务必删除尽可能多的依赖项，以确保能在尽可能多的故障场景中获得访问权限。为了支持此操作，可创建一个行动手册，验证是否在专用的安全账户中创建事件响应用户作为 AWS Identity and Access Management 用户，而不是通过任何现有的联合身份验证或单点登录（SSO）解决方案管理他们。每个响应者都必须有自己的指定账户。账户配置必须实施 [强密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 和多重身份验证（MFA）。如果事件响应行动手册仅需要对 AWS 管理控制台的访问权限，则用户不应配置访问密钥，并且应明确禁止用户创建访问密钥。可以使用 IAM 策略或服务控制策略（SCP，Service Control Policy）进行此配置，如 AWS 安全最佳实践（适用于 [AWS Organizations SCP）中所述](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。用户仅能够在其他账户中代入事件响应角色，而不应具有其他任何权限。 

 在事件处理期间，可能需要向其他内部或外部人员授予访问权限，以支持调查、补救或恢复活动。在这种情况下，可以使用前面提到的行动手册机制，并且必须创建一个流程，确保在事件结束后立即撤消其他任何访问权限。 

 要确保能正确地监控和审计对事件响应角色的使用，至关重要的一点是，为此目的创建的 IAM 用户账户不会在人员之间共享，并且不会使用 AWS 账户 根用户，除非 [特定任务要求这样做](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。如果需要根用户（例如，对特定账户的 IAM 访问权限不可用），请使用单独的流程和可用的行动手册来验证根用户密码和 MFA 令牌的可用性。 

 要为事件响应角色配置 IAM 策略，请考虑使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 来生成基于 AWS CloudTrail 日志的策略。为此，请在非生产账户中向事件响应角色授予管理员访问权限，并运行行动手册。完成后，会创建一个策略，仅允许已执行的操作。之后，可以跨所有账户将此策略应用于所有事件响应角色。您可能希望为每个行动手册创建一个单独的 IAM 策略，以便更轻松地进行管理和审计。示例行动手册可能包括针对勒索软件、数据泄露、丢失生产访问权限和其他场景的响应计划。 

 使用事件响应用户账户可在 [其他 AWS 账户 中代入专用的事件响应 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。必须将这些角色配置为仅可由安全账户中的用户代入，并且信任关系必须要求调用主体已使用 MFA 进行身份验证。角色必须使用严格界定的 IAM 策略来控制访问。确保这些角色的所有 `AssumeRole` 请求都记录在 CloudTrail 中并发出提醒，并确保记录使用这些角色执行的任何操作。 

 强烈建议清楚地命名 IAM 用户账户和 IAM 角色，以便在 CloudTrail 日志中轻松找到他们。例如，将 IAM 账户命名为 `<USER_ID>-BREAK-GLASS，` 并将 IAM 角色命名为 `BREAK-GLASS-ROLE`。

 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 用于记录 AWS 账户中的 API 活动，并且应该用于 [配置关于使用事件响应角色的提醒。](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)。请参阅博文，了解有关配置使用根密钥时的提醒。可以修改说明以配置 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指标筛选条件，从而筛选 `AssumeRole` 事件（与事件响应 IAM 角色相关）： 

```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "<INCIDENT_RESPONSE_ROLE_ARN>" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```

 由于事件响应角色可能具有高级别的访问权限，因此，请务必将这些提醒转至广泛的群体，并及时采取适当的行动。 

 在事件处理期间，响应者可能需要访问不受 IAM 直接保护的系统。它们可能包括 Amazon Elastic Compute Cloud 实例、Amazon Relational Database Service 数据库或软件即服务（SaaS）平台。强烈建议不要使用 SSH 或 RDP 等本机协议，而是使用[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 对 Amazon EC2 实例进行所有管理访问。可以使用安全且经过审计的 IAM 控制此访问。此外，还可以使用 [AWS Systems Manager Run Command 文档自动实施行动手册的部分内容，](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)这可以减少用户出错的机会并缩短恢复时间。对于访问数据库和第三方工具，我们建议将访问凭证存储在 AWS Secrets Manager 中，并向事件响应者角色授予访问权限。 

 最后，事件响应 IAM 用户账户的管理应该添加到您的 [合并人员、移动人员和离开人员流程中，](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html) 并定期进行检查和测试，以确认只允许预期访问。 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [管理对 AWS 环境的临时提升的访问权限](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) 
+  [AWS 安全事件响应指南 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 
+  [为 IAM 用户设置账户密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) 
+  [在 AWS 中使用多重身份验证（MFA）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) 
+ [ 使用 MFA 配置跨账户存取 ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ 使用 IAM Access Analyzer 生成 IAM 策略 ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [ 多账户环境中的 AWS Organizations 服务控制策略的最佳实践 ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ 如何在使用 AWS 账户的根访问密钥时接收通知 ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ 使用 IAM 托管策略创建精细会话权限 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)

 **相关视频：** 
+ [ 在 AWS 中自动化事件响应和取证 ](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+  [运行手册、事件报告和事件响应 DIY 指南](https://youtu.be/E1NaYN_fJUo) 
+ [ 准备和响应 AWS 环境中的安全事件 ](https://www.youtube.com/watch?v=8uiO0Z5meCs)

 **相关示例：** 
+ [ 实验室：AWS 账户设置和根用户 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
+ [ 实验：使用 AWS 控制台和 CLI 的事件响应 ](https://wellarchitectedlabs.com/security/300_labs/300_incident_response_with_aws_console_and_cli/)

# SEC10-BP06 预先部署工具
<a name="sec_incident_response_pre_deploy_tools"></a>

 确保安全人员将适当的工具预先部署到 AWS 中，以缩短调查到恢复的时间。 

要自动化安全工程和运营功能，您可以使用 AWS 提供的一整套 API 和工具。您可以完全自动执行身份管理、网络安全、数据保护和监控功能，并使用您已采用的常见软件开发方法交付这些功能。当构建安全自动化时，您的系统可以监控、审核和启动响应，您不必安排人员监控您的安全位置并对事件做出人为响应。跨 AWS 服务，自动向意外事件响应者提供可搜索的相关日志数据的有效方法是启用 [Amazon Detective](https://aws.amazon.com/detective/).

如果您的事件响应团队继续以同样的方式响应警报，警报可能会让他们应接不暇。随着时间的推移，团队对警报的敏感性可能会下降，并可能在处理正常情况时犯错或者错过异常警报。利用一些功能自动处理重复和正常的警报，并将敏感、特殊的事件交由人员来处理，这样有助于避免疲于应对警报。集成异常检测系统（例如 Amazon GuardDuty、AWS CloudTrail Insights 和 Amazon CloudWatch Anomaly Detection）可以减轻常见的基于阈值的警报负担。

您可以通过编程方式自动执行此流程中的步骤，从而改进手动流程。为事件定义修复模式之后，您可以将此模式分解为可执行的逻辑，并编写代码以执行此逻辑。随后，响应者即可执行此代码以修复问题。随着时间的推移，您可以自动化越来越多的步骤，并最终自动处理各类常见事件。

对于在您的 Amazon Elastic Compute Cloud（Amazon EC2）实例的操作系统内运行的工具，您应使用 AWS Systems Manager Run Command 执行评估，它可以使用您安装在 Amazon EC2 实例操作系统中的代理，安全地远程管理实例。它需要使用 Systems Manager 代理（SSM 代理），很多亚马逊云机器镜像（AMI，Amazon Machine Image）中都默认安装了此代理。但请注意，一旦某个实例受损，此实例上运行的工具或代理所做出的任何响应都应被视为不可信赖的响应。

 **未建立此最佳实践暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  预先部署工具：确保安全人员在 AWS 中预先部署了适当的工具，以便对意外事件做出适当响应。 
  +  [实验：使用 AWS 管理控制台和 CLI 响应意外事件 ](https://wellarchitectedlabs.com/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.html)
  + [ 使用 Jupyter 的意外事件响应行动手册 – AWS IAM ](https://wellarchitectedlabs.com/Security/300_Incident_Response_Playbook_with_Jupyter-AWS_IAM/README.html)
  +  [AWS 安全自动化 ](https://github.com/awslabs/aws-security-automation)
+  实施资源标记：用信息标记资源（例如，正在调查的资源的代码），以便在意外事件期间确定资源。
  + [AWS 标记策略 ](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS 意外事件响应指南 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)

 **相关视频：** 
+  [ 运行手册、事件报告和事件响应 DIY 指南 ](https://youtu.be/E1NaYN_fJUo)

# SEC10-BP07 执行实际试用
<a name="sec_incident_response_run_game_days"></a>

实际试用（也称为模拟或练习）是一些内部事件，可提供结构化机会，使您能够在逼真的场景中练习您的事件管理计划和流程。这些事件应让响应者练习在真实场景中使用的相同工具和技术，甚至应该模仿真实环境。实际试用主要涉及做好准备，并以迭代方式提高您的响应能力。有些原因能够让您发现开展实际试用活动的价值，这些原因包括： 
+ 验证准备情况
+ 建立信心 – 从模拟中学习以及开展员工培训
+ 履行合规或合同义务
+ 生成资格鉴定构件
+ 敏捷 – 增量改进
+ 速度更快并且不断改进的工具
+ 优化沟通和上报
+ 适应罕见和意外的情况

由于这些原因，通过参与模拟活动而学到的东西能够让组织有效地应对压力事件。开展既逼真又有益的模拟活动可能是一项非常困难的练习。尽管对可处理常见事件的流程或自动化进行测试能够实现一些优势，但只有参与创造性的 [安全意外事件响应模拟（SIRS，Security Incident Response Simulation）](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/security-incident-response-simulations.html) 活动以测试您应对意外情况的能力并持续改进时，这些测试才能体现价值。

创建为您的环境、团队和工具定制的自定义模拟。找出一个问题，并围绕该问题设计您的模拟。这样的问题可以包括凭证泄露、服务器与不必要的系统通信或者导致未经授权暴露的错误配置。确定由熟悉组织的工程师创建场景，并确定另一个团队来参与其中。场景应是逼真的且具有挑战性，这样才有价值。它应包含掌握日志记录、通知、上报和执行运行手册或自动化的机会。在模拟过程中，响应者应练习他们的技术和组织技能，领导者应培养他们的意外事件管理技能。在模拟结束时，庆祝团队取得的成效，并寻找迭代、重复和扩展到深度模拟的方法。

[AWS 已创建意外事件响应运行手册模板，](https://github.com/aws-samples/aws-incident-response-playbooks) 您不仅可以使用该模板准备您的响应工作，还可以将该模板用作模拟的基础。在规划时，可以将模拟分为五个阶段。

**证据收集： **在这个阶段，团队将通过各种方式获得提醒，例如内部票证系统、来自监控工具的提醒、匿名提示甚至是公共新闻。之后，团队开始审查基础设施和应用程序日志来确定问题来源。此步骤还将涉及内部上报和意外事件领导力。在确定后，团队将继续控制意外事件

**控制意外事件： **团队确定发生了意外事件并确立了问题来源。现在，团队应采取行动来控制意外事件，例如，通过禁用已泄露的凭证、隔离计算资源或撤销角色的权限。

**解决意外事件： **现在，团队已控制意外事件，他们将努力减少应用程序或基础设施配置中任何易受攻击的漏洞。这可能包括轮换用于工作负载的所有凭证、修改访问控制列表（ACL，Access Control List）或更改网络配置。

**未建立这种最佳实践的情况下暴露的风险等级：** 中

## 实施指导
<a name="implementation-guidance"></a>
+  运行 [实际试用](https://wa.aws.amazon.com/wat.concept.gameday.en.html)：运行模拟 [意外事件](https://wa.aws.amazon.com/wat.concept.incident.en.html) 响应 [事件（实际试用）](https://wa.aws.amazon.com/wat.concept.event.en.html) 来处理涉及关键人员和管理的各种威胁。
+  记录经验教训：从运行 [实际试用](https://wa.aws.amazon.com/wat.concept.gameday.en.html) 中获得的经验教训应成为反馈循环的一部分以改进流程。

## 资源
<a name="resources"></a>

 **相关文档：** 
+ [AWS 意外事件响应指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+ [AWS 弹性灾难恢复](https://aws.amazon.com/cloudendure-disaster-recovery/) 

 **相关视频：** 
+ [ 运行手册、事件报告和事件响应 DIY 指南 ](https://youtu.be/E1NaYN_fJUo)