本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 重新解譯雲端的基本八項策略
以下是專為 Microsoft型網際網路連線網路設計的原始 Essential Eight 緩解策略：
+ 應用程式控制
+ 修補程式應用程式
+ 設定Microsoft Office巨集設定
+ 使用者應用程式強化
+ 限制管理權限
+ 修補程式作業系統
+ 多重要素驗證
+ 定期備份
請務必重申 Essential Eight 架構並非針對雲端環境而設計。不過，基礎原則適用，Essential Eight 策略和 AWS Well-Architected Framework 最佳實務之間存在重疊。
各種雲端原生方法可以改善安全性，並大幅降低您的合規負擔。在內部部署環境中，您必須負責所有層面的安全，而且沒有繼承的控制項。在雲端執行工作負載時， AWS 負責保護執行我們服務的基礎設施。您也可以使用自動化和受管服務來減輕合規負擔。*受管服務*也稱為*抽象服務*，其 AWS 服務 可 AWS 操作基礎設施層、作業系統和平台，而且您可以存取端點來存放和擷取資料。Amazon Simple Storage Service (Amazon S3) 和 Amazon DynamoDB 是受管服務的範例。如需詳細資訊，請參閱本指南中的[主題 1：使用 受管服務](theme-1.md)一節。
因此，需要一些重新解譯才能使 Essential Eight 策略適用於其上的工作負載 AWS。本指南將 Essential Eight 策略轉換為 AWS *佈景主題*。
## 使用佈景主題
本指南分為八個主題。每個 Essential Eight 策略對應至下列一或多個主題，而每個主題對應至 AWS Well-Architected Framework 中的一或多個最佳實務：
+ [主題 1：使用 受管服務](theme-1.md)
+ [主題 2：透過安全管道管理不可變的基礎設施](theme-2.md)
+ [佈景主題 3：使用自動化管理可變基礎設施](theme-3.md)
+ [佈景主題 4：管理身分](theme-4.md)
+ [佈景主題 5：建立資料周邊](theme-5.md)
+ [主題 6：自動化備份](theme-6.md)
+ [佈景主題 7：集中記錄和監控](theme-7.md)
+ [佈景主題 8：實作手動程序的機制](theme-8.md)
每個主題都包含主題的概觀、相關的 AWS Well-Architected Framework 最佳實務，以及如何實現 Essential Eight 成熟度並監控合規性的說明。這些指示提供手動步驟，或使用 [AWS Config 規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)協助您設定自動化。手動步驟需要機制來確保問題清單已解決。如需詳細資訊，請參閱 [佈景主題 8：實作手動程序的機制](theme-8.md). AWS Config rules 需要類似的監督或自動化，以[修復不合規的資源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)。透過遵循與這些主題一致的指引，您可以使用同時將雲端優勢最大化的方法達到 Essential Eight 成熟度。
## 重新解譯雲端的基本八項策略
由於 Essential Eight 架構並非針對雲端環境而設計，因此在解決每個 Essential Eight 策略的基礎原則時，必須採取雲端原生方法。該方法取決於兩個關鍵問題。
### 您使用哪些 服務？
[AWS 共同責任模型](australian-sec-compliance.md#shared-model) 有助於減輕您的合規和操作負擔。受管服務會將更多責任轉移到 ， AWS 以維護已部署服務的可用性、效能和安全性最佳化。受管服務也會消除維護服務的營運和管理負擔，提供更多時間專注於創新。
受管服務包括無伺服器服務，例如 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、 和 [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html)。[Amazon Relational Database Service (Amazon RDS) ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)上的資料庫比 [Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/ec2/?icmpid=docs_homepage_compute) 上的資料庫需要較少的操作責任。
例如，如果您要為雲端調整*修補程式作業系統* Essential Eight 策略，您需要考慮正在使用哪些服務，以及是否負責修補這些資源。 AWS 負責修補完全受管的服務，例如 Lambda 和 DynamoDB。對於其他 服務，例如 Amazon RDS 或 [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html)，您可能需要在維護時段期間管理修補程式。
### 您使用哪種部署模型？
您的組織是否使用可變或不可變的基礎設施方法？
*可變基礎設施*模型會更新和修改生產工作負載的現有基礎設施。** **這是雲端之前的標準部署方法，當取代伺服器基礎設施非常昂貴且耗時，最實際的方法就是將變更套用至已在生產環境中的伺服器。雲端中可變方法的範例是將應用程式變更直接部署到執行中的 EC2 執行個體，無論是手動或使用 Run [AWS Systems Manager Command ](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html)或 等軟體部署服務[AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)。
*不可變的基礎設施*模型會為生產工作負載部署新的基礎設施，而不是更新、修補或修改現有的基礎設施。不可變方法的範例是在 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)或 中定義應用程式堆疊[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)。您可以使用這些服務，透過持續整合和持續交付 (CI/CD) 管道來部署應用程式堆疊。此方法使用[部署方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)，例如*滾動*或*藍/綠*。如需此方法的詳細資訊，請參閱 AWS Well-Architected Framework [中的使用不可變基礎設施的部署](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_immutable_infrastructure.html)最佳實務。
例如，如果您要針對雲端調整*修補程式作業系統* Essential Eight 策略，您需要考慮修補如何套用至部署模型。對於可變基礎設施，您可以手動修補資源，也可以透過自動化提高營運效率。如果您使用的是不可變的基礎設施，則會使用 CI/CD 管道來部署具有最新版本作業系統的新基礎設施。事實上，*修補*一詞是此模型下的誤判，因為基礎設施將被取代而不是修補。