Dans les articles précédents, on a posé pas mal de briques Snowflake : l’architecture, les types de tables, les streams... Maintenant on attaque un sujet qui arrive toujours tôt ou tard et sans surprise c'est les accès.

Quand on parle d'accès sur Snowflake, l'objectif n'est pas de faire marcher un SELECT une fois et de passer à autre chose, mais avoir un modèle scalable et qui reste propre dans la durée et quand :

  • Tu onboard 50 nouveaux utilisateurs
  • Tu branches un nouveau outil (QlikSense, Talend, Airflow ...)
  • Tu ajoutes des tables tous les jours
  • Tu dois répondre à tout moment à la question : “qui a accès à quoi ?”

La bonne nouvelle c'est que Snowflake est très cohérent mais à condition de partir sur une bonne base dés le debut.

Le modèle à retenir

C'est simple, dans Snowflake, les droits ne vont pas sur les users.
Les droits vont sur des rôles et ensuite les users reçoivent ces rôles.

On a donc 3 niveaux :

  • USER : un utilisateur (ou un compte technique)
  • ROLE : un ensemble de droits
  • PRIVILEGES : les actions autorisées (USAGE, SELECT, CREATE, …)

Si tu commences à donner les droits d'accès directement aux users, tu vas vite te retrouver avec un système impossible à maintenir.

La structure de rôles

Il est recommandé de garder une approche simple avec trois niveaux :

1) Rôle d'accès
C'est lui qui porte les droits sur les objets : database, schemas, tables, views etc..

2) Rôle métier
C'est celui que tu donnes aux utilisateurs : MARKETING_ANALYST, FINANCE_ANALYST, DATA_ENGINEER, etc..
Un rôle métier peut avoir un ou plusieurs rôles d'accès.

3) Rôle de service
Même logique, mais pour un outil comme : QLIKSENSE_SVC, AIRFLOW_SVC, FIVETRAN_SVC , TALEND_SVC, etc...

Pourquoi faut-il séparer les rôles ? C'est simple c'est pour éviter la redondance des droits et avoir un système flexible et robust.
Tu modifies le rôle d'accès une seule fois, et tout le monde hérite des changements correctement.

Exemple complet

On a une base FINANCE_DB, un schéma MART_FINANCE, un warehouse WH_FINANCE.

Objectif :

  • Un rôle d'accès en lecture
  • Un rôle métier pour le service de finance
  • Un rôle de service pour Qlik sense
  • Les droits sur les objets existants et futurs

1) Le rôle d'accès (lecture)

CREATE ROLE FINANCE_READ;

-- Base
GRANT USAGE ON DATABASE FINANCE_DB TO ROLE FINANCE_READ;
GRANT USAGE ON SCHEMA FINANCE_DB.MART_FINANCE TO ROLE FINANCE_READ;

-- Objets existants
GRANT SELECT ON ALL TABLES IN SCHEMA FINANCE_DB.MART_FINANCE TO ROLE FINANCE_READ;
GRANT SELECT ON ALL VIEWS  IN SCHEMA FINANCE_DB.MART_FINANCE TO ROLE FINANCE_READ;

-- Objets futurs (pour rien casser si y'a de nouvelles tables)
GRANT SELECT ON FUTURE TABLES IN SCHEMA FINANCE_DB.MART_FINANCE TO ROLE FINANCE_READ;
GRANT SELECT ON FUTURE VIEWS  IN SCHEMA FINANCE_DB.MART_FINANCE TO ROLE FINANCE_READ;

2) Le rôle métier

CREATE ROLE FINANCE_ANALYST;
GRANT ROLE FINANCE_READ TO ROLE FINANCE_ANALYST;

-- Compute
GRANT USAGE ON WAREHOUSE WH_FINANCE TO ROLE FINANCE_ANALYST;

3) Le rôle de service (Qlik Sense)

CREATE ROLE FINANCE_QLIK_SVC;
GRANT ROLE FINANCE_READ TO ROLE FINANCE_QLIK_SVC;

-- Compute
GRANT USAGE ON WAREHOUSE WH_FINANCE TO ROLE FINANCE_QLIK_SVC;

4) Rattacher à SYSADMIN (pour éviter les rôles “isolés”)

C'est important pour garder une hiérarchie claire et éviter des rôles perdus dans la nature 

GRANT ROLE FINANCE_ANALYST TO ROLE SYSADMIN;
GRANT ROLE FINANCE_QLIK_SVC TO ROLE SYSADMIN;

5) Ajouter un user

CREATE USER user_1
  PASSWORD = '...'
  DEFAULT_ROLE = FINANCE_ANALYST
  DEFAULT_WAREHOUSE = WH_FINANCE
  MUST_CHANGE_PASSWORD = TRUE;

GRANT ROLE FINANCE_ANALYST TO USER user_1;

Les deux pièges qui reviennent tout le temps

1) “J'ai le droit SELECT mais ça ne marche pas”

Très souvent, c'est parce qu'il manque le droit USAGE.

Snowflake est hiérarchique : database → schema → objets.-

Hiérarchie snowflake - Objets sécurisables


Donc pour lire une table, il faut avoir au minimum besoin de :

  • USAGE sur la database
  • USAGE sur le schema
  • SELECT sur la table (ou la vue)

Si un seul de ces niveaux manque, tu peux avoir l'impression d'avoir “le bon droit”… et pourtant être bloqué.

2) “J'ai les droits mais je ne peux rien exécuter”

Deuxième oubli classique : le warehouse.

Sans USAGE sur le warehouse, l'utilisateur peut parfois voir la structure… mais il ne peut pas lancer de requête (puisqu'il n'a aucun compute utilisable).

Les droits "futurs"

Donner des droits sur les tables existantes, c'est bien.
Mais si tu ne gères pas les objets futurs, ton modèle casse dès qu'une nouvelle table arrive.

Donc dès que tu fais un grant "ALL TABLES", pense aussi à "FUTURE TABLES".
C'est le petit détail qui transforme un modèle d'accès "support quotidien" en modèle d'accès "stable"

Le rôle ACCOUNTADMIN

Le rôle ACCOUNTADMIN est un rôle très puissant pour être utilisé au quotidien ou être donné à plusieurs utilisateurs.

Il est recommandé de le réserver à un nombre très restreint d'utilisateurs superadmin et de le garder uniquement pour les actions rares au niveau du compte.

Dans la même logique, il est également recommander d'éviter des rôles “fourre-tout” du style DATA_ALL_POWER.
Ça marche vite.. mais ça coûte cher en gouvernance, en audit, et sans parler des risques de sécurité.

Vérifier "qui a accés à quoi"

Quand quelqu'un dit "je n'ai pas accès", il faut commencer par :

SHOW GRANTS TO USER user_1;
SHOW GRANTS TO ROLE FINANCE_ANALYST;
SHOW GRANTS TO ROLE FINANCE_READ;

En général, tu repères immédiatement :

  • Un USAGE manquant (database/schema)
  • Un warehouse non accordé
  • Ou un oubli de droits "futurs"

Aller plus loin : Formation Snowflake

J’ai regroupé tous mes articles Snowflake dans un parcours complet.

👉 Accéder à la Formation Snowflake

Vous voulez que je vous accompagne sur votre projet data (Snowflake, ingestion, modélisation, performance, coûts, gouvernance) ?
👉 Réserver un appel de 30 minutes