本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 建置您的安全架構 – 分階段方法
| |
| --- |
| 進行[簡短的問卷](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)，以影響 AWS 安全參考架構 (AWS SRA) 的未來。 |
AWS SRA 建議的多帳戶安全架構是一種基準架構，可協助您儘早將安全注入設計程序中。每個組織的雲端旅程都是獨一無二的。若要成功 發展您的雲端安全架構，您需要規劃所需的目標狀態、了解目前的雲端準備程度，並採用敏捷的方法來消除任何差距。 AWS SRA 為您的安全架構提供參考目標狀態。逐步轉換可讓您快速示範值，同時將進行遙遠預測的需求降到最低。
[AWS 雲端採用架構](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/welcome.html) (AWS CAF) 建議四個疊代和增量雲端轉換階段： [設想、對齊、啟動和擴展](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/your-cloud-transformation-journey.html)。當您進入啟動階段並專注於在生產環境中交付試行計劃時，您應該專注於建置強大的安全架構作為擴展階段的基礎，以便您能夠放心地遷移和操作最關鍵業務的工作負載。如果您是新創公司、想要擴展業務的小型或中型公司，或是正在取得新業務單位或正在進行合併和收購的企業，則適用此分階段方法。 AWS SRA 可協助您實現該安全基準架構，以便您可以在 中擴展的組織之間統一套用安全控制 AWS Organizations。基準架構包含多個 AWS 帳戶 和 服務。規劃和實作應該是一個多階段程序，讓您可以反覆執行較小的里程碑，以達到設定基準安全架構的更大目標。本節說明以結構化方法為基礎的雲端旅程典型階段。這些階段符合 [AWS Well-Architected Framework 安全設計原則](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html)。
## 階段 1：建置您的 OU 和帳戶結構
強大安全基礎的先決條件是設計良好的 AWS 組織和帳戶結構。如本指南先前 [SRA 建置區塊](organizations.md)一節所述，擁有多個 AWS 帳戶 可協助您透過設計隔離不同的業務和安全功能。這看起來像是一開始不必要的工作，但這是一項投資，可協助您快速且安全地擴展。本節也說明如何使用 AWS Organizations 來管理多個 AWS 帳戶，以及如何使用信任存取和委派管理員功能來集中 AWS 服務 管理這些多個帳戶。
您可以使用本指南前面[AWS Control Tower](org-management.md#mgmt-tower)所述的 來協調您的登陸區域。如果您目前正在使用單一 AWS 帳戶，請參閱 [轉換為多個 AWS 帳戶](https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/welcome.html) 指南，以盡早遷移到多個帳戶。例如，如果您的新創公司目前在單一 中構想和原型設計產品 AWS 帳戶，您應該考慮在市場上啟動產品之前採用多帳戶策略。同樣地，小型、中型和企業組織應在規劃初始生產工作負載後立即開始建置其多帳戶策略。從基礎 OUs和 開始 AWS 帳戶，然後新增與工作負載相關的 OUs和帳戶。
如需 SRA 所提供的 AWS AWS 帳戶 和 OU 結構建議，請參閱 [中小型企業的多帳戶策略](https://aws.amazon.com/blogs/mt/multi-account-strategy-for-small-and-medium-businesses/) 部落格文章。當您完成 OU 和帳戶結構時，請考慮使用服務控制政策 (SCPs)、資源控制政策 (RCPs) 和宣告政策來強制執行的高階全組織安全控制。
**設計考量事項**
當您設計 OU 和帳戶結構時，請勿複寫公司的報告結構。您的 OUs 應以工作負載函數和一組適用於工作負載的常見安全控制為基礎。請勿嘗試從頭開始設計完整的帳戶結構。專注於基礎 OUs，然後視需要新增工作負載 OUs。您可以在 [OUs 之間移動帳戶](https://docs.aws.amazon.com/organizations/latest/userguide/move_account_to_ou.html)，以便在設計的早期階段嘗試替代方法。不過，這可能會導致管理邏輯許可的一些額外負荷，取決於以 OU 和帳戶路徑為基礎的 SCPs、RCPs、宣告政策和 IAM 條件。
**實作範例**
[AWS SRA 程式碼庫](https://github.com/aws-samples/aws-security-reference-architecture-examples)提供[帳戶替代聯絡人](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/account/account_alternate_contacts)的範例實作。此解決方案會 設定組織內所有帳戶的帳單、操作和安全替代聯絡人。
## 階段 2：實作強大的身分基礎
建立多個 之後 AWS 帳戶，您應該讓團隊存取這些帳戶中 AWS 的資源。身分管理有兩種一般類別：[人力資源身分和存取管理](https://aws.amazon.com/identity/workforce-identities/)，以及[客戶身分和存取管理](https://aws.amazon.com/identity/customer-identities/) (CIAM)。Workforce IAM 適用於員工和自動化工作負載需要登入 AWS 才能執行其任務的組織。當組織需要一種方法來驗證使用者，以提供組織應用程式的存取權時，會使用 CIAM。首先您需要人力 IAM 策略，讓您的團隊可以建置和遷移應用程式。您應該一律使用 IAM 角色，而不是 IAM 使用者來提供人類或機器使用者的存取權。遵循 AWS SRA 指引，了解如何 AWS IAM Identity Center 在[組織管理和](org-management.md#mgmt-sso)[共用服務](shared-services.md#shared-sso)帳戶中使用 ，以集中管理對 的單一登入 (SSO) 存取 AWS 帳戶。當您無法使用 IAM Identity Center 時，本指南也提供使用 IAM 聯合的設計考量。
當您使用 IAM 角色來提供使用者對 AWS 資源的存取權時，您應該使用 IAM Access Analyzer 和 IAM 存取顧問，如本指南[的安全工具](security-tooling.md)與[組織管理](org-management.md)章節所述。這些服務可協助您實現最低權限，這是重要的預防性控制，可協助您建立良好的安全狀態。
**設計考量事項**
為了實現最低權限，請設計程序來定期檢閱和了解您的身分與其正常運作所需的許可之間的關係。當您學習時，請微調這些許可，並逐步將其縮減為盡可能最少的許可。為了可擴展性，這應該是您中央安全與應用程式團隊之間的共同責任。使用 [資源型政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)、 [許可界限](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)、 [屬性型存取控制](https://www.youtube.com/watch?v=Iq_hDc385t4&t=1318s) 和 [工作階段政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) 等功能，協助應用程式擁有者定義精細存取控制。
**實作範例**
[AWS SRA 程式碼庫](https://github.com/aws-samples/aws-security-reference-architecture-examples)提供兩個適用於此階段的範例實作：
[IAM 密碼政策](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/iam/iam_password_policy)會設定帳戶密碼政策，讓使用者符合常見的合規標準。
[Access Analyzer](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/iam/iam_access_analyzer) 會設定委派管理員帳戶內的組織層級分析器，以及每個帳戶內的帳戶層級分析器。
## 階段 3：維持可追蹤性
當您的使用者可以存取 AWS 並開始建置時，您會想要知道誰正在執行什麼操作、何時執行和從何處執行。您也需要了解潛在的安全錯誤組態、威脅或意外行為。更了解安全威脅可讓您優先考慮適當的安全控制。若要監控 AWS 活動，請遵循 AWS SRA 建議，透過在 [Log Archive](log-archive.md) 帳戶中使用[AWS CloudTrail](security-tooling.md#tool-cloudtrail)並集中日誌來設定組織線索。針對安全事件監控，請使用 AWS Config、Amazon GuardDuty AWS Security Hub CSPM和 Amazon Security Lake，如[安全工具帳戶](security-tooling.md)一節中所述。
**設計考量事項**
當您開始使用新的 時 AWS 服務，請務必為服務啟用 [服務特定的日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) ，並將其儲存為中央日誌儲存庫的一部分。
**實作範例**
[AWS SRA 程式碼庫](https://github.com/aws-samples/aws-security-reference-architecture-examples)提供適用於此階段的下列範例實作：
[Organization CloudTrail](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/cloudtrail/cloudtrail_org) 會建立組織追蹤，並設定預設值來設定資料事件 （例如，在 Amazon S3 和 中 AWS Lambda)，以減少由 設定的 CloudTrail 重複 AWS Control Tower。此解決方案提供設定管理事件的選項。
[AWS Config Control Tower 管理帳戶](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/config/config_management_account) 可讓 管理帳戶中 AWS Config 的 監控資源合規。
[一致性套件組織規則](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/config/config_conformance_pack_org)會將一致性套件部署到組織內的帳戶和指定區域。
[AWS Config 彙整工具](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/config/config_aggregator_org) 透過將管理委派給稽核帳戶以外的成員帳戶來部署彙整工具。
[Security Hub CSPM Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/securityhub/securityhub_org) 在委派管理員帳戶中設定 Security Hub CSPM，用於帳戶和組織內受管區域。
[GuardDuty Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/guardduty/guardduty_org) 在組織的委派管理員帳戶中設定 GuardDuty。
## 階段 4：在所有層套用安全性
此時，您應該有：
+ 適用於您的 的安全控制 AWS 帳戶。
+ 定義明確的帳戶和 OU 結構，具有透過 SCPs、RCPs、宣告政策和最低權限 IAM 角色和政策定義的預防性控制。
+ 能夠使用 記錄 AWS 活動 AWS CloudTrail；使用 AWS Security Hub CSPM、Amazon GuardDuty 和 偵測安全事件 AWS Config；以及使用 Amazon Security Lake 在專用資料湖上執行進階分析以確保安全。
在此階段中，計劃在 AWS 組織的其他層套用安全性，如 [在 AWS 組織中套用安全性服務](security-services.md)一節中所述。您可以使用網路 [帳戶](network.md)區段中所述的服務，例如 AWS WAF AWS Shield、 AWS Firewall Manager、 AWS Network Firewall AWS Certificate Manager (ACM)、Amazon CloudFront、Amazon Route 53 和 Amazon VPC，來建置網路層的安全控制。當您向下移動技術堆疊時，請套用工作負載或應用程式堆疊專屬的安全控制。如[應用程式帳戶](application.md) 一節所述，使用 VPC 端點 AWS Systems Manager、Amazon Inspector AWS Secrets Manager和 Amazon Cognito。
**設計考量事項**
當您設計深度防禦 (DiD) 安全控制時，請考慮擴展因素。您的中央安全團隊將無法擁有頻寬或完全了解每個應用程式在環境中的行為。讓您的應用程式團隊能夠負責識別和設計其應用程式的適當安全控制。中央安全團隊應專注於提供適當的工具和諮詢，以啟用應用程式團隊。若要了解 用來 AWS 採用更左移安全方法的擴展機制，請參閱部落格文章 [如何 AWS 建置 Security Guardians 程式，這是一種分配安全擁有權的機制](https://aws.amazon.com/blogs/security/how-aws-built-the-security-guardians-program-a-mechanism-to-distribute-security-ownership/)。
**實作範例**
[AWS SRA 程式碼庫](https://github.com/aws-samples/aws-security-reference-architecture-examples)提供適用於此階段的下列範例實作：
[EC2 預設 EBS 加密](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/ec2/ec2_default_ebs_encryption) 會將 Amazon EC2 中的預設 Amazon EBS 加密設定為在提供的 AWS KMS key 中使用預設值 AWS 區域。
[S3 封鎖帳戶公開存取](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/s3/s3_block_account_public_access) 會為組織內的帳戶設定 Amazon S3 中的帳戶層級封鎖公開存取 (BPA) 設定。
[Firewall Manager](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/firewall_manager/firewall_manager_org) 示範如何為組織內的帳戶設定安全群組政策和 AWS WAF 政策。
[Inspector Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/inspector/inspector_org) 會在委派的管理員帳戶中設定 Amazon Inspector，用於組織內的帳戶和受管區域。
## 階段 5：保護傳輸中和靜態的資料
您的業務和客戶資料是您需要保護的寶貴資產。 AWS 提供各種安全服務和功能，以保護動態和靜態資料。如 [網路帳戶](network.md) 一節所述 AWS Certificate Manager，使用 Amazon CloudFront 搭配 來保護透過網際網路收集的動態資料。對於內部網路內動態中的資料，請使用 Application Load Balancer AWS 私有憑證授權單位，如 [應用程式帳戶](application.md)一節所述。 AWS KMS 和 AWS CloudHSM 可協助您提供密碼編譯金鑰管理，以保護靜態資料。
## 階段 6：準備安全事件
當您操作 IT 環境時，將會遇到安全事件，這是 IT 環境日常操作的變更，表示可能違反安全政策或無法安全控制。適當的可追蹤性至關重要，以便您盡快知道安全事件。同樣重要的是，請準備好分類和回應此類安全事件，以便在安全事件升級之前採取適當動作。準備可協助您快速分類安全事件，以了解其潛在影響。
AWS SRA 透過設計 [安全工具帳戶](security-tooling.md) 和 [在所有範圍內部署常見的安全服務 AWS 帳戶，](security-tooling.md#tool-common)可讓您偵測整個 AWS 組織的安全事件。安全工具帳戶中的 [Amazon Detective](security-tooling.md#tool-detective) 可協助您分類安全事件並識別根本原因。在安全調查期間，您必須能夠檢閱相關日誌，以記錄並了解事件的完整範圍和時間表。當特定感興趣的動作發生時，產生警示也需要日誌。 AWS SRA 建議使用中央 [Log Archive 帳戶](log-archive.md) 來儲存所有安全性和操作日誌。您可以使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 查詢儲存在 CloudWatch 日誌群組中的資料，以及使用 [Amazon Athena](https://aws.amazon.com/athena/) 和 [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) 查詢儲存在 Amazon S3 中的資料。使用 Amazon Security Lake 自動集中來自 AWS 環境、軟體即服務 (SaaS) 提供者、內部部署和其他雲端提供者的安全資料。在安全工具帳戶或任何專用帳戶中[設定訂閱者](security-tooling.md#tool-security-lake)，如 AWS SRA 所述，以查詢這些日誌以進行調查。
[AWS 安全事件應變](https://aws.amazon.com/security-incident-response/) 可協助您自動化安全事件回應、調查和修復。它提供預先建置的手冊和工作流程，協助您快速一致地回應安全事件。啟用主動回應功能時，安全事件回應[會與 Security Hub CSPM 和 GuardDuty 整合](https://docs.aws.amazon.com/security-ir/latest/userguide/detect-and-analyze.html)，以便在偵測到安全調查結果時自動觸發回應工作流程。此服務可協助您將整個 AWS 組織的事件回應程序標準化並自動化。如果您需要其他協助，您可以開啟服務支援案例，以與客戶事件回應團隊 AWS (CIRT) 互動。
**設計考量**
您應該從雲端旅程的一開始就開始準備偵測和回應安全事件。為了更好地利用有限的資源，請將資料和業務關鍵性指派給您的 AWS 資源，以便在偵測到安全事件時，您可以根據涉及的資源關鍵性來排定分類和回應的優先順序。
如本節所述，建置雲端安全架構的階段本質上是循序的。不過，您不需要等待一個階段的完整完成，即可開始下一個階段。我們建議您採用反覆方法，開始平行處理多個階段，並在您發展雲端安全狀態時發展每個階段。隨著您經歷不同的階段，您的設計將會演進。請考慮根據您的特定需求，量身打造下圖所示的建議序列。
![\[建置雲端安全架構的循序和反覆階段。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/security-reference-architecture/images/sra-phases.png)
**實作範例**
[AWS SRA 程式碼庫](https://github.com/aws-samples/aws-security-reference-architecture-examples)提供** **** **[Detective Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/tree/main/aws_sra_examples/solutions/detective/detective_org) 的範例實作， 透過將管理委派給 帳戶 （例如，稽核或安全工具） 來自動啟用 Amazon Detective，並為現有和未來的 AWS Organizations 帳戶設定 Detective。