[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"portal-settings:stajic:ru":3,"public-menus:all":38,"post:rbac-vs-tenant-isolation-two-different-security-boundaries:ru":205,"related:post:rbac-vs-tenant-isolation-two-different-security-boundaries:ru:1":3030},{"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","ru","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":3029},{"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 против изоляции арендаторов: две разные границы безопасности","rbac-vs-tenant-isolation-two-different-security-boundaries","\u003Cp>RBAC и изоляция тенантов решают две разные задачи безопасности в мультитенантных системах. Управление доступом на основе ролей (RBAC) определяет, что разрешено делать аутентифицированному субъекту, например читать заказы, редактировать товары или управлять пользователями. Изоляция тенантов определяет, к данным, ресурсам и контексту выполнения какого тенанта этот субъект имеет доступ. Пользователь может быть корректно аутентифицирован и корректно наделён ролью RBAC, но при этом всё равно столкнуться с нарушением безопасности, если приложение позволяет этой роли работать с ресурсами другого тенанта.\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\">Прямой ответ\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">\u003Cstrong>RBAC отвечает на вопрос «что может делать эта учётная запись?» Изоляция тенантов отвечает на вопрос «внутри чьей границы она может это делать?»\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Безопасное мультитенантное приложение обычно нуждается в обоих механизмах. Администратор тенанта может обладать широкими правами, но эти права должны оставаться ограниченными рамками тенанта администратора, если только не существует явно отдельного полномочия уровня платформы.\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\">Роль — это не граница тенанта\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Назначение пользователю роли \u003Ccode>ADMIN\u003C\u002Fcode> не означает автоматически «администратор только тенанта A». Роль должна оцениваться вместе с проверенным контекстом тенанта и принадлежностью целевого ресурса к тенанту. В противном случае действительная роль может превратиться в межтенантную привилегию.\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\">Примечание об актуальных источниках — 8 октября 2026 г.\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Само различие остаётся стабильным. NIST определяет RBAC через пользователей, роли, разрешения, операции и объекты. Актуальные рекомендации AWS по SaaS прямо указывают, что аутентификация и авторизация не равны изоляции тенантов и что пользователь может быть аутентифицирован и авторизован, но при этом всё равно получить доступ к ресурсам другого тенанта, если изоляция не обеспечивается отдельно. Актуальные рекомендации OWASP по мультитенантной безопасности также рассматривают изоляцию тенантов как требование на всех уровнях, охватывающее API, базы данных, кэши, хранилища, очереди и другие общие ресурсы.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cnav class=\"editorjs-toc\" data-editorjs-toc=\"true\" aria-label=\"Содержание\">\u003Cstrong class=\"editorjs-toc__title\">Содержание\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\">Что на самом деле контролирует RBAC\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-10\" class=\"editorjs-toc__link\">Что на самом деле контролирует изоляция тенантов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-14\" class=\"editorjs-toc__link\">Простейший пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-19\" class=\"editorjs-toc__link\">Где останавливается простой пример\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-23\" class=\"editorjs-toc__link\">RBAC против изоляции арендаторов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-25\" class=\"editorjs-toc__link\">Аутентификация, авторизация и изоляция — это три разные проверки\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-28\" class=\"editorjs-toc__link\">Ролям нужна область действия\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-32\" class=\"editorjs-toc__link\">Контекст арендатора должен поступать из доверенного источника\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-36\" class=\"editorjs-toc__link\">Область арендатора должна быть в поиске ресурса\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-40\" class=\"editorjs-toc__link\">Проверки на уровне приложения полезны, но изоляция не должна зависеть от идеального поведения разработчика\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-44\" class=\"editorjs-toc__link\">Стратегии изоляции баз данных\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-47\" class=\"editorjs-toc__link\">Безопасность на уровне строк PostgreSQL может обеспечить эшелонированную защиту\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-51\" class=\"editorjs-toc__link\">Изоляция арендаторов должна включать кэши\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-55\" class=\"editorjs-toc__link\">Файлы и объектное хранилище нуждаются в собственной границе арендатора\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-59\" class=\"editorjs-toc__link\">Фоновые задачи и очереди могут нарушить изоляцию\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-63\" class=\"editorjs-toc__link\">Поиск и RAG нуждаются в извлечении с учётом арендатора\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-68\" class=\"editorjs-toc__link\">Производные данные наследуют чувствительность арендатора\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-71\" class=\"editorjs-toc__link\">Не всё принадлежит арендатору\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-75\" class=\"editorjs-toc__link\">Администраторы платформы требуют иной модели полномочий\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-79\" class=\"editorjs-toc__link\">RBAC можно комбинировать с атрибутами\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-83\" class=\"editorjs-toc__link\">Решения об авторизации как минимум двумерны\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-85\" class=\"editorjs-toc__link\">Свидетельство оригинальной реализации: Aaasaasa AI CMS\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-94\" class=\"editorjs-toc__link\">Почему это различие еще важнее для ИИ-агентов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-98\" class=\"editorjs-toc__link\">Тестируйте RBAC и изоляцию тенантов отдельно\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-101\" class=\"editorjs-toc__link\">Распространенные режимы отказа\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-103\" class=\"editorjs-toc__link\">Распространенные заблуждения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-105\" class=\"editorjs-toc__link\">Практическая последовательность проектирования\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-107\" class=\"editorjs-toc__link\">Контрольный список RBAC + изоляция тенантов\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-109\" class=\"editorjs-toc__link\">Граничные случаи и ограничения\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-115\" class=\"editorjs-toc__link\">Что могло бы изменить этот ответ?\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-119\" class=\"editorjs-toc__link\">Связанные канонические знания\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-125\" class=\"editorjs-toc__link\">Часто задаваемые вопросы\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-127\" class=\"editorjs-toc__link\">Глоссарий\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-129\" class=\"editorjs-toc__link\">Заключение\u003C\u002Fa>\u003C\u002Fli>\u003Cli class=\"editorjs-toc__item\">\u003Ca href=\"#section-133\" class=\"editorjs-toc__link\">Первоисточники и актуальные рекомендации\u003C\u002Fa>\u003C\u002Fli>\u003C\u002Fol>\u003C\u002Fnav>\n\u003Ch2 id=\"section-6\">Что на самом деле контролирует RBAC\u003C\u002Fh2>\n\u003Cp>RBAC — это модель авторизации, в которой разрешения связаны с ролями, а пользователи назначаются на эти роли. Роль выступает административной абстракцией между учётными записями и разрешениями.\u003C\u002Fp>\n\u003Cp>Классическая работа NIST по RBAC формализует это через пользователей, роли, разрешения, операции и объекты. Практическая выгода в том, что организация может управлять авторизацией через относительно стабильные должностные или функциональные роли, а не привязывать каждое разрешение напрямую к каждому пользователю.\u003C\u002Fp>\n\u003Cp>Роль, например EDITOR, может означать: может читать контент, писать контент и публиковать контент. Роль, например ACCOUNTANT, может означать: может читать данные биллинга, сверять счета и утверждать расчёты.\u003C\u002Fp>\n\u003Ch2 id=\"section-10\">Что на самом деле контролирует изоляция тенантов\u003C\u002Fh2>\n\u003Cp>Изоляция тенантов — это набор механизмов, которые не позволяют одному тенанту читать, изменять, влиять или случайно получать ресурсы другого тенанта в общей системе.\u003C\u002Fp>\n\u003Cp>Защищаемая граница шире, чем строки в базе данных. Состояние, относящееся к тенанту, может существовать в реляционных таблицах, объектных хранилищах, векторных индексах, кэшах, поисковых индексах, сообщениях очередей, файлах, временных артефактах, фоновых задачах, аналитике, ограничениях скорости и инфраструктурных ресурсах.\u003C\u002Fp>\n\u003Cp>Рекомендации AWS по SaaS делают это различие явным: авторизация предоставляет доступ к ресурсам, а изоляция тенантов гарантирует, что эти ресурсы не пересекут границу не того тенанта, даже когда инфраструктура является общей.\u003C\u002Fp>\n\u003Ch2 id=\"section-14\">Простейший пример\u003C\u002Fh2>\n\u003Cp>Предположим, Алиса — администратор тенанта A, а Боб — администратор тенанта B. Оба пользователя правомерно обладают одной и той же ролью ADMIN.\u003C\u002Fp>\n\u003Cp>RBAC может корректно заключить, что оба пользователя могут выполнить операцию, например users.read. Но когда Алиса запрашивает пользователя с ID 847, приложение всё равно должно проверить, что пользователь 847 принадлежит тенанту A.\u003C\u002Fp>\n\u003Cp>Если API проверяет только «у Алисы есть ADMIN» и затем выполняет SELECT * FROM users WHERE id = 847, RBAC сработал, а изоляция тенантов — нет.\u003C\u002Fp>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Корректное решение об авторизации в мультитенантной среде\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. Аутентифицировать субъект\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Установить, кто является пользователем, сервисом или агентом.\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. Определить проверенный контекст тенанта\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Определить, какой контекст тенанта применяется, на основе доверенной серверной информации об идентичности и членстве.\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. Определить разрешение\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Оценить, разрешает ли роль или политика субъекта запрошенную операцию.\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. Ограничить целевой ресурс рамками\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Проверить, что целевой объект принадлежит разрешённому тенанту или явно общему пространству.\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. Обеспечить соблюдение на границе доступа\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Выполнить операцию с базой данных, кэшем, хранилищем, очередью или сервисом с применением ограничений тенанта.\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. Аудит обоих измерений\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Записывать субъект, тенант, операцию, цель и результат, чтобы межтенантные попытки были видны.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-19\">Где останавливается простой пример\u003C\u002Fh2>\n\u003Cp>Реальные системы часто содержат несколько классов идентичностей: пользователи арендаторов, администраторы платформы, фоновые обработчики, интеграции, агенты и кросс-арендаторские операционные сервисы. Некоторые из них законно пересекают границы арендаторов.\u003C\u002Fp>\n\u003Cp>Это не устраняет необходимость изоляции. Это означает, что кросс-арендаторские полномочия должны быть явными, узкими и отдельно проверяемыми, а не возникать случайно из глобальной роли или неограниченного подключения к базе данных.\u003C\u002Fp>\n\u003Cp>Изоляция арендаторов также может различаться по уровням. Продукт может совместно использовать серверы приложений, разделяя базы данных, или использовать общую базу данных с политиками на уровне строк, предоставляя премиум-арендаторам изолированное хранилище или вычислительные ресурсы. Не существует единой универсальной топологии изоляции.\u003C\u002Fp>\n\u003Ch2 id=\"section-23\">RBAC против изоляции арендаторов\u003C\u002Fh2>\n\u003Csection class=\"editorjs-comparison my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Два разных измерения безопасности\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\">Изоляция арендаторов\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\">Основной вопрос\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\">Типичная единица\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\">Пример\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\">Типичный сбой\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\">Типичная реализация\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\">Может ли существовать отдельно?\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\">Аутентификация, авторизация и изоляция — это три разные проверки\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\">Уровень\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Вопрос\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Пример сбоя\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Аутентификация\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто этот субъект?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Злоумышленник выдает себя за Алису\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Авторизация \u002F RBAC\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Может ли этот субъект выполнить эту операцию?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Наблюдатель может удалять пользователей\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изоляция арендаторов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Может ли эта операция достичь границы этого арендатора\u002Fресурса?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Администратор арендатора A читает заказ арендатора B\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Эти проверки связаны, но не взаимозаменяемы. Аутентификация может быть идеальной, а авторизация — нет. Авторизация может быть корректной, а изоляция арендаторов — нет. Безопасный путь запроса в SaaS требует всех применимых границ.\u003C\u002Fp>\n\u003Ch2 id=\"section-28\">Ролям нужна область действия\u003C\u002Fh2>\n\u003Cp>Слово ADMIN неполно без области действия. Оно может означать администратора платформы, администратора арендатора, администратора проекта, администратора рабочего пространства или администратора одной подсистемы.\u003C\u002Fp>\n\u003Cp>В мультитенантных системах назначение роли обычно должно быть связано с членством в арендаторе или другой явной областью ресурса. Один и тот же пользователь может законно быть ADMIN в арендаторе A и VIEWER в арендаторе B.\u003C\u002Fp>\n\u003Cp>Глобальная модель ролей, игнорирующая это различие, может создавать утечку привилегий, даже когда сама карта разрешений корректна.\u003C\u002Fp>\n\u003Ch2 id=\"section-32\">Контекст арендатора должен поступать из доверенного источника\u003C\u002Fh2>\n\u003Cp>Идентификатор арендатора, предоставленный клиентом, полезен как селектор, но не является доказательством полномочий. Сервер должен выводить или проверять членство в арендаторе на основе аутентифицированной идентичности и текущих данных авторизации.\u003C\u002Fp>\n\u003Cp>Текущие рекомендации OWASP по мультитенантности советуют устанавливать контекст арендатора на раннем этапе жизненного цикла запроса и явно предупреждают против рассмотрения клиентских заголовков или параметров запроса как доказательства авторизации.\u003C\u002Fp>\n\u003Cp>Это важно, потому что тривиальное изменение запроса с tenant=A на tenant=B не должно быть достаточным для пересечения границы изоляции.\u003C\u002Fp>\n\u003Ch2 id=\"section-36\">Область арендатора должна быть в поиске ресурса\u003C\u002Fh2>\n\u003Cp>Распространённый паттерн изоляции на уровне приложения — включать область арендатора в тот же запрос, который разрешает ресурс.\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\">Слабый поиск\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Более строгий поиск с областью арендатора\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>Этот паттерн не является единственным возможным механизмом изоляции, но он удерживает принадлежность арендатору рядом с операцией доступа к данным и предотвращает превращение идентификатора объекта в межарендаторскую возможность.\u003C\u002Fp>\n\u003Ch2 id=\"section-40\">Проверки на уровне приложения полезны, но изоляция не должна зависеть от идеального поведения разработчика\u003C\u002Fh2>\n\u003Cp>Руководство AWS по изоляции явно предостерегает от того, чтобы оставлять обеспечение изоляции только на разработчиков сервисов. В большой кодовой базе в конце концов один запрос, ключ кэша или путь воркера может пропустить область арендатора.\u003C\u002Fp>\n\u003Cp>Поэтому эшелонированная защита может перенести изоляцию в общее промежуточное ПО, слои репозиториев\u002Fсервисов, движки политик, безопасность на уровне строк базы данных, выделенные учётные данные, отдельные схемы или отдельные базы данных в зависимости от риска и архитектуры.\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\">Изоляцию должно быть трудно забыть\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Самая сильная граница — та, которую обычный код приложения не может легко обойти, пропустив одно условие \u003Ccode>tenantId\u003C\u002Fcode>.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-44\">Стратегии изоляции баз данных\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\">Стратегия\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Граница\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Сила \u002F компромисс\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общие таблицы + ключ арендатора\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Политика на уровне строк\u002Fприложения\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Операционно эффективно; требует исчерпывающего ограничения областью арендатора и строгих тестов\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общие таблицы + RLS базы данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Граница политики базы данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Снижает зависимость от каждого запроса приложения; требует правильных ролей, контекста арендатора сессии\u002Fтранзакции и покрытия политиками\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Отдельные схемы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Граница пространства имён \u002F роли БД\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Более сильное логическое разделение; больше операционной сложности\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Отдельные базы данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Граница базы данных \u002F учётных данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Сильная изоляция и более простая история радиуса поражения; выше затраты на предоставление и эксплуатацию\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Отдельная инфраструктура\u002Fаккаунт\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Граница инфраструктуры\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Самое сильное крупнозернистое разделение; самые высокие затраты и операционные накладные расходы\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Гибрид\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">По рабочей нагрузке\u002Fклассу данных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Позволяет более сильную изоляцию только там, где риск\u002Fсоответствие требованиям это оправдывает\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Текущая шпаргалка OWASP по безопасности мультиарендаторных систем перечисляет отдельные базы данных, отдельные схемы, общие таблицы с контролем на уровне строк и гибридные модели. Правильная модель зависит от уровня угрозы, соответствия требованиям, производительности и операционных затрат.\u003C\u002Fp>\n\u003Ch2 id=\"section-47\">Безопасность на уровне строк PostgreSQL может обеспечить эшелонированную защиту\u003C\u002Fh2>\n\u003Cp>При общих таблицах безопасность на уровне строк PostgreSQL может обеспечить предикат арендатора на уровне базы данных, чтобы обычные запросы не могли видеть строки вне политики активного арендатора.\u003C\u002Fp>\n\u003Cp>Однако RLS — не магия. Суперпользователи PostgreSQL и роли с BYPASSRLS могут обходить политики строк. Поэтому OWASP рекомендует использовать роль с минимальными привилегиями для пути запроса и тестировать тот же режим соединения\u002Fпула, который используется в продакшене.\u003C\u002Fp>\n\u003Cp>Повторное использование соединений — ещё один важный крайний случай: контекст арендатора должен безопасно устанавливаться и сбрасываться для каждой транзакции\u002Fзапроса, чтобы одно соединение из пула не могло раскрыть предыдущее состояние арендатора.\u003C\u002Fp>\n\u003Ch2 id=\"section-51\">Изоляция арендаторов должна включать кэши\u003C\u002Fh2>\n\u003Cp>Запрос к базе данных может быть идеально ограничен по области, но всё равно раскрыть данные через общий ключ кэша.\u003C\u002Fp>\n\u003Cp>Если user:42 существует и в Арендаторе A, и в Арендаторе B, глобальный ключ кэша может вернуть значение не того арендатора. Ключи кэша, чувствительные к арендатору, должны включать каждый атрибут, который меняет видимость или семантику результата, обычно арендатора, пользователя, локаль, набор функций или версию разрешений.\u003C\u002Fp>\n\u003Cp>Разделение кэша — это эшелонированная защита, а не замена авторизации. Запрос всё ещё должен быть авторизован до возврата защищённого кэшированного содержимого.\u003C\u002Fp>\n\u003Ch2 id=\"section-55\">Файлы и объектное хранилище нуждаются в собственной границе арендатора\u003C\u002Fh2>\n\u003Cp>Объектное хранилище должно различать глобальные, привязанные к арендатору и привязанные к пользователю объекты. Префикс папки сам по себе является лишь соглашением об именовании, если политика доступа фактически не ограничивает чтение и запись.\u003C\u002Fp>\n\u003Cp>Более строгие архитектуры могут использовать ключи объектов с учётом арендатора, политики бакетов, отдельные бакеты\u002Fаккаунты или ключи шифрования для конкретного арендатора, когда риск или требования соответствия требуют более сильной изоляции.\u003C\u002Fp>\n\u003Cp>Подписанные URL должны быть авторизованы до выдачи и ограничены точным объектом и операцией. Наличие идентификатора объекта само по себе не должно предоставлять доступ между арендаторами.\u003C\u002Fp>\n\u003Ch2 id=\"section-59\">Фоновые задачи и очереди могут нарушить изоляцию\u003C\u002Fh2>\n\u003Cp>Асинхронные задачи часто покидают исходный контекст HTTP-запроса, что затрудняет корректную передачу арендатора. Сообщение в очереди, содержащее tenantId, не является достаточным доказательством того, что производитель был авторизован.\u003C\u002Fp>\n\u003Cp>Воркер должен нести проверенную идентичность сервиса\u002Fпользователя или доверенный конверт задачи, заново устанавливать контекст арендатора и повторно авторизовывать значимые операции на границе потребителя.\u003C\u002Fp>\n\u003Cp>Изоляция арендаторов также включает доступность. Один арендатор не должен иметь возможности монополизировать общие воркеры, очереди, пулы соединений или вычислительные ресурсы способами, которые существенно ухудшают работу других арендаторов.\u003C\u002Fp>\n\u003Ch2 id=\"section-63\">Поиск и RAG нуждаются в извлечении с учётом арендатора\u003C\u002Fh2>\n\u003Cp>Мультитенантный ИИ вводит ещё одну копию проблемы изоляции. Документы могут быть разбиты на фрагменты, преобразованы в эмбеддинги и сохранены в векторном индексе после приёма.\u003C\u002Fp>\n\u003Cp>Текущее руководство OWASP по безопасности RAG утверждает, что контроль доступа должен применяться во время извлечения и что фрагменты от Арендатора A не должны извлекаться запросами от Арендатора B. Нельзя просто предполагать, что разрешения на уровне документа автоматически сохраняются при разбиении на фрагменты.\u003C\u002Fp>\n\u003Cp>Таким образом, векторный индекс нуждается в метаданных арендатора\u002Fдоступа или физически\u002Fлогически разделённых коллекциях в соответствии с архитектурой изоляции. Фильтры извлечения должны применяться до того, как неавторизованный контент сможет попасть в контекст модели.\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\">Модель никогда не должна быть фильтром арендатора\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Не извлекайте фрагменты между арендаторами и затем не инструктируйте языковую модель игнорировать их. Как только защищённые данные попадают в контекст модели, граница изоляции уже нарушена.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-68\">Производные данные наследуют чувствительность арендатора\u003C\u002Fh2>\n\u003Cp>Эмбеддинги, поисковые индексы, миниатюры, сгенерированные резюме, кэши, строки аналитики и ответы ИИ являются производными от исходных данных. Их область арендатора должна следовать за источником, если только явное преобразование не создаёт законный общий\u002Fглобальный артефакт.\u003C\u002Fp>\n\u003Cp>Удаление и отключение поэтому должны распространяться за пределы канонической строки. Удаление документа арендатора с сохранением доступных для поиска фрагментов или кэшированных резюме может сохранить межарендаторское или послерetенционное воздействие.\u003C\u002Fp>\n\u003Ch2 id=\"section-71\">Не всё принадлежит арендатору\u003C\u002Fh2>\n\u003Cp>Мультитенантные платформы часто имеют намеренно глобальные ресурсы: таксономии продуктов, публичные шаблоны, системные разрешения, определения функций или публичный контент.\u003C\u002Fp>\n\u003Cp>Самая безопасная модель — это явная классификация: глобальная, ограниченная арендатором, ограниченная пользователем или явно кросс-арендаторская. Именно неоднозначные ресурсы становятся отправной точкой случайной утечки.\u003C\u002Fp>\n\u003Cp>У намеренно общего объекта должна быть документированная причина быть глобальным, а не просто отсутствие привязки к арендатору.\u003C\u002Fp>\n\u003Ch2 id=\"section-75\">Администраторы платформы требуют иной модели полномочий\u003C\u002Fh2>\n\u003Cp>Оператору платформы может потребоваться проверять несколько арендаторов для поддержки, соответствия требованиям или инфраструктурных операций. Моделирование этого как обычного ADMIN арендатора со случайным глобальным доступом к базе данных ослабляет как безопасность, так и возможность аудита.\u003C\u002Fp>\n\u003Cp>Лучший дизайн использует отдельную идентичность платформы или явное кросс-арендаторское разрешение, усиленную аутентификацию, ограничение цели, детальный аудит и, где это уместно, элементы управления одобрением или экстренным доступом.\u003C\u002Fp>\n\u003Cp>Таким образом, кросс-арендаторский доступ должен быть именованной возможностью, а не отсутствием фильтра арендатора.\u003C\u002Fp>\n\u003Ch2 id=\"section-79\">RBAC можно комбинировать с атрибутами\u003C\u002Fh2>\n\u003Cp>Некоторые решения зависят не только от роли. Членство в арендаторе, регион, владелец ресурса, уровень подписки, время, членство в проекте или классификация данных — всё это может влиять на доступ.\u003C\u002Fp>\n\u003Cp>RBAC и ABAC не являются взаимоисключающими. Текущее руководство AWS по мультиарендаторской авторизации рассматривает RBAC, ABAC и гибридные модели. Роль может определять широкую ответственность, в то время как атрибуты ограничивают, к какому конкретному экземпляру ресурса можно получить доступ.\u003C\u002Fp>\n\u003Cp>Ключевое архитектурное правило остаётся неизменным: не кодируйте изоляцию арендаторов только как случайное имя роли, если идентичность арендатора является первостепенной границей ресурса.\u003C\u002Fp>\n\u003Ch2 id=\"section-83\">Решения об авторизации как минимум двумерны\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\">Субъект\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Разрешение роли\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Отношение арендатора\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Решение\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Алиса\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\">Заказ принадлежит арендатору Алисы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разрешить\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Алиса\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\">Заказ принадлежит другому арендатору\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Запретить\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Алиса\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\">Заказ принадлежит арендатору Алисы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разрешить, если роль включает запись\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Алиса\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\">Заказ принадлежит другому арендатору\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Запретить\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поддержка платформы\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\">Явная область поддержки + аудируемый целевой арендатор\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Потенциально разрешить в рамках политики платформы\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Фоновый обработчик\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\">Доверенная область сервиса для арендатора задания\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разрешить только для подтверждённого арендатора задания\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-85\">Свидетельство оригинальной реализации: 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\">Свидетельство оригинальной реализации\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">Aaasaasa AI CMS содержит конкретную реализацию RBAC с ограничением по арендатору. Это полезное свидетельство того, как авторизация ролей и область арендатора могут быть объединены, но это не должно представляться как доказательство того, что каждый уровень хранения, кэша или инфраструктуры имеет полную изоляцию арендаторов.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Cp>Сервис RBAC определяет типизированные коды разрешений, такие как cms.content.read, shop.orders.write, billing.reconcile и users.roles. Системные роли отображают эти разрешения в именованные наборы ответственности.\u003C\u002Fp>\n\u003Cp>Записи ролей создаются и разрешаются с tenantId. Системные роли обновляются или вставляются с использованием составной идентичности арендатор\u002Fкод, а список ролей фильтруется по арендатору.\u003C\u002Fp>\n\u003Cp>Обновление и удаление роли сначала разрешают роль, используя как ID роли, так и ID арендатора. Назначения ролей пользователям также сохраняются и заменяются в контексте текущего арендатора.\u003C\u002Fp>\n\u003Cp>Разрешение разрешений читает явные назначения ролей пользователям с областью, ограниченной как tenantId, так и userId. Это предотвращает автоматическое превращение назначения роли одного арендатора в назначение роли другого арендатора.\u003C\u002Fp>\n\u003Cp>На уровне API административные маршруты RBAC разрешают контекст тенанта перед созданием или изменением ролей. Это правильное направление: администрирование разрешений само должно учитывать мультитенантность.\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\">Наблюдаемый шаблон реализации\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Значение для безопасности\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Типизированные коды разрешений\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Словарь операций RBAC явный\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Сопоставления системных ролей → разрешений\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Роли агрегируют разрешения, а не жестко кодируют пользователей\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Идентичность роли tenantId_code\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Одна и та же логическая роль может существовать отдельно для каждого тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поиск роли использует id + tenantId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изменение роли ограничено тенантом\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Связь пользователь-роль хранит tenantId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Членство не выводится глобально только из роли\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Разрешение разрешений использует tenantId + userId\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Авторизация оценивается внутри контекста тенанта\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\">Что эти доказательства не доказывают\u003C\u002Fstrong>\u003Cdiv class=\"text-gray-700 dark:text-gray-200\">RBAC с ограничением по тенанту — это один слой. Полная изоляция тенантов должна также охватывать все поиски ресурсов, принадлежащих тенанту, базы данных, кэши, файлы, поисковые\u002Fвекторные индексы, фоновые задачи, интеграции и операционные пути. Доказательства из репозитория здесь подтверждают шаблон проектирования RBAC\u002Fограничения по тенанту, а не заявление о независимо проверенной изоляции SaaS.\u003C\u002Fdiv>\u003C\u002Faside>\n\u003Ch2 id=\"section-94\">Почему это различие еще важнее для ИИ-агентов\u003C\u002Fh2>\n\u003Cp>ИИ-агенты могут превратить ошибку в разрешениях в последовательность действий. Если агенту дан широкий инструмент orders.read без принудительного ограничения по тенанту, сбой рассуждения или внедрение промпта может вызвать межтенантные чтения на машинной скорости.\u003C\u002Fp>\n\u003Cp>Описания инструментов агента могут упоминать ограничения тенанта, но принудительное применение все равно должно происходить в доверенном слое среды выполнения\u002Fсервиса\u002Fданных. Инструкции на естественном языке не являются границей авторизации.\u003C\u002Fp>\n\u003Cp>То же самое относится к RAG: агент может иметь разрешение на использование инструмента поиска, но серверная часть поиска все равно должна предотвращать возврат запросом Тенанта A фрагментов Тенанта B.\u003C\u002Fp>\n\u003Ch2 id=\"section-98\">Тестируйте RBAC и изоляцию тенантов отдельно\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\">Семейство тестов\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Что оно должно доказать\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест понижения роли\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пользователь без разрешения не может выполнить операцию даже внутри своего тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест объекта другого тенанта\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пользователь с правильной ролью все равно не может получить доступ к тому же типу ресурса в другом тенанте\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Подмена идентификаторов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изменение ID объекта\u002Fтенанта не пересекает границы области\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест списочных\u002Fмассовых эндпоинтов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Широкие запросы возвращают только авторизованные данные тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест повторного использования кэша\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Два тенанта, использующие переиспользуемые процессы\u002Fсоединения, никогда не получают кэшированное состояние друг друга\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест роли запроса RLS\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Роль производственного запроса не может обойти политики строк\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест асинхронного воркера\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Контекст тенанта сохраняется при постановке в очередь и повторно проверяется при потреблении\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест векторного поиска\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Запрос Тенанта A никогда не извлекает фрагменты Тенанта B\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест администратора платформы\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Межтенантная возможность является явной, узкой и поддающейся аудиту\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Тест отключения\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Данные тенанта и производные индексы\u002Fкэши удаляются в соответствии с политикой\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Руководство OWASP по регрессии авторизации специально выделяет тесты границ между тенантами, потому что изменения кода в кэшировании, запросах или общих сервисах могут незаметно нарушить изоляцию, даже если тесты ролей продолжают проходить.\u003C\u002Fp>\n\u003Ch2 id=\"section-101\">Распространенные режимы отказа\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\">Режим отказа\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Почему он не работает\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Проверка роли, но не тенанта\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Действительная роль становится межтенантным полномочием\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Доверие tenant ID из запроса\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Клиент контролирует селектор изоляции\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ограничение UI, но не API\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Скрытые кнопки не защищают серверные ресурсы\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Эндпоинт деталей с учетом тенанта, эндпоинт списка без области\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Массовые чтения раскрывают другие тенанты\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Фильтр тенанта в большинстве запросов\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Один забытый путь нарушает границу\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Глобальные ключи кэша\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Правильная изоляция базы данных обходится кэшированными данными\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Общий векторный индекс без принудительных фильтров метаданных\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RAG извлекает фрагменты другого тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">tenant ID сообщения очереди рассматривается как авторизация\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поддельная или неправильно созданная задача может пересечь границу тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Администратор платформы смоделирован как обычный ADMIN\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Межтенантная власть становится неявной и трудной для аудита\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Роль копируется глобально между членствами в тенантах\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пользователь получает разрешения в тенантах, где он никогда не был назначен\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Отдельные базы данных, но общий привилегированный учетный данные\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Приложение все еще может пересекать базы данных, если его учетные данные слишком широки\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RLS с ролью запроса BYPASSRLS\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Политика базы данных существует, но не защищает фактический путь запроса\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Случайные UUID рассматриваются как изоляция\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Трудно угадываемые идентификаторы уменьшают перебор, но не авторизуют доступ\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-103\">Распространенные заблуждения\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\">Заблуждение\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Исправление\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«RBAC обеспечивает изоляцию тенантов».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">RBAC управляет разрешениями; изоляция также требует ограничения области тенанта\u002Fресурса.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Если пользователь администратор, проверки тенанта не нужны».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Полномочия администратора все равно должны иметь явную область.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Tenant ID в JWT достаточно».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Он может быть доверенным входом только если проверен и последовательно применяется ко всем защищенным путям ресурсов.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Отдельные базы данных устраняют требования авторизации».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Пользователям все еще нужны разрешения на уровне операций внутри их тенанта.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Столбец tenant_id означает, что система изолирована».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поле помогает только если пути доступа его применяют.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«UUID предотвращают межтенантный доступ».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Непредсказуемые идентификаторы — это эшелонированная защита, а не авторизация.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«RLS означает, что код приложения не нуждается в проверках безопасности».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Авторизация приложения, правильные роли БД и покрытие политик все еще важны.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Одна общая векторная БД небезопасна».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Она может быть безопасной, если изоляция может быть обеспечена и проверена; физическое разделение — один из вариантов, а не единственный.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Поддержке платформы нужен глобальный ADMIN».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Межтенантная поддержка должна быть отдельным, ограниченным и поддающимся аудиту полномочием.\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">«Внутренние сервисы могут пропускать проверки тенанта».\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Внутренние пути все еще могут быть скомпрометированы или неправильно настроены и должны сохранять контекст тенанта.\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-105\">Практическая последовательность проектирования\u003C\u002Fh2>\n\u003Csection class=\"editorjs-process my-6\">\u003Ch3 class=\"mb-3 text-lg font-semibold\">Проектируйте разрешения и изоляцию как отдельные измерения\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. Определите владение тенантом\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Классифицируйте, какие сущности и ресурсы являются глобальными, ограниченными тенантом, ограниченными пользователем или намеренно межтенантными.\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. Определите операции\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Создайте явные разрешения для чтения, записи, публикации, утверждения, администрирования и других бизнес-действий.\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. Определите роли\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Группируйте разрешения в соответствии с обязанностями, не встраивая случайную глобальную область.\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. Определите область членства\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Привяжите назначения ролей к контексту тенанта\u002Fрабочего пространства\u002Fпроекта, в котором они применяются.\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. Разрешите доверенный контекст тенанта\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Выводите идентичность тенанта из аутентифицированного, проверенного сервером членства или авторизации сервиса.\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. Обеспечьте владение ресурсами\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Применяйте область тенанта на каждой границе данных\u002Fсервиса, принадлежащих тенанту.\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. Добавьте эшелонированную защиту\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Используйте RLS, отдельные учетные данные, схемы\u002Fбазы данных, политики хранения или движки политик там, где риск это оправдывает.\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. Переносите область через производные системы\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Сохраняйте метаданные тенанта в кэше, поиске, векторных индексах, очередях, файлах и аналитике.\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. Моделируйте межтенантные операции явно\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Отделяйте администрирование платформы и идентичности сервисов от обычных ролей тенанта.\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. Тестируйте обе оси\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Запускайте негативные тесты для отсутствующего разрешения и для неправильного тенанта независимо.\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. Аудит тенанта + разрешения вместе\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Регистрируйте, кто действовал, в каком тенанте, над какой целью и под какими полномочиями.\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. Повторно тестируйте после изменений схемы\u002Fсреды выполнения\u003C\u002Fdiv>\u003Cdiv class=\"mt-1 text-sm text-gray-600 dark:text-gray-300\">Изоляция может нарушиться при введении новых таблиц, кэшей, очередей или путей поиска.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-107\">Контрольный список RBAC + изоляция тенантов\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\">Вопрос\u003C\u002Fth>\u003Cth class=\"border border-gray-300 px-4 py-2 text-left font-semibold\">Ожидаемый ответ\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто является субъектом?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Аутентифицированная идентичность пользователя\u002Fсервиса\u002Fагента\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какой контекст тенанта применяется?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Проверенное сервером членство или область сервиса\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Какая операция запрашивается?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Типизированное разрешение или действие политики\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Имеет ли субъект это разрешение?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Решение роли\u002Fполитики\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Кто владеет целевым ресурсом?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Явная классификация тенанта\u002Fглобального\u002Fпользовательского\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Соответствует ли область ресурса полномочиям?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Поиск\u002Fполитика с учетом тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Может ли хранилище обойти проверки приложения?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Решение об эшелонированной защите задокументировано\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Безопасны ли кэши для тенантов?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Ключи\u002Fпространства имен и авторизация сохраняют область тенанта\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Безопасны ли файлы\u002Fблобы для тенантов?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Политика объектов и выдача подписанных URL обеспечивают область\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Безопасны ли асинхронные задачи для тенантов?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Проверенный контекст распространяется и повторно проверяется\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Безопасны ли RAG\u002Fпоиск для тенантов?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Изоляция метаданных\u002Fколлекций обеспечивается до контекста модели\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Явны ли межтенантные администраторы?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Отдельные полномочия, средства контроля и аудит\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Могут ли обычные учетные данные обойти изоляцию?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Нет, или строго задокументированный исключительный путь\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Автоматизированы ли негативные межтенантные тесты?\u003C\u002Ftd>\u003Ctd class=\"border border-gray-300 px-4 py-2\">Да для каждого соответствующего слоя доступа\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Ch2 id=\"section-109\">Граничные случаи и ограничения\u003C\u002Fh2>\n\u003Cp>Пользователь может принадлежать нескольким тенантам. Поэтому текущий тенант должен быть явным контекстом выполнения, а не постоянно выводиться из учетной записи пользователя.\u003C\u002Fp>\n\u003Cp>Некоторые ресурсы намеренно используются совместно выбранными тенантами, например пространства для совместной работы или данные консорциума. Это требует явной модели совместного использования; попытка представить, что ресурс принадлежит одному тенанту, и добавление исключений позже обычно создает неоднозначную авторизацию.\u003C\u002Fp>\n\u003Cp>Изоляция от шумных соседей связана, но отличается от изоляции конфиденциальности. Тенант может никогда не видеть данные другого тенанта, но при этом исчерпать общие ресурсы CPU, емкость очереди или подключения к базе данных. Поэтому ограничения скорости и квоты ресурсов могут учитывать тенанта как границу доступности.\u003C\u002Fp>\n\u003Cp>Физическая изоляция не является автоматически безопасной, если учетные данные плоскости управления или административные пути могут пересекать границы. Логическая изоляция не является автоматически слабой, если политики централизованно применяются, основаны на принципе наименьших привилегий и тщательно протестированы.\u003C\u002Fp>\n\u003Cp>Требования к изоляции тенантов могут различаться в зависимости от класса данных. Публичные данные каталога, записи о выставлении счетов и частные документы ИИ могут оправдывать различные границы хранения и шифрования внутри одного SaaS-продукта.\u003C\u002Fp>\n\u003Ch2 id=\"section-115\">Что могло бы изменить этот ответ?\u003C\u002Fh2>\n\u003Cp>Конкретная реализация меняется в зависимости от архитектуры: бессерверные API, Kubernetes, PostgreSQL, объектное хранилище, векторные базы данных и движки политик предоставляют разные примитивы изоляции.\u003C\u002Fp>\n\u003Cp>Требуемая степень также меняется в зависимости от регулирования, контрактов с клиентами, чувствительности данных, модели угроз и операционного масштаба. Некоторые тенанты могут оправдывать изолированные базы данных или инфраструктуру, в то время как другие используют общие ресурсы.\u003C\u002Fp>\n\u003Cp>Концептуальное различие не меняется: разрешение на выполнение операции — это не то же самое, что разрешение на пересечение границы тенанта.\u003C\u002Fp>\n\u003Ch2 id=\"section-119\">Связанные канонические знания\u003C\u002Fh2>\n\u003Cp>S01 является предварительным условием безопасности для архитектуры корпоративного ИИ и управления ИИ. Как только инструменты ИИ, RAG или агенты работают с мультитенантными данными, идентичность тенанта должна проходить через извлечение, выполнение инструментов, память, кэши и трассировки аудита.\u003C\u002Fp>\n\u003Cp>Это также напрямую связано с агентным ИИ: возможности инструментов и разрешения ролей должны быть ограничены владением тенанта, прежде чем агент сможет читать или изменять бизнес-ресурсы.\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: объяснение стека протоколов агентов\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Совместимость протоколов не заменяет авторизацию или изоляцию тенантов. Обнаружение возможностей и бизнес-полномочия остаются отдельными архитектурными вопросами.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Читать статью о стеке протоколов →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Cp>Для RAG изоляция тенантов должна применяться до того, как защищенные фрагменты попадут в контекст модели.\u003C\u002Fp>\n\u003Caside class=\"editorjs-referral my-6\">\u003Ca href=\"https:\u002F\u002Fstajic.de\u002Fru\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\">Что такое RAG? Самое простое объяснение того, как это работает\u003C\u002Fstrong>\u003Cp class=\"mt-2 text-sm text-gray-600 dark:text-gray-300\">Основа извлечения для понимания того, где должны применяться фильтрация источников с учетом тенанта и изоляция векторного хранилища.\u003C\u002Fp>\u003Cspan class=\"mt-3 inline-flex text-sm font-medium text-primary-600 dark:text-primary-400\">Читать основы RAG →\u003C\u002Fspan>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Faside>\n\u003Ch2 id=\"section-125\">Часто задаваемые вопросы\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\">RBAC vs изоляция тенантов: FAQ\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\">В чем разница между RBAC и изоляцией тенантов?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">RBAC определяет, какие операции может выполнять субъект. Изоляция тенантов определяет, к ресурсам какого тенанта эти операции могут получить доступ. Безопасные мультитенантные приложения обычно нуждаются в обоих.\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\">Роль ADMIN автоматически разрешает доступ ко всем тенантам?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. ADMIN должен иметь явную область действия. Администратор тенанта обычно имеет широкие разрешения только внутри этого тенанта, в то время как кросс-тенантное администрирование платформы должно моделироваться отдельно.\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\">Достаточно ли аутентификации для изоляции тенантов?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Нет. Аутентификация подтверждает личность. Авторизация контролирует разрешенные действия. Изоляция тенантов дополнительно предотвращает доступ этих действий к ресурсам неправильного тенанта.\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\">Следует ли хранить tenantId в JWT?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Это может быть одним из входных данных для контекста тенанта, но сервер должен проверять текущее членство\u002Fполномочия и применять область действия на границах защищенных ресурсов. Одного утверждения недостаточно для замены средств изоляции.\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\">Нужна ли отдельная база данных для каждого тенанта?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Не обязательно. Модели изоляции с общей таблицей, RLS, схемой, базой данных, инфраструктурой и гибридные модели могут быть допустимы в зависимости от рисков и операционных требований.\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 заменить фильтры тенантов в коде приложения?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">RLS может обеспечить надежную эшелонированную защиту, но правильные роли базы данных, контекст запроса, покрытие политик и авторизация на уровне приложения по-прежнему важны.\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\">Как RAG должен обеспечивать изоляцию тенантов?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Область действия тенанта\u002Fдоступа должна применяться во время извлечения, чтобы неавторизованные фрагменты никогда не попадали в контекст модели. Сохраняйте метаданные доступа при разбиении на фрагменты и индексации.\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\">Может ли один пользователь иметь разные роли в разных тенантах?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Да. Это распространено в B2B SaaS и является веской причиной для привязки назначений ролей к членству в тенанте, а не для рассмотрения ролей как глобально привязанных к пользователю.\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\">Какой лучший тест для изоляции тенантов?\u003C\u002Fh4>\u003Cdiv class=\"mt-2 text-gray-600 dark:text-gray-300\">Используйте негативные кросс-тенантные тесты: создайте как минимум два тенанта, дайте пользователю действительные разрешения в одном тенанте, затем докажите, что каждый защищенный путь запрещает доступ к ресурсам другого тенанта.\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fsection>\n\u003Ch2 id=\"section-127\">Глоссарий\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\">Ключевые термины безопасности мультитенантных систем\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\">Управление доступом на основе ролей: модель авторизации, которая связывает разрешения с ролями и назначает пользователей или субъектов этим ролям.\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\">Тенант\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Клиент, организация, рабочее пространство или иной изолированный логический потребитель общей мультитенантной системы.\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\">Изоляция тенантов\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Механизмы, которые не позволяют одному тенанту получать доступ к ресурсам другого тенанта, изменять их или получать их в общей системе.\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\">Аутентификация\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Проверка подлинности пользователя, сервиса или иного субъекта.\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\">Авторизация\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Процесс принятия решения о том, может ли субъект выполнить запрошенную операцию над ресурсом.\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\">Разрешение\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Определённая допустимая операция или возможность, например orders.read или 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\">Роль\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Именованная группа разрешений, связанная с ответственностью или функцией.\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\">Управление доступом на основе атрибутов: авторизация на основе атрибутов субъекта, ресурса, действия или среды.\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\">Безопасность на уровне строк\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Механизм политик базы данных, который ограничивает, какие строки роль или сессия базы данных может читать или изменять.\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\">Межтенантный доступ\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Любой путь доступа, при котором субъект, действующий в контексте одного тенанта, достигает ресурсов, принадлежащих другому тенанту.\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\">Администратор платформы\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Привилегированная операционная учётная запись с явно смоделированными полномочиями, которые могут охватывать несколько тенантов.\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\">Контекст тенанта\u003C\u002Fdt>\u003Cdd class=\"mt-1 text-gray-600 dark:text-gray-300\">Проверенная область тенанта, в рамках которой выполняется текущий запрос, задача или операция агента.\u003C\u002Fdd>\u003C\u002Fdiv>\u003C\u002Fdl>\u003C\u002Fsection>\n\u003Ch2 id=\"section-129\">Заключение\u003C\u002Fh2>\n\u003Cp>RBAC и изоляция тенантов — это взаимодополняющие, а не конкурирующие механизмы безопасности. RBAC структурирует операционные разрешения; изоляция тенантов ограничивает границу ресурсов, внутри которой эти разрешения могут применяться.\u003C\u002Fp>\n\u003Cp>Поэтому надёжный мультитенантный запрос требует большего, чем «у пользователя есть роль ADMIN». Ему нужны проверенный субъект, проверенный контекст тенанта, разрешённая операция, цель в области тенанта и принудительное применение на каждом уровне ресурсов, который может содержать данные, принадлежащие тенанту.\u003C\u002Fp>\n\u003Cp>Самое короткое надёжное правило таково: авторизуйте действие, затем изолируйте область — и никогда не предполагайте, что одно доказывает другое.\u003C\u002Fp>\n\u003Ch2 id=\"section-133\">Первоисточники и актуальные рекомендации\u003C\u002Fh2>\n\u003Cp>Приведённые ниже источники подтверждают определение RBAC и актуальные рекомендации по изоляции тенантов. Раздел Aaasaasa AI CMS является оригинальным свидетельством реализации и намеренно ограничен теми шаблонами кода, которые были проверены.\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\">Обзор NIST моделей RBAC и стандарта INCITS RBAC, включая пользователей, роли, разрешения, операции и объекты.\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 — RBAC glossary\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные определения управления доступом на основе ролей в глоссарии NIST как назначения разрешений через роли.\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 — The isolation mindset\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Рекомендации AWS по SaaS, явно разграничивающие аутентификацию\u002Fавторизацию и изоляцию тенантов и рекомендующие общие механизмы изоляции.\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 — Multi-tenant authorization FAQ\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации, объясняющие разницу между авторизацией и изоляцией тенантов в 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 — Multi-tenant design considerations\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по SaaS, разграничивающие изоляцию тенантов и авторизацию и обсуждающие модели политик авторизации с общим и выделенным размещением.\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 — Multi-Tenant Application Security Cheat Sheet\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные практические рекомендации по контексту тенанта, изоляции баз данных, кэшей, хранилищ, очередей, тестированию и предотвращению межтенантного доступа.\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 — RAG Security Cheat Sheet\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации, требующие контроля доступа во время извлечения и изоляции тенантов для мультитенантных векторных хранилищ.\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 — Authorization Regression Testing\u003C\u002Fstrong>\u003Cp class=\"text-sm text-gray-600 dark:text-gray-400\">Актуальные рекомендации по тестированию, включая тесты понижения роли и границ между тенантами.\u003C\u002Fp>\u003C\u002Fa>",{"time":212,"blocks":213,"version":1410},1791485473247,[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 и изоляция тенантов решают две разные задачи безопасности в мультитенантных системах. Управление доступом на основе ролей (RBAC) определяет, что разрешено делать аутентифицированному субъекту, например читать заказы, редактировать товары или управлять пользователями. Изоляция тенантов определяет, к данным, ресурсам и контексту выполнения какого тенанта этот субъект имеет доступ. Пользователь может быть корректно аутентифицирован и корректно наделён ролью RBAC, но при этом всё равно столкнуться с нарушением безопасности, если приложение позволяет этой роли работать с ресурсами другого тенанта.","paragraph",{},{"id":221,"data":222,"type":226,"tunes":227},"direct",{"body":223,"title":224,"variant":225},"\u003Cstrong>RBAC отвечает на вопрос «что может делать эта учётная запись?» Изоляция тенантов отвечает на вопрос «внутри чьей границы она может это делать?»\u003C\u002Fstrong>\u003Cbr>\u003Cbr>Безопасное мультитенантное приложение обычно нуждается в обоих механизмах. Администратор тенанта может обладать широкими правами, но эти права должны оставаться ограниченными рамками тенанта администратора, если только не существует явно отдельного полномочия уровня платформы.","Прямой ответ","info","callout",{},{"id":229,"data":230,"type":226,"tunes":234},"boundary",{"body":231,"title":232,"variant":233},"Назначение пользователю роли \u003Ccode>ADMIN\u003C\u002Fcode> не означает автоматически «администратор только тенанта A». Роль должна оцениваться вместе с проверенным контекстом тенанта и принадлежностью целевого ресурса к тенанту. В противном случае действительная роль может превратиться в межтенантную привилегию.","Роль — это не граница тенанта","warning",{},{"id":236,"data":237,"type":226,"tunes":241},"current",{"body":238,"title":239,"variant":240},"Само различие остаётся стабильным. NIST определяет RBAC через пользователей, роли, разрешения, операции и объекты. Актуальные рекомендации AWS по SaaS прямо указывают, что аутентификация и авторизация не равны изоляции тенантов и что пользователь может быть аутентифицирован и авторизован, но при этом всё равно получить доступ к ресурсам другого тенанта, если изоляция не обеспечивается отдельно. Актуальные рекомендации OWASP по мультитенантной безопасности также рассматривают изоляцию тенантов как требование на всех уровнях, охватывающее API, базы данных, кэши, хранилища, очереди и другие общие ресурсы.","Примечание об актуальных источниках — 8 октября 2026 г.","note",{},{"id":243,"data":244,"type":248,"tunes":249},"toc",{"title":245,"maxLevel":246,"minLevel":247},"Содержание",3,2,"tableOfContents",{},{"id":251,"data":252,"type":42,"tunes":254},"h-meaning",{"text":253,"level":247},"Что на самом деле контролирует RBAC",{},{"id":256,"data":257,"type":218,"tunes":259},"p-rbac-1",{"text":258},"RBAC — это модель авторизации, в которой разрешения связаны с ролями, а пользователи назначаются на эти роли. Роль выступает административной абстракцией между учётными записями и разрешениями.",{},{"id":261,"data":262,"type":218,"tunes":264},"p-rbac-2",{"text":263},"Классическая работа NIST по RBAC формализует это через пользователей, роли, разрешения, операции и объекты. Практическая выгода в том, что организация может управлять авторизацией через относительно стабильные должностные или функциональные роли, а не привязывать каждое разрешение напрямую к каждому пользователю.",{},{"id":266,"data":267,"type":218,"tunes":269},"p-rbac-3",{"text":268},"Роль, например EDITOR, может означать: может читать контент, писать контент и публиковать контент. Роль, например ACCOUNTANT, может означать: может читать данные биллинга, сверять счета и утверждать расчёты.",{},{"id":271,"data":272,"type":42,"tunes":274},"h-tenant",{"text":273,"level":247},"Что на самом деле контролирует изоляция тенантов",{},{"id":276,"data":277,"type":218,"tunes":279},"p-tenant-1",{"text":278},"Изоляция тенантов — это набор механизмов, которые не позволяют одному тенанту читать, изменять, влиять или случайно получать ресурсы другого тенанта в общей системе.",{},{"id":281,"data":282,"type":218,"tunes":284},"p-tenant-2",{"text":283},"Защищаемая граница шире, чем строки в базе данных. Состояние, относящееся к тенанту, может существовать в реляционных таблицах, объектных хранилищах, векторных индексах, кэшах, поисковых индексах, сообщениях очередей, файлах, временных артефактах, фоновых задачах, аналитике, ограничениях скорости и инфраструктурных ресурсах.",{},{"id":286,"data":287,"type":218,"tunes":289},"p-tenant-3",{"text":288},"Рекомендации AWS по SaaS делают это различие явным: авторизация предоставляет доступ к ресурсам, а изоляция тенантов гарантирует, что эти ресурсы не пересекут границу не того тенанта, даже когда инфраструктура является общей.",{},{"id":291,"data":292,"type":42,"tunes":294},"h-simple",{"text":293,"level":247},"Простейший пример",{},{"id":296,"data":297,"type":218,"tunes":299},"p-simple-1",{"text":298},"Предположим, Алиса — администратор тенанта A, а Боб — администратор тенанта B. Оба пользователя правомерно обладают одной и той же ролью ADMIN.",{},{"id":301,"data":302,"type":218,"tunes":304},"p-simple-2",{"text":303},"RBAC может корректно заключить, что оба пользователя могут выполнить операцию, например users.read. Но когда Алиса запрашивает пользователя с ID 847, приложение всё равно должно проверить, что пользователь 847 принадлежит тенанту A.",{},{"id":306,"data":307,"type":218,"tunes":309},"p-simple-3",{"text":308},"Если API проверяет только «у Алисы есть ADMIN» и затем выполняет SELECT * FROM users WHERE id = 847, RBAC сработал, а изоляция тенантов — нет.",{},{"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. Аутентифицировать субъект","Установить, кто является пользователем, сервисом или агентом.",{"label":318,"description":319},"2. Определить проверенный контекст тенанта","Определить, какой контекст тенанта применяется, на основе доверенной серверной информации об идентичности и членстве.",{"label":321,"description":322},"3. Определить разрешение","Оценить, разрешает ли роль или политика субъекта запрошенную операцию.",{"label":324,"description":325},"4. Ограничить целевой ресурс рамками","Проверить, что целевой объект принадлежит разрешённому тенанту или явно общему пространству.",{"label":327,"description":328},"5. Обеспечить соблюдение на границе доступа","Выполнить операцию с базой данных, кэшем, хранилищем, очередью или сервисом с применением ограничений тенанта.",{"label":330,"description":331},"6. Аудит обоих измерений","Записывать субъект, тенант, операцию, цель и результат, чтобы межтенантные попытки были видны.","Корректное решение об авторизации в мультитенантной среде","auto","processFlow",{},{"id":337,"data":338,"type":42,"tunes":340},"h-stops",{"text":339,"level":247},"Где останавливается простой пример",{},{"id":342,"data":343,"type":218,"tunes":345},"p-stops-1",{"text":344},"Реальные системы часто содержат несколько классов идентичностей: пользователи арендаторов, администраторы платформы, фоновые обработчики, интеграции, агенты и кросс-арендаторские операционные сервисы. Некоторые из них законно пересекают границы арендаторов.",{},{"id":347,"data":348,"type":218,"tunes":350},"p-stops-2",{"text":349},"Это не устраняет необходимость изоляции. Это означает, что кросс-арендаторские полномочия должны быть явными, узкими и отдельно проверяемыми, а не возникать случайно из глобальной роли или неограниченного подключения к базе данных.",{},{"id":352,"data":353,"type":218,"tunes":355},"p-stops-3",{"text":354},"Изоляция арендаторов также может различаться по уровням. Продукт может совместно использовать серверы приложений, разделяя базы данных, или использовать общую базу данных с политиками на уровне строк, предоставляя премиум-арендаторам изолированное хранилище или вычислительные ресурсы. Не существует единой универсальной топологии изоляции.",{},{"id":357,"data":358,"type":42,"tunes":360},"h-compare",{"text":359,"level":247},"RBAC против изоляции арендаторов",{},{"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","Основной вопрос",[369,369],"",{"id":371,"label":372,"values":373},"unit","Типичная единица",[369,369],{"id":375,"label":376,"values":377},"example","Пример",[369,369],{"id":379,"label":380,"values":381},"failure","Типичный сбой",[369,369],{"id":383,"label":384,"values":385},"implementation","Типичная реализация",[369,369],{"id":387,"label":388,"values":389},"scope","Может ли существовать отдельно?",[369,369],"Два разных измерения безопасности","table",[393,396],{"id":394,"label":395},"rbac","RBAC",{"id":397,"label":398},"tenant","Изоляция арендаторов","comparison",{},{"id":402,"data":403,"type":42,"tunes":405},"h-authn",{"text":404,"level":247},"Аутентификация, авторизация и изоляция — это три разные проверки",{},{"id":407,"data":408,"type":391,"tunes":425},"three-checks",{"content":409,"stretched":43,"withHeadings":14},[410,414,418,422],[411,412,413],"Уровень","Вопрос","Пример сбоя",[415,416,417],"Аутентификация","Кто этот субъект?","Злоумышленник выдает себя за Алису",[419,420,421],"Авторизация \u002F RBAC","Может ли этот субъект выполнить эту операцию?","Наблюдатель может удалять пользователей",[398,423,424],"Может ли эта операция достичь границы этого арендатора\u002Fресурса?","Администратор арендатора A читает заказ арендатора B",{},{"id":427,"data":428,"type":218,"tunes":430},"p-authn-1",{"text":429},"Эти проверки связаны, но не взаимозаменяемы. Аутентификация может быть идеальной, а авторизация — нет. Авторизация может быть корректной, а изоляция арендаторов — нет. Безопасный путь запроса в SaaS требует всех применимых границ.",{},{"id":432,"data":433,"type":42,"tunes":435},"h-role-scope",{"text":434,"level":247},"Ролям нужна область действия",{},{"id":437,"data":438,"type":218,"tunes":440},"p-role-scope-1",{"text":439},"Слово ADMIN неполно без области действия. Оно может означать администратора платформы, администратора арендатора, администратора проекта, администратора рабочего пространства или администратора одной подсистемы.",{},{"id":442,"data":443,"type":218,"tunes":445},"p-role-scope-2",{"text":444},"В мультитенантных системах назначение роли обычно должно быть связано с членством в арендаторе или другой явной областью ресурса. Один и тот же пользователь может законно быть ADMIN в арендаторе A и VIEWER в арендаторе B.",{},{"id":447,"data":448,"type":218,"tunes":450},"p-role-scope-3",{"text":449},"Глобальная модель ролей, игнорирующая это различие, может создавать утечку привилегий, даже когда сама карта разрешений корректна.",{},{"id":452,"data":453,"type":42,"tunes":455},"h-context",{"text":454,"level":247},"Контекст арендатора должен поступать из доверенного источника",{},{"id":457,"data":458,"type":218,"tunes":460},"p-context-1",{"text":459},"Идентификатор арендатора, предоставленный клиентом, полезен как селектор, но не является доказательством полномочий. Сервер должен выводить или проверять членство в арендаторе на основе аутентифицированной идентичности и текущих данных авторизации.",{},{"id":462,"data":463,"type":218,"tunes":465},"p-context-2",{"text":464},"Текущие рекомендации OWASP по мультитенантности советуют устанавливать контекст арендатора на раннем этапе жизненного цикла запроса и явно предупреждают против рассмотрения клиентских заголовков или параметров запроса как доказательства авторизации.",{},{"id":467,"data":468,"type":218,"tunes":470},"p-context-3",{"text":469},"Это важно, потому что тривиальное изменение запроса с tenant=A на tenant=B не должно быть достаточным для пересечения границы изоляции.",{},{"id":472,"data":473,"type":42,"tunes":475},"h-query",{"text":474,"level":247},"Область арендатора должна быть в поиске ресурса",{},{"id":477,"data":478,"type":218,"tunes":480},"p-query-1",{"text":479},"Распространённый паттерн изоляции на уровне приложения — включать область арендатора в тот же запрос, который разрешает ресурс.",{},{"id":482,"data":483,"type":391,"tunes":497},"query-table",{"content":484,"stretched":43,"withHeadings":14},[485,488,491,494],[486,487],"Слабый поиск","Более строгий поиск с областью арендатора",[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},"Этот паттерн не является единственным возможным механизмом изоляции, но он удерживает принадлежность арендатору рядом с операцией доступа к данным и предотвращает превращение идентификатора объекта в межарендаторскую возможность.",{},{"id":504,"data":505,"type":42,"tunes":507},"h-defense",{"text":506,"level":247},"Проверки на уровне приложения полезны, но изоляция не должна зависеть от идеального поведения разработчика",{},{"id":509,"data":510,"type":218,"tunes":512},"p-defense-1",{"text":511},"Руководство AWS по изоляции явно предостерегает от того, чтобы оставлять обеспечение изоляции только на разработчиков сервисов. В большой кодовой базе в конце концов один запрос, ключ кэша или путь воркера может пропустить область арендатора.",{},{"id":514,"data":515,"type":218,"tunes":517},"p-defense-2",{"text":516},"Поэтому эшелонированная защита может перенести изоляцию в общее промежуточное ПО, слои репозиториев\u002Fсервисов, движки политик, безопасность на уровне строк базы данных, выделенные учётные данные, отдельные схемы или отдельные базы данных в зависимости от риска и архитектуры.",{},{"id":519,"data":520,"type":226,"tunes":524},"defense-rule",{"body":521,"title":522,"variant":523},"Самая сильная граница — та, которую обычный код приложения не может легко обойти, пропустив одно условие \u003Ccode>tenantId\u003C\u002Fcode>.","Изоляцию должно быть трудно забыть","success",{},{"id":526,"data":527,"type":42,"tunes":529},"h-db",{"text":528,"level":247},"Стратегии изоляции баз данных",{},{"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],"Стратегия","Граница","Сила \u002F компромисс",[539,540,541],"Общие таблицы + ключ арендатора","Политика на уровне строк\u002Fприложения","Операционно эффективно; требует исчерпывающего ограничения областью арендатора и строгих тестов",[543,544,545],"Общие таблицы + RLS базы данных","Граница политики базы данных","Снижает зависимость от каждого запроса приложения; требует правильных ролей, контекста арендатора сессии\u002Fтранзакции и покрытия политиками",[547,548,549],"Отдельные схемы","Граница пространства имён \u002F роли БД","Более сильное логическое разделение; больше операционной сложности",[551,552,553],"Отдельные базы данных","Граница базы данных \u002F учётных данных","Сильная изоляция и более простая история радиуса поражения; выше затраты на предоставление и эксплуатацию",[555,556,557],"Отдельная инфраструктура\u002Fаккаунт","Граница инфраструктуры","Самое сильное крупнозернистое разделение; самые высокие затраты и операционные накладные расходы",[559,560,561],"Гибрид","По рабочей нагрузке\u002Fклассу данных","Позволяет более сильную изоляцию только там, где риск\u002Fсоответствие требованиям это оправдывает",{},{"id":564,"data":565,"type":218,"tunes":567},"p-db-1",{"text":566},"Текущая шпаргалка OWASP по безопасности мультиарендаторных систем перечисляет отдельные базы данных, отдельные схемы, общие таблицы с контролем на уровне строк и гибридные модели. Правильная модель зависит от уровня угрозы, соответствия требованиям, производительности и операционных затрат.",{},{"id":569,"data":570,"type":42,"tunes":572},"h-rls",{"text":571,"level":247},"Безопасность на уровне строк PostgreSQL может обеспечить эшелонированную защиту",{},{"id":574,"data":575,"type":218,"tunes":577},"p-rls-1",{"text":576},"При общих таблицах безопасность на уровне строк PostgreSQL может обеспечить предикат арендатора на уровне базы данных, чтобы обычные запросы не могли видеть строки вне политики активного арендатора.",{},{"id":579,"data":580,"type":218,"tunes":582},"p-rls-2",{"text":581},"Однако RLS — не магия. Суперпользователи PostgreSQL и роли с BYPASSRLS могут обходить политики строк. Поэтому OWASP рекомендует использовать роль с минимальными привилегиями для пути запроса и тестировать тот же режим соединения\u002Fпула, который используется в продакшене.",{},{"id":584,"data":585,"type":218,"tunes":587},"p-rls-3",{"text":586},"Повторное использование соединений — ещё один важный крайний случай: контекст арендатора должен безопасно устанавливаться и сбрасываться для каждой транзакции\u002Fзапроса, чтобы одно соединение из пула не могло раскрыть предыдущее состояние арендатора.",{},{"id":589,"data":590,"type":42,"tunes":592},"h-cache",{"text":591,"level":247},"Изоляция арендаторов должна включать кэши",{},{"id":594,"data":595,"type":218,"tunes":597},"p-cache-1",{"text":596},"Запрос к базе данных может быть идеально ограничен по области, но всё равно раскрыть данные через общий ключ кэша.",{},{"id":599,"data":600,"type":218,"tunes":602},"p-cache-2",{"text":601},"Если user:42 существует и в Арендаторе A, и в Арендаторе B, глобальный ключ кэша может вернуть значение не того арендатора. Ключи кэша, чувствительные к арендатору, должны включать каждый атрибут, который меняет видимость или семантику результата, обычно арендатора, пользователя, локаль, набор функций или версию разрешений.",{},{"id":604,"data":605,"type":218,"tunes":607},"p-cache-3",{"text":606},"Разделение кэша — это эшелонированная защита, а не замена авторизации. Запрос всё ещё должен быть авторизован до возврата защищённого кэшированного содержимого.",{},{"id":609,"data":610,"type":42,"tunes":612},"h-storage",{"text":611,"level":247},"Файлы и объектное хранилище нуждаются в собственной границе арендатора",{},{"id":614,"data":615,"type":218,"tunes":617},"p-storage-1",{"text":616},"Объектное хранилище должно различать глобальные, привязанные к арендатору и привязанные к пользователю объекты. Префикс папки сам по себе является лишь соглашением об именовании, если политика доступа фактически не ограничивает чтение и запись.",{},{"id":619,"data":620,"type":218,"tunes":622},"p-storage-2",{"text":621},"Более строгие архитектуры могут использовать ключи объектов с учётом арендатора, политики бакетов, отдельные бакеты\u002Fаккаунты или ключи шифрования для конкретного арендатора, когда риск или требования соответствия требуют более сильной изоляции.",{},{"id":624,"data":625,"type":218,"tunes":627},"p-storage-3",{"text":626},"Подписанные URL должны быть авторизованы до выдачи и ограничены точным объектом и операцией. Наличие идентификатора объекта само по себе не должно предоставлять доступ между арендаторами.",{},{"id":629,"data":630,"type":42,"tunes":632},"h-queues",{"text":631,"level":247},"Фоновые задачи и очереди могут нарушить изоляцию",{},{"id":634,"data":635,"type":218,"tunes":637},"p-queue-1",{"text":636},"Асинхронные задачи часто покидают исходный контекст HTTP-запроса, что затрудняет корректную передачу арендатора. Сообщение в очереди, содержащее tenantId, не является достаточным доказательством того, что производитель был авторизован.",{},{"id":639,"data":640,"type":218,"tunes":642},"p-queue-2",{"text":641},"Воркер должен нести проверенную идентичность сервиса\u002Fпользователя или доверенный конверт задачи, заново устанавливать контекст арендатора и повторно авторизовывать значимые операции на границе потребителя.",{},{"id":644,"data":645,"type":218,"tunes":647},"p-queue-3",{"text":646},"Изоляция арендаторов также включает доступность. Один арендатор не должен иметь возможности монополизировать общие воркеры, очереди, пулы соединений или вычислительные ресурсы способами, которые существенно ухудшают работу других арендаторов.",{},{"id":649,"data":650,"type":42,"tunes":652},"h-search",{"text":651,"level":247},"Поиск и RAG нуждаются в извлечении с учётом арендатора",{},{"id":654,"data":655,"type":218,"tunes":657},"p-search-1",{"text":656},"Мультитенантный ИИ вводит ещё одну копию проблемы изоляции. Документы могут быть разбиты на фрагменты, преобразованы в эмбеддинги и сохранены в векторном индексе после приёма.",{},{"id":659,"data":660,"type":218,"tunes":662},"p-search-2",{"text":661},"Текущее руководство OWASP по безопасности RAG утверждает, что контроль доступа должен применяться во время извлечения и что фрагменты от Арендатора A не должны извлекаться запросами от Арендатора B. Нельзя просто предполагать, что разрешения на уровне документа автоматически сохраняются при разбиении на фрагменты.",{},{"id":664,"data":665,"type":218,"tunes":667},"p-search-3",{"text":666},"Таким образом, векторный индекс нуждается в метаданных арендатора\u002Fдоступа или физически\u002Fлогически разделённых коллекциях в соответствии с архитектурой изоляции. Фильтры извлечения должны применяться до того, как неавторизованный контент сможет попасть в контекст модели.",{},{"id":669,"data":670,"type":226,"tunes":673},"rag-rule",{"body":671,"title":672,"variant":233},"Не извлекайте фрагменты между арендаторами и затем не инструктируйте языковую модель игнорировать их. Как только защищённые данные попадают в контекст модели, граница изоляции уже нарушена.","Модель никогда не должна быть фильтром арендатора",{},{"id":675,"data":676,"type":42,"tunes":678},"h-derived",{"text":677,"level":247},"Производные данные наследуют чувствительность арендатора",{},{"id":680,"data":681,"type":218,"tunes":683},"p-derived-1",{"text":682},"Эмбеддинги, поисковые индексы, миниатюры, сгенерированные резюме, кэши, строки аналитики и ответы ИИ являются производными от исходных данных. Их область арендатора должна следовать за источником, если только явное преобразование не создаёт законный общий\u002Fглобальный артефакт.",{},{"id":685,"data":686,"type":218,"tunes":688},"p-derived-2",{"text":687},"Удаление и отключение поэтому должны распространяться за пределы канонической строки. Удаление документа арендатора с сохранением доступных для поиска фрагментов или кэшированных резюме может сохранить межарендаторское или послерetенционное воздействие.",{},{"id":690,"data":691,"type":42,"tunes":693},"h-shared",{"text":692,"level":247},"Не всё принадлежит арендатору",{},{"id":695,"data":696,"type":218,"tunes":698},"p-shared-1",{"text":697},"Мультитенантные платформы часто имеют намеренно глобальные ресурсы: таксономии продуктов, публичные шаблоны, системные разрешения, определения функций или публичный контент.",{},{"id":700,"data":701,"type":218,"tunes":703},"p-shared-2",{"text":702},"Самая безопасная модель — это явная классификация: глобальная, ограниченная арендатором, ограниченная пользователем или явно кросс-арендаторская. Именно неоднозначные ресурсы становятся отправной точкой случайной утечки.",{},{"id":705,"data":706,"type":218,"tunes":708},"p-shared-3",{"text":707},"У намеренно общего объекта должна быть документированная причина быть глобальным, а не просто отсутствие привязки к арендатору.",{},{"id":710,"data":711,"type":42,"tunes":713},"h-platform-admin",{"text":712,"level":247},"Администраторы платформы требуют иной модели полномочий",{},{"id":715,"data":716,"type":218,"tunes":718},"p-platform-1",{"text":717},"Оператору платформы может потребоваться проверять несколько арендаторов для поддержки, соответствия требованиям или инфраструктурных операций. Моделирование этого как обычного ADMIN арендатора со случайным глобальным доступом к базе данных ослабляет как безопасность, так и возможность аудита.",{},{"id":720,"data":721,"type":218,"tunes":723},"p-platform-2",{"text":722},"Лучший дизайн использует отдельную идентичность платформы или явное кросс-арендаторское разрешение, усиленную аутентификацию, ограничение цели, детальный аудит и, где это уместно, элементы управления одобрением или экстренным доступом.",{},{"id":725,"data":726,"type":218,"tunes":728},"p-platform-3",{"text":727},"Таким образом, кросс-арендаторский доступ должен быть именованной возможностью, а не отсутствием фильтра арендатора.",{},{"id":730,"data":731,"type":42,"tunes":733},"h-abac",{"text":732,"level":247},"RBAC можно комбинировать с атрибутами",{},{"id":735,"data":736,"type":218,"tunes":738},"p-abac-1",{"text":737},"Некоторые решения зависят не только от роли. Членство в арендаторе, регион, владелец ресурса, уровень подписки, время, членство в проекте или классификация данных — всё это может влиять на доступ.",{},{"id":740,"data":741,"type":218,"tunes":743},"p-abac-2",{"text":742},"RBAC и ABAC не являются взаимоисключающими. Текущее руководство AWS по мультиарендаторской авторизации рассматривает RBAC, ABAC и гибридные модели. Роль может определять широкую ответственность, в то время как атрибуты ограничивают, к какому конкретному экземпляру ресурса можно получить доступ.",{},{"id":745,"data":746,"type":218,"tunes":748},"p-abac-3",{"text":747},"Ключевое архитектурное правило остаётся неизменным: не кодируйте изоляцию арендаторов только как случайное имя роли, если идентичность арендатора является первостепенной границей ресурса.",{},{"id":750,"data":751,"type":42,"tunes":753},"h-matrix",{"text":752,"level":247},"Решения об авторизации как минимум двумерны",{},{"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],"Субъект","Разрешение роли","Отношение арендатора","Решение",[764,765,766,767],"Алиса","orders.read","Заказ принадлежит арендатору Алисы","Разрешить",[764,765,769,770],"Заказ принадлежит другому арендатору","Запретить",[764,772,766,773],"orders.write","Разрешить, если роль включает запись",[764,772,769,770],[776,777,778,779],"Поддержка платформы","support.cross_tenant.read","Явная область поддержки + аудируемый целевой арендатор","Потенциально разрешить в рамках политики платформы",[781,782,783,784],"Фоновый обработчик","orders.process","Доверенная область сервиса для арендатора задания","Разрешить только для подтверждённого арендатора задания",{},{"id":787,"data":788,"type":42,"tunes":790},"h-implementation",{"text":789,"level":247},"Свидетельство оригинальной реализации: Aaasaasa AI CMS",{},{"id":792,"data":793,"type":226,"tunes":796},"impl-note",{"body":794,"title":795,"variant":240},"Aaasaasa AI CMS содержит конкретную реализацию RBAC с ограничением по арендатору. Это полезное свидетельство того, как авторизация ролей и область арендатора могут быть объединены, но это не должно представляться как доказательство того, что каждый уровень хранения, кэша или инфраструктуры имеет полную изоляцию арендаторов.","Свидетельство оригинальной реализации",{},{"id":798,"data":799,"type":218,"tunes":801},"p-impl-1",{"text":800},"Сервис RBAC определяет типизированные коды разрешений, такие как cms.content.read, shop.orders.write, billing.reconcile и users.roles. Системные роли отображают эти разрешения в именованные наборы ответственности.",{},{"id":803,"data":804,"type":218,"tunes":806},"p-impl-2",{"text":805},"Записи ролей создаются и разрешаются с tenantId. Системные роли обновляются или вставляются с использованием составной идентичности арендатор\u002Fкод, а список ролей фильтруется по арендатору.",{},{"id":808,"data":809,"type":218,"tunes":811},"p-impl-3",{"text":810},"Обновление и удаление роли сначала разрешают роль, используя как ID роли, так и ID арендатора. Назначения ролей пользователям также сохраняются и заменяются в контексте текущего арендатора.",{},{"id":813,"data":814,"type":218,"tunes":816},"p-impl-4",{"text":815},"Разрешение разрешений читает явные назначения ролей пользователям с областью, ограниченной как tenantId, так и userId. Это предотвращает автоматическое превращение назначения роли одного арендатора в назначение роли другого арендатора.",{},{"id":818,"data":819,"type":218,"tunes":821},"p-impl-5",{"text":820},"На уровне API административные маршруты RBAC разрешают контекст тенанта перед созданием или изменением ролей. Это правильное направление: администрирование разрешений само должно учитывать мультитенантность.",{},{"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],"Наблюдаемый шаблон реализации","Значение для безопасности",[830,831],"Типизированные коды разрешений","Словарь операций RBAC явный",[833,834],"Сопоставления системных ролей → разрешений","Роли агрегируют разрешения, а не жестко кодируют пользователей",[836,837],"Идентичность роли tenantId_code","Одна и та же логическая роль может существовать отдельно для каждого тенанта",[839,840],"Поиск роли использует id + tenantId","Изменение роли ограничено тенантом",[842,843],"Связь пользователь-роль хранит tenantId","Членство не выводится глобально только из роли",[845,846],"Разрешение разрешений использует tenantId + userId","Авторизация оценивается внутри контекста тенанта",{},{"id":849,"data":850,"type":226,"tunes":853},"impl-boundary",{"body":851,"title":852,"variant":233},"RBAC с ограничением по тенанту — это один слой. Полная изоляция тенантов должна также охватывать все поиски ресурсов, принадлежащих тенанту, базы данных, кэши, файлы, поисковые\u002Fвекторные индексы, фоновые задачи, интеграции и операционные пути. Доказательства из репозитория здесь подтверждают шаблон проектирования RBAC\u002Fограничения по тенанту, а не заявление о независимо проверенной изоляции SaaS.","Что эти доказательства не доказывают",{},{"id":855,"data":856,"type":42,"tunes":858},"h-ai",{"text":857,"level":247},"Почему это различие еще важнее для ИИ-агентов",{},{"id":860,"data":861,"type":218,"tunes":863},"p-ai-1",{"text":862},"ИИ-агенты могут превратить ошибку в разрешениях в последовательность действий. Если агенту дан широкий инструмент orders.read без принудительного ограничения по тенанту, сбой рассуждения или внедрение промпта может вызвать межтенантные чтения на машинной скорости.",{},{"id":865,"data":866,"type":218,"tunes":868},"p-ai-2",{"text":867},"Описания инструментов агента могут упоминать ограничения тенанта, но принудительное применение все равно должно происходить в доверенном слое среды выполнения\u002Fсервиса\u002Fданных. Инструкции на естественном языке не являются границей авторизации.",{},{"id":870,"data":871,"type":218,"tunes":873},"p-ai-3",{"text":872},"То же самое относится к RAG: агент может иметь разрешение на использование инструмента поиска, но серверная часть поиска все равно должна предотвращать возврат запросом Тенанта A фрагментов Тенанта B.",{},{"id":875,"data":876,"type":42,"tunes":878},"h-tests",{"text":877,"level":247},"Тестируйте RBAC и изоляцию тенантов отдельно",{},{"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],"Семейство тестов","Что оно должно доказать",[887,888],"Тест понижения роли","Пользователь без разрешения не может выполнить операцию даже внутри своего тенанта",[890,891],"Тест объекта другого тенанта","Пользователь с правильной ролью все равно не может получить доступ к тому же типу ресурса в другом тенанте",[893,894],"Подмена идентификаторов","Изменение ID объекта\u002Fтенанта не пересекает границы области",[896,897],"Тест списочных\u002Fмассовых эндпоинтов","Широкие запросы возвращают только авторизованные данные тенанта",[899,900],"Тест повторного использования кэша","Два тенанта, использующие переиспользуемые процессы\u002Fсоединения, никогда не получают кэшированное состояние друг друга",[902,903],"Тест роли запроса RLS","Роль производственного запроса не может обойти политики строк",[905,906],"Тест асинхронного воркера","Контекст тенанта сохраняется при постановке в очередь и повторно проверяется при потреблении",[908,909],"Тест векторного поиска","Запрос Тенанта A никогда не извлекает фрагменты Тенанта B",[911,912],"Тест администратора платформы","Межтенантная возможность является явной, узкой и поддающейся аудиту",[914,915],"Тест отключения","Данные тенанта и производные индексы\u002Fкэши удаляются в соответствии с политикой",{},{"id":918,"data":919,"type":218,"tunes":921},"p-tests-1",{"text":920},"Руководство OWASP по регрессии авторизации специально выделяет тесты границ между тенантами, потому что изменения кода в кэшировании, запросах или общих сервисах могут незаметно нарушить изоляцию, даже если тесты ролей продолжают проходить.",{},{"id":923,"data":924,"type":42,"tunes":926},"h-failures",{"text":925,"level":247},"Распространенные режимы отказа",{},{"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],"Режим отказа","Почему он не работает",[935,936],"Проверка роли, но не тенанта","Действительная роль становится межтенантным полномочием",[938,939],"Доверие tenant ID из запроса","Клиент контролирует селектор изоляции",[941,942],"Ограничение UI, но не API","Скрытые кнопки не защищают серверные ресурсы",[944,945],"Эндпоинт деталей с учетом тенанта, эндпоинт списка без области","Массовые чтения раскрывают другие тенанты",[947,948],"Фильтр тенанта в большинстве запросов","Один забытый путь нарушает границу",[950,951],"Глобальные ключи кэша","Правильная изоляция базы данных обходится кэшированными данными",[953,954],"Общий векторный индекс без принудительных фильтров метаданных","RAG извлекает фрагменты другого тенанта",[956,957],"tenant ID сообщения очереди рассматривается как авторизация","Поддельная или неправильно созданная задача может пересечь границу тенанта",[959,960],"Администратор платформы смоделирован как обычный ADMIN","Межтенантная власть становится неявной и трудной для аудита",[962,963],"Роль копируется глобально между членствами в тенантах","Пользователь получает разрешения в тенантах, где он никогда не был назначен",[965,966],"Отдельные базы данных, но общий привилегированный учетный данные","Приложение все еще может пересекать базы данных, если его учетные данные слишком широки",[968,969],"RLS с ролью запроса BYPASSRLS","Политика базы данных существует, но не защищает фактический путь запроса",[971,972],"Случайные UUID рассматриваются как изоляция","Трудно угадываемые идентификаторы уменьшают перебор, но не авторизуют доступ",{},{"id":975,"data":976,"type":42,"tunes":978},"h-misconceptions",{"text":977,"level":247},"Распространенные заблуждения",{},{"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],"Заблуждение","Исправление",[987,988],"«RBAC обеспечивает изоляцию тенантов».","RBAC управляет разрешениями; изоляция также требует ограничения области тенанта\u002Fресурса.",[990,991],"«Если пользователь администратор, проверки тенанта не нужны».","Полномочия администратора все равно должны иметь явную область.",[993,994],"«Tenant ID в JWT достаточно».","Он может быть доверенным входом только если проверен и последовательно применяется ко всем защищенным путям ресурсов.",[996,997],"«Отдельные базы данных устраняют требования авторизации».","Пользователям все еще нужны разрешения на уровне операций внутри их тенанта.",[999,1000],"«Столбец tenant_id означает, что система изолирована».","Поле помогает только если пути доступа его применяют.",[1002,1003],"«UUID предотвращают межтенантный доступ».","Непредсказуемые идентификаторы — это эшелонированная защита, а не авторизация.",[1005,1006],"«RLS означает, что код приложения не нуждается в проверках безопасности».","Авторизация приложения, правильные роли БД и покрытие политик все еще важны.",[1008,1009],"«Одна общая векторная БД небезопасна».","Она может быть безопасной, если изоляция может быть обеспечена и проверена; физическое разделение — один из вариантов, а не единственный.",[1011,1012],"«Поддержке платформы нужен глобальный ADMIN».","Межтенантная поддержка должна быть отдельным, ограниченным и поддающимся аудиту полномочием.",[1014,1015],"«Внутренние сервисы могут пропускать проверки тенанта».","Внутренние пути все еще могут быть скомпрометированы или неправильно настроены и должны сохранять контекст тенанта.",{},{"id":1018,"data":1019,"type":42,"tunes":1021},"h-design",{"text":1020,"level":247},"Практическая последовательность проектирования",{},{"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. Определите владение тенантом","Классифицируйте, какие сущности и ресурсы являются глобальными, ограниченными тенантом, ограниченными пользователем или намеренно межтенантными.",{"label":1030,"description":1031},"2. Определите операции","Создайте явные разрешения для чтения, записи, публикации, утверждения, администрирования и других бизнес-действий.",{"label":1033,"description":1034},"3. Определите роли","Группируйте разрешения в соответствии с обязанностями, не встраивая случайную глобальную область.",{"label":1036,"description":1037},"4. Определите область членства","Привяжите назначения ролей к контексту тенанта\u002Fрабочего пространства\u002Fпроекта, в котором они применяются.",{"label":1039,"description":1040},"5. Разрешите доверенный контекст тенанта","Выводите идентичность тенанта из аутентифицированного, проверенного сервером членства или авторизации сервиса.",{"label":1042,"description":1043},"6. Обеспечьте владение ресурсами","Применяйте область тенанта на каждой границе данных\u002Fсервиса, принадлежащих тенанту.",{"label":1045,"description":1046},"7. Добавьте эшелонированную защиту","Используйте RLS, отдельные учетные данные, схемы\u002Fбазы данных, политики хранения или движки политик там, где риск это оправдывает.",{"label":1048,"description":1049},"8. Переносите область через производные системы","Сохраняйте метаданные тенанта в кэше, поиске, векторных индексах, очередях, файлах и аналитике.",{"label":1051,"description":1052},"9. Моделируйте межтенантные операции явно","Отделяйте администрирование платформы и идентичности сервисов от обычных ролей тенанта.",{"label":1054,"description":1055},"10. Тестируйте обе оси","Запускайте негативные тесты для отсутствующего разрешения и для неправильного тенанта независимо.",{"label":1057,"description":1058},"11. Аудит тенанта + разрешения вместе","Регистрируйте, кто действовал, в каком тенанте, над какой целью и под какими полномочиями.",{"label":1060,"description":1061},"12. Повторно тестируйте после изменений схемы\u002Fсреды выполнения","Изоляция может нарушиться при введении новых таблиц, кэшей, очередей или путей поиска.","Проектируйте разрешения и изоляцию как отдельные измерения",{},{"id":1065,"data":1066,"type":42,"tunes":1068},"h-checklist",{"text":1067,"level":247},"Контрольный список RBAC + изоляция тенантов",{},{"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],"Ожидаемый ответ",[1076,1077],"Кто является субъектом?","Аутентифицированная идентичность пользователя\u002Fсервиса\u002Fагента",[1079,1080],"Какой контекст тенанта применяется?","Проверенное сервером членство или область сервиса",[1082,1083],"Какая операция запрашивается?","Типизированное разрешение или действие политики",[1085,1086],"Имеет ли субъект это разрешение?","Решение роли\u002Fполитики",[1088,1089],"Кто владеет целевым ресурсом?","Явная классификация тенанта\u002Fглобального\u002Fпользовательского",[1091,1092],"Соответствует ли область ресурса полномочиям?","Поиск\u002Fполитика с учетом тенанта",[1094,1095],"Может ли хранилище обойти проверки приложения?","Решение об эшелонированной защите задокументировано",[1097,1098],"Безопасны ли кэши для тенантов?","Ключи\u002Fпространства имен и авторизация сохраняют область тенанта",[1100,1101],"Безопасны ли файлы\u002Fблобы для тенантов?","Политика объектов и выдача подписанных URL обеспечивают область",[1103,1104],"Безопасны ли асинхронные задачи для тенантов?","Проверенный контекст распространяется и повторно проверяется",[1106,1107],"Безопасны ли RAG\u002Fпоиск для тенантов?","Изоляция метаданных\u002Fколлекций обеспечивается до контекста модели",[1109,1110],"Явны ли межтенантные администраторы?","Отдельные полномочия, средства контроля и аудит",[1112,1113],"Могут ли обычные учетные данные обойти изоляцию?","Нет, или строго задокументированный исключительный путь",[1115,1116],"Автоматизированы ли негативные межтенантные тесты?","Да для каждого соответствующего слоя доступа",{},{"id":1119,"data":1120,"type":42,"tunes":1122},"h-edge",{"text":1121,"level":247},"Граничные случаи и ограничения",{},{"id":1124,"data":1125,"type":218,"tunes":1127},"p-edge-1",{"text":1126},"Пользователь может принадлежать нескольким тенантам. Поэтому текущий тенант должен быть явным контекстом выполнения, а не постоянно выводиться из учетной записи пользователя.",{},{"id":1129,"data":1130,"type":218,"tunes":1132},"p-edge-2",{"text":1131},"Некоторые ресурсы намеренно используются совместно выбранными тенантами, например пространства для совместной работы или данные консорциума. Это требует явной модели совместного использования; попытка представить, что ресурс принадлежит одному тенанту, и добавление исключений позже обычно создает неоднозначную авторизацию.",{},{"id":1134,"data":1135,"type":218,"tunes":1137},"p-edge-3",{"text":1136},"Изоляция от шумных соседей связана, но отличается от изоляции конфиденциальности. Тенант может никогда не видеть данные другого тенанта, но при этом исчерпать общие ресурсы CPU, емкость очереди или подключения к базе данных. Поэтому ограничения скорости и квоты ресурсов могут учитывать тенанта как границу доступности.",{},{"id":1139,"data":1140,"type":218,"tunes":1142},"p-edge-4",{"text":1141},"Физическая изоляция не является автоматически безопасной, если учетные данные плоскости управления или административные пути могут пересекать границы. Логическая изоляция не является автоматически слабой, если политики централизованно применяются, основаны на принципе наименьших привилегий и тщательно протестированы.",{},{"id":1144,"data":1145,"type":218,"tunes":1147},"p-edge-5",{"text":1146},"Требования к изоляции тенантов могут различаться в зависимости от класса данных. Публичные данные каталога, записи о выставлении счетов и частные документы ИИ могут оправдывать различные границы хранения и шифрования внутри одного SaaS-продукта.",{},{"id":1149,"data":1150,"type":42,"tunes":1152},"h-change",{"text":1151,"level":247},"Что могло бы изменить этот ответ?",{},{"id":1154,"data":1155,"type":218,"tunes":1157},"p-change-1",{"text":1156},"Конкретная реализация меняется в зависимости от архитектуры: бессерверные API, Kubernetes, PostgreSQL, объектное хранилище, векторные базы данных и движки политик предоставляют разные примитивы изоляции.",{},{"id":1159,"data":1160,"type":218,"tunes":1162},"p-change-2",{"text":1161},"Требуемая степень также меняется в зависимости от регулирования, контрактов с клиентами, чувствительности данных, модели угроз и операционного масштаба. Некоторые тенанты могут оправдывать изолированные базы данных или инфраструктуру, в то время как другие используют общие ресурсы.",{},{"id":1164,"data":1165,"type":218,"tunes":1167},"p-change-3",{"text":1166},"Концептуальное различие не меняется: разрешение на выполнение операции — это не то же самое, что разрешение на пересечение границы тенанта.",{},{"id":1169,"data":1170,"type":42,"tunes":1172},"h-related",{"text":1171,"level":247},"Связанные канонические знания",{},{"id":1174,"data":1175,"type":218,"tunes":1177},"p-related-1",{"text":1176},"S01 является предварительным условием безопасности для архитектуры корпоративного ИИ и управления ИИ. Как только инструменты ИИ, RAG или агенты работают с мультитенантными данными, идентичность тенанта должна проходить через извлечение, выполнение инструментов, память, кэши и трассировки аудита.",{},{"id":1179,"data":1180,"type":218,"tunes":1182},"p-related-2",{"text":1181},"Это также напрямую связано с агентным ИИ: возможности инструментов и разрешения ролей должны быть ограничены владением тенанта, прежде чем агент сможет читать или изменять бизнес-ресурсы.",{},{"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: объяснение стека протоколов агентов","Совместимость протоколов не заменяет авторизацию или изоляцию тенантов. Обнаружение возможностей и бизнес-полномочия остаются отдельными архитектурными вопросами.","Читать статью о стеке протоколов","referralArticle",{},{"id":1193,"data":1194,"type":218,"tunes":1196},"p-related-3",{"text":1195},"Для RAG изоляция тенантов должна применяться до того, как защищенные фрагменты попадут в контекст модели.",{},{"id":1198,"data":1199,"type":1190,"tunes":1204},"ref-rag",{"url":1200,"title":1201,"excerpt":1202,"ctaLabel":1203},"https:\u002F\u002Fstajic.de\u002Fru\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","Что такое RAG? Самое простое объяснение того, как это работает","Основа извлечения для понимания того, где должны применяться фильтрация источников с учетом тенанта и изоляция векторного хранилища.","Читать основы RAG",{},{"id":1206,"data":1207,"type":42,"tunes":1209},"h-faq",{"text":1208,"level":247},"Часто задаваемые вопросы",{},{"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 определяет, какие операции может выполнять субъект. Изоляция тенантов определяет, к ресурсам какого тенанта эти операции могут получить доступ. Безопасные мультитенантные приложения обычно нуждаются в обоих.","В чем разница между RBAC и изоляцией тенантов?",{"id":1219,"answer":1220,"question":1221},"faq2","Нет. ADMIN должен иметь явную область действия. Администратор тенанта обычно имеет широкие разрешения только внутри этого тенанта, в то время как кросс-тенантное администрирование платформы должно моделироваться отдельно.","Роль ADMIN автоматически разрешает доступ ко всем тенантам?",{"id":1223,"answer":1224,"question":1225},"faq3","Нет. Аутентификация подтверждает личность. Авторизация контролирует разрешенные действия. Изоляция тенантов дополнительно предотвращает доступ этих действий к ресурсам неправильного тенанта.","Достаточно ли аутентификации для изоляции тенантов?",{"id":1227,"answer":1228,"question":1229},"faq4","Это может быть одним из входных данных для контекста тенанта, но сервер должен проверять текущее членство\u002Fполномочия и применять область действия на границах защищенных ресурсов. Одного утверждения недостаточно для замены средств изоляции.","Следует ли хранить tenantId в JWT?",{"id":1231,"answer":1232,"question":1233},"faq5","Не обязательно. Модели изоляции с общей таблицей, RLS, схемой, базой данных, инфраструктурой и гибридные модели могут быть допустимы в зависимости от рисков и операционных требований.","Нужна ли отдельная база данных для каждого тенанта?",{"id":1235,"answer":1236,"question":1237},"faq6","RLS может обеспечить надежную эшелонированную защиту, но правильные роли базы данных, контекст запроса, покрытие политик и авторизация на уровне приложения по-прежнему важны.","Может ли PostgreSQL RLS заменить фильтры тенантов в коде приложения?",{"id":1239,"answer":1240,"question":1241},"faq7","Область действия тенанта\u002Fдоступа должна применяться во время извлечения, чтобы неавторизованные фрагменты никогда не попадали в контекст модели. Сохраняйте метаданные доступа при разбиении на фрагменты и индексации.","Как RAG должен обеспечивать изоляцию тенантов?",{"id":1243,"answer":1244,"question":1245},"faq8","Да. Это распространено в B2B SaaS и является веской причиной для привязки назначений ролей к членству в тенанте, а не для рассмотрения ролей как глобально привязанных к пользователю.","Может ли один пользователь иметь разные роли в разных тенантах?",{"id":1247,"answer":1248,"question":1249},"faq9","Используйте негативные кросс-тенантные тесты: создайте как минимум два тенанта, дайте пользователю действительные разрешения в одном тенанте, затем докажите, что каждый защищенный путь запрещает доступ к ресурсам другого тенанта.","Какой лучший тест для изоляции тенантов?","RBAC vs изоляция тенантов: FAQ",{},{"id":1253,"data":1254,"type":42,"tunes":1256},"h-glossary",{"text":1255,"level":247},"Глоссарий",{},{"id":1258,"data":1259,"type":1258,"tunes":1306},"glossary",{"title":1260,"entries":1261},"Ключевые термины безопасности мультитенантных систем",[1262,1264,1267,1271,1274,1278,1282,1286,1290,1294,1298,1302],{"term":395,"anchor":394,"definition":1263},"Управление доступом на основе ролей: модель авторизации, которая связывает разрешения с ролями и назначает пользователей или субъектов этим ролям.",{"term":1265,"anchor":397,"definition":1266},"Тенант","Клиент, организация, рабочее пространство или иной изолированный логический потребитель общей мультитенантной системы.",{"term":1268,"anchor":1269,"definition":1270},"Изоляция тенантов","tenant-isolation","Механизмы, которые не позволяют одному тенанту получать доступ к ресурсам другого тенанта, изменять их или получать их в общей системе.",{"term":415,"anchor":1272,"definition":1273},"authentication","Проверка подлинности пользователя, сервиса или иного субъекта.",{"term":1275,"anchor":1276,"definition":1277},"Авторизация","authorization","Процесс принятия решения о том, может ли субъект выполнить запрошенную операцию над ресурсом.",{"term":1279,"anchor":1280,"definition":1281},"Разрешение","permission","Определённая допустимая операция или возможность, например orders.read или users.write.",{"term":1283,"anchor":1284,"definition":1285},"Роль","role","Именованная группа разрешений, связанная с ответственностью или функцией.",{"term":1287,"anchor":1288,"definition":1289},"ABAC","abac","Управление доступом на основе атрибутов: авторизация на основе атрибутов субъекта, ресурса, действия или среды.",{"term":1291,"anchor":1292,"definition":1293},"Безопасность на уровне строк","row-level-security","Механизм политик базы данных, который ограничивает, какие строки роль или сессия базы данных может читать или изменять.",{"term":1295,"anchor":1296,"definition":1297},"Межтенантный доступ","cross-tenant-access","Любой путь доступа, при котором субъект, действующий в контексте одного тенанта, достигает ресурсов, принадлежащих другому тенанту.",{"term":1299,"anchor":1300,"definition":1301},"Администратор платформы","platform-administrator","Привилегированная операционная учётная запись с явно смоделированными полномочиями, которые могут охватывать несколько тенантов.",{"term":1303,"anchor":1304,"definition":1305},"Контекст тенанта","tenant-context","Проверенная область тенанта, в рамках которой выполняется текущий запрос, задача или операция агента.",{},{"id":1308,"data":1309,"type":42,"tunes":1311},"h-conclusion",{"text":1310,"level":247},"Заключение",{},{"id":1313,"data":1314,"type":218,"tunes":1316},"p-conclusion-1",{"text":1315},"RBAC и изоляция тенантов — это взаимодополняющие, а не конкурирующие механизмы безопасности. RBAC структурирует операционные разрешения; изоляция тенантов ограничивает границу ресурсов, внутри которой эти разрешения могут применяться.",{},{"id":1318,"data":1319,"type":218,"tunes":1321},"p-conclusion-2",{"text":1320},"Поэтому надёжный мультитенантный запрос требует большего, чем «у пользователя есть роль ADMIN». Ему нужны проверенный субъект, проверенный контекст тенанта, разрешённая операция, цель в области тенанта и принудительное применение на каждом уровне ресурсов, который может содержать данные, принадлежащие тенанту.",{},{"id":1323,"data":1324,"type":218,"tunes":1326},"p-conclusion-3",{"text":1325},"Самое короткое надёжное правило таково: авторизуйте действие, затем изолируйте область — и никогда не предполагайте, что одно доказывает другое.",{},{"id":1328,"data":1329,"type":42,"tunes":1331},"h-sources",{"text":1330,"level":247},"Первоисточники и актуальные рекомендации",{},{"id":1333,"data":1334,"type":218,"tunes":1336},"p-sources-note",{"text":1335},"Приведённые ниже источники подтверждают определение RBAC и актуальные рекомендации по изоляции тенантов. Раздел Aaasaasa AI CMS является оригинальным свидетельством реализации и намеренно ограничен теми шаблонами кода, которые были проверены.",{},{"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","Обзор NIST моделей RBAC и стандарта INCITS RBAC, включая пользователей, роли, разрешения, операции и объекты.","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 — RBAC glossary","Актуальные определения управления доступом на основе ролей в глоссарии NIST как назначения разрешений через роли.",{},{"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 — The isolation mindset","Рекомендации AWS по SaaS, явно разграничивающие аутентификацию\u002Fавторизацию и изоляцию тенантов и рекомендующие общие механизмы изоляции.",{},{"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 — Multi-tenant authorization FAQ","Актуальные рекомендации, объясняющие разницу между авторизацией и изоляцией тенантов в 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 — Multi-tenant design considerations","Актуальные рекомендации по SaaS, разграничивающие изоляцию тенантов и авторизацию и обсуждающие модели политик авторизации с общим и выделенным размещением.",{},{"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 — Multi-Tenant Application Security Cheat Sheet","Актуальные практические рекомендации по контексту тенанта, изоляции баз данных, кэшей, хранилищ, очередей, тестированию и предотвращению межтенантного доступа.",{},{"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 — RAG Security Cheat Sheet","Актуальные рекомендации, требующие контроля доступа во время извлечения и изоляции тенантов для мультитенантных векторных хранилищ.",{},{"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 — Authorization Regression Testing","Актуальные рекомендации по тестированию, включая тесты понижения роли и границ между тенантами.",{},"2.31","RBAC определяет, что пользователь может делать; изоляция тенантов определяет, к ресурсам какого тенанта это действие может получить доступ. Узнайте, почему безопасность многотенантного SaaS требует обеих границ.","\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-and-data",{"id":1433,"name":1434,"slug":1435},57,"Границы данных","data-boundaries",{"id":1437,"name":1438,"slug":1439},64,"Информационная архитектура","information-architecture",{"id":1441,"login":1442,"email":1443,"displayName":1444},"20","rooth8233","aleksandar@stajic.de","Aleksandar Stajić",[1446,2436],{"lang":1447,"title":1448,"content":1449,"contentJson":1450,"excerpt":2435},"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":2434},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,1908,1912,1917,1921,1925,1929,1933,1937,1962,1967,1971,1975,1979,1983,1987,2024,2028,2032,2078,2082,2119,2123,2164,2168,2216,2220,2224,2228,2232,2236,2240,2244,2248,2252,2256,2260,2264,2268,2274,2278,2285,2289,2321,2325,2362,2366,2370,2374,2378,2382,2386,2392,2398,2404,2410,2416,2422,2428],{"id":215,"data":1454,"type":218,"tunes":1456},{"text":1455},"RBAC and tenant isolation solve two different security problems in multi-tenant systems. Role-Based Access Control (RBAC) determines what an authenticated principal is allowed to do, such as read orders, edit products or manage users. Tenant isolation determines which tenant's data, resources and execution context that principal is allowed to access. A user can be correctly authenticated and correctly assigned an RBAC role yet still experience a security failure if the application lets that role operate on another tenant's resources.",{},{"id":221,"data":1458,"type":226,"tunes":1461},{"body":1459,"title":1460,"variant":225},"\u003Cstrong>RBAC answers “what may this identity do?” Tenant isolation answers “inside whose boundary may it do it?”\u003C\u002Fstrong>\u003Cbr>\u003Cbr>A secure multi-tenant application normally needs both. A tenant administrator may have broad permissions, but those permissions should remain constrained to the administrator's tenant unless an explicitly separate platform-level authority exists.","Direct answer",{},{"id":229,"data":1463,"type":226,"tunes":1466},{"body":1464,"title":1465,"variant":233},"Giving a user the role \u003Ccode>ADMIN\u003C\u002Fcode> does not automatically imply “administrator of tenant A only.” The role must be evaluated together with verified tenant context and the target resource's tenant ownership. Otherwise a valid role can become a cross-tenant privilege.","A role is not a tenant boundary",{},{"id":236,"data":1468,"type":226,"tunes":1471},{"body":1469,"title":1470,"variant":240},"The underlying distinction is stable. NIST defines RBAC around users, roles, permissions, operations and objects. Current AWS SaaS guidance explicitly states that authentication and authorization are not equal to tenant isolation, and that a user can be authenticated and authorized while still accessing another tenant's resources if isolation is not separately enforced. OWASP's current Multi-Tenant Security guidance likewise treats tenant isolation as a cross-layer requirement covering APIs, databases, caches, storage, queues and other shared resources.","Current-source note — 8 October 2026",{},{"id":243,"data":1473,"type":248,"tunes":1475},{"title":1474,"maxLevel":246,"minLevel":247},"Contents",{},{"id":251,"data":1477,"type":42,"tunes":1479},{"text":1478,"level":247},"What RBAC really controls",{},{"id":256,"data":1481,"type":218,"tunes":1483},{"text":1482},"RBAC is an authorization model in which permissions are associated with roles and users are assigned to those roles. The role acts as an administrative abstraction between identities and permissions.",{},{"id":261,"data":1485,"type":218,"tunes":1487},{"text":1486},"NIST's classic RBAC work formalizes this around users, roles, permissions, operations and objects. The practical benefit is that an organization can manage authorization through relatively stable job or responsibility roles rather than attaching every permission directly to every user.",{},{"id":266,"data":1489,"type":218,"tunes":1491},{"text":1490},"A role such as EDITOR can therefore mean: may read content, write content and publish content. A role such as ACCOUNTANT may mean: may read billing data, reconcile invoices and approve settlements.",{},{"id":271,"data":1493,"type":42,"tunes":1495},{"text":1494,"level":247},"What tenant isolation really controls",{},{"id":276,"data":1497,"type":218,"tunes":1499},{"text":1498},"Tenant isolation is the set of mechanisms that prevents one tenant from reading, modifying, influencing or accidentally receiving another tenant's resources in a shared system.",{},{"id":281,"data":1501,"type":218,"tunes":1503},{"text":1502},"The protected boundary is broader than database rows. Tenant-specific state can exist in relational tables, object storage, vector indexes, caches, search indexes, queue messages, files, temporary artifacts, background jobs, analytics, rate limits and infrastructure resources.",{},{"id":286,"data":1505,"type":218,"tunes":1507},{"text":1506},"AWS's SaaS guidance makes the distinction explicit: authorization grants access to resources, while tenant isolation ensures those resources cannot cross the wrong tenant boundary even when infrastructure is shared.",{},{"id":291,"data":1509,"type":42,"tunes":1511},{"text":1510,"level":247},"The simplest example",{},{"id":296,"data":1513,"type":218,"tunes":1515},{"text":1514},"Suppose Alice is an administrator for Tenant A and Bob is an administrator for Tenant B. Both users legitimately hold the same ADMIN role.",{},{"id":301,"data":1517,"type":218,"tunes":1519},{"text":1518},"RBAC can correctly conclude that both users may execute an operation such as users.read. But when Alice requests user ID 847, the application must still verify that user 847 belongs to Tenant A.",{},{"id":306,"data":1521,"type":218,"tunes":1523},{"text":1522},"If the API checks only “Alice has ADMIN” and then executes SELECT * FROM users WHERE id = 847, RBAC succeeded while tenant isolation failed.",{},{"id":311,"data":1525,"type":334,"tunes":1546},{"steps":1526,"title":1545,"orientation":333},[1527,1530,1533,1536,1539,1542],{"label":1528,"description":1529},"1. Authenticate principal","Establish who the user, service or agent is.",{"label":1531,"description":1532},"2. Resolve verified tenant context","Determine which tenant context applies from trusted server-side identity\u002Fmembership information.",{"label":1534,"description":1535},"3. Resolve permission","Evaluate whether the principal's role or policy permits the requested operation.",{"label":1537,"description":1538},"4. Scope the target resource","Verify that the target object belongs to the permitted tenant or explicitly shared scope.",{"label":1540,"description":1541},"5. Enforce at the access boundary","Perform the database, cache, storage, queue or service operation with tenant constraints applied.",{"label":1543,"description":1544},"6. Audit both dimensions","Record principal, tenant, operation, target and result so cross-tenant attempts are visible.","A correct multi-tenant authorization decision",{},{"id":337,"data":1548,"type":42,"tunes":1550},{"text":1549,"level":247},"Where the simple example stops",{},{"id":342,"data":1552,"type":218,"tunes":1554},{"text":1553},"Real systems often contain several classes of identity: tenant users, platform administrators, background workers, integrations, agents and cross-tenant operational services. Some of these legitimately cross tenant boundaries.",{},{"id":347,"data":1556,"type":218,"tunes":1558},{"text":1557},"That does not remove the need for isolation. It means cross-tenant authority must be explicit, narrow and separately auditable rather than emerging accidentally from a global role or unscoped database connection.",{},{"id":352,"data":1560,"type":218,"tunes":1562},{"text":1561},"Tenant isolation can also vary by layer. A product may share application servers while separating databases, or use a shared database with row-level policies while giving premium tenants isolated storage or compute. There is no single universal isolation topology.",{},{"id":357,"data":1564,"type":42,"tunes":1566},{"text":1565,"level":247},"RBAC vs tenant isolation",{},{"id":362,"data":1568,"type":399,"tunes":1593},{"rows":1569,"title":1588,"layout":391,"columns":1589},[1570,1573,1576,1579,1582,1585],{"id":366,"label":1571,"values":1572},"Primary question",[369,369],{"id":371,"label":1574,"values":1575},"Typical unit",[369,369],{"id":375,"label":1577,"values":1578},"Example",[369,369],{"id":379,"label":1580,"values":1581},"Typical failure",[369,369],{"id":383,"label":1583,"values":1584},"Typical implementation",[369,369],{"id":387,"label":1586,"values":1587},"Can it exist alone?",[369,369],"Two different security dimensions",[1590,1591],{"id":394,"label":395},{"id":397,"label":1592},"Tenant isolation",{},{"id":402,"data":1595,"type":42,"tunes":1597},{"text":1596,"level":247},"Authentication, authorization and isolation are three different checks",{},{"id":407,"data":1599,"type":391,"tunes":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":1907},{"content":1883,"stretched":43,"withHeadings":14},[1884,1889,1893,1896,1898,1899,1903],[1885,1886,1887,1888],"Principal","Role permission","Tenant relationship","Decision",[1890,765,1891,1892],"Alice","Order belongs to Alice's tenant","Allow",[1890,765,1894,1895],"Order belongs to another tenant","Deny",[1890,772,1891,1897],"Allow if role includes write",[1890,772,1894,1895],[1900,777,1901,1902],"Platform support","Explicit support scope + audited target tenant","Potentially allow under platform policy",[1904,782,1905,1906],"Background worker","Trusted service scope for job tenant","Allow only for verified job tenant",{},{"id":787,"data":1909,"type":42,"tunes":1911},{"text":1910,"level":247},"Original implementation evidence: Aaasaasa AI CMS",{},{"id":792,"data":1913,"type":226,"tunes":1916},{"body":1914,"title":1915,"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":1918,"type":218,"tunes":1920},{"text":1919},"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":1922,"type":218,"tunes":1924},{"text":1923},"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":1926,"type":218,"tunes":1928},{"text":1927},"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":1930,"type":218,"tunes":1932},{"text":1931},"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":1934,"type":218,"tunes":1936},{"text":1935},"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":1938,"type":391,"tunes":1961},{"content":1939,"stretched":43,"withHeadings":14},[1940,1943,1946,1949,1952,1955,1958],[1941,1942],"Observed implementation pattern","Security meaning",[1944,1945],"Typed permission codes","RBAC operation vocabulary is explicit",[1947,1948],"System role → permission maps","Roles aggregate permissions rather than hard-coding users",[1950,1951],"tenantId_code role identity","Same logical role can exist separately per tenant",[1953,1954],"Role lookup uses id + tenantId","Role mutation is tenant-scoped",[1956,1957],"User-role relation stores tenantId","Membership is not globally inferred from role alone",[1959,1960],"Permission resolution uses tenantId + userId","Authorization is evaluated inside tenant context",{},{"id":849,"data":1963,"type":226,"tunes":1966},{"body":1964,"title":1965,"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":1968,"type":42,"tunes":1970},{"text":1969,"level":247},"Why this distinction matters even more for AI agents",{},{"id":860,"data":1972,"type":218,"tunes":1974},{"text":1973},"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":1976,"type":218,"tunes":1978},{"text":1977},"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":1980,"type":218,"tunes":1982},{"text":1981},"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":1984,"type":42,"tunes":1986},{"text":1985,"level":247},"Test RBAC and tenant isolation separately",{},{"id":880,"data":1988,"type":391,"tunes":2023},{"content":1989,"stretched":43,"withHeadings":14},[1990,1993,1996,1999,2002,2005,2008,2011,2014,2017,2020],[1991,1992],"Test family","What it should prove",[1994,1995],"Role demotion test","A user without a permission cannot perform the operation even inside their own tenant",[1997,1998],"Cross-tenant object test","A user with the correct role still cannot access the same resource type in another tenant",[2000,2001],"Identifier tampering","Changing object\u002Ftenant IDs does not cross scope",[2003,2004],"List\u002Fbulk endpoint test","Broad queries return only authorized tenant data",[2006,2007],"Cache reuse test","Two tenants using reused processes\u002Fconnections never receive each other's cached state",[2009,2010],"RLS request-role test","Production request role cannot bypass row policies",[2012,2013],"Async worker test","Tenant context survives queueing and is revalidated at consumption",[2015,2016],"Vector retrieval test","Tenant A query never retrieves Tenant B chunks",[2018,2019],"Platform-admin test","Cross-tenant capability is explicit, narrow and auditable",[2021,2022],"Offboarding test","Tenant data and derived indexes\u002Fcaches are removed according to policy",{},{"id":918,"data":2025,"type":218,"tunes":2027},{"text":2026},"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":2029,"type":42,"tunes":2031},{"text":2030,"level":247},"Common failure modes",{},{"id":928,"data":2033,"type":391,"tunes":2077},{"content":2034,"stretched":43,"withHeadings":14},[2035,2038,2041,2044,2047,2050,2053,2056,2059,2062,2065,2068,2071,2074],[2036,2037],"Failure mode","Why it fails",[2039,2040],"Check role but not tenant","Valid role becomes cross-tenant authority",[2042,2043],"Trust tenant ID from request","Client controls the isolation selector",[2045,2046],"Scope UI but not API","Hidden buttons do not protect backend resources",[2048,2049],"Tenant-aware detail endpoint, unscoped list endpoint","Bulk reads leak other tenants",[2051,2052],"Tenant filter in most queries","One forgotten path breaks the boundary",[2054,2055],"Global cache keys","Correct database isolation is bypassed by cached data",[2057,2058],"Shared vector index without enforced metadata filters","RAG retrieves another tenant's chunks",[2060,2061],"Queue message tenant ID treated as authorization","Forged or wrongly produced job can cross tenant boundary",[2063,2064],"Platform admin modeled as ordinary ADMIN","Cross-tenant power becomes implicit and difficult to audit",[2066,2067],"Role copied globally across tenant memberships","User receives permissions in tenants where they were never assigned",[2069,2070],"Separate databases but shared privileged credential","Application can still cross databases if its credential is too broad",[2072,2073],"RLS with BYPASSRLS request role","Database policy exists but does not protect the actual request path",[2075,2076],"Random UUIDs treated as isolation","Hard-to-guess identifiers reduce enumeration but do not authorize access",{},{"id":975,"data":2079,"type":42,"tunes":2081},{"text":2080,"level":247},"Common misconceptions",{},{"id":980,"data":2083,"type":391,"tunes":2118},{"content":2084,"stretched":43,"withHeadings":14},[2085,2088,2091,2094,2097,2100,2103,2106,2109,2112,2115],[2086,2087],"Misconception","Correction",[2089,2090],"“RBAC provides tenant isolation.”","RBAC controls permissions; isolation also requires tenant\u002Fresource scoping.",[2092,2093],"“If the user is an admin, tenant checks are unnecessary.”","Admin authority must still have an explicit scope.",[2095,2096],"“Tenant ID in JWT is enough.”","It can be a trusted input only if validated and applied consistently to every protected resource path.",[2098,2099],"“Separate databases remove authorization requirements.”","Users still need operation-level permissions inside their tenant.",[2101,2102],"“A tenant_id column means the system is isolated.”","The field only helps if access paths enforce it.",[2104,2105],"“UUIDs prevent cross-tenant access.”","Unpredictable identifiers are defense in depth, not authorization.",[2107,2108],"“RLS means application code needs no security checks.”","Application authorization, correct DB roles and policy coverage still matter.",[2110,2111],"“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.",[2113,2114],"“Platform support needs global ADMIN.”","Cross-tenant support should be a distinct, constrained and auditable authority.",[2116,2117],"“Internal services can skip tenant checks.”","Internal paths can still be compromised or misconfigured and must preserve tenant context.",{},{"id":1018,"data":2120,"type":42,"tunes":2122},{"text":2121,"level":247},"A practical design sequence",{},{"id":1023,"data":2124,"type":334,"tunes":2163},{"steps":2125,"title":2162,"orientation":333},[2126,2129,2132,2135,2138,2141,2144,2147,2150,2153,2156,2159],{"label":2127,"description":2128},"1. Define tenant ownership","Classify which entities and resources are global, tenant-scoped, user-scoped or intentionally cross-tenant.",{"label":2130,"description":2131},"2. Define operations","Create explicit permissions for reads, writes, publishing, approvals, administration and other business actions.",{"label":2133,"description":2134},"3. Define roles","Group permissions according to responsibilities without embedding accidental global scope.",{"label":2136,"description":2137},"4. Define membership scope","Bind role assignments to the tenant\u002Fworkspace\u002Fproject context in which they apply.",{"label":2139,"description":2140},"5. Resolve trusted tenant context","Derive tenant identity from authenticated, server-verified membership or service authorization.",{"label":2142,"description":2143},"6. Enforce resource ownership","Apply tenant scope at every tenant-owned data\u002Fservice boundary.",{"label":2145,"description":2146},"7. Add defense in depth","Use RLS, separate credentials, schemas\u002Fdatabases, storage policies or policy engines where risk justifies them.",{"label":2148,"description":2149},"8. Carry scope through derived systems","Preserve tenant metadata in cache, search, vector indexes, queues, files and analytics.",{"label":2151,"description":2152},"9. Model cross-tenant operations explicitly","Separate platform administration and service identities from ordinary tenant roles.",{"label":2154,"description":2155},"10. Test both axes","Run negative tests for missing permission and for wrong tenant independently.",{"label":2157,"description":2158},"11. Audit tenant + permission together","Log who acted, in which tenant, on what target and under which authority.",{"label":2160,"description":2161},"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":2165,"type":42,"tunes":2167},{"text":2166,"level":247},"RBAC + tenant isolation checklist",{},{"id":1070,"data":2169,"type":391,"tunes":2215},{"content":2170,"stretched":43,"withHeadings":14},[2171,2173,2176,2179,2182,2185,2188,2191,2194,2197,2200,2203,2206,2209,2212],[1603,2172],"Expected answer",[2174,2175],"Who is the principal?","Authenticated user\u002Fservice\u002Fagent identity",[2177,2178],"Which tenant context applies?","Server-verified membership or service scope",[2180,2181],"Which operation is requested?","Typed permission or policy action",[2183,2184],"Does the principal have that permission?","Role\u002Fpolicy decision",[2186,2187],"Who owns the target resource?","Explicit tenant\u002Fglobal\u002Fuser classification",[2189,2190],"Does resource scope match authority?","Tenant-aware lookup\u002Fpolicy",[2192,2193],"Can storage bypass application checks?","Defense-in-depth decision documented",[2195,2196],"Are caches tenant-safe?","Keys\u002Fnamespaces and authorization preserve tenant scope",[2198,2199],"Are files\u002Fblobs tenant-safe?","Object policy and signed URL issuance enforce scope",[2201,2202],"Are async jobs tenant-safe?","Verified context propagates and is revalidated",[2204,2205],"Is RAG\u002Fsearch tenant-safe?","Metadata\u002Fcollection isolation enforced before model context",[2207,2208],"Are cross-tenant admins explicit?","Separate authority, controls and audit",[2210,2211],"Can ordinary credentials bypass isolation?","No, or tightly documented exceptional path",[2213,2214],"Are negative cross-tenant tests automated?","Yes for every relevant access layer",{},{"id":1119,"data":2217,"type":42,"tunes":2219},{"text":2218,"level":247},"Edge cases and limitations",{},{"id":1124,"data":2221,"type":218,"tunes":2223},{"text":2222},"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":2225,"type":218,"tunes":2227},{"text":2226},"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":2229,"type":218,"tunes":2231},{"text":2230},"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":2233,"type":218,"tunes":2235},{"text":2234},"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":2237,"type":218,"tunes":2239},{"text":2238},"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":2241,"type":42,"tunes":2243},{"text":2242,"level":247},"What would change this answer?",{},{"id":1154,"data":2245,"type":218,"tunes":2247},{"text":2246},"The exact implementation changes with architecture: serverless APIs, Kubernetes, PostgreSQL, object storage, vector databases and policy engines expose different isolation primitives.",{},{"id":1159,"data":2249,"type":218,"tunes":2251},{"text":2250},"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":2253,"type":218,"tunes":2255},{"text":2254},"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":2257,"type":42,"tunes":2259},{"text":2258,"level":247},"Related canonical knowledge",{},{"id":1174,"data":2261,"type":218,"tunes":2263},{"text":2262},"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":2265,"type":218,"tunes":2267},{"text":2266},"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":2269,"type":1190,"tunes":2273},{"url":1186,"title":2270,"excerpt":2271,"ctaLabel":2272},"MCP vs A2A vs UCP vs AP2 vs A2UI: The Agent Protocol Stack Explained","Protocol interoperability does not replace authorization or tenant isolation. Capability discovery and business authority remain separate architecture concerns.","Read the protocol stack article",{},{"id":1193,"data":2275,"type":218,"tunes":2277},{"text":2276},"For RAG, tenant isolation must be enforced before protected chunks reach model context.",{},{"id":1198,"data":2279,"type":1190,"tunes":2284},{"url":2280,"title":2281,"excerpt":2282,"ctaLabel":2283},"https:\u002F\u002Fstajic.de\u002Fblog\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works","What Is RAG? The Simplest Explanation of How It Works","The retrieval foundation for understanding where tenant-aware source filtering and vector-store isolation must be enforced.","Read the RAG foundation",{},{"id":1206,"data":2286,"type":42,"tunes":2288},{"text":2287,"level":247},"Frequently asked questions",{},{"id":1211,"data":2290,"type":1211,"tunes":2320},{"items":2291,"title":2319},[2292,2295,2298,2301,2304,2307,2310,2313,2316],{"id":1215,"answer":2293,"question":2294},"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":2296,"question":2297},"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":2299,"question":2300},"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":2302,"question":2303},"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":2305,"question":2306},"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":2308,"question":2309},"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":2311,"question":2312},"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":2314,"question":2315},"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":2317,"question":2318},"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":2322,"type":42,"tunes":2324},{"text":2323,"level":247},"Glossary",{},{"id":1258,"data":2326,"type":1258,"tunes":2361},{"title":2327,"entries":2328},"Key multi-tenant security terms",[2329,2331,2334,2336,2338,2341,2344,2347,2349,2352,2355,2358],{"term":395,"anchor":394,"definition":2330},"Role-Based Access Control: an authorization model that associates permissions with roles and assigns users or principals to those roles.",{"term":2332,"anchor":397,"definition":2333},"Tenant","A customer, organization, workspace or other isolated logical consumer of a shared multi-tenant system.",{"term":1592,"anchor":1269,"definition":2335},"Mechanisms that prevent one tenant from accessing, modifying or receiving another tenant's resources in a shared system.",{"term":1606,"anchor":1272,"definition":2337},"Verification of the identity of a user, service or other principal.",{"term":2339,"anchor":1276,"definition":2340},"Authorization","Decision process that determines whether a principal may perform a requested operation on a resource.",{"term":2342,"anchor":1280,"definition":2343},"Permission","A defined allowed operation or capability such as orders.read or users.write.",{"term":2345,"anchor":1284,"definition":2346},"Role","A named grouping of permissions associated with a responsibility or function.",{"term":1287,"anchor":1288,"definition":2348},"Attribute-Based Access Control: authorization based on attributes of the principal, resource, action or environment.",{"term":2350,"anchor":1292,"definition":2351},"Row-Level Security","Database policy mechanism that restricts which rows a database role or session may read or modify.",{"term":2353,"anchor":1296,"definition":2354},"Cross-tenant access","Any access path in which a principal operating under one tenant context reaches resources belonging to another tenant.",{"term":2356,"anchor":1300,"definition":2357},"Platform administrator","A privileged operational identity with explicitly modeled authority that may span multiple tenants.",{"term":2359,"anchor":1304,"definition":2360},"Tenant context","The verified tenant scope under which the current request, job or agent operation executes.",{},{"id":1308,"data":2363,"type":42,"tunes":2365},{"text":2364,"level":247},"Conclusion",{},{"id":1313,"data":2367,"type":218,"tunes":2369},{"text":2368},"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":2371,"type":218,"tunes":2373},{"text":2372},"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":2375,"type":218,"tunes":2377},{"text":2376},"The shortest reliable rule is: authorize the action, then isolate the scope — and never assume one proves the other.",{},{"id":1328,"data":2379,"type":42,"tunes":2381},{"text":2380,"level":247},"Primary sources and current guidance",{},{"id":1333,"data":2383,"type":218,"tunes":2385},{"text":2384},"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":2387,"type":1345,"tunes":2391},{"link":1340,"meta":2388},{"image":2389,"title":1343,"description":2390},{"url":369},"NIST overview of RBAC models and the INCITS RBAC standard, including users, roles, permissions, operations and objects.",{},{"id":1348,"data":2393,"type":1345,"tunes":2397},{"link":1350,"meta":2394},{"image":2395,"title":1353,"description":2396},{"url":369},"Current NIST glossary definitions of role-based access control as permission assignment through roles.",{},{"id":1357,"data":2399,"type":1345,"tunes":2403},{"link":1359,"meta":2400},{"image":2401,"title":1362,"description":2402},{"url":369},"AWS SaaS guidance explicitly distinguishing authentication\u002Fauthorization from tenant isolation and recommending shared isolation mechanisms.",{},{"id":1366,"data":2405,"type":1345,"tunes":2409},{"link":1368,"meta":2406},{"image":2407,"title":1371,"description":2408},{"url":369},"Current guidance explaining the difference between authorization and tenant isolation in SaaS applications.",{},{"id":1375,"data":2411,"type":1345,"tunes":2415},{"link":1377,"meta":2412},{"image":2413,"title":1380,"description":2414},{"url":369},"Current SaaS guidance distinguishing tenant isolation from authorization and discussing pooled\u002Fsiloed authorization policy models.",{},{"id":1384,"data":2417,"type":1345,"tunes":2421},{"link":1386,"meta":2418},{"image":2419,"title":1389,"description":2420},{"url":369},"Current practical guidance for tenant context, database isolation, caches, storage, queues, testing and cross-tenant access prevention.",{},{"id":1393,"data":2423,"type":1345,"tunes":2427},{"link":1395,"meta":2424},{"image":2425,"title":1398,"description":2426},{"url":369},"Current guidance requiring access control at retrieval time and tenant isolation for multi-tenant vector stores.",{},{"id":1402,"data":2429,"type":1345,"tunes":2433},{"link":1404,"meta":2430},{"image":2431,"title":1407,"description":2432},{"url":369},"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":2437,"excerpt":1411},{"time":212,"blocks":2438,"version":1410},[2439,2442,2445,2448,2451,2454,2457,2460,2463,2466,2469,2472,2475,2478,2481,2484,2487,2490,2500,2503,2506,2509,2512,2515,2534,2537,2545,2548,2551,2554,2557,2560,2563,2566,2569,2572,2575,2578,2586,2589,2592,2595,2598,2601,2604,2615,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,2740,2743,2746,2749,2752,2755,2758,2761,2772,2775,2778,2781,2784,2787,2790,2805,2808,2811,2829,2832,2847,2850,2866,2869,2888,2891,2894,2897,2900,2903,2906,2909,2912,2915,2918,2921,2924,2927,2930,2933,2936,2939,2952,2955,2971,2974,2977,2980,2983,2986,2989,2994,2999,3004,3009,3014,3019,3024],{"id":215,"data":2440,"type":218,"tunes":2441},{"text":217},{},{"id":221,"data":2443,"type":226,"tunes":2444},{"body":223,"title":224,"variant":225},{},{"id":229,"data":2446,"type":226,"tunes":2447},{"body":231,"title":232,"variant":233},{},{"id":236,"data":2449,"type":226,"tunes":2450},{"body":238,"title":239,"variant":240},{},{"id":243,"data":2452,"type":248,"tunes":2453},{"title":245,"maxLevel":246,"minLevel":247},{},{"id":251,"data":2455,"type":42,"tunes":2456},{"text":253,"level":247},{},{"id":256,"data":2458,"type":218,"tunes":2459},{"text":258},{},{"id":261,"data":2461,"type":218,"tunes":2462},{"text":263},{},{"id":266,"data":2464,"type":218,"tunes":2465},{"text":268},{},{"id":271,"data":2467,"type":42,"tunes":2468},{"text":273,"level":247},{},{"id":276,"data":2470,"type":218,"tunes":2471},{"text":278},{},{"id":281,"data":2473,"type":218,"tunes":2474},{"text":283},{},{"id":286,"data":2476,"type":218,"tunes":2477},{"text":288},{},{"id":291,"data":2479,"type":42,"tunes":2480},{"text":293,"level":247},{},{"id":296,"data":2482,"type":218,"tunes":2483},{"text":298},{},{"id":301,"data":2485,"type":218,"tunes":2486},{"text":303},{},{"id":306,"data":2488,"type":218,"tunes":2489},{"text":308},{},{"id":311,"data":2491,"type":334,"tunes":2499},{"steps":2492,"title":332,"orientation":333},[2493,2494,2495,2496,2497,2498],{"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":2501,"type":42,"tunes":2502},{"text":339,"level":247},{},{"id":342,"data":2504,"type":218,"tunes":2505},{"text":344},{},{"id":347,"data":2507,"type":218,"tunes":2508},{"text":349},{},{"id":352,"data":2510,"type":218,"tunes":2511},{"text":354},{},{"id":357,"data":2513,"type":42,"tunes":2514},{"text":359,"level":247},{},{"id":362,"data":2516,"type":399,"tunes":2533},{"rows":2517,"title":390,"layout":391,"columns":2530},[2518,2520,2522,2524,2526,2528],{"id":366,"label":367,"values":2519},[369,369],{"id":371,"label":372,"values":2521},[369,369],{"id":375,"label":376,"values":2523},[369,369],{"id":379,"label":380,"values":2525},[369,369],{"id":383,"label":384,"values":2527},[369,369],{"id":387,"label":388,"values":2529},[369,369],[2531,2532],{"id":394,"label":395},{"id":397,"label":398},{},{"id":402,"data":2535,"type":42,"tunes":2536},{"text":404,"level":247},{},{"id":407,"data":2538,"type":391,"tunes":2544},{"content":2539,"stretched":43,"withHeadings":14},[2540,2541,2542,2543],[411,412,413],[415,416,417],[419,420,421],[398,423,424],{},{"id":427,"data":2546,"type":218,"tunes":2547},{"text":429},{},{"id":432,"data":2549,"type":42,"tunes":2550},{"text":434,"level":247},{},{"id":437,"data":2552,"type":218,"tunes":2553},{"text":439},{},{"id":442,"data":2555,"type":218,"tunes":2556},{"text":444},{},{"id":447,"data":2558,"type":218,"tunes":2559},{"text":449},{},{"id":452,"data":2561,"type":42,"tunes":2562},{"text":454,"level":247},{},{"id":457,"data":2564,"type":218,"tunes":2565},{"text":459},{},{"id":462,"data":2567,"type":218,"tunes":2568},{"text":464},{},{"id":467,"data":2570,"type":218,"tunes":2571},{"text":469},{},{"id":472,"data":2573,"type":42,"tunes":2574},{"text":474,"level":247},{},{"id":477,"data":2576,"type":218,"tunes":2577},{"text":479},{},{"id":482,"data":2579,"type":391,"tunes":2585},{"content":2580,"stretched":43,"withHeadings":14},[2581,2582,2583,2584],[486,487],[489,490],[492,493],[495,496],{},{"id":499,"data":2587,"type":218,"tunes":2588},{"text":501},{},{"id":504,"data":2590,"type":42,"tunes":2591},{"text":506,"level":247},{},{"id":509,"data":2593,"type":218,"tunes":2594},{"text":511},{},{"id":514,"data":2596,"type":218,"tunes":2597},{"text":516},{},{"id":519,"data":2599,"type":226,"tunes":2600},{"body":521,"title":522,"variant":523},{},{"id":526,"data":2602,"type":42,"tunes":2603},{"text":528,"level":247},{},{"id":531,"data":2605,"type":391,"tunes":2614},{"content":2606,"stretched":43,"withHeadings":14},[2607,2608,2609,2610,2611,2612,2613],[535,536,537],[539,540,541],[543,544,545],[547,548,549],[551,552,553],[555,556,557],[559,560,561],{},{"id":564,"data":2616,"type":218,"tunes":2617},{"text":566},{},{"id":569,"data":2619,"type":42,"tunes":2620},{"text":571,"level":247},{},{"id":574,"data":2622,"type":218,"tunes":2623},{"text":576},{},{"id":579,"data":2625,"type":218,"tunes":2626},{"text":581},{},{"id":584,"data":2628,"type":218,"tunes":2629},{"text":586},{},{"id":589,"data":2631,"type":42,"tunes":2632},{"text":591,"level":247},{},{"id":594,"data":2634,"type":218,"tunes":2635},{"text":596},{},{"id":599,"data":2637,"type":218,"tunes":2638},{"text":601},{},{"id":604,"data":2640,"type":218,"tunes":2641},{"text":606},{},{"id":609,"data":2643,"type":42,"tunes":2644},{"text":611,"level":247},{},{"id":614,"data":2646,"type":218,"tunes":2647},{"text":616},{},{"id":619,"data":2649,"type":218,"tunes":2650},{"text":621},{},{"id":624,"data":2652,"type":218,"tunes":2653},{"text":626},{},{"id":629,"data":2655,"type":42,"tunes":2656},{"text":631,"level":247},{},{"id":634,"data":2658,"type":218,"tunes":2659},{"text":636},{},{"id":639,"data":2661,"type":218,"tunes":2662},{"text":641},{},{"id":644,"data":2664,"type":218,"tunes":2665},{"text":646},{},{"id":649,"data":2667,"type":42,"tunes":2668},{"text":651,"level":247},{},{"id":654,"data":2670,"type":218,"tunes":2671},{"text":656},{},{"id":659,"data":2673,"type":218,"tunes":2674},{"text":661},{},{"id":664,"data":2676,"type":218,"tunes":2677},{"text":666},{},{"id":669,"data":2679,"type":226,"tunes":2680},{"body":671,"title":672,"variant":233},{},{"id":675,"data":2682,"type":42,"tunes":2683},{"text":677,"level":247},{},{"id":680,"data":2685,"type":218,"tunes":2686},{"text":682},{},{"id":685,"data":2688,"type":218,"tunes":2689},{"text":687},{},{"id":690,"data":2691,"type":42,"tunes":2692},{"text":692,"level":247},{},{"id":695,"data":2694,"type":218,"tunes":2695},{"text":697},{},{"id":700,"data":2697,"type":218,"tunes":2698},{"text":702},{},{"id":705,"data":2700,"type":218,"tunes":2701},{"text":707},{},{"id":710,"data":2703,"type":42,"tunes":2704},{"text":712,"level":247},{},{"id":715,"data":2706,"type":218,"tunes":2707},{"text":717},{},{"id":720,"data":2709,"type":218,"tunes":2710},{"text":722},{},{"id":725,"data":2712,"type":218,"tunes":2713},{"text":727},{},{"id":730,"data":2715,"type":42,"tunes":2716},{"text":732,"level":247},{},{"id":735,"data":2718,"type":218,"tunes":2719},{"text":737},{},{"id":740,"data":2721,"type":218,"tunes":2722},{"text":742},{},{"id":745,"data":2724,"type":218,"tunes":2725},{"text":747},{},{"id":750,"data":2727,"type":42,"tunes":2728},{"text":752,"level":247},{},{"id":755,"data":2730,"type":391,"tunes":2739},{"content":2731,"stretched":43,"withHeadings":14},[2732,2733,2734,2735,2736,2737,2738],[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":2741,"type":42,"tunes":2742},{"text":789,"level":247},{},{"id":792,"data":2744,"type":226,"tunes":2745},{"body":794,"title":795,"variant":240},{},{"id":798,"data":2747,"type":218,"tunes":2748},{"text":800},{},{"id":803,"data":2750,"type":218,"tunes":2751},{"text":805},{},{"id":808,"data":2753,"type":218,"tunes":2754},{"text":810},{},{"id":813,"data":2756,"type":218,"tunes":2757},{"text":815},{},{"id":818,"data":2759,"type":218,"tunes":2760},{"text":820},{},{"id":823,"data":2762,"type":391,"tunes":2771},{"content":2763,"stretched":43,"withHeadings":14},[2764,2765,2766,2767,2768,2769,2770],[827,828],[830,831],[833,834],[836,837],[839,840],[842,843],[845,846],{},{"id":849,"data":2773,"type":226,"tunes":2774},{"body":851,"title":852,"variant":233},{},{"id":855,"data":2776,"type":42,"tunes":2777},{"text":857,"level":247},{},{"id":860,"data":2779,"type":218,"tunes":2780},{"text":862},{},{"id":865,"data":2782,"type":218,"tunes":2783},{"text":867},{},{"id":870,"data":2785,"type":218,"tunes":2786},{"text":872},{},{"id":875,"data":2788,"type":42,"tunes":2789},{"text":877,"level":247},{},{"id":880,"data":2791,"type":391,"tunes":2804},{"content":2792,"stretched":43,"withHeadings":14},[2793,2794,2795,2796,2797,2798,2799,2800,2801,2802,2803],[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":2806,"type":218,"tunes":2807},{"text":920},{},{"id":923,"data":2809,"type":42,"tunes":2810},{"text":925,"level":247},{},{"id":928,"data":2812,"type":391,"tunes":2828},{"content":2813,"stretched":43,"withHeadings":14},[2814,2815,2816,2817,2818,2819,2820,2821,2822,2823,2824,2825,2826,2827],[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":2830,"type":42,"tunes":2831},{"text":977,"level":247},{},{"id":980,"data":2833,"type":391,"tunes":2846},{"content":2834,"stretched":43,"withHeadings":14},[2835,2836,2837,2838,2839,2840,2841,2842,2843,2844,2845],[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":2848,"type":42,"tunes":2849},{"text":1020,"level":247},{},{"id":1023,"data":2851,"type":334,"tunes":2865},{"steps":2852,"title":1062,"orientation":333},[2853,2854,2855,2856,2857,2858,2859,2860,2861,2862,2863,2864],{"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":2867,"type":42,"tunes":2868},{"text":1067,"level":247},{},{"id":1070,"data":2870,"type":391,"tunes":2887},{"content":2871,"stretched":43,"withHeadings":14},[2872,2873,2874,2875,2876,2877,2878,2879,2880,2881,2882,2883,2884,2885,2886],[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":2889,"type":42,"tunes":2890},{"text":1121,"level":247},{},{"id":1124,"data":2892,"type":218,"tunes":2893},{"text":1126},{},{"id":1129,"data":2895,"type":218,"tunes":2896},{"text":1131},{},{"id":1134,"data":2898,"type":218,"tunes":2899},{"text":1136},{},{"id":1139,"data":2901,"type":218,"tunes":2902},{"text":1141},{},{"id":1144,"data":2904,"type":218,"tunes":2905},{"text":1146},{},{"id":1149,"data":2907,"type":42,"tunes":2908},{"text":1151,"level":247},{},{"id":1154,"data":2910,"type":218,"tunes":2911},{"text":1156},{},{"id":1159,"data":2913,"type":218,"tunes":2914},{"text":1161},{},{"id":1164,"data":2916,"type":218,"tunes":2917},{"text":1166},{},{"id":1169,"data":2919,"type":42,"tunes":2920},{"text":1171,"level":247},{},{"id":1174,"data":2922,"type":218,"tunes":2923},{"text":1176},{},{"id":1179,"data":2925,"type":218,"tunes":2926},{"text":1181},{},{"id":1184,"data":2928,"type":1190,"tunes":2929},{"url":1186,"title":1187,"excerpt":1188,"ctaLabel":1189},{},{"id":1193,"data":2931,"type":218,"tunes":2932},{"text":1195},{},{"id":1198,"data":2934,"type":1190,"tunes":2935},{"url":1200,"title":1201,"excerpt":1202,"ctaLabel":1203},{},{"id":1206,"data":2937,"type":42,"tunes":2938},{"text":1208,"level":247},{},{"id":1211,"data":2940,"type":1211,"tunes":2951},{"items":2941,"title":1250},[2942,2943,2944,2945,2946,2947,2948,2949,2950],{"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":2953,"type":42,"tunes":2954},{"text":1255,"level":247},{},{"id":1258,"data":2956,"type":1258,"tunes":2970},{"title":1260,"entries":2957},[2958,2959,2960,2961,2962,2963,2964,2965,2966,2967,2968,2969],{"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":2972,"type":42,"tunes":2973},{"text":1310,"level":247},{},{"id":1313,"data":2975,"type":218,"tunes":2976},{"text":1315},{},{"id":1318,"data":2978,"type":218,"tunes":2979},{"text":1320},{},{"id":1323,"data":2981,"type":218,"tunes":2982},{"text":1325},{},{"id":1328,"data":2984,"type":42,"tunes":2985},{"text":1330,"level":247},{},{"id":1333,"data":2987,"type":218,"tunes":2988},{"text":1335},{},{"id":1338,"data":2990,"type":1345,"tunes":2993},{"link":1340,"meta":2991},{"image":2992,"title":1343,"description":1344},{"url":369},{},{"id":1348,"data":2995,"type":1345,"tunes":2998},{"link":1350,"meta":2996},{"image":2997,"title":1353,"description":1354},{"url":369},{},{"id":1357,"data":3000,"type":1345,"tunes":3003},{"link":1359,"meta":3001},{"image":3002,"title":1362,"description":1363},{"url":369},{},{"id":1366,"data":3005,"type":1345,"tunes":3008},{"link":1368,"meta":3006},{"image":3007,"title":1371,"description":1372},{"url":369},{},{"id":1375,"data":3010,"type":1345,"tunes":3013},{"link":1377,"meta":3011},{"image":3012,"title":1380,"description":1381},{"url":369},{},{"id":1384,"data":3015,"type":1345,"tunes":3018},{"link":1386,"meta":3016},{"image":3017,"title":1389,"description":1390},{"url":369},{},{"id":1393,"data":3020,"type":1345,"tunes":3023},{"link":1395,"meta":3021},{"image":3022,"title":1398,"description":1399},{"url":369},{},{"id":1402,"data":3025,"type":1345,"tunes":3028},{"link":1404,"meta":3026},{"image":3027,"title":1407,"description":1408},{"url":369},{},"Post erfolgreich abgerufen",{"items":3031,"source":3115,"manualIds":3116,"manualMatchedIds":3117},[3032,3039,3046,3053,3060,3067,3074,3081,3088,3095,3102,3109],{"id":3033,"slug":3034,"title":3035,"excerpt":3036,"featuredImage":3037,"publishedAt":3038},"476","mcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained","MCP vs A2A vs UCP vs AP2 vs A2UI: разбор стека протоколов агентов","MCP, A2A, UCP, AP2 и A2UI часто представляют как конкурирующие агентские стандарты. В основном они решают разные проблемы интероперабельности. Это руководство сопоставляет каждый протокол с границей, которую он фактически стандартизирует,—и показывает, как они могут работать вместе в одной промышленной системе.","\u002Fuploads\u002F2026\u002F09\u002Fmcp-vs-a2a-vs-ucp-vs-ap2-vs-a2ui-the-agent-protocol-stack-explained-1790352625869-2ezle0.webp","2026-09-25T12:09:00.000Z",{"id":3040,"slug":3041,"title":3042,"excerpt":3043,"featuredImage":3044,"publishedAt":3045},"492","mcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits","MCP: объяснение — что он подключает, чего не делает и где ему место","Протокол контекста модели соединяет приложения ИИ с внешними инструментами, ресурсами и подсказками через стандартную границу клиент-сервер. Узнайте, что делает MCP, чего он не делает и где он вписывается в архитектуру агента.","\u002Fuploads\u002F2026\u002F10\u002Fmcp-explained-what-it-connects-what-it-does-not-do-and-where-it-fits-1791486640275-7ub1cq.webp","2026-10-08T15:09:00.000Z",{"id":3047,"slug":3048,"title":3049,"excerpt":3050,"featuredImage":3051,"publishedAt":3052},"494","air-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access","Air-Gapped AI: как работают ИИ-системы без интернета и облачного доступа","AI-системы в изолированной среде запускают модели, RAG и AI-приложения внутри изолированного домена безопасности без зависимости от интернета или облачных сервисов. Узнайте, как модели, данные, обновления и инструменты работают в автономном режиме.","\u002Fuploads\u002F2026\u002F10\u002Fair-gapped-ai-how-ai-systems-work-without-internet-or-cloud-access-1791487983978-e6xqf0.webp","2026-10-08T11:32:00.000Z",{"id":3054,"slug":3055,"title":3056,"excerpt":3057,"featuredImage":3058,"publishedAt":3059},"363","front-und-backend-entwicklung","Фронтенд- и бэкенд-разработка","Фронтенд- и бэкенд-разработка является неотъемлемой частью веб-разработки и включает в себя создание веб-приложений и веб-сайтов. Фронтенд-разработка сосредоточена на пользовательском интерфейсе, в то время как бэкенд-разработка отвечает за программирование и управление серверной частью.","\u002Fuploads\u002F2026\u002F03\u002Ffront-und-backend-entwicklung-1774872219531-wyu4i1.webp","2023-04-12T11:11:00.000Z",{"id":3061,"slug":3062,"title":3063,"excerpt":3064,"featuredImage":3065,"publishedAt":3066},"481","generative-ai-explained-models-retrieval-tools-and-applications-are-not-the-same-thing","Генеративный ИИ: модели, поиск, инструменты и приложения — это не одно и то же","Генеративный ИИ — это больше, чем модель. Узнайте, как модели, поиск информации, инструменты, контекст, среды выполнения и приложения сочетаются друг с другом в производственных системах ИИ.","\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":3068,"slug":3069,"title":3070,"excerpt":3071,"featuredImage":3072,"publishedAt":3073},"483","what-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs","Что такое архитектор ИИ-решений? Границы системы, обязанности и компромиссы","Архитектор решений ИИ превращает бизнес-требования в готовую к производству систему ИИ, охватывающую данные, модели, инструменты, безопасность, среду выполнения, оценку и операции.","\u002Fuploads\u002F2026\u002F10\u002Fwhat-is-an-ai-solution-architect-system-boundaries-responsibilities-and-trade-offs-1791476643267-1st5xz.webp","2026-10-08T12:23:00.000Z",{"id":3075,"slug":3076,"title":3077,"excerpt":3078,"featuredImage":3079,"publishedAt":3080},"467","the-answer-validity-boundary-the-missing-layer-between-relevance-and-reliable-ai-answers","Граница достоверности ответа: недостающий слой между релевантностью и надёжными ответами ИИ","Источник может быть релевантным, авторитетным и при этом неверным для задаваемого вопроса. Недостающий слой — применимость: условия, при которых ответ остаётся в силе, и изменения, вынуждающие пересмотреть его. В этой статье вводится понятие «Граница действительности ответа» как паттерн проектирования источников для людей, ИИ-поиска и 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":3082,"slug":3083,"title":3084,"excerpt":3085,"featuredImage":3086,"publishedAt":3087},"486","source-of-truth-in-ai-systems-where-reliable-knowledge-actually-comes-from","Источник истины в системах ИИ: откуда на самом деле берутся надёжные знания","Источник истины определяет, какой источник является авторитетным для конкретного факта или состояния. Узнайте, чем он отличается от RAG, происхождения данных, памяти, контекста, векторных баз данных и систем учёта.","\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":3089,"slug":3090,"title":3091,"excerpt":3092,"featuredImage":3093,"publishedAt":3094},"495","sovereign-ai-control-of-models-data-infrastructure-and-dependencies","Суверенный ИИ: контроль над моделями, данными, инфраструктурой и зависимостями","Суверенный ИИ — это эффективный контроль над моделями, данными, инфраструктурой, программным обеспечением, операциями и стратегическими зависимостями, а не просто место размещения модели ИИ.","\u002Fuploads\u002F2026\u002F10\u002Fsovereign-ai-control-of-models-data-infrastructure-and-dependencies-1791488833132-niy85x.webp","2026-10-08T15:45:00.000Z",{"id":3096,"slug":3097,"title":3098,"excerpt":3099,"featuredImage":3100,"publishedAt":3101},"472","why-more-context-can-make-ai-answers-worse","Почему больше контекста может ухудшить ответы ИИ","Большее контекстное окно не гарантирует более качественного ответа. В этой статье объясняется, как размывание сигнала, противоречивые данные, устаревшее состояние, чувствительность к позиции и сжатие с потерями могут снизить надежность ИИ — и предлагается практический стресс-тест контекста.","\u002Fuploads\u002F2026\u002F09\u002Fwhy-more-context-can-make-ai-answers-worse-1790351615793-2ntv2v.webp","2026-09-25T11:51:00.000Z",{"id":3103,"slug":3104,"title":3105,"excerpt":3106,"featuredImage":3107,"publishedAt":3108},"364","tipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung","Освоение рабочего процесса SEO: Основные стратегии оптимизации для органического роста","Структурированный рабочий процесс SEO крайне важен для устойчивого органического роста. Изучите десять основополагающих стратегий, от исследования ключевых слов и технической оптимизации до качества контента и анализа производительности.","\u002Fuploads\u002F2026\u002F03\u002Ftipps-fuer-die-verbesserung-der-seo-suchmaschinenoptimierung-1774866098131-hwkzrg.webp","2024-01-26T06:35:00.000Z",{"id":3110,"slug":3111,"title":1201,"excerpt":3112,"featuredImage":3113,"publishedAt":3114},"478","what-is-rag-the-simplest-explanation-of-how-it-works","RAG звучит сложно, но идея проста: прежде чем ИИ ответит, он сначала находит полезную информацию из источника знаний и передаёт эту информацию языковой модели. В этом руководстве объясняются RAG, LLM, состояние, память и инструменты с помощью одной простой ментальной модели.","\u002Fuploads\u002F2026\u002F09\u002Fwhat-is-rag-the-simplest-explanation-of-how-it-works-1790377492124-khjagt.webp","2026-09-25T19:03:00.000Z","fallback",[],[]]