SaaS 权限体系设计，做一个总结与优化改善笔记。以下文章内容面向政府工业中大型企业。
权限控制主要做什么
权限控制在B端的后台属于基础能力，主要管理人员在平台内可以做什么事情，看到什么数据。
权限价值体现在什么地方
权限控制的价值在于提高系统的安全性、稳定性和灵活性，同时确保企业内部的信息安全和分工协作体系的有效运作
常见的B端权限场景问题总结
1、在 SaaS 中，可以分配账号权限给代理，代理具有创建租户/项目的能力，同时具备管理租户内的所有权限
2、在租户中可以独立分配权限
3、各个部门有其自己的管理员，并给其部门员工分配权限，即实现多级管理员层层分配。
4、用户希望整个部门的人员都有设备管理、巡检管理、养护管理、维修管理、采集管理的权限时，可以以部门为权限载体，为其分配权限。
5、除超级管理员之外，需要其他副管理员进行协助管理系统，可以分配多个，同时也满足分配给代理或其他角色。
6、权限配置完后，不知道用户最终权限是什么，具体是否有分配到
7、用户在权限管理中会遇到下面情况
多个角色的权限类似，仅有小部分不同，希望可以批量为多个角色设置权限，不需要单独为每个角色配置一遍。
新增加的角色，希望可以直接复用已有角色的权限，然后在此基础上微调，避免重新配置，降低工作量。
8、当用户面临以下场景时分配权限不方便
部分用户临时需要查看某张模板。
领导身兼多职，领导有权限查看某些模板但领导所在部门和角色没有权限。
有时候需要针对特定的个人分配报表权限，就必须先专门建一个新角色
9、子部门数据可根据条件查看置顶数据权限
10、某资源需要开发给所有互联网用户下载
11、集团内企业A数据共享给企业B
12、用户可以分享某个页面到公网、或可以配置密码
怎么选择权限控制方案
权限控制方案取决于公司产品战略以及市场战略方面。
在产品战略部署上，明确产品的发展蓝图，需要做什么样的规划，怎么符合市场需求；在18年时从 0-1 设计 SaaS 化工五位一体物联网整体产品架构上，从市场侧有几个明确设计方向：
1、以版本为售卖形式之一，区分个人版、企业版、企业专业版、数据分析专业版；
2、按照接入点位阶梯收费，5000个点、1w个点、1.5w个点、3w个点；
3、在产品内部应用管理架构上，按照最小应用为单位管理方式，采用应用分发机制。
4、需要满足集团式权限管理，自上而下管理，如钱江水务集团，需满足集团权限以及各子公司。
后续在设计综合能源运维管理平台权限体系改造
从客户侧，需满足集团式管理，同时需支持接入外部项目管理，在集团内部需能够控制PC客户端、小程序端、移动客户端功能权限控制、数据权限控制；
从公司内部侧，需满足所有公司第三方代理账号管理，第三方账号可建立不同的项目；同时需满足按照行业不同场景要求，建立权限体系；在SaaS 平台中，可管理多个第三方代理，第三方代理可在自己的账号体系下建立自己的不同项目，不同的第三方代理需要的行业场景不一致；代理管理的项目之间数据权限控制。
权限模型总结对比
| 对比 | RBAC | ABAC | ACL | MAC |
| 解释 | RBAC通常用于配置哪些角色拥有哪些权限，而哪些用户可以拥有这些角色。 实现原理：把用户按角色进行归类，通过用户的角色来确定用户能否针对某项资源进行某项操作。 RBAC模型的三要素为：用户、角色、权限。 | ABAC通常用于配置哪些属性的用户在哪些属性的环境下可以对哪些属性的资源进行哪些操作。 实现原理：通过各种属性条件来动态判断一个操作是否可以被允许，也可以理解为“配置规则”。 我们在配置规则时需要定义属性条件和资源的关系。其中属性条件又分成以下3类： 用户属性：如年龄、部门、职位、性别等； | ACL访问控制通常用于配置哪些用户可以访问操作哪些资源。 实现原理：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源操作。 | MAC在ACL基础上，增加了双重验证的限制，要求用户和要访问的资源必须具备相应的安全等级关系才可获取权限 |
| 灵活度 | 静态授权 | 动态授权 | 静态授权 | 静态授权 |
| 控制粒度 | 相对较粗，只能做到控制到功能上，很难把控制粒度放到具体实体上。比如doc访问如果控制到部门、组等，需要抽象出很多角色。 | 可以非常细致，可以具体到指定用户、指定实体、并且满足具体的条件约束 | 因只有主体与资源，粒度比较细 | 层级明确，颗粒度细 |
| 管理与复杂成都 | 简单，在管理上会遇到多个角色，因为在多种场景下需要建立不同的角色，在角色的维护上会比较麻烦，特别是在saas层级或者在项目层级，每建立一个项目都需要建立相应的角色，会导致角色爆炸。 | 复杂，基于属性控制数据权限，要求配置人员必须在非常了解系统的情况下才可很好的使用。同时在管理上也是比较困扰的一个难题；和 RBAC 一致，少的情况下🆗，但是多的情况下，梳理排查起来就更困难了，也会导致规则爆炸。 | 简单，非常明确，排查起来也非常简单 | 简单，非常明确，排查起来也非常简单 |
| 使用场景 | 基本上都适用，管理企业数据以及系统功能场景，只需要分配角色就可以了 | 适用于复杂策略定制的场景。 | 适用于职能部门隔离场景。不同部门固定就可以查看的数据以及功能 | 适用于保密场景，比如资源与数据保密。 |
解决的问题
1、按照自上而下原则，可解决平台层用户、代理层用户、集团层用户、子公司层用户权限分配。
2、在角色管理上，尽可能在平台层面建立通用角色，可解决一部分角色爆炸问题。
3、解决了不同人可以查看不同的数据，可设置自己部门的数据，可设置查看制定部门指定时间范围内的数据。
4、解决代理账号问题
5、解决应用权限复杂问题
6、解决权限审计问题
设计原则：自上而下原则
权限控制构成
功能权限与数据权限
功能权限：用户可以看到哪些菜单，可以做什么操作，比如可以看巡检任务菜单、可以做巡检任务的开始操作等等。
数据权限：用户可以看模块里面的哪些数据，比如：巡检任务只需要看到自己的任务数据即可。
角色维度上的考量
在工业场景下，角色类型是相通的，无论是化工企业、化工集团、污水厂、自来水厂、水务集团、工业生产车间等等，在应用设计之初就能够明确通用角色；通用角色应该就具备通用权限，不需要用户去进行配置，这里有几个痛点问题：
1、客户不了你平台系统的规则以及功能按钮权限，唯一能够理解的就是有一个角色他直接进行配置就可以了；
2、角色太多的情况下是不利于管理的，针对大型企业或者管理多个企业的情况下，角色管理是大的难题；
3、一般的B端政府、工厂、企业，如果是中小型企业，用户使用者对信息化是不够非常了解的，他更倾向于直接使用就可以。不需要管其他的。
常见的角色：巡检人员、部门副主管、部门主管、机修人员、维修人员、财务人员、经理等等，在平台设计之初应该就已经确定了权限，如果有不一致的也是用户企业管理上面的微调。
所以对于角色的设计应该考虑的问题：
1、在应用设计上，明确角色类型，有哪些角色可能会用到，在当前应用功能中，为了哪些角色进行的设计，这些角色对应了系统中哪些业务。
2、在权限上，哪些权限是连锁的，如巡检应用与巡检统计，巡检任务统计就必须拥有巡检应用才可进行统计，在设计之初就可以设定应用为前提条件，如果没有这个前提条件，就不需要进行显示。如在算法应用上，算法编辑、算法推理，AI报告的前提是有算法应用基础上，那么在这个里面就可以提前设定前提条件。
3、在应用中，有哪些通用变量，如：创建时间、当前用户、当前部门、当前角色、当前岗位；哪些是条件变量，如设备类型、金额、能源分类等等；
4、明确那些是资源，需要对资源进行控制，如设备分析报告、部门分析报告、节能分析报告，这些报告是否可查看与下载。有哪些人可以查看。
基于以上内容第一步明确角色类型大概的管理权限，第二步梳理权限，包含页面权限、操作权限、列权限、数据权限，第三步关联权限，梳理权限表，可以按照以下思路方法整理：
谁需要得到什么结果，需要在什么页面查看什么信息，需要进行哪些操作
| 谁（角色） | 需要的结果 | 需要在什么页面（页面权限） | 查看什么信息（数据权限） | 做什么操作（操作权限） |
| 巡检人员 | 查看自己的所有任务，可以对任务进行开始结束操作 | （PC）巡检任务，（移动端）巡检任务 | 查看自己的任务 | 任务开始、扫码、查询、完成任务、报修 |
| 机修人员/维修人员 | 可以操作自己的任务，对自己的任务进行闭环操作。 | （PC）养护工单，维修工单，库存台账；（移动端）养护工单、维修工单、领料、库存台账 | 查看自己的任务，查看可以领料的耗材 | 任务开始、暂停、启用、关闭、申请领料、申请延期、处理任务等等 |
| 运维主管 | 查看自己管辖部门的所有任务完成情况以及任务统计 | （PC）养护工单、维修工单、库存台账、养护计划、养护标准、养护统计、维修统计 | 查看管辖部门的任务以及统计；统计报告；设备运维报告 | 查看、导出、关闭、审核、等等 |
| …… | …… | …… | …… | …… |
权限体系设计方案
结合以上内容，给出我个人认为比较好的设计方案，此方案面向B端工厂、政府企业。
在 RBAC 的模型基础上，拓展 ABAC 设计思想，加入规则进行管理。
权限通过三个维度进行管理：角色维度、部门维度、用户维度；
这三个维度根据实际情况进行选择
场景1：如果对于中小企业，一人多岗，每个人实际上只关注自己做的事情，在平台管理员的角度来思考就是怎么少一点工作量。这种场景里面实际需要使用角色管理就可以解决，但是不是有这个角色管理功能就完事了，而是说根据功能业务的设计系统默认好响应的角色，需要自己进行选择就可以。
使用到的功能就是：RGBA 角色的增删改查，用户的最终权限预览；在数据权限中就根据角色走，配置不同的权限层级，如果遇到重复的数据权限的时候取最大即可。平台有默认的角色，用户只管使用就行，这样的设计下这类企业一定很喜欢。
其是根据中小企业来评定是有点问题的，而是应该评定会有多少人使用平台；场景1应该在0-50人，角色群体在5个以内，在工厂里面往往使用到的人群其实并不多，主要就是执行层，执行层只关心自己的事物；管理者关心结果，使用频率不高。
场景2：使用人群在 50-200 人，角色群体在 15 个左右，角色群体可能还到不了 15 个；这种情况最好能够新增部门管理维度，用户权限维度，部门维度可以配置模块菜单操作，按照部门权限进行配置；在用户上可以查看最终权限，并且可以进行权限微调。
场景3：使用人群在 200 人以上，角色群体在15个以上 ，在这个阶段，往往面临的是角色管理问题，因为角色会有很多，这种情况一定要有基础权限，基础权限根据平台设计业务明确，并进行权限分级，分级后在根据RGBA进行设计，同时满足角色维度、部门维度、用户自身权限维度，在权限分级上是明确的，在这个基础之上进行角色维度、部门维度、用户自身维度，并结合ABAC策略方式进行管理；在权限上一定是可以进行追溯，在查看用户的时候，可以看到用户的权限来源。
第三方参考
Guide to Attribute Based Access Control (ABAC) Definition and Considerations (nist.gov)
