このページは機械翻訳したものです。

6.2.2 MySQL で提供される権限

MySQL アカウントに付与される権限によって、アカウントが実行できる操作が決まります。 MySQL の権限は、適用されるコンテキストと操作のレベルによって異なります:

• 管理権限によって、ユーザーは MySQL サーバーの動作を管理できます。 これらの権限は特定のデータベースに固有でないため、グローバルです。

• データベース権限は、データベースおよびデータベース内のすべてのオブジェクトに適用されます。 これらの権限は、特定のデータベースに付与したり、すべてのデータベースに適用されるようにグローバルに付与したりすることができます。

• テーブル、インデックス、ビュー、ストアドルーチンなどのデータベースオブジェクトに対する権限は、データベース内の特定のオブジェクト、データベース内の特定のタイプのすべてのオブジェクト (データベース内のすべてのテーブルなど)、またはすべてのデータベース内の特定のタイプのすべてのオブジェクトに対してグローバルに付与できます。

権限は、静的 (サーバーに組み込まれている) か動的 (実行時に定義される) かによっても異なります。 権限が静的であるか動的であるかは、ユーザーアカウントおよびロールに付与される可用性に影響します。 静的権限と動的権限の違いの詳細は、静的権限と動的権限 を参照してください。)

アカウント権限に関する情報は、mysql システムデータベースの付与テーブルに格納されます。 これらのテーブルの構造および内容の説明は、セクション6.2.3「付与テーブル」 を参照してください。 MySQL サーバーは、起動時に付与テーブルの内容をメモリーに読み取り、セクション6.2.13「権限変更が有効化される時期」 に示されている状況下でそれらをリロードします。 サーバーは、付与テーブルのメモリー内コピーに基づいてアクセス制御の決定を行います。

重要

一部の MySQL リリースでは、新しい権限または機能を追加するために付与テーブルに変更が導入されています。 新しい機能を確実に利用できるようにするには、MySQL をアップグレードするたびに付与テーブルを現在の構造に更新します。 セクション2.11「MySQL のアップグレード」を参照してください。

次の各セクションでは、使用可能な権限の概要、各権限の詳細な説明および使用上のガイドラインを示します。

• 使用可能な権限のサマリー

• 静的権限の説明

• 動的権限の説明

• 権限付与のガイドライン

• 静的権限と動的権限

• SUPER から動的権限へのアカウントの移行

使用可能な権限のサマリー

次のテーブルに、GRANT および REVOKE ステートメントで使用される静的権限名と、付与テーブルの各権限に関連付けられたカラム名および権限が適用されるコンテキストを示します。

表 6.2 GRANT および REVOKE に許可される静的権限

権限	付与テーブルカラム	コンテキスト
ALL [PRIVILEGES]	「「すべての権限」」のシノニム	サーバー管理
ALTER	Alter_priv	テーブル
ALTER ROUTINE	Alter_routine_priv	ストアドルーチン
CREATE	Create_priv	データベース、テーブルまたはインデックス
CREATE ROLE	Create_role_priv	サーバー管理
CREATE ROUTINE	Create_routine_priv	ストアドルーチン
CREATE TABLESPACE	Create_tablespace_priv	サーバー管理
CREATE TEMPORARY TABLES	Create_tmp_table_priv	テーブル
CREATE USER	Create_user_priv	サーバー管理
CREATE VIEW	Create_view_priv	ビュー
DELETE	Delete_priv	テーブル
DROP	Drop_priv	データベース、テーブルまたはビュー
DROP ROLE	Drop_role_priv	サーバー管理
EVENT	Event_priv	データベース
EXECUTE	Execute_priv	ストアドルーチン
FILE	File_priv	サーバーホストでのファイルアクセス
GRANT OPTION	Grant_priv	データベース、テーブル、またはストアドルーチン
INDEX	Index_priv	テーブル
INSERT	Insert_priv	テーブルまたはカラム
LOCK TABLES	Lock_tables_priv	データベース
PROCESS	Process_priv	サーバー管理
PROXY	proxies_priv テーブルを参照	サーバー管理
REFERENCES	References_priv	データベースまたはテーブル
RELOAD	Reload_priv	サーバー管理
REPLICATION CLIENT	Repl_client_priv	サーバー管理
REPLICATION SLAVE	Repl_slave_priv	サーバー管理
SELECT	Select_priv	テーブルまたはカラム
SHOW DATABASES	Show_db_priv	サーバー管理
SHOW VIEW	Show_view_priv	ビュー
SHUTDOWN	Shutdown_priv	サーバー管理
SUPER	Super_priv	サーバー管理
TRIGGER	Trigger_priv	テーブル
UPDATE	Update_priv	テーブルまたはカラム
USAGE	「権限なし」のシノニムです	サーバー管理

次のテーブルに、GRANT および REVOKE ステートメントで使用される動的権限名と、その権限が適用されるコンテキストを示します。

表 6.3 GRANT および REVOKE に許可される動的権限

権限	コンテキスト
APPLICATION_PASSWORD_ADMIN	デュアルパスワード管理
AUDIT_ADMIN	監査ログの管理
BACKUP_ADMIN	バックアップ管理
BINLOG_ADMIN	バックアップとレプリケーションの管理
BINLOG_ENCRYPTION_ADMIN	バックアップとレプリケーションの管理
CLONE_ADMIN	クローン管理
CONNECTION_ADMIN	サーバー管理
ENCRYPTION_KEY_ADMIN	サーバー管理
FIREWALL_ADMIN	ファイアウォール管理
FIREWALL_USER	ファイアウォール管理
FLUSH_OPTIMIZER_COSTS	サーバー管理
FLUSH_STATUS	サーバー管理
FLUSH_TABLES	サーバー管理
FLUSH_USER_RESOURCES	サーバー管理
GROUP_REPLICATION_ADMIN	レプリケーション管理
INNODB_REDO_LOG_ARCHIVE	redo ログアーカイブ管理
NDB_STORED_USER	NDB Cluster
PERSIST_RO_VARIABLES_ADMIN	サーバー管理
REPLICATION_APPLIER	レプリケーションチャネル用の PRIVILEGE_CHECKS_USER
REPLICATION_SLAVE_ADMIN	レプリケーション管理
RESOURCE_GROUP_ADMIN	リソースグループ管理
RESOURCE_GROUP_USER	リソースグループ管理
ROLE_ADMIN	サーバー管理
SESSION_VARIABLES_ADMIN	サーバー管理
SET_USER_ID	サーバー管理
SHOW_ROUTINE	サーバー管理
SYSTEM_USER	サーバー管理
SYSTEM_VARIABLES_ADMIN	サーバー管理
TABLE_ENCRYPTION_ADMIN	サーバー管理
VERSION_TOKEN_ADMIN	サーバー管理
XA_RECOVER_ADMIN	サーバー管理

静的権限の説明

静的権限は、実行時に定義される動的権限とは対照的に、サーバーに組み込まれます。 次のリストでは、MySQL で使用可能な各静的権限について説明します。

特定の SQL ステートメントには、ここに示されているよりも具体的な権限要件がある場合もあります。 そのような場合、該当するステートメントの説明で詳細を示します。

• ALL, ALL PRIVILEGES

  これらの権限指定子は、「「特定の権限レベルで使用可能なすべての権限」」 (GRANT OPTION を除く) の短縮形です。 たとえば、グローバルレベルまたはテーブルレベルで ALL を付与すると、すべてのグローバル権限またはすべてのテーブルレベル権限がそれぞれ付与されます。

• ALTER

  ALTER TABLE ステートメントを使用してテーブルの構造を変更できます。 ALTER TABLE には CREATE および INSERT 権限も必要です。 テーブルの名前を変更するには、古いテーブルで ALTER および DROP を、新しいテーブルで CREATE および INSERT を実行する必要があります。

• ALTER ROUTINE

  ストアドルーチン (ストアドプロシージャーおよびストアドファンクション) を変更または削除するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。

• CREATE

  新しいデータベースおよびテーブルを作成するステートメントの使用を有効にします。

• CREATE ROLE

  CREATE ROLE ステートメントの使用を有効にします。 (CREATE USER 権限により、CREATE ROLE ステートメントの使用も可能になります。) セクション6.2.10「ロールの使用」を参照してください。

  CREATE ROLE および DROP ROLE 権限は、アカウントの作成および削除にのみ使用できるため、CREATE USER ほど強力ではありません。 これらは、CREATE USER でアカウント属性を変更したり、アカウントの名前を変更できるため、使用できません。 ユーザーとロールの互換性を参照してください。

• CREATE ROUTINE

  ストアドルーチン (ストアドプロシージャーとストアドファンクション) を作成するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。

• CREATE TABLESPACE

  テーブルスペースおよびログファイルグループを作成、変更または削除するステートメントを使用可能にします。

• CREATE TEMPORARY TABLES

  CREATE TEMPORARY TABLE ステートメントを使用した一時テーブルの作成を有効にします。

  セッションが一時テーブルを作成したあと、サーバーはそのテーブルに対するそれ以上の権限チェックを実行しません。 セッションの作成によって、DROP TABLE、INSERT、UPDATE、SELECT などのあらゆる操作をテーブル上で実行できます。 詳細は、セクション13.1.20.2「CREATE TEMPORARY TABLE ステートメント」を参照してください。

• CREATE USER

  ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, RENAME USER および REVOKE ALL PRIVILEGES ステートメントの使用を有効にします。

• CREATE VIEW

  CREATE VIEW ステートメントの使用を有効にします。

• DELETE

  データベース内のテーブルから行を削除できます。

• DROP

  既存のデータベース、テーブルおよびビューを削除するステートメントを使用可能にします。 パーティションテーブルで ALTER TABLE ... DROP PARTITION ステートメントを使用するには、DROP 権限が必要です。 DROP 権限は TRUNCATE TABLE のためにも必要です。

• DROP ROLE

  DROP ROLE ステートメントの使用を有効にします。 (CREATE USER 権限により、DROP ROLE ステートメントの使用も可能になります。) セクション6.2.10「ロールの使用」を参照してください。

  CREATE ROLE および DROP ROLE 権限は、アカウントの作成および削除にのみ使用できるため、CREATE USER ほど強力ではありません。 これらは、CREATE USER でアカウント属性を変更したり、アカウントの名前を変更できるため、使用できません。 ユーザーとロールの互換性を参照してください。

• EVENT

  イベントスケジューラのイベントを作成、変更、削除、または表示するステートメントの使用を有効にします。

• EXECUTE

  ストアドルーチン (ストアドプロシージャーとストアドファンクション) を実行するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。

• FILE

  次の操作およびサーバーの動作に影響します:

  • LOAD DATA および SELECT ... INTO OUTFILE ステートメントと LOAD_FILE() 関数を使用して、サーバーホスト上のファイルの読取りおよび書込みを有効にします。 FILE 権限を持つユーザーは、すべてのユーザーから読み取り可能であるか、MySQL サーバーによって読み取り可能なサーバーホスト上のすべてのファイルを読み取ることができます。 (このことは暗黙的に、データベースディレクトリ内のあらゆるファイルにサーバーからアクセスできるため、ユーザーはそれらのすべてのファイルを読み取ることができることを意味します。)

  • MySQL サーバーが書込みアクセス権を持つ任意のディレクトリに新しいファイルを作成できます。 これは、権限テーブルを実装するファイルを格納するサーバーのデータディレクトリを含みます。

  • CREATE TABLE ステートメントに DATA DIRECTORY または INDEX DIRECTORY テーブルオプションを使用できるようにします。

  セキュリティ対策として、サーバーは既存のファイルを上書きしません。

  ファイルの読取りおよび書込みが可能な場所を制限するには、secure_file_priv システム変数を特定のディレクトリに設定します。 セクション5.1.8「サーバーシステム変数」を参照してください。

• GRANT OPTION

  自分が所有する権限を他のユーザーに付与したり、他のユーザーから取り消すことができます。

• INDEX

  インデックスを作成または削除するステートメントの使用を有効にします。 INDEX は既存のテーブルに適用されます。 テーブルに対する CREATE 権限を持つ場合、CREATE TABLE ステートメントにインデックス定義を含めることも可能です。

• INSERT

  データベースのテーブルに行を挿入できます。 ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE などのテーブル保守に関するステートメントにも、INSERT 権限が必要です。

• LOCK TABLES

  明示的な LOCK TABLES ステートメントを使用して、SELECT 権限を持つテーブルをロックできます。 これには、他のセッションによるロックされたテーブルの読取りを防止する書込みロックの使用が含まれます。

• PROCESS

  PROCESS 権限は、サーバー内で実行されているスレッドに関する情報 (セッションによって実行されているステートメントに関する情報) へのアクセスを制御します。 SHOW PROCESSLIST ステートメント、mysqladmin processlist コマンド、INFORMATION_SCHEMA.PROCESSLIST テーブル、およびパフォーマンススキーマ processlist テーブルを使用して使用可能なスレッド情報には、次のようにアクセスできます:

  • PROCESS 権限を持つユーザーは、他のユーザーに属するスレッドも含め、すべてのスレッドに関する情報にアクセスできます。

  • PROCESS 権限がない場合、非匿名ユーザーは自分のスレッドに関する情報にアクセスできますが、他のユーザーのスレッドにはアクセスできません。また、匿名ユーザーはスレッド情報にアクセスできません。

  注記

  パフォーマンススキーマ threads テーブルはスレッド情報も提供しますが、テーブルアクセスは別の特権モデルを使用します。 セクション27.12.19.10「スレッドテーブル」を参照してください。

  PROCESS 権限では、SHOW ENGINE ステートメントの使用、INFORMATION_SCHEMA InnoDB テーブル (INNODB_で始まる名前を持つテーブル) へのアクセスおよび、(MySQL 8.0.21 の時点で) INFORMATION_SCHEMA FILES テーブルへのアクセスも可能です。

• PROXY

  あるユーザーが別のユーザーになりすましたり、別のユーザーとして知られるようにします。 セクション6.2.18「プロキシユーザー」を参照してください。

• REFERENCES

  外部キー制約を作成するには、親テーブルに対する REFERENCES 権限が必要です。

• RELOAD

  RELOAD では、次の操作が可能です:

  • FLUSH ステートメントの使用。

  • FLUSH 操作と同等の mysqladmin コマンドの使用: flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh および reload。

    reload コマンドは、付与テーブルをメモリーにリロードするようにサーバーに指示します。flush-privileges は reload のシノニムです。 refresh コマンドは、ログファイルを閉じて再オープンし、すべてのテーブルをフラッシュします。 ほかの flush-xxx コマンドは refresh に類似した機能を実行しますが、より具体的であるため一部の状況では好ましい場合があります。 たとえば、ログファイルだけをフラッシュするときは、refresh よりも flush-logs を選択することをお勧めします。

  • 様々な FLUSH 操作を実行する mysqldump オプションの使用: --flush-logs および --master-data。

  • RESET MASTER および RESET REPLICA | SLAVE ステートメントの使用。

• REPLICATION CLIENT

  SHOW MASTER STATUS、SHOW REPLICA | SLAVE STATUS および SHOW BINARY LOGS ステートメントの使用を有効にします。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。

• REPLICATION SLAVE

  SHOW REPLICAS | SHOW SLAVE HOSTS、SHOW RELAYLOG EVENTS および SHOW BINLOG EVENTS ステートメントを使用して、レプリケーションソースサーバー上のデータベースに対して行われた更新をアカウントがリクエストできるようにします。 この権限は、mysqlbinlog オプションの --read-from-remote-server (-R) および --read-from-remote-master を使用する場合にも必要です。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。

• SELECT

  データベース内のテーブルから行を選択できます。 SELECT ステートメントには、実際にテーブルにアクセスする場合にのみ SELECT 権限が必要です。 一部の SELECT ステートメントはテーブルにアクセスしないため、あらゆるデータベースへのアクセス権がなくても実行できます。 たとえば、テーブルを参照しない式を評価するための単純な計算機として SELECT を使用することができます。

  SELECT 1+1;
  SELECT PI()*2;

  SELECT 権限は、カラム値を読み取るほかのステートメントについても必要です。 たとえば、UPDATE ステートメントの代入 col_name=expr の右辺で参照されるカラムや、DELETE または UPDATE ステートメントの WHERE 句で指定されるカラムについて、SELECT が必要です。

  EXPLAIN で使用されるテーブルまたはビュー (ビュー定義の基礎となるテーブルを含む) には、SELECT 権限が必要です。

• SHOW DATABASES

  SHOW DATABASE ステートメントを発行して、アカウントがデータベース名を表示できるようにします。 この権限を持たないアカウントには、アカウントが一部の権限を持つデータベースしか表示されず、サーバーが --skip-show-database オプションで起動されている場合はステートメントを一切使用できません。

  注意

  静的グローバル権限はすべてのデータベースに対する権限とみなされるため、静的グローバル権限を使用すると、ユーザーは、部分的な取消しによってデータベースレベルで制限されているデータベースを除き、SHOW DATABASES を使用するか、INFORMATION_SCHEMA の SCHEMATA テーブルを調べることで、すべてのデータベース名を表示できます。

• SHOW VIEW

  SHOW CREATE VIEW ステートメントの使用を有効にします。 この権限は、EXPLAIN で使用されるビューにも必要です。

• SHUTDOWN

  SHUTDOWN および RESTART ステートメント、mysqladmin shutdown コマンドおよび mysql_shutdown() C API 関数の使用を有効にします。

• SUPER

  SUPER は強力で遠いリカバリ権限であるため、軽く付与しないでください。 アカウントで SUPER 操作のサブセットのみを実行する必要がある場合は、かわりに 1 つ以上の動的権限を付与することで、必要な権限セットを実現できる場合があり、それぞれがより制限された機能を構成します。 動的権限の説明を参照してください。

  注記

  SUPER は非推奨であり、将来のバージョンの MySQL で削除される予定です。 SUPER から動的権限へのアカウントの移行を参照してください。

  SUPER は、次の操作およびサーバーの動作に影響します:

  • 実行時のシステム変数の変更を有効にします:

    • SET GLOBAL および SET PERSIST を使用して、グローバルシステム変数に対するサーバー構成の変更を有効にします。

      対応する動的権限は SYSTEM_VARIABLES_ADMIN です。

    • 特別な権限を必要とする制限付きセッションシステム変数の設定を有効にします。

      対応する動的権限は SESSION_VARIABLES_ADMIN です。

    セクション5.1.9.1「システム変数権限」も参照してください。

  • グローバルトランザクション特性の変更を有効にします (セクション13.3.7「SET TRANSACTION ステートメント」 を参照)。

    対応する動的権限は SYSTEM_VARIABLES_ADMIN です。

  • グループレプリケーションを含む、レプリケーションを開始および停止するアカウントを有効にします。

    対応する動的権限は、通常のレプリケーションの場合は REPLICATION_SLAVE_ADMIN、グループレプリケーションの場合は GROUP_REPLICATION_ADMIN です。

  • (MySQL 8.0.23 の)CHANGE REPLICATION SOURCE TO ステートメント、(MySQL 8.0.23 の前の)CHANGE MASTER TO ステートメントおよび CHANGE REPLICATION FILTER ステートメントを使用できます。

    対応する動的権限は REPLICATION_SLAVE_ADMIN です。

  • PURGE BINARY LOGS および BINLOG ステートメントを使用してバイナリログ制御を有効にします。

    対応する動的権限は BINLOG_ADMIN です。

  • ビューまたはストアドプログラムの実行時に有効な承認 ID を設定できるようにします。 この権限を持つユーザーは、ビューまたはストアドプログラムの DEFINER 属性で任意のアカウントを指定できます。

    対応する動的権限は SET_USER_ID です。

  • CREATE SERVER、ALTER SERVER および DROP SERVER ステートメントの使用を有効にします。

  • mysqladmin debug コマンドの使用を有効にします。

  • InnoDB 暗号化キーのローテーションを有効にします。

    対応する動的権限は ENCRYPTION_KEY_ADMIN です。

  • バージョントークンのユーザー定義関数の実行を有効にします。

    対応する動的権限は VERSION_TOKEN_ADMIN です。

  • ロールの付与と取消し、GRANT ステートメントの WITH ADMIN OPTION 句の使用、および ROLES_GRAPHML() 関数からの結果の空でない <graphml> 要素コンテンツを有効にします。

    対応する動的権限は ROLE_ADMIN です。

  • SUPER 以外のアカウントに対して許可されていないクライアント接続の制御を有効にします:

    • KILL ステートメントまたは mysqladmin kill コマンドを使用して、他のアカウントに属するスレッドを強制終了できます。 (アカウントは常に独自のスレッドを強制終了できます。)

    • サーバーは、SUPER クライアントの接続時に init_connect システム変数の内容を実行しません。

    • サーバーは、max_connections システム変数で構成された接続制限に達した場合でも、SUPER クライアントからの接続を受け入れます。

    • オフラインモード (offline_mode が有効) のサーバーは、次のクライアントリクエスト時に SUPER クライアント接続を終了せず、SUPER クライアントからの新しい接続を受け入れます。

    • read_only システム変数が有効な場合でも、更新を実行できます。 これは、明示的なテーブル更新、およびテーブルを暗黙的に更新する GRANT や REVOKE などのアカウント管理ステートメントの使用に適用されます。

    前述の接続制御操作に対応する動的権限は、CONNECTION_ADMIN です。

  セクション25.7「ストアドプログラムバイナリロギング」 で説明されているように、バイナリロギングが有効になっている場合は、ストアドファンクションを作成または変更するために SUPER 権限が必要になることもあります。

• TRIGGER

  トリガー操作を有効にします。 テーブルのトリガーを作成、削除、実行または表示するには、そのテーブルに対するこの権限が必要です。

  トリガーが (トリガーに関連付けられたテーブルに対して INSERT、UPDATE または DELETE ステートメントを実行する権限を持つユーザーによって) アクティブ化された場合、トリガーの実行には、トリガーを定義したユーザーがそのテーブルに対する TRIGGER 権限を持っている必要があります。

• UPDATE

  データベース内のテーブルで行を更新できます。

• USAGE

  この権限指定子は、「「権限なし」」を表します。 GRANT でグローバルレベルで使用され、権限リスト内の特定のアカウント権限に名前を付けずに WITH GRANT OPTION などの句を指定します。 SHOW GRANTS には、アカウントに権限レベルの権限がないことを示す USAGE が表示されます。

動的権限の説明

サーバーに組み込まれている静的権限とは対照的に、動的権限は実行時に定義されます。 次のリストでは、MySQL で使用可能な各動的権限について説明します。

ほとんどの動的権限は、サーバーの起動時に定義されます。 その他は、権限の説明に示されているように、特定のコンポーネントまたはプラグインによって定義されます。 このような場合、権限を定義するコンポーネントまたはプラグインが有効になっていないかぎり、権限は使用できません。

特定の SQL ステートメントには、ここに示されているよりも具体的な権限要件がある場合もあります。 そのような場合、該当するステートメントの説明で詳細を示します。

• APPLICATION_PASSWORD_ADMIN (MySQL 8.0.14 で追加)

  デュアルパスワード機能の場合、この権限により、自分のアカウントに適用される ALTER USER ステートメントおよび SET PASSWORD ステートメントに RETAIN CURRENT PASSWORD 句および DISCARD OLD PASSWORD 句を使用できます。 ほとんどのユーザーは 1 つのパスワードのみを必要とするため、自分のセカンダリパスワードを操作するにはこの権限が必要です。

  アカウントがすべてのアカウントのセカンダリパスワードの操作を許可される場合は、APPLICATION_PASSWORD_ADMIN ではなく CREATE USER 権限を付与する必要があります。

  デュアルパスワードの使用の詳細は、セクション6.2.15「パスワード管理」 を参照してください。

• AUDIT_ADMIN

  監査ログ構成を有効にします。 この権限は、audit_log プラグインによって定義されます。セクション6.4.5「MySQL Enterprise Audit」 を参照してください。

• BACKUP_ADMIN

  LOCK INSTANCE FOR BACKUP ステートメントの実行およびパフォーマンススキーマ log_status テーブルへのアクセスを有効にします。

  注記

  BACKUP_ADMIN の他に、log_status テーブルに対する SELECT 権限もアクセスに必要です。

  以前のバージョンから MySQL 8.0 へのインプレースアップグレードを実行すると、RELOAD 権限を持つユーザーに BACKUP_ADMIN 権限が自動的に付与されます。

• BINLOG_ADMIN

  PURGE BINARY LOGS および BINLOG ステートメントを使用してバイナリログ制御を有効にします。

• BINLOG_ENCRYPTION_ADMIN

  バイナリログファイルおよびリレーログファイルの暗号化をアクティブまたは非アクティブにするシステム変数 binlog_encryption の設定を有効にします。 この機能は、BINLOG_ADMIN、SYSTEM_VARIABLES_ADMIN または SESSION_VARIABLES_ADMIN 権限では提供されません。 サーバーの再起動時にバイナリログマスターキーを自動的にローテーションする関連システム変数 binlog_rotate_encryption_master_key_at_startup には、この権限は必要ありません。

• CLONE_ADMIN

  CLONE ステートメントの実行を有効にします。 BACKUP_ADMIN および SHUTDOWN 権限が含まれます。

• CONNECTION_ADMIN

  KILL ステートメントまたは mysqladmin kill コマンドを使用して、他のアカウントに属するスレッドを強制終了できます。 (アカウントは常に独自のスレッドを強制終了できます。)

  クライアント接続に関連するシステム変数の設定、またはクライアント接続に関連する制限の回避を有効にします。 CONNECTION_ADMIN は、次のシステム変数の影響に適用されます:

  • init_connect: サーバーは、CONNECTION_ADMIN クライアントの接続時に init_connect システム変数の内容を実行しません。

  • max_connections: サーバーは、max_connections システム変数で構成された接続制限に達した場合でも、CONNECTION_ADMIN クライアントからの接続を受け入れます。

  • offline_mode: オフラインモード (offline_mode が有効) のサーバーは、次のクライアントリクエスト時に CONNECTION_ADMIN クライアント接続を終了せず、CONNECTION_ADMIN クライアントからの新しい接続を受け入れます。

  • read_only: read_only システム変数が有効な場合でも、更新を実行できます。 これは、明示的なテーブル更新、およびテーブルを暗黙的に更新する GRANT や REVOKE などのアカウント管理ステートメントの使用に適用されます。

• ENCRYPTION_KEY_ADMIN

  InnoDB 暗号化キーのローテーションを有効にします。

• FIREWALL_ADMIN

  ユーザーは、任意のユーザーのファイアウォールルールを管理できます。 この権限は、MYSQL_FIREWALL プラグインによって定義されます。セクション6.4.7「MySQL Enterprise Firewall」 を参照してください。

• FIREWALL_USER

  ユーザーが独自のファイアウォールルールを更新できるようにします。 この権限は、MYSQL_FIREWALL プラグインによって定義されます。セクション6.4.7「MySQL Enterprise Firewall」 を参照してください。

• FLUSH_OPTIMIZER_COSTS (MySQL 8.0.23 で追加)

  FLUSH OPTIMIZER_COSTS ステートメントの使用を有効にします。

• FLUSH_STATUS (MySQL 8.0.23 で追加)

  FLUSH STATUS ステートメントの使用を有効にします。

• FLUSH_TABLES (MySQL 8.0.23 で追加)

  FLUSH TABLES ステートメントの使用を有効にします。

• FLUSH_USER_RESOURCES (MySQL 8.0.23 で追加)

  FLUSH USER_RESOURCES ステートメントの使用を有効にします。

• GROUP_REPLICATION_ADMIN

  START GROUP REPLICATION および STOP GROUP REPLICATION ステートメントを使用してグループレプリケーションを開始および停止し、group_replication_consistency システム変数のグローバル設定を変更し、group_replication_set_write_concurrency() および group_replication_set_communication_protocol() UDF を使用できるようにします。 レプリケーショングループのメンバーであるサーバーの管理に使用されるアカウントにこの権限を付与します。

• INNODB_REDO_LOG_ARCHIVE

  アカウントが redo ログアーカイブをアクティブ化および非アクティブ化できるようにします。

• INNODB_REDO_LOG_ENABLE

  ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG ステートメントを使用して redo ロギングを有効または無効にします。 MySQL 8.0.21 で導入されました。

  redo ロギングの無効化を参照してください。

• NDB_STORED_USER

  特定の NDB Cluster に参加するとすぐに、ユーザーまたは役割とその権限をすべての NDB 対応 MySQL サーバー間で共有および同期できるようにします。 この権限は、NDB ストレージエンジンが有効になっている場合にのみ使用できます。

  指定されたユーザーまたはロールに対して行われた権限の変更または取消しは、接続されているすべての MySQL サーバー (SQL ノード) とただちに同期化されます。 異なる SQL ノードから発生した権限に影響する複数のステートメントが、すべての SQL ノードで同じ順序で実行されることは保証されないことに注意してください。 このため、すべてのユーザー管理は単一の指定された SQL ノードから実行することを強くお薦めします。

  NDB_STORED_USER はグローバル権限であり、ON *.* を使用して付与または取り消す必要があります。 この権限に他のスコープを設定しようとすると、エラーになります。 この権限は、ほとんどのアプリケーションユーザーおよび管理ユーザーに付与できますが、mysql.session@localhost や mysql.infoschema@localhost などのシステム予約アカウントには付与できません。

  NDB_STORED_USER 権限を付与されたユーザーは、この権限を持つロールと同様に、NDB に格納されます (したがって、すべての SQL ノードで共有されます)。 NDB_STORED_USER を持つロールのみを付与されたユーザーは、NDB には格納されません。各 NDB 格納ユーザーには、権限を明示的に付与する必要があります。

  NDB でのこの動作の詳細は、セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 を参照してください。

  NDB_STORED_USER 権限は NDB 8.0.18 以降で使用できます。

• PERSIST_RO_VARIABLES_ADMIN

  SYSTEM_VARIABLES_ADMIN も持っているユーザーの場合、PERSIST_RO_VARIABLES_ADMIN を使用すると、SET PERSIST_ONLY を使用してグローバルシステム変数をデータディレクトリの mysqld-auto.cnf オプションファイルに永続化できます。 このステートメントは SET PERSIST と似ていますが、ランタイムグローバルシステム変数の値は変更されません。 これにより、SET PERSIST_ONLY は、サーバーの起動時にのみ設定できる読取り専用システム変数の構成に適しています。

  セクション5.1.9.1「システム変数権限」も参照してください。

• REPLICATION_APPLIER

  アカウントをレプリケーションチャネルの PRIVILEGE_CHECKS_USER として機能させ、mysqlbinlog 出力で BINLOG ステートメントを実行できるようにします。 CHANGE REPLICATION SOURCE TO (MySQL 8.0.23 から) または CHANGE MASTER TO (MySQL 8.0.23 より前) を使用して割り当てられたアカウントにこの権限を付与して、レプリケーションチャネルのセキュリティコンテキストを提供し、それらのチャネルでレプリケーションエラーを処理します。 REPLICATION_APPLIER 権限と同様に、レプリケーションチャネルで受信したトランザクションまたは mysqlbinlog 出力に含まれるトランザクションを実行するために必要な権限をアカウントに付与して、影響を受けるテーブルを更新する必要があります。 詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。

• REPLICATION_SLAVE_ADMIN

  アカウントがレプリケーションソースサーバーに接続し、START REPLICA | SLAVE および STOP REPLICA | SLAVE ステートメントを使用してレプリケーションを開始および停止し、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) および CHANGE REPLICATION FILTER ステートメントを使用します。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。 この権限はグループレプリケーションには適用されません。そのためには GROUP_REPLICATION_ADMIN を使用します。

• RESOURCE_GROUP_ADMIN

  リソースグループの作成、変更および削除、およびリソースグループへのスレッドとステートメントの割当てで構成されるリソースグループ管理を有効にします。 この権限を持つユーザーは、リソースグループに関連する操作を実行できます。

• RESOURCE_GROUP_USER

  リソースグループへのスレッドとステートメントの割り当てを有効にします。 この権限を持つユーザーは、SET RESOURCE GROUP ステートメントおよび RESOURCE_GROUP オプティマイザヒントを使用できます。

• ROLE_ADMIN

  ロールの付与と取消し、GRANT ステートメントの WITH ADMIN OPTION 句の使用、および ROLES_GRAPHML() 関数からの結果の空でない <graphml> 要素コンテンツを有効にします。 mandatory_roles システム変数の値を設定するために必要です。

• SERVICE_CONNECTION_ADMIN

  管理接続のみを許可するネットワークインタフェースへの接続を有効にします (セクション5.1.12.1「接続インタフェース」 を参照)。

• SESSION_VARIABLES_ADMIN (MySQL 8.0.14 で追加)

  ほとんどのシステム変数では、セッション値の設定に特別な権限は必要なく、すべてのユーザーが現在のセッションに影響を与えることができます。 一部のシステム変数では、セッション値を設定すると、現在のセッションの外部に影響を与える可能性があるため、操作が制限されます。 これらの場合、SESSION_VARIABLES_ADMIN 権限により、ユーザーはセッション値を設定できます。

  システム変数が制限されていて、セッション値を設定するために特別な権限が必要な場合、変数の説明にその制限が示されます。 例として、binlog_format、sql_log_bin および sql_log_off があります。

  SESSION_VARIABLES_ADMIN が追加された MySQL 8.0.14 より前は、SYSTEM_VARIABLES_ADMIN または SUPER 権限を持つユーザーのみが制限付きセッションシステム変数を設定できます。

  SESSION_VARIABLES_ADMIN 権限は、SYSTEM_VARIABLES_ADMIN および SUPER 権限のサブセットです。 これらの権限のいずれかを持つユーザーは、制限付きセッション変数の設定も許可され、効果的には SESSION_VARIABLES_ADMIN を意味するため、SESSION_VARIABLES_ADMIN を明示的に付与する必要はありません。

  セクション5.1.9.1「システム変数権限」も参照してください。

• SET_USER_ID

  ビューまたはストアドプログラムの実行時に有効な承認 ID を設定できるようにします。 この権限を持つユーザーは、ビューまたはストアドプログラムの DEFINER 属性として任意のアカウントを指定できます。

  MySQL 8.0.22 では、SET_USER_ID を使用して、(おそらく誤って) ストアドオブジェクトが孤立したり、現在孤立しているストアドオブジェクトを採用する原因となる操作を防ぐために設計されたセキュリティチェックをオーバーライドすることもできます。 詳細は、孤立したストアドオブジェクトを参照してください。

• SHOW_ROUTINE (MySQL 8.0.20 で追加)

  ユーザーがルーチン DEFINER として指定されていないストアドルーチン (ストアドプロシージャーおよびストアドファンクション) の定義およびプロパティーにアクセスできるようにします。 このアクセスには、次のものが含まれます:

  • INFORMATION_SCHEMA.ROUTINES テーブルの内容。

  • SHOW CREATE FUNCTION および SHOW CREATE PROCEDURE ステートメント。

  • SHOW FUNCTION CODE および SHOW PROCEDURE CODE ステートメント。

  • SHOW FUNCTION STATUS および SHOW PROCEDURE STATUS ステートメント。

  MySQL 8.0.20 より前では、ユーザーが定義しなかったルーチンの定義にアクセスするには、グローバルな SELECT 権限が必要です。これは非常に広範です。 8.0.20 の時点では、代わりに、ルーチン定義へのアクセスを許可するより制限されたスコープを持つ特権として SHOW_ROUTINE を付与できます。 (つまり、管理者は、それを必要としないユーザーからグローバル SELECT を廃棄し、かわりに SHOW_ROUTINE を付与できます。) これにより、アカウントは広範囲の権限を必要とせずにストアドルーチンをバックアップできます。

• SYSTEM_USER (MySQL 8.0.16 で追加)

  SYSTEM_USER 権限は、システムユーザーを通常のユーザーと区別します:

  • SYSTEM_USER 権限を持つユーザーはシステムユーザーです。

  • SYSTEM_USER 権限を持たないユーザーは通常のユーザーです。

  SYSTEM_USER 権限は、特定のユーザーが他の権限を適用できるアカウント、およびそのユーザーが他のアカウントから保護されているかどうかに影響します:

  • システムユーザーは、システムアカウントと通常アカウントの両方を変更できます。 つまり、通常のアカウントに対して特定の操作を実行する適切な権限を持つユーザーは、システムアカウントに対しても操作を実行するように SYSTEM_USER を所有することで有効になります。 システムアカウントは、通常のユーザーではなく、適切な権限を持つシステムユーザーのみが変更できます。

  • 適切な権限を持つ通常のユーザーは通常のアカウントを変更できますが、システムアカウントは変更できません。 通常のアカウントは、適切な権限を持つシステムユーザーと通常のユーザーの両方が変更できます。

  詳細は、セクション6.2.11「アカウントカテゴリ」を参照してください。

  SYSTEM_USER 権限によってシステムアカウントに付与される通常のアカウントによる変更からの保護は、mysql システムスキーマに対する権限を持つ通常のアカウントには適用されないため、そのスキーマの付与テーブルを直接変更できます。 完全保護のために、mysql スキーマ権限を通常のアカウントに付与しないでください。 通常アカウントによる操作からのシステムアカウントの保護を参照してください。

• SYSTEM_VARIABLES_ADMIN

  次の操作およびサーバーの動作に影響します:

  • 実行時のシステム変数の変更を有効にします:

    • SET GLOBAL および SET PERSIST を使用して、グローバルシステム変数に対するサーバー構成の変更を有効にします。

    • ユーザーが PERSIST_RO_VARIABLES_ADMIN も持っている場合、SET PERSIST_ONLY を使用してグローバルシステム変数に対するサーバー構成の変更を有効にします。

    • 特別な権限を必要とする制限付きセッションシステム変数の設定を有効にします。 実際には、SYSTEM_VARIABLES_ADMIN は、SESSION_VARIABLES_ADMIN を明示的に付与せずに SESSION_VARIABLES_ADMIN を暗黙的に意味します。

    セクション5.1.9.1「システム変数権限」も参照してください。

  • グローバルトランザクション特性の変更を有効にします (セクション13.3.7「SET TRANSACTION ステートメント」 を参照)。

• TABLE_ENCRYPTION_ADMIN (MySQL 8.0.16 で追加)

  table_encryption_privilege_check が有効な場合に、ユーザーがデフォルトの暗号化設定をオーバーライドできるようにします。スキーマおよび一般テーブルスペースの暗号化デフォルトの定義 を参照してください。

• VERSION_TOKEN_ADMIN

  バージョントークンのユーザー定義関数の実行を有効にします。 この権限は、version_tokens プラグインによって定義されます。セクション5.6.6「バージョントークン」 を参照してください。

• XA_RECOVER_ADMIN

  XA RECOVER ステートメントの実行を有効にします。セクション13.3.8.1「XA トランザクション SQL ステートメント」 を参照してください。

  MySQL 8.0 より前は、すべてのユーザーが XA RECOVER ステートメントを実行して、未処理の準備済 XA トランザクションの XID 値を検出できたため、XA トランザクションを開始したユーザー以外のユーザーによる XA トランザクションのコミットまたはロールバックが発生する可能性がありました。 MySQL 8.0 では、XA RECOVER は XA_RECOVER_ADMIN 権限を持つユーザーにのみ許可されます。これは、それを必要とする管理ユーザーにのみ付与されることが予想されます。 たとえば、XA アプリケーションがクラッシュし、ロールバックできるようにアプリケーションによって開始された未処理のトランザクションを検索する必要がある場合などです。 この権限要件により、ユーザーは自分以外の未処理の準備済 XA トランザクションの XID 値を検出できなくなります。 XA トランザクションを開始したユーザーが XID を認識しているため、XA トランザクションの通常のコミットまたはロールバックには影響しません。

権限付与のガイドライン

アカウントには必要な権限のみを付与することをお勧めします。 FILE 権限と管理権限の付与については十分に注意するようにしてください。

• FILE を使用すると、MySQL サーバーがサーバーホスト上で読み取ることができるファイルをデータベーステーブルに読み込むことができます。 これにはすべてのユーザーが読み取り可能なすべてのファイルと、サーバーのデータディレクトリ内のファイルが含まれます。 そのあと、SELECT を使用してそのテーブルにアクセスし、テーブルの内容をクライアントホストに送信することができます。

• GRANT OPTION を使用すると、ユーザーは他のユーザーに権限を付与できます。 異なる権限を持つ 2 人のユーザーが GRANT OPTION 権限を持っていれば、権限を組み合わせることができます。

• ALTER を使用すると、テーブルの名前を変更して権限システムを再変換できます。

• SHUTDOWN では、サーバーを終了することで、他のユーザーに対するサービスを完全に拒否できます。

• PROCESS を使用すると、パスワードを設定または変更するステートメントを含む、現在実行中のステートメントのプレーンテキストを表示できます。

• SUPER を使用すると、他のセッションを終了したり、サーバーの動作方法を変更できます。

• mysql システムデータベース自体に付与された権限を使用して、パスワードおよびその他のアクセス権限情報を変更できます:

  • パスワードは暗号化されて保管されているため、悪意のあるユーザーは単純にそのパスワードを見てプレーンテキストパスワードを知ることはできません。 ただし、mysql.user システムテーブルの authentication_string カラムへの書込みアクセス権を持つユーザーは、アカウントパスワードを変更し、そのアカウントを使用して MySQL サーバーに接続できます。

  • mysql システムデータベースに付与された INSERT または UPDATE を使用すると、ユーザーはそれぞれ権限を追加したり、既存の権限を変更できます。

  • mysql システムデータベース用の DROP を使用すると、ユーザーはリモート権限テーブルまたはデータベース自体を使用できます。

静的権限と動的権限

MySQL では、静的権限および動的権限がサポートされています:

• 静的権限はサーバーに組み込まれています。 これらは常にユーザーアカウントに付与でき、登録解除できません。

• 動的権限は、実行時に登録および登録解除できます。 これは可用性に影響: 登録されていない動的権限は付与できません。

たとえば、SELECT および INSERT 権限は静的で常に使用可能ですが、動的権限は、それを実装するコンポーネントが有効になっている場合にのみ使用可能になります。

このセクションの残りの部分では、動的権限が MySQL でどのように機能するかについて説明します。 この説明では、「「コンポーネント」」という用語を使用しますが、プラグインにも同様に適用されます。

注記

サーバー管理者は、動的権限を定義するサーバーコンポーネントに注意する必要があります。 MySQL ディストリビューションの場合、動的権限を定義するコンポーネントのドキュメントには、これらの権限が記載されています。

サードパーティコンポーネントでも動的権限を定義できます。管理者は、これらの権限を理解し、サーバー操作が競合または危険にさらされる可能性のあるコンポーネントをインストールしないでください。 たとえば、両方で同じ名前の権限が定義されている場合、あるコンポーネントが別のコンポーネントと競合します。 コンポーネント開発者は、コンポーネント名に基づいて接頭辞を持つ権限名を選択することで、この発生の可能性を減らすことができます。

サーバーは、登録された動的権限のセットをメモリー内に内部的に保持します。 サーバーの停止時に登録解除が発生します。

通常、動的権限を定義するコンポーネントは、インストール時に初期化シーケンス中にそれらを登録します。 アンインストール時に、コンポーネントは登録されている動的権限を登録解除しません。 (これは現在の演習であり、要件ではありません。 つまり、コンポーネントは、登録した権限でいつでも登録解除できますが、できません。)

すでに登録されている動的権限を登録しようとしても、警告やエラーは発生しません。 次の一連のステートメントについて考えてみます:

INSTALL COMPONENT 'my_component';
UNINSTALL COMPONENT 'my_component';
INSTALL COMPONENT 'my_component';

最初の INSTALL COMPONENT ステートメントでは、コンポーネント my_component によって定義された権限は登録されますが、UNINSTALL COMPONENT では登録解除されません。 2 番目の INSTALL COMPONENT ステートメントでは、登録するコンポーネント権限はすでに登録されていますが、警告やエラーは発生しません。

動的権限はグローバルレベルでのみ適用されます。 サーバーは、ユーザーアカウントへの動的権限の現在の割当てに関する情報を mysql.global_grants システムテーブルに格納します:

• サーバーは、(--skip-grant-tables オプションが指定されていないかぎり) サーバーの起動時に global_grants で指定された権限を自動的に登録します。

• GRANT および REVOKE ステートメントによって、global_grants の内容が変更されます。

• global_grants にリストされている動的権限割当ては永続的です。 サーバーの停止時には削除されません。

例: 次のステートメントは、レプリカに対するレプリケーション (グループレプリケーションを含む) の制御およびシステム変数の変更に必要な権限をユーザー u1 に付与します:

GRANT REPLICATION_SLAVE_ADMIN, GROUP_REPLICATION_ADMIN, BINLOG_ADMIN
ON *.* TO 'u1'@'localhost';

付与された動的権限は、SHOW GRANTS ステートメントおよび INFORMATION_SCHEMA USER_PRIVILEGES テーブルからの出力に表示されます。

グローバルレベルの GRANT および REVOKE の場合、静的として認識されない名前付き権限は、現在登録されている動的権限のセットに対してチェックされ、見つかった場合は付与されます。 それ以外の場合は、不明な権限識別子を示すエラーが発生します。

GRANT および REVOKE の場合、グローバルレベルの ALL [PRIVILEGES]の意味には、すべての静的グローバル権限と、現在登録されているすべての動的権限が含まれます:

• グローバルレベルの GRANT ALL では、すべての静的グローバル権限および現在登録されているすべての動的権限が付与されます。 GRANT ステートメントの実行後に登録された動的権限は、どのアカウントにも遡及的に付与されません。

• グローバルレベルの REVOKE ALL は、付与されているすべての静的グローバル権限および付与されているすべての動的権限を取り消します。

FLUSH PRIVILEGES ステートメントは、動的権限割当てのために global_grants テーブルを読み取り、そこで見つかった未登録の権限を登録します。

MySQL Server によって提供される動的権限および MySQL ディストリビューションに含まれるコンポーネントの詳細は、セクション6.2.2「MySQL で提供される権限」 を参照してください。

SUPER から動的権限へのアカウントの移行

MySQL 8.0 では、以前に SUPER 権限を必要としていた多くの操作も、より限定された有効範囲の動的権限に関連付けられています。 (これらの権限の詳細は、セクション6.2.2「MySQL で提供される権限」 を参照してください。) このような各操作は、SUPER ではなく、関連付けられた動的権限を付与することで、アカウントに対して許可できます。 この変更により、DBA は SUPER の付与を回避し、ユーザー権限を許可されている操作により厳密に調整できるため、セキュリティが向上します。 SUPER は非推奨になりました。将来のバージョンの MySQL で削除される予定です。

SUPER の削除が発生すると、SUPER を付与されたアカウントが適切な動的権限に移行されないかぎり、以前は SUPER を必要としていた操作は失敗します。 次の手順を使用して、SUPER を削除する前にアカウントの準備が整うようにその目標を達成します:

1. 次のクエリーを実行して、SUPER が付与されているアカウントを識別します:

   SELECT GRANTEE FROM INFORMATION_SCHEMA.USER_PRIVILEGES
   WHERE PRIVILEGE_TYPE = 'SUPER';

2. 前述のクエリーで識別されたアカウントごとに、SUPER が必要な操作を決定します。 次に、これらの操作に対応する動的権限を付与し、SUPER を取り消します。

   たとえば、バイナリログのパージおよびシステム変数の変更に'u1'@'localhost'で SUPER が必要な場合、次のステートメントによってアカウントに必要な変更が加えられます:

   GRANT BINLOG_ADMIN, SYSTEM_VARIABLES_ADMIN ON *.* TO 'u1'@'localhost';
   REVOKE SUPER ON *.* FROM 'u1'@'localhost';

   適用可能なすべてのアカウントを変更した後、最初のステップの INFORMATION_SCHEMA クエリーで空の結果セットが生成されます。