A Cloud-Edge Collaborative Security Management Method and Device Based on SDP

Abstract

The present invention discloses a cloud-edge collaborative security management method and device based on SDP, aiming to solve the security threats faced by the central cloud during the data transmission from the edge cloud to the central cloud in the open and dynamic environment of cloud-edge collaboration, such as port scanning, DDoS attacks, data theft and tampering. The present invention innovatively introduces the software-defined perimeter (SDP) technology, designs a multiple port knocking mechanism, and effectively prevents the attacked or hijacked edge cloud devices from initiating unauthorized data transmission to the central cloud by finely managing the authentication ports, tunnel ports and service ports, thus ensuring the communication security of the central cloud. At the same time, a lightweight and adaptive dynamic real-time trust assessment algorithm is designed to improve the system assessment efficiency, and combined with the method of automatically generating emergency plans based on large models, threat disposal is carried out, a network threat event analysis report is generated, the threat handling efficiency is improved, and the human cost of network security operation and maintenance is reduced.

Description

Technical Field

[0001] The present invention belongs to the field of computer network security, and particularly relates to a cloud-edge collaborative security management method and device based on SDP. Background Art

[0002] With the rapid development and wide application of cloud computing, edge computing, artificial intelligence, and Internet of Things technologies, the cloud-edge collaborative architecture has gradually become an important infrastructure for supporting distributed computing and real-time processing tasks. Among them, devices represented by cloud data integration machines are increasingly widely deployed. They can not only efficiently process local data but also achieve collaborative computing and data interaction with the central cloud to meet more complex and real-time business requirements.

[0003] However, the cloud-edge collaborative environment is usually deployed in an open and dynamic network. Traditional network security protection means (such as firewalls, VPNs, etc.) often rely on static network boundaries and are difficult to adapt to the characteristics of frequent changes in edge nodes, strong device heterogeneity, and diverse data transmission paths. Such an open boundary environment greatly increases the exposure surface of cloud-edge secure transmission and is prone to security threats such as port scanning, distributed denial of service attacks (DDoS), data theft, and data tampering, posing great challenges to the protection of sensitive data and the continuous and stable operation of the system.

[0004] The data collected by the edge cloud often involves sensitive information, such as environmental monitoring data, industrial production data, video surveillance data, or important alarm logs. Once these data are intercepted or tampered with during the transmission process, serious consequences will occur, such as data leakage, business interruption, or even harm to public safety. Edge cloud devices are usually deployed in open and dynamic network environments, such as unattended intelligent monitoring devices, intelligent transportation nodes, or industrial data acquisition devices. These devices lack perfect physical protection measures and are exposed to the public network, making them vulnerable to malicious intrusion.

[0005] There is a large amount of data transmission from the edge cloud to the central cloud in cloud-edge transmission. For example, the edge cloud collects Internet of Things device data or environmental monitoring data locally and needs to upload it to the central cloud in real time or regularly for data analysis, model training, or storage; when the edge cloud detects device anomalies or network security events during the task execution process, it needs to upload the anomaly alarms and relevant log data to the central cloud for unified risk assessment and emergency response.

[0006] During the above transmission process, edge cloud devices are usually deployed in open environments, such as roadside intelligent monitoring terminals in smart cities, monitoring nodes in intelligent transportation systems, and unattended industrial production line data acquisition devices, etc. They are extremely vulnerable to network attacks (such as port scanning, DDoS attacks, data theft or tampering, etc.), resulting in security problems such as data leakage, tampering, and service interruption. These security threats pose great challenges to the protection of sensitive data and the continuous operation of services in the cloud-edge collaboration architecture.

[0007] At the same time, most traditional security authentication methods authenticate identities based on human beings. For unattended edge cloud devices, how to effectively authenticate the credibility of devices and manage identities has become a difficult problem to be solved urgently. In addition, the computing power of edge nodes is limited. While pursuing security, the impact of authentication and security mechanisms on system efficiency must also be considered. How to balance the contradiction between the intensity of security protection and the efficiency of system operation has also become a key research topic in the cloud-edge collaboration scenario.

[0008] To address the above problems, the present invention introduces a security management technology based on Software Defined Perimeter (SDP), proposes a multiple port knocking mechanism and a device real-time credibility calculation scheme based on a time window, and combines a large model to automatically generate emergency plans, which can ensure the security of cloud-edge collaboration data communication, effectively improve communication efficiency, reduce unnecessary consumption of system performance, and thus provide a practical and effective technical solution for cloud-edge collaboration secure communication. Summary of the Invention

[0009] To solve the problem of data communication security risks between edge clouds and central clouds in the open and dynamic environment of cloud-edge collaboration, the present invention proposes a cloud-edge collaboration security management method and device based on SDP. Aiming at the problems that edge cloud devices face serious risks such as port scanning attacks, DDoS attacks, data theft and tampering during data transmission, the present invention introduces the Software Defined Perimeter (SDP) technology, utilizes the dynamic authorization and zero-trust security concept of the SDP model, and designs a multiple port knocking security mechanism to dynamically hide and manage communication ports to protect the security of the central cloud. At the same time, a lightweight and adaptive dynamic real-time trust evaluation algorithm is designed to improve the system evaluation efficiency, and combined with an emergency plan automatic generation method based on a large model, threat disposal is carried out, a network threat event analysis report is generated, the threat handling efficiency is improved, and the human cost of network security operation and maintenance is reduced.

[0010] The technical solution adopted by the present invention to solve its technical problems is: to provide a cloud-edge collaboration security management method based on SDP, including the following steps:

[0011] S1 authentication port knocking: Request port opening knocking. The SDP client on the edge cloud actively sends a connection request to the central cloud SDP controller, so that the SDP controller opens the ports related to the identity authentication service.

[0012] S2 Authentication Knocking: Authentication knocking, the SDP client on the edge cloud dynamically calculates the trust level of the device based on multiple factors such as the device's historical behavior and environmental information, and performs multi-dimensional authentication according to different trust levels;

[0013] S3 Tunnel Port Knocking: Tunnel port knocking, after identity authentication, the SDP controller of the central cloud allows the edge cloud device to establish a secure encrypted communication tunnel with the SDP gateway;

[0014] S4 business port knocking: Business port knocking, the edge cloud device initiates a knocking request in the established secure tunnel. After verifying the legitimacy of the request, the SDP gateway opens the business port to allow the edge cloud device to transmit data to the central cloud.

[0015] S5 large model automatic generation of emergency plans: Introducing a security brain driven by a large model, it automatically analyzes threat characteristics and dynamically generates emergency plans when abnormal access or attack behavior is detected. It also automatically performs plan optimization, review, and linkage response in combination with security strategies to achieve intelligent and automated security protection.

[0016] Compared with the traditional solution, the beneficial effects of the present invention are:

[0017] 1. The present invention innovatively proposes a multi-level port knocking mechanism. Through a progressive security verification process, it ensures that the business port and authentication port remain hidden in the event of unauthorized access, effectively reducing the exposure time of the port and the risk window of network attacks. Compared with traditional static security protection measures, the present invention significantly reduces the threat of network attacks such as port scanning attacks and denial of service attacks, and improves the security and reliability of the business system.

[0018] 2. The present invention designs a lightweight, adaptive, dynamic real-time trust evaluation mechanism, which is specifically designed for the characteristics of rapid changes in the device status in the cloud-edge collaborative environment. It monitors multi-dimensional factors such as the device operating environment, device behavior, historical status, and environmental changes in real time, and achieves the best coordination of security and efficiency by dynamically adjusting the identity authentication strength, authentication cycle, and port lifecycle management strategy. Compared with the traditional fixed strategy trust evaluation, this mechanism can flexibly respond to the complex and changeable edge node operating environment, greatly improving the overall protection efficiency and operational reliability of the system.

[0019] 3. The identity authentication mechanism proposed by the present invention targets the device itself rather than the personnel and is specially optimized for the unattended edge cloud environment. It implements a differential authentication strategy based on the trust level calculated in real time by the device, ranging from strict multi-factor authentication to fast lightweight authentication. While avoiding the errors and security risks that may be brought by human factors, it significantly improves the accuracy, automation degree and overall efficiency of the identity authentication process, and is applicable to the cloud-edge collaborative open dynamic scenario.

[0020] 4. The present invention designs an automatic emergency plan generation method based on a large model. When the system detects a security threat, this method can quickly analyze the characteristics and impacts of the threat and use a pre-trained large language model to generate targeted and directly implementable emergency plans. It not only quickly links with the security management platform for rapid response and automatic disposal of threats, but also can automatically generate a comprehensive and detailed analysis report on network threat events, effectively improving the disposal efficiency and response speed of network security incidents and significantly reducing the labor cost of network security operation and maintenance.

[0021] Through the above technical solutions, the present invention significantly improves the security, reliability and operation efficiency of communication in the cloud-edge collaborative environment, provides an efficient, secure and dynamic protection mechanism for sensitive data transmission, and is applicable to complex, open and dynamically changing network environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required to be used in the embodiments. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings.

[0023] Figure 1 Schematic diagram of the architecture of a cloud-edge collaborative security management method based on SDP according to an embodiment of the present invention.

[0024] Figure 2 Schematic diagram of the deployment of SDP components in the cloud-edge collaborative scenario of a cloud-edge collaborative security management method based on SDP according to an embodiment of the present invention.

[0025] Figure 3 Overall flowchart of a cloud-edge collaborative security management method and device based on SDP provided by an embodiment of the present invention.

[0026] Figure 4 Diagram of the credibility calculation scheme of a cloud-edge collaborative security management method based on SDP provided by an embodiment of the present invention.

[0027] Figure 5A trusted value update scheme diagram based on a time window for a cloud-edge collaborative security management method based on SDP is provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0028] The present invention provides a cloud-edge collaborative security port hiding method and device based on SDP, which is suitable for secure communication management under the cloud-edge collaborative architecture. The method mainly ensures the access security from the edge cloud to the central cloud through multiple port knocking mechanisms, trust evaluation, dynamic authentication and encrypted tunnels.

[0029] In order to better understand the technical solution, the method of the present invention is described in detail below in conjunction with the accompanying drawings and specific implementations.

[0030] refer to Figure 1 In the present invention, the SDP client, SDP controller, and SDP gateway are designed and deployed on the cloud-data integrated machine.

[0031] refer to Figure 2 ,In the process of cloud-edge collaboration, the cloud-data-in-one machine acting as the central cloud opens the SDP controller and SDP gateway, and the cloud-data-in-one machine acting as the edge cloud opens the SDP client.

[0032] refer to Figure 3 The present invention proposes a cloud-edge collaborative security management method and device based on SDP, comprising the following steps:

[0033] Step S1: Authentication port knocking

[0034] Before the SDP client on the edge cloud initiates an authentication request to the SDP controller on the central cloud, in order to ensure that the SDP controller can receive the authentication request from the SDP client, the SDP controller needs to open the relevant authentication ports. To achieve this goal, the SDP client on the edge cloud performs the first knock operation.

[0035] The specific authentication port knocking process includes the following steps:

[0036] Step S1.1: Authentication port knocking

[0037] The SDP controller on the edge cloud initiates the first knock on the door to the SDP controller on the central cloud, requesting the SDP controller to open the identity authentication port. The specific process includes the following steps:

[0038] Step S1.1.1: Key Agreement and Distribution

[0039] As the central management node, the SDP controller first conducts a secure key negotiation process with the SDP client at the edge cloud. This process typically uses an asymmetric encryption algorithm or a pre-shared key mechanism to generate a temporary key or use a pre-set key. Once the key negotiation is successful, the SDP controller securely distributes the temporary key or pre-set key to the corresponding SDP client at the edge cloud for generating the knocking key for the subsequent authentication request.

[0040] Step S1.1.2: Knocking key generation

[0041] The SDP client at the edge cloud calculates a secure knocking key dedicated to this authentication knock through a specific encryption algorithm based on its unique identifier (such as device ID or MAC address), a random number, and the negotiated temporary key or pre-set key, ensuring that the key is unique and unpredictable for each device.

[0042] Step S1.1.3: Construct and send a knocking UDP packet

[0043] The SDP client encapsulates the calculated knocking key, the device unique identifier, the current real-time trust level of the client, and the target authentication port number into a special UDP knocking packet. This UDP knocking packet is then sent to the port control module at the SDP controller end as a "knocking" request in the initial authentication stage.

[0044] Specifically, the UDP knocking packet contains the following content:

[0045] (1) Edge cloud SDP client unique identifier: This identifier can be a device ID or MAC address, etc., for the SDP controller to accurately identify the client device.

[0046] (2) SDP client knocking key information: The knocking key calculated by the client is used to protect the confidentiality and integrity of the communication content, ensuring that the knocking request information cannot be illegally intercepted or tampered with.

[0047] Step S1.2: The port control module releases the identity authentication port

[0048] After receiving the UDP knocking packet, the port control module verifies its content, including the legitimacy checks of the knocking key, the device unique identifier, and the trust level value. After passing the verification, the port module briefly opens the identity authentication port.

[0049] Step S1.3: The port control module returns the identity authentication port information to the SDP client

[0050] The port control module generates the identity authentication port information and returns the identity authentication port number and address to the SDP client for its subsequent detailed identity authentication.

[0051] Through the above steps, on the basis of realizing the dynamic control of the device's secure identity authentication port, this solution effectively enhances the security of the authentication request phase, reduces the risks of the identity authentication port being attacked and port scanning, and ensures the smooth and secure progress of the subsequent identity authentication process.

[0052] Step S2: Identity authentication knock

[0053] After completing the authentication port knock, the SDP client of the edge cloud can start the identity authentication phase according to the obtained identity authentication port information. In this stage, the present invention designs a lightweight adaptive dynamic real-time trust evaluation algorithm to further verify the credibility and legitimacy of the device and determine the subsequent secure access policy of the device.

[0054] Specifically, it includes the following steps:

[0055] Step S2.1: Identity authentication knock

[0056] The SDP client of the edge cloud uses the identity authentication port obtained in step S1 to officially initiate an identity authentication request to the SDP controller. The SDP client submits an authentication request data packet containing data such as its own unique identifier and authentication token. The SDP controller selects the corresponding identity authentication method according to the trust level of the client to complete the knock process of device identity authentication.

[0057] Step S2.1.1: Device trustworthy feature extraction

[0058] This project proposes four security-related trust indicators, including authentication type , authorization type , self-security ability and malicious access times . The SDP client is responsible for collecting security-related data of the edge cloud and quantifying the credibility according to the definitions in the following table (Table 1).

[0059] Table 1: Table of value ranges and level divisions of security-related trust indicators

[0060]

[0061] In Table 1, , , are defined as positive integers 1, 2, or 3, respectively, reflecting low, medium, and high security levels. It should be emphasized that any other numbers with relative relationships reflecting security levels can be used, not just the above positive integers 1, 2, and 3. The above settings are selected for ease of understanding and calculation.

[0062] Step S2.1.2: Calculation of real-time device credibility based on time window

[0063] To improve the real-time performance and accuracy of device credibility calculation, the present invention introduces a time window mechanism to process device behavior data in chunks, so as to more efficiently capture the dynamic security state of the device. Multiple time windows are defined. For example, each time window contains a fixed number of device behavior data records. A device feature evaluation matrix is constructed within each time window to reflect the security features of the device in the current time period.

[0064] At the th timestamp, behavior data are selected as the input data set for trusted computing. Therefore, for measuring samples , , …, , …, the total number of groups. From the behavior data, the following feature matrix can be obtained:

[0065]

[0066] where , .

[0067] As the usage time increases, the scale of the evaluation matrix will become larger and larger. According to the decay property of credibility, the present invention adopts an innovative mechanism that combines the time window mechanism and the algorithm of the time decay function to calculate credibility, which can effectively meet the accuracy requirements of credibility calculation. Constructing the evaluation matrix can improve the efficiency of the evaluation algorithm and reduce the time and space overhead of the system. At the same time, in order to overcome the deficiencies of the subjective weight method in trusted computing, the present invention adopts a lightweight and adaptive method to calculate the credibility of edge cloud devices in real time. In such an environment with a large amount of data, a block parallel computing mechanism is adopted, which greatly speeds up the trusted computing speed. The specific steps are as follows:

[0068] Step S2.1.2.1: Window real-time credibility calculation

[0069] Input the evaluation matrix , and is divided into several sub-matrices. In this way, multiple time windows can be obtained, such as time window and . Calculate the real-time credibility of each time window according to the parallel mode.

[0070] Step S2.1.2.2: Form a credibility evaluation matrix

[0071] In each time window and Among them, the behavior data can form a credibility evaluation matrix. Taking the time window as an example for calculating real-time credibility. The evaluation matrix can be expressed as follows:

[0072]

[0073] Where .

[0074] Step S2.1.2.3: Evaluation matrix normalization

[0075] Normalize the evaluation matrix X to eliminate the physical dimension of the monitoring data. For any row of evidence ∈X, , it can be normalized to according to the following two cases. In one case, is decreasing positively, that is, the desired value is very small; this value includes the average response time, and the specific formula is as follows:

[0076]

[0077] Where and are the maximum and minimum values of the column evidence , respectively.

[0078] In another case, is increasing positively, that is, the value expected by the user is relatively large; this value includes 5 other indicators in addition to the average response time, and the formula is as follows:

[0079]

[0080] Where and are the maximum and minimum values of the column evidence , respectively.

[0081] Therefore, the standardized matrix can be obtained, and the formula is as follows:

[0082] =

[0083] Where .

[0084] Step S2.1.2.4: Obtain the decision matrix

[0085] Multiply the matrix by the weight matrix to obtain the decision matrix , and the formula is as follows:

[0086]

[0087] Among them 。

[0088] Step S2.1.2.5: Edge cloud trusted sequence calculation

[0089] In the decision matrix , the ideal values of each attribute are as follows, and the formula is as follows:

[0090]

[0091] Among them , is the ideal value of each property in the standardized matrix .

[0092] And calculate the squared difference of the distance between the common value and the ideal value in , and the formula is as follows:

[0093]

[0094] Construct the Lagrangian function as follows:

[0095]

[0096] Among them, λ is the Lagrange constant. The constraint condition of formula (9) is , and = 1.

[0097] Therefore, the present invention uses an adaptive weight calculation method, which can make up for the deficiencies of the subjective weight method in traditional trusted computing. Then calculate the partial derivative , and the following formula can be obtained:

[0098]

[0099] Substitute the conditions , and into the above formula to get:

[0100]

[0101] Calculate the credibility of the time series from 1 to i, and the formula is as follows:

[0102]

[0103] Among them , is the number of time windows, is the time-window-based credibility of the resource to be evaluated. By executing formulas (1) to (12) in parallel, the credibility sequence of the edge cloud can be obtained, that is .

[0104] Step S2.1.2.6: Overall credibility calculation

[0105] In the above formula, the time-window-based credibility u is obtained. According to the time decay property of credibility, the previous monitoring behavior data is used to participate in the calculation of credibility. Next, a time decay function is used to calculate the overall credibility , and the specific formula is as follows:

[0106]

[0107] where , is the number of time windows, and . is the weight assigned to each .

[0108] Define A as a time-based decay function, and the specific formula is as follows:

[0109]

[0110] where, is an adjustable normal constant in the system and can be tuned accordingly. represents the time window farthest from the present, represents the time window closest to the present. As increases, increases gradually. That is to say, through the above formula, the closest time window will be set with a larger weight in the overall credibility calculation, while the farther time window should be set with a smaller weight. The overall credibility calculation process is as Figure 4 shown.

[0111] Step S2.1.3 Credibility value update

[0112] In the implementation process of the credibility calculation mechanism proposed in the present invention, the update problem of the credibility value must be considered. The update frequency of the credibility value will affect the execution efficiency of the system. The present invention adopts a time-window-based credibility value update scheme.

[0113] Suppose is the old credibility value based on the existing monitoring data, is the latest credibility value based on the new monitoring data. When the number of new monitoring data reaches the set value of the time window, start to Perform a new calculation, and then a new time series can be obtained as follows:

[0114]

[0115] Next, the system will recalculate the overall trust value of the edge cloud , and the specific process is as Figure 5 shown. At the same time, within the given time window, the values are fixed, so these values only need to be calculated once. This time-window-based trust value update method can greatly improve the speed of trust value update.

[0116] Step S2.2: The SDP controller releases the SDP gateway

[0117] After the SDP controller successfully completes the device identity authentication and confirms the identity is trustworthy, it sends an instruction to the SDP gateway of the central cloud to notify the gateway to briefly open the security tunnel port to allow the edge cloud device to establish a secure communication channel. At the same time, the SDP controller dynamically determines the lifecycle and access permissions of the gateway port according to the level of the edge cloud during this process to ensure network security. The evaluation formula for the edge cloud trust level is as follows:

[0118]

[0119] where, and are respectively the low threshold and high threshold for trust level division. The higher the rating, the higher the credibility of the edge cloud.

[0120] For edge cloud devices with a trust level of 3, the SDP controller gives a relatively long SDP gateway port opening time (such as 180 - 300 seconds). For edge cloud devices with a trust level of 2, the controller adopts a medium opening duration (such as 60 - 120 seconds). For edge cloud devices with a low trust level, the controller only briefly opens the gateway port (such as 20 - 40 seconds).

[0121] Step S2.3: The SDP controller returns gateway information to the SDP client

[0122] After the SDP gateway port is successfully activated, the SDP controller securely returns the communication information about the SDP gateway, including key information such as the gateway port number, communication key, and port opening duration, to the SDP client of the edge cloud. The client then establishes a secure tunnel connection with the SDP gateway based on this information.

[0123] Through the above-mentioned identity authentication knocking process, this solution effectively ensures that devices with different trust levels are reasonably protected during the identity authentication process, optimizes the authentication efficiency, and further enhances the security and reliability of communication between the edge cloud and the central cloud.

[0124] Step S3: Tunnel port knocking

[0125] The SDP controller on the edge cloud performs tunnel port knocking on the SDP gateway on the central cloud, requests to establish an IPSec encrypted channel with the SDP gateway to ensure confidentiality and integrity during the communication process. And monitor the running status of the edge cloud device. If an anomaly (such as environmental change, tampering behavior, etc.) is detected, the trust level is reduced or tunnel access is blocked.

[0126] Step S3.1: The SDP client initiates a tunnel connection request;

[0127] When the SDP client application or device in the edge cloud needs to transfer data to the central cloud, it initiates a tunnel connection request to the SDP controller. This request contains data such as the client's identity information, device identifier (Device ID), session token, current IP address, and timestamp, which are used to verify the legitimacy of the request and the trusted status of the device.

[0128] This measure aims to prevent potential attacks such as IP address spoofing, data tampering, or replay attacks. The timestamp and nonce mechanism can effectively limit late attacks, while the session token can reduce the overhead of repeated authentication.

[0129] Step S3.2: Identity authentication and request review

[0130] After receiving the tunnel connection request, the SDP controller verifies the client's identity based on the following multiple dimensions, checks the validity of the session token to ensure that it has not expired and is authentic.

[0131] (1) Device identifier comparison: Confirm whether the device ID is consistent with the trusted device identifier recorded in the previous authentication to exclude the possibility of device tampering.

[0132] (2) IP address matching verification: Ensure that the IP address when the client sends the request matches the IP address recorded in the previous authentication to prevent IP spoofing attacks.

[0133] (3) Timestamp validity verification: Verify whether the request timestamp is within the allowed time window to reduce the risk of replay attacks.

[0134] If the client authentication is successful, the SDP controller will instruct the SDP gateway to open the specified tunnel port and enter the next phase. Otherwise, the controller will reject the request and return relevant error messages or warnings.

[0135] Step S3.3: Establish a tunnel;

[0136] Once the SDP client on the edge cloud passes the authentication, the SDP controller on the central cloud will send an instruction to the SDP gateway to instruct it to open the tunnel port.

[0137] Step S3.3.1: Issue the tunnel port opening instruction

[0138] The SDP controller sends an instruction to the SDP gateway to open the tunnel port. This instruction contains the relevant network parameters and key exchange parameters of the client device. The SDP gateway will reserve a port for the client for subsequent negotiation and establishment of the encrypted tunnel.

[0139] Step S3.3.2: IPsec encrypted tunnel negotiation

[0140] Between the SDP gateway and the client, the IPsec protocol starts the key negotiation process and uses the Internet Key Exchange (IKE) mechanism to complete the negotiation of encryption parameters and mutual authentication. The specific steps are as follows:

[0141] The first-phase handshake (security parameter negotiation): The client and the SDP gateway negotiate important parameters such as encryption algorithms, hash algorithms, and key exchange methods, and generate a master key for subsequent encryption processes.

[0142] The second-phase handshake (session key generation): Based on the master key, generate a temporary session key for data encryption and verification to further ensure the security of data communication.

[0143] Establishment of the encrypted tunnel: After completing the above handshake process, a secure tunnel based on IPsec is formally established between the edge cloud device and the central cloud SDP gateway. After the tunnel is established, all business data is encrypted and decrypted in real time during transmission, ensuring the confidentiality, integrity, and anti-tampering of the data transmission process, and greatly improving the overall security of the cloud-edge collaborative communication link.

[0144] Step S3.3.3: Dynamic access policy and trust level control

[0145] After the tunnel is established, the system will dynamically apply access policies according to the trust level of the client to ensure that only clients in a trusted state can communicate with the central cloud. The trust level is dynamically adjusted mainly based on the following factors:

[0146] (1)Device status monitoring: If the device operating status shows abnormalities (such as changes in environmental variables, hardware abnormalities, etc.), the system will lower the device's trust level.

[0147] (2)Behavior detection: If abnormal network behavior or configuration changes are detected, the system may directly block the client's tunnel access and issue a security alert.

[0148] (3)Access frequency and pattern evaluation: Based on the frequency and pattern of the client requesting to transmit information to the central cloud, evaluate whether its behavior conforms to normal operating habits, and thus adjust the access policy.

[0149] Through the above steps, the SDP client can establish an IPsec-based secure tunnel connection with the SDP gateway to provide protection for subsequent data transmission. This process not only enhances security but also ensures that only verified edge clouds can transmit information to the central cloud.

[0150] At the same time, according to the edge cloud trust level obtained in step 2.2 Adjust the tunnel opening time. For edge cloud devices with a trust level of 3 (high trust level), the tunnel port opening time is longer (such as 180 - 300 seconds), and relatively loose access permissions are provided, allowing the transmission of highly sensitive data. The monitoring frequency during the tunnel life cycle is moderate, but once an abnormality is detected, an early warning is immediately triggered and the permissions are moderately reduced. For edge cloud devices with a trust level of 2 (medium trust level), the tunnel port opening duration is 60 - 120 seconds, the real-time monitoring and logging intensity increase, and real-time responses are made to suspicious behaviors and communication permissions are dynamically adjusted. For edge cloud devices with a trust level of 1 (low trust level), the tunnel port opening duration is limited to 20 - 40 seconds, the real-time monitoring intensity is comprehensively strengthened, and once a potential threat is detected, the communication link is quickly interrupted and a security alert is issued, and an emergency plan for the large model is automatically generated according to step S5.

[0151] Step S4: Business port knocking

[0152] After successfully establishing a secure encrypted tunnel based on the IPsec protocol, the edge cloud device needs to further go through the business port knocking mechanism before being allowed to upload business data to the central cloud. This stage aims to ensure that the business port is only briefly open for devices that have passed the trust verification, thereby minimizing the port exposure time and potential attack risks and enhancing the overall security of the cloud-edge collaboration environment.

[0153] Step S4.1: Business port knocking;

[0154] After the SDP client establishes a secure tunnel with the SDP gateway, it sends a service port knocking packet to the SDP gateway through the secure communication tunnel. The knocking packet contains the unique identifier of the SDP client, the service information requested to be transmitted to the central cloud, and a timestamp.

[0155] The SDP client on the edge cloud initiates a service port knocking request to the SDP gateway of the central cloud through the established secure communication tunnel. The knocking request data packet carries a wealth of authentication and service-related information, including:

[0156] (1) Unique device identification: includes device ID, MAC address or unique device identifier, so that the central cloud SDP gateway can quickly and accurately identify and record the identity of the device.

[0157] (2) Business request information: clearly indicates the type of data transmission requested, such as real-time data upload, sensitive business operations, configuration updates, etc., to facilitate the gateway to evaluate the security sensitivity of the request.

[0158] (3) Request session information: The session token or related key information negotiated during the tunnel establishment process is included to assist in verifying the authenticity of the knock request and prevent malicious knock requests.

[0159] Through the above measures, the SDP gateway can effectively identify the legitimacy of the request source and ensure the security and effectiveness of the knocking process.

[0160] Step S4.2: Multi-level supplementary identity verification

[0161] After receiving the service port knocking data packet, the SDP gateway immediately performs a preliminary legitimacy review, including: checking whether the device unique identifier is in the current valid connection list, verifying whether the service request information matches the device permissions, checking the data packet integrity and time validity of the knocking request, and preventing replay attacks and data tampering.

[0162] After the initial review is passed, the SDP gateway will send a knock confirmation request to the SDP controller. After receiving the confirmation request, the SDP controller will further perform secondary identity authentication and access rights review. The review content includes but is not limited to: the current trust level and historical trust records of the device, the real-time security status of the device and the risk level of access behavior, the sensitivity of the business request, etc.

[0163] Step S4.3: SDP gateway releases data receiving port

[0164] After strict review by the SDP controller, if the device identity and authority verification are passed, the SDP controller sends a clear service port opening instruction to the SDP gateway, notifying the gateway to open the corresponding service port to the central cloud and adjust the status of the communication tunnel to remain open.

[0165] The present invention innovatively introduces a dynamic management mechanism for the lifecycle of service ports, and uses the trusted level of the edge cloud device (i.e., the historical trusted value and the current trusted level value) updated in real time during the secondary authentication process in step S4.2 to dynamically adjust the opening time of the service port. Specifically, the previous trusted level of the device is defined as , and the new trusted level after this authentication is . Then, the difference in the change of the trusted level is:

[0166]

[0167] Furthermore, the opening duration of the service port is dynamically calculated according to the change in the trusted level. The specific formula is as follows:

[0168]

[0169] where is the preset standard opening benchmark duration of the service port, and γ is the adjustment coefficient for the change in the trusted level, which is used to reflect the influence degree of the change in the trusted level on the port opening time. When is greater than 0, it indicates that the credibility of the device has increased, and the port opening time is appropriately extended; when is less than 0, it indicates that the credibility of the device has decreased, and the port opening time is appropriately shortened; when is 0, the opening time is executed according to the standard trusted level benchmark duration. is the corresponding weight coefficient set according to the newly calculated trusted level. The specific formula is as follows:

[0170]

[0171] When the new trusted value after this authentication is lower than the threshold , the weight coefficient is 80%, and the opening time of the service port is reduced; when the new trusted value is between the threshold and , the weight coefficient is 100%, and the preset standard opening time of the service port remains unchanged; when the new trusted value is higher than the threshold , the weight coefficient is 120%, and the opening time of the service port is increased.

[0172] Through the above dynamic mechanism, the refined control of the service port is realized, so that the increase or decrease in the credibility of the edge cloud device can be timely reflected in the service port opening policy, effectively reducing the long-term exposure risk of the port, while ensuring the best balance between communication efficiency and security, and adapting to the complex dynamic requirements of the cloud-edge collaborative network environment.

[0173] Step S4.4 Business data upload;

[0174] After receiving the instruction from the SDP controller, the SDP gateway briefly opens the specified service port according to the instruction, and the SDP client of the edge cloud device can directly interact with the business system of the central cloud through this open port.

[0175] During the business data transmission process, the SDP gateway monitors the data transmission activities in real time, records the transmission logs and periodically verifies the integrity of the business data. When the business transmission is completed or the port life cycle ends, the SDP gateway automatically closes the business port and the communication tunnel to prevent security risks caused by long-term exposure of the port and long-term establishment of the communication tunnel.

[0176] Step S5: Automatic generation of large model emergency response plan

[0177] When security risks or abnormal events occur in any link from Step S1 to S4 (such as the reduction of device trust level, authentication failure, abnormal tunnel connection request or abnormal business port access), the large model emergency response plan generation module designed by the present invention is automatically started. This module fully integrates the characteristics of security events detected in real time, the specific interaction mode between the edge cloud and the central cloud, the historical threat event handling experience, and the emergency response plan cases stored in the knowledge base, and constructs a security brain driven by a pre-trained large model to quickly generate an emergency response plan for the current event characteristics.

[0178] Specifically, the plan generation and disposal process is divided into the following key stages:

[0179] Step S5.1: Initial plan generation;

[0180] After receiving the security event data generated and reported by the security brain the emergency response plan generation module will automatically generate a plan through the large model. The input event data usually contains the following multi-modal feature vectors:

[0181]

[0182] Among them, represents the characteristics of the i-th security event, including timestamp, threat level, attack source, attack target, etc. During the plan generation process, the system models this task as a conditional generation problem, that is, under the conditions of the given input event data the emergency response plan knowledge base of the central cloud and the edge cloud and solve the optimal emergency response plan output:

[0183]

[0184] Among them, Represents the conditional probability distribution for generating the pre - plan, which are the trainable parameters of the large - model.

[0185] The large - model adopts a generation framework based on the Transformer structure and gradually generates the emergency plan text through an autoregressive mechanism. The generation process is as follows:

[0186]

[0187] Among them, represents the t - th word of the pre - plan text. The generated pre - plan will include multi - level handling opinions for the central cloud and edge cloud such as traffic blocking, permission adjustment, etc.

[0188] Step S5.2: Expert review and feedback mechanism;

[0189] The generated pre - plan will be submitted to experts in the field for review. The review content includes the rationality, implementability, and potential risks of the pre - plan. Experts score each handling opinion based on a scoring matrix:

[0190]

[0191] Among them, represents the score given by the expert to the i - th handling opinion and the j - th decision dimension (such as timeliness, security, operability). The scoring function combines expert experience and system reference indicators.

[0192] According to the scoring results, the pre - plan review is divided into the following two execution modes:

[0193] (1) Automatic execution mode: If the scoring matrix meets all execution threshold conditions, the system automatically executes the handling opinion , and records the operation log .

[0194] (2) Manual execution mode: For opinions that require manual intervention, the system will notify network managers or operation managers to execute through text messages, emails, etc., and record the manual operation log .

[0195] Step S5.3: Model fine - tuning and iterative optimization;

[0196] For pre - plans that fail the review, the expert's modification opinions will be recorded as feedback data and passed into the model knowledge base for fine - tuning training. The fine - tuning training objective of the large - model is to minimize the following loss function:

[0197]

[0198] Among them, is the expectation of the training samples composed of security event data and expert feedback After multiple rounds of optimization, the model will gradually improve its ability to generate high-quality preplans.

[0199] Step S5.4: Automatic linkage and threat disposal;

[0200] The finally optimized model outputs automatic disposal opinions, and the system performs specific operations according to these opinions, such as traffic blocking, access permission adjustment, or vulnerability repair. The execution results will be recorded in the disposal log, and at the same time, a network threat event analysis report will be generated. The report content includes information such as threat source, threat path, disposal measures, and disposal results, comprehensively improving the threat handling efficiency of the cloud-edge collaborative network.

Claims

1. A cloud-edge collaborative security management method based on SDP, characterized in that, The following steps are involved: Step S1: Authentication port knocking; The SDP client of the edge cloud device actively sends a connection request to the SDP controller of the central cloud. The SDP controller opens the identity authentication service port according to the preset port control mechanism and feeds back the port opening information to the client. Step S2: identity authentication knocking; The SDP client calculates the real-time trust level of the device based on the trust characteristics of the device and updates the trust value in real time. The SDP controller releases the SDP gateway after verifying that the edge cloud identity is trustworthy and returns the gateway information to the SDP client. Step S3: Tunnel port knocking: The SDP controller applies to establish a secure tunnel connection based on the IPsec protocol with the SDP gateway. After verifying the client identity based on the validity of the authentication token, the SDP controller instructs the SDP gateway to open the tunnel port and dynamically adjusts the life cycle and access rights of the secure tunnel according to the real-time trust level. Step S4: Business port knocking: In the established secure communication tunnel, the SDP client sends a service port knocking request data packet to the SDP gateway. After receiving the service port knocking request, the SDP gateway performs secondary identity verification through the SDP controller, dynamically determines the service port opening time according to the real-time trust level change of the client, opens the corresponding service port, and allows the edge cloud device to transmit data to the central cloud; Step S5: Automatic generation of large model emergency plan: When a security abnormality occurs in any link from step S1 to step S4, the emergency plan generation module based on the pre-trained large model is started to automatically generate a security disposal plan and a network threat event analysis report for the abnormal event.

2. The method for cloud-edge collaborative security management based on SDP according to claim 1, wherein The SDP client, SDP controller, and SDP gateway are all deployed in the cloud-data-in-one machine. The corresponding modules are started according to the role played by the cloud-data-in-one machine in its environment to realize cloud-edge transmission security management.

3. The method for cloud-edge collaborative security management based on SDP according to claim 1, wherein The specific implementation process in step S2 is: Step S2.1: identity authentication knocking; Step S2.1.1 Extract trusted features of the device; Step S2.1.2: Calculate the real-time credibility of the device based on the time window; Step S2.1.3: Trusted value update; Step S2.2: The SDP controller releases the SDP gateway; Step S2.3: The SDP controller returns the gateway information to the SDP client.

4. The cloud-edge collaborative security management method based on SDP according to claim 3, wherein, The real-time trust level calculation described in step S2.1.2 is achieved by constructing a device feature matrix based on a time window and performing normalization processing, using the Lagrangian function method to achieve adaptive adjustment of the weights of the trust feature indicators, and introducing a time decay function to dynamically adjust the weight of the influence of the trust level historical data on the current credibility.

5. A cloud-edge collaborative security management method based on SDP according to claim 1, characterized in that, The specific implementation process in step S3 is: Step S3.1: The SDP client initiates a tunnel connection request; The request contains the client's identity information, device identification, session token, current IP address, and timestamp data, which are used to verify the legitimacy of the request and the trusted status of the device; Step S3.2: Identity verification and request review; The SDP controller conducts identity review on the initiated tunnel connection request, including device identifier comparison, IP address matching verification, timestamp validity verification, to prevent security threats such as device tampering, IP spoofing, and replay attacks; Step S3.3: Establish a tunnel; An IPsec encrypted tunnel is negotiated and established between the SDP client and the SDP gateway.

6. The method for cloud-edge collaborative security management based on SDP according to claim 5, characterized in that, In step S3.3, an IPsec encrypted tunnel is established between the SDP client and the SDP gateway. The access policy is dynamically applied according to the trust level of the client to ensure that only clients in a trusted state can communicate with the central cloud, and different encryption tunnel opening times are set according to the trust level of the edge cloud.

7. A cloud-edge collaborative security management method based on SDP according to claim 1, characterized in that The specific implementation process in step S4 is as follows: Step S4.1: Business port knock; Step S4.2: Multi-level supplementary identity verification; Step S4.3: The SDP gateway releases the data receiving port; Step S4.4: Business data upload.

8. The method for cloud-edge collaborative security management based on SDP according to claim 7, wherein, In step S4.2, multi-level supplementary identity verification is carried out. It is checked whether the unique device identifier is in the current valid connection list, whether the business request information matches the device permissions, and the integrity and time validity of the knocked request packet are verified to prevent replay attacks and data tampering in the secure transmission of cloud-edge collaboration.

9. A cloud-edge collaborative security management method based on SDP according to claim 7, characterized in that In step S4.3, a dynamic management mechanism for the business port life cycle is introduced. The opening time of the business port is dynamically adjusted using historical trust values and current trust level values, ensuring the best balance between communication efficiency and security and adapting to the complex dynamic requirements of the cloud-edge collaborative network environment.

10. A cloud-edge collaborative security management method based on SDP according to claim 1, characterized in that In step S5, the large model emergency plan generation process uses a large language model based on the Transformer architecture. It fully integrates the characteristics of security events detected in real time, the specific interaction patterns between the edge cloud and the central cloud, the historical threat event handling experience, and the emergency plan cases stored in the knowledge base to construct a security brain driven by a pre-trained large model and quickly generate an emergency response plan for the current event characteristics.

Images