WordPressの安全性を見直す方法。PHP・プラグイン・復旧手順を点検する
公開日 ・更新日
PHPの重大な脆弱性が公表されると、「WordPressだから危険なのか」と不安になります。結論は、WordPressを一括で危険と決めつけるのではなく、PHP、WordPress本体、プラグイン、テーマ、ホスティング、復旧手順を分けて点検することです。どこを誰が更新し、問題が起きたら何分で切り戻せるかまで決めると、ニュースに振り回されにくくなります。
WordPress公式の推奨環境は、PHP 8.3以上、MariaDB 10.11以上またはMySQL 8.0以上、HTTPS対応です。古いPHPやデータベースでも動作する場合はありますが、公式のサポートが終わった環境は脆弱性の影響を受けるおそれがあります。現在のバージョンが推奨環境から外れていないかを、まず確認します。
本体と拡張機能の更新責任を分ける
WordPress本体の更新だけでは、プラグインやテーマのリスクは消えません。使っていないプラグインを削除し、残すものは提供元、最終更新日、対応するPHPバージョン、代替手段を記録します。テーマのfunctions.phpや独自プラグインに重要な処理が入っている場合は、更新前に変更履歴とテスト環境を用意します。
管理画面と設定ファイルを守る
管理者アカウントの使い回しを避け、不要な管理者を削除し、強い認証を設定します。WordPress公式のハードニング手順には、ファイル権限、データベース、wp-config.php、管理画面、プラグイン、ログ記録、監視などが含まれます。ログインURLを隠すだけで安全になったと考えず、権限と変更履歴を確認できる状態を優先します。更新を担当する人と、更新後に確認する人も同じ表へ書きます。担当者が休みの日に警告が届いたとき、誰が判断し、どの範囲を止めるのかが決まっていれば、放置と過剰反応の両方を減らせます。
バックアップは取得より復元を確認する
バックアップがあるという説明だけでは、障害時の判断材料になりません。データベースとファイルの両方が含まれるか、世代数と保存先が適切か、復元後にURLやフォームが正常かを、検証環境で試します。復元担当者と連絡先、判断基準、公開を止める方法も決めておきます。
WordPressのリスクは、ソフトウェア名だけで決まりません。古いPHPを放置しているのか、拡張機能を管理できていないのか、復旧を試したことがないのかで、必要な対策は変わります。現状の棚卸しから始め、更新、監視、復元を一つの運用にまとめる。サイトの安全点検を一緒に進めたい方は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹