WordPress安心診断 by MozCheck

WordPressセキュリティ対策 完全ガイド｜初心者から中小企業まで守る実践チェックリスト

Written by

Yudai Tsuyuzaki

in

WordPress は世界で最も普及している CMS だからこそ、攻撃者にとって「自動化で狙いやすい標的」になりがちです。

アクセスが少ない個人ブログや小規模サイトでも例外ではありません。一般的な被害は、不正ログインによる管理画面乗っ取り、改ざんやマルウェア埋め込み、情報漏えい、スパム送信の踏み台化、検索評価の低下など。多くは「初期設定の甘さ」「更新の滞り」「運用ルール不備」という、少しの手当てで防げるポイントから始まります。

このガイドは、初心者から中小企業の担当者までが今日から実践できることに的を絞り、プラグイン任せにしない多層防御を最短ルートで整えることを目的にしています。まずは 30 分でできる初期強化で土台を固め、ログイン／認証の防御とサーバー／設定のハードニングで突破口をふさぎ、監視・バックアップで「起きてもすぐ戻せる」体制をつくります。最後に 日次／週次／月次で回せる実践チェックリストを用意し、運用を仕組み化します。

キーワードは 「最小権限」「常時更新」「可視化と検知」「復旧の即応」。やるべき順番と理由を明確にし、手順はできるだけシンプルに。今日の 30 分が、明日のインシデントを確率ごと下げます。

なぜWordPressのセキュリティ対策が必須なのか

WordPressが狙われやすい理由と主な被害例

WordPressは世界で最も利用されているCMSで、攻撃者はボットで脆弱なサイトを無差別にスキャンします。

狙われる主な理由は、

  1. 利用者が多く自動攻撃の効率が良い
  2. 古いプラグイン/テーマの脆弱性が放置されがち
  3. 既定のログインURLやIDの推測容易性です。

代表的な被害は次のとおりです。

    • 不正ログイン：管理権限を奪われ、設定改変・バックドア設置・ユーザー追加。
    • 改ざん・マルウェア埋め込み：広告の差し替え、フィッシングページ設置、SEOスパム。
    • 情報漏えい：問い合わせ情報や会員データの流出。
    • 踏み台化：あなたのサーバーからスパム送信、DDoS、他サイト攻撃に悪用。
    • 評価低下：検索結果での警告表示、インデックス除外、ブランド毀損。

    「うちはアクセスが少ないから大丈夫」は誤解です。ボットは流量に関係なく脆弱なサイトを機械的に狙います。

    まず押さえる優先順位（影響度×発生確率）

    影響度 × 発生確率で優先度を決めます。

    • 最優先（今すぐ）：
      強力パスワード／2FA／WordPress・プラグイン・テーマ更新／不要プラグイン削除／定期バックアップ
    • 高優先（本日中）：
      ログイン試行回数制限／reCAPTCHA／管理画面IP制限 or 基本認証／wp-config.php保護
    • 中優先（今週）：
      WAF/CDN／セキュリティヘッダー／権限棚卸し／XML-RPC制御
    • 継続（毎月）：
      復元テスト／脆弱性情報の確認／ログと改ざんスキャンの見直し

    まず30分でできる初期強化（クイックウィン）

    強力パスワード／不要ユーザー削除

    • 管理者IDを“admin”にしない。表示名（ニックネーム）も投稿者名と分ける。
    • パスワードは12文字以上＋大小英字・数字・記号。使い回し禁止。パスワードマネージャーを利用。
    • ユーザー一覧を棚卸し：不要アカウントは削除／権限を適正化（管理者は必要最小限）。
    • 投稿の所有者がある退職者アカウントは、寄稿者などへ移管後に削除。

    本体・プラグイン・テーマの更新と未使用削除

    • ダッシュボード → 更新 で本体・プラグイン・テーマを最新化。
    • 5.5以降は自動更新を有効化可能。常用プラグインは自動更新ON、互換性に注意が必要なものは手動更新＋検証。
    • 未使用プラグイン/テーマは停止ではなく削除。脆弱性の温床になります。
    • テーマは子テーマ運用が前提。デバッグや復旧のために公式のデフォルトテーマを1つだけ残す。

    二要素認証（2FA）導入とバックアップ初期設定

    • 2FAを管理者から順に必須化。TOTP（認証アプリ）を基本に、バックアップコードを安全保管。
    • バックアップは最低でも
      • 毎日：DB（投稿・設定）
      • 毎週：ファイル（wp-content など）
      • 保持：世代管理（例：14〜30世代）
      • 保管：オフサイト（同一サーバー内だけはNG）
    • 復元できないバックアップは無意味。テスト復元の手順を後述の運用で回します。

    ログイン／認証の防御

    試行回数制限とreCAPTCHAの併用

    • ログイン試行回数を制限（例：5回失敗で15分ロック、一定回数で長時間ロック）。
    • reCAPTCHA/画像認証をログイン・コメント・パスワードリセットに適用。
    • 失敗イベントをメール/Slackで通知し、IP単位でブロック。
    • 2FAと組み合わせて多層防御にします。

    管理画面へのIP制限・基本認証

    固定IPやVPNが使えるなら最強の対策。社外からの保守にはVPN経由で。

    Apache（.htaccess）例：

    # /wp-admin/ を許可IPのみに制限
<Directory "/var/www/html/wp-admin">
  Order deny,allow
  Deny from all
  Allow from 203.0.113.10
</Directory>

# /wp-login.php を基本認証で二重化（併せてIP制限も可）
<Files "wp-login.php">
  AuthType Basic
  AuthName "Restricted"
  AuthUserFile /path/to/.htpasswd
  Require valid-user
</Files>

    Nginx例：

    location /wp-admin/ {
  allow 203.0.113.10;
  deny all;
}

location = /wp-login.php {
  satisfy any;
  auth_basic "Restricted";
  auth_basic_user_file /etc/nginx/.htpasswd;
  include fastcgi_params;
  fastcgi_pass php-fpm:9000;
}

    ※ 共有サーバーではコントロールパネルのアクセス制限機能を活用。

    ログインURL変更・XML-RPCの制御

    • 既定の /wp-login.php からカスタムURLへ変更し、ボットの照会を減らします。
    • XML-RPCはリモート投稿や一部連携で必要ですが、使わないなら無効化。必要なときは特定メソッドやIPのみ許可。

    ApacheでXML-RPCを遮断：

    <Files "xmlrpc.php">
  Order Deny,Allow
  Deny from all
</Files>

    NginxでXML-RPCを遮断：

    location = /xmlrpc.php { return 403; }

    ※ Jetpackなど連携を使う場合は機能要件を確認し、完全遮断ではなくレート制限/WAFルールで対処します。

    サーバー／設定のハードニング

    WAF/CDNの導入と常時HTTPS（HSTS）

    • WAF（Webアプリケーションファイアウォール）でSQLi/XSS/ブルートフォースなどの典型攻撃を入口で遮断。併せてレート制限やボット対策を有効化。
    • 常時HTTPSを前提にHTTP→HTTPS 301リダイレクト。TLSは最新を優先し、古いプロトコル/暗号スイートは無効化。
    • HSTSを設定し、ブラウザ側で常にHTTPSを強制。プリロードは要件を満たすまで慎重に。

    Apache（HSTS/リダイレクト例）

    # HTTP→HTTPS
<VirtualHost *:80>
  ServerName example.com
  Redirect permanent / https://example.com/
</VirtualHost>

# HSTS（1年・サブドメイン含む）
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

    Nginx（HSTS/リダイレクト例）

    server {
  listen 80;
  server_name example.com;
  return 301 https://example.com$request_uri;
}

server {
  listen 443 ssl http2;
  server_name example.com;
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

    wp-config.php保護とパーミッション設計（644/755）

    • 可能ならwp-config.phpをWebルート外へ移動。難しい場合でも直接アクセスを拒否。
    • キー&ソルトをリフレッシュしてセッション無効化（侵害後は必須）。
    • ファイル/ディレクトリ権限の原則：ファイル 644、ディレクトリ 755、wp-config.phpは600や640などより厳格に。
    • テーマ/プラグインの編集機能を無効化し、管理画面からの改ざんリスクを低減。

    Apache（wp-config.phpへ直接アクセス禁止）

    <files wp-config.php>
  order allow,deny
  deny from all
</files>

    wp-config.php（編集機能無効化）

    define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', false); // 自動更新を止めたい場合はtrue（推奨は運用方針に合わせる）

    セキュリティヘッダー設定・編集機能無効化

    • X-Content-Type-Options: nosniff（MIMEスニッフィング防止）
    • X-Frame-Options: SAMEORIGIN または CSPのframe-ancestors
    • Referrer-Policy: no-referrer-when-downgrade（またはより厳格に）
    • Permissions-Policy（不要なAPIを明示的に無効化）
    • **CSP（Content-Security-Policy）**は段階導入：まずContent-Security-Policy-Report-Onlyでレポート確認→本番適用。

    Nginx（代表例）

    add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "no-referrer-when-downgrade" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
/* CSPはサイトに合わせて厳密に設計 */
# add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; object-src 'none'; frame-ancestors 'self'" always;

    監視とバックアップ・復旧

    改ざんスキャン・監査ログ・アラート設計

    • 改ざん検知：コア/テーマ/プラグインのファイル整合性チェックとマルウェアスキャンをスケジュール実行。
    • 監査ログ：ログイン成功/失敗、ユーザー作成、権限変更、プラグイン有効化/更新、テーマ切替などを永続保存。
    • 死活監視（Uptime）、APM/サーバーログ監視で応答遅延やエラー率の異常を検知。
    • 通知：重大イベントはメール/Slack/Teamsへ即時通知。しきい値（例：5分で500エラー連続n回）を定義。

    3-2-1バックアップと復元テスト

    • 3-2-1ルール：3世代以上・2種類の媒体・1つはオフサイト（クラウド/別リージョン）。
    • 頻度：DBは毎日、wp-content/は週1以上、高更新サイトは差分/増分で短縮。
    • 保持：14～30世代（業務要件に合わせて）。暗号化し、アクセス権限を分離。
    • テスト復元：ステージングで定期演習（最低月1）。RPO/RTO（許容データ損失/復旧時間）を実測し、計画を更新。

    インシデント初動とSEO回復フロー

    1. 隔離：管理者ログイン停止/パスワード即時変更、メンテナンスモードやWAFで一時遮断。
    2. 証跡保全：ディスク/ログのスナップショット取得。
    3. 原因特定→除去：改ざん箇所・バックドア・脆弱プラグインを特定しパッチ適用/削除。
    4. 安全復元：クリーンなバックアップからリストア→すべての秘密情報をローテーション（DBパス、SFTP、APIキー、WP salts）。
    5. 再開前検査：スキャン/外部診断/403・5xx監視。
    6. 公開後：キャッシュ/ CDNをパージ、Search Consoleで「セキュリティ問題」解消と再クロール依頼。必要なら利用者への周知/法令対応。

    実践チェックリスト

    日次／週次／月次の点検項目

    日次

    • ログイン失敗/ロックアウト件数の確認、怪しいIPの遮断
    • Uptime/5xxの有無、改ざんスキャン結果の差分確認
    • 重要プラグインの更新通知チェック

    週次

    • すべての更新（本体/プラグイン/テーマ）の適用と簡易回帰テスト
    • 監査ログの異常（新規管理者、プラグイン大量更新など）
    • WAF/レート制限のヒット状況レビュー

    月次

    • ユーザー権限棚卸し（不要アカウント削除、権限最小化）
    • バックアップのテスト復元（手順の鮮度確認）
    • セキュリティヘッダー/CSPの見直し、脆弱性情報（CVE/公式告知）の確認

    まとめ

    セキュリティは一度やって終わりではなく、優先度づけ→実装→監視→見直しのループで強くなります。

    とくに WordPress は利用者が多いぶん、既定値のまま・更新滞留・権限の甘さが狙われがちです。この記事で整理したように、最小権限・常時更新・多層防御・即時復旧の4本柱を揃えれば、被害確率も影響度も大きく下げられます。

    まずは30分でできる初期強化から始め、ログイン防御（2FA／試行回数制限／IP制限）、サーバー＆設定のハードニング（WAF／HTTPS／wp-config保護／パーミッション／セキュリティヘッダー）へ段階的に広げ、監視とバックアップで「起きてもすぐ戻せる」状態を標準化しましょう。運用は日次・週次・月次のチェックリストに落とし込むことで、属人化を防ぎつつ継続できます。

    迷ったら次の3ステップだけは今日終わらせてください。

    • 強力パスワード＋2FA導入、不要ユーザーの削除
    • 本体／プラグイン／テーマの更新と未使用の削除（自動更新の最適化）
    • DBは毎日・ファイルは週1以上のバックアップとテスト復元の実施

    この3つで土台は一気に堅くなります。あとは記録を残し、異常を早く察知し、復旧を訓練するだけ。小さな積み重ねが、インシデントを未然に防ぐ最大の武器になります。

    参考・参照リンク

    関連記事

    1. セキュリティ、後回しにしていませんか？あなたのWordPressを守る対策

    投稿者

    Yudai Tsuyuzaki

    フリーランスのWeb系プログラマー。 長野県の北アルプス地方在住

    🛠️ WordPressのトラブルでお困りですか？

    ログインが出来ない・白画面・更新崩れなどの緊急トラブルは、
    「WordPress保守サービス」で即対応いたします。

    今すぐ依頼する

    🧰 WordPress無料診断

    サイト改善の第一歩をお届け

    当サイト「MozCheck」は、WordPressサイトの不安をチェックできる無料診断サービスです。
    URLを入力するだけ。登録不要、すぐに診断結果が表示されます。

    無料で診断する

    コメント

    コメントを残す

    メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

    CAPTCHA


    More posts