Multi-layer architecture multi-resource permission dynamic adaptation and isolation unloading method

Abstract

The invention provides a multi-layer architecture multi-resource permission dynamic adaptation and isolated unloading method, which comprises the following steps: traversing all nodes and edges by adopting a graph traversal algorithm according to an obtained permission graph, determining a dependency chain among permission items, and obtaining a dependency subset, in which the dependency chain reflects a shared dimension of an attribute tag; for the obtained classified target permission group, obtaining the timeliness attribute and granting time of each permission item in the group, determining permission item subgroups with expired or out-of-range timeliness, and obtaining expired subgroups; according to the obtained pure unloading set, corresponding nodes and edges are deleted from the permission graph, it is determined that deletion operation covers all related hierarchies, and an updated permission graph is obtained; and for the obtained updated permission graph, traversing residual nodes to verify that no residual trace exists, judging that a verification result meets a security cleaning requirement, and obtaining a finally confirmed unloading state.

Description

A method for dynamic adaptation and isolation unloading of multi-resource permissions in a multi-layer architecture Technical Field

[0001] This invention relates to the field of information technology, and in particular to a method for dynamic adaptation and isolation unloading of multi-resource permissions in a multi-layer architecture. Background Technology

[0002] The custom terms used in this specification have the following specific meanings: 1. Multi-layer architecture: refers to the four permission control layers in a multi-resource system, divided from bottom to top: data layer, platform layer, application layer, and business layer. The data layer corresponds to access permissions for resource storage media; the platform layer corresponds to access permissions for resource scheduling interfaces; the application layer corresponds to operation permissions for functional modules; and the business layer corresponds to process permissions for business scenarios. 2. Dynamic adaptation: refers to the system's ability to automatically update the nodes, edges, and dependencies of the permission graph based on changes in permission item attribute tags, changes in business scenarios, and adjustments to the system architecture, and to synchronously adjust the filtering conditions and execution scope for permission unloading. The following are the processing steps: 3. Isolation and Unloading: This refers to logically isolating the permission item to be uninstalled from the legitimate permission items required for normal system operation before executing the permission uninstallation, blocking the access link of the permission item to be uninstalled, and then performing the deletion operation of the permission node and associated edge to avoid the uninstallation process affecting business continuity; 4. Permission Items with Insufficient Granularity: This refers to permission items whose scope attributes are not clearly defined to the smallest manageable resource unit, or whose operation type is not clearly defined to the smallest executable action, resulting in the inability to perform differentiated control over the permission item. The judgment criteria are: the scope of the operation object of the permission item is larger than the smallest resource unit corresponding to the actual business needs, or the permission... 5. Connection Strength: Refers to the degree of dependency between permission nodes, quantified as the percentage of calls triggered by upstream nodes in the effective call counts of downstream nodes in the dependency path, with a value range of 0-1; 6. Preset Threshold: Refers to the critical value of connection strength used to determine strong dependencies, with a fixed value of 0.8; 7. Specific Unloading Conditions: Refers to the set of rules used to determine whether a permission item is included in the scope of unloading, including: the permission item has been marked as an invalid node, the permission item has insufficient granularity and no corresponding active business call record, and the applicable scope of the permission item exceeds the preset business boundary. 8. Filtering Criteria: These are the pre-defined rules used to filter permission items to be uninstalled, including: the expiration period of the permission item is ≥30 days, the permission item does not belong to the preset business-related permission whitelist, and the permission item has no valid business call records in the past 90 days; 9. Hierarchical Confirmation Mechanism: This refers to the verification mechanism that checks whether all associated nodes and edges corresponding to the permission item to be uninstalled have been included in the deletion scope, in the order of data layer, platform layer, application layer, and business layer from top to bottom; 10. Security Cleanup Threshold: This refers to the critical value used to determine whether permission uninstallation meets security requirements, specifically, the ratio of the number of abnormal nodes to the total number of nodes in the updated permission graph is ≤0.1%.

[0003] In this specification, the terms "associated edge," "associated border line," and "edge" all refer to the graphical elements in the permission graph that represent the attribute relationships between permission items, and have the same meaning; the terms "expired subgroup," "permission item subgroup," and "set of expired permission subgroups" all refer to the set of permission items whose validity period has expired or exceeded the scope, and have the same meaning; the terms "permission graph structure," "graphical structure," and "graphical framework" all refer to the graphical model structure built based on permission items, and have the same meaning.

[0004] In the complex field of multi-resource access control, ensuring that permissions can be securely and thoroughly cleared is a key aspect of maintaining system security, which directly relates to whether unauthorized access and data leakage risks can be effectively prevented.

[0005] Current common methods for uninstalling permissions often focus on overall revocation, such as directly removing all associated permissions of a user. Although this method is simple to operate, it is difficult to adapt to the dynamic and fine-grained permission management needs of modern business.

[0006] Its limitations lie not only in the static nature of the method, but also in the lack of detailed characterization and correlation analysis of the elements constituting permissions. This makes it impossible to accurately distinguish and locate the uninstallation operation, which may accidentally infringe on permissions necessary for normal business operations during the cleanup process, causing service interruption.

[0007] This limitation leads to two closely related core technical challenges.

[0008] The primary challenge lies in the insufficient granularity of permission descriptions, meaning that permission items themselves lack sufficiently rich attribute tags to identify their source, scope of application, and validity period.

[0009] Because permissions are not systematically labeled with key dimensions such as resource type and grant time, the system is unable to effectively filter during uninstallation.

[0010] This factor directly leads to the second challenge: the lack of selectivity in the uninstallation process.

[0011] When it is necessary to target specific scenarios, such as revoking read permissions for only a certain type of resource or clearing temporary authorizations within a specific time period, the system is forced to adopt a "one-size-fits-all" approach to clear all permissions because it cannot identify and separate these specific subsets mixed in with a large number of permissions, or it falls into an operational dilemma.

[0012] Therefore, in a multi-resource, multi-level system architecture, how to ensure that all relevant permission traces are completely cleared to meet security requirements when performing permission uninstallation, while also precisely controlling the scope of the cleanup to avoid affecting unrelated legitimate permissions and thus ensuring business continuity, has become a key issue in permission lifecycle management.

[0013] In existing publicly available technologies, patent document CN112541070A discloses a permission cleanup method based on a permission graph. This method primarily identifies redundant permissions through the permission graph, but it does not address the issue of insufficient permission granularity or establish a multi-level uninstallation and coverage verification mechanism. Therefore, it cannot solve the problem of incomplete permission uninstallation and residual permissions in multi-layered architectures. Patent document CN114860901A discloses an automatic recycling method for expired permissions, which only reclaims permissions based on expiration time and does not consider the dependencies between permissions. This can easily lead to the accidental removal of legitimate permissions, causing business interruptions, and it also cannot achieve fine-grained selective uninstallation. To address the shortcomings of the aforementioned existing technologies, this invention proposes a full-process dynamic permission adaptation and isolated uninstallation scheme. Summary of the Invention

[0014] This invention provides a method for dynamic adaptation and isolation unloading of multi-resource permissions in a multi-layered architecture. The method mainly includes: obtaining a set of attribute tags for all permission items from a multi-resource system, including source, scope, and validity period, using a pre-established permission graph model, to obtain a permission graph where each node represents a permission item and edges represent attribute relationships; traversing all nodes and edges using a graph traversal algorithm to determine the dependency chains between permission items, obtaining a dependency subset, where the dependency chains reflect the shared dimension of attribute tags; if there are permission items with insufficient granularity in the obtained dependency subset, classifying the subset using a decision tree algorithm, determining which permission items in the classification results match specific unloading conditions, and obtaining the classified target permission item. Grouping; for the obtained target permission groups after classification, obtain the validity period attribute and grant time of each permission item in the group, identify the permission item subgroups whose validity period has expired or exceeded the scope, and obtain the expired subgroups; through the obtained expired subgroups, use filtering conditions to perform association analysis on the permission items in the subgroups, and determine whether the analysis results contain irrelevant legal permissions, to obtain a clean uninstallation set, in which the clean uninstallation set excludes falsely affected items; based on the obtained clean uninstallation set, delete the corresponding nodes and edges from the permission graph, determine that the deletion operation has covered all relevant levels, and obtain the updated permission graph; for the obtained updated permission graph, traverse the remaining nodes to verify that there are no residual traces, determine that the verification result meets the security cleanup requirements, and obtain the final confirmed uninstallation status.

[0015] Furthermore, before obtaining the attribute tag set of all permission items from the multi-resource system through the pre-established permission graph model, a permission dynamic adaptation preprocessing step is also included: real-time monitoring of attribute tag changes, business scenario changes, and system architecture adjustment information of permission items in the multi-resource system; when change information is detected, the corresponding nodes, associated edges, and dependencies of the permission graph are automatically updated synchronously, and the adaptation parameters of the uninstallation conditions and filtering conditions are adjusted synchronously to complete the dynamic adaptation of permissions.

[0016] Furthermore, before deleting the corresponding nodes and edges from the permission graph based on the obtained clean unload set, a permission isolation preprocessing step is also included: based on the clean unload set, all nodes and associated edges corresponding to the permission item to be uninstalled are locked; all access links of the permission item to be uninstalled are blocked, and the permission item to be uninstalled is logically isolated from the legal permission items that are running normally in the system, generating an isolation execution log; after verifying that the isolation status is correct, the deletion operation of nodes and edges is then performed.

[0017] Furthermore, the method employs a preset rule parser to transform the collected attribute tags into structured data, obtaining a set of permission item attributes. Specifically, this includes: the rule parser having built-in standardized mapping rules for three types of tags: source domain, scope domain, and time domain; the rule parser reading the collected unstructured attribute tag text and extracting the core fields of the three types of tags through keyword matching; standardizing and converting the extracted core fields according to a preset JSON key-value pair format to generate a structured set of permission item attributes; and marking tags that fail to convert as exceptions and generating tag exception logs.

[0018] Furthermore, the determination that if the connection strength between nodes in a certain path is higher than a preset threshold, it is classified as a strong dependency relationship. Specifically, this includes: counting the total number of effective calls to downstream nodes in the dependent path and the number of effective calls triggered by upstream nodes within a preset statistical period; calculating the ratio of the number of calls triggered by upstream nodes to the total number of calls to downstream nodes to obtain the connection strength between nodes in the path; if the connection strength is ≥ the preset threshold of 0.8, then the nodes in the path are determined to be in a strong dependency relationship.

[0019] Furthermore, the step of analyzing the candidate permission item set according to the association rule algorithm and generating association rules between permission items specifically includes: using the Apriori association rule algorithm, setting the minimum support to 0.5 and the minimum confidence to 0.7; scanning the candidate permission item set, counting the frequency of occurrence of permission items, and generating frequent itemsets that meet the minimum support; generating association rules between permission items based on the frequent itemsets, and filtering out strong association rules that meet the minimum confidence.

[0020] Furthermore, the hierarchical confirmation mechanism traverses the initially adjusted graphical structure to determine whether there are any uncovered associated levels. Specifically, this includes: traversing the initially adjusted graphical structure layer by layer in the order of business layer, application layer, platform layer, and data layer from top to bottom; verifying whether all nodes and edges in each layer that are associated with permission items in the clean uninstallation set have been deleted; if there are still undeleted associated nodes or edges in a certain level, it is determined that there are uncovered associated levels.

[0021] The technical solution provided by this invention can include the following beneficial effects: This invention discloses a multi-layered architecture method for dynamic adaptation and isolation unloading of multi-resource permissions. Addressing the dynamic, complex, and security issues in permission management within multi-resource systems, it proposes a comprehensive solution based on a permission graph model. This invention constructs a permission graph, combining graph traversal algorithms and decision tree classification to accurately identify dependencies and insufficient granularity between permission items. It then classifies and analyzes the timeliness of permission items, filtering out expired or out-of-scope permission subgroups. Irrelevant and legitimate permissions are removed through association analysis, forming a clean unloading set. Finally, the permission graph is updated, and the cleanup effect is verified. This process achieves dynamic adaptation and isolation of permissions. The core lies in ensuring the accuracy and security of permission unloading through multi-level analysis and verification, avoiding accidental damage to legitimate permissions, and ensuring no residual risks in the system. This invention effectively improves the granularity of permission management in multi-resource environments, ensuring the security and stability of the system.

[0022] The beneficial effects of this invention are also reflected in the following aspects: by constructing a permission graph with three-dimensional attribute tags and analyzing dependency chains, the granularity of permission control is refined to the smallest resource unit of a single permission item, and the permission identification accuracy is improved by more than 90% compared with traditional solutions; by using decision tree classification and association rule analysis, accurate screening of permission uninstallation is achieved, and the false positive rate of legitimate permissions is reduced to below 0.1%; by using multi-level coverage verification and residual trace verification, the residual rate after permission uninstallation is reduced to below 0.05%; at the same time, by using isolation uninstallation and dynamic adaptation mechanisms, zero business interruption is achieved during the permission uninstallation process, which fully adapts to the dynamic permission management needs under complex multi-layer architectures. Attached Figure Description

[0023] Figure 1 is a flowchart of the permission dynamic adaptation and isolation uninstallation method of the present invention.

[0024] Figure 2 is a schematic diagram of the permission graph model structure of the present invention.

[0025] Figure 3 is a schematic diagram of the multi-layered architecture permission control hierarchy of the present invention.

[0026] Figure 4 is a clustering diagram of the permission dependency network and sharing dimension of the present invention.

[0027] Figure 5 is a multi-level filtering flow diagram of the permission items in this invention.

[0028] Figure 6 is a diagram of the permission control deployment of the enterprise hybrid cloud data center of this invention.

[0029] Figure 7 is a comparison chart of the accuracy of permission recognition in this invention.

[0030] Figure 8 is a distribution chart of the error rate of legitimate rights in this invention.

[0031] Figure 9 is a comprehensive comparison chart of the permission residual rate and uninstallation coverage rate of this invention. Detailed Implementation

[0032] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] The multi-layer architecture described in this invention is uniformly divided into four layers: business layer, application layer, platform layer, and data layer. All permission items correspond to at least one of the above layers. The general implementation method of dynamic adaptation and isolated uninstallation is as follows: 1. General implementation method of dynamic adaptation: The system has a built-in real-time monitoring module that continuously scans the permission configuration interface, business process engine, and architecture management module of the multi-resource system at a cycle of 5 minutes, collecting relevant information on permission item attribute label changes, business scenario start-up and shutdown, and system architecture adjustments. When change information is detected, the system automatically triggers the permission graph update process, adding / deleting corresponding permission nodes, adjusting the dependency relationships of related edges, and updating the partitioning results of dependency subsets. At the same time, based on the changed business scenario, the system automatically adjusts the adaptation parameters in the uninstallation conditions and filtering conditions to ensure... 1. The permission-preserving uninstallation process is matched with the current system status and business requirements; 2. General implementation method of isolation uninstallation: After obtaining the clean uninstallation set and before executing the node deletion operation, the system first starts the isolation process: Based on the unique identifier of the permission item in the clean uninstallation set, all access entries of the corresponding permission item are locked in the system access control list to block its call chain; At the same time, an isolation mark is added to the node to be uninstalled in the permission graph, and it is logically partitioned with the legitimate permission nodes of normal business to ensure that the permission to be uninstalled cannot be called during the isolation period, and the isolation operation does not affect the normal operation of legitimate permissions; After the isolation operation is completed, the system generates an isolation execution log, which includes information such as isolation time, isolation permission item, and isolation status. After verifying that the isolation status is correct, the subsequent node and edge deletion operations are then executed.

[0034] The isolation operation manifests in different physical forms in a multi-layered architecture: at the database layer, the system achieves data isolation by modifying the database view or temporarily revoking the schema access permissions of a specific service account; at the application logic layer, the system uses aspect-oriented programming (AOP) or middleware interceptors to dynamically truncate API call requests pointing to the resource to be unloaded; at the system resource layer, it blocks residual execution paths from the system call level by updating the operating system's access control list (ACL) or file system permission bits, ensuring that the isolation operation generates secure linkage across layers.

[0035] As shown in Figure 1, the permission dynamic adaptation and isolation unloading method provided by the present invention includes the following steps: First, dynamic adaptation preprocessing is performed to monitor permission changes in real time and automatically update the permission graph; Step S101: Using a pre-established permission graph model, the attribute tag set (source, scope, validity) of all permission items is obtained from the multi-resource system to obtain the permission graph; Step S102: Based on the permission graph, a graph traversal algorithm is used to traverse all nodes and edges to determine the dependency chains between permission items and obtain the dependency subset; Step S103: It is determined whether there are permission items with insufficient granularity in the dependency subset. If so, the subset is classified using a decision tree algorithm to obtain the target permission group; Step S104: ... Step S104: For the target permission group, obtain the validity period attribute and grant time, identify expired or out-of-scope permission item subgroups, and obtain the expired subgroups; Step S105: Through the expired subgroups, perform association analysis using filtering conditions to determine whether they contain irrelevant legal permissions, and obtain a clean uninstallation set; then perform isolation preprocessing, lock the permission items to be uninstalled, block access links, and perform logical isolation; Step S106: Based on the clean uninstallation set, delete the corresponding nodes and edges from the permission graph, determine that all relevant levels are covered, and obtain the updated permission graph; Step S107: Traverse the remaining nodes to verify that there are no residual traces, determine that the security cleanup requirements are met, and obtain the final confirmed uninstallation status.

[0036] Example 1: Dynamic Permission Cleanup System under Enterprise Hybrid Cloud Architecture. Suppose a large group has multiple resource domains such as finance, R&D, and human resources (HR). When a project ends or an employee is transferred, it is necessary to accurately uninstall the relevant permissions to prevent security risks caused by permission redundancy.

[0037] In this embodiment, the system manages permissions according to a four-layer architecture of business layer, application layer, platform layer and data layer, and performs dynamic adaptation and isolation preprocessing operations synchronously throughout the permission cleanup process.

[0038] 1. Construction and initialization of the permission graph model (corresponding to S101) The system first collects permission data from the interfaces of each subsystem and constructs the permission graph model.

[0039] Nodes: Each specific permission operation is defined as a node. For example, "View financial statements" is one node, and "Modify code repository" is another node.

[0040] Attribute tags: Each node includes source, scope, and expiration tags. For example, permission A has a source of "financial system", a scope of "project group A only", and an expiration date of "expiring at the end of 2025".

[0041] Edges: Edges represent logical dependencies between attributes. If "modify code" permission requires "login server" permission, then an edge is established between the two.

[0042] Failure handling: If the system detects that the current time has exceeded the expiration date, it will mark the node as an "expired node".

[0043] 2. Graph Traversal Algorithm and Dependency Chain Analysis (corresponding to S102): By performing a depth-first search (DFS) on the permission graph, the deep relationships between permissions are clarified.

[0044] Dependency Chain: The complete path that the system traverses from "Employee A → R&D Department → P001 Project Team → Production Environment Access Rights" is the dependency chain.

[0045] Shared Dimension: Analysis revealed that multiple permission nodes (such as code submission, log viewing, and environment deployment) all contained a common tag "Project Number: P001", which is their shared dimension.

[0046] Dependency Subset: Based on the shared dimension, the system clusters these permissions that serve the same business objective and divides them into "P001 Project Permission Subset".

[0047] 3. Granularity evaluation and decision tree classification (corresponding to S103) optimizes permissions with ambiguous descriptions within subsets.

[0048] Insufficient Granularity: If a permission is defined as "access all databases", but the actual requirement is only "access the financial database", then it is considered insufficient granularity.

[0049] Decision tree algorithm: The system constructs a decision tree based on features such as operation type and resource level, and automatically divides permissions into multiple categories such as "high-risk write permission" and "low-risk read permission".

[0050] Target permission group: Filter out permission categories that match specific uninstallation conditions, and focus them on subsequent cleanup.

[0051] 4. Association analysis and generation of clean unload set (corresponding to S105) To prevent "false positives" to normal business operations, accurate identification is required.

[0052] Expired Subgroup: Extracts permission items from the target group that have expired or been granted for too long.

[0053] Association rule analysis: Algorithms such as Apriori are used to analyze the symbiotic relationships between permissions. For example, it was found that "file edit permission" often appears together with "database query permission".

[0054] Irrelevant Legal Permissions: If an item such as "printer usage permission" is mixed into the association rule, even though it may be in the subgroup, it is legal in business logic and should not be uninstalled. In this case, it is judged as an "accidental item" and removed.

[0055] Clean uninstall set: The final generated set contains only expired permissions that actually need to be removed without any false positives.

[0056] 4.1 Permission Isolation Preprocessing (corresponding to Isolation Unloading Steps) After generating the clean unloading set, the system immediately performs permission isolation operations: First, it locks all nodes and associated edges corresponding to permission items within the clean unloading set, blocks all call links for these permission items in the group access control list, and prohibits any account from accessing the corresponding resources through these permission items; at the same time, it adds isolation markers to the nodes to be uninstalled in the permission graph, logically partitions them with the legitimate permission nodes of the group's normal business, and ensures that the isolation operation will not affect the normal operation of core businesses such as the financial system and R&D management system; after the isolation operation is completed, the system generates an isolation execution log, which is verified by the administrator or automatically by the system before proceeding to the subsequent permission graph update steps.

[0057] 5. Permission graph update and hierarchy coverage verification (corresponding to S106) Deletion operation: The system removes the node corresponding to the clean unloaded set and its associated edge from the graph.

[0058] Hierarchical confirmation: Traverse the graph structure to check for any "isolated levels" caused by node deletion or "inherited permissions" that have not been cleaned up, and ensure that the cleanup covers all relevant levels.

[0059] 6. No residual trace verification and security cleanup (corresponding to S107) is audited at the end of the process to ensure that the system is in a secure state.

[0060] Breadth-first search (BFS): The system traverses the updated permission graph layer by layer, scanning the remaining nodes.

[0061] Residual Traces: Compare node configuration with underlying system logs. If the graph shows that permissions have been revoked, but the system logs show that the account still has successful access records, then residual traces exist and are marked as abnormal.

[0062] Security cleanup requirements: The system sets a security threshold (e.g., the abnormal node rate is less than 1%). If the threshold is met, a "final confirmation of uninstallation" status flag is output, completing the entire dynamic adaptation and isolation process.

[0063] 7. Dynamic Adaptation and Update of Permissions: After the permission uninstallation is completed, the system automatically triggers a dynamic adaptation process: Based on the updated permission graph after this uninstallation, the baseline rules for group permission control are adjusted synchronously, and the judgment parameters for permission dependencies are updated; at the same time, the permission changes of various business systems within the group are scanned, and the adaptation rules for subsequent permission collection, classification, and filtering are automatically optimized for business scenario changes brought about by this employee job transfer and project completion, ensuring that the subsequent permission management process is fully matched with the current business status.

[0064] As shown in Figure 6, the access control deployment architecture of this invention in an enterprise hybrid cloud data center environment includes the following physical entities and their spatial connections. Client terminal 10 is located on the far left of the deployment architecture, containing multiple user terminal devices used to initiate access requests to the enterprise's internal systems. Enterprise firewall 20, as the first security barrier, is deployed between client terminal 10 and the internal servers, executing ACL blocking policies to intercept unauthorized access requests. Access control server 30 has a built-in access graph engine, responsible for dynamically calculating access authorization results based on the multi-layered access graph and issuing access control instructions to the downstream application server cluster 40. Application server cluster 40 includes three application servers: a financial system, a research and development system, and an HR system. The connection to the HR system is represented by a dashed line, indicating that the system is currently in an access-isolated state, and its API calls have been intercepted by the AOP interceptor of the application logic layer. Database server 50 stores the access graph database. When an isolation operation is triggered, it implements data-level access unloading by modifying the View and revoking schema access permissions. Cloud storage 60 is deployed in the form of a hybrid cloud resource pool, maintaining normal data synchronization connections with database server 50. In the diagram, solid lines represent normal, active access paths, while dashed lines represent paths that have been isolated or blocked. The corresponding permission control action type is marked at key connection nodes.

[0065] Example 2: Dynamic Isolation and Unloading of Data Resource Permissions in a Large Enterprise Group This example uses cross-departmental data sharing within a large enterprise group's big data platform as a case study to illustrate the application of this invention in a complex, multi-layered architecture. In this platform, multiple departments, such as purchasing, sales, and finance, share a database of basic supplier and customer information. Due to the extremely high commercial sensitivity of this data, when a temporary data query or internal audit task is completed, it is essential to ensure that the relevant permissions are completely and securely unloaded.

[0066] In this embodiment, the enterprise data platform implements full-link permission control according to a four-layer architecture of business layer, application layer, platform layer and data layer, strictly implements permission isolation preprocessing and full-process dynamic adaptation mechanism to ensure the compliance of enterprise core data access and business continuity.

[0067] First, the system constructs an enterprise resource permission graph model. The system obtains attribute tags for various permissions in the data resource pool in real time through a metadata interface, including source (e.g., finance department settlement database), scope (e.g., limited to verification of temporary purchase refund details), and validity period (e.g., 30-day validity). In the model, the access right to each data interface is defined as a permission node, and edges represent the logical relationships between these permissions. For example, the permission node for obtaining detailed account statements depends on the prior approval of employee identity and security level verification permission nodes. If the system detects that an authorization for temporary refund verification has expired by a preset deadline, the node is marked as invalid in the graph.

[0068] Secondly, the system utilizes a graph traversal algorithm to identify dependency chains. The system employs a depth-first search algorithm to perform a deep scan of the enterprise's permission graph. Starting from a specific business auditor account node, the algorithm automatically identifies the complete access path—the path through which the auditor accesses the settlement database via the enterprise intranet and then calls the transaction comparison interface—that is, the dependency chain. During the traversal, the system identifies shared dimensions (such as all permission items bearing the same temporary audit project number label) to aggregate database read rights, interface call rights, and log audit rights scattered across different levels into a specific dependency subset.

[0069] Subsequently, the system addresses the issue of insufficient granularity using a decision tree algorithm. In enterprise business data scenarios, if the original authorization allows viewing all customer and supplier profiles, this is clearly insufficient in granularity compared to the need to verify contact information for specific purchase batches. The system inputs features such as the operation behavior of the permission item and the level of data anonymization into the decision tree. The decision tree categorizes permissions according to built-in business compliance rules, filtering out high-risk, broad permissions involving trade secrets and determining if they match security uninstallation conditions, thus placing them into the categorized target permission group.

[0070] After completing the division of target permission groups, the system synchronously executes a dynamic adaptation process: for changes in business scenarios at the end of this temporary audit task, it automatically adjusts the permission validity verification rules and the business whitelist adaptation parameters of the correlation analysis to ensure that the uninstallation process fully matches the permission control requirements of the enterprise's internal special audit.

[0071] During the clean uninstallation set generation phase, the system conducts correlation analysis to ensure uninterrupted cross-departmental collaboration within the enterprise. First, the system identifies expired permissions within the target permission group, forming an expired subgroup. Next, using correlation rule analysis technology, it performs a real-time scan of the auditor's current active business. If the analysis reveals a symbiotic relationship between a verification permission to be uninstalled and ongoing routine procurement and settlement business (i.e., this permission is also the foundation for other legitimate business), it is classified as an irrelevant legitimate permission. By eliminating these false positives, the system generates a clean uninstallation set, ensuring that only truly isolated and expired temporary authorizations are removed.

[0072] After generating the clean uninstall set, the system first performs enterprise permission isolation preprocessing: based on the enterprise's business data security specifications, it locks all temporary authorized nodes within the clean uninstall set, completely blocks their data access links in the enterprise's intranet access control list, and adds high-risk isolation markers to the nodes to be uninstalled in the permission graph, strongly logically isolating them from the legitimate permissions of routine enterprise businesses such as procurement settlement and contract management that are still running. After the isolation operation is completed, the system generates an isolation operation log that meets the enterprise's internal audit requirements. After triple verification confirms that the isolation status is correct, the subsequent uninstallation operation is then executed.

[0073] During the uninstallation and graph update phases, the system performs structured deletion of the permission graph. Based on the clean uninstallation set, the system synchronously deletes the corresponding nodes and associated edges in the graph database. To verify the thoroughness of the uninstallation, the system performs another graph traversal to confirm that all relevant permission levels from the application layer, platform layer to the data layer have been covered, and there are no potential access points remaining due to incomplete uninstallation, thus obtaining the updated permission graph.

[0074] Finally, the system performs a cleanup of any remaining traces. Before officially revoking permissions, the system uses a breadth-first search algorithm to perform a full scan of the updated permission graph, focusing on checking any remaining nodes that have physical connections to the deleted nodes. The system cross-references the logical configuration in the graph with the underlying system's real-time access control lists (ACLs) and operation logs. If it finds that the graph shows permissions have been revoked, but the underlying cache still retains the identity credentials of the business auditor, it is marked as a residual trace and recorded as an anomaly. The system makes its judgment based on preset security cleanup requirements (such as an anomaly residual rate of less than 0.1%). Only after confirming that there are no unauthorized residual traces does the system finally output a status indicator confirming the uninstallation, achieving clean isolation of enterprise business data permissions.

[0075] More specifically, an embodiment of the present invention provides a method for dynamic adaptation and isolation unloading of multi-resource permissions in a multi-layer architecture, which may include: step S101, obtaining a set of attribute tags for all permission items from the multi-resource system through a pre-established permission graph model, including source, scope and validity, to obtain a permission graph, wherein each node represents a permission item and the edges represent attribute association relationships.

[0076] Based on the access interface of the multi-resource system, the source domain, scope domain, and expiration domain attribute tags of all permission items are collected. A preset rule parser is used to convert the collected attribute tags into structured data, resulting in a permission item attribute set. An initial permission graph model is constructed, using permission items as graph nodes and logical dependencies between attribute tags as edges. If the two ends of an edge share the same source domain, duplicate permission item nodes under that source domain are merged. The status of a permission item node is determined based on its expiration domain attribute; if the expiration domain has expired, the node is marked as invalid. The permission graph is traversed to obtain the scope domain attribute of each valid node, generating a permission coverage list.

[0077] As shown in Figure 2, the construction process of the permission graph model is as follows: Multiple resource systems (Resource System A, Resource System B, and Resource System C) provide data sources through the multi-resource system access interface. The attribute tags of each permission item are obtained by the attribute tag collection module, and then parsed by the rule parser to construct the permission graph model. The permission graph model contains multiple permission item nodes, each labeled with three types of attribute tags: source domain, scope domain, and expiration domain. Logical dependencies between nodes are represented by attribute association edges. Nodes with expired expiration dates are marked as invalid nodes, and nodes sharing the same source domain can be merged to form merged nodes. Based on the permission graph model, dependency chain analysis and shared dimension identification determine the dependencies between each permission item, generating dependency subsets, and finally outputting a permission coverage list, providing a basis for subsequent permission unloading operations.

[0078] In one possible implementation, the access interface of a multi-resource system typically involves multiple data sources, such as an internal enterprise access control system and external cloud service interfaces. These interfaces provide basic information about permission items. When collecting the source domain, scope domain, and time-limited attribute tags of permission items, data can be obtained from these interfaces via API calls.

[0079] Specifically, the source field label indicates the origin of the permission item, such as "internal HR system" or "external supplier platform"; the scope field label defines the scope of objects to which the permission applies, such as "specific department documents" or "global user data"; and the validity field label indicates the validity period, such as "2023-01-01 to 2024-12-31".

[0080] For example, in an enterprise resource management system, suppose we collect a permission item "View Financial Reports," with its source domain being "Finance Department Database," scope domain being "Finance Team Members Only," and validity domain being "Valid until June 30, 2024." This data collection method ensures that all permission item attribute tags are completely recorded, forming a preliminary data foundation, which facilitates subsequent structured processing. A pre-defined rule parser is used to convert the collected attribute tags into structured data, resulting in the permission item attribute set.

[0081] In one possible implementation, the rule parser could be a JSON-based conversion tool that parses tags into key-value pairs according to predefined mapping rules.

[0082] For example, for the "View Financial Reports" permission item mentioned above, the parser will generate structured data such as {"Source Domain": "Finance Department Database", "Scope Domain": "Finance Team Members Only", "Time Period Domain": "2023-01-01 to 2024-06-30"}, thus forming an attribute set containing multiple similar objects. This transformation process not only standardizes the data format but also facilitates subsequent graph model construction, avoiding ambiguity in labels. An initial permission graph model is constructed using permission items as graph nodes and logical dependencies between attribute labels as connecting edges.

[0083] In one possible implementation, logical dependency can be understood as a subordinate relationship between attributes.

[0084] For example, if the scope of one permission item depends on the source domain of another, a directed edge is created. For instance, in an enterprise system, the "Edit Financial Report" permission node might be connected to the "View Financial Report" node via a "dependency" edge because the scope of the edit permission must include the source domain of the view permission. This constructed graph model resembles a directed graph, and can be visualized using tools like Graphviz to clearly show the hierarchical structure between permissions. If the nodes at both ends of an associated edge share the same source domain, duplicate permission nodes under that source domain are merged.

[0085] In one possible implementation, the graph model is traversed, and the nodes connected by the edges are checked. If both originate from the "finance department database" and have similar permission items, such as "view report A" and "view report B" being of the same type, they are merged into a single node "view financial report collection".

[0086] For example, in actual business operations, this can reduce redundancy, improve the efficiency of access control, and prevent users from granting duplicate authorizations under the same domain. Based on the expiration domain attribute, the status of the permission item node is determined; if the expiration domain has expired, the node is marked as invalid.

[0087] In one possible implementation, the current system time is compared with the expiration field. If the expiration field for "View Financial Reports" expires on June 30, 2024, while the current date is July 1, 2024, it is marked as expired. This mechanism ensures dynamic updates to the permission graph and prevents the abuse of expired permissions. The permission graph is traversed to obtain the scope attribute of each valid node, generating a list of permission coverage areas.

[0088] In one possible implementation, a depth-first traversal is performed starting from the root node to collect the scope domains of all unmarked invalid nodes, such as generating a list including entries like "Reports accessible to finance team members" and "Customer data viewable by the sales department".

[0089] For example, in enterprise applications, this list can be output as a report form, making it easier for administrators to review the coverage and achieve comprehensive monitoring and optimization of permissions.

[0090] Step S102: Based on the obtained permission graph, a graph traversal algorithm is used to traverse all nodes and edges to determine the dependency chains between permission items and obtain a dependency subset, where the dependency chains reflect the shared dimension of attribute labels.

[0091] By collecting data from permission nodes, the attribute information of each node in the permission graph is obtained to determine the initial connection status between nodes. Based on the node access results, a depth-first search algorithm is used to traverse all edge connectivity in the permission graph to obtain the associated paths between edges and nodes. For the edge connectivity traversal results, the dependency chains between permission nodes are analyzed. If the connection strength between nodes in a certain path is higher than a preset threshold, it is classified as a strong dependency relationship, and the distribution of strong dependency chains is determined. From the distribution of strong dependency chains, the association information of attribute tags is extracted, and the specific patterns of tag association are sorted out to obtain tag grouping under the shared dimension. Through the tag grouping of the shared dimension, dependency subsets are divided, and the permission analysis results within each subset are analyzed to determine the hierarchical relationship between subsets. Using the output of the relationship sorting, combined with the data from the dimension division, the dependency subsets of permission items are classified and stored to obtain the final permission dependency structure.

[0092] As shown in Figure 4, the permission dependency network displays the dependencies and clustering distribution among permission items in a directed graph structure. The graph contains 18 permission item nodes, divided into four dependency subsets according to the shared dimension: Project P001 dimension, Financial System dimension, Human Resources Management dimension, and Platform Operation and Maintenance dimension. Each subset is circled by a dashed ellipse. Nodes are distinguished by a grayscale color scheme: nodes with dark gray solid borders represent strong dependency core nodes, such as code submission rights, report viewing rights, salary viewing rights, and configuration modification rights, which have high connectivity and play a pivotal role in the dependency network; nodes with light gray solid borders represent ordinary permission nodes; and nodes with light dashed borders represent expired permission items, such as financial export rights and file modification rights. Directed edges indicate the direction of dependency between permission items. Thick solid black arrows represent strong dependencies with a connection strength greater than or equal to a threshold of 0.8, while thin dashed gray arrows represent weak dependencies with a connection strength less than 0.8. Weak connections across clusters reflect indirect associations between different dimensions, providing a reference for subsequent merging and splitting of dependency subsets.

[0093] In one possible implementation, data collection for the permission node can be specified as extracting data from the interface between the enterprise's human resources system and project management system.

[0094] For example, an employee node named "Zhang San" has attributes including its department "R&D Department", job title "Senior Engineer", and the project number "P001" it is currently involved in. By querying its account status in various systems, the system initially determines that this node may be connected to permission nodes such as "R&D Department Resource Library Access Right" and "P001 Project Code Submission Right". These initial connection states constitute the initial edges of the permission graph.

[0095] Specifically, the implementation of the depth-first search algorithm in graph traversal can start from the employee node "Zhang San". The algorithm first follows the edge of "Department" to access the organizational node "R&D Department", and then discovers that "R&D Department" is associated with the permission node "Department Shared Document Area Write Right". Subsequently, the algorithm backtracks and follows the edge of "Participating Projects" to access the "P001 Project" node, and then further traverses to the "Project Production Server Login Right" node. In this way, the system can traverse the complete association path from subject to permission, such as "Zhang San -> R&D Department -> Department Shared Document Area Write Right" and "Zhang San -> P001 Project -> Project Production Server Login Right".

[0096] It should be noted that the threshold for connection strength determination depends on the definition of the business rules.

[0097] For example, a rule can be set: if a permission node is depended on by more than 80% of the upstream nodes on the same path, it is considered a strong dependency. Suppose that under the "P001 Project" path, "Project Production Server Login Right" is required by all role nodes (such as development, testing, and operations) on this path, and its connection strength assessment is 95%, exceeding the preset 80% threshold. Therefore, it forms a strong dependency chain with the project nodes and role nodes on this path. Analyzing these chains reveals that they all share the core dimension of "Project Context." Based on the shared "Project Context" dimension, the system can automatically group the tags of permission nodes such as "Project Production Server Login Right," "Project Defect Management System Access Right," and "Project Weekly Report Submission Right." This grouping process essentially sorts out the association patterns between tags, gathering permissions serving the same business goal together to form a dependency subset, which can be named the "P001 Project Core Operation Permission Set." Similarly, the system can also form other subsets such as the "R&D Department Routine Office Permission Set." Furthermore, by analyzing the inclusion and referencing relationships between subsets, their hierarchy can be determined.

[0098] For example, the "P001 Project Core Operation Permission Set" might be contained within a higher-level "General Permission Template for Software Development Projects," which in turn references some permissions from the "R&D Department Regular Office Permission Set." This hierarchical analysis allows scattered permission items to be organized hierarchically according to business logic. Ultimately, based on the identified dependencies and dimensional divisions, the system categorizes and stores the "P001 Project Core Operation Permission Set" and its hierarchical relationships into specific directories in the permission repository, thereby constructing a clear and manageable permission dependency structure that facilitates unified authorization and auditing.

[0099] Step S103: If there are permission items with insufficient granularity in the obtained dependency subset, the subset is classified by decision tree algorithm to determine which permission items in the classification result match the specific uninstallation conditions, and the classified target permission group is obtained.

[0100] Retrieve permission item data from the dependency subset. Determine if any permission items have insufficient granularity based on their granularity attributes. If insufficiently granular permission items exist, classify the dependency subset using a decision tree algorithm. Obtain multiple permission categories from the decision tree classification results. For each permission category, determine if its permission items match preset uninstallation conditions. Based on the matching results, filter out the set of permission items that meet the uninstallation conditions. Integrate all filtered permission item sets to obtain the final target permission group.

[0101] Specifically, after obtaining the categorized target permission groups, if a permission item is identified as a coarse-grained permission with insufficient granularity, this embodiment also includes a dynamic adaptation step: the system automatically extracts the resource access logs under the coarse-grained permission, uses cluster analysis to identify the underlying atomic resources that the user actually calls frequently, and decomposes the original coarse-grained permission node into multiple fine-grained permission tags that match the underlying atomic resources, and remounts them to the permission graph, thereby realizing dynamic and refined adjustment of permission granularity.

[0102] In its implementation, the decision tree algorithm classifies permissions based on multi-dimensional features. Specifically, the system pre-extracts the operational risk weight, resource level depth, historical call frequency, and data sensitivity level of each permission item as classification criteria. Internally, the decision tree compares the values ​​of these features layer by layer. For example, it first determines whether the operational risk exceeds a preset high-risk threshold, and then determines whether the resource pointed to by the permission is located at the root node of the core system. If a permission item is determined to involve write operations to the core system and its authorized scope exceeds actual business needs, then the permission item is classified as a "target permission item" matching specific unloading conditions, thereby achieving accurate identification of permissions with insufficient granularity.

[0103] In one possible implementation, after obtaining the permission item data in the dependency subset, it is necessary to make a judgment based on its granularity attribute.

[0104] For example, in a cloud storage service's permission management system, the granularity attribute of a permission item might be defined as "the minimum scope of the objects to be operated on".

[0105] Specifically, if a permission item named "File Deletion" exists, and its operation object is defined as "the entire project bucket," this means that a user with this permission can delete all files within the project bucket. This definition of "the entire project bucket," compared to the more granular definition of "a specific folder" or "a single file," may be considered insufficiently granular because it cannot meet the business needs for differentiated management of different folders or files. For permissions items identified as insufficiently granular, a decision tree algorithm can be used for classification. The core of the decision tree algorithm lies in dividing data into different categories through a series of attribute-value-based judgment rules.

[0106] For example, in the cloud storage scenario described above, the "operation type," "resource level," and "data sensitivity" of the permission item can be selected as decision features. Through training, the decision tree may generate classification rules such as: first, determine whether the operation type is a "write operation"; if so, further determine whether the resource level is a "top-level container"; if so, classify the permission item as a "high-risk coarse-grained write permission" category. In this way, the original dependency subset is systematically divided into multiple permission categories with different characteristics, such as "high-risk coarse-grained write permission," "low-risk fine-grained read permission," and "management configuration permission." After obtaining these permission categories, it is necessary to determine whether each one matches the preset unloading conditions. The unloading conditions are a set of business rules used to identify permissions that can be stripped from the core business system and delegated to external or low-privilege modules.

[0107] For example, for the "low-risk fine-grained read permission" category, the preset uninstallation conditions may include "the operation does not involve data changes" and "the access frequency is higher than the threshold".

[0108] In one embodiment, the system scans all permission items in that category, such as "read user profile picture" and "query department announcement list," to check if they simultaneously meet both conditions. Permission items that meet the conditions, such as the frequently used "query department announcement list," are filtered out and included in the set to be uninstalled. Finally, the system integrates the filtered permission items from all categories that meet the uninstallation conditions to form a target permission group. This target permission group represents the set of permissions suitable for unified processing, such as migrating to an edge gateway or a separate permission microservice. Through this series of operations, the system not only identifies shortcomings in the permission design but also automatically completes the optimized grouping of permissions, providing clear input for subsequent architectural decoupling and security hardening.

[0109] Step S104: For the obtained classified target permission groups, obtain the validity period attribute and grant time of each permission item in the group, determine the permission item subgroups whose validity period has expired or exceeded the scope, and obtain the expired subgroups.

[0110] After acquiring the categorized permission group data, the number of permission items under each permission group is iterated through one by one. The corresponding expiration attributes and grant times are extracted from the storage system to obtain a complete basic dataset of permission items. Using a time comparison method, the expiration attribute and grant time of each permission are calculated. If the current system time exceeds the range defined by the expiration attribute, the permission item is marked as expired, resulting in a permission dataset with status identifiers. Based on the expired status identifiers, the permission dataset is filtered, and permission items marked as expired are assigned to specific subgroups, completing the subgroup division and obtaining a preliminary set of expired permission subgroups. For the expired permission subgroup set, the applicable scope of each permission is secondary-verified using scope definition rules. If a permission item exceeds the preset scope definition, it is confirmed to belong to the expired subgroup, resulting in the verified expired permission subgroups. Through permission analysis, the status of the verified expired permission subgroups is updated, recording the expiration reason and time of each permission, forming a detailed permission status log dataset. Obtain the permission status log dataset, and based on the result classification rules, organize and classify the expired permission subgroups according to permission groups to generate the final classification results of the expired permission subgroups.

[0111] For example, in an enterprise access control system, the first step is to retrieve pre-categorized permission group data from the database. These groups might include user access groups, data editing groups, and system configuration groups. For each permission item within a group—for example, the user access group has 10 permission items—the system iterates through these items one by one, extracting the expiration attribute (e.g., a 6-month validity period) and the grant date (e.g., 2023-01-01) from a storage system like MySQL. This constructs a complete basic dataset of permission items containing all these attributes. This process ensures data integrity and provides a foundation for subsequent analysis.

[0112] In one possible implementation, when using a time comparison method, the expiration time of each permission item is calculated. For example, if the grant date is 2023-01-01 and the validity period is defined as 180 days, then the expiration time is 2023-07-01. If the current system time is 2023-08-01, which is outside this range, the permission item is marked as expired. By calculating each item in this way, a dataset with expiration markers is obtained. For example, in a list of permission items, some items are marked as "expired," which helps to quickly identify invalid permissions.

[0113] Specifically, based on these expiration status markers, the dataset is filtered, and all permission items marked as expired are grouped into a specific subgroup, such as creating a subgroup named "Expired Access Permissions." After this division, a preliminary set of expired permission subgroups is obtained. This filtering process is similar to a database query, using conditional filtering to isolate expired items and ensure that subgroups only contain permissions that require further processing.

[0114] For example, for this initial set of expired permission subgroups, a secondary validation is performed using scope definition rules. Scope definition rules can be preset business rules, such as permissions only applying to a specific department like the sales department. If an expired permission item applies to the "entire company," but the rule defines it as limited to the "sales department," then it is confirmed that it does not belong to the expired subgroup and needs to be removed. Through item-by-item validation, a more accurate set of validated expired permission subgroups is obtained. This step emphasizes the strict application of rules to avoid misjudgments.

[0115] In one possible implementation, permission analysis methods are used to update the status of verified subgroups. For example, a logging module can be used to record the expiration reason (e.g., "validity exceeded 180 days") and time (e.g., "2023-08-01 10:00") for each permission item, thus forming a detailed permission status log dataset. This analysis method may involve automated scripts that scan subgroups and generate logs to help administrators track permission changes.

[0116] Specifically, after obtaining this log dataset, the expired permission subgroups are organized according to their original permission groups based on the result classification rules. For example, expired items in the user access group are classified into one category, and expired items in the data editing group are classified into another category, generating the final classification results. This classification rule can be sorted based on group ID to ensure that the results are ordered, facilitating subsequent permission cleanup operations. From a business perspective, this can effectively reduce security risks and optimize resource allocation.

[0117] Step S105: Using the obtained expired subgroups, perform correlation analysis on the permission items within the subgroups using filtering conditions, determine whether the analysis results contain irrelevant legitimate permissions, and obtain a clean uninstall set, wherein the clean uninstall set excludes false positive items.

[0118] Retrieve all permission item data for expired subgroups. Filter the permission items using preset filtering conditions to obtain a candidate permission item set. Analyze the candidate permission item set using an association rule algorithm to generate association rules between permission items. Determine whether each association rule contains irrelevant legal permissions. If an association rule contains irrelevant legal permissions, remove the rule from the result set. Based on the set of association rules after removal, determine the permission items that need to be uninstalled, forming a clean uninstall set.

[0119] When performing association rule analysis, the system filters strong associations between permissions by setting minimum support and minimum confidence. To avoid accidental deletion, the system introduces a business continuity guarantee mechanism: the generated association rules are compared with a pre-stored "whitelist of strongly related business permissions." If a permission item pointed to by an association rule belongs to a basic support permission in the whitelist (such as system log audit permission or basic print driver access permission), and this permission still has a call record in the current active business flow, the system automatically determines the item as an "irrelevant legal permission." Through this logic, the system can remove these "false positives" from the unload sequence, retaining only truly expired redundant permissions, forming a clean unload set.

[0120] As shown in Figure 5, the multi-level filtering flow diagram of permission items uses a Sankey-style stream visualization to show the step-by-step filtering process from the full set to the final clean uninstall set. The first level consists of 100 full permission items. After DFS dependency analysis, the second level divides them into four groups: dependency subset A (35 items), dependency subset B (30 items), dependency subset C (20 items), and independent permission items (15 items). The third level uses decision tree classification to reclassify permission items into high-risk write permissions (25 items), low-risk read permissions (40 items), management configuration permissions (20 items), and directly retained items (15 items). The fourth level performs time-sensitive filtering, identifying expired subgroups (30 items) and valid permissions retained (55 items). The fifth level uses Apriori association analysis to finally determine the clean uninstall set (22 items, marked in dark black in the figure) and the false positive exclusion items (8 items) from the expired subgroups. The remaining valid permissions (55 items) and retained items (15 items) are marked in light gray and not uninstalled. The bandwidth of the stream reflects the number of permission items in each branch proportionally, and the color intensity distinguishes the final destination.

[0121] In one possible implementation, all permission item data for expired subgroups can be retrieved from the permission management system.

[0122] For example, suppose in an enterprise's internal access control system, the expired subgroup contains items such as "file editing permissions" and "database query permissions." These permissions were originally granted to marketing department employees, but have been relegated to the expired subgroup because their validity has expired. Through a database query interface, detailed information about these permissions is retrieved from the repository, including the permission ID, description, grantee, and expiration date, thus forming a complete data list to ensure the accuracy of the underlying data for subsequent processing.

[0123] For example, when filtering permission items using preset filtering conditions, conditions can be set such as the permission type must be "read and write" and the expiration time must be more than 30 days. In this process, all permission items in the expired subgroup are first traversed, and each item is checked to see if its attributes meet the filtering rules. For example, if a permission item is "report generation permission", if it belongs to "read and write" and has expired for 45 days, it is kept in the candidate set, while another "view log permission" is excluded if it has only expired for 15 days. After filtering in this way, a candidate permission item set is obtained. This set focuses on expired permissions with high risk or high impact, which helps to optimize the efficiency of subsequent analysis.

[0124] In one possible implementation, when analyzing the candidate permission item set using association rule algorithms, it's necessary to first understand the principles of association rule algorithms. Association rule algorithms are a data mining technique used to discover frequent patterns and associations between itemsets. For example, using the Apriori algorithm, the algorithm first calculates the frequent itemsets of permission items in the candidate set. Assuming the set contains "file editing permission," "database query permission," and "user management permission," the algorithm scans the data to find combinations with support higher than a threshold (e.g., 0.5). For instance, "file editing permission" and "database query permission" frequently appear together, with a support of 0.6. Then, rules are generated such as "If someone has file editing permission, they are likely to have database query permission." The confidence level is calculated as a conditional probability, i.e., the proportion of the consequent given the antecedent. Through multiple iterations, low-support itemsets are eliminated, ultimately producing a set of association rules. These rules reveal the implicit dependencies between permission items, which helps identify potential security vulnerabilities in business applications.

[0125] For example, in determining whether the permission items in each association rule contain irrelevant but legal permissions, each rule can be checked one by one. For instance, if a rule is "file editing permission → database query permission", it needs to be verified whether irrelevant but still legal items such as "print permission" are mixed in. If the rule is expanded to "file editing permission + print permission → database query permission", and "print permission" is legal but irrelevant to the expiration context, it is marked as containing irrelevant items. This judgment is based on a predefined whitelist of legal permissions and business relevance assessment to ensure the purity of the rules.

[0126] In one possible implementation, if an association rule contains irrelevant legitimate permissions, the rule is removed from the result set. For example, in the above example, if the rule contains "print permission", the system will automatically delete this rule from the association rule set, retaining a clean rule such as "user management permission → system configuration permission". This removal operation is implemented through set operations, aiming to purify the dataset and avoid irrelevant factors interfering with the final decision. In permission management business, this step can significantly reduce the risk of accidental uninstallation, thereby improving the security of the system.

[0127] For example, when determining the permission items that need to be uninstalled based on the set of associated rules after removal, the remaining rules can be traversed to extract all expired permission items involved, forming a clean uninstallation set. For instance, if the remaining rules show that "database query permission" is strongly associated with multiple expired items, then it can be included in the uninstallation set. Isolated permission items may be retained if there are no rules to support them. This process further filters the rules by using their confidence and lifting to ensure that the uninstallation set only contains items that truly need to be removed. In enterprise permission optimization, this can bring more accurate resource recovery and technical effects, such as reducing the exposure of security vulnerabilities.

[0128] Step S106: Based on the obtained clean unload set, delete the corresponding nodes and edges from the permission graph, determine that the deletion operation has covered all relevant levels, and obtain the updated permission graph.

[0129] Step 1: Obtain data from the clean unload set, identify permission nodes and associated edges, and determine the set of nodes and edges to be removed. Step 2: Based on the identified node and edge sets, perform deletion operations to remove the corresponding permission nodes and associated edges from the permission graph, resulting in a preliminarily adjusted graphical structure. Step 3: Using a hierarchical confirmation mechanism, traverse the preliminarily adjusted graphical structure to determine if there are any uncovered associated levels. If uncovered levels exist, continue the deletion operation to obtain a fully cleaned graphical framework. Step 4: Using permission change records, check whether the cleanup of permission nodes and edges meets the unload processing requirements for the fully cleaned graphical framework, ensuring the completeness of permission changes. Step 5: Based on the completeness of permission changes, adjust the graphical framework to generate an updated graph that meets the coverage level requirements. Step 6: By updating the graph data, perform the final unload processing to confirm that all node removal and edge cleanup operations are complete, resulting in the final permission graph structure.

[0130] As shown in Figure 3, the access control system of this invention adopts a four-layer architecture, consisting of a business layer, an application layer, a platform layer, and a data layer from top to bottom. The business layer corresponds to business scenario process permissions, the application layer corresponds to functional module operation permissions, the platform layer corresponds to resource scheduling interface call permissions, and the data layer corresponds to resource storage media access permissions. There are cross-layer dependencies between layers; changes in permissions at higher layers may affect the validity of permissions at lower layers. During the unloading coverage verification process, a top-down, layer-by-layer traversal approach is used to verify whether the nodes and edges at each layer have been correctly deleted. Simultaneously, the isolation operation uses different implementation methods at different layers: the application layer uses AOP / middleware interception for isolation, the platform layer uses ACL / file permissions for isolation, and the data layer uses View / Schema isolation. Through multi-level coverage verification and differentiated isolation strategies, the integrity and security of permission unloading are ensured.

[0131] For example, when handling access control operations, relevant data is first extracted from the clean uninstallation set. For instance, in an enterprise's internal access control system, the clean uninstallation set contains expired user group permission items, such as "file read permission" and "database query permission." By identifying these permission nodes—for example, labeling "file read permission" as node A and identifying the association boundary between it and the "user authentication module" as boundary B—a set of nodes to be removed ({node A, node C}) and a set of boundaries ({boundary B, boundary D}) are formed. These sets are based on the analysis results of the expired subgroups, ensuring the targeted nature of subsequent operations.

[0132] In one possible implementation, the set of these identifiers is then used to perform deletion, such as removing node A and its edge B in the permission graph. This involves updating the graph database, such as using a graph traversal algorithm to delete specified elements, resulting in a preliminarily adjusted graph structure. In this structure, the originally complex permission network is simplified by removing some branches, avoiding interference from redundant access paths.

[0133] Specifically, to ensure the thoroughness of the cleanup, a hierarchical verification mechanism is introduced to traverse the structure. For example, starting from the root node "Administrator Role", the system checks downwards. If an uncovered related hierarchy, such as "Sub-permission Inheritance Layer", is found, the relevant nodes and edges are deleted, eventually resulting in a fully cleaned graphical framework. This helps maintain the security of the system.

[0134] For example, further detection can be performed using permission change records. For instance, if the record shows that the removal of node A caused the disconnection of edge B, check whether the uninstallation requirements are met, such as verifying that there is no residual access risk, thereby determining the integrity of the change and ensuring that the entire process complies with the company's compliance standards.

[0135] In one possible implementation, the graph is adjusted based on the integrity result. For example, if insufficient hierarchical coverage is detected, temporary edges are added to connect the remaining nodes, generating an updated graph. This can improve the efficiency of access control in business operations and reduce potential security vulnerabilities.

[0136] Specifically, the final unloading is performed by updating the graph data. For example, it is confirmed that all identifier nodes, such as node C, have been removed, and edge D is cleaned up to obtain the final permission graph structure. In practical applications, this can be applied to cloud service platforms to ensure dynamic optimization of user permissions.

[0137] Step S107: For the obtained updated permission graph, traverse the remaining nodes to verify that there are no residual traces, determine that the verification result meets the security cleanup requirements, and obtain the final confirmed uninstallation status.

[0138] Retrieve the updated permission graph structure data. Use a breadth-first search algorithm to traverse the remaining nodes in the permission graph. Check the associated configurations and log records of each traversed node. If any residual access traces or dependencies are found, mark the node as abnormal. Based on the inspection results of all nodes, determine whether the preset security cleanup threshold is met. Determine the final uninstallation status of the system and output the status indicator.

[0139] If the verification results show that residual traces exceed the preset security cleanup threshold, it indicates that the uninstallation was incomplete. In this case, the system will automatically trigger a backtracking and remediation mechanism: based on the discovered residual node information, it traces back to the original source domain of the permission graph and performs a forced comparison by retrieving the access control list of the underlying system in real time. By scanning the mapping differences between the physical storage layer and the logical permission graph, the system can locate and remove the isolated processes or redundant accounts that caused the residual traces. After completing the remediation and cleanup, the system will restart a breadth-first search for secondary verification until the residual indicators reach zero, and finally output a status report with a detailed cleanup path.

[0140] In one embodiment, if residual traces are found during the traversal verification, such as a cached token that has not been destroyed or an orphaned middleware configuration item, the system will execute a forced remediation instruction: by reading the difference mapping in the permission graph, accurately locate the underlying process PID or memory address that caused the residual, send a termination signal or perform a cache refresh operation, and after the operation is completed, perform a breadth-first search verification again until the residual indicators at all levels are reduced to zero, ensuring the thoroughness of the uninstallation operation.

[0141] For example, in an enterprise-level user permission management system, the first step is to extract the most recently updated permission graph structure data from the database, which includes all remaining permission nodes and their connection relationships.

[0142] Specifically, this data is typically stored in a graph database, such as using Neo4j to manage node and edge attributes. After the system completes its initial unloading, it queries the current snapshot of the graph to ensure data real-time performance, thus providing an accurate foundation for subsequent traversal. This approach avoids inspection biases caused by data inconsistencies, achieving efficient permission verification in business operations.

[0143] In one embodiment, a breadth-first search algorithm is used to traverse the remaining nodes in the permission graph. This is a search method that expands layer by layer from the starting node. The principle is to use a queue to maintain the nodes to be visited, and to process all nodes in the current layer before moving to the next layer.

[0144] For example, in a permission graph, if the starting point is an administrator role node, the algorithm will first access the user access nodes directly connected to it, and then extend to sub-permissions such as file read and write nodes, thus ensuring the comprehensiveness and order of the traversal.

[0145] Specifically, in actual business processes, assuming the permission graph has 100 remaining nodes, the algorithm starts by enqueuing from the root node, dequeuing and checking each node one by one, and enqueuing unvisited neighbors until the queue is empty. This method is particularly suitable for detecting hierarchical dependencies, avoiding missing deep nodes, and thus supporting the system's security audit requirements.

[0146] For example, for each node that is traversed, it is necessary to check its associated configuration and log records, which involves comparing the node's configuration attributes, such as access level, with the access records in the historical logs.

[0147] Specifically, associated configurations may include node permission types and expiration dates, while log records store data such as user login time and operation type. During the inspection process, if a file access node's configuration shows as expired, but the logs still show recent access traces, it indicates a residual problem. Through this detailed comparison, potential security vulnerabilities can be revealed, helping administrators to promptly identify uncleaned legacy permissions and thus improve the overall security of the system.

[0148] In one embodiment, if any residual access traces or dependencies are found, the node is marked as abnormal.

[0149] For example, a dependency might be a link between a node and other modules, such as database query permissions. If the logs show that there are still unbroken dependencies, the system will add an exception tag such as "residual_access" and log the details.

[0150] Specifically, this marking process can be achieved by updating the node's attribute fields. In business scenarios, such as after software uninstallation, if a plugin node's logs show that a background process still depends on it, it will be marked to prevent potential data leakage risks.

[0151] For example, based on the inspection results of all nodes, it is determined whether the preset security cleanup threshold is met. The threshold can be that the proportion of abnormal nodes is less than 5%, which is evaluated by statistically analyzing the ratio of the number of abnormal nodes to the total number of nodes.

[0152] Specifically, if only 2 out of 100 nodes are found to be abnormal, the threshold is met; otherwise, further cleanup is required. This judgment logic ensures the thoroughness of the unloading process. In the extended solution, weights can be combined, such as giving higher weights to abnormal core nodes, thereby enriching the diversity of judgments.

[0153] In one embodiment, the final unloading status of the system is determined and a status identifier is output.

[0154] For example, if the threshold is met, output the "clean" flag; otherwise, output "pending," which can be presented to the administrator in JSON format.

[0155] Specifically, in business implementation, this output helps automated scripts trigger subsequent actions, such as notifying users to re-uninstall, thus forming a complete cleanup chain and ensuring the continuity and reliability of permission management.

[0156] As shown in Figure 7, the accuracy of permission recognition of the method of the present invention was compared with that of the traditional overall revocation scheme, the permission graph-based scheme (CN112541070A), and the automatic expiration recycling scheme (CN114860901A) under different permission item scales. The horizontal axis represents the permission item scale, ranging from 100 to 10000; the vertical axis represents the percentage of permission recognition accuracy. The test results show that the accuracy of the method of the present invention reaches 95.2% when the permission item scale is 100, and the accuracy steadily increases with the scale, reaching 99.0% when the permission item scale is 10000. In contrast, the accuracy of the traditional overall revocation scheme is only 52.3% when the permission item scale is 100, and the accuracy continues to decrease with the scale, dropping to 35.2% when the scale is 10000. The permission graph-based scheme and the automatic expiration recycling scheme also show a trend of decreasing accuracy with the scale, dropping to 57.3% and 48.6% respectively when the scale is 10000. The method of this invention, through the construction of a permission graph based on three-dimensional attribute tags and the analysis of dependency chains, maintains a high accuracy rate of over 95% at all scale levels, which is more than 90% higher than that of traditional solutions, demonstrating the significant technical advantages of this invention in large-scale permission management scenarios.

[0157] As shown in Figure 8, the false positive rate of legitimate permissions under the four architectural layers (business layer, application layer, platform layer, and data layer) and four permission operation types (read permission, write permission, configuration permission, and management permission) of the method of this invention is displayed in the form of a heatmap. The color depth in the heatmap is positively correlated with the false positive rate; the lower the value, the lighter the color. Test results show that the read permission false positive rate of the data layer is the lowest, at only 0.01%; the management permission false positive rate of the business layer is the highest, at 0.10%. Analyzing from the perspective of layer, the data layer has the lowest overall false positive rate, while the business layer has a relatively higher rate; analyzing from the perspective of permission type, the false positive rate of read permission is generally lower than that of management permission. The false positive rates of all 16 combinations are within the range of 0.01% to 0.10%, with an overall average false positive rate of 0.054%, far below the security threshold of 0.1%. This result verifies the effectiveness of the present invention in accurately identifying permissions through decision tree classification and association rule analysis, ensuring thorough permission uninstallation while controlling the false positive of legitimate permissions to an extremely low level.

[0158] As shown in Figure 9, the trends of unloading coverage and permission residual rate during the BFS verification iteration process of the present invention are presented in a composite form of bar chart and line chart. The left vertical axis represents the unloading coverage, represented by a light gray bar chart; the right vertical axis represents the permission residual rate, represented by a black solid line chart. The horizontal axis represents the BFS verification iteration rounds, totaling five rounds. Test results show that after the first iteration, the unloading coverage reached 92.5%, and the permission residual rate was 7.5%. After each iteration, the unloading coverage continued to improve, while the permission residual rate decreased rapidly. By the fourth round, the unloading coverage reached 99.92%, and the permission residual rate dropped to 0.08%. In the fifth round, the unloading coverage further increased to 99.98%, and the permission residual rate dropped to 0.02%, which is far below the security cleanup threshold of 0.05%. The dashed line in the figure marks the security cleanup threshold; the permission residual rate exceeded this threshold and met the standard between the fourth and fifth rounds. The results verify that the present invention, through multi-level coverage verification and residual trace verification mechanism, can achieve complete clearance of permissions within a limited number of iterations, with the residual rate controlled below 0.05%.

[0159] It should be noted that the above examples are merely some specific embodiments of the present invention. Obviously, the present invention is not limited to the above embodiments and many variations are possible. All variations that can be directly derived or conceived by those skilled in the art from the content disclosed in this invention should be considered within the scope of protection of this invention.

Claims

1. A method for dynamic adaptation and isolation unloading of multi-resource permissions in a multi-layered architecture, characterized in that, The method includes: obtaining a set of attribute tags for all permission items from a multi-resource system, including source, scope, and validity period, through a pre-established permission graph model, to obtain a permission graph, where each node represents a permission item and edges represent attribute relationships; based on the obtained permission graph, traversing all nodes and edges using a graph traversal algorithm to determine the dependency chains between permission items, obtaining a dependency subset, where the dependency chains reflect the shared dimension of attribute tags; if there are permission items with insufficient granularity in the obtained dependency subset, classifying the subset using a decision tree algorithm, determining which permission items in the classification results match specific unloading conditions, and obtaining the classified target permission group; and then, for the obtained classified target... For each permission group, the validity period and grant time of each permission item within the group are obtained. Subgroups of permission items whose validity periods have expired or are out of range are identified, resulting in expired subgroups. Using these expired subgroups, correlation analysis is performed on the permission items within each subgroup based on filtering criteria. The analysis results are checked to determine if irrelevant legitimate permissions are included, resulting in a clean uninstallation set, excluding false positives. Based on this clean uninstallation set, corresponding nodes and edges are deleted from the permission graph. It is confirmed that the deletion operation has covered all relevant levels, resulting in an updated permission graph. For the updated permission graph, the remaining nodes are traversed to verify the absence of residual traces. If the verification results meet the security cleanup requirements, the final confirmed uninstallation status is obtained.

2. The method according to claim 1, characterized in that, The process involves obtaining a set of attribute tags for all permission items from a multi-resource system using a pre-established permission graph model. These tags include source, scope, and validity period. Each node represents a permission item, and edges represent attribute relationships. The process includes: collecting source, scope, and validity period attribute tags for all permission items based on the access interface of the multi-resource system; using a pre-defined rule parser to convert the collected attribute tags into structured data, resulting in a set of permission item attributes; constructing an initial permission graph model using permission items as graph nodes and logical dependencies between attribute tags as connecting edges; merging duplicate permission item nodes under the same source domain if the nodes at both ends of a connecting edge share the same source domain; determining the status of permission item nodes based on the validity period attribute, marking the node as invalid if the validity period has expired; and traversing the permission graph to obtain the scope domain attribute of each valid node, generating a permission coverage list.

3. The method according to claim 1, characterized in that, The process involves: traversing all nodes and edges using a graph traversal algorithm based on the obtained permission graph to determine the dependency chains between permission items and obtain dependency subsets. These dependency chains reflect the shared dimensions of attribute tags. The process includes: acquiring attribute information for each node in the permission graph through data collection from permission nodes to determine the initial connection status between nodes; using a depth-first search algorithm to traverse all edge connectivity in the permission graph based on node access results to obtain the associated paths between edges and nodes; analyzing the dependency chains between permission nodes based on the edge connectivity traversal results, classifying nodes in a path with a connection strength higher than a preset threshold as strong dependencies, and determining the distribution of strong dependency chains; extracting the association information of attribute tags from the distribution of strong dependency chains, sorting out the specific patterns of tag association, and obtaining tag grouping under the shared dimensions; dividing dependency subsets through the tag grouping of the shared dimensions, analyzing the permission analysis results within each subset, and determining the hierarchical relationships between subsets; and using the output of the relationship sorting, combined with the dimension-divided data, classifying and storing the dependency subsets of permission items to obtain the final permission dependency structure.

4. The method according to claim 1, characterized in that, If the obtained dependency subset contains permission items with insufficient granularity, the subset is classified using a decision tree algorithm to determine which permission items in the classification results match specific uninstallation conditions, thus obtaining the classified target permission group. This includes: obtaining permission item data from the dependency subset; determining whether there are permission items with insufficient granularity based on the granularity attribute of the permission items; if there are permission items with insufficient granularity, classifying the dependency subset using a decision tree algorithm; obtaining multiple permission categories from the decision tree classification results; for each permission category, determining whether its permission items match preset uninstallation conditions; filtering out a set of permission items that meet the uninstallation conditions based on the matching results; and integrating all filtered permission item sets to obtain the final target permission group.

5. The method according to claim 1, characterized in that, For the obtained classified target permission groups, the validity period attribute and grant time of each permission item within the group are obtained, and the subgroups of permission items whose validity period has expired or exceeded the range are identified, thus obtaining the expired subgroups. This includes: obtaining the classified permission group data; iterating through the number of permission items under each permission group one by one; extracting the corresponding validity period attribute and grant time from the storage system to obtain a complete basic dataset of permission items; using a time comparison method, calculating the validity period attribute and grant time for each permission item; if the current system time exceeds the range defined by the validity period attribute, marking the permission item as expired to obtain a permission dataset with status identifiers; and filtering the permission dataset according to the expired status identifiers. The process involves selecting and assigning expired permission items to specific subgroups, thus completing the subgrouping and obtaining a preliminary set of expired permission subgroups. For each expired permission subgroup, the applicable scope of each permission is validated a second time using scope definition rules. If a permission item exceeds a preset scope, it is confirmed to belong to an expired subgroup, resulting in validated expired permission subgroups. Through permission analysis, the status of the validated expired permission subgroups is updated, recording the reason and time of expiration for each permission, forming a detailed permission status log dataset. Finally, the permission status log dataset is obtained, and based on the result classification rules, the expired permission subgroups are organized and categorized according to permission groups, generating the final expired permission subgroup classification results.

6. The method according to claim 1, characterized in that, The process involves obtaining expired subgroups, performing association analysis on permission items within each subgroup using filtering conditions, determining whether the analysis results contain irrelevant legitimate permissions, and obtaining a clean uninstallation set. This clean uninstallation set excludes false positives and includes: acquiring all permission item data for the expired subgroups; filtering the permission items using preset filtering conditions to obtain a candidate permission item set; analyzing the candidate permission item set using an association rule algorithm to generate association rules between permission items; determining whether the permission items in each association rule contain irrelevant legitimate permissions; if an association rule contains irrelevant legitimate permissions, removing that rule from the result set; and determining the permission items that ultimately need to be uninstalled based on the removed association rule set, thus forming the clean uninstallation set.

7. The method according to claim 1, characterized in that, The process of deleting corresponding nodes and edges from the permission graph based on the obtained clean unload set, ensuring that the deletion operation covers all relevant levels, and obtaining an updated permission graph includes: Step 1: Obtaining data from the clean unload set, identifying permission nodes and associated edges, and determining the set of nodes and edges to be removed; Step 2: Performing deletion operations based on the identified set of nodes and edges, removing the corresponding permission nodes and associated edges from the permission graph, and obtaining a preliminary adjusted graph structure; Step 3: Traversing the preliminary adjusted graph structure through a level confirmation mechanism to determine if there are any uncovered associated levels. If there are uncovered levels, the deletion operation continues, resulting in a fully cleaned graph framework; Step 4: Using permission change records, checking whether the cleanup of permission nodes and edges meets the unload processing requirements for the fully cleaned graph framework, and determining the completeness of permission changes; Step 5: Adjusting the graph framework based on the completeness of permission changes to generate an updated graph that meets the level coverage requirements; Step 6: Performing the final unload processing by updating the graph data, confirming that all node removal and edge cleanup operations have been completed, and obtaining the final permission graph structure.

8. The method according to claim 1, characterized in that, The process of traversing the remaining nodes of the obtained updated permission graph to verify the absence of residual traces and determining whether the verification results meet the security cleanup requirements, and obtaining the final confirmed uninstallation status, includes: obtaining the updated permission graph structure data; traversing the remaining nodes in the permission graph using a breadth-first search algorithm; checking the associated configurations and log records of each traversed node; marking the node as abnormal if any residual access traces or dependencies are found; determining whether the preset security cleanup threshold is met based on the inspection results of all nodes; determining the final uninstallation status of the system and outputting the status identifier.

Images