RBAC(Role-Based Access Control)

http://hi.baidu.com/akini/blog/item/eddbd61b90f6d4fbae513371.html

RBAC

求助编辑百科名片


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

目录

简介
RBAC基本概念
RBAC96模型
ARBAC97模型
DRBAC

展开

编辑本段简介

 
 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。

编辑本段RBAC96模型

RBAC0

 
 1. U:表示用户集; R:表示角色集; P:表示权限集; S:表示会话集;   2.
PAÍP×R,是权限到角色的多对多指派;   3. UA Í U×R,是用户到角色的多对多指派;
  4. user: S→U,会话和用户的单一映射,user(si)表示创建会话si的用户;  5. roles:
S→2R,会话和角色子集的映射,roles(si)表示会话si对应的角色集合;   6. 会话si具有的权限集 P(si)。

RBAC1

  在RBAC0的基础上加上了角色层次,反应了多级安全需求。

RBAC2

  在RBAC0的基础上加上了约束集合。

RBAC3

  RBAC1 的功能和RBAC2的功能的集合。

编辑本段ARBAC97模型

  ARBAC97模型是基于角色的角色管理模型,包括三个部分:   URA97:用户-角色管理模型  PRA97:权限-角色管理模型   RRA97:角色-层次管理模型

编辑本段DRBAC

 
 DRBAC是动态结盟环境下的分布式RBAC模型。  DRBAC区别于以前的信任管理和RBAC方法就在于它支持3个特性:  1.第三方指派:一个
实体如果被授权了指派分配后,就可以指派它的名字空间以外的角色。  2.数字属性:通过分配处理与角色有关的数值的机制来调整访问权限。  3.指派监
控:用pub/sub结构对建立的信任关系进行持续监控来跟踪可被取消的指派的状态。  DRBAC是由在结盟环境下对资源的访问控制这个问题引出的。
“结盟环境”可以是军事上几个国家一起工作达到一个共同的目标,或者商业上几个公司合伙。结盟环境定义的特点是存在多个组织或多个实体没有共同的可信的授
权中心。在这种情况下,实体在保护它们各自的资源的同时还必须协作来共享对结盟来说必要的受保护资源的部分。Internet上网络服务的增长使这样的需
求很普遍。  DRBAC结合了RBAC和信任管理系统的优点,是既管理灵活又可分散地,可扩展的实现的系统。DRBAC表示依据角色的受控行为,角色在
一个实体的信任域内定义并且可以将这个角色传递地指派给不同信任域内的其他角色。DRBAC利用PKI来鉴别所有与信任敏感操作有关的实体以及确认指派证
书。从角色到授权的名字空间的映射避免了确认额外的策略根源的需要。

时间: 2024-10-24 22:15:01

RBAC(Role-Based Access Control)的相关文章

Azure RBAC(Roles Based Access Control)正式上线了

期盼已久的Azure RBAC(Roles Based Access Control)正式上线了. 在很多情况下,客户需要对各种类型的用户加以区分,以便做出适当的授权决定.基于角色的访问控制 (RBAC) 的思路是为用户可以担任的角色分配权限,从而恰当定义界限来限定某类用户可以执行和不可执行的操作. 假设想开发一个仅供销售团队使用的应用程序.要访问该应用程序,用户不仅必须是公司目录中的成员,而且要被分配到销售组,确保只有经过身份验证的销售团队成员才能访问该应用程序.

Azure ARM (16) 基于角色的访问控制 (Role Based Access Control, RBAC) - 使用默认的Role

<Windows Azure Platform 系列文章目录> 今天上午刚刚和客户沟通过,趁热打铁写一篇Blog. 熟悉Microsoft Azure平台的读者都知道,在老的Classic Portal里面,我们可以设置共同管理员(Co-admin). 参考:Windows Azure Active Directory (3) China Azure AD增加新用户 但是Co-Admin和服务管理员(Service Admin)的权限是一样的. 比如上图的admin创建的任何资源,是可以被ne

Azure ARM (17) 基于角色的访问控制 (Role Based Access Control, RBAC) - 自定义Role

<Windows Azure Platform 系列文章目录> 在上面一篇博客中,笔者介绍了如何在RBAC里面,设置默认的Role. 这里笔者将介绍如何使用自定的Role. 主要内容有: 一.了解Role中的Action和NotAction 二.通过PowerShell,查看相应的Action 三.编辑json Template,自定义Role 四.设置相应的Role 五.删除自定义Role 一.了解Role中的Action和NotAction 比如SQL DB Contributor这个Ro

[认证授权] 6.Permission Based Access Control

在前面5篇博客中介绍了OAuth2和OIDC(OpenId Connect),其作用是授权和认证.那么当我们得到OAuth2的Access Token或者OIDC的Id Token之后,我们的资源服务如何来验证这些token是否有权限来执行对资源的某一项操作呢?比如我有一个API,/books,它具有如下5个操作: POST /books 添加一本书 GET /books/{id} 获取一本书 PUT /books/{id} 更新一本书 DELETE /books/{id} 删除一本书 GET

关于RBAC(Role-Base Access Control)的理解

基于角色的访问控制(Role-Base Access Control) 有两种正在实践中使用的RBAC访问控制方式:隐式(模糊)的方式和显示(明确)的方式. 今天依旧有大量的软件应用是使用隐式的访问控制方式.显示的访问控制方式更适合于当前的软件应用. 隐式的访问控制 隐式的访问控制就是并没有给角色添加具体权限操作,只是给访问的用户添加了一个标识,告诉系统我是隶属于这个角色的,只要系统允许这角色操作的资源,我就有权限去操作. 比如说,我现在某个系统有两个角色,分别是“超级管理员”,"项目管理员&q

php_ThinkPHP的RBAC(基于角色权限控制)详解

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

RBAC (基于角色的访问控制)

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

Risk Adaptive Information Flow Based Access Control

Systems and methods are provided to manage risk associated with access to information within a given organization. The overall risk tolerance for the organization is determined and allocated among a plurality of subjects within the organization. Allo

【转载】增强学习(Reinforcement Learning and Control)

增强学习(Reinforcement Learning and Control)  [pdf版本]增强学习.pdf 在之前的讨论中,我们总是给定一个样本x,然后给或者不给label y.之后对样本进行拟合.分类.聚类或者降维等操作.然而对于很多序列决策或者控制问题,很难有这么规则的样本.比如,四足机器人的控制问题,刚开始都不知道应该让其动那条腿,在移动过程中,也不知道怎么让机器人自动找到合适的前进方向. 另外如要设计一个下象棋的AI,每走一步实际上也是一个决策过程,虽然对于简单的棋有A*的启发式