Rôles Snowflake 101 : le guide complet du contrôle d'accès

Snowflake adopte une approche Role-Based Access Control (RBAC) pour gérer ce que les utilisateurs et autres systèmes peuvent consulter et faire. En RBAC, disposer d'un certain rôle revient à se voir attribuer certains privilèges.

Posons un peu de vocabulaire :

• User — entité qui permet à une personne (ou à un service) de se connecter à Snowflake.
• Object — entité à laquelle un User peut accéder (table, vue, base de données, etc.) s'il dispose des privilèges adéquats.
• Privilege — opération qu'un User peut exécuter sur un Object si son rôle en a reçu le droit.
• Role — entité de liaison entre les Users et les Privileges. Les privilèges sont accordés aux rôles, et les rôles sont accordés aux utilisateurs.

En bref, comme le résume Snowflake :

Les privilèges sont accordés aux rôles, et les rôles sont accordés aux utilisateurs, afin de spécifier les opérations que ces derniers peuvent effectuer sur les objets du système.

À partir de ces 4 concepts clés, les sections et schémas qui suivent se compléteront pour aboutir à une configuration de contrôle d'accès minimale, mais complète.

Users

Un User Snowflake est une identité capable de se connecter à un compte Snowflake et d'exécuter un ensemble d'opérations autorisées. Chaque personne de votre équipe data doit disposer d'un User Snowflake pour se connecter et exécuter des requêtes. Un User Snowflake peut aussi être utilisé par un système tiers — par exemple un outil BI (Tableau, Looker) ou un outil ELT (Stitch, Fivetran).

Au final, ce que les Users Snowflake sont autorisés à faire constitue l'enjeu central du contrôle d'accès.

Objects

Les Objects sont les primitives Snowflake auxquelles un accès peut être accordé. Les exemples les plus évidents sont les bases de données, les schémas et les tables, mais on y trouve aussi des objets de niveau compte comme les warehouses, les storage integrations, etc.

Voici quelques exemples courants d'Objects Snowflake :

Objet sécurisable	Niveau	Description
Database	Niveau compte	Les bases de données sont les objets clés qui maintiennent tous les autres objets sécurisables isolés et regroupés logiquement.
Schema	Niveau base de données	Un regroupement logique d'objets tels que des tables, des vues, des stages, etc.
Table	Niveau schéma	L'objet qui contient les données et occupe le stockage physique. Dans la plupart des cas, les tables sont la pierre angulaire de l'utilité de Snowflake. Il en existe plusieurs types, répondant chacun à des cas d'usage différents.
View	Niveau schéma	Une table déguisée. Elle donne accès à des données sans réellement occuper d'espace de stockage. Une vue se définit comme une requête posée sur d'autres tables. Il en existe plusieurs types, répondant chacun à des cas d'usage différents.
Virtual Warehouse	Niveau compte	Principales ressources de calcul nécessaires à l'exécution des requêtes ou au chargement de données dans Snowflake.
Storage Integration	Niveau compte	Objet qui connecte un bucket S3 (ou GCS, ou Azure Blob Storage) à Snowflake, permettant aux Users de charger ou décharger des données, ou d'interroger directement le contenu du bucket.
Snowpipe	Niveau schéma	Objet qui automatise le chargement de données depuis S3 (ou GCS, ou Azure Blob Storage) vers des tables dès qu'un nouveau fichier arrive dans le bucket.
Stage	Niveau schéma	Emplacement des fichiers de données (CSV, Parquet, etc.) dans le stockage cloud. Il existe deux types de stages : interne (stockage cloud géré par Snowflake) et externe (stockage cloud autogéré).

Privileges

Les privilèges sont un concept essentiel du contrôle d'accès. Ils autorisent une opération unique — ou parfois un ensemble d'opérations — à être exécutée sur un objet.

Par exemple, sur une Table Snowflake, un User peut avoir le privilège d'exécuter SELECT sur ses données, d'INSERT des lignes, de DELETE des données, etc. Sur une Database Snowflake, un User peut être autorisé à CREATE SCHEMA ou à MONITOR celle-ci.

Le tableau ci-dessous décrit brièvement quelques-uns des privilèges clés qui peuvent être accordés aux objets clés.

Object	Privilège	Description
Database	USAGE	Permet d'utiliser et de visualiser la base de données, mais d'autres privilèges sont nécessaires pour y effectuer des actions.
	MONITOR	Permet d'exécuter une commande DESCRIBE.
	CREATE SCHEMA	Permet de créer (ou cloner) un schéma dans la base de données.
	IMPORTED PRIVILEGES	S'applique uniquement aux bases de données partagées et permet à d'autres rôles du compte d'accéder aux objets partagés. Pour en savoir plus sur les imported privileges, consultez https://docs.snowflake.com/en/user-guide/data-share-consumers#option-1-objects-in-a-share-not-associated-with-a-database-role.
Schema	USAGE	Permet de voir et d'utiliser le schéma, mais requiert tout de même des privilèges supplémentaires sur les objets de niveau schéma pour les voir ou y exécuter des commandes.
	MONITOR	Permet d'exécuter une commande DESCRIBE.
	CREATE TABLE / CREATE VIEW / CREATE STAGE / CREATE PIPE	Permet de créer une table / vue / stage / pipe dans le schéma.
Table	SELECT	Permet d'interroger la table pour récupérer ses données.
	INSERT	Permet d'insérer des lignes dans la table.
	UPDATE	Permet de mettre à jour les données existantes dans la table.
	TRUNCATE	Permet de supprimer toutes les données de la table.
	DELETE	Permet de supprimer tout ou partie des lignes de la table.
View	SELECT	Permet d'interroger la vue pour en extraire les données (indépendamment des tables sous-jacentes et des privilèges qui y sont accordés).
Stage	USAGE	Permet d'utiliser le stage externe dans une instruction SQL.
	READ	Permet d'exécuter toute commande qui lit le stage interne (GET, LIST, COPY INTO).
	WRITE	Permet d'exécuter toute commande qui écrit dans le stage interne (PUT, REMOVE, COPY INTO).

Vous trouverez la liste complète des privilèges d'objets disponibles pour le contrôle d'accès Snowflake ici.

Avec cette liste en tête, il sera utile, lors de l'audit des accès, de garder à l'esprit que les privilèges sont accordés à différents niveaux selon l'endroit où l'objet est créé (niveau compte, niveau base de données, niveau schéma).

Le privilège d'Ownership

Snowflake adopte une approche Role-Based Access Control (RBAC) […]

👆 La première phrase de cette section n'était que partiellement vraie. Snowflake combine en réalité le RBAC avec un concept clé issu d'un autre modèle de contrôle d'accès : le Discretionary Access Control (DAC). En DAC, chaque objet doit avoir un propriétaire.

Dans l'implémentation DAC de Snowflake, chaque objet appartient au rôle utilisé pour le créer. Dire qu'un rôle possède un objet signifie qu'il dispose du privilège OWNERSHIP sur cet objet.

Il est important de comprendre que ce ne sont pas les Users qui possèdent les objets, mais les rôles. Si tous les Analysts de votre équipe data disposent du même rôle, les objets créés par un Analyst seront possédés par l'ensemble des Analysts.

Notez que le privilège OWNERSHIP sur un objet peut être transféré à un autre rôle. Vous pouvez par exemple vouloir transférer la propriété d'une table à un rôle plus puissant afin de restreindre qui peut en accorder l'accès à d'autres rôles.

Privilèges sur les objets futurs

Parfois, lors de la configuration initiale du contrôle d'accès, certains objets n'existent pas encore. Vous savez pourtant déjà qu'un certain rôle devra y accéder une fois ces objets créés. Snowflake permet d'anticiper en accordant certains privilèges sur des objets futurs.

On peut par exemple accorder à un rôle ANALYST le privilège SELECT sur les futures tables de la base GOLDEN_DB, ou sur les futures tables d'un schéma précis. Consultez cette documentation Snowflake pour en savoir plus sur la priorité des grants portant sur les objets futurs.

Roles

Vous pouvez voir les rôles Snowflake comme des clés. 🔑 Vous avez une clé pour votre maison, une autre pour votre voiture, et peut-être une pour le bureau. Si vous avez un voisin proche, il possède sans doute un double de la clé de chez vous (en cas d'urgence). Les clés de votre maison vous y donnent accès, à vous comme à votre voisin.

De la même manière, dans Snowflake, un rôle accordé à un utilisateur lui donne accès à diverses opérations et à divers objets. Voici une illustration de la façon dont notre organigramme pourrait se traduire en rôles Snowflake.

Snowflake propose trois grands types de rôles :

• les account roles,
• les database roles,
• les instance roles.

S'y ajoutent les application roles, liés aux Snowflake Native Applications — un sujet passionnant qui mériterait son propre billet et qui dépasse le cadre de ce Snowflake Roles 101.

Account Role

Les rôles Snowflake d'origine, les Account Roles, sont les rôles standards qui :

• peuvent recevoir des privilèges sur tous les objets sécurisables du compte,
• portent un nom unique à l'échelle du compte, et
• peuvent être accordés à des Users ou à d'autres Account Roles.

Database Role

Comme son nom l'indique, un Database Role est lié à une base de données précise, et :

• il ne peut recevoir que des privilèges spécifiques aux objets de cette base (schémas, tables, vues, etc.),
• son nom est unique à la base sur laquelle il est créé,
• il peut être accordé à d'autres Database Roles (au sein de la même base) ainsi qu'à des Account Roles,
• il ne peut pas être accordé directement à des Users, et
• il dispose par défaut du privilège USAGE sur sa base de données.

Instance Role

Les Instance Roles sont le type de rôle le moins utilisé. Ils sont rattachés à une Snowflake Class Instance et sont accordés à des Account Roles afin de permettre aux Users d'exécuter les méthodes de la Class Instance.

À l'heure où nous écrivons ces lignes, seul Snowflake peut créer des Classes. Pour en savoir plus sur les Snowflake Classes disponibles, c'est par ici.

Quel type de rôle utiliser ?

Si vous débutez, les Account Roles vous mèneront déjà loin.

Les choses deviennent intéressantes lorsque l'on s'attarde sur les database roles et sur leur capacité à simplifier et standardiser votre configuration : le propriétaire d'une base peut gérer lui-même les privilèges sur celle-ci, sans avoir besoin du rôle ACCOUNTADMIN.

Par ailleurs, si vous utilisez des Snowflake Shares pour partager vos données, les database roles rendent le contrôle d'accès bien plus simple à configurer.

Les rôles peuvent aussi être accordés à d'autres rôles, ce qui crée une hiérarchie de rôles.

Le plus simple pour définir une hiérarchie est de l'illustrer par un exemple. Avec la hiérarchie ci-dessous, Splinter, qui dispose du rôle SYSADMIN, hérite des privilèges des rôles DATA_ENG_ROLE, ANALYST_ROLE et DB_MANAGER_ROLE, tandis que Kim ne dispose que des privilèges de DATA_ENG_ROLE et DB_MANAGER_ROLE.

Lorsque vous créez un compte Snowflake et que vous ouvrez Admin / Users & Roles, vous y trouverez un ensemble de rôles créés par défaut par Snowflake. Ces rôles system-defined ne peuvent être ni supprimés, ni modifiés dans leur jeu de privilèges standard. Chacun remplit une fonction précise :

• ACCOUNTADMIN — le rôle god mode, capable de tout faire au niveau du compte. Soyez attentif à qui vous l'accordez. Notez qu'ACCOUNTADMIN hérite de tous les privilèges des rôles SECURITYADMIN et SYSADMIN.
• SECURITYADMIN — ce rôle dispose du privilège MANAGE GRANTS au niveau compte, ce qui lui permet d'accorder (ou de révoquer) des droits sur tous les objets du compte vers (ou depuis) d'autres rôles. Il hérite également de tous les privilèges qui lui sont transmis par le rôle USERADMIN.
• USERADMIN — comme son nom l'indique, ce rôle sert à créer et gérer les utilisateurs (grâce aux privilèges de niveau compte CREATE USER et CREATE ROLE).
• SYSADMIN — ce rôle peut créer tous les objets du compte (bases de données, warehouses et autres objets de niveau schéma).
• PUBLIC — tous les utilisateurs du compte se voient attribuer par défaut le rôle PUBLIC, mais sans accès explicite à des objets, il ne peut pas faire grand-chose. Faites néanmoins très attention à ne pas lui accorder par mégarde des privilèges sur des données sensibles, sous peine de les rendre accessibles à tous les utilisateurs du compte. Ou, mieux encore, n'accordez aucun privilège au rôle PUBLIC. 😉

Enfin, ORGADMIN mérite une attention particulière. Il sert aux opérations à l'échelle de l'organisation, comme la création de comptes Snowflake supplémentaires, et ne s'intègre pas vraiment dans la hiérarchie de rôles par défaut.

Lorsque vous créez des rôles personnalisés et bâtissez une hiérarchie, Snowflake recommande que tous les rôles personnalisés finissent par être descendants de SYSADMIN.

D'après notre expérience sur de nombreux comptes Snowflake, il est fréquent que la majorité des objets d'une base soient créés et possédés par ACCOUNTADMIN. C'est globalement une mauvaise pratique : elle trahit un manque de réflexion sur le contrôle d'accès et signale qu'ACCOUNTADMIN est utilisé comme rôle par défaut, ce qui peut conduire à des erreurs destructrices, comme la suppression de données ou d'utilisateurs. Nous reviendrons sur les bonnes pratiques de contrôle d'accès dans la partie II de cette série. 🙌

Rôle par défaut d'un User

Lorsqu'un utilisateur se connecte à Snowflake, il établit une session, qui nécessite dans la plupart des cas qu'un rôle lui soit défini. À défaut, Snowflake retombera sur le rôle par défaut de l'utilisateur.

Rôles secondaires

Les secondary roles permettent à un utilisateur de cumuler les capacités d'accès de plusieurs rôles en même temps. La plupart des clients Snowflake n'utilisent que des rôles primaires (un seul rôle à la fois), mais les secondary roles constituent une fonctionnalité puissante qui peut éviter d'avoir à combiner plusieurs rôles.

De la même manière que vous exécutez use role pour définir votre rôle principal dans une session donnée, vous pouvez exécuter use secondary roles. La principale différence est que cette commande accepte deux options :

1. use secondary roles all active tous les rôles auxquels un utilisateur a accès,
2. use secondary roles none désactive les rôles secondaires.

Très bien, très bien — Montre-moi du SQL ! 💢, je vous entends.

Assemblons le puzzle à travers un exemple de bout en bout : initialiser un compte Snowflake tout neuf et permettre à Kim et Rufus de l'utiliser selon leurs besoins.

En résumé :

• On crée les Users, les Roles et la Database.

use role SECURITYADMIN;
create role DATA_ENGINEER_ROLE;
create role DB_MANAGER_ROLE;
create role ANALYST_ROLE;

use role USERADMIN;
create user KIM;

use role SYSADMIN; -- objects are owned by the active role
create database SOURCE_DB;
create warehouse ANALYSIS_WH;

• Les privilèges sur les objets sécurisables sont accordés aux rôles.

use role SECURITYADMIN;

grant USAGE, MODIFY, CREATE SCHEMA
	on database SOURCE_DB to role DB_MANAGER_ROLE;
grant USAGE on database SOURCE_DB to role ANALYST_ROLE;

grant USAGE, OPERATE
	on warehouse ANALYSIS_WH to role ANALYST_ROLE;

• Les rôles sont reliés entre eux dans une hiérarchie, ce qui crée un héritage des privilèges.

use role SECURITYADMIN;

grant role DB_MANAGER_ROLE to role DATA_ENGINEER_ROLE;
grant role ANALYST_ROLE to role DATA_ENGINEER_ROLE;
grant role DATA_ENGINEER_ROLE to role SYSADMIN;

• Les Users accèdent aux objets sécurisables via l'attribution de rôles.

use role SECURITYADMIN;

grant role DATA_ENGINEER_ROLE to user KIM;
grant role ANALYST_ROLE to user RUFUS;

On aboutit à une configuration qui :

1. permet à Kim :
2. de créer des schémas dans la base SOURCE_DB et de l'utiliser ;
3. d'utiliser et d'opérer le warehouse ANALYSIS_WH ;
4. permet à Rufus :
5. d'utiliser la base SOURCE_DB (si vous vous demandez s'il manque des privilèges supplémentaires sur les schémas et les bases, vous avez 💯 raison, mais ils ont été volontairement omis pour rester simples) ;
6. d'utiliser et d'opérer le warehouse ANALYSIS_WH.

Bien que très simple, cette configuration vous fournit toutes les briques nécessaires pour mettre en œuvre votre propre modèle RBAC dans Snowflake. Dans la partie II de cette série, nous aborderons les bonnes pratiques RBAC Snowflake et partagerons quelques recommandations assumées.