Chef InSpec を使用した自動コンプライアンス テストのパターン

Last reviewed 2023-11-24 UTC

このドキュメントでは、Chef InSpec(オープンソースのインフラストラクチャ テスト フレームワーク)を使用して、Google Cloud リソースのポリシーとコンプライアンス チェックを自動化するパターンについて説明します。このドキュメントは、ソフトウェア開発ワークフローに継続的なコンプライアンス テストを統合することを目的とするアーキテクトや DevOps 従事者を対象としています。

Google Cloud のポリシーとコンプライアンス

Google Cloud には、ポリシーとコンプライアンス要件の適用と監査に役立つさまざまなツールが用意されています。

サービス 説明
リソース階層

リソース階層を使用して、会社の運用構造を Google Cloud にマッピングし、関連リソースのグループのアクセス制御と権限を管理できます。関連するリソースのグループを定義し、グループ内のすべてのリソースに一貫した制御を適用できます。

たとえば、Payment Card Industry Data Security Standard(PCI DSS)コンプライアンスの対象となるすべての Google Cloud プロジェクトを特定のフォルダにグループ化できます。そのフォルダ内のすべてのプロジェクトに関連する制御を適用できます。

組織のポリシー サービス

組織のポリシー サービスを使用して、Google Cloud サービスの可用性や機能を制限する制約を定義します。たとえば、リソース ロケーションの制約を使用して、仮想マシンなどのロケーション ベースのリソースを作成できる一連のリージョンを制限できます。

組織のポリシー サービスはリソース階層と連携します。階層のさまざまなレベルで組織のポリシーを適用できます。たとえば、PCI コンプライアンスの対象となるプロジェクトに組織のポリシーを定義し、そのポリシーを PCI フォルダに適用できます。

Security Command Center

Security Command Center を使用すると、すべての Google Cloud リソースを一元的に可視化できます。Security Command Center は既知の脆弱性についてクラウド リソースを自動的に分析し、セキュリティに関する検出結果を集約および管理するための単一のユーザー インターフェースとデータ プラットフォームを提供します。

Security Health Analytics では、PCI DSS などのコンプライアンス標準や、Center for Internet Security(CIS)ベンチマークなどの業界基準のモニタリングとレポート作成ができます。レポートは、コンプライアンス ダッシュボードで表示してエクスポートできます。

Security Command Center は複数のサードパーティ セキュリティ ソースと統合されており、API を備えているため、カスタム検出結果を追加して管理できます。Security Command Center では、セキュリティとコンプライアンスのすべての検出結果が統合インターフェースにまとめられています。

Config Sync

GKE Enterprise を使用している場合は、Config Sync を使用して、Git リポジトリで定義された構成と Kubernetes クラスタの同期を維持できます。Git リポジトリは、クラスタ構成とポリシーに関する信頼できる単一の情報源として機能します。Config Sync は GKE Enterprise 環境を継続的に監査し、リポジトリで定義されている構成から逸脱したクラスタを特定して修正します。

Policy Controller

GKE Enterprise を使用している場合は、Kubernetes の動的アドミッション コントローラである Policy Controller を使用して、完全にプログラム可能なポリシーをクラスタに適用できます。Policy Controller を使用すると、ポリシー要件を満たさないオブジェクトがクラスタ内に作成されるのを防止できます。たとえば、Pod セキュリティを適用するポリシーを作成できます。

Chef InSpec の概要

Chef InSpec は、コンプライアンス、セキュリティ、ポリシーの要件を指定するための、人が読める形式のドメイン固有の言語(DSL)を備えたオープンソースのインフラストラクチャ テスト フレームワークです。

Chef InSpec では次のことができます。

  • コンプライアンス要件をコードとして定義し、それらの要件に対してクラウド インフラストラクチャをテストします。
  • 本番環境に変更を push する前に、開発チームがアプリケーション固有のテストを追加し、セキュリティ ポリシーに対するアプリケーションのコンプライアンスを評価できるようにします。
  • リリース プロセスの一環として、CI / CD パイプラインでコンプライアンス検証を自動化します。
  • 他のクラウド環境でインフラストラクチャをテストするのと同じ方法で、Google Cloud インフラストラクチャをテストします。

Google Cloud には、Chef InSpec を使い始める際に役立つ複数のリソースがあります。

  • Google Cloud InSpec リソースパックには、Google Cloud オブジェクトに対して Chef InSpec テストを作成するためのベースライン リソースが含まれています。
  • Google Cloud InSpec CIS プロファイルには、Center InSpecs テストのセットが含まれています。このセットは、Center for Internet Security(CIS)ベンチマークに対する Google Cloud プロジェクトのセキュリティ ポスチャーを評価します。

Google Cloud で Chef InSpec を使用する際のベスト プラクティス

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 テストの作成には Chef InSpec DSL を使用します。これは、監査コントロール書き込み用の Ruby DSL です。

次のコードは、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 を使用すると、コンテナ イメージを実行し、ビルドステップを連結してパイプラインを形成できます。たとえば、1 つのビルドステップで Chef InSpec テストを実施し、その後、生成されたレポートをエクスポートまたは分析できます。ただし、Cloud Build を使用する必要はありません。Chef InSpec は、使用するどのツールとも統合できます。

次の Cloud Build 構成ファイルには、2 つのビルドステップを含むパイプラインが示されています。

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 リポジトリからテストを取得します。2 番目のビルドステップでは、生成されたレポートを Cloud Storage バケットにコピーします。

上記の例では、わかりやすくするためにすべてのコンテナ イメージの latest タグを参照しています。再現性のあるビルドにするために、ローリング バージョンではなく、コンテナ イメージの特定の固定バージョン(latest など)を参照することをおすすめします。

いずれかのテストが失敗した場合、Chef InSpec はエラーを返します。ビルドを不合格にする代わりに、最初のビルドステップで fail.marker ファイルを書き込むと、いずれかの Chef InSpec テストが失敗しても、2 番目のビルドステップが実行されます。ビルドを明示的に不合格にしてエラーを強調するには、最終ビルドステップで fail.marker ファイルをチェックし、ビルドが存在する場合はビルドを不合格にします。

Chef InSpec レポートを分析する

Chef InSpec のレポーターを構成すると、InSpec のテストと結果を記述する書式設定されたレポートが生成されます。これらのレポートを保存することで、履歴レコードを提供できます。また、これらのレポートを他のセキュリティ ツールとコンプライアンス ツールへの入力として使用することや、可視化またはアラートの生成にも使用することもできます。このドキュメントで後述するパターンでは、Chef InSpec レポートを Cloud Storage バケットに保存することをおすすめします。

次の図は、レポートを保存し、自動的に追加のアクションをトリガーする方法を示しています。

レポートによってトリガーされるイベント。

レポートを Cloud Storage バケットに追加すると、イベントが生成されます。このイベントに応じて、レポートをさらに操作または分析できます。上の図では、Chef InSpec テストの詳細を BigQuery に書き込む Cloud Functions の関数と、検出結果を Security Command Center に追加する Cloud Functions の関数をトリガーします。

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 が含まれています。Security Health Analytics では、Google Cloud プロジェクトとリソースを自動的にスキャンして一般的な脆弱性を検出します。たとえば、Security Health Analytics では、CIS Google Cloud Foundation 1.0 ベンチマークに対してプロジェクトを評価するスキャンを実施します。Google Cloud InSpec CIS プロファイルを使用して、同様のテストセットを実施することもできます。テストが Security Health Analytics によって実施されるチェックと重複しないように、Chef InSpec テストのスコープを比較する必要があります。

Chef InSpec の検出結果を Security Command Center に追加するには、いくつかの方法があります。

パターン

このセクションでは、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 パイプラインと直接統合する

多くの組織では、TerraformConfig Connector などのツールを使用して、インフラストラクチャのプロビジョニングと管理を自動化しています。通常、インフラストラクチャは、CI / CD パイプラインの一部としてのみ作成または変更されます。Google Cloud での CI / CD のコンセプトについては、GKE Enterprise を使用した最新の CI / CD をご覧ください。

このパターンでは、Chef Deployment パイプラインの追加のステップとして Chef InSpec テストを追加し、デプロイ パイプラインを実行するたびにインフラストラクチャを検証できます。コンプライアンス違反がある場合は、ビルドを不合格にできます。

次の図は、インフラストラクチャの変更を含む commit に基づいてデプロイ パイプラインがトリガーされる一般的なワークフローを示しています。

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 トピックに公開され、個々のビルドステップとその引数などのビルドに関する情報が含まれます。

次の図は、メッセージがビルド通知 Pub/Sub トピックに公開されるたびに自動的にトリガーされる Cloud Functions を作成する方法を示しています。

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 の関数を各プロジェクトにデプロイする必要があります。

Cloud Asset Inventory の通知に応じて Chef InSpec テストをトリガーする

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 の通知はほぼリアルタイムで配信されるため、コンプライアンス違反やポリシー違反をすばやく特定できます。
  • このパターンは、インフラストラクチャのプロビジョニングと管理に使用するプロセスとは独立して使用できます。Chef InSpec テストは、個々のデベロッパーや CI / CD パイプラインによってインフラストラクチャが作成または変更されたかどうかにかかわらず実施されます。
  • Cloud Asset Inventory では、組織全体または選択したフォルダやプロジェクトのリソースへの変更に関する通知を生成できます。変更の発生元のフォルダまたはプロジェクトに応じて、特定の Chef InSpec テストセットを実施できます。
  • このパターンは他のパターンと組み合わせて使用できます。たとえば、多くの組織では、開発環境またはサンドボックス環境には自動デプロイがありません。このパターンを使用して、選択した環境でポリシー チェックを行いながら、本番環境とステージング環境の CI / CD パイプラインを統合できます。

このパターンには、次の制限事項があります。

  • クラウド アセットに大量の変更を加えると、Chef InSpec テストは変更ごとにトリガーされる可能性があるため、このパターンは現実的ではありません。
  • Cloud Asset Inventory の通知メッセージを解析および分析して Chef InSpec テストを実施するかどうかを判断するためのコードを記述し、管理する必要があります。

次のステップ