MariaDBのデータベースロールベースのアクセス制御を実装するためのヒントとコツ

MariaDB> GRANT CREATE, ALTER, DROP, CREATE VIEW, CREATE ROUTINE, INDEX, TRIGGER, REFERENCES ON app.* to app_structure;

データ操作言語（DML）の権限をapp_writerロールに付与します：

MariaDB> GRANT INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES app.* to app_writer;

app_readerロールにデータクエリ言語（DQL）の権限を付与します：

MariaDB> GRANT SELECT, LOCK TABLES, SHOW VIEW app.* to app_reader;

最後に、上記のすべての役割をapp_developerに割り当てることができます。app_developerはスキーマを完全に制御する必要があります。

MariaDB> GRANT app_structure TO app_developer;
MariaDB> GRANT app_reader TO app_developer;
MariaDB> GRANT app_writer TO app_developer;

ロールの準備が整いました。これで、app_developerロールを持つデータベースユーザーを作成できます：

MariaDB> CREATE USER 'michael'@'192.168.0.%' IDENTIFIED BY 'passw0rdMMMM';
MariaDB> GRANT app_developer TO 'michael'@'192.168.0.%';
MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';

Michaelはapp_deleloperとapp_readerの役割に属しているため、デフォルトの役割として最低の権限を割り当てて、不要な人為的ミスから彼を保護することもできます。

MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';

ロールを使用することの良い点は、データベースユーザーから実際の特権を隠すことができることです。ログインしたばかりの次のデータベースユーザーについて考えてみます。

MariaDB> SELECT user();
+----------------------+
| user()               |
+----------------------+
| [email protected] |
+----------------------+

SHOW GRANTSを使用して特権を取得しようとすると、Michaelは次のように表示されます。

MariaDB> SHOW GRANTS FOR 'michael'@'192.168.0.%';
+----------------------------------------------------------------------------------------------------------------+
| Grants for [email protected]                                                                                   |
+----------------------------------------------------------------------------------------------------------------+
| GRANT `app_developer` TO `michael`@`localhost`                                                                 |
| GRANT USAGE ON *.* TO `michael`@`localhost` IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
+----------------------------------------------------------------------------------------------------------------+

そして、Michaelがapp_developerの特権を検索しようとすると、次のエラーが表示されます：

MariaDB> SHOW GRANTS FOR FOR app_developer;
ERROR 1044 (42000): Access denied for user 'michael'@'localhost' to database 'mysql'

このトリックにより、DBAは、ユーザーが属する論理グループのみを表示し、それ以上は表示できません。ユーザーは実際に割り当てられている特権を知らないため、この側面から攻撃ベクトルを減らすことができます。

MariaDBでデフォルトの役割を強制する

デフォルトの役割を適用することにより、データベースユーザーを最初のレイヤーで偶発的な人為的ミスから保護できます。たとえば、app_developerロールが付与されているユーザーMichaelについて考えてみます。ここで、app_developerロールは、以下に示すように、app_strucutre、app_writer、およびapp_readerロールのスーパーセットです。

Michaelはapp_deleloperロールに属しているため、最低の権限を設定することもできます偶発的なデータ変更から彼を保護するためのデフォルトの役割として：

MariaDB> GRANT app_reader TO 'michael'@'192.168.0.%';
MariaDB> SET DEFAULT ROLE app_reader FOR 'michael'@'192.168.0.%';

ユーザー「michael」については、ログインすると次のように表示されます。

MariaDB> SELECT user(),current_role();
+-------------------+----------------+
| user()            | current_role() |
+-------------------+----------------+
| [email protected] | app_reader     |
+-------------------+----------------+

デフォルトの役割はapp_readerです。これは、「app」と呼ばれるデータベースのread_only特権です。現在のユーザーは、SET ROLE機能を使用して、該当するロールを切り替えることができます。マイケルについては、次のステートメントを使用して別の役割に切り替えることができます。

MariaDB> SET ROLE app_developer;

この時点で、app_developerはapp_writerとapp_structureのスーパーセットであるため、Michaelはデータベース'app'に書き込むことができるはずです。現在のユーザーが使用できるロールを確認するには、information_schema.applicable_rolesテーブルにクエリを実行します。

MariaDB> SELECT * FROM information_schema.applicable_roles;
+-------------------+---------------+--------------+------------+
| GRANTEE           | ROLE_NAME     | IS_GRANTABLE | IS_DEFAULT |
+-------------------+---------------+--------------+------------+
| [email protected] | app_developer | NO           | NO         |
| app_developer     | app_writer    | NO           | NULL       |
| app_developer     | app_reader    | NO           | NULL       |
| app_developer     | app_structure | NO           | NULL       |
| [email protected] | app_reader    | NO           | YES        |
+-------------------+---------------+--------------+------------+

このように、ユーザーのプライマリロールを設定します。プライマリロールは、特定のユーザーに対して可能な限り低い特権にすることができます。ユーザーは、データベースサーバーに対して危険なアクティビティを実行する前に、別の特権ロールに切り替えることにより、アクティブなロールについて同意する必要があります。

MariaDBでのロールマッピング

MariaDBは、mysql.roles_mappingと呼ばれるロールマッピングテーブルを提供します。マッピングにより、ユーザーとその役割の相関関係、および役割が別の役割にどのようにマッピングされるかを簡単に理解できます。

MariaDB> SELECT * FROM mysql.roles_mapping;
+-------------+-------------------+------------------+--------------+
| Host        | User              | Role             | Admin_option |
+-------------+-------------------+------------------+--------------+
| localhost   | root              | app_developer    | Y            |
| localhost   | root              | app_writer       | Y            |
| localhost   | root              | app_reader       | Y            |
| localhost   | root              | app_structure    | Y            |
|             | app_developer     | app_structure    | N            |
|             | app_developer     | app_reader       | N            |
|             | app_developer     | app_writer       | N            |
| 192.168.0.% | michael           | app_developer    | N            |
| localhost   | michael           | app_developer    | N            |
| localhost   | root              | mysqldump_backup | Y            |
| localhost   | dump_user1        | mysqldump_backup | N            |
| localhost   | root              | mariadb_backup   | Y            |
| localhost   | mariabackup_user1 | mariadb_backup   | N            |
+-------------+-------------------+------------------+--------------+

上記の出力から、ホストのないユーザーは基本的にロールに対するロールであり、管理ユーザー（Admin_option =Y）も作成されたロールに自動的に割り当てられていることがわかります。作成されたロールのリストを取得するには、MySQLユーザーテーブルをクエリします。

MariaDB> SELECT user FROM mysql.user WHERE is_role = 'Y';
+------------------+
| User             |
+------------------+
| app_developer    |
| app_writer       |
| app_reader       |
| app_structure    |
| mysqldump_backup |
| mariadb_backup   |
+------------------+