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

# 計劃：建立您的安全範圍和模型
<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) 安全最佳實務，以降低安全風險。

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

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