Download presentation
Presentation is loading. Please wait.
1
应用背景 类似dRBAC SVE体系结构和基本组件
安全虚拟组织结盟的访问控制 应用背景 类似dRBAC SVE体系结构和基本组件
2
SVE结盟基础设施主要由下列组件组成 虚拟节点管理 安全策略管理 安全策略交换控制器 访问监控器 其中虚拟节点管理组件负责创建虚拟节点、批准其他节点加入和进行控制信息交换 安全策略管理组件负责创建节点内实施访问控制的安全策略 安全策略交换控制器组件负责在节点之间发布和交换安全策略 访问监控器组件负责共享资源的安全策略具体执行和实施
3
SVE结盟基础设施的体系结构和各个组件之间的关系如下图所示
4
例1,在节点B中,分别定义四种不同类型的访问规则
规则 1 主体角色 = engineer_d eweb.com = accountant_d 规则 2 客体类别 specifications_t = source_code_t = financials_t = 规则 3 授权规则 engineer_d = specifications_t, source_code_t 规则 4 访问约束 accountant_d = financials_t+TimeInterval!900!1600!M!F
5
从该实例可以看出: )角色 规则(2)中定义了需要保护的客体资源的安全类别,分别是文档资料(specifications_t)类、源代码(source_code_t )类和财务信息(financials _t )类 规则(3)和(4)均为授权规则,规则(3)为工程师角色授权,使得工程师角色可以访问文档资料类和源代码类的客体 规则(4)为会计师角色授权,使得会计师角色可以访问财务信息类的客体;在规则(4)中“TimeInterval!900!1600!M!F”为访问约束条件,其含义是会计师角色必须在从周一到周五的上午9:00至下午4:00的时间范围内,才能执行对财务信息类客体的访问
6
例2,现有节点A和节点B,节点A中主体Carle@eit
下面分析节点A和节点B建立SVE结盟环境实现安全共享访问的整个过程 (1)由节点B的管理员使用虚拟节点管理组件,创建SVE结盟环境。管理员使用安全策略管理组件,完成本节点内的安全策略创建和管理。
7
规则 1 A的主体识别规则 = programmer_d 规则 2 A的主体角色对B的客体类别的授权规则 programmer_d = specifications_t 的访问。节点B中的访问监控器截获该次访问请求,然后检查A的主体角色和A的主体角色在节点B中的授权规则,根据检查结果允许主体进行访问
8
(4)如果节点A中主体Carle@eit. com提出对B中源代码类资源https://eweb. com/source/index
(5)访问结束后,节点A退出该SVE结盟环境,节点B最后撤销该SVE结盟环境。则整个过程结束
9
SVE的安全性分析 SVE结盟基础设施基于分布式应用的中间件技术,设计和实现了一个跨域的安全互操作体系框架,能够对共享的安全对象实施安全策略的保护,并且支持节点对本地安全对象的自治管理。从安全的角度来分析,SVE结盟基础设施也存在一些问题 首先,每一个加入虚拟组织结盟环境的节点,都必须将本地制定的主体角色规则在整个SVE范围内进行发布,如同6.1节的角色映射技术(IRBAC2000)一样,它会存在外域角色层次的信息披露问题
10
其次,在一个节点内部,外节点的主体识别规则发布到本节点以后,本节点没有将外节点的主体角色映射到本地主体角色,而是另外授予外节点的主体角色对本地客体类别的访问权限。这与6.1节的角色映射技术是有区别的
角色映射技术通过建立外域角色到本地角色的关联,将外域角色当成了本地角色来对待,不需要为外域角色重新授权
11
参与SVE结盟环境的节点在两两节点之间都必须进行互相授权,不能提供授权的传递性。这与6.2节的dRBAC技术是不同的
dRBAC技术能够提供基于角色委托的授权链,可以在实体之间进行权限的传递。比如,实体A可以将角色A.role1委托给实体B的角色B.role2,而实体B可以将角色B.role2进一步委托给实体C的角色C.role3。则实体C的角色C.role3可以通过角色B.role2传递获得角色A.role1具有的权限 而这种权限的传递功能是SVE结盟环境所不具备的
12
对比dRBAC技术而言,SVE技术缺乏必要的灵活性,必须在两两节点之间进行互相授权
13
结合PKI跨域的RBAC控制 跨域的基于角色访问控制应用背景
在目前大规模的Internet应用环境下,基于Web的浏览方式为用户获取网络上各种信息提供了便利。如果服务器提供的是敏感或重要信息,那么系统就需要针对这些信息提供访问保护 这样的Web服务有很多,比如大学图书馆提供的电子资源服务,通常都包含有最新的期刊、学术会议和学位论文等在线检索和下载服务。这些信息资源都具有十分重要的学术科研价值,必须是经过系统授权的用户才能进行访问
14
结合PKI跨域的RBAC控制 设有A和B两所大学根据联合办学协议,互为对方的学生开放各自图书馆提供的在线服务。因为学生毕业和新生入学等情况,用户经常发生变化。因此B的服务器在面向A大学的学生提供服务时,应基于“A大学的学生”这个角色授权,而无需针对A大学的每一个学生进行授权。反之,A的服务器也是如此 当A大学的学生访问B的服务器时,发出访问请求的用户需要证明自己确实来自于A大学这个组织,而且具有“A大学的学生”这个角色,才能够获得在线服务
15
结合PKI跨域的RBAC控制 针对大规模的分布式系统环境下如何识别用户的身份问题,现阶段主要采用PKI的技术。每一个组织内部建立PKI机制,为每一个用户发布X.509证书来证实身份。不同的组织之间借助交叉认证技术来相互识别和信任。具体实施技术可以参考下一章PKI技术的相关内容 在服务器方验证用户的身份以后,必须解决的问题就是如何验证用户具备相应的角色。针对该问题,下面介绍的结合PKI的跨域基于角色的访问控制技术,是从服务器端的访问控制表设置、用户角色的表示、角色层次链的设计、服务器端角色验证等方面提出的具体解决方案
16
结合PKI跨域的RBAC控制 访问控制表和用户证书
1. 服务器访问控制列表设计 服务器提供的资源信息需要受到安全策略的保护,系统必须针对角色进行相应的授权设置。服务器采用访问控制表(ACL)的形式将权限和角色联系起来 ACL就是将系统保护的资源或服务的访问权限授予给相应的角色。因此,ACL目录表中的每一项可以被看作一个(角色,访问权限)序偶。下文具体分析一个ACL目录表的实例
17
结合PKI跨域的RBAC控制 例,在B大学的图书馆在线服务器中,针对某项期刊查询和下载服务,可以设置如表6.1的ACL列表
从表6.1可以看出,对于该项期刊查询和下载服务,系统针对不同的角色,授予不同的访问权限。来自于A大学的学生可以进行在线查询服务,但是没有下载的权限;来自于B大学的学生不但可以进行在线查询服务,而且可以对期刊进行下载操作 表6.1 服务器ACL列表设置 角色 权限 A大学的学生 查询 B大学的学生 查询、下载
18
结合PKI跨域的RBAC控制 2. 客户域中用户角色证书设计
从服务器域的ACL列表可以看出,服务器域和客户域达成一致协议,通过定义角色实现共享访问。比如,在例1中,A大学和B服务器域以“A大学的学生”这个角色达成一致,针对该角色进行相应的授权 服务器域相信客户域为每一个提出访问请求的用户,分配相应的角色。客户机必须给服务器提供如下证据:通过明确的指派表明用户是客户域的一个成员;在客户域中,用户拥有相应的角色
19
结合PKI跨域的RBAC控制 使用用户角色证书表明用户是某个客户域的成员,证书中不仅包含有该用户的公钥信息,而且为用户指派一个非常明确具体的角色,其中公钥信息主要是为了验证用户的身份。因为在用户角色证书设计时,主要强调其角色信息,所有省略了其公钥信息 用户角色证书的一般形式如下: [user → role]A 该用户角色证书表明:在客户域A内,用户user具有角色role
20
结合PKI跨域的RBAC控制 3. 客户域中角色层次证书设计
如果在客户域内角色集是具有层次关系的,就必须保证用户的角色能够完整的体现它在角色层次中的位置 在一个角色层次中,如果角色r`是角色r的子角色,记作r≥r`,那么角色r`具有的所有权限均被角色r继承 使用角色层次证书揭示角色之间的直接继承关系。其形式为: [role1 → role2]A 该角色层次证书表明:在客户域A内,角色role1是role2的直接上级角色,角色role1能够继承role2具有的任何权限
21
结合PKI跨域的RBAC控制 一般情况下,用户将从他具有的最有特权角色开始,通过角色层次继承关系,获取其具有的所有权限。使用形如r≥r1,r1≥r2,…,rn≥r`角色层次证书链,建立r≥r`的继承关系。这些证书被客户传给服务器,服务器首先证实这个链中的所有证书都是有效的,然后再确认这是一个用户与其相应角色关联的链 4. 用户角色证书和角色层次证书格式 在客户域内具体实现用户角色证书和角色层次证书的格式如图6.10所示,其中省略了与用户、角色、角色层次关系不是很紧密的公钥证书的项目
22
结合PKI跨域的RBAC控制 用户角色证书和角色层次证书 具体实现的证书格式与X. 509公钥证书和PMI属性证书是一致的,角色证书的“角色”项和层次证书的“子角色”项可以被定义为X.509标准证书的扩展项 其中X. 509公钥证书具体的内容项可以参考有关PKI技术的相关章节内容
23
结合PKI跨域的RBAC控制 6.4.3客户域内证书撤销
当客户域内的角色层次发生变化时,系统必须对相应的用户角色证书和角色层次证书进行撤销,而撤销行为当然也会影响到服务器端ACL列表中的相关设置。用户角色和角色层次关系均可以被撤销 如果一个角色r被删除,那么所有与角色r直接关联的用户角色证书和角色层次证书也必须同时被撤销,然后发布新的角色层次关系证书进行相应的补充。比如,r1≥r2≥r3,而r2被删除了,那么r1到r2和r2到r3的角色层次证书都必须被撤销,然后由新的r1到r3的角色层次证书来替代 最后,客户域管理员将会告诉每一个受影响的服务器域管理员。ACL列表中有关r2角色的相关设置也需要被删除,这将是角色r2被撤消的直接后果
24
结合PKI跨域的RBAC控制 应用实例分析
为了说明客户域中用户使用用户角色证书和角色层次证书,访问服务器域中服务的整个流程,下面分析一个实例 例6.8,假设在服务器域B大学图书馆在线服务器中,针对期刊查询和下载服务,设置的ACL列表如例1中所示。在客户域A大学内角色层次中,具有“教授”、“教师”、“助理”、“博士生”、“硕士生”和“学生”等角色,它们之间的继承关系如图6.11所示。设用户“张三”具有“博士生”角色,那么从角色层次中可以看出,他可以通过角色层次继承关系得到硕士生角色和学生角色的权限
25
结合PKI跨域的RBAC控制 若用户张三提出对服务器端的访问,则它必须提供如下的用户角色证书和角色证书链: [张三 → 博士生]A,[博士生→ 硕士生]A,[硕士生 → 学生]A 在服务器端,服务器必须验证每一个证书的有效性,而且从角色层次证书链中证明在客户域A内博士生角色通过硕士生而继承学生角色的权限 通过上述验证以后,服务器允许张三以角色学生的权限进行访问
26
结合PKI跨域的RBAC控制 如果A内部角色层次发生了变化,比如删除了角色硕士生,则A会撤销 [博士生→ 硕士生]A [硕士生 → 学生]A
的证书,并且发布新的证书 [博士生→学生]A 来替代原来的角色继承关系 若怀有恶意的用户继续提供原有的用户角色证书和角色证书链,请求对服务器端的访问: [张三 → 博士生]A,[博士生→ 硕士生]A,[硕士生 → 学生]A 则服务器通过验证角色层次证书链,就会发现证书[博士生→ 硕士生]A已经被撤销,则拒绝用户的访问请求
27
结合PKI跨域的RBAC控制 6.4.5跨域基于角色访问控制技术的安全性分析 针对在跨域的大规模应用中如何实现基于角色访问控制的问题,设计用户角色证书和支持角色层次的证书链,结合服务器的ACL列表设置方案,实现了跨域的基于角色访问控制,同时支持角色层次的授权,并讨论了相应的证书撤销机制
28
结合PKI跨域的RBAC控制 从安全的角度分析,本文的方案与6.3节所介绍的SVE技术类似,服务器需要针对客户域内的角色进行单独的授权。与SVE技术不同的是,客户域无需把每一个用户的主体识别规则都发送给服务器域,因为客户域的用户成员众多,而且经常发生变化 服务器域不用保存客户域的主体识别规则,只需要验证提出访问请求的用户是否具有相应的角色即可。从这个方面来看,结合PKI的跨域的基于角色访问控制技术比SVE技术更加灵活和简单
29
结合PKI跨域的RBAC控制 与6.1节所介绍的角色映射技术相比,结合PKI的跨域的基于角色访问控制技术在服务器域需要为客户域的角色单独授权,并没有把客户域角色当成本地的角色来对待 当客户域角色层次发生变化时,只需要撤销客户域角色在本地ACL列表的设置即可,不会影响到本地的角色层次关系和授权设置
30
结合PKI跨域的RBAC控制 总体而言,结合PKI的跨域的基于角色访问控制技术的主要特点是结合PKI技术,采用用户角色证书和角色层次证书实现跨域的基于角色访问控制,其安全性主要与PKI技术相关 它主要适合于大规模的Internet应用环境下,客户域和服务器域的用户众多,而且经常发生变化的应用情形下实现跨域的基于角色访问控制 比如,大学与大学之间,大企业与大企业之间建立协作共享关系等
31
结合PKI跨域的RBAC控制 习题六 1. 试设计一个算法,检测建立一个从外域角色到本域角色映射是否会发生角色冲突,若发生了冲突,给出该映射与那些映射是冲突的。 2. 试列举一个dRBAC的应用实例,分析其实体、角色和角色委托关系,要求至少使用一次第三方委托;并思考如何使用一系列自证明的委托来替代该第三方委托。 3. 列举一个使用dRBAC模型中应用值属性的应用实例,并能够使用值属性进行传递委托,使得不同实体获得的不同的访问服务。 4. 从角色映射、角色授权、角色信息披露等方面对比6.1节、6.3节和6.4节中所跨域的访问控制技术,说明各自优点和缺点
Similar presentations