Cloud edge collaborative security management method and device based on SDP

Abstract

The invention discloses a cloud edge collaborative security management method and device based on an SDP, and aims to solve the security threats of port scanning, DDoS attack, data stealing and tampering and the like faced by a central cloud in the process of transmitting data from an edge cloud to the central cloud in a cloud edge collaborative open dynamic environment. According to the invention, the software definition boundary SDP technology is innovatively introduced, a multi-port knocking mechanism is designed, the authentication port, the tunnel port and the service port are finely managed, the attacked or hijacked edge cloud equipment is effectively prevented from initiating unauthorized data transmission to the central cloud, and the communication security of the central cloud is guaranteed. Meanwhile, a lightweight self-adaptive dynamic real-time trust evaluation algorithm is designed to improve the system evaluation efficiency, and threat processing is performed and a network threat event analysis report is generated in combination with an emergency plan automatic generation method based on a large model, so that the threat processing efficiency is improved, and the labor 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 to support 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 needs.

[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, etc. Once these data are intercepted or tampered with during the transmission process, serious consequences will occur, such as data leakage, business interruption, or even endanger 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 during 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 are based on human beings for identity verification. For unattended edge cloud devices, how to effectively conduct device trustworthiness authentication and identity management 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 security protection intensity and the system operation efficiency 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. It can ensure the security of cloud-edge collaborative data communication, effectively improve communication efficiency, reduce unnecessary consumption of system performance, and thus provide a practical and effective technical solution for cloud-edge collaborative 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 collaborative 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 central cloud security. 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 the method of automatically generating emergency plans 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 collaborative security management method based on SDP, including the following steps: 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.

[0011] 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; 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; 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.

[0012] 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 optimizes, reviews, and responds to plans in conjunction with security policies to achieve intelligent and automated security protection.

[0013] Compared with the traditional solution, the beneficial effects of the present invention are: 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.

[0014] 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.

[0015] 3. The identity authentication mechanism proposed by the present invention targets the device itself rather than the personnel and is specifically optimized for the unattended edge cloud environment. By implementing a differential authentication strategy based on the trust level calculated in real time by the device, from strict multi-factor authentication to fast lightweight authentication, it not only avoids the errors and security risks that may be brought by human factors, but also 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.

[0016] 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 of 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.

[0017] 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

[0018] 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 according to these drawings.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] 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.

[0023] Figure 5A trusted value update scheme diagram based on a time window for a cloud-edge collaborative security management method provided by an embodiment of the present invention based on SDP. Detailed implementation manners

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

[0025] To better understand this technical solution, the method of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0026] Refer to Figure 1 In the present invention, an SDP client, an SDP controller, and an SDP gateway are all deployed on a cloud data integration machine.

[0027] Refer to Figure 2 During the cloud-edge collaboration process, the cloud data integration machine acting as the central cloud opens the SDP controller and the SDP gateway, and the cloud data integration machine acting as the edge cloud opens the SDP client.

[0028] Refer to Figure 3 A method and device for cloud-edge collaborative security management based on SDP proposed by the present invention include the following steps: Step S1: Authentication port knocking Before the SDP client on the edge cloud sends an identity authentication request to the SDP controller on the central cloud, in order to ensure that the SDP controller can receive the identity authentication request from the SDP client, the SDP controller needs to open the relevant ports for identity authentication. To achieve this purpose, the SDP client on the edge cloud performs the first knocking operation.

[0029] The specific authentication port knocking process includes the following steps: Step S1.1: Authentication port knocking The SDP controller on the edge cloud sends the first knock 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: Step S1.1.1: Key negotiation and distribution As the central management node, the SDP controller first conducts a secure key negotiation process with the SDP client on the edge cloud. This process usually uses an asymmetric encryption algorithm or a pre-shared key mechanism to generate a temporary key or use a preset key. Once the key negotiation is successful, the SDP controller securely distributes the temporary key or preset key to the corresponding SDP client on the edge cloud for generating the knocking key for the authentication request in the future.

[0030] Step S1.1.2: Knocking Key Generation The SDP client of the edge cloud calculates a secure knocking key dedicated to this authentication knocking through a specific encryption algorithm based on its own 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.

[0031] Step S1.1.3: Construct and Send a Knocking UDP Packet 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.

[0032] Specifically, the UDP knocking packet contains the following content: (1) Edge cloud SDP client unique identifier: This identifier can be a device ID or MAC address, etc., used for the SDP controller to accurately identify the client device.

[0033] (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.

[0034] Step S1.2: The Port Control Module Releases the Identity Authentication Port 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 successful verification, the port module temporarily opens the identity authentication port.

[0035] Step S1.3: The Port Control Module Returns the Identity Authentication Port Information to the SDP Client 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.

[0036] Through the above steps, this solution effectively enhances the security in the authentication request stage on the basis of realizing the dynamic control of the device's secure identity authentication port, 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.

[0037] Step S2: Identity Authentication Knocking After completing the authentication port knocking, the SDP client of the edge cloud can initiate the identity authentication phase based on the obtained identity authentication port information. In this phase, 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 security access policy of the device.

[0038] Specifically, it includes the following steps: Step S2.1: Identity authentication knocking 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 its own unique identifier, authentication token, and other data. The SDP controller selects the corresponding identity authentication method according to the trust level of the client to complete the knocking process of device identity authentication.

[0039] Step S2.1.1: Device trusted feature extraction Four security-related trust metrics are proposed in this project, including authentication type , authorization type , self-security ability and the number of malicious accesses . 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).

[0040] Table 1: Table of value assignments and level divisions for security-related trust metrics

[0041] 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 a relative relationship reflecting the security levels can be used, not just the above positive integers 1, 2, or 3. The above settings are selected for ease of understanding and calculation.

[0042] Step S2.1.2: Real-time credibility calculation of the device based on the time window 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 blocks 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.

[0043] At the th timestamp, select The behavior data is used as the input data set for trusted computing. Therefore, is the measurement sample , , …, , …, The total number of groups. From the behavior data, the following feature matrix can be obtained:

[0044] where , .

[0045] As the usage time increases, the scale of the evaluation matrix will become larger and larger. According to the attenuation property of credibility, the present invention adopts an innovative mechanism, combining 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: Step S2.1.2.1: Window real-time credibility calculation Input the evaluation matrix , and divide 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.

[0046] Step S2.1.2.2: Form a credibility evaluation matrix In each time window and , the behavior data can form a credibility evaluation matrix. Taking the time window as an example of real-time credibility calculation. The evaluation matrix can be expressed as follows:

[0047] where .

[0048] Step S2.1.2.3: Evaluation matrix normalization 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 . In one case, is decreasing, that is, the desired value is very small; this value includes the average response time, and the specific formula is as follows:

[0049] where and are the maximum and minimum values of the column evidence respectively.

[0050] Another case is that is increasing, that is, the desired value by the user is relatively large; this value includes 5 other metrics in addition to the average response time, and the formula is as follows:

[0051] where and are the maximum and minimum values of the column evidence respectively.

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

[0053] where .

[0054] Step S2.1.2.4: Obtain the decision matrix Multiply the matrix by the weight matrix to obtain the decision matrix , and the formula is as follows:

[0055] where .

[0056] Step S2.1.2.5: Edge cloud trust sequence calculation In the decision matrix , the ideal values of each attribute are as follows, and the formula is as follows:

[0057] where , is the ideal value of each property in the standardized matrix .

[0058] And calculate the square difference of the distance between the common value and the ideal value in

[0059] Construct the Lagrangian function as follows:

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

[0061] Therefore, the method used in the present invention is 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 derivatives , and the following formula can be obtained:

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

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

[0064] where , is the number of time windows, is the credibility of the resource to be evaluated based on the time window. Parallel execution of formula (1) to formula (12) can obtain the credibility sequence of the edge cloud, that is .

[0065] Step S2.1.2.6: Overall credibility calculation The credibility u based on the time window is obtained in the above formula. 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:

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

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

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

[0069] Step S2.1.3 Trusted Value Update In the implementation process of the trusted computing mechanism proposed in the present invention, the issue of updating the trusted value must be considered. The update frequency of the trusted value will affect the execution efficiency of the system. The present invention adopts a trusted value update scheme based on time windows.

[0070] Suppose is the old trusted value based on the existing monitoring data, is the closest trusted value based on the new monitoring data. When the number of new monitoring data reaches the set value of the time window, start a new calculation for , and then a new time series can be obtained as follows:

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

[0072] Step S2.2: SDP Controller Releases the SDP Gateway After successfully completing the device identity authentication and confirming the identity is trustworthy, the SDP controller 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, during this process, the SDP controller dynamically determines the life cycle and access rights of the gateway port according to the level of the edge cloud to ensure network security. The evaluation formula for the trusted level of the edge cloud is as follows:

[0073] Among them, and are respectively the low threshold and high threshold for trusted level division, and the higher the rating, the higher the credibility of the edge cloud.

[0074] For edge cloud devices with a trust level of 3, the SDP controller gives a longer 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).

[0075] Step S2.3: The SDP controller returns gateway information to the SDP client 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.

[0076] 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.

[0077] Step S3: Tunnel port knocking 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 it monitors the running status of the edge cloud devices. If anomalies (such as environmental changes, tampering behaviors, etc.) are detected, the trust level is reduced or tunnel access is blocked.

[0078] Step S3.1: The SDP client initiates a tunnel connection request; 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 trust status of the device.

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

[0080] Step S3.2: Identity authentication and request review 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.

[0081] (1)Device identity comparison: Confirm whether the device ID is consistent with the trusted device identity recorded in the previous authentication to rule out the possibility of device tampering.

[0082] (2)IP address matching verification: Ensure that the IP address when the client sends a request is consistent with the IP address recorded in the previous authentication to prevent IP spoofing attacks.

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

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

[0085] Step S3.3: Establish a tunnel; 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.

[0086] Step S3.3.1: Issuing the tunnel port opening instruction 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.

[0087] Step S3.3.2: IPsec encrypted tunnel negotiation 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: 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.

[0088] 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.

[0089] Encryption Tunnel Establishment: After completing the above handshake process, a secure tunnel based on IPsec is officially 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.

[0090] Step S3.3.3: Dynamic Access Policy and Trust Level Control 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: (1) Device Status Monitoring: If the device running status shows abnormalities (such as changes in environmental variables, hardware abnormalities, etc.), the system will lower the trust level of the device.

[0091] (2) Behavior Detection: If abnormal network behaviors or configuration changes are detected, the system may directly block the tunnel access of the client and issue a security alert.

[0092] (3) Access Frequency and Pattern Evaluation: According to the frequency and pattern of the client requesting to transmit information to the central cloud, evaluate whether its behavior conforms to normal operation habits, and thus adjust the access policy.

[0093] Through the above steps, the SDP client can establish a secure tunnel connection based on IPsec with the SDP gateway, providing 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.

[0094] At the same time, according to the trusted level of the edge cloud 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 relatively long (such as 180 - 300 seconds), and relatively loose access permissions are provided, allowing the transmission of highly sensitive data. The monitoring frequency is moderate during the tunnel life cycle, but once an abnormality is found, 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 intensity of real-time monitoring and log recording increases, 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 intensity of real-time monitoring is comprehensively strengthened, and once a potential threat is found, 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.

[0095] Step S4: Business Port Knocking 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 allowing business data to be uploaded to the central cloud. This stage aims to ensure that the business port is only briefly open to devices that have passed trusted verification, thereby minimizing the port exposure time and potential attack risks and enhancing the overall security of the cloud-edge collaboration environment.

[0096] Step S4.1: Business port knocking; After the SDP client establishes a secure tunnel with the SDP gateway, it sends a business port knocking data packet to the SDP gateway through the secure communication tunnel. The knocking data packet contains the unique identifier of the SDP client, the business information requested to be transmitted to the central cloud, the timestamp, etc.

[0097] The SDP client on the edge cloud initiates a business port knocking request to the SDP gateway of the central cloud through the established secure communication tunnel. The knocking request data packet carries rich authentication and business-related information, specifically including: (1) Device unique identifier: Includes the device ID, MAC address, or exclusive device identifier, so that the central cloud SDP gateway can quickly and accurately identify and record the identity of the device.

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

[0099] (3) Request session information: Attaches the session token or related key information negotiated during the tunnel establishment process, used to assist in verifying the authenticity of the knocking request and preventing malicious knocking requests.

[0100] Through the above measures, the SDP gateway can effectively authenticate the legitimacy of the request source and ensure the security and effectiveness of the knocking process. Step S4.2: Multi-level supplementary identity authentication After receiving the business port knocking data packet, the SDP gateway immediately performs a preliminary legality review, including: checking whether the device unique identifier is in the current valid connection list, verifying whether the business request information matches the device permissions, and checking the data packet integrity and time validity of the knocking request to prevent replay attacks and data tampering.

[0101] After the preliminary review passes, the SDP gateway sends a knocking confirmation request to the SDP controller. After receiving the confirmation request, the SDP controller further performs secondary identity authentication and access permission review. The review content includes but is not limited to: the current trust level and historical trust record of the device, the real-time security status and access behavior risk level of the device, the sensitivity of the business request, etc.

[0102] Step S4.3: The SDP gateway releases the data receiving port After being strictly reviewed by the SDP controller, if the device identity and permissions verification pass, the SDP controller sends a clear service port opening instruction to the SDP gateway, notifies the gateway to open the corresponding service port to the central cloud, and adjusts the status of the communication tunnel to remain open.

[0103] The present invention innovatively introduces a dynamic management mechanism for the service port life cycle, 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 identity 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 trusted level change is:

[0104] Furthermore, the opening duration of the service port is dynamically calculated according to the trusted level change, and the specific formula is as follows:

[0105] where is the preset standard service port opening benchmark duration, and γ is the trusted level change adjustment coefficient, which is used to reflect the influence degree of the trusted level change on the port opening time. When is greater than 0, it indicates that the device credibility has increased, and the port opening time is appropriately extended; when is less than 0, it indicates that the device credibility 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, and the specific formula is as follows:

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

[0107] Through the above dynamic mechanism, the refined control of business ports is realized, so that the increase or decrease in the credibility of edge cloud devices can be timely reflected in the business port opening policy, effectively reducing the long-term exposure risk of ports. At the same time, the best balance between communication efficiency and security is ensured, meeting the complex dynamic requirements of the cloud-edge collaborative network environment.

[0108] Step S4.4 Business data upload; After receiving the instruction from the SDP controller, the SDP gateway briefly opens the specified business 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.

[0109] 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 the long-term exposure of the port and the long-term establishment of the communication tunnel.

[0110] Step S5: Automatic generation of large model emergency response plan When security risks or abnormal events occur in any link from step S1 to S4 (such as a decrease in 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.

[0111] Specifically, the plan generation and disposal process is divided into the following key stages: Step S5.1: Initial plan generation; 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:

[0112] 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 given input event data , the central cloud and edge cloud plan knowledge base and conditions, solve the optimal emergency response plan output:

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

[0114] 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:

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

[0116] Step S5.2: Expert review and feedback mechanism; 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 disposal opinion based on a scoring matrix:

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

[0118] According to the scoring results, the pre - plan review is divided into the following two execution modes: (1) Automatic execution mode: If the scoring matrix meets all execution threshold conditions, the system automatically executes the disposal opinion , and records the operation log .

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

[0120] Step S5.3: Model fine - tuning and iterative optimization; For pre - plans that fail the review, the modification opinions of experts will be recorded as feedback data and input 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:

[0121] 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 emergency plans.

[0122] Step S5.4: Automatic linkage and threat handling; The finally optimized model outputs automatic handling 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 handling log, and at the same time, a network threat event analysis report will be generated. The report content includes information such as threat sources, threat paths, handling measures, and handling 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 1 to step 4, 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. According to claim 1, a cloud-edge collaborative security management device based on SDP is characterized in that 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. According to the SDP-based cloud-edge collaborative security management method of claim 1, it is characterized in that: 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. According to the SDP-based cloud-edge collaborative security management method of claim 3, it is characterized in that: 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. According to the SDP-based cloud-edge collaborative security management method of claim 1, it is 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 performs identity verification on the initiated tunnel connection request, including device identification comparison, IP address matching verification, and timestamp validity verification to prevent device tampering, IP spoofing, and replay attack security threats; Step S3.3: Establish a tunnel; The SDP client and the SDP gateway negotiate to establish an IPsec encrypted tunnel.

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

7. The cloud-edge collaborative security management method based on SDP according to claim 1 is characterized in that: The specific implementation process in step S4 is: Step S4.1: knocking on the service port; Step S4.2: multi-level supplementary identity authentication; Step S4.3: The SDP gateway releases the data receiving port; Step S4.4: Upload business data.

8. The SDP-based cloud-edge collaborative security management method according to claim 7, characterized in that: In step S4.2, multi-level supplementary identity authentication is performed to check whether the device unique identifier is in the current valid connection list, verify whether the business request information matches the device permissions, check the data packet integrity and time validity of the knock request, and prevent replay attacks and data tampering in cloud-edge collaborative secure transmission.

9. The cloud-edge collaborative security management method based on SDP according to claim 7 is characterized in that: Step S4.3 introduces a dynamic management mechanism for the service port lifecycle, which uses historical trust values ​​and current trust level values ​​to dynamically adjust the opening time of the service port, ensuring the optimal balance between communication efficiency and security, and adapting to the complex dynamic needs of the cloud-edge collaborative network environment.

10. The SDP-based cloud-edge collaborative security management method according to claim 1, characterized in that: In step S5, the large-model emergency plan generation process adopts a large language model with a Transformer architecture, which fully integrates the security event characteristics 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 plan cases stored in the knowledge base, and constructs a security brain driven by a pre-trained large model to quickly generate emergency response plans for current event characteristics.

Images