Authority management method, access control method, device and equipment based on RBAC model

Abstract

The invention provides an RBAC model-based authority management method, device and equipment, and an access control method, device and equipment, and relates to the technical field of authority management. According to the method, a role inheritance mechanism is introduced, so that the authority management process is remarkably simplified, and the redundancy of authority distribution is reduced. By determining the uppermost parent role and centrally configuring the authority set thereof, the system can automatically transmit the authority downwards along the inheritance relation structure diagram to ensure that all the child roles automatically obtain the corresponding authority without repeated configuration. The hierarchical permission inheritance mode not only improves the efficiency of permission allocation, but also enhances the flexibility and maintainability of the system, and can quickly adapt to the change of service requirements.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of permission management, in particular to a permission management method and an access control method based on an RBAC model, and a device. BACKGROUND

[0002] The Role-Based Access Control (RBAC) model has become the core mechanism for many enterprises to control resource access due to its many advantages in permission management. The traditional RBAC model manages user access permissions to system resources based on the association between roles and permissions. Users obtain corresponding permission sets by being assigned different roles, thereby achieving control over resource access.

[0003] However, as enterprise businesses continue to expand and business processes become increasingly complex, the traditional RBAC model gradually reveals its limitations. The number of roles is showing an explosive growth trend. In large enterprises, the diversification and refinement of businesses make role definition extremely complex. For example, an enterprise with thousands of employees may need to define hundreds or even thousands of roles to meet the needs of different departments and different business scenarios. This sharp increase in the number of roles not only increases the complexity of role management, but also makes the permission assignment process cumbersome and prone to errors, requiring administrators to spend a lot of time and effort to create, modify, and maintain these roles and their permission relationships. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide a permission management method, an access control method, an apparatus and a device based on an RBAC model to improve the problem of low efficiency of the existing permission management method.

[0005] In a first aspect, the embodiments of the present application provide a permission management method based on an RBAC model, the method comprising: determining a top-level parent role in a role set according to an inheritance relationship between the configured roles, wherein the roles in the role set other than the top-level parent role have one or more parent roles; obtaining a permission set configured for the top-level parent role; constructing an inheritance relationship structure diagram according to the inheritance relationship, and successively inheriting the permission set of the top-level parent role to lower-level roles along the inheritance relationship until reaching a bottom-level child role, wherein the nodes in the inheritance relationship structure diagram represent roles, and the edges represent inheritance relationships, and the permission set of the bottom-level child role is inherited to the permission sets of all its parent roles, and the permission set of a role is used to control the access permission of a user corresponding to the role to a corresponding resource.

[0006] In the implementation process, by introducing the role inheritance mechanism, the permission management process is significantly simplified, and the redundancy of permission allocation is reduced. By determining the top-level parent role and centrally configuring its permission set, the system can automatically transmit the permissions along the inheritance relationship structure diagram downward, ensuring that all child roles automatically obtain the corresponding permissions without repeated configuration. This hierarchical permission inheritance method not only improves the efficiency of permission allocation, but also enhances the flexibility and maintainability of the system, enabling it to quickly adapt to changes in business requirements.

[0007] Optionally, before determining the top-level parent role in the role set according to the inheritance relationship between the configured roles, the method further comprises: For a child role and its parent role, recursively traversing all parent roles of the parent role according to the inheritance relationship; If all parent roles include the child role, outputting prompt information indicating that the inheritance relationship is incorrect.

[0008] In the implementation process, before determining the role inheritance relationship, by recursively traversing to detect whether there is a circular inheritance (i.e., a child role pointing to itself through an inheritance chain), the configuration error of the inheritance relationship can be discovered and prompted in a timely manner. This mechanism effectively avoids permission calculation errors and system logic confusion caused by circular inheritance, ensuring the correctness and stability of the role inheritance relationship structure diagram.

[0009] Optionally, the inheritance relationship structure diagram is a directed acyclic graph or a tree structure diagram.

[0010] In the implementation process, the directed acyclic graph or tree structure diagram supports hierarchical permission inheritance, making permission management more intuitive, easy to understand and maintain. At the same time, this structure facilitates efficient permission calculation and dynamic adjustment.

[0011] Optionally, after constructing the inheritance relationship structure diagram according to the inheritance relationship, and inheriting the permission set of the top-level parent role to the lower-level roles along the inheritance relationship until reaching the lowest-level child role, the method further comprises: In response to detecting a role that needs to adjust permissions, updating the permission set of the role.

[0012] In the implementation process, when a role that needs to adjust permissions is detected, the system can update the permission set of the role in a timely manner, and automatically transmit the changes along the inheritance relationship downward, ensuring that the permissions of all related child roles are updated synchronously.

[0013] Optionally, the step of updating the permission set of the role in response to detecting a role that needs to adjust permissions comprises: In response to detecting a role that needs to adjust permissions, generating a permission adjustment instruction; updating, according to the permission adjustment instruction, the permission set of the role; The permission adjustment instruction is generated by the following method: obtaining a permission adjustment event, the permission adjustment event containing a role whose permission needs to be adjusted; performing feature extraction on the permission adjustment event to obtain a structured feature vector corresponding to the permission adjustment event; mapping the structured feature vector to an executable permission adjustment instruction through rule reasoning and machine learning prediction and outputting the permission adjustment instruction, the permission adjustment instruction being used to instruct adjustment of the permission of the role.

[0014] In the above implementation process, by introducing an intelligent permission adjustment instruction generation mechanism, the role whose permission needs to be adjusted can be automatically identified, and feature extraction and structured analysis are performed based on the permission adjustment event, and a rule reasoning and machine learning model is combined to accurately generate an executable permission adjustment instruction. This automatic and intelligent method greatly improves the efficiency and accuracy of permission adjustment and reduces the risk of manual intervention and operation errors.

[0015] Optionally, after the permission adjustment instruction is generated, before the permission set of the role is updated according to the permission adjustment instruction, the method further includes: obtaining a permission change risk degree of the permission adjustment; determining, according to the permission change risk degree, whether to perform the step of updating the permission set of the role according to the permission adjustment instruction.

[0016] In the above implementation process, a permission change risk degree evaluation mechanism is introduced, which can intelligently determine whether to perform the adjustment operation according to the risk level. For high-risk changes, the system can automatically intercept or transfer to a manual review process, thereby effectively avoiding security risks or business risks caused by improper permission adjustment. This risk pre-control mechanism significantly improves the security and reliability of permission management.

[0017] Optionally, after the permission adjustment instruction is generated in response to the detection of the role whose permission needs to be adjusted, the method further includes: verifying the permission adjustment instruction, and if the verification is passed, performing the step of updating the permission set of the role according to the permission adjustment instruction, wherein the verification includes at least one of syntax compliance verification, semantic logic verification, and security policy verification.

[0018] In the above implementation process, after the permission adjustment instruction is generated, a multi-level verification mechanism is added, including syntax compliance, semantic logic, and security policy verification, to ensure the correctness, rationality, and security of the instruction.

[0019] Optionally, the method further includes: In response to the inheritance relationship of each role configured in the inheritance relationship configuration interface, inheritance relationship is configured between each role; And / or, in the permission display interface, the permission set configured for each role is displayed; And / or, in response to the permission adjustment instruction triggered in the permission adjustment interface, the permission of the related role is adjusted.

[0020] In the above implementation process, by providing the inheritance relationship configuration interface, the permission display interface and the permission adjustment interface, the visualization and interactive operation of the permission management are realized. The administrator can intuitively configure the role inheritance relationship, view the permission allocation situation, and quickly trigger the permission adjustment instruction through the interface, which significantly improves the convenience and operation efficiency of the permission management.

[0021] In a second aspect, the embodiments of the present application provide an access control method, which comprises: Obtaining a user permission set of an access user, the user permission set of the access user being a permission set of a role corresponding to the access user, and the permission set of the role being obtained through the above-mentioned permission management method; Obtaining a resource permission set corresponding to a resource to be accessed by the access user; In the case that the user permission set includes the resource permission set, allowing the access user to access the resource.

[0022] In the above implementation process, by accurately matching the user's permission set and the resource required permission set, fine-grained access control is realized. The user's permission set is automatically calculated and updated in real time based on the role inheritance mechanism, ensuring the accuracy and timeliness of the permission information; and the resource permission set clearly defines the permission requirements required for accessing the resource. After comparison and verification, the system only allows access when the user has all the required permissions, effectively preventing unauthorized access and abuse of permissions, and significantly improving the security and reliability of the system.

[0023] Optionally, the method further comprises: Obtaining the permission usage of each user; Identifying abnormal permissions according to the permission usage; Outputting alarm information for the abnormal permissions.

[0024] In the above implementation process, by obtaining and analyzing the permission usage of the user in real time, abnormal permission behaviors (such as abuse of permissions, unauthorized access or abnormal use patterns) can be automatically identified, and alarm information can be output in time to notify the administrator. This active monitoring mechanism greatly improves the perception ability of the system to potential security threats, helps to quickly discover and handle permission abuse or internal threats, and prevents data leakage and loss of control of permissions.

[0025] Thirdly, embodiments of this application provide a permission management device based on the RBAC model, the device comprising: The role determination module is used to determine the top-level parent role in the role set based on the inheritance relationship between the configured roles, wherein other roles in the role set, excluding the top-level parent role, have one or more parent roles; The permission acquisition module is used to acquire the set of permissions configured for the top-level parent role; The permission inheritance module is used to inherit the permission set of the top-level parent role to the lower-level roles sequentially along the inheritance relationship structure graph constructed by the inheritance relationship, until the bottom-level child role is reached. In the inheritance relationship structure graph, the nodes represent roles and the edges represent inheritance relationships. The permission set of the bottom-level child role is inherited from the permission sets of all its parent roles. The permission set of a role is used to control the permissions of the user corresponding to that role to access the corresponding resources.

[0026] Fourthly, embodiments of this application provide an access control device, the device comprising: The user permission acquisition module is used to acquire the user permission set of the accessing user. The user permission set of the accessing user is the permission set of the role corresponding to the accessing user. The permission set of the role is obtained through the permission management method described above. The resource permission acquisition module is used to acquire the set of resource permissions corresponding to the resource that the accessing user wants to access; The access control module is used to allow the accessing user to access the resource when the user permission set includes the resource permission set.

[0027] Fifthly, embodiments of this application provide an electronic device including a processor and a memory, the memory storing computer-readable instructions, which, when executed by the processor, perform the steps of the methods provided in the first or second aspect above.

[0028] Sixthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the steps of the methods provided in the first or second aspect above.

[0029] In a seventh aspect, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the steps in the methods provided in the first or second aspect above.

[0030] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a schematic diagram of the structure of a permission management system provided in an embodiment of this application; Figure 2 A flowchart illustrating a permission management method based on the RBAC model provided in this application embodiment; Figure 3 A flowchart illustrating an access control method provided in an embodiment of this application; Figure 4 A structural block diagram of a permission management device based on the RBAC model provided in this application embodiment; Figure 5 A structural block diagram of an access control device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device for executing a permission management method or access control method based on the RBAC model, provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0034] It should be noted that the terms "system" and "network" in the embodiments of this invention can be used interchangeably. "Multiple" refers to two or more; therefore, in the embodiments of this invention, "multiple" can also be understood as "at least two". "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0035] It should also be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device.

[0036] This application provides a permission management method based on the RBAC model. This method significantly simplifies the permission management process and reduces redundancy in permission allocation by introducing a role inheritance mechanism. By determining the top-level parent role and centrally configuring its permission set, the system can automatically pass permissions down the inheritance hierarchy, ensuring that all child roles automatically acquire the corresponding permissions without repeated configuration. This hierarchical permission inheritance approach not only improves the efficiency of permission allocation but also enhances the system's flexibility and maintainability, enabling rapid adaptation to changes in business needs.

[0037] To make it easier to understand, the RBAC model will be briefly introduced below.

[0038] The core idea of ​​the RBAC model is to simplify the process of permission allocation and management by using roles as intermediaries between users and permissions. The RBAC model consists of three basic elements: users, roles, and permissions. Users obtain permissions by being assigned roles, and roles implement access control over resources by binding permissions.

[0039] The access control method in this solution can be implemented by the access control system, and the overall architecture of the access control system can be as follows: Figure 1 As shown, the permission management system may include a role definition module, a permission allocation module, a dynamic adjustment module, and a visualization support module.

[0040] The role definition module is responsible for creating roles, defining inheritance relationships, and storing role information. This module allows administrators to create new roles and assign initial permissions, and to define inheritance relationships between roles to form a role hierarchy. It also performs circular dependency checks to prevent circular dependencies in role inheritance relationships; the specific detection methods will be described in detail in subsequent embodiments. This module can also persist role information and its inheritance relationships to a database for use by other modules.

[0041] The core data structures of the role definition module include a role table, a permission table, and a role inheritance table, as shown below: Table 1. Roles

[0042] Table 2. Permissions Table

[0043] Table 3 Role Permissions

[0044] Table 4 Role Inheritance Table

[0045] The permission allocation module is responsible for automatically assigning permissions to users based on inheritance relationships and supports permission revoke and verification. This module automates permission allocation, reduces manual intervention, and improves the efficiency and accuracy of permission management. Its data structure includes a user table, a user role table, a resource table, and a resource permission table, as shown below: Table 5 User Table

[0046] Table 6 User Roles

[0047] Table 7 Resources

[0048] Table 8 Resource Permissions

[0049] The dynamic adjustment module primarily monitors changes in business requirements, role inheritance relationships, and permission allocation to automatically adjust role inheritance relationships and user permissions. For example, it monitors changes in business requirements in real time, identifies roles and permissions that need adjustment, dynamically adjusts the inheritance relationships between roles based on these requirements, and automatically updates user permissions according to the new inheritance relationships. When a user accesses resources, the system verifies their permissions based on the latest settings.

[0050] The visualization support module primarily provides a graphical interface that supports the visual management and monitoring of roles, permissions, and user relationships, helping administrators to manage and monitor permissions more efficiently.

[0051] The functions and implementation processes of each module in the above-mentioned permission management system can be described in detail in the subsequent method embodiments, and will not be elaborated on here.

[0052] Please refer to Figure 2 , Figure 2 A flowchart of a permission management method based on the RBAC model provided in this application embodiment is included, the method comprising the following steps: Step S110: Determine the top-level parent role in the role set based on the inheritance relationship between the configured roles.

[0053] First, the role definition module described above can be used to create roles, forming a role collection. When creating a role, the system generates a unique role ID and then stores the role information (role ID and role name) in the role table mentioned above. The role definition module can also configure inheritance relationships for each role, such as configuring inheritance relationships for child role IDs and parent role IDs, and storing them in the role inheritance table.

[0054] When determining the top-level parent role based on inheritance relationships, an inheritance relationship structure graph can be constructed first. In this graph, nodes represent roles and edges represent inheritance relationships. By traversing this inheritance relationship structure graph, the root node can be found, which represents the top-level parent role.

[0055] In some implementations, the inheritance relationship structure graph can be a directed acyclic graph or a tree structure graph. When creating the inheritance relationship structure graph, a graph structure can be created first, where nodes represent roles and edges represent inheritance relationships. Based on the information in the role inheritance table, nodes and edges are added to the graph, thereby forming the inheritance relationship structure graph.

[0056] Among them, the top-level parent character has no parent character, and other characters in the character set, excluding the top-level parent character, have one or more parent characters.

[0057] Step S120: Obtain the set of permissions configured for the top-level parent role.

[0058] The top-level parent role can be understood as the role with the lowest authority. Its child roles can inherit its set of permissions. For example, if the top-level parent role is the role corresponding to an ordinary employee, its child role can be a department manager. Then the department manager can inherit the permissions of the ordinary employee.

[0059] The permissions of the top-level parent role can be configured by the user, such as the role permission table mentioned above. The set of permissions for the top-level parent role can be obtained through the role permission table.

[0060] Understandably, there may be multiple top-level parent roles, so the permission set of each top-level parent role is obtained.

[0061] Step S130: Based on the inheritance relationship structure diagram constructed according to the inheritance relationship, the set of permissions of the top-level parent role is inherited to the lower-level roles in sequence along the inheritance relationship until the bottom-level child role is reached.

[0062] Inheritance relationship structure diagrams, such as directed acyclic graphs or tree structure diagrams, can be represented as follows: ; in, inherit , inherit And so on.

[0063] In this directed acyclic graph, This refers to the top-level parent role, where the edges represent inheritance relationships. Following these inheritance relationships, the following elements are sequentially... The set of permissions is inherited by lower-level roles, up to the lowest-level child role R. n .

[0064] When inheriting permissions, you can select a node representing the top-level parent role in the inheritance relationship structure diagram, and then visit its child roles sequentially along the inheritance relationship of that node. Each time a lower-level child role is visited, the permission set of the upper-level parent role is inherited to the lower-level child role, until the bottom-level child role is reached.

[0065] Understandably, some child roles may have more than one parent role. These child roles inherit the permission set of all their parent roles; that is, the permission set of the lowest-level child role is inherited from the permission set of all its parent roles. For example, the lowest-level child role R... n The parent role also includes S1, then R n It can also inherit the permission set of S1.

[0066] Thus, permissions can be inherited by each other role in the role set, thereby enabling permission configuration. Of course, if a sub-role also has special permissions, in addition to inheriting permissions, these special permissions can be manually configured and marked as non-inheritable.

[0067] In some implementations, for certain permissions of the top-level parent role, their inheritance generation and whether they are inheritable can be configured. For permissions that are not inheritable, they may not be inherited by child roles during permission inheritance. For permissions with an inheritance generation configured, if the permission reaches the required inheritance generation, it will not be inherited further. For example, for R1 in the above directed acyclic graph, if one of its permissions is configured with an inheritance generation of 3, then this permission will be inherited by R4, but not further. That is, R5 will not inherit this permission. When inheriting to R4, the permission can be marked as not inheritable in R4's permission set, so that R5 will not inherit this permission during inheritance.

[0068] Each character Includes the following attributes: Role ID: A unique identifier for a character; Role Name: The name of the role, used for display and management; Permissions: The set of permissions that this role directly possesses; Parent Roles: The set of parent roles that this role inherits from; ChildRoles: The set of child roles for this role; Right now .

[0069] After determining the permission set for each role, these roles can be associated with users, thus constructing the user role table and resource permission table mentioned above, thereby configuring user permissions. The permission set of a role can be used to control the access permissions of users associated with that role to the corresponding resources.

[0070] For example, the permissions of a resource can be determined based on the resource permission table, and the permissions of a user can be determined through the user role table and the role permission table. Thus, by comparing the permissions of the resource with the permissions of the user, it can be determined whether the user has the right to access the resource, thereby realizing user access control for resources.

[0071] In the above implementation process, the introduction of a role inheritance mechanism significantly simplifies the permission management process and reduces redundancy in permission allocation. By determining the top-level parent role and centrally configuring its permission set, the system can automatically pass permissions down the inheritance hierarchy, ensuring that all child roles automatically acquire the corresponding permissions without repeated configuration. This hierarchical permission inheritance method not only improves the efficiency of permission allocation but also enhances the system's flexibility and maintainability, enabling it to quickly adapt to changes in business needs.

[0072] Based on the above embodiments, after constructing the inheritance relationship between each role, in order to avoid the problem of uncontrolled permission inheritance, it is also necessary to perform cyclic inheritance detection on the inheritance relationship. For example, for a child role and its parent role, according to the inheritance relationship, starting from the parent role, recursively traverse all its parent roles. If all parent roles include the child role, output the prompt message that the inheritance relationship is incorrect.

[0073] For example, randomly select a child role 1 and its parent role 1 from the role inheritance table. Then, based on the created inheritance relationship, traverse upwards from the parent role 1 node. This can be done using a directed acyclic graph or a tree structure to find all parent roles of parent role 1, up to the top-level parent role. If any of these parent roles contain the child role 1, it indicates a circular inheritance, and the inheritance relationship can be deleted from the role inheritance table. If none of these parent roles contain the child role 1, there is no circular inheritance, and the inheritance relationship can be retained. The same method can be used to check for circular inheritance between any two parent roles and child roles to detect errors in the inheritance relationship. If an error is found, an error message is output to prompt the user to reconfigure, delete, or modify the inheritance relationship.

[0074] In the above implementation process, before determining the role inheritance relationship, a recursive traversal is used to check for circular inheritance (i.e., a child role ultimately points to itself through the inheritance chain). This allows for timely detection and alerts to errors in the inheritance relationship configuration. This mechanism effectively avoids permission calculation errors and system logic confusion caused by circular inheritance, ensuring the correctness and stability of the role inheritance relationship structure diagram.

[0075] Based on the above embodiments, when assigning permissions to users, the user's role set is obtained from the user role table, and then the permission set of each role in the user's role set is merged to obtain a merged permission set. The merged permission set is then assigned to the user as the user's permission set.

[0076] For example, you can obtain a set of all roles for a user from the user role table, then obtain the permissions for these roles from the role permission table, and merge the permissions. The merged permissions are the user's permissions, which are the user's permissions to access resources.

[0077] For example, step 1: Retrieve users from the UserRoles table. All characters ,Right now

[0078] in, This is the user role table.

[0079] Step 2: Initialize the permission set.

[0080] Initialize user permission set It is an empty set, that is .

[0081] Step 3: Iterate through the user's role set.

[0082] For each character Recursively calculate its permission set , means as follows:

[0083] in, It is a character The set of permissions.

[0084] Step 4: Calculate the permission set for the role.

[0085] Calculate the role permission set This includes direct permissions and inherited permissions. That is:

[0086] in, It is a character The set of permissions that are directly possessed. It is a character The set of parent roles.

[0087] Step 5: Recursively calculate the permission set of the parent role.

[0088] For each parent role Recursively calculate its permission set ,Right now

[0089] in, Father role The father figure.

[0090] Step 6: Merge the permission sets.

[0091] Set the permissions for each role Merge into users permission set middle.

[0092] Step 7: Return to user All permissions set .

[0093] Building upon the above embodiments, when role inheritance relationships or permission allocations change, the system can automatically reclaim redundant user permissions. Through this permission reclamation mechanism, the system can ensure the accuracy and consistency of permission allocation, preventing permission abuse or data leakage. Specifically, in response to detecting a role whose permissions need adjustment, the system updates the permission set for that role.

[0094] When the inheritance relationship between roles is modified or the permissions of a role are modified, the permissions of the role need to be updated again.

[0095] If the inheritance relationship is modified, the roles whose permissions need to be adjusted are those involved in the modification of the inheritance relationship. For example, if the inheritance relationship between role 1 and role 2 is re-added, the original inheritance relationship needs to be updated, including updating the constructed inheritance relationship structure diagram and updating the role inheritance table. Then, the permissions of role 1 and role 2 need to be recalculated according to the above method. In addition, the permissions of roles that are related to role 1 and role 2 also need to be updated, such as roles that have direct or indirect inheritance.

[0096] If the permissions of a role are modified, the permissions for that role and the roles that inherit that role will also need to be recalculated, and the permissions for the user corresponding to that role will also need to be recalculated.

[0097] When a user's role is modified, the user's permissions need to be recalculated.

[0098] For example, step 1: Identify users whose permissions need to be revoked based on the triggering conditions.

[0099]

[0100] in, It is the set of affected users. It is the set of affected roles.

[0101] Step 2: For each affected user Recalculate its permission set ,Right now

[0102] in, Calculated using a permission allocation algorithm.

[0103] Step 3: Recalculate the permission set Update the database.

[0104] Step 4: When a user accesses a resource, the system performs permission verification based on the latest set of permissions.

[0105] In the above implementation process, when a role whose permissions need to be adjusted is detected, the system can update the permission set of that role in a timely manner and automatically pass the changes down the inheritance relationship to ensure that the permissions of all related child roles are updated synchronously.

[0106] Building upon the above embodiments, changes in business requirements may also involve adjusting role permissions. For example, the dynamic adjustment module can dynamically adjust role inheritance relationships and user permissions based on business needs. That is, in response to detecting a role whose permissions need adjustment, a permission adjustment instruction is generated, and the permission set for that role is updated according to the instruction. Specifically, the permission adjustment instruction is generated as follows: A permission adjustment event is obtained, which includes the role whose permissions need adjustment; features are extracted from the permission adjustment event to obtain a structured feature vector corresponding to the event; then, through rule-based reasoning and machine learning prediction, the structured feature vector is mapped to an executable permission adjustment instruction and output. This instruction indicates the permission adjustment for the role.

[0107] Specifically, permission adjustment events can be obtained through manual input or through system monitoring, as shown in the table below:

[0108] When extracting features from permission adjustment events, Natural Language Processing (NLP) and log pattern recognition techniques are used to transform the events into structured feature vectors. Different methods are employed depending on the source of the event. (1) For manually input text: Entity relations are extracted using the Bidirectional Encoder Representations from Transformers (BERT) model, which identifies the operating subject, action type, and permission object. The specific implementation steps are as follows: Input: Natural language text S.

[0109] Processing flow: Step 1: Encode the text using a pre-trained BERT model to obtain the embedding vector for each token.

[0110] Step 2: Classify each token through a classification layer (fully connected layer) to identify the entity type.

[0111] Step 3: Use a relation classification model to identify the relationships between entities.

[0112] Output: ,in, This indicates the output of the CLS token. Represents word embedding layer, This represents the entity label in the Conditional Random Field (CRF) decoding.

[0113] (2) System monitoring logs: Regular expressions and cluster analysis are used to extract abnormal access patterns, and each abnormal pattern (i.e., a cluster) is transformed into a feature vector. The specific implementation is as follows: Input: Log entries.

[0114] Processing flow: Step 1: Use predefined regular expression templates to extract key fields (user, role, resource, operation, result, etc.).

[0115] Step 2: Convert the extracted log entries into vector representations. Each entry is represented as: (u, r, res, op, result), where u is the user, r is the role, res is the resource, op is the operation, and result is the access result.

[0116] Step 3: Cluster the log entries and use a clustering model to identify anomalous clusters.

[0117] Step 4: Determine the anomaly type based on cluster statistical characteristics (such as rejection rate, frequency, etc.).

[0118] Step 5: Generate structured feature vectors based on anomaly types and cluster statistical characteristics. .

[0119] Output: .

[0120] Then, through rule-based reasoning and machine learning prediction, the above structured feature vectors are mapped into executable permission adjustment instructions.

[0121] Given structured feature vectors and rule base structure ,in, The dimension of the feature vector. This represents the comparison operator. This represents the value of the critical point.

[0122] First, check the rule base: if a rule exists within the threshold range, output the corresponding rule. .

[0123] If the rule base is not matched, a machine learning model is used: .in, Represents a single decision tree; The cumulative function of a decision tree works by constructing multiple decision trees, each dividing the feature space into multiple regions, with each region corresponding to the distribution of an action. Finally, the action with the highest probability is selected as the voting result for the predicted action.

[0124] Output: Executable permission adjustment commands.

[0125] In the aforementioned implementation process, by introducing an intelligent permission adjustment instruction generation mechanism, the system can automatically identify the roles whose permissions need to be adjusted, and perform feature extraction and structured analysis based on permission adjustment events. Combining rule-based reasoning and machine learning models, it accurately generates executable permission adjustment instructions. This automated and intelligent approach significantly improves the efficiency and accuracy of permission adjustments, reducing the risk of human intervention and operational errors.

[0126] Based on the above embodiments, after generating the permission adjustment instruction but before making the permission adjustment, in order to quantify the risk of permission adjustment, the degree of permission change risk can be obtained. Then, based on the degree of permission change risk, it is determined whether to execute the step: update the permission set of the role according to the permission adjustment instruction, or the degree of permission change risk can be output. The degree of permission change risk can be used to provide a basis for users to make decisions on permission adjustment.

[0127] Specifically, changes in business needs will trigger permission adjustments, such as adding new functional modules or changing access rules. Based on these changes, the roles and permissions that may be affected can be identified, and then the extent to which each role and permission is affected can be determined, including the number of affected users and the sensitivity of the permissions. The following formula can be used to calculate the risk level of permission changes:

[0128] in, This represents the set of all permissions for the affected role. This indicates the user's identity, corresponding to different numerical values; This indicates the user's permission sensitivity value.

[0129] The following is a specific example to illustrate this.

[0130] Suppose a company adds a sensitive data access module, and only senior management (Manager) and finance (Finance) roles need access permissions.

[0131] First, query the UserRoles table and the Users table to find the users who belong to the Manager and Finance roles, and then count the number of these users.

[0132] The system needs to recalculate the permission sets for the Manager and Finance roles and add new access permissions.

[0133] Assume an initial set of permissions: Manager: {A, B, C}.

[0134] Finance: {D, E}.

[0135] Add a new permission: Sensitive data access permission, marked as F.

[0136] Adjusted permission set: Manager: {A, B, C, F}.

[0137] Finance: {D, E, F}.

[0138] The merged set of user permissions: For a user who belongs to both Manager and Finance, the permission set is {A, B, C, D, E, F}.

[0139] For users who belong only to the Manager, the permission set is {A, B, C, F}.

[0140] For users who belong only to Finance, the permission set is {D, E, F}.

[0141] The set of affected role permissions can be further quantified using the following formula: Assume the following user identity weights: ordinary employee (1), department manager (2), senior executive (3); permission sensitivity values: ordinary permission (1), sensitive permission (2), highly sensitive permission (3).

[0142] Formula for assessing the risk level of permission changes: Risk level of permission changes = Σ (user identity weight × permission sensitivity value).

[0143] Assuming the new permission F is a highly sensitive permission (sensitivity value 3), among the 100 affected users, 20 are senior executives (identity weight 3), 30 are department managers (identity weight 2), and 50 are ordinary employees (identity weight 1). Therefore, the risk level of the permission change = (20 × 3 × 3) + (30 × 2 × 3) + (50 × 1 × 3) = 180 + 180 + 150 = 510.

[0144] The user identity weight reflects the degree of risk associated with permission changes due to different roles or responsibilities within the organization. This weight can be determined based on factors such as the user's job level, department, and user type. For example, ordinary employees typically have limited access, so a lower weight (e.g., 1) could be assigned. Department managers, needing access to more resources, could have a weight of 2. Senior executives, who significantly impact the company's overall operations, could have a weight of 3 or higher. Similarly, the human resources department, primarily handling sensitive data such as employee information, could have a weight of 2, while the finance department, dealing with highly sensitive information like company financial data, could have a weight of 3.

[0145] The permission sensitivity value reflects the importance and sensitivity of the information or operation involved in different permissions, and can be determined based on factors such as the permission category, the sensitivity of associated data, and the scope of data impact.

[0146] For example, permission categories: read permission has relatively low sensitivity, and the sensitivity value can be set to 1; write permission has higher sensitivity, and the sensitivity value can be set to 2; delete permission has very high sensitivity, and the sensitivity value can be set to 3.

[0147] Sensitivity of related data: For example, the sensitivity value of public information can be set to 1, the sensitivity value of internal information can be set to 2, and the sensitivity value of confidential information can be set to 3.

[0148] Data impact scope: If the impact scope of personal data is small, the sensitivity value can be set to 1; the sensitivity value of departmental data can be set to 2; and the sensitivity value of company-wide data can be set to 3.

[0149] After calculating the risk level of permission changes using the above formula, the risk level can be output, allowing for a quantitative reflection of the impact of changes in business requirements on the permission system. For example, a high risk level means that changes in business requirements will have a significant impact on the permission system, potentially affecting many roles, permissions, or users. This quantitative approach helps administrators quickly assess the potential impact of changes and formulate appropriate adjustment strategies.

[0150] Suppose that in an organization, the impact score of business requirement change A is 510, while the impact score of business requirement change B is 200. This means that business requirement change A has a greater impact on the access control system, involving more roles, permissions, or users, or involving more sensitive permissions. Administrators can prioritize handling business requirement change A to ensure the smooth operation of critical business processes.

[0151] Furthermore, if the risk level of a permission change exceeds a set threshold, the step of updating the role's permission set will not be executed; conversely, if the risk level is less than or equal to the set threshold, the step of updating the role's permission set will be executed. This allows for risk assessment to determine whether to perform permission adjustments; if the risk is high, adjustments will not be made, thus avoiding the problem of high risk to the permission system due to permission adjustments.

[0152] In the above implementation process, a risk assessment mechanism for permission changes is introduced, which can intelligently determine whether to perform adjustment operations based on the risk level. For high-risk changes, the system can automatically intercept them or transfer them to a manual review process, thereby effectively avoiding security risks or business risks caused by improper permission adjustments. This proactive risk control mechanism significantly improves the security and reliability of permission management.

[0153] Based on the above embodiments, after generating the permission adjustment instruction, the permission adjustment instruction can be verified. If the verification passes, the following step is executed: updating the permission set of the role according to the permission adjustment instruction. The verification includes at least one of the following: syntax compliance verification, semantic logic verification, and security policy verification. Verification ensures the security and executability of the instruction.

[0154] First, perform syntax compliance checks using JSON Schema to rigorously verify the integrity of the command format and the validity of fields, ensuring no basic structural errors. Second, perform semantic logic checks by querying the RBAC policy library to verify the existence of the target role and permission entity, and use Tarjan's cycle detection to ensure that role inheritance relationships will not form circular inheritance after adjustment. Finally, perform security policy checks by connecting to the system's OpenPolicy Agent engine to automatically block commands that violate security principles. Commands that pass at least one or all checks are marked as executable, and the final result is output. Commands with conflicts or risks are transferred to the manual review queue, and an audit log containing specific reasons for failure is generated. In other words, if a command fails the check, it can be submitted for manual review; if it still fails the manual review, the permission adjustment will not be executed.

[0155] In the above implementation process, after generating the permission adjustment command, a multi-layered verification mechanism was added, including syntax compliance, semantic logic and security policy verification, to ensure the correctness, rationality and security of the command.

[0156] Based on the above embodiments, this solution also provides a visualization support module, which can realize information visualization, including: in response to the inheritance relationship of each role configured in the inheritance relationship interface, configuring inheritance relationship between each role, and / or, displaying the permission set configured for each role in the permission display interface, and / or, in response to the permission adjustment instruction triggered in the permission adjustment interface, adjusting the permissions of the relevant roles.

[0157] The visualization support module provides a graphical interface for the visual management and monitoring of roles, permissions, and user relationships, helping administrators to manage and monitor permissions more efficiently. Specifically, it may include the following functions: (1) Visualization of inheritance relationships.

[0158] The inheritance relationship visualization feature displays the inheritance relationships between roles in the form of directed acyclic graphs or tree diagrams, helping administrators intuitively understand the role hierarchy. Administrators can dynamically adjust role inheritance relationships on the inheritance relationship configuration interface by dragging and dropping, and the system will update the role inheritance data in real time and synchronize it to the permission allocation module. This feature supports the display of multi-level role inheritance, clearly presenting complex role relationships and reducing the complexity of role management.

[0159] (2) Visualization of permission allocation.

[0160] The permission allocation visualization feature displays permission distribution in bar chart format, supporting filtering and statistics by role, user, or permission type. Administrators can see the permission sets configured for each role in the permission display interface, enabling them to quickly understand the permission distribution for each role or user and identify redundancies or deficiencies in permission allocation. This feature supports exporting permission allocation reports, facilitating permission auditing and optimization by administrators.

[0161] (3) Visualization of permission adjustment.

[0162] The permission adjustment visualization feature provides a graphical interface, the permission adjustment interface, which allows administrators to dynamically adjust permission assignments through drag-and-drop methods. Administrators can drag and drop permissions from one role to another, or adjust permissions for multiple users in batches. This feature simplifies the permission adjustment process, improves the efficiency of permission management, and ensures the accuracy and consistency of permission adjustments.

[0163] In the above implementation process, by providing an inheritance relationship configuration interface, a permission display interface, and a permission adjustment interface, visualization and interactive operation of permission management are achieved. Administrators can intuitively configure role inheritance relationships, view permission allocation status, and quickly trigger permission adjustment commands through the interface, significantly improving the convenience and operational efficiency of permission management.

[0164] In conjunction with the above embodiments, please refer to Figure 3 , Figure 3 A flowchart of an access control method provided in this application embodiment, the method including the following steps: Step S210: Obtain the set of user permissions for the accessing user.

[0165] The user access permission set is the permission set of the role corresponding to that user, and the role permission set is obtained through the permission management method described above. For example, the role corresponding to the access user can be found in the user role table, and then the permission set of these roles can be obtained through the role permission table, thus obtaining the access user's permission set.

[0166] Step S220: Obtain the set of resource permissions corresponding to the resource that the user wants to access.

[0167] The set of resource permissions for a resource can be obtained from the resource permission table mentioned above.

[0168] Step S230: If the user permission set includes the resource permission set, run the access user to access the resource.

[0169] This checks whether a user has permission to access specific resources to ensure the security and compliance of resource access. Specifically: Retrieve resources from the ResourcePermissions table. Required permission set ,Right now

[0170] Retrieve user from user permission table permission set .

[0171] The set of permissions required to inspect resources Is it a set of user permissions? A subset of, i.e.

[0172] Returns a permission verification result of True or False.

[0173] If the permission verification result is True, the user is allowed to access the resource; if it is False, the user is denied access to the resource.

[0174] In the above implementation process, fine-grained access control is achieved by precisely matching the user's permission set with the resource's required permission set. The user's permission set is automatically calculated and updated in real time based on a role inheritance mechanism, ensuring the accuracy and timeliness of permission information; while the resource permission set explicitly defines the permission requirements for accessing the resource. After comparison and verification, the system only allows access when the user has all the required permissions, effectively preventing unauthorized access and permission abuse, and significantly improving the system's security and reliability.

[0175] Based on the above embodiments, in order to ensure the correct use of user permissions, abnormal use of user permissions can also be monitored, such as obtaining the permission usage status of each user, then identifying abnormal permissions based on the permission usage status, and outputting alarm information for abnormal permissions.

[0176] First, user operation logs can be collected in the system. These logs can include information such as the operations performed by the user, the permissions used, the timestamps of the operations, the resources accessed, and the results of the operations.

[0177] Then, based on the collected operation logs, the frequency and patterns of each user's use of various permissions can be statistically analyzed. This can be achieved by periodically analyzing the operation logs.

[0178] A set of rules can be defined to identify abnormal permission usage behavior. These rules can be based on permission usage frequency, time pattern, resource type, etc.

[0179] For example, abnormal frequency of permission usage: If a user uses a specific permission much more frequently than average, it may indicate abnormal permissions. Abnormal timing of permission usage: If a user frequently uses highly sensitive permissions outside of working hours, it may indicate abnormal permissions. Permission mismatch with resources: If a user frequently accesses resources unrelated to their role, it may indicate abnormal permissions.

[0180] When identifying abnormal user permissions, defined rules can be used to detect unusual permission usage. Methods such as statistical analysis and machine learning models can be employed.

[0181] For example, you can statistically analyze the frequency and standard deviation of each user's permissions. If the frequency of a permission exceeds three times the standard deviation of the average, it is marked as an anomalous permission. Alternatively, you can train a classification model using historical data to identify anomalous permissions.

[0182] When abnormal permissions are detected, an alarm message can be generated and sent via email, SMS, or system notification to ensure that administrators can handle abnormal situations in a timely manner and to ensure the security and compliance of the system.

[0183] In the above implementation process, by acquiring and analyzing users' permission usage in real time, abnormal permission behaviors (such as permission abuse, unauthorized access, or abnormal usage patterns) can be automatically identified, and alarm information can be promptly output to notify the administrator. This proactive monitoring mechanism significantly improves the system's ability to perceive potential security threats, helps to quickly detect and handle permission abuse or internal threats, and prevents data leakage and loss of control over permissions.

[0184] Please refer to Figure 4 , Figure 4 This application provides a structural block diagram of a permission management device 300 based on the RBAC model, which can be a module, program segment, or code on an electronic device. It should be understood that this permission management device 300 is similar to the one described above. Figure 2 The method implementation corresponds to this and can be executed. Figure 2 The various steps involved in the method embodiment, and the specific functions of the permission management device 300, can be found in the description above. To avoid repetition, detailed descriptions are omitted here.

[0185] Optionally, the access control device 300 includes: The role determination module 310 is used to determine the top-level parent role in the role set according to the inheritance relationship between the configured roles, wherein other roles in the role set, excluding the top-level parent role, have one or more parent roles. The permission acquisition module 320 is used to acquire the permission set configured for the top-level parent role; The permission inheritance module 330 is used to inherit the permission set of the top-level parent role to the lower-level roles sequentially along the inheritance relationship structure graph constructed by the inheritance relationship, until the bottom-level child role is reached. In the inheritance relationship structure graph, the nodes represent roles and the edges represent inheritance relationships. The permission set of the bottom-level child role is inherited from the permission sets of all its parent roles. The permission set of a role is used to control the permissions of the user corresponding to that role to access the corresponding resources.

[0186] Optionally, the device 300 further includes: The inheritance relationship detection module is used to recursively traverse all parent roles of a child role and its parent role according to the inheritance relationship, starting from the parent role; if the child role is included in all parent roles, the module outputs a prompt message indicating that the inheritance relationship is incorrect.

[0187] Optionally, the inheritance relationship structure diagram is a directed acyclic graph or a tree structure diagram.

[0188] Optionally, the device 300 further includes: The permission adjustment module is used to update the permission set of a role when a role whose permissions need to be adjusted is detected.

[0189] Optionally, the permission adjustment module is configured to generate a permission adjustment instruction in response to detecting a role whose permissions need to be adjusted; and update the permission set of the role according to the permission adjustment instruction. The permission adjustment command is generated in the following way: Get a permission adjustment event, wherein the permission adjustment event includes the role whose permissions need to be adjusted; Feature extraction is performed on the permission adjustment event to obtain the structured feature vector corresponding to the permission adjustment event; Through rule-based reasoning and machine learning prediction, the structured feature vector is mapped into executable permission adjustment instructions and output, which are used to indicate the adjustment of a role's permissions.

[0190] Optionally, the permission adjustment module is further configured to obtain the degree of risk of permission change in the permission adjustment; and determine whether to execute the step of updating the permission set of the role according to the permission adjustment instruction based on the degree of risk of permission change.

[0191] Optionally, the permission adjustment module is further configured to verify the permission adjustment instruction. If the verification passes, the following step is executed: updating the permission set of the role according to the permission adjustment instruction. The verification includes at least one of the following: syntax compliance verification, semantic logic verification, and security policy verification.

[0192] Optionally, the access control device 300 further includes: The visualization module is used to configure inheritance relationships between roles in response to the inheritance relationship configuration interface; and / or to display the permission set configured for each role in the permission display interface; and / or to adjust the permissions of relevant roles in response to permission adjustment commands triggered in the permission adjustment interface.

[0193] Please refer to Figure 5 , Figure 5 This is a structural block diagram of an access control device 400 provided in an embodiment of this application. The access control device 400 may be a module, program segment, or code on an electronic device. It should be understood that this access control device 400 is similar to the one described above. Figure 3 The method implementation corresponds to this and can be executed. Figure 3 The specific functions of the access control device 400 involved in the various steps of the method embodiment can be found in the description above. To avoid repetition, detailed descriptions are omitted here.

[0194] Optionally, the access control device 400 includes: User permission acquisition module 410 is used to acquire the user permission set of the accessing user. The user permission set of the accessing user is the permission set of the role corresponding to the accessing user. The permission set of the role is obtained through the above-mentioned permission management method. The resource permission acquisition module 420 is used to acquire the set of resource permissions corresponding to the resource that the accessing user wants to access; The access control module 430 is used to allow the accessing user to access the resource when the user permission set includes the resource permission set.

[0195] Optionally, the access control device 400 further includes: The anomaly detection module is used to obtain the permission usage information of each user; identify abnormal permissions based on the permission usage information; and output alarm information for the abnormal permissions.

[0196] It should be noted that those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0197] Please refer to Figure 6 , Figure 6This application provides a schematic diagram of the structure of an electronic device for executing a permission management method or access control method based on the RBAC model. The electronic device may include: at least one processor 510, such as a CPU; at least one communication interface 520; at least one memory 530; and at least one communication bus 540. The communication bus 540 is used to establish communication between these components. In this embodiment, the communication interface 520 is used for signaling or data communication with other node devices. The memory 530 may be a high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 530 may also be at least one storage device located remotely from the aforementioned processor. The memory 530 stores computer-readable instructions, which, when executed by the processor 510, cause the electronic device to perform the aforementioned method process.

[0198] Understandable. Figure 6 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown. Figure 6 The components shown can be implemented using hardware, software, or a combination thereof.

[0199] This application provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it performs the method process as executed by the electronic device in the above method embodiments.

[0200] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments, such as including: Based on the inheritance relationship between the configured roles, determine the top-level parent role in the role set, wherein other roles in the role set, excluding the top-level parent role, have one or more parent roles; Retrieve the set of permissions configured for the topmost parent role; Based on the inheritance relationship structure diagram constructed according to the inheritance relationship, the permission set of the top-level parent role is inherited to the lower-level roles in sequence along the inheritance relationship until the bottom-level child role is reached. In the inheritance relationship structure diagram, the nodes represent roles and the edges represent inheritance relationships. The permission set of the bottom-level child role is inherited from the permission sets of all its parent roles. The permission set of a role is used to control the permissions of the user corresponding to that role to access the corresponding resources.

[0201] In summary, this application provides a permission management method, access control method, apparatus, and device based on the RBAC model. This method significantly simplifies the permission management process and reduces redundancy in permission allocation by introducing a role inheritance mechanism. By determining the top-level parent role and centrally configuring its permission set, the system can automatically pass permissions down the inheritance hierarchy, ensuring that all child roles automatically acquire the corresponding permissions without repeated configuration. This hierarchical permission inheritance approach not only improves the efficiency of permission allocation but also enhances the system's flexibility and maintainability, enabling rapid adaptation to changes in business needs.

[0202] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0203] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0204] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0205] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0206] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A permission management method based on the RBAC model, characterized in that, The method includes: Based on the inheritance relationship between the configured roles, determine the top-level parent role in the role set, wherein each role in the role set other than the top-level parent role has one or more parent roles; Retrieve the set of permissions configured for the topmost parent role; Based on the inheritance relationship structure diagram constructed according to the inheritance relationship, the permission set of the top-level parent role is inherited to the lower-level roles in sequence along the inheritance relationship until the bottom-level child role is reached. In the inheritance relationship structure diagram, the nodes represent roles and the edges represent inheritance relationships. The permission set of the bottom-level child role is inherited from the permission sets of all its parent roles. The permission set of a role is used to control the permissions of the user corresponding to that role to access the corresponding resources.

2. The method according to claim 1, characterized in that, Before determining the top-level parent role in the role set based on the inheritance relationship between the configured roles, the process also includes: For a child role and its parent role, according to the inheritance relationship, starting from the parent role, recursively traverse all its parent roles; If the child role is included in all parent roles, an error message indicating an incorrect inheritance relationship will be output.

3. The method according to claim 1, characterized in that, The inheritance relationship structure diagram is a directed acyclic graph or a tree structure diagram.

4. The method according to any one of claims 1-3, characterized in that, The inheritance structure diagram constructed based on the inheritance relationship, which inherits the permission set of the top-level parent role sequentially to the lower-level roles along the inheritance relationship until the bottom-level child role is reached, further includes: In response to the detection of a role whose permissions need to be adjusted, update the permission set for that role.

5. The method according to claim 4, characterized in that, The response to detecting a role whose permissions need to be adjusted, updating the permission set for that role, includes: In response to the detection of a role whose permissions need to be adjusted, a permission adjustment command is generated; Update the permission set for this role according to the permission adjustment instruction; The permission adjustment command is generated in the following way: Get a permission adjustment event, wherein the permission adjustment event includes the role whose permissions need to be adjusted; Feature extraction is performed on the permission adjustment event to obtain the structured feature vector corresponding to the permission adjustment event; Through rule-based reasoning and machine learning prediction, the structured feature vector is mapped into executable permission adjustment instructions and output, which are used to indicate the adjustment of a role's permissions.

6. The method according to claim 5, characterized in that, After generating the permission adjustment instruction, and before updating the permission set of the role according to the permission adjustment instruction, the method further includes: The degree of risk associated with changes to permissions that allow for adjustment; Based on the risk level of the permission change, determine whether to execute the following step: update the permission set for the role according to the permission adjustment instruction.

7. The method according to claim 5, characterized in that, After generating a permission adjustment instruction in response to detecting a role whose permissions need to be adjusted, the method further includes: The permission adjustment instruction is verified. If the verification passes, the following steps are executed: the permission set of the role is updated according to the permission adjustment instruction. The verification includes at least one of the following: syntax compliance verification, semantic logic verification, and security policy verification.

8. The method according to claim 1, characterized in that, The method further includes: In response to the inheritance relationships configured for each role in the inheritance relationship configuration interface, configure the inheritance relationships between each role; And / or, display the set of permissions configured for each role on the permission display interface; And / or, in response to a permission adjustment command triggered in the permission adjustment interface, adjust the permissions of the relevant role.

9. An access control method, characterized in that, The method includes: Obtain the user permission set of the accessing user, wherein the user permission set of the accessing user is the permission set of the role corresponding to the accessing user, and the permission set of the role is obtained by the method described in any one of claims 1-8; Obtain the set of resource permissions corresponding to the resource that the accessing user wants to access; If the user permission set includes the resource permission set, the accessing user is allowed to access the resource.

10. The method according to claim 9, characterized in that, The method further includes: Obtain the permission usage information of each user; Identify abnormal permissions based on the usage of those permissions; Output alarm information for the abnormal permissions.

11. A permission management device based on the RBAC model, characterized in that, The device includes: The role determination module is used to determine the top-level parent role in the role set based on the inheritance relationship between the configured roles, wherein other roles in the role set, excluding the top-level parent role, have one or more parent roles; The permission acquisition module is used to acquire the set of permissions configured for the top-level parent role; The permission inheritance module is used to inherit the permission set of the top-level parent role to the lower-level roles sequentially along the inheritance relationship structure graph constructed by the inheritance relationship, until the bottom-level child role is reached. In the inheritance relationship structure graph, the nodes represent roles and the edges represent inheritance relationships. The permission set of the bottom-level child role is inherited from the permission sets of all its parent roles. The permission set of a role is used to control the permissions of the user corresponding to that role to access the corresponding resources.

12. An electronic device, characterized in that, It includes a processor and a memory, the memory storing computer-readable instructions that, when executed by the processor, perform the method as described in any one of claims 1-10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it performs the method as described in any one of claims 1-10.

14. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-10.

Images