La première question d’un client qui choisit un logiciel en ligne partagé (on parle de logiciel multi-tenant) est toujours la même : « Mes données sont-elles visibles par un autre client ? ». La réponse habituelle est une affirmation : « Non, c’est sécurisé. » Une affirmation n’est pas une preuve.

Dans cet article, nous expliquons comment prouver l’isolation des données, à partir de la méthode que nous avons appliquée à une plateforme de gestion multi-clients. Nous ne parlons ni de ses données ni de ses clients : seulement de la méthode, des résultats génériques et des pièges.

Trois niveaux d’isolation à vérifier

1. Entre rôles. Un collaborateur ne doit pas accéder aux écrans d’administration. Un consultant ne voit pas la comptabilité.
2. Entre utilisateurs. Un consultant ne voit que ses propres documents, pas ceux de son collègue.
3. Entre clients (tenants). Un client ne voit jamais les données d’un autre client, même s’il connaît un identifiant.

La plupart des projets ne testent que le premier niveau, parce que c’est celui que l’on voit dans l’interface. Les deux autres se cassent plus discrètement.

La méthode de la « vérité terrain »

L’erreur classique consiste à comparer l’application à elle-même : « la liste affichée correspond à ce que l’application dit qu’elle devrait afficher ». Si l’application se trompe, le test se trompe avec elle.

Nous faisons autrement. Pour chaque personne de test, nous lisons directement dans la base de données la liste de ce qu’elle a le droit de voir, par exemple :

SELECT id FROM documents
WHERE client_id = :client AND proprietaire_id = :utilisateur;

Puis nous appelons l’application et vérifions que chaque identifiant renvoyé appartient à cette liste. Un seul identifiant en trop, et le test échoue. La base est la référence, l’application est ce qu’on met à l’épreuve.

La matrice rôles contre écrans

Pour chaque rôle (super administrateur, administrateur, financier, consultant…), chaque écran doit répondre soit « oui », soit « refusé ». On teste toutes les combinaisons :

• un « oui » à tort est une faille : le consultant lit une donnée d’administration ;
• un « refusé » à tort est une fonctionnalité cassée : l’administrateur ne peut plus travailler.

Dans notre cas, une vingtaine d’écrans testés avec cinq rôles ont donné zéro faille et zéro blocage à tort. Mais nous avons surtout trouvé un défaut de test, ce qui nous amène au piège principal.

Les accès directs : ce que l’interface ne montre pas

Une application peut cacher un document dans l’interface tout en le servant à quiconque demande directement son identifiant. On teste donc ce qu’aucun utilisateur ne fait normalement :

• demander directement le document d’un autre utilisateur ;
• demander une ressource appartenant à un autre client ;
• appeler un écran d’administration avec un compte de consultant.

La réponse attendue est toujours un refus (accès interdit ou introuvable), jamais un succès. Sur une centaine de tentatives de ce type, toutes ont été refusées. Nous ne décrivons pas la façon d’attaquer, seulement ce qu’il faut vérifier.

Le piège : un test qui ne vérifie rien

Notre premier test annonçait « zéro fuite ». Bonne nouvelle ? Non. En relisant, nous avons constaté que les factures n’étaient pas contrôlées du tout : elles étaient renvoyées dans une structure de réponse différente de celle que notre outil savait lire, et il comptait donc zéro identifiant à vérifier. Zéro anomalie sur zéro élément contrôlé.

Nous avons corrigé de deux façons :

1. Le test échoue si la structure de la réponse est inconnue, au lieu de l’ignorer.
2. Le test échoue si la liste est vide, parce qu’un test qui ne contrôle rien est un faux vert.

La règle à retenir : un test qui ne peut pas échouer ne prouve rien.

Ce que cela prouve, et ce que cela ne prouve pas

• Cela prouve que, sur un jeu de données réaliste, chaque rôle et chaque client voit ce qu’il doit voir, et que les accès directs courants sont refusés.
• Cela ne remplace pas un audit de sécurité ni un test d’intrusion : ce sont des méthodes plus larges, menées par des spécialistes.
• C’est une preuve par échantillon. Il faut la rejouer à chaque évolution qui touche les droits ou les requêtes.

Checklist à reprendre dans votre projet

• Des comptes de test pour chaque rôle, sur plusieurs clients différents.
• Une liste de référence lue en base, indépendante de l’application.
• Une matrice rôles contre écrans rejouée automatiquement.
• Des tentatives d’accès direct à des ressources d’autres utilisateurs et d’autres clients.
• Des tests qui échouent sur une réponse vide ou inattendue.
• Un jeu de données volumineux : certaines fuites n’apparaissent que sur les pages suivantes d’une liste.
• Un rapport conservé à chaque livraison.

Questions fréquentes

Qu’est-ce qu’une application multi-tenant ? Un logiciel unique, utilisé par plusieurs entreprises clientes dont les données sont séparées logiquement. C’est le modèle de la plupart des logiciels en ligne.

Qu’est-ce qu’un accès direct non autorisé (IDOR) ? Quand une application sert une ressource à quelqu’un qui connaît son identifiant sans vérifier qu’il y a droit. C’est l’une des failles les plus répandues des applications web.

Ce test suffit-il pour la conformité ? Non. Il apporte une preuve technique utile, mais la conformité (protection des données, contrats, audits) demande d’autres démarches.

Un regard extérieur sur votre isolation des données

Chez Neologix, nous réalisons des revues d’isolation des données pour des logiciels multi-clients : matrice de rôles, accès directs, rapport clair. Pour un regard plus large sur votre sécurité, lisez notre guide de la cybersécurité des PME au Maroc ou contactez-nous.