访问控制——或者广义的称其为授权——作为概念，在人类有了保护自己的财产的意识时就已经存在。守卫、门和锁在远古时期就已经用作保护个人的财物不受他人侵犯。对访问控制的需求在很大程度上促进了被认为是世界上首个安全处理系统的诞生。在1879年，美国俄亥俄州代顿市一个名为James Ritty的酒馆老板设计出“清廉的出纳员”，即随后广为人知的现金出纳机。通过在顾客的完全注视下录入出售量，这样一项交易就被记入现金记录机，而且只有在此时店员才被允许使用存储现金的抽屉，Ritty的发明减轻了店员偷窃这个普遍存在的难题。通过记录销售量和记录不断增长的总计量，记录机使商店老板保证当天实际收入和记录的销售总量一致成为可能。
在当今的信息技术领域，授权这个概念，或者通俗地称之为“谁能做什么”，在计算机系统中用来控制用户对资源的访问。正如可提出证据加以证明的那样，访问控制被认为是如今使用最基本的、最普遍的安全机制。事实上访问控制在所有的系统中都有所表现，在不同级别的建筑系统设计、管理系统设计中都提出了巨大的挑战。从商业角度出发，访问控制拥有促进最佳的共享和资源交流的潜力，但同时它会增加大量的管理费用，造成未经许可的信息泄露或者关于有价值信息的腐败问题，使人感到阻挠。
访问控制有很多形式。除了决定一个用户是否有权访问一项资源外，访问控制系统可以约束在何时用何种方式访问资源。例如：用户只能在工作时间访问某个网络资源。有些机构可能建立更为复杂的控制规则。例如：像打开拱顶或者是发射导弹这些高危险性的操作，需要两名工作成员同时进行引导。访问控制的定义与模型在七十年代早期就有所显现，在八十年代成功地形成早期的标准，而RABC的出现则是在九十年代早期，直至发展到如今。本章介绍了访问控制的起源、历史和主要的概念，回顾了在当今使用得很多的访问控制结构，解释了RABC的基本概念和它在系统、应用程序和网络安全等方面的优势。
1.1 访问控制的用途及其基本原则
访问控制只是众多计算机安全解决方案的一种，但它也是有着最显著效果的方案之一。每当一个用户登录到一个多用户计算机系统，访问控制就强制执行。为了更好地理解访问控制的目的，我们有必要回顾一下关于信息系统的风险这一问题。信息安全问题分以下三个类型：机密性(confidentiality)、完整性(integrity)、可用性(availability)。可以简记为“CIA”。它们的描述如下：
机密性即是需要保证信息的安全性与保密性。这一类可能涵盖任何事物，从国家机密到私密的便笺，金融情报或者口令这种安全信息。
完整性即是要保护信息不受未被授权的用户进行不正当地篡改。例如：绝大多数用户都希望确保他们的银行帐号不受其他人修改，当然除了他自己或是他授权的安全管理员之外。
可用性即是信息在需要的时候是可用的这一概念。企图使公共网络服务器过载这一攻击行为即是一种被媒体广泛报道的可用性攻击。
访问控制在保护信息的机密性和完整性方面是值得肯定的。机密性的满足条件为只有被授权的用户才能获取信息，完整性的满足条件为只有经授权的用户才有权力通过一些规定的操作更改信息。访问控制明显地在保护信息的可用性方面有所欠缺，但明显它还是在这方面扮演一个重要的角色。一个攻击者想通过一些未被授权的方法入侵系统并破坏系统是有些困难的。
1.1.1 授权与认证
授权与认证是访问控制的基本原理。它们是截然不同的概念，但却常常被混淆。有些混淆来自于它们之间紧密的联系。严格意义上的授权事实上是依赖认证。
确定一个用户申明的身份是否是合法的这一过程即是认证。每个计算机用户都对口令，这个最普遍的认证形式很熟悉。如果Alice用alice46登录同时提供alice46这个身份的正确口令，那么她对系统认证了自己。还有些比较少见的认证方式，包括生物测定学（例如指识别）和智能卡。认证基于以下一个或多个因素：
- 一些你知道的，例如：口令，个人身份识别号，或者密码锁的密码；
- 一些你有的，例如：智能卡，自动出纳机卡，或者钥匙；
- 一些你本身具备的生理特征，例如：指纹，视网膜图案，或者面部特征。
明显地，如果认证过程使用两个或更多的因素，通常更加安全。密码可能被猜测出来，钥匙可能会遗失，面部识别系统有很大程度上的假阳性几率，所以只用这里面的一个认证方法可能无法提供一个可以接受的安全级别。这就是为什么银行同时需要自动出纳机卡和个人身份识别号才能让人使用自动出纳机，而不仅仅是一个口令、一把钥匙，或者一张磁卡而已。如果磁卡遗失，小偷只有三次机会猜测出个人身份识别号来通过认证系统。
认证是确定你是谁的过程，授权决定你被允许能什么。认证与一个用户是否被允许访问系统资源的判定结果有关；一个信息系统应当维持使用者身份与系统资源的一些联系，或者通过一个表单来联系被授权用户和资源，或者通过一个存储好的表单来联系可使用资源与每个用户身份。注意授权必须依靠正确的认证。如果一个系统不能确定一个用户的身份，那么就没有一个正确的决定，那个用户是否应该被授权访问资源。
1.1.2 用户、主体、客体、操作和权限
在过去30年中，为了描述访问控制的模型和系统，一个相当完备的术语范畴产生了。几乎任何一个访问控制模型都能在形式上用用户、主体、客体、操作和权限，还有这些实体之间关系这几个概念来规定。了解这些术语是很重要的，因为读者不仅仅在这本书中会碰到这些术语，而且在大多数访问控制和计算机安全的文献中都会遇到。
用户这个术语即是与计算机系统接触的人。在很多设计中，一个用户有多个登录身份是可能的，而且这些身份可能同时处于登录状态。认证机制使一个个人用户能够拥有多个身份成为可能。
一个用户和计系统的对话的实例被称作为会话。
一个代表用户操作的计算机进程被称为一个主体。需要注意的是，事实上一个用户在计算机系统上的行为都是通过一些在计算机上的程序的运行表现出来的。一个用户可能会同时拥有多个正在运行的主体，即使这个用户仅仅用一个身份登录而且仅仅发起了一个会话。例如：一个电子邮件系统可能在后台运行，定时地从一个电子邮件服务器收取电子邮件，而同时这个用户在运行一个网页浏览器。一个用户的每个程序都是一个主体，而且每个程序的访问都要被检查以确保调用这些程序的用户有相关的授权。
一个客体可能是一个计算机系统上的任何一个可用的资源，包括文件、外围设备，如打印机、数据库和一些更细微的实体，例如数据库记录中的一块单独的区域。尽管在早些时候，访问控制模型中有可能会把程序、打印机或者其它主动的实体看作客体，但传统地看来，客体是被动的实体，它包含或接收信息。
操作是一个主体调用一个运行的程序的过程。早期的访问控制模型——即是在数据流中严格控制的模型（也就是读写访问）——将所有的主动程序都以术语主体来归纳，但是在RABC模型中需要区别主体和操作。例如：当一位自动出纳机用户塞入一张磁卡再输入正确的个人身份识别码，通过用户的行为而运行的控制程序就是主体，而这个主体可以发起多个操作——存款，取款，余额查询，或者其它的功能。
权限（或者特权）就是在计算机系统上执行一些操作的授权。在本书中，在大多数计算机安全文献中，权限这一术语用来表示客体和操作的一些联系。一个应用于两个不同的客体特殊的操作表现出两种截然不同的权限，同样地两个不同的操作应用于一个单独的客体表现出截然不同的权限。例如：一个银行出纳员可能有权通过事务处理在客户的记录上执行借记操作和存款操作，而一个会计师可能会执行借款和存款操作的总帐清算，以巩固银行的账目资料。
1.1.3 最小特权
最小特权是一个历史悠久的选择性分配权限的管理习惯。除了分配他或她为了完成工作职责所必需的权限外，任何其它的权限都不应当被授予。最小特权原则消除了个体有能力执行不必要的和潜在有害的操作这一问题，而这一问题仅仅是完成需要的任务而授权的副作用。然后这个问题就变成了怎样分配一种固定的系统权限与所有的任务相对应，而这些任务与一个用户的角色或一个代表用户操作的主体相对应。最小特权为了在什么地方设置权限的分界线提供了一个基本原理，而它是由访问控制机制而来。确保坚持最小特权这个原则是个主要的管理挑战，它需要鉴定工作职责，需要鉴定完成每个任务所需要的一套权限的范围，同时约束用户在一定范围内使用那些特权，不能有更多的操作。
严格执行最小特权原则需要一个个体有在不同时刻有不同级别的权限，这决定于任务完成过程。但我们要认识到，在某些情况下，在拥有某些权限的时候，因为是名义上地最小特权，权限的约束会让用户觉得不方便，会给管理员增加一些额外的负担。然而，授予额外的特权无论从完整性还是从机密性上来说都应当避免任何可能，因为潜在地它能被用作绕开保护系统。同样重要的是特权只能在执行任务过程中有效，任务完成后应当被收回。
1.2 访问控制简史
显然在六十年代的一些早期分时计算机系统中安全问题就被提出过，而计算机安全学科从七十年代初才开始迅速地发展。在那个时候大型资源共享系统在政府部门、军队、大型贸易组织中被广泛地使用。这个领域在政府和军事部门都得到了发展，在商业这个舞台上，例如自动出纳机，需要强力的安全保护。
1.2.1 大型机时代的访问控制
随着不断增长的多用户计算机系统和防御系统对计算机系统日益加深的依赖，在六十年代末，美国国防部科学部努力研究调查政府系统的弱点。大学研究人员也在考虑相关问题。最早的关于访问控制的正式定义及精确的描述的成果是由兰普森(Lampson)取得，他提出了主体、客体及作为主体和客体媒介的访问矩阵这些正式的概念。一个访问矩阵是一个简单的概念上的表示法，在矩阵中( i,j )这一项目指定的是主体 i 对客体 j 所拥有的权限。如图1.1所示，根据矩阵中详细说明的权限，主体（被用户调用的程序）被允许访问客体，如文件或者是外围设备。例如：用户Bob对薪水册有读和写的访问权限，对应收款和应付款文件有读的权限。
| General ledger | Payroll | Accounts receivable | Accounts payable | |
| Alice | R,W | R | R | |
| Bob | R,W | R | R | |
| Charles | R | R | R |
图 1.1 访问矩阵
一份1970年兰德（RAND）公司的报告对国防部计算机系统的安全性做了全面的分析。报告包含在一个资源共享系统中实现多级——就是将文件用安全级别来分类，例如：机密、秘密、最高机密——访问控制的方案的详细说明，它对本地访问和远程访问用不同的方式处理，远程访问需要基于口令的授权。这份文件也论述了这种方案最基本的需求，它是基于存储在系统里的用户的保密级别与文件的分级级别来实现的。多级安全系统由一份美国空军的报告得以扩展，报告提到一个用于通信的相关系统的工程研发计划。
Bell和LaPadula用数学模型将军用的访问控制规则形式化，以便定义和评估计算机安全系统。用这种明确的表达方式，多级安全系统实现了常见的政府文件分级规则：用户只允许访问安全级别低于或等于自己安全级别的信息。从概念上来说，这是很简单的策略，很容易理解和执行。但是，由于信息技术太要注意的问题太多，在计算机系统中实现这看似简单的策略是需要技巧的。不可预见的漏洞和系统中不同的模块之间明显的交互作用会使一个计算机安全系统易于受到攻击。Bell-LaPadula模型是有重大意义的，因为它使多级安全系统形式化（就是数学模型化），那么从细节上分析模型的性质就变得可能。
形式化模型有两个基本的规则：简单安全性规则和*-性质，就是大家熟知的“向上写”和“向下读”。简单安全性规则是显而易见的：一个有指定安全级的用户不允许读安全级别比自己高的信息（例如：一个秘密级别的用户不能读一个最高机密的文件）。*-性质，从本质上来说，颠倒了简单安全性规则，它是这样保护安全系统的：一个在此指定安全级的用户只能写安全级比自己高或安全级与自己相同的文件。例如：一个用户用机密级别登录系统，那么他所调用的程序或处理进程不能写级别为秘密级别文件，显然它能写入一个安全级更高的文件中，比如说最高机密。（值得注意的是这个规则是有意义的，我们考虑到了计算机系统中运行的程序。显然，一个用户可能先用一个级别较高的身份登录系统，然后打印出文件或者记录下信息，再用一个安全级别较低的身份重新登录系统。）Bell-LaPadula模型也包含范畴这一概念，它穿过密级进行垂直分类。用户除了拥有一个密级之外，还需要一个范畴集标识，这个标识与保密文件系统在一起。例如：一份文件可能会这样分类[机密，核能，NATO]。如果想访问这份文件，用户的安全级别必须是机密或机密以上，而且他的范畴集应该有两项——核能和NATO。（第二章会对这些规则进行详细的讨论）这个策略确保信息不会被无意的或是有意的处理进程降低级别。
在1976年的一份论文中，Harrison,Ruzzo和Ullman提出了一个安全观点，传统的访问矩阵有着固有的安全不可判定性。换句话说，拥有一些安全需求被认为是安全的结构是不是依然保持安全特性，这是无法判定的。如果一个系统始于一套对客体的访问权限集合，我们不可能知道系统是后来的授权是不是在原访问矩阵之内。尽管这项结果的证明有点技术性，而不可判定性的根本的原因在于用户能授予其他用户相关权限。如果系统不能控制权限从一个用户传递到另一个用户，那么通过一系列的权限传递后，我们就没有办法去判定一个未经授权的用户是否不正当地得到了权限。
1.2.2 国防部标准
在1983年，美国国防部发表了《可性计算机系统评价标准》（TCSEC），就是熟知的“橙皮书”，标准化了访问控制模型，使它向前迈进了有重要意义的一步。这个标准为军事系统详细地定义了两个访问控制模型：自主访问控制（DAC）和强制访问控制（MAC）。就如名字提示的那样，DAC模型中，由文件创建者和拥有者来指派权限，对信息有自主访问控制的主体能将该信息传递给另一个主体。
DAC想实现军用的文件分级方案只靠自身是不够的。因为在DAC安全模型中用户能把访问客体的权限进行传递，Harrison,Ruzzo,Ullman的关于不可判定性的论证正好可以用DAC模型说明。为了提出能真正保证一个系统保持安全性的方案，MAC成为需要。
像通常实现一样，如1.2.1这部分的描述，MAC的多级安全策略由Bell-LaPadula模型来形式化。（第二章会详细地论述DAC和MAC策略。）正如它的名字所暗示的，MAC的关键特点是，系统中所有对客体的访问都受到访问控制策略的介入。由于访问控制强制用形式上规则介入所有对客体的访问操作，用户不能将客体的访问权限进行传递。那么用户的行为都被限制在一定范围内，所以不管用户如何进行操作，访问控制都能保证系统保持在安全状态。
1.2.3 Clark-Wilson 模型
鼓励发展安全操作系统和计算机安全产品的市场是TCSEC的目标之一。许多相关研究人员都解释说TCSEC较低级的需求组合都足够满足商业用途。都希望以TCSEC在商业安全和军事安全上的指导，可以建立起统一的安全产品市场。
尽管为解决商业安全问题，在发展TCSEC与需求相适应的系统方面人们做了很大的努力。大多数贸易公司认为DAC和MAC并不能满足他们的需求。以TCSEC为标准的系统都以信息流和信息的机密性作为最关键的方面。在广泛地参考了大量的论文后，1987年Clark和Wilson提出他们的观点，既然机密性对商业用户来说是重要的，那么系统首要关注的问题应该是完整性（也就是确保信息只能通过被授权用户用适当的方法来修改）。
当Clark与Wilson将传统的商业安全方案形式化为安全模型，出现了与由Bell和LaPadula形式化的军事安全模型完全不一样的结果。Clark-Wilson模型中的两个中心概念是良性事务和职责分散（SoD）。良性事务约束用户只能通过经审定的的方法修改数据。例如：一个银行出纳员不能修改一个消费者的任何一个记录，除了与特殊的事务联系在一起的数据区域，如存款和取款。补充上良性事务是SoD的一个古老的原则，它能确保数据修改的一致性。例如：一个公司经理可能会申请一笔支出，但是必须通过另一个人的批准，而且由第三方人员审计完整会计事项，以确保不会出现欺诈行为。随后发现，在计算机系统上实现这些规则与实现信息流策略有同样的挑战性。RBAC的动机之一是为了使商业安全策略易于执行。
1.2.4 RBAC的起源
像Bell与LaPadula形式化的多级安全策略一样，RBAC来源于比正式模型早的历史实践，只不过RBAC的重要特性起源于商界。同样与多级安全策略一样，RBAC有着简单的概念：基于用户在组织中角色来控制用户访问计算机系统中的客体。在商业组织中，拥有不同权限和职责的角色早就被人注意到，至少从七十年代就有商业计算机应用软件实现基于用户在组织中的角色约束其访问能力。例如：在那时，在线银行事务软件包括出纳员和出纳监督员，他们可以执行不同的固定的一套事务，而在同时使用自动出纳机的用户能够执行另一套事务，而基于同一个数据库。
在八十年代末九十年代初，研究人员开始意识到角色的优点，它是从应用软件和数据库管理系统中提取出来的管理权限。角色可以看作是一个组织中的位置或是职位。角色是一个独立的结构，它不同于用户，而用户则可以被指派角色。 Dobson和McDermid用功能角色这个术语。Baldwin称这些结构为指定保护域（NPDs），而且NPD的子集能联系组合在一起形成层次结构。可以注意到，角色也支持最小特权原则，其中角色由完成任务的需要的最小权限组合而成。Brewer和Nash模型提出了一个基本的理论，用于有力地执行访问权限的变化。该模型用详细的商业安全策略术语说明，就是有名的“中国墙”。模型首先解释了中国墙的意思，然后定义了一组规则（SoD所需求的），即是用户不能从墙的错误的那一边访问数据。Nash和Poland论述了基于角色的安全应用，它作为密码鉴定装置在银行业中使用普遍。
这些基于角色的系统相对较简单而且是面向特定应用的。就是说没有一个多方面的模型来确定怎样去定义基于角色的访问控制，对于这些安全系统的正式分析也非常的少。这些系统由各种各样的组织创建，但是没有一个一致的定义，也没有一个公认的正式的标准。
在1992年，NIST对商业和政府组织开始研究，发现在当时市场没并没有一个满足访问控制需求的产品，很多产品都只是实现了TCSEC类型的自主控制，这在当时被很多组织认识为是理所当然的标准。在很多工业企业和政府单位，最终用户并不“拥有”DAC规定有权访问的信息。在这些机构中，法人和中介才真正是系统客体的“拥有者”，在用户方面自主控制并不适当。注重保证机密性的常规MAC对这些机构来说也是不适当的。虽然在信息分类系统中强制执行“需要知道”策略是很重要的，而仍存在对基于主体的安全策略的普通需求，例如：基于资格的访问，强制执行的利益冲突规则，或是基于精确的最小特权的访问。支持这些些策略需要相关能力，即能基于用户在企业中的职责和角色进行访问约束。
在1992年，Ferraiolo和Kuhn提出了满足这些需要的解决方案，他们将现有的面向特定应用的方案的特点融合在一起，成为一个广义的RBAC模型。论文用一种简单而正式的方式进行描述，集合，关系，映射用于界定角色和作用层次结构，主体角色的激活作用，并主客调解，以及限制用户的角色成员和角色设置激活。三个基本的规则如下：
1．角色指派：一个主体只有在选择或者被指派了一个角色时才能执行一项事务处理。鉴定程序（例如：登录系统）不被认为是一项事务。所有其他的在系统上的用户的行为都通过事务来引导管理。因此，所有的使用中的用户都需要有效角色。
2．角色授权：一个主体的有效角色必须被授予相应的权限。由规则1，这条规则确保用户只具有被授权的角色。
3．事务授权：一个主体只能在它的有效角色已经被授权时才能执行一项事务。联合规则1和规则2，这条规则确保一个用户只能执行被授权的事务。
关于该模型的形式上的描述如图1.2所示。这个模型的一个关键的特性在于，所有的访问都是通过角色来进行的。从本质上来说，一个角色就是若干权限的一个集合，所有的用户都只能通过角色得到权限，而角色则是如图1.3所示，通过指派得到。在一个机构中角色相对来说是稳定的，而用户和权限都非常多，而且可能会变化得很快。因此，通过角色来控制访问简化了管理和访问控制检查。
在计算机系统中，大多数都是通过访问控制表（ACLs）这个普通的方法来实现访问控制。所有的系统资源，如文件、打印机和终端，都有一张与授权用户相联系的表。这种方式可以简单而快捷地回应每个客体访问的问题：“什么用户有权访问客体X？”而复杂的是主体访问问题：“主体X能访问哪些客体？”回答这个问题需要搜索计算机系统中所有的客体，而客体的数量可能有百万之多；记录它们的访问控制列表；最后报告用户X能访问哪些客体。在真实系统上进行的实验测量显示，这个过程需要的时间可能会超过一天。这个方案还有个副作用，ACLs使在客体访问表中的增加权限很简单，而想撤回所有用户的相关权限却非常困难。在很多系统中，用户被分配成一些组，然后当作ACLs中的项目来使用。
| RBAC的形式原始描述 |
| 对于每个主体，有效角色即是主体正在使用的角色： AR(s:主体)={主体s 的有效角色} |
| 每个主体可能被授权执行一个或多个角色的任务： RA(s:主体)={主体s 的授权角色} |
| 每个角色可能被授权处理一个或多个事务： TA(r:角色)={授权给角色r 的事务} |
| 主体可以执行事务。当且仅当exec(s,t)为真的时，主体s能在当时时刻执行事务t；否则为假：exec(s:subject,t:tran)={为真当且仅当主体s能执行事务t}
2．角色授权：一个主体的有效角色必须被授予相应的权限：
3．事务授权: 一个主体只能在它的有效角色已经被授权时才能执行一项事务：
|
| 注意，因为规则3的条件是“仅当”，这条规则考虑到事务处理额外约束的可能性。也就是说，规则不会仅仅应为事务属于TA[AR(s)]就保证事务为可执行的。事务的潜在可执行性是由主体的有效角色来决定的。例如：一个管理角色的新手可能会被授予管理角色，但是他或她的管理角色与正常的管理角色相比，可能有某些约束。 |
图 1.2 Ferraiolo和Kuhn的关于RBAC的形式描述
图 1.3 RBAC 中的关联
熟悉传统的分组机制的读者会发现RBAC和分组机制在表面上是类似的。由通常的实现方式，一个分组是用户的集合，而不是权限的集合，而且权限可以由所属用户和分组来联合，就如图1.4表示的那样。因为用户可能基于他们的用户身份或者分组身份来访问客体，那么用户可能依然拥有相关权限，即使该项权限在分组权限被移除时就应当被回收。基于个人用户身份识别的权限分配方案在强制安全策略中对漏洞起到了作用。 RBAC的需求——所有的访问都是通过角色完成——在真实应用中消除了这个漏洞，很大程度上加强了系统安全性。Ferraiolo-Kuln模型的另一个重要特性为角色是分等级的——角色能从其它角色继承权限（图1.5）——而分组则通常被认识是同级的用户的集合。虽然约束的种类没有详细的规定，而在模型中角色成员资格的约束是有规定的。
图 1.4 分组访问控制的联系
图 1.5 角色功能层次举例
这份1992年的论文指出该模型包含了Clark-Wilson模型（也就是说Clark-Wilson模型是当中的一个特例）。后来NIST的发表了一份对RBAC更加详细的研究，提出了一些1992年的模型中没有的额外的功能，而且包括为了实现职责分离需求的具体形式的制约因素。
George Mason大学的教授Ravi Sandhu,一位著名的有影响力的安全专家，形容Ferraiolo-Kuhn的RBAC安全模型为“一项重大的创新，它使RBAC模型成为一项应用程序服务……不是散射安全应用程序代码，RBAC在一个统一的服务标准上巩固安全，更有适应性的和单独应用程序的专用化能力，使系统更加容易管理”。Sandhu博士继续进行广泛的研究，在RBAC领域发表了许多论文。他的几个学生也加入了他的这项研究中，并创作出与RBAC领域有关的一些博士论文。
在1994年，Nyanchama和Osborn提出了一个非常普遍的角色组织结构，并称之为角色图模型。作者表明，角色可以基于三个角色关系来组织：部分，共享和扩大特权。角色图模型在分析特权共享方面有显著的作用，这在检测和预防角色之间的利益冲突方面很关键。Gligor介绍了“角色类型”的概念，在产生角色实例时用参数化的类型可以简化角色管理。这项成果成为RBAC领域中美国的首个专利。
在1996年，Sandhu和同事提出了RBAC模型的一个框架，RBAC96，将RBAC分成四个概念模型。如图1.6所示，这个框架详细说明了一个基础模型，RBAC0，它包含一个实现RBAC系统的最起码的特性。两个经过发展的模型，RBAC1和RBAC2，包括RBAC0，添加（分别）
支持层次结构和如SoD一样的制约因素。第四个部分，RBAC3，包括了级别较低的模型的所有方面。Sandhu等人的RBAC96框架为RBAC系统制定了一个模块结构，简化了拥有基本RBAC0功能，或依客户所要求拥有更先进功能的商业实现。
图 1.6 Sandhu 等人的 RBAC96 框架
主要因为NIST的Sandhu和David Ferraiolo教授所创立的计算机协会（ACM）发起的一系列讨论会，一个健全的RBAC研究团体建立起来了，而且在当今的商业实现上创造出了比以往任何时候都更为复杂的RBAC系统。RBAC开始出现在更广泛的应用领域。Barkley早期成果表明，RBAC应用天生安全。工作流管理，一个重要的经济领域，它处理商业程序的自动化操作，在这个领域RBAC似乎是非常的合适，不仅提供安全保障，而且还可以作为工作流的框架。Barkley,Cincotta,Bertino,Ferrari及Atluri介绍了基于RBAC的工作流系统。
在2000年，NIST开始努力建立一个国际公认的RBAC标准，在RBAC研讨会中提出了这个提案。拟议的标准遵循RBAC96结构，具体详细的特性由后续讨论和研究团体及商业团体提出的评论来制定。在2002年，拟议的标准在提交到国际标准的过程中，而商业公司已经开始生产符合RBAC标准的的产品。
关于RBAC的历史，最引人注目的是它从一个概念速度地发展成为商业实现和和部署。显然它的成功可以归因于多种因素，但要注意到到RBAC的双重策略和生产力优势无疑也为它当前地位作出了贡献。在此方面，RBAC不同于许多其它安全概念，因为其部署的费用是毫无道理的，安全仅仅基于危胁和系统的漏洞。虽然RBAC允许执行许多各种各样的重要的访问控制策略，即使它们是不切实际的，甚至是无法执行的，RBAC的生产力优势作为单独的理由来证明部署是正确的。当两者合在一起时，这些双重刺激可以产生强大的商业理由。为了提高健康保护系统的效率，1996年的美国健康保险流通与责任法案（HIPAA）明确地要求了RBAC的必要条件，而且美国联邦航空引用RBAC为国家空域系统的安全规范。现在RBAC几乎都被认为是广义的访问控制。例如：RBAC被认为是“在多终端数字政府结构中提供安全功能的最有吸引力的解决方案”，并且在基于网络的应用程序复杂的安全需求上显示出它强大的适应性。
在经济方面可以直接证明RBAC是非常出色的，而在过去的十年也发生了一些别的事情。在这个时期中，数百篇围绕RBAC这个主题的论文被发表。正如我们已经论述过的，RBAC是一个包含着紧密依存的访问控制策略和管理功能及思想的结合体。虽然RBAC的重点无疑是访问控制，但在许多方面，RBAC可视为一种调控和管理用户行为的模型，以及IT环境的自由活跃性。而且这些活动都已经装入高度直观的角色结构中，自然地出现在大部分商业环境中。事实证明，角色结构不仅应用于资源配置系统和访问控制及策略管理系统，它们还自然融入工作流、进程管理、协作和虚拟企业环境。当RBAC模型首次出现的时候，这些企业应用程序没有想到会使用RBAC。但是，一经发表和彻底地调查，其他研究人员迅速开始扩展和详细说明RBAC的概念及结构。
在当今IT基础设施中，普遍存在的RBAC应用是有重要意义的。今天，RBAC的功能包含在各个级别的企业事务处理中，包括操作系统、数据库管理系统、网络和企业管理层次。RBAC被纳入整合到基础技术中，如公共密钥基础结构（PKI），工作流管理系统和目录及网络服务。此外，RBAC正被拟议作为在协作和虚拟企业系统中定制元策略的一项有利的技术。
1.3 RBAC与DAC及MAC之间的比较
RBAC的行动原则是能够指定和实施企业具体的访问控制策略，精简以繁琐为特色的授权管理过程。从现有的DAC与MAC标准来看，RBAC表现的主要是灵活性方面的进步及细节的控制。
如可信计算机系统评价标准（TCSEC）的定义及普遍实现的那样，DAC是一个访问控制策略和机制，它同意系统用户可以决定允许或不允许其他用户访问在该用户控制下的客体。TCSEC定义的DAC策略如下：
基于主体或集合，或同时基于两者的所属的身份来约束对客体的访问。自主控制意思是一个拥有某个访问权限的主体能够将该权限传递（可能是间接地）给任何另一个主体（除非受到MAC的限制）。
自主访问控制(DAC)，顾名思义，允许访问权限的授予和撤回由个人用户来决定。一个DAC机制允许用户能够授予或撤回在他们控制下的任何客体的权限，再不需要一个系统管理员的介入调解。
在很多工业企业和政府单位，最终用户并不“拥有”DAC规定有权访问的信息。在这些机构中，法人和中介才真正是系统客体的“拥有者”，那么允许用户传递客体的访问权限是不适当的。对于RBAC，访问的决定权是基于用户在组织中的角色的。这包括任务的详细说明、职责和资格。例如：个人之与医院的角色可以设定包括医生、护士、临床医生和药剂师。在银行的角色包括出纳员、信贷员和会计师。角色同样可以应用于军事系统，例如：目标分析家、位置分析家和交通分析家都是战术系统中普遍的角色。一个RBAC策略是基于职责和行为的，某组织中的一个用户只能在允许的范围内执行操作（称其为特权或权限）。用户通常不能根据他们的决定来传递他们的权限。例如：一个拥有开药的医生没有权限将他的权限传递给一个临床医生。
安全策略往往要支持更高级别的结构，例如：维护和执行法庭上的道德规范，对疾病的诊断与治疗方面尊重隐私，遵守规则，在一家医院中对药物治疗进行管理。为了支持这些策略，就需要集中控制和维护访问权限。策略要求安全管理员，而非用户，必须认真地代表组织进行组织资源访问策略的指定。
同样地，RBAC有时被描述为强制访问（MAC）的一种形式，因为用户不可避免地被限制，而且在执行组织保护策略方面没有任何影响力。但是RBAC不同于可信计算机系统评价标准（TCSEC）规定的强制访问控制（MAC）。MAC在TCSEC中的定义如下：
基于客体包含的信息的敏感性（用一个标识来表示）和主体对于该敏感性的信息的正式授权（也就是主体的安全级）是对客体访问进行约束的一种方法。
作为合理的可信计算机系统评价标准，MAC满足国防部的需求，支持对机密信息未授权访问的相适应的规则，特别是支持保护敏感信息的机密性（阅读或观察）。支持MAC策略的系统都非常注意信息非法由低级流向高级。同样地，策略支持读写控制。但是，对写操作的控制只涉及防止间接非法对敏感信息的获取，而不涉及它的完整性（未经授权的修改或删除）。
关于RBAC的控制，策略可能会涉及到机密性或完整性的问题，或同时考虑：“谁能执行什么样的行动？”
为了区别RBAC和MAC的策略细节，RBAC往往定性为不可任意支配的访问控制。RBAC允许不可任意支配地执行多种保护策略，可定制为一种企业对企业的依据。在单机或分布式系统中执行的策略是各种不同的RBAC结构的管理配置的最终结果。
1.4 RBAC模型和企业
RBAC相对MAC和DAC已经成为首选方案，因为比早期的模型，它更加适合商业客户的需要。本节介绍了一个简单的经济模型，表明RBAC的成本效益，然后讨论了RBAC如何适合一个庞大的组织。
1.4.1 RBAC中的经济学
从商业角度来看，RBAC有潜力提供多种好处。这包括提高执行普通的授权管理的效率。这些管理功能涉及到为新用户对资源的访问进行权限分配（新用户和新资源），根据用户工作任务的变化来审查和撤销一些不再必要的（有潜在危险性）访问权限，一旦用户离开企业就彻底而迅速地撤销其权限。这些相同的功能已经证明通过减少管理事件过程中的停工时间可以提高用户工作效率，在停工时间内用户不能访问系统资源，那么企业在这段时间内就没有生产力。为了执行一个访问控制策略，通常应该掌握好管理成本和部门数量之间的直接关系：部门数量越多，访问控制管理的成本就越高，就更容易出错。在多数机构中，RBAC的应用减少了必须维持的部门的数量。
可以用一个简单的经济模型来估算一个基于角色的方案所能节省的成本。通常一个职业上有多个人，而且许多职位需要多个权限，以用来使这个工作职位上的人能完成其职责。可以用一个有序对来描述授权和个人之间的联系，有序对由一系列权限和一系列个人用户组成，用（U，P）表示，其中：
U=在一个工作职位的个人的集合；
P=完成该职位的工作所需要的权限的集合。
所需要的个人和权限的直接联系数量是：|U|·|P|，其中
|U|=集合U中个体的数量；
|P|=集合P中权限的数量。
换句话说，对于在U中的每个个体，每个在P中的权限都与之相联系。
一个角色可以描述为一系列权限的集合。那么，集合P即可作为一个角色，或者一个职位，而这个职位的用户—角色和角色—权限关联用有序对（U，P）来表示。用户—角色和角色—权限关联需要对集合U中每个用户分配集合P中所有的权限，用P表示角色为|U|+|P|（也就是，角色P与集合U中每个个体关联，且与集合P中的每个权限相关联）。
对于一个职位，如果|U|+|P|<|U|·|P|，那么将用户直接和权限关联起来就是RBAC的管理优点。|U|+|P|<|U|·|P|的一个充分条件是|U|，|P|>2，这是在许多组织中许多职位的通常情况。如果n是一个机构中职位数量，那么当
时，RBAC表现出管理优点。（要注意到，这只是一个近似值，因为在一个机构中用户可能常常会有多个角色，而且角色可能会有分层关联。）
除了由于提高管理效率和用户工作效率所节省的成本外，RBAC能避免由于将来安全或隐私策略的破坏而带来的费用。因为RBAC能自然地描绘出组织和企业结构，它比传统的基于身份的访问控制机制有更好可配置性，它能从它所控制的系统和应用中抽象出来，RBAC可以执行更多数量和类型的访问控制策略。根据RBAC所部署的类型，这些策略可以包括最小特权的实现（历史悠久的特权分配管理习惯，用户只被分配了完成任务的最低限度的特权）和职责分离的实现（从而避免可能导致的利益冲突）。通过分配给用户访问更多资源的权限，还有对客户或合作伙伴时——在有必要的时候——有更好的管理权限，RBAC提高了用户的工作效率。
1.4.2 授权管理和资源配置
在最低水平上，管理员通过一个系统到一个系统的原则来创建和维护访问控制列表（ACLs），从而控制用户的访问权限。ACLs为每个受保护的资源指定了一个列表，列表包括个体用户或是由个体用户组成的分组各自对该客体的访问模式（例如：读或写）。ACLs的这种用法从很多原因上可以证明是很有问题的。ACLs依赖特定的资源。ACLs使问题变得更加复杂，因为它是由一个系统到一个系统的原则来执行。大量的用户，每个用户都有许多特权，意味着大量的用户—特权关联，它们遍布大量的独立管理平台和应用程序中。因此，当一个用户在企业中从事一个不同职责时，执行这些改变必需彻底的审查，从而导致用户特权的添加和删除，这通常出现在许多系统中。通常纳入到RBAC中的授权管理和资源配置工具被开发用来帮助管理员处理这些挑战。
在多个平台上管理用户、资源和特权的安全管理员必须在很多不同的系统上执行相似的任务。因为每个系统都有它自己特有的管理界面，甚至日常任务都需要安全管理员对每个类型的安全系统有详细的知识。他们在完成每个本地任务时都要花费宝贵的时间在不同的安全系统上登录和注销。
随着组织的发展，用户常常需要访问越来越多的系统，包括一个或多个应用程序，用户用它们每天进行交互电子邮件服务器、用于临时事务处理的系统，如记录差旅费或管理退休帐目，或者打印服务器、网站和需要授权的其他系统。所有的这些系统都需要某种形式的身份验证及访问控制，而且它们可能不依赖其它系统而独自更新改变，使用户难以在所有系统中保持他们密码的一致性。一些组织可能明确地要求用户在不同的系统中不能使用相同的密码，特别是在一些敏感性不同的系统中。在多系统中管理身份验证和访问控制是授权管理的关键问题。
维持用户ID、角色成员、权限和角色与权限的关联都是授权管理的任务。在大多数情况下，随着组织增加和减少员工，以及组织中的职位和权限的变化，系统管理员每天都必须处理这些问题。因而对于大量应用的权限管理不只是用户的一个问题；它代表着一个对企业系统管理员的巨大挑战。
虽然对于这个挑战有许多授权管理解决方案，它们都提供了一个方法，将授权信息存储在一个服务器上。一般来说，有两个常见的方法来处理权限集中的问题，如图1.7和图1.8所示。
第一种方法，被专业术语称为用户拉，用户被授权服务器验证，获得某种形式的凭据来访问应用程序。第二种方法，术语称之为服务器拉，需要应用程序验证用户，但是将用户的特权信息集中到一个授权服务器上。当用户试图调用一个应用程序，该应用程序查询授权服务器来决定该用户是否有相关权限。
图 1.7 用户拉授权结构
图 1.8 服务器拉授权结构
在用户开始能访问应用程序以完成他们的任务之前，组织必须在整个网络上设置好他们的访问权限。这就是资源配置问题。除了数千雇员，公司可能需要为承包商、业务合作伙伴和通过网络访问公共信息的客户设置权限。同样重要的任务是当雇员离开公司时撤销其权限。通过对企业的调查发现，当前的和以往的雇员是破坏安全性的两个主要来源。以前的雇员被认为与当前雇员一样常常产生安全问题，因为当雇员离开时删除权限的这个问题。在一个快速变化的商业环境中建立和维持适当的访问权限是一个复杂的问题，这导致要装备先进的设备，常常要花费$600,000到$800,000不等。资源配置常常要根据用户的职位来结合计算机系统、企业人力资源、信息系统、和广泛收集的其他部门的信息来共同确定。如果“Bob Smith”被雇用了，必须授予他在工作过程所需访问的所有资源的访问权限。对于传统的常规的访问控制系统，这意味着要将他的用户ID指派给他要访问的每个资源。将用户和权限直接联系起来不仅仅耗时；而由于用户任务分配的改变，它常常会导致错误，致使用户拥有他们本不该拥有的权限。
RBAC不允许用户和权限直接相联系。对于RBAC，权限被授予给角色，而角色被授予给用户。授予给一个角色的权限可能跨越若干个平台和应用程序。因此，当管理RBAC的时候，必须得管理两个不同类型的组合关系（也就是用户和角色间的组合关系和角色和权限间的结合关系）。当一个用户的职位变动时，只是用户—角色组合关系需要改变。如果一个工作职位只由一个单一的角色来表示，那么当一个用户的工作职业改变时，只需要改变两个用户—角色的组关系：为了实现这些变化，只需要移除用户与用户当前的角色间的组合关系再添加上用户与用户新角色间的组合关系。由组织层次结构和制约因素引起的复杂性，例如：职责分离的相关需求被访问控制软件隐藏。就是这个概念简单的方法赋予RBAC强大的功能和灵活性。
2957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
