RHEL 9のセキュリティ更新手順｜DNF・RHSA・再起動・停止影響
Red HatのRHSAとRPM修正版、DNF更新方法、RHELサブスクリプション・EUS、停止影響・復元条件を確認し、本番に段階適用するための運用ガイド。
この記事の目的
修正対象のRHSA/RPMと更新範囲を確定し、業務停止を管理して適用する。
最初に確認
RHEL 9の実版、repo/Satellite、EUS/release lock、RHSAと停止影響。
1. 更新前に知っておくこと
対象環境と停止リスクを先に確認し、作業可否を判断します。
- 公式修正
- RHSAとRPMのEVR、EUS/Satelliteとrepo同期を確認
- 更新範囲
- security全件/minimal/特定RHSAのどれかを事前決定
- 再起動
- kernel/重要プロセスとアプリの再起動計画を確認
対象・前提条件と企業システムの停止リスク
対象はRed Hat Enterprise Linux 9で、Red HatのDNF/RPM管理によるセキュリティ更新を行う環境です。RHEL 8、Rocky Linux、AlmaLinux、Oracle Linux、CentOS Stream、LeappによるRHELメジャーバージョンアップはこの手順をそのまま適用しません。サポート契約・配布元・EUS等のリリース固定条件も実環境で確認します。
| サービス構成 | 停止・変更リスク | 実施前の条件 |
|---|---|---|
| 単一サーバー/単一DB | kernelや重要デーモン更新でOS/サービス再起動が必要になることがある | 停止時間承認、リモート外のコンソール、VMとDBの復元試験 |
| LB配下の複数AP/Webサーバー | 対象1台を接続drain・更新・再起動・業務テスト後に段階復帰 | 代替系容量、セッション/ジョブ、ヘルスチェックと観測期間 |
| RHELを用いたDB/HPC/クラスタ | quorum・共有ストレージ・DBフェイルオーバーを誤ると業務・データ損失 | 各ミドルウェアのベンダー手順、アプリ・DB担当の承認 |
| RHSAの重大対応 | 更新を急ぐことと停止を防ぐことのバランスが必要 | リスク承認と代替緩和、復旧担当、RTO/RPO |
DNF自体に無停止保証はありません。クラスタであってもshared DB/ファイルシステムやアプリのセッション設計が単一障害点になることがあります。
RHSA・CVE・RPMのreleaseを使って修正版を判断
Red Hat Security Advisory（RHSA）は影響を受けるRHEL製品と修正パッケージを確認する一次資料。脆弱性の修正が上流版番号を変えないバックポートとして提供されることがあります。RPMのEpoch:Version-Release（EVR）とアドバイザリを照合し、上流バージョンだけで危険/安全を断定しないでください。
| 状態 | 判断と次の操作 |
|---|---|
| RHSAが存在し必要パッケージの候補がある | 導入済みEVRと修正版EVR、依存するrpmと他ベンダー製品を確認 |
| RHSAが見つからない/更新が出ない | Satellite同期、RHEL release固定、契約/配布元、モジュール/除外設定を確認 |
| 上流の修正バージョンより数字が古い | Red Hatが提供した修正releaseとRHSA、対象リポジトリで判定 |
| 重要デーモンやkernel/GRUBの更新 | プロセス・OS再起動、bootloader/UEFI/BIOS構成、クラスター復旧経路を事前評価 |
Red Hat公式のアドバイザリは、Red Hat Product Securityから確認します。
RHELの実版・サブスクリプション・更新元を確かめる
Red Hat Subscription ManagementやSatellite・社内ミラーを使用する場合、取得元とアドバイザリメタデータの同期条件が異なります。Simple Content Access構成ではsubscription-manager statusのDisabled表示だけで契約・配布不良と判定せず、実際にリポジトリと必要な更新・アドバイザリが参照できるか確認します。
マイナー版/EUS/モジュールを固定している場合
RHEL 9.xの指定リリースに固定されている場合、最新のパッケージに更新しないことが意図した運用かもしれません。EUSの契約・リポジトリ、アプリ認定、kernel/moduleとドライバの適合を管理者と照合。release固定を解除して先に進むことはしません。
変更票・トランザクション・バックアップのGo/No-Go
対象のRHSA、対象rpm一覧、依存関係、利用しているサービスと停止影響、リリース固定、管理サーバー/衛星サーバーの同期時点を変更票に記録します。VM/OSの復元だけでなくDB・業務データの整合性復元を試験してください。
| ゲート | 承認に必要な証拠 |
|---|---|
| 更新対象の一貫性 | RHELの実版、repo/Satellite、固定release、RHSAとrpm版が整合 |
| 変更の予測 | トランザクションに意図しない削除・依存変化・kernel/bootloader変更がない |
| 無停止の可能性 | 代替系容量、フェイルオーバー、セッション終了、DB整合性を試験済み |
| 復旧条件 | バックアップ復元試験、コンソール、bootloader/旧kernelの起動可否、RPO/RTOの承認 |
| 監視・担当者 | 基準となるSLO、HTTP 5xx、p95遅延、DBエラー、観測期間、中止・再開承認者が確定 |
--assumenoは更新パッケージを適用しませんが、メタデータ取得やキャッシュ更新があり得ます。また承認を自動で拒否するため終了コードが非ゼロとなる場合があり、更新失敗と同一視しません。全件securityの予行結果をminimalや特定RHSAの実行判断に流用せず、それぞれ同じ対象/フラグで予行してください。大量削除や依存解決失敗、誤ったリポジトリが見えたら本実行は中止してください。
dnf-automaticと管理サーバーによる自動更新の区別
dnf-automaticが設定されている場合、管理者の定めたタイマーと/etc/dnf/automatic.confに従って更新が実行されることがあります。手動の更新窓と競合しないようにし、設定を読んだだけで自動実行を開始・停止しないでください。
自動更新タイマーの有効化・無効化、Satelliteによる配布タイミング変更は独立した変更管理の対象。複数の管理基盤が同時更新しないことを確認します。
2. 確認コマンドと結果の読み方
代表例を見てから、必要なコマンドの詳しい判定へ進みます。
以下は結果の読み方を示す想定例であり、実環境の測定結果ではありません。
| 確認 | 目安 | 要確認・異常時 |
|---|---|---|
subscription-manager status | SCAのDisabledは想定内の場合あり | 実repoとRHSA配信も確認 |
dnf updateinfo list --security | 対象RHSAの候補表示 | 空欄でも適用済みと即断しない |
dnf needs-restarting | 古いライブラリを使うプロセス等 | 空でもkernel/業務正常は別に確認 |
コマンドごとの正常・例外・異常判定
以下はRHEL 9で想定される出力と運用判断例。実機での測定値ではありません。「正常」は変更対象と一致、「要確認」は想定内だが追加照合が必要、「異常」は作業停止、「判定不能」は権限不足・コマンド未導入・repo未同期などで成功とも失敗とも扱わない状態です。
--assumenoは実rpm更新を行わない予行ですが、メタデータ・キャッシュに影響する場合があります。トランザクションの自動拒否に伴う非ゼロ終了を更新失敗と同一視しません。権限・配布元・対象RHSA/EVR・実行前後のログを変更記録に残してください。全コマンドの想定出力と結果別の判断を見る
実機の環境や版によって出力は変わります。必要な箇所を開き、対象ホストと終了コードも照合してください。
| コマンド | 想定出力・意味 | 合否と次に行う操作 |
|---|---|---|
cat /etc/redhat-release | Red Hat Enterprise Linux release 9.x | 9系で管理対象のマイナー/サポート状態と一致なら正常。8系・別ディストリ・想定外なら停止 |
cat /etc/os-release | ID=rhel、VERSION_ID=9.x等 | 識別値/管理対象と一致。異なるOSは手順を混用しない。ファイル読取失敗なら判定保留 |
uname -r | 現在実行中のKernel版 | 更新前値を保存。Kernel更新後の新旧を照合し、旧版なら計画rebootを検討 |
df -h / /boot | 利用率・空き容量 | カーネル/ログを含めて十分な空きがあること。/boot満杯や不足ならNo-Go |
systemctl --failed | 0 loaded units listed. またはfailed unit | 0ならunit障害なし（業務正常は別）。新規failedなら原因調査。systemd非稼働は判定不能 |
dnf repolist --enabled | 有効repo名、BaseOS/AppStream/EUS/Satellite等 | 実際の契約/固定マイナーと一致なら正常。必要repo欠落・意図外repoは配布/契約を確認 |
subscription-manager status | Overall Status: Disabledなど（SCA時）、Subscribed等 | Disabledだけでは異常にしない。SCA/組織構成と実repo到達性・RHSA配信を確認。コマンド未導入は管理方式を調査 |
subscription-manager release --show | 指定releaseかRelease not setなど | EUS/リリース固定と作業票が一致。固定が意図外の場合は更新保留。勝手に解除しない |
systemctl list-timers 'dnf-automatic*' | timer名・NEXT/LAST、導入なしなら空 | 定常更新との競合がないこと。空でもSatellite等の別自動更新を否定できない |
dnf updateinfo list --security | RHSAとrpm対象一覧、対象なしなら空 | 対象RHSAが候補か、すでに適用済みかをEVRと照合。空だけで修正済みとは断定しない |
dnf updateinfo summary | セキュリティ通知件数・severity別の要約 | 対象通知を特定。0件時はrepo/Satellite同期・リリース固定・実導入版を確認 |
dnf updateinfo info RHSA-ID | 対象RHSAの対象製品/修正RPM詳細、無効IDなら情報なし | 実在するRHSAを使用。合致しない/情報なしはID・同期・repoを調査 |
rpm -q PACKAGE | 実インストールRPMのName-Version-Release | RHSA対象の正確なEVRと照合。未導入/名前違いなら該当性を確認 |
dnf info PACKAGE | Installed/Availableの版やrepo情報 | 修正版が期待repoから入手可能。repo別の候補/除外/モジュールを確認 |
sudo dnf upgrade --security --assumeno | Transaction Summary、候補rpm、新規/削除/更新一覧（適用なし） | 対象/依存・kernelが承認と一致。N自動応答で非ゼロ終了でも適用失敗とは限らない。異常/変更は中止 |
sudo dnf upgrade-minimal --security --assumeno | minimal方式に固有のtransaction候補 | minimalで本実行する場合はこの予行が必須。security全件のプレビューを使い回さない |
sudo dnf upgrade --advisory=RHSA-ID --assumeno | 当該RHSAと依存のみの候補一覧 | ID/EVR/依存/配布元が承認済みと一致。別RHSAや候補違いなら作業中止 |
sudo dnf upgrade --security | 更新済rpmを反映する取引・完了ログ（状態変更） | 予行のtransactionと一致し正常終了が前提。終了後も修正EVR・プロセス・業務確認必須 |
sudo dnf upgrade-minimal --security | 最小更新方針の取引・完了ログ（状態変更） | 同一minimal予行・承認があること。依存と実版が変われば再承認 |
sudo dnf upgrade --advisory=RHSA-ID | 選定したRHSA単位の取引（状態変更） | 実在IDと同一予行、承認内容が一致。実施後のRPMと業務テストまで確認 |
rpm -q kernel-core | 導入されているkernel RPM群 | uname -rと照合。新kernel導入のみでは稼働kernelは更新されない |
sudo dnf history info last | 最後のDNF transactionの実施日時・対象rpm・return code | 作業時刻/ユーザー/対象が一致。別の自動更新取引なら検証対象を特定し直す |
rpm -q dnf-automatic | dnf-automaticの導入版、未導入ならエラー | 未導入は必ずしも障害でない。タイマー0でもSatellite/別管理方式を調査 |
systemctl status dnf-automatic-install.timer | active/inactive/not-foundと次回予定 | 運用方針に一致。activeなら手動更新と競合しない窓を確保 |
sudo grep ... /etc/dnf/automatic.conf | upgrade_type=security/defaultなど | security限定要件ならsecurityが設定済みか確認。ファイルなしは未導入/他管理方式を確認 |
sudo dnf needs-restarting | 古いライブラリ等を使用するPIDとコマンド、空欄もある | 列挙されたプロセスを1件ずつ調査し製品別の再起動方法を選択。空でもkernel/業務合格とは別 |
journalctl -p err -b --no-pager -n 50 | 当該起動内のerrorイベント、空もある | 変更前後の差分で重大な新規ログを判定。journal空でも外形試験は別 |
sudo dnf history | DNFのtransaction ID/日時一覧 | 対象変更のIDを特定。自動更新と重複していないか照合 |
sudo grep -E '^upgrade_type\s*=' /etc/dnf/automatic.conf | upgrade_type=security/default等、設定なしのこともある | 自動更新範囲と承認が一致。見つからないときはd n f automatic導入有無と設定場所を確認 |
systemctl status dnf-automatic-install.timer --no-pager | Timerのactive/inactive/unknown | 有効でも停止すべきとは限らない。更新窓との競合を調査 |
subscription-manager identity | 登録ID/名前/組織などの登録情報（機密情報を含む） | SCAでstatusがDisabled等なら、登録実体を確認。表示内容を公開しない |
想定出力例：SCAと更新前transaction
本番Go：対象RHSAの修正EVR、適切なrepo/契約、重要プロセスの再起動・OSブート、実サービス通信と監視の基準値が全て満たされ、観測時間中に新しい重大アラートがない。いずれか未確認の場合は次ホストへの更新を禁止する。
想定出力と作業記録の取り方
リリースが9.xでもEUSや固定版の条件が違う可能性があります。監査票にはRHSA、repo、前後rpm EVR、実行カーネル、停止時間、DB整合性、監視しきい値と復帰承認者を記録してください。
3. 安全な進め方・完了確認と復旧
環境ごとの作業計画を前提に、変更・監視・中止・復旧の順で確認します。
次へ進める条件：対象RHSAの予行と適用をそろえ、OS・サービス・業務を確認。
DNFでセキュリティ更新・最小更新・特定RHSAを使い分ける
全セキュリティerrataに対して最新の対象パッケージを適用
この操作はセキュリティerrata対象の最新の利用可能なパッケージへの更新であり、依存関係によって更新範囲が広がり得ます。RHEL 9のdnf upgrade（--securityなし）はバグ修正・機能改善を含めた通常更新です。
セキュリティ修正に必要な最小限のバージョン変更
修正に必要なバージョンを目指す選択肢。サポート契約、依存関係や複数アドバイザリの整合が必要で、必ず小さな停止影響になるとは限りません。
特定RHSAだけを対象にする場合
実際のRHSA・関連rpm・依存・対象パッケージをDNFと提供元のアドバイザリで確認してから実行してください。「1つのRHSAだけだから停止が発生しない」とは限りません。
更新前後のDNFトランザクション記録
トランザクション実行後にRHELのカーネル/GRUB、サービス・アプリの再起動要否を別に評価。OSの再起動は停止/冗長切替の計画とセットで承認してください。
ステージングのトランザクションと本番実行を一致させる
本番更新は承認された更新方式ごとに、同じリポジトリ・release lock・RHSA・オプションの--assumenoによる取引を記録します。RHSA/パッケージ候補が予行から変化した、別のrpm/カーネル変更が現れた、依存の削除・新規導入が追加された場合はNo-Goに戻して再承認。Satelliteの同期やEUS切替によって候補が変わる場合も同様です。
SCA環境でのsubscription-managerの結果
Simple Content Access（SCA）でsubscription-manager statusがDisabledと表示されても、直ちに異常ではありません。dnf repolist --enabledで必要なリポジトリを確認し、dnf updateinfoと対象RHSAの配信・実際のRPM EVRを突き合わせる。ネットワークや認証の不具合、アドバイザリ同期遅延を「更新不要」と解釈しないでください。
HA・LB構成では一台ずつ更新し段階復帰
企業向けの運用順序
- ステージングで対象RHSA/rpmの更新とアプリ依存、設定差分、kernel/サービス再起動を先に試験。
- LB/クラスタから対象1台への新規リクエストを停止、既存接続・長時間ジョブをdrainして残存系の処理能力を確認。
- 承認したDNFトランザクションで更新し、必要なサービス・OS再起動を製品/クラスタ別手順に従って実施。
- 復帰前にRHELの実版、重要unit、業務の実通信・DB・ログを確認し、異常なら隔離したまま更新を停止。
- LBへ少量のトラフィックで段階復帰し、SLOと外形監視に合格したら次ホストを更新。
単一ノード・状態保持基盤は停止を前提に判断
LB退避やクラスタフェイルオーバーがない場合、無停止は保証できません。DBのquorum/レプリケーション/データ整合は製品別の正式Runbookを使用。復旧可能なデータの保持と許容停止が承認されるまでGoにしないでください。
適用後：RHSA・プロセス・OS・業務を確認
| 検証対象 | 成功条件 | 失敗時の判断 |
|---|---|---|
| RHSA/パッケージ | 対象rpmの導入EVRがRHSAの修正済みパッケージと一致 | repo/リリース固定/除外/依存に戻る |
| Kernel・サービス | 必要な再起動後に実行カーネルと重要unitが正常、古いライブラリ保持のプロセスを評価 | 再起動窓・bootloader・関連サービスを再検証 |
| 外形監視・DB | アプリのHTTP/認証/DB read-writeとバッチが基準内 | LBへ復帰せず隔離、次ホストの更新禁止 |
dnf needs-restartingはプロセスを列挙し、systemdサービスと一対一ではありません。needs-restartingの提供/実行可否はdnf needs-restarting --helpが利用できるかを確認し、必要に応じて関連パッケージを調査し、何を再起動する必要があるかをアプリの担当者と判断。カーネル更新時は再起動後の実行カーネルを確認します。
作業判定票：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、復旧承認者 | 変更を止め、既知の復旧手順を使用。ロールバック不能なら担当者へエスカレーション |
復旧・切り戻し・中止条件
| 状況 | 次の調査・復旧判断 |
|---|---|
| DNFが依存エラー/異常終了 | トランザクションとDNFログ、repo/Satellite同期とディスク容量を保全。無条件の再実行は避ける |
| 再起動後にSSH不可・OS起動失敗 | 管理コンソールでbootloader/GRUB、kernel、認証/SELinuxのログ・設定を調査 |
| RHSA後にアプリ異常・5xx増加 | そのホストをLBから隔離し、旧設定・依存rpm、サービスの状態と業務ログを比較 |
| DB/共有ストレージ不整合 | rpmを戻すだけでは復旧しない。クラスター/DB管理者が整合性と復元点を決定 |
| 復元試験未実施・旧版互換性不明 | 本番更新を止め、バックアップの有効性・RPO/RTOを再承認 |
dnf history undo/rollback等はすべてのパッケージを安全に戻せる保証ではありません。特にkernel/DBと既にデータ変更した製品は、依存と整合性を確認すること。必要ならVMやDBの検証済み復元手順を選びます。
公式根拠と関連運用ガイド
- Red Hat公式：RHEL 9セキュリティ更新・アドバイザリ指定
- Red Hat公式：DNF更新範囲
- Red Hat公式：DNF Automatic
- Red Hat Product Security
- Red Hat公式：GRUB更新後の再インストール条件
Ubuntu 22.04/24.04の更新（別記事）／Kubernetes更新／journalctl調査／ディスク容量
公式参照日：2026年11月1日。作業当日のバージョンと契約/EUS条件・配布元の修正情報を再照合してください。
更新前の確認チェックを開く （任意・作業メモ作成）
更新前リスクをチェックして、作業メモを作る
構成・停止条件・復旧準備とRHSAとDNF更新範囲を確認。未確認事項と次に読む説明を整理し、チェック結果をテキスト保存できます。実機診断や更新の実行許可ではありません。
ブラウザ内で判定し、入力内容をこの機能から外部送信・自動保存しません。機密情報は入力しないでください。