数据库篇(数据库设计) ---权限系统设计

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/programlight/article/details/83186198

目录

概述

菜单功能权限控制

用户-权限

用户-角色-权限

 用户-用户组-角色-权限

数据权限控制


概述

    权限管理,一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源,不多不少。

    权限管理几乎出现在任何系统里面,只要有用户和密码的系统。 很多人常将“用户身份认证”、“密码加密”、“系统管理”等

    概念与权限管理概念混淆。一个(ERP)系统中没有权限进行管理,就像躯体没有了灵魂,没有任何控制,行尸走肉一

    般,无论功能设计的多么完美,白搭。

    依据我现有的浅薄认知,我认为权限从控制作用上来划分成两类:

  1. 菜单功能权限控制
  2. 数据权限控制

菜单功能权限控制

    声明一下:菜单功能权限控制不单单是对菜单的展示和控制,还包括菜单页面上的功能控制,细分到每一个按钮链接操作,

    有些人只有查看权限,有些人可以修改,具体不同的人员可以查看到不同的数据,就交由数据权限控制。

    说起菜单权限,RBAC是目前最-最-最为广泛接受的权限模型。我们从简单的开始说起。

用户-权限

    每个用户和每个权限进行多对多的关联

    数据库:人员表-人员权限关联表-权限表
    这种设计比较简单,一般不用。

用户-角色-权限

    当我们需要管理很多权限的时候,有些权限可以分成组以功能模块进行赋权限。这个时候角色就是一些权限的集合。

    比如机构管理的增删改可以放到一个角色中,只需要将改角色和某个人关联就能把增删改都赋予这个人。

    在这个模型中,我们把权限赋予角色,再把角色赋予用户。用户和角色,角色和权限都是多对多的关系。

    用户拥有的权限等于他所有的角色持有权限之和。

     数据库表设计:

 用户-用户组-角色-权限

    当用户的数量非常大时,要给系统每个用户逐一授权(授角色),是件非常烦琐的事情。这时,就需要给用户分组,

    每个用户组内有多个用户。除了可给用户授权外,还可以给用户组授权。这样一来,用户拥有的所有权限,就是用户

    个人拥有的权限与该用户所在用户组拥有的权限之和。(下图为用户组、用户与角色三者的关联关系)

     数据库设计:

     这个时候发现,我用户没有和权限进行关联,为什么不关联呢?不是不可以,是根据业务场景来,基本上一个

     用户所拥有的权限来源于他的职责范围,而职责范围是一个权限的集合,而且,业务系统中这种场景不多,并且

     可以通过再次新建一个角色进行关联单独解决。如果有业务需要,增加一个用户-权限表就可以了。

数据权限控制

    当我们查询敏感数据时候,每个人对某个表都有查询权限,但是部门人员只能查询本部门的数据,但是总部可以

    查询所有的,这个时候就要涉及到数据权限隔离。

    首先,人员或者组我们可以使用以上功能权限的表格数据,对不同的功能数据类型进行不同的控制,这个时候需要

    一张功能表,一张组/用户-数据表(通过标识区分用户或者租),用来记录数据权限。

     其中数据类型可以存放到字典中,主要是功能的一个唯一标识。大体上我们可以分为4个主要对象:

     用户,关联表,系统数据,功能。

    数据来源是系统中各个表格的待查询类型数据。例如我们查询个人工资数据,每个人只能查询自己的,这个可以

    做名称条件限制,但是各个部门人力资源需要知道部门内人员的薪资数据,总公司可以查询到全部的数据。我们

    可以将薪资数据查询作为一个功能类型-01(薪资查询)存放到字典中,然后将部门作为另一个类型从系统中部门

    表读取,并根据不同的部门分配不同的部门数据(如果还需要根据其他其他类型做区分,只需要增加组/用户-数据

    表字段就可以了,例如只能看到某一职级人员,不能看到老总那个职级的数据,就可以把职级也添加成一个条件)。

建议组/用户-数据表的设计.(id,用户或者组id,用户或者组标识,数据类型(例如:部门),功能类型(01-薪资查询),扩展1(职级数据),….)

猜你喜欢

转载自blog.csdn.net/programlight/article/details/83186198
今日推荐