【分布式技术专题】「架构设计方案」盘点和总结RBAC服务体系的功能设计及注意事项技术体系

简介: 【分布式技术专题】「架构设计方案」盘点和总结RBAC服务体系的功能设计及注意事项技术体系

前言介绍

权限管理是后台系统的重要组成部分,主要目的是控制不同人对资源的访问权限,以避免操作错误和隐私数据泄露等风险问题。我在公司负责权限管理,对该领域的设计很熟悉。公司采用微服务架构,因此权限系统独立于其他业务系统,包括商品中心、订单中心、用户中心、仓库系统、小程序和多个APP等十几个系统和终端。

权限模型

目前最普遍的权限设计模型是基于角色的访问控制(RBAC)模型。RBAC的核心设计及模型分析,此模型也叫做RBAC0,而基于核心概念之上,RBAC还提供了扩展模式。包括RBAC1,RBAC2,RBAC3模型。而对于RBAC模型的总体发展方向主要需要经历大致四个版本。

RBAC0模型

【RBAC0模型】 这是权限管理中最基础且核心的模型,包括用户、角色和权限。用户和角色之间存在多对多的关系,同样角色和权限之间也是多对多的关系,RBAC0模型如下:

  • 用户:发起操作的主体,根据类型可划分为2B和2C用户,可以是后台管理系统的用户、OA系统的内部员工,也可以是面向C端用户,比如阿里云的用户。
  • 角色:起到了桥梁的作用,连接了用户和权限之间的关系。每个角色可以关联多个权限,并且一个用户可以关联多个角色。这样,一个用户就拥有了多个角色所具有的多个权限。
  • 权限:用户可以访问的资源,包括页面权限、操作权限和数据权限。通过对用户、角色和权限之间的合理关联,可以实现权限管理的灵活性和高效性。

角色出现的原因

实际的企业系统中,用户基数通常较大,其中很多人所具有的权限都是相同的,即普通的访问权限。如果管理员需要给100甚至更多的人授权,工作量将会非常巨大。

因此,引入了"角色"的概念。一个角色可以与多个用户关联,管理员只需要将该角色赋予用户,那么用户就拥有了该角色下的所有权限。这样的设计既提升了效率,又具有很大的拓展性。

权限的种类介绍

- 页面权限:用户登录系统后可见的页面,通过菜单进行控制。菜单分为一级和二级分类。只要用户拥有一级和二级菜单权限,就可以访问相应的页面。

  • 操作权限:页面的功能按钮,包括查看、新增、修改、删除、审核等。当用户点击删除按钮时,后台会验证用户角色是否具有删除权限。如果具有该权限,则可以进行下一步操作;否则,会提示无权限。有些系统要求“可见即可操作”,即只要用户可以看到操作按钮,就可以进行相应的操作。
  • 为实现这一需求,前端需要与后台进行协作。前端开发人员会缓存用户的权限信息,并在页面上判断用户是否拥有该权限。如果有,就显示该按钮;如果没有,则隐藏该按钮。这在一定程度上提升了用户体验。但在实际场景中,是否采用这种做法可以根据具体需求进行选择。
  • 数据权限:不同用户在同一页面上看到的数据不同。例如,财务部只能查看本部门的用户数据,采购部只能查看采购部的数据。在一些大型公司中,可能存在多个城市和分公司,例如杭州用户只能查看杭州的数据,上海用户只能查看上海的数据。一种解决方案是将数据与具体的组织架构关联起来。举个例子,在为用户授权时,用户可以选择某个角色,同时绑定具体的组织架构,如财务部或合肥分公司。这样,该用户就具有了该角色下财务部或合肥分公司的数据权限。

RBAC1模型

RBAC1模型引入了角色继承的概念,即角色之间具有上下级的关系。角色的继承关系可以分为一般继承关系和受限继承关系。一般继承关系只要求角色继承关系是一个绝对偏序关系,允许角色之间存在多继承。而受限继承关系则进一步要求角色继承关系是一个树结构,实现角色之间的单继承。这种设计可以将角色进行分组和分层,从而简化了权限管理工作。

RBAC2模型

RBAC2模型在RBAC1的基础上, 加入了角色的约束控制, 这个控制包含了责任分离关系。在RBAC2模型中, 规定了在分配权限给角色, 将角色分配给用户, 以及用户激活角色时必须遵循的强制性规则。责任分离包括静态责任分离和动态责任分离。下面是一些主要约束规则:

  • 互斥角色: 同一用户只能被分配到互斥角色集合中的最多一个角色, 这样支持了责任分离原则。
  • 互斥角色是指彼此权限有上下约束关系的两个角色。例如, 财务部门有会计和审核员两个角色, 它们是互斥角色, 所以一个用户不能同时拥有这两个角色, 这体现了职责分离原则。
  • 基数约束: 限制了每个角色的用户数量;限制了每个用户可以拥有的角色数量;同样, 限制了每个角色对应的访问权限数量, 以控制高级权限在系统中的分配。
  • 先决条件角色: 即用户想要获得某一级别的角色, 必须先获得其下一级别的角色。换句话说, 用户必须按照一定的顺序依次获得角色。

通过这些约束规则, RBAC2模型可以更精确地控制角色之间的关系和权限分配, 提高了安全性和权限管理的灵活性。

RBAC3模型

RBAC3模型是一种更加细化和灵活的基于角色的访问控制模型,它结合了RBAC0模型的基本思想和RBAC1、RBAC2模型的进阶功能。同时,RBAC3模型还引入了用户组的概念,以更好地管理角色和用户之间的关系。 RBAC3模型的主要特点包括:

  • 角色继承关系:RBAC3模型允许角色之间建立继承关系,这意味着一个角色可以继承其他角色的权限。这种继承关系可以减少权限的重复定义,提高权限管理的效率。
  • 动态角色分配:RBAC3模型支持动态角色分配,即在运行时根据用户的需求和上下文环境,灵活地分配和撤销角色。这使得角色的分配更加适应变化的需求和业务场景。
  • 用户组概念:RBAC3模型引入了用户组的概念,将用户组与角色关联起来。通过将一组用户组织到用户组中,并将角色分配给用户组,可以更方便地管理和控制用户的权限。

用户组

伴随着业务场景越来越庞大,组织架构就会越来越大,因此用户角色越来越多,故此直接给每个用户分配角色将增加管理员的工作量。为了降低维护的成本,可以将具有一类相关联的用户人群归类到某个用户组中。权限维护人员只需给用户组分配角色,用户组内的每个用户将自动拥有该角色。 当其他用户加入用户组时,也会自动获取用户组的所有角色。同样地,当用户退出用户组时,也会撤销用户组下的角色,无需管理员手动管理角色。

用户组的分类

根据用户组是否具有上下级关系,可以分为具有上下级关系的用户组和普通用户组:

  • 具有上下级关系的用户组:最典型的例子就是部门和职位。部门和职位通常用于内部管理系统。
  • 普通用户组:即没有上下级关系,与组织架构和职位无关。换句话说,普通用户组可以跨部门、职位等。

具有上下级关系的用户组(组织)

将组织与角色进行关联,这样用户在加入组织后会自动获取该组织的全部角色,无需管理员手动授权,从而大大减轻了管理员的工作量。此外,当用户需要调岗时,只需调整其所属组织,角色会自动批量调整。 组织还有一个重要的作用是控制数据权限。将角色与组织相关联,那么该角色只能访问该组织下的数据,实现了精确的数据权限控制。这样的设计可以提高权限管理的效率和安全性。

总结介绍

权限系统是整个系统中最基础且复杂的部分。在实际项目中,我们可能会遇到多个系统、多个用户类型和多个使用场景,因此需要根据具体情况进行详细分析。然而,最核心的角色-权限访问控制(RBAC)模型保持不变,我们可以基于此模型进行扩展以满足各种需求。

目录
打赏
0
0
0
0
379
分享
相关文章
阿里二面:10亿级分库分表,如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图,看完直接上offer!
阿里二面:10亿级分库分表,如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图,看完直接上offer!
阿里二面:10亿级分库分表,如何丝滑扩容、如何双写灰度?阿里P8方案+ 架构图,看完直接上offer!
文生图架构设计原来如此简单之分布式服务
想象一下,当成千上万的用户同时要求AI画图,如何公平高效地处理这些请求?文生图/图生图大模型的架构设计看似复杂,实则遵循简单而有效的原则:合理排队、分工明确、防患未然。
55 14
文生图架构设计原来如此简单之分布式服务
【上云基础系列 02-01】通过SLB+1台ECS+ESS弹性伸缩,搭建一个精简版的上云标准弹性架构(含方案及教程)
通常,构建一个弹性架构(即使是一个最基础的入门版),至少需要2台ECS。但是,很多小微企业刚开始上云的时候,为了节省成本不愿意购买更多的服务器。通过 “ALB+ESS弹性伸缩+1台ECS+RDS”方案,在保障低成本的同时,也不牺牲业务架构的弹性设计,更避免了很多人因为节省成本选择了单体架构后频繁改造架构的困局。 方案中的几个设计非常值得小微企业借鉴:(1)通过ALB/RDS的按量付费,节省了初期流量不大时的费用;(2)通过ESS弹性伸缩,不需要提前购买服务器资源,但是当业务增长或减少时却保持了资源弹性自动扩缩容。
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
使用Qwen2.5+SpringBoot+SpringAI+SpringWebFlux的基于意图识别的多智能体架构方案
本项目旨在解决智能体的“超级入口”问题,通过开发基于意图识别的多智能体框架,实现用户通过单一交互入口使用所有智能体。项目依托阿里开源的Qwen2.5大模型,利用其强大的FunctionCall能力,精准识别用户意图并调用相应智能体。 核心功能包括: - 意图识别:基于Qwen2.5的大模型方法调用能力,准确识别用户意图。 - 业务调用中心:解耦框架与业务逻辑,集中处理业务方法调用,提升系统灵活性。 - 会话管理:支持连续对话,保存用户会话历史,确保上下文连贯性。 - 流式返回:支持打字机效果的流式返回,增强用户体验。 感谢Qwen2.5系列大模型的支持,使项目得以顺利实施。
930 8
使用Qwen2.5+SpringBoot+SpringAI+SpringWebFlux的基于意图识别的多智能体架构方案
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
90 11
云端问道9期方案教学-省心省钱的云上Serverless高可用架构
本文介绍了省心省钱的云上Serverless高可用架构,主要分为两个部分:1. Serverless的发展历程、特点及高可用架构;2. SAE(Serverless Application Engine)产品介绍。Serverless作为一种云计算模式,让用户无需管理底层基础设施,自动弹性扩展资源,按需付费,极大提高了资源利用率和业务灵活性。SAE作为Serverless计算服务,提供了简便的应用部署、运维自动化、丰富的弹性策略和可观测性等功能,帮助企业降低运营成本、提升研发效率。通过极氪汽车、南瓜电影等客户案例展示了SAE在实际应用中的优势。
大厂都在用的分布式事务方案,Seata+RocketMQ带你打破10万QPS瓶颈
分布式事务涉及跨多个数据库或服务的操作,确保数据一致性。本地事务通过数据库直接支持ACID特性,而分布式事务则需解决跨服务协调难、高并发压力及性能与一致性权衡等问题。常见的解决方案包括两阶段提交(2PC)、Seata提供的AT和TCC模式、以及基于消息队列的最终一致性方案。这些方法各有优劣,适用于不同业务场景,选择合适的方案需综合考虑业务需求、系统规模和技术团队能力。
646 7
|
3月前
|
Spring Boot中的分布式缓存方案
Spring Boot提供了简便的方式来集成和使用分布式缓存。通过Redis和Memcached等缓存方案,可以显著提升应用的性能和扩展性。合理配置和优化缓存策略,可以有效避免常见的缓存问题,保证系统的稳定性和高效运行。
96 3