WordPress管理画面の乗っ取り対策｜2段階認証・権限・復旧を実務で解説

2026年10月26日

WordPressの管理画面を守るには、ログインURLを隠すだけでは足りません。最初に管理者アカウントを棚卸しし、全員に二段階認証を設定します。同時に復旧コードを保管し、使っていないアプリケーションパスワードを失効させ、ログイン試行の制限と更新・バックアップを運用に組み込むことが重要です。

この記事は、自己ホスト型WordPressサイトの担当者向けに、設定順序と確認方法をまとめたものです。WordPress.orgのアカウントに二段階認証を設定する手順とは異なります。画面名や使える認証方式は、利用中のプラグイン、WordPressの版、ホスティング環境によって変わります。作業前にバックアップと代替の管理者ログイン経路を確認してください。

結論：最初の30分は「誰が入れるか」「二段階認証は有効か」「外部連携用の認証情報が残っていないか」「異常なログイン試行はないか」を調べます。変更は一度に全員へ適用せず、テストアカウントで検証してから段階的に展開します。この記事の製品・仕様情報は2026年10月26日に公式資料を確認しました。

30分で行う初動点検

WordPress管理画面の最初の30分で確認する管理者・2段階認証・API連携・ログ

ログイン画面への大量アクセスがあった場合、まず攻撃の有無と実際の侵入を分けて考えます。失敗ログインの増加だけで「侵害された」と断定はできません。一方、知らない管理者アカウント、新しいアプリケーションパスワード、不審な投稿や設定変更があれば、単なる試行として片付けず、侵害対応へ切り替えます。

WordPress公式のブルートフォース攻撃対策は、管理者の二段階認証、強固で固有のパスワード、ログイン試行の制限、XML-RPCの要否確認、コア・テーマ・プラグインの更新を挙げています。ログインURLの変更は雑音を減らす可能性がありますが、主要な防御にはなりません。

時間の目安	担当者が見るもの	完了条件
最初の5分	管理者一覧、退職者・外注先のアカウント	所有者不明の管理者を洗い出す
次の10分	各管理者の二段階認証、復旧手段	未設定者とロックアウト時の連絡先が分かる
次の5分	プロフィール内のアプリケーションパスワード	用途不明・未使用の連携を記録する
最後の10分	WAF・ホストのログ、サイトヘルス、バックアップ	異常と更新対象、戻し方を記録する

この表は作業時間の保証ではなく、最初に見る順番です。ECサイト、会員サイト、複数の外部連携があるサイトでは、設定変更前の影響確認にもっと時間をかけます。作業記録には、確認日、担当者、対象サイト、変更前後、試験ログイン結果、切り戻し方法を残してください。

点検を始める前に用意する情報

作業を任された人は、サイトURLだけでなく、ホスティング管理画面の契約者、ドメイン管理者、既存のバックアップ先、ログインに使うSSOの有無を確認します。WordPressへ入れなくなったときに、どこへ連絡し、誰が本人確認に応じられるかが分からないまま認証設定を変えるのは危険です。特に制作会社が作ったサイトでは、サイト所有者と制作担当者の権限が混在していることがあります。最初に所有者を確定し、変更権限と承認経路を残します。

失敗ログインを判断する際は、同一IPからの試行だけでなく、複数の発信元から少しずつ試される可能性も考えます。ただし、アクセス元だけでは人間の利用者や攻撃者を確定できません。日時、対象ユーザー、成功・失敗、対象URL、実際の投稿・設定変更との時間的な関係を見てください。ロギング機能がない場合は、ホストやWAFの提供するログから確認できる範囲を記録し、将来どのログが必要かを決めます。ログには個人情報やIPアドレスが含まれる場合があるため、閲覧者と保存期間も定めます。

不審な操作が見つかった場合は通常の導入作業を止める

知らない管理者が増えた、身に覚えのない投稿が公開された、ファイルが改変されたなどの兆候がある場合は、単に二段階認証プラグインを追加して終えないでください。まず証拠となるログを保全し、正規の管理者とホスト事業者へ連絡し、影響範囲を調べます。WordPressで侵害を疑うときの初動手順も参照してください。被害が継続しているなら、公開停止や資格情報の失効を含む判断が必要です。

管理者権限を棚卸し

二段階認証より先に、誰がどの権限を持つかを確認します。WordPressの「ユーザー」から一覧を開き、管理者、編集者、投稿者、外部委託先のアカウントを分けます。管理者はプラグインや設定などサイト全体へ影響する操作ができるため、記事編集だけの担当者へ広く渡さないことが基本です。WordPress公式の権限表を基準にしてください。

退職者・契約終了者のアカウントは、いきなり削除しないでください。そのユーザーが作成した投稿の帰属、外部連携、作業中の予約投稿を確認し、必要な権限を別の担当者へ引き継ぎます。投稿の再割り当てや停止手順は、管理画面とプラグイン構成により異なります。変更後に公開記事が消えたり、連携処理が止まったりしないことを検証します。

確認項目	判断の目安	対応
管理者の数	業務上必要な人に限られているか	記事編集だけなら編集者等へ変更
共有アカウント	複数人が同じIDを使っていないか	個人別アカウントへ移行し、旧IDを停止
退職・契約終了	担当者と有効期限が明確か	引き継ぎ後に権限を削除・無効化
パスワード	固有の長いパスワードか	使い回しをやめ、管理ツールで保管
メールアドレス	本人が安全に受信できるか	共有受信箱や退職者宛を見直す

管理者を減らす前に、復旧責任者を決める

管理者が一人だけだと、その人の端末紛失時に運用が止まります。一方、管理者を増やしすぎると攻撃面が広がります。個人別の正規管理者を必要な人数に絞り、誰が復旧の承認者で、誰がホスティング契約を管理し、誰がバックアップを戻せるかを分けて記録します。緊急用アカウントを設ける場合も、常用せず、厳重な保管と利用記録を前提にします。

パスワードだけを変えても、攻撃者がログインしたセッションや外部連携用の認証情報が残る可能性があります。侵害の疑いがあるときは、権限・セッション・アプリケーションパスワード・ホスト側の認証情報まで確認する必要があります。通常の棚卸しとインシデント対応を混同しないでください。

小規模サイトでの権限の分け方

例えば、社内にサイト責任者1人、記事を更新する担当者2人、月1回保守する外部パートナー1社がいるとします。責任者が管理者、記事担当者が編集者または業務に足りる権限、外部パートナーは作業時だけ必要な権限という設計を検討します。実際にどの操作が必要かは、プラグインが追加した権限にも左右されるため、役割名だけで決めずテストアカウントで確認します。作業が終わったら外部パートナーの継続アクセスが必要か再判断します。この例は運用設計の例であり、すべての会社にそのまま適用する設定ではありません。

「記事を公開できない」「画像をアップロードできない」といった問い合わせが出ても、安易に管理者へ昇格しないでください。必要な操作を特定し、現行のロールで可能か、承認フローを変えるべきかを確認します。管理者権限を付与すると、投稿以外の設定変更やユーザー操作まで可能になる場合があります。権限変更の前後には、作業に必要な機能と不要な機能の双方を試験し、実施者・承認者・期限を記録します。

2段階認証を導入する

WordPress管理画面へ2段階認証を導入し別端末で確認して管理者に展開する流れ

WordPressのコアには、自己ホスト型サイトの管理者向け二段階認証が標準で含まれていません。プラグイン、または利用中のIDプロバイダーを使って導入します。WordPress公式ガイドは、管理者全員への適用を勧めています。プラグインの入手元、更新状況、互換性、復旧手段、ロール別強制の有無を選定基準にしてください。

設定例として、WordPress.orgに掲載される「Two Factor」は、ユーザーごとにプロフィール画面から認証アプリ、メールコード、バックアップコードなどを設定します。このプラグインでは各ユーザーの個別設定が必要です。「プラグインを有効化しただけで全管理者が保護された」と判断してはいけません。組織全体へ設定を強制したい場合は、ロール別の強制機能を持つWP 2FAなどの公式説明と、現在の版・プランの機能を確認します。複数の2FAプラグインを同時に動かす前には競合テストが必要です。

安全な導入順序

事前確認：WordPress、PHP、ログイン方式、SSO、会員プラグイン、バックアップの動作を記録します。ホスティング側で二段階認証を提供している場合は、どのログインに適用されるか分けて確認します。
テスト：本番に近い検証環境でプラグインを導入します。管理者1人で認証アプリを登録し、復旧コードを別の安全な場所へ保存します。
再ログイン：シークレットウィンドウや別端末で、パスワード入力後に二段階目が要求されることを確認します。現在のログイン状態だけで成功と判断しません。
段階展開：他の管理者に期限と手順を伝え、個人別に登録してもらいます。設定済み人数と未設定人数を記録します。強制ポリシーが必要なら、復旧手順と連絡先を整えた後に有効化します。
検収：PC・スマートフォン・必要なSSOや会員導線で、正規ユーザーが入れることを確認します。不具合が出たら対象アカウントと導入変更を特定し、用意した手順で切り戻します。

認証アプリの時刻が大きくずれると、時間に基づくワンタイムコードが通らないことがあります。端末の自動時刻設定を確認し、連続して失敗する場合は無理に何度も試さず復旧手段を使います。認証アプリの画面、QRコード、シークレットキー、復旧コードをサポート窓口やチャットへ貼り付けてはいけません。

プラグイン選定時の確認表

選定条件	確認する質問	判断を保留する例
互換性	現在のWordPress・PHP・会員機能と動くか	検証環境でログイン不能になる
強制ポリシー	管理者全員へ期限付きで適用できるか	有効化だけで全員に効くと思い込む
復旧	予備コード、複数方式、管理者による救済はあるか	コードの保管・再発行方法が不明
更新	公式ページで対応版、更新履歴、サポートを確認したか	長期未更新や対応版が不明
監査	誰が登録済みか、失敗・解除を把握できるか	未設定者が特定できない

比較表は一つの製品を推奨する順位表ではありません。先にサイトの条件を定め、その条件に合う製品の公式情報を確認します。メールコードしか使えない担当者がいる場合は、メールの保護状況や端末の利用条件も確認します。管理者と一般会員で同じ認証ルールにすると、会員の離脱や問い合わせ増加につながることがあるため、対象ロールを分けて段階的に適用してください。

パスキーとの違い

パスキーは、対応するプラグインや認証基盤で利用する別のログイン方式です。フィッシング耐性などの利点がありますが、WordPressのどのサイトでも自動で使えるわけではありません。対応ブラウザ・端末、管理者ごとの登録、予備の認証器、失くしたときの手順まで確認します。記事では「パスキーがあれば更新や権限整理は不要」とは扱いません。認証を強くしても、脆弱なプラグインや過大な権限は別に管理する必要があります。

復旧コードと機種変更

二段階認証の導入で最も避けたいのは、管理者が正規の端末を失った際にサイトへ入れなくなることです。導入時に発行した復旧コードは、認証アプリや同じスマートフォン内だけに保存しないでください。パスワードとは別の、アクセス制御された保管場所へ置きます。利用できる回数や再発行方法はプラグインごとに異なるため、使っている製品の画面・公式説明を確認します。

場面	最初の確認	次の行動
機種変更前	旧端末でログインでき、復旧コードがある	新端末を登録し、別ブラウザで試験後に旧端末を解除
端末紛失	復旧コード・別の登録済み方式がある	正規の復旧手順で入り、失った方式を無効化
復旧コードもない	別の管理者・ホスト契約者に連絡できる	本人確認を経て製品公式の回復手順を実施
侵害の疑い	ログイン履歴と設定変更を保存できる	証拠保全と影響調査を先に行い、認証情報を失効

ログインできないからといって、確認なしにプラグインのファイルを消したり、全ユーザーの二段階認証を解除したりしないでください。他の管理者の保護まで失われます。どのアカウントが影響を受けているか、正規のバックアップ方式が残っているか、ホストや制作会社が回復を支援できるかを先に確認します。

復旧後は「入れた」で終わりません。使った復旧コードの再発行、紛失端末の認証登録解除、パスワードとメール受信先の確認、ログイン履歴の調査、作業記録の更新まで行います。コードの保管場所へアクセスできる人も見直します。年に一度などの固定間隔だけでなく、担当変更、端末変更、契約終了のタイミングを見直しの契機にします。

復旧訓練で確認すること

本番の管理者全員を同時にロックアウトする訓練はしません。検証環境または影響を限定したテストアカウントを使い、復旧コードで入れるか、使ったコードを再使用できないか、新しいコードを発行できるかを確認します。結果はスクリーンショットに秘密のコードを残さず記録します。「復旧担当が不在でも、代替担当が手順書と保管庫へアクセスし、所定の承認を経て復旧できる」状態を完了条件にします。

保管庫へコードを入れるときは、誰でも閲覧できる共有フォルダやメール本文ではなく、アクセス制御と履歴を備えた保管方法を選びます。印刷して保管する場合は施錠、持ち出し、廃棄のルールまで決めます。予備コードを複数人で同じテキストファイルとして持つ運用は、複製先の管理が難しくなります。緊急時に素早く使えることと、普段は不用意に見られないことの両方を満たす方法が必要です。

なお、PHP更新後にセッションが維持できない、ログイン後に戻されるなどの問題は、二段階認証とは別の原因の可能性があります。PHP更新後のWordPressログイン障害と切り分けてください。

API連携の認証を点検

人がブラウザで管理画面へ入る認証と、ツールがREST APIへ接続する認証は分けて管理します。WordPressのアプリケーションパスワードは、プログラムや外部アプリのための個別に失効できる認証情報です。管理画面の通常のログインフォームに入力するものではありません。二段階認証を人間のログインに導入しても、既存の外部連携の認証情報まで自動で整理されたとは考えないでください。

各ユーザーのプロフィールにある「アプリケーションパスワード」を開き、名前、作成日、最終利用情報、用途、所有者を照合します。機能が表示されない場合は、HTTPSの状態、権限、プラグインやカスタムコードによる制限を確認します。用途不明の項目を見つけたときは、直ちに削除すると投稿やバックアップの自動処理が止まる可能性があります。連携元を特定し、切り替え手順と試験方法を決めてから失効させます。ただし、不正利用が疑われる場合は、被害拡大の停止を優先します。

アプリケーションパスワードは「その文字列だけに閲覧権限を付ける」仕組みではありません。紐づくWordPressユーザーの権限で利用されるため、必要のない管理者ユーザーに外部連携を集中させないことが重要です。例えば記事の下書きを作る連携なら、実際に必要な権限を確認して専用ユーザーを設計します。APIのアクセス制御を確認せず「2FAを入れたからAPIも安全」と結論づけないでください。

XML-RPCは「未使用なら止める、使用中なら制限する」

WordPress公式は、XML-RPCを使っていないなら無効化を検討し、必要な場合はWAFなどで制限・レート制限するよう案内しています。ただし、モバイルアプリ、連携サービス、古い投稿ツールなどが利用している可能性があります。通信ログと連携一覧を確認せず、全サイト共通の設定を一括投入しないでください。REST APIまでまとめて停止する設定も、現在の編集・連携機能へ影響する場合があります。

外部連携の棚卸し表には「連携名／目的／所有者／使用ユーザー／必要権限／最終確認日／停止時の影響／失効方法」を残します。担当者が辞めたときやベンダー契約が終わったときに、どの認証情報を止めるべきかすぐ分かる状態が目標です。

アプリケーションパスワードを安全に入れ替える例

例えば記事を自動で下書き保存するツールが、個人の管理者アカウントに紐づく古いアプリケーションパスワードを使っているとします。まず連携元、実行頻度、必要なAPI操作、失敗時の通知先を確認します。次に用途に合う権限の専用ユーザーを用意し、新しい認証情報を連携先の安全な設定画面に登録します。テスト投稿が正しく下書きとなり、意図しない公開やユーザー編集ができないことを確認した後、旧パスワードを失効します。最後に、旧認証情報で接続できないことと、新連携の定期実行が続くことを確認します。

この手順は「古い鍵を先に消す」より作業が多いですが、連携の停止時間と原因不明の障害を減らせます。もし旧パスワードの漏えいが疑われるなら順序は変わります。被害を止めるため直ちに失効し、連携が止まることを関係者へ通知し、ログと実行結果を調べます。通常の鍵交換と侵害対応では優先順位が違います。

攻撃を抑える月次運用

二段階認証は強い防御ですが、ログイン試行を大量に送られてサーバー負荷が上がる問題を単独では解決しません。WordPress公式は、ホスティング事業者やCDNのWAF、またはWebサーバー側でのレート制限を優先して検討するよう案内しています。アプリケーション内のプラグインだけで遮断する方式では、攻撃リクエストごとにPHP処理が動くことがあります。設定は運用環境と契約プランに合わせて選びます。

WAFを厳しくしすぎると、正規の管理者、リモート編集、API連携まで止まります。まずログから対象URL、時刻、発信元、正規ユーザーの利用時間を確認し、検証環境または短い監視期間で試します。ログインURLを変更するだけ、国単位で広く遮断するだけ、といった対策に依存しないでください。緊急時の解除権限と連絡先を事前に決めます。

頻度	担当	点検内容	完了の証拠
毎週	運用担当	WordPress・テーマ・プラグインの更新通知、異常ログ	更新記録と異常時のチケット
毎月	サイト責任者	管理者・2FA・アプリパス・外部委託先	署名済みの棚卸し表
更新前後	技術担当	バックアップ、検証、フォーム・ログイン・決済等の重要導線	復旧可能なバックアップと動作確認結果
担当変更時	責任者と技術担当	権限引き継ぎ、端末・復旧コード、外部連携の失効	旧担当のアクセス停止と新担当の試験ログイン

WordPressの「ツール → サイトヘルス」は、更新や環境の注意点を確認する入口になります。ただし、サイトヘルスが良好でも二段階認証の未設定や、所有者不明の管理者がすべて検出されるわけではありません。公式のサイトヘルス説明を参照し、アカウントの棚卸しと併用してください。PHP自体の脆弱性対応は別の点検項目です。PHP2ShellへのWordPress運営者向け対応も必要に応じて確認します。

更新とバックアップは「復元できるか」まで見る

自動バックアップの成功通知だけでは、元に戻せるとは言えません。バックアップにデータベース、アップロード画像、プラグイン設定など必要な範囲が含まれるかを確認し、別環境での復元を定期的に試します。更新前には変更対象と互換性、作業時間帯、担当者、連絡先を決めます。更新後はトップページだけでなく、管理者ログイン、問い合わせフォーム、会員ログイン、購入や予約の導線など、そのサイトで重要な機能を試します。

更新で問題が出た場合に、古い脆弱な版へ無期限に戻すのは解決ではありません。必要なら一時的に安全な状態へ切り戻し、原因を確認し、代替プラグインへの変更や修正版への再更新を期限付きで計画します。脆弱性が公表された場合は、提供元の修正状況と自分のサイトで実際に動いている版を照合します。運用報告には「修正済み」「暫定策中」「未確認」を分けて書き、確認できていない状態を対策済みと呼ばないでください。

よくある質問

二段階認証を入れると、パスワードは不要になりますか？

通常の二段階認証では、パスワードも必要です。パスキーなどパスワードレスの方式は別の実装です。サイトで実際に何を要求するかを、別端末からの再ログインで確認してください。

メールコードと認証アプリは同じ強さですか？

同じではありません。メールアカウントへの侵入や配信遅延が認証へ影響します。利用できる方式、担当者の端末、復旧手段を考え、管理者には認証アプリなどを優先して検討します。方式を問わず、メール自体の保護も必要です。

ログインURLを変えれば攻撃を防げますか？

いいえ。URLの変更で機械的なアクセスが減る可能性はありますが、WordPress公式も単独の防御策として扱っていません。2FA、強い固有パスワード、権限最小化、WAF、更新を組み合わせます。

2FA設定後、投稿ツールが動かなくなりました。何を見ますか？

そのツールがブラウザのログイン、REST APIのアプリケーションパスワード、XML-RPC、SSOのどれを使うか確認します。アプリケーションパスワードは管理画面ログイン用ではありません。連携の認証方式と権限、変更前後のログを比べ、必要ならベンダーの公式手順で再接続します。

復旧コードが見つからず、管理者全員が入れません。

むやみにプラグインを削除せず、ホスト契約者・制作会社・プラグイン提供元へ、サイトの所有者確認ができる情報とともに連絡してください。事前に確保したバックアップ・代替管理者経路があるか調べます。不正ログインの疑いもあるなら証拠を保全します。

管理者だけ2FAを必須にして、一般会員は対象外にできますか？

利用する認証プラグインやID基盤にロール別の適用機能があれば可能です。ただし無料版と有料版、現行版と旧版で機能が異なることがあります。製品の公式ページで現在の仕様を確認し、管理者・編集者・一般会員の各テストアカウントで、設定前後のログインと復旧を試してください。記事にある「Two Factor」は各ユーザーの個別設定が必要なので、導入しただけで全員に強制されたとは見なせません。

アクセスログに失敗ログインが多いとき、全て攻撃ですか？

正規ユーザーのパスワード忘れや、古い外部連携の再試行も含まれます。成功したログインの有無、試行されたユーザー名、時間帯、アクセス元、WAFの判定、同時期の設定変更を合わせて確認します。ログが短期間で消える環境なら、必要な範囲だけ証拠を保全します。攻撃と確定できない段階で個人を名指しせず、まずは試行を抑え、正規利用者への影響を調べます。

管理者に2FAを入れたら、PHPやプラグインの更新は後回しでよいですか？

いいえ。ログイン認証の強化と、ソフトウェアの脆弱性修正は別の防御です。認証を迂回できる問題や、ログインせずに悪用できる問題もあり得ます。提供元の更新情報を確認し、検証・バックアップ・更新後テストを計画してください。対応できない版を使い続ける場合は、事業者が提供する暫定策と移行期限を確認します。2FAだけを「サイト全体が安全になった」証拠にはしません。

この後の行動：今日は管理者一覧と2FA設定状況を記録し、未設定の管理者1人で復旧まで試します。次に全管理者へ展開し、API連携と月次点検を運用表へ移してください。記事を読み終えた時点で、責任者・対象者・期限・完了条件が明確になっていれば、最初の一歩は完了です。