

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

# AWS Control Tower 管理員的最佳實務
<a name="best-practices"></a>

本主題主要適用於管理帳戶管理員。

管理帳戶管理員負責解釋 AWS Control Tower 控制阻止其成員帳戶管理員執行的一些任務。本主題說明一些傳輸此知識的最佳實務和程序，並提供其他秘訣，讓您有效率地設定和維護 AWS Control Tower 環境。

## 向使用者說明存取權
<a name="explaining-users"></a>

AWS Control Tower 主控台僅適用於具有管理帳戶管理員許可的使用者。只有這些使用者可以在您的登陸區域內執行管理工作。根據最佳實務，這表示您的大多數使用者和成員帳戶管理員永遠不會看到 AWS Control Tower 主控台。身為管理帳戶管理員群組的成員，您有責任視需要向您成員帳戶的使用者和管理員解釋以下資訊。
+ 說明使用者和管理員可以在登陸區域內存取哪些 AWS 資源。
+ 列出適用於每個組織單位 (OU) 的預防性控制，以便其他管理員可以相應地規劃和執行其 AWS 工作負載。

## 說明資源存取
<a name="explaining-resource-access"></a>

有些管理員和其他使用者可能需要說明他們在登陸區域中可存取 AWS 的資源。此存取可以包括程式設計存取和以主控台為基礎的存取。一般而言，允許 AWS 資源的讀取存取和寫入存取。若要在 內執行工作 AWS，您的使用者需要某種層級的存取權才能執行其任務所需的特定服務。

有些使用者，例如您的 AWS 開發人員，可能需要了解他們可存取的資源，以便他們可以建立工程解決方案。其他使用者，例如在 AWS 服務上執行的應用程式最終使用者，不需要知道登陸區域中 AWS 的資源。

AWS 提供工具來識別使用者 AWS 資源存取的範圍。識別使用者存取的範圍之後，您可以根據組織的資訊管理政策，與使用者分享該資訊。如需這些工具的詳細資訊，請參閱下列連結。
+ **AWS 存取建議**程式 – AWS Identity and Access Management (IAM) 存取建議程式工具可讓您在 IAM 實體，例如使用者、角色或群組，稱為 AWS 服務時，透過分析上次時間戳記來判斷開發人員擁有的許可。您可以稽核服務存取和移除不必要的權限，而且可以視需要自動化程序。如需詳細資訊，請參閱[我們的 AWS 安全部落格文章](https://aws.amazon.com/blogs/security/automate-analyzing-permissions-using-iam-access-advisor)。
+ **IAM 政策模擬器** – 透過 IAM 政策模擬器，您可以測試和疑難排解 IAM 型和資源型政策。如需詳細資訊，請參閱[使用 IAM 政策模擬器測試 IAM 政策](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_testing-policies.html)。
+ **AWS CloudTrail 日誌** – 您可以檢閱 AWS CloudTrail 日誌，以查看使用者、角色或 採取的動作 AWS 服務。如需有關 CloudTrail 的相關資訊，請參閱 [AWS CloudTrail 使用者指南](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-user-guide.html)。

  AWS Control Tower 登陸區域管理員採取的動作可在登陸區域管理帳戶中檢視。您可以在共用日誌封存帳戶中檢視成員帳戶管理員和使用者採取的動作。

  您可以在[活動頁面中檢視 AWS Control Tower 事件的摘要資料表。](https://console.aws.amazon.com/)

## 說明預防性控制
<a name="explaining-preventive-controls"></a>

預防性控制可確保組織的帳戶持續遵守您的公司政策。預防性控制的狀態為**強制執行**或未**啟用**。預防性控制使用服務控制政策 (SCPs)、資源控制政策 (RCPs) 或宣告政策來防止政策違規。相比之下，偵測性控制會透過定義的 AWS Config 規則通知您存在的各種事件或狀態。

您的一些使用者，例如 AWS 開發人員，可能需要了解適用於他們使用的任何帳戶和 OUs預防性控制，以便他們可以建立工程解決方案。以下程序根據貴組織的資訊管理政策，針對如何為適當的使用者提供此資訊，提供一些指導方針。

**注意**  
此程序假設您已在登陸區域內建立至少一個子 OU，以及至少一個 AWS IAM Identity Center 使用者。

**範例：為需要知道的使用者顯示預防性控制**

1. 登入 AWS Control Tower 主控台，網址為 https：//[https://console.aws.amazon.com/controltower/](https://console.aws.amazon.com/controltower/)。

1. 從左側導覽中，選擇**組織**。

1. 從表格中，選擇您的使用者需要適用控制項相關資訊的其中一個 OUs **名稱**。

1. 請注意 OU 的名稱和適用於此 OU 的控制項。

1. 對於使用者所需資訊的每個 OU 重複前兩個步驟。

如需控制項及其函數的詳細資訊，請參閱 [AWS Control Tower 中的關於控制項](https://docs.aws.amazon.com//controltower/latest/userguide/controls.html)。

# 規劃您的 AWS Control Tower 登陸區域
<a name="planning-your-deployment"></a>

當您完成設定程序時，AWS Control Tower 會啟動與您的帳戶相關聯的金鑰資源，稱為*登陸區域*，做為您組織及其帳戶的首頁。

**注意**  
每個組織可以有一個登陸區域。

如需規劃和設定登陸區域時應遵循的一些最佳實務的相關資訊，請參閱 [AWS AWS Control Tower 登陸區域的多帳戶策略](aws-multi-account-landing-zone.md)。

**設定 AWS Control Tower 的方法**

您可以在現有組織中設定 AWS Control Tower 登陸區域，也可以從建立包含 AWS Control Tower 登陸區域的新組織開始。
+ [在現有組織中啟動 AWS Control Tower](#deploy-with-existing-orgs)：本節適用於已經 AWS Organizations 準備好讓 AWS Control Tower 進行控管的客戶。
+ [在新組織中啟動 AWS Control Tower](#fresh-deployment-no-existing-orgs)：本節適用於沒有現有 AWS Organizations、OUs 和帳戶的客戶。

**注意**  
如果您已有 AWS Organizations 登陸區域，您可以將 AWS Control Tower 管控從現有登陸區域擴展到組織內的部分或全部現有 OUs 和帳戶。請參閱[管理現有的組織和帳戶](https://docs.aws.amazon.com//controltower/latest/userguide/importing-existing.html)。

## 比較功能
<a name="functionality-comparison"></a>

以下是將 AWS Control Tower 新增至現有組織或將 AWS Control Tower 控管延伸至 OUs 和帳戶之間的差異的簡短比較。此外，如果您要從 AWS 登陸區域解決方案移至 AWS Control Tower，也會有一些特殊考量。

**關於將 新增至現有組織：**將 AWS Control Tower 新增至現有組織是您可以在 主控台中 AWS 完成的任務。在此情況下，您已經擁有已在 AWS Organizations 服務中建立的組織、該組織目前尚未向 AWS Control Tower 註冊，而且之後想要*新增登陸區域*。

當您*將*登陸區域新增至現有組織時，AWS Control Tower 會在 AWS Organizations 層級設定平行結構。它不會變更現有組織中OUs 和帳戶。

**關於擴展控管：**擴展控管適用於已向 AWS Control Tower *註冊的單一組織中*的特定 OUs 和帳戶，這表示該組織已存在登陸區域。擴展控管意味著擴展 AWS Control Tower 控制項，以便其限制條件適用於該註冊組織中的特定 OUs 和帳戶。在此情況下，您不會啟動新的登陸區域，只會擴展組織的目前登陸區域。

**重要**  
特殊考量：如果您目前使用適用於 的[AWS 登陸區域解決方案 (ALZ)](https://aws.amazon.com//solutions/implementations/aws-landing-zone/) AWS Organizations，請先向您的 AWS 解決方案架構師確認，再嘗試在組織中啟用 AWS Control Tower。AWS Control Tower 無法執行預先檢查，以判斷 AWS Control Tower 是否可能干擾您目前的登陸區域部署。如需詳細資訊，請參閱[逐步解說：從 ALZ 移至 AWS Control Tower](alz-to-control-tower.md)。此外，如需將帳戶從一個登陸區域移至另一個登陸區域的資訊，請參閱 [如果帳戶不符合先決條件](fulfill-prerequisites.md)

## 在現有組織中啟動 AWS Control Tower
<a name="deploy-with-existing-orgs"></a>

透過在現有組織中設定 AWS Control Tower 登陸區域，您可以立即開始與現有 AWS Organizations 環境平行運作。您在 中建立的其他 OUs AWS Organizations 保持不變，因為它們並未向 AWS Control Tower 註冊。您可以繼續依現狀使用該些 OU 和帳戶。

 AWS Control Tower 會使用現有組織的管理帳戶做為其管理帳戶來進行合併。不需要新的管理帳戶。您可以從現有的管理帳戶啟動 AWS Control Tower 登陸區域。

**注意**  
若要在現有組織上設定 AWS Control Tower，您的服務限制必須允許建立至少兩個額外的帳戶。

**將 AWS Control Tower 新增至現有組織的效果**

AWS Control Tower 會在您的組織中建立兩個帳戶：稽核帳戶和記錄帳戶。這些帳戶會記錄您的團隊在其個別最終使用者帳戶中所採取的動作。**稽核**和**日誌封存**帳戶會顯示在 AWS Control Tower 登陸區域內**的安全** OU 中。

當您設定登陸區域時，AWS Control Tower 新增的帳戶會成為您現有組織的一部分 AWS Organizations，因此會成為現有組織帳單的一部分。

### 功能摘要
<a name="comparison-existing-and-not-existing-orgs"></a>

在現有 AWS Organizations 組織上啟用 AWS Control Tower 可為組織提供數個主要增強功能。
+ 它允許跨組織的群組統一計費，因為 AWS Control Tower 新增的帳戶將成為現有組織的一部分。
+ 它可讓您從 OU 中的一個管理帳戶管理所有帳戶。
+ 它簡化了如何套用和強制執行控制，以涵蓋現有和新帳戶的安全性和合規性。

**重要**  
在現有 AWS Organizations 組織中啟動 AWS Control Tower 登陸區域，無法讓您將 AWS Control Tower 管控從該組織擴展到未向 AWS Control Tower 註冊的其他 OUs 或帳戶。

若要在現有組織中啟動 AWS Control Tower，請遵循中所述的程序[AWS Control Tower 入門](getting-started-with-control-tower.md)。

如需 AWS Control Tower 如何與現有 AWS Organizations 組織互動的詳細資訊，請參閱 [使用 AWS Control Tower 管理組織和帳戶](existing-orgs.md)。

## 在新組織中啟動 AWS Control Tower
<a name="fresh-deployment-no-existing-orgs"></a>

如果您是初次使用 AWS Control Tower 且尚未使用 AWS Organizations，最好的起點是使用 [設定](setting-up.md) 文件。

當您沒有設定組織時，AWS Control Tower 會自動為您設定組織。

# AWS AWS Control Tower 登陸區域的多帳戶策略
<a name="aws-multi-account-landing-zone"></a>

AWS Control Tower 客戶通常會尋求有關如何設定 AWS 環境和帳戶以獲得最佳結果的指導。 AWS 已建立一組統一的建議，稱為*多帳戶策略*，以協助您充分利用 AWS 資源，包括 AWS Control Tower 登陸區域。

基本上，AWS Control Tower 可做為與其他 AWS 服務搭配使用的協同運作層，協助您針對 AWS 帳戶和 實作 AWS 多帳戶建議 AWS Organizations。設定登陸區域之後，AWS Control Tower 會繼續協助您在多個帳戶和工作負載中維護公司政策和安全實務。

大多數登陸區域會隨著時間發展。隨著 AWS Control Tower 登陸區域中的組織單位 (OUs) 和帳戶數量增加，您可以透過有助於有效組織工作負載的方式擴展 AWS Control Tower 部署。本章提供如何規劃和設定 AWS Control Tower 登陸區域的規範性指導，以符合 AWS 多帳戶策略，並隨時間擴展。

如需組織單位最佳實務的一般討論，請參閱[搭配 的組織單位最佳實務 AWS Organizations](https://aws.amazon.com//blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)。

## AWS 多帳戶策略：最佳實務指引
<a name="multi-account-guidance"></a>

AWS 架構良好的環境最佳實務建議您將資源和工作負載分隔為多個 AWS 帳戶。您可以將 AWS 帳戶視為隔離的資源容器：它們提供工作負載分類，並在發生錯誤時減少爆量半徑。

** AWS 帳戶的定義**  
* AWS 帳戶充當 資源容器和資源隔離界限。*

**注意**  
 AWS 帳戶與透過聯合或 AWS Identity and Access Management (IAM) 設定的使用者帳戶不同。

** AWS 帳戶詳細資訊**

 AWS 帳戶可讓您隔離資源，並包含 AWS 工作負載的安全威脅。帳戶也提供用於計費和管理工作負載環境的機制。

 AWS 帳戶是為您的工作負載提供資源容器的主要實作機制。如果您的環境架構良好，您可以有效管理多個 AWS 帳戶，進而管理多個工作負載和環境。

AWS Control Tower 會設定架構良好的環境。它依賴 AWS 帳戶以及 AWS Organizations，這有助於控管可跨多個帳戶擴展的環境變更。

**架構良好的環境定義**  
*AWS 將架構良好的環境定義為以 登陸區域開頭的環境。*

AWS Control Tower 提供自動設定的登陸區域。它強制執行控制，以確保在您環境中的多個帳戶中符合您的公司準則。

**登陸區域的定義**  
*登陸區域是提供建議起點的雲端環境，包括預設帳戶、帳戶結構、網路和安全配置等。從登陸區域，您可以部署利用解決方案和應用程式的工作負載。*

## 設定架構良好的環境的指導方針
<a name="guidelines-for-multi-account-setup"></a>

建構良好的環境的三個關鍵元件，如以下章節所述：
+ 多個 AWS 帳戶
+ 多個組織單位 OUs)
+ 妥善規劃的結構

**使用多個 AWS 帳戶**

一個帳戶不足以設定架構良好的環境。透過使用多個帳戶，您可以最佳地支援您的安全目標和業務流程。以下是使用多帳戶方法的一些好處：
+ **安全控制** – 應用程式有不同的安全設定檔，因此需要不同的控制政策和機制。例如，與稽核人員交談並指向託管支付卡產業 (PCI) 工作負載的單一帳戶會更為容易。
+ **隔離** – 帳戶是安全保護的單位。帳戶中可以包含潛在風險和安全威脅，而不會影響其他人。因此，安全需求可能會要求您將帳戶彼此隔離。例如，您可能擁有具有不同安全性設定檔的團隊。
+ **許多團隊** – 團隊有不同的責任和資源需求。透過設定多個帳戶，團隊無法互相干擾，因為他們在使用相同帳戶時可能會相互干擾。
+ **資料隔離** – 將資料存放區隔離到帳戶有助於限制可存取資料並可管理資料存放區的人數。此隔離有助於防止高度私有資料的未經授權暴露。例如，資料隔離有助於支援遵循一般資料保護法規 (GDPR)。
+ **業務流程** – 業務單位或產品通常具有完全不同的目的和流程。您可以建立個別帳戶，以滿足業務特定需求。
+ **帳單** – 帳戶是在帳單層級分隔項目的唯一方法，包括轉移費用等項目。多帳戶策略有助於跨業務單位、職能團隊或個別使用者建立個別的計費項目。
+ **配額配置** – AWS 配額是根據每個帳戶設定。將工作負載分成不同的帳戶，可讓每個帳戶 （例如專案） 獲得明確定義的個別配額。

**使用多個組織單位**

AWS Control Tower 和其他帳戶協同運作架構可以進行跨帳戶界限的變更。因此， AWS 最佳實務可處理跨帳戶變更，這可能會破壞環境或破壞其安全性。在某些情況下，除了政策之外，變更可能會影響整體環境。因此，我們建議您至少設定兩個強制性帳戶：生產和預備。

此外，基於控管和控制目的， AWS 帳戶通常會分組為組織單位 (OUs)。OUs旨在處理多個帳戶間政策的強制執行。

我們建議至少建立生產前 （或預備） 環境，該環境與您的生產環境不同，並具有不同的控制和政策。生產和預備環境可以建立和管理為單獨的 OUs，並以單獨的帳戶計費。此外，您可能想要設定沙盒 OU 進行程式碼測試。

**為登陸區域中OUs 使用妥善規劃的結構**

AWS Control Tower 會自動為您設定一些 OUs。隨著工作負載和需求隨時間擴展，您可以擴展原始登陸區域組態以符合您的需求。

**注意**  
範例中提供的名稱遵循建議的 AWS 命名慣例來設定多帳戶 AWS 環境。您可以在設定登陸區域之後，透過在 OUs 詳細資訊頁面上選取**編輯**來重新命名 OU。

**建議**

AWS Control Tower 為您設定第一個必要的 OU 之後，我們建議您在登陸區域中建立一些額外的 OUs。

我們建議您允許 AWS Control Tower 建立至少一個額外的 OU，稱為沙盒 OU。此 OU 適用於您的軟體開發環境。如果您選取沙盒 OU，AWS Control Tower 可以在登陸區域建立期間為您設定沙盒 OU。

您可以自行設定的兩個建議其他 OUs：基礎設施 OU 包含共用服務和聯網帳戶，以及 OU 包含生產工作負載，稱為工作負載 OU。您可以透過**組織單位**頁面上的 AWS Control Tower 主控台，在登陸區域中新增其他 OUs。

**除了自動設定的 OU 之外的建議 OUs**
+ **基礎設施 OU** – 包含您的共用服務和聯網帳戶。
**注意**  
AWS Control Tower 不會為您設定基礎設施 OU。
+ **沙盒 OU** – 軟體開發 OU。例如，它可能有固定的花費限制，也可能未連線到生產網路。
**注意**  
AWS Control Tower 建議您設定沙盒 OU，但這是選用的。它可以在設定登陸區域時自動設定。
+ **工作負載 OU** – 包含執行工作負載的帳戶。
**注意**  
AWS Control Tower 不會為您設定工作負載 OU。

如需詳細資訊，請參閱[使用 AWS Control Tower 的生產入門組織](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/production-starter-organization.html#production-starter-organization-with-aws-control-tower)。

## 具有完整多帳戶 OU 結構的 AWS Control Tower 範例
<a name="guidelines-for-full-multi-account"></a>

AWS Control Tower 支援巢狀 OU 階層，這表示您可以建立符合組織需求的階層 OU 結構。您可以建置 AWS Control Tower 環境以符合 AWS 多帳戶策略指引。

您也可以建置更簡單、平坦的 OU 結構，其效能良好，並符合 AWS 多帳戶指引。只是因為您可以建置階層式 OU 結構，並不表示您必須這麼做。
+ 若要檢視圖表，其中顯示 OUs 擴展、平面 AWS Control Tower 環境中具有 AWS 多帳戶指引的一組 OU 範例，請參閱[範例：平面 OU 結構中的工作負載](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html#example-workloads-flat-structure)。
+ 如需 AWS Control Tower 如何搭配巢狀 OU 結構運作的詳細資訊，請參閱 [AWS Control Tower 中的巢狀 OUs](nested-ous.md)。
+ 如需 AWS Control Tower 如何符合 AWS 指引的詳細資訊，請參閱 AWS 白皮書：[使用多個帳戶組織您的 AWS 環境](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/appendix-e-establish-multi-account.html)。

連結頁面上的圖表顯示已建立更多基礎 OUs和更多其他 OUs。這些 OUs 可滿足大型部署的其他需求。

在基礎 OUs欄中，有兩個 OUs已新增至基本結構：
+ **Security\$1Prod OU** – 提供安全政策的唯讀區域，以及碎片安全稽核區域。
+ **基礎設施 OU** – 您可能希望將先前建議的基礎設施 OU 分成兩個 OUs，即 Infrastructure\$1Test （適用於生產前基礎設施） 和 Infrastructure\$1Prod （適用於生產基礎設施）。

在其他 OUs區域中，已將多數個 OUs新增至基本結構。以下是隨著環境成長而建立的下一個建議 OUs：
+ **工作負載 OU** – 先前建議但選用的工作負載 OU 已分成兩個 OUs：Workloads\$1Test （適用於生產前工作負載） 和 Workloads\$1Prod （適用於生產工作負載）。
+ **PolicyStaging OU** – 允許系統管理員在完全套用控制項和政策之前測試其變更。
+ **暫停的 OU** – 為可能暫時停用的帳戶提供位置。

## 關於根目錄
<a name="about-the-root"></a>

根不是 OU。這是管理帳戶以及組織中所有 OUs和帳戶的容器。概念上，根包含所有 OUs。無法刪除。您無法在 AWS Control Tower 的根層級管理已註冊的帳戶。反之， 會控管您 OUs 中的註冊帳戶。如需實用圖表，請參閱 [AWS Organizations 文件](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_getting-started_concepts.html)。

# 登陸區域設定的管理秘訣
<a name="tips-for-admin-setup"></a>

以下是設定和設定登陸區域的一些秘訣。
+ 您執行最多工作 AWS 的區域應該是您的主區域。
+ 設定您的登陸區域，並從主區域部署您的 Account Factory 帳戶。
+ 如果您要投資多個 AWS 區域，請確定您的雲端資源位於您將執行大部分雲端管理工作並執行工作負載的區域中。
+ 透過將您的工作負載和日誌保留在同一個 AWS 區域中，您可以降低與跨區域移動和擷取日誌資訊相關聯的成本。
+ 稽核和其他 Amazon S3 儲存貯體會在您啟動 AWS Control Tower 的相同 AWS 區域中建立。建議不要移動這些儲存貯體。
+ 您可以在 Log Archive 帳戶中建立自己的日誌儲存貯體，但不建議這麼做。請務必保留 AWS Control Tower 建立的儲存貯體。
+ 您的 Amazon S3 存取日誌必須與來源儲存貯體位於相同的 AWS 區域。
+ 啟動時，必須在管理帳戶中針對 AWS Control Tower 支援的所有區域啟用 AWS 安全性字符服務 (STS) 端點。否則，啟動可能會在組態過程中途發生失敗。
+ *AWS Control Tower 僅支援已啟用控制項的標記。*如需詳細資訊，請參閱[AWS Control Tower 控制標記 APIs](2023-all.md#control-tagging-apis)。
+ 我們建議為 AWS Control Tower 管理的每個帳戶啟用多重驗證 (MFA)。
+ 或者，您可以使用 AWS 根存取管理功能，允許對成員帳戶執行根動作，並不需要為每個帳戶啟用 MFA。如需詳細資訊，請參閱[使用 為客戶集中管理根存取權 AWS Organizations](https://aws.amazon.com/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/)。

**VPCs的考量**
+ AWS Control Tower 建立的 VPC 僅限於可使用 AWS Control Tower AWS 區域 的 。有些工作負載在不支援的區域中執行的客戶可能想要停用以您的 Account Factory 帳戶建立的 VPC。他們可能偏好使用 Service Catalog 產品組合建立新的 VPC，或建立只在所需區域中執行的自訂 VPC。
+ AWS Control Tower 建立的 VPC 與為所有 建立的預設 VPC 不同 AWS 帳戶。在支援 AWS Control Tower 的區域中，AWS Control Tower 會在建立 AWS Control Tower VPC 時刪除預設 VPC。
+  如果您在主要區域中刪除預設 VPC AWS ，最好在所有其他 AWS 區域中將其刪除。

# 登陸區域 v4.0 遷移指南
<a name="landing-zone-v4-migration-guide"></a>

 AWS Control Tower 登陸區域 4.0 引入了登陸區域架構的主要大修，提供靈活的專用控制體驗和完全可選的服務整合。主要增強功能包括選擇性地啟用 AWS Config、AWS CloudTrail、SecurityRoles 和 AWS Backup 整合，以及 AWS Config 和 AWS CloudTrail 的專用資源，以改善隔離。

 版本會移除強制性的組織結構需求，讓客戶能夠定義自己的組織結構需求，同時引進新的`ConfigBaseline`偵測性控制支援，而不需要完整的 `AWSControlTowerBaseline`。服務連結的 Config 彙總工具會取代先前的彙總方法，簡化合規資料收集。

 此外，資訊清單欄位會變成選用，讓最少的登陸區域部署僅 AWS Organizations 專注於整合和控制啟用。這些變更提供更大的自訂選項，同時維持強大的控管功能，讓客戶更有效地根據其特定需求量身打造 AWS Control Tower。

**Topics**
+ [金鑰變更](key-changes-lz-v4.md)
+ [AWS Config 更新](config-updates-v4.md)

# 金鑰變更
<a name="key-changes-lz-v4"></a>

**注意**  
 「已註冊」和「已註冊」的定義已隨著 AWS Control Tower 的新版本而轉移。當您的帳戶/OU 已啟用任何 AWS Control Tower 資源時 （例如控制項或基準），它將被視為受管資源。定義將不再由`AWSControlTowerBaseline`基準的存在所驅動。
 服務連結角色會保留在所有登陸區域版本中，並且在 OUs 變成「未註冊」時不再刪除 
 只有在登陸區域解除委任後，客戶才能手動刪除服務連結角色 
+  **登陸區域 4.0 的先決條件：**透過 API 升級至 4.0 版時，請確定`AWSControlTowerCloudTrailRole`服務角色使用新的受管政策，`AWSControlTowerCloudTrailRolePolicy`而非現有的內嵌政策。分離目前的內嵌政策並連接新的受管政策，如 [文件](https://docs.aws.amazon.com//controltower/latest/userguide/access-control-managing-permissions.html#AWSControlTowerCloudTrailRolePolicy)所述。
+  **選用資訊清單：**登陸區域 API 中的資訊清單欄位現在為選用。客戶可以建立登陸區域，而不需要任何服務整合。對於已經使用資訊清單欄位的現有客戶沒有影響。
+  **選用的組織結構：**AWS Control Tower 不再強制執行或管理安全 OU 建立，讓客戶可以定義和管理自己的組織結構。不過，AWS Control Tower 會要求針對每個 AWS 服務整合設定的所有帳戶都位於相同的父 OU 下。對於已設定 AWS Control Tower 且具有安全 OU 的客戶，沒有影響。AWS Control Tower 會自動部署在 Security OU 中管理服務整合帳戶所需的資源和控制項。例如，啟用 AWS Config 整合時，會在所有服務整合帳戶中啟用 AWS Config 記錄。AWS Control Tower 基準和 AWS Config 基準不適用於安全 OU 和整合帳戶。若要變更服務整合，請更新登陸區域設定。
**注意**  
 AWS Control Tower 登陸區域 4.0 的組織結構設定已從先前的登陸區域版本變更。AWS Control Tower 將不再建立指定的安全 OU。具有服務整合帳戶的 OU 將是指定的安全 OU。
 如果成員帳戶移至每個整合帳戶所在的 OU，則無論開啟或關閉自動註冊，都會漂移在該 OU 上啟用的控制項。
+  **偏離通知：**AWS Control Tower 將在未`AWSControlTowerBaseline`啟用 的情況下，停止向登陸區域 4.0 的所有客戶傳送偏離通知至 SNS 主題，並改為開始將偏離通知傳送至管理帳戶中的 EventBridge。若要檢閱如何透過 EventBridge 接收偏離通知的範例事件和指引，請參閱[本指南](https://docs.aws.amazon.com/controltower/latest/userguide/governance-drift.html)。
+  **選用的服務整合：**您現在可以啟用/停用所有 AWS Control Tower 整合 AWS Config，包括 AWS CloudTrail、SecurityRoles 和 AWS Backup。這些整合現在在 API 中也有選用的必要`enabled`旗標。可能適用於您的登陸區域或共用帳戶的基準現在彼此具有相依性。整合的特定相依性為：
  + 啟用：
    +  `CentralSecurityRolesBaseline` → `CentralConfigBaseline` 需要啟用 
    +  `IdentityCenterBaseline` → `CentralSecurityRolesBaseline` 需要啟用 
    +  `BackupCentralVaultBaseline` → `CentralSecurityRolesBaseline` 需要啟用 
    +  `BackupAdminBaseline` → `CentralSecurityRolesBaseline` 需要啟用 
    +  `LogArchiveBaseline` → 獨立 （無相依性） 
    +  `CentralConfigBaseline` → 獨立 （無相依性） 
  + 停用：
    +  `CentralConfigBaseline` 只有在先停用 `CentralSecurityRolesBaseline`、 `BackupAdminBaseline`和 `BackupCentralVaultBaseline`基準時`IdentityCenterBaseline`，才能停用。
    +  `CentralSecurityRolesBaseline` 只有在 `IdentityCenterBaseline`、 `BackupAdminBaseline`和 `BackupCentralVaultBaseline`基準先停用時，才能停用。
    +  `IdentityCenterBaseline` 可以獨立停用。
    +  `BackupAdminBaseline` 和 `BackupCentralVaultBaseline`基準可以獨立停用 
    +  `LogArchiveBaseline` 可以獨立停用 

# AWS Config 更新
<a name="config-updates-v4"></a>
+  ** AWS Config 和 AWS CloudTrail 的專用資源： ** AWS Config 和 AWS CloudTrail 現在使用單獨的專用 S3 儲存貯體和 SNS 主題，而不是共用資源。客戶在多個整合中使用單一或個別帳戶的彈性受到限制。
  +  升級到 AWS Control Tower 登陸區域 4.0 版時，不會移動現有的資料和 S3 儲存貯體。AWS CloudTrail 整合會繼續使用字首為 的現有 S3 儲存貯體`aws-controltower-logs`。更新操作後的新 AWS Config 資料將存放在新的 S3 儲存貯體中`aws-controltower-config`，並加上 AWS Control Tower 在為 CentralConfigBaseline 指定的帳戶中建立的字首。
**注意**  
 第一次在登陸區域 4.0 上啟用 AWS CloudTrail 整合時，每次都會使用字首建立新的 S3 儲存貯體 `aws-controltower-cloudtrail` 
  +  資料位置變更：從先前共用的現有客戶升級至專用資源時，會在不同的 S3 儲存貯體中擁有 AWS Config 和 AWS CloudTrail 資料。建立的客戶工作流程和工具可能需要更新，才能從新的儲存貯體位置存取資料。
  +  AWS CloudTrail 將繼續保留在相同的現有儲存貯體中，但 AWS Config 資料將保留在 AWS Control Tower 建立的新 S3 儲存貯體中。
  +  如果客戶想要將不同的日誌集中到單一儲存貯體，則可以設定跨儲存貯體複寫。如需詳細資訊，請參閱 [ S3 文件](https://docs.aws.amazon.com//AmazonS3/latest/userguide/replication.html)。
  +  如果您已在 AWS Config Control Tower 管理的區域中使用 AWS Control Tower 未建立的預先存在 AWS Config 交付通道註冊帳戶，請將交付通道的 S3 儲存貯體名稱更新為 AWS Config 整合帳戶中具有字首的新 S3 儲存貯`aws-controltower-config-logs-`體，以符合登陸區域 4.0 上的 AWS Control Tower 組態。如需詳細資訊，請參閱[註冊具有現有 AWS Config 資源的帳戶](existing-config-resources.md)。
+  **AWS Config 登陸區域 4.0 版上的整合：**在啟用 AWS Config 整合的情況下遷移至登陸區域 4.0 時，客戶會看到下列變更 - 

  1.  現有的 Audit 帳戶會註冊為 的委派管理員 AWS Config。

  1.  服務連結 Config 彙整工具會部署到 Audit 帳戶 （新客戶的AWS Config 中央彙整工具帳戶和現有客戶的 Audit 帳戶）。新的彙總工具可以從組織中的任何 AWS Config 記錄器彙總資料，包括非 Control Tower 受管帳戶。

  1.  現有的彙總工具將被刪除 - 管理帳戶 (`aws-controltower-ConfigAggregatorForOrganizations`) 中的組織彙總器和稽核帳戶 (`aws-controltower-GuardRailsComplianceAggregator`) 中的帳戶彙總器將被刪除。

  1.  由於組態彙總工具是服務連結，因此與已刪除彙總工具相關聯的控制項會自動移除。

     1. [不允許變更 AWS Control Tower for AWS Config 資源建立的標籤](https://docs.aws.amazon.com//controltower/latest/controlreference/mandatory-controls.html#cloudwatch-disallow-config-changes)

     1. [不允許刪除 AWS Control Tower 建立的 AWS Config 彙總授權](https://docs.aws.amazon.com//controltower/latest/controlreference/mandatory-controls.html#config-aggregation-authorization-policy)
+  **新的`ConfigBaseline`基準：**OU `ConfigBaseline` 層級現在有一個單獨的偵測控制支援，而不需要全面的 `AWSControlTowerBaseline`。如需詳細資訊，請參閱 [OU 層級的基準類型](https://docs.aws.amazon.com//controltower/latest/userguide/types-of-baselines.html#ou-baseline-types)清單。對於使用預設登陸區域的現有客戶，所有服務整合現在都是選用的，並具有 中概述的相依性要求警告[金鑰變更](key-changes-lz-v4.md)。
+  **服務連結組態彙總工具：**取代 AWS Config 中央彙總工具帳戶中的組織和帳戶彙總工具。
  +  在啟用 AWS Config 整合的情況下升級至登陸區域 4.0 時，客戶需要具有 `organizations:ListDelegatedAdministrators` 許可 

    ```
    {
       "Version": "2012-10-17",		 	 	 
       "Statement": [
          {
             "Effect": "Allow",
             "Action": [
               "backup:UpdateGlobalSettings",
               "controltower:CreateLandingZone",
               "controltower:UpdateLandingZone",
               "controltower:ResetLandingZone",
               "controltower:DeleteLandingZone",
               "controltower:GetLandingZoneOperation",
               "controltower:GetLandingZone",
               "controltower:ListLandingZones",
               "controltower:ListLandingZoneOperations",
               "controltower:ListTagsForResource",
               "controltower:TagResource",
               "controltower:UntagResource",
                "servicecatalog:*",
                "organizations:*",
                "organizations:RegisterDelegatedAdministrator",
                "organizations:EnableAWSServiceAccess",
                "organizations:DeregisterDelegatedAdministrator",
                "organizations:ListDelegatedAdministrators",
                "sso:*",
                "sso-directory:*",
                "logs:*",
                "cloudformation:*",
                "kms:*",
                "iam:GetRole",
                "iam:CreateRole",
                "iam:GetSAMLProvider",
                "iam:CreateSAMLProvider",
                "iam:CreateServiceLinkedRole",
                "iam:ListRolePolicies",
                "iam:PutRolePolicy",
                "iam:ListAttachedRolePolicies",
                "iam:AttachRolePolicy",
                "iam:DeleteRole",
                "iam:DeleteRolePolicy",
                "iam:DetachRolePolicy"
             ],
             "Resource": "*"
          }
       ]
    }
    ```

# 設定群組、角色和政策的建議
<a name="roles-recommendations"></a>

設定登陸區域時，建議您先決定好哪些使用者需要存取特定帳戶以及原因。例如，安全帳戶應只能由安全團隊存取，管理帳戶應只能由雲端管理員的團隊存取，以此類推。

如需此主題的詳細資訊，請參閱 [AWS Control Tower 中的身分和存取管理](auth-access.md)。

**建議限制**

您可以設定 IAM 角色或政策，允許管理員僅管理 AWS Control Tower 動作，以限制組織的管理存取範圍。建議的方法為使用 IAM 政策 `arn:aws:iam::aws:policy/service-role/AWSControlTowerServiceRolePolicy`。啟用`AWSControlTowerServiceRolePolicy`角色後，管理員只能管理 AWS Control Tower。請務必在每個帳戶中包含適當的 存取權 AWS Organizations ，以管理您的預防性控制和 SCPs AWS Config，以及 存取權，以管理偵測性控制。

當您在登錄區域中設定共用稽核帳戶時，建議您將 `AWSSecurityAuditors` 群組指派至帳戶的任何第三方稽核員。此群組會提供其成員唯讀權限。帳戶不得在正在稽核的環境中擁有寫入權限，因為這可能違反稽核員的責任分離規定。

您可以在角色信任政策中強加條件，以限制與 AWS Control Tower 中特定角色互動的帳戶和資源。我們強烈建議您限制對`AWSControlTowerAdmin`角色的存取，因為它允許廣泛的存取許可。如需詳細資訊，請參閱[角色信任關係的選用條件](https://docs.aws.amazon.com//controltower/latest/userguide/conditions-for-role-trust.html)。

# 建立和修改 AWS Control Tower 資源的指引
<a name="getting-started-guidance"></a>

當您在 AWS Control Tower 中建立和修改資源時，我們建議您採用下列最佳實務。這個指導可能會隨服務更新而變更。請記住，[共同責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)適用於您的 AWS Control Tower 環境。

**一般指導**
+ 請勿修改或刪除 AWS Control Tower 建立的任何資源，包括管理帳戶、共用帳戶和成員帳戶中的資源。如果您修改這些資源，您可能需要更新登陸區域或重新註冊 OU，而修改可能會導致合規報告不準確。

  **特別是：**
  + 保留作用中 AWS Config 的記錄器。如果您刪除 Config 記錄器，偵測控制項將無法偵測和報告偏離。由於資訊不足，不合規資源可能會報告為**合規**。
  + 請勿修改或刪除在安全組織單位 AWS Identity and Access Management (OU) 中共用帳戶內建立的 (IAM) 角色。修改這些角色可能需要更新您的登陸區域。
  + 請勿從您的成員帳戶刪除`AWSControlTowerExecution`角色，即使是在未註冊的帳戶中也一樣。如果您這麼做，您將無法向 AWS Control Tower 註冊這些帳戶，或註冊其直接父系 OUs。
+ 請勿禁止 AWS 區域 透過 SCPs或 AWS Security Token Service () 使用任何AWS STS。這樣做會導致 AWS Control Tower 進入未定義狀態。如果您不允許使用 的區域 AWS STS，您的功能會在這些區域中失敗，因為在這些區域中無法使用身分驗證。相反地，依賴 AWS Control Tower 區域拒絕功能，如控制項所示，[AWS 根據請求拒絕對 的存取 AWS 區域](https://docs.aws.amazon.com//controltower/latest/userguide/primary-region-deny-policy.html)，其在登陸區域層級運作，或控制[區域拒絕套用至 OU 的控制](https://docs.aws.amazon.com//controltower/latest/userguide/ou-region-deny.html)，其在 OU 層級運作以限制對區域的存取。
+ 必須 AWS Organizations `FullAWSAccess`套用 SCP，且不應與其他 SCPs 合併。此 SCP 的變更不會報告為偏離；不過，如果拒絕存取特定資源，某些變更可能會以無法預測的方式影響 AWS Control Tower 功能。例如，如果 SCP 分離或修改，帳戶可能會失去對記錄器的 AWS Config 存取權或在 CloudTrail 日誌中建立間隙。
+ 請勿使用 AWS Organizations `DisableAWSServiceAccess` API 關閉您設定登陸區域之組織的 AWS Control Tower 服務存取權。如果您這樣做，某些 AWS Control Tower 偏離偵測功能可能無法正常運作，如果沒有來自 的訊息支援 AWS Organizations。這些偏離偵測功能有助於保證 AWS Control Tower 可以準確報告組織中組織單位、帳戶和控制項的合規狀態。如需詳細資訊，請參閱《 [API\$1DisableAWSServiceAccessAWS Organizations API 參考》中的](https://docs.aws.amazon.com//organizations/latest/APIReference/API_DisableAWSServiceAccess.html) 。
+ 一般而言，AWS Control Tower 會一次執行單一動作，必須先完成才能開始另一個動作。例如，如果您嘗試在啟用控制項的程序已在操作時佈建帳戶，帳戶佈建將會失敗。

  **例外狀況：**
  + AWS Control Tower 允許並行動作來部署選用的控制項。如需詳細資訊，請參閱[選用控制項的並行部署](https://docs.aws.amazon.com//controltower/latest/userguide/enable-controls-on-ou.html#concurrent-optional-controls)。
  + AWS Control Tower 允許帳戶工廠最多十個並行建立、更新或註冊動作。

**注意**  
如需 AWS Control Tower 所建立資源的詳細資訊，請參閱 [什麼是共用帳戶？](what-shared.md)。

**有關帳戶和 OUs提示**
+ 我們建議您將每個已註冊的 OU 保留為最多 1000 個帳戶，以便在需要帳戶更新時，使用**重新註冊 OU **功能來更新這些帳戶，例如設定新的 區域進行控管。
+ 若要縮短註冊 OU 所需的時間，建議您將每個 OU 的帳戶數量保留在大約 680 個，即使限制為每個 OU 1000 個帳戶。一般而言，註冊 OU 所需的時間會根據您 OU 操作的區域數量增加，乘以 OU 中的帳戶數量。
+ 根據預估，擁有 680 個帳戶的 OU 最多可能需要 2 小時才能註冊和啟用控制項，最多可能需要 1 小時才能重新註冊。此外，具有許多控制項的 OU 比具有少量控制項的 OU 需要更長的時間進行註冊。
+ 允許較長的 OU 註冊時間範圍的其中一個考量是此程序會封鎖其他動作。有些客戶願意允許更長的時間註冊或重新註冊 OU，因為他們偏好在每個 OU 中允許更多帳戶。

# 以根使用者身分登入的時機
<a name="root-login"></a>

特定管理工作需要您以根使用者的身分登入。您可以以根使用者身分登入 AWS Control Tower 中帳戶工廠建立 AWS 帳戶 的 。

**您必須以根使用者的身分登入，才能執行下列動作：**
+ 變更特定帳戶設定，包括帳戶名稱、根使用者密碼或電子郵件地址。如需詳細資訊，請參閱[使用 AWS Control Tower 更新和移動帳戶](updating-account-factory-accounts.md)。
+ 關閉 [AWS 帳戶](https://docs.aws.amazon.com//awsaccountbilling/latest/aboutv2/close-account.html)。
+ 如需需要根使用者登入憑證之動作的詳細資訊，請參閱《 *AWS 帳戶管理 參考指南*》中的[需要根使用者登入](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)憑證的任務。

**注意**  
若要變更或啟用[AWS 支援計劃，您必須以根使用者身分登入，*或是*具有適當 IAM 許可的使用者。 ](https://docs.aws.amazon.com//controltower/latest/userguide/troubleshooting.html#getting-support)

**以根使用者身分登入**

1. 開啟 AWS 登入頁面。

   如果您沒有 AWS 帳戶 您需要存取的 的電子郵件地址，您可以從 AWS Control Tower 取得。開啟 管理帳戶的主控台，選擇 **帳戶**，然後尋找電子郵件地址。

1. 輸入 AWS 帳戶 您需要存取的 的電子郵件地址，然後選擇 **下一步**。

1. 選擇 **Forgot password? (忘記密碼？)**，將密碼重設說明寄送至根使用者電子郵件地址。

1.  開啟來自根使用者信箱的密碼重設電子郵件訊息，然後依照說明重設您的密碼。

1. 開啟 AWS 登入頁面，然後使用重設密碼登入。

或者，您可以使用 AWS 根存取管理功能，允許在成員帳戶上執行根動作，而不需要以根身分登入。如需詳細資訊，請參閱[使用 為客戶集中管理根存取權 AWS Organizations](https://aws.amazon.com/blogs/aws/centrally-managing-root-access-for-customers-using-aws-organizations/)。

# AWS Organizations 指引
<a name="orgs-guidance"></a>

AWS Control Tower 與 密切相關 AWS Organizations。以下是一些具體指引，說明它們如何以最佳方式協同運作來保護您的 AWS 環境。
+ 您可以在 AWS Organizations 文件中找到保護 AWS Control Tower 管理帳戶和成員帳戶安全的最佳實務相關指導。
  + [管理帳戶的最佳實務](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)
  + [成員帳戶的最佳實務](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_member-acct.html)
+ 請勿更新連接至向 AWS Control Tower 註冊之 OU 的現有服務控制政策 (SCPs)。這樣做可能會導致控制項進入未知狀態，這將會要求您在 AWS Control Tower 中重設登陸區域或重新註冊 OU。反之，您可以使用 AWS Organizations 建立新的 SCPs，並將它們連接到 OUs，而不是編輯 AWS Control Tower 已建立SCPs。
+ 將已註冊的個人帳戶從已註冊的 OU 外部移至 AWS Control Tower，會導致必須解決的偏離。請參閱 [控管偏離的類型](governance-drift.md)。
+ 如果您使用 AWS Organizations 在向 AWS Control Tower 註冊的組織中建立、邀請或移動帳戶，AWS Control Tower 不會註冊這些帳戶，也不會記錄這些變更。如果您需要透過 SSO 存取這些帳戶，請參閱[成員帳戶存取](https://aws.amazon.com//premiumsupport/knowledge-center/organizations-member-account-access/)。
+ 如果您使用 AWS Organizations 將 OU 移至 AWS Control Tower 建立的組織，則 AWS Control Tower 不會註冊外部 OU。
+ AWS Control Tower 處理許可篩選的方式與 AWS Organizations 處理方式不同。如果使用 AWS Control Tower 帳戶工廠佈建您的帳戶，最終使用者可以在 AWS Control Tower 主控台中查看所有 OUs 的名稱和父項，即使他們沒有 AWS Organizations 直接從 擷取這些名稱和父項的許可。
+ AWS Control Tower 不支援組織混合許可，例如檢視 OU 父項但不支援檢視 OU 名稱的許可。因此，AWS Control Tower 管理員應擁有完整許可。
+ 必須 AWS Organizations `FullAWSAccess`套用 SCP，且不應與其他 SCPs 合併。此 SCP 的變更不會報告為偏離；不過，如果拒絕存取特定資源，某些變更可能會以無法預測的方式影響 AWS Control Tower 功能。例如，如果 SCP 分離或修改，帳戶可能會失去對記錄器的 AWS Config 存取權或在 CloudTrail 日誌中建立間隙。
+ 請勿使用 AWS Organizations `DisableAWSServiceAccess` API 關閉您設定登陸區域之組織的 AWS Control Tower 服務存取權。如果您這樣做，某些 AWS Control Tower 偏離偵測功能可能無法正常運作，如果沒有來自 的訊息支援 AWS Organizations。這些偏離偵測功能有助於保證 AWS Control Tower 可以準確報告組織中組織單位、帳戶和控制項的合規狀態。如需詳細資訊，請參閱《 [API\$1DisableAWSServiceAccessAWS Organizations API 參考》中的](https://docs.aws.amazon.com//organizations/latest/APIReference/API_DisableAWSServiceAccess.html) 。

# IAM Identity Center 指引
<a name="sso-guidance"></a>

AWS Control Tower 建議您使用 AWS Identity and Access Management (IAM) 來規範對 的存取 AWS 帳戶。不過，您可以選擇 AWS Control Tower 是否為您設定 IAM Identity Center、您是否以最符合您業務需求的方式為自己設定 IAM Identity Center，還是選擇其他帳戶存取方法。

**注意**  
**SSO** 是技術產業用來表示*單一登入*的縮寫。一般而言，SSO 是工作階段和使用者身分驗證服務。它允許某人使用一組登入憑證來存取許多應用程式。參考 中的單一登入功能時 AWS，我們指的是名為 AWS 的服務**AWS Identity and Access Management**，並縮寫為 **IAM** 或 **IAM Identity Center**。

根據預設，AWS Control Tower AWS 會為您的登陸區域設定 IAM Identity Center，以符合[使用多個帳戶整理 AWS 環境](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)時所定義的最佳實務指引。大多數客戶都會選擇預設值。有時需要替代的存取方法，才能在特定產業或國家/地區的法規合規，或是無法使用 AWS IAM Identity Center AWS 區域 的 。

**選擇選項**

從主控台，您可以選擇在登陸區域設定程序中自我管理 IAM Identity Center，而不是允許 AWS Control Tower 為您設定。稍後，您可以在登陸區域設定****頁面上修改登陸區域設定並更新登陸區域，以選擇變更此選項。

**若要停止 AWS Control Tower AWS 中的 IAM Identity Center，或開始使用 AWS IAM Identity Center**

1. 導覽至登陸區域**設定**頁面

1. 選取**組態**索引標籤

1. 然後選擇適當的選項按鈕，以變更 IAM Identity Center AWS 的選擇。

在您選擇自行管理 AWS IAM Identity Center 做為 IdP 之後，AWS Control Tower 只會建立管理 AWS Control Tower 所需的這些角色和政策，例如 `AWSControlTowerAdmin`和 `AWSControlTowerAdminPolicy`。對於自我管理的登陸區域，AWS Control Tower 不再為客戶特定用途建立 IAM 角色和群組，而不是在登陸區域設定程序期間，或在帳戶工廠的帳戶佈建期間。

**注意**  
如果您從 AWS Control Tower AWS 登陸區域移除 IAM Identity Center，則不會移除 AWS Control Tower 建立的使用者、群組和許可集。我們建議您移除這些資源。

具有替代身分提供者 IdPs) 的帳戶工廠客戶，例如 Azure AD、Ping 或 Okta，可以遵循 AWS IAM Identity Center [程序](https://docs.aws.amazon.com//singlesignon/latest/userguide/manage-your-identity-source-idp.html)連線到外部身分提供者並加入其 IdP。您可以隨時修改登陸區域設定，讓 AWS Control Tower 產生您的群組和角色。
+ 如需 AWS Control Tower 如何根據您的身分來源與 IAM Identity Center 搭配使用的特定資訊，請參閱《 使用者指南*》入門*頁面的[啟動前檢查](https://docs.aws.amazon.com//controltower/latest/userguide/getting-started-prereqs.html#sso-considerations)一節中的** AWS IAM Identity Center 客戶考量事項**。
+ 如需 AWS Control Tower 行為如何與 IAM Identity Center 和不同身分來源互動的其他資訊，請參閱《*IAM Identity Center 使用者指南*》中的[變更身分來源的考量](https://docs.aws.amazon.com//singlesignon/latest/userguide/manage-your-identity-source-considerations.html)。
+ 如需使用 AWS Control Tower 和 IAM Identity Center 的詳細資訊[使用 AWS IAM Identity Center 和 AWS Control Tower](sso.md)，請參閱 。

# 帳戶工廠指引
<a name="af-guidance"></a>

**注意**  
單一帳戶佈建、更新和自訂必須以啟用 AWSControlTowerBaseline 的組織單位 (OU) 為目標。如果 OU 未啟用 AWSControlTowerBaseline，您可以啟用帳戶自動註冊，或在 EnabledBaselines 上使用 ResetEnabledBaseline 和 ResetEnabledControl APIs並在該 OU 上使用 EnabledControls 來註冊帳戶。如需 AWSControlTowerBaseline 的詳細資訊，請參閱：[在 OU 層級套用的基準類型](types-of-baselines.md#ou-baseline-types)。

 使用 Account Factory 在 AWS Control Tower 中佈建新帳戶時，您可能會遇到問題。如需有關如何對這些問題進行故障診斷的資訊，請參閱《*AWS Control Tower 使用者指南*》[的故障診斷](https://docs.aws.amazon.com/controltower/latest/userguide/troubleshooting.html)[新帳戶佈建失敗](troubleshooting.md#account-provisioning-failed)一節。

 我們建議您建立聯合身分使用者或 IAM 角色，而不是 IAM 使用者。聯合身分使用者和 IAM 角色為您提供暫時登入資料。IAM 使用者具有難以管理的長期登入資料。如需詳細資訊，請參閱《[IAM 使用者指南》中的 IAM 身分 （使用者、使用者群組和角色）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)。 **

 如果您在 Account Factory 中佈建新帳戶或使用*註冊帳戶*功能 AWS Control Tower 時，已驗證為 IAM 使用者或 IAM Identity Center 使用者，請確認您的使用者可存取您的 AWS Service Catalog 產品組合。否則，您可能會收到來自 Service Catalog 的錯誤訊息。如需詳細資訊，請參閱[找不到啟動路徑錯誤](troubleshooting.md#no-launch-paths-found)《*AWS Control Tower 使用者指南*》中的[故障診斷一節](https://docs.aws.amazon.com/controltower/latest/userguide/troubleshooting.html)。

**注意**  
 一次最多可佈建五個帳戶。

# 訂閱 SNS 主題的指引
<a name="sns-guidance"></a>

訂閱 SNS 主題以取得 AWS Control Tower 環境的相關資訊。

**注意**  
AWS Control Tower 會停止為所有 LZ4.0\$1 上的客戶傳送偏離通知至 SNS 主題。
+ `aws-controltower-AllConfigNotifications` SNS 主題會接收 發佈的所有事件 AWS Config，包括合規通知和 Amazon CloudWatch 事件通知。例如，如果發生控制違規，本主題會通知您。它也會提供有關其他類型事件的資訊。([AWS Config](https://docs.aws.amazon.com//config/latest/developerguide/notifications-for-AWS-Config.html)進一步了解設定此主題時發佈的內容。) 
+ 來自`aws-controltower-BaselineCloudTrail`追蹤[的資料事件](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html?icmpid=docs_cloudtrail_console#logging-data-events)也會設定為發佈至 `aws-controltower-AllConfigNotifications` SNS 主題。
+ 若要接收詳細的合規通知，建議您訂閱 `aws-controltower-AllConfigNotifications` SNS 主題。本主題彙總所有子帳戶的合規通知。
+ 若要接收偏離通知和其他通知以及合規通知，但整體而言較少通知，建議您訂閱 `aws-controltower-AggregateSecurityNotifications` SNS 主題。
+ 若要接收有關 AWS Control Tower Account Factory for Terraform (AFT) 錯誤的通知，您可以訂閱名為 的 SNS 主題[https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/0f2caea57e37a1a58dc305e2f342e9c28aeb9c41/modules/aft-account-request-framework/sns.tf](https://github.com/aws-ia/terraform-aws-control_tower_account_factory/blob/0f2caea57e37a1a58dc305e2f342e9c28aeb9c41/modules/aft-account-request-framework/sns.tf)，如 AFT 儲存庫所示。例如：

  ```
  resource "aws_sns_topic" "aft_failure_notifications" {
      name = "aft-failure-notifications"
      kms_master_key_id = "alias/aws/sns"
  }
  ```
+ 所有 SNS 主題都會使用磁碟加密進行靜態加密。如需詳細資訊，請參閱[資料加密](https://docs.aws.amazon.com//sns/latest/dg/sns-data-encryption.html)。

如需 SNS 主題和合規的詳細資訊，請參閱[預防和通知](https://docs.aws.amazon.com//controltower/latest/userguide/prevention-and-notification.html)。

# KMS 金鑰的指引
<a name="kms-guidance"></a>

AWS Control Tower 可與 AWS Key Management Service (AWS KMS) 搭配使用。或者，如果您想要使用您管理的加密金鑰來加密和解密 AWS Control Tower 資源，您可以產生和設定 AWS KMS keys。您可以在更新登陸區域時新增或變更 KMS 金鑰。最佳實務是建議您使用自己的 KMS 金鑰，並隨時變更它們。

AWS KMS 可讓您建立多區域 KMS 金鑰和非對稱金鑰。不過，AWS Control Tower 不支援多區域金鑰或非對稱金鑰。AWS Control Tower 會執行現有金鑰的預先檢查。如果您選擇多區域金鑰或非對稱金鑰，您可能會看到錯誤訊息。在這種情況下，請產生另一個金鑰以搭配 AWS Control Tower 資源使用。

*對於操作 AWS CloudHSM 叢集的客戶：*建立與 CloudHSM 叢集相關聯的自訂金鑰存放區。然後，您可以建立 KMS 金鑰，該金鑰位於您建立的 CloudHSM 自訂金鑰存放區中。您可以將此 KMS 金鑰新增至 AWS Control Tower。

您必須對 KMS 金鑰的許可政策進行特定更新，才能使用 AWS Control Tower。如需詳細資訊，請參閱名為 的章節[更新 KMS 金鑰政策](configure-kms-keys.md#kms-key-policy-update)。

# 登陸區域更新的最佳實務
<a name="lz-update-best-practices"></a>

當您考慮在 AWS Control Tower 中升級登陸區域版本時，本節提供一些考量和最佳實務。從 2.0 登陸區域版本系列變更為 3.0 登陸區域版本系列尤其重要。升級登陸區域時，AWS Control Tower 會自動將您移至最新的可用版本。

**注意**  
最佳實務是更新至最新版本的登陸區域。

**本節中說明的最佳實務摘要**
+  **最佳實務：**基於安全和稽核原因，強烈建議您為所有帳戶啟用整個電路板的記錄，並將記錄資訊傳送至集中位置。在 AWS Control Tower 中，此集中位置是**日誌封存**帳戶，可提供 Amazon S3 記錄儲存貯體。
+ **最佳實務：**如果您選擇退出 AWS Control Tower 中的組織層級 CloudTrail 追蹤，請設定和管理您自己的追蹤。
+ **最佳實務：**操作 AWS Control Tower 環境時，請設定測試環境。

**從 2.x 登陸區域版本移至 3.x 登陸區域版本的優勢**
+ 僅在主區域中記錄 AWS Config 資源，這可在您管理全域資源時節省成本
+ 使用您自己的 KMS 金鑰加密您的 AWS CloudTrail 線索
+ 自訂您的日誌保留時間範圍
+ 增強型強制性控制
+ 可用的控制項數量增加
+ 與 整合 AWS Security Hub CSPM
+ Python 執行期更新

**從 2.x 登陸區域版本移至 3.x 登陸區域版本的注意事項**
+ 在登陸區域 3.0 及更新版本中，AWS Control Tower 不再支援 AWS 管理的帳戶層級 AWS CloudTrail 追蹤。
+ 您可以選擇由 AWS Control Tower 管理的組織層級追蹤，或選擇退出它並管理您自己的 CloudTrail 追蹤。
+ 有些潛在的雙成本存在，特別是如果 OU 中的某些帳戶未註冊 AWS Control Tower，並且有自己想要保留的帳戶層級追蹤。

**選擇組織層級 CloudTrail 追蹤的考量**
+ 當您升級至 3.0 或更新版本時，AWS Control Tower 會在 24 小時後刪除其最初建立的帳戶層級追蹤。[【例外狀況】](https://docs.aws.amazon.com//controltower/latest/userguide/retain-account-trails.html)
+ 不會遺失來自這些線索的資料。即使移除線索，您現有的日誌也會保留。
+ AWS Control Tower 會在追蹤的相同 Amazon S3 儲存貯體中建立新的路徑，以區分帳戶層級追蹤與組織層級追蹤。
  + 帳戶追蹤日誌路徑的格式如下： `/orgId/AWSLogs/...`
  + 組織追蹤日誌路徑的格式如下： `/orgId/AWSLogs/orgId/...`
+ 您已部署的其他 CloudTrail 線索，AWS Control Tower 未部署的線索不會碰觸到。
+ 如果未註冊的帳戶是已註冊 OU 的一部分，則所有帳戶都會包含在組織層級追蹤中，包括未在 AWS Control Tower 註冊的帳戶。
+ 連結帳戶中的 Amazon CloudWatch 警示不會觸發。
+ 如果您選擇退出組織層級追蹤，AWS Control Tower 仍會建立追蹤，但將其狀態設定為**關閉**。
+ 最佳實務是，如果您選擇退出 AWS Control Tower 中的組織層級追蹤，您應該設定和管理自己的 CloudTrail 追蹤，

**組織層級追蹤的優勢**
+ 組織追蹤適用於 OU 中的所有帳戶。
+ 記錄的項目是標準化的，帳戶使用者無法修改。

**考慮測試環境**

升級登陸區域時，AWS Control Tower 只會對共用帳戶和基礎 OU 進行變更。它不會對工作負載帳戶或 OUs 進行變更。*不過，根據最佳實務，在操作 AWS Control Tower 環境時，建議您設定測試環境。*在隔離的測試環境中，您可以測試 AWS Control Tower 登陸區域升級，以及您對服務控制政策 (SCPs) 所做的任何變更，也可以測試您想要套用至環境的控制。如果您在受管制的產業中操作，此建議特別有用。

**更新時常見錯誤的檢查清單**

以下是您可以執行的簡短任務清單，以避免將 AWS Control Tower 登陸區域從 2.x 版本更新為 3.x 版本時發生常見錯誤。

**基本更新檢查清單**
+ 檢查您的登陸區域：

   – 前往 AWS Control Tower 服務，檢閱**組織單位**和**帳戶**頁面，然後確認您的帳戶狀態設定為**已註冊**和**已註冊**。

   – 如適用，請驗證並確認自訂管道的上次執行是否成功。

   – 檢查**稽核**帳戶中的 Amazon S3 集中式記錄儲存貯體，因為先前對儲存貯體政策所做的任何變更都會遭到覆寫。
+ 驗證 AWS Control Tower 未擁有的任何 SCPs 不會限制`AWSControlTowerExecution`角色在成員帳戶中執行動作，或在管理帳戶中對執行更新的管理角色執行動作。

# AI 型服務和 AWS Control Tower
<a name="ai-opt-out"></a>

您可以建立服務控制政策 (SCPs)，讓您選擇退出 AI 型服務儲存資料 AWS。這些 SCP 政策指定 AI 型服務，例如 Amazon Rekognition 或 Amazon CodeWhisperer，無法存放和使用您的資料來改善其他 AI 型 AWS 服務。

這些 AI 選擇不接收 SCP 政策可以套用至整個組織、OU 或特定帳戶。這些政策是全域生效的。您可以在 AWS Organizations 文件中找到 AI [服務選擇退出](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html)政策中這些政策的詳細資訊。

如需使用 AI AWS 的服務清單，以及政策範例，請參閱*AWS Organizations 《 使用者指南*》中的 [AI 服務選擇退出政策語法和範例](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_ai-opt-out_syntax.html)。