Architecture multi-locataire

L'architecture multi-locataire (multi-tenancy) est une architecture dans laquelle une seule plateforme partagée sert plusieurs locataires indépendants — des clients, des unités métier ou des applications distinctes — chaque locataire étant isolé logiquement de sorte qu'aucun ne puisse voir ni affecter les autres. Les locataires partagent le même matériel et le même logiciel sous-jacents, mais chacun se comporte comme s'il disposait de son propre système privé.

Tout l'intérêt est d'y parvenir à la fois de façon sûre et efficace : une seule plateforme à acheter, exploiter et faire évoluer (plutôt qu'un silo distinct par locataire), associée à un isolement strict des données, de l'identité et de l'espace de noms de chaque locataire. C'est l'architecture multi-locataire qui permet à un fournisseur de services d'héberger des centaines de clients sur une infrastructure partagée, ou à une entreprise de séparer proprement ses départements, sans que les données de l'un ne fuient vers celles d'un autre.

Ce que signifie l'architecture multi-locataire

Un locataire (tenant) est un ensemble d'utilisateurs et de ressources qui vont de pair et doivent rester séparés des autres : généralement un client, un département ou un environnement applicatif. L'architecture multi-locataire isole chaque locataire selon plusieurs dimensions à la fois :

• Données et espace de noms. Chaque locataire dispose de ses propres buckets et de son propre espace de noms d'objets. Deux locataires peuvent même utiliser les mêmes noms d'objet ou de bucket sans collision.
• Identité et accès. Chaque locataire possède ses propres comptes, utilisateurs et identifiants ; les clés d'un locataire ne donnent aucun accès aux données d'un autre.
• Capacité et performance. Des quotas et des contrôles empêchent un locataire d'épuiser le pool partagé ou de priver les autres de débit (le problème du « voisin bruyant »).
• Administration. Le périmètre d'administration est borné, de sorte que l'administrateur d'un locataire ne gère que le sien.

Partagé en dessous, isolé au-dessus : cette combinaison est la caractéristique déterminante d'un système multi-locataire.

Multi-locataire ou mono-locataire

L'alternative à l'architecture multi-locataire est l'architecture mono-locataire, où chaque locataire reçoit sa propre instance dédiée de la plateforme.

• Mono-locataire (dédié). Isolement et personnalisation maximaux, et le plus petit rayon d'impact en cas de problème, mais un coût plus élevé, davantage de matériel et davantage d'instances à exploiter et à corriger.
• Multi-locataire (partagé). Une efficacité et une densité bien supérieures : une seule plateforme sert tout le monde, la capacité est mutualisée et l'exploitation est centralisée. En contrepartie, l'isolement doit être assuré par logiciel plutôt que par séparation physique.

La plupart des services de stockage et de cloud à grande échelle sont multi-locataires parce que l'efficacité est décisive ; l'effort d'ingénierie consiste alors à rendre l'isolement logique aussi solide que l'aurait été une séparation physique.

Comment l'isolement est assuré

Dans le stockage objet, l'isolement des locataires repose principalement sur des contrôles d'identité et d'espace de noms :

• Comptes et IAM. Chaque locataire correspond à son propre compte, avec ses propres utilisateurs, groupes, rôles et politiques qui régissent précisément ce que chaque identité peut faire.
• Espaces de noms et identifiants distincts. Les buckets et les clés d'accès sont limités au locataire, de sorte que les requêtes sont authentifiées et autorisées uniquement pour ce locataire.
• Quotas et QoS. Les limites de capacité et les contrôles de débit contiennent l'effet du voisin bruyant et empêchent un locataire de consommer tout le pool.
• Chiffrement par locataire. Des clés distinctes — souvent des clés gérées par le client — garantissent que même des supports de stockage partagés ne révèlent rien d'exploitable au-delà des frontières entre locataires.
• Réseau et audit. Des points d'accès segmentés et une journalisation par locataire complètent la séparation et assurent la traçabilité.

Qui utilise l'architecture multi-locataire, et pourquoi

L'architecture multi-locataire est la norme pour quiconque sert de nombreux consommateurs depuis une infrastructure partagée :

• Les fournisseurs de services proposant du stockage as a service ou de la sauvegarde as a service hébergent de nombreux clients sur une seule plateforme, avec mesure et refacturation par locataire.
• Les entreprises séparent départements, filiales ou projets sur un système unique tout en gardant distincts les données et les accès de chacun.
• Les équipes SaaS et plateforme attribuent à chaque client ou environnement une tranche isolée d'un backend commun.

Les avantages sont l'efficacité, la densité et une exploitation plus simple ; les risques à gérer sont la fuite de données entre locataires, l'effet du voisin bruyant et un rayon d'impact plus large, que les contrôles d'isolement ci-dessus servent précisément à contenir.

L'architecture multi-locataire et ARTESCA

ARTESCA est conçu pour une architecture multi-locataire sécurisée grâce à un modèle IAM compatible AWS. La documentation de Scality décrit ce modèle comme garantissant « une sécurité forte et une compatibilité applicative avec le multi-tenant pour les offres de sauvegarde as a service ».

En pratique, chaque locataire est représenté par ses propres comptes, avec des utilisateurs, des groupes, des rôles et des politiques qui contrôlent l'accès ; les buckets, les espaces de noms et les identifiants sont limités à chaque locataire, de sorte que deux locataires peuvent partager le même pool et les mêmes points d'accès S3 tout en restant totalement invisibles l'un pour l'autre. Les identités peuvent être locales à ARTESCA ou fédérées depuis un annuaire AD/LDAP existant, les rôles d'administrateur délimitent ce que chaque administrateur peut gérer, et l'authentification multifacteur peut être imposée. Associé à des clés gérées par le client par locataire, cela permet à un fournisseur ou à une entreprise de regrouper de nombreux locataires sur une seule plateforme sans compromettre l'isolement ni la souveraineté des données.

FAQ sur l'architecture multi-locataire

Quelle est la différence entre multi-locataire et mono-locataire ?

Dans un système mono-locataire, chaque locataire reçoit sa propre instance dédiée. Dans un système multi-locataire, de nombreux locataires partagent une instance mais sont isolés logiquement. Le multi-locataire est plus efficace ; le mono-locataire offre la séparation physique la plus forte.

Les locataires peuvent-ils voir les données des autres dans un système multi-locataire ?

Non : c'est tout l'objectif. L'isolement des comptes, des espaces de noms et des identifiants fait que chaque locataire ne peut accéder qu'à ses propres données, même si la plateforme sous-jacente est partagée.

Qu'est-ce qu'un « voisin bruyant » ?

Un voisin bruyant est un locataire dont l'usage intensif dégrade les performances ou consomme la capacité dont les autres ont besoin. Les quotas et les contrôles de qualité de service servent à contenir cet effet.

Comment un locataire est-il isolé dans le stockage objet ?

Principalement grâce aux comptes et à l'IAM : chaque locataire possède son propre compte, ses utilisateurs, ses rôles et ses politiques, ainsi que des buckets et des identifiants distincts et, souvent, ses propres clés de chiffrement.

ARTESCA prend-il en charge le multi-locataire ?

Oui. ARTESCA offre un multi-locataire sécurisé grâce à un modèle IAM compatible AWS de comptes, d'utilisateurs, de groupes, de rôles et de politiques, conçu pour la sauvegarde as a service et les déploiements multi-départements.