ACQUA JOURNAL
WordPressの不正アクセス対策を見直す｜認証・WAF・通知の決め方
WordPressの対策を調べると、ログインURLの変更、セキュリティプラグイン、WAF、二要素認証など、設定の一覧が多く見つかります。すべてを入れれば安全になる、と一律には決められません。サイトの機能、ホストの契約、担当者、通知を確認する人、復元方法によって、合う対策と確認作業が変わります。
この記事では、特定の防御率や製品を勧める代わりに、誰がどの記録を見て、異常時にどう判断し、変更後に何を確認するかを決めます。対策の目的はリスクを下げ、問題に気付き、業務を戻しやすくすることです。危険をゼロにする保証ではありません。
1. まず決める：対象・担当・連絡先
以下を一枚の運用表にまとめます。サイトの管理画面、サーバー、ドメイン、メール、外部サービスの担当が異なる場合は、役割と連絡先を分けて記録してください。
| 確認する対象 | 記録する内容 |
|---|---|
| WordPress | URL、バージョン、テーマ/プラグイン、更新担当 |
| アカウント | 管理者、編集担当、外部連携、二要素認証の復帰担当 |
| ホスト/CDN | 契約プラン、WAFの場所と設定範囲、管理者、通知先 |
| 業務機能 | 問い合わせ、予約、決済、会員ログイン、メール連携 |
| ログ/通知 | 何の記録をどこから取得できるか、保存期間、確認者、連絡期限 |
| バックアップ | 対象、保存先、時点、保持期間、復元担当と試験方法 |
パスワード、秘密鍵、データベース情報を表やメールに書き込まず、アクセス権は契約先が案内する安全な方法で管理します。退職・異動で担当者が変わったときに、誰も管理画面へ入れない状態にならないよう、復帰方法も確認してください。
自社サイトのバージョンや警告、管理者、バックアップの現状から始める場合は、WordPressの安全点検と担当を確認する記事を使えます。この記事はその次の段階、認証・WAF・ログ通知をどう運用するかを決める内容です。
2. 管理者アカウントとログインを整える
「ユーザー」一覧で、管理者権限を持つ人、実際の担当者、外部連携用アカウントを確認します。各担当者に必要な権限を割り当て、日常作業に不要な管理者権限を共有しない運用を検討します。
利用者ごとに長く一意なパスワードを設定し、パスワード管理ツールを使う方法があります。特権アカウントには二要素認証や、環境に合う場合はパスキーなどの追加認証を検討します。二要素認証を導入するときは、端末紛失や担当変更時の復旧方法、予備認証手段、誰が解除できるかを一緒に決めます。
ログイン試行の制限は、WordPress、ホスト、CDN/WAFのどこで行うかを確認します。アプリ内のプラグイン方式は、攻撃が大量に届く状況ではWordPress/PHP側の処理を使う場合があります。ホストやCDN側で制限する案も含め、現在の構成と誤検知時の解除手順を確認してください。
ログインURLを変える方法は、アクセスのノイズを減らす補助にはなりますが、それだけで認証対策を置き換えるものではありません。XML-RPCは、Jetpackやモバイルアプリなどが使う場合があります。利用している連携を調べ、不要なら停止、必要なら範囲や試験方法を担当者と決めます。
既存ユーザーを削除・降格すると、投稿の帰属、予約投稿、外部連携が変わることがあります。先に代替の管理者、投稿の移管先、ログイン復帰を決めてから個別に作業します。
3. WAFは「どこを、何から守るか」で確認する
WAFはWeb通信を検査し、設定に合う通信へ記録・遮断などの処理を行う仕組みです。ホストに付属する機能、CDN/クラウド側、WordPress内のプラグインでは、通信が処理される場所や確認できるログ、契約プラン、調整方法が異なります。
設定を選ぶ前に、次を確認します。
- いま使っているホスト、CDN、WAFの機能名と契約範囲
- Web通信が実際にそのWAFを通っているか
- 対象になるURL、通信、ルールと、除外・解除の方法
- 問い合わせ、ログイン、予約、決済、APIなどの動作への影響
- 検知・遮断ログを誰が見て、誤検知があればどこへ連絡するか
- DNS、メール、外部サービスなど、切替時に影響する設定
「ONにしたら十分」「無料プランなら同じ機能」と決めず、契約プランの対象ルールと例外を確認します。たとえばCloudflareのWAF公式仕様ではFree Managed Rulesetと有料プランのCloudflare Managed Rulesetが分かれています。製品名だけで防御範囲を同じと見なさず、契約中の画面と公式仕様を照合してください。
設定を変更する場合は、まず現状の値と変更者を記録し、影響の少ない範囲から試します。変更後はサイト閲覧だけでなく、管理画面、フォーム送信と受信、予約・決済、外部APIなど実際に使う機能を確認し、誤検知時の解除担当も共有します。
4. ログ通知は「検知」から「対応」まで決める
ログは、記録を取るだけでは業務上の対応につながりません。取得できる記録はホスト、CDN/WAF、WordPressの機能や契約によって異なります。管理画面の操作記録が標準で残ると決めつけず、何をどこまで確認できるか、保存期間は何日かを先に調べます。
運用表には、次の列を用意します。
| 確認対象 | 記録の例 | 対応を決める人 |
|---|---|---|
| 認証 | 成功/失敗したログイン、時刻、対象アカウント | 管理担当。身に覚えのない成功は担当へ連絡 |
| アカウント | 管理者の追加・権限変更・退職者の状態 | サイト管理者。正規の作業かを記録と照合 |
| WAF/ホスト | 検知・遮断の日時、対象URL、ルール、結果 | ホスト/WAF管理者。フォーム等の誤検知も確認 |
| 更新 | 本体・テーマ・プラグインの更新結果と通知 | 更新担当。表示・フォームの試験結果も残す |
| 公開機能 | 問い合わせの受信、予約/決済の失敗、停止 | 業務担当。サイトが応答するだけで完了としない |
ログのIPアドレスや大量のログイン失敗だけで、特定の個人や侵入を断定しないでください。記録の前後関係、管理者の作業予定、ホストからの通知と照合します。
通知には、宛先だけでなく「誰が読むか」「いつまでに見るか」「担当者が不在なら誰に渡すか」「ホストへ連絡する条件」を設定します。設定後はテスト通知を送り、実際に届くことと、対応担当が受信できることを確かめます。メール通知が即時に届く・すべての異常を検出するとは限らないため、通知機能の対象と遅延、監視できない範囲も記録します。
5. 更新とバックアップを一組で運用する
更新通知を確認し、提供元の案内、変更内容、使っている機能、復元できる時点を確認します。プラグイン・テーマの自動更新を使う場合も、対象ごとに設定し、更新結果の通知を受ける担当を決めます。更新を実行したままにせず、主要ページやフォームを試す工程を予定に入れてください。
作業前に、ファイルとデータベースの保存状況、保管場所、取得日時、保持期間、復元担当を確認します。復元時には保存時点以降の予約・注文・問い合わせなどが失われることがあります。どのデータが戻り、どのデータが戻らないか、実作業前に合意します。
バックアップ方式の比較はWordPressのバックアップ方法を選ぶ記事、保存済みのバックアップからどの時点へ戻すか、復元後に何を確認するかは復元判断と試験の記事を確認してください。復元は本番以外の環境で試す方法を優先し、実施後にログイン、主要ページ、フォーム、業務データを確認します。
変更前後に使う記録票
| 項目 | 作業前 | 作業後 |
|---|---|---|
| 目的と対象 | どの問題/機能に対する変更か | どこを変更したか、想定との差 |
| 設定/バージョン | 現在値、日時、担当者 | 新しい値、更新結果 |
| 保存/復元 | バックアップ時点、対象、復元者 | 必要なら戻せる状態か、残る懸念 |
| 確認した機能 | ログイン、フォーム、外部連携等 | 成功/失敗、確認者、確認時刻 |
| 通知/連絡 | 宛先、期限、緊急連絡先 | 通知が届いたか、次に対応する人 |
変更を一度に重ねず、結果が分かる単位で実施します。特に本番のDNS、WAF、認証、プラグイン、PHP設定に変更を加える場合は、担当者、承認者、影響範囲、戻す方法を先に決めます。
6. 不正アクセスを疑う兆候に気付いたら
見覚えのない管理者、予定にない認証成功、知らないファイルやプラグイン、サイトの改ざん、ホストからの警告に気付いたら、次を記録します。
- 症状、対象URL、発見した日時とタイムゾーン
- 見覚えのないアカウントや変更、関連する通知
- 直近で行った更新、設定変更、外部連携の追加
- 影響するフォーム、予約、決済、メール、顧客情報
- ホスト、制作/保守担当、社内責任者の連絡先
不用意なファイル削除、プラグイン追加、バックアップ上書き、パスワード一斉変更を始めず、ホストと現在の管理担当へ連絡します。共有サーバーや顧客情報が関係する場合は、影響範囲とログ/バックアップの保存方法を確認してください。利用者へ見せる必要がある対応やアクセス制限は、業務影響を踏まえて責任者と決めます。
原因の確認、侵害範囲の調査、駆除、復旧の手順は、サイトの症状と契約範囲で異なります。状況を記録してホストへ伝える手順はWordPressサイトの被害初動ガイドも参照してください。復元だけで侵入経路が解消したとは限りません。
7. Acquaに任せる場合
自社で設定と通知を管理できる場合は、この記事の表を使って、担当者・確認間隔・復帰方法・変更後のテストを記録してください。更新やWAFの確認、バックアップ、主要ページ/フォームの動作確認まで任せたい場合は、サイトと契約、必要な範囲を確認してから作業内容を決めます。サービスの案内に記載された作業候補も、対象サイトと合意した条件をもとに整理します。
- 企業・事業者の方：保守・運用案内を確認し、サイトURL、使っているホスト/WAF、通知先、止められない機能、現在の担当を添えて相談できます。企業向けの支援全体はこちらです。
- 制作会社・広告会社の方：実装・テスト・顧客連絡の承認者と納品範囲を共有し、制作パートナーの相談窓口へ進めます。
独立した脆弱性診断、侵害調査・駆除、24時間の監視や緊急対応が必要な場合は、対象、成果物、対応時間、契約、費用を別途確認してください。この記事や一般的な保守案内だけでは、これらの受付・保証条件は確定しません。
8. よくある質問
ログインURLを変えれば不正ログインを防げますか？
URLを見つけにくくすることは補助策ですが、それだけで認証を守るものではありません。個別のアカウント、強いパスワード、追加認証、試行制限、通知と復帰方法を組み合わせて検討します。
WAFを有効にすれば他の対策は要りませんか？
いいえ。WAFは契約範囲、通過する通信、ルール、例外によって対象が変わります。アカウント管理、更新、バックアップ、ログ通知、業務機能の確認も必要です。
失敗したログイン通知は何回から出せばよいですか？
固定回数をすべてのサイトへ適用する根拠はありません。ログの取得場所、普段のアクセス、通知件数、担当者が対応できる時間から試し、正規利用者の締め出しや見落としがないか見直します。
WordPressの管理者を一人だけにしてよいですか？
管理者権限を必要な人へ絞る一方、担当者不在時に更新や復旧ができなくならないよう、承認済みの代替担当と安全な復帰方法を決めます。アカウント削除の前に、投稿や連携の扱いも確認します。
参照した一次情報
- WordPress公式：ブルートフォース攻撃への対策
- WordPress公式：WordPressの堅牢化
- WordPress公式：ユーザー画面
- WordPress公式：プラグインとテーマの自動更新
- Cloudflare公式：WAF Managed Rulesとプラン別の対象
（参照日：2026年10月4日。画面名、利用可能な機能、契約条件はWordPressの版やホスト、各サービスのプランで異なります。）