Les bases de la sécurité dans Snowflake

Quelles sont les notions de sécurité à comprendre quand on débute avec Snowflake ?

Contexte

Snowflake est un outil disponible via Internet, vous devez donc vous préoccuper de sa sécurisation avec la plus grande attention. En termes de sécurité, nous allons aborder les 2 éléments importants :

Les accès à l’outil avec les moyens de protéger les connexions.
Les accès dans l’outil avec les moyens de protéger les données.

Security By Design

Ce terme désigne le fait de définir le fonctionnement de sa sécurité AVANT de faire entrer les premières données dans le système. C’est une très bonne pratique si on souhaite avoir un système protégé. Dans le cas contraire si vous laissez vos utilisateurs avoir tous les droits et tout voir dès le début la mise en place des moyens permettant de garantir un bon niveau de sécurité de vos données et une liberté de travail suffisante pour vos utilisateurs sera très douloureuse à mettre en place à postériori.

Le design de votre sécurité doit être adapté à vos besoins et à vos risques, le seul conseil que l’on pourrait appliquer à chacun est le principe de moindre privilège. Ne donner à chacun que les droits dont ils ont besoin et pas plus.

Les administrateurs sont les principaux concernés par ce principe. Par exemple une personne ayant un rôle d’analyste et d’administrateur de la plate-forme aura tout intérêt à avoir 2 comptes distincts afin de se protéger notamment des erreurs de manipulation, plus fréquentes que les vols d’identifiants.

Les connexions

Quand on parle de connexion à un outil, il faut en général prendre en compte 2 types de connexion

Les connexions faites par des humains qui peuvent interagir avec l’interface.
Les connexions faites par des programmes qui doivent se faire sans interactions.

Un autre élément important à prendre en compte est le provisionnement des comptes, mais aussi le décommissionnement. En effet, mieux vaut créer les comptes de manière automatisés afin d’éviter des erreurs humaines, mais aussi prévoir dès le départ comment gérer les départs de vos utilisateurs.

Mode de connexion

Snowflake propose plusieurs modes d’authentification pour vos comptes parmi lesquelles je retiendrais :

Le classique Login / Mot de passe
- Utilisable par un humain ou un programme
- Devra être décomissionné en plus de votre stratégie actuelle de décommisionement de compte d’entreprise.
Le SSO avec Entra Id (ex Azure AD)
- Facile à mettre en place, mais utilisable seulement par un humain, car cela ne prend pas en charge les principaux de service.
- Un autoprovisionning des comptes peut être mis en place depuis votre Entra ID.
La clé RSA, permettant de ce connecter via un système clé publique/clé privée très robuste.
- Utilisable par un programme

La mise en place du SSO avec Entra Id ou Okta me semble un prérequis si vous utilisez déjà ces services.
Pour Entra ID vous pouvez faire des tests pour vérifier la faisabilité et vous rassurez, en créant un compte de test gratuit Microsoft 365 pour Entra ID et un compte gratuit Snowflake.

Pour les programmes, utilisez de préférence une clé RSA quand c’est possible.

Attention aux cumuls des authentifications

Les modes d’authentification peuvent être cumulés. Vous pouvez par exemple paramétré un login/mot de passe et une clé RSA. Je pense que ce genre de pratique doit être évité, car cela représente 2 modes d’attaque cumulables. Une clé RSA seule ou un mot de passe fort (plus de 15 caractères en 2023) sont préférables.

Les rôles

Quand on parle de sécurisation des objets Snowflake, on parle de rôle. En effet les droits sont affectables seulement à des rôles. Ensuite vous pouvez affecter un rôle à un autre rôle afin de cumuler des droits basiques. Enfin vous pourrez affecter un ou plusieurs rôles à vos utilisateurs afin de leur donner des droits.

Vous trouverez tous les détails dans la documentation officielle Aperçu du contrôle d’accès.

Les rôles spéciaux

En fonction des tâches que vous réalisez, choisissez le bon rôle :

SECURITYADMIN : Pour toutes les tâches d’affectation de droits.
USERADMIN : Pour toutes les tâches de création d’utilisateurs et de rôles.
SYSADMIN : Pour toutes les opérations de création d’objets liés aux données (bases, warehouse, …).
ACCOUNTADMIN : À utiliser dans les rares exceptions où vous avez besoin de droits de très haut niveau.

Comme dans la vie, il est important de se mettre dans le bon rôle en fonction de ce que l’on veut faire.

Les rôles spéciaux sont à réserver aux tâches d’administration de la plate-forme, pour gérer les accès de vos utilisateurs, créer des rôles adaptés à leurs besoins.

Donner des droits

Pour donner des droits sur un objet dans Snowflake, on utilisera la commande SQL GRANT et on utilisera REVOKE pour supprimer un droit. Chaque type d’objet dans Snowflake possède sa panoplie de droit, par exemple pour une table vous pouvez donner les droits suivants :

DELETE : Permets de supprimer des lignes.
INSERT : Permets d’ajouter des lignes.
REFERENCES : Permets de référencer la table quand vous partagez une vue sécurisée.
SELECT : Permets de lire les lignes de la table.
TRUNCATE : Permets de vider la table.
UPDATE : Permets de mettre à jour une ligne.

Pas d’héritage

Dans Snowflake il n’y a pas de notion d’héritage implicite d’un objet parent vers un objet enfant. Par exemple votre rôle peut avoir le ownership d’une base de données, mais pas pour autant le droit de lecture sur une table. Pour avoir des droits sur un objet, il y a donc 2 possibilités :

Avoir le droit ownership de l’objet, un seul rôle peut avoir ce droit.
Avoir un droit explicitement donné par un GRANT sur l’objet.

Créer vos propres rôles

Afin de maitriser la sécurité de Snowflake, vous devrez réfléchir à une stratégie de rôles personnalisée permettant à vos équipes de travailler sans trop leur donner de droits pour autant.

Par exemple si vous voulez donner au rôle MON_ROLE le droit de lire la table MA_TABLE du schéma MON_SCHEMA de la base MA_BASE vous devrez procéder de la manière suivante :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- Création du rôle MON_ROLE
CREATE ROLE IF NOT EXISTS MON_ROLE;
-- On affecte le rôle MON_ROLE au rôle SYSADMIN
GRANT ROLE MON_ROLE TO ROLE SYSADMIN;
-- On donne à MON_ROLE le droit d'accéder au warehouse MON_WARHOUSE
GRANT USAGE ON WAREHOUSE MON_WARHOUSE TO ROLE MON_ROLE;
-- On donne à MON_ROLE le droit d'accéder à la base MA_BASE
GRANT USAGE ON DATABASE MA_BASE TO ROLE MON_ROLE;
-- On donne à MON_ROLE le droit d'accéder au schéma MON_SCHEMA
GRANT USAGE ON SCHEMA MON_SCHEMA TO ROLE MON_ROLE;
-- On donne à MON_ROLE le droit de lire la table MA_TABLE
GRANT SELECT ON TABLE MA_TABLE TO ROLE MON_ROLE;
-- Maintenant MON_ROLE peut faire la requête : SELECT * FROM MA_TABLE;

Il existe bien sûr des commandes pour vous aidez à aller vite et vous permettre de donner tous les droits d’un coup (GRANT ALL PRIVILEGES) ou sur les futurs schémas d’une base ou les futures tables d’un schéma.
Bien sûr donner des droits massivement peut créer des failles massivement.

Merci de votre attention.