デプロイを保護する

このドキュメントでは、デプロイを保護するためのベスト プラクティスについて説明します。

デプロイ ポリシーを作成して適用する

ランタイム環境を保護するには、デプロイの条件を含むポリシーを定義し、デプロイの前後にポリシーのコンプライアンスを検証します。事前定義された構成証明者によって署名されたコードのみを許可するポリシーを定義すると、デプロイを制限し、信頼できる送信元からのコードのみをデプロイできます。

デプロイ条件の例:

  • 重大度が「中」以上の既知の脆弱性はない
  • ソースコードが信頼できるソース リポジトリから取得されている
  • 信頼できるビルドサービスがビルドを実行した
  • デプロイするビルド アーティファクトは信頼できるアーティファクト リポジトリからのものである

メタデータを生成する

これらの要件を検証するには、ビルド アーティファクトに関するメタデータを提供する必要があります。

ビルドの出所

ビルドの来歴は、ビルドされたイメージ ダイジェスト、入力ソースの場所、ビルド ツールチェーン、ビルド期間など、ビルドに関する検証可能なデータのコレクションです。セキュリティ対策を評価するためのフレームワークである SLSA は、来歴のモデルと来歴の要件を提供します。来歴はフレームワークの要件カテゴリの 1 つであり、各要件は SLSA レベルに関連付けられているため、緩和策を段階的に実装できます。

  • SLSA レベル 1 の保証の場合、来歴が使用可能である必要があります。
  • SLSA レベル 2 の保証の場合、来歴を生成し、使用者がその信頼性と整合性を検証できる必要があります。
  • SLSA レベル 3 と 4 では、来歴の署名と来歴データの詳細の深さに関する要件が厳格になります。

一部のビルドサービスでは、ビルドの来歴のメタデータが生成されます。

  • Google Cloud では、Cloud Build が SLSA レベル 3 のビルドをサポートするコンテナ イメージのビルドの来歴を生成し、署名します。
  • SLSA フレームワークには、GitHub の来歴ツールが用意されています。このツールは、SLSA レベル 3 のビルドおよび来歴のカテゴリの要件を満たす、GitHub 上に改ざん不可能な SLSA 来歴を生成します。
  • オープンソースの sigstore プロジェクトには、コンテナの署名に使用する cosign ツールが含まれています。
脆弱性

脆弱性スキャン ソフトウェアは、ソースコードとビルド アーティファクトで既知の脆弱性をチェックします。Artifact Analysis では、Artifact Registry に push されたコンテナ イメージの脆弱性が自動的にスキャンされます。脆弱性を保存する前にアーティファクトを確認するには、ローカル開発環境や CI/CD パイプラインで、Cloud Build ビルドステップなどの On-Demand Scanning API を使用します。

ポリシーの適用を設定する

デプロイ可能なアーティファクトに関するメタデータを取得したら、ポリシーを適用するツールが必要です。

Google Cloud では、デプロイの Binary Authorization でポリシーを構成できます。Binary Authorization は、サポートされているコンテナベースのプラットフォームへのデプロイの試行に対してポリシーを適用します。GKE、Cloud Run、GKE Enterprise で実行されているワークロードのポリシーの継続的な検証を行うこともできます。

デプロイ前のチェックでは、除外イメージリストにないすべてのイメージをブロックして、信頼できるレジストリから信頼できるイメージのみをデプロイできます。ポリシーには、特定の必須プロセスを使用してイメージが正常にビルドされたことを示す証明書も要求できます。たとえば、構成証明は、イメージが次のいずれかであることを示します。

継続的検証は、ポリシー検証をデプロイ後の環境に拡張します。有効にすると、Binary Authorization は Cloud Logging にポリシーの適合性を定期的に記録することで、Pod のライフサイクル全体で検証を行います。これはさまざまな状況で役立ちます。 たとえば、コンテナのデプロイ後にポリシーを変更すると、更新されたポリシーに違反する Pod が継続的な検証によってログに記録されます。また、ドライランまたはブレークグラスでデプロイされた Pod のポリシー違反もログに記録されます。

ゲート付きデプロイ サービスを使用する

デプロイ ゲーティングを使用すると、スタンドアロンの CI/CD サービスまたはプロセス自動化システムと統合された CI/CD サービスを使用して、デプロイ プロセスの特定の時点でデプロイを承認または拒否できます。ゲート付きデプロイにより、未承認のユーザーはアプリケーション環境を変更できなくなります。これらのユーザーはデプロイ プロセスをさらに監視して、承認の可視性を高めます。

Google Cloud では、Cloud Deploy によって、Google Kubernetes Engine にワークロードをデプロイするためのフルマネージド サービスが提供されます。ゲート付きデプロイ機能では、ターゲットへの昇格に承認が必要かどうかを指定できます。

ワークロードをモニタリングする

ワークロードは、GKE や Cloud Run などのコンテナベースのプラットフォームで実行されるアプリケーションです。デプロイするワークロードには、攻撃対象領域を制限する強化された構成を含めることが理想的です。

クラスタ全体のワークロードの確認では、構成の問題がないか手動で確認するのが難しい場合があります。Google Cloud には、Cloud Run と GKE のダッシュボードがあり、ワークロードのセキュリティ分析情報を表示できます。

GKE セキュリティ ポスチャー ダッシュボードには、Google の推奨事項に基づいてクラスタのセキュリティ対策を強化するためのガイダンスが示されます。これには自動ワークロード構成スキャンが含まれ、これによりすべてのワークロードで既知の構成の問題が確認されます。GKE は、デプロイされた各ワークロードを、Pod セキュリティ標準のポリシーなどの関連する業界のベスト プラクティスと照合します。 GKE は検出された問題の重大度を評価し、対処可能な推奨事項とログを返します。Cloud Logging を使用して、懸念事項に関する監査証跡を確認できます。これにより、レポーティングとオブザーバビリティが改善されます。GKE セキュリティ対策ダッシュボードでセキュリティ分析情報を表示する手順については、GKE にデプロイしてセキュリティ分析情報を表示するをご覧ください。

Cloud Run には、SLSA ビルドレベルのコンプライアンス情報、ビルドの来歴、実行中のサービスで見つかった脆弱性などのソフトウェア サプライ チェーンのセキュリティ分析情報を表示するセキュリティ パネルが含まれています。Cloud Run のセキュリティ分析情報パネルでセキュリティ分析情報を表示する手順については、Cloud Run にデプロイしてセキュリティ分析情報を表示するをご覧ください。

Google Cloud には、ソフトウェア開発ライフサイクル全体でセキュリティ対策を改善する他のサービスや機能も提供されています。詳細については、ソフトウェア サプライ チェーンの概要をご覧ください。

次のステップ