デプロイを保護する

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

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

ランタイム環境を保護するには、デプロイ基準を使用してポリシーを定義し、デプロイの前後にポリシー コンプライアンスを検証します。事前定義済みの認証者によって署名されたコードのみを許可するポリシーを定義すると、デプロイの制御と、信頼できる生成元からのコードのみのデプロイに役立ちます。

デプロイ条件の例を以下に示します。

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

メタデータを生成する

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

ビルドの出所

ビルドの来歴は、ビルドされたイメージ ダイジェスト、入力ソースの場所、ビルド ツールチェーン、ビルド期間など、ビルドに関する検証可能なデータのコレクションです。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 などのコンテナベースのプラットフォームで実行されるアプリケーションです。デプロイするワークロードには、攻撃対象領域を制限する強化された構成を含めることが理想的です。

クラスタ全体のワークロードの確認では、構成の問題がないか手動で確認するのが難しい場合があります。Software Delivery Shield は、Google Cloud のフルマネージド ソフトウェア サプライ チェーン セキュリティ ソリューションです。Cloud Run のダッシュボードと Google Cloud コンソールの GKE UI を提供し、ワークロードのセキュリティ分析情報を表示します。

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

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

Software Delivery Shield には、ソフトウェア開発ライフサイクル全体を通してセキュリティ体制を改善するその他のサービスや機能も用意されています。詳細については、Software Delivery Shield の概要をご覧ください。

次のステップ