ACT3

お問い合わせ
設計／運用

WordPressセキュリティ対策はどこまで必要？実務で考える3段階モデル

はじめに

WordPressのセキュリティについて調べると、「これをやらないと危険」「ここまでやって初めて安全」といった断定的な情報を多く見かけます。

しかし、実務の現場ではすべてのサイトに同じセキュリティ対策を適用することはありません。

セキュリティは技術論ではなく、想定リスク・運用体制・責任範囲をどう設計するかの問題だからです。

この記事では、実務で実際に想定しているリスクを整理した上で、WordPressサイトのセキュリティ対策を「3段階モデル」としてまとめます。

実務で想定している主なリスク

認証系攻撃（ブルートフォース）

  • wp-login.php / xmlrpc.php への総当たり
  • BOTによる自動化攻撃
  • 管理者アカウントの乗っ取り

発生頻度が高く、サイト規模に関係なく起こり得るリスクです。

プラグイン・テーマ経由の侵入

  • 更新されていないプラグイン
  • 開発停止テーマ
  • 既知・未知の脆弱性

実際の侵害原因として最も多く、運用ミスが直接リスクにつながるポイントです。

ファイル改ざん・マルウェア混入

  • PHPファイルへの不正コード埋め込み
  • JavaScript差し替え
  • SEO汚染・外部リダイレクト

検索結果や信用問題に直結し、クライアント側が最初に気づく被害になりやすいリスクです。

メールフォーム悪用・踏み台化

  • スパムメール送信
  • サーバーIPのブラックリスト化
  • 正常なメール不達

WordPress自体の問題ではなく、設計・設定不備が原因になるケースも多く見られます。

情報漏洩

  • 管理画面からの情報閲覧
  • REST APIによる想定外データ公開
  • 問い合わせ内容・個人情報の漏洩

発生頻度は高くありませんが、起きた場合のダメージが非常に大きいリスクです。

DDoS・大量アクセス

  • 大量リクエストによるサーバー負荷

個人・中小規模のサイトでは優先度は比較的低いと考えています。

セキュリティ対策の3段階モデル

レベル1：運用の基本（全案件で必須）

想定リスク

  • プラグイン起点の侵入
  • 初期的な改ざん
  • 運用ミスによる脆弱性

対策内容

  • WordPress本体・プラグイン・テーマの定期更新
  • 不要なプラグインの削除
  • 管理者権限の最小化
  • 推測されにくいID・パスワード
  • 定期バックアップ（復旧できることが前提）
  • サーバーWAFの有効化
  • xmlrpc.php の無効化

位置付け

  • セキュリティ以前に、運用の基本
  • これだけでは攻撃を防げないが、やらない理由がない最低ライン

想定コスト・工数（目安）

  • 初期設定：1〜2時間
  • 月次メンテナンス：30分〜1時間

レベル2：最低限の防御（ほぼ全案件で実施）

想定リスク

  • 認証系攻撃（ブルートフォース）
  • 管理画面の不正アクセス
  • フォーム悪用

対策内容

  • ログイン試行制限プラグイン（Login LockDown、Limit Login Attempts Reloaded等）
  • 管理画面URLの変更（自動攻撃の軽減目的、運用可能な場合のみ）
  • 管理画面へのIP制限（固定IPで運用可能な場合）
  • フォームのreCAPTCHA・送信制限
  • REST API の適切なアクセス制限・不要エンドポイント無効化
  • 専用WAF導入（Cloudflare等、必要に応じて）

判断基準

  • 管理者が固定IPで作業できる → IP制限を優先
  • 運用者が少ない → ログイン試行制限は必須
  • 問い合わせフォームがある → reCAPTCHA導入

位置付け

  • 実質的な最低ライン
  • レベル1だけでは侵入を防げない

想定コスト・工数（目安）

  • 初期設定：2〜4時間
  • 月次メンテナンス：1時間程度
  • IP制限設定時は運用者への説明が必要

レベル3：強化（限定的な案件のみ）

想定リスク

  • 情報漏洩
  • 被害範囲の拡大
  • 社会的信用の失墜

対策内容

  • 管理画面の分離（サブドメイン化、Headless CMS構成等）
  • 多要素認証（IP制限＋認証アプリ）
  • CMSとフロントの完全分離設計（Static Site Generator、JAMstack等）
  • CMSを別サーバー・非公開ネットワークに配置
  • ネットワーク・権限レベルでの分離

判断基準

  • 医療・教育・公共系
  • 個人情報を扱う
  • 長期保守前提
  • インフラまで管理できる体制がある

位置付け

  • 技術的には有効だが、多くの案件ではオーバースペック
  • 運用体制とクライアント理解が前提
  • WordPress標準構成ではなく、設計レベルでの対応が必要

想定コスト・工数（目安）

  • 初期設計・構築：20時間〜
  • 月次メンテナンス：2〜3時間
  • サーバー費用・保守費用が大幅に増加

用途別推奨レベル

サイトの用途は?
├─ 情報発信のみ（個人情報なし）
│   └─ レベル2（IP制限なしでも可）
│
├─ 問い合わせフォームあり
│   └─ レベル2（reCAPTCHA必須）
│
├─ 会員機能・決済あり
│   └─ レベル2〜3（決済機能がある場合はレベル3推奨）
│
└─ 医療・公共・教育系
    └─ レベル3検討

「やりすぎ」になるケース

  • 想定リスクに対して対策が過剰
  • 運用できない構成を組む
  • トラブル時に誰も触れない設計
  • クライアントが理解できない仕組み

セキュリティは守ることと同じくらい、復旧できることが重要です。

補足：大規模サイトでのWordPress採用事例

参考までに、アメリカのホワイトハウス（whitehouse.gov）など、大規模サイトでもWordPressがCMSとして採用されています。

ただし、内部構成や運用体制は公開されておらず、一般的な中小規模サイトとは前提が大きく異なります。

一般論として考えれば、こうした政府系・大規模サイトでは、セキュリティだけでなく 可用性（落ちないこと）を重視した冗長化構成が取られている可能性も高いと考えられます。

例えば、

  • 複数サーバーによる冗長構成
  • CDN やロードバランサーの利用
  • 障害発生時の自動切り替え

といった設計です。

もっとも、これらは内部を確認したわけではなく、あくまで一般的な推測に過ぎません。

重要なのは、この事例を「WordPressは安全」「この構成を真似すべき」と短絡的に捉えないことです。

こうした設計は、専門チーム・監視体制・即時対応を前提としたものであり、中小規模サイトでは運用が破綻するケースも少なくありません。

結論

WordPressのセキュリティに万能解はありません。

重要なのは、

  • 何が起こり得るかを理解し
  • どこまで守るかを決め
  • 運用できる形に落とすこと

実務では、最適なレベルを選ぶこと自体がセキュリティ対策だと考えています。

レベル1は運用の基本、レベル2が実質的な最低ライン、レベル3は限定的な案件のみ。この3段階を基準に、案件ごとに適切な対策を選択してください。

前の記事 技術情報一覧に戻る

他の技術情報

他の記事も合わせてご覧ください。