SEC03-BP03 建立紧急访问流程 - 安全支柱
实施指导 资源

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

SEC03-BP03 建立紧急访问流程

创建一个流程，便于在集中式身份提供程序偶尔出现问题时紧急访问您的工作负载。

必须针对可能导致紧急事件的不同故障模式设计流程。例如，在正常情况下，您的员工用户使用集中式身份提供商 (SEC02-BP04) 联合到云端来管理其工作负载。但是，如果您的集中式身份提供程序出现故障，或者云中联合身份验证的配置被修改，则您的员工用户可能无法联合到云中。紧急访问流程允许授权管理员通过其他方式（例如其他联合形式或直接用户访问）访问云资源，以解决联合配置或工作负载的问题。在恢复正常的联合机制之前，将使用紧急访问流程。

期望结果：

  • 您已经定义并记录了算是紧急情况的故障模式：考虑您的正常情况以及用户管理其工作负载所依赖的系统。考虑这些依赖项中的每一个在哪些情形下会发生故障并导致紧急情况。您可能会发现可靠性支柱中的问题和最佳实践有助于识别故障模式和构建更具韧性的系统，从而最大限度地降低发生故障的可能性。

  • 您已记录了将故障确认为紧急情况所必须遵循的步骤。例如，您可以要求身份管理员检查主身份提供程序和备用身份提供程序的状态，如果两者均不可用，则宣布身份提供程序故障为紧急事件。

  • 您已针对每种紧急情况或故障模式定义了紧急访问流程。应尽可能明确具体，这样可减少用户针对所有类型的紧急情况过度使用通用流程的倾向。紧急访问流程描述了每个流程的使用情形，以及哪些情况下不应使用该流程，并指出了可能适用的替代流程。

  • 您的流程有详细的说明和行动手册，便于快速有效地遵循。请记住，对用户来说，紧急事件可能让人很煎熬，他们可能面临极大的时间压力，因此流程设计应尽可能简单。

常见反模式：

  • 您没有详细记录并经过充分测试的紧急访问流程。您的用户没有为紧急情况做好准备，在出现紧急事件时遵循临时流程。

  • 您的紧急访问流程依赖于与普通访问机制相同的系统（例如集中式身份提供程序）。这意味着，此类系统的故障可能会同时影响您的正常访问和紧急访问机制，并削弱您从故障中恢复的能力。

  • 您的紧急访问流程被用于非紧急情况。例如，您的用户经常滥用紧急访问流程，因为他们发现直接进行更改比通过管道提交更改更容易。

  • 您的紧急访问流程未生成足够的日志用于审核这些流程，或者没有监控日志以提醒可能存在的流程滥用。

建立此最佳实践的好处：

  • 通过拥有记录详实且经过充分测试的紧急访问流程，您可以减少用户响应和解决紧急事件所花费的时间。这样可以缩短停机时间，提高您向客户提供的服务的可用性。

  • 您可以跟踪每个紧急访问请求，检测未经授权企图对非紧急事件滥用该过程的行为，并发出警报。

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

实施指导

本节为与部署的工作负载相关的几种故障模式创建紧急访问流程提供了指导 AWS，首先是适用于所有故障模式的通用指南，然后是基于故障模式类型的具体指导。

适用于所有故障模式的通用指南

在针对故障模式设计紧急访问流程时，请考虑以下几点：

  • 记录流程的先决条件和假设：何时应使用该流程、何时不应使用该流程。它有助于详细说明故障模式并记录假设，例如其他相关系统的状态。例如，故障模式 2 的过程假设身份提供者可用，但上的 AWS 配置已修改或已过期。

  • 预先创建紧急访问流程所需的资源 (SEC10-BP05)。例如，IAM使用用户和角色预先创建紧急访问权限 AWS 账户 ，并在所有工作负载帐户中创建跨账户IAM角色。这样可以验证在发生紧急事件时这些资源是否已准备就绪并且可用。通过预先创建资源，您就不会依赖在紧急情况下可能不可用的 AWS 控制平面APIs（用于创建和修改 AWS 资源）。此外，通过预先创建IAM资源，您无需考虑最终一致性可能导致的延迟。

  • 将紧急访问流程纳入事件管理计划 (SEC10-BP02)。记录如何跟踪紧急事件并将其传达给组织中的其他人，例如同级团队、您的领导层，如果适用，还包括外部的客户和业务合作伙伴。

  • 在现有的服务请求工作流程系统（如果有）中定义紧急访问请求流程。通常，此类工作流程系统允许您创建受理表来收集有关请求的信息，在工作流程的每个阶段跟踪请求，并添加自动和手动审批步骤。将每个请求与事件管理系统中所跟踪的相应紧急事件关联起来。通过拥有统一的紧急访问系统，您可以在单个系统中跟踪这些请求，分析使用趋势并改进流程。

  • 确保您的紧急访问流程只能由授权用户启动，并且需要用户的同事或管理层（视情况而定）的批准。审批流程在工作时间内和工作时间之外应该能够有效运作。明确在主审批人抽不开身的情况下，如何允许辅助审批人审批请求，并沿管理链条上报，直至获得批准。

  • 验证流程是否会针对成功和失败的紧急访问尝试，生成详细的审计日志和事件。监控请求流程和紧急访问机制，以检测滥用或未经授权的访问。将活动与事件管理系统中正在发生的紧急事件关联起来，并在预期时间段之外执行操作时发出警报。例如，您应监控紧急访问 AWS 账户中的活动并发出警报，因为在正常操作过程中绝不应使用该账户。

  • 定期测试紧急访问流程，以确保步骤清楚明了，并快速高效地授予正确的访问级别。您的紧急访问流程应作为事件响应模拟 (SEC10-BP07) 和灾难恢复测试 (REL13-B P03) 的一部分进行测试。

故障模式 1：用于联合的身份提供商不可 AWS 用

正如 SEC02-BP04 中所述，依靠集中式身份提供商，我们建议依靠集中式身份提供商来联合您的员工用户以授予访问权限。 AWS 账户您可以使用 Identity Center 与 AWS 组织 AWS 账户 中的多个组织进行联合，也可以使用联合IAM身份中心与个人 AWS 账户 联合。IAM在这两种情况下，员工用户都要先通过集中式身份提供程序进行身份验证，然后才会被重定向到 AWS 登录端点进行单点登录。

万一集中式身份提供程序不可用，员工用户就无法联合到 AWS 账户 或管理其工作负载。在这种紧急情况下，您可以为一小部分管理员提供紧急访问流程，让他们 AWS 账户 能够执行关键任务，而这些任务迫不及待您的集中式身份提供商恢复在线状态后才能执行。例如，您的身份提供商在 4 小时内不可用，在此期间，您需要修改生产账户中 Amazon A EC2 uto Scaling 组的上限，以应对客户流量意外激增的情况。您的应急管理员应遵循紧急访问流程，以获得对特定作品的访问权限 AWS 账户 并进行必要的更改。

紧急访问过程依赖于预先创建的紧急访问权限 AWS 账户 ，该访问仅用于紧急访问并具有支持紧急访问过程的 AWS 资源（例如IAM角色和IAM用户）。在正常运营期间，任何人都不得访问紧急访问账户，而且您必须对滥用该账户的行为进行监控并发出警报（有关更多详情，请参阅前面的“通用指南”部分）。

紧急访问账户具有紧急访问IAM角色，有权在需要紧急访问的中 AWS 账户 扮演跨账户角色。这些IAM角色是预先创建的，并配置了信任紧急账户IAM角色的信任策略。

紧急访问过程可以使用以下方法之一：

  • 您可以在紧急访问帐户中为紧急管理员预先创建一组IAM用户，并附上相关的强密码和MFA令牌。这些IAM用户有权代入IAM角色，然后允许跨账户访问需要紧急访问 AWS 账户 的地方。我们建议尽可能少地创建此类用户，并将每个用户分配给一个紧急状况管理员。在紧急情况下，紧急管理员用户使用其密码和MFA令牌码登录紧急访问帐户，在紧急帐户中切换到紧急访问IAM角色，最后在工作负载帐户中切换到紧急访问IAM角色以执行紧急更改操作。这种方法的优点是，每个IAM用户都被分配给一个紧急管理员，您可以通过查看事件来知道哪个用户已登录。 CloudTrail 缺点是，您必须维护多个IAM用户及其关联的长期密码和MFA令牌。

  • 您可以使用紧急访问AWS 账户 根用户登录紧急访问账户，担任紧急访问IAM角色，并在工作负载账户中担任跨账户角色。我们建议为 root 用户设置一个强密码和多个MFA令牌。我们还建议将密码和MFA令牌存储在安全的企业证书库中，以强制执行严格的身份验证和授权。您应该保护密码和MFA令牌重置因素：将帐户的电子邮件地址设置为由您的云安全管理员监控的电子邮件通讯组列表，并将该帐户的电话号码设置为也由安全管理员监控的共享电话号码。这种方法的优点是只需管理一组根用户凭证。缺点是，由于这是共享用户，多个管理员都能以根用户身份登录。您必须审计企业保管库日志事件，以确定是哪位管理员查看了根用户密码。

故障模式 2：开启的身份提供商配置 AWS 已修改或已过期

要允许您的员工用户联合到 AWS 账户，您可以使用外部IAM身份提供商配置身份中心或创建IAM身份提供商 (SEC02-BP04)。通常，您可以通过导入身份提供商提供的SAML元数据XML文档来配置这些文档。元数据XML文档包括一个 X.509 证书，该证书对应于身份提供者用来签署其断言的私钥。SAML

管理员可能会错误地修改或删除这些配置。 AWS在另一种情况下，导入到的 X.509 证书 AWS 可能会过期，并且尚未将XML带有新证书的新元数据导入。 AWS这两种情况都可能使 AWS 您的员工用户无法联合，从而导致紧急情况。

在这种紧急情况下，您可以向您的身份管理员提供访问权限 AWS 以修复联盟问题。例如，您的身份管理员使用紧急访问流程登录紧急访问权限 AWS 账户，切换到 Identity Center 管理员帐户中的角色，并通过从您的身份提供商导入最新的SAML元数据XML文档来更新外部身份提供商配置，以重新启用联合。修复联合后，您的员工用户将继续使用正常操作流程联合到其工作负载账户。

您可以按照前面的故障模式 1 中详述的方法来创建紧急访问流程。您可以向您的身份管理员授予最低访问权限，使其只能访问 Identity Center 管理员账户，并使用该账户对 Identity Center 执行操作。

故障模式 3：Identity Center 中断

万一出现IAM身份中心或 AWS 区域 中断的情况，我们建议您设置一个配置，用于提供对身份中心的临时访问权限 AWS Management Console。

紧急访问过程使用身份提供商与紧急账户IAM的直接联合。有关流程和设计注意事项的详细信息，请参阅《设置对 AWS Management Console的紧急访问》。

实施步骤

针对所有故障模式的通用步骤

  • 创建 AWS 账户 专门用于紧急访问的流程。预先创建账户中所需的IAM资源，例如IAM角色或IAM用户，以及可选的IAM身份提供者。此外，在工作负载中预先创建跨账户IAM角色， AWS 账户 并与紧急访问账户中的相应IAM角色建立信任关系。您可以AWS CloudFormation StackSets 与一起 AWS Organizations使用在组织的成员账户中创建此类资源。

  • 创建 AWS Organizations 服务控制策略 (SCPs) 以拒绝删除和修改成员 AWS 账户中的跨账户IAM角色。

  • 启用 CloudTrail 紧急访问权限 AWS 账户 并将跟踪事件发送到日志集中的中央 S3 存储桶 AWS 账户。如果您使用 AWS Control Tower 来设置和管理您的 AWS 多账户环境，则默认情况下，您使用 AWS Control Tower 或注册的每个账户都 AWS Control Tower 已 CloudTrail 启用并发送到专用日志存档 AWS 账户中的 S3 存储桶。

  • 通过创建与控制台登录和紧急IAM角色活动相匹配的 EventBridge 规则，监控紧急访问账户API的活动。当事件管理系统中所跟踪的正在发生的紧急事件之外出现活动时，向安全运营中心发送通知。

故障模式 1：用于联合的身份提供商 AWS 不可用和故障模式 2：开启的身份提供商配置已修改或已过期的其他步骤 AWS

  • 根据您选择的紧急访问机制，预先创建资源：

    • 使用IAM用户：使用强密码和关联MFA设备预先创建IAM用户。

    • 使用紧急账户的根用户：为根用户配置一个强密码，并将该密码存储在您的企业凭证库中。将多个物理MFA设备与 root 用户关联，并将设备存储在紧急管理员团队成员可以快速访问的位置。

针对“故障模式 3：Identity Center 中断”的其他步骤

资源

相关的 Well-Architected 最佳实践：

相关文档：

相关视频：

相关示例：