PREUVE / Feuillet de consultation

Pentest multi-tenant : vérifier l’isolation entre clients du SaaS

Mis à jour le 1er octobre 2026

Décrire les frontières entre organisations

Un SaaS multi-tenant doit être évalué selon les frontières qu’il promet à ses clients. Décrivez comment une organisation est définie, comment un utilisateur la rejoint et comment les rôles s’y appliquent. Deux clients peuvent partager une infrastructure sans partager leurs données. Le pentest vise des scénarios précis d’isolation ; il ne permet pas de déclarer toute l’architecture sûre sans examiner les chemins et composants retenus au contrat.

Préparez plusieurs organisations fictives avec des objets distincts et quelques noms volontairement proches. Les jeux de test permettent de distinguer un résultat appartenant à une organisation d’un résultat appartenant à l’autre. Évitez de copier des données de clients réels pour rendre le test plus convaincant. Les exemples doivent rester artificiels, même lorsque la structure des objets reproduit fidèlement le modèle métier utilisé en production.

Construire une matrice de droits

Listez les rôles utilisateur, responsable d’équipe, administrateur d’organisation et support interne selon votre produit. Pour chaque rôle, notez les actions permises sur un objet de la même organisation et sur un objet extérieur. Les délégations et invitations méritent des scénarios spécifiques. Un membre de plusieurs organisations doit pouvoir changer de contexte sans conserver des droits inappropriés issus de sa session précédente.

Le CTO fournit la logique attendue ; le cabinet recherche les écarts observables dans le périmètre autorisé. Ne laissez pas la matrice être déduite seulement de l’interface. Un bouton absent n’est pas une preuve d’interdiction côté serveur. Les vérifications peuvent concerner les API, les fonctions de recherche, les fichiers et les exports. Les limites exactes sont convenues avant mission, en particulier pour les comptes d’administration globale.

Examiner les chemins indirects

L’isolation ne se réduit pas à l’affichage du tableau de bord. Un fichier stocké, un aperçu, une notification, un index de recherche ou un traitement asynchrone peut transporter le contexte de l’organisation. Décrivez ces mécanismes dans la consultation. Le cabinet doit comprendre quels chemins relèvent du même contrôle d’accès et quels chemins demandent des scénarios distincts. Une API oubliée peut invalider la portée commerciale d’une conclusion limitée à l’interface.

Préparez aussi les transitions : départ d’un membre, changement de rôle, suppression d’organisation et révocation d’un partage. Certaines actions peuvent avoir une propagation différée. Indiquez le comportement attendu et les limites convenues du test. Les données fictives doivent rester disponibles assez longtemps pour que le cabinet vérifie les effets après traitement, puis être supprimées selon la procédure définie avec vos équipes.

Protéger les clients pendant l’audit

Un test d’isolation ne donne aucune autorisation de consulter des données réelles d’un client. Prévoyez une procédure d’arrêt si une information inattendue apparaît. Le cabinet doit savoir qui contacter et comment conserver une preuve minimale sans multiplier les copies. Les règles d’engagement doivent encadrer les opérations d’export ou de suppression. Le plan de test est adapté au risque d’impact, surtout lorsque l’environnement est partagé avec des utilisateurs réels.

Sur une préproduction, documentez les différences avec la production : stockage, cache, services de recherche, rôles et configuration d’accès. Une bonne isolation dans un environnement simplifié ne démontre pas celle d’un environnement différent. Le rapport doit indiquer ces limites. Si une vérification en production est nécessaire, elle exige un cadrage spécifique et des comptes dédiés, avec supervision et conditions d’arrêt.

Relier les résultats à la vente

L’acheteur doit comprendre quelles organisations et quels rôles ont été utilisés, sans recevoir leurs secrets. Une synthèse peut décrire les scénarios de séparation testés et l’état des corrections. Demandez que le rapport distingue un contrôle vérifié d’un chemin exclu. La mention « multi-tenant » dans un titre ne suffit pas à démontrer que les fonctions essentielles à votre client ont réellement été examinées.

Après un constat, recherchez sa cause dans le contrôle partagé plutôt que de corriger seulement une URL. Le retest ciblé doit reprendre les chemins pertinents convenus avec le cabinet. Le commercial peut alors transmettre une version expurgée cohérente avec le résultat technique. Toute nouvelle fonction de partage, de délégation ou de support introduite après l’audit doit être considérée dans l’analyse des changements et dans la décision de refaire des tests.