RBAC против изоляции арендаторов: две разные границы безопасности

RBAC и изоляция тенантов решают две разные задачи безопасности в мультитенантных системах. Управление доступом на основе ролей (RBAC) определяет, что разрешено делать аутентифицированному субъекту, например читать заказы, редактировать товары или управлять пользователями. Изоляция тенантов определяет, к данным, ресурсам и контексту выполнения какого тенанта этот субъект имеет доступ. Пользователь может быть корректно аутентифицирован и корректно наделён ролью RBAC, но при этом всё равно столкнуться с нарушением безопасности, если приложение позволяет этой роли работать с ресурсами другого тенанта.

Что на самом деле контролирует RBAC

RBAC — это модель авторизации, в которой разрешения связаны с ролями, а пользователи назначаются на эти роли. Роль выступает административной абстракцией между учётными записями и разрешениями.

Классическая работа NIST по RBAC формализует это через пользователей, роли, разрешения, операции и объекты. Практическая выгода в том, что организация может управлять авторизацией через относительно стабильные должностные или функциональные роли, а не привязывать каждое разрешение напрямую к каждому пользователю.

Роль, например EDITOR, может означать: может читать контент, писать контент и публиковать контент. Роль, например ACCOUNTANT, может означать: может читать данные биллинга, сверять счета и утверждать расчёты.

Что на самом деле контролирует изоляция тенантов

Изоляция тенантов — это набор механизмов, которые не позволяют одному тенанту читать, изменять, влиять или случайно получать ресурсы другого тенанта в общей системе.

Защищаемая граница шире, чем строки в базе данных. Состояние, относящееся к тенанту, может существовать в реляционных таблицах, объектных хранилищах, векторных индексах, кэшах, поисковых индексах, сообщениях очередей, файлах, временных артефактах, фоновых задачах, аналитике, ограничениях скорости и инфраструктурных ресурсах.

Рекомендации AWS по SaaS делают это различие явным: авторизация предоставляет доступ к ресурсам, а изоляция тенантов гарантирует, что эти ресурсы не пересекут границу не того тенанта, даже когда инфраструктура является общей.

Простейший пример

Предположим, Алиса — администратор тенанта A, а Боб — администратор тенанта B. Оба пользователя правомерно обладают одной и той же ролью ADMIN.

RBAC может корректно заключить, что оба пользователя могут выполнить операцию, например users.read. Но когда Алиса запрашивает пользователя с ID 847, приложение всё равно должно проверить, что пользователь 847 принадлежит тенанту A.

Если API проверяет только «у Алисы есть ADMIN» и затем выполняет SELECT * FROM users WHERE id = 847, RBAC сработал, а изоляция тенантов — нет.

Где останавливается простой пример

Реальные системы часто содержат несколько классов идентичностей: пользователи арендаторов, администраторы платформы, фоновые обработчики, интеграции, агенты и кросс-арендаторские операционные сервисы. Некоторые из них законно пересекают границы арендаторов.

Это не устраняет необходимость изоляции. Это означает, что кросс-арендаторские полномочия должны быть явными, узкими и отдельно проверяемыми, а не возникать случайно из глобальной роли или неограниченного подключения к базе данных.

Изоляция арендаторов также может различаться по уровням. Продукт может совместно использовать серверы приложений, разделяя базы данных, или использовать общую базу данных с политиками на уровне строк, предоставляя премиум-арендаторам изолированное хранилище или вычислительные ресурсы. Не существует единой универсальной топологии изоляции.

RBAC против изоляции арендаторов

Аутентификация, авторизация и изоляция — это три разные проверки

Эти проверки связаны, но не взаимозаменяемы. Аутентификация может быть идеальной, а авторизация — нет. Авторизация может быть корректной, а изоляция арендаторов — нет. Безопасный путь запроса в SaaS требует всех применимых границ.

Ролям нужна область действия

Слово ADMIN неполно без области действия. Оно может означать администратора платформы, администратора арендатора, администратора проекта, администратора рабочего пространства или администратора одной подсистемы.

В мультитенантных системах назначение роли обычно должно быть связано с членством в арендаторе или другой явной областью ресурса. Один и тот же пользователь может законно быть ADMIN в арендаторе A и VIEWER в арендаторе B.

Глобальная модель ролей, игнорирующая это различие, может создавать утечку привилегий, даже когда сама карта разрешений корректна.

Контекст арендатора должен поступать из доверенного источника

Идентификатор арендатора, предоставленный клиентом, полезен как селектор, но не является доказательством полномочий. Сервер должен выводить или проверять членство в арендаторе на основе аутентифицированной идентичности и текущих данных авторизации.

Текущие рекомендации OWASP по мультитенантности советуют устанавливать контекст арендатора на раннем этапе жизненного цикла запроса и явно предупреждают против рассмотрения клиентских заголовков или параметров запроса как доказательства авторизации.

Это важно, потому что тривиальное изменение запроса с tenant=A на tenant=B не должно быть достаточным для пересечения границы изоляции.

Область арендатора должна быть в поиске ресурса

Распространённый паттерн изоляции на уровне приложения — включать область арендатора в тот же запрос, который разрешает ресурс.

Этот паттерн не является единственным возможным механизмом изоляции, но он удерживает принадлежность арендатору рядом с операцией доступа к данным и предотвращает превращение идентификатора объекта в межарендаторскую возможность.

Проверки на уровне приложения полезны, но изоляция не должна зависеть от идеального поведения разработчика

Руководство AWS по изоляции явно предостерегает от того, чтобы оставлять обеспечение изоляции только на разработчиков сервисов. В большой кодовой базе в конце концов один запрос, ключ кэша или путь воркера может пропустить область арендатора.

Поэтому эшелонированная защита может перенести изоляцию в общее промежуточное ПО, слои репозиториев/сервисов, движки политик, безопасность на уровне строк базы данных, выделенные учётные данные, отдельные схемы или отдельные базы данных в зависимости от риска и архитектуры.

Стратегии изоляции баз данных

Текущая шпаргалка OWASP по безопасности мультиарендаторных систем перечисляет отдельные базы данных, отдельные схемы, общие таблицы с контролем на уровне строк и гибридные модели. Правильная модель зависит от уровня угрозы, соответствия требованиям, производительности и операционных затрат.

Безопасность на уровне строк PostgreSQL может обеспечить эшелонированную защиту

При общих таблицах безопасность на уровне строк PostgreSQL может обеспечить предикат арендатора на уровне базы данных, чтобы обычные запросы не могли видеть строки вне политики активного арендатора.

Однако RLS — не магия. Суперпользователи PostgreSQL и роли с BYPASSRLS могут обходить политики строк. Поэтому OWASP рекомендует использовать роль с минимальными привилегиями для пути запроса и тестировать тот же режим соединения/пула, который используется в продакшене.

Повторное использование соединений — ещё один важный крайний случай: контекст арендатора должен безопасно устанавливаться и сбрасываться для каждой транзакции/запроса, чтобы одно соединение из пула не могло раскрыть предыдущее состояние арендатора.

Изоляция арендаторов должна включать кэши

Запрос к базе данных может быть идеально ограничен по области, но всё равно раскрыть данные через общий ключ кэша.

Если user:42 существует и в Арендаторе A, и в Арендаторе B, глобальный ключ кэша может вернуть значение не того арендатора. Ключи кэша, чувствительные к арендатору, должны включать каждый атрибут, который меняет видимость или семантику результата, обычно арендатора, пользователя, локаль, набор функций или версию разрешений.

Разделение кэша — это эшелонированная защита, а не замена авторизации. Запрос всё ещё должен быть авторизован до возврата защищённого кэшированного содержимого.

Файлы и объектное хранилище нуждаются в собственной границе арендатора

Объектное хранилище должно различать глобальные, привязанные к арендатору и привязанные к пользователю объекты. Префикс папки сам по себе является лишь соглашением об именовании, если политика доступа фактически не ограничивает чтение и запись.

Более строгие архитектуры могут использовать ключи объектов с учётом арендатора, политики бакетов, отдельные бакеты/аккаунты или ключи шифрования для конкретного арендатора, когда риск или требования соответствия требуют более сильной изоляции.

Подписанные URL должны быть авторизованы до выдачи и ограничены точным объектом и операцией. Наличие идентификатора объекта само по себе не должно предоставлять доступ между арендаторами.

Фоновые задачи и очереди могут нарушить изоляцию

Асинхронные задачи часто покидают исходный контекст HTTP-запроса, что затрудняет корректную передачу арендатора. Сообщение в очереди, содержащее tenantId, не является достаточным доказательством того, что производитель был авторизован.

Воркер должен нести проверенную идентичность сервиса/пользователя или доверенный конверт задачи, заново устанавливать контекст арендатора и повторно авторизовывать значимые операции на границе потребителя.

Изоляция арендаторов также включает доступность. Один арендатор не должен иметь возможности монополизировать общие воркеры, очереди, пулы соединений или вычислительные ресурсы способами, которые существенно ухудшают работу других арендаторов.

Поиск и RAG нуждаются в извлечении с учётом арендатора

Мультитенантный ИИ вводит ещё одну копию проблемы изоляции. Документы могут быть разбиты на фрагменты, преобразованы в эмбеддинги и сохранены в векторном индексе после приёма.

Текущее руководство OWASP по безопасности RAG утверждает, что контроль доступа должен применяться во время извлечения и что фрагменты от Арендатора A не должны извлекаться запросами от Арендатора B. Нельзя просто предполагать, что разрешения на уровне документа автоматически сохраняются при разбиении на фрагменты.

Таким образом, векторный индекс нуждается в метаданных арендатора/доступа или физически/логически разделённых коллекциях в соответствии с архитектурой изоляции. Фильтры извлечения должны применяться до того, как неавторизованный контент сможет попасть в контекст модели.

Производные данные наследуют чувствительность арендатора

Эмбеддинги, поисковые индексы, миниатюры, сгенерированные резюме, кэши, строки аналитики и ответы ИИ являются производными от исходных данных. Их область арендатора должна следовать за источником, если только явное преобразование не создаёт законный общий/глобальный артефакт.

Удаление и отключение поэтому должны распространяться за пределы канонической строки. Удаление документа арендатора с сохранением доступных для поиска фрагментов или кэшированных резюме может сохранить межарендаторское или послерetенционное воздействие.

Не всё принадлежит арендатору

Мультитенантные платформы часто имеют намеренно глобальные ресурсы: таксономии продуктов, публичные шаблоны, системные разрешения, определения функций или публичный контент.

Самая безопасная модель — это явная классификация: глобальная, ограниченная арендатором, ограниченная пользователем или явно кросс-арендаторская. Именно неоднозначные ресурсы становятся отправной точкой случайной утечки.

У намеренно общего объекта должна быть документированная причина быть глобальным, а не просто отсутствие привязки к арендатору.

Администраторы платформы требуют иной модели полномочий

Оператору платформы может потребоваться проверять несколько арендаторов для поддержки, соответствия требованиям или инфраструктурных операций. Моделирование этого как обычного ADMIN арендатора со случайным глобальным доступом к базе данных ослабляет как безопасность, так и возможность аудита.

Лучший дизайн использует отдельную идентичность платформы или явное кросс-арендаторское разрешение, усиленную аутентификацию, ограничение цели, детальный аудит и, где это уместно, элементы управления одобрением или экстренным доступом.

Таким образом, кросс-арендаторский доступ должен быть именованной возможностью, а не отсутствием фильтра арендатора.

RBAC можно комбинировать с атрибутами

Некоторые решения зависят не только от роли. Членство в арендаторе, регион, владелец ресурса, уровень подписки, время, членство в проекте или классификация данных — всё это может влиять на доступ.

RBAC и ABAC не являются взаимоисключающими. Текущее руководство AWS по мультиарендаторской авторизации рассматривает RBAC, ABAC и гибридные модели. Роль может определять широкую ответственность, в то время как атрибуты ограничивают, к какому конкретному экземпляру ресурса можно получить доступ.

Ключевое архитектурное правило остаётся неизменным: не кодируйте изоляцию арендаторов только как случайное имя роли, если идентичность арендатора является первостепенной границей ресурса.

Решения об авторизации как минимум двумерны

Свидетельство оригинальной реализации: Aaasaasa AI CMS

Сервис RBAC определяет типизированные коды разрешений, такие как cms.content.read, shop.orders.write, billing.reconcile и users.roles. Системные роли отображают эти разрешения в именованные наборы ответственности.

Записи ролей создаются и разрешаются с tenantId. Системные роли обновляются или вставляются с использованием составной идентичности арендатор/код, а список ролей фильтруется по арендатору.

Обновление и удаление роли сначала разрешают роль, используя как ID роли, так и ID арендатора. Назначения ролей пользователям также сохраняются и заменяются в контексте текущего арендатора.

Разрешение разрешений читает явные назначения ролей пользователям с областью, ограниченной как tenantId, так и userId. Это предотвращает автоматическое превращение назначения роли одного арендатора в назначение роли другого арендатора.

На уровне API административные маршруты RBAC разрешают контекст тенанта перед созданием или изменением ролей. Это правильное направление: администрирование разрешений само должно учитывать мультитенантность.

Почему это различие еще важнее для ИИ-агентов

ИИ-агенты могут превратить ошибку в разрешениях в последовательность действий. Если агенту дан широкий инструмент orders.read без принудительного ограничения по тенанту, сбой рассуждения или внедрение промпта может вызвать межтенантные чтения на машинной скорости.

Описания инструментов агента могут упоминать ограничения тенанта, но принудительное применение все равно должно происходить в доверенном слое среды выполнения/сервиса/данных. Инструкции на естественном языке не являются границей авторизации.

То же самое относится к RAG: агент может иметь разрешение на использование инструмента поиска, но серверная часть поиска все равно должна предотвращать возврат запросом Тенанта A фрагментов Тенанта B.

Тестируйте RBAC и изоляцию тенантов отдельно

Руководство OWASP по регрессии авторизации специально выделяет тесты границ между тенантами, потому что изменения кода в кэшировании, запросах или общих сервисах могут незаметно нарушить изоляцию, даже если тесты ролей продолжают проходить.

Распространенные режимы отказа

Распространенные заблуждения

Практическая последовательность проектирования

Контрольный список RBAC + изоляция тенантов

Граничные случаи и ограничения

Пользователь может принадлежать нескольким тенантам. Поэтому текущий тенант должен быть явным контекстом выполнения, а не постоянно выводиться из учетной записи пользователя.

Некоторые ресурсы намеренно используются совместно выбранными тенантами, например пространства для совместной работы или данные консорциума. Это требует явной модели совместного использования; попытка представить, что ресурс принадлежит одному тенанту, и добавление исключений позже обычно создает неоднозначную авторизацию.

Изоляция от шумных соседей связана, но отличается от изоляции конфиденциальности. Тенант может никогда не видеть данные другого тенанта, но при этом исчерпать общие ресурсы CPU, емкость очереди или подключения к базе данных. Поэтому ограничения скорости и квоты ресурсов могут учитывать тенанта как границу доступности.

Физическая изоляция не является автоматически безопасной, если учетные данные плоскости управления или административные пути могут пересекать границы. Логическая изоляция не является автоматически слабой, если политики централизованно применяются, основаны на принципе наименьших привилегий и тщательно протестированы.

Требования к изоляции тенантов могут различаться в зависимости от класса данных. Публичные данные каталога, записи о выставлении счетов и частные документы ИИ могут оправдывать различные границы хранения и шифрования внутри одного SaaS-продукта.

Что могло бы изменить этот ответ?

Конкретная реализация меняется в зависимости от архитектуры: бессерверные API, Kubernetes, PostgreSQL, объектное хранилище, векторные базы данных и движки политик предоставляют разные примитивы изоляции.

Требуемая степень также меняется в зависимости от регулирования, контрактов с клиентами, чувствительности данных, модели угроз и операционного масштаба. Некоторые тенанты могут оправдывать изолированные базы данных или инфраструктуру, в то время как другие используют общие ресурсы.

Концептуальное различие не меняется: разрешение на выполнение операции — это не то же самое, что разрешение на пересечение границы тенанта.

Связанные канонические знания

S01 является предварительным условием безопасности для архитектуры корпоративного ИИ и управления ИИ. Как только инструменты ИИ, RAG или агенты работают с мультитенантными данными, идентичность тенанта должна проходить через извлечение, выполнение инструментов, память, кэши и трассировки аудита.

Это также напрямую связано с агентным ИИ: возможности инструментов и разрешения ролей должны быть ограничены владением тенанта, прежде чем агент сможет читать или изменять бизнес-ресурсы.

Для RAG изоляция тенантов должна применяться до того, как защищенные фрагменты попадут в контекст модели.

Часто задаваемые вопросы

Глоссарий

Заключение

RBAC и изоляция тенантов — это взаимодополняющие, а не конкурирующие механизмы безопасности. RBAC структурирует операционные разрешения; изоляция тенантов ограничивает границу ресурсов, внутри которой эти разрешения могут применяться.

Поэтому надёжный мультитенантный запрос требует большего, чем «у пользователя есть роль ADMIN». Ему нужны проверенный субъект, проверенный контекст тенанта, разрешённая операция, цель в области тенанта и принудительное применение на каждом уровне ресурсов, который может содержать данные, принадлежащие тенанту.

Самое короткое надёжное правило таково: авторизуйте действие, затем изолируйте область — и никогда не предполагайте, что одно доказывает другое.

Первоисточники и актуальные рекомендации

Приведённые ниже источники подтверждают определение RBAC и актуальные рекомендации по изоляции тенантов. Раздел Aaasaasa AI CMS является оригинальным свидетельством реализации и намеренно ограничен теми шаблонами кода, которые были проверены.