WordPress にゼロトラストを適用するとは、「社内ネットワークから来たから」「ログイン済みだから」という理由で信用せず、管理画面・API・サーバーへのアクセスごとに本人確認と権限の確認を行う設計にすることです。具体的には、強い認証、管理画面の前段での認証、最小権限、API 用の資格情報の分離、操作の記録の 5 つを組み合わせます。この記事では、それぞれを WordPress でどう実装するか、どこでつまずきやすいかを順に説明します。
ゼロトラストの考え方を WordPress に当てはめる
従来の守り方は「境界防御」と呼ばれ、ファイアウォールの内側や VPN 接続中の端末を信頼済みとして扱います。しかし WordPress の管理画面はインターネットに公開された URL で、外注先や在宅の担当者がさまざまな回線から使います。境界の内側という前提がもともと成り立ちにくい仕組みです。
ゼロトラストは、次の原則で設計します。
- 常に検証する：アクセスのたびに、誰が・どの端末から・何をしようとしているかを確かめる
- 最小権限：必要な操作だけを許可し、権限は必要な期間だけ与える
- 侵害を前提にする：どこかが破られても被害が広がらないよう分け、記録から追跡できるようにする
WordPress に置き換えると、守る対象は大きく「管理画面（/wp-admin/ と wp-login.php）」「API（REST API・XML-RPC）」「サーバー（SSH・データベース・ファイル）」の 3 つです。以下、この順に対策を見ていきます。
本人確認を強くする
ゼロトラストの土台は、パスワードだけに頼らない本人確認です。
管理者と編集者には二要素認証を必須にする
二要素認証（2FA）は、Two Factor、Wordfence、WP 2FA などのプラグインで導入できます。大切なのは「使えるようにする」だけでなく、管理者・編集者のロールでは有効化を必須にすることです。任意のままだと、設定していないアカウントが最も弱い入口として残ります。プラグインによってはロール単位で強制する設定があります。
組織で使うなら IdP にまとめる
社員が多い組織では、Google Workspace や Microsoft Entra ID などの IdP（ID プロバイダー）に WordPress のログインをまとめる方法があります。SAML や OpenID Connect に対応したシングルサインオン用プラグインを使うと、退職者のアカウント停止や多要素認証の強制を IdP 側で一括管理できます。WordPress 側にローカルの管理者パスワードを残す場合は、緊急用の 1 アカウントに限り、普段は使わないようにします。
管理画面の前段で認証する
WordPress のログイン画面に届く前に、もう一段の認証を置くのがゼロトラストらしい構成です。代表的なのは、Cloudflare Zero Trust の Access のような「アイデンティティ認識型プロキシ」を管理画面の URL の前に置く方法です。利用者は IdP やメールのワンタイムコードで認証してから、はじめて WordPress のログイン画面にたどり着きます。料金体系は少人数なら無料枠で始められる場合がありますが、条件は変わるため公式サイトで確認してください（2026年10月現在）。
設定で気をつける点は次のとおりです。
- 保護するパス：
/wp-admin/と/wp-login.phpを対象にします。 - **
admin-ajax.phpを外す**：/wp-admin/admin-ajax.phpは、問い合わせフォームや「もっと見る」ボタンなど、一般の訪問者向けの機能からも呼ばれます。ここまで保護すると表側の機能が動かなくなるため、このパスは保護対象から除外します。 - オリジンへの直接アクセスを塞ぐ：プロキシを経由せずにサーバーの IP アドレスへ直接アクセスされると、前段の認証は迂回されます。Cloudflare Tunnel のように外向きの接続だけでつなぐ方式にするか、ファイアウォールでプロキシ事業者の IP 範囲以外からの 80/443 番ポートを拒否してください。
前段の認証が使えない環境では、管理画面への IP 制限や Basic 認証でも「WordPress のログイン画面に誰でも届く」状態は避けられます。ただし IP 制限は「その回線にいる人は信頼する」という境界型の発想なので、2FA と組み合わせて使います。
権限を最小にする
ロールを見直す
「とりあえず管理者」で作られたアカウントは、ゼロトラストの観点では最も大きなリスクです。「ユーザー → ユーザー一覧」でロールごとの人数を確認し、記事を書くだけの人は投稿者、他人の記事も直す人は編集者に下げます。管理者は、プラグインの導入やサイト設定を担当する少人数に絞ります。使われていないアカウントは、投稿を別のユーザーに引き継いでから削除します。
管理画面からのコード変更を止める
管理者アカウントが乗っ取られた場合に、管理画面からテーマやプラグインのファイルを書き換えられると被害が大きくなります。wp-config.php に次の定数を追加すると、テーマ・プラグインのファイルエディターを無効にできます。
// テーマ・プラグインのファイルエディターを無効にする
define( 'DISALLOW_FILE_EDIT', true );
// プラグイン・テーマの追加と更新も管理画面から行わせない場合（更新は WP-CLI やデプロイで行う運用向け）
// define( 'DISALLOW_FILE_MODS', true );DISALLOW_FILE_MODS を有効にすると、管理画面からのプラグイン更新もできなくなります。更新を WP-CLI や CI で行う体制がない場合は、更新が止まって逆に危険になるので、DISALLOW_FILE_EDIT だけにとどめてください。wp-config.php を編集する前には、ファイルのバックアップを取っておきます。
API の資格情報を分ける
外部サービスや自動化ツールから REST API を使う場合は、人のログインパスワードを渡さず、WordPress 5.6 で追加された「アプリケーションパスワード」を使います。ユーザーのプロフィール画面で、連携先ごとに名前を付けて発行し、不要になったものは個別に取り消せます。
さらに、連携用には専用のユーザーを作り、必要最小限のロールを与えます。たとえば記事を投稿するだけの連携なら、投稿者ロールの専用ユーザーで十分です。アプリケーションパスワードを発行できるユーザーを絞りたい場合は、次のフィルターが使えます。
// アプリケーションパスワードを「api-」で始まるユーザー名の連携専用アカウントだけに許可する
add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
if ( ! $user instanceof WP_User ) {
return false;
}
return $available && 0 === strpos( $user->user_login, 'api-' );
}, 10, 2 );XML-RPC を使っていない場合は、無効にして入口を減らします。Jetpack や一部のスマートフォンアプリは XML-RPC を使うので、無効化の前に依存しているものがないか確認してください。
サーバー側も「信頼しない」構成にする
WordPress 本体を固めても、サーバーへの経路が甘いと意味がありません。
- SSH：パスワード認証を止めて公開鍵認証にし、root での直接ログインを禁止します。担当者ごとに鍵を分けておくと、退職時に 1 人分だけ無効化できます。
- データベース：MySQL のポートは外部に公開せず、WordPress からはローカルまたはプライベートネットワーク経由で接続します。WordPress 用の DB ユーザーには、そのデータベースだけの権限を与えます。
- ファイル：Web サーバーの実行ユーザーが書き込めるのは、原則として
wp-content/uploadsなどの必要な場所だけにします。
記録して検証し続ける
ゼロトラストは一度設定して終わりではなく、「本当に想定どおりのアクセスだけか」を記録から確かめ続ける考え方です。最低限、次の 3 種類を残します。
- WordPress のログイン成功・失敗、ユーザーやロールの変更、プラグインの有効化（アクティビティログ系のプラグインで記録できます）
- 前段のプロキシや WAF の認証ログ
- Web サーバーのアクセスログ
ログは攻撃者に消されないよう、サーバーの外にも転送しておくのが理想です。月に一度は、管理者ロールの人数、発行済みのアプリケーションパスワード、前段の認証で許可しているユーザーの一覧を見直し、不要なものを削除します。
まとめ
- ゼロトラストは「場所やログイン状態で信頼しない」設計で、WordPress では管理画面・API・サーバーの 3 つが対象です。
- 管理者と編集者には 2FA を必須にし、組織では IdP に認証をまとめます。
- 管理画面の前段に認証を置く場合は、
admin-ajax.phpの除外とオリジンへの直接アクセス対策を忘れないようにします。 - ロールを最小にし、
DISALLOW_FILE_EDITで管理画面からのコード変更を止めます。 - API 連携は専用ユーザーとアプリケーションパスワードで分け、ログで定期的に検証します。