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・データベース・ホスティングの管理画面の特権も、担当者ごとに分けて管理します。
関連記事: