Configuration du contrôle d’accès

Ce chapitre décrit comment configurer la sécurité au niveau de l’objet en utilisant les rôles définis par le système (fournis par Snowflake) et les rôles personnalisés (en option).

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. Désignez plutôt un rôle administratif de niveau inférieur (p. ex. SYSADMIN) ou rôle personnalisé 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;

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

Par exemple, vous pouvez créer un rôle personnalisé avec tous les privilèges sur un schéma spécifique :

  1. Accordez les privilèges suivants à ce rôle :

    • USAGE dans la base de données qui contient le schéma.

    • ALL sur le schéma qui contient les tables à interroger.

    • USAGE sur un entrepôt utilisé pour exécuter des requêtes sur les tables du schéma.

  2. Créez la hiérarchie des rôles. Accordez le rôle personnalisé au rôle SYSADMIN. Les rôles parents héritent des privilèges d’objet associés à chaque rôle enfant.

  3. Attribuez le rôle personnalisé à tout utilisateur qui a besoin des privilèges spécifiés.

Tout utilisateur possédant le rôle peut créer et utiliser n’importe quel objet du schéma. Le diagramme suivant illustre un exemple de hiérarchie des rôles et les privilèges accordés à chaque rôle :

Role hierarchy and privileges granted to each role

Note

Les sections suivantes fournissent des instructions étape par étape pour créer un rôle personnalisé nommé custom dans une hiérarchie de rôles de base. Ce rôle custom permet aux utilisateurs de créer des objets dans un schéma et de gérer ces objets (en tant que propriétaire de l’objet). Le rôle n’a pas de permissions sur les objets existants dans le schéma, bien que celles-ci puissent être accordées par le biais de privilèges supplémentaires au niveau du schéma ou de l’objet.

Exécutez les instructions SQL dans cette section en tant qu’utilisateur avec le rôle SECURITYADMIN (ou supérieur).

Création d’un rôle personnalisé

  1. Créez le rôle custom :

    CREATE ROLE custom
       COMMENT = 'This role has all privileges on schema_1';
    
  2. Accordez les privilèges d’objet suivants au rôle custom :

    • USAGE sur la base de données contenant le schéma (database_a). Pour utiliser un objet quelconque dans un schéma, un rôle doit également avoir le privilège USAGE sur la base de données de conteneur.

    • ALL [PRIVILEGES] sur le schéma (schema_1).

    • USAGE sur l’entrepôt utilisé pour exécuter les requêtes (warehouse_1). Les utilisateurs possédant ce rôle peuvent exécuter des requêtes à l’aide de cet entrepôt.

    GRANT USAGE
      ON DATABASE database_a
      TO ROLE custom;
    
    GRANT ALL
      ON SCHEMA database_a.schema_1
      TO ROLE custom;
    
    GRANT USAGE
      ON WAREHOUSE warehouse_1
      TO ROLE custom;
    

Attribution du 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 custom au rôle SYSADMIN. Le rôle SYSADMIN hérite de tous les privilèges d’objet accordés au rôle custom :

GRANT ROLE custom
   TO ROLE sysadmin;

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.

Attribution du rôle à un utilisateur

  1. Utilisez ALTER USER pour désactiver l’utilisateur que vous souhaitez modifier. Ceci fermera de force toutes les sessions existantes pour l’utilisateur pendant que vous effectuez les modifications. Par exemple, la commande suivante désactive l’utilisateur Bonnie Smith (bsmith) :

    ALTER USER bsmith SET DISABLED=TRUE;
    
  2. Affectez le rôle custom à un utilisateur :

    GRANT ROLE custom
       TO USER bsmith;
    
  3. Définissez le rôle par défaut de l’utilisateur. La commande suivante définit le rôle par défaut de l’utilisateur Bonnie Smith :

    ALTER USER bsmith
       SET DEFAULT_ROLE = custom;
    
  4. Activez l’utilisateur à l’aide de la commande ALTER USER pour qu’il puisse se reconnecter avec le nouveau rôle par défaut. Par exemple :

    ALTER USER bsmith SET DISABLED=false;
    

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. Pour afficher les permissions actuelles sur un schéma, exécutez la commande suivante :

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

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 d’un rôle personnalisé :

SHOW GRANTS ON SCHEMA database_a.schema_1;

Snowflake renvoie les résultats suivants :

+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+
| created_on                    | privilege          | granted_on | name                | granted_to | grantee_name | grant_option | granted_by   |
|-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------|
| 2016-08-24 12:35:08.000 -0700 | OWNERSHIP          | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | SYSADMIN     | true         | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FILE FORMAT | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FUNCTION    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE SEQUENCE    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE STAGE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE TABLE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE VIEW        | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MODIFY             | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MONITOR            | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+

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>;

Par exemple, exécutez la commande suivante pour afficher les privilèges accordés au rôle custom créé dans Création d’un rôle personnalisé :

SHOW GRANTS TO ROLE custom;

Snowflake renvoie les résultats suivants :

+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+
| created_on                    | privilege          | granted_on | name                | granted_to | grantee_name | grant_option | granted_by   |
|-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------|
| 2016-11-22 12:34:29.000 -0800 | USAGE              | DATABASE   | DATABASE_A          | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FILE FORMAT | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FUNCTION    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE SEQUENCE    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE STAGE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE TABLE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE VIEW        | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MODIFY             | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MONITOR            | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | WAREHOUSE  | WAREHOUSE_1         | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+

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

Création de rôles en lecture seule

Supposons que vous ayez besoin d’un rôle qui se limite à interroger les tables dans un schéma spécifique (par ex. database_a.schema_1). 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.

Dans ce scénario, vous pouvez créer un rôle personnalisé avec un accès limité au schéma et à ses tables. Vous accordez ensuite le rôle en lecture seule aux utilisateurs qui ont besoin d’un accès en lecture seule au schéma et aux tables. Ces utilisateurs peuvent travailler dans le rôle limité par défaut sans se soucier de modifier ou de détruire accidentellement des objets de schéma.

Note

Exécutez les instructions SQL dans cette section en tant qu’utilisateur avec le rôle SECURITYADMIN (ou supérieur).

  1. Créez le rôle personnalisé read_only_rl :

    CREATE ROLE read_only_rl
       COMMENT = 'This role is limited to querying tables in schema_1';
    
  2. Si vous avez implémenté une hiérarchie des rôles (recommandé), 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 read_only_rl au rôle SYSADMIN. Le rôle SYSADMIN hérite de tous les privilèges d’objet accordés au rôle read_only_rl :

    GRANT ROLE read_only_rl
       TO ROLE sysadmin;
    
  3. Accordez les privilèges d’objet suivants au rôle read_only_rl :

    • USAGE sur la base de données contenant le schéma (database_a).

    • USAGE sur le schéma contenant les tables à interroger (schema_1). Pour utiliser un objet quelconque dans un schéma, un rôle doit également avoir le privilège USAGE sur la base de données et le schéma.

    • SELECT sur toutes les tables existantes.

    • USAGE sur l’entrepôt utilisé pour exécuter des requêtes sur les tables (warehouse_1). Les utilisateurs possédant ce rôle peuvent exécuter des requêtes à l’aide de cet entrepôt.

    GRANT USAGE
      ON DATABASE database_a
      TO ROLE read_only_rl;
    
    GRANT USAGE
      ON SCHEMA database_a.schema_1
      TO ROLE read_only_rl;
    
    GRANT SELECT
      ON ALL TABLES IN SCHEMA database_a.schema_1
      TO ROLE read_only_rl;
    
    GRANT USAGE
      ON WAREHOUSE warehouse_1
      TO ROLE read_only_rl;
    

    Note

    L’instruction GRANT SELECT ON ALL TABLES IN SCHEMA <schéma> ne s’applique qu’aux tables existantes. Le rôle en lecture seule doit se voir accorder le privilège SELECT sur toutes les tables créées dans le schéma par la suite. Par exemple :

    GRANT SELECT
      ON TABLE database_a.schema_1.table_new
      TO ROLE read_only_rl;
    
  4. Utilisez ALTER USER pour désactiver l’utilisateur que vous souhaitez modifier. Ceci fermera de force toutes les sessions existantes pour l’utilisateur pendant que vous effectuez les modifications. Par exemple, la commande suivante désactive l’utilisateur Bonnie Smith (bsmith) :

    ALTER USER bsmith SET DISABLED=TRUE;
    
  5. Affectez le rôle read_only_rl à un utilisateur :

    GRANT ROLE read_only_rl
       TO USER bsmith;
    
  6. Définissez le rôle par défaut de l’utilisateur. La commande suivante définit le rôle par défaut de l’utilisateur Bonnie Smith :

    ALTER USER bsmith
       SET DEFAULT_ROLE = read_only_rl;
    
  7. Activez l’utilisateur à l’aide de la commande ALTER USER pour qu’il puisse se reconnecter avec le nouveau rôle par défaut. Par exemple :

    ALTER USER bsmith SET DISABLED=false;
    

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, 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

  • Les autorisations futures définies pour un objet au niveau de la base de données s’appliquent à tous les objets de ce type créés à l’avenir. Pour plus d’informations sur les autorisations futures, voir Définition d’autorisations futures sur des objets de base de données ou de schéma (dans ce chapitre).

  • Vous devez définir les autorisations futures sur chaque type d’objet (schémas, tables, vues, flux, etc.) individuellement. Pour plus d’informations sur les autorisations futures, voir Définition d’autorisations futures sur des objets de base de données ou de schéma existants (dans ce chapitre).

  • Les privilèges définis à l’aide d’autorisations futures sont automatiquement accordés au moment de la création de l’objet.

  • Lorsque les autorisations futures sont définies à la fois au niveau de la base de données et du 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.

  • 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. Pour plus d’informations, voir Privilèges de sécurité requis pour gérer les autorisations futures (dans ce chapitre).

Privilèges de sécurité requis pour gérer les autorisations futures

Le privilège global MANAGE GRANTS est requis pour accorder ou révoquer des privilèges sur des objets futurs au niveau de la base de données. Par défaut, seuls les rôles SECURITYADMIN et ACCOUNTADMIN ont le privilège MANAGE GRANTS.

En outre, dans un schéma d’accès géré, le propriétaire du schéma (c’est-à-dire le rôle doté du privilège OWNERSHIP sur le schéma) peut gérer des autorisations futures sur des objets du schéma.

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

Vous pouvez attribuer des autorisations futures sur des objets de base de données ou de schéma à l’aide de la commande GRANT <privileges> … TO ROLE avec les mots-clés ON FUTURE.

Exemple de code pour définir les autorisations futures au niveau de la base de données :

use role accountadmin;

-- Grant the USAGE privilege on all future schemas in a database to role R1
grant usage on future schemas in database DB1 to role R1;

Exemple de code pour définir les autorisations futures au niveau du schéma :

use role accountadmin;

-- Grant the SELECT privilege on all future tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA DB1.schema1 TO ROLE R1;

-- Grants the SELECT and INSERT privileges on all future tables in a schema to R1
grant select,insert on future tables in schema DB1.schema1 to role R1;

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

Les autorisations futures ne concernent que les nouveaux objets. Vous devez explicitement accorder les privilèges souhaités à un rôle sur des objets existants à l’aide de la commande GRANT <privileges> … TO ROLE.

Exemple de code :

use role accountadmin;

-- Grant the USAGE privilege on all existing schemas in a database to role R1
grant usage on all schemas in database DB1 to role R1;

-- Grant the SELECT privilege on all existing tables in a schema to role R1
grant select on all tables in schema DB1.schema1 to role R1

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

Vous pouvez révoquer des autorisations futures sur des objets de base de données à l’aide de la commande REVOKE <privileges> … FROM ROLE avec les mots-clés ON FUTURE.

Note

La révocation de futures autorisations sur des objets de base de données ne supprime que les privilèges accordés sur de futurs objets d’un type spécifié plutôt que sur des objets existants. Les privilèges accordés sur les objets existants sont conservés.

Exemple de code :

use role accountadmin;

-- Revoke the USAGE privilege on all existing schemas in a database from role R1
revoke usage on all schemas in database DB1 from role R1;

-- Revoke the SELECT and INSERT privilages on tables in a schema from the role R1
revoke select,insert on future tables in schema DB1.schema1 from role R1;

Gestion des autorisations futures à l’aide de l’interface Web

Vous pouvez également définir des autorisations futures à l’aide de l’interface Web :

  • Pour les objets de base de données : Cliquez sur Databases Databases tab » <nom_bd> » <type_objet> » <nom_objet> » Grant Privileges.

  • Pour les objets de schéma : Cliquez sur Databases Databases tab » <nom_bd> » Schemas » <nom_schéma> » Grant Privileges.

Restrictions et limitations

Les restrictions et limitations suivantes s’appliquent aux autorisations futures au niveau de la base de données ou du schéma :

  • Les autorisations futures ne sont pas prises en charge pour :

    • Partage de données

    • Réplication de données

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

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

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

  • Les autorisations futures au niveau de la base de données du privilège OWNERSHIP sur les objets des schémas d’accès géré dans la base de données ne sont pas affectées.

  • Lorsqu’une base de données est clonée, les schémas de la base de données clonée copient les autorisations futures des schémas sources. Cela maintient la cohérence avec les attributions d’objet normales, dans lesquelles les attributions de l’objet source (c’est-à-dire la base de données) ne sont pas copiées sur le clone, mais les octrois de tous les objets enfants (les schémas de la base de données) sont copiés sur les clones.

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 :

Interface Web

Cliquez sur Databases Databases tab » <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 :

Interface Web

Cliquez sur Databases Databases tab » <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

Permettre aux administrateurs sans compte de surveiller l’historique d’utilisation et de facturation

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

Interface Web

Cliquez sur Account Account tab » Billing & Usage.

SQL

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

Cependant, par défaut, ces informations ne peuvent être consultées que par les administrateurs de compte. Pour permettre aux utilisateurs qui ne sont pas des administrateurs de compte d’accéder à ces informations ou de les consulter, Snowflake propose le privilège global MONITOR USAGE. L’attribution du privilège MONITOR USAGE à un rôle permet à tous les utilisateurs auxquels ce rôle est accordé d’accéder à ces informations historiques/d’utilisation.

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 privilèges accordés.

Par exemple, pour accorder ce privilège au rôle custom :

GRANT MONITOR USAGE ON ACCOUNT TO ROLE custom;