作者:橘子洲头
全文共 2210 字 5 图,阅读需要 6 分钟
———— / BEGIN / ————
在人人都是产品经理的网站上蛰居了4年,学习了四年,由于最近的工作方向偏向于后台,在设计后台时时常会查阅后台的相关资料,但是关于后台的文章等内容分享的太少了。
正好这一段时间在调整,想尝试撰写一系列的关于后台文章,希望跟大家一起来探讨、分享,希望对大家有所裨益。
由于不同的后台需求多样化,不能一一兼顾,只能蜻蜓点水,尽量深入浅出。
权限管理是一个几乎所有后台系统的都会涉及的一个重要组成部分,主要目的是对整个后台管理系统进行权限的控制,而针对的对象是员工,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,数据泄露等问题。
其实权限管理的设计并不难,就目前来说最广泛的是一个账号对应多个角色,每个角色对应相应的权限集(RBAC模型)这种模型基本可以应对所有的问题,且通过角色可以实现灵活且多样的的权限操作需求,我们梳理一下上面主要提到的几个名词:账号、角色、权限。
每个员工想要进入系统肯定都会有一个账号,而这个账号就是一把钥匙。
我们通过控制账号所具备的权限,进而控制这个员工的授权范围。
因此需要告诫员工,账号密码不能轻易提供他人,不然遇到的问题由自己承担。
角色管理是确定角色具备哪些权限的一个过程,他是一个集合的概念,是众多最小权限颗粒的组成。
我们通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。
引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。
角色的命名最好按照职位而定,例如市场部普通员工,市场部主管等。因为职位在任何企业都是存在的,且是有限的,并且容易理解,市场部文员那就是市场部文员角色,方便我们配置权限时的判断,避免配置错误。
权限可以分为三种:页面权限,操作权限,数据权限。
页面权限
控制你可以看到哪个页面,看不到哪个页面。
很多系统都只做到了控制页面这一层级,它实现起来比较简单,一些系统会这样设计,但是比较古板,控制的权限不精细,难以在页面上对权限进行更下一层级的划分。
操作权限
则控制你可以在页面上操作哪些按妞。
可能你在某个页面上,只能查询数据,而不能修改数据。
数据权限
数据权限则是控制你可以看到哪些数据,比如市场A部的人只能看到或者修改A部创建的数据,他看不到或者不能修改B部的数据。
哪个页面要放置哪些权限,完全根据业务需要配置,你只需要把控制权限的地方列出来交给开发就好。
删除角色,需要去判断是否有账号关联了此角色,如果有关联,则不允许删除。如果角色不想用或者取消了,你可以将角色设置为无效状态,账户获取角色时会首先判断角色是否有效。
从便捷性上可以提供一个功能批量给某角色添加账户,在新员工入职时特别是同一岗位的,设置的权限时效率会大大提升。
给角色配置权限
首先我们肯定有个账户列表,因为我们是给账户配置权限。里面可以查询到或者添加到所有的人(为什么说添加,因为很多大公司有很多的管理系统,而每一个管理系统只有一部分人用,所以不会把所有人都在账户列表显示出来,故用到了添加)。
这里需要注意的是账号的禁用,用于防止员工离职后的问题。可以跟人事系统打通,人事那边设置某员工离职后,所有系统账号自动设为禁用。
有很多系统,提供了给账号直接添加具体权限的功能而不是通过角色,如同下图,我是不提倡的,给某个员工增加某个特定权限时,虽然操作更加便捷了,但是缺少规范性,一个员工明明是只有市场部角色,居然有财务部的支付功能,这个在页面上是解释不通的,而且日积月累会导致人员权限混乱,这种需求完全可以通过可以新增一个角色去处理。
账户列表
给账户配置角色
这种方式也是不提倡的,这种形式如果上面所讲的,直接给账号添加具体的权限,虽然提升的操作的便捷性,但是影响了权限的规范性与可维护性,角色这一桥梁就会变成断桥,统一性就会破坏掉。
截取的部分原型的页面,页面有点粗陋,仅供参考。
权限的分配要合理,很多公司分配给部门权限的时候很随意,部门要什么权限就给什么权限,其实这是有隐患的。
我们更多需要更深入的考虑部门能有什么权限,而不是要什么权限,而这一块往往被忽略。
归根到底我想强调一件事情:权限的管理,如何从公司制度上重视?
即如何规范权限的分配,即那个部门哪个员工要哪个权限都需要进行审批或邮件知会后才能帮其配置,还有哪些数据要设置权限,哪些操作要设置权限,这些权限管理过程才是权限系统的核心,恰恰这些核心的东西在系统上是体现不出来的。
前期的不经意就会在后期会变成麻烦,不仅影响业务效率,更会导致风险危机。
权限管理最终是为了风控,如果权限的风控意识没做好,权限系统做的再好也是枉然。
———— / END / ————
本文由 @橘子洲头 原创发布于人人都是产品经理。未经许可,禁止转载
点击“阅读原文”下载APP