Configuration du contrôle d’accès¶

Administration des comptes¶

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 :

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é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 :

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;

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 :

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.

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.

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 » <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 » <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é :

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.

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 » Billing & Usage.

SQL

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

• Les fonctions de table (dans Schéma d’information de Snowflake) :

  • DATABASE_STORAGE_USAGE_HISTORY

  • STAGE_STORAGE_USAGE_HISTORY

  • WAREHOUSE_LOAD_HISTORY

  • WAREHOUSE_METERING_HISTORY

• Les vues (dans Account Usage) :

  • Vue DATABASE_STORAGE_USAGE_HISTORY

  • Vue STAGE_STORAGE_USAGE_HISTORY

  • Vue WAREHOUSE_LOAD_HISTORY

  • Vue WAREHOUSE_METERING_HISTORY

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