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

# 爬蟲階段：規劃、建置和評估
<a name="crawl"></a>



![\[爬蟲人員的圖示\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/crawl.png)


爬蟲階段從規劃開始。規劃涉及確定安全範圍，並選擇最適合您組織的模型。建立計畫後，您可以開始建立基礎。接著評估您目前的安全狀態，並在您建置安全基礎設施後立即設定紀律。爬蟲階段是反覆的。雲端中的反覆運算比內部部署環境中的反覆運算更快。隨著雲端功能的成熟，反覆運算的程序會加速。

以下是爬蟲階段中的階段：
+ [計畫](plan.md) – 如何找出您的範圍並選取模型？
+ [建置](build.md) – 您要如何建立架構？
+ [評估](assess.md) – 您目前的安全狀態為何？

# 計劃：建立您的安全範圍和模型
<a name="plan"></a>

規劃是在您成熟安全模型時的反覆程序。規劃程序中的關鍵步驟包括：
+ [了解安全範圍](understanding-the-security-scope.md) – 安全範圍會有所不同，取決於雲端的使用方式。
+ [選擇安全模型](choosing-a-security-model.md) – 識別最適合您安全使用案例的安全模型。
+ [建立業務目標模型](creating-a-business-objective-model.md) – 定義明確的目標和機制以衡量成功。

當您制定計畫時，請考慮下列事項：
+ 願意反覆運算。雲端中的反覆運算是固定的。反覆運算可協助您識別計劃中的差距。
+ 請勿從 服務開始。從計畫開始，而不是挑選您需要的服務。這有助於推動您的組織實現其預期成果。

# 了解安全範圍
<a name="understanding-the-security-scope"></a>

 AWS 共同責任模型會定義您與 共同 AWS 承擔雲端安全與合規責任的方式。 會 AWS 保護執行 中提供之所有服務的基礎設施 AWS 雲端，而且您需負責保護對這些服務的使用，例如您的資料和應用程式。

此共用模型有助於減輕您的合規和操作負擔，因為 會 AWS 操作、管理和控制許多元件，從主機作業系統和虛擬化層，到服務操作所在設施的實體安全性。受管服務可讓您 AWS 管理一些安全任務，例如修補和漏洞管理，以協助您降低安全性和合規義務。[AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a4.html) 中的最佳實務是使用 受管服務。一般而言，隨著基礎設施的現代化，更多的責任會轉移到服務供應商。

以下是三種不同的服務範例，可協助您了解安全範圍如何根據您選擇的服務而變更：
+ [基礎設施服務](#infrastructure-services)
+ [容器服務](#container-services)
+ [無伺服器服務](#serverless-services)

您對安全的責任不是靜態的，而且會隨著您選擇的架構類型而改變。您的時間、精力和成本會受到您選擇的雲端架構影響。

## 基礎設施服務
<a name="infrastructure-services"></a>

對於基礎設施服務， AWS 專注於保護基礎基礎設施。在基礎設施服務中，客戶的範圍更大，因為與其他模型相比，他們需要解決平台安全性、作業系統修補和應用程式管理的問題。Amazon Elastic Compute Cloud (Amazon EC2) 是常見基礎設施服務的範例。



![\[AWS 基礎設施服務的共同責任模型。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-shared-responsibility-model-infrastructure-services.png)


## 容器服務
<a name="container-services"></a>

隨著基礎設施的抽象化和現代化，足跡也會變小。您的範圍會縮小，因為某些安全元素的責任會轉移為 AWS。容器服務是一些後端責任轉移回的範例 AWS。例如， AWS 負責作業系統 (OS) 組態、網路組態、平台管理和應用程式管理。常見容器服務的範例包括 Amazon Elastic Kubernetes Service (Amazon EKS)、Amazon Elastic Container Registry (Amazon ECR)、Amazon Elastic Container Service (Amazon ECS) 和 AWS Fargate。



![\[AWS 容器服務的共同責任模型。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-shared-responsibility-model-container-services.png)


## 無伺服器服務
<a name="serverless-services"></a>

使用無伺服器服務時，幾乎所有的安全責任都屬於其中 AWS。您的責任範圍很小。例如，受管無伺服器資料庫 (DB) 不需要保護網路、硬體和作業系統。涵蓋所有作業系統和資料庫修補 AWS。您唯一的考量是透過加密和身分驗證來保護對資料的存取。



![\[AWS 無伺服器服務的共同責任模型。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-shared-responsibility-model-serverless-services.png)


# 選擇安全模型
<a name="choosing-a-security-model"></a>

您可以從各種安全模型或方法中進行選擇 AWS。方法的選擇和最適合的模型取決於您的受眾、目標業務成果和整體業務流程。您可以使用多個模型的混合。

**Topics**
+ [架構模型](#architectural-model)
+ [成熟度模型](#maturity-model)
+ [控管模型](#governance-model)

每個模型都有自己的一組優點和缺點。請務必考慮哪種方法最適合您的組織。在現代化基礎設施和採用雲端策略的過程中，儘早讓安全專業人員參與其中。您選擇的模型會對組織中的角色和責任產生重大影響。

## 架構模型
<a name="architectural-model"></a>

下圖顯示 [AWS 安全參考架構](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html)。這種架構方法為安全模型提供了藍圖。當您與組織內的技術團隊互動時，此方法最適合您。它有助於設定 理想的未來狀態目標。它也符合許多合規和 AWS 架構。



![\[AWS 安全參考架構的架構圖\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/aws-sra-architecture.png)


**架構模型的優點：**
+ 符合健康保險流通與責任法案 (HIPAA) 和健康資訊信任聯盟共同安全架構 (HITRUST CSF) 要求
+ 提供架構觀點
+ 符合大型企業的雲端策略和指引
+ 與[AWS 雲端採用架構 (AWS CAF) ](https://aws.amazon.com/cloud-adoption-framework/)保持一致
+ 與 [AWS Well-Architected 架構](https://aws.amazon.com/architecture/well-architected/)保持一致

**架構模型的缺點：**
+ 以技術為中心，而不是以業務為中心

## 成熟度模型
<a name="maturity-model"></a>

[AWS 安全成熟度模型](https://maturitymodel.security.aws.dev/en/model/)方法著重於透過優先實作安全措施來管理和降低風險。這種方法非常適合安全主管和 CISOs，但不是以業務為中心。

**成熟度模型的優點：**
+ 以安全為重心
+ 是一種專注於使用敏捷型實作方法的模型
+ 協助您快速降低風險
+ 與[AWS 雲端採用架構 (AWS CAF) ](https://aws.amazon.com/cloud-adoption-framework/)保持一致

**成熟度模型的缺點：**
+ 以技術為中心，而不是以業務為中心

## 控管模型
<a name="governance-model"></a>

[Cloud Foundation on AWS](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/capabilities.html) Model 使用控管、風險管理和合規 (GRC) 方法來協助組織滿足安全和合規要求。它定義您的雲端環境應遵循的整體政策。此模型中的功能可協助您定義動作項目、定義您的風險偏好，以及調整內部政策。



![\[Cloud Foundation on AWS governance 模型的各個層面。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/governance-model.png)


Cloud Foundation 模型是一種功能和控管指南，可協助您建置和發展您的 AWS 雲端 環境。它以一組定義、案例、指引和自動化為基礎。本指南包含建立環境 AWS 雲端 的人員、程序和技術層面。它涵蓋雲端基礎所需的六個功能類別：
+ 控管、風險管理和合規
+ 作業
+ 安全
+ 業務持續性
+ 財務
+ 基礎設施

本指南也提供每個功能的範例、時間表和進一步閱讀。

**控管模型的優點：**
+ 具有廣泛的技術焦點
+ 專為可靠性而設計
+ 使用操作方法

**控管模型的缺點：**
+ 以技術為中心，而不是以業務為中心

# 建立業務目標模型
<a name="creating-a-business-objective-model"></a>

業務目標模型涉及定義業務成果。它類似於 AWS 雲端採用架構和 AWS Well-Architected 架構。這種方法著重於透過解讀目標業務成果來了解業務感興趣的內容。這種方法的價值在於，將業務目標與安全目標輕鬆關聯。業務目標的一個範例是「啟用安全外部連線並加速佈建新使用者和環境，方法是自動化可見性和根據最佳實務測量以持續降低風險。」  您可以建立技術目標，協助您達成對應的業務成果。業務目標模型與安全目標相關聯，例如維持可見性。然後，您實作技術目標，例如 AWS Identity and Access Management (IAM) 安全最佳實務，以降低安全風險。

**業務目標方法的優點：**
+ 包含成本對正
+ 提供清晰且符合業務的安全方向
+ 透過實現目標業務成果來定義成功指標

**業務目標方法的缺點：**
+ 可能很耗時，因為您必須了解企業想要什麼
+ 以業務為中心，而不是以技術為中心

# 組建：奠定穩固雲端安全基礎的基礎
<a name="build"></a>

現在您已有計劃，下一個步驟是鋪設基礎。此步驟示範如何在 AWS 跨多個帳戶的安全、彈性、可擴展和自動化基礎上建立初始雲端基礎。根據您的業務目標，可以專門設計和自訂基礎。您可以根據新的登陸區域調整控制項，也可以將其包含在現有的登陸區域中。中的自動化[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)可協助您在 中鋪設安全基礎 AWS 雲端。下圖顯示透過 設定的登陸區域 AWS Control Tower。



![\[使用 建置初始雲端基礎 AWS Control Tower\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-accelerating-security-maturity/images/control-tower-landing-zone.png)


AWS Control Tower AWS 服務 代表您協調多個 ，例如 AWS Organizations AWS Service Catalog和 AWS IAM Identity Center。您可以在一小時內設定新的登陸區域，該登陸區域旨在滿足您的安全和合規要求。 AWS Control Tower 會根據規範性安全最佳實務來設定您的登陸區域。 AWS Control Tower 透過增強對帳戶和最終使用者的可見性和控制，協助您管理雲端佈建。它可協助管理員有效率地配置和監督運算資源、實作角色型存取控制、透過記錄和監控工具來監控效能、有效管理成本、自動化部署程序、強制執行安全措施，並確保符合業界標準。

AWS Control Tower 根據最佳實務， 是設定和管理安全、合規、多帳戶 AWS 環境的最快方法。如需使用 的詳細資訊， AWS Control Tower 以及 AWS 多帳戶策略中概述的最佳實務，請參閱[AWS 多帳戶策略：最佳實務指引](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html#multi-account-guidance)。

雖然 AWS Control Tower 是最快的方法，但不是唯一的方法。重要部分是您設定至少提供下列項目的登陸區域：
+ 多帳戶管理
+ 身分和聯合存取管理
+ 日誌的集中式封存
+ 跨帳戶稽核存取權
+ 最終使用者帳戶佈建
+ 集中式監控和通知

# 評估：評估您目前的雲端安全狀態
<a name="assess"></a>

在您將任何項目部署到登陸區域之前，請評估您的登陸區域，以確保其符合您的需求並建立基準。此實務稱為*雲端狀態評估*。它可協助您識別和修復整個雲端基礎設施的風險。評估您的雲端安全狀態可讓您了解雲端環境中的相關安全控制。

以下是雲端狀態評估的優點：
+ 它可協助您了解目前的安全狀態，並取得建議，以減少您的風險設定檔、修復現有的漏洞，或修正設定錯誤。
+ 它可協助您識別安全最佳實務，以避免失誤並降低業務風險。
+ 它提供的指標可協助您追蹤改進並衡量成功。

本節會檢閱服務和工具， AWS Security Hub CSPM 以及 Prowler，您可以用來在環境中執行雲端狀態評估。

## Prowler
<a name="prowler"></a>

[https://github.com/prowler-cloud/prowler/#requirements-and-installation](https://github.com/prowler-cloud/prowler/#requirements-and-installation) 是一種開放原始碼命令列工具，可協助您評估、稽核和監控您的帳戶是否符合 AWS 安全最佳實務和其他安全架構和標準。它會檢查您的組態並識別安全問題。您可以在Prowler多帳戶環境中使用 ，而第三方供應商也可以使用它來評估 AWS 環境的安全性。

以下是 的優點Prowler：
+ 它是免費的開放原始碼。
+ 它具有靈活的部署選項，並且可擴展。
+ 它會執行合規檢查，例如 [的網際網路安全中心 (CIS) 基準 AWS](https://www.cisecurity.org/benchmark/amazon_web_services)、一般資料保護法規 (GDPR) 和 HIPAA。
+ 它可協助您建立快照和基準。

## AWS Security Hub CSPM
<a name="as-hlong"></a>

[AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 提供 中安全狀態的完整檢視 AWS。它還可協助您根據安全產業標準和最佳實務來檢查環境。它與 整合， AWS Control Tower 因此您可以透過 AWS Control Tower 服務設定 Security Hub CSPM 偵測控制。加速安全成熟度的目標是將評估程序從一次性快照成熟為持續監控進度的程序。

以下是 Security Hub CSPM 的優點：
+ 它提供統一的儀表板，可顯示環境的目前狀態，並協助您識別和修復問題。
+ 它使用自動檢查執行持續評估。