Construire une plateforme SaaS multi-tenant sécurisée pour les entreprises algériennes

Multi-tenant ne veut pas dire base partagée

Le multi-tenant est un modèle dans lequel une plateforme sert plusieurs organisations clientes avec une expérience et une exploitation communes. Les ressources peuvent être partagées, séparées ou combinées. Le critère déterminant est qu’un tenant ne puisse ni voir, ni modifier, ni perturber les ressources d’un autre tenant.

AWS distingue l’authentification et l’autorisation fonctionnelle de l’isolation tenant. Un utilisateur peut être correctement connecté et autorisé à consulter des commandes, mais accéder aux commandes d’une autre entreprise si le contexte tenant n’est pas imposé. L’isolation est donc un contrôle supplémentaire et transversal.

Choisir un modèle d’isolation

La décision peut varier par ressource. Une plateforme peut partager le calcul, séparer les bases des tenants sensibles et isoler les fichiers par préfixes et politiques. Le niveau choisi doit répondre aux exigences contractuelles, au volume, au risque de voisin bruyant, aux sauvegardes et au modèle commercial.

Établir le contexte tenant une seule fois, puis le propager

Le contexte doit être établi au début de la requête à partir du domaine, de l’organisation liée à la session ou d’un jeton signé. Une valeur tenant_id envoyée par le navigateur ne doit jamais être considérée comme fiable sans validation contre l’identité et les autorisations.

Propagez le contexte vers les services, requêtes, événements et journaux avec une convention contrôlée. Les tâches asynchrones doivent transporter un contexte signé ou retrouver le tenant depuis une référence interne. Les opérations d’administration globale nécessitent un chemin séparé, explicite et audité.

Appliquer la frontière à chaque couche

• Base: imposer tenant_id dans les clés, contraintes, politiques ou connexions, avec défense en profondeur.
• API: vérifier la propriété tenant de chaque ressource, y compris les exports et recherches globales.
• Fichiers: séparer préfixes, autorisations, liens signés et processus de suppression.
• Cache: inclure le tenant dans chaque clé et éviter les résultats partagés sans contrôle.
• Files: transporter le contexte et empêcher un worker de mélanger les messages.
• Recherche: filtrer avant la récupération, y compris dans les index vectoriels.
• Journaux: conserver le contexte pour l’audit sans exposer de données sensibles.
• Sauvegardes: définir restauration, export, rétention et suppression par tenant.

Le support est une surface d’accès privilégiée

Les outils d’impersonation ou de support peuvent contourner les frontières ordinaires. Limitez-les à des rôles dédiés, imposez une justification, une durée courte, une approbation selon le risque et un journal consultable. Ne demandez jamais les mots de passe du client.

Les exports de diagnostic, captures et copies de bases doivent respecter la même classification. Un environnement de test ne doit pas recevoir des données de production par défaut. Les équipes de support ont besoin de vues minimales et de procédures de purge.

Protéger aussi la disponibilité entre tenants

L’isolation concerne la confidentialité, mais aussi la capacité. Un tenant peut saturer une file, une API, une base ou un traitement et dégrader tous les autres. Appliquez quotas, limites, files séparées ou priorités selon le niveau de service. Mesurez l’usage par tenant et alertez sur les écarts.

La limite ne doit pas seulement retourner une erreur. Elle doit expliquer l’état, permettre une reprise et protéger les opérations essentielles. Les tâches lourdes peuvent être asynchrones et isolées du trafic interactif.

Tester la frontière comme une propriété du système

• Créer deux tenants avec données distinctes et tenter chaque lecture ou modification croisée.
• Tester les identifiants devinables, filtres omis, exports, recherches et endpoints administratifs.
• Vérifier les collisions de cache, fichiers, files et identifiants externes.
• Répéter après changements de requête, migration, optimisation de cache ou nouveau service.
• Alerter sur toute tentative d’accès croisé et conserver une preuve sans données sensibles.

Exemple anonymisé: plateforme wholesale multi-marques

Une plateforme B2B sert plusieurs marques. Les produits, prix et clients portent un tenant_id, mais le cache du catalogue utilise seulement l’identifiant produit. Deux tenants peuvent employer la même référence et recevoir un résultat incorrect malgré des requêtes SQL filtrées.

La correction ajoute le tenant à toutes les clés de cache, centralise le contexte, renforce les contraintes, sépare les fichiers et crée une suite de tests croisés. Le risque montre pourquoi l’isolation doit être évaluée au-delà de la base principale.