SEC10-BP02 制定事件管理计划 - AWS Well-Architected Framework
实施指导资源

SEC10-BP02 制定事件管理计划

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

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

实施指导

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

云的许多操作角色和要求都与本地环境中的相同。在创建事件管理计划时，应考虑最符合业务成果和合规性要求的响应和恢复策略，这一点非常重要。例如，如果您在 AWS 中运行在美国符合 FedRAMP 标准的工作负载，则遵守 《NIST SP 800-61 计算机安全处理指南》会很有帮助。同样，在使用欧洲 PII（Personally Identifiable Information，个人身份信息）数据运行工作负载时，请考虑如何根据 欧盟通用数据保护条例（GDPR，General Data Protection Regulation）。

在为 AWS 中运行的工作负载构建事件管理计划时，请首先使用 AWS 责任共担模式，以便构建针对事件响应的深度防御方法。在此模式中，AWS 负责管理云本身的安全，云内部的安全则由您负责。这意味着您将保留控制权，并对选择实施的安全控制机制负责。此 AWS 安全事件响应指南 详细介绍了构建以云为中心的事件管理计划的关键概念和基本指南。

必须不断地迭代有效的事件管理计划，使其与您的云运营目标保持一致。在创建和改进事件管理计划时，请考虑使用下面详述的实施计划。

  • 针对事件响应进行的培训和训练： 当与定义的基线存在偏差（例如，部署错误或配置错误）时，您可能需要做出响应并展开调查。要成功做到这一点，您必须了解可用于 AWS 环境中的安全事件响应的控制机制和功能，以及准备、培训和训练参与事件响应的云团队时要考虑的流程。

    • 行动手册 和 运行手册 是有效机制，用于在训练如何应对事件时建立一致性。首先，在事件响应期间构建经常运行的过程的初始列表，并在学习或使用新过程时继续迭代。

    • 通过计划的 实际试用，将行动手册和运行手册社交化。在实际试用期间，在受控环境中模拟事件响应，帮助您的团队回顾如何进行响应，以及验证参与事件响应的团队是否熟悉工作流。审查模拟事件的结果以明确改进措施，并确定有关进一步的训练或其他工具的需求。

    • 在安全方面，人人有责。通过让通常运行工作负载的所有人员参与进来，建立事件管理流程的集体性知识。这项工作应该涵盖业务的所有方面，即运营、测试、开发、安全性、业务运营和业务部门的负责人均应参与其中。

  • 将事件管理计划归档： 将一些工具和过程归档，而这些工具和过程用于记录、处理、传达进度，以及提供有关活动事件的通知。事件管理计划旨在确保尽快恢复正常操作、将业务影响降至最低并始终通知所有相关方。事件示例包括（但不限于）网络连接丢失或降级、进程或 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 资源相关的商业服务或应用程序的非关键功能受到影响。系统可以在性能降低的情况下运行，对财务和声誉产生的影响极小。

  • 使安全控制机制标准化： 使安全控制机制标准化的目标是实现操作结果的一致性、可追溯性和可重复性。加快实施对事件响应至关重要的关键活动的标准化，例如：

    • 身份和访问权限管理： 建立用于控制对数据的访问以及管理人类和机器身份的权限的机制。将您自己的身份和访问权限管理扩展到云，并使用具有单点登录和基于角色的权限的联合安全性来优化访问权限管理。有关标准化访问权限管理的最佳实践建议和改进计划，请参阅《安全性支柱》白皮书的 “身份和访问权限管理”部分 。

    • 漏洞管理： 建立机制来识别 AWS 环境中的漏洞，攻击者可能会利用这些漏洞来破坏和滥用您的系统。将预防性和检测性控制机制用作安全机制，以响应安全事件并缓解安全事件可能带来的影响。将威胁建模等流程标准化，使之成为基础设施构建和应用程序交付生命周期的一部分。

    • 配置管理： 对于在 AWS Cloud 中部署资源，定义标准配置，并使其过程实现自动化。通过实施基础设施和资源预置的标准化，有助于降低因错误部署或意外的人为错误配置而带来的错误配置风险。请参阅《卓越运营支柱》白皮书的 “设计原则”部分 ，以获取实施此控制机制的指南和改进计划。

    • 用于审计控制机制的日志记录和监控： 实施一些机制来监控资源的故障、性能下降和安全问题。通过使这些控制机制标准化，还对系统中发生的活动进行审计跟踪，有助于及时对问题进行分类和补救。SEC04 （“您如何检测和调查安全事件？”） 下的最佳实践提供了有关实施此控制机制的指南。

  • 使用自动化： 利用自动化，可以及时地大规模解决事件。AWS 提供了多种服务，以在事件响应策略的上下文中实施自动化。请专注于在自动化和人工干预之间找到适当的平衡。您在行动手册和运行手册中构建事件响应时，系统会自动执行可重复的步骤。使用 AWS Systems Manager Incident Manager 等 AWS 服务 更快地解决 IT 事件。使用 开发人员工具 提供版本控制，并自动实施 Amazon Machine Images (AMI) 和基础设施即代码（IaC）部署，而无需人工干预。在适用的情况下，使用 Amazon GuardDuty、Amazon Inspector、AWS Security Hub、AWS Config 和 Amazon Macie 等托管服务，来自动实施检测和合规性评估。使用 Amazon DevOps Guru 等机器学习服务来优化检测功能，在异常操作模式问题出现之前检测出它们。

  • 进行根本原因分析并汲取经验教训： 实施一些机制，以在事件后响应审查过程中记录经验教训。当事件的根本原因揭示出更大的缺陷、设计缺陷、配置错误或再次发生的可能性时，它就会被归类为问题。在这种情况下，请分析并解决问题，最大程度地减小对正常操作的中断。

资源

相关文档：

相关视频：

相关示例：