FORSMILE
EN
セキュリティ2026/09/07

Oracle HTTP Server/WebLogic Proxy Plug-in:使用コンポーネントとパッチ適用状況の確認表

OHS、Apache向けプラグイン、WebLogic本体を分けて棚卸し。Oracle Homeの適用履歴、実際の参照先、更新後の確認結果を担当者へ渡せる形に整理します。

ブログ一覧へ / Back to Blog

『WebLogicは更新済み』だけでは、前段のプラグインまで確認できません。 サービスの入口から順に、どのホストのどのコンポーネントが動いているかを記録しましょう。本稿は管理者が確認結果を引き継ぐためのチェックリストです。特定のパッチを一律に適用する手順ではありません。

2026年9月7日にOracleの公開資料を確認しました。OPatchの例はFusion Middleware 12.2.1.4の資料を対象とします。14cなど別リリースでは、そのリリースの手順と取得したパッチのREADMEを照合してください。実環境でのコマンド実行・パッチ適用は未検証です。

1. リクエストの通り道を棚卸しする

  • 入口のWebサーバ:Oracle HTTP Server(OHS)、Apache HTTP Server、IISのどれか。複数あればホストごとに記録する。
  • 中継コンポーネント:OHSに含まれるプラグインか、別途導入したWebLogic Server Proxy Plug-inか。Webサーバの設定で参照するファイルと導入記録を確認する。
  • 転送先:WebLogic Serverのホスト・ドメイン・担当者を記録する。前段の管理担当者と同一とは限らない。
  • 確認対象:本番だけでなく待機系、別ノード、旧環境も記録し、利用中・停止中・不明を分ける。停止中の環境は再稼働前の確認担当を決める。

Oracleの14.1.2の概要資料では、OHS向けはOHS配布に含まれ、Apache向けはZIPで提供されます。Apache向けの設定例にはLoadModuleとmod_wl_24.soが登場します。展開したフォルダがあるだけでなく、設定がどのファイルを参照しているかを確認します。IISにはApacheの設定名を当てはめず、導入した版の資料と構成記録を使ってください。

2. Oracle Homeごとに適用履歴を残す

OPatchで管理されるOracle Homeでは、対象HomeのOPatchからversionとlsinventoryを実行します。次の例はLinux/UNIXのシェル用です。ORACLE_HOMEが対象の絶対パスを指していることを先に確認してください。これらはパッチの適用コマンドではありませんが、ログファイルは作成されます。

sh
# Linux / UNIX: use the Oracle Home you intend to inspect
"$ORACLE_HOME/OPatch/opatch" version
"$ORACLE_HOME/OPatch/opatch" lsinventory

Windowsでは対象HomeのOPatchディレクトリにあるopatch.batを使用します。例はコマンドプロンプト用で、PowerShell構文ではありません。出力のOracle Homeが意図した場所かを確認してから結果を採用します。

bat
REM Windows Command Prompt: ORACLE_HOME must identify the target home
"%ORACLE_HOME%\OPatch\opatch.bat" version
"%ORACLE_HOME%\OPatch\opatch.bat" lsinventory
  • 出力にあるOracle Home、OPatchの版、実行日時、ログ保存先を記録した。
  • 対象製品、適用パッチID、適用日時を控え、パッチのREADMEと対応付けた。
  • 別のHomeや別ノードを同じ結果で済ませていない。
  • コマンドが失敗した場合は『未確認』と記録した。エラーを『パッチなし』や『対象製品なし』と読み替えていない。

ZIP展開した独立プラグインを、別のOracle Homeのlsinventoryだけで確認済みにしないでください。配布物の識別情報、導入・置換記録、設定の参照先をそろえます。証跡がなく版を特定できない場合は、推測で埋めず保守担当へ確認します。

3. 修正要件と照合し、更新後も確認する

製品名と基本バージョンだけで適用済みと判断せず、該当するOracleのアドバイザリとMy Oracle Supportのパッチ資料に、記録したパッチIDを対応付けます。後続パッチで修正を取り込んだと判断する場合も、対象版と包含関係の根拠を残します。My Oracle Supportの認証が必要な個別READMEやパッチIDは本稿では確認していません。

  • 作業前:対象Home・プラグイン・ノード、READMEの要件、停止範囲、バックアップと復旧手順を担当者間で確認する。
  • 作業後:適用ログと履歴を保存し、READMEが求める再起動・追加手順の完了を記録する。
  • 設定確認:更新したプラグインを設定が参照しているか、旧ファイルや別パスを参照していないか確認する。
  • サービス確認:担当者が決めた疎通、認証、主要画面、転送先への接続を確認し、時刻と結果を記録する。
  • 残課題:エラーや不審なログは別途調査する。ページが表示できたことだけで、修正完了や侵害なしを証明しない。

4. 社内担当者へ渡す確認表

以下は編集部が用意した記録テンプレートです。コンポーネント・ノードごとにコピーし、未確認欄には担当者と確認期限を入れてください。ログや構成には内部情報が含まれるため、社内の指定された保管先で共有します。

text
確認日時/確認者:
サービス名/環境(本番・待機・検証):
ホスト/ノード:
入口Webサーバと版:
プラグインの種類・版/配布物の識別情報:
Oracle Home またはプラグイン配置先:
設定が参照するプラグインのパス:
WebLogic転送先/担当部署:
参照アドバイザリ/パッチREADME:
OPatchの版/適用パッチID/適用日時:
後続パッチの包含関係の根拠(該当時):
作業前後のログ・履歴の保管先:
停止・再起動・追加手順の実施結果:
疎通/認証/主要画面の確認結果:
状態(確認済み・対応待ち・未確認・対象外):
判定の根拠:
残課題/担当者/期限:

『対象外』にも根拠が必要です。資料が不足している場合は『未確認』にします。運用担当が証跡を集め、セキュリティ担当が修正要件との対応を確認できる状態を、このチェックリストの完了条件にしてください。

🚨 「しまった!」と思ったら、今すぐこちらへ

被害に遭った直後・遭ったかもしれない時のための、状況別の緊急対応ガイドです。落ち着いて、上から順に対処すれば大丈夫です。

Related articles