DRBAC动态结盟环境下的分布式的基于角色的访问控制机制.docx
《DRBAC动态结盟环境下的分布式的基于角色的访问控制机制.docx》由会员分享，可在线阅读，更多相关《DRBAC动态结盟环境下的分布式的基于角色的访问控制机制.docx（28页珍藏版）》请在冰豆网上搜索。
DRBAC动态结盟环境下的分布式的基于角色的访问控制机制
DRBAC：
动态结盟环境下的分布式的基于角色的访问控制
摘要：
对跨越多个管理域的系统而言，分布式的基于角色的访问控制（dRBAC）是一个可伸缩的、分散的信任管理和访问控制机制。
dRBAC描述了依据角色的受控行为，角色在一个实体的信任域内定义并且可以将这个角色传递地委托给不同信任域内的其他角色。
dRBAC利用PKI来鉴别所有执行信任敏感操作的实体和验证委托证书的有效性。
从角色到授权的名字空间的映射避免了需要识别额外的策略根（additionalpolicyroots）。
dRBAC区别于以前的信任管理和RBAC方法就在于它支持3个特性：
（1）第三方委托（third-partydelegations）一个实体如果被授权了指派委托（delegationofassignment）后，就可以委托它的名字空间以外的角色，从而增强了表现力。
（2）值属性（valuedattributes）通过分配和处理与角色有关的数值的机制来调整传递的访问权限。
（3）证书预订（credentialsubscription）用pub/sub基础设施来跟踪可被回收的委托的状态，从而对建立的信任关系进行持续监控。
本文介绍了dRBAC模型，使用基于图的指派发现和确认模型来实现它，以及在更大安全范围的应用。
1简介
dRBAC是由在结盟环境下对资源的访问控制这个问题引出的。
“结盟环境”可以是军事上几个国家一起工作达到一个共同的目标，或者商业上几个公司合伙。
结盟环境定义的特点是存在多个组织或多个实体没有共同的可信的授权中心。
在这种情况下，实体必须协作来共享对结盟来说必要的受保护的部分资源，同时保护它们不想共享的资源。
Internet上网络服务的增长使这样的需求很普遍。
例如，可以想象这样一种情况，在用户的组织和管理网络的实体之间结盟的基础上，移动用户就可以在旅馆或机场使用网络工具连接到Internet，一收到用户的请求，网关就可以确定用户所在的组织与网关所在的网络之间是否存在信任关系，如果存在，不管用户和网络之间是不可知的还是暂时的关系，都可以在特定级别上访问。
尽管如此，但在结盟环境下建立信任关系还是有一些困难：
·结盟的成员必须安全地对其他每个成员来证明自己的身份，这可能要通过不安全的网络连接来传输信息。
结盟的成员可能不知道彼此之间的身份，这就需要它们提供额外的证据来证明它们的可信赖性。
·实现和保持组织的自然结构的访问控制系统对大组织机构的结盟是很有好处的，就可以授权给一个用户在组织内他所执行的“角色”。
·高度动态结盟环境应该支持授权的传递委托。
资源的拥有者不仅可以指出谁可以访问该资源，还可以确定谁可以进一步委托授权给其他的用户。
应该采取一种方式将资源的拥有者和可以进一步委托该资源的实体之间的数目进行协调控制。
很显然，传递地对用户授权进行委托可能分布在很多不同的网络主机上，最好能自动收集和显示这些指派。
·应该持续监控建立的信任关系来跟踪可被回收委托的状态。
这对延长用户对某些安全资源访问的情况是很重要的。
遗憾的是，现有的解决方案并没有很好的解决这些问题。
简单的访问控制列表引起管理上的困难，不能很好的扩展到大的系统，并且不允许授权的传递委托。
传统的RBAC系统依赖于一个集中的可信的处理中心，这个中心被一个具有组织内所有的安全策略的授权中心管理。
RBAC系统简化管理：
当用户被加到一个组时，他就立即拥有该组的权限。
然而，这种方法对于结盟环境下一个用户碰到很多不知道的其他用户的情况下就不适用了。
最近，开发基于信任的系统（如SDSI/SPKI[17,7],Keynote[2,3]）来控制访问，控制资源的应用程序使用公钥密码签名的方法来鉴别请求访问的用户，该方法具有分散管理、可扩展和可鉴别不安全网络中的个体等优势。
但是，大部分基于信任的系统并不提供映射到组织的自然结构的委托语言，也没有提出对证书状态的改变而对建立的信任关系进行持续监控的问题。
我们的dRBAC方法，结合了RBAC和信任管理系统的优点，是既管理灵活又可分散地，可扩展的实现的系统。
dRBAC表示依据角色的受控行为，角色在一个实体的信任域内定义并且可以将这个角色传递地委托给不同信任域内的其他角色。
dRBAC利用PKI来鉴别所有与信任敏感操作有关的实体以及确认委托证书。
从角色到授权的名字空间的映射避免了确认额外的策略根源的需要。
本文介绍了dRBAC的主要部分：
授权行为的模型和支持分配、发现、确认、监控证书链的可伸缩的结构。
dRBAC受其他的提议的信任管理系统设计的影响，它的算法就是采用了最有名的RT0[13]的指派链的发现的思想。
但是，dRBAC区别于以前的方法在于它支持3个新的特性：
·第三方委托即允许一个授权的实体可以委托其他实体所创建的角色，而只要通过直接指向该角色的创建者的名字空间，与后面讲的Li的委托逻辑的“代表说话”关系有关，这个机制允许简单的管理模型，即系统中有权限的实体可以创建角色并且可以让其他的权限少的实体分发这些角色，就象在第三部分指出的。
更为重要的是，第三方指派实际上增加了dRBAC的能力，这是以低成本获得的：
第三方委托除签名的委托外不需要说明额外的基础设施或系统安全策略的规范说明。
·值属性通过数值来获得不同级别的访问权。
数值属性，就像角色一样，由一个给定实体创建，并定义在该实体的名字空间里。
与第三方委托一起，值属性通过发布委托来指定，并不需要额外的策略。
·证书预订用pub/sub结构对建立的信任关系进行持续监控来跟踪可回收证书的状态。
这个特性允许dRBAC结构支持在调整时间建立信任，dRBAC系统根据委托的状态对客户端应用程序进行更新，这样就以更有效的方式来促进回收消息的传播，而不需要不断的轮询。
dRBAC的这3个特性可以构造一个强大的信任管理与访问控制系统。
与其他的信任管理系统一样，使访问机制与策略分离，不需要全局的可信的“认证授权中心”。
每个对受保护资源负责的授权机构可以在分布式系统中定义它们自己与其他实体的信任关系。
对受限制资源的访问权限完全由委托证书的发布者指定，委托是描述合伙人之间的信任关系，提供自动发现信任关系的委托链的机制。
最后，提供监控在一个事务的持续时间内信任关系的状态的机制。
为了便于理解这些特性带来的好处，看一下下面这个例子。
假设这样一个问题：
动态将视频数据分发给一个军事联盟，包括3个国家：
美国、英国和澳大利亚。
假设美国方面捕获到一些视频信息，并想把它不仅传给美国军队，而且传给参加军事演习的英国和澳大利亚军队。
假设这些军队通过不安全的网络连接，通过那些对拥有视频资源的主机来说不可知的计算机连接到视频资源。
另外，美国想要调整数据的发送，比如，美国军官收到比其他国家的军官更高的图象分辨率。
使用dRBAC，所有这些要求都可以通过以一种直接向前的方式发布委托来实现。
有视频信息的主机可能指定美国将军既可以观察视频信息又可以将这个权力委托给其他人。
美国将军就可以发布委托定义英国和澳大利亚军队可以观看视频信息。
这些dRBAC第三方指派所支持的委托避免了与“美国将军”角色有关的名字空间内的冲突。
dRBAC对值属性的支持可以通过发布给不同国家的委托和不同的分辨率设置来获得期望的等级。
最后，对证书预订的支持允许在演习结束时（比如对非美国军队的委托的改变）通知分发应用程序，使它能及时取消不允许的用户的访问。
dRBAC系统是我们研究小组正在开发一个叫做DisCo的大型安全基础设施的一个组成部分。
DisCo可在部分信任环境下动态配置可分解的服务，这依赖于dRBAC互相之间的认证和基于客户机服务器指派的认证。
DisCo也包含一个称作是接线总机（Switchboard）的新的抽象概念，Switchboard提供的应用程序可以创建信任的安全的连接，这可能在完全安全环境下才这样要求，DisCo的全部结构和Switchboard部分在别的部分详细介绍。
本文的剩下部分是这样组织的：
第三部分讨论委托授权的基本dRBAC模型以及支持调整访问权和证书生命期的控制的扩展；第四部分介绍支持分配、发现、确认、持续监控证书链的结构；第五部分包括dRBAC在一个更大安全范围内的一个实用例子；最后，介绍相关的工作，并讨论进一步实现和设计的目标。
2DRBAC纵览（Overview）
基本上，dRBAC通过确定请求的用户是否被授予对安全资源访问所需的角色来控制对安全资源的访问。
dRBAC试图回答的主要问题是：
“主体（principal）P拥有角色R吗？
”
dRBAC使用下面定义的“积木块（buildingblocks）”来回答这个问题：
证书（Credentials）我们可以将一个用户和该用户被授予的角色的关系看作为一个证书。
如果一个用户能使用一个给定的角色，他应该有一个证书来证明他有权这样做。
这个术语不是很正式，当我们讨论实现证书的具体的软件对象时，我们称之为委托。
证书链（CredentialChains）证书可以以传递的形式在主体（principal）之间传递。
一个拥有角色R的用户U可以进一步将角色R委托给其他人，这取决于将R授予给U的证书的创建者指定的限制。
角色在主体（principal）之间的传递称作为证书链。
支持链（SupportingChains）在dRBAC中，用户U可能委托他自己并没有定义的角色R。
在这种情况下，U必须提供证据来证明他有权委托R。
这个证据会采取以R的创建者为根的证书链的形式，就称作为支持链。
证据（Proofs）回答“主体（principal）P拥有角色R吗？
”这个问题所需的证书链和支持链的全部集合就称作证据。
图1表示主体（principal）A拥有B所创建的角色Role.2。
如果这样的证据存在，就记作：
A＝〉B.Role2.
子证据（Sub-Proofs）从个体委托中建立整个证据的过程中，子证据的概念就变得很重要了。
一个有效的证据是由一条或多条子证据构成的。
子证据就是与所有需要的支持链一起的主链中的委托的连续子集，因此，子证据提供在子证据主链中的第一个委托的主体和最后一个委托的对象之间的信任关系的所有证据（fullevidence）。
证据监控（ProofMonitor）一旦证据A=>B.Role2确定，有必要保证证据中的所有的证书在访问期间是有效的。
一个证据监控器提供这样的功能，这将在第四部分更加详细地介绍。
第三部分将通过dRBAC的委托语言的精确描述来形式化这些概念，第四部分将介绍一个可以用来在分布式环境下配置dRBAC的基础设施。
3dRBAC模型和理论
3.1委托的基本模型
表1给出了基本dRBAC委托模型的语法和使用的例子，我们现在详细介绍这个模型的部件。
3.1.1实体（Entities）
不像其他的信任管理系统，dRBAC并不严格区分系统保护的“资源”和访问这些资源的“主体（principals）”。
在dRBAC中，所有的都叫做“实体”，并且都是通过一对唯一的公/私钥对来表示。
不严格区分资源和主体（principals）的区别允许在指定委托关系时有更多的传递性。
特别地，在我们的系统内，所有的用户、主机和服务都用实体来表示。
所有的实体都映射为唯一的公/私钥对，以便它们能够被唯一地识别。
实体可以代表一组个体，也可以是一个个体，例如，“心脏病专家“和”史密斯医生“都是dRBAC实体，参看表1。
表1基本dRBAC委托模型的语法
3.1.2角色（Roles）
dRBAC的核心概念是角色，每一个想要执行一个受保护行为的用户都必须首先证明他能够以必要的角色行动。
角色是一个给定实体的名字空间内的名字，角色是一个给定实体的名字空间内的名字，角色用于对实体需要控制的一些事物进行命名，不管是像数据库这样的需要受保护的资源，还是象经理这样的一个组织里的有一组权利的职务。
3.1.3委托（Delegations）
角色通过委托授予给对象，委托的一般形式是：
[主体—>对象]发布者（[Subject－>Object]Issuer）
其中，主体（subject）可以是一个角色或者实体，对象（object）是一个角色，发布者（issuer）是一个实体，箭头可以读作是“拥有角色”。
“发布者”负责创建（或发布）委托，方括号内的关系由发布者签名。
dRBAC区别于其他很多系统的一个很重要的特性就是：
发布者不必是和对象实体（ObjectEntity）（对象角色（ObjectRole）定义在它的名字空间的实体）相同的实体。
dRBAC在委托使用时就要验证对象和发布者之间关系的有效性。
为了使主体可以使用委托中授予的角色，必须要证明发布者有权分发（giveaway）对象。
准予一个给定角色的能力称作为该角色的“指派权（rightofassignment）”。
通常，对象实体和发布者实际上是同一个实体，这种情况下的委托就称作是“自我证明（self-certifying）”。
因为任何人都可以分发（giveaway）任何他们自己名字空间内的任何角色，所以定义“自我证明”委托都是有效的。
所有的证书链都是以自我证明委托来结束的。
对象委托（ObjectDelegation）委托的对象是一个角色，这里的角色是一个实体的名字空间内的一个字符串属性。
有一点很重要的是，委托的对象必须是一个角色（从不可能是实体），一个实体不能将自己的身份委托给别人。
主体既可以是一个角色也可以是一个实体。
如果主体是角色，那么委托的形式就是：
这个委托的作用是将对象名字空间的角色映射到主体名字空间的角色。
因为任何实体都可以分发自己名字空间的角色，上述委托的主体就可以进一步指派授予给它的角色了。
如果主体是实体，那么委托的形式就是：
这个委托是将箭头右边的角色授予给箭头左边的实体。
在这种情况下，主体是一个实体而不是一个角色，对象角色并没有映射到主体的名字空间，因此，一般来说，该委托的主体不能再进一步委托。
（但是，下面介绍的“第三方委托”就可以通过指向对象的名字空间使得主体可以进一步委托角色。
）
指派委托（AssignmentDelegation）在指派委托时，一个实体授予某个主体委托一个角色，可以不将角色映射到这个主体的名字空间。
在dRBAC中，主体对对象的角色有指派的权力（rightofassignment）。
dRBAC句法中，在对象后面加一个（’）表示指派的权力，在下面的委托中：
[Subject—>Object’]Issuer
主体被授予了对象角色的指派的权力。
这就是说允许主体发布有效的委托，这个委托是通过指向对象的名字空间来分发（giveaway）对象角色（ObjectRole），而不是主体自己的名字空间。
第三方委托（Third-PartyDelegation）在dRBAC第三方委托中，发布者委托存在于其他用户名字空间里的角色。
这就必须要保证发布者有对对象指派的权力（rightofassignment）。
下面举例说明这个概念：
主体（Principal）A想要使用下面的委托来使用（employ）角色B.b。
（1）[A—>B.b]C
如果对象和发布者是同一个实体（B=C）,那么委托就是“自我证明”委托（“self-certifying”delegation）。
如果他们不是同一个实体，那么就必须证明C有权指派实体B的这个角色。
下面的委托，和
（1）一起将提供必要的证据（evidence）。
（2）[C—>B.b’]D
B.b后面的’表明C被授予了指派角色B.b的权力，现在C可以委托角色B.b给别的主体。
当然，这是一个递归的陈述（recursiveformulation），现在必须证明D有指派B.b的权力。
每一个这样的链都必须以自我证明委托来结束，自我证明就是对象和发布者是同一个实体，就像下面所示的：
（3）[D—>B.b’]B
将委托
（1）
（2）（3）综合起来就组成了一个有效的把角色B.b授予给实体A的委托链。
如果主体（principal）A想要使用角色B.b，那么它就提供3条证据：
（1）C说A拥有角色B.b；
（2）D说C有指派角色B.b的权力；（3）B说D有指派角色B.b的权力。
使用这种方式，每个实体就变成自己的认证中心（CA）。
自我证明的证书就避免了需要指定该相信哪个权威机构的任何外部策略。
第三方委托的好处
简化了委托和名字空间的管理（ClarityofDelegationsandNamespaceManagement）第三方委托的主要目的是简洁和表现力（clarityandexpressiveness）。
一个实体可以作为一个“角色的指派者”，而不仅是他们自己权力的委托者。
一个用户有权委托角色CameraA.view，就比将CameraA的view角色映射到他们自己的view角色更好些。
另外，第三方委托可以用来减少名字空间的冲突。
如果是同一个用户，比如Alice，想要指派角色CameraB.view，而她自己名字空间的view属性（attribute）已经被使用了，她就不需找一个新的角色名字来使用了。
在任何她写（write）的委托中，她都可以通过指向CameraB的名字空间来明确命名CameraB.view了。
当然，这需要与给Alice指派CameraB权力的发布者进行协调——他们需要使用第三方委托的模式。
然而，要注意的是，使用第三方委托，CameraB和Alice不需要在他们各自的名字空间里对view的含义取得一致意见，而如果使用的是对象指派的话就必须这样做。
功能差别（FunctionalDifference）另外，第三方委托能够创建一些对象指派中所没有的功能。
例如，第三方委托提供这样一种方式，就是将权能（capabilities）组装进角色里，然后将该角色的指派权力委托给其他的用户，从而就给这个用户委托任何或所有与这个角色有关的权能（capabilities）的权力（therebygivingtheusertherighttodelegateanyorallcapabilitiesthatareassociatedwiththeRole）。
这种方式对于一个角色可能包含大量的权能（capabilities）的系统是有很大价值的。
在这个例子中，一个美国将军有指派3个角色的能力：
现在，Bob不能进一步指派将军这个角色，因为将军这个角色没有映射到Bob的名字空间里，这正是所希望的。
然而，因为Bob是
，那么就应该有有效的委托链使得他有指派
，
和
的权力。
假设Bob想要将观看录相和驱动坦克的权力委托给士兵Joe，而没有发射导弹的权力。
他就可以发布下面的委托：
这不仅增加了系统中委托的数目（在主体有很多capabilities的实际系统中要增加很大的数目），而且也增加了为避免名字空间冲突而引起的协调的数目。
3.2基本指派模型的扩展（ExtensionstoBaseDelegationModel）
表2给出了基本dRBAC模型的扩展的句法和例子。
这些扩展包括值属性和证书管理信息。
我们下面详细介绍它们。
3.2.1值属性（ValuedAttributes）
通常，被信任的资源允许在不同的级别上访问。
dRBAC使用值属性的概念来支持对这样的资源的访问控制说明。
值属性可以被用来调节访问的级别或者授予一个授权用户的服务质量。
就象角色一样，值属性存在于一个给定实体的名字空间里，但是他们与实体角色的集合分开。
对某个角色的委托可能与一个或多个值属性有关。
只有设置对象角色的名字空间里定义的属性或者被对象角色继承的属性才有意义。
也象角色一样，委托值属性的权力也可以被指派给第三方。
例如，假设一个现场的视频资源
，一个
应该尽可能地实时收到数据。
可是，也有可能出于安全的考虑，需要推迟5个小时发送数据给美国信任的报道员（
）。
这可以通过引入下面的委托来完成。
注意扩展的委托的句法：
后面带有“＝”的对象角色有设置属性值的效果。
现在来考虑一下更复杂的问题：
照相机的视频资源可以有多个独立的参数。
例如：
延迟（delay）：
推迟多长时间
清晰度：
分辨率从0（模糊）到1（清晰）
有必要独立地调整这些参数。
为了达到这个目的，我们允许委托指定多个对象：
第三方委托也适用于这些角色，下面的委托就提供新闻部的成员低质量的视频服务：
最后，我们考虑一下角色值的累计问题（challengeofaccumulatedrolevalues）。
例如，一个外国新闻部的成员可能被授权接收同样的视频信息，那么
就应该允许增加一定的延迟。
表2：
dRBAC委托模型的扩展
为了能够这样，我们就引进了一种从多个委托中构造一个复合值的机制。
例如，下面的w委托就允许
对不喜欢的报道员的延迟值每次增加24小时。
第一个指派中的“＋”表示NSA有委托
的权力，并且有权指定它的值。
没有实体可以发布比他们自己更高级别的访问或更高质量服务的证书，这很重要。
在dRBAC中这是通过认真选择操作符和有效值的设定来实现的。
任何有上界和下界的有关的操作符都可以使用。
支持的操作符包括：
+：
对数值属性加一个正值，值越高就表明服务质量越低，基值（Basevalue）是0。
*：
对数值属性乘以一个0到1之间的正值。
这将界定可能取值的范围在0和1之间。
值越大就表明服务质量越高，基值是1。
<＝：
收集证明链中所有值的最小值，默认值是无穷大。
>＝：
收集证明链中所有值的最大值，默认值是0。
值属性委托类型（ValuedAttributeDelegationTypes）可以通过对象委托或第三方委托来传递进一步调节值属性的权力。
下面是一个使用对象委托的一般例子。
表明
拥有角色
，并且可以将值属性
设为基值的0.25倍。
下面是一个使用第三方委托的例子：
表明
拥有角色
，并且可以将
设为基值的0.5倍。
3.2.2证书管理
表2也显示了发现标记（DiscoveryTags）和截止日期（ExpirationDate）的句法。
发现标记在第四部分里介绍。
截止日期很简单：
委托可以包含一个严格的截止日期，过了这个时间证书就不再认为是有效的。
一个更灵活的控制证书生命期的机制是由dRBAC的证书预订提供的，证书预订对所建立的信任关系进行持续监控，这将在第四部分详细讨论。
4DRBAC：
支持的基础设施（SupportingInfrastructure）
4.1功能需求（FunctionalRequirements）
在分布式环境下配置dRBAC需要健壮的基础设施实现下列功能：
分配：
提供一种为新委托发布者发布这些委托的方法，以便其他实体都可以发现这些委托。
发现：
当出现“实体x拥有角色y吗？
”这个问题时，找到一组有效的从x到y的委托链，或者报告不存在这样的链。
有效性：
一旦确认了一个委托链，验证链中每一个委托的签名，并且检查终止日期。
监控：
不管任何原因，当委托被回收或变得无效时，通知任何一个可能在这些委托的有效性下有授权行为的用户。
这个功能是由dRBAC的知识库（repositories）提供的。
在分布式实现中，每一个参与的服务器都运行一个dRBAC知识库，在知识库里，用户可以发布委托，提交查询，用证书预订来订阅一条存在证据的状态。
因为大部分复杂性都是从发现证书链和监控存在的信任关系中引出的，这个部分就将着重讲述这些问题的解决办法。
有效性验证相对比较简单
升级会员 