Configuration du contrôle d’accès

Cette rubrique décrit comment configurer la sécurité du contrôle d’accès pour les objets sécurisables dans votre compte.

Dans ce chapitre :

Administration des comptes

Désignation d’utilisateurs supplémentaires comme administrateurs de compte

Par défaut, chaque compte a un utilisateur qui a été désigné comme administrateur de compte (c.-à-d. un utilisateur à qui le rôle ACCOUNTADMIN défini par le système a été accordé). Nous vous recommandons de désigner au moins un autre utilisateur comme administrateur de compte. Ceci permet de vous assurer que votre compte a toujours au moins un utilisateur qui peut effectuer des tâches au niveau du compte, en particulier si l’un de vos administrateurs de compte est incapable de se connecter.

Pour ces administrateurs de compte supplémentaires, vous pouvez choisir de créer de nouveaux utilisateurs ou de désigner des utilisateurs existants, mais veillez à spécifier ce qui suit :

  • Attribuez le rôle ACCOUNTADMIN au(x) utilisateur(s), mais ne définissez pas ce rôle par défaut. Au lieu de cela, désignez un rôle administratif ou personnalisé de niveau inférieur (SYSADMIN, par ex.) comme rôle par défaut. Ceci aide à empêcher les administrateurs de compte d’utiliser par inadvertance le rôle ACCOUNTADMIN pour créer des objets.

  • Assurez-vous qu’une adresse électronique est spécifiée pour chaque utilisateur (nécessaire pour l’authentification multifactorielle).

Par exemple, attribuez les rôles ACCOUNTADMIN et SYSADMIN à un utilisateur existant nommé user2, et spécifiez SYSADMIN comme rôle par défaut :

GRANT ROLE ACCOUNTADMIN, SYSADMIN TO USER user2;

ALTER USER user2 SET EMAIL='user2@domain.com', DEFAULT_ROLE=SYSADMIN;
Copy

Activation de MFA pour chaque administrateur de compte

Pour assurer le plus haut niveau de sécurité pour votre compte Snowflake, nous recommandons fortement que tout utilisateur pouvant modifier ou visualiser des données sensibles soit tenu d’utiliser une authentification multifactorielle (MFA) pour se connecter.

Cette recommandation s’applique particulièrement aux utilisateurs ayant le rôle ACCOUNTADMIN, mais peut également être étendue aux utilisateurs ayant les rôles SECURITYADMIN et SYSADMIN.

Pour plus de détails, voir Remarques relatives au contrôle d’accès et Authentification multifactorielle (MFA).

Création de rôles personnalisés

Pour suivre le principe général du « moindre privilège », nous recommandons de créer des rôles personnalisés qui s’alignent sur les fonctions métier de votre organisation pour permettre des actions SQL sur un ensemble restreint d’objets sécurisables.

Le workflow est le suivant :

  1. Créez un rôle personnalisé.

  2. Accordez un ensemble de privilèges au rôle.

  3. Accordez le rôle à un ou plusieurs utilisateurs qui ont besoin des privilèges attribués au rôle pour effectuer des actions SQL pour leurs besoins professionnels.

  4. Accordez le rôle à un autre rôle pour créer une hiérarchie de rôles ou l’ajouter à la hiérarchie. Bien que non obligatoire, cette étape est fortement recommandée. Pour plus d’informations, voir Création d’une hiérarchie de rôles (dans ce chapitre).

Cette section fournit des instructions pour créer un rôle nommé r1 et lui accorder les privilèges suivants. Les privilèges permettent à un utilisateur qui active le rôle dans une session d’interroger une seule table, d1.s1.t1 :

Privilège

Objet

Remarques

USAGE

Entrepôt w1

Base de données d1

Schéma s1

Pour interroger un objet (par exemple, une table ou une vue), un rôle doit disposer du privilège USAGE sur un entrepôt. L’entrepôt fournit les ressources informatiques nécessaires à l’exécution de la requête.

Pour utiliser un objet quelconque dans un schéma, un rôle doit avoir le privilège USAGE sur la base de données de conteneur et le schéma.

SELECT

t1 de table

Après la création d’un rôle, des privilèges supplémentaires peuvent lui être accordés pour permettre aux utilisateurs disposant du rôle d’effectuer des actions SQL supplémentaires sur le même objet ou sur des objets supplémentaires.

Créer un rôle

  1. Créez le rôle r1 en utilisant CREATE ROLE.

    Seuls les administrateurs des utilisateurs (c’est-à-dire les utilisateurs ayant le rôle système USERADMIN ou un rôle supérieur), ou un autre rôle ayant le privilège CREATE ROLE sur le compte, peuvent créer des rôles.

    CREATE ROLE r1
   COMMENT = 'This role has all privileges on schema_1';
    Copy

Accorder des privilèges au rôle

  1. Accordez au rôle r1 les privilèges définis dans le tableau précédent dans cette section.

    Le rôle système SECURITYADMIN peut être utilisé pour accorder des privilèges sur des objets aux rôles. Pour des options supplémentaires, voir GRANT <privilèges>.

    GRANT USAGE
  ON WAREHOUSE w1
  TO ROLE r1;

GRANT USAGE
  ON DATABASE d1
  TO ROLE r1;

GRANT USAGE
  ON SCHEMA d1.s1
  TO ROLE r1;

GRANT SELECT
  ON TABLE d1.s1.t1
  TO ROLE r1;
    Copy

Accorder le rôle à des utilisateurs

  1. Attribuez le rôle r1 à l’utilisateur smith.

    Le rôle SECURITYADMIN peut être utilisé pour accorder des rôles à des utilisateurs. Pour des options supplémentaires, voir GRANT ROLE.

    GRANT ROLE r1
   TO USER smith;
    Copy

  2. Vous pouvez aussi, si vous le souhaitez, définir le nouveau rôle personnalisé comme le rôle par défaut pour l’utilisateur. La prochaine fois que l’utilisateur se connectera à Snowflake, le rôle par défaut sera automatiquement actif dans la session.

    Seuls le rôle ayant le privilège OWNERSHIP sur l’utilisateur ou un rôle supérieur peuvent exécuter cette commande.

    La commande suivante définit le rôle par défaut de l’utilisateur smith :

    ALTER USER smith
   SET DEFAULT_ROLE = r1;
    Copy

Création de rôles personnalisés en lecture seule

Supposons que vous ayez besoin d’un rôle qui se limite à interroger toutes les tables dans un schéma spécifique (par ex. d1.s1). Les utilisateurs qui exécutent des commandes à l’aide de ce rôle ne peuvent pas mettre à jour les données de table, créer des objets de base de données supplémentaires ou détruire des tables. Le rôle est limité à l’interrogation des données de la table.

Pour créer un rôle en lecture seule, suivez les étapes de base décrites dans Création de rôles personnalisés (dans cette rubrique). Dans la section Attribuer des privilèges au rôle , accordez au rôle en lecture seule (nommé read_only dans ces instructions) les privilèges d’objet suivants :

Privilège

Objet

Remarques

USAGE

Entrepôt

Pour interroger un objet (par exemple, une table ou une vue), un rôle doit disposer du privilège USAGE sur un entrepôt. L’entrepôt fournit les ressources informatiques nécessaires à l’exécution de la requête.

SELECT

Table

Pour utiliser un objet quelconque dans un schéma, un rôle doit avoir le privilège USAGE sur la base de données de conteneur et le schéma.

Les instructions GRANT <privilège> sont les suivantes :

GRANT USAGE
  ON DATABASE d1
  TO ROLE read_only;

GRANT USAGE
  ON SCHEMA d1.s1
  TO ROLE read_only;

GRANT SELECT
  ON ALL TABLES IN SCHEMA d1.s1
  TO ROLE read_only;

GRANT USAGE
  ON WAREHOUSE w1
  TO ROLE read_only;
Copy

Note

L’instruction GRANT SELECT ON ALL TABLES IN SCHEMA <schema> accorde le privilège SELECT sur toutes les tables existantes uniquement. Pour accorder au rôle le privilège SELECT sur toutes les tables futures , exécutez l’instruction suivante :

GRANT SELECT ON FUTURE TABLES IN SCHEMA d1.s1 TO ROLE read_only;
Copy

Création d’une hiérarchie de rôles

Lorsque vous créez des rôles personnalisés, envisagez de créer une hiérarchie de rôles qui sera ensuite affectée au rôle d’administrateur de haut niveau. En général, le rôle SYSADMIN convient bien à tous les autres rôles attribués dans une hiérarchie, même s’il est important de noter que tout rôle disposant de privilèges suffisants peut remplir cette fonction. Le rôle SYSADMIN est un rôle défini par le système qui a des privilèges pour créer des entrepôts, des bases de données et des objets de base de données dans un compte, et accorder ces privilèges aux autres rôles. Dans la hiérarchie système par défaut, le rôle de niveau supérieur ACCOUNTADMIN gère le rôle d’administrateur système.

Créez une hiérarchie de rôles en accordant un rôle à un deuxième rôle. Vous pouvez ensuite accorder ce deuxième rôle à un troisième rôle. Les privilèges associés à un rôle sont hérités par tous les rôles situés au-dessus de ce rôle dans la hiérarchie (c’est-à-dire, le rôle parent).

Le diagramme suivant illustre un exemple de hiérarchie des rôles et les privilèges accordés à chaque rôle :

Hiérarchie des rôles et privilèges accordés à chaque rôle

Accorder un rôle à un autre rôle

Affectez le rôle à un rôle de niveau supérieur dans une hiérarchie des rôles. Dans cet exemple, nous assignons le rôle r1 créé dans Création de rôles personnalisés (dans cette rubrique) au rôle SYSADMIN. Le rôle SYSADMIN hérite de tous les privilèges d’objet accordés au rôle r1 :

GRANT ROLE r1
   TO ROLE sysadmin;
Copy

Note

Dans un exemple plus complexe, vous pouvez attribuer le rôle custom à un autre rôle enfant de SYSADMIN (ou à un autre rôle d’administrateur, tel qu’un rôle personnalisé doté de privilèges suffisants pour créer des bases de données). Le rôle SYSADMIN hériterait des privilèges combinés attribués au rôle custom et à son rôle parent. Si le rôle au-dessus de custom dans la hiérarchie possède des objets, alors la hiérarchie des rôles s’assure que les membres du rôle SYSADMIN possèdent également ces objets (indirectement) et peuvent les gérer comme prévu.

Affichage des privilèges accordés

Pour afficher l’ensemble des privilèges accordés à un objet, vous pouvez exécuter la commande SHOW GRANTS.

Note

Exécuter la commande SHOW GRANTS sur un objet spécifique nécessite les mêmes privilèges d’objet que pour exécuter la commande SHOW pour ce type d’objet.

Par exemple, exécuter la commande SHOW GRANTS sur une table nécessite les privilèges suivants sur la table, et la base de données et le schéma de conteneur :

Base de données:

USAGE

Schéma:

USAGE

Table:

privilège quelconque

Par exemple, pour afficher les autorisations actuelles sur un schéma, exécutez la commande suivante :

SHOW GRANTS ON SCHEMA <database_name>.<schema_name>;
Copy

Par exemple, exécutez la commande suivante pour afficher les privilèges sur database_a.schema_1 qui ont été accordés dans Création de rôles personnalisés (dans cette rubrique) :

SHOW GRANTS ON SCHEMA database_a.schema_1;
Copy

Snowflake renvoie les résultats suivants :

+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+
| created_on                    | privilege             | granted_on | name                 | granted_to | grantee_name             | grant_option | granted_by    |
|-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------|
| 2022-03-07 09:04:23.635 -0800 | USAGE                 | SCHEMA     | D1.S1                | ROLE       | R1                       | false        | SECURITYADMIN |
+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+
Copy

Vous pouvez également exécuter la commande SHOW GRANTS pour afficher l’ensemble des privilèges accordés à un rôle ou l’ensemble des rôles accordés à un utilisateur :

SHOW GRANTS TO ROLE <role_name>;
SHOW GRANTS TO USER <user_name>;
Copy

Par exemple, exécutez la commande suivante pour afficher les privilèges accordés au rôle r1 créé dans Création de rôles personnalisés (dans cette rubrique) :

SHOW GRANTS TO ROLE r1;
Copy

Snowflake renvoie les résultats suivants :

+-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
| created_on                    | privilege | granted_on | name                 | granted_to | grantee_name | grant_option | granted_by    |
|-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------|
| 2022-03-07 09:08:43.773 -0800 | USAGE     | DATABASE   | D1                   | ROLE       | R1           | false        | SECURITYADMIN |
| 2022-03-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | D1.S1                | ROLE       | R1           | false        | SECURITYADMIN |
| 2022-03-07 09:09:07.206 -0800 | SELECT    | TABLE      | D1.S1.T1             | ROLE       | R1           | false        | SECURITYADMIN |
| 2022-03-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | W1                   | ROLE       | R1           | false        | SECURITYADMIN |
+-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
Copy

Attribution d’autorisations futures sur des objets

Pour simplifier la gestion des autorisations, les autorisations futures permettent de définir un ensemble initial de privilèges à attribuer à de nouveaux objets (c.-à-d. futurs) d’un certain type dans un schéma ou une base de données. Lors de la création de nouveaux objets dans la base de données ou le schéma, les privilèges définis sont automatiquement attribués à un rôle spécifié.

Les attributions futures définissent uniquement l’ensemble initial de privilèges accordés sur les nouveaux objets d’un type spécifié. Une fois qu’un objet individuel est créé, les administrateurs peuvent explicitement accorder des privilèges supplémentaires ou en révoquer sur l’objet. Cela permet un contrôle d’accès détaillé sur tous les objets du schéma ou de la base de données.

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 toutes les futures tables de la base de données d1 au rôle r1 :

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

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

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

    Les autorisations futures attribuées au rôle r1 sur des types d’objets dans le schéma d1.s1 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.

Définition d’autorisations futures sur des objets de base de données ou de schéma

Accorde des privilèges sur les objets futurs d’un type spécifié en utilisant la commande GRANT <privilèges> avec les mots-clés ON FUTURE.

Révocation d’autorisations futures sur des objets de base de données ou de schéma

Révoquer des autorisations futures sur des objets futurs à l’aide de la commande REVOKE <privilèges> avec les mots-clés ON FUTURE.

Clonage d’objets et autorisations futures

  • Lorsqu’une base de données ou un schéma est cloné, les autorisations futures sont copiées sur son clone. Ce comportement maintient la cohérence avec les autorisations d’objets ordinaires ; c’est-à-dire que les autorisations de privilèges sur un objet source (c’est-à-dire la base de données) ne sont pas copiés sur ses clones, mais les autorisations de privilèges sur tous les objets enfants (c’est-à-dire les tables de la base de données) sont copiés sur les clones.

  • Lorsqu’un objet d’un schéma est cloné, toutes les autorisations futures définies pour ce type d’objet dans le schéma sont appliquées à l’objet cloné, sauf si l’option COPY GRANTS est spécifiée dans l’instruction CREATE <objet> pour l’opération de clonage. Dans ce cas, le nouvel objet conserve les autorisations d’accès de l’objet d’origine et n’hérite d”aucune autorisation future pour des objets de ce type.

Gestion des attributions futures à l’aide de la console classique

Vous pouvez également définir des autorisations futures à l’aide de l”Classic Console :

Autorisations sur les futurs objets de base de données:

  1. Sélectionnez Databases Onglet Bases de données.

  2. Cliquez sur la ligne pour une base de données spécifique. Le panneau de sécurité s’ouvre.

  3. Sélectionnez Grant Privileges. La boîte de dialogue Grant Privileges s’ouvre.

  4. Dans la liste déroulante Grant privileges on , sélectionnez future object_type pour définir les futures autorisations sur de nouveaux objets d’un type d’objet spécifique.

  5. Dans les listes déroulantes restantes, sélectionnez les privilèges que vous accordez aux nouveaux objets du type que vous avez spécifié, ainsi que le rôle auquel les privilèges seront accordés.

  6. Sélectionnez Grant Privileges.

Autorisations sur les futurs objets du schéma:

  1. Sélectionnez Databases Onglet Bases de données » <nom_bd> » Schemas.

  2. Cliquez sur la ligne pour un schéma spécifique. Le panneau de sécurité s’ouvre.

  3. Sélectionnez Grant Privileges. La boîte de dialogue Grant Privileges s’ouvre.

  4. Dans la liste déroulante Grant privileges on , sélectionnez future object_type pour définir les futures autorisations sur de nouveaux objets d’un type d’objet spécifique.

  5. Dans les listes déroulantes restantes, sélectionnez les privilèges que vous accordez aux nouveaux objets du type que vous avez spécifié, ainsi que le rôle auquel les privilèges seront accordés.

  6. Sélectionnez Grant Privileges.

Pour gérer les attributions futures dans Snowsight, exécutez les instructions SQL dans une feuille de calcul.

Création de schémas d’accès gérés

Les schémas d’accès gérés améliorent la sécurité en verrouillant la gestion des privilèges sur des objets.

Dans les schémas classiques (c.-à-d. non gérés), les propriétaires d’objets (dont le rôle dispose du privilège OWNERSHIP sur un objet) peuvent accorder l’accès à leurs objets à d’autres rôles, avec la possibilité d’accorder à ces rôles la possibilité de gérer les autorisations d’objets.

Avec les schémas d’accès gérés, les propriétaires d’objets perdent la capacité de prendre des décisions en matière 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 MANAGE GRANTS peut octroyer des privilèges sur les objets du schéma, notamment des autorisations futures, centralisant ainsi la gestion des privilèges.

Vous pouvez créer un schéma d’accès géré via l’interface Web ou SQL :

Classic Console:

Cliquez sur Databases Onglet Bases de données » <nom_bdd> » Schemas » Create Schema.

SQL:

Exécutez une instruction CREATE SCHEMA avec les mots clés WITH MANAGED ACCESS.

Vous pouvez remplacer un schéma standard par un schéma d’accès géré (ou inversement) à l’aide de l’interface Web ou de SQL :

Classic Console:

Cliquez sur Databases Onglet Bases de données » <nom_bdd> » Schemas » <nom_schéma> » Alter a schema.

SQL:

Exécutez une instruction ALTER SCHEMA avec les mots clés ENABLE | DISABLE MANAGED ACCESS.

Le tableau suivant indique les rôles pouvant gérer les privilèges d’objet dans un schéma d’accès normal ou géré :

Rôle

Peut accorder des privilèges d’objet dans un schéma standard

Peut accorder des privilèges d’objet dans un schéma d’accès géré

SYSADMIN

Non

Non

SECURITYADMIN ou supérieur

Oui

Oui

Propriétaire de la base de données

Non

Non

Propriétaire du schéma

Non

Oui

Propriétaire d’objet

Oui

Non

Tout rôle avec le privilège MANAGE GRANTS

Oui

Oui

Gérer les privilèges des objets avec Snowsight

Vous pouvez utiliser Snowsight pour gérer l’attribution de privilèges d’objets de base de données à des rôles. Pour gérer ces attributions, utilisez un rôle doté du privilège OWNERSHIP sur l’objet ou du privilège global MANAGE GRANTS.

Lorsque vous utilisez Snowsight pour gérer les attributions, cela équivaut à exécuter une commande GRANT PRIVILEGE ou REVOKE PRIVILEGE dans SQL. Par exemple, vous pouvez utiliser Snowsight pour accorder le privilège USAGE sur une vue au rôle ACCOUNTADMIN.

Attribuer des privilèges sur des objets

Pour accorder des privilèges d’objet de base de données à un rôle, procédez comme suit :

  1. Connectez-vous à Snowsight.

  2. Sélectionnez Data » Databases.

  3. Pour une base de données et un schéma spécifiques, sélectionnez un objet de base de données auquel vous souhaitez accorder des privilèges.

  4. Dans Object Details, localisez la section Privileges.

  5. Sélectionnez + Privilege.

  6. Sélectionnez le rôle auquel vous souhaitez accorder le privilège.

  7. Sélectionnez le privilège que vous souhaitez accorder au rôle.

  8. Si vous souhaitez que le rôle puisse accorder le privilège à d’autres rôles, sélectionnez Grant option.

  9. Répétez ces étapes pour chaque privilège d’objet que vous souhaitez accorder au rôle.

  10. Sélectionnez Grant Privileges.

Révoquer des privilèges sur des objets.

Pour révoquer les privilèges d’un objet de base de données d’un rôle, procédez comme suit :

  1. Connectez-vous à Snowsight.

  2. Sélectionnez Data » Databases.

  3. Pour une base de données et un schéma spécifiques, sélectionnez un objet de base de données dont vous souhaitez révoquer les privilèges.

  4. Dans Object Details, localisez la section Privileges.

  5. Pour un rôle spécifique répertorié, sélectionnez l’icône en forme de crayon Edit Role qui apparaît lorsque vous survolez la ligne.

  6. Dans la boîte de dialogue qui s’affiche, sélectionnez le bouton x pour révoquer un privilège d’un rôle spécifique.

  7. Sélectionnez Update Privileges.

Identifier les privilèges accordés à des rôles.

Pour afficher les privilèges accordés à un rôle spécifique, vous pouvez exécuter la commande SHOW GRANTS ou faire ce qui suit dans Snowsight :

  1. Connectez-vous à Snowsight.

  2. Sélectionnez Admin » Users & Roles » Roles.

  3. Sélectionnez Table et localisez le rôle pour lequel vous souhaitez afficher les privilèges accordés.

  4. Sélectionnez le rôle pour lequel vous souhaitez afficher les privilèges accordés afin de consulter les détails.

  5. Examinez la section Privileges pour le rôle.

Permettre aux administrateurs sans compte de surveiller l’historique d’utilisation et de facturation dans la console classique

Snowflake fournit des informations détaillées sur l’utilisation et la facturation de compte concernant le stockage et le transfert de données ainsi que sur l’utilisation et le chargement d’entrepôts :

Snowsight:

Select Admin » Cost Management.

Classic Console:

Cliquez sur Account Onglet Compte » Billing & Usage.

SQL:

Interrogez les éléments suivants (au choix) :

Par défaut, ces informations ne peuvent être consultées que par les administrateurs de compte.

Note

Actuellement, Snowsight n’affiche les informations relatives à l’utilisation et à la facturation que pour les administrateurs de comptes. Il n’est pas possible d’accorder à d’autres rôles la possibilité de consulter ces informations.

Pour permettre aux utilisateurs qui ne sont pas des administrateurs de comptes d’accéder à ces informations ou de les consulter, accordez les privilèges suivants à un rôle défini par le système ou personnalisé. L’attribution de privilèges à un rôle permet à tous les utilisateurs auxquels ce rôle est accordé d’accéder à ces informations historiques/d’utilisation :

Privilège

Objet

Description

MONITOR USAGE

Compte (c’est-à-dire privilège global)

Permet aux utilisateurs qui ont reçu ce rôle de visualiser les informations relatives à l’utilisation et à la facturation dans l’interface Web et d’interroger les fonctions de table correspondantes dans l’Information Schema.

De plus, avec ce privilège, les commandes SHOW DATABASES et SHOW WAREHOUSES renvoient les listes de toutes les bases de données et de tous les entrepôts du compte indépendamment des autres autorisations accordées.

IMPORTED PRIVILEGES

Base de données snowflake

Permet aux utilisateurs qui ont reçu ce rôle d’interroger toutes les vues ACCOUNT USAGE, y compris les vues contenant des informations sur l’utilisation et la facturation.

Pour plus d’informations, voir Activation de l’utilisation de la base de données SNOWFLAKE pour d’autres rôles.

Par exemple, pour accorder ces autorisations au rôle custom :

GRANT MONITOR USAGE ON ACCOUNT TO ROLE custom;

GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE custom;
Copy
Langage: Français