共有管理者を減らす
担当者ごとにアカウントを発行し、記事更新だけの人へ管理者権限を付けないようにします。退職者、制作時の検証用、使っていない連携アカウントを確認します。削除時には投稿の引継ぎ先と連携先を調べ、操作記録を残します。
認証を強くする順序
- 使い回しを避け、十分に長く固有のパスワードへ変更する。
- 管理者から2FAを導入し、予備手段と再設定担当を決める。
- ログイン試行を制御し、正規利用者の解除方法を用意する。
- 利用場所が限定されるならIP制限などを検討する。
- ログイン通知や操作ログで不自然な変更を確認する。
パスワード再発行先も保護する
再発行メールを受けるアカウントが侵害されると、WordPress側だけの保護では不足します。組織管理のメール、2FA、端末の管理も確認します。代表者個人の受信箱にしか復旧手段がない構成は、担当不在時に困ります。
URL変更・IP制限の注意点
URL変更は機械的な試行を減らす場合がありますが、脆弱性の修正ではありません。IP制限は回線変更やVPNで正規ユーザーを締め出すことがあるため、別経路の復旧を用意します。CDN配下では接続元IPの扱いも確認します。
APIや外部ツールの認証も確認する
通常ログインの2FAが、全てのAPI認証経路に同じ形で適用されるとは限りません。アプリケーションパスワードやXML-RPC、外部投稿ツールを棚卸しし、不要な資格情報を無効化します。利用する連携は、権限と更新の担当者を残します。
設定後の確認と見直し
別ブラウザーでログインし直し、再発行、2FA、解除手順、主要業務を検証します。管理者の交代やスマートフォン紛失を想定して手順を確認し、使えなくなる前に復旧経路を試してください。
担当者変更時の確認手順
退職・委託終了・部署異動の際は、アカウント、権限、再発行先、2FA、外部連携、操作記録を確認します。投稿を残す必要があれば引継ぎ先を指定し、契約者の個人メールへ復旧通知が残っていないか点検します。共通パスワードを変えるだけでは、個別発行したAPI資格情報が残る場合があります。作業終了後には、新しい担当者が自分のアカウントでログインし、必要な作業ができることを確認します。強すぎる権限を付けて確認を省くのではなく、実際の担当業務で試します。
不審なログイン通知を受けた場合
通知のリンクからすぐ認証情報を入力せず、正規の管理URLから状態を確認します。日時、アカウント、操作、セッション、接続元情報を照合します。侵害疑いがあればログを保全し、安全な端末から必要な資格情報の失効を進めます。
adminというユーザー名を変えれば十分ですか？
名前の推測されにくさだけでは認証は守れません。固有の強いパスワード、2FA、最小権限、試行制御、不要アカウントの整理を組み合わせます。
外部制作会社へ管理者を渡してもよいですか？
必要な作業、期間、承認を確認し、担当者別に付与します。完了後の失効や権限縮小、2FA、操作記録を含めて管理してください。