2026年5月25日

2026年5月25日

MySQLのユーザー作成と権限設定方法(WordPress用の最小権限の考え方)

MySQL でユーザーを作って権限を与えるには、CREATE USER でユーザーを作成し、GRANT で「どのデータベースに対して何ができるか」を付与し、SHOW GRANTS で結果を確認する、という3段階で進めます。この記事では WordPress 用のユーザーを例に、ユーザー名とホストの考え方、用途に合った権限の選び方、確認・変更・取り消し・削除の方法、MySQL 8 系で変わった点と、接続できないときの確認方法までを説明します。

ユーザーは「名前@ホスト」で1つになる

MySQL のユーザーは、名前だけでなく接続元のホストとの組み合わせで区別されます。'wp_user'@'localhost' と 'wp_user'@'%' は別のユーザーで、パスワードも権限も別々に管理されます。

  • 'wp_user'@'localhost': 同じサーバー内から接続する場合に使います。Linux では、接続先に localhost を指定すると TCP ではなく Unix ソケット経由の接続になります。
  • 'wp_user'@'127.0.0.1': 同じサーバー内から TCP で接続する場合です。
  • 'wp_user'@'10.0.0.%' や 'wp_user'@'192.0.2.20': 別のサーバーから接続する場合に、接続元を絞って指定します。
  • 'wp_user'@'%': どこからでも接続を受け付けます。データベースのポートを外部に公開している環境では避けるべき指定です。

WordPress とデータベースが同じサーバーにあり、wp-config.php の DB_HOST が localhost なら、'wp_user'@'localhost' を作るのが基本です。

ユーザーを作成する

作業は管理者権限のあるアカウントで行います。Ubuntu のパッケージ版では、root はパスワードではなく OS の root 権限で認証する設定になっていることが多いため、sudo mysql で接続できます。

CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'your-strong-password';

パスワードは推測されにくい長いものにします。openssl rand -base64 24 などで生成すると手軽です。ただし、シングルクォートやバックスラッシュを含むパスワードは、wp-config.php の文字列として書くときにエスケープが必要になり、書き間違いの原因になります。生成した文字列にそれらが含まれていたら作り直すほうが安全です。

コマンドラインで mysql -u root -p'パスワード' のようにパスワードを引数に書くと、シェルの履歴やプロセス一覧に残ります。-p だけを付けて対話的に入力してください。

MySQL 8 系で変わった点

MySQL 8.0 以降では、GRANT 文でユーザーを同時に作成することはできなくなり、CREATE USER を先に実行する必要があります。古い記事にある GRANT ... IDENTIFIED BY ... の書き方はエラーになります。

認証方式(認証プラグイン)も変わっています。MySQL 8.0 以降の既定は caching_sha2_password で、従来の mysql_native_password は非推奨となり、8.4 では既定で無効、9.0 では削除されました(2026年10月現在。MySQL は 8.0 系のサポートが終了し、8.4 LTS への移行が進んでいる時期です)。PHP 7.4 以降の mysqlnd は caching_sha2_password に対応しているため、現行の WordPress 環境では通常そのままで接続できます。古いクライアントやツールで接続できないときは、まずクライアント側の更新を検討してください。

MariaDB では認証の仕組みと既定値が MySQL と異なり、caching_sha2_password はありません。MariaDB を使っている場合は、使用中の版の公式ドキュメントを確認してください。

権限を付与する:用途ごとの考え方

権限は「どの範囲に(*.* / データベース.* / データベース.テーブル)」「何を許すか」で指定します。WordPress のユーザーにサーバー全体の権限(*.*)を与える必要はありません。万一 WordPress 側に SQL インジェクションの脆弱性があったとき、被害がそのデータベースだけで済むよう、範囲は1つのデータベースに限定します。

WordPress用のユーザー

もっとも一般的なのは、WordPress のデータベースに限定して全権限を与える方法です。

GRANT ALL PRIVILEGES ON wordpress.* TO 'wp_user'@'localhost';

さらに絞る場合は、次のような組み合わせがよく使われます。通常の運用は SELECT・INSERT・UPDATE・DELETE で動きますが、WordPress 本体の更新やプラグインの有効化ではテーブルの作成・変更が行われるため、CREATE・ALTER・INDEX なども必要になります。

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP,
      CREATE TEMPORARY TABLES, LOCK TABLES
  ON wordpress.* TO 'wp_user'@'localhost';

権限を絞りすぎると、プラグインの有効化や更新が途中で失敗し、テーブルが中途半端な状態で残ることがあります。絞る場合は、ステージング環境で更新やプラグインの追加まで試してから本番に適用してください。

バックアップ専用のユーザー

mysqldump で定期バックアップを取るだけなら、書き込みの権限は不要です。

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'your-strong-password';
GRANT SELECT, SHOW VIEW, TRIGGER, EVENT, LOCK TABLES ON wordpress.* TO 'backup'@'localhost';

MySQL 8.0.21 以降の mysqldump は、テーブルスペースの情報を出力するために PROCESS 権限を求めます。PROCESS はサーバー全体の権限なので、付与したくない場合は mysqldump --no-tablespaces を付けて実行します。InnoDB のテーブルを --single-transaction 付きでダンプする場合は、LOCK TABLES がなくても動作します。

権限を確認する

付与した内容は SHOW GRANTS で確認します。

SHOW GRANTS FOR 'wp_user'@'localhost';
SELECT user, host, plugin FROM mysql.user ORDER BY user, host;

2つ目のクエリでは、同じ名前で別のホストのユーザーが残っていないか、認証プラグインが何になっているかを確認できます。意図しない '%' のユーザーが見つかったら、使われていないことを確かめたうえで削除します。

GRANT や CREATE USER で操作した場合、FLUSH PRIVILEGES は不要です。これが必要になるのは、mysql.user などの権限テーブルを UPDATE 文で直接書き換えたときだけで、そうした直接の書き換え自体も避けるべき操作です。

権限の取り消し・パスワード変更・削除

付けすぎた権限は REVOKE で取り消します。

REVOKE DROP ON wordpress.* FROM 'wp_user'@'localhost';

パスワードの変更は ALTER USER で行います。WordPress のユーザーのパスワードを変えたら、wp-config.php の DB_PASSWORD も同時に書き換えないと、サイトが「データベース接続確立エラー」になります。変更の前に wp-config.php のバックアップを取り、作業は短い時間で続けて行ってください。

ALTER USER 'wp_user'@'localhost' IDENTIFIED BY 'your-new-password';

使わなくなったユーザーは DROP USER で削除します。削除前に、そのユーザーで接続しているアプリやバックアップのスクリプトがないかを確認します。一時的に止めたいだけなら、ALTER USER 'wp_user'@'localhost' ACCOUNT LOCK; でロックする方法もあります(ACCOUNT UNLOCK で解除)。

DROP USER 'old_user'@'localhost';

複数のユーザーに同じ権限のセットを配りたい場合は、MySQL 8.0 以降のロール機能(CREATE ROLE で権限のまとまりを作り、GRANT ロール名 TO ユーザー で割り当てる)も使えます。ロールは割り当てただけでは有効にならず、SET DEFAULT ROLE で既定のロールを設定する必要がある点に注意してください。

「Access denied」で接続できないとき

Access denied for user 'wp_user'@'localhost' が出る場合は、次の順で確認します。

  1. パスワードの誤り: mysql -u wp_user -p -h localhost で、wp-config.php と同じ値を手で入力して接続できるかを試します。
  2. ホストの食い違い: DB_HOST が 127.0.0.1 なのにユーザーが 'wp_user'@'localhost' しかない、などの組み合わせです。エラーメッセージの @ の後ろに表示されるホストと、mysql.user のホストを比べます。
  3. 権限の範囲違い: 接続はできてもデータベースを開けない場合は、SHOW GRANTS の対象データベース名が実際の名前と一致しているかを確認します。
  4. 認証プラグインの非対応: 古いクライアントでは caching_sha2_password に対応しておらず、認証の段階で失敗します。

まとめ

  • MySQL のユーザーは「名前@ホスト」で区別されます。同じサーバー内の WordPress なら 'wp_user'@'localhost' が基本です。
  • MySQL 8.0 以降は CREATE USER で作成してから GRANT で権限を与えます。GRANT で同時に作る書き方は使えません。
  • 権限の範囲は1つのデータベースに限定し、バックアップ用など用途ごとにユーザーを分けると被害の範囲を狭められます。
  • SHOW GRANTS で確認し、REVOKE・ALTER USER・DROP USER で見直します。パスワードを変えたら wp-config.php も更新します。

お気軽にご相談ください

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