PHP更新を、
確かな手順で。

01まず、対応を計画する

対象・手順・担当を、
揃えてから進めます。

PHPの更新は、管理画面の切替だけを指すものではありません。利用環境と修正状況を確かめ、必要な準備、適用、動作確認をひとつの作業として計画します。

同じ系統内の修正版の適用と、大きなバージョン移行では、確認範囲が変わります。現在の構成に合う手順を、提供元や保守担当者と整理してください。

02更新前の準備

バックアップと、
元へ戻す方法を確認。

ファイル、データベース、必要な設定などを、管理者が決めた範囲で保存します。WordPressでは、ファイルとデータベースの両方が重要です。

保存と復元の確認項目

• 必要なデータが、いつの時点で保存されたか
• 保存先へアクセスでき、必要な一式が揃っているか
• 誰が、どの手順で復元できるか
• テーマ・プラグイン・独自機能が、更新後のPHPに対応するか
• 可能なら検証環境で、主要な機能が動くか

検証環境を作る場合は、公開範囲やデータの取り扱い、メール・決済が本番へ流れないことも確認します。

参考：WordPress公式のバックアップ案内 ↗

03修正版の適用

提供元の手順で、
実行環境へ反映します。

サーバー会社が管理

契約サービスの案内に従い、提供元が行う修正と、利用者側で必要な切替を確認します。

自社で管理

権限のある管理者が、提供元のパッケージやイメージなどを更新し、必要な再起動・再読込を行います。

ファイルやパッケージを入れ替えたことと、Webサイトが修正版で処理されていることを分けて確かめます。複数台・複数の実行環境がある場合は、対象ごとに確認してください。

04更新後の確認

表示と処理を、
分けて確認します。

PHPの修正が反映されたことを確かめたうえで、実際の業務に必要な機能を確認します。TOPが表示できるだけで、すべての機能が正常とは判断しません。

実送信、決済、データ変更を伴うテストは、対象・権限・費用・通知先を整理し、テスト環境と承認された手順で行います。

05すぐに更新できないとき

暫定対応を、
修正までの計画につなぐ。

PHP公式は、設定変更による緩和策は特定の経路への露出を減らすもので、完全な解決にはならないとしています。暫定策だけで対応完了とはしません。

CERT-EUは、直ちに修正できない場合、修正を適用して確認するまで、インターネットに公開する環境の隔離を検討するよう案内しています。管理者と業務への影響を整理し、必要な対応を判断してください。

• 誰が、いつまでに修正するかを決める
• アクセスを制限する範囲と、残る経路を確認する
• 利用者の代替案内や受付方法を用意する
• 暫定設定がある場合は、適用箇所・副作用・解除条件を管理する

設定値の一部を抜き出して、本番へ一律に適用することは避けてください。環境を理解した担当者が、公式アドバイザリと提供元の手順を確認します。

06被害が疑われる場合

通常の更新作業と、
事故への初動対応を分ける。

不審なファイル、身に覚えのない画面変更や転送などがあるときは、PHP更新だけで完了とは判断できません。現在の管理者・保守担当者・社内責任者へ速やかに連絡してください。

1. 01

   状況と連絡先を整理する

   発見時刻、対象URL、見えた事象、連絡した相手を記録します。

2. 02

   被害の拡大を防ぐ

   公開範囲や接続の制限などを、管理者と状況に応じて判断します。

3. 03

   調査に必要な情報を保全する

   不用意な削除・初期化などで記録を失わないようにし、ログや変更内容の保全を進めます。

4. 04

   調査・復旧・再発防止を進める

   影響を確認し、必要な専門担当者と、復旧の条件や関係者への対応を整理します。

一般的な初動対応の考え方です。具体的な操作や復旧・報告の判断は、対象環境と状況に応じて担当者が行います。当窓口の通常返信を待たず、現在の管理者へも連絡してください。

参考：IPA「セキュリティインシデント対応の手引き」

07対応後の運用

今回の更新を、
継続できる保守へ。

今回の修正が反映されても、サイト全体の安全性を保証するものではありません。今後の更新、バックアップ、権限、監視などを継続して管理します。