建立您的安全架構 — 分階段式方法

通過進行簡短的調查來影響AWS安全參考架構（AWSSRA）的 future。

AWS SRA 建議的多帳戶安全架構是一種基準架構，可協助您儘早將安全性注入設計程序。每個組織的雲端旅程都是獨一無二的。為了成功發展您的雲端安全架構，您需要設想您想要的目標狀態、瞭解您目前的雲端準備程度，並採用敏捷的方法來消除任何差距。AWS SRA 為您的安全架構提供參考目標狀態。逐步轉換使您能夠快速展示價值，同時最大限度地減少進行深遠預測的需求。

AWS 雲端採用架構 (AWS CAF) 建議四個反覆和增量的雲端轉換階段：設想、調整、啟動和擴展。當您進入 Launch 階段並專注於提供生產環境中的試驗性計畫時，您應該專注於建置強大的安全性架構，做為 Scale 階段的基礎，讓您擁有自信地移轉和操作最重要的業務工作負載的技術能力。如果您是初創公司，想要擴展其業務的中小型公司，或正在收購新業務單位或正在進行併購的企業，則此分階段性方法適用。AWS SRA 可協助您實現該安全基準架構，以便您可以在 AWS Organizations 中不斷擴展的組織中統一套用安全控制。基準架構由多個 AWS 帳戶和服務組成。規劃和實施應該是一個多階段的過程，以便您可以迭代較小的里程碑，以達到設置基準安全性架構的更大目標。本節根據結構化方法描述雲端旅程的典型階段。這些階段符合 AWS Well-Architected Framework 安全設計原則。

階段 1：建立您的 OU 和帳戶結構

強大安全基礎的先決條件是設計良好的 AWS 組織和帳戶結構。如本指南的 SRA 建置區塊一節所述，擁有多個 AWS 帳戶可協助您根據設計隔離不同的業務和安全功能。一開始，這似乎是不必要的工作，但這是一項投資，可以幫助您快速安全地擴展。本節也說明如何使用 AWS Organization 管理多個 AWS 帳戶，以及如何使用受信任的存取和委派管理員功能，在這些多個帳戶中集中管理 AWS 服務。

您可以使用本指南先前所述的 AWS Control Tower 來協調您的 landing zone。如果您目前使用單一 AWS 帳戶，請參閱轉換至多個 AWS 帳戶指南，以儘早遷移到多個帳戶。例如，如果您的新創公司目前正在單一 AWS 帳戶中構思產品並製作原型，則在市場上推出產品之前，您應該考慮採用多帳戶策略。同樣地，小型、中型和企業組織應該在規劃初始生產工作負載後立即開始建立多帳戶策略。從您的基礎 OU 和 AWS 帳戶開始，然後新增與工作負載相關的 OU 和帳戶。

如需 AWS SRA 以外的 AWS 帳戶和 OU 結構建議，請參閱中小型企業的多帳戶策略部落格文章。當您完成 OU 和帳戶結構時，請考慮您想要使用服務控制原則 (SCP) 強制執行的高階、整個組織的安全性控制項。

設計考量

• 設計 OU 和帳戶結構時，請勿複製公司的報表結構。您的 OU 應以工作負載功能和套用至工作負載的一組通用安全性控制為基礎。不要嘗試從一開始就設計完整的帳戶結構。專注於基礎 OU，然後視需要新增工作負載 OU。您可以在 OU 之間移動帳戶，以便在設計的早期階段嘗試替代方法。但是，這可能會導致管理邏輯許可的一些額外負荷，具體取決於以 OU 和帳戶路徑為基礎的 SCP 和 IAM 條件。

實作範例

AWS SRA 程式碼程式庫提供帳戶替代聯絡人的範例實作。此解決方案會為組織內所有帳戶設定帳單、作業和安全性替代連絡人。

階段 2：實施強大的身分基礎

建立多個 AWS 帳戶後，您應該讓團隊存取這些帳戶中的 AWS 資源。身分識別管理有兩種一般類別：人力身分識別與存取管理，以及客戶身分識別與存取管理 (CIAM)。員工 IAM 適用於員工和自動化工作負載需要登入 AWS 才能完成工作的組織。當組織需要驗證使用者以提供對組織應用程式存取權的方式時，會使用 CIAM。您首先需要人力 IAM 策略，以便您的團隊可以建立和遷移應用程式。您應始終使用 IAM 角色而不是 IAM 使用者，以提供人類或機器使用者的存取權。遵循 AWS SRA 指導，瞭解如何在組織管理和共用服務帳戶中使用 AWS IAM 身分中心集中管理對 AWS 帳戶的單一登入 (SSO) 存取。當您無法使用 IAM 身分中心時，該指南還提供了使用 IAM 聯合的設計考量。

當您使用 IAM 角色提供使用者存取 AWS 資源時，應該使用 AWS IAM 存取分析器和 IAM 存取顧問，如本指南的安全工具和組織管理章節所述。這些服務可協助您達到最低權限，這是一項重要的預防性控制，可協助您建立良好的安全性狀態。

設計考量

• 若要達到最低權限，請設計程序以定期檢閱和瞭解身分識別與正常運作所需的權限之間的關係。當您學習時，請微調這些權限，並逐漸將它們縮小到盡可能少的權限。對於可擴展性，這應該是您的中央安全和應用程序團隊之間的共同責任。使用資源型原則、權限界限、屬性型存取控制和工作階段原則等功能，協助應用程式擁有者定義精細的存取控制。

實作範例

AWS SRA 程式碼程式庫提供兩個適用於此階段的範例實作：

• IAM 密碼政策為使用者設定帳戶密碼政策，以符合常見的合規標準。

• Access Analyzer 會在委派的系統管理員帳戶中設定組織層級分析器，以及每個帳戶內的帳戶層級分析器。

階段 3：保持可追溯性

當您的使用者可以存取 AWS 並開始建置時，您會想知道誰在做什麼、何時和從何處進行。您還需要查看潛在的安全錯誤配置，威脅或意外行為。更好地了解安全威脅可讓您優先考慮適當的安全控制。若要監控 AWS 活動，請遵循 AWS SRA 建議，以設定組織追蹤，方法是使用 AWS CloudTrail 並將日誌集中在日誌存檔帳戶中。對於安全事件監控，請使用 AWS Security Hub GuardDuty、亞馬遜、AWS Config 和 AWS 安全湖，如安全工具帳戶部分所述。

設計考量

• 開始使用新的 AWS 服務時，請務必為服務啟用特定服務的日誌，並將其存放為中央日誌存放庫的一部分。

實作範例

AWS SRA 程式碼程式庫提供下列適用於此階段的範例實作：

• 組織 CloudTrail會建立組織追蹤並設定預設值來設定資料事件 (例如，在 Amazon S3 和 AWS Lambda 中)，以減少 AWS Control Tower 所設定的重複。 CloudTrail 此解決方案提供設定管理事件的選項。

• AWS 組態 Control Tower 管理帳戶可讓管理帳戶中的 AWS Config 監控資源合規。

• 「符合性套件組織規則」會將一致性套件部署至組織內的帳號與指定區域。

• AWS Config 彙總工具會將管理委派給稽核帳戶以外的成員帳戶，藉此部署彙總工具。

• 安全性中樞組織會在委派的系統管理員帳戶中，針對組織內的帳戶和受控管的區域設定 Security Hub。

• GuardDuty 組織會針對組織 GuardDuty 內的帳戶，在委派的管理員帳戶中進行設定。

階段 4：在所有層級套用安全性

在這一點上，你應該有：

• 適用於 AWS 帳戶的適當安全控制。

• 明確定義的帳戶和 OU 結構，其中包含透過 SCP 和最低權限 IAM 角色和政策定義的預防性控制。

• 使用 AWS 記錄 AWS 活動的能力 CloudTrail；使用 AWS Security Hub、Amazon 和 AWS Config 偵測安全事件；以及使用 Amazon Security Lake 在專門建置的資料湖上執行進階分析 GuardDuty，以確保安全。

在此階段，計劃在 AWS 組織的其他層級套用安全性，如跨 AWS 組織套用安全服務一節所述。您可以使用 AWS WAF、AWS Shield、AWS Firewall Manager、AWS Network Firewall 管理員、AWS 網路防火牆、AWS Certificate Manager (ACM)、亞馬遜、亞馬遜 Amazon Route 53 和 Amazon CloudFront VPC 等服務，為您的聯網層建立安全控制，如網路帳戶部分所述。當您向下移動技術堆疊時，請套用特定於工作負載或應用程式堆疊的安全性控制。使用 VPC 端點、Amazon Inspector、亞馬遜 Systems Manager 器、AWS Secrets Manager 和 Amazon Cognito，如應用程式帳戶部分所述。

設計考量

• 當您深度設計防禦 (dID) 安全控制時，請考慮擴展因素。您的中央安全團隊不會有頻寬或完全瞭解每個應用程式在您的環境中的行為。讓您的應用程式團隊負責並負責識別和設計適合其應用程式的安全控制項。中央安全團隊應該專注於提供正確的工具和諮詢，以使應用團隊成為可能。若要了解 AWS 用來採用更左移的安全性方法的擴展機制，請參閱部落格文章 AWS 如何建置安全監護人計劃，這是一種分配安全擁有權的機制。

實作範例

AWS SRA 程式碼程式庫提供下列適用於此階段的範例實作：

• EC2 預設 EBS 加密可設定 Amazon EC2 中的預設亞馬遜 Elastic Block Store (Amazon EBS) 加密，以便在提供的 AWS 區域內使用預設 AWS KMS 金鑰。

• S3 區塊帳戶公開存取會針對組織內的帳戶設定 Amazon S3 中的帳戶層級區塊公開存取 (BPA) 設定。

• Firewall Manager 員示範如何為組織內的帳戶設定安全群組政策和 AWS WAF 政策。

• 檢查器組織會在委派的管理員帳戶中為組織內的帳戶和受管轄區域設定 Amazon Inspector。

階段 5：保護傳輸中和靜態資料

您的業務和客戶資料是您需要保護的寶貴資產。AWS 提供各種安全服務和功能來保護動態和靜態資料。如網路帳戶部分所述，將 AWS CloudFront 與 AWS Certificate Manager 搭配使用，以保護透過網際網路收集的動態資料。對於內部網路中移動的資料，請使用具有 AWS 私有憑證授權單位的 Application Load Balancer，如應用程式帳戶一節所述。AWS KMS 和 AWS CloudHSM 可協助您提供加密金鑰管理，以保護靜態資料。

階段 6：為安全事件做好準備

當您操作 IT 環境時，您將會遇到安全事件，這些事件是 IT 環境日常運作中的變化，表示可能違反安全政策或安全控制失敗。適當的可追溯性至關重要，因此您可以盡快瞭解安全性事件。同樣重要的是要準備分類和回應這類安全性事件，以便您可以在安全性事件升級之前採取適當的動作。準備工作可協助您快速分類安全性事件，以瞭解其潛在影響。

AWS SRA 透過安全工具帳戶的設計，以及在所有 AWS 帳戶中部署常見安全服務，讓您能夠偵測整個 AWS 組織的安全事件。安全工具帳戶中的 AWS Detective 可協助您分類安全事件並找出根本原因。在安全性調查期間，您必須能夠檢閱相關記錄檔，以便記錄並瞭解事件的完整範圍和時間表。當發生特定感興趣的動作時，也需要記錄檔才能產生警示。

AWS SRA 建議使用集中日誌存檔帳戶，用於所有安全和操作日誌的不可變儲存。您可以使用日CloudWatch 誌洞見查詢存放在日 CloudWatch 誌群組中的資料，使用 Amazon Athena 和 Amazon OpenSearch 服務查詢存放在 Amazon S3 中的資料。使用 Amazon Security Lake 自動集中來自 AWS 環境、軟體即服務 (SaaS) 供應商、內部部署和其他雲端供應商的安全資料。在安全工具帳戶或 AWS SRA 概述的任何專用帳戶中設定訂閱者，以查詢這些記錄以進行調查。

設計考量

• 您應該從雲端旅程的一開始就開始準備偵測和回應安全事件。為了更好地利用有限的資源，請為 AWS 資源指派資料和業務重要性，以便在偵測到安全事件時，您可以根據所涉及資源的重要性來排定分類和回應的優先順序。

• 如本節所述，建置雲端安全性架構的階段本質上是連續的。但是，在開始下一個階段之前，您不必等待一個階段的完整完成。我們建議您採用反覆的方法，在這裡您可以開始並行處理多個階段，parallel 隨著雲端安全性狀態的發展而發展每個階段。當您經歷不同的階段時，您的設計將會發展。考慮根據您的特定需求調整下圖中顯示的建議順序。

實作範例

AWS SRA 程式碼程式庫提供 Detective 組織的範例實作，透過將管理委派給帳戶 (例如稽核或安全工具) 來自動啟用 Detective，並為現有和 future 的 AWS Organizations 帳戶設定 Detective。