后台经验分享:如何做权限管理系统设计

39 评论 148534 浏览 510 收藏 10 分钟

作者分享了关于后台设计中权限管理的相关知识,希望能够给你的产品工作带来一些帮助。

在人人都是产品经理的网站上蛰居了4年,学习了四年,由于最近的工作方向偏向于后台,在设计后台时时常会查阅后台的相关资料,但是关于后台的文章等内容分享的太少了,正好这一段时间在调整,想尝试撰写一系列的关于后台文章,希望跟大家一起来探讨、分享,希望对大家有所裨益,由于不同的后台需求多样化,不能一一兼顾,只能蜻蜓点水,尽量深入浅出。

权限管理系统定义

权限管理是一个几乎所有后台系统的都会涉及的一个重要组成部分,主要目的是对整个后台管理系统进行权限的控制,而针对的对象是员工,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,数据泄露等问题。其实权限管理的设计并不难,就目前来说最广泛的是一个账号对应多个角色,每个角色对应相应的权限集(RBAC模型)这种模型基本可以应对所有的问题,且通过角色可以实现灵活且多样的的权限操作需求,我们梳理一下上面主要提到的几个名词:账号、角色、权限。

账号的定义

每个员工想要进入系统肯定都会有一个账号,而这个账号就是一把钥匙。我们通过控制账号所具备的权限,进而控制这个员工的授权范围。因此需要告诫员工,账号密码不能轻易提供他人,不然遇到的问题由自己承担。

角色的定义

角色管理是确定角色具备哪些权限的一个过程,他是一个集合的概念,是众多最小权限颗粒的组成。我们通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。

角色的命名最好按照职位而定,例如市场部普通员工,市场部主管等。因为职位在任何企业都是存在的,且是有限的,并且容易理解,市场部文员那就是市场部文员角色,方便我们配置权限时的判断,避免配置错误。

权限的定义

权限可以分为三种:页面权限,操作权限,数据权限。

页面权限控制你可以看到哪个页面,看不到哪个页面,很多系统都只做到了控制页面这一层级,它实现起来比较简单,一些系统会这样设计,但是比较古板,控制的权限不精细,难以在页面上对权限进行更下一层级的划分。

操作权限则控制你可以在页面上操作哪些按妞。(延伸:当我们进入一个页面,我们的目的无非是在这个页面上进行增删改查,那在页面上对应的操作可能是:查询,删除,编辑,新增四个按钮)可能你在某个页面上,只能查询数据,而不能修改数据。

数据权限则是控制你可以看到哪些数据,比如市场A部的人只能看到或者修改A部创建的数据,他看不到或者不能修改B部的数据(延伸:数据的控制我们一般通过部门去实现,每条记录都有一个创建人,而每一个创建人都属于某个部门,因此部门分的越细,数据的控制层级也就越精细,这里是否有其他好的方式除了部门这个维度还有其他什么方式可以控制数据权限,大家可以提出来探讨一下)。

哪个页面要放置哪些权限,完全根据业务需要配置,你只需要把控制权限的地方列出来交给开发就好。

权限管理系统基本的页面设计

角色列表页

  1. 删除角色,需要去判断是否有账号关联了此角色,如果有关联,则不允许删除。如果角色不想用或者取消了,你可以将角色设置为无效状态,账户获取角色时会首先判断角色是否有效。
  2. 从便捷性上可以提供一个功能批量给某角色添加账户,在新员工入职时特别是同一岗位的,设置的权限时效率会大大提升。

给角色配置权限

账户列表页

  1. 首先我们肯定有个账户列表,因为我们是给账户配置权限。里面可以查询到或者添加到所有的人(为什么说添加,因为很多大公司有很多的管理系统,而每一个管理系统只有一部分人用,所以不会把所有人都在账户列表显示出来,故用到了添加)。
  2. 这里需要注意的是账号的禁用,用于防止员工离职后的问题。可以跟人事系统打通,人事那边设置某员工离职后,所有系统账号自动设为禁用。
  3. 有很多系统,提供了给账号直接添加具体权限的功能而不是通过角色,如同下图,我是不提倡的,给某个员工增加某个特定权限时,虽然操作更加便捷了,但是缺少规范性,一个员工明明是只有市场部角色,居然有财务部的支付功能,这个在页面上是解释不通的,而且日积月累会导致人员权限混乱,这种需求完全可以通过可以新增一个角色去处理。

账户列表

给账户配置角色

从权限添加账户

这种方式也是不提倡的,这种形式如果上面所讲的,直接给账号添加具体的权限,虽然提升的操作的便捷性,但是影响了权限的规范性与可维护性,角色这一桥梁就会变成断桥,统一性就会破坏掉。

截取的部分原型的页面,页面有点粗陋,仅供参考。

权限的分配

权限的分配要合理,很多公司分配给部门权限的时候很随意,部门要什么权限就给什么权限,其实这是有隐患的,我们更多需要更深入的考虑部门能有什么权限,而不是要什么权限,而这一块往往被忽略。

总结

归根到底我想强调一件事情,权限的管理,如何从公司制度上重视,即如何规范权限的分配,即那个部门哪个员工要哪个权限都需要进行审批或邮件知会后才能帮其配置,还有哪些数据要设置权限,哪些操作要设置权限,这些权限管理过程才是权限系统的核心,恰恰这些核心的东西在系统上是体现不出来的。前期的不经意就会在后期会变成麻烦,不仅影响业务效率,更会导致风险危机。权限管理最终是为了风控,如果权限的风控意识没做好,权限系统做的再好也是枉然。

 

本文由 @橘子洲头 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自PEXELS,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感觉文字描述和原型图的意思不一致。

    来自贵州 回复
  2. 2333

    来自上海 回复
  3. 数据权限分配原型应该怎么做比较好?

    来自福建 回复
  4. 我是做客服的后台系统,请问由于权限被禁用导致相关角色无法查看历史记录,这种问题怎么解决呢?

    来自广东 回复
    1. 能否查看历史记录本身推是一个权限,可设置是否开放该权限,或者设置权限开放时段

      回复
  5. 请问作者能留个微信么?

    来自宁夏 回复
  6. 多年产品经验告诉我,严谨的权限需求是个伪需求。
    真实的需求是,能随时随地审核权限,出事能找替罪羊。现在看来,腾讯文档,协作文档这种交互最实用。。

    来自四川 回复
  7. 请问 数据权限如何设计的呢

    来自北京 回复
    1. 同问

      来自广东 回复
    2. 先区分数据类型,每种数据进行任务溯源,根据溯源关系判断是否需要针对角色开放权限

      回复
  8. 权限给角色、角色给用户 这样用户就有对应的权限了 是这样吗?

    来自广东 回复
    1. 其实觉得角色分等级应该也是可以的

      来自陕西 回复
    2. 151651

      来自四川 回复
    3. 151

      来自四川 回复
  9. 纠正一下,是RBAC模型

    来自北京 回复
    1. 谢谢指出,打错了

      回复
    2. 🤝

      来自北京 回复
  10. 还不错

    回复
  11. 🙂

    来自广东 回复
  12. 权限配置,是典型的后端产品经理干的,这么多年经验下来,建议后端产品经理还是不要只关注原型、界面,后端的结构才是相对重要的。
    了解权限的注册,生成,怎么通过权限组,角色,节点,账号,甚至部门,职位,这些是怎么把Actor和auth连接起来的,他们的实体关系,权限类的设计、实例化,只有亲自设计这些,你才能真正的将做一套适合现行需求的权限后台。
    另外,采用角色还是节点,怎么实现你的需求才是合适的,横纵向扩展性,这些都远比几个界面来的实际和重要。

    来自广东 回复
    1. 默默点赞,谁做谁知道 🙄

      来自北京 回复
    2. 说的很有道理,往下深钻还要很多要点

      回复
    3. 大神 希望加个微信扣扣啥的 需要指点

      回复
    4. 唉,当年小白时,没接触过,后来总算弄明白了。其实很简单,就是没人带。这也是中国互联网发展的毛病,没有系统的教学。

      来自四川 回复
    5. 是的 不过有本书可以推荐你 大象

      来自广东 回复
    6. 你好,请问书名就叫《大象》吗?

      回复
    7. 大佬,你知道是哪本书了吗?我去搜大象,没有找到相关的

      来自广东 回复
    8. 求指教

      来自北京 回复
    9. 这块资料很多 权限最多用的模型就是RBAC和Auth 或者自己做 我们之前自己做了一套 采用ping的方式限制, RBAC有很多变种,站在产品角度,连接下实体构成,实现模型就好,可以自己根据需求去做一些定制,例如我上面说的 加入部门、职位 来替代角色

      来自广东 回复
    10. 谢谢,您说的很有帮助,这块还不是一下就能吃透的,还是我需要时间来打磨,慢慢理解您说的话,非常感谢

      来自北京 回复
    11. ~~~恩恩 多交流呀~~

      来自广东 回复
    12. 大神 方便加个联系方式么,我是一个刚踏入JAVA的菜鸟,特别需要一个指路人

      回复
    13. 大佬,我有个私活,后台系统设计,能谈一下嘛?

      来自日本 回复
    14. 能推荐这方面的书吗,或者资料

      来自江苏 回复
  13. 期待后续的文章

    来自广东 回复
  14. 给出了错误示例,最好再来个正确示范咯

    来自广东 回复
    1. 哪里错了?

      来自北京 回复
  15. 来自广东 回复
  16. 😉

    来自北京 回复