[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:it":3,"public-menus:all":38,"post:rbac-vs-tenant-isolation-two-different-security-boundaries:it":205,"related:post:rbac-vs-tenant-isolation-two-different-security-boundaries:it:1":3033},{"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","it","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":3032},{"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 Isolamento dei Tenant: Due Confini di Sicurezza Diversi","rbac-vs-tenant-isolation-two-different-security-boundaries","\u003Cp>RBAC e isolamento dei tenant risolvono due problemi di sicurezza diversi nei sistemi multi-tenant. Il controllo degli accessi basato sui ruoli (RBAC) determina cosa è consentito fare a un principal autenticato, come leggere ordini, modificare prodotti o gestire utenti. L'isolamento dei tenant determina a quali dati, risorse e contesto di esecuzione di quale tenant quel principal è autorizzato ad accedere. Un utente può essere correttamente autenticato e correttamente assegnato a un ruolo RBAC e tuttavia subire un fallimento di sicurezza se l'applicazione consente a quel ruolo di operare sulle risorse di un altro tenant.\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\">Risposta diretta\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>RBAC risponde a "cosa può fare questa identità?" L'isolamento dei tenant risponde a "all'interno di quale confine può farlo?"\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Un'applicazione multi-tenant sicura normalmente necessita di entrambi. Un amministratore di tenant può avere permessi ampi, ma tali permessi dovrebbero rimanere limitati al tenant dell'amministratore, a meno che non esista un'autorità a livello di piattaforma esplicitamente separata.\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 ruolo non è un confine di tenant\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Assegnare a un utente il ruolo \u003Ccode>ADMIN\u003C\u002Fcode> non implica automaticamente "amministratore solo del tenant A". Il ruolo deve essere valutato insieme al contesto di tenant verificato e alla proprietà del tenant della risorsa di destinazione. Altrimenti un ruolo valido può diventare un privilegio cross-tenant.\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\">Nota sulle fonti attuali — 8 ottobre 2026\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">La distinzione di fondo è stabile. NIST definisce RBAC attorno a utenti, ruoli, permessi, operazioni e oggetti. Le attuali linee guida AWS SaaS affermano esplicitamente che autenticazione e autorizzazione non equivalgono all'isolamento dei tenant, e che un utente può essere autenticato e autorizzato pur accedendo alle risorse di un altro tenant se l'isolamento non è applicato separatamente. Anche le attuali linee guida OWASP sulla sicurezza multi-tenant trattano l'isolamento dei tenant come un requisito trasversale a tutti i livelli che copre API, database, cache, storage, code e altre risorse condivise.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Indice\">\u003Cstrong class=\"editorjs-toc__title\">Indice\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\">Cosa controlla realmente RBAC\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Cosa controlla realmente l'isolamento dei tenant\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-14\" class=\"editorjs-toc__link\">L'esempio più semplice\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-19\" class=\"editorjs-toc__link\">Dove si ferma l'esempio semplice\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">RBAC vs isolamento dei tenant\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-25\" class=\"editorjs-toc__link\">Autenticazione, autorizzazione e isolamento sono tre controlli diversi\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-28\" class=\"editorjs-toc__link\">I ruoli necessitano di uno scope\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">Il contesto del tenant deve provenire da un percorso attendibile\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-36\" class=\"editorjs-toc__link\">Lo scope del tenant appartiene alla ricerca della risorsa\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-40\" class=\"editorjs-toc__link\">I controlli applicativi sono utili, ma l'isolamento non dovrebbe dipendere da un comportamento perfetto degli sviluppatori\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Strategie di isolamento del database\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">PostgreSQL Row-Level Security può fornire difesa in profondità\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">L'isolamento del tenant deve includere le cache\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">File e object storage necessitano di un proprio confine di tenant\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">I job in background e le code possono rompere l'isolamento\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">Ricerca e RAG necessitano di retrieval tenant-aware\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-68\" class=\"editorjs-toc__link\">I dati derivati ereditano la sensibilità del tenant\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Non tutto appartiene a un tenant\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">Gli amministratori della piattaforma richiedono un modello di autorità diverso\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-79\" class=\"editorjs-toc__link\">RBAC può essere combinato con gli attributi\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-83\" class=\"editorjs-toc__link\">Le decisioni di autorizzazione sono almeno bidimensionali\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" class=\"editorjs-toc__link\">Evidenza dell'implementazione originale: Aaasaasa AI CMS\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-94\" class=\"editorjs-toc__link\">Perché questa distinzione conta ancora di più per gli agenti AI\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-98\" class=\"editorjs-toc__link\">Testare RBAC e isolamento tenant separatamente\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-101\" class=\"editorjs-toc__link\">Modalità di errore comuni\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-103\" class=\"editorjs-toc__link\">Idee sbagliate comuni\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-105\" class=\"editorjs-toc__link\">Una sequenza di progettazione pratica\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-107\" class=\"editorjs-toc__link\">Checklist RBAC + isolamento tenant\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-109\" class=\"editorjs-toc__link\">Casi limite e limitazioni\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-115\" class=\"editorjs-toc__link\">Cosa cambierebbe questa risposta?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-119\" class=\"editorjs-toc__link\">Conoscenza canonica correlata\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-125\" class=\"editorjs-toc__link\">Domande frequenti\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-127\" class=\"editorjs-toc__link\">Glossario\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-129\" class=\"editorjs-toc__link\">Conclusione\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-133\" class=\"editorjs-toc__link\">Fonti primarie e linee guida attuali\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Cosa controlla realmente RBAC\u003C\u002Fh2>\n\u003Cp>RBAC è un modello di autorizzazione in cui i permessi sono associati ai ruoli e gli utenti sono assegnati a tali ruoli. Il ruolo funge da astrazione amministrativa tra identità e permessi.\u003C\u002Fp>\n\u003Cp>Il lavoro classico di NIST su RBAC formalizza questo concetto attorno a utenti, ruoli, permessi, operazioni e oggetti. Il vantaggio pratico è che un'organizzazione può gestire l'autorizzazione attraverso ruoli relativamente stabili basati su mansioni o responsabilità, invece di collegare ogni permesso direttamente a ogni utente.\u003C\u002Fp>\n\u003Cp>Un ruolo come EDITOR può quindi significare: può leggere contenuti, scrivere contenuti e pubblicare contenuti. Un ruolo come ACCOUNTANT può significare: può leggere dati di fatturazione, riconciliare fatture e approvare regolamenti.\u003C\u002Fp>\n\u003Ch2 id=\"section-10\">Cosa controlla realmente l'isolamento dei tenant\u003C\u002Fh2>\n\u003Cp>L'isolamento dei tenant è l'insieme dei meccanismi che impediscono a un tenant di leggere, modificare, influenzare o ricevere accidentalmente le risorse di un altro tenant in un sistema condiviso.\u003C\u002Fp>\n\u003Cp>Il confine protetto è più ampio delle righe del database. Lo stato specifico di un tenant può esistere in tabelle relazionali, object storage, indici vettoriali, cache, indici di ricerca, messaggi in coda, file, artefatti temporanei, job in background, analisi, limiti di velocità e risorse infrastrutturali.\u003C\u002Fp>\n\u003Cp>Le linee guida AWS per SaaS rendono esplicita la distinzione: l'autorizzazione concede l'accesso alle risorse, mentre l'isolamento dei tenant garantisce che tali risorse non possano attraversare il confine del tenant sbagliato anche quando l'infrastruttura è condivisa.\u003C\u002Fp>\n\u003Ch2 id=\"section-14\">L'esempio più semplice\u003C\u002Fh2>\n\u003Cp>Supponiamo che Alice sia un'amministratrice del Tenant A e Bob sia un amministratore del Tenant B. Entrambi gli utenti possiedono legittimamente lo stesso ruolo ADMIN.\u003C\u002Fp>\n\u003Cp>RBAC può correttamente concludere che entrambi gli utenti possono eseguire un'operazione come users.read. Ma quando Alice richiede l'ID utente 847, l'applicazione deve comunque verificare che l'utente 847 appartenga al Tenant A.\u003C\u002Fp>\n\u003Cp>Se l'API controlla solo \"Alice ha ADMIN\" e poi esegue SELECT * FROM users WHERE id = 847, RBAC ha avuto successo mentre l'isolamento dei tenant ha fallito.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Una decisione di autorizzazione multi-tenant corretta\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. Autenticare il principal\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Stabilire chi è l'utente, il servizio o l'agente.\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. Risolvere il contesto di tenant verificato\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Determinare quale contesto di tenant si applica dalle informazioni attendibili lato server su identità\u002Fappartenenza.\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. Risolvere il permesso\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Valutare se il ruolo o la policy del principal consente l'operazione richiesta.\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. Delimitare la risorsa di destinazione\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Verificare che l'oggetto di destinazione appartenga al tenant consentito o a un ambito esplicitamente condiviso.\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. Applicare al confine di accesso\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Eseguire l'operazione su database, cache, storage, coda o servizio con i vincoli di tenant applicati.\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. Verificare entrambe le dimensioni\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Registrare principal, tenant, operazione, destinazione e risultato in modo che i tentativi cross-tenant siano visibili.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-19\">Dove si ferma l'esempio semplice\u003C\u002Fh2>\n\u003Cp>I sistemi reali spesso contengono diverse classi di identità: utenti tenant, amministratori di piattaforma, worker in background, integrazioni, agenti e servizi operativi cross-tenant. Alcune di queste attraversano legittimamente i confini dei tenant.\u003C\u002Fp>\n\u003Cp>Ciò non elimina la necessità di isolamento. Significa che l'autorità cross-tenant deve essere esplicita, ristretta e verificabile separatamente, invece di emergere accidentalmente da un ruolo globale o da una connessione al database senza scope.\u003C\u002Fp>\n\u003Cp>L'isolamento dei tenant può anche variare a seconda del livello. Un prodotto può condividere i server applicativi separando i database, oppure utilizzare un database condiviso con policy a livello di riga, offrendo al contempo ai tenant premium storage o capacità di calcolo isolati. Non esiste un'unica topologia di isolamento universale.\u003C\u002Fp>\n\u003Ch2 id=\"section-23\">RBAC vs isolamento dei tenant\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Due diverse dimensioni di sicurezza\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\">Isolamento dei tenant\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\">Domanda 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à tipica\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\">Esempio\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\">Errore tipico\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\">Implementazione tipica\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\">Può esistere da solo?\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\">Autenticazione, autorizzazione e isolamento sono tre controlli diversi\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\">Livello\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Domanda\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Esempio di errore\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autenticazione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chi è questo principale?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'attaccante si spaccia per Alice\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autorizzazione \u002F RBAC\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Questo principale può eseguire questa operazione?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un visualizzatore può eliminare utenti\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Isolamento dei tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Questa operazione può raggiungere questo confine di tenant\u002Frisorsa?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'amministratore del Tenant A legge l'ordine del Tenant B\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Questi controlli sono correlati ma non sostituibili. L'autenticazione può essere perfetta mentre l'autorizzazione fallisce. L'autorizzazione può essere corretta mentre l'isolamento dei tenant fallisce. Un percorso di richiesta SaaS sicuro necessita di tutti i confini applicabili.\u003C\u002Fp>\n\u003Ch2 id=\"section-28\">I ruoli necessitano di uno scope\u003C\u002Fh2>\n\u003Cp>La parola ADMIN è incompleta senza scope. Può significare amministratore di piattaforma, amministratore di tenant, amministratore di progetto, amministratore di workspace o amministratore di un sottosistema.\u003C\u002Fp>\n\u003Cp>Nei sistemi multi-tenant, l'assegnazione dei ruoli dovrebbe normalmente essere associata all'appartenenza al tenant o a un altro scope esplicito della risorsa. Lo stesso utente può legittimamente essere ADMIN nel Tenant A e VIEWER nel Tenant B.\u003C\u002Fp>\n\u003Cp>Un modello di ruoli globale che ignora questa distinzione può creare una fuga di privilegi anche quando la mappa dei permessi stessa è corretta.\u003C\u002Fp>\n\u003Ch2 id=\"section-32\">Il contesto del tenant deve provenire da un percorso attendibile\u003C\u002Fh2>\n\u003Cp>Un ID tenant fornito dal client è utile come selettore, ma non è prova di autorità. Il server deve derivare o verificare l'appartenenza al tenant rispetto all'identità autenticata e ai dati di autorizzazione correnti.\u003C\u002Fp>\n\u003Cp>Le attuali linee guida multi-tenant di OWASP raccomandano di stabilire il contesto del tenant all'inizio del ciclo di vita della richiesta e mettono esplicitamente in guardia dal trattare header del client o parametri della richiesta come prova di autorizzazione.\u003C\u002Fp>\n\u003Cp>Questo è importante perché una banale modifica della richiesta da tenant=A a tenant=B non deve essere sufficiente per superare il confine di isolamento.\u003C\u002Fp>\n\u003Ch2 id=\"section-36\">Lo scope del tenant appartiene alla ricerca della risorsa\u003C\u002Fh2>\n\u003Cp>Un modello comune di isolamento a livello applicativo consiste nell'includere lo scope del tenant nella stessa query che risolve la risorsa.\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\">Ricerca debole\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ricerca più robusta con scope del tenant\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>Questo modello non è l'unico meccanismo di isolamento possibile, ma mantiene la proprietà del tenant vicina all'operazione di accesso ai dati e impedisce che un ID oggetto diventi una capability cross-tenant.\u003C\u002Fp>\n\u003Ch2 id=\"section-40\">I controlli applicativi sono utili, ma l'isolamento non dovrebbe dipendere da un comportamento perfetto degli sviluppatori\u003C\u002Fh2>\n\u003Cp>Le linee guida sull'isolamento di AWS mettono esplicitamente in guardia dal lasciare l'applicazione dell'isolamento solo agli sviluppatori dei servizi. In una grande codebase, prima o poi una query, una chiave di cache o un percorso di un worker potrebbe omettere lo scope del tenant.\u003C\u002Fp>\n\u003Cp>La difesa in profondità può quindi spostare l'isolamento in middleware condiviso, livelli repository\u002Fservice, motori di policy, Row-Level Security del database, credenziali dedicate, schemi separati o database separati a seconda del rischio e dell'architettura.\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'isolamento dovrebbe essere difficile da dimenticare\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Il confine più forte è quello che il normale codice applicativo non può aggirare casualmente omettendo una singola condizione \u003Ccode>tenantId\u003C\u002Fcode>.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-44\">Strategie di isolamento del database\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\">Strategia\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Confine\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Forza \u002F compromesso\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tabelle condivise + chiave tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Policy a livello di riga\u002Fapplicazione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Efficiente dal punto di vista operativo; richiede uno scoping esaustivo del tenant e test solidi\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Tabelle condivise + RLS del database\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confine della policy del database\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Riduce la dipendenza da ogni query applicativa; richiede ruoli corretti, contesto tenant di sessione\u002Ftransazione e copertura delle policy\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Schemi separati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confine di namespace \u002F ruolo DB\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Separazione logica più forte; maggiore complessità operativa\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Database separati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confine di database \u002F credenziali\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Isolamento forte e gestione del blast radius più semplice; costi di provisioning e operativi più elevati\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Infrastruttura\u002Faccount separati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Confine infrastrutturale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Separazione a grana grossa più forte; costi e overhead operativo più elevati\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ibrido\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Per carico di lavoro\u002Fclasse di dati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Consente un isolamento più forte solo dove rischio\u002Fconformità lo giustificano\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>L'attuale Multi-Tenant Security Cheat Sheet di OWASP elenca database separati, schemi separati, tabelle condivise con controlli a livello di riga e modelli ibridi. Il modello corretto dipende dal livello di minaccia, dalla conformità, dalle prestazioni e dal costo operativo.\u003C\u002Fp>\n\u003Ch2 id=\"section-47\">PostgreSQL Row-Level Security può fornire difesa in profondità\u003C\u002Fh2>\n\u003Cp>Con tabelle condivise, PostgreSQL Row-Level Security può applicare un predicato tenant a livello di database, così le query ordinarie non possono vedere righe al di fuori della policy del tenant attivo.\u003C\u002Fp>\n\u003Cp>Tuttavia, RLS non è magia. I superuser di PostgreSQL e i ruoli con BYPASSRLS possono bypassare le policy a livello di riga. OWASP raccomanda quindi di utilizzare un ruolo con privilegi minimi per il percorso di richiesta e di testare la stessa modalità di connessione\u002Fpooling usata in produzione.\u003C\u002Fp>\n\u003Cp>Il riutilizzo delle connessioni è un altro caso limite importante: il contesto del tenant deve essere impostato e reimpostato in modo sicuro per ogni transazione\u002Frichiesta, così una connessione in pool non può far trapelare lo stato di un tenant precedente.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">L'isolamento del tenant deve includere le cache\u003C\u002Fh2>\n\u003Cp>Una query al database può avere uno scope perfetto e comunque far trapelare dati attraverso una chiave di cache condivisa.\u003C\u002Fp>\n\u003Cp>Se user:42 esiste sia nel Tenant A sia nel Tenant B, una chiave di cache globale può restituire il valore del tenant sbagliato. Le chiavi di cache sensibili al tenant dovrebbero includere ogni attributo che modifica la visibilità o la semantica del risultato, comunemente tenant, utente, locale, set di funzionalità o versione dei permessi.\u003C\u002Fp>\n\u003Cp>La partizione della cache è difesa in profondità, non un sostituto dell'autorizzazione. La richiesta deve comunque essere autorizzata prima che venga restituito il contenuto protetto memorizzato in cache.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">File e object storage necessitano di un proprio confine di tenant\u003C\u002Fh2>\n\u003Cp>L'object storage dovrebbe distinguere oggetti globali, con ambito tenant e con ambito utente. Un prefisso di cartella da solo è solo una convenzione di denominazione, a meno che la policy di accesso non vincoli effettivamente letture e scritture.\u003C\u002Fp>\n\u003Cp>Progettazioni più robuste possono utilizzare chiavi oggetto tenant-aware, policy di bucket, bucket\u002Faccount separati o chiavi di cifratura specifiche per tenant, laddove il rischio o la conformità richiedano un isolamento più forte.\u003C\u002Fp>\n\u003Cp>Gli URL firmati devono essere autorizzati prima dell'emissione e limitati all'oggetto e all'operazione esatti. Il possesso di un identificatore di oggetto non dovrebbe di per sé concedere accesso cross-tenant.\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">I job in background e le code possono rompere l'isolamento\u003C\u002Fh2>\n\u003Cp>I job asincroni spesso abbandonano il contesto della richiesta HTTP originale, il che rende facile gestire male la propagazione del tenant. Un messaggio in coda che contiene tenantId non è prova sufficiente che il produttore fosse autorizzato.\u003C\u002Fp>\n\u003Cp>Il worker dovrebbe portare un'identità di servizio\u002Futente verificata o una busta di job attendibile, ristabilire il contesto del tenant e riautorizzare le operazioni consequenziali al confine del consumatore.\u003C\u002Fp>\n\u003Cp>L'isolamento del tenant include anche la disponibilità. Un tenant non dovrebbe essere in grado di monopolizzare worker, code, pool di connessioni o risorse di calcolo condivise in modi che degradino materialmente gli altri tenant.\u003C\u002Fp>\n\u003Ch2 id=\"section-63\">Ricerca e RAG necessitano di retrieval tenant-aware\u003C\u002Fh2>\n\u003Cp>L'AI multi-tenant introduce un'altra copia del problema di isolamento. I documenti possono essere suddivisi in chunk, incorporati e memorizzati in un indice vettoriale dopo l'ingestione.\u003C\u002Fp>\n\u003Cp>L'attuale guida alla sicurezza RAG di OWASP afferma che il controllo degli accessi deve essere applicato al momento del retrieval e che i chunk del Tenant A non devono essere recuperati da query del Tenant B. Non si può semplicemente presumere che i permessi a livello di documento sopravvivano automaticamente alla suddivisione in chunk.\u003C\u002Fp>\n\u003Cp>L'indice vettoriale necessita quindi di metadati di tenant\u002Faccesso o di collezioni fisicamente\u002Flogicamente separate in base al design di isolamento. I filtri di retrieval dovrebbero essere applicati prima che contenuti non autorizzati possano entrare nel contesto del modello.\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\">Il modello non deve mai essere il filtro del tenant\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Non recuperare chunk cross-tenant e poi istruire il modello linguistico a ignorarli. Una volta che i dati protetti entrano nel contesto del modello, il confine di isolamento è già fallito.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-68\">I dati derivati ereditano la sensibilità del tenant\u003C\u002Fh2>\n\u003Cp>Embedding, indici di ricerca, miniature, riepiloghi generati, cache, righe di analytics e risposte AI derivano dai dati di origine. Il loro ambito di tenant dovrebbe seguire la fonte, a meno che una trasformazione esplicita crei un artefatto condiviso\u002Fglobale legittimo.\u003C\u002Fp>\n\u003Cp>La cancellazione e l'offboarding devono quindi propagarsi oltre la riga canonica. Rimuovere un documento del tenant lasciando chunk ricercabili o riepiloghi in cache può mantenere un'esposizione cross-tenant o successiva alla conservazione.\u003C\u002Fp>\n\u003Ch2 id=\"section-71\">Non tutto appartiene a un tenant\u003C\u002Fh2>\n\u003Cp>Le piattaforme multi-tenant hanno spesso risorse intenzionalmente globali: tassonomie di prodotto, template pubblici, permessi di sistema, definizioni di funzionalità o contenuti pubblici.\u003C\u002Fp>\n\u003Cp>Il modello più sicuro è la classificazione esplicita: globale, con ambito tenant, con ambito utente o esplicitamente cross-tenant. Le risorse ambigue sono il punto in cui inizia una fuga di dati accidentale.\u003C\u002Fp>\n\u003Cp>Un oggetto condiviso intenzionalmente dovrebbe avere una motivazione documentata per essere globale, invece di mancare semplicemente di un'associazione a un tenant.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">Gli amministratori della piattaforma richiedono un modello di autorità diverso\u003C\u002Fh2>\n\u003Cp>Un operatore della piattaforma potrebbe aver bisogno di ispezionare più tenant per supporto, conformità o operazioni infrastrutturali. Modellare questo come un normale ADMIN di tenant con accesso accidentale al database globale indebolisce sia la sicurezza che l'auditabilità.\u003C\u002Fp>\n\u003Cp>Un design migliore utilizza un'identità di piattaforma distinta o un permesso cross-tenant esplicito, autenticazione più forte, limitazione dello scopo, audit dettagliato e, ove appropriato, controlli di approvazione o break-glass.\u003C\u002Fp>\n\u003Cp>L'accesso cross-tenant dovrebbe quindi essere una capacità denominata, non l'assenza di un filtro tenant.\u003C\u002Fp>\n\u003Ch2 id=\"section-79\">RBAC può essere combinato con gli attributi\u003C\u002Fh2>\n\u003Cp>Alcune decisioni dipendono da più del ruolo. L'appartenenza al tenant, la regione, il proprietario della risorsa, il livello di abbonamento, il tempo, l'appartenenza al progetto o la classificazione dei dati possono tutti influenzare l'accesso.\u003C\u002Fp>\n\u003Cp>RBAC e ABAC non si escludono a vicenda. Le attuali linee guida di AWS sull'autorizzazione multi-tenant discutono modelli RBAC, ABAC e ibridi. Un ruolo può definire una responsabilità ampia mentre gli attributi limitano quale istanza concreta di risorsa può essere accessibile.\u003C\u002Fp>\n\u003Cp>La regola architetturale chiave rimane: non codificare l'isolamento del tenant solo come un nome di ruolo incidentale se l'identità del tenant è un confine di risorsa di prima classe.\u003C\u002Fp>\n\u003Ch2 id=\"section-83\">Le decisioni di autorizzazione sono almeno bidimensionali\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\">Principale\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Permesso del ruolo\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Relazione con il tenant\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Decisione\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\">L'ordine appartiene al tenant di Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Consenti\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\">L'ordine appartiene a un altro tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nega\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\">L'ordine appartiene al tenant di Alice\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Consenti se il ruolo include la scrittura\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\">L'ordine appartiene a un altro tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Nega\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Supporto piattaforma\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\">Ambito di supporto esplicito + tenant di destinazione verificato\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Potenzialmente consenti secondo la policy della piattaforma\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Worker in background\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\">Ambito di servizio attendibile per il tenant del job\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Consenti solo per il tenant del job verificato\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-85\">Evidenza dell'implementazione 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\">Evidenza dell'implementazione originale\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Aaasaasa AI CMS contiene un'implementazione concreta di RBAC con ambito tenant. È un'evidenza utile di come l'autorizzazione dei ruoli e l'ambito del tenant possano essere combinati, ma non dovrebbe essere presentata come prova che ogni livello di archiviazione, cache o infrastruttura abbia un isolamento completo del tenant.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>Il servizio RBAC definisce codici di permesso tipizzati come cms.content.read, shop.orders.write, billing.reconcile e users.roles. I ruoli di sistema mappano quei permessi in insiemi di responsabilità denominati.\u003C\u002Fp>\n\u003Cp>I record dei ruoli vengono creati e risolti con un tenantId. I ruoli di sistema vengono inseriti o aggiornati utilizzando un'identità composita tenant\u002Fcodice, e l'elenco dei ruoli è filtrato per tenant.\u003C\u002Fp>\n\u003Cp>L'aggiornamento e l'eliminazione dei ruoli risolvono prima il ruolo utilizzando sia l'ID del ruolo che l'ID del tenant. Anche le assegnazioni utente-ruolo vengono memorizzate e sostituite nel contesto del tenant corrente.\u003C\u002Fp>\n\u003Cp>La risoluzione dei permessi legge le assegnazioni esplicite utente-ruolo con ambito sia tenantId che userId. Questo impedisce che l'assegnazione di ruolo di un tenant diventi automaticamente l'assegnazione di ruolo di un altro tenant.\u003C\u002Fp>\n\u003Cp>A livello API, le route RBAC amministrative risolvono un contesto tenant prima di creare o modificare ruoli. Questa è la direzione corretta: l'amministrazione dei permessi stessa deve rispettare la tenancy.\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\">Pattern di implementazione osservato\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Significato di sicurezza\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Codici di permesso tipizzati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il vocabolario delle operazioni RBAC è esplicito\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Mappe ruolo di sistema → permessi\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I ruoli aggregano permessi invece di codificare direttamente gli utenti\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identità del ruolo tenantId_code\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lo stesso ruolo logico può esistere separatamente per tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La ricerca del ruolo usa id + tenantId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La modifica del ruolo è limitata al tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La relazione utente-ruolo memorizza tenantId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'appartenenza non è inferita globalmente dal solo ruolo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La risoluzione dei permessi usa tenantId + userId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorizzazione è valutata all'interno del contesto tenant\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\">Cosa questa evidenza non prova\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Il RBAC con ambito tenant è uno strato. L'isolamento completo dei tenant deve coprire anche tutte le ricerche di risorse di proprietà del tenant, database, cache, file, indici di ricerca\u002Fvettoriali, job in background, integrazioni e percorsi operativi. L'evidenza del repository qui supporta il pattern di progettazione RBAC\u002Fambito tenant, non un'affermazione di isolamento SaaS verificato in modo indipendente.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-94\">Perché questa distinzione conta ancora di più per gli agenti AI\u003C\u002Fh2>\n\u003Cp>Gli agenti AI possono trasformare un errore di permesso in una sequenza di azioni. Se a un agente viene fornito uno strumento ampio orders.read senza applicazione con ambito tenant, un errore di ragionamento o di prompt-injection può causare letture cross-tenant alla velocità della macchina.\u003C\u002Fp>\n\u003Cp>Le descrizioni degli strumenti dell'agente possono menzionare vincoli tenant, ma l'applicazione deve comunque avvenire nel runtime\u002Fservizio\u002Fstrato dati attendibile. Le istruzioni in linguaggio naturale non sono un confine di autorizzazione.\u003C\u002Fp>\n\u003Cp>Lo stesso vale per RAG: un agente può avere il permesso di usare lo strumento di ricerca mentre il backend di ricerca deve comunque impedire che la query del Tenant A restituisca i chunk del Tenant B.\u003C\u002Fp>\n\u003Ch2 id=\"section-98\">Testare RBAC e isolamento tenant separatamente\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\">Famiglia di test\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Cosa dovrebbe provare\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test di retrocessione del ruolo\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un utente senza un permesso non può eseguire l'operazione nemmeno all'interno del proprio tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test oggetto cross-tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un utente con il ruolo corretto non può comunque accedere allo stesso tipo di risorsa in un altro tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Manomissione dell'identificatore\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La modifica degli ID oggetto\u002Ftenant non attraversa l'ambito\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test endpoint di elenco\u002Fin blocco\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le query ampie restituiscono solo dati tenant autorizzati\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test riutilizzo cache\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Due tenant che utilizzano processi\u002Fconnessioni riutilizzati non ricevono mai lo stato in cache dell'altro\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test ruolo richiesta RLS\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il ruolo di richiesta di produzione non può bypassare le politiche di riga\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test worker asincrono\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il contesto tenant sopravvive all'accodamento e viene rivalidato al consumo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test recupero vettoriale\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La query del Tenant A non recupera mai i chunk del Tenant B\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test amministratore piattaforma\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La capacità cross-tenant è esplicita, ristretta e verificabile\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Test offboarding\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I dati del tenant e gli indici\u002Fcache derivati vengono rimossi secondo la politica\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>La guida OWASP sui test di regressione dell'autorizzazione menziona specificamente i test sui confini cross-tenant perché modifiche al codice in caching, query o servizi condivisi possono rompere silenziosamente l'isolamento anche quando i test dei ruoli continuano a passare.\u003C\u002Fp>\n\u003Ch2 id=\"section-101\">Modalità di errore comuni\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\">Modalità di errore\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Perché fallisce\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Controlla il ruolo ma non il tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un ruolo valido diventa autorità cross-tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Fidarsi dell'ID tenant dalla richiesta\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il client controlla il selettore di isolamento\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Limitare l'interfaccia utente ma non l'API\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I pulsanti nascosti non proteggono le risorse backend\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Endpoint di dettaglio tenant-aware, endpoint di elenco senza ambito\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le letture in blocco fanno trapelare altri tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Filtro tenant nella maggior parte delle query\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un percorso dimenticato rompe il confine\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chiavi cache globali\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'isolamento corretto del database viene bypassato dai dati in cache\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Indice vettoriale condiviso senza filtri di metadati applicati\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RAG recupera i chunk di un altro tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">ID tenant del messaggio in coda trattato come autorizzazione\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Un job falsificato o prodotto erroneamente può attraversare il confine tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Amministratore piattaforma modellato come ADMIN ordinario\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il potere cross-tenant diventa implicito e difficile da verificare\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ruolo copiato globalmente tra appartenenze tenant\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'utente riceve permessi in tenant in cui non è mai stato assegnato\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Database separati ma credenziale privilegiata condivisa\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'applicazione può comunque attraversare i database se la sua credenziale è troppo ampia\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RLS con ruolo di richiesta BYPASSRLS\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La politica del database esiste ma non protegge il percorso di richiesta effettivo\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">UUID casuali trattati come isolamento\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gli identificatori difficili da indovinare riducono l'enumerazione ma non autorizzano l'accesso\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-103\">Idee sbagliate comuni\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\">Idea sbagliata\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Correzione\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“RBAC fornisce l'isolamento tenant.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RBAC controlla i permessi; l'isolamento richiede anche l'ambito tenant\u002Frisorsa.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Se l'utente è un amministratore, i controlli tenant sono superflui.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorità di amministratore deve comunque avere un ambito esplicito.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“L'ID tenant nel JWT è sufficiente.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Può essere un input attendibile solo se validato e applicato in modo coerente a ogni percorso di risorsa protetto.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Database separati rimuovono i requisiti di autorizzazione.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gli utenti hanno comunque bisogno di permessi a livello di operazione all'interno del loro tenant.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Una colonna tenant_id significa che il sistema è isolato.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il campo aiuta solo se i percorsi di accesso lo applicano.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Gli UUID impediscono l'accesso cross-tenant.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gli identificatori imprevedibili sono difesa in profondità, non autorizzazione.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“RLS significa che il codice dell'applicazione non ha bisogno di controlli di sicurezza.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'autorizzazione dell'applicazione, i ruoli DB corretti e la copertura delle politiche contano ancora.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Un unico database vettoriale condiviso è insicuro.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Può essere sicuro se l'isolamento è applicabile e verificato; la separazione fisica è un'opzione, non l'unica.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“Il supporto piattaforma ha bisogno di ADMIN globale.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il supporto cross-tenant dovrebbe essere un'autorità distinta, vincolata e verificabile.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">“I servizi interni possono saltare i controlli tenant.”\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I percorsi interni possono comunque essere compromessi o mal configurati e devono preservare il contesto tenant.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-105\">Una sequenza di progettazione pratica\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Progettare permessi e isolamento come dimensioni separate\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. Definire la proprietà del tenant\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Classificare quali entità e risorse sono globali, con ambito tenant, con ambito utente o intenzionalmente cross-tenant.\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. Definire le operazioni\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Creare permessi espliciti per letture, scritture, pubblicazione, approvazioni, amministrazione e altre azioni aziendali.\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. Definire i ruoli\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Raggruppare i permessi in base alle responsabilità senza incorporare un ambito globale accidentale.\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. Definire l'ambito di appartenenza\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Vincolare le assegnazioni di ruolo al contesto tenant\u002Fworkspace\u002Fprogetto in cui si applicano.\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. Risolvere il contesto tenant attendibile\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Derivare l'identità del tenant dall'appartenenza autenticata e verificata dal server o dall'autorizzazione del servizio.\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. Applicare la proprietà delle risorse\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Applicare l'ambito tenant a ogni confine di dati\u002Fservizio di proprietà del tenant.\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. Aggiungere difesa in profondità\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Utilizzare RLS, credenziali separate, schemi\u002Fdatabase, politiche di archiviazione o motori di policy dove il rischio lo giustifica.\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. Trasportare l'ambito attraverso i sistemi derivati\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Preservare i metadati del tenant in cache, ricerca, indici vettoriali, code, file e analisi.\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. Modellare esplicitamente le operazioni cross-tenant\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Separare l'amministrazione della piattaforma e le identità di servizio dai ruoli tenant ordinari.\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. Testare entrambi gli assi\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Eseguire test negativi per permesso mancante e per tenant errato in modo indipendente.\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. Verificare tenant + permesso insieme\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Registrare chi ha agito, in quale tenant, su quale target e sotto quale 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. Ripetere i test dopo modifiche a schema\u002Fruntime\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">L'isolamento può rompersi quando vengono introdotte nuove tabelle, cache, code o percorsi di recupero.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-107\">Checklist RBAC + isolamento tenant\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\">Domanda\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Risposta attesa\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chi è il principale?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Identità utente\u002Fservizio\u002Fagente autenticata\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quale contesto tenant si applica?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Appartenenza verificata dal server o ambito di servizio\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Quale operazione è richiesta?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Permesso tipizzato o azione di policy\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il principale ha quel permesso?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione ruolo\u002Fpolicy\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chi possiede la risorsa target?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Classificazione esplicita tenant\u002Fglobale\u002Futente\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">L'ambito della risorsa corrisponde all'autorità?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ricerca\u002Fpolicy tenant-aware\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Lo storage può bypassare i controlli dell'applicazione?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Decisione di difesa in profondità documentata\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le cache sono sicure per il tenant?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Chiavi\u002Fnamespace e autorizzazione preservano l'ambito tenant\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">File\u002Fblob sono sicuri per il tenant?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">La policy degli oggetti e l'emissione di URL firmati applicano l'ambito\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I job asincroni sono sicuri per il tenant?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Il contesto verificato si propaga e viene rivalidato\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RAG\u002Fricerca è sicuro per il tenant?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Isolamento di metadati\u002Fcollezioni applicato prima del contesto del modello\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Gli amministratori cross-tenant sono espliciti?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Autorità, controlli e audit separati\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Le credenziali ordinarie possono bypassare l'isolamento?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">No, o percorso eccezionale strettamente documentato\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">I test negativi cross-tenant sono automatizzati?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Sì per ogni strato di accesso rilevante\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-109\">Casi limite e limitazioni\u003C\u002Fh2>\n\u003Cp>Un utente può appartenere a più tenant. Il tenant corrente dovrebbe quindi essere un contesto di esecuzione esplicito, non dedotto permanentemente dall'account utente.\u003C\u002Fp>\n\u003Cp>Alcune risorse sono intenzionalmente condivise tra tenant selezionati, come spazi di collaborazione o dati di consorzio. Ciò richiede un modello di condivisione esplicito; fingere che la risorsa appartenga a un tenant e aggiungere eccezioni in seguito di solito crea autorizzazioni ambigue.\u003C\u002Fp>\n\u003Cp>L'isolamento da vicini rumorosi è correlato ma diverso dall'isolamento di riservatezza. Un tenant potrebbe non vedere mai i dati di un altro tenant e tuttavia esaurire CPU condivisa, capacità di coda o connessioni al database. I limiti di velocità e le quote di risorse possono quindi essere tenant-aware come confine di disponibilità.\u003C\u002Fp>\n\u003Cp>L'isolamento fisico non è automaticamente sicuro se le credenziali del piano di controllo o i percorsi amministrativi possono attraversare i confini. L'isolamento logico non è automaticamente debole se le politiche sono applicate centralmente, con privilegi minimi e testate a fondo.\u003C\u002Fp>\n\u003Cp>I requisiti di isolamento dei tenant possono differire per classe di dati. Dati di catalogo pubblici, record di fatturazione e documenti AI privati possono giustificare confini di archiviazione e crittografia diversi all'interno dello stesso prodotto SaaS.\u003C\u002Fp>\n\u003Ch2 id=\"section-115\">Cosa cambierebbe questa risposta?\u003C\u002Fh2>\n\u003Cp>L'implementazione esatta cambia con l'architettura: API serverless, Kubernetes, PostgreSQL, object storage, database vettoriali e motori di policy espongono primitive di isolamento diverse.\u003C\u002Fp>\n\u003Cp>La forza richiesta cambia anche con la regolamentazione, i contratti dei clienti, la sensibilità dei dati, il modello di minaccia e la scala operativa. Alcuni tenant possono giustificare database o infrastrutture siloed mentre altri condividono risorse in pool.\u003C\u002Fp>\n\u003Cp>La distinzione concettuale non cambia: il permesso di eseguire un'operazione non è la stessa cosa del permesso di attraversare un confine di tenant.\u003C\u002Fp>\n\u003Ch2 id=\"section-119\">Conoscenza canonica correlata\u003C\u002Fh2>\n\u003Cp>S01 è un prerequisito di confine di sicurezza per Enterprise AI Architecture e AI Governance. Una volta che strumenti AI, RAG o agenti operano su dati multi-tenant, l'identità del tenant deve viaggiare attraverso il recupero, l'esecuzione degli strumenti, la memoria, le cache e le tracce di audit.\u003C\u002Fp>\n\u003Cp>Si collega anche direttamente ad Agentic AI: la capacità degli strumenti e il permesso del ruolo devono comunque essere vincolati dalla proprietà del tenant prima che un agente possa leggere o modificare risorse aziendali.\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: The Agent Protocol Stack Explained\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">L'interoperabilità dei protocolli non sostituisce l'autorizzazione o l'isolamento dei tenant. La scoperta delle capacità e l'autorità aziendale rimangono preoccupazioni architetturali separate.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Leggi l'articolo sullo stack di protocolli →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>Per RAG, l'isolamento dei tenant deve essere applicato prima che i chunk protetti raggiungano il contesto del modello.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fit\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\">What Is RAG? The Simplest Explanation of How It Works\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">La base di recupero per comprendere dove devono essere applicati il filtraggio delle fonti tenant-aware e l'isolamento del vector store.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Leggi le basi di RAG →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-125\">Domande frequenti\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 su RBAC vs isolamento dei tenant\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\">Qual è la differenza tra RBAC e isolamento dei tenant?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">RBAC determina quali operazioni un principale può eseguire. L'isolamento dei tenant determina a quali risorse di quale tenant quelle operazioni possono accedere. Le applicazioni multi-tenant sicure normalmente necessitano di entrambi.\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 ruolo ADMIN consente automaticamente l'accesso a tutti i tenant?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. ADMIN dovrebbe avere uno scope esplicito. Un amministratore di tenant normalmente ha ampi permessi solo all'interno di quel tenant, mentre l'amministrazione della piattaforma cross-tenant dovrebbe essere modellata separatamente.\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'autenticazione è sufficiente per l'isolamento dei tenant?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">No. L'autenticazione prova l'identità. L'autorizzazione controlla le azioni consentite. L'isolamento dei tenant impedisce inoltre che tali azioni raggiungano le risorse del tenant sbagliato.\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\">Il tenantId dovrebbe essere memorizzato nel JWT?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Può essere un input per il contesto del tenant, ma il server deve verificare l'appartenenza\u002Fautorità corrente e applicare lo scope ai confini delle risorse protette. Un claim da solo non sostituisce i controlli di isolamento.\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\">Ho bisogno di un database separato per tenant?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Non necessariamente. Modelli di isolamento con tabella condivisa, RLS, schema, database, infrastruttura e ibridi possono essere tutti validi a seconda del rischio e dei requisiti operativi.\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\">PostgreSQL RLS può sostituire i filtri tenant nel codice dell'applicazione?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">RLS può fornire una forte difesa in profondità, ma ruoli di database corretti, contesto della richiesta, copertura delle policy e autorizzazione a livello di applicazione contano comunque.\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\">Come dovrebbe RAG applicare l'isolamento dei tenant?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Lo scope tenant\u002Faccesso dovrebbe essere applicato durante il recupero in modo che i chunk non autorizzati non entrino mai nel contesto del modello. Conserva i metadati di accesso attraverso chunking e indicizzazione.\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 utente può avere ruoli diversi in tenant diversi?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Sì. Questo è comune nel SaaS B2B ed è una forte ragione per limitare le assegnazioni di ruolo all'appartenenza al tenant piuttosto che trattare i ruoli come globalmente collegati all'utente.\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\">Qual è il miglior test per l'isolamento dei tenant?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Usa test negativi cross-tenant: crea almeno due tenant, assegna a un utente permessi validi in un tenant, poi dimostra che ogni percorso protetto nega l'accesso alle risorse dell'altro tenant.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-127\">Glossario\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\">Termini chiave di sicurezza 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\">Role-Based Access Control: un modello di autorizzazione che associa i permessi ai ruoli e assegna utenti o principal a tali ruoli.\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 cliente, organizzazione, workspace o altro consumatore logico isolato di un sistema multi-tenant condiviso.\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\">Isolamento del tenant\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Meccanismi che impediscono a un tenant di accedere, modificare o ricevere le risorse di un altro tenant in un sistema condiviso.\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\">Autenticazione\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Verifica dell'identità di un utente, servizio o altro 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\">Autorizzazione\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Processo decisionale che determina se un principal può eseguire un'operazione richiesta su una risorsa.\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\">Permesso\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un'operazione o capacità consentita e definita, come orders.read o 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\">Ruolo\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un raggruppamento denominato di permessi associato a una responsabilità o funzione.\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\">Attribute-Based Access Control: autorizzazione basata su attributi del principal, della risorsa, dell'azione o dell'ambiente.\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\">Sicurezza a livello di riga\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Meccanismo di policy del database che limita quali righe un ruolo o una sessione del database può leggere o modificare.\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\">Accesso cross-tenant\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Qualsiasi percorso di accesso in cui un principal che opera in un contesto tenant raggiunge risorse appartenenti a un altro 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\">Amministratore della piattaforma\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Un'identità operativa privilegiata con autorità esplicitamente modellata che può estendersi su più tenant.\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\">Contesto del tenant\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">L'ambito del tenant verificato sotto il quale viene eseguita la richiesta, il job o l'operazione dell'agente corrente.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-129\">Conclusione\u003C\u002Fh2>\n\u003Cp>RBAC e isolamento del tenant sono meccanismi di sicurezza complementari, non in competizione. RBAC struttura il permesso operativo; l'isolamento del tenant vincola il confine delle risorse entro cui tale permesso può essere applicato.\u003C\u002Fp>\n\u003Cp>Una richiesta multi-tenant robusta necessita quindi di più di \"l'utente ha il ruolo ADMIN\". Richiede un principal verificato, un contesto tenant verificato, un'operazione consentita, un target con ambito tenant e l'applicazione a ogni livello di risorsa che può contenere dati di proprietà del tenant.\u003C\u002Fp>\n\u003Cp>La regola affidabile più breve è: autorizza l'azione, poi isola l'ambito — e non presumere mai che una dimostri l'altra.\u003C\u002Fp>\n\u003Ch2 id=\"section-133\">Fonti primarie e linee guida attuali\u003C\u002Fh2>\n\u003Cp>Le fonti seguenti supportano la definizione di RBAC e le linee guida attuali sull'isolamento del tenant. La sezione Aaasaasa AI CMS è una prova di implementazione originale ed è intenzionalmente limitata ai pattern di codice che sono stati verificati.\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 — Role Based Access Control\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Panoramica NIST dei modelli RBAC e dello standard INCITS RBAC, inclusi utenti, ruoli, permessi, operazioni e oggetti.\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 — Glossario RBAC\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Definizioni attuali del glossario NIST del controllo di accesso basato sui ruoli come assegnazione di permessi tramite ruoli.\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 — La mentalità dell'isolamento\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Linee guida AWS SaaS che distinguono esplicitamente autenticazione\u002Fautorizzazione dall'isolamento del tenant e raccomandano meccanismi di isolamento condivisi.\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 sull'autorizzazione multi-tenant\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Linee guida attuali che spiegano la differenza tra autorizzazione e isolamento del tenant nelle applicazioni 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 — Considerazioni di progettazione multi-tenant\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Linee guida SaaS attuali che distinguono l'isolamento del tenant dall'autorizzazione e discutono modelli di policy di autorizzazione pooled\u002Fsiloed.\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 — Cheat Sheet sulla sicurezza delle applicazioni multi-tenant\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Linee guida pratiche attuali per contesto tenant, isolamento del database, cache, storage, code, test e prevenzione dell'accesso cross-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 — Cheat Sheet sulla sicurezza RAG\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Linee guida attuali che richiedono il controllo di accesso al momento del recupero e l'isolamento del tenant per i vector store 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 — Test di regressione dell'autorizzazione\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Linee guida attuali per i test, inclusi test di retrocessione del ruolo e di confine cross-tenant.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1410},1791485417531,[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 e isolamento dei tenant risolvono due problemi di sicurezza diversi nei sistemi multi-tenant. Il controllo degli accessi basato sui ruoli (RBAC) determina cosa è consentito fare a un principal autenticato, come leggere ordini, modificare prodotti o gestire utenti. L'isolamento dei tenant determina a quali dati, risorse e contesto di esecuzione di quale tenant quel principal è autorizzato ad accedere. Un utente può essere correttamente autenticato e correttamente assegnato a un ruolo RBAC e tuttavia subire un fallimento di sicurezza se l'applicazione consente a quel ruolo di operare sulle risorse di un altro tenant.","paragraph",{},{"id":221,"data":222,"type":226,"tunes":227},"direct",{"body":223,"title":224,"variant":225},"\u003Cstrong>RBAC risponde a \"cosa può fare questa identità?\" L'isolamento dei tenant risponde a \"all'interno di quale confine può farlo?\"\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Un'applicazione multi-tenant sicura normalmente necessita di entrambi. Un amministratore di tenant può avere permessi ampi, ma tali permessi dovrebbero rimanere limitati al tenant dell'amministratore, a meno che non esista un'autorità a livello di piattaforma esplicitamente separata.","Risposta diretta","info","callout",{},{"id":229,"data":230,"type":226,"tunes":234},"boundary",{"body":231,"title":232,"variant":233},"Assegnare a un utente il ruolo \u003Ccode>ADMIN\u003C\u002Fcode> non implica automaticamente \"amministratore solo del tenant A\". Il ruolo deve essere valutato insieme al contesto di tenant verificato e alla proprietà del tenant della risorsa di destinazione. Altrimenti un ruolo valido può diventare un privilegio cross-tenant.","Un ruolo non è un confine di tenant","warning",{},{"id":236,"data":237,"type":226,"tunes":241},"current",{"body":238,"title":239,"variant":240},"La distinzione di fondo è stabile. NIST definisce RBAC attorno a utenti, ruoli, permessi, operazioni e oggetti. Le attuali linee guida AWS SaaS affermano esplicitamente che autenticazione e autorizzazione non equivalgono all'isolamento dei tenant, e che un utente può essere autenticato e autorizzato pur accedendo alle risorse di un altro tenant se l'isolamento non è applicato separatamente. Anche le attuali linee guida OWASP sulla sicurezza multi-tenant trattano l'isolamento dei tenant come un requisito trasversale a tutti i livelli che copre API, database, cache, storage, code e altre risorse condivise.","Nota sulle fonti attuali — 8 ottobre 2026","note",{},{"id":243,"data":244,"type":248,"tunes":249},"toc",{"title":245,"maxLevel":246,"minLevel":247},"Indice",3,2,"tableOfContents",{},{"id":251,"data":252,"type":42,"tunes":254},"h-meaning",{"text":253,"level":247},"Cosa controlla realmente RBAC",{},{"id":256,"data":257,"type":218,"tunes":259},"p-rbac-1",{"text":258},"RBAC è un modello di autorizzazione in cui i permessi sono associati ai ruoli e gli utenti sono assegnati a tali ruoli. Il ruolo funge da astrazione amministrativa tra identità e permessi.",{},{"id":261,"data":262,"type":218,"tunes":264},"p-rbac-2",{"text":263},"Il lavoro classico di NIST su RBAC formalizza questo concetto attorno a utenti, ruoli, permessi, operazioni e oggetti. Il vantaggio pratico è che un'organizzazione può gestire l'autorizzazione attraverso ruoli relativamente stabili basati su mansioni o responsabilità, invece di collegare ogni permesso direttamente a ogni utente.",{},{"id":266,"data":267,"type":218,"tunes":269},"p-rbac-3",{"text":268},"Un ruolo come EDITOR può quindi significare: può leggere contenuti, scrivere contenuti e pubblicare contenuti. Un ruolo come ACCOUNTANT può significare: può leggere dati di fatturazione, riconciliare fatture e approvare regolamenti.",{},{"id":271,"data":272,"type":42,"tunes":274},"h-tenant",{"text":273,"level":247},"Cosa controlla realmente l'isolamento dei tenant",{},{"id":276,"data":277,"type":218,"tunes":279},"p-tenant-1",{"text":278},"L'isolamento dei tenant è l'insieme dei meccanismi che impediscono a un tenant di leggere, modificare, influenzare o ricevere accidentalmente le risorse di un altro tenant in un sistema condiviso.",{},{"id":281,"data":282,"type":218,"tunes":284},"p-tenant-2",{"text":283},"Il confine protetto è più ampio delle righe del database. Lo stato specifico di un tenant può esistere in tabelle relazionali, object storage, indici vettoriali, cache, indici di ricerca, messaggi in coda, file, artefatti temporanei, job in background, analisi, limiti di velocità e risorse infrastrutturali.",{},{"id":286,"data":287,"type":218,"tunes":289},"p-tenant-3",{"text":288},"Le linee guida AWS per SaaS rendono esplicita la distinzione: l'autorizzazione concede l'accesso alle risorse, mentre l'isolamento dei tenant garantisce che tali risorse non possano attraversare il confine del tenant sbagliato anche quando l'infrastruttura è condivisa.",{},{"id":291,"data":292,"type":42,"tunes":294},"h-simple",{"text":293,"level":247},"L'esempio più semplice",{},{"id":296,"data":297,"type":218,"tunes":299},"p-simple-1",{"text":298},"Supponiamo che Alice sia un'amministratrice del Tenant A e Bob sia un amministratore del Tenant B. Entrambi gli utenti possiedono legittimamente lo stesso ruolo ADMIN.",{},{"id":301,"data":302,"type":218,"tunes":304},"p-simple-2",{"text":303},"RBAC può correttamente concludere che entrambi gli utenti possono eseguire un'operazione come users.read. Ma quando Alice richiede l'ID utente 847, l'applicazione deve comunque verificare che l'utente 847 appartenga al Tenant A.",{},{"id":306,"data":307,"type":218,"tunes":309},"p-simple-3",{"text":308},"Se l'API controlla solo \"Alice ha ADMIN\" e poi esegue SELECT * FROM users WHERE id = 847, RBAC ha avuto successo mentre l'isolamento dei tenant ha fallito.",{},{"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. Autenticare il principal","Stabilire chi è l'utente, il servizio o l'agente.",{"label":318,"description":319},"2. Risolvere il contesto di tenant verificato","Determinare quale contesto di tenant si applica dalle informazioni attendibili lato server su identità\u002Fappartenenza.",{"label":321,"description":322},"3. Risolvere il permesso","Valutare se il ruolo o la policy del principal consente l'operazione richiesta.",{"label":324,"description":325},"4. Delimitare la risorsa di destinazione","Verificare che l'oggetto di destinazione appartenga al tenant consentito o a un ambito esplicitamente condiviso.",{"label":327,"description":328},"5. Applicare al confine di accesso","Eseguire l'operazione su database, cache, storage, coda o servizio con i vincoli di tenant applicati.",{"label":330,"description":331},"6. Verificare entrambe le dimensioni","Registrare principal, tenant, operazione, destinazione e risultato in modo che i tentativi cross-tenant siano visibili.","Una decisione di autorizzazione multi-tenant corretta","auto","processFlow",{},{"id":337,"data":338,"type":42,"tunes":340},"h-stops",{"text":339,"level":247},"Dove si ferma l'esempio semplice",{},{"id":342,"data":343,"type":218,"tunes":345},"p-stops-1",{"text":344},"I sistemi reali spesso contengono diverse classi di identità: utenti tenant, amministratori di piattaforma, worker in background, integrazioni, agenti e servizi operativi cross-tenant. Alcune di queste attraversano legittimamente i confini dei tenant.",{},{"id":347,"data":348,"type":218,"tunes":350},"p-stops-2",{"text":349},"Ciò non elimina la necessità di isolamento. Significa che l'autorità cross-tenant deve essere esplicita, ristretta e verificabile separatamente, invece di emergere accidentalmente da un ruolo globale o da una connessione al database senza scope.",{},{"id":352,"data":353,"type":218,"tunes":355},"p-stops-3",{"text":354},"L'isolamento dei tenant può anche variare a seconda del livello. Un prodotto può condividere i server applicativi separando i database, oppure utilizzare un database condiviso con policy a livello di riga, offrendo al contempo ai tenant premium storage o capacità di calcolo isolati. Non esiste un'unica topologia di isolamento universale.",{},{"id":357,"data":358,"type":42,"tunes":360},"h-compare",{"text":359,"level":247},"RBAC vs isolamento dei tenant",{},{"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","Domanda principale",[369,369],"",{"id":371,"label":372,"values":373},"unit","Unità tipica",[369,369],{"id":375,"label":376,"values":377},"example","Esempio",[369,369],{"id":379,"label":380,"values":381},"failure","Errore tipico",[369,369],{"id":383,"label":384,"values":385},"implementation","Implementazione tipica",[369,369],{"id":387,"label":388,"values":389},"scope","Può esistere da solo?",[369,369],"Due diverse dimensioni di sicurezza","table",[393,396],{"id":394,"label":395},"rbac","RBAC",{"id":397,"label":398},"tenant","Isolamento dei tenant","comparison",{},{"id":402,"data":403,"type":42,"tunes":405},"h-authn",{"text":404,"level":247},"Autenticazione, autorizzazione e isolamento sono tre controlli diversi",{},{"id":407,"data":408,"type":391,"tunes":425},"three-checks",{"content":409,"stretched":43,"withHeadings":14},[410,414,418,422],[411,412,413],"Livello","Domanda","Esempio di errore",[415,416,417],"Autenticazione","Chi è questo principale?","L'attaccante si spaccia per Alice",[419,420,421],"Autorizzazione \u002F RBAC","Questo principale può eseguire questa operazione?","Un visualizzatore può eliminare utenti",[398,423,424],"Questa operazione può raggiungere questo confine di tenant\u002Frisorsa?","L'amministratore del Tenant A legge l'ordine del Tenant B",{},{"id":427,"data":428,"type":218,"tunes":430},"p-authn-1",{"text":429},"Questi controlli sono correlati ma non sostituibili. L'autenticazione può essere perfetta mentre l'autorizzazione fallisce. L'autorizzazione può essere corretta mentre l'isolamento dei tenant fallisce. Un percorso di richiesta SaaS sicuro necessita di tutti i confini applicabili.",{},{"id":432,"data":433,"type":42,"tunes":435},"h-role-scope",{"text":434,"level":247},"I ruoli necessitano di uno scope",{},{"id":437,"data":438,"type":218,"tunes":440},"p-role-scope-1",{"text":439},"La parola ADMIN è incompleta senza scope. Può significare amministratore di piattaforma, amministratore di tenant, amministratore di progetto, amministratore di workspace o amministratore di un sottosistema.",{},{"id":442,"data":443,"type":218,"tunes":445},"p-role-scope-2",{"text":444},"Nei sistemi multi-tenant, l'assegnazione dei ruoli dovrebbe normalmente essere associata all'appartenenza al tenant o a un altro scope esplicito della risorsa. Lo stesso utente può legittimamente essere ADMIN nel Tenant A e VIEWER nel Tenant B.",{},{"id":447,"data":448,"type":218,"tunes":450},"p-role-scope-3",{"text":449},"Un modello di ruoli globale che ignora questa distinzione può creare una fuga di privilegi anche quando la mappa dei permessi stessa è corretta.",{},{"id":452,"data":453,"type":42,"tunes":455},"h-context",{"text":454,"level":247},"Il contesto del tenant deve provenire da un percorso attendibile",{},{"id":457,"data":458,"type":218,"tunes":460},"p-context-1",{"text":459},"Un ID tenant fornito dal client è utile come selettore, ma non è prova di autorità. Il server deve derivare o verificare l'appartenenza al tenant rispetto all'identità autenticata e ai dati di autorizzazione correnti.",{},{"id":462,"data":463,"type":218,"tunes":465},"p-context-2",{"text":464},"Le attuali linee guida multi-tenant di OWASP raccomandano di stabilire il contesto del tenant all'inizio del ciclo di vita della richiesta e mettono esplicitamente in guardia dal trattare header del client o parametri della richiesta come prova di autorizzazione.",{},{"id":467,"data":468,"type":218,"tunes":470},"p-context-3",{"text":469},"Questo è importante perché una banale modifica della richiesta da tenant=A a tenant=B non deve essere sufficiente per superare il confine di isolamento.",{},{"id":472,"data":473,"type":42,"tunes":475},"h-query",{"text":474,"level":247},"Lo scope del tenant appartiene alla ricerca della risorsa",{},{"id":477,"data":478,"type":218,"tunes":480},"p-query-1",{"text":479},"Un modello comune di isolamento a livello applicativo consiste nell'includere lo scope del tenant nella stessa query che risolve la risorsa.",{},{"id":482,"data":483,"type":391,"tunes":497},"query-table",{"content":484,"stretched":43,"withHeadings":14},[485,488,491,494],[486,487],"Ricerca debole","Ricerca più robusta con scope del tenant",[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},"Questo modello non è l'unico meccanismo di isolamento possibile, ma mantiene la proprietà del tenant vicina all'operazione di accesso ai dati e impedisce che un ID oggetto diventi una capability cross-tenant.",{},{"id":504,"data":505,"type":42,"tunes":507},"h-defense",{"text":506,"level":247},"I controlli applicativi sono utili, ma l'isolamento non dovrebbe dipendere da un comportamento perfetto degli sviluppatori",{},{"id":509,"data":510,"type":218,"tunes":512},"p-defense-1",{"text":511},"Le linee guida sull'isolamento di AWS mettono esplicitamente in guardia dal lasciare l'applicazione dell'isolamento solo agli sviluppatori dei servizi. In una grande codebase, prima o poi una query, una chiave di cache o un percorso di un worker potrebbe omettere lo scope del tenant.",{},{"id":514,"data":515,"type":218,"tunes":517},"p-defense-2",{"text":516},"La difesa in profondità può quindi spostare l'isolamento in middleware condiviso, livelli repository\u002Fservice, motori di policy, Row-Level Security del database, credenziali dedicate, schemi separati o database separati a seconda del rischio e dell'architettura.",{},{"id":519,"data":520,"type":226,"tunes":524},"defense-rule",{"body":521,"title":522,"variant":523},"Il confine più forte è quello che il normale codice applicativo non può aggirare casualmente omettendo una singola condizione \u003Ccode>tenantId\u003C\u002Fcode>.","L'isolamento dovrebbe essere difficile da dimenticare","success",{},{"id":526,"data":527,"type":42,"tunes":529},"h-db",{"text":528,"level":247},"Strategie di isolamento del database",{},{"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],"Strategia","Confine","Forza \u002F compromesso",[539,540,541],"Tabelle condivise + chiave tenant","Policy a livello di riga\u002Fapplicazione","Efficiente dal punto di vista operativo; richiede uno scoping esaustivo del tenant e test solidi",[543,544,545],"Tabelle condivise + RLS del database","Confine della policy del database","Riduce la dipendenza da ogni query applicativa; richiede ruoli corretti, contesto tenant di sessione\u002Ftransazione e copertura delle policy",[547,548,549],"Schemi separati","Confine di namespace \u002F ruolo DB","Separazione logica più forte; maggiore complessità operativa",[551,552,553],"Database separati","Confine di database \u002F credenziali","Isolamento forte e gestione del blast radius più semplice; costi di provisioning e operativi più elevati",[555,556,557],"Infrastruttura\u002Faccount separati","Confine infrastrutturale","Separazione a grana grossa più forte; costi e overhead operativo più elevati",[559,560,561],"Ibrido","Per carico di lavoro\u002Fclasse di dati","Consente un isolamento più forte solo dove rischio\u002Fconformità lo giustificano",{},{"id":564,"data":565,"type":218,"tunes":567},"p-db-1",{"text":566},"L'attuale Multi-Tenant Security Cheat Sheet di OWASP elenca database separati, schemi separati, tabelle condivise con controlli a livello di riga e modelli ibridi. Il modello corretto dipende dal livello di minaccia, dalla conformità, dalle prestazioni e dal costo operativo.",{},{"id":569,"data":570,"type":42,"tunes":572},"h-rls",{"text":571,"level":247},"PostgreSQL Row-Level Security può fornire difesa in profondità",{},{"id":574,"data":575,"type":218,"tunes":577},"p-rls-1",{"text":576},"Con tabelle condivise, PostgreSQL Row-Level Security può applicare un predicato tenant a livello di database, così le query ordinarie non possono vedere righe al di fuori della policy del tenant attivo.",{},{"id":579,"data":580,"type":218,"tunes":582},"p-rls-2",{"text":581},"Tuttavia, RLS non è magia. I superuser di PostgreSQL e i ruoli con BYPASSRLS possono bypassare le policy a livello di riga. OWASP raccomanda quindi di utilizzare un ruolo con privilegi minimi per il percorso di richiesta e di testare la stessa modalità di connessione\u002Fpooling usata in produzione.",{},{"id":584,"data":585,"type":218,"tunes":587},"p-rls-3",{"text":586},"Il riutilizzo delle connessioni è un altro caso limite importante: il contesto del tenant deve essere impostato e reimpostato in modo sicuro per ogni transazione\u002Frichiesta, così una connessione in pool non può far trapelare lo stato di un tenant precedente.",{},{"id":589,"data":590,"type":42,"tunes":592},"h-cache",{"text":591,"level":247},"L'isolamento del tenant deve includere le cache",{},{"id":594,"data":595,"type":218,"tunes":597},"p-cache-1",{"text":596},"Una query al database può avere uno scope perfetto e comunque far trapelare dati attraverso una chiave di cache condivisa.",{},{"id":599,"data":600,"type":218,"tunes":602},"p-cache-2",{"text":601},"Se user:42 esiste sia nel Tenant A sia nel Tenant B, una chiave di cache globale può restituire il valore del tenant sbagliato. Le chiavi di cache sensibili al tenant dovrebbero includere ogni attributo che modifica la visibilità o la semantica del risultato, comunemente tenant, utente, locale, set di funzionalità o versione dei permessi.",{},{"id":604,"data":605,"type":218,"tunes":607},"p-cache-3",{"text":606},"La partizione della cache è difesa in profondità, non un sostituto dell'autorizzazione. La richiesta deve comunque essere autorizzata prima che venga restituito il contenuto protetto memorizzato in cache.",{},{"id":609,"data":610,"type":42,"tunes":612},"h-storage",{"text":611,"level":247},"File e object storage necessitano di un proprio confine di tenant",{},{"id":614,"data":615,"type":218,"tunes":617},"p-storage-1",{"text":616},"L'object storage dovrebbe distinguere oggetti globali, con ambito tenant e con ambito utente. Un prefisso di cartella da solo è solo una convenzione di denominazione, a meno che la policy di accesso non vincoli effettivamente letture e scritture.",{},{"id":619,"data":620,"type":218,"tunes":622},"p-storage-2",{"text":621},"Progettazioni più robuste possono utilizzare chiavi oggetto tenant-aware, policy di bucket, bucket\u002Faccount separati o chiavi di cifratura specifiche per tenant, laddove il rischio o la conformità richiedano un isolamento più forte.",{},{"id":624,"data":625,"type":218,"tunes":627},"p-storage-3",{"text":626},"Gli URL firmati devono essere autorizzati prima dell'emissione e limitati all'oggetto e all'operazione esatti. Il possesso di un identificatore di oggetto non dovrebbe di per sé concedere accesso cross-tenant.",{},{"id":629,"data":630,"type":42,"tunes":632},"h-queues",{"text":631,"level":247},"I job in background e le code possono rompere l'isolamento",{},{"id":634,"data":635,"type":218,"tunes":637},"p-queue-1",{"text":636},"I job asincroni spesso abbandonano il contesto della richiesta HTTP originale, il che rende facile gestire male la propagazione del tenant. Un messaggio in coda che contiene tenantId non è prova sufficiente che il produttore fosse autorizzato.",{},{"id":639,"data":640,"type":218,"tunes":642},"p-queue-2",{"text":641},"Il worker dovrebbe portare un'identità di servizio\u002Futente verificata o una busta di job attendibile, ristabilire il contesto del tenant e riautorizzare le operazioni consequenziali al confine del consumatore.",{},{"id":644,"data":645,"type":218,"tunes":647},"p-queue-3",{"text":646},"L'isolamento del tenant include anche la disponibilità. Un tenant non dovrebbe essere in grado di monopolizzare worker, code, pool di connessioni o risorse di calcolo condivise in modi che degradino materialmente gli altri tenant.",{},{"id":649,"data":650,"type":42,"tunes":652},"h-search",{"text":651,"level":247},"Ricerca e RAG necessitano di retrieval tenant-aware",{},{"id":654,"data":655,"type":218,"tunes":657},"p-search-1",{"text":656},"L'AI multi-tenant introduce un'altra copia del problema di isolamento. I documenti possono essere suddivisi in chunk, incorporati e memorizzati in un indice vettoriale dopo l'ingestione.",{},{"id":659,"data":660,"type":218,"tunes":662},"p-search-2",{"text":661},"L'attuale guida alla sicurezza RAG di OWASP afferma che il controllo degli accessi deve essere applicato al momento del retrieval e che i chunk del Tenant A non devono essere recuperati da query del Tenant B. Non si può semplicemente presumere che i permessi a livello di documento sopravvivano automaticamente alla suddivisione in chunk.",{},{"id":664,"data":665,"type":218,"tunes":667},"p-search-3",{"text":666},"L'indice vettoriale necessita quindi di metadati di tenant\u002Faccesso o di collezioni fisicamente\u002Flogicamente separate in base al design di isolamento. I filtri di retrieval dovrebbero essere applicati prima che contenuti non autorizzati possano entrare nel contesto del modello.",{},{"id":669,"data":670,"type":226,"tunes":673},"rag-rule",{"body":671,"title":672,"variant":233},"Non recuperare chunk cross-tenant e poi istruire il modello linguistico a ignorarli. Una volta che i dati protetti entrano nel contesto del modello, il confine di isolamento è già fallito.","Il modello non deve mai essere il filtro del tenant",{},{"id":675,"data":676,"type":42,"tunes":678},"h-derived",{"text":677,"level":247},"I dati derivati ereditano la sensibilità del tenant",{},{"id":680,"data":681,"type":218,"tunes":683},"p-derived-1",{"text":682},"Embedding, indici di ricerca, miniature, riepiloghi generati, cache, righe di analytics e risposte AI derivano dai dati di origine. Il loro ambito di tenant dovrebbe seguire la fonte, a meno che una trasformazione esplicita crei un artefatto condiviso\u002Fglobale legittimo.",{},{"id":685,"data":686,"type":218,"tunes":688},"p-derived-2",{"text":687},"La cancellazione e l'offboarding devono quindi propagarsi oltre la riga canonica. Rimuovere un documento del tenant lasciando chunk ricercabili o riepiloghi in cache può mantenere un'esposizione cross-tenant o successiva alla conservazione.",{},{"id":690,"data":691,"type":42,"tunes":693},"h-shared",{"text":692,"level":247},"Non tutto appartiene a un tenant",{},{"id":695,"data":696,"type":218,"tunes":698},"p-shared-1",{"text":697},"Le piattaforme multi-tenant hanno spesso risorse intenzionalmente globali: tassonomie di prodotto, template pubblici, permessi di sistema, definizioni di funzionalità o contenuti pubblici.",{},{"id":700,"data":701,"type":218,"tunes":703},"p-shared-2",{"text":702},"Il modello più sicuro è la classificazione esplicita: globale, con ambito tenant, con ambito utente o esplicitamente cross-tenant. Le risorse ambigue sono il punto in cui inizia una fuga di dati accidentale.",{},{"id":705,"data":706,"type":218,"tunes":708},"p-shared-3",{"text":707},"Un oggetto condiviso intenzionalmente dovrebbe avere una motivazione documentata per essere globale, invece di mancare semplicemente di un'associazione a un tenant.",{},{"id":710,"data":711,"type":42,"tunes":713},"h-platform-admin",{"text":712,"level":247},"Gli amministratori della piattaforma richiedono un modello di autorità diverso",{},{"id":715,"data":716,"type":218,"tunes":718},"p-platform-1",{"text":717},"Un operatore della piattaforma potrebbe aver bisogno di ispezionare più tenant per supporto, conformità o operazioni infrastrutturali. Modellare questo come un normale ADMIN di tenant con accesso accidentale al database globale indebolisce sia la sicurezza che l'auditabilità.",{},{"id":720,"data":721,"type":218,"tunes":723},"p-platform-2",{"text":722},"Un design migliore utilizza un'identità di piattaforma distinta o un permesso cross-tenant esplicito, autenticazione più forte, limitazione dello scopo, audit dettagliato e, ove appropriato, controlli di approvazione o break-glass.",{},{"id":725,"data":726,"type":218,"tunes":728},"p-platform-3",{"text":727},"L'accesso cross-tenant dovrebbe quindi essere una capacità denominata, non l'assenza di un filtro tenant.",{},{"id":730,"data":731,"type":42,"tunes":733},"h-abac",{"text":732,"level":247},"RBAC può essere combinato con gli attributi",{},{"id":735,"data":736,"type":218,"tunes":738},"p-abac-1",{"text":737},"Alcune decisioni dipendono da più del ruolo. L'appartenenza al tenant, la regione, il proprietario della risorsa, il livello di abbonamento, il tempo, l'appartenenza al progetto o la classificazione dei dati possono tutti influenzare l'accesso.",{},{"id":740,"data":741,"type":218,"tunes":743},"p-abac-2",{"text":742},"RBAC e ABAC non si escludono a vicenda. Le attuali linee guida di AWS sull'autorizzazione multi-tenant discutono modelli RBAC, ABAC e ibridi. Un ruolo può definire una responsabilità ampia mentre gli attributi limitano quale istanza concreta di risorsa può essere accessibile.",{},{"id":745,"data":746,"type":218,"tunes":748},"p-abac-3",{"text":747},"La regola architetturale chiave rimane: non codificare l'isolamento del tenant solo come un nome di ruolo incidentale se l'identità del tenant è un confine di risorsa di prima classe.",{},{"id":750,"data":751,"type":42,"tunes":753},"h-matrix",{"text":752,"level":247},"Le decisioni di autorizzazione sono almeno bidimensionali",{},{"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],"Principale","Permesso del ruolo","Relazione con il tenant","Decisione",[764,765,766,767],"Alice","orders.read","L'ordine appartiene al tenant di Alice","Consenti",[764,765,769,770],"L'ordine appartiene a un altro tenant","Nega",[764,772,766,773],"orders.write","Consenti se il ruolo include la scrittura",[764,772,769,770],[776,777,778,779],"Supporto piattaforma","support.cross_tenant.read","Ambito di supporto esplicito + tenant di destinazione verificato","Potenzialmente consenti secondo la policy della piattaforma",[781,782,783,784],"Worker in background","orders.process","Ambito di servizio attendibile per il tenant del job","Consenti solo per il tenant del job verificato",{},{"id":787,"data":788,"type":42,"tunes":790},"h-implementation",{"text":789,"level":247},"Evidenza dell'implementazione originale: Aaasaasa AI CMS",{},{"id":792,"data":793,"type":226,"tunes":796},"impl-note",{"body":794,"title":795,"variant":240},"Aaasaasa AI CMS contiene un'implementazione concreta di RBAC con ambito tenant. È un'evidenza utile di come l'autorizzazione dei ruoli e l'ambito del tenant possano essere combinati, ma non dovrebbe essere presentata come prova che ogni livello di archiviazione, cache o infrastruttura abbia un isolamento completo del tenant.","Evidenza dell'implementazione originale",{},{"id":798,"data":799,"type":218,"tunes":801},"p-impl-1",{"text":800},"Il servizio RBAC definisce codici di permesso tipizzati come cms.content.read, shop.orders.write, billing.reconcile e users.roles. I ruoli di sistema mappano quei permessi in insiemi di responsabilità denominati.",{},{"id":803,"data":804,"type":218,"tunes":806},"p-impl-2",{"text":805},"I record dei ruoli vengono creati e risolti con un tenantId. I ruoli di sistema vengono inseriti o aggiornati utilizzando un'identità composita tenant\u002Fcodice, e l'elenco dei ruoli è filtrato per tenant.",{},{"id":808,"data":809,"type":218,"tunes":811},"p-impl-3",{"text":810},"L'aggiornamento e l'eliminazione dei ruoli risolvono prima il ruolo utilizzando sia l'ID del ruolo che l'ID del tenant. Anche le assegnazioni utente-ruolo vengono memorizzate e sostituite nel contesto del tenant corrente.",{},{"id":813,"data":814,"type":218,"tunes":816},"p-impl-4",{"text":815},"La risoluzione dei permessi legge le assegnazioni esplicite utente-ruolo con ambito sia tenantId che userId. Questo impedisce che l'assegnazione di ruolo di un tenant diventi automaticamente l'assegnazione di ruolo di un altro tenant.",{},{"id":818,"data":819,"type":218,"tunes":821},"p-impl-5",{"text":820},"A livello API, le route RBAC amministrative risolvono un contesto tenant prima di creare o modificare ruoli. Questa è la direzione corretta: l'amministrazione dei permessi stessa deve rispettare la tenancy.",{},{"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],"Pattern di implementazione osservato","Significato di sicurezza",[830,831],"Codici di permesso tipizzati","Il vocabolario delle operazioni RBAC è esplicito",[833,834],"Mappe ruolo di sistema → permessi","I ruoli aggregano permessi invece di codificare direttamente gli utenti",[836,837],"Identità del ruolo tenantId_code","Lo stesso ruolo logico può esistere separatamente per tenant",[839,840],"La ricerca del ruolo usa id + tenantId","La modifica del ruolo è limitata al tenant",[842,843],"La relazione utente-ruolo memorizza tenantId","L'appartenenza non è inferita globalmente dal solo ruolo",[845,846],"La risoluzione dei permessi usa tenantId + userId","L'autorizzazione è valutata all'interno del contesto tenant",{},{"id":849,"data":850,"type":226,"tunes":853},"impl-boundary",{"body":851,"title":852,"variant":233},"Il RBAC con ambito tenant è uno strato. L'isolamento completo dei tenant deve coprire anche tutte le ricerche di risorse di proprietà del tenant, database, cache, file, indici di ricerca\u002Fvettoriali, job in background, integrazioni e percorsi operativi. L'evidenza del repository qui supporta il pattern di progettazione RBAC\u002Fambito tenant, non un'affermazione di isolamento SaaS verificato in modo indipendente.","Cosa questa evidenza non prova",{},{"id":855,"data":856,"type":42,"tunes":858},"h-ai",{"text":857,"level":247},"Perché questa distinzione conta ancora di più per gli agenti AI",{},{"id":860,"data":861,"type":218,"tunes":863},"p-ai-1",{"text":862},"Gli agenti AI possono trasformare un errore di permesso in una sequenza di azioni. Se a un agente viene fornito uno strumento ampio orders.read senza applicazione con ambito tenant, un errore di ragionamento o di prompt-injection può causare letture cross-tenant alla velocità della macchina.",{},{"id":865,"data":866,"type":218,"tunes":868},"p-ai-2",{"text":867},"Le descrizioni degli strumenti dell'agente possono menzionare vincoli tenant, ma l'applicazione deve comunque avvenire nel runtime\u002Fservizio\u002Fstrato dati attendibile. Le istruzioni in linguaggio naturale non sono un confine di autorizzazione.",{},{"id":870,"data":871,"type":218,"tunes":873},"p-ai-3",{"text":872},"Lo stesso vale per RAG: un agente può avere il permesso di usare lo strumento di ricerca mentre il backend di ricerca deve comunque impedire che la query del Tenant A restituisca i chunk del Tenant B.",{},{"id":875,"data":876,"type":42,"tunes":878},"h-tests",{"text":877,"level":247},"Testare RBAC e isolamento tenant separatamente",{},{"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],"Famiglia di test","Cosa dovrebbe provare",[887,888],"Test di retrocessione del ruolo","Un utente senza un permesso non può eseguire l'operazione nemmeno all'interno del proprio tenant",[890,891],"Test oggetto cross-tenant","Un utente con il ruolo corretto non può comunque accedere allo stesso tipo di risorsa in un altro tenant",[893,894],"Manomissione dell'identificatore","La modifica degli ID oggetto\u002Ftenant non attraversa l'ambito",[896,897],"Test endpoint di elenco\u002Fin blocco","Le query ampie restituiscono solo dati tenant autorizzati",[899,900],"Test riutilizzo cache","Due tenant che utilizzano processi\u002Fconnessioni riutilizzati non ricevono mai lo stato in cache dell'altro",[902,903],"Test ruolo richiesta RLS","Il ruolo di richiesta di produzione non può bypassare le politiche di riga",[905,906],"Test worker asincrono","Il contesto tenant sopravvive all'accodamento e viene rivalidato al consumo",[908,909],"Test recupero vettoriale","La query del Tenant A non recupera mai i chunk del Tenant B",[911,912],"Test amministratore piattaforma","La capacità cross-tenant è esplicita, ristretta e verificabile",[914,915],"Test offboarding","I dati del tenant e gli indici\u002Fcache derivati vengono rimossi secondo la politica",{},{"id":918,"data":919,"type":218,"tunes":921},"p-tests-1",{"text":920},"La guida OWASP sui test di regressione dell'autorizzazione menziona specificamente i test sui confini cross-tenant perché modifiche al codice in caching, query o servizi condivisi possono rompere silenziosamente l'isolamento anche quando i test dei ruoli continuano a passare.",{},{"id":923,"data":924,"type":42,"tunes":926},"h-failures",{"text":925,"level":247},"Modalità di errore comuni",{},{"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],"Modalità di errore","Perché fallisce",[935,936],"Controlla il ruolo ma non il tenant","Un ruolo valido diventa autorità cross-tenant",[938,939],"Fidarsi dell'ID tenant dalla richiesta","Il client controlla il selettore di isolamento",[941,942],"Limitare l'interfaccia utente ma non l'API","I pulsanti nascosti non proteggono le risorse backend",[944,945],"Endpoint di dettaglio tenant-aware, endpoint di elenco senza ambito","Le letture in blocco fanno trapelare altri tenant",[947,948],"Filtro tenant nella maggior parte delle query","Un percorso dimenticato rompe il confine",[950,951],"Chiavi cache globali","L'isolamento corretto del database viene bypassato dai dati in cache",[953,954],"Indice vettoriale condiviso senza filtri di metadati applicati","RAG recupera i chunk di un altro tenant",[956,957],"ID tenant del messaggio in coda trattato come autorizzazione","Un job falsificato o prodotto erroneamente può attraversare il confine tenant",[959,960],"Amministratore piattaforma modellato come ADMIN ordinario","Il potere cross-tenant diventa implicito e difficile da verificare",[962,963],"Ruolo copiato globalmente tra appartenenze tenant","L'utente riceve permessi in tenant in cui non è mai stato assegnato",[965,966],"Database separati ma credenziale privilegiata condivisa","L'applicazione può comunque attraversare i database se la sua credenziale è troppo ampia",[968,969],"RLS con ruolo di richiesta BYPASSRLS","La politica del database esiste ma non protegge il percorso di richiesta effettivo",[971,972],"UUID casuali trattati come isolamento","Gli identificatori difficili da indovinare riducono l'enumerazione ma non autorizzano l'accesso",{},{"id":975,"data":976,"type":42,"tunes":978},"h-misconceptions",{"text":977,"level":247},"Idee sbagliate comuni",{},{"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],"Idea sbagliata","Correzione",[987,988],"“RBAC fornisce l'isolamento tenant.”","RBAC controlla i permessi; l'isolamento richiede anche l'ambito tenant\u002Frisorsa.",[990,991],"“Se l'utente è un amministratore, i controlli tenant sono superflui.”","L'autorità di amministratore deve comunque avere un ambito esplicito.",[993,994],"“L'ID tenant nel JWT è sufficiente.”","Può essere un input attendibile solo se validato e applicato in modo coerente a ogni percorso di risorsa protetto.",[996,997],"“Database separati rimuovono i requisiti di autorizzazione.”","Gli utenti hanno comunque bisogno di permessi a livello di operazione all'interno del loro tenant.",[999,1000],"“Una colonna tenant_id significa che il sistema è isolato.”","Il campo aiuta solo se i percorsi di accesso lo applicano.",[1002,1003],"“Gli UUID impediscono l'accesso cross-tenant.”","Gli identificatori imprevedibili sono difesa in profondità, non autorizzazione.",[1005,1006],"“RLS significa che il codice dell'applicazione non ha bisogno di controlli di sicurezza.”","L'autorizzazione dell'applicazione, i ruoli DB corretti e la copertura delle politiche contano ancora.",[1008,1009],"“Un unico database vettoriale condiviso è insicuro.”","Può essere sicuro se l'isolamento è applicabile e verificato; la separazione fisica è un'opzione, non l'unica.",[1011,1012],"“Il supporto piattaforma ha bisogno di ADMIN globale.”","Il supporto cross-tenant dovrebbe essere un'autorità distinta, vincolata e verificabile.",[1014,1015],"“I servizi interni possono saltare i controlli tenant.”","I percorsi interni possono comunque essere compromessi o mal configurati e devono preservare il contesto tenant.",{},{"id":1018,"data":1019,"type":42,"tunes":1021},"h-design",{"text":1020,"level":247},"Una sequenza di progettazione pratica",{},{"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. Definire la proprietà del tenant","Classificare quali entità e risorse sono globali, con ambito tenant, con ambito utente o intenzionalmente cross-tenant.",{"label":1030,"description":1031},"2. Definire le operazioni","Creare permessi espliciti per letture, scritture, pubblicazione, approvazioni, amministrazione e altre azioni aziendali.",{"label":1033,"description":1034},"3. Definire i ruoli","Raggruppare i permessi in base alle responsabilità senza incorporare un ambito globale accidentale.",{"label":1036,"description":1037},"4. Definire l'ambito di appartenenza","Vincolare le assegnazioni di ruolo al contesto tenant\u002Fworkspace\u002Fprogetto in cui si applicano.",{"label":1039,"description":1040},"5. Risolvere il contesto tenant attendibile","Derivare l'identità del tenant dall'appartenenza autenticata e verificata dal server o dall'autorizzazione del servizio.",{"label":1042,"description":1043},"6. Applicare la proprietà delle risorse","Applicare l'ambito tenant a ogni confine di dati\u002Fservizio di proprietà del tenant.",{"label":1045,"description":1046},"7. Aggiungere difesa in profondità","Utilizzare RLS, credenziali separate, schemi\u002Fdatabase, politiche di archiviazione o motori di policy dove il rischio lo giustifica.",{"label":1048,"description":1049},"8. Trasportare l'ambito attraverso i sistemi derivati","Preservare i metadati del tenant in cache, ricerca, indici vettoriali, code, file e analisi.",{"label":1051,"description":1052},"9. Modellare esplicitamente le operazioni cross-tenant","Separare l'amministrazione della piattaforma e le identità di servizio dai ruoli tenant ordinari.",{"label":1054,"description":1055},"10. Testare entrambi gli assi","Eseguire test negativi per permesso mancante e per tenant errato in modo indipendente.",{"label":1057,"description":1058},"11. Verificare tenant + permesso insieme","Registrare chi ha agito, in quale tenant, su quale target e sotto quale autorità.",{"label":1060,"description":1061},"12. Ripetere i test dopo modifiche a schema\u002Fruntime","L'isolamento può rompersi quando vengono introdotte nuove tabelle, cache, code o percorsi di recupero.","Progettare permessi e isolamento come dimensioni separate",{},{"id":1065,"data":1066,"type":42,"tunes":1068},"h-checklist",{"text":1067,"level":247},"Checklist RBAC + isolamento tenant",{},{"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],"Risposta attesa",[1076,1077],"Chi è il principale?","Identità utente\u002Fservizio\u002Fagente autenticata",[1079,1080],"Quale contesto tenant si applica?","Appartenenza verificata dal server o ambito di servizio",[1082,1083],"Quale operazione è richiesta?","Permesso tipizzato o azione di policy",[1085,1086],"Il principale ha quel permesso?","Decisione ruolo\u002Fpolicy",[1088,1089],"Chi possiede la risorsa target?","Classificazione esplicita tenant\u002Fglobale\u002Futente",[1091,1092],"L'ambito della risorsa corrisponde all'autorità?","Ricerca\u002Fpolicy tenant-aware",[1094,1095],"Lo storage può bypassare i controlli dell'applicazione?","Decisione di difesa in profondità documentata",[1097,1098],"Le cache sono sicure per il tenant?","Chiavi\u002Fnamespace e autorizzazione preservano l'ambito tenant",[1100,1101],"File\u002Fblob sono sicuri per il tenant?","La policy degli oggetti e l'emissione di URL firmati applicano l'ambito",[1103,1104],"I job asincroni sono sicuri per il tenant?","Il contesto verificato si propaga e viene rivalidato",[1106,1107],"RAG\u002Fricerca è sicuro per il tenant?","Isolamento di metadati\u002Fcollezioni applicato prima del contesto del modello",[1109,1110],"Gli amministratori cross-tenant sono espliciti?","Autorità, controlli e audit separati",[1112,1113],"Le credenziali ordinarie possono bypassare l'isolamento?","No, o percorso eccezionale strettamente documentato",[1115,1116],"I test negativi cross-tenant sono automatizzati?","Sì per ogni strato di accesso rilevante",{},{"id":1119,"data":1120,"type":42,"tunes":1122},"h-edge",{"text":1121,"level":247},"Casi limite e limitazioni",{},{"id":1124,"data":1125,"type":218,"tunes":1127},"p-edge-1",{"text":1126},"Un utente può appartenere a più tenant. Il tenant corrente dovrebbe quindi essere un contesto di esecuzione esplicito, non dedotto permanentemente dall'account utente.",{},{"id":1129,"data":1130,"type":218,"tunes":1132},"p-edge-2",{"text":1131},"Alcune risorse sono intenzionalmente condivise tra tenant selezionati, come spazi di collaborazione o dati di consorzio. Ciò richiede un modello di condivisione esplicito; fingere che la risorsa appartenga a un tenant e aggiungere eccezioni in seguito di solito crea autorizzazioni ambigue.",{},{"id":1134,"data":1135,"type":218,"tunes":1137},"p-edge-3",{"text":1136},"L'isolamento da vicini rumorosi è correlato ma diverso dall'isolamento di riservatezza. Un tenant potrebbe non vedere mai i dati di un altro tenant e tuttavia esaurire CPU condivisa, capacità di coda o connessioni al database. I limiti di velocità e le quote di risorse possono quindi essere tenant-aware come confine di disponibilità.",{},{"id":1139,"data":1140,"type":218,"tunes":1142},"p-edge-4",{"text":1141},"L'isolamento fisico non è automaticamente sicuro se le credenziali del piano di controllo o i percorsi amministrativi possono attraversare i confini. L'isolamento logico non è automaticamente debole se le politiche sono applicate centralmente, con privilegi minimi e testate a fondo.",{},{"id":1144,"data":1145,"type":218,"tunes":1147},"p-edge-5",{"text":1146},"I requisiti di isolamento dei tenant possono differire per classe di dati. Dati di catalogo pubblici, record di fatturazione e documenti AI privati possono giustificare confini di archiviazione e crittografia diversi all'interno dello stesso prodotto SaaS.",{},{"id":1149,"data":1150,"type":42,"tunes":1152},"h-change",{"text":1151,"level":247},"Cosa cambierebbe questa risposta?",{},{"id":1154,"data":1155,"type":218,"tunes":1157},"p-change-1",{"text":1156},"L'implementazione esatta cambia con l'architettura: API serverless, Kubernetes, PostgreSQL, object storage, database vettoriali e motori di policy espongono primitive di isolamento diverse.",{},{"id":1159,"data":1160,"type":218,"tunes":1162},"p-change-2",{"text":1161},"La forza richiesta cambia anche con la regolamentazione, i contratti dei clienti, la sensibilità dei dati, il modello di minaccia e la scala operativa. Alcuni tenant possono giustificare database o infrastrutture siloed mentre altri condividono risorse in pool.",{},{"id":1164,"data":1165,"type":218,"tunes":1167},"p-change-3",{"text":1166},"La distinzione concettuale non cambia: il permesso di eseguire un'operazione non è la stessa cosa del permesso di attraversare un confine di tenant.",{},{"id":1169,"data":1170,"type":42,"tunes":1172},"h-related",{"text":1171,"level":247},"Conoscenza canonica correlata",{},{"id":1174,"data":1175,"type":218,"tunes":1177},"p-related-1",{"text":1176},"S01 è un prerequisito di confine di sicurezza per Enterprise AI Architecture e AI Governance. Una volta che strumenti AI, RAG o agenti operano su dati multi-tenant, l'identità del tenant deve viaggiare attraverso il recupero, l'esecuzione degli strumenti, la memoria, le cache e le tracce di audit.",{},{"id":1179,"data":1180,"type":218,"tunes":1182},"p-related-2",{"text":1181},"Si collega anche direttamente ad Agentic AI: la capacità degli strumenti e il permesso del ruolo devono comunque essere vincolati dalla proprietà del tenant prima che un agente possa leggere o modificare risorse aziendali.",{},{"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: The Agent Protocol Stack Explained","L'interoperabilità dei protocolli non sostituisce l'autorizzazione o l'isolamento dei tenant. La scoperta delle capacità e l'autorità aziendale rimangono preoccupazioni architetturali separate.","Leggi l'articolo sullo stack di protocolli","referralArticle",{},{"id":1193,"data":1194,"type":218,"tunes":1196},"p-related-3",{"text":1195},"Per RAG, l'isolamento dei tenant deve essere applicato prima che i chunk protetti raggiungano il contesto del modello.",{},{"id":1198,"data":1199,"type":1190,"tunes":1204},"ref-rag",{"url":1200,"title":1201,"excerpt":1202,"ctaLabel":1203},"https:\u002F\u002Fstajic.de\u002Fit\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","What Is RAG? The Simplest Explanation of How It Works","La base di recupero per comprendere dove devono essere applicati il filtraggio delle fonti tenant-aware e l'isolamento del vector store.","Leggi le basi di RAG",{},{"id":1206,"data":1207,"type":42,"tunes":1209},"h-faq",{"text":1208,"level":247},"Domande frequenti",{},{"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","RBAC determina quali operazioni un principale può eseguire. L'isolamento dei tenant determina a quali risorse di quale tenant quelle operazioni possono accedere. Le applicazioni multi-tenant sicure normalmente necessitano di entrambi.","Qual è la differenza tra RBAC e isolamento dei tenant?",{"id":1219,"answer":1220,"question":1221},"faq2","No. ADMIN dovrebbe avere uno scope esplicito. Un amministratore di tenant normalmente ha ampi permessi solo all'interno di quel tenant, mentre l'amministrazione della piattaforma cross-tenant dovrebbe essere modellata separatamente.","Un ruolo ADMIN consente automaticamente l'accesso a tutti i tenant?",{"id":1223,"answer":1224,"question":1225},"faq3","No. L'autenticazione prova l'identità. L'autorizzazione controlla le azioni consentite. L'isolamento dei tenant impedisce inoltre che tali azioni raggiungano le risorse del tenant sbagliato.","L'autenticazione è sufficiente per l'isolamento dei tenant?",{"id":1227,"answer":1228,"question":1229},"faq4","Può essere un input per il contesto del tenant, ma il server deve verificare l'appartenenza\u002Fautorità corrente e applicare lo scope ai confini delle risorse protette. Un claim da solo non sostituisce i controlli di isolamento.","Il tenantId dovrebbe essere memorizzato nel JWT?",{"id":1231,"answer":1232,"question":1233},"faq5","Non necessariamente. Modelli di isolamento con tabella condivisa, RLS, schema, database, infrastruttura e ibridi possono essere tutti validi a seconda del rischio e dei requisiti operativi.","Ho bisogno di un database separato per tenant?",{"id":1235,"answer":1236,"question":1237},"faq6","RLS può fornire una forte difesa in profondità, ma ruoli di database corretti, contesto della richiesta, copertura delle policy e autorizzazione a livello di applicazione contano comunque.","PostgreSQL RLS può sostituire i filtri tenant nel codice dell'applicazione?",{"id":1239,"answer":1240,"question":1241},"faq7","Lo scope tenant\u002Faccesso dovrebbe essere applicato durante il recupero in modo che i chunk non autorizzati non entrino mai nel contesto del modello. Conserva i metadati di accesso attraverso chunking e indicizzazione.","Come dovrebbe RAG applicare l'isolamento dei tenant?",{"id":1243,"answer":1244,"question":1245},"faq8","Sì. Questo è comune nel SaaS B2B ed è una forte ragione per limitare le assegnazioni di ruolo all'appartenenza al tenant piuttosto che trattare i ruoli come globalmente collegati all'utente.","Un utente può avere ruoli diversi in tenant diversi?",{"id":1247,"answer":1248,"question":1249},"faq9","Usa test negativi cross-tenant: crea almeno due tenant, assegna a un utente permessi validi in un tenant, poi dimostra che ogni percorso protetto nega l'accesso alle risorse dell'altro tenant.","Qual è il miglior test per l'isolamento dei tenant?","FAQ su RBAC vs isolamento dei tenant",{},{"id":1253,"data":1254,"type":42,"tunes":1256},"h-glossary",{"text":1255,"level":247},"Glossario",{},{"id":1258,"data":1259,"type":1258,"tunes":1306},"glossary",{"title":1260,"entries":1261},"Termini chiave di sicurezza multi-tenant",[1262,1264,1267,1271,1274,1278,1282,1286,1290,1294,1298,1302],{"term":395,"anchor":394,"definition":1263},"Role-Based Access Control: un modello di autorizzazione che associa i permessi ai ruoli e assegna utenti o principal a tali ruoli.",{"term":1265,"anchor":397,"definition":1266},"Tenant","Un cliente, organizzazione, workspace o altro consumatore logico isolato di un sistema multi-tenant condiviso.",{"term":1268,"anchor":1269,"definition":1270},"Isolamento del tenant","tenant-isolation","Meccanismi che impediscono a un tenant di accedere, modificare o ricevere le risorse di un altro tenant in un sistema condiviso.",{"term":415,"anchor":1272,"definition":1273},"authentication","Verifica dell'identità di un utente, servizio o altro principal.",{"term":1275,"anchor":1276,"definition":1277},"Autorizzazione","authorization","Processo decisionale che determina se un principal può eseguire un'operazione richiesta su una risorsa.",{"term":1279,"anchor":1280,"definition":1281},"Permesso","permission","Un'operazione o capacità consentita e definita, come orders.read o users.write.",{"term":1283,"anchor":1284,"definition":1285},"Ruolo","role","Un raggruppamento denominato di permessi associato a una responsabilità o funzione.",{"term":1287,"anchor":1288,"definition":1289},"ABAC","abac","Attribute-Based Access Control: autorizzazione basata su attributi del principal, della risorsa, dell'azione o dell'ambiente.",{"term":1291,"anchor":1292,"definition":1293},"Sicurezza a livello di riga","row-level-security","Meccanismo di policy del database che limita quali righe un ruolo o una sessione del database può leggere o modificare.",{"term":1295,"anchor":1296,"definition":1297},"Accesso cross-tenant","cross-tenant-access","Qualsiasi percorso di accesso in cui un principal che opera in un contesto tenant raggiunge risorse appartenenti a un altro tenant.",{"term":1299,"anchor":1300,"definition":1301},"Amministratore della piattaforma","platform-administrator","Un'identità operativa privilegiata con autorità esplicitamente modellata che può estendersi su più tenant.",{"term":1303,"anchor":1304,"definition":1305},"Contesto del tenant","tenant-context","L'ambito del tenant verificato sotto il quale viene eseguita la richiesta, il job o l'operazione dell'agente corrente.",{},{"id":1308,"data":1309,"type":42,"tunes":1311},"h-conclusion",{"text":1310,"level":247},"Conclusione",{},{"id":1313,"data":1314,"type":218,"tunes":1316},"p-conclusion-1",{"text":1315},"RBAC e isolamento del tenant sono meccanismi di sicurezza complementari, non in competizione. RBAC struttura il permesso operativo; l'isolamento del tenant vincola il confine delle risorse entro cui tale permesso può essere applicato.",{},{"id":1318,"data":1319,"type":218,"tunes":1321},"p-conclusion-2",{"text":1320},"Una richiesta multi-tenant robusta necessita quindi di più di \"l'utente ha il ruolo ADMIN\". Richiede un principal verificato, un contesto tenant verificato, un'operazione consentita, un target con ambito tenant e l'applicazione a ogni livello di risorsa che può contenere dati di proprietà del tenant.",{},{"id":1323,"data":1324,"type":218,"tunes":1326},"p-conclusion-3",{"text":1325},"La regola affidabile più breve è: autorizza l'azione, poi isola l'ambito — e non presumere mai che una dimostri l'altra.",{},{"id":1328,"data":1329,"type":42,"tunes":1331},"h-sources",{"text":1330,"level":247},"Fonti primarie e linee guida attuali",{},{"id":1333,"data":1334,"type":218,"tunes":1336},"p-sources-note",{"text":1335},"Le fonti seguenti supportano la definizione di RBAC e le linee guida attuali sull'isolamento del tenant. La sezione Aaasaasa AI CMS è una prova di implementazione originale ed è intenzionalmente limitata ai pattern di codice che sono stati verificati.",{},{"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 — Role Based Access Control","Panoramica NIST dei modelli RBAC e dello standard INCITS RBAC, inclusi utenti, ruoli, permessi, operazioni e oggetti.","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 — Glossario RBAC","Definizioni attuali del glossario NIST del controllo di accesso basato sui ruoli come assegnazione di permessi tramite ruoli.",{},{"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 — La mentalità dell'isolamento","Linee guida AWS SaaS che distinguono esplicitamente autenticazione\u002Fautorizzazione dall'isolamento del tenant e raccomandano meccanismi di isolamento condivisi.",{},{"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 sull'autorizzazione multi-tenant","Linee guida attuali che spiegano la differenza tra autorizzazione e isolamento del tenant nelle applicazioni 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 — Considerazioni di progettazione multi-tenant","Linee guida SaaS attuali che distinguono l'isolamento del tenant dall'autorizzazione e discutono modelli di policy di autorizzazione pooled\u002Fsiloed.",{},{"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 — Cheat Sheet sulla sicurezza delle applicazioni multi-tenant","Linee guida pratiche attuali per contesto tenant, isolamento del database, cache, storage, code, test e prevenzione dell'accesso cross-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 — Cheat Sheet sulla sicurezza RAG","Linee guida attuali che richiedono il controllo di accesso al momento del recupero e l'isolamento del tenant per i vector store 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 — Test di regressione dell'autorizzazione","Linee guida attuali per i test, inclusi test di retrocessione del ruolo e di confine cross-tenant.",{},"2.31","Il controllo RBAC stabilisce cosa può fare un utente; l'isolamento dei tenant stabilisce a quali risorse di quale tenant può accedere tale azione. Scopri perché la sicurezza SaaS multi-tenant richiede entrambi i confini.","\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,"Policy e limiti dati","policy-and-data",{"id":1433,"name":1434,"slug":1435},57,"Limiti dei dati","data-boundaries",{"id":1437,"name":1438,"slug":1439},64,"Architettura dell’informazione","information-architecture",{"id":1441,"login":1442,"email":1443,"displayName":1444},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1446,2439],{"lang":1447,"title":1448,"content":1449,"contentJson":1450,"excerpt":2438},"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":2437},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,1617,1621,1625,1629,1633,1637,1641,1645,1649,1653,1657,1661,1671,1675,1679,1683,1687,1692,1696,1728,1732,1736,1740,1744,1748,1752,1756,1760,1764,1768,1772,1776,1780,1784,1788,1792,1796,1800,1804,1808,1812,1817,1821,1825,1829,1833,1837,1841,1845,1849,1853,1857,1861,1865,1869,1873,1877,1881,1907,1911,1916,1920,1924,1928,1932,1936,1961,1966,1970,1974,1978,1982,1986,2023,2027,2031,2077,2081,2118,2122,2163,2167,2215,2219,2223,2227,2231,2235,2239,2243,2247,2251,2255,2259,2263,2267,2272,2276,2282,2286,2318,2322,2358,2362,2366,2370,2374,2378,2382,2388,2395,2402,2409,2416,2423,2430],{"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":1616},{"content":1600,"stretched":43,"withHeadings":14},[1601,1605,1609,1613],[1602,1603,1604],"Layer","Question","Example failure",[1606,1607,1608],"Authentication","Who is this principal?","Attacker impersonates Alice",[1610,1611,1612],"Authorization \u002F RBAC","May this principal perform this operation?","Viewer can delete users",[1592,1614,1615],"May this operation reach this tenant\u002Fresource boundary?","Tenant A admin reads Tenant B order",{},{"id":427,"data":1618,"type":218,"tunes":1620},{"text":1619},"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":1622,"type":42,"tunes":1624},{"text":1623,"level":247},"Roles need a scope",{},{"id":437,"data":1626,"type":218,"tunes":1628},{"text":1627},"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":1630,"type":218,"tunes":1632},{"text":1631},"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":1634,"type":218,"tunes":1636},{"text":1635},"A global role model that ignores this distinction can create privilege leakage even when the permission map itself is correct.",{},{"id":452,"data":1638,"type":42,"tunes":1640},{"text":1639,"level":247},"Tenant context must come from a trusted path",{},{"id":457,"data":1642,"type":218,"tunes":1644},{"text":1643},"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":1646,"type":218,"tunes":1648},{"text":1647},"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":1650,"type":218,"tunes":1652},{"text":1651},"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":1654,"type":42,"tunes":1656},{"text":1655,"level":247},"Tenant scope belongs in the resource lookup",{},{"id":477,"data":1658,"type":218,"tunes":1660},{"text":1659},"A common application-level isolation pattern is to include tenant scope in the same query that resolves the resource.",{},{"id":482,"data":1662,"type":391,"tunes":1670},{"content":1663,"stretched":43,"withHeadings":14},[1664,1667,1668,1669],[1665,1666],"Weak lookup","Stronger tenant-scoped lookup",[489,490],[492,493],[495,496],{},{"id":499,"data":1672,"type":218,"tunes":1674},{"text":1673},"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":1676,"type":42,"tunes":1678},{"text":1677,"level":247},"Application checks are useful, but isolation should not depend on perfect developer behavior",{},{"id":509,"data":1680,"type":218,"tunes":1682},{"text":1681},"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":1684,"type":218,"tunes":1686},{"text":1685},"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":1688,"type":226,"tunes":1691},{"body":1689,"title":1690,"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":1693,"type":42,"tunes":1695},{"text":1694,"level":247},"Database isolation strategies",{},{"id":531,"data":1697,"type":391,"tunes":1727},{"content":1698,"stretched":43,"withHeadings":14},[1699,1703,1707,1711,1715,1719,1723],[1700,1701,1702],"Strategy","Boundary","Strength \u002F trade-off",[1704,1705,1706],"Shared tables + tenant key","Row\u002Fapplication policy","Operationally efficient; requires exhaustive tenant scoping and strong tests",[1708,1709,1710],"Shared tables + database RLS","Database policy boundary","Reduces dependence on every application query; requires correct roles, session\u002Ftransaction tenant context and policy coverage",[1712,1713,1714],"Separate schemas","Namespace \u002F DB-role boundary","Stronger logical separation; more operational complexity",[1716,1717,1718],"Separate databases","Database \u002F credential boundary","Strong isolation and simpler blast-radius story; higher provisioning and operations cost",[1720,1721,1722],"Separate infrastructure\u002Faccount","Infrastructure boundary","Strongest coarse-grained separation; highest cost and operational overhead",[1724,1725,1726],"Hybrid","Per workload\u002Fdata class","Allows stronger isolation only where risk\u002Fcompliance justifies it",{},{"id":564,"data":1729,"type":218,"tunes":1731},{"text":1730},"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":1733,"type":42,"tunes":1735},{"text":1734,"level":247},"PostgreSQL Row-Level Security can provide defense in depth",{},{"id":574,"data":1737,"type":218,"tunes":1739},{"text":1738},"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":1741,"type":218,"tunes":1743},{"text":1742},"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":1745,"type":218,"tunes":1747},{"text":1746},"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":1749,"type":42,"tunes":1751},{"text":1750,"level":247},"Tenant isolation must include caches",{},{"id":594,"data":1753,"type":218,"tunes":1755},{"text":1754},"A database query can be perfectly scoped and still leak data through a shared cache key.",{},{"id":599,"data":1757,"type":218,"tunes":1759},{"text":1758},"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":1761,"type":218,"tunes":1763},{"text":1762},"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":1765,"type":42,"tunes":1767},{"text":1766,"level":247},"Files and object storage need their own tenant boundary",{},{"id":614,"data":1769,"type":218,"tunes":1771},{"text":1770},"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":1773,"type":218,"tunes":1775},{"text":1774},"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":1777,"type":218,"tunes":1779},{"text":1778},"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":1781,"type":42,"tunes":1783},{"text":1782,"level":247},"Background jobs and queues can break isolation",{},{"id":634,"data":1785,"type":218,"tunes":1787},{"text":1786},"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":1789,"type":218,"tunes":1791},{"text":1790},"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":1793,"type":218,"tunes":1795},{"text":1794},"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":1797,"type":42,"tunes":1799},{"text":1798,"level":247},"Search and RAG need tenant-aware retrieval",{},{"id":654,"data":1801,"type":218,"tunes":1803},{"text":1802},"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":1805,"type":218,"tunes":1807},{"text":1806},"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":1809,"type":218,"tunes":1811},{"text":1810},"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":1813,"type":226,"tunes":1816},{"body":1814,"title":1815,"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":1818,"type":42,"tunes":1820},{"text":1819,"level":247},"Derived data inherits tenant sensitivity",{},{"id":680,"data":1822,"type":218,"tunes":1824},{"text":1823},"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":1826,"type":218,"tunes":1828},{"text":1827},"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":1830,"type":42,"tunes":1832},{"text":1831,"level":247},"Not everything belongs to a tenant",{},{"id":695,"data":1834,"type":218,"tunes":1836},{"text":1835},"Multi-tenant platforms often have intentionally global resources: product taxonomies, public templates, system permissions, feature definitions or public content.",{},{"id":700,"data":1838,"type":218,"tunes":1840},{"text":1839},"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":1842,"type":218,"tunes":1844},{"text":1843},"An intentionally shared object should have a documented reason for being global rather than simply lacking a tenant association.",{},{"id":710,"data":1846,"type":42,"tunes":1848},{"text":1847,"level":247},"Platform administrators require a different authority model",{},{"id":715,"data":1850,"type":218,"tunes":1852},{"text":1851},"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":1854,"type":218,"tunes":1856},{"text":1855},"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":1858,"type":218,"tunes":1860},{"text":1859},"Cross-tenant access should therefore be a named capability, not the absence of a tenant filter.",{},{"id":730,"data":1862,"type":42,"tunes":1864},{"text":1863,"level":247},"RBAC can be combined with attributes",{},{"id":735,"data":1866,"type":218,"tunes":1868},{"text":1867},"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":1870,"type":218,"tunes":1872},{"text":1871},"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":1874,"type":218,"tunes":1876},{"text":1875},"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":1878,"type":42,"tunes":1880},{"text":1879,"level":247},"Authorization decisions are at least two-dimensional",{},{"id":755,"data":1882,"type":391,"tunes":1906},{"content":1883,"stretched":43,"withHeadings":14},[1884,1889,1892,1895,1897,1898,1902],[1885,1886,1887,1888],"Principal","Role permission","Tenant relationship","Decision",[764,765,1890,1891],"Order belongs to Alice's tenant","Allow",[764,765,1893,1894],"Order belongs to another tenant","Deny",[764,772,1890,1896],"Allow if role includes write",[764,772,1893,1894],[1899,777,1900,1901],"Platform support","Explicit support scope + audited target tenant","Potentially allow under platform policy",[1903,782,1904,1905],"Background worker","Trusted service scope for job tenant","Allow only for verified job tenant",{},{"id":787,"data":1908,"type":42,"tunes":1910},{"text":1909,"level":247},"Original implementation evidence: Aaasaasa AI CMS",{},{"id":792,"data":1912,"type":226,"tunes":1915},{"body":1913,"title":1914,"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":1917,"type":218,"tunes":1919},{"text":1918},"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":1921,"type":218,"tunes":1923},{"text":1922},"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":1925,"type":218,"tunes":1927},{"text":1926},"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":1929,"type":218,"tunes":1931},{"text":1930},"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":1933,"type":218,"tunes":1935},{"text":1934},"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":1937,"type":391,"tunes":1960},{"content":1938,"stretched":43,"withHeadings":14},[1939,1942,1945,1948,1951,1954,1957],[1940,1941],"Observed implementation pattern","Security meaning",[1943,1944],"Typed permission codes","RBAC operation vocabulary is explicit",[1946,1947],"System role → permission maps","Roles aggregate permissions rather than hard-coding users",[1949,1950],"tenantId_code role identity","Same logical role can exist separately per tenant",[1952,1953],"Role lookup uses id + tenantId","Role mutation is tenant-scoped",[1955,1956],"User-role relation stores tenantId","Membership is not globally inferred from role alone",[1958,1959],"Permission resolution uses tenantId + userId","Authorization is evaluated inside tenant context",{},{"id":849,"data":1962,"type":226,"tunes":1965},{"body":1963,"title":1964,"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":1967,"type":42,"tunes":1969},{"text":1968,"level":247},"Why this distinction matters even more for AI agents",{},{"id":860,"data":1971,"type":218,"tunes":1973},{"text":1972},"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":1975,"type":218,"tunes":1977},{"text":1976},"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":1979,"type":218,"tunes":1981},{"text":1980},"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":1983,"type":42,"tunes":1985},{"text":1984,"level":247},"Test RBAC and tenant isolation separately",{},{"id":880,"data":1987,"type":391,"tunes":2022},{"content":1988,"stretched":43,"withHeadings":14},[1989,1992,1995,1998,2001,2004,2007,2010,2013,2016,2019],[1990,1991],"Test family","What it should prove",[1993,1994],"Role demotion test","A user without a permission cannot perform the operation even inside their own tenant",[1996,1997],"Cross-tenant object test","A user with the correct role still cannot access the same resource type in another tenant",[1999,2000],"Identifier tampering","Changing object\u002Ftenant IDs does not cross scope",[2002,2003],"List\u002Fbulk endpoint test","Broad queries return only authorized tenant data",[2005,2006],"Cache reuse test","Two tenants using reused processes\u002Fconnections never receive each other's cached state",[2008,2009],"RLS request-role test","Production request role cannot bypass row policies",[2011,2012],"Async worker test","Tenant context survives queueing and is revalidated at consumption",[2014,2015],"Vector retrieval test","Tenant A query never retrieves Tenant B chunks",[2017,2018],"Platform-admin test","Cross-tenant capability is explicit, narrow and auditable",[2020,2021],"Offboarding test","Tenant data and derived indexes\u002Fcaches are removed according to policy",{},{"id":918,"data":2024,"type":218,"tunes":2026},{"text":2025},"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":2028,"type":42,"tunes":2030},{"text":2029,"level":247},"Common failure modes",{},{"id":928,"data":2032,"type":391,"tunes":2076},{"content":2033,"stretched":43,"withHeadings":14},[2034,2037,2040,2043,2046,2049,2052,2055,2058,2061,2064,2067,2070,2073],[2035,2036],"Failure mode","Why it fails",[2038,2039],"Check role but not tenant","Valid role becomes cross-tenant authority",[2041,2042],"Trust tenant ID from request","Client controls the isolation selector",[2044,2045],"Scope UI but not API","Hidden buttons do not protect backend resources",[2047,2048],"Tenant-aware detail endpoint, unscoped list endpoint","Bulk reads leak other tenants",[2050,2051],"Tenant filter in most queries","One forgotten path breaks the boundary",[2053,2054],"Global cache keys","Correct database isolation is bypassed by cached data",[2056,2057],"Shared vector index without enforced metadata filters","RAG retrieves another tenant's chunks",[2059,2060],"Queue message tenant ID treated as authorization","Forged or wrongly produced job can cross tenant boundary",[2062,2063],"Platform admin modeled as ordinary ADMIN","Cross-tenant power becomes implicit and difficult to audit",[2065,2066],"Role copied globally across tenant memberships","User receives permissions in tenants where they were never assigned",[2068,2069],"Separate databases but shared privileged credential","Application can still cross databases if its credential is too broad",[2071,2072],"RLS with BYPASSRLS request role","Database policy exists but does not protect the actual request path",[2074,2075],"Random UUIDs treated as isolation","Hard-to-guess identifiers reduce enumeration but do not authorize access",{},{"id":975,"data":2078,"type":42,"tunes":2080},{"text":2079,"level":247},"Common misconceptions",{},{"id":980,"data":2082,"type":391,"tunes":2117},{"content":2083,"stretched":43,"withHeadings":14},[2084,2087,2090,2093,2096,2099,2102,2105,2108,2111,2114],[2085,2086],"Misconception","Correction",[2088,2089],"“RBAC provides tenant isolation.”","RBAC controls permissions; isolation also requires tenant\u002Fresource scoping.",[2091,2092],"“If the user is an admin, tenant checks are unnecessary.”","Admin authority must still have an explicit scope.",[2094,2095],"“Tenant ID in JWT is enough.”","It can be a trusted input only if validated and applied consistently to every protected resource path.",[2097,2098],"“Separate databases remove authorization requirements.”","Users still need operation-level permissions inside their tenant.",[2100,2101],"“A tenant_id column means the system is isolated.”","The field only helps if access paths enforce it.",[2103,2104],"“UUIDs prevent cross-tenant access.”","Unpredictable identifiers are defense in depth, not authorization.",[2106,2107],"“RLS means application code needs no security checks.”","Application authorization, correct DB roles and policy coverage still matter.",[2109,2110],"“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.",[2112,2113],"“Platform support needs global ADMIN.”","Cross-tenant support should be a distinct, constrained and auditable authority.",[2115,2116],"“Internal services can skip tenant checks.”","Internal paths can still be compromised or misconfigured and must preserve tenant context.",{},{"id":1018,"data":2119,"type":42,"tunes":2121},{"text":2120,"level":247},"A practical design sequence",{},{"id":1023,"data":2123,"type":334,"tunes":2162},{"steps":2124,"title":2161,"orientation":333},[2125,2128,2131,2134,2137,2140,2143,2146,2149,2152,2155,2158],{"label":2126,"description":2127},"1. Define tenant ownership","Classify which entities and resources are global, tenant-scoped, user-scoped or intentionally cross-tenant.",{"label":2129,"description":2130},"2. Define operations","Create explicit permissions for reads, writes, publishing, approvals, administration and other business actions.",{"label":2132,"description":2133},"3. Define roles","Group permissions according to responsibilities without embedding accidental global scope.",{"label":2135,"description":2136},"4. Define membership scope","Bind role assignments to the tenant\u002Fworkspace\u002Fproject context in which they apply.",{"label":2138,"description":2139},"5. Resolve trusted tenant context","Derive tenant identity from authenticated, server-verified membership or service authorization.",{"label":2141,"description":2142},"6. Enforce resource ownership","Apply tenant scope at every tenant-owned data\u002Fservice boundary.",{"label":2144,"description":2145},"7. Add defense in depth","Use RLS, separate credentials, schemas\u002Fdatabases, storage policies or policy engines where risk justifies them.",{"label":2147,"description":2148},"8. Carry scope through derived systems","Preserve tenant metadata in cache, search, vector indexes, queues, files and analytics.",{"label":2150,"description":2151},"9. Model cross-tenant operations explicitly","Separate platform administration and service identities from ordinary tenant roles.",{"label":2153,"description":2154},"10. Test both axes","Run negative tests for missing permission and for wrong tenant independently.",{"label":2156,"description":2157},"11. Audit tenant + permission together","Log who acted, in which tenant, on what target and under which authority.",{"label":2159,"description":2160},"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":2164,"type":42,"tunes":2166},{"text":2165,"level":247},"RBAC + tenant isolation checklist",{},{"id":1070,"data":2168,"type":391,"tunes":2214},{"content":2169,"stretched":43,"withHeadings":14},[2170,2172,2175,2178,2181,2184,2187,2190,2193,2196,2199,2202,2205,2208,2211],[1603,2171],"Expected answer",[2173,2174],"Who is the principal?","Authenticated user\u002Fservice\u002Fagent identity",[2176,2177],"Which tenant context applies?","Server-verified membership or service scope",[2179,2180],"Which operation is requested?","Typed permission or policy action",[2182,2183],"Does the principal have that permission?","Role\u002Fpolicy decision",[2185,2186],"Who owns the target resource?","Explicit tenant\u002Fglobal\u002Fuser classification",[2188,2189],"Does resource scope match authority?","Tenant-aware lookup\u002Fpolicy",[2191,2192],"Can storage bypass application checks?","Defense-in-depth decision documented",[2194,2195],"Are caches tenant-safe?","Keys\u002Fnamespaces and authorization preserve tenant scope",[2197,2198],"Are files\u002Fblobs tenant-safe?","Object policy and signed URL issuance enforce scope",[2200,2201],"Are async jobs tenant-safe?","Verified context propagates and is revalidated",[2203,2204],"Is RAG\u002Fsearch tenant-safe?","Metadata\u002Fcollection isolation enforced before model context",[2206,2207],"Are cross-tenant admins explicit?","Separate authority, controls and audit",[2209,2210],"Can ordinary credentials bypass isolation?","No, or tightly documented exceptional path",[2212,2213],"Are negative cross-tenant tests automated?","Yes for every relevant access layer",{},{"id":1119,"data":2216,"type":42,"tunes":2218},{"text":2217,"level":247},"Edge cases and limitations",{},{"id":1124,"data":2220,"type":218,"tunes":2222},{"text":2221},"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":2224,"type":218,"tunes":2226},{"text":2225},"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":2228,"type":218,"tunes":2230},{"text":2229},"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":2232,"type":218,"tunes":2234},{"text":2233},"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":2236,"type":218,"tunes":2238},{"text":2237},"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":2240,"type":42,"tunes":2242},{"text":2241,"level":247},"What would change this answer?",{},{"id":1154,"data":2244,"type":218,"tunes":2246},{"text":2245},"The exact implementation changes with architecture: serverless APIs, Kubernetes, PostgreSQL, object storage, vector databases and policy engines expose different isolation primitives.",{},{"id":1159,"data":2248,"type":218,"tunes":2250},{"text":2249},"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":2252,"type":218,"tunes":2254},{"text":2253},"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":2256,"type":42,"tunes":2258},{"text":2257,"level":247},"Related canonical knowledge",{},{"id":1174,"data":2260,"type":218,"tunes":2262},{"text":2261},"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":2264,"type":218,"tunes":2266},{"text":2265},"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":2268,"type":1190,"tunes":2271},{"url":1186,"title":1187,"excerpt":2269,"ctaLabel":2270},"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":2273,"type":218,"tunes":2275},{"text":2274},"For RAG, tenant isolation must be enforced before protected chunks reach model context.",{},{"id":1198,"data":2277,"type":1190,"tunes":2281},{"url":2278,"title":1201,"excerpt":2279,"ctaLabel":2280},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-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":2283,"type":42,"tunes":2285},{"text":2284,"level":247},"Frequently asked questions",{},{"id":1211,"data":2287,"type":1211,"tunes":2317},{"items":2288,"title":2316},[2289,2292,2295,2298,2301,2304,2307,2310,2313],{"id":1215,"answer":2290,"question":2291},"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":2293,"question":2294},"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":2296,"question":2297},"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":2299,"question":2300},"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":2302,"question":2303},"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":2305,"question":2306},"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":2308,"question":2309},"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":2311,"question":2312},"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":2314,"question":2315},"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":2319,"type":42,"tunes":2321},{"text":2320,"level":247},"Glossary",{},{"id":1258,"data":2323,"type":1258,"tunes":2357},{"title":2324,"entries":2325},"Key multi-tenant security terms",[2326,2328,2330,2332,2334,2337,2340,2343,2345,2348,2351,2354],{"term":395,"anchor":394,"definition":2327},"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":2329},"A customer, organization, workspace or other isolated logical consumer of a shared multi-tenant system.",{"term":1592,"anchor":1269,"definition":2331},"Mechanisms that prevent one tenant from accessing, modifying or receiving another tenant's resources in a shared system.",{"term":1606,"anchor":1272,"definition":2333},"Verification of the identity of a user, service or other principal.",{"term":2335,"anchor":1276,"definition":2336},"Authorization","Decision process that determines whether a principal may perform a requested operation on a resource.",{"term":2338,"anchor":1280,"definition":2339},"Permission","A defined allowed operation or capability such as orders.read or users.write.",{"term":2341,"anchor":1284,"definition":2342},"Role","A named grouping of permissions associated with a responsibility or function.",{"term":1287,"anchor":1288,"definition":2344},"Attribute-Based Access Control: authorization based on attributes of the principal, resource, action or environment.",{"term":2346,"anchor":1292,"definition":2347},"Row-Level Security","Database policy mechanism that restricts which rows a database role or session may read or modify.",{"term":2349,"anchor":1296,"definition":2350},"Cross-tenant access","Any access path in which a principal operating under one tenant context reaches resources belonging to another tenant.",{"term":2352,"anchor":1300,"definition":2353},"Platform administrator","A privileged operational identity with explicitly modeled authority that may span multiple tenants.",{"term":2355,"anchor":1304,"definition":2356},"Tenant context","The verified tenant scope under which the current request, job or agent operation executes.",{},{"id":1308,"data":2359,"type":42,"tunes":2361},{"text":2360,"level":247},"Conclusion",{},{"id":1313,"data":2363,"type":218,"tunes":2365},{"text":2364},"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":2367,"type":218,"tunes":2369},{"text":2368},"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":2371,"type":218,"tunes":2373},{"text":2372},"The shortest reliable rule is: authorize the action, then isolate the scope — and never assume one proves the other.",{},{"id":1328,"data":2375,"type":42,"tunes":2377},{"text":2376,"level":247},"Primary sources and current guidance",{},{"id":1333,"data":2379,"type":218,"tunes":2381},{"text":2380},"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":2383,"type":1345,"tunes":2387},{"link":1340,"meta":2384},{"image":2385,"title":1343,"description":2386},{"url":369},"NIST overview of RBAC models and the INCITS RBAC standard, including users, roles, permissions, operations and objects.",{},{"id":1348,"data":2389,"type":1345,"tunes":2394},{"link":1350,"meta":2390},{"image":2391,"title":2392,"description":2393},{"url":369},"NIST CSRC — RBAC glossary","Current NIST glossary definitions of role-based access control as permission assignment through roles.",{},{"id":1357,"data":2396,"type":1345,"tunes":2401},{"link":1359,"meta":2397},{"image":2398,"title":2399,"description":2400},{"url":369},"AWS — The isolation mindset","AWS SaaS guidance explicitly distinguishing authentication\u002Fauthorization from tenant isolation and recommending shared isolation mechanisms.",{},{"id":1366,"data":2403,"type":1345,"tunes":2408},{"link":1368,"meta":2404},{"image":2405,"title":2406,"description":2407},{"url":369},"AWS — Multi-tenant authorization FAQ","Current guidance explaining the difference between authorization and tenant isolation in SaaS applications.",{},{"id":1375,"data":2410,"type":1345,"tunes":2415},{"link":1377,"meta":2411},{"image":2412,"title":2413,"description":2414},{"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":2417,"type":1345,"tunes":2422},{"link":1386,"meta":2418},{"image":2419,"title":2420,"description":2421},{"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":2424,"type":1345,"tunes":2429},{"link":1395,"meta":2425},{"image":2426,"title":2427,"description":2428},{"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":2431,"type":1345,"tunes":2436},{"link":1404,"meta":2432},{"image":2433,"title":2434,"description":2435},{"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":2440,"excerpt":1411},{"time":212,"blocks":2441,"version":1410},[2442,2445,2448,2451,2454,2457,2460,2463,2466,2469,2472,2475,2478,2481,2484,2487,2490,2493,2503,2506,2509,2512,2515,2518,2537,2540,2548,2551,2554,2557,2560,2563,2566,2569,2572,2575,2578,2581,2589,2592,2595,2598,2601,2604,2607,2618,2621,2624,2627,2630,2633,2636,2639,2642,2645,2648,2651,2654,2657,2660,2663,2666,2669,2672,2675,2678,2681,2684,2687,2690,2693,2696,2699,2702,2705,2708,2711,2714,2717,2720,2723,2726,2729,2732,2743,2746,2749,2752,2755,2758,2761,2764,2775,2778,2781,2784,2787,2790,2793,2808,2811,2814,2832,2835,2850,2853,2869,2872,2891,2894,2897,2900,2903,2906,2909,2912,2915,2918,2921,2924,2927,2930,2933,2936,2939,2942,2955,2958,2974,2977,2980,2983,2986,2989,2992,2997,3002,3007,3012,3017,3022,3027],{"id":215,"data":2443,"type":218,"tunes":2444},{"text":217},{},{"id":221,"data":2446,"type":226,"tunes":2447},{"body":223,"title":224,"variant":225},{},{"id":229,"data":2449,"type":226,"tunes":2450},{"body":231,"title":232,"variant":233},{},{"id":236,"data":2452,"type":226,"tunes":2453},{"body":238,"title":239,"variant":240},{},{"id":243,"data":2455,"type":248,"tunes":2456},{"title":245,"maxLevel":246,"minLevel":247},{},{"id":251,"data":2458,"type":42,"tunes":2459},{"text":253,"level":247},{},{"id":256,"data":2461,"type":218,"tunes":2462},{"text":258},{},{"id":261,"data":2464,"type":218,"tunes":2465},{"text":263},{},{"id":266,"data":2467,"type":218,"tunes":2468},{"text":268},{},{"id":271,"data":2470,"type":42,"tunes":2471},{"text":273,"level":247},{},{"id":276,"data":2473,"type":218,"tunes":2474},{"text":278},{},{"id":281,"data":2476,"type":218,"tunes":2477},{"text":283},{},{"id":286,"data":2479,"type":218,"tunes":2480},{"text":288},{},{"id":291,"data":2482,"type":42,"tunes":2483},{"text":293,"level":247},{},{"id":296,"data":2485,"type":218,"tunes":2486},{"text":298},{},{"id":301,"data":2488,"type":218,"tunes":2489},{"text":303},{},{"id":306,"data":2491,"type":218,"tunes":2492},{"text":308},{},{"id":311,"data":2494,"type":334,"tunes":2502},{"steps":2495,"title":332,"orientation":333},[2496,2497,2498,2499,2500,2501],{"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":2504,"type":42,"tunes":2505},{"text":339,"level":247},{},{"id":342,"data":2507,"type":218,"tunes":2508},{"text":344},{},{"id":347,"data":2510,"type":218,"tunes":2511},{"text":349},{},{"id":352,"data":2513,"type":218,"tunes":2514},{"text":354},{},{"id":357,"data":2516,"type":42,"tunes":2517},{"text":359,"level":247},{},{"id":362,"data":2519,"type":399,"tunes":2536},{"rows":2520,"title":390,"layout":391,"columns":2533},[2521,2523,2525,2527,2529,2531],{"id":366,"label":367,"values":2522},[369,369],{"id":371,"label":372,"values":2524},[369,369],{"id":375,"label":376,"values":2526},[369,369],{"id":379,"label":380,"values":2528},[369,369],{"id":383,"label":384,"values":2530},[369,369],{"id":387,"label":388,"values":2532},[369,369],[2534,2535],{"id":394,"label":395},{"id":397,"label":398},{},{"id":402,"data":2538,"type":42,"tunes":2539},{"text":404,"level":247},{},{"id":407,"data":2541,"type":391,"tunes":2547},{"content":2542,"stretched":43,"withHeadings":14},[2543,2544,2545,2546],[411,412,413],[415,416,417],[419,420,421],[398,423,424],{},{"id":427,"data":2549,"type":218,"tunes":2550},{"text":429},{},{"id":432,"data":2552,"type":42,"tunes":2553},{"text":434,"level":247},{},{"id":437,"data":2555,"type":218,"tunes":2556},{"text":439},{},{"id":442,"data":2558,"type":218,"tunes":2559},{"text":444},{},{"id":447,"data":2561,"type":218,"tunes":2562},{"text":449},{},{"id":452,"data":2564,"type":42,"tunes":2565},{"text":454,"level":247},{},{"id":457,"data":2567,"type":218,"tunes":2568},{"text":459},{},{"id":462,"data":2570,"type":218,"tunes":2571},{"text":464},{},{"id":467,"data":2573,"type":218,"tunes":2574},{"text":469},{},{"id":472,"data":2576,"type":42,"tunes":2577},{"text":474,"level":247},{},{"id":477,"data":2579,"type":218,"tunes":2580},{"text":479},{},{"id":482,"data":2582,"type":391,"tunes":2588},{"content":2583,"stretched":43,"withHeadings":14},[2584,2585,2586,2587],[486,487],[489,490],[492,493],[495,496],{},{"id":499,"data":2590,"type":218,"tunes":2591},{"text":501},{},{"id":504,"data":2593,"type":42,"tunes":2594},{"text":506,"level":247},{},{"id":509,"data":2596,"type":218,"tunes":2597},{"text":511},{},{"id":514,"data":2599,"type":218,"tunes":2600},{"text":516},{},{"id":519,"data":2602,"type":226,"tunes":2603},{"body":521,"title":522,"variant":523},{},{"id":526,"data":2605,"type":42,"tunes":2606},{"text":528,"level":247},{},{"id":531,"data":2608,"type":391,"tunes":2617},{"content":2609,"stretched":43,"withHeadings":14},[2610,2611,2612,2613,2614,2615,2616],[535,536,537],[539,540,541],[543,544,545],[547,548,549],[551,552,553],[555,556,557],[559,560,561],{},{"id":564,"data":2619,"type":218,"tunes":2620},{"text":566},{},{"id":569,"data":2622,"type":42,"tunes":2623},{"text":571,"level":247},{},{"id":574,"data":2625,"type":218,"tunes":2626},{"text":576},{},{"id":579,"data":2628,"type":218,"tunes":2629},{"text":581},{},{"id":584,"data":2631,"type":218,"tunes":2632},{"text":586},{},{"id":589,"data":2634,"type":42,"tunes":2635},{"text":591,"level":247},{},{"id":594,"data":2637,"type":218,"tunes":2638},{"text":596},{},{"id":599,"data":2640,"type":218,"tunes":2641},{"text":601},{},{"id":604,"data":2643,"type":218,"tunes":2644},{"text":606},{},{"id":609,"data":2646,"type":42,"tunes":2647},{"text":611,"level":247},{},{"id":614,"data":2649,"type":218,"tunes":2650},{"text":616},{},{"id":619,"data":2652,"type":218,"tunes":2653},{"text":621},{},{"id":624,"data":2655,"type":218,"tunes":2656},{"text":626},{},{"id":629,"data":2658,"type":42,"tunes":2659},{"text":631,"level":247},{},{"id":634,"data":2661,"type":218,"tunes":2662},{"text":636},{},{"id":639,"data":2664,"type":218,"tunes":2665},{"text":641},{},{"id":644,"data":2667,"type":218,"tunes":2668},{"text":646},{},{"id":649,"data":2670,"type":42,"tunes":2671},{"text":651,"level":247},{},{"id":654,"data":2673,"type":218,"tunes":2674},{"text":656},{},{"id":659,"data":2676,"type":218,"tunes":2677},{"text":661},{},{"id":664,"data":2679,"type":218,"tunes":2680},{"text":666},{},{"id":669,"data":2682,"type":226,"tunes":2683},{"body":671,"title":672,"variant":233},{},{"id":675,"data":2685,"type":42,"tunes":2686},{"text":677,"level":247},{},{"id":680,"data":2688,"type":218,"tunes":2689},{"text":682},{},{"id":685,"data":2691,"type":218,"tunes":2692},{"text":687},{},{"id":690,"data":2694,"type":42,"tunes":2695},{"text":692,"level":247},{},{"id":695,"data":2697,"type":218,"tunes":2698},{"text":697},{},{"id":700,"data":2700,"type":218,"tunes":2701},{"text":702},{},{"id":705,"data":2703,"type":218,"tunes":2704},{"text":707},{},{"id":710,"data":2706,"type":42,"tunes":2707},{"text":712,"level":247},{},{"id":715,"data":2709,"type":218,"tunes":2710},{"text":717},{},{"id":720,"data":2712,"type":218,"tunes":2713},{"text":722},{},{"id":725,"data":2715,"type":218,"tunes":2716},{"text":727},{},{"id":730,"data":2718,"type":42,"tunes":2719},{"text":732,"level":247},{},{"id":735,"data":2721,"type":218,"tunes":2722},{"text":737},{},{"id":740,"data":2724,"type":218,"tunes":2725},{"text":742},{},{"id":745,"data":2727,"type":218,"tunes":2728},{"text":747},{},{"id":750,"data":2730,"type":42,"tunes":2731},{"text":752,"level":247},{},{"id":755,"data":2733,"type":391,"tunes":2742},{"content":2734,"stretched":43,"withHeadings":14},[2735,2736,2737,2738,2739,2740,2741],[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":2744,"type":42,"tunes":2745},{"text":789,"level":247},{},{"id":792,"data":2747,"type":226,"tunes":2748},{"body":794,"title":795,"variant":240},{},{"id":798,"data":2750,"type":218,"tunes":2751},{"text":800},{},{"id":803,"data":2753,"type":218,"tunes":2754},{"text":805},{},{"id":808,"data":2756,"type":218,"tunes":2757},{"text":810},{},{"id":813,"data":2759,"type":218,"tunes":2760},{"text":815},{},{"id":818,"data":2762,"type":218,"tunes":2763},{"text":820},{},{"id":823,"data":2765,"type":391,"tunes":2774},{"content":2766,"stretched":43,"withHeadings":14},[2767,2768,2769,2770,2771,2772,2773],[827,828],[830,831],[833,834],[836,837],[839,840],[842,843],[845,846],{},{"id":849,"data":2776,"type":226,"tunes":2777},{"body":851,"title":852,"variant":233},{},{"id":855,"data":2779,"type":42,"tunes":2780},{"text":857,"level":247},{},{"id":860,"data":2782,"type":218,"tunes":2783},{"text":862},{},{"id":865,"data":2785,"type":218,"tunes":2786},{"text":867},{},{"id":870,"data":2788,"type":218,"tunes":2789},{"text":872},{},{"id":875,"data":2791,"type":42,"tunes":2792},{"text":877,"level":247},{},{"id":880,"data":2794,"type":391,"tunes":2807},{"content":2795,"stretched":43,"withHeadings":14},[2796,2797,2798,2799,2800,2801,2802,2803,2804,2805,2806],[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":2809,"type":218,"tunes":2810},{"text":920},{},{"id":923,"data":2812,"type":42,"tunes":2813},{"text":925,"level":247},{},{"id":928,"data":2815,"type":391,"tunes":2831},{"content":2816,"stretched":43,"withHeadings":14},[2817,2818,2819,2820,2821,2822,2823,2824,2825,2826,2827,2828,2829,2830],[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":2833,"type":42,"tunes":2834},{"text":977,"level":247},{},{"id":980,"data":2836,"type":391,"tunes":2849},{"content":2837,"stretched":43,"withHeadings":14},[2838,2839,2840,2841,2842,2843,2844,2845,2846,2847,2848],[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":2851,"type":42,"tunes":2852},{"text":1020,"level":247},{},{"id":1023,"data":2854,"type":334,"tunes":2868},{"steps":2855,"title":1062,"orientation":333},[2856,2857,2858,2859,2860,2861,2862,2863,2864,2865,2866,2867],{"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":2870,"type":42,"tunes":2871},{"text":1067,"level":247},{},{"id":1070,"data":2873,"type":391,"tunes":2890},{"content":2874,"stretched":43,"withHeadings":14},[2875,2876,2877,2878,2879,2880,2881,2882,2883,2884,2885,2886,2887,2888,2889],[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":2892,"type":42,"tunes":2893},{"text":1121,"level":247},{},{"id":1124,"data":2895,"type":218,"tunes":2896},{"text":1126},{},{"id":1129,"data":2898,"type":218,"tunes":2899},{"text":1131},{},{"id":1134,"data":2901,"type":218,"tunes":2902},{"text":1136},{},{"id":1139,"data":2904,"type":218,"tunes":2905},{"text":1141},{},{"id":1144,"data":2907,"type":218,"tunes":2908},{"text":1146},{},{"id":1149,"data":2910,"type":42,"tunes":2911},{"text":1151,"level":247},{},{"id":1154,"data":2913,"type":218,"tunes":2914},{"text":1156},{},{"id":1159,"data":2916,"type":218,"tunes":2917},{"text":1161},{},{"id":1164,"data":2919,"type":218,"tunes":2920},{"text":1166},{},{"id":1169,"data":2922,"type":42,"tunes":2923},{"text":1171,"level":247},{},{"id":1174,"data":2925,"type":218,"tunes":2926},{"text":1176},{},{"id":1179,"data":2928,"type":218,"tunes":2929},{"text":1181},{},{"id":1184,"data":2931,"type":1190,"tunes":2932},{"url":1186,"title":1187,"excerpt":1188,"ctaLabel":1189},{},{"id":1193,"data":2934,"type":218,"tunes":2935},{"text":1195},{},{"id":1198,"data":2937,"type":1190,"tunes":2938},{"url":1200,"title":1201,"excerpt":1202,"ctaLabel":1203},{},{"id":1206,"data":2940,"type":42,"tunes":2941},{"text":1208,"level":247},{},{"id":1211,"data":2943,"type":1211,"tunes":2954},{"items":2944,"title":1250},[2945,2946,2947,2948,2949,2950,2951,2952,2953],{"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":2956,"type":42,"tunes":2957},{"text":1255,"level":247},{},{"id":1258,"data":2959,"type":1258,"tunes":2973},{"title":1260,"entries":2960},[2961,2962,2963,2964,2965,2966,2967,2968,2969,2970,2971,2972],{"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":2975,"type":42,"tunes":2976},{"text":1310,"level":247},{},{"id":1313,"data":2978,"type":218,"tunes":2979},{"text":1315},{},{"id":1318,"data":2981,"type":218,"tunes":2982},{"text":1320},{},{"id":1323,"data":2984,"type":218,"tunes":2985},{"text":1325},{},{"id":1328,"data":2987,"type":42,"tunes":2988},{"text":1330,"level":247},{},{"id":1333,"data":2990,"type":218,"tunes":2991},{"text":1335},{},{"id":1338,"data":2993,"type":1345,"tunes":2996},{"link":1340,"meta":2994},{"image":2995,"title":1343,"description":1344},{"url":369},{},{"id":1348,"data":2998,"type":1345,"tunes":3001},{"link":1350,"meta":2999},{"image":3000,"title":1353,"description":1354},{"url":369},{},{"id":1357,"data":3003,"type":1345,"tunes":3006},{"link":1359,"meta":3004},{"image":3005,"title":1362,"description":1363},{"url":369},{},{"id":1366,"data":3008,"type":1345,"tunes":3011},{"link":1368,"meta":3009},{"image":3010,"title":1371,"description":1372},{"url":369},{},{"id":1375,"data":3013,"type":1345,"tunes":3016},{"link":1377,"meta":3014},{"image":3015,"title":1380,"description":1381},{"url":369},{},{"id":1384,"data":3018,"type":1345,"tunes":3021},{"link":1386,"meta":3019},{"image":3020,"title":1389,"description":1390},{"url":369},{},{"id":1393,"data":3023,"type":1345,"tunes":3026},{"link":1395,"meta":3024},{"image":3025,"title":1398,"description":1399},{"url":369},{},{"id":1402,"data":3028,"type":1345,"tunes":3031},{"link":1404,"meta":3029},{"image":3030,"title":1407,"description":1408},{"url":369},{},"Post erfolgreich abgerufen",{"items":3034,"source":3119,"manualIds":3120,"manualMatchedIds":3121},[3035,3042,3049,3056,3063,3070,3077,3084,3091,3098,3105,3112],{"id":3036,"slug":3037,"title":3038,"excerpt":3039,"featuredImage":3040,"publishedAt":3041},"484","what-is-an-ai-platform-architect-models-data-runtime-security-and-operations","Che cos'è un architetto di piattaforme AI? Modelli, dati, runtime, sicurezza e operazioni","Un Architetto di Piattaforme AI progetta fondamenta AI riutilizzabili attraverso modelli, fornitori, recupero, agenti, identità, sicurezza, valutazione, osservabilità e operazioni.","\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":3043,"slug":3044,"title":3045,"excerpt":3046,"featuredImage":3047,"publishedAt":3048},"486","source-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from","Fonte di verità nei sistemi di IA: da dove proviene realmente la conoscenza affidabile","Una Fonte di Verità definisce quale fonte è autorevole per un fatto o uno stato specifico. Scopri come si differenzia da RAG, provenienza, memoria, contesto, database vettoriali e sistemi di registrazione.","\u002Fuploads\u002F2026\u002F10\u002Fsource-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from-1791479103235-6bq9em.webp","2026-10-08T13:02:00.000Z",{"id":3050,"slug":3051,"title":3052,"excerpt":3053,"featuredImage":3054,"publishedAt":3055},"363","front-und-backend-entwicklung","Sviluppo Front-end e Backend","Lo sviluppo front-end e back-end è una parte essenziale dello sviluppo web e comporta la creazione di applicazioni web e siti web. Lo sviluppo front-end si concentra sull'interfaccia utente, mentre lo sviluppo back-end è responsabile della programmazione e della gestione del lato server.","\u002Fuploads\u002F2026\u002F03\u002Ffront-und-backend-entwicklung-1774872219531-wyu4i1.webp","2023-04-12T11:11:00.000Z",{"id":3057,"slug":3058,"title":3059,"excerpt":3060,"featuredImage":3061,"publishedAt":3062},"485","enterprise-ai-architecture-what-changes-when-ai-enters-a-company","Architettura AI aziendale: cosa cambia quando l'AI entra in un'azienda","L'architettura AI aziendale spiega come l'AI cambia i sistemi aziendali attraverso autorità sui dati, identità, permessi, fornitori, rischio, governance, valutazione, conformità e operazioni.","\u002Fuploads\u002F2026\u002F10\u002Fenterprise-ai-architecture-what-changes-when-ai-enters-a-company-1791478161363-czrwaq.webp","2026-10-08T10:48:00.000Z",{"id":3064,"slug":3065,"title":3066,"excerpt":3067,"featuredImage":3068,"publishedAt":3069},"471","how-to-know-whether-an-ai-agent-actually-used-the-right-evidence","Come sapere se un agente IA ha effettivamente usato le prove giuste","Un agente IA può citare fonti e comunque utilizzare le prove sbagliate. Questo articolo introduce un metodo pratico per verificare il supporto delle affermazioni, l'autorevolezza della fonte, l'applicabilità, la provenienza e se le prove abbiano effettivamente influenzato la risposta.","\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":3071,"slug":3072,"title":3073,"excerpt":3074,"featuredImage":3075,"publishedAt":3076},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","Il confine della validità della risposta: il livello mancante tra rilevanza e risposte AI affidabili","Una fonte può essere pertinente, autorevole e comunque errata per la domanda posta. Il livello mancante è l'applicabilità: le condizioni alle quali una risposta è valida e i cambiamenti che ne impongono una riconsiderazione. Questo articolo introduce l'Answer Validity Boundary come modello di progettazione delle fonti per esseri umani, ricerca AI e sistemi RAG.","\u002Fuploads\u002F2026\u002F09\u002Fthe-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers-1790272901306-1g5jly.webp","2026-09-24T11:59:00.000Z",{"id":3078,"slug":3079,"title":3080,"excerpt":3081,"featuredImage":3082,"publishedAt":3083},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","L'IA generativa spiegata: modelli, recupero, strumenti e applicazioni non sono la stessa cosa","L'IA generativa è più di un modello. Scopri come modelli, recupero, strumenti, contesto, runtime e applicazioni si integrano nei sistemi di IA in produzione.","\u002Fuploads\u002F2026\u002F10\u002Fgenerative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing-1791475411822-pp0dvz.webp","2026-10-08T12:00:00.000Z",{"id":3085,"slug":3086,"title":3087,"excerpt":3088,"featuredImage":3089,"publishedAt":3090},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Padroneggiare il Flusso di Lavoro SEO: Strategie di Ottimizzazione Essenziali per la Crescita Organica","Un flusso di lavoro SEO strutturato è fondamentale per una crescita organica sostenibile. Scopri le dieci strategie fondamentali, dalla ricerca di parole chiave e dall'ottimizzazione tecnica alla qualità dei contenuti e all'analisi delle prestazioni.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":3092,"slug":3093,"title":3094,"excerpt":3095,"featuredImage":3096,"publishedAt":3097},"478","what-is-rag-the-simplest-explanation-of-how-it-works","Cos'è il RAG? La spiegazione più semplice di come funziona","RAG sembra complicato, ma l'idea è semplice: prima che un'IA risponda, cerca prima informazioni utili da una fonte di conoscenza e fornisce tali informazioni al modello linguistico. Questa guida spiega RAG, LLM, stato, memoria e strumenti utilizzando un semplice modello mentale.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z",{"id":3099,"slug":3100,"title":3101,"excerpt":3102,"featuredImage":3103,"publishedAt":3104},"487","vector-databases-embeddings-and-reranking-three-different-parts-of-retrieval","Database vettoriali, embedding e reranking: tre parti diverse del recupero","Gli embedding rappresentano il significato, i database vettoriali recuperano i candidati e i reranker affinano i risultati. Scopri come questi tre livelli di recupero si differenziano e collaborano nel RAG.","\u002Fuploads\u002F2026\u002F10\u002Fvector-databases-embeddings-and-reranking-three-different-parts-of-retrieval-1791480129884-9dtasz.webp","2026-10-08T11:21:00.000Z",{"id":3106,"slug":3107,"title":3108,"excerpt":3109,"featuredImage":3110,"publishedAt":3111},"480","when-should-an-ai-stop-trusting-its-own-knowledge-the-retrieval-trigger","Quando dovrebbe un'IA smettere di fidarsi della propria conoscenza? — Il grilletto del recupero","Un modello di IA non necessita del recupero per ogni domanda. Il problema importante è sapere quando la sua conoscenza interna non è più sufficiente. Il Trigger di Recupero è un confine decisionale pratico che determina quando un sistema di IA dovrebbe smettere di affidarsi esclusivamente alla conoscenza del modello e ottenere prove esterne prima di rispondere.","\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":3113,"slug":3114,"title":3115,"excerpt":3116,"featuredImage":3117,"publishedAt":3118},"494","air-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access","AI Air-Gapped: Come funzionano i sistemi di IA senza Internet o accesso al cloud","L'IA air-gapped esegue modelli, RAG e applicazioni di IA all'interno di un dominio di sicurezza isolato senza dipendenze da internet o dal cloud. Scopri come modelli, dati, aggiornamenti e strumenti operano offline.","\u002Fuploads\u002F2026\u002F10\u002Fair-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access-1791487983978-e6xqf0.webp","2026-10-08T11:32:00.000Z","fallback",[],[]]