设置紧急访问权限 AWS Management Console

IAMIdentity Center 基于高度可用的 AWS 基础架构构建，并使用可用区架构来消除单点故障。为了在不太可能发生的IAM身份中心或 AWS 区域 中断事件中断时提供额外的保护，我们建议您设置一个可用于提供临时访问权限的配置 AWS Management Console。

概述

AWS 使您能够：

• 将您的第三方 IdP 连接到 Identity C IAM enter。

• 使用基于 SAML2. 0 的联合身份验证将您的第三方 IdP 连接到 AWS 账户 个人。

如果您使用 IAM Identity Center，则可以使用这些功能来创建以下各节中描述的紧急访问配置。此配置使您可以使用 Ident IAM ity Center 作为 AWS 账户 访问机制。如果 Ident IAM ity Center 中断，您的紧急操作用户可以使用与访问其帐户相同的凭据登录直 AWS Management Console 通联合。当 Ident IAM ity Center 不可用，但IAM数据平面和您的外部身份提供商 (IdP) 可用时，此配置起作用。

重要

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

紧急访问配置汇总

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

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

2. 使用基于 SAML2. 0 的联合身份验证将您的 IdP 连接到紧急行动账户。

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

4. 将您在紧急行动账户中创建的IAM角色的工作负载账户的访问权限委托给他们。要授权访问您的紧急操作帐户，请在您的 IdP 中创建一个没有成员的紧急操作组。

5. 通过在您的 IdP 中创建一条规则，启用 SAML2.0 联合访问权限，使您的 IdP 中的紧急行动组能够使用紧急行动角色。 AWS Management Console

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

如何设计关键操作角色

通过这种设计，您可以配置一个 AWS 账户 在其中进行联合的单个IAM，以便用户可以扮演关键操作角色。关键操作角色具有信任策略，使用户能够在工作负载帐户中担任相应的角色。工作负载帐户中的角色提供用户执行基本工作所需的权限。

下图提供了设计概述。

如何规划您的访问模型

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

1. 确定在IAM身份中心中断期间，需要紧急操作员访问 AWS 账户 的地方。例如，您的生产帐户可能是必需的，但您的开发和测试帐户可能不是必需的。

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

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

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

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

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

如何创建紧急访问配置

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

帐户	要创建的角色	信任策略	权限策略
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联合应用程序。有关更多信息，请参阅 在中一次性设置直接IAM联合应用程序 Okta。

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

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

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

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

6. 测试直接IAM联合。

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

紧急故障转移流程

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

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

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

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

恢复正常运营

检查 AWS Health Das hboard 以确认IAM身份中心服务的运行状况何时恢复。要恢复正常操作，请执行以下步骤。

1. 在 Ident IAM ity Center 服务的状态图标表明服务运行正常后，登录IAM身份中心。

2. 如果您可以成功登录IAM身份中心，请告知紧急访问用户IAM身份中心可用。指示这些用户注销并使用 AWS 访问门户重新登录 Ident IAM ity Center。

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

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

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

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

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

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

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

4. 按照如何为 AWS 账户IAM联合配置 SAML 2.0 中的步骤设置直接联合 AWS 。

5. 在 “登录选项” 选项卡上，选择 SAML 2.0，然后输入群组筛选器和角色值模式设置。用户目录的组名称取决于您配置的筛选条件。

   

   在上图中，role 变量适用于您的紧急访问帐户中的紧急操作角色。例如，如果您在中创建EmergencyAccess_Role1_RO角色（如映射表中所述） AWS 账户 123456789012，并且您的群组筛选器设置配置如上图所示，则您的群组名称应为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联合应用程序，直到需要进行紧急访问为止。