WordPressのセキュリティ対策を多層防御の優先順位フレームで整理。公的データで読む現実的なリスク水準、ログイン経路→脆弱性管理→バックアップ→WAFの4層、主要プラグインの選び方、インシデント時の復旧プロトコルを解説します。
この記事でわかること
- WordPressのセキュリティ対策を「多層防御の優先順位フレーム」で動かす理由と、各層の判断基準
- 公的データ（IPA情報セキュリティ10大脅威／警察庁サイバー脅威情勢／JPCERT/CC）で読み解く現実的なリスク水準
- 「ログイン経路→脆弱性管理→バックアップ→WAF」の4層フレームの実装手順
- Wordfence／SiteGuard WP Plugin／All-In-One Security の選び方と組み合わせ
- インシデント発生時の90日復旧プロトコル（保全→通報→復旧→再発防止）
これからWordPressを始める方は、サーバー選びの段階でバックアップとWAFが標準提供されているかが効きます。
サーバー選びの基準はWordPressに最適なレンタルサーバーおすすめで整理しています。
結論を先に書きます
WordPressのセキュリティ対策を最短で動かすなら、巷で語られる「セキュリティプラグインを2〜3本入れる」「ログインURLを変える」といった表層TIPSの羅列から入らないことが起点になります。
おすすめは、「①ログイン経路の遮断 → ②脆弱性管理 → ③バックアップと復旧 → ④WAF／サーバー側多層防御」の優先順位フレームで層構造に動かす進め方です。入れるべきプラグインの本数より、層の順序を逆転させないことのほうが被害確率を大きく下げます。
公的データと突き合わせても、WordPressの被害は「層の優先順位を間違えた順序逆転」にほぼ集約されます。表層TIPSは個別の防御手段を語っているだけで、どの層をどの順番で固めるかを語っていないからです。
- 対策は「多層防御の優先順位フレーム」で動かす。順序を逆転させないことが最大の差別化軸
- 被害の大半は第1層（ログイン経路）と第2層（脆弱性管理）で予防できる構造
- プラグインは2本以内に収め、層ごとに役割を割り当てる
- 予防では止まらない事故に備え、バックアップと90日復旧プロトコルを事前に用意する
この記事は、発注側（中小企業のWeb担当者・経営者）と受注側（制作会社・フリーランス）の両方を想定し、多層防御の優先順位フレームと各層の判断軸を1つずつ整理します。
WordPressのセキュリティ対策は「多層防御の優先順位フレーム」で動かす
WordPressの入門記事や上位記事では「Wordfenceを入れる」「ログインURLを変える」「reCAPTCHAを入れる」といった表層TIPSの羅列で語られることが多いです。これは個別の防御手段の整理であって、層の順序の整理ではありません。
現場で起きやすいのは、プラグインを5本入れて満足し、コアの更新を半年放置する。ログインURLは変えたがadminユーザーのまま。こうした順序逆転に陥り、結果としてテーマ／プラグイン経由の改ざんを受けるケースです。
4層防御フレームの全体像
サイトリニューアル案件の運用フェーズで組み立てられているのは、次の4層防御フレームです。層の順序を逆転させないこと自体が、被害確率を桁単位で下げる差別化要因になります。
- 第1層 ログイン経路の遮断──/wp-admin・/wp-login.php・XML-RPC・REST APIの4つの侵入口を、ユーザー名強度・パスワード強度・二要素認証（2FA）・IP制限・ログインURL変更で固める
- 第2層 脆弱性管理──コア・テーマ・プラグインの更新運用を「いつ・誰が・どの基準で」適用するかルール化する
- 第3層 バックアップと復旧フロー──世代管理・保存先の分散（サーバー外）・復旧手順の事前リハーサル。突破された場合の最終防衛線
- 第4層 WAF／サーバー側多層防御──サーバーWAF・CDNレベルのWAF・リバースプロキシ・SSL/TLSの最新規格対応。アプリ層を超えた攻撃を入口で削る
順序を守らずに第4層からスタート（WAFを入れて満足）すると、肝心の第1層が露出したままになります。攻撃者から見れば「玄関の鍵は開いているのに、外壁だけ厚い家」です。改ざんを受けたサイトの多くが、この「第4層は手厚いが第1層・第2層が薄い」という順序逆転に当てはまります。
なぜ「プラグイン羅列型」の対策では破綻するのか
「セキュリティプラグインを2〜3本入れれば安心」という認識が実務で破綻する理由は、公的データを見ると構造的に浮かびます。
IPA（独立行政法人 情報処理推進機構）の「情報セキュリティ10大脅威 2024」（出典：IPA 情報セキュリティ10大脅威 2024）では、組織向け脅威に「ランサムウェアによる被害」「サプライチェーンの弱点を悪用した攻撃」「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」「脆弱性対策情報の公開に伴う悪用増加」などが並びます。
WordPressに直結するのは、特に「ゼロデイ攻撃」と「脆弱性対策情報の公開に伴う悪用増加」の2つです。これらはプラグインを入れたかどうかではなく「更新運用がルール化されているか」で被害確率が変わります。
警察庁の「サイバー空間における脅威の情勢」（出典：警察庁 サイバー空間をめぐる脅威の情勢）でも、中小企業の被害報告が増加傾向にあり、「公開済み脆弱性を悪用した攻撃」「認証情報を悪用した攻撃」が継続的に観測されています。
WordPressの場合、認証情報（管理者ID／パスワード）の漏えいとプラグイン脆弱性の悪用が統計の主要構成要素です。つまり第1層（ログイン経路）と第2層（脆弱性管理）の2つで、被害の大半を予防できる構造になっています。
| 公的データ | WordPress運用への示唆 |
|---|---|
| IPA 10大脅威 | ゼロデイ・脆弱性悪用は「更新運用のルール化」で被害確率が変わる |
| 警察庁 脅威情勢 | 認証情報悪用と公開済み脆弱性が主因。第1層・第2層で大半を予防 |
| JPCERT/CC | Webサイト改ざん・CMS脆弱性悪用が継続的に報告される |
| 経産省 経営ガイドライン | 脆弱性情報の収集・適用、インシデント体制、委託先管理が要点 |
JPCERT/CC（一般社団法人 JPCERTコーディネーションセンター）の「インシデント報告対応レポート」（出典：JPCERT/CC インシデント報告対応レポート）でも、CMS（WordPressを含む）の脆弱性悪用が継続的な比率で報告されています。プラグインを入れても、コア・テーマ・プラグインの更新が止まっていれば、報告件数の構造的な分母は減りません。
経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver 3.0」（出典：経済産業省 サイバーセキュリティ経営ガイドライン）でも、WordPress運用に直結するのは「脆弱性情報の収集と適用」「インシデント発生時の体制整備」「委託先の管理」の3項目です。いずれもプラグイン購入予算ではなく、運用ルールと体制で決まる項目になります。
第1層 ログイン経路の遮断（最優先で固める）
4層フレームの第1層、ログイン経路の遮断から具体的に整理します。WordPressのログイン経路は、表面的には「/wp-login.php」と「/wp-admin」の2つに見えますが、実際にはXML-RPC（/xmlrpc.php）とREST API（/wp-json/）の2つも認証経路として攻撃面になります。ブルートフォース攻撃の多くは、XML-RPC経由の試行を含みます。
第1層で固める5つの実装項目
第1層の実装項目を順序通りに整理します。これは全部やるのが基本で、1つでも欠けると残りが意味を失う層です。
- adminユーザーを使わない──「admin」のままなら別名で管理者ユーザーを作成し、旧adminは削除。攻撃者は最初に「admin」を試行する
- 強パスワード＋二要素認証（2FA）──16文字以上の英数字記号混在。Google Authenticator等のTOTP方式での2FAを必須化（SMS方式は番号乗っ取りリスクで非推奨）
- ログインURLの変更──/wp-login.php を独自パスへ。これ単独では突破されるため「強パスワード＋2FA」と組み合わせる前提
- XML-RPCの無効化または制限──外部連携（Jetpack等）で使わなければ、.htaccessでIP制限・遮断する
- REST APIの認証必須化──/wp-json/wp/v2/users などの未認証GETを制限し、ユーザー名列挙を防ぐ
これら5項目を全て揃えて、ようやく「ログイン経路の遮断」が成立します。1つでも抜けると攻撃者は最も弱い経路から試行を始めるため、全体の安全性は最弱項目で決まる構造です。
なお、認証情報を扱う以上、保管・運用に個人情報保護の観点が絡みます。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン」（出典：個人情報保護委員会 個人情報の保護に関する法律ガイドライン）では、安全管理措置として「アクセス制御」「アクセス者の識別と認証」「外部からの不正アクセス等の防止」が整理されています。委託で運用を引き受ける場合は、契約書に2FA運用とパスワード管理ポリシーを明記しておくのが、責任分界点を整理するうえで標準です。
第2層 脆弱性管理（更新運用のルール化）
第2層は脆弱性管理です。ここは「やる／やらない」の二択ではなく、「どの粒度・どの頻度でルール化するか」の設計問題になります。更新を「気が向いたとき」にやっている運用は、必ずどこかで止まり、止まったタイミングで脆弱性を踏みます。
現実的に回る更新運用ルール
- コアのマイナー更新は自動有効化──セキュリティリリースはWordPress 5.6以降デフォルトで自動更新。手動で切らない運用が基本
- コアのメジャー更新は月次・ステージング先行──6.x→6.y は本番直適用せず、ステージングで動作確認後に反映。月初の固定曜日に枠を取る
- プラグインは週次・テーマは月次──プラグインは脆弱性報告が多いため週次で通知確認、セキュリティ修正は即適用。テーマは月次見直しで足りるケースが多い
- 使っていないプラグイン・テーマは削除──停止中でも脆弱性経由で悪用されることがある。半年使っていなければ削除
- 更新ログの保管──「いつ・誰が・何を更新したか」をスプレッドシート1枚で残す。インシデント調査コストが激減する
このルールを契約書に「保守契約の最低ライン」として明記するのが、受注側にとっても発注側にとっても透明性の高い運用です。IPAの「組織における内部不正防止ガイドライン」（出典：IPA 組織における内部不正防止ガイドライン）でも、操作ログ保管と権限分掌が組織的安全管理措置として整理されており、更新ログを残すこと自体が「安全管理措置を講じている」根拠の一部になります。
脆弱性情報の取得源
脆弱性情報は、複数のソースを並列で見るのが基本です。最低ラインで次の3つを押さえます。
- JPCERT/CC 注意喚起・脆弱性関連情報──JPCERT/CC 公式 でWebサイト改ざん／CMS脆弱性の情報を定期確認
- JVN（Japan Vulnerability Notes）──JPCERT/CCとIPAが共同運営するJVN でWordPress関連脆弱性情報をRSS購読
- WordPress公式 セキュリティリリース──WordPress.org Security でコアのセキュリティリリースを把握
第3層 バックアップと復旧（最終防衛線としての世代管理）
第3層はバックアップと復旧フローです。第1層・第2層を組んでも、ゼロデイ脆弱性・サプライチェーン攻撃・内部不正など、予防では止められないインシデントが残ります。「事故が起きる前提」で組むのが第3層で、ここを薄くすると復旧コストが膨らみます。
バックアップ世代管理の最低ライン
- 日次バックアップ（直近7世代）──ファイル＋データベースの両方。エックスサーバーやConoHa WINGは日次14世代の自動バックアップを標準提供
- 週次バックアップ（直近4世代）──サーバー外（ローカル／別クラウドストレージ）へ退避。サーバー全体が侵害された場合の最終防衛線
- 月次バックアップ（直近12世代）──長期保管。改ざんを後追いで発見した場合の復元に使う
- 復旧リハーサル（年1回）──バックアップから実際にステージングを復元する。「取れているが復旧したことがない」は、事実上バックアップがないのと同じ
- 個人情報を含むバックアップの保管期間ルール──保管期間と廃棄ルールを明確化。利用目的との関連性で必要な期間に限定する運用が個人情報保護法の要請に整合する
サーバー選定の段階で、自動バックアップ機能の有無は重要な判断軸です。詳細はWordPressに最適なレンタルサーバーおすすめとレンタルサーバー比較（用途別マトリクス）で整理しています。バックアップ運用込みで考えると、サーバー側に世代管理機能があるかどうかは月額1,000円台の差以上の価値があるケースが多いです。
- バックアップは取れているのに、保存先がサーバー内のみ（同じディスク上）で、ランサムウェア／改ざん時にバックアップごと暗号化・改ざんされる失敗が起きやすい
- 「サーバー外」「別クラウド」への退避が、第3層を機能させるための前提条件
第4層 WAF／サーバー側多層防御（SSL/TLS・Cloudflare・サーバーWAF）
第4層はWAF（Web Application Firewall）とサーバー側の多層防御です。順序として第4層に置いているのは「重要度が低い」という意味ではなく、第1〜3層を固めずに第4層から入ると効果が薄いという意味です。第1〜3層が揃った上で第4層を厚くすると、攻撃の大半を「アプリケーション層に到達する前」に削れます。
サーバー側WAFの実装ライン
サーバー側WAFは、レンタルサーバーが標準提供しているものをまず有効化するのが基本です。エックスサーバー・ConoHa WING・カラフルボックス等の主要レンタルサーバーは、WAF機能を標準で提供しており、管理画面からON/OFFとルールセットのカスタマイズが可能です。デフォルトでONのサーバーもあれば、初期設定で手動有効化が必要なサーバーもあるため、契約直後に確認します。
SSL/TLSとHSTSの実装
SSL/TLSの実装は、Let’s Encryptの無料証明書で足りるケースが多く、TLS 1.2以降のみ許可、TLS 1.0/1.1は無効化するのが2026年時点の標準ラインです。HSTS（HTTP Strict Transport Security）ヘッダの設定で、HTTPアクセスを強制的にHTTPSへ昇格させ、中間者攻撃の余地を削ります。総務省「情報通信白書」（出典：総務省 情報通信白書）でも、暗号化通信の普及状況が継続的に整理されており、HTTPS化は前提になっています。
Cloudflare等のリバースプロキシ層
大規模サイトやDDoS攻撃が懸念されるサイトでは、Cloudflareなどのリバースプロキシ層を追加します。中小規模サイトでは無料プランで足りるケースが多く、IPの隠匿・Bot対策・レートリミットがWAF機能と組み合わせて有効化できます。
注意点として、Cloudflare経由のリクエストはサーバーログ上の送信元IPがCloudflareのIPになります。SiteGuardやWordfenceのIP制限機能と組み合わせる場合、Cloudflareの実IP復元機能（CF-Connecting-IPヘッダ）を有効化しておく必要があります。
セキュリティプラグイン3本の比較（Wordfence／SiteGuard／All-In-One）
第1〜4層を実装する際に使うセキュリティプラグインを3本で比較します。「どれが最強か」ではなく「どの層をカバーするか」「運用負荷がどう違うか」で選ぶのが基本です。
| プラグイン | 主なカバー層 | 運用負荷の体感 | 向くサイト |
|---|---|---|---|
| SiteGuard WP Plugin | 第1層（ログイン経路） | 低（日本語UI・設定がシンプル） | 中小企業・個人サイト全般 |
| Wordfence | 第1層・第2層・第4層 | 中（機能が多い／通知調整が必要） | 中〜大規模・複数プラグイン運用 |
| All-In-One Security | 第1層・第2層 | 中（設定項目が多い／スコア化） | 段階的に強化したいサイト |
現実的な「2本構成」の組み合わせ
3本全部入れる必要はなく、機能重複が運用負荷を増やすため、現実的な組み合わせは次の2パターンです。
- 中小企業案件の標準形：SiteGuard WP Plugin（第1層）＋ サーバー側WAF（第4層）＋ レンタルサーバー標準バックアップ（第3層）。コアの自動更新＋プラグイン週次更新ルール（第2層）で全層をカバー
- 中〜大規模サイトの強化形：Wordfence（第1層・第2層・第4層）＋ サーバー側WAF（第4層）＋ Cloudflare（第4層）＋ 別クラウドへの週次退避（第3層）
テーマ・プラグインの選定そのものはWordPressテーマ比較（SWELL／Cocoon／Lightning）で整理しています。組み合わせ全体での運用負荷を見るには併読をおすすめします。
5年残った施策／廃れた施策（棚卸しの基準）
長期運用で「5年経っても残った施策」と「廃れた／非推奨になった施策」を整理します。新規実装の優先順位を決めるときの参考にしてください。
おすすめできる定着施策
- 強パスワード＋2FA（TOTP方式）を管理者全員で必須化
- adminユーザーの廃止と別名管理者ユーザーへの切り替え
- SiteGuard WP PluginによるログインURL変更＋画像認証、XML-RPCの遮断
- コアのマイナー更新自動有効化、プラグイン週次・テーマ月次の更新ルール
- サーバー標準の日次自動バックアップ＋サーバー外への週次退避
- SSL/TLS（TLS 1.2以降）＋HSTS、サーバー側WAFの有効化
おすすめしない（廃れた・非推奨）施策
- セキュリティバイオブスキュリティ単独運用（wp-config.phpの場所を変えるだけ）
- SMS方式の2FA（番号乗っ取りリスクで非推奨）、2FAを入れないBasic認証のみ
- セキュリティプラグインを5本以上重ねる構成（機能重複で運用破綻）
- WAF・キャッシュ系プラグインだけで「対策完了」とみなす運用
- 古いWordPress（5.5以前）の「動いているから触らない」運用
- サーバー内のみ（同じディスク）のバックアップ、FTP（暗号化なし）転送
起きやすいのは、廃れた施策のうち1〜2項目を残したまま「全体としてセキュリティが固まった」と認識して運用が止まり、半年後にインシデントを踏むパターンです。施策の本数ではなく、廃れた施策が残っていないかの棚卸しを年1回行うのが保守運用の基本形になります。
インシデント発生時の90日復旧プロトコル
第1〜4層を組んでも、ゼロデイ脆弱性・サプライチェーン攻撃・内部不正でインシデントが起きる可能性は残ります。発生時の対応をテンプレ化しておくことで、復旧コストと二次被害を最小化できます。
Day 1〜3 保全フェーズ
最優先は「事実の保全」と「拡大の停止」です。改ざんされたサイトをそのままにせず、サーバー側でメンテナンスモード（503）に切り替え、ログ（アクセスログ・エラーログ・WordPressデバッグログ）と現状ファイルのスナップショットを取得します。復旧を急いで上書きすると、原因究明と再発防止に必要な証跡が消えます。保全フェーズは復旧フェーズの前に必ず置きます。
Day 4〜7 通報フェーズ
個人情報が漏えいした可能性がある場合、個人情報保護委員会への報告が必要になるケースがあります。個人情報保護委員会の「漏えい等の報告」（出典：個人情報保護委員会 漏えい等の報告）では、報告対象となる事案と報告期限が整理されています。
JPCERT/CCの「インシデント報告フォーム」（出典：JPCERT/CC インシデント報告）で改ざん・マルウェアサイト化を報告すると、攻撃者IPの共有や類似攻撃の警戒情報につながります。サイバー犯罪に該当する場合は、警察庁または各都道府県警察のサイバー犯罪相談窓口への相談も並行します。
Day 8〜30 復旧フェーズ
復旧は「直近の正常時バックアップからの復元」が基本ですが、バックアップ時点で既に改ざんされていた可能性を必ず確認します。日次バックアップだけで遡るのではなく、週次・月次のバックアップとファイル差分を突合せ、改ざんが入った推定タイミングより前の世代から復元します。復旧と同時に第1〜2層の全項目を強化（全パスワード変更／全管理者ユーザー棚卸し／全プラグイン・テーマ・コア更新／不要プラグイン削除）します。
Day 31〜90 再発防止フェーズ
再発防止は、根本原因の特定と運用ルールの改訂で構成します。「どの層から侵入されたか」を保全フェーズで取得したログから推定し、その層の運用ルールを改訂します。改訂内容を保守契約書に反映し、次回の更新リハーサルで動作検証する流れが、再発防止プロトコルの基本形です。
よくある質問
WordPressのセキュリティ対策で頻出する質問への回答を整理しました。
Q1：セキュリティプラグインは何本入れるべき？
2本以内に収めるのがおすすめです。機能重複が起きにくいラインで、中小企業案件の標準形はSiteGuard WP Plugin 1本＋サーバー側WAF＋サーバー側バックアップ、中〜大規模サイトはWordfence 1本＋サーバー側WAF＋Cloudflareの構成。プラグインを増やすほどPHPメモリ・更新運用・機能重複の管理コストが増えます。
Q2：ログインURLは変えるべき？
変えた方が攻撃の試行回数を桁単位で減らせます。ただし「ログインURL変更のみ」では、IDS／OSINTで発見されるため単独運用は避け、必ず「強パスワード＋2FA」と組み合わせます。ログインURL変更単独で安心して残りを放置した運用は、半年〜1年で別経路から侵入される傾向があります。
Q3：自動更新は有効化すべき？
セキュリティリリース（マイナー更新）は自動有効化が現実的です。WordPress 5.6以降はデフォルトで有効になっており、これを手動で切る理由はインシデントリスクと比較して薄いケースが多いです。メジャー更新は手動＋ステージング先行が基本。影響範囲が大きいプラグイン（フォーム・決済・キャッシュ系）は手動、それ以外は自動でも実務が回ります。
Q4：バックアップはサーバーの機能だけで十分？
「サーバー側バックアップのみ」は第3層として不完全です。サーバー全体が侵害された場合、サーバー内のバックアップも同時に侵害されるリスクが残るため、必ず「サーバー外への退避」を最低週次で組みます。中小企業案件であれば、UpdraftPlus等のプラグインでGoogle Drive／Dropboxへの週次退避でも実務が回ります。
Q5：インシデントが起きたら警察に通報すべき？
個人情報漏えいの可能性がある場合は、個人情報保護委員会への報告が必要になるケースがあります（個人情報保護法の規定）。サイバー犯罪に該当する不正アクセス／改ざんは、警察庁または各都道府県警察のサイバー犯罪相談窓口へ相談できます。JPCERT/CCへの報告は法的義務ではありませんが、攻撃情報の共有という観点で報告するケースが多いです。報告判断は契約上の責任分界点で発注側／受注側のどちらが行うかを契約書で事前に決めておくのが基本です。
Q6：制作会社に保守を委託するときのセキュリティ条項は？
保守委託契約書に「更新運用ルール（コア／プラグイン／テーマの頻度・基準）」「バックアップ運用（頻度・世代・保存先）」「インシデント発生時の通報体制（誰が・いつまでに）」「個人情報の取り扱い」「契約終了時のデータ引き渡し方法」の5項目を最低明記するのが標準ラインです。月額の見積もり差は、この5項目の運用ルールの粒度差で説明できるケースがほとんどです。発注時の費用観点は中小企業のホームページ制作費用（3年TCO）とホームページ保守費用の相場で整理しています。
まとめ：4層フレームと優先順位で動かすWordPressセキュリティ
最後にこの記事の要点を整理します。
- 対策はプラグイン本数ではなく、「①ログイン経路 → ②脆弱性管理 → ③バックアップ → ④WAF」の優先順位フレームを順序通りに固める
- 被害の大半は第1層・第2層で予防できる。順序を逆転させると効果が桁単位で落ちる
- プラグインは2本以内に収め、層ごとに役割を割り当てる
- 予防で止まらない事故に備え、サーバー外バックアップと90日復旧プロトコルを事前に用意する
- 年1回の棚卸しで廃れた施策が残っていないかを確認し、ルールを改訂する
運用ラインを動かす前提として、サーバー側のバックアップ世代管理とWAFが標準提供されているレンタルサーバーを選ぶことが、第3層・第4層の運用負荷を下げます。具体的なサーバー選びはWordPressに最適なレンタルサーバーおすすめとレンタルサーバー比較（用途別マトリクス）で整理しています。これからサイトを立ち上げる方は、全体の流れをWordPressの始め方で確認してから進めるとスムーズです。
次の一歩として、自サイトを4層フレームに当てはめ、最も薄い層から1つずつ実装することをおすすめします。
関連記事
免責事項
※本記事はWordPressのセキュリティ運用に関する公開情報と実務知見をもとにした整理です。法律相談・コンサルティングを目的としたものではありません。仕様・公的制度・各サービスの提供内容は変更される場合があるため、個別案件の判断は専門家（弁護士・社内法務・情報セキュリティ専門業者など）と各公式情報をご確認のうえご判断ください。
