デプロイ パイプラインは、コードまたはビルド済みのアーティファクトを取得してテスト環境または本番環境にデプロイする自動化されたプロセスです。デプロイ パイプラインは、アプリケーション、構成、クラウド インフラストラクチャ（Infrastructure as Code）のデプロイで一般的に使用され、クラウド デプロイの全体としてのセキュリティ ポスチャーにおいて重要な役割を果たします。
このガイドは、DevOps とセキュリティ エンジニアを対象としており、機密性、完全性、可用性の要件に基づいて安全なデプロイ パイプラインを設計するためのベスト プラクティスについて説明します。
アーキテクチャ
次の図は、デプロイ パイプライン内のデータの流れを示しています。アーティファクトをリソースに変える方法を示しています。
デプロイ パイプラインは、多くの場合、より大きな継続的インテグレーション / 継続的デプロイ（CI / CD）ワークフローの一部であり、通常は次のいずれかのモデルを使用して実装されます。
push モデル: このモデルでは、Jenkins や GitLab などの中央 CI / CD システムを使用してデプロイ パイプラインを実装します。この CI / CD システムは、Google Cloud、オンプレミス、または別のクラウド環境で実行できます。多くの場合、複数のデプロイ パイプラインの管理に同じ CI / CD システムが使用されます。
push モデルを使用すると、大量のリソースやアプリケーションを管理することができる少数の CI / CD システムを備えた一元的なアーキテクチャを実現できます。たとえば、単一の Jenkins または GitLab インスタンスを使用して、すべてのプロジェクトやアプリケーションを含む本番環境全体を管理できます。
pull モデル: このモデルでは、デプロイ プロセスはリソースと一緒にデプロイされるエージェントによって実装されます（例: 同じ Kubernetes クラスタ内）。エージェントは、一元化された場所からアーティファクトやソースコードを pull し、ローカルにデプロイします。各エージェントは 1 つまたは 2 つのリソースを管理します。
pull モデルは、潜在的に多数の単一目的のエージェントがあるより分散型のアーキテクチャになります。
手動デプロイと比較して、デプロイ パイプラインを一貫して使用すると次のような利点があります。
- 手動での作業が不要なため、効率性が向上します。
- プロセスが完全に自動化され、再現性があるため、信頼性が向上します。
- コードの変更や入力アーティファクトに対するすべてのデプロイをトレースできるため、トレーサビリティが向上します。
デプロイ パイプラインを実行するには、管理するリソースへのアクセス権が必要です。
- Terraform などのツールを使用してインフラストラクチャをデプロイするパイプラインでは、VM インスタンス、サブネット、Cloud Storage バケットなどのリソースの作成、変更、削除が必要になることがあります。
- アプリケーションをデプロイするパイプラインで、新しいコンテナ イメージを Artifact Registry にアップロードし、新しいアプリケーション バージョンを App Engine、Cloud Run または Google Kubernetes Engine（GKE）にデプロイすることが必要になる場合があります。
- 設定の管理や構成ファイルのデプロイを行うパイプラインでは、VM インスタンス メタデータ、Kubernetes 構成の変更や、Cloud Storage 内のデータの変更が必要になる場合があります。
デプロイ パイプラインが適切に保護されていない場合、Google Cloud リソースへのアクセスがセキュリティ ポスチャー上の弱点になる可能性があります。弱いセキュリティは、次のような数種類の攻撃につながる可能性があります。
パイプライン ポイズニング攻撃: 不正な行為者は、リソースを直接攻撃する代わりに、デプロイ パイプライン、その構成、基盤となるインフラストラクチャを侵害しようとする可能性があります。不正な行為者は、パイプラインから Google Cloud にアクセスする仕組みを悪用して、以下の図に示すようにパイプラインからクラウド リソースに対して悪意のあるアクションを実行する可能性があります。
サプライ チェーン攻撃: 次の図に示すように、不正な行為者が、デプロイ パイプラインを攻撃する代わりに、ソースコード、ライブラリ、コンテナ イメージなどのパイプライン入力を不正使用または置き換えようとする可能性があります。
デプロイ パイプラインが適切に保護されているかどうかを判断するには、Google Cloud リソースの許可ポリシーと拒否ポリシーのみを単独で確認するだけでは不十分です。代わりに、リソースへのアクセス権を直接的または間接的に付与するシステムのグラフ全体を考慮する必要があります。このグラフには次の情報が含まれます。
- デプロイ パイプラインと、その基盤となる CI / CD システムおよび基盤となるインフラストラクチャ
- ソースコード リポジトリと、その基盤となるサーバーおよび基盤となるインフラストラクチャ
- 入力アーティファクトと、そのストレージの場所および基盤となるインフラストラクチャ
- 入力アーティファクトを生成するシステムと、その基盤となるインフラストラクチャ
複雑な入力グラフにより、リソースへのユーザー アクセスとシステム上の脆弱性を特定することが困難になります。
以下のセクションでは、グラフのサイズを管理し、ラテラル ムーブメントやサプライ チェーン攻撃のリスクを軽減するために役立つデプロイ パイプラインを設計するためのベスト プラクティスについて説明します。
評価を通してセキュリティ目標を定める
Google Cloud のリソースは、それぞれ必要なセキュリティ レベルが異なる可能性があります。たとえば、ビジネス クリティカルであるため、または機密性が高いため、セキュリティ レベルが高いリソースがあります。エフェメラルであるため、またはテストのみを目的としているため、セキュリティ レベルが高くないリソースもあります。
安全なデプロイ パイプラインを設計するには、まず、パイプラインがアクセスする必要があるリソースと、これらのリソースのセキュリティ レベルを理解する必要があります。リソースのセキュリティ レベルが高いほど、パイプラインの保護に注力する必要があります。
デプロイ パイプラインによってアクセスされるリソースには、次のものがあります。
- Cloud Run や App Engine などのアプリケーション
- VM インスタンスや Cloud Storage バケットなどのクラウド リソース
- Cloud Storage オブジェクト、BigQuery レコード、ファイルなどのデータ
これらのリソースの一部には、他のリソースとの依存関係がある場合があります。次に例を示します。
- アプリケーションは、データ、クラウド リソース、その他のアプリケーションにアクセスすることがあります。
VM インスタンスや Cloud Storage バケットなどのクラウド リソースには、アプリケーションやデータが含まれる場合があります。
上図に示すように、依存関係はリソースのセキュリティ レベルに影響します。たとえば、センシティブ データにアクセスするアプリケーションを使用する場合は、通常、そのアプリケーションを非常にセキュリティ レベルが高いものとして扱う必要があります。同様に、Cloud Storage バケットなどのクラウド リソースにセンシティブ データが含まれている場合は、通常、そのバケットをセキュリティ レベルが高いものとして扱う必要があります。
このような依存関係があるため、最初にデータのセキュリティ レベルを評価することをおすすめします。データを評価したら、依存関係チェーンを調べて、クラウド リソースとアプリケーションのセキュリティ レベルを評価します。
データのセキュリティ レベルを分類する
デプロイ パイプライン内のデータのセキュリティ レベルを理解するためには、以下の 3 つの目標を考慮します。
- 機密性: データを不正アクセスから保護する必要があります。
- 完全性: 不正な変更や削除からデータを保護する必要があります。
- 可用性: 承認されたユーザーとシステムがデプロイ パイプラインのデータにアクセスできるようにする必要があります。
これらの目標ごとに、パイプラインが侵害された場合にどうなるかを考えてみてください。
- 機密性: データが不正な行為者に開示された場合や、一般に漏洩した場合、どの程度の損害が発生するか。
- 完全性: 不正な行為者がデータを変更または削除した場合、どの程度の損害が発生するか。
- 可用性: 不正な行為者がデータアクセスを中断した場合、どの程度の損害が発生するか。
リソース間で結果を比較できるようにするには、セキュリティ カテゴリを導入すると便利です。セキュリティ分類の標準（FIPS-199）では、次の 4 つのカテゴリの使用が推奨されています。
- 高: 損害が重大または壊滅的なものである
- 中: 損害は深刻である
- 低: 損害が限定される
- 該当なし: 標準は適用されない
環境とコンテキストによっては、別のカテゴリセットのほうが適切な場合があります。
パイプライン データの機密性と完全性は、前述のセキュリティ カテゴリに基づいたスペクトルで存在します。次のサブセクションには、機密性と完全性の測定値が異なるリソースの例が含まれています。
機密性は低いものの、完全性が低いか、中程度か、高いリソース
次のリソースの例はすべて機密性が低くなります。
- 低い完全性: テストデータ
- 中程度の完全性: 公開ウェブサーバーのコンテンツ、組織のポリシーの制約
- 高い完全性: コンテナ イメージ、ディスク イメージ、アプリケーション構成、アクセス ポリシー（許可リストと拒否リスト）、リーエン、アクセスレベル データ
機密性は中程度であるものの、完全性が低いか、中程度か、高いリソース
次のリソースの例の機密性はすべて中程度です。
- 低い完全性: 内部ウェブサーバーのコンテンツ
- 中程度の完全性: 監査ログ
- 高い完全性: アプリケーション構成ファイル
機密性は高いものの、完全性が低いか、中程度か、高いリソース
次のリソースの例はすべて機密性が高くなっています。
- 低い完全性: 使用状況データと個人情報
- 中程度の完全性: Secret
- 高い完全性: 財務データ、KMS 鍵
アクセスするデータに基づいてアプリケーションを分類する
アプリケーションがセンシティブ データにアクセスすると、アプリケーションとアプリケーションを管理するデプロイ パイプラインもセキュリティ レベルが高くなる可能性があります。必要なセキュリティ レベルを判断するためには、アプリケーションとパイプラインがアクセスする必要があるデータについてセキュリティ レベルを確認します。
アプリケーションがアクセスするすべてのデータを特定して分類したら、最初に以下のカテゴリを使用してアプリケーションを分類してから、安全なデプロイ パイプラインを設計します。
- 機密性: アクセスされるデータの最も高いカテゴリ
- 完全性: アクセスされるデータの最も高いカテゴリ
- 可用性: アクセスされるデータの最も高いカテゴリ
この初期評価ではガイダンスが提供されますが、他にも次のような要素を考慮する必要があります。
- 2 セットのデータがあり、それぞれ個別にみると機密性が低くても、組み合わせるとまったく新しい意味を帯びることがあります。アプリケーションが両方のデータセットにアクセスできる場合は、機密性を「中程度」または「高」に分類する必要がある場合があります。
- アプリケーションが完全性の高いデータにアクセスできる場合は、通常、アプリケーションを高い完全性に分類する必要があります。ただし、そのアクセス権が読み取り専用の場合、高い完全性の分類が厳しすぎる可能性があります。
アプリケーションを分類する形式化されたアプローチの詳細については、情報および情報システムの種類をセキュリティ カテゴリにマッピングするためのガイド（NIST SP 800-60 Vol. 2 Rev1）をご覧ください。
ホストするデータとアプリケーションに基づいてクラウド リソースを分類する
Google Cloud にデプロイするデータやアプリケーションは、Google Cloud リソースでホストされます。
- アプリケーションは、App Engine サービス、VM インスタンス、または GKE クラスタによってホストされている場合があります。
- データは、永続ディスク、Cloud Storage バケット、BigQuery データセットによってホストされます。
クラウド リソースでセンシティブ データやアプリケーションをホストすると、そのリソース、およびリソースを管理するデプロイ パイプラインもセキュリティ レベルが高くなる可能性があります。たとえば、Cloud Run サービスとそのデプロイ パイプラインは、ホストされているアプリケーションと同程度のセキュリティ レベルであるとみなすことができます。
データとアプリケーションを分類した後、アプリケーションの初期セキュリティ カテゴリを作成します。その場合は、次のカテゴリからレベルを決定します。
- 機密性: ホストされているデータまたはアプリケーションの最高カテゴリ
- 完全性: ホストされているデータまたはアプリケーションの最高カテゴリ
- 可用性: ホストされているデータまたはアプリケーションの最高カテゴリ
初期評価を行うときは、あまり厳格にしないでください。次に例を示します。
- 機密性の高いデータを暗号化する場合は、暗号鍵を機密性が高いものとして扱います。ただし、データを含むリソースには、低いセキュリティ カテゴリを使用できます。
- データの冗長コピーを保存するか、複数のリソースにまたがって同じアプリケーションの冗長インスタンスを実行する場合は、リソースのカテゴリを、ホストするデータまたはアプリケーションのカテゴリよりも低くできます。
デプロイ パイプラインの使用を制限する
デプロイ パイプラインでセキュリティ レベルの高い Google Cloud リソースにアクセスする必要がある場合は、パイプラインのセキュリティ ポスチャーを検討する必要があります。リソースのセキュリティ レベルが高いほど、パイプラインのセキュリティをより強固にする必要があります。ただし、次のような実質的な制限が適用される場合があります。
- 既存のインフラストラクチャまたは既存の CI / CD システムを使用する場合、そのインフラストラクチャによって現実的に達成できるセキュリティ レベルが制限される可能性があります。たとえば、CI / CD システムでサポートされているセキュリティ管理機能が限られている場合や、CI / CD システム自体が一部の本番環境よりも安全性が低いと考えられるインフラストラクチャで実行されている場合があります。
- デプロイ パイプラインを実行するために新しいインフラストラクチャやシステムを設定する場合、最も厳しいセキュリティ要件を満たすようにすべてのコンポーネントを保護すると、費用対効果が低くなる可能性があります。
このような制限がある場合は、制約条件を定義して、デプロイ パイプラインおよび特定の CI / CD システムを使用すべきシナリオと、使用すべきでないシナリオを判断すると便利です。たとえば、多くの場合、最高セキュリティ レベルのデプロイは、デプロイ パイプライン外部で処理する方が適切です。このようなデプロイは、特権セッション管理システムや特権アクセス管理システム、あるいはツールプロキシなどを使用して、手動で行うことができます。
制約を設定するには、リソース カテゴリに基づいて適用するアクセス制御を定義します。次の表のガイダンスをご覧ください。
| リソースのカテゴリ | アクセス制御 |
|---|---|
| 低 | 承認は不要 |
| 適度 | チームリーダーが承認する必要がある |
| 高 | 複数のリーダーが承認し、アクションを記録する必要がある |
以下のような問いかけを通して、これらの要件をソースコード管理（SCM）システムや CI / CD システムの機能と比較して検討します。
- SCM システムまたは CI / CD システムは、必要なアクセス制御と承認メカニズムをサポートしていますか？
- 不正な行為者が基盤となるインフラストラクチャを攻撃した場合、制御の仕組みに対するセキュリティ侵害を防ぐことができますか？
- 制御の仕組みを定義する構成は適切に保護されますか？
SCM システムまたは CI / CD システムの機能と制限事項に応じて、デプロイ パイプラインのデータとアプリケーションの制約を定義できます。次の表でガイダンスをご確認ください。
| リソースのカテゴリ | 制約 |
|---|---|
| 低 | デプロイ パイプラインを使用でき、デベロッパーはデプロイを自己承認できます。 |
| 適度 | デプロイ パイプラインを使用できますが、チームリーダーはすべての commit とデプロイを承認する必要があります。 |
| 高 | デプロイ パイプラインを使用しないでください。代わりに、管理者は特権アクセス管理システムとセッション記録を使用する必要があります。 |
リソースの可用性を維持する
デプロイ パイプラインを使用してリソースを管理すると、それらのリソースの可用性に影響し、新たなリスクが発生する可能性があります。
- システム停止の発生: デプロイ パイプラインが問題のあるコードや構成ファイルを push すると、以前は機能していたシステムで障害が発生したり、データを使用できなくなったりすることがあります。
- システム停止が長引く: システム停止を修正するには、デプロイ パイプラインを再実行する必要があります。デプロイ パイプラインで障害が発生している場合や他の理由で利用できない場合は、停止が長引く可能性があります。
サービス停止の原因となる、または長引く可能性があるパイプラインでは、サービス拒否攻撃が発生する可能性があります。不正な行為者がデプロイ パイプラインを使用して、意図的にシステム停止を引き起こす可能性があります。
緊急用のアクセス手順を作成する
デプロイ パイプラインがアプリケーションまたはリソースのデプロイまたは構成を行う唯一の方法である場合、パイプラインの可用性が重要になります。極端な場合、デプロイ パイプラインがビジネス クリティカルなアプリケーションを管理する唯一の方法であれば、デプロイ パイプラインをビジネス クリティカルにすることも検討する必要もあります。
デプロイ パイプラインは複数のシステムとツールから作成されていることが多いため、高レベルの可用性の維持が困難であるか、経済的ではない可能性があります。
緊急用のアクセス手順を作成することで、デプロイ パイプラインが可用性に与える影響を軽減できます。たとえば、デプロイ パイプラインが稼働していない場合に使用できる代替アクセスパスを作成します。
緊急用のアクセス手順を作成する場合、一般的に以下のほとんどのプロセスが必要となります。
- 関連する Google Cloud リソースに対する特権アクセス権を持つユーザー アカウントを 1 つ以上用意しておきます。
- 緊急用のアクセス ユーザー アカウントの認証情報を安全な場所に保存するか、特権アクセス管理システムを使用してアクセスを仲介します。
- 承認された従業員が認証情報にアクセスするための手順を確立します。
- 緊急用のアクセス ユーザー アカウントの使用を監査し、確認します。
入力アーティファクトが可用性の需要を確実に満たすようにする
通常、デプロイ パイプラインでは、デプロイを実行する前に、中央のソースコード リポジトリからソースコードをダウンロードする必要があります。ソースコード リポジトリを利用できない場合、デプロイ パイプラインの実行が失敗する可能性があります。
多くのデプロイ パイプラインは、サードパーティのアーティファクトにも依存しています。このようなアーティファクトには、npm、Maven Central、NuGet Gallery などのソースからのライブラリや、コンテナ ベース イメージ、.deb パッケージ、.rpm パッケージが含まれている可能性があります。いずれかのサードパーティ ソースが使用できない場合、デプロイ パイプラインの実行が失敗する可能性があります。
特定のレベルの可用性を維持するには、デプロイ パイプラインの入力アーティファクトのすべてが同等またはそれ以上の可用性要件を満たす必要があります。次のリストは、入力アーティファクトの可用性を確保するために役立ちます。
- 入力アーティファクトのソース（特にサードパーティ ソース）の数を制限する
- ソースシステムが利用できない場合にデプロイ パイプラインで使用できる入力アーティファクトのキャッシュを維持する
デプロイ パイプラインとそのインフラストラクチャを本番環境システムと同様に扱う
多くの場合、デプロイ パイプラインは、開発環境、ステージング環境、本番環境を有機的につなぎ合わせる役割を果たします。環境に応じて、複数のステージが実装されます。
- 最初のステージでは、デプロイ パイプラインが開発環境を更新します。
- 次のステージでは、デプロイ パイプラインがステージング環境を更新します。
- 最終ステージでは、デプロイ パイプラインが本番環境を更新します。
デプロイ パイプラインを複数の環境で使用する場合は、パイプラインが各環境の可用性の需要を満たしていることを確認してください。通常、本番環境は可用性の需要が最も高いため、デプロイ パイプラインとその基盤となるインフラストラクチャは本番環境システムのように扱う必要があります。つまり、デプロイ パイプラインを実行するインフラストラクチャには、本番環境システムと同じアクセス制御、セキュリティ、品質標準を適用します。
デプロイ パイプラインのスコープを制限する
デプロイ パイプラインがアクセスできるリソースが多いほど、セキュリティが侵害された場合により多くの被害が発生する可能性があります。複数のプロジェクトまたは組織全体にアクセスできるデプロイ パイプラインが侵害され、最悪の場合、Google Cloud 上のすべてのデータとアプリケーションに永続的な損害を与える可能性があります。
この最悪のシナリオを回避するには、デプロイ パイプラインのスコープを制限します。各デプロイ パイプラインのスコープを定義して、Google Cloud 上の比較的少数のリソースにのみアクセスできるようにします。
- プロジェクト レベルでアクセス権を付与するのではなく、デプロイ パイプラインに個々のリソースへのアクセス権のみを付与します。
- 複数の Google Cloud プロジェクト間でリソースへのアクセス権を付与しないようにします。
- 複数のプロジェクトや環境にアクセスする必要がある場合は、デプロイ パイプラインを複数のステージに分割します。その後、それらのステージを個別に保護します。
機密性を維持する
デプロイ パイプラインは、管理するデータの機密性を維持する必要があります。機密性保持に関する主なリスクの 1 つは、データの引き出しです。
不正な行為者がデプロイ パイプラインを使用して Google Cloud リソースからデータを引き出そうとする方法は複数あります。次のような方法があります。
- 直接的: 不正な行為者が、Google Cloud リソースからデータを抽出して別の場所にコピーするように、デプロイ パイプラインまたはその構成を変更する可能性があります。
- 間接的: 不正な行為者がデプロイ パイプラインを使用して侵害されたコードをデプロイし、Google Cloud 環境からデータを盗む可能性があります。
機密リソースへのアクセスを最小限に抑えることで、機密性のリスクを軽減できます。ただし、機密リソースへのすべてのアクセス権を削除することは、現実的でない場合があります。したがって、デプロイ パイプラインは、管理するリソースの機密性保持の需要を満たすように設計する必要があります。これらの需要を判断するには、次の方法を使用できます。
- デプロイ パイプラインがアクセスする必要があるデータ、アプリケーション、リソースを決定し、分類します。
- 機密性が最も高いカテゴリのリソースを見つけ、デプロイ パイプラインの初期カテゴリとして使用します。
アプリケーションとクラウド リソースの分類プロセスと同様に、この初期評価は常に適切であるとは限りません。たとえば、デプロイ パイプラインを使用して、最終的に機密性の高い情報を含むリソースを作成するとします。デプロイ パイプラインでは、それらのリソースを作成することはできるが読み取ることはできない場合、低い機密性カテゴリで十分である可能性があります。
機密性を維持するため、Bell–LaPadula モデルでは、デプロイ パイプラインで次のことを行わないように推奨されています。
- 機密性が高い入力アーティファクトを使用する
- 機密性の低いリソースにデータを書き込む
上の図は、Bell–LaPadula モデルに従って、データの機密性を確保するためにパイプライン内でデータがどのように流れるかを示しています。
デプロイ パイプラインが不要なデータを読み取らないようにする
デプロイ パイプラインは通常、データにアクセスする必要はありませんが、アクセスするパイプラインも存在します。アクセス権が過剰に付与される場合、次のような原因が考えられます。
- 不適切なアクセス権の付与。たとえば、デプロイ パイプラインには、プロジェクト レベルで Cloud Storage へのアクセスが許可されます。その結果、1 つのバケットで十分であるものの、デプロイ パイプラインでプロジェクト内のすべての Cloud Storage バケットにアクセスできます。
- 制限が過度に緩いロールを使用する。たとえば、デプロイ パイプラインに、Cloud Storage への完全アクセス権を持つロールが付与される場合です。新しいバケットを作成する権限があれば十分です。
パイプラインでアクセスできるデータが多いほど、誰かがデータを盗むリスクも高くなります。このリスクを最小限に抑えるため、不要なデータへのアクセスをデプロイ パイプラインに付与しないでください。多くのデプロイ パイプラインは、構成やソフトウェアのデプロイの管理のみを目的としているため、データにアクセスする必要はありません。
デプロイ パイプラインが不要なロケーションに書き込まないようにする
不正な行為者がデータを窃取するためには、環境へのアクセス権と、データを転送する手段が必要です。デプロイ パイプラインがデータを送信できるストレージとネットワークのロケーションが多いほど、不正な行為者がこれらのロケーションのいずれかを漏洩に使用する可能性が高くなります。
パイプラインがデータを送信できるネットワークとストレージのロケーションの数を制限すると、リスクを軽減できます。
- リソースに機密性の高いデータが含まれていない場合でも、パイプラインに不要なリソースへの書き込みアクセス権を与えないようにします。
- 許可リストに登録された一連のネットワーク ロケーションへのインターネット アクセスをブロックするか、接続を制限します。
送信アクセスを制限することは、機密性が中程度または高いとして分類された、機密データまたは暗号鍵マテリアルにアクセスできるパイプラインでは特に重要です。
VPC Service Controls を使用して、不正なデプロイがデータを盗み出すのを防ぐ
不正な行為者が、デプロイ パイプラインによってデータの引き出しを実行するのではなく、デプロイ パイプラインを使用して不正使用されたコードをデプロイしようとする可能性があります。不正使用されたコードによって Google Cloud 環境内からデータが盗まれる可能性があります。
VPC Service Controls を使用すると、このようなデータ盗難の脅威のリスクを軽減できます。VPC Service Controls を使用すると、特定の Google Cloud プロジェクト内からアクセスできるリソースと API のセットを制限できます。
完全性を維持する
Google Cloud 環境を保護するには、その完全性を保護する必要があります。以下が該当します。
- データや構成の不正な変更や削除を防止する
- 信頼できないコードまたは構成のデプロイを防止する
- すべての変更に明確な監査証跡が残るようにする
デプロイ パイプラインを使用すると、以下が可能になり、環境の完全性を維持できます。
- コードレビューなどの形で承認プロセスを実装する
- すべての構成やコードの変更に一貫したプロセスを適用する
- 各デプロイの前に自動テストまたはクイック チェックを実行する
効果を生むには、不正な行為者がこれらの対策を弱めたり、回避したりできないようにする必要があります。このようなアクティビティを防ぐには、以下について完全性を保護する必要があります。
- デプロイ パイプラインとその構成
- 基盤となるインフラストラクチャ
- デプロイ パイプラインによって使用されるすべての入力
デプロイ パイプラインに脆弱性が生まれるのを防ぐため、デプロイ パイプラインの完全性の基準が、そのパイプラインが管理するリソースの完全性のニーズを満たすか、またはそれよりも厳しくなるようにします。これらの需要を判断するには、次の方法を使用できます。
- デプロイ パイプラインがアクセスする必要があるデータ、アプリケーション、リソースを決定し、分類します。
- 完全性が最も高いカテゴリのリソースを見つけ、デプロイ パイプラインのカテゴリとして使用します。
デプロイ パイプラインの完全性を維持するため、Biba モデルは次のことを提案しています。
- デプロイ パイプラインは、完全性の低い入力アーティファクトを使用しないこと。
- デプロイ パイプラインは、完全性の高いリソースにデータを書き込まないこと。
上の図は、Biba のモデルに従って、データの完全性を確保するためにパイプライン内でデータがどのように流れるかを示しています。
入力アーティファクトの真正性を検証する
多くのデプロイ パイプラインは、サードパーティのソースからアーティファクトを使用します。このようなアーティファクトとしては、次のようなものがあります。
- Docker のベースイメージ
.rpmパッケージまたは.debパッケージ- Maven、
.npm、または NuGet ライブラリ
不正な行為者が、次の方法でサードパーティ アーティファクトの不正使用バージョンを使用するようにデプロイ パイプラインを変更しようとする可能性があります。
- アーティファクトを保存するリポジトリを侵害する
- 別のソース リポジトリを使用するようにデプロイ パイプラインの構成を変更する
- 類似した名前またはスペルミスを含む名前の不正なパッケージをアップロードする
多くのパッケージ管理システムではコード署名をサポートしており、これによりパッケージの真正性を検証できます。たとえば、PGP を使用して RPM パッケージや Maven パッケージに署名できます。Authenticode を使用して NuGet パッケージに署名できます。
コード署名を使用すると、次の方法でサードパーティ パッケージの不正使用のリスクを軽減できます。
- すべてのサードパーティ アーティファクトへの署名を必須とする
- 信頼できるパブリッシャーの証明書または公開鍵のキュレートされたリストを維持する
- デプロイ パイプラインで、信頼できるパブリッシャーのリストと照合してサードパーティ アーティファクトの署名を検証できるようにする
または、アーティファクトのハッシュを検証することもできます。この方法は、コード署名をサポートしておらず、変更の頻度が低いアーティファクトに使用できます。
基盤となるインフラストラクチャが完全性の需要を満たしていることを確認する
不正な行為者は、デプロイ パイプライン自体を侵害するのではなく、次のようなインフラストラクチャの侵害を試みる可能性があります。
- デプロイ パイプラインを実行する CI / CD ソフトウェア
- パイプラインで使用されるツール（Terraform、kubectl、Docker など）
- オペレーティング システムとそのすべてのコンポーネント
デプロイ パイプラインの基盤となるインフラストラクチャは複雑であることが多く、さまざまなベンダーやソースのコンポーネントが含まれている可能性があるため、このタイプのセキュリティ侵害を検出するのは困難な場合があります。
インフラストラクチャ侵害のリスクを軽減するには、次のような方法があります。
- インフラストラクチャとそのすべてのコンポーネントを、デプロイ パイプラインおよび管理する Google Cloud リソースと同じ完全性標準に維持する
- 信頼できる提供元のツールを使用し、信頼性を検証する
- インフラストラクチャを定期的にゼロから再構築する
- Shielded VM でデプロイ パイプラインを実行する
パイプラインに完全性コントロールを適用する
不正な行為者は脅威ですが、Google Cloud 環境の完全性を損なう可能性があるソフトウェアまたは構成の変更の原因はこれだけではありません。デベロッパーが無意識に、または入力ミスなどの誤りが原因でこうした変更を行ってしまうこともあります。
追加の完全性のコントロールを適用するために、デプロイ パイプラインを構成することで、リスクのある変更が誤って適用されるリスクを軽減できます。このようなコントロールには次のものがあります。
- コードと構成の静的分析を実行する
- すべての変更において、一連のルール（コードとしてのポリシー）を渡すことを必須にする
- 同時に実行できる変更の数を制限する
次のステップ
- デプロイ パイプラインでサービス アカウントを使用するためのベスト プラクティスについて学習する。
- サービス アカウントを保護するためのベスト プラクティスを確認する。
- 脅威の調査と対応について学習する。
- リファレンス アーキテクチャ、図、ベスト プラクティスについては、Cloud アーキテクチャ センターをご確認ください。