GRANT <privilèges> … TO APPLICATION ROLE

Attribue à un rôle d’application un ou plusieurs privilèges d’accès à un objet sécurisé au niveau du schéma. Les privilèges qui peuvent être accordé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 OWNERSHIP , REVOKE <privilèges> FROM APPLICATION ROLE

Syntaxe

GRANT {
        { schemaPrivileges         | ALL [ PRIVILEGES ] } ON SCHEMA <schema_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 SCHEMA <schema_name>
      }
    TO APPLICATION ROLE <name> [ WITH GRANT OPTION ]
Copy

Où :

schemaPrivileges ::=
ADD SEARCH OPTIMIZATION
| CREATE {
    ALERT | EXTERNAL TABLE | FILE FORMAT | FUNCTION
    | MATERIALIZED VIEW | PIPE | PROCEDURE
    | { AGGREGATION | MASKING | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY
    | SECRET | SEQUENCE | 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, or SEQUENCE
     USAGE [ , ... ]
  -- For PIPE
     { APPLYBUDGET | MONITOR | OPERATE } [ , ... ]
  -- For { AGGREGATION | MASKING | PACKAGES | PASSWORD | PROJECTION | ROW ACCESS | SESSION } POLICY or TAG
     APPLY [ , ... ]
  -- For SECRET
     READ, USAGE [ , ... ]
  -- 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 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

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

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

name

Spécifie l’identificateur du rôle d’application 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 schéma (futurs) d’un type spécifié plutôt que sur les objets existants. Les autorisations futures peuvent être annulées à tout moment en utilisant REVOKE <privilèges> FROM APPLICATION 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 schéma dans cette rubrique.

WITH GRANT OPTION

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

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

Note

La clause WITH GRANT OPTION ne prend pas en charge le privilège IMPORTED PRIVILEGES. Pour plus d’informations, reportez-vous à Attribution de privilèges sur une base de données partagée.

Notes sur l’utilisation

Vous devez utiliser un rôle d’application pour attribuer et révoquer des privilèges sur les objets d’une application.

Cette commande a des restrictions différentes selon que vous êtes le fournisseur ou le consommateur de l’application.

Le consommateur d’applications ne peut pas faire ce qui suit concernant un rôle d’application :

  • Accorder ou révoquer les privilèges d’un objet par rapport à un rôle d’application.

  • Accorder un rôle d’application à une base de données ou à un partage, ou révoquer un rôle d’application d’une base de données ou d’un partage.

  • Attribuer un rôle à la même application ou à une application différente, ou révoquer un rôle à la même application ou à une application différente.

Ces éléments appliquent le fournisseur d’application par rapport à un rôle d’application.

  • 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 d’application, en transférant la propriété de l’objet d’un rôle d’application à un autre, utilisez la commande GRANT OWNERSHIP .

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

    Cependant, seuls les privilèges détenus et pouvant être attribués par le rôle d’application exécutant la commande GRANT sont réellement attribué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 d’application particulier sont automatiquement hérités par tous les autres rôles d’application auxquels le rôle d’application est accordé, ainsi que tous les autres rôles d’application 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.

  • 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’applique 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 mises en zone de préparation externes et internes, référez-vous à CREATE STAGE et Exigences en matière de contrôle d’accès (dans cette rubrique).

  • 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> [ , ... ] ] )
    
    Copy

    Snowflake utilise des types de données d’argument pour résoudre des UDFs et des procédures stockées qui ont le même nom dans un schéma. Pour plus d’informations, reportez-vous à Surcharge de procédures et de fonctions.

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

  • Cette commande ne peut être exécutée qu’à partir de l’application.

  • Les privilèges ne peuvent être accordés ou révoqués que sur des objets appartenant à l’application. Pour déterminer ces objets, utilisez la commande SHOW OBJECTS :

    SHOW OBJECTS OWNED BY APPLICATION myapp;
    
    Copy
  • À propos des schémas d’accès gérés :

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

      Les rôles suivants peuvent attribuer des privilèges sur des objets d’un schéma d’accès géré :

      • Le rôle d’application, car ce rôle est le propriétaire du schéma (c’est-à-dire le rôle ayant le privilège OWNERSHIP sur le schéma).

      • Un rôle qui hérite du rôle d’application.

      • Un rôle doté du privilège global MANAGE GRANTS peut attribuer des privilèges sur les objets du schéma.

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

    • Reportez-vous à Futures autorisations sur des objets de schéma (dans cette rubrique) pour connaître les exigences en matière de contrôle d’accès des futures attributions dans les schémas d’accès gérés.

Futures autorisations sur des objets de schéma

Les remarques de ces sections s’appliquent lors de l’affectation d’autorisations futures à des objets d’un schéma (c’est-à-dire lorsque vous utilisez les mots clés ON FUTURE).

Considérations

  • Lorsque les autorisations futures sont définies sur le même type d’objet pour un 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. Ce comportement s’applique aux privilèges sur les objets futurs accordés à un rôle d’application ou à différents rôles d’application.

Restrictions et limitations

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

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

    • Pool de calcul

    • Fonction externe

    • Référentiel d’images

    • Objets de politique :

      • Politique d’agrégation

      • Politique de masquage

      • Politique de paquets

      • Politique de projection

      • Politique d’accès aux lignes

      • Politique de session

    • Balise

  • Une attribution future du privilège OWNERSHIP sur des objets d’un type spécifié dans une base de données ne s’applique pas aux nouveaux objets dans un schéma d’accès géré.

  • Les restrictions suivantes s’appliquent aux attributions futures sur des objets d’un schéma d’accès géré :

    • 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 <privilèges> et des mots clés ON FUTURE.

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

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

  • Dans un schéma d’accès géré, le rôle d’application et un rôle avec le privilège global MANAGE GRANTS peuvent accorder des privilèges sur les objets futurs du schéma d’accès géré.

    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.

Exemple

Accordez le privilège SELECT sur une vue à un rôle d’application :

GRANT SELECT ON VIEW data.views.credit_usage
  TO APPLICATION ROLE app_snowflake_credits;
Copy