多租户 SaaS 权限：将组织、团队与角色讲清楚

如果你的应用服务不止一个客户，在写规则之前先把心智地图画清楚。多租户 SaaS 权限的大多数混淆来自定义义漂移——同一个词在产品不同地方意味着不同事。

为租户边界挑选一个含义并坚持它。很多产品把 “organization” 当作租户：所有数据都在组织内，除非你显式构建共享，否则数据不会跨组织流动。

一个简单且随规模保持清晰的词汇：

• 组织（Organization/tenant）： 客户账户和硬性的数 据边界。
• 用户（User/identity）： 拥有一个登录的人。
• 成员关系（Membership）： 表示某用户属于某组织并具有特定角色的链接。
• 团队（Team，可选）： 组织内日常工作的分组。
• 资源（Resource）： 任何需要保护的对象（项目、发票、工单、API 密钥）。

“一个人属于多个组织”是常态。顾问可能同时属于三个客户组织，每个组织里的角色不同。因此“用户”和“成员关系”需要分开。大多数权限检查都基于成员关系，而不是用户本身。

团队在能反映真实分组（例如“支持”或“财务”）时很有用。当团队变成第二套权限系统时，它们就是噪音。一个实用的测试是：你是否能用一句话解释该团队的作用而不提到某个具体功能规则。

示例：Maria 用同一个登录切换 Org A 和 Org B。在 Org A 她在财务组并能查看发票；在 Org B 她是查看者只能读取项目。相同用户，不同成员关系，一致的资源类型，边界清晰。

角色、权限与作用域，用通俗话说

当你把三件事分开时，多租户 SaaS 的权限会更容易理解：

• 角色（Roles）： 描述职责的标签。
• 权限（Permissions）： 可以执行的操作。
• 作用域（Scope）： 在哪里能执行这些操作。

用白话理解 RBAC

RBAC（基于角色的访问控制）意思是：你把某个角色赋给用户，角色决定允许的操作。角色名称应描述职责，而不是状态。“Billing Admin（计费管理员）”就很清楚。“Power User” 通常会引起争议。

把权限当作动词并在整个产品中保持一致：

• 查看（View / 读取）
• 创建（Create）
• 编辑（Edit）
• 删除（Delete）
• 管理（Manage：邀请、设置、导出等特殊操作）

然后加入作用域，这样相同的动词就能在不同场景下重复使用。这能避免创建 20 个几乎相同的角色。

常见且易读的作用域有：

• 全组织（Org-wide）
• 仅团队（Team-only）
• 自有（Own items）
• 被指派（Assigned）

当所有权比新增角色更合适时

如果你发现自己创建了“Project Editor”和“Project Editor (Own)”这类角色，通常是作用域问题，而不是角色问题。

示例：在 CRM 中，让 “Sales Rep（销售代表）” 能创建和编辑交易，但把作用域限制为“仅自有”。让 “Sales Manager（销售经理）” 拥有类似动词但作用域为“团队内”或“全组织”。这样你能少用角色、规则更清晰，当有人换团队时也不容易出现意外。

一个稳妥的默认策略是：角色授予动词，所有权（或指派）限制这些动词生效的范围。

一个能扩展到数百个组织的简单规则集

如果你的模型对一个客户有效但在十个客户时就崩了，你很可能把“谁能看”与“谁能做”和“谁是所有者”混在一起了。把它们分开，系统就可预测了。

一个可扩展的规则集：

• 每条记录（项目、发票、工单、API 密钥）恰好属于一个主组织（home organization）。
• 用户只能看到其为活跃成员的组织的数据。如果他们不是该组织成员，UI 和 API 应表现得像该组织不存在一样。
• 角色控制操作（创建、编辑、删除、导出），但仅在用户已看得见的组织内生效。
• 所有权作为决定性因素。它可以在允许的作用域内授予额外权限（编辑自己的草稿、管理自己的 API 令牌），但不扩大对其他数据的访问。
• 管理员权限是窄而明确的例外。定义“管理员”能做什么，并保持管理员角色数量少。

示例：Sam 属于 Org A 和 Org B。在 Org A，他是成员，能创建和编辑自己的报告，但不能更改计费；在 Org B，他是计费经理，能更新支付方式并下载发票，但除非他的成员关系包括相应区域，否则仍看不到私有项目。

这会让扩展变得“无聊而好”：添加新组织只是增加成员关系和角色，核心规则不变。

逐步：在一页纸上设计你的权限模型

写一页纸，让队友两分钟内能读懂。如果你能在不开代码的情况下解释权限，那就说明状态良好。

1) 在规则之前写清输入项

把要素故意写小一些：

• 选择四个能说明白的用户类型：所有者（Owner）、管理员（Admin）、成员（Member）、查看者（Viewer）。
• 列出 3–6 个日常触及的资源（项目、客户、报告、计费）。
• 对每个资源列出 2–4 个动作（查看、创建、编辑、删除、邀请、导出）。
• 决定新成员默认权限（通常是 Viewer 或 Member，而不是 Admin）。
• 决定“团队”改变什么：把它限制在可见性、指派和报表上，而不是带来意外权限。

2) 把规则放到简单表格里

用作用域避免角色爆炸。很多产品只需三种作用域：自有（own）、团队（team）、组织（org）。

自检：把这页给非技术同事看，问一句 “Support 成员能编辑 Sales 报表吗？” 如果他们犹豫，说明你的作用域或团队定义不清。

保持理性的资源所有权与共享规则

为了让权限易于理解，先决定谁是每类资源的所有者，然后限制共享选项。

默认所有权模型

让大部分资源归组织所有。客户通常按公司来思考：发票、项目、联系人、工单和自动化属于组织，不属于某个人。

团队仍然有用，但把团队当作用于路由和可见性默认的工作流标签，而不是隐性的安全逻辑。团队标签可驱动筛选、仪表盘、通知或队列，而访问仍由角色和作用域决定。

用户拥有的资源应为例外，保留给真正个人化的项：草稿、私密笔记、保存的视图、API 令牌或个人设置。当用户离开时，决定处理方式：删除、转移或保留为私有。

一组可读性强的共享规则：

• 默认归组织所有：在一条记录上存储组织 ID。
• 团队标签用于工作流：标记到某团队以便路由，但不是硬性访问控制。
• 用户拥有用于个人项：默认私有，除非显式共享。
• 共享级别仅限于：私有（仅所有者）、团队、组织。早期避免每项自定义 ACL。
• 把“被指派（assigned to）”和“能访问（can access）”分开：指派是责任，不是权限。

保持简单的共享策略

当有人说“我需要访问”时，引导他们选择是哪一级别：他们的个人项、他们团队的工作，还是整个组织。如果不属于这三类，通常说明你的作用域不清晰，而不是需要新共享模式。

示例：一个工单可以归组织所有（便于管理层做全量报表），标签为 Support 团队（进入正确队列），并指派给 Jordan（Jordan 对此负责）。指派不应阻止其他有权查看的角色访问它。

邀请、成员变更与切换组织

权限常在“人员事件”时出错：邀请、在团队间移动或移除访问。这些流程决定你的模型是否可预测。

邀请

把邀请视为创建成员关系的请求，而不是本身就赋予访问。邀请应说明组织、团队（可选）和接受后将获得的角色。

保持规则严格：

• 只有特定角色可以发邀请（例如 Owner 和 Admin）。若支持团队负责人，可限制其只能邀请进自己团队。
• 发起人只能授予不高于自己级别的角色。
• 过期邀请无效。
• 若电子邮件已有账号，接受后只会把该账号附加到组织；若没有，则创建账号并附加。

临时访问也可在这里处理。不是发明“临时用户”角色，而是允许角色授权带结束日期；到期后访问自动取消，并保留审计记录。

离开与不丢失所有权

当某人离开组织时，不要自行决定其资源如何处理。如果你的规则是“资源归组织所有”，就坚持它。此人可以保留作为创建者以保留历史，但组织仍是所有者。

如果存在用户拥有的资源，要求在移除前完成敏感项的转移（项目、文档、API 密钥）。

安全地切换组织

一个登录可以属于多个组织，但应用始终必须有一个“当前组织”。在 UI 明显标示并把所有操作限定到当前组织。

停用通常优于删除。停用能立即移除访问同时保留历史可审计。

常见错误与陷阱

大多数权限模型失败是因为规则增长速度赶不上变化。保护好基础（租户边界、所有权、作用域），把其他都当作细节处理。

角色爆炸是经典陷阱。出现边缘情况就创建新角色，而不是用更清晰的权限或作用域解决。几个月后没人知道 “Manager Plus” 到底是什么意思。如果某个特性常被需要，就把它做成一项一级权限；若很少用，用有到期的临时授权处理。

权限漂移更安静却更糟。有人添加了“就这一个例外”然后忘了更新一页纸模型。一年后，书面规则与真实系统不一致。先更新模型，再实现代码。

把团队当作假的安全边界会导致持续混乱。如果资源可以在组织内跨团队共享，要明确说明；如果不能，应该在代码中强制执行，而不是靠名字约定。

早期的危险信号：

• 有一个“超级管理员”默认能看到所有客户组织的数据
• 只有 UI 保护（隐藏按钮）而没有后端校验
• 绕过成员关系规则的 API 密钥和服务账号
• 角色按职位定义而不是按动作定义
• 解释不清的一堆例外

如果支持人员需要帮助客户，“给他们全局管理员一会儿”就是租户泄漏的诱因。更好的做法是明确、可记录且范围严格的临时访问（限定一个组织、时间窗和具体动作）。

发布权限前的快速检查

每个请求应先解析出活动组织（从子域、请求头、会话或路由），若不匹配就拒绝。

在组织上下文之后，把检查按一致顺序执行：先成员关系（他们是否在此组织？）、再角色（在此组织他们被允许做什么？）、最后是所有权或共享（他们是否对这条记录有访问？）。若先做所有权检查，可能会泄露记录是否存在。

用真实账号跑一小组端到端测试，而不是仅靠单元测试：

• 新成员尝试查看、创建和导出数据
• 团队负责人尝试仅管理自己团队而非整个组织
• 组织管理员更改角色后尝试敏感操作（删除、导出）
• 被移除的用户在旧标签页中重试操作
• 受邀但未接受的用户尝试利用旧邀请访问

为改变权限或移动数据的操作添加基本审计事件：角色变更、成员移除、导出、删除、设置更新。第一天不需要完美，但需要能回答“谁在什么时候做了什么？”

检查默认值。新组织和新成员应以最低能成功所需的访问开始。一份面向支持和销售的内部权限 FAQ 也有帮助，包含诸如“团队负责人能否看到其他团队？”和“移除后访问怎么办？”等示例。

示例：从一个组织扩展到数百个而不重设计

从一个小而真实的设置开始：一家公司（一个组织），两个团队——销售和运营。每个人登录一次，然后选择其所属组织。销售需要客户记录和报价，运营需要计费和内部设置。

阶段 1：一个组织，两个团队

把团队当作分组和工作流，而不是主要的权限开关。团队可以影响默认值和路由，但不应作为唯一门槛。

阶段 2：稳定的角色，可预测的作用域

选择一小组稳定的角色并在功能上线时保持不变：Admin、Member、Viewer。角色回答“在这个组织你能做什么？”，作用域回答“在哪些对象上能做？”。

阶段 3：所有权让编辑决策变简单

增加一条所有权规则：每个资源有组织和所有者（通常是创建者）。编辑在你是管理员，或你是所有者且你的角色包含“编辑自己的”时被允许。查看在你的角色包含该资源类型的“查看”时被允许。

示例：一名销售成员创建了一份报价。另一名销售成员可以查看，但不能编辑，除非该报价被共享给团队或重新指派。运营的查看者只有在规则允许运营查看销售资源时才能看到它。

阶段 4：200 个组织，相同规则

当你入职 200 个客户组织时，重复使用相同的角色和相同的所有权规则。你只变更成员关系，而不是模型本身。

支持请求如“你能给 X 访问吗？”会变成一个清单：确认组织和资源，检查该用户在该组织的角色，检查所有权和共享，然后更改角色或共享资源。避免一次性例外，并留下审计说明。

下一步：安全地实现、测试与迭代

把那一页纸模型当作契约。只实现你能在每个 API 调用和每个 UI 屏幕上强制执行的规则，否则权限就会滑向“视情况而定”。

从小处开始：少量角色、清晰的作用域、简单的所有权。当有新需求（“我们能增加一个 Editor-Manager 角色吗？”）时，先考虑收紧所有权或作用域。新角色应当罕见。

为每个新增资源统一基础：

• 存储 org_id（若适用也存 team_id）
• 有可见性规则（私有、团队、组织）
• 为敏感操作记录审计事件（邀请、角色变更、导出）
• 在每个查询中按作用域过滤（不仅仅在 UI）
• 具有可预测的默认值（创建后谁能立即看到）

在修饰边缘情况前先测试真实流程：邀请、切换组织、管理页以及有人在会话中途失去访问权限时的表现。

如果你用基于聊天的应用构建器开发，先用通俗语言写好权限模型并把它随产品规范放在一起会有帮助。在 Koder.ai (koder.ai) 上，Planning Mode 加上快照与回滚是一种实用方式，用来试验这些场景并确认规则在 Web、后端与移动端表现一致。