ACQUA JOURNAL
WordPressのセキュリティ対策を見直す｜更新・認証・復元の15項目
WordPressの安全性は、設定を何個入れたかだけでは判断できません。サイトの役割、使っている拡張機能、更新を担当する人、保存と復元の方法を確認し、業務への影響が大きいところから対策します。
一般的な防止率や設定数だけでは、自社サイトの状態は判断できません。確認した状態と、次に対応する担当を記録します。
この記事の15項目は、全員が同じ設定を順番に変更する指示ではありません。現状を確認し、必要な作業だけ選ぶためのチェックリストです。管理画面へ入れない、知らないユーザーやファイルがある、サイト表示が書き換わったなど、すでに異常が疑われる場合は、設定を変える前にWordPress公式の侵害時の案内と契約中のホストの手順を確認してください。
1. 最初に決めること：どこまで止められるか
サイトの障害や不正アクセスのリスクをゼロにする設定はありません。WordPress公式資料も、セキュリティはリスクを減らし、問題が起きたときに復旧できるよう準備する継続的な作業と説明しています。WordPress公式のセキュリティ解説
まず、次の情報を分かる範囲で一枚にまとめます。
- サイトのURL、ホスティング会社、管理画面とサーバーの連絡先
- サイトで受け付けている問い合わせ、予約、注文など、止まると困る機能
- WordPress本体、テーマ、プラグインの更新を行う担当者
- 管理者アカウントと、退職・契約終了後に権限を外す手順
- バックアップの取得場所、保存範囲、復元を依頼できる窓口
- 異常を見つけた人が連絡する順番と、利用者へ案内する担当者
担当や契約が分からない項目は「未確認」と記録します。確認前に、ログインURL、ユーザー、権限、ファイル設定、データベースなどを一括変更しないでください。
2. 15項目の確認リスト
認証・更新・保存・通知を分けて点検します。確認できた状態と未確認を記録し、変更が必要な項目だけ担当者と判断してください。
1. サイトとホストの担当範囲を確認する
ホスティング会社が管理するサーバーと、サイト担当者が管理するWordPress本体・テーマ・プラグインでは、作業の責任範囲が異なります。サーバーのWAF、ログ、バックアップ、障害時の連絡先について、契約画面やサポート窓口で確認します。
2. 管理者アカウントと権限を確認する
「ユーザー」画面で、誰が管理者か、複数人で同じIDを共有していないか、使われていないアカウントが残っていないかを確認します。担当者ごとにアカウントを分け、必要な権限にします。アカウントを削除する前に、投稿者の記録、連携サービス、緊急時に入れる管理者、パスワード復旧の方法を確認してください。
3. 強く一意なパスワードを使う
他サービスと使い回さず、推測しにくい長いパスワードをパスワード管理ツールで管理します。会社名やサイト名、担当者名を組み合わせた文字列は避けます。退職・担当交代や漏えいの疑いがあるときは、影響するアカウントと連携先を確認して変更します。
4. 管理者の二段階認証を検討する
二段階認証は、パスワードに加えて別の確認手段を使う方法です。WordPress本体に標準で含まれる機能とは限らず、プラグインや認証サービスを使う場合は、管理者全員への設定、機種変更時の復旧コード、ログインできない場合の代替手段を先に用意します。本人確認手段を失うと正規担当者が入れなくなる点も確認してください。WordPress公式の二段階認証案内
5. ログイン不能時の復帰方法を決める
認証アプリやパスワードを失った場合に、誰がホストへ連絡し、本人確認をして、管理者を復旧するか決めます。復旧用メールアドレスや電話番号が退職者のものになっていないかも確認します。連絡先や復旧コードを公開場所へ置かず、権限を持つ担当が保管してください。
6. WordPress本体の更新状態を確認する
管理画面の更新通知とWordPress公式の更新情報を確認します。更新の前に、サイト全体のバックアップと復元方法を確かめ、更新後はログイン、重要ページ、フォーム、予約・決済など実際に使っている機能を試します。重大なセキュリティ更新を長く放置しない一方、復元できない状態で大規模な更新をまとめて行わないでください。
7. テーマとプラグインの配布元・更新状態を確認する
利用中のテーマとプラグインについて、配布元、現在のバージョン、更新通知、サイトのどの機能が依存しているかを一覧にします。更新が止まっている期間だけで危険と断定せず、開発元の告知、既知の問題、WordPressやPHPとの互換情報、代替の有無を確認します。配布元が分からないファイルは、管理画面からすぐ削除せず担当者へ調査を依頼します。
8. 使っていないプラグインやテーマを整理する
使っていない拡張機能は、不要と確認できれば停止・削除を検討できます。削除前に、テーマ、ショートコード、フォーム、決済、外部連携などが依存していないかを調べます。現在の構成とバックアップを記録し、削除後に管理画面・主要ページ・フォームを確認してください。複数のセキュリティプラグインを重ねて導入する必要はありません。
9. 自動更新をサイトごとに選ぶ
WordPressでは、プラグインやテーマごとに自動更新を選べる場合があります。自動更新の可否、通知、ホスト側の制御、更新後に異常を見つけたときの戻し方を確認し、重要機能への影響を考えて設定します。自動更新を有効にして終わりではなく、通知を受け取る担当者と定期的な表示確認を決めます。WordPress公式のプラグイン・テーマ自動更新案内
10. ログイン試行と不審なアクセスへの対応を確認する
ホストやWAF、プラグインなど、どこでログイン試行を制限できるか確認します。固定回数や固定時間をすべてのサイトへ適用するのではなく、正規担当者の誤入力、共有回線、外部連携が止まらないかを考えます。通知を誰が読み、どの状況でホストや実装担当者へ連絡するかも決めます。WordPress公式のブルートフォース対策
11. ログインURLとXML-RPCは必要性を調べてから変更する
ログインURLを変えても、認証や更新の代わりにはなりません。アクセスログのノイズを減らす目的で変更する場合は、担当者が新しいURLから入れること、外部サービスやアプリとの連携が動くこと、失敗時の復帰方法をテストします。
XML-RPCも、外部アプリや連携で使われている場合があります。使っている機能とホスト/WAFの選択肢を確認し、無効化するなら影響範囲を試験します。.htaccessへ遮断コードを貼る前に、Webサーバーの種類と既存設定を確かめてください。WordPress公式のブルートフォース対策でも、サーバーごとに異なる設定例を説明しています。別の環境向けのコードを流用せず、契約先の方式を確認します。
12. HTTPSと証明書の更新を確認する
サイトと管理画面がHTTPSで表示され、証明書の期限切れや混在コンテンツの警告がないか確認します。HTTPSは通信を暗号化しますが、古いプラグインや権限設定の問題を解決するものではありません。証明書の自動更新と、更新失敗時の通知先も確認します。
13. バックアップの保存内容と復元を試す
WordPressの復元には、通常、ファイルとデータベースの両方が必要です。更新頻度や失ってよいデータの範囲に応じて取得頻度と保管世代を決め、サイトとは別の保管先も使います。取得完了の表示だけでは復旧できるとは限りません。可能であれば本番に影響しない別環境へ戻し、記事、画像、フォーム、ログインを確認します。WordPress公式のバックアップ案内
14. サーバー設定とファイル権限は環境に合わせて確認する
wp-config.phpの権限、ディレクトリ一覧の表示、管理画面からのファイル編集を見直す場合は、Webサーバー、所有者、ホストの自動更新方法を確認します。設定例をそのまま適用すると、更新・アップロード・サイト表示に影響することがあります。WordPress公式資料にも構成により権限が異なる説明があります。chmod 440などの一律コマンドを実行せず、現状を記録し、変更前の復旧方法を確保してから必要な範囲だけ試します。WordPress公式のHardening資料
データベースのテーブル接頭辞を変えても、SQLインジェクションを解決するものではありません。稼働中サイトでの変更は、プラグインや独自コード、データベースへの影響を確認せずに行わないでください。
15. ログ、通知、定期点検の担当を決める
更新、ログイン失敗、バックアップ失敗、フォーム停止など、どの通知を誰が確認するかを決めます。作業日、変更内容、確認した画面、問題が起きたときの連絡先を記録します。定期点検では設定を増やすこと自体を目標にせず、担当者の交代、サイトの機能追加、ホスト契約の変更に合わせて手順を見直します。
3. 変更前後に使う簡単な記録票
| 確認項目 | 記録する内容 |
|---|---|
| 対象 | URL、環境、本体・テーマ・プラグインの版 |
| 困りごと | 何を守りたいか、止まると困る業務は何か |
| 現在の状態 | 管理者、認証、更新、保存、通知の担当 |
| 変更候補 | 変える設定と、影響しそうな機能 |
| 戻す方法 | バックアップの時点、復旧を行う人、連絡先 |
| 作業後の確認 | 管理画面、主要ページ、フォーム、予約/決済、通知 |
| 未解決 | 確認できなかった点と、次に確認する担当・期日 |
一つずつ作業し、変更直後に必要な画面と機能を確認します。問題が起きた場合は、同じ設定を追加し続けず、記録を残して復元またはホストへの相談を判断します。
4. どれから確認するか
不審な管理者や改ざんが見つかった場合は、通常の点検を中断し、証拠を残してホストの侵害時手順を確認します。異常が見つかっていない場合は、まず担当者と復元方法、更新通知、重要な機能を確認します。すぐ直したい更新がある場合も、サイトのバックアップと戻し方を確認してから作業します。ステージングを使えるサイトはそこで互換性を試し、使えない場合はホストの案内を確認して、変更範囲を小さくし、一度に複数の設定を変えないようにします。
5. 自社でできる確認と、担当者へ渡す作業
管理画面の更新通知、登録ユーザー、通知メールの宛先、ホストの契約画面に表示されるバックアップ日など、表示を読むだけの確認は担当者自身でも始められます。サイトのパスワードや復旧コードを送らずに、画面の状態と分かった範囲を記録してください。ホスト会社へ問い合わせる場合も、契約者本人であることを確認できる窓口から連絡します。
一方、SQLの書き換え、サーバー設定、ファイル権限、管理者削除、ログイン方法の切替、データの復元は、設定を間違えるとログインや受付機能が止まる場合があります。設定値を変える前に、作業者、影響する機能、作業環境、作業後の確認、失敗したときの戻し方を決めてください。手順や復元手段が分からない場合は、危険な操作を試す前にホストまたは実装担当者へ質問します。
相談時に共有するとよい情報は、サイトURL、困っている画面や機能、停止すると困る業務、最後に正常と確認できた時点、現在分かるバックアップと管理者の状況です。パスワード、復旧コード、顧客情報、設定ファイルの秘密鍵やAPIキーをメールやフォームへ貼らないでください。安全な受け渡し方法が必要なときは、担当者と確認してから別途共有します。
6. WordPressに異常が見つかったとき
知らない管理者、改ざんされたページ、見慣れない広告、マルウェア警告が見つかったときは、影響を広げないことと調査記録を残すことを優先します。手当たり次第にファイルを削除したり、古いバックアップを本番へ上書きしたりしないでください。ホストの緊急連絡手順を確認し、発見時刻、画面、通知、直前の変更、影響する機能を記録します。顧客情報やフォーム受付に影響する可能性がある場合は、社内の責任者へすぐ共有し、必要な対応を確認します。
調査・駆除・復旧は、通常の更新作業と範囲や前提が異なります。誰がどの環境で何を確認し、どこまで対応するかを契約や作業合意で確認してください。
7. Acquaへ相談するときに伝えること
自力で確認できる人は、上の記録票で担当と残る課題を整理してください。更新、権限、バックアップ、表示やフォーム確認を実務担当へ任せたい場合は、WordPressサイトのURL、止まると困る機能、分かっている契約・ホスト、希望する作業を共有すると、相談範囲を整理しやすくなります。
- 企業向けWeb制作・運用支援では、Webまわりの制作・更新・保守を相談できます。
- 制作会社向けパートナー案内では、WordPress実装などの依頼について相談できます。
- お問い合わせでは、相談の目的と希望工程を分けて送れます。
対応内容、緊急時の受付、費用、期間はサイトの状態と希望する作業に応じて確認・合意します。診断・駆除・常時監視を標準条件として約束するものではありません。
8. 対策後に目指す状態
管理者と連絡先が分かり、必要な更新を行える。重要ページ、管理画面、フォームが使える。バックアップの保存場所と、実際に戻す担当・方法が分かる。異常を見つけた人が記録し、次の担当へ引き継げる。こうした状態を確かめることが、設定数やプラグイン数を増やすより、運用を続けるうえで役立ちます。
参考にした公式資料