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

Dans ce chapitre :

Syntaxe

GRANT {  { globalPrivileges         | ALL [ PRIVILEGES ] } ON ACCOUNT
       | { accountObjectPrivileges  | ALL [ PRIVILEGES ] } ON { USER | 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 { DATABASE <db_name> | 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 {
               ACCOUNT | DATA EXCHANGE LISTING | DATABASE | INTEGRATION
               | NETWORK POLICY | ROLE | SHARE | USER | WAREHOUSE
     }
     | APPLY MASKING POLICY | APPLY ROW ACCESS POLICY | APPLY SESSION POLICY | APPLY TAG | ATTACH POLICY
     | EXECUTE TASK | IMPORT SHARE | MANAGE GRANTS | MONITOR { EXECUTION | USAGE } | OVERRIDE SHARE RESTRICTIONS
  }
  [ , ... ]
accountObjectPrivileges ::=
-- For USER
  { MONITOR } [ , ... ]
-- For RESOURCE MONITOR
  { MODIFY | MONITOR } [ , ... ]
-- For WAREHOUSE
  { MODIFY | MONITOR | USAGE | OPERATE } [ , ... ]
-- 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 | ROW ACCESS POLICY | SESSION POLICY
                 | TAG | SEQUENCE | FUNCTION | PROCEDURE | FILE FORMAT | STAGE | PIPE | STREAM | TASK
              }
     | ADD SEARCH OPTIMIZATION
  }
  [ , ... ]
schemaObjectPrivileges ::=
-- For TABLE
  { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES } [ , ... ]
-- For VIEW
  { SELECT | REFERENCES } [ , ... ]
-- For MATERIALIZED VIEW
  { SELECT | REFERENCES } [ , ... ]
-- For SEQUENCE, FUNCTION (UDF or external function), PROCEDURE, or FILE FORMAT
    USAGE
-- For internal STAGE
    READ [ , WRITE ]
-- For external STAGE
    USAGE
-- For PIPE
   { MONITOR | OPERATE } [ , ... ]
-- For STREAM
    SELECT
-- For TASK
   { MONITOR | OPERATE } [ , ... ]
-- For MASKING POLICY
    APPLY
-- For ROW ACCESS POLICY
    APPLY
-- For SESSION POLICY
    APPLY
-- For TAG
    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

object_name

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

object_type

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

TABLE | EXTERNAL TABLE | VIEW | MATERIALIZED VIEW | MASKING POLICY | ROW ACCESS POLICY | SESSION POLICY | SEQUENCE | FUNCTION | PROCEDURE | FILE FORMAT | STAGE | PIPE | STREAM | TASK

object_type_plural

Forme plurielle de object_type (par exemple, TABLES, VIEWS).

Notez que les autorisations globales sur les canaux ne sont pas autorisées.

role_name

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

  • Pour accorder le privilège OWNERSHIP sur un objet (ou tous les objets d’un type spécifié dans un schéma) à un rôle, en transférant la propriété de l’objet d’un rôle à un autre, utilisez plutôt GRANT OWNERSHIP . La commande GRANT OWNERSHIP a une syntaxe différente.

  • 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 object_type_plural in container 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 à une UDF individuelle ou à une procédure stockée, vous devez spécifier les types de données des arguments, le cas échéant, à l’aide de la syntaxe indiquée ci-dessous :

    <udf_or_stored_procedure_name> ( [ <arg_data_type> [ , ... ] ] )
    

    Snowflake utilise des types de données d’argument pour résoudre des UDFs ou des procédures stockées qui ont le même nom dans un schéma. Pour plus d’informations, voir :

    Pour voir un exemple, voir Exemples (dans ce chapitre) et Surcharge de noms de procédures stockées.

Exigences en matière de contrôle d’accès

Accorder des privilèges sur des objets individuels

En général, un rôle possédant l’un des ensembles de privilèges suivants peut accorder des privilèges sur un objet à d’autres rôles :

  • Le privilège MANAGE GRANTS global.

    Seuls les rôles système SECURITYADMIN et ACCOUNTADMIN ont le privilège MANAGE GRANTS ; cependant, le privilège peut être accordé à des rôles personnalisés.

  • Le privilège OWNERSHIP sur l’objet. Lors de l’accord de privilèges sur des objets de schéma (par exemple, des tables et des vues), le rôle doit avoir le privilège USAGE sur la base de données et le schéma parents.

  • Si un privilège a été accordé à un rôle dont le paramètre WITH GRANT OPTION est inclus dans l’instruction GRANT <privilèges> … TO ROLE, le rôle peut accorder le même privilège à d’autres rôles.

Dans les schémas d’accès géré, (c’est-à-dire les schémas créés avec la syntaxe CREATE SCHEMA … WITH MANAGED ACCESS), les propriétaires d’objets perdent la capacité de prendre des décisions d’attribution. Seul le propriétaire du schéma (c’est-à-dire le rôle doté du privilège OWNERSHIP sur le schéma) ou un rôle doté du privilège global MANAGE GRANTS peut octroyer des privilèges sur les objets du schéma.

Notez qu’un rôle qui détient le privilège global MANAGE GRANTS peut accorder des privilèges supplémentaires au rôle actuel (concédant).

Définition des autorisations sur les futurs objets d’un type spécifié

Niveau base de données

Le privilège global MANAGE GRANTS est requis pour accorder des privilèges sur des objets futurs dans une base de données. Seuls les rôles système SECURITYADMIN et ACCOUNTADMIN ont le privilège MANAGE GRANTS ; cependant, le privilège peut être accordé à des rôles personnalisés.

Niveau de schéma

Dans les schémas d’accès géré (c’est-à-dire les schémas créés à l’aide de la syntaxe CREATE SCHEMA … WITH MANAGED ACCESS), soit le propriétaire du schéma (c’est-à-dire le rôle avec le privilège OWNERSHIP sur le schéma) ou un rôle avec le privilège global MANAGE GRANTS peut accorder des privilèges sur de futurs objets dans le schéma.

Dans les schémas standards, le privilège global MANAGE GRANTS est requis pour accorder des privilèges sur des objets futurs au sein du schéma.

Pour plus d’informations sur la définition des attributions sur les futurs objets d’un type spécifié, consultez Futures autorisations sur des objets de base de données ou de schéma (dans cette rubrique).

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.

Pour plus d’informations, voir les schémas d’accès gérés.

Considérations

  • Lorsque les autorisations futures sont définies sur le même type d’objet pour une base de données et un schéma dans la même base, 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. Ce comportement s’applique aux privilèges sur les objets futurs accordés à un rôle ou à différents rôles.

    Par exemple, les instructions suivantes accordent des privilèges différents sur les objets du même type au niveau de la base de données et du schéma.

    Accorder le privilège SELECT sur tous les futurs schémas de la base de données d1 au rôle r1 :

    GRANT SELECT ON FUTURE TABLES IN DATABASE d1 TO ROLE r1;
    

    Accorder les privilèges INSERT et DELETE sur toutes les futures tables créées dans le schéma d1.s1 au rôle r2.

    GRANT INSERT,DELETE ON FUTURE TABLES IN SCHEMA d1.s1 TO ROLE r2;
    

    Les autorisations futures attribuées au rôle r1 sont complètement ignorées. Lorsque de nouvelles tables sont créées dans le schéma d1.s1, seuls les privilèges futurs définis dans les tables du rôle r2 sont autorisés.

  • 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.

Restrictions/Limitations

  • Les autorisations futures ne peuvent pas être définies sur les objets des types suivants :

    • Fonction externe

    • Objets de politique :

      • Politique de masquage

      • Politique d’accès aux lignes

      • Politique de session

    • Balise

  • 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 du privilège OWNERSHIP 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 dans le schéma mydb.myschema au rôle analyst :

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

GRANT ALL PRIVILEGES ON FUNCTION mydb.myschema.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.

Accorder le privilège d’utilisation d’une procédure stockée dans le schéma mydb.myschema au rôle analyst :

GRANT USAGE ON PROCEDURE mydb.myschema.myprocedure(number) TO ROLE analyst;

Notez que les noms de procédures stockées (comme les noms des UDF) peuvent être surchargés, vous devez donc spécifier le type de données des arguments. Pour plus de détails sur le surchargement des procédures stockées, voir Surcharge de noms.

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;
Revenir au début