CI/CDパイプラインにおけるセキュリティ対策

本章ではCI/CDパイプラインにおける共通した対策及び各フェーズ特有の対策について記載する。 [14] [15] [16] [17]

全フェーズに共通した保護

本項では、図１の流れに沿って、CI/CDパイプライン全体において重要となる対策について記載する。なお、政府情報システムにおけるCI/CDパイプラインも政府情報システムの一部であるため、対策については統一基準を遵守する。

資産管理

統一基準2.1.2 「資産管理」で述べられるとおり、自組織の資産の状況を把握し、台帳に記録することが重要である。CI/CDパイプライン自体やCI/CDパイプラインに利用するソースコード管理システムだけでなく、CI/CDパイプラインのプラグイン、ソースコード管理システムのリポジトリや各ファイル、各システムと連携しているサードパーティ製アプリ、オープンソースソフトウェア（以下、「OSS」という。）[^3]といったものも資産管理の対象にするよう留意する。

脆弱性管理を含む運用・保守

統一基準5.2.3「情報システムの運用・保守」にある各種対策は、CI/CDパイプラインにも適用される。CI/CDパイプラインそのものが動作するサーバやコンテナ等や、CI/CDパイプライン内のサードパーティ製アプリやOSSにおける脆弱性管理も適切に行う必要がある。また、CI/CDパイプラインがクラウドサービスである場合は、クラウドサービスの設定や構成に不備がないよう留意する。CI/CDパイプラインがサーバ装置等でホスティングされている場合は、統一基準6.2.1「サーバ装置」の対策を実施する。

環境への対策

サーバやコンテナホスト等でCI/CDパイプラインをホスティングする際は統一基準第６部「情報システムの構成要素」や第７部「情報システムのセキュリティ要件」、クラウドサービスとして利用する場合は、統一基準4.2「クラウドサービス」に従い、安全な環境を確立すべきである。管理対象のシステムに対して変更作業を実施するという特性上、CI/CDパイプラインでは特に次の事項については注意すべきである。

シークレットの保護

CI/CDパイプラインは、基本的にシステム・コンポーネント同士を連携することで、一連の業務を自動化する。なお、CI/CDパイプラインを構成する各種システムやストレージは、基本的にシステム同士が自動化された形で連携し、情報のやり取りが行われる。このシステム間の連携は大まかに次の３パターンがある。

直接連携パターン：ソースコード管理システムとビルド環境等、連携元システムと連携先システムの連携が同一のサービス運営内で完結する形態である。
Web API連携パターン: 連携したい先のシステムが持つAPIに対して、処理対象のデータを送信する形態である。
Webhookパターン: 連携元のシステムが、連携先のシスしむテムにおける処理実施するタイミングをイベントという形で通知する形態である。通知自体はWeb APIリクエストで行われるが、通知を受けた連携先システムが処理対象のデータを取得しにいくという点で、「API連携パターン」とは異なる。

直接連携パターンではサービス内で完結するが、それ以外のパターンでは、システム間同士が互いを認識する必要があり、その際には互いに発行したシークレットを用いて、主体認証する必要がある。シークレットの管理が適切でない場合、漏洩等による不正アクセスに繋がりかねないため、統一基準7.1.1「主体認証機能」などを参考にし、適切に利用・保存・更新・失効がされなければならない。

適切な管理をするために、CI/CDパイプラインで扱うシークレットは「シークレットマネージャー」と呼ばれるシステム・コンポーネントで管理することが一般的である。これは、シークレットの生成、暗号化、保存、更新、削除及び監査ログに加えて、他システムからの利用時のログ等の機能を提供する。

また、昨今ではそもそも長期にわたってシークレットを管理する必要のない仕組みがCI/CDパイプライン関連のサービスに整備されつつある。具体的にはOpenID Connectをサポートすることで、数分程度の有効期間しか持たないアクセストークンを、ビルドやデリバリといったアクションを実行する都度発行することが可能となった。これにより、シークレットの管理コストが減るだけでなく、漏洩や管理不備によって発生する影響範囲を低減できる。

なお、シークレットを異なるフェーズ間で再利用することは、最小権限の原則から避けるべきである。例えばデリバリフェーズで扱う主体をビルドフェーズで使い回した場合、ビルドフェーズ内から本来不要であるはずの本番環境の変更を実行できるようになる。

アカウント管理・アクセス制御

主体認証ののちに付与される権限については、最小権限の原則に従ってアクセス制御をすべきである。アクセス制御の考え方については、DS-210 ゼロトラストアーキテクチャ適用方針 [9]や統一基準7.1.2「アクセス制御機能」を参照できる。可能な場合はネットワーク制御を入れると多層防御的な観点から、よりリスクを抑えられる。

また、統一基準6.2.5(1)-1「情報システムの管理者とデータベースの管理者を別」のような関係性はCI/CDパイプラインにも言える。任意のコードを本番環境で実行されないよう、CI/CDパイプラインの管理者と、CI/CDパイプラインの利用者の権限を適切に分掌することが望ましい。

ログの取得・管理

統一基準7.1.4「ログの取得・管理」に従い、CI/CDパイプラインやその動作環境における動作履歴、変更履歴等に関するログを、情報セキュリティインシデントの予兆や痕跡を調査・分析するために取得するべきである。さらに、それらを適切な期間、保全するべきである。また、CI/CDパイプラインそのもののログに加え、変更対象となる環境のログや、CI/CDパイプラインと連携するサードパーティのシステムにおけるログも同様に管理対象とすべきである。

CI/CDパイプラインを通した信頼性の確保

最終的に本番環境で実行する成果物の完全性・真正性が担保されていなければならない。各フェーズにおいては、直前のフェーズの出力を検証し、その正当性を確認し、パイプライン全体の信頼を確立するべきである。このために、成果物を要保全情報として電子署名の付与及び検証を行い、全フェーズの完全性と真正性、それらの追跡性を確保する。

ローカル作業フェーズの保護

ここでは、CI/CDでよく利用されるSCMの一つであるGitのケースを例にとって説明する。作業者はソースコードを、自身の統合開発環境（IDE）で作成・編集する。作業者は編集作業の結果を、ファイルやディレクトリの状態及び履歴として、自身の作業端末上のリポジトリ (ローカルリポジトリ)という保管場所に記録する。これを「コミット」 [10]という。複数人で作業をする場合は、ローカルリポジトリにおける作業結果を関係者と同期するために、作業結果をソースコード管理システム上の「リモートリポジトリ」 [10]に送信する。このアクションを「push」と呼ぶ。変更内容が重なりソースコードの完全性が損なわれる可能性を減らすため、一般的に元のソースコードから別の「ブランチ」 [10]を作成する。これにより、元のブランチの内容に影響を与えることなく安全に変更を加え、そして変更が完了したら、メインの内容に統合することができる。

利用者やエンドポイントにおける対策

　ローカル作業フェーズで利用される端末や、その端末上で操作されるアカ　　ウントは、図中の各システムに対して、ブラウザやCLIなど経由でアクセスする。攻撃者は初期アクセスの対象として端末を標的にすることが多い。なぜなら、一般的な業務で利用する端末は、メールやコラボレーションツールで頻繁に内外の連絡先とコミュニケーションをするためである。正当な連絡先やアクセス先と認知させ、端末へのマルウェア感染を狙うフィッシング等の脅威は非常に多い。そういった脅威から端末を保護するには、セキュリティパッチ適用などの統一基準5.2.3「情報システムの運用・保守」に加え、統一基準7.2.1「ソフトウェアに関する脆弱性対策」、統一基準7.2.2「不正プログラム対策」、統一基準7.2.4「標的型攻撃対策」などを検討すべきである。

利用者のアカウント情報の窃取については、利用者への教育、フィッシング耐性のある二要素認証、アクセスごとの認証・認可、内部CSIRT等への報告方法の周知など、統一基準の既存のコントロールを検討すべきである。端末の保護についても同様に、パッチ適用等の統一基準により対応可能である。具体的には統一基準7.1.1 「主体認証機能」統一基準7.1.2「アクセス制御機能」統一基準7.1.3「権限の管理」等が対象になる。

ソースコード管理システム、そのリポジトリ及びブランチの保護

ソースコード管理システムは複数のリポジトリを管理し、リポジトリは特定の時点のソースコード、構成ファイル、CI/CDパイプラインや実行環境の設定ファイルを管理する。それらのファイルを更新するにあたり、変更差分の承認やテスト等の品質保証を必要とするため、リポジトリごとにアクセス制御を適用することは一般的な措置である。

さらに、リポジトリ内の各ブランチに対して、異なる権限を設定することができる。例えば、本番環境に関連する重要なブランチへの編集内容の取り込みには、複数の明示的な承認を必要とするなどリスクに応じた構成にできる。逆に、ブランチに不備がある場合、正当でないコミットが取り込まれ、重大な被害につながる恐れがある。例えば、CI/CDパイプラインの設定ファイルの実行トリガーを変更し、任意のタイミングでCI/CDパイプラインを実行し、デリバリまでさせることも可能である。こういったリスクから保護するために、次のような対策が考えられる。

アクセス権限の設定

ブランチへのアクセス権限を適切に設定することで、不正な主体による任意の編集結果の反映を防止する。

強制的な取り込みの禁止

バージョン管理システムによっては、特定ブランチへの強制的な取り込みを禁止する機能を有する。この機能を設定することで、不正な主体によるコミットの強制的な取り込みをより確実に防止できる。

CI/CDパイプライン定義ファイルの保護

定義ファイル自体への変更を更に別のリポジトリで管理し、通常より厳重な保護設定を適用し、サブモジュールとして参照することを検討する。

ソースコード管理システムの公私共用なユーザーアカウントの管理

近年のソースコード管理システム[^4]はSaaSサービスの形態をとることも多い。そういったサービスでは、個人がアカウントを作成することができる。また、同サービスは組織レベルでも利用が可能で、組織テナントに個人アカウントを招待し、組織のソースコードへのアクセス権限を付与することも珍しくない。

これら個人アカウントは、貸与された管理端末よりも脆弱な傾向がある私用端末からも利用できる。そのため、個人アカウントの認証情報やセッション情報が私用端末から窃取された場合、政府情報システムのCI/CDパイプラインの侵害やソースコード改ざんなどが可能となる。

基本的には、個人アカウントの利用を禁止し、組織の利用者アカウントと完全に分離することが最も効果的な対策であり、また、従来から実績のある手法である。しかし、バージョン管理システムや類似サービスの広く一般的な運用方法などの理由から、個人アカウントの招待を避けられない場面が想定される。その場合は、政府情報システムの利用者アカウントと個人アカウントをリンクすることで、政府情報システムとして管理したいソースコード及びリポジトリへのアクセス権限を利用者アカウントに限定することが可能である [11] [12]。ただし、アカウント同士の紐付けを実現する機能は有償であることが多いため、システム導入及びアカウント管理の運用設計をする時に、十分な検討をすべきである。

また、組織のリソースへのアクセスを貸与端末または業務環境からのみに限定する多層防御的な対策にすることも有効である。一般的な例[^5]としては、ソースコード管理システムやバージョン管理システムにネットワーク制限を設定する、リモートデスクトップ環境を用意するといったことが考えられる。また、より高度な対策としては、当該サービスへのログインに、ユーザーログインに加え、組織が発行した証明書を持つ端末のみ許可する端末認証を適用することも考えられる。

作業内容と作業者の紐付き

アカウントに不正アクセスされる可能性については既に述べた。攻撃者は不正にアクセスしたアカウント（または不正に作成したアカウント）を使用して、任意の変更を試みることができる。後続のビルドフェーズに不正なコードが混入することを防ぐためには、作業者に最小の権限しか与えないことや、リポジトリに対する変更を実行した作業者の身元を確認することが考えられる。具体的には、変更に対して作業者の署名を求めることである。作業者の署名を取得・検証することで、ソースコード管理システムは変更の真正性を確認することができる。

ソースコード管理システムに対するシークレットの記録予防

シークレットをリポジトリにコミットすると、ソースコードの変更履歴として記録される。この変更履歴は長期間にわたって参照可能になる。不正アクセスの原因となりかねないため、ローカル作業フェーズにおけるコントロールとして、シークレットの記載されたファイルはコミットの対象外とするか、都度、専用ストレージなどから取得することが一般的である。もし、コミットしてしまった場合、変更履歴を参照可能な主体全てがシークレットを利用可能となるため、早急にローテーションしなければならない。[^6]

また、3.2.3)で述べたようにソースコード管理システムの個人アカウントと、政府情報システム上の利用者アカウントをリンクさせることが可能である。この際に、個人アカウントで発行したシークレットで、政府情報システムの管理するソースコードやリポジトリを操作できないよう制限をかけておくことも重要である。

ビルドフェーズの保護

ビルドフェーズは、特定のコミットから再現可能な成果物を生成する。生成した成果物は、検査・検証を行い、所定のストレージに伝送・保管する。成果物には、自組織が管理するソースコードだけでなく、OSSを含めたサードパーティ製のモジュールも含まれる。

シークレット情報の漏洩対策

ビルドフェーズでは多くの外部リソースとの連携をするにあたり、複数のシークレットを処理する。また、実際のソースコードファイルやIaCファイルをビルドする上で、構成情報や非公開なシステム情報も処理する。いずれの情報も適切な範囲で参照可能な状態にすべきである。しかし、ビルドフェーズにおいて、デバッグなどの背景で出力したログに、パスワードなどの秘密情報が平文で記載される可能性がある。対策としては、出力自体の抑止やマスキングの実施が有効である。マスキングとは、重要な情報を置き換える技術であり、パスワードや秘密情報を識別できないようにすることで、漏洩を防止する。

また、変更がかけられたファイルへのテストとして、それらのシークレットが含まれていないことを検証し、検知した場合は変更を取り込まないよう「失敗」扱いにすることも有効である。その結果を通知することで、シークレットの速やかなローテーション作業を開始することができる。

ソースコード・成果物の信頼性の担保

図 4: ビルドフェーズのアーティファクトリポジトリ

ソースコードの変更差分を主たるブランチに取り込む際に、ソースコードの品質や信頼性が維持されるようルールを整備すべきである。例えば、変更内容の取り込みの条件として別の関係者によるレビューや、上位者による承認を必須にするといったことが変更管理として考えられる。また、CI/CDパイプラインの強みである自動化を活かし、当該フェーズ内で自動的に実行されるテストの結果を、取り込みの条件とすることも、近年のモダンアプリケーション関連の運営では一般的である。その際、成果物における脆弱性スキャンをするようなツール[^7]を用いることもできる。また、利用したいサードパーティ製のモジュールやライブラリを導入するに当たって、そのライセンスによってサービスの持続性や方向性に対する影響有無も検証すべきである。また、導入実績のない物、依存関係の複雑なもの、長期間にわたってのメンテナンスがないものは、脆弱性などがあった場合に持続的な対応が困難になるため、リスクを確認する。

ビルド上での実行範囲の制限

ビルドフェーズの処理内容は、CIの定義ファイルとして記述され、リポジトリで管理されることが一般的である。この中で、特にテスト等のように、取り込み前に動作するプロセスは注意が必要だ。なぜなら、それらに関係するファイルが変更された場合は、3.3.2「ソースコード・成果物の信頼性の担保」がされないまま動作するからである。

例えば、3.2.2「ソースコード管理システム、そのリポジトリ及びブランチの保護」を迂回された際に、テストやビルドに必要なツールやモジュールをダウンロードする定義ファイルに、マルウェア等の不正なファイルをダウンロードする処理が追加される可能性は排除できない。そういった脅威への対策としては、環境の外向き通信の限定が考えられる。また、定義ファイル内で都度ツールやモジュールをダウンードするのではなく、それらを事前検証・インストールしたCI環境やコンテナイメージを利用するなどし、セットアップ処理を、実際のテストや成果物の生成処理と分離することも有効である。

依存物の安全性の担保

成果物は、ソフトウェアのソースコードや、IaCなどで使用されるツールは、外部のツールに依存することが多い。提供形態としてはベンダーといった商用のものもあれば、OSSなどもあり、幅広い。

OSSは多くの個人の貢献により透明性が保たれるなどメリットがあるが、悪意のあるパッケージ誘導[^8]や、管理者権限を何らかの手段で入手した後に悪意のあるスクリプトを注入する、あるいはパッケージを置換するなどの脅威が近年見られる。

これらの脅威から保護するには、パッケージに対する脆弱性チェックやパッケージに対する検証をする仕組み[^9]を整備し、ソフトウェア資産として管理することが重要である。また、当然のことながら、脆弱性管理として依存物のアップデートやパッチ適用は定期的に行う必要がある。

または、信頼できるダウンロード元や開発元のみのパッケージを許可することも対策の１つである。その際に、それらに対する署名及び検証も必要となる。

ストレージ内の成果物の保護

ビルドフェーズにおいては、生成された成果物をストレージに保存する。ストレージにアクセス制限の不備やその他の脆弱性がある場合、攻撃者が不正な成果物を注入・改ざんするリスクが生じる。

このような脅威に対処するための保護策として、適切なアクセス制限の設定が考慮されるべきである。また、安全性及び実装性能を適切に満たすアルゴリズムを利用した暗号化などにより、安全性を確保しなければならない。また、クラウドサービスの利用においては成果物を意図せぬ形で公開しないよう管理すべきである。

さらに、デリバリフェーズや、別の政府情報システム等のサービスで不正なモジュールとして使われないようにするため、正しくない成果物が利用されないようにする必要がある。これは悪意ある成果物への入れ替えだけに限らず、意図せぬ形で成果物を上書きすることも想定している。そのために、成果物の真正性と完全性を保証する仕組みの導入が重要である。多層的な防御戦略の一環として、成果物にデジタル署名を施すことで、攻撃による影響を後続のプロセスで検知・防止することが可能となる。

これらのうちアクセス制御は統一基準7.1.1 「主体認証機能」7.1.2「アクセス制御機能」7.1.3「権限の管理」が参考になる。暗号化や電子署名については、統一基準7.1.5「暗号・電子署名」が参考になる。

デリバリフェーズの保護

デリバリフェーズは、成果物を動作環境に配送する。

図 5: デリバリフェーズの範囲

デリバリ時に利用する主体の保護

デリバリフェーズでは、実質的に本番環境を変更する。そのため、デリバリを実施する主体は、他のフェーズで利用される主体に比較し、より強固に保護されなければならない。例えば、統一基準7.1.1(1)-2「厳格な主体認証が必要な場合」などに該当することもある。また、デリバリ時の主体を、他フェーズで共有することは基本的に避けるべきである。

信頼できる成果物をデリバリするための保護

デリバリ前に成果物を取得する必要がある。この際の主な脅威として、ストレージ内の改ざんされた成果物のデリバリが考えられる。改ざんされた成果物が本番環境にリリースされれば、セキュリティ侵害やデータ漏洩につながる可能性がある。ビルドフェーズで侵害が発生するリスクがある以上、多層防御の観点に則り、デリバリ時の成果物の完全性や真正性を検証すべきである。具体的にはビルドフェーズに施されたデジタル署名を検証し、改ざんを検知できるようにすることである。また、成果物について、ビルド時のSCA、SAST、DASTの結果から特定の基準をクリアしているか確認することも有効である。また、意図したCI環境における成果物であることを保証するために、ビルドフェーズ時に署名を実施することが有効である。それにより、信頼された環境で構築された成果物か判定することができる。

デリバリ時の証跡

本番環境へのデリバリは、既存利用者やサービスに大きな影響があるため、その変更内容が適切であり、品質が確保されているかを保証し、証跡として保管することが重要である。そのため、本番環境へのデリバリには、レビューや承認を必須とすべきである。