RBAC权限模型实例分析

权限体系和RBAC模型概述

RBAC（Role-Based Access Control）基于角色的访问控制。

20世纪90年代，大量专家、学者和专业研究单位对RBAC的概念进行了深入研究，并相继提出了多种类型的RBAC模型。其中，美国乔治梅森大学信息安全技术实验LIST提出的RBAC96模型最为系统且得到广泛认可。

RBAC认为权限的过程可以抽象概括为：判断逻辑表达式[谁可以对What执行How访问操作(Operator)]的值是否为i的求解过程是的。

将权限问题转换为“谁”、“什么”和“如何”的问题。谁、什么以及如何构成访问权限三元组。

RBAC支持公认的安全原则：最小权限原则、责任分离原则和数据抽象原则。

支持最小权限原则，因为在RBAC模型中可以通过限制分配给角色的权限数量和大小来实现。分配给用户对应的角色的权限只需要不超过该用户完成其他任务的能力即可。只要满足任务的需要就可以了。

实现职责分离的原则是因为在RBAC模型中，可以通过在完成敏感任务的过程中分配两个职责相互约束的角色来实现。例如，查账时，只需设置只有财务管理员和会计两个角色可以参与。

借助抽象权限的概念来实现数据抽象。例如，在账户管理活动中，可以使用贷记、借记等抽象权限来代替操作系统提供的读、写、执行功能。等待特定权限。然而，RBAC 并不强制执行这些原则。安全管理员可以允许配置 RBAC 模型，使其不支持这些原则。因此，RBAC对数据抽象的支持程度与RBAC模型的实现细节有关。

RBAC96是一个模型族，包括四个概念模型RBAC0~RBAC3。

1.基本模型 RBAC0 定义了完全支持 RBAC 概念的任何系统的最低要求。

2. RBAC1 和 RBAC2 都包含 RBAC0，但各自添加了独立的功能。它们被称为高级模型。

RBAC1 添加了角色层次结构的概念，其中一个角色可以继承另一个角色的权限。

RBAC2中添加了一些限制，强调了RBAC不同组件中配置的一些限制。

3. RBAC3被称为统一模型，它包括RBAC1和RBAC2。使用传递性，它还包括 RBAC0。这些模型构成了 RBAC96 模型系列。

RBAC模型简要说明

RBAC0的模型包括用户（U）和角色(R)、权限(P)等三类实体的集合。

RABC0是权限管理的核心部分。其他版本都是基于0的。看一下类图：

RBAC0定义了最小的元素集合即可构成RBAC控制系统。

在RBAC中，它包括五个基本数据元素：用户（USERS）、角色（ROLES）、对象（OBS）、操作（OPS）和权限（PRMS）。该模型指定了用户、角色、访问权限、nd 会议。

每个角色至少有一个权限，每个用户至少扮演一个角色；两个完全不同的角色可以被分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色以获得相应的访问权限。用户可以更改会话中的活动角色，并且用户可以主动结束会话。

用户和角色之间是多对多的关系，即一个用户在不同的场景下可以拥有不同的角色。

例如，项目经理也可以是项目架构师等；当然，一个角色可以赋予多个用户，例如一个项目中有多个团队负责人、多个团队成员等。

这里需要提到的是，用户和权限的分离是相互独立的，使得权限的授权和认证更加灵活。

存在多对多关系下注角色和权限（permissions）之间的关系，即一个角色可以拥有多个权限。很容易理解，可以将相同的权限授予多个角色。在现实生活中想想吧。在官员有不同级别权限的场景下，其实这个模型是对权限的抽象，联系生活就很容易理解。

RBAC1、在RBAC0模型的基础上，引入了角色之间的继承关系，即有上下级角色的区分。角色之间的继承关系可以分为一般继承关系和接受者关系。有限继承关系。一般遵循的继承关系只要求角色继承关系是绝对的偏序关系，允许角色之间的多重继承。受限继承关系进一步要求role继承关系采用树形结构，实现角色之间的单一继承。

该模型适用于角色之间层次清晰、包含明确的情况。

RBAC2基于RBAC0模型，进行角色访问控制。

RBAC2模型中增加了责任分离关系。 RBAC2的约束规定了为角色分配权限、为用户分配角色以及用户在某个时间激活角色时应遵循的强制规则。职责分离包括静态职责分离和动态职责分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问权限。约束有很多种。

互斥角色 ：同一用户最多只能分配给一组互斥角色中的一个角色，supp遵循职责分离的原则。互斥角色是指两个角色各自的权限相互限制。对于该类型的角色，用户在某一活动中只能被分配其中一种角色，而不能同时获得使用两种角色的权利。一个常见的例子：在审计活动中，一个角色不能同时分配给会计角色和审计员角色。

基数约束 ：分配给某个角色的用户数量受到限制；用户可以拥有的角色数量是有限的；同一角色对应的访问权限数量也应进行限制，以控制系统中高级权限的分配。例如，公司领导是有限的；

先决角色 ：只有当用户已经是另一个用户的成员时，才能将角色分配给用户角色;相应地，只有当角色已经存在时，才可以将访问权限分配给该角色。ady 有另一个访问权限。意思是，要想获得更高的权限，必须先拥有更低级别的权限。就像我们生活中一样，国家主席是从副主席中选举出来的。

运行时互斥 ：例如，允许用户拥有两个角色的成员资格，但两个角色不能同时激活运行时的时间。

RBAC3，是最全面的权限管理级别，它是在RBAC0的基础上，结合了RBAC1和RBAC2已经集成了，第一个也是最复杂的一个：

综上所述，上面是权限管理模型的介绍，会用到在任何系统中。涉及权限管理的模块，无论复杂还是简单，我们都可以使用RBA，基于C模型，我们可以灵活地使用它来解决我们的问题。

RBAC的优缺点

RBAC模型不提供操作顺序控制机制。这个缺陷使得RBAC模型很难应用于那些需要严格操作顺序的物理系统。

例如，在购物控制系统中，要求系统对购买步骤进行控制，不应该允许顾客在付款前拿走商品。 RBAC模型要求将这种控制机制放入模型中

2． RBAC模型的实用数据库建模

1.扩展RBAC用户角色权限设计解决方案

RBAC（Role-Based Access Control，基于角色的访问控制）是通过角色将用户与权限关联起来。简单来说，一个用户有多个角色，每个角色有多个权限。这样就构建了“用户-角色-权限”的授权模型。在该模型中，用户和角色、角色和权限之间通常存在多对多的关系。 （如下图）

作用是什么？可以理解为一个是一定数量的权限的集合和权限的载体。例如：在论坛系统中，“超级管理员”和“版主”就是角色。版主可以管理论坛里的帖子，管理论坛里的用户等等，这些都是权限。要将这些权限授予用户，您不需要直接向用户授予权限。您可以授予用户“主持人”角色。

当用户数量非常多时，对系统的每个用户进行一一授权（授予角色）是非常繁琐的。这时候就需要对用户进行分组，每个用户组有多个用户。除了对用户进行授权外，还可以对用户组进行授权。这样，一个用户拥有的所有权限就是该用户个人拥有的权限和该用户所属用户组拥有的权限的总和。 （下图展示了用户组、用户和角色之间的关系）

权限在应用中是什么样子的？在系统上？对功能模块的操作，对上传文件的删除和修改，对菜单的访问，甚至对页面上某个按钮或图片的可见性控制，都属于权限范围。有些权限设计会将功能操作视为一类，将文件、菜单、页面元素等视为另一类，从而形成“用户-角色-权限-资源”的授权模型。在做数据表建模时，可以对功能操作和资源进行统一管理，即直接与权限表关联起来，这样可能会更加方便，并且具有可扩展性。 （见下图）

请注意，权限表中有“权限类型”一栏。我们根据它的值区分它是哪种类型。权限，比如“MENU”代表菜单的访问权限，“OPERATION”代表功能模块的操作权限，“FILE”代表文件的修改权限，“乙LMENT”代表页面元素的可见性控制等。这样的设计有两个好处，一是不需要区分哪些是权限操作，哪些是资源（其实有时候不太容易区分，比如作为菜单，应该理解为资源还是功能模块权限？）。第二，方便扩展，当系统要控制新事物的权限时，只需要新建一张关联表“权限XX”

这里需要注意的是，权限表和权限菜单关联表是一一对应的关系，权限菜单关联表和菜单表。（同样适用于文件、页面权限、功能操作等）。即每次添加菜单时，都要同时向这三个表各插入一条记录。 这样，不需要权限菜单关联表，权限表直接与菜单表关联。这时候就必须在权限表中添加一个新列来保存菜单的ID。权限表是通过“权限类型”和这个ID来区分的。该类型下有哪些记录。

至此，RBAC权限模型扩展模型的完整设计图如下：

随着系统变得越来越大，为了方便管理，可以引入角色组对角色进行分类管理。与用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色挂在区局下面，区局在这里可以作为一个角色组，不参与权限分配。另外，为了方便上面各个主表的管理和查找，可以采用树形结构n 可以使用，比如菜单树、功能树等，当然这些不需要参与权限分配。

2.百度百科展示的模型

以上就是《RBAC权限模型示例分析》一文的全部内容，感谢您的阅读！相信大家都有一定的了解，希望分享的内容对大家有所帮助。如果您想了解更多知识，请关注行业资讯频道！