[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:fr":3,"public-menus:all":38,"post:rbac-vs-tenant-isolation-two-different-security-boundaries:fr":205,"related:post:rbac-vs-tenant-isolation-two-different-security-boundaries:fr:1":3031},{"statusCode":4,"data":5,"message":37},200,{"tenantId":6,"lang":7,"defaultLang":8,"siteUrl":9,"contactEmail":10,"brandName":11,"logoUrl":12,"siteName":11,"siteDescription":13,"ogImage":10,"robotsIndex":14,"socialLinks":10,"reservedSlugs":10,"seoPolicy":15},"stajic","fr","de","https:\u002F\u002Fstajic.de",null,"Stajic Platform","\u002FLogo_Planet.svg","Stajic Portal",true,{"branding":16,"relatedContent":17,"crossDomainLinks":18},{"logoUrl":12},{"enabled":14},[19,22,25,28,31,34],{"url":20,"label":21,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Ffigure.rocks","figure.rocks",{"url":23,"label":24,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Floving.rocks","loving.rocks",{"url":26,"label":27,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.com","bazify.com",{"url":29,"label":30,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.de","bazify.de",{"url":32,"label":33,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.at","bazify.at",{"url":35,"label":36,"isActive":14,"showInFooter":14,"includeInSameAs":14},"https:\u002F\u002Fbazify.ba","bazify.ba","Portal settings resolved",[39,45],{"id":40,"name":41,"location":42,"isActive":14,"isDefault":43,"items":44},1,"main-navigation","header",false,[],{"id":46,"name":47,"location":48,"isActive":14,"isDefault":14,"items":49},4,"main-menu","sidebar",[50,66,79,93,103,118,133],{"id":51,"title":52,"url":60,"target":61,"icon":62,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":64,"portfolioId":10,"children":65},"item-18",{"de":53,"en":54,"es":55,"fr":56,"it":54,"ru":57,"sr":58,"zh":59},"Startseite","Home","Inicio","Accueil","Главная","Почетна","首页","\u002Ffull-stack-web-developer-munich-performance-seo-and-maintainable-builds","_self","i-lucide-home","page",111,[],{"id":67,"title":68,"url":75,"target":61,"icon":76,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":77,"portfolioId":10,"children":78},"item-22",{"de":69,"en":69,"es":70,"fr":69,"it":71,"ru":72,"sr":73,"zh":74},"Vision","Visión","Visione","Видение","Визија","想象","\u002Fueber-uns-webdesign-muenchen-webaplikation","i-lucide-eye",113,[],{"id":80,"title":81,"url":89,"target":61,"icon":90,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":91,"portfolioId":10,"children":92},"item-19",{"de":82,"en":83,"es":84,"fr":83,"it":85,"ru":86,"sr":87,"zh":88},"Leistungen","Services","Servicios","Servizi","Услуги","Услуге","服务","\u002Fservices-dienstleistungen-muenchen","i-lucide-wrench",116,[],{"id":94,"title":95,"url":99,"target":61,"icon":100,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":101,"portfolioId":10,"children":102},"item-23",{"de":96,"en":96,"es":96,"fr":96,"it":96,"ru":97,"sr":97,"zh":98},"Blog","Блог","博客","\u002Fblog","i-lucide-book-open",112,[],{"id":104,"title":105,"url":114,"target":61,"icon":115,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":116,"portfolioId":10,"children":117},"item-32",{"de":106,"en":107,"es":108,"fr":109,"it":110,"ru":111,"sr":112,"zh":113},"Neue Technologien","New Technologies","Nuevas tecnologías","Nouvelles technologies","Nuove tecnologie","Новые технологии","Нове технологије","新技术！","\u002Fneue-webtechnologien","i-lucide-sparkles",122,[],{"id":119,"title":120,"url":129,"target":61,"icon":130,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":131,"portfolioId":10,"children":132},"item-20",{"de":121,"en":122,"es":123,"fr":124,"it":125,"ru":126,"sr":127,"zh":128},"Kontakt","Contact us!","Contacto","Contact","Contatto","Контакт","Контактирајте нас","联系我们！","\u002Fcontact","i-lucide-mail",115,[],{"id":134,"title":135,"url":144,"target":61,"icon":145,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":147},"item-21",{"de":136,"en":137,"es":138,"fr":139,"it":140,"ru":141,"sr":142,"zh":143},"Unsere Arbeit","Our Work","Nuestro trabajo","Nos réalisations","I nostri lavori","Наши работы","Наши радови","文件夹","\u002Fportfolio","i-lucide-briefcase",114,[148,161,175,181,193],{"id":149,"title":150,"url":144,"target":61,"icon":159,"isActive":14,"type":63,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":146,"portfolioId":10,"children":160},"item-24",{"de":151,"en":152,"es":153,"fr":154,"it":155,"ru":156,"sr":157,"zh":158},"Alle Projekte","All Projects","Todos los proyectos","Tous les projets","Tutti i progetti","Все проекты","Сви пројекти","所有项目","i-lucide-grid-3x3",[],{"id":162,"title":163,"url":171,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":174},"item-29",{"de":164,"en":165,"es":166,"fr":167,"it":168,"ru":169,"sr":170,"zh":143},"Local Roots, Global Reach","Local Roots - Global Reach","Empresa local ","Entreprise locale","Azienda locale","Местная компания","Локално предузеће глобално тржиште","\u002Fportfolio\u002Flocal-roots-global-reach-communication-media-systems-for-modern-business","i-lucide-folder","custom",[],{"id":176,"title":177,"url":179,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":180},"item-28",{"de":178,"en":178,"es":178,"fr":178,"it":178,"ru":178,"sr":178,"zh":178},"Solr Suggester","\u002Fportfolio\u002Fsolr-fuzzy-suggester-und-solr-infix-suggester-abfrage-ueber-ajax-und-filterung",[],{"id":182,"title":183,"url":191,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":192},"item-27",{"de":184,"en":185,"es":186,"fr":187,"it":188,"ru":189,"sr":190,"zh":185},"Firmenwebseite SEO","Company Website SEO","Sitio web corporativo SEO","Site web d’entreprise SEO","Sito web aziendale SEO","Корпоративный сайт SEO","Пословна веб-страница SEO","\u002Fportfolio\u002Fseo-sem-branding-mobile-webseite-muenchen",[],{"id":194,"title":195,"url":203,"target":61,"icon":172,"isActive":14,"type":173,"productId":10,"categoryId":10,"shopCategoryId":10,"articleId":10,"pageId":10,"portfolioId":10,"children":204},"item-31",{"de":196,"en":197,"es":198,"fr":199,"it":200,"ru":201,"sr":202,"zh":197},"Digitalisierungsportal","Digitalization Portal","Portal de digitalización","Portail de numérisation","Portale di digitalizzazione","Портал цифровизации","Портал за дигитализацију","\u002Fportfolio\u002Fdigitalisierungsportal-archiv-museum-bibliothek-ead-lido-mets-mods",[],{"statusCode":4,"data":206,"message":3030},{"id":207,"title":208,"slug":209,"content":210,"contentJson":211,"excerpt":1411,"featuredImage":1412,"featuredImageAlt":1413,"featuredImageCaption":10,"featuredImageTitle":10,"featuredImageCopyright":10,"featuredImageAuthor":10,"featuredImageSourceUrl":10,"featuredImageLicense":10,"featuredImageIsAiGenerated":43,"status":1414,"publishedAt":1415,"createdAt":1416,"updatedAt":1417,"seoLocalePaths":1418,"categories":1427,"author":1440,"translations":1445},"490","RBAC vs isolation des locataires : deux frontières de sécurité différentes","rbac-vs-tenant-isolation-two-different-security-boundaries","\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--info my-6 rounded-xl border p-5 border-blue-300 bg-blue-50 dark:border-blue-900 dark:bg-blue-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Réponse directe\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>RBAC répond à « que peut faire cette identité ? » L'isolation des locataires répond à « à l'intérieur de quelle frontière peut-elle le faire ? »\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Une application multi-locataires sécurisée a normalement besoin des deux. Un administrateur de locataire peut disposer de permissions étendues, mais ces permissions doivent rester limitées au locataire de l'administrateur, sauf s'il existe une autorité explicitement distincte au niveau de la plateforme.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Un rôle n'est pas une frontière de locataire\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Attribuer à un utilisateur le rôle \u003Ccode>ADMIN\u003C\u002Fcode> n'implique pas automatiquement « administrateur du locataire A uniquement ». Le rôle doit être évalué conjointement avec le contexte de locataire vérifié et la propriété du locataire de la ressource cible. Sinon, un rôle valide peut devenir un privilège inter-locataires.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Note sur les sources actuelles — 8 octobre 2026\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">La distinction sous-jacente est stable. Le NIST définit le RBAC autour des utilisateurs, des rôles, des permissions, des opérations et des objets. Les recommandations actuelles d'AWS pour le SaaS indiquent explicitement que l'authentification et l'autorisation ne sont pas équivalentes à l'isolation des locataires, et qu'un utilisateur peut être authentifié et autorisé tout en accédant aux ressources d'un autre locataire si l'isolation n'est pas appliquée séparément. Les recommandations actuelles de l'OWASP sur la sécurité multi-locataires considèrent également l'isolation des locataires comme une exigence transversale couvrant les API, les bases de données, les caches, le stockage, les files d'attente et d'autres ressources partagées.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Sommaire\">\u003Cstrong class=\"editorjs-toc__title\">Sommaire\u003C\u002Fstrong>\u003Col class=\"editorjs-toc__list editorjs-toc__list--depth-0\">\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-6\" class=\"editorjs-toc__link\">Ce que le RBAC contrôle réellement\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Ce que l'isolation des locataires contrôle réellement\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-14\" class=\"editorjs-toc__link\">L'exemple le plus simple\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-19\" class=\"editorjs-toc__link\">Où l'exemple simple s'arrête\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">RBAC vs isolation des locataires\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-25\" class=\"editorjs-toc__link\">Authentification, autorisation et isolation sont trois vérifications différentes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-28\" class=\"editorjs-toc__link\">Les rôles ont besoin d'une portée\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">Le contexte du locataire doit provenir d'un chemin de confiance\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-36\" class=\"editorjs-toc__link\">La portée du locataire appartient à la recherche de ressource\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-40\" class=\"editorjs-toc__link\">Les contrôles applicatifs sont utiles, mais l'isolation ne devrait pas dépendre d'un comportement parfait des développeurs\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Stratégies d'isolation de base de données\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">La sécurité au niveau des lignes de PostgreSQL peut fournir une défense en profondeur\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">L'isolation des locataires doit inclure les caches\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Les fichiers et le stockage d'objets nécessitent leur propre frontière de locataire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">Les tâches en arrière-plan et les files d'attente peuvent briser l'isolation\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">La recherche et le RAG nécessitent une récupération tenant compte du locataire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-68\" class=\"editorjs-toc__link\">Les données dérivées héritent de la sensibilité du locataire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Tout n'appartient pas à un locataire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">Les administrateurs de plateforme nécessitent un modèle d'autorité différent\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-79\" class=\"editorjs-toc__link\">Le RBAC peut être combiné avec des attributs\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-83\" class=\"editorjs-toc__link\">Les décisions d'autorisation sont au moins bidimensionnelles\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" class=\"editorjs-toc__link\">Preuve d'implémentation originale : Aaasaasa AI CMS\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-94\" class=\"editorjs-toc__link\">Pourquoi cette distinction est encore plus importante pour les agents IA\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-98\" class=\"editorjs-toc__link\">Tester le RBAC et l'isolation des locataires séparément\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-101\" class=\"editorjs-toc__link\">Modes de défaillance courants\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-103\" class=\"editorjs-toc__link\">Idées fausses courantes\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-105\" class=\"editorjs-toc__link\">Une séquence de conception pratique\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-107\" class=\"editorjs-toc__link\">Liste de contrôle RBAC + isolation des locataires\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-109\" class=\"editorjs-toc__link\">Cas limites et limitations\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-115\" class=\"editorjs-toc__link\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-119\" class=\"editorjs-toc__link\">Connaissances canoniques associées\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-125\" class=\"editorjs-toc__link\">Questions fréquemment posées\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-127\" class=\"editorjs-toc__link\">Glossaire\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-129\" class=\"editorjs-toc__link\">Conclusion\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-133\" class=\"editorjs-toc__link\">Sources primaires et recommandations actuelles\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Ce que le RBAC contrôle réellement\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-10\">Ce que l'isolation des locataires contrôle réellement\u003C\u002Fh2>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-14\">L'exemple le plus simple\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Une décision d'autorisation multi-locataires correcte\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Authentifier le principal\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Établir qui est l'utilisateur, le service ou l'agent.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Résoudre le contexte de locataire vérifié\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Déterminer quel contexte de locataire s'applique à partir d'informations d'identité\u002Fappartenance fiables côté serveur.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Résoudre la permission\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Évaluer si le rôle ou la politique du principal autorise l'opération demandée.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Délimiter la ressource cible\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Vérifier que l'objet cible appartient au locataire autorisé ou à une portée explicitement partagée.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Appliquer à la frontière d'accès\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Effectuer l'opération sur la base de données, le cache, le stockage, la file d'attente ou le service avec les contraintes de locataire appliquées.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Auditer les deux dimensions\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Enregistrer le principal, le locataire, l'opération, la cible et le résultat afin que les tentatives inter-locataires soient visibles.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-19\">Où l'exemple simple s'arrête\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-23\">RBAC vs isolation des locataires\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Deux dimensions de sécurité différentes\u003C\u002Fh3>\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left dark:border-gray-700 dark:bg-gray-900\">\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">RBAC\u003C\u002Fth>\u003Cth class=\"border border-gray-300 bg-gray-50 px-4 py-3 text-left font-semibold dark:border-gray-700 dark:bg-gray-900\">Isolation des locataires\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Question principale\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Unité typique\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Exemple\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Défaillance typique\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Implémentation typique\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-3 text-left font-semibold dark:border-gray-700\">Peut-il exister seul ?\u003C\u002Fth>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-3 dark:border-gray-700\">\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-25\">Authentification, autorisation et isolation sont trois vérifications différentes\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Couche\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Question\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Exemple de défaillance\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Authentification\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qui est ce principal ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un attaquant usurpe l'identité d'Alice\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autorisation \u002F RBAC\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ce principal peut-il effectuer cette opération ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un lecteur peut supprimer des utilisateurs\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Isolation des locataires\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Cette opération peut-elle atteindre cette frontière de locataire\u002Fressource ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un administrateur du locataire A lit une commande du locataire B\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-28\">Les rôles ont besoin d'une portée\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-32\">Le contexte du locataire doit provenir d'un chemin de confiance\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-36\">La portée du locataire appartient à la recherche de ressource\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Recherche faible\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Recherche plus forte limitée au locataire\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">findFirst({ where: { id } })\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">findFirst({ where: { id, tenantId } })\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">UPDATE orders SET ... WHERE id = ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">UPDATE orders SET ... WHERE id = ? AND tenant_id = ?\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">cache.get('user:' + id)\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">cache.get('tenant:' + tenantId + ':user:' + id)\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-40\">Les contrôles applicatifs sont utiles, mais l'isolation ne devrait pas dépendre d'un comportement parfait des développeurs\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>La défense en profondeur peut donc déplacer l'isolation vers des middlewares partagés, des couches de dépôt\u002Fservice, 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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--success my-6 rounded-xl border p-5 border-emerald-300 bg-emerald-50 dark:border-emerald-900 dark:bg-emerald-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">L'isolation devrait être difficile à oublier\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">La frontière la plus solide est celle que le code applicatif ordinaire ne peut pas contourner facilement en omettant une seule condition \u003Ccode>tenantId\u003C\u002Fcode>.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-44\">Stratégies d'isolation de base de données\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Stratégie\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Frontière\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Force \u002F compromis\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tables partagées + clé de locataire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Politique au niveau ligne\u002Fapplicatif\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Efficace sur le plan opérationnel ; nécessite une portée de locataire exhaustive et des tests solides\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tables partagées + RLS de base de données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Frontière de politique de base de données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Réduit la dépendance à chaque requête applicative ; nécessite des rôles corrects, un contexte de locataire de session\u002Ftransaction et une couverture de politique\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Schémas séparés\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Frontière d'espace de noms \u002F rôle de base de données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Séparation logique plus forte ; complexité opérationnelle accrue\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bases de données séparées\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Frontière de base de données \u002F identifiants\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Isolation forte et rayon d'impact plus simple ; coût de provisionnement et d'exploitation plus élevé\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Infrastructure\u002Fcompte séparé\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Frontière d'infrastructure\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Séparation à gros grain la plus forte ; coût et surcharge opérationnelle les plus élevés\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Hybride\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Par charge de travail\u002Fclasse de données\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permet une isolation plus forte uniquement là où le risque\u002Fla conformité le justifie\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-47\">La sécurité au niveau des lignes de PostgreSQL peut fournir une défense en profondeur\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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\u002Fpooling utilisé en production.\u003C\u002Fp>\n\u003Cp>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\u002Frequête afin qu'une connexion mise en pool ne puisse pas divulguer l'état d'un locataire précédent.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">L'isolation des locataires doit inclure les caches\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Les fichiers et le stockage d'objets nécessitent leur propre frontière de locataire\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">Les tâches en arrière-plan et les files d'attente peuvent briser l'isolation\u003C\u002Fh2>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-63\">La recherche et le RAG nécessitent une récupération tenant compte du locataire\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Le modèle ne doit jamais être le filtre de locataire\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Ne récupérez pas de segments inter-locataires pour ensuite demander au modèle de langage de les ignorer. Une fois que des données protégées entrent dans le contexte du modèle, la frontière d'isolation a déjà échoué.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-68\">Les données dérivées héritent de la sensibilité du locataire\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-71\">Tout n'appartient pas à un locataire\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>Un objet intentionnellement partagé doit avoir une raison documentée d'être global plutôt que de simplement manquer d'une association à un locataire.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">Les administrateurs de plateforme nécessitent un modèle d'autorité différent\u003C\u002Fh2>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>L'accès inter-locataires devrait donc être une capacité nommée, et non l'absence d'un filtre de locataire.\u003C\u002Fp>\n\u003Ch2 id=\"section-79\">Le RBAC peut être combiné avec des attributs\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-83\">Les décisions d'autorisation sont au moins bidimensionnelles\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Principal\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Permission de rôle\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Relation avec le locataire\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Décision\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">orders.read\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La commande appartient au locataire d'Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autoriser\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">orders.read\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La commande appartient à un autre locataire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Refuser\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">orders.write\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La commande appartient au locataire d'Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autoriser si le rôle inclut l'écriture\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">orders.write\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La commande appartient à un autre locataire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Refuser\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Support de plateforme\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">support.cross_tenant.read\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Portée de support explicite + locataire cible audité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Potentiellement autoriser selon la politique de la plateforme\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Travailleur en arrière-plan\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">orders.process\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Portée de service de confiance pour le locataire du travail\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autoriser uniquement pour le locataire du travail vérifié\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-85\">Preuve d'implémentation originale : Aaasaasa AI CMS\u003C\u002Fh2>\n\u003Caside class=\"editorjs-callout editorjs-callout--note my-6 rounded-xl border p-5 border-gray-300 bg-gray-50 dark:border-gray-700 dark:bg-gray-900\u002F40\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Preuve d'implémentation originale\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Aaasaasa AI CMS contient une implémentation concrète de RBAC limitée au locataire. C'est une preuve utile de la façon dont l'autorisation par rôle et la portée du locataire peuvent être combinées, mais elle ne doit pas être présentée comme la preuve que chaque couche de stockage, de cache ou d'infrastructure a une isolation complète des locataires.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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\u002Fcode, et la liste des rôles est filtrée par locataire.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Modèle d'implémentation observé\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Signification de sécurité\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Codes de permission typés\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le vocabulaire des opérations RBAC est explicite\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rôles système → cartes de permissions\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les rôles agrègent les permissions plutôt que de coder en dur les utilisateurs\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identité de rôle tenantId_code\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le même rôle logique peut exister séparément par locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La recherche de rôle utilise id + tenantId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La mutation de rôle est limitée au locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La relation utilisateur-rôle stocke tenantId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'appartenance n'est pas déduite globalement du rôle seul\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La résolution des permissions utilise tenantId + userId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorisation est évaluée dans le contexte du locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Caside class=\"editorjs-callout editorjs-callout--warning my-6 rounded-xl border p-5 border-amber-300 bg-amber-50 dark:border-amber-900 dark:bg-amber-950\u002F20\" role=\"note\">\u003Cstrong class=\"block mb-2 text-gray-900 dark:text-gray-100\">Ce que ces preuves ne prouvent pas\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Le RBAC limité au locataire est une couche. L'isolation complète des locataires doit également couvrir toutes les recherches de ressources appartenant au locataire, les bases de données, les caches, les fichiers, les index de recherche\u002Fvectoriels, les tâches en arrière-plan, les intégrations et les chemins opérationnels. Les preuves du dépôt ici soutiennent le modèle de conception RBAC\u002Fportée du locataire, et non une affirmation d'isolation SaaS auditée indépendamment.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-94\">Pourquoi cette distinction est encore plus importante pour les agents IA\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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\u002Fservice\u002Fdonnées). Les instructions en langage naturel ne constituent pas une frontière d'autorisation.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-98\">Tester le RBAC et l'isolation des locataires séparément\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Famille de tests\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ce qu'elle doit prouver\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de rétrogradation de rôle\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un utilisateur sans permission ne peut pas effectuer l'opération même au sein de son propre locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test d'objet inter-locataires\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un utilisateur avec le bon rôle ne peut toujours pas accéder au même type de ressource dans un autre locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Falsification d'identifiant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La modification des ID d'objet\u002Flocataire ne franchit pas la portée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de point de terminaison de liste\u002Fen masse\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les requêtes larges ne renvoient que les données de locataire autorisées\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de réutilisation de cache\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Deux locataires utilisant des processus\u002Fconnexions réutilisés ne reçoivent jamais l'état mis en cache de l'autre\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de rôle de requête RLS\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le rôle de requête de production ne peut pas contourner les politiques de lignes\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de worker asynchrone\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le contexte du locataire survit à la mise en file d'attente et est revalidé à la consommation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de récupération vectorielle\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La requête du Locataire A ne récupère jamais les chunks du Locataire B\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test d'administrateur de plateforme\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La capacité inter-locataires est explicite, étroite et auditable\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test de désinscription\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les données du locataire et les index\u002Fcaches dérivés sont supprimés conformément à la politique\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-101\">Modes de défaillance courants\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Mode de défaillance\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Pourquoi il échoue\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Vérifier le rôle mais pas le locataire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un rôle valide devient une autorité inter-locataires\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Faire confiance à l'ID de locataire de la requête\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le client contrôle le sélecteur d'isolation\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Limiter l'interface mais pas l'API\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les boutons cachés ne protègent pas les ressources backend\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Point de terminaison de détail tenant-aware, point de terminaison de liste non limité\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les lectures en masse fuient vers d'autres locataires\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Filtre de locataire dans la plupart des requêtes\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un chemin oublié brise la frontière\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Clés de cache globales\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'isolation correcte de la base de données est contournée par les données mises en cache\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Index vectoriel partagé sans filtres de métadonnées appliqués\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le RAG récupère les chunks d'un autre locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ID de locataire du message de file d'attente traité comme autorisation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Une tâche forgée ou mal produite peut franchir la frontière du locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Administrateur de plateforme modélisé comme ADMIN ordinaire\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le pouvoir inter-locataires devient implicite et difficile à auditer\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Rôle copié globalement à travers les appartenances de locataires\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'utilisateur reçoit des permissions dans des locataires où il n'a jamais été assigné\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Bases de données séparées mais identifiant privilégié partagé\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'application peut toujours traverser les bases de données si son identifiant est trop large\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RLS avec rôle de requête BYPASSRLS\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La politique de base de données existe mais ne protège pas le chemin de requête réel\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">UUID aléatoires traités comme isolation\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les identifiants difficiles à deviner réduisent l'énumération mais n'autorisent pas l'accès\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-103\">Idées fausses courantes\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Idée fausse\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Correction\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Le RBAC fournit l'isolation des locataires. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le RBAC contrôle les permissions ; l'isolation nécessite également une portée de locataire\u002Fressource.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Si l'utilisateur est un administrateur, les vérifications de locataire sont inutiles. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorité d'administrateur doit toujours avoir une portée explicite.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« L'ID de locataire dans le JWT suffit. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">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é.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Des bases de données séparées suppriment les exigences d'autorisation. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les utilisateurs ont toujours besoin de permissions au niveau des opérations au sein de leur locataire.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Une colonne tenant_id signifie que le système est isolé. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le champ n'aide que si les chemins d'accès l'appliquent.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Les UUID empêchent l'accès inter-locataires. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les identifiants imprévisibles sont une défense en profondeur, pas une autorisation.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« RLS signifie que le code applicatif n'a pas besoin de contrôles de sécurité. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorisation applicative, les rôles DB corrects et la couverture des politiques restent importants.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Une seule base de données vectorielle partagée est dangereuse. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Elle peut être sûre si l'isolation est applicable et vérifiée ; la séparation physique est une option, pas la seule.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Le support de plateforme a besoin d'un ADMIN global. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le support inter-locataires devrait être une autorité distincte, contrainte et auditable.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">« Les services internes peuvent ignorer les vérifications de locataire. »\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les chemins internes peuvent toujours être compromis ou mal configurés et doivent préserver le contexte du locataire.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-105\">Une séquence de conception pratique\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Concevoir les permissions et l'isolation comme des dimensions séparées\u003C\u002Fh3>\u003Cdiv class=\"grid grid-cols-1 md:grid-cols-2 xl:grid-cols-3 gap-4\">\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">1\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">1. Définir la propriété du locataire\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Classer quelles entités et ressources sont globales, limitées au locataire, limitées à l'utilisateur ou intentionnellement inter-locataires.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">2\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">2. Définir les opérations\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Créer des permissions explicites pour les lectures, écritures, publications, approbations, administration et autres actions métier.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">3\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">3. Définir les rôles\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Regrouper les permissions selon les responsabilités sans intégrer de portée globale accidentelle.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">4\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">4. Définir la portée de l'appartenance\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Lier les attributions de rôle au contexte de locataire\u002Fespace de travail\u002Fprojet dans lequel elles s'appliquent.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">5\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">5. Résoudre le contexte de locataire de confiance\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Dériver l'identité du locataire à partir d'une appartenance authentifiée et vérifiée par le serveur ou d'une autorisation de service.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">6\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">6. Appliquer la propriété des ressources\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Appliquer la portée du locataire à chaque frontière de données\u002Fservice appartenant au locataire.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">7\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">7. Ajouter une défense en profondeur\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Utiliser RLS, des identifiants séparés, des schémas\u002Fbases de données, des politiques de stockage ou des moteurs de politiques là où le risque le justifie.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">8\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">8. Transmettre la portée à travers les systèmes dérivés\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Préserver les métadonnées du locataire dans le cache, la recherche, les index vectoriels, les files d'attente, les fichiers et l'analytique.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">9\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">9. Modéliser explicitement les opérations inter-locataires\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Séparer l'administration de la plateforme et les identités de service des rôles ordinaires de locataire.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">10\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">10. Tester les deux axes\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Exécuter des tests négatifs pour la permission manquante et pour le mauvais locataire indépendamment.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">11\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">11. Auditer le locataire + la permission ensemble\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Journaliser qui a agi, dans quel locataire, sur quelle cible et sous quelle autorité.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv class=\"editorjs-process__step min-w-0  rounded-xl border border-gray-200 dark:border-gray-700 p-4\">\u003Cdiv class=\"text-xs font-semibold text-gray-500 dark:text-gray-400\">12\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 font-semibold text-gray-900 dark:text-gray-100\">12. Re-tester après les changements de schéma\u002Fruntime\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">L'isolation peut se briser lorsque de nouvelles tables, caches, files d'attente ou chemins de récupération sont introduits.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-107\">Liste de contrôle RBAC + isolation des locataires\u003C\u002Fh2>\n\u003Cdiv class=\"overflow-x-auto\">\u003Ctable class=\"w-full border-collapse\">\u003Cthead>\u003Ctr>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Question\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Réponse attendue\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qui est le principal ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identité d'utilisateur\u002Fservice\u002Fagent authentifiée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quel contexte de locataire s'applique ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Appartenance vérifiée par le serveur ou portée de service\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quelle opération est demandée ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permission typée ou action de politique\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le principal a-t-il cette permission ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision de rôle\u002Fpolitique\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Qui possède la ressource cible ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Classification explicite locataire\u002Fglobal\u002Futilisateur\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La portée de la ressource correspond-elle à l'autorité ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Recherche\u002Fpolitique tenant-aware\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le stockage peut-il contourner les vérifications applicatives ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Décision de défense en profondeur documentée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les caches sont-ils sûrs pour les locataires ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les clés\u002Fespaces de noms et l'autorisation préservent la portée du locataire\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les fichiers\u002Fblobs sont-ils sûrs pour les locataires ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La politique d'objet et l'émission d'URL signées appliquent la portée\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les tâches asynchrones sont-elles sûres pour les locataires ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le contexte vérifié se propage et est revalidé\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le RAG\u002Frecherche est-il sûr pour les locataires ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'isolation des métadonnées\u002Fcollections est appliquée avant le contexte du modèle\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les administrateurs inter-locataires sont-ils explicites ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autorité, contrôles et audit séparés\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les identifiants ordinaires peuvent-ils contourner l'isolation ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Non, ou chemin exceptionnel étroitement documenté\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Les tests négatifs inter-locataires sont-ils automatisés ?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Oui pour chaque couche d'accès pertinente\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-109\">Cas limites et limitations\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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ë.\u003C\u002Fp>\n\u003Cp>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é.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-115\">Qu'est-ce qui changerait cette réponse ?\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-119\">Connaissances canoniques associées\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fde\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">MCP vs A2A vs UCP vs AP2 vs A2UI : la pile de protocoles d'agents expliquée\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">L'interopérabilité des protocoles ne remplace pas l'autorisation ou l'isolation des tenants. La découverte des capacités et l'autorité métier restent des préoccupations architecturales distinctes.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Lire l'article sur la pile de protocoles →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>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.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\" class=\"flex flex-col sm:flex-row gap-4 rounded-xl border border-gray-200 dark:border-gray-700 p-4 transition hover:border-primary-500\">\u003Cdiv class=\"min-w-0 flex-1\">\u003Cstrong class=\"block text-lg text-gray-900 dark:text-gray-100\">Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">La base de récupération pour comprendre où le filtrage des sources conscient du tenant et l'isolation du magasin vectoriel doivent être appliqués.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Lire les fondements du RAG →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-125\">Questions fréquemment posées\u003C\u002Fh2>\n\u003Csection class=\"editorjs-faq my-6 rounded-xl border border-gray-200 p-5 dark:border-gray-700\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">FAQ RBAC vs isolation des tenants\u003C\u002Fh3>\u003Cdiv id=\"faq1\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Quelle est la différence entre RBAC et l'isolation des tenants ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Le RBAC détermine quelles opérations un principal peut effectuer. L'isolation des tenants détermine à quelles ressources de quel tenant ces opérations peuvent accéder. Les applications multi-tenants sécurisées ont normalement besoin des deux.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq2\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Un rôle ADMIN permet-il automatiquement l'accès à tous les tenants ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. ADMIN doit avoir une portée explicite. Un administrateur de tenant a normalement des permissions étendues uniquement à l'intérieur de ce tenant, tandis que l'administration de la plateforme inter-tenants doit être modélisée séparément.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq3\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">L'authentification suffit-elle pour l'isolation des tenants ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non. L'authentification prouve l'identité. L'autorisation contrôle les actions permises. L'isolation des tenants empêche en outre ces actions d'atteindre les ressources du mauvais tenant.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq4\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Le tenantId doit-il être stocké dans le JWT ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Il peut être une entrée pour le contexte du tenant, mais le serveur doit vérifier l'appartenance ou l'autorité actuelle et appliquer la portée aux frontières des ressources protégées. Une revendication seule ne remplace pas les contrôles d'isolation.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq5\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Ai-je besoin d'une base de données séparée par tenant ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Pas nécessairement. Les modèles d'isolation par table partagée, RLS, schéma, base de données, infrastructure et hybride peuvent tous être valides selon les risques et les exigences opérationnelles.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq6\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Le RLS PostgreSQL peut-il remplacer les filtres de tenant dans le code applicatif ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Le RLS peut fournir une solide défense en profondeur, mais des rôles de base de données corrects, un contexte de requête, une couverture des politiques et une autorisation au niveau applicatif restent importants.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq7\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Comment le RAG doit-il appliquer l'isolation des tenants ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">La portée du tenant ou de l'accès doit être appliquée lors de la récupération afin que les fragments non autorisés n'entrent jamais dans le contexte du modèle. Préservez les métadonnées d'accès tout au long du découpage et de l'indexation.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq8\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Un utilisateur peut-il avoir différents rôles dans différents tenants ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Oui. C'est courant dans le SaaS B2B et c'est une raison forte pour limiter les attributions de rôles par appartenance au tenant plutôt que de traiter les rôles comme globalement attachés à l'utilisateur.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cdiv id=\"faq9\" class=\"border-t border-gray-200 py-4 first:border-t-0 dark:border-gray-700\">\u003Ch4 class=\"font-semibold text-gray-900 dark:text-gray-100\">Quel est le meilleur test pour l'isolation des tenants ?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Utilisez des tests négatifs inter-tenants : créez au moins deux tenants, donnez à un utilisateur des permissions valides dans un tenant, puis prouvez que chaque chemin protégé refuse l'accès aux ressources de l'autre tenant.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-127\">Glossaire\u003C\u002Fh2>\n\u003Csection class=\"editorjs-glossary my-6 rounded-xl border border-gray-200 dark:border-gray-700 p-5\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Termes clés de la sécurité multi-tenant\u003C\u002Fh3>\u003Cdl>\u003Cdiv id=\"rbac\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">RBAC\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"tenant\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Tenant\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un client, une organisation, un espace de travail ou tout autre consommateur logique isolé d'un système multi-tenant partagé.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"tenant-isolation\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Isolation des tenants\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">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é.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"authentication\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Authentification\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Vérification de l'identité d'un utilisateur, d'un service ou d'un autre principal.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"authorization\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Autorisation\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Processus de décision qui détermine si un principal peut effectuer une opération demandée sur une ressource.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"permission\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Permission\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Une opération ou capacité autorisée définie, telle que orders.read ou users.write.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"role\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Rôle\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un regroupement nommé de permissions associé à une responsabilité ou une fonction.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"abac\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">ABAC\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"row-level-security\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Sécurité au niveau des lignes\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"cross-tenant-access\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Accès inter-tenant\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Tout chemin d'accès dans lequel un principal opérant dans un contexte de tenant atteint des ressources appartenant à un autre tenant.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"platform-administrator\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Administrateur de plateforme\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Une identité opérationnelle privilégiée avec une autorité explicitement modélisée qui peut s'étendre sur plusieurs tenants.\u003C\u002Fdd>\u003C\u002Fdiv>\u003Cdiv id=\"tenant-context\" class=\"border-t border-gray-200 dark:border-gray-700 py-3 first:border-t-0\">\u003Cdt class=\"font-semibold text-gray-900 dark:text-gray-100\">Contexte de tenant\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">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.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-129\">Conclusion\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"section-133\">Sources primaires et recommandations actuelles\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ca href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fprojects\u002Frole-based-access-control\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST — Contrôle d'accès basé sur les rôles\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Aperçu NIST des modèles RBAC et de la norme INCITS RBAC, incluant les utilisateurs, rôles, permissions, opérations et objets.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Frole_based_access_control\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">NIST CSRC — Glossaire RBAC\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Dé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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwhitepapers\u002Flatest\u002Fsaas-tenant-isolation-strategies\u002Fthe-isolation-mindset.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS — L'état d'esprit d'isolation\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations AWS SaaS distinguant explicitement l'authentification\u002Fautorisation de l'isolation des tenants et recommandant des mécanismes d'isolation partagés.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fsaas-multitenant-api-access-authorization\u002Ffaq.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS — FAQ sur l'autorisation multi-tenant\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations actuelles expliquant la différence entre l'autorisation et l'isolation des tenants dans les applications SaaS.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fsaas-multitenant-api-access-authorization\u002Favp-design-considerations.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">AWS — Considérations de conception multi-tenant\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations SaaS actuelles distinguant l'isolation des tenants de l'autorisation et discutant des modèles de politique d'autorisation mutualisés\u002Fisolés.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FMulti_Tenant_Security_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">OWASP — Aide-mémoire sur la sécurité des applications multi-tenant\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations 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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FRAG_Security_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">OWASP — Aide-mémoire sur la sécurité RAG\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations 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.\u003C\u002Fp>\u003C\u002Fa>\n\u003Ca href=\"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FAuthorization_Regression_Testing_Cheat_Sheet.html\" target=\"_blank\" rel=\"noopener noreferrer\" class=\"editorjs-link-tool block border border-gray-200 dark:border-gray-700 rounded-lg p-4 transition text-gray-900 dark:text-gray-100 hover:border-primary-500 hover:bg-primary-50 dark:hover:bg-gray-900 hover:text-gray-900 dark:hover:text-gray-100\">\u003Cstrong class=\"block font-semibold\">OWASP — Tests de régression d'autorisation\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Recommandations de test actuelles incluant les tests de rétrogradation de rôle et de frontière inter-tenant.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1410},1791485361496,[214,220,228,235,242,250,255,260,265,270,275,280,285,290,295,300,305,310,336,341,346,351,356,361,401,406,426,431,436,441,446,451,456,461,466,471,476,481,498,503,508,513,518,525,530,563,568,573,578,583,588,593,598,603,608,613,618,623,628,633,638,643,648,653,658,663,668,674,679,684,689,694,699,704,709,714,719,724,729,734,739,744,749,754,786,791,797,802,807,812,817,822,848,854,859,864,869,874,879,917,922,927,974,979,1017,1022,1064,1069,1118,1123,1128,1133,1138,1143,1148,1153,1158,1163,1168,1173,1178,1183,1192,1197,1205,1210,1252,1257,1307,1312,1317,1322,1327,1332,1337,1347,1356,1365,1374,1383,1392,1401],{"id":215,"data":216,"type":218,"tunes":219},"intro",{"text":217},"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.","paragraph",{},{"id":221,"data":222,"type":226,"tunes":227},"direct",{"body":223,"title":224,"variant":225},"\u003Cstrong>RBAC répond à « que peut faire cette identité ? » L'isolation des locataires répond à « à l'intérieur de quelle frontière peut-elle le faire ? »\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Une application multi-locataires sécurisée a normalement besoin des deux. Un administrateur de locataire peut disposer de permissions étendues, mais ces permissions doivent rester limitées au locataire de l'administrateur, sauf s'il existe une autorité explicitement distincte au niveau de la plateforme.","Réponse directe","info","callout",{},{"id":229,"data":230,"type":226,"tunes":234},"boundary",{"body":231,"title":232,"variant":233},"Attribuer à un utilisateur le rôle \u003Ccode>ADMIN\u003C\u002Fcode> n'implique pas automatiquement « administrateur du locataire A uniquement ». Le rôle doit être évalué conjointement avec le contexte de locataire vérifié et la propriété du locataire de la ressource cible. Sinon, un rôle valide peut devenir un privilège inter-locataires.","Un rôle n'est pas une frontière de locataire","warning",{},{"id":236,"data":237,"type":226,"tunes":241},"current",{"body":238,"title":239,"variant":240},"La distinction sous-jacente est stable. Le NIST définit le RBAC autour des utilisateurs, des rôles, des permissions, des opérations et des objets. Les recommandations actuelles d'AWS pour le SaaS indiquent explicitement que l'authentification et l'autorisation ne sont pas équivalentes à l'isolation des locataires, et qu'un utilisateur peut être authentifié et autorisé tout en accédant aux ressources d'un autre locataire si l'isolation n'est pas appliquée séparément. Les recommandations actuelles de l'OWASP sur la sécurité multi-locataires considèrent également l'isolation des locataires comme une exigence transversale couvrant les API, les bases de données, les caches, le stockage, les files d'attente et d'autres ressources partagées.","Note sur les sources actuelles — 8 octobre 2026","note",{},{"id":243,"data":244,"type":248,"tunes":249},"toc",{"title":245,"maxLevel":246,"minLevel":247},"Sommaire",3,2,"tableOfContents",{},{"id":251,"data":252,"type":42,"tunes":254},"h-meaning",{"text":253,"level":247},"Ce que le RBAC contrôle réellement",{},{"id":256,"data":257,"type":218,"tunes":259},"p-rbac-1",{"text":258},"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.",{},{"id":261,"data":262,"type":218,"tunes":264},"p-rbac-2",{"text":263},"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.",{},{"id":266,"data":267,"type":218,"tunes":269},"p-rbac-3",{"text":268},"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.",{},{"id":271,"data":272,"type":42,"tunes":274},"h-tenant",{"text":273,"level":247},"Ce que l'isolation des locataires contrôle réellement",{},{"id":276,"data":277,"type":218,"tunes":279},"p-tenant-1",{"text":278},"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é.",{},{"id":281,"data":282,"type":218,"tunes":284},"p-tenant-2",{"text":283},"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.",{},{"id":286,"data":287,"type":218,"tunes":289},"p-tenant-3",{"text":288},"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.",{},{"id":291,"data":292,"type":42,"tunes":294},"h-simple",{"text":293,"level":247},"L'exemple le plus simple",{},{"id":296,"data":297,"type":218,"tunes":299},"p-simple-1",{"text":298},"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.",{},{"id":301,"data":302,"type":218,"tunes":304},"p-simple-2",{"text":303},"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.",{},{"id":306,"data":307,"type":218,"tunes":309},"p-simple-3",{"text":308},"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é.",{},{"id":311,"data":312,"type":334,"tunes":335},"simple-flow",{"steps":313,"title":332,"orientation":333},[314,317,320,323,326,329],{"label":315,"description":316},"1. Authentifier le principal","Établir qui est l'utilisateur, le service ou l'agent.",{"label":318,"description":319},"2. Résoudre le contexte de locataire vérifié","Déterminer quel contexte de locataire s'applique à partir d'informations d'identité\u002Fappartenance fiables côté serveur.",{"label":321,"description":322},"3. Résoudre la permission","Évaluer si le rôle ou la politique du principal autorise l'opération demandée.",{"label":324,"description":325},"4. Délimiter la ressource cible","Vérifier que l'objet cible appartient au locataire autorisé ou à une portée explicitement partagée.",{"label":327,"description":328},"5. Appliquer à la frontière d'accès","Effectuer l'opération sur la base de données, le cache, le stockage, la file d'attente ou le service avec les contraintes de locataire appliquées.",{"label":330,"description":331},"6. Auditer les deux dimensions","Enregistrer le principal, le locataire, l'opération, la cible et le résultat afin que les tentatives inter-locataires soient visibles.","Une décision d'autorisation multi-locataires correcte","auto","processFlow",{},{"id":337,"data":338,"type":42,"tunes":340},"h-stops",{"text":339,"level":247},"Où l'exemple simple s'arrête",{},{"id":342,"data":343,"type":218,"tunes":345},"p-stops-1",{"text":344},"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.",{},{"id":347,"data":348,"type":218,"tunes":350},"p-stops-2",{"text":349},"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.",{},{"id":352,"data":353,"type":218,"tunes":355},"p-stops-3",{"text":354},"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.",{},{"id":357,"data":358,"type":42,"tunes":360},"h-compare",{"text":359,"level":247},"RBAC vs isolation des locataires",{},{"id":362,"data":363,"type":399,"tunes":400},"core-comparison",{"rows":364,"title":390,"layout":391,"columns":392},[365,370,374,378,382,386],{"id":366,"label":367,"values":368},"question","Question principale",[369,369],"",{"id":371,"label":372,"values":373},"unit","Unité typique",[369,369],{"id":375,"label":376,"values":377},"example","Exemple",[369,369],{"id":379,"label":380,"values":381},"failure","Défaillance typique",[369,369],{"id":383,"label":384,"values":385},"implementation","Implémentation typique",[369,369],{"id":387,"label":388,"values":389},"scope","Peut-il exister seul ?",[369,369],"Deux dimensions de sécurité différentes","table",[393,396],{"id":394,"label":395},"rbac","RBAC",{"id":397,"label":398},"tenant","Isolation des locataires","comparison",{},{"id":402,"data":403,"type":42,"tunes":405},"h-authn",{"text":404,"level":247},"Authentification, autorisation et isolation sont trois vérifications différentes",{},{"id":407,"data":408,"type":391,"tunes":425},"three-checks",{"content":409,"stretched":43,"withHeadings":14},[410,414,418,422],[411,412,413],"Couche","Question","Exemple de défaillance",[415,416,417],"Authentification","Qui est ce principal ?","Un attaquant usurpe l'identité d'Alice",[419,420,421],"Autorisation \u002F RBAC","Ce principal peut-il effectuer cette opération ?","Un lecteur peut supprimer des utilisateurs",[398,423,424],"Cette opération peut-elle atteindre cette frontière de locataire\u002Fressource ?","Un administrateur du locataire A lit une commande du locataire B",{},{"id":427,"data":428,"type":218,"tunes":430},"p-authn-1",{"text":429},"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.",{},{"id":432,"data":433,"type":42,"tunes":435},"h-role-scope",{"text":434,"level":247},"Les rôles ont besoin d'une portée",{},{"id":437,"data":438,"type":218,"tunes":440},"p-role-scope-1",{"text":439},"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.",{},{"id":442,"data":443,"type":218,"tunes":445},"p-role-scope-2",{"text":444},"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.",{},{"id":447,"data":448,"type":218,"tunes":450},"p-role-scope-3",{"text":449},"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.",{},{"id":452,"data":453,"type":42,"tunes":455},"h-context",{"text":454,"level":247},"Le contexte du locataire doit provenir d'un chemin de confiance",{},{"id":457,"data":458,"type":218,"tunes":460},"p-context-1",{"text":459},"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.",{},{"id":462,"data":463,"type":218,"tunes":465},"p-context-2",{"text":464},"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.",{},{"id":467,"data":468,"type":218,"tunes":470},"p-context-3",{"text":469},"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.",{},{"id":472,"data":473,"type":42,"tunes":475},"h-query",{"text":474,"level":247},"La portée du locataire appartient à la recherche de ressource",{},{"id":477,"data":478,"type":218,"tunes":480},"p-query-1",{"text":479},"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.",{},{"id":482,"data":483,"type":391,"tunes":497},"query-table",{"content":484,"stretched":43,"withHeadings":14},[485,488,491,494],[486,487],"Recherche faible","Recherche plus forte limitée au locataire",[489,490],"findFirst({ where: { id } })","findFirst({ where: { id, tenantId } })",[492,493],"UPDATE orders SET ... WHERE id = ?","UPDATE orders SET ... WHERE id = ? AND tenant_id = ?",[495,496],"cache.get('user:' + id)","cache.get('tenant:' + tenantId + ':user:' + id)",{},{"id":499,"data":500,"type":218,"tunes":502},"p-query-2",{"text":501},"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.",{},{"id":504,"data":505,"type":42,"tunes":507},"h-defense",{"text":506,"level":247},"Les contrôles applicatifs sont utiles, mais l'isolation ne devrait pas dépendre d'un comportement parfait des développeurs",{},{"id":509,"data":510,"type":218,"tunes":512},"p-defense-1",{"text":511},"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.",{},{"id":514,"data":515,"type":218,"tunes":517},"p-defense-2",{"text":516},"La défense en profondeur peut donc déplacer l'isolation vers des middlewares partagés, des couches de dépôt\u002Fservice, 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.",{},{"id":519,"data":520,"type":226,"tunes":524},"defense-rule",{"body":521,"title":522,"variant":523},"La frontière la plus solide est celle que le code applicatif ordinaire ne peut pas contourner facilement en omettant une seule condition \u003Ccode>tenantId\u003C\u002Fcode>.","L'isolation devrait être difficile à oublier","success",{},{"id":526,"data":527,"type":42,"tunes":529},"h-db",{"text":528,"level":247},"Stratégies d'isolation de base de données",{},{"id":531,"data":532,"type":391,"tunes":562},"db-table",{"content":533,"stretched":43,"withHeadings":14},[534,538,542,546,550,554,558],[535,536,537],"Stratégie","Frontière","Force \u002F compromis",[539,540,541],"Tables partagées + clé de locataire","Politique au niveau ligne\u002Fapplicatif","Efficace sur le plan opérationnel ; nécessite une portée de locataire exhaustive et des tests solides",[543,544,545],"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\u002Ftransaction et une couverture de politique",[547,548,549],"Schémas séparés","Frontière d'espace de noms \u002F rôle de base de données","Séparation logique plus forte ; complexité opérationnelle accrue",[551,552,553],"Bases de données séparées","Frontière de base de données \u002F identifiants","Isolation forte et rayon d'impact plus simple ; coût de provisionnement et d'exploitation plus élevé",[555,556,557],"Infrastructure\u002Fcompte séparé","Frontière d'infrastructure","Séparation à gros grain la plus forte ; coût et surcharge opérationnelle les plus élevés",[559,560,561],"Hybride","Par charge de travail\u002Fclasse de données","Permet une isolation plus forte uniquement là où le risque\u002Fla conformité le justifie",{},{"id":564,"data":565,"type":218,"tunes":567},"p-db-1",{"text":566},"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.",{},{"id":569,"data":570,"type":42,"tunes":572},"h-rls",{"text":571,"level":247},"La sécurité au niveau des lignes de PostgreSQL peut fournir une défense en profondeur",{},{"id":574,"data":575,"type":218,"tunes":577},"p-rls-1",{"text":576},"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.",{},{"id":579,"data":580,"type":218,"tunes":582},"p-rls-2",{"text":581},"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\u002Fpooling utilisé en production.",{},{"id":584,"data":585,"type":218,"tunes":587},"p-rls-3",{"text":586},"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\u002Frequête afin qu'une connexion mise en pool ne puisse pas divulguer l'état d'un locataire précédent.",{},{"id":589,"data":590,"type":42,"tunes":592},"h-cache",{"text":591,"level":247},"L'isolation des locataires doit inclure les caches",{},{"id":594,"data":595,"type":218,"tunes":597},"p-cache-1",{"text":596},"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.",{},{"id":599,"data":600,"type":218,"tunes":602},"p-cache-2",{"text":601},"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.",{},{"id":604,"data":605,"type":218,"tunes":607},"p-cache-3",{"text":606},"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é.",{},{"id":609,"data":610,"type":42,"tunes":612},"h-storage",{"text":611,"level":247},"Les fichiers et le stockage d'objets nécessitent leur propre frontière de locataire",{},{"id":614,"data":615,"type":218,"tunes":617},"p-storage-1",{"text":616},"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.",{},{"id":619,"data":620,"type":218,"tunes":622},"p-storage-2",{"text":621},"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.",{},{"id":624,"data":625,"type":218,"tunes":627},"p-storage-3",{"text":626},"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.",{},{"id":629,"data":630,"type":42,"tunes":632},"h-queues",{"text":631,"level":247},"Les tâches en arrière-plan et les files d'attente peuvent briser l'isolation",{},{"id":634,"data":635,"type":218,"tunes":637},"p-queue-1",{"text":636},"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é.",{},{"id":639,"data":640,"type":218,"tunes":642},"p-queue-2",{"text":641},"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.",{},{"id":644,"data":645,"type":218,"tunes":647},"p-queue-3",{"text":646},"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.",{},{"id":649,"data":650,"type":42,"tunes":652},"h-search",{"text":651,"level":247},"La recherche et le RAG nécessitent une récupération tenant compte du locataire",{},{"id":654,"data":655,"type":218,"tunes":657},"p-search-1",{"text":656},"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.",{},{"id":659,"data":660,"type":218,"tunes":662},"p-search-2",{"text":661},"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.",{},{"id":664,"data":665,"type":218,"tunes":667},"p-search-3",{"text":666},"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.",{},{"id":669,"data":670,"type":226,"tunes":673},"rag-rule",{"body":671,"title":672,"variant":233},"Ne récupérez pas de segments inter-locataires pour ensuite demander au modèle de langage de les ignorer. Une fois que des données protégées entrent dans le contexte du modèle, la frontière d'isolation a déjà échoué.","Le modèle ne doit jamais être le filtre de locataire",{},{"id":675,"data":676,"type":42,"tunes":678},"h-derived",{"text":677,"level":247},"Les données dérivées héritent de la sensibilité du locataire",{},{"id":680,"data":681,"type":218,"tunes":683},"p-derived-1",{"text":682},"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.",{},{"id":685,"data":686,"type":218,"tunes":688},"p-derived-2",{"text":687},"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.",{},{"id":690,"data":691,"type":42,"tunes":693},"h-shared",{"text":692,"level":247},"Tout n'appartient pas à un locataire",{},{"id":695,"data":696,"type":218,"tunes":698},"p-shared-1",{"text":697},"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.",{},{"id":700,"data":701,"type":218,"tunes":703},"p-shared-2",{"text":702},"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.",{},{"id":705,"data":706,"type":218,"tunes":708},"p-shared-3",{"text":707},"Un objet intentionnellement partagé doit avoir une raison documentée d'être global plutôt que de simplement manquer d'une association à un locataire.",{},{"id":710,"data":711,"type":42,"tunes":713},"h-platform-admin",{"text":712,"level":247},"Les administrateurs de plateforme nécessitent un modèle d'autorité différent",{},{"id":715,"data":716,"type":218,"tunes":718},"p-platform-1",{"text":717},"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é.",{},{"id":720,"data":721,"type":218,"tunes":723},"p-platform-2",{"text":722},"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.",{},{"id":725,"data":726,"type":218,"tunes":728},"p-platform-3",{"text":727},"L'accès inter-locataires devrait donc être une capacité nommée, et non l'absence d'un filtre de locataire.",{},{"id":730,"data":731,"type":42,"tunes":733},"h-abac",{"text":732,"level":247},"Le RBAC peut être combiné avec des attributs",{},{"id":735,"data":736,"type":218,"tunes":738},"p-abac-1",{"text":737},"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.",{},{"id":740,"data":741,"type":218,"tunes":743},"p-abac-2",{"text":742},"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.",{},{"id":745,"data":746,"type":218,"tunes":748},"p-abac-3",{"text":747},"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.",{},{"id":750,"data":751,"type":42,"tunes":753},"h-matrix",{"text":752,"level":247},"Les décisions d'autorisation sont au moins bidimensionnelles",{},{"id":755,"data":756,"type":391,"tunes":785},"matrix-table",{"content":757,"stretched":43,"withHeadings":14},[758,763,768,771,774,775,780],[759,760,761,762],"Principal","Permission de rôle","Relation avec le locataire","Décision",[764,765,766,767],"Alice","orders.read","La commande appartient au locataire d'Alice","Autoriser",[764,765,769,770],"La commande appartient à un autre locataire","Refuser",[764,772,766,773],"orders.write","Autoriser si le rôle inclut l'écriture",[764,772,769,770],[776,777,778,779],"Support de plateforme","support.cross_tenant.read","Portée de support explicite + locataire cible audité","Potentiellement autoriser selon la politique de la plateforme",[781,782,783,784],"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é",{},{"id":787,"data":788,"type":42,"tunes":790},"h-implementation",{"text":789,"level":247},"Preuve d'implémentation originale : Aaasaasa AI CMS",{},{"id":792,"data":793,"type":226,"tunes":796},"impl-note",{"body":794,"title":795,"variant":240},"Aaasaasa AI CMS contient une implémentation concrète de RBAC limitée au locataire. C'est une preuve utile de la façon dont l'autorisation par rôle et la portée du locataire peuvent être combinées, mais elle ne doit pas être présentée comme la preuve que chaque couche de stockage, de cache ou d'infrastructure a une isolation complète des locataires.","Preuve d'implémentation originale",{},{"id":798,"data":799,"type":218,"tunes":801},"p-impl-1",{"text":800},"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.",{},{"id":803,"data":804,"type":218,"tunes":806},"p-impl-2",{"text":805},"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\u002Fcode, et la liste des rôles est filtrée par locataire.",{},{"id":808,"data":809,"type":218,"tunes":811},"p-impl-3",{"text":810},"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.",{},{"id":813,"data":814,"type":218,"tunes":816},"p-impl-4",{"text":815},"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.",{},{"id":818,"data":819,"type":218,"tunes":821},"p-impl-5",{"text":820},"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.",{},{"id":823,"data":824,"type":391,"tunes":847},"impl-table",{"content":825,"stretched":43,"withHeadings":14},[826,829,832,835,838,841,844],[827,828],"Modèle d'implémentation observé","Signification de sécurité",[830,831],"Codes de permission typés","Le vocabulaire des opérations RBAC est explicite",[833,834],"Rôles système → cartes de permissions","Les rôles agrègent les permissions plutôt que de coder en dur les utilisateurs",[836,837],"Identité de rôle tenantId_code","Le même rôle logique peut exister séparément par locataire",[839,840],"La recherche de rôle utilise id + tenantId","La mutation de rôle est limitée au locataire",[842,843],"La relation utilisateur-rôle stocke tenantId","L'appartenance n'est pas déduite globalement du rôle seul",[845,846],"La résolution des permissions utilise tenantId + userId","L'autorisation est évaluée dans le contexte du locataire",{},{"id":849,"data":850,"type":226,"tunes":853},"impl-boundary",{"body":851,"title":852,"variant":233},"Le RBAC limité au locataire est une couche. L'isolation complète des locataires doit également couvrir toutes les recherches de ressources appartenant au locataire, les bases de données, les caches, les fichiers, les index de recherche\u002Fvectoriels, les tâches en arrière-plan, les intégrations et les chemins opérationnels. Les preuves du dépôt ici soutiennent le modèle de conception RBAC\u002Fportée du locataire, et non une affirmation d'isolation SaaS auditée indépendamment.","Ce que ces preuves ne prouvent pas",{},{"id":855,"data":856,"type":42,"tunes":858},"h-ai",{"text":857,"level":247},"Pourquoi cette distinction est encore plus importante pour les agents IA",{},{"id":860,"data":861,"type":218,"tunes":863},"p-ai-1",{"text":862},"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.",{},{"id":865,"data":866,"type":218,"tunes":868},"p-ai-2",{"text":867},"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\u002Fservice\u002Fdonnées). Les instructions en langage naturel ne constituent pas une frontière d'autorisation.",{},{"id":870,"data":871,"type":218,"tunes":873},"p-ai-3",{"text":872},"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.",{},{"id":875,"data":876,"type":42,"tunes":878},"h-tests",{"text":877,"level":247},"Tester le RBAC et l'isolation des locataires séparément",{},{"id":880,"data":881,"type":391,"tunes":916},"tests-table",{"content":882,"stretched":43,"withHeadings":14},[883,886,889,892,895,898,901,904,907,910,913],[884,885],"Famille de tests","Ce qu'elle doit prouver",[887,888],"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",[890,891],"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",[893,894],"Falsification d'identifiant","La modification des ID d'objet\u002Flocataire ne franchit pas la portée",[896,897],"Test de point de terminaison de liste\u002Fen masse","Les requêtes larges ne renvoient que les données de locataire autorisées",[899,900],"Test de réutilisation de cache","Deux locataires utilisant des processus\u002Fconnexions réutilisés ne reçoivent jamais l'état mis en cache de l'autre",[902,903],"Test de rôle de requête RLS","Le rôle de requête de production ne peut pas contourner les politiques de lignes",[905,906],"Test de worker asynchrone","Le contexte du locataire survit à la mise en file d'attente et est revalidé à la consommation",[908,909],"Test de récupération vectorielle","La requête du Locataire A ne récupère jamais les chunks du Locataire B",[911,912],"Test d'administrateur de plateforme","La capacité inter-locataires est explicite, étroite et auditable",[914,915],"Test de désinscription","Les données du locataire et les index\u002Fcaches dérivés sont supprimés conformément à la politique",{},{"id":918,"data":919,"type":218,"tunes":921},"p-tests-1",{"text":920},"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.",{},{"id":923,"data":924,"type":42,"tunes":926},"h-failures",{"text":925,"level":247},"Modes de défaillance courants",{},{"id":928,"data":929,"type":391,"tunes":973},"failures-table",{"content":930,"stretched":43,"withHeadings":14},[931,934,937,940,943,946,949,952,955,958,961,964,967,970],[932,933],"Mode de défaillance","Pourquoi il échoue",[935,936],"Vérifier le rôle mais pas le locataire","Un rôle valide devient une autorité inter-locataires",[938,939],"Faire confiance à l'ID de locataire de la requête","Le client contrôle le sélecteur d'isolation",[941,942],"Limiter l'interface mais pas l'API","Les boutons cachés ne protègent pas les ressources backend",[944,945],"Point de terminaison de détail tenant-aware, point de terminaison de liste non limité","Les lectures en masse fuient vers d'autres locataires",[947,948],"Filtre de locataire dans la plupart des requêtes","Un chemin oublié brise la frontière",[950,951],"Clés de cache globales","L'isolation correcte de la base de données est contournée par les données mises en cache",[953,954],"Index vectoriel partagé sans filtres de métadonnées appliqués","Le RAG récupère les chunks d'un autre locataire",[956,957],"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",[959,960],"Administrateur de plateforme modélisé comme ADMIN ordinaire","Le pouvoir inter-locataires devient implicite et difficile à auditer",[962,963],"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é",[965,966],"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",[968,969],"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",[971,972],"UUID aléatoires traités comme isolation","Les identifiants difficiles à deviner réduisent l'énumération mais n'autorisent pas l'accès",{},{"id":975,"data":976,"type":42,"tunes":978},"h-misconceptions",{"text":977,"level":247},"Idées fausses courantes",{},{"id":980,"data":981,"type":391,"tunes":1016},"misconceptions-table",{"content":982,"stretched":43,"withHeadings":14},[983,986,989,992,995,998,1001,1004,1007,1010,1013],[984,985],"Idée fausse","Correction",[987,988],"« Le RBAC fournit l'isolation des locataires. »","Le RBAC contrôle les permissions ; l'isolation nécessite également une portée de locataire\u002Fressource.",[990,991],"« Si l'utilisateur est un administrateur, les vérifications de locataire sont inutiles. »","L'autorité d'administrateur doit toujours avoir une portée explicite.",[993,994],"« 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é.",[996,997],"« 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.",[999,1000],"« Une colonne tenant_id signifie que le système est isolé. »","Le champ n'aide que si les chemins d'accès l'appliquent.",[1002,1003],"« Les UUID empêchent l'accès inter-locataires. »","Les identifiants imprévisibles sont une défense en profondeur, pas une autorisation.",[1005,1006],"« 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.",[1008,1009],"« 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.",[1011,1012],"« Le support de plateforme a besoin d'un ADMIN global. »","Le support inter-locataires devrait être une autorité distincte, contrainte et auditable.",[1014,1015],"« 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.",{},{"id":1018,"data":1019,"type":42,"tunes":1021},"h-design",{"text":1020,"level":247},"Une séquence de conception pratique",{},{"id":1023,"data":1024,"type":334,"tunes":1063},"design-flow",{"steps":1025,"title":1062,"orientation":333},[1026,1029,1032,1035,1038,1041,1044,1047,1050,1053,1056,1059],{"label":1027,"description":1028},"1. Définir la propriété du locataire","Classer quelles entités et ressources sont globales, limitées au locataire, limitées à l'utilisateur ou intentionnellement inter-locataires.",{"label":1030,"description":1031},"2. Définir les opérations","Créer des permissions explicites pour les lectures, écritures, publications, approbations, administration et autres actions métier.",{"label":1033,"description":1034},"3. Définir les rôles","Regrouper les permissions selon les responsabilités sans intégrer de portée globale accidentelle.",{"label":1036,"description":1037},"4. Définir la portée de l'appartenance","Lier les attributions de rôle au contexte de locataire\u002Fespace de travail\u002Fprojet dans lequel elles s'appliquent.",{"label":1039,"description":1040},"5. Résoudre le contexte de locataire de confiance","Dériver l'identité du locataire à partir d'une appartenance authentifiée et vérifiée par le serveur ou d'une autorisation de service.",{"label":1042,"description":1043},"6. Appliquer la propriété des ressources","Appliquer la portée du locataire à chaque frontière de données\u002Fservice appartenant au locataire.",{"label":1045,"description":1046},"7. Ajouter une défense en profondeur","Utiliser RLS, des identifiants séparés, des schémas\u002Fbases de données, des politiques de stockage ou des moteurs de politiques là où le risque le justifie.",{"label":1048,"description":1049},"8. Transmettre la portée à travers les systèmes dérivés","Préserver les métadonnées du locataire dans le cache, la recherche, les index vectoriels, les files d'attente, les fichiers et l'analytique.",{"label":1051,"description":1052},"9. Modéliser explicitement les opérations inter-locataires","Séparer l'administration de la plateforme et les identités de service des rôles ordinaires de locataire.",{"label":1054,"description":1055},"10. Tester les deux axes","Exécuter des tests négatifs pour la permission manquante et pour le mauvais locataire indépendamment.",{"label":1057,"description":1058},"11. Auditer le locataire + la permission ensemble","Journaliser qui a agi, dans quel locataire, sur quelle cible et sous quelle autorité.",{"label":1060,"description":1061},"12. Re-tester après les changements de schéma\u002Fruntime","L'isolation peut se briser lorsque de nouvelles tables, caches, files d'attente ou chemins de récupération sont introduits.","Concevoir les permissions et l'isolation comme des dimensions séparées",{},{"id":1065,"data":1066,"type":42,"tunes":1068},"h-checklist",{"text":1067,"level":247},"Liste de contrôle RBAC + isolation des locataires",{},{"id":1070,"data":1071,"type":391,"tunes":1117},"checklist-table",{"content":1072,"stretched":43,"withHeadings":14},[1073,1075,1078,1081,1084,1087,1090,1093,1096,1099,1102,1105,1108,1111,1114],[412,1074],"Réponse attendue",[1076,1077],"Qui est le principal ?","Identité d'utilisateur\u002Fservice\u002Fagent authentifiée",[1079,1080],"Quel contexte de locataire s'applique ?","Appartenance vérifiée par le serveur ou portée de service",[1082,1083],"Quelle opération est demandée ?","Permission typée ou action de politique",[1085,1086],"Le principal a-t-il cette permission ?","Décision de rôle\u002Fpolitique",[1088,1089],"Qui possède la ressource cible ?","Classification explicite locataire\u002Fglobal\u002Futilisateur",[1091,1092],"La portée de la ressource correspond-elle à l'autorité ?","Recherche\u002Fpolitique tenant-aware",[1094,1095],"Le stockage peut-il contourner les vérifications applicatives ?","Décision de défense en profondeur documentée",[1097,1098],"Les caches sont-ils sûrs pour les locataires ?","Les clés\u002Fespaces de noms et l'autorisation préservent la portée du locataire",[1100,1101],"Les fichiers\u002Fblobs sont-ils sûrs pour les locataires ?","La politique d'objet et l'émission d'URL signées appliquent la portée",[1103,1104],"Les tâches asynchrones sont-elles sûres pour les locataires ?","Le contexte vérifié se propage et est revalidé",[1106,1107],"Le RAG\u002Frecherche est-il sûr pour les locataires ?","L'isolation des métadonnées\u002Fcollections est appliquée avant le contexte du modèle",[1109,1110],"Les administrateurs inter-locataires sont-ils explicites ?","Autorité, contrôles et audit séparés",[1112,1113],"Les identifiants ordinaires peuvent-ils contourner l'isolation ?","Non, ou chemin exceptionnel étroitement documenté",[1115,1116],"Les tests négatifs inter-locataires sont-ils automatisés ?","Oui pour chaque couche d'accès pertinente",{},{"id":1119,"data":1120,"type":42,"tunes":1122},"h-edge",{"text":1121,"level":247},"Cas limites et limitations",{},{"id":1124,"data":1125,"type":218,"tunes":1127},"p-edge-1",{"text":1126},"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.",{},{"id":1129,"data":1130,"type":218,"tunes":1132},"p-edge-2",{"text":1131},"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ë.",{},{"id":1134,"data":1135,"type":218,"tunes":1137},"p-edge-3",{"text":1136},"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é.",{},{"id":1139,"data":1140,"type":218,"tunes":1142},"p-edge-4",{"text":1141},"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.",{},{"id":1144,"data":1145,"type":218,"tunes":1147},"p-edge-5",{"text":1146},"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.",{},{"id":1149,"data":1150,"type":42,"tunes":1152},"h-change",{"text":1151,"level":247},"Qu'est-ce qui changerait cette réponse ?",{},{"id":1154,"data":1155,"type":218,"tunes":1157},"p-change-1",{"text":1156},"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.",{},{"id":1159,"data":1160,"type":218,"tunes":1162},"p-change-2",{"text":1161},"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.",{},{"id":1164,"data":1165,"type":218,"tunes":1167},"p-change-3",{"text":1166},"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.",{},{"id":1169,"data":1170,"type":42,"tunes":1172},"h-related",{"text":1171,"level":247},"Connaissances canoniques associées",{},{"id":1174,"data":1175,"type":218,"tunes":1177},"p-related-1",{"text":1176},"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.",{},{"id":1179,"data":1180,"type":218,"tunes":1182},"p-related-2",{"text":1181},"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.",{},{"id":1184,"data":1185,"type":1190,"tunes":1191},"ref-agentic",{"url":1186,"title":1187,"excerpt":1188,"ctaLabel":1189},"https:\u002F\u002Fstajic.de\u002Fde\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","MCP vs A2A vs UCP vs AP2 vs A2UI : la pile de protocoles d'agents expliquée","L'interopérabilité des protocoles ne remplace pas l'autorisation ou l'isolation des tenants. La découverte des capacités et l'autorité métier restent des préoccupations architecturales distinctes.","Lire l'article sur la pile de protocoles","referralArticle",{},{"id":1193,"data":1194,"type":218,"tunes":1196},"p-related-3",{"text":1195},"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.",{},{"id":1198,"data":1199,"type":1190,"tunes":1204},"ref-rag",{"url":1200,"title":1201,"excerpt":1202,"ctaLabel":1203},"https:\u002F\u002Fstajic.de\u002Ffr\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","Qu'est-ce que le RAG ? L'explication la plus simple de son fonctionnement","La base de récupération pour comprendre où le filtrage des sources conscient du tenant et l'isolation du magasin vectoriel doivent être appliqués.","Lire les fondements du RAG",{},{"id":1206,"data":1207,"type":42,"tunes":1209},"h-faq",{"text":1208,"level":247},"Questions fréquemment posées",{},{"id":1211,"data":1212,"type":1211,"tunes":1251},"faq",{"items":1213,"title":1250},[1214,1218,1222,1226,1230,1234,1238,1242,1246],{"id":1215,"answer":1216,"question":1217},"faq1","Le RBAC détermine quelles opérations un principal peut effectuer. L'isolation des tenants détermine à quelles ressources de quel tenant ces opérations peuvent accéder. Les applications multi-tenants sécurisées ont normalement besoin des deux.","Quelle est la différence entre RBAC et l'isolation des tenants ?",{"id":1219,"answer":1220,"question":1221},"faq2","Non. ADMIN doit avoir une portée explicite. Un administrateur de tenant a normalement des permissions étendues uniquement à l'intérieur de ce tenant, tandis que l'administration de la plateforme inter-tenants doit être modélisée séparément.","Un rôle ADMIN permet-il automatiquement l'accès à tous les tenants ?",{"id":1223,"answer":1224,"question":1225},"faq3","Non. L'authentification prouve l'identité. L'autorisation contrôle les actions permises. L'isolation des tenants empêche en outre ces actions d'atteindre les ressources du mauvais tenant.","L'authentification suffit-elle pour l'isolation des tenants ?",{"id":1227,"answer":1228,"question":1229},"faq4","Il peut être une entrée pour le contexte du tenant, mais le serveur doit vérifier l'appartenance ou l'autorité actuelle et appliquer la portée aux frontières des ressources protégées. Une revendication seule ne remplace pas les contrôles d'isolation.","Le tenantId doit-il être stocké dans le JWT ?",{"id":1231,"answer":1232,"question":1233},"faq5","Pas nécessairement. Les modèles d'isolation par table partagée, RLS, schéma, base de données, infrastructure et hybride peuvent tous être valides selon les risques et les exigences opérationnelles.","Ai-je besoin d'une base de données séparée par tenant ?",{"id":1235,"answer":1236,"question":1237},"faq6","Le RLS peut fournir une solide défense en profondeur, mais des rôles de base de données corrects, un contexte de requête, une couverture des politiques et une autorisation au niveau applicatif restent importants.","Le RLS PostgreSQL peut-il remplacer les filtres de tenant dans le code applicatif ?",{"id":1239,"answer":1240,"question":1241},"faq7","La portée du tenant ou de l'accès doit être appliquée lors de la récupération afin que les fragments non autorisés n'entrent jamais dans le contexte du modèle. Préservez les métadonnées d'accès tout au long du découpage et de l'indexation.","Comment le RAG doit-il appliquer l'isolation des tenants ?",{"id":1243,"answer":1244,"question":1245},"faq8","Oui. C'est courant dans le SaaS B2B et c'est une raison forte pour limiter les attributions de rôles par appartenance au tenant plutôt que de traiter les rôles comme globalement attachés à l'utilisateur.","Un utilisateur peut-il avoir différents rôles dans différents tenants ?",{"id":1247,"answer":1248,"question":1249},"faq9","Utilisez des tests négatifs inter-tenants : créez au moins deux tenants, donnez à un utilisateur des permissions valides dans un tenant, puis prouvez que chaque chemin protégé refuse l'accès aux ressources de l'autre tenant.","Quel est le meilleur test pour l'isolation des tenants ?","FAQ RBAC vs isolation des tenants",{},{"id":1253,"data":1254,"type":42,"tunes":1256},"h-glossary",{"text":1255,"level":247},"Glossaire",{},{"id":1258,"data":1259,"type":1258,"tunes":1306},"glossary",{"title":1260,"entries":1261},"Termes clés de la sécurité multi-tenant",[1262,1264,1267,1271,1274,1278,1282,1286,1290,1294,1298,1302],{"term":395,"anchor":394,"definition":1263},"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.",{"term":1265,"anchor":397,"definition":1266},"Tenant","Un client, une organisation, un espace de travail ou tout autre consommateur logique isolé d'un système multi-tenant partagé.",{"term":1268,"anchor":1269,"definition":1270},"Isolation des tenants","tenant-isolation","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é.",{"term":415,"anchor":1272,"definition":1273},"authentication","Vérification de l'identité d'un utilisateur, d'un service ou d'un autre principal.",{"term":1275,"anchor":1276,"definition":1277},"Autorisation","authorization","Processus de décision qui détermine si un principal peut effectuer une opération demandée sur une ressource.",{"term":1279,"anchor":1280,"definition":1281},"Permission","permission","Une opération ou capacité autorisée définie, telle que orders.read ou users.write.",{"term":1283,"anchor":1284,"definition":1285},"Rôle","role","Un regroupement nommé de permissions associé à une responsabilité ou une fonction.",{"term":1287,"anchor":1288,"definition":1289},"ABAC","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.",{"term":1291,"anchor":1292,"definition":1293},"Sécurité au niveau des lignes","row-level-security","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.",{"term":1295,"anchor":1296,"definition":1297},"Accès inter-tenant","cross-tenant-access","Tout chemin d'accès dans lequel un principal opérant dans un contexte de tenant atteint des ressources appartenant à un autre tenant.",{"term":1299,"anchor":1300,"definition":1301},"Administrateur de plateforme","platform-administrator","Une identité opérationnelle privilégiée avec une autorité explicitement modélisée qui peut s'étendre sur plusieurs tenants.",{"term":1303,"anchor":1304,"definition":1305},"Contexte de tenant","tenant-context","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.",{},{"id":1308,"data":1309,"type":42,"tunes":1311},"h-conclusion",{"text":1310,"level":247},"Conclusion",{},{"id":1313,"data":1314,"type":218,"tunes":1316},"p-conclusion-1",{"text":1315},"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.",{},{"id":1318,"data":1319,"type":218,"tunes":1321},"p-conclusion-2",{"text":1320},"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.",{},{"id":1323,"data":1324,"type":218,"tunes":1326},"p-conclusion-3",{"text":1325},"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.",{},{"id":1328,"data":1329,"type":42,"tunes":1331},"h-sources",{"text":1330,"level":247},"Sources primaires et recommandations actuelles",{},{"id":1333,"data":1334,"type":218,"tunes":1336},"p-sources-note",{"text":1335},"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.",{},{"id":1338,"data":1339,"type":1345,"tunes":1346},"src-nist-rbac",{"link":1340,"meta":1341},"https:\u002F\u002Fcsrc.nist.gov\u002Fprojects\u002Frole-based-access-control",{"image":1342,"title":1343,"description":1344},{"url":369},"NIST — Contrôle d'accès basé sur les rôles","Aperçu NIST des modèles RBAC et de la norme INCITS RBAC, incluant les utilisateurs, rôles, permissions, opérations et objets.","linkTool",{},{"id":1348,"data":1349,"type":1345,"tunes":1355},"src-nist-glossary",{"link":1350,"meta":1351},"https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Frole_based_access_control",{"image":1352,"title":1353,"description":1354},{"url":369},"NIST CSRC — Glossaire RBAC","Dé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.",{},{"id":1357,"data":1358,"type":1345,"tunes":1364},"src-aws-isolation",{"link":1359,"meta":1360},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwhitepapers\u002Flatest\u002Fsaas-tenant-isolation-strategies\u002Fthe-isolation-mindset.html",{"image":1361,"title":1362,"description":1363},{"url":369},"AWS — L'état d'esprit d'isolation","Recommandations AWS SaaS distinguant explicitement l'authentification\u002Fautorisation de l'isolation des tenants et recommandant des mécanismes d'isolation partagés.",{},{"id":1366,"data":1367,"type":1345,"tunes":1373},"src-aws-faq",{"link":1368,"meta":1369},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fsaas-multitenant-api-access-authorization\u002Ffaq.html",{"image":1370,"title":1371,"description":1372},{"url":369},"AWS — FAQ sur l'autorisation multi-tenant","Recommandations actuelles expliquant la différence entre l'autorisation et l'isolation des tenants dans les applications SaaS.",{},{"id":1375,"data":1376,"type":1345,"tunes":1382},"src-aws-avp",{"link":1377,"meta":1378},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fsaas-multitenant-api-access-authorization\u002Favp-design-considerations.html",{"image":1379,"title":1380,"description":1381},{"url":369},"AWS — Considérations de conception multi-tenant","Recommandations SaaS actuelles distinguant l'isolation des tenants de l'autorisation et discutant des modèles de politique d'autorisation mutualisés\u002Fisolés.",{},{"id":1384,"data":1385,"type":1345,"tunes":1391},"src-owasp-multi",{"link":1386,"meta":1387},"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FMulti_Tenant_Security_Cheat_Sheet.html",{"image":1388,"title":1389,"description":1390},{"url":369},"OWASP — Aide-mémoire sur la sécurité des applications multi-tenant","Recommandations 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.",{},{"id":1393,"data":1394,"type":1345,"tunes":1400},"src-owasp-rag",{"link":1395,"meta":1396},"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FRAG_Security_Cheat_Sheet.html",{"image":1397,"title":1398,"description":1399},{"url":369},"OWASP — Aide-mémoire sur la sécurité RAG","Recommandations 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.",{},{"id":1402,"data":1403,"type":1345,"tunes":1409},"src-owasp-auth-test",{"link":1404,"meta":1405},"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FAuthorization_Regression_Testing_Cheat_Sheet.html",{"image":1406,"title":1407,"description":1408},{"url":369},"OWASP — Tests de régression d'autorisation","Recommandations de test actuelles incluant les tests de rétrogradation de rôle et de frontière inter-tenant.",{},"2.31","Le RBAC contrôle ce qu’un utilisateur peut faire ; l’isolation des locataires contrôle à quelles ressources de locataire cette action peut accéder. Découvrez pourquoi la sécurité SaaS multi-locataires nécessite ces deux frontières.","\u002Fuploads\u002F2026\u002F10\u002Frbac-vs-tenant-isolation-two-different-security-boundaries-1791485111528-qqtzby.webp","rbac-vs-tenant-isolation-two-different-security-boundaries-1791485111528-qqtzby","PUBLISHED","2026-10-08T14:43:00.000Z","2026-10-08T18:43:57.878Z","2026-10-08T18:56:28.335Z",{"en":1419,"de":1420,"sr":1421,"es":1422,"fr":1423,"it":1424,"ru":1425,"zh":1426},"\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Fde\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Fsr\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Fes\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Ffr\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Fit\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Fru\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries","\u002Fzh\u002Fblog\u002Frbac-vs-tenant-isolation-two-different-security-boundaries",[1428,1432,1436],{"id":1429,"name":1430,"slug":1431},84,"Politique et limites des données","policy-and-data",{"id":1433,"name":1434,"slug":1435},57,"Limites des données","data-boundaries",{"id":1437,"name":1438,"slug":1439},64,"Architecture de l’information","information-architecture",{"id":1441,"login":1442,"email":1443,"displayName":1444},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1446,2437],{"lang":1447,"title":1448,"content":1449,"contentJson":1450,"excerpt":2436},"en","RBAC vs Tenant Isolation: Two Different Security Boundaries","{\"time\":1791485112883,\"blocks\":[{\"id\":\"intro\",\"type\":\"paragraph\",\"data\":{\"text\":\"RBAC and tenant isolation solve two different security problems in multi-tenant systems. Role-Based Access Control (RBAC) determines what an authenticated principal is allowed to do, such as read orders, edit products or manage users. Tenant isolation determines which tenant's data, resources and execution context that principal is allowed to access. A user can be correctly authenticated and correctly assigned an RBAC role yet still experience a security failure if the application lets that role operate on another tenant's resources.\"},\"tunes\":{}},{\"id\":\"direct\",\"type\":\"callout\",\"data\":{\"variant\":\"info\",\"title\":\"Direct answer\",\"body\":\"\u003Cstrong>RBAC answers “what may this identity do?” Tenant isolation answers “inside whose boundary may it do it?”\u003C\u002Fstrong>\u003Cbr>\u003Cbr>A secure multi-tenant application normally needs both. A tenant administrator may have broad permissions, but those permissions should remain constrained to the administrator's tenant unless an explicitly separate platform-level authority exists.\"},\"tunes\":{}},{\"id\":\"boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"A role is not a tenant boundary\",\"body\":\"Giving a user the role \u003Ccode>ADMIN\u003C\u002Fcode> does not automatically imply “administrator of tenant A only.” The role must be evaluated together with verified tenant context and the target resource's tenant ownership. Otherwise a valid role can become a cross-tenant privilege.\"},\"tunes\":{}},{\"id\":\"current\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Current-source note — 8 October 2026\",\"body\":\"The underlying distinction is stable. NIST defines RBAC around users, roles, permissions, operations and objects. Current AWS SaaS guidance explicitly states that authentication and authorization are not equal to tenant isolation, and that a user can be authenticated and authorized while still accessing another tenant's resources if isolation is not separately enforced. OWASP's current Multi-Tenant Security guidance likewise treats tenant isolation as a cross-layer requirement covering APIs, databases, caches, storage, queues and other shared resources.\"},\"tunes\":{}},{\"id\":\"toc\",\"type\":\"tableOfContents\",\"data\":{\"title\":\"Contents\",\"minLevel\":2,\"maxLevel\":3},\"tunes\":{}},{\"id\":\"h-meaning\",\"type\":\"header\",\"data\":{\"text\":\"What RBAC really controls\",\"level\":2},\"tunes\":{}},{\"id\":\"p-rbac-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"RBAC is an authorization model in which permissions are associated with roles and users are assigned to those roles. The role acts as an administrative abstraction between identities and permissions.\"},\"tunes\":{}},{\"id\":\"p-rbac-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"NIST's classic RBAC work formalizes this around users, roles, permissions, operations and objects. The practical benefit is that an organization can manage authorization through relatively stable job or responsibility roles rather than attaching every permission directly to every user.\"},\"tunes\":{}},{\"id\":\"p-rbac-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"A role such as EDITOR can therefore mean: may read content, write content and publish content. A role such as ACCOUNTANT may mean: may read billing data, reconcile invoices and approve settlements.\"},\"tunes\":{}},{\"id\":\"h-tenant\",\"type\":\"header\",\"data\":{\"text\":\"What tenant isolation really controls\",\"level\":2},\"tunes\":{}},{\"id\":\"p-tenant-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Tenant isolation is the set of mechanisms that prevents one tenant from reading, modifying, influencing or accidentally receiving another tenant's resources in a shared system.\"},\"tunes\":{}},{\"id\":\"p-tenant-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The protected boundary is broader than database rows. Tenant-specific state can exist in relational tables, object storage, vector indexes, caches, search indexes, queue messages, files, temporary artifacts, background jobs, analytics, rate limits and infrastructure resources.\"},\"tunes\":{}},{\"id\":\"p-tenant-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"AWS's SaaS guidance makes the distinction explicit: authorization grants access to resources, while tenant isolation ensures those resources cannot cross the wrong tenant boundary even when infrastructure is shared.\"},\"tunes\":{}},{\"id\":\"h-simple\",\"type\":\"header\",\"data\":{\"text\":\"The simplest example\",\"level\":2},\"tunes\":{}},{\"id\":\"p-simple-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Suppose Alice is an administrator for Tenant A and Bob is an administrator for Tenant B. Both users legitimately hold the same ADMIN role.\"},\"tunes\":{}},{\"id\":\"p-simple-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"RBAC can correctly conclude that both users may execute an operation such as users.read. But when Alice requests user ID 847, the application must still verify that user 847 belongs to Tenant A.\"},\"tunes\":{}},{\"id\":\"p-simple-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"If the API checks only “Alice has ADMIN” and then executes SELECT * FROM users WHERE id = 847, RBAC succeeded while tenant isolation failed.\"},\"tunes\":{}},{\"id\":\"simple-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"A correct multi-tenant authorization decision\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Authenticate principal\",\"description\":\"Establish who the user, service or agent is.\"},{\"label\":\"2. Resolve verified tenant context\",\"description\":\"Determine which tenant context applies from trusted server-side identity\u002Fmembership information.\"},{\"label\":\"3. Resolve permission\",\"description\":\"Evaluate whether the principal's role or policy permits the requested operation.\"},{\"label\":\"4. Scope the target resource\",\"description\":\"Verify that the target object belongs to the permitted tenant or explicitly shared scope.\"},{\"label\":\"5. Enforce at the access boundary\",\"description\":\"Perform the database, cache, storage, queue or service operation with tenant constraints applied.\"},{\"label\":\"6. Audit both dimensions\",\"description\":\"Record principal, tenant, operation, target and result so cross-tenant attempts are visible.\"}]},\"tunes\":{}},{\"id\":\"h-stops\",\"type\":\"header\",\"data\":{\"text\":\"Where the simple example stops\",\"level\":2},\"tunes\":{}},{\"id\":\"p-stops-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Real systems often contain several classes of identity: tenant users, platform administrators, background workers, integrations, agents and cross-tenant operational services. Some of these legitimately cross tenant boundaries.\"},\"tunes\":{}},{\"id\":\"p-stops-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"That does not remove the need for isolation. It means cross-tenant authority must be explicit, narrow and separately auditable rather than emerging accidentally from a global role or unscoped database connection.\"},\"tunes\":{}},{\"id\":\"p-stops-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Tenant isolation can also vary by layer. A product may share application servers while separating databases, or use a shared database with row-level policies while giving premium tenants isolated storage or compute. There is no single universal isolation topology.\"},\"tunes\":{}},{\"id\":\"h-compare\",\"type\":\"header\",\"data\":{\"text\":\"RBAC vs tenant isolation\",\"level\":2},\"tunes\":{}},{\"id\":\"core-comparison\",\"type\":\"comparison\",\"data\":{\"title\":\"Two different security dimensions\",\"layout\":\"table\",\"columns\":[{\"id\":\"rbac\",\"label\":\"RBAC\"},{\"id\":\"tenant\",\"label\":\"Tenant isolation\"}],\"rows\":[{\"id\":\"question\",\"label\":\"Primary question\",\"values\":[\"\",\"\"]},{\"id\":\"unit\",\"label\":\"Typical unit\",\"values\":[\"\",\"\"]},{\"id\":\"example\",\"label\":\"Example\",\"values\":[\"\",\"\"]},{\"id\":\"failure\",\"label\":\"Typical failure\",\"values\":[\"\",\"\"]},{\"id\":\"implementation\",\"label\":\"Typical implementation\",\"values\":[\"\",\"\"]},{\"id\":\"scope\",\"label\":\"Can it exist alone?\",\"values\":[\"\",\"\"]}]},\"tunes\":{}},{\"id\":\"h-authn\",\"type\":\"header\",\"data\":{\"text\":\"Authentication, authorization and isolation are three different checks\",\"level\":2},\"tunes\":{}},{\"id\":\"three-checks\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Layer\",\"Question\",\"Example failure\"],[\"Authentication\",\"Who is this principal?\",\"Attacker impersonates Alice\"],[\"Authorization \u002F RBAC\",\"May this principal perform this operation?\",\"Viewer can delete users\"],[\"Tenant isolation\",\"May this operation reach this tenant\u002Fresource boundary?\",\"Tenant A admin reads Tenant B order\"]]},\"tunes\":{}},{\"id\":\"p-authn-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"These checks are related but non-substitutable. Authentication can be perfect while authorization fails. Authorization can be correct while tenant isolation fails. A secure SaaS request path needs all applicable boundaries.\"},\"tunes\":{}},{\"id\":\"h-role-scope\",\"type\":\"header\",\"data\":{\"text\":\"Roles need a scope\",\"level\":2},\"tunes\":{}},{\"id\":\"p-role-scope-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The word ADMIN is incomplete without scope. It can mean platform administrator, tenant administrator, project administrator, workspace administrator or administrator of one subsystem.\"},\"tunes\":{}},{\"id\":\"p-role-scope-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"In multi-tenant systems, role assignment should normally be associated with tenant membership or another explicit resource scope. The same user may legitimately be ADMIN in Tenant A and VIEWER in Tenant B.\"},\"tunes\":{}},{\"id\":\"p-role-scope-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"A global role model that ignores this distinction can create privilege leakage even when the permission map itself is correct.\"},\"tunes\":{}},{\"id\":\"h-context\",\"type\":\"header\",\"data\":{\"text\":\"Tenant context must come from a trusted path\",\"level\":2},\"tunes\":{}},{\"id\":\"p-context-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A tenant ID supplied by the client is useful as a selector, but it is not proof of authority. The server must derive or verify tenant membership against authenticated identity and current authorization data.\"},\"tunes\":{}},{\"id\":\"p-context-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"OWASP's current multi-tenant guidance recommends establishing tenant context early in the request lifecycle and explicitly warns against treating client headers or request parameters as authorization proof.\"},\"tunes\":{}},{\"id\":\"p-context-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"This matters because a trivial request modification from tenant=A to tenant=B must not be sufficient to cross the isolation boundary.\"},\"tunes\":{}},{\"id\":\"h-query\",\"type\":\"header\",\"data\":{\"text\":\"Tenant scope belongs in the resource lookup\",\"level\":2},\"tunes\":{}},{\"id\":\"p-query-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A common application-level isolation pattern is to include tenant scope in the same query that resolves the resource.\"},\"tunes\":{}},{\"id\":\"query-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Weak lookup\",\"Stronger tenant-scoped lookup\"],[\"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)\"]]},\"tunes\":{}},{\"id\":\"p-query-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"This pattern is not the only possible isolation mechanism, but it keeps tenant ownership close to the data access operation and prevents an object ID from becoming a cross-tenant capability.\"},\"tunes\":{}},{\"id\":\"h-defense\",\"type\":\"header\",\"data\":{\"text\":\"Application checks are useful, but isolation should not depend on perfect developer behavior\",\"level\":2},\"tunes\":{}},{\"id\":\"p-defense-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AWS's isolation guidance explicitly warns against leaving isolation enforcement only to service developers. In a large codebase, eventually one query, cache key or worker path may omit tenant scope.\"},\"tunes\":{}},{\"id\":\"p-defense-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Defense in depth can therefore move isolation into shared middleware, repository\u002Fservice layers, policy engines, database Row-Level Security, dedicated credentials, separate schemas or separate databases depending on risk and architecture.\"},\"tunes\":{}},{\"id\":\"defense-rule\",\"type\":\"callout\",\"data\":{\"variant\":\"success\",\"title\":\"Isolation should be hard to forget\",\"body\":\"The strongest boundary is one that ordinary application code cannot casually bypass by omitting one \u003Ccode>tenantId\u003C\u002Fcode> condition.\"},\"tunes\":{}},{\"id\":\"h-db\",\"type\":\"header\",\"data\":{\"text\":\"Database isolation strategies\",\"level\":2},\"tunes\":{}},{\"id\":\"db-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Strategy\",\"Boundary\",\"Strength \u002F trade-off\"],[\"Shared tables + tenant key\",\"Row\u002Fapplication policy\",\"Operationally efficient; requires exhaustive tenant scoping and strong tests\"],[\"Shared tables + database RLS\",\"Database policy boundary\",\"Reduces dependence on every application query; requires correct roles, session\u002Ftransaction tenant context and policy coverage\"],[\"Separate schemas\",\"Namespace \u002F DB-role boundary\",\"Stronger logical separation; more operational complexity\"],[\"Separate databases\",\"Database \u002F credential boundary\",\"Strong isolation and simpler blast-radius story; higher provisioning and operations cost\"],[\"Separate infrastructure\u002Faccount\",\"Infrastructure boundary\",\"Strongest coarse-grained separation; highest cost and operational overhead\"],[\"Hybrid\",\"Per workload\u002Fdata class\",\"Allows stronger isolation only where risk\u002Fcompliance justifies it\"]]},\"tunes\":{}},{\"id\":\"p-db-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"OWASP's current Multi-Tenant Security Cheat Sheet lists separate databases, separate schemas, shared tables with row-level controls and hybrid models. The correct model depends on threat level, compliance, performance and operational cost.\"},\"tunes\":{}},{\"id\":\"h-rls\",\"type\":\"header\",\"data\":{\"text\":\"PostgreSQL Row-Level Security can provide defense in depth\",\"level\":2},\"tunes\":{}},{\"id\":\"p-rls-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"With shared tables, PostgreSQL Row-Level Security can enforce a tenant predicate at the database layer so ordinary queries cannot see rows outside the active tenant policy.\"},\"tunes\":{}},{\"id\":\"p-rls-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"However, RLS is not magic. PostgreSQL superusers and roles with BYPASSRLS can bypass row policies. OWASP therefore recommends using a least-privileged request-path role and testing the same connection\u002Fpooling mode used in production.\"},\"tunes\":{}},{\"id\":\"p-rls-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Connection reuse is another important edge: tenant context must be set and reset safely for every transaction\u002Frequest so one pooled connection cannot leak prior tenant state.\"},\"tunes\":{}},{\"id\":\"h-cache\",\"type\":\"header\",\"data\":{\"text\":\"Tenant isolation must include caches\",\"level\":2},\"tunes\":{}},{\"id\":\"p-cache-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A database query can be perfectly scoped and still leak data through a shared cache key.\"},\"tunes\":{}},{\"id\":\"p-cache-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"If user:42 exists in both Tenant A and Tenant B, a global cache key can return the wrong tenant's value. Tenant-sensitive cache keys should include every attribute that changes visibility or result semantics, commonly tenant, user, locale, feature set or permission version.\"},\"tunes\":{}},{\"id\":\"p-cache-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Cache partitioning is defense in depth, not a replacement for authorization. The request still needs to be authorized before protected cached content is returned.\"},\"tunes\":{}},{\"id\":\"h-storage\",\"type\":\"header\",\"data\":{\"text\":\"Files and object storage need their own tenant boundary\",\"level\":2},\"tunes\":{}},{\"id\":\"p-storage-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Object storage should distinguish global, tenant-scoped and user-scoped objects. A folder prefix alone is only a naming convention unless access policy actually constrains reads and writes.\"},\"tunes\":{}},{\"id\":\"p-storage-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Stronger designs may use tenant-aware object keys, bucket policies, separate buckets\u002Faccounts or tenant-specific encryption keys where risk or compliance requires stronger isolation.\"},\"tunes\":{}},{\"id\":\"p-storage-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Signed URLs must be authorized before issuance and scoped to the exact object and operation. Possession of an object identifier should not itself grant cross-tenant access.\"},\"tunes\":{}},{\"id\":\"h-queues\",\"type\":\"header\",\"data\":{\"text\":\"Background jobs and queues can break isolation\",\"level\":2},\"tunes\":{}},{\"id\":\"p-queue-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Async jobs often leave the original HTTP request context, which makes tenant propagation easy to mishandle. A queue message containing tenantId is not sufficient proof that the producer was authorized.\"},\"tunes\":{}},{\"id\":\"p-queue-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The worker should carry a verified service\u002Fuser identity or trusted job envelope, re-establish tenant context and re-authorize consequential operations at the consumer boundary.\"},\"tunes\":{}},{\"id\":\"p-queue-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Tenant isolation also includes availability. One tenant should not be able to monopolize shared workers, queues, connection pools or compute in ways that materially degrade other tenants.\"},\"tunes\":{}},{\"id\":\"h-search\",\"type\":\"header\",\"data\":{\"text\":\"Search and RAG need tenant-aware retrieval\",\"level\":2},\"tunes\":{}},{\"id\":\"p-search-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Multi-tenant AI introduces another copy of the isolation problem. Documents may be chunked, embedded and stored in a vector index after ingestion.\"},\"tunes\":{}},{\"id\":\"p-search-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"OWASP's current RAG security guidance states that access control must be enforced at retrieval time and that chunks from Tenant A must not be retrieved by queries from Tenant B. Document-level permissions cannot simply be assumed to survive chunking automatically.\"},\"tunes\":{}},{\"id\":\"p-search-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The vector index therefore needs tenant\u002Faccess metadata or physically\u002Flogically separate collections according to the isolation design. Retrieval filters should be applied before unauthorized content can enter model context.\"},\"tunes\":{}},{\"id\":\"rag-rule\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"The model must never be the tenant filter\",\"body\":\"Do not retrieve cross-tenant chunks and then instruct the language model to ignore them. Once protected data enters model context, the isolation boundary has already failed.\"},\"tunes\":{}},{\"id\":\"h-derived\",\"type\":\"header\",\"data\":{\"text\":\"Derived data inherits tenant sensitivity\",\"level\":2},\"tunes\":{}},{\"id\":\"p-derived-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Embeddings, search indexes, thumbnails, generated summaries, caches, analytics rows and AI responses are derived from source data. Their tenant scope should follow the source unless an explicit transformation creates a legitimate shared\u002Fglobal artifact.\"},\"tunes\":{}},{\"id\":\"p-derived-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Deletion and offboarding must therefore propagate beyond the canonical row. Removing a tenant document while leaving searchable chunks or cached summaries can retain cross-tenant or post-retention exposure.\"},\"tunes\":{}},{\"id\":\"h-shared\",\"type\":\"header\",\"data\":{\"text\":\"Not everything belongs to a tenant\",\"level\":2},\"tunes\":{}},{\"id\":\"p-shared-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Multi-tenant platforms often have intentionally global resources: product taxonomies, public templates, system permissions, feature definitions or public content.\"},\"tunes\":{}},{\"id\":\"p-shared-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The safest model is explicit classification: global, tenant-scoped, user-scoped or explicitly cross-tenant. Ambiguous resources are where accidental leakage begins.\"},\"tunes\":{}},{\"id\":\"p-shared-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"An intentionally shared object should have a documented reason for being global rather than simply lacking a tenant association.\"},\"tunes\":{}},{\"id\":\"h-platform-admin\",\"type\":\"header\",\"data\":{\"text\":\"Platform administrators require a different authority model\",\"level\":2},\"tunes\":{}},{\"id\":\"p-platform-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A platform operator may need to inspect multiple tenants for support, compliance or infrastructure operations. Modeling this as an ordinary tenant ADMIN with accidental global database access weakens both security and auditability.\"},\"tunes\":{}},{\"id\":\"p-platform-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A better design uses a distinct platform identity or explicit cross-tenant permission, stronger authentication, purpose limitation, detailed audit and, where appropriate, approval or break-glass controls.\"},\"tunes\":{}},{\"id\":\"p-platform-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Cross-tenant access should therefore be a named capability, not the absence of a tenant filter.\"},\"tunes\":{}},{\"id\":\"h-abac\",\"type\":\"header\",\"data\":{\"text\":\"RBAC can be combined with attributes\",\"level\":2},\"tunes\":{}},{\"id\":\"p-abac-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"Some decisions depend on more than role. Tenant membership, region, resource owner, subscription tier, time, project membership or data classification can all affect access.\"},\"tunes\":{}},{\"id\":\"p-abac-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"RBAC and ABAC are not mutually exclusive. AWS's current multi-tenant authorization guidance discusses RBAC, ABAC and hybrid models. A role can define broad responsibility while attributes constrain which concrete resource instance can be accessed.\"},\"tunes\":{}},{\"id\":\"p-abac-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The key architecture rule remains: do not encode tenant isolation only as an incidental role name if tenant identity is a first-class resource boundary.\"},\"tunes\":{}},{\"id\":\"h-matrix\",\"type\":\"header\",\"data\":{\"text\":\"Authorization decisions are at least two-dimensional\",\"level\":2},\"tunes\":{}},{\"id\":\"matrix-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Principal\",\"Role permission\",\"Tenant relationship\",\"Decision\"],[\"Alice\",\"orders.read\",\"Order belongs to Alice's tenant\",\"Allow\"],[\"Alice\",\"orders.read\",\"Order belongs to another tenant\",\"Deny\"],[\"Alice\",\"orders.write\",\"Order belongs to Alice's tenant\",\"Allow if role includes write\"],[\"Alice\",\"orders.write\",\"Order belongs to another tenant\",\"Deny\"],[\"Platform support\",\"support.cross_tenant.read\",\"Explicit support scope + audited target tenant\",\"Potentially allow under platform policy\"],[\"Background worker\",\"orders.process\",\"Trusted service scope for job tenant\",\"Allow only for verified job tenant\"]]},\"tunes\":{}},{\"id\":\"h-implementation\",\"type\":\"header\",\"data\":{\"text\":\"Original implementation evidence: Aaasaasa AI CMS\",\"level\":2},\"tunes\":{}},{\"id\":\"impl-note\",\"type\":\"callout\",\"data\":{\"variant\":\"note\",\"title\":\"Original implementation evidence\",\"body\":\"Aaasaasa AI CMS contains a concrete tenant-scoped RBAC implementation. It is useful evidence for how role authorization and tenant scope can be combined, but it should not be presented as proof that every storage, cache or infrastructure layer has complete tenant isolation.\"},\"tunes\":{}},{\"id\":\"p-impl-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The RBAC service defines typed permission codes such as cms.content.read, shop.orders.write, billing.reconcile and users.roles. System roles map those permissions into named responsibility sets.\"},\"tunes\":{}},{\"id\":\"p-impl-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Role records are created and resolved with a tenantId. System roles are upserted using a composite tenant\u002Fcode identity, and role listing is filtered by tenant.\"},\"tunes\":{}},{\"id\":\"p-impl-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Role update and deletion first resolve the role using both role ID and tenant ID. User-role assignments are also stored and replaced under the current tenant context.\"},\"tunes\":{}},{\"id\":\"p-impl-4\",\"type\":\"paragraph\",\"data\":{\"text\":\"Permission resolution reads explicit user-role assignments scoped by both tenantId and userId. This prevents one tenant's role assignment from automatically becoming another tenant's role assignment.\"},\"tunes\":{}},{\"id\":\"p-impl-5\",\"type\":\"paragraph\",\"data\":{\"text\":\"At API level, administrative RBAC routes resolve a tenant context before creating or modifying roles. This is the correct direction: permission administration itself must respect tenancy.\"},\"tunes\":{}},{\"id\":\"impl-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Observed implementation pattern\",\"Security meaning\"],[\"Typed permission codes\",\"RBAC operation vocabulary is explicit\"],[\"System role → permission maps\",\"Roles aggregate permissions rather than hard-coding users\"],[\"tenantId_code role identity\",\"Same logical role can exist separately per tenant\"],[\"Role lookup uses id + tenantId\",\"Role mutation is tenant-scoped\"],[\"User-role relation stores tenantId\",\"Membership is not globally inferred from role alone\"],[\"Permission resolution uses tenantId + userId\",\"Authorization is evaluated inside tenant context\"]]},\"tunes\":{}},{\"id\":\"impl-boundary\",\"type\":\"callout\",\"data\":{\"variant\":\"warning\",\"title\":\"What this evidence does not prove\",\"body\":\"Tenant-scoped RBAC is one layer. Complete tenant isolation must also cover all tenant-owned resource lookups, databases, caches, files, search\u002Fvector indexes, background jobs, integrations and operational paths. The repository evidence here supports the RBAC\u002Ftenant-scope design pattern, not a claim of independently audited SaaS isolation.\"},\"tunes\":{}},{\"id\":\"h-ai\",\"type\":\"header\",\"data\":{\"text\":\"Why this distinction matters even more for AI agents\",\"level\":2},\"tunes\":{}},{\"id\":\"p-ai-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"AI agents can turn a permission mistake into a sequence of actions. If an agent is given a broad orders.read tool without tenant-scoped enforcement, a reasoning or prompt-injection failure can cause cross-tenant reads at machine speed.\"},\"tunes\":{}},{\"id\":\"p-ai-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Agent tool descriptions can mention tenant constraints, but enforcement must still happen in the trusted runtime\u002Fservice\u002Fdata layer. Natural-language instructions are not an authorization boundary.\"},\"tunes\":{}},{\"id\":\"p-ai-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The same applies to RAG: an agent can have permission to use the search tool while the search backend must still prevent Tenant A's query from returning Tenant B's chunks.\"},\"tunes\":{}},{\"id\":\"h-tests\",\"type\":\"header\",\"data\":{\"text\":\"Test RBAC and tenant isolation separately\",\"level\":2},\"tunes\":{}},{\"id\":\"tests-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Test family\",\"What it should prove\"],[\"Role demotion test\",\"A user without a permission cannot perform the operation even inside their own tenant\"],[\"Cross-tenant object test\",\"A user with the correct role still cannot access the same resource type in another tenant\"],[\"Identifier tampering\",\"Changing object\u002Ftenant IDs does not cross scope\"],[\"List\u002Fbulk endpoint test\",\"Broad queries return only authorized tenant data\"],[\"Cache reuse test\",\"Two tenants using reused processes\u002Fconnections never receive each other's cached state\"],[\"RLS request-role test\",\"Production request role cannot bypass row policies\"],[\"Async worker test\",\"Tenant context survives queueing and is revalidated at consumption\"],[\"Vector retrieval test\",\"Tenant A query never retrieves Tenant B chunks\"],[\"Platform-admin test\",\"Cross-tenant capability is explicit, narrow and auditable\"],[\"Offboarding test\",\"Tenant data and derived indexes\u002Fcaches are removed according to policy\"]]},\"tunes\":{}},{\"id\":\"p-tests-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"OWASP's authorization regression guidance specifically calls out cross-tenant boundary tests because code changes in caching, queries or shared services can silently break isolation even when role tests continue to pass.\"},\"tunes\":{}},{\"id\":\"h-failures\",\"type\":\"header\",\"data\":{\"text\":\"Common failure modes\",\"level\":2},\"tunes\":{}},{\"id\":\"failures-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Failure mode\",\"Why it fails\"],[\"Check role but not tenant\",\"Valid role becomes cross-tenant authority\"],[\"Trust tenant ID from request\",\"Client controls the isolation selector\"],[\"Scope UI but not API\",\"Hidden buttons do not protect backend resources\"],[\"Tenant-aware detail endpoint, unscoped list endpoint\",\"Bulk reads leak other tenants\"],[\"Tenant filter in most queries\",\"One forgotten path breaks the boundary\"],[\"Global cache keys\",\"Correct database isolation is bypassed by cached data\"],[\"Shared vector index without enforced metadata filters\",\"RAG retrieves another tenant's chunks\"],[\"Queue message tenant ID treated as authorization\",\"Forged or wrongly produced job can cross tenant boundary\"],[\"Platform admin modeled as ordinary ADMIN\",\"Cross-tenant power becomes implicit and difficult to audit\"],[\"Role copied globally across tenant memberships\",\"User receives permissions in tenants where they were never assigned\"],[\"Separate databases but shared privileged credential\",\"Application can still cross databases if its credential is too broad\"],[\"RLS with BYPASSRLS request role\",\"Database policy exists but does not protect the actual request path\"],[\"Random UUIDs treated as isolation\",\"Hard-to-guess identifiers reduce enumeration but do not authorize access\"]]},\"tunes\":{}},{\"id\":\"h-misconceptions\",\"type\":\"header\",\"data\":{\"text\":\"Common misconceptions\",\"level\":2},\"tunes\":{}},{\"id\":\"misconceptions-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Misconception\",\"Correction\"],[\"“RBAC provides tenant isolation.”\",\"RBAC controls permissions; isolation also requires tenant\u002Fresource scoping.\"],[\"“If the user is an admin, tenant checks are unnecessary.”\",\"Admin authority must still have an explicit scope.\"],[\"“Tenant ID in JWT is enough.”\",\"It can be a trusted input only if validated and applied consistently to every protected resource path.\"],[\"“Separate databases remove authorization requirements.”\",\"Users still need operation-level permissions inside their tenant.\"],[\"“A tenant_id column means the system is isolated.”\",\"The field only helps if access paths enforce it.\"],[\"“UUIDs prevent cross-tenant access.”\",\"Unpredictable identifiers are defense in depth, not authorization.\"],[\"“RLS means application code needs no security checks.”\",\"Application authorization, correct DB roles and policy coverage still matter.\"],[\"“One shared vector DB is unsafe.”\",\"It can be safe if isolation is enforceable and verified; physical separation is one option, not the only one.\"],[\"“Platform support needs global ADMIN.”\",\"Cross-tenant support should be a distinct, constrained and auditable authority.\"],[\"“Internal services can skip tenant checks.”\",\"Internal paths can still be compromised or misconfigured and must preserve tenant context.\"]]},\"tunes\":{}},{\"id\":\"h-design\",\"type\":\"header\",\"data\":{\"text\":\"A practical design sequence\",\"level\":2},\"tunes\":{}},{\"id\":\"design-flow\",\"type\":\"processFlow\",\"data\":{\"title\":\"Design permissions and isolation as separate dimensions\",\"orientation\":\"auto\",\"steps\":[{\"label\":\"1. Define tenant ownership\",\"description\":\"Classify which entities and resources are global, tenant-scoped, user-scoped or intentionally cross-tenant.\"},{\"label\":\"2. Define operations\",\"description\":\"Create explicit permissions for reads, writes, publishing, approvals, administration and other business actions.\"},{\"label\":\"3. Define roles\",\"description\":\"Group permissions according to responsibilities without embedding accidental global scope.\"},{\"label\":\"4. Define membership scope\",\"description\":\"Bind role assignments to the tenant\u002Fworkspace\u002Fproject context in which they apply.\"},{\"label\":\"5. Resolve trusted tenant context\",\"description\":\"Derive tenant identity from authenticated, server-verified membership or service authorization.\"},{\"label\":\"6. Enforce resource ownership\",\"description\":\"Apply tenant scope at every tenant-owned data\u002Fservice boundary.\"},{\"label\":\"7. Add defense in depth\",\"description\":\"Use RLS, separate credentials, schemas\u002Fdatabases, storage policies or policy engines where risk justifies them.\"},{\"label\":\"8. Carry scope through derived systems\",\"description\":\"Preserve tenant metadata in cache, search, vector indexes, queues, files and analytics.\"},{\"label\":\"9. Model cross-tenant operations explicitly\",\"description\":\"Separate platform administration and service identities from ordinary tenant roles.\"},{\"label\":\"10. Test both axes\",\"description\":\"Run negative tests for missing permission and for wrong tenant independently.\"},{\"label\":\"11. Audit tenant + permission together\",\"description\":\"Log who acted, in which tenant, on what target and under which authority.\"},{\"label\":\"12. Re-test after schema\u002Fruntime changes\",\"description\":\"Isolation can break when new tables, caches, queues or retrieval paths are introduced.\"}]},\"tunes\":{}},{\"id\":\"h-checklist\",\"type\":\"header\",\"data\":{\"text\":\"RBAC + tenant isolation checklist\",\"level\":2},\"tunes\":{}},{\"id\":\"checklist-table\",\"type\":\"table\",\"data\":{\"withHeadings\":true,\"stretched\":false,\"content\":[[\"Question\",\"Expected answer\"],[\"Who is the principal?\",\"Authenticated user\u002Fservice\u002Fagent identity\"],[\"Which tenant context applies?\",\"Server-verified membership or service scope\"],[\"Which operation is requested?\",\"Typed permission or policy action\"],[\"Does the principal have that permission?\",\"Role\u002Fpolicy decision\"],[\"Who owns the target resource?\",\"Explicit tenant\u002Fglobal\u002Fuser classification\"],[\"Does resource scope match authority?\",\"Tenant-aware lookup\u002Fpolicy\"],[\"Can storage bypass application checks?\",\"Defense-in-depth decision documented\"],[\"Are caches tenant-safe?\",\"Keys\u002Fnamespaces and authorization preserve tenant scope\"],[\"Are files\u002Fblobs tenant-safe?\",\"Object policy and signed URL issuance enforce scope\"],[\"Are async jobs tenant-safe?\",\"Verified context propagates and is revalidated\"],[\"Is RAG\u002Fsearch tenant-safe?\",\"Metadata\u002Fcollection isolation enforced before model context\"],[\"Are cross-tenant admins explicit?\",\"Separate authority, controls and audit\"],[\"Can ordinary credentials bypass isolation?\",\"No, or tightly documented exceptional path\"],[\"Are negative cross-tenant tests automated?\",\"Yes for every relevant access layer\"]]},\"tunes\":{}},{\"id\":\"h-edge\",\"type\":\"header\",\"data\":{\"text\":\"Edge cases and limitations\",\"level\":2},\"tunes\":{}},{\"id\":\"p-edge-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"A user can belong to multiple tenants. The current tenant should therefore be an explicit execution context, not inferred permanently from the user account.\"},\"tunes\":{}},{\"id\":\"p-edge-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"Some resources are intentionally shared between selected tenants, such as collaboration spaces or consortium data. This requires an explicit sharing model; pretending the resource belongs to one tenant and adding exceptions later usually creates ambiguous authorization.\"},\"tunes\":{}},{\"id\":\"p-edge-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"Noisy-neighbor isolation is related but different from confidentiality isolation. A tenant may never see another tenant's data yet still exhaust shared CPU, queue capacity or database connections. Rate limits and resource quotas can therefore be tenant-aware as an availability boundary.\"},\"tunes\":{}},{\"id\":\"p-edge-4\",\"type\":\"paragraph\",\"data\":{\"text\":\"Physical isolation is not automatically secure if control-plane credentials or administrative paths can cross boundaries. Logical isolation is not automatically weak if policies are centrally enforced, least-privileged and thoroughly tested.\"},\"tunes\":{}},{\"id\":\"p-edge-5\",\"type\":\"paragraph\",\"data\":{\"text\":\"Tenant isolation requirements can differ by data class. Public catalog data, billing records and private AI documents may justify different storage and encryption boundaries inside the same SaaS product.\"},\"tunes\":{}},{\"id\":\"h-change\",\"type\":\"header\",\"data\":{\"text\":\"What would change this answer?\",\"level\":2},\"tunes\":{}},{\"id\":\"p-change-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"The exact implementation changes with architecture: serverless APIs, Kubernetes, PostgreSQL, object storage, vector databases and policy engines expose different isolation primitives.\"},\"tunes\":{}},{\"id\":\"p-change-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"The required strength also changes with regulation, customer contracts, data sensitivity, threat model and operational scale. Some tenants may justify siloed databases or infrastructure while others share pooled resources.\"},\"tunes\":{}},{\"id\":\"p-change-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The conceptual distinction does not change: permission to perform an operation is not the same thing as permission to cross a tenant boundary.\"},\"tunes\":{}},{\"id\":\"h-related\",\"type\":\"header\",\"data\":{\"text\":\"Related canonical knowledge\",\"level\":2},\"tunes\":{}},{\"id\":\"p-related-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"S01 is a security-boundary prerequisite for Enterprise AI Architecture and AI Governance. Once AI tools, RAG or agents operate over multi-tenant data, tenant identity must travel through retrieval, tool execution, memory, caches and audit traces.\"},\"tunes\":{}},{\"id\":\"p-related-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"It also connects directly to Agentic AI: tool capability and role permission must still be constrained by tenant ownership before an agent can read or mutate business resources.\"},\"tunes\":{}},{\"id\":\"ref-agentic\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fde\u002Fblog\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained\",\"title\":\"MCP vs A2A vs UCP vs AP2 vs A2UI: The Agent Protocol Stack Explained\",\"excerpt\":\"Protocol interoperability does not replace authorization or tenant isolation. Capability discovery and business authority remain separate architecture concerns.\",\"ctaLabel\":\"Read the protocol stack article\"},\"tunes\":{}},{\"id\":\"p-related-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"For RAG, tenant isolation must be enforced before protected chunks reach model context.\"},\"tunes\":{}},{\"id\":\"ref-rag\",\"type\":\"referralArticle\",\"data\":{\"url\":\"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works\",\"title\":\"What Is RAG? The Simplest Explanation of How It Works\",\"excerpt\":\"The retrieval foundation for understanding where tenant-aware source filtering and vector-store isolation must be enforced.\",\"ctaLabel\":\"Read the RAG foundation\"},\"tunes\":{}},{\"id\":\"h-faq\",\"type\":\"header\",\"data\":{\"text\":\"Frequently asked questions\",\"level\":2},\"tunes\":{}},{\"id\":\"faq\",\"type\":\"faq\",\"data\":{\"title\":\"RBAC vs tenant isolation FAQ\",\"items\":[{\"id\":\"faq1\",\"question\":\"What is the difference between RBAC and tenant isolation?\",\"answer\":\"RBAC determines which operations a principal may perform. Tenant isolation determines which tenant's resources those operations may access. Secure multi-tenant applications normally need both.\"},{\"id\":\"faq2\",\"question\":\"Does an ADMIN role automatically allow access to all tenants?\",\"answer\":\"No. ADMIN should have an explicit scope. A tenant administrator normally has broad permissions only inside that tenant, while cross-tenant platform administration should be modeled separately.\"},{\"id\":\"faq3\",\"question\":\"Is authentication enough for tenant isolation?\",\"answer\":\"No. Authentication proves identity. Authorization controls permitted actions. Tenant isolation additionally prevents those actions from reaching the wrong tenant's resources.\"},{\"id\":\"faq4\",\"question\":\"Should tenantId be stored in the JWT?\",\"answer\":\"It can be one input to tenant context, but the server must verify current membership\u002Fauthority and enforce the scope at protected resource boundaries. A claim alone does not replace isolation controls.\"},{\"id\":\"faq5\",\"question\":\"Do I need a separate database per tenant?\",\"answer\":\"Not necessarily. Shared-table, RLS, schema, database, infrastructure and hybrid isolation models can all be valid depending on risk and operational requirements.\"},{\"id\":\"faq6\",\"question\":\"Can PostgreSQL RLS replace tenant filters in application code?\",\"answer\":\"RLS can provide strong defense in depth, but correct database roles, request context, policy coverage and application-level authorization still matter.\"},{\"id\":\"faq7\",\"question\":\"How should RAG enforce tenant isolation?\",\"answer\":\"Tenant\u002Faccess scope should be enforced during retrieval so unauthorized chunks never enter model context. Preserve access metadata through chunking and indexing.\"},{\"id\":\"faq8\",\"question\":\"Can one user have different roles in different tenants?\",\"answer\":\"Yes. This is common in B2B SaaS and is a strong reason to scope role assignments by tenant membership rather than treating roles as globally attached to the user.\"},{\"id\":\"faq9\",\"question\":\"What is the best test for tenant isolation?\",\"answer\":\"Use negative cross-tenant tests: create at least two tenants, give a user valid permissions in one tenant, then prove every protected path denies access to the other tenant's resources.\"}]},\"tunes\":{}},{\"id\":\"h-glossary\",\"type\":\"header\",\"data\":{\"text\":\"Glossary\",\"level\":2},\"tunes\":{}},{\"id\":\"glossary\",\"type\":\"glossary\",\"data\":{\"title\":\"Key multi-tenant security terms\",\"entries\":[{\"term\":\"RBAC\",\"definition\":\"Role-Based Access Control: an authorization model that associates permissions with roles and assigns users or principals to those roles.\",\"anchor\":\"rbac\"},{\"term\":\"Tenant\",\"definition\":\"A customer, organization, workspace or other isolated logical consumer of a shared multi-tenant system.\",\"anchor\":\"tenant\"},{\"term\":\"Tenant isolation\",\"definition\":\"Mechanisms that prevent one tenant from accessing, modifying or receiving another tenant's resources in a shared system.\",\"anchor\":\"tenant-isolation\"},{\"term\":\"Authentication\",\"definition\":\"Verification of the identity of a user, service or other principal.\",\"anchor\":\"authentication\"},{\"term\":\"Authorization\",\"definition\":\"Decision process that determines whether a principal may perform a requested operation on a resource.\",\"anchor\":\"authorization\"},{\"term\":\"Permission\",\"definition\":\"A defined allowed operation or capability such as orders.read or users.write.\",\"anchor\":\"permission\"},{\"term\":\"Role\",\"definition\":\"A named grouping of permissions associated with a responsibility or function.\",\"anchor\":\"role\"},{\"term\":\"ABAC\",\"definition\":\"Attribute-Based Access Control: authorization based on attributes of the principal, resource, action or environment.\",\"anchor\":\"abac\"},{\"term\":\"Row-Level Security\",\"definition\":\"Database policy mechanism that restricts which rows a database role or session may read or modify.\",\"anchor\":\"row-level-security\"},{\"term\":\"Cross-tenant access\",\"definition\":\"Any access path in which a principal operating under one tenant context reaches resources belonging to another tenant.\",\"anchor\":\"cross-tenant-access\"},{\"term\":\"Platform administrator\",\"definition\":\"A privileged operational identity with explicitly modeled authority that may span multiple tenants.\",\"anchor\":\"platform-administrator\"},{\"term\":\"Tenant context\",\"definition\":\"The verified tenant scope under which the current request, job or agent operation executes.\",\"anchor\":\"tenant-context\"}]},\"tunes\":{}},{\"id\":\"h-conclusion\",\"type\":\"header\",\"data\":{\"text\":\"Conclusion\",\"level\":2},\"tunes\":{}},{\"id\":\"p-conclusion-1\",\"type\":\"paragraph\",\"data\":{\"text\":\"RBAC and tenant isolation are complementary, not competing security mechanisms. RBAC structures operational permission; tenant isolation constrains the resource boundary inside which that permission can apply.\"},\"tunes\":{}},{\"id\":\"p-conclusion-2\",\"type\":\"paragraph\",\"data\":{\"text\":\"A robust multi-tenant request therefore needs more than “user has role ADMIN.” It needs a verified principal, verified tenant context, an allowed operation, a tenant-scoped target and enforcement at every resource layer that can carry tenant-owned data.\"},\"tunes\":{}},{\"id\":\"p-conclusion-3\",\"type\":\"paragraph\",\"data\":{\"text\":\"The shortest reliable rule is: authorize the action, then isolate the scope — and never assume one proves the other.\"},\"tunes\":{}},{\"id\":\"h-sources\",\"type\":\"header\",\"data\":{\"text\":\"Primary sources and current guidance\",\"level\":2},\"tunes\":{}},{\"id\":\"p-sources-note\",\"type\":\"paragraph\",\"data\":{\"text\":\"The sources below support the RBAC definition and current tenant-isolation guidance. The Aaasaasa AI CMS section is original implementation evidence and is intentionally bounded to the code patterns that were verified.\"},\"tunes\":{}},{\"id\":\"src-nist-rbac\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fcsrc.nist.gov\u002Fprojects\u002Frole-based-access-control\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST — Role Based Access Control\",\"description\":\"NIST overview of RBAC models and the INCITS RBAC standard, including users, roles, permissions, operations and objects.\"}},\"tunes\":{}},{\"id\":\"src-nist-glossary\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fcsrc.nist.gov\u002Fglossary\u002Fterm\u002Frole_based_access_control\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"NIST CSRC — RBAC glossary\",\"description\":\"Current NIST glossary definitions of role-based access control as permission assignment through roles.\"}},\"tunes\":{}},{\"id\":\"src-aws-isolation\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fwhitepapers\u002Flatest\u002Fsaas-tenant-isolation-strategies\u002Fthe-isolation-mindset.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS — The isolation mindset\",\"description\":\"AWS SaaS guidance explicitly distinguishing authentication\u002Fauthorization from tenant isolation and recommending shared isolation mechanisms.\"}},\"tunes\":{}},{\"id\":\"src-aws-faq\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fsaas-multitenant-api-access-authorization\u002Ffaq.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS — Multi-tenant authorization FAQ\",\"description\":\"Current guidance explaining the difference between authorization and tenant isolation in SaaS applications.\"}},\"tunes\":{}},{\"id\":\"src-aws-avp\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fdocs.aws.amazon.com\u002Fprescriptive-guidance\u002Flatest\u002Fsaas-multitenant-api-access-authorization\u002Favp-design-considerations.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"AWS — Multi-tenant design considerations\",\"description\":\"Current SaaS guidance distinguishing tenant isolation from authorization and discussing pooled\u002Fsiloed authorization policy models.\"}},\"tunes\":{}},{\"id\":\"src-owasp-multi\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FMulti_Tenant_Security_Cheat_Sheet.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"OWASP — Multi-Tenant Application Security Cheat Sheet\",\"description\":\"Current practical guidance for tenant context, database isolation, caches, storage, queues, testing and cross-tenant access prevention.\"}},\"tunes\":{}},{\"id\":\"src-owasp-rag\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FRAG_Security_Cheat_Sheet.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"OWASP — RAG Security Cheat Sheet\",\"description\":\"Current guidance requiring access control at retrieval time and tenant isolation for multi-tenant vector stores.\"}},\"tunes\":{}},{\"id\":\"src-owasp-auth-test\",\"type\":\"linkTool\",\"data\":{\"link\":\"https:\u002F\u002Fcheatsheetseries.owasp.org\u002Fcheatsheets\u002FAuthorization_Regression_Testing_Cheat_Sheet.html\",\"meta\":{\"image\":{\"url\":\"\"},\"title\":\"OWASP — Authorization Regression Testing\",\"description\":\"Current testing guidance including role-demotion and cross-tenant boundary tests.\"}},\"tunes\":{}}],\"version\":\"2.31.6\"}",{"time":1451,"blocks":1452,"version":2435},1791485112883,[1453,1457,1462,1467,1472,1476,1480,1484,1488,1492,1496,1500,1504,1508,1512,1516,1520,1524,1547,1551,1555,1559,1563,1567,1594,1598,1616,1620,1624,1628,1632,1636,1640,1644,1648,1652,1656,1660,1670,1674,1678,1682,1686,1691,1695,1727,1731,1735,1739,1743,1747,1751,1755,1759,1763,1767,1771,1775,1779,1783,1787,1791,1795,1799,1803,1807,1811,1816,1820,1824,1828,1832,1836,1840,1844,1848,1852,1856,1860,1864,1868,1872,1876,1880,1905,1909,1914,1918,1922,1926,1930,1934,1959,1964,1968,1972,1976,1980,1984,2021,2025,2029,2075,2079,2115,2119,2160,2164,2212,2216,2220,2224,2228,2232,2236,2240,2244,2248,2252,2256,2260,2264,2270,2274,2281,2285,2317,2321,2356,2359,2363,2367,2371,2375,2379,2386,2393,2400,2407,2414,2421,2428],{"id":215,"data":1454,"type":218,"tunes":1456},{"text":1455},"RBAC and tenant isolation solve two different security problems in multi-tenant systems. Role-Based Access Control (RBAC) determines what an authenticated principal is allowed to do, such as read orders, edit products or manage users. Tenant isolation determines which tenant's data, resources and execution context that principal is allowed to access. A user can be correctly authenticated and correctly assigned an RBAC role yet still experience a security failure if the application lets that role operate on another tenant's resources.",{},{"id":221,"data":1458,"type":226,"tunes":1461},{"body":1459,"title":1460,"variant":225},"\u003Cstrong>RBAC answers “what may this identity do?” Tenant isolation answers “inside whose boundary may it do it?”\u003C\u002Fstrong>\u003Cbr>\u003Cbr>A secure multi-tenant application normally needs both. A tenant administrator may have broad permissions, but those permissions should remain constrained to the administrator's tenant unless an explicitly separate platform-level authority exists.","Direct answer",{},{"id":229,"data":1463,"type":226,"tunes":1466},{"body":1464,"title":1465,"variant":233},"Giving a user the role \u003Ccode>ADMIN\u003C\u002Fcode> does not automatically imply “administrator of tenant A only.” The role must be evaluated together with verified tenant context and the target resource's tenant ownership. Otherwise a valid role can become a cross-tenant privilege.","A role is not a tenant boundary",{},{"id":236,"data":1468,"type":226,"tunes":1471},{"body":1469,"title":1470,"variant":240},"The underlying distinction is stable. NIST defines RBAC around users, roles, permissions, operations and objects. Current AWS SaaS guidance explicitly states that authentication and authorization are not equal to tenant isolation, and that a user can be authenticated and authorized while still accessing another tenant's resources if isolation is not separately enforced. OWASP's current Multi-Tenant Security guidance likewise treats tenant isolation as a cross-layer requirement covering APIs, databases, caches, storage, queues and other shared resources.","Current-source note — 8 October 2026",{},{"id":243,"data":1473,"type":248,"tunes":1475},{"title":1474,"maxLevel":246,"minLevel":247},"Contents",{},{"id":251,"data":1477,"type":42,"tunes":1479},{"text":1478,"level":247},"What RBAC really controls",{},{"id":256,"data":1481,"type":218,"tunes":1483},{"text":1482},"RBAC is an authorization model in which permissions are associated with roles and users are assigned to those roles. The role acts as an administrative abstraction between identities and permissions.",{},{"id":261,"data":1485,"type":218,"tunes":1487},{"text":1486},"NIST's classic RBAC work formalizes this around users, roles, permissions, operations and objects. The practical benefit is that an organization can manage authorization through relatively stable job or responsibility roles rather than attaching every permission directly to every user.",{},{"id":266,"data":1489,"type":218,"tunes":1491},{"text":1490},"A role such as EDITOR can therefore mean: may read content, write content and publish content. A role such as ACCOUNTANT may mean: may read billing data, reconcile invoices and approve settlements.",{},{"id":271,"data":1493,"type":42,"tunes":1495},{"text":1494,"level":247},"What tenant isolation really controls",{},{"id":276,"data":1497,"type":218,"tunes":1499},{"text":1498},"Tenant isolation is the set of mechanisms that prevents one tenant from reading, modifying, influencing or accidentally receiving another tenant's resources in a shared system.",{},{"id":281,"data":1501,"type":218,"tunes":1503},{"text":1502},"The protected boundary is broader than database rows. Tenant-specific state can exist in relational tables, object storage, vector indexes, caches, search indexes, queue messages, files, temporary artifacts, background jobs, analytics, rate limits and infrastructure resources.",{},{"id":286,"data":1505,"type":218,"tunes":1507},{"text":1506},"AWS's SaaS guidance makes the distinction explicit: authorization grants access to resources, while tenant isolation ensures those resources cannot cross the wrong tenant boundary even when infrastructure is shared.",{},{"id":291,"data":1509,"type":42,"tunes":1511},{"text":1510,"level":247},"The simplest example",{},{"id":296,"data":1513,"type":218,"tunes":1515},{"text":1514},"Suppose Alice is an administrator for Tenant A and Bob is an administrator for Tenant B. Both users legitimately hold the same ADMIN role.",{},{"id":301,"data":1517,"type":218,"tunes":1519},{"text":1518},"RBAC can correctly conclude that both users may execute an operation such as users.read. But when Alice requests user ID 847, the application must still verify that user 847 belongs to Tenant A.",{},{"id":306,"data":1521,"type":218,"tunes":1523},{"text":1522},"If the API checks only “Alice has ADMIN” and then executes SELECT * FROM users WHERE id = 847, RBAC succeeded while tenant isolation failed.",{},{"id":311,"data":1525,"type":334,"tunes":1546},{"steps":1526,"title":1545,"orientation":333},[1527,1530,1533,1536,1539,1542],{"label":1528,"description":1529},"1. Authenticate principal","Establish who the user, service or agent is.",{"label":1531,"description":1532},"2. Resolve verified tenant context","Determine which tenant context applies from trusted server-side identity\u002Fmembership information.",{"label":1534,"description":1535},"3. Resolve permission","Evaluate whether the principal's role or policy permits the requested operation.",{"label":1537,"description":1538},"4. Scope the target resource","Verify that the target object belongs to the permitted tenant or explicitly shared scope.",{"label":1540,"description":1541},"5. Enforce at the access boundary","Perform the database, cache, storage, queue or service operation with tenant constraints applied.",{"label":1543,"description":1544},"6. Audit both dimensions","Record principal, tenant, operation, target and result so cross-tenant attempts are visible.","A correct multi-tenant authorization decision",{},{"id":337,"data":1548,"type":42,"tunes":1550},{"text":1549,"level":247},"Where the simple example stops",{},{"id":342,"data":1552,"type":218,"tunes":1554},{"text":1553},"Real systems often contain several classes of identity: tenant users, platform administrators, background workers, integrations, agents and cross-tenant operational services. Some of these legitimately cross tenant boundaries.",{},{"id":347,"data":1556,"type":218,"tunes":1558},{"text":1557},"That does not remove the need for isolation. It means cross-tenant authority must be explicit, narrow and separately auditable rather than emerging accidentally from a global role or unscoped database connection.",{},{"id":352,"data":1560,"type":218,"tunes":1562},{"text":1561},"Tenant isolation can also vary by layer. A product may share application servers while separating databases, or use a shared database with row-level policies while giving premium tenants isolated storage or compute. There is no single universal isolation topology.",{},{"id":357,"data":1564,"type":42,"tunes":1566},{"text":1565,"level":247},"RBAC vs tenant isolation",{},{"id":362,"data":1568,"type":399,"tunes":1593},{"rows":1569,"title":1588,"layout":391,"columns":1589},[1570,1573,1576,1579,1582,1585],{"id":366,"label":1571,"values":1572},"Primary question",[369,369],{"id":371,"label":1574,"values":1575},"Typical unit",[369,369],{"id":375,"label":1577,"values":1578},"Example",[369,369],{"id":379,"label":1580,"values":1581},"Typical failure",[369,369],{"id":383,"label":1583,"values":1584},"Typical implementation",[369,369],{"id":387,"label":1586,"values":1587},"Can it exist alone?",[369,369],"Two different security dimensions",[1590,1591],{"id":394,"label":395},{"id":397,"label":1592},"Tenant isolation",{},{"id":402,"data":1595,"type":42,"tunes":1597},{"text":1596,"level":247},"Authentication, authorization and isolation are three different checks",{},{"id":407,"data":1599,"type":391,"tunes":1615},{"content":1600,"stretched":43,"withHeadings":14},[1601,1604,1608,1612],[1602,412,1603],"Layer","Example failure",[1605,1606,1607],"Authentication","Who is this principal?","Attacker impersonates Alice",[1609,1610,1611],"Authorization \u002F RBAC","May this principal perform this operation?","Viewer can delete users",[1592,1613,1614],"May this operation reach this tenant\u002Fresource boundary?","Tenant A admin reads Tenant B order",{},{"id":427,"data":1617,"type":218,"tunes":1619},{"text":1618},"These checks are related but non-substitutable. Authentication can be perfect while authorization fails. Authorization can be correct while tenant isolation fails. A secure SaaS request path needs all applicable boundaries.",{},{"id":432,"data":1621,"type":42,"tunes":1623},{"text":1622,"level":247},"Roles need a scope",{},{"id":437,"data":1625,"type":218,"tunes":1627},{"text":1626},"The word ADMIN is incomplete without scope. It can mean platform administrator, tenant administrator, project administrator, workspace administrator or administrator of one subsystem.",{},{"id":442,"data":1629,"type":218,"tunes":1631},{"text":1630},"In multi-tenant systems, role assignment should normally be associated with tenant membership or another explicit resource scope. The same user may legitimately be ADMIN in Tenant A and VIEWER in Tenant B.",{},{"id":447,"data":1633,"type":218,"tunes":1635},{"text":1634},"A global role model that ignores this distinction can create privilege leakage even when the permission map itself is correct.",{},{"id":452,"data":1637,"type":42,"tunes":1639},{"text":1638,"level":247},"Tenant context must come from a trusted path",{},{"id":457,"data":1641,"type":218,"tunes":1643},{"text":1642},"A tenant ID supplied by the client is useful as a selector, but it is not proof of authority. The server must derive or verify tenant membership against authenticated identity and current authorization data.",{},{"id":462,"data":1645,"type":218,"tunes":1647},{"text":1646},"OWASP's current multi-tenant guidance recommends establishing tenant context early in the request lifecycle and explicitly warns against treating client headers or request parameters as authorization proof.",{},{"id":467,"data":1649,"type":218,"tunes":1651},{"text":1650},"This matters because a trivial request modification from tenant=A to tenant=B must not be sufficient to cross the isolation boundary.",{},{"id":472,"data":1653,"type":42,"tunes":1655},{"text":1654,"level":247},"Tenant scope belongs in the resource lookup",{},{"id":477,"data":1657,"type":218,"tunes":1659},{"text":1658},"A common application-level isolation pattern is to include tenant scope in the same query that resolves the resource.",{},{"id":482,"data":1661,"type":391,"tunes":1669},{"content":1662,"stretched":43,"withHeadings":14},[1663,1666,1667,1668],[1664,1665],"Weak lookup","Stronger tenant-scoped lookup",[489,490],[492,493],[495,496],{},{"id":499,"data":1671,"type":218,"tunes":1673},{"text":1672},"This pattern is not the only possible isolation mechanism, but it keeps tenant ownership close to the data access operation and prevents an object ID from becoming a cross-tenant capability.",{},{"id":504,"data":1675,"type":42,"tunes":1677},{"text":1676,"level":247},"Application checks are useful, but isolation should not depend on perfect developer behavior",{},{"id":509,"data":1679,"type":218,"tunes":1681},{"text":1680},"AWS's isolation guidance explicitly warns against leaving isolation enforcement only to service developers. In a large codebase, eventually one query, cache key or worker path may omit tenant scope.",{},{"id":514,"data":1683,"type":218,"tunes":1685},{"text":1684},"Defense in depth can therefore move isolation into shared middleware, repository\u002Fservice layers, policy engines, database Row-Level Security, dedicated credentials, separate schemas or separate databases depending on risk and architecture.",{},{"id":519,"data":1687,"type":226,"tunes":1690},{"body":1688,"title":1689,"variant":523},"The strongest boundary is one that ordinary application code cannot casually bypass by omitting one \u003Ccode>tenantId\u003C\u002Fcode> condition.","Isolation should be hard to forget",{},{"id":526,"data":1692,"type":42,"tunes":1694},{"text":1693,"level":247},"Database isolation strategies",{},{"id":531,"data":1696,"type":391,"tunes":1726},{"content":1697,"stretched":43,"withHeadings":14},[1698,1702,1706,1710,1714,1718,1722],[1699,1700,1701],"Strategy","Boundary","Strength \u002F trade-off",[1703,1704,1705],"Shared tables + tenant key","Row\u002Fapplication policy","Operationally efficient; requires exhaustive tenant scoping and strong tests",[1707,1708,1709],"Shared tables + database RLS","Database policy boundary","Reduces dependence on every application query; requires correct roles, session\u002Ftransaction tenant context and policy coverage",[1711,1712,1713],"Separate schemas","Namespace \u002F DB-role boundary","Stronger logical separation; more operational complexity",[1715,1716,1717],"Separate databases","Database \u002F credential boundary","Strong isolation and simpler blast-radius story; higher provisioning and operations cost",[1719,1720,1721],"Separate infrastructure\u002Faccount","Infrastructure boundary","Strongest coarse-grained separation; highest cost and operational overhead",[1723,1724,1725],"Hybrid","Per workload\u002Fdata class","Allows stronger isolation only where risk\u002Fcompliance justifies it",{},{"id":564,"data":1728,"type":218,"tunes":1730},{"text":1729},"OWASP's current Multi-Tenant Security Cheat Sheet lists separate databases, separate schemas, shared tables with row-level controls and hybrid models. The correct model depends on threat level, compliance, performance and operational cost.",{},{"id":569,"data":1732,"type":42,"tunes":1734},{"text":1733,"level":247},"PostgreSQL Row-Level Security can provide defense in depth",{},{"id":574,"data":1736,"type":218,"tunes":1738},{"text":1737},"With shared tables, PostgreSQL Row-Level Security can enforce a tenant predicate at the database layer so ordinary queries cannot see rows outside the active tenant policy.",{},{"id":579,"data":1740,"type":218,"tunes":1742},{"text":1741},"However, RLS is not magic. PostgreSQL superusers and roles with BYPASSRLS can bypass row policies. OWASP therefore recommends using a least-privileged request-path role and testing the same connection\u002Fpooling mode used in production.",{},{"id":584,"data":1744,"type":218,"tunes":1746},{"text":1745},"Connection reuse is another important edge: tenant context must be set and reset safely for every transaction\u002Frequest so one pooled connection cannot leak prior tenant state.",{},{"id":589,"data":1748,"type":42,"tunes":1750},{"text":1749,"level":247},"Tenant isolation must include caches",{},{"id":594,"data":1752,"type":218,"tunes":1754},{"text":1753},"A database query can be perfectly scoped and still leak data through a shared cache key.",{},{"id":599,"data":1756,"type":218,"tunes":1758},{"text":1757},"If user:42 exists in both Tenant A and Tenant B, a global cache key can return the wrong tenant's value. Tenant-sensitive cache keys should include every attribute that changes visibility or result semantics, commonly tenant, user, locale, feature set or permission version.",{},{"id":604,"data":1760,"type":218,"tunes":1762},{"text":1761},"Cache partitioning is defense in depth, not a replacement for authorization. The request still needs to be authorized before protected cached content is returned.",{},{"id":609,"data":1764,"type":42,"tunes":1766},{"text":1765,"level":247},"Files and object storage need their own tenant boundary",{},{"id":614,"data":1768,"type":218,"tunes":1770},{"text":1769},"Object storage should distinguish global, tenant-scoped and user-scoped objects. A folder prefix alone is only a naming convention unless access policy actually constrains reads and writes.",{},{"id":619,"data":1772,"type":218,"tunes":1774},{"text":1773},"Stronger designs may use tenant-aware object keys, bucket policies, separate buckets\u002Faccounts or tenant-specific encryption keys where risk or compliance requires stronger isolation.",{},{"id":624,"data":1776,"type":218,"tunes":1778},{"text":1777},"Signed URLs must be authorized before issuance and scoped to the exact object and operation. Possession of an object identifier should not itself grant cross-tenant access.",{},{"id":629,"data":1780,"type":42,"tunes":1782},{"text":1781,"level":247},"Background jobs and queues can break isolation",{},{"id":634,"data":1784,"type":218,"tunes":1786},{"text":1785},"Async jobs often leave the original HTTP request context, which makes tenant propagation easy to mishandle. A queue message containing tenantId is not sufficient proof that the producer was authorized.",{},{"id":639,"data":1788,"type":218,"tunes":1790},{"text":1789},"The worker should carry a verified service\u002Fuser identity or trusted job envelope, re-establish tenant context and re-authorize consequential operations at the consumer boundary.",{},{"id":644,"data":1792,"type":218,"tunes":1794},{"text":1793},"Tenant isolation also includes availability. One tenant should not be able to monopolize shared workers, queues, connection pools or compute in ways that materially degrade other tenants.",{},{"id":649,"data":1796,"type":42,"tunes":1798},{"text":1797,"level":247},"Search and RAG need tenant-aware retrieval",{},{"id":654,"data":1800,"type":218,"tunes":1802},{"text":1801},"Multi-tenant AI introduces another copy of the isolation problem. Documents may be chunked, embedded and stored in a vector index after ingestion.",{},{"id":659,"data":1804,"type":218,"tunes":1806},{"text":1805},"OWASP's current RAG security guidance states that access control must be enforced at retrieval time and that chunks from Tenant A must not be retrieved by queries from Tenant B. Document-level permissions cannot simply be assumed to survive chunking automatically.",{},{"id":664,"data":1808,"type":218,"tunes":1810},{"text":1809},"The vector index therefore needs tenant\u002Faccess metadata or physically\u002Flogically separate collections according to the isolation design. Retrieval filters should be applied before unauthorized content can enter model context.",{},{"id":669,"data":1812,"type":226,"tunes":1815},{"body":1813,"title":1814,"variant":233},"Do not retrieve cross-tenant chunks and then instruct the language model to ignore them. Once protected data enters model context, the isolation boundary has already failed.","The model must never be the tenant filter",{},{"id":675,"data":1817,"type":42,"tunes":1819},{"text":1818,"level":247},"Derived data inherits tenant sensitivity",{},{"id":680,"data":1821,"type":218,"tunes":1823},{"text":1822},"Embeddings, search indexes, thumbnails, generated summaries, caches, analytics rows and AI responses are derived from source data. Their tenant scope should follow the source unless an explicit transformation creates a legitimate shared\u002Fglobal artifact.",{},{"id":685,"data":1825,"type":218,"tunes":1827},{"text":1826},"Deletion and offboarding must therefore propagate beyond the canonical row. Removing a tenant document while leaving searchable chunks or cached summaries can retain cross-tenant or post-retention exposure.",{},{"id":690,"data":1829,"type":42,"tunes":1831},{"text":1830,"level":247},"Not everything belongs to a tenant",{},{"id":695,"data":1833,"type":218,"tunes":1835},{"text":1834},"Multi-tenant platforms often have intentionally global resources: product taxonomies, public templates, system permissions, feature definitions or public content.",{},{"id":700,"data":1837,"type":218,"tunes":1839},{"text":1838},"The safest model is explicit classification: global, tenant-scoped, user-scoped or explicitly cross-tenant. Ambiguous resources are where accidental leakage begins.",{},{"id":705,"data":1841,"type":218,"tunes":1843},{"text":1842},"An intentionally shared object should have a documented reason for being global rather than simply lacking a tenant association.",{},{"id":710,"data":1845,"type":42,"tunes":1847},{"text":1846,"level":247},"Platform administrators require a different authority model",{},{"id":715,"data":1849,"type":218,"tunes":1851},{"text":1850},"A platform operator may need to inspect multiple tenants for support, compliance or infrastructure operations. Modeling this as an ordinary tenant ADMIN with accidental global database access weakens both security and auditability.",{},{"id":720,"data":1853,"type":218,"tunes":1855},{"text":1854},"A better design uses a distinct platform identity or explicit cross-tenant permission, stronger authentication, purpose limitation, detailed audit and, where appropriate, approval or break-glass controls.",{},{"id":725,"data":1857,"type":218,"tunes":1859},{"text":1858},"Cross-tenant access should therefore be a named capability, not the absence of a tenant filter.",{},{"id":730,"data":1861,"type":42,"tunes":1863},{"text":1862,"level":247},"RBAC can be combined with attributes",{},{"id":735,"data":1865,"type":218,"tunes":1867},{"text":1866},"Some decisions depend on more than role. Tenant membership, region, resource owner, subscription tier, time, project membership or data classification can all affect access.",{},{"id":740,"data":1869,"type":218,"tunes":1871},{"text":1870},"RBAC and ABAC are not mutually exclusive. AWS's current multi-tenant authorization guidance discusses RBAC, ABAC and hybrid models. A role can define broad responsibility while attributes constrain which concrete resource instance can be accessed.",{},{"id":745,"data":1873,"type":218,"tunes":1875},{"text":1874},"The key architecture rule remains: do not encode tenant isolation only as an incidental role name if tenant identity is a first-class resource boundary.",{},{"id":750,"data":1877,"type":42,"tunes":1879},{"text":1878,"level":247},"Authorization decisions are at least two-dimensional",{},{"id":755,"data":1881,"type":391,"tunes":1904},{"content":1882,"stretched":43,"withHeadings":14},[1883,1887,1890,1893,1895,1896,1900],[759,1884,1885,1886],"Role permission","Tenant relationship","Decision",[764,765,1888,1889],"Order belongs to Alice's tenant","Allow",[764,765,1891,1892],"Order belongs to another tenant","Deny",[764,772,1888,1894],"Allow if role includes write",[764,772,1891,1892],[1897,777,1898,1899],"Platform support","Explicit support scope + audited target tenant","Potentially allow under platform policy",[1901,782,1902,1903],"Background worker","Trusted service scope for job tenant","Allow only for verified job tenant",{},{"id":787,"data":1906,"type":42,"tunes":1908},{"text":1907,"level":247},"Original implementation evidence: Aaasaasa AI CMS",{},{"id":792,"data":1910,"type":226,"tunes":1913},{"body":1911,"title":1912,"variant":240},"Aaasaasa AI CMS contains a concrete tenant-scoped RBAC implementation. It is useful evidence for how role authorization and tenant scope can be combined, but it should not be presented as proof that every storage, cache or infrastructure layer has complete tenant isolation.","Original implementation evidence",{},{"id":798,"data":1915,"type":218,"tunes":1917},{"text":1916},"The RBAC service defines typed permission codes such as cms.content.read, shop.orders.write, billing.reconcile and users.roles. System roles map those permissions into named responsibility sets.",{},{"id":803,"data":1919,"type":218,"tunes":1921},{"text":1920},"Role records are created and resolved with a tenantId. System roles are upserted using a composite tenant\u002Fcode identity, and role listing is filtered by tenant.",{},{"id":808,"data":1923,"type":218,"tunes":1925},{"text":1924},"Role update and deletion first resolve the role using both role ID and tenant ID. User-role assignments are also stored and replaced under the current tenant context.",{},{"id":813,"data":1927,"type":218,"tunes":1929},{"text":1928},"Permission resolution reads explicit user-role assignments scoped by both tenantId and userId. This prevents one tenant's role assignment from automatically becoming another tenant's role assignment.",{},{"id":818,"data":1931,"type":218,"tunes":1933},{"text":1932},"At API level, administrative RBAC routes resolve a tenant context before creating or modifying roles. This is the correct direction: permission administration itself must respect tenancy.",{},{"id":823,"data":1935,"type":391,"tunes":1958},{"content":1936,"stretched":43,"withHeadings":14},[1937,1940,1943,1946,1949,1952,1955],[1938,1939],"Observed implementation pattern","Security meaning",[1941,1942],"Typed permission codes","RBAC operation vocabulary is explicit",[1944,1945],"System role → permission maps","Roles aggregate permissions rather than hard-coding users",[1947,1948],"tenantId_code role identity","Same logical role can exist separately per tenant",[1950,1951],"Role lookup uses id + tenantId","Role mutation is tenant-scoped",[1953,1954],"User-role relation stores tenantId","Membership is not globally inferred from role alone",[1956,1957],"Permission resolution uses tenantId + userId","Authorization is evaluated inside tenant context",{},{"id":849,"data":1960,"type":226,"tunes":1963},{"body":1961,"title":1962,"variant":233},"Tenant-scoped RBAC is one layer. Complete tenant isolation must also cover all tenant-owned resource lookups, databases, caches, files, search\u002Fvector indexes, background jobs, integrations and operational paths. The repository evidence here supports the RBAC\u002Ftenant-scope design pattern, not a claim of independently audited SaaS isolation.","What this evidence does not prove",{},{"id":855,"data":1965,"type":42,"tunes":1967},{"text":1966,"level":247},"Why this distinction matters even more for AI agents",{},{"id":860,"data":1969,"type":218,"tunes":1971},{"text":1970},"AI agents can turn a permission mistake into a sequence of actions. If an agent is given a broad orders.read tool without tenant-scoped enforcement, a reasoning or prompt-injection failure can cause cross-tenant reads at machine speed.",{},{"id":865,"data":1973,"type":218,"tunes":1975},{"text":1974},"Agent tool descriptions can mention tenant constraints, but enforcement must still happen in the trusted runtime\u002Fservice\u002Fdata layer. Natural-language instructions are not an authorization boundary.",{},{"id":870,"data":1977,"type":218,"tunes":1979},{"text":1978},"The same applies to RAG: an agent can have permission to use the search tool while the search backend must still prevent Tenant A's query from returning Tenant B's chunks.",{},{"id":875,"data":1981,"type":42,"tunes":1983},{"text":1982,"level":247},"Test RBAC and tenant isolation separately",{},{"id":880,"data":1985,"type":391,"tunes":2020},{"content":1986,"stretched":43,"withHeadings":14},[1987,1990,1993,1996,1999,2002,2005,2008,2011,2014,2017],[1988,1989],"Test family","What it should prove",[1991,1992],"Role demotion test","A user without a permission cannot perform the operation even inside their own tenant",[1994,1995],"Cross-tenant object test","A user with the correct role still cannot access the same resource type in another tenant",[1997,1998],"Identifier tampering","Changing object\u002Ftenant IDs does not cross scope",[2000,2001],"List\u002Fbulk endpoint test","Broad queries return only authorized tenant data",[2003,2004],"Cache reuse test","Two tenants using reused processes\u002Fconnections never receive each other's cached state",[2006,2007],"RLS request-role test","Production request role cannot bypass row policies",[2009,2010],"Async worker test","Tenant context survives queueing and is revalidated at consumption",[2012,2013],"Vector retrieval test","Tenant A query never retrieves Tenant B chunks",[2015,2016],"Platform-admin test","Cross-tenant capability is explicit, narrow and auditable",[2018,2019],"Offboarding test","Tenant data and derived indexes\u002Fcaches are removed according to policy",{},{"id":918,"data":2022,"type":218,"tunes":2024},{"text":2023},"OWASP's authorization regression guidance specifically calls out cross-tenant boundary tests because code changes in caching, queries or shared services can silently break isolation even when role tests continue to pass.",{},{"id":923,"data":2026,"type":42,"tunes":2028},{"text":2027,"level":247},"Common failure modes",{},{"id":928,"data":2030,"type":391,"tunes":2074},{"content":2031,"stretched":43,"withHeadings":14},[2032,2035,2038,2041,2044,2047,2050,2053,2056,2059,2062,2065,2068,2071],[2033,2034],"Failure mode","Why it fails",[2036,2037],"Check role but not tenant","Valid role becomes cross-tenant authority",[2039,2040],"Trust tenant ID from request","Client controls the isolation selector",[2042,2043],"Scope UI but not API","Hidden buttons do not protect backend resources",[2045,2046],"Tenant-aware detail endpoint, unscoped list endpoint","Bulk reads leak other tenants",[2048,2049],"Tenant filter in most queries","One forgotten path breaks the boundary",[2051,2052],"Global cache keys","Correct database isolation is bypassed by cached data",[2054,2055],"Shared vector index without enforced metadata filters","RAG retrieves another tenant's chunks",[2057,2058],"Queue message tenant ID treated as authorization","Forged or wrongly produced job can cross tenant boundary",[2060,2061],"Platform admin modeled as ordinary ADMIN","Cross-tenant power becomes implicit and difficult to audit",[2063,2064],"Role copied globally across tenant memberships","User receives permissions in tenants where they were never assigned",[2066,2067],"Separate databases but shared privileged credential","Application can still cross databases if its credential is too broad",[2069,2070],"RLS with BYPASSRLS request role","Database policy exists but does not protect the actual request path",[2072,2073],"Random UUIDs treated as isolation","Hard-to-guess identifiers reduce enumeration but do not authorize access",{},{"id":975,"data":2076,"type":42,"tunes":2078},{"text":2077,"level":247},"Common misconceptions",{},{"id":980,"data":2080,"type":391,"tunes":2114},{"content":2081,"stretched":43,"withHeadings":14},[2082,2084,2087,2090,2093,2096,2099,2102,2105,2108,2111],[2083,985],"Misconception",[2085,2086],"“RBAC provides tenant isolation.”","RBAC controls permissions; isolation also requires tenant\u002Fresource scoping.",[2088,2089],"“If the user is an admin, tenant checks are unnecessary.”","Admin authority must still have an explicit scope.",[2091,2092],"“Tenant ID in JWT is enough.”","It can be a trusted input only if validated and applied consistently to every protected resource path.",[2094,2095],"“Separate databases remove authorization requirements.”","Users still need operation-level permissions inside their tenant.",[2097,2098],"“A tenant_id column means the system is isolated.”","The field only helps if access paths enforce it.",[2100,2101],"“UUIDs prevent cross-tenant access.”","Unpredictable identifiers are defense in depth, not authorization.",[2103,2104],"“RLS means application code needs no security checks.”","Application authorization, correct DB roles and policy coverage still matter.",[2106,2107],"“One shared vector DB is unsafe.”","It can be safe if isolation is enforceable and verified; physical separation is one option, not the only one.",[2109,2110],"“Platform support needs global ADMIN.”","Cross-tenant support should be a distinct, constrained and auditable authority.",[2112,2113],"“Internal services can skip tenant checks.”","Internal paths can still be compromised or misconfigured and must preserve tenant context.",{},{"id":1018,"data":2116,"type":42,"tunes":2118},{"text":2117,"level":247},"A practical design sequence",{},{"id":1023,"data":2120,"type":334,"tunes":2159},{"steps":2121,"title":2158,"orientation":333},[2122,2125,2128,2131,2134,2137,2140,2143,2146,2149,2152,2155],{"label":2123,"description":2124},"1. Define tenant ownership","Classify which entities and resources are global, tenant-scoped, user-scoped or intentionally cross-tenant.",{"label":2126,"description":2127},"2. Define operations","Create explicit permissions for reads, writes, publishing, approvals, administration and other business actions.",{"label":2129,"description":2130},"3. Define roles","Group permissions according to responsibilities without embedding accidental global scope.",{"label":2132,"description":2133},"4. Define membership scope","Bind role assignments to the tenant\u002Fworkspace\u002Fproject context in which they apply.",{"label":2135,"description":2136},"5. Resolve trusted tenant context","Derive tenant identity from authenticated, server-verified membership or service authorization.",{"label":2138,"description":2139},"6. Enforce resource ownership","Apply tenant scope at every tenant-owned data\u002Fservice boundary.",{"label":2141,"description":2142},"7. Add defense in depth","Use RLS, separate credentials, schemas\u002Fdatabases, storage policies or policy engines where risk justifies them.",{"label":2144,"description":2145},"8. Carry scope through derived systems","Preserve tenant metadata in cache, search, vector indexes, queues, files and analytics.",{"label":2147,"description":2148},"9. Model cross-tenant operations explicitly","Separate platform administration and service identities from ordinary tenant roles.",{"label":2150,"description":2151},"10. Test both axes","Run negative tests for missing permission and for wrong tenant independently.",{"label":2153,"description":2154},"11. Audit tenant + permission together","Log who acted, in which tenant, on what target and under which authority.",{"label":2156,"description":2157},"12. Re-test after schema\u002Fruntime changes","Isolation can break when new tables, caches, queues or retrieval paths are introduced.","Design permissions and isolation as separate dimensions",{},{"id":1065,"data":2161,"type":42,"tunes":2163},{"text":2162,"level":247},"RBAC + tenant isolation checklist",{},{"id":1070,"data":2165,"type":391,"tunes":2211},{"content":2166,"stretched":43,"withHeadings":14},[2167,2169,2172,2175,2178,2181,2184,2187,2190,2193,2196,2199,2202,2205,2208],[412,2168],"Expected answer",[2170,2171],"Who is the principal?","Authenticated user\u002Fservice\u002Fagent identity",[2173,2174],"Which tenant context applies?","Server-verified membership or service scope",[2176,2177],"Which operation is requested?","Typed permission or policy action",[2179,2180],"Does the principal have that permission?","Role\u002Fpolicy decision",[2182,2183],"Who owns the target resource?","Explicit tenant\u002Fglobal\u002Fuser classification",[2185,2186],"Does resource scope match authority?","Tenant-aware lookup\u002Fpolicy",[2188,2189],"Can storage bypass application checks?","Defense-in-depth decision documented",[2191,2192],"Are caches tenant-safe?","Keys\u002Fnamespaces and authorization preserve tenant scope",[2194,2195],"Are files\u002Fblobs tenant-safe?","Object policy and signed URL issuance enforce scope",[2197,2198],"Are async jobs tenant-safe?","Verified context propagates and is revalidated",[2200,2201],"Is RAG\u002Fsearch tenant-safe?","Metadata\u002Fcollection isolation enforced before model context",[2203,2204],"Are cross-tenant admins explicit?","Separate authority, controls and audit",[2206,2207],"Can ordinary credentials bypass isolation?","No, or tightly documented exceptional path",[2209,2210],"Are negative cross-tenant tests automated?","Yes for every relevant access layer",{},{"id":1119,"data":2213,"type":42,"tunes":2215},{"text":2214,"level":247},"Edge cases and limitations",{},{"id":1124,"data":2217,"type":218,"tunes":2219},{"text":2218},"A user can belong to multiple tenants. The current tenant should therefore be an explicit execution context, not inferred permanently from the user account.",{},{"id":1129,"data":2221,"type":218,"tunes":2223},{"text":2222},"Some resources are intentionally shared between selected tenants, such as collaboration spaces or consortium data. This requires an explicit sharing model; pretending the resource belongs to one tenant and adding exceptions later usually creates ambiguous authorization.",{},{"id":1134,"data":2225,"type":218,"tunes":2227},{"text":2226},"Noisy-neighbor isolation is related but different from confidentiality isolation. A tenant may never see another tenant's data yet still exhaust shared CPU, queue capacity or database connections. Rate limits and resource quotas can therefore be tenant-aware as an availability boundary.",{},{"id":1139,"data":2229,"type":218,"tunes":2231},{"text":2230},"Physical isolation is not automatically secure if control-plane credentials or administrative paths can cross boundaries. Logical isolation is not automatically weak if policies are centrally enforced, least-privileged and thoroughly tested.",{},{"id":1144,"data":2233,"type":218,"tunes":2235},{"text":2234},"Tenant isolation requirements can differ by data class. Public catalog data, billing records and private AI documents may justify different storage and encryption boundaries inside the same SaaS product.",{},{"id":1149,"data":2237,"type":42,"tunes":2239},{"text":2238,"level":247},"What would change this answer?",{},{"id":1154,"data":2241,"type":218,"tunes":2243},{"text":2242},"The exact implementation changes with architecture: serverless APIs, Kubernetes, PostgreSQL, object storage, vector databases and policy engines expose different isolation primitives.",{},{"id":1159,"data":2245,"type":218,"tunes":2247},{"text":2246},"The required strength also changes with regulation, customer contracts, data sensitivity, threat model and operational scale. Some tenants may justify siloed databases or infrastructure while others share pooled resources.",{},{"id":1164,"data":2249,"type":218,"tunes":2251},{"text":2250},"The conceptual distinction does not change: permission to perform an operation is not the same thing as permission to cross a tenant boundary.",{},{"id":1169,"data":2253,"type":42,"tunes":2255},{"text":2254,"level":247},"Related canonical knowledge",{},{"id":1174,"data":2257,"type":218,"tunes":2259},{"text":2258},"S01 is a security-boundary prerequisite for Enterprise AI Architecture and AI Governance. Once AI tools, RAG or agents operate over multi-tenant data, tenant identity must travel through retrieval, tool execution, memory, caches and audit traces.",{},{"id":1179,"data":2261,"type":218,"tunes":2263},{"text":2262},"It also connects directly to Agentic AI: tool capability and role permission must still be constrained by tenant ownership before an agent can read or mutate business resources.",{},{"id":1184,"data":2265,"type":1190,"tunes":2269},{"url":1186,"title":2266,"excerpt":2267,"ctaLabel":2268},"MCP vs A2A vs UCP vs AP2 vs A2UI: The Agent Protocol Stack Explained","Protocol interoperability does not replace authorization or tenant isolation. Capability discovery and business authority remain separate architecture concerns.","Read the protocol stack article",{},{"id":1193,"data":2271,"type":218,"tunes":2273},{"text":2272},"For RAG, tenant isolation must be enforced before protected chunks reach model context.",{},{"id":1198,"data":2275,"type":1190,"tunes":2280},{"url":2276,"title":2277,"excerpt":2278,"ctaLabel":2279},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","What Is RAG? The Simplest Explanation of How It Works","The retrieval foundation for understanding where tenant-aware source filtering and vector-store isolation must be enforced.","Read the RAG foundation",{},{"id":1206,"data":2282,"type":42,"tunes":2284},{"text":2283,"level":247},"Frequently asked questions",{},{"id":1211,"data":2286,"type":1211,"tunes":2316},{"items":2287,"title":2315},[2288,2291,2294,2297,2300,2303,2306,2309,2312],{"id":1215,"answer":2289,"question":2290},"RBAC determines which operations a principal may perform. Tenant isolation determines which tenant's resources those operations may access. Secure multi-tenant applications normally need both.","What is the difference between RBAC and tenant isolation?",{"id":1219,"answer":2292,"question":2293},"No. ADMIN should have an explicit scope. A tenant administrator normally has broad permissions only inside that tenant, while cross-tenant platform administration should be modeled separately.","Does an ADMIN role automatically allow access to all tenants?",{"id":1223,"answer":2295,"question":2296},"No. Authentication proves identity. Authorization controls permitted actions. Tenant isolation additionally prevents those actions from reaching the wrong tenant's resources.","Is authentication enough for tenant isolation?",{"id":1227,"answer":2298,"question":2299},"It can be one input to tenant context, but the server must verify current membership\u002Fauthority and enforce the scope at protected resource boundaries. A claim alone does not replace isolation controls.","Should tenantId be stored in the JWT?",{"id":1231,"answer":2301,"question":2302},"Not necessarily. Shared-table, RLS, schema, database, infrastructure and hybrid isolation models can all be valid depending on risk and operational requirements.","Do I need a separate database per tenant?",{"id":1235,"answer":2304,"question":2305},"RLS can provide strong defense in depth, but correct database roles, request context, policy coverage and application-level authorization still matter.","Can PostgreSQL RLS replace tenant filters in application code?",{"id":1239,"answer":2307,"question":2308},"Tenant\u002Faccess scope should be enforced during retrieval so unauthorized chunks never enter model context. Preserve access metadata through chunking and indexing.","How should RAG enforce tenant isolation?",{"id":1243,"answer":2310,"question":2311},"Yes. This is common in B2B SaaS and is a strong reason to scope role assignments by tenant membership rather than treating roles as globally attached to the user.","Can one user have different roles in different tenants?",{"id":1247,"answer":2313,"question":2314},"Use negative cross-tenant tests: create at least two tenants, give a user valid permissions in one tenant, then prove every protected path denies access to the other tenant's resources.","What is the best test for tenant isolation?","RBAC vs tenant isolation FAQ",{},{"id":1253,"data":2318,"type":42,"tunes":2320},{"text":2319,"level":247},"Glossary",{},{"id":1258,"data":2322,"type":1258,"tunes":2355},{"title":2323,"entries":2324},"Key multi-tenant security terms",[2325,2327,2329,2331,2333,2336,2338,2341,2343,2346,2349,2352],{"term":395,"anchor":394,"definition":2326},"Role-Based Access Control: an authorization model that associates permissions with roles and assigns users or principals to those roles.",{"term":1265,"anchor":397,"definition":2328},"A customer, organization, workspace or other isolated logical consumer of a shared multi-tenant system.",{"term":1592,"anchor":1269,"definition":2330},"Mechanisms that prevent one tenant from accessing, modifying or receiving another tenant's resources in a shared system.",{"term":1605,"anchor":1272,"definition":2332},"Verification of the identity of a user, service or other principal.",{"term":2334,"anchor":1276,"definition":2335},"Authorization","Decision process that determines whether a principal may perform a requested operation on a resource.",{"term":1279,"anchor":1280,"definition":2337},"A defined allowed operation or capability such as orders.read or users.write.",{"term":2339,"anchor":1284,"definition":2340},"Role","A named grouping of permissions associated with a responsibility or function.",{"term":1287,"anchor":1288,"definition":2342},"Attribute-Based Access Control: authorization based on attributes of the principal, resource, action or environment.",{"term":2344,"anchor":1292,"definition":2345},"Row-Level Security","Database policy mechanism that restricts which rows a database role or session may read or modify.",{"term":2347,"anchor":1296,"definition":2348},"Cross-tenant access","Any access path in which a principal operating under one tenant context reaches resources belonging to another tenant.",{"term":2350,"anchor":1300,"definition":2351},"Platform administrator","A privileged operational identity with explicitly modeled authority that may span multiple tenants.",{"term":2353,"anchor":1304,"definition":2354},"Tenant context","The verified tenant scope under which the current request, job or agent operation executes.",{},{"id":1308,"data":2357,"type":42,"tunes":2358},{"text":1310,"level":247},{},{"id":1313,"data":2360,"type":218,"tunes":2362},{"text":2361},"RBAC and tenant isolation are complementary, not competing security mechanisms. RBAC structures operational permission; tenant isolation constrains the resource boundary inside which that permission can apply.",{},{"id":1318,"data":2364,"type":218,"tunes":2366},{"text":2365},"A robust multi-tenant request therefore needs more than “user has role ADMIN.” It needs a verified principal, verified tenant context, an allowed operation, a tenant-scoped target and enforcement at every resource layer that can carry tenant-owned data.",{},{"id":1323,"data":2368,"type":218,"tunes":2370},{"text":2369},"The shortest reliable rule is: authorize the action, then isolate the scope — and never assume one proves the other.",{},{"id":1328,"data":2372,"type":42,"tunes":2374},{"text":2373,"level":247},"Primary sources and current guidance",{},{"id":1333,"data":2376,"type":218,"tunes":2378},{"text":2377},"The sources below support the RBAC definition and current tenant-isolation guidance. The Aaasaasa AI CMS section is original implementation evidence and is intentionally bounded to the code patterns that were verified.",{},{"id":1338,"data":2380,"type":1345,"tunes":2385},{"link":1340,"meta":2381},{"image":2382,"title":2383,"description":2384},{"url":369},"NIST — Role Based Access Control","NIST overview of RBAC models and the INCITS RBAC standard, including users, roles, permissions, operations and objects.",{},{"id":1348,"data":2387,"type":1345,"tunes":2392},{"link":1350,"meta":2388},{"image":2389,"title":2390,"description":2391},{"url":369},"NIST CSRC — RBAC glossary","Current NIST glossary definitions of role-based access control as permission assignment through roles.",{},{"id":1357,"data":2394,"type":1345,"tunes":2399},{"link":1359,"meta":2395},{"image":2396,"title":2397,"description":2398},{"url":369},"AWS — The isolation mindset","AWS SaaS guidance explicitly distinguishing authentication\u002Fauthorization from tenant isolation and recommending shared isolation mechanisms.",{},{"id":1366,"data":2401,"type":1345,"tunes":2406},{"link":1368,"meta":2402},{"image":2403,"title":2404,"description":2405},{"url":369},"AWS — Multi-tenant authorization FAQ","Current guidance explaining the difference between authorization and tenant isolation in SaaS applications.",{},{"id":1375,"data":2408,"type":1345,"tunes":2413},{"link":1377,"meta":2409},{"image":2410,"title":2411,"description":2412},{"url":369},"AWS — Multi-tenant design considerations","Current SaaS guidance distinguishing tenant isolation from authorization and discussing pooled\u002Fsiloed authorization policy models.",{},{"id":1384,"data":2415,"type":1345,"tunes":2420},{"link":1386,"meta":2416},{"image":2417,"title":2418,"description":2419},{"url":369},"OWASP — Multi-Tenant Application Security Cheat Sheet","Current practical guidance for tenant context, database isolation, caches, storage, queues, testing and cross-tenant access prevention.",{},{"id":1393,"data":2422,"type":1345,"tunes":2427},{"link":1395,"meta":2423},{"image":2424,"title":2425,"description":2426},{"url":369},"OWASP — RAG Security Cheat Sheet","Current guidance requiring access control at retrieval time and tenant isolation for multi-tenant vector stores.",{},{"id":1402,"data":2429,"type":1345,"tunes":2434},{"link":1404,"meta":2430},{"image":2431,"title":2432,"description":2433},{"url":369},"OWASP — Authorization Regression Testing","Current testing guidance including role-demotion and cross-tenant boundary tests.",{},"2.31.6","RBAC controls what a user may do; tenant isolation controls which tenant’s resources that action may reach. Learn why multi-tenant SaaS security requires both boundaries.",{"lang":7,"title":208,"content":210,"contentJson":2438,"excerpt":1411},{"time":212,"blocks":2439,"version":1410},[2440,2443,2446,2449,2452,2455,2458,2461,2464,2467,2470,2473,2476,2479,2482,2485,2488,2491,2501,2504,2507,2510,2513,2516,2535,2538,2546,2549,2552,2555,2558,2561,2564,2567,2570,2573,2576,2579,2587,2590,2593,2596,2599,2602,2605,2616,2619,2622,2625,2628,2631,2634,2637,2640,2643,2646,2649,2652,2655,2658,2661,2664,2667,2670,2673,2676,2679,2682,2685,2688,2691,2694,2697,2700,2703,2706,2709,2712,2715,2718,2721,2724,2727,2730,2741,2744,2747,2750,2753,2756,2759,2762,2773,2776,2779,2782,2785,2788,2791,2806,2809,2812,2830,2833,2848,2851,2867,2870,2889,2892,2895,2898,2901,2904,2907,2910,2913,2916,2919,2922,2925,2928,2931,2934,2937,2940,2953,2956,2972,2975,2978,2981,2984,2987,2990,2995,3000,3005,3010,3015,3020,3025],{"id":215,"data":2441,"type":218,"tunes":2442},{"text":217},{},{"id":221,"data":2444,"type":226,"tunes":2445},{"body":223,"title":224,"variant":225},{},{"id":229,"data":2447,"type":226,"tunes":2448},{"body":231,"title":232,"variant":233},{},{"id":236,"data":2450,"type":226,"tunes":2451},{"body":238,"title":239,"variant":240},{},{"id":243,"data":2453,"type":248,"tunes":2454},{"title":245,"maxLevel":246,"minLevel":247},{},{"id":251,"data":2456,"type":42,"tunes":2457},{"text":253,"level":247},{},{"id":256,"data":2459,"type":218,"tunes":2460},{"text":258},{},{"id":261,"data":2462,"type":218,"tunes":2463},{"text":263},{},{"id":266,"data":2465,"type":218,"tunes":2466},{"text":268},{},{"id":271,"data":2468,"type":42,"tunes":2469},{"text":273,"level":247},{},{"id":276,"data":2471,"type":218,"tunes":2472},{"text":278},{},{"id":281,"data":2474,"type":218,"tunes":2475},{"text":283},{},{"id":286,"data":2477,"type":218,"tunes":2478},{"text":288},{},{"id":291,"data":2480,"type":42,"tunes":2481},{"text":293,"level":247},{},{"id":296,"data":2483,"type":218,"tunes":2484},{"text":298},{},{"id":301,"data":2486,"type":218,"tunes":2487},{"text":303},{},{"id":306,"data":2489,"type":218,"tunes":2490},{"text":308},{},{"id":311,"data":2492,"type":334,"tunes":2500},{"steps":2493,"title":332,"orientation":333},[2494,2495,2496,2497,2498,2499],{"label":315,"description":316},{"label":318,"description":319},{"label":321,"description":322},{"label":324,"description":325},{"label":327,"description":328},{"label":330,"description":331},{},{"id":337,"data":2502,"type":42,"tunes":2503},{"text":339,"level":247},{},{"id":342,"data":2505,"type":218,"tunes":2506},{"text":344},{},{"id":347,"data":2508,"type":218,"tunes":2509},{"text":349},{},{"id":352,"data":2511,"type":218,"tunes":2512},{"text":354},{},{"id":357,"data":2514,"type":42,"tunes":2515},{"text":359,"level":247},{},{"id":362,"data":2517,"type":399,"tunes":2534},{"rows":2518,"title":390,"layout":391,"columns":2531},[2519,2521,2523,2525,2527,2529],{"id":366,"label":367,"values":2520},[369,369],{"id":371,"label":372,"values":2522},[369,369],{"id":375,"label":376,"values":2524},[369,369],{"id":379,"label":380,"values":2526},[369,369],{"id":383,"label":384,"values":2528},[369,369],{"id":387,"label":388,"values":2530},[369,369],[2532,2533],{"id":394,"label":395},{"id":397,"label":398},{},{"id":402,"data":2536,"type":42,"tunes":2537},{"text":404,"level":247},{},{"id":407,"data":2539,"type":391,"tunes":2545},{"content":2540,"stretched":43,"withHeadings":14},[2541,2542,2543,2544],[411,412,413],[415,416,417],[419,420,421],[398,423,424],{},{"id":427,"data":2547,"type":218,"tunes":2548},{"text":429},{},{"id":432,"data":2550,"type":42,"tunes":2551},{"text":434,"level":247},{},{"id":437,"data":2553,"type":218,"tunes":2554},{"text":439},{},{"id":442,"data":2556,"type":218,"tunes":2557},{"text":444},{},{"id":447,"data":2559,"type":218,"tunes":2560},{"text":449},{},{"id":452,"data":2562,"type":42,"tunes":2563},{"text":454,"level":247},{},{"id":457,"data":2565,"type":218,"tunes":2566},{"text":459},{},{"id":462,"data":2568,"type":218,"tunes":2569},{"text":464},{},{"id":467,"data":2571,"type":218,"tunes":2572},{"text":469},{},{"id":472,"data":2574,"type":42,"tunes":2575},{"text":474,"level":247},{},{"id":477,"data":2577,"type":218,"tunes":2578},{"text":479},{},{"id":482,"data":2580,"type":391,"tunes":2586},{"content":2581,"stretched":43,"withHeadings":14},[2582,2583,2584,2585],[486,487],[489,490],[492,493],[495,496],{},{"id":499,"data":2588,"type":218,"tunes":2589},{"text":501},{},{"id":504,"data":2591,"type":42,"tunes":2592},{"text":506,"level":247},{},{"id":509,"data":2594,"type":218,"tunes":2595},{"text":511},{},{"id":514,"data":2597,"type":218,"tunes":2598},{"text":516},{},{"id":519,"data":2600,"type":226,"tunes":2601},{"body":521,"title":522,"variant":523},{},{"id":526,"data":2603,"type":42,"tunes":2604},{"text":528,"level":247},{},{"id":531,"data":2606,"type":391,"tunes":2615},{"content":2607,"stretched":43,"withHeadings":14},[2608,2609,2610,2611,2612,2613,2614],[535,536,537],[539,540,541],[543,544,545],[547,548,549],[551,552,553],[555,556,557],[559,560,561],{},{"id":564,"data":2617,"type":218,"tunes":2618},{"text":566},{},{"id":569,"data":2620,"type":42,"tunes":2621},{"text":571,"level":247},{},{"id":574,"data":2623,"type":218,"tunes":2624},{"text":576},{},{"id":579,"data":2626,"type":218,"tunes":2627},{"text":581},{},{"id":584,"data":2629,"type":218,"tunes":2630},{"text":586},{},{"id":589,"data":2632,"type":42,"tunes":2633},{"text":591,"level":247},{},{"id":594,"data":2635,"type":218,"tunes":2636},{"text":596},{},{"id":599,"data":2638,"type":218,"tunes":2639},{"text":601},{},{"id":604,"data":2641,"type":218,"tunes":2642},{"text":606},{},{"id":609,"data":2644,"type":42,"tunes":2645},{"text":611,"level":247},{},{"id":614,"data":2647,"type":218,"tunes":2648},{"text":616},{},{"id":619,"data":2650,"type":218,"tunes":2651},{"text":621},{},{"id":624,"data":2653,"type":218,"tunes":2654},{"text":626},{},{"id":629,"data":2656,"type":42,"tunes":2657},{"text":631,"level":247},{},{"id":634,"data":2659,"type":218,"tunes":2660},{"text":636},{},{"id":639,"data":2662,"type":218,"tunes":2663},{"text":641},{},{"id":644,"data":2665,"type":218,"tunes":2666},{"text":646},{},{"id":649,"data":2668,"type":42,"tunes":2669},{"text":651,"level":247},{},{"id":654,"data":2671,"type":218,"tunes":2672},{"text":656},{},{"id":659,"data":2674,"type":218,"tunes":2675},{"text":661},{},{"id":664,"data":2677,"type":218,"tunes":2678},{"text":666},{},{"id":669,"data":2680,"type":226,"tunes":2681},{"body":671,"title":672,"variant":233},{},{"id":675,"data":2683,"type":42,"tunes":2684},{"text":677,"level":247},{},{"id":680,"data":2686,"type":218,"tunes":2687},{"text":682},{},{"id":685,"data":2689,"type":218,"tunes":2690},{"text":687},{},{"id":690,"data":2692,"type":42,"tunes":2693},{"text":692,"level":247},{},{"id":695,"data":2695,"type":218,"tunes":2696},{"text":697},{},{"id":700,"data":2698,"type":218,"tunes":2699},{"text":702},{},{"id":705,"data":2701,"type":218,"tunes":2702},{"text":707},{},{"id":710,"data":2704,"type":42,"tunes":2705},{"text":712,"level":247},{},{"id":715,"data":2707,"type":218,"tunes":2708},{"text":717},{},{"id":720,"data":2710,"type":218,"tunes":2711},{"text":722},{},{"id":725,"data":2713,"type":218,"tunes":2714},{"text":727},{},{"id":730,"data":2716,"type":42,"tunes":2717},{"text":732,"level":247},{},{"id":735,"data":2719,"type":218,"tunes":2720},{"text":737},{},{"id":740,"data":2722,"type":218,"tunes":2723},{"text":742},{},{"id":745,"data":2725,"type":218,"tunes":2726},{"text":747},{},{"id":750,"data":2728,"type":42,"tunes":2729},{"text":752,"level":247},{},{"id":755,"data":2731,"type":391,"tunes":2740},{"content":2732,"stretched":43,"withHeadings":14},[2733,2734,2735,2736,2737,2738,2739],[759,760,761,762],[764,765,766,767],[764,765,769,770],[764,772,766,773],[764,772,769,770],[776,777,778,779],[781,782,783,784],{},{"id":787,"data":2742,"type":42,"tunes":2743},{"text":789,"level":247},{},{"id":792,"data":2745,"type":226,"tunes":2746},{"body":794,"title":795,"variant":240},{},{"id":798,"data":2748,"type":218,"tunes":2749},{"text":800},{},{"id":803,"data":2751,"type":218,"tunes":2752},{"text":805},{},{"id":808,"data":2754,"type":218,"tunes":2755},{"text":810},{},{"id":813,"data":2757,"type":218,"tunes":2758},{"text":815},{},{"id":818,"data":2760,"type":218,"tunes":2761},{"text":820},{},{"id":823,"data":2763,"type":391,"tunes":2772},{"content":2764,"stretched":43,"withHeadings":14},[2765,2766,2767,2768,2769,2770,2771],[827,828],[830,831],[833,834],[836,837],[839,840],[842,843],[845,846],{},{"id":849,"data":2774,"type":226,"tunes":2775},{"body":851,"title":852,"variant":233},{},{"id":855,"data":2777,"type":42,"tunes":2778},{"text":857,"level":247},{},{"id":860,"data":2780,"type":218,"tunes":2781},{"text":862},{},{"id":865,"data":2783,"type":218,"tunes":2784},{"text":867},{},{"id":870,"data":2786,"type":218,"tunes":2787},{"text":872},{},{"id":875,"data":2789,"type":42,"tunes":2790},{"text":877,"level":247},{},{"id":880,"data":2792,"type":391,"tunes":2805},{"content":2793,"stretched":43,"withHeadings":14},[2794,2795,2796,2797,2798,2799,2800,2801,2802,2803,2804],[884,885],[887,888],[890,891],[893,894],[896,897],[899,900],[902,903],[905,906],[908,909],[911,912],[914,915],{},{"id":918,"data":2807,"type":218,"tunes":2808},{"text":920},{},{"id":923,"data":2810,"type":42,"tunes":2811},{"text":925,"level":247},{},{"id":928,"data":2813,"type":391,"tunes":2829},{"content":2814,"stretched":43,"withHeadings":14},[2815,2816,2817,2818,2819,2820,2821,2822,2823,2824,2825,2826,2827,2828],[932,933],[935,936],[938,939],[941,942],[944,945],[947,948],[950,951],[953,954],[956,957],[959,960],[962,963],[965,966],[968,969],[971,972],{},{"id":975,"data":2831,"type":42,"tunes":2832},{"text":977,"level":247},{},{"id":980,"data":2834,"type":391,"tunes":2847},{"content":2835,"stretched":43,"withHeadings":14},[2836,2837,2838,2839,2840,2841,2842,2843,2844,2845,2846],[984,985],[987,988],[990,991],[993,994],[996,997],[999,1000],[1002,1003],[1005,1006],[1008,1009],[1011,1012],[1014,1015],{},{"id":1018,"data":2849,"type":42,"tunes":2850},{"text":1020,"level":247},{},{"id":1023,"data":2852,"type":334,"tunes":2866},{"steps":2853,"title":1062,"orientation":333},[2854,2855,2856,2857,2858,2859,2860,2861,2862,2863,2864,2865],{"label":1027,"description":1028},{"label":1030,"description":1031},{"label":1033,"description":1034},{"label":1036,"description":1037},{"label":1039,"description":1040},{"label":1042,"description":1043},{"label":1045,"description":1046},{"label":1048,"description":1049},{"label":1051,"description":1052},{"label":1054,"description":1055},{"label":1057,"description":1058},{"label":1060,"description":1061},{},{"id":1065,"data":2868,"type":42,"tunes":2869},{"text":1067,"level":247},{},{"id":1070,"data":2871,"type":391,"tunes":2888},{"content":2872,"stretched":43,"withHeadings":14},[2873,2874,2875,2876,2877,2878,2879,2880,2881,2882,2883,2884,2885,2886,2887],[412,1074],[1076,1077],[1079,1080],[1082,1083],[1085,1086],[1088,1089],[1091,1092],[1094,1095],[1097,1098],[1100,1101],[1103,1104],[1106,1107],[1109,1110],[1112,1113],[1115,1116],{},{"id":1119,"data":2890,"type":42,"tunes":2891},{"text":1121,"level":247},{},{"id":1124,"data":2893,"type":218,"tunes":2894},{"text":1126},{},{"id":1129,"data":2896,"type":218,"tunes":2897},{"text":1131},{},{"id":1134,"data":2899,"type":218,"tunes":2900},{"text":1136},{},{"id":1139,"data":2902,"type":218,"tunes":2903},{"text":1141},{},{"id":1144,"data":2905,"type":218,"tunes":2906},{"text":1146},{},{"id":1149,"data":2908,"type":42,"tunes":2909},{"text":1151,"level":247},{},{"id":1154,"data":2911,"type":218,"tunes":2912},{"text":1156},{},{"id":1159,"data":2914,"type":218,"tunes":2915},{"text":1161},{},{"id":1164,"data":2917,"type":218,"tunes":2918},{"text":1166},{},{"id":1169,"data":2920,"type":42,"tunes":2921},{"text":1171,"level":247},{},{"id":1174,"data":2923,"type":218,"tunes":2924},{"text":1176},{},{"id":1179,"data":2926,"type":218,"tunes":2927},{"text":1181},{},{"id":1184,"data":2929,"type":1190,"tunes":2930},{"url":1186,"title":1187,"excerpt":1188,"ctaLabel":1189},{},{"id":1193,"data":2932,"type":218,"tunes":2933},{"text":1195},{},{"id":1198,"data":2935,"type":1190,"tunes":2936},{"url":1200,"title":1201,"excerpt":1202,"ctaLabel":1203},{},{"id":1206,"data":2938,"type":42,"tunes":2939},{"text":1208,"level":247},{},{"id":1211,"data":2941,"type":1211,"tunes":2952},{"items":2942,"title":1250},[2943,2944,2945,2946,2947,2948,2949,2950,2951],{"id":1215,"answer":1216,"question":1217},{"id":1219,"answer":1220,"question":1221},{"id":1223,"answer":1224,"question":1225},{"id":1227,"answer":1228,"question":1229},{"id":1231,"answer":1232,"question":1233},{"id":1235,"answer":1236,"question":1237},{"id":1239,"answer":1240,"question":1241},{"id":1243,"answer":1244,"question":1245},{"id":1247,"answer":1248,"question":1249},{},{"id":1253,"data":2954,"type":42,"tunes":2955},{"text":1255,"level":247},{},{"id":1258,"data":2957,"type":1258,"tunes":2971},{"title":1260,"entries":2958},[2959,2960,2961,2962,2963,2964,2965,2966,2967,2968,2969,2970],{"term":395,"anchor":394,"definition":1263},{"term":1265,"anchor":397,"definition":1266},{"term":1268,"anchor":1269,"definition":1270},{"term":415,"anchor":1272,"definition":1273},{"term":1275,"anchor":1276,"definition":1277},{"term":1279,"anchor":1280,"definition":1281},{"term":1283,"anchor":1284,"definition":1285},{"term":1287,"anchor":1288,"definition":1289},{"term":1291,"anchor":1292,"definition":1293},{"term":1295,"anchor":1296,"definition":1297},{"term":1299,"anchor":1300,"definition":1301},{"term":1303,"anchor":1304,"definition":1305},{},{"id":1308,"data":2973,"type":42,"tunes":2974},{"text":1310,"level":247},{},{"id":1313,"data":2976,"type":218,"tunes":2977},{"text":1315},{},{"id":1318,"data":2979,"type":218,"tunes":2980},{"text":1320},{},{"id":1323,"data":2982,"type":218,"tunes":2983},{"text":1325},{},{"id":1328,"data":2985,"type":42,"tunes":2986},{"text":1330,"level":247},{},{"id":1333,"data":2988,"type":218,"tunes":2989},{"text":1335},{},{"id":1338,"data":2991,"type":1345,"tunes":2994},{"link":1340,"meta":2992},{"image":2993,"title":1343,"description":1344},{"url":369},{},{"id":1348,"data":2996,"type":1345,"tunes":2999},{"link":1350,"meta":2997},{"image":2998,"title":1353,"description":1354},{"url":369},{},{"id":1357,"data":3001,"type":1345,"tunes":3004},{"link":1359,"meta":3002},{"image":3003,"title":1362,"description":1363},{"url":369},{},{"id":1366,"data":3006,"type":1345,"tunes":3009},{"link":1368,"meta":3007},{"image":3008,"title":1371,"description":1372},{"url":369},{},{"id":1375,"data":3011,"type":1345,"tunes":3014},{"link":1377,"meta":3012},{"image":3013,"title":1380,"description":1381},{"url":369},{},{"id":1384,"data":3016,"type":1345,"tunes":3019},{"link":1386,"meta":3017},{"image":3018,"title":1389,"description":1390},{"url":369},{},{"id":1393,"data":3021,"type":1345,"tunes":3024},{"link":1395,"meta":3022},{"image":3023,"title":1398,"description":1399},{"url":369},{},{"id":1402,"data":3026,"type":1345,"tunes":3029},{"link":1404,"meta":3027},{"image":3028,"title":1407,"description":1408},{"url":369},{},"Post erfolgreich abgerufen",{"items":3032,"source":3116,"manualIds":3117,"manualMatchedIds":3118},[3033,3040,3047,3054,3061,3068,3075,3082,3089,3096,3103,3110],{"id":3034,"slug":3035,"title":3036,"excerpt":3037,"featuredImage":3038,"publishedAt":3039},"488","what-is-context-engineering-what-the-model-receives-before-it-answers","Qu’est-ce que l’ingénierie du contexte ? Ce que le modèle reçoit avant de répondre","L'ingénierie de contexte conçoit les informations qu'un modèle d'IA reçoit avant l'inférence, y compris les invites, la récupération, la mémoire, l'état de l'application, les résultats d'outils et l'historique des conversations.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-context-engineering-what-the-model-receives-before-it-answers-1791480653258-018kcv.webp","2026-10-08T13:29:00.000Z",{"id":3041,"slug":3042,"title":3043,"excerpt":3044,"featuredImage":3045,"publishedAt":3046},"489","agentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act","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.","\u002Fuploads\u002F2026\u002F10\u002Fagentic-ai-explained-when-an-ai-system-can-plan-use-tools-and-act-1791481499084-wnji2a.webp","2026-10-08T11:43:00.000Z",{"id":3048,"slug":3049,"title":3050,"excerpt":3051,"featuredImage":3052,"publishedAt":3053},"484","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","Qu'est-ce qu'un architecte de plateforme d'IA ? Modèles, données, environnement d'exécution, sécurité et opérations","Un architecte de plateforme d'IA conçoit des fondations d'IA réutilisables à travers les modèles, les fournisseurs, la récupération, les agents, l'identité, la sécurité, l'évaluation, l'observabilité et les opérations.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-platform-architect-models-data-runtime-security-and-operations-1791477229171-ou3zcc.webp","2026-10-08T12:32:00.000Z",{"id":3055,"slug":3056,"title":3057,"excerpt":3058,"featuredImage":3059,"publishedAt":3060},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","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.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":3062,"slug":3063,"title":3064,"excerpt":3065,"featuredImage":3066,"publishedAt":3067},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","Quand une IA devrait-elle cesser de faire confiance à ses propres connaissances ? — Le déclencheur de récupération","Un modèle d'IA n'a pas besoin de récupération pour chaque question. Le problème important est de savoir quand ses connaissances internes ne suffisent plus. Le Déclencheur de Récupération est une frontière de décision pratique qui détermine quand un système d'IA devrait cesser de se fier uniquement aux connaissances du modèle et obtenir des preuves externes avant de répondre.","\u002Fuploads\u002F2026\u002F09\u002Fwhen-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger-1790574991244-f4rpyg.webp","2026-09-28T01:49:00.000Z",{"id":3069,"slug":3070,"title":3071,"excerpt":3072,"featuredImage":3073,"publishedAt":3074},"468","ai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context","La mémoire des agents IA n'est pas le RAG : comment séparer la mémoire, la récupération, l'état et le contexte","La mémoire des agents, le RAG, l'état et le contexte sont souvent utilisés comme s'ils étaient interchangeables. Ils ne le sont pas. Ce modèle d'architecture pratique sépare les quatre couches, montre où chacune se situe et explique ce qui dysfonctionne lorsque les systèmes les fusionnent en une seule.","\u002Fuploads\u002F2026\u002F09\u002Fai-agent-memory-is-not-rag-how-to-separate-memory-retrieval-state-and-context-1790350560308-np0xy6.webp","2026-09-25T11:34:00.000Z",{"id":3076,"slug":3077,"title":3078,"excerpt":3079,"featuredImage":3080,"publishedAt":3081},"476","mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","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.","\u002Fuploads\u002F2026\u002F09\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained-1790352625869-2ezle0.webp","2026-09-25T12:09:00.000Z",{"id":3083,"slug":3084,"title":3085,"excerpt":3086,"featuredImage":3087,"publishedAt":3088},"472","why-more-context-can-make-ai-answers-worse","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.","\u002Fuploads\u002F2026\u002F09\u002Fwhy-more-context-can-make-ai-answers-worse-1790351615793-2ntv2v.webp","2026-09-25T11:51:00.000Z",{"id":3090,"slug":3091,"title":3092,"excerpt":3093,"featuredImage":3094,"publishedAt":3095},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Comment savoir si un agent IA a réellement utilisé les bonnes preuves","Un agent IA peut citer des sources et tout de même utiliser les mauvais éléments de preuve. Cet article présente une méthode pratique pour vérifier le soutien des affirmations, l'autorité de la source, l'applicabilité, la provenance et si les éléments de preuve ont réellement influencé la réponse.","\u002Fuploads\u002F2026\u002F09\u002Fhow-to-know-whether-an-ai-agent-actually-used-the-right-evidence-1790351317188-o5z9ve.webp","2026-09-25T11:47:00.000Z",{"id":3097,"slug":3098,"title":3099,"excerpt":3100,"featuredImage":3101,"publishedAt":3102},"470","what-should-an-ai-agent-remember-forget-recompute-or-retrieve-again","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é.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-should-an-ai-agent-remember-forget-recompute-or-retrieve-again-1790351131087-iehz28.webp","2026-09-25T09:43:00.000Z",{"id":3104,"slug":3105,"title":3106,"excerpt":3107,"featuredImage":3108,"publishedAt":3109},"466","the-gpu-is-not-the-product-future-proof-private-ai-architecture","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.","\u002Fuploads\u002F2026\u002F09\u002Fthe-gpu-is-not-the-product-future-proof-private-ai-architecture-1790140878812-8hsl39.webp","2026-09-23T01:19:00.000Z",{"id":3111,"slug":3112,"title":1201,"excerpt":3113,"featuredImage":3114,"publishedAt":3115},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Le RAG semble compliqué, mais l'idée est simple : avant qu'une IA ne réponde, elle recherche d'abord des informations utiles dans une source de connaissances et transmet ces informations au modèle de langage. Ce guide explique le RAG, les LLM, l'état, la mémoire et les outils à l'aide d'un modèle mental simple.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z","fallback",[],[]]