本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 在部署 AWS 基础设施之前，实施集中式自定义 Checkov 扫描以强制执行策略 *Benjamin Morris，Amazon Web Services* ## Summary 这种模式提供了一个 GitHub 操作框架，用于在一个存储库中编写可在整个组织中重复使用的自定义 Checkov 策略。 GitHub 通过采用这种模式，信息安全团队可以根据公司要求编写、添加和维护自定义策略。自定义策略可以自动拉入 GitHub 组织中的所有管道。这种方法可用于在资源部署之前强制执行公司的资源标准。 ## 先决条件和限制 **先决条件** + 活跃的 AWS 账户 + 使用 “ GitHub 操作” 的 GitHub 组织 + AWS 使用 HashiCorp Terraform 部署的基础架构或 AWS CloudFormation **限制** + 此模式是为 GitHub 操作编写的。但是，它可以适应类似的持续集成和持续交付 (CI/CD) 框架，例如。 GitLab不需要特定的付费版本。 GitHub + 有些 AWS 服务 并非全部可用 AWS 区域。有关区域可用性，请参阅 AWS 文档中的[服务终端节点和配额](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html)，然后选择该服务的链接。 ## 架构 此模式旨在作为包含 GitHub 可重复使用的工作流程和自定义 Checkov 策略的 GitHub 存储库进行部署。可重复使用的工作流程可以扫描 Terraform 和 CloudFormation 基础设施即代码 (IaC) 存储库。 下图将**可重用 GitHub 工作流程存储库**和**自定义 Checkov 策略存储库**作为单独的图标显示。但是，您可以将这些存储库作为单独的存储库或单个存储库来实现。示例代码使用单个存储库，工作流文件 (`.github/workflows`) 和自定义策略文件（`custom_policies` 文件夹和 `.checkov.yml` 配置文件）位于同一个存储库中。 ![\[GitHub Actions 使用可重复使用 GitHub 的工作流程和自定义 Checkov 策略来评估 IaC。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/images/pattern-img/6c0c941f-14f9-4569-92da-9f81ab3e525c/images/a1539ce5-0ee6-4af1-bd01-cafad0f71708.png) 下图显示了如下工作流： 1. 用户在 GitHub 仓库中创建拉取请求。 1. 管道工作流程从 Acti GitHub ons 开始，包括对 Checkov 可重复使用工作流程的引用。 1. 管道工作流程从外部存储库下载引用的 Checkov 可重用工作流程，并使用 GitHub 操作运行该 Checkov 工作流程。 1. Checkov 可重复使用的工作流从外部存储库下载自定义策略。 1. Checkov 可重用工作流程根据内置和自定义 Checkov 策略评估 GitHub 存储库中的 IaC。Checkov 可重复使用的工作流通过还是失败取决于是否发现了安全问题。 **自动化和扩展** 此模式允许集中管理 Checkov 配置，以便于从单个位置应用策略更新。不过，此模式确实要求每个代码仓库都使用一个工作流，且该工作流需包含对中央可复用工作流的引用。您可以手动添加此引用，也可以使用脚本将文件推送到每个存储库的 `.github/workflows` 文件夹。 ## 工具 **AWS 服务** + [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)帮助您设置 AWS 资源，快速一致地配置资源，并在资源的整个生命周期中跨地区对其 AWS 账户 进行管理。Checkov 可以扫描 CloudFormation。 **其他工具** + [Checkov](https://www.checkov.io/) 是一款静态代码分析工具，用于检查 IaC 是否存在安全性和合规性配置错误。 + GitHub A@@ [c](https://github.com/features/actions) tions 已集成到 GitHub 平台中，可帮助您在 GitHub 仓库中创建、共享和运行工作流程。您可以使用 GitHub Actions 来自动执行诸如构建、测试和部署代码之类的任务。 + [Terraform](https://www.terraform.io/) 是一款 IaC 工具 HashiCorp ，可帮助您创建和管理云和本地资源。Checkov 可以扫描 Terraform。 **代码存储库** 此模式的代码可在 GitHub [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast)存储库中找到。 ## 最佳实践 + 为了保持一致的安全态势，请使贵公司的安全策略与 Checkov 策略保持一致。 + 在实施 Checkov 自定义策略的早期阶段，您可以在 Checkov 扫描中使用软失败选项来允许合并存在安全问题的 IaC。随着过程的成熟，从软失败选项切换到硬失败选项。 ## 操作说明 ### 为自定义策略创建中央 Checkov 存储库 | Task | 说明 | 所需技能 | | --- | --- | --- | | 创建一个中央 Checkov 存储库。 | 创建一个存储库来存储将在组织内使用的自定义 Checkov 策略。为了快速入门，您可以将此模式 GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)存储库的内容复制到中央的 Checkov 存储库中。 | DevOps 工程师 | | 为可重复使用的工作流创建存储库。 | 如果可重复使用的工作流的存储库已存在，或者您计划在与自定义 Checkov 策略相同的存储库中包含可重复使用的工作流文件，则可以跳过此步骤。创建 GitHub 存储库以保存可重复使用的工作流程。其他存储库的管道将引用此存储库。 | DevOps 工程师 | ### 创建可重复使用的 Checkov 工作流和示例 | Task | 说明 | 所需技能 | | --- | --- | --- | | 添加可重复使用的 Checkov 工作流。 | 在可重复使用的工作流程存储库中创建可重复 GitHub 使用的 Checkov Actions 工作流程（YAML 文件）。您可以从此模式中提供的工作流文件中调整此可重复使用的工作流。您可能想要进行的更改示例之一，是更改可重复使用的工作流以使用软失败选项。将 `soft-fail` 设置为 `true`，即使发生 Checkov 扫描失败仍允许作业成功完成。有关说明，请参阅 Checkov 文档中的[硬失败和软失败](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html)。 | DevOps 工程师 | | 添加示例工作流。 | 添加引用该 `reusable` 工作流的 Checkov 工作流示例。这将为 `reusable` 工作流的复用方式提供一个模板。在示例存储库中，`checkov-source.yaml` 是可重复使用的工作流，`checkov-scan.yaml` 是使用 `checkov-source` 的示例。有关编写示例 Checkov 工作流的更多详细信息，请参阅[其他信息](#centralized-custom-checkov-scanning-additional)。 | DevOps 工程师 | ### 将公司策略与 Checkov 自定义策略相关联 | Task | 说明 | 所需技能 | | --- | --- | --- | | 确定可以通过 Checkov 强制执行的策略。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)有关创建 Checkov 自定义策略的更多详细信息，请参阅 Checkov 文档中的[自定义策略概述](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)。 | 安全性与合规性 | | 添加 Checkov 自定义策略。 | 将已确定的公司策略转换为中央存储库中的自定义 Checkov 策略。您可以用 Python 或 YAML 编写简单的 Checkov 策略。 | 安全性 | ### 实现集中式 Checkov 自定义策略 | Task | 说明 | 所需技能 | | --- | --- | --- | | 将 Checkov 可重复使用的工作流添加到所有存储库。 | 此时，您应举出一个引用可重复使用工作流的 Checkov 工作流示例。将引用可重复使用工作流的示例 Checkov 工作流复制到每个需要它的存储库。 | DevOps 工程师 | | 创建一种机制来确保 Checkov 在合并之前运行。 | 为确保每个拉取请求都运行 Checkov 工作流程，请创建一个[状态检查](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)，要求在合并拉取请求之前成功执行 Checkov 工作流程。 GitHub 允许您要求在合并拉取请求之前运行特定的工作流程。 | DevOps 工程师 | | 创建组织范围的 PAT，并将其作为密钥共享。 | 如果您的 GitHub 组织是公开可见的，则可以跳过此步骤。这种模式要求 Checkov 工作流程能够从 GitHub 组织中的自定义策略存储库下载自定义策略。您必须提供相关权限，这样 Checkov 工作流才能访问这些存储库。为此，请创建拥有读取组织存储库权限的[个人访问令牌](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token)（PAT）。与存储库共享此 PAT，可以作为组织范围的密钥（如果是付费计划），也可以是每个存储库中的密钥（免费版本）。在示例代码中，密钥的默认名称为 `ORG_PAT`。 | DevOps 工程师 | | （可选）保护 Checkov 工作流文件不被修改。 | 为了保护 Checkov 工作流文件免受不必要的更改，您可以使用 `CODEOWNERS` 文件。`CODEOWNERS` 文件通常部署在目录的根目录中。例如，要要求在修改`checkov-scan.yaml`文件时获得 GitHub 组织`secEng`群组的批准，请将以下内容附加到存储库`CODEOWNERS`的文件中：
[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
`CODEOWNERS` 文件特定于其所在的存储库。为了保护存储库使用的 Checkov 工作流，必须在每个存储库中添加（或更新）一个 `CODEOWNERS` 文件。有关保护 Checkov 工作流文件的更多信息，请参阅[其他信息](#centralized-custom-checkov-scanning-additional)。有关`CODEOWNERS`文件的更多信息，请参阅您的 CI/CD 提供商的官方文档（例如 [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)）。 | DevOps 工程师 | ## 相关资源 + [Checkov 自定义策略概述](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) + [CloudFormation 配置扫描](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html) + [GitHub 操作可重复使用的工作流程](https://docs.github.com/en/actions/using-workflows/reusing-workflows) ## 附加信息 **编写 Checkov 工作流文件** 编写 `checkov-scan.yaml` 时，请考虑希望它何时运行。顶级 `on` 密钥决定工作流何时运行。在示例存储库中，当有针对 `main` 分支的拉取请求时（以及该拉取请求的源分支被修改时），就会运行该工作流。由于 `workflow_dispatch` 密钥的缘故，也可以根据需要运行该工作流。 您可以根据您希望的工作流运行频率来更改工作流触发条件。例如，您可以将工作流更改为每次将代码推送到任何分支时运行，方法是将 `pull_request` 替换为 `push` 并移除 `branches` 密钥。 您可以修改在单个存储库中创建的示例工作流文件。例如，如果存储库围绕 `production` 分支构造，则可以将目标分支的名称从 `main` 调整为 `production`。 **保护 Checkov 工作流文件** Checkov 扫描可提供有关潜在安全配置错误的有用信息。但是，一些开发人员可能会认为这是他们工作效率的障碍，因此试图删除或禁用扫描工作流。 有几种方法可以解决这个问题，包括更好地宣传安全扫描的长期价值，更清晰地记录如何部署安全基础设施。这些是重要的 “软” DevSecOps 协作方法，可以看作是解决这个问题根本原因的办法。但是，您也可以使用 `CODEOWNERS` 文件之类的技术控制措施作为护栏，帮助开发人员走在正确的道路上。 **在沙盒中测试模式** 要在沙盒环境测试此模式，请执行以下步骤： 1. 创建新 GitHub 组织。创建一个对组织中的所有存储库拥有只读访问权限的令牌。由于此令牌适用于沙盒环境，而非付费环境，因此您将无法将此令牌存储在组织级密钥中。 1. 创建一个 `checkov` 存储库来存放 Checkov 配置，并创建一个 `github-workflows` 存储库来存放可重复使用的工作流配置。使用示例存储库的内容填充存储库。 1. 创建一个应用程序存储库，然后将 `checkov-scan.yaml` 工作流复制并粘贴到其 `.github/workflows` 文件夹。向存储库中添加一个密钥，其中包含您为组织只读访问创建的 PAT。默认密钥为 `ORG_PAT`。 1. 创建一个拉取请求，向应用程序存储库中添加一些 Terraform 或 CloudFormation 代码。Checkov 应进行扫描并返回结果。