1. B2B多租户权限概述：租户隔离模型、权限核心概念、RICE角色定义来源

1.1 什么是多租户与租户隔离

在SaaS/B2B环境中，多租户（Multi-tenancy）指单个软件实例同时为多个组织（租户）提供服务，每个租户的数据和配置在逻辑上相互隔离。租户隔离模型决定了隔离的深度与成本。

隔离模型	核心特征	典型适用场景
数据库级隔离	每个租户独立数据库，数据完全物理隔离	金融、医疗等高合规行业
Schema级隔离	共享数据库，每个租户独立Schema	中型企业SaaS
表级隔离	共享数据库和Schema，通过租户ID字段区分	成本敏感型SaaS（如CRM）
混合隔离	根据租户等级动态切换隔离策略	大型平台型SaaS

1.2 权限核心概念：主体、资源、动作、条件

所有权限系统都围绕四个核心要素构建：

• 主体（Subject） —— 谁发起请求？可能是用户、API密钥、服务账户。
• 资源（Resource） —— 访问什么？如项目、订单、报告。
• 动作（Action） —— 做什么？如读取、创建、删除、审批。
• 条件（Condition） —— 在什么上下文？如时间、IP、租户内分支部门。

在B2B多租户中，条件常包含“所属租户ID”，从而将权限锁定在租户边界内。

1.3 RICE角色定义来源

RICE 是权限架构中抽象出的四种角色类型来源的缩写，由行业实践总结而来：

缩写	全称	含义	典型示例
R	Role-based	基于角色的权限	RBAC：管理员、编辑、查看者
I	Identity-based	基于身份的细粒度策略	ABAC：“只允许本部门经理访问客户数据”
C	Contextual	基于上下文（租户、时间、位置）	“仅在上班时间访问生产环境”
E	Entitlement-based	基于产品订阅/购买权限	“购买了高级分析模块的用户才能看报表”

1.4 类比：写字楼租赁与门禁系统

想象一栋多租户写字楼：

• 租户隔离模型 = 每个公司独占一层（数据库隔离）还是共享楼层隔断（表级隔离）。
• 主体 = 员工卡。
• 资源 = 会议室、机房、库房。
• 动作 = 进入、刷卡、开门。
• 条件 = 只能在办公时间允许非本层访客进入。
• RICE角色：保安（Role）、CEO（Identity）、加班时段（Context）、购买了VIP停车位（Entitlement）。

这个类比清晰地展示了多租户权限的本质——在物理/逻辑隔离基础上，通过灵活的策略控制跨租户或租户内的访问。

1.5 常见误区

• ❌ "租户隔离好了就不需要权限控制" — 即使数据完全隔离，租户内部仍然需要RBAC或ABAC；同时跨租户超级管理员、审计、业务协同场景也需要精细权限。
• ❌ "RICE就是另一种RBAC" — RICE是对权限来源的分类法，RBAC只是其中R（Role-based）的一种实现；现代系统常叠加I、C、E以满足复杂B2B业务。
• ❌ "统一用一个角色模型就行" — B2B场景下，不同租户对角色粒度要求差异巨大，必须支持“租户级角色定制”与“全局模板”并存。

1.6 练习题

1. 假设你正在设计一个医疗SaaS（多租户），要求：a) 不同医院数据必须物理隔离；b) 同一医院内不同科室（心内科、骨科）医生只能查看本科室患者记录。你会选择哪种隔离模型？权限控制应采用RICE中的哪些维度？说明理由。
2. 某SaaS客户抱怨：员工离职后，使用该员工账号共享的文件夹仍然能通过链接访问。请从RICE角度分析问题可能出在哪个来源维度？应如何修复？

1.7 应用边界

• 适用场景： 所有SaaS、PaaS、IaaS平台；需要为多个组织提供独立工作空间的企业软件；政务系统的多部门协同。
• 不适用场景： 完全单租户的本地部署软件（无需多租户隔离）；纯个人消费级App（无组织概念）；静态权限配置远少于10个角色的微型系统（使用RICE设计显得过度工程）。