Tester l’isolation entre locataires : un client peut-il accéder aux données d’un autre ?

La décision que ce guide vous aide à prendre

Utilisez deux locataires synthétiques et ne modifiez qu’une relation de propriété à la fois. Vérifiez chaque opération séparément et examinez les effets en aval. Un refus sur un point d’accès ne démontre pas l’isolation des exportations, des tâches asynchrones ou d’une autre action sur le même objet.

Maintenir une variable constante

Commencez par une requête valide pour le tenant A. Répétez l’opération avec une identité du tenant B en conservant le même objet, puis testez un autre objet avec l’identité d’origine. Ces comparaisons contrôlées aident à distinguer un défaut d’autorisation d’une requête mal formée ou d’un prérequis manquant.

Vérifiez chaque opération séparément

La lecture, la mise à jour, l’approbation, l’exportation et la suppression peuvent être contrôlées à différents points. Le fait qu’un point de terminaison de liste filtre correctement les objets renseigne peu sur un point de terminaison d’accès direct aux objets ou sur le téléchargement d’un export. Utilisez la matrice des rôles documentée pour déterminer ce qui doit être autorisé ou refusé.

Regardez au-delà du statut de la réponse

Vérifiez la propriété de l’objet, l’état persistant et l’identité d’audit. Certains services renvoient une réponse générique de réussite avant qu’un processus en arrière-plan n’exécute l’action. Suivez la tâche approuvée jusqu’à son résultat et confirmez les données ou autorisations du tenant qu’elle a utilisées.

Retester la limite de la politique

Une correction durable associe côté serveur le principal authentifié au locataire, à l’objet et à l’opération concernés. Testez aussi bien la délégation légitime que le refus. Des identifiants aléatoires et des commandes masquées peuvent réduire les découvertes accidentelles, mais ne remplacent pas la décision d’autorisation métier.

Utilisez un ensemble de comparaison choisi délibérément

Créez deux organisations clientes disposant de ressources synthétiques et d’identités de test distinctes. Vérifiez d’abord que chacune peut effectuer ses opérations légitimes. Répétez ensuite une opération convenue sur l’objet canari de l’autre organisation, en gardant le reste de la requête identique. Le résultat sera ainsi plus facile à interpréter qu’en remplaçant des identifiants au hasard. Traitez séparément les rôles inter-organisations réellement prévus par le produit : un opérateur de support ou de plateforme peut relever d’une politique différente de celle d’un utilisateur client ordinaire.

Testez les différentes catégories d’opérations lorsqu’elles existent : consultation, modification, exportation, recherche et actions d’administration. La réussite d’une comparaison en lecture seule ne prouve pas que chaque route traitant le même objet applique la même décision de politique.

Recherchez les changements de contexte au sein du processus

Le contexte de propriété peut passer du service web à une file d’attente, un worker, un cache ou un stockage de fichiers. Identifiez ces transferts dans le périmètre et déterminez à quel endroit la décision attendue doit rester liée à l’organisation à l’origine de la demande. Le rejet correct d’un appel par l’interface frontale constitue un élément utile, mais une exportation asynchrone ou un lien vers les résultats accessible indépendamment peut nécessiter une vérification distincte. Utilisez des données synthétiques et un nombre limité d’opérations approuvées par le responsable.

Le guide sur l’autorisation dans les portails patients examine des changements comparables dans les relations d’accès, notamment l’accès délégué et sa révocation. Les règles métier diffèrent, mais dans les deux contextes, il est utile de tester le cycle de vie d’une autorisation, et pas seulement sa création initiale.

Retester la politique et le processus autorisé

Formulez la condition d’acceptation en précisant le principal, l’opération et la responsabilité. Consignez la réponse de refus ainsi que tout état ultérieur pertinent, avec une référence de corrélation si elle est disponible. Après la correction, vérifiez que le client légitime peut toujours effectuer l’action prévue et que l’interface adjacente convenue applique la même règle. Si l’implémentation centralise l’autorisation, validez le résultat observé au lieu de supposer que le changement d’architecture suffit.

Lorsqu’une action transfère une valeur ou modifie l’état d’une transaction, utilisez les comparaisons supplémentaires de notre guide de test d’intrusion de l’autorisation des paiements. La propriété du tenant et la séparation entre saisie et validation sont des contrôles complémentaires ; un constat doit identifier la décision qui a échoué, au lieu d’utiliser « contrôle d’accès » comme terme générique sans explication.

Mettez les recommandations en pratique

Utilisez la liste de préparation pour consigner les hypothèses, ou consultez le rapport fictif de Fintech AG pour des exemples d’éléments probants et de plans de traitement. Contactez Atlant Security en fournissant une description non sensible du périmètre.