引言
企业云存储，又称企业网盘，是基于云计算理念推出的企业数据网络存储和管理解决方案，利用互联网后台数据中心的海量计算和存储能力为企业提供数据汇总分发、存储备份和管理等服务。企业云存储必须保证企业数据的安全性，包括保密性、完整性和可用性。其中数据的保密性又包括两个方面：ａ）对数据进行加密，确保非本企业的用户（被授权的除外）以及云存储运营商都无法获得本企业数据的明文；ｂ）对数据进行访问控制，确保只有被授权的本企业用户才能访问特定的数据，这也是本文研究的内容。
目前市场上比较流行的企业云存储产品有联想企业网盘、网易企业网盘和１１５企业网盘等。它们的访问控制方案基本上都是采用自主访问控制（ｄｉｓｃｒｅｔｉｏｎａｒｙａｃｃｅｓｓｃｏｎｔｒｏｌ，ＤＡＣ）和基于角色访问控制（ｒｏｌｅｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏｌ，ＲＢＡＣ）模型。但这两种模型无法满足企业云存储的应用需求，主要表现为：ａ）随着用户和资源数量的增长，ＤＡＣ中访问控制列表（ａｃｃｅｓｓｃｏｎｔｒｏｌｌｉｓｔ，ＡＣＬ）的规模急剧增加，难以管理和维护；ｂ）若要进行细粒度的访问控制，必须对用户进行精确区分，从而使ＲＢＡＣ需要定义大量的用户角色，这给角色的分配和管理带来困难；ｃ）它们都是静态的授权机制，没有考虑上下文环境对授权的影响。
基于属性的访问控制（ａｔｔｒｉｂｕｔｅｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏｌ，ＡＢＡＣ）是将相关实体（如主体、资源和环境等）的属性作为授权的基础来进行访问决策，它能解决复杂信息系统中的细粒度访问控制和大规模用户动态扩展的问题，为开放网络环境提供了较理想的访问控制方案。特别地，如果将身份、角色以及资源安全密级等信息也抽象化为实体属性，ＡＢＡＣ则能实现传统ＩＢＡＣ（ｉｄｅｎｔｉｔｙｂａｓｅｄａｃｃｅｓｓｃｏｎｔｒｏｌ，基于身份的访问控制）、ＲＢＡＣ和ＭＡＣ（ｍａｎｄａｔｏｒｙａｃｃｅｓｓｃｏｎｔｒｏｌ，强制访问控制）模型的功能。
ＡＢＡＣ基于主体、资源和环境等实体的属性来制定访问规则（或策略），并依照访问规则来进行访问决策，因而访问规则的描述是ＡＢＡＣ研究的关键问题之一。ＸＡＣＭＬ（ｅｘｔｅｎｓｉｂｌｅａｃｃｅｓｓｃｏｎｔｒｏｌｍａｒｋｕｐｌａｎｇｕａｇｅ，可扩展的访问控制标记语言）是一种基于ＸＭＬ的开放标准语言，它为ＡＢＡＣ提供了利用属性进行访问控制的策略描述语言，并给出了基本的ＡＢＡＣ授权框架，是ＡＢＡＣ策略描述语言的理想选择。但在ＸＡＣＭＬ中，访问请求和访问规则都采用ＸＭＬ文件来描述，决策时由于需要解析这两个ＸＭＬ文件，因而运行开销较大。另外，访问规则文件中的ＸＭＬ标签很复杂，需要由专业人士编写。基于属性的加密体制是ＡＢＡＣ的一种应用方式，它将数据加密和访问控制融为一体，让密文和密钥分别对应一个访问结构（规则）和一个属性集合（或反过来），只有当属性集合满足访问结构时才能解密数据。但该体制中的访问规则的表达能力很弱，只能表达实体具有或不具有某种属性，而无法将实体属性与数值或字符串等进行比较。规则引擎也可以用来描述访问规则，并且能表达较复杂的规则，但由于规则引擎并不是为访问控制而建立的，故其实现较复杂，运行开销较大。另外，由于规则是存储在一定格式的文本文件中，其解析开销也较大。还有一些文献（如文献［７，８］等）自己定义访问规则的形式，并自己实现规则的解析和执行，这不但实现工作量巨大，而且在规则的表达能力以及规则的解析和执行效率上也很难具有优势。对于企业云存储的访问控制方案来说：
ａ）用户的每个操作都需要进行访问决策，访问规则的解析和运行开销要小；
ｂ）访问规则可能由普通用户制定，规则的编写要很容易；
ｃ）为了进行精细的访问控制，规则的表达能力要很强。因此，现有的ＡＢＡＣ方案无法满足企业云存储的应用需求。为此，本文提出了一种满足上述需求的适合企业云存储应用的ＡＢＡＣ方案。此外，考虑到云存储中资源数量巨大和层次结构的特点，该方案允许继承访问规则，以简化访问规则的制定和减小访问规则的存储空间。
1 企业云存储系统的整体设计
1.1体系结构
企业云存储系统的体系结构如图１所示。
图1企业云存储系统的体系结构
用户可以通过浏览器、PC客户端、手彬平板客户端或API来访问云存储服务器，并且用户的访问操作可分为两类：
a)上／下载文件的操作；b)非上／下载文件的其他操作，如文件的删除、目录的创建等，本文将其称为应用操作。用户的任何访问操作都需要事先询问访问控制器，访问控制器则根据用户属性、被访问资源的属性、当前的环境、操作的类型以及访问规则进行决策。只有当决策结果为true时该操作才被允许执行。其中用户属性和资源属性存储在属性库中，访问规则存储在规则库中。为了保证服务性能，各种服务均采用集群服务器来提供可伸缩的服务。
1．2企业数据的存储
系统采用HDFS(hadoop distributed file system)存储企业的数据文件。HDFS是Google GFS的开源实现，是一个高度容错的分布式文件系统，它能够提供高吞吐量的数据访问，并且可以部署在低廉的硬件上。系统采用单实例多租户的方式为大量企业提供云存储服务，每个企业对应一个英文缩写，其数据存储在“{HDFS数据目录}／{企业英文缩写}”目录下，并采取一定的数据加密措施以保证其安全。
2 实体属性及其存储
2．1实体及实体属性
访问规则中允许使用主体(subject)、资源(resource)和环境(environment)三种实体。主体是指访问者；资源是指被访问的对象，包括文件和目录，每个资源对应一个路径；环境是指访问过程的上下文，包括客户端的类型和访问时间等。
不同类型的企业之间存在差异，它们需要用到的主体(员工)属性也有所不同，例如学校员工的属性需要包括院、系、职称等，而工厂员工的属性需要包括部门、车间、工种等，并且有些企业可能需要用到一些特殊的员工属性。因此，将主体属性分为基本主体属性和企业自定义主体属性。基本主体属性由系统制定，包括用户名、邮箱、姓名等一些通用且必需的员工属性；而企业自定义主体属性则是在企业注册时设置的。企业在注册时会连同注册一个管理员用户(admin)，其拥有管理该企业数据的最高权限。企业普通用户的属性由企业的admin在创建该用户时填写，且只能由admin修改，用户自己无法修改。
资源属性和环境属性由系统制定。资源属性包括路径、类型(文件或目录)、扩展名、大小、哈希值(以上三属性仅针对文件)、修改日期、修改时间、拥有者和密级(普通、机密、绝密或继承，继承表示继承其上级资源的值)；环境属性包括客户端类型、客户端IP、(服务器)负载(0～1之间的数值)、(访问)日期和时间。
2．2属性的存储
环境属性无须存储，由系统根据当时实际情况动态生成；资源属性存储在数据库中。显然，基本主体属性和企业自定义主体属性也需要存储到数据库中。但如果采用传统的关系型数据库来存储企业自定义的主体属性，无论存储还是查询时都需要对多个表进行操作，效率较低。另外，数据库需要存储海量的用户属性和资源属性。因此，系统需要采用一个结构松散且扩展性好的数据库。
MongoDB是一种开源的面向文档的数据库。一个MongoDB服务可以建立多个数据库，每个数据库可以有多个集合(相当于关系数据库中的表)，每个集合可以存放多个文档(相当于关系数据库中的记录)，文档被存储为键／值对的形式。MongoDB具有以下优点：
a)以文档为单位存储，易存储对象类型的数据，很适合存储实体的属性；
b)模式自由，不需要提前设计结构，非常适合存储企业自定义的主体属性，且方便属性的扩展；
e)支持的查询语言非常强大，且支持建立索引以提高查询效率；
d)自动分片功能支持水平的数据库集群，支持云级别的伸缩性。
因此系统选用MongoDB作为数据库。
假设某学校的英文缩写为abc，那么注册时需要用一个集合abc．attr来存储其自定义的主体属性，每个属性用一个文档表示。例如：
｛′ｎａｍｅ′：′学院′，′ｔｙｐｅ′：′枚举′，′值′：′工学院，文学院，…′｝，
｛′ｎａｍｅ′：′职务′，′ｔｙｐｅ′：′枚举′，′值′：′校长，院长，…，无′｝，
｛′ｎａｍｅ′：′入职日期′，′ｔｙｐｅ′：′日期′｝，
…
属性的类型（ｔｙｐｅ）主要有两个作用：ａ）区别该属性的输入方式，如枚举类型的用选择框输入、日期类型的用日期控件输入等；ｂ）提供检查该属性数据是否合法的依据。当增加普通用户时，则在集合ａｂｃ．ｓｔａｆｆ中增加如下文档：
｛
′用户名′：′ｚｈａｎｇｓａｎ′，
′邮箱′：′ｚｈａｎｇｓａｎ＠ａｂｃ．ｅｄｕ．ｃｎ′，
′姓名′：′张三′，
… ＃其他基本主体属性
′学院′：′工学院′，
′职务′：′系主任′，
′入职日期′：′２００６０７０１′，
… ＃其他企业自定义主体属性
｝
3 访问规则的描述及存储
3.1访问权限
由于访问规则的制定者是每个企业的管理员或普通用户，如果权限的种类太多，会使得规则的制定过于复杂且容易出错，因此系统目前只定义了三种权限，即读、写和管理，它们对应的具体操作如表1所示。
表1 权限对应的操作
3．2访问规则的描述
每个资源的每种访问权限都对应一条访问规则。访问规则为一逻辑表达式，由主体、资源和环境三者的属性，算术、逻辑、关系等运算符，以及一些常用的函数构成。其执行结果为布尔值，当执行结果为ti'ue时表示允许访问，为false时表示禁止访问。本文采用Python逻辑表达式描述访问规则，并采用eval函数执行规则。由于Python语言具有灵活且强大的表达能力，加上访问规则表达式只要符合Python的语法，且执行结果为布尔值即可，因此访问规则的表达能力很强，可以制定出非常复杂的控制规则，且书写容易，只需掌握Python的基本语法即可。
在访问规则中，实体用字典变量来表示，实体属性用字典中的元素表示，元素的“键”对应属性名，元素的“值”对应属性值。由于字典变量无须(而对象类需要)事先定义结构，故当对实体属性进行扩展时，无须修改程序代码。本文还规定主体用变量Ｓ表示，资源用变量Ｒ表示，环境用变量Ｅ表示。以下是几条合法的访问规则实例：
规则１ （（Ｓ［′部门′］＝＝′财务部′）ａｎｄ（Ｓ［′职务′］ｉｎ｛′经理′，′副经理′｝））ｏｒ（Ｓ［′姓名′］＝＝′张三′），即允许财务部的经理和副经理，或者张三访问；
规则２ （Ｓ［′用户名′］＝＝Ｒ［′拥有者′］）ｏｒ（Ｓ［′用户名′］＝＝′ａｄｍｉｎ′），即允许资源的拥有者或者管理员访问；
规则３ （ＲＥＭａｔｃｈ（Ｅ［′客户端ＩＰ′］，′＾２０２＼．１９２＼．１５９＼．′））ａｎｄ（ＹｅａｒＳｐａｎ（Ｅ［′日期′］，Ｓ［′入职日期′］）＞２），即允许ＩＰ地址为２０２．１９２．１５９．且入职超过２年的用户访问（ＲＥＭａｔｃｈ和ＹｅａｒＳｐａｎ是本文实现的正则表达式匹配函数与计算两日期之间年份差的函数）；
规则４ （Ｒ［′类型′］＝＝′文件′）ａｎｄ（Ｒ［′大小′］＜２２０）ａｎｄ（Ｒ［′扩展名′］．ｌｏｗｅｒ（）ｎｏｔｉｎ［′．ｅｘｅ′，′．ｂａｔ′］），即允许访问（如上传）大小不超过１ＭＢ的非可执行文件。
3．3访问规则的继承与存储
各企业的资源访问规则连同资源属性一起存储在集合{企业英文缩写}．res中。为了便于文件的归档和分类，以及便于用户的检索，各企业文件的组织通常都是成树状的层次结构。并且考虑到：a)资源(目录或文件)的权限通常默认继承上一级资源(目录)的权限；b)拥有某个资源的读权限通常必须拥有其上级资源的读权限，而拥有某个资源的读权限不一定拥有其下级资源的读权限；c)拥有某个资源的写权限通常也拥有其下级资源的写权限，而拥有某个资源的写权限不一定拥有其上级资源的写权限；d)管理权限与写权限类似。因此，系统为每种权限定义了两个键：一个是inherit(继承)，键值为布尔量；另一个是nile(规则)，键值为逻辑表达式字符串。各资源对应的文档格式如下：
｛
′路径′：′′，
′类型′：′文件′，
… ＃其他资源属性
′访问规则′：｛
′ｒｅａｄ′：｛′ｉｎｈｅｒｉｔ′：，ｒｕｌｅ：′′｝，
′ｗｒｉｔｅ′：｛′ｉｎｈｅｒｉｔ′：，ｒｕｌｅ：′′｝，
′ｍａｎａｇｅ′：｛′ｉｎｈｅｒｉｔ′：，ｒｕｌｅ：′′｝
｝
｝
资源各种权限的键值组合与该资源最终访问规则的对应关系如表２所示。
表２ 资源的最终访问规则
允许访问规则的继承，使得上一级资源的规则可被下一级资源重复利用，不仅大幅度减少了规则存储的空间，而且大幅度减少了规则编写的工作量。另外，本文将inherit为true、rule为空视为默认情况，此时无须存储其键和键值。由于该情况通常会大量出现，从而可进一步节省大量的存储空间。对于各企业的根目录，本文将其密级设置为普通，将其访问规则设置为
′ｒｅａｄ′：｛′ｉｎｈｅｒｉｔ′：ｆａｌｓｅ，′ｒｕｌｅ′：′ｔｒｕｅ′｝，
′ｗｒｉｔｅ′：｛′ｉｎｈｅｒｉｔ′：ｆａｌｓｅ，′ｒｕｌｅ′：
＂（Ｓ［′用户名′］＝＝Ｒ［′拥有者′］）ｏｒ
（Ｓ［′用户名′］＝＝′ａｄｍｉｎ′）＂｝，
′ｍａｎａｇｅ′：｛′ｉｎｈｅｒｉｔ′：ｆａｌｓｅ，′ｒｕｌｅ′：
＂（Ｓ［′用户名′］＝＝Ｒ［′拥有者′］）ｏｒ
（Ｓ［′用户名′］＝＝′ａｄｍｉｎ′）＂｝
4 访问控制器
4．1开发框架
访问控制器采用跨语言的服务开发框架Thrift进行实现。采用该框架，开发人员无须关注RPC(remote procedurecall，远程过程调用)协议层和传输层的实现，而只需首先在Thirft文件中定义数据类型和服务接口；然后用Thrift编译器编译该文件产生相应语言(目前支持C++、Java、Python、PHP等10多种主流语言)的代码文件；最后分别用相应的语言实现服务程序和客户端调用程序。Thrift框架类似于Web Service，但其效率和开发的方便性是Web Service所不能比拟的。
4．2数据类型和服务接口的定义
访问控制服务接口为每种访问操作都定义了一个返回布尔值的访问控制服务函数。Thrift文件的主要代码如下：
ｓｔｒｕｃｔＲｅｑｕｅｓｔＰａｒａｍｅｔｅｒ｛
１：ｓｔｒｉｎｇｅｎｔERPｒｉｓｅ
２：ｓｔｒｉｎｇｕｓｅｒ
３：ＣｌｉｅｎｔＴｙｐｅｃｌｉｅｎｔｔｙｐｅ ／／枚举类型，其定义省略
４：ｓｔｒｉｎｇｃｌｉｅｎｔｉｐ
｝
ｓｅｒｖｉｃｅＡｃｃｅｓｓＣｏｎｔｒｏｌ｛
… ／／省略其他读写操作的访问控制服务函数
ｂｏｏｌＤｉｒＭｏｖｅ（１：ｓｔｒｉｎｇｏｌｄｐａｔｈ，２：ｓｔｒｉｎｇｎｅｗｐａｔｈ，
３：ＲｅｑｕｅｓｔＰａｒａｍｅｔERPａｒａｍｅｔｅｒ），
… ／／省略其他管理操作的访问控制服务函数
ｂｏｏｌＳｅｔＲｕｌｅ（１：ｓｔｒｉｎｇｐａｔｈ，２：ＲｅｑｕｅｓｔＰａｒａｍｅｔERPａｒａｍｅｔｅｒ）
4.3访问控制服务函数的实现
各服务函数在实现时，首先将访问操作转换为对某个（或某些）资源进行某种（或某些）权限的操作，然后调用决策函数Ｄｅｃｉｓｉｏｎ对操作进行决策并返回决策结果，Ｄｅｃｉｓｉｏｎ又是通过调用递归的决策函数ＲｅｃｕｒｓｉｖｅＤｅｃｉｓｉｏｎ进行决策。服务函数也采用Ｐｙｔｈｏｎ来实现。下面以ＤｉｒＭｏｖｅ为例说明服务函数的实现方法。
ｄｅｆＤｉｒＭｏｖｅ（ｓｅｌｆ，ｏｌｄｐａｔｈ，ｎｅｗｐａｔｈ，ｐａｒａｍｅｔｅｒ）：
ｒｅｔｕｒｎ（Ｄｅｃｉｓｉｏｎ（ｏｌｄｐａｔｈ，Ｒｉｇｈｔ．ＭＡＮＡＧＥ，ｐａｒａｍｅｔｅｒ）ａｎｄ
Ｄｅｃｉｓｉｏｎ（Ｆａｔｈｅｒ（ｎｅｗｐａｔｈ），Ｒｉｇｈｔ．ＷＲＩＴＥ，ｐａｒａｍｅｔｅｒ））
ｄｅｆＤｅｃｉｓｉｏｎ（ｒｅｓｏｕｒｃｅｐａｔｈ，ｒｉｇｈｔｔｙｐｅ，ｐａｒａｍｅｔｅｒ）：
4．4 Eval函数的安全性
由于访问规则是由用户编写的，为了防止用户在规则中执行恶意的代码，如利用_import_(“OS”)．system(cmd)执行删除系统文件和窥探系统信息的代码，系统必须对规则中使用的变量和函数进行限制。这可以借助eval(expression[，globals[，locals]])函数的后两个可选参数做到，其中globals用于指定expression中可用的全局变量和函数，locals则用于指定可用的局部变量和函数。本文在实现时允许规则中使用的局部变量为S、R和E，全局函数为REMatch和YearSpan等实现的函数。注意，Python内置的函数(如abs、len等)和内置对象的成员函数(如字符串的lower函数等)是不受这两个可选参数限制的，因而访问规则的表达能力能够得到保证。
5 实例及优势分析
下面将本文提出的ABAC方案与目前流行的三种ABAC方案，即基于XACML的方案、基于属性的加密体制以及基于规则引擎的方案。结合实例进行对比分析，假设需要实现的规则为：仅当主体的用户名等于资源的拥有者且客户端类型为浏览器时才允许访问。
5．1 访问规则的编写难度
基于属性的加密体制无法实现该规则。在本文的方案中，该规则可简单地描述为
（Ｓ［′用户名′］＝＝Ｒ［′拥有者′］）ａｎｄ（Ｅ［′客户端类型′］＝＝′浏览器′）
若采用基于ＸＡＣＭＬ的方案，规则文件的核心部分如下：
可见其规则编写的难度很大，即使采用程序来生成该规则文件，代码也很复杂。Drools是一个应用广泛的开源规则引擎实现，若用其描述该规则，规则文件的核心部分如下：
若采用后者ｅｖａｌ的方式来表达规则，则规则的编写与本文的方案类似，也很容易。
5.2访问规则的执行效率
在一台ＣＰＵ为Ｉｎｔｅｌ酷睿２双核Ｅ８４００（主频３ＧＨｚ）、内存为３ＧＢ的ＷｉｎｄｏｗｓＸＰ机器上，分别测试了该规则在三种方案（基于属性的加密体制除外）下的（本地）执行时间，ＸＡＣＭＬ实现采用的是ＳＵＮ公司的ｓｕｎｘａｃｍｌ，测试结果如下：Ｄｒｏｏｌｓ约为１２００ｍｓ，ｓｕｎｘａｃｍｌ约为２００ｍｓ，本文方案约为０．０４ｍｓ。在前两种方案中，由于分别需要解析文本文件和ＸＭＬ文件，故执行开销较大，而本文方案无须解析文件，规则直接执行，故执行开销很小。特别地，由于规则引擎并不是为访问控制而建立的，Ｄｒｏｏｌｓ还实现了诸如对象修改、规则重复触发等其他功能，故其实现复杂，运行开销很大。此外，由于在基于属性的加密体制中访问控制和加密融为一体，故这里没有测试其执行效率。
5.3访问规则的表达能力
基于属性的加密体制中访问规则的表达能力很弱，只能表达实体具有或不具有某种属性，而无法将实体属性与数值或字符串等进行比较；其他三种方案的访问规则中都能使用各种类型的变量，如算数运算符、关系运算符、逻辑运算符，集合操作，正则表达式等，并且可以自定义函数，从而表达能力都很强，但本文方案中规则的书写更为简洁明了。
6 结束语
目前市场上的企业云存储产品采用的访问控制模型无法满足应用需求，虽然ＡＢＡＣ是非常理想的访问控制模型，但目前已有的ＡＢＡＣ方案在访问规则的描述方面存在着一些不足，仍然无法满足应用需求，为此本文提出了一种新的ＡＢＡＣ方案，并给出了实现方法。该方案的设计与实现具有以下优点：
ａ）采用Ｐｙｔｈｏｎ逻辑表达式描述访问规则，并采用ｅｖａｌ函数执行规则，从而使规则编写容易，表达能力强，且执行效率高；
ｂ）规则中采用字典变量表示实体，从而当扩展实体属性时无须修改程序代码；
ｃ）考虑到云存储中的资源具有层次结构的特点，并根据读、写和管理权限的特点，分别为不同的权限设计了相应的访问规则继承策略，不仅减少了规则存储的空间，而且减少了规则编写的工作量；
ｄ）采用模式自由的ＭｏｎｇｏＤＢ作为属性存储的数据库，便于存储企业自定义的主体属性；
ｅ）采用Ｔｈｒｉｆｔ框架实现访问控制器，从而能提供开放、跨语言、跨平台，且高效的访问控制服务。针对层次结构的资源设计通用的访问控制模型和框架是笔者下一步的工作。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：一种基于属性的企业云存储访问控制方案
相关文章
