本发明属于计算机领域，尤其涉及一种公有云系统的升级方法。在以HDFS(HadoopDistributedFileSystem)为基础架构的公有云系统的升级方法环境下实现了数据升级的安全机制。
背景技术：
云计算作为一种新兴的技术和商业应用模式，近年来无论在业界还是学术界都获得了广泛的关注和巨大的推动。云计算为企业用户展现了美好的愿景。一方面，企业可以将其IT基础架构的管理和维护交由专业的云服务提供商负责，从而更加专注于公司本身的业务；另一方面，也是更为重要一点在于云计算提供的服务是自适应性的，具备灵活的可伸缩性。企业可以根据自身业务需求量大小租赁相应负载的云服务，不会因为公司业务需求量不足造成现有IT资源的浪费，也不会因为公司规模扩大导致旧有IT架构无法负载更大的业务量需求而需要花费昂贵的代价重新架构其IT基础设施。
发明名称“在云存储环境下一种安全存储系统的实现方法”（公开号为102014133A）提供了在云存储环境下一种安全存储系统的实现方法，其特征在于：在服务器中根据用户需求建立信任域，在其中利用公钥基础设施PKI进行身份认证，利用用户空间的文件系统FUSE，实现了存储系统与底层系统无关，利用哈希算法SHA1算法以块为单位对文件计算哈希值，再利用密钥和对称加密算法AES算法对以块为单位对文件块加密，再将文件密文上传到云存储区中的文件服务器，保证了文件的机密性和完整性，文件所有者通过在访问控制列表中指定具有对该文件进行访问的用户及其权限，在发生权限撤销操作时，将对文件进行重新加密的操作推迟，只有当用户对文件内容进行修改时，由该用户重新加密修改内容所在的文件块，系统实行了文件块密钥、安全元数据文件密钥和信任域服务器密钥三层密钥管理，既保证了权限撤销时文件的安全性，又不增加系统的管理负担。此专利的侧重点在于保护云存储上数据的机密性和完整性，实现机制主要是通过加密算法保护数据机密性，通过哈希值来保证数据完整性，其中也粗略的提到了简单的数据访问控制机制，数据保护的粒度较粗。
发明名称“一种分布式安全存储系统”（公开号为101316273）目的在于克服现有基于证书的安全存储系统中安全管理器负载重，用户权限管理复杂的问题。此发明包括连入网络的应用客户端、存储设备、安全与策略管理器和元数据服务器；安全与策略管理器存储并管理全系统的访问控制项、访问控制策略和规则，依据全系统访问控制项、访问控制策略和规则对存储设备进行访问策略控制和权限控制，包括改变访问控制项的优先级和继承规则、添加和删除访问控制项。此专利提出了一种主/从式的安全存储架构，通过成员或者角色的访问控制项来控制主体对数据资源的访问。同本发明类似，其实现针对的对象亦是主/从式的存储架构。不同的是此专利侧重于安全存储架构的设计，仅通过较为简单的自主访问控制列表来保障分布式存储的数据安全。本发明在此基础上更进了一步，主要面向云存储多租户的复杂环境，通过制定了一套灵活通用的强制访问控制安全策略来实现预定的数据升级目标，具备环境直接针对性和更多的安全保障性。
云计算的模式获得了巨大的成功，但研究人员对于其的关注往往多集中于如何提高云平台的可用性、可扩展性、效率性能以及容错性等，却忽视了云平台的安全性。事实上，实现安全可靠的云平台是保证企业用户从传统模式过渡到“云模式”一个关键要素，这是由云本身的特点决定的。在“云时代”，公司的应用运行在远端的云平台上，数据也存储在云上，云底层的IT基础设施由云服务提供商统一管理。对于应用了云计算的企业用户而言，其安全界限远远超出了公司的防火墙以外，企业本身能够控制的范围是非常有限的。公司的应用及数据均涉及到公司的商业机密，一旦泄露损失难以估量，甚至可能对整个公司造成毁灭性的打击。保证云平台的安全性对于云计算的进一步推广至关重要。如果无法为云平台提供可靠的安全保障，企业用户将很难放心的享用云带来的巨大效益。
云存储在云计算体系中位于IAAS(InfrastructureasaService)一层，主要用作云平台的存储基础设施。云存储的数据安全是云安全重要的一环。云存储出现以前，企业的数据都存储在公司内部的数据中心。“云时代”的到来使得企业将其私有数据由内部数据中心迁移到云服务提供商统一管理的公共平台以降低公司的运作成本。然而对于企业用户而言，云存储却是一把双刃剑。云存储给企业带来了收益同时也带来了安全隐患。云存储作为一种多租户的数据存储平台，存放着来自许多企业的内部私有数据。企业用户通过访问这个共享的公共平台获取属于自己公司的数据。由于云存储平台共享的特点，企业绝不希望自己的数据信息被同一平台上的其它租户窃取或者篡改。因此企业间的数据升级是云存储亟待解决的一个重要问题。企业用户依据内部的安全需求需要对来自公司不同部门或者地域的数据进行升级。云存储作为公共的存储平台，应该提供一种灵活多变的安全策略，它能够方便被使用云存储的企业用户定制以满足各个企业不同的安全需求。这也对云存储企业内的数据升级提出了要求。
技术实现要素：
本发明针对公有云这样一个多租户的存储环境，就其数据升级问题，提出了相应的安全解决方案。云存储数据升级的安全目标简单来说是为了保证存储在云间的数据只能被授权的企业用户访问，而无法被恶意的用户访问或者篡改。
本发明提出了一套云存储系统安全升级服务，通过基于安全标签的强制升级策略为企业用户提供了数据升级服务。本文针对云存储的特殊环境，以RBAC(RolebasedAccessControl)为基础，结合组织标签和多种安全属性的逻辑组合，提出了一种灵活的升级策略，一方面能够保证云端不同企业间数据的强升级性，使得企业用户无法越权去访问其它企业用户的数据；另一方面该策略能够保证云存储企业内部数据的适度升级，企业用户可以根据公司自身的安全需求灵活定制企业内的升级策略，升级来自不同部门和地域的数据；最后该策略通过虚拟组织的概念在企业间数据强升级的情况下实现了可能的数据共享，并通过中国墙策略保障同一冲突集中的企业是不能共享数据的。本发明提出的策略遵循通用性原则，适用于公有云，私有云以及混合云。
本发明的技术方案为：
一种公有云系统的升级方法，其步骤为：
1)根据租户的安全需求，在存储云系统主节点中建立该租户安全策略配置，其包括主体层次化的角色模型和客体层次化的Tag模型，角色模型中的角色权限包括：读权限、写权限、执行权限；
2)在存储云系统主节点中创建属于该租户的主体用户，并为主体用户打上该租户角色模型中的角色标签；
3)在存储云系统主节点中将某租户的主体用户创建的客体资源上，打上该租户Tag模型中的Tag标签；
4)根据访问客体资源的角色权限，设置角色主体对访问资源客体的安全访问策略并将其存储到存储云系统的主节点中；所述安全访问策略为：
a)对于主体对客体的读访问，要求主客体所属租户一致，并且存在赋予主体的角色k，使得角色k的读权限表达式在客体标签为真的情况下计算结果也为真；
b)对于主体对客体的写访问，要求主客体所属租户一致，并且存在赋予主体的角色k，使得角色k的写权限表达式在客体标签为真的情况下计算结果也为真；
c)对于主体对客体的执行访问，要求主客体所属租户一致，并且存在赋予主体的角色k，使得角色k的执行权限表达式在客体标签为真的情况下计算结果也为真；
5)主节点根据所述安全访问策略，判断拒绝升级是否通过，如果通过则允许访问，否则拒绝升级。
进一步的，所述主体角色模型为一具有角色继承关系的层次化标签森林，每一标签具有一角色权限。
进一步的，所述客体层次化的Tag模型为一具有继承关系的层次化标签森林。
进一步的，所述主节点采用XML文件存储所述安全策略配置；采用字符串形式表达所述角色权限表达式。
进一步的，所述主节点中设置一哈希表结构的安全配置池，其中，键为租户名称，值包括哈希表结构的角色配置池、标签配置池；所述角色配置池的键为角色名称，值为角色对象；所述标签配置池的键为标签名称，值为标签对象；角色对象通过父指针指向其在所述角色模型中的父节点；标签对象通过父指针指向其在所述Tag模型中的父节点；主节点根据输入的租户信息、以及主体角色名或客体标签名，利用所述安全配置池查找角色对象或标签对象。
进一步的，所述主节点判断拒绝升级是否通过的方法为：主节点将字符串形式表示的角色权限表达式转化成后序表达式树，然后根据给定表达式变量值，利用权限表达式树计算出决策结果。
进一步的，所述主节点采用镜像文件和操作访问日志持久化所述安全策略配置。
进一步的，角色主体对访问资源客体进行升级的方法为：
1)角色主体向主节点发送要访问的文件名，访问的文件偏移量以及要访问客体资源的数据长度；
2)主节点为该角色主体生成访问票据并用集群内共享的密钥对票据进行加密，然后将该角色主体要访问的数据块的标识及其所在数据节点的位置，以及加密后的访问票据发送给该角色主体；
3)该角色主体对于每一个数据块，选择具有该数据块且距离该角色主体最近的数据节点，发送该数据块标识和访问票据，请求访问该数据块；
4)数据节点使用集群内共享的密钥解密访问票据，判定该角色主体是否有权限访问相应的数据块，如果允许访问，则向该角色主体回送数据块的数据，否则拒绝升级。
进一步的，所述访问票据包括：角色主体的标识符、角色主体要访问数据块的数据块标识以及访问的具体操作。
进一步的，对于写访问操作：首先，角色主体远程调用主节点的create方法，开始新文件的创建，主节点采用租约方法为新创建的文件增加排它锁；然后角色主体远程调用主节点的addBlock方法，主节点在接收到addBlock请求后会返回给角色主体一个LocatedBlock对象，其包括新建数据块的标识以及能够写入数据块的数据节点；最后，角色主体远程调用主节点的complete方法，完成新文件的创建。
安全策略设计的目标如下：
1.企业之间数据的强升级性。对于公有云存储而言，云服务提供商必须要严格保障来自不同公司的数据被安全的升级。公有云上存储着来自许多不同企业的数据，同时使用同一云服务提供商服务的某些企业之间甚至是同一块市场的激烈竞争者。一个企业内部的私密数据对其而言是重要的生命线，一旦泄露后果不堪设想，因此必须严格的保障企业和企业间数据的强升级性。
2.灵活的企业内部数据升级。无论对于存储在公有云上来自同一企业不同部门的数据，还是存储在企业内部私有云上的不同部门的数据，都需要进行一定程度的安全升级。企业的每一个部门有自身的职责划分，它们分管企业某一块任务拼图的运作，比如生产部负责产品的制造，人事部负责人才的招聘和管理，以及财务部负责公司的收入和支出管理。根据系统安全的最基本原则“最小特权原则”，安全的系统一方面应该给予主体必不可少的权限，保证所有的主体都能够在赋予的权限之下完成所需要的任务和操作，另一方面也只给予主体必不可少的权限，这样就能够限制每个主体所能进行的操作，确保蓄意或者不小心越权造成的错误和事故导致的损失最小。因此不同部门间的数据也是需要进行一定程度的安全升级以保证最小特权原则。因为公司内部部门存在着一定的协作关系，部分数据的共享在所难免，它们之间数据升级应当具备适当的灵活性，不应当使用企业之间数据的强升级特性。
3.企业之间数据共享的情况。当企业之间有协作关系时，也会存在着一定数据共享的情况。如果双方企业都使用云作为存储平台，那么公有云存储可以成为公司间数据共享的很好媒介平台。企业的应用可以在不用改变数据访问的接口的情况下直接去访问存储在云上的另一个企业的数据。然而企业间数据的共享需求和企业间数据的升级需求存在着很大程度的矛盾和冲突。需要有一种机制能够在保障企业间数据强升级的情况下，完成企业数据的共享。另外一些企业是同一块市场的激烈竞争者，如中国移动和中国联通，中国石油和中国石化。这些公司由于双方利益存在很大的冲突，它们可能不希望与竞争对手共享数据，应当有相关的机制防止误操作或恶意操作导致它们之间数据的共享。
策略设计原则
本发明提出的安全策略基于如下的设计原则：
1.通用性。无论是多个企业共享的公有云，还是企业内部使用的私有云，或者是公有云和私有云构成的混合云，它们都存在着多租户数据升级的安全需求，因此安全策略应该是通用的，能够适用于各种不同的云环境。
2.灵活性。各个企业存在着自身不同的安全需求，因此存在多租户的云存储上的安全策略应当是灵活的，能够适用于各个公司不同的情况。企业用户可以根据自身的安全需求灵活的定制安全策略，实现其安全目标。
3.层次性。此安全策略是主要针对企业用户设计的。大部分企业的划分具有一定的层次性，安全策略中主体和资源客体的属性应该能够体现出企业的这种层次的特性。
具体策略描述
本发明所设计的安全策略是基于RBAC模型的，它实现了文中描述的安全目标，提供了云存储的数据升级服务。策略的核心是基于主客体安全标签的强制升级。本节分为三小节，分别描述主体的安全标签设计，客体的安全标签设计以及基于主客体安全标签的升级规则。文中所指的组织，企业，公司，租户均可认为是同一概念，只是在不同的应用场景中使用。
1>主体安全标签
层次化的角色模型
RBAC模型预先定义了一组具备相应权限的角色(role)，在遵循最小特权原则的基础上为相关用户赋予相应的角色。给用户赋予角色的过程实际上也是为用户赋予一定权限的过程。扩展的RBAC模型更具备灵活性，角色和角色之间可以存在继承的关系。角色继承的意义主要在于不用重复定义一些已经定义过的角色的权限，而是可以通过继承的方式自动承接所有祖先节点的角色权限，在此基础上进行角色权限的特定扩展。显示了三组定义好的角色继承的层次树结构。可以称作角色的森林。
主体安全标签定义
由于每个公司有不同的安全需求，因此其也会有不同的角色定义的需求。因此这里允许每个公司拥有自己不同的角色定义的森林。为了区分不同公司的角色定义，需要在资源访问的主体安全标签内加上特定公司的标签。一方面它可以区分不同公司的角色森林，另一方面它也可以实现公司间数据的升级，关于这一点将在后面说明。
云存储中资源访问的主体标签如下：
<org1，role1，role2，role3，...，rolen>或<org，rolelist>
的示例进一步说明了主体标签的角色定义。
2>客体安全标签
层次化的标签模型
使用标签(Tags)来对资源访问的客体进行标识。如果采用Web上常用的平面标签模型，确实它非常的灵活，但却存在两方面的问题。首先由于它的平面结构，它无法表达公司或者组织内部的层次化机构，这点对于公司而言是很不合理的；其次由于在标签定义上没有控制，很容易造成标签定义爆炸，会定义大量语义相同然而名字不同的标签，给整个系统的维护和运作带来困难。因此我们决定在此基础上对其进行改进，将平面的标签模型进行扩展成为层次化的对象标签模型。
层次化的对象标签模型应用场景如下：首先由公司内部的高层管理人员根据公司需求，按照不同的准则(如地域，部门等)对公司进行具体划分，这样就能构成由很多树构成的森林，树上的每一个节点即代表了这个公司内部的一个可控的标签。通过这种方式，大大限制了系统中存在的标签个数，并且很好的表达出了公司内部的层次化的结构。在层次化的标签模型中，子节点相当于自动继承了其祖先节点的标签，因此也就拥有多个标签。
说明了这种层次化的标签模型，可以称作标签的森林。
客体安全标签定义
同主体的安全标签类似，每个公司也会针对于自身的安全需求来创建自己专属的不同的标签森林。在客体的标签上需要对不同公司的标签进行区分，当然这也是保证公司之间数据升级的需要。
云存储中资源访问的客体标签如下：
<org1，tag1，tag2，tag3，...，tagn>或<org，taglist>
进一步说明了客体标签的定义。
3>升级规则
角色的权限定义
由于系统的强制升级是基于RBAC的，RBAC中的角色脱离了权限的定义是无意义的，本小节主要对角色权限进行了定义。根据客户在云存储的访问需求，这里为每个role分别制定相应的读(R)，写(W)以及执行(X)权限，即为role：(permr，permw，permx)。
权限定义针对云存储上的文件和目录的概念是不一样的，如下所示：
1>针对普通文件的权限定义：
·读权限(R)：对此文件拥有读权限
·写权限(W)：对此文件拥有写权限
·执行权限(X)：针对于云存储的特性，执行权限不适用于普通文件。
2>针对目录/文件夹的权限定义：
·读权限(R)：可以查看此文件夹下的文件和子文件夹列表(类似于允许执行ls操作)
·写权限(W)：可以对此文件夹下创建文件，删除文件，修改文件名
·执行权限(X)：可以进入此文件夹(类似于允许执行cd操作)
对于读，写，执行权限的具体定义是一致的，都是使用客体的Tag标签加上于(&&)，或(||)，非(！)三种逻辑运算符组合构成的权限表达式(expr)。具体定义可以用下面的表达式描述所示.逻辑运算符的优先级为非(！)＞与(&&)＝或(||)，从左到右计算，可以使用括号来改变权限表达式的运算次序。
1.entity:＝{allavailabletags}.
2.predicate:＝{&&，||，！}
ii.expr-＞entity
iii.expr-＞(expr)
iv.expr-＞！expr
v.expr-＞expr&&expr
vi.expr-＞expr//expr
3.perm:＝expr
4.role：<r:permr，w:permw，x:permx>
另外，根据之前的层次性的模型，角色还是自动继承其祖先节点的权限，即读权限还会扩展继承所有祖先的读权限，写权限还会扩展继承所有祖先的写权限，执行权限还会扩展继承所有祖先的执行权限。
访问规则定义
访问规则是整个策略的核心，无论是主体标签还是客体标签的定义都是服务于最终的访问规则的，访问规则才是策略的重点所在。这里针对于读，写，执行权限定义了三套访问规则。
1.预备定义
Tag继承树定义
i>定义explict_tags(o)为客体标签<org，tag1，tag2，，...，tagn>中明确定义的tag集合。
ii>定义implicit_tags(o)为explict_tags(o)中所有tag的祖先tag的集合。
iii>定义all_tags(o)为explict_tags(o)和implicit_tags(o)的并集。
Role继承树定义
i>定义explict_roles(s)为主体标签<org，role1，role2，...，rolen>中明确定义的role集合。
ii>定义implicit_roles(s)为explict_tags(s)中所有role的祖先role的集合。
iii>定义all_roles(s)为explict_roles(s)和implicit_roles(s)的并集。
2.访问规则定义
1)读访问规则
假定有主体S和客体0，主体S能读客体0当且仅当以下条件满足：
a)org(S)＝org(O)，
即要求主客体所属组织一致，并且存在赋予主体的角色k使得此角色的读权限表达式(permr(k))在客体Tag标签为真的情况下计算结果也为真。
2)写访问规则
假定有主体S和客体0，主体S能写客体0当且仅当以下条件满足：
a)org(S)＝org(O)
即要求主客体所属组织一致，并且存在赋予主体的角色k使得此角色的写权限表达式(permw(k))在客体Tag标签为真的情况下计算结果也为真。
3)执行访问规则
假定有主体S和客体0，主体S能执行客体0当且仅当以下条件满足：
a)org(S)＝org(O)
即要求主客体所属组织一致，并且存在赋予主体的角色k使得此角色的执行权限表达式(permx(k))在客体Tag标签为真的情况下计算结果也为真。
4>虚拟组织和中国墙
企业之间有时因为相互协作关系存在着数据的共享，然而企业间数据的强升级和企业数据的共享是相悖的。为了满足企业之间数据共享的特殊需求，这里引入虚拟组织的概念。虚拟组织指的是希望共享数据的几个企业共同建立的虚拟的组织，在现实中是不存在的。虚拟组织也可以有自己的用户和数据，通过为存在协作关系的企业用户之间创建虚拟组织的用户，并给这些企业某些私有数据打上虚拟组织的标签，那么根据之前定义升级规则便可以实现企业间数据的共享。此时，主体和共享的客体的企业属性都是此虚拟组织，它们是匹配的，因此允许主体访问客体资源。
某些企业用户之间共享同一市场，之间存在着激烈的竞争关系，如中国移动和中国联通，中国石油和中国石化。这些公司由于双方利益存在很大的冲突，它们可能不希望和竞争对手共享数据，应当有相关的机制防止误操作或恶意操作导致它们之间数据的共享。这里可以应用中国墙模型(参考：THECHINESEWALLSECURITYPOLICY，Dr.DavidF.C.BrewerandDr.MichaelJ.Nash)，通过制定冲突集，保证同一冲突集内的企业无法建立虚拟组织。如将中国移动和中国联通放置在同一冲突集内，将中国石油和中国石化放在另一冲突集内，这样便可以防止它们数据的共享。
与现有技术相比，本发明的积极效果为：
本发明针对云存储的特殊环境，以RBAC(RolebasedAccessControl)为基础，结合组织标签和多种安全属性的逻辑组合，提出了一种灵活的升级策略，一方面能够保证云端不同企业间数据的强升级性，使得企业用户无法越权去访问其它企业用户的数据；另一方面该策略能够保证云存储企业内部数据的适度升级，企业用户可以根据公司自身的安全需求灵活定制企业内的升级策略，升级来自不同部门和地域的数据；最后该策略通过虚拟组织的概念在企业间数据强升级的情况下实现了可能的数据共享，并通过中国墙策略保障同一冲突集中的企业是不能共享数据的。本发明提出的策略遵循通用性原则，适用于公有云，私有云以及混合云。
具体实施方式
本发明基于Hadoop分布式文件系统(HDFS)开发了数据升级的安全机制。分布式文件系统广泛用作云存储的底层基础设施，商业化的云存储Cloudera其底层使用正是HDFS。使用开源的HDFS开发安全机制原型有利于对整个系统的效果评估。
升级基于HDFS架构的安全体系结构设计。
原型系统的核心是安全决策模块。为了判定主体是否有权限访问资源客体，安全决策模块需要首先获取主客体安全标签的信息及当前系统的安全策略。在HDFS中，文件系统的元信息存储在主节点Namenode一端，因此安全标签及安全策略这类安全元信息按照原有设计也应当存储在Namenode端，并由Namenode加以管理；从安全的角度上看亦是如此。如果将敏感的安全元信息分布在集群内多个Datanode节点上，那么势必增加安全的风险，因为整个系统需要保护的安全界限明显的增大了，保护单节点的Namenode会比保护多节点的Datanode要简单的多；将安全元信息放在单节点的Namenode上也便于系统的管理维护。由此可见，将系统安全元信息放在Namenode一端是良好的设计，它既遵循了原有系统的设计也便于管理维护，并且安全可靠性更高。
Namenode端的安全决策模块在作出升级判定后，需要在整个分布式的系统中实施安全决策，包括数据块读写请求决策的实施。安全决策的实施是通过网络节点的交互完成的，包括DFSClient和Namenode之间元信息交互，DFSClient和Datanode的数据流交互以及在写数据块过程中Datanode和Datanode之间的数据流交互。
在DFSClient端提供了一些管理命令，通过这些命令接口可以查询修改Namenode上的安全元信息。当然绝大数这些命令是提供给管理员的，普通用户没有权限使用这些命令。
下面说明各个关键模块的设计与实现。
1>主客体安全标签的设计与实现
依照HDFS的原有设计，为了保证系统的性能，文件系统的元信息都是保存在Namenode内存中以供运行时快速访问。因此对于需要经常访问的主客体安全标签这类元信息，也应当存放在Namenode内存中以防止降低系统效率。客体标签可以存放在代表文件目录树节点的类INode内，但由于不存在现有的数据结构存放主体信息，主体标签需新建数据结构保存，可以通过哈希表的索引结构存储系统中所有的主体标签，在需要获取相应主体标签时根据主体名从哈希表中获取。
内存中的主客体安全标签信息需要实现持久化机制以在系统断电后长期保存。Namenode同时采用镜像文件fsimage和操作访问日志edits持久化内存中系统的元信息。镜像文件fsimage记录了整个文件系统的元信息，而操作日志edits则记录运行时对元信息的更新操作。Namenode每次启动时会首先载入镜像文件fsimage以装载系统的元信息，并在此基础上重放操作日志edits中的每一条操作记录将内存中的元信息更改至最新。在系统运行时，如果系统有操作修改了Namenode内存中的元信息，Namenode会同时向操作日志写入该条操作的信息，以便下次重放。系统会不定时的将内存中最新的元信息重新写入fsimage，并清空操作日志。通过应用操作日志的方法，Namenode可以避免每次系统元信息更新都需要重新写入整个系统元信息镜像以防止系统异常崩溃导致的元信息更新丢失，同时还可以减少系统I/O保证性能。因此通过镜像文件fsimage和操作日志edits部分的代码修改来实现主客体安全标签的持久化/非持久化。
2>系统安全策略的设计与实现
安全策略是另一类需要经常访问的信息。每个组织均可根据内部安全需求建立特有的主体角色模型和客体标签模型，存放在以xml文件表示的安全策略配置文件中。XML层次化的格式使得它能够很好的适应这种角色。安全策略配置文件中描述了每个组织特有的角色层次树和Tag层次树，并为组织内所有角色定义了以字符串形式表达的读，写以及执行所要求的权限表达式。
系统在初始化时载入所有企业用户的安全策略配置以提升运行时效率。在Namenode内存中为每个企业维护一个Role配置池(RolePool)和一个Tag配置池(TagPool)，其中的Role对象和Tag对象即保存了企业用户相关的安全策略配置。在系统运行时刻，如果主体需要引用Role标签或客体需要引用Tag标签，可以直接通过安全配置池快速获取，而不用反复读取安全配置文件进行耗时的I/O操作。
安全配置池通过两级索引可以快速定位到具体的Role对象和Tag对象。OrganizationPool为每个组织维护一个配置池，使用的是哈希表的索引结构，其主键为组织的名字(orgName)，值包含Role配置池(rolepool)和Tag配置池(tagpool)。Role配置池和Tag配置池同样使用的是哈希表结构。Role配置池的键为角色的名字，值为角色对象(RoleObject)。Tag配置池的键为Tag的名字，值为Tag对象(TagObject)。Role对象使用parent指针指向在角色模型中的父亲节点，Role对象通过parent指针这种相互引用的关系形成了一种层次性的结构，但并不是所有的Role都有这种祖先后辈的联系。从最上层看就形成了一片Role对象的森林。对于Tag对象也一样，Tag对象使用parent指针相互引用最终也形成了一片Tag对象的森林。
组织内的主体用户可以由该组织的管理员创建，主体的组织标签取决于创建它的管理员所属的组织，即某组织管理员创建的主体用户都隶属于该组织，该管理员不能创建其它组织的用户；客体资源的组织标签由创建客体的主体用户决定，即某组织的主体用户创建的客体资源默认属于该组织所有。组织管理员可以为组织内的主体用户增加角色标签，亦可为组织内的客体资源增加Tag标签，前提是该角色标签和Tag标签都在该组织的安全配置中有定义。在组织管理员为主体或客体执行增加角色标签或者Tag标签时，系统可以根据管理员用户所属的组织信息以及管理员提供的主体角色名或客体Tag名快速通过两次哈希表的查找操作迅速定位到相应的Role对象或者Tag对象，并且这些Role对象和Tag对象已经通过parent指针形成了树形的层次性结构。这样可以避免系统在运行时反复的读写安全策略配置文件，减少I/O操作，极大提高系统的性能。
3>安全决策模块的设计与实现
安全决策模块的作用在于判定给定主体是否有权限访问给定的客体。由于角色权限的定义是由Tag标签变量和逻辑运算符所组成的逻辑表达式，如何在给定客体Tag集合的情况下高效的计算出权限逻辑表达式的值是非常关键。云存储系统在同一时间内需要负荷来自不同公司的成千上万的客户的访问，而权限判定是客户在访问每一个文件的时候都必须通过的，如果权限判定不够高效，一方面会降低客户端的访问速度，另一方面也由于服务器的负载增大导致单位时间内可以访问云存储的客户数量减少。因此升级决策判定的性能是非常重要的。
为了把服务性能的损耗降低到最小，项目原型在Hadoop分布式文件系统初始化的时候将所有角色以字符串形式表示的权限表达式转化成后序表达式树这种中间形式。在系统运行时，HDFS可以直接根据权限表达式树很快计算出决策结果，而不用再对权限表达式做字符串分析。这样一方面可以减少运行时客户访问文件系统的时间，提升系统的性能；另外一方面也可以避免同一角色在访问不同文件时反复对相同权限表达式进行分析，避免重复工作。
权限表达式计算的算法思想如下：
1>系统初始化时动作：
把角色权限定义的逻辑表达式转化为以表达树形式描述的后序表达式(Postfixrepresentation，又称逆波兰序)。
2>系统运行时动作：
在给定表达式变量值(即Tag标签值)输入的情况下，通过内存中的后序表达式树快速计算权限表达式的值。
4>安全决策的实施
读请求的安全控制
根据电影票售票模式，HDFS可以采用类似的安全实施方式，称为”基于票据(Ticket)的升级”。客户端在访问Namenode以获取数据块的位置信息时，Namenode会首先进行根据主客体的安全标签相关安全决策判定，如果通过的话则会为客户端生成一个包含了访问决策的票据。客户端在访问Datanode上的数据时需要向Datanode出示Namenode授予的票据才能够正常的访问数据。为了防止恶意的客户端对票据进行伪造和篡改，Namenode使用和所有Datanode共享的一组密钥对其进行加密，因此只有Datanode才能够解密票据查看其中的访问决策，从而判定当前的客户端是否有权利访问相关的数据块。
根据HDFS客户端的访问流程，在加上基于Ticket的升级：
加粗的部分即是修改了HDFS网络通信的部分，主要是传递新增加的票据信息，其它的部分均是HDFS原本存在的部分。整个流程如下所述：
客户端向Namenode发送要访问的文件名(filename)，访问的文件偏移量以及要访问的数据的长度(length)。
Namenode在判定客户端对文件的访问权限通过之后，生成访问票据并用集群内共享的密钥对票据进行加密。Namenode向客户端返回其要访问的多个数据块的标识(blockhandle)以及它们所处的Datanode的位置(blocklocations)，最后是附加的加密后的访问票据。
客户端在获取了数据块的具体位置以及访问票据之后，对于每一个数据块选择离它最近DataNode，向其发送客户端要访问的数据块标识(blockhandle)和访问票据(AccessTicket)，请求访问数据块。由于访问票据被加密过了，客户端是不能随便篡改其中的内容的。
Datanode取得AccessTicket之后，使用集群内共享的密钥解密AccessTicket判定当前客户端是否有权限访问相应的block。如果允许访问，则向client回送数据块的数据，否则拒绝客户端的访问。
AccessTicket包含了安全决策的信息，是由Namenode生成，之后通过Client转发给Datanode，其定义如下：
AccessTicket＝E{user-id，<fileblockIDs>，op}secret
访问票据包括访问资源主体的标识符(user-id)，主体要的所有的blockid(<fileblockIDs>)，以及访问的具体操作(op)。为了防止客户端篡改Ticket，Ticket使用HDFS集群内共享的一组密钥(secret)加密。
写请求的安全控制
HDFS0.18版本只支持创建写操作(create)，文件一旦创建成功后就不能再被修改，这样也部分简化了写请求安全控制的工作量。
客户端在分布式文件系统上创建新的文件时，遵循如下步骤：
1.客户端(即租户的主体用户，角色主体)开始新文件的创建
客户端通过rpc远程调用Namenode实现的create方法，开始新文件的创建。Namenode采用了一种称为租约(Lease)的方法，为新创建的文件增加排它锁。除了启动文件创建的用户可以访问此文件外，其他用户是不能访问文件的。此时尚未完成创建的文件在Namenode内存中以INodeFileUnderConstruction对象表示。
2.客户端写入文件的数据块
对于每一个数据块，执行如下操作：
客户端rpc远程调用Namenode实现的addBlock方法，为文件新增数据块。Namenode在接收到addBlock请求后会返回给客户端一个LocatedBlock对象。此对象中包含了新建数据块的标识，并说明了应该往哪几个Datanode中写入数据块。
客户端和LocatedBlock对象中包含的Datanode之间建立起pipeline连接，通过网络I/O流往Datanode中写入数据块的数据。
3.客户端完成文件的创建
客户端rpc远程调用Namenode实现的complete方法，完成新文件的创建。Namenode将INodeFileUnderConstruction对象转化为正常的INodeFile对象，并解除文件上的排他锁。
根据以上的数据写访问过程，HDFS的写升级不需要向读升级那样使用基于票据的方式。由于在HDFS的Namenode端实现了基于Lease的排他锁，其它的用户是不能够访问尚未创建完成的文件的。而在文件创建完成之后就不能修改，这样大大简化了文件写请求的安全控制。只需要在DFSClient向Namenode发起create远程调用开始文件创建的时候对其进行升级即可。
5>用户命令的设计
为了方便各个组织管理员的操作，在系统的客户端实现了相应的管理员命令。可以使用这些命令对系统用户，用户角色以及客体的Tag标签进行管理。所有的这些命令都实现在Hadoop原有的FSShell中，命令说明如下：
本发明的保护范围不限于上述的实施例，显然，本领域的技术人员可以对本发明进行各种改动和变形而不脱离本发明的范围和精神。倘若这些改动和变形属于本发明权利要求及其等同技术的范围，则本发明的意图也包含这些改动和变形在内。