海关总署发布规范跨境支付企业登记管理公告
705
2023-03-10
本文目录一览:
权限管理是所有后台系统的都会涉及的一个重要组成部分工单系统设计用户权限,主要目的是对不同的人访问资源进行权限的控制工单系统设计用户权限,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题。
迄今为止最为普及的权限设计模型是RBAC模型,基于角色的访问控制(Role-Based Access Control)
RBAC-0模型是权限最基础也是最核心的模型,它包括用户/角色/权限,其中用户和角色是多对多的关系,角色和权限也是多对多的关系。
用户 是发起操作的主体,按类型分可分为2B和2C用户,可以是后台管理系统的用户,可以是OA系统的内部员工,也可以是面向C端的用户,比如阿里云的用户。
角色 起到了桥梁的作用,连接了用户和权限的关系,每个角色可以关联多个权限,同时一个用户关联多个角色,那么这个用户就有了多个角色的多个权限。
有人会问了为什么用户不直接关联权限呢?在用户基数小的系统,比如20个人的小系统,管理员可以直接把用户和权限关联,工作量并不大,选择一个用户勾选下需要的权限就完事了。
但是在实际企业系统中,用户基数比较大,其中很多人的权限都是一样的,就是个普通访问权限,如果管理员给100人甚至更多授权,工作量巨大。
这就引入了 "角色(Role)" 概念,一个角色可以与多个用户关联,管理员只需要把该角色赋予用户,那么用户就有了该角色下的所有权限,这样设计既提升了效率,也有很大的拓展性。
权限 是用户可以访问的资源,包括页面权限,操作权限,数据权限:
以上是RBAC的核心设计及模型分析,此模型也叫做RBAC-0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC-1,RBAC-2,RBAC-3模型。下面介绍这三种类型
此模型引入了角色继承(Hierarchical Role)概念,即角色具有上下级的关系,角色间的继承关系可分为一般继承关系和受限继承关系。
一般继承关系仅要求角色继承关系是一个绝对偏序关系,允许角色间的多继承。
而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色间的单继承。这种设计可以给角色分组和分层,一定程度简化了权限管理工作。
基于核心模型的基础上,进行了角色的约束控制,RBAC2模型中添加了责任分离关系。
其规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。主要包括以下约束:
即最全面的权限管理,它是基于RBAC-0,将RBAC-1和RBAC-2进行了整合。
当平台用户基数增大,角色类型增多时,而且有一部分人具有相同的属性,比如财务部的所有员工,如果直接给用户分配角色,管理员的工作量就会很大。
如果把相同属性的用户归类到某用户组,那么管理员直接给用户组分配角色,用户组里的每个用户即可拥有该角色,以后其他用户加入用户组后,即可自动获取用户组的所有角色,退出用户组,同时也撤销了用户组下的角色,无须管理员手动管理角色。
根据用户组是否有上下级关系,可以分为有上下级的用户组和普通用户组:
每个公司都会涉及到到组织和职位,下面就重点介绍这两个。
我们可以把组织与角色进行关联,用户加入组织后,就会自动获得该组织的全部角色,无须管理员手动授予,大大减少工作量,同时用户在调岗时,只需调整组织,角色即可批量调整。
组织的另外一个作用是控制数据权限,把角色关联到组织,那么该角色只能看到该组织下的数据权限。
每个组织部门下都会有多个职位,比如财务部有总监,会计,出纳等职位,虽然都在同一部门,但是每个职位的权限是不同的,职位高的拥有更多的权限。
总监拥有所有权限,会计和出纳拥有部分权限。特殊情况下,一个人可能身兼多职。
根据以上场景,新的权限模型就可以设计出来了,如下图:
根据系统的复杂度不同,其中的多对多关系和一对一关系可能会有变化
授权即给用户授予角色,按流程可分为手动授权和审批授权。权限中心可同时配置这两种,可提高授权的灵活性。
有了上述的权限模型,设计表结构就不难了,下面是多系统下的表结构,简单设计下,主要提供思路:
在项目中可以采用其中一种框架,它们的优缺点以及如何使用会在后面的文章中详细介绍。
权限系统可以说是整个系统中最基础,同时也可以很复杂的,在实际项目中,会遇到多个系统,多个用户类型,多个使用场景,这就需要具体问题具体分析,但最核心的RBAC模型是不变的,我们可以在其基础上进行扩展来满足需求。
基于角色的访问控制模型就是把“用户—角色—操作—资源”关联到一起,实现非自主型访问控制策略。使用基于角色的访问控制模型可以减轻安全管理工作,因为某种任务是稳定的,而负责该项任务的人员是经常变化的,这种方式只需把新的用户分配给已有的角色即可,无需为用户重新指定资源和操作,因而简化了授权管理工作。
为了保障本系统操作使用的信息安全,系统登录认证体系由三个要素组成:用户、角色、权限,三者相辅相成,共同组成系统的安全运行屏障。
1.用户信息
用户信息表统一管理,在用户信息表中存储用户名称、登录名、口令、各子系统权限、用户角色信息等。
用户信息表的添加、删除以及子系统权限修改由总系统授权的管理员执行,本系统中,用户信息表的操作在业务处理与信息服务子系统的系统管理菜单下的用户信息管理页面。用户口令可以自行改变,用户权限的变更需要提请管理员同意,并由管理员修改。
子系统启动时读取用户信息表验证用户权限,在系统运行时依据权限分配相应的功能。依据用户在子系统中的权限级别控制用户可操作的功能,实现最终用户对ORACLE数据库中数据的读取和添加操作权限控制(表8-2)。
表8-2 用户信息结构表
2.角色信息
角色可以根据需要任意多地添加,多个角色权限组合生成多个权限控制,对应到一个确定的用户,赋予用户对功能模块的控制权限。用户角色表包括角色名称、用户唯一值编码等信息。示例见表8-3。
表8-3 用户角色表(示例)
在数据库中为各个功能模块建立了功能名称表,每个功能模块均有记录,有功能编码和功能名称及其他附属信息。功能名称示例见表8-4。
表8-4 功能名称表(示例)
每个用户必须属于至少一个角色,每个角色具备多个功能的控制权限,功能权限通过角色传递给用户,从而实现用户对功能的操作权限控制。
3.权限信息
权限表明了用户可执行的操作。系统权限控制采用最大优先,用户可以拥有多个角色,每个角色对每一页面都可拥有权限,但在权限结果判断时只以最大权限为主,即管理员级权限大于并包含访问者权限。功能权限示例如表8-5所示。
表8-5 功能权限表(示例)
系统规划的子系统权限等级见表8-6。
表8-6 子系统权限等级规划表(部分)
续表
4.用户认证授权
通过以上四个表将用户、角色与权限组合起来,可以形成无穷多的用户权限组合,直接控制用户权限到每个细分功能。
用户、角色、权限、功能控制流程如图8-1所示:
图8-1 用户权限控制流程图
功能权限表仅在部署角色权限时使用,标示功能具备的可部署权限。
在角色中必须保证有一个管理角色拥有用户管理功能的管理权限,防止不能分配角色与权限,同样在用户中必须保证至少有一个用户是管理角色。
关于工单系统设计用户权限和工单系统设计用户权限有哪些的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 工单系统设计用户权限的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于工单系统设计用户权限有哪些、工单系统设计用户权限的信息别忘了在本站进行查找喔。发表评论
暂时没有评论,来抢沙发吧~