ITSM-oriented permission delegation path planning method

Abstract

The application provides an ITSM-oriented permission delegation path planning method. The method deploys a local planning agent and a local policy evaluation component in each compliance domain, so that the policy evaluation process is completed within the local domain where the sensitive data is located, thereby providing a local feasibility proof object and an attribute capability token to the central path planning module without transmitting local sensitive attributes across borders. The central path planning module establishes a candidate permission delegation path set based on the non-sensitive attribute set allowed across borders, and when it needs to determine whether a path is feasible, it sends a local query request involving the corresponding compliance domain to the local planning agent within the compliance domain, which invokes local policy rules and local sensitive attribute sets for evaluation within the local domain, and then returns the evaluation result in the form of a local feasibility proof object without containing sensitive field original values. Thus, compliance requirements are considered while maintaining the automation and executability of permission delegation path planning.

Description

Technical Field

[0001] This application relates to path planning technology, and more particularly to a permission delegation path planning method for ITSM. Background Technology

[0002] In existing IT service management systems, permission delegation path planning typically adopts a centralized authorization control model, where the central end uniformly maintains the relationship diagram between users, roles, organizations, resource objects, and change orders, and performs permission path search and policy judgment at the central end.

[0003] To determine whether an authorization path is compliant and feasible, the central end needs to rely on detailed information such as user identity attributes (e.g., region, organization, job title), asset tags (e.g., asset region, sensitivity level, business domain), and work order content (e.g., whether it involves specific customer data, data type, and operation purpose).

[0004] However, in cross-regional deployment scenarios, especially when it comes to the regulation of cross-border data transmission, data localization requirements and industry compliance standards, some user attributes, asset attributes and work order fields are classified as sensitive data, which can only be stored and used within the local domain and are not allowed to be transmitted across borders or directly disclosed in overseas systems. This results in a significant conflict between the existing centralized authorization path planning model and the actual data residency strategy. Summary of the Invention

[0005] This application provides a permission delegation path planning method for ITSM, which addresses how to ensure that the central path planning module can still obtain sufficient and trustworthy constraint judgment basis to complete the feasibility and compliance judgment of cross-regional permission delegation paths without breaking the boundaries of data residence in different regions and cross-border compliance, and without exposing local sensitive attributes and work order sensitive content at the central end. Thus, in actual deployment environments with multiple compliance domains and multiple security domains, it can realize automated authorization path planning that meets regulatory requirements and is executable.

[0006] The permission delegation path planning method for ITSM provided in this application deploys local planning agents and local policy evaluation components within each compliance domain. This allows the policy evaluation process to be completed within the local domain where sensitive data resides, thus providing the central path planning module with structured local feasibility proof objects and attribute capability tokens without cross-border transfer of local sensitive attributes. The central path planning module establishes a candidate permission delegation path set based solely on the set of non-sensitive attributes allowed across borders. When it needs to determine the feasibility of a path, it sends a local query request involving the corresponding compliance domain to the local planning agent within that compliance domain. The agent then calls local policy rules and the local sensitive attribute set for evaluation within the local domain, and returns the evaluation result as a local feasibility proof object that does not contain the original values ​​of sensitive fields. By employing the above methods, on the one hand, it ensures that sensitive user attributes, asset attributes, and work order content remain within the local domain, complying with data residency and cross-border compliance requirements; on the other hand, it provides the central end with credible proof information that can be used to evaluate path constraints, enabling the central path planning module to correctly identify feasible and infeasible paths in a multi-compliance domain environment, thereby achieving automation and executability of permission delegation path planning while taking into account compliance requirements. Attached Figure Description

[0007] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0008] Figure 1 This is a flowchart illustrating an ITSM-oriented permission delegation path planning method according to an example embodiment of this application; Figure 2 This is a schematic flowchart of S400 shown in the first example embodiment of this application; Figure 3 This is a schematic flowchart of S400 shown in the second example embodiment of this application; Figure 4 This is a schematic flowchart of S400 shown in the third exemplary embodiment of this application; Figure 5 This is a schematic flowchart of S600 shown in the first example embodiment of this application; Figure 6 This is a schematic flowchart of S600 shown in the second example embodiment of this application; Figure 7 This is a schematic flowchart of S600 shown in the third example embodiment of this application.

[0009] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0010] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0011] In cross-regional ITSM permission delegation scenarios, the goal of permission path planning is to determine an executable delegation path from the authorization requesting entity to the target operation permission. This path typically needs to satisfy at least three types of constraints: The first type is permission relationship constraints, i.e., whether there are role, organizational, approval, or resource access relationships between candidate nodes. The second type is business context constraints, i.e., whether the operation type, risk level, scope of change, and target asset of the current work order allow the path to be executed. The third type is compliance constraints, i.e. whether the entities, resources, and work order content involved in the authorization comply with relevant regional or industry regulatory requirements. Since the second and third types of constraints usually rely on fine-grained attributes, attribute data is required to participate in policy evaluation during the path planning process.

[0012] In traditional centralized architectures, the central path planner performs the aforementioned evaluation by reading attributes from various data sources. This approach relies on the central path planner having access to all necessary attributes, and the attribute transfer from different regions to the central server not violating security or compliance boundaries. However, in cross-regional deployment scenarios, data residency policies alter this premise. Data residency policies restrict the use of certain sensitive attributes to the local compliance domain and use compliance gateways to filter fields or block transmission of external requests. Therefore, when the central path planner still requests attributes in the traditional way, the actual data set it can obtain will be less than the data set required for policy evaluation.

[0013] When the available attribute set is less than the attribute set required by the strategy, path planning inevitably encounters uncertainty. If the strategy evaluation component adopts a default allow rule when key attributes are missing, it may incorrectly classify non-compliant paths as feasible, creating a risk of false approval. If a default reject rule is adopted, it may incorrectly classify compliant paths as infeasible, creating a risk of false rejection. If an undecidable state is returned, the central path planner cannot effectively prune candidate paths, leading to an expansion of the search space, an increase in the number of replanning attempts, and a reduction in the processing efficiency of authorization requests. Therefore, missing attributes do not simply affect the accuracy of judgment, but rather propagate to all stages of the path search algorithm, affecting candidate path retention, path ranking, target path selection, and the success rate of the execution phase.

[0014] Meanwhile, directly replacing the original sensitive attributes with de-identified fields cannot fully eliminate the aforementioned uncertainties. The purpose of de-identification is to reduce the risk of data exposure, but the purpose of policy evaluation is to maintain the semantic integrity of conditional judgments. When the de-identification result is too coarse, it cannot support the judgment of complex policy conditions. When the de-identification result contains sufficiently detailed judgment information, it may carry semantics that allow for the inference of sensitive attributes, thereby increasing compliance risks. Therefore, the existing centralized path planning plus de-identified transmission method essentially still requires the central end to obtain information for policy judgment; it only changes the information format and does not change the fundamental pattern that the central end needs to master local sensitive semantics.

[0015] Therefore, to solve this technical problem, the system architecture needs to shift from centralized evaluation of sensitive attributes after cross-domain transmission to evaluation where sensitive attributes remain within the local domain. In other words, policy evaluation capabilities should be decentralized to the local compliance domain, enabling it to perform local feasibility assessments using local sensitive attributes and local policy rules. The assessment results, proof objects, or capability credentials (excluding the original sensitive attributes) are then provided to the central path planner. The central path planner no longer directly obtains local sensitive attributes; instead, it uses the reliable results returned by each local compliance domain to combine candidate paths and determine the target path. This approach allows the central path planner to obtain the decisionable information needed for path planning without violating data residency boundaries.

[0016] As the above derivation shows, the essence of this technical problem lies in the incompatibility between existing centralized permission delegation path planning mechanisms and cross-regional data residency mechanisms in terms of data acquisition methods, policy evaluation locations, and path search control processes. The central path planner requires fine-grained attributes to ensure the accuracy of path planning, while compliance mechanisms require that fine-grained sensitive attributes not leave the local domain. Without changing the policy evaluation location and proof transmission method, simply expanding central access permissions, adding desensitized fields, or delaying manual approval cannot simultaneously meet the requirements of data compliance and automated path executability. Therefore, there is an urgent need to provide a permission delegation path planning technical solution that enables local use of sensitive attributes, allows trusted use of local policy results by the central end, and supports cross-regional combined path judgment.

[0017] Figure 1 This is a flowchart illustrating an ITSM-oriented permission delegation path planning method according to an example embodiment of this application. Figure 1 As shown, the method provided in this embodiment includes: S100. After receiving a permission delegation request, establish a set of candidate permission delegation paths based on the set of non-sensitive attributes.

[0018] In this step, after receiving the permission delegation request, a set of candidate permission delegation paths is established based on a set of non-sensitive attributes. The set of non-sensitive attributes includes at least one of user identification information, role identification information, organization identification information, region identification information, resource identification information, and service identification information.

[0019] In one specific implementation, upon receiving a permission delegation request, the central path planning module first parses the subject information, target resource information, and service request information in the permission delegation request, and extracts a set of non-sensitive attributes for path planning from the permission delegation request. The set of non-sensitive attributes includes at least one of the following: user identification information, role identification information, organization identification information, region identification information, resource identification information, and service identification information.

[0020] Specifically, the central path planning module retrieves the role and organizational relationships corresponding to user identification information from the identity management system to form a set of entity-side associated nodes. Simultaneously, it retrieves the service dependencies corresponding to service identification information from the service catalog system to form a set of service-side associated nodes. Finally, it retrieves the resource ownership and geographic ownership relationships corresponding to resource identification information from the resource management system to form a set of resource-side associated nodes.

[0021] After forming the sets of associated nodes on the subject side, service side, and resource side, the central path planning module establishes a permission delegation graph based on the delegation relationships between these nodes. The nodes in the permission delegation graph include at least one of the following: user nodes, role nodes, organization nodes, service nodes, region nodes, and resource nodes. The edges in the permission delegation graph represent at least one of the following: authorization relationships, attribution relationships, service relationships, and region relationships between nodes.

[0022] Subsequently, the central path planning module takes the main node corresponding to the user identification information in the permission delegation request as the starting node and the target resource node corresponding to the resource identification information as the target node, and performs path traversal operation in the permission delegation association graph to obtain multiple candidate node sequences that meet the basic association conditions.

[0023] During the path traversal process, the central path planning module filters out path branches that do not meet the node association conditions based on role association, organizational affiliation, regional affiliation, and service association, and retains path branches that meet the node connectivity conditions.

[0024] After obtaining multiple candidate node sequences, the central path planning module performs path standardization processing on each candidate node sequence to generate a set of candidate permission delegation paths. The path standardization processing includes: merging duplicate nodes in the node sequences; sorting node identifiers according to a unified order rule; generating corresponding path identifier information for each candidate permission delegation path; and recording the set of geographical nodes and resource nodes involved in the candidate permission delegation path.

[0025] In this way, the central path planning module can establish a set of candidate permission delegation paths based solely on the set of non-sensitive attributes without reading the original attribute values ​​of the local sensitive attribute set, thereby providing basic path data for subsequent local feasibility queries and cross-regional constraint evaluation.

[0026] Furthermore, the candidate path generation process in existing cross-regional permission delegation systems typically employs a path expansion traversal mechanism. This means that after discovering a new candidate delegation node, the central side initiates a local feasibility query to the corresponding compliance domain to confirm whether the node meets the local domain policy rules. Since different candidate paths may share the same delegation nodes, resource nodes, or regional nodes, multiple paths are prone to triggering duplicate queries to the same compliance domain during path expansion. In addition, the local query mechanism in existing systems usually lacks unified query triggering constraint rules, preventing the central side from limiting the number of queries, query categories, and information disclosure granularity. On the other hand, since the central side cannot directly obtain the policy status within the local domain, it can only improve the query success rate by adding auxiliary information fields, which further expands the scope of information exposure in cross-domain interactions. These mechanisms collectively lead to increased cross-domain request frequency, increased duplicate disclosures, and increased local proxy load.

[0027] To address this, disclosure control information can be maintained for each candidate permission delegation path. This information constrains the number of triggers and the types of partial feasibility query requests for each compliance domain. Furthermore, the disclosure control information includes disclosure frequency limits and request type limits. The disclosure frequency limits restrict the maximum number of partial feasibility query requests triggered for the same compliance domain, while the request type limits restrict the types of partial feasibility query requests that can be sent to the compliance domain. Then, during the candidate permission delegation path planning process, partial feasibility query requests are filtered and controlled based on the disclosure control information to reduce the number of cross-domain requests and narrow the scope of information disclosure.

[0028] To facilitate understanding, we can use a cross-regional database operation and maintenance authorization scenario of a multinational cloud service company as an example to illustrate the above disclosure control mechanism: This multinational cloud service provider has deployed independent data centers in China, Europe, and Singapore, each with its own independent compliance domain. Each compliance domain has its own local identity directory system, resource allocation management system, and operation and maintenance approval system, and direct sharing of sensitive local data is prohibited between the different compliance domains.

[0029] In this embodiment, User A, an operations and maintenance engineer in the Chinese region, needs to perform database maintenance operations on a data analytics cluster deployed in the European region through the enterprise's unified ITSM platform. Because this database cluster is associated with multiple business systems and is subject to European data compliance rules, the central path planning module cannot directly obtain complete authorization rule information within the European region and needs to perform local feasibility verification through a local planning agent.

[0030] Specifically, upon receiving a permission delegation request from user A, the central path planning module first generates multiple candidate permission delegation paths based on user identification information, organization identification information, regional identification information, resource identification information, and service identification information. For example, the first candidate permission delegation path is "China Region Level 1 Operations and Maintenance Group — Europe Region Database Administrator Group — Target Database Cluster". The second candidate permission delegation path is "China Region Senior Operations and Maintenance Group — Singapore Region Cross-Domain Operations and Maintenance Node — Europe Region Database Administrator Group — Target Database Cluster".

[0031] Since all candidate permission delegation paths involve the European region database administrator group, multiple candidate paths may simultaneously initiate partial feasibility query requests to the European region compliance domain during the subsequent verification phase. Without control over query behavior, the central path planning module may send duplicate query requests to the European region multiple times for the same resource node, the same delegation node, and the same work order type, thus increasing the number of cross-domain communications.

[0032] Based on the above, in this embodiment, after generating candidate permission delegation paths, the central path planning module establishes corresponding disclosure control information for each candidate permission delegation path. This disclosure control information includes disclosure frequency limits and request type limits.

[0033] For example, for the European region compliance domain, the central path planning module sets a maximum of two queries in the current permission delegation task and restricts the first phase to only sending basic feasibility query requests. In this case, when the first candidate permission delegation path needs to verify whether the European region database administrator group has the authorization to perform database maintenance operations, the central path planning module first sends a basic feasibility query request to the European region local planning agent. This basic feasibility query request only includes anonymized subject identifiers, resource category identifiers, and operation category identifiers, and does not carry the user's real identity information, detailed work order content, or business system association information.

[0034] Upon receiving the basic feasibility query request, the European region local planning agent retrieves the set of local sensitive attributes corresponding to the candidate delegate node within the European region and performs constraint evaluation according to local policy rules. For example, within the local domain, the local planning agent confirms whether the current operation involves a restricted dataset, whether the target resource is in a frozen maintenance window, and whether the corresponding work order meets the European region's nighttime maintenance approval requirements. After completing the local constraint evaluation, the European region local planning agent generates a local feasibility proof object and returns the local feasibility status information to the central path planning module.

[0035] After the first candidate permission delegation path is determined to be partially satisfied, the central path planning module continues to evaluate the second candidate permission delegation path. Since the second candidate permission delegation path also involves the European region database administrator group, the system first queries the disclosure control information corresponding to the current path. At this point, the system detects that a basic feasibility query has already been completed for the European region, so it does not send the same type of query request again, but directly reuses the existing local feasibility status results, thereby avoiding repeated cross-domain communication.

[0036] Furthermore, when the central path planning module discovers that the second candidate permission delegation path still requires confirmation of whether the target database allows high-risk structural adjustment operations, since this query is a high-disclosure level query, the central path planning module first checks whether the current number of disclosures has reached the limit. Only when the system confirms that the current number of queries for the European region has not reached the maximum limit will a second partial feasibility query request be sent. This second query request adds a limited range of work order risk level information, but still does not send the complete work order content or the user's real identity information.

[0037] In this way, the central path planning module in this embodiment can dynamically control cross-domain local feasibility query requests during the permission delegation path expansion process, thereby reducing the number of duplicate query requests and reducing the scope of cross-domain auxiliary information disclosure.

[0038] In this embodiment, compared with the traditional scheme that does not adopt disclosure control mechanism, the number of cross-domain local query requests is significantly reduced, the request processing pressure of the European regional local planning agent is reduced, and since high disclosure level query requests are only triggered at necessary stages, the range of data transmitted across domains is significantly reduced, avoiding the spread of a large amount of user-related information and business-related information between different compliance domains.

[0039] Therefore, this embodiment achieves information disclosure control in cross-regional ITSM permission delegation scenarios through a collaborative processing mechanism of candidate path generation, disclosure control establishment, local feasibility query screening, and local verification result reuse, thereby improving the planning efficiency and compliance execution capability of complex cross-regional permission delegation paths.

[0040] S200. For at least one candidate permission delegation path in the candidate permission delegation path set, determine the set of compliance domains involved in the candidate permission delegation path.

[0041] In this embodiment, after establishing a set of candidate permission delegation paths, the central path planning module performs compliance domain identification processing on each candidate permission delegation path to determine the set of compliance domains involved in the candidate permission delegation path.

[0042] Specifically, the central path planning module first reads the set of path nodes in the candidate permission delegation path. The set of path nodes includes at least one of the following: user nodes, role nodes, organization nodes, resource nodes, service nodes, and delegation nodes. Each path node is associated with corresponding geographic identification information and management domain identification information.

[0043] Subsequently, the central path planning module retrieves the corresponding compliance domain identifier information for each path node from the compliance domain mapping table based on the regional identifier information in the path nodes. The compliance domain mapping table records the correspondence between regional identifier information, organization identifier information, resource ownership information, and compliance domain identifier information.

[0044] During the query process, when multiple path nodes correspond to the same compliance domain identifier, the central path planning module merges the duplicate compliance domain identifiers. When path nodes correspond to different compliance domain identifiers, the central path planning module adds the corresponding multiple compliance domain identifiers to the compliance domain set corresponding to the current candidate permission delegation path.

[0045] Furthermore, the central path planning module determines the data residency region information corresponding to the target resource based on the resource node identifier information in the candidate permission delegation path. It then performs supplementary verification on the compliance domain set based on the data residency region information.

[0046] For example, when a user node in a candidate permission delegation path belongs to the China region compliance domain, while the target resource node belongs to the European region compliance domain, the central path planning module will simultaneously write the China region compliance domain identification information and the European region compliance domain identification information into the compliance domain set corresponding to the candidate permission delegation path.

[0047] Furthermore, when there are cross-regional delegation nodes in the candidate permission delegation path, the central path planning module also reads the cross-domain authorization relationship information corresponding to the cross-regional delegation node, and determines whether to add intermediate compliance domain identification information based on the cross-domain authorization relationship information.

[0048] For example, when the candidate permission delegation path includes "China Region Operations and Maintenance Group - Singapore Region Cross-Domain Operations and Maintenance Node - Europe Region Database Administrator Group", the central path planning module, in addition to identifying the China Region compliance domain and the Europe Region compliance domain, also identifies the Singapore Region compliance domain corresponding to the Singapore Region cross-domain operations and maintenance node and adds it to the compliance domain set.

[0049] After completing the compliance domain identification of all path nodes, the central path planning module generates a set of compliance domains corresponding to the candidate permission delegation paths, and establishes the association between the candidate permission delegation path identification information and the set of compliance domains, so that it can be called in the subsequent local feasibility query request generation process.

[0050] S300. For at least one compliance domain in the compliance domain set, generate a local feasibility query request corresponding to the compliance domain.

[0051] In this step, for at least one compliance domain in the compliance domain set, a local feasibility query request corresponding to the compliance domain is generated. The local feasibility query request includes the candidate delegation node identifier, the compliance domain identifier, and non-sensitive auxiliary information related to the candidate delegation node.

[0052] In one possible implementation, after determining the set of compliance domains corresponding to the candidate permission delegation path, the central path planning module generates a corresponding local feasibility query request for at least one compliance domain in the set of compliance domains, so that the local authorization node in the corresponding compliance domain can perform local authorization feasibility verification on the candidate permission delegation path.

[0053] Specifically, the central path planning module first reads the set of candidate delegation nodes in the candidate permission delegation path. The set of candidate delegation nodes includes at least one of the following: user nodes, role nodes, organization nodes, approval nodes, and cross-domain delegation nodes related to the target resource access process.

[0054] Subsequently, the central path planning module assigns the candidate delegated nodes to their corresponding compliance domains based on the regional identifiers and management domain identifiers, and establishes a correspondence between the candidate delegated node identifiers and the compliance domain identifiers.

[0055] Furthermore, the central path planning module extracts non-sensitive auxiliary information related to candidate delegation nodes from the candidate permission delegation paths. This non-sensitive auxiliary information includes at least one of the following: resource type identifier information, operation type identifier information, service order type identifier information, delegation level quantity information, node relationship direction information, valid time interval information, node responsibility classification information, cross-domain access category information, session source region information, and terminal type identifier information.

[0056] During the extraction process, the central path planning module performs hiding processing on information involving identity text, account text, resource address text, and business data content, retaining only the structured identification information used for local authorization judgment.

[0057] For example, when the account information corresponding to the candidate delegate node is "DB_Admin_EU_01", the central path planning module only retains the category identifier information corresponding to the "database administrator account category" and does not retain the account character content.

[0058] Subsequently, the central path planning module generates corresponding partial feasibility query requests based on the compliance domain identification information. Each partial feasibility query request includes: candidate delegation node identification information, compliance domain identification information, non-sensitive auxiliary information related to the candidate delegation node, request flow identification information, path identification information, and request generation time information.

[0059] Furthermore, the central path planning module groups the local feasibility query requests according to the compliance domain identification information and sends them to the local authorized nodes in the corresponding compliance domain.

[0060] For example, when a candidate permission delegation path involves the compliance domains of China, Europe, and Singapore, the central path planning module generates corresponding local feasibility query requests for China, Europe, and Singapore, and sends them to the local authorization nodes in the corresponding regions.

[0061] Furthermore, after generating a local feasibility query request, the central route planning module writes a unique request sequence identifier for each local feasibility query request and establishes a relationship between the request sequence identifier and the route identifier, so as to merge the local authorization feedback results in the future.

[0062] Furthermore, the central path planning module also adds node relationship direction information to the local feasibility query request to indicate the upstream and downstream relationships of the corresponding candidate delegation node in the candidate permission delegation path.

[0063] For example, when the candidate permission delegation path is: regional operation and maintenance group, cross-domain approval node, database administrator node, the local feasibility query request records the node relationship direction information of the regional operation and maintenance group located upstream of the database administrator node, so that the local authorization node can perform local authorization link check based on the node relationship direction information.

[0064] The above method allows structured auxiliary information used for local authorization judgment to be sent to the corresponding compliance domain without transmitting sensitive identity data and business data content, thereby reducing the scope of cross-regional data exposure and improving the efficiency of local authorization verification.

[0065] S400. Send the local feasibility query request to the local planning agent corresponding to the compliance domain. The local planning agent obtains the local sensitive attribute set in the local domain and performs policy constraint evaluation to obtain local feasibility status information.

[0066] Figure 2 This is a schematic flowchart of S400 according to the first example embodiment of this application. Figure 2 As shown, the above S400 includes: S411. After receiving a local feasibility query request, the local planning agent obtains a set of local sensitive attributes from the local domain user directory, the local domain configuration management database, and the local domain work order system based on the candidate delegated node identifier and the compliance domain identifier. The set of local sensitive attributes includes at least one of user sensitive attributes, resource sensitive attributes, and work order sensitive attributes.

[0067] In this embodiment, after receiving a local feasibility query request, the local planning agent first parses the candidate delegation node identifier, compliance domain identifier, path identifier information and request flow identifier information in the local feasibility query request, and determines the corresponding local domain data access range based on the compliance domain identifier.

[0068] Subsequently, the local planning agent initiates local attribute read requests to the local domain user directory, the local domain configuration management database, and the local domain work order system based on the candidate delegate node identifier.

[0069] Specifically, the local domain user directory is used to return user-sensitive attributes corresponding to candidate delegation nodes. The local domain configuration management database is used to return resource-sensitive attributes corresponding to the target resource. The local domain work order system is used to return work order-sensitive attributes corresponding to the current permission delegation request.

[0070] Furthermore, the local planning agent reads at least one of the following user-sensitive attributes from the local domain user directory: user job information, user permission level information, user on-duty status information, user security group information, user historical authorization status information, user authentication status information, and user geographic residency information.

[0071] The local planning agent reads at least one of the following resource sensitive attributes from the local domain configuration management database: resource security level information, information about the business system to which the resource belongs, information about the region where the resource is located, information about the operation and maintenance level of the resource, information about the isolation status of the resource, and information about the organization to which the resource belongs.

[0072] The local planning agent reads at least one of the following work order sensitive attributes in the local domain work order system: work order approval status information, work order risk level information, work order operation time interval information, work order change type information, and work order urgency information.

[0073] Furthermore, during the process of obtaining the local sensitive attribute set, the local planning agent performs unified field mapping processing on attribute information from different data sources to generate a locally sensitive attribute set with consistent structure.

[0074] For example, when both the "personnel level field" in the local domain user directory and the "approval permission field" in the local domain work order system are used to represent the user's authorization level, the local planning agent will map both to "permission level information".

[0075] Furthermore, after the local planning agent completes the acquisition, it generates corresponding attribute set identification information for the local sensitive attribute set and establishes the association between the attribute set identification information and the request pipeline identification information for subsequent local constraint evaluation processes.

[0076] S412. Based on the local domain policy rules, perform constraint evaluation on the local sensitive attribute set to obtain local feasibility status information. The local feasibility status information includes at least one of the following: permitted status information, prohibited status information, and pending status information.

[0077] In this embodiment, after obtaining the local sensitive attribute set, the local planning agent reads the local domain policy rule set corresponding to the current compliant domain from the local domain policy rule base.

[0078] The local domain policy rule set includes at least one of the following: user job constraint rules, user and resource matching constraint rules, work order approval constraint rules, time window constraint rules, regional access constraint rules, operation and maintenance level constraint rules, and high-risk operation restriction rules.

[0079] Subsequently, the local planning agent performs matching and verification on each policy rule in the local policy rule set in turn, based on the attribute information in the local sensitive attribute set.

[0080] For example, when a local policy rule requires that "only users belonging to the database operation and maintenance group and who are on duty are allowed to access core database resources", the local planning agent reads the user's security group information, user duty status information, and resource security level information, and performs the corresponding rule matching process.

[0081] Furthermore, when all policy rules are satisfied, the local planning agent generates an allowed status information. When at least one prohibited policy rule is triggered, the local planning agent generates a prohibited status information. When there are attribute items that cannot be validated or when there are restrictions requiring manual approval, the local planning agent generates a pending status information.

[0082] Furthermore, after generating local feasibility status information, the local planning agent records the strategy rule identification information participating in this constraint evaluation and establishes the association between the local feasibility status information and the strategy rule identification information.

[0083] S413. Based on the local feasibility status information and the policy identification information of the local domain policy rules, generate a local feasibility proof object and sign the local feasibility proof object.

[0084] In this embodiment, after generating local feasibility status information, the local planning agent constructs the corresponding local feasibility proof object.

[0085] Specifically, the objects of local feasibility proof include at least one of the following: candidate delegation node identification information, compliance domain identification information, local feasibility status information, policy identification information, request flow identification information, path identification information, time information, and attribute set identification information.

[0086] Subsequently, the local planning agent combines the information in the local feasibility proof object according to the field order and generates the corresponding proof object summary information.

[0087] Furthermore, the local planning agent invokes the local domain signature component, uses the local domain signature key to perform signature processing on the digest information of the proof object, and obtains the compliance domain signature information.

[0088] Among them, the compliance domain signature information is used to indicate that the local feasibility proof object comes from the corresponding compliance domain, and the content of the local feasibility proof object has not been modified after it is generated.

[0089] Furthermore, the local planning agent writes the compliance domain signature information into the local feasibility proof object and returns the complete local feasibility proof object to the central path planning module.

[0090] For example, after the European region local planning agent completes the evaluation of local constraints for the database access request, it generates a local feasibility proof object containing "permission status information", "European region policy identification information" and "European region signature information" and returns it to the central path planning module for subsequent cross-domain combination evaluation.

[0091] Figure 3 This is a schematic flowchart of S400 according to the second example embodiment of this application. Figure 2 As shown, the above S400 includes: S421. After receiving a local feasibility query request, the local planning agent retrieves the historical operation record information corresponding to the candidate delegated node from the local audit log library based on the candidate delegated node identifier and compliance domain identifier.

[0092] After receiving a local feasibility query request, the local planning agent retrieves historical operation records corresponding to the candidate delegated node from the local audit log database based on the candidate delegated node identifier and compliance domain identifier. First, the local planning agent establishes corresponding log retrieval conditions based on the candidate delegated node identifier and limits the log retrieval scope based on the compliance domain identifier. Then, it reads historical delegated operation records, historical access operation records, and historical approval result records related to the candidate delegated node from the local audit log database. The historical delegated operation records include historical delegated time information, historical delegated target information, and historical delegated resource information; the historical access operation records include historical access resource information, historical access operation type information, and historical access result information; and the historical approval result records include approval status information, approval time information, and approval node information. The local planning agent categorizes and organizes the read historical operation record information in chronological order and establishes a set of historical behavior records corresponding to the candidate delegated node for subsequent consistency comparison processing.

[0093] S422. Based on the consistency comparison between historical operation record information and local domain policy rules, determine whether the candidate delegation node has any historical operation behavior that conflicts with the local domain policy rules.

[0094] The local planning agent reads the resource access restrictions, delegation level restrictions, and approval process restrictions from the local policy rules. Then, it matches historical resource access information in the historical behavior record set with the resource access restrictions, historical delegation target information with the delegation level restrictions, and historical approval result record approval node information with the approval process restrictions. When any historical operation record does not meet the corresponding restriction, the local planning agent generates corresponding conflict identifier information and establishes a correlation between the conflict identifier information and the corresponding historical operation record to identify historical operation behaviors that conflict with the local policy rules.

[0095] S423. When there are no historical operational behaviors that conflict with local domain policy rules, determine the corresponding local feasibility status information as permitted status information. When there are historical operational behaviors that conflict with local domain policy rules, determine the corresponding local feasibility status information as prohibited status information.

[0096] When there are no historical operational behaviors that conflict with local policy rules, the corresponding local feasibility status information is determined as permitted. When there are historical operational behaviors that conflict with local policy rules, the local planning agent determines the corresponding local feasibility status information as prohibited. During this process, the local planning agent counts the number of conflict identifiers in the historical behavior record set. When the number of conflict identifiers is zero, the local feasibility status information is marked as permitted. When the number of conflict identifiers is greater than zero, the local feasibility status information is marked as prohibited. Simultaneously, the local planning agent writes the corresponding conflict identifier information into the status association record for subsequent audit tracing and path review processing.

[0097] S424. Generate a local feasibility proof object based on the local feasibility status information, and sign the local feasibility proof object.

[0098] In the process of generating a local feasibility proof object based on local feasibility status information and signing the local feasibility proof object, the local planning agent writes the candidate delegation node identifier, compliance domain identifier, local feasibility status information, corresponding conflict identifier information, and time information into the local feasibility proof object. Subsequently, the local planning agent performs a signature operation on the object content in the local feasibility proof object according to the local domain signature key and generates the corresponding compliance domain signature information. Finally, the local feasibility proof object containing the compliance domain signature information is returned to the central path planning module for use in subsequent constraint evaluation processing of candidate permission delegation paths.

[0099] To facilitate understanding, let's continue with the example of the global operations and maintenance (O&M) permission management scenario of the aforementioned multinational cloud service company. During an actual O&M operation, the data platform administrator in China needed to perform an emergency fault recovery operation on the database cluster in the European region. Therefore, the administrator initiated a cross-regional permission delegation request to the central O&M management platform. Upon receiving the permission delegation request, the central O&M management platform first generates corresponding candidate permission delegation paths and sends a local feasibility query request to the corresponding local planning agent in the European region. This local feasibility query request includes the candidate delegation node identifier, the target resource identifier, the requesting role identifier, and the corresponding compliance domain identifier.

[0100] Upon receiving a local feasibility query request, the local planning agent in the European region first establishes log retrieval criteria based on the candidate delegation node identifier and then limits the log retrieval scope based on the corresponding compliance domain identifier for the European region. Subsequently, the local planning agent retrieves historical delegation operation records, historical access operation records, and historical approval result records related to the candidate delegation node from the audit log repository deployed within the European region. For example, historical delegation operation records include the administrator's database delegation time information, delegation target information, and involved database resource information for the past three months. Historical access operation records include historical accessed database instances, executed operation types, and corresponding access results. Historical approval result records include approval status, approval time, and approval process node information.

[0101] After reading historical operation records, the local planning agent categorizes and organizes historical delegation operation records, historical access operation records, and historical approval result records in chronological order, and generates a set of historical behavior records corresponding to the candidate delegation node. Subsequently, the local planning agent further reads the currently effective local policy rules within the European region, including database access restrictions, cross-level delegation restrictions, and operation and maintenance approval process restrictions.

[0102] During the consistency comparison process, the local planning agent matches historical access resource information in the historical behavior record set with database access restrictions, historical delegation target information with cross-level delegation restrictions, and approval node information in historical approval result records with approval process restrictions. For example, the local planning agent might discover that an administrator attempted to access unauthorized highly sensitive database resources in historical access records, and that the corresponding approval process lacks security audit node confirmation information. Therefore, it determines that this historical operation conflicts with the current local domain policy rules. Subsequently, the local planning agent generates corresponding conflict identification information and establishes a correlation between the conflict identification information and the corresponding historical operation record.

[0103] After completing the consistency comparison of all historical behaviors, the local planning agent counts the number of conflict identifiers in the historical behavior record set. When the number of conflict identifiers is greater than zero, the local planning agent marks the corresponding local feasibility status information as prohibited. If the number of conflict identifiers is zero, the local feasibility status information is marked as permitted. Simultaneously, the local planning agent writes the corresponding conflict identifier information into the status association record for subsequent audit tracing and path review processing.

[0104] Subsequently, the local planning agent writes the candidate delegation node identifier, European region compliance domain identifier, local feasibility status information, conflict identifier information, and time information into the local feasibility proof object. It then invokes the signature component deployed within the European region, using the local domain signature key to perform a signature operation on the object content within the local feasibility proof object, generating the corresponding compliance domain signature information. Finally, the local planning agent returns the local feasibility proof object containing the compliance domain signature information to the central operations and maintenance management platform.

[0105] Upon receiving the partial feasibility proof from the European region, the central operations and maintenance management platform verifies the signature information and determines whether to continue with the subsequent permission delegation path planning based on the partial feasibility status information. If the partial feasibility status information is prohibited, the central operations and maintenance management platform terminates the current cross-regional permission delegation process. If the partial feasibility status information is permitted, it continues to initiate subsequent partial feasibility query requests to other compliant domains.

[0106] By employing the above methods, cross-regional permission delegation path planning based on historical behavior consistency verification is achieved without directly sharing historical sensitive operation data between different compliance domains. This effectively identifies candidate delegation nodes with historical violations, reduces the risk of cross-domain permission abuse, and improves compliance audit capabilities and the accuracy of permission control during the cross-regional ITSM permission delegation process.

[0107] Figure 4 This is a schematic flowchart of S400 according to the third exemplary embodiment of this application. Figure 2 As shown, the above S400 includes: S431. After receiving a local feasibility query request, the local planning agent retrieves the policy association information corresponding to the candidate delegation node from the local policy mapping table based on the candidate delegation node identifier and compliance domain identifier.

[0108] After receiving a local feasibility query request, the local planning agent retrieves the policy association information corresponding to the candidate delegated node from the local domain policy mapping table based on the candidate delegated node identifier and compliance domain identifier. First, the local planning agent parses the candidate delegated node identifier, role identifier, organization identifier, and resource identifier information from the local feasibility query request. Then, based on the compliance domain identifier, it determines the storage location of the corresponding local domain policy mapping table and performs association query processing on the local domain policy mapping table using the role identifier, organization identifier, and resource identifier information as search conditions. Specifically, the role policy association information includes the correspondence between role identifiers and policy rule identifiers; the resource policy association information includes the correspondence between resource identifiers and resource access restriction rules; and the organization policy association information includes the correspondence between organization identifiers and organization-level compliance rules. The local planning agent then summarizes the multiple policy association records obtained from the query and generates a set of policy association information corresponding to the candidate delegated node.

[0109] S432. Determine the set of local domain policy rules corresponding to the candidate delegation node based on the policy association information, and perform rule conflict detection on the set of local domain policy rules.

[0110] In the process of determining the set of local policy rules corresponding to candidate delegation nodes based on policy association information and performing rule conflict detection on the local policy rule set, the local planning agent reads the policy rule identifier information from the policy association information set and retrieves the corresponding policy rule content from the local policy rule library based on the policy rule identifier information. Subsequently, the local planning agent classifies and organizes the retrieved policy rules according to resource access constraints, delegation level constraints, and approval process constraints. During the rule conflict detection process, the local planning agent compares the allowed operation types, prohibited operation types, resource application scope, and effective time range of multiple policy rules item by item. When both allowed and prohibited operation types for the same resource object are valid, or when the effective time ranges overlap and the constraint results are opposite, a conflicting rule is determined, and corresponding rule conflict identifier information is generated.

[0111] S433. When there are no conflicting rules in the local domain policy rule set, the corresponding local feasibility status information is determined to be permitted status information. When there are conflicting rules in the local domain policy rule set, the corresponding local feasibility status information is determined to be prohibited status information.

[0112] When no conflicting rules exist in the local policy rule set, the corresponding local feasibility status information is determined as permitted. When conflicting rules exist in the local policy rule set, the corresponding local feasibility status information is determined as prohibited. During this process, the local planning agent counts the number of rule conflict identifiers. When the number of rule conflict identifiers is zero, the local feasibility status information is marked as permitted. When the number of rule conflict identifiers is greater than zero, the local feasibility status information is marked as prohibited. Simultaneously, the local planning agent establishes an association record between the corresponding rule conflict identifiers and the conflicting rule identifiers for subsequent path review and compliance audit processing.

[0113] S434. Based on the local feasibility status information and the policy identification information of the local domain policy rule set, generate a local feasibility proof object and sign the local feasibility proof object.

[0114] In the process of generating and signing a local feasibility proof object based on local feasibility status information and policy identification information from the local domain policy rule set, the local planning agent writes the candidate delegation node identifier, compliance domain identifier, local feasibility status information, policy identification information, rule conflict identifier information, and time information into the local feasibility proof object. Subsequently, the local planning agent calls the local domain signature component, uses the local domain signature key to perform a signature operation on the object content in the local feasibility proof object, and generates the corresponding compliance domain signature information. Finally, the local planning agent returns the local feasibility proof object containing the compliance domain signature information to the central path planning module for subsequent constraint evaluation processing of candidate permission delegation paths.

[0115] In another actual operation and maintenance process, the database operations engineer in the China region needed to temporarily handle a database failure in the European region. Therefore, he submitted a cross-regional permission delegation request through the central path planning module. The permission delegation request included the candidate delegation node identifier, the requesting role identifier, the organization identifier, and the target database resource identifier. After receiving the permission delegation request, the central path planning module generated a corresponding local feasibility query request and sent it to the local planning agent deployed within the European region.

[0116] Upon receiving a local feasibility query request, the local planning agent in the European region first parses the candidate delegation node identifier, role identifier, organization identifier, and resource identifier information in the request. Then, based on the corresponding compliance domain identifier for the European region, the local planning agent determines the storage location of the internal policy mapping table for the European region and performs join queries on the local policy mapping table using the role identifier, organization identifier, and resource identifier information as search criteria.

[0117] For example, the local planning agent retrieves the database maintenance policy rule identifier corresponding to the "Advanced Database Operations Role" from the role-policy association record. It retrieves the high-sensitivity resource access restriction rules corresponding to the "Core Transaction Database" from the resource-policy association record. It retrieves the cross-border data access compliance rules corresponding to the "Cross-Regional Operations Department" from the organization-policy association record. Subsequently, the local planning agent summarizes the retrieved role-policy association information, resource-policy association information, and organization-policy association information, and generates a set of policy association information corresponding to the candidate delegation node.

[0118] After generating the policy association information set, the local planning agent reads the corresponding policy rule content from the policy rule repository deployed within the European region, based on the policy rule identifier information in the policy association information. Subsequently, the local planning agent categorizes and organizes the acquired policy rules according to resource access constraints, delegation hierarchy constraints, and approval process constraints. For example, resource access constraints stipulate that only local European database administrators are allowed to access the core transaction database. Delegation hierarchy constraints stipulate that cross-regional operations personnel cannot directly obtain the highest-level database management privileges. Approval process constraints stipulate that the delegation of permissions involving the core database must be approved by both the security audit department and the data compliance department.

[0119] During the rule conflict detection process, the local planning agent compares the allowed and prohibited operation types, resource applicability, and effective time ranges of multiple policy rules item by item. For example, the local planning agent detects that a role policy rule allows a database operations engineer to perform database maintenance operations, while a resource policy rule prohibits non-European local administrators from accessing the core transaction database. Therefore, a situation arises where both allowed and prohibited operation types for the same resource object are valid simultaneously. Furthermore, the local planning agent discovers that the effective time of a temporary operations authorization rule overlaps with the effective time of a long-term access prohibition rule, and their constraint results are opposite, thus confirming a rule conflict. Subsequently, the local planning agent generates corresponding rule conflict identification information and establishes an association record between the rule conflict identification information and the corresponding conflicting rule.

[0120] After completing all rule conflict detection, the local planning agent counts the number of rule conflict identifiers. When the number of rule conflict identifiers is zero, the local planning agent marks the local feasibility status information as permitted. When the number of rule conflict identifiers is greater than zero, the local feasibility status information is marked as prohibited, and the corresponding rule conflict identifier is written into the conflict association record for subsequent path review and compliance audit processing.

[0121] Subsequently, the local planning agent writes the candidate delegation node identifier, European region compliance domain identifier, local feasibility status information, policy identifier information, rule conflict identifier information, and time information into the local feasibility proof object. Then, the local planning agent calls the signature component deployed within the European region, uses the local domain signature key to perform a signature operation on the object content in the local feasibility proof object, generates the corresponding compliance domain signature information, and returns the local feasibility proof object containing the compliance domain signature information to the central path planning module.

[0122] Upon receiving the partial feasibility proof object from the European region, the central path planning module verifies the compliance domain signature information and determines whether to continue the planning process for subsequent candidate permission delegation paths based on the partial feasibility status information. If the partial feasibility status information is prohibited, the central path planning module terminates the current cross-regional permission delegation process. If the partial feasibility status information is permitted, it continues with the generation of subsequent permission delegation paths and resource authorization processing.

[0123] By employing the above methods, without sharing local sensitive policy content and identity attribute data between different compliance domains, policy rule association acquisition, rule conflict detection, and local feasibility proof generation are achieved during cross-regional permission delegation. This effectively identifies constraint conflicts between different policy rules, avoids unauthorized permission delegation due to cross-domain policy inconsistencies, and improves compliance control capabilities, path planning accuracy, and audit traceability during cross-regional ITSM permission delegation.

[0124] In order to address the above Figures 2-4 To further understand the illustrated embodiments, let's compare the three specific implementation methods described above: exist Figure 2In the illustrated embodiment, the local planning agent obtains a set of local sensitive attributes from the local domain user directory, the local domain configuration management database, and the local domain work order system, and performs constraint evaluation based on local domain policy rules to determine the local feasibility status information of candidate delegation nodes. This solution is suitable for ITSM scenarios where permission status strongly depends on real-time identity attributes, resource operating status, and current work order context information, such as core database operation and maintenance authorization, emergency change authorization in the production environment, and high-risk system access control scenarios. In the above scenarios, the permission delegation result is often directly related to the user's current job status, resource sensitivity level, work order approval status, and temporary risk level. Therefore, it is necessary to read the latest attribute information in real time for constraint evaluation during permission delegation. Since this solution directly performs local constraint calculation based on real-time sensitive attribute data, it can promptly identify the permission impact caused by changes in user job status, resource status, and work order approval results, thereby avoiding unauthorized permission delegation problems caused by cached status lag and improving the accuracy of permission control and dynamic risk control capabilities in high-real-time ITSM scenarios.

[0125] Furthermore, Figure 2 The illustrated embodiment completes sensitive attribute reading and constraint evaluation within the local domain, returning only local feasibility status information and local feasibility proof objects to the central path planning module without outputting the original sensitive attribute values. Therefore, it can meet the needs of cross-domain collaborative planning while achieving local isolation of sensitive identity data, resource data, and work order data. The underlying technical reason is that the local planning agent directly calls the existing identity directory system, configuration management database, and work order system within the local domain to perform local correlation evaluation of real-time status data. The central path planning module only receives the evaluation results and does not participate in sensitive data parsing. Therefore, it can maintain real-time constraint judgment capabilities while reducing the risk of sensitive information leakage caused by cross-domain data transmission.

[0126] exist Figure 3 In the illustrated embodiment, the local planning agent does not directly read the current real-time sensitive attribute data. Instead, it obtains historical operation record information corresponding to the candidate delegation nodes through the local domain audit log library and performs local feasibility judgment based on the consistency relationship between the historical operation record information and the local domain policy rules. This solution is suitable for ITSM scenarios with high requirements for the credibility of historical behavior, operational compliance, and long-term risk trends, such as financial industry operation and maintenance audits, government data center access control, and critical infrastructure operation and maintenance behavior review scenarios. In the above scenarios, whether permission delegation is allowed depends not only on the current identity status but also on whether there have been unauthorized access, unauthorized delegation, abnormal approvals, or high-risk resource operation behaviors in the past. Therefore, it is necessary to verify the credibility of candidate delegation nodes through historical behavior trajectories.

[0127] Because this solution performs consistency comparisons based on historical operation records, it can identify candidate delegation nodes whose current identity status is normal but whose historical behavior poses risks. For example, if a candidate delegation node currently has a legitimate position, but has historically frequently engaged in unauthorized access to core resources, bypassed approval processes, or illegally exported cross-regional data, the local planning agent can directly mark the corresponding local feasibility status as prohibited based on historical records in the audit logs, thereby blocking high-risk permission delegation paths. The underlying technical reason is that the local domain audit log library naturally records long-term, continuous operation trajectory information. By performing consistency correlation comparisons between historical behavior records and local domain policy rules, the local planning agent can identify potential violation risks from long-term behavioral patterns. Therefore, this solution is more suitable for ITSM scenarios that emphasize behavioral credibility analysis and long-term compliance supervision.

[0128] exist Figure 4 In the illustrated embodiment, the local planning agent obtains policy association information corresponding to candidate delegation nodes through a local domain policy mapping table, and performs rule conflict detection processing based on multiple policy rule sets to determine local feasibility status information. This solution is suitable for large-scale ITSM collaborative scenarios involving cross-organizational, cross-regional, and multi-policy systems, such as unified operation and maintenance platforms for large group enterprises, multi-cloud hybrid operation and maintenance platforms, and joint operation and maintenance management scenarios for multinational organizations. In the above scenarios, different organizations, different resource types, and different regions often maintain independent policy rule systems, which can easily lead to constraint conflicts between role policies, resource policies, and organizational policies.

[0129] For example, the same candidate delegation node may simultaneously satisfy both the role policy rule of "allowing database maintenance" and the resource policy rule of "prohibiting cross-regional access to core resources". When multiple policy rules apply to the same resource object at the same time, it is easy to generate a conflict between the allowed and prohibited rules. Figure 4 The embodiment shown in the figure summarizes the policy association information in a unified manner within the local planning agent and performs rule conflict detection processing on multiple policy rule sets. This enables potential rule conflicts to be identified in advance before cross-domain path planning, thus avoiding cross-domain logical inconsistencies in the central path planning module during subsequent path combination.

[0130] Furthermore, the underlying technical reason for this solution lies in the fact that the local planning agent establishes multi-dimensional relationships between candidate delegation nodes and role policies, resource policies, and organizational policies through a policy mapping table, and performs cross-comparison of rules within the local domain. Therefore, it can identify logical conflicts between allowed and prohibited rules for the same operation object before the permission path is officially generated. Compared to solutions that simply rely on real-time attribute evaluation or historical behavior analysis, this solution focuses more on the rule coordination capabilities between multiple policy systems, making it more suitable for ITSM collaborative management scenarios with complex rule sources, multi-level organizational structures, and significant cross-domain policy differences.

[0131] In conclusion, Figures 2-4 The embodiments shown correspond to three different technical concepts: real-time attribute constraint evaluation, historical behavior consistency verification, and multi-strategy rule conflict detection. Among them, Figure 2 The illustrated embodiment is more suitable for scenarios that emphasize real-time dynamic access control. Figure 3 The illustrated embodiment is more suitable for scenarios that emphasize long-term behavioral auditing and risk management. Figure 4 The illustrated embodiments are more suitable for scenarios that emphasize multi-policy collaboration and cross-domain rule consistency. The three technical solutions address compliance control issues in cross-domain ITSM permission delegation path planning from three different dimensions: real-time status reliability, historical behavior reliability, and rule system consistency, thereby covering permission planning needs in different ITSM application scenarios.

[0132] S500: Receives the local feasibility proof object returned by the local planning agent.

[0133] Optionally, the aforementioned partial feasibility proof objects include at least one of the following: candidate delegate node identifier, compliance domain identifier, partial feasibility status information, strategy identifier information, time information, and compliance domain signature information, but do not include the original attribute values ​​of the local sensitive attribute set.

[0134] It is worth noting that existing permission delegation systems typically present policy rules as overall logical expressions, lacking independent decomposition and state expression mechanisms between different constraints. This results in policy evaluation results being output only as a single overall state. Furthermore, because sensitive attributes in different compliance domains cannot be directly shared, the central path planning module cannot obtain complete original attribute data for unified calculation, creating a technical contradiction in cross-domain constraint scenarios where these attributes are invisible yet necessary for judgment. Moreover, in the joint evaluation of multiple constraints, logical relationships such as AND and OR exist between different sub-constraints. Without a structured description of the sub-constraint state information, it is impossible to pinpoint the specific source of constraint conflicts or retain intermediate states for unknown states, thus hindering accurate feasibility analysis of cross-domain permission delegation paths.

[0135] To address this, the local feasibility proof object can be configured to include constraint decomposition result information. This information characterizes the evaluation status of multiple sub-constraints. When evaluating local policy rules, the local planning agent decomposes these rules into multiple sub-constraints, generates sub-constraint identifier information for each, and determines the corresponding sub-constraint status information. The sub-constraint status information includes at least one of the following: satisfied status information, unsatisfied status information, and unknown status information. The local feasibility status information in the local feasibility proof object is generated based on the sub-constraint status information of multiple sub-constraints according to preset logical rules.

[0136] Specifically, in the process of implementing the local feasibility proof object, which includes constraint decomposition result information and is used to characterize the evaluation status of multiple sub-constraints, the local planning agent generates a structured constraint decomposition result record after completing the evaluation of the local domain policy rules. This structured constraint decomposition result record includes a sub-constraint identifier field, a sub-constraint category field, a sub-constraint status field, a constraint association field, and a time field. The sub-constraint category field identifies whether the corresponding sub-constraint belongs to a role consistency constraint, a geographical restriction constraint, a resource ownership constraint, a work order approval constraint, or an operation permission constraint. The constraint association field records the logical relationships between multiple sub-constraints. The local planning agent writes the sub-constraint status information corresponding to each sub-constraint into the sub-constraint status field and encapsulates it according to a unified field format to form constraint decomposition result information. This constraint decomposition result information is then written into the local feasibility proof object for cross-domain combination verification by the central path planning module.

[0137] When the local planning agent evaluates constraints on local domain policy rules, it breaks down the local domain policy rules into multiple sub-constraints. For each sub-constraint, it generates sub-constraint identifier information and determines the corresponding sub-constraint status information. The sub-constraint status information includes at least one of the following: satisfied status information, unsatisfied status information, and unknown status information. In this process, the local planning agent first reads the logical expression in the local domain policy rule and breaks it down according to logical connectors. Specifically, when an AND relation is detected, multiple independent sub-constraints are generated; when an OR relation is detected, corresponding sub-constraints are generated for each alternative condition. Then, the local planning agent generates corresponding sub-constraint identifier information based on the sub-constraint content. The sub-constraint identifier information includes the policy number, constraint category number, and sequence number. Afterward, the local planning agent calls the corresponding attribute values ​​from the local domain user directory, the local domain configuration management database, and the local domain work order system to perform condition matching on each sub-constraint. When the condition matching result satisfies the corresponding constraint expression, the corresponding sub-constraint status information is determined to be satisfied. When the condition matching result does not satisfy the corresponding constraint expression, the corresponding sub-constraint status information is determined to be unsatisfied. When a required attribute is missing, an attribute is inaccessible, or the current state cannot be determined, the corresponding sub-constraint state information is set to unknown. Finally, the sub-constraint identifier information and the corresponding sub-constraint state information are written into the local feasibility proof object.

[0138] In the implementation process of generating local feasibility state information in the local feasibility proof object based on the sub-constraint state information of multiple sub-constraints according to logical rules, the local planning agent aggregates and calculates the multiple sub-constraint state information according to the logical connection relationship in the local domain policy rules. Specifically, when multiple sub-constraints are related by AND, an allowed state information is generated only if all sub-constraint state information is satisfied; a prohibited state information is generated if any sub-constraint state information is unsatisfied; and a pending state information is generated if no unsatisfied state information exists and at least one unknown state information exists. When multiple sub-constraints are related by OR, an allowed state information is generated if any satisfied state information exists; a prohibited state information is generated if all sub-constraint state information is unsatisfied; and a pending state information is generated if no satisfied state information exists and at least one unknown state information exists. After obtaining the local feasibility state information, the local planning agent writes the corresponding logical relationship identifier, the sub-constraint identifier information involved in the calculation, and the final local feasibility state information into the local feasibility proof object and generates corresponding signature information.

[0139] Furthermore, due to strict data isolation requirements between cross-regional systems, the central path planning module cannot directly obtain the local sensitive attribute set and complete policy rule set. Therefore, it cannot determine whether the local planning agent has completed constraint evaluation based on the correct data and the correct version of the policy. In addition, in scenarios with dynamic changes in policy rules, real-time changes in attribute states, and multiple repeated evaluations, if there is a lack of verification information that can stably characterize the features of the evaluation input set, it is easy to encounter situations during the audit process where the original evaluation environment cannot be reproduced, policy version deviations cannot be identified, and the consistency of the attribute set cannot be confirmed.

[0140] In response, when generating a local feasibility proof object, the local planning agent can generate summary information for the attribute set and policy rule set used for constraint evaluation. The summary information includes attribute set summary information and policy set summary information. The attribute set summary information characterizes the set characteristics of the local sensitive attribute set used for constraint evaluation, and the policy set summary information characterizes the set characteristics of the local policy rule set participating in this constraint evaluation. The local feasibility proof object further includes attribute set summary information and policy set summary information for verification of the local constraint evaluation process in compliance audit scenarios.

[0141] Specifically, during the generation of a local feasibility proof object by the local planning agent, in the process of generating summary information for the attribute set and policy rule set used for constraint evaluation, after completing the constraint evaluation of the local domain policy rules, the local planning agent first standardizes and organizes the local sensitive attribute set involved in this constraint evaluation. User sensitive attributes, resource sensitive attributes, and work order sensitive attributes from different sources are combined according to a unified field order, and corresponding attribute item sequences are generated according to attribute categories. Subsequently, the local planning agent extracts policy identifier information, policy version information, and rule association order information from the local domain policy rule set involved in this constraint evaluation, and generates corresponding policy sequences. Afterwards, the local planning agent performs character concatenation processing on the attribute item sequences and policy sequences respectively, and generates corresponding attribute set summary information and policy set summary information based on the summary calculation function. Finally, the local planning agent writes the attribute set summary information and policy set summary information into the local feasibility proof object for consistency verification during subsequent cross-domain constraint verification and compliance auditing.

[0142] In the implementation process of the summary information, which includes attribute set summary information and policy set summary information, the attribute set summary information is used to characterize the set characteristics of the local sensitive attribute set used for constraint evaluation, and the policy set summary information is used to characterize the set characteristics of the local policy rule set participating in this constraint evaluation. The generated content of the attribute set summary information includes a combination of attribute item identification information, attribute category information, and attribute status information. The local planning agent generates an attribute set character sequence based on the participation order of each attribute item in this constraint evaluation and performs summary calculation processing on the attribute set character sequence. The generated content of the policy set summary information includes a combination of policy identification information, policy version information, and policy effective time information. The local planning agent generates a policy set character sequence based on the invocation order of each policy rule in this constraint evaluation and performs summary calculation processing on the policy set character sequence. The generated attribute set summary information and policy set summary information each correspond to different summary field identifiers for subsequent classification verification and difference identification in audit scenarios.

[0143] In the implementation process where the local feasibility proof object further includes attribute set summary information and policy set summary information for verification of the local constraint evaluation process in compliance audit scenarios, the local planning agent encapsulates the attribute set summary information, policy set summary information, local feasibility status information, candidate delegation node identifier, compliance domain identifier, and time information in a fixed field order when generating the local feasibility proof object, and generates corresponding signature information. After receiving the local feasibility proof object, the central path planning module stores the attribute set summary information and policy set summary information in the audit record table. When a permission dispute, path review, or compliance check occurs, the central path planning module re-obtains the attribute set and policy rule set under the corresponding time node and re-executes the summary calculation process. If the regenerated summary result is consistent with the summary information in the local feasibility proof object, it is determined that no attribute set tampering or policy rule change occurred during this local constraint evaluation process.

[0144] Furthermore, current permission verification results typically exist only as one-time session results, lacking an intermediate capability representation structure that can be reused across requests. The central path planning module cannot determine whether a subject continuously possesses specific permission capabilities without accessing the original data of sensitive attributes; therefore, it can only re-initiate a local policy evaluation request each time path planning occurs. In addition, policy rules and sensitive attributes in different compliance domains are dynamically changing. Traditional caching mechanisms struggle to distinguish the applicable scope, validity period, and constraints of permission capabilities, easily leading to the erroneous reuse of cached results after they expire, thus affecting the accuracy and compliance of cross-domain permission delegation results.

[0145] In response, while receiving the local feasibility proof object returned by the local planning agent, the system can also receive attribute capability tokens generated by the local planning agent. These attribute capability tokens characterize the subject's permission and capability information under specific constraints. The attribute capability token includes at least one of the following: anonymized subject identifier information, capability identifier information, compliance domain identifier information, scope of application information, validity period information, and policy version information, but does not include the original attribute values ​​of the local sensitive attribute set. The attribute capability token is then stored in the central path planning cache for reuse in subsequent permission delegation path planning processes.

[0146] The capability identifier information corresponds to at least one item in the static capability type set, which is uniformly configured within the compliance domain. When the local planning agent determines that a candidate delegation node conforms to a specific capability type under the current constraints, it generates an attribute capability token with capability identifier information, and records the corresponding compliance domain identifier information, anonymized subject identifier information, and validity period information in the attribute capability token. When the central path planning module plans the path for subsequent permission delegation requests, it matches and verifies the attribute capability token based on the static capability type set and capability identifier information to determine the feasibility status of the candidate delegation node.

[0147] Furthermore, attribute capability tokens include conditional constraint expression information, which is used to limit the scope of application of the attribute capability token. The conditional constraint expression information includes at least one of resource level constraint information, work order risk level constraint information, and operation category constraint information. When using an attribute capability token, the central path planning module performs constraint matching on the conditional constraint expression information based on the resource level information, work order risk level information, and operation category information in the current permission delegation path. If the constraint matching result satisfies the conditional constraint expression information, the attribute capability token is considered valid in the current permission delegation path scenario.

[0148] Furthermore, within the compliance domain, status change events related to attribute capability tokens are monitored. These status change events include at least one of the following: user role change event, user region change event, resource ownership change event, and policy version change event. Upon detecting a status change event, the local planning agent generates a token invalidation notification. This notification includes at least one of the following: attribute capability token identification information, compliance domain identification information, and event type information. After receiving the token invalidation notification, the central path planning module marks the corresponding attribute capability token as invalid and will no longer use it in subsequent permission delegation path planning processes.

[0149] In the above implementation, after the local planning agent completes the constraint evaluation of the local domain policy rules, it converts the subject's corresponding permission capabilities under the current constraints into independently verifiable attribute capability tokens. These tokens record anonymized subject identification information, capability identification information, compliance domain identification information, scope of application information, validity period information, and condition constraint expression information. When the central path planning module receives a new permission delegation request, it first performs condition constraint matching on the cached attribute capability tokens based on the resource level information, work order risk level information, and operation category information in the current permission delegation path. When the matching result satisfies the condition constraint expression information in the attribute capability token and the token is within its validity period, the corresponding candidate delegation node is directly identified as satisfying the local constraint conditions, thereby avoiding re-initiating cross-domain policy evaluation requests. Simultaneously, the compliance domain continuously monitors user role change events, resource ownership change events, and policy version change events. Upon detecting a status change, it generates a token expiration notification, enabling the central path planning module to promptly mark the corresponding attribute capability token as expired, preventing the reuse of expired permission capabilities.

[0150] S600. Based on the local feasibility proof object, perform constraint evaluation on the candidate permission delegation path to determine the target permission delegation path.

[0151] In this step, the candidate permission delegation path can be constrained and evaluated based on the local feasibility proof object to determine the target permission delegation path. The target permission delegation path is used to control the execution of permission delegation requests while satisfying cross-regional compliance constraints.

[0152] Furthermore, in practical applications, permission constraints in different compliance domains typically originate from different business systems and compliance policy frameworks. The relationships between local feasibility results are not simply independent but involve various combinations of logic, such as conditional dependencies, parallel fulfillment relationships, and quantity threshold relationships. If only a single local validation result is stored, lacking a unified structure to express the logical relationships between multiple local results, it becomes impossible to accurately evaluate multi-condition combinations of constraints in complex cross-domain scenarios. Moreover, since the local feasibility states returned by different compliance domains may include multiple states such as permitted, prohibited, and pending, without unified rules for combining and evaluating these states, the central path planning module will struggle to generate stable and consistent overall path feasibility judgment results.

[0153] To address this, when the target permission delegation path involves multiple compliance domains, the central path planning module performs combined evaluation on the local feasibility proof objects returned by multiple compliance domains according to combined constraint rules. These combined constraint rules include at least one of AND rules, OR rules, and threshold rules. Based on these combined constraint rules, the central path planning module synthesizes the local feasibility status information from each local feasibility proof object to obtain the overall feasibility status information of the target permission delegation path. This overall feasibility status information characterizes the constraint satisfaction status of the target permission delegation path at the cross-domain compliance level.

[0154] To facilitate understanding, let's take a cross-regional financial ITSM operations and maintenance scenario as an example. Specifically, a national bank's core business systems are deployed in the Beijing compliance domain, the Shanghai compliance domain, and the Shenzhen disaster recovery compliance domain. During nighttime fault handling, operations and maintenance personnel A submits a temporary high-privilege delegation request for the core database through the ITSM system. The request includes "obtaining database maintenance permissions and performing fault recovery operations within two hours." Because this database is a cross-regional joint regulatory resource, this permission delegation path is simultaneously constrained and controlled by multiple compliance domains. Specifically, the Beijing compliance domain requires the applicant to have headquarters-level database operations and maintenance qualifications. The Shanghai compliance domain requires that the current work order risk level not exceed level three. The Shenzhen disaster recovery compliance domain requires that at least one backup approval domain exists in the disaster recovery state to allow this permission delegation.

[0155] After generating candidate permission delegation paths, the central path planning module sends partial feasibility query requests to the Beijing compliance domain, Shanghai compliance domain, and Shenzhen disaster recovery compliance domain. The partial feasibility status information returned by the Beijing compliance domain is "allowed." The partial feasibility status information returned by the Shanghai compliance domain is "allowed." The Shenzhen disaster recovery compliance domain returns a "pending" status because the backup approval node has not yet been confirmed. Upon receiving the three partial feasibility proof objects, the central path planning module reads the partial feasibility status information and the corresponding compliance domain identifier information, and determines the combined constraint relationships corresponding to this cross-domain permission delegation path.

[0156] In this implementation, the Beijing compliance domain and the Shanghai compliance domain correspond to a mandatory simultaneous fulfillment relationship. Therefore, the central path planning module performs combined evaluation on both using the AND relation rule, meaning that the mandatory compliance condition is only considered met when both local feasibility status information are in an allowed state. Since both the Beijing and Shanghai compliance domains return an allowed state, the central path planning module determines that the mandatory constraint is partially satisfied. Meanwhile, the Shenzhen disaster recovery compliance domain corresponds to a backup approval condition. Therefore, the central path planning module performs supplementary combined evaluation on it using the OR relation rule. As long as the Shenzhen disaster recovery compliance domain subsequently returns to an allowed state or other backup approval domains return to an allowed state, the disaster recovery approval requirement is met.

[0157] In another specific scenario, a multinational manufacturing company's ITSM system needs to perform a unified software upgrade operation on multiple regional production systems. The system requires that the upgrade action be simultaneously approved by at least two regional security audit centers before upgrade permissions can be issued to operations personnel. At this point, the central path planning module receives partial feasibility proof objects from the Guangzhou, Chengdu, and Wuhan compliance domains. The Guangzhou and Chengdu compliance domains return an "allowed" status, while the Wuhan compliance domain returns a "prohibited" status. Based on the threshold relationship rules corresponding to the current path, the central path planning module counts the number of these three partial feasibility statuses. When the number of "allowed" statuses reaches two, it generates overall "allowed" status information and determines that the target permission delegation path meets cross-domain compliance requirements, thus allowing the subsequent software upgrade task to continue.

[0158] In the above implementation process, the central path planning module maintains a combined constraint relationship mapping table. This table records the combined constraint types corresponding to different permission delegation scenarios and the compliance domain identifiers involved in the combined evaluation. Upon receiving multiple local feasibility proof objects, the central path planning module first classifies each local feasibility status information according to the compliance domain identifiers. Then, based on the combined constraint relationship mapping table, it determines the corresponding AND, OR, or threshold relationship rules and performs combined operations on the multiple local feasibility status information. When there are pending states in the local feasibility status information, the central path planning module adds the compliance domain corresponding to the pending state to the supplementary evaluation queue and waits for subsequent state update results. If the number of pending states exceeds the current scenario's allowed threshold, it directly generates overall pending state information, thereby avoiding the erroneous issuance of permissions when compliance conditions are not explicitly met.

[0159] In this way, the central path planning module can perform unified combination and evaluation of local feasibility status information returned by multiple compliance domains in complex cross-regional ITSM permission delegation scenarios, thereby accurately generating overall feasibility status information. This avoids cross-domain logical conflicts caused by the independent processing of local verification results in traditional systems, and improves the accuracy, stability, and cross-domain compliance consistency of permission delegation path planning results.

[0160] Figure 5 This is a schematic flowchart of S600 according to the first example embodiment of this application. Figure 5 As shown, the above-mentioned S600 includes: S611. For each candidate delegation node in the candidate permission delegation path, read the local feasibility status information and compliance domain identifier information in the corresponding local feasibility proof object.

[0161] After receiving local feasibility proof objects from multiple local planning agents, the central path planning module establishes a correspondence between candidate delegation node identifiers and local feasibility proof objects based on the node order in the candidate permission delegation paths. For each candidate delegation node, the central path planning module reads the local feasibility status information and compliance domain identifier information from the corresponding local feasibility proof object and writes the reading results to the path status cache. The path status cache records the candidate permission delegation path identifier, node order identifier, local feasibility status information, and compliance domain identifier information for use in subsequent path combination evaluation processes. This method ensures that the status information of each node in the cross-domain path is managed in a unified order, avoiding errors in path status association due to inconsistent return order.

[0162] S612. According to the node order in the candidate permission delegation path, perform sequential combination and value evaluation of each local feasibility status information.

[0163] When the local feasibility status information corresponding to the current candidate delegation node is read as "allowed," the process continues reading the local feasibility status information corresponding to the next candidate delegation node. When the local feasibility status information corresponding to the current candidate delegation node is read as "pending," the current candidate permission delegation path is marked as a path to be reviewed. When the local feasibility status information corresponding to the current candidate delegation node is read as "prohibited," the subsequent combination evaluation process for the current candidate permission delegation path is terminated. This sequential combination method reduces the subsequent computational overhead of invalid paths and improves the efficiency of cross-domain permission delegation path combination evaluation.

[0164] S613. When any local feasibility status information is prohibited, the corresponding candidate permission delegation path is determined as an infeasible path.

[0165] When the central path planning module detects that the local feasibility status information corresponding to any candidate delegation node is prohibited during the sequential combination evaluation process, it modifies the path status identifier of the current candidate permission delegation path to an infeasible path status and writes the corresponding prohibited node identifier, the time information of the prohibited status generation, and the corresponding compliance domain identifier information into the path result record table. Simultaneously, the central path planning module stops sending additional verification requests to subsequent nodes corresponding to the current candidate permission delegation path. Through this processing method, the invalid path processing process can be terminated in a timely manner when a locally violating node is detected, thereby reducing the number of cross-domain verification requests and lowering path planning resource consumption.

[0166] S614. When all local feasibility status information is allowed, the corresponding candidate permission delegation path is determined as a feasible path.

[0167] After evaluating the sequential combination of all candidate delegation nodes in the current candidate permission delegation path, the central path planning module generates a corresponding feasible path identifier if all corresponding local feasibility status information is allowed, and writes the candidate permission delegation path into the feasible path set. The feasible path set records the candidate permission delegation path identifier, the set of compliance domains involved, node sequence information, and corresponding time information. By establishing a feasible path set, candidate permission delegation paths that meet cross-domain compliance requirements can be managed uniformly, thereby improving the efficiency of subsequent target permission delegation path screening and processing.

[0168] S615. Determine the target permission delegation path from the feasible paths, and perform execution control on the permission delegation request based on the target permission delegation path.

[0169] The central path planning module reads the number of nodes, cross-domain scope, and path generation time information for each feasible path from the feasible path set, and sorts the feasible paths in ascending order of the number of nodes. When multiple feasible paths have the same number of nodes, the feasible path with fewer cross-domain scopes is selected as the target permission delegation path. When the number of cross-domain scopes is still the same, the feasible path with the earliest path generation time is selected as the target permission delegation path. After determining the target permission delegation path, the central path planning module sends permission delegation execution instructions to the corresponding ITSM execution nodes according to the node order in the target permission delegation path, and records the corresponding execution result information. In this way, permission delegation paths with shorter path structures and smaller cross-domain scopes can be selected first, thereby reducing the complexity of cross-domain permission transmission and improving the stability of permission execution.

[0170] Figure 6 This is a schematic flowchart of S600 according to the second example embodiment of this application. Figure 6 As shown, the above-mentioned S600 includes: S621. Extract the strategy identification information, time information, and compliance domain signature information from the local feasibility proof object.

[0171] After receiving local feasibility proof objects from multiple local planning agents, the central path planning module parses and processes each object according to the node order corresponding to the candidate permission delegation paths. It reads policy identification information, time information, and compliance domain signature information from each object and establishes a relationship between the candidate delegation node identifier and the corresponding policy identification information. Simultaneously, the central path planning module writes the read policy identification information, time information, and compliance domain signature information into the path verification cache. The path verification cache includes the candidate permission delegation path identifier, candidate delegation node identifier, policy identification information, time information, and compliance domain signature information for subsequent signature verification and consistency checks. This approach ensures that local feasibility proof objects returned by different compliance domains are managed according to a unified structure, thereby improving the efficiency of cross-domain path verification processing.

[0172] S622. Perform signature verification on the compliance domain signature information and verify the validity of the partial feasibility proof object based on the time information.

[0173] The central path planning module, based on the compliance domain identifier information, reads the signature verification public key information associated with the corresponding compliance domain from the compliance domain certificate store, and uses this public key information to perform signature verification processing on the compliance domain signature information in the local feasibility proof object. When the signature verification result is successful, the central path planning module further reads the time information in the local feasibility proof object and compares it with the current system time. When the time difference is less than the valid duration allowed by the corresponding compliance domain, the corresponding local feasibility proof object is determined to be valid. When the time difference exceeds the valid duration allowed by the corresponding compliance domain, the corresponding local feasibility proof object is marked as invalid. Through this processing method, the local feasibility proof object can be prevented from being tampered with during transmission, and the risk of invalid proof objects participating in cross-domain path planning can be reduced.

[0174] S623. When the signature verification passes and the time information is within the validity period, perform a consistency check on the local feasibility proof objects involved in each candidate permission delegation path based on the policy identification information.

[0175] The central path planning module reads the corresponding policy identification information for multiple local feasibility proof objects within the same candidate permission delegation path, and verifies the compatibility between these policy identification information based on the policy mapping table. When there are no conflicts between the policy identification information corresponding to multiple local feasibility proof objects, the corresponding local feasibility proof object passes the consistency check. When there are conflicts between the policy identification information corresponding to multiple local feasibility proof objects, the corresponding candidate permission delegation path is marked as a policy conflict path, and subsequent path filtering for that candidate permission delegation path is stopped. This approach reduces the risk of unauthorized permission delegation when there are conflicts between policy rules in different compliance domains.

[0176] S624. When the policy identification information corresponding to each local feasibility proof object in the same candidate permission delegation path meets the policy compatibility condition, and the corresponding local feasibility status information does not include the prohibition status information, the corresponding candidate permission delegation path is determined as the target permission delegation path.

[0177] After completing the consistency check of all local feasibility proof objects corresponding to the same candidate permission delegation path, the central path planning module further reads the local feasibility status information of each local feasibility proof object. When all local feasibility status information is either allowed or pending, and the corresponding policy identification information meets the policy compatibility conditions, the central path planning module generates the corresponding target permission delegation path identification information and writes the corresponding candidate permission delegation path into the target path record table. The target path record table includes the target permission delegation path identifier, the set of compliance domains involved, the set of policy identification information, path generation time information, and path status information. Through this processing method, target permission delegation paths that meet compliance requirements can be selected while ensuring cross-domain policy compatibility.

[0178] Figure 7 This is a schematic flowchart of S600 according to the third exemplary embodiment of this application. Figure 7 As shown, the above-mentioned S600 includes: S631. Obtain constraint decomposition result information from multiple local feasibility proof objects corresponding to the candidate permission delegation path.

[0179] After receiving multiple local feasibility proof objects returned by local planning agents, the central path planning module parses and processes each local feasibility proof object according to the node order corresponding to the candidate permission delegation paths. It reads constraint decomposition result information, sub-constraint identifier information, and corresponding sub-constraint status information from each local feasibility proof object, and establishes the association between candidate delegation nodes and corresponding sub-constraints based on the candidate delegation node identifier. Simultaneously, the central path planning module writes the read constraint decomposition result information into a cross-domain constraint cache, which includes candidate permission delegation path identifiers, candidate delegation node identifiers, sub-constraint identifier information, sub-constraint status information, and compliance domain identifier information, for subsequent cross-domain combination evaluation processing. Through this method, the constraint decomposition result information returned by different compliance domains can be managed in a unified and structured manner.

[0180] S632. Based on the constraint decomposition results, determine the status information of multiple sub-constraints corresponding to each candidate permission delegation path.

[0181] The central path planning module aggregates multiple constraint decomposition results from the cross-domain constraint cache based on the candidate delegation node identifiers corresponding to the same candidate permission delegation path, and reads the sub-constraint status information corresponding to each sub-constraint identifier. When multiple local feasibility proof objects contain the same sub-constraint identifier information, the central path planning module categorizes the corresponding sub-constraint status information according to the compliance domain identifier information. When there are inconsistencies among multiple sub-constraint status information, the central path planning module marks the corresponding sub-constraint identifier information as conflicting sub-constraint identifier information. Through the above processing method, the constraint differences between different compliance domains can be identified, improving the accuracy of cross-domain constraint analysis.

[0182] S633. Based on the multiple compliance domains involved in the candidate permission delegation path, perform cross-domain combination evaluation of multiple sub-constraint status information.

[0183] The central path planning module performs sequential combination processing on multiple sub-constraint status information based on the order of compliance domains involved in the candidate permission delegation path. For multiple sub-constraint status information corresponding to the same sub-constraint identifier, when all sub-constraint status information corresponding to each compliance domain is satisfied, the central path planning module determines the cross-domain combination result of the corresponding sub-constraint as satisfied. When at least one sub-constraint status information is unsatisfied, the cross-domain combination result of the corresponding sub-constraint is determined as unsatisfied. When there is no unsatisfied status information and at least one unknown status information, the cross-domain combination result of the corresponding sub-constraint is determined as unknown. Subsequently, the central path planning module writes the cross-domain combination results of each sub-constraint into the combination evaluation result table, which includes the candidate permission delegation path identifier, sub-constraint identifier information, cross-domain combination result information, and combination time information. Through the above method, joint constraint evaluation processing among multiple compliance domains can be achieved.

[0184] S634. When the sub-constraint status information corresponding to each compliance domain includes the satisfying status information, determine that the corresponding candidate permission delegation path satisfies the cross-domain constraint condition.

[0185] The central path planning module reads all cross-domain combination results for the same candidate permission delegation path and counts the number of sub-constraints in a satisfied state. When all cross-domain combination results for all sub-constraints are satisfied, the central path planning module generates corresponding cross-domain constraint satisfaction identifiers and marks the corresponding candidate permission delegation path as a candidate path that satisfies the cross-domain constraint conditions. Simultaneously, the central path planning module writes the corresponding candidate permission delegation path into the cross-domain feasible path record table, which includes the candidate permission delegation path identifier, satisfaction status information, the set of compliance domains involved, and generation time information. Through this processing method, permission delegation paths that satisfy all cross-domain constraints can be selected.

[0186] S635. When there is at least one sub-constraint state information that is not satisfied, determine that the corresponding candidate permission delegation path does not satisfy the cross-domain constraint condition.

[0187] When the central path planning module reads the cross-domain combination result information from the combination evaluation result table, if it detects that the cross-domain combination result corresponding to any sub-constraint is not satisfied, it immediately stops the subsequent combination evaluation processing of the current candidate permission delegation path and generates the corresponding cross-domain constraint failure flag. Simultaneously, the central path planning module writes the corresponding candidate permission delegation path into the cross-domain infeasible path record table. The cross-domain infeasible path record table includes the candidate permission delegation path identifier, the sub-constraint identifier information corresponding to the unsatisfied state, the involved compliance domain identifier information, and the failure time information. Through this method, the system resource consumption caused by candidate permission delegation paths that do not meet the cross-domain constraint conditions continuing to participate in the path selection process can be reduced.

[0188] S636. Determine the target permission delegation path from the candidate permission delegation paths that meet the cross-domain constraint conditions.

[0189] The central path planning module reads multiple candidate permission delegation paths that meet cross-domain constraints from the cross-domain feasible path record table, and performs path filtering based on the path length, number of compliant domains, and path generation time of each candidate permission delegation path. When multiple candidate permission delegation paths meet the cross-domain constraints, the central path planning module prioritizes the candidate permission delegation path with the shorter path length and fewer compliant domains as the target permission delegation path, and generates corresponding target path identifier information. Subsequently, the central path planning module writes the corresponding target permission delegation path into the target path record table, which includes target path identifier information, candidate permission delegation path identifier, path status information, and target path generation time information. Through this processing method, the efficiency of cross-domain permission delegation path planning can be improved and the complexity of cross-domain processing can be reduced.

[0190] Continuing with the example of the globally unified ITSM operations and maintenance management scenario of the aforementioned multinational cloud service companies, in Figure 5In the illustrated embodiment, the central path planning module performs sequential combination evaluation based solely on the local feasibility status information returned by each compliance domain. For example, when headquarters needs to temporarily grant a global operations engineer database maintenance permissions for the China region and log audit permissions for the Singapore region, the local planning agent for the China region returns "Allow" status information, and the local planning agent for the Singapore region also returns "Allow" status information. The central path planning module directly completes the status combination according to the path order and generates the corresponding target permission delegation path. Since this solution does not require further parsing of fine-grained constraint information within each region, nor does it require performing complex cross-domain constraint aggregation processing, it is more suitable for routine standardized operations and maintenance approvals, batch work order authorizations, and high-concurrency temporary permission granting scenarios. In the above scenarios, this solution can reduce the computational processing steps of the central path planning module, reduce cross-domain status aggregation overhead, and shorten the permission delegation path generation time, thereby improving the real-time response capability and large-scale concurrent processing efficiency in the cross-regional ITSM permission delegation process.

[0191] exist Figure 6 In the illustrated embodiment, each compliance domain, when returning a partial feasibility proof object, also includes the corresponding compliance domain signature information, policy identifier information, and time information. Before generating the target permission delegation path, the central path planning module performs signature verification, time validity verification, and policy consistency checks on each partial feasibility proof object. For example, when the headquarters security audit department needs to grant data recovery permissions to multiple regions for a cross-regional security emergency response team, the China region, the European region, and the Singapore region each perform signature processing on the partial feasibility proof objects generated in their respective regions. After receiving the corresponding proof objects, the central path planning module verifies the signature information of each region and checks whether the current permission policy versions used by each region are consistent. If it is found that the policy identifier information returned by the European region is inconsistent with other regions, the central path planning module terminates the generation of this permission delegation path. Because this solution can verify the authenticity of the source of the partial feasibility proof object and prevent different versions of policy rules from being mixed in path planning, it is more suitable for scenarios involving regulatory audits, critical business system operation and maintenance, and high-security-level permission control. In the above scenarios, this solution can improve the trusted verification capability, audit traceability capability, and cross-domain policy execution consistency in the cross-regional permission delegation process.

[0192] exist Figure 6In the illustrated embodiment, each compliance domain not only returns overall and local feasibility status information but also further returns constraint decomposition result information. The central path planning module performs cross-domain combination evaluation based on multiple sub-constraint status information. For example, when headquarters needs to grant joint operation and maintenance permissions to a global database operation and maintenance team involving customer databases in the China region, backup nodes in the Singapore region, and log analysis platforms in the European region, the China region requires operators to have local data security qualifications, the Singapore region requires the current access time to be within the authorized maintenance window, and the European region requires the access terminal to be located in a dedicated enterprise network environment. Each regional local planning agent decomposes the above constraints into multiple sub-constraint status information and returns them to the central path planning module. After performing unified aggregation processing on the sub-constraint results returned by multiple regions, the central path planning module finds that the current operating terminal does not meet the network access constraints in the European region, and therefore terminates the corresponding permission delegation path. Because this solution can perform unified analysis and conflict identification on fine-grained constraints in different regions, it is more suitable for joint operation and maintenance of multiple regulatory regions, collaborative management of multi-cloud hybrid environments, and complex cross-domain compliance control scenarios. In the above scenarios, this solution can improve the ability to identify constraints, locate conflicts, and conduct cross-regional joint compliance analysis in the process of complex cross-domain permission delegation.

[0193] Furthermore, within the same multinational cloud service enterprise scenario, Figure 5 The illustrated embodiment is more suitable for standardized permission delegation services that emphasize real-time response efficiency and high concurrency processing capabilities. Figure 6 The illustrated embodiment is more suitable for high-security operations and maintenance businesses that emphasize trusted auditing, policy consistency, and traceability of permissions. Figure 7 The illustrated embodiments are more suitable for global collaborative operations and maintenance businesses that emphasize joint analysis of complex constraints and cross-regional compliance control capabilities. Therefore, the three parallel technical solutions can respectively meet the performance optimization requirements, trust control requirements, and complex compliance analysis requirements corresponding to different business objectives in the same cross-domain ITSM permission delegation scenario.

[0194] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0195] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A permission delegation path planning method for ITSM, characterized in that, include: Upon receiving a permission delegation request, a set of candidate permission delegation paths is established based on a set of non-sensitive attributes. For at least one candidate permission delegation path in the candidate permission delegation path set, determine the set of compliance domains involved in the candidate permission delegation path; For at least one compliance domain in the set of compliance domains, generate a local feasibility query request corresponding to the compliance domain; The local feasibility query request is sent to the local planning agent corresponding to the compliance domain. The local planning agent obtains the local sensitive attribute set within the local domain and performs policy constraint evaluation to obtain local feasibility status information. The system receives a local feasibility proof object returned by the local planning agent, and performs constraint evaluation on the candidate permission delegation path based on the local feasibility proof object to determine the target permission delegation path. The target permission delegation path is used to perform execution control on the permission delegation request while satisfying cross-regional compliance constraints.

2. The method according to claim 1, characterized in that, The local planning agent obtains a set of locally sensitive attributes within the local domain and performs policy constraint evaluation, including: Obtain the set of local sensitive attributes based on the candidate delegation node identifier and the compliance domain identifier; Based on the local domain policy rules, the set of local sensitive attributes is constrained and evaluated to obtain local feasibility status information; Based on the local feasibility status information and the policy identification information of the local domain policy rules, a local feasibility proof object is generated and the local feasibility proof object is signed.

3. The method according to claim 1, characterized in that, The local planning agent obtains a set of locally sensitive attributes within the local domain and performs policy constraint evaluation, including: Obtain historical operation record information corresponding to the candidate delegation node based on the candidate delegation node identifier and compliance domain identifier; Based on the consistency comparison between the historical operation record information and the local domain policy rules, it is determined whether the candidate delegation node has any historical operation behavior that conflicts with the local domain policy rules. When there are no historical operational behaviors that conflict with the local domain policy rules, the corresponding local feasibility status information is determined to be allowed status information; when there are historical operational behaviors that conflict with the local domain policy rules, the corresponding local feasibility status information is determined to be prohibited status information. A local feasibility proof object is generated based on the local feasibility status information, and the local feasibility proof object is signed.

4. The method according to claim 1, characterized in that, The local planning agent obtains a set of locally sensitive attributes within the local domain and performs policy constraint evaluation, including: Obtain the policy association information corresponding to the candidate delegation node based on the candidate delegation node identifier and compliance domain identifier; Based on the policy association information, determine the set of local domain policy rules corresponding to the candidate delegation node, and perform rule conflict detection on the set of local domain policy rules; When there are no conflicting rules in the local domain policy rule set, the corresponding local feasibility status information is determined to be allowed status information; when there are conflicting rules in the local domain policy rule set, the corresponding local feasibility status information is determined to be prohibited status information. Based on the local feasibility status information and the policy identification information of the local domain policy rule set, a local feasibility proof object is generated and the local feasibility proof object is signed.

5. The method according to claim 1, characterized in that, The local feasibility proof object includes constraint decomposition result information, which is used to characterize the evaluation state of multiple sub-constraints. When evaluating the constraints of the local domain policy rules, the local planning agent breaks down the local domain policy rules into multiple sub-constraints, generates sub-constraint identification information for each sub-constraint, and determines the corresponding sub-constraint status information.

6. The method according to claim 1, characterized in that, When generating a local feasibility proof object, the local planning agent generates summary information for the attribute set and strategy rule set used for constraint evaluation.

7. The method according to claim 1, characterized in that, The method further includes: Upon receiving the local feasibility proof object returned by the local planning agent, the system also receives the attribute capability token generated by the local planning agent. The attribute capability token is used to characterize the subject's permission capability information under specific constraints, and the attribute capability token is stored in the central path planning cache.

8. The method according to claim 7, characterized in that, The attribute capability token includes capability identification information, which corresponds to at least one item in a static capability type set. Generate an attribute capability token containing the capability identification information; When planning the path for subsequent permission delegation requests, the attribute capability token is matched and verified based on the static capability type set and the capability identifier information to determine the feasibility status of the candidate delegation node.

9. The method according to claim 7, characterized in that, The attribute capability token includes condition constraint expression information, which is used to limit the scope of application of the attribute capability token.

10. The method according to claim 7, characterized in that, The method further includes: Listen for state change events related to attribute capability tokens within the compliance domain; Upon detecting the state change event, the local planning agent generates a token expiration notification; Upon receiving the token expiration notification, the central path planning module marks the corresponding attribute capability token as expired.

11. The method according to claim 1, characterized in that, The method further includes: Disclosure control information is maintained for each candidate permission delegation path, and during the candidate permission delegation path planning process, the local feasibility query requests are screened and controlled based on the disclosure control information.

12. The method according to claim 1, characterized in that, The step of constraining and evaluating the candidate permission delegation paths based on the local feasibility proof object to determine the target permission delegation path includes: For each candidate delegation node in the candidate permission delegation path, read the local feasibility status information and compliance domain identifier information from the corresponding local feasibility proof object; According to the node order in the candidate permission delegation path, the local feasibility status information is sequentially combined and evaluated. If any local feasibility status information is prohibited, the corresponding candidate permission delegation path will be determined as an infeasible path. When all local feasibility status information is in the allowed state, the corresponding candidate permission delegation path is determined as a feasible path; The target permission delegation path is determined from the feasible paths, and the permission delegation request is executed and controlled based on the target permission delegation path.

13. The method according to claim 1, characterized in that, The step of constraining and evaluating the candidate permission delegation paths based on the local feasibility proof object to determine the target permission delegation path includes: Extract the policy identification information, time information, and compliance domain signature information from the local feasibility proof object; The signature information of the compliance domain is verified, and the validity of the partial feasibility proof object is verified based on the time information. When the signature verification passes and the time information is within the validity period, a consistency check is performed on the local feasibility proof objects involved in each candidate permission delegation path based on the policy identification information. When the policy identification information corresponding to each local feasibility proof object in the same candidate permission delegation path meets the policy compatibility condition, and the corresponding local feasibility status information does not include prohibited status information, the corresponding candidate permission delegation path is determined as the target permission delegation path.

14. The method according to claim 1, characterized in that, The step of constraining and evaluating the candidate permission delegation paths based on the local feasibility proof object to determine the target permission delegation path includes: Obtain constraint decomposition result information from multiple local feasibility proof objects corresponding to the candidate permission delegation path, and determine multiple sub-constraint status information corresponding to each candidate permission delegation path based on the constraint decomposition result information. Based on the multiple compliance domains involved in the candidate permission delegation path, the multiple sub-constraint status information is evaluated by cross-domain combination. When the sub-constraint status information corresponding to each compliance domain includes the satisfying status information, the corresponding candidate permission delegation path is determined to satisfy the cross-domain constraint condition. When there is at least one sub-constraint state information that is not satisfied, it is determined that the corresponding candidate permission delegation path does not meet the cross-domain constraint condition. The target permission delegation path is determined from the candidate permission delegation paths that meet the cross-domain constraints.

15. The method according to claim 1, characterized in that, When the target permission delegation path involves multiple compliance domains, the partial feasibility proof objects returned by the multiple compliance domains are evaluated in combination according to the combination constraint rules. Based on the combined constraint rules, the local feasibility status information of each local feasibility proof object is synthesized to obtain the overall feasibility status information of the target permission delegation path.

Images