谈一谈B端产品的权限设计(上)

B端产品经理不可避免会遇到权限设计的相关问题,“权限管理”是B端产品的基础功能,行业里已经很成熟,虽然它不是核心业务功能,但却牵一发而动全身,需要产品经理根据具体业务使用场景来设计。

我们所说的“权限”,包括“功能权限”和“数据权限”,“功能权限”指用户登录系统后能看到哪些模块,操作哪些按钮,

比如常见的CRM系统,销售人员和财务人员由于处理的业务不同,登录系统后,看到的功能模块也不尽相同;同样都是财务人员,职位大小不同,拥有的操作功能也可能不同。

比如“删除”的操作,不会随意提供给一个普通员工。而数据权限指的是用户在某个模块里能看到哪些范围的数据,比如华南的销售总监可以看到华南地区的销售数据,而华北的销售总监只能看到华北地区的销售数据。              

本篇我们主要谈一下功能权限设计方面的问题,关于数据权限,我们下一篇再见啦。

功能权限主要有以下3种设计方式

1. 自主访问控制

(DAC:Discretionary Access Control)

自主访问控制是由《可信计算机系统评估准则》所定义的访问控制中的一种类型。

被操作对象,根据访问控制规则,来判断操作主体可对操作对象做哪些操作,比如只读或者是可写的权限。

Windows中的系统权限设计是典型的DAC应用,拥有访问权限的用户,可以直接将访问权限赋予其他成员,比如管理员有计算机的完全访问权,标准用户可以使用系统内的大多数软件。

在windows系统中,通过高级用户账户设置,赋予成员不同的系统操作权限,从而达到控制成员操作权限的目的。

2. 强制访问控制

(MAC:Mandatory Access Control)

被操作对象及用户两方均有各自的权限标识,用户能否对对象进行操作,取决于权限标识的对照关系。

MAC一般会给用户和资源分级。

比如,用户级别分为:初级 、高级;文件级别分为:公开、绝密,系统管理员会制定访问策略,如初级用户仅可以访问公开文件,高级用户可以访问全部文件。

从而达到不同标识的用户,访问不同标识的操作对象。

3. 基于角色的访问控制

(RBAC:Role-Based Access Control)

其基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。

一旦用户被分配了适当的角色后,该用户就拥有此角色的所有操作权限。

这样做的好处是,不必在每次创建用户时都进行分配权限的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多,这样将简化用户的权限管理,减少系统的开销。

RBAC0,基础模型:用户与角色是多对多的关系。一个用户可以拥有若干角色,一个角色也可以赋予若干用户。

企业的后台管理系统,通常包含多种管理模块,有面向供应商的管理,面向财务的管理,面向日常运营的管理,为了避免内部信息的交叉传播,以及操作人员可能存在的误操作行为,我们就可以通过RBAC0模型,为后台的操作者设置多种角色,并为每个角色赋予不同的业务权限。

这样就可以让销售同事只能查阅和修改供应商管理模块,无法查阅公司的财务信息,而财务同事也只能查阅和修改财务报表相关的管理模块,无法干预公司的日常运营,运营同事则只被授予面向产品的运营管理能力,不同岗位各司其职,互不干扰。

当一个人既负责销售部,又负责运营部时,就可以为其赋予销售人员、运营人员两个角色,这样他就拥有这两个角色的所有权限。

RBAC1,用户分级模型:相比RBAC0,需要设计角色间层级关系和角色间继承关系。

公司规模越大,对每个岗位的权责要求也更为细致。我们可以通过RBAC1模型,为用户提供角色间的继承关系。

如销售角色,可以分为销售主管和普通销售2个级别,普通销售默认继承销售主管的权限,并支持在销售主管级别的基础上,删减普通销售的权限。

这样,通过角色分级,可以控制不同级别权责的差异化,避免出现下级比上级权限大的情况。

RBAC2,角色限制模型:用户和角色为多对多的关系,如果采用责任分离模型,则需要定义角色和角色间的互斥关系,也就是约束规则。

有些公司对于“责任分离”比较重视,如合同的录入与审核不能为同一个人,销售人员来做合同录入,财务人员来做合同审核,那么一个合同管理模块,如何做到责任分离呢?RBAC2模型,通过角色互斥可以实现。

给一个员工分配了销售人员角色时,就不能再分配财务人员的角色,保证一个员工不会既有销售人员,又有财务人员的角色,约束工作职责。

RBAC3,统一模型:包括了继承和分离两种情况的更为复杂的模型,即既要定义角色间的继承关系,也要维护好角色间的责任分离关系。 

RBAC3=RBAC1+RBAC2,可以解决上述3个问题,既能实现角色的分级与继承关系,避免出现下级比上级权限大的情况,又可以定义角色间的互斥关系,保证一个员工不会同时操作互斥的功能。

关于功能权限设计的几点Tips

如果项目初期不需要权限管理,一定记得提醒开发同学,预留相关接口。

功能权限设计,也包括页面权限和接口权限,这一点没有经验的产品同学可能注意不到,需要保证没有该模块功能权限的用户直接输入页面地址或调用接口时,也无法访问。

一个页面完成一件事,避免页面交互方式太复杂,无法划分功能权限。

未完 · 待续

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念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

推荐阅读更多精彩内容