Autrefois, à l’époque où les serveurs Unix hébergés sur site avec de vastes systèmes de fichiers étaient monnaie courante, les entreprises mettaient en place des règles et des stratégies de gestion de dossiers très élaborées. L’objectif principal était de régir les autorisations d’accès aux différents répertoires, en fonction des rôles et des besoins des utilisateurs.
Généralement, la plateforme d’une organisation est utilisée par divers groupes d’utilisateurs, chacun ayant des intérêts spécifiques, des restrictions de confidentialité ou des types de contenu complètement distincts. Pour les entreprises internationales, cela pouvait même impliquer la séparation du contenu en fonction de la localisation géographique, afin de cloisonner les données entre les utilisateurs de différents pays.
D’autres exemples typiques incluent :
- La segmentation des données entre les environnements de développement, de test et de production.
- Le contenu commercial qui ne doit pas être accessible au grand public.
- Le contenu législatif spécifique à un pays, qui ne doit pas être visible ou accessible depuis d’autres régions.
- Le contenu lié à un projet, où les « données de direction » doivent être réservées à un cercle restreint de personnes.
Les exemples de ce type sont potentiellement infinis. L’idée centrale est qu’il existe toujours une nécessité d’orchestrer les droits d’accès aux fichiers et aux données parmi tous les utilisateurs ayant accès à la plateforme.
Avec les solutions sur site, cette tâche était relativement simple. L’administrateur du système de fichiers configurait des règles spécifiques, en utilisant un outil de son choix. Ensuite, les utilisateurs étaient regroupés, et ces groupes étaient associés à des listes de dossiers ou de points de montage auxquels ils pouvaient accéder, avec un niveau d’accès défini (lecture seule ou lecture/écriture).
En considérant les plateformes cloud AWS, il est logique de s’attendre à ce que les besoins en matière de restriction d’accès au contenu soient similaires. Toutefois, la solution à ce défi doit être différente. Les fichiers ne résident plus sur des serveurs Unix, mais dans le cloud (et peuvent être potentiellement accessibles non seulement à l’ensemble de l’organisation, mais même au monde entier). Le contenu n’est plus stocké dans des dossiers, mais dans des compartiments S3.
Ci-dessous, nous allons examiner une alternative pour aborder ce problème. Elle est basée sur mon expérience pratique en matière de conception de solutions similaires pour un projet réel.
Une approche simple, mais très manuelle
Une méthode pour résoudre ce problème sans automatisation est relativement simple :
- Créer un nouveau compartiment S3 pour chaque groupe distinct d’utilisateurs.
- Attribuer des autorisations d’accès à chaque compartiment afin que seul le groupe concerné puisse y accéder.
Cette méthode est envisageable si vous recherchez une solution très simple et rapide. Cependant, elle présente certaines limitations qu’il faut connaître.
Par défaut, un compte AWS ne peut créer que 100 compartiments S3 au maximum. Cette limite peut être augmentée à 1 000 en soumettant une demande d’augmentation de limite de service auprès d’AWS. Si ces limites ne posent pas de problème pour votre cas spécifique, vous pouvez attribuer un compartiment S3 unique à chacun de vos groupes d’utilisateurs et considérer le problème comme résolu.
Des complications peuvent surgir s’il existe des groupes de personnes ayant des responsabilités transversales, ou des individus ayant besoin d’accéder à du contenu provenant de plusieurs domaines en même temps. Par exemple :
- Les analystes de données qui évaluent des informations issues de divers domaines, régions, etc.
- L’équipe de test, qui fournit des services à différentes équipes de développement.
- Les utilisateurs responsables des rapports, qui doivent créer des analyses de tableaux de bord pour différents pays d’une même région.
Comme vous pouvez l’imaginer, cette liste est extensible à l’infini, et les besoins d’une organisation peuvent générer une multitude de cas d’utilisation.
Plus la situation est complexe, plus il est important d’orchestrer finement les droits d’accès, afin d’octroyer à chaque groupe les autorisations adéquates pour accéder aux différents compartiments S3 de l’organisation. Des outils supplémentaires, voire une personne dédiée (administrateur), pourraient être nécessaires pour gérer les listes d’accès et les mettre à jour à chaque modification (ce qui arrivera très souvent, surtout si l’organisation est de grande taille).
Comment réaliser la même chose de manière plus structurée et automatisée ?
Si l’approche d’un compartiment par domaine n’est pas envisageable, toute autre solution impliquera des compartiments partagés par plusieurs groupes d’utilisateurs. Dans ces situations, il est nécessaire de créer une logique d’attribution des droits d’accès facile à modifier ou à mettre à jour dynamiquement.
Une méthode consiste à utiliser des balises sur les compartiments S3. Il est recommandé d’utiliser les balises dans tous les cas (ne serait-ce que pour simplifier la catégorisation de la facturation). De plus, la balise peut être modifiée ultérieurement pour n’importe quel compartiment.
Si toute la logique repose sur les balises du compartiment et que le reste dépend de la configuration des valeurs des balises, vous obtenez une solution dynamique, car il est possible de redéfinir la fonction d’un compartiment simplement en modifiant les valeurs de ses balises.
Quel type de balises utiliser pour que cela fonctionne ?
Cela dépend de votre cas d’utilisation spécifique. Par exemple :
- Il peut être nécessaire de séparer les compartiments par type d’environnement. Dans ce cas, l’une des balises doit être nommée « ENV », avec les valeurs possibles « DEV », « TEST », « PROD », etc.
- Peut-être souhaitez-vous segmenter l’accès par pays. Dans ce cas, une balise « COUNTRY » avec un nom de pays en valeur est appropriée.
- Il est également possible de séparer les utilisateurs en fonction du service fonctionnel auquel ils appartiennent, comme les analystes commerciaux, les utilisateurs de l’entrepôt de données, les data scientists, etc. On peut créer une balise nommée « USER_TYPE », avec la valeur correspondante.
- Une autre option pourrait être de définir explicitement une structure de dossiers fixe que des groupes d’utilisateurs spécifiques doivent respecter (pour éviter de créer un fouillis de dossiers et de s’y perdre). Vous pouvez réaliser cela à l’aide de balises, en spécifiant plusieurs répertoires de travail tels que : « data/import », « data/processed », « data/error », etc.
Dans l’idéal, les balises doivent être définies de manière à pouvoir être combinées logiquement et à former une structure de dossiers complète sur le compartiment.
Par exemple, il est possible d’associer les balises mentionnées précédemment pour créer une structure de dossiers dédiée pour différents types d’utilisateurs, de différents pays, avec des dossiers d’importation prédéfinis :
- /<ENV>/<USER_TYPE>/<COUNTRY>/<UPLOAD>
En modifiant simplement la valeur de <ENV>, vous pouvez redéfinir l’objectif de la balise (pour déterminer si elle est liée à l’environnement de test, de développement, de production, etc.).
Cela permet d’utiliser le même compartiment pour un grand nombre d’utilisateurs différents. Les compartiments ne prennent pas explicitement en charge les dossiers, mais ils supportent les « étiquettes ». Ces étiquettes fonctionnent en fait comme des sous-dossiers, car les utilisateurs doivent parcourir une série d’étiquettes pour accéder à leurs données (comme ils le feraient avec des sous-dossiers).
Une fois les balises définies de manière utilisable, l’étape suivante consiste à créer des politiques de compartiment S3 qui utiliseront ces balises.
Si les politiques utilisent les noms des balises, vous créez ce qu’on appelle des « politiques dynamiques ». Concrètement, cela signifie que votre politique se comportera différemment pour les compartiments ayant des valeurs de balise différentes, auxquelles la politique fait référence dans sa configuration ou ses espaces réservés.
Cette étape implique évidemment un développement personnalisé pour les politiques dynamiques, mais vous pouvez simplifier cette tâche à l’aide de l’outil d’éditeur de politiques Amazon AWS, qui vous guidera tout au long du processus.
Dans la politique elle-même, vous devrez définir les autorisations d’accès concrètes qui seront appliquées au compartiment et le niveau d’accès (lecture, écriture). La logique lira les balises des compartiments et créera la structure de dossiers sur le compartiment (en créant des étiquettes basées sur les balises). En fonction des valeurs concrètes des balises, les sous-dossiers seront créés et les autorisations d’accès requises seront attribuées.
L’avantage de cette politique dynamique est qu’elle peut être créée une seule fois, puis attribuée à plusieurs compartiments. Elle se comportera différemment pour les compartiments ayant des valeurs de balise distinctes, mais elle répondra toujours à vos attentes en fonction de ces valeurs.
C’est une manière très efficace de gérer les attributions de droits d’accès de manière organisée et centralisée pour un grand nombre de compartiments, où l’on s’attend à ce que chaque compartiment suive une structure prédéfinie qui sera utilisée par tous les utilisateurs de l’organisation.
Automatisez l’intégration de nouvelles entités
Une fois les politiques dynamiques définies et attribuées aux compartiments existants, les utilisateurs peuvent commencer à les utiliser, sans risquer que des utilisateurs de groupes différents accèdent au contenu (stocké dans le même compartiment) qui se trouve dans une structure de dossiers à laquelle ils n’ont pas accès.
De plus, certains groupes d’utilisateurs ayant des accès plus larges pourront facilement accéder à toutes les données, car celles-ci seront stockées dans le même compartiment.
La dernière étape consiste à simplifier au maximum l’intégration de nouveaux utilisateurs, de nouveaux compartiments, et même de nouvelles balises. Cela implique un développement personnalisé supplémentaire, mais celui-ci n’a pas besoin d’être trop complexe, à condition que votre processus d’intégration ait des règles claires et qu’il soit possible de l’encapsuler dans un algorithme simple. (Au moins, vous pouvez ainsi prouver que votre processus suit une certaine logique et qu’il n’est pas trop chaotique.)
Cela peut être aussi simple que de créer un script exécutable à l’aide de la ligne de commande AWS CLI, avec les paramètres nécessaires pour intégrer correctement une nouvelle entité à la plateforme. Il peut même s’agir d’une série de scripts CLI, exécutables dans un ordre spécifique, comme par exemple :
- create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
- create_new_tag(<bucket_id>,<tag_name>,<tag_value>)
- update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
- create_user_group(<type_utilisateur>,<pays>,<env>)
- etc.
Vous avez compris l’idée. 😃
Un conseil de pro 👨💻
Voici un conseil de pro qui peut être facilement mis en œuvre en complément de ce qui précède.
Les politiques dynamiques peuvent être utilisées non seulement pour attribuer des droits d’accès aux emplacements de dossiers, mais également pour octroyer automatiquement des droits d’accès aux services pour les compartiments et les groupes d’utilisateurs !
Il suffirait d’enrichir la liste des balises sur les compartiments, puis d’ajouter des autorisations à la politique dynamique pour autoriser des groupes d’utilisateurs à utiliser des services spécifiques.
Par exemple, un groupe d’utilisateurs peut également avoir besoin d’accéder à un serveur de cluster de base de données spécifique. Cela peut être réalisé avec des politiques dynamiques tirant parti des tâches de compartiment, surtout si les accès aux services sont gérés par une approche basée sur les rôles. Il suffit d’ajouter au code de la politique dynamique une partie qui traite les balises relatives au cluster de base de données et qui attribue directement les droits d’accès à la politique pour ce cluster et ce groupe d’utilisateurs en particulier.
De cette manière, l’intégration d’un nouveau groupe d’utilisateurs ne sera gérée que par cette seule politique dynamique. De plus, comme elle est dynamique, la même politique peut être réutilisée pour l’intégration de nombreux groupes d’utilisateurs différents (qui suivent le même modèle, mais n’ont pas nécessairement les mêmes accès aux services).
Vous pouvez également consulter ces commandes AWS S3 pour gérer les compartiments et les données.