自動セキュリティパッチ適用の本番段階導入｜unattended-upgradesの設定・ドライラン・失敗切り戻し

月次CVEレポートが公開されるたびに、運用担当者が手動でパッチ適用作業を組むのは現実的ではありません。特に複数台のサーバーを管理する環境では、セキュリティアップデートの適用漏れが重大なインシデントにつながるリスクが常に存在します。

本記事では、Debian系Linux（Ubuntu・Debian）における unattended-upgrades を使った自動セキュリティパッチ適用の本番段階での導入手順を、設定の意味・ドライラン・失敗時の切り戻しまで含めて解説します。

なぜ自動パッチ適用が必要なのか

CVE（Common Vulnerabilities and Exposures）は毎月多数が公開されており、緊急度の高いものは公開後数日以内に実証済みの攻撃コードが出回ることもあります。NVD（National Vulnerability Database）の統計ではCVSSスコア9.0以上の「Critical」脆弱性が年間数百件規模で報告されており、対応優先度の判断だけでも相当な工数がかかります。

こうした状況下で、セキュリティパッケージに限定した自動更新を仕組み化することは、リスクを最小化しながら運用コストを抑える有効な手段です。ただし「自動＝ノータッチ」ではなく、適切な事前検証とアラート体制が前提となります。

unattended-upgradesの基本設定

パッケージのインストール

Ubuntu 22.04 LTS以降では unattended-upgrades がデフォルトでインストール済みの場合がほとんどですが、明示的に確認・導入するには以下を実行します。

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

dpkg-reconfigure の対話ウィンドウで「自動更新を有効にしますか」に「はい」を選択すると、/etc/apt/apt.conf.d/20auto-upgrades が自動生成されます。

設定ファイルの要点（50unattended-upgrades）

主要な設定ファイルは /etc/apt/apt.conf.d/50unattended-upgrades です。デフォルトではコメントアウトされている設定が多いため、用途に応じて有効化します。

// セキュリティアップデートのみを対象にする（Ubuntu例）
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// 自動再起動（カーネル更新時など）
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// メール通知
Unattended-Upgrade::Mail "ops-team@example.com";
Unattended-Upgrade::MailReport "on-change";

// syslogへの記録
Unattended-Upgrade::SyslogEnable "true";

本番環境では Automatic-Reboot を安易に true にしないことが重要です。カーネルやglibcのアップデート後に再起動が必要になるケースがありますが、サービス影響を伴うためメンテナンス窓を設けた上で手動で判断するのが一般的な運用です。

20auto-upgrades 側では更新頻度を制御します。

APT::Periodic::Update-Package-Lists "1";   // 毎日リスト更新
APT::Periodic::Unattended-Upgrade "1";    // 毎日自動適用
APT::Periodic::AutocleanInterval "7";     // 7日ごとにキャッシュ削除

ドライランで本番前に動作を確認する

設定を変更したら、実際に適用する前にドライラン（dry-run）で挙動を確認します。これはパッチ適用を本番導入する前に必ず行うべきステップです。

sudo unattended-upgrade --dry-run --debug 2>&1 | tee /tmp/unattended-dry-run.log

--dry-run は実際のインストールをスキップし、--debug は詳細な処理ログを標準出力へ出します。確認すべきポイントは以下のとおりです。

• 「Packages that will be upgraded:」に意図しないパッケージが含まれていないか
• 「Packages that are blacklisted:」に除外指定が正しく反映されているか
• 「No packages found that can be upgraded unattended」が出る場合は Allowed-Origins の設定ミスを疑う

ドライランで問題がなければ、--dry-run を除いて実際に適用します。

sudo unattended-upgrade --debug 2>&1 | tee /tmp/unattended-apply.log

適用後の検証とログ確認

自動適用が実行されたかどうかは、ログファイルとsystemdのジャーナルで確認できます。

ログファイルの確認

# 適用ログ
cat /var/log/unattended-upgrades/unattended-upgrades.log

# エラーや警告のみ抽出
grep -E "ERROR|WARNING|Packages" /var/log/unattended-upgrades/unattended-upgrades.log

正常適用時は「Packages that were upgraded:」の後に適用済みパッケージ一覧が記録されます。「WARNING: An error occurred during the signature verification.」が出る場合はGPGキーの問題を疑ってください。

systemdタイマーの状態確認

2026年現在の主要ディストリビューションでは、cronではなくsystemdタイマーで apt-daily と apt-daily-upgrade が管理されています。

systemctl list-timers apt-daily*
systemctl status apt-daily-upgrade.service

タイマーの「NEXT」列に次回実行予定が表示されます。「LAST」列で直前の実行時刻を確認し、ログの記録時刻と突き合わせることで正常動作を検証できます。

失敗時の切り戻し手順

自動パッチ適用後にサービス異常が発生した場合、まず適用されたパッケージを特定し、必要なら前バージョンに戻します。

直近の変更を確認する

# 直近のapt操作履歴を確認
grep "upgraded" /var/log/dpkg.log | tail -50

# または apt history で確認
cat /var/log/apt/history.log | tail -100

パッケージのダウングレード

問題のあるパッケージを特定したら、APTのキャッシュを利用して前バージョンへ戻します。

# キャッシュに旧バージョンが残っているか確認
ls /var/cache/apt/archives/ | grep パッケージ名

# ダウングレード実行
sudo apt install パッケージ名=旧バージョン番号

# dpkgで直接インストールする場合
sudo dpkg -i /var/cache/apt/archives/パッケージ名_旧バージョン_amd64.deb

キャッシュに旧バージョンが残っていない場合は、snapshot.debian.org（Debian）やLaunchpad（Ubuntu）から特定バージョンを取得する方法があります。ただしこの操作はセキュリティ上のトレードオフを伴うため、根本原因の調査と並行して行い、できるだけ速やかに修正バージョンへ再適用することが推奨されます。

自動更新を一時停止する

調査中に自動更新が再度走らないよう、一時的に停止する方法も把握しておく必要があります。

# タイマーを一時停止
sudo systemctl stop apt-daily-upgrade.timer
sudo systemctl stop apt-daily.timer

# 復旧後に再開
sudo systemctl start apt-daily.timer
sudo systemctl start apt-daily-upgrade.timer

2026年の現行環境における注意点

2026年時点でのDebian系主要LTSリリースはUbuntu 24.04 LTS（Noble Numbat）とDebian 12（Bookworm）です。これらの環境では以下の差分に注意が必要です。

• Ubuntu 24.04 LTS：unattended-upgrades 2.9以降が標準搭載されており、Unattended-Upgrade::Origins-Pattern 形式の新しい設定記法が利用可能です。従来の Allowed-Origins も引き続き動作しますが、新規構築では Origins-Pattern への移行が推奨されています。
• Debian 12（Bookworm）：apt-daily-upgrade.service の RandomizedDelaySec がデフォルト60分に設定されており、複数台が同時刻にミラーへ集中しないよう分散する設計になっています。オンプレで多数のサーバーを運用する環境では意図的な挙動のため、変更は不要です。
• needrestartの挙動変化：Ubuntu 22.04以降では needrestart が自動インストールされるケースがあり、パッケージ適用後にサービス再起動を促す対話プロンプトが出ることがあります。非対話実行時は /etc/needrestart/needrestart.conf で $nrconf{restart} = 'a'; を設定することで回避できます。
• サードパーティリポジトリの混入：ProxySQLやMySQL Shellなどのサードパーティリポジトリは Allowed-Origins に追加していない限り自動更新対象外ですが、意図せず対象に含まれているケースが本番環境で報告されています。ドライランで対象パッケージを定期的に確認することが重要です。

自動パッチ適用は「省力化のツール」であると同時に「適用制御の仕組み」でもあります。対象範囲・通知・検証・切り戻しの四点を整備した上で本番稼働させることで、月次CVEへの対応速度とサービス安定性を両立できます。