REVOKE <privilèges> FROM APPLICATION

Révoque un ou plusieurs privilèges d’accès sur un objet sécurisé d’une application. Les privilèges qui peuvent être révoqués sont spécifiques à chaque objet.

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

Variations :

GRANT <privileges> … TO APPLICATION

Syntaxe

REVOKE {  { globalPrivileges } 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> }
       }
     FROM APPLICATION <name>
Copy

Où :

globalPrivileges ::=
  {
      CREATE {
       COMPUTE POOL | DATABASE | WAREHOUSE
      }
      | BIND SERVICE ENDPOINT
      | EXECUTE MANAGED TASK
      | MANAGE WAREHOUSES
      | READ SESSION
  }
  [ , ... ]
Copy
accountObjectPrivileges ::=
-- For COMPUTE POOL
   { MODIFY | MONITOR | OPERATE | USAGE } [ , ... ]
-- For CONNECTION
   { FAILOVER } [ , ... ]
-- 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
| CREATE {
    ALERT | EXTERNAL TABLE | FILE FORMAT | FUNCTION
    | IMAGE REPOSITORY | MATERIALIZED VIEW | PIPE | PROCEDURE
    | { AGGREGATION | MASKING | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY
    | SECRET | SEQUENCE | SERVICE | SNAPSHOT | STAGE | STREAM
    | TAG | TABLE | TASK | VIEW
  }
| MODIFY | MONITOR | USAGE
[ , ... ]
Copy
schemaObjectPrivileges ::=
  -- For ALERT
     { MONITOR | OPERATE } [ , ... ]
  -- For DYNAMIC TABLE
     OPERATE, SELECT [ , ...]
  -- For EVENT TABLE
     { INSERT | SELECT } [ , ... ]
  -- For FILE FORMAT, FUNCTION (UDF or external function), PROCEDURE, SECRET, SEQUENCE, or SNAPSHOT
     USAGE [ , ... ]
  -- For IMAGE REPOSITORY
     { READ, WRITE } [ , ... ]
  -- For PIPE
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For { MASKING | PACKAGES | PASSWORD | ROW ACCESS | SESSION } POLICY or TAG
     APPLY [ , ... ]
  -- For SECRET
     READ, USAGE [ , ... ]
  -- For SERVICE
     { MONITOR | OPERATE } [ , ... ]
  -- For external STAGE
     USAGE [ , ... ]
  -- For internal STAGE
     READ [ , WRITE ] [ , ... ]
  -- For STREAM
     SELECT [ , ... ]
  -- 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 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.

  • ALERT

  • DYNAMIC TABLE

  • EVENT TABLE

  • EXTERNAL TABLE

  • FILE FORMAT

  • FUNCTION

  • MASKING POLICY

  • MATERIALIZED VIEW

  • NETWORK RULE

  • PACKAGES POLICY

  • PASSWORD POLICY

  • PIPE

  • PROCEDURE

  • ROW ACCESS POLICY

  • SECRET

  • SESSION POLICY

  • SEQUENCE

  • STAGE

  • STREAM

  • TABLE

  • TAG

  • TASK

  • VIEW

object_type_plural

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

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

name

Spécifie l’identificateur de l’application destinataire (le rôle auquel les privilèges sont accordés).

Exigences en matière de sécurité

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

Vous pouvez utiliser un rôle actif qui répond à l’un des critères suivants, ou un rôle supérieur, 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 vous avez plusieurs instances d’un privilège accordées sur l’objet spécifié, seules les instances accordées par le rôle du concédant actif de privilèges sont révoquées.

  • Le rôle possède le privilège global MANAGE GRANTS.

    Si vous avez plusieurs instances d’un privilège 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é (les schémas créés à l’aide de la syntaxe CREATE SCHEMA … WITH MANAGED ACCESS), seul le propriétaire du schéma (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.

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.

  • 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 Consommer des 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 (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 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.

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

Exemple

Révoquer le privilège SELECT sur une vue à partir d’une application :

REVOKE SELECT ON VIEW data.views.credit_usage
  FROM APPLICATION app_snowflake_credits;
Copy
Langage: Français