访问安全性

访问安全性（精选12篇）

访问安全性 篇1

一、引言

.NET中运行代码的时候，必须有公共语言运行库（CLR）的支持，公共语言运行库允许代码仅执行它有权执行的操作。每种以公共语言运行库为目标的应用程序都必须与运行库的安全系统进行交互。基于代码访问安全CAS (Code Access Security）：是在.NET Framework中提出的一种新的安全机制。CAS主要根据代码的证据，计算和确定该代码的权限，分配给代码相应的权限，从而允许和拒绝代码的运行和操作，整个过程与代码运行的用户和角色无关。相对于过去Windows基于身份（Identity）和角色（Role）的安全机制，安全控制更加的细腻和完善，安全性得到了大大增强。

二、代码访问安全运行机制

在.NET Framework中，代码访问安全性执行下列功能：

·定义权限和权限集，它们表示访问各种系统资源的权限。

·使管理员能够通过将权限集与代码组关联来配置安全策略。

·使代码能够请求运行所需权限以及其他一些有用的权限，以及指定代码绝对不能拥有哪些权限。

·根据代码请求的权限和安全策略允许的操作，向加载的每个程序集授予权限。

·使代码能够要求其调用方拥有特定的权限。

·使代码能够要求其调用方拥有数字签名，从而只允许特定组织或特定站点的调用方来调用受保护的代码。

代码访问安全运行机制流程如图一所示，关键处理过程如下。

证据收集:.NET Framework在编译程序的时候，把程序集的证据（Evidence类）写入到程序集清单中，证据是关于程序集的信息，用来描述程序集的标识和来源，主要包括主机证据和程序集证据。当加载程序集的时候，CLR收集程序集的证据。

计算允许的权限集：获取程序集的证据后，CLR根据Framework安全策略（PolicyStatement）分配该程序集允许的权限。安全策略是用来定义并配置管理不同程序集的权限规则。

程序集请求权限:代码通知运行库在此范围内运行它所需的权限或者具体不需要哪些权限。运行库会在代码加载到内存中时计算安全请求。请求不会使运行库给予代码的权限大于您不请求时运行库给予代码的权限。但是，代码需要使用请求来通知运行库运行它所需的权限。

是否授予权限：如果代码请求的权限不存在，则代码的权限就是通过安全策略计算出来的权限。如果存在，则求出代码请求的权限和计算的允许权限的交集作为代码授予的最终权限。当在执行特定操作的时候，CLR根据代码的权限确定是否能够正常运行。

三、权限

公共语言运行库允许代码仅执行它有权执行的操作。运行库使用称为权限的对象来实现其在托管代码上强制限制的机制。权限是一种对象，它授权对资源执行操作的权利。在.Ne Framework中权限通常存储在PermissionSet的集合类中，该集合中保存各种类型的Pvermission对象。

权限的基本抽象是IPermission接口，它要求特定的权限类型实现一组标准的权限操作，如返回与具有相同权限类型的其他权限实例的联合或子集。CodeAccessPermission类作为定义和管理权限的基类。每种代码访问权限均从CodeAccessPermission类派生，这意味着所有代码访问权限都具有通用方法，如Demand、Assert、Deny、PermitOnly、IsSubsetOf、Intersect和Union。

四、权限的请求

请求权限是您让运行库知道需要允许代码执行哪些操作的方法。应通过将属性放到代码的程序集范围内来为程序集请求权限。创建程序集后，语言编译器将请求的权限存储在程序集清单中。加载时，运行库检查权限请求，并应用安全策略规则来确定授予程序集哪些权限。请求只会促使运行库拒绝将权限给予代码，而永远不会促使运行库将更多权限给予代码。授予您的代码的最大权限最终总是由本地管理策略来控制。

请求权限会通知运行库应用程序正常运行需要哪些权限，或具体不需要哪些权限。如果代码不访问受保护的资源或执行受保护的操作，则不必请求任何权限。如果代码访问受保护的资源但未请求必要的权限，则仍可能允许它执行，但如果它尝试访问某种资源而它没有必要的权限，则可能在执行过程中某一处失败。所以若要请求权限，必须知道代码将使用哪些资源和受保护的操作，而且还需要知道哪些权限保护着这些资源和操作。

下面的代码段说明声明式语法，该语法用于请求代码的调用方拥有名为MyPermission的自定义权限。此权限是假设的自定义权限，在.NET Framework中并不存在。声明式调用直接放在类定义之前，指定将此权限应用到类级别。向该属性传递一个SecurityAction.Demand结构来指定调用方必须拥有此权限才能运行。

五、权限的要求

权限的要求可以出现在代码中的任何位置，通常位于方法级别，作为一种确保代码具有足够的权限来完成特定任务的方法。若要确保只有被授予了指定权限的调用方才能够调用您的代码，可以声明方式或强制方式要求您的代码的调用方拥有特定的权限或权限集。要求使运行库执行安全检查，从而对调用代码实施限制。在进行安全调用前，必须初始化权限对象的状态数据，使之表示您需要的特定形式的权限。下面的代码段说明请求代码的调用方拥有名为MyPermission的自定义权限。

六、安全策略

安全策略是一组可配置的规则，公共语言运行库在决定允许代码执行的操作时遵循此规则。安全策略由管理员设置，并由运行库强制。管理员可以通过.Net Framework配置工具、caspol exe工具和SecurityManager类配置安全策略。安全策略有四个策略级别：企业、计算机、用户，应用程序域。每个安全策略级别均有自己的代码组的层次结构，该层次结构为建立和配置安全策略提供基础结构。代码组将证据映射到允许的权限集。当评估程序集权限时，运行库将从该层次结构的顶部启动依次向下运行。

七、小结

通过对.NET Framework中代码访问安全技术的研究，深入解析了公共语言运行库如果控制代码访问的权限，给出了如何管理和定制CAS。从中可以看出，通过CAS可以方便灵活的控制代码对资源的访问和操作，从而增强的应用程序的健壮性和安全性。

参考文献

[1]微软公司。.NET Framework程序设计.北京:高等教育出版社, 2007

[2]Andrew Krowczyk, Vinod Kumar..NET网络高级编程.北京:清华大学出版社, 2003

[3]Kevin Hoffman。ASP.NET电子商务高级编程序.北京:清华大学出版社, 2003

访问安全性 篇2

在windows平台下，应用程序通常使用API函数来进行文件访问，创建，打开，读写文件，从kernel32的CreateFile/

ReadFile/WriteFile函数，到本地系统服务，再到FileSystem及其FilterDriver，经历了很多层次。在每个层次上，都存在着安全防护软件，病毒或者后门作监视或者过滤的机会。作为安全产品开发者，我们需要比别人走得更远，因此我们需要一个底层的“windows平台内核级文件访问”的方法来确保我们能够看到正确的干净的文件系统。

直接访问FSD的内核级别文件访问

FSD(FileSystemDriver)层是文件API函数经过本地系统服务层(native API)最后到达的驱动层次。如果我们可以模仿操作系统，在我们自己的驱动程序里直接向FSD发送IRP，就可以绕过那些native API 和win32 API了，也就可以绕过设置在这些层次上面的API钩子等监控措施。

文件的Create和Open

文件的Create和Open可以通过发送IRP_MJ_CREATE给FSD，或者调用IoCreateFile函数来完成。Create和Open的区别实际上在于IoCreateFile/IRP_MJ_CREATE的一个参数Disposition的取值。

通过发送IRP_MJ_CREATE给FSD的方法与此类似，可以参考IFSDDK document的IRP_MJ_CREATE说明。不同于上面方法的是需要自己创建一个FILE_OBJECT，好于上面方法的是这种方法不需要一个HANDLE，HANDLE是线程依赖的,FileObject则是线程无关。

文件的Read和Write

我们通过给FSD发送IRP_MJ_READ来读取文件，给FSD发送IRP_MJ_WRITE来改写文件。

如果我们是通过一个HANDLE来执行(如使用IoCreateFile打开的文件)，就要先用ObReferenceObjectByHandle函数来获得这个Handle对应的FileObject。我们只能给FileObject发送IRP。

之后我们使用IoAllocateIrp分配一个IRP。根据FileObject->DeviceObject->Flags的值，我们判断目标文件系统使用什么样的IO方式。

对每种不同的IO方式使用不同的地址传递方式。随后我们填充IRP内的各个参数域，就可以发送IRP了。

接着要考虑如果IRP不能及时完成，会异步的返回的情况，我们安装一个CompletionRoutine，在CompletionRoutine里面设置一个事件为已激活，通知我们的主线程读取或者写入操作已经完成。

现在可以发送IRP了。如果不采取特殊的措施的话，IRP发送目标是FileObject对应的DeviceObject。发送后，等待IRP的完成并且释放资源，返回。

文件的Delete

Delete实际上是通过向FSD发送IRP_MJ_SET_INFORMATION的IRP，并把IrpSp->Parameters.SetFile.FileInformationClass设置为FileDispositionInformation，用一个FILE_DISPOSITION_INFORMATION结构填充buffer来执行的。

文件的Rename

类似于Delete，Rename是向FSD发送IRP_MJ_SET_INFORMATION的IRP，把IrpSp->Parameters.SetFile.FileInformationClass设置为FileRenameInformation，填充buffer为FILE_RENAME_INFORMATION结构，

综上，于是我们可以在驱动里面通过发送IRP来直接访问文件系统了，绕过了native API 和win32 API层次。

绕过文件系统过滤驱动和钩子

有了以上的内容，我们目前可以直接给FSD发送请求操作文件。但是这还不够，因为有很多的杀毒软件或者监视工具使用FSD Filter Driver或者FSD H

访问安全性 篇3

关键词：分布式网络安全；访问控制；智能客户端；安全通信

0引言

智能客户端一种可扩展的、不同应用可以集成的桌面应用程序。它可以无接触部署、即需即装、动态加载，XCopy可运行而无须修改注册表．可以动态升级、自动更新，可以方便地经Web运行而不用担心防火墙问题，并可以方便地离线运用，方便地连接Web Services应用。

智能客户端是分布式应用，通常跨越多种不同的产品和技术。组成应用程序的各组件通常来自于完全不同的组织。所以应用程序的不同组件可能要求不同的信任度。用组件动态组成的系统具有独特的安全需求。针对这种安全需求，有人提出了多种改进模型，试图在分布式环境下实现传统的角色访问控制M，但这些方案大多有以下缺陷：

(1)无法解决引诱攻击问题。来自被信任组织的组件可能需要访问敏感资源，而这些资源正常情况下需要得到保护以防止恶意代码访问。引诱攻击经常通过欺骗受信任的代码组件对敏感资源进行调用，或以低信任度组件调用高信任度组件的方式来获得合法代码的权限，以此访问敏感资源。

(2)角色分配困难。有的代码，例如可移动代码，可以由任意数量的用户下载和执行，这些用户的身份无法判断，角色也就无从分配。

智能客户端将逻辑和数据分布到客户端计算机，因此需要考虑的安全性和与瘦客户端应用程序相关的安全性是不同的，后者的数据和逻辑更多地被限制到服务器。本文讨论智能客户端应用程序中的数据安全性、身份验证、授权，并系统地提出了代码访问的权限解析、安全设计方案，从较低的代码层次和用户角色层次上进行访问控制。

通用数据安全访问模型 篇4

本文提出了一种通用数据安全访问的模型CDSA, 它实现数据的抽象访问与同步, 帮助工程师们管理好系统软件的数据, 保持数据的一致性和完整性。基于此模型可以实现远程过程调用 (RPC) , 其机制、原理和标准的RPC调用以及分布式计算原理完全相同, 不同之处在于这种调用方式可用于跨进程、跨系统、跨计算机边界、跨平台等复杂的环境中。

1 通用数据安全访问模型

首先, CDSA模型把各种系统软件对公用数据的访问划分为高级访问 (调用者需要理解数据以及各参数和返回的含义) 和原始访问 (调用者无需理解数据以及各参数和返回的含义) 。高级访问针对数据应用, 原始访问针对数据传递过程。

(1) 原始接口:输入和输出为数据流, 不理解协议本身以及任何应用数据结构, 供通讯使用。

(2) 高级接口:输入和输出为实际应用数据, 理解协议本身以及应用数据结构, 供业务使用。

其次, 考虑到一般的系统软件中数据的传递过程分为进程组内部数据传送 (交换) 和远程数据交换, CDSA模型规定进程组内的数据传送通过消息队列进行通讯, 在进程组外的数据传送, 主要通过SOCKET进行通讯。CDSA模型还约定这两种数据传输均通过原始模式进行, 不需要理解数据的含义以及输入和返回。

(1) 对于本地应用进程 (服务器进程) , 通过消息队列和主进程进行通讯, 达到数据读写的目的。为什么这样处理呢?主要是因为CDSA模型支持保存复杂的数据结构, 而共享内存只能适用于简单的数据结构, 如果采用复杂数据结构, 必须实现空间管理, 这非常复杂且可移植性不强。

(2) 对于其他进程, CDSA选用SOCKET作为通讯的手段, 通过抽象和复用代码等方法完成完整的数据通讯和交换过程。既达到RPC的效果, 又降低系统复杂程度, 同时满足了高效数据通讯的需求。

(3) CDSA模型规定, 服务器启动后, 主进程负责将全部的数据加载到内存, 主进程有义务通过消息队列或SOCKET等方式为其他服务进程 (包括远程管理进程、客户端进程) 提供数据共享, 并惟一直接操作数据库, 以维持数据的统一性。

(4) 如果系统软件有独立的远程管理进程, 由于多次远程读取数据需要耗费大量的带宽和时间, 所以CDSA模型规定管理端进程与服务端连接后, 首先下载并且维护一份和远程服务端一致的数据, 如此一方面保证本地数据和服务器数据的一致性, 一方面降低数据读取的消耗。

(5) CDSA为了保证数据的一致性, 采用了读取共享、写入独占的方式。具体来说, 本地应用进程在系统启动后自动获取数据库的修改权限, 第一个连接进入的管理进程可以抢占该写入权限, 直到该进程退出后, 如果系统中已经存在有一个管理连接, 后连接进入的进程将只能获取读取的权限, 并不能剥夺第一个管理进程的写入权限。

最后, CDSA模型定义数据访问的触发 (回调) 机制, 用于在设置变更或读取的状态下做出某种响应 (如配置系统、数据同步传递、数据重读、数据更新等) 。

2 CDSA模型的实现

CDSA模型存取的数据可以是数据库, 可以是配置文件、系统环境等。对数据库的操作没有定义专门类, 需要各系统软件自行考虑。对配置文件、系统环境等的存取, CDSA模型定义了实现IBoot DBIPlugin接口的Csvr Cfgtor类。通过这个专门类去处理实际的数据存取, 该专门类还支持调用IAdvBootDBI接口, 以便远程重新获取数据、远程修正数据。

CDSA模型还定义了两个实现IRaw Boot DBI或者IAdv BootDBI接口的类, 用于完成对数据的存储和数据格式的转换。

(1) 数据直接访问类

完成数据的直接访问, 对数据库进行直接操作, 通过IBoot DBIPlugin接口调用Csvr Cfgtor类来完成数据的存储以及存储的事件通知。

该类实现了IRawBootDBI、IAdvBootDBI这两个接口。其他进程可以通过这两个接口调用来存取数据。

(2) 数据中继访问类

完成数据的转换, 可以将复杂的数据结构转换为标准的数据流, 或者将数据流还原成复杂的数据结构。这些数据流包括两个部分:输入流和输出流, 通过这两个部分完成参数的传递和返回值的获取。

该类实现了IAdvBootDBI这个接口, 支持调用其他类的IRawBootDBI接口去传递、存取数据。其他进程可以通过这两个接口调用来存取数据。

(3) 客户端SOCKET类 (数据通讯模块)

数据通讯模块本身即为一个基于IRawBootDBI的对象, 他们完成的工作即将输入流送入其他服务进程或者服务器端, 然后等待其他服务进程或者服务器端返回一个输出流。一个CBootDBRelay的对象可以成功地将高级的数据转换为 (序列化) 流格式, 然后调用通讯模块的接口IRawBootDBI, 等待通讯模块完成数据请求后, 将返回流还原成 (反序列化) 高级格式, 返回给调用者。

数据通讯模块对数据的序列化与反序列化是成对出现的, 如果有多对序列化的格式, 就要分配协议号以示区别, 协议号本身被序列化成流格式的第一个字节, 反序列化时先读取第一个字节, 了解序列化的格式, 再对后续的流格式进行反序列化。

3 CDSA模型中数据访问的流程

模型中涉及配置数据的各进程对数据访问的逻辑示意如图1。

(1) 数据服务进程的直接数据访问

数据服务进程负责数据库的管理, 是数据的直接处理进程, 该进程通过消息队列实现数据的对外共享。

如图1所示, 在请求到达后, 该进程通过CBootDBDirect访问数据, 并同时完成系统配置:[消息队列服务器端]->IRawBootDBI (CBootDBDirect) ->DB (->IBootDBIPlugin (CSvr Cfgtor) ->系统配置) 。

(2) 本地进程间的数据访问

本地应用进程是本地的数据消费者之一, 该进程不能直接访问数据库的数据, 但可以通过高级访问接口存取数据:[本地应用进程]→IAdvBootDBI (CBootDBRelay) ->IRawBootDBI (消息队列客户端) 。其过程如图2所示。

(3) 远程进程间的数据访问—服务端

远程管理进程的服务端是数据的转发层, 对外衔接网络, 对内衔接数据服务进程。

[远程管理进程的服务器端]->IRawBootDBI (消息队列客户端) 其过程如图3所示。

(4) 远程进程间的数据访问-客户端

如图4所示, 远程管理客户端进程为数据的消费进程, 存在两种访问数据库的方式:

本地缓存数据:[管理]->IAdvBootDBI (CBootDBDirect) ->CacheDB

远程数据:[管理]->IAdvBootDBI (CBootDBDirect) ->IBoot DBIPlugin (Csvr Cfgtor) ->IAdvBootDBI

(CBootDBRelay) ->IRawBootDBI (SOCKET客户端)

4 CDSA模型的应用

图5说明了一个无盘站引导服务系统使用CDSA模型进行数据访问的实际情况。

说明:

(1) 图中数据守护进程不但是主无盘站引导服务软件的主进程, 还是数据服务进程, 它直接进行数据访问, 通过消息队列实现数据的对外共享。

由于系统软件本身功能不同, 操作的数据类型肯定也不同, 这就要根据实际需要去定义具体的实现类。图5中定义了无盘配置数据, 系统数据, 系统配置数据, 缓存数据等类。

(2) 图中DHCPBINL服务进程和TFTP守护进程对应了本地应用进程。

D H C P B I N L和T F T P守护进程是本地的数据消费者, FTFP还会fork出新的进程进行数据消费, 这些进程通过高级访问接口存取数据。

(3) 图中的管理服务器进程对应远程进程的服务端

管理服务器进程是数据的转发层, 对外为管理工具提供数据, 对内向数据服务进程取得数据。

(4) 图中的管理工具进程对应远程进程间的客户端

管理工具进程是数据消费进程, 刚建立连接时, 把数据从服务端请求到本地缓存, 以后的操作在缓存内进行。操作完成后, 如果缓存数据被修改过, 就调用CsvrCfgtor类的IBoot DBIPlugin接口回写数据。也可以通过IBoot DBIPlugin接口从远程取得最新的数据。

摘要：本文提出了一个称为CDSA的数据安全访问模型, 该模型可以被用在各应用软件中保证服务端与客户端数据的一致性, 也可以用在本地进程间通信、远程进程间通信等领域, 保证共享数据的一致性。

关键词：数据存取,数据一致性,回调

参考文献

访问安全性 篇5

答：打开IE，单击“工具”菜单→“Internet选项”→“安全”选项卡→“自定义级别”按钮，在弹出的“安全设置”对话框中找到“显示混合内容”，将它的设置更改为“启用”，最后单击“确定”按钮退出即可

点击阅读更多学院相关文章>>

访问安全性 篇6

企业一直在不遗余力地保证用户的安全，其措施之一就是限制访问。不过，智能卡和公钥基础设施（PKI）结合使用可能是另一种更加有效的手段。

技术创新使得计算机成了我们日常生活中不可或缺的一部分，但是，在前进的路上还有很多障碍。最近出现的各种恶意软件、间谍软件和病毒影响了用户访问企业网络。在世界各地出差的人感到了风险，笔记本电脑被盗、不可靠的宽带网络连接都给他们造成了不便。诸如此类的问题还有很多。

不管企业面临的问题是什么，它们的压力都越来越大，他们必须要设法找到有效的方法以锁定远程用户。有些通过减少使用或限制远程访问来解决这一问题，但事实是，这些方法不过是进一步，退两步。

解决远程访问问题的关键要素就是创建可靠的身份和访问模型。对很多企业来说，这是一项艰巨的任务。我们看到过很多鉴别和授权用户的战略。这些战略旨在提高虚拟专用网络的安全性，它们既有积极的一面，也有消极的一面。

有些组织正在使用多密码等其他能够解决问题的方案，比如使用一次性密码以锁定虚拟专用网络访问。这些方法的主要问题是用户使用不方便，数列很难辨认，也很难输入。有些系统中的密码每分钟都在变，用户经常在规定时间内无法完成输入。

IT经理们试图在笔记本电脑或台式机中应用“软令牌”，使软件程序自动生成并且提交密码。但如果笔记本电脑丢失或有人从这些机器上复制了软件以实施攻击，就会引发另一种安全问题。在用户识别中使用软令牌可能会使组织容易遭受中间人攻击。黑客可以拦截密码，并合法地连接上系统。

一个极为有效的解决方法就是将复杂的认证管理和严格的加密同基于所有权的对系统资源的沟通和访问结合起来。通常，人们认为实现这点最有效的方法就是采用PKI模型。这是一个强大的安全系统，采用了一系列的密码，并且很适于实施双因素身份认证。PKI之所以有效是因为它使用了两种与数学相关的密码——公钥和私钥。公钥的作用是产生可以公布和分发的数字身份证书，而私钥是保密的。

尽管PKI在网络安全方面是最有发展前途的，但它仍然面临着一些经济和流动性方面的挑战。问题之一就是不能转移，证书一旦发布，私钥就被存在了一台特定的设备上。比如，如果证书是在某台电脑中，那么用户就只能通过这台电脑使用密钥。

而且，这一系统也很复杂，很难在一年之内建立起全面的PKI。不过，如果利用PKI管理服务结合智能卡技术就可以解决很多问题。

PKI管理服务在实现安全标准的同时，还有助于减少企业的管理和财务负担。同智能卡技术结合之后，PKI管理服务可以有效地保证远程访问的安全，而不会导致基础设施的变化或高额的成本。

这项技术与PKI管理服务结合之后，用户在任何地点都可以安全地、以完全加密的方式访问公司网络，而数据都会在公司防火墙的保护之下。这意味着出差人员可以轻装上阵，远程访问也可以更加安全。只要具备装有Windows的可以上网的电脑，组织机构就可以让雇员使用低价的移动设备访问数据、应用程序和网络资源，并且从中受益。

多伦多的一个资本公司已经为40多个投资顾问配备了可以结合智能卡和管理PKI基础设施的设备。该设备采用了抗干扰技术，可以达到严格的安全认证标准，而且只能用于多因素身份认证。如果丢失或被盗，该设备会彻底失效。

Linux访问控制安全测评 篇7

关键词：信息安全,访问控制,安全测试

1.Linux安全测评的背景与意义

随着计算机与网络技术的普及应用,信息安全已经成为关系到国家安全的关键因素。在计算机系统安全中,操作系统安全是整个计算机信息系统安全的基石[1]。如果不经过安全测评,操作系统的安全性就得不到保障。随着我国基于Linux的国产操作系统研发的不断发展,研究Linux操作系统安全测评技术己成为迫切的需求,可以有效地保障国产操作系统应用地质量,从而更好地推动国产操作系统产业的发展。

操作系统安全测评涉及到安全操作系统、安全等级评估、评估标准等多方面内容。目前国内在Linux操作系统安全测评领域的研究还处在逐步发展的阶段,在操作系统安全等级评估方面已经取得了一定的成果,制定出了一系列等级评估相关标准。

随着操作系统在计算机系统安全中的重要作用越来越引起人们的重视,如何测评操作系统安全性成为一个重要的课题。信息安全国际通用标准CCCommon Criteria for IT Security Evaluation)提出了安全系统通常应该具备的安全功能,并进行了分类,其中,访问控制是系统安全的第一道防护手段[2]。因此,本文将从访问控制功能这个操作系统中最重要的安全机制出发,对Linux访问控制及其测试进行研究。

2.Linux安全测评的基础和标准

为了对Linux操作系统的安全性进行统一的评价,为Linux操作系统产品厂商提供权威的系统安全性标准,需要有相应的安全测评标准来支持。目前,国际上信息安全评估标准的制定已经取得了长足的发展[3][4][5]。

美国国防部于1983年推出了历史上第一个计算机系统安全评测准则TCSEC(Trusted Computer System Evaluation Criteria),又称桔皮书,从而带动了国际上计算机系统安全评测的研究。为了方便安全信息系统的统一评价,德国、英国、加拿大、西欧等纷纷制定了各自的计算机系统安全评价标准,其中较为著名的有ITSEC(Information Technology Security Evaluation Criteria)、CC(Common Criteria for IT Security Evaluation)。我国在借鉴、吸收TCSEC和CC等基础上制定了相应的国家标准GB/T18336-2001和GB/T20008-2005等标准。

基于相关安全需求,TCSEC在用户登录、授权管理、访问控制、审计跟踪、隐蔽通道分析、可信通路建立、安全检测、生命周期保障、文档撰写等方面均提出了规范性要求,并根据所采用的安全策略及系统所具备的安全功能设定四类(A~D)及七个安全级别,从低到高依次为D、C1、C2、B1、B2、B3、A1,各级别描述由满足安全策略、审计和保证的主要控制目标及文档要求共四部分组成。

我国的GB17859-1999《计算机信息系统安全保护等级划分准则》把计算机信息系统的安全保护能力划分为五级,从低到高依次为用户自主保护级、系统审计保护级、安全标记保护级、结构化保护级、访问验证保护级,相关要求分别对应TCSEC的C1级、C2级、B1级、B2级和B3级,并稍作调整。

信息技术安全评价通用准则CC基于欧洲ITSEC、美国TCSEC、加拿大CTCPEC及ISO SC27 WG3安全评价标准而形成,是目前最全面的信息技术安全评估标准。它们提出了保护轮廓的概念,将评估内容划分为安全功能要求和安全保证要求两个方面,并均按照类、族、组件的层次结构分别展开描述。CC提供和定义了七个逐步增强的评估保证等级EAL1~7,依次为功能测试级、结构测试级、系统测试检查级、系统设计测试复查级、半形式化设计测试级、半形式化验证设计测试级和形式化验证设计测试级。各评估保证等级结构上由评估保证等级名称、目标、适用性说明和一组保证组件以及相应保证组件间的所有依赖关系构成。

3.Linux系统的访问控制机制分析

访问控制是操作系统安全机制的主要内容,主要用来规范和控制系统内部主体对客体的访问操作[6][7][8]。

定义1主体(Subject)是指系统中能够发起行为的实体,比如,人、进程和设备等。

定义2客体(object)是指系统中被动的主体行为承担者,比如,文件、目录、管道、消息,以及存储页和存储段等。

定义3存取访问控制(Access Control)是规范和控制各类主体(用户、本地进程或远程进程等)访问本系统中客体的决策与实施过程。

访问控制的目的是为了限制访问主体对访问客体的访问权限,从而使计算机系统在合法范围内使用。它决定用户能做什么,也决定代表一定用户身份的进程能做什么。其中主体可以是某个用户,也可以是用户启动的进程和服务。因此,访问控制需要完成以下两种任务:

1)识别和确认访问系统的用户;

2)决定该用户可以对某一系统资源进行何种类型的访问。

现有的Linux的存取访问控制方式主要采用自主访问控制(Discretionary Access Control,DAC)和强制访控制(Mandatory Access Control,MAC)两种。

定义4自主访问控制是指客体(比如程序、文件或进程等)的拥有者可以任意的修改或授予此客体相应的权限。

定义5强制访问控制是基于更高的安全要求考虑,不由客体的所有者任意分配客体权限,而是事先按照一定的安全策略统一配置。

Linux支持UGO(User、Group、Other)和ACL(Access control List)权限管理方式,它们都属于自主访问控制方式,UGO将权限位信息存储在节点的权限中,ACL将权限位信息存储在节点的扩展属性中。

3.1 UGO访问控制管理机制

UGO访问控制机制是Linux文件系统传统的访问控制方式,它通过在文件和目录上都设置权限位,用来控制用户对文件或目录的访问。

在UGO访问控制方式中,一个文件创建后,它具有读、写和执行三种操作方式。UGO权限管理方式将文件的操作者分为文件所有者、同组用户和其他用户三类。文件所有者是指创建文件的用户,他是文件的拥有者,他可以设置用户的读、写和执行权限,也就是说他是访问控制权限的决定者。文件建立时默认的用户组是文件所有者所在的用户组,但文件所有者可以对该用户组进行修改,该组中的所有用户都是文件的同组用户。

UGO访问控制方式将文件的权限用三组3位的二进制位描述,即9位二进制数,并且在最前面加上一位作为文件的类型标志。每类用户占3位,读、写、执行权限各用1位描述,具有权限时,该位就设置为1。读、写、执行权限分别用r、w、x三个字符表示,如表2所示。

3.2基于ACL的自主访问控制机制

ACL实现用户权限管理,它对UGO权限管理方式进行了扩展,可以对任意的用户/组分配读、写和执行操作权限。ACL基于IEEE POSIX 1003.le标准,EXT2、EXT3、EXT4、JFS、XFS和Reiser FS等文件系统都支持ACL。

ACL的优先级高于UGO的优先级,当ACL的权限设置大于UGO时,mask就是UGO权限中的同组用户的最高权限,而ACL的有效权限则是和mask取权限的交集,从而限制了ACL对UGO权限的超越。但文件的所有者可以通过修改mask值来消除这种限制。在测试时,为了保证ACL访问控制不受限于UGO访问控制,应得将mask值设为rwx。ACL中单个用户权限的优先权高于同组用户权限,也就是说如果在ACL中设置了某个用户的权限,又设置了这个用户所在组的用户权限,则这个用户的权限与他所在组的用户权限无关。

4.Linux访问控制测试

4.1测试流程

对Linux操作系统的访问控制机制实现测试自动化,首先要分析该机制提供的安全功能,然后设计相关的测试用例,构建测试环境,执行测试,最后对测试结果进行分析,如图1所示。

分析Linux访问控制机制的安全功能需求主要是确定从哪些方面测试这些安全功能,这一步可参考测评标准中的相关安全功能组件中的具体描述来确定。本文主要参考了信息技术安全评价通用准则CC中规定的自主访问控制的安全功能组件的内容。

4.2.测试用例设计

在Linux操作系统中,UGO是最基本的访问控制管理方式,ACL是建立在UGO权限管理方式基础上的可选的机制。本节将先对不开启ACL机制时的UGO权限管理方式进行测试,然后在对ACL机制进行测试,后者也就是测试这两种安全机制都工作时是否满足安全功能需求。

根据CC标准中安全功能组件,访问控制安全测试应该分为访问控制权授予测试和访问控制实施测试两类。由于UGO权限管理方式在特殊权限位开启和关闭时安全功能不同,所以将对UGO的测试分为开启特殊权限位测试和不开启特殊权限位的测试,如图2所示。

(1)UGO访问控制安全测试

为了保证将所有的安全功能都覆盖到,应该先对该访问方式的类型进行分类。UGO将权限按用户分类,用户分为文件所有者、同组用户、其他用户三类,所以必须保证每一类中至少有一个用户,才能通过这类用户的行为判定安全功能是否实现。例如,当一个文件的所有者为Userl,所在的组为Groupl时,User2是这个文件的同组用户,User3是这个文件的其他用户。这就保证了文件所有者、同组用户、其他用户三类分别有不同的用户,如表3所示。

UGO权限中的特殊权限位SUID,SGID和Sticky开启和关闭时,访问控制功能是不同的。接下来我们分别在在特殊权限位关闭和开启情况下,对这两种测试进行测试数据准备和测试用例的描述。

没有开启特殊权限位UGO访问控制授予测试的文件准备比较简单,只需要一个所以者为Userl,用户组为Group1,权限为rwxrwxrwx的文件“Test ugo_change”,测试用例如表4所示。

开启权限位后对UGO访问控制授予测试,要验证这三个位对文件权限的授予没有影响,测试用例如表5所示。

(2)ACL访问控制机制的测试设计

在ACL机制中权限的分配是以单个用户和单个用户组为单位的。测试用例要检查ACL机制对文件所有者、组用户和其他用户和用户组能否指定的访问权限是否正确实施。为了不受ACL的影响我们将mask都设为rwx权限。ACL访问控制权授予测试用例如表6所示。其中Test_acl_changel文件的所有者为Userl,用户组为Group1,权限是rwxrwxrwx,ACL权限为用户Userl、User2、User3用户有rwx权限,组Userl有rwx权限。

5.结束语

访问控制机制是操作系统最为关键的安全支撑机制,同时由于国内自主研发的操作系统大多基于开源的Linux系统内核,所以本文以Linux系统的访问控制机制为切入点,对操作系统安全测试进行了探索和讨论。

开展Linux操作系统安全测评的研究,目的是对操作系统的安全指标进行评估,为信息系统的安全及国产操作系统产品的开发和选购提供理论和技术指导,最终为信息系统的安全、实用奠定基础。为了进一步推动国产操作系统的发展,在注重操作系统质量的同时,要重点关注操作系统的安全性。

参考文献

[1]陆幼骊,张红旗.操作系统安全测评系统设计[J],信息安全与通信保密,2005,8:94-97.

[2]牛妍萍,吕述望.Linux文件访问控制及其自动化测试,信息安全与通信保密,2006,9:165-166.

[3]左晓栋.信息安全产品与系统的测评与标准研究[D],北京:中国科学院研究生院,2002.

[4]马妙霞.基于Linux的强制访问控制机制及其安全测试自动化的研究[D].北京:北京交通大学,2007.

[5]陈晨.操作系统安全测评及安全测试自动化的研究[D],北京:北京交通大学,2008.

[6]牛晗晖.Linux系统调用及其安全测试自动化的研究[D],北京:北京交通大学,2009.

[7]李耀东.Linux操作系统存取访问控制机制的研究[D],北京:北京交通大学,2008年.

访问安全性 篇8

ASP.Net技术是一种用于创建Web应用程序的编程模型。运行时可以和.Net Framework类库集一起配合用于创建动态Web页。大多数ASP.NET Web应用程序都涉及数据访问。许多应用程序都会收集数据并将其存储在数据库或文件中, 要存储的数据通常基于来自用户的信息。由于原始数据可能来自不受信任的来源, 信息是以持久格式存储的, 并且希望确保未经授权的用户不能直接访问数据源, 因而需要特别注意与数据访问有关的安全问题。本文主要探讨从连接字符串、使用集成安全性连接到SQL Server/Microsoft Access数据库、XML文件等操作, 来提高Web应用程序中的数据访问的安全性。

2、连接字符串

在数据库的各种应用程序开发中, 连接数据库是数据库应用程序中最重要的一步。由于连接字符串可能包含敏感数据, 如数据库名、登录名、密码等, 因此连接字符串应当遵循以下若干准则:

(1) 将连接字符串存储在Web.config文件中

要避免通过声明SqlDataSource控件或其他数据源控件的属性的方式来设置连接字符串, 而应当将连接字符串存储在站点的Web.config文件中。这种做法有两个有点: (1) 数据源控件可以从配置文件中引用连接字符串的名称, 而不是包括连接字符串作为控件属性; (2) 由于连接字符串的管理集中进行, 在连接字符串信息更改时无需重新访问各页, 因此更易于管理站点。

(2) 加密连接字符串

使用ASP.NET IIS注册工具 (Aspnet_regiis.exe) 可以加密连接字符串。Aspnet_regiis.exe工具位于%systemroot%Microsoft.NETFramework版本号的文件夹中。在Windows命令行, 使用以下选项运行:

-pe选项, 向其传递字符串"connectionStrings"以加密connectionStrings元素。

-app选项, 向其传递应用程序的名称。

下面的代码示例演示如何为名为SampleApplication的应用程序加密Web.config文件的connectionStrings节。

当该命令完成时, 可以查看Web.config文件的内容。connectionStrings配置节将包含加密信息而不是明文形式的连接字符串, 这样就保证在使用数据源控件时连接字符串的安全。

(3) 不要以纯文本形式存储连接字符串

为了确保与数据库服务器之间的连接的安全性, 应当使用受保护的配置来对配置文件中的连接字符串信息进行加密。

ASP.NET应用程序中存储敏感信息的主要位置之一是Web.config文件。为了帮助保护配置文件中的信息, ASP.NET提供了一项称为“受保护配置”的功能, 可以使用受保护配置来加密Web应用程序配置文件 (如Web.config文件) 中的敏感信息 (包括用户名和密码、数据库连接字符串和加密密钥) 。对配置信息进行加密后, 即使攻击者获取了对配置文件的访问, 也可以使攻击者难以获取对敏感信息的访问, 从而改进应用程序的安全性。

例如, 未加密的配置文件中可能包含一个指定用于连接到数据库的连接字符串的节, 如下面的示例所示:

可以通过使用ProtectedConfigurationProvider类对Web.config文件的内容进行加密和解密, 使用受保护配置对连接字符串值进行加密的配置文件不以明文形式显示连接字符串, 而是以加密形式存储它们, 在对页进行请求时, .NET Framework对连接字符串信息进行解密, 并使其可供应用程序使用。

3、连接数据库

连接Sql Server数据库应该遵循以下安全性原则:

(1) 使用集成安全性连接到SQL Server

使用集成安全性, 而不要使用显式的用户名和密码连接到SQL Server实例, 这有助于避免危及连接字符串的安全以及泄漏用户ID和密码。因此要确保运行ASP.NET的进程的标识是默认进程帐户或受限用户帐户。如果不同的网站连接到不同的SQL Server数据库, 那么使用集成安全性可能并不实际。例如, 在Web宿主网站中, 通常会为每个客户分配一个不同的SQL Server数据库, 但所有用户均以匿名用户的身份使用Web服务器。在这种情况需要使用显式凭据来连接到SQL Server实例。

(2) SQL Server数据库权限

为用来连接到应用程序所使用的SQL Server数据库的用户ID分配最低特权。

(3) 限制SQL操作

数据绑定控件可以支持各种数据操作, 包括在数据表中选择、插入、删除和更新记录等。将数据控件配置为仅执行页上或应用程序中所需的最低功能。例如, 如果控件不应该允许用户删除数据, 则不要在数据源控件中包括删除查询, 也不要在控件中启用删除功能。

(4) SQL Server Express Edition

在将某个进程附加到SQL Server Express Edition数据库 (.mdf文件) 时, 该进程必须具备管理权限。通常情况下, 这种做法使得SQL Server Express Edition数据库不适合用在成品网站上, 因为ASP.NET进程不会 (也不应当) 使用管理特权运行。因此, SQL Server Express Edition数据库只能用于下面的情况中:

(1) .在开发Web应用程序时用作测试数据库。在准备好部署应用程序时, 可以将数据库从SQL Server Express Edition转移到SQL Server的成品实例中。

(2) .如果正在运行可以使用模拟功能的网站并且可以控制所模拟的用户的特权, 那么可以使用该版本。实际上, 此策略仅当应用程序运行于局域网 (而非公共网站) 上时才可行。

(3) .将.mdf文件存储在站点的App_Data文件夹中, 因为该文件夹的内容不会返回给直接的HTTP请求。还应在IIS中将.mdf扩展名映射到ASP.NET, 并在站点的Web.config文件中使用以下元素将该扩展名映射到ASP.NET中的HttpForbiddenHandler处理程序:

(5) Microsoft Access数据库

Microsoft Access数据库 (.mdb文件) 所包括的安全功能比SQL Server数据库少。对于商务网站, 尽量不要使用Access数据库。但是, 如果确实需要在Web应用程序中使用.mdb文件, 请遵循以下准则:

(1) .将.mdb文件存储在站点的App_Data文件夹中, 因为该文件夹的内容不会返回给直接的HTTP请求。还应在IIS中将.mdb扩展名映射到ASP.NET, 并在站点的Web.config文件中使用以下元素将该扩展名映射到ASP.NET中的HttpForbiddenHandler处理程序:

(2) .为读写.mdb文件的用户帐户添加适当的权限。如果网站支持匿名访问, 这通常是本地ASPNET用户帐户或NETWORK SERVICE帐户。由于Access必须创建一个.ldb文件以支持锁定, 因此用户帐户必须对包含.mdb文件的文件夹具备写权限。

(3) .如果数据库采用密码保护, 那么不要使用AccessDataSource控件来建立与数据库的连接, 因为AccessDataSource控件不支持凭据的传递。在这种情况下, 应使用ODBC提供程序和SqlDataSource控件, 并在连接字符串中传递凭据。

4、XML文件

如果将数据存储在XML文件中, 则应将XML文件放在网站的App_Data文件夹中, 因为该文件夹的内容不会返回给直接的HTTP请求。并且需要防止恶意用户输入, 如果应用程序要接受用户输入, 则需要确保输入中不包含可能危及应用程序的恶意内容。恶意用户输入可用于发动下面两类攻击:

·脚本注入攻击

脚本注入攻击尝试向应用程序发送可执行的脚本, 意欲使其他用户运行该脚本。典型的脚本插入攻击是向数据库中存储脚本的页发送脚本, 以使查看数据的其他用户在不经意间运行该代码。

·SQL注入攻击

SQL注入攻击尝试创建SQL命令以取代或扩充应用程序内置的命令, 从而危及数据库 (可能还有运行数据库的计算机) 的安全。

对于所有用户输入, 请遵循以下准则: (1) 尽可能使用验证控件, 以限定用户输入可接受的值。 (2) 在运行服务器代码之前, 请始终确保IsValid属性的值为true。如果值为false, 则意味着一个或多个验证控件未通过验证检查。 (3) 应始终执行服务器端验证 (即使浏览器也执行客户端验证) 以防止用户跳过客户端验证环节。对于CustomValidator控件尤其应如此;不要使用“仅客户端验证”逻辑。 (4) 始终在应用程序的业务层再次验证用户输入。不要依赖于调用进程来提供安全的数据。例如, 如果正在使用ObjectDataSource控件, 则可向执行数据更新的对象添加冗余验证和编码。

若要避免脚本注入攻击, 请遵循以下准则: (1) 采用HtmlEncode方法对用户输入进行编码, 该方法可将HTML转换为文本表示形式 (例如, 将<b>转换为&ltb>) , 这有助于防止在浏览器中执行标记。 (2) 在使用参数对象将用户输入传递给查询时, 可以为数据源控件的预查询事件添加处理程序并在这些事件中进行编码。例如, 如果处理SqlDataSource控件的Inserting事件, 可以在该事件中, 在执行查询之前对参数值进行编码。 (3) 若正在使用带绑定字段的GridView控件, 则可将BoundField对象的HtmlEncode属性设置为true。这会使GridView控件在行处于编辑模式下时对用户输入进行编码。 (4) 对于可以进入编辑模式的控件, 就使用模板。例如, GridView、DetailsView、FormView、DataList和Login控件可以显示可编辑的文本框。但是, 除GridView控件之外, 这些控件不会自动验证用户输入或对用户输入进行HTML编码。因此, 要为这些控件创建模板, 在模板中包括输入控件 (例如TextBox控件) 并添加验证控件。此外, 在提取控件的值时, 应对其进行编码。

若要避免SQL注入攻击, 请遵循以下准则: (1) 不要通过将字符串 (尤其是那些包括了用户输入的字符串) 串联在一起来创建SQL命令, 而应当使用参数化查询或存储过程。 (2) 如果要创建参数化查询, 则可使用参数对象来建立参数的值。

5、缓存与加密视图状态数据

在启用了客户端模拟并根据客户端标识检索数据源中的结果时, 应避免在Cache对象中存储敏感信息。如果启用了缓存, 则单个用户的缓存数据会被所有用户看到, 并且敏感信息可能公开给有害源。如果identity配置元素的impersonate特性设置为true且对Web服务器上的应用程序禁用匿名标识, 则说明启用了客户端模拟。

数据绑定控件 (例如GridView控件) 有时需要保存被视为敏感内容的信息。例如, GridView控件可能要在DataKeys属性中维护一个键的列表, 即使该信息并不显示。在往返行程之间, 控件会将该信息存储在视图状态中。因此要对视图状态信息进行编码, 并与页的内容一起存储, 未经授权的源无法解码和查看视图状态信息。如果必须在视图状态中存储敏感信息, 可以要求页对视图状态数据进行加密。若要加密数据, 请将页的ViewStateEncryptionMode属性设置为true。

6、总结

尽管遵循编码和配置最佳做法可以提高应用程序的安全性。但还有一点也很重要, 那就是应经常执行Microsoft Windows和Internet信息服务 (IIS) 的最新安全更新以及Microsoft SQL Server或其他数据源软件的所有安全更新, 以使Web服务器始终保持在最新状态。

摘要：数据访问在Web程序中占有十分重要位置, 其安全性也决定着整个Web系统的安全。文章就基于ASP.NET数据访问的安全性问题进行了详细的阐述, 主要探讨从连接字符串、使用集成安全性连接到SQL Server/Microsoft Access数据库、XML文件等操作, 来提高ASP.NET Web应用程序中的数据访问的安全性。

关键词：ASP.NET,数据访问,安全性

参考文献

[1]KAUFFMAN J, THANGARATHINAM T.ASP.Net数据库入门经典[M].4版.肖奕, 译.北京:清华大学出版社, 2007.

[2]LIBERTY J, HURWITZ D.Programming ASP.Net中文版[M].3版.瞿杰, 赵立东, 张昊, 等, 译.北京:电子工业出版社, 2008.

解析Linux下VPN安全访问 篇9

对于企业网用户来说, 当其需要从Internet上访问内网资源时, 就需要建立安全稳定的传输通道。其优点是通过VPN加密通道, 为用户提供安全的网络访问功能。但Windows平台的安全性比较脆弱。实际上, 很多情况下连接Internet的服务器采用的都是Linux平台, 这可以有效的防御黑客侵袭, 更好的保护内网安全。

安装和配置L2TP VPN服务器

以建立L2TP VPN服务器为例, 在企业内网中存在一台VPN服务器, 其eth1网络接口的IP为192.168.0.1, 用来连接内网。其eth0网络接口的IP为100.60.220.11, 用来连接Internet。在该服务器上安装XL2TPD这款软件, 执行“rpm-ivh xl2tpd-x.x.i386.rpm”命令, 完成安装操作, 其中的“x.x”表示具体的版本。使用VIM命令, 对“/etc/xl2tpd/xl2tpd.conf”文件进行编辑, 在该文件中存储XL2TPD的配置信息。在其中的“listen-addr”行中设置连接外网的IP, 这里为“100.60.220.11”。在“port”行中设置UDP通讯端口, 默认为1701。

编辑PPP协议配置文件

配置好所需参数后, 执行“service xl2tpd restart”命令来启动XL2TCP服务。因为上面已指定了PPP协议的配置文件, 所以需要对其进行必要的配置。

这里要说明一下Proxy ARP的运行机制, 其主要用来解决内网主机和VPN客户端的连接顺畅问题。例如当远程VPN的IP为192.168.0.19, 如果其访问的内网主机的IP为192.168.0.30的话, 当其和L2TP服务器建立VPN连接后, 发送的数据由客户端的PPP0虚拟端口发送到L2TP的PPP0端口, 那么数据包中的源地址为192.168.0.19, 目的地址为192.168.0.30。根据L2TP服务器上的路由表信息, 数据包会通过eth1接口传送给IP为192.168.0.50的主机。

但是, 当该主机回送数据包时, 就会发现目标主机的IP是192.168.0.19, 和自身处于同一网段, 其自然会通过ARP进行广播, 来查找IP为192.168.0.11的主机。由于ARP广播无法跨网段传播, 就会造成要么无法找到目标主机, 要么和错误的目标主机通讯, 而无法和远程VPN客户端互传数据的情况。为了解决该问题, 就需要在L2TP服务器上启动Proxy ARP机制, 让其先替代VPN客户端接收数据包, 之后根据L2TP服务器的的路由表信息, 来确定正确的连接方向。这样, 数据包就会从PPP0虚拟端口发送出去, VPN客户端自然可以顺利接收。

创建VPN连接账户信息

当通过L2TP VPN服务器建立连接时, 必然会对客户端的身份进行验证, 该验证操作和PPP协议的密码相关。在PPP协议的验证方式中, 包含明文验证和安全认证。对于明文验证 (例如PAP等) 来说, 因为其会暴露用户的账户名和密码等敏感信息, 在实际中很少使用。

当然, 这需要对“/etc/ppp/chap-secrets”文件进行配置, 在其中添加VPN客户端的账户名等信息。在其中每一个VPN账户占用一行, 其包含四个字段, 第一个字段账户名 (例如“vpnuser1”) , 第二个字段为相关的服务名, 即上述配置文件中预设的“xl2tpvpnserver”。注意, 在L2TP服务器上可能运行有多个服务, 而不仅仅是L2TP服务, 所以这里必须明确指定具体的服务名。第三个字段为该账户的密码, 这里为明文密码, 第四个字段为允许连接的IP范围, 例如“192.168.0.0/24”。

使用证书保护VPN通讯安全

为了保证连接的安全性, 需要使用证书对其进行加密。在Linux中可以使用Open SSL来发布证书。一般会通过证书管理中心 (CA) 机构, 来申请和获得数字证书。SSL加密连接机制在实际工作中应用的很广泛。但凡涉及到SSL安全技术, 在服务器端都必须提供相应的数字证书, 否则SSL机制就无法工作。

搭建CA证书中心

在Linux中借助于Open SSL软件, 可以很轻松的搭建CA证书中心。在RHEL 5中已经自带了该软件, 例如将其安装盘中的“openssl-0.9.8b-8.3-el5.rpm”包复制进来, 执行“rpm-ivh openssl-0.9.8b-8.3-el5.rpm”命令, 就可以安装Open SSL。或者从网上下载稳定版本, 之后完成安装操作。在命令提示符下执行“cd/etc/pki/tls/misc”命令, 切换到指定的目录, 执行“./CA-newca”命令, 表示创建企业CA。之后会依次显示具体的创建过程, 需要按照提示执行必要的配置操作。

证书的申请和审核签发

在命令提示符下执行“cd/etc/pki/tls/misc”命令, 切换到指定目录。执行“./CA-newreq”命令, 表示创建证书申请单。之后该命令以随机方式生成私钥, 之后将其保存成名为“newkey.pem”的私钥文件。在“Enter PEM pass phrase”栏中输入密码, 用来对私钥进行加密。

当生成证书申请单后, 在当前路径下会得到“newreq.pem”和“newkey.pem”文件, 前者是申请单文件, 后者是私钥文件。

之后将证书申请单提交给CA服务器处理, 必须将存放在“/etc/pki/tls/misc”目录中, 其名称必须为“newreq.pem”。执行“cd/etc/pki/tls/misc”命令, 切换到指定目录, 执行“./CA-sign”命令, 使用“-sign”参数表示执行证书签发操作。根据命令的提示, 在“Enter pass phrase for”栏中输入CA私钥的密码。在“Certification Details”栏中显示证书申请单的内容, 便于管理员进行核对。当核对无误后, 在“Sign the certificate?”栏中输入“y”, 表示执行凭证签发动作。在“1 out of 1 certificate request certified, commit?”栏中输入“y”, 再次执行确认操作, 执行凭证签发作业。之后执行具体的签发操作。

当执行完毕后, 打开“/etc/pki/tls/misc”目录, 可以看到名为“newcet.pem”的证书文件。之后将其发送给申请者即可。在CA服务器上将上述证书申请单文件以及创建的证书删除, 因为CA不需要保存这些文件。

配置VPN连接安全策略

为了保证VPN客户端和L2TP服务器连接的安全性, 需要使用IPSec对其进行加密传输。而这种加密具有双向性。L2TP客户端的IP一般处于变动之中, 因此在L2TP服务器上的安全策略中只能设置单向策略。因为L2TP协议默认使用的是UDP 1701端口, 因此只要经过该端口发送出去的数据, 都需要进行IPSec加密传输。打开“/etc/racoon/setkey.conf”文件, 在其中可以配置所需的安全策略。在其中添加“spdadd1 0 0.6 0.2 2 0.1 1[1 7 0 1]0.0.0.0 any-P out ipsec”一行, 其作用就是对经由UDP 1701发送的数据进行IPSec加密传输。为了实现双向的安全策略, 更好的保护数据的安全, 可以对IKE的配置文件进行修改。

IKE (Internet Key Exchange) 架构的功能是解决固定密钥模式中VPN连接不安全的问题。管理员只需设置加解密算法以及验证算法等信息, IKE就会定时自动的生成加密密钥。这样, 让管理员不再关心密钥的生成以及交换等问题。在数字证书验证模式下, 可以使用数字证书来进行VPN双向身份验证。对于L2TP服务器, 可以按照上述方法向CA证书颁发机构申请证书, 假设申请到的证书为“vpnsrv.pem”, 私钥文件为“vpnsrv.key”, CA证书为“cacert.pem”, 证书注销清单文件为“crl.pem”, 将这些文件保存到L2TP服务器的“/etc/racoon/certs”目录下。

进入该目录后, 执行“ln-s cacert.pem$ (openssl x 5 0 9-n o o u t-h a s h<cacert.pem) .0”和“ln-s ctl.pem$ (openssl x509-noout-hash<cacert.pem) .r0”命令, 针对“cacert.pem”和“crl.pem”文件创建两个哈希连接, 让racoon可以根据其来查找CA证书和注销清单。使用VIM命令打开“/etc/racoon/racoon.conf”文件, 在其中可以对IKE参数进行配置。

在Windows客户端导入证书

将证书导入到Windows中的话, 需要对其进行转换操作。因为Windows并不支持上述证书格式。假设生成的证书为“kehu.pem”, 私钥为“kehu.key”文件。执行“openssl pkcs12-export-in kehu.pem-out kehuduan.p12-inkey kehu.key”命令, 按照提示输入私钥密码, 同时需要输入保护“kehuduan.p12”证书的密码, 该密码在Windows导入证书时需要输入。同时将CA证书“cacert.pem”改名为“cavert.crt”。

在Windows 7中点击“Windows+R”组合键, 执行“mmc”命令, 在控制台窗口中点击“Ctrl+M”组合键, 在弹出窗口中的“可用的管理单元”列表中选择“证书”项, 点击“添加”按钮, 在证书管理界面中选择“计算机账户”项, 在下一步窗口中选择“本地计算机”项, 点击完成按钮。在控制台界面左侧选择“控制台根节点”、“证书 (本地计算机) ”、“个人”项, 在其右键菜单上点击“所有任务”、“导入”项, 在操作向导界面中点击下一步按钮, 在“要导入的文件”窗口中点击浏览按钮, 选择上述“kehuduan.p12”文件。

在下一步窗口中输入保护密码, 点击下一步按钮, 选择证书存储位置, 选择“个人”项。点击完成按钮, 完成证书导入操作。当计算机证书导入完毕后, 接下来需要导入CA证书, 在控制台左侧选择“控制台根节点”、“证书” (本地计算机) 、“受信任的跟证书颁发机构”、“证书”项, 在其右键菜单上点击“所有任务”、“导入”项, 在操作向导界面中点击下一步按钮, 点击浏览按钮, 选择CA证书文件, 例如“cacert.crt”。在下一步窗口中选择证书存储位置, 选择“受信任的根证书颁发机构”项。点击“完成”按钮, 完成CA证书导入操作。客户端就即可信任CA证书颁发机构。

在客户端创建VPN拨号连接

当导入证书之后, 在网络和共享中心窗口点击“设置新的连接或网络”项, 在打开窗口中点击“连接到工作区”项, 点击下一步按钮, 选择“使用我的Internet连接 (VPN) ”项, 在连接窗口中的“internet地址”栏中输入L2TP服务器的外网地址, 例如“100.60.220.11”, 在“目标名称”栏中输入合适的名称, 在下一步窗口中输入预设的VPN账户名和密码, 即可连接到目标L2TP服务器。

这样, 不管VPN客户端将数据包发送到何处, 其都会通过PPP连接发送到该默认网关, 对于发送给内网的数据, 都会通过L2TP服务器转发给内网主机。对于发送给外网的数据则会通过L2TP服务器。其优点是客户端传送的数据全程处于L2TP服务器的保护之下, 别人无法对加密的数据进行拦截破译。其缺点是网络传输性较差, 安全性较低。

基于端口访问WLAN的安全配置 篇10

数据泄露:对不安全的无线通信进行窃听攻击可造成机密数据泄露、用户凭据被发现,甚至导致身份盗窃。经验丰富的攻击者可使用通过窃听收集的信息来发动对可能不容易受到攻击的系统的攻击。

1、数据截取和修改

能够访问网络资源的攻击者也能够将恶意系统插入在两个合法系统之间中途截取和修改数据的网络。

2、欺骗方式进行访问

访问内部网络使攻击者有机会伪造数据。这类攻击可以使用欺骗性电子邮件,较发来自外部来源的通信,当然内部用户更愿意信任这些邮件,为社会工程攻击和特洛伊木马插入提供了平台。

3、拒绝服务(Do S)

WLAN都容易受到Do S有意或无意的攻击。这些损害可能只是由像微波炉或某个设备一样简单的物体造成的,从而使网络塞满不加选择的通信。

4、自由加载

某些入侵者的目的可能只是为了能够自由访问因特网。虽然这种行为不是直接恶意行为或损害,但可能造成合法用户的网络连接速度更慢或者非托管媒介受到恶意软件的攻击。

5、恶意访问点攻击

即使企业没有无线网络,仍很容易受到来自非托管无线网络的安全威胁。无线硬件的价格相对便宜,因此任何员工都有可能在环境内部建立非托管和不受保护的网络。

二、WLAN端口访问机制

802.1x协议又称为基于端口的访问控制协议,可提供对802.11无线局域网和对有线以太网络的验证的网络访问权限。802.1x协议仅仅关注端口的打开与关闭,对于合法用户接入时,打开端口;对于非法用户接入或没有用户接入时,则端口处于关闭状态。

1、802.1x协议体系结构原理

IEEE 802.1x协议的体系结构主要包括三部分实体:客户端系统Supplicant System、认证系统Authenticator System、认证服务器系统Authentication Server System。

(1)设置客户端:一般为一个用户终端系统,该终端系统通常要安装一个客户端软件,用户通过启动这个客户端软件发起IEEE 802.1x协议的认证过程。

(2)设置认证系统:认证系统一般是支持IEEE 802.1x协议的网络设备。该设备对应于不同用户的端口有两个逻辑端口:受控(Controlled Port)端口和非受控端口(Uncontrolled Port)。第一个逻辑接入点(非受控端口),允许验证者和LAN上其它计算机之间交换数据,而无需考虑计算机的身份验证状态如何。非受控端口始终处于双向连通状态(开放状态),主要用来传递EAPOL协议帧,可保证客户端始终可以发出或接受认证;第二个逻辑接入点(受控端口),允许经验证的LAN用户和验证者之间交换数据。受控端口平时处于关闭状态,只有在客户端认证通过时才打开,用于传递数据和提供服务。受控端口可配置为双向受控、仅输入受控两种方式,以适应不同的应用程序。如果用户未通过认证,则受控端口处于未认证(关闭)状态,则用户无法访问认证系统提供的服务。

(3)设置认证服务器:认证服务器通常为RADIUS(Remote Authentication Dial In User Service)服务器,该服务器可以存储有关用户的信息,比如用户名和口令、用户所属的VLAN、优先级、用户的访问控制列表等。当用户通过认证后,认证服务器会把用户的相关信息传递给认证系统,由认证系统构建动态的访问控制列表,用户的后续数据流就将接受上述参数的监管。

2、设置802.1x认证协议

IEEE 802.1x使用标准安全协议(如RADIUS)提供集中的用户标识、身份验证、动态密钥管理和记账。

(1)802.1x身份验证可以增强安全性。IEEE 802.1x身份验证提供对802.11无线网络和对有线以太网网络的经验证的访问权限。IEEE 802.1x通过提供用户和计算机标识、集中的身份验证以及动态密钥管理,可将无线网络安全风险减小到最低程度。作为RADIUS客户端配置的无线接入点将连接请求和记账邮件发送到中央RADIUS服务器。中央RADIUS服务器处理此请求并准予或拒绝连接请求。如果准予请求,根据所选身份验证方法,该客户端获得身份验证,并且为会话生成唯一密钥,减少了非法用户访问的可能性。

(2)IEEE 802.1x为可扩展的身份验证协议EAP安全类型提供的支持使您能够使用诸如智能卡、证书以及Message Digest5(MD5)算法这样的身份验证方法。扩展身份验证协议EAP是一个支持身份验证信息通过多种机制进行通信的协议。利用802.1x,EAP可以用来在申请者和身份验证服务器之间传递验证信息。这意味着EAP消息需要通过LAN介质直接进行封装。认证者负责在申请者和身份验证服务器之间转递消息。身份验证服务器可以是一台远程身份验证拨入用户服务(RADIUS)服务器。

(3)另外,可设置产品提供SSID、IEEE802.1X、MAC地址绑定、WEP、WPA、TKIP、AES等安全机制,加强其安全性。

三、合理布置硬件及安全意识的提高

合理布置无线AP及工作站的位置,同样对网络安全性十分重要。例如,应将AP置于接近建筑物中心的地方,远离外向墙壁或窗户。这样不仅可使所有办公室能够更好地接入WLAN,而且还可减少来自外界的干扰,而且还应灵活地减少接入点广播强度,仅覆盖所需区域,减少被窃听的机会。

保障数据安全,网络技术主管需要采用最高安全保护措施,从最基本的安全制度到最新的访问控制、数据加密协议,采用的安全措施越多,其网络相对就越安全。当然,只靠软硬件的设置,远远不能保障数据的安全,最为重要的是提高用户的安全意识,并对各级网络用户负责其安全性,让所有网络用户都是“安全代理”。另外要帮助用户了解不采取安全保护的危险性,培训用户如何检查其电脑上的安全机制,并按需要激活这些机制,这样可以大幅度提高其网络的安全性。

总之,WLAN安全是一个复杂的工程,在防范中,应积极定期检查各级网络上的欺骗性或未知接入点。定期修改接入点上的缺省管理密码和SSID,并实施动态密钥(802.1x)或定期配置密钥更新,这样可以最大限度地减少非法用户接入网络的可能性。

参考文献

[1]王祥仲郑少京.局域网组建与维护实用教程[M].清华大学出版社.2007-7-1.

[2]陈明.网络安全教程[M].清华大学出版社2004-4-1.

[3]王钧民,邢丽.网络服务器配置与管理项目教程[M].电子工业出版社.2009年06月.

[4]http://it.china-b.com[EB/OL].

[5]马建峰.无线局域网的安全体系结构[M].高等教育出版社2008年5月.

[6]郭峰,曾兴雯等.无线局域网[M].电子工业出版社.1997.

访问安全性 篇11

摘 要：分析了电子档案元数据构成和归档安全性要求，提出了基于XML文件访问控制机制的电子档案安全保障模型（xERSPM）。通过敏感性信息嵌入、文件访问权限控制、XML签名、XML应用防火墙验证等信息安全机制，解决了电子档案访问、传输等操作过程的安全性问题。在xERSPM模型的XML文件访问机制控制下，采用电子档案数据分类封装、数字摘要和XML签名等技术，解决了电子档案封装包持续更新和多次数字签名认证问题。

关键词：电子档案；安全保障；XML签名；访问控制列表；信息安全

电子档案安全保障技术是电子档案的归档、鉴定、处置、移交、利用的根本性保障[1]。由于电子政务系统和档案管理系统的复杂性和多样性，电子档案安全保障通常是一个跨网络的、异构系统之间数据转换和信息共享的安全保障问题。随着电子政务系统和OA系统普及和深入应用[2]，如何保障电子档案管理的安全性是电子档案管理工作面临的新挑战。

本文在分析电子档案元数据构成和归档安全性要求的基础上，借助XML文件信息安全和电子档案封装技术，构建基于XML文件访问控制机制的电子档案安全保障模型，以高效保障电子档案安全。

1 电子档案安全保障要点及实现机制

电子档案安全保障的核心目标是维护电子档案的真实性和长期可读性，防止电子档案受损、失真、不可读，保障电子档案与归档时的状态一致[1]。电子档案的真实性包括电子档案归档时来源身份和原始状态是真实可证的和电子档案的保管过程可追溯、可审计性等两个层面的含义[7]。针对电子档案的真实性保障，档案界已经开展很多研究，如数字签名、元数据管理等[2]。电子档案长期可读性要求档案管理系统要对电子档案实体进行一定处理，使之满足长期可读的格式和存储要求，防止其丢失和失效。目前主要保障措施有格式转换和基于封装包的数字迁移等。

电子文件封装技术是一种将电子文件数据实体及其元数据按指定结构打包的技术，例如VEO（Victorian Encapsulated Object）、METS（Metadata Encoding and Transmission Standard）[8]等。由于电子文件封装技术具有资源自包含、自描述、自证明等特性，档案界认为它是一种有效的电子档案安全保障技术。国家档案局2009年颁布的《基于XML的电子文件封装规范DA/T48-2009》（以下简称“DA/T48-2009标准”）采用VEO对电子档案的封装格式、要求制定了规范，是我国电子政务系统普遍采用的一种电子档案安全保障策略。但实践证明，由于在制定元数据和电子档案实体数据XML封装规范时，DA/T48-2009标准没有最大限度地兼顾电子档案的真实性和长期可读性要求，加之存在VEO技术存在内容不易机器处理、封装包随电子档案保管活动的进行多次封装等局限性，导致它并没有得到广泛地应用。

电子档案元数据包括描述性元数据和管理性元数。一方面，电子档案长期可读性主张将电子档案及其元数据进行整体封装；另一方面，完善的元数据记录有利于追溯档案实体生成和管理过程，是确保电子档案真实性的基础，因此管理性元数据要不断被添加到电子档案元数据中。增加元数据使得电子档案面临多次封装，极易造成内在安全保障风险和漏洞。作为一种解决方案，有研究采用分体式METS技术，将电子档案实体数据的二进制内容以外部文件的形式存在，指向电子档案实体数据的链接封装在“文件列表块”中，元数据统一记录在“描述性元数据块”和“管理元数据块”中。[8]分体式METS技术在一定程度上提高了电子档案封装包的稳定性，降低了内在风险。但由于每次更新电子档案封装包都要增加数字签名，使得电子档案部分数据仍要多次封装，而且还导致了电子档案的真实性过分依赖于对第三方的信任。

综上所述，由于目前采用的有些安全保障策略很难兼顾真实性和长期可读性的双重要求，导致电子档案安全保障工作难以高效地开展。因此，如何高效地解决电子档案封装包持续更新问题和多次数字签名认证问题，是电子档案管理系统安全保障的关键。

2 基于XML文件访问机制的电子档案安全保障模型

2.1 模型框架。基于XML文件管理机制的电子档案安全保障模型（XML-based Electronic Records Security Protection Model，xERSPM）由访问权限控制智能体ACA、电子档案封装智能体EREA、XML防火墙、数据资源、可信用户等五个部分构成（如图1所示），各部分功能如下：

（1）访问权限控制智能体（ACA）：根据访问权限控制策略，判断用户操作请求是否合法。

（2）电子档案封装智能体（EREA）：是一个XML封装模块，ACA决策的实际执行者。EREA的主要职责有三个：①将用户的请求采用XACML协议封装成XML；②按照特定规则将电子档案数据封装成包含敏感性信息的XML文件；③通过XML签名技术，承担电子档案安全性保障工作。

（3）XML防火墙：应用程序级的XML文件防火墙，它可以阻止未经ACA授权或ERAE处理的电子档案流出电子档案管理系统，确保电子档案的安全性。

（4）数据资源：关系型数据库或者XML等格式电子文件的集合，包括电子档案数据库和其它数据库资源。其中，电子档案数据库包括电子档案身份性数据（ERIMD）和电子档案管理性数据（ERMMD）。

（5）可信用户：来自身份确认的用户实体或者应用程序的可信XML文件访问请求。

图1：xERSPM模型的构成

2.2 电子档案访问与封装。xERSPM模型的电子档案访问及XML封装具体流程步骤（如图2所示）为：

Step1：用户通过电子档案管理系统的身份认证系统（Identity Authority System，IAS）确认，成为可信用户，并将电子档案访问请求连同身份验证信息一起提交给电子档案管理系统的ERAE。只有具有IAS签发的合法数字证书的电子档案管理系统（电子政务系统、OA系统等）的用户才能成为可信用户。

Step2：ERAE根据可信用户提交的身份验证信息，从IAS中获得该可信用户的数字证书，按照XACML协议将可信用户的数字证书和电子档案访问请求转换为XML格式（标识为RQxmli）并将RQxmli提交给ACA。

Step3：ACA根据RQxmli中的请求信息，从数据资源中得到相应电子档案访问策略，验证RQxmli的合法性，并将验证结果Reli返回给ERAE。如果用户本次访问请求合法，Reli值为真，否则为假。

Step4：ERAE首先根据RQxmli的用户信息和访问请求，从数据资源中得到电子档案数据{File}i和权限列表ACLi；然后按照散列函数（如MD5）生成{File}i的数字摘要DDi；最后根据XML描述规则将{File}i、ACLi和DDi封装成XML格式的电子文件Filexmli。

图2：xERSPM模型的电子档案访问及XML封装流程

Step5 ERAE使用XML签名算法采用私钥对Filexmli进行XML签名，生成新的XML文件SFilexmli。

Step6： ERAE生成一个对称秘钥SKeyi，使用SM4算法采用SKeyi加密SFilexmli得到密文Cipherxmli。

Step7：ERAE使用SM2算法采用可信用户的公钥加密SKeyi得到密文Cipherskeyi，并将Cipherskeyi和Cipherxmli传输给目标可信用户。

Step8：可信用户得到Cipherskeyi和Cipherxmli后，首先利用私钥解密Cipherskeyi得到SKeyi，然后利用SKeyi解密Cipherxmli得到SFilexmli。

Step9：根据SFilexmli中的ERAE公钥和数字摘要DDi，验证XML签名的真实性和Filexmli的完整性。

Step10：解析XML文件，提取{File}i中的电子档案实体数据、电子档案元数据等数据，按照特定格式解码还原电子档案，完成本次电子档案访问。

2.3 分类封装与XML签名。通常电子档案数据可能是图片、WORD文本、电子表格、多媒体文件，也可能是电子邮件、网页等。在xERSPM模型中，电子档案实体数据及其元数据均被封装成XML文件。为此，首先采用Base64编码器将它们编码为ASCII字符串，然后按照预定格式和要求进行XML文件封装。

为了解决电子档案面临的多次封装问题，在xERSPM模型的XML文件访问控制保障下，本文通过改进分体式METS技术，设计了一种新的电子档案封装技术，即xERSPM封装技术。首先，根据电子档案数据在归档后是否会改变，将电子档案数据分为身份性数据和过程性数据等两大类。身份性数据是电子档案的身份性数据，一经归档就不能改变，它包括电子档案实体数据和描述性元数据两部分内容；过程性数据描述了电子档案的归档、鉴定、处置、移交、利用等环节。然后，将身份性数据和过程性数据分别封装成两个XML文件，即xFile02和xFile01。

在身份性数据文件xFile02中，描述性元数据和档案实体分别封装在“描述性元数据块”和“文件列表块”中，而“文件列表块”记录的是电子档案文件链接。为了保证电子档案的“四性”，首先采用散列函数生成身份性数据的数字摘要，然后采用SM2算法通过私钥加密该数字摘要，将加密结果封装到xFile02的数字签名块中（标识为Signxf02）。同时，在保存xFile02之前，ERAE要先进行XML签名。

在过程性数据文件xFile01中，过程性数据被封装在“管理性元数据块”中。“数字签名块”部分的每一个数字签名由身份性数字摘要和过程性数字摘要组成。xERSPM封装技术要求xFile01封装用户必须对这些元数据进行签名。生成一个数字签名，需要完成3个步骤：首先，根据散列函数生成的xFile01的过程性数字摘要；然后，引用Signxf02得到身份性数字摘要；最后，使用SM2算法使用私钥加密过程性和身份性数字摘要。同时，在保存xFile01之前，ERAE要先进行XML签名。

3 xERSPM模型电子档案安全保障分析

3.1 敏感性信息嵌入与XML签名技术为电子档案长期保存提供了安全保障。xERSPM模型的ERAE在执行基于XML封装时，首先要根据ACA授权从数据资源中得到用户的请求访问的文件资源和访问权限列表，然后生成数字摘要，最后采用XML文件格式封装数字摘要并使用私钥进行XML签名。数字摘要是ERAE通过散列函数生成的，使用私钥进行了签名，因此除了ERAE以外，无论是任何用户都无法篡改XML文件内容以及包含的用户访问权限列表。同时，XML应用防火墙对用户访问权限列表的验证和权限的控制，可以在物理介质层面拦截非法的跨网络文件访问，保证政务网或互联网系统用户无法从电子档案管理系统中非法获得电子档案数据。

3.2 基于SM2和SM4的数字加密为电子档案访问提供了安全保障。通过SM4算法使用对称密钥加密ERAE生成XML文件，不仅提高了XML文件加密的效率，还保证了电子档案管理系统可以满足《GB/T25056-2010证书认证系统密码及其相关安全技术规范》等标准规范提出的新要求。此外，通过SM2算法使用访问请求用户的私钥加密上述对称密钥，使得只有合法用户才能解密对称密钥，进而解密电子档案，保证了电子档案不会被其它用户非法获得。

3.3 分类封装技术和XML签名技术为电子档案的“四性”提供了安全保障。一方面，对于身份性数据， xFile02记录了加密后的身份性数字摘要，保证了身份性数据封装操作的可信性、不可抵赖性和完整性。在身份性数据封装完成后，ERAE会对其XML签名保存，因此除非ACA和ERAE许可，否则任何用户都无法修改或再次生成xFile02，确保了身份性数据的完整性、真实性。另一方面，对于过程性数据，xFile01记录了加密后的过程性数据数字摘要和xFile02的数字签名，保证了电子档案的完整性、可信性和不可抵赖性。在过程性数据封装完成后，ERAE会对其签名保存，确保了身份性数据的完整性、真实性。此外，电子档案的身份性数据和过程性数据分开封装，当电子档案管理活动产生的管理性元数只会导致xFile01多次封装，降低了电子档案安全保障措施的内在安全风险，有利于电子档案永久性保存。同时，在xERSPM模型中，无论是电子档案管理系统用户还是电子政务系统或者互联网用户，对电子档案执行的访问都须经过ERAE、ACA和XML应用防火墙构成的三级安全性认证。因此，即使在缺少权威的第三方CA认证，档案管理系统也可以保证数字签名的真实性。

4 结语

电子档案安全保障是电子政务环境中电子档案管理的关键性技术问题。本文构建的电子档案安全保障xERSPM模型将操作权限列表和数字摘要等作为敏感性信息封装到XML中，并采用SM2非对称加密技术对操作权限列表和数字摘要等敏感性信息加密和签名，不仅可以通过访问权限控制智能体阻止未授权用户获取或操作电子档案，也可以借助XML应用防火墙阻止未经授权的电子档案在企业政务网、企业内网或者互联网上传播，确保了电子档案的安全性和真实性。同时，在xERSPM模型的XML文件访问机制控制下，采用电子档案数据分类封装、数字摘要、XML签名和SM2与SM4混合加密等技术不仅可以兼顾电子档案真实性和长期可读性的双重要求，可以满足我国新时期对电子档案管理系统提出的安全性新要求。

*本文系河南省科技厅科技攻关资助项目 “基于政务网的电子文件管理系统研究”（编号：142102210120）和“基于数据关联分析的网络安管平台研发”（编号：162102210047）；河南省科技厅基础前沿资助项目“基于透明加密的网络安全模型及稳定性研究”（编号：142300410014）的阶段成果。

参考文献：

[1]陈永生，侯衡等.电子政务系统中的档案管理：文件归档[J].档案学研究，2015（3）：10～20.

[2]冯馨雨，李珂.河南省直单位电子文件形成与归档情况调查报告[J].档案管理2015（2）：59～61+44.

[3]陈永生，苏焕宁等.电子政务系统中的档案管理：安全保障[J].档案学研究，2015（4）：29～40.

[4]程妍妍.国际电子文件元数据封装方法VEO和METS的比较研究[J].现代图书情报技术， 2011（10）： 7～11.

代码访问安全的原理与策略研究 篇12

关键词：信息安全,远程代码,代码访问安全,沙盒

1 代码访问的安全问题

随着网络技术的发展,现在的计算机应用越来越大量使用着来自远程的未知主机的代码,包括嵌入在邮件、文档或是从网络下载的多媒体数据中的代码,这也为恶意代码的传播拓宽了途径,带来了越来越多的安全方面的问题。恶意代码可能会分析窃取系统信息,或者通过写内存导致系统崩溃,甚至还可以修改、删除用户个人文件。

大多数系统提供的安全机制仅是基于用户的登陆及对部分文件和目录的保护,无法防范恶意代码在授权用户不能察觉时运行。更严格的安全机制针是对代码本身展开分析,阻止不安全代码的执行。具有广泛实用性的系统应该允许未知主机的代码在本地运行,不需建立身份认证,而只需建立安全的代码检查与资源保护机制[1,2]。

2 基于沙盒的代码访问安全性控制

2.1 沙盒模型

沙盒(sandbox)主要用于为一些来源不可信、具备破坏力或无法判定程序意图的程序提供试验环境,可以使用沙盒运行下载到计算机上的部分受信任的应用程序partial-trust Web application,也可以使用沙盒测试将分发的、将在部分受信任的环境(例如Intranet)中运行的应用程序[3]。沙盒技术的原理是限制授予应用程序的代码访问权限,并通过重定向把程序生成和修改的文件定向到受控制的特定路径中。当某个程序试图发挥作用时,系统的安全控制部件先让它在沙盒中运行,如果该程序含有恶意行为,则禁止程序的进一步运行,以此限制其对真实系统造成危害。

2.2 沙盒的实现和验证的对象

沙盒模式为不可信代码提供了一个受限的运行环境,沙盒主机将为指定代码特别分配代码地址,使其操作严格局限于沙盒中。实现沙盒有两种方法:1)插入对地址进行条件检查的操作,如果地址非法则产生异常;2)简单覆盖对应沙盒地址的高比特位,使沙盒内的内容失效。第一种方法更适合调试,而第二种方法系统开销小一些。当然,为充分测试程序,沙盒会模拟系统为程序授权,例如,浏览器下载的控件使用Internet权限集运行,局域网共享上的应用程序使用Local Intranet权限集运行[4]。

系统为沙盒设置了安全事件管理器,以确定沙盒验证的对象,对具备特征的远程代码的操作实施允许或禁止。在代码试图执行包含风险的操作时,沙盒首先向安全管理器询问此操作是否获许,只有获得准许才能执行,否则,将产生一个安全异常并向控制器报告出错信息。一般地,安全管理器认为如下操作是包含风险的:对本地文件的读写;执行操作系统命令或本地代码;载入一个直接调用本地方法的新的动态库;与远程主机的机器建立连接;新建进程等。安全管理器在启动时载入,在沙盒的运行过程中,它不能被扩展、重载或替代。

2.3 代码访问安全性控制

代码访问安全性控制(code access security,CAS)是基于沙盒的代码信任机制。CAS根据代码来源或代码特征标识对代码实施分级信任,并动态降低某些充分信任代码(fully-trusted code)拥有的不必要的高权限,减少系统风险。在面临恶意代码的攻击时,CAS可充分抵御攻击造成的危害。CAS在系统的运行时环境(runtime environment)实施安全策略,根据受检代码的安全性鉴定,进行相应的许可授权;如发现恶意代码则终止之。

3 安全的代码访问策略

主机系统利用沙盒检测和排除不安全的代码对系统造成的威胁,另一方面,代码开发者也应该熟悉通用的安全策略,才能开发出既广泛适用又安全可靠的代码。以下列举一些通用的代码访问的安全策略。

3.1 类型安全

类型安全指代码只访问被授权的系统资源。例如,只用定义完善的公共接口访问对象,而不去读取其他对象的私有字段值。在Java语言的即时编译阶段(JIT),编译器的验证过程要实时检查将编译为本机代码的方法和元数据,而Microsoft.NET的中间语言(MSIL)的编译阶段也将验证代码是否为类型安全的,除非代码具有忽略验证的特权。

类型安全在程序集隔离和强制安全性中起着至关重要的作用。程序集隔离有助于确保程序集之间不会传播负面影响,且通过降低模块耦合可提高应用程序的可移植性。如果代码不是类型安全的,则可能会出现越界访问,其副作用是为恶意程序提供了入侵的途径,危害到主机的系统安全。

3.2 语法安全

使用定义完善的语法机制,如基于属性的声明式调用(Declarative calls)和基于新建对象的强制式调用(imperative calls),与运行时的系统安全特性实现交互。

在代码中,许可请求和所有其它形式的声明式安全是作为定置属性被指定的,因此声明式调用可以使程序员直接在组合代码的元数据中为组合指定安全需求。例如,声明式安全可用于类的调用者在调用类的方法前检查该方法是否是被信任的主机或服务签名的。强制式调用是直接在代码中实现的,程序员可根据安全堆栈的状态决定对当前方法给予或拒绝许可。例如,当一个方法请求访问一个特定的文件时,如果调用者没有被授予必需的许可权限,那么请求失败。因为强制式安全是通过程序实现的,所以可满足系统安全的动态需求,如对一个特定文件的访问权限可根据其它系统信息的变化,通过代码实现动态授权。

3.3 为代码访问声明请求

远程代码应在组件作用域内,明确声明运行时所需的许可。通过此声明,代码在装载入内存时,运行时环境将首先评估其许可请求,并基于安全策略决定组件可获得何种级别的许可授权,本地安全策略将最终决定远程代码所能获得授予的最大许可。请求本身不应使运行时环境为代码提供过高的访问权限;另一方面,访问请求应更着重于说明何种访问是应被拒绝的,以免被恶意代码间接利用。

3.4 使用安全类库

安全类库(Secure Class Libraries)定义了CAS指定的代码访问的权限。程序员需要了解各类操作所需的权限并在代码中提出合适的请求。安全类库还规定了其他库函数的安全需求,包括库的调用者在访问库所定义的资源时必须具备何种许可。例如,某库中有一个需要创建文件的方法,则安全的类库实现了对方法的调用者是否具有创建文件的权限的检查。即使本地方法的代码是可信的,安全类库还会进一步检查本地方法的调用者的权限。

使用安全类库无法减少程序员在书写代码时犯错的可能性,但如果程序员要访问受保护的系统资源,利用安全类库对潜在的安全问题的严格控制和预防措施,将可有效降低应用程序的安全风险。

4 结束语

远程代码可能对本地系统造成危害。从代码执行主机角度考虑,利用基于沙盒的代码访问安全性控制,在可控范围内测试代码,可有效对抗恶意代码的攻击。从代码编写者角度考虑,为配合主机安全策略,应使用安全的代码访问原则来开发程序,提高程序的安全性和适用性。随着远程代码应用的多样化和技术更新,其带来安全隐忧一直未得到完善的解决,代码访问安全控制的优化和综合应用的研究将是一个持续发展的过程。

参考文献

[1]张燕,吴星.恶意代码及防护技术探讨[J].电脑与信息技术,2006,12:81-84.

[2]吴建刚,鲁士文.针对恶意代码的行为阻断方法研究[J].微电子学与计算机,2004,21(2):78-80.

[3]王洋,王钦.沙盒安全技术的发展研究[J].软件导刊,2009,8:152-153.