权限设计指南
2022-09-22 22:27:58 0 举报AI智能生成
登录查看完整内容
权限设计指南
作者其他创作
大纲/内容
“权限设计”是中后台的底层设计，用于明确操作人员可在平台内能做什么；即什么样的人，可以做什么样的事。
让使用者在有效的限制范围内访问被授权的资源。
让管理者基于系统的安全规则与策略，控制不同用户合理访问对应资源。
1.1.权限的意义
角色权限管理：角色权限管理顾名思义是根据用户角色类型进行权限分配；一个角色对应一组权限组，一个用户可能有多个角色。适用于中后台逻辑复杂功能模块繁多，需要对系统按权限进行切割的应用场景。
版本管理：部分中后台存在商业化诉求，基于前者的角色权限分配（也有可能不存在角色区分），再将完整的系统进行功能切割，将整个系统按功能切割为普通版、进阶版，甚至更多版本；这些版本功能范围基本处于一个包含关系。
权限设计的应用主要有两种场景，分别是版本切割、角色权限管理：
1.2.权限的应用
系统安全：基于系统的安全规则和策略进行设计，同时需要降低用户操作错误导致的风险概率。
关系明确：需要界定权限的边界与关系，遵循一定的规则与用户进行关联。
拓展性高：需要确保权限管理的拓展性，系统的能力建设是持续的，用户也是不断流动的；保持高拓展性以此降低变更对安全性、稳定性的影响。
好的权限设计，需要达到以下三方面要求：
1.3.权限设计要求
界面设计：权限查询、管理与授权等一系列页面设计。
业务梳理：权限构成、赋予以及行使的逻辑、元素的梳理。
数据验证&管理：数据管理层面，最终目标是可被表达成一个运算则式，体验方案的合理性与拓展性，验证设计的有效性。
底层架构开发：偏向于开发层面的系统底层架构设计与研发。
1.4.权限设计的工作范畴
1.什么是「权限设计」
在业界有很多关于权限系统的技术模型，常见的有ACL、ABAC、DAC、RBAC等等，不同体量的权限系统，我们可以参考不同的权限模型进行梳理和设计。
RBAC0的基础理念是将“角色”这个概念赋予用户，在用户与权限之间通过角色进行关联，实现灵活配置。
用户：是发起操作的主体，例如：后台管理系统的用户、OA系统的内部员工、面向C端的用户。
角色：用于连接了用户和权限的桥梁，每个角色可以关联多个权限，同时一个用户也可以关联多个角色，那么这个用户就有了多个角色的多个权限。
权限：用户可以访问的资源，包括：页面权限、操作权限、数据权限。
RBAC模型的三要素为：用户、角色、权限。
2.1.1.RBAC0模型
ACL为查询操作对象的权限控制列表。当权限系统体量小，用户直接对应具体功能点即可满足系统诉求时，可以考虑使用ACL模型作为参考。
ACL权限中，只有用户、权限这两个要素：
2.1.2.ACL模型
RBAC1模型是在RBAC0模型基础上，引入了角色继承的概念，即角色具有上下级的关系，每个等级权限不同，从而实现更细粒度的权限管理。
2.1.3.RBAC1模型：基于 RBAC0 加入角色继承
RBAC2模型是在RBAC0模型基础上，对角色进行约束控制。RBAC2模型中添加了责任分离关系，规定了权限被赋予角色时或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。主要包括以下约束:
互斥关系角色: 同一用户只能分配到一组互斥角色集合中至多一个角色，互斥角色是指各自权限互相制约的两个角色。例如：设计部有交互设计师和视觉设计师两个角色，他们如果在系统中为互斥角色，那么用户不能同时拥有这两个角色，体现了职责分离原则。
基数约束: a.一个角色被分配的用户数量受限；b.一个用户可拥有的角色数目受限；c.同一个角色对应的访问权限数目受限；以此控制高级权限在系统中的分配。
先决条件角色: 简单理解即如果某用户想获得上级角色，必须得先获得其下一级的角色，以此为一个先决条件。
2.1.4.RBAC2 模型：基于 RBAC0 引入角色约束控制
2.1.准备工作：权限模型的了解与选择
角色是连接用户和权限的桥梁，在这一步对参与系统的角色进行穷举，需要保证系统的运作能否绝对闭环，所以明确系统中的角色至关重要。
参考组织本身的岗位划分：绝大多数情况下，系统中的工作职责与实际工作岗位有较为紧密的相关性，我们可以参考已有的岗位来盘点系统中的角色。
根据任务流盘点：根据系统任务流对角色进行穷举，即盘点需要创建哪些角色进行任务闭关。
如何进行角色盘点，主要有以下两种方式：
2.2.1.第一步：盘点角色
权限是用户能够访问的资源，本步骤需要将系统中所有权限点按照类型进行整理归类，最终成表。权限点主要有以下几种类型需要盘点：
通俗讲即用户在系统内可见的页面，由导航/菜单来控制，包括一级导航/菜单、二级导航/菜单，甚至三级导航/菜单；只要用户有对应导航/菜单的权限即可访问页面。
页面权限
通俗讲即页面的功能按钮，包括查看、新增、修改、删除、审核等等。
操作权限
数据权限就是用户在同一页面看到的数据是不同的，比如：A部门只能看到其部门下的数据，B部门只看B部门的数据。数据权限分割的解决方案为：创建用户组——将相同属性或相同数据范围诉求的用户进行编组，不同的用户组则享有不同的数据权限。
根据用户组是否有上下级的关系，可将用户组分为：具上下级关系用户组、普通用户组。
具上下级关系用户组:最典型的例子就是部门组织。
普通用户组: 没有上下级关系的用户分组。在日常系统最常见的普通用户组为“项目组”，按项目组来划分用户的数据权限。
数据权限
2.2.2.第二步：盘点权限
本步骤主要工作在于连接权限点与角色的关系，最终整理出一张完整的角色权限表。在梳理角色和权限的关系时，可以借助设计分析方法“角色任务行为穷举”来进行权限点转化和连接。
2.2.3.第三步：连接角色权限
在建立了角色与权限的关系后，需要去明确用户授权/导入的方式，并给导入的用户赋予角色权限。
有部分公司域下的中后台，用户已有有统一的验证方式，例如：腾讯OA身份验证；也有部分中后台需要用户创建独立的ID账号密码作为身份验证。我们首先需要去明确我们设计的中后台是以上哪种方式作为身份验证，这将影响用户导入流程的设计。
明确账号体系
已有账号：如为公司域下中后台的用户导入，用户账号为现成的我们不需要考虑用户的账号。可直接为用户赋予权限，授权分为两种方式：为用户选择角色、为角色添加用户。
无账号：如需要用户创建ID的用户导入，则适用
初始用户授权流程
在实际工作中，用户为完成某项任务却无权限时，需要为用户提供清晰的申请流程。申请权限有两种场景。
场景一：权限存在岗位身份之分，身份与某组权限进行绑定，用户主动申请岗位身份并获得审批通过后，即可获得该组权限，流程参考下图：
场景二：用户在访问系统时，系统页面提示用户无访问/操作权限，用户针对该页面/操作进行权限申请，通过后即可获得该页面/操作权限，流程参考下图：
授权申请流程
2.2.4.第四步：设计用户导入与授权流程
2.2.开始梳理：基于RBAC模型盘点要素
2.怎么做「权限设计」—业务梳理
线上申请：用户通过触发申请按钮，发起申请，并在线上填写表单完成申请。在此场景下，除了申请按钮，我们需要也很明确的告知用户当前为无权限的状态，甚至将原因也给予简单说明；同时建议告知用户申请的审批人是谁，需要审批多久。
线下申请：页面仅告诉用户申请方式，一般为授权人的联系方式。
无权限页面申请指引设计
3.1.页面权限设计点
由于数据权限的展示和切换控制着用户对于整个系统的数据范围，故需要存在于系统架构的第一层级，一般可独立放置于一级菜单之上。
数据权限范围的展示与切换
3.2.数据权限设计点
对于开放申请的操作权限的展示，可将操作权限点置灰，表示用户当前不可操作；在用户hover置灰权限点时，提供气泡提示置灰原因为无操作权限并提供申请权限入口。
可申请
有些系统要求用户可见操作全貌，即所有操作无论是否有权限都为可见的；若无权限则且不可申请，则直接置灰操作
有些系统要求\"可见即可操作\"，即为有权限的操作则显示，无权限的操作则隐藏，这里就需要前端来配合，前端开发把用户的权限信息缓存，在页面判断用户是否包含此权限。
不可申请
无权限操作展示设计
3.3.操作权限设计点
3.怎么做「权限设计」—界面设计
权限设计指南
0 条评论
回复 删除
下一页
