2026年7月6日

2026年7月6日

WordPressの特権アクセス管理(PAM)|管理者権限を絞り、使用を記録する手順

特権アクセス管理(PAM: Privileged Access Management)は、管理者のように強い権限を持つアカウントを「必要な人に、必要な間だけ」渡し、その使用を記録する考え方です。WordPressでは管理者(administrator)が該当し、プラグインのインストールやユーザーの追加など、サイト全体を書き換えられます。

この記事では、WordPressで特権アクセス管理を実践する手順を、管理画面とWP-CLIの操作、短いコード例で紹介します。

先に確認: 2つの「PAM」は別物

「PAM」という略語は、Linuxの認証の仕組み Pluggable Authentication Modules にも使われます。こちらは /etc/pam.d/ の設定でSSHやsudoなどの認証方式を切り替える仕組みです。

WordPressは自分のデータベース(wp_users テーブル)でユーザーを認証しており、コアにはLinuxのPAMで認証する設定はありません。wp-config.php に定数を1行書けばLinuxのPAM認証に切り替わる、といった方法は存在しないので注意してください。この記事で扱うのは、特権アクセス管理のほうです。

特権アクセス管理で押さえる4点

考え方 WordPressでの具体策
特権アカウントを把握する 管理者の一覧を定期的に出して確認する
権限を最小にする 日常の作業は編集者などの権限で行い、管理者は必要な人だけにする
特権の入口を守る 二要素認証、アプリケーションパスワードの管理、ファイル編集の禁止
使用を記録する 権限の変更と管理者のログインをログに残す

手順1: 管理者アカウントを棚卸しする

管理画面では「ユーザー」→「ユーザー一覧」の上部にある「管理者」をクリックすると、管理者だけを表示できます。WP-CLIでは次のように一覧を出せます。

# 管理者の一覧(ID・ログイン名・メール・登録日)
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# CSVで保存して、担当者と照合する
wp user list --role=administrator --format=csv > admins.csv

退職者や外部の制作会社のアカウント、誰のものか分からないアカウントが残っていないかを確認します。見覚えのない管理者がいた場合は、不正侵入で作られた可能性もあるため、削除する前にサーバーのアクセスログやファイルの変更履歴も調べてください。

手順2: 権限を必要な分だけにする

WordPressの標準の権限グループは、権限が強い順に管理者・編集者・投稿者・寄稿者・購読者です。記事の公開や他人の記事の編集は編集者でできるため、編集担当に管理者を渡す必要はありません。

# 管理者を編集者に変更する(ユーザーはID・ログイン名・メールで指定できる)
wp user set-role alice editor

# 現在の権限グループと個別の権限を確認する
wp user get alice --field=roles
wp user list-caps alice

管理者の作業が一時的に必要なときは、作業の前に権限を上げ、終わったら戻す運用にすると、管理者の人数を最小に保てます。

# 作業の前
wp user set-role alice administrator

# 作業の後(あわせて、そのユーザーのログイン中のセッションをすべて切る)
wp user set-role alice editor
wp user session destroy alice --all

権限グループごとの権限の内容は、ユーザー権限と権限グループの解説も参考にしてください。

手順3: 特権の入口を守る

管理画面からのファイル編集を禁止する

wp-config.php の「編集が必要なのはここまでです」の行より上に、次を追加します。

define( 'DISALLOW_FILE_EDIT', true );

公式のハードニングガイドでは、これはすべてのユーザーから edit_themes・edit_plugins・edit_files の権限を外すのと同じだと説明されています。管理者のアカウントが乗っ取られても、管理画面のテーマ・プラグインのエディターでPHPを書き換えられなくなります。ただし、悪意のあるファイルのアップロードまで防ぐものではありません。

管理者に二要素認証を設定する

パスワードだけに頼らず、管理者には二要素認証を設定します。WordPress.orgで配布されている「Two-Factor」プラグインなどで、認証アプリのワンタイムコードやメールでの確認を追加できます。

アプリケーションパスワードを確認する

WordPress 5.6以降には、REST APIなどで使う「アプリケーションパスワード」があります。管理者に発行されたものは管理者と同じ権限で使えるため、使っていないものは削除します。

# alice に発行されたアプリケーションパスワードの一覧
wp user application-password list alice

管理画面では「ユーザー」→対象ユーザーのプロフィール画面の「アプリケーションパスワード」欄で確認・取り消しができます。サイトで使っていない場合は、次のフィルターで機能ごと無効にできます。

add_filter( 'wp_is_application_passwords_available', '__return_false' );

手順4: 権限の変更と管理者のログインを記録する

誰がいつ権限を変えたか、管理者がいつログインしたかを残しておくと、異常に気付きやすくなります。次のコードを wp-content/mu-plugins/privileged-access-log.php として保存すると、PHPのエラーログに記録されます(mu-plugins フォルダーが無ければ作ります)。

<?php
/**
 * Plugin Name: Privileged Access Log
 * Description: 権限グループの変更と、管理権限を持つユーザーのログインを記録する。
 */

// 権限グループが変更されたとき
add_action( 'set_user_role', function ( $user_id, $role, $old_roles ) {
	error_log( sprintf(
		'[privileged-access] role changed: user=%d from=%s to=%s by=%d',
		$user_id,
		implode( ',', (array) $old_roles ),
		$role,
		get_current_user_id()
	) );
}, 10, 3 );

// 管理権限(manage_options)を持つユーザーがログインしたとき
add_action( 'wp_login', function ( $user_login, $user ) {
	if ( user_can( $user, 'manage_options' ) ) {
		$ip = isset( $_SERVER['REMOTE_ADDR'] ) ? $_SERVER['REMOTE_ADDR'] : '-';
		error_log( sprintf( '[privileged-access] admin login: user=%s ip=%s', $user_login, $ip ) );
	}
}, 10, 2 );

set_user_role は権限グループが設定されたときに、新しい権限と以前の権限を渡して呼ばれるフックです。WP-CLIで変更した場合、操作したユーザーのIDは0として記録されます。ログの出力先はサーバーのPHP設定(error_log)によって変わるので、記録されているかを一度確認してください。ログは改ざんを避けるため、サイトとは別の場所に定期的に転送しておくと安心です。

手順5: サーバーとデータベースの特権も分ける

WordPressの外側にも特権があります。管理画面だけ固めても、SSHやデータベースの権限が広いままでは効果が限られます。

  • SSH: 担当者ごとに個別のアカウントを作り、公開鍵認証にします。/etc/ssh/sshd_config で PermitRootLogin no と PasswordAuthentication no を設定し、管理作業は sudo で行うと、誰が何をしたかが記録に残ります。
  • データベース: サイトごとに専用のDBユーザーを作り、他のデータベースへの権限は渡しません。公式ガイドによると、通常の動作に必要なのは SELECT・INSERT・UPDATE・DELETE の4つです。ただし、プラグインや更新でテーブル構造を変えることがあるため、ALTER や CREATE などを外すことは推奨されていません。DBユーザーの分け方はデータベースユーザーの最小権限で詳しく扱っています。
  • ホスティングの管理画面: レンタルサーバーやクラウドの管理画面のアカウントも、共有せずに担当者ごとに分け、二要素認証を設定します。

企業でPAM製品やシングルサインオン(SSO)を導入済みなら、WordPressのログインもその認証基盤に寄せると、退職者のアカウント停止などを一元化できます(OpenID ConnectでのSSO設定を参照)。

まとめ

  • WordPressの特権アカウントは管理者です。LinuxのPAM(Pluggable Authentication Modules)とは別の話で、WordPressコアにLinuxのPAMで認証する設定はありません。
  • 管理者を定期的に棚卸しし、日常の作業は編集者などで行い、管理者の作業は必要なときだけ権限を上げます。
  • DISALLOW_FILE_EDIT、二要素認証、アプリケーションパスワードの整理で特権の入口を守ります。
  • set_user_role と wp_login のフックで、権限の変更と管理者のログインを記録できます。
  • SSH・データベース・ホスティングの管理画面の特権も、担当者ごとに分けて管理します。

関連記事:

お気軽にご相談ください

お見積りへ お問い合わせへ
▲