

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 重新解读云的八大要点策略
<a name="applying-e8-framework"></a>

以下是最初为基于 Microsoft 的互联网连接网络设计的八大要点缓解策略：
+ 应用程序控制
+ 修补应用程序
+ 配置 Microsoft Office 宏设置
+ 用户应用程序固化
+ 限制管理权限
+ 修补操作系统
+ 多重身份验证
+ 定期备份

需要再次强调的是，八大要点框架并非为云环境而设计。但是，基本原则是适用的，基本八大策略和Well-Architecte AWS d Framework最佳实践之间存在重叠之处。

各种云原生方法可以提高安全性并显著减轻您的合规负担。在本地环境中，您对安全的各个方面负责，并且不存在继承的控制措施。在云中运行工作负载 AWS 时，负责保护运行我们服务的基础架构。您还可以通过使用自动化和托管服务来减轻合规负担。*托管服务*，也称为*抽象服务*， AWS 服务 用于 AWS 运营基础设施层、操作系统和平台，您可以访问端点来存储和检索数据。Amazon Simple Storage Service（Amazon S3）和 Amazon DynamoDB 就是托管服务的示例。有关更多信息，请参阅本指南的[主题 1：使用托管服务](theme-1.md)部分。

因此，需要进行一些重新解释，才能使八大要点策略适合 AWS上的工作负载。本指南将基本八大策略转换为 AWS *主题*。

## 使用主题
<a name="using-themes"></a>

本指南分为八个主题。每个 Essential Eight 策略都映射到以下一个或多个主题，每个主题都映射到 Well-Architecte AWS d 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)

每个主题都包括该主题的概述、相关的Well-Architect AWS ed Framework最佳实践，以及有关如何实现基本八项成熟度和监控合规性的说明。这些说明提供了手动步骤或帮助您使用 [AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)配置自动化。手动步骤需要相应的机制，来确保发现的问题得到解决。有关更多信息，请参阅[主题 8：实施手动流程机制](theme-8.md)。 AWS Config 规则需要类似的监督或自动化，才能[补救不合规](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)的资源。通过遵循与这些主题一致的指引，您可以采用一种能够最大限度地发挥云优势的方法，达到八大要点成熟度。

## 重新解读云的八大要点策略
<a name="reinterpreting-e8-strategies"></a>

由于八大要点框架不是为云环境设计的，因此在解决每个八大要点策略的基本原则时，必须采用云原生方法。方法因两个关键问题而异。

### 您正在使用哪些服务？
<a name="services"></a>

[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 Elastic Compute Cloud（Amazon EC2）](https://docs.aws.amazon.com/ec2/?icmpid=docs_homepage_compute)上的数据库相比，[Amazon Relational Database Service（Amazon RDS）](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)上的数据库所需的运营责任更少。

例如，如果您正在调整云端*操作系统*的 Essential Eight 策略，则需要考虑正在使用哪些服务，以及是否负责修补这些资源。 AWS 负责修补完全托管的服务，例如 Lambda 和 DynamoDB。对于其他服务，例如 Amazon RDS 或 [Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html)，您可能需要在维护时段内管理补丁。

### 您使用的是哪种部署模式？
<a name="deployment-model"></a>

您的组织是否在使用可变或不可变的基础设施方法？

*可变基础设施*模型更新和修改生产工作负载的现有基础设施。****这是云之前的标准部署方法，当时更换服务器基础设施成本高昂且耗时，因此最实用的方法是将更改应用于已在生产环境中运行的服务器。云中可变方法的一个示例是将应用程序更改直接部署到正在运行的 EC2 实例上，可以手动部署或使用软件部署服务，例如 [AWS Systems Manager Run 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)最佳实践。

例如，如果您要为云调整*修补操作系统*八大要点策略，则需要考虑如何将补丁应用于部署模型。对于可变基础设施，您可以手动修补资源，或者通过自动化提高运营效率。如果你使用的是不可变的基础架构，那么你需要使用 CI/CD 管道来部署带有最新版本操作系统的新基础架构。实际上，在这种模式下，*修补*一词用词不当，因为基础设施将被替换而不是修补。