# 安全基础知识
安全支柱介绍了如何利用云技术来保护数据、系统和资产，从而改善您的安全状况。本白皮书深度介绍了有关在 AWS 上构建安全工作负载的最佳实践指导。
## 设计原则
在云中，有很多原则可帮助您提高工作负载的安全性：
+ **实施强大的身份验证基础：**实施最低权限原则，并通过对每一次与 AWS 资源之间的交互进行适当授权来强制执行职责分离。集中进行身份管理，并努力消除对长期静态凭证的依赖。
+ **保持可追溯性：**实时监控和审查对环境执行的操作和更改并发送警报。为系统集成日志和指标收集功能，以自动调查并采取行动。
+ **在所有层面应用安全措施：**利用多种安全控制措施实现深度防御。应用到所有层面（例如网络边缘、VPC、负载均衡、每个实例和计算服务、操作系统、应用程序和代码）。
+ **自动化安全性最佳实践：**借助基于软件的自动化安全机制，您能够以更为快速且更具成本效益的方式实现安全扩展。创建安全架构，包括实施可在版本控制模板中以代码形式定义和管理的控制措施。
+ **保护传输中数据和静态数据：**按敏感程度对数据进行分类，并根据情况采用加密、令牌化和访问控制等适当机制。
+ **限制对数据的访问：**利用相关机制和工具来减少或消除对于直接访问或手动处理数据的需求。这样可以降低处理敏感数据时数据处理不当、被修改以及人为错误的风险。
+ **做好应对安全性事件的准备工作：**制定符合组织要求的事件管理和调查政策和流程，做好应对意外事件的准备工作。开展意外事件响应模拟演练，并使用具有自动化功能的工具来提高检测、调查和恢复的速度。
## 定义
云中的安全性包含七个方面：
+ [安全基础知识](#security)
+ [身份和访问管理](identity-and-access-management.md)
+ [检测](detection.md)
+ [基础设施保护](infrastructure-protection.md)
+ [数据保护](data-protection.md)
+ [事件响应](incident-response.md)
+ [应用程序安全性](application-security.md)
# 责任共担
安全性和合规性是 AWS 与客户共同承担的责任。这种共担模式可以减轻客户的运营负担，因为 AWS 会运营、管理和控制从主机操作系统和虚拟化层组件，一直到服务运营所在物理设施的安全性。客户负责管理来宾操作系统（包括更新和安全补丁）、其他关联应用程序软件以及 AWS 提供的安全组防火墙的配置。客户应慎重选择服务，因为他们所承担的责任因他们使用的服务、服务与其 IT 环境的集成以及适用法律法规而各异。这种责任共担的性质还赋予了客户足够的灵活性和控制能力来进行部署。如下图所示，责任的这种区分通常称为云“本身的”安全性与云“中的”安全性。
**AWS“云的安全性”责任** – AWS 负责保护运行 AWS 云中提供的所有服务的基础设施。该基础设施由运行 AWS 云服务的硬件、软件、网络和设施组成。
**客户“云中的安全性”责任** – 客户责任将由客户选择的 AWS 云服务确定。这决定了客户必须执行的作为其安全责任一部分的配置工作量。例如，Amazon Elastic Compute Cloud（Amazon EC2）等服务被归类为基础设施即服务（IaaS），因此，这需要客户执行所有必要的安全配置和管理任务。部署 Amazon EC2 实例的客户负责管理来宾操作系统（包括更新和安全补丁）、客户在实例上安装的任何应用程序软件或实用程序，以及每个实例上由 AWS 提供的防火墙（称为安全组）的配置。对于抽象服务（例如 Amazon S3 和 Amazon DynamoDB），AWS 会运营基础设施层、操作系统和平台，而客户访问端点即可存储和检索数据。客户负责管理他们的数据（包括加密选项）、对其资产进行分类以及使用 IAM 工具应用适当的权限。
![\[Shared responsibility model diagram showing customer and AWS security roles in cloud services.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/security-pillar/images/aws-shared-responsibility.png)
*图 1：AWS 责任共担模式*
此客户/AWS 责任共担模式还扩展到 IT 控制措施方面。正如 AWS 与客户共同行使控制 IT 环境的责任一样，管理、运营和验证 IT 控制措施的责任也是由双方共同承担。AWS 负责管理与部署在 AWS 环境中的物理基础设施相关的控制措施（此管理工作此前可能由客户承担），从而帮助客户缓解操作控制措施的负担。因为每个客户在 AWS 中的部署均不相同，所以客户可以藉此将管理特定 IT 控制措施的责任移交到 AWS，从而形成一个新型分布式控制环境。然后客户可以使用 AWS 控制和合规性文档来根据需要执行控制评估与验证程序。以下是由 AWS 和/或 AWS 客户管理的控制措施示例。
**继承的控制措施**– 客户完全从 AWS 继承的控制措施。
+ 物理和环境控制措施
**共享的控制措施** – 应用于基础设施层和客户层的控制措施，但在单独的上下文中或从单独的视角应用。在共享的控制措施中，AWS 提供了对基础设施的要求，客户必须对其使用 AWS 服务实施自己的控制措施。示例包括：
+ 补丁管理 – AWS 负责修补和修复基础设施中的缺陷，而客户负责修补他们的来宾操作系统和应用程序。
+ 配置管理 – AWS 维护其基础设施设备的配置，而客户负责配置他们自己的来宾操作系统、数据库和应用程序。
+ 意识与培训 – AWS 培训 AWS 的员工，而客户必须对自己的员工进行培训。
**客户特定** – 完全由客户负责的控制措施，基于客户在 AWS 服务中部署的应用程序。示例包括：
+ 服务和通信保护或区安全，这可能需要客户在特定的安全环境中路由数据或将数据分区。
# Governance
安全治理是总体方法的一部分，旨在通过制定策略和控制目标来帮助管理风险，从而帮助实现业务目标。通过遵循安全控制目标的分层方法来实施风险管理，其中每一层均基于前一层而构建。了解 AWS 责任共担模式是您的基础层。这方面的知识阐明了您需对客户承担的责任以及您从 AWS 得到了什么。[AWS Artifact](https://aws.amazon.com/artifact/) 是一种实用资源，让您可以按需访问 AWS 安全性与合规性报告以及选定的在线协议。
在下一层满足您的大部分控制目标。在该层提供了平台范围的功能。例如，该层包括 AWS 账户分配过程、与身份提供程序（例如 AWS IAM Identity Center）的集成以及常见的检测性控制。平台治理过程的一些输出也位于该层。在您希望开始使用新的 AWS 服务时，更新 AWS Organizations 服务中的服务控制策略（SCP）可为服务的初次使用提供防护机制。您可以使用其他 SCP 来实施常见的安全控制目标，这通常称为安全不变量。这些是您应用于多个账户、组织单位或整个 AWS 组织的控制目标或配置。典型示例是限制运行基础设施的区域，或防止停用检测性控制措施。该中间层还包含编码策略，例如配置规则或签入管道。
顶层是产品团队满足控制目标的地方，这是因为实施是在产品团队控制的应用程序中完成的。这可能是在应用程序中实施输入验证或确保身份在各项微服务之间正确传递。尽管产品团队负责配置，他们也仍能从中间层继承一些功能。
无论您在何处实施控制措施，目标都是一致的，即管理风险。一系列风险管理框架将应用于特定的行业、区域或技术。您的主要目标：根据可能性和后果来强调风险。这就是*固有风险*。紧接着，您可以定义控制目标，降低可能性和/或减少后果。随后，采用适当的控制措施后，您可以查看可能产生哪些风险。这就是*剩余风险*。控制目标可应用于一个或多个工作负载。下图显示了一个典型的风险矩阵。可能性基于以前发生事件的频率，而后果基于事件的财务、声誉和时间成本。
![\[Risk matrix showing likelihood vs. consequence, with risk levels from low to critical.\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/security-pillar/images/risk-matrix.png)
*图 2：风险等级可能性矩阵*
# AWS 账户管理和分离
我们建议您根据职能、合规性要求或一组通用控制措施，在单独的账户和组账户中组织工作负载，而不是完全沿用您企业的报告结构。在 AWS 中，账户是硬性边界。例如，强烈建议执行账户级分离，以使生产工作负载与开发和测试工作负载分离。
**集中管理账户**：AWS Organizations 会[自动创建和管理 AWS 账户](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html)，并在创建之后控制这些账户。在通过 AWS Organizations 创建账户时，请务必考虑使用您的电子邮件地址，因为这将是允许重置密码的根用户。Organizations 允许您根据工作负载的要求和用途，将账户分组成代表不同环境的[组织部门（OU）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)。
**集中设置控制：**在适当的级别，只允许特定的服务、区域和服务操作，以控制您的 AWS 账户能够执行的操作。AWS Organizations 允许您使用服务控制策略（SCP），在组织、组织部门或账户级别应用权限防护机制，此操作适用于所有 [AWS Identity and Access Management](https://aws.amazon.com/iam/)（IAM）用户和角色。例如，您可以利用 SCP 禁止用户从您未明确允许的区域启动资源。AWS Control Tower 能够以一种简化的方式设置和管理多个账户。它会自动在您的 AWS Organization 中设置账户、自动预置、应用[防护机制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)（包括预防和检测），并提供一个控制面板供您获得可见性。
**集中配置服务和资源：**AWS Organizations 可帮助配置能够应用于您所有账户的 [AWS 服务](https://aws.amazon.com/organizations/features/)。例如，您可以使用 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 配置集中日志记录功能，记录组织中执行的所有操作，也可以禁止成员账户禁用日志记录功能。您也可以使用 [AWS Config](https://aws.amazon.com/config/) 集中聚合自己定义的规则的数据，以便能够审计工作负载是否合规，并快速对变化做出反应。AWS CloudFormation[StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) 允许您在组织中跨账户和组织部门集中管理 AWS CloudFormation 堆栈。这样，您就可以自动预置一个新账户来满足自己的安全要求。
使用安全服务的委托管理功能，将用于管理的账户与组织计费（管理）账户分隔开。多项 AWS 服务（例如，GuardDuty、Security Hub 和 AWS Config）支持与 AWS Organizations 的集成，包括为管理功能指定特定的账户。
**Topics**
+ [
# SEC01-BP01 使用账户分隔工作负载
](sec_securely_operate_multi_accounts.md)
+ [
# SEC01-BP02 保护账户根用户和属性
](sec_securely_operate_aws_account.md)
# SEC01-BP01 使用账户分隔工作负载
通过采取多账户策略，在环境（如生产、开发和测试）和工作负载之间建立共同的防护机制和隔离措施。强烈建议在账户层面进行分离管理，这样可为安全性、账单和访问提供强大的隔离边界。
**期望结果：**形成一种账户结构，可将云运维、无关工作负载和环境隔离到单独的账户中，从而提高整个云基础设施的安全性。
**常见反模式：**
+ 将多个相互毫无关联，具有不同数据敏感度级别的工作负载放入同一账户中。
+ 组织单位（OU）结构界定不清。
**建立此最佳实践的好处：**
+ 即使不该访问的工作负载无意中被访问了，影响范围也会缩小。
+ 能够对访问 AWS 服务、资源和区域进行集中治理。
+ 可集中管理策略和安全服务，维护云基础设施的安全性。
+ 实现账户创建和维护流程自动化。
+ 集中审核基础设施状况，从而满足法规遵从性和监管要求。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
AWS 账户提供安全隔离边界，使不同敏感度的工作负载或资源相互分离。AWS 提供相应工具，以多账户策略来大规模管理云工作负载，从而利用此隔离边界。如要获得有关 AWS 多账户策略的概念、模式和实施的指导，请参阅《[Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)》白皮书。
如果需要集中管理多个 AWS 账户，账户应基于组织单位（OU）层建立层次结构。然后可以建立安全控制机制，并将其应用于 OU 和成员账户，从而为组织内的成员账户建立一致的预防性控制机制。安全控制机制是层层继承的，使您能够筛选位于 OU 层次结构较低层次的成员账户的可用权限。优秀的架构设计将能够利用这种层层继承的特性，减少设置安全策略，降低复杂性，并使每个成员账户的安全控制效果达到预期。
采用 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) 和 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 这两种服务，可在您的 AWS 环境中实施和管理多账户结构。AWS Organizations 使得您能够将账户建立成由一个或多个 OU 层定义的层次结构形式，每个 OU 均可包含若干成员账户。[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)（SCP）使组织管理员能够对成员账户建立精细的预防性控制机制，而 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/config-rule-multi-account-deployment.html) 可用于建立对成员账户的主动式和检测性控制。许多 AWS 服务[与 AWS Organizations 集成](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)，可提供委派型管理控制，并在组织内的所有成员账户中执行服务特定的任务。
[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 位于 AWS Organizations 之上，为具有[登录区](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)的多账户 AWS 环境提供了一键式最佳实践设置。登录区是由 Control Tower 建立的多账户环境的入口处。与 AWS Organizations 相比，采用 Control Tower 具有若干[好处](https://aws.amazon.com/blogs/architecture/fast-and-secure-account-governance-with-customizations-for-aws-control-tower/)。可以改进账户治理状况的三种好处为：
+ 将强制安全防护机制集成于系统中，可自动应用于准入组织的账户。
+ 有多种防护机制可供选择，还能开启或关闭给定 OU 组的防护机制。
+ [AWS Control Tower Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/account-factory.html) 可在组织内部自动部署账户，设置好预先批准的基准和配置选项。
**实施步骤**
1. **设计组织单位结构：**设计良好的组织单位结构减少了创建和维护服务控制策略及其他安全控制机制所需的管理负担。组织单位结构应[与业务需求、数据敏感度和工作负载结构看齐](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)。
1. **为多账户环境创建登录区：**登录区提供了一致的安全性和基础设施基础，让组织可以从中快速开发、启动和部署工作负载。您可以使用[定制的登录区或 AWS Control Tower](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/building-landing-zones.html) 来编排环境。
1. **建立防护机制：**通过登录区为环境实施一致的安全防护机制。AWS Control Tower 提供了可部署的[必选](https://docs.aws.amazon.com/controltower/latest/userguide/mandatory-controls.html)和[可选](https://docs.aws.amazon.com/controltower/latest/userguide/optional-controls.html)控制机制的列表。实施 Control Tower 时会自动部署必选控制机制。查看高度推荐和可选控制机制的列表，并实施适合您需求的控制机制。
1. **限制访问新添加的区域**：对于新的 AWS 区域，诸如用户和角色之类的 IAM 资源将仅传播到您指定的区域。可以在[使用 Control Tower 时通过控制台](https://docs.aws.amazon.com/controltower/latest/userguide/region-deny.html)执行此操作，也可以通过调整 [AWS Organizations 中的 IAM 权限策略](https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/)执行此操作。
1. **考虑使用 AWS [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)**：StackSets 可帮助您通过已批准的模板将资源（包括 IAM 策略、角色和组）部署到不同的 AWS 账户和区域中。
## 资源
**相关最佳实践：**
+ [SEC02-BP04 依赖集中式身份提供程序](sec_identities_identity_provider.md)
**相关文档：**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 安全审计指南](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Use CloudFormation StackSets to provision resources across multiple AWS 账户 and regions](https://aws.amazon.com/blogs/aws/use-cloudformation-stacksets-to-provision-resources-across-multiple-aws-accounts-and-regions/)
+ [Organizations 常见问题](https://aws.amazon.com/organizations/faqs/)
+ [AWS Organizations 术语和概念](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
+ [Best Practices for Service Control Policies in an AWS Organizations Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [AWS Account Management Reference Guide](https://docs.aws.amazon.com/accounts/latest/reference/accounts-welcome.html)
+ [使用多个账户整理您的 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
**相关视频：**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Building and Governing Multiple Accounts using AWS Control Tower](https://www.youtube.com/watch?v=agpyuvRv5oo)
+ [Enable Control Tower for Existing Organizations](https://www.youtube.com/watch?v=CwRy0t8nfgM)
# SEC01-BP02 保护账户根用户和属性
根用户是 AWS 账户中权限最高的用户，对账户内的所有资源具有完全管理访问权限，在某些情况下不受安全策略的约束。停用对根用户的编程访问，为根用户建立适当的控制机制，并避免日常使用根用户，这样有助于降低无意中暴露根凭证以及随后破坏云环境的风险。
**期望结果：**保护根用户有助于减少因滥用根用户凭证而导致意外或故意损坏的可能性。建立检测性控制机制也可以在有人使用根用户执行操作时向适当人员发出警报。
**常见反模式：**
+ 使用根用户执行各种任务，而非仅在必要时使用根用户凭证。
+ 忽略定期测试应急计划，不验证关键基础设施、流程和人员在紧急情况下的运作情况。
+ 只考虑典型的账户登录流程，而没有考虑或测试替代的账户恢复方法。
+ 因为 DNS、电子邮件服务器和电话提供商要用于账户恢复流程，就不将其作为关键安全边界的一部分进行处理。
**建立此最佳实践的好处：**保护对根用户的访问可以建立信心，让账户中的操作受到控制和审核。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
AWS 提供许多有助于保护账户安全的工具。但由于其中一些措施默认情况下未启用，因此您必须采取直接行动来实施这些措施。请将这些建议视为确保 AWS 账户安全的基本步骤。实施这些步骤时，务必建立一个可持续评测和监控安全控制机制的过程，这非常重要。
当您首次创建 AWS 账户时，最初使用的是一个对账户中所有 AWS 服务和资源有完全访问权限的身份。此身份称作 AWS 账户根用户。您可以使用在创建账户所用的电子邮件地址和密码以根用户身份登录。由于授予 AWS 根用户的访问权限较高，您必须仅将 AWS 根用户用于执行[特别需要它](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)的任务。必须严格保护根用户登录凭证，并且应始终为 AWS 账户根用户使用多重身份验证（MFA）。
除了使用用户名、密码和多重身份验证（MFA）设备登录根用户的常规身份验证流程外，还可以使用账户恢复流程登录您的 AWS 账户 根用户，该用户可以访问与您的账户关联的电子邮件地址和电话号码。因此，保护发送恢复电子邮件的根用户电子邮件账户和保护与该账户关联的电话号码同样重要。还应考虑潜在的循环依赖关系，其中与根用户关联的电子邮件地址托管在同一 AWS 账户的电子邮件服务器或域名服务（DNS）资源上。
使用 AWS Organizations 时，有多个 AWS 账户（每个均有一个根用户）。将一个账户指定为管理账户，然后可以在管理账户下面添加几层成员账户。优先保护管理账户的根用户，然后解决成员账户根用户问题。保护管理账户根用户的策略可能与保护成员账户根用户的策略不同，您可以对成员账户根用户建立预防性安全控制机制。
**实施步骤**
建议使用以下实施步骤为根用户建立控制机制。在适用情况下，建议与 [CIS AWS Foundations Benchmark 版本 1.4.0](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cis-controls-1.4.0.html) 交叉引用。除了这些步骤外，请参阅 [AWS 最佳实践指导](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)来确保 AWS 账户和资源安全。
**预防性控制机制**
1. 为账户设置准确的[联系信息](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)。
1. 该信息用于丢失的密码恢复流程、丢失的 MFA 设备账户恢复流程，以及与您的团队进行关键的安全相关通信。
1. 使用企业域托管的电子邮件地址（最好是通讯组列表）作为根用户的电子邮件地址。使用通讯组列表而不是个人的电子邮件账户可提供额外的冗余和连续性，以便在很长一段时间内访问根账户。
1. 联系信息上所列的电话号码应该是为此目的而设置的专用安全电话的号码。电话号码不应列出或与任何人共享。
1. 不要为根用户创建访问密钥。如果存在访问密钥，请将其删除（CIS 1.4）。
1. 消除根用户的任何长期编程凭证（访问密钥和私有密钥）。
1. 如果已存在根用户访问密钥，您应将使用这些密钥的进程转换为使用 AWS Identity and Access Management（IAM）角色的临时访问密钥，然后[删除根用户访问密钥](https://docs.aws.amazon.com/accounts/latest/reference/root-user-access-key.html#root-user-delete-access-key)。
1. 确定是否需要为根用户存储凭证。
1. 如果您使用 AWS Organizations 创建新的成员账户，则新成员账户上根用户的初始密码将设置为一个不向您公开的随机值。如果需要，请考虑使用 AWS 组织管理账户的密码重置流程来[访问成员账户](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html#orgs_manage_accounts_access-as-root)。
1. 对于独立 AWS 账户或管理 AWS 组织账户，请考虑为根用户创建并安全地存储凭证。为根用户启用 MFA。
1. 在 AWS 多账户环境中，为成员账户根用户使用预防性控制机制。
1. 考虑为成员账户启用[不允许为根用户创建根访问密钥](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-access-keys)预防性防护机制。
1. 考虑为成员账户启用[不允许以根用户身份执行操作](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html#disallow-root-auser-actions)预防性防护机制。
1. 如果需要根用户凭证，请执行以下操作：
1. 使用复杂密码。
1. 为根用户启用多重身份验证（MFA），特别是 AWS Organizations 管理（付款人）账户（CIS 1.5）。
1. 考虑使用硬件 MFA 设备来提高韧性和安全性，因为一次性设备可以减少包含 MFA 代码的设备被重复用于其他用途的可能性。验证是否定期更换由电池供电的硬件 MFA 设备。（CIS 1.6）
+ 要为根用户配置 MFA，请遵循创建[虚拟 MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_virtual.html#enable-virt-mfa-for-root) 或[硬件 MFA 设备](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable_physical.html#enable-hw-mfa-for-root)的说明。
1. 考虑注册多个 MFA 设备用于备份。[每个账户最多允许 8 个 MFA 设备](https://aws.amazon.com/blogs/security/you-can-now-assign-multiple-mfa-devices-in-iam/)。
+ 请注意，为根用户注册多个 MFA 设备将自动禁用[在 MFA 设备丢失的情况下恢复账户的流程](https://aws.amazon.com/premiumsupport/knowledge-center/reset-root-user-mfa/)。
1. 安全地存储密码，如果以电子方式存储密码，则考虑循环依赖关系。不要以需要访问同一 AWS 账户才能获得密码的方式存储密码。
1. 可选：考虑为根用户制定定期密码轮换计划。
+ 凭证管理最佳实践取决于您的监管和政策要求。受 MFA 保护的根用户并不依赖密码作为单重身份验证。
+ 定期[更改根用户密码](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_change-root.html)可降低无意中暴露的密码被滥用的风险。
**侦测性控制**
+ 创建警报来检测根凭证的使用情况（CIS 1.7）。[启用 Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_settingup.html) 将通过 [RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage) 调查发现对根用户 API 凭证的使用进行监控和发出警报。
+ 评估并实施[适用于 AWS Config 的 AWS Well-Architected 安全性支柱合规包](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-wa-Security-Pillar.html)中包含的检测性控制机制，或者如果使用 AWS Control Tower，则评估并实施 Control Tower 内[强烈建议的控制机制](https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-controls.html)。
**运营指导**
+ 确定组织中应该有权访问根用户凭证的人员。
+ 采用双人规则，以便不会出现一个人就能够访问所有必要凭证和 MFA 来获得根用户访问权限的情况。
+ 验证组织（而不是个人）对与账户关联的电话号码和电子邮件别名（用于密码重置和 MFA 重置流程）保持控制。
+ 仅在例外情况下使用根用户（CIS 1.7）。
+ 不得使用 AWS 根用户执行日常任务，即使是管理任务也不可以。仅以根用户身份登录，以执行[需要根用户的 AWS 任务](https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html)。所有其他操作都应由代入适当角色的其他用户执行。
+ 定期检查对根用户的访问是否正常，以便在出现需要使用根用户凭证的紧急情况之前对过程进行测试。
+ 定期检查与账户关联的电子邮件地址以及[备用联系人](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)下列出的电子邮件地址是否有效。监控这些电子邮件收件箱，查看您可能从 abuse@amazon.com 中收到的安全通知。还要确保与该账户相关的任何电话号码都有效。
+ 准备事件响应程序，应对根账户滥用情况。请参阅《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)》以及[《安全性支柱》白皮书“事件响应”部分](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)中的最佳实践，了解有关为 AWS 账户构建事件响应策略的更多信息。
## 资源
**相关最佳实践：**
+ [SEC01-BP01 使用账户分隔工作负载](sec_securely_operate_multi_accounts.md)
+ [SEC02-BP01 使用强大的登录机制](sec_identities_enforce_mechanisms.md)
+ [SEC03-BP02 授予最低访问权限](sec_permissions_least_privileges.md)
+ [SEC03-BP03 建立紧急访问流程](sec_permissions_emergency_process.md)
+ [SEC10-BP05 预置访问权限](sec_incident_response_pre_provision_access.md)
**相关文档：**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 安全审计指南](https://docs.aws.amazon.com/general/latest/gr/aws-security-audit-guide.html)
+ [IAM 最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ [Amazon GuardDuty – root credential usage alert](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#policy-iam-rootcredentialusage)
+ [通过 CloudTrail 监控根凭证使用情况的分步指导](https://docs.aws.amazon.com/securityhub/latest/userguide/iam-controls.html#iam-20)
+ [获准与 AWS 一起使用的 MFA 令牌](https://aws.amazon.com/iam/features/mfa/)
+ Implementing [break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) on AWS
+ [Top 10 security items to improve in your AWS 账户](https://aws.amazon.com/blogs/security/top-10-security-items-to-improve-in-your-aws-account/)
+ [发现我的 AWS 账户中存在未经授权的活动时该怎么办？](https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/)
**相关视频：**
+ [Enable AWS adoption at scale with automation and governance](https://youtu.be/GUMSgdB-l6s)
+ [Security Best Practices the Well-Architected Way](https://youtu.be/u6BCVkXkPnM)
+ [Limiting use of AWS root credentials](https://youtu.be/SMjvtxXOXdU?t=979) from AWS re:inforce 2022 – Security best practices with AWS IAM
# 安全地运营工作负载
安全地运营工作负载涵盖了从设计、构建、运行到持续改进的整个工作负载生命周期。为了增强您在云中安全运营的能力，其中一种方法是采用组织化的方法进行治理。治理是采用一致的方法来指导决策，而不是完全依赖于相关人员做出良好判断。您的治理模式和流程决定了您如何回答以下问题：“我如何知道给定工作负载的控制目标已实现并且适用于该工作负载？” 采用一致的方法来制定决策可以加快部署工作负载，并帮助提高组织中的安全能力标准。
为了安全地操作您的工作负载，您必须将纲领性最佳实践应用于每个安全领域。将您在组织和工作负载级别的卓越运营中定义的要求和流程应用于所有领域。及时了解 AWS 和行业建议及威胁情报可以帮助您发展威胁模型和控制目标。实现安全流程、测试和验证的自动化可帮助您扩展安全运营。
利用自动化，可以实现流程的一致性和可重复性。虽然每个人都擅长做很多事情，但肯定不能始终如一地重复做同一件事而不出错。即使编写了良好的运行手册，您也会面临人员无法始终如一地执行重复任务的风险。当人员承担多种责任并且必须对不熟悉的提醒做出响应时尤为如此。不过，自动化每次都会以相同的方式响应。通过自动化部署应用程序是最佳选择。可以先测试运行部署的代码，然后将该代码用于执行部署。这增加了变更过程中的信心，同时降低了变更失败的风险。
要验证配置是否达到您的控制目标，请首先在非生产环境中测试自动化和部署的应用程序。这样一来，您就可以测试自动化，证明它正确地执行了所有步骤，还可以在开发和部署周期中获得早期反馈，从而减少返工。要降低出现部署错误的几率，请通过代码而不是人员来进行配置更改。如果您需要重新部署应用程序，可以利用自动化更轻松地完成此操作。在定义其他控制目标时，您可以轻松地将它们添加到所有工作负载的自动化中。
让各个工作负载负责人使用常见功能和共享组件来节省时间，而不是将精力放在实现针对工作负载的安全性上。多个团队可使用的服务的一些示例包括 AWS 账户创建过程、人员的集中化身份、通用日志记录配置以及 AMI 和容器基础映像创建。此方法可以帮助构建者缩短工作负载周期并始终如一地达到安全控制目标。当团队的一致性更高时，您可以验证控制目标，并向利益相关方更好地报告您的控制态势和风险状况。
**Topics**
+ [
# SEC01-BP03 识别并验证控制目标
](sec_securely_operate_control_objectives.md)
+ [
# SEC01-BP04 随时了解安全威胁和建议
](sec_securely_operate_updated_threats.md)
+ [
# SEC01-BP05 缩小安全管理范围
](sec_securely_operate_reduce_management_scope.md)
+ [
# SEC01-BP06 自动部署标准安全控制措施
](sec_securely_operate_automate_security_controls.md)
+ [
# SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级
](sec_securely_operate_threat_model.md)
+ [
# SEC01-BP08 定期评估并实施新的安全服务和功能
](sec_securely_operate_implement_services_features.md)
# SEC01-BP03 识别并验证控制目标
根据合规性要求以及从威胁模型中发现的风险，获得并验证需要应用于工作负载的控制目标和控制措施。持续验证控制目标和控制措施可帮助您衡量风险缓解措施的有效性。
**期望结果：**针对业务明确定义了安全控制目标，并且这些目标符合合规性要求。通过自动化方法以及策略来实施和强制执行控制措施，并持续评估这些措施在达成目标方面的有效性。收集某个时间点以及一段时间内的有效性证据，并能够随时报告给审核人员。
**常见反模式：**
+ 没有充分了解用于确保业务安全性的监管要求、市场期望和行业标准
+ 网络安全框架和控制目标与业务要求不一致
+ 虽然实施了控制措施，但没有与控制目标保持高度一致，也难于衡量
+ 不使用自动化方法来报告控制措施的有效性
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
根据安全控制目标，您可以利用许多常见的网络安全框架来奠定基础。根据业务考虑监管要求、市场期望和行业标准，确定哪些框架能够很好地满足需求。这些框架的例子包括 [AICPA SOC 2](https://aws.amazon.com/compliance/soc-faqs/)、[HITRUST](https://aws.amazon.com/compliance/hitrust/)、[PCI-DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)、[ISO 27001](https://aws.amazon.com/compliance/iso-27001-faqs/) 和 [NIST SP 800-53](https://aws.amazon.com/compliance/nist/)。
对于所确定的控制目标，了解所使用的 AWS 服务如何帮助实现这些目标。使用 [AWS Artifact](https://aws.amazon.com/artifact/) 来查找与目标框架相符的文档和报告，这些文档和报告介绍了 AWS 承担的责任范围，并且提供了针对您负责的其余责任范围的相关指导。如需进一步了解与各种框架控制声明对应的服务特定指导，请参阅《[AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)》。
在定义用于实现目标的控制措施时，请使用预防性控制措施来规范执行方法，并使用检测性控制措施来自动执行缓解方法。在您的 AWS Organizations 中，使用[服务控制策略（SCP）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)来协助防范不合规的资源配置和操作。在 [AWS Config](https://aws.amazon.com/config/) 中实施规则，用于监控并报告不合规的资源，然后在确信规则的行为正确无误时，将规则切换为强制执行模式。要部署与网络安全框架相一致的预定义托管规则集，请优先评估使用 [AWS Security Hub CSPM 标准](https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html)。AWS 基础服务最佳实践（FSBP，Foundational Service Best Practice）标准和 CIS AWS 基础基准可作为很好的起点，用于制定与多种标准框架所共有的多个目标相一致的控制措施。如果 Security Hub CSPM 实质上没有所需的控制检测措施，则可以使用 [AWS Config 合规包](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)予以补充。
使用 AWS Global Security and Compliance Acceleration（GSCA）团队推荐的 [APN 合作伙伴服务包](https://aws.amazon.com/partners/programs/gsca/bundles/)，可以根据需要，从安全顾问、咨询机构、证据收集和报告系统、审核人员以及其他补充性服务那里获取协助。
### 实施步骤
1. 评估常见的网络安全框架，让控制目标与所选框架保持一致。
1. 使用 AWS Artifact 获取所选框架的相关指导和责任文档。了解在责任共担模式下，合规性的责任有哪些归属于 AWS，哪些由您承担。
1. 使用 SCP、资源策略、角色信任策略和其他防护机制，防止出现不合规的资源配置和操作。
1. 评估与您的控制目标相一致的 Security Hub CSPM 标准和 AWS Config 合规包的部署。
## 资源
**相关最佳实践：**
+ [SEC03-BP01 定义访问要求](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_permissions_define.html)
+ [SEC04-BP01 配置服务和应用程序日志记录](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_app_service_logging.html)
+ [SEC07-BP01 了解数据分类方案](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_identify_data.html)
+ [OPS01-BP03 评估治理要求](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_governance_reqs.html)
+ [OPS01-BP04 评估合规性要求](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_compliance_reqs.html)
+ [PERF01-BP05 使用策略和参考架构](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_use_policies_and_reference_architectures.html)
+ [COST02-BP01 根据组织的要求制定各种策略](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html)
**相关文档：**
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**相关工具：**
+ [AWS Artifact](https://aws.amazon.com/artifact/)
# SEC01-BP04 随时了解安全威胁和建议
关注行业威胁情报出版物和数据源来获取行业动态，及时了解最新的威胁和缓解措施。评估根据最新威胁数据自动进行更新的托管服务产品。
**期望结果：**在行业出版物发布最新的威胁和建议更新时及时了解情况。 您可以使用自动化功能来检测潜在的漏洞和暴露情况，以及识别新的威胁。您对这些威胁采取了缓解措施。 您采用 AWS 服务来自动更新最新的威胁情报。
**常见反模式：**
+ 没有可靠且可重复的机制来随时了解最新的威胁情报。
+ 手动维护技术产品组合、工作负载和依赖项清单，这些清单需要人工审查来发现潜在的漏洞和暴露情况。
+ 没有采取机制来更新工作负载和依赖项，未获得可提供已知威胁缓解措施的最新版本。
**建立此最佳实践的好处：**使用威胁情报来源来了解最新信息，可以降低错过可能影响业务的重要威胁形势变化的风险。 与手动替代方案相比，采取自动化功能来扫描、检测和修复工作负载及其依赖项中存在潜在的漏洞或暴露情况，有助于您快速且可预测地降低风险。 这样就可以控制与漏洞缓解相关的时间和成本。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
阅读可信的威胁情报出版物，随时掌握威胁形势。 有关已知的对抗策略、技巧和程序（TTP，Tactics, Techniques, and Procedures）的文档，请参阅 [MITRE ATT&CK](https://attack.mitre.org/) 知识库。查看 MITRE 的[通用漏洞披露](https://cve.org/)（CVE，Common Vulnerabilities and Exposures）列表，随时了解您依赖的产品中的已知漏洞。通过开放式全球应用程序安全项目（OWASP，Open Worldwide Application Security Project）的热门 [OWASP Top 10](https://owasp.org/www-project-top-ten/) 项目，了解 Web 应用程序面临的严重风险。
通过 CVE 的 AWS [安全公告](https://aws.amazon.com/security/security-bulletins/)，及时了解 AWS 安全事件和建议的修复措施。
为了减少保持最新状态所需的总体工作量和开销，您可以考虑使用 AWS 服务，这样就能随着时间的推移自动整合新威胁情报。 例如，[Amazon GuardDuty](https://aws.amazon.com/guardduty/) 会及时了解行业威胁情报，从而检测账户中的异常行为和威胁特征。 [Amazon Inspector](https://aws.amazon.com/inspector/) 自动让其用于持续扫描功能的 CVE 数据库保持最新状态。 [AWS WAF](https://aws.amazon.com/waf/) 和 [AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-advanced-summary.html) 均提供了托管规则组，这些规则组会在新威胁出现时自动更新。
查看用于自动化实例集管理和修补的 [Well-Architected 卓越运营支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)。
## 实施步骤
+ 订阅与业务和行业相关的威胁情报出版物，了解最新动态。订阅 AWS 安全公告。
+ 考虑采用自动整合新威胁情报的服务，例如 Amazon GuardDuty 和 Amazon Inspector。
+ 部署符合 Well-Architected 卓越运营支柱最佳实践的实例集管理和修补策略。
## 资源
**相关最佳实践：**
+ [SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_threat_model.html)
+ [OPS01-BP05 评估威胁形势](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_priorities_eval_threat_landscape.html)
+ [OPS11-BP01 设置持续改进流程](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_evolve_ops_process_cont_imp.html)
# SEC01-BP05 缩小安全管理范围
确定是否可以使用 AWS 服务，将某些控制措施的管理工作转移给 AWS（*托管服务*），从而缩小安全管理范围。这些服务有助于减少安全维护任务，例如基础设施预置、软件设置、修补或备份。
**期望结果：**在为工作负载选择 AWS 服务时考虑到安全管理工作的范围。在应该考虑的其他 Well-Architected 注意事项之外，将管理开销和维护任务的成本（总拥有成本，简称 TCO）与您所选择服务的成本进行权衡。在控制措施评估和验证流程中，可以结合考虑 AWS 的控制和合规性文档。
**常见反模式：**
+ 在部署工作负载时，未充分了解所选服务的责任共担模式。
+ 在虚拟机上托管数据库和其他技术，但没有评估具备相同功能的托管服务。
+ 在与托管服务方案对比时，虚拟机上托管技术的总拥有成本中没有包括安全管理任务。
**建立此最佳实践的好处：**使用托管服务可以减轻管理运营安全控制措施的整体负担，从而降低您的安全风险和总拥有成本。原本会用在某些安全任务上的时间，可以重新投入到能够为业务创造更多价值的任务上。托管服务还可以将一些控制要求转移给 AWS，从而减少您为满足合规性要求的工作范围。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
您可以通过多种方式将工作负载的组件集成到 AWS 上。如果您在 Amazon EC2 实例上安装和运行各种技术服务，那么在总体安全责任中，通常需要承担更大的份额。为了减轻运营某些控制措施的负担，请找出可以减少您在责任共担模式中所承担责任范围的 AWS 托管服务，并了解如何在现有架构中使用这些服务。例如，使用 [Amazon Relational Database Service（Amazon RDS）](https://aws.amazon.com/rds/)部署数据库，使用 [Amazon Elastic Kubernetes Service（Amazon EKS）](https://aws.amazon.com/eks/)或 [Amazon Elastic Container Service（Amazon ECS）](https://aws.amazon.com/ecs/)编排容器，或者使用[无服务器方案](https://aws.amazon.com/serverless/)。在构建新应用程序时，请仔细考虑哪些服务有助于减少实施和管理安全控制措施的时间及成本。
在选择服务时，合规性要求也可能是需要考虑的因素之一。托管服务可以将一些合规性要求转移给 AWS。请与合规团队讨论，了解他们对审核您所运营和管理的服务各个方面的满意程度，以及接受相关 AWS 审核报告中控制声明的满意程度。您可以将[AWS Artifact](https://aws.amazon.com/artifact/) 中的审核构件提供给审核人员或监管机构，作为 AWS 安全控制措施的证据。您还可以使用一些 AWS 审核构件提供的责任指导，并结合 [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) 来设计架构。这些指导可以让您了解到，为了支持系统的具体应用场景，您还应落实的其他安全控制措施。
使用托管服务时，您需要熟悉将这些服务的资源更新到新版本的过程（例如，更新 Amazon RDS 管理的数据库版本，或者更新 AWS Lambda 函数的编程语言运行时）。尽管托管服务可能会为您执行此操作，但配置更新时间以及了解这些更新会对您的运营产生何种影响，仍然是您的责任。您可以利用 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 等工具在整个环境中跟踪和管理这些更新。
### 实施步骤
1. 评估工作负载中可以用托管服务取代的组件。
1. 如果您将工作负载迁移到 AWS，则在评测是要重新托管、重构、更换平台、重新构建还是更换工作负载时，请考虑减少的管理工作（时间和开支）和降低的风险。从长远来看，在迁移开始时进行额外的投入，有时可以节省大量资金。
1. 请考虑实施 Amazon RDS 等托管服务，而不是安装和管理自己的技术部署。
1. 使用 AWS Artifact 中的责任指导来帮助确定应针对工作负载采取的安全控制措施。
1. 记录所使用资源的清单，及时了解新的服务和方法，以便发现减少责任范围的新机会。
## 资源
**相关最佳实践：**
+ [PERF02-BP01 为工作负载选择最佳计算方案](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_compute_hardware_select_best_compute_options.html)
+ [PERF03-BP01 使用最能满足数据访问和存储要求的专用数据存储](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_data_use_purpose_built_data_store.html)
+ [SUS05-BP03 使用托管服务](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_hardware_a4.html)
**相关文档：**
+ [Planned lifecycle events for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)
**相关工具：**
+ [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Artifact](https://aws.amazon.com/artifact/)
+ [AWS Customer Compliance Guides](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf)
**相关视频：**
+ [How do I migrate to an Amazon RDS or Aurora MySQL DB instance using AWS DMS?](https://www.youtube.com/watch?v=vqgSdD5vkS0)
+ [AWS re:Invent 2023 - Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
# SEC01-BP06 自动部署标准安全控制措施
在开发和部署 AWS 环境中的标准安全控制措施时，应用现代化 DevOps 实践。 使用基础设施即代码（IaC）模板定义和配置标准安全控制措施，收集版本控制系统中的更改，测试作为 CI/CD 管道一部分的更改，并自动将更改部署到您的 AWS 环境。
**期望结果：**使用 IaC 模板收集标准化的安全控制措施，并将其提交给版本控制系统。 在检测到变化的地方部署了 CI/CD 管道，并自动测试和部署 AWS 环境。 在继续部署之前，采取了防护机制来检查模板中的错误配置并发出警报。 工作负载部署到采用标准控制措施的环境中。 团队具有访问权限，可以通过自助服务机制部署经批准的服务配置。 制定了安全的备份和恢复策略，用于控制配置、脚本和相关数据。
**常见反模式：**
+ 通过 Web 控制台或命令行界面手动更改标准安全控制措施。
+ 依靠各个工作负载团队来手动实施中心团队定义的控制措施。
+ 依靠中心安全团队，根据工作负载团队的要求来部署工作负载级别的控制措施。
+ 允许相同的个人或团队开发、测试和部署安全控制措施自动化脚本，而没有采取适当的职责分离或制衡措施。
**建立此最佳实践的好处：**使用模板来定义标准安全控制措施，这样您就可以通过版本控制系统来跟踪和比较随时间发生的变化。 使用自动化功能来测试和部署更改，这样可以实现标准化程序及可预测性，增加成功部署的可能性，减少重复的手动任务。 为工作负载团队提供了自助服务机制来部署经批准的服务和配置，可减少配置错误和滥用的风险。这样还可以让团队在开发过程的早期融入控制措施。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
按照 [SEC01-BP01 使用账户分隔工作负载](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html)中描述的做法，您最终将多个 AWS 账户用于您通过 AWS Organizations 管理的不同环境。 虽然这些环境和工作负载可能会需要不同的安全控制措施，不过您可以对整个企业内的一些安全控制措施进行标准化。 这样的例子包括集成集中式身份提供程序、定义网络和防火墙，以及配置用于存储和分析日志的标准位置。 就像使用*基础设施即代码*（IaC）将同样严格的应用程序代码开发要求应用于基础设施预置一样，您也可以使用 IaC 来定义和部署标准安全控制措施。
尽可能以声明式方式（例如在 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 中）定义安全控制措施，并将这些安全控制措施存储在源代码控制系统中。 使用 DevOps 实践来自动部署控制措施，从而获得可预测性更强的发布，使用 [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 等工具自动进行测试，并检测已部署的控制措施与所需配置之间的偏差。 您可以使用 [AWS CodePipeline](https://aws.amazon.com/codepipeline/)、[AWS CodeBuild](https://aws.amazon.com/codebuild/) 和 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) 等服务来构造 CI/CD 管道。请参考[使用多个账户组织 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)中的指导，在每个服务自己的、独立于其他部署管道的账户中，配置这些服务。
您还可以定义模板来实现标准化的 AWS 账户、服务和配置的定义及部署。 利用这种技术，中心安全团队可以管理这些定义，并通过自助服务方法将这些定义提供给工作负载团队。 为此，您可以采取的一种方法是使用 [Service Catalog](https://aws.amazon.com/servicecatalog/)，将模板作为*产品*发布，供工作负载团队整合到自己的管道部署中。 如果使用的是 [AWS Control Tower](https://aws.amazon.com/controltower/)，则可以使用一些模板和控制措施作为起点。 Control Tower 还提供 [Account Factory](https://docs.aws.amazon.com/controltower/latest/userguide/af-customization-page.html) 功能，让工作负载团队可以使用您定义的标准创建新的 AWS 账户。 在工作负载团队确定了需要新账户时，此功能可以避免需要依赖中心团队来审批和创建新账户。 您可能需要通过这些账户，根据工作负载提供的功能、所处理数据的敏感性或其行为等原因，来隔离不同的工作负载组件。
## 实施步骤
1. 确定如何在版本控制系统中存储和维护模板。
1. 创建 CI/CD 管道来测试和部署模板。 定义测试方法，用于检查配置是否有误，以及模板是否符合公司标准。
1. 构建标准化模板目录，供工作负载团队根据您的要求部署 AWS 账户和服务。
1. 为控制配置、脚本和相关数据实施安全的备份和恢复策略。
## 资源
**相关最佳实践：**
+ [OPS05-BP01 使用版本控制](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_version_control.html)
+ [OPS05-BP04 使用构建和部署管理系统](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_build_mgmt_sys.html)
+ [REL08-BP05 使用自动化功能部署更改](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_automated_changemgmt.html)
+ [SUS06-BP01 采用可以快速引入可持续性改进的方法](https://docs.aws.amazon.com/wellarchitected/latest/framework/sus_sus_dev_a2.html)
**相关文档：**
+ [使用多个账户整理您的 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/deployments-ou.html)
**相关示例：**
+ [Automate account creation, and resource provisioning using Service Catalog, AWS Organizations, and AWS Lambda](https://aws.amazon.com/blogs/mt/automate-account-creation-and-resource-provisioning-using-aws-service-catalog-aws-organizations-and-aws-lambda/)
+ [Strengthen the DevOps pipeline and protect data with AWS Secrets Manager, AWS KMS, and AWS Certificate Manager](https://aws.amazon.com/blogs/security/strengthen-the-devops-pipeline-and-protect-data-with-aws-secrets-manager-aws-kms-and-aws-certificate-manager/)
**相关工具：**
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [Landing Zone Accelerator on AWS](https://github.com/awslabs/landing-zone-accelerator-on-aws)
# SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级
执行威胁建模，以识别并维护一个针对工作负载的潜在威胁和相关缓解措施的最新登记表。确定威胁优先级并调整安全控制缓解措施，用于防范、检测和响应。根据工作负载以及不断变化的安全环境，重新审视和维护此登记表。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
**什么是威胁建模？**
“威胁建模可识别、沟通和理解威胁及缓解措施，用于保护重要资产。” – [开源 Web 应用程序安全项目（OWASP）应用程序威胁建模](https://owasp.org/www-community/Threat_Modeling)
**为什么应该进行威胁建模？**
系统是复杂的，也会随着时间的推移会变得越来越复杂、越来越强大，从而提供更多业务价值，提高客户满意度和参与度。这意味着 IT 设计决策需要考虑数量不断增加的应用场景。由于复杂性和使用案例排列组合的数量过多，非结构化方法将通常无法有效地发现和减轻威胁。因此，您需要采用一种系统方法来列举对系统的潜在威胁，制定缓解措施并确定这些缓解措施的优先级，确保贵组织利用有限资源，在改善系统的整体安全态势方面发挥巨大作用。
威胁建模旨在提供这种系统方法，目的是在设计过程的早期发现和解决问题。此时与生命周期的后期相比，缓解措施的成本和工作量相对较低。这种方法与[*左移*安全实践](https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview)的行业原则相一致。最终，威胁建模将与组织的风险管理流程相互集成，并通过使用威胁驱动的方法，帮助您决定实施哪些控制措施。
**应在什么时候进行威胁建模？**
应在工作负载的生命周期中尽早开始进行威胁建模，这使您能够更灵活地处理已识别的威胁。就像软件漏洞一样，越早发现威胁，解决威胁的成本效益就越高。威胁模型是一个动态文档，应随着工作负载的变化而不断发展。随着时间的推移（包括当发生重大变更、威胁形势发生变化或您采用新功能或服务时），重新审视您的威胁模型。
### 实施步骤
**我们如何进行威胁建模？**
可以采用许多不同的方式来进行威胁建模。就像编程语言一样，每种方式都有优点和缺点，您应该选择最适合自己的方式。一种方法是从 [Shostack 的威胁建模 4 问题框架](https://github.com/adamshostack/4QuestionFrame)开始，该框架提出开放式问题，可为威胁建模工作提供结构：
1. **我们正在做什么？**
该问题旨在帮助您了解所构建的系统并达成一致意见，以及了解与安全性相关的系统细节。创建模型或图表是回答该问题的常用方法，因为这有助于对所构建的内容进行可视化，例如使用[数据流图](https://en.wikipedia.org/wiki/Data-flow_diagram)。写下关于系统的假设和重要细节也有助于定义范围内的内容。这使每个参与威胁建模的人员都能专注于同一件事，避免因在超出范围的主题（包括过时的系统版本）上走弯路而浪费时间。例如，如果您要构建一个 Web 应用程序，那么可能不值得花时间为浏览器客户端操作系统可信引导顺序进行威胁建模，因为您无法在设计中影响这一点。
1. **会出现什么问题？**
该问题可帮助您识别系统存在的威胁。威胁是指会产生不必要的影响，也可能影响系统安全的意外或故意行为或事件。如果不清楚哪里可能出现问题，您就无从应对。
对于可能出现的问题，并没有一个规范的列表。创建此列表需要团队中的所有个人和参与威胁建模工作的[相关角色](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/#tips)集思广益并展开协作。您可以通过使用识别威胁的模型（如 [STRIDE](https://en.wikipedia.org/wiki/STRIDE_(security))）来帮助集思广益，该模型建议了不同的评估类别：欺骗、篡改、抵赖、信息披露、拒绝服务和权限提升。此外，您可能希望通过回顾现有的列表和研究来帮助集思广益，寻找灵感，其中包括 [OWASP Top 10](https://owasp.org/www-project-top-ten/)、[HiTrust 威胁目录](https://hitrustalliance.net/hitrust-threat-catalogue/)和贵组织自己的威胁目录。
1. **我们要怎么做？**
与前面的问题一样，我们不可能得到包含所有缓解措施的规范清单。这一步骤需要考虑的是上一步中确定的威胁、威胁行动者和要改进的领域。
安全性和合规性是[您与 AWS 共同承担的责任](https://aws.amazon.com/compliance/shared-responsibility-model/)。重要的是要明白，当您问“我们要怎么做？”时，您也在问“谁负责做这件事？”。了解您和 AWS 之间的责任平衡有助于将威胁建模工作的范围限定在您控制的缓解措施范围内，这些缓解措施通常是 AWS 服务配置选项和您自己的系统特定缓解措施的组合。
对于共担责任中 AWS 应承担的部分，您会发现 [AWS 服务在许多合规计划的范围内](https://aws.amazon.com/compliance/services-in-scope/)。这些计划可帮助您理解 AWS 用以维持云安全性与合规性的可靠控制机制。AWS 客户可以从 [AWS Artifact](https://aws.amazon.com/artifact/) 下载这些计划的审核报告。
无论您使用哪项 AWS 服务，客户始终要承担一部分责任，并且与这些责任相一致的缓解措施应包含在威胁模型中。对于 AWS 服务自身的安全控制缓解措施，您需要考虑跨域实施安全控制措施，包括身份和访问管理（身份验证和授权）、数据保护（静态和传输中）、基础设施安全性、日志记录和监控等域。每项 AWS 服务的文档都包含一个[专门的安全章节](https://docs.aws.amazon.com/security/)，其中提供的安全控制机制指导可用作缓解措施。重要的是，需要考虑您正在编写的代码及其代码依赖项，并思考可以设置哪些控制机制来应对这些威胁。这些控制机制可以是[输入验证](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)、[会话处理](https://owasp.org/www-project-mobile-top-10/2014-risks/m9-improper-session-handling)和[边界处理](https://owasp.org/www-community/vulnerabilities/Buffer_Overflow)等内容。通常，大多数漏洞都是在自定义代码中引入，因此请重点关注这一领域。
1. **我们做得好吗？**
该问题旨在随着时间的推移，让您的团队和组织提高威胁模型的质量并加快执行威胁建模的速度。通过将实践、学习、教学和回顾相结合可以取得这些改进。要想深入了解并亲身体验，建议您和团队完成[“适合构建者的威胁建模方式”培训课程](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)或[讲习会](https://catalog.workshops.aws/threatmodel/en-US)。此外，如果您正在寻找如何将威胁建模集成到组织的应用程序开发生命周期中的指导，请参阅 AWS 安全博客上的《[How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)》一文。
**Threat Composer**
为了协助并指导执行威胁建模，您可以考虑使用 [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer) 工具，缩短进行威胁建模时实现价值的时间。该工具有助于您执行以下操作：
+ 撰写符合[威胁语法](https://catalog.workshops.aws/threatmodel/en-US/what-can-go-wrong/threat-grammar)、能够在自然非线性工作流程中发挥作用的有用威胁语句
+ 生成人类可读的威胁模型
+ 生成机器可读的威胁模型，允许您将威胁模型视为代码
+ 使用 Insights 控制面板协助您快速确定质量和覆盖范围有待改进的方面
如需更多参考，请访问 Threat Composer 并切换到系统定义的**示例工作区**。
## 资源
**相关最佳实践：**
+ [SEC01-BP03 识别并验证控制目标](sec_securely_operate_control_objectives.md)
+ [SEC01-BP04 随时了解安全威胁和建议](sec_securely_operate_updated_threats.md)
+ [SEC01-BP05 缩小安全管理范围](sec_securely_operate_reduce_management_scope.md)
+ [SEC01-BP08 定期评估并实施新的安全服务和功能](sec_securely_operate_implement_services_features.md)
**相关文档：**
+ [How to approach threat modeling](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)（AWS 安全博客）
+ [NIST: Guide to Data-Centric System Threat modeling](https://csrc.nist.gov/publications/detail/sp/800-154/draft)
**相关视频：**
+ [AWS Summit ANZ 2021 - How to approach threat modeling](https://www.youtube.com/watch?v=GuhIefIGeuA)
+ [AWS Summit ANZ 2022 - Scaling security – Optimise for fast and secure delivery ](https://www.youtube.com/watch?v=DjNPihdWHeA)
**相关培训：**
+ [Threat modeling the right way for builders – AWS Skill Builder virtual self-paced training](https://explore.skillbuilder.aws/learn/course/external/view/elearning/13274/threat-modeling-the-right-way-for-builders-workshop)
+ [Threat modeling the right way for builders – AWS 讲习会](https://catalog.workshops.aws/threatmodel)
**相关工具：**
+ [Threat Composer](https://github.com/awslabs/threat-composer#threat-composer)
# SEC01-BP08 定期评估并实施新的安全服务和功能
评估并实施 AWS 和 AWS 合作伙伴提供的安全服务和功能，以此改善工作负载的安全态势。
**期望结果：**已经采取标准做法，可获取 AWS 和 AWS 合作伙伴发布的新功能及服务的信息。针对环境和工作负载评估了这些新功能对当前和新控制措施的设计有何影响。
**常见反模式：**
+ 未订阅 AWS 博客和 RSS 源，无法及时了解相关的新功能和服务
+ 依赖二手来源来了解有关安全服务和功能的新闻与动态
+ 没有鼓励企业中的 AWS 用户随时了解最新动态
**建立此最佳实践的好处：**如果能够随时了解新的安全服务和功能，就可以针对云环境和工作负载中控制措施的实施，制定出明智的决策。大家可以通过这些来源提高对不断变化的安全形势的认识，以及了解如何使用 AWS 服务来防范新兴的威胁。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
AWS 通过多种渠道向客户告知新的安全服务和功能：
+ [AWS 的新功能](https://aws.amazon.com/new)
+ [AWS 新闻博客](https://aws.amazon.com/blogs/aws/)
+ [AWS 安全博客](https://aws.amazon.com/blogs/security/)
+ [AWS 安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS 文档概览](https://aws.amazon.com/documentation/)
您可以使用 Amazon Simple Notification Service（Amazon SNS）订阅 [AWS 每日功能更新](https://aws.amazon.com/blogs/aws/subscribe-to-aws-daily-feature-updates-via-amazon-sns/)主题，获取全面的每日更新摘要。一些安全服务（例如 [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_sns.html) 和 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-announcements.html)）会提供自己的 SNS 主题，方便您随时了解这些特定服务的新标准、调查发现和其他更新。
每年在全球举行的[会议、活动和网络研讨会](https://aws.amazon.com/events/)上，同样会公布和详细介绍新的服务及功能。每年的 [AWS re:Inforce](https://reinforce.awsevents.com/) 安全会议以及内容更全面的 [AWS re:Invent](https://reinvent.awsevents.com/) 会议尤其需要注意。前面提到的 AWS 新闻频道会分享这些有关安全和其他服务的会议公告，您可以在 YouTube 上的 [AWS Events 频道](https://www.youtube.com/c/AWSEventsChannel)上在线观看深度探讨分组会议，其中提供了丰富的信息。
您也可以向 [AWS 账户账户团队](https://aws.amazon.com/startups/learn/meet-your-aws-account-team)询问最新的安全服务更新和建议。如果没有这些团队的直接联系信息，您可以填写[销售支持表](https://aws.amazon.com/contact-us/sales-support/)与该团队取得联系。同样，如果您订阅了 [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/)，技术客户经理（TAM，Technical Account Manager）每周都会向您发布更新内容，而您也可以安排与他们定期开展审查会议。
### 实施步骤
1. 使用您最喜欢的 RSS 阅读器订阅各种博客和公告，或订阅每日功能更新 SNS 主题。
1. 评估要参加哪些 AWS 活动，获得有关新功能和服务的第一手信息。
1. 如果有任何有关更新安全服务和功能的问题，请安排与您的 AWS 账户团队进行讨论。
1. 请考虑订阅 Enterprise Support，这样就可以定期咨询技术客户经理（TAM）。
## 资源
**相关最佳实践：**
+ [PERF01-BP01 了解并掌握可用的云服务和功能](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_architecture_understand_cloud_services_and_features.html)
+ [COST01-BP07 及时了解新发布的服务](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management_scheduled.html)