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

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

L'un des défis consiste à le contrôle d'accès. Il s'agit d'un élément essentiel de tout programme data governance. Snowflake fournit caractéristiques prêtes à l'emploi pour vous 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 de gestion de votre compte.

Nous sommes passés par là. Pour l'un des nos clients, Nous avons géré un compte avec 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é créé et de nombreuses bonnes idées avaient été mises en œuvre. Rôles personnalisés a été créé. Les utilisateurs sont gérés avec soin. Mais il y a 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 dataniveau de base. Il permet de répliquer facilement les privilèges d'un environnement à l'autre en utilisant le clonage sans copie. Il s'agit é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 du database, 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 Signature unique pour permettre aux utilisateurs de Snowflake de connectez-vous via Azure Active Directory (AAD). Ainsi, nous avons supprimé la complexité liée à la gestion de deux bases data d'utilisateurs et le processus de désinscription a été plus robuste. En effet, il nous suffisait de désactiver l'utilisateur dans l'AAD et la suppression était automatiquement répliquée dans 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 de la procédure pour les utilisateurs humains réels, mais elle ne tient pas compte de l'une des limites 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 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 un relation univoque entre les comptes de service et leurs rôles. Nous limitons donc strictement l'étendue des autorisations 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 des 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 le 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 qui essayaient d'apporter des modifications en même temps. C'est pourquoi nous avons mis en place un 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 !