具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

参图1所示，本实施例提供了一种云平台访问控制方法(机制)，包括：

1)知识抽取

基于构建的知识库模型，根据结构化数据抽离知识，并存储至知识库中；

2)规则预处理

建立推理规则，并基于逻辑转换进行复合规则约简，使规则库中的规则符合SWRL规则表示的原子规则；

3)基于规则的动态授权推理

采用自定义规则的方式实现规则推理，采用三元组动态连接的方式实现动态授权；

4)规则优化管理

采用基于层级继承的冲突对分析方法，对步骤3)中的自定义规则进行冲突检测，得到冲突检测结果(冲突与否)；

采用基于层级继承的冗余对分析方法，对步骤3)中的自定义规则进行冗余检测，包括规则冗余检测及一般性冗余检测，得到冗余检测结果(冗余与否)；

若规则检测结果中，两规则满足冗余对或冲突对，进行基于属性原子的相似度计算，根据相似度计算结果，针对互为冲突对的两规则进行基于层级的规则冲突自动消解，针对互为冗余对的两规则进行基于层级的规则冗余自动消解。

在本访问控制机制中，通过结构化数据，形成知识库，通过基于本体和规则的推理实现动态权限授予，采用基于层级的规则冲突冗余检测与自动消解等处理，实现了适用于云平台的具有可扩展性、动态性、优化管理的访问控制机制。

本实施例中知识库是知识工程中结构化、高度概括、易描述、易使用、可扩展的知识节点群，是针对某一(或某些)领域问题，采用某种(或若干)知识表示方式，在计算机存储器中存储、组织、管理和使用的互相联系的知识片集合，以求解问题。在这里是关于访问控制先验知识的知识片集合。

本实施例中，动态权限授予通过对知识进行基于本体和规则的推理学习，将知识库中的数据作为先验知识，本体和规则作为推理的依据，输出为主体对客体的动态操作权限。

本实施例中，冲突冗余自动检测为：对规则库中的复合规则进行约简，将层级间的正负向继承作为先验事实，规则间属性原子的相似度作为量化准则，输出为冲突与否或冗余与否。

本实施例中，冲突冗余自动消解方法为：对存在冲突或冗余的两规则，将规则属性原子的相似度作为量化准则，规则属性原子约束条件集合关系作为处理依据，输出为冲突或冗余消解后的规则。

下面对本发明作进一步详细说明。

该机制包括：构建本体模型，采用知识推理的方法实现动态权限授予，采用策略优化管理实现规则冲突检测和冗余消解，旨在扩展云平台中因属性动态变化、规则多属性、元素多层级、规则隐含语义等特性所需的访问控制策略，以及消除传统访问控制模型实现资源授权管控的局限性。

如图1所示，该方法包括如下步骤：

(1)知识库建模。采用从上到下的方式构建知识库，完成访问控制概念分析，并进行访问控制模型类的定义以及类层次的体系建立，最后根据已定义类的特征分析，完成类的属性定义以及属性层次的体系建立，其中属性包括数据属性和对象属性，最后根据已定义的类和属性填充实体。本专利的访问控制本体模型中，将主体、角色、租户、客体、动态属性作为类，主体名称、角色名、租户名、主体年龄、客体名称、地理位置、IP地址、系统状态、客体等级等作为数据属性，其中地理位置、IP地址、系统状态、客体等级等具有动态变化特性的属性定义为动态属性类的数据属性。另外，将主体和主体、主体和角色、角色和租户、租户和客体、客体和客体等之间的关系定义为对象属性，将具体主体、角色、租户等建模为实例模型。

(2)知识抽取。本步骤旨在将数据源中蕴含的知识抽离出来，形成知识元库，并进行知识存储。为降低大多数企业迁移本专利访问控制机制的成本，本专利中的知识来源为结构化数据，并将获取的数据按照本体语义映射规则转换成三元组知识元库。为提高数据存储速度、操作性、并发性等特性，本机制采用TDB作为知识存储数据库。利用抽取到的知识，形成访问控制实体关系网，通过知识节点的连通性，获取多实体之间的隐含语义关系。

(3)基于逻辑转换的复合规则约简。复合规则中包含多种复杂逻辑组合，如与、或、非，进行规则推理、规则冲突检测和规则冗余检测时，检测难度较高、检测成本较大。故而，本专利中的访问控制机制进行基于逻辑转换的复合。

(4)规则约简，约简公式为A∩B∩NOT(C)→F等价于A∩B∩(C1∪C2)→F等价于A∩B∩C1→F与A∩B∩C2→F的合集。其中，C1的C2的并集是C的补集。

(5)基于规则的动态授权推理。步骤2将实体与实体之间的关系通过三元组的形式存储在TDB数据库中。对于知识库中基于规则的动态授权推理，采用自定义规则的方式实现规则推理，采用三元组动态连接的方式实现动态授权。本访问控制机制中，存在主体、角色、租户、客体等元素，且归纳所有授权系的动态属性为属性元素。因主体、角色、租户、客体之间的数据属性和对象属性不具有动态性，故而当授权请求发生时，只需根据授权请求生成动态属性元素实例，并填充数据属性，动态连接主体-属性三元组。另外，需自定义访问控制规则，如主体所在租户域仍在租用时间内且主体所分配的角色为学生，其可在每周二非22:00-8:00，具有读资源的权限。由于此时知识库中已具有请求发生处的动态属性数据以及主体与属性间的三元组，故而可以根据自定义规则推导出主体节点与资源节点的连通性，实现基于规则的动态授权推理判断。

(6)基于层级的规则冲突检测。本步骤对步骤3中的自定义规则进行冲突检测，以优化访问控制策略管理。实现方法采用基于层级继承的冲突对分析。经过步骤4约简后的规则，每个规则的属性均为原子项，可进行基于层级的冲突对分析，本专利的访问控制机制研究了如下三种层级引起的冲突：角色层级冲突、客体层级冲突、授权操作层级冲突。角色层级冲突定义如下：角色A2继承自角色A1，可利用正向继承实现肯定授权继承和否定授权继承。若角色A1对客体B进行操作C时，得到肯定授权。角色A2对客体B进行操作C时，得到否定授权。或者若角色A1对客体B进行操作C时，得到否定授权。角色A2对客体B进行操作C时，得到肯定授权。此时两规则因角色继承产生冲突。客体层级冲突定义如下：客体B2是客体B1的子层级，客体B2要求更细粒度的。

(7)访问控制，可实现负向的肯定授权继承和正向的否定授权继承。若角色A对客体B1进行操作C时，得到否定授权。角色A对客体B2进行操作C时，得到肯定授权。此时两规则因客体层级产生冲突。授权操作层级冲突定义如下：授权操作C2是授权操作C1的下级操作，操作C2可对客体进行深层的处理，可实现负向的肯定授权继承和正向的否定授权继承。若角色A对客体B进行操作C1时，得到否定授权。角色A对客体B进行操作C2时，得到肯定授权。此时两规则因操作层级产生冲突。以上仅对单层级继承引起的冲突进行分析，多层级继承冲突可通过单层级继承冲突推导得出。通过对三种层级产生的冲突进行研究，可得到<A,B,C>和<A1,B1,C1>两两冲突对。

(8)基于层级的规则冗余检测及一般性冗余检测。本步骤对步骤4中的自定义规则进行冗余检测，以优化访问控制策略管理。实现方法采用基于层级继承的冗余对分析。与步骤5中基于层级继承的冲突对分析类似，本步骤依旧从角色、客体、授权操作三个维度进行冗余对分析，以上三个维度的继承授权方向已在步骤5中声明，此处不再赘述。本步骤中给出基于层级的肯定授权冗余对定义：给定规则1为角色A1对客体B1进行操作C1时，拥有肯定授权。若存在规则2为角色A2对客体B2进行操作C2时，拥有肯定授权。当且仅当，角色A2是角色A1的下级角色，B2是B1的上级客体，C2是C1的上级操作，<A,B,C>和<A1,B1,C1>为肯定授权冗余对。基于层级的否定授权冗余对定义：给定规则1为角色A1对客体B1进行操作C1时，拥有否定授权。若存在规则2为角色A2对客体B2进行操作C2时，拥有否定授权。当且仅当，角色A2是角色A1的下级角色，B2是B1的下级客体，C2是C1的下级操作，<A,B,C>和<A1,B1,C1>为否定授权冗余对。此处存在一种特殊情况，即两规则的角色、客体、授权操作均相同，定义为一般性冗余。通过以上操作对两规则进行冗余对

(9)分析后，需根据基于属性原子的相似度计算。

(10)基于属性原子的相似度计算。基于属性原子的相似度计算旨在对两规则中的属性原子一一进行相似度计算，计算公式和系数采用Jaccard系数，通过相似度定量两规则间的属性原子值相交区域大小。

(11)基于层级的规则冲突自动消解。互为冲突对<A,B,C>、<A1,B1,C1>的两规则，计算两规则间基于属性原子的相似度值。当且仅当两规则中角色、客体、授权操作互为冲突对，且相似度值不为0时，两规则冲突。对于冲突的两规则，消解原则为消解冲突概率较大者。冲突概率采用规则与满冲突规则的相似度大小定量表示。此处满冲突规则表示规则适用所有情况，即每一个属性原子项的值均为值域的全集。

(12)基于层级的规则冗余自动消解。本步骤中基于属性原子的相似度计算需判断，互为冗余对<A,B,C>、<A1,B1,C1>的两规则中，前者规则的属性原子项需为后者规则属性原子项的子集，且对于每一个属性原子项的约束范围均有后者是前者的子集。此时，可对后者规则进行消解。若对于两规则，满足一般性冗余条件，则对两规则的属性原子项进行分析，若属性原子项均相同，且属性原子项的约束范围相似度不为0，则对两规则中相似度不为0的同属性原子项的约束范围进行合并操作。

本专利面向云平台的访问控制机制整体结构主要由四部分构成：(1)知识抽取层：主要负责收集各种数据，并对收集到的数据进行分析，按照建立好的知识本体模型，将知识抽取出来并存储到知识库中。(2)规则预处理层：主要负责建立推理规则并对复合规则进行约简处理，保证规则库中的规则是可用SWRL规则表示的原子规则。(3)推理层：推理层主要利用规则库中的SWRL规则推理出主体和客体之间的授权操作。(4)规则优化管理层：主要负责对规则库中的规则进行优化处理，包括冲突检测和冗余检测，并对检测到的结果进行消解或合并处理。此层利用属性原子的相似度作为量化指标。

在本例实施中，处理数据流程如下：

步骤一：利用OWL技术构建知识库模型，有了知识库模型才方便对知识库进行推理，对于主体、角色、租户、客体、动态属性、授权操作进行知识库建模，主体具有对象属性，userHasRole、userHasAttr，分别指的是主体所分配的角色和主体具有动态属性。角色具有对象属性roleHasTenant，指的是角色所属的租户域，此外角色具有对象属性rolePrior和roleNext，分别表示上级角色和下级角色。租户具有对象属性tenantTenRes，指的是当前租户域已租用的客体，租户具有数据属性tenantTime，指的是租户域租用客体的时间。客体具有对象属性resPrior和resNext，分别表示上级客体和下级客体。客体具有数据属性resName、resType分别表示客体名称和客体类别。动态属性具有数据属性POI_long、POI_lati、sysStatus、userAge、sysTime、sysWeek，分别代表地理位置经度、地理位置纬度、系统状态、客体年龄、系统时间、星期。授权操作具有数据属性actionName，表示授权操作名称。具有对象属性actPrior、actNext，分别表示上级授权和下级授权。

步骤二：根据结构化数据抽离知识。结构化数据采用数据表形式，建立User、Role、Tenant、Resource、Attribute、Action数据库表，分别定义主体、角色、租户、客体、动态属性、授权操作的结构并存储数据。建立user_to_role表，存储主体和角色之间的连接关系。建立role_to_tenant表，存储角色和租户域之间的连接关系。建立tenant_to_res表，存储租户和客体之间的连接关系。建立user_to_attr表，存储主体和动态属性之间的关系，此表为空表，仅定义结构使用，主体节点和动态属性节点之间的连通性，通过动态连接和解除三元组实现。填充各个表的信息，使用工具将三个数据库转化为RDF类型数据。

步骤三：构建推理规则，并基于逻辑转换进行复合规则约简，对约简后的规则使用SWRL语言描述，举例1:User(？u)^userHasRole(？u,？r)^roleHasTenant(？r,？t)^tenantTenRes(？t,？re)^tenantTenRes(？tr)^tenantId(？tr,？t)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^tenantTime(？tr,？teTime)^swrlb:lessThan(？systime,？teTime)->userHasTenResource(？u,？re)，这个规则说明主体所分配到的角色对应的租户域已租用某资源，且主体请求资源时的时间在租用时间内，则此用户拥有此资源的租用权。举例2:规定主体已拥有资源的租用权，且是学生，其可在每周二的非10:00-12:00，拥有写私密文件资源的权限。通过逻辑转换为两条约简后的规则：(1)主体已拥有资源的租用权，且是学生，其可在每周二的0:00-10:00，拥有写私密文件资源的权限。(2)主体已拥有资源的租用权，且是学生，其可在每周二的12:00-24:00，拥有写私密文件资源的权限。SWRL规则描述如下：

规则3-1:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0000)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->permit(？u,？re)。

规则3-2:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？2400)^swrlb:greaterThan(？systime,？1200)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->permit(？u,？re)。

步骤四：通过动态增加三元组，实现动态增加主体和动态属性间的节点连通性，并使用SPARQL查询语言对知识库进行查询遍历操作，可实现基于规则的动态授权推理。如动态增加的三元组例：<:user/1:userHasAttr:/attr/1>、<:/attr/1:systime 0900>、<:/attr/1:week‘Tuesday’>，此时可根据知识库和规则进行推理授权，推理可得满足规则3-2，允许写资源。

步骤五：为优化管理规则库，需对规则库中的规则进行冲突检测。此处给出三条规则，分别从角色、客体、授权操作三个维度举例说明，如下所示：

规则5-1:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Undergraduates’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0100)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->deny(？u,？re)。此条规则说明主体已拥有资源的租用权，且是本科生，则其在每周二的1:00-10:00，请求写私密文件资源时被拒绝。由于本科生是学生的下级角色，且角色层次拥有正向肯定授权继承，故而与规则3-1因角色层次产生了授权冲突。冲突对为<Student，私密文件，WRITE>、<Undergraduates，私密文件，WRITE>。

规则5-2:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘GeneralFile”)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0000)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->deny(？u,？re)。此条规则说明主体已拥有资源的租用权，且是学生，则其在每周二的0:00-10:00，请求写普通文件资源时被拒绝。因普通文件是私密文件的上层客体，且客体层次拥有负向肯定授权继承，故而此条规则与规则3-1因客体层次产生了授权冲突。冲突对为<Student，私密文件，WRITE>、<Student，普通文件，WRITE>。

规则5-3:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0000)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘READ’)->deny(？u,？re)。此规则说明主体已拥有资源的租用权，且是学生，则在每周二的0:00-10:00，对私密文件资源进行读请求时被拒绝。因读请求是写请求的上层授权操作，且授权操作层次拥有负向肯定授权继承，故而此条规则与规则3-1因授权操作层次产生了授权冲突。冲突对为<Student，私密文件，WRITE>、<Student，私密文件，READ>。

步骤六：基于属性原子的相似度计算

为优化管理规则库，需对规则库中的规则进行冲突检测。此处给出三条规则，分别从角色、客体、授权操作三个维度举例说明并给出一般性冗余的示例，如下所示：

规则6-1:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Undergraduates’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0100)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->permit(？u,？re)。此条规则说明主体已拥有资源的租用权，且是本科生，则其在每周二的1:00-10:00，请求写私密文件资源时被拒绝。由于本科生是学生的下级角色，且角色层次拥有正向肯定授权继承，故而与规则3-1因角色层次产生了授权冗余。冗余对为<Student，私密文件，WRITE>、<Undergraduates，私密文件，WRITE>。

规则6-2:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘GeneralFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0000)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->permit(？u,？re)。此条规则说明主体已拥有资源的租用权，且是学生，则其在每周二的0:00-10:00，请求写普通文件资源时被拒绝。因普通文件是私密文件的上层客体，且客体层次拥有负向肯定授权继承，故而此条规则与规则3-1因客体层次产生了授权冗余。冗余对为<Student，私密文件，WRITE>、<Student，普通文件，WRITE>。

规则6-3:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1000)^swrlb:greaterThan(？systime,？0000)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘READ’)->permit(？u,？re)。此规则说明主体已拥有资源的租用权，且是学生，则其在每周二的0:00-10:00，对文件资源进行读请求时被拒绝。因读请求是写请求的上层授权操作，且授权操作层次拥有负向肯定授权继承，故而此条规则与规则3-1因授权操作层次产生了授权冗余。冗余对为<Student，私密文件，WRITE>、<Student，私密文件，READ>。

规则6-4:

User(？u)^userHasRole(？u,？r)^roleName(？r,‘Student’)^userHasTenResource(？u,？re)^resName(？re,‘PrivateFile’)^userHasAttr(？u,？attr)^sysTime(？attr,？systime)^swrlb:lessThan(？systime,？1100)^swrlb:greaterThan(？systime,？0100)^week(？attr,‘Tuesday’)^Action(？act)^actionName(？act,‘WRITE’)->permit(？u,？re)。此条规则与规则3-1的角色、客体、授权操作均相同，满足一般性冗余。

步骤七：基于属性原子的相似度计算

若两规则满足冗余对或冲突对，可进行基于属性原子的相似度计算。此步骤中以规则3-1和规则5-1为例进行量化。规则3-1和规则5-1因角色层级产生冲突对，此步骤中将两规则的属性拆分为原子项进行相似度计算。拆分后结果为：sysTime和week，则分别计算两属性的相似度，计算公式如下：

步骤八：基于层级的规则冲突自动消解

针对冲突的两个规则，如规则3-1和规则5-1，对其进行自动消解处理，处理原则为消解冲突概率较大者。两规则的满冲突规则中属性原子项的值域应为{0000-2400}，{‘Monday’,‘Tuesday’,‘Wednesday’,‘Thursday’,‘Friday’,‘Saturday’,‘Sunday’}。规则3-1与满冲突规则的相似度计算结果为0.059，规则5-1与满冲突规则的相似度计算结果为0.053，故而消解规则3-1。

步骤九：基于层级的规则冗余自动消解

针对层级冗余的两个规则，如规则3-1和规则6-1，对其进行自动消解处理。前者属性原子sysTime约束条件为0000-1000，后者约束条件为0100-1000。前者和后者属性原子week的约束条件均为‘星期二’。故而可对后者规则进行消解。针对一般性冗余的两个规则，如规则3-1和规则6-1，对其进行自动合并处理。前者属性原子sysTime约束条件为0000-1000，后者约束条件为0100-1100。前者和后者属性原子week的约束条件均为‘Tuesday’。则可将二者属性原子sysTime约束条件合并为0000-1100。

以上所述仅是本发明的优选实施方式，并不用于限制本发明，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变型，这些改进和变型也应视为本发明的保护范围。