【产品设计】对权限系统的思考

【产品设计】对权限系统的思考

编辑导语：几乎所有的管理后台都会涉及到权限的设计，权限控制是管理后台的重要功能，可以有效的提高系统的安全性，减少误 *** 作、数据泄漏等风险的发生；本文作者对权限系统进行了思考，我们一起来看一下。

最近入职了新公司，在申请后台权限时，发现后台没做权限系统，开通账号、分配权限必须要找运维；领导跟运维同事确定好要开通的权限，半小时之后，运维才完成账号添加和权限分配。

没有权限系统，给权限的分配和管理带来了困难；回想过去从0到1搭建权限系统，和对权限系统进行了改造升级的经历，我对权限系统有了更多的思考。

一、为什么要做权限控制？

每个企业都有自己的分工协作体系；不同岗位的员工，负责不同的工作内容；不属于岗位职责范围内的事情，员工通常不具有参与权和知情权。

垂直电商企业，运营人员的负责维护商品信息、策划和执行运营活动；客服人员负责处理客户投诉、售后问题；财务人员负责处理收支款项、查看财务数据。

运营人员不需要处理客户投诉，也不需要给客户打款，更不应该查看企业的月度财务报表。

如果每个岗位地员工都可以参与所有的工作、看到所有的信息，就会给企业的分工协作体系造成巨大冲击，导致内部管理混乱。

如果每一个员工都可以修改商品信息，商品价格可能随意变化，导致大量的订单纠纷和订单流失。

如果每一个员工都可以处理客户投诉，就会因为与客户沟通的语气不好或方法不当，导致客户产生更大的怨气。

如果每一个员工，都可以给客户打款，企业对外打款就会失控，出现严重的资金管理问题。

更极端的情况是，员工利用自己“无限制的参与权和知情权”，进行违法的牟利活动，给企业带来致命的损害。

如员工删除数据，以掩盖工作失误，导致系统瘫痪；员工导出企业重要客户资料，高价卖给竞争对手；员工向竞争对手泄漏企业关键业务数据。

企业通过对员工在系统中拥有的权限进行控制，让不同岗位、层级的员工，只能使用和看到其职权范围内的功能和信息，以确保分工协作体系能顺畅运作，同时维护企业信息安全。

二、权限系统的适用场景

权限系统，是指对用户在系统中可 *** 作的功能、可查看数据范围进行控制的功能模块。

通俗的解释是：权限系统通过设定不同的用户角色，再将权限分配给各个角色，控制不同的用户，能在系统中使用什么功能、查看什么信息，是企业对员工进行权限控制的工具。

设定运营人员为“电商运营”角色，并分配商品管理、订单管理、活动管理权限。权限系统允许了运营人员查看和编辑商品信息、订单信息、活动信息，禁止了他们对财务等非岗位职责范围内的功能 *** 作和信息查看。

并非所有的系统都需要做权限控制——只有当系统功能足够多、使用角色多样时，才有对用户进行权限控制的必要。

当更多岗位的工作内容被纳入系统时，系统使用的角色也会从单个变成多个；为了避免员工的权限不受限带来的信息安全问题，就需要分岗位进行权限控制；如上文提到的随意修改数据、泄漏重要信息等。

而当系统功能单一、或使用角色单一时，意味着系统的用户必须拥有该功能的权限，或他们的工作职责也相同，需要使用的功能也相同；此时，对用户权限进行控制没有太大意义。

三、功能权限

1. 功能权限的定义
根据员工的岗位职责，控制在系统中能使用的功能，是最常见的情况，也是权限控制最基础、最主要的部分——限制用户能使用的功能，称之为功能权限控制。

功能权限取决于用户在实际工作中，要负责的工作内容。而工作内容取决于用户所在岗位的岗位职责；因此，功能权限取决于用户的岗位职责，用户有什么岗位职责，在系统上就应该对应拥有什么功能权限。

张三、李四是一家垂直电商公司的运营专员：张三负责维护商品信息，李四负责订单跟进、活动策划。

张三只拥有商品管理的功能权限，可以添加、修改商品信息；李四则拥有订单管理、运营活动管理的功能权限，可以查看跟进订单、配置运营活动。

2. 功能权限设计注意点
1）找出需要做特定权限控制的功能点每个模块都是由很多个功能点构成的，但并非每一个功能点都需要对用户做特定的权限控制。

那些依附于主功能，且即使不做控制，也不会带来风险的基础功能点，完全就可以使用默认授权，开放给所有用户使用。

一个列表页面，通常由数据查询、数据列表、添加数据、删除数据、分页等功能点构成；其中，数据查询、分页功能，依附于数据列表。

若用户拥有数据列表的权限，那么理应也拥有这2个功能的权限；反过来，如果用户没有数据列表的权限，即便用户有这2个功能，也完全不会有任何风险。

我们要遵循“有独立负责的岗位”和“ *** 作时存在风险隐患”两个标准，从大量的功能点中，找出少量但必需要做权限控制的功能点。

优惠券通常由运营人员管理；在优惠券列表中，添加优惠券功能，通常由运营岗位的员工来 *** 作；添加优惠券时，一旦配置错误，可能会给公司带来较大损失；优惠券列表中的添加优惠券功能，应该要做特定的权限控制，而不是默认授权给所有用户。

而查看优惠券列表，没有特定负责的岗位，也不存在风险隐患；因此，查看优惠券列表功能，可以默认授权给全部用户，不需要做特定权限控制。

2）给权限准确命名在给用户授权时，我们需要通过权限名称理解该权限控制的内容；给权限命名的准确度，直接影响后期给用户授权的效率；命名准确，能避免不必要的错误授权。

“分配权限”的权限，可能会授权给部门领导，他们不一定理解专业词汇；可以很轻松地理解“添加优惠券”权限的含义，但无法理解什么是“获取缓存”，即便知道“缓存”的含义，也无法确定是什么功能的缓存。

在给权限命名时，要注意以下3点：

避免研发视角的专用词汇。如：缓存、队列等；使用动宾结构，描述完整。活动的详细信息，应该命名为“查看活动详情”，而不是简写为“查看”或“活动详情”；同一个功能模块或页面中的权限，不要重名；如推文列表中，查看推文在前端的展示效果和查看推文内容，不要都可以命名为“查看推文”。

3）对权限进行分组管理在对用户进行功能权限分配时，需要从权限清单中找出需要授权的权限；若对权限进行合理的分组管理，就能使权限清单的管理和权限分配变得非常方便。

功能点归属于各个模块、页面，而功能权限是对功能点进行权限控制；与此同时，在给用户授权时，我们很清楚地知道，这个功能点属于某个模块、某个页面；因此，按其所属模块和页面对其进行分组，是最自然的分组方式。

将“添加优惠券”权限，分组到“会员营销-优惠券列表”中；在给运营人员分配“添加优惠券”权限时，可以直接通过该功能的路径，在权限清单中快速找出，完成授权。

如果没有分组，就只能从无数个功能权限中搜寻，效率极其低下。

四、数据权限

多个不同或相同岗位的员工都拥有同一个功能的权限，但该功能产生的数据，每个员工并不需要看到所有数据，而只能看到一部分。

限制用户在查看某类数据时，能查看到的数据范围，称之为数据权限控制。

1. 为什么要做数据权限？
员工拥有数据查看权限的同时，也有对该数据保密的义务。如果数据不做数权限控制，会导致对应业务的核心数据，被有该功能权限的所有员工查看到。

1）同级别的普通员工互相看到对方的数据，引发员工之间的恶意竞争，增加内耗。

市场专员A搜集的潜在客户信息，被B看到，并被B抢先开发为真实客户，原本属于A的收入，被计入了B的业绩。

这严重打击了A的工作积极性，还诱发了内部的恶意竞争。

2）下级员工越过自己的可见范围，看到上级领导权限范围内的数据，带来不稳定因素。

下级员工看到了部门同事被审批通过的调薪申请，可能就会因此而心里不平衡，进而要求同等额度的调薪。

看到其他同事的绩效评分，可能就会产生不公平感，进而导致对领导的不满。

3）员工看到高管才有权限的关键数据，并泄露给外部。

普通员工看到企业各个收入源的具体营收数据，可能就会泄露到外部，给公司带来不必要的损失。

数据权限控制，最重要的就是确保数据的私密性，避免因员工的数据权限超出权限范围，给企业带来不稳定因素和损失。

2. 根据岗位级别进行数据权限控制
数据权限主要取决于用户的岗位级别。岗位级别越高，数据权限越大。

一般可以分为以下3种：

仅自己的数据：基层员工通常只能看到自己产生、或与自己相关的数据；

所在部门的数据：部门管理者可以看到本部门所有人的数据。根据组织架构的层级，还可以分为所在一级部门的数据、所在二级部门的数据等；

所有数据：更高级别的领导，能看到更大范围的数据。

当月用户一共下了1000个订单，分属于不同业务部门的员工。

运营专员李四只能看到属于自己的100个订单，李四的直属领导能看到属于本部门的600个订单，公司领导能看到全部的1000个订单。

五、总结

后台系统的权限系统已经有成熟的解决方案，我们在参考成熟解决方案的同时，一定要先想清楚为什么要这么设计，做到知其然且知其所以然，才能设计出更好的产品方案。