访问控制机制（精选9篇）
访问控制机制 篇1
0 引言
Internet正在越来越多地融入到社会的各个方面,计算机网络的安全问题随着Internet的发展而越来越被人们所重视。在社会日益信息化的今天,随着Internet以电子商务为代表的网络应用的日益发展,出于各种目的的网络入侵和攻击越来越频繁。信息网络的大规模全球互联趋势,随着网络用户成分越来越多样化,以及人们的社会与经济活动对计算机网络依赖性的与日俱增,Internet安全以及信息数据安全,使得计算机网络的安全性成为信息化建设的一个核心问题。随着Internet对公司、个人和社会生活影响的日益扩大,Internet越来越深入地渗透到各行各业的关键要害领域,网络安全作为一个无法回避的问题呈现在人们面前.如果网络安全问题不能得到妥善的解决,网络使用者如果不重视自身的安全防范,将会对国家安全带来严重的威胁,将很有可能给自己带来一系列的严重后果。
本文以研究和改进Linux现有的存取访问控制机制为主要目标,在对Linux现有安全机制分析的基础上,为了验证LYSLinux存取访问控制模型的可行性和正确性,进一步结合信息安全模型理论,本文设计并实现了基于LYSLinux存取访问控制模型的LYSLinux原型系统,总结出了安全操作系的分权思想,并进一步提出了LYSLinux存取访问控制模型及分层授权观点。LYSLinux原型系统的设计充分利用了Linux内核提供的安全设施,基于现有FLASK安全体系结构设计。本文通过对LYSLinux原型系统的测试和结果分析,进一步总结该系统的优缺点。
1 安全操作系统的发展和研究现状
Linux网络系统结构将整个网络系统的结构分为内核空间和用户空间两部分,IP协议实现网络层协议,其中内核空间又可以分为协议层和设备驱动层,在IP层以下是网络设备来支持所有Linux网络工作。Linux选用编程接口是由于它的流行性及可移植性,控制Socket文件描述符对应的就是对BSD Socket的操作,有助于应用程序从Linux平台移植到其他Unix平台。从INET Socket层到IP层,它由INET Sockets层来支持,发送数据时根据发送的目标地址确定需要使用的网络设备接口和下一个需要传送的及其地址,这一层为基于IP协议的TCP和UI)P管理传输端点。从而进入到BsD Socket层的操作,从IP层到数据链路层,接收数据时在IP层判断数据包是向上一层协议提交还是需要做IP转发,就是到网络接口设备驱动程序,对数据包的采集和发送。
由于Linux安全操作系统的应用已非常广泛,不断成熟和完善的Linux提倡的开放源码政策及自身安全方面所具有的一些优良特性。国内近年来在这方面也取得了大量成果,Linux的存取访问控制机制也在不断的发展和完善,然而,现有的Linux存取访问控制仍有其不足之处,较之国外仍存在差距,在研究成果的产品化上亦有诸多缺陷。
2 安全体系结构
安全模型是对系统安全功能的高度抽象和概括,安全系统的设计和实现除了依赖于具体的安全模型之外,是实现具体安全机制的理论基础。同时,还需具有良好的体构来保证系统的运行效率和质量,安全模型也是制定安全策略的依据。因此,安全体系结构(安全体系框架)是实现安全系统的基础和依据,对安全框架的研究是十分必要的。
Flask体系结构提供了动态策略支持,从安全服务器取得主体对客体的访问权限。Flask体系结构实现了动态安全策略,标识系统管理的对象,支持策略灵活性。缓存了数目有限的特定主体对客体的访问权限记录,主要为了避免由于安全服务器的频繁访问而造成的系统性能下降对象管理器,实施安全策略的判定;安全服务器通过该接口对象管理器能及时感知安全策略的变化,做出安全策略的判定。Flask体系结构如图1所示。
3 Linux内核安全机制分析
针对自主访问控制存在的种种不足,Linux系统下出现了许多强制访问控制机制,SELinux是一个基于动态策略配置的强制访问控制子系统。由于SELinux支持较细粒度的权限描述和管理,采用SELinux能极大程度的提高系统的安全性能。
SELinux安全策略配置支持RBAC模型,该模型中存在另一个实体集——用户集。用户可以将一个或多个类型指派给某一角色,SELinux定义的用户是RBAC模型的组成部分,换言之,SELinux中的角色是包含一个或多个类型的更大的权限集,实际上是一个更大的权限集合。SELinux在设计初期是以内核模块的形式插入到内核中运行的,Linux2.6内核中SELinux访问控制建立在LSM框架之上。LSM的主要思想是内核的设计者在需要进行访问控制的位置插入相应的钩子函数(hooks),是Linux内核中为安全模块(系统)的设计提供的一套内核机制。当信息流到这些钩子函数时控制时,内核根据该反馈结果控制系统中的信息流,内核会将控制交给注册到LSM中的安全控制函数,然后经过某一安全策略的判断后将决策结果反馈给内核,安全控制函数首先提取出主体和客体信息,SELinux的存取访问控制是基于LSM框架实现的。SELinux的结构如图2所示。
4 Linux存取访问控制模块设计
Linux安全模块(LSM)采用了通过在内核源代码中放置钩子的方法,满足大多数现有Linux安全增强系统的需要,截获主体对客体的访问。为了Linux安全模块(LSM)采取了简化设计的方式,在系统运行过程中,Linux安全模块(LSM)现在主要支持大多数现存安全增强系统的核心功能。系统通过提取存放在内核对象安全域中的信息,对一些安全增强系统要求的其他安全功能,得到主客体的安全标识。Linux安全模块(LSM)现在主要支持“限制型”的访问控制决策,LSM框架为多数内核对象增加了安全域。当Linux内核给予访问权限时,进程控制块(task struct),inode结点,用户进程执行系统调用,首先经过Linux内核原有的逻辑找到并分配资源,进行错误检查,只提供了的少量的支持,然后经过经典的UNIX自主访问控制,对于模块功能合成。在Linux内核试图对内核对象进行访问之前,Linux安全模块(LSM)允许模块堆栈,安全模块根据其安全策略进行决策。LKM的最基本框架
LKM编译成功之后,可用insmod命令插入到系统内核,并在内核态下运行。
5 系统工作流程分析
当LYSLinux内核模块初始化完毕后,内核中LSM框架的钩子函数会将程序流引向LYSLinux安全策略实施机构中相应的辅助函数,安全策略实施机构开始截获并根据安全策略实施强制访问控制。LYSLinux安全策略实施机构的辅助函数会从内核对象中提取出LYSLinux所需的安全信息,根据激活的辅助函数及其他LSM传递的参数判断主体对客体的操作请求以及该操作的类别,一般是指主体的当前有效SID和客体类型的类型号。
当存取访问向量缓存(AVC)中找不到相应向量时,由主体的SID,客体类型的类型号以及操作和操作类别到存取访问向量缓存中查寻相应的访问向量,AVC会进一步请求对象管理器并得到与SID对应的主体权限信息,通过查询安全策略数据库计算出对该操作集的决策结果以及存取向量,然后会将主体权限信息与客体类型和操作集及操作类别发送到安全服务器。更新存取访问向量缓存并返回决策结果,安全策略实施机构将决策结果返回给Linux内核。
安全策略服务器主要由安全策略加载器(DBLoader)和策略查询器(Policy Querier)组成,安全策略服务器的结构和工作时所依赖的数据结构信息。策略查询器(PolicyQuerier)负责根据其他组件的安全查询请求信息从安全策略数据库中提取出相应的信息,安全策略加载器负责构建和维护安全策略数据库(PolicyDB)。系统启动时安全策略加载器会从文件系统加载二进制安全策略描述文件到内核空间,计算出该请求的访问向量并返回,并由一组加载函数从二进制策略文件中读出策略数据,并用这些数据初始化安全策略数据库。策略查询器实现了db make decision函数,该函数申明如下:
该函数会根据一定的策略由上述的三个集合计算出该主体对该客体的所有权限以及请求操作集中被允许的权限。
6 结论
系统管理的各类软硬件资源包括数据的安全,而在操作系统中对资源的访问操作都需请求操作系统内核的服务,Linux操作系统以其良稳定的系统性能和开放源码的优势受到了广大个人用户和企业的青睐,因此基于操作系统内核的存取访问控制可以有效的保证系统中数据的安全性。但是Linux操作系统的存取访问控制还存在不足之处,对信息安全模型和安全体系结构研究的基础上,着重对现有Linux操作系统的存取访问控制机制进行了优缺点分析,并在此基础是提出了若干改进思路和观点,并构建了原型系统加以验证。
参考文献
[1]Sylvia Osborn,Ravi Sandhu,Qamar Munawer.Configuringrole-based access control to enforce mandatory anddiscretionary access control policies.ACM Transactions onInformation and System Security.2000,13(2):8-96.
[2]梁洪亮.支持多安全政策的安全操作系统的研究与实施[D].中国科学院软什研究所,2002:11-23.
[3]Zanin,Giorgio.Towards a formal model for security policiesspecification and validation in the SE Linux system.Proceedings on the Ninth ACM Symposium on AccessControl Models and Technologies,2004,10(5),136-145.
[4]李远征.操作系统访问控制模型关键技术研究[J].计算机工程与设计,2005,26(4):1004-1002,1095.
[5]Ray Spencer,Stephen Smalley,Peter Leacock,Mike Hitler,David Andersen,Jay Leprous.The Flask Security Architec-ture:System Support for Diverse Security Policies.Proceedingof The Eighth USENIX Security Symposium.1999,8:123-139.
访问控制机制 篇2
PC(10.1.1.2)---E0(10.1.1.1)[RouterA]S0(192.1.1.1)---S1(192.1.1.2)[RouterB]
做网络的单向访问其实实现的是防火墙的基本功能：我是内网，你是外网，我能访问你，但你不能访问我，
所以现在假设RouterA的E0口所连网段为内网段，RouterA S0所连的网段为外网段，还假设我想做的是内网的PC机能ping通外网RouterB的S1口，但RouterB却ping不进我的内网。
用ACL来实现类似的单向访问控制需要用到一种特殊的ACL，叫Reflexive ACL。Reflexive ACL的配置分为两个部分，一部分是outbound的配置，一部分是inbound的配置。
在继续下面的说明之前，先说点题外话。在最开始想到单向访问问题时，我(也包括其它一些我的同事)自然的就这么想：那我在E0口上允许PC的流量进来，然后再在S0口上禁止RouterB的流量进来不就行了?看上去好像没什么问题，但一试就知道其实是不行的。为什么不行呢，因为很多人都忽略了这么一个问题：即绝大多数的网络流量都是有去有回的，上面的方法只解决了去的问题，但这个流量在到达RouterB后，RouterB还需要返回这个流量给PC，这个返回的流量到了RouterA的S0口，但上面的方法却在S0口上禁止了RouterB的流量进来，回来的流量被挡住了，通讯失败。
好，下面再切回来。Reflexive ACL中outbound的部分决定了我出去的哪些内网网络流量是需要被单向访问的，inbound部分决定了这些流量在返回后能被正确的识别并送给内网发起连接的PC机，
Reflexive ACL中outbound的部分：
ip access-list extended outbound_filter
permit icmp any any reflect icmp_traffic
permit ip any any
!---注意在Reflexive ACL中只能用named方式的ACL，不能用numbered方式的ACL。
!---基本配置和普通ACL并没有什么太多不同，不同之处是reflect icmp_traffic，它的意思是这条ACE作为单向流量来处理，并且给了一个名称叫icmp_traffic，icmp_traffic在inbound部分被引用。
!---permit ip any any并不是必要的，加在这里是为了另一个测试，下面会说明。
Reflexive ACL中inbound的部分：
ip access-list extended inbound_filter
evaluate icmp_traffic
deny ip any any log
访问控制机制 篇3
在基于属性的访问控制 (ABAC) 中, 访问判定是基于请求者和资源具有的属性, 请求者和资源在基于属性的访问控制中通过特性来标识, 而不像基于身份的访问控制那样只通过ID来标识, 这使得基于属性的访问控制具有足够的灵活性和可扩展性。对一些复杂的授权可能需要一种细化的控制策略, 针对某一特性进行授权, 在Web Services访问控制中, “服务请求者”对“服务”进行的某种操作权限也是基于服务请求者和服务的特性而作出的, 因此可以“将服务请求者”对“服务”都作为对象处理, 用属性对它们进行描述, 则属性的动态变化会引起授权的相应调整, 从而实现动态授权。有了属性, 可以对角色做更细致的刻画, 那么基于属性的访问控制比基于角色的访问控制就拥有更细的控制粒度, 能够展现出表述含义更加丰富而灵活的访问控制策略。基于属性的访问控制模型是根据参与决策的相关实体的属性来进行授权决策的。这里提到的实体分3类:主体 (Subject) 、资源 (Resource) 和环境 (Environment) 。
(1) 主体属性:
主体是对资源进行操作的实体。每个主体都有很多与其身份和特点相关的很多属性, 比如身份、角色、年龄、职位、PI地址等。
(2) 资源属性:
资源是被主体操作的实体。它可以是一个文档, 一个文件夹或一组数据库中的数据。跟主体一样, 资源的很多属性都可以作为访问控制判断的依据。比如一个Word文档就有题目、作者、创建日期等属性, 以及一些与安全相关的属性, 如安全级别、防扩散要求等。
(3) 环境属性:
环境属性被很多访问控制策略所忽视, 它通常描述事务处理时的上下文, 包括时间、日期、系统状态、安全级别等。
在访问控制策略中, 我们分别用S、R和E来表示主体、资源和环境。如果需要考虑K个主体属性, 我们就用SAk (1≤k≤K) 来表示这些主体的属性, 用SAkDomain (1≤k≤K) 来表示这些属性的取值范围;如果需要考虑M个资源属性, 我们就用RAm (1≤m≤M) 来表示这些资源的属性, 用RAmDomain (1≤m≤M) 来表示这些属性的取值范围;如果需要考虑N个环境属性, 我们就用EAn (1≤n≤N) 来表示这些环境的属性, 用EAnDomain (1≤n≤N) 来表示这些属性的取值范围。在基于属性的访问控制模型中, 判断是否允许一个主体S在环境E下访问资源R, 是根据主体S、资源R以及当前上下文环境E的具体属性来决定的。
can_access (s, r, e) ←f (attr (s) , attr (r) , attr (e) )
其中, access通常代表一系列操作, 如:red、write等;f是一个函数, 它通过主体S、资源R和环境E的属性值来计算, 其结果决定主体S的访问是否合法。f函数就是访问控制策略规则, 它是根据具体的业务规则来制定的, 它描述了主体访问资源时必须满足的条件。
2访问策略合成器
为实现基于Web Services的多安全异构域集成与整合, 就需要整合服务提供域之间的不同访问控制策略。该策略是系统管理员基于主体对客体的行为信息而为系统量身制定的一系列访问控制规则以及规则组合算法, 以此对资源、用户的访问进行控制。因此按照属性的规则对服务资源进行控制, 非常适合动态分布的Web服务环境。而如何整合不同的访问策略就在怎样确定f这个函数。
本文假设制定聚合资源策略的各方均采用基于属性的访问控制, 并且各方对实体所有的关联属性有一个共同的认识。事实上, 随着基于属性的访问控制的发展, 这是在分布式跨域协作应用中常见和典型的环境假设.虽然环境的开放性和安全需求的多样性可能导致需要考虑的属性很多, 但对常见的公共属性, 可以建立一个通用的属性本体 (Ontology) , 然而这不是本文研究的重点。值得注意的是, 这并不意味着各方访问控制都考虑相同的公共属性, 允许各方策略具有不同的属性 (即异构环境) , 另外, 本文的工作主要解决策略合成方式的刻画问题, 我们假定协作各方已经具有相应的访问控制策略.
在实际问题中, 函数y=f (attr (s) , attr (r) , attr (e) ) 往往是比较复杂的, 难以写出它的表达式, 但通过实验观测, 我们连接每个域的策略模型的种类是有限的, 一般有基于角色和基于ACL这两种策略模型。策略合成模型如下图1根据策略合成模型构建的数据流模型如图2。
由用户发送的一个服务请求, 经过PEP, PDP等组件, 完成一个完整的授权过程, 一般要经过以下几个步骤:
(1) PAP定义的策略和策略集合存储在PDP可以检索到的地方。这些策略和策略集合都有各自的目标 (Target) 标识;
(2) 用户向保护资源的PEP发送一个服务请求;
(3) PEP收到用户的服务请求, 根据其内容构造一个本地请求, 包括请求主体、所请求资源、所进行的操作以及当时的执行环境的属性 (有些是可选的) , 发送给PDP ;
(4) PDP根据收到的PEP的请求, 重新构造XACML请求;
(5) PDP要对XACML请求评估过程中需要的其它主体、资源、行为和环境的属性进行检索, 再从PIP处检索所需要的属性信息, PIP根据PDP的请求返还所需要的属性信息;
(6) PDP根据所得属性判断是基于ACL的还是基于角色, 如果基于ACL, 转交基于ACL访问控制器。如果基于角色, 转交基于角色访问控制器;
(7) 基于ACL访问控制器或基于角色访问控制器根据策略判断, 返回信息;
(8) PDP把评估XACML请求后的响应内容 (包含授权决策的结果) 返回给PDP;
(9) PDP把收到的PDP的响应转换成PEP能够理解的响应格式, 并把转换后的响应消息发送给PEP;
(10) PEP根据收到的响应内容, 即PDP的授权策略要求PEP在执行该策略授权的同时, 需要执行PDP所规定的一组指令, 实施义务;
(11) 最后如果访问允许, PEP允许访问受保护的资源, 否则访问将被拒绝。
3结束语
本文讨论了开放网络环境下的访问控制问题, 提出一种基于属性的访问控制策略模型, 基于属性的访问控制 (ABAC) 能够解决传统访问控制难以解决的细粒度访问控制和大规模动态授权问题, 它能够灵活支持基于主体属性、客体属性和环境属性的访问控制策略。对策略评估过程进行了形式化定义与分析, 给出了策略评估的具体模型, 设计了一种可扩展性强的策略管理框架。下一步研究要完善策略模型对职责和义务策略的支持。本文同时为未来开放网络环境中的复杂信息系统访问控制研究提供了新思路和文献参考, 具有一定的理论意义和实用价值。
参考文献
[1]G.Malkin Internet Users’glossary.IETF RFC1983[EB/OL], ht-tp://www.fags.org/rfcs/.
[2]R SANDHU E.COYNE H.FEINSTEIN, C YOUMAN.Role-based access control models[J].IEEE Computer, 1996 (2) .
[3]戴怡, 杨庚.网格环境下多域间的认证机制研究[J].计算机工程与应用, 2007 (5) .
[4]韩涛, 郭荷清, 等.一个WEB服务访问控制模型[J].计算机科学, 2007 (10) .
[5]WANG L D.WIJESEKERA, S JAJODIA.A Logic-based Frame-workfor Attribute Based Access Control[A].Proceedings of the2004 ACM Workshop on Formal Methods in Security Engineering[C].2004.
[6]W WANG.Research of multiple domain single sign-on based onPKI/PMI[J].Control and Automation, 2006 (5) .
[7]MICHAEL A HARRISON, WALTER L RUZZO, JEFFREY D.ULLMAN.Protection in operating systems[J].Communicationsof the ACM, 1976 (8) .
CISCO控制VTY访问 篇4
实验拓扑如下：
实验目的：学习指定源IP可TELNET路由
实验要求：从FA0/0口只有192.168.2.100/24这台PC可以telnet到router上，
首先配置网络可通
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: no
Router>en
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#hostname r1
//修改路由器名称为r1
r1(config)#no ip domain lookup
//输错命令不进行域名查询
r1(config)#line console 0
//进入管理控制台接口配置
r1(config-line)#logging synchronous
//日志进行同步
r1(config-line)#exit
配置接口地址：
r1(config)#interface fastEthernet 0/0
//进入接口视图
r1(config-if)#ip address 192.168.2.1 255.255.255.0
//配置IP地址
r1(config-if)#no shutdown
//开启接口
Mar 2 06:24:23.795: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
//配置访问控制列表：
r1(config)#access-list 1 permit 192.168.2.100 0.0.0.0
//配置ACL列表只允许192.168.2.100这个IP通过
r1(config)#line vty 0 4
//进入虚拟控制台配置
r1(config-line)#password cisco
//配置telnet的登录密码
r1(config-line)#login
//允许远程登录
r1(config-line)#access-class 1 in
//将访问控制列表应用到VTY的进口方向
配置完毕，进行测试
192.168.2.99登陆不到设备上，换个100测试下
点击回车
验证成功，没有问题！！！
第一次做，请各位指正
访问控制机制 篇5
关键词：Docker容器,访问控制机制,LSM,安全
0 引言
随着计算机技术的迅猛发展,容器技术以其高性能和便携性愈发火热,受到人们的广泛关注和大力推广,同时容器和宿主机之间访问的安全性也受到很大的挑战。人们在享受容器技术带来的轻量和快速之余,也感受到容器技术安全的困扰。当人们在容器内运行自己的应用时,不安全的进程就会逃逸出容器,给宿主机带来安全隐患[3,4]。
访问控制是非常重要的安全机制,访问控制是所有系统都会用到的一种安全技术,该技术防止主体对客体的非法访问。目前,针对Docker的安全问题,Docker开发团队采取层叠式安全机制,即多层不同安全技术叠加在一起。Docker容器技术内部使用了部分Linux操作系统原生自带的自主访问控制机制,而且还使用了Linux内核中命名空间机制(Namespaces)和控制组机制(Cgroups)实现Docker容器和Linux宿主机之间的资源隔离,这两种隔离机制是Docker容器和Linux宿主机之间访问控制机制的基础。这些机制是Docker开发团队采用的进行访问控制的基础。但是,Linux操作系统中不是所有的资源都有命名空间(Namespace)。在Docker容器中的进程可以访问到未被隔离内核资源,如根目录下的/sys、/proc等。一旦Docker容器进程能访问这些文件,就导致内核资源的泄露,更严重的将导致Docker容器用户可以获得整个宿主机的控制权。所以,对于Docker容器的安全性,隔离不是万能的,不断地加固安全才是关键。只有不断完善Docker容器和Linux宿主机之间访问控制机制,才能确保Docker容器的安全性[7,8]。
文中分析了Docker容器在Linux宿主机中针对访问控制的隔离机制以及不足,提出一种基于LSM(Linux Secrity Module)通用框架在Linux内核中针对Docker容器进程的强制访问控制机制的框架[9]。通过测试,该框架可以有效地防止Docker进程逃逸出容器,对Linux宿主机的非法访问,完善了Docker容器和Linux宿主机之间的访问控制机制,加固了Docker容器的安全性,而且Linux内核加载该强制访问控制机制框架对自身系统性能影响较小。
1 Docker的访问控制隔离机制及其安全性分析
Docker容器访问控制机制基于Namespaces机制和Cgroups机制,采用Linux内核中Namespaces机制和Cgroups机制实现容器的隔离性和可配额[10]。Docker容器采用Namespaces命名空间机制将Docker容器(container)中的进程、网络、消息、文件系统、UTS和Linux宿主机进行隔离,采用Cgroups机制对Docker容器能够使用的系统资源进行限制和度量,实现对Docker容器进程能够使用的系统资源进行控制。Docker容器技术采用这两种底层机制的叠加实现访问控制中的层叠式安全机制。
1.1 Namespaces机制
Linux操作系统使用Linux Namespaces命名空间机制将Linux系统资源进行隔离开。采用Linux Namespaces命名空间机制之后,Linux系统资源就变成了局部的资源,属于某个固定的namespace命名空间。两个同类型的namespace命名空间下的系统资源是相互不可见的,不同类型的namespace命名空间下的系统资源也是相互不可见的。例如PID Namespace从操作系统层面看,会出现多个相同的pid进程,但是属于不同的namespace命名空间,相互之间不冲突。Linux Namespaces命名空间机制原理图如图1所示。
目前,Linux内核为Linux操作系统提供六个不用的namespace命名空间,分别是uts、ipc、mnt、pid、user、net类别的namespace。在Linux系统中,多个namespaces命名空间里可以有同一个进程,也就是说一个进程可以在多个不同的命名空间中拥有自己的不同的PID进程号,Linux源代码中进程控制块task_struct结构体包含一个进程的所有信息,其中有结构体指针struct nsproxy*nsproxy,指向该进程的所属namespace命名空间信息结构体,如下代码。
在/include/linux文件中的头文件nsproxy.h中,定义nsproxy结构体,该结构体指针指向具体的命名空间信息,主要定义了六个不同的结构体指针分别指向六个不同类型的namespace命名空间,如下代码。
容器技术有了Linux Namespaces命名空间机制才使得容器虚拟化技术更加完善,LXC(Linux containers)利用命名空间(namespace)机制实现Linux系统资源的隔离。不同容器(container)内部的进程是相互不可见的。命名空间可以组织为层次,子命名空间(namespace)之间是相互独立、不可见的,但是父命名空间可以看到子命名空间的进程信息。本质上,Linux Namespaces机制为Linux系统建立了的系统资源的不同视图。
Docker容器采用Linux Namespaces机制实现资源隔离,例如Docker容器中的PID Namespaces,在宿主机新开Docker容器中,默认第一个进程PID为1(dockerinit),即在Docker容器中该进程类似Linux系统中的init进程的功能,负责Docker容器内部所有进程的监控和资源回收。虽然Docker采用Namespaces机制实现隔离,大部分的Linux的资源被隔离,还有一部分的系统资源没有被隔离,例如/sys、/proc目录下的资源。
1.2 Cgroups机制
Cgroups的全称是Control Groups控制组,Linux操作系统使用控制组技术将Linux系统的物理资源进行分配,控制组机制是Linux系统中自身容器技术的底层支撑,为容器的虚拟化提供了基础。Linux内核运用Cgroups控制组机制对Linux操作系统资源进行限制、记录、隔离。Cgroups机制由各个不同的cgroup子系统组成,根据不同的子系统将任意进程和系统资源进行分组化管理。Linux系统中有一个cgroup虚拟文件系统,该虚拟文件系统为Linux用户提供管理和设置各个cgroup子系统的接口。用户挂在需要使用的cgroup子系统就可以设置和管理与之相对应的Cgroups控制组。
在Docker容器中,Cgroups机制是为Linux系统资源在不同用户层面的管理提供一个统一化的接口。Cgroups控制组机制从控制一个进程的简单机制到控制整个Linux操作系统的复杂机制,全部功能就是Linux操作系统级别的虚拟化。Cgroups控制组机制具备四项基本功能:资源限制、资源统计、进程控制、优先级分配。资源限制,Cgroups控制组机制限制进程组能够使用的操作系统资源的份额。资源统计,Cgroups控制组机制使用cpuacct子系统统计Linux操作系统的内存用量、cpu使用量等操作系统资源使用情况。进程控制,Cgroups机制使用控制组中的freezer子系统对系统进程进行调度的一系列操作。优先级分配,Cgroups机制使用控制组中的cpu子系统分配cpu时间片数量以及控制了系统内进程的优先级。Cgroups机制原理图如图2所示。
图中每个Container Cgroup控制组内部都有自己的进程,Cgroups控制组技术通过不用的子系统给每个Container Cgroup分配不用的资源,如cpuset子系统给控制组分配cpu资源、memory子系统给控制组分配内存资源等。Cgroups机制的实现本质是建立钩子函数(Hooks)与系统进程的关联,当系统进程task运行的过程需要使用Linux系统资源时,就会触发挂在进程上的钩子函数(Hooks),进而触发与钩子函数关联的对子系统(Subsystem),子系统进行检测,根据检测的资源类别采用相应的机制实现Linux系统资源限制和进程优先级分配。
2 Docker容器强制访问控制机制框架的设计
该强制访问控制框架在内核中对Docker容器进程进行监控控制,阻止进程逃逸出容器,对宿主机中内核资源的访问。该框架在内核中运用Namespaces机制原理对Docker容器进程定位,然后采用LSM通用框架的可加载安全模块对Docker容器进程进行访问控制,阻止Docker容器进程访问Linux内核资源。
2.1 LSM
LSM即Linux安全模块(Linux Secrity Module),是Linux内核提供的通用的、轻量的访问控制框架,很多访问控制模型能够利用这一通用访问控制框架,将自己编写的具有不用功能的安全模块以可加载的内核模块(Kernel Module)的形式加载到内核中。Linux Secrity Mo-dule安全模块针对内核资源的访问安全定义了一系列与内核结构相对应的hooks钩子函数。Linux Secrity Module安全模块的设计思想是在将透明安全域附加到相应的受保护的内核对象中,这些透明安全域在内核对象中被视为受保护的内核对象安全属性,同时在Linux内核源代码中添加与透明安全域相对应的钩子函数(Hooks),这些被添加的钩子函数负责完成对内核对象的访问的控制。Linux Secrity Module通用访问控制框架使用起来比较灵活、比较高效,使用LSM通用框架对Linux内核性能参数影响较小,不会造成其他的系统开销。LSM逻辑框架如图3所示。
Linux Secrity Module通用框架是从Linux2.6版本以后加入标准Linux内核中。Linux Secrity Module安全模块对Linux内核做了以下修改:①在Linux内核需要保护的数据结构中添加透明的安全域;②在Linux系统调用将要访问到内核对象的地方添加对安全钩子函数的调用;③在Linux系统中加入一个安全的、通用的系统调用;④在Linux操作系统中加入Linux安全模块(Secrity Module)的注册及注销函数;⑤将Linux操作系统中的大部分能力安全逻辑(capabilities逻辑)移植到一个可供用户选择的安全模块。
在Linux内核的关键数据结构中,Linux Secrity Module通用框架会在需要保护的数据结构中添加了一个空类型的指针(void*),该指针建立具体内核对象和对象的安全信息的关联,void*型指针指向安全域。LSM修改的内核关键数据结构有task_struct、inode、super_block、sk_buff、linux_binprm等。同时,Linux Secrity Module在Linux内核源码关键处(系统调用将访问到内核对象的地方)添加对通用框架中钩子函数(hooks)的调用。Linux Secrity Module安全模块中的钩子函数根据它们的作用可以分为两个基本的大类:①一部分函数管理Linux内核对象安全域中各自对应的钩子函数(hooks);②另一部分函数负责内核对象访问控制的各自对应的钩子函数(hooks)的实现。Linux操作系统中全局表security_ops(security_operations)中定义的函数指针用来调用钩子函数(hooks)。Linux系统中所有的系统调用都有相对应的钩子函数(hooks),钩子函数主要包括文件、文件系统、网络、进程、进程通信等方面。
2.2 基于LSM的强制访问控制机制框架的设计
该强制访问控制框架融合了Docker容器中的Namespaces机制和LSM通用框架,其在Docker容器进程对内核对象资源进行访问控制,可以有效防止Docker容器进程逃逸出容器,确保容器进程对宿主机的安全。首先,需要对Docker容器进程进行定位,判断访问宿主机内核资源的进程是否为Docker容器进程,根据结果裁定该进程是否需要进一步安全过滤。如果判定进程为Docker容器进程,该进程需要通过安全决策模块的过滤,安全钩子函数判断进程访问的文件是否为内核资源,裁定进程是否有权访问内核资源。强制访问控制机制框架可以将宿主机与Docker容器未被隔离的内核资源保护起来,使得Docker容器进程不能随意访问Linux宿主机中的内核资源。
Linux宿主机文件不能被Docker容器进程访问是指文件不能被进程打开、读、写、修改等。文件在被Docker容器进程读、写、修改之前,进程必须打开文件,所以保证Docker容器进程不能访问宿主机文件资源,首先要阻止Docker容器进程打开宿主机文件。open系统调用的功能是打开文件,同时进程通过文件位图表获得一个未被使用的文件描述符fd,调用函数获取打开文件对象的信息struct file结构体,最后建立文件对象信息struct file与文件描述符fd的关联,使得根据文件描述符就可以访问与之相对应的文件。open系统调用的详细流程如图4所示。
文中设计的基于LSM框架的强制访问控制机制框架如图4所示。
该强制访问控制机制框架图中具备两个基本功能:①对Docker容器进程定位;②Docker容器的进程进行强制访问控制,完成对Linux宿主机中的内核资源进行保护。定位内核模块对Docker容器进程进行定位,然后与LSM决策模块交互。决策模块根据交互信息判断执行系统调用的进程是否为Docker容器进程,如果不是,则返回0,可正常操作,如果是,则继续执行文件保护判断。针对Docker容器进程的系统调用进行跟踪和处理,容器进程的open系统调用执行流程中,经过自主访问控制判断,还要使用security_inode_permission函数进行文件inode节点判断。security_inode_permission函数对应的钩子函数int(*inode_permission)(struct inode*inode,int mask)。在安全检测模块中使用inode_permission钩子函数判断文件是否是Linux宿主机保护的保护文件。如果是保护文件,则返回错误信息(-ERERM),无权访问,终止系统调用,如果不是保护文件,则返回0,可正常执行系统调用。
强制访问控制机制框架在内核中采用LSM,结合Namespaces机制对Docker容器进程进行定位,在Docker容器的进程系统调用将要访问到Linux内核未被隔离的数据时调用了与之相对应的安全钩子函数。在Linux宿主机中使用该框架可以有效阻止Docker容器进程对Linux宿主机中未被隔离的文件资源的访问。完善了现有的Docker容器和Linux宿主机之间的访问控制机制。
3 强制访问控制机制框架的测试
该强制访问控制机制框架使用LSM通用安全框架,在Linux操作系统中以内核模块(kernel module)的形式加载到Linux内核代码中,加载后可以有效阻止Docker容器进程对Linux宿主机中未被隔离的系统资源的访问,也一定会增加系统负担。文中使用Lmbench测试工具测试了加载强制访问控制机制框架对Linux系统性能参数的影响。
Lmbench是符合ANSI/C标准的一组小型Benchmark测试程序集,是为UNIX/POSIX专门制定的一款微型测评工具。测试主要包括:带宽(Bandwidth benchmarks)和延时(Lateency benchmarks)。本次测试主要关注Lmbench中的处理器、进程操作时间(Processor/Processes)测试结果。
测试在Ubuntu14.04操作系统上进行,Linux内核版本为Linux 3.13.0。测试为两组:原系统Processor/Processes结果,加载强制访问控制机制框架后的Processor/Processes结果。每项参数测试数据统计三次,然后取平均值。测试结果如表1所示。
分析上表中的实现数据可知,加载强制访问控制框架后,读写操作、获取文件系统状态、文件打开和关闭的三项系统性能有所下降。因为Linux系统加载的强制访问控制框架对文件的读写操作、获取文件系统状态、文件的打开及关闭等相关的钩子函数(hooks)进行了重写,当触发这些钩子函数时执行LSM安全策略中重写的钩子函数(hooks),而不是默认的钩子函数(hooks),这将导致这些性能下降。从表1中的整体数据分析,加载该针对Docker容器的强制访问控制机制框架后对原ubuntu14.04系统的性能损失在10%左右浮动,对Linux操作系统的性能的参数影响相对较小。
4 结束语
访问控制机制 篇6
近年来,安卓智能手机的全球市场份额大幅攀升[1],大量的安全问题也不断显现。安卓的安全体系通过权限机制控制第三方应用程序对短信、联系人、感知设备等敏感资源的访问。然而,由于粗粒度的权限控制,使用者和开发者通常为了更好地用户体验而希望获得更多权限,从而导致系统的安全机制直接失效,安卓设备也因此面临了更多安全威胁。其中,恶意代码植入、权限扩大攻击等带来的恶意收费、窃听、位置泄露等安全事件频发。这些用户敏感信息的泄漏问题,给安卓系统安全带来了巨大的挑战。
1 研究背景
1.1 国内外研究现状
国内外的研究人员在安卓权限管理上做了大量的研究。Bugiel等人研究发现权限的过度请求违反了最少权限法则,从而带来隐私泄露和财产损失的隐患[2]。此外,Schlegel等人对权限扩大攻击进行了研究,发现恶意应用程序可以通过和其他应用程序协作,在没有显式请求的情况下访问敏感资源[3]。
研究人员在隐私数据保护方面也做了大量研究。Rayarikar等人在安卓系统上实现了一个对短信进行加密的应用程序,采用AES算法对数据进行加解密[4]。吴剑华等人通过黑白名单的方式,实现对隐私数据的授权访问以及对进程的实时监控[5]。
此外,常见的系统保护软件,如腾讯手机管家等,它们将隐私数据文件隐藏在磁盘的隐藏空间中,使得恶意软件或攻击者无法得到,以达到防止数据泄露的目的。但在该解决方案中,文件本身并没有加密,所以仍存在明文获取、隐私泄露的风险。
1.2 研究内容和意义
面对大量的安卓安全威胁,研究者们已经做了大量的研究,但这些研究大多停留在粗粒度控制上,用户不能对资源进行自定义的保护配置。毕竟,在实际应用场景中,我们并不需要对整个磁盘或者整个数据库进行加密操作。此外,由于缺乏对感知来源的控制,麦克风等感知来源可能被恶意程序调用,从而获取用户的敏感数据,造成用户隐私数据的泄露。
基于以上问题,本文提出基于安卓系统的访问控制增强机制。通过对联系人和短信数据进行细粒度加密,实现隐私数据的保护。同时,本文采用权限阻断的方式,对感知来源数据进行保护。最后,本文通过性能实验验证了保护机制的可用性和可靠性。本文主要贡献如下:1)设计并实现了隐私数据加解密框架,保护自定义字段的数据,避免全加密对系统造成的性能负担。2)设计了权限阻断机制,在不同的应用场景中完成对权限的授予和阻断,从而保护感知来源数据。
2 相关理论与技术
2.1 安卓体系结构
安卓系统的体系结构由4个层次组成:应用程序层、应用程序框架层、Android的运行时和系统库、Linux内核层[6]。
应用程序层提供了基本的应用程序包。该层由一个或多个不同的组件组成:活动、服务、广播接收器和内容提供商。应用程序不一定包含全部组件,但必须至少有一个活动呈现图形用户界面。应用程序框架层是应用开发的基础,该层包括了活动管理器、窗口管理器等10个部分。应用程序框架为不同目的(如电源管理、资源处理、窗口管理)提供管理器。应用程序应该使用管理器的服务,而不是直接使用底层的函数库。这种方式使得通过沙盒式权限系统对管理器强制实施应用程序权限变为可能。系统库和Android运行时中,系统库包含了9个子系统,运行时由Dalvik虚拟机和Java核心库组成[7]。Linux内核是安卓核心系统服务的重要依赖。安卓使用的内核是Linux2.6系列内核,并被修改以满足电源管理、内存管理和运行时环境中的特殊需要。
2.2 安卓系统访问控制模型
访问控制是一种显式的准许或限制主体对客体访问能力及范围的方法[8]。访问控制通过限制关键资源的访问,防止非法用户的入侵,从而保证系统资源的合法使用。安卓对应用程序和数据的访问控制主要通过两种机制的结合,一种为Linux内核安全机制,另一种为安卓特有的安全机制。
(1)Linux内核安全机制
Linux操作系统提供了认证和访问控制机制。首先,root用户作为超级用户能对系统的所有资源做最大限度的调整,还可以允许或禁止其他用户对系统的访问[9]。其次,文件系统是Linux系统安全的核心。安卓系统中的文件也受制于此文件权限机制。Linux系统中的文件使用了文件读写许可机制,不同的用户对不同的文件具有各自的读、写和执行权限。此外,Linux将许多系统功能视作伪文件,所以文件访问机制也能有效地对驱动、硬件传感器、音频设备等进行访问控制。
(2)安卓特有安全机制
访问控制的核心是授权策略。授权策略是用于确定一个主体能否对客体拥有访问能力的一套规则。访问控制模型定义了主体、客体、访问规则是如何表示和操作的,它决定了授权策略的表达能力和灵活性。安卓利用权限机制控制应用程序对敏感资源的访问,每个权限代表了针对系统资源的一个或者一组操作许可,具有细粒度的安全特征[10]。
应用程序默认没有任何权限,它必须在自己的配置文件Android Manifest.xml中用uses-permission标签声明自己所需要的权限,才可以使用某个系统资源或者访问某些数据[11]。安卓约有130条内置权限分别对应了系统中的设备、功能以及数据等的访问权限[12],应用程序也可以定义额外的权限。此外,权限有四个保护级别[13]:正常、危险、签名、签名或系统。
安卓应用程序还使用了数字签名机制对应用程序安装包进行数字签名,以对应用程序开发者进行身份合法性认证,防止恶意应用开发者替换合法应用程序。此外,文件签名还可以确保安装文件内容的完整性和正确性[14]。
最后,安卓系统实现了将不同应用程序之间、进程之间互相隔离。默认情况下,应用程序没有权限访问系统资源或其他应用程序的资源。每个应用程序和系统进程都被分配唯一且固定的User ID。当应用程序需要共享数据或进程时,系统会验证程序的shared User ID和签名,如果结果相同,那么虚拟机认定两个应用程序由相同开发者开发,为两个程序分配相同的User ID,以实现程序之间的数据和进程共享[15]。
3 威胁分析与代码分析
3.1 安卓威胁分析
(1)开发者威胁
来自开发者的基于权限的威胁主要分为过度授权和权限扩大攻击两类。
权限的过度请求是安卓安全中最大的问题之一。它违反了最少权限法则,给用户带来隐私泄露和财产损失的隐患[2]。例如一个请求了SEND_SMS短信发送权限的单机游戏,利用了不必要的短信发送权限在用户不知情的情况下发送付费短信。
一般来说,恶意应用程序造成的影响会受到安卓系统沙盒机制限制[16]。但权限扩大攻击允许恶意应用程序和其他应用程序相互协作从而在没有显式请求的情况下访问敏感资源[3]。权限扩大攻击可以分为混淆代理攻击和共谋攻击。
(2)root威胁
安卓系统基于Linux系统。在Linux系统中,root用户作为管理员用户,可以访问整个系统。在默认设定下,使用者无法获取root权限。然而在现实场景中,用户有许多方法可以获得root权限。root权限可以使用户实现卸载自带软件,取消应用权限,运行防火墙等功能。然而,当root被窃取后,安卓系统的最高权限也被授予,系统安全和用户隐私将受到极大威胁。
(3)物理威胁
安卓系统一般都以手机等智能设备作为载体,因此,也不可避免受到以下的物理威胁:储存卡威胁、设备遗失或报废威胁、传感器威胁等。
通常情况下,手机存储卡上的数据是不会被加密的。储存卡读取成为窃取用户隐私的方便途径。攻击者可通过运行相关程序,获得存储卡上的明文数据。设备遗失或报废会导致数据的机密性受到威胁。恶意用户可以利用用户遗失或报废的设备获取存储在手机中的数据。此外,手机是传感器的集合体。研究学者发现,手机的震动功能、麦克风、定位系统均存在威胁漏洞,用户也因此会面临更复杂更严重的攻击。
3.2 访问控制代码分析
(1)数据库表结构分析
安卓系统中联系人和短信数据存储在SQLite数据库中。SQLite是一个存储效率高、查询快、运行时占用内存小且能被多个进程同时访问的开源数据库。SQLite本身没有提供任何安全控制机制,只要用户得到数据库文件或访问数据库的权限[17],便能够读取这些信息,也直接导致了用户的隐私数据泄露。
通过研究,我们发现安卓系统中联系人数据库contacts2.db存放在/data/data/com.android.providers.contacts/databases路径下。为了获取对该数据库的访问,第三方应用需申请READ_CONTACTS和WRITE_CONTACTS权限。联系人数据库主要涉及到三个表:contacts、raw_contacts和data。其中,contact表保存了所有联系人信息,具体字段包括联系人编号、联系次数、是否有电话号码等。Raw_contacts表存储了联系人的详细信息包括显示名称、昵称、是否被删除等。Data表存储了所有创建过的联系人的详细信息。通过相关分析可知,本文需要对三个数据表中的数据进行选择性加密即可实现联系人数据的细粒度保护机制。
另一方面,安卓系统中的短信数据库mmssms.db存放在/data/data/com.android.providers.telephone/databases路径下。第三方应用需申请READ_SMS、WRITE_SMS、SEND_SMS等权限以获取访问短信数据库文件的权限。数据库mmssms.db中包含所有与短信有关的表结构。其中sms表用于存储短信内容、短信属性、重要字段的描述等。此外,person字段指向了contacts表中的联系人编号,body字段描述了短信的内容。在这两个字段的基础上。本文实现了添加联系人并选择是否对短信内容进行加密的细粒度保护机制。
(2)权限检查分析
安卓操作系统中的权限检查模块主要针对系统服务的访问控制策略。安卓系统提供约30项以特权用户的身份运行的系统服务,包括管理应用程序、提供位置信息、提供蓝牙连接和管理用户账户等重要功能[18]。权限检查模块允许开发者利用权限保护服务的单个方法而不是整个服务,以实现对服务的细粒度的访问控制。例如,check Permission可用于判断给定的进程和用户是否被赋予某条权限。
4 访问控制增强模块需求与设计
如图1所示,为文本设计的访问控制增强系统的总体架构图。该架构旨在实现对安卓设备三个功能模块的访问控制,即:联系人管理模块、短信管理模块和感知来源控制模块。为了更好地实现访问控制增强模块,本文采用了策略管理和密钥管理两个机制。在策略管理机制下,用户可以指定修改联系人、短信的加密策略以及对于感知来源的细粒度控制策略;在密钥管理机制下,用户可以通过密钥机制实现对隐私数据的安全保护。
4.1 联系人管理模块
联系人管理是访问控制增强系统中的重要部分,其主要特点为:在加密策略的驱动下,对联系人数据进行加密操作,以保护联系人数据的安全性。本系统主要实现了联系人的查看、添加、删除和搜索的功能。
用户通过点击按钮进行相关的联系人操作。例如,用户点击联系人信息添加按钮,系统需要从联系人管理模块获取联系人密钥,然后获取联系人加解密策略,最后根据该策略将联系人信息中需要加密的字段加密处理并存储。
由于安卓系统并没有考虑联系人数据的加解密问题,因此,本文增加了一个名为encryptdata的数据表记录数据加解密状态信息。由于本方案为细粒度加密,系统需要维护数据库中每个字段的加密策略,因此encryptdata表和data表相对应,并通过字段的比特值表示加密状态,其中,1表示信息已加密。
4.2 短信管理模块
短信管理实现了加解密策略驱动下短信的接受、发送、删除和搜索的功能。在访问控制增强机制中,系统通过对短信的加解密来保证短信操作的安全性和机密性。用户通过策略管理机制制定短信加解密策略,并将安全管理策略存储在策略库中。
当设备接收到新短信时,短信管理模块会将其存储于短信数据库中。此时,对策略库的检索会被触发,系统会获取对应发件人的短信加密规则。系统成功验证用户的短信密钥后,会选择对该短信进行加密保存或者直接保存。同样,当用户在安卓设备上撰写新的短信并点击发送后,本模块会验证收件人是否属于短信加密列表,并进行加密储存。此外,针对密文的短信搜索和删除服务均需建立在验证密钥的前提下进行。
4.3 感知来源控制模块
感知来源控制模块在应用框架层对安卓设备的感知来源进行细粒度权限设置。本系统的感知来源控制模块主要实现了感知权限的状态设置和感知场景的新建、修改和删除的功能。
首先,用户进入感知权限设置界面设置感知权限状态。感知来源的状态可设置为开启或者关闭,且立即生效。其次,在预置场景中,用户可以新建、修改、删除感知场景。用户点击新建或修改按钮后,可在感知来源列表中设置感知来源的状态,并输入名称、保存该场景。此外,用户可直接选择相应的感知来源场景快捷地对系统的感知来源进行相应权限的保护。
应用程序访问感知设备,需要经过框架层、Linux内核层和设备驱动程序三个层次。因此,本系统要实现对感知设备的访问控制,可以在这三个层次中分别插入策略执行点。策略执行点截获应用程序访问感知设备的请求,向策略决策点请求访问决策(即允许或拒绝),并按收到的访问决策执行。
5 访问控制增强机制实现
5.1 策略管理机制
策略管理机制用于管理联系人和短信的加解密策略以及感知来源的控制策略,联系人和短信根据加解密策略选择明文或密文加载,感知设备也根据权限策略而设定是否可用。
策略文件包含policyset、policy、rule的三层结构。其中,前者元素可包含一至多条的后者元素,同时policyset可以内嵌零至多条的policyset。如图2所示为一个policy.xml的源文件,系统的策略编辑器通过操作策略文件完成对加密选项的选择。
用户通过策略编辑器选择对联系人、短信进行加密,选择后status发生改变,从初始状态0变为加密状态1。后台通过读取policy.xml中对应status值,选择对联系人、短信进行加密。这样的设计实现了基于场景的安全策略设置,降低了安卓用户敏感数据的访问控制策略设置的复杂度。
本文实现了系统中的联系人策略管理配置界面,用户可以选择将联系人的字段分别加密,生成策略文件。当用户存储联系人信息时,系统会查看当前的策略文件,对需要加密的字段进行加密并存储在本地数据库中。这样即使第三方应用获取了对联系人数据的访问权限,由于底层数据库中的数据是密文存储的,也只能获取到密文信息,通过这样的方式,可以避免隐私数据的泄露。
5.2 密钥管理机制
(1)初始化密钥
系统在初始化过程中,需要进行密钥初始化工作,以设置对联系人数据和短信数据进行加解密操作所需的系列密钥。
初始化安卓设备时,用户输入初始口令,密钥管理模块使用SHA-256算法对初始口令进行加密后保存,并生成相应加密密钥。此外,系统使用SHA-256算法加密初始口令、联系人特定字段和安卓设备号后取前128位作为联系人应用的密钥;使用SHA-256算法加密初始口令、短信特定字段、安卓设备号后后取前128位作为短信应用的密钥。
(2)信息加解密
在本系统中,联系人、短信加解密均使用AES算法。
在联系人信息管理模块中,用户在策略管理点制定联系人加解密策略,并存储在策略库中。当用户新建联系人并保存数据时,联系人模块会触发对策略库的检索,以获取联系人的加密规则。系统成功验证用户的联系人密钥后,依据加密规则加密联系人的数据,并将密文数据保存于联系人数据库中。同样,当用户试图查看联系人信息时,联系人模块触发对策略库的检索,获取联系人的加密规则,成功验证联系人密钥后,解密联系人的数据,并最终显示联系人的明文信息。
在短信管理模块中,用户在策略管理点制定短信加解密策略并存储在策略库中。当安卓设备接收到一条短信时,存储过程会触发对策略库的检索。系统获取发件人的短信加密规则,并成功验证用户的短信密钥后,会选择对该短信进行加密或者直接保存。同样,当用户试图查看短信箱内的短信时,短信模块会触发对策略库的检索,获取相应的加密规则。系统成功验证短信密钥后,会解密短信数据,并最终显示短信的明文信息。
5.3 感知来源控制的实现
(1)安卓应用框架层实现
针对感知设备的权限保护,本系统修改了权限检查模块,通过插入策略执行点,使得在权限检查时,合法的感知设备请求一律返回PERMISSION_DENIED参数。在本访问控制增强机制中,选择了在访问控制层进行感知设备的控制。这种做法具有实现复杂度低、覆盖全部API、兼容性强的优点。
具体实现如图3所示,通过在加入以下具有下划线的代码片,使得系统在检查名称为android.permission.CAMERA的权限时,一律返回PERMISSION_DENIED参数。
(2)安卓Linux内核层实现
感知来源的权限控制还可以通过Linux内核层实现。对Linux内核来说,应用程序在安装完成时会被分配一个唯一的用户ID,并以该用户ID运行。对于安卓系统权限,应用程序被授予后,其用户ID也被加入该权限的用户组。例如应用程序被授予CAMERA权限后,其用户ID就成为camera用户组的成员。在安卓应用框架层的访问控制机制中,粒度为整个外置存储设备,而在Linux内核层,普通文件的访问控制粒度为单个文件。因此,对大部分感知设备的访问,应用框架层由权限进行控制,Linux内核层则由用户ID和组ID机制进行控制,在两个层次的控制粒度都是对感知设备整体的访问。
SELinux(Security Enhanced Linux)为Linux内核提供了强制访问控制机制。SELinux对所有进程、对象和操作实施系统级的安全策略,并实现了策略指定和策略实施逻辑的分离。例如,一个具有标签app_t应用程序被授予访问具有的标签microphone_t麦克风的权限,策略管理模块会新建一条允许app_t读取和获得microphone_t属性的规则的策略,但不包括写入、删除和修改microphone_t的拥有者信息的权限。由于在SELinux中,默认情况下所有访问都被拒绝,没有策略规则显式允许访问microphone_t的应用程序将无法访问麦克风。
5.4 性能测试
(1)系统整体性能对比
针对本文所涉及的访问控制增强机制,本文将其和原生安卓系统进行了性能对比。对比测试环境为四核智能手机,内存13231.8 MB且RAM值为1872.1 MB。如表1所示,为原生安卓4.2.2系统和两种启动策略管理模块的系统的部分性能对比结果。表中分数为测试工具An Tu Tu的评分结果。由该对比可知,基于应用框架层的策略管理模块具有少量的性能优势。
(2)联系人模块性能横向对比
图4显示了策略模块启动前后,添加200、400、600、800条联系人信息得到的平均添加时间。其中,曲线1~4为启动了策略模块的结果,曲线5、6没有启动策略模块。每条曲线代表的实验场景如图4所示。
曲线1:策略模块启动,验证口令正确,添加一个包含完整联系人字段并且加密所有信息;
曲线2:策略模块启动,验证口令正确,添加一个只有一个字段的联系人并且加密该字段;
曲线3:策略模块启动,验证口令错误,添加一个包含完整联系人字段并且加密所有信息;
曲线4:策略模块启动,验证口令错误,添加一个只有一个字段的联系人并且加密该字段;
曲线5:未启动策略模块,添加一个完整字段的联系人;
曲线6:未启动策略模块,添加一个单个字段的联系人。
由图4可以得出以下结论:首先,从整体来看,启动策略模块后添加联系人的平均时间大于未启动策略模块所需要的时间。然后,在策略模块启动后,添加的联系人越多,平均消耗的时间越多,而未启动策略模块的情况下,添加联系人所需要的平均时间与联系人的数量无关。在启动策略模块的情况下,加密的字段越多,即联系人信息越复杂所消耗的平均时间越多。
在启动策略模块后,针对联系人信息的加密,系统会执行以下四步操作:验证用户是否持有密钥;加密;储存加密特征;储存联系人。因此,对比未启动策略模块的情况,额外的时间开销来自前三步,这与图4中的实验结果相吻合。此外,由于本文在数据库中额外添加了表格记录联系人字段加密信息。随着系统中的联系人增加,数据库操作所需的时间也会增加,故曲线1~4中平均消耗时间随着添加联系人的增加而增加。
(3)短信模块性能横向对比
表2列出了在策略管理模块启动前后发送一定条数的短信所消耗时间的对比。该时间从用户按下发送按钮到短信在数据库插入一条记录并进入发送服务计算而得。可以看出,安全策略模块启动前后对短信模块的性能也无明显的影响。因此安卓系统访问控制增强机制保证了短信模块的性能。
(4)感知源状态控制性能评测
本实验中,我们在豌豆荚上分别以“照相机”和“录音机”为关键字进行搜索,选取搜索结果中的前20个应用进行实验,以测试感知源访问拦截率。我们在启用了本文设计的访问控制增强机制的设备上安装并运行这些应用程序。同时制定阻止应用程序访问感知设备的策略,并执行这些应用程序的主要功能,观察和分析应用程序对感知设备的访问是否阻止,计算拦截各种感知设备的应用程序的成功率和应用程序崩溃率。
从表3可以看出,应用框架层的感知源状态控制能完全阻止应用程序对麦克风的访问,但是有10%的应用程序能绕过控制访问摄像头。基于Linux内核层的感知源状态控制能同时完全阻止应用程序对麦克风和摄像头的访问。同时,两者的应用程序崩溃率都在可以接受的范围之内。
6 结语
本文设计并实现了一种基于安卓系统的访问控制增强机制。该机制能够为用户提供敏感数据如联系人、短信等信息的细粒度保护,解决安全存储问题,同时通过对安卓权限的访问控制实现对感知源的安全控制。最后,本文通过对比实验验证了加解密模块对系统性能造成的时间开销在用户的可接受范围内,同时也验证了对感知源的访问控制增强机制的有效性。
然而,虽然本文设计实现的安卓访问控制增强机制能有效的防止隐私数据的泄露问题,但在日益增加的用户体验需求和日益复杂的安卓威胁下,本文提出的方案仍有不足之处。在未来,首先我们希望提供一个更加友好的方式以处理安全性和易用性上的平衡关系。然后我们希望在感知源数据保护的应用程序崩溃问题上有所改善。最后我们希望在下一步工作中将密钥的存储位置从本地文件中转移到更为安全的存储位置。
摘要：安卓设备中的敏感数据和感知能力面临严重安全威胁。现有的安全机制主要从应用层实施粗粒度访问控制,无法有效保护用户敏感数据和设备感知能力。为此,提出基于密码学和细粒度安全策略驱动的安卓敏感数据和能力访问控制增强机制。首先,结合密钥管理和细粒度加密策略,利用高强度对称加密算法对敏感数据进行加密,解决敏感数据的安全存储问题;其次,应用基于细粒度安全策略的访问控制机制,从安卓平台层控制感知能力的访问权限,实现感知数据保护的目的。通过原型系统和性能测试,提出的安卓敏感数据和能力的访问控制增强机制可以运行在当前安卓平台上,并且性能是可接受的。
访问控制机制 篇7
随着信息技术与网络技术的高速发展, 给人们的工作和日常生活带来便利的同时也带来了大量的安全隐患。对数据的及时性与安全性要求很高的医院信息系统, 面对日益猖獗的病毒与木马以及各种网络攻击手段, 内网的安全性和可靠性是急需解决的问题。
传统的基于RBAC模型[4]的网络访问控制技术在可靠性、易用性、高效性等方面表现出色, 但是在动态调整的灵活性方面出现了不足, 主要表现在以下两个方面: (1) RBAC模型建立在主体-客体访问控制思想上, 采用静态授权方式, 缺乏对角色权限的动态调整能力。 (2) 访问控制策略必须人工定义, 不能根据网络状态的变化进行自增学习。
针对以上的问题, 本文参考了基于行为的网络访问控制技术 (Behavior-Based Network Access Control, BB-NAC) [2,3]的思想, 提出了RB-NAC机制, 其核心思想是建立角色模型来划定权限集, 建立行为簇来动态调整用户权限。RB-NAC弥补了RBAC-based NAC的缺陷, 并加强了对用户实时行为的监控。
二、基于角色与行为的访问控制机制 (RB-NAC) 2.1 RB-NAC的访问控制策略
RB-NAC核心思想是以角色模型来划定权限集, 利用行为簇来动态调整用户可使用的权限, 其体系结构如图1所示。
RB-NAC的访问控制策略主要包括两部分内容: (1) 建立角色访问控制模型 (2) 建立行为簇动态调整用户的权限范围。
1. 建立角色模型主要包括:
定义系统角色, 为角色分配权限, 为用户分配适当的角色。这些操作可以由高级管理员或者某些合适的代理角色来完成。可以利用现有的RBAC模型及其改进版本 (例如ARBAC97) 来建立RB-NAC中的角色模型。RB-NAC具有很强的扩展性, 现有的RBAC-based NAC经过修改后可以很容易的扩展成RB-NAC。
2. 建立行为簇, 根据用户的网络行为动态决定用户可使用的权限, 主要包含三个部分:
分簇[1,5]、计算阈值、动态调整。
(1) 分簇:为每个角色建立簇组, 并为每个簇分配适合的权限。例如, 在角色r中, 其权限集合记为Q, 为角色r建立4个行为簇, 分别标记为c1, c2, c3, c4, 并为每个簇分配适当的权限记为q1, q2, q3, q4, 且每个行为簇都对应一组相似的用户行为特征。每个用户根据其网络行为特征被分配到适当的簇中, 并具有该簇的权限。簇的划分策略, 即用户的行为特征与簇的对应关系可以根据不同的需求来设计。
在准备阶段, 系统需要收集用户的网络行为信息作为动态归簇的依据, 这些信息被称之为行为档案 (behavior profiles) , 简称为BP。BP中包含的是一系列的网络行为的特征值, 例如, 针对80端口的行为的特征值可以是连接不同IPs的总数量、数据包的总数、每个数据流的大小等等。将每个接入设备的BP用一个矢量pi来代表:pi={pi[0], pi[1], …pi[n]}, 其中每个pi[l]代表特征l的平均值l=0..n。系统在准备阶段采集足够多的样本数据, 分布在各个簇中并作为系统的初始数据使用。
(2) 计算阈值:完成分簇之后就获得了簇的信息以及每个簇中的样本数据, NAC的执行点开始计算每个设备的阈值。阈值代表每个设备与同簇中的其他设备之间的最大距离, 如图2所示。在RB-NAC中使用BP代表设备计算阈值, 这些阈值在之后的动态访问控制中起到至关重要的作用。对于每个pi来说, 其阈值的计算公式如下所示:
pi与pj代表两个BP, n代表特征值的数量。公式1用来计算pi与pj之间的距离, 也就是pi与pj之间的相似度。公式2用来计算每个pi的阈值, q代表pi所属的簇中的BP的个数, d代表使用公式1所计算出来的pi, pj之间的距离。
(3) 动态访问控制
完成分簇与计算阈值的工作之后, 系统进入动态访问控制阶段。动态访问控制主要处理两类设备, 一类是新设备 (未提交BP) , 另一类是存量设备 (已提交BP) 。新设备刚进入时系统还无法获知其BP的信息, 可以在簇组中设置一个通用簇用来做过度之用。系统在后续的权限使用过程中, 将新设备的行为特征记下, 并在适当的时候提交BP, 然后分析归簇。进行归簇时, NAC的执行点用公式3计算与新设备的BP最接近的簇 (如图3所示) 。
公式3
其中k代表簇中BP的数目, pnew代表新设备的BP, c[i]代表每个簇i的中心, c[i]的计算过程如公式4所示:
其中cn代表第n个特征值的平均数, q代表簇i中BP的数量。
选出最近的簇之后, 由簇中的所有成员进行投票表决是否接受新设备加入到网络中, 如图3所示。投票的结果决定是否同意让新成员加入。投票的方法按照公式5进行:
其中, q代表簇中成员的个数, ti是pi的阈值 (由之前计算得到) 。v代表投票的结果值, 如果系统要求簇中至少60%的成员投赞成票才允许新设备进入, 则v必须大于0.6。对于存量设备, 当设备经过一段时间后其BP可能发生变化, 这时系统将更新之后的BP提交给NAC执行点, 由NAC执行点通过公式3~5对其进行归簇计算。
2.2增量学习
RB-NAC主要针对访问设备行为信息 (即BP) 进行增量学习。对于新设备, 还未提交BP不能参与簇内的投票, 只有当其提交BP并执行归簇之后才能参与投票。新设备的BP自动添加到所属的簇中, 更新簇的BP集合。对于存量设备, 当其BP信息发生改变时需要重新进行归簇计算, 将旧的BP从原来的簇中删除, 并将更新后的BP添加到新簇的BP集合中。RB-NAC采用增量学习的方式自动对动态归簇策略进行调整已符合当前网络的状态, 提高了系统的灵活性与可靠性。
三、应用实例分析
医院内部某用户拥有对服务器资源进行各种业务操作的权限, 然而在某个阶段, 该用户的设备因感染了病毒而对服务器发起大量的恶意行为, 此时RB-NAC系统检测并发现此攻击行为, 根据其行为的特征将其划分到特定的簇中 (例如簇A) , 由于处于簇A中的设备被限定了一部分的核心权限 (比如访问网络的权限) , 因而可以有效的控制住该设备试图造成的危害, 同时簇A中还保留了该设备其他一部分权限, 在控制用户的异常行为的同时还适当保留了用户的一些基本操作权限。依据用户的行为在簇组内做动态调整从而分配或限制用户的权限, 这种设计方案使得权限随着网络行为的安全等级做动态调整, 提高了系统的灵活性。
四、总结
本文提出了一种基于角色与行为的访问控制机制:RB-NAC机制, 其核心思想是以角色模型来划定权限集, 利用行为簇来动态调整用户可使用的权限, 克服了RBAC-based NAC在动态权限调整方面的缺陷。RB-NAC利用行为簇分配或限制了用户的权限, 并利用用户实时的网络行为特征的变化, 对用户进行动态归簇, 提高了系统的灵活性。此外RB-NAC还能自动完成增量学习, 无需人工干预就能适应多变的网络环境。综上所述RB_NAC机制能有效的加强医院内网的安全性与可靠性。
参考文献
[1]许春根, 黄生, 一种新型的基于角色访问控制的角色管理, 计算机工程, 2003, 29 (8) :26-29
[2]V.Frias-Martinez, S.Stolfo, and A.Keromytis, “Behav-ior-based network access control:A proof-of-concept, ”in Infor-mation Security Conference (ISC) , 2008.
[3]Vanessa Frias-Martinez, Joseph Sherrick, Salvatore J.Stolfo, Angelos D.Keromytis, “A network access control mechanism basedon behavior profiles”, in Annual Computer Security ApplicationsConference (ACSAC) , 2009.
[4]Sandhu R, Coyne E, Feinstein H, et a1.Role-based accesscontrol model[s J].IEEE Computer, 1996, 29 (2) :38—47.
访问控制机制 篇8
1 探讨数据库安全访问控制机制的重要性
随着数据库技术的广泛应用, 数据库的安全越来越受到重视。数据库技术引起了世界范围内的普遍关注, 数据库安全问题也是人们比较关心的问题之一。要想保障数据库的安全有效, 就必须建立数据库安全访问控制机制。数据库的安全访问能够保障数据信息的安全有效, 起着十分重要的作用, 保障数据信息的完整性和保密性。在保护计算机数据信息的安全工作中, 需要设置防卫权限, 控制访问主体对访问客体使用的访问权限。访问机制能够保障和代表用户的利益, 在很大程度上保障数据信息的安全性。
2 不同种类的数据库安全访问控制
数据库安全运行是在保障信息的安全性, 数据库的安全需要引入访问控制机制, 借助控制手段对以下几种行为进行控制, 这些行为有发起网络连接、运行可执行文件、读取数据等等。
当前, 从研究中发现, 存在的访问控制机制主要有以下几种类型:
2.1 强制访问控制
强制访问控制称为MAC。数据管理员负责具体的工作, 提供一种共享服务, 实现主体和客体资源的共享, 系统的安全决策很大程度上影响安全性。不可否认, DAC在体统当中, 是其组成的一部分, 但是并不拥有决定权, 决定权取决于客体的拥有者。从原则立场出发, 系统安全管理员并没有干预授权的转让和传递的权利。可能的一种情况:客体的拥有者会改变DAC的方式, 当时客体的MAC方式不能被客体的拥有者改变。MAC方式的发展, 有一定的构建模型, 这种模型是BLP模型, 主体有安全级, 客体同样有安全级, 安全级元素一个是密级, 另一个是范围。客体的安全级代表客体涉及的信息, 主体的可信度能够在主体的安全级中得到体现。在安全访问控制过程中, 需要遵循两个规则:不能上读规则和不能下读规则。不能上读规则:在主体支配范围之内, 主体方能读客体。另外一种需要遵循的原则:不能下读:主体所写的安全级别的客体也是处于其安全级别支配之下的。在安全等级的基础之上, MAC实施访问控制, 面临病毒的挑战, 能够有效避免攻击。
2.2 自主访问控制
自主访问控制又称DAC, 认同客体和主体之间的关系, 在此基础上生成的一种访问控制机制。只要具备了这个基础性条件, 主体能够拥有客体的所有访问特权, 另外, 主体还可以通过转让的方式将这些权限的全部或者部分给转让出去。当主体需要对其它用户访问的时候, 需要通过搜索检查的方式才能实现。
2.3 基于角色访问控制
Ravi Sandu最早提出基于角色的访问控制, 是美国著名的大学教授。面临很多复杂的问题, 该机制能够有效进行解决。基于角色访问控制机制设计概念较多, 不仅有角色、许可, 而且还有会话、用户。其中, 访问权的集合是角色。当用户拥有某个角色时候, 同时也具备了该角色所有的访问权。用户和角色之间存在一种关系, 确切的说是一种多对多的关系, 当然, 角色和许可之间也是这种关系。一旦进入RBAC构建模式, 用户将面临一场对话, 激活其中一个角色, 用户激活角色后, 获得了访问权。角色激活是访问控制实现最大优势, 最小特权原则能够轻松实现。应用层下角色有直接和明显的逻辑意义, RBAC是一种比较理性的安全模型, 能够很好的应用到数据库层面。
3 数据库的安全访问控制机制优缺点
自主访问控制策略, 又简称为DAC, 有较早的数据库系统访问控制时间。在自主访问控制中, 该控制策略是一种比较常见的系统访问控制策略。但是不可否认, 在使用过程中, 自身存在一定缺陷:数据资源不能实现有效管理, 数据信息比较分散;不能将用户间的关系很好体现出来, 管理工作相当困难, 有最为突出的一个缺陷, 就是无法对系统中的数据信息实行很好的保护, 导致数据信息暴露出来, 面临来自病毒的威胁, 变得束手无策。针对以上出现的问题, 强制访问控制系统, 能够很好的解决这些突出的问题, 但是同样也存在一定缺陷, 有狭窄的应用领域, 具体的控制过程中, 无法保障完整性。当前有一种控制方式是比较先进的-基于角色的控制访问, 该访问技术和策略没有必然, 具备自我管理能力。其中有一点缺陷是值得注意的, 目前, 该技术尚未成熟, 处于发展阶段。
4 前景眺望
社会在前进过程中, 技术相互交融和渗透现象较为普遍, 也是一种发展趋势。其中, 网络通讯技术和数据库机制之间的渗透、融合就是这种情形。相对过去, 用户对数据库的安全提出了更高要求, 同时, 面临许多突出性问题, 数据库安全问题一直是一个十分重要的话题。数据库安全访问机制在未来发展过程中, 将会朝着以下拓展性方向发展, DAC的授权表示能力竟会进一步拓展, 实现描述安全策略语言的开发的通用性, 保障DAC能够担负各种安全策略问题, 在进一步的研究和应用过程中, RBAC将会使用到实际中的DBMS。不可否认, 目前存在的一种状况是:基于角色策略下的DBMS, 没有实现对RBAC潜力的开发, 需要注意:分离角色需求能够在角色策略中得到解决, 但是, DBMS并未做到这一点。
5 结束语
计算机技术与网络技术的发展, 使数据库系统广泛的应用于企业管理、政府办公以及军事等多个领域。数据表明:数据库的安全问题需要被重视起来。网络技术发展迅速, 网络数据库安全机制出现了新问题。在新情况下, 研究者在研究数据库的时候, 需要重新树立研究工作的重要性意识, 确保在改变传统技术的基础上, 开展数据库安全机制研究问题。从宏观视域上来看, 出现的新问题需要我们根据实际需要, 拓宽我们的思维, 实现技术的创新性突破。
摘要：信息技术发展取得了突破性发展, 数据库技术具有宽广的使用范围, 人们普遍担忧数据库的安全问题关注。文章主要探讨了数据库的安全访问控制机制和各自的优缺点, 对访问控制机制未来的发展方向提出了指导性见解。
关键词：数据库,安全访问控制机制,优缺点
参考文献
[1]赵登峰, 许英杰, 王诤.浅析数据库的安全访问控制机制[J].价值工程, 2014, (33) :225-226.
访问控制机制 篇9
随着Internet技术的不断发展, Web应用系统开发技术也得到了进一步地发展, 这类系统通常采用Browser/Server方式实现对Web数`据库服务器的访问, 而访问数据库的关键技术就是数据访问接口。在不同的Web环境下, 操作数据库的技术有所不同, 具有代表性的有:CGI、JDBC、ASP等。
其中ASP技术通过ADO数据访问接口可以很方便地与数据库建立连接, 并操纵数据库, 开发者能够比较容易地开发出功能强大的数据库应用程序, 只是A-DO的连接传输模式性能较低, 尤其同时对多用户连接时, 服务器负载很重。
在.NET技术产生后, 微软为了克服ADO的不足, 随即推出了ADO.NET, 这种非连接传输模式, 只有在需要取得数据或更改数据时才需要与数据源进行连接, 应用程序所要管理的连接数减少, 服务器负载大大减轻了, 运行效率也大大提高了。
1、ADO.NET的结构
ADO.NET是一组用于和数据源进行交互的面向对象类库, 数据源可以是数据库, 也可以是文本文件、Excel表格或者XML文件, 应用程序可以使用ADO.NET来连接数据源, 并检索、处理和更新所包含的数据。
ADO.NET对象可分为两类, 一类是联机对象 (与数据直接连接) , 包括Command对象、DataReader对象、DataAdapter对象等, 借助于这些对象可以连接数据源或者进行数据维护等相关操作;另一类是与数据源无关的对象, 如DataSet对象。对象模型如图1所示。
DataSet对象是ADO.NET非连接结构的核心组件, 设计该对象的目的是为了实现独立于数据源的访问, 用于多种不同的数据访问, 用于XML数据或管理应用程序本地数据等。DataSet中还包括一个或多个DataTable对象的集合, 这些对象由数据行和数据列组成, 也包括主键、外键、约束和有关的数据关系信息等。
ADO.NET结构的另一个核心是.NET Framework数据提供程序, 是一组包括Connection对象、Command对象、DataReader对象和DataAdapter对象在内的组件, 其设计目的是为了实现数据的存取、修改、更新等操作。
ADO.NET集合了所有允许数据处理的类, 这些类表示具有典型数据库功能的数据容器对象, 其结构图如图2所示。
2、ADO.NET的数据访问机制
从ADO.NET结构分析来看, 我们知道对数据访问的形式有两类:一种是联机模式, 利用DataReader对象来实现对数据的只读访问;另一种是非联机模式, 利用DataSet对象来实现对数据的各类操作。下面我们将基于VB语言为基础, 以对学生信息进行访问为例, 来分析这两种模式的数据访问机制。
2.1 联机模式
在这类模式下, 客户机一直保持与数据库服务器的连接, 这和ADO技术是一致的。它利用DataReader对象从数据源中提取高性能的数据流。其数据访问步骤如下:
(1) 导入命名空间System.Data.OleDb。 (DataReader封装在该命名空间内)
(2) 使用Connection对象连接数据库。
(3) 使用Command (命令) 对象向数据库索取数据。
(4) 把取回来的数据放在DataReader (数据阅读器) 对象中进行读取。
(5) 关闭对象。
提示:ADO.NET的联机模式只能返回向前的、只读的数据, 这是因为DataReader对象的特性决定的。
访问学生信息的代码如下:
2.2 非联机模式
这类模式的数据访问, 只有当进行数据库读写时才需与服务器联机, 其它操作都可在断开联机状态下进行。它利用DataSet对象实现数据源在内存中的映射, 增、删、改、查、排序等操作均可在内存中进行。其数据访问步骤可从如下学生信息访问代码中获知:
注:以上在调用DataAdapter的fill方法时, 该方法将隐式调用数据连接的Open方法, 填充完毕后会自动关闭。
2.3 两种机制性能分析
联机模式的数据访问是利用DataReader对象从数据源中提供只读的向前的高性能的数据流, 用以快速检索查询所返回的行, DataReader支持最小特性集, 所以速度非常快[3]。这种方式对数据库的操作必须是在与数据库连接的状态下, 在网络程序设计和Web应用系统中, 使用这种技术显然是存在着问题, 当网络上有成千上万的用户需要对数据库操作时, 服务器的负载是相当重的, 长时间地打开数据库也是不安全的。
而非联机模式的数据访问是利用DataSet对象实现数据源在内存中的映射, 其各类数据操作对象是本机内存中的数据。这种非联机的“断开”结构体系使得只有在读写数据库时才需要使用数据库服务器资源, 因而提供了更好的可伸缩性, 有效地避免了由于活动连接过多而千万的数据库堵塞和网络资源的浪费。
3、结束语
综上分析, ADO.NET的两种数据访问机制各有千秋, 不能一概而论, 应视具体情况而定。对于联机模式的访问在创建Web页或XML Web服务时尤为有用, 而对于多用户在进行数据库的批量操作时, 非联机模式体现出了它的优越性。
摘要：本文在介绍了ADO.NET的体系结构的基础上, 以访问学生信息为例阐述了ADO.NET的两种数据访问模式, 并对两种机制进行了性能分析。
关键词：ADO.NET,数据库,访问机制
参考文献
[1]王磊.基于.NET平台的数据库访问技术[J].福建电脑, 2006年第12期 (71)
[2]于训全, 于晓冬.基于ADO.NET的数据库访问技术研究与应用[J].企业技术开发, 2006年1月 (3~5)