RBAC权限模型

基于角色的访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到广泛的关注。在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而 得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以 很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起 来以囊括更广泛的客观情况。

RBAC支持三个著名的安全原则:最小权限原则,责任分离原则和数据抽象原则。最小权限原则之所以被RBAC所支持,是因为RBAC可以将其角色配置成其 完成任务所需要的最小的权限集。责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现,比如要求一个计帐员和财务管理员共参与同一过 帐。数据抽象可以通过权限的抽象来体现,如财务操作用借款、存款等抽象权限,而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC 各部件的详细配置才能得以体现。

RBAC有许多部件,这使得RBAC的管理多面化。尤其是,我们要分割这些问题来讨论:用户与 角色的指派;角色与权限的指派;为定义角色的继承进行的角色与角色的指派。这些活动都要求把用户和权限联系起来。然而在很多情况下它们最好由不同的管理员 或管理角色来做。对角色指派权限是典型的应用管理者的职责。银行应用中,把借款、存款操作权限指派给出纳角色,把批准贷款操作权限指派给经理角色。而将具 体人员指派给相应的出纳角色和管理者角色是人事管理的范畴。角色与角色的指派包含用户与角色的指派、角色与权限的指派的一些特点。更一般来说,角色与角色 的关系体现了更广泛的策略。

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中,who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

  Who:权限的拥用者或主体(如Principal、User、Group、Role、Actor等等)

  What:权限针对的对象或资源(Resource、Class)。

  How:具体的权限(Privilege,正向授权与负向授权)。

  Operator:操作。表明对What的How操作。也就是Privilege+Resource

  Role:角色,一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.

  Group:用户组,权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承),也可以包含用户,组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化,以满足不同层级权限控制的要求。

  RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role,role可以包括多个user。

  凡是用过RDBMS都知道,n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上,整个RBAC都是基于关系模型。

  Session在RBAC中是比较隐晦的一个元素。标准上说:每个Session是一个映射, 一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候,建立一个session。每个Session和单个的user关联,并且每个 User可以关联到一或多个Session.

  在RBAC系统中,User实际上是在扮演角色(Role),可以用Actor来取代 User,这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限,RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念 就具象到一个人。

  这里的Group和GBAC(Group-Based Access Control)中的Group(组)不同。GBAC多用于操作系统中。其中的Group直接和权限相关联,实际上RBAC也借鉴了一些GBAC的概念。

  Group和User都和组织机构有关,但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型,包括部门,人,职位等等,而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。

  Party模式中的Person和User的关系,是每个Person可以对应到一个 User,但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization,都可以对应到 Group。反之Group未必对应一个实际的机构。例如,可以有副经理这个Group,这是多人有相同职责。

  引入Group这个概念,除了用来解决多人相同角色问题外,还用以解决组织机构的另一种授权问题:例如,A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group,就可直接授权给这个Group。

### RBAC权限模型概念 RBAC(Role-Based Access Control),即基于角色的访问控制,是一种用于管理用户对资源访问权限的方法。其核心思想在于通过定义角色来间接分配权限给用户,从而简化复杂的权限管理系统[^1]。 在RBAC模型中,“Who”表示用户,“What”代表资源,“How”则指代操作行为。这三者共同构成了一种访问权限三元组关系:“谁能够对什么执行何种操作”。这种机制使得权限管理和分配更加灵活且易于维护[^3]。 --- ### RBAC权限模型实现原理 #### 1. 用户与角色关联 用户被赋予一个或多个角色,而这些角色决定了该用户可以访问哪些资源以及能对其进行什么样的操作。例如,在企业系统中,管理员可能拥有“超级管理员”的角色,而普通员工仅具有“查看员”的角色[^4]。 #### 2. 角色与权限绑定 每个角色都对应一组特定的权限集合。当某个用户被授予某一角色时,他便自动获得了与此角色相关联的所有权限。这种方式减少了直接为每位单独设置复杂权限的需求。 #### 3. 资源保护 对于受控资源而言,只有具备适当权限的角色才能对其实施允许范围内的动作。比如文件夹读取、数据库记录修改等均需经过严格的验证过程以确认当前登录者的身份及其所拥有的权利是否满足条件。 --- ### Java实现RBAC权限模型示例 以下是利用Java语言构建的一个简单版本RBAC框架: ```java // 定义实体类 public class User { private String id; private List<String> roles; // 用户所属角色列表 public boolean hasPermission(String resource, String action){ for (String role : this.roles){ Role r = getRoleById(role); if(r != null && r.isAllowed(resource,action)){ return true; } } return false; } } class Role{ private String name; private Map<String,List<String>> permissions; public boolean isAllowed(String resource,String action){ if(this.permissions.containsKey(resource)){ List<String> actionsList = this.permissions.get(resource); return actionsList.contains(action); }else{ return false; } } } ``` 上述代码片段展示了如何判断某位用户是否有权针对指定资源执行特定行动的功能逻辑。 --- ### 小结 综上所述,RBAC不仅提供了一个清晰明了的方式来描述并处理安全需求,而且还能有效降低因频繁更改个人级别设定所带来的错误风险。它广泛应用于各类信息系统当中,成为现代软件开发不可或缺的一部分[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值