无思
本BLOG只用于个人资料收藏,内容如非注明,均为转贴资料,无意侵犯版权,特此声明!
博客园
::
首页
::
新随笔
::
联系
::
订阅
::
管理
::
63 随笔 :: 42 文章 :: 17 评论 :: 3 引用
安全模型的一种模式语言
摘要
安全问题是Internet中比较重要的问题,对于设计一个包含安全模块的新系统,安全性也是必需的。模式是一个很好的工具,可以帮助设计者构建安全的系统。我们在这里将讨论三种模式,它们都是最通用的安全模型:授权(Authorization)、基于角色的访问控制(Role-Based Access Control)和多级安全(Multilevel Security)。这些模式可以应用于系统的所有级别,我们将展示它们在文件授权模式定义中的使用。
1、简介
安全是任何计算系统非常重要的方面,并且在机构把他们的数据库向Internet开放后,这已经成为日益严重的问题。大多现在正使用的Web系统在设计时并没有过多考虑安全性,即使打上补丁,也还是不能有效抵御攻击。所以,开发系统过程中,在设计的每个阶段都考虑到安全性是很重要的,不能够仅仅满足功能性需求,还要满足安全性需求[Fer00a]。为做到这一步,我们要从表示机构安全策略的高层模型开始。现在,大多数系统使用三种模型:访问矩阵、基于角色的访问控制(RBAC)模型和多级模型。
安全性包含在系统所有的架构层中[Fer99],因此,分层架构(Layer)模式[Bus96]是本模式语言的入手点。这个模式提供了一个结构,在这个结构中,我们可以为所有层定义模式,共同完成一个安全的系统。它的主要概念是将系统分解成若干抽象的层次级别,高层使用低层的服务。这里给出一种全面看待事物的方式,并且描述了每层所需的机制。我们在以前曾讨论过 [Fer99]:为什么所有这些层必须协调起来,确保其安全性。图1展示了我们所考虑的特定分层,这个图展示了每层的一些参与者和它们相应的交叉层。
由于问题的复杂性,我们需要一系列模式语言,每层一种。本文我们从抽象模型的一种模式语言开始,它包括三种基本的模型,上边提到了,这些模型为应用程序架构最上层定义了安全性约束,但在底层实施。这些模型已经被安全性社区广泛研究[Pfl97,Sum97],我们不想再增加新模型或扩展现有模型。我们的目的是将这些已被接受的模型表示成面向对象的模式,以能够作为构建安全系统的指导,同时,也展示这些模式如何应用于所有系统级别。
首先,我们提出描述资源访问控制的授权模式,接着在第3节描述RBAC模式,它是授权模式的一种扩展。第4节是多级安全模型。在这之后,我们将讨论这些模式如何应用于底层,并展示一种文件访问控制的模式,作为授权模式特殊形式的例子。最后,我们将讨论这些模式的一些共同方面。
图1 分层模式的一个实例
2 授权模式
上下文
任何存在主动实体请求某种受控资源的计算环境。
问题
如何描述主动计算实体(主体)对被动资源(保护对象)可允许的访问类型(授权)。
先决条件
◆ 授权结构必须独立于资源类型,例如对用户访问概念实体、程序访问操作系统资源,要以统一的方式来描述。
◆ 根据特定条件,谓词或保护措施可能要限定授权的使用。
◆ 有些授权可以被它的持有者委托给其他主体。
解决方案
用类和类的关联来表示授权规则的元素。类Subject描述一个主动实体,类ProtectionObject描述一个被请求的资源,一个授权规则由这两个类的关联来定义。一个关联类Right,包含访问许可的类型(读,写等),包含一个谓词,对授权持有者来说必须为true,还包含一个复制标志可以为true或false,表明这个权限是否可以转让。另外还有一个操作check_rights用来让主体或对象检查请求的合法性。图2展示了涉及到的元素。
图3是一个时序图,展示了一个请求的验证。ActiveSubject是一个角色(Actor),例如一个请求某种资源的执行进程,这个请求被一个Reference监视器解释。
图2 授权模式
结论
这个模式的优点包括:
◆可以应用于所有类型的资源。主体可以是执行进程、用户、角色、用户组等。保护对象可以是事务、内存区域、IO设备、文件或其他OS资源。访问类型可以是读、写、执行或对象其他高层的某种方法。
◆对于任何可以限定规则应用的条件,谓词是一种通用表示。
◆规则中的复制标志控制权限的转让。不过有些系统不允许转让权限,那么这儿的复制标志将总是为false。
◆有些系统把管理员授权和一般用户授权分开,以满足更高的安全性(职责分离原则)[Woo79]。
◆请求无需在规则中指定确切的对象,它可以由一个已有的保护对象隐式指定[Fer75]。同样,主体和访问类型也可以隐式,这样当进行一些附加处理时,能提高时间花费的灵活性(引出所需的特定规则)。
已知应用
此模型对应访问矩阵的成分,访问矩阵是一个基本的安全模型[Sum97]。它的首个面向对象形式出现在[Fer93]。后来,它在其他若干论文和产品中也出现过[Ess97,Kod01]。它是多数商业产品访问控制系统的基础,例如Unix、Windows、Oracle和很多其他产品。
相关模式
在后面提出的RBAC模式就是这个模式的一个特例。在第5节,我们将展示另一个特例--操作系统文件访问控制模式。
图3 验证请求
3 基于角色的访问控制(RBAC)模式
上下文
多数机构具有很多不同的工作岗位,需要不同的技能和责任,为了安全考虑,用户应该根据它们的工作岗位获得权限。这对应一种基础安全策略,need-to-know原则的应用[Sum97]。工作岗位可以视为人们在执行职责时扮演的角色,尤其在基于web的系统中,有很多不同的用户:公司职员、客户、合作伙伴、搜索引擎等等。
问题
在一个机构中,如何根据角色为用户分配权限。
先决条件
◆机构中的人根据他们职能不同,对信息的访问有不同的需求。
◆我们想协助机构基于need-to-know策略,为它的成员定义精确的访问权限。
◆为单个用户赋予权限需要存储很多授权规则,并且管理员很难跟踪这些规则。
◆用户也许拥有不止一个角色,并且我们可能想实施诸如职责分离之类的策略,那样用户不能在同一个会话中扮演两个角色。
◆一个角色可以分配给单个用户或用户组。
解决方案
延伸上一个模式的概念,把角色当作主体,图4展示了基于角色访问控制的一个基本模型。类User和Role分别表示已注册的用户和预定义的角色,用户被赋予角色,按照角色的职能,赋予用户特定权限。关联类Right定义一个角色用户被授权访问保护对象的权限类型。实际上,综合Role、ProtectionObject和Right,就是一个授权模式的实例。同样,谓词表示依内容而定的限定,用来选择特定对象,copy_flag属性表示一个布尔值,true或false。
图4 基本RBAC模式
图5中的模型考虑到复合角色(Composite模式的应用),以及管理权限和其他权限的分离(职责分离策略的应用),这个模型同时也包含了一个约束条件来实施职责的分离。管理员具有为组和用户赋予角色的权限,它是一个特殊的用户,可以为用户赋予角色和为角色分配权限。安全管理的权限通常包括:
◆角色授权规则的定义。
◆用户组的创建、删除。
◆用户的角色赋予。
图5还包括了会话(Session)的概念,对应于执行时,用户排他方式地扮演某个角色。最后,Group类描述一组可以被赋予同样角色的用户。
结论
这个模式的优点如下:
◆允许管理员降低安全性的复杂度,用户要比角色多得多。
◆机构关于工作岗位的策略可以直接反映为角色的定义和用户的角色赋予。
◆为得到更大的灵活性和规则的简约性,角色可以进行结构化。
◆为了功能的灵活性,用户可以同时激活多个会话,有些任务可能需要多个视图或不同类型的行为。
◆我们可以增加UML约束,以表明有些角色不能用于同一个会话或被赋予给同一个用户(职责分离)。
◆用户组可以作为角色成员,这样可以大大降低授权规则和角色分配的数目。
可能的缺点包括:
◆附加的概念复杂度(新的角色概念,以及多重角色赋予等概念)。
另外还有一些可能的角色结构[Fer94],在特定环境中比较有用。同时,使用角色来扩展第5节的多级模型也是可以的。
已知应用
我们的模式使用面向对象方式表示在[San96]中描述的模型,那个模型已经成为多数研究论文和实现RBAC概念的基本原理[FBK99]。RBAC在很多商业系统中都有应用,包括Sun J2EE[Jaw00],Microsoft的Windows 2000,IBM的WebSphere和Oracle等等。Java JDK1.2的基本安全模块已经表示可以支持很多种RBAC策略[Giu99]。
相关模式
在[Fer93]和[Yod97]中出现一个更简单的版本(相对于图3),在[Kod01]中,有一个软件实现的模式语言(没有考虑合成角色、组和会话)。图5的模式包含了授权模式和合成模式,其他相关模式还有角色(Role)模式[Bau00]和抽象会话(Abstract Session)模式[Pry00]。
图5 RBAC模式
4 多级安全模式
上下文
在某些环境中,数据和文档具有不同敏感级别,例如秘密级、机密级。用户可以凭借许可证访问文档。
问题
如何在安全分级的环境中决定访问方式。
先决条件
◆模型应该根据数据的敏感度来保护它的机密性和完整性。
◆模型应该能够用于所有的架构层。
◆能够有不同的规则组来决定访问方式。
◆必须有一种便利的方式为用户和数据分配分类级别。
解决方案
在这个模型中,用户和数据被赋予分类或许可证。分类包括级别(高度机密、机密等)和分区(工程部、市场部等)。根据Bell-Lapadula模型定义的规则实现用户对数据的机密性访问,通过Biba模型[Sum97]定义的规则来实现完整性。图6展示了这个模型的基本结构。
但是,基本模型不允许级别分配,所以需要一组特定授信的进程来分配级别和修改分类,也就是完成所有管理的功能。
结论
优点包括:
◆用户和数据的分类比较简单,可以根据机构策略进行。
◆在可靠假设前提下被证明是安全的[Sum97]。
可能的缺点包括:
◆通过为数据标上标签以表明它们的分类,这样确保了安全性。但如果没有这么做,将反而降低整个安全度。
◆我们需要附加的受信程序为用户和数据分配级别。
◆数据需要能够结构化成层次化的且具有敏感分级的,同时用户也要能结构化成许可证形式,这通常难以做到,或者在商业环境中是不可能的。
已知应用
这个模型已经用于若干军事项目和一些商业产品中,包括DBMS(Informix)和操作系统(Pitbull[Arg]和HP的Virtual Vault[HP])。
相关模式
角色的概念也可以用在此处,角色分类可以代替用户分类。
图6 多级安全模式的类模型
5 底层
上面这些模式定义了抽象的模型,可以应用于系统的所有层。在每一层可以使用该层具体的实体来表示抽象模型的概念,以形成更加具体的模式。为得到一个安全的系统,有必要为每层定义模式语言,这将留作以后的工作,这里提供一个示例。
第3节的授权模式可以应用于操作系统中用户从工作站访问文件的情况,这是一个图1中系统层的模式。
5.1 文件授权模式
上下文
操作系统的用户需要定义文件,这些文件可以从被不同授权的工作站访问,并且对文件的访问只限于授权用户。
先决条件
对于这种情况,具有如下先决条件
◆可能有不同类型的主体,如用户、角色和组。
◆主体可以被授权访问文件、目录和工作站。
◆一个主体在每个已授权工作站上都有一个home目录,但是同样的home目录可以在多个工作站或主体之间共享。
◆用户可以形成组来访问。
◆有些系统使用角色代替用户作为主体,或两者都作为主体。
◆操作系统中文件系统具有不同的实现方法。
解决方案
把授权模式特殊化,以文件代替对象,以访问许可代替权限,如图7。它定义了文件访问,工作站方式也是类似地应用授权模式定义。文件和目录是递归结构的,结果是一个语义分析模式(Semantic Analysis pattern SAP),组合了两个版本的授权模式成为一个合成模式。一个SAP是对应于一组基本用例的分析模式[Fer00]。
结论
这个模式可能的优点:
◆它可以使用于多种主体,包括用户、角色和组。
◆被访问的对象可以是单个文件、目录,或者是递归结构的目录和文件。
◆隐式的授权是可能的,例如,访问一个目录可以隐式指定以类似的方式访问该目录下所有的文件。
一些缺点如下:
◆该模式的实现不必依据访问矩阵模型。例如,Unix使用一种伪访问矩阵,使用need-to-know策略并不恰当。但可以为这个模式加上约束,强迫模式所有的示例都遵从一个访问矩阵模型。
其他方面包括:
◆有些系统对工作站不能使用授权。
◆多数操作系统使用读、写、执行作为访问类型,更高层类型的访问也是有可能的。
◆多数操作系统有所有者的概念,它是一个特殊的用户,对它创建的文件拥有所有的权限。
◆有些系统中,文件映射到虚拟内存地址空间,这个模式同样适用于这样的情况。
已知应用
这个模式出现在Unix、Windows、Linux和多数现代操作系统中。
相关模式
这是授权模式的一个特例,如果使用角色,就还和基于角色访问控制模式有关,文件系统使用了一个合成模式。
图7 文件授权的一种模式
6 模式的一般讨论
以上这些模式的具体实现要看它应用在架构中的哪一层,其中一个重要的问题是如何以较低的负荷来进行访问控制。授权模式可以通过访问控制列表(ACL)来实现,多数操作系统就采用这种方法。另一种方式是使用Capablities,硬件和操作系统层控制资源即采用这种方式。近来有些文章描述应用控制对类的访问[Fra99],使用元类和反射机制来实现这些模型是另一种有趣的方式[Wel99]。对资源的请求必须被ACL或capabilities中的信息解释和验证,这需要一个特殊的程序(另一种模式),叫做Reference Monitor[Sum97],一个可能的实现就是POSA2中的Interception模式[Sch00]。
已经提出的某些架构层的模式:
◆Yoder和Barcalow[Yod97]描述了单访问点(Single Access Point,一种通用安全系统设计模式),检查点(Check Point,一种Reference Monitor)、角色(见第三节)以及其他等。
◆Fernandez讨论了元数据和模式之间的关系[Fer00a]。第三节的RBAC模型最先出现在此。
◆Cryptographic模式描述在[Bar00]。
◆关于安全模式,包括一些网络安全模式的一般性讨论位于[Sch01]。
◆一个访问控制、过滤分布对象的框架,组合了若干模式,位于[Hay00]。
◆Java的若干安全模式位于[Jaw00]。
对于在每一层增加更多的模式,收集和统一这些模式的工作还有待继续进行。
还有一些基于其他策略或策略组合的安全模型。其中重要的两个模型是Clark-Wilson模型和Chinese Wall模型[Sum97]。Clark-Wilson模型着重强调完整性,并定义两个基本原则:
◆组织良好的事务――确保对数据的修改保持在一致的状态
◆职责分离――改变必须至少被两方认可。
Chinese Wall模型与其说是模型,不如说是一种策略。信息被分组成若干利益冲突的类,一个人在每个类中至多允许访问一组信息。
目前有Clark-Wilson模型的模式[Wel99],但是没有Chinese Wall模型的模式。
绿色通道:
好文要顶
关注我
收藏该文
与我联系
posted on 2004-11-03 11:30
kavenmo
阅读(372)
评论(0)
编辑
收藏
注册用户登录后才能发表评论,请
登录
或
注册
,
返回博客园首页
。
首页
博问
闪存
新闻
园子
招聘
知识库
最新IT新闻
:
·
报告称当前Linux人才抢手 高薪也难觅
·
谷歌业务大盘点:社交网络令人失望(组图)
·
为程序员和设计师准备的10个流程图
·
一周之内,这个公司推出了三家创业公司
·
三星高层称无需担忧苹果智能电视
»
更多新闻...
最新知识库文章
:
·
进入2012 -- 回顾我走过的编程之路
·
如何学习编程
·
学编程关键在动手,提高在实践
·
十年程序员
·
HTTP 协议详解
»
更多知识库文章...
China-pub 2011秋季教材巡展
China-Pub 计算机绝版图书按需印刷服务
<
2012年2月
>
日
一
二
三
四
五
六
29
30
31
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
1
2
3
4
5
6
7
8
9
10
公告
昵称:
kavenmo
园龄:
7年4个月
粉丝:
0
关注:
0
搜索
常用链接
我的随笔
我的评论
我的参与
最新评论
我的标签
随笔分类
AJAX(1)
(rss)
C#.NET
(rss)
Java田地(15)
(rss)
Unix世界(1)
(rss)
读书人生(1)
(rss)
股慧(1)
(rss)
架构设计&设计模式(10)
(rss)
人际管理(1)
(rss)
软件工程(6)
(rss)
生活备忘录(3)
(rss)
数据库随笔(2)
(rss)
卫生信息(3)
(rss)
信息化咨询(6)
(rss)
哲学思源(1)
(rss)
知识库(7)
(rss)
随笔档案
2007年11月 (2)
2007年2月 (5)
2006年12月 (2)
2006年7月 (5)
2006年6月 (2)
2006年4月 (5)
2006年3月 (12)
2006年2月 (2)
2006年1月 (8)
2005年3月 (2)
2004年10月 (11)
2004年9月 (7)
文章档案
2010年11月 (1)
2004年12月 (1)
2004年11月 (7)
2004年10月 (32)
相册
家园
旅游
人生
相关资源
(原创)Ant、Xdoclet、struts、jboss、intellij联合开发,斑竹鼓励
ant手册
AppFuse In Eclipse
C#设计模式
Cleaner and More Concise Transaction Definitions in Spring 1.1
Demonstrating Spring's Finesse
GRASP Patterns-Genernal Responsibility Assignment Software Patterns
Grease's Java
(rss)
Java FAQ Struts Hibernate Eclipse Spring JSF Velocity JDO Tapestry
Matt Raible 可是大名鼎鼎啊,是 appfuse 的开发者,非常活跃!
Nhibernate
Persistence in Spring
References for OO and JAVA™ Programmers
SpringFrameworkBlog
webperformanceinc.com
理解 JTS — 幕后魔术-J2EE 容器如何隐藏事务管理的复杂性
梦想风暴
中文Blog目录集
最新评论
阅读排行榜
评论排行榜
推荐排行榜