Ubuntu Serverのセキュリティ更新手順｜apt・USN・再起動・停止影響
Ubuntu Serverのセキュリティ更新を、公式USNとAPTの修正版、変更範囲、サービス停止影響、復旧条件から判断し、段階的に実施するための運用手順。
この記事の目的
Ubuntuの修正を確認し、対象パッケージとサービス停止影響を確定したうえで安全に反映する。
最初に確認
22.04/24.04、USN、APT配布元、Ubuntu Pro、自動更新、冗長構成。
1. 更新前に知っておくこと
対象環境と停止リスクを先に確認し、作業可否を判断します。
- 更新範囲
- 通常更新かUSN対象のみかを先に決める
- 再起動影響
- needrestart・unattended-upgradesの動作と更新窓を確認
- 復旧
- Ubuntu Pro、データ復元、保守窓と冗長構成を確認
対象環境・更新範囲・無停止の前提
対象はUbuntu Server 22.04 LTS / 24.04 LTSでAPT管理されるパッケージのセキュリティ更新です。Ubuntu 26.04等、別リリースやUbuntu Pro/ESMの保守条件は使用時点の公式資料で照合してください。OSリリースアップグレード（do-release-upgrade）は対象外。 Docker Engine/DB/アプリ独自の配布物も別更新計画にします。
| 構成 | 更新時の停止影響 | 進める条件 |
|---|---|---|
| 単一VM・単一DB | カーネルやサービス更新に再起動が必要になることがあり、無停止は保証できない | 業務停止窓、バックアップ復元試験、管理コンソール、承認 |
| 冗長Web/AP＋LB | 対象を新規振分から退避し既存接続をdrain、一台ずつ更新と復帰 | 他系統の容量・セッション・ジョブ継続、監視と復帰ゲート |
| DB/認証/キュー等の状態保持基盤 | フロントが冗長でも共有DB停止やデータ整合性による業務断があり得る | 製品別quorum・フェイルオーバーと整合性検証 |
| 緊急のCVE対応 | 脆弱性の放置リスクと停止・更新事故リスクの両方がある | 緊急承認、暫定緩和策、復旧担当とRTO/RPO |
停止をゼロにする一般的なAPTコマンドは存在しません。依存サービスの冗長化、LB切替、外形監視とデータ保全が前提です。
USN・CVE・バックポートから更新要否を判断
USN（Ubuntu Security Notice）はUbuntuの修正パッケージと対象リリースを確認する一次資料。上流ソフトの版が古くてもUbuntuの修正がバックポート済みのことがあります。ソフトウェアのupstream版だけでは脆弱性判定しないでください。
| 観測 | 次に取る具体的な行動 |
|---|---|
| 該当USNにUbuntu 22.04/24.04用修正版あり | USNのパッケージ名・完全なバージョン文字列と導入版・候補版を照合 |
| 候補版が見つからない | APTソース、pinning/hold、Ubuntu Pro、インターネット/proxy、サポート期間を調査 |
| 上流のCVE修正版より古い版が導入済み | Ubuntu側のパッケージrevisionsとUSNのFixed versionで判断 |
| 更新にカーネル・openssl・SSH・glibc等を含む | プロセス・OS再起動・証明書/認証・アプリ互換性・停止影響を担当者と確認 |
USN確認先：Ubuntu公式セキュリティ通知。作業時点の最新修正情報を再取得します。
更新前のOS・パッケージ・保守状態の棚卸し
Ubuntu 24.04ではdeb822形式のubuntu.sourcesを使用する構成が一般的。22.04など従来形式のsources.listと混同しないでください。apt-dailyやunattended-upgrades実行中に手動更新を開始しないこと。APTのロックファイルを無理に削除しないでください。
セキュリティ修正が提供される範囲を判定
Main/Restricted/Universe/MultiverseとUbuntu Pro（ESM Infra/Apps）で、サポート・修正提供範囲が違います。更新候補がない場合も「完全に安全」とは限りません。パッケージの提供元、適用したUbuntu Proサービス、CVE/USNの該当状況を照合します。
変更票・復元試験・Go/No-Goを確定
更新対象・変更時刻・利用者通知・実施者と承認者・中止判断者・切替と戻し方を作業票に記載します。OSスナップショットだけではDBデータの整合性を保証しません。 アプリ固有のバックアップと隔離環境での復元を検証し、復元点（RPO）と所要時間（RTO）を決めます。
| 事前ゲート | 合格条件 |
|---|---|
| 影響範囲 | 更新先のAPTパッケージと依存、カーネル/サービス再起動、設定ファイル差分が確定 |
| 復元 | OS/VMとアプリDBのバックアップ・復元試験、コンソール/旧kernel起動手段を確認 |
| 無停止の実現可能性 | 冗長構成なら代替系の負荷余力、readiness/connection-drain、DBの状態共有が検証済み |
| 監視と停止基準 | HTTP 5xx率、p95応答、ログイン/DB/バッチ成功率の平常値・許容値・観測時間を定義 |
| 更新範囲 | 通常更新を含むかsecurity-onlyかを明示承認。未決定なら本番変更禁止 |
Ubuntuの自動更新や社内配布基盤が既に更新を管理している場合は、競合させずその管理方式で変更します。
unattended-upgradesの設定・競合・自動再起動リスク
Ubuntu Serverではunattended-upgradesにより自動でセキュリティ更新が動く場合があります。APTの更新ポリシーを変更すると、作業窓外にサービス再起動や自動rebootが起こる可能性があります。手動更新前に現在の設定と実行状況を点検してください。
/etc/apt/apt.conf.d/50unattended-upgradesを直接書き換えるのではなく、組織の運用方針で承認した後に優先順位の高いdrop-inファイルで管理します。Allowed-Originsにはセキュリティ以外を含む設定も可能なため、現在値の確認が先。自動再起動の有無とタイミングを見ずに重要サーバーへ適用しません。
2. 確認コマンドと結果の読み方
代表例を見てから、必要なコマンドの詳しい判定へ進みます。
以下は結果の読み方を示す想定例であり、実環境の測定結果ではありません。
| 確認 | 目安 | 要確認・異常時 |
|---|---|---|
apt-cache policy | 候補版・導入版・配布元を確認 | 候補がなければrepo・hold・Proを調査 |
systemctl --failed | 新しいfailed unitがないか比較 | 0件だけで業務成功ではない |
/run/reboot-required | 存在すれば再起動計画へ | 存在しなくてもサービス再起動の確認が必要 |
確認コマンド別の期待結果と判断
下表はUbuntu 22.04/24.04 LTS用の想定結果であり実測ログではありません。「正常」は対象サーバーと変更計画に合う状態。「要確認」は期待内の例外（更新0件・再起動要求なし等）。「異常」は更新を止めて調査する状態。「判定不能」は未導入・権限不足・取得不能であり、成功にも失敗にも数えません。
apt-get updateは索引変更、apt-get upgrade/installはパッケージ変更。--dry-runは適用を避けますがログ等への影響はあり得ます。各コマンドの対象ホスト・実行者・実行時刻・終了コード・出力を記録します。ひとつでも重要項目が異常/判定不能なら次段階へ進まない。全コマンドの想定出力と結果別の判断を見る
実機の環境や版によって出力は変わります。必要な箇所を開き、対象ホストと終了コードも照合してください。
| 確認コマンド | 想定される出力 | 正常・要確認・異常と次の行動 |
|---|---|---|
cat /etc/os-release | ID=ubuntu、VERSION_ID=22.04/24.04など | 対象版と一致なら正常。別OS/別版は本記事を停止。取得不能なら環境・権限を確認 |
uname -r | 現在実行中のカーネル版 | 変更前記録と一致を保存。更新後も旧版ならreboot要否を調査。空/異常は判定保留 |
df -h / /boot | 使用率・空き容量の一覧 | 更新予定のパッケージ・initramfsに十分な空きがあること。100%や想定外の不足なら更新中止。/bootが別FSでない場合は表示に注意 |
systemctl --failed | 0 loaded units listed. または失敗unit名 | 失敗0はsystemd上の異常検知なし。既存失敗は事前記録。新規失敗は中止しjournalctlへ。systemdでない環境は適用対象外 |
command -v pro && pro status | proのパス・契約/ESM状態、未導入なら非ゼロ終了 | 未導入は必ずしも障害ではない。必要なESM対象ならGo保留。契約状態とUSN提供範囲を照合 |
apt-cache policy | 有効なAPT由来・pin priority・候補 | 対象repoが有効で想定リリースに一致。候補がない、他リリースが混入なら中止 |
apt-mark showhold | 保持中パッケージ名、対象なしなら空 | 対象の修正パッケージがholdされていないこと。holdがある場合は理由・除外リスクを確認し勝手に解除しない |
systemctl list-timers 'apt-daily*' | 次回・前回実行時刻、タイマー名（設定がなければ0件） | 手動更新と重ならないこと。タイマー0件でも他の自動更新経路を否定できない |
grep -RhsE ... /etc/apt/sources.list* | deb形式・deb822のURIs/Suites/Components | Ubuntuの対象コードネーム/security pocketが一致。空・許可外mirror・誤リリースならHold。秘密情報を公開しない |
sudo apt-get update | 索引取得のHit/Get、警告や失敗の表示（状態変更：索引） | 期待repoがすべて取得でき、GPG署名・TLS・proxy等の警告なし。取得失敗/署名エラーなら中止。終了0だけでは部分的警告を見落とさない |
apt list --upgradable | 候補パッケージ名とversion、空の場合もある | 対象USNの修正版を含むか導入済み版と突合。空でも『修正済み』と即断せずrepo/USNを確認 |
sudo apt-get -s upgrade --with-new-pkgs | Inst/Conf行、保持対象・追加依存、新規/更新の計画（実導入なし） | 想定外の追加・保留・設定影響がなく承認版と一致してGo。依存不整合や対象漏れならHold。予行後に候補変更なら再実施 |
dpkg-query -W PACKAGE | パッケージ名とインストール済みの完全版。未導入で非ゼロ | USNのFixed version以上で配布元が一致するか確認。未導入は『CVE対象なし』の断定不可。パッケージ名やsource/binaryを再確認 |
apt-cache policy PACKAGE | Installed、Candidate、version tableとorigin | Candidateが修正対象版、Installedが旧版なら更新対象。未提供/他originならrepo/Pro/holdを調査 |
sudo apt-get upgrade --with-new-pkgs | 承認した更新計画の取引内容、設定ファイル質問等（状態変更） | 直前予行の版/追加依存と一致する場合だけ確認入力。途中で削除や設定変更が出たら止める。完了後にdpkg版・サービスを検証 |
sudo apt-get -s install PACKAGE=VERSION | 特定パッケージ＋依存の追加/更新予測 | USNのFixed versionとAPT候補、依存全件が一致すれば承認対象。適合しない場合は範囲を再設計 |
dpkg-query -W needrestart | 導入済み版、未導入なら非ゼロ | 24.04で導入済みなら自動再起動設定と例外を調査。未導入でもAPT hook/別再起動機構を確認 |
grep -R ... needrestart/conf.d | restart/override_rcの設定断片、無ければ空・ファイルなし | 明示的設定と既定動作を合わせて判断。空を『自動restartなし』と扱わない。critical serviceへの影響不明ならNo-Go |
sudo unattended-upgrade -v --dry-run | 取得予定のパッケージ/Originやdry-run出力（ログ等に影響し得る） | 対象security originと一致し、予期しない再起動ポリシーがないこと。コマンド未導入・取得不能・不一致は定常更新設定を調査 |
test -f /run/reboot-required | 存在ならexit 0、存在しなければexit 1（通常の未存在） | exit 1はコマンド失敗/異常ではない。存在なら計画reboot、なくても古いライブラリ・サービス再起動不要の証明ではない |
journalctl -p err -b --no-pager -n 50 | 今ブートのerrorログ。空でもあり得る | 更新前との差分と重要サービスを評価。重大な新規エラーならLBへ戻さず調査。空だけで業務合格にしない |
grep -R 'Allowed-Origins\|Origins-Pattern\|Automatic-Reboot' ... | unattended-upgradesの許可配布元と自動再起動設定 | securityのみか通常更新も含むか、再起動窓が承認済みか確認。未設定は既定値も調査 |
sudo ls -l /var/log/unattended-upgrades/ | 自動更新ログの一覧、ファイルがなければ空やエラー | 時刻と自動更新の重複を照合。未導入やログローテートをすぐ異常と決めない |
sudo grep -R ... /etc/needrestart/... | 自動restart/除外unitの設定（ファイルなしもある） | 24.04の既定と合わせて判断。設定が表示されないことは無効の証明にならない |
systemctl list-timers 'apt-daily*' | APTタイマーのNEXT/LAST/UNIT | 手動適用と重複しないこと。対象が空でも別の更新基盤を確認 |
grep -RhsE '^(deb |URIs:|Suites:|Components:)' /etc/apt/sources.list* | APTリポジトリのURI/Suite/Componentの行（旧形式・deb822、取得不可なら空） | 自OSのsecurity pocketとコードネームを確認。空欄は形式・権限・sourceパスを調査し配布元不明のまま更新しない |
dpkg-query -W openssh-server 2>/dev/null || true | openssh-serverの実導入版。未導入なら空でexit 0となり得る | || trueによってコマンド失敗が隠れるため『空＝安全』としない。SSHが重要ならdpkg-queryを単独で再確認 |
apt-cache policy openssh-server | Installed/CandidateとAPTの取得元 | SSH更新の有無と候補を確認。USNの修正版・再起動影響・保守経路を照合 |
sudo grep -R -E '$nrconf{restart}|override_rc' /etc/needrestart/... | needrestartのrestart modeと除外unitの設定行、設定がなければ空 | 設定未表示は自動再起動無効の証拠ではない。Ubuntu 24.04の既定・パッケージ版を確認してから実行 |
想定出力例：APT更新の予行
更新後の最終Go：修正済みパッケージ版・必要なサービス/OSの再起動・監視と業務テスト（認証、DB read/write、API、バッチ）の3層が合格し、承認した観測時間内に重大アラートがない。ひとつでも満たさなければ対象ホストを隔離し復旧判断へ。
想定コマンド出力の読み方と作業記録
再起動要求ファイルがあっても、対象USNの修正適用は別途パッケージ版で確認します。「正常な例」と「実際の本番変更結果」は混同せず、変更票には日時、対象機、導入版、監視値、復帰承認者を保存してください。
3. 安全な進め方・完了確認と復旧
環境ごとの作業計画を前提に、変更・監視・中止・復旧の順で確認します。
次へ進める条件：APTの予行と本実行を一致させ、修正版・サービス・業務の3層を確認。
更新前シミュレーションと承認後の実施
APT索引更新・差分の事前確認
apt-get -s upgrade --with-new-pkgsはパッケージの変更を適用しません。--with-new-pkgsは更新に必要な新規依存パッケージの導入を許し、削除は許しません。出力に削除、意図しない関連パッケージの変更、保留、設定変更、不要な新規依存がないか確認。保守窓の途中で想定外が出たら中止します。シミュレーションと実作業の間に候補が変化する場合も、再承認が必要です。事前に確認した更新方式・オプション・APTソース・候補版が本実行と一致していることを最終確認します。
通常更新も含めて承認した場合（セキュリティ限定ではない）
apt-get upgrade --with-new-pkgsはセキュリティ更新だけを選ぶコマンドではありません。旧記事にあったapt-get -s upgradeとapt upgradeの組合せは、新規依存パッケージの扱いが異なるため、同条件の予行・実行にならない点を修正しています。「CVE修正だけ」という変更票なら上記を実行しません。
セキュリティ修正に限定する場合
USNのパッケージとFixed version、APTの候補・依存を照合し、対象パッケージの版指定更新または組織が管理するunattended-upgradesのsecurity originを使います。APTの依存解決でセキュリティ以外の変更が発生することもあるため、選定版でシミュレーションを行います。
固定のUSN番号やパッケージ版は作業日時・OSリリースごとに異なるため、記事内で「最新版」を決め打ちしません。
サービスが突然再起動しないか確認（Ubuntu 24.04 LTS）
Ubuntu 24.04 LTSでは、needrestartがライブラリ更新後に影響を受けるサービスを自動再起動する設定が標準です。 APTの実行が終わるまでOSを再起動しないとしても、sshdや業務daemonなどのサービス停止・接続断が起こり得ます。22.04も構成・パッケージによって振る舞いが異なるため実機設定を確認。自動更新の実行窓も監査してください。
判定：needrestartが導入済み・restart='a'相当なら自動再起動のリスクとして対象サービスを事前調査。設定が表示されない場合でも、既定値や配布元の設定を確認するまで「自動再起動なし」と判定しません。critical serviceの除外は/etc/needrestart/conf.d/で責任者が設計し、必要なサービス再起動を別の保守窓で実施する。セキュリティ修正を導入しただけで、旧ライブラリを使用するサービスが保護されたとは限りません。
公式根拠：Ubuntu Server: automatic updates / needrestart。
冗長系・単一系ごとの本番切替手順
LBと冗長アプリがある場合の段階更新
- ステージングで候補版と正常動作を検証。更新前の外形監視・SLO値を保存。
- 対象1台をLBの新規振分から退避し、既存HTTP/WebSocket・バッチ・セッションが終了/移行したか確認。残存系の容量を確認。
- 更新対象を承認済み範囲で適用。カーネルや重要サービス再起動が必要なら製品別の正常停止を実施し、再起動。
- LBへ戻す前にOS/SSH・認証/業務API/DBの実測テストを実施。異常なら当該ホストを隔離したまま中止。
- 少量のトラフィックで復帰し、5xx/遅延/DBエラー/ジョブを定めた観測時間測定。合格すれば次の1台へ。
単一構成の場合
LB退避は利用できません。停止窓と利用者通知、SSH以外のコンソール、OS/アプリデータ復元手順が揃わない場合はGoにしません。サービスを無停止と表示しないでください。
LBやDBの切替コマンドは製品固有。誤接続を避けるため、承認済み構成に紐づく社内Runbookを利用してください。
更新後：修正版・再起動・業務の三段階で完了確認
| 確認対象 | 合格条件 | 不合格時の行動 |
|---|---|---|
| USNと導入版 | 該当Ubuntuリリース向け修正版の完全なパッケージ版が適用済み | sources/Pro/hold/依存を再調査 |
| kernel・重要プロセス | 必要な再起動を承認済み窓で完了し、実行カーネルとunitが正常 | OS起動・サービス再起動原因を確認 |
| 業務・冗長系 | 実業務HTTP、ログイン、DB読み書き、ジョブ・監視が基準内 | LBへ復帰せず隔離し次ホスト更新停止 |
更新済みなのに旧ライブラリを読み込んだままのプロセスや、サービスの自動再起動を伴うパッケージがあり得ます。再起動要否はパッケージ通知・稼働プロセス・運用手順で個別判断し、/run/reboot-requiredだけで完了判定しません。
作業判定票：Go / Hold / Abort / Recovery を明確化
以下の欄を更新前に実環境の数値・対象・責任者で記入し、未確定のまま本番更新しません。閾値を記事の架空数値で共通化しないでください。
| 工程 | 必要な証跡・判断者 | 許可・保留・中止条件 |
|---|---|---|
| Preflight / Go | 対象host/node、現行/目標版、パッケージ差分、公式修正情報、復旧試験、切替担当と承認者 | すべて照合済みならGo。未実施/権限不足/候補違いはHold |
| Canary / Hold | 対象をLB/スケジューラで隔離、OS・アプリログ、重要ユニット・業務APIの基準値 | 事前SLOしきい値超過、データ異常、想定外の再起動ならAbort |
| 段階復帰 / Go | アプリ認証、HTTP成功率・5xx、p95、DB read/write、Job、監視、観測時間の記録 | 合格後に対象を復帰し観測完了した場合のみ次ホストへ。回復せず原因不明ならHold |
| 復旧 / Recovery | 原因ログ、バックアップと復元点、データ互換性、RTO/RPO、復旧承認者 | 変更を止め、既知の復旧手順を使用。ロールバック不能なら担当者へエスカレーション |
障害別の切り分けと戻し方
| 症状 | 次の調査・復旧判断 |
|---|---|
| APTのロック・依存・設定差分 | apt/dpkgのログ、実行中の自動更新ジョブを確認。ロックを削除せず公式修復手順を選択 |
| SSH接続断・OS未起動 | 管理コンソール/救済モードでsshd・PAM・firewall・bootloader・kernelを調査 |
| LB復帰後の5xx増加・遅延 | 対象ホストへの新規受付を停止し、平常時SLOとアプリ/DBログを比較 |
| DB/アプリデータ不整合 | 旧パッケージを戻しても解決するとは限らない。データ復元点を責任者と合意 |
| 修正未適用・復旧不能 | 更新停止と一時緩和策を記録し、セキュリティ担当・基盤・アプリ担当へエスカレーション |
復旧のための旧カーネル起動やVMスナップショット復元は、旧版の互換性とRPO/RTOを検証した場合のみ選択。業務データがバックアップ時点へ戻る場合があるため、承認なしに復元しません。
公式根拠・関連ガイド
RHEL 9のセキュリティ更新（別記事）／Docker Engine更新／ディスク容量／journalctl調査
公式参照日：2026年11月1日。リリース・パッケージによって更新手順が変わるため、本番適用時点で再照合してください。
更新前の確認チェックを開く （任意・作業メモ作成）
更新前リスクをチェックして、作業メモを作る
構成・停止条件・復旧準備とUSNと自動サービス再起動を確認。未確認事項と次に読む説明を整理し、チェック結果をテキスト保存できます。実機診断や更新の実行許可ではありません。
ブラウザ内で判定し、入力内容をこの機能から外部送信・自動保存しません。機密情報は入力しないでください。