Catégories :

Utilisateur et sécurité DDL (contrôle d’accès)

GRANT <privileges> … TO ROLE

Attribue un ou plusieurs privilèges d’accès à un rôle sur un objet sécurisable. Les privilèges qui peuvent être accordés sont spécifiques à l’objet et sont regroupés dans les catégories suivantes :

  • Privilèges globaux

  • Privilèges pour les objets de compte (moniteurs de ressources, entrepôts virtuels et bases de données)

  • Privilèges pour les schémas

  • Privilèges pour les objets de schéma (tables, vues, zones de préparation, formats de fichiers, UDFs et séquences)

Pour plus de détails sur les rôles et les objets sécurisables, voir Contrôle d’accès dans Snowflake.

Variations :

GRANT OWNERSHIP , GRANT <privilège> … TO SHARE

Voir aussi :

REVOKE <privileges> … FROM ROLE

Syntaxe

GRANT {  { globalPrivileges         | ALL [ PRIVILEGES ] } ON ACCOUNT
       | { accountObjectPrivileges  | ALL [ PRIVILEGES ] } ON { RESOURCE MONITOR | WAREHOUSE | DATABASE | INTEGRATION } <object_name>
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { SCHEMA <schema_name> | ALL SCHEMAS IN DATABASE <db_name> }
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { FUTURE SCHEMAS IN DATABASE <db_name> }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON { <object_type> <object_name> | ALL <object_type_plural> IN SCHEMA <schema_name> }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON FUTURE <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> }
      }
  TO [ ROLE ] <role_name> [ WITH GRANT OPTION ]

Où :

globalPrivileges ::=
  { { CREATE { ROLE | USER | WAREHOUSE | DATABASE | INTEGRATION } } | APPLY MASKING POLICY | EXECUTE TASK | MANAGE GRANTS | MONITOR { EXECUTION | USAGE }  } [ , ... ]
accountObjectPrivileges ::=
-- For RESOURCE MONITOR
  { MODIFY | MONITOR } [ , ... ]
-- For WAREHOUSE
  { MODIFY | MONITOR | USAGE | OPERATE } [ , ... ]
-- For USER
  { MONITOR } [ , ... ]
-- For DATABASE
  { MODIFY | MONITOR | USAGE | CREATE SCHEMA | IMPORTED PRIVILEGES } [ , ... ]
-- For INTEGRATION
  { USAGE | USE_ANY_ROLE } [ , ... ]
schemaPrivileges ::=
  { MODIFY | MONITOR | USAGE | CREATE { TABLE | EXTERNAL TABLE | VIEW | MATERIALIZED VIEW | MASKING POLICY | FILE FORMAT | STAGE | PIPE | STREAM | TASK | SEQUENCE | FUNCTION (UDF) | PROCEDURE } } [ , ... ]
schemaObjectPrivileges ::=
-- For TABLE
  { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES } [ , ... ]
-- For VIEW
    SELECT
-- For MATERIALIZED VIEW
    SELECT
-- For internal STAGE
    READ [ , WRITE ]
-- For external STAGE
    USAGE
-- For FILE FORMAT, FUNCTION (UDF or external function), or SEQUENCE
    USAGE
-- For STREAM
    SELECT
-- For TASK
   { MONITOR | OPERATE } [ , ... ]
-- For MASKING POLICY
    APPLY

Pour plus de détails sur les privilèges pris en charge pour chaque type d’objet, voir Privilèges de contrôle d’accès.

Paramètres requis

nom_objet

Indique l’identificateur de l’objet sur lequel les privilèges sont accordés.

type_objet

Indique le type d’objet (pour les objets de schéma) :

TABLE | EXTERNAL TABLE | VIEW | MATERIALIZED VIEW | STAGE | FILE FORMAT | FUNCTION | PROCEDURE | SEQUENCE | STREAM | TASK

pluriel_type_objet

Pluriel de type_objet (par exemple TABLES, VIEWS).

nom_rôle

Spécifie l’identificateur du rôle du destinataire (c’est-à-dire le rôle auquel les privilèges sont accordés).

Paramètres facultatifs

ON FUTURE

Spécifie que les privilèges sont accordés sur les nouveaux objets de base de données ou de schéma (futurs) d’un type spécifié (par exemple, tables ou vues) plutôt que sur les objets existants. Notez que les autorisations futures peuvent être annulées à tout moment en utilisant REVOKE <privileges> … FROM ROLE avec les mots-clés ON FUTURE. Tous les privilèges accordés sur des objets existants sont conservés. Pour plus d’informations sur les autorisations futures, voir Futures autorisations sur des objets de base de données ou de schéma dans ce chapitre.

WITH GRANT OPTION

Si spécifié, permet au rôle destinataire d’accorder les privilèges à d’autres rôles.

Par défaut : aucune valeur (le rôle destinataire ne peut pas accorder les privilèges à d’autres rôles)

Note

Le paramètre WITH GRANT OPTION ne prend pas en charge le privilège IMPORTED PRIVILEGES. Pour plus d’informations, voir Attribution de privilèges sur une base de données partagée.

Notes sur l’utilisation

  • Le privilège global MANAGE GRANTS est requis pour accorder ou révoquer des privilèges sur des objets futurs au niveau de la base de données. Par défaut, seuls les rôles SECURITYADMIN et ACCOUNTADMIN ont le privilège MANAGE GRANTS. Pour plus d’informations sur les autorisations futures, voir Futures autorisations sur des objets de base de données ou de schéma dans ce chapitre.

    Par ailleurs :

    • Dans les schémas classiques (non gérés), le propriétaire de l’objet (c’est-à-dire le rôle doté du privilège OWNERSHIP sur l’objet) peut octroyer des privilèges sur des objets individuels.

    • Dans les schémas d’accès gérés, les propriétaires d’objet ne peuvent plus prendre de décision. Le propriétaire du schéma (c’est-à-dire le rôle doté du privilège OWNERSHIP sur le schéma) peut octroyer des privilèges sur les objets du schéma, y compris des autorisations futures.

  • Plusieurs privilèges peuvent être spécifiés pour le même type d’objet dans une seule instruction GRANT (chaque privilège étant séparé par des virgules), ou le mot clé spécial ALL [ PRIVILEGES ] peut être utilisé pour accorder tous les privilèges applicables au type d’objet spécifié. Notez, cependant, que seuls les privilèges détenus et pouvant être accordés par le rôle exécutant la commande GRANT sont réellement accordés au rôle cible. Un message d’avertissement est renvoyé pour tout privilège qui n’a pas pu être accordé.

  • Les privilèges accordés à un rôle particulier sont automatiquement hérités par tous les autres rôles auxquels le rôle est accordé, ainsi que tous les autres rôles de niveau supérieur dans la hiérarchie des rôles. Pour plus de détails, voir Contrôle d’accès dans Snowflake.

  • Pour les bases de données, le privilège IMPORTED PRIVILEGES ne s’applique qu’aux bases de données partagées (c’est-à-dire les bases de données créées à partir d’un partage). Pour plus de détails, voir Consommateurs de données.

  • Pour les schémas et les objets dans les schémas, une option ALL pluriel_type_objet in conteneur est fournie pour accorder des privilèges sur tous les objets du même type dans le conteneur (c’est-à-dire la base de données ou le schéma). C’est une option pratique ; en interne, la commande est étendue en une série de commandes GRANT individuelles sur chaque objet. Seuls les objets qui existent actuellement dans le conteneur sont concernés.

    Toutefois, il est à noter que, dans le modèle de Snowflake, l’octroi de privilèges en lot n’est pas une pratique recommandée. Snowflake vous recommande plutôt de créer un rôle partagé et de l’utiliser pour créer des objets qui sont automatiquement accessibles à tous les utilisateurs auxquels le rôle a été accordé.

  • Dans les schémas d’accès gérés :

    • Le privilège OWNERSHIP sur les objets ne peut être transféré que vers un rôle subordonné du propriétaire du schéma.

  • Pour les zones de préparation :

    • USAGE ne s’applique qu’aux zones de préparation externes.

    • READ | WRITE ne s’appliquent qu’aux zones de préparation internes. De plus, pour accorder le privilège WRITE sur une zone de préparation interne, le privilège READ doit d’abord être accordé sur la zone de préparation.

    Pour plus de détails sur les zones de préparation externes et internes, voir CREATE STAGE.

  • Lorsque vous accordez des privilèges à un UDF individuel, vous devez spécifier les types de données pour les arguments, le cas échéant, pour l’UDF (sous la forme de udf_nom ( [ type_données_arg , ... ] )). Ceci est nécessaire parce que Snowflake utilise des types de données d’argument pour résoudre les UDFs qui ont le même nom dans un schéma. Pour voir un exemple, voir Exemples (dans ce chapitre). Pour plus de détails, voir Aperçu des UDFs.

Futures autorisations sur des objets de base de données ou de schéma

Les remarques de cette section s’appliquent lors de l’affectation d’autorisations futures à des objets d’un schéma ou d’une base de données ; c’est-à-dire lorsque vous utilisez le mot clé ON FUTURE.

Considérations

  • Les autorisations futures définies pour un objet au niveau de la base de données s’appliquent à tous les objets de ce type créés à l’avenir.

  • Vous devez définir les autorisations futures sur chaque type d’objet (schémas, tables, vues, flux, etc.) individuellement.

  • Les privilèges définis à l’aide d’autorisations futures sont automatiquement accordés au moment de la création de l’objet.

  • Lorsque les autorisations futures sont définies à la fois au niveau de la base de données et du schéma, les autorisations au niveau du schéma ont priorité sur les autorisations au niveau de la base de données et les autorisations au niveau de la base de données sont ignorées.

  • Les autorisations futures ne concernent que les nouveaux objets. Vous devez explicitement accorder les privilèges souhaités à un rôle sur des objets existants à l’aide de la commande GRANT <privileges> … TO ROLE.

  • Les autorisations futures au niveau de la base de données s’appliquent aux schémas d’accès réguliers et gérés.

Clonage d’objets

  • Lorsqu’une base de données est clonée, les schémas de la base de données clonée copient les autorisations futures des schémas sources. Cela maintient la cohérence avec les attributions d’objet normales, dans lesquelles les attributions de l’objet source (c’est-à-dire la base de données) ne sont pas copiées sur le clone, mais les octrois de tous les objets enfants (les schémas de la base de données) sont copiés sur les clones.

  • Lorsqu’un schéma est cloné, les autorisations futures du schéma source ne sont pas copiées sur le clone.

  • Lorsqu’un objet d’un schéma est cloné, toutes les autorisations futures définies pour ce type d’objet dans le schéma sont appliquées à l’objet cloné, sauf si l’option COPY GRANTS est spécifiée dans l’instruction CREATE <objet> pour l’opération de clonage. Dans ce cas, le nouvel objet conserve les autorisations d’accès de l’objet d’origine et n’hérite d” aucune autorisation future pour des objets de ce type.

Restrictions/Limitations

  • Les autorisations futures ne sont pas prises en charge pour :

    • Partage de données

    • Réplication de données

  • Les autorisations futures sont prises en charge sur les zones de préparation nommées avec les restrictions suivantes :

    • Le privilège WRITE ne peut pas être spécifié sans le privilège READ.

    • Le privilège READ ne peut pas être révoqué si le privilège WRITE est présent.

    • Pour les zones de préparation internes, seules les autorisations futures avec le privilège READ ou WRITE sont matérialisées.

    • Pour les zones de préparation externes, seules les autorisations futures avec les privilèges USAGE sont matérialisées.

  • Les autorisations futures ne sont pas appliquées lors du changement de nom ou de l’échange d’une table.

  • Une seule autorisation future du privilège OWNERSHIP est autorisée sur chaque type d’objet sécurisable.

  • Dans les schémas d’accès gérés :

    • Une autorisation future du privilège OWNERSHIP sur des objets ne peut être appliquée qu’à un rôle subordonné du propriétaire du schéma (c’est-à-dire le rôle qui dispose du privilège OWNERSHIP sur le schéma).

    • Avant que la propriété d’un schéma d’accès géré ne soit transférée à un rôle différent, toutes les autorisations futures ouvertes doivent être révoquées à l’aide de REVOKE <privileges> … FROM ROLE et des mots clés ON FUTURE.

Exemples

Accorder les privilèges nécessaires à l’exploitation (c’est-à-dire suspendre ou reprendre) de l’entrepôt virtuel report_wh au rôle analyst :

GRANT OPERATE ON WAREHOUSE report_wh TO ROLE analyst;

Comme dans l’exemple précédent, mais permet aussi au rôle analyst d’accorder le privilège à d’autres rôles :

GRANT OPERATE ON WAREHOUSE report_wh TO ROLE analyst WITH GRANT OPTION;

Accorder le privilège SELECT sur toutes les tables existantes dans le schéma mydb.myschema au rôle analyst :

GRANT SELECT ON ALL TABLES IN SCHEMA mydb.myschema to ROLE analyst;

Accorder tous les privilèges sur deux UDFs (avec le même nom dans le schéma actuel) au rôle analyst :

GRANT ALL PRIVILEGES ON FUNCTION add5(number) TO ROLE analyst;

GRANT ALL PRIVILEGES ON FUNCTION add5(string) TO ROLE analyst;

Notez que les UDFs ont des arguments différents, c’est ainsi que Snowflake identifie de façon unique les UDFs avec le même nom. Pour plus de détails sur les conventions d’appellation des UDF, voir Aperçu des UDFs.

Accordez le privilège de créer des vues matérialisées dans le schéma spécifié :

GRANT CREATE MATERIALIZED VIEW ON SCHEMA MyDB.MySchema TO ROLE MyRole;

Accorder les privilèges SELECT et INSERT sur toutes les futures tables créées dans le schéma mydb.myschema au rôle role1 :

GRANT SELECT,INSERT ON FUTURE TABLES IN SCHEMA mydb.myschema
TO ROLE role1;

Accordez le privilège USAGE sur tous les futurs schémas de la base de données mydb au rôle role1 :

use role accountadmin;

grant usage on future schemas in database mydb to role role1;