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 Automate 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 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 テストを実施するかどうかを判断するためのコードを記述し、管理する必要があります。

次のステップ

Cloud Shell チュートリアルを試して Cloud Shell インスタンスに Chef InSpec をすばやくインストールし、CIS ベンチマークに基づいて Google Cloud プロジェクトのインフラストラクチャをスキャンする。
Google Cloud コンプライアンスリソースセンターにアクセスする。
エンタープライズ基盤ブループリントを読む。
Cloud アーキテクチャセンターで、リファレンスアーキテクチャ、図、ベストプラクティスを確認する。

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

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

Chef InSpec の概要

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

Chef InSpec テストを作成する

Cloud Build で Chef InSpec テストを実施する

Chef InSpec レポートを分析する

Chef InSpec と Security Command Center を統合する

パターン

Chef InSpec テストのスケジュールを設定する

CI / CD パイプラインと直接統合する

CI / CD パイプラインと間接的に統合する

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

次のステップ

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

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