A network security service scheduling method and system based on constraint loop weaving

Abstract

The application discloses a network security service scheduling method and system based on constraint loop weaving. By acquiring multi-type constraint factor data associated with a security service request, generating constraint identification data representing constraint permission relationships and constraint blocking relationships, constructing a constraint loop network and generating loop hanging state data, further identifying constraint blocking paths, determining rigid loops and reconstructable loops, executing loop bypass scheduling, closed path reconstruction and closed state updating, and after the execution of a target service action, re-annotating and weaving new constraint factors to form scheduling constraint data for the next service stage, the continuity, controllability and engineering adaptability of security service scheduling in a complex constraint environment are improved.

Description

Technical Field

[0001] This application relates to the field of network security service scheduling and security control technology, and in particular to a network security service scheduling method and system based on constraint loop weaving. Background Technology

[0002] With the continuous development of government and enterprise networks, cloud computing environments, industrial control networks, and hybrid business networks, the targets, scope, and constraints of cybersecurity services are constantly expanding. Security services are no longer limited to a single policy issuance or a single action, but rather manifest as a continuous sequence of service actions organized around specific security objectives. In actual deployment, the advancement of security services is often simultaneously influenced by multiple factors, including business continuity requirements, system change boundaries, account permission boundaries, compliance requirements, operational window limitations, customer authorization conditions, and resource usage limits. How to orderly schedule and continuously advance security services under multiple constraints has become a crucial technical requirement for the effective implementation of cybersecurity services.

[0003] In practice, the scheduling and control of network security services are typically handled through rule verification, work order workflow, or sequential orchestration. These solutions generally assess approval status, authorization status, execution time, permission scope, resource availability, and rollback conditions before executing a security service action. If a condition is met, the corresponding action is allowed; if a condition is not met, the current action is paused or execution is resumed after external conditions change. This approach often attaches constraint information from different sources as independent conditions before each service action, using static verification results as the basis for action approval. The progression between service actions relies primarily on a preset order or fixed orchestration links.

[0004] However, treating multiple constraint factors as static ancillary conditions for isolated verification makes it difficult to uniformly organize and dynamically control the dependency relationships, blocking and propagation relationships, and closure and triggering relationships between constraints. When multiple constraint factors act simultaneously on multiple service actions and create cross-effects during service execution, existing methods typically cannot identify the propagation effect of a local blockage on subsequent service actions, nor can they structurally reconstruct and continuously advance the blocked service action sequence while maintaining the business continuity boundaries, permission boundaries, and recovery conditions. Furthermore, existing methods struggle to promptly incorporate new scope changes, permission occupancy, resource occupancy, and rollback constraints that arise after the actual execution of service actions into subsequent scheduling links for continued control. This makes it difficult to continuously and controllably advance network security services under complex constraint environments. Summary of the Invention

[0005] In view of the above-mentioned actual situation, this application proposes a network security service scheduling method and system based on constraint loop weaving to solve the technical problem in the prior art that multiple types of constraint factors are isolated and verified as static auxiliary conditions, making it difficult to uniformly organize and dynamically control the dependency and restriction relationships, blocking and transmission relationships and closure triggering relationships between constraints, thus making it difficult for network security services to be continuously and controllably promoted in complex constraint environments.

[0006] A network security service scheduling method based on constraint loop weaving includes:

[0007] Obtain the security service request corresponding to the target network environment and the constraint factor data associated with the security service request. The constraint factor data includes business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data. Perform constraint classification processing and constraint relationship parsing processing on the constraint factor data to generate first constraint identifier data representing constraint permission relationship and second constraint identifier data representing constraint blocking relationship, respectively.

[0008] Based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request, a constraint loop network is constructed. The constraint loop network is used to characterize the connection relationship between multiple constraint factors and each service action, as well as the dependency restriction relationship, blocking transmission relationship, and closure trigger relationship formed by each service action under the action of multiple constraint factors. According to the constraint loop network, loop connection status data corresponding to each service action is generated. The loop connection status data is used to characterize whether the current service action is in an executable state, a blocked state, or a bypassable state.

[0009] The constraint loop network is processed to locate loop conflicts, identify constraint blocking paths that block the current service advancement, and determine whether the release conditions of the corresponding constraint loop can be achieved by service action rearrangement, execution order adjustment, or insertion of additional verification actions, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions. The loop attributes of each constraint loop in the constraint loop network are determined, generating rigid loop data and reconfigurable loop data. Based on the rigid loop data, the reconfigurable loop data, and the loop attachment status data, service advancement blocking data is generated.

[0010] In response to the service advancement blocking data, loop bypass scheduling processing is performed on the rigid loop data and the reconfigurable loop data. The loop bypass scheduling processing includes one or more of the following: alternative service action insertion processing, service action segmentation and orchestration processing, pre-verification action pre-processing, and local scope advance processing, so as to reconstruct the loop closure path corresponding to the original service action sequence without breaking the rigid loop release condition, generate bypass scheduling sequence data, and update the constraint loop network based on the bypass scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service stage.

[0011] When the closed loop state data indicates that the target service action meets the execution conditions, the corresponding network security service action is executed, and the newly added constraint factors generated after the execution of the network security service action are back-injected and woven to attach the newly added constraint factors to the constraint loop network corresponding to the subsequent service action, thereby generating the scheduling constraint data for the next service stage, so that the subsequent service stage can continue to enter the scheduling and advancement process under the constraints of the updated constraint loop network.

[0012] Furthermore, the constraint factor data undergoes constraint classification and constraint relationship parsing processing to generate first constraint identifier data and second constraint identifier data representing constraint permission relationships and constraint blocking relationships, respectively, including:

[0013] The constraint factor data is classified and mapped according to the constraint source attribute, constraint action stage attribute, and constraint release dependency attribute to generate constraint category index data;

[0014] Based on the constraint category index data, identify the permission and blocking conditions for each constraint factor on the corresponding service action, and generate constraint action pointing data;

[0015] Based on the constraint action pointing data, the constraint relationship that allows the corresponding service action to enter the execution orchestration is encoded to generate the first constraint identifier data, and the constraint relationship that restricts the corresponding service action from entering the execution orchestration is encoded to generate the second constraint identifier data.

[0016] Furthermore, the step of constructing a constraint loop network based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request includes:

[0017] Obtain the pre-execution conditions, subsequent influence conditions, and rollback verification conditions corresponding to each service action in the service action sequence;

[0018] Based on the first constraint identification data and the second constraint identification data, each constraint factor is attached to the pre-execution condition, subsequent influence condition and rollback verification condition of the corresponding service action to generate an action constraint attachment diagram.

[0019] The action constraint connection diagram contains multiple service actions and their corresponding constraint factors that have interdependent, mutually blocking, or sequential constraints. Loop weaving is performed to generate a constraint loop network including loop entry segment, loop blocking segment, loop bypass segment, and loop closure segment.

[0020] Furthermore, the step of generating loop connection status data corresponding to each service action based on the constraint loop network includes:

[0021] The closure condition analysis is performed on each constraint loop in the constraint loop network to obtain the permissive closure condition and the blocking closure condition corresponding to each constraint loop;

[0022] Based on the attachment position of each service action in the constrained loop network, the type of the loop segment to which it belongs, the number of times it is blocked, and the availability of alternative closed paths, determine the state judgment parameters corresponding to each service action.

[0023] Based on the permission closure condition, the blocking closure condition, and the state determination parameters, the loop connection status data representing whether the current service action is in an executable state, a blocked state, or a loopable state is generated.

[0024] Furthermore, the process of performing loop conflict localization processing on the constraint loop network, identifying constraint blocking paths that obstruct the current service advancement, and determining the loop attributes of each constraint loop in the constraint loop network to generate rigid loop data and reconfigurable loop data includes:

[0025] Perform blocking propagation tracing processing on each constraint loop in the constraint loop network to determine the loop start blocking point, blocking transmission node, blocking convergence node and loop exit node that cause the current service action to be unable to proceed, and generate constraint blocking path data.

[0026] Based on whether the release conditions corresponding to each constraint loop depend on external approval completion, customer authorization completion, permission change effect, compliance confirmation completion, or rollback verification pass, rigidity determination is performed on each constraint loop to generate the rigid loop data.

[0027] Based on whether the release conditions corresponding to each constraint loop can be satisfied by service action rearrangement, execution scope contraction, pre-verification insertion, or partial replacement execution, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions, the reconfigurable loop data is generated.

[0028] Furthermore, in response to the service advance blocking data, the rigid loop data and the reconfigurable loop data are subjected to loop reconnection scheduling processing to generate loop reconnection scheduling sequence data, including:

[0029] When the constraint loop that blocks the current service advancement is a rigid loop, based on the blocking convergence node and loop exit node corresponding to the rigid loop, insert a pre-verification service action or an approval connection service action to satisfy the release condition.

[0030] When the constraint loop that blocks the current service advancement is a reconfigurable loop, based on the loop bypass segment and alternative closed path corresponding to the reconfigurable loop, the original service action sequence is processed by alternative service action insertion, service action segmentation and arrangement, or local scope advance processing.

[0031] The inserted service action sequence is subjected to stage connectivity verification, permission boundary preservation verification, and rollback recoverability verification to generate the bypass scheduling sequence data.

[0032] Furthermore, updating the constraint loop network based on the bypass scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service phase includes:

[0033] Based on the connection relationship between the newly added service actions, split service actions, and replacement service actions and the original service actions in the bypass scheduling sequence data, the action constraint connection relationship of the subsequent service stage is reconstructed.

[0034] The reconstructed action constraint connection relationship is subjected to closed-loop simulation processing to determine the closing sequence, blocking release sequence, and service release sequence of each constraint loop under the bypass scheduling sequence.

[0035] Based on the closing sequence, the blocking release sequence, and the service release sequence, the loop closure status data corresponding to the subsequent service phase is generated.

[0036] Furthermore, the step of executing the corresponding network security service action when the closed loop state data characterizes the target service action as meeting the execution conditions includes:

[0037] When the permission closure condition corresponding to the target service action has been met and the blocking closure condition corresponding to the target service action has been released, the target service action is triggered to enter the execution phase.

[0038] During the execution of the target service action, the execution feedback data and environmental constraint change data corresponding to the target service action are obtained, and constraint backflow determination is performed on the execution feedback data and the environmental constraint change data.

[0039] When the constraint backflow determination result indicates that a new blocking relationship or a new restriction relationship has been formed in the current execution stage, the advancement of subsequent unexecuted service actions is suspended, and the current execution stage is switched to the loop reweaving processing stage.

[0040] Furthermore, the back-injection weaving process performed on the newly added constraint factors generated after the execution of the network security service action, in order to attach the newly added constraint factors to the constraint loop network corresponding to subsequent service actions, and generate scheduling constraint data for the next service phase, includes:

[0041] Identify the scope change information, permission occupation information, resource occupation information, and fallback constraint information generated after the network security service action is executed, and generate a new set of restriction factors;

[0042] The newly added set of limiting factors is reconnected with the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions to generate incremental constraint data for subsequent stage actions.

[0043] Based on the incremental data of the subsequent stage action constraints, the constraint loop network is subjected to a continuation weaving process to form new blocking segments, new bypass segments, or new closing segments for subsequent service actions, thereby generating the scheduling constraint data for the next service stage.

[0044] Furthermore, a network security service scheduling system based on constraint loop weaving is also disclosed, the system comprising:

[0045] The constraint acquisition and parsing unit is used to acquire the security service request corresponding to the target network environment and the constraint factor data associated with the security service request. The constraint factor data includes business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data. The unit performs constraint classification processing and constraint relationship parsing processing on the constraint factor data to generate first constraint identifier data representing constraint permission relationship and second constraint identifier data representing constraint blocking relationship, respectively.

[0046] The loop construction state generation unit is used to construct a constraint loop network based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request. The constraint loop network is used to characterize the connection relationship between multiple constraint factors and each service action, as well as the dependency restriction relationship, blocking transmission relationship, and closure trigger relationship formed by each service action under the action of multiple constraint factors. According to the constraint loop network, loop connection state data corresponding to each service action is generated. The loop connection state data is used to characterize whether the current service action is in an executable state, a blocked state, or a loopable state.

[0047] The conflict location attribute determination unit is used to perform loop conflict location processing on the constraint loop network, identify constraint blocking paths that block the current service advancement, and determine the loop attributes of each constraint loop in the constraint loop network based on whether the release conditions of the corresponding constraint loop can be achieved by service action rearrangement, execution order adjustment, or additional verification action insertion, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions. This generates rigid loop data and reconfigurable loop data. Based on the rigid loop data, the reconfigurable loop data, and the loop attachment status data, service advancement blocking data is generated.

[0048] The loop routing scheduling closure update unit is used to respond to the service advancement blocking data and perform loop routing scheduling processing on the rigid loop data and the reconfigurable loop data. The loop routing scheduling processing includes one or more of the following: alternative service action insertion processing, service action segmentation and orchestration processing, pre-verification action pre-processing, and local scope advance processing, so as to reconstruct the loop closure path corresponding to the original service action sequence without breaking the rigid loop release condition, generate loop routing scheduling sequence data, and update the constraint loop network based on the loop routing scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service stage.

[0049] The execution backflow continuation unit is used to execute the corresponding network security service action when the target service action is characterized by the closed loop state data and the execution conditions are met. It also performs backflow weaving processing on the newly added constraint factors generated after the execution of the network security service action, so as to attach the newly added constraint factors to the constraint loop network corresponding to the subsequent service action, generate the scheduling constraint data of the next service stage, and enable the subsequent service stage to continue to enter the scheduling and advancement process under the constraints of the updated constraint loop network.

[0050] The network security service scheduling method and system proposed in this application based on constraint loop weaving realize unified modeling, blocking location, bypass reconstruction, closed-loop advancement and continuation control of network security services under multiple constraints, thereby improving the continuity, controllability and engineering adaptability of security service scheduling in complex constraint environments. Attached Figure Description

[0051] Figure 1 This is a flowchart illustrating a network security service scheduling method based on constraint loop weaving.

[0052] Figure 2 A schematic diagram of the action constraint connection diagram and the structural relationship of the constraint loop network;

[0053] Figure 3 A logical diagram illustrating the relationship between loop reconnection scheduling and closed reconstruction;

[0054] Figure 4 A schematic diagram illustrating the relationship between loop closure evolution, constraint backflow triggering, and the continuation weaving of the next service phase;

[0055] Figure 5 This is a schematic diagram of a network security service scheduling system based on constraint loop weaving, provided as an embodiment of this application. Detailed Implementation

[0056] The technical solutions in the embodiments of the present invention will now be clearly and completely described with reference to the accompanying drawings. It should be noted that the described embodiments are only a part of the embodiments of the present invention, and not all of them. Other implementation methods obtained by those skilled in the art based on the embodiments disclosed in this invention without creative effort should all fall within the protection scope of this invention.

[0057] It should be noted that the target network environment, service action execution module, constraint acquisition module, permission management module, approval management module, resource monitoring module, loop analysis module, and data interaction method involved in the embodiments of the present invention can all be deployed and implemented using methods well known to those skilled in the art, and will not be described in detail here. The following, in conjunction with the accompanying drawings and specific embodiments, further explains the technical concept, processing flow, and related data objects of the present invention.

[0058] Please see Figure 1 A network security service scheduling method based on constraint loop weaving, comprising:

[0059] S1. Obtain the security service request corresponding to the target network environment and the constraint factor data associated with the security service request. The constraint factor data includes business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data. Perform constraint classification processing and constraint relationship parsing processing on the constraint factor data to generate first constraint identifier data representing constraint permission relationship and second constraint identifier data representing constraint blocking relationship, respectively.

[0060] S2, based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request, a constraint loop network is constructed. The constraint loop network is used to characterize the connection relationship between multiple constraint factors and each service action, as well as the dependency restriction relationship, blocking transmission relationship, and closure trigger relationship formed by each service action under the action of multiple constraint factors. According to the constraint loop network, loop connection status data corresponding to each service action is generated. The loop connection status data is used to characterize whether the current service action is in an executable state, a blocked state, or a bypassable state.

[0061] S3, perform loop conflict localization processing on the constraint loop network, identify constraint blocking paths that block the current service advancement, and, based on whether the release conditions of the corresponding constraint loop can be achieved by service action rearrangement, execution order adjustment, or insertion of additional verification actions while maintaining business continuity boundaries, permission boundaries, and rollback recovery conditions, determine the loop attributes of each constraint loop in the constraint loop network to generate rigid loop data and reconfigurable loop data; and generate service advancement blocking data based on the rigid loop data, the reconfigurable loop data, and the loop attachment status data.

[0062] S4, in response to the service advancement blocking data, loop bypass scheduling processing is performed on the rigid loop data and the reconfigurable loop data. The loop bypass scheduling processing includes one or more of the following: alternative service action insertion processing, service action segmentation and orchestration processing, pre-verification action pre-processing, and local scope advance processing, so as to reconstruct the loop closure path corresponding to the original service action sequence without breaking the rigid loop release condition, generate bypass scheduling sequence data, and update the constraint loop network based on the bypass scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service stage;

[0063] S5, when the closed loop state data indicates that the target service action meets the execution conditions, the corresponding network security service action is executed, and the newly added constraint factors generated after the execution of the network security service action are back-injected and woven to attach the newly added constraint factors to the constraint loop network corresponding to the subsequent service action, thereby generating the scheduling constraint data for the next service stage, so that the subsequent service stage can continue to enter the scheduling and advancement process under the constraints of the updated constraint loop network.

[0064] Specifically, the above method does not treat each constraint factor as an independent static verification condition for a one-time judgment. Instead, it organizes the permission, blocking, transmission, and closure relationships between multiple constraint factors and service actions into a loop-based structure to form a constraint control structure oriented towards the service advancement process. Based on this constraint control structure, it is possible to further realize loop conflict location, loop attribute determination, loop bypass scheduling, closure sequence reconstruction, and new constraint factor continuation weaving, thereby enabling the continuous advancement of network security services under the coexistence of constraints such as business continuity boundaries, permission boundaries, approval conditions, operation and maintenance windows, and resource availability. The following provides a detailed description of each step and related data objects.

[0065] Furthermore, this application provides a network security service scheduling method based on constraint loop weaving, which can be applied to government and enterprise network environments, cloud computing environments, hybrid network environments, industrial control network environments, and other target network environments with multiple types of execution constraints that require network security service scheduling. The scheduling object of this method is not limited to a single security action, but rather controls a sequence of service actions organized according to predetermined execution goals. These security service actions may include policy issuance, access restrictions, traffic switching, isolation control, account handling, image acquisition, rollback recovery, verification and detection, and other action units used to achieve network security service goals. The specific calling interfaces, execution driving methods, and underlying control commands for the above-mentioned security service actions can be implemented using methods well-known to those skilled in the art, and will not be elaborated upon here.

[0066] It should be noted that in traditional security service execution, most implementation methods typically treat business continuity requirements, permission boundaries, approval conditions, compliance restrictions, operational and maintenance windows, and resource usage limits as independent ancillary conditions for static verification. Under this type of implementation, constraint information is often used only as a single threshold for judgment before action execution, failing to depict the continuous interaction, transmission blocking, and phase continuation relationships formed by different constraint factors among multiple service actions. Therefore, it is difficult to adapt to the continuous security service deployment scenarios facing large-scale network environments.

[0067] Therefore, in this embodiment, constraint factors are not treated as isolated validation items. Instead, multiple constraint factors associated with security service requests are structurally collected, their relationships resolved, and linked together to form a constraint control relationship that can be uniformly modeled with the service action sequence. Based on this, the restriction, release, blocking, and recovery relationships between multiple constraint factors and multiple service actions are organized in a loop to construct a constraint loop network. This constraint loop network is not a simple set of rules or a task list, but a networked control structure used to characterize the continuous control effect of constraint factors on service actions during service execution.

[0068] In some implementations, the constraint loop network can be used to describe the following control elements: first, the permission conditions that must be met before a service action enters the execution phase; second, the impact conditions of a service action on subsequent service actions after execution; third, the blocking transmission relationships caused by incomplete approval, invalid permissions, peak business hours restrictions, failed rollback verification, or resource consumption exceeding a threshold; and fourth, how the original blocking relationships are reconstructed into new closed loop paths under scheduling methods such as alternative action insertion, segmented execution, pre-verification, or local scope priority. Based on this organizational method, the advancement process of security services no longer exhibits a linear triggering mode, but rather a phased advancement mode driven by constraint closure states.

[0069] Specifically, in some implementations, the security service requests to be executed in the target network environment can be obtained first, and business continuity constraints, system change boundary constraints, account permission boundary constraints, compliance execution constraints, operation and maintenance window constraints, customer authorization constraints, and resource usage limit constraints can be collected around the security service requests. Subsequently, the above constraint factors are categorized and their relationships are analyzed to form structured constraint identifier data representing constraint permission relationships and constraint blocking relationships respectively. Further, the constraint identifier data is attached to the pre-execution conditions, subsequent impact conditions, and fallback verification conditions corresponding to the service action sequence to form an action constraint attachment diagram. Based on this action constraint attachment diagram, loop weaving processing is performed to form a constraint loop network including loop entry segments, loop blocking segments, loop wrapping segments, and loop closing segments.

[0070] In some implementations, once the constraint loop network is formed, corresponding loop attachment status data can be generated based on the attachment position of each service action in the loop network, the type of the loop segment to which it belongs, the number of times it has been blocked, and the availability of alternative closed paths. This data indicates whether the current service action is in an executable state, a blocked state, or a loopable state. Subsequently, loop conflict localization processing is performed on the constraint loop network to identify the constraint blocking paths that are preventing the current service from proceeding. Combined with the implementation method of the release conditions, the attributes of each constraint loop are determined, classifying them into rigid loops and reconfigurable loops. Rigid loops typically correspond to constraint loops that can only be released after external approval, customer authorization, permission activation, compliance confirmation, or successful rollback verification. Reconfigurable loops typically correspond to constraint loops that can be reconfigured by adjusting the action sequence, narrowing the execution scope, prioritizing verification actions, or partially substituting execution, while maintaining the business continuity boundaries, permission boundaries, and rollback recovery conditions.

[0071] In some implementations, for identified rigid and reconfigurable loops, loop reconnection scheduling can be further implemented. It should be understood that this loop reconnection scheduling does not circumvent or skip the original constraints, but rather reconstructs the original service action sequence to form a new loop closure path without violating the rigidity release conditions and boundary control requirements. The loop reconnection scheduling may include one or more of the following: alternative service action insertion processing, service action segmentation orchestration processing, pre-verification action pre-processing, and local scope advance processing. Through the above processing, reconnection scheduling sequence data can be generated, and the constraint loop network can be updated based on this data to obtain the loop closure state data corresponding to subsequent service phases.

[0072] In some implementations, when the loop closure status data indicates that the target service action meets the execution conditions, the corresponding network security service action can be triggered to enter the execution phase. During execution, execution feedback data and environmental constraint change data corresponding to the current service action can be continuously acquired, and constraint backflow determination can be performed based on the execution feedback data and environmental constraint change data. When the constraint backflow determination result indicates that a new blocking relationship or a new restriction relationship has been formed in the current execution phase, the advancement of subsequent unexecuted service actions can be stopped, and the current execution phase can be switched back to the loop reweaving processing phase, thereby achieving continuous response to dynamically changing constraints.

[0073] Furthermore, in some implementations, information such as scope changes, permission occupancy, resource occupancy, and rollback constraints generated after the execution of network security service actions can be extracted as new constraint factors and reattached to the constraint loop network corresponding to subsequent service actions to generate scheduling constraint data for the next service stage. Thus, the method can not only complete security service scheduling in a single stage but also support multi-stage, continuous network security service advancement, allowing subsequent service stages to continue the scheduling process under the constraints of the updated constraint loop network. This application's implementation, by constructing a constraint loop network, implementing loop conflict localization, executing loop bypass scheduling, and back-injecting and weaving new constraint factors, transforms the execution process of network security services from the traditional static condition verification method to a dynamic scheduling control method oriented towards constraint closure, conflict bypass, and state continuation. Therefore, it can achieve more continuous, controllable, and engineering-adaptable network security service scheduling in complex network environments where business continuity requirements, permission boundary restrictions, customer approval conditions, operation and maintenance window restrictions, and resource availability constraints coexist. In this embodiment of the invention, the above-mentioned network security service scheduling process can be further divided into a constraint factor collection and relationship analysis stage, a constraint loop network construction stage, a loop conflict location and attribute determination stage, a loop reconnection scheduling and closure update stage, and an execution feedback and continuation weaving stage.

[0074] To facilitate a clear explanation of the embodiments of this application and to ensure that the processing logic of subsequent steps has a clear input, output, and calling relationship, the core data objects and related terms involved in the embodiments of this application are explained below. It should be understood that the following definitions are mainly used to describe a preferred expression in the embodiments of this application and do not constitute an undue limitation on the scope of protection of this application; without departing from the technical concept of this application, those skilled in the art can make adjustments to the specific field organization form, data storage structure, and interaction method.

[0075] Security service request: refers to a request initiated by a security operations platform, policy management platform, operations and maintenance platform, compliance management module, joint response module, or manual operation terminal in the target network environment to trigger the network security service process of the target network. The security service request is used to characterize the security service objective to be achieved, the scope of the object to be processed, the target execution environment, and the service priority.

[0076] In one optional implementation, the security service request may include a request identifier, request source, request initiation time, target asset set, target user set, service objective to be implemented, service priority, allowed execution period, expected impact scope, and rollback requirements. The security service request can be automatically generated by a pre-defined policy or triggered by a manual work order. Its underlying generation method, message transmission protocol, and storage structure can employ implementation methods well-known to those skilled in the art.

[0077] Service action sequence: refers to a set of service actions organized around the security service request and arranged in a logical execution order. Each service action in the service action sequence can correspond to an execution unit that can be independently scheduled, independently verified, and controlled by constraint factors. The service action sequence can be a linear sequence or an orchestratable sequence of actions that includes branching, merging, or phase switching relationships.

[0078] In one optional implementation, each service action is associated with at least three pre-execution conditions, subsequent impact conditions, and rollback verification conditions. Pre-execution conditions characterize the set of conditions that must be met before the corresponding service action enters the execution phase; subsequent impact conditions characterize the set of effects that the corresponding service action will have on subsequent service actions after execution; and rollback verification conditions characterize the set of conditions that must be met to ensure the system recovers to the expected safe state when the corresponding service action fails, is revoked, or undergoes a phased rollback. These conditions can be field-based condition items, rule expressions, or policy expressions.

[0079] Constraint factor data: refers to the set of constraint information used to characterize the execution boundaries, execution order, execution scope, execution timing, and rollback conditions of the service action sequence. This constraint factor data may be provided by business systems, approval systems, permission systems, compliance policy libraries, resource monitoring modules, maintenance window management modules, customer authorization record modules, or other related systems, and after collection, transformation, and standardization, it forms a unified structured data object.

[0080] In a preferred implementation, each constraint factor includes at least a factor identifier, factor category, factor source, target, action stage, permission condition, blocking condition, release condition, constraint strength, priority, and duration. The target represents the service action or set of service actions affected by the current constraint factor; the action stage represents whether the current constraint factor acts during the pre-execution stage, execution period, or rollback verification stage; the permission condition represents the conditions required for the corresponding service action to enter the allowed execution state; the blocking condition represents the triggering condition for the corresponding service action to enter the blocked state; and the release condition represents the conditions required to eliminate the blocking relationship or release the restriction relationship.

[0081] In some implementations, the constraint factor data includes at least business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data.

[0082] First constraint identifier data and second constraint identifier data: These refer to the structured relationship data formed after the constraint factor data has undergone constraint classification processing and constraint relationship parsing processing. Specifically, the first constraint identifier data is used to characterize constraint permission relationships, and the second constraint identifier data is used to characterize constraint blocking relationships.

[0083] In one optional implementation, the first constraint identification data includes at least a permission relationship identifier, an associated constraint factor identifier, an action service identifier, a permission establishment condition, and a permission validity range; the second constraint identification data includes at least a blocking relationship identifier, an associated constraint factor identifier, an action service identifier, a blocking trigger condition, a release condition, and a blocking validity range. Through these two types of constraint identification data, the original constraint factors can be converted into unified relationship objects that can participate in subsequent attachment modeling, loop weaving, and state determination, and serve as direct input for constructing action constraint attachment diagrams and constraint loop networks.

[0084] Action constraint connection diagram: refers to the structured relationship diagram formed by connecting the first constraint identifier data and the second constraint identifier data to the pre-execution conditions, subsequent influence conditions and backoff verification conditions corresponding to each service action in the service action sequence. It is used to describe the connection relationship between constraint factors and service actions, as well as the dependency, blocking and recovery relationships formed by service actions under the action of constraints.

[0085] In one optional implementation, the nodes in the action constraint graph include service action nodes and constraint factor nodes, and the edges include permissive attachment edges, blocking attachment edges, influence propagation edges, and fallback association edges. The action constraint graph serves as the input foundation for the subsequent construction of the constraint loop network.

[0086] Constraint loop network: refers to a networked control structure formed by weaving multiple service actions and their corresponding constraint factors with interdependent, mutually blocking, sequential constraints or closed triggering relationships based on action constraint connection diagram. It is used to characterize the permitted closed path, blocking transmission path, bypass reconstruction path and stage continuation path in the service advancement process.

[0087] In a preferred implementation, each constraint loop includes at least a loop entry segment, a loop blocking segment, a loop bypass segment, and a loop closure segment. The loop entry segment characterizes the initial segment where a service action enters the current loop control range; the loop blocking segment characterizes the segment where service advancement is restricted due to the continued effect of the blocking relationship; the loop bypass segment characterizes the alternative advancement segment formed through alternative actions, segmented orchestration, pre-verification, or local scope prior to the action; and the loop closure segment characterizes the convergence segment formed after the permission conditions are met and the blocking relationship is released.

[0088] Loop connection status data: refers to the state-based description data formed by the controlled state of each service action in the current loop network based on the constraint loop network. It is used to characterize whether the corresponding service action is in an executable state, a blocked state, or a loopable state, and serves as the input for subsequent conflict location processing and loop scheduling processing.

[0089] In one optional implementation, the loop connection status data includes at least a service action identifier, the loop identifier, the connection location, the type of the loop segment, the degree of permitted closure, the blocking strength, the number of times it has been blocked, the availability of alternative closure paths, and the current status identifier.

[0090] Rigid loop data and reconfigurable loop data: These refer to data objects formed after attribute determination of each constraint loop in the constraint loop network. Rigid loop data corresponds to constraint loops whose release conditions depend on external approval completion, customer authorization completion, permission change effect, compliance confirmation completion, or rollback verification success. Reconfigurable loop data corresponds to constraint loops that can be reconfigured by service action rearrangement, execution scope shrinking, pre-verification insertion, or partial replacement execution, provided that business continuity boundaries, permission boundaries, and rollback recovery conditions are met.

[0091] In one optional implementation, both the rigid loop data and the reconfigurable loop data include at least a loop identifier, a set of loop component nodes, a set of blocking paths, a set of release conditions, attribute determination results, and an optional processing method identifier.

[0092] Service advance blocking data: refers to a data object formed by summarizing the reasons for blocking, blocking location, blocking impact range and subsequent processing direction when the current service action cannot enter the execution stage, based on rigid loop data, reconfigurable loop data and loop connection status data. It is used to trigger subsequent loop bypass scheduling processing and identify the blocking path that should be prioritized for processing.

[0093] In one optional implementation, the service advancement blocking data includes a target service action identifier, a loop identifier, a blocking start point, a blocking transmission node, a blocking convergence node, a loop exit node, a blocking cause identifier, a loop attribute determination result, and a suggested processing path.

[0094] Bypass scheduling sequence data: refers to the structured scheduling result formed after performing loop bypass scheduling on rigid and reconfigurable loops in response to service advance blocking data. It is used to replace or supplement the original service action sequence and to characterize the succession relationship and execution order relationship between the new service action, the replacement service action, the split service action and the original service action.

[0095] In one optional implementation, the bypass scheduling sequence data includes at least a sequence identifier, original service action reference relationship, new service action set, split service action set, replacement service action set, stage split identifier, order adjustment relationship, connectivity verification result, permission boundary preservation verification result, and rollback recoverability verification result.

[0096] Loop closure status data: refers to the data object formed after analyzing the closing sequence, blocking release sequence and service release sequence of each constraint loop in the subsequent service phase after updating the constraint loop network based on the bypass scheduling sequence data. It is used to determine whether the target service action meets the conditions to enter the execution phase.

[0097] In one optional implementation, the loop closure status data includes at least a loop identifier, permission closure condition satisfaction status, blocking closure condition release status, closure sequence identifier, blocking release sequence identifier, service release sequence identifier, and target service action execution permission identifier.

[0098] Execution feedback data and environmental constraint change data refer to two types of data generated after the target service action enters the execution phase. Execution feedback data characterizes the current execution result, execution progress, execution impact, and anomalies. Environmental constraint change data characterizes changes in external conditions related to constraints during the current execution phase. These changes may include updates to approval status, changes in authorization status, changes in resource usage, changes in workload, changes in maintenance windows, or changes in rollback conditions. Both execution feedback data and environmental constraint change data serve as input for constraint rollback determination, identifying whether new blocking relationships or new restrictive relationships have formed during the current execution phase.

[0099] The newly added set of constraint factors and scheduling constraint data refers to the set of constraint factors formed by extracting and standardizing the scope change information, permission occupancy information, resource occupancy information, and rollback constraint information generated after the execution of network security service actions. This newly added set of constraint factors can be reattached to the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions to form incremental constraint data for subsequent stages. The scheduling constraint data refers to the data object formed after the newly added set of constraint factors is continuously woven into the constraint loop network, and the constraint status, blocking relationships, bypass relationships, and closure conditions of the next service stage are uniformly expressed. This data serves as the input basis for the classification of execution constraints, loop updates, status determination, and service advancement in the next service stage.

[0100] Furthermore, the constraint factor data is subjected to constraint classification processing and constraint relationship parsing processing to generate first constraint identifier data and second constraint identifier data representing constraint permission relationships and constraint blocking relationships, respectively. This includes: classifying and mapping the constraint factor data according to constraint source attributes, constraint action stage attributes, and constraint release dependency attributes to generate constraint category index data; based on the constraint category index data, identifying the permission attachment conditions and blocking attachment conditions of each constraint factor for the corresponding service action to generate constraint action pointing data; and encoding the constraint relationship that allows the corresponding service action to enter the execution orchestration according to the constraint action pointing data to generate the first constraint identifier data, and encoding the constraint relationship that restricts the corresponding service action from entering the execution orchestration to generate the second constraint identifier data.

[0101] In some implementations, constraint factor collection, classification, and relationship parsing are used to convert constraint information from scattered sources and with different forms of expression into structured constraint objects that can participate in subsequent action constraint attachment and loop weaving, so as to generate constraint identification data that characterizes constraint permission relationships and constraint blocking relationships.

[0102] In some implementations, constraint factor collection and processing revolves around security service requests within the target network environment. The scope of constraint sources to be collected can be determined based on the target asset scope, service objectives, expected impact range, permitted execution period, and rollback requirements stated in the request. These constraint sources may include business systems, change approval systems, access control systems, compliance policy libraries, maintenance window management systems, resource monitoring modules, customer authorization record modules, and execution control platforms. Related interface access, log subscriptions, database reads, or message queue synchronization methods can employ implementations well-known to those skilled in the art.

[0103] In one optional implementation, the raw constraint information collected from various constraint sources can first undergo standardization transformation to unify field names, time formats, object identification methods, and condition expression methods, forming a constraint factor dataset. Each constraint factor is preferably stored using a field-based structure, including at least factor identifier, factor category, target object, action stage, permission condition, blocking condition, release condition, constraint strength, and priority. This field organization method transforms the raw constraint information from source expression to control expression.

[0104] Among them, the factor category is used to characterize the type of constraint factor, which may include business continuity, system change boundary, account permission boundary, compliance execution, operation and maintenance window, customer authorization, and resource usage limit; the target object is used to characterize the service action, service action set, target asset set, or execution domain scope of the current constraint factor; the action stage is used to characterize whether the current constraint factor acts in the pre-execution stage, during execution, or rollback verification stage; the permission condition is used to characterize the conditions that need to be met for the corresponding service action to enter the allowed progress state; the blocking condition is used to characterize the triggering conditions for the corresponding service action to enter the blocked or restricted state; the release condition is used to characterize the conditions that need to be met to eliminate the blocking relationship or release the restriction relationship; the constraint strength is used to characterize the degree of restriction of the current constraint factor on the progress of the service action; and the priority is used to characterize the processing order or impact level of the current constraint factor in the case of multiple constraints.

[0105] In some implementations, the constraint factor can be applied to a single-action mapping method, an action set mapping method, or an execution domain mapping method. The single-action mapping method is used to attach the current constraint factor to a specific service action; the action set mapping method is used to apply the current constraint factor to a group of related service actions simultaneously; and the execution domain mapping method is used to apply the current constraint factor to related service actions under a network partition, business system domain, asset domain, or permission domain.

[0106] In some implementations, constraint factor classification may include source attribute classification, action phase classification, and dependency removal classification. Source attribute classification distinguishes constraint factors into business source constraints, approval source constraints, permission source constraints, compliance source constraints, resource source constraints, and operation / maintenance time period source constraints. Action phase classification distinguishes the different stages at which constraint factors act before service implementation, during service execution, or during rollback verification. Dependency removal classification distinguishes whether the current constraint factor's removal condition is due to approval completion, authorization completion, permission activation, resource release, time period arrival, or rollback verification success. After classification, constraint category index data can be generated, which records the factor identifier, category label, stage label, dependency removal label, target object label, and priority label for each constraint factor.

[0107] In some implementations, constraint resolution is used to identify whether each constraint factor creates a permissive or blocking relationship with the corresponding service action. The same constraint factor may exert different types of control effects in different service actions and at different stages. For example, a maintenance window constraint may create a blocking relationship for policy-issued actions before the window opens, but a permissive relationship after the window opens; a rollback verification constraint may act as a pre-restriction relationship before formal execution, but may be transformed into a closed permissive condition after rewiring and reconstruction. Therefore, constraint resolution requires a comprehensive judgment based on the current stage position of the service action, object matching, and the state of the release condition.

[0108] In one alternative implementation, constraint factors can be defined. Service actions The relation determination function is: ,in Represents constraint factor Category and source attributes, Represents constraint factor With service actions The object matching results between them Indicates a service action Execution stage and constraint factors Matching results at the action stage Represents constraint factor The release condition is met. By combining and judging the above parameters, the relationship attribute of the constraint factor to the target service action can be obtained.

[0109] In a preferred implementation, when When, it represents the constraint permission relationship formed between the current constraint factor and the corresponding service action; when When, it represents the current constraint factor forming a constraint blocking relationship with the corresponding service action; when When the constraint factor does not directly affect the corresponding service action at the current stage, it indicates that the current constraint factor does not directly affect the corresponding service action. It should be noted that the above mathematical expression is only used to illustrate one possible implementation of relation resolution processing. In specific implementations, rule engine judgment methods, finite state mapping methods, or other equivalent relation judgment methods can also be used.

[0110] In some implementations, the identified permission and blocking relationships can be further weighted by combining constraint strength and priority. Specifically, a relationship weight value can be assigned to each relationship item. The relation weight value can be determined by the constraint strength, priority, time range, and coverage of the affected object. The relation weight value can be used to set the edge weights in the subsequent action constraint connection graph, and can also be used to measure the blocking strength and permissible closure degree during subsequent state determination processing.

[0111] In one alternative implementation, the relation weight value can be represented as: ,in This indicates the constraint strength of the constraint factor. Indicates the priority of the current constraint factor. This indicates the time-dependent impact value of the current constraint factor. This indicates the coverage value of the current constraint factor's affected objects. The preset weight parameters are used. By employing the above processing method, subsequent loop analysis can not only identify the existence of constraint relationships, but also further identify the degree of influence of these constraint relationships.

[0112] In some implementations, after the relationship resolution process is completed, first constraint identifier data and second constraint identifier data can be generated respectively. The first constraint identifier data is used to characterize the constraint permission relationship, and includes at least a permission relationship identifier, an association factor identifier, an action service identifier, a permission establishment condition, a permission validity stage, and a relationship weight value. The second constraint identifier data is used to characterize the constraint blocking relationship, and includes at least a blocking relationship identifier, an association factor identifier, an action service identifier, a blocking trigger condition, a release condition, a blocking validity stage, and a relationship weight value. The first constraint identifier data and the second constraint identifier data can be used as input for subsequent construction of the action constraint attachment graph.

[0113] In some implementations, when the same service action is controlled by multiple permission relationships and multiple blocking relationships simultaneously, a relationship merging process can be performed to eliminate duplicate relationship items, merge same-origin relationship items, and retain conflicting relationship items. For conflicting relationship items, the priority of the current stage's effective relationship can be determined based on priority, constraint strength, and maturity of the release condition. Through the above processing, duplicate edges in subsequent hook graphs can be reduced, improving the stability of loop weaving processing.

[0114] In some implementations, the constraint loop network construction process may include the following steps: obtaining the pre-execution conditions, subsequent influence conditions, and backoff verification conditions corresponding to each service action in the service action sequence; based on the first constraint identifier data and the second constraint identifier data, attaching each constraint factor to the pre-execution conditions, subsequent influence conditions, and backoff verification conditions of the corresponding service action to generate an action constraint attachment diagram; performing loop weaving processing on multiple service actions and their corresponding constraint factors that have interdependent, mutually blocking, or sequential constraint relationships in the action constraint attachment diagram to generate a constraint loop network including loop entry segments, loop blocking segments, loop wrapping segments, and loop closing segments. The above processing steps are further explained below.

[0115] In some implementations, the action constraint linking graph and constraint loop network construction process is used to structurally link the first constraint identifier data, the second constraint identifier data and the service action sequence corresponding to the security service request, forming a graph structure control object that represents the dependencies, constraint transmission, blocking convergence and closure triggering relationships of the service actions.

[0116] In some implementations, before constructing the action constraint mapping graph, the condition structure of each service action in the service action sequence can be determined first. Each service action is associated with at least pre-execution conditions, subsequent impact conditions, and rollback verification conditions. Pre-execution conditions characterize the set of conditions that must be met before the corresponding service action enters the execution phase; subsequent impact conditions characterize the set of impacts that the current service action will have on subsequent service actions, execution domain status, resource occupancy status, or permission status after execution; rollback verification conditions characterize the set of verification items that must be met to ensure the service environment returns to a controllable state when the current service action is revoked, interrupted, or needs to be restored. By pre-defining the above condition structure, a clear carrier can be provided for the binding of constraint factors.

[0117] In one alternative implementation, the sequence of service actions can be represented as a set of action nodes. The relational objects obtained from the aforementioned constraint factors are represented as a set of constraint nodes. Based on this, an action constraint connection diagram can be constructed. The node set V includes service action nodes and constraint nodes, and the edge set E includes permitted attachment edges, blocked attachment edges, influence propagation edges, and fallback association edges. The permitted attachment edge represents a constraint factor being attached to a service action as a permitted condition; the blocked attachment edge represents a constraint factor being attached to a service action as a blocked condition; the influence propagation edge represents the impact of a service action on the conditional states of other service actions after its execution; and the fallback association edge represents the recovery association between a service action and its fallback verification conditions.

[0118] In some implementations, the attachment process can be executed layer by layer according to the conditional structure of the service actions. Specifically, the permission relationship items recorded in the first constraint identifier data can first be attached to the pre-execution conditions and fallback verification conditions of the corresponding service action, thereby forming permission attachment edges; secondly, the blocking relationship items recorded in the second constraint identifier data can be attached to the pre-execution conditions, execution period conditions, or fallback verification conditions of the corresponding service action, thereby forming blocking attachment edges; furthermore, based on the execution sequence, resource dependency, permission influence, and scope influence of the service actions themselves, influence propagation edges and fallback association edges are established between different service actions. Through the above processing, service actions, constraint factors, and inter-action relationships can be uniformly incorporated into the same graph structure.

[0119] In one alternative implementation, when the same constraint factor applies to multiple service actions simultaneously, an action constraint connection graph can be constructed using shared constraint nodes. This involves retaining a unique constraint node corresponding to the same constraint factor and connecting it to different service actions via multiple connection edges. This approach allows shared approval restrictions, time-based restrictions, permission boundary restrictions, or resource limit restrictions across actions to form a shared control relationship in the graph, thus providing a foundation for subsequently identifying transitive and convergent blocking paths.

[0120] In some implementations, after constructing the action constraint connection diagram, loop weaving can be further performed to form a constraint loop network. It should be noted that loop weaving does not simply refer to identifying ordinary closed loops in the diagram, but rather to organizing multiple action nodes and constraint nodes into loop units with control significance based on the sequential constraints between service actions, the shared control relationships between constraint factors, the impact transmission relationships after action execution, and the backoff verification relationships. Each loop unit represents the complete progression path of a set of service actions from entry, restriction, bypass to closed release under certain control boundaries.

[0121] In some implementations, a node can be considered to constitute a weavable loop when at least one of the following conditions is met: First, at least two service actions share the same constraint node, and this constraint node forms a blocking relationship for one service action and a permitting or releasing condition for the other service action; Second, at least two service actions have a sequential dependency relationship, and the execution result of the preceding service action changes the effective state of the constraint factor associated with the subsequent service action; Third, the fallback verification condition of a certain service action acts in reverse on the preceding or parallel service action, thereby forming a recovery control relationship; Fourth, the insertion of a substitute service action or pre-verification action can change the extension direction of the original blocking path and form a new closed release path. Any node that meets any of the above conditions can participate in loop weaving.

[0122] In one alternative implementation, each constraint loop can be represented as ,in This represents the set of service action nodes participating in the current loop. This represents the set of constraint nodes participating in the current loop. This represents the set of connected edges, transmitted edges, and restored edges within the current loop. Furthermore, each constrained loop can be divided into loop entry segment, loop blocking segment, loop wrapping segment, and loop closing segment.

[0123] The loop entry segment characterizes the initial segment where a service action enters the control range of the current constraint loop. In one optional implementation, if a service action first establishes a connection with a constraint node within the current loop, and the execution result of the service action can transmit constraint status, resource status, or permission status to subsequent actions, then the segment containing the service action and its initial connection edge can be identified as the loop entry segment. The purpose of the loop entry segment is to clarify the starting action and initial control boundary of the current loop, providing a reference for subsequently identifying the blocking start point and the release start point.

[0124] A loop blocking segment is used to characterize a segment where service advancement is restricted, suspended, or cannot be directly permitted due to the continuous effect of one or more blocking relationships. In one optional implementation, if a blocking connection exists within a segment, and this blocking relationship extends through an influence propagation edge to at least one subsequent service action, preventing that at least one service action from meeting its prerequisite execution conditions, then the segment can be identified as a loop blocking segment. The loop blocking segment may contain one or more blocking propagation nodes and may form a blocking convergence point when multiple blocking paths converge. The purpose of the loop blocking segment is to clarify the formation location and propagation range of service advancement restriction, providing a basis for subsequent conflict localization and loop attribute determination.

[0125] A loop reconnection segment is used to characterize an alternative advancement segment formed without disrupting existing boundary controls, through inserting alternative service actions, performing segmented orchestration, implementing pre-verification, or limiting a local scope. In one optional implementation, if an alternative path exists for a certain loop blocking segment, and this alternative path can reconnect the originally blocked service action to the permitted closed path while maintaining business continuity boundaries, permission boundaries, and fallback recovery conditions, then the set of nodes and edges corresponding to the alternative path can be determined as a loop reconnection segment. The loop reconnection segment does not exist independently of the original loop, but participates in the subsequent closure process as a reconstruction advancement branch after the original loop is blocked.

[0126] A closed loop segment characterizes the section that causes the current constraint loop to enter a convergent state after the permission conditions are met, the blocking relationship is released, and the service release sequence is established. In one optional implementation, if the pre-execution conditions of the corresponding service action within a certain segment have been met, the blocking connection has been released or transformed into a release condition, and the service action corresponding to the end of the segment can legally enter the execution phase, then the segment can be identified as a closed loop segment. The function of the closed loop segment is to indicate when the current loop completes control closure and to provide a basis for subsequently generating loop closure state data.

[0127] In some implementations, to further describe the formation process from the action constraint binding graph to the constraint loop network, a graph structure mapping relationship can be introduced. Specifically, subgraphs satisfying the loop weaving condition in the action constraint binding graph G can be extracted and identified using a loop identification operator. Form a set of constraint loops: Where L represents the set of constraint loops identified by the action constraint connection graph G. Let represent the k-th constraint loop. Further, for each constraint loop... It can be achieved through segmentation operators get: ,in Indicates the loop entry segment. Indicates the circuit blocking segment. Indicates the loop connection segment. This represents a closed segment of a loop. The mathematical expression above illustrates one possible implementation of constraint loop identification and segment partitioning. In practice, rule matching, graph traversal, adjacency analysis, or other equivalent implementation methods can also be used.

[0128] Reference Figure 2 , Figure 2The diagram illustrates the structural relationships of the action constraint connection diagram and constraint loop network. In this embodiment, the left side can be understood as the constraint factor node layer, the middle as the service action node layer, and the right side as the loop segmentation structure layer. Multiple constraint factor nodes establish connection relationships with their corresponding service action nodes through permission connection edges, blocking connection edges, or fallback connection edges. Service action nodes are connected through influence propagation relationships. Based on the above connection and propagation relationships, multiple service actions and their corresponding constraint factors can be further organized into constraint loops with associated control significance.

[0129] like Figure 2 As shown, when a pre-verification service action first establishes a permission connection with a business continuity constraint factor, and the execution result of this service action transmits status effects to subsequent service actions, the corresponding segment can be identified as a loop entry segment; when a policy-issued service action, access restriction service action, or account handling service action is simultaneously affected by approval, time period, or permission boundary constraints, and subsequent service actions cannot meet the pre-execution conditions, the corresponding segment can be identified as a loop blocking segment; when an alternative action, segmented execution action, or local pre-action action is inserted on the basis of the original blocking segment, thereby forming an alternative advancement path, the corresponding segment can be identified as a loop bypass segment; when the permission conditions are met and the blocking relationship is lifted, enabling subsequent service actions to enter the execution phase, the corresponding segment can be identified as a loop closure segment. Figure 2 The structure shown provides a more intuitive understanding of the organizational relationships between constraint factors, service actions, and loop segments. After the constraint loop network is constructed, the following basic attributes can be recorded for each loop: loop identifier, set of participating action nodes, set of participating constraint nodes, entry segment identifier, blocking segment identifier, bypass segment identifier, closed segment identifier, shared constraint node identifier, and inter-segment transitivity identifier. These attributes can be used for subsequent generation of loop connection status data, identification of blocking paths, determination of rigidity and reconfigurability attributes, and performance of closed-loop simulation processing.

[0130] Furthermore, in some implementations, to enhance the stability of subsequent state determination, edge weights can be assigned to various edges in the action constraint attachment layer. The edge weight of the permitted attachment edge can be determined by the relation weight value of the corresponding permitted relationship; the edge weight of the blocking attachment edge can be determined by the relation weight value of the corresponding blocking relationship; the edge weight of the influence transmission edge can be jointly determined by the influence range, influence duration, and influence reversibility of the preceding service action on the subsequent service action; and the edge weight of the fallback associated edge can be jointly determined by the fallback verification complexity and the degree of recovery dependency. Through the above methods, the degree of influence of different edges on the overall blocking propagation and closure release can be distinguished within the same loop.

[0131] In some implementations, generating loop connection status data corresponding to each service action based on the constraint loop network and performing loop conflict location processing may include at least the following steps: performing closure condition parsing processing on each constraint loop in the constraint loop network to obtain the permissive closure condition and blocking closure condition corresponding to each constraint loop; determining the state judgment parameters corresponding to each service action based on the connection position of each service action in the constraint loop network, the type of the loop segment to which it belongs, the number of times it has been blocked, and the availability of alternative closure paths, and generating loop connection status data representing whether the current service action is in an executable state, a blocked state, or a reconnectable state; furthermore, performing blocking propagation tracing processing on each constraint loop in the constraint loop network to identify the constraint blocking path that blocks the current service advancement, and on this basis, determining the loop attributes of each constraint loop to generate rigid loop data and reconfigurable loop data. The above processing steps are further explained below.

[0132] In some implementations, the purpose of the loop connection status determination process is to further transform the already constructed constraint loop network from a structured control object into a stateful control object that can participate in scheduling decisions. This process does not merely determine whether a service action can be executed, but rather jointly determines the current controlled state of the service action from multiple dimensions, such as the degree of loop closure, the degree of obstruction propagation, and the availability of alternative paths. This enables subsequent scheduling processes to clearly distinguish between actions that can be directly advanced, actions that need to wait for release, and actions that can be advanced through reconfiguration.

[0133] In some implementations, closure condition parsing is performed on each constraint loop before generating loop attachment state data. This closure condition parsing process identifies the permissive closure conditions required to grant a service action permission in the current constraint loop, as well as the blocking closure conditions that cause the service action to remain restricted or unable to be released. Specifically, the closure control boundary of each loop can be parsed based on permissive attachment edges, blocking attachment edges, influence propagation edges, and fallback association edges in the constraint loop network, combined with the permissive conditions, blocking conditions, and release conditions corresponding to each constraint node.

[0134] In one alternative implementation, the permission closure condition may include: the permission condition associated with the current loop has been met, the impact of the preceding service action has been transmitted, the rollback verification condition associated with the current service action is recoverable, and the external authorization condition associated with the execution of the current action is in a valid state. Correspondingly, the blocking closure condition may include: the existence of an unremoved blocking edge, the existence of an incomplete preceding external approval, the existence of an ineffective permission change, the existence of a failed rollback verification condition, or a situation where resource occupancy exceeds a predetermined boundary. Through this parsing, control conditions originally scattered across different nodes and edges can be extracted into a computable set of closure conditions.

[0135] In one alternative implementation, for the k-th constraint loop Each set of permission closure conditions can be constructed separately. and the set of blocking closure conditions .in This is used to characterize the set of conditions that must be satisfied for the current loop to enter the release convergence state. This is the set of conditions that characterize whether the current loop remains in a blocked state or is prohibited from being allowed to pass. Further, the closure determination function for the current loop at time t can be defined as: ,in This indicates whether the permission condition is true at time t. This indicates whether the blocking condition term is true at time t. When, it indicates that the corresponding constraint loop satisfies the closure condition at time t; when At time t, the corresponding constraint loop has not yet formed a closed loop. It should be noted that the above mathematical expression is used to describe one optional implementation of the closure condition analysis and closure state determination. In specific implementations, rule evaluation, state machine mapping, or other equivalent implementation methods can also be used.

[0136] In some implementations, after completing the closure condition analysis, state determination parameters can be determined for each service action. These state determination parameters may include at least: a connection position parameter, a loop segment type parameter, a blocking count parameter, and an alternative closure path availability parameter. Specifically, the connection position parameter indicates whether the current service action is located in the loop entry segment, blocking segment, bypass segment, or closed segment; the loop segment type parameter indicates which function the segment performs in the current stage: initiation introduction, blocking transmission, alternative advancement, or convergence release; the blocking count parameter indicates the number of times the current service action is hit by blocking relationships within a preset observation period; and the alternative closure path availability parameter indicates whether there is an alternative closure path that meets the boundary preservation requirements, and the availability of that alternative path.

[0137] In a preferred implementation, the attachment position parameter can be determined by the node level of the current service action in the constraint loop network, its distance from the entry segment, and its distance from the closed segment; the loop segment type parameter can be directly determined by the structural attributes of the segment to which the current service action belongs; the blocking count parameter can be obtained by combining the number of times the blocking attachment edge is hit, the number of times the blocking propagation path is traversed, or the number of times the blocking convergence node is associated; the available alternative closed path parameter can be determined by the number of alternative paths from the current service action to the closed segment, the path reachability, and the number of new actions required for the path. By uniformly calculating the above parameters, a parameter input set for state-oriented decision-making can be obtained.

[0138] In some implementations, loop connection status data corresponding to each service action can be generated based on permission closure conditions, blocking closure conditions, and state determination parameters. The loop connection status data can at least characterize whether the current service action is in an executable state, a blocked state, or a loopable state. It should be noted that the executable state means that the current service action has satisfied the permission closure conditions and there are no blocking closure conditions; the blocking state means that the current service action has a blocking relationship that cannot be directly resolved by the current stage; and the loopable state means that although the current service action cannot proceed directly according to the original service action sequence, there is an alternative closed path that satisfies the boundary preservation requirements.

[0139] In one alternative implementation, service actions can be further defined. The state scoring function is: ,in This indicates the degree of permission closure corresponding to the current service action. This indicates the degree of reachability of the loop containing the current service action. Indicates the strength of the current service action being blocked. Indicates the availability of alternative closed paths. For preset weight parameters. In one optional determination method, when... When the current service action is ready, it can be determined to be executable; when When this happens, the current service action can be determined to be in a bypassable state; when When this happens, the current service action can be determined to be in a blocked state, where This is a preset threshold. Through this process, permission and blocking relationships of different sources and intensities can be uniformly mapped into state results oriented towards scheduling decisions.

[0140] In some implementations, after generating the loop connection status data, loop conflict localization processing can be further performed on the constraint loop network. This loop conflict localization processing is used to identify constraint blocking paths that prevent the current service action from proceeding, and to extract the corresponding blocking start point, blocking transmission node, blocking convergence node, and loop exit node, thereby providing a clear localization basis for subsequent loop attribute determination and bypass scheduling processing.

[0141] In one alternative implementation, the loop conflict localization process can perform blocking propagation tracing based on blocking attachment edges and influence propagation edges. Specifically, it can trace back from the target service action in a blocked or loopable state to its associated blocking attachment edge, and trace forward along the influence propagation edge to the earliest constraint node or service action node that triggered the current blocking relationship, to determine the loop starting blocking point; at the same time, it can traverse backward along the blocking propagation direction to the subsequent service action nodes affected by the current blocking relationship, to determine the blocking propagation node; if multiple blocking paths overlap at a certain service action node or constraint node, then that node can be determined as the blocking convergence node; if there is a unique path, candidate path, or loop path leading to the closed segment after that node, then the corresponding boundary node can be determined as the loop exit node.

[0142] In some implementations, after completing the blocking propagation tracing, constrained blocking path data can be generated. This constrained blocking path data may include at least the target service action identifier, loop identifier, blocking start point, blocking propagation node set, blocking convergence node, loop exit node, blocking path length, path blocking strength, and path substitutability identifier. This constrained blocking path data can serve as direct input for subsequent rigidity and reconstruction determinations.

[0143] In some implementations, based on conflict localization, loop attribute determination can be performed on each constrained loop to generate rigid loop data and reconfigurable loop data. It should be noted that loop attribute determination is a crucial supporting step in the embodiments of this invention. Its purpose is not merely classification and naming, but rather to provide clear processing boundaries for the subsequent scheduling system, i.e., which loops must wait for the external conditions to be resolved, and which loops are allowed to perform alternative reconfiguration while maintaining the boundaries. Therefore, this part of the processing should revolve around three dimensions: "determination rules + parameter source + result application".

[0144] In some implementations, the determination rule for rigid loops can be based on whether the release condition of the corresponding constraint loop depends on the completion of external approval, customer authorization, effective permission change, compliance confirmation, or successful rollback verification. In other words, if the release of the blocking relationship of a constraint loop does not depend on the internal order adjustment or partial substitution of the current service action sequence, but requires the fulfillment of external control conditions, then the constraint loop can be determined as a rigid loop. The determination parameters mainly include: the release condition field in the constraint factor data, the release dependency label in the constraint category index data, the blocking convergence node attribute in the blocking path data, and the external control status in the execution domain. The purpose of the determination result is that for constraint loops determined to be rigid, subsequent scheduling processing should not directly advance the original service action by bypassing the release condition, but should prioritize inserting pre-verification service actions, approval connection service actions, or waiting for the completion of external events.

[0145] In one alternative implementation, a rigid decision function can be constructed. : ,in Indicates whether the current loop depends on external approval to complete. Indicates whether the current loop requires customer authorization to complete. Indicates whether the current loop depends on permission changes to take effect. Indicates whether the current loop depends on compliance confirmation to complete. This indicates whether the current loop depends on the successful backoff verification. When the corresponding constraint loop is defined as a rigid loop, it can be determined that the loop is rigid; when When the condition is met, it indicates that the current loop does not meet the rigid judgment condition and can proceed to the subsequent reconfigurable judgment stage.

[0146] In some implementations, the criteria for determining reconfigurable loops can be based on whether the release conditions of the corresponding constraint loop can be satisfied through service action rearrangement, execution scope contraction, pre-verification insertion, or partial alternative execution, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions. It should be noted that reconfigurability does not mean that the current loop can be arbitrarily adjusted, but rather that alternative reconstruction of the closed path corresponding to the original service action sequence is allowed, provided that the control boundary is not violated, business risks remain under control, and the rollback path remains effective. The determination parameters mainly include: the availability of alternative closed paths in the loop connection status data, loop exit node information in the constraint blocking path data, action decomposability information in the service action sequence, the influence propagation relationship in the action constraint connection graph, and rollback verification condition data. The purpose of the determination result is to: for constraint loops determined to be reconfigurable, subsequent executable loop bypass scheduling processing is performed to form alternative closed paths.

[0147] In one alternative implementation, a refactoring decision function can be constructed. : ,in Indicates the degree to which business continuity boundaries are maintained. Indicates the degree to which permission boundaries are maintained. Indicates the degree to which the rollback and recovery conditions are maintained. Indicates the feasibility of alternative executions or action reordering. When When this happens, the corresponding constraint loop can be determined as a reconfigurable loop, where A preset threshold is set. In practice, a judgment method based on the number of rules satisfied, a judgment method based on the Boolean combination of constraints, or other equivalent methods can also be used.

[0148] In some implementations, after completing the rigidity determination and reconfiguration determination, rigid loop data and reconfigurable loop data can be generated respectively. The rigid loop data may include at least a loop identifier, a set of blocking paths, a set of release conditions, a set of external dependency conditions, and a processing priority; the reconfigurable loop data may include at least a loop identifier, a set of blocking paths, a set of alternative paths, a set of boundary preservation conditions, a suggested reconfiguration method, and a processing priority. Both the rigid loop data and the reconfigurable loop data can serve as input for subsequent loop reconnection scheduling processing.

[0149] Furthermore, in response to the service advance blocking data, the rigid loop data and the reconfigurable loop data are subjected to loop reconnection scheduling processing to generate loop reconnection scheduling sequence data, including:

[0150] When the constraint loop that blocks the current service advancement is a rigid loop, based on the blocking convergence node and loop exit node corresponding to the rigid loop, insert a pre-verification service action or an approval connection service action to satisfy the release condition.

[0151] When the constraint loop that blocks the current service advancement is a reconfigurable loop, based on the loop bypass segment and alternative closed path corresponding to the reconfigurable loop, the original service action sequence is processed by alternative service action insertion, service action segmentation and arrangement, or local scope advance processing.

[0152] The inserted service action sequence is subjected to stage connectivity verification, permission boundary preservation verification, and rollback recoverability verification to generate the bypass scheduling sequence data.

[0153] Furthermore, updating the constraint loop network based on the bypass scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service phase includes:

[0154] Based on the connection relationship between the newly added service actions, split service actions, and replacement service actions and the original service actions in the bypass scheduling sequence data, the action constraint connection relationship of the subsequent service stage is reconstructed.

[0155] The reconstructed action constraint connection relationship is subjected to closed-loop simulation processing to determine the closing sequence, blocking release sequence, and service release sequence of each constraint loop under the bypass scheduling sequence.

[0156] Based on the closing sequence, the blocking release sequence, and the service release sequence, the loop closure status data corresponding to the subsequent service phase is generated.

[0157] In some implementations, loopback scheduling is used to provide corresponding advancement methods for identified rigid loops and reconfigurable loops, preventing the original service action sequence from stalling entirely due to local blocking. The loopback scheduling does not bypass existing constraints, but rather reconstructs the advancement path, execution order, and local scope of the original service action sequence to form a new closed loop path, while maintaining business continuity boundaries, permission boundaries, and rollback recovery conditions.

[0158] In some implementations, when a constraint loop blocking the current service's progress is determined to be a rigid loop, subsequent scheduling processes revolve around the release conditions. Based on the blocking convergence node and loop exit node corresponding to the rigid loop, the external conditions, verification conditions, or connection conditions required to release the rigid loop can be identified, and accordingly, pre-verification service actions or approval connection service actions can be inserted into the original service action sequence. The pre-verification service action can be used to verify whether external conditions have been met, whether the current execution domain has the prerequisites for release, and whether the rollback recovery chain is complete; the approval connection service action can be used for status linkage with external approval systems, authorization systems, compliance confirmation modules, or permission activation modules.

[0159] In one optional implementation, when the blocking of a rigid loop is due to incomplete customer authorization or the approval status not transitioning to the executable state, an authorization status verification action, an approval status polling action, an approval result retrieval action, or a compliance confirmation action can be inserted into the original service action sequence. After the newly added action is completed, the closure condition parsing process of the corresponding rigid loop can be retried.

[0160] In some implementations, when a constraint loop blocking the current service progression is determined to be a reconfigurable loop, alternative service action insertion processing, service action segmentation orchestration processing, or local scope advance processing can be performed around the loop connection segment and alternative closed path corresponding to the original service action sequence. The alternative service action insertion processing is used to replace the original service action with an action that has finer control granularity, a smaller impact range, or stronger pre-verification capabilities; the service action segmentation orchestration processing is used to break down a service action executed once into multiple staged execution actions; the local scope advance processing is used to first execute the controlled action within a local execution domain with a smaller impact range, and then decide whether to expand to a larger scope based on the result.

[0161] In one alternative implementation, for reconfigurable loops with clearly alternative paths, candidate alternative paths from the current blocking node to the closed segment of the loop can be identified first, and a feasibility assessment can be performed on each candidate alternative path. The feasibility assessment can at least consider the degree of business continuity disturbance, the degree of permission boundary preservation, the degree of additional resource consumption, the number of required new actions, the impact of execution latency, and the difficulty of rollback recovery. Based on this, a candidate path that meets the boundary preservation requirements and has a lower overall scheduling cost can be selected as the bypassing and advancement path for the current loop.

[0162] In one alternative implementation, candidate bypass paths can be defined. The scheduling cost function is: ,in This represents the cost of business continuity disruption. This indicates the cost of additional resource usage. Indicates the cost of scheduling delay. This represents the complexity cost of rollback recovery. This is a preset weight parameter. Provided that the permission boundary preservation condition and rollback recovery condition are met, it can be selected to... The candidate path with the smallest value is selected as the preferred bypass path. It should be noted that the above formula is only used to illustrate one implementation of alternative path selection processing, and it can also be implemented using other methods based on rule priority, path scoring, or multi-objective constraint screening.

[0163] After completing rigid loop processing or reconfigurable loop processing, a service action sequence is obtained after inserting new actions, splitting original actions, or adjusting their order. To ensure that the reconfigured service action sequence still has executability and recoverability, further checks can be performed on its execution phase connectivity, permission boundary preservation, and rollback recoverability. The phase connectivity check is used to check whether the input-output relationship between adjacent phases is continuous, whether the condition state is transitive, and whether the new action can form a complete progression chain with the original action; the permission boundary preservation check is used to check whether the reconfigured sequence exceeds the original permission scope, whether unauthorized actions are introduced, or whether it leads to the risk of permission escalation; the rollback recoverability check is used to check whether the system can be restored to a controlled state along the rollback verification conditions if execution fails at any phase.

[0164] In one optional implementation, if the reconstructed service action sequence passes stage connectivity verification, permission boundary preservation verification, and rollback recoverability verification, then bypass scheduling sequence data can be generated. The bypass scheduling sequence data may include at least the set of newly added service actions, the set of split service actions, the set of replacement service actions, stage segmentation relationships, action sequence relationships, local scope boundaries, and the above three types of verification results. The bypass scheduling sequence data can serve as direct input for updating the constraint loop network and performing closed-loop simulation processing. (Refer to...) Figure 3 , Figure 3 The logical relationship between loop reconnection scheduling and closure reconstruction is illustrated. In this embodiment, service advancement blocking data serves as the input basis for loop reconnection scheduling processing, and can be diverted to two types of processing paths: one is a rigid loop processing path, and the other is a reconfigurable loop processing path. For rigid loops, pre-verification service actions or approval connection service actions can be inserted around the blocking convergence node and the loop exit node to establish an explicit acceptance chain of release conditions; for reconfigurable loops, alternative service actions, split service actions, or local scope pre-action actions can be inserted around the loop reconnection segment and the alternative closure path to reconstruct the advancement path of the original service action sequence. Figure 3 As shown, rigid loop processing paths and reconfigurable loop processing paths do not form isolated results, but rather are jointly incorporated into the loop scheduling sequence data. After the loop scheduling sequence is generated, stage connectivity verification, permission boundary preservation verification, and rollback recoverability verification must be performed. The verified scheduling sequence can then be further used to form reconfigured action constraint relationships, and based on this, closed-loop simulation processing is performed to obtain the closing sequence, blocking release sequence, and service release sequence, thereby forming loop closure state data. Figure 3 The logic shown can provide a clearer understanding of the continuous control process of "blocking and locating - path diversion - bypass scheduling - closure reconstruction" in this implementation.

[0165] In some implementations, after generating the bypass scheduling sequence data, the constraint loop network can be updated based on this data. Specifically, the action constraint connection relationship of subsequent service stages can be reconstructed according to the succession relationship between the new service action, the split service action, the replacement service action and the original service action, and the loop blocking segment, loop bypass segment and loop closing segment in the original constraint loop can be updated accordingly. If the original blocking segment is partially replaced by the pre-verification action due to the insertion of a new action, the new path formed can be included in the loop bypass segment; if the original blocking segment is released due to the completion of the approval connection action, its subsequent release path can be included in the closing segment; if the original closing segment needs to be split due to changes in the local scope boundary, the scope of the closing segment can be re-divided according to the new stage segmentation relationship.

[0166] In one alternative implementation, the attachment positions of the pre-execution conditions, subsequent impact conditions, and rollback verification conditions corresponding to each service action in the subsequent service stage can be re-determined based on the connection relationship between the newly added service action, split service action, and replacement service action and the original service action. The permission attachment edge, blocking attachment edge, impact transmission edge, and rollback association edge can be reconnected, replaced, or added to rebuild the action constraint attachment relationship of the subsequent service stage.

[0167] In some implementations, after updating the constraint loop network, a closure simulation process can be further performed. This closure simulation process is used to perform timing deduction and state calculation on the updated action constraint linkages before actual execution, to determine the closure sequence, blocking release sequence, and service release sequence corresponding to each constraint loop under the reconstructed service action sequence. This process can filter out reconstructed sequences that are feasible only on local paths but cannot be closed in the overall timing.

[0168] In one alternative implementation, a closed evolution function can be defined for the k-th constraint loop on the reconstructed time series t: ,in This indicates whether the i-th blocking condition in the k-th constraint loop is true at time t. This indicates whether the j-th permissible condition in the k-th constraint loop is true at time t. When, it represents that the corresponding constraint loop reaches a closed state at time t; when At time t, it indicates that the corresponding constraint loop has not yet closed. Furthermore, it can be based on the state of each loop at different times. Based on the changes, the closing time, blocking release time, and release time of each loop are extracted, and the closing sequence, blocking release sequence, and service release sequence are formed accordingly.

[0169] In one optional implementation, the closure sequence characterizes the order in which multiple constraint loops form closures under the current scheduling sequence; the blocking release sequence characterizes the order in which multiple blocking conditions fail or are resolved under the current scheduling sequence; and the service release sequence characterizes the order in which multiple service actions legally enter the execution phase under the current scheduling sequence. Based on the closure sequence, the blocking release sequence, and the service release sequence, loop closure status data corresponding to subsequent service phases can be generated. The loop closure status data includes at least a loop identifier, a closure sequence identifier, a blocking release sequence identifier, a service release sequence identifier, and a target service action execution permission identifier, and serves as the basis for subsequent service phases to determine whether a target service action can enter the execution phase.

[0170] In some implementations, if the closure simulation process indicates that there are still unremovable blocking segments, release order conflicts, or unrecoverable rollback issues under the current bypass scheduling sequence, the current bypass scheduling sequence can be marked as an invalid reconstruction sequence, and candidate alternative path selection processing, stage segmentation processing, or new action insertion processing can be re-triggered until a valid reconstruction sequence that meets the closure requirements is generated. Thus, the bypass scheduling process can be iteratively adjusted under boundary control constraints, and the executability, closureability, and recoverability of the reconstructed sequence can be verified through closure simulation processing.

[0171] Furthermore, the step of executing the corresponding network security service action when the closed loop state data characterizes the target service action as meeting the execution conditions includes:

[0172] When the permission closure condition corresponding to the target service action has been met and the blocking closure condition corresponding to the target service action has been released, the target service action is triggered to enter the execution phase.

[0173] During the execution of the target service action, the execution feedback data and environmental constraint change data corresponding to the target service action are obtained, and constraint backflow determination is performed on the execution feedback data and the environmental constraint change data.

[0174] When the constraint backflow determination result indicates that a new blocking relationship or a new restriction relationship has been formed in the current execution stage, the advancement of subsequent unexecuted service actions is suspended, and the current execution stage is switched to the loop reweaving processing stage.

[0175] Furthermore, the back-injection weaving process performed on the newly added constraint factors generated after the execution of the network security service action, in order to attach the newly added constraint factors to the constraint loop network corresponding to subsequent service actions, and generate scheduling constraint data for the next service phase, includes:

[0176] Identify the scope change information, permission usage information, resource usage information, and fallback constraint information generated after the network security service action is executed, and generate a new set of restriction factors;

[0177] The newly added set of limiting factors is reconnected with the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions to generate incremental constraint data for subsequent stage actions.

[0178] Based on the incremental data of the subsequent stage action constraints, the constraint loop network is subjected to a continuation weaving process to form new blocking segments, new bypass segments, or new closing segments for subsequent service actions, thereby generating the scheduling constraint data for the next service stage.

[0179] In some implementations, feedback, constraint backflow, and continuation weaving processes are used to couple the aforementioned closed-loop simulation results with the dynamic environmental changes during the actual execution phase, thereby preventing the service action from detaching from the constraint control link once it is released. This processing does not involve post-execution recording of the results, but rather continuously identifies newly emerging constraint relationships, boundary change relationships, and restoration constraint relationships during the execution process after the service action enters the execution phase, further expanding the constraint control structure from a single-stage closed-loop control to a stage-progressive closed-loop control structure.

[0180] In some implementations, when the permission closure condition corresponding to a certain target service action has been met and the blocking closure condition has been released, the target service action can be triggered to enter the execution phase based on the target service action execution permission identifier corresponding to the aforementioned loop closure state data. The execution phase can be implemented by a policy execution agent, a flow control module, an isolation control module, an account handling module, a verification detection module, or other action execution units. To maintain a continuous connection between the execution phase and the constraint control link, execution feedback acquisition and environmental constraint change acquisition can be initiated simultaneously after the target service action enters the execution phase.

[0181] In some implementations, the execution feedback data is used to characterize the degree of completion, scope of impact, abnormal states, resource usage changes, and rollback preparation status of the target service action during actual execution. The execution feedback data may include at least: execution action identifier, execution start time, execution end time, execution progress identifier, execution result identifier, scope change identifier, resource usage increment, abnormal event identifier, and rollback preparation status. The method for collecting execution results can be based on log retrieval, status polling, event reporting, message bus feedback, or other methods well known to those skilled in the art.

[0182] In some implementations, the environmental constraint change data is used to characterize the changes in the constraint environment caused by changes in external conditions, execution domain status, or related system status during the current execution phase. The environmental constraint change data may include at least: approval status change information, authorization status change information, permission activation status change information, workload change information, resource reserve change information, maintenance window status change information, rollback condition change information, and execution domain boundary change information. By collecting execution feedback data and environmental constraint change data in parallel, dynamic constraint observation results within the current execution phase can be formed.

[0183] In some implementations, the constraint backflow determination process is used to identify whether new blocking relationships or new restrictive relationships have been formed in the current execution phase due to changes in the actual execution result of the action or changes in the environmental state. It should be noted that the backflow determination does not merely check whether the execution was successful, but rather detects whether the current execution result has new constraints on the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions. For example, if the execution of an action leads to increased local resource consumption, persistent permission usage, incomplete business domain switching, or temporary restrictions on the rollback path, these changes may all form new blocking relationships or new restrictive relationships in subsequent service phases.

[0184] In one alternative implementation, the execution feedback data of the current execution phase can be represented as a vector. Representing environmental constraint change data as vectors Represent the current closed loop state data as a vector. And construct a constraint reflux determination function: A represents the execution feedback mapping matrix, which maps execution feedback data to the dimensions of scope change, resource consumption, and abnormal events; B represents the environmental constraint change mapping matrix, which maps environmental change data to the dimensions of approval, authorization, permissions, time period, and load. This represents the coupling term between execution feedback and environmental changes, used to measure the combined impact of the two on the constrained state. This indicates the offset of the current execution phase relative to the closed state of the previous phase; This indicates the blocking strength compensation items that have been lifted during the current execution phase; Preset weight parameters; This is a normalized mapping function. In one optional determination method, when... At that time, it can be determined that a new blocking relationship or a new restrictive relationship is formed in the current execution phase, among which... Preset judgment threshold.

[0185] In another alternative implementation, new blocking relationships and newly added restrictive relationships can be further distinguished and determined. Specifically, a relationship type mapping function can be constructed based on the scope change component, permission occupancy component, resource occupancy component, and fallback constraint component in the backflow determination result. .when When the output corresponds to "prohibit subsequent actions and allow" or "blocking closure condition is re-established," it can be considered a new blocking relationship; when When the output corresponds to "subsequent actions require additional preconditions" or "the execution scope of subsequent actions needs to be narrowed," it can be identified as a newly added constraint relationship. Using this distinction method allows for more targeted reweaving of subsequent loops.

[0186] In some implementations, when the constraint backflow determination result indicates that a new blocking relationship or a new restriction relationship has been formed in the current execution stage, the advancement of subsequent unexecuted service actions can be suspended, and the current execution stage can be switched to the loop reweaving processing stage. Suspending subsequent advancement does not terminate the entire service scheduling process, but rather temporarily freezes subsequent service actions that have not yet entered the execution stage into a pending reweaving state, thereby preventing the continued release of subsequent actions before the new constraint relationship is incorporated into the control structure. The loop reweaving processing stage can re-invoke the previously described processing procedures so that the newly added constraints can participate in the loop division, state determination, conflict location, and bypass scheduling in subsequent stages.

[0187] In some implementations, the generation of the new set of constraint factors is used to standardize newly generated constraint information within the current execution phase into structured objects that can participate in subsequent scheduling and control. Specifically, scope change information, permission occupancy information, resource occupancy information, and rollback constraint information can be identified from execution feedback data and environmental constraint change data, and converted into new constraint factors. The scope change information is used to characterize whether the current execution action changes the target asset scope, target user scope, or execution domain boundary that subsequent actions can apply; the permission occupancy information is used to characterize whether the current execution action temporarily occupies a certain type of execution permission, approval quota, or authorized time period; the resource occupancy information is used to characterize whether the current execution action occupies bandwidth, computing power, storage, number of connections, or concurrent processing quota; and the rollback constraint information is used to characterize whether the current execution action introduces new rollback dependencies, recovery order requirements, or recovery pre-verification requirements.

[0188] In one alternative implementation, the set of newly added restrictive factors can be represented as: ,in This represents the characteristic quantity of the change in the scope of the u-th newly added restriction factor. This indicates the characteristic quantity of permission occupancy. This represents a characteristic quantity of resource usage. This represents the backoff constraint feature quantity. This represents the stage duration coefficient of the newly added limiting factor. Here, q represents the number of new constraint factors, which are preset combination parameters. This construction method allows the complex changes occurring during the execution phase to be compressed into standardized constraint objects capable of participating in subsequent relationship joining and loop continuation.

[0189] To more clearly illustrate the closed-loop evolution, backflow triggering, and continuation weaving relationships during the execution phase, refer to... Figure 4 , Figure 4 This diagram illustrates the relationship between loop closure evolution, constraint backflow triggering, and the continuation weaving of the next service phase. Figure 4 In the upper dual-axis timing evolution diagram, the horizontal axis represents time t, the left vertical axis represents loop closure, and the right vertical axis represents the reflux determination value. The solid line function curve in the diagram represents the loop closure evolution function. This characterizes the process of the corresponding constraint loop evolving from an open state to a closed state during the execution phase; the dashed function curve in the figure represents the constraint backflow determination function. This is used to characterize the change process of the reflux judgment result over time, formed by superimposing execution feedback data and environmental constraint change data. For example... Figure 4 As shown, after the target service action enters the execution phase, the solid-line function curve evolves towards closure as the permission conditions are continuously satisfied and the blocking conditions are gradually released. Meanwhile, the dashed-line function curve reflects the combined impact of the current execution result and changes in the external environment on the constraint state. When the dashed-line function curve exceeds the predetermined backflow determination threshold, it indicates that a new blocking relationship or a new constraint relationship has been formed in the current execution phase. At this point, the current execution phase can be switched to the loop reweaving processing phase. Figure 4 The schematic diagram of the continuation weaving structure in the lower middle section further illustrates how the newly added set of constraint factors is reattached to the subsequent service action condition structure, thereby forming new blocking segments, new bypass segments, or new closed segments. Therefore, the next service phase does not simply reuse the control results of the previous phase, but continues under the constraints of the updated constraint loop network.

[0190] In some implementations, after the new set of constraint factors is generated, it can be further re-attached to the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions to generate incremental constraint data for subsequent stage actions. The purpose of this re-attaching process is to ensure that the new constraint factors do not exist as independent additional records, but rather enter the control structure of subsequent service actions, becoming a component affecting the release, blocking, and closure of subsequent actions. Specifically, the new constraint factors can be attached to the condition structure of the corresponding service action based on the matching relationship between the target of action, the matching relationship between the action stage, and the matching relationship between the new constraint factors and the subsequent service actions.

[0191] In one alternative implementation, a new set of constraint factors can be defined. Set of subsequent service actions The attachment operator is: ,in This represents the object matching weight between the u-th newly added restriction factor and the v-th subsequent service action. Indicates the matching coefficient during the action phase. Let represent the compatibility coefficient for releasing the condition, r represent the number of subsequent service actions, and q represent the number of newly added constraint factors. Based on the aforementioned attachment operator, an incremental matrix of action constraints for subsequent stages can be generated. : ,in The matrix represents the original conditional structure matrix for subsequent service actions, and ⊙ represents the condition superposition operator. The incremental constraint matrix for subsequent stage actions can be used to characterize the incremental changes in the pre-execution conditions, subsequent influence conditions, and rollback verification conditions of subsequent service actions after the introduction of new constraint factors.

[0192] In some implementations, based on incremental constraint data for subsequent stages, a continuation weaving process can be performed on the constraint loop network. This continuation weaving process recouples the newly generated constraint factors from the current execution stage with the existing loop network in subsequent service stages, causing subsequent service actions to re-form blocking segments, bypass segments, or closed segments under the new constraint boundaries. It should be noted that this continuation weaving process is not simply adding new nodes to the existing network; rather, it requires re-analyzing, based on the coupling results of the newly generated constraint factors and the subsequent action condition structure, which existing open paths have been transformed into blocking paths, which existing blocking paths can be transformed into bypass paths through local adjustments, and which existing waiting paths can be transformed into closed paths after the new conditions are met.

[0193] In one alternative implementation, if a newly added constraint factor corresponds to a precondition for increased resource consumption and affects multiple subsequent service actions, a new blocking segment can be formed in the existing loop network; if a newly added constraint factor corresponds to a shrinking local scope that allows execution within the reduced scope, a new bypass segment can be formed in the existing loop network; if a newly added constraint factor corresponds to a new verification action that allows subsequent actions to enter the release state after completion, a new closing segment can be formed in the existing loop network. Therefore, the loop structure in the subsequent service phase will no longer simply follow the control pattern of the previous phase, but will form a phased control pattern that includes incremental constraint relationships.

[0194] In some implementations, after the continuation weaving process is completed, scheduling constraint data for the next service phase can be generated. This scheduling constraint data may include at least: newly added constraint factor set identifiers, incremental data of subsequent phase action constraints, updated loop segment structure identifiers, subsequent phase blocking relationship identifiers, subsequent phase bypass relationship identifiers, and subsequent phase closure condition identifiers. This scheduling constraint data can serve as the input basis for re-executing constraint classification, relationship resolution, state determination, conflict location, and bypass scheduling in the next service phase, thereby forming a continuously progressive phase control link in the entire network security service scheduling process.

[0195] To further illustrate the engineering implementation methods of the aforementioned execution feedback, constraint backflow, and continuation weaving processes, typical deployment scenarios can be used for explanation. The following examples are only used to illustrate the application forms of the embodiments of the present invention in different network environments and do not constitute a limitation on specific deployment environments.

[0196] In a government and enterprise cloud environment implementation scenario, the target network environment includes a business access layer, an application service layer, a permission management layer, and a security operations platform. The service objectives corresponding to security service requests may include access restrictions, policy issuance, and account freezing. The constraint information associated with this service objective may include customer authorization status, compliance confirmation status, peak business window restrictions, and resource usage limit restrictions. After constraint classification and relationship parsing, the above constraint information can be categorized into customer authorization constraints, compliance execution constraints, operation and maintenance time period constraints, and resource limit constraints. These are then respectively attached to the pre-execution conditions, subsequent impact conditions, and rollback verification conditions corresponding to access restriction actions, policy issuance actions, and account freezing actions. In this scenario, if the customer authorization status is not yet complete, the approval constraints associated with policy issuance and account freezing actions will form an approval blocking loop; if the current time period is during a peak business window, the time period constraints associated with access restriction actions and policy issuance actions will form a time period restriction loop. After the loop attributes are determined, the approval blocking loop usually manifests as a rigid loop, which is released from the condition that the customer's authorization status has reached the effective condition or the approval process has been completed; the time-limited loop may manifest as a reconfigurable loop in some cases, which can form an alternative closed path through local scope processing or phased execution.

[0197] In one optional implementation, for approval blocking loops, authorization status verification and approval result retrieval actions can be inserted into the service action sequence, bringing authorization status changes that were originally outside the process into the service action sequence. For time-limited loops, access restriction actions originally targeting all target assets can be split into local business domain access restriction actions and global access restriction actions. Local actions are first executed in low-impact business domains to verify business continuity boundaries and fallback paths. If the local execution result is normal and no new blocking relationship is introduced, the global policy issuance action can continue in subsequent stages. In this scenario, after the local access restriction action enters the execution stage, its execution feedback data and environmental constraint change data can be collected. If the execution feedback indicates that the local policy issuance has led to an increase in the consumption of some shared resources, and the environmental constraint change data indicates that the authorization time window has shortened, then the backflow determination result can represent the formation of new resource consumption restriction relationships and time-limited compression restriction relationships. At this point, pending global policy issuance and account freezing actions can be suspended. Newly added constraint factors resulting from changes in resource usage, time periods, and local scope can be reattached to the subsequent action condition structure, thereby performing a reconnection weaving process on the subsequent loop network. After reconnection weaving, new resource blocking segments and new local bypass segments can be formed in the subsequent service phase, and the closure simulation and release judgment will be re-executed in the next phase.

[0198] In an industrial control network (ICS) environment implementation scenario, the target network environment includes a production control domain, a monitoring and acquisition domain, a network boundary protection domain, and an operation and maintenance isolation domain. The service objectives corresponding to security service requests may include isolation control, port management, and traffic mirroring. Constraint information associated with these service objectives may include production continuity constraints, maintenance window constraints, permission boundary constraints, and rollback verification constraints. Because ICS environments typically have higher requirements for the timing of action execution, the scope of impact, and recovery capabilities, the same service action is often subject to multiple strong constraints simultaneously. In this scenario, if the maintenance window has not yet opened, isolation control actions and port management actions can jointly form a time-limited blocking loop; if the rollback verification chain has not yet been established, traffic mirroring actions and isolation control actions can form a rollback verification blocking loop; if the permission boundary requires the current operation to be limited to a specific device group, the permission boundary constraint connected to the global port management action can form a scope-limiting loop. After attribute determination, maintenance window blocking loops and rollback verification blocking loops are usually rigid loops, while permission boundary limiting loops can be transformed into reconfigurable loops in some cases through preliminary processing of local scopes.

[0199] In one optional implementation, maintenance window status verification actions can be inserted into maintenance window blocking loops, and rollback path detection and recovery link confirmation actions can be inserted into rollback verification blocking loops. Subsequently, for permission boundary restriction loops, global port control actions are broken down into device group-level port restriction actions and cross-group port restriction actions. Port restrictions are first executed within local device groups with clearly defined permission coverage to verify the impact on production continuity and recovery links. If the execution results within the local device group are normal and no new rigid blockage is formed, the scope can be gradually expanded. In this scenario, after the port restriction actions of a local device group are executed, if the execution feedback data indicates that the bandwidth redundancy of a certain acquisition link is lower than the preset value, and the environmental constraint change data indicates that the remaining time of the current maintenance window is insufficient to support cross-group extended execution, the backflow determination result can characterize the formation of new resource occupancy blocking relationships and maintenance time period restriction relationships. At this time, the advancement of subsequent cross-group port restriction actions can be stopped, and the newly added bandwidth occupancy factor, remaining window compression factor, and local recovery constraint factor can be included in the new restriction factor set. By reattaching the newly added constraint factors to the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions, new incremental constraint data for subsequent stage actions can be formed, and new blocking segments and new closing segments can be further generated on the original loop network. Thus, subsequent service stages can re-form a new scheduling and control sequence around the local mirror acquisition action, recovery verification action, and opportunistic expansion action.

[0200] At the engineering implementation level, the constraint acquisition, action scheduling, state synchronization, log reporting, message passing, and graph structure storage processing involved in the aforementioned implementation scenarios can be collaboratively implemented by a centralized control platform, a distributed execution agent, and a state synchronization module. Constraint factor data, action constraint connection graphs, constraint loop networks, and state data generated at each stage can be stored in relational databases, graph databases, key-value stores, or other data storage media commonly used in this field. Execution feedback data and environmental constraint change data can be sent to the feedback judgment module via event streams, polling, or message feedback. Closed-loop simulation processing and continuation weaving processing can be executed by an independent loop analysis engine or collaboratively implemented by the scheduling control module and the graph analysis module. Those skilled in the art can adaptively select the above engineering implementation methods based on the target network environment scale, action execution frequency, and deployment resource conditions.

[0201] Based on the description of the above embodiments of the network security service scheduling method based on constraint loop weaving, this application also discloses a network security service scheduling system based on constraint loop weaving. The network security service scheduling system based on constraint loop weaving can be a computer program (including program code) that runs the aforementioned network security service scheduling method based on constraint loop weaving. Please see the appendix. Figure 5 As shown, the network security service scheduling system based on constraint loop weaving can operate the following units:

[0202] The constraint acquisition and parsing unit 110 is used to acquire the security service request corresponding to the target network environment and the constraint factor data associated with the security service request. The constraint factor data includes business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data. The constraint factor data is processed for constraint classification and constraint relationship parsing to generate first constraint identifier data representing constraint permission relationship and second constraint identifier data representing constraint blocking relationship, respectively.

[0203] The loop construction state generation unit 120 is used to construct a constraint loop network based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request. The constraint loop network is used to characterize the connection relationship between multiple constraint factors and each service action, as well as the dependency restriction relationship, blocking transmission relationship, and closure trigger relationship formed by each service action under the action of multiple constraint factors. According to the constraint loop network, loop connection state data corresponding to each service action is generated. The loop connection state data is used to characterize whether the current service action is in an executable state, a blocked state, or a loopable state.

[0204] The conflict location attribute determination unit 130 is used to perform loop conflict location processing on the constraint loop network, identify constraint blocking paths that block the current service advancement, and determine the loop attributes of each constraint loop in the constraint loop network based on whether the release conditions of the corresponding constraint loop can be achieved by service action rearrangement, execution order adjustment, or additional verification action insertion, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions. This generates rigid loop data and reconfigurable loop data. Based on the rigid loop data, the reconfigurable loop data, and the loop attachment status data, service advancement blocking data is generated.

[0205] The loop routing scheduling closure update unit 140 is used to respond to the service advancement blocking data and perform loop routing scheduling processing on the rigid loop data and the reconfigurable loop data. The loop routing scheduling processing includes one or more of the following: alternative service action insertion processing, service action segmentation and orchestration processing, pre-verification action pre-processing, and local scope advance processing, so as to reconstruct the loop closure path corresponding to the original service action sequence without breaking the rigid loop release condition, generate loop routing scheduling sequence data, and update the constraint loop network based on the loop routing scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service stage.

[0206] The execution backflow continuation unit 150 is used to execute the corresponding network security service action when the target service action is characterized by the closed loop state data and the execution conditions are met. It also performs backflow weaving processing on the newly added constraint factors generated after the execution of the network security service action, so as to attach the newly added constraint factors to the constraint loop network corresponding to the subsequent service action, generate the scheduling constraint data of the next service stage, and enable the subsequent service stage to continue to enter the scheduling and advancement process under the constraints of the updated constraint loop network.

[0207] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.

Claims

1. A network security service scheduling method based on constraint loop weaving, characterized in that, include: Obtain the security service request corresponding to the target network environment and the constraint factor data associated with the security service request. The constraint factor data includes business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data. The constraint factor data is subjected to constraint classification processing and constraint relationship parsing processing to generate first constraint identifier data representing constraint permission relationship and second constraint identifier data representing constraint blocking relationship respectively; Based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request, a constraint loop network is constructed. The constraint loop network is used to characterize the connection relationship between multiple constraint factors and each service action, as well as the dependency restriction relationship, blocking transmission relationship, and closure trigger relationship formed by each service action under the action of multiple constraint factors. According to the constraint loop network, loop connection status data corresponding to each service action is generated. The loop connection status data is used to characterize whether the current service action is in an executable state, a blocked state, or a bypassable state. The constraint loop network is processed to locate loop conflicts, identify constraint blocking paths that block the current service advancement, and determine whether the release conditions of the corresponding constraint loop can be achieved by service action rearrangement, execution order adjustment, or insertion of additional verification actions, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions. The loop attributes of each constraint loop in the constraint loop network are determined, generating rigid loop data and reconfigurable loop data. Based on the rigid loop data, the reconfigurable loop data, and the loop attachment status data, service advancement blocking data is generated. In response to the service advancement blocking data, loop bypass scheduling processing is performed on the rigid loop data and the reconfigurable loop data. The loop bypass scheduling processing includes one or more of the following: alternative service action insertion processing, service action segmentation and orchestration processing, pre-verification action pre-processing, and local scope advance processing, so as to reconstruct the loop closure path corresponding to the original service action sequence without breaking the rigid loop release condition, generate bypass scheduling sequence data, and update the constraint loop network based on the bypass scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service stage. When the closed loop state data indicates that the target service action meets the execution conditions, the corresponding network security service action is executed, and the newly added constraint factors generated after the execution of the network security service action are back-injected and woven to attach the newly added constraint factors to the constraint loop network corresponding to the subsequent service action, thereby generating the scheduling constraint data for the next service stage, so that the subsequent service stage can continue to enter the scheduling and advancement process under the constraints of the updated constraint loop network.

2. The network security service scheduling method based on constraint loop weaving according to claim 1, characterized in that, The constraint factor data is subjected to constraint classification processing and constraint relationship parsing processing to generate first constraint identifier data and second constraint identifier data representing constraint permission relationships and constraint blocking relationships, respectively, including: The constraint factor data is classified and mapped according to the constraint source attribute, constraint action stage attribute, and constraint release dependency attribute to generate constraint category index data; Based on the constraint category index data, identify the permission and blocking conditions for each constraint factor on the corresponding service action, and generate constraint action pointing data; Based on the constraint action pointing data, the constraint relationship that allows the corresponding service action to enter the execution orchestration is encoded to generate the first constraint identifier data, and the constraint relationship that restricts the corresponding service action from entering the execution orchestration is encoded to generate the second constraint identifier data.

3. The network security service scheduling method based on constraint loop weaving according to claim 1, characterized in that, The step of constructing a constraint loop network based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request includes: Obtain the pre-execution conditions, subsequent influence conditions, and rollback verification conditions corresponding to each service action in the service action sequence; Based on the first constraint identification data and the second constraint identification data, each constraint factor is attached to the pre-execution condition, subsequent influence condition and rollback verification condition of the corresponding service action to generate an action constraint attachment diagram. The action constraint connection diagram contains multiple service actions and their corresponding constraint factors that have interdependent, mutually blocking, or sequential constraints. Loop weaving is performed to generate a constraint loop network including loop entry segment, loop blocking segment, loop bypass segment, and loop closing segment.

4. The network security service scheduling method based on constraint loop weaving according to claim 3, characterized in that, The step of generating loop connection status data corresponding to each service action based on the constraint loop network includes: The closure condition analysis is performed on each constraint loop in the constraint loop network to obtain the permissive closure condition and the blocking closure condition corresponding to each constraint loop; Based on the attachment position of each service action in the constrained loop network, the type of the loop segment to which it belongs, the number of times it is blocked, and the availability of alternative closed paths, determine the state judgment parameters corresponding to each service action. Based on the permission closure condition, the blocking closure condition, and the state determination parameters, the loop connection status data representing whether the current service action is in an executable state, a blocked state, or a loopable state is generated.

5. The network security service scheduling method based on constraint loop weaving according to claim 1, characterized in that, The process of performing loop conflict localization processing on the constraint loop network, identifying constraint blocking paths that block the current service advancement, and determining the loop attributes of each constraint loop in the constraint loop network to generate rigid loop data and reconfigurable loop data includes: Perform blocking propagation tracing processing on each constraint loop in the constraint loop network to determine the loop start blocking point, blocking transmission node, blocking convergence node and loop exit node that cause the current service action to be unable to proceed, and generate constraint blocking path data. Based on whether the release conditions corresponding to each constraint loop depend on external approval completion, customer authorization completion, permission change effect, compliance confirmation completion, or rollback verification pass, rigidity determination is performed on each constraint loop to generate the rigid loop data. Based on whether the release conditions corresponding to each constraint loop can be satisfied by service action rearrangement, execution scope shrinkage, pre-verification insertion, or partial replacement execution, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions, the reconfigurable loop data is generated.

6. The network security service scheduling method based on constraint loop weaving according to claim 5, characterized in that, In response to the service advance blocking data, the rigid loop data and the reconfigurable loop data are subjected to loop reconnection scheduling processing to generate loop reconnection scheduling sequence data, including: When the constraint loop that blocks the current service advancement is a rigid loop, based on the blocking convergence node and loop exit node corresponding to the rigid loop, insert a pre-verification service action or an approval connection service action to satisfy the release condition. When the constraint loop that blocks the current service advancement is a reconfigurable loop, based on the loop bypass segment and alternative closed path corresponding to the reconfigurable loop, the original service action sequence is processed by alternative service action insertion, service action segmentation and arrangement, or local scope advance processing. The inserted service action sequence is subjected to stage connectivity verification, permission boundary preservation verification, and rollback recoverability verification to generate the bypass scheduling sequence data.

7. A network security service scheduling method based on constraint loop weaving according to claim 6, characterized in that, The step of updating the constraint loop network based on the bypass scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service phase includes: Based on the connection relationship between the newly added service actions, split service actions, and replacement service actions and the original service actions in the bypass scheduling sequence data, the action constraint connection relationship of the subsequent service stage is reconstructed. The reconstructed action constraint connection relationship is subjected to closed-loop simulation processing to determine the closing sequence, blocking release sequence, and service release sequence of each constraint loop under the bypass scheduling sequence. Based on the closing sequence, the blocking release sequence, and the service release sequence, the loop closure status data corresponding to the subsequent service phase is generated.

8. The network security service scheduling method based on constraint loop weaving according to claim 1, characterized in that, When the closed-loop state data indicates that the target service action meets the execution conditions, the corresponding network security service action is executed, including: When the permission closure condition corresponding to the target service action has been met and the blocking closure condition corresponding to the target service action has been released, the target service action is triggered to enter the execution phase. During the execution of the target service action, the execution feedback data and environmental constraint change data corresponding to the target service action are obtained, and constraint backflow determination is performed on the execution feedback data and the environmental constraint change data. When the constraint backflow determination result indicates that a new blocking relationship or a new restriction relationship has been formed in the current execution stage, the advancement of subsequent unexecuted service actions is suspended, and the current execution stage is switched to the loop reweaving processing stage.

9. A network security service scheduling method based on constraint loop weaving according to claim 8, characterized in that, The step of back-injecting and weaving new constraint factors generated after the execution of the network security service action to attach the new constraint factors to the constraint loop network corresponding to subsequent service actions and generate scheduling constraint data for the next service phase includes: Identify the scope change information, permission occupation information, resource occupation information, and fallback constraint information generated after the network security service action is executed, and generate a new set of restriction factors; The newly added set of limiting factors is reconnected with the pre-execution conditions, subsequent impact conditions, and rollback verification conditions of subsequent service actions to generate incremental constraint data for subsequent stage actions. Based on the incremental data of the subsequent stage action constraints, the constraint loop network is subjected to a continuation weaving process to form new blocking segments, new bypass segments, or new closing segments for subsequent service actions, thereby generating the scheduling constraint data for the next service stage.

10. A network security service scheduling system based on constraint loop weaving, characterized in that, The system includes: The constraint acquisition and parsing unit is used to acquire the security service request corresponding to the target network environment and the constraint factor data associated with the security service request. The constraint factor data includes business continuity constraint data, system change boundary constraint data, account permission boundary constraint data, compliance execution constraint data, operation and maintenance window constraint data, customer authorization constraint data, and resource usage limit constraint data. The unit performs constraint classification processing and constraint relationship parsing processing on the constraint factor data to generate first constraint identifier data representing constraint permission relationship and second constraint identifier data representing constraint blocking relationship, respectively. The loop construction state generation unit is used to construct a constraint loop network based on the first constraint identifier data, the second constraint identifier data, and the service action sequence corresponding to the security service request. The constraint loop network is used to characterize the connection relationship between multiple constraint factors and each service action, as well as the dependency restriction relationship, blocking transmission relationship, and closure trigger relationship formed by each service action under the action of multiple constraint factors. According to the constraint loop network, loop connection state data corresponding to each service action is generated. The loop connection state data is used to characterize whether the current service action is in an executable state, a blocked state, or a loopable state. The conflict location attribute determination unit is used to perform loop conflict location processing on the constraint loop network, identify constraint blocking paths that block the current service advancement, and determine the loop attributes of each constraint loop in the constraint loop network based on whether the release conditions of the corresponding constraint loop can be achieved by service action rearrangement, execution order adjustment, or additional verification action insertion, while maintaining the business continuity boundary, permission boundary, and rollback recovery conditions. This generates rigid loop data and reconfigurable loop data. Based on the rigid loop data, the reconfigurable loop data, and the loop attachment status data, service advancement blocking data is generated. The loop routing scheduling closure update unit is used to respond to the service advancement blocking data and perform loop routing scheduling processing on the rigid loop data and the reconfigurable loop data. The loop routing scheduling processing includes one or more of the following: alternative service action insertion processing, service action segmentation and orchestration processing, pre-verification action pre-processing, and local scope advance processing, so as to reconstruct the loop closure path corresponding to the original service action sequence without breaking the rigid loop release condition, generate loop routing scheduling sequence data, and update the constraint loop network based on the loop routing scheduling sequence data to obtain the loop closure state data corresponding to the subsequent service stage. The execution backflow continuation unit is used to execute the corresponding network security service action when the target service action is characterized by the closed loop state data and the execution conditions are met. It also performs backflow weaving processing on the newly added constraint factors generated after the execution of the network security service action, so as to attach the newly added constraint factors to the constraint loop network corresponding to the subsequent service action, generate the scheduling constraint data of the next service stage, and enable the subsequent service stage to continue to enter the scheduling and advancement process under the constraints of the updated constraint loop network.

Images