CN113127848A - 一种权限系统数据的存储方法及相关设备 - Google Patents

Abstract

本申请提供了一种权限系统数据的存储方法和相关设备。其中，该方法包括：权限管理服务器获取权限配置信息，该权限配置信息包括各个存储对象之间的具有方向的关系；将每个存储对象与其它存储对象之间的关系记录在存储对象对应的属性信息中；将每个存储对象以及其对应的属性信息存储在图数据库中；其中，存储对象包括权限系统的资源信息、权限信息和角色信息，资源信息包括权限系统数据，权限信息包括对资源信息执行的操作，角色信息包括具有权限信息所对应权限的角色。上述方法能够提高权限查询效率，缩短权限查询时间。

Description

一种权限系统数据的存储方法及相关设备

技术领域

本申请涉及信息处理技术领域，尤其涉及一种权限系统数据的存储方法及相关设备。

背景技术

基于角色的访问控制(role base access control，RBAC)是实施面向企业安全策略的一种有效的访问控制方式。其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合于权限集合之间建立一个角色集合。每一种角色对应一组相应的权限，一旦用户被分配了适当的角色之后，该用户就拥有此角色的所有操作权限。这样，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样就可以简化用户的权限管理，减少系统的开销。

目前对于RBAC的所有数据，包括RBAC所涉及的所有核心对象，例如资源、权限、角色等，以及核心对象之间的关系都是保存在关系型数据库中，例如oracle、结构化查询语言服务(strutured query language server，SQLServer)等，而利用关系型数据库存储RBAC的数据，在进行权限查询等操作时，将耗费大量的时间，查询效率极其低下。

因此，如何提高权限查询效率，缩短权限查询时间是目前亟待解决的问题。

发明内容

本申请提供了一种权限系统数据的存储方法及相关设备，可以提高权限查询效率，缩短权限查询时间。

第一方面，提供了一种权限系统数据的存储方法，包括：权限管理服务器获取权限配置信息，所述权限配置信息包括各个存储对象之间的关系，所述关系具有方向；权限管理服务器将每个存储对象与其它存储对象之间的关系记录在所述存储对象对应的属性信息；权限管理服务器将所述每个存储对象以及所述每个存储对象对应的属性信息存储在图数据库中；其中，所述存储对象包括所述权限系统的资源信息、权限信息和角色信息，所述资源信息包括所述权限系统数据，所述权限信息包括对所述资源信息执行的操作，所述角色信息包括具有所述权限信息所对应权限的角色。

在本申请实施例中，权限管理服务器将配置的各个存储对象之间具有方向的关系记录在存储对象对应的属性信息中，并将每个存储对象及其对应的属性信息存储在图数据库中，由于图数据库是非关系型数据库，适合存储对象之间的复杂关系，并可以通过有向图将这种关系直接显示出来，这样可以保证在进行权限信息查询等操作时，可以提高查询效率，缩短查询时间。

结合第一方面，在第一方面一种可能的实现方式中，当所述存储对象或所述存储对象与其它存储对象之间的关系被删除，权限管理服务器获取所述存储对象对应的属性信息；权限管理服务器针对所述属性信息中记录的由所述存储对象指向其它存储对象的关系添加标签信息，所述标签信息记录由所述存储对象指向其它存储对象的关系被删除的时刻。

在本申请实施例中，权限管理服务器在删除存储对象之间的关系时是通过添加标签信息的方式进行软删除，即针对要删除的对象之间的关系，添加标签记录该关系被删除的时刻，这样可以保证对整个权限系统的历史权限信息进行还原，对每个用户所拥有的权限可以进行还原，以及所获取到的权限路径进行追溯。

结合第一方面，在第一方面一种可能的实现方式中，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，权限管理服务器接收当前权限查询请求，所述当前权限查询请求包括所述用户标识和所述资源信息；权限管理服务器根据所述当前权限查询请求，查找所述用户标识到所述资源信息的所有路径；若存在一条由所述用户标识到达所述资源信息的路径，且形成所述路径的所有关系都未曾被删除，则确定所述用户标识对应的用户拥有操作所述资源信息的权限。

在本申请实施例中，权限管理服务器根据查询请求中的用户标识和资源信息查找从该用户标识到该资源信息的由关系构成的路径，并判断是否存在至少一条路径中所包含的所有关系都未曾被删除，即每个关系都没有添加标签信息，通过这种方式可以快速查询并判断出该用户标识所对应的用户当前是否拥有操作资源信息的权限。

结合第一方面，在第一方面一种可能的实现方式中，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，权限管理服务器接收历史权限查询请求，所述历史权限查询请求包括所述用户标识和所述资源信息；权限管理服务器根据所述历史权限查询请求，确定从所述用户标识到所述资源信息的路径；权限管理服务器确定构成所述路径的所有关系，并根据所述标签信息确定所述构成所述路径的所有关系中被删除的关系所对应的删除时刻；若所述被删除的关系所对应的删除时刻晚于所述历史权限查询请求所请求查询的历史时刻，则确定所述用户标识对应的用户在所述历史时刻拥有操作所述资源信息的权限。

在本申请实施例中，权限管理服务器首先找到从用户标识到资源信息的路径，然后进一步判断构成该路径的所有关系是否存在被删除的情况，进而通过其对应的标签信息确定关系被删除的时刻，最后比较关系的删除时刻与需要查询的历史时刻的关系，可以确定该用户标识对应的用户在历史时刻是否拥有操作资源信息的权限，这样可以查询到用户标识所对应的用户在任意一个历史时刻的权限关系，其所拥有的权限的全部历史可以还原。

第二方面，本申请提供了一种计算设备，包括：获取单元，用于获取权限配置信息，所述权限配置信息包括各个存储对象之间的关系，所述关系具有方向；权限管理单元，用于将每个存储对象与其它存储对象之间的关系记录在所述存储对象对应的属性信息，并将每个存储对象以及所述每个存储对象对应的属性信息存储在图数据库中；其中，所述存储对象包括所述权限系统的资源信息、权限信息和角色信息，所述资源信息包括所述权限系统数据，所述权限信息包括对所述资源信息执行的操作，所述角色信息包括具有所述权限信息所对应权限的角色。

结合第二方面，在第二方面一种可能的实现方式中，所述获取单元，还用于当所述存储对象或所述存储对象与其它存储对象之间的关系被删除，获取所述存储对象对应的属性信息；所述权限管理单元，还用于针对所述属性信息中记录的由所述存储对象指向其它存储对象的关系添加标签信息，所述标签信息记录由所述存储对象指向其它存储对象的关系被删除的时刻。

结合第二方面，在第二方面一种可能的实现方式中，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，所述计算设备还包括查询单元，所述获取单元，还用于获取当前权限查询请求，所述当前权限查询请求包括所述用户标识和所述资源信息；所述查询单元，用于根据所述当前权限查询请求，查找所述用户标识到所述资源信息的所有路径，若存在一条由所述用户标识到达所述资源信息的路径，且形成所述路径的所有关系都未曾被删除，则确定所述用户标识对应的用户拥有操作所述资源信息的权限。

结合第二方面，在第二方面一种可能的实现方式中，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，所述计算设备还包括查询单元，

所述获取单元，还用于获取历史权限查询请求，所述历史权限查询请求包括所述用户标识和所述资源信息；所述查询单元，用于：根据所述历史权限查询请求，确定从所述用户标识到所述资源信息的路径；确定构成所述路径的所有关系，并根据所述标签信息确定所述构成所述路径的所有关系中被删除的关系所对应的删除时刻；若所述被删除的关系所对应的删除时刻晚于所述历史权限查询请求所请求查询的历史时刻，则确定所述用户标识对应的用户在所述历史时刻拥有操作所述资源信息的权限。

第三方面，本申请提供了一种计算设备集群，所述计算设备集群包括至少一个计算设备，每个计算设备包括处理器和存储器，所述至少一个计算设备的处理器用于调用所述至少一个计算设备的存储器中的程序代码以执行上述第一方面以及结合上述第一方面中的任意一种实现方式的方法。

第四方面，本申请提供了一种计算机存储介质，所述计算机存储介质存储有计算机程序，当该计算机程序被处理器执行时实现上述第一方面以及结合上述第一方面中的任意一种实现方式所提供的方法的流程。

第五方面，本申请提供了一种计算机程序，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行上述第一方面以及结合上述第一方面中的任意一种实现方式所提供的方法的流程。

附图说明

图1为本申请实施例提供的一种基于角色访问控制系统的结构示意图；

图2为本申请实施例提供的一种系统架构示意图；

图3为本申请实施例提供的一种权限数据存储系统的结构示意图；

图4为本申请实施例提供的一种权限系统数据的存储方法的流程示意图；

图5为本申请实施例提供的一种系统权限关系的示意图；

图6为本申请实施例提供的一种权限关系有向图；

图7为本申请实施例提供的一种计算设备的结构示意图；

图8为本申请实施例提供的一种计算设备集群的结构示意图。

具体实施方式

下面结合附图对本申请实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。

首先，结合附图对本申请中所涉及的部分用语和相关技术进行解释说明，以便于本领域技术人员理解。

RBAC是一种权限访问控制方式，由四个部分组成，即用户、角色、会话、权限。它们之间存在对应关系，一个用户可以对应多个角色，一个角色也可以对应多个用户；一个角色可以对应多个权限，一个权限可以对应多个角色；一个用户对应一个会话，而一个会话可以对应多个角色。

有向无环图(directed acyclic graph，DAG)是指在一个有向图中，从任意顶点出发无法经过若干条边回到该点，DGA与数组、排列、区块链一样，也是一种数据结构，在本申请中，各个存储对象之间的关系可以构成DAG。

图数据库(graph database，GDB)是非关系型(not only SQL，NoSQL)数据库的一种类型，它应用图形理论存储实体之间的关系信息，使用图形结构进行语义查询。在一个GDB中，主要由结点集和连接结点的关系组成，结点集就是图中一系列结点的集合，类似于关系数据库中所使用的表，而结点之间的关系是GDB所特有的组成。每个结点具有标示自己所属实体类型的标签，并记录一系列描述该结点特性的属性，此外，还可以通过关系来连接各个结点，关系是有向的，如果希望在两个结点集间建立双向关系，需要为每个方向定义一个关系。GDB善于处理大量的、复杂的、互联的、多变的网状数据，其效率远远高于传统的关系型数据库，特别适用于社交网络、实时推荐、银行交易环路、金融征信系统等广泛的领域。

关系型数据库(relational database)是指采用了关系模型来组织数据的数据库，例如oracle、SQLServer等，其以行和列的形式存储数据，这一系列的行和列被称为表，一组表组成了数据库。关系模型可以简单理解为二维表格模型，关系型数据库就是由二维表及其之间的关系组成的一个数据组织。关系型数据库采用结构化查询语言来对数据进行查询，它能够支持数据库的增加、查询、更新、删除等操作，由于关系型数据库将数据存储在数据表中，数据操作的瓶颈出现在多张数据表的操作中，而且数据表越多，这个问题就越严重，如果要缓解这个问题只能提高处理能力，但这样的拓展非常有限，也就是说关系型数据库只具备纵向扩展能力。

快照(snapshot)是一种针对内存进行的快速读取技术，是对指定数据集合的一个完全可用拷贝，该拷贝包括相应数据在某个时间点的映像。快照可用是其所表示的数据的一个副本，也可以是数据的一个复制品，其主要用于在线数据备份与恢复。

参见图1，图1是一种基于角色的访问控制系统的结构示意图。如图1所示，租户110、项目120、用户组集合130、用户集合140、角色集合150、权限集合160和资源集合170为系统中的实体对象，各个实体对象之间存在关联关系。租户110包括一个或多个项目120，租户110也可以包括一个或多个用户组集合130，项目120也可以包括一个或多个用户组集合130；每个用户组集合130包括用户集合140的一个或多个用户，用户组集合130关联角色集合150，用户集合140也可以直接关联角色集合150；角色集合150关联权限集合160，权限集合160操作资源集合170，资源集合170归属于项目120。可以看出，可以为角色集合150中的角色分配某个项目120下相应的资源集合170中的资源对应的权限集合160中的权限，用户集合140中的用户或用户组集合130中的用户组通过关联相应的角色集合150中的角色，从而获得权限。

目前都是利用关系型数据库对实体对象以及实体对象之间的关系进行存储，在使用关系型数据库时，首先需要对实体对象之间的关系进行建模，先建立表示各种实体对象的一系列表，这些表常常需要通过一系列关联表将它们关联起来，例如在上述图1所示的系统结构中，需要大量的关联表来记录这一系列复杂的关系。应理解，关系型数据库是以实体建模这一基础理念设计的，并没有提供对这些实体间关系的直接支持，需要通过创建关联表以记录这些数据之间的关联关系，此外，关联表也仅仅是通过关系型数据库所已有的功能来模拟实体之间的关系，这样数据库需要通过关联表间接的维护实体间的关系，将会导致数据库的执行效能低下，同时关联表的数量也会急剧上升。换句话说，当利用关系型数据库存储基于角色的访问控制系统的数据时，查询用户的权限信息是非常困难的，将会耗费大量的计算资源，在实体对象数量和关系更为复杂的情况下，甚至无法完成查询过程。

此外，当在图1所示的系统结构中，若需要删除部分实体对象之间的关系，例如需要删除用户集合140和角色集合150之间的某些关联关系；或者是需要删除或改变某些实体对象，例如删除角色集合150中的某些角色或者更改权限集合160中的某些权限，这时，将会造成用户对于特定资源的权限关系发生改变。关系型数据库对于实体对象和关系的删除一般有两种处理方式，一种是硬删除，即数据库中不再保存相关实体对象或关系；另一种是软删除，即将相关实体对象或关系标记为删除或者移动到单独的表中，以表示对实体对象或关系进行了删除。无论是哪种方式，都无法查询到历史上某个时刻的系统权限信息，即查询到实体对象和关系被删除或修改之前的系统权限信息，对于用户所拥有的权限信息不能进行历史还原，无法追溯用户获得权限的路径。

基于上述，本申请提供了一种权限系统数据的存储方法及相关设备，可以提高权限查询效率，缩短权限查询时间，还原权限系统在任意历史时刻的整体快照。

本申请实施例的技术方案可以应用于各种涉及复杂的实体对象关系的权限解决方案的场景，包括但不限于RBAC、基于标号的访问控制(label base access control，LBAC)等。

在一个具体的实施例中，如图2所示，权限数据存储系统可以部署在云环境和边缘环境，具体为云环境上的一个或多个计算设备(例如中心服务器)和边缘环境中的一个或多个计算设备(边缘计算设备)上，边缘计算设备可以为服务器。其中，云环境是指云服务提供商拥有的，用于提供计算、存储、通信资源的中心计算设备集群，云环境中具备较多的存储资源和计算资源。边缘环境是指在地理位置上距离终端设备较近的，用于提供计算、存储、通信资源的边缘计算设备集群。此外，权限数据存储系统包括多个部分(例如包括多个单元)，各个部分可以分布式部署在不同的环境中。例如，可以在云环境、边缘环境上分别部署权限数据存储系统的一部分。

权限数据存储系统用于接收权限配置信息，将各个存储对象之间的关系记录在相应的属性信息中(其可视化效果为有向线段将不同的存储对象连接起来)并存储在图数据库中，此外，还用于接收权限查询请求，确定当前时刻或历史时刻权限关系。权限数据存储系统内部的单元可以有多种划分方式，本申请对此不作限制。图3为一种示例性的划分方式，如图3所示，下面分别简述每个功能单元的功能。

所示权限数据存储系统300包括多个功能单元，其中，获取单元310，用于获取权限配置信息，该权限配置信息包括各个存储对象之间的关系；权限管理单元320，用于根据获取单元310获取到的配置信息，将各个存储对象之间的关系记录在相应的属性信息中(表现为用有向线段将各个存储对象进行连接)，并以有向图的方式存储在图数据库330中。

可选的，权限管理单元320还用于当存储对象被删除或存储对象之间的关系被删除时，获取被删除的存储对象的属性信息，针对属性信息中记录的由该存储对象指向其它存储对象的关系添加标签信息，标签信息记录被删除的时刻。其可视化效果表现为：该被删除的存储对象指向其它存储对象的有向线段由实线转换为虚线。

权限数据存储系统300还包括查询单元340，用于根据获取单元310获取到的权限查询请求，查询权限系统的权限信息。可选的，查询单元340可以查询当前权限信息，即在图数据库330中查找到一条从用户标识到资源信息的路径，且构成该路径的所有关系都未被删除(即对应的有向线段都为实线)；查询单元340还可以查询历史权限信息，即在图数据库330中查找到一条从用户标识到资源信息的路径，且构成该路径的关系中，被删除的关系所对应的删除时刻晚于需要查询的历史时刻。

本申请中，权限数据存储系统300可以为软件系统，其内部包括的各部分以及功能单元部署在硬件设备上的形式比较灵活，如图2所示，整个系统可以分布式部署在一个或两个环境中的一台或多台计算设备中。

请参见图4，图4为本申请实施例提供的一种权限系统数据的存储方法的流程示意图。如图4所示，该方法包括但不限于以下步骤：

S401：权限管理服务器获取配置信息。

具体地，系统管理员通过权限管理服务器提供的万维网(world wide web，Web)浏览器或应用程序接口(application programming interface，API)(例如restful等接口)访问权限管理服务器，并配置各个存储对象之间的关系，该权限管理服务器可以是上述图3中所示的权限管理单元320，其所提供的权限配置界面(即上述Web浏览器或API接口等)可以是上述图3中所示的获取单元310。例如，配置用户标识、用户组标识、角色、授权资源、权限等之间的关系。

存储对象又可以称为实体对象，可以包括权限系统的资源信息、权限信息、角色信息和用户标识，资源信息主要为权限系统的具体数据，权限信息为对资源信息执行的操作，例如增加、查询、更新或删除等，角色信息主要为具有各种权限信息的角色，每个角色都可以被分配相应的权限。

示例性的，授权资源为数据“123”，系统管理员将权限1设置为对数据“123”进行读写，然后把权限1分配给角色1，即角色1具有读写数据“123”的权限，再将角色1分配给用户标识A，即具有标识为A的用户可以拥有角色1的所有权限，可以读取数据“123”。

可选的，系统管理员还可以为同一个角色设置不同的优先级，高优先级的角色可以分配更多的权限，低优先级的角色所分配的权限少于高优先级的角色所拥有的权限。

可以理解，各个存储对象之间的关系都可以通过系统管理员进行配置，系统管理员可以将权限同时分配给多个角色或将多个权限分配给同一个角色，也可以将一个角色同时分配给多个用户标识或将多个角色分配给同一个用户标识，整个配置方式比较灵活。

S402：权限管理服务器根据各个存储对象之间的关系，将每个存储对象与其它存储对象之间的关系记录在所述存储对象对应的属性信息中。

具体地，权限管理服务器在接收到系统管理员配置的各个存储对象之间的关系之后，根据该配置的关系将各个存储对象与其它存储对象之间的关系记录在对应的属性信息中，即通过存储对象的属性信息，可以直接获取到该存储对象与其它存储对象之间的关系，并确定与其有关系的其它存储对象。其可视化效果即为通过有向线段将各个存储对象连接起来，从而得到有向无环图(即有向图)。

例如，如图5所示，若配置信息中包括权限1为对资源“345”进行读写，那么将权限1与资源“345”之间的这种关系记录在权限1对应的属性信息中，将相当于利用有向线段将资源“345”和权限1连接起来，并由权限1指向资源“345”；同理，配置信息中包括将权限1分配给角色1，那么利用有向线段将权限1和角色1连接起来，并由角色1指向权限1；配置信息中包括将角色1分配给标识为A的用户和标识为B的用户组，则利用有向线段将角色1和用户标识A以及用户组标识B连接起来，并由用户标识A指向角色1以及用户组标识B指向角色1。

可以看出，各个存储对象之间的关系可以利用有向线段进行表达，进而利用有向线段将不同的存储对象连接起来可以得到有向图，通过有向图可以轻易的将整个权限系统的各种权限关系表现出来。

在一种可能的实现方式中，当所述存储对象或所述存储对象与其它存储对象之间的关系被删除，权限管理服务器获取该存储对象对应的属性信息，针对属性信息中记录的所有由所述存储对象指向其它存储对象的关系添加标签信息，该标签信息记录由该存储对象指向其它存储对象的关系被删除的时刻。在该存储对象所对应的有向图中，将该存储对象指向其它存储对象的有向线段由实线转换为虚线。

具体地，当存储对象或者存储对象之间的关系被删除时，在可视化有向图中不会真正的去除该存储对象或存储对象之间的关系，而是进行软删除，即将相应的存储对象或存储对象之间的关系所对应的有向线段用虚线进行表示，在有向图中保留了删除痕迹，即得到了删除时刻对应的权限系统的权限关系的快照，并针对被删除的存储对象或存储对象之间的关系添加相应的标签信息，用于记录存储对象或存储对象之间的关系被删除的时刻，这样通过可视化有向图就可以实现对被删除或者修改过的权限关系进行全量存储，保证后续可以追溯，以进行历史权限关系还原。

示例性的，如图6所示，对各个存储对象之间的关系进行了配置形成了如图6所示的可视化有向图。例如，标识为A的用户被配置为标识为B的用户组中的用户和标识为C的用户组中的用户，角色1和角色2分配给标识为A的用户，角色2和角色3分配给标识为B的用户组，角色3分配给标识为C的用户组，角色3分配给标识为D的用户；权限1和权限2分配给角色1和角色2，权限2分配给角色3，权限1和权限2对同一资源进行操作。假设在t1时刻，需要删除标识为C的用户组，则在上述有向图中将标识为C的用户组的边框用虚线表示，此外，由于标识为C的用户组被删除，因此与它指向其它存储对象的所有关系都将被删除，所以将其与角色3之间的有向线段转换为虚线，然后添加标签信息，记录标识为C的用户组被删除的时刻为t1时刻。在t2时刻，需要删除角色2，则在有向图中将角色2以及角色2指向其它存储对象的有向线段转换为虚线，即将权限1和权限2与角色2之间的有向线段转换为虚线，然后添加标签信息，记录角色2被删除的时刻为t2时刻。在t3时刻，需要删除用户标识D与角色3之间的关系，即将用户标识D与角色3之间的有向线段转换为虚线，然后添加标签信息，记录用户标识D与角色3之间的关系被删除的时刻为t3时刻，其中，t1时刻在t2时刻之前，t2时刻在t3时刻之前。

S403：权限管理服务器将每个存储对象以及每个存储对象对应的属性信息存储在图数据库中。

具体地，权限管理服务器在将每个存储对象与其它存储对象之间的关系记录在每个存储对象对应的属性信息中，然后通过图数据库客户端将各个存储对象以及对应的属性信息存储在图数据库中，该图数据库可以是上述图3中所示的图数据库330。

应理解，图数据库相比于关系型数据库来说，更适合存储各个存储对象之间的关系，不需要向关系型数据库一样通过建表来表示不同存储对象之间的关系，当两个存储对象之间存在多种关系时，还需要建立多个表来进行表示。而图数据库直接是将两个存储对象之间的关系记录在相应的属性信息中(即可视化表现为通过有向线段连接两个存储对象)，因此，图数据库的处理效率要远远高于关系数据库，对于查询等操作，仅需耗费较短的时间就可以返回结果。

在一种可能的实现方式中，权限管理服务器接收当前权限查询请求，该当前权限查询请求包括用户的标识和资源信息，权限管理服务器根据接收到的当前权限查询请求，在图数据库中查找所述用户标识到所述资源信息的所有路径，若存在一条由用户标识到达所述资源信息的路径，且构成该路径的所有关系都未曾被删除，即所有的关系对应的有向线段全部为实线，则确定所述用户标识对应的用户拥有操作所述资源信息的权限。

具体地，用户通过权限管理服务器提供的权限查询界面接收当前权限查询请求，然后启动查询服务，该查询服务可以是上述图3中所示的查询单元340，对图数据库中存储的有向图进行搜索，查找是否存在从该用户标识到资源信息的路径，且形成该路径的所有有向线段都为实线，即都未曾被删除。若存在，则说明该用户标识对应的用户具有相应的权限，可以对该资源信息对应的资源进行相应的操作，例如用户标识为A，资源信息对应的资源为数据“123”，若存在用户标识A到数据“123”的实线路径，则用户标识A所对应的用户可以读写数据“123”。

示例性的，如上述图6所示，若当前权限查询请求为标识为A的用户是否拥有操作资源的权限，则直接转变为寻找一条全实线路径从用户标识A到达资源。由于存在用户标识A到角色1、角色1到权限1、权限1到资源的全实线路径，因此，可以确定标识为A的用户具有操作资源的权限。

可选的，为了进一步提高查询效率，缩短查询时间，权限管理服务器可以缓存相关用户的权限信息，例如将标识为A的用户的相关权限信息缓存在本地，这样就不必去图数据库中进行查询。此外，还可以针对缓存的权限信息设置失效时间，即经过多少时间后，该缓存的权限信息失效，不再具有价值，应该丢弃以释放缓存空间，提高权限管理服务器的存储资源的利用率。

应理解，通过上述方式进行权限查询，其本质就是寻找一条全实线路径从相应的用户标识到请求操作的资源，其查询效率将远远高于关系型数据库，大大缩短查询时间。

在一种可能的实现方式中，权限管理服务器接收历史权限查询请求，该历史权限查询请求包括用户的标识和资源信息；权限管理服务器根据接收到的历史权限查询请求，确定从所述用户标识到所述资源信息的路径；确定构成所述路径的所有关系，并根据所述标签信息确定构成所述路径的所有关系中被删除的关系所对应的删除时刻；若所述被删除的关系所对应的删除时刻晚于所述历史权限查询请求所请求查询的历史时刻，则确定所述用户标识对应的用户在所述历史时刻拥有操作所述资源信息的权限。

具体地，权限管理服务器不仅可以查询当前时刻的权限关系，还可以查询任意一个历史时刻的权限关系。因为通过添加标签信息实现关系的软删除，即在可视化有向图中，存储对象和存储对象之间的关系被删除时都保留了删除痕迹，从实线转换为虚线，因此，对于任意一个历史时刻，都可以追溯当时的权限系统的整体权限关系，对于任意一个用户标识来说，其所拥有的权限的全部历史可以还原，其所获得权限的路径可以追溯，都可以通过可视化有向图进行直观表示。

进一步的，权限管理服务器在接收到历史权限查询请求之后，查找从用户标识到资源信息的路径，在确定路径之后，针对构成该路径的所有关系判断其是否被删除，若存在被删除的关系，则根据该关系对应的标签信息确定被删除的时刻，进而判断该删除时刻与需要查询的历史时刻的先后关系，若所有被删除的关系的删除时刻都晚于需要查询的历史时刻，即在需要查询的历史时刻之前，所有的关系都是有效的，则可以确定该用户标识所对应的用户在该历史时刻拥有操作所述资源信息的权限。当至少有一个关系的删除时刻早于需要查询的历史时刻，则该用户标识对应的用户在该历史时刻不具备操作所述资源信息的权限。

示例性的，如上述图6所示，若历史权限查询请求为查询t4时刻标识为D的用户是否拥有操作资源的权限，则找到从用户标识D到资源的所有路径，可以找到用户标识D经过角色3以及权限2到达资源，且用户标识D与角色3之间的有向线段为虚线，通过其对应的标签信息可知，其被删除的时刻为t3时刻。若t4时刻早于t3时刻，则说明在t4时刻时，用户标识D与角色3之间的关系还未被删除，还处于有效时间内，即标识为D的用户具有操作资源的权限；若t4时刻晚于t3时刻，则说明在t4时刻时，用户标识D与角色3之间的关系已经被删除，关系已经失效，即标识为D的用户不具有操作资源的权限。

需要说明的是，不仅可以查询用户的某个历史时刻的权限关系，还可以查询用户在某个历史时间段内的权限关系，以及可以查询整个权限系统在任意时刻的权限关系，还原权限系统在任意时刻的整体快照，可以对授权过程和授权结果进行追溯，并通过有向图进行直观表达。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面还提供用于配合实施上述方案的相关设备。

本申请实施例还提供一种计算设备，该计算设备部署有如图3中所示的权限数据存储系统300的相关功能单元，该计算设备用于执行前述权限系统数据的存储方法。本申请对计算设备中的功能单元的划分不做限定，可以根据需要对该计算设备中的各个单元进行增加、减少或合并。图3示例性的提供了一种功能单元的划分：

该计算设备300包括获取单元310、权限管理单元320和查询单元340。

具体地，所述获取单元310用于执行前述步骤S401，且可选的执行前述步骤中可选的方法，获取到配置信息。

所述权限管理单元320用于执行前述步骤S402-S403，且可选的执行前述步骤中可选的方法，将每个存储对象与其它存储对象之间的关系记录在其对应的属性信息中，并将其存储在图数据库中。

所述查询单元用于执行前述步骤S403，且可选的执行前述步骤中可选的方法，查询当前或历史的权限关系。

上述三个单元之间互相通过通信通路进行数据传输，应理解，计算设备300包括的各单元可以为软件单元、也可以为硬件单元、或部分为软件单元部分为硬件单元。

参见图7，图7是本申请实施例提供的一种计算设备的结构示意图。如图7所示，该计算设备700包括：处理器710、通信接口720以及存储器730，所述处理器710、通信接口720以及存储器730通过内部总线740相互连接。应理解，该计算设备可以是通用服务器。

所述处理器710可以由一个或者多个通用处理器构成，例如中央处理器(centralprocessing unit，CPU)，或者CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application-specific integrated circuit，ASIC)、可编程逻辑器件(programmablelogic device，PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(complexprogrammable logic device，CPLD)、现场可编程逻辑门阵列(field-programmable gatearray，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合。

总线740可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。所述总线740可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但不表示仅有一根总线或一种类型的总线。

存储器730可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)；存储器730也可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)、快闪存储器(flash memory)、硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器730还可以包括上述种类的组合。程序代码可以是用来实现图3所示的的功能单元，或者用于实现图4所示的方法实施例中以权限管理服务为执行主体的方法步骤。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时，可以实现上述方法实施例中记载的任意一种的部分或全部步骤，以及实现上述图3所描述的任意一个功能单元的功能。

如图8所示，本申请还提供一种计算设备集群，该计算设备集群包括多个计算设备800。每个计算设备800的组织结构与计算设备700相同，包括处理器810、通信接口820以及存储器830，所述处理器810、通信接口820以及存储器830通过内部总线840相互连接。

每个计算设备800间通过通信网络建立通信通路。每个计算设备800上运行获取单元310、权限管理单元320和查询单元340中的任意一个或多个。任一计算设备800可以为边缘计算设备系统中的计算设备，或终端计算设备。

本申请实施例还提供了一种计算机程序产品，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。上述所涉及的设备的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。

在上述实施例中，对各个实施例的描述各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

还应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (11)

1.一种权限系统数据的存储方法，其特征在于，包括：

获取权限配置信息，所述权限配置信息包括各个存储对象之间的关系，所述关系具有方向；

将每个存储对象与其它存储对象之间的关系记录在所述存储对象对应的属性信息；

将所述每个存储对象以及所述每个存储对象对应的属性信息存储在图数据库中；

其中，所述存储对象包括所述权限系统的资源信息、权限信息和角色信息，所述资源信息包括所述权限系统数据，所述权限信息包括对所述资源信息执行的操作，所述角色信息包括具有所述权限信息所对应权限的角色。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

当所述存储对象或所述存储对象与其它存储对象之间的关系被删除，获取所述存储对象对应的属性信息；

针对所述属性信息中记录的由所述存储对象指向其它存储对象的关系添加标签信息，所述标签信息记录由所述存储对象指向其它存储对象的关系被删除的时刻。

3.如权利要求1或2所述的方法，其特征在于，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，所述方法还包括：

接收当前权限查询请求，所述当前权限查询请求包括所述用户标识和所述资源信息；

根据所述当前权限查询请求，查找所述用户标识到所述资源信息的所有路径；

若存在至少一条由所述用户标识到达所述资源信息的路径，且形成所述路径的所有关系都未曾被删除，则确定所述用户标识对应的用户拥有操作所述资源信息的权限。

4.如权利要求1或2所述的方法，其特征在于，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，所述方法还包括：

接收历史权限查询请求，所述历史权限查询请求包括所述用户标识和所述资源信息；

根据所述历史权限查询请求，确定从所述用户标识到所述资源信息的路径；

确定构成所述路径的所有关系，并根据所述标签信息确定所述构成所述路径的所有关系中被删除的关系所对应的删除时刻；

若所述被删除的关系所对应的删除时刻晚于所述历史权限查询请求所请求查询的历史时刻，则确定所述用户标识对应的用户在所述历史时刻拥有操作所述资源信息的权限。

5.一种计算设备，其特征在于，包括：

获取单元，用于获取权限配置信息，所述权限配置信息包括各个存储对象之间的关系，所述关系具有方向；

权限管理单元，用于将每个存储对象与其它存储对象之间的关系记录在所述存储对象对应的属性信息，并将每个存储对象以及所述每个存储对象对应的属性信息存储在图数据库中；

其中，所述存储对象包括所述权限系统的资源信息、权限信息和角色信息，所述资源信息包括所述权限系统数据，所述权限信息包括对所述资源信息执行的操作，所述角色信息包括具有所述权限信息所对应权限的角色。

6.如权利要求5所述的计算设备，其特征在于，

所述获取单元，还用于当所述存储对象或所述存储对象与其它存储对象之间的关系被删除，获取所述存储对象对应的属性信息；

所述权限管理单元，还用于针对所述属性信息中记录的由所述存储对象指向其它存储对象的关系添加标签信息，所述标签信息记录由所述存储对象指向其它存储对象的关系被删除的时刻。

7.如权利要求5或6所述的计算设备，其特征在于，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，所述计算设备还包括查询单元，

所述获取单元，还用于获取当前权限查询请求，所述当前权限查询请求包括所述用户标识和所述资源信息；

所述查询单元，用于根据所述当前权限查询请求，查找所述用户标识到所述资源信息的所有路径，若存在一条由所述用户标识到达所述资源信息的路径，且形成所述路径的所有关系都未曾被删除，则确定所述用户标识对应的用户拥有操作所述资源信息的权限。

8.如权利要求5或6所述的计算设备，其特征在于，所述存储对象还包括用户标识，所述用户标识对应所述角色信息包括的一个或多个角色，所述计算设备还包括查询单元，

所述获取单元，还用于获取历史权限查询请求，所述历史权限查询请求包括所述用户标识和所述资源信息；

所述查询单元，用于：

根据所述历史权限查询请求，确定从所述用户标识到所述资源信息的路径；

确定构成所述路径的所有关系，并根据所述标签信息确定所述构成所述路径的所有关系中被删除的关系所对应的删除时刻；

若所述被删除的关系所对应的删除时刻晚于所述历史权限查询请求所请求查询的历史时刻，则确定所述用户标识对应的用户在所述历史时刻拥有操作所述资源信息的权限。

9.一种计算设备集群，其特征在于，所述计算设备集群包括至少一个计算设备，每个计算设备包括存储器和处理器，所述至少一个计算设备的处理器执行所述至少一个计算设备的存储器存储的计算机指令，使得所述至少一个计算设备执行权利要求1-4任一项所述的方法。

10.一种计算机存储介质，所述计算机存储介质存储有计算机程序，当该计算机程序被处理器执行时实现权利要求1-4任一项所述的方法。

11.一种计算机程序，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行权利要求1-4任一项所述的方法。

Images