怎么用RBAC模型创建后台安全管理

Posted 2023-03-28

我就是想做个后台网站，这里有7到8个的角色，有很多用户，客户就是想总管理员可以为每个角色授予权限，也就是细化到了每一项，比如，对系统账单的查询，用户资料的查看等权限在后台能勾选的，打勾的说明角色有权限，没有说明没有，这个该怎么做啊？后台设计该怎么设计呢？

参考技术A 你看这个模型有不有用（自己看着你们上面讨论的 就去敲了一下）use master
go
if exists(select * from sysdatabases where name = 'HMS')
drop database HMS
go
------------------建库
create database HMS
on primary
(
name = 'HMS_data',
filename = 'D:\数据库\数据库存放包\HMS_data.mdf',
size = 5,
filegrowth=15%
)
log on
(
name = 'HMS_log',
filename = 'D:\数据库\数据库存放包\HMS_log.ldf',
size = 3,
filegrowth=10%
)
go
-----------------建表(不考虑项目表)
use HMS
go
-----建立用户信息表
create table users
(
uid varchar(10) primary key,--用户编号
uname varchar(20) not null,--用户姓名
upassword varchar(16) default('888888') not null,--用户密码
usex char(2) check(usex = '男' or usex = '女') not null,--用户性别
uage int check(uage>=16 and uage<=60) not null,--用户年龄
upid varchar(18) check(len(upid)=15 or len(upid)=18) not null,--用户身份证
uactive char(2) check(uactive = '是' or uactive = '女') not null,
uphono varchar(13) check(uphono like '____-_______' or uphono like '____-________' or len(uphono)=11 ),--联系电话
uaddress varchar(50) default('地址不详'),--家住地址
uremark varchar(100)--备注
)
go
---建立角色表
create table roles
(
rid varchar(10) primary key,--角色编号
rname varchar(20) not null,--角色名称
rremark varchar(100),--角色备注
)
go
--建立资源表
create table resources
(
sid varchar(10) primary key,--资源编号
sname varchar(20) not null,--资源名称
sremark varchar(100),--资源备注
)
go
-----建立用户角色表
create table users_roles
(
urid int identity(1,1) primary key,--用户角色编号 自动增长
uruid varchar(10) not null,--外键 引用用户表的主键
urrid varchar(10) not null--外键 引用角色表的主键
)
go

--建立角色资源表
create table roles_resources
(
rrid int identity(1,1) primary key,--角色资源编号 自动增长
rrrid varchar(10) not null,--外键 引用角色表主键
rrsid varchar(10) not null--外键 引用资源表主键
)
go
--添加约束
alter table users
add
constraint ck_pass check(len(upassword)>=6 and len(upassword)<=16),
constraint df_usex default('男')for usex,
constraint df_uactive default('是') for uactive
go

alter table users_roles
add
constraint fk_users_roles_users_uid foreign key(uruid) references users(uid),
constraint fk_users_roles_roles_rid foreign key(urrid) references roles(rid)
go

alter table roles_resources
add
constraint fk_roles_resources_roles foreign key(rrrid) references roles(rid),
constraint fk_roles_resources_resources foreign key(rrsid) references resources(sid)
go 因该可以解决你的问题 参考技术B 用户-角色-权限通过权限表的字段来控制url或者业务方法的访问

如何从0到1建立后台权限管理系统

参考技术A     权限模型主要有这四类：自主访问控制（DAC: Discretionary Access Control）、强制访问控制（MAC: Mandatory Access Control）、基于角色的访问控制（RBAC: Role-Based Access Control)、基于属性的权限验证（ABAC: Attribute-Based Access Control）。

    当前使用最普遍的是RBAC模型，即用户-角色-权限。该模型可以满足大部分的业务场景，较为细化复杂的权限，也可结合ABAC模型来实现。

    系统会有若干个功能，但是不同模块功能会对应企业中不同的管理者，那么权限不尽相同。为了灵活分配给不同用户不同权限，衍生出了用户-角色-权限模型，一个角色封装多个权限操作，可直接将该角色分配给用户：

    若大量用户使用同一个角色，则每次分配，仍会有很多重复劳动，所以衍生出了「用户组」的概念，将用户绑定到一个组上，可为这个组赋予一个角色，组下的用户均有这个角色：

    同理，角色之间有很多相同的权限，每个维护角色时都要勾选大量的权限，因此可以增加「权限组」的概念，将通用的权限打包成组，分配给角色。

    在设计系统时，可具体问题具体分析，较简单的系统，无需设计的太过复杂，越复杂越灵活，同时越灵活也越复杂；要考虑实际业务场景、培训成本等各个因素。在设计表结构的时候，可以预留出组的概念，产品设计层面0到1，无需设计过于复杂。

    用户，即账号的概念，登录系统要有账号，账号关联着角色，决定可以看到什么、操作什么；每个账号可看到的数据范围也各有不同，因此可以根据不用行业的字段属性，去为账号配置数据范围，也就是基于属性的权限验证（ABAC: Attribute-Based Access Control）。

    权限可以再细分为字段权限和菜单功能权限，不同账号进入系统时，看到的菜单、菜单中的功能都有所不同，进入同一个页面时，页面中的字段是否展示，也各不相同。

    因此，我们在设计权限体系时，可以参考该思考方式去设计。

    5步搭建权限管理：创建账号、创建角色、字段权限设计、菜单功能权限设计、数据范围设计。本文将以人事系统为例，进行权限搭建说明。

    孤立的系统，可单独设计注册逻辑、后台添加账号逻辑进行账号的创建；人事系统作为员工入离职的核心，因此可在入职成功时，系统自动为其创建一个单点登录账号；离职时，自动失效账号。

    如果需要引用用户组的概念，则可根据一些特定的规则，例如部门、岗位等，自动加入某用户组。也可设计页面为其手动维护到用户组中。

    创建角色时，可设置该角色属于哪个角色组，没有角色组概念则可忽略；是否可向下赋权，即该角色是否可设置子角色并分配权限，一般非集团企业，可不进行此设计。

    一般情况下，创建角色只要维护角色名称和描述即可。较为复杂的，可引入角色组或向下赋权的概念，例如集团企业。

    在角色下，可为不同系统模块分配字段权限；例如，在员工管理模块，可编辑基本信息、工作信息、学历信息，在个人档案模块仅可只读基础信息（具体如何设计系统表结构、字段等，本文不做详细说明，后面有机会会在别的文章进行说明）。

    账号是否有菜单功能权限，即是否配置了相关的接口权限；在产品设计时，需要梳理好各个页面功能的颗粒度，这样研发同学在拆分接口的时候，才能更好的规划。

    一般权限配置都是由系统管理员来完成，所以保证逻辑通畅、页面较清晰即可；商业化的产品，一般会将菜单功能梳理出来列举好，让用户学会自己勾选配置，通常层级为：目录模块-菜单-功能。如果是内部系统定制化开发，则可不必拘泥于形式，能配置即可，例如下图，先在后台把菜单与功能的接口配置好，再在角色中勾选这些接口，组合成角色-权限。

    当多个人拥有相同的菜单和功能，但管理的数据范围有所不同时；例如：A和B同样是HRBP，管理着团队的入离职等情况，但A负责的是产品部，B负责的是企业内所有组长等。此时就需要为不同人划分不同的数据范围，由于人事系统主要的划分属性来源于员工属性，因此在设计员工表的时候，可根据业务划分成不同对象（或者说是表），对象下拥有不同的字段（或者说是员工属性），再根据字段的不同类型，将逻辑判断区分出来；例如，日期格式字段，逻辑判断可为＞/≥/＜/≤/介于/≠/＝等；字典值字段，逻辑判断可为属于/不属于/为空/不为空等。

    如果是其他行业，则可根据具体场景划分出不同属性；这个就是基于属性的权限验证（ABAC: Attribute-Based Access Control）。

    当每个人都有数据范围时，在做数据共享类似功能时，例如员工档案数据分享时，可仅分享数据统计的逻辑、数据来源，而能看到哪些字段和数据范围则取决于账号本身的权限。

    一般针对中小型企业的商业化产品的权限都不会做的过于复杂，但是万变不离其宗，无论页面如何设置，其本质没有什么变化。以钉钉举例，钉钉在设置管理范围时，仅支持按组织架构划分，由于钉钉人事模块是后发展起来的，一开始并没有过多的内置各种属性字段，因此管理范围也只能做成根据组织架构划分。但是日常基本够用了。

    当「智能人事」中权限选择细分时，可以看到在单独这个业务下，钉钉也是划分了不同的人事模块，并且不同模块可单独配置字段权限，虽然现在只有员工档案一个模块。但是可以看到架构基本还是这一套，后面也支持各种扩展。