本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 轉換為多帳戶架構的身分管理與存取控制
<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 帳戶 也有稱為*根使用者的*單一身分。可以使用用來建立帳戶的電子郵件地址和密碼，以根使用者的身分登入。不過，強烈建議您不要以根使用者身分處理日常任務，即使是管理任務。如需詳細資訊，請參閱 [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)，並從組織中的成員帳戶移除根使用者憑證。

在階層式樹狀結構中組織帳戶，該結構包含組織根、組織單位 (OU) 以及成員帳戶。*根*是組織中所有帳戶的父級容器。*組織單位* (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 可以包含其他 OU 或成員帳戶。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) 許可政策，但不會授予許可。相反，SCP 會定義最大許可。當您將政策附接至階層中的其中一個節點時，它會套用至該節點內的所有 OU 和帳戶。例如，如果將政策套用至根，則它將套用至組織中的所有 [OU](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 以及目標 OU 中的帳戶。

[資源控制政策 (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 帳戶 和管理組織的個人才能存取管理帳戶。
+ 使用 SCP 來定義根、組織單位和成員帳戶的最大許可。SCP 無法直接套用至管理帳戶。
+ 使用 RCPs 定義成員帳戶中資源的最大許可。RCPs無法直接套用至管理帳戶。
+ 遵守 (AWS Organizations 文件） [的最佳實務 AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html)。

# 建立登陸區域
<a name="create-landing-zone"></a>

*登陸區域*是架構良好的多帳戶 AWS 環境，是您可以從中部署工作負載和應用程式的起點。它會提供一種基準，以便開始使用多帳戶架構、身分管理和存取管理、控管、資料安全、網路設計和日誌。[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 是一項服務，它透過提供自動化防護機制來簡化多帳戶環境的維護和控管。一般而言，您會佈建單一 AWS Control Tower 登陸區域，透過在您的 AWS 服務 帳戶中協調其他 來管理您在 all AWS 區域. AWS Control Tower works 的環境。如需詳細資訊，請參閱[設定登陸區域 （文件） 時會發生的情況](https://docs.aws.amazon.com/controltower/latest/userguide/how-control-tower-works.html#how-it-works-setup)。AWS Control Tower 

當您使用 設定登陸區域時 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 區域 託管大部分工作負載的 中建立登陸區域。
**重要**  
如果您決定在部署登陸區域之後變更此區域，則需要 的協助 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 文件）。
+ 在 中設定登陸區域時 AWS Control Tower，建議您重新命名下列 OUs和帳戶：
  + 建議您將 **Security** OU 重新命名為 **Security\$1Prod**，表明此 OU 將用於生產安全相關 AWS 帳戶。
  + 我們建議您允許 AWS Control Tower 建立額外的 OU，然後將其從**沙盒**重新命名為**工作負載**。在下一節中，您可以在**工作負載** OU 中建立其他 OU，用來組織您的 AWS 帳戶。
  + 建議您將 **Log Archive** AWS 帳戶 的集中式記錄重新命名為 **log-archive-prod**。
  + 建議將稽核帳戶從**稽核**重新命名為為 **security-tooling-prod**。
+ 為了協助防止詐騙， AWS 需要 AWS 帳戶 有使用歷史記錄，才能將其新增至 AWS Control Tower 登陸區域。如果您使用的是 AWS 帳戶 沒有任何使用歷史記錄的新 ，您可以在新帳戶中啟動不在 AWS 免費方案中的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。讓執行個體執行幾分鐘，然後將其終止。

# 新增組織單位
<a name="add-organizational-units"></a>

建立適當的組織結構對於設定多帳戶環境至關重要。因為您使用服務控制政策 (SCP) 來定義 OU 及其中帳戶的最大許可，因此從管理、許可和財務報告的角度來看，您的組織結構必須是合乎邏輯的。如需組織結構的詳細資訊，包括組織單位 OUs)，請參閱[術語和概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) (AWS Organizations 文件）。

在本節中，可以透過建立巢狀 OU 來自訂登陸區域，以協助您對環境進行分割和結構化，例如生產和非生產。這些建議的最佳實務設計用來將登陸區域劃分為生產資源和非生產資源，並將基礎設施與工作負載分開。

如需如何建立 OUs 的詳細資訊，請參閱[管理組織單位](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html) (AWS Organizations 文件）。

## 最佳實務
<a name="ou-best-practices"></a>
+ 在您在 [建立登陸區域](create-landing-zone.md) 中建立的**工作負載**中，建立下列巢狀 OU：
  + **Prod** – 針對儲存和存取生產資料的 AWS 帳戶 使用此 OU，包括客戶資料。
  + **NonProd** – 針對儲存非生產資料的 AWS 帳戶 使用此 OU，例如開發、預備或測試環境

在組織根下，建立一個 **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) 暫時請求*短期憑證*，它會在可設定的時間後過期。

您可以透過 [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) AWS 帳戶 管理人員存取您的 。您可以為每位員工或承包商建立個別使用者帳戶，他們可以管理自己的密碼和多重要素驗證 (MFA) 解決方案，也可以將他們分組以管理存取權。設定 MFA 時，可以使用軟體權杖，例如驗證器應用程式，也可以使用硬體權杖，例如 YubiKey 裝置。

IAM Identity Center 也支援來自外部身分提供者 (IdP) 的聯合，例如 Okta、JumpCloud 和 Ping Identity。如需詳細資訊，請參閱[支援的身分提供者](https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html) (IAM Identity Center 文件)。透過與外部 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 文件)。

  諸如 Microsoft Azure Active Directory 和 Okta 等許多 IdP 可使用 SAML 宣告中的 Authentication Method Reference (`amr`) 聲明將使用者的 MFA 狀態傳遞至 IAM Identity Center。用來宣告 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 Cost and Usage Report 將該資訊匯出至 Amazon Simple Storage Service (Amazon S3) 儲存貯體。在接受邀請加入組織之前執行此操作。當帳戶加入組織時，您將無法存取該帳戶的此歷史資料。如需詳細資訊，請參閱[設定成本和用量報告的 Amazon S3 儲存貯體](https://docs.aws.amazon.com/cur/latest/userguide/cur-s3.html) (AWS Cost and Usage Report 文件)。

*最佳實務*
+ 建議您將先前存在的帳戶 (它可能包含生產工作負載) 新增至您在 [新增組織單位](add-organizational-units.md) 中建立的**工作負載** > **生產**組織單位。
+ 依預設，組織的管理帳戶沒有對受邀加入組織之成員帳戶的管理存取權。如果您希望管理帳戶擁有管理控制權，則必須在成員帳戶中建立 **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 Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) 佈建新的 AWS Control Tower。透過使用 Account Factory，您可以使用與 Amazon EventBridge 的 AWS Control Tower 整合，在帳戶建立 AWS 帳戶 後立即在新的 中佈建資源。

當您設定新的 時 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 會在每個新帳戶中佈建兩個預設 VPC。

公司通常希望對其帳戶中的 VPC 進行更多控制。許多人偏好使用其他 服務 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 文件)。您也可以設定 [AWS Control Tower Account Factory for Terraform](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html) (AFT) 以自動刪除新建立帳戶中的預設 VPC。
+ 在**工作負載** > NonProd 組織單位中佈建 AWS 帳戶 稱為 dev-nonprod 的新 。 **** **NonProd** 在開發環境中使用此帳戶。如需說明，請參閱[使用 佈建帳戶工廠帳戶 AWS Service Catalog](https://docs.aws.amazon.com/controltower/latest/userguide/provision-as-end-user.html) (AWS Control Tower 文件）。

## 定義範圍標準
<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 政策以限制對帳戶資源的存取，以便使用者無法存取不需要的工作負載。作為替代方案，您可以在 IAM Identity Center 中使用多個帳戶和[許可集](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)來管理對個別帳戶的存取。

*最佳實務*
+ 遵守[AWSAWS 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) (Service Quotas 文件)。