コンテナイメージと配布物の署名はどこで行うか――パイプライン内の検証設計判断

コンテナイメージや配布物への署名は「やるかやらないか」ではなく、「パイプラインのどこで署名し、どこで検証するか」という位置の設計判断が核心です。署名タイミングと検証タイミングのズレがサプライチェーン攻撃の主要な侵入口になります。この2点の位置を確定してから、署名方式・鍵管理・ポリシー設定の判断を進めることが、実装層にとって最も効率的な構築経路になります。

署名が必要な成果物の種類と署名を省略できる条件の整理

署名対象になる成果物の分類基準

署名対象の主軸は「コンテナイメージ」「Helmチャート」「バイナリ配布物」「設定ファイルバンドル」の4種類です。判断軸は「外部に配布するか」「本番環境に直接デプロイされるか」「第三者リポジトリを経由するか」の3点で、1つでも該当すれば署名を設計に含めます。JUnitレポートやSARIFファイルのようなパイプライン内のみで参照される中間生成物は省略できますが、省略の判断を一度確定させておくことが重要です。後から署名を追加すると既存の鍵管理フローとの整合が取れなくなり、改修コストが積み上がります。

省略できる条件と省略してはいけないパターン

省略が許容されるのは「ステージングまでしか到達しない」「イメージが毎ビルド破棄され本番に持ち込まれない」「署名インフラ整備期間が開発フェーズに対して不釣り合いに長い」という3条件が揃った場合に限定されます。よくあるつまずきとして、開発環境では署名なしで運用しておき、本番リリース直前に急いで署名インフラを追加するパターンがあります。この場合、鍵の発行・配布・検証ポリシーを本番品質で整備する時間が確保できず、形式的な署名だけが存在して検証が機能しない状態になりやすいです。署名インフラは本番化の少なくとも2〜3か月前から設計を開始することが現実的な目安になります。

成果物ごとの署名粒度の設計判断

Helmチャートはチャート単位とバンドル単位のどちらで署名するかを決める必要があります。チャート単位では、バージョンごとに独立した署名が残るため過去バージョンとの比較が容易ですが、チャート数が50本を超えると管理対象が膨らみ、鍵のマッピングが複雑化します。バンドル単位に統一するとシンプルになる反面、特定チャートだけ差し替えた場合にバンドル全体の再署名が必要になります。粒度の変更は後から困難なため、初期設計の段階で確定させます。

Cosign・Notary・GPGの署名方式比較

3方式の設計上の違いを一覧する

方式	鍵管理	レジストリ統合	主な用途	設計上の注意点
Cosign	鍵レス（Sigstore/Fulcio）または自己管理鍵	OCI Artifact形式で標準対応	コンテナイメージ・Helmチャート	鍵レス時は外部透明性ログ（Rekor）に署名メタデータが記録される
Notary v2	階層型CA（NTS）	OCI仕様準拠	コンテナ・汎用OCI成果物	プライベートNTSの整備に初期コストがかかる
GPG	手動または鍵サーバー管理	直接対応なし（ラッパー要）	バイナリ・deb/rpmパッケージ	有効期限・失効通知の管理が煩雑で小規模チームには負担が大きい

方式選定の判断基準

Cosignの鍵レスフローはSigstore/Fulcioを利用するため鍵管理の負担が最小化され、新規導入では最も選ばれやすい方式です。ただし、Sigstoreの透明性ログ（Rekor）に署名メタデータが外部公開される点を懸念する場合は、自己署名鍵（キーフル）フローやNotaryのプライベートNTSへの切り替えを検討します。GPGはdeb/rpmパッケージ管理ツールとの統合が必要な場合に依然として有効な選択肢ですが、鍵の有効期限管理・失効通知の仕組みが煩雑で、チームメンバーが3名未満の小規模環境では運用コストが高くなりやすいです。

ハイブリッド構成を取る場合の注意点

コンテナにはCosign、バイナリにはGPGというハイブリッド構成は実際に多い組み合わせです。この場合、検証ロジックが2系統になるため、デプロイパイプラインの検証ステップに条件分岐が生まれます。分岐を1か所にまとめるラッパーを置くか、成果物の種別に応じてジョブを分離するかを事前に決めておかないと、新たな成果物が追加されたときに検証漏れのリスクが高まります。ハイブリッド構成を選ぶ際は、検証ルートの一元化方針も合わせて設計に含めます。

パイプラインのどのステージで検証を差し込むか

署名と検証の位置が分離する問題

署名はCI側（ビルドジョブ）、検証はCD側（デプロイジョブ）に置くのが基本構成です。CIとCDが独立したシステム（GitHub ActionsとArgoCDなど）の場合、署名情報の受け渡し経路が明示的に設計されていないと、CDが検証をスキップする設定になりやすいです。よくある失敗は「CIで署名したが、CDはレジストリからイメージをPullするだけで検証ジョブを追加していない」という構成で、この状態ではレジストリ上で差し替えられたイメージがそのままデプロイされるリスクが残ります。署名と検証は「対」として設計し、検証が存在しない署名はセキュリティ上意味をなさないと判断します。

各ステージへの検証配置の判断基準

主要な配置候補は「ビルド後」「レジストリPush後」「デプロイ前」の3点です。ビルド後は署名処理の正常完了を確認する目的で、主に「署名処理自体が成功したか」を検出します。レジストリPush後は「署名メタデータがレジストリに正しく付属しているか」の確認で、Pull時に署名が欠落していないかを検出します。デプロイ前は最終防衛線であり、「デプロイしようとしているイメージが信頼済みソースから来ているか」を確認する最重要ポイントです。環境数が5つ以上（dev/stg/preprod/prod/drなど）ある場合は、各環境のデプロイ前に独立した検証ジョブを配置することが求められます。

検証を入れる順番と優先度の判断

すべてのステージに同時に検証を入れることが難しい場合、優先度の判断基準は「本番に近い位置から」です。デプロイ前の検証を最初に実装し、次にレジストリPush後、最後にビルド後という順序が一般的な落とし所です。ビルド後の検証はサービス保護への直接的な効果が薄く、CI工数を消費するわりに価値が限定的なため、後回しにしても許容できます。優先度を決めたら、未実装のステージにも「将来追加する」という設計上の予約を明示しておくことで、段階的な整備が進めやすくなります。

公開鍵の配布と信頼チェーンの設計

公開鍵の配布経路の選択肢と判断基準

公開鍵の配布方法は大きく「レジストリ付属（OCI Artifact形式）」「外部鍵サーバー」「リポジトリ管理（Git）」の3パターンです。OCI Artifact形式はCosignが標準対応しており、イメージと署名を同一レジストリ内に保管できるためシンプルです。ただし、レジストリ自体が侵害された場合に署名も同時に書き換えられるリスクが生じます。外部鍵サーバーを使う場合は可用性の設計が必要で、鍵サーバーがダウンするとデプロイが全停止するため、冗長構成（最低2系統）と緊急時のキャッシュ利用ポリシーを事前に決めておきます。Gitリポジトリ管理は透明性が高く監査に向いていますが、鍵の更新が別PRを必要とするため、ローテーション時の手続きが増える点を考慮します。

信頼チェーンの設計パターン

信頼チェーンは「ルートCA → 中間CA → 署名鍵」の階層型と「直接の公開鍵リスト」のフラット型に大別されます。成果物数が20本未満で署名者が1チームの場合はフラット型で十分です。複数チームが独立して署名する場合や、ベンダー提供のコンテナが混在する場合は、階層型で各チーム・ベンダーに中間CAを割り当てる構成が管理しやすくなります。フラット型から階層型への移行は鍵の全面再発行を伴うため、スケールアップの見込みがある場合は初期から階層型を選択することも判断の選択肢に入ります。

デプロイ前の検証ゲート実装と失敗時の処理設計

検証ゲートの実装パターン

検証ゲートの実装方法は「Admissionコントローラー（OPAまたはKyverno）」「デプロイツール組み込みのVerifyステップ」「シェルスクリプトによる事前チェック」の3パターンがあります。Kubernetesを使っている場合はAdmissionコントローラーが最も確実で、クラスターへのAdmit前にポリシー違反を検出できます。ArgoCD 2.x以降はネイティブでCosign検証をサポートしているため、ArgoCDを使う構成ではデプロイツール組み込みが実装コストを最小化できます。シェルスクリプトによる事前チェックは導入コストが最も低い反面、スクリプトのバイパスが容易なため本番環境での信頼性は低く、暫定的な対応に留めます。

検証失敗時の処理設計チェックリスト

検証ゲートが失敗したときの処理として、最低限以下の5項目を事前に確定させます。緊急強制デプロイの例外フローを設計しておかないと、インシデント発生時に検証ゲート自体が障害対応の妨げになるという逆の問題が起きます。

• 署名なしイメージのデプロイ試行 → 即時停止（例外は下記の強制デプロイフローへ）
• 署名あり・有効期限切れ → 即時停止＋アラート通知（重大度: HIGH）
• 署名あり・鍵不一致（改ざんの疑い） → 即時停止＋インシデント自動起票（重大度: CRITICAL）
• 緊急強制デプロイの例外フロー → 2名以上の承認ログ記録＋有効期間24時間の一時解除フラグ設定
• ロールバック先イメージの検証通過確認 → ロールバックジョブにも独立した検証ステップを含める

フォールバックとロールバック設計の連携

検証ゲートで失敗したとき、デプロイが停止するだけでは不十分で、「現在稼働中のバージョンに留まるか、1世代前にロールバックするか」を自動的に判断する設計が必要です。ロールバック先のイメージ自体が検証済みかどうかも確認が必要で、検証ゲートが連鎖的に失敗するケースを想定した設計が求められます。緊急ロールバック用のイメージを専用タグで管理し、そのタグに対してのみ例外ポリシーを適用する方法が、現場での一般的な対応です。

レジストリ側のポリシー設定と鍵管理の責任分界

レジストリ側で設定すべきポリシー

レジストリ側で設定できる主なポリシーは「署名なしイメージのPushを拒否」「特定タグパターン（:latestタグなど）への署名必須化」「信頼できないソースからのイメージPullをブロック」の3つです。Harbor・ECR・Artifact Registryはいずれもポリシー設定に対応していますが、設定の粒度と方式が異なるため、レジストリを移行する際に設定が引き継げない場合があります。レジストリ選定の時点でポリシー設定の互換性を確認しておくことが、後の手戻りを防ぐ判断材料になります。

鍵管理の責任分界の設計

よくある責任境界の曖昧さとして、「署名鍵を生成したチームと、その鍵でパイプラインに署名させているチームが別」という状態があります。この場合、鍵の有効期限切れや漏洩時に誰が対応するかが不明確になります。責任分界として「鍵の発行・失効はセキュリティチーム」「パイプラインへの組み込みはインフラチーム」「使用状況の監査はコンプライアンス担当」という3者分離が確立されている組織では、インシデント対応時の判断速度と対応精度が明確に向上します。この分界はRACIマトリクスとして文書化しておくことで、担当者が入れ替わった際の引き継ぎコストを抑えられます。

マルチレジストリ構成での設計判断

本番・ステージング・DR用に複数のレジストリを持つ構成では、署名メタデータのレジストリ間コピーが必要になります。CosignはOCI仕様に準拠した署名をレジストリ間でコピーする機能を持っていますが、コピー先で検証ポリシーが正しく動作するかを別途確認する手順が必要です。レジストリが3つ以上になる場合は、署名メタデータのコピー漏れを検出する自動チェックジョブを設計に含めます。コピー漏れが発覚するのはデプロイ時が多く、本番デプロイが止まってから原因を調べるという事態を避けるためにも、事前の自動検出が重要です。

署名鍵のローテーションとリカバリ手順設計

ローテーションの時期と条件の設計

鍵のローテーション条件は「有効期限到来」「担当者の離籍」「漏洩の疑い」「署名方式の変更」の4つが代表的です。このうち最もリスクが高いのは漏洩時の緊急ローテーションで、対応速度と影響範囲の制御が同時に求められます。定期ローテーションは1年周期が一般的な目安ですが、CIパイプラインが毎日数十回の署名を行う環境では、鍵の使用回数に上限を設ける設計も有効です。ローテーション作業は本番デプロイの稼働中に重なると影響が大きいため、メンテナンスウィンドウと合わせて計画します。

リカバリ手順の設計（想定例）

想定例として、ローテーション中に旧鍵で署名済みの成果物が本番環境に残っている状態を考えます。旧鍵を即時失効させると旧鍵署名のイメージがデプロイ不能になるため、本番稼働中の全イメージを新鍵で再署名してから失効させる順序が必要です。移行期間（7〜14日が一般的な目安）を設けて旧鍵・新鍵の両方を一時的に信頼済みにする設定を維持する方法が、計画的なローテーションでは標準的な設計です。緊急ローテーションでは移行期間を設けられないため、全イメージの即時再署名フローを事前に自動化しておくことが求められます。

リカバリ失敗を防ぐドライラン設計

ローテーション作業のドライランをステージング環境で実施してから本番に適用するのは基本ですが、確認すべき項目を明示しておかないと手順が省略される傾向があります。最低限確認すべき事項は「新鍵でPushした署名がレジストリに正しく付属しているか」「CDパイプラインが新鍵の公開鍵を参照できているか」「旧鍵の失効後に既存の検証ジョブがエラーを出さないか」の3点です。ドライランを省略してローテーションを実施すると、本番デプロイが全停止するリスクが高まります。ドライランの実施記録はローテーション後の監査証跡としても機能するため、結果をドキュメントに残すことを設計に組み込みます。手を動かす詳細手順については、各ツールのセミナー・ハンズオンで補完してください。