Comment tester l’isolation des tenants dans les exports de données SaaS ?
L’isolation des tenants ne consiste pas seulement à filtrer l’affichage par client. La requête d’export, la tâche en arrière-plan, le stockage du fichier et le lien de téléchargement doivent…
Que contient cet article ?
Réponse courte
L’isolation des tenants ne consiste pas seulement à filtrer l’affichage par client. La requête d’export, la tâche en arrière-plan, le stockage du fichier et le lien de téléchargement doivent appliquer les mêmes autorisations pour le client concerné. Les tests doivent aussi vérifier que l’identifiant du rapport d’un client ne permet pas d’accéder au fichier d’un autre.
L’isolation doit continuer dans la file des rapports
Ne considérez pas le paramètre de tenant choisi par l’utilisateur comme une identité fiable. Le serveur doit vérifier les rapports qu’il peut créer dans cet espace. Les tâches en file nécessitent identité du tenant, périmètre et contexte d’autorisation ; les workers doivent respecter cette limite. Le droit de créer une tâche ne justifie pas un résultat publiquement téléchargeable.
Un nom de fichier ou une URL difficile à deviner n’est pas un contrôle d’accès. Vérifiez à nouveau les droits actuels au téléchargement. Pour des liens temporaires, définissez risques de partage, durée et révocation. Testez les anciens liens avec un utilisateur dont les droits ont été retirés.
Rendre le périmètre du rapport vérifiable visuellement
Le fichier doit afficher la période sélectionnée, l’espace client et la date et l’heure de création du rapport. Ces informations facilitent les contrôles opérationnels ; elles ne constituent pas un mécanisme de sécurité. Une clé de cache sans identifiant de tenant peut restituer un rapport au mauvais client. L’utilisation des mêmes paramètres de rapport par deux tenants doit donc faire l’objet d’un test spécifique.
Les accès temporaires du support doivent aussi figurer dans le système. Consignez explicitement délégations et rôles exceptionnels ; une étiquette générique « admin » ne doit pas autoriser par défaut tous les téléchargements clients. L’approche OWASP de l’autorisation des objets peut guider les contrôles des identifiants de rapports et de fichiers.
Faire des tests négatifs un critère de livraison
Créez des enregistrements témoins portant des marqueurs distincts dans deux tenants de test. Faites essayer au premier utilisateur l’identifiant du rapport, l’URL du fichier et les paramètres de filtrage du second. Vérifiez que le contexte du tenant est conservé dans la tâche en file et que les clés de cache ne se confondent pas. Le résultat ne doit contenir aucun marqueur de l’autre tenant. Répétez ces tests pour chaque type de rapport et chaque rôle.
Liste de contrôle de mise en œuvre
- L’identité du tenant est-elle vérifiée côté serveur ?
- Le worker respecte-t-il la même limite de données ?
- Le téléchargement est-il autorisé séparément ?
- Le cache est-il séparé par contexte client ?
- Des tests négatifs avec l’identifiant d’un autre tenant ont-ils été effectués ?
Questions fréquentes
Les UUID assurent-ils l’isolation ?
Ils peuvent compliquer les tentatives de deviner un identifiant ; ils ne remplacent pas les contrôles d’autorisation.
Que faire si les droits sont retirés pendant la génération ?
Vérifiez les droits actuels au téléchargement ; l’ancien droit de création ne doit pas donner un accès illimité.
Périmètre et limites
Ces tests couvrent un flux d’export particulier. Vérifiez séparément l’isolation sur toutes les API, fichiers et opérations de fond.
Sources et actualité
Vérification des sources : 7 octobre 2026. Les versions des documents liés et les conditions des fournisseurs peuvent changer. Vérifiez la version actuelle de la source concernée avant toute mise en œuvre.
Service associé
Découvrir les logiciels sur mesure et les applications mobiles