GRANT <privilèges> … TO USER¶

Accorde un ou plusieurs privilèges d’accès sur un objet sécurisable à un utilisateur. Les privilèges qui peuvent être accordés sont spécifiques à chaque objet.

Pour plus d’informations sur les rôles et les objets sécurisables, consultez Aperçu du contrôle d’accès.

Pour plus d’informations sur ces privilèges, voir Privilèges de contrôle d’accès.

Voir aussi :: GRANT <privilèges> … TO ROLE, REVOKE <privilèges> … FROM USER

Syntaxe¶

GRANT {  { globalPrivileges         | ALL [ PRIVILEGES ] } ON ACCOUNT
       | { accountObjectPrivileges  | ALL [ PRIVILEGES ] } ON { USER | RESOURCE MONITOR | WAREHOUSE | COMPUTE POOL | DATABASE | INTEGRATION | CONNECTION | FAILOVER GROUP | REPLICATION GROUP | EXTERNAL VOLUME } <object_name>
       | { schemaPrivileges         | ALL [ PRIVILEGES ] } ON { SCHEMA <schema_name> | ALL SCHEMAS IN DATABASE <db_name> }
       | { schemaObjectPrivileges   | ALL [ PRIVILEGES ] } ON { <object_type> <object_name> | ALL <object_type_plural> IN { DATABASE <db_name> | SCHEMA <schema_name> } }
      }
  TO [ USER ] <user_name> [ WITH GRANT OPTION ]

Copy

Où :

globalPrivileges ::=
  {
      | ATTACH POLICY | AUDIT | BIND SERVICE ENDPOINT
      | APPLY {
         { AGGREGATION | AUTHENTICATION | JOIN | MASKING | PACKAGES | PASSWORD
           | PROJECTION | ROW ACCESS | SESSION } POLICY
         | TAG }
      | EXECUTE { ALERT | DATA METRIC FUNCTION | MANAGED ALERT | MANAGED TASK | TASK }
      | IMPORT SHARE
      | MANAGE { ACCOUNT SUPPORT CASES | EVENT SHARING | GRANTS | LISTING AUTO FULFILLMENT | ORGANIZATION SUPPORT CASES | USER SUPPORT CASES | WAREHOUSES }
      | MODIFY { LOG LEVEL | TRACE LEVEL | SESSION LOG LEVEL | SESSION TRACE LEVEL }
      | MONITOR { EXECUTION | SECURITY | USAGE }
      | OVERRIDE SHARE RESTRICTIONS | PURCHASE DATA EXCHANGE LISTING | RESOLVE ALL
      | READ SESSION
  }
  [ , ... ]

Copy

accountObjectPrivileges ::=
-- For COMPUTE POOL
   { MODIFY | MONITOR | OPERATE | USAGE } [ , ... ]
-- For CONNECTION
   { FAILOVER } [ , ... ]
-- For DATABASE
   { APPLYBUDGET
   | IMPORTED PRIVILEGES | MODIFY | MONITOR | USAGE } [ , ... ]
-- For EXTERNAL VOLUME
   { USAGE } [ , ... ]
-- For FAILOVER GROUP
   { FAILOVER | MODIFY | MONITOR | REPLICATE } [ , ... ]
-- For INTEGRATION
   { USAGE | USE_ANY_ROLE } [ , ... ]
-- For REPLICATION GROUP
   { MODIFY | MONITOR | REPLICATE } [ , ... ]
-- For RESOURCE MONITOR
   { MODIFY | MONITOR } [ , ... ]
-- For USER
   { MONITOR } [ , ... ]
-- For WAREHOUSE
   { APPLYBUDGET | MODIFY | MONITOR | USAGE | OPERATE } [ , ... ]

Copy

schemaPrivileges ::=

    ADD SEARCH OPTIMIZATION | APPLYBUDGET
   | MODIFY | MONITOR | USAGE
   [ , ... ]

Copy

schemaObjectPrivileges ::=
  -- For ALERT
     { MONITOR | OPERATE } [ , ... ]
  -- For DATA METRIC FUNCTION
     USAGE [ , ... ]
  -- For DYNAMIC TABLE
     MONITOR, OPERATE, SELECT [ , ...]
  -- For EVENT TABLE
     { APPLYBUDGET | DELETE | REFERENCES | SELECT | TRUNCATE } [ , ... ]
  -- For FILE FORMAT, FUNCTION (UDF or external function), MODEL, PROCEDURE, SECRET, SEQUENCE, or SNAPSHOT
     USAGE [ , ... ]
  -- For GIT REPOSITORY
     { READ, WRITE } [ , ... ]
  -- For HYBRID TABLE
     { APPLYBUDGET | DELETE | INSERT | REFERENCES | SELECT | TRUNCATE | UPDATE } [ , ... ]
  -- For IMAGE REPOSITORY
     { READ, WRITE } [ , ... ]
  -- For ICEBERG TABLE
     { APPLYBUDGET | DELETE | INSERT | REFERENCES | SELECT | TRUNCATE | UPDATE } [ , ... ]
  -- For MATERIALIZED VIEW
     { APPLYBUDGET | REFERENCES | SELECT } [ , ... ]
  -- For PIPE
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For { AGGREGATION | AUTHENTICATION | MASKING | JOIN | PACKAGES | PASSWORD | PRIVACY | PROJECTION | ROW ACCESS | SESSION } POLICY or TAG
     APPLY [ , ... ]
  -- For SECRET
     { READ | USAGE } [ , ... ]
  -- For SEMANTIC VIEW
     REFERENCES [ , ... ]
  -- For SERVICE
     { MONITOR | OPERATE } [ , ... ]
  -- For external STAGE
     USAGE [ , ... ]
  -- For internal STAGE
     READ [ , WRITE ] [ , ... ]
  -- For STREAM
     SELECT [ , ... ]
  -- For STREAMLIT
     USAGE [ , ... ]
  -- For TABLE
     { APPLYBUDGET | DELETE | EVOLVE SCHEMA | INSERT | REFERENCES | SELECT | TRUNCATE | UPDATE } [ , ... ]
  -- For TAG
     READ
  -- For TASK
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For VIEW
     { REFERENCES | SELECT } [ , ... ]

Copy

Pour plus d’informations 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

Spécifie le type d’objet pour les objets au niveau du schéma.

AGGREGATION POLICY
ALERT
AUTHENTICATION POLICY
CORTEX SEARCH SERVICE
DATA METRIC FUNCTION
DATASET
DYNAMIC TABLE
EVENT TABLE
EXTERNAL TABLE
FILE FORMAT
FUNCTION
GIT REPOSITORY
IMAGE REPOSITORY
ICEBERG TABLE
JOIN POLICY
MASKING POLICY
MATERIALIZED VIEW
MODEL
MODEL MONITOR
NETWORK RULE
NOTEBOOK
PACKAGES POLICY
PASSWORD POLICY
PIPE
PRIVACY POLICY
PROCEDURE
PROJECTION POLICY
ROW ACCESS POLICY
SECRET
SEMANTIC VIEW
SERVICE
SESSION POLICY
SEQUENCE
SNAPSHOT
STAGE
STREAM
STREAMLIT
TABLE
TAG
TASK
VIEW

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.

user_name

Spécifie l’identificateur de l’utilisateur destinataire (l’utilisateur auquel les privilèges sont accordés).

Paramètres facultatifs¶

WITH GRANT OPTION

Si cette valeur est spécifiée, permet à l’utilisateur destinataire d’accorder les privilèges à d’autres rôles ou utilisateurs.

Par défaut : aucune valeur, ce qui signifie que le rôle destinataire ne peut pas accorder les privilèges à d’autres rôles ou utilisateurs.

Note

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

Notes sur l’utilisation¶

Les privilèges attribués directement aux utilisateurs ne sont effectifs que si tous les rôles secondaires de l’utilisateur sont activés.
L’octroi de privilèges directement aux utilisateurs peut accroître la prolifération d’octrois dans votre compte. En dehors des scénarios de partage de personne à personne, nous vous recommandons d’accorder des privilèges aux rôles pour gérer l’accès dont les utilisateurs ont besoin dans Snowflake.
Les octrois futurs ne sont pas disponibles.
Les privilèges CREATE et OWNERSHIP ne peuvent pas être accordés aux utilisateurs.

Les privilèges ne peuvent pas être accordées ou révoquées directement dans une classe.

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). Il est également possible d’utiliser le mot-clé spécial ALL [ PRIVILEGES ] pour accorder tous les privilèges applicables au type d’objet spécifié.
Note
- Seuls les privilèges détenus et pouvant être accordés par l’utilisateur qui exécute la commande GRANT sont effectivement accordés au rôle cible. Un message d’avertissement est renvoyé pour tout privilège non accordé.
- Vous ne pouvez pas spécifier ALL [ PRIVILEGES ] pour des balises.
- ALL [ PRIVILEGES ] n’accorde pas de privilèges sur une classe si vous essayez d’accorder ALL [ PRIVILEGES ] sur un schéma.

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). Cette option est pratique. En interne, la commande est développée en une série de commandes GRANT individuelles sur chaque objet. Cette option n’affecte que les objets qui existent actuellement dans le conteneur.

Note

L’octroi de privilèges en masse n’est pas une pratique recommandée dans le modèle Snowflake. Snowflake recommande plutôt de créer un rôle partagé, puis d’utiliser ce rôle pour créer des objets automatiquement accessibles à tous les utilisateurs auxquels le rôle a été accordé.

Vous ne pouvez pas spécifier ALL TAGS ou ALL MASKING POLICIES.

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 d’informations sur les zones de préparation externes et internes, consultez CREATE STAGE.
Lorsque vous accordez des privilèges à une UDF ou à une procédure stockée individuelle, vous devez spécifier les types de données des arguments, le cas échéant, à l’aide d’une syntaxe telle que 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 Surcharge de procédures et de fonctions.
Pour les tables dynamiques, l’utilisateur destinataire doit se voir accorder le privilège USAGE sur la base de données et le schéma qui contient la table dynamique, ainsi que sur l’entrepôt utilisé pour actualiser la table. Pour plus d’informations, voir Contrôle de l’accès aux tables dynamiques.
Lorsque vous accordez des privilèges à une UDF individuelle, vous devez spécifier les types de données des arguments, le cas échéant, pour l’UDF en utilisant une syntaxe telle que udf_name ( [ arg_data_type , ... ] ). Ceci est nécessaire, car 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 plus d’informations, voir Vue d’ensemble des fonctions définies par l’utilisateur.
Lorsque vous accordez des privilèges à une procédure stockée individuelle, vous devez spécifier les types de données des arguments, le cas échéant, de la procédure à l’aide d’une syntaxe telle que procedure_name ( [ arg_data_type , ... ] ). Ceci est nécessaire parce que Snowflake utilise des types de données d’argument pour résoudre les procédures stockées qui ont le même nom dans un schéma.

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

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 ou un utilisateur disposant de l’un des privilèges suivants peut accorder des privilèges sur un objet à d’autres utilisateurs :

Le privilège MANAGE GRANTS global.

Seuls les rôles système SECURITYADMIN et ACCOUNTADMIN disposent du privilège MANAGE GRANTS ; toutefois, ce privilège peut être accordé à des rôles personnalisés ou à des utilisateurs.
Le privilège OWNERSHIP.

Le rôle qui a le privilège OWNERSHIP sur l’objet.
Le privilège USAGE. Lors de l’octroi de privilèges sur des objets de schéma (par exemple, des tables et des vues), le rôle ou l’utilisateur doit également disposer du privilège USAGE sur la base de données et le schéma parents.

Si un privilège a été accordé à un utilisateur à l’aide de la commande GRANT privileges ... TO USER WITH GRANT OPTION, cet utilisateur peut réattribuer ce même privilège à d’autres utilisateurs ou rôles.

Dans les schémas d’accès gérés (schémas créés à l’aide de la syntaxe CREATE SCHEMA ... WITH MANAGED ACCESS), les propriétaires d’objets perdent la possibilité de prendre des décisions d’octroi. Seul le propriétaire du schéma (le rôle disposant du privilège OWNERSHIP sur le schéma) ou un rôle disposant du privilège MANAGE GRANTS global peut accorder des privilèges sur des objets de ce schéma.

Note

Un rôle qui détient le privilège MANAGE GRANTS global peut accorder des privilèges supplémentaires au rôle ou à l’utilisateur actuel (concédant).

Exemples¶

Pour accorder le privilège USAGE sur une application Streamlit à un utilisateur spécifique, joe :

GRANT USAGE ON STREAMLIT streamlit_db.streamlit_schema.streamlit_app TO USER joe;

Copy

Pour accorder le privilège USAGE sur une procédure à un utilisateur spécifique, user1 :

GRANT USAGE ON PROCEDURE mydb.myschema.myprocedure(number) TO USER user1;

Copy