REVOKE <privilèges>¶

Supprime un ou plusieurs privilèges sur un objet sécurisable d’un rôle ou d’un rôle de base de données. Les privilèges qui peuvent être révoqués sont spécifiques à chaque objet.

Rôles:

Les privilèges qui peuvent être révoqués de rôles 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)

Rôles de base de données:

Les privilèges qui peuvent être révoqués de rôles de base de données sont regroupés dans les catégories suivantes :

Privilèges pour la base de données qui contient le rôle de base de données.
Privilèges pour les schémas de la base de données qui contient le rôle de base de données.
Privilèges pour les objets de schéma (tables, vues, zones de préparation, formats de fichiers, UDFs et séquences) dans la base de données qui contient le rôle de base de données.

Voir aussi :

GRANT <privilèges> , GRANT OWNERSHIP

REVOKE <privilège> … FROM SHARE

Syntaxe¶

Rôles de comptes :

REVOKE [ GRANT OPTION FOR ]
    {
       { globalPrivileges         | ALL [ PRIVILEGES ] } ON ACCOUNT
     | { accountObjectPrivileges  | ALL [ PRIVILEGES ] } ON { RESOURCE MONITOR | WAREHOUSE | COMPUTE POOL | DATABASE | INTEGRATION | FAILOVER GROUP | REPLICATION GROUP | EXTERNAL VOLUME } <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> }
    }
  FROM [ ROLE ] <role_name> [ RESTRICT | CASCADE ]

Copy

Rôles de base de données :

REVOKE [ GRANT OPTION FOR ]
    {
       { CREATE SCHEMA | MODIFY | MONITOR | USAGE } [ , ... ] } ON DATABASE <object_name>
       { globalPrivileges         | ALL [ PRIVILEGES ] } ON ACCOUNT
     | { accountObjectPrivileges  | ALL [ PRIVILEGES ] } ON { RESOURCE MONITOR | WAREHOUSE | COMPUTE POOL | DATABASE | INTEGRATION | EXTERNAL VOLUME } <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> }
    }
  FROM DATABASE ROLE <database_role_name> [ RESTRICT | CASCADE ]

Copy

Où :

globalPrivileges ::=
  {
      CREATE {
                ACCOUNT | COMPUTE POOL | DATA EXCHANGE LISTING | DATABASE | FAILOVER GROUP | INTEGRATION
                | NETWORK POLICY | EXTERNAL VOLUME | REPLICATION GROUP | ROLE | SHARE
                | USER | WAREHOUSE
      }
      | APPLY { { AGGREGATION | AUTHENTICATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY | TAG }
      | ATTACH POLICY | AUDIT | BIND SERVICE ENDPOINT
      | EXECUTE { ALERT | TASK }
      | IMPORT SHARE
      | MANAGE { GRANTS | LISTING AUTO FULFILLMENT | 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
  }
  [ , ... ]

Copy

accountObjectPrivileges ::=
-- For COMPUTE POOL
   { MODIFY | MONITOR | OPERATE | USAGE } [ , ... ]
-- For DATABASE
   { APPLYBUDGET | CREATE { DATABASE ROLE | SCHEMA } | 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

| CREATE {
      ALERT | DYNAMIC TABLE | EXTERNAL TABLE | FILE FORMAT | FUNCTION | HYBRID TABLE | IMAGE REPOSITORY |
      | ICEBERG TABLE | MATERIALIZED VIEW | MODEL | NETWORK RULE | PIPE | PROCEDURE
      | { AGGREGATION | AUTHENTICATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY | SERVICE
      | SECRET | SEQUENCE | STAGE | STREAM | STREAMLIT
      | SNOWFLAKE.CORE.BUDGET |
      | SNOWFLAKE.ML.ANOMALY_DETECTION | SNOWFLAKE.ML.FORECAST
      | TAG | TABLE | TASK | VIEW
  }
| MODIFY | MONITOR | USAGE
[ , ... ]

Copy

schemaObjectPrivileges ::=
  -- For ALERT
     { MONITOR | OPERATE } [ , ... ]
  -- For DYNAMIC TABLE
     MONITOR, OPERATE, SELECT [ , ...]
  -- For EVENT TABLE
     { INSERT | SELECT } [ , ... ]
  -- For FILE FORMAT, FUNCTION (UDF or external function), MODEL, PROCEDURE, SECRET, or SEQUENCE
     USAGE [ , ... ]
  -- For HYBRID TABLE
     { INSERT | SELECT | UPDATE } [ , ... ]
  -- For IMAGE REPOSITORY
     { READ, WRITE } [ , ... ]
  -- For ICEBERG TABLE
     { APPLYBUDGET | DELETE | INSERT | REFERENCES | SELECT | TRUNCATE | UPDATE } [ , ... ]
  -- For PIPE
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For { AGGREGATION | AUTHENTICATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY or TAG
     APPLY [ , ... ]
  -- For SECRET
     READ, USAGE [ , ... ]
  -- For SERVICE
     { USAGE | 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 } [ , ... ]
  -- For MATERIALIZED VIEW
     { APPLYBUDGET | REFERENCES | SELECT } [ , ... ]

Copy

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 révoqués.

object_type

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

AGGREGATION POLICY
ALERT
AUTHENTICATION POLICY
DYNAMIC TABLE
EVENT TABLE
EXTERNAL TABLE
FILE FORMAT
FUNCTION
HYBRID TABLE
IMAGE REPOSITORY
ICEBERG TABLE
MASKING POLICY
MATERIALIZED VIEW
MODEL
NETWORK RULE
PACKAGES POLICY
PASSWORD POLICY
PIPE
PROCEDURE
PROJECTION POLICY
ROW ACCESS POLICY
SECRET
SERVICE
SESSION POLICY
SEQUENCE
STAGE
STREAM
TABLE
TAG
TASK
VIEW

object_type_plural: Forme plurielle de object_type (par exemple, TABLES, VIEWS).
role_name: Spécifie l’identificateur du rôle du destinataire (c’est-à-dire le rôle dont les privilèges sont révoqués).
database_role_name: Spécifie l’identificateur du rôle de base de données du destinataire (c’est-à-dire le rôle dont les privilèges sont révoqués). Si l’identificateur n’est pas complet (sous la forme de db_name.database_role_name), la commande recherche le rôle de base de données dans la base de données actuelle de la session.

Paramètres facultatifs¶

GRANT OPTION FOR

Si spécifié, supprime la possibilité pour le rôle destinataire d’accorder des privilèges à un autre rôle.

Par défaut : aucune valeur

ON FUTURE

Si spécifié, supprime uniquement les privilèges accordés sur les nouveaux objets de schéma (futurs) d’un type spécifié (par exemple, tables ou vues) plutôt que sur les objets existants. Notez que tous les privilèges accordés sur les objets existants sont conservés.

RESTRICT | CASCADE

Si spécifié, détermine si l’opération de révocation réussit ou échoue pour les privilèges, en fonction du fait que les privilèges ont été réattribués à un autre rôle.

RESTRICT : si le privilège révoqué a été réattribué à un autre rôle, la commande REVOKE échoue.
CASCADE : si le privilège révoqué a été réattribué, la commande REVOKE révoque récursivement ces autorisations dépendantes. Si le même privilège sur un objet a été accordé au rôle cible par un autre concédant (accord parallèle), cette autorisation ne sera pas affectée et le rôle cible conservera le privilège.

Par défaut : RESTRICT

Exigences en matière de sécurité¶

Révoquer des privilèges sur des objets individuels:

Un rôle actif qui répond à l’un des critères suivants, ou un rôle supérieur, peut être utilisé pour révoquer les privilèges d’autres rôles sur un objet :

Le rôle est identifié comme le donneur du privilège dans la colonne GRANTED_BY de la sortie SHOW GRANTS.

Si plusieurs instances d’un privilège ont été accordées sur l’objet spécifié, seules les instances accordées par le rôle de donneur actif sont révoquées.
Le rôle possède le privilège global MANAGE GRANTS.

Si plusieurs instances d’un privilège ont été accordées sur l’objet spécifié, toutes les instances sont révoquées.

Notez que seuls les rôles système SECURITYADMIN et supérieurs disposent du privilège MANAGE GRANTS par défaut ; toutefois, ce privilège peut être accordé aux rôles personnalisés.

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), seul 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, ou un rôle supérieur, peut révoquer des privilèges sur des objets dans le schéma.

Révocation 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 révoquer des privilèges sur des objets futurs dans une base de données. Seuls les rôles système SECURITYADMIN et supérieurs 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 révoquer 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 révoquer des privilèges sur des objets futurs au sein du schéma.

Notes sur l’utilisation¶

Les privilèges ne peuvent pas être accordées ou révoquées directement dans une classe. Vous pouvez toutefois créer une instance d’une classe et révoquer des rôles d’instance d’un rôle de compte. Révoquer le privilège CREATE <nom_classe> sur le schéma pour empêcher un rôle de créer une instance d’une classe.
Un privilège peut être accordé à un rôle plusieurs fois par différents concédants. Un instruction de <privilège> REVOKE ne révoque que les autorisations pour lesquelles le rôle actif, ou un rôle inférieur dans une hiérarchie, est le concédant. Toute attribution supplémentaire d’un privilège spécifié par d’autres concédants est ignoré.

Notez également qu’une instruction de <privilège> REVOKE est réussie même si aucun privilège n’est révoqué. Une instruction de <privilège> REVOKE renvoie une erreur uniquement si un privilège spécifié possède des autorisations dépendantes et si la clause CASCADE est omise dans l’instruction.
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é.

Vous ne pouvez pas spécifier ce mot-clé pour les balises.
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 Aperçu du contrôle d’accès.
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 Consommation de données partagées.
Pour les schémas et les objets dans les schémas, une option 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é.
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_name ( [ arg_data_type , ... ] ). 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 Vue d’ensemble des fonctions définies par l’utilisateur.
Lorsque vous accordez des privilèges à une procédure stockée particulière, vous devez spécifier les types de données pour les arguments, le cas échéant, pour la procédure sous la forme de 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.
Autorisations futures : la révocation des autorisations futures ne supprime que les autorisations de privilèges pour des objets futurs d’un type spécifié. Les privilèges accordés sur les objets existants sont conservés.

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

Exemples¶

Rôles¶

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

REVOKE OPERATE ON WAREHOUSE report_wh FROM ROLE analyst;

Copy

Révoquez uniquement l”option d’autorisation pour le privilège OPERATE sur l’entrepôt report_wh du rôle analyst . Le rôle conserve le privilège OPERATE mais ne peut plus accorder le privilège OPERATE sur l’entrepôt aux autres rôles :

REVOKE GRANT OPTION FOR OPERATE ON WAREHOUSE report_wh FROM ROLE analyst;

Copy

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

REVOKE SELECT ON ALL TABLES IN SCHEMA mydb.myschema from ROLE analyst;

Copy

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

REVOKE ALL PRIVILEGES ON FUNCTION add5(number) FROM ROLE analyst;

REVOKE ALL PRIVILEGES ON FUNCTION add5(string) FROM ROLE analyst;
Copy
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 Vue d’ensemble des fonctions définies par l’utilisateur.

Révoquer tous les privilèges sur deux procédures stockées (avec le même nom dans le schéma actuel) du rôle analyst :

REVOKE ALL PRIVILEGES ON PROCEDURE clean_schema(string) FROM ROLE analyst;

REVOKE ALL PRIVILEGES ON procedure clean_schema(string, string) FROM ROLE analyst;
Copy
Notez que les deux procédures stockées ont des arguments différents, c’est ainsi que Snowflake identifie de façon unique les procédures avec le même nom.

Révoquez les privilèges SELECT et INSERT accordés sur toutes les futures tables créées dans le schéma mydb.myschema à partir du rôle role1 :

REVOKE SELECT,INSERT ON FUTURE TABLES IN SCHEMA mydb.myschema
FROM ROLE role1;

Copy

Rôles de base de données¶

Révoquer le privilège SELECT sur toutes les tables existantes dans le schéma mydb.myschema au rôle de base de données mydb.dr1 :

REVOKE SELECT ON ALL TABLES IN SCHEMA mydb.myschema
  FROM DATABASE ROLE mydb.dr1;

Copy

Révoquer tous les privilèges sur deux UDFs (avec le même nom dans le schéma actuel) du rôle de base de données mydb.dr1 :

REVOKE ALL PRIVILEGES ON FUNCTION add5(number)
  FROM DATABASE ROLE mydb.dr1;

REVOKE ALL PRIVILEGES ON FUNCTION add5(string)
  FROM DATABASE ROLE mydb.dr1;
Copy
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 Vue d’ensemble des fonctions définies par l’utilisateur.

Révoquer tous les privilèges sur deux procédures stockées (avec le même nom dans le schéma actuel) du rôle de base de données mydb.dr1 :

REVOKE ALL PRIVILEGES ON PROCEDURE clean_schema(string)
  FROM DATABASE ROLE mydb.dr1;

REVOKE ALL PRIVILEGES ON procedure clean_schema(string, string)
  FROM DATABASE ROLE mydb.dr1;
Copy
Notez que les deux procédures stockées ont des arguments différents, c’est ainsi que Snowflake identifie de façon unique les procédures avec le même nom.

Révoquer les privilèges SELECT et INSERT accordés sur toutes les futures tables créées dans le schéma mydb.myschema à partir du rôle de base de données mydb.dr1 :

REVOKE SELECT,INSERT ON FUTURE TABLES IN SCHEMA mydb.myschema
  FROM DATABASE ROLE mydb.dr1;

Copy