B端产品如何设计权限系统？4个要素，5个模型，2个行业案例

B端产品如何设计权限系统？4个要素，5个模型，2个行业案例

编辑导语：B端产品的权限管理是衡量产品商业模式以及用户价值高低的一杆标尺，那么我们该如何进行权限系统的设计呢？作者分享了一些自己的经验，我们一起来看看吧。

现代经济学理论认为，企业本质上是“一种资源配置的机制”，其能够实现整个社会经济资源的优化配置，降低整个社会的“交易成本”。

权限管理系统的本质是企业内部或企业之间的资源在B端产品上以特定机制配置的映射；所以权限管理系统的贴身情况也是衡量产品商业模式好坏、用户价值高低的一杆标尺。

权限管理系统的设计中常遇到的问题有：

• 配置不规范，系统基础不稳，拓展性差；
• 配置不灵活，用户需求难满足，体验差；
• 配置太灵活，逻辑会复杂，实施成本高；

那么，如何设计一款贴身并能随着产品一起生长的权限管理系统呢？

在古代，没有互联网、没有软件时，泱泱中华在中央集权的帝制制度、“君君臣臣、父父子子”的角色说明书等管理系统中正常运转。

皇帝把资源下发给特定的人、岗位角色、宦官集团等以促进农业生产、税收、户籍管理、治安维护等。

资源包括权力、办事流程等抽象资源，也包括钱财、粮食、盐、矿等实物资源，同时包括印章、信纸、官服、轿子、马等承载资源、象征权力、代表等级的工具。

而管理机制除了帝制和角色说明书，还有子承父业的继承机制、藩王行为规范、文官武官的互斥监督、官职逐级递升约束、虎符口令双向验证等等。

在盛世时期百姓人口增加、战争时期军队数量增加要在基础机制上做适应性的调整。

权限管理的本质也大致如此，管理的是主体对客体遵循特定机制做出的行为。

• 权限管理系统的组成要素有哪些？
• 常见的权限模型有哪些？
• Oracle和Salesforce的权限模型是啥样的？
• 实操案例中如何应用的？
• 有哪些经验及建议？

一、4个基本要素

权限是主体对客体遵循特定机制做出的行为。所以，权限的4个基本要素就是主体、客体、行为、机制。

指行为的行使者，是操作的发起者。主体的类型有很多种，常见的有：

• 用户及用户组。更准确地术语应是“系统使用者”，其与系统的账号体系相对应，一个用户对应一个唯一账号；多个用户组成一个用户组；
• 角色及角色组。角色是权限分配的单位与载体，通常与组织架构体系相对应。Oracle产品中分为工作角色、职责角色、数据角色和抽象角色四类，后面我们会说到；
• 用户标签及用户标签组；
• 设备及设备组。HarmonyOS系统首期给Mate40系列开放使用；
• IP地址。限制对IP地址的访问；
• 地理位置。如O2O生活平台在不同位置展示的店铺不同；
• 局域网。如公司电脑在内网和外网所访问的资源不同。

指行为的承受者，是操作所针对的对象。主要有三大类：

（1）资源

• 基本属性的数据
• 个别的列数据（俗称“某些字段”）

（2）资源的容器

• 目录或菜单

（3）操作资源所必须的条件

• 任务流，也称工作流。某一资源在任务流中的状态不同，不同状态的资源可以分配给不同角色操作；
• 所属权。所属权包括个人、个人及下属、部门、部门及下属、全部，通常与组织架构体系的组织范围相对应。

指主体对客体的活动，包括主体在产品中对客体的一些操作，而我们常说的“权限”一词则指代了这一操作，例如“查看朋友圈的权限”。常见的行为有：

• 登入、登出
• 改，包括读写
• 查，包括不可见、只读
• 上传、下载

系统机制包括对主体、客体和主客体关系的认证，对主体行为及行为运行方式的授权。常见的机制有：

• 继承。父级可以拥有子级的权限，依托于组织架构或角色层级结构；例如销售部门负责人有所有下属的权限；
• 互斥。是对主体之间责任的强制性规定，防止同一主体拥有足够权限进行欺骗行为，防止即当运动员又当裁判的行为。责任分离有静态和动态之分：
• 静态互斥。一个用户不能同时拥有两个互斥的角色。例如银行内部的贷款申请者和贷款审批者不能让同一个人承担；
• 动态互斥。一个用户可以拥有两个角色，但在运行时只能激活一个角色，也成为运行互斥机制。例如银行内部为了灵活放贷，职员张三可以同时有贷款申请者角色和贷款审批者角色，但对于同一笔贷款，不能即申请又审批。
• 先决条件。A想成为C，就必须先成为B，C只能从B中产生；
• 基数限制。是主体与主体、主体与客体、主体与行为间数量关系的限制。例如一个用户可拥有的角色数目受限；一个角色被分配的用户数量受限；一个角色的权限数目受限；
• 授予机制。是主体将自己的权限授予给其他主体的权限；
• 双向验证。系统即验证主体，也验证客体，双方都通过验证时才能允许主体对客体的行为；
• 共享机制。

访问范围限定机制。一般有三类依托：

• 角色层级结构
• 组织范围/抽象关系

环境限制。分为三类：

• 空间限制。例如针对地理位置、IP地址、局域网的限制；
• 时间限制。例如考试时间到了之后，操作权限有所限制；
• 频度限制。例如对输入密码的频率的限制；

二、5种常见的权限模型

2. ACL模型：访问控制列表

Access Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。

原理：每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。

例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

2. DAC模型：自主访问控制

Discretionary Access Control，DAC是ACL的一种拓展。

原理：在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。

例如：常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。

缺点：对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。

3. MAC模型：强制访问控制

Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。

原理：主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。

例如：将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

4. RBAC模型：基于角色的访问控制

(Role-Based Access Control)，RBAC模型在目前使用的最广泛、最普遍。

原理：在主体和权限之间引入了“角色（Role）”的概念，角色解耦了主体和权限之间的关系。，有四个不同的层次：

• RBAC0：基本模型，相当于ACL+角色。权限被赋予角色，而不是用户，当一个角色被制定给一个用户时，该用户就拥有了该角色所包含的权限。所有的角色都是平级的，没有制定角色层级关系；所有对象都没有附加约束，没有制定限制；
• RBAC1：角色分级模型，相当于RBAC0+继承机制；
• RBAC2：角色限制模型，相当于RBAC0+互斥机制+先决条件机制+基数限制机制；
• RBAC3：统一模型，相当于RBAC1+RBAC2。

缺点：需要将某个权限单独设置给用户时，如果用户已有的角色中不包含该权限，就需要重新设置角色的权限或者重新创建一个新的角色，在业务和需求变更时需要维护大量的角色。

5. ABAC模型：基于属性的访问控制

(Attribute-Based Access Control)，能很好地解决RBAC的缺点，在新增资源时容易维护。

原理：通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。

属性通常有四类：

• 一是主体属性，如用户年龄、性别等；
• 二是客体属性，如一篇文章等；
• 三是环境属性，即空间限制、时间限制、频度限制；
• 四是操作属性，即行为类型，如读写、只读等。

例如：早上9:00~11:00期间A、B两个部门一起以考生的身份考试，下午14:00~17:00期间A、B两个部门相互阅卷。

缺点：规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。

三、Oracle和Salesforce的权限模型是啥样的？

1. Oracle

其权限管理系统基于RBAC模型的基础发展，角色分为四类：

• 工作角色：反映了工作头衔并描述了责任职位。例如采购员；
• 抽象角色：代表个人与企业或组织的一般关联，与该人的工作（职位）无关。例如临时工、员工、直属经理等；
• 职责角色：将必须在抽象角色或工作角色中执行的任务分组，代表一项工作职责的一组功能和数据权限。例如文章的审核职责；
• 数据角色：是访问特定数据的权利。例如HR中的薪资管理员可以看员工薪资，其他HR不能看。

这四种角色之间有什么样的联系呢？

抽象角色和工作角色必须继承职责角色。工作角色可以继承抽象角色和其他工作角色。数据角色可以继承抽象、作业和其他数据角色。职责角色可以继承其他职责角色。该图显示了角色类型之间的这些继承关系。

不同角色之间如何访问功能和数据呢？

这四类角色是如何配置在一个账号上的呢？

注意的是数据角色、数据权限一般直接配置在用户身上。

2. Salesforce

是通用型CRM系统中权限管理灵活配置的先进案例。使用简档、权限集、权限集组，控制用户可以访问的对象和字段。使用组织范围的共享设置、用户角色和共享规则，以指定用户可以查看并编辑的单个记录。

简档定义了用户访问对象和数据的方式，以及在应用程序内部执行的操作。简档是每个用户指定的标准配置文件，在创建用户时指定。一个用户只能有一个简档，同一个简档可以配置给多个用户。例如某公司的销售人员的简档是一样的。

权限集是授予用户对各种工具和功能的访问权限的设置和权限集合。无需更改用户简档，权限集即可扩展用户的功能访问权限。多个权限集可以构成一个权限集组。一个用户可以有多个权限集及多个权限集组，同一个权限集或权限集组可以配置给多个用户。

角色旨在提高数据可见性，控制着用户可以看到的内容。角色并非对每个用户都是强制性的。角色/角色层次结构的主要功能是允许层次结构中的较高级别的用户访问层次结构中较低级别的用户拥有的记录。例如：上级见下级，平级之间不可见。

角色层级衍生于组织架构，定义了角色之间的层级结构，例如销售副总裁在角色层次结构中，分管不同地区的销售经理。

而组织范围定义了数据的读写等操作所属范围，例如阅读范围有全部数据、本部全部数据、本部及子部全部数据、本人全部数据、本人及下属全部数据等，操作范围有个人操作、公共操作。

简档和角色之间的区别与联系是什么？

简档和权限集之间的区别与联系是什么？一般使用简档分配给用户最低的权限集合，然后使用权限集补充配置的其他权限。

两个联合使用，提供了访问的灵活性。两者对权限点的控制范围与设置方式是相同的，包括：

• 用户可以看到哪些对象；
• 用户可以看到哪些对象的哪些字段；
• 用户可以对哪些对象有什么行为；
• 用户可以看到哪些应用；
• 用户可以看到对象在不同的应用中的形态。

简档、权限集是如何配置在一个账号上的呢？

对字段权限的设置如下：

数据共享规则的设置如下：

四、实操案例中如何应用的？

将上文已讲的所有机制及权限对应的场景放入一个公司的管理系统中如下展示：

除此之外，也可以有一个账号对应多个企业角色，但在使用时需要选择其中一个企业角色使用；例如我是浙江省销售经理，同时兼任门店一的店长，一般来说销售经理只需要查看三个门店的数据即可，而店长要管理门店的所有操作及数据输入。

那么为了减少工作混乱及权限的耦合程度，可以给我配置两个企业角色，一个浙江省销售经理，一个门店一的店长，登录后必须选择一个企业角色再进入相应产品界面，两个企业角色可以随时切换。

五、经验及建议

1. 从产品开发商to企业客户，再从企业客户to 使用者的角度来看

一般产品开发商要根据客户画像、业务模式和行业标准将权限划分，求同存异，相同部分默认配置，不同部分根据业务粒度抽象为可配置项。

而企业内部给使用者配置是也需要根据用户习惯及标准化的操作进行求同存异，因为线下的灵活性难以把控，所以尽可能将能在线上化的部分标准化，但保证使用者只能用到自己需要的功能和数据。

抽象程度越高，配置项越少，开发成本和实施成本越低，用户体验越好，使用起来越贴身。否则随着产品的生长会衍生出更多权限点、更多角色，维护性变差，也极易出错，这也是笔者所亲身经历的教训。

2. 从常说的功能权限、数据权限的角度来看

常说的功能权限也就是资源的容器（即页面、目录或菜单、Tab、按钮）与行为（增删改查等）的权限之和；数据权限及资源本身、行数据或个别列数据（字段）。

从各种权限模型及Oracle和Salesforce的经验来看，更多情况下，功能权限配置在角色上，数据配置在用户上。

在Oracle中有专门的数据角色，但数据角色是直接配置给用户的。在Salesforce的简档将一个用户更基础的对象及数据权限预先设置给用户。

功能权限和数据权限一般设置尽量不要太细，能到菜单权限就不到页面权限，能到页面权限就不到按钮权限；能到行数据权限就不到列数据权限；尽量避免不同用户对相同字段有不同计算规则的情况。

本文由 @七牛 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议