所有者、编辑者、查看者:Rexfin 权限模型的真实运作方式

小型 SaaS 工具的权限模型往往落入两种糟糕的形态之一:因为团队小，所以人人都能做任何事;或者硬塞进一套企业级 RBAC 系统，而三人财务团队里根本没人要求过这种复杂度。Rexfin 选择了更窄的中间路线:三种角色，各自职责分明，每次都在服务器端强制执行，而不仅仅是在菜单上隐藏选项。

三种角色，而非一张权限矩阵

所有者可以邀请队友、更改任何人的角色、停用成员，这是唯一能做到这些的角色。编辑者可以上传文档、审阅文档、运行情景并生成导出文件。查看者可以看仪表盘、报表并提问，但不能上传或更改任何内容。这大致刻意贴近多数财务团队的真实需求:一个人负责运营工作区，一群人负责实际工作，还有一群人消费产出结果，大体上相当于总监、分析师和阅读他人做好的材料包的董事会成员。

三种角色之下都遵循同一条规则:一个工作区永远不能出现零所有者的状态。如果最后一位所有者试图自我降级，或被他人停用，系统会阻止该操作。这条规则听起来理所当然，但考虑一下它防止的竞态条件就会明白其必要性:两位所有者几乎同时相互停用对方，原本可能导致工作区无人负责。Rexfin 在事务层面就堵住了这个漏洞，而不是靠一个手快就能绕过的警告弹窗。

停用，而非删除

在 Rexfin 上把某人移出工作区是一个软操作，而不是硬删除。停用一名成员会原子性地完成三件事:标记其为非活跃状态、撤销其当前持有的每一个会话、并写入一条记录说明操作人和操作时间。该成员会被立即登出，不是“最终会”登出，也不是“等 token 下次过期时”才登出，因为每一个受保护的请求都会针对数据库校验会话状态，而不仅仅在边缘节点靠签名 cookie 验证。被停用的账户无法重新登录，发送到该账户的密码重置链接也不起作用。

不会发生的是静默的级联删除。被停用者撰写的评论、情景和审计条目会原样保留在原位，仍然归属于该人，界面上只是注明其已被移出团队，这样历史记录保持完整，也没有人需要解释记录中出现的空白。一个尚未被接受的待处理邀请可以被直接撤销。但一个已经被接受的邀请不能被撤销得像从未发生过一样;系统会明确提示你改为停用该成员，因为在审计追踪中假装一个活跃账户从未被邀请过，是一种更糟糕的失实。

每一次变更都被记录，跨工作区试探无路可走

每一次角色变更和每一次停用都会在该工作区自己的审计日志中写入一行记录:谁做的、对谁做的、改了什么。这份日志正是当审计人员问“谁在何时拥有过这些数据的访问权”时，你能直接拿出来的记录，而不是靠记忆重建的说法。

访问检查在服务器端对每一次变更操作执行，并且首先限定在调用者自己所属的工作区范围内。如果试图对一个你不属于的工作区中的资源进行操作，你得到的是一个普通的 404,而不是 403,系统甚至不会确认该资源是否存在，而不只是拒绝你访问它，这一点很重要，因为 403 会不经意地告诉试探者“是的，这个资源存在，只是你没权限”,而 404 则什么都不透露。

这在整体格局中的位置

以上都不能替代企业级 SSO 或一套完整的 RBAC 层级体系，这是针对 Rexfin 目前所服务的团队规模做出的刻意范围取舍，而非疏漏。想了解这如何与平台其他控制措施相配合，可参阅安全架构概览;想了解新队友在每种角色下第一天实际看到的内容，可阅读第一周入职指南。以上内容也是 Rexfin 直接向潜在客户的安全团队展示的内容之一，详见信任中心,或浏览完整的专题中心。