Method and system for dynamic scheduling of ssl traffic based on policy intelligent orchestration

Abstract

The application provides a SSL flow dynamic scheduling method and system based on policy intelligent arrangement, the method comprises the following steps: collecting handshake fields, certificate structure abstracts and connection statistical behaviors of SSL encrypted flows, and generating uniform structured feature vectors; combining a policy template, a decryption node state and a key state, calculating a deployment credibility score, and selecting at least two combinations with the highest score to form candidate deployment tasks; determining a deployment granularity level and a life cycle according to flow activity, key heat and resource cost; issuing a deployment instruction through an SDN control channel, and performing key fingerprint and policy version checking on the node side to ensure safety and effectiveness. The application realizes accurate matching, dynamic optimization and reliable deployment of SSL policies under multi-dimensional constraints, and improves the intelligent level and system stability of encrypted flow management.

Description

Technical Field

[0001] This invention belongs to the field of data processing, and in particular relates to a method and system for dynamic scheduling of SSL traffic based on policy-based intelligent orchestration. Background Technology

[0002] With the widespread adoption of encrypted communication, the SSL protocol has become the most common secure transmission mechanism on the Internet. While its encryption protection of data content enhances privacy, it also significantly reduces the ability of operations, security auditing, and compliance regulatory departments to effectively identify and manage network traffic. Traditional encrypted traffic processing methods mostly rely on shallow features, fixed rules, or static information such as ports for classification. When faced with constantly evolving encrypted business behaviors, complex multi-node network environments, and multi-type certificate systems, it is difficult to guarantee identification accuracy and real-time performance. Meanwhile, existing SSL decryption policies are typically distributed through static configuration, lacking comprehensive awareness of multiple factors such as node resources, traffic behavior, and policy hit rate. When traffic experiences sudden increases, node load imbalances, or dynamic changes in business types, policy deployment is prone to lag, redundancy, or mismatch issues. Furthermore, key management, as an indispensable core facility in SSL decryption scenarios, directly determines whether a policy can function correctly based on its lifecycle status, usage frequency, and rotation progress. However, existing solutions generally do not deeply link key status with the policy scheduling process, leading to security risks such as deployment failures and decryption interruptions during key rotation periods, low-activity periods, or high-risk periods. Faced with a large-scale network environment with multiple nodes, multiple policies, and multiple keys operating in parallel, existing technologies lack a complete solution that can perform unified modeling from multiple dimensions such as data characteristics, policy templates, node resources, and key status, and on this basis realize policy deployment path planning, granular optimization, and lifecycle control. Summary of the Invention

[0003] The purpose of this invention is to design a dynamic scheduling method and system for SSL traffic based on policy-based intelligent orchestration, which can realize intelligent management of the entire process of policy from input features to deployment and execution, improve policy matching accuracy, resource utilization efficiency and system stability, and realize collaborative control of policies, nodes and keys in complex network environments.

[0004] To achieve the above objectives, a method for dynamic scheduling of SSL traffic based on policy-driven intelligent orchestration is provided in a first aspect of the present invention, the method comprising:

[0005] Collect handshake field information, certificate structure digest field and connection statistics behavior field of SSL encrypted traffic, and normalize and encode the fields to generate a structured feature vector with a unified dimension;

[0006] The structured feature vectors are jointly modeled with the preset set of policy templates, decryption node status information and key status information. The deployment credibility score of each SSL connection under each policy template and each decryption node combination is calculated. At least two combinations with the highest deployment credibility scores are selected to form a candidate deployment task set.

[0007] For each item in the candidate deployment task set, the final deployment granularity level is determined by combining the traffic activity of the corresponding SSL connection, the popularity of the policy template bound key, and the resource consumption cost of different granularity policy templates, and the policy deployment lifecycle is calculated based on the traffic activity and key popularity.

[0008] Deployment instructions, which include policy template identifiers, deployment granularity levels, target decryption nodes, and deployment lifecycles, are sent to the corresponding decryption nodes via the SDN control channel. Before sending, the deployment instructions are prioritized based on deployment trustworthiness scores, target node control channel utilization, and deployment lifecycles. Key fingerprint consistency verification and policy version hash verification are performed on the node side to ensure that the policy takes effect securely.

[0009] Furthermore, the handshake field information includes the TLS protocol version, the number of cipher suites, whether the SNI field is included, and whether session recovery is enabled.

[0010] Furthermore, the certificate structure digest field includes the master certificate digest hash, the number of certificate chain levels, and the signature algorithm identifier.

[0011] Furthermore, the connection statistics behavior fields include handshake completion delay, direction sequence of the first ten packets, length sequence of the first ten packets, and number of TCP retransmissions.

[0012] Furthermore, the calculation of the deployment credibility score introduces a resource conflict factor and a key stability suppression term. The resource conflict factor is determined based on the CPU utilization rate, policy slot number, memory usage ratio, and deployment policy conflict count of the target decryption node. The key stability suppression term is determined based on the deployment frequency, rotation frequency, and number of effective policies of the key in the past time window.

[0013] Furthermore, the deployment granularity is divided into at least three levels from coarse to fine. The finer the granularity, the higher the resource consumption cost. Moreover, high-risk mitigation items inhibit the deployment of high-granularity strategies when the deployment credibility score is below the threshold.

[0014] Furthermore, the deployment lifecycle of the strategy extends as traffic activity increases and shortens as key popularity decreases.

[0015] Furthermore, during the deployment instruction issuance process, if the target decryption node detects that the fingerprint of the policy binding key is inconsistent with the local key or that the key has expired, it will refuse to deploy and return a failure flag to the control center.

[0016] Furthermore, each policy configuration includes a version hash value generated by concatenating the policy rule content, granularity level, and binding key number. The decryption node verifies the version hash value before loading the policy to avoid policy version conflicts.

[0017] A second aspect of the present invention provides a policy-based intelligent orchestration-based dynamic SSL traffic scheduling system, the system comprising:

[0018] The traffic feature extraction module is used to collect handshake field information, certificate structure digest field and connection statistics behavior field of SSL encrypted traffic, and to normalize and encode the handshake field information, certificate structure digest field and connection statistics behavior field to generate a structured feature vector with a unified dimension.

[0019] The strategy orchestration center module is used to jointly model the structured feature vector with the preset set of strategy templates, decryption node status information and key status information, calculate the deployment credibility score of each SSL connection under each combination of strategy templates and decryption nodes, and select at least two combinations with the highest deployment credibility scores to form a candidate deployment task set.

[0020] The granularity and lifecycle decision module is used to determine the final deployment granularity level for each item in the candidate deployment task set, taking into account the traffic activity of the corresponding SSL connection, the popularity of the policy template bound key, and the resource consumption cost of different granularity policy templates, and to calculate the policy deployment lifecycle based on the traffic activity and key popularity.

[0021] The policy execution control module is used to send deployment instructions, which include policy template identifier, deployment granularity level, target decryption node, and deployment lifecycle, to the corresponding decryption node through the SDN control channel. Before sending, the deployment instructions are prioritized according to deployment trustworthiness score, target node control channel utilization, and deployment lifecycle. Key fingerprint consistency verification and policy version hash verification are performed on the node side to ensure that the policy takes effect securely.

[0022] The beneficial technical effects of the present invention are at least as follows:

[0023] To address the aforementioned issues, this invention provides a method and system for dynamic SSL traffic scheduling based on policy-based intelligent orchestration. It forms a complete policy scheduling closed loop through four stages: feature modeling, policy matching, deployment optimization, and execution control. The system first constructs a structured feature representation for encrypted traffic, fusing handshake behavior, certificate information, and connection statistics to provide computable input for policy matching. Then, a multi-dimensional scoring mechanism is introduced in the policy orchestration center to jointly model factors such as traffic behavior characteristics, policy template structure, node resource status, and key popularity, thereby generating candidate deployment relationships between policies, nodes, and traffic. Next, by introducing granular selection and lifecycle calculation methods oriented towards key stability, business activity, and resource costs, the most suitable template granularity and effective time can be determined for each candidate policy before deployment, achieving dynamic optimization of the policy under resource constraints. Finally, in the deployment execution stage, by constructing a priority-based distribution path planning model, a policy version verification mechanism, and a key consistency detection mechanism, the system ensures that the policy can be reliably and securely distributed to the target decryption node and take effect smoothly. By combining the above mechanisms, this invention achieves intelligent management of the entire process of policy from input features to deployment and execution, significantly improving policy matching accuracy, resource utilization efficiency and system stability. It realizes the collaborative control of policies, nodes and keys in complex network environments and is an efficient and scalable intelligent scheduling solution for large-scale SSL business scenarios. Attached Figure Description

[0024] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0025] Figure 1 This is a flowchart of the SSL traffic dynamic scheduling method based on policy-based intelligent orchestration of the present invention.

[0026] Figure 2 This is a framework diagram of the SSL traffic dynamic scheduling system based on policy-based intelligent orchestration of the present invention. Detailed Implementation

[0027] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0028] In one or more embodiments, such as Figure 1 As shown, a method for dynamic scheduling of SSL traffic based on policy-based intelligent orchestration is disclosed, the method comprising the following:

[0029] S1: Collect the handshake field information, certificate structure digest field and connection statistics behavior field of SSL encrypted traffic, and normalize and encode the fields to generate a structured feature vector with a unified dimension;

[0030] Specifically, this step is used to construct a feature representation structure for encrypted traffic, providing a unified and computable input tensor for subsequent policy matching and orchestration. Since this invention deals with encrypted traffic based on the SSL protocol, the service type cannot be identified through plaintext fields. Therefore, a feature extraction method that is independent of decrypted content, possesses distinctiveness, and can be structurally modeled is required. We construct three types of field representations based on handshake protocol behavior, certificate structure attributes, and connection statistics behavior, and merge them into a standardized vector structure. This step extracts feature dimensions relevant to policy deployment without introducing plaintext data or violating the legitimacy of the encryption protocol. Simultaneously, a lightweight structure that can be embedded into edge nodes is used to implement the mapping, ensuring real-time system deployment and low resource consumption.

[0031] The data input for this step comes from passively collected encrypted traffic on the network side, without relying on any decryption. All data is collected in real time on the SDN controller or edge routing node using standard network probes (such as those based on NetFlow, sFlow, or port mirroring). The input data includes three types of structures: The first type is handshake field information, derived from messages during the TLS handshake phase, such as protocol version, number of cipher suites, whether an SNI field is included, and whether session recovery is enabled. The second type is certificate structure digest fields, extracted from fields such as the digest hash of the master certificate, the number of certificate chain levels, and the signature algorithm identifier, without needing to read the plaintext content of the certificate. The third type is connection statistics, including the delay from connection establishment to handshake completion, the direction sequence of the first few packets (using 0 / 1 to represent inbound or outbound), the length sequence (in bytes), and abnormal TCP layer behaviors such as the number of retransmissions. All fields can be extracted in a structured manner through the protocol stack state monitoring module.

[0032] For example, in an encrypted connection from a client, the following information can be collected: the TLS version of the connection is 1.3, the client provides a total of 12 cipher suites, the handshake time is 218 milliseconds, the SNI field is present, the certificate chain depth is 3 layers, the signature algorithm is elliptic curve digital signature, and the direction sequence of the first 10 packets is "1,0,1,...", with the corresponding length sequence being "134,1514,60,...". This information can be extracted in a structured manner using a standard network protocol parser.

[0033] Let the first The three types of feature vectors extracted from the encrypted connection are the handshake field vector. Certificate field vector and behavioral statistics field vectors They each have dimensions , and We use three sets of transformation mapping functions to perform a nonlinear transformation, obtaining a vector representation of uniform length. This process is formally represented as:

[0034] ;

[0035] Among the symbols This represents a vector concatenation operation. For the first The final feature representation vector of each connection, with a total dimension of ,in This represents the output dimension of each transformation function. , , All methods employ a two-layer linear transformation structure. The first layer is a linear mapping with a bias, and the second layer is an activation transformation with a nonlinear function. Before entering the transformation structure, numerical fields of the input vector are uniformly normalized, and discrete fields are encoded using fixed-length mapping to ensure consistency of dimensions between vectors. All function structures are fixed, independent of external training, and easy to deploy.

[0036] Using the method described above, each connection sample is mapped to a vector of uniform length. All samples are organized as tensors:

[0037] ;

[0038] in The structured feature tensor representing the total flow. This represents the number of connections processed in the current batch. To unify feature dimensions, For the first Structured feature representation of a connection.

[0039] S2: Jointly model the structured feature vector with the preset set of policy templates, decryption node status information and key status information, calculate the deployment credibility score of each SSL connection under each policy template and each decryption node combination, and select at least two combinations with the highest deployment credibility scores to form a candidate deployment task set.

[0040] Specifically, this step generates candidate deployment tasks in the strategy intelligent orchestration center. Its core task is to generate the structured traffic feature tensor extracted in the previous step. By jointly modeling with existing policy templates, decryption node states, and key states in the current system, a set of candidate deployment tasks for policy-node-traffic triples is output. This step not only provides deployment suggestions for the system decision-making module, but more importantly, it provides core support for the most critical "intelligent policy orchestration" part of the entire solution: it establishes the adaptation relationship between policies and traffic, the capability mapping between policies and nodes, and the dynamic dependency relationship between policies and keys, forming an orchestration and scheduling foundation that is highly adaptable to dynamic environmental changes.

[0041] Unlike existing passive policy deployment methods based on "rule-based allocation strategies" or "fixed template matching strategies," this step designs a three-dimensional coupled scoring structure of behavior, resources, and keys from a system-level perspective, enabling dynamic perception and scheduling optimization across different dimensions. Furthermore, this step introduces key-dependent policy confidence suppression and node resource conflict suppression terms to avoid blindly deploying policies on high-risk keys or high-load nodes, thereby improving the overall system security and scheduling efficiency.

[0042] The input for this step comes from the output of the previous step, namely the feature tensor. ,in This indicates the number of SSL connections currently awaiting scheduling. Indicates the first The structured feature vectors of the connected segments have a dimension of . In addition, three types of structured data are introduced:

[0043] Strategy Template Collection Each template Includes predefined structure vectors This vector is constructed by fixing the policy target business fingerprint, certificate rules, and resolvable fields, and does not change dynamically during operation. Furthermore, the template... Bind unique key number ;

[0044] Node state matrix ,in To decrypt the number of nodes, Indicates the first The current resource status of each node, including CPU utilization, number of policy slots, memory usage ratio, deployment policy conflict count, etc.

[0045] Key state vector ,in This represents the current total number of keys. Indicates the first The activity estimate of a key is derived from the key's deployment frequency, rotation frequency, and the number of effective policies over a past period.

[0046] To simultaneously consider traffic-policy matching, node deployment capabilities, and key stability, we designed the following policy deployment trustworthiness scoring function:

[0047] ;

[0048] in Indicates the first Is a single traffic connection suitable for using a policy template? At the node Credibility score for deployment. It is the similarity term of the behavior vector, reflecting the structural matching degree between the traffic and the policy template. Representation strategy At the node The current resource conflict factors include, for example, slot conflicts and computing resource overload that may result from deploying this strategy. This conflict value can be determined by analyzing the node resource matrix. The regularization function is extracted. It is a key stability suppression term, when the bound key When activity is low (indicating that the device may be in rotation or no longer used frequently), this value increases, thus negatively impacting the deployment score. and This is a manually set penalty factor used to adjust the weighting of resource pressure and key instability. This indicates an optional compression function used to control the output within a specified range.

[0049] In the above scoring model, innovation is mainly reflected in the following aspects:

[0050] The traditional "traffic-policy" similarity matching is upgraded to a four-element scoring structure of "traffic-policy-node-key", and for the first time, explicit intervention of key status and node resource status is introduced in the policy orchestration scoring.

[0051] Introduce a "resource conflict item" into the scoring function. and "key stability item" To introduce system-aware constraints for the feasibility of strategy deployment;

[0052] Using an adjustable penalty factor to replace the uncontrollable parameters in the black-box model improves the transparency and interpretability of the scoring mechanism, which is helpful for subsequent policy optimization and system evolution.

[0053] For all triples Calculate the score Then, the system will select the top-ranked deployments based on their deployment credibility. These combinations serve as candidate deployment tasks, forming a deployment task set:

[0054] ;

[0055] This set Each quadruple in the code represents: the system suggests placing the first... The strategy template was deployed to the first... The node is used to decrypt the first node. Each traffic entry, along with a current deployment trustworthiness score. This set will be used as the input basis for selecting the granularity of strategy deployment and determining the effective period in the next step.

[0056] S3: For each item in the candidate deployment task set, combine the traffic activity of the corresponding SSL connection, the popularity of the policy template bound key, and the resource consumption cost of different granularity policy templates to determine the final deployment granularity level, and calculate the policy deployment lifecycle based on the traffic activity and key popularity.

[0057] Specifically, this step plays a crucial role in the strategy intelligent orchestration system, serving as a bridge between the preceding and following steps. Its task is to receive the set of candidate deployment tasks output from the previous step. Furthermore, based on this, the final deployment granularity level and deployment lifecycle are determined for each candidate deployment task. (This refers to the task set from the previous stage.) Each traffic item has been clearly defined. Its matching strategy template and suitable nodes for deployment And the overall compatibility score among the three. However, simply knowing whether a policy is suitable for deployment is not sufficient for actual system configuration. A complete policy scheduling system must further determine "at what granularity to deploy the policy" and "for how long to deploy it." Otherwise, the system lacks adjustment mechanisms, leading to resource waste, key conflicts, policy redundancy, or failure. Therefore, this step, through spatiotemporal optimization of candidate tasks, generates final deployment instructions that can be directly executed by the system. This is a crucial step in this solution, transforming the policy from "pending deployment" to "executable deployment."

[0058] The input required for this step comes entirely from the candidate deployment set output from the previous stage. Each element is a quadruple. In addition, two state variables from within the system are used: one is traffic activity. The first indicator, calculated by the management system based on the frequency of similar traffic occurrences within a fixed time window in the past, reflects the importance of the business to which the traffic belongs; the second is key popularity. , for strategy template Bound key The current activity level is calculated in real time by the key management system based on key usage frequency, rotation interval, and the number of bound policies. These two state variables, along with data from the candidate task set, are used in the decision-making process for this step.

[0059] There are three key constraints in the decision design of deployment granularity: (1) The finer the granularity of the SSL decryption strategy, the stronger the matching accuracy, but the higher the consumption of resources such as CPU, memory, and cache; (2) When using a key with higher activity, the strategy is more likely to hit, which is suitable for deploying high-granularity templates; (3) The policy fineness should be improved for high-activity traffic, while resources should be saved for low-activity traffic.

[0060] Based on these characteristics, this method defines a set of granularity levels. , representing template granularity from coarse to fine, respectively. The following joint scoring formula is used to determine the deployment granularity:

[0061] ;

[0062] in Indicates the final selected granularity level; The deployment adaptation score for the previous stage; For traffic activity; Key popularity; For the first The resource consumption cost constant of granular templates (e.g.) ); The "high-risk mitigation item" is specially introduced to further suppress the deployment of high-granularity strategies when the score is low, so as to avoid node resource waste caused by mismatch; The weights are adjustable. The above formula considers five dimensions simultaneously: behavior matching, business importance, key stability, resource constraints, and low-score risk. Compared with traditional scoring models, it significantly improves the intelligence and controllability of deployment-level decision-making.

[0063] After determining the granularity, this step combines key status and traffic activity to determine the deployment lifecycle of the policy. In a real system, if the policy pertains to highly active services and the key status is stable (i.e., high popularity), a longer lifecycle can be granted; conversely, for policies whose keys are about to rotate, their validity period should be shortened to avoid policy failure due to key replacement. This step uses the following lifecycle calculation formula:

[0064] ;

[0065] in For deployment lifecycle; System basic deployment time; This represents the maximum activity level of the current batch of traffic, used for normalization. This refers to key popularity. The formula is simple in structure but crucial in its function: higher activity levels result in a longer lifespan, while lower key popularity levels result in a shorter lifespan, achieving fully adaptive time-level control from a system perspective.

[0066] Through the dual decision-making process of granularity and lifecycle described above, this step ultimately generates a five-tuple of deployment instructions. ,in Representation Strategy Template The Granular version The length of time the strategy is retained on the node. All five-tuples constitute the final deployment table. In the fourth step, the command will be sent to the specific decryption node for execution via the SDN control channel.

[0067] S4: Deployment instructions containing policy template identifier, deployment granularity level, target decryption node, and deployment lifecycle are sent to the corresponding decryption node through the SDN control channel. Before sending, the deployment instructions are prioritized according to the deployment trustworthiness score, target node control channel utilization, and deployment lifecycle. Key fingerprint consistency verification and policy version hash verification are performed on the node side to ensure that the policy is securely effective.

[0068] Specifically, this step is the final execution module in the strategy intelligent orchestration system proposed in this invention, responsible for executing the deployment scheduling table generated in the previous step. The commands are transformed into actionable control instructions and distributed to the corresponding SSL decryption nodes via the SDN architecture to complete policy deployment. The goal of this step is not only to complete the "action execution," but more importantly, to: 1. Ensure the consistency and synchronization of policy and key configurations, especially in environments with multiple key rotations and multiple policy versions; 2. Based on a combined evaluation of policy priority, network load, and deployment window, achieve intelligent optimization of the distribution order, improving overall deployment efficiency and reliability.

[0069] The input data for this step is the deployment schedule table. This data is output from the previous stage and has a quintuple structure. ,in For the first A unique identifier for each traffic connection. Representation strategy The Granular version This indicates that the strategy is being distributed to the target nodes. It is the strategy deployment adaptability score. This refers to the deployment lifecycle (in seconds). These data structures will be parsed line by line in this step to generate specific deployment instructions and enter the control delivery process.

[0070] In practical implementation, strategy templates The policy center encapsulates the policy into a structured configuration file according to a predefined format. Fields include policy number, granularity level, matching rule set, and deployment duration. Binding key number Version hash value, etc. This configuration file is packaged into control plane messages by the deployment encapsulation module, ready to be sent to the nodes. The control channel is established based on SDN control protocols (such as OpenFlow extended fields, NETCONF, etc.). The deployment center needs to select an appropriate time window and path to complete the policy distribution. To avoid control channel congestion or node load imbalance, this step performs a priority ranking mechanism before scheduling and distribution, using the following scheduling priority scoring function to score all deployment tasks:

[0071] ;

[0072] in Indicates task scheduling priority, To achieve a deployment adaptation score, Indicates the current node Control channel utilization is obtained through periodic reports from the controller. This represents the maximum configurable control channel bandwidth percentage. For the deployment lifecycle of this strategy, This is the longest lifespan constant supported by the system. The weighting coefficients are used. The design of this scoring function ensures the following three points: first, high-adaptability strategies are deployed first; second, idle resource nodes are given priority for receiving deployments; and third, strategies with shorter lifecycles are scheduled first, to avoid long delays that cause strategies to miss their effective window.

[0073] After the control message is sent, the target node The local agent receives and parses deployment instructions, loads the policy template content, and binds the corresponding key number. The key configuration process is implemented through an interface with the local key module. The key module maintains a fingerprint hash table of loaded keys, and during deployment, it compares the key hash recorded in the policy template with the local key hash. If the policy-bound key does not match the local key fingerprint, or the target key has expired, the node refuses to deploy the policy and sends a failure flag back to the control center. Upon receiving the failure report, the control center can attempt to reallocate the key, schedule other templates, or reassign the policy task to other nodes to avoid deployment anomalies affecting the execution of decryption tasks.

[0074] To prevent policy version conflicts and misdeployment, a version hash verification mechanism is introduced in the deployment configuration. Each policy configuration is generated by structurally concatenating the policy rule content, granularity information, and key number, and then calculating the version hash value. This hash value is distributed to nodes along with the policy. Before loading the policy template, each node must compare it with the version hash table already loaded in the system. If it finds that the same policy number already exists but the version hash is different, the version conflict handling mechanism is triggered, and the system policy is used to choose to retain the version or abort the deployment. For example, when... The hash value is The node already has an existing number. version The system can decide whether to replace it based on the version timestamp.

[0075] In actual system deployment, policy configuration and control message transmission are completed through encrypted channels (such as TLS channels bound to the control plane) to prevent data leakage or man-in-the-middle attacks during deployment. After all deployment actions are completed, the node will report the deployment status through the deployment feedback interface. The feedback includes information such as deployment success / failure, loading time, memory usage, conflict flags, and key status. All feedback data constitutes the deployment feedback set. It is used for subsequent auditing, optimization, and controller status synchronization.

[0076] Here's a real-world deployment example: Strategy (Granularity level 3) Requires deployment to nodes Its score is Expected deployment lifecycle Seconds, bind key High popularity, node Current load is low (channel utilization) This task has a high priority score and will be prioritized for distribution. The controller's packaging strategy configuration includes adding hash values. and key identifier, sent to The node loads its configuration, verifies that the key fingerprint matches the version hash, and then deploys and begins execution.

[0077] The final output is a deployment status table. ,in This indicates the execution result of the deployment task, including statuses such as "deployed," "key mismatch," and "version conflict." The deployment status information will be entered into the system logs, scheduler optimizer, and policy failure management module, providing fundamental data support for the continuous operation of the entire system.

[0078] In one or more embodiments, such as Figure 2As shown, a policy-based intelligent orchestration-based dynamic SSL traffic scheduling system is disclosed, the system comprising:

[0079] The traffic feature extraction module is used to collect handshake field information, certificate structure digest field and connection statistics behavior field of SSL encrypted traffic, and to normalize and encode the handshake field information, certificate structure digest field and connection statistics behavior field to generate a structured feature vector with a unified dimension.

[0080] The strategy orchestration center module is used to jointly model the structured feature vector with the preset set of strategy templates, decryption node status information and key status information, calculate the deployment credibility score of each SSL connection under each combination of strategy templates and decryption nodes, and select at least two combinations with the highest deployment credibility scores to form a candidate deployment task set.

[0081] The granularity and lifecycle decision module is used to determine the final deployment granularity level for each item in the candidate deployment task set, taking into account the traffic activity of the corresponding SSL connection, the popularity of the policy template bound key, and the resource consumption cost of different granularity policy templates, and to calculate the policy deployment lifecycle based on the traffic activity and key popularity.

[0082] The policy execution control module is used to send deployment instructions, which include policy template identifier, deployment granularity level, target decryption node, and deployment lifecycle, to the corresponding decryption node through the SDN control channel. Before sending, the deployment instructions are prioritized according to deployment trustworthiness score, target node control channel utilization, and deployment lifecycle. Key fingerprint consistency verification and policy version hash verification are performed on the node side to ensure that the policy takes effect securely.

[0083] It is worth noting that the specific workflow of the SSL traffic dynamic scheduling system based on policy intelligent orchestration provided in this embodiment of the invention is the same as that of the SSL traffic dynamic scheduling method based on policy intelligent orchestration described in the above embodiments, and will not be repeated here.

[0084] This invention also provides a policy-based intelligent orchestration-based SSL traffic dynamic scheduling device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the steps described in the above-described policy-based intelligent orchestration-based SSL traffic dynamic scheduling method embodiment, for example... Figure 1 The steps S1 to S4 described above; or, when the processor executes the computer program, it implements the functions of each module in the above system embodiments.

[0085] For example, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the policy-based intelligent orchestration SSL traffic dynamic scheduling device.

[0086] The policy-based intelligent orchestration-based SSL traffic dynamic scheduling device can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. This device may include, but is not limited to, processors and memory. Those skilled in the art will understand that the policy-based intelligent orchestration-based SSL traffic dynamic scheduling device may also include input / output devices, network access devices, buses, etc.

[0087] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASACs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. This processor is the control center of the policy-based intelligent orchestration SSL traffic dynamic scheduling device, connecting all parts of the device via various interfaces and lines.

[0088] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the policy-based intelligent orchestration SSL traffic dynamic scheduling device by running or executing the computer programs and / or modules stored in the memory and calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created based on the operation of the air conditioner controller, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0089] The modules integrated into the policy-based intelligent orchestration-based SSL traffic dynamic scheduling device, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0090] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0091] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for dynamic scheduling of SSL traffic based on policy-based intelligent orchestration, characterized in that, The method includes: Collect handshake field information, certificate structure digest field and connection statistics behavior field of SSL encrypted traffic, and normalize and encode the fields to generate a structured feature vector with a unified dimension; The structured feature vectors are jointly modeled with a preset set of policy templates, decryption node status information, and key status information. The deployment trustworthiness score for each SSL connection under each policy template and decryption node combination is calculated. The calculation of the deployment trustworthiness score incorporates a resource conflict factor and a key stability suppression term. The resource conflict factor is determined based on the target decryption node's CPU utilization, policy slot count, memory usage ratio, and deployment policy conflict count. The key stability suppression term is determined based on the key's deployment frequency, rotation frequency, and the number of effective policies within the past time window. At least two combinations with the highest deployment trustworthiness scores are selected to form a candidate deployment task set. The trustworthiness score is calculated as follows: ; in Indicates the first Is a single traffic connection suitable for using a policy template? At the node Credibility score for deployment on the platform; It is the similarity term of the behavior vector, reflecting the structural matching degree between the traffic and the policy template; Representation strategy At the node The current resource conflict factor, whose value can be obtained by analyzing the node resource matrix. The regularization function is extracted; It is a key stability suppression term, when the bound key When activity is low, this value increases, thus negatively impacting the deployment score. Key The activity level is estimated by the key. This estimate was derived from the combined data of deployment frequency, rotation frequency, and number of effective policies over a past period. and This is a manually set penalty factor used to adjust the weighting of resource pressure and key instability. Indicates an optional compression function used to control the output within a specified range; For each item in the candidate deployment task set, the final deployment granularity level is determined by combining the traffic activity of the corresponding SSL connection, the popularity of the key bound to the policy template, and the resource consumption cost of different granularity policy templates. The policy deployment lifecycle is calculated based on the traffic activity and key popularity. The deployment granularity level is divided into at least three levels from coarse to fine. The finer the granularity, the higher the resource consumption cost. High-risk mitigation items suppress the deployment of high-granularity policies when the deployment credibility score is lower than the threshold. Deployment instructions, which include policy template identifiers, deployment granularity levels, target decryption nodes, and deployment lifecycles, are sent to the corresponding decryption nodes via the SDN control channel. Before sending, the deployment instructions are prioritized based on deployment trustworthiness scores, target node control channel utilization, and deployment lifecycles. Key fingerprint consistency verification and policy version hash verification are performed on the node side to ensure that the policy takes effect securely.

2. The SSL traffic dynamic scheduling method based on policy-driven intelligent orchestration according to claim 1, characterized in that, The handshake field information includes the TLS protocol version, the number of cipher suites, whether to include the SNI field, and whether to enable session recovery.

3. The SSL traffic dynamic scheduling method based on policy-driven intelligent orchestration according to claim 1, characterized in that, The certificate structure digest field includes the master certificate digest hash, the number of certificate chain levels, and the signature algorithm identifier.

4. The SSL traffic dynamic scheduling method based on policy-driven intelligent orchestration according to claim 1, characterized in that, The connection statistics behavior fields include handshake completion delay, direction sequence of the first ten packets, length sequence of the first ten packets, and number of TCP retransmissions.

5. The SSL traffic dynamic scheduling method based on policy-driven intelligent orchestration according to claim 1, characterized in that, The deployment lifecycle of the strategy extends as traffic activity increases and shortens as key popularity decreases.

6. The SSL traffic dynamic scheduling method based on policy-driven intelligent orchestration according to claim 1, characterized in that, During the deployment instruction issuance process, if the target decryption node detects that the fingerprint of the policy binding key is inconsistent with the local key or that the key has expired, it will refuse to deploy and return a failure flag to the control center.

7. The SSL traffic dynamic scheduling method based on policy-driven intelligent orchestration according to claim 1, characterized in that, Each policy configuration contains a version hash value generated by concatenating the policy rule content, granularity level, and binding key number. The decryption node verifies the version hash value before loading the policy to avoid policy version conflicts.

8. A policy-based intelligent orchestration-based dynamic SSL traffic scheduling system, characterized in that, The system includes: The traffic feature extraction module is used to collect handshake field information, certificate structure digest field and connection statistics behavior field of SSL encrypted traffic, and to normalize and encode the handshake field information, certificate structure digest field and connection statistics behavior field to generate a structured feature vector with a unified dimension. The strategy orchestration center module is used to jointly model the structured feature vectors with a preset set of strategy templates, decryption node status information, and key status information. It calculates the deployment credibility score for each SSL connection under each strategy template and decryption node combination. The calculation of the deployment credibility score incorporates a resource conflict factor and a key stability suppression term. The resource conflict factor is determined based on the target decryption node's CPU utilization, strategy slot count, memory usage ratio, and deployment strategy conflict count. The key stability suppression term is determined based on the key's deployment frequency, rotation frequency, and the number of effective strategies within the past time window. At least two combinations with the highest deployment credibility scores are selected to form a candidate deployment task set. The credibility score is calculated as follows: ; in Indicates the first Is a single traffic connection suitable for using a policy template? At the node Credibility score for deployment on the platform; It is the similarity term of the behavior vector, reflecting the structural matching degree between the traffic and the policy template; Representation strategy At the node The current resource conflict factor, whose value can be obtained by analyzing the node resource matrix. The regularization function is extracted; It is a key stability suppression term, when the bound key When activity is low, this value increases, thus negatively impacting the deployment score. Key The activity level is estimated by the key. This estimate was derived from the combined data of deployment frequency, rotation frequency, and number of effective policies over a past period. and This is a manually set penalty factor used to adjust the weighting of resource pressure and key instability. Indicates an optional compression function used to control the output within a specified range; The granularity and lifecycle decision module is used to determine the final deployment granularity level for each item in the candidate deployment task set, combining the traffic activity of the corresponding SSL connection, the popularity of the policy template bound key, and the resource consumption cost of different granularity policy templates, and to calculate the policy deployment lifecycle based on the traffic activity and key popularity. The deployment granularity level is divided into at least three levels from coarse to fine. The finer the granularity, the higher the resource consumption cost. Furthermore, high-risk mitigation items suppress the deployment of high-granularity policies when the deployment credibility score is lower than the threshold. The policy execution control module is used to send deployment instructions, which include policy template identifier, deployment granularity level, target decryption node, and deployment lifecycle, to the corresponding decryption node through the SDN control channel. Before sending, the deployment instructions are prioritized according to deployment trustworthiness score, target node control channel utilization, and deployment lifecycle. Key fingerprint consistency verification and policy version hash verification are performed on the node side to ensure that the policy takes effect securely.

Images