设计实例:如何以“用户”为单位的进行权限设计(一)

19 评论 35509 浏览 142 收藏 10 分钟

权限设计可以很好地对保证公司信息系统的安全。权限设计的方式主要有:以“用户”为单位、以“权限”为单位和以“用户”与“权限”结合的权限设计方式。这篇文章针对以“用户”为单位的权限设计方式进行展开解读。

最近公司发生一件大事:公司一员工,窃取网站后台管理功能资源以及网站销售额等数据,事后发现是敌对公司派人有意所为。电视剧场景在现实重演,有些吃惊,为防止此类事情再次发生,临危受命,针对权限管理进行重构。

为何有权限设计的需求

禁止非法用户盗取资源

访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,每一台计算机具备浏览器,如果不建立一个完整的权限检测,那么一个非法用户可以轻而易举通过浏览器访问Web应用项目中的所有功能资源。

保证数据的保密性

公司内部员工的角色不同,自然对于系统使用功能的权限不一样,关于机密数据的列表菜单是不能允许让所有人进行访问的。

比如:一个电商网站的销售额等报表数据,是不允许公司内所有员工都进行查阅的,有针对地进行管理。

权限设计的方式有哪些?

  • 以“用户”为单位的权限设计
  • 以“权限”为单位的权限设计
  • 以“用户”与“权限”结合的权限设计

针对以上三种类型,结合业务场景以及具体设计方式,详细进行讲解。

以“用户”为单位的权限设计

适用的业务场景

当使用该系统的人之中,存在很多拥有同一类权限的人,将拥有同一类权限的人定义为“角色”或者“部门”等其他称号,而这个集合的称号就是定义权限的集合体。

举例:在公司内部,运营部人员拥有查询报表的权限,客服部人员拥有审核商品评论的权限,而运营部人员和客服部人员人数众多,且权限一致,那么以“用户”为单位的权限设计更符合业务需求。

如何进行设计?

1、信息架构图

用户:添加用户过程中,分配至某一个部门,该部门拥有的权限就是该用户的权限

部门:添加部门时,除填写部门基本资料外,对该部门定义具体权限

2、业务流程图

具体流程:添加部门,给部门设置权限,添加用户时,设置所属部门,部门的权限即是该用户的权限。

3、具体原型图设计

添加部门:

添加用户:

由于公司内部资料的保密性,我纯手打两分钟,撸了个最简单的示意图进行参照,其设计方式相信一看即懂。

关于此方法的权限设计疑问

1.权限的类型有哪些?

权限分为菜单功能和特殊项区分权限。

菜单功能权限:为一个用户设置权限,该用户所属部门为运营部,运营部的权限设置中,勾选报表管理,但是未勾选导出报表。

那么该用户进入该系统,能看到菜单页,但是无法看到导出报表的按钮,因为没有改权限。

特殊项区分权限:有这样一个业务场景,该后台系统管理几个电商网站,我不希望A网站的运营人员看到B网站的销售额数据,同理,B网站的运营人员看不到A网站的销售额数据,似乎菜单功能权限不能为我们解决此问题。

那么,我们分两步走:

1、在给部门设置权限的页面,加上特殊项区分权限。

2、找出与此特殊项区分权限所有相关的页面,进行展示并进行标记。

以上为报表详情页,如果该用户所在部门的权限中,勾选了A站、B站以及C站的权限,那么在报表详情页中的搜索选项,出现的站点为权限勾选的网站,如果未勾选任何网站,那么相应地,报表详情页中查看不到任何网站的数据。

需要记住一点的是,涉及到特殊项区分权限的页面很多,产品经理需要全部找出,并进行合理的设计展示,完善方案后给到开发,进行代码的实现。

3.当遇到一个部门内部,必须针对不同的人设置不一样的权限,如何处理?

业务场景:一个后台管理系统管理众多电商网站的评论,客服部人员内部进行分工,1号客服负责A网站的评论审核,2号客服负责B网站的评论审核,3号客服负责C网站的评论审核,那么问题来了。

1号、2号、3号客服同属于一个部门,他们所拥有的权限不一样,你如何进行处理?

大部分人会想到一个解决方案:那就帮2号、3号客服再次新建一个部门,一个部门一个权限可以解决。

但是,这是有弊端的:

  • 试想这种业务场景足够多的话,那么会造成的结果是:你的部门列表会有一堆重复的部门,部门之间也无法进行区分,显得页面非常乱。
  • 有些重复的部门下只有一两个人,非常不利于进行管理

此路不通,怎么解决?

方法是制造一个二级部门的概念,部门太大需要在小组内再区分,就增加三级部门的概念。

三级部门属于二级部门,二级部门属于一级部门,针对现实的状况进行区分。

在添加部门时,选择一级部门时,如图所示:

选择二级部门时,如果所示:

选择不一样的部门类型,进行添加,针对部门进行权限设置,也更方便解决会有重复部门以及页面会很乱的情况。

一个部门内部,必须针对不同的人设置不一样的权限,此类场景根据频次进行处理,有以下类型:

  • 此类场景频次极少,直接添加新部门,设置权限
  • 此类场景频次较多,增加二级部门或三级部门的方式,设置权限
  • 此类场景频次特别多,走个极端,一个团队一个人拥有一种权限,怎么办???

第三种业务场景中在现实中是大量存在的,特别是国家机关的工作系统,保密性是非常有必要的,如果我们使用以“用户”为单位的权限设计,其中涉及的部门根本毫无作用,一个人一个部门,这是非常可笑的,那么我们应该如何进行处理此种情况?

在下一篇文章中,将详细介绍以“权限”为单位的权限设计,欢迎阅读~

#专栏作家#

不羁,微信号:hujianfeng1234,人人都是产品经理专栏作家,对于电商以及社交领域产品有深入了解,重业务逻辑,喜深入思考,欢迎交流~

本文原创发布于人人都是产品经理,未经许可,不得转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 作者只是分享了一下基础的权限设置,不知道为什么会有这么多喷子,在更早的时候没有RBAC模型的时候,用的的确是这个模型,只是现在权限设置更偏业务了,所以这个慢慢变得不再适用。

    来自浙江 回复
  2. 兄弟,你这篇文章把我看糊涂了,按照你的观点:是在部门上授权,归属于这个部门下的所有用户都具有这个权限,如果同一个部门下的用户有不同的权限,那就再建下级部门,给下级部门授权。
    【首先】我要对看这篇文章的朋友们说一声:这种权限设计可能对这个公司的用户适用,在借鉴的时候,切莫拿来主义。
    【其次】我要对作者说:一个企业的行政组织(包含部门)都是固定的,这属于企业HR管理的一部分,不会因为你权限的设置而变更,部门不会随便增加改变的,其次,组织是和业务有很大关系的,不仅仅只是关联权限,你这种设计并没考虑过企业内部审批、业务汇报关系、人员考勤等和业务相关事情,组织一旦有变动就会产生很大的影响。
    【建议】如果没有非常成熟的权限模型,建议使用RBAC或在RBAC基础上改良优化,建立更严格的权限体系,不要紧紧地将权限绑定在组织上。

    来自北京 回复
  3. 难道RBAC权限模型不能解决你的问题吗?

    来自广东 回复
    1. RBAC模型很不错,我会深入再研究一下,感谢你的建议~

      来自广东 回复
  4. 这小伙,有点误人子弟。。。

    来自北京 回复
    1. 赞同

      来自上海 回复
    2. 不要就知道喷人,写篇文章来教育我,真的求求你了~

      来自广东 回复
    3. 分享东西,注定是要有人喷的,但是这套逻辑是解决了我公司遇到的问题,你们看了,认为与你们公司遇到的问题不适用,也是正常,你生搬硬套,就说我误人子弟,有本事写篇牛逼文章出来教育我啊,不行就别喷人,好好说话,真TMD受不了这种氛围。

      来自广东 回复
    4. 哪里都有喷子,千万别因为他们而影响你的分享热情。就像你做的那样,适当的回击再加上无视,就足够了。每个浏览者的浏览目的、需求阶段都不一样,有不一样的看法也是正常。你的文章对现阶段的我就挺有帮助的,谢谢你。

      来自上海 回复
  5. 1、权限和部门没有关系吧,一个部门不同的人有不同权限,或多项权限叠加情况,一个人一般属于一个部门或交叉虚拟组。
    2、一般设置角色+个人权限组合,角色自可以定义设置很多种,并赋予对应权限,人员权限分级(比如最大权限主管,系统主管,具有全产品使用权限,一般人员权限。被授予的权限:可以细化到每个模块,单据,功能,菜单,字段,敏感数据上,所以权限维度和组合,架构要考虑清楚)

    来自四川 回复
  6. 对于部门下每个人都拥有不通权限的问题是否可以通过将部门权限维护的权限赋予部门领导这个角色来解决呢?

    来自四川 回复
  7. 我们的系统一般而言部门的存在只是为了方便管理众多的用户,真正的权限是放在角色上的。角色是用户的属性,去分配不同的功能权限。

    来自陕西 回复
    1. 最简单的是部门和用户在一起,直接分配权限比较方便,当然,你要通过角色设置权限,部门管理人员,这都是可行的~

      来自广东 回复
    2. 部门一般是用来区分数据权限居多吧

      来自上海 回复
  8. 最简单的权限接解决方案:
    1.一个创建系统用户,创建时将用户与业务人员关联
    2.一个创建业务人员与对应的权限

    :mrgreen: 😉

    来自广东 回复
  9. 权限建立的基础,是划分并梳理好“业务从属”和“任务权限”;这两块不涉及到用户画像和需求调研,相对比较明确,所以还好…
    但是更为复杂的,是在权限分配中,加入绩效考核与评定,这个也是必须的步骤,因为权责分明,也就是为了绩效权衡。且行且努力吧… 😉

    来自广东 回复
  10. 干货,学习了。

    来自四川 回复
  11. 说的太好了

    来自四川 回复
    1. 谢谢,欢迎交流~

      来自广东 回复