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

# AWS SRA 的值
<a name="value"></a>


|  | 
| --- |
| 進行[簡短的問卷](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)，以影響 AWS 安全參考架構 (AWS SRA) 的未來。 | 

AWS 有一組大型 （和不斷成長） [的安全和安全相關服務](https://aws.amazon.com/products/security)。客戶對我們的服務文件、部落格文章、教學課程、高峰會和會議提供的詳細資訊表示感謝。他們還告訴我們，他們想要更好地了解大局，並獲得 AWS 安全服務的策略觀點。當我們與客戶合作以更深入了解他們需要什麼時，會出現三個優先順序：
+ 客戶需要更多資訊和建議模式，以了解如何全面部署、設定和操作 AWS 安全服務。服務應部署和管理於哪些帳戶和哪些安全目標？ 是否有一個安全帳戶，其中所有或大多數服務都應該操作？ 選擇位置 （組織單位或 AWS 帳戶) 如何通知安全目標？ 客戶應該注意哪些權衡 （設計考量）？
+ 客戶有興趣查看邏輯組織許多 AWS 安全服務的不同觀點。除了每個服務的主要功能 （例如身分服務或記錄服務） 之外，這些替代觀點還協助客戶規劃、設計和實作其安全架構。本文件稍後共用的範例會根據符合您 AWS 環境建議結構的保護層，將服務分組。
+ 客戶正在尋找指引和範例，以最有效的方式整合安全服務。例如，他們應該如何最好地與其他 服務協調和連線 AWS Config ，以便在自動化稽核和監控管道中繁重工作？ 客戶請求指導，了解每個 AWS 安全服務如何依賴或支援其他安全服務。

我們處理 AWS SRA 中的每個項目。清單中的第一個優先順序 （實物移動的位置） 是主架構圖和本文件中隨附討論的重點。我們提供建議的 AWS Organizations 架構和account-by-account描述，說明 服務的目的地。若要開始使用清單中的第二優先順序 （如何考慮整組安全服務），請閱讀章節：將[安全服務套用至整個 AWS 組織。](security-services.md)本節說明根據 AWS 組織中元素結構將安全服務分組的方法。此外，這些相同的想法也反映在[應用程式帳戶的](application.md)討論中，重點介紹了如何操作安全服務以專注於帳戶的某些層：Amazon Elastic Compute Cloud (Amazon EC2) 執行個體、Amazon Virtual Private Cloud (Amazon VPC) 網路，以及更廣泛的帳戶。最後，第三優先順序 （服務整合） 會反映在整個指引中，尤其是在 [AWS SRA 程式庫深入指南](about-sra-library.md)中的個別服務討論，以及 AWS SRA 程式碼儲存庫中的程式碼。

## 如何使用 AWS SRA
<a name="how-to-use"></a>

視您在雲端採用旅程中的位置而定，有多種不同的 SRA AWS 使用方式。以下是從 AWS SRA 資產取得最多洞見的方法清單 （架構圖、書面指引和程式碼範例）。
+ 為您自己的安全架構*定義*目標狀態。

  無論您是剛開始 AWS 雲端 旅程，或是設定您的第一組帳戶，或是規劃強化已建立 AWS 的環境， AWS SRA 都是開始建置安全架構的地方。從帳戶結構和安全服務的完整基礎開始，然後根據您的特定技術堆疊、技能、安全目標和合規要求進行調整。如果您知道您要建置並啟動更多工作負載，您可以取得自訂版本的 AWS SRA，並將其用作組織安全參考架構的基礎。若要了解如何達到 AWS SRA 所述的目標狀態，請參閱[建置安全架構 – 分階段方法](phases.md)一節。 
+ *檢閱* （和修訂） 您已實作的設計和功能。

  如果您已經有安全設計和實作，建議您花一些時間來比較與 AWS SRA 的關聯。 AWS SRA 的設計是全方位的，並提供診斷基準來檢閱您自己的安全性。如果您的安全設計與 AWS SRA 保持一致，您可以更有信心在使用 時遵循最佳實務 AWS 服務。如果您的安全設計與 SRA 中的指引不同或甚至不同，這不一定是您做錯事的 AWS 跡象。相反地，此觀察可讓您有機會檢閱您的決策程序。您可能會偏離 AWS SRA 最佳實務的合法商業和技術原因。您的特定合規、法規或組織安全需求可能需要特定的服務組態。或者，您可能會有來自 AWS Partner Network 或您所建置和管理之自訂應用程式的產品功能偏好設定 AWS 服務，而不是使用 。有時候，在此檢閱期間，您可能會發現您先前的決策是根據不再適用的舊技術、 AWS 功能或業務限制條件所做出。這是檢閱、排定任何更新的優先順序，並將其新增至您工程待處理項目適當位置的好機會。無論您在根據 AWS SRA 評估安全架構時發現什麼，都會發現記錄該分析很有價值。擁有決策及其理由的歷史記錄，有助於通知並排定未來決策的優先順序。
+ *引導*您實作自己的安全架構。

   AWS SRA 基礎設施即程式碼 (IaC) 模組提供快速、可靠的方法來開始建置和實作您的安全架構。這些模組在[程式碼儲存庫](code-repo.md)區段和[公有 GitHub 儲存庫](https://github.com/aws-samples/aws-security-reference-architecture-examples)中有更深入的說明。它們不僅讓工程師能夠根據 AWS SRA 指南中模式的高品質範例建置，還包含建議的安全控制，例如 IAM 密碼政策、Amazon Simple Storage Service (Amazon S3) 封鎖帳戶公開存取、Amazon EC2 預設 Amazon Elastic Block Store (Amazon EBS) 加密，以及與 的整合， AWS Control Tower 以便在新 AWS 帳戶 加入或取消委任時套用或移除控制項。
+ ** 進一步了解 AWS 安全服務和功能。

   AWS SRA 中的指導和討論包括重要功能，以及個別 AWS 安全和安全相關服務的部署和管理考量。 AWS SRA 的一項功能是提供安全 AWS 服務廣度的高階介紹，以及它們如何在多帳戶環境中一起運作。這補充了深入了解在其他來源中找到的每個服務的功能和組態。其中一個範例是[討論](security-tooling.md#tool-security-hub) AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM) 如何從各種 AWS 服務、 AWS Partner 產品，甚至是您自己的應用程式擷取安全調查結果。
+ *推動*組織治理和安全責任的討論。

  設計和實作任何安全架構或策略的一個重要元素是了解組織中的哪些人員具有與安全相關的責任。例如，彙整和監控安全調查結果的問題，與負責該活動團隊的問題有關。整個組織的所有調查結果是否由需要存取專用安全工具帳戶的中央團隊監控？ 或者，個別應用程式團隊 （或業務單位） 是否負責特定監控活動，因此需要存取特定提醒和監控工具？ 另一個範例是，如果您的組織有一個集中管理所有加密金鑰的群組，這會影響誰具有建立 AWS Key Management Service (AWS KMS) 金鑰的許可，以及這些金鑰將管理的帳戶。了解組織的特性 ― 各種團隊和責任 ― 將協助您量身打造最適合需求的 AWS SRA。相反地，有時安全架構的討論會成為討論現有組織責任和考慮潛在變更的動力。 AWS 建議一項分散式決策程序，其中工作負載團隊負責根據其工作負載函數和需求定義安全控制。集中式安全與控管團隊的目標是建置系統，讓工作負載擁有者能夠做出明智的決策，並讓各方都能了解組態、問題清單和事件。 AWS SRA 可以是識別和通知這些討論的工具。

## AWS SRA 的關鍵實作準則
<a name="key-guidelines"></a>

以下是 AWS SRA 的八個關鍵要點，供您在設計和實作安全性時謹記。  
+ AWS Organizations 和適當的多帳戶策略是您安全架構的必要元素。適當地分隔工作負載、團隊和函數，為職責分離和defense-in-depth策略提供了基礎。本指南在[稍後的章節](account-structure.md)中進一步介紹了這一點。
+ Defense-in-depth是為您的組織選擇安全控制的重要設計考量。它可協助您在 AWS Organizations 結構的不同層注入適當的安全控制，這有助於將問題的影響降至最低：如果一個層存在問題，則存在隔離其他寶貴 IT 資源的控制。 AWS SRA 會示範 AWS 技術堆疊不同層的不同 AWS 服務 函數如何運作，以及結合使用這些服務如何協助您達成defense-in-depth。[稍後章節](security-services.md) AWS 會進一步討論 的defense-in-depth概念，其中包含[應用程式帳戶](application.md)下顯示的設計範例。
+ 跨多個 AWS 服務 和 功能使用各種安全建置區塊，以建置強大且具彈性的雲端基礎設施。根據您的特定需求量身打造 AWS SRA 時，不僅要考慮 AWS 服務 和 功能的主要函數 （例如，身分驗證、加密、監控、許可政策），還要考慮它們如何符合您架構的結構。本指南稍後的[章節](security-services.md#orgwide)說明一些 服務如何在整個 AWS 組織中運作。其他服務在單一 帳戶中運作最佳，有些服務旨在授予或拒絕個別委託人的許可。考慮這兩個觀點，可協助您建置更靈活、分層的安全方法。
+ 在可能的情況下 （如後續章節所述），請利用 AWS 服務 來部署在每個帳戶中 （分散而非集中），並建置一組一致的共用護欄，以協助保護您的工作負載免於誤用，並協助降低安全事件的影響。 AWS SRA 使用 AWS Security Hub CSPM （集中調查結果監控和合規檢查）、Amazon GuardDuty （威脅偵測和異常偵測）、 AWS Config （資源監控和變更偵測）、IAM Access Analyzer （資源存取監控）、 AWS CloudTrail （在整個環境中記錄服務 API 活動） 和 Amazon Macie （資料分類） 作為 AWS 服務 要部署在每個 的基礎集合 AWS 帳戶。
+ 使用 AWS Organizations受支援之 的委派管理功能，如本指南稍後[委派管理](security-tooling.md#tool-delegated-admin)一節所述。這可讓您將 AWS 成員帳戶註冊為受支援服務的管理員。委派的管理為企業內不同團隊提供彈性，以根據其責任使用不同的帳戶，來管理 AWS 服務 整個環境。此外，使用委派管理員可協助您限制對 AWS Organizations 管理帳戶的存取和管理許可額外負荷。
+ 在您的 AWS 組織中實作集中式監控、管理和控管。透過使用 AWS 服務 支援多帳戶 （有時是多區域） 彙總，以及委派的管理功能，您可以讓您的中央安全、網路和雲端工程團隊能夠廣泛地了解和控制適當的安全組態和資料收集。此外，資料可以提供給工作負載團隊，讓他們能夠在軟體開發生命週期 (SDLC) 的早期做出有效的安全決策。
+ 使用 透過實作預先建置的安全控制 AWS Control Tower 來設定和控管您的多帳戶 AWS 環境，以引導您的安全參考架構建置。 AWS Control Tower 提供藍圖，以提供身分管理、帳戶聯合存取、集中式記錄，以及用於佈建其他帳戶的已定義工作流程。然後，您可以使用 [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 解決方案，透過 AWS Control Tower 額外的安全控制、服務組態和控管來基準化 管理的帳戶，如 AWS SRA 程式碼儲存庫所示。帳戶工廠功能會根據核准的帳戶組態，自動佈建具有可設定範本的新帳戶，以標準化 AWS 組織內的帳戶。您也可以將其 AWS 帳戶 註冊到已受 管理的組織單位 (OU)，將控管擴展到現有的個別 AWS Control Tower。
+  AWS SRA 程式碼範例示範如何使用基礎設施做為程式碼 (IaC)，自動化 AWS SRA 指南中的模式實作。透過編纂模式，您可以將 IaC 視為組織中的其他應用程式，並在部署程式碼之前自動化測試。IaC 也透過在多個 （例如 SDLC 或區域特定） 環境中部署護欄，協助確保一致性和可重複性。SRA 程式碼範例可以部署在 AWS Organizations 多帳戶環境中，無論是否有 AWS Control Tower。此儲存庫中需要 的解決方案 AWS Control Tower 已在AWS Control Tower環境中使用 AWS CloudFormation和 [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 部署和測試。不需要 的解決方案 AWS Control Tower 已在AWS Organizations環境中使用 進行測試AWS CloudFormation。如果您不使用 AWS Control Tower，則可以使用 [AWS Organizations型部署](https://github.com/aws-samples/aws-security-reference-architecture-examples#getting-started-using-aws-sra-in-aws-organizations-environments)解決方案。