大规模治理：通过将策略作为代码来强制执行权限和合规性

作者：Roland Odorfer，发布于2023年12月13日，来自 Amazon Verified Permissions、最佳实践、中级200 及 安全、身份与合规性。永久链接 评论

关键要点

AWS 的身份和访问管理(IAM)政策是访问控制的核心，支持多个 AWS 帐户的权限设置。Amazon Verified Permissions 提供细粒度的授权和权限管理，简化审计和政策变更流程。使用“策略作为代码”方法可以自动化关键治理任务，如政策部署和审计。AWS Control Tower、AWS Config 和 AWS Security Hub 在合规性管理中发挥重要作用。

AWS 身份和访问管理IAM政策是 AWS 上访问控制的核心。它们通过帮助捆绑权限，提供有效且模块化的 AWS 服务访问控制。服务控制政策SCPs 补充 IAM 政策，帮助组织在大规模上强制执行权限界限，确保跨多个 AWS 帐户的安全性与合规性。

访问控制政策的使用并不仅限于 AWS 资源。运行在 AWS 基础设施上的客户应用程序同样可以使用政策来控制用户访问。然而，这通常涉及在程序代码中实施自定义授权逻辑，这会使审计和政策变更变得复杂。

为了解决这个问题，AWS 开发了 Amazon Verified Permissions，该服务有助于在客户应用程序中实施细粒度的授权和权限管理。它使用 Cedar一种开源政策语言将权限定义与应用程序代码分开。

除了访问控制，政策还可用于监控组织在安全性、运营和合规性方面的各项治理规则。例如，定期轮换加密密钥，以减少密钥泄露事件的影响。

然而，手动检查和实施这些规则非常复杂，并且难以扩展，尤其是在迅速增长的 IT 组织中。因此，组织应力求实现这些规则的自动化执行。本文将展示如何使用“策略作为代码”来管理 AWS 环境。

策略作为代码

与基础设施即代码IaC类似，策略作为代码是一种将策略视为常规程序代码的方法。您可以将策略定义为结构化文本文件策略文档，这些文档可以由策略引擎自动评估。

这一方法的主要优势在于能够自动化关键治理任务，如策略的部署、强制执行和审计。通过将策略文档存储在中央存储库中，您可以利用版本控制，简化审计，并跟踪政策变更。此外，还可以通过与持续集成CI和持续交付CD管道的集成，对新政策进行自动化测试。因此，策略作为代码构成了现代自动化 IT 治理战略的关键支柱之一。

接下来的章节将描述如何结合不同的 AWS 服务和功能，将策略作为代码集成到现有的 IT 治理流程中。

访问控制 AWS 资源

对 AWS 控制平面资源特别是 AWS API的每个请求无论是通过 AWS 管理控制台、AWS 命令行界面AWS CLI、或 SDK都通过 IAM 进行身份验证和授权。IAM 通过评估请求主体人类用户或工作负载及相应请求上下文的适用政策来决定是批准还是拒绝特定请求。这些策略以 JSON 文档的形式呈现，并遵循特定的架构，允许自动评估。

IAM 支持多种不同的政策类型，以帮助保护您的 AWS 资源并落实最小权限原则。有关各个政策类型及其用途的概述，请参见 IAM 中的政策和权限。有关如何及何时使用它们的一些实用指导，请参见 IAM 政策类型：如何及何时使用它们。要了解更多关于 IAM 政策评估过程的信息以及 IAM 检查各个政策类型的顺序，请见 政策评估逻辑。

传统上，IAM 依赖于 基于角色的访问控制RBAC 进行授权。使用 RBAC，主体被分配预定义角色，仅授予执行其职责所需的最低权限也称为最小权限原则。虽然 RBAC 起初似乎直观，但在大规模应用时可能会变得繁琐。每次新增 AWS 资源时，IAM 管理员都需手动更新每个角色的权限，这无疑会影响在动态环境中的灵活性。

相反，基于属性的访问控制ABAC 则根据分配给用户和资源的属性来基于权限。IAM 管理员定义了一项政策，当特定标签匹配时允许访问。ABAC 特别适用于已经超越 RBAC 模型的动态、快速成长的组织。要了解如何在 AWS 环境中实施 ABAC，请见 根据标签定义访问 AWS 资源的权限。

有关 AWS IAM 支持的服务及每项服务是否支持 ABAC 的列表，请参见 与 IAM 一起工作的 AWS 服务。

访问控制 客户应用程序

运行在 AWS 资源上的客户应用程序通常需要一种能够以细粒度控制访问自身及其各个功能的授权机制。

许多客户应用程序在自身应用代码中包含自定义授权机制，这会使政策变更的实施变得具有挑战性。这种做法也会阻碍监控和审计，因为授权逻辑的实现通常在不同应用程序之间有所不同，并且没有统一标准。

为了解决这一挑战，AWS 开发了 Amazon Verified Permissions 及相应的开源政策语言 Cedar。Amazon Verified Permissions 可以通过简单的 IsAuthorized API 调用替代应用程序代码中的自定义授权逻辑，因此您可以使用基于 Cedar 的政策集中控制和监控授权逻辑。要了解如何将 Amazon Verified Permissions 集成到您的应用程序中并使用 Cedar 定义自定义访问控制策略，请参见 如何使用 Amazon Verified Permissions 进行授权。

合规性

除了访问控制外，您还可以使用政策来帮助监控和执行组织在安全性、运营和合规性方面的个别治理规则。AWS Config 和 AWS Security Hub 在合规性管理中发挥着核心作用，因为它们能够建立符合最佳实践的多账户环境称为 着陆区。AWS Config 持续跟踪资源配置和变化，而 Security Hub 聚合和优先处理安全发现。有了这些服务，您可以创建启用自动化审计和合规检查的控制。或者，您也可以选择现成的控制，这些控制覆盖个人合规目标，例如静态加密，或涵盖整个框架，如 PCIDSS 和 NIST 80053。

AWS Control Tower 在 AWS Config 和 Security Hub 之上构建，帮助简化多账户环境的治理和合规性。AWS Control Tower 在现有控制的基础上还整合了其他控制，并通过统一界面呈现。这些控制适用于不同资源生命周期阶段，如图 1 所示，您可以通过政策来定义它们。

图 1：资源生命周期

控制可根据其行为进行分类：

主动控制 在部署前扫描 IaC 模板，以帮助及早识别不合规问题。预防控制 限制 AWS 环境内的操作，以帮助防止不合规行为。例如，这些控制可以阻止某些用户部署大型 Amazon Elastic Compute CloudAmazon EC2 实例或限制某些用户可用的 AWS 区域。侦测控制 监控已部署资源，以帮助识别主动和预防控制可能未能发现的不合规资源。它们还检测已部署资源的更改或随着时间的推移失去合规的情况。

这种控制分类方法使得合规框架更为全面，涵盖整个资源生命周期。每个控制适用的阶段决定了其如何帮助实施政策和治理规则。

通过 AWS Control Tower，您可以通过控制台一键启用数百个预配置的安全、合规性和操作控制，无需编写代码。此外，您也可以在 AWS Control Tower 提供的基础上实施自定义控制，具体实施方式视控制类型而定。接下来的章节将分别解释如何为每一类控制设置自定义控制。

主动控制

主动控制是扫描资源及其配置以确认其是否遵循合规要求的机制。AWS 提供了一系列工具和服务，供您单独使用或组合使用，以实施主动控制。以下图表提供了可用机制的概述，并示例其在 AWS Cloud Development Kit (CDK) 项目中的集成。

图 2：AWS CDK 项目中的 CI/CD 管道

如图 2 所示，您可以使用以下机制作为主动控制：

国外加速器下载

您可以通过使用 AWS CloudFormation Guard CLI 在本地机器上验证文档，例如 IaC 模板，从而支持 左移测试 策略。该方法的优势是在部署周期内较早地进行测试，支持快速迭代开发，从而缩短等待时间。

另外，您还可以使用 CfnGuardValidator 插件，将 CloudFormation Guard 规则集成到 AWS CDK CLI 中。这会在 CDK 项目中直接应用政策和最佳实践，简化本地开发。

为了集中执行验证检查，将 CfnGuardValidator 插件集成到 CDK CI/CD 管道中。

您还可以在 AWS CodeBuild 的 buildspecs 中调用 CloudFormation Guard CLI，在 CI/CD 管道中嵌入 CloudFormation Guard 扫描。

使用 CloudFormation hooks，在 CloudFormation 部署资源之前可以实施策略。

AWS CloudFormation Guard 使用策略作为代码的方法来评估 IaC 文档，如 AWS CloudFormation 模板和 Terraform 配置文件。该工具采用 Guard 语言定义验证规则，以确保这些 JSON 或 YAML 文档符合最佳实践和组织在云资源提供方面的政策。通过对规则进行编码并程序化扫描基础设施定义，CloudFormation Guard 实现政策的自动化执行，有助于在基础设施部署中提升一致性和安全性。

在以下示例中，您将使用 CloudFormation Guard 验证 CloudFormation 模板中 Amazon Simple Storage Service (Amazon S3) 存储桶的名称，以一种简单的 Guard 规则进行验证：

验证 S3 存储桶

在本地安装 CloudFormation Guard。有关于安装的说明，请参见 设置 AWS CloudFormation Guard。

创建一个名为 templateyaml 的 YAML 文件，其内容如下，并将 替换为您选择的存储桶名称此文件是创建 S3 存储桶的 CloudFormation 模板：

yamlResources S3Bucket Type AWSS3Bucket Properties BucketName ltDOCEXAMPLEBUCKETgt

创建一个名为 rulesguard 的文本文件，其内容如下：

yamlrule checkBucketName { ResourcesS3BucketPropertiesBucketName == ltDOCEXAMPLEBUCKETgt}

在本地终端运行以下命令，以验证 CloudFormation 模板是否符合 Guard 规则：

bashcfnguard validate rules rulesguard data templateyaml

如果 CloudFormation Guard 成功验证模板，validate 命令将返回状态 0 ( 在 bash 中)。否则，它将返回状态报告，列出未通过的规则。您可以通过更改存储桶名称自行测试此行为。

为了加快 Guard 规则的编写，可以使用 CloudFormation Guard 的 rulegen 命令，该命令以 CloudFormation 模板文件为输入，自动生成与模板资源属性匹配的 Guard 规则。要了解更多关于 CloudFormation Guard 规则的结构及其编写方法，请见 编写 AWS CloudFormation Guard 规则。

AWS Guard Rules Registry 提供现成的 CloudFormation Guard 规则文件，以加速您的合规之路，无需您自行编写规则。

通过 CDK 策略验证的插件接口，CfnGuardValidator 插件将 CloudFormation Guard 规则集成到 AWS CDK，并在合成步骤期间自动验证生成的 CloudFormation 模板。有关更多详细信息，请参见 插件文档 和 借助 AWS CDK 插件 CfnGuardValidator 加速开发。

单单使用 CloudFormation Guard 并不一定能阻止不合规资源的提供。这是因为 CloudFormation Guard 无法检测在验证后模板或其他文档的更改。因此，我建议您将 CloudFormation Guard 与更具权威性的机制结合使用。

其中一个机制是 CloudFormation hooks，您可以使用它在部署 AWS 资源之前进行验证。您可以配置 hooks，以便在 CloudFormation 模板不合规时取消部署过程并发出警报，或者只是触发警报但完成部署流程。关于 CloudFormation hooks 的更多信息，请参见以下博客帖子：

通过 AWS CloudFormation hooks 主动保持资源的安全和合规如何让 AWS Control Tower 用户主动验证 AWS CloudFormation 栈中的合规性

CloudFormation hooks 提供了一种强制执行通过 CloudFormation 部署的资源规则的方法。然而，它们并不控制通过控制台、CLI、SDK 或 API 进行的资源创建。例如，Terraform 是一种直接通过 AWS API 而不是通过 CloudFormation 模板提供资源的工具。因此，我建议您使用 AWS Config 实施额外的侦测控制。AWS Config 可以在部署后持续检查资源配置，无论其提供方法如何。使用 AWS Config 规则进一步补充了 CloudFormation hooks 的预防能力。

预防控制

预防控制可以通过施加合规性限制来帮助维护合规性。AWS Control Tower 与 [AWS Organizations](https//docsaws