产品经理必懂的B端产品的权限设计逻辑

一、B端后台权限的必要性和重要性。

权限控制是管理后台的重要功能,可以有效的提高系统的安全性,减少误操作、数据泄漏等风险的发生。

由于太过基础,很多人对于权限设置的认识很多是浮于表面或直接拿来主义直接照搬。权限结构设置好坏,直接影响企业生产、经营的效率,可以说,权限的设置企业来说至关重要。


二、ACL(Access control list), 权限访问列表

ACL权限控制模式是一种通过账号直接控制权限的访问模式,这种模式可以抽象下图。

这种模式很好理解,新建用户时直接赋予用户相应的权限,。


优点:

这种模式的优点在于其设置的灵活性,可为不同的用户赋予不同的权限。

企业中不同的岗位有不同职责,每个岗位或职级的工作内容有所不同,对应到权限系统就是分别对应不同的功能权限与数据权限。

适合人数少且系统权限较少的企业,设置灵活且高效。


缺点:

这种模式的缺点显而易见,不太适用中大型企业,易用性和扩展性较差。

中大型企业中由于人数较多,职责划分较为明确:产品、研发、技术、销售、财务...等岗位,各岗位的职责相对明确,采用此种模式设置权限或当人员发生岗位或职级变动去编辑权限时,需要针对用户一个个去设置权限,效率极低且不具备扩展性。


三、RBAC(Role-Based Access Control),基于角色的访问控制

RBAC模式是现在企业中应用最为广泛的权限控制模式。


说RBAC模式前,先说几个非常重要的概念:

1、用户(账号);2、角色、3、岗位;4、职级。


1、用户:系统中的用户对应着企业中一个个真实的用户,每个用户可拥有1个或多个账号。


2、角色:提起角色的概念,一般人很容易与岗位进行关联,角色与岗位关联也是可以的,但是当企业中同一个岗位有不同的职级时,角色与岗位关联在控制权限中无法精准控制。

在企业中,对于「销售」这个岗位,可能会细分为:「销售专员」、「销售经理」等不同的职级,「销售专员」、「销售经理」在实际的工作中的权限会有不同,在角色中「销售专员」、「销售经理」也不能等同于一个角色。


所以说,角色具体与岗位关联还是与岗位中的具体职级关联,主要取决于现实企业中具体场景。


3、岗位与职级。同一个岗位可能有不同的职级或者职称。


常见的RBAC模式:

常见的RBAC模式是先创建一个「角色」,角色中会定义相应的权限,然后在新建「用户」,选择用户所属的权限。


RBAC模式的权限一般会有3种:

1、数据权限

数据权限主要跟组织架构相关。比如同是销售部门的员工小A和小B,小A只能看自己维护的客户信息和交易信息,小B只能看自己维护的客户信息和交易信息,数据互不关联;员工小A和小B的领导小C,可查看小A、小B和自己部门手下员工的全部客户信息和交易信息。


一般有2种方式解决数据权限问题:

(1)通过菜单权限去控制可查看数据范围。

这种很好理解,就是将特殊的数据入口做成功能,赋予用户相关的功能权限后才能才看数据。

(2)通过企业组织的层级关系去限制数据权限。

这是根据企业的组织架构,根据职员的职位高低来控制数据的访问权限。所以它通常的解决方案是和组织架构相关联的,具体逻辑如下:

(1)在给职员分配账号的时候,设置好对应的部门和职位

(2)当用户获取数据时,根据自己当前的部门和职位,获取到所有下属的职员信息

(3)将属于这些下属职员的所有客户信息显示出来,这个数据控制就完成了。


2、功能权限

功能权限主要是指不同的岗位工作职责不同,映射到系统中就是相关的功能权限不同。


3、特殊权限

在门店业务系统中,在收银时,针对同一个职级的不同员工,需要进行支付方式的限制。就需要在用户中进行特殊业务场景权限的设置。


优点

1、对比ACL模式,RBAC模式更贴合多数企业的适用场景。

2、具有很强的可扩展性。随着企业业务的发展,针对特殊的权限设置更具扩展性。

3、设置权限效率较高。当人员岗位或者职级调动后,直接修改该用户的角色即可。


在RBAC模式中,用户与角色的关系是多对多的关系。

实际企业内部关系中,一个用户可能会有多个角色。

比如:集团下属的上海销售负责人,可能负责江苏或者浙江的销售市场,设置权限时,单个用户赋予多个角色即可实现,这时候该用户所拥有的权限则是所有角色权限的并集。(针对用户赋予「针对业务的特殊权限」,也能达到针对一个用户赋予多个角色进行权限管理的目的,具体采用哪种方式,需要根据具体的业务进行衡量采用。)


此外,RBAC还有几个扩展模型:

第一种:在角色上加入了上下级关系,上级可以继承下级的权限。

这种在适合大多数企业的数据权限。上级默认可查看下级的数据权限。

第二种:在角色之间加入了多个约束关系,如角色互斥

针对一个用户赋予多个角色后,角色直接的只能可能是冲突的,尤其是有审核的场景。如:采购专员发起采购申请后,一般需要采购经理审核后进行采购。这时候如果将采购专员和采购经理角色赋予同一个用户,也就失去了审核的意义,这时候设置多个角色时需要进行必要的提示。

以上就是常见的权限设置及优缺点,RBAC模式在实际场景中因为极具扩展性、设置高效应用广泛,RBAC模式在设置权限中,有很多种通用的方法需要结合企业组织架构和实际业务场景灵活采用。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,802评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,109评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,683评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,458评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,452评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,505评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,901评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,550评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,763评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,556评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,629评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,330评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,898评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,897评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,140评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,807评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,339评论 2 342

推荐阅读更多精彩内容