🚫
【Aurora MySQL】マスターユーザーが使用できない権限まとめ
はじめに
Aurora MySQL でデータベース作成時、デフォルトのマスターユーザーが作成されますが、このユーザーには使用を禁止されている権限があります。
あらかじめ使用できない権限があることを把握しておけば、作業の手戻りが減り、素早く適切な対処を取ることができます。
(例) dumpファイルインポート時のエラー
例えば、既存の DB から dump したファイルを Aurora にインポートしようとするとエラーになる場合があります。
dump ファイルにトリガー設定などを含んでいる場合、インポート時に SUPER 権限が要求されますが、Aurora では禁止されている権限なので、エラーになってしまいます。
ERROR 1227 (42000) at line 2077: Access denied; you need (at least one of) the SUPER privilege(s) for this operation
また、Aurora マスターユーザーに SUPER 権限を付与する方法はありません。
dump ファイル作成時にトリガー設定などを除去しておき、インポート後に手動で設定するようにしましょう。
Aurora マスターユーザーアカウントで使用できない権限
以下では、Aurora MySQL バージョン3(MySQL 8.0)とバージョン2(MySQL 5.7) について、それぞれマスターユーザーアカウントで使用できない権限についてまとめてみました。
何かの参考になれば幸いです。
◼️ MySQL 8.0 静的権限の一覧と Aurora MySQL v3 および v2 マスターアカウントでの使用可否リスト(USAGE 権限を除く)
権限 | 説明 | v3 | v2 |
---|---|---|---|
ALL [PRIVILEGES] | すべての権限を一度に付与するシノニムであり、個別に権限を設定する代わりに全権限を付与する際に使用されます。これにより、ユーザーはすべての操作を行うことができますが、Aurora MySQLでは、個別の権限設定がより細かく管理されているため、ALL 権限はサポートされていません。 | ❌ | ❌ |
ALTER | テーブルの変更を行う権限 | ○ | ○ |
ALTER ROUTINE | ストアドルーチンの変更を行う権限 | ○ | ○ |
CREATE | データベース、テーブル、インデックスの作成を行う権限 | ○ | ○ |
CREATE ROLE | ロールの作成を行う権限 | ○ | なし(※) |
CREATE ROUTINE | ストアドルーチンの作成を行う権限 | ○ | ○ |
CREATE TABLESPACE | テーブルスペースの作成を行う権限。MySQL でのテーブルスペースは、ストレージの管理やパフォーマンスの最適化に使用され、特に大規模なデータベースでの分割ストレージや専用ストレージの割り当てが可能になります。例: CREATE TABLESPACE my_space ADD DATAFILE 'myfile.ibd'; | ❌ | ❌ |
CREATE TEMPORARY TABLES | 一時テーブルの作成を行う権限 | ○ | ○ |
CREATE USER | 新しいユーザーの作成を行う権限 | ○ | ○ |
CREATE VIEW | ビューの作成を行う権限 | ○ | ○ |
DELETE | テーブルからデータを削除する権限 | ○ | ○ |
DROP | データベース、テーブル、ビューの削除を行う権限 | ○ | ○ |
DROP ROLE | ロールの削除を行う権限 | ○ | なし(※) |
EVENT | イベントの作成と削除を行う権限 | ○ | ○ |
EXECUTE | ストアドルーチンの実行を行う権限 | ○ | ○ |
FILE | サーバーホスト上でのファイルの読み書き権限。データベースサーバーのファイルシステムにアクセスし、ファイルの読み込みや書き込みを行うことができます。これにより、LOAD DATA INFILE や SELECT ... INTO OUTFILE コマンドが利用可能になります。例: LOAD DATA INFILE '/path/to/file.csv' INTO TABLE my_table; | ❌ | ❌ |
GRANT OPTION | 他のユーザーに権限を付与する権限。この権限を持つユーザーは、自分が持っている権限を他のユーザーに付与することができます。これにより、権限の管理や再配布が可能になりますが、Aurora MySQLでは、管理者権限が限定的であるため、GRANT OPTION がサポートされていません。例: GRANT SELECT ON mydb.* TO 'user'@'localhost' WITH GRANT OPTION; | ❌ | ○ |
INDEX | テーブルのインデックスを作成および削除する権限 | ○ | ○ |
INSERT | テーブルにデータを挿入する権限 | ○ | ○ |
LOCK TABLES | テーブルのロックを行う権限 | ○ | ○ |
PROCESS | サーバー上のプロセスに関する情報を表示する権限 | ○ | ○ |
PROXY | 他のユーザーとしてのアクセスを可能にする権限。プロキシユーザーは、元のユーザーとしての権限を持ちつつ、代理として操作を行うことができます。これにより、ユーザーの代理アクセスが可能になります。例: GRANT PROXY ON 'proxy_user'@'localhost' TO 'original_user'@'localhost'; | ❌ | ❌ |
REFERENCES | 外部キーを使用する権限 | ○ | ○ |
RELOAD | サーバーのリロード操作を行う権限 | ○ | ○ |
REPLICATION CLIENT | レプリケーションに関する情報を表示する権限 | ○ | ○ |
REPLICATION SLAVE | スレーブサーバーの設定を行う権限 | ○ | ○ |
SELECT | テーブルからデータを選択する権限 | ○ | ○ |
SHOW DATABASES | サーバー上のデータベースを表示する権限 | ○ | ○ |
SHOW VIEW | ビューの定義を表示する権限 | ○ | ○ |
SHUTDOWN | MySQL サーバーのシャットダウンを行う権限。この権限を持つユーザーは、サーバーを完全に停止することができます。サーバーの停止や再起動が行え、管理者がサーバーをメンテナンスモードにする際に使用します。例: SHUTDOWN; | ❌ | ❌ |
SUPER | システム全体の特権操作を行う権限。例えば、スレーブのリセットやリカバリ操作、トランザクションの強制終了など、通常の権限ではできない管理操作を行うことができます。これにより、システムの管理やトラブルシューティングが行えます。例: KILL QUERY <query_id>; | ❌ | ❌ |
TRIGGER | トリガーの作成と削除を行う権限 | ○ | ○ |
UPDATE | テーブル内のデータを更新する権限 | ○ | ○ |
※ MySQL 5.7 では扱われていない権限のため「なし」と表記。
MySQL 公式ドキュメント ▼
おまけ
Aurora のフルマネージドの特性を踏まえると、権限の制限にも納得できそうですね。
- セキュリティと安定性の確保:
- SHUTDOWN: データベースのシャットダウンは、サービスの中断やデータ損失を防ぐため、ユーザーには与えられていません。AWSがこれを管理することで、データベースの可用性と信頼性を確保しています。
- SUPER: システム全体に対する広範な操作が可能なこの権限は、データベースのセキュリティを脅かす可能性があるため、AWSが制御します。
- リソース管理と制御:
- CREATE TABLESPACE: テーブルスペースの作成や管理は、Auroraのストレージシステムに依存しており、AWSが自動で管理するため、ユーザーに対してこの権限を制限しています。
- FILE: ファイルシステムへのアクセスは、AWSの内部管理に含まれており、ユーザーがサーバーのファイルに直接アクセスすることはできません。
- 運用の簡素化:
- PROXY: 他のユーザーの代わりに接続するこの権限は、複雑なユーザー管理やセキュリティ問題を引き起こす可能性があり、AWSがこの管理を担当します。
- GRANT OPTION: 権限の付与を制御することで、予期しないセキュリティリスクや権限の乱用を防ぐため、AWSが管理します。
Discussion