Architecture SaaS multitenant : modèles, sécurité et compromis

Une architecture SaaS multitenant permet à un fournisseur de servir plusieurs clients à partir d’un même service, tout en séparant leurs données et leurs accès. Le partage peut réduire certains coûts d’infrastructure et d’exploitation. Mais il impose de concevoir des frontières fiables entre clients et de surveiller les ressources communes.

Pour une organisation qui achète ou crée un produit SaaS, la bonne question n’est donc pas seulement « multitenant ou non ? ». Il faut déterminer ce qui sera partagé, ce qui sera dédié et comment l’isolation sera vérifiée.

Qu’appelle-t-on un tenant ?

Un tenant, ou locataire, est une unité distincte regroupant des utilisateurs, des données et des paramètres. Dans un logiciel destiné aux entreprises, il correspond souvent à un client. Une même entreprise peut toutefois souhaiter plusieurs tenants, par exemple pour ses divisions, ses régions ou ses environnements de développement. Un tenant peut compter plusieurs utilisateurs, et un utilisateur peut être autorisé à accéder à plusieurs tenants.

Cette définition influence les droits d’accès, les rapports, la localisation des données, la facturation et la sortie du service. Les recommandations de Microsoft sur les modèles de multitenance invitent à partir des besoins métier avant de choisir les ressources techniques.

Trois façons d’organiser le service

Application et base de données partagées

Tous les clients utilisent la même application et la même infrastructure de base de données. Des identifiants de tenant et des règles d’accès appliquées par le système séparent leurs informations. Ce modèle peut être économique à exploiter, mais il exige une attention particulière à l’isolation, aux charges de travail et à la restauration des données d’un seul client. Une erreur de déploiement peut aussi toucher de nombreux clients à la fois.

Application partagée, base par tenant

L’application reste commune, mais chaque tenant dispose de sa propre base. Les opérations de sauvegarde, de restauration ou de localisation peuvent être organisées plus finement. En contrepartie, il faut automatiser la création et la mise à jour des bases et diriger chaque requête vers la bonne destination. La séparation des bases ne supprime pas les risques liés aux serveurs et autres services encore partagés.

Déploiement dédié ou modèle hybride

Le fournisseur peut réserver une pile applicative à un client ou combiner des composants partagés et dédiés. Des ressources dédiées peuvent réduire certains risques d’interférence et d’accès entre clients, avec des coûts d’infrastructure et de gestion généralement plus élevés. Un modèle hybride peut, par exemple, réserver un environnement à un client ayant des exigences particulières tout en conservant une plateforme commune pour les autres. Microsoft détaille les compromis liés à l’échelle, à l’automatisation et aux attentes de service.

Isoler les tenants : les points à vérifier

Une connexion réussie ne prouve pas qu’un utilisateur ne peut accéder qu’aux ressources autorisées. Le service doit vérifier les tenants auxquels il appartient, établir un contexte fiable et l’appliquer à chaque accès concerné. AWS distingue cette isolation de l’authentification et des mécanismes généraux d’autorisation.

• Identité et droits : vérifier l’appartenance et le rôle dans le tenant sélectionné ; ne pas se fier uniquement à un identifiant transmis par le client.
• Accès aux données : appliquer les règles de tenant dans les requêtes et, lorsque c’est pertinent, dans la base. Dans PostgreSQL, la sécurité au niveau des lignes apporte une protection supplémentaire, mais certains rôles privilégiés et propriétaires de tables peuvent la contourner selon la configuration. Les tests doivent utiliser les rôles réels de l’application. Voir la documentation PostgreSQL.
• Autres composants : protéger aussi les fichiers, index de recherche, traitements en arrière-plan, exports et caches. Des clés de cache propres à chaque tenant évitent des collisions, sans remplacer les contrôles d’accès.
• Tests : automatiser les tentatives de lecture et d’écriture entre tenants, notamment après un changement de tenant, une modification de droits ou la réutilisation d’une connexion.

Ces mesures réduisent les risques, mais ne garantissent ni la sécurité ni la conformité réglementaire. Les exigences et les preuves attendues doivent être définies pour chaque produit et ses clients.

Anticiper la performance, la reprise et les coûts

Un tenant très actif peut monopoliser des ressources communes et ralentir les autres : c’est le problème du « voisin bruyant ». Il est utile de mesurer la consommation et les temps de réponse par tenant lorsque c’est possible, de tester des pics réalistes et d’envisager des quotas, des limites de débit ou une séparation des charges. Une base dédiée peut limiter la contention à ce niveau, sans éliminer les goulots d’étranglement de l’application partagée.

La reprise doit être prévue dès la conception. Une sauvegarde globale d’une base partagée ne permet pas nécessairement de restaurer simplement un seul client sans conséquence pour les autres. Définissez les objectifs de reprise, testez l’export et la restauration par tenant, et documentez la conservation et la suppression. Les recommandations de Microsoft sur les données présentent les différences entre ressources partagées et dédiées.

Pour évaluer le modèle économique, estimez les coûts d’infrastructure, de support, de supervision et de développement dans des scénarios d’utilisation normale et intensive. Le partage peut diminuer le coût par client, mais le résultat dépend du taux d’utilisation et des contrôles nécessaires. Répartissez les coûts communs de façon cohérente avant d’utiliser une estimation de rentabilité par tenant pour éclairer les prix ou une décision d’investissement.

Questions à poser à un partenaire

• Quels composants sont partagés ou dédiés, et comment chaque tenant y est-il associé ?
• Comment le contexte du tenant est-il vérifié dans les API, les bases, les fichiers et les traitements en arrière-plan ? Quels tests d’isolation peut-on examiner ?
• Comment sont gérés les limites d’utilisation, les objectifs de service, les incidents et l’information des clients ?
• Peut-on exporter, restaurer, déplacer ou supprimer les données d’un seul tenant ? Quelles opérations ont été testées ?
• Où les données et les sauvegardes peuvent-elles être stockées ? Quels fournisseurs ou sous-traitants interviennent ?
• À qui appartiennent le code et l’infrastructure ? Qui assure l’exploitation et la documentation de transfert ? Comment les changements ou la fin de la collaboration seront-ils gérés ?

Définir les frontières avant de choisir les outils

Il n’existe pas de modèle multitenant optimal pour tous les produits. Partez des besoins d’isolation et de reprise, des charges attendues et d’une estimation des coûts, puis testez l’architecture la plus simple qui y répond. En tant qu’entreprise de développement logiciel et de conseil technologique, Altweeb peut participer à cette réflexion avec le responsable du produit et ses autres partenaires.

Pour approfondir ce sujet, découvrez aussi Développement logiciel et de produits numériques.