Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 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. # GRANT Définit les autorisations d’accès pour un utilisateur ou un rôle. Les autorisations incluent les options d’accès telles que pouvoir lire les données des tables et des vues, écrire des données, créer et supprimer des tables. Utilisez cette commande pour accorder des autorisations spécifiques pour une table, une base de données, un schéma, une fonction, une procédure, un langage ou une colonne. Pour révoquer les autorisations d’un objet de base de données, utilisez la commande [REVOKE](r_REVOKE.md). Les autorisations incluent également les options d’accès producteur suivantes aux unités de partage des données : + Octroi d’accès à l’unité de partage des données aux espaces de noms et comptes consommateur. + Octroi de l’autorisation de modifier une unité de partage des données en y ajoutant ou supprimant des objets. + Octroi de l’autorisation de partager une unité de partage des données en y ajoutant ou supprimant des espaces de noms consommateur. Les options d’accès consommateur à l’unité de partage des données sont les suivantes : + Octroi aux utilisateurs d’un accès complet aux bases de données créées à partir d’une unité de partage des données, ou à des schémas externes pointant vers de telles bases de données. + Octroi aux utilisateurs des autorisations de niveau objet sur les bases de données créées à partir d’une unité de partage des données, comme cela est possible pour les objets de base de données locaux. Pour accorder ce niveau d’autorisation, vous devez utiliser la clause WITH PERMISSIONS lors de la création d’une base de données à partir de l’unité de partage des données. Pour plus d’informations, consultez [CREATE DATABASE](r_CREATE_DATABASE.md). Pour plus d’informations sur les autorisations liées aux unités de partage des données, consultez [Autorisations que vous pouvez accorder aux unités de partages des données](permissions-datashares.md). Les autorisations incluent également le catalogue d'autorisations fédérées Amazon Redshift suivant : + Octroi d'autorisations au niveau de la table aux utilisateurs et aux rôles. + Octroi d'autorisations détaillées au niveau des colonnes sur les tables, les vues et les vues matérialisées. + Octroi d'autorisations étendues aux utilisateurs et aux rôles. + Octroi d'autorisations au niveau de la base de données sur le catalogue d'autorisations fédérées Amazon Redshift. Pour plus d'informations sur la gestion des autorisations sur le catalogue des autorisations fédérées Amazon Redshift, consultez. [Gestion du contrôle d'accès sur le catalogue d'autorisations fédérées Amazon RedshiftAccorder/Révoquer](federated-permissions-managing-access.md) [Pour plus d'informations sur les grant/revoke syntaxes prises en charge par Amazon Redshift Federated Permissions Catalog, consultez Grant/Revoke.](https://docs.aws.amazon.com/redshift/latest/dg/federated-permissions-managing-access.html#federated-permissions-managing-access-grant-revoke) Les autorisations incluent également le privilège CONNECT pour les utilisateurs AWS IAM Identity Center fédérés. Ce privilège permet aux administrateurs de contrôler l'accès des utilisateurs par le biais d'autorisations détaillées dans chaque groupe de travail ou cluster Amazon Redshift où les autorisations fédérées Amazon Redshift sont activées. L'administrateur Amazon Redshift peut spécifier quels utilisateurs ou groupes AWS IAM Identity Center fédérés ont accès pour se connecter directement au groupe de travail Amazon Redshift, ce qui permet de contrôler avec précision l'accès des utilisateurs à chaque groupe de travail ou cluster. AWS IAM Identity Center Vous pouvez également attribuer des rôles pour gérer les autorisations de la base de données et contrôler ce que les utilisateurs peuvent faire par rapport à vos données. En définissant des rôles et en les attribuant à des utilisateurs, vous pouvez limiter les actions que ces derniers peuvent entreprendre, par exemple en les limitant aux commandes CREATE TABLE et INSERT. Pour plus d’informations sur la commande CREATE ROLE, consultez [CREATE ROLE](r_CREATE_ROLE.md). Amazon Redshift dispose de certains rôles définis par le système que vous pouvez également utiliser pour accorder des autorisations spécifiques à vos utilisateurs. Pour plus d’informations, consultez [Rôles définis par le système Amazon Redshift](r_roles-default.md). Vous pouvez accorder les autorisations GRANT ou REVOKE USAGE sur un schéma externe à des utilisateurs et des groupes d’utilisateurs de base de données qui utilisent la syntaxe ON SCHEMA. Lorsque vous utilisez ON EXTERNAL SCHEMA avec AWS Lake Formation, vous pouvez uniquement ACCORDER et RÉVOQUER des autorisations pour un rôle Gestion des identités et des accès AWS (IAM). Pour connaître la liste des autorisations, reportez-vous à la syntaxe. Pour les procédures stockées, la seule autorisation que vous pouvez accorder est EXECUTE. Vous ne pouvez pas exécuter GRANT (sur une ressource externe) dans un bloc de transaction (BEGIN ... END). Pour plus d’informations sur les transactions, consultez [Niveaux d’isolement dans Amazon Redshift](c_serial_isolation.md). Pour connaître les autorisations accordées aux utilisateurs pour une base de données, utilisez [HAS\$1DATABASE\$1PRIVILEGE](r_HAS_DATABASE_PRIVILEGE.md). Pour connaître les autorisations accordées aux utilisateurs pour un schéma, utilisez [HAS\$1SCHEMA\$1PRIVILEGE](r_HAS_SCHEMA_PRIVILEGE.md). Pour connaître les autorisations accordées aux utilisateurs pour une table, utilisez [HAS\$1TABLE\$1PRIVILEGE](r_HAS_TABLE_PRIVILEGE.md). ## Syntaxe ``` GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | REFERENCES | ALTER | TRUNCATE } [,...] | ALL [ PRIVILEGES ] } ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | TEMPORARY | TEMP | ALTER } [,...] | ALL [ PRIVILEGES ] } ON DATABASE db_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } ON SCHEMA schema_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { FUNCTION function_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL FUNCTIONS IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON { PROCEDURE procedure_name ( [ [ argname ] argtype [, ...] ] ) [, ...] | ALL PROCEDURES IN SCHEMA schema_name [, ...] } TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT USAGE ON LANGUAGE language_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } ON COPY JOB job_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } ON TEMPLATE [database_name.][schema_name.]template_name [,...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Octroi d’autorisations au niveau des colonnes pour les tables Voici la syntaxe des autorisations de niveau colonne sur les tables et les vues Amazon Redshift. ``` GRANT { { SELECT | UPDATE } ( column_name [, ...] ) [, ...] | ALL [ PRIVILEGES ] ( column_name [,...] ) } ON { [ TABLE ] table_name [, ...] } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Octroi d’autorisations à ASSUMEROLE Voici la syntaxe des autorisations ASSUMEROLE accordées aux utilisateurs et aux groupes ayant un rôle spécifié. Pour commencer à utiliser le privilège ASSUMEROLE, consultez [Notes d’utilisation pour l’octroi de l’autorisation ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ``` GRANT ASSUMEROLE ON { 'iam_role' [, ...] | default | ALL } TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] FOR { ALL | COPY | UNLOAD | EXTERNAL FUNCTION | CREATE MODEL } [, ...] ``` ### Octroi d’autorisations pour l’intégration de Redshift Spectrum avec Lake Formation La syntaxe suivante s’applique à l’intégration de Redshift Spectrum à Lake Formation. ``` GRANT { SELECT | ALL [ PRIVILEGES ] } ( column_list ) ON EXTERNAL TABLE schema_name.table_name TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] GRANT { { SELECT | ALTER | DROP | DELETE | INSERT } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL TABLE schema_name.table_name [, ...] TO { { IAM_ROLE iam_role } [, ...] | PUBLIC } [ WITH GRANT OPTION ] GRANT { { CREATE | ALTER | DROP } [, ...] | ALL [ PRIVILEGES ] } ON EXTERNAL SCHEMA schema_name [, ...] TO { IAM_ROLE iam_role } [, ...] [ WITH GRANT OPTION ] ``` ### Octroi d’autorisations d’unité de partage des données **Autorisations d’unité de partage des données côté producteur** La syntaxe suivante permet d’utiliser GRANT pour accorder des autorisations ALTER ou SHARE à un utilisateur ou à un rôle. L’utilisateur peut modifier l’unité de partage des données avec l’autorisation ALTER, ou en autoriser l’utilisation à un consommateur avec l’autorisation SHARE. ALTER et SHARE sont les seules autorisations que vous pouvez accorder aux utilisateurs et aux rôles sur une unité de partage des données. ``` GRANT { ALTER | SHARE } ON DATASHARE datashare_name TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` Voici la syntaxe d’utilisation de GRANT pour les autorisations d’unité de partage des données sur Amazon Redshift. Vous accordez l’accès à une unité de partage des données à un consommateur en utilisant l’autorisation USAGE. Vous ne pouvez pas accorder cette autorisation à des utilisateurs ou à des groupes d’utilisateurs. Cette autorisation ne prend pas non plus en charge WITH GRANT OPTION pour l’instruction GRANT. Seuls les utilisateurs ou groupes d’utilisateurs disposant de l’autorisation SHARE qui leur a été préalablement accordée POUR l’unité de partage des données peuvent exécuter ce type d’instruction GRANT. ``` GRANT USAGE ON DATASHARE datashare_name TO NAMESPACE 'namespaceGUID' | ACCOUNT 'accountnumber' [ VIA DATA CATALOG ] ``` L’exemple suivant montre comment autoriser l’utilisation d’une unité de partage des données à un compte Lake Formation. ``` GRANT USAGE ON DATASHARE salesshare TO ACCOUNT '123456789012' VIA DATA CATALOG; ``` **Autorisations d’unité de partage des données côté consommateur** Voici la syntaxe des autorisations d’utilisation d’unité de partage des données GRANT sur une base de données spécifique ou un schéma créé à partir d’une unité de partage des données. Les autorisations supplémentaires requises pour que les consommateurs puissent accéder à une base de données créée à partir d’une unité de partage des données varient selon que la commande CREATE DATABASE utilisée pour créer la base de données à partir de l’unité de partage des données utilisait ou non la clause WITH PERMISSIONS. Pour plus d’informations sur la commande CREATE DATABASE et la clause WITH PERMISSIONS, consultez [CREATE DATABASE](r_CREATE_DATABASE.md). **Bases de données créées sans utiliser la clause WITH PERMISSIONS** Lorsque vous accordez l’accès USAGE sur une base de données créée à partir d’une unité de partage des données sans utiliser la clause WITH PERMISSIONS, vous n’avez pas besoin d’accorder des autorisations séparément sur les objets de la base de données partagée. Les entités autorisées à utiliser les bases de données créées à partir d’unités de partage des données sans la clause WITH PERMISSIONS ont automatiquement accès à tous les objets de la base de données. **Bases de données créées avec la clause WITH PERMISSIONS** Lorsque vous accordez l’accès USAGE à une base de données dont la base de données partagée a été créée à partir d’une unité de partage des données utilisant la clause WITH PERMISSIONS, les identités côté consommateur doivent toujours bénéficier des autorisations appropriées pour les objets de base de données de la base de données partagée afin de pouvoir y accéder, tout comme vous accorderiez des autorisations pour les objets de base de données locale. Pour accorder des autorisations aux objets d’une base de données créée à partir d’une unité de partage des données, utilisez la syntaxe en trois parties `database_name.schema_name.object_name`. Pour accorder des autorisations aux objets d’un schéma externe pointant vers un schéma partagé au sein de la base de données partagée, utilisez la syntaxe en deux parties `schema_name.object_name`. ``` GRANT USAGE ON { DATABASE shared_database_name [, ...] | SCHEMA shared_schema} TO { username | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Octroi d’autorisations étendues Les autorisations étendues vous permettent d’accorder des autorisations à un utilisateur ou à un rôle sur tous les objets d’un type au sein d’une base de données ou d’un schéma. Les utilisateurs et les rôles dotés d’autorisations étendues ont les autorisations spécifiées sur tous les objets actuels et futurs de la base de données ou du schéma. Vous pouvez consulter l’étendue des autorisations délimitées au niveau de la base de données dans [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Vous pouvez consulter l’étendue des autorisations délimitées au niveau du schéma dans [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md). Pour plus d’informations sur les autorisations étendues, consultez [Autorisations délimitées](t_scoped-permissions.md). La syntaxe suivante permet d’accorder des autorisations étendues aux utilisateurs et rôles. ``` GRANT { CREATE | USAGE | ALTER | DROP } [,...] | ALL [ PRIVILEGES ] } FOR SCHEMAS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { SELECT | INSERT | UPDATE | DELETE | DROP | ALTER | TRUNCATE | REFERENCES } [, ...] } | ALL [PRIVILEGES] } } FOR TABLES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name} [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR FUNCTIONS IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } FOR PROCEDURES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name | } [, ...] GRANT USAGE FOR LANGUAGES IN {DATABASE db_name} TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { CREATE | ALTER | DROP} [,...] | ALL [ PRIVILEGES ] } FOR COPY JOBS IN DATABASE db_name TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] GRANT { { ALTER | DROP | USAGE } [,...] | ALL [ PRIVILEGES ] } FOR TEMPLATES IN {SCHEMA schema_name [DATABASE db_name ] | DATABASE db_name } TO { username [ WITH GRANT OPTION ] | ROLE role_name } [, ...] ``` Notez que les autorisations étendues ne font pas de distinction entre les autorisations relatives aux fonctions et aux procédures. Par exemple, l’instruction suivante accorde à `bob` l’autorisation `EXECUTE` pour les fonctions et les procédures du schéma `Sales_schema`. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` ### Accorder des autorisations de machine learning Voici la syntaxe pour les autorisations des modèles de machine learning sur Amazon Redshift. ``` GRANT CREATE MODEL TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] GRANT { EXECUTE | ALL [ PRIVILEGES ] } ON MODEL model_name [, ...] TO { username [ WITH GRANT OPTION ] | ROLE role_name | GROUP group_name | PUBLIC } [, ...] ``` ### Octroi d’autorisations de rôle La syntaxe suivante s’applique à l’octroi de rôles sur Amazon Redshift. ``` GRANT { ROLE role_name } [, ...] TO { { user_name [ WITH ADMIN OPTION ] } | ROLE role_name }[, ...] ``` Voici la syntaxe permettant d’accorder des autorisations système aux rôles sur Amazon Redshift. Notez que vous ne pouvez accorder des autorisations qu’aux rôles, et non aux utilisateurs. ``` GRANT { { CREATE USER | DROP USER | ALTER USER | CREATE SCHEMA | DROP SCHEMA | ALTER DEFAULT PRIVILEGES | ACCESS CATALOG | ACCESS SYSTEM TABLE CREATE TABLE | DROP TABLE | ALTER TABLE | CREATE OR REPLACE FUNCTION | CREATE OR REPLACE EXTERNAL FUNCTION | DROP FUNCTION | CREATE OR REPLACE PROCEDURE | DROP PROCEDURE | CREATE OR REPLACE VIEW | DROP VIEW | CREATE MODEL | DROP MODEL | CREATE DATASHARE | ALTER DATASHARE | DROP DATASHARE | CREATE LIBRARY | DROP LIBRARY | CREATE ROLE | DROP ROLE | TRUNCATE TABLE VACUUM | ANALYZE | CANCEL | IGNORE RLS | EXPLAIN RLS | EXPLAIN MASKING }[, ...] } | { ALL [ PRIVILEGES ] } TO ROLE role_name [, ...] ``` ### Octroi d’autorisations d’explication pour les politiques de sécurité Voici la syntaxe permettant d’accorder des autorisations pour expliquer les filtres de politique de sécurité d’une requête dans le plan EXPLAIN. Les politiques de sécurité possibles incluent des politiques de sécurité au niveau des lignes et des politiques de masquage dynamique des données. ``` GRANT EXPLAIN { RLS | MASKING } TO ROLE rolename ``` Voici la syntaxe permettant d’accorder des autorisations permettant de contourner les politiques de sécurité au niveau des lignes pour une requête. Cette syntaxe ne s’applique pas aux politiques de masquage dynamique des données. ``` GRANT IGNORE RLS TO ROLE rolename ``` Voici la syntaxe permettant d’accorder des autorisations pour les tables de recherche à la politique de sécurité spécifiée. Les politiques de sécurité possibles incluent des politiques de sécurité au niveau des lignes et des politiques de masquage dynamique des données. ``` GRANT SELECT ON [ TABLE ] table_name [, ...] TO { RLS | MASKING } POLICY policy_name [, ...] ``` ### Octroi d'autorisations de connexion Voici la syntaxe permettant d'accorder des autorisations aux utilisateurs (ou groupes) AWS IAM Identity Center fédérés pour se connecter à un groupe de travail/cluster : ``` GRANT CONNECT [ON WORKGROUP] TO [USER] : | ROLE : | PUBLIC; ``` ## Parameters SELECT Autorise la sélection de données dans une table ou une vue à l’aide d’une instruction SELECT. L’autorisation SELECT est également requise pour référencer les valeurs des colonnes existantes pour les opérations UPDATE ou DELETE. INSERT Autorise le chargement de données dans une table à l’aide d’une instruction INSERT ou d’une instruction COPY. UPDATE Autorise la mise à jour d’une colonne de table à l’aide d’une instruction UPDATE. Les opérations UPDATE nécessitent également l’autorisation SELECT, car elles doivent faire référence aux colonnes de la table pour déterminer les lignes à mettre à jour ou pour calculer les nouvelles valeurs des colonnes. DELETE Autorise la suppression d’une ligne de données d’une table. Les opérations DELETE nécessitent également l’autorisation SELECT, car elles doivent faire référence aux colonnes de la table pour déterminer les lignes à supprimer. DROP En fonction de l’objet de la base de données, accorde les autorisations suivantes à l’utilisateur ou au rôle : + Pour les tables, DROP autorise la suppression d’une table ou d’une vue. Pour plus d’informations, consultez [DROP TABLE](r_DROP_TABLE.md). + Pour les bases de données, DROP autorise la suppression d’une base de données. Pour plus d’informations, consultez [DROP DATABASE](r_DROP_DATABASE.md). + Pour les schémas, DROP autorise la suppression d’un schéma. Pour plus d’informations, consultez [DROP SCHEMA](r_DROP_SCHEMA.md). REFERENCES Autorise la création d’une contrainte de clé étrangère. Vous devez accorder cette autorisation à la fois à la table référencée et à la table qui fait référence ; sinon, l’utilisateur ne peut pas créer la contrainte. ALTER En fonction de l’objet de la base de données, accorde les autorisations suivantes à l’utilisateur ou au groupe d’utilisateurs : + Pour les tables, ALTER autorise la modification d’une table ou d’une vue. Pour plus d’informations, consultez [ALTER TABLE](r_ALTER_TABLE.md). + Pour les bases de données, ALTER autorise la modification d’une base de données. Pour plus d’informations, consultez [ALTER DATABASE](r_ALTER_DATABASE.md). + Pour les schémas, ALTER autorise la modification d’un schéma. Pour plus d’informations, consultez [ALTER SCHEMA](r_ALTER_SCHEMA.md). + Pour les tables externes, ALTER autorise la modification d’une table dans un AWS Glue Data Catalog qui est activé pour Lake Formation. Cette autorisation s’applique uniquement lors de l’utilisation de Lake Formation. TRUNCATE Accorde l’autorisation de tronquer une table. Sans cette autorisation, seul le propriétaire d’une table ou un super-utilisateur peut tronquer une table. Pour plus d’informations sur la commande TRUNCATE, consultez [TRUNCATE](r_TRUNCATE.md). ALL [ PRIVILEGES ] Accorde toutes les autorisations disponibles en une seule fois à l’utilisateur ou au rôle spécifié. Le mot-clé PRIVILEGES est facultatif. GRANT ALL ON SCHEMA n’accorde pas les autorisations CREATE pour les schémas externes. Vous pouvez accorder l'autorisation ALL à une table dans un AWS Glue Data Catalog fichier activé pour Lake Formation. Dans ce cas, les autorisations individuelles (telles que SELECT, ALTER, etc.) sont enregistrées dans le catalogue de données. Amazon Redshift ne prend pas en charge les autorisations RULE et TRIGGER. Pour plus d’informations, consultez la section concernant [Fonctions PostgreSQL non prises en charge](c_unsupported-postgresql-features.md). ASSUMEROLE Accorde l’autorisation d’exécuter les commandes COPY, UNLOAD, EXTERNAL FUNCTION et CREATE MODEL aux utilisateurs, aux rôles et aux groupes ayant un rôle spécifié. L’utilisateur, le rôle ou le groupe assume ce rôle lors de l’exécution de la commande spécifiée. Pour commencer à utiliser l’autorisation ASSUMEROLE, consultez [Notes d’utilisation pour l’octroi de l’autorisation ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ON [ TABLE ] *nom\$1table* Accorde les autorisations spécifiées sur une table ou une vue. Le mot-clé TABLE est facultatif. Vous pouvez afficher plusieurs tables et vues dans une seule instruction. ON ALL TABLES IN SCHEMA *nom\$1schéma* Accorde les autorisations spécifiées sur toutes les tables et vues du schéma référencé. ( *nom\$1colonne* [,...] ) ON TABLE *nom\$1table* Accorde les autorisations spécifiées aux utilisateurs, groupes ou PUBLIC sur les colonnes spécifiées de la table ou vue Amazon Redshift. ( *column\$1list* ) ON EXTERNAL TABLE *schema\$1name.table\$1name* Accorde les autorisations spécifiées à un rôle IAM sur les colonnes spécifiées de la table Lake Formation dans le schéma référencé. ON EXTERNAL TABLE *schema\$1name.table\$1name* Accorde les autorisations spécifiées à un rôle IAM sur les tables Lake Formation spécifiées dans le schéma référencé. ON EXTERNAL SCHEMA *schema\$1name* Accorde les autorisations spécifiées à un rôle IAM sur le schéma référencé. ON *iam\$1role* Accorde les autorisations spécifiées à un rôle IAM. TO *nom\$1utilisateur* Indique l’utilisateur qui reçoit les autorisations. TO IAM\$1ROLE *iam\$1role* Indique le rôle IAM qui reçoit les autorisations. WITH GRANT OPTION Indique que l’utilisateur qui reçoit les autorisations peut à son tour accorder les mêmes autorisations à d’autres personnes. WITH GRANT OPTION ne peut pas être accordé à un groupe ou à PUBLIC. ROLE *role\$1name* Octroie les autorisations à un rôle. GROUP *group\$1name* Octroie les autorisations à un groupe d’utilisateurs. Il peut s’agir d’une liste séparée par des virgules pour spécifier plusieurs groupes d’utilisateurs. PUBLIC Accorde les autorisations spécifiées à tous les utilisateurs, y compris aux utilisateurs créés ultérieurement. PUBLIC représente un groupe qui inclut toujours tous les utilisateurs. Les autorisations d’un utilisateur sont la somme des autorisations accordées à PUBLIC, des autorisations accordées aux groupes auxquels l’utilisateur appartient et des autorisations accordées à l’utilisateur à titre individuel. L’octroi de PUBLIC à une TABLE EXTERNE de Lake Formation a pour effet d’accorder l’autorisation au groupe de personnes *tout le monde* de Lake Formation. CONNECTEZ [SUR LE GROUPE DE TRAVAIL] À \$1[UTILISATEUR] : \$1 RÔLE : \$1 PUBLIC\$1 Accorde l'autorisation de se connecter à un groupe de travail ou à un cluster à des utilisateurs ou à des groupes AWS IAM Identity Center fédérés. Le préfixe identifie le fournisseur d'identité. Lorsqu'elle est accordée à PUBLIC, l'autorisation s'applique à tous les utilisateurs AWS IAM Identity Center fédérés, y compris les utilisateurs créés ultérieurement. Cette autorisation n'est applicable que lorsque les autorisations fédérées Amazon Redshift sont activées sur le groupe de travail ou le cluster. CREATE En fonction de l’objet de la base de données, accorde les autorisations suivantes à l’utilisateur ou au groupe d’utilisateurs : + Pour les bases de données, CREATE permet aux utilisateurs de créer des schémas au sein de la base de données. + Pour les schémas, CREATE permet aux utilisateurs de créer des objets au sein d’un schéma. Pour renommer un objet, l’utilisateur doit disposer de l’autorisation CREATE et posséder l’objet à renommer. + CREATE ON SCHEMA n’est pas pris en charge pour les schémas externes Amazon Redshift Spectrum. Pour accorder l’utilisation de tables externes dans un schéma externe, accordez USAGE ON SCHEMA aux utilisateurs qui nécessitent un accès. Seul le propriétaire d’un schéma externe ou un super-utilisateur est autorisé à créer des tables externes dans le schéma externe. Pour transférer la propriété d’un schéma externe, utilisez [ALTER SCHEMA](r_ALTER_SCHEMA.md) pour modifier le propriétaire. TEMPORARY \$1 TEMP Accorde l’autorisation de créer des tables temporaires dans la base de données spécifiée. Pour exécuter des requêtes Amazon Redshift Spectrum, l’utilisateur de la base de données doit avoir l’autorisation d’y créer des tables temporaires. Par défaut, les utilisateurs ont l’autorisation de créer des tables temporaires grâce à leur appartenance automatique au groupe PUBLIC. Pour retirer à tout utilisateur l’autorisation de créer des tables temporaires, révoquez l’autorisation TEMP du groupe PUBLIC. Accordez ensuite explicitement l’autorisation de créer des tables temporaires à des utilisateurs ou à des groupes d’utilisateurs spécifiques. ON DATABASE *nom\$1db* Accorde les autorisations spécifiées à une base de données. USAGE Accorde l’autorisation USAGE sur un schéma spécifique, ce qui rend les objets de ce schéma accessibles aux utilisateurs. Les actions spécifiques sur ces objets doivent être accordées séparément (par exemple, l’autorisation SELECT ou UPDATE sur les tables) pour les schémas Amazon Redshift locaux. Par défaut, tous les utilisateurs disposent de l’autorisation CREATE et USAGE sur le schéma PUBLIC. Lorsque vous autorisez USAGE pour des schémas externes à l’aide de la syntaxe ON SCHEMA, vous n’avez pas besoin d’accorder des actions séparément sur les objets du schéma externe. Les autorisations de catalogue correspondantes contrôlent les autorisations granulaires sur les objets de schéma externes. ON SCHEMA *nom\$1schéma* Accorde les autorisations spécifiées à un schéma. GRANT CREATE ON SCHEMA et l’autorisation CREATE dans GRANT ALL ON SCHEMA ne sont pas pris en charge pour les schémas externes Amazon Redshift Spectrum. Pour accorder l’utilisation de tables externes dans un schéma externe, accordez USAGE ON SCHEMA aux utilisateurs qui nécessitent un accès. Seul le propriétaire d’un schéma externe ou un super-utilisateur est autorisé à créer des tables externes dans le schéma externe. Pour transférer la propriété d’un schéma externe, utilisez [ALTER SCHEMA](r_ALTER_SCHEMA.md) pour modifier le propriétaire. EXECUTE ON ALL FUNCTIONS IN SCHEMA *nom\$1schéma* Accorde les autorisations spécifiées à toutes les fonctions du schéma référencé. Amazon Redshift ne prend pas en charge les instructions GRANT ou REVOKE pour les entrées intégrées pg\$1proc définies dans l’espace de noms pg\$1catalog. EXECUTE ON PROCEDURE *procedure\$1name* Accorde l’autorisation EXECUTE à une procédure stockée spécifique. Comme les noms de procédures stockées peuvent être surchargés, vous devez inclure la liste des arguments de la procédure. Pour plus d'informations, consultez [Dénomination des procédures stockées](stored-procedure-naming.md). EXECUTE ON ALL PROCEDURES IN SCHEMA *nom\$1schéma* Accorde les autorisations spécifiées à toutes les procédures stockées du schéma référencé. USAGE ON LANGUAGE *nom\$1langage* Accorde l’autorisation USAGE à une langue. À compter du 1er novembre 2025, Amazon Redshift ne prendra plus en charge la création de nouveaux Python. UDFs UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. À compter du 1er juillet 2026, Amazon Redshift ne prendra plus en charge Python. UDFs Nous vous recommandons de migrer votre Python existant UDFs vers Lambda UDFs avant le 1er novembre 2025. Pour plus d'informations sur la création et l'utilisation de Lambda UDFs, consultez. [Lambda scalaire UDFs](udf-creating-a-lambda-sql-udf.md) Pour plus d'informations sur la conversion de Python existant UDFs en Lambda UDFs, consultez le [billet de blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). L'autorisation USAGE ON LANGUAGE est requise pour créer des fonctions définies par l'utilisateur (UDFs) en exécutant la [CREATE FUNCTION](r_CREATE_FUNCTION.md) commande. Pour de plus amples informations, veuillez consulter [Sécurité et autorisations des fonctions définies par l’utilisateur](udf-security-and-privileges.md). L’autorisation USAGE ON LANGUAGE est requise pour créer des procédures stockées définies par l’utilisateur (UDF) en exécutant la commande [CREATE PROCEDURE](r_CREATE_PROCEDURE.md). Pour de plus amples informations, veuillez consulter [Sécurité et privilèges des procédures stockées](stored-procedure-security-and-privileges.md). Pour Python UDFs, utilisez`plpythonu`. Pour SQL UDFs, utilisez`sql`. Pour les procédures stockées, utilisez `plpgsql`. ON COPY JOB *job\$1name* Accorde les autorisations spécifiées à une tâche copy. FOR \$1 ALL \$1 COPY \$1 UNLOAD \$1 EXTERNAL FUNCTION \$1 CREATE MODEL \$1 [, ...] Spécifie la commande SQL pour laquelle l’autorisation est accordée. Vous pouvez spécifier ALL pour accorder l’autorisation sur les instructions COPY, UNLOAD, EXTERNAL FUNCTION et CREATE MODEL. Cette clause ne s’applique qu’à l’octroi de l’autorisation ASSUMEROLE. ALTER Accorde l’autorisation ALTER aux utilisateurs pour ajouter ou supprimer des objets d’une unité de partage des données, ou pour définir la propriété PUBLICACCESSIBLE. Pour plus d’informations, consultez [ALTER DATASHARE](r_ALTER_DATASHARE.md). SHARE Accorde des autorisations aux utilisateurs et aux groupes d’utilisateurs pour ajouter des consommateurs de données à une unité de partage des données. Cette autorisation est requise pour permettre au consommateur particulier (compte ou espace de noms) d’accéder à l’unité de partage des données à partir de ses clusters. Le consommateur peut être le même compte ou un AWS compte différent, avec le même espace de noms de cluster ou un autre, tel que spécifié par un identifiant unique global (GUID). ON DATASHARE *datashare\$1name* Accorde les autorisations spécifiées sur l’unité de partage des données référencée. Pour obtenir des informations sur la granularité du contrôle d’accès des consommateurs, consultez [Partage de données à différents niveaux dans Amazon Redshift](datashare-overview.md#granularity). USAGE Lorsque le privilège USAGE est accordé à un compte consommateur ou à un espace de noms au sein du même compte, le compte ou l’espace de noms spécifique du compte peut accéder à l’unité de partage des données et aux objets de l’unité de partage des données en lecture seule. TO NAMESPACE ’clusternamespace GUID’ Indique un espace de noms dans le même compte où les consommateurs peuvent recevoir les autorisations spécifiées pour l’unité de partage des données. Les espaces de noms utilisent un GUID alphanumérique 128 bits. TO ACCOUNT ’accountnumber’ [ VIA DATA CATALOG ] Indique le numéro d’un autre compte dont les consommateurs peuvent recevoir les autorisations spécifiées pour l’unité de partage des données. La spécification « VIA DATA CATALOG » indique que vous autorisez un compte Lake Formation à utiliser l’unité de partage des données. L’omission de ce paramètre signifie que vous accordez l’utilisation à un compte propriétaire du cluster. ON DATABASE *shared\$1database\$1name> [, ...]* Accorde les autorisations d’utilisation spécifiées à la base de données spécifiée qui est créée dans l’unité de partage des données spécifiée. ON SCHEMA* shared\$1schema* Accorde les autorisations spécifiées au schéma spécifié qui est créé dans l’unité de partage des données spécifiée. FOR \$1 SCHEMAS \$1 TABLES \$1 FUNCTIONS \$1 PROCEDURES \$1 LANGUAGES \$1 COPY JOBS\$1 IN Spécifie les objets de base de données auxquels accorder une autorisation. Les paramètres situés après IN définissent l’étendue de l’autorisation accordée. CREATE MODEL Accorde l’autorisation CREATE MODEL à des utilisateurs ou groupes d’utilisateurs spécifiques. ON MODEL *model\$1name* Accorde l’autorisation EXECUTE à un modèle spécifique. ACCESS CATALOG Accorde l’autorisation d’afficher les métadonnées pertinentes des objets auxquels le rôle a accès. \$1 role \$1 [, ...] Rôle à attribuer à un autre rôle, à un utilisateur ou à PUBLIC. PUBLIC représente un groupe qui inclut toujours tous les utilisateurs. Les autorisations d’un utilisateur sont la somme des autorisations accordées à PUBLIC, des autorisations accordées aux groupes auxquels l’utilisateur appartient et des autorisations accordées à l’utilisateur à titre individuel. TO \$1 \$1 *user\$1name* [ WITH ADMIN OPTION ] \$1 \$1 role \$1[, ...] Attribue le rôle spécifié à un utilisateur spécifié avec WITH ADMIN OPTION, à un autre rôle ou à PUBLIC. La clause WITH ADMIN OPTION fournit les options d’administration de tous les rôles accordés à tous les bénéficiaires. EXPLAIN \$1 RLS \$1 MASKING \$1 TO ROLE *rolename* Accorde à un rôle l’autorisation d’expliquer les filtres de politique de sécurité d’une requête dans le plan EXPLAIN. RLS accorde l’autorisation d’explication pour les filtres de politique de sécurité au niveau des lignes. MASKING accorde l’autorisation d’explication pour les filtres de politique de masquage dynamique des données. IGNORE RLS TO ROLE *rolename* Accorde à un rôle l’autorisation de contourner les politiques de sécurité au niveau des lignes pour une requête. TO \$1 RLS \$1 MASKING \$1 POLICY *policy\$1name* Indique la politique de sécurité qui reçoit les autorisations. TO RLS POLICY indique une politique de sécurité de niveau des lignes. TO MASKING POLICY indique une politique de masquage dynamique des données. ## Notes d’utilisation Pour en savoir plus sur les notes d’utilisation de GRANT, consultez [Notes d’utilisation](r_GRANT-usage-notes.md). ## Exemples Pour des exemples d’utilisation de GRANT, consultez [Exemples](r_GRANT-examples.md). # Notes d’utilisation Pour attribuer des privilèges sur un objet, vous devez répondre à l’un des critères suivants : + Être le propriétaire de l’objet. + Être un super-utilisateur. + Avoir un privilège accordé pour cet objet et ce privilège. Par exemple, la commande suivante autorise l’utilisateur HR à exécuter des commandes SELECT sur la table des employés et à accorder et révoquer le même privilège aux autres utilisateurs. ``` grant select on table employees to HR with grant option; ``` HR ne peut pas accorder de privilèges pour une opération autre que SELECT, ou sur toute autre table que celle des employés. Par exemple, la commande suivante autorise l’utilisateur HR à exécuter des commandes ALTER sur la table des employés et à accorder et révoquer le même privilège aux autres utilisateurs. ``` grant ALTER on table employees to HR with grant option; ``` HR ne peut pas accorder de privilèges pour une opération autre que ALTER ou sur toute autre table que celle des employés. Le fait d’avoir les privilèges octroyés sur une vue n’implique pas d’avoir les privilèges sur les tables sous-jacentes. De même, le fait d’avoir les privilèges octroyés sur un schéma n’implique pas d’avoir les privilèges sur les tables du schéma. Accordez explicitement l’accès aux tables sous-jacentes. Pour accorder des privilèges à une AWS Lake Formation table, le rôle IAM associé au schéma externe de la table doit être autorisé à accorder des privilèges à la table externe. L’exemple suivant crée un schéma externe avec un rôle IAM `myGrantor` associé. Le rôle IAM `myGrantor` a l’autorisation d’accorder des autorisations. La commande GRANT utilise l’autorisation du rôle IAM `myGrantor` associé au schéma externe pour accorder des autorisations au rôle IAM `myGrantee`. ``` create external schema mySchema from data catalog database 'spectrum_db' iam_role 'arn:aws:iam::123456789012:role/myGrantor' create external database if not exists; ``` ``` grant select on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` Si vous accordez des privilèges GRANT ALL à un rôle IAM, des privilèges individuels sont accordés dans le catalogue de données Lake Formation. Par exemple, les privilèges GRANT ALL suivants permettent aux privilèges individuels accordés (SELECT, ALTER, DROP, DELETE et INSERT) de s’afficher dans la console Lake Formation. ``` grant all on external table mySchema.mytable to iam_role 'arn:aws:iam::123456789012:role/myGrantee'; ``` Les super-utilisateurs peuvent accéder à tous les objets, quelle que soit les commandes GRANT et REVOKE qui définissent les privilèges d’objet. ## Notes d’utilisation pour le contrôle d’accès de niveau colonne Les notes d’utilisation suivantes s’appliquent aux privilèges de niveau colonne sur les tables et les vues Amazon Redshift. Ces notes décrivent des tableaux ; les mêmes notes s’appliquent aux vues, sauf signalement explicite d’une exception. + Pour une table Amazon Redshift, vous pouvez accorder uniquement les privilèges SELECT et UPDATE au niveau de la colonne. Pour une vue Amazon Redshift, vous pouvez accorder uniquement le privilège SELECT au niveau de la colonne. + Le mot-clé ALL est synonyme des privilèges combinés SELECT et UPDATE lorsqu’ils sont utilisés dans le contexte d’un GRANT de niveau colonne sur une table. + Si vous ne disposez pas du privilège SELECT sur toutes les colonnes d’une table, l’opération SELECT \$1 ne renvoie que les colonnes auxquelles vous avez accès. Lorsque vous utilisez une vue, une opération SELECT \$1 tente d’accéder à toutes les colonnes de la vue. Si vous n’êtes pas autorisé à accéder à toutes les colonnes, ces requêtes échouent avec un message d’erreur de refus d’autorisation. + SELECT \$1 ne s’étend pas aux seules colonnes accessibles dans les cas suivants : + Vous ne pouvez pas créer une vue normale avec seulement des colonnes accessibles en utilisant SELECT \$1. + Vous ne pouvez pas créer une vue matérialisée avec seulement des colonnes accessibles en utilisant SELECT \$1. + Si vous disposez du privilège SELECT ou UPDATE sur une table ou une vue et que vous ajoutez une colonne, vous disposez toujours des mêmes privilèges sur la table ou la vue et donc, sur toutes ses colonnes. + Seul le propriétaire d’une table ou un superutilisateur peut accorder des privilèges de niveau colonne. + La clause WITH GRANT OPTION n’est pas prise en charge pour les privilèges de niveau colonne. + Vous ne pouvez pas détenir le même privilège au niveau de la table et de la colonne. Par exemple, l’utilisateur `data_scientist` ne peut pas avoir à la fois le privilège SELECT sur la table `employee` et le privilège SELECT sur la colonne `employee.department`. Tenez compte des résultats suivants lorsque vous accordez le même privilège à une table et à une colonne de la table : + Si un utilisateur dispose d’un privilège de niveau table sur une table, l’octroi du même privilège au niveau de la colonne n’a aucun effet. + Si un utilisateur dispose d’un privilège de niveau table sur une table, la révocation du même privilège pour une ou plusieurs colonnes de la table renvoie une erreur. Au lieu de cela, révoquez le privilège au niveau de la table. + Si un utilisateur dispose d’un privilège au niveau de la colonne, l’octroi du même privilège au niveau de la table renvoie une erreur. + Si un utilisateur dispose d’un privilège au niveau de la colonne, la révocation du même privilège au niveau de la table révoque les privilèges de colonne et de table pour toutes les colonnes de la table. + Vous ne pouvez pas accorder de privilèges de niveau colonne sur les vues de liaison tardive. + Pour créer une vue matérialisée, vous devez disposer du privilège SELECT au niveau de la table sur les tables de base. Même si vous disposez de privilèges au niveau de colonnes spécifiques, vous ne pouvez pas créer de vue matérialisée uniquement avec ces colonnes. Toutefois, vous pouvez accorder le privilège SELECT aux colonnes d’une vue matérialisée, de la même manière que les vues régulières. + Pour rechercher des privilèges de niveau colonne, utilisez la vue [PG\$1ATTRIBUTE\$1INFO](r_PG_ATTRIBUTE_INFO.md). ## Notes d’utilisation pour l’octroi de l’autorisation ASSUMEROLE Les notes d’utilisation suivantes s’appliquent à l’octroi de l’autorisation ASSUMEROLE dans Amazon Redshift. Vous utilisez l’autorisation ASSUMEROLE pour contrôler les autorisations d’accès des rôles IAM pour les utilisateurs, les rôles ou les groupes de bases de données sur des commandes telles que COPY, UNLOAD, EXTERNAL FUNCTION ou CREATE MODEL. Après avoir accordé l’autorisation ASSUMEROLE à un utilisateur, un rôle ou un groupe pour un rôle IAM, l’utilisateur, le rôle ou le groupe peut assumer ce rôle lors de l’exécution de la commande. L’autorisation ASSUMEROLE vous permet d’accorder l’accès aux autorisations appropriées en fonction des besoins. Seul un super-utilisateur de la base de données peut accorder ou révoquer l’autorisation ASSUMEROLE pour les utilisateurs, les rôles et les groupes. Un super-utilisateur conserve toujours l’autorisation ASSUMEROLE. Pour autoriser l’utilisation de l’autorisation ASSUMEROLE pour les utilisateurs, les rôles et les groupes, un super-utilisateur effectue les deux actions suivantes : + Exécuter l’instruction suivante une fois sur le cluster : ``` revoke assumerole on all from public for all; ``` + Accordez l’autorisation ASSUMEROLE aux utilisateurs, aux rôles et aux groupes pour les autorisations appropriées. Vous pouvez spécifier la création de chaînes de rôles dans la clause ON lorsque vous accordez l’autorisation ASSUMEROLE. Vous utilisez des virgules pour séparer les rôles dans une chaîne de rôles, par exemple `Role1,Role2,Role3`. Si la création de chaînes de rôles a été spécifiée lors de l’octroi de l’autorisation ASSUMEROLE, vous devez spécifier la chaîne de rôles lors de l’exécution des autorisations accordées par l’autorisation ASSUMEROLE. Vous ne pouvez pas spécifier des rôles individuels dans la chaîne de rôles lorsque vous exécutez des autorisations accordées par l’autorisation ASSUMEROLE. Par exemple, si un utilisateur, un rôle ou un groupe se voit attribuer la chaîne de rôles `Role1,Role2,Role3`, vous ne pouvez pas spécifier uniquement `Role1` pour effectuer des opérations. Si un utilisateur tente d’effectuer une opération COPY, UNLOAD, EXTERNAL FUNCTION ou CREATE MODEL et n’a pas obtenu l’autorisation ASSUMEROLE, un message semblable au suivant s’affiche. ``` ERROR: User awsuser does not have ASSUMEROLE permission on IAM role "arn:aws:iam::123456789012:role/RoleA" for COPY ``` Pour répertorier les utilisateurs qui ont obtenu l’accès aux rôles et commandes IAM via l’autorisation ASSUMEROLE, consultez [HAS\$1ASSUMEROLE\$1PRIVILEGE](r_HAS_ASSUMEROLE_PRIVILEGE.md). Pour répertorier les rôles IAM et les autorisations de commande qui ont été accordées à un utilisateur que vous spécifiez, consultez [PG\$1GET\$1IAM\$1ROLE\$1BY\$1USER](PG_GET_IAM_ROLE_BY_USER.md). Pour répertorier les utilisateurs, les rôles et les groupes auxquels l’accès a été accordé à un rôle IAM que vous spécifiez, consultez [PG\$1GET\$1GRANTEE\$1BY\$1IAM\$1ROLE](PG_GET_GRANTEE_BY_IAMROLE.md). ## Notes d’utilisation pour l’octroi d’autorisations de machine learning Vous ne pouvez pas accorder ou révoquer directement les autorisations liées à une fonction ML. Une fonction ML appartient à un modèle ML et les autorisations sont contrôlées par le biais du modèle. En revanche, vous pouvez accorder des autorisations liées au modèle ML. L’exemple suivant montre comment autoriser tous les utilisateurs à exécuter la fonction ML associée au modèle `customer_churn`. ``` GRANT EXECUTE ON MODEL customer_churn TO PUBLIC; ``` Vous pouvez également accorder toutes les autorisations à un utilisateur pour le modèle ML `customer_churn`. ``` GRANT ALL on MODEL customer_churn TO ml_user; ``` L’octroi de l’autorisation `EXECUTE` liée à une fonction de ML échouera s’il existe une fonction de ML dans le schéma, même si cette fonction de ML dispose déjà de l’autorisation `EXECUTE` par le biais de `GRANT EXECUTE ON MODEL`. Nous vous recommandons d’utiliser un schéma distinct lorsque vous utilisez la commande `CREATE MODEL` afin de conserver les fonctions ML dans un schéma distinct. L’exemple suivant vous montre comment procéder. ``` CREATE MODEL ml_schema.customer_churn FROM customer_data TARGET churn FUNCTION ml_schema.customer_churn_prediction IAM_ROLE default SETTINGS ( S3_BUCKET 'amzn-s3-demo-bucket' ); ``` # Exemples L’exemple suivant accorde le privilège SELECT sur la table SALES à l’utilisateur `fred`. ``` grant select on table sales to fred; ``` L’exemple suivant accorde le privilège SELECT sur toutes les tables du schéma QA\$1TICKIT à l’utilisateur `fred`. ``` grant select on all tables in schema qa_tickit to fred; ``` L’exemple suivant accorde tous les privilèges de schéma sur le schéma QA\$1TICKIT au groupe d’utilisateurs QA\$1USERS. Les privilèges de schéma sont CREATE et USAGE. USAGE accorde aux utilisateurs l’accès aux objets du schéma, mais n’accorde pas les privilèges tels que INSERT or SELECT sur ces objets. Accordez des privilèges sur chaque objet séparément. ``` create group qa_users; grant all on schema qa_tickit to group qa_users; ``` L’exemple suivant accorde tous les privilèges sur la table SALES du schéma QA\$1TICKIT à tous les utilisateurs du groupe QA\$1USERS. ``` grant all on table qa_tickit.sales to group qa_users; ``` L’exemple suivant accorde tous les privilèges sur la table SALES du schéma QA\$1TICKIT à tous les utilisateurs des groupes QA\$1USERS et RO\$1USERS. ``` grant all on table qa_tickit.sales to group qa_users, group ro_users; ``` L’exemple suivant accorde le privilège DROP sur la table SALES du schéma QA\$1TICKIT à tous les utilisateurs du groupe QA\$1USERS. ``` grant drop on table qa_tickit.sales to group qa_users;> ``` La séquence de commandes suivante montre comment l’accès à un schéma n’accorde pas de privilèges sur une table du schéma. ``` create user schema_user in group qa_users password 'Abcd1234'; create schema qa_tickit; create table qa_tickit.test (col1 int); grant all on schema qa_tickit to schema_user; set session authorization schema_user; select current_user; current_user -------------- schema_user (1 row) select count(*) from qa_tickit.test; ERROR: permission denied for relation test [SQL State=42501] set session authorization dw_user; grant select on table qa_tickit.test to schema_user; set session authorization schema_user; select count(*) from qa_tickit.test; count ------- 0 (1 row) ``` La séquence de commandes suivante montre comment l’accès à une vue n’implique pas l’accès à ses tables sous-jacentes. L’utilisateur appelé VIEW\$1USER ne peut pas sélectionner à partir de la table DATE, même si cet utilisateur s’est vu accorder tous les privilèges sur VIEW\$1DATE. ``` create user view_user password 'Abcd1234'; create view view_date as select * from date; grant all on view_date to view_user; set session authorization view_user; select current_user; current_user -------------- view_user (1 row) select count(*) from view_date; count ------- 365 (1 row) select count(*) from date; ERROR: permission denied for relation date ``` L’exemple suivant accorde le privilège SELECT sur les colonnes `cust_name` et `cust_phone` de la table `cust_profile` à l’utilisateur `user1`. ``` grant select(cust_name, cust_phone) on cust_profile to user1; ``` L’exemple suivant accorde le privilège SELECT sur les colonnes `cust_name` et `cust_phone` et le privilège UPDATE sur la colonne `cust_contact_preference` de la table `cust_profile` au groupe `sales_group`. ``` grant select(cust_name, cust_phone), update(cust_contact_preference) on cust_profile to group sales_group; ``` L’exemple suivant montre l’utilisation du mot-clé ALL pour accorder au groupe `sales_admin` les privilèges SELECT et UPDATE sur trois colonnes de la table `cust_profile`. ``` grant ALL(cust_name, cust_phone,cust_contact_preference) on cust_profile to group sales_admin; ``` L’exemple suivant accorde à l’utilisateur `user2` le privilège SELECT sur la colonne `cust_name` de la vue `cust_profile_vw`. ``` grant select(cust_name) on cust_profile_vw to user2; ``` ## Exemples d’octroi d’accès à des unités de partage des données Les exemples suivants illustrent les autorisations d’utilisation de partage de données GRANT sur une base de données spécifique ou un schéma créé à partir d’une unité de partage des données. Dans l’exemple suivant, un administrateur côté producteur accorde à l’espace de noms spécifié l’autorisation USAGE sur l’unité de partage des données `salesshare`. ``` GRANT USAGE ON DATASHARE salesshare TO NAMESPACE '13b8833d-17c6-4f16-8fe4-1a018f5ed00d'; ``` Dans l’exemple suivant, un administrateur côté consommateur accorde à `Bob` l’autorisation USAGE sur la base de données `sales_db`. ``` GRANT USAGE ON DATABASE sales_db TO Bob; ``` Dans l’exemple suivant, un administrateur côté consommateur accorde au rôle `Analyst_role`l’autorisation GRANT USAGE sur le schéma `sales_schema`. `sales_schema` est un schéma externe qui pointe vers sales\$1db. ``` GRANT USAGE ON SCHEMA sales_schema TO ROLE Analyst_role; ``` À ce stade, `Bob` et `Analyst_role` peuvent accéder à tous les objets de base de données dans `sales_schema` et`sales_db`. L’exemple suivant montre comment accorder une autorisation de niveau objet supplémentaire pour les objets d’une base de données partagée. Ces autorisations supplémentaires ne sont nécessaires que si la commande CREATE DATABASE utilisée pour créer la base de données partagée utilisait la clause WITH PERMISSIONS. Si la commande CREATE DATABASE n’a pas utilisé la clause WITH PERMISSIONS, accorder l’autorisation USAGE sur la base de données partagée donne un accès complet à tous les objets de cette base de données. ``` GRANT SELECT ON sales_db.sales_schema.tickit_sales_redshift to Bob; ``` ## Exemples d’octroi d’autorisations étendues L’exemple suivant autorise le rôle `Sales` à utiliser tous les schémas actuels et futurs de la base de données `Sales_db`. ``` GRANT USAGE FOR SCHEMAS IN DATABASE Sales_db TO ROLE Sales; ``` L’exemple suivant accorde à l’utilisateur `alice` l’autorisation SELECT pour toutes les tables actuelles et futures de la base de données `Sales_db`, et donne aussi à `alice` l’autorisation d’accorder à d’autres utilisateurs des autorisations étendues sur les tables de `Sales_db`. ``` GRANT SELECT FOR TABLES IN DATABASE Sales_db TO alice WITH GRANT OPTION; ``` L’exemple suivant accorde à l’utilisateur `bob` l’autorisation EXECUTE pour les fonctions du schéma `Sales_schema`. ``` GRANT EXECUTE FOR FUNCTIONS IN SCHEMA Sales_schema TO bob; ``` L’exemple suivant accorde au `Sales` rôle toutes les autorisations pour toutes les tables du schéma `ShareSchema` de la base de données `ShareDb`. Lorsque vous spécifiez le schéma, vous pouvez spécifier la base de données du schéma en utilisant le format en deux parties `database.schema`. ``` GRANT ALL FOR TABLES IN SCHEMA ShareDb.ShareSchema TO ROLE Sales; ``` L’exemple suivant est le même que le précédent. Vous pouvez spécifier la base de données à l’aide du mot-clé `DATABASE` au lieu d’utiliser un format en deux parties. ``` GRANT ALL FOR TABLES IN SCHEMA ShareSchema DATABASE ShareDb TO ROLE Sales; ``` ## Exemples d’octroi du privilège ASSUMEROLE Voici des exemples d’octroi du privilège ASSUMEROLE. L’exemple suivant montre l’instruction REVOKE qu’un super-utilisateur exécute une fois sur le cluster pour activer l’utilisation du privilège ASSUMEROLE pour les utilisateurs et les groupes. Ensuite, le super-utilisateur accorde le privilège ASSUMEROLE aux utilisateurs et aux groupes pour les commandes appropriées. Pour obtenir des informations sur l’activation du privilège ASSUMEROLE pour les utilisateurs et les groupes, consultez [Notes d’utilisation pour l’octroi de l’autorisation ASSUMEROLE](r_GRANT-usage-notes.md#r_GRANT-usage-notes-assumerole). ``` revoke assumerole on all from public for all; ``` L’exemple suivant accorde le privilège ASSUMEROLE à l’utilisateur `reg_user1` pour le rôle IAM `Redshift-S3-Read` pour effectuer des opérations COPY. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-S3-Read' to reg_user1 for copy; ``` L’exemple suivant accorde le privilège ASSUMEROLE à l’utilisateur `reg_user1` pour la chaîne de rôles IAM `RoleA`, `RoleB` pour effectuer des opérations UNLOAD. ``` grant assumerole on 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB' to reg_user1 for unload; ``` Voici un exemple de commande UNLOAD utilisant la chaîne de rôles IAM `RoleA`, `RoleB`. ``` unload ('select * from venue limit 10') to 's3://companyb/redshift/venue_pipe_' iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB'; ``` L’exemple suivant accorde le privilège ASMEROLE à l’utilisateur `reg_user1` pour le rôle IAM `Redshift-Exfunc` pour créer des fonctions externes. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-Exfunc' to reg_user1 for external function; ``` L’exemple suivant accorde le privilège ASSUMEROLE à l’utilisateur `reg_user1` pour le rôle IAM `Redshift-model` pour créer des modèles de machine learning. ``` grant assumerole on 'arn:aws:iam::123456789012:role/Redshift-ML' to reg_user1 for create model; ``` ## Exemples d’octroi de privilèges ROLE L’exemple suivant accorde le rôle sample\$1role1 à l’utilisateur user1. ``` CREATE ROLE sample_role1; GRANT ROLE sample_role1 TO user1; ``` L’exemple suivant accorde le rôle sample\$1role1 à l’utilisation user1 avec la clause WITH ADMIN OPTION, définit la séance actuelle pour user1, et user1 accorde le rôle sample\$1role1 à l’utilisateur user2. ``` GRANT ROLE sample_role1 TO user1 WITH ADMIN OPTION; SET SESSION AUTHORIZATION user1; GRANT ROLE sample_role1 TO user2; ``` L’exemple suivant accorde le rôle sample\$1role1 au rôle sample\$1role2. ``` GRANT ROLE sample_role1 TO ROLE sample_role2; ``` L’exemple suivant accorde le rôle sample\$1role2 au rôle sample\$1role3 et au rôle sample\$1role4. Ensuite, il tente d’accorder le rôle sample\$1role3 au rôle sample\$1role1. ``` GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; ERROR: cannot grant this role, a circular dependency was detected between these roles ``` L’exemple suivant accorde les privilèges système CREATE USER au rôle sample\$1role1. ``` GRANT CREATE USER TO ROLE sample_role1; ``` L’exemple suivant accorde le rôle défini par le système `sys:dba` à l’utilisateur user1. ``` GRANT ROLE sys:dba TO user1; ``` L’exemple suivant tente d’accorder le rôle sample\$1role3 dans une dépendance circulaire au rôle sample\$1role2. ``` CREATE ROLE sample_role3; GRANT ROLE sample_role2 TO ROLE sample_role3; GRANT ROLE sample_role3 TO ROLE sample_role2; -- fail ERROR: cannot grant this role, a circular dependency was detected between these roles ```