Modèles d'isolation pour les plateformes d'entreprise multi-tenants

Une colonne tenant_id est utile, mais ce n'est pas une stratégie d'isolation. Les requêtes traversent navigateurs, APIs, services, files d'attente, caches, stockage objet, exports et flux de travail de support. Chaque frontière a besoin d'une identité de tenant non ambiguë et d'une règle définissant ce qui peut la traverser.

Le défaut le plus sûr est de dériver le contexte de tenant de l'appartenance authentifiée et du routage côté serveur — pas d'un identifiant arbitraire accepté du client.

Les tables partagées, schémas séparés et bases de données séparées offrent des propriétés opérationnelles et d'isolation différentes. Le bon choix dépend de l'échelle, de la personnalisation, des attentes réglementaires, du risque de voisin bruyant, des exigences de sauvegarde et restauration et de la capacité opérationnelle.

Les modèles hybrides sont courants : la plupart des tenants partagent un schéma bien indexé tandis que des charges de travail sélectionnées reçoivent une séparation physique plus forte. L'application devrait masquer ce placement derrière des dépôts ou services stables.

Les noms de rôles seuls sont généralement trop larges. L'autorisation devrait considérer l'organisation, le sous-compte, la propriété de la ressource, le module activé, l'action demandée et parfois l'état de l'enregistrement.

Les helpers de politique centrale réduisent l'incohérence, mais les services de domaine doivent toujours appliquer les invariants. La sécurité au niveau des lignes de la base de données peut ajouter une défense en profondeur lorsque la gestion des connexions et du contexte est rigoureuse.

Chaque job devrait porter un contexte de tenant et d'acteur immuable, le revalider lors de l'exécution et écrire les sorties dans des emplacements définis par tenant. Les clés de cache génériques, les répertoires temporaires réutilisés et les noms de fichiers d'export non scopés peuvent contourner une autorisation API par ailleurs soigneuse.

Les tests de chemin normal prouvent qu'un utilisateur peut accéder à ses données. Les tests d'isolation prouvent que les identifiants, filtres, exports, webhooks, recherche et timing ne peuvent pas exposer les données d'un autre tenant.

Créez deux tenants dans les tests d'intégration et tentez systématiquement des lectures et mutations inter-frontières. Incluez les workers, opérations par lots, outils d'administration et chemins d'erreur — pas seulement les endpoints HTTP.