RBAC vs isolation des locataires : deux frontières de sécurité différentes
RBAC et l'isolation des locataires résolvent deux problèmes de sécurité différents dans les systèmes multi-locataires. Le contrôle d'accès basé sur les rôles (RBAC) détermine ce qu'un principal authentifié est autorisé à faire, comme lire des commandes, modifier des produits ou gérer des utilisateurs. L'isolation des locataires détermine à quelles données, ressources et contexte d'exécution d'un locataire ce principal est autorisé à accéder. Un utilisateur peut être correctement authentifié et correctement associé à un rôle RBAC tout en subissant une faille de sécurité si l'application permet à ce rôle d'opérer sur les ressources d'un autre locataire.
Ce que le RBAC contrôle réellement
Le RBAC est un modèle d'autorisation dans lequel les permissions sont associées à des rôles et les utilisateurs sont affectés à ces rôles. Le rôle agit comme une abstraction administrative entre les identités et les permissions.
Les travaux classiques du NIST sur le RBAC formalisent cela autour des utilisateurs, des rôles, des permissions, des opérations et des objets. L'avantage pratique est qu'une organisation peut gérer l'autorisation via des rôles relativement stables liés aux fonctions ou responsabilités, plutôt que d'attacher chaque permission directement à chaque utilisateur.
Un rôle tel que EDITOR peut donc signifier : peut lire du contenu, écrire du contenu et publier du contenu. Un rôle tel que ACCOUNTANT peut signifier : peut lire les données de facturation, rapprocher les factures et approuver les règlements.
Ce que l'isolation des locataires contrôle réellement
L'isolation des locataires est l'ensemble des mécanismes qui empêchent un locataire de lire, modifier, influencer ou recevoir accidentellement les ressources d'un autre locataire dans un système partagé.
La frontière protégée est plus large que les lignes d'une base de données. L'état propre à un locataire peut exister dans des tables relationnelles, du stockage objet, des index vectoriels, des caches, des index de recherche, des messages de file d'attente, des fichiers, des artefacts temporaires, des tâches en arrière-plan, des analyses, des limites de débit et des ressources d'infrastructure.
Les recommandations d'AWS pour le SaaS rendent la distinction explicite : l'autorisation accorde l'accès aux ressources, tandis que l'isolation des locataires garantit que ces ressources ne peuvent pas franchir la mauvaise frontière de locataire même lorsque l'infrastructure est partagée.
L'exemple le plus simple
Supposons qu'Alice soit administratrice du locataire A et que Bob soit administrateur du locataire B. Les deux utilisateurs détiennent légitimement le même rôle ADMIN.
Le RBAC peut correctement conclure que les deux utilisateurs peuvent exécuter une opération telle que users.read. Mais lorsque Alice demande l'ID utilisateur 847, l'application doit encore vérifier que l'utilisateur 847 appartient au locataire A.
Si l'API vérifie seulement « Alice a ADMIN » puis exécute SELECT * FROM users WHERE id = 847, le RBAC a réussi tandis que l'isolation des locataires a échoué.
Une décision d'autorisation multi-locataires correcte
Où l'exemple simple s'arrête
Les systèmes réels contiennent souvent plusieurs classes d'identité : utilisateurs locataires, administrateurs de plateforme, travailleurs en arrière-plan, intégrations, agents et services opérationnels inter-locataires. Certains d'entre eux franchissent légitimement les frontières des locataires.
Cela ne supprime pas le besoin d'isolation. Cela signifie que l'autorité inter-locataires doit être explicite, étroite et auditables séparément plutôt que d'émerger accidentellement d'un rôle global ou d'une connexion à la base de données non délimitée.
L'isolation des locataires peut également varier selon la couche. Un produit peut partager des serveurs d'application tout en séparant les bases de données, ou utiliser une base de données partagée avec des politiques au niveau des lignes tout en offrant aux locataires premium un stockage ou une puissance de calcul isolés. Il n'existe pas de topologie d'isolation universelle unique.
RBAC vs isolation des locataires
Deux dimensions de sécurité différentes
| RBAC | Isolation des locataires | |
|---|---|---|
| Question principale | ||
| Unité typique | ||
| Exemple | ||
| Défaillance typique | ||
| Implémentation typique | ||
| Peut-il exister seul ? |
Authentification, autorisation et isolation sont trois vérifications différentes
| Couche | Question | Exemple de défaillance |
|---|---|---|
| Authentification | Qui est ce principal ? | Un attaquant usurpe l'identité d'Alice |
| Autorisation / RBAC | Ce principal peut-il effectuer cette opération ? | Un lecteur peut supprimer des utilisateurs |
| Isolation des locataires | Cette opération peut-elle atteindre cette frontière de locataire/ressource ? | Un administrateur du locataire A lit une commande du locataire B |
Ces vérifications sont liées mais non substituables. L'authentification peut être parfaite alors que l'autorisation échoue. L'autorisation peut être correcte alors que l'isolation des locataires échoue. Un chemin de requête SaaS sécurisé nécessite toutes les frontières applicables.
Les rôles ont besoin d'une portée
Le mot ADMIN est incomplet sans portée. Il peut signifier administrateur de plateforme, administrateur de locataire, administrateur de projet, administrateur d'espace de travail ou administrateur d'un sous-système.
Dans les systèmes multi-locataires, l'attribution de rôle doit normalement être associée à l'appartenance à un locataire ou à une autre portée de ressource explicite. Le même utilisateur peut légitimement être ADMIN dans le locataire A et VIEWER dans le locataire B.
Un modèle de rôle global qui ignore cette distinction peut créer une fuite de privilèges même lorsque la carte des permissions elle-même est correcte.
Le contexte du locataire doit provenir d'un chemin de confiance
Un ID de locataire fourni par le client est utile comme sélecteur, mais il ne constitue pas une preuve d'autorité. Le serveur doit dériver ou vérifier l'appartenance au locataire par rapport à l'identité authentifiée et aux données d'autorisation actuelles.
Les directives actuelles d'OWASP sur les systèmes multi-locataires recommandent d'établir le contexte du locataire tôt dans le cycle de vie de la requête et mettent explicitement en garde contre le fait de traiter les en-têtes client ou les paramètres de requête comme une preuve d'autorisation.
Cela est important car une modification triviale de la requête de tenant=A à tenant=B ne doit pas suffire à franchir la frontière d'isolation.
La portée du locataire appartient à la recherche de ressource
Un modèle courant d'isolation au niveau applicatif consiste à inclure la portée du locataire dans la même requête qui résout la ressource.
| Recherche faible | Recherche plus forte limitée au locataire |
|---|---|
| findFirst({ where: { id } }) | findFirst({ where: { id, tenantId } }) |
| UPDATE orders SET ... WHERE id = ? | UPDATE orders SET ... WHERE id = ? AND tenant_id = ? |
| cache.get('user:' + id) | cache.get('tenant:' + tenantId + ':user:' + id) |
Ce modèle n'est pas le seul mécanisme d'isolation possible, mais il maintient la propriété du locataire proche de l'opération d'accès aux données et empêche un identifiant d'objet de devenir une capacité inter-locataires.
Les contrôles applicatifs sont utiles, mais l'isolation ne devrait pas dépendre d'un comportement parfait des développeurs
Les recommandations d'isolation d'AWS mettent explicitement en garde contre le fait de laisser l'application de l'isolation uniquement aux développeurs de services. Dans une grande base de code, une requête, une clé de cache ou un chemin de worker finira par omettre la portée du locataire.
La défense en profondeur peut donc déplacer l'isolation vers des middlewares partagés, des couches de dépôt/service, des moteurs de politiques, la sécurité au niveau des lignes (Row-Level Security) de la base de données, des identifiants dédiés, des schémas séparés ou des bases de données séparées selon le risque et l'architecture.
Stratégies d'isolation de base de données
| Stratégie | Frontière | Force / compromis |
|---|---|---|
| Tables partagées + clé de locataire | Politique au niveau ligne/applicatif | Efficace sur le plan opérationnel ; nécessite une portée de locataire exhaustive et des tests solides |
| Tables partagées + RLS de base de données | Frontière de politique de base de données | Réduit la dépendance à chaque requête applicative ; nécessite des rôles corrects, un contexte de locataire de session/transaction et une couverture de politique |
| Schémas séparés | Frontière d'espace de noms / rôle de base de données | Séparation logique plus forte ; complexité opérationnelle accrue |
| Bases de données séparées | Frontière de base de données / identifiants | Isolation forte et rayon d'impact plus simple ; coût de provisionnement et d'exploitation plus élevé |
| Infrastructure/compte séparé | Frontière d'infrastructure | Séparation à gros grain la plus forte ; coût et surcharge opérationnelle les plus élevés |
| Hybride | Par charge de travail/classe de données | Permet une isolation plus forte uniquement là où le risque/la conformité le justifie |
La fiche pratique actuelle d'OWASP sur la sécurité multi-locataires répertorie les bases de données séparées, les schémas séparés, les tables partagées avec contrôles au niveau des lignes et les modèles hybrides. Le modèle correct dépend du niveau de menace, de la conformité, des performances et du coût opérationnel.
La sécurité au niveau des lignes de PostgreSQL peut fournir une défense en profondeur
Avec des tables partagées, la sécurité au niveau des lignes de PostgreSQL peut appliquer un prédicat de locataire au niveau de la base de données afin que les requêtes ordinaires ne puissent pas voir les lignes en dehors de la politique de locataire active.
Cependant, la RLS n'est pas magique. Les superutilisateurs PostgreSQL et les rôles avec BYPASSRLS peuvent contourner les politiques de lignes. OWASP recommande donc d'utiliser un rôle de chemin de requête à moindre privilège et de tester le même mode de connexion/pooling utilisé en production.
La réutilisation des connexions est un autre point important : le contexte du locataire doit être défini et réinitialisé en toute sécurité pour chaque transaction/requête afin qu'une connexion mise en pool ne puisse pas divulguer l'état d'un locataire précédent.
L'isolation des locataires doit inclure les caches
Une requête de base de données peut être parfaitement délimitée et pourtant divulguer des données via une clé de cache partagée.
Si user:42 existe à la fois dans le locataire A et le locataire B, une clé de cache globale peut renvoyer la valeur du mauvais locataire. Les clés de cache sensibles au locataire doivent inclure chaque attribut qui modifie la visibilité ou la sémantique du résultat, généralement le locataire, l'utilisateur, la locale, l'ensemble de fonctionnalités ou la version des permissions.
La partition du cache est une défense en profondeur, pas un remplacement de l'autorisation. La requête doit toujours être autorisée avant que le contenu protégé mis en cache ne soit renvoyé.
Les fichiers et le stockage d'objets nécessitent leur propre frontière de locataire
Le stockage d'objets doit distinguer les objets globaux, ceux limités au locataire et ceux limités à l'utilisateur. Un préfixe de dossier seul n'est qu'une convention de nommage, sauf si la politique d'accès restreint réellement les lectures et les écritures.
Des conceptions plus robustes peuvent utiliser des clés d'objet tenant compte du locataire, des politiques de compartiment, des compartiments ou comptes séparés, ou des clés de chiffrement spécifiques au locataire lorsque le risque ou la conformité exige une isolation plus forte.
Les URL signées doivent être autorisées avant leur émission et limitées à l'objet et à l'opération exacts. La possession d'un identifiant d'objet ne doit pas, en soi, accorder un accès inter-locataires.
Les tâches en arrière-plan et les files d'attente peuvent briser l'isolation
Les tâches asynchrones quittent souvent le contexte de la requête HTTP d'origine, ce qui rend la propagation du locataire facile à mal gérer. Un message de file d'attente contenant tenantId ne constitue pas une preuve suffisante que le producteur était autorisé.
Le worker doit porter une identité de service ou d'utilisateur vérifiée ou une enveloppe de tâche de confiance, rétablir le contexte du locataire et réautoriser les opérations importantes à la frontière du consommateur.
L'isolation des locataires inclut également la disponibilité. Un locataire ne doit pas pouvoir monopoliser les workers, les files d'attente, les pools de connexions ou la puissance de calcul partagés d'une manière qui dégrade matériellement les autres locataires.
La recherche et le RAG nécessitent une récupération tenant compte du locataire
L'IA multi-locataires introduit une autre copie du problème d'isolation. Les documents peuvent être découpés en segments, vectorisés et stockés dans un index vectoriel après ingestion.
Les recommandations actuelles de l'OWASP en matière de sécurité RAG indiquent que le contrôle d'accès doit être appliqué au moment de la récupération et que les segments du locataire A ne doivent pas être récupérés par des requêtes du locataire B. Les autorisations au niveau du document ne peuvent pas simplement être supposées survivre automatiquement au découpage en segments.
L'index vectoriel doit donc contenir des métadonnées de locataire ou d'accès, ou des collections physiquement ou logiquement séparées selon la conception d'isolation. Les filtres de récupération doivent être appliqués avant que du contenu non autorisé puisse entrer dans le contexte du modèle.
Les données dérivées héritent de la sensibilité du locataire
Les embeddings, les index de recherche, les vignettes, les résumés générés, les caches, les lignes analytiques et les réponses de l'IA sont dérivés des données sources. Leur portée de locataire doit suivre la source, sauf si une transformation explicite crée un artefact partagé ou global légitime.
La suppression et le départ d'un locataire doivent donc se propager au-delà de la ligne canonique. Supprimer un document de locataire tout en laissant des segments recherchables ou des résumés en cache peut maintenir une exposition inter-locataires ou post-rétention.
Tout n'appartient pas à un locataire
Les plateformes multi-locataires comportent souvent des ressources intentionnellement globales : taxonomies de produits, modèles publics, autorisations système, définitions de fonctionnalités ou contenu public.
Le modèle le plus sûr est une classification explicite : global, limité au locataire, limité à l'utilisateur ou explicitement inter-locataires. Les ressources ambiguës sont le point de départ des fuites accidentelles.
Un objet intentionnellement partagé doit avoir une raison documentée d'être global plutôt que de simplement manquer d'une association à un locataire.
Les administrateurs de plateforme nécessitent un modèle d'autorité différent
Un opérateur de plateforme peut avoir besoin d'inspecter plusieurs locataires pour le support, la conformité ou les opérations d'infrastructure. Modéliser cela comme un ADMIN de locataire ordinaire avec un accès accidentel à la base de données globale affaiblit à la fois la sécurité et l'auditabilité.
Une meilleure conception utilise une identité de plateforme distincte ou une permission inter-locataires explicite, une authentification plus forte, une limitation d'usage, un audit détaillé et, le cas échéant, des contrôles d'approbation ou de bris de glace.
L'accès inter-locataires devrait donc être une capacité nommée, et non l'absence d'un filtre de locataire.
Le RBAC peut être combiné avec des attributs
Certaines décisions dépendent de plus que le rôle. L'appartenance à un locataire, la région, le propriétaire de la ressource, le niveau d'abonnement, le temps, l'appartenance à un projet ou la classification des données peuvent tous affecter l'accès.
Le RBAC et l'ABAC ne sont pas mutuellement exclusifs. Les directives actuelles d'AWS sur l'autorisation multi-locataires abordent les modèles RBAC, ABAC et hybrides. Un rôle peut définir une responsabilité large tandis que les attributs contraignent l'instance de ressource concrète à laquelle on peut accéder.
La règle architecturale clé demeure : ne pas encoder l'isolation des locataires uniquement comme un nom de rôle accessoire si l'identité du locataire est une frontière de ressource de premier ordre.
Les décisions d'autorisation sont au moins bidimensionnelles
| Principal | Permission de rôle | Relation avec le locataire | Décision |
|---|---|---|---|
| Alice | orders.read | La commande appartient au locataire d'Alice | Autoriser |
| Alice | orders.read | La commande appartient à un autre locataire | Refuser |
| Alice | orders.write | La commande appartient au locataire d'Alice | Autoriser si le rôle inclut l'écriture |
| Alice | orders.write | La commande appartient à un autre locataire | Refuser |
| Support de plateforme | support.cross_tenant.read | Portée de support explicite + locataire cible audité | Potentiellement autoriser selon la politique de la plateforme |
| Travailleur en arrière-plan | orders.process | Portée de service de confiance pour le locataire du travail | Autoriser uniquement pour le locataire du travail vérifié |
Preuve d'implémentation originale : Aaasaasa AI CMS
Le service RBAC définit des codes de permission typés tels que cms.content.read, shop.orders.write, billing.reconcile et users.roles. Les rôles système mappent ces permissions en ensembles de responsabilités nommés.
Les enregistrements de rôle sont créés et résolus avec un tenantId. Les rôles système sont insérés ou mis à jour en utilisant une identité composite locataire/code, et la liste des rôles est filtrée par locataire.
La mise à jour et la suppression de rôle résolvent d'abord le rôle en utilisant à la fois l'ID de rôle et l'ID de locataire. Les affectations utilisateur-rôle sont également stockées et remplacées dans le contexte du locataire actuel.
La résolution des permissions lit les affectations utilisateur-rôle explicites limitées à la fois par tenantId et userId. Cela empêche l'affectation de rôle d'un locataire de devenir automatiquement l'affectation de rôle d'un autre locataire.
Au niveau de l'API, les routes RBAC administratives résolvent un contexte de locataire avant de créer ou de modifier des rôles. C'est la bonne direction : l'administration des permissions elle-même doit respecter la multi-location.
| Modèle d'implémentation observé | Signification de sécurité |
|---|---|
| Codes de permission typés | Le vocabulaire des opérations RBAC est explicite |
| Rôles système → cartes de permissions | Les rôles agrègent les permissions plutôt que de coder en dur les utilisateurs |
| Identité de rôle tenantId_code | Le même rôle logique peut exister séparément par locataire |
| La recherche de rôle utilise id + tenantId | La mutation de rôle est limitée au locataire |
| La relation utilisateur-rôle stocke tenantId | L'appartenance n'est pas déduite globalement du rôle seul |
| La résolution des permissions utilise tenantId + userId | L'autorisation est évaluée dans le contexte du locataire |
Pourquoi cette distinction est encore plus importante pour les agents IA
Les agents IA peuvent transformer une erreur de permission en une séquence d'actions. Si un agent se voit attribuer un outil large orders.read sans application limitée au locataire, une défaillance de raisonnement ou d'injection de prompt peut provoquer des lectures inter-locataires à la vitesse de la machine.
Les descriptions des outils d'agent peuvent mentionner des contraintes de locataire, mais l'application doit toujours avoir lieu dans la couche de confiance (runtime/service/données). Les instructions en langage naturel ne constituent pas une frontière d'autorisation.
Il en va de même pour le RAG : un agent peut avoir la permission d'utiliser l'outil de recherche alors que le backend de recherche doit toujours empêcher la requête du Locataire A de renvoyer les chunks du Locataire B.
Tester le RBAC et l'isolation des locataires séparément
| Famille de tests | Ce qu'elle doit prouver |
|---|---|
| Test de rétrogradation de rôle | Un utilisateur sans permission ne peut pas effectuer l'opération même au sein de son propre locataire |
| Test d'objet inter-locataires | Un utilisateur avec le bon rôle ne peut toujours pas accéder au même type de ressource dans un autre locataire |
| Falsification d'identifiant | La modification des ID d'objet/locataire ne franchit pas la portée |
| Test de point de terminaison de liste/en masse | Les requêtes larges ne renvoient que les données de locataire autorisées |
| Test de réutilisation de cache | Deux locataires utilisant des processus/connexions réutilisés ne reçoivent jamais l'état mis en cache de l'autre |
| Test de rôle de requête RLS | Le rôle de requête de production ne peut pas contourner les politiques de lignes |
| Test de worker asynchrone | Le contexte du locataire survit à la mise en file d'attente et est revalidé à la consommation |
| Test de récupération vectorielle | La requête du Locataire A ne récupère jamais les chunks du Locataire B |
| Test d'administrateur de plateforme | La capacité inter-locataires est explicite, étroite et auditable |
| Test de désinscription | Les données du locataire et les index/caches dérivés sont supprimés conformément à la politique |
Les directives d'OWASP sur les régressions d'autorisation mentionnent spécifiquement les tests de frontière inter-locataires car les modifications de code dans la mise en cache, les requêtes ou les services partagés peuvent silencieusement briser l'isolation même lorsque les tests de rôle continuent de réussir.
Modes de défaillance courants
| Mode de défaillance | Pourquoi il échoue |
|---|---|
| Vérifier le rôle mais pas le locataire | Un rôle valide devient une autorité inter-locataires |
| Faire confiance à l'ID de locataire de la requête | Le client contrôle le sélecteur d'isolation |
| Limiter l'interface mais pas l'API | Les boutons cachés ne protègent pas les ressources backend |
| Point de terminaison de détail tenant-aware, point de terminaison de liste non limité | Les lectures en masse fuient vers d'autres locataires |
| Filtre de locataire dans la plupart des requêtes | Un chemin oublié brise la frontière |
| Clés de cache globales | L'isolation correcte de la base de données est contournée par les données mises en cache |
| Index vectoriel partagé sans filtres de métadonnées appliqués | Le RAG récupère les chunks d'un autre locataire |
| ID de locataire du message de file d'attente traité comme autorisation | Une tâche forgée ou mal produite peut franchir la frontière du locataire |
| Administrateur de plateforme modélisé comme ADMIN ordinaire | Le pouvoir inter-locataires devient implicite et difficile à auditer |
| Rôle copié globalement à travers les appartenances de locataires | L'utilisateur reçoit des permissions dans des locataires où il n'a jamais été assigné |
| Bases de données séparées mais identifiant privilégié partagé | L'application peut toujours traverser les bases de données si son identifiant est trop large |
| RLS avec rôle de requête BYPASSRLS | La politique de base de données existe mais ne protège pas le chemin de requête réel |
| UUID aléatoires traités comme isolation | Les identifiants difficiles à deviner réduisent l'énumération mais n'autorisent pas l'accès |
Idées fausses courantes
| Idée fausse | Correction |
|---|---|
| « Le RBAC fournit l'isolation des locataires. » | Le RBAC contrôle les permissions ; l'isolation nécessite également une portée de locataire/ressource. |
| « Si l'utilisateur est un administrateur, les vérifications de locataire sont inutiles. » | L'autorité d'administrateur doit toujours avoir une portée explicite. |
| « L'ID de locataire dans le JWT suffit. » | Il ne peut être une entrée de confiance que s'il est validé et appliqué de manière cohérente à chaque chemin de ressource protégé. |
| « Des bases de données séparées suppriment les exigences d'autorisation. » | Les utilisateurs ont toujours besoin de permissions au niveau des opérations au sein de leur locataire. |
| « Une colonne tenant_id signifie que le système est isolé. » | Le champ n'aide que si les chemins d'accès l'appliquent. |
| « Les UUID empêchent l'accès inter-locataires. » | Les identifiants imprévisibles sont une défense en profondeur, pas une autorisation. |
| « RLS signifie que le code applicatif n'a pas besoin de contrôles de sécurité. » | L'autorisation applicative, les rôles DB corrects et la couverture des politiques restent importants. |
| « Une seule base de données vectorielle partagée est dangereuse. » | Elle peut être sûre si l'isolation est applicable et vérifiée ; la séparation physique est une option, pas la seule. |
| « Le support de plateforme a besoin d'un ADMIN global. » | Le support inter-locataires devrait être une autorité distincte, contrainte et auditable. |
| « Les services internes peuvent ignorer les vérifications de locataire. » | Les chemins internes peuvent toujours être compromis ou mal configurés et doivent préserver le contexte du locataire. |
Une séquence de conception pratique
Concevoir les permissions et l'isolation comme des dimensions séparées
Liste de contrôle RBAC + isolation des locataires
| Question | Réponse attendue |
|---|---|
| Qui est le principal ? | Identité d'utilisateur/service/agent authentifiée |
| Quel contexte de locataire s'applique ? | Appartenance vérifiée par le serveur ou portée de service |
| Quelle opération est demandée ? | Permission typée ou action de politique |
| Le principal a-t-il cette permission ? | Décision de rôle/politique |
| Qui possède la ressource cible ? | Classification explicite locataire/global/utilisateur |
| La portée de la ressource correspond-elle à l'autorité ? | Recherche/politique tenant-aware |
| Le stockage peut-il contourner les vérifications applicatives ? | Décision de défense en profondeur documentée |
| Les caches sont-ils sûrs pour les locataires ? | Les clés/espaces de noms et l'autorisation préservent la portée du locataire |
| Les fichiers/blobs sont-ils sûrs pour les locataires ? | La politique d'objet et l'émission d'URL signées appliquent la portée |
| Les tâches asynchrones sont-elles sûres pour les locataires ? | Le contexte vérifié se propage et est revalidé |
| Le RAG/recherche est-il sûr pour les locataires ? | L'isolation des métadonnées/collections est appliquée avant le contexte du modèle |
| Les administrateurs inter-locataires sont-ils explicites ? | Autorité, contrôles et audit séparés |
| Les identifiants ordinaires peuvent-ils contourner l'isolation ? | Non, ou chemin exceptionnel étroitement documenté |
| Les tests négatifs inter-locataires sont-ils automatisés ? | Oui pour chaque couche d'accès pertinente |
Cas limites et limitations
Un utilisateur peut appartenir à plusieurs tenants. Le tenant courant doit donc être un contexte d'exécution explicite, et non déduit de manière permanente à partir du compte utilisateur.
Certaines ressources sont intentionnellement partagées entre des tenants sélectionnés, comme les espaces de collaboration ou les données de consortium. Cela nécessite un modèle de partage explicite ; prétendre que la ressource appartient à un seul tenant et ajouter des exceptions plus tard crée généralement une autorisation ambiguë.
L'isolation contre les voisins bruyants est liée mais différente de l'isolation de confidentialité. Un tenant peut ne jamais voir les données d'un autre tenant tout en épuisant le CPU partagé, la capacité de file d'attente ou les connexions à la base de données. Les limites de débit et les quotas de ressources peuvent donc être conscients du tenant en tant que frontière de disponibilité.
L'isolation physique n'est pas automatiquement sécurisée si les identifiants du plan de contrôle ou les chemins administratifs peuvent franchir les frontières. L'isolation logique n'est pas automatiquement faible si les politiques sont appliquées de manière centralisée, avec le moindre privilège et testées de manière approfondie.
Les exigences d'isolation des tenants peuvent différer selon la classe de données. Les données de catalogue public, les enregistrements de facturation et les documents IA privés peuvent justifier différentes frontières de stockage et de chiffrement au sein du même produit SaaS.
Qu'est-ce qui changerait cette réponse ?
La mise en œuvre exacte change avec l'architecture : les API serverless, Kubernetes, PostgreSQL, le stockage d'objets, les bases de données vectorielles et les moteurs de politiques exposent différentes primitives d'isolation.
La force requise change également avec la réglementation, les contrats clients, la sensibilité des données, le modèle de menace et l'échelle opérationnelle. Certains tenants peuvent justifier des bases de données ou une infrastructure en silo tandis que d'autres partagent des ressources mutualisées.
La distinction conceptuelle ne change pas : la permission d'effectuer une opération n'est pas la même chose que la permission de franchir une frontière de tenant.
Connaissances canoniques associées
S01 est un prérequis de frontière de sécurité pour l'architecture IA d'entreprise et la gouvernance de l'IA. Une fois que les outils IA, le RAG ou les agents opèrent sur des données multi-tenants, l'identité du tenant doit traverser la récupération, l'exécution des outils, la mémoire, les caches et les traces d'audit.
Il se connecte également directement à l'IA agentique : la capacité des outils et la permission de rôle doivent encore être contraintes par la propriété du tenant avant qu'un agent puisse lire ou modifier des ressources métier.
Pour le RAG, l'isolation des tenants doit être appliquée avant que les fragments protégés n'atteignent le contexte du modèle.
Questions fréquemment posées
FAQ RBAC vs isolation des tenants
Quelle est la différence entre RBAC et l'isolation des tenants ?
Un rôle ADMIN permet-il automatiquement l'accès à tous les tenants ?
L'authentification suffit-elle pour l'isolation des tenants ?
Le tenantId doit-il être stocké dans le JWT ?
Ai-je besoin d'une base de données séparée par tenant ?
Le RLS PostgreSQL peut-il remplacer les filtres de tenant dans le code applicatif ?
Comment le RAG doit-il appliquer l'isolation des tenants ?
Un utilisateur peut-il avoir différents rôles dans différents tenants ?
Quel est le meilleur test pour l'isolation des tenants ?
Glossaire
Termes clés de la sécurité multi-tenant
- RBAC
- Contrôle d'accès basé sur les rôles : un modèle d'autorisation qui associe des permissions à des rôles et affecte des utilisateurs ou des principaux à ces rôles.
- Tenant
- Un client, une organisation, un espace de travail ou tout autre consommateur logique isolé d'un système multi-tenant partagé.
- Isolation des tenants
- Mécanismes qui empêchent un tenant d'accéder, de modifier ou de recevoir les ressources d'un autre tenant dans un système partagé.
- Authentification
- Vérification de l'identité d'un utilisateur, d'un service ou d'un autre principal.
- Permission
- Une opération ou capacité autorisée définie, telle que orders.read ou users.write.
- Rôle
- Un regroupement nommé de permissions associé à une responsabilité ou une fonction.
- ABAC
- Contrôle d'accès basé sur les attributs : autorisation basée sur les attributs du principal, de la ressource, de l'action ou de l'environnement.
- Sécurité au niveau des lignes
- Mécanisme de politique de base de données qui restreint les lignes qu'un rôle ou une session de base de données peut lire ou modifier.
- Accès inter-tenant
- Tout chemin d'accès dans lequel un principal opérant dans un contexte de tenant atteint des ressources appartenant à un autre tenant.
- Administrateur de plateforme
- Une identité opérationnelle privilégiée avec une autorité explicitement modélisée qui peut s'étendre sur plusieurs tenants.
- Contexte de tenant
- La portée de tenant vérifiée sous laquelle la requête, la tâche ou l'opération d'agent actuelle s'exécute.
Conclusion
RBAC et l'isolation des tenants sont des mécanismes de sécurité complémentaires, et non concurrents. RBAC structure la permission opérationnelle ; l'isolation des tenants contraint la frontière des ressources à l'intérieur de laquelle cette permission peut s'appliquer.
Une requête multi-tenant robuste nécessite donc plus que « l'utilisateur a le rôle ADMIN ». Elle nécessite un principal vérifié, un contexte de tenant vérifié, une opération autorisée, une cible limitée au tenant et une application à chaque couche de ressource pouvant contenir des données appartenant à un tenant.
La règle fiable la plus courte est : autoriser l'action, puis isoler la portée — et ne jamais supposer que l'une prouve l'autre.
Sources primaires et recommandations actuelles
Les sources ci-dessous soutiennent la définition RBAC et les recommandations actuelles sur l'isolation des tenants. La section Aaasaasa AI CMS est une preuve d'implémentation originale et est intentionnellement limitée aux modèles de code qui ont été vérifiés.
NIST — Contrôle d'accès basé sur les rôlesAperçu NIST des modèles RBAC et de la norme INCITS RBAC, incluant les utilisateurs, rôles, permissions, opérations et objets.
NIST CSRC — Glossaire RBACDéfinitions actuelles du glossaire NIST du contrôle d'accès basé sur les rôles en tant qu'attribution de permissions via des rôles.
AWS — L'état d'esprit d'isolationRecommandations AWS SaaS distinguant explicitement l'authentification/autorisation de l'isolation des tenants et recommandant des mécanismes d'isolation partagés.
AWS — FAQ sur l'autorisation multi-tenantRecommandations actuelles expliquant la différence entre l'autorisation et l'isolation des tenants dans les applications SaaS.
AWS — Considérations de conception multi-tenantRecommandations SaaS actuelles distinguant l'isolation des tenants de l'autorisation et discutant des modèles de politique d'autorisation mutualisés/isolés.
OWASP — Aide-mémoire sur la sécurité des applications multi-tenantRecommandations pratiques actuelles pour le contexte de tenant, l'isolation des bases de données, les caches, le stockage, les files d'attente, les tests et la prévention des accès inter-tenant.
OWASP — Aide-mémoire sur la sécurité RAGRecommandations actuelles exigeant un contrôle d'accès au moment de la récupération et une isolation des tenants pour les magasins vectoriels multi-tenant.
OWASP — Tests de régression d'autorisationRecommandations de test actuelles incluant les tests de rétrogradation de rôle et de frontière inter-tenant.
Related Articles
L'IA générative expliquée : modèles, recherche, outils et applications ne sont pas la même chose
L'IA générative est plus qu'un modèle. Découvrez comment les modèles, la récupération, les outils, le contexte, les environnements d'exécution et les applications s'articulent dans les systèmes d'IA en production.
Le GPU n'est pas le produit : architecture d'IA privée pérenne
Une infrastructure d'IA privée ne devrait pas être conçue autour d'un seul GPU ou d'un seul modèle. Une approche plus résiliente combine des GPU d'inférence rapides, des systèmes d'IA riches en mémoire, des nœuds d'IA physique et des modèles cloud de pointe optionnels derrière une couche de routage prenant en compte les capacités.
L'IA agentique expliquée : quand un système d'IA peut planifier, utiliser des outils et agir
L'IA agentique utilise des modèles au sein de boucles d'exécution multi-étapes où ils peuvent choisir des outils, observer les résultats, mettre à jour l'état et adapter leur action suivante dans des limites explicites d'exécution et de permissions.
La frontière de validité des réponses : la couche manquante entre la pertinence et les réponses fiables de l'IA
Une source peut être pertinente, faisant autorité et pourtant être erronée pour la question posée. La couche manquante est l'applicabilité : les conditions dans lesquelles une réponse est valable, et les changements qui obligent à la reconsidérer. Cet article présente la Frontière de Validité de la Réponse comme un modèle de conception de source pour les humains, la recherche par IA et les systèmes RAG.
Maîtriser le flux de travail SEO : Stratégies d'optimisation essentielles pour la croissance organique
Un flux de travail SEO structuré est crucial pour une croissance organique durable. Découvrez les dix stratégies fondamentales, de la recherche de mots-clés et l'optimisation technique à la qualité du contenu et l'analyse des performances.
Que devrait mémoriser, oublier, recalculer ou récupérer à nouveau un agent IA ?
Les agents à exécution longue ne devraient pas tout retenir. Cet article propose un modèle de cycle de vie pratique pour décider de ce qui a sa place dans la mémoire durable, de ce qui devrait être récupéré à nouveau, de ce qu'il est plus sûr de recalculer et de ce qui devrait expirer ou être remplacé.
Qu'est-ce qu'un architecte de solutions IA ? Limites du système, responsabilités et compromis
Un architecte de solutions d'IA transforme les exigences métier en un système d'IA prêt pour la production, couvrant les données, les modèles, les outils, la sécurité, l'exécution, l'évaluation et les opérations.
MCP vs A2A vs UCP vs AP2 vs A2UI : La pile de protocoles d'agent expliquée
MCP, A2A, UCP, AP2 et A2UI sont souvent présentés comme des standards d'agents concurrents. Ils résolvent principalement des problèmes d'interopérabilité différents. Ce guide associe chaque protocole à la frontière qu'il standardise réellement—et montre comment ils peuvent fonctionner ensemble dans un seul système de production.
IA souveraine : contrôle des modèles, des données, des infrastructures et des dépendances
L'IA souveraine concerne le contrôle effectif sur les modèles, les données, l'infrastructure, les logiciels, les opérations et les dépendances stratégiques — et non simplement l'endroit où un modèle d'IA est hébergé.
Source de vérité dans les systèmes d’IA : d’où provient réellement une connaissance fiable
Une source de vérité définit quelle source fait autorité pour un fait ou un état spécifique. Découvrez en quoi elle diffère du RAG, de la provenance, de la mémoire, du contexte, des bases de données vectorielles et des systèmes d'enregistrement.
IA en environnement isolé : comment les systèmes d’IA fonctionnent sans accès à Internet ni au cloud
L'IA en environnement isolé exécute des modèles, du RAG et des applications d'IA à l'intérieur d'un domaine de sécurité isolé, sans dépendance à Internet ni au cloud. Découvrez comment les modèles, les données, les mises à jour et les outils fonctionnent hors ligne.
Pourquoi plus de contexte peut rendre les réponses de l'IA pires
Une fenêtre de contexte plus grande ne garantit pas une meilleure réponse. Cet article explique comment la dilution du signal, les preuves contradictoires, l'état obsolète, la sensibilité à la position et la compression avec perte peuvent réduire la fiabilité de l'IA — et présente un test pratique de pression de contexte.