RBAC权限设计——理论篇（转行后的第一篇文章）
RBAC权限moxing
不知不觉已经转行3年，从工业设计——电商——工作室——产品经理，可谓也是经过了很多的行业锤炼，才再30岁找到自身的发展方向。这是3年转行后的第一篇文章输出，既是知识分享，也是转行后的成果输出。
废话不多说进入正文：
在企业快速发展的初期，通常以线下业务为核心战略目标。随着公司的快速发展，线上产品做的越来越深，导致权限管理的复杂性增加，特别是在大型组织中。管理大量用户的权限可能会变得混乱，难以维护。等到后期需求堆叠困难时候，才想到权限梳理的问题。所以在产品初期就应该有权限分配的意识。
一、传统权限
企业攻城拔寨的早期阶段，IT产品业务线较为单一，研发部小步快跑迎合业务往往最初的产品需求。而且公司高层变动较大，每当新来一个leader都临时赋予给他最高或部分权限。所以传统权限分配或都是直接授予用户，而不涉及角色的概念。在这种模型下，每个用户被赋予特定的权限，而不考虑用户是否属于某个角色或组。
这里拿西游记举个例子，可以看出唐僧和孙悟空对应的“经文”是系统直接授予的。这时候，如果再来一个猪八戒那我们需要再次对“经文”勾选查看或者编辑权限。
但是当我们的取经队伍足够大的时候，再去一个个按照人名去勾选权限维护起来肯定是困难的，那我们该如何更有效的管理我们的取经队伍？这时引入RBAC模型，它可以更轻松地处理用户的权限。
二、RBAC模型是什么？
RBAC是指”基于角色的访问控制”（Role-Based Access Control）。它是一种访问控制的安全模型，通过将权限分配给角色，然后将角色分配给用户，来管理系统中的用户访问。RBAC的核心思想是将用户的权限与其角色关联，而不是直接将权限授予用户。
- 用户（User）：系统的最终使用者，可以被分配一个或多个角色。
- 角色（Role）：定义了一组相关权限的命名集合。用户可以被分配到一个或多个角色。
- 权限（Permission）：描述了可以执行的操作或访问的资源。权限与角色相关联，用户通过分配到角色而获得相应的权限。
- 访问控制矩阵（Access Control Matrix）：显示了用户、角色和权限之间的关系，以及谁可以执行什么操作的表格。
接着上面的案例，当我们的系统加入猪八戒和沙悟净这两个人物时，按照传统的权限分配模式，我们需要分别对每个人授予权限，那如果使用RBAC模型，我们将系统中加入角色。这时候只需要把“孙悟空”“猪八戒”“沙悟净”赋予徒弟这个角色后，后续修改徒弟的权限，即可修改给所有的徒弟。
相比之下，RBAC引入了角色的概念，将权限与角色相关联，然后将角色分配给用户。这种方式使得权限管理更为灵活和可维护，因为只需要管理角色的权限，而不是每个用户的权限。这对于大型组织或复杂系统来说是一种更有效的权限管理方法。
三、多角色权限
当一个人具有多个角色时，RBAC允许用户同时拥有多个角色。这样的设计使得系统更加灵活，能够更好地适应组织结构和复杂的访问需求。在RBAC中，用户和角色之间的关系可以是多对一或多对多，具体取决于系统的设计需求和安全策略。
- 多对一（Many-to-One）：多个用户映射到同一个角色。这表示多个用户共享相同的角色，但每个用户在系统中只属于一个角色。
- 多对多（Many-to-Many）：一个用户可以映射到多个角色，同时一个角色可以包含多个用户。这表示用户和角色之间存在更为灵活的关系，一个用户可以在系统中属于多个角色，而一个角色也可以包含多个用户。
四、多角色权限处理方式
在RBAC中，有两种常见的处理多角色的方式：
- 合并权限： 用户被赋予所有角色的权限。这意味着用户将拥有他所属的每个角色的权限。
- 最小化权限： 用户只被赋予他所属的所有角色共同的权限。这种方式确保用户只能执行他所有角色共同具有的权限，而不是所有角色的权限总和。
例如，如果“蜈蚣精”同时具有“飞天怪”和“潜水怪”两个角色，而这两个角色分别具有不同的权限。这时候若使用合并权限的逻辑，则“蜈蚣精”同时拥有“飞天”“地面”“潜水”三个技能，若使用最小化权限逻辑，则“蜈蚣精”只有“地面”技能。
因此如何选择合适的方法取决于系统的安全需求和设计目标。在某些情况下，可能需要灵活性更大，因此采用合并权限的方式。在其他情况下，为了确保最小的权限原则，可能会选择最小化权限的方式。
五、模型分类
读到现在你应该对RBAC已经有了初步的认识，甚至可以适配一些业务场景。但是在真实的工作中，往往业务比我们想象的要复杂，那么我们需要有更进阶的模型方式去处理我们的业务，首先RBAC一共有4种模型，分别是RBAC0（基础模型）、RBAC1（基础模型）、RBAC2（角色限制模型）、RBAC3（统一模型）。
1. RBAC0（基础模型）： 最基本的 RBAC 实现，包括角色、用户和权限的概念。在这个级别上，访问控制比较简单，可能不包括角色的层次结构或其他复杂的功能。就比如我们刚刚的举例：
角色：徒弟；权限：查看经文，编辑经文。
2. RBAC1（基础模型）：引入了高级用户的概念，如角色的层次结构、继承权限等。高级用户可能具有比普通用户更多的权限，例如删除其他用户的文章。同时，管理员仍然拥有更高级别的权限。
角色：师傅；权限：可以查看并编辑徒弟的经文，但是徒弟只能编辑和查看自己的。同时可以删除自己和徒弟的经文。
3. RBAC2（角色限制模型）： 他是RBAC 模型的演进，通过引入更多的约束和规则，以满足实际业务中对角色分配的特定需求。这里的约束关系主要包含静态分离和动态分析，静态分离是指互斥的角色不能同时赋予同一个用户；动态分离指用户不能同时操作两个互斥的角色进行登录。
动态分离
动态分离是指在用户操作阶段，确保用户不能同时操作两个互斥的角色，即用户不能同时登录并执行涉及到互斥角色的操作。
例：即使我现在又是师傅又是徒弟，但是我在系统操作的时候，我不能同时操作两个角色。比如我是师傅时候我就不能降妖除魔，防止潜在的业务冲突。
静态分离
静态分离是指在角色分配的静态配置阶段就确保某些角色是互斥的，不能同时赋予同一个用户。这样的限制可以通过在 RBAC 模型中定义互斥关系或者强制性的角色分离规则来实现。
例：在西游记中定义师傅和徒弟角色为互斥的，系统在进行角色分配时会检查这一规则，确保一个用户不能同时拥有师傅和徒弟角色。
动态分离和静态主要有三种约束形式：
a、互斥角色：互斥关系角色指的是在某些情况下，两个或多个角色是互斥的，即它们不能同时分配给同一个用户。这是一种静态的限制，通常在角色分配的静态配置阶段就确定。
b、基数约束：基数约束涉及到限制用户能够拥有的角色数量，或者某个角色在系统中的实例数。这种约束可以是静态的，也可以是动态的，取决于在哪个阶段进行约束的检查。
c、先决条件约束：先决条件角色是指在分配某个角色之前，用户必须先拥有另一个或一组先决条件角色。这种机制可以用于确保用户在获得某个高级别角色之前必须具备一定的背景或权限。
4. RBAC3（统一模型）：很多人说 RBAC3=RBAC1+RBAC2，虽然在某些方面有相似之处，但它们并不是简单的加法关系。RBAC3 通常被认为是对 RBAC 模型的更进一步的增强。RBAC1 引入了角色的层次结构和权限继承的概念，增加了灵活性和简化了权限管理。RBAC2 在 RBAC1 的基础上引入了动态任务权限的概念，使得权限的分配更加灵活和动态。RBAC3 进一步提高了安全性和灵活性，引入了更高级的审计功能、自定义安全策略、高级用户管理等。
例：
- 角色：徒弟（悟空）。权限： 查看经文，编辑经文。
- 角色：师傅（三藏）。权限： 除了查看经文，编辑经文。增加了删除经文。
- 角色：仙班（玉帝）。权限： 除了师傅的权限外，还能创建创建经文，评估徒弟表现。
- 角色：教主（如来）。权限： 除了仙班的权限外，还能调整创建经文平台的设置、审计平台活动。
- 特殊情况下的动态调整： 在某些特殊情况下，可以灵活地调整权限，例如允许一个关卡有两位首领。
- 角色分配先决条件：想成为如来，必须先是师傅。
六、用户组
现在我们已经了解了RBAC模型的概念，但是对于更复杂的企业来说维护起来的工作量还是及其庞大和繁琐的。针对这种情况，往往我们可以将相同权限的角色进行合并成用户组。这样可以简化权限管理。同时也可以让用户组织更为清晰。这时候我们再看第一个案例，那么孙悟空、猪八戒、沙悟净就是一个取经团队，也就是用户组。
