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

# 用于过渡到多账户架构的身份管理和访问控制
<a name="identity-management"></a>

过渡到多账户架构的第一步是在组织内设置新的账户结构。然后，您可以添加用户并配置他们对账户的访问权限。本节介绍管理用户访问多 AWS 账户的权限的方法。

**Topics**
+ [设置组织](set-up-organization.md)
+ [创建登录区](create-landing-zone.md)
+ [添加组织单位](add-organizational-units.md)
+ [添加初始用户](add-initial-users.md)
+ [管理成员账户](manage-member-accounts.md)

# 设置组织
<a name="set-up-organization"></a>

如果您有多个帐户 AWS 账户，则可以通过中的组织在逻辑上管理这些帐户[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)。中的*账户* AWS Organizations 是一种标准 AWS 账户 ，其中包含您的 AWS 资源以及可以访问这些资源的身份。*组织*是整合您的实体， AWS 账户 以便您可以将其作为一个单位进行管理。

当您使用账户创建组织时，该账户将变为*管理账户*（也称为*付款人账户*或*根账户*）代表该组织。一个组织只能有一个管理账户。当您 AWS 账户 向组织中添加其他帐户时，他们将成为*成员帐户*。

**注意**  
每个用户 AWS 账户 还有一个名为 *root 用户的*身份。您可以使用在创建账户时使用的电子邮件地址和密码以根用户身份登录。但是，我们强烈建议您不要使用根用户来执行日常任务，即使是管理任务。有关更多信息，请参阅 [AWS 账户 根用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)。  
我们还建议[集中成员账户的根访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)，并从组织中的成员账户中移除根用户证书。

您可以在树状分层结构中组织帐户，该结构由组织根帐户、组织单位 (OUs) 和成员帐户组成。*根*是您组织中所有账户的父容器。一个*组织单位*（OU）是[根](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#root)中[账户](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)的一个容器。OU 可以包含其他账户 OUs 或成员账户。一个 OU 只有一个父级，而每个账户都只能是一个 OU 的成员。有关更多信息，请参阅[术语和概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)（AWS Organizations 文档）。

[服务控制策略 (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 指定用户和角色可以使用的服务和操作。 SCPs 与 AWS Identity and Access Management (IAM) 权限策略类似，不同之处在于它们不授予权限。而是 SCPs 定义最大权限。当您将策略附加到层次结构中的一个节点时，该策略将应用于该节点中的所有 OUs 和账户。例如，如果您将策略应用于根，则该策略将应用于组织中的所有[OUs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#organizationalunit)和[账户](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html#account)；如果您将策略应用于 OU，则该策略仅适用于目标 OU 中的 OUs 和账户。

[资源控制策略 (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) 可对组织中资源的最大可用权限进行集中控制。 RCPs 帮助您确保账户中的资源符合组织的访问控制准则。

您可以使用 AWS Organizations 控制台集中查看和管理组织内的所有账户。使用组织的好处之一是，您可以收到一份整合账单，其中显示与管理账户和成员账户相关的所有费用。有关更多信息，请参阅[整合账单](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)（AWS Organizations 文档）。

## 最佳实践
<a name="organization-best-practices"></a>
+ 不要使用现有的组织 AWS 账户 来创建组织。用一个新账户开始，该账户将成为组织的管理账户。特权操作可以在组织的管理账户内执行 SCPs ，但 RCPs 不适用于管理账户。因此，管理账户中包含的云资源和数据应仅限于必须在管理账户中管理的云资源和数据。
+ 将管理账户的访问权限限制为只有那些需要配置新账号 AWS 账户 并管理组织的人员。
+  SCPs 用于定义根账户、组织单位账户和成员账户的最大权限。 SCPs 不能直接应用于管理账户。
+  RCPs 用于定义成员账户中资源的最大权限。 RCPs不能直接应用于管理账户。
+ 遵守 AWS Organizations（AWS Organizations 文档）[的最佳实践](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html)。

# 创建登录区
<a name="create-landing-zone"></a>

l *anding zon* e 是一个架构良好的多账户 AWS 环境，您可以从中开始部署工作负载和应用程序。它为开始使用多账户架构、身份和访问管理、治理、数据安全、网络设计和日志记录提供了基准。[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 是一项通过提供自动化防护机制来简化多账户环境维护和治理的服务。通常，您可以配置一个用于管理所有环境的 AWS Control Tower 着陆区 AWS 区域。 AWS Control Tower 通过协调账户 AWS 服务 中的其他人来工作。有关更多信息，请参阅[设置着陆区时会发生什么](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup)（AWS Control Tower 文档）。

使用设置 landing zone 时 AWS Control Tower，可以识别出三个共享账户：管理账户、日志存档账户和审核账户。有关更多信息，请参阅[什么是共享账户](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#what-shared)（AWS Control Tower 文档）。对于管理账户，您必须使用未托管任何工作负载的现有账户来设置登录区。对于日志存档和审计帐户，您可以选择重复使用现有帐户 AWS 账户， AWS Control Tower 也可以为您创建它们。

有关如何设置 AWS Control Tower 着陆区的说明，请参阅[入门](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html)（AWS Control Tower 文档）。

## 最佳实践
<a name="landing-zone-best-practices"></a>
+ 遵循[多账户策略设计原则](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.html)中的最佳实践（AWS 白皮书）。
+ 遵守[AWS Control Tower 管理员最佳实践](https://docs.aws.amazon.com/controltower/latest/userguide/best-practices.html)（AWS Control Tower 文档）。
+ 在托管大部分工作负载 AWS 区域 的 landing zone 中创建。
**重要**  
如果您在部署着陆区后决定更改此区域，则需要的帮助 AWS 支持，并且必须停用该着陆区。不建议采用这种做法。
+ 在确定哪些区域 AWS Control Tower 将进行管理时，请仅选择您希望立即部署工作负载的区域。您可以更改这些区域，也可以稍后添加更多区域。如果 AWS Control Tower 管理一个地区，它将把侦探护栏部署到该区域，因为。[AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ 确定哪些区域 AWS Control Tower 将进行管理后，拒绝访问所有未受管理的区域。这有助于确保您的工作负载和开发人员只能使用经过批准的 AWS 区域。这是作为组织的服务控制策略（SCP）来实现。有关更多信息，请参阅[配置 AWS 区域 拒绝控件](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html)（AWS Control Tower 文档）。
+ 在中设置 landing zone 时 AWS Control Tower，我们建议您重命名以下内容 OUs 和帐户：
  + 我们建议重命名**安全** OU 为 **Security\$1Prod**，表示此 OU 将用于与生产安全相关的 AWS 账户。
  + 我们建议您允许再创建一个 OU AWS Control Tower ，然后将其从 **Sandbox 重命名为 Workdlo** ads **。**在下一节中，您将在 Workloads OU OUs 中创建其他内容，用于组织**工作负载** OU AWS 账户。
  + 我们建议您将集中式日志 AWS 账户 从**日志存档**重命名为**log-archive-prod**。
  + **我们建议您将审计账户从 “审计” 重命名为**security-tooling-prod**。**
+ 为了帮助防止欺诈， AWS 要求在将其添加到 l AWS Control Tower anding zone 之前 AWS 账户 有使用记录。如果您使用的是 AWS 账户 没有任何使用历史记录的新账户，则可以在新账户中启动不在免费套餐中的 AWS 亚马逊弹性计算云 (Amazon EC2) 实例。让实例运行几分钟，然后将其终止。

# 添加组织单位
<a name="add-organizational-units"></a>

建立适当的组织结构对于设置多账户环境至关重要。由于您使用服务控制策略 (SCPs) 来定义 OU 及其中的账户的最大权限，因此从管理、权限和财务报告的角度来看，您的组织结构必须合乎逻辑。有关组织结构（包括组织单位OUs）的更多信息，请参阅[术语和概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)（AWS Organizations 文档）。

在本节中，您将通过创建嵌套来自定义 landing zone OUs ，以帮助您细分和构建环境，例如生产环境和非生产环境。这些推荐的最佳做法旨在细分您的登录区，将生产资源与非生产资源分开，将基础设施与工作负载分开。

有关如何创建的更多信息 OUs，请参阅[管理组织单位](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)（AWS Organizations 文档）。

## 最佳实践
<a name="ou-best-practices"></a>
+ 在您创建**的工作负载** OU 中[创建登录区](create-landing-zone.md)，创建以下嵌套内容 OUs：
  + **Prod**：将此 OU 用于存储和访问生产数据的 AWS 账户 ，包括客户数据。
  + **NonProd**— 将此 OU 用于 AWS 账户 存储非生产数据，例如开发、暂存或测试环境

在组织根账户下，创建一个 **Infrastructure\$1Prod** OU。使用此 OU 托管集中式网络账户。

# 添加初始用户
<a name="add-initial-users"></a>

有两种方法向用户授予对 AWS 账户的访问权限：
+ IAM 身份，例如：用户、组和角色
+ 身份联合，例如使用 AWS IAM Identity Center

在小型公司和单账户环境中，管理员通常会在有新人加入公司时创建 IAM 用户。与 IAM 用户关联的访问密钥和私密密钥凭证称为*长期凭证*，因为它们不会过期。但是，这并不是推荐的安全最佳实践，因为如果攻击者破解了这些凭证，则您必须为用户生成一组新的凭证。另一种访问方法 AWS 账户 是通过 [IAM 角色](https://aws.amazon.com/blogs/startups/how-setting-up-iam-users-and-iam-roles-can-help-keep-your-startup-secure/)进行访问。您也可以使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)（AWS STS）临时请求*短期凭证*，它将在一段可配置的时间后过期。

您可以 AWS 账户 通过 [IAM 身份中心](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)管理人们对您的访问权限。您可以为每位员工或承包商创建个人用户账户，他们可以管理自己的密码和多重身份验证（MFA）解决方案，也可以对他们进行分组以管理访问权限。配置 MFA 时，您可以使用软件令牌，例如身份验证器应用程序，也可以使用硬件令牌，例如设备。 YubiKey 

IAM 身份中心还支持来自外部身份提供商 (IdPs) 的联合，例如 Okta JumpCloud、和 Ping Identity。有关更多信息，请参阅[支持的身份提供者](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html)（IAM Identity Center documentation 文档）。通过与外部 IdP 联合，您可以跨应用程序管理用户身份验证，然后使用 IAM Identity Center 向特定应用程序授予访问权限。 AWS 账户

## 最佳实践
<a name="users-best-practices"></a>
+ 遵循配置用户访问权限的[安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)（IAM 文档）。
+ 按组而不是个人用户管理账户访问权限。在 IAM Identity Center 中，创建代表您的每项业务职能的新组。例如，您可以为工程、财务、销售和产品管理等部门创建组。
+ 通常，将需要访问所有 AWS 账户 的人（通常只有只读访问权限）以及需要访问单个 AWS 账户的人分开来定义组。我们建议您对群组使用以下命名约定，以便于识别与群组关联的 AWS 账户 和权限。

  `<prefix>-<account name>-<permission set>`
+ 例如，对于组 `AWS-A-dev-nonprod-DeveloperAccess`，`AWS-A` 是一个前缀，表示对单个账户的访问权限，`dev-nonprod` 是账户的名称，`DeveloperAccess` 是分配给该组的权限集。对于组 `AWS-O-BillingAccess`，`AWS-O` 前缀表示具有对整个组织的访问权限，`BillingAccess` 表示该组的权限集。在本例中，由于组有权访问整个组织，因此组名中没有显示账户名。
+ 如果您将 IAM Identity Center 与外部基于 SAML 的 IdP 一起使用，并且希望要求 MFA，则可以使用基于属性的访问权限控制（ABAC）将身份验证方法从 IdP 传递到 IAM Identity Center。这些属性通过 SAML 断言发送。有关更多信息，请参阅[启用和配置访问控制的属性](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html)（IAM Identity Center 文档）。

  许多公司 IdPs，例如微软 Azure Active Directory 和 Okta，可以使用 SAML 断言中的身份验证方法参考 (`amr`) 声明将用户的 MFA 状态传递给 IAM 身份中心。用于断言 MFA 状态的声明及其格式因 IdP 而异。有关更多信息，请参阅您的 IdP 的相应文档。

  然后，您可以在 IAM Identity Center 中创建权限集策略来确定谁可以访问您的 AWS 资源。当您启用 ABAC 并指定属性时，IAM Identity Center 会将经过身份验证的用户的属性值传递到 IAM，以便在策略评估中使用。有关更多信息，请参阅[为 ABAC 创建权限策略](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-policies.html)（IAM Identity Center 文档）。如以下示例所示，您可以使用 `aws:PrincipalTag` 条件键为 MFA 创建访问控制规则。

  ```
  "Condition": {
    "StringLike": { "aws:PrincipalTag/amr": "mfa" }
  }
  ```

# 管理成员账户
<a name="manage-member-accounts"></a>

在本节中，您需要邀请您先前存在的账户加入组织，并开始在组织中创建新账户。此过程的一个重要部分是定义用于确定是否需要配置新账户的标准。

**Topics**
+ [邀请您先前存在的账户](#invite-account)
+ [在中自定义 VPC 设置 AWS Control Tower](#customize-vpc-settings)
+ [定义范围界定标准](#define-scoping-criteria)

## 邀请您先前存在的账户
<a name="invite-account"></a>

在内部 AWS Organizations，您可以邀请贵公司先前存在的账户加入您的新组织。只有组织中的管理账户可以邀请其他账户加入。当受邀账户的管理员接受时，该账户会立即加入组织，组织的管理账户将承担新成员账户产生的所有费用。有关更多信息，请参阅[邀请 AWS 账户 加入您的组织](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html)和[接受或拒绝来自组织的邀请](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_invites.html#orgs_manage_accounts_accept-decline-invite)（AWS Organizations 文档）。

**注意**  
只有当某个账户当前不在其他组织中时，您才能邀请该账户加入组织。如果某个账户是现有组织的成员，则您必须将其从组织中删除。如果某个账户是错误创建的另一个组织的管理账户，则必须删除该组织。

**重要**  
如果您需要访问先前存在的账户中的任何历史成本或使用量信息，则可以使用 AWS 成本和使用情况报告 将这些信息导出到亚马逊简单存储服务 (Amazon S3) 存储桶。请在接受加入组织的邀请之前执行此操作。在账户加入组织后，您将无法访问该账户的历史数据。有关更多信息，请参阅[为成本和使用情况报告设置 Amazon S3 存储桶](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html)（AWS 成本和使用情况报告 文档）。

*最佳实践*
+ 我们建议您将先前存在的账户（可能包含生产工作负载）添加到您在 [添加组织单位](add-organizational-units.md) 中创建的**工作负载** > **Prod** 组织单位。
+ 默认情况下，组织的管理账户对受邀加入该组织的成员账户没有管理访问权限。如果您希望管理账户拥有管理控制权，则必须在成员账户中创建 **OrganizationAccountAccessRole**IAM 角色并向管理账户授予代入该角色的权限。有关更多信息，请参阅[在受邀成员账户 OrganizationAccountAccessRole 中创建](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_create-cross-account-role)（AWS Organizations 文档）。
+ 对于您邀请加入该组织的先前存在的账户，请查看[成员账户的最佳实践](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)（AWS Organizations 文档），并确认该账户符合这些建议。

## 在中自定义 VPC 设置 AWS Control Tower
<a name="customize-vpc-settings"></a>

我们建议您 AWS 账户 通过中的 Account F [actory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) 进行新配置 AWS Control Tower。通过使用 Account Factory，您可以在创建账户后立即使用与亚马逊的 AWS Control Tower 集成 EventBridge 来配置新 AWS 账户 资源。

当您设置新的虚拟私有云 (VPC) 时 AWS 账户，系统会自动配置[默认的虚拟私有云 (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html)。但是，当您通过 Account Factory 设置新账户时， AWS Control Tower 会自动配置额外的 VPC。有关更多信息，请参阅[AWS Control Tower 和概述 VPCs](https://docs.aws.amazon.com/controltower/latest/userguide/vpc-concepts.html)（AWS Control Tower 文档）。这意味着，默认情况下， AWS Control Tower 每个新账户 VPCs 中都会预置两个默认值。

公司通常希望加强对账户 VPCs 内部的控制权。许多人更喜欢使用其他服务 AWS CloudFormation，例如Hashicorp Terraform或Pulumi，来设置和管理他们的。 VPCs您应自定义 Account Factory 设置，以防止创建由 AWS Control Tower配置的其他 VPC。有关说明，请参阅[配置 Amazon VPC 设置](https://docs.aws.amazon.com/controltower/latest/userguide/configuring-account-factory-with-VPC-settings.html)（AWS Control Tower 文档），然后应用以下设置：

1. 禁用**可通过互联网访问的子网**选项。

1. 对于**私有子网的最大数量**，选择 **0**。

1. 在**创建 VPC 的区域**，清除所有区域。

1. 在**可用区**，选择 **3**。

*最佳实践*
+ 删除每个新账户中自动配置的默认 VPC。这可以防止用户在未明确创建专用 VPC 的情况下在账户中启动公有 EC2 实例。有关更多信息，请参阅[删除默认子网和默认 VPC](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#deleting-default-vpc)（Amazon Virtual Private Cloud 文档）。您也可以配置[适用于 Terraform 的AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)（AFT），自动删除新创建账户中的默认 VPC。
+ 在 “**工作负载**” > “组织部门” 中配置一个 AWS 账户 名为 d **ev-nonprod** 的新版本。**NonProd**在您的开发环境中使用此账户。有关说明，请参阅 Provisi [on Account Factory 账户](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html)AWS Control Tower 和 AWS Service Catalog（文档）。

## 定义范围界定标准
<a name="define-scoping-criteria"></a>

您需要选择贵公司在决定是否配置新产品时将使用的标准 AWS 账户。您可以决定为每个业务部门配置账户，也可以决定根据环境（例如生产、测试或 QA）配置账户。每家公司对自己的规模或规模都有自己的要求。 AWS 账户 通常，在决定如何调整账户规模时，您需要评估以下三个因素：
+ **平衡服务配***额 — 服务配额*是其中每 AWS 服务 项资源、操作和项目数量的最大值 AWS 账户。如果许多工作负载共享同一个账户，而一个工作负载占用了大部分或全部服务限额，则可能会对同一账户中的另一个工作负载产生负面影响。如果是这样，您可能需要将这些工作负载分到不同的账户中。有关更多信息，请参阅 [AWS 服务 限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)（AWS 一般参考）。
+ **成本报告**：将工作负载隔离到单独的账户中，方便您在成本和使用情况报告中查看账户级别的成本。当为多个工作负载使用同一个账户时，可以使用标签来帮助管理和识别资源。有关标记的更多信息，请参阅为[AWS 资源添加标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) ()AWS 一般参考。
+ **控制访问权限**：当工作负载共享账户时，您需要考虑如何配置 IAM policy，以限制对账户资源的访问权限，确保用户无法访问不需要的工作负载。作为替代方案，您可以在 IAM Identity Center 中使用多个账户和[权限集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)，管理对个人账户的访问权限。

*最佳实践*
+ 遵循您的 landing [zone AWS 多账户策略的最佳 AWS Control Tower 实](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)践（AWS Control Tower 文档）。
+ 制定有效的标记策略，帮助您识别和管理 AWS 资源。您可使用标签，按用途、业务部门、环境或其他标准对资源进行分类。有关更多信息，请参阅[标记的最佳实践](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html#tag-best-practices)（AWS 一般参考 文档）。
+ 不要让账户负载过多的工作负载。如果工作负载的需求超过服务限额，则可能导致出现性能问题。您可以将相互竞争的工作负载分成不同的工作负载， AWS 账户 也可以申请增加服务配额。有关更多信息，请参阅[请求增加限额](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)（《服务限额》文档）。