大家好，我是讯享网，很高兴认识大家。



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

讯享网

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

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

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

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

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

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

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

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

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

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

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

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

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

  （1）资源  

  （2）资源的容器  

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

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

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

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

环境限制。分为三类：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

属性通常有四类：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对字段权限的设置如下：

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

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

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

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

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

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

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

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

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

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

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