使用 Chef InSpec 进行自动合规性测试的模式

Last reviewed 2023-11-24 UTC

本文档介绍了使用 Chef InSpec（一种开源基础架构测试框架）自动执行 Google Cloud 资源的政策和合规性检查的模式。本文档适用于希望将持续合规性测试集成到其软件开发工作流中的架构师和 DevOps 从业人员。

Google Cloud 中的政策与合规性

Google Cloud 提供了一系列工具来帮助您强制执行和审核政策和合规性要求：

服务	说明
资源层次结构	您可以使用资源层次结构将公司的运营结构映射到 Google Cloud，并管理相关资源组的访问权限控制和权限。您可以定义相关资源组，并将统一控件应用于组中的所有资源。例如，您可以将符合支付卡行业数据安全标准 (PCI DSS) 的所有 Google Cloud 项目分组到特定文件夹中。然后，您可以将相关控件应用于该文件夹中的所有项目。
组织政策服务	您可以使用组织政策服务来定义限制 Google Cloud 服务的可用性或功能的限制。例如，您可以使用资源位置限制条件来限制哪些区域可以创建基于位置的资源（如虚拟机）。组织政策服务可与资源层次结构配合使用。您可以在层次结构的不同级层应用组织政策。例如，您可以为受 PCI 合规性的项目定义组织政策，然后将政策应用于 PCI 文件夹。
Security Command Center	您可以使用 Security Command Center 集中查看所有 Google Cloud 资源。Security Command Center 会自动分析您的云资源是否存在已知漏洞，并提供单一界面和数据平台来汇总和管理安全性问题。 Security Health Analytics 可以为 PCI DSS 等合规性标准以及互联网安全中心 (CIS) 基准等业界标准提供监控和报告。您可以在合规性信息中心内查看报告，然后导出报告。 Security Command Center 与多个第三方安全来源集成，并提供 API，以便您可以添加和管理自定义发现结果。Security Command Center 为您的所有安全性和合规性发现结果都提供了一个统一的界面。
Config Sync	如果您使用 GKE Enterprise，则可以使用 Config Sync 使 Kubernetes 集群与 Git 代码库中定义的配置保持同步。Git 代码库充当您的集群配置和政策的单一数据源。Config Sync 会持续审核 GKE Enterprise 环境，以识别和修复偏离代码库中定义的配置的集群。
Policy Controller	如果您使用 GKE Enterprise，则可以使用 Policy Controller（一种 Kubernetes 动态准入控制器）对集群强制执行完全可编程的政策。使用政策控制器，您可以防止在集群内创建不符合政策要求的对象。例如，您可以创建强制执行 Pod 安全性的政策。

Chef InSpec 简介

Chef InSpec 是一个开源基础架构测试框架，使用人类可读的领域特定语言 (DSL) 来指定合规性、安全性和政策要求。

利用 Chef InSpec，您可以执行以下操作：

将合规要求定义为代码，并根据这些要求测试您的云基础架构。
允许开发团队添加特定于应用的测试并评估其应用的安全政策，然后再将更改推送到生产环境。
在 CI/CD 流水线中以及作为发布流程的一部分时，自动执行合规性验证。
按照在其他云环境中测试基础架构的方法来测试 Google Cloud 基础架构。

Google Cloud 提供了多项资源来帮助您开始使用 Chef InSpec：

Google Cloud InSpec 资源包包含针对 Google Cloud 对象编写 Chef InSpec 测试的基准资源。
Google Cloud InSpec CIS 配置文件包含一组 Chef InSpecs 测试，这些测试会根据互联网安全中心 (CIS) 基准评估 Google Cloud 项目的安全状况。

将 Chef InSpec 与 Google Cloud 结合使用的最佳做法

以下是使用 Chef InSpec 的一般最佳做法：

定义并采用一个流程来修复 CheF InSpec 测试发现的违规行为。Chef InSpec 会突出显示违反政策和合规要求的行为，但不会执行任何补救措施。
向用于运行 Chef InSpec 测试的服务账号授予适当的 IAM 权限。例如，如果您要测试 Cloud Storage 存储桶，该服务账号必须具有适当的 Cloud Storage IAM 角色。
配置 Chef InSpec 报告器以生成描述测试和结果的格式化报告。您可以存储这些报告以提供历史记录。您还可以将这些报告用作其他安全与合规性工具的输入。例如，您可以将 Chef InSpec 与 Security Command Center 集成。
将相关的 Chef InSpec 测试分组为配置文件。您可以针对不同的使用情形创建不同的配置文件。例如，您可以在计划的夜间测试期间运行全面的端到端配置文件。或者，您可能运行一个更简短、更有针对性的配置文件来响应实时事件。

编写 Chef InSpec 测试

您可以使用 Chef InSpec DSL（一种用于编写审核控制的 Ruby DSL）编写 Chef InSpec 测试。

以下代码展示了用于验证 Cloud Storage 存储桶的特性的控件：

control 'policy_gcs_bucket' do
 title 'Cloud Storage bucket policy'
 desc 'Compliance policy checks for Cloud Storage bucket'
 impact 'medium'

 google_storage_buckets(project: project_id).bucket_names.each do |bucket|
   describe "[#{project_id}] Cloud Storage Bucket #{bucket}" do
     subject { google_storage_bucket(name: bucket) }
     its('storage_class') { should eq 'STANDARD' }
     its('location') { should be_in ['EUROPE-WEST2', 'EU'] }
     end
   end
 end

该控件指定了以下信息：

描述控件的元数据
故障的影响或严重程度
政策检查用于验证项目中每个 Cloud Storage 存储桶的特性

使用 Cloud Build 运行 Chef InSpec 测试

本文档中介绍的模式使用 Cloud Build 和 Chef InSpec 容器映像来运行 InSpec 测试。通过使用 Cloud Build，您可以运行容器映像，并将构建步骤链接在一起以形成流水线。例如，您可以在一个构建步骤中运行 Chef InSpec 测试，然后在后续步骤中导出或分析生成的报告。不过，您无需使用 Cloud Build。您可以将 Chef InSpec 与您使用的任何工具集成。

以下 Cloud Build 配置文件显示了包含两个构建步骤的流水线：

steps:
- id: 'run-inspec-cis'
  name: chef/inspec:latest
  entrypoint: '/bin/sh'
  args:
   - '-c'
   - |
     inspec exec https://github.com/GoogleCloudPlatform/inspec-gcp-cis-benchmark.git \
     --target gcp:// \
     --input gcp_project_id=${PROJECT_ID} \
     --reporter cli json:/workspace/report.json \
     --chef-license accept || touch fail.marker

- id: 'store-report'
  name: gcr.io/cloud-builders/gsutil:latest
  args:
   - cp
   - /workspace/report.json
   - gs://${_REPORTS_BUCKET}/cis-report-${BUILD_ID}.json

第一步是运行 Google Cloud CIS 基准测试，并生成 JSON 格式的报告。构建步骤使用 chef/inspec 容器映像，并从公共 Google Cloud CIS GitHub 代码库中提取测试。第二个构建步骤将生成的报告复制到 Cloud Storage 存储桶。

为简单起见，前面的示例对所有容器映像引用了 latest 标记。为了使构建可重现，我们建议您引用特定的固定容器映像版本，而不是滚动版本，例如 latest。

如果任何测试失败，Chef InSpec 将返回错误。第一个构建步骤会写入 fail.marker 文件，而不会使构建失败，即使任何 Chef InSpec 测试失败，第二个构建步骤也会运行。如果要明确失败构建以突出显示错误，您可以在最终构建步骤中检查 fail.marker 文件，如果构建存在，则失败。

分析 Chef InSpec 报告

您可以配置 Chef InSpec 报告器以生成描述 InSpec 测试和结果的格式化报告。您可以存储这些报告以提供历史记录。您还可以将这些报告用作其他安全和合规性工具的输入，或生成可视化或提醒。本文档后面介绍的模式建议将 Chef InSpec 报告存储在 Cloud Storage 存储桶中。

下图展示了如何存储报告并自动触发进一步操作。

由报告触发的事件。

将报告添加到 Cloud Storage 存储桶会生成事件。您可以触发对报告进一步的操作或分析，以响应此事件。在上图中，您触发的 Cloud Functions 函数将 Chef InSpec 测试的详细信息写入 BigQuery，以及另一个 Cloud Functions 函数将发现结果添加到 Security Command Center。

将 Chef InSpec 与 Security Command Center 集成

Security Command Center 是 Google Cloud 的规范安全和风险数据库。Security Command Center 可让您集中了解所有 Google Cloud 资源，并自动分析您的云端资源是否存在已知漏洞。我们建议您为组织启用 Security Command Center。

您可以将 Chef InSpec 测试的结果添加到 Security Command Center。Security Command Center 充当集中式数据平台，以聚合和管理来自多个来源的安全性发现结果。

Security Command Center 包括安全运行状况分析。Security Health Analytics 会自动扫描 Google Cloud 项目和资源是否存在常见漏洞。例如，Security Health Analytics 会运行扫描作业，以便根据 CIS Google Cloud Foundation 1.0 基准评估您的项目。您还可以使用 Google Cloud InSpec CIS 配置文件运行一组类似的测试。您应该比较 Chef InSpec 测试的范围，以确保测试不会重复 Security Health Analytics 执行的检查。

您可以通过以下几种方法将 Chef InSpec 发现结果添加到 Security Command Center：

使用 Chef Automatically for Security Command Center，将 Chef InSpec 测试结果自动集成到 Security Command Center 中。
使用 Security Command Center API 为 Chef InSpec 创建自定义源，然后创建发现结果以捕获 Chef InSpec 测试发现的任何违规行为。

模式

本部分介绍将 Chef InSpec 集成到您的日常操作中的模式。您可以组合使用这些模式来实现持续合规性测试。

安排 Chef InSpec 测试

在此模式中，您将按固定的时间表运行一组 Chef InSpec 测试。我们建议使用这种固定时间表方法作为开始使用 Chef InSpec 的好方法，因为您可以引入 Chef InSpec 测试，而无需修改现有流程。

下图展示了如何按计划运行测试。

安排 Chef InSpec 测试。

在上图中，您将创建一个按您的首选频率运行的 Cloud Scheduler 作业。每次作业运行时，它都会触发一个 Cloud Build 流水线，该流水线运行 Chef InSpec 测试并将测试报告输出到 Cloud Storage。如需了解详情，请参阅安排构建。

此模式具有以下优势：

您可以引入 Chef InSpec 测试，只需对现有流程进行最少的更改。
您可以将 Chef InSpec 测试与用于预配和管理基础架构和应用的任何流程无关。

此模式具有以下限制：

Chef InSpec 测试与基础架构预配分离，因此更难将特定的更改归因于失败的 Chef InSpec 测试。
Chef InSpec 测试仅定期运行，因此在识别合规性或违反政策行为之前可能会有一些延迟

直接与 CI/CD 流水线集成

许多组织使用 Terraform 或 Config Connector 等工具自动预配和管理其基础架构。通常，基础架构仅作为 CI/CD 流水线的一部分创建或更改。如需详细了解 Google Cloud 上的 CI/CD 概念，请参阅借助 GKE Enterprise 实现现代化 CI/CD。

在此模式中，您将 Chef InSpec 测试添加为基础架构部署流水线中的附加步骤，以便在运行部署流水线时验证基础架构。如有任何违规行为，您都可以使构建失败。

下图展示了一个常见工作流，其中根据包含基础架构更改的提交触发部署流水线。

将 Chef Inspec 与 CI/CD 流水线集成。

在上图中，基础架构更改应用于测试或预演环境，然后针对该环境运行 Chef InSpec 测试。如果所有 Chef InSpec 检查都符合要求，您可以合并基础架构更改并将其应用于生产环境，并且 Chef InSpec 测试针对生产环境再次运行。

此模式具有以下优势：

Chef InSpec 测试已直接集成到您的部署流程中，以便快速识别违规行为。
如果 Chef InSpec 测试未通过，您可以明确导致部署失败。

此模式具有以下限制：

Chef InSpec 测试直接与您的构建流水线集成，因此管理您的构建流水线的团队必须了解 Chef InSpec 测试
如果您有多个需要 Chef InSpec 测试的构建，则必须将 Chef InSpec 步骤添加到每个单独的构建中，这可能会使维护和扩展您的 Chef InSpec 工作变得更加困难。

与 CI/CD 流水线间接集成

此模式与先前模式类似，但不是在部署流水线中直接运行 Chef InSpec 测试，而是在单独的流水线中运行 Chef InSpec 测试。此单独的流水线由部署流水线触发。您可以将 Chef InSpec 逻辑与基础架构流水线分开，但仍然可以在部署工作流中运行合规性和政策测试。

Cloud Build 会在构建状态更改时（例如，创建构建时、构建转换到工作状态时、构建完成时）自动生成构建通知。通知消息会发布到 Pub/Sub 主题，并包含有关构建的信息，包括各个构建步骤及其参数。

下图展示了如何创建 Cloud Functions 函数，该函数会在消息发布到构建通知 Pub/Sub 主题时自动触发。

Chef InSpec 与 CI/CD 流水线的间接集成。

在上图中，该函数可以检查构建通知消息，然后在需要时触发 Chef InSpec 流水线。例如，您只想触发 Chef InSpec 流水线以响应包含特定构建步骤的成功构建。

此模式具有以下优势：

Chef InSpec 测试与部署流水线无关。管理部署流水线的团队无需与 Chef InSpec 互动。
您可以集中进行 Chef InSpec 测试，从而更轻松地维护和扩缩您的 Chef InSpec 工作。
您可以根据上游构建的结果和输出选择性地运行 Chef InSpec 测试。

此模式具有以下限制：

您必须编写和维护代码，以解析和分析构建通知消息，以确定是否运行 Chef InSpec 测试并将参数传递给 Chef InSpec 测试。
Cloud Build 通知会发布至同一项目的 Pub/Sub 主题。如果您在多个项目中有构建，则需要将 Cloud Functions 函数部署到每个项目中。

触发 Chef InSpec 测试以响应 Cloud Asset Inventory 通知

Cloud Asset Inventory 提供您的所有 Google Cloud 资源的资产清单。您可以使用 Cloud Asset Inventory 在 Google Cloud 项目、文件夹和组织中搜索、分析和导出资产及资产元数据。您还可以使用 Cloud Asset Inventory 发送有关云资源和政策的变更的实时通知。

下图展示了如何基于 Cloud Asset Inventory 的通知运行 Chef InSpec 测试。

基于通知触发 Chef InSpec 测试。

上图显示了如何获得关于不合规的任何新的或更新的云资源的近乎实时的反馈。您可以过滤通知，以便仅在特定类型的资源发生更改时收到通知。您可以使用这些通知触发特定于资源的目标 Chef InSpec 测试。例如，您可在创建 Cloud Storage 存储桶时运行一组特定的测试，并在 IAM 政策更新时运行一组不同的 Chef InSpec 测试。

此模式具有以下优势：

您可以根据对云资产的特定更改触发特定于资源的目标 Chef InSpec 测试。
Cloud Asset Inventory 通知几乎实时发送，因此可以快速识别任何合规性或政策违规行为。
您可以独立于用来预配和管理基础架构的任何过程来使用此模式。无论个人开发者还是 CI/CD 流水线创建或更改基础架构，Chef InSpec 测试都会运行。
Cloud Asset Inventory 可以生成有关整个组织中或从所选文件夹或项目中的资源更改的通知。您可以根据更改源自的文件夹或项目执行特定的 Chef InSpec 测试集。
您可以将此模式与其他模式结合使用。例如，许多组织没有在开发或沙盒环境中实施自动部署。您可以使用此模式对这些环境执行所选政策检查，同时与生产和预演环境进行持续集成/持续交付流水线集成。

此模式具有以下限制：

如果云资源发生大量更改，则此模式可能不可行，这是因为您的 Chef InSpec 测试可能由每次更改触发。
您必须编写并维护代码以解析和分析 Cloud Asset Inventory 通知消息以确定是否运行 Chef InSpec 测试

后续步骤

试用 Cloud Shell 演示，以在 Cloud Shell 实例中快速安装 Chef InSpec，并根据 CIS 基准扫描 Google Cloud 项目中的基础架构。
访问 Google Cloud 合规性资源中心。
阅读企业基础蓝图。
如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。