基于RBAC的模式的多租户权限设计
最近因为产品版本迭代，要在原有的产品账户架构的基础上，增加多租户的权限设计。多租户的账户架构目前是SAAS类产品对外提供服务所必须的一种账户体系架构，例如在云平台上，公有云要利用多租户的账户体系完成账户的增值服务，私有云要依靠多租户的账户体系完成集团公司内部的资源管理。
其实我在之前的产品工作中已经经历过一次多租户的账户体系设计，说是账户体系设计，其实是一次比较大的账户体系优化。过程中设计了无数种方案，都在深度思考之后被否决掉。
经过这两次的账户体系优化改造，明白几个点：
账户体系优先。一个产品从0-->1的过程中，一定要优先把账户体系设计完成并且要考虑周全，因为以后所有的业务均是在账户体系上面搭建。这就好像盖房子，你要先把地基搭建好，上层建筑都是在这个的基础上搭建，一旦地基要调整，可能就会出现伤筋动骨的情况。
产品冗余设计。没有一种架构体系能够满足所有的需求，你也不可能预料到未来所有的情况。所以在此基础认知上，我们在已开始设计的时候，就要尽可能多的容纳未来的，不求满足所有。
账户体系架构
一般来说，用户体系是一套关于系统用户分类、成长、关系、社交等概念的融合体系，通过良好的用户体系设计，可以精准匹配用户需求，提供更好的用户体验。根据产品形态的不同，用户体系也大致可以分为C端产品用户体系和B端产品用户体系。
（1）C端产品用户体系
C端产品是我们日常生活中使用最频繁的产品，通常的，它的用户体系一般包括个人成就、财富激励、社交关系等方面。比如360安全的积分兑换，微博的会员成长体系，QQ的勋章，小红书的等级体系；分别代表了用户成长体系、用户激励体系、用户增长体系、用户运营体系等常见的C端用户体系。
C端用户体系的最终目的都是为了提升用户体验、增加用户黏性、激励用户行为，并服务于实现产品的终极商业目的。
（2）B端产品用户体系
B端产品主要用于满足用户日常的工作、管理需求，所以常见的业务场景包括日常办公、资源管理、业务流转等；在B端常见的账户体系中OA产品应该是最常见且使用最频繁的产品。
B端产品的最终目的是满足用户的日常工作管理需要；一款好的B端产品首先肯定是一款简单易用的管理工具，其最终目的是为了提高工作效率、降低管理成本、维护数据安全。在这里，用户体系扮演着极其重要的角色，正是用户体系中的组织结构、权限管理的实现才是应用系统的人员管理、业务流程、数据安全得以保障。在B端用户体系大框架之下，针对不同的产品，我们也会设计不同的用户体系，以反映每种产品面向的用户群不同。
我没有做过C端的产品，一直在和B端产品打交道，在B端产品中，账户体系最重要的就是把控要权限，各个用户之间的权限划分，其实是最重要的。其中常见权限设计模式采用基于RBAC模型。
模式架构是：用户==>角色===>权限==>资源。
我们产品也是使用这种模型。当然不同行业可能使用的权限设计还是不一样的。比如说：MAC 强制访问控制模型，一般使用在保密系统中；ABAC 基于属性的访问控制，一般使用在防火墙中，等等。
模型没有最好，只有最适合。
RBAC模型
RBAC（Role-Based Access Control) 基于角色的访问控制的设计思想。将权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
这样解释可能有点麻烦，简单举个例子：技术支持角色，拥有查看资料的权限。当技术支持部门的一个新人入职，运维部门只需要将这个新人划分入技术支持分组下，他便会拥有技术支持这个角色，同样就会具备查看资料的权限。这样的话权限变动便很简单，只需要将不同角色赋予这个账户，那么他便拥有这个角色的权限。
具体划分如下：
权限表
名称：创建客户
资源: 客户信息
操作：创建
名称：删除客户
资源: 客户信息
操作：删除
名称：查看客户
资源: 客户信息
操作：查看
名称：修改客户
资源: 客户信息
操作：修改
角色表
名称：销售角色
权限: 创建客户、删除客户、查看客户、修改客户
用户表
主体：小王
角色: 销售角色
基于RBAC的模式的多租户权限设计
假如我们的产品需要采用SaaS的模式对外提供增值服务。目标就是如何规划好平台的管理、租户的管理、租户应用的管理以及租户业务流程等内容的管理。我们将SaaS平台基本角色分为平台管理员、平台运维、平台开发、租户管理员、租户子管理员、租户其他角色组成。
如图所示：
（1）平台管理员：属于超级管理员权限，该账户应该归属于产品所有者来拥有，一般情况是集团公司的运维人员来负责，如果在云平台上，当归属于云平台管理人员拥有。
（2）租户A/B/C：属于租户级别，云平台管理人员可以手动开通账户，分配给一个用户进行使用。如果在公有云上，例如阿里云平台，用户可以自己创建自己的账户。创建账户完成之后，用户即可拥有这个账户的所有权限，用户可以自己开通自己的资源，并配置相关数据。租户A/B/C之间完全隔离，不可视。
（3）组织结构：在RBAC权限划分中，属于用户模块。在私有云的环境中，不同部门会有不同部门的权限。比如说：产品部，可能只有资源的使用权，没有资源的开通和删除的权限。这样最直接的好处就是用户不用通过设置不同的角色即可完成对权限的划分。
（4）角色组：在系统中，存在相同属性或操作功能的用户存在。随着使用的用户基数增大、角色类型增多时，分配的工作就会越发的繁琐。这里可以增加用户组的概念来统一规划这一部分用户的权限管理。在上面的设计中，角色组中的岗位、职位就充当了这部分的作用。以后其他用户加入对应的用户组（角色组）后，即可自动获取用户组的所有角色。退出用户组，同时也撤销了用户组下的角色，无须管理员手动管理角色。
落地方案
当我们在对产品进行账户体系或者权限设计的过程中，我们要充分考虑到实际情况：
不同公司或者不同产品甚至面对不同客户，在做账户需求设计的时候都需要不同的账号体系设计方案。落地方案要充分理解需求。
如果我们在做账户体系改动的时候，更要充分考虑到对现有的数据和产品架构的影响程度。一不留神就会被程序员们打了，一杯星巴克肯定少不了了。
我们在做这块的时候更要考虑到成本问题，包括时间成本和人力成本。万一甲方爸爸只是让你做一个茅草屋，你给他砌了一个城堡，那估计甲方也只能用到你城堡中的一个屋子啦。