基础架构即代码 (IaC) 改变了我们管理云操作的方式，通过一个配置文件，按需推出基础架构变得无比轻松和快捷。
我们将深入探讨采用 AWS 任何即代码模型所带来的底层堆栈带来的好处和安全挑战。我们还将介绍为任何堆栈提供基线安全控制 的最小可行安全( MVS ) 方法。
拥抱Everything-as-Code模型
根据 IaC 的原则，组织越来越多地为技术堆栈的不同组件采用代码框架，包括安全性、策略、合规性、配置和操作。AWS 支持各种 as-code 框架，包括他们自己的 CloudFormation、Terraform、Pulumi，甚至最近以 AWS CDK 的形式推出了他们的下一代 IaC。通过提供 API 来供应和管理资源，现在可以通过定义简单的、基于代码的模板来构建复杂的云架构。
借助环境即代码管道，组织可以利用相同的代码，通过单个工作流程跨多个区域和帐户管理和扩展其部署环境。
为基线安全控制采用最低可行安全
虽然 IaC 框架具有跨整个堆栈的自动化优势，可实现更快速的交付和更严格的控制，但保护每个环境都面临着一系列独特的挑战。最重要的是，随着围绕安全和漏洞不断产生的所有噪音和恐慌，刚起步的组织很难理解最低限度的关键控制，以及什么应该超出范围。最终结果是，努力推出其产品的第一个版本的新兴公司对他们实际需要实施的基线安全性知之甚少。
为了解决这个问题，MVS 方法提供了一个供应商中立的安全基线，可以降低部署基础架构时的复杂性和开销，特别是云（本机）环境。与敏捷方法类似，MVS 专注于关键安全控制的最小候选清单，为已发布的产品添加一些初始安全性以应对最常见的威胁。这种方法可帮助组织建立足够的安全态势，同时无缝集成到用于配置当今复杂的基于云的环境的现有自动化工具和管道中。
为了在实践中证明这一点，我们将通过自动化 MVS 方法展示如何在保护 AWS 实例（作为最流行和最广泛采用的云）时实际应用和工作。
如何将 AWS 环境保护为代码的最佳实践
我们已经确定了几个层面，我们将重点放在 AWS 环境的安全控制上，这些安全控制提供了所需的基线安全性，可以表示为代码，以在不影响速度的情况下自动引导 AWS 环境。
这些包括：
- 账户结构
- 身份和访问管理
- 用户创建和秘密管理
- 层次结构、治理和政策
- 访问控制
下面我们将逐个深入研究，以及我们如何最终在您现有的 IaC 和自动化管道中实现这些自动化。
构建安全的 AWS 账户结构
我们将在下面列出的许多实践都是经过验证的。首先，我们将 AWS 账户分为三个主要组织单位 (OU)：用户、沙盒和工作负载。
用户 OU 让我们托管一个专用帐户来设置所有用户。
沙盒单元用于开发或测试新的代码更改。此 OU 还可以托管用于试验代码模板和 CI/CD 管道的帐户。
工作负载单元包括登台/生产环境，并包含运行面向外部服务的各种帐户。
随着云工作负载的增长，DevOps 团队倾向于设置多个帐户以实现快速创新和灵活控制。使用多个 AWS 账户通过为计费、安全和资源访问提供自然边界，帮助开发运营团队实现隔离和独立。
在构建 AWS 账户时，建议采用以下做法：
使用组织单位 (OU) 将帐户分组为逻辑和层次结构。应根据类似和相关的功能而不是组织的报告层次结构来组织帐户。尽管 AWS 支持最多五个级别的 OU 深度，但最好保持尽可能低的结构深度以避免复杂性。
维护一个为管理所有组织单位和相关计费而创建的主帐户，以控制成本并便于维护。
将有限的云资源、数据或工作负载分配给组织的管理帐户或主帐户，以获得最大的安全性，因为组织的服务控制策略 (SCP) 不适用于管理帐户。
将生产和非生产工作负载环境相互隔离。AWS 工作负载通常包含在账户中，每个账户可以有多个工作负载。生产帐户应该有一个或几个密切相关的工作负载。通过分离工作负载环境，管理员可以保护生产免受未经授权的访问。
遵循身份和访问管理实践
为了管理对 AWS 资源的访问和权限，身份和访问管理 (IAM) 通过简化用户、角色和组的创建提供了第一道防线。通过自动化配置 AWS 环境时，组织应利用现有模块来管理 IAM 用户、角色和权限。
通过 IAM 管理强大的安全性：
- 确保用户、组或角色的 IAM 策略仅授予完成给定任务所需的权限——这种方法也被称为“最小权限”，并且有大量关于它的优秀材料。权限最初应该只包含所需的最少权限；如有必要，以后可以增加。
- 为每个 IAM 用户的不同任务创建单独的角色。
- 使用会话令牌作为授权的临时凭证。您还应该将会话令牌配置为具有较短的生命周期，以防止在发生妥协时被滥用。
- 不要使用根用户的访问密钥来执行常规活动或任何编程任务，因为根访问密钥授予对任何资源的所有 AWS 服务的完全访问权限。您还应该定期轮换 root 用户的访问密钥以防止误用。
- 如果允许帐户用户选择自己的密码，请确保有一个强大的基线密码策略和定期更改它的要求。
- 实施多因素身份验证 (MFA) 以提高安全性。MFA 在用户凭据之上添加了额外的身份验证层，并且在凭据被泄露的情况下将继续保护资源。
使用加密的秘密自动创建用户
为了降低与手动工作相关的风险，强烈建议组织采用自动化来创建用户。这可确保流程的所有阶段（包括帐户创建、配置和分配给 OU）都需要最少的人工干预。
自动化还通过与入职和离职用户工作流程集成来帮助简化用户体验。该机制允许跨多个环境（开发、暂存或生产）自动配置和验证 IAM 策略，从而在敏捷性和控制之间提供良好的平衡。
图 1：典型的用户创建流程（来源：亚马逊）
除了用户创建之外，您还应该自动化身份联合和秘密配置，以确保一个全面的用户创建周期。典型的工作流程类似于上述流程，并利用Keybase等工具自动加密凭证和密钥对，并由 Terraform 等 IaC 框架支持。]
使用 AWS Organizations 创建层次结构和策略
AWS Organizations 可帮助您实施精细控制，以可管理的方式构建账户。该服务基于组织单位 (OU) 为 AWS 资源提供增强的灵活性和层次结构。对于任何 AWS 组织，建议从具有核心 OU（如基础设施和安全性）的基本 OU 结构开始。
您还应该创建一个策略继承框架，允许在基础级别对 OU 进行最大访问，然后逐步限制对 OU 每一层的访问。这种策略分层可以进一步延续到账户和实例级别。
组织还应在 OU 而不是单个帐户上应用服务控制策略 (SCP)。SCP 提供了一种多层次的访问管理方法，因为它们提供了优先于 IAM 策略的冗余安全检查。
作为最佳实践，建议使用受信任的访问权限来授权整个组织的服务。这种机制有助于仅将权限授予指定的服务，而不会影响用户或角色的整体权限。随着工作负载的增长，您可以根据常见主题包括其他组织单位，例如：策略暂存、暂停帐户、个人用户、部署和过渡帐户。
安全远程访问 AWS 控制台
保护对 AWS 控制台的远程访问是在 AWS as-code 环境中维护安全性的最简单但最重要的部分之一。通过利用 AWS 管理控制台和 AWS Directory Service 对账户切换实施 IAM 策略，可以实现此处的最小化方法。登录后，根据用户的角色（只读或读写访问），此方法允许单个用户从控制台内切换帐户。
此外，您还可以通过用户账户和目标账户之间的信任策略强制执行 MFA，以确保只有启用了 MFA 的用户才能访问目标账户。
强制执行 AWS API 的安全访问
由于大多数 API 端点都是面向公众的，因此保护它们非常重要。始终建议通过实施强大的身份验证和授权机制来访问 API 来限制未经身份验证的 API 路由。除了利用各种 AWS 内置机制来保护公共和私有 API 终端节点外，您还应该采用最低限度的安全控制，例如使 MFA 能够使用 AWS CLI 或使用 AWS Vault 来保护密钥对。
除此之外，还有几种方法可以实现对 API 的受控访问。这些包括：
- 基于 IAM 的角色和策略权限
- Lambda 授权者
- 客户端 SSL 证书
- 强大的 Web 应用程序防火墙 (WAF) 规则
- 限制目标
- JWT 授权人
- 创建基于资源的策略以允许从特定 IP 或 VPC 进行访问
- API 密钥
AWS 安全性
各种计算组件的 as-code 模型允许您使用清单文件自动、一致且可预测地启动部署环境。尽管一切皆为代码的方法简化了 AWS 上资源的部署和管理，但作为此过程的一部分，安全性不容忽视，并且还应受益于自动化可以提供的护栏。
本文深入研究了 MVS 方法以及如何将其应用为代码。