设置对 Amazon Web Services Management Console 的紧急访问。 - Amazon IAM Identity Center
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

设置对 Amazon Web Services Management Console 的紧急访问。

IAM Identity Center 基于高度可用的 Amazon 基础设施构建,并使用可用区架构来消除单点故障。为了在万一发生 IAM Identity Center 或Amazon Web Services 区域中断时提供额外的保护,我们建议您设置一个可用于提供临时访问权限的配置Amazon Web Services Management Console。

概述

Amazon 让您能够:

如果您使用 IAM Identity Center,则可以使用这些功能来创建以下部分中所述的紧急访问配置。此配置使您能够使用 IAM Identity Center 作为 Amazon Web Services 账户 访问机制。如果 IAM Identity Center 中断,您的紧急操作用户可以使用与访问其账户相同的凭证,通过直接联合身份验证来登录 Amazon Web Services Management Console。当 IAM Identity Center 不可用,但 IAM 数据面板和外部身份提供商 (IdP) 可用时,此配置有效。

重要

我们建议您在发生中断之前部署此配置,因为如果您创建所需 IAM 角色的访问也被中断,您将无法创建该配置。此外,请定期测试此配置,以确保您的团队了解在 IAM Identity Center 中断时该怎么做。

紧急访问配置汇总

配置紧急访问需要完成以下任务:

  1. 在 Amazon Organizations 中的组织中创建一个紧急操作帐户。

  2. 使用基于 SAML 2.0 的联合身份验证将您的 IdP 连接到紧急操作帐户。

  3. 在紧急操作帐户中,为第三方身份提供商联合身份验证创建角色。此外,在每个工作负载帐户中创建紧急操作角色,并具有所需的权限。

  4. 为您在紧急操作账户中创建的 IAM 角色委派对工作负载账户的访问权限。要授权访问您的紧急操作帐户,请在您的 IdP 中创建一个没有成员的紧急操作组。

  5. 通过在 IdP 中创建启用 SAML 2.0 联合身份验证访问 Amazon Web Services Management Console 的规则,使 IdP 中的紧急操作组能够使用紧急操作角色。

在正常操作期间,没有人可以访问紧急操作帐户,因为 IdP 中的紧急操作组没有成员。如果 IAM Identity Center 中断,请使用您的 IdP 将受信任的用户添加到 IdP 中的紧急操作组。然后,这些用户可以登录到您的 IdP,导航到 Amazon Web Services Management Console,并在紧急操作帐户中承担紧急操作角色。从那里,这些用户可以将角色切换到需要执行操作工作的工作负载帐户中的紧急访问角色。

如何设计关键操作角色

通过此设计,您可以配置一个通过 IAM 联合身份验证的 Amazon Web Services 账户,以便用户可以承担关键操作角色。关键操作角色具有信任策略,使用户能够在工作负载帐户中担任相应的角色。工作负载帐户中的角色提供用户执行基本工作所需的权限。

如何规划您的访问模型

在配置紧急访问之前,请为访问模型的工作方式制定计划。使用以下过程来创建此计划。

  1. 确定在 IAM Identity Center 中断期间紧急操作员访问至关重要的 Amazon Web Services 账户。例如,您的生产帐户可能是必需的,但您的开发和测试帐户可能不是必需的。

  2. 对于该帐户集合,确定您的帐户中需要的特定关键角色。在这些帐户中,在定义角色可以做什么时保持一致。这简化了您在紧急访问账户中创建跨账户角色的工作。我们建议您从这些帐户中的两个不同角色开始:只读 (RO) 和操作 (Ops)。如果需要,您可以创建更多角色并将这些角色映射到设置中更独特的紧急访问用户组。

  3. 在 IdP 中识别并创建紧急访问组。组成员是您向其委派紧急访问角色访问权限的用户。

  4. 定义这些组可以在紧急访问帐户中承担哪些角色。为此,请在 IdP 中定义规则,以生成列出该组可以访问的角色的声明。然后,这些组可以承担您在紧急访问帐户中的“只读”或“操作”角色。通过这些角色,他们可以在您的工作负载帐户中担任相应的角色。

如何设计紧急角色、帐户和组映射

下图显示如何将紧急访问组映射到紧急访问帐户中的角色。该图还显示了跨账户角色信任关系,这些关系使紧急访问账户角色能够访问工作负载账户中的相应角色。我们建议您的应急计划设计使用这些映射作为起点。

用于将紧急访问组映射到紧急访问账户中的角色的 IAM Identity Center 工作流程。

如何创建紧急访问配置

使用以下映射表创建紧急访问配置。此表反映了一个计划,其中包括工作负载帐户中的两个角色:只读 (RO) 和操作 (Ops) 以及相应的信任策略和权限策略。信任策略使紧急访问帐户角色能够访问各个工作负载帐户角色。各个工作负载帐户角色还具有关于角色可以在帐户中执行的操作的权限策略。权限策略可以是 Amazon 托管策略客户托管策略

账户 要创建的角色 信任策略 权限策略
Account 1 EmergencyAccess_RO EmergencyAccess_Role1_RO

arn:aws:iam::aws:policy/ReadOnlyAccess

Account 1 EmergencyAccess_Ops EmergencyAccess_Role1_Ops

arn:aws:iam::aws:policy/job-function/SystemAdministrator

Account 2 EmergencyAccess_RO EmergencyAccess_Role2_RO

arn: aws: iam:: aws: policy/ ReadOnlyAccess

Account 2 EmergencyAccess_Ops EmergencyAccess_Role2_Ops

arn:aws:iam::aws:policy/job-function/SystemAdministrator

紧急访问帐户

EmergencyAccess_Role1_RO

EmergencyAccess_Role1_Ops

EmergencyAccess_Role2_RO

EmergencyAccess_Role2_Ops

IdP

AssumeRole 用于账户中的角色资源

在此映射计划中,紧急访问帐户包含两个只读角色和两个操作角色。这些角色信任您的 IdP,通过在断言中传递角色名称来验证和授权您选择的组访问角色。工作负载 Account 1 和 Account 2 中有对应的只读和操作角色。对于工作负载帐户 1,EmergencyAccess_RO 角色信任驻留在紧急访问帐户中的 EmergencyAccess_Role1_RO 角色。该表指定了工作负载帐户只读和操作角色与相应的紧急访问角色之间的类似信任模式。

应急准备工作

要准备紧急访问配置,我们建议您在紧急情况发生之前执行以下任务。

  1. 在您的 IdP 中设置直接 IAM 联合身份验证应用程序。有关更多信息,请参阅 在 Okta 中一次性设置直接 IAM 联合身份验证应用程序

  2. 在事件期间可以访问的紧急访问帐户中创建 IdP 连接。

  3. 如上面的映射表中所述,在紧急访问帐户中创建紧急访问角色。

  4. 在每个工作负载帐户中创建具有信任和权限策略的临时操作角色。

  5. 在 IdP 中创建临时操作组。组名称将取决于临时操作角色的名称。

  6. 测试直接 IAM 联合身份验证。

  7. 禁用 IdP 中的 IdP 联合身份验证应用程序以防止经常使用。

紧急故障转移流程

当 IAM Identity Center 实例不可用并且您确定必须提供对 Amazon 管理控制台的紧急访问权限时,我们建议您执行以下故障转移流程。

  1. IdP 管理员在您的 IdP 中启用直接 IAM 联合身份验证应用程序。

  2. 用户通过现有机制请求访问临时操作组,例如电子邮件请求、Slack 通道或其他形式的通信。

  3. 添加到紧急访问组的用户登录 IdP,选择紧急访问帐户,然后用户选择要在紧急访问帐户中使用的角色。通过这些角色,他们可以在与紧急账户角色具有跨账户信任的相应工作负载账户中担任角色。

恢复正常运营

检查 Amazon Health Dashboard 以确认 IAM Identity Center 服务的运行状况何时恢复。要恢复正常操作,请执行以下步骤。

  1. 当 IAM Identity Center 服务的状态图标指示该服务运行正常后,登录 IAM Identity Center。

  2. 如果您可以成功登录 IAM Identity Center,请告知紧急访问用户 IAM Identity Center 可用。指示这些用户注销并使用 Amazon Web Services 访问门户重新登录 IAM Identity Center。

  3. 所有紧急访问用户注销后,在 IdP 中禁用 IdP 联合身份验证应用程序。我们建议您在下班后执行此任务。

  4. 从 IdP 中的紧急访问组中删除所有用户。

您的紧急访问角色基础设施仍作为备份访问计划保留,但现已禁用。

在 Okta 中一次性设置直接 IAM 联合身份验证应用程序

  1. 以具有管理权限的用户身份登录您的 Okta 帐户。

  2. 在 Okta 管理控制台中的应用程序下,选择应用程序

  3. 选择浏览应用程序目录。搜索并选择 Amazon 帐户联合身份验证。然后选择添加集成

  4. 按照如何为 Amazon 账户联合身份验证配置 SAML 2.0 中的步骤,设置与 Amazon 的进行直接 IAM 联合身份验证。

  5. 登录选项选项卡上,选择 SAML 2.0 并输入组筛选条件角色值模式设置。用户目录的组名称取决于您配置的过滤条件。

    两个不同的选项显示您的 accountid 和 role 在组筛选条件或角色值模式中的位置。

    在上图中,role 变量适用于您的紧急访问帐户中的紧急操作角色。例如,如果您在 Amazon Web Services 账户 123456789012 中创建了 EmergencyAccess_Role1_RO 角色(如映射表中所述),并且您的组过滤设置如上图所示配置,则您的组名称应为 aws#EmergencyAccess_Role1_RO#123456789012

  6. 在您的目录(例如,Active Directory 中的目录)中,创建紧急访问组并指定目录名称(例如, aws#EmergencyAccess_Role1_RO#123456789012)。使用现有的预置机制将您的用户分配到该组。

  7. 在紧急访问帐户中,配置自定义信任策略,该策略提供在中断期间承担紧急访问角色所需的权限。以下是附加到 EmergencyAccess_Role1_RO 角色的自定义信任策略的示例语句。示例请参见 如何设计紧急角色、帐户和组映射 下图中的紧急账户。

    { "Version": "2012-10-17", "Statement": [ { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/Okta" }, "Action":[ "sts:AssumeRoleWithSAML", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition":{ "StringEquals":{ "SAML:aud":"https:~/~/signin.aws.amazon.com/saml" } } } ] }
  8. 以下是附加到 EmergencyAccess_Role1_RO 角色的权限策略的示例语句。示例请参见 如何设计紧急角色、帐户和组映射 下图中的紧急账户。

    { "Version": "2012-10-17", "Statement":[ { "Effect":"Allow", "Action":"sts:AssumeRole", "Resource":[ "arn:aws:iam::<account 1>:role/EmergencyAccess_RO", "arn:aws:iam::<account 2>:role/EmergencyAccess_RO" ] } ] }
  9. 在工作负载帐户上,配置自定义信任策略。以下是附加到 EmergencyAccess_RO 角色的信任策略的示例语句。在本例中,帐户 123456789012 是紧急访问帐户。有关说明,请参阅 如何设计紧急角色、帐户和组映射 下图表中的工作负载帐户。

    { "Version": "2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::123456789012:root" }, "Action":"sts:AssumeRole" } ] }
    注意

    大多数都 IdPs 允许您在需要之前停用应用程序集成。我们建议您在 IdP 中保持直接 IAM 联合身份验证应用程序处于停用状态,直到需要紧急访问为止。