L’isolation des tenants SaaS signifie qu’un client ne peut accéder qu’aux fiches et opérations que son organisation a le droit d’utiliser. Un sélecteur de tenant dans l’interface ne suffit pas. La frontière doit tenir lorsque les requêtes, tâches de fond, caches et téléchargements de fichiers atteignent les systèmes sous-jacents.
Testez l’isolation avec des organisations distinctes, des rôles utilisateurs ordinaires et des tentatives délibérées de franchir leurs frontières. Vérifiez lectures, écritures, fichiers, réponses en cache et traitements de fond selon les mêmes règles d’accès. Demandez des preuves issues de la frontière backend effectivement appliquée avant d’accueillir des clients aux données sensibles ou commercialement importantes.
Imaginez un portail client où chaque organisation voit ses propres bons de commande. La liste paraît correcte, mais un export téléchargé contient les lignes d’une autre organisation. C’est un échec d’isolation, même si la connexion et le chemin ordinaire de la page fonctionnent comme prévu.
Ce guide aide un responsable à définir la vérification et la correction. Il n’affirme pas qu’une organisation de base de données garantit la sécurité ni qu’une liste de contrôle remplace une analyse applicative complète.
Définir l’isolation des tenants SaaS avant le stockage
Identifiez ce que représente un tenant dans le produit : organisation cliente, entité juridique ou espace de travail. Consignez comment les utilisateurs rejoignent, quittent et changent de tenant, et quels rôles de support peuvent agir entre eux. Des règles ambiguës rendent les tests ambigus.
Le guide OWASP de sécurité multi-tenant décrit l’isolation aux frontières de base, cache, stockage et calcul. Il distingue aussi le sélecteur fourni par le client des droits vérifiés par le serveur. Utilisez cette distinction pour examiner le véritable chemin de requête du produit.
Définissez explicitement la propriété des données. Un catalogue partagé peut être volontairement visible par plusieurs clients, tandis que les notes de commande appartiennent à un tenant. Les tests doivent connaître cette différence pour détecter les fuites sans classer les informations délibérément partagées comme défauts.
Cartographiez l’exception administrative. Si le support peut consulter les fiches d’un client, expliquez qui accorde l’accès, comment il est limité et comment son usage est consigné. Un chemin de support puissant doit être testé comme capacité intentionnelle, pas dissimulé hors du modèle ordinaire de tenant.
Suivre le contexte du tenant dans la requête
Partez d’un utilisateur authentifié et vérifiez son appartenance actuelle ou les droits du service. Suivez le tenant choisi dans la logique métier et l’accès aux données. Vérifiez qu’un changement d’en-tête, de valeur de route ou de corps de requête ne peut pas substituer les droits d’une autre organisation.
Des identifiants d’apparence aléatoire peuvent compliquer la devinette, mais n’établissent aucune permission. Le guide d’autorisation d’OWASP recommande de contrôler l’accès à chaque requête. Testez un identifiant obtenu légitimement d’un autre tenant plutôt que de compter sur la capacité du testeur à le deviner.
| Frontière | Tentative illustrative | Résultat accepté |
|---|---|---|
| Consultation de fiche | Demander l’identifiant connu d’une commande d’un autre tenant | Refus sans divulgation de fiche |
| Modification | Soumettre l’identifiant d’un autre tenant dans une charge valide | Aucune modification non autorisée |
| Changement de tenant | Choisir une organisation sans en être membre | Le serveur rejette le périmètre demandé |
| Point d’accès par lot | Inclure des identifiants de plusieurs tenants | Rejet défini sans fuite partielle |
| Action de support | Employer un rôle ordinaire sur une route privilégiée | Refus et preuves utiles d’investigation |
Répétez ce raisonnement pour recherches, exports et API alternatives. Le premier écran de détail correct ne prouve pas qu’un rapport par lot, un point d’accès mobile ou une ancienne route de compatibilité applique la même frontière.
Comparer les bases selon leurs contrôles réels
Bases distinctes, schémas distincts et tables partagées impliquent différents compromis opérationnels. Aucun ne supprime la nécessité de vérifier identifiants, rôles, requêtes et chemins administratifs. La proposition doit identifier où la frontière est appliquée et ce qui arriverait si le code applicatif omettait un filtre.
| Approche | Frontière à examiner | Travail opérationnel à inclure |
|---|---|---|
| Bases distinctes | Droits des connexions et identifiants | Provisionnement, migrations et séparation des sauvegardes |
| Schémas distincts | Rôles de base et choix d’espace de noms | Droits, discipline de migration et accès administratif |
| Tables partagées | Propriété du tenant et politiques d’accès appliquées | Couverture des requêtes, rôles et tests négatifs |
| Hybride | Règle documentée par classe de données | Routage clair et investigation cohérente des incidents |
Ne considérez pas une migration vers des bases séparées comme la correction par défaut de tout défaut. Un bogue d’autorisation limité peut être corrigé précisément. À l’inverse, ajouter un filtre dans un contrôleur ne suffit pas si exports, tâches et outils de support gardent un accès illimité.
Tester le rôle réellement utilisé en production
La documentation PostgreSQL sur la sécurité des lignes explique des exceptions importantes, dont les rôles privilégiés et la propriété des tables. Si le produit dépend de politiques de lignes, vérifiez-les avec le véritable rôle de requête restreint. Un test exécuté comme administrateur de base ne représente pas la frontière de l’application ordinaire.
Incluez les comptes de déploiement et de migration dans l’inventaire. Ils peuvent légitimement exiger un accès plus large, mais ne doivent pas devenir l’identité habituelle des requêtes clientes. Documentez comment l’exécution obtient les droits prévus et comment ce dispositif est vérifié après déploiement.
Vérifier caches, fichiers et résultats dérivés
Examinez les clés de cache et le périmètre des résultats mémorisés. Une entrée créée pour une organisation ne doit pas devenir une réponse pour une autre parce que les deux requêtes partagent une route ou un filtre pratique. Testez le second tenant après que le premier a rempli le cache.
Les fichiers exigent leurs propres preuves d’acceptation. Vérifiez la propriété des envois, l’accès aux aperçus, les téléchargements et rapports générés. Une page peut refuser correctement l’accès alors qu’une URL de pièce jointe reste disponible par une autre route. Incluez les liens périmés et déjà émis dans le périmètre convenu.
Vérifiez les données dérivées : index de recherche, recommandations et exports analytiques. Établissez si les restrictions du tenant sont appliquées à la récupération et pas seulement à l’insertion. Une synthèse peut franchir la frontière même lorsque le point d’accès à la fiche source est protégé.
Utilisez des données de test contrôlées appartenant à des organisations distinctes. Donnez-leur assez de contenu reconnaissable pour identifier une contamination sans copier de vrais documents clients dans l’analyse. Un résultat de cache inattendu ou un export mélangé devient plus facile à diagnostiquer.
Exercer les tâches de fond et changements d’appartenance
Le travail de fond doit transporter le contexte vérifié du tenant à travers la file jusqu’à l’opération. Vérifiez ce qui se passe si une tâche est retardée, relancée ou reprise par un autre worker. Un périmètre valide dans la requête web ne prouve pas sa préservation dans la tâche ultérieure.
Testez les changements d’appartenance. Un utilisateur retiré d’une organisation ne doit pas garder son accès ordinaire par une session en cache, un export sauvegardé ou une opération en attente contrairement à la politique convenue. Définissez le comportement du travail déjà accepté avant révocation.
L’usurpation de session par le support et la suppression du tenant méritent aussi une couverture délibérée. Expliquez comment les opérateurs quittent une session privilégiée et comment fichiers résiduels, tâches et références sont traités. La bonne politique de suppression dépend des obligations de conservation du produit ; l’analyse doit vérifier la politique choisie, pas en inventer une.
Notre guide de reprise de projet logiciel est pertinent si l’équipe actuelle ne peut pas expliquer ces chemins. Reprendre la maîtrise du déploiement, de l’accès aux données et de la documentation opérationnelle peut contribuer à rendre la frontière maintenable.
Définir un rapport de vérification utile
Demandez des constats montrant l’acteur, le tenant, l’opération et l’effet observé. Incluez les preuves de requête et de destination pertinentes en contrôlant les valeurs sensibles. Un constat intitulé contrôle d’accès sans chemin reproductible est difficile à corriger et à retester.
OWASP ASVS peut soutenir les exigences plus larges de sécurité applicative. Conservez la matrice d’acceptation propre aux tenants à côté de ce travail pour que le réviseur voie les organisations, rôles et types de ressources exercés.
Séparez les défauts confirmés des chemins non testés. Si l’évaluateur n’a pas pu examiner un stockage privé ou un export administratif, dites-le. Une limite de périmètre honnête est plus utile qu’une conclusion infondée affirmant que toutes les données des tenants sont isolées.
Après correction, répétez le cas initialement défaillant et les cas légitimes voisins. Une réparation bloquant tous les téléchargements peut arrêter la fuite mais casser le produit. L’acceptation exige le refus des accès non autorisés et la poursuite du travail client permis.
Budgéter la véritable frontière du produit
Définissez l’analyse selon les types de ressources, rôles et chemins opérationnels, pas seulement le nombre de pages. Incluez fichiers externes, caches, tâches de fond et support lorsqu’ils peuvent exposer des informations du tenant. Un petit portail peut avoir une frontière plus large que son interface ne le suggère.
| Lot de travail | Livrable | Hypothèse à clarifier |
|---|---|---|
| Cartographie de frontière | Modèle des tenants et rôles | Disponibilité des connaissances d’architecture |
| Vérification | Preuves d’accès positives et négatives | Comptes et environnements contrôlés |
| Correction | Application corrigée et contrôles de régression | Besoin éventuel de changements structurels |
| Transmission | Tests reproductibles et exclusions connues | Responsabilité après l’accueil client |
Demandez des propositions en GBP distinguant analyse et correction. N’acceptez pas une assurance universelle fondée uniquement sur un test de connexion ou un scan automatique. Le livrable précieux est la preuve des frontières d’accès dont dépendront vos clients.
Notre service de sécurité applicative offre un point de départ à ce périmètre. Envoyez-nous le modèle des tenants et la décision d’accueil client pour discuter des vérifications, corrections ciblées et preuves nécessaires avant l’ouverture du prochain compte client.
Questions fréquentes
Qu’est-ce que l’isolation des tenants SaaS ? Il s’agit de la séparation effectivement appliquée des données et opérations autorisées des organisations clientes. La frontière doit tenir dans les requêtes applicatives, le stockage, les caches, les fichiers et le travail de fond, y compris les exceptions administratives définies par le produit.
Des bases distinctes garantissent-elles l’isolation ? Non. Identifiants, routage, outils de support, exports et sauvegardes peuvent encore franchir les frontières. Des bases séparées peuvent participer à la conception, mais les chemins réels d’accès doivent être testés.
Des identifiants aléatoires suffisent-ils ? Non. Ils peuvent réduire l’énumération facile mais ne sont pas des contrôles de permissions. Testez l’accès avec un véritable identifiant d’un autre tenant contrôlé et confirmez le refus du serveur.
Faut-il tester les accès autorisés autant que les refus ? Oui. Une correction refusant toute requête peut dissimuler un produit cassé. Vérifiez que les utilisateurs ordinaires gardent les opérations prévues tandis que les tentatives entre tenants sont rejetées.
Pourquoi les caches exigent-ils des tests séparés ? Ils peuvent renvoyer des données sans répéter le chemin d’accès initial. Remplissez un cache sous un tenant et examinez le résultat sous un autre. Confirmez que son périmètre préserve les droits prévus au lieu de partager simplement une clé pratique.
Comment l’accès du support doit-il fonctionner ? Définissez qui peut l’obtenir, son périmètre, sa durée et l’enregistrement des actions. Testez l’entrée, l’utilisation et la sortie de ce contexte privilégié. La conception doit rendre l’exception explicite et vérifiable.
Et si nous utilisons la sécurité au niveau des lignes ? Testez-la avec le véritable rôle de requête applicative et incluez les opérations contournant les contrôleurs ordinaires. Les rôles privilégiés de base et les autres chemins d’accès peuvent avoir des comportements différents. Les politiques de lignes sont un contrôle à vérifier, pas une raison d’omettre l’analyse.
Que transmettre au prestataire avant le devis ? Une description des tenants et rôles, des types de ressources, du stockage externe et des opérations de fond. Identifiez les environnements et comptes contrôlés disponibles pour les tests, ainsi que la décision à soutenir.