APTパッケージ供給チェーン検証の本番組み込み｜署名確認・ミラー汚染検知と更新停止フロー

なぜ今、APT供給チェーンの検証を「本番フロー」に組み込むのか

2025年以降、Linuxディストリビューションのパッケージミラーを標的にした改ざん事案が複数報告されています。従来はセキュリティチームが四半期レビューで確認すれば十分とされてきた署名検証ですが、現在は月次CVEへの対応と組み合わせて、更新実行前に毎回チェックすることが現場標準になりつつあります。

APTは元々、InReleaseファイルのGPG署名を自動検証する仕組みを持っています。しかしその検証ロジックを「通過すれば問題なし」で終わらせると、鍵ローテーション漏れ・ミラー側の静的ファイル改ざん・社内プロキシキャッシュによる古いメタデータの混入といった問題を見逃します。本記事では、検証の仕組みを理解した上で、実際の更新パイプラインに組み込む手順を順番に整理します。

署名検証の仕組みと現行の鍵管理方式

APTがリポジトリを信頼する根拠は、/etc/apt/trusted.gpg.d/ に置かれたGPG公開鍵とInReleaseファイルの署名が一致することです。apt-get update を実行すると、APTはミラーからInRelease（またはRelease.gpg）を取得し、ローカルの鍵束で署名を検証します。この検証に失敗すると、後続の apt-get install や apt-get upgrade は実行されません。

運用上の注意点として、apt-key コマンドは Ubuntu 22.04 以降で非推奨となり、Ubuntu 24.04 では事実上削除されています。現在の標準は、.asc または .gpg 形式の公開鍵を /etc/apt/trusted.gpg.d/ に直接配置し、sources.list（または /etc/apt/sources.list.d/ 配下の .sources ファイル）で signed-by= オプションを使ってリポジトリごとに鍵を紐付ける方式です。

鍵の紐付けを明示しないと、trusted.gpg.d/ に存在するいずれかの鍵でも署名が通ればOKという緩い状態になります。サードパーティリポジトリを複数追加している環境では、この緩さが意図しない信頼の連鎖につながるため、signed-by= による明示的な紐付けを必ず行います。

鍵の有効期限を定期監視する

GPG公開鍵には有効期限が設定されているものがあります。期限切れに気づかず更新を続けると、APTが警告を出しながら続行するケースがあるため、月次メンテナンス時に以下で期限を確認します。

gpg --no-default-keyring \
    --keyring /usr/share/keyrings/対象リポジトリ.gpg \
    --list-keys --with-colons \
  | awk -F: '/^pub/{print $7, $10}'

出力されるUnixタイムスタンプを現在日時と比較して、90日以内に期限が来る鍵はベンダー側の更新情報を先行確認します。

ミラー汚染の検知：更新前チェックを自動化する

ミラーが汚染されたケースでは、InRelease自体の署名は正常であっても、パッケージファイルのハッシュ値がInRelease内の記録と一致しないことがあります。APTはパッケージ取得時にこのハッシュを照合しますが、プロキシキャッシュや古いCDNエッジが介在すると、署名は通るが中身が古い（または改ざんされた）状態が続く場合があります。

検知の起点は apt-get update の終了コードとエラー出力です。更新スクリプトやAnsibleタスク内では、終了コードが0以外の場合は即座に後続処理を中断し、アラートを発報するようにします。加えて、--error-on=any オプションを付けると、警告レベルの出力も非ゼロ終了として扱われるため、通常は無視されがちな検証の揺れを捉えられます。

apt-get update --error-on=any 2>&1 | tee /var/log/apt/update-preflight.log
if [ ${PIPESTATUS[0]} -ne 0 ]; then
  echo "[ALERT] apt update failed. Aborting upgrade." >&2
  exit 1
fi

既にインストール済みのパッケージファイルの整合性を後から確認したい場合は debsums が有効です。debsums -c はパッケージに含まれるMD5sumをローカルファイルと比較します。ただし debsums が参照するチェックサムデータベース自体が改ざんされていた場合は検知できないため、あくまでファーストチェックとして位置づけます。

社内ミラーを運用している場合の追加確認

aptly・apt-mirror・Nexus Repositoryなどで社内ミラーを運用している環境では、アップストリームからの同期後に署名の再検証を行うステップを挟みます。具体的には、同期完了後に gpgv でInReleaseを検証し、ハッシュリストに含まれるPackagesファイルのSHA256を sha256sum で突合するシェルスクリプトをCIパイプラインに組み込む方法が広く使われています。同期スクリプトとCI/CDを分離して管理している現場では、同期ジョブの完了Webhookを受けてCI側が検証ジョブを走らせる構成が一般的です。

本番更新フローへの組み込み：段階的なアーキテクチャ

月次CVE対応の更新作業を安全に進めるには、単一コマンドで全台一括アップグレードするのではなく、事前検証 → ステージング適用 → 本番ローリング適用 の3段階に分けることが現場での基本設計です。

事前検証フェーズでは、更新対象パッケージの一覧と依存関係を apt-get upgrade --simulate（または -s）で出力し、CVEの修正が含まれるパッケージ以外に予期しないアップグレードが混入していないかを確認します。apt-get upgrade -s の出力を前月分と差分比較することで、依存解決の変化を可視化できます。

ステージング適用後の検証には needrestart が役立ちます。カーネル・ライブラリを更新した後に再起動が必要なサービスを一覧表示し、再起動を自動化するかどうかを制御できます。本番適用前にステージング環境で needrestart -r a を走らせ、予期しないサービス再起動が発生しないかを確認します。

Ansibleで管理している環境であれば、ansible.builtin.apt モジュールの前に ansible.builtin.command で apt-get update --error-on=any を実行し、その戻り値を failed_when で評価するタスクを前段に置くだけで、署名検証の失敗を自動的にプレイブック停止条件にできます。

更新停止フローと切り戻し手順

署名検証の異常を検知した場合や、適用後に障害が発生した場合に備えて、更新を即座に停止・切り戻せる手順を事前に整備しておく必要があります。

特定パッケージのピン止めによる更新ブロック

インシデント発生時に特定パッケージの自動更新を止めるには、/etc/apt/preferences.d/ 配下にピン設定ファイルを作成します。

Package: 対象パッケージ名
Pin: version 現在のバージョン
Pin-Priority: 1001

優先度1001は「インストール済みバージョンを維持し、より新しいバージョンがあっても自動更新しない」という意味を持ちます。apt-cache policy 対象パッケージ名 でピン設定が反映されていることを確認します。

unattended-upgradesの一時停止

自動更新が有効な環境では、インシデント調査中に追加の変更が入らないよう、systemdのタイマーユニットを一時停止します。

systemctl stop unattended-upgrades
systemctl disable unattended-upgrades

調査完了後に再度有効化するまで自動更新が行われないため、停止したことを変更管理票やインシデントチケットに必ず記録します。再有効化を失念したまま放置されるケースが現場では散見されます。

dpkgレベルでの切り戻し

パッケージを旧バージョンに戻す場合は、APTのダウングレードか、/var/cache/apt/archives/ に残っている旧バージョンの .deb ファイルを直接 dpkg -i でインストールします。APTキャッシュに残っていない場合は、スナップショット（aptly・Nexusのリポジトリバージョン管理）から旧パッケージを取得します。この観点から、月次更新前にはキャッシュをクリアしない運用を推奨する現場もあります。

2026年現行環境での差分と注意点

Ubuntu 24.04 LTS（Noble Numbat）では apt-key コマンドが完全に削除されており、旧来の手順書をそのまま実行するとエラーになります。既存の /etc/apt/trusted.gpg に蓄積された鍵は個別の .gpg ファイルとして trusted.gpg.d/ に移行し、各リポジトリ設定に signed-by= を追記する作業が移行フェーズでは必要です。

Debian 12（Bookworm）以降では、.list 形式の sources.list に加えて DEB822 形式（.sources 拡張子）が推奨されています。DEB822形式は Signed-By: フィールドを一行で記述でき、読みやすさと管理のしやすさが向上しています。新規構築の環境ではDEB822形式を採用し、既存環境は計画的に移行することを検討する価値があります。

apt 2.x系（Debian 12 / Ubuntu 22.04以降で標準）では、InReleaseの有効期限チェックが厳格化されています。Valid-Until フィールドが過去日時になっているリポジトリは更新が拒否されるため、社内ミラーを同期スクリプトで管理している場合は、同期が数日遅延しただけでも更新が止まることを認識しておく必要があります。同期ジョブの死活監視と Valid-Until の余裕確認を運用チェックリストに加えます。

また、2025年後半から主要クラウドベンダーのマネージドリポジトリサービス（AWS、GCP、Azureが提供するaptミラー）では、署名鍵の自動ローテーション機能の展開が進んでいます。クラウド上のインスタンスでこれらのミラーを利用している場合、ベンダー側の鍵更新通知メーリングリストを購読し、鍵更新タイミングを事前に把握しておくことが停止リスクの低減につながります。

供給チェーン検証は「一度設定して終わり」ではなく、鍵管理・ミラー監視・フロー自動化の三つを継続的に見直す運用サイクルです。月次CVE対応のタイミングで検証ログを振り返り、警告が出ていないかを確認する習慣を組織的なプロセスとして定着させることが、実害に至る前に異常を捉える最も現実的なアプローチといえます。