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


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

文章插图
一、B端后台权限的必要性和重要性 。权限控制是管理后台的重要功能,可以有效的提高系统的安全性,减少误操作、数据泄漏等风险的发生 。
由于太过基础,很多人对于权限设置的认识很多是浮于表面或直接拿来主义直接照搬 。权限结构设置好坏,直接影响企业生产、经营的效率,可以说,权限的设置企业来说至关重要 。
二、ACL(Access control list), 权限访问列表ACL权限控制模式是一种通过账号直接控制权限的访问模式,这种模式可以抽象下图 。
产品经理必懂的B端产品的权限设计逻辑

文章插图
这种模式很好理解,新建用户时直接赋予用户相应的权限,。
优点:
这种模式的优点在于其设置的灵活性,可为不同的用户赋予不同的权限 。
企业中不同的岗位有不同职责,每个岗位或职级的工作内容有所不同,对应到权限系统就是分别对应不同的功能权限与数据权限 。
适合人数少且系统权限较少的企业,设置灵活且高效 。
缺点:
这种模式的缺点显而易见,不太适用中大型企业,易用性和扩展性较差 。
中大型企业中由于人数较多,职责划分较为明确:产品、研发、技术、销售、财务…等岗位,各岗位的职责相对明确,采用此种模式设置权限或当人员发生岗位或职级变动去编辑权限时,需要针对用户一个个去设置权限,效率极低且不具备扩展性 。
三、RBAC(Role-Based Access Control),基于角色的访问控制RBAC模式是现在企业中应用最为广泛的权限控制模式 。
【产品经理必懂的B端产品的权限设计逻辑】说RBAC模式前,先说几个非常重要的概念:
1、用户(账号);2、角色、3、岗位;4、职级 。
1、用户:系统中的用户对应着企业中一个个真实的用户,每个用户可拥有1个或多个账号 。
2、角色:提起角色的概念,一般人很容易与岗位进行关联,角色与岗位关联也是可以的,但是当企业中同一个岗位有不同的职级时,角色与岗位关联在控制权限中无法精准控制 。
在企业中,对于「销售」这个岗位,可能会细分为:「销售专员」、「销售经理」等不同的职级,「销售专员」、「销售经理」在实际的工作中的权限会有不同,在角色中「销售专员」、「销售经理」也不能等同于一个角色 。
所以说,角色具体与岗位关联还是与岗位中的具体职级关联,主要取决于现实企业中具体场景 。
3、岗位与职级 。同一个岗位可能有不同的职级或者职称 。
常见的RBAC模式:
产品经理必懂的B端产品的权限设计逻辑

文章插图
常见的RBAC模式是先创建一个「角色」,角色中会定义相应的权限,然后在新建「用户」,选择用户所属的权限 。
RBAC模式的权限一般会有3种:
1、数据权限
数据权限主要跟组织架构相关 。比如同是销售部门的员工小A和小B,小A只能看自己维护的客户信息和交易信息,小B只能看自己维护的客户信息和交易信息,数据互不关联;员工小A和小B的领导小C,可查看小A、小B和自己部门手下员工的全部客户信息和交易信息 。
一般有2种方式解决数据权限问题:
(1)通过菜单权限去控制可查看数据范围 。
这种很好理解,就是将特殊的数据入口做成功能,赋予用户相关的功能权限后才能才看数据 。
(2)通过企业组织的层级关系去限制数据权限 。
产品经理必懂的B端产品的权限设计逻辑