Un logiciel SaaS multi entreprise doit appliquer l’identifiant du client à chaque lecture et écriture, puis vérifier cette séparation avec des tests ciblés.
Dans une application destinée à plusieurs entreprises, les utilisateurs partagent le même service mais leurs dossiers doivent rester séparés. Une erreur de filtre peut afficher un client dans la recherche d’un autre. La sécurité dépend donc de règles répétées à chaque couche, depuis la session jusqu’à la base de données.
L’isolation commence par une décision d’architecture. Toutes les entreprises peuvent partager les mêmes tables avec une colonne d’appartenance. Elles peuvent aussi utiliser des schémas ou des bases distinctes. Chaque modèle a un coût de déploiement, de sauvegarde et de maintenance. Le niveau retenu doit correspondre au risque et aux capacités de l’équipe.
Définir l’entreprise courante
La session doit associer l’utilisateur à une ou plusieurs entreprises autorisées. Ne déduisez pas cette information d’un identifiant envoyé seul par le navigateur. Le serveur doit contrôler que l’utilisateur possède bien l’accès à l’entreprise demandée et à la ressource ouverte.
Pour chaque requête, établissez le contexte avant de charger des données. Une fonction de service peut recevoir un objet de contexte contenant l’utilisateur, l’entreprise et ses droits. Les opérations sensibles utilisent ensuite ce contexte au lieu de faire confiance à une valeur fournie par l’écran.
Les changements d’entreprise doivent être visibles pour l’utilisateur. Affichez le nom et l’identifiant de l’espace actif, surtout lorsqu’une personne travaille avec plusieurs comptes. Évitez les actions irréversibles immédiatement après un simple changement de contexte, et demandez une confirmation lorsque le risque le justifie.
Appliquer le filtre partout
Chaque table appartenant à une entreprise doit posséder un lien explicite vers celle-ci ou vers un objet qui en dépend. Les requêtes de lecture, de modification et de suppression doivent inclure cette relation. Une route qui charge un enregistrement par son identifiant doit ajouter le contrôle d’appartenance avant de le retourner.
Les recherches, exports, rapports et tâches en arrière-plan sont des sources fréquentes d’oubli. Un export doit recevoir le même contexte qu’un écran. Une tâche planifiée doit conserver l’entreprise concernée dans son message. Un cache doit inclure cet identifiant dans sa clé pour éviter de partager une réponse entre espaces.
Les données communes demandent une règle différente. Un catalogue global peut être visible par plusieurs entreprises, alors qu’un prix négocié reste privé. Documentez le propriétaire de chaque champ et testez les exceptions. Une condition « global ou entreprise courante » mérite une fonction claire, car elle est facile à réécrire de travers.
Choisir le niveau d’isolation
Le partage de tables simplifie les migrations et la supervision, mais une erreur de requête peut avoir un impact large. Des politiques de sécurité au niveau de la base peuvent ajouter un contrôle, selon le moteur et le modèle retenu. Elles ne dispensent pas de vérifier les droits dans l’application.
Un schéma par entreprise réduit certaines interactions, mais augmente le nombre d’objets à migrer et à sauvegarder. Une base par entreprise renforce la séparation et facilite parfois une restauration ciblée. Elle impose en revanche une gestion des connexions, des coûts et des versions plus lourde.
Avant de décider, estimez le nombre d’entreprises, le volume par espace, les exigences de restauration et les opérations d’administration. Une PME peut commencer avec des tables partagées bien contrôlées et prévoir une stratégie d’extraction pour les clients qui auront des contraintes particulières.
Tester les accès croisés
Les tests doivent utiliser au moins deux entreprises fictives avec des données qui se ressemblent. Connectez un utilisateur de la première entreprise et vérifiez les listes, recherches, détails, exports, fichiers et notifications. Tentez ensuite d’utiliser directement l’identifiant d’un enregistrement de la seconde entreprise.
Testez aussi les changements de rôle, les utilisateurs membres de plusieurs entreprises, les tâches asynchrones et les caches. Une protection qui fonctionne sur l’écran peut manquer dans une route d’administration ou un traitement nocturne.
Les erreurs doivent rester neutres. Une réponse différente entre « ressource inexistante » et « ressource d’un autre client » peut révéler qu’un identifiant existe. Le choix dépend du parcours et du niveau d’information que vous acceptez d’exposer. Documentez la réponse prévue et vérifiez qu’elle ne laisse pas de données dans les logs.
Préparer l’exploitation et la maintenance
Les comptes d’administration ont besoin d’un accès contrôlé et journalisé. Un support peut devoir agir sur un espace client, mais l’accès doit être limité dans le temps et associé à une raison. Le journal d’audit aide à retracer ces interventions.
Les sauvegardes doivent respecter la même séparation que la production. Testez une restauration avec un seul espace et vérifiez qu’elle ne réintroduit pas des données d’un autre client. Définissez aussi la procédure de suppression, d’export et de changement de formule selon les engagements de l’entreprise.
Une architecture multi entreprise se juge dans les détails opérationnels. Le contexte doit traverser les services, les fichiers, les recherches et les traitements différés. Des données de test volontairement proches des données d’un autre client permettent de détecter les filtres oubliés avant la mise en service.
Sources : OWASP, contrôle d’accès, Microsoft, architecture SaaS multi locataire, PostgreSQL, sécurité au niveau des lignes.