Utilisation des rôles définis par le système dans Snowflake pour la configuration du compte

Avec un compte Snowflake facilement utilisable et avec une compréhension limitée de ses rôles définis par le système, il devient généralement difficile pour un chef d’équipe ou un administrateur de configurer les environnements avec des contrôles d’accès appropriés pour ses développeurs ou utilisateurs.

Pour commencer avec la configuration du compte, vous aurez d’abord besoin d’un utilisateur disposant d’un accès au rôle ACCOUNTADMIN pour le compte snowflake.

Cela peut être fourni par un utilisateur qui a accès au compte ORGADMIN Snowflake. Cela peut être compris par l’exemple ci-dessous :

Une organisation a 1 compte à l’échelle de l’organisation Snowflake et est gérée par ORGADMIN.

ORGADMIN peut créer plusieurs comptes sous la même organisation dans snowflake, qui peuvent être gérés séparément par différentes équipes au sein de l’organisation.

Avant de commencer à créer des utilisateurs, des rôles, des entrepôts, des bases de données, etc., vous devez d’abord comprendre les rôles définis par le système ci-dessous dans Snowflake et ce que snowflake recommande comme meilleure pratique lors de la configuration du compte.

Vous trouverez ci-dessous les rôles définis par le système :

1. ADMINISTRATEUR UTILISATEUR :

La première partie du processus de création de compte consiste à créer des utilisateurs et des rôles au sein d’un compte.

L’objectif des rôles USERADMIN est la création d’utilisateurs et de rôles.

Ce rôle est accordé avec les privilèges de sécurité CREATE USER et CREATE ROLE.

2. ADMINISTRATEUR SECURITE:

Un rôle est incomplet sans aucun octroi et le rôle SECURITYADMIN est uniquement utilisé pour l’octroi.

Tout ce qui concerne les subventions dans Snowflake est entièrement géré par le rôle SECURITYADMIN.

Une fois les utilisateurs et les rôles créés par USERADMIN, vous pouvez utiliser SECURITYADMIN pour attribuer aux utilisateurs les rôles appropriés.

Vous pouvez accorder des entrepôts, des bases de données, des schémas, des objets d’intégration, l’accès pour créer des tables, des étapes, des vues, etc. à un rôle à l’aide du rôle SECURITYADMIN

Le rôle SECURITYADMIN hérite des privilèges du rôle USERADMIN via la hiérarchie des rôles système

Notez que Snowflake n’a pas le concept de groupes d’utilisateurs. Au lieu de cela, les utilisateurs sont créés et les rôles nécessaires sont accordés à l’utilisateur.

3. SYSADMIN:

SYSADMIN crée les objets comme les bases de données, les entrepôts, les schémas, etc. dans un compte.

Bien qu’il crée des objets tels que des bases de données, des entrepôts, etc., il n’accorde pas l’accès à ces objets aux rôles. C’est fait par SECURITYADMIN.

4. ADMINISTRATEUR DE COMPTE :

Le rôle ACCOUNTADMIN encapsule les rôles définis par le système SYSADMIN et SECURITYADMIN. Il s’agit du rôle de niveau supérieur dans le système et ne doit être accordé qu’à un nombre limité/contrôlé d’utilisateurs de votre compte.

En dehors de cela, ACCOUNTADMIN n’a accès qu’aux objets CREATE INTEGRATION dans snowflake.

En tant que meilleure pratique, activez les utilisateurs avec le rôle ACCOUNTADMIN doivent avoir MFA activé.

5. ORGANISATION :

Ce rôle est principalement utilisé pour créer des comptes au sein d’une organisation.

Chaque compte agit comme une entité distincte et aura ses propres bases de données, entrepôts et autres objets.

6. PUBLIQUE :

Comme son nom l’indique, ce rôle est accessible à tous les autres utilisateurs d’un compte.

Les objets créés dans le cadre d’un rôle PUBLIC sont accessibles à tous et utilisés lorsqu’il n’est pas nécessaire de contrôler l’accès aux objets et peuvent être partagés dans le compte.

Il n’est généralement pas recommandé d’utiliser ce rôle à des fins de production.

Créer un compte avec un exemple :

Depuis maintenant, il est clair sur ce que chaque rôle défini par le système est censé faire dans snowflake, voyons quelques exemples de base de la configuration d’un compte en les utilisant.

En supposant que vous vous êtes connecté en utilisant un utilisateur ayant un accès ACCOUNTADMIN, voyons le cas d’utilisation ci-dessous :

Il y a 4 utilisateurs nommés : meghna , adnan , kaushik et shushant

meghna et adnan font partie d’une équipe d’analyse qui crée des rapports à l’aide d’outils de création de rapports. Par conséquent, ils n’ont besoin que de l’accès en lecture pour les objets créés.

kaushik et shushant font partie de l’équipe d’ingénierie des données qui construit des pipelines pour charger les données dans les bases de données de flocons de neige.

Puisqu’il s’agit d’un environnement de développement, ils auront l’accès en lecture et en écriture sur les objets créés.

Utilisons donc les noms d’utilisateur comme prénoms : meghna , adnan , kaushik et shushant

Puisqu’ils travaillent dans un projet d’analyse et un environnement de développement, nous pouvons créer 2 rôles.

Un pour lire nommé ROLE_DEV_ANALYTICS_RO

et un pour l’accès en lecture/écriture nommé ROLE_DEV_ANALYTICS_RW

Voici comment nous allons progresser :

Tout d’abord, comme indiqué, créons les utilisateurs à l’aide du rôle USERADMIN.

utiliser le rôle USERADMIN ;

– Créer les rôles

créer le rôle ROLE_DEV_ANALYTICS_RO ;

créer le rôle ROLE_DEV_ANALYTICS_RW ;

– créer les utilisateurs

créer un utilisateur meghna password=’abc123′ default_role = ROLE_DEV_ANALYTICS_RO default_Secondary_roles = (‘ALL’) must_change_password = true ;

créer un utilisateur adnan password=’abc123′ default_role = ROLE_DEV_ANALYTICS_RO default_Secondary_roles = (‘ALL’) must_change_password = true ;

créer un utilisateur kaushik password=’abc123′ default_role = ROLE_DEV_ANALYTICS_RW default_Secondary_roles = (‘ALL’) must_change_password = true ;

créer un utilisateur shushant password=’abc123′ default_role = ROLE_DEV_ANALYTICS_RW default_Secondary_roles = (‘ALL’) must_change_password = true ;

Notez que les 4 utilisateurs sont créés en utilisant le même mot de passe avec l’argument must_change_password = true qui les forcera à changer les mots de passe lors de la première connexion.

Utilisez SECURITYADMIN pour accorder aux utilisateurs leurs rôles respectifs :

utiliser le rôle SECURITYADMIN ;

– Accorder les rôles créés à SYSADMIN

accordez le rôle ROLE_DEV_ANALYTICS_RO au rôle SYSADMIN ;

accordez le rôle ROLE_DEV_ANALYTICS_RW au rôle SYSADMIN ;

Ceci est fait pour que les objets tels que les tables, les étapes, les vues, etc. créés à l’aide des rôles soient également accessibles par SYSADMIN. Si cela n’est pas accordé, SYSADMIN ne pourra pas accéder ou gérer les objets créés par ces rôles.

utiliser le rôle SECURITYADMIN ;

– Attribuer aux utilisateurs les rôles

accordez ROLE ROLE_DEV_ANALYTICS_RO à l’utilisateur meghna ;

accordez ROLE ROLE_DEV_ANALYTICS_RO à l’utilisateur adnan ;

accordez ROLE ROLE_DEV_ANALYTICS_RW à l’utilisateur kaushik ;

accorder ROLE ROLE_DEV_ANALYTICS_RW à l’utilisateur shushant ;

Utilisons maintenant SYSADMIN pour créer l’entrepôt, les bases de données, les schémas, etc.

utiliser le rôle SYSADMIN ;

créer la base de données analytics_dev ;

créer le schéma analytics_dev.analytics_master ;

créer le schéma analytics_dev.analytics_summary ;

créer un entrepôt analytics_small avec

taille_entrepôt = ‘PETIT’

type_entrepôt = ‘STANDARD’

suspension_auto = 60

auto_resume = TRUE ;

Cela crée un petit entrepôt qui peut s’arrêter en 60 secondes d’inactivité et reprendre automatiquement chaque fois que des requêtes sont déclenchées.

Maintenant que la base de données, le schéma et l’entrepôt sont prêts, il est temps d’accorder aux rôles les accès nécessaires à l’aide de SECURITYADMIN.

Supposons que seules les tables sont des vues utilisées pour ce projet.

utiliser le rôle SECURITYADMIN ;

– Accorder l’accès d’utilisation à ROLE_DEV_ANALYTICS_RO

accorder l’utilisation de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RO ;

accorder l’utilisation sur tous les schémas de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RO ;

accorder la sélection sur les futures tables de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RO ;

accorder select sur toutes les tables de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RO ;

accorder la sélection sur les vues futures dans la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RO ;

accorder la sélection sur toutes les vues de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RO ;

– Accorder l’accès d’utilisation à ROLE_DEV_ANALYTICS_RW

accorder l’utilisation de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RW ;

accorder l’utilisation sur tous les schémas de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RW ;

accorder la sélection sur les futures tables de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RW ;

accorder select sur toutes les tables de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RW ;

accorder la sélection sur les vues futures dans la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RW ;

accorder la sélection sur toutes les vues de la base de données analytics_dev au rôle ROLE_DEV_ANALYTICS_RW ;

accorder la création d’une table sur le schéma analytics_dev.analytics_master au rôle ROLE_DEV_ANALYTICS_RW;

accorder la création d’une vue sur le schéma analytics_dev.analytics_master au rôle ROLE_DEV_ANALYTICS_RW;

accorder la création d’une table sur le schéma analytics_dev.analytics_summary au rôle ROLE_DEV_ANALYTICS_RW;

accorder la création d’une vue sur le schéma analytics_dev.analytics_summary au rôle ROLE_DEV_ANALYTICS_RW;

Comme vu ci-dessus ROLE_DEV_ANALYTICS_RO dispose d’un accès en lecture seule et ROLE_DEV_ANALYTICS_RW dispose d’un accès en lecture et en écriture.

Enfin, accordons l’entrepôt aux rôles.

accorder l’UTILISATION, OPÉRER sur l’entrepôt analytics_small jouer un rôle ROLE_DEV_ANALYTICS_RO;

accorder l’UTILISATION, OPÉRER sur l’entrepôt analytics_small jouer un rôle ROLE_DEV_ANALYTICS_RW;

Les utilisateurs disposant des autorisations appropriées devraient désormais pouvoir se connecter à snowflake et ne devraient pouvoir utiliser que les rôles associés aux autorisations appropriées.