产品复盘：后台系统权限管理设计
1. 背景介绍
2. 权限管理设计的阶段
3. 权限管理的主要组成部分
4. 用户组的引入
5. 结尾
1. 背景介绍
本文针对一个金融风控后台系统从0到1的权限管理进行简单复盘分析，其中包括反推的部分以及对后续优化方向的思考。由于权限是需要和系统具体业务紧密联系的，所以本文更注重于产品分析过程的思维方式，实际做法对于其它系统并没有普适性。
2. 权限管理设计的阶段
小钟是一家金融科技公司的产品经理，接到任务负责一个金融风控系统的优化迭代。该金融风控系统主要应用于银行，银行利用该系统对合作企业进行初步的风险评估。
小钟在leader的介绍下了解到，该系统基本的业务都已经可以跑通，但由于之前为了满足快速上线的需求，权限管理部分在开发前就进行了设计，现在发现跟不上业务需求，所以引发了很多问题。如果条件允许的话，权限管理的设计一定是在系统初步搭建完成之后开始做的。
3. 权限管理的主要组成
小钟经过短暂的体验后发现，目前系统的权限分为三级：超级管理员-管理员-用户，功能权限的配置细分到具体用户上，数据权限不同用户互相独立，向上继承，没有明确的可配置页面。
由于小钟之前并不熟悉权限的设计（其实小钟啥也不会），所以查阅了很多的资料。小钟发现，权限管理主要是分为功能权限和数据权限。
功能权限可以细分到页面权限和操作权限，页面权限是指菜单栏上的每一个tab页面，操作权限是指增删查改的动作权限。
数据权限可以细分到可见范围以及数据接口权限。可见范围即指用户可以看到的数据范围，数据接口权限指具体接入的数据，但本人认为该部分不属于应用系统的考虑范围，在本文里不做考虑。
小钟认为，该金融风控系统的操作相对简单，功能权限控制在页面级别即可，数据权限依然保持原来的向上继承方式，即超级管理员可以看到管理员进件的数据，管理员可以看到用户进件的数据。
4. 用户组的引入
由于之前的分析都是建立在系统层面的考虑，没有考虑到使用主体的情况（用户画像），所以接下来就是对银行进行分析。
小钟发现，银行存在简单的组织架构，如总行-分行：
每个分行之间的数据应该是相互独立的，那按照目前的权限设计肯定是做不了的。小钟经过一阵摸索后发现，可以通过引入用户组来控制这个数据权限。每个分行即为一个用户组，用户组和用户组之间的数据互相独立，不可见。
小钟突然有个疑问，那分行下面的部门是否需要数据独立呢？是不是需要将用户组也划分层级？经过调研后发现，该系统主要是由指定业务部门使用，并无多个部门共用，无需划分用户组层级。
5. 结尾
由于篇幅有限，所以难免讲得浅显，其实对于每个点还有很多需要去细究的点，在此就无法一一赘述。而且该文章主要是对自己工作的复盘，所以也难免无法对权限管理有大而全的概括。
