WordPressのセキュリティ対策は、調べるほど項目が増えていきます。全部やろうとして手が止まった経験はないでしょうか。実際には、対策ごとに効果の大きさも手間も大きく違います。この記事では、対策を「効果 × 手間」の2軸で整理し、優先度の高いものから手順つきで説明します。あわせて、よく紹介されるものの効果が薄い対策と、やると運用に支障が出る設定も扱います。

なぜWordPressが狙われるのか

特定のサイトが狙われているのではなく、機械的に総当たりされているからです。

多くの攻撃は、脆弱性のあるサイトを自動で探し回るプログラムによるものです。「うちのような小さいサイトは狙われない」という前提は成り立ちません。攻撃側は相手を選んでおらず、条件に合致したサイトを順に処理しているだけです。

WordPressが対象になりやすい理由は2つあります。

1つは、利用サイト数が多いことです。同じ手法が多くのサイトに通用するため、攻撃プログラムを作る側にとって費用対効果が高くなります。

もう1つは、プラグインとテーマの存在です。WordPress本体は開発体制が整っていますが、プラグインは数万点あり、作者も保守状況もさまざまです。更新が止まったプラグインを使い続けていると、公表済みの脆弱性が放置された状態になります。攻撃側から見れば、本体を破るより、既知の穴が開いたプラグインを探すほうが簡単です。

つまり対策の中心は、本体そのものより プラグインとテーマの管理 に置くべきだということになります。

対策の優先順位

「効果が大きく、手間が小さい」ものから着手します。

セキュリティ対策は積み上げるほど強くなりますが、運用の手間も増えます。手間のかかる対策から始めると、続かずに形骸化します。

対策を効果と手間の2軸に置くと、次のようになります。

これを効果と手間の2軸で置き直すと、着手の順序が見えやすくなります。

1〜3は今日中に終わります。まずここまでを片付けてください。

今日やること（優先度1〜3）

更新を溜めない

管理画面の更新通知を放置しないことが、最も効果の大きい対策です。

脆弱性は、修正版のリリースと同時に内容が公表されるのが一般的です。この時点で、攻撃側も「どのバージョンに、どんな穴があるか」を知ることになります。つまり更新を放置している期間は、穴の場所が公開されたまま塞いでいない状態が続きます。攻撃が自動化されている以上、公表から実際に狙われるまでの猶予は長くありません。

手順は次のとおりです。

1. 管理画面 > ダッシュボード > 更新 を開く
2. 本体・プラグイン・テーマの更新をすべて適用する
3. 更新後、サイトの表示と主要な機能（フォーム送信、カートなど）を確認する

自動更新も設定できます。プラグイン一覧の「自動更新を有効化」から個別に指定できます。ただし、業務に直結する機能を担うプラグインは、自動更新にすると不具合に気づくのが遅れることがあります。カートや予約など、止まると売上に影響するものは手動更新にし、更新日を決めて運用するほうが安全です。

使っていないプラグイン・テーマを消す

停止しているだけでは不十分です。削除してください。

無効化されたプラグインでもファイルはサーバー上に残っており、ファイルに直接アクセスする形の攻撃が成立することがあります。使わないものは残さないのが確実です。

1. プラグイン一覧で、停止中のものを確認する
2. 今後使う予定がないものを削除する
3. 外観 > テーマ で、使用中のテーマ以外を削除する（デフォルトテーマ1つは残す）

デフォルトテーマを1つ残すのは、使用中テーマに問題が起きたときの切り分けに使うためです。

管理者アカウントを整理する

権限は、必要な人に、必要な分だけ渡します。

管理者権限を持つアカウントが多いほど、どこか1つが破られたときの被害が大きくなります。

1. ユーザー一覧を開き、管理者権限のアカウントを洗い出す
2. 退職者・取引終了した外部業者のアカウントを削除する
3. 記事を書くだけの人は「投稿者」または「編集者」に権限を下げる
4. admin というユーザー名を使っている場合は、別名の管理者を新規作成して権限を移し、admin を削除する

ユーザーを削除する際、そのユーザーが書いた記事の扱いを聞かれます。別ユーザーに引き継ぐ選択をしてください。削除を選ぶと記事も消えます。

バックアップと復旧の準備（優先度4）

対策をどれだけ積んでも、被害の可能性はゼロになりません。復旧できる状態を先に作ってください。

改ざんされたサイトを元に戻せるかどうかは、バックアップがあるかで決まります。そして、バックアップは「取れていること」より「戻せること」が重要です。

バックアップの考え方として、3-2-1ルールがあります。

• 3: データを3つ持つ（本番＋バックアップ2つ）
• 2: 2種類の媒体・場所に保存する
• 1: そのうち1つは別の場所に置く

同じサーバー内にだけバックアップを置いていると、サーバーごと問題が起きたときに一緒に失われます。外部ストレージへの保存を1つは用意してください。

WordPressのバックアップは、ファイルとデータベースの両方が必要です。どちらか一方だけでは復旧できません。記事本文や設定はデータベースに、画像やテーマはファイルに入っています。

そして、復旧手順を一度試してください。 バックアップから実際に復元できるかを確認していないサイトは珍しくありません。テスト環境に復元し、次の3点を確認しておきます。

1. ファイルとデータベースの両方が揃っているか
2. 復元後にサイトが正常に表示され、管理画面にログインできるか
3. 復旧にかかる時間（障害時に「何時間で戻せるか」を即答できる状態にする）

ログイン周りを固める（優先度5〜6）

ログイン試行の制限と二段階認証

WordPressの管理画面は既定で /wp-login.php にあり、場所は公開情報です。したがってパスワードだけが防御になります。

• ログイン試行回数の制限: 一定回数失敗したIPを一時的に遮断する
• 二段階認証: パスワードが漏れても、認証アプリのコードがなければ入れない状態にする

このうち効果が大きいのは二段階認証です。管理者権限のアカウントだけでも設定してください。

どちらもプラグインで設定します。導入手順は次のとおりです。

1. 認証アプリ方式（TOTP）に対応したセキュリティプラグインを1つ選ぶ
2. 管理者アカウントで有効化し、スマートフォンの認証アプリでQRコードを読み取る
3. リカバリーコードを発行し、管理画面の外に保管する
4. 一度ログアウトして、実際にログインできるか確認する
5. 他の管理者アカウントにも展開する

3を飛ばさないでください。スマートフォンを機種変更・紛失したときに、自分が管理画面へ入れなくなります。復旧手段を確保してから展開してください。

ログインURLの変更（/wp-login.php を別のパスにする）もよく紹介されますが、これは単体では防御になりません。攻撃を「見えにくくする」だけで、防いではいないためです。ログイン試行制限や二段階認証と組み合わせる前提で考えてください。

XML-RPCを無効化する

xmlrpc.php は外部アプリからWordPressを操作するための古い仕組みです。現在はREST APIが主流で、使っていないサイトが多くあります。

この機能には、1回のリクエストで多数のログイン試行をまとめて送れる仕様があり、総当たり攻撃を効率化するために使われることがあります。使っていないなら止めてください。

使っているかの確認方法: WordPressアプリからの投稿、Jetpackの一部機能、外部サービスからの自動投稿を使っている場合は稼働しています。心当たりがなければ、まず無効化して数日運用し、問題が出ないことを確認してください。

無効化の手段は2つあります。セキュリティプラグインの設定項目で切る方法と、.htaccess に記述して xmlrpc.php へのアクセスを拒否する方法です。プラグインを既に入れているなら前者で十分です。ただし .htaccess は、書き方を誤るとサイト全体が表示されなくなります。編集前に必ずバックアップを取り、サーバーの管理画面から元に戻せる状態にしてから作業してください。

情報の露出を減らす（優先度7）

ユーザー名は、外から取得できる状態になっていることがあります。

確認したい経路は2つです。いずれも設定やテーマによって挙動が変わるため、自分のサイトで実際に試してみてください。

• https://（サイトURL）/?author=1 にアクセスする … 投稿者アーカイブへ転送され、URLにユーザー名が出ることがあります
• https://（サイトURL）/wp-json/wp/v2/users にアクセスする … ユーザーの一覧がJSON形式で返ることがあります

前者が転送されず404になる、後者が空を返す、といった場合は既に塞がれています。

ユーザー名が分かると、攻撃側はパスワードだけを狙えばよくなります。二段階認証を設定していれば致命傷にはなりませんが、露出は減らしておくに越したことはありません。

対策はセキュリティプラグインの設定項目にまとまっていることが多く、個別に対応するより、まとめて設定できるものを使うほうが管理しやすくなります。

WAFの導入（優先度8）

効果は大きいものの、費用と運用の手間がかかります。優先度1〜7を終えてから検討してください。

WAF（Web Application Firewall）は、攻撃と判断される通信をサイトに届く前に遮断する仕組みです。個別の脆弱性を塞ぐのではなく、入口でまとめて止めます。

ただし、正常な通信を誤って遮断することがあります。管理画面での操作や、フォームの送信が止まるといった形で表面化します。導入したら、主要な機能が動くかを一通り確認してください。

費用をかけずに始めるなら、契約中のレンタルサーバーに付属のWAFがないかを確認してください。 多くの事業者が標準機能として提供しており、管理画面から有効化するだけで使えます。

効果が薄い対策・やらないほうがよい設定

よく紹介されるものの、期待するほど効果がない、あるいは運用に支障が出るものもあります。

パーミッションの777は、更新やアップロードのエラーが出たときに解決策として案内されることがありますが、原因を放置したまま権限を開けているだけです。サーバー会社に相談してください。

まとめ

• 攻撃は自動化されており、サイトの規模とは関係なく対象になります。「小さいから狙われない」という前提は成り立ちません
• 対策は「効果が大きく手間が小さい」ものから着手します。更新・不要なプラグインの削除・管理者アカウントの整理は今日中に終わります
• 対策を積んでも被害の可能性は残ります。バックアップは取るだけでなく、復旧できることを一度確認してください

自社サイトの現状が分からない、どこから手を付けるべきか判断がつかないという場合は、お問い合わせフォームよりご相談ください。