系统解读:权限设计指南
共 5291字,需浏览 11分钟
·
2021-12-13 01:40
1.什么是「权限设计」
1.1.权限的意义
让使用者在有效的限制范围内访问被授权的资源。
让管理者基于系统的安全规则与策略,控制不同用户合理访问对应资源。
1.2.权限的应用
角色权限管理:角色权限管理顾名思义是根据用户角色类型进行权限分配;一个角色对应一组权限组,一个用户可能有多个角色。适用于中后台逻辑复杂功能模块繁多,需要对系统按权限进行切割的应用场景。
版本管理:部分中后台存在商业化诉求,基于前者的角色权限分配(也有可能不存在角色区分),再将完整的系统进行功能切割,将整个系统按功能切割为普通版、进阶版,甚至更多版本;这些版本功能范围基本处于一个包含关系。
1.3.权限设计要求
系统安全:基于系统的安全规则和策略进行设计,同时需要降低用户操作错误导致的风险概率。
关系明确:需要界定权限的边界与关系,遵循一定的规则与用户进行关联。
拓展性高:需要确保权限管理的拓展性,系统的能力建设是持续的,用户也是不断流动的;保持高拓展性以此降低变更对安全性、稳定性的影响。
1.4.权限设计的工作范畴
界面设计:权限查询、管理与授权等一系列页面设计。
业务梳理:权限构成、赋予以及行使的逻辑、元素的梳理。
数据验证&管理:数据管理层面,最终目标是可被表达成一个运算则式,体验方案的合理性与拓展性,验证设计的有效性。
底层架构开发:偏向于开发层面的系统底层架构设计与研发。
2.怎么做「权限设计」—业务梳理
2.1.准备工作:权限模型的了解与选择
2.1.1.RBAC0模型
RBAC模型的三要素为:用户、角色、权限。
用户:是发起操作的主体,例如:后台管理系统的用户、OA系统的内部员工、面向C端的用户。
角色:用于连接了用户和权限的桥梁,每个角色可以关联多个权限,同时一个用户也可以关联多个角色,那么这个用户就有了多个角色的多个权限。
权限:用户可以访问的资源,包括:页面权限、操作权限、数据权限。
* 2.1.2.ACL模型
* 2.1.3.RBAC1模型:基于 RBAC0 加入角色继承
* 2.1.4.RBAC2 模型:基于 RBAC0 引入角色约束控制
RBAC2模型是在RBAC0模型基础上,对角色进行约束控制。RBAC2模型中添加了责任分离关系,规定了权限被赋予角色时或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。主要包括以下约束:
互斥关系角色: 同一用户只能分配到一组互斥角色集合中至多一个角色,互斥角色是指各自权限互相制约的两个角色。例如:设计部有交互设计师和视觉设计师两个角色,他们如果在系统中为互斥角色,那么用户不能同时拥有这两个角色,体现了职责分离原则。
基数约束: a.一个角色被分配的用户数量受限;b.一个用户可拥有的角色数目受限;c.同一个角色对应的访问权限数目受限;以此控制高级权限在系统中的分配。
先决条件角色: 简单理解即如果某用户想获得上级角色,必须得先获得其下一级的角色,以此为一个先决条件。
2.2.开始梳理:基于RBAC模型盘点要素
2.2.1.第一步:盘点角色
如何进行角色盘点,主要有以下两种方式:
参考组织本身的岗位划分:绝大多数情况下,系统中的工作职责与实际工作岗位有较为紧密的相关性,我们可以参考已有的岗位来盘点系统中的角色。
🌰举例,研发运维工具中的角色定义,不同的岗位对应不同的角色拥有不同工具的使用权。
根据任务流盘点:根据系统任务流对角色进行穷举,即盘点需要创建哪些角色进行任务闭关。
🌰举例,支撑A平台的智能客服知识库,角色是我们在产品规划过程中为其定义产生的。
2.2.2.第二步:盘点权限
页面权限
🌰举例,智能客服知识库系统的页面权限:
操作权限
数据权限
具上下级关系用户组:最典型的例子就是部门组织。
🌰举例:
普通用户组: 没有上下级关系的用户分组。在日常系统最常见的普通用户组为“项目组”,按项目组来划分用户的数据权限。
🌰举例,以应用项目的纬度控制用户可访问的数据范围。
2.2.3.第三步:连接角色权限
🌰举例:
2.2.4.第四步:设计用户导入与授权流程
已有账号:如为公司域下中后台的用户导入,用户账号为现成的我们不需要考虑用户的账号。可直接为用户赋予权限,授权分为两种方式:为用户选择角色、为角色添加用户。
无账号:如需要用户创建ID的用户导入,则适用于以下流程:
场景一:权限存在岗位身份之分,身份与某组权限进行绑定,用户主动申请岗位身份并获得审批通过后,即可获得该组权限,流程参考下图:
场景二:用户在访问系统时,系统页面提示用户无访问/操作权限,用户针对该页面/操作进行权限申请,通过后即可获得该页面/操作权限,流程参考下图:
3.怎么做「权限设计」—界面设计
3.1.页面权限设计点
无权限页面申请指引设计
在2.2.4章节中,我们提到用户在实际工作中为完成某项任务,对无权限页面/操作会存在申请的场景诉求,我们除了要为用户提供清晰的申请流程,也需要有清晰的指引,实际上也是针对空状态的设计。
线上申请:用户通过触发申请按钮,发起申请,并在线上填写表单完成申请。在此场景下,除了申请按钮,我们需要也很明确的告知用户当前为无权限的状态,甚至将原因也给予简单说明;同时建议告知用户申请的审批人是谁,需要审批多久。
🌰举例:无权限页面
线下申请:页面仅告诉用户申请方式,一般为授权人的联系方式。
🌰举例:无权限页面
3.2.数据权限设计点
数据权限范围的展示与切换
3.3.操作权限设计点
无权限操作展示设计
可申请
对于开放申请的操作权限的展示,可将操作权限点置灰,表示用户当前不可操作;在用户hover置灰权限点时,提供气泡提示置灰原因为无操作权限并提供申请权限入口。
不可申请
总结
干货 | 产品经理要了解的技术类知识
复盘 | 产品经理晋级连胜的诀窍
如何正确解码用户的“玄学需求”?
👇欢迎关注: