Le stockage objet Amazon S3 offre un service simple, peu coûteux et hautement scalable. Requêtable au travers de la console, via la CLI, en utilisant un SDK ou directement par les API publiques de AWS, ce service de plus de 15 ans fait toujours partie des services phares d’AWS.
Son intégration dans les processus métier peut impliquer la nécessité pour des collaborateurs non techniques (comprendre, qui ne font pas partie du service informatique), d’accéder aux fichiers contenus dans les buckets pour pouvoir les lire, les déplacer ou en ajouter de nouveaux.
Pour fournir un accès web à vos fichiers stockés sur Amazon S3, vous disposez des options suivantes :
- Utiliser la console AWS : mais ce n’est pas très user-friendly pour les non-initiés.
- Utiliser un client lourd type WinSCP ou S3Browser : mais vous devrez fournir des clés d’API Access Key ID et Secret Access Key (AK/SK) à vos collaborateurs, ce qui n’est pas optimal d’un point de vue cybersécurité.
- Exposer votre stockage en tant que site web avec une authentification edge sur CloudFront par exemple. Mais là encore ce n’est pas très user-friendly si vous devez exposer de nombreux buckets S3.
Sinon, vous avez aussi l’option YarkonS3. YarkonS3 est un outil clientless que vous pouvez consommer en tant que service SaaS ou en auto-hébergé, qui vous permet d'accéder à vos buckets S3.
On y retrouve un affichage familier semblable à la plupart des explorateurs de fichier avec quelques fonctionnalités issues de S3 comme :
- Le support du versioning et du chiffrement KMS
- La gestion des fichiers au niveau type de stockage (Standard, Infrequent Access, Glacier…), la personnalisation des permissions ACL du fichier, l’édition des metadata et du content-type de chaque objet.
- Partager des documents par l’intermédiaire d’URL pré-signés
- L’administration des buckets S3 avec création et suppression de bucket, personnalisation des permissions et activation des fonctionnalités de logging, website et du versioning.
Avantage supplémentaire si vous optez pour un auto-hébergement, vous pourrez tirer parti de la fédération des identités.
Si vous optez pour la version SaaS, il vous suffira de fournir une AK/SK avec les permissions nécessaires sur vos buckets S3, de créer vos utilisateurs dans l’interface d’administration et de configurer les CORS de vos buckets pour autoriser les requêtes provenant du domaine de YarkonS3.
Si vous choisissez l’option de l’auto-hébergement, il y a évidemment un peu plus de charge pour la mise en place et vous allez devoir choisir en une version Docker ou Server (sous-entendu, une VM) qui est directement disponible dans la Marketplace d’AWS.
Dans les deux cas, il est préférable d’externaliser la base de données pour des questions de durabilité, de maintenance et de scalabilité. YarkonS3 est compatible avec les bases de données MySQL, MariaDB, SQLite, PostgreSQL et MSSQL que vous pouvez héberger sur une instance RDS.
Une fois l’architecture de votre implémentation entérinée, il va falloir vous poser la question de la méthode d’attribution des droits aux utilisateurs sur les différents buckets. Pour cela, YarkonS3 propose trois Security Models :
- Shared : Tous les utilisateurs de la plateforme ont les mêmes droits (ceux accordés à l’instance EC2 ou la tâche fargate).
- Federated : Les utilisateurs ont différents droits basés sur un utilisateur AWS IAM qui leur est propre.
- Integrated : Les utilisateurs ont différents droits basés sur un rôle AWS IAM qui leur est propre.
Généralement, Federated et Integrated sont les meilleures options. Si vous intégrez YarkonS3 à votre gestion centralisée des identités, vous allez pouvoir fournir à vos utilisateurs une authentification SSO via SAML. Ainsi, vous n’aurez pas à gérer les utilisateurs directement dans YarkonS3 mais depuis votre Identity Provider (IDP) et vous pourrez même passer dans la réponse SAML le nom de l’utilisateur, du groupe ou du rôle IAM à utiliser pour l’affectation de droits (Cf. mode Pass Through).
Gain de sécurité supplémentaire, si vous exposez votre service YarkonS3 auto-hébergé sur internet, vous pouvez sécuriser l’accès en pré authentifiant les utilisateurs au niveau du load balancer applicatif (ALB) via une règle d’authentification OIDC par exemple.
Cela nous donnerait une implémentation semblable à celle-ci :
Résumé
Pour faire simple :
Quand avez-vous besoin d’un outil comme YarkonS3 ?
Quand vous devez permettre à des utilisateurs l’accès à des fichiers stockés dans S3 sans passer par la console AWS ou un outil utilisant des AK/SK.
YarkonS3 version SaaS ou auto-hébergé ?
SaaS :
- Simplicité d’utilisation
- Pas de maintenance
- Utilisation d’une AK/SK pour lier YarkonS3 à votre compte AWS
- Gestion des utilisateurs dans YarkonS3 sans SSO
- Possibilité d’attribuer des droits différents par utilisateurs
Auto-hébergement :
- Plus complexe à mettre en place
- Maintenance d’infrastructure et applicative à prévoir
- Utilisation d’identités AWS IAM pour l’attribution des droits
- Gestion des utilisateurs dans YarkonS3 ou IDP externe avec SSO
- Nom de domaine customisé et support des API
YarkonS3 est-il intégrable à mes outils de gestion des identités ?
En version auto-hébergée, oui. Vous pouvez intégrer YarkonS3 avec votre IDP et votre IGA pour fournir au travers de la réponse SAML les informations d’authentification et d’autorisation nécessaires à l’attribution des permissions sur les buckets S3.
Références
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html
Timothée participe activement au programme d’innovation
Merci pour votre lecture. Si cet article vous a plu, merci de le partager sur vos réseaux 😉
Timothée Taron - Janvier, 2023
VOUS AVEZ UN PROJET ?
Audit, migration, infogérance ?
Skale-5 vous écoute : contact@skale-5.com
Nous suivre :
