Sommaire
Un client voit uniquement ses dossiers à l’écran. Cela ne prouve pas que les fichiers, les exports et les traitements différés respectent la même frontière. Pour évaluer l’isolation des données dans un SaaS multi-tenant, suivez un dossier jusqu’à ses copies et à sa restauration. Vous obtiendrez une liste de preuves à demander avant d’accueillir de nouveaux clients.
Le protocole proposé utilise deux organisations fictives et décrit les résultats attendus. Il ne rapporte aucun essai exécuté. L’équipe de réalisation doit l’adapter à son architecture, le lancer dans un environnement maîtrisé et conserver les résultats observés, y compris les échecs.
Choisir la frontière d’isolation
Un SaaS peut partager ses tables entre clients, séparer les schémas ou réserver une base à chacun. Le choix dépend des risques, des volumes et des opérations à soutenir. Une base distincte facilite certaines séparations; elle ne corrige pas automatiquement un service d’export qui sélectionne le mauvais client.
La documentation AWS sur l’isolation distingue l’authentification de la restriction des ressources par locataire. Un utilisateur peut être correctement connecté tout en atteignant une donnée qui appartient à une autre organisation si la frontière manque.
Dans le cadrage d’une application web sur mesure, demandez un schéma qui identifie où le contexte client est établi et contrôlé. Incluez l’API, la base, les fichiers, le cache et les travailleurs qui exécutent les tâches. Indiquez aussi les fonctions administratives autorisées à traverser cette frontière.
Construire le laboratoire à deux clients
Créons les sociétés fictives Atelier Boréal et Fabrication Horizon. Chacune possède un administrateur, un employé, une facture et une pièce jointe. Utilisez volontairement un même nom de fichier et un même numéro de facture dans les deux sociétés. Ces collisions rendent visibles les clés qui oublient le contexte client.
Ajoutez une personne membre des deux organisations avec des rôles différents. Elle doit pouvoir changer d’espace sans transporter les droits de son premier rôle. Préparez aussi un utilisateur suspendu et un compte de soutien. Précisez ce que chacun peut faire, avant toute tentative de consultation ou modification.
Le jeu de données doit rester entièrement fictif. Attribuez des marqueurs reconnaissables aux documents de chaque société, puis notez leur propriétaire attendu dans un inventaire. Conservez cet inventaire avec la version de l’application et la configuration du laboratoire. Il servira à détecter une exposition, même dans une réponse techniquement réussie.
Suivre les chemins moins visibles
Commencez par remplacer un identifiant de dossier dans une requête émise par Boréal par celui d’Horizon. Le résultat attendu est un refus sans contenu d’Horizon. Reprenez le scénario pour la lecture, la modification et la suppression. Un bouton masqué ne constitue pas une frontière si l’API accepte toujours l’opération.
Préparez ensuite un export chez Boréal et consultez un dossier équivalent chez Horizon avant la fin du traitement. Vérifiez que le fichier final correspond à l’organisation qui a lancé la tâche. La même question se pose pour les notifications : quel contexte le travailleur utilise-t-il lorsque la session du navigateur a changé ou disparu?
Les recommandations OWASP multi-tenant couvrent notamment le contexte client, les caches et le stockage. Dans votre recette, incluez un fichier dont le nom existe des deux côtés et un résultat de recherche mis en cache. Demandez une preuve sur le contenu retourné, pas seulement sur le code HTTP.
Les intégrations d’un CRM ou ERP sur mesure demandent le même suivi. Une connexion externe doit être rattachée à la bonne organisation. Le travailleur ne devrait pas choisir le compte fournisseur à partir d’une valeur modifiable librement dans la demande.
Rejouer les vérifications à chaque changement
Donnez un identifiant à chaque scénario et associez-le à une frontière précise. Une modification du moteur d’export appelle les essais d’export. Un changement de gestion des membres appelle ceux des rôles, des sessions et des révocations. Gardez également une série minimale qui traverse les principaux chemins d’accès à chaque livraison.
Pour chaque exécution, consignez la version, le compte utilisé, l’action, le résultat attendu et le résultat observé. Ajoutez la référence de la preuve sans exposer de données de production. Une capture d’écran peut compléter un journal d’API; elle ne décrit pas à elle seule ce qui s’est passé dans une tâche différée.
Prévoyez un arrêt de livraison lorsqu’un cas révèle des données de l’autre société. N’effacez pas le résultat pour obtenir une série verte : corrigez la cause, reprenez le scénario et vérifiez les chemins qui partagent le composant. Un changement de cache peut affecter plusieurs fonctions sans modifier leurs écrans.
Restaurer un client sans toucher à l’autre
Supposons que Boréal demande la récupération d’une facture supprimée. Une sauvegarde commune peut aussi contenir Horizon. Préparez la restauration dans une ressource séparée, puis sélectionnez les données de Boréal selon une procédure autorisée. Le client ne doit pas recevoir une copie brute qui contient les autres organisations.
Avant de réintroduire la facture, vérifiez sa propriété, ses dépendances et les règles d’accès actuelles. Une vieille sauvegarde peut contenir un membre dont l’accès a depuis été retiré. La restauration du contenu ne doit pas rétablir silencieusement ses droits. Identifiez aussi la façon de traiter les pièces jointes et les index de recherche.
Le résultat attendu comprend deux constats : les données ciblées de Boréal sont récupérées selon le périmètre convenu, et l’état d’Horizon demeure intact. Comparez les marqueurs des deux sociétés avant et après. Le temps de reprise et la perte de données acceptable sont des objectifs à convenir et à mesurer lors d’un exercice réel.
Inclure les agents et la documentation
Une base de connaissances avec RAG ajoute des fragments, des index et parfois des conversations à examiner. Reprenez le laboratoire avec une question qui ressemble aux documents des deux clients. Le périmètre de recherche et les passages cités doivent rester autorisés pour l’utilisateur courant.
Le dossier de décision devrait réunir l’architecture, l’inventaire fictif, les scénarios et leurs résultats datés. Ajoutez les limites connues et le responsable de chaque correction. Cet ensemble aide à décider d’une livraison; il ne remplace pas une évaluation de sécurité adaptée à la plateforme.
Guides pour préparer la mise en œuvre
Questions fréquentes
Deux clients fictifs suffisent-ils?+
Ils fournissent un premier laboratoire lisible. Ajoutez ensuite les rôles, les volumes et les configurations qui représentent vos risques réels, notamment les fonctions de soutien et les intégrations.
Une base par client garantit-elle la séparation?+
Elle établit une frontière utile pour certaines opérations. Les services applicatifs, comptes administratifs, fichiers et exports doivent aussi sélectionner et autoriser le bon client.
Faut-il tester les refus?+
Oui. Vérifiez qu’un compte d’une organisation ne peut lire, modifier ou exporter les données de l’autre, et que les erreurs ne révèlent pas leur contenu.
Peut-on restaurer directement la sauvegarde commune?+
Une restauration globale peut affecter tous les clients. Pour une récupération ciblée, préparez une extraction contrôlée dans un environnement séparé et vérifiez les dépendances avant réintégration.
Préparer une preuve de séparation exploitable
Daillac peut cadrer avec votre équipe le laboratoire fictif, les chemins à contrôler et les critères d’une restauration ciblée.
D
