Resource authority management method and device based on graph database and electronic equipment

Abstract

The invention provides a resource authority management method and device based on a graph database and electronic equipment, and the method comprises the steps: creating at least one tag tree and at least one role based on a current resource authority management and control scene and demand; for each sub-node label of each label tree, if it is determined that the to-be-bound resource instance corresponding to the sub-node label exists, generating a first relation path between the sub-node label and the correspondingly bound resource instance; for each role, if it is determined that the to-be-bound sub-node tag corresponding to the role exists, generating a second relation path between the role and the correspondingly bound sub-node tag; and managing the authority of each resource instance based on each first relation path and each second relation path. According to the method, the tree-structured tag is added in the CMDB system, the role is bound with the tag, and the tag is bound with the resource instance, so that flexible management and control of the resource instance authority can be realized, and a flexible and changeable authority management and control scene is supported.

Description

Technical Field

[0001] The present invention relates to the technical field of resource authority management, and in particular to a resource authority management method, device and electronic equipment based on a graph database. Background Art

[0002] With the development of informatization and digitalization, more and more companies are beginning to use IT asset management tools to manage their hardware and software assets to ensure the operational stability and security of their IT infrastructure. Among them, the CMDB (Configuration Management Data Base) system is a common IT asset management tool used to record and manage various configuration items in IT infrastructure. It can help enterprises achieve goals such as IT asset management, automated deployment, and change control on the basis of a comprehensive understanding of IT assets. How to manage resource permissions based on a graph database in a CMDB system is a difficult problem facing the development of the CMDB system. Existing resource limit management methods cannot fundamentally support CMDB resource permission management for various scenarios where actual permissions are complex, diverse, flexible, and changeable. Summary of the invention

[0003] In view of this, the purpose of the present invention is to provide a resource permission management method, device and electronic device based on a graph database to achieve flexible management and control of resource instance permissions, thereby supporting flexible and changeable permission management scenarios.

[0004] The present invention provides a resource authority management method based on a graph database, the method comprising:

[0005] Based on the current resource permission management scenario and the current resource permission management requirements, create at least one label tree and at least one role; wherein each label tree includes a root node label and at least one child node label;

[0006] Get the attribute information corresponding to each resource instance currently stored in the graph database;

[0007] For each child node tag, if it is determined based on the attribute information corresponding to each resource instance that there is a resource instance to be bound corresponding to the child node tag, the child node tag is bound to the corresponding resource instance to be bound, and a first relationship path between the child node tag and the corresponding bound resource instance is generated;

[0008] For each role, if it is determined that there is a sub-node label to be bound corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label, the role is bound to the corresponding sub-node label to be bound, and a second relationship path between the role and the corresponding bound sub-node label is generated;

[0009] Based on each first relationship path and each second relationship path, the permission of each resource instance is managed.

[0010] Furthermore, each tag tree is created in the following way:

[0011] Based on the current resource permission management and control requirements, multiple node labels are created, where the node labels include: at least one root node label, and at least one child node label corresponding to each root node label; the root node label is used to indicate the type corresponding to the label tree;

[0012] Based on the relationship between each root node label and each child node label, as well as the relationship between each child node label, a label tree of the type corresponding to each root node label is generated.

[0013] Further, for each child node tag, if it is determined based on the attribute information corresponding to each resource instance that there is a resource instance to be bound corresponding to the child node tag, the child node tag is bound to the corresponding resource instance to be bound, and the step of generating a first relationship path between the child node tag and the corresponding bound resource instance includes:

[0014] Traverse each sub-node tag, and for each sub-node tag, compare the sub-node tag with the attribute information corresponding to each resource instance to determine whether there is target attribute information matching the sub-node tag;

[0015] If there is target attribute information matching the sub-node label, the target resource instance corresponding to the target attribute information is determined as the resource instance to be bound to the sub-node label;

[0016] Binding the subnode label to a corresponding resource instance to be bound, and generating a first relationship path between the subnode label and the corresponding bound resource instance;

[0017] If there is no target attribute information matching the sub-node tag, then skip this sub-node tag and continue to match the next sub-node tag until all sub-node tags have been matched.

[0018] Further, for each role, if it is determined that there is a sub-node label to be bound corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label, the role is bound to the corresponding sub-node label to be bound, and the step of generating a second relationship path between the role and the corresponding bound sub-node label includes:

[0019] Traverse each role, and for each role, determine the target sub-node label corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label;

[0020] If the role is not invalid, the target subnode label is determined as the subnode label to be bound to the role;

[0021] Binding the role to the corresponding sub-node label to be bound, generating a second relationship path between the role and the corresponding bound sub-node label;

[0022] If a role is invalid, skip this role and continue processing the next role until all roles have been processed.

[0023] Furthermore, based on the current resource permission control scenario and the current resource permission control requirements, the execution steps after creating at least one tag tree and at least one role also include:

[0024] Obtain each pre-established user account and the corresponding relationship between each user account and role;

[0025] Bind each user account with a corresponding role, and generate a third relationship path between each user account and the corresponding bound role.

[0026] Further, based on each first relationship path and each second relationship path, the step of managing the permission of each resource instance includes:

[0027] Get the current user account and the first query condition;

[0028] Based on the third relationship path, determine the first role played by the current user account;

[0029] Based on the first role and each second relationship path, determine a first child node label corresponding to the first role;

[0030] A query statement is generated based on the first child node label, the first query condition, and each first relationship path to query the corresponding resource instance.

[0031] Furthermore, the method also includes:

[0032] If there is at least one new resource instance in the graph database, obtain first attribute information corresponding to each new resource instance;

[0033] Based on each first attribute information and each sub-node label, generate a first label list corresponding to each new resource instance; wherein each first label list includes at least one second sub-node label to be bound to the corresponding new resource instance;

[0034] For each first label list, each second sub-node label in the first label list is bound to the corresponding new resource instance, and a fourth relationship path between each second sub-node label and the corresponding bound new resource instance is generated.

[0035] Furthermore, the method also includes:

[0036] Determine the resource instance whose attribute information has changed as the first resource instance;

[0037] Acquire the attribute change information of the first resource instance, and generate a second label list corresponding to the first resource instance based on each attribute change information and each sub-node label; wherein the second label list includes at least one third sub-node label to be bound to the first resource instance;

[0038] The first relationship path corresponding to the first resource instance is deleted, and each third sub-node tag is bound to the first resource instance to generate a fifth relationship path between each third sub-node tag and the corresponding bound first resource instance.

[0039] The present invention provides a resource authority management device based on a graph database, the device comprising:

[0040] A creation module, used to create at least one label tree and at least one role based on the current resource permission management scenario and the current resource permission management requirements; wherein each label tree includes a root node label and at least one child node label;

[0041] The acquisition module is used to obtain the attribute information corresponding to each resource instance currently stored in the graph database;

[0042] A first generating module is used for binding the sub-node label to the corresponding resource instance to be bound, and generating a first relationship path between the sub-node label and the corresponding bound resource instance, if it is determined that there is a resource instance to be bound corresponding to the sub-node label based on the attribute information corresponding to each resource instance.

[0043] A second generating module is used for binding the role to the corresponding sub-node label to be bound, and generating a second relationship path between the role and the corresponding bound sub-node label, if it is determined that there is a sub-node label to be bound corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label.

[0044] The management module is used to manage the authority of each resource instance based on each first relationship path and each second relationship path.

[0045] An electronic device provided by the present invention includes a memory and a processor. The memory stores a computer program that can be run on the processor. When the processor executes the computer program, the steps of any one of the above-mentioned resource permission management methods based on a graph database are implemented.

[0046] The resource permission management method, device and electronic device based on graph database provided by the present invention include: creating at least one label tree and at least one role based on the current resource permission management scenario and demand; for each sub-node label of each label tree, if it is determined that there is a resource instance to be bound corresponding to the sub-node label, generating a first relationship path between the sub-node label and the corresponding bound resource instance; for each role, if it is determined that there is a sub-node label to be bound corresponding to the role, generating a second relationship path between the role and the corresponding bound sub-node label; based on each first relationship path and second relationship path, managing the permission of each resource instance. This method can realize flexible management and control of resource instance permissions by adding tree-structured labels in the CMDB system, binding roles to labels, and binding labels to resource instances, thereby supporting flexible and changeable permission management scenarios.

[0047] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0048] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0050] Figure 1 A flowchart of a resource authority management method based on a graph database provided in an embodiment of the present invention;

[0051] Figure 2 A schematic diagram of the structure of a regional label tree provided by an embodiment of the present invention;

[0052] Figure 3 A schematic diagram of the overall logical structure of permissions provided by an embodiment of the present invention;

[0053] Figure 4 A flowchart of another resource authority management method based on a graph database provided in an embodiment of the present invention;

[0054] Figure 5 A schematic diagram of the logical structure of a tag tree provided by an embodiment of the present invention;

[0055] Figure 6 A first relationship path diagram of a plurality of sub-node labels and corresponding bound resource instances provided by an embodiment of the present invention;

[0056] Figure 7 A schematic diagram of a permission data binding process in the system initialization phase provided by an embodiment of the present invention;

[0057] Figure 8 A schematic diagram of a resource authority authentication process provided by an embodiment of the present invention;

[0058] Fig. 9 A schematic diagram of an incremental resource permission data binding process provided by an embodiment of the present invention;

[0059] Fig.10 A schematic diagram of the structure of a resource authority management device based on a graph database provided in an embodiment of the present invention;

[0060] Fig.11 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0061] The technical solution of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0062] With the development of informatization and digitalization, more and more companies are beginning to use IT asset management tools to manage their hardware and software assets to ensure the operational stability and security of their IT infrastructure. Among them, CMDB is a common IT asset management tool used to record and manage various configuration items in IT infrastructure. It can help enterprises achieve goals such as IT asset management, automated deployment, and change control based on a comprehensive understanding of IT assets. In CMDB, using graph databases as data storage engines has become an increasingly popular practice. Compared with traditional relational databases, graph databases have better flexibility and scalability, and are more efficient in processing complex relational data.

[0063] In order to avoid data fragmentation caused by storing resource data in a graph database and permission data in other databases (such as MySQL, Oracle), it is a reasonable option to store data in a graph database. How to manage resource permissions based on a graph database in a CMDB system is a difficult problem faced by the development of a CMDB system.

[0064] The patent with application number CN202310520123.7 discloses a method and device for permission management based on a graph database. Once the abstract permission management model in the scheme is determined and the actual graph permission management model is generated according to the abstract model, the overall structure will be solidified into the graph database and cannot be adjusted, or the adjustment is very difficult, and it is impossible to flexibly customize and expand the permission structure. Therefore, the application of this patent cannot fundamentally support the application of CMDB resource permissions to various scenarios where the actual permissions are complex, diverse, flexible and changeable.

[0065] Based on this, the embodiments of the present invention provide a resource permission management method, device and electronic device based on a graph database, which can be applied to applications that need to manage resource permissions.

[0066] To facilitate understanding of this embodiment, a resource authority management method based on a graph database disclosed in an embodiment of the present invention is first introduced in detail; Figure 1 As shown, the method comprises the following steps:

[0067] Step S102: based on the current resource permission management scenario and the current resource permission management requirement, create at least one label tree and at least one role; wherein each label tree includes a root node label and at least one child node label.

[0068] In the specific implementation process, resource permission management scenarios are complex and diverse, and the resource permission management requirements corresponding to each resource permission management scenario are also flexible and changeable. Therefore, the permission management in the CMDB system, like other business of the system, may need to be adjusted at any time to adapt to new resource permission management scenarios (that is, new business scenarios).

[0069] Specifically, the current resource permission control requirements corresponding to the current resource permission control scenario can be determined according to actual needs; and at least one role corresponding to the scenario can be created according to the current resource permission control scenario, and then at least one label tree can be created according to the current resource permission control requirements. The label tree includes sub-node labels, and the sub-node labels can serve as an association bridge between the role and the resource instance. By binding the role to the sub-node label, and the binding of the sub-node label to the resource instance, the resource instance accessible to the role can be determined (that is, the access rights of the role are determined, and the same role is granted the same access rights), thereby realizing a flexible permission control scenario.

[0070] In actual implementation, the above current resource permission management requirement may include only one sub-requirement or multiple sub-requirements, and different label trees can be created according to each different sub-requirement. For example, when there is only one sub-requirement, one label tree corresponding to the sub-requirement can be created, and if there are two different sub-requirements, one corresponding label tree can be created for each sub-requirement (that is, for two different sub-requirements, a total of two label trees need to be created).

[0071] Each of the above-mentioned label trees consists of a root node label and a child node label, wherein the number of root node labels is 1, which is used to indicate the type of the corresponding label tree, and the number of child node labels can be 1 or more; and the child node labels can include only the first-level node labels, or can include the first-level node labels and node labels of the first level or above (such as the second-level node labels, ..., n-level node labels), and the number of node labels at each level can be one or more.

[0072] Assuming that the current resource permission control requirement corresponds to only one sub-requirement, which requires authorization management according to the region where the resource belongs, you can create a regional label tree. For details, see Figure 2 A structural diagram of a regional label tree is shown, where the region (equivalent to the root node label of the regional label tree) includes China (equivalent to the first-level child node label of the regional label tree), China includes Beijing, Shanghai, Guangzhou (equivalent to the second-level child node label of the regional label tree), etc., and Beijing includes Dongcheng, Xicheng, Chaoyang, Haidian (equivalent to the third-level child node label of the regional label tree), etc.

[0073] Step S104, obtaining attribute information corresponding to each resource instance currently stored in the graph database.

[0074] In CMDB (Configuration Management Data Base, which can be understood as an asset management tool for recording and managing various configuration items in IT infrastructure) systems, the above-mentioned graph database is generally used as a data storage engine. Graph databases are data management systems that use nodes and edges as basic storage units and are designed to efficiently store and query graph data. The concept of graph is crucial to understanding graph databases. A graph is a set of nodes and edges, where "nodes" represent entities (i.e. resource instances) and "edges" represent relationships between entities. In a graph database, the relationships between data are as important as the data itself, and they are stored as part of the data. This architecture enables graph databases to quickly respond to complex association queries because the relationships between entities have been stored in the database in advance. Graph databases can intuitively visualize relationships and are the best way to store, query, and analyze highly interconnected data. Graph databases belong to non-relational databases (NoSQL). Graph databases are very different from relational databases in terms of data storage, query, and data structure. The graph data structure directly stores the dependencies between nodes, while relational databases and other types of non-relational databases represent the relationships between data in an indirect way. Graph databases store the relationships between data as part of the data. Labels (i.e. labels set for the relationships between entities), directions, and attributes can be added to the relationships. However, queries on relationships in other databases must be concretized at runtime. This is why graph databases have huge performance advantages over other types of databases in relationship queries.

[0075] In the specific implementation process, we can first determine the entities of several dimensions such as servers, networks, IDCs, cabinets, storage, and accessories according to the current resource permission management scenario; then determine the attributes of these entities (that is, the attribute information of resource instances), such as servers will have SN serial numbers, IP addresses, manufacturers, hardware configurations (such as CPU, memory, hard disk, network card, PCIE, BIOS), maintenance information, etc.; network equipment such as switches will also have manufacturers, models, bandwidth, etc.; then sort out the associations (or topological relationships) between the above information, such as the cabinet where the server is located, the host where the virtual machine is located, and the IDC where the cabinet is located; more complex ones will have core switches, aggregation switches, access switches, and cascade relationships between cabinets and servers. After the above information is sorted out, data modeling is performed through ER modeling tools, and then the above information is solidified into the graph database of CMDB. However, information solidification is not the purpose and has no value. Only when the information flows dynamically can it be valuable. Therefore, process specifications can be constructed based on this information, such as the online, offline, maintenance, and installation processes of servers. At the same time, the changes in status during the process must be managed synchronously; visualization and dynamic display of topological relationships, such as the cascade relationship between switches and servers, and the display of status (normal or faulty).

[0076] In fact, according to the number of entities obtained (equivalent to resource instances), a corresponding number of nodes can be created in the graph database; the entity attributes of the obtained entities can be transferred to the node attributes of the corresponding nodes in the graph database (equivalent to the attribute information of the resource instance); according to the relationship between the obtained entities, edges can be created between the nodes corresponding to the related entities.

[0077] Step S106, for each child node tag, if it is determined based on the attribute information corresponding to each resource instance that there is a resource instance to be bound corresponding to the child node tag, the child node tag is bound to the corresponding resource instance to be bound, and a first relationship path between the child node tag and the corresponding bound resource instance is generated.

[0078] In the specific implementation process, the attribute information of each resource instance may include multiple sub-attribute information. For example, the attribute information of resource instance A is: cpu (central processing unit) = 16, ip (internet protocol) = 10.1.1.7; then cpu = 16 is one of the sub-attribute information, and ip = 10.1.1.7 is another sub-attribute information.

[0079] Therefore, in actual implementation, for each child node label, it can be compared with the attribute information corresponding to each resource instance in the graph database. If there is a target resource instance (that is, equivalent to the resource instance to be bound corresponding to the above-mentioned child node label) corresponding to the attribute information that matches the current child node label (that is, the matching attribute information contains the same sub-attribute information as the current child node label), the current child node label can be bound to the target resource instance, and the first relationship path between the current child node label and the target resource instance is generated (it should be noted that the first relationship path type is "has", so generating the first relationship path between the current child node label and the target resource instance can indicate that the target resource instance has the current child node label).

[0080] Specifically, taking the sub-node label "Region is Beijing" as an example, if the attribute information of resource instance A in the graph database has a sub-attribute information of "Region = Beijing", then resource instance A can be considered as the target resource instance corresponding to the attribute information matching the sub-node label "Region is Beijing", and then the sub-node label "Region is Beijing" is bound to resource instance A. In actual implementation, if the current sub-node label needs to be bound to the target resource instance, the corresponding target resource instance is selected, and a relationship path from the current sub-node label to the target resource instance is created (the relationship path type is "has").

[0081] It should be noted that a subnode label can correspond to multiple resource instances, and a resource instance can also have multiple subnode labels.

[0082] Step S108, for each role, if it is determined that there is a sub-node label to be bound corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label, the role is bound to the corresponding sub-node label to be bound, and a second relationship path between the role and the corresponding bound sub-node label is generated.

[0083] A role usually refers to a group of people with certain common characteristics, such as department, location, seniority, level, job responsibilities, etc. At the beginning of the system, the administrator can create multiple roles corresponding to different tags according to the business needs of the current resource permission management scenario, and grant the same access rights to the same roles; for example, role a has access rights to all sub-node tags, and role b only has access rights to the sub-node tag "Region is Haidian". When it is necessary to grant access rights to a user, the user can be assigned to the corresponding role to grant the required permissions.

[0084] Therefore, in actual implementation, for each role, it can be matched with each sub-node label. If there is a sub-node label that matches the current role (that is, there is a sub-node label in each sub-node label that is the same as the sub-node label corresponding to the current role obtained in advance), that is, there is a sub-node label to be bound to the current role, the current sub-node label can be bound to the matching sub-node label to generate a second relationship path between the current role and the corresponding bound sub-node label. It should be noted that the second relationship path type is "accessible", so the second relationship path between the current role and the corresponding bound sub-node label can indicate that the current role can access the corresponding bound sub-node label.

[0085] Specifically, taking "role is resource administrator" as an example, if the sub-node label corresponding to the role of "resource administrator" is obtained in advance as "region is Beijing", and there is a sub-node label "region is Beijing" in each sub-node label, then the sub-node label "region is Beijing" can be considered as a sub-node label that matches the role of "resource administrator", and then the role of "resource administrator" is bound to the sub-node label "region is Beijing". In actual implementation, if the current role needs to be bound to a sub-node label, select the corresponding matching sub-node label, and create a relationship path between the current role and the sub-node label to be bound (the relationship path type is "accessible").

[0086] It should be noted that a role can access multiple sub-node labels, and a sub-node label can also be accessed by multiple roles.

[0087] Step S110: managing the authority of each resource instance based on each first relationship path and each second relationship path.

[0088] In the specific implementation process, this application adds tree-structured tags (i.e., tag trees) to the CMDB system, and can implement flexible permission management scenarios through binding roles and tags, and binding tags and resource instances; that is, the resource permission management method provided by this application is highly adaptable and can support flexible and changeable permission scenarios at a relatively low cost or with a small amount of configuration.

[0089] Specifically, after the present application uses labels as the association bridge between roles and resource instances, since the labels have a tree structure, combined with the path query characteristics of the graph database, it is convenient to query the resource instances corresponding to the labels and sub-labels. This also simplifies the aggregation and range query logic of resource instances and has higher query efficiency.

[0090] In fact, a role can also have multiple tags, and these multiple tags are effective in parallel. According to the resources corresponding to each tag, the resources bound to the tags owned by the role can be authorized to the user bound to the role, so that the user can perform operations such as viewing these resources, and generate a permission record for storage.

[0091] When a user wants to perform a user operation, the corresponding sub-node label is filtered out according to the user's role and the second relationship path corresponding to the role, and then the corresponding resource instance (that is, the resource on which the user has the authority to perform the user operation) can be filtered out according to the first relationship path corresponding to the filtered sub-node label.

[0092] For details, please refer to Figure 3 The schematic diagram of the overall logical structure of permissions shown in the figure shows that a user account has a role, a role is associated with a tag (accessible), and a tag is associated with a resource instance (an instance has a tag). Through the serial association relationship, the resource instance that the account can access is determined.

[0093] The resource permission management method based on the graph database provided in the above embodiment includes: creating at least one label tree and at least one role based on the current resource permission management scenario and requirements; for each sub-node label of each label tree, if it is determined that there is a resource instance to be bound corresponding to the sub-node label, generating a first relationship path between the sub-node label and the corresponding bound resource instance; for each role, if it is determined that there is a sub-node label to be bound corresponding to the role, generating a second relationship path between the role and the corresponding bound sub-node label; based on each first relationship path and second relationship path, managing the permissions of each resource instance. This method can realize flexible management and control of resource instance permissions by adding tree-structured labels in the CMDB system, binding roles to labels, and binding labels to resource instances, thereby supporting flexible and changeable permission management scenarios.

[0094] The embodiment of the present invention also provides another resource authority management method based on a graph database, which is implemented on the basis of the method of the above embodiment; Figure 4 As shown, the method comprises the following steps:

[0095] Step S202: based on the current resource permission management scenario and the current resource permission management requirement, create at least one label tree and at least one role; wherein each label tree includes a root node label and at least one child node label.

[0096] In the specific implementation process, each of the above label trees can be created and generated in the following ways:

[0097] Based on the current resource permission management requirements, multiple node labels are created, where the node labels include: at least one root node label, and at least one child node label corresponding to each root node label; the root node label is used to indicate the type corresponding to the label tree; the child node label is used to indicate the attributes of the resource instance.

[0098] Based on the relationship between each root node label and each child node label, as well as the relationship between each child node label, a label tree of the type corresponding to each root node label is generated.

[0099] Resource permission management scenarios are complex and diverse, and the resource permission management requirements corresponding to each resource permission management scenario are also flexible and changeable. In actual implementation, a label tree can be planned according to the resource permission management requirements, and node labels (sub-node labels and root node labels) can be created in the system to generate relationships between node labels, thereby realizing the creation of a planned label tree (labels with a tree structure introduced into the system); sub-node labels can include only first-level node labels, or first-level node labels and node labels of levels above one (such as second-level node labels, ..., n-level node labels). The relationship between sub-node labels is reflected in that the next-level node label extended from each upper-level node label belongs to the upper-level node label. For example, the n-level node label belongs to the n-1-level node label that extends the n-level node label, and the second-level node label belongs to the first-level node label that extends the second-level node label. Specifically, the logical structure of the label tree can be as follows Figure 5 As shown, the label tree type is the root of each label tree (that is, the root node label). Each type of label tree takes the root as the starting point and expands downward to a first-level child node label. Each first-level child node label then expands downward to a second-level child node label, and so on, eventually forming a label tree.

[0100] In the specific implementation, the system can design multiple label trees according to actual needs, such as regional label tree, business label tree, computer room label tree, etc. Figure 2 Take this as an example to illustrate: Figure 2 is a regional label tree, where region (i.e., the root node label) is the type of the label tree. China (i.e., a first-level child node label of the regional label tree) belongs to the region, Beijing, Shanghai, Guangzhou, etc. (i.e., multiple second-level child node labels extended from a first-level child node label "China" of the regional label tree) belong to China, and Dongcheng, Xicheng, Chaoyang, Haidian, etc. (equivalent to multiple third-level child node labels extended from a second-level child node label "Beijing" of the regional label tree) belong to Beijing.

[0101] In fact, this application proposal supports custom extension of tags, which can well support the scalability of resource permission management business. Through custom tags, new dimensions can be introduced to meet new scenario maintenance requirements.

[0102] Step S204, obtaining each pre-established user account and the corresponding relationship between each user account and a role.

[0103] Step S206: bind each user account with a corresponding role, and generate a third relationship path between each user account and the corresponding bound role.

[0104] In the specific implementation process, according to the current resource permission management scenario, the corresponding roles, such as administrator, operator, etc., can be created in the system first, and then the role of the current account can be obtained to bind the role to the user account; specifically, the user account created by the user can be obtained, the role played by the user account in the current actual application scenario can be obtained, the user account can be bound to the actual role played, and a third relationship path between the user account and the corresponding bound role can be generated (the type is "has", that is, the user account has the corresponding bound role); for example, user M creates a user account 123456, and the role played by the user account in the current application scenario is administrator, then the user account of the user can be bound to the administrator role, thereby generating a third relationship path between the user account and the corresponding bound administrator role; that is, the user account of the user is associated with the administrator role, and the association type is "has", and the user account 123456 has the administrator role.

[0105] Step S208, obtaining the attribute information corresponding to each resource instance currently stored in the graph database.

[0106] Step S210, traverse each child node tag, and for each child node tag, compare the child node tag with the attribute information corresponding to each resource instance to determine whether there is target attribute information matching the child node tag; if there is target attribute information matching the child node tag, determine the target resource instance corresponding to the target attribute information as the resource instance to be bound to the child node tag; bind the child node tag to the corresponding resource instance to be bound, and generate a first relationship path between the child node tag and the corresponding bound resource instance; if there is no target attribute information matching the child node tag, skip this child node tag, and continue to compare the next child node tag until all child node tags have been compared.

[0107] In the specific implementation process, when binding resources to labels, for each label tree, all sub-node labels of the label tree can be processed cyclically according to the breadth-first rule (that is, in order from the first-level sub-node label to the n-level sub-node label). If the sub-node label currently processed by the label tree needs to be bound to a resource instance (that is, there is a target resource instance corresponding to the target attribute information matching the sub-node label in the CMDB system), the corresponding target resource instance is selected, and a relationship from the current sub-node label to the corresponding target resource instance is created (the relationship type is: "has"). If the current sub-node label does not need to be bound to a resource instance, the current sub-node label is skipped and the next sub-node label is processed until all sub-node labels have been processed.

[0108] In fact, generating the first relationship path between each sub-node label and the corresponding bound resource instance can be understood as marking the resource instance with the corresponding sub-node label.

[0109] For details, please refer to Figure 6 A first relationship path diagram of a plurality of sub-node labels and corresponding bound resource instances is shown, where region and business represent two types of labels (i.e., region label tree and business label tree), respectively. Server resource 01, server resource 02, ..., server resource n can be understood as a plurality of resource instances, and the resource instances of these servers have two sub-node labels, region and business. Among them, the sub-node label of server resource 01 in the region label tree is Xicheng, and the sub-node label in the business label tree is billing; the sub-node label of server resource 02 in the region label tree is Chaoyang, and the sub-node label in the business label tree is call; the sub-node label of server resource n in the region label tree is Changping, and the sub-node label in the business label tree is MMS.

[0110] Step S212, traverse each role, for each role, based on the pre-acquired correspondence between each role and the sub-node label, determine the target sub-node label corresponding to the role; if the role is not invalid, determine the target sub-node label as the sub-node label to be bound to the role; bind the role with the corresponding sub-node label to be bound, and generate a second relationship path between the role and the corresponding bound sub-node label; if the role is invalid, skip this role and continue to process the next role until all roles have been processed.

[0111] In the specific implementation process, when binding tags to roles, all roles created in the current scenario can be processed cyclically. For each role, if the currently processed role needs to be bound to a sub-node tag (that is, the role has not expired in the CMDB system, which can also be understood as the creation time of the role has not exceeded the set time), the corresponding target sub-node tag is selected, and a relationship from the current role to the corresponding sub-node tag is created (the relationship type is: accessible). If the current role does not need to be bound to a sub-node tag (that is, the role has expired in the CMDB system, which can also be understood as the creation time of the role has exceeded the set time), the current role is skipped and the next role is processed until all roles have been processed.

[0112] In fact, generating the second relationship path between each role and the corresponding bound sub-node label can be understood as labeling the role with the corresponding sub-node label.

[0113] In the specific implementation process, resource instance permission management includes two parts, one of which is resource permission data binding, and the other is resource permission authentication. Resource permission data binding includes: system initialization phase permission data binding, incremental resource permission data binding, and modified resource permission data binding; and before resource permission data binding, it is necessary to create the corresponding role in the system and create a planned label tree. To better understand the above embodiments, please refer to Figure 7 The figure shows a schematic diagram of the permission data binding process in the system initialization phase.

[0114] Specifically, the steps of the resource permission data binding process in the system initialization phase include: planning a tag tree according to system requirements, creating tag nodes in the system, and generating relationships between tags; creating roles in the system and binding roles to user accounts; binding tags to resources: looping through all tags in breadth-first order, selecting tags, and if the currently selected tag needs to be bound to a resource instance, select the corresponding resource instance, bind the tag to the resource, and create a relationship from the current tag to the resource instance (relationship type is: has); if the current tag does not need to be bound to a resource instance, skip this tag and process the next tag until all tags have been processed; binding tags to roles: looping through all roles, selecting a role, and if the currently selected role needs to be bound to a tag, select the corresponding tag, bind the tag to the role, and create a relationship between the current role and the tag (relationship type is: accessible); if the current role does not need to be bound to a tag, skip the current role until all roles have been processed; end data binding.

[0115] Step S214, obtain the current user account and the first query condition; based on the third relationship path, determine the first role played by the current user account; based on the first role and each second relationship path, determine the first child node label that is accessible to the first role; generate a query statement based on the first child node label, the first query condition and each first relationship path to query the corresponding resource instance.

[0116] In the specific implementation process, after the permission data binding process in the system initialization phase is completed, the resource permission authentication process can be executed, that is, when a user queries a resource instance in the system, the resource instance accessible to the user needs to be returned in the return result according to the resource permission binding situation. In order to better understand the above embodiment, please refer to Figure 8 A schematic diagram of a resource permission authentication process is shown.

[0117] Specifically, the process steps of resource permission authentication include: obtaining the role of the current account, and the condition parameters of the query input, that is, the instance query condition (equivalent to the above-mentioned first query condition), wherein the above-mentioned instance query condition can be input by the user according to actual needs, for example, it can be a specific IP address, etc.; then the role queries the sub-node labels accessible to the role of the current account (in fact, the sub-node labels accessible to the role of the current account, that is, the above-mentioned first sub-node labels, can be determined according to the second relationship path corresponding to each role); the library query statement is created according to the instance query condition, and the query condition of the relationship path between the label and the resource instance is supplemented in the query statement; since the label and the instance are connected through a relationship, the corresponding resource instance can be queried through the path condition of the graph database (that is, according to the first relationship path corresponding to each sub-node label, the resource instance bound to the sub-node label accessible to the role of the current account can be determined), and since there is a tree structure between the labels, the resource instances corresponding to all sub-labels under a certain label can be supported through the graph query feature, so as to achieve the effect of data range query and aggregation; the assembled query statement is executed in the graph database to obtain the query result, and the query result is returned, and the query ends.

[0118] In actual implementation, assuming that the instance query condition is IP=d, and the sub-node label accessible to the role of the current account is M, then after supplementing the query condition of the relationship path between the label and the resource instance in the query statement (that is, supplementing the first relationship path between each sub-node label and the corresponding bound resource instance), the resource instance bound to M can be determined, and then a search is made from the resource instances bound to M to determine whether there is a resource instance with IP=d. If so, the found resource instance with IP=d can be fed back to the current user for the current user to operate, that is, the current user has the right to view the resource instance with IP=d; but if the resource instance with IP=d does not exist in the resource instances bound to M, it is considered that the current user has no right to view the resource instance with IP=d.

[0119] In the above method, after using tags as the association bridge between roles and resource instances, since tags have a tree structure, combined with the path query characteristics of the graph database, it is convenient to query the resource instances corresponding to tags and sub-tags. This also simplifies the aggregation and range query logic of resource instances and has higher query efficiency.

[0120] Step S216, if there is at least one new resource instance in the graph database, obtain the first attribute information corresponding to each new resource instance; based on each first attribute information and each child node label, generate a first label list corresponding to each new resource instance; wherein each first label list includes at least one second child node label to be bound to the corresponding new resource instance (that is, the child node label in each first label list is actually a child node label that matches the first attribute information of the corresponding new resource instance to be bound); for each first label list, bind each second child node label in the first label list to the corresponding new resource instance, and generate a fourth relationship path between each second child node label and the corresponding bound new resource instance.

[0121] In the specific implementation process, when there is a new resource instance in the system (equivalent to the above new resource instance), the incremental resource binding label process needs to be triggered. In order to better understand the above embodiment, please refer to Fig. 9 A schematic diagram of an incremental resource permission data binding process is shown. Specifically, the incremental resource permission data binding process (i.e., the process of binding labels to newly added resource instances) includes: creating a new resource instance, selecting the label to be bound (i.e., selecting the sub-node label that matches each first attribute information from each existing sub-node label according to the first attribute information corresponding to each new resource instance) to the first label list corresponding to each new resource instance, binding the label in the first label list to the new resource instance: looping through all the labels in the first label list, selecting the current label, and creating a relationship between the corresponding new resource instance and the current label (relationship type: "has"); the incremental data binding ends.

[0122] Step S218, determine the resource instance whose attribute information has changed as the first resource instance; obtain the attribute change information of the first resource instance, and generate a second label list corresponding to the first resource instance based on each attribute change information and each child node label; wherein the second label list includes at least one third child node label to be bound to the first resource instance; delete the first relationship path corresponding to the first resource instance, obtain a new first relationship path between each child node label and the corresponding resource instance to be bound, and bind each third child node label to the first resource instance, and generate a fifth relationship path between each third child node label and the corresponding bound first resource instance.

[0123] In the specific implementation process, when there is a resource instance in the system whose permission data needs to be modified (equivalent to the first resource instance mentioned above), the resource unbinding label process can be triggered first, and then the resource binding label process can be triggered. Specifically, the processing flow when modifying resource permission data is similar to that when adding a new resource instance. The difference is that when modifying permission data, there is no need to create a resource instance. Moreover, before selecting the new label to be bound (that is, the third child node label, which can actually be understood as the child node label that matches the attribute change information of the first resource instance mentioned above) to the new label list (that is, the second label list), the first relationship path between the first resource instance and the corresponding bound child node label before the attribute information changes can be deleted, thereby obtaining a new first relationship path between each child node label and the corresponding resource instance to be bound.

[0124] In actual implementation, after selecting the third sub-node label to be bound to the second label list, each third sub-node label can be bound to the corresponding first resource instance to generate a fifth relationship path between each third sub-node label and the corresponding bound first resource instance.

[0125] In the specific implementation process, after executing the above steps S216 and S218, the steps that can also be executed include: obtaining the current user account and the first query condition; based on the third relationship path, determining the first role played by the current user account; based on the first role and each second relationship path, determining the first child node label accessed by the first role; based on the first child node label, the first query condition, each new first relationship path, each fourth relationship path and each fifth relationship path, generating a new query statement to query the corresponding resource instance, and / or new resource instance, and / or first resource instance.

[0126] In actual implementation, after the incremental resource permission data binding and the modified resource permission data binding processes are completed, a new resource permission authentication process can be executed. Specifically, the steps of the new resource permission authentication process include: obtaining the role of the current account, and the query input condition parameters, that is, the instance query condition (equivalent to the above-mentioned first query condition), wherein the above-mentioned instance query condition can be input by the user according to actual needs, for example, it can be a specific IP address, etc.; then the role queries the child node label accessible to the role of the current account (in fact, the child node label accessible to the role of the current account can be determined according to the second relationship path corresponding to each role, that is, the above-mentioned first child node label); the instance query condition creates a gallery query statement, and the query condition of the relationship path between the label and the resource instance is supplemented in the query statement; since the label and the instance are connected through a relationship, the corresponding resource instance can be queried through the path condition of the graph database; and in fact, the child node label accessible to the role of the current account, that is, the first child node label, may be the child node label corresponding to the resource instance, and / or the second child node label corresponding to the new resource instance, and / or the third child node label corresponding to the first resource instance.

[0127] Therefore, a new query statement can be generated based on the first child-node label, the first query condition, the new first relationship path corresponding to each child-node label, the fourth relationship path corresponding to each second child-node label, and the fifth relationship path corresponding to each third child-node label to query the corresponding resource instance, and / or the new resource instance, and / or the first resource instance.

[0128] The patent with application number CN202111145407.X discloses a method for managing resource access rights, but the patent solution uses server instance tags to determine the corresponding resource group and then generate credentials to access the resource group. There is no need to configure different cloud server instance RAM roles, which facilitates management. However, labels cannot determine specific resource permissions, that is, it is impossible to determine the scope of resources accessible to the current user based on the user role. Therefore, the application of this patent makes it impossible to perform resource permission management in CMDB.

[0129] In the present application, the association between tags and resource instances, the association between roles and tags, and the association between user accounts and roles can actually be stored in the CMDB system. By introducing specially designed tree-structured tags, by binding roles to tags, and by binding tags to resource instances through automatically processed business rules, the scope of resources accessible to the current user can be determined based on the user role, thereby achieving flexible permission management and control of resource instances and supporting flexible and changeable scenarios. At the same time, the present application supports custom extensions to tags, so it can support the introduction of new permission system management and control dimensions, adapt to new scenario maintenance requirements, and solve the adaptive problem of resource permissions. When new resources are generated or resource attributes are changed, the resource permissions of the role can be automatically changed, and the resource retrieval efficiency based on permission system management can be guaranteed.

[0130] Specifically, the support for flexible and changeable resource permission scenarios in the present application solution is reflected in the following aspects: Since the system supports dynamic binding of roles and tags, and dynamic binding of tags and resource instances, the decoupling of roles and resource instances is achieved, and the flexible configuration of permissions is achieved through dynamic binding mapping of tags. In addition, the solution supports flexible customization of tags, so that the scope of application of the permission system is not limited to the current established scenarios, and it can also be expanded to support the addition of new scenarios in the future. For example, there are new resource permission management scenario requirements: it is required that authorization management can be performed according to the department to which the resources belong. Then, a department tag tree can be added. When authorizing, first add the corresponding department tag to each role, and then bind each department tag to the corresponding resource instance. In this way, the authorization dimension of resource permissions is increased by the department dimension to support new scenario requirements.

[0131] The embodiment of the present invention also provides a resource authority management device based on a graph database, such as Fig.10As shown, the device includes: a creation module 100, which is used to create at least one label tree and at least one role based on the current resource permission management scenario and the current resource permission management requirements; wherein each label tree includes a root node label and at least one child node label; an acquisition module 101, which is used to obtain the attribute information corresponding to each resource instance currently stored in the graph database; a first generation module 102, which is used to, for each child node label, if based on the attribute information corresponding to each resource instance, determine that there is a resource instance to be bound corresponding to the child node label, bind the child node label to the corresponding resource instance to be bound, and generate a first relationship path between the child node label and the corresponding bound resource instance; a second generation module 103, which is used to, for each role, if based on the correspondence between each role and the child node label obtained in advance, determine that there is a child node label to be bound corresponding to the role, bind the role to the corresponding child node label to be bound, and generate a second relationship path between the role and the corresponding bound child node label; a management module 104, which is used to manage the permissions of each resource instance based on each first relationship path and each second relationship path.

[0132] The above-mentioned resource permission management device based on graph database includes: creating at least one label tree and at least one role based on the current resource permission management scenario and demand; for each sub-node label of each label tree, if it is determined that there is a resource instance to be bound corresponding to the sub-node label, generating a first relationship path between the sub-node label and the corresponding bound resource instance; for each role, if it is determined that there is a sub-node label to be bound corresponding to the role, generating a second relationship path between the role and the corresponding bound sub-node label; based on each first relationship path and second relationship path, managing the permissions of each resource instance. The device can realize flexible management and control of resource instance permissions by adding tree-structured labels in the CMDB system, binding roles to labels, and binding labels to resource instances, thereby supporting flexible and changeable permission management scenarios.

[0133] Furthermore, the creation module is also used to:

[0134] Based on the current resource permission management and control requirements, multiple node labels are created, where the node labels include: at least one root node label, and at least one child node label corresponding to each root node label; the root node label is used to indicate the type corresponding to the label tree;

[0135] Based on the relationship between each root node label and each child node label, as well as the relationship between each child node label, a label tree of the type corresponding to each root node label is generated.

[0136] Furthermore, the first generating module is also used for:

[0137] Traverse each subnode tag, and for each subnode tag, compare the subnode tag with the attribute information corresponding to each resource instance to determine whether there is target attribute information matching the subnode tag;

[0138] If there is target attribute information matching the sub-node label, the target resource instance corresponding to the target attribute information is determined as the resource instance to be bound to the sub-node label;

[0139] Binding the subnode label to the corresponding resource instance to be bound, generating a first relationship path between the subnode label and the corresponding bound resource instance;

[0140] If there is no target attribute information matching the sub-node tag, then skip this sub-node tag and continue to match the next sub-node tag until all sub-node tags have been matched.

[0141] Furthermore, the second generation module is also used for:

[0142] Traverse each role, and for each role, determine the target sub-node label corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label;

[0143] If the role is not invalid, the target subnode label is determined as the subnode label to be bound to the role;

[0144] Binding the role to the corresponding sub-node label to be bound, generating a second relationship path between the role and the corresponding bound sub-node label;

[0145] If a role is invalid, skip this role and continue processing the next role until all roles have been processed.

[0146] Furthermore, the resource authority management device also includes:

[0147] Obtain each pre-established user account and the corresponding relationship between each user account and role;

[0148] Bind each user account with a corresponding role, and generate a third relationship path between each user account and the corresponding bound role.

[0149] Furthermore, the management module is also used to:

[0150] Get the current user account and the first query condition;

[0151] Based on the third relationship path, determine the first role played by the current user account;

[0152] Based on the first role and each second relationship path, determine a first child node label corresponding to the first role;

[0153] A query statement is generated based on the first child node label, the first query condition, and each first relationship path to query the corresponding resource instance.

[0154] Furthermore, the resource authority management device also includes:

[0155] If there is at least one new resource instance in the graph database, obtain first attribute information corresponding to each new resource instance;

[0156] Based on each first attribute information and each sub-node label, generate a first label list corresponding to each new resource instance; wherein each first label list includes at least one second sub-node label to be bound to the corresponding new resource instance;

[0157] For each first label list, each second sub-node label in the first label list is bound to the corresponding new resource instance, and a fourth relationship path between each second sub-node label and the corresponding bound new resource instance is generated.

[0158] Furthermore, the resource authority management device also includes:

[0159] Determine the resource instance whose attribute information has changed as the first resource instance;

[0160] Acquire the attribute change information of the first resource instance, and generate a second label list corresponding to the first resource instance based on each attribute change information and each sub-node label; wherein the second label list includes at least one third sub-node label to be bound to the first resource instance;

[0161] The first relationship path corresponding to the first resource instance is deleted, and each third sub-node tag is bound to the first resource instance to generate a fifth relationship path between each third sub-node tag and the corresponding bound first resource instance.

[0162] The resource permission management device based on graph database provided in the embodiment of the present invention has the same implementation principle and technical effects as the aforementioned resource permission management method embodiment based on graph database. For the embodiment of the resource permission management device based on graph database, reference can be made to the corresponding contents in the aforementioned resource permission management method embodiment based on graph database.

[0163] The embodiment of the present invention further provides an electronic device, see Fig.11 As shown, the electronic device includes a processor 130 and a memory 131, wherein the memory 131 stores machine executable instructions that can be executed by the processor 130, and the processor 130 executes the machine executable instructions to implement the above-mentioned resource permission management method based on the graph database.

[0164] Further, Fig.11 The electronic device shown further includes a bus 132 and a communication interface 133 , and the processor 130 , the communication interface 133 and the memory 131 are connected via the bus 132 .

[0165] The memory 131 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk storage. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 133 (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used. The bus 132 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.11 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0166] The processor 130 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 130. The above processor 130 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present invention can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module may be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 131, and the processor 130 reads the information in the memory 131 and completes the steps of the method of the above embodiment in combination with its hardware.

[0167] Finally, it should be noted that the above embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above embodiments, those skilled in the art should understand that any person skilled in the art can still modify the technical solutions recorded in the above embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be based on the protection scope of the claims.

Claims

1. A resource authority management method based on a graph database, characterized in that: The method comprises: Based on the current resource permission management scenario and the current resource permission management requirements, create at least one label tree and at least one role; wherein each of the label trees includes a root node label and at least one child node label; Get the attribute information corresponding to each resource instance currently stored in the graph database; For each of the sub-node tags, if it is determined based on the attribute information corresponding to each resource instance that there is a resource instance to be bound corresponding to the sub-node tag, the sub-node tag is bound to the corresponding resource instance to be bound, and a first relationship path between the sub-node tag and the corresponding bound resource instance is generated; For each of the roles, if it is determined that there is a sub-node label to be bound corresponding to the role based on the pre-acquired correspondence between each role and the sub-node label, the role is bound to the corresponding sub-node label to be bound, and a second relationship path between the role and the corresponding bound sub-node label is generated; Based on each of the first relationship paths and each of the second relationship paths, the authority of each resource instance is managed.

2. The method according to claim 1, characterized in that Each of the tag trees is created in the following way: Based on the current resource permission management and control requirements, multiple node labels are created, wherein the node labels include: at least one root node label, and at least one child node label corresponding to each root node label; the root node label is used to indicate the type corresponding to the label tree; Based on the relationship between each root node label and each child node label, and the relationship between each child node label, a label tree of the type corresponding to each root node label is generated.

3. The method according to claim 1, characterized in that For each of the sub-node tags, if it is determined based on the attribute information corresponding to each resource instance that there is a resource instance to be bound corresponding to the sub-node tag, the sub-node tag is bound to the corresponding resource instance to be bound, and the step of generating a first relationship path between the sub-node tag and the corresponding bound resource instance includes: Traversing each of the sub-node tags, for each of the sub-node tags, comparing the sub-node tag with the attribute information corresponding to each resource instance to determine whether there is target attribute information matching the sub-node tag; If there is target attribute information matching the sub-node tag, the target resource instance corresponding to the target attribute information is determined as the resource instance to be bound to the sub-node tag; Binding the subnode label to a corresponding resource instance to be bound, and generating a first relationship path between the subnode label and the corresponding bound resource instance; If there is no target attribute information matching the sub-node tag, then skip this sub-node tag and continue to match the next sub-node tag until all sub-node tags have been matched.

4. The method according to claim 3, characterized in that For each of the roles, if it is determined that there is a sub-node tag to be bound corresponding to the role based on the pre-acquired correspondence between each role and the sub-node tag, the role is bound to the corresponding sub-node tag to be bound, and the step of generating a second relationship path between the role and the corresponding bound sub-node tag includes: Traversing each of the roles, for each of the roles, based on the pre-acquired correspondence between each role and the sub-node label, determining the target sub-node label corresponding to the role; If the role is not invalid, determining the target subnode label as the subnode label to be bound to the role; Binding the role to the corresponding sub-node label to be bound, generating a second relationship path between the role and the corresponding bound sub-node label; If the role is invalid, skip this role and continue to process the next role until all roles have been processed.

5. The method according to claim 4, characterized in that Based on the current resource permission control scenario and the current resource permission control requirements, the execution steps after creating at least one tag tree and at least one role also include: Obtain each pre-established user account and the corresponding relationship between each user account and a role; Bind each of the user accounts with the corresponding role, and generate a third relationship path between each user account and the corresponding bound role.

6. The method according to claim 5, characterized in that Based on each of the first relationship paths and each of the second relationship paths, the step of managing the permissions of each resource instance includes: Get the current user account and the first query condition; Based on the third relationship path, determining a first role played by the current user account; Based on the first role and each of the second relationship paths, determine a first child node label corresponding to access by the first role; A query statement is generated based on the first sub-node label, the first query condition and each of the first relationship paths to query the corresponding resource instance.

7. The method according to claim 1, characterized in that The method further comprises: If there is at least one new resource instance in the graph database, obtain first attribute information corresponding to each new resource instance; Based on each of the first attribute information and each of the sub-node labels, a first label list corresponding to each of the new resource instances is generated; wherein each of the first label lists includes at least one second sub-node label to be bound to the corresponding new resource instance; For each of the first label lists, each of the second sub-node labels in the first label list is bound to a corresponding new resource instance, and a fourth relationship path between each of the second sub-node labels and the corresponding bound new resource instance is generated.

8. The method according to claim 7, characterized in that The method further comprises: Determine the resource instance whose attribute information has changed as the first resource instance; Acquire the attribute change information of the first resource instance, and generate a second label list corresponding to the first resource instance based on each of the attribute change information and each sub-node label; wherein the second label list includes at least one third sub-node label to be bound to the first resource instance; The first relationship path corresponding to the first resource instance is deleted, and each of the third sub-node tags is bound to the first resource instance, so as to generate a fifth relationship path between each of the third sub-node tags and the corresponding bound first resource instance.

9. A resource authority management device based on a graph database, characterized in that: The device comprises: A creation module, used to create at least one label tree and at least one role based on the current resource permission management scenario and the current resource permission management requirements; wherein each of the label trees includes a root node label and at least one child node label; The acquisition module is used to obtain the attribute information corresponding to each resource instance currently stored in the graph database; A first generating module is used for binding the sub-node label to the corresponding resource instance to be bound, and generating a first relationship path between the sub-node label and the corresponding bound resource instance, if it is determined that there is a resource instance to be bound corresponding to the sub-node label based on the attribute information corresponding to each resource instance. A second generating module is used for binding the role to the corresponding sub-node label to be bound, and generating a second relationship path between the role and the corresponding bound sub-node label, if it is determined that there is a sub-node label to be bound corresponding to the role based on the correspondence relationship between each role and the sub-node label obtained in advance. A management module is used to manage the authority of each resource instance based on each of the first relationship paths and each of the second relationship paths.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, wherein: When the processor executes the computer program, the steps of the resource permission management method based on the graph database described in any one of claims 1 to 8 are implemented.

Images