Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Modèle de privilège basé sur les rôles pour RDS for MySQL À compter de RDS for MySQL version 8.0.36, vous ne pouvez pas modifier les tables dans la base de données `mysql` directement. En particulier, vous ne pouvez pas créer d’utilisateurs de base de données en effectuant des opérations du langage de manipulation des données (DML) sur les tables `grant`. Vous utilisez plutôt des instructions de gestion de compte MySQL telles que `CREATE USER`, `GRANT`, et `REVOKE` pour accorder des privilèges basés sur les rôles aux utilisateurs. Vous ne pouvez pas non plus créer d'autres types d'objets tels que des procédures stockées dans la base de données `mysql`. Vous pouvez toujours interroger les tables `mysql`. Si vous utilisez la réplication des journaux binaires, les modifications apportées directement aux tables `mysql` de l’instance de base de données source ne sont pas répliquées sur le cluster cible. Dans certains cas, votre application peut utiliser des raccourcis pour créer des utilisateurs ou d'autres objets en les insérant dans les tables `mysql`. Le cas échéant, modifiez le code de votre application pour utiliser les instructions correspondantes telles que `CREATE USER`. Pour exporter des métadonnées pour les utilisateurs de bases de données pendant la migration à partir d’une base de données MySQL externe, utilisez une des méthodes suivantes : + Utilisez l’utilitaire de vidage d’instance de MySQL Shell avec un filtre pour exclure les utilisateurs, les rôles et les autorisations. L’exemple suivant illustre la syntaxe de commande à utiliser. Vérifiez que `outputUrl` est vide. ``` mysqlsh user@host -- util.dumpInstance(outputUrl,{excludeSchemas:['mysql'],users: true}) ``` Pour plus d’informations, consultez les sections [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html) dans le manuel de référence MySQL. + Utilisez l’utilitaire client `mysqlpump`. Cet exemple inclut toutes les tables à l’exception des tables de la base de données système `mysql`. Elle comprend également les instructions `CREATE USER` et `GRANT` pour reproduire tous les utilisateurs MySQL de la base de données migrée. ``` mysqlpump --exclude-databases=mysql --users ``` L’utilitaire client `mysqlpump` n’est plus disponible avec MySQL 8.4. Utilisez à la place `mysqldump`. Pour simplifier la gestion des autorisations pour de nombreux utilisateurs ou applications, vous pouvez utiliser l'instruction `CREATE ROLE` pour créer un rôle doté d'un ensemble d'autorisations. Vous pouvez ensuite utiliser les instructions `GRANT` et `SET ROLE`, et la fonction `current_role` pour attribuer des rôles à des utilisateurs ou des applications, changer le rôle actuel et vérifier les rôles en vigueur. Pour plus d'informations sur le système d'autorisations basé sur les rôles dans MySQL 8.0, consultez [Utilisation de rôles](https://dev.mysql.com/doc/refman/8.0/en/roles.html) dans le manuel de référence MySQL. **Important** Nous vous recommandons vivement de ne pas avoir recours au rôle d’utilisateur principal directement dans vos applications. Au lieu de cela, respectez la bonne pratique qui consiste à avoir recours à un utilisateur de base de données doté des privilèges minimum requis pour votre application. À compter de la version 8.0.36, RDS for MySQL inclut un rôle spécial doté de tous les privilèges suivants. Ce rôle est nommé `rds_superuser_role`. Ce rôle est déjà accordé à l’utilisateur administratif principal de chaque instance de base de données. Le rôle `rds_superuser_role` inclut les privilèges suivants pour tous les objets de base de données : + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` La définition du rôle inclut également `WITH GRANT OPTION` afin qu'un utilisateur administratif puisse accorder ce rôle à d'autres utilisateurs. En particulier, l’administrateur doit accorder tous les privilèges nécessaires à la réplication des journaux binaires avec le cluster MySQL comme cible. **Astuce** Pour voir tous les détails des autorisations, utilisez l’instruction suivante. ``` SHOW GRANTS FOR rds_superuser_role@'%'; ``` Lorsque vous accordez l’accès à l’aide de rôles dans RDS for MySQL versions 8.0.36 et ultérieures, vous activez également le rôle à l’aide de l’instruction `SET ROLE role_name` ou `SET ROLE ALL`. L’exemple suivant montre comment procéder. Remplacez le nom de rôle approprié par `CUSTOM_ROLE`. ``` # Grant role to user mysql> GRANT CUSTOM_ROLE TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the CUSTOM_ROLE role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +--------------------------------------------------+ | CURRENT_ROLE() | +--------------------------------------------------+ | `CUSTOM_ROLE`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+ ```