RBAC与租户隔离：两种不同的安全边界

RBAC 和租户隔离解决了多租户系统中两个不同的安全问题。基于角色的访问控制（RBAC）决定已认证主体被允许做什么，例如读取订单、编辑产品或管理用户。租户隔离决定该主体被允许访问哪个租户的数据、资源和执行上下文。一个用户可能被正确认证并正确分配了 RBAC 角色，但如果应用程序允许该角色操作另一个租户的资源，仍然会遭遇安全失败。

RBAC 真正控制什么

RBAC 是一种授权模型，其中权限与角色关联，用户被分配到这些角色。角色充当身份与权限之间的管理抽象。

NIST 经典的 RBAC 工作围绕用户、角色、权限、操作和对象将其形式化。实际好处是，组织可以通过相对稳定的工作或职责角色来管理授权，而不是将每个权限直接附加到每个用户。

例如，EDITOR 这样的角色可以表示：可以读取内容、写入内容和发布内容。ACCOUNTANT 这样的角色可以表示：可以读取账单数据、核对发票和批准结算。

租户隔离真正控制什么

租户隔离是一组机制，用于防止一个租户在共享系统中读取、修改、影响或意外接收另一个租户的资源。

受保护的边界比数据库行更广泛。租户特定状态可能存在于关系表、对象存储、向量索引、缓存、搜索索引、队列消息、文件、临时产物、后台作业、分析、速率限制和基础设施资源中。

AWS 的 SaaS 指南明确指出了这一区别：授权授予对资源的访问权限，而租户隔离确保即使基础设施是共享的，这些资源也不会跨越错误的租户边界。

最简单的例子

假设 Alice 是租户 A 的管理员，Bob 是租户 B 的管理员。两个用户都合法地拥有相同的 ADMIN 角色。

RBAC 可以正确判断两个用户都可以执行诸如 users.read 之类的操作。但当 Alice 请求用户 ID 847 时，应用程序仍必须验证用户 847 属于租户 A。

如果 API 只检查“Alice 拥有 ADMIN”，然后执行 SELECT * FROM users WHERE id = 847，那么 RBAC 成功了，而租户隔离失败了。

正确的多租户授权决策

1

1. 认证主体

确定用户、服务或代理是谁。

2

2. 解析已验证的租户上下文

从可信的服务器端身份/成员信息中确定适用哪个租户上下文。

3

3. 解析权限

评估主体的角色或策略是否允许所请求的操作。

4

4. 限定目标资源范围

验证目标对象属于允许的租户或明确共享的范围。

5

5. 在访问边界强制执行

在应用租户约束的情况下执行数据库、缓存、存储、队列或服务操作。

6

6. 审计两个维度

记录主体、租户、操作、目标和结果，以便跨租户尝试可见。

简单示例的局限

真实系统通常包含多种身份类别：租户用户、平台管理员、后台工作进程、集成、代理以及跨租户运营服务。其中一些身份合法地跨越租户边界。

这并不消除隔离的必要性。它意味着跨租户权限必须是显式的、狭窄的且可单独审计的，而不是从全局角色或无范围限制的数据库连接中意外产生的。

租户隔离也可能因层而异。一个产品可能共享应用服务器但分离数据库，或者使用带有行级策略的共享数据库，同时为高级租户提供隔离的存储或计算资源。不存在单一的通用隔离拓扑。

RBAC 与租户隔离

两个不同的安全维度

	RBAC	租户隔离
主要问题
典型单元
示例
典型故障
典型实现
能否单独存在？

认证、授权和隔离是三种不同的检查

这些检查相互关联但不可替代。认证可以完美无缺，而授权却失败。授权可以正确无误，而租户隔离却失败。安全的 SaaS 请求路径需要所有适用的边界。

角色需要作用域

没有作用域，ADMIN 这个词是不完整的。它可以指平台管理员、租户管理员、项目管理员、工作区管理员或某个子系统的管理员。

在多租户系统中，角色分配通常应与租户成员资格或其他显式资源作用域相关联。同一用户可以在租户 A 中合法地是 ADMIN，而在租户 B 中是 VIEWER。

忽略这种区别的全局角色模型，即使权限映射本身是正确的，也可能造成权限泄漏。

租户上下文必须来自可信路径

客户端提供的租户 ID 作为选择器是有用的，但它不是权限的证明。服务器必须根据已认证的身份和当前授权数据来推导或验证租户成员资格。

OWASP 当前的多租户指南建议在请求生命周期的早期建立租户上下文，并明确警告不要将客户端标头或请求参数视为授权证明。

这一点很重要，因为从 tenant=A 到 tenant=B 的简单请求修改不应足以跨越隔离边界。

租户作用域应属于资源查找的一部分

一种常见的应用层隔离模式是在解析资源的同一个查询中包含租户范围。

这种模式不是唯一可能的隔离机制，但它使租户所有权贴近数据访问操作，并防止对象 ID 成为跨租户能力。

应用检查有用，但隔离不应依赖于完美的开发者行为

AWS 的隔离指南明确警告不要将隔离执行仅留给服务开发者。在大型代码库中，最终可能有一个查询、缓存键或工作路径会遗漏租户范围。

因此，纵深防御可以将隔离移至共享中间件、仓库/服务层、策略引擎、数据库行级安全、专用凭据、独立模式或独立数据库，具体取决于风险和架构。

数据库隔离策略

OWASP 当前的多租户安全备忘单列出了独立数据库、独立模式、带行级控制的共享表和混合模型。正确的模型取决于威胁级别、合规性、性能和操作成本。

PostgreSQL 行级安全可以提供纵深防御

对于共享表，PostgreSQL 行级安全可以在数据库层强制执行租户谓词，以便普通查询无法看到活动租户策略之外的行。

然而，RLS 不是魔法。PostgreSQL 超级用户和具有 BYPASSRLS 的角色可以绕过行策略。因此，OWASP 建议使用最小权限的请求路径角色，并测试生产环境中使用的相同连接/池化模式。

连接重用是另一个重要的边缘情况：必须为每个事务/请求安全地设置和重置租户上下文，以便一个池化连接不会泄漏先前的租户状态。

租户隔离必须包括缓存

数据库查询可以完美地限定范围，但仍然通过共享缓存键泄漏数据。

如果 user:42 同时存在于租户 A 和租户 B 中，全局缓存键可能会返回错误租户的值。租户敏感的缓存键应包含每个改变可见性或结果语义的属性，通常是租户、用户、区域设置、功能集或权限版本。

缓存分区是纵深防御，而不是授权的替代品。在返回受保护的缓存内容之前，请求仍然需要被授权。

文件和对象存储需要自己的租户边界

对象存储应区分全局对象、租户范围对象和用户范围对象。除非访问策略实际约束了读写，否则仅靠文件夹前缀只是一种命名约定。

当风险或合规要求更强的隔离时，更稳健的设计可以使用租户感知的对象键、存储桶策略、独立的存储桶/账户或租户特定的加密密钥。

签名 URL 必须在签发前获得授权，并限定到确切的对象和操作。持有对象标识符本身不应授予跨租户访问权限。

后台任务和队列可能破坏隔离

异步任务通常会脱离原始 HTTP 请求上下文，这使得租户传播很容易被错误处理。包含 tenantId 的队列消息不足以证明生产者已获得授权。

工作进程应携带经过验证的服务/用户身份或可信的任务信封，重新建立租户上下文，并在消费者边界对重要操作重新授权。

租户隔离也包括可用性。一个租户不应能够以实质性降低其他租户服务质量的方式垄断共享工作进程、队列、连接池或计算资源。

搜索和 RAG 需要租户感知的检索

多租户 AI 引入了隔离问题的另一个副本。文档在摄取后可能被分块、嵌入并存储在向量索引中。

OWASP 当前的 RAG 安全指南指出，访问控制必须在检索时强制执行，并且租户 A 的块不得被租户 B 的查询检索到。不能简单地假设文档级权限会自动在分块后继续存在。

因此，向量索引需要租户/访问元数据，或根据隔离设计采用物理/逻辑上独立的集合。应在未经授权的内容进入模型上下文之前应用检索过滤器。

派生数据继承租户敏感性

嵌入、搜索索引、缩略图、生成的摘要、缓存、分析行和 AI 响应都派生自源数据。除非显式转换创建了合法的共享/全局产物，否则其租户范围应遵循源数据。

因此，删除和离职处理必须传播到规范行之外。删除租户文档但保留可搜索的块或缓存摘要，可能会保留跨租户或保留期后的暴露风险。

并非所有内容都属于某个租户

多租户平台通常有意设置全局资源：产品分类、公共模板、系统权限、功能定义或公共内容。

最安全的模型是显式分类：全局、租户范围、用户范围或显式跨租户。模糊的资源正是意外泄漏开始的地方。

有意共享的对象应当有文档化的理由说明其为何是全局的，而不是仅仅缺少租户关联。

平台管理员需要不同的权限模型

平台运营者可能需要为支持、合规或基础设施运维而检查多个租户。将其建模为普通的租户 ADMIN 并意外拥有全局数据库访问权限，会削弱安全性和可审计性。

更好的设计使用独立的平台身份或显式的跨租户权限、更强的身份验证、目的限制、详细审计，以及在适当情况下使用审批或紧急访问控制。

因此，跨租户访问应当是一项具名能力，而不是缺少租户过滤器。

RBAC 可以与属性结合使用

有些决策取决于角色之外的因素。租户成员身份、区域、资源所有者、订阅层级、时间、项目成员身份或数据分类都可能影响访问。

RBAC 和 ABAC 并不互斥。AWS 当前的多租户授权指南讨论了 RBAC、ABAC 和混合模型。角色可以定义广泛的职责，而属性则约束可以访问哪些具体资源实例。

关键架构规则仍然不变：如果租户身份是一等资源边界，就不要仅将租户隔离编码为附带的角色名称。

授权决策至少是二维的

原始实现证据：Aaasaasa AI CMS

RBAC 服务定义了类型化权限代码，例如 cms.content.read、shop.orders.write、billing.reconcile 和 users.roles。系统角色将这些权限映射为具名职责集。

角色记录使用 tenantId 创建和解析。系统角色使用租户/代码复合身份进行 upsert，角色列表按租户过滤。

角色更新和删除首先使用角色 ID 和租户 ID 解析角色。用户-角色分配也在当前租户上下文中存储和替换。

权限解析读取按 tenantId 和 userId 双重限定的显式用户-角色分配。这防止一个租户的角色分配自动变成另一个租户的角色分配。

在 API 层面，管理性 RBAC 路由在创建或修改角色之前会先解析租户上下文。这是正确的方向：权限管理本身也必须遵守租户隔离。

为什么这一区分对 AI 代理更为重要

AI 代理可以将权限错误转化为一系列操作。如果代理被授予宽泛的 orders.read 工具而没有租户范围的强制执行，推理或提示注入失败可能导致以机器速度进行跨租户读取。

代理工具描述可以提及租户约束，但强制执行仍必须在受信任的运行时/服务/数据层进行。自然语言指令不是授权边界。

这同样适用于 RAG：代理可以拥有使用搜索工具的权限，但搜索后端仍必须防止租户 A 的查询返回租户 B 的块。

分别测试 RBAC 和租户隔离

OWASP 的授权回归指南特别指出跨租户边界测试，因为缓存、查询或共享服务中的代码更改可能会在角色测试继续通过的情况下悄然破坏隔离。

常见故障模式

常见误解

实用的设计顺序

将权限和隔离设计为独立维度

1

1. 定义租户所有权

对哪些实体和资源是全局的、租户范围的、用户范围的或有意跨租户的进行分类。

2

2. 定义操作

为读取、写入、发布、审批、管理和其他业务操作创建显式权限。

3

3. 定义角色

根据职责对权限进行分组，而不嵌入意外的全局范围。

4

4. 定义成员资格范围

将角色分配绑定到其适用的租户/工作区/项目上下文。

5

5. 解析受信任的租户上下文

从经过身份验证、服务器验证的成员资格或服务授权中派生租户身份。

6

6. 强制执行资源所有权

在每个租户拥有的数据/服务边界应用租户范围。

7

7. 添加纵深防御

在风险需要时使用 RLS、独立凭据、模式/数据库、存储策略或策略引擎。

8

8. 将范围传递到派生系统

在缓存、搜索、向量索引、队列、文件和分析中保留租户元数据。

9

9. 显式建模跨租户操作

将平台管理和服务身份与普通租户角色分开。

10

10. 测试两个轴

分别针对缺少权限和错误租户运行负面测试。

11

11. 一起审计租户 + 权限

记录谁在哪个租户、对什么目标、以何种权限执行了操作。

12

12. 在模式/运行时更改后重新测试

引入新表、缓存、队列或检索路径时，隔离可能会被破坏。

RBAC + 租户隔离检查清单

边界情况与限制

一个用户可以属于多个租户。因此，当前租户应当是一个明确的执行上下文，而不是从用户账户中永久推断出来的。

有些资源是有意在选定的租户之间共享的，例如协作空间或联盟数据。这需要一个明确的共享模型；假装资源属于某一个租户，然后再添加例外，通常会导致授权变得模糊不清。

吵闹邻居隔离与机密性隔离相关但不同。一个租户可能永远看不到另一个租户的数据，但仍然可能耗尽共享的 CPU、队列容量或数据库连接。因此，速率限制和资源配额可以作为可用性边界，按租户进行感知。

如果控制平面凭据或管理路径可以跨越边界，物理隔离并不自动安全。如果策略被集中执行、最小权限化并经过充分测试，逻辑隔离也并不自动薄弱。

租户隔离要求可能因数据类别而异。公共目录数据、账单记录和私有 AI 文档可能需要在同一个 SaaS 产品内采用不同的存储和加密边界。

什么会改变这个答案？

具体实现会随架构而变化：无服务器 API、Kubernetes、PostgreSQL、对象存储、向量数据库和策略引擎暴露出不同的隔离原语。

所需的强度也会随法规、客户合同、数据敏感性、威胁模型和运营规模而变化。有些租户可能需要隔离的数据库或基础设施，而其他租户则共享池化资源。

概念上的区别不会改变：执行某项操作的权限与跨越租户边界的权限不是一回事。

相关规范知识

S01 是企业 AI 架构和 AI 治理的安全边界前提。一旦 AI 工具、RAG 或代理在多租户数据上运行，租户身份就必须贯穿检索、工具执行、记忆、缓存和审计追踪。

它也与代理式 AI 直接相关：在代理能够读取或修改业务资源之前，工具能力和角色权限仍然必须受到租户所有权的约束。

对于 RAG，必须在受保护的分块进入模型上下文之前强制执行租户隔离。

常见问题

RBAC 与租户隔离常见问题

RBAC 和租户隔离有什么区别？

RBAC 决定主体可以执行哪些操作。租户隔离决定这些操作可以访问哪个租户的资源。安全的多租户应用程序通常需要两者兼备。

ADMIN 角色是否自动允许访问所有租户？

不。ADMIN 应当具有明确的范围。租户管理员通常只在该租户内拥有广泛权限，而跨租户的平台管理应当单独建模。

仅靠身份验证就足以实现租户隔离吗？

不。身份验证证明身份。授权控制允许的操作。租户隔离还额外防止这些操作触及错误租户的资源。

tenantId 应该存储在 JWT 中吗？

它可以作为租户上下文的输入之一，但服务器必须验证当前成员资格/权限，并在受保护资源边界处强制执行范围。仅凭声明不能取代隔离控制。

我需要为每个租户使用单独的数据库吗？

不一定。共享表、RLS、模式、数据库、基础设施和混合隔离模型都可能有效，具体取决于风险和运营要求。

PostgreSQL RLS 可以取代应用程序代码中的租户过滤器吗？

RLS 可以提供强大的纵深防御，但正确的数据库角色、请求上下文、策略覆盖范围和应用程序级授权仍然很重要。

RAG 应如何强制执行租户隔离？

应在检索期间强制执行租户/访问范围，以便未经授权的分块永远不会进入模型上下文。在分块和索引过程中保留访问元数据。

一个用户可以在不同租户中拥有不同角色吗？

可以。这在 B2B SaaS 中很常见，也是将角色分配按租户成员资格进行范围限定的有力理由，而不是将角色视为全局附加到用户。

测试租户隔离的最佳方法是什么？

使用负向跨租户测试：创建至少两个租户，在一个租户中为用户授予有效权限，然后证明每个受保护路径都拒绝对另一个租户资源的访问。

术语表

关键多租户安全术语

RBAC

基于角色的访问控制：一种授权模型，将权限与角色关联，并将用户或主体分配到这些角色。

租户

共享多租户系统中的客户、组织、工作区或其他隔离的逻辑消费者。

租户隔离

防止一个租户在共享系统中访问、修改或接收另一个租户资源的机制。

身份验证

验证用户、服务或其他主体身份的过程。

授权

确定主体是否可以对资源执行所请求操作的决策过程。

权限

已定义的允许操作或能力，例如 orders.read 或 users.write。

角色

与职责或职能相关联的权限的命名分组。

ABAC

基于属性的访问控制：基于主体、资源、操作或环境属性的授权。

行级安全

数据库策略机制，限制数据库角色或会话可以读取或修改哪些行。

跨租户访问

在一个租户上下文中运行的主体访问属于另一个租户资源的任何访问路径。

平台管理员

具有明确建模权限的特权操作身份，可能跨越多个租户。

租户上下文

当前请求、作业或代理操作执行时所处的已验证租户范围。

结论

RBAC 和租户隔离是互补的安全机制，而非相互竞争。RBAC 构建操作权限；租户隔离约束该权限可以适用的资源边界。

因此，一个健壮的多租户请求需要的不仅仅是“用户拥有 ADMIN 角色”。它需要已验证的主体、已验证的租户上下文、允许的操作、租户范围内的目标，以及在每个可能承载租户数据的资源层上执行强制措施。

最简短可靠的规则是：授权操作，然后隔离范围——并且永远不要假设其中一个能证明另一个。

主要来源和当前指南

以下来源支持 RBAC 定义和当前租户隔离指南。Aaasaasa AI CMS 部分是原始实现证据，并有意限定在已验证的代码模式范围内。

NIST — 基于角色的访问控制

NIST 对 RBAC 模型和 INCITS RBAC 标准的概述，包括用户、角色、权限、操作和对象。

NIST CSRC — RBAC 术语表

NIST 当前术语表对基于角色的访问控制的定义，即通过角色进行权限分配。

AWS — 隔离思维模式

AWS SaaS 指南明确区分身份验证/授权与租户隔离，并推荐共享隔离机制。

AWS — 多租户授权常见问题

当前指南解释 SaaS 应用程序中授权与租户隔离之间的区别。

AWS — 多租户设计考虑因素

当前 SaaS 指南区分租户隔离与授权，并讨论池化/隔离授权策略模型。

OWASP — 多租户应用程序安全备忘单

当前关于租户上下文、数据库隔离、缓存、存储、队列、测试和跨租户访问预防的实用指南。

OWASP — RAG 安全备忘单

当前指南要求在检索时进行访问控制，并为多租户向量存储提供租户隔离。

OWASP — 授权回归测试

当前测试指南，包括角色降级和跨租户边界测试。