一种云环境下的动态属性访问控制方法

1.一种云环境下的动态属性访问控制方法，其特征在于包括：
客户端对所上传的数据对象，建立多个动态属性二元组，然后客户端将建立的多个动态属性二元组进行组合，以生成访问控制策略，然后客户端将数据对象和访问控制策略上传到认证服务器；
认证服务器接收数据对象和访问控制策略，并对需要对用户行为进行行为分析才可获取的动态属性进行信息采集；
客户端向代理服务器发起用户请求；
若代理服务器判断用户请求是登录请求，则代理服务器将该请求转发到认证服务器，认证服务器在判断用户请求中包含的用户登录信息正确的情况下生成用户的身份标识，而且认证服务器将身份标识返回给用户，并且将身份标识缓存到缓存服务器；其中，用户的身份标识是全局唯一的，而且用户的身份标识具有预定时限；
若代理服务器判断用户请求是对象操作请求，则在缓存服务器中判断用户的身份标识是否合法，其中判断用户的身份标识是否合法包括判断用户的身份标识是否存在并具有时效；而且若判断用户的身份标识合法，则定位所请求对象的位置，然后将相应的对象操作请求转发到相应的存储节点以便在存储节点执行用户的权限判断；
而且，认证服务器通过分析用户的历史访问行为，赋予用户动态属性，并且将赋予的用户动态属性反馈到存储节点进行保存以更新用户的属性；其中，在存储节点执行用户的权限判断时，首先从用户的操作请求中提取出用户的属性，并查询认证服务器端所保存的对用户行为分析所得出的动态属性；随后在存储节点获取所请求对象的访问控制策略，与用户的属性进行匹配，如果用户的属性满足访问控制策略要求，则响应用户的对象操作请求。

一种云环境下的动态属性访问控制方法\n技术领域\n[0001] 本发明涉及计算机存储安全技术领域，具体涉及一种云环境下的动态属性访问控制方法。\n背景技术\n[0002] 近年来，云存储的广泛应用使用户随时随地存取数据成为了可能。基于静态属性的访问控制方法，其身份、角色、静态属性都需要预先制定好，不能根据云环境中用户的访问行为及其一些实时变化的属性来动态调整其访问权限，因此无法体现云用户多元化需求的变化，无法很好的适应用户的动态性。\n发明内容\n[0003] 本发明所要解决的技术问题是针对现有技术中存在上述缺陷，提供一种云环境下的动态属性访问控制方法，其目的在于通过分析用户的历史访问行为获取用户的动态属性，实现云环境下数据的动态安全访问控制，从而解决现有方法中因用户的历史访问行为的变化而引起用户权限的变更这一技术问题。\n[0004] 根据本发明，提供了一种云环境下的动态属性访问控制方法，包括：\n[0005] 客户端向代理服务器发起用户请求；\n[0006] 若代理服务器判断用户请求是登录请求，则代理服务器将该请求转发到认证服务器，认证服务器在判断用户请求中包含的用户登录信息正确的情况下生成用户的身份标识，而且认证服务器将身份标识返回给用户，并且将身份标识缓存到缓存服务器；\n[0007] 若代理服务器判断用户请求是对象操作请求，则在缓存服务器中判断用户的身份标识是否合法；而且若判断用户的身份标识合法，则定位所请求对象的位置，然后将相应的对象操作请求转发到相应的存储节点以便在存储节点执行用户的权限判断。\n[0008] 优选地，在存储节点执行用户的权限判断时，首先从用户的操作请求中提取出用户的属性；随后在存储节点获取所请求对象的访问控制策略，与用户的属性进行匹配，如果用户的属性满足访问控制策略要求，则响应用户的对象操作请求。\n[0009] 优选地，所述的云环境下的动态属性访问控制方法还包括：认证服务器通过分析用户的历史访问行为，赋予用户动态属性，并且将赋予的用户动态属性反馈到存储节点进行保存以更新用户的属性。\n[0010] 优选地，用户的身份标识是全局唯一的。\n[0011] 优选地，用户的身份标识具有预定时限。\n[0012] 优选地，判断用户的身份标识是否合法包括判断用户的身份标识是否存在并具有时效。\n附图说明\n[0013] 结合附图，并通过参考下面的详细描述，将会更容易地对本发明有更完整的理解并且更容易地理解其伴随的优点和特征，其中：\n[0014] 图1示意性地示出了根据本发明优选实施例的系统访问控制流程示意图。\n[0015] 图2示意性地示出了传统访问控制树结构。\n[0016] 图3示意性地示出了根据本发明优选实施例的动态属性访问控制树结构。\n[0017] 需要说明的是，附图用于说明本发明，而非限制本发明。注意，表示结构的附图可能并非按比例绘制。并且，附图中，相同或者类似的元件标有相同或者类似的标号。\n具体实施方式\n[0018] 为了使本发明的内容更加清楚和易懂，下面结合具体实施例和附图对本发明的内容进行详细描述。\n[0019] 针对云环境中用户属性并非一成不变，有些属性会随时间动态变化的现象，本发明引入动态属性的概念以更好地适应云环境中因用户特征的动态变化引起的权限变更，并对动态属性进行了描述和相应访问控制策略的制定，以及用户权限的判断方法。在访问控制策略制定中，对传统的访问控制树结构进行了一定的改造与优化，以期能提高其访问控制效率及灵活性。\n[0020] 按照本发明，设计了一种云环境下的动态属性访问控制方法，该方法主要包括用户登录认证和权限判断两个步骤。\n[0021] (1)用户登录认证处理：例如，所设计的用户登录口令为“用户名+密码”(用户登录信息)的形式。客户端向代理服务器发起用户请求，代理服务器首先对用户请求进行处理，若用户请求是登录请求，则将该请求转发到认证服务器，在认证服务器中判断用户登录信息是否正确，若正确则生成用户的身份标识Auth token(例如，如图1所示)，该标识是全局唯一的，但具有一定的时限(即在预定时限内有效)，一方面通过认证服务器将身份标识返回给用户，另一方面将身份标识缓存到缓存服务器，提高用户合法性判断的效率；若代理服务器判断用户请求是对象操作请求，则在缓存服务器中判断用户的身份标识Auth token是否合法(具体地，可以判断用户的身份标识Auth token是否存在并具有时效)，若判断合法，则定位所请求对象的位置，然后将相应的对象操作请求转发到相应的存储节点，若用户的身份标识Auth token不合法，则拒绝用户的操作请求，返回对应的错误码(例如，如图1所示的错误码“401Error”)。\n[0022] (2)权限判断处理：若“(1)用户登录认证处理”的用户登录认证通过，而且判断用户的身份标识Auth token合法，则将对象操作请求转发到相应存储节点，然后在存储节点执行用户的权限判断。在这一步中，首先需要从用户的操作请求中提取出用户的属性(本发明涉及了用户的动态属性，即从服务器中获取用户的历史访问记录，分析其历史访问行为，从而得出用户的动态属性；这将在后文详细描述)。\n[0023] 进一步地，在存储节点获取所请求对象的访问控制策略，与用户的属性进行匹配，如果用户的属性满足访问控制策略要求，则响应用户的对象操作请求，否则拒绝操作请求，并返回相应的错误码(例如，如图1所示的错误码“403Error”)。\n[0024] 认证服务器(服务器端)通过分析用户的历史访问行为，赋予用户动态属性(可以采用诸如协同过滤等算法分析出用户特征，然后进行属性赋予)，并且将赋予的用户动态属性反馈到存储节点(用户端)进行保存以更新用户的属性。具体地，用户一开始并不具有这种用户动态属性，或者该用户动态属性的属性值并不满足系统要求，但根据用户的历史访问行为，赋予用户该用户动态属性或者动态修正该用户动态属性的属性值，使用户具有该用户动态属性所对应的权限，这种“从无到有”的过程很好的体现了动态属性的“动态”性。\n[0025] 传统的访问控制所建立的数据结构呈现的都是二叉树型结构，而在基于属性的访问控制(ABAC)中，一般采用的也是这种树形结构，叶子节点代表各个独立的属性，中间节点代表逻辑连接词(and、or、not)。由于动态属性访问控制(DABAC)中引入了权重因子，且动态属性叶子节点满足条件较为丰富，因此不同于ABAC的二叉树访问结构，DABAC需要采用多叉树结构。\n[0026] 以下将对本发明的相关技术术语进行解释和说明：\n[0027] (1)静态属性static_attr：本发明中，静态属性是指属性值基本保持不变的一类属性，或者属性值存在变化，但在一定时间范围内相对固定。例如，一个人的身份证号、性别，电脑MAC地址等属性一经确定往往不再改变，而诸如企业地址，用户年龄、职业等属性在一定时间范围内也是保持不变的。静态属性集可以表示为若干个静态属性元组[静态属性名：静态属性值]所构成的集合，描述如下：\n[0028] Sstatic_attr＝{[static_attr1name:static_attr1value],\n[0029] [static_attr2name:static_attr2value],……}\n[0030] (2)动态属性dynamic_attr：顾名思义，是与用户行为相关的随时间动态变化的属性。包括非量化的动态属性和可量化的动态属性。非量化的动态属性往往很难通过一个值来描述，例如用户对某类事物的喜好程度，对一种编程语言(例如Java、c++等)的精通程度，用户在某论坛的活跃度等等；量化的动态属性则可以用一个确定的值或者区间来表示，例如用户的地理位置信息，行车的实时速度(往往是一个区间范围)，商家举办某活动的日期时间等等。非量化的动态属性比较难以描述，而且需要一套和属性相关的完整评估系统。动态属性集可以表示为若干个动态属性元组[动态属性名：动态属性值，动态属性所占权重]的集合，描述如下：\n[0031] Sdynamic_attr＝{[dynamic_attr1name:dynamic_attr1value,dynamic_attr1weight],[0032] [dynamic_attr2name:dynamic_attr2value,dynamic_attr2weight],……}[0033] 其中，动态属性权重因子weight是可选的，也就是说，并非所有场合都需要设置权重因子，有些场合只需要单纯的属性组合就可以了。之所以引入权重因子，是考虑类比RBAC中角色之间的层次关系，说明不同属性对应的权限重要程度并不相同，应用到动态属性中，说明某些属性的重要程度要高于其他属性，用户只要具备了关键属性即可，如果没有具备关键属性，则需要拥有更多的其他属性才能满足访问要求。对weight举例说明如下：\n[0034] 假设某IT公司招聘程序员，各要求如下：\n[0035] Policy＝{WEIGHT>＝2in[Item1,Item2,Item3]}\n[0036] 其中Item1、Item2、Item3含义如下：\n[0037] Item1：[‘language’:’C++’,weight＝1]，即会C++编程；\n[0038] Item2：[‘workyear’:‘>＝3’,weight＝2]，即工作年龄超过三年；\n[0039] Item3：[‘age’:’<30’,weight＝1]，即面试者年龄要求低于30岁；招聘策略Policy说明用户要么具有工作年龄超过三年的属性，要么具备三种属性之中的任意两种，否则不能满足访问要求。由此策略可以看出该公司对于应聘者的工作年龄较为看重，比较倾向于招收有经验的应试者。\n[0040] 由动态属性的定义可以看出，动态属性较之于静态属性一个很大的不同，就是用户一开始可能不具有某个系统所规定的属性，或者其属性值不满足系统要求，但根据用户一系列的操作行为，进行分析后赋予用户该属性，或者对该用户的属性值进行反馈修正，使其属性值满足要求，这种“从无到有”、“从不满足到满足”的过程很好地体现了动态属性的“动态”性。例如对于用户喜好这一属性，经过用户的一些行为分析得出用户很喜欢跳舞，则可以由系统动态赋予一个爱好为跳舞的属性给用户，而在一开始用户是不具有该属性的。\n当然，诸如用户地理位置信息等动态属性，也可以由系统实时赋予。\n[0041] 在上面对术语的解释的基础上，以下将结合附图1对本发明进一步说明：\n[0042] (1)客户端对所上传的数据对象，建立多个动态属性二元组\n[0043] Sdynamic_attr＝{attrname:attrvalue,attrweight},\n[0044] 其中attrname表示属性名称，attrvalue表示属性值，attrweight表示属性权重。然后客户端将建立的多个动态属性二元组进行组合，以生成访问控制策略Policy，并将Policy封装成XML格式文本。然后客户端将数据对象和Policy上传到服务器。\n[0045] (2)服务器接收数据对象和Policy，并对一些需要对用户行为进行行为分析才可获取的动态属性进行信息采集。\n[0046] (3)客户端发起数据对象请求，服务器从请求中提取出用户属性，并查询服务器端所保存的对用户行为分析所得出的动态属性。\n[0047] (4)服务器获取所请求对象的访问控制策略，生成相应的访问控制树。传统的访问控制所建立的数据结构呈现的都是二叉树型结构，而在基于属性的访问控制中，一般采用的也是这种树形结构，叶子节点代表各个独立的属性，中间节点代表逻辑连接词(and、or、not)，如图2所示。由于引入了权重因子，且动态属性叶子节点满足条件较为丰富，因此不同于ABAC的二叉树访问结构，DABAC需要采用多叉树结构，如图3所示，其中间节点代表逻辑连接词或者权重值之和的要求，叶子节点Item为动态属性元组，即：\n[0048] Item＝[dynamic_attrname:dynamic_attrvalue,dynamic_attrweight]\n[0049] (5)服务器将所获得的所有属性进行访问控制权限匹配，如果通过，则相应客户端的对象操作请求，否则拒绝请求并返回错误码。以图2的访问控制树结构为例来说明用户的权限判断流程。假设各叶子节点Item的内容如下：\n[0050] Item1：[‘language’:’C++’,weight＝2]\n[0051] Item2：[‘workyear’:‘>＝3’,weight＝1]\n[0052] Item3：[‘age’:’<30’,weight＝1]\n[0053] Item4：[‘job’:’designer’,weight＝1]\n[0054] Item5：[‘hometown’:’China’,weight＝1]\n[0055] Item6：[‘graduate school’:’HUST’,weight＝2]\n[0056] 其中，根节点为逻辑连接词AND，说明必须同时满足左子树和右子树的条件才行。\n以左子树为例来说明。\n[0057] Policy＝{WEIGHT>＝2in[Item1,Item2,Item3]}\n[0058] 说明用户要么具有会C++的属性，要么具备三种属性之中的任意两种，否则不能满足访问要求。右子树类似分析，不再赘述。\n[0059] 此外，需要说明的是，除非特别指出，否则说明书中的术语“第一”、“第二”、“第三”等描述仅仅用于区分说明书中的各个组件、元素、步骤等，而不是用于表示各个组件、元素、步骤之间的逻辑关系或者顺序关系等。\n[0060] 可以理解的是，虽然本发明已以较佳实施例披露如上，然而上述实施例并非用以限定本发明。对于任何熟悉本领域的技术人员而言，在不脱离本发明技术方案范围情况下，都可利用上述揭示的技术内容对本发明技术方案作出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均仍属于本发明技术方案保护的范围内。