WordPressのログインを守る基本は、使い回さない長いパスワード、二要素認証、不要な管理者アカウントの整理です。ログインURLの変更や試行回数の制限は、それを補う対策になります。

通常のWordPressでは、二要素認証は対応プラグインや外部認証サービスなどで追加します。導入前に保守担当へ既存機能との重複を確認し、ログインできる予備の手段を残して試すと安心です。URLを変えるだけでは、漏れたパスワードによる侵入は防げません。

記事を書く人に、すべての管理権限は必要ない

管理者一覧を開き、現在の担当者・制作会社・退職者を照合します。用途不明のアカウントを見つけたら、いきなり削除せず作成時期と投稿の所有を確認します。必要な記事を現担当者へ引き継いだ後、不要な入口を停止します。

一つのadminを複数人で共有すると、誰の操作か追えません。担当者ごとのアカウントを作り、日常業務には編集者など必要な役割だけを割り当てます。プラグイン追加や利用者管理を行う人だけに管理者権限を残します。

表示名をログイン名と違うものにしても、それだけで認証は強くなりません。利用者名が推測される前提で、パスワードと追加要素を守ります。最終ログインや操作履歴を確認できる環境では、不使用アカウントを見つける材料にします。

固有の長いパスワードと二要素認証を組み合わせる

パスワードは他サービスと使い回さず、会社で認めたパスワード管理ツールで生成・保存します。NISTの認証指針は、既知または侵害済みのパスワードを拒否し、パスワード管理ツールと貼り付けを許可するよう求めています。記号の置換パターンだけを複雑さと考えません。

WordPress公式のセキュリティ資料も、強いパスワードに加えて二段階認証を勧めています。対応するならパスキーやセキュリティキーなど、フィッシング耐性のある方式を優先します。認証アプリの手入力コードもパスワードだけより防御を増やしますが、偽画面へ入力したコードを中継される可能性は残ります。

管理者の一人だけに二要素認証を付けても、ほかの管理者がパスワードだけなら、その入口のリスクは残ります。回復コードをパスワードと同じ場所へ保存せず、会社管理の保管先へ置きます。通常ログインと回復手順を試してから、古い端末や旧担当者の認証を解除します。

ログイン試行を遅らせ異常を通知する

長いパスワードでも、無制限に試せる入口は放置しません。NISTはオンライン推測攻撃へのレート制限を求めています。WordPressではサーバー・WAF・セキュリティ機能のどこで制限するかを決め、同じ機能を重ねて正規利用者を締め出さないようにします。

IPアドレス一つを永久遮断するだけでは、分散した攻撃や共有回線へ対応できません。アカウントごとの失敗回数、待機時間、送信元の変化を組み合わせます。解除手段を攻撃者が悪用できないよう、回復メールのアカウントにも二要素認証を設定します。

失敗試行の急増、管理者の追加、未知の端末からの成功ログインを通知対象にします。通知が多すぎると見なくなるため、正常な失敗と対応が必要な変化を分けます。ログにはIPや利用者情報が含まれるので、閲覧権限と保管期間も制限します。

URL変更や追加認証は補助策として扱う

ログインURLの変更は、既定URLだけを巡回するボットを減らす効果が見込めます。しかし新URLがリンクやログから判明すれば、パスワード攻撃は再開できます。URL変更を強い認証の代わりにせず、担当者と回復手順を記録します。

wp-adminへサーバー側の追加認証を置く方法もあります。WordPress公式資料は第二層になり得る一方、admin-ajax.phpなどを使う機能が壊れる場合を示しています。公開フォームやプラグインの通信を含め、保護対象と例外を確認します。

XML-RPC・REST API・アプリケーションパスワードなど、ログイン画面以外の認証経路を使う連携もあります。画面URLを変えてもこれらは別に残ります。使っていない連携の資格情報は解除できます。ただし、利用中の投稿アプリなどまで止めないよう、何に使っている認証かを先に確かめます。

更新と端末管理をログイン防御へ含める

ログイン画面を守っても、古いプラグインの脆弱性から管理者権限を得られる場合があります。WordPress本体・テーマ・プラグインを公式情報に基づいて更新し、使っていないものは停止だけでなく削除を検討します。更新前のバックアップと検証は別記事の手順に沿います。

管理に使うパソコンがマルウェアへ感染すれば、入力した認証情報やログイン済みセッションを奪われる可能性があります。OSとブラウザーを更新し、不特定の人が使うパソコンでは管理作業を避けます。公共Wi-Fiを使う場合も、正しいHTTPS接続であることが前提です。証明書警告を無視しないでください。退職や端末紛失時には、アカウントだけでなくセッションと認証器も無効にします。

HTTPSはログイン通信を保護する前提です。証明書警告を無視して管理画面へ入らず、正しいホスト名と有効な証明書を確認します。サイトのURL設定と転送が不安定な状態でログイン対策を重ねると、回復経路まで失うことがあります。

導入後は正常系と回復系を別々に試す

対策は一度にすべて有効にしません。予備の管理者セッションを安全に確保し、一層ずつ反映します。通常ログイン、パスワード再設定、二要素認証の回復を別のブラウザーで試します。

公開フォーム・予約機能・管理Ajax・外部アプリも確認します。正規利用者の失敗が増えた場合は、制限を外す前にどの層で拒否されたかをログから調べます。対策全体を無効にするのではなく、誤判定の条件だけを調整します。

失敗したログインの記録があるだけで、侵入されたとは限りません。対策後もボットの試行は残ることがあります。身に覚えのない成功ログインや管理者追加は別に扱い、保守担当へ早めに相談する方が良いです。