Contrôle d'accès Snowflake à l'échelle

De plus en plus d'entreprises placent Snowflake au cœur de leurs plateformes data . Même s'il s'agit d'une solution gérée, vous devez toujours administrer l'environnement. Cela peut être un défi, surtout pour les grandes entreprises.

L'un des défis est le contrôle d'accès. Il s'agit d'un élément essentiel de tout programme de gouvernance data . Snowflake fournit des fonctionnalités prêtes à l'emploi pour aider à relever ce défi. Mais lorsque vous avez des dizaines d'utilisateurs et des téraoctets de data, les fonctions intégrées ne suffisent pas. Vous devez réfléchir à une stratégie pour gérer votre compte.

Nous sommes passés par là. Pour l'un de nos clients, nous avons géré un compte comptant plus de 50 utilisateurs actifs. Nous avons conçu une solution permettant d'échelonner la gestion du contrôle d'accès.

Cet article décrit les principaux enseignements tirés de l'année écoulée.

Avant que nous ne rejoignions l'entreprise, le compte avait été configuré et de nombreuses bonnes idées avaient été mises en œuvre. Des rôles personnalisés avaient été créés. Les utilisateurs étaient gérés avec soin. Mais il y avait quelques limitations :

Nous avons créé un nouveau système pour gérer le contrôle d'accès et lutter contre ces lacunes.

Tout d'abord, nous avons révoqué tous les rôles attribués par défaut (SYSADMIN, USERADMIN ...) aux utilisateurs ... Seules quelques personnes ont pu assumer ces rôles. Il s'agissait des personnes chargées de l'administration.

Deuxièmement, nous avons créé un cadre de contrôle d'accès basé sur des rôles personnalisés. Nous avons défini deux types de rôles personnalisés :

Nous avons choisi de définir les rôles d'accès au niveau de la base de données. Cela permet de répliquer facilement les privilèges d'un environnement à l'autre en utilisant le clonage sans copie. Il s'agissait également d'un compromis entre la flexibilité que nous accordons aux utilisateurs finaux et l'application stricte du principe du moindre privilège.

Au niveau de la base de données, nous avons défini 3 niveaux de rôles d'accès :

Nous avons appliqué une stratégie similaire à l'accès aux entrepôts avec deux types de rôles :

Vous trouverez ci-dessous une illustration de notre cadre. Les flèches représentent les subventions.

À ce stade, nous avions une meilleure idée de la manière dont nous allions gérer les autorisations, mais nous avions également des problèmes avec la gestion des utilisateurs.

Nous avons mis en place l'authentification unique pour permettre aux utilisateurs de Snowflake de se connecter via Azure Active Directory (AAD). Ainsi, nous avons supprimé la complexité liée à la gestion de deux bases de données d'utilisateurs et le processus de désinscription a été plus robuste. En effet, il nous suffisait de désactiver l'utilisateur dans AAD et la suppression était automatiquement répliquée sur Snowflake.

Comme il existe une correspondance entre les groupes AD et les rôles dans Snowflake, nous avons pu attribuer un rôle à chaque utilisateur que nous avons créé. Nous suivons le même processus pour chaque nouvel utilisateur.

Il s'agit du processus pour les utilisateurs humains réels, mais il ne répond pas à l'une des limitations mentionnées au début de cet article : l'utilisation d'informations d'identification personnelles pour des tâches automatisées.

C'est pourquoi nous avons introduit les comptes de service. La gestion des comptes de service est très similaire à ce que nous venons de décrire. La seule différence est que nous créons un rôle fonctionnel pour chaque compte de service. Il existe une relation univoque entre les comptes de service et leurs rôles. Ainsi, nous limitons strictement l'étendue des permissions pour chaque compte de service.

Ces étapes ont constitué de grandes améliorations. Tout était documenté. Les équipes ont rapidement adopté le nouveau cadre. Nous étions heureux.

Mais nous passions encore beaucoup de temps à accorder des accès manuellement, et comme c'était très manuel, c'était aussi une source d'erreurs. La nécessité d'un outil permettant d'automatiser ces tâches était évidente.

Plusieurs options s'offraient à nous :

Nous avons finalement créé un CLI en Python.

Nous préférons utiliser Terraform pour déployer l'infrastructure et uniquement l'infrastructure. Des comportements indésirables peuvent se produire lorsque vous commencez à gérer vos utilisateurs et vos permissions avec Terraform. Par exemple, la rotation des secrets est très difficile à gérer.

Nous aimons bien bash mais seulement pour des opérations simples et ad-hoc. Ici, nous avons besoin de charger des fichiers de configuration, d'interagir avec l'API Snowflake et de manipuler les structures data . C'est possible, mais ce serait difficile à maintenir à long terme.

En plus de cet aspect, nous avions besoin de fiabilité. Une façon d'y parvenir est d'écrire des tests. Cela est plus facile à faire dans les langages de programmation tels que Python.

Lorsque vous exécutez l'outil, voici ce qui se passe en coulisses.

Par conception, l'outil ne crée pas un rôle qui existe déjà. Il en va de même pour les privilèges. L'outil calcule la différence entre la configuration et l'environnement distant et applique les changements nécessaires. Cela nous permet d'éviter tout temps d'arrêt.

Dans un premier temps, nous avons exécuté cet outil localement. Mais cela pouvait poser des problèmes. Par exemple, nous pouvions avoir des conflits entre deux ingénieurs essayant d'apporter des modifications en même temps. C'est pourquoi nous avons mis en place un flux de travail basé sur les capacités CI/CD d'Azure DevOps (ADO).

Note : nous avons utilisé ADO mais vous pouvez faire la même chose avec GitHub, GitLab ou Bitbucket.

Voici le processus final.

Ce flux de travail entièrement automatisé fonctionne très bien. Les tests détectent les défauts dès le début du pipeline CI. Et la révision obligatoire est également un moyen de prévenir les incidents.

En outre, les demandes d'extraction servent en quelque sorte de documentation pour toutes les demandes.

Cela fait un peu moins d'un an que nous avons commencé à utiliser cette solution. Bien que la mise en œuvre ait nécessité un investissement initial en temps, cela en valait vraiment la peine.

Nous passons désormais plus de temps à discuter avec les utilisateurs de leurs demandes qu'à les mettre en œuvre. La plupart des demandes peuvent être résolues en une dizaine de lignes de YAML. C'est très efficace et cela s'adapte bien. Nous continuons à accueillir de nouveaux utilisateurs et nous pouvons faire face à la demande. Nous avons également résolu les problèmes initiaux. C'est donc un succès !