Isolation des tenants pour les MSP : un tenant ID n'est pas une autorisation

Un tenant ID fourni par le client, un en-tête X-Tenant-ID, une connexion qui fonctionne, une politique d'accès conditionnel ou une connexion SSO indiquent chacun quelque chose d'utile — mais aucun d'entre eux, à lui seul, ne prouve que l'appelant est autorisé à voir les données d'un client donné. Ce guide s'adresse aux MSP et aux équipes IT qui exploitent ou achètent des plateformes multi-tenant : il expose, mécanisme par mécanisme, où une vérification d'autorisation côté serveur doit réellement se situer, de la première requête jusqu'au jour où un compte est désactivé.

Un tenant ID sélectionne un client, il ne l'autorise pas

Un tenant ID fourni par le client — dans le corps de la requête, dans un paramètre de requête, ou résolu à partir d'un sous-domaine — est un sélecteur. Il indique à l'application quel contexte client ouvrir. L'OWASP Multi-Tenant Security Cheat Sheet pose la règle sous-jacente : lier chaque requête à un principal authentifié, résoudre l'appartenance de ce principal au tenant à partir de l'état côté serveur, appliquer des contrôles au niveau des objets à l'intérieur du tenant, et garder les chemins d'administration ou de secours séparés de l'accès tenant ordinaire. Ce contrôle doit s'exécuter partout où une frontière de tenant compte, pas seulement à la porte d'entrée de l'API : sur les lectures et écritures, sur les actions administratives, et sur les tâches de fond qui reprennent le travail après la fin de la requête d'origine. Une tâche déclenchée par une file d'attente qui hérite d'un tenant ID depuis un message, sans le revérifier, rouvre exactement la brèche que le contrôle d'origine devait fermer.

Un en-tête X-Tenant-ID ou un champ du corps cachent le même piège

La même erreur revient sous le nom d'un en-tête. Les API multi-tenant acceptent couramment un en-tête X-Tenant-ID ou un champ tenant dans le corps de la requête pour choisir les données de quel client un appel doit toucher, et il est tentant de traiter cette valeur comme suffisante dès qu'elle est correctement interprétée. Les recommandations d'OWASP signalent deux pièges liés : supposer qu'un identifiant de tenant est sûr parce qu'il est long ou difficile à deviner, au lieu d'exécuter un véritable contrôle d'autorisation ; et laisser un chemin de code normalement limité au tenant retomber silencieusement sur une requête non limitée lorsque la valeur attendue est absente ou mal formée. Chacune de ces deux erreurs permet à un appelant authentifié, mais qui n'appartient pas au tenant demandé, d'atteindre des données appartenant à quelqu'un d'autre.

La connexion prouve qui vous êtes, pas quel tenant vous pouvez toucher

L'authentification répond à une question différente de l'isolation. La NIST Special Publication 800-210, consacrée au contrôle d'accès pour les systèmes cloud, traite l'isolation des tenants comme une propriété que la plateforme elle-même doit appliquer sur chaque API et chaque chemin de données lorsqu'une seule instance logicielle sert de nombreux tenants, car le client qui utilise le service ne contrôle pas l'infrastructure sous-jacente. Le Well-Architected SaaS Lens d'AWS décrit deux façons dont les fournisseurs construisent cela : dans un modèle « silo », chaque tenant dispose de ressources dédiées et d'un rôle d'exécution limité, plus simple à comprendre mais plus difficile à exploiter à grande échelle ; dans un modèle « pool », les tenants partagent l'infrastructure et l'isolation doit être appliquée dans la logique applicative à chaque requête. Aucun des deux modèles n'est intrinsèquement plus sûr. Ce qui compte, c'est si un fournisseur peut montrer, concrètement, comment une requête est liée au tenant de l'appelant avant que la moindre donnée ne soit touchée, et non que l'appelant dispose d'une connexion qui fonctionne.

L'accès conditionnel sécurise la connexion, pas le chemin des données

Microsoft décrit l'accès conditionnel comme un moteur de politiques Zero Trust fondé sur une logique si-alors : si un utilisateur, ou de plus en plus un agent d'IA, tente d'atteindre une ressource, alors une condition telle que la conformité de l'appareil, le risque de connexion ou la localisation doit être satisfaite au préalable. C'est une barrière réellement utile — elle peut empêcher un identifiant compromis de démarrer une session, ou couper une session qui commence à se comporter de manière suspecte. Mais elle n'a aucune visibilité sur la façon dont le backend d'une application décide, une fois qu'une session existe, quels enregistrements de quel client un appel d'API donné est autorisé à lire ou écrire. Si une plateforme se fie à une valeur de tenant fournie par le client pour prendre cette décision, l'accès conditionnel a déjà terminé son travail, avec succès et sans rapport avec le problème, au moment où la décision est prise. Une barrière de connexion bien configurée devant une API mal isolée produit la même fuite qu'elle produirait sans cette barrière. La licence Agent 365 de Microsoft étend l'accès conditionnel aux agents d'IA, mais la même distinction entre connexion et accès aux données continuera de s'y appliquer.

Le SSO fait entrer les utilisateurs ; seul SCIM fait sortir ceux qui partent

La fédération répond à « qui peut se connecter maintenant ? ». Le System for Cross-domain Identity Management, normalisé sous la RFC 7644, répond à une question différente : quels comptes devraient encore exister. La documentation de provisionnement SCIM de Microsoft décrit le déroulement habituel : une suppression logique chez le fournisseur d'identité met l'attribut active d'une ressource utilisateur à false, et l'application réceptrice est censée désactiver ou archiver ce compte en réponse. Sans intégration SCIM, la connexion unique d'une personne qui part cesse de fonctionner, mais son compte, et tout accès API résiduel qui lui est lié, peut rester intact. Le côté provisionnement a besoin de sa propre délimitation : un jeton porteur SCIM devrait être émis par tenant client et accepté uniquement sur le point de terminaison SCIM propre à ce tenant. Partager un seul secret SCIM multi-tenant entre plusieurs clients transforme un jeton unique divulgué en un risque de déprovisionnement et de prise de contrôle de compte entre clients différents.

Désactiver le compte ne met fin ni à la session ni au jeton

Lorsqu'une personne part et qu'un administrateur désactive son compte chez le fournisseur d'identité, il est facile de supposer que le travail est terminé. La documentation de Microsoft sur la révocation d'accès dit le contraire : désactiver un compte bloque les nouvelles connexions mais n'invalide pas automatiquement les jetons d'actualisation, les sessions actives ou les cookies de navigateur déjà émis. Pour vraiment couper l'accès, il faut révoquer séparément les sessions et les jetons et effacer les identifiants mis en cache — et, lorsqu'elle est disponible, l'évaluation continue de l'accès applique la coupure plus rapidement que d'attendre l'expiration naturelle d'un jeton. Le projet de guide NIST sur la gestion des sessions fait une remarque connexe : posséder un jeton d'accès valide ne prouve pas qu'une session est encore légitimement ouverte, et les sessions du fournisseur d'identité et celles de l'application sont indépendantes l'une de l'autre, si bien que mettre fin à l'une ne met pas fin à l'autre. C'est pourquoi l'OWASP Session Management Cheat Sheet exige une invalidation de session côté serveur avec des délais d'expiration à la fois pour l'inactivité et en valeur absolue, plutôt que de compter sur le client pour abandonner les identifiants.

Certains MSP préfèrent confier ce travail de plan de contrôle à un fournisseur dédié plutôt que de le construire et de l'auditer eux-mêmes ; Auris est une plateforme européenne d'IAM-as-a-Service pour l'authentification multifacteur adaptative, le SSO fédéré et des journaux d'audit immuables.

Que faire

• Vérifiez l'appartenance au tenant à partir des données d'identité côté serveur à chaque requête ; ne faites jamais confiance à un ID, un en-tête ou un champ du corps fourni par le client à lui seul.
• Appliquez ce contrôle sur chaque chemin où une frontière de tenant intervient : lectures, écritures, actions administratives, et tâches de fond ou déclenchées par une file d'attente.
• Rejetez tout sélecteur de tenant qui n'a pas été confirmé face aux appartenances réelles de l'appelant authentifié, au lieu de supposer qu'un identifiant long est sûr.
• Traitez l'accès conditionnel, le SSO et la liaison au tenant comme des contrôles distincts avec des modes de défaillance distincts, et testez chacun séparément.
• Mettez en place SCIM en plus du SSO, limitez chaque jeton SCIM à un seul tenant, et vérifiez que le compte d'une personne qui part est désactivé également dans le système source, pas seulement chez le fournisseur d'identité.
• Lors du départ, révoquez explicitement les sessions et les jetons d'actualisation sur chaque application utilisée par la personne, plutôt que de vous arrêter à « compte désactivé ».

Sources : OWASP Multi Tenant Security Cheat Sheet, NIST SP 800-210, AWS Well-Architected SaaS Lens, Microsoft Learn — Vue d'ensemble de l'accès conditionnel, Microsoft Learn — Use SCIM to provision users and groups, OWASP Session Management Cheat Sheet.