Threat detection method and device for cloud native encrypted traffic, equipment and storage medium

Abstract

The invention provides a threat detection method and device for cloud native encrypted traffic, equipment and a storage medium. The method comprises the following steps: acquiring encrypted traffic of a traffic processing node in a cloud native environment; analyzing the encrypted traffic to obtain metadata information; performing session division on the data packet of the encrypted traffic according to the metadata information to obtain a plurality of session flow records, each session flow record corresponding to one session; calculating statistical behavior characteristics of the session flow records; according to the metadata information and an address mapping relationship in the cloud native environment, determining a source object and a target object corresponding to the session flow record; acquiring historical access behavior characteristics of the source object and historical access time characteristics of the target object; and inputting the statistical behavior characteristics, the historical access behavior characteristics and the historical access time characteristics into a preset threat detection model for threat detection. According to the invention, the threat detection accuracy of the cloud native encrypted traffic can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and particularly relates to a cloud-native encrypted traffic threat detection method, device, equipment and storage medium. BACKGROUND

[0002] With the wide application of cloud-native architecture, microservices, containerized deployment, service mesh and other technologies have become the main form of modern business systems. In such an environment, business components and external access generally use encryption protocols such as TLS, mTLS, HTTPS, gRPC over TLS for communication, and encrypted traffic has become the mainstream form of data transmission. Encryption mechanisms can effectively protect the privacy and integrity of data during transmission, but also make it difficult for traditional threat detection methods based on plaintext content to continue to function.

[0003] Existing threat detection technologies usually rely on the following methods: one method relies on deep packet inspection of plaintext traffic, but since encrypted traffic cannot directly obtain plaintext content, this method is basically ineffective in encrypted scenarios; another method attempts to decrypt encrypted traffic by obtaining keys, session keys or intermediate certificates, and then analyzes the decrypted content, but this method has problems such as complex key distribution, high key management difficulty, large decryption performance overhead, strong system invasiveness, and the like. In addition, in a cloud-native environment, business components are highly dynamic, pods and containers are frequently created, migrated and destroyed, and service instances can be scaled at any time, so traditional decryption solutions and detection algorithms based on fixed servers and fixed links are difficult to adapt to such a complex and variable environment, posing challenges to detection accuracy and system stability. In summary, in a cloud-native environment, in the face of a large amount of encrypted traffic, relying solely on decryption cannot effectively identify potential threats. Existing technologies generally have problems such as low decryption efficiency, complex key management, detection capability dependent on plaintext, high false positive and false negative rates, and the like.

[0004] Therefore, how to improve the threat detection accuracy of cloud-native encrypted traffic has become a technical problem that needs to be solved in the field. SUMMARY

[0005] The present application aims to provide a cloud-native encrypted traffic threat detection method, device, equipment and storage medium to solve the above technical problems in the prior art.

[0006] In one aspect, to achieve the above object, the present application provides a cloud-native encrypted traffic threat detection method.

[0007] The cloud-native encrypted traffic threat detection method comprises: collecting encrypted traffic of a traffic processing node in a cloud-native environment; analyzing the encrypted traffic to obtain metadata information; dividing sessions of data packets of the encrypted traffic according to the metadata information to obtain a plurality of session flow records, wherein each session flow record corresponds to a session; calculating statistical behavior characteristics of the session flow records; determining source objects and destination objects corresponding to the session flow records according to the metadata information and an address mapping relationship in the cloud-native environment; obtaining historical access behavior characteristics of the source objects and historical access time characteristics of the destination objects; and inputting the statistical behavior characteristics, the historical access behavior characteristics and the historical access time characteristics into a preset threat detection model for threat detection.

[0008] Further, the step of calculating the statistical behavior characteristics of the session flow records comprises: calculating a packet length sequence, adjacent data packet time intervals, flow duration, traffic direction ratios and / or data packet numbers corresponding to the session flow records.

[0009] Further, the source objects comprise source Pods, source containers and / or source nodes, and the step of obtaining the historical access behavior characteristics of the source objects comprises: within a preset historical time window, based on historical session flow records corresponding to the source objects, counting access behavior characteristics of the source objects within the historical time window, wherein the historical access behavior characteristics comprise historical session numbers, access failure times, types of access destination objects and / or types of access ports.

[0010] Further, the destination objects comprise destination Services, destination Pods, destination containers and / or destination nodes, and the step of obtaining the historical access time characteristics of the destination objects comprises: within the historical time window, based on historical session flow records corresponding to the destination objects, aggregating access events according to a preset time granularity, counting access times of the destination objects in different time periods, constructing an access time distribution of the destination objects, and determining a normal access time window of the destination objects from the access time distribution, taking the access time distribution and the access time window as the historical access time characteristics.

[0011] Further, the cloud-native encrypted traffic threat detection method further comprises: determining a business type of the destination Service, a data type carried by the destination Service, whether the destination Service is exposed to the outside and an operation permission of the destination Service; performing weighted calculation according to the business type, the data type carried by the destination Service, whether the destination Service is exposed to the outside and the operation permission to obtain a service sensitivity level corresponding to the destination Service; wherein the step of performing threat detection comprises: inputting the statistical behavior characteristics, the historical access behavior characteristics, the historical access time characteristics and the service sensitivity level into a preset threat detection model for threat detection.

[0012] Further, the step of collecting the encrypted traffic of the traffic processing node in the cloud-native environment comprises: starting a traffic collection module in the traffic processing node when the traffic processing node starts; mounting the traffic collection module to a network interface of the traffic processing node in an initialization stage of the traffic processing node; capturing, by the traffic collection module, a data packet passing through the network interface in a kernel state; transmitting the data packet captured in the kernel state to a shared ring buffer in a user state; and obtaining the encrypted traffic by reading the data packet from the shared ring buffer in batches by a user state thread.

[0013] Further, the cloud-native encrypted traffic threat detection method further comprises: listening to a Pod life cycle event dispatched to the traffic processing node in the cloud-native environment; counting the number of the Pod life cycle events within a preset time window; and reducing a sampling rate of the traffic collection module and / or prolonging a time interval of data reporting of the traffic collection module when the number of the Pod life cycle events reaches a preset threshold.

[0014] Further, the cloud-native encrypted traffic threat detection method further comprises: obtaining a key matched with the metadata information from the key management system; decrypting the session flow record by using the key; recording a decryption process parameter and a decryption result of decrypting the session flow record; and wherein the step of performing threat detection comprises: inputting the statistical behavior feature, the historical access behavior feature, the historical access time feature, the decryption process parameter and the decryption result into a preset threat detection model to perform threat detection.

[0015] Further, the cloud-native encrypted traffic threat detection method further comprises: obtaining a key life cycle change event, wherein the key life cycle change event comprises a generation event, an update event, a rotation event and / or a revocation event; and maintaining the key in the key management system according to the key life cycle change event.

[0016] In another aspect, to achieve the above object, the present application provides a cloud-native encrypted traffic threat detection device.

[0017] The cloud-native encrypted traffic threat detection apparatus comprises: a collection module configured to collect encrypted traffic of a traffic processing node in a cloud-native environment; an analysis module configured to analyze the encrypted traffic to obtain metadata information; a processing module configured to perform session division on data packets of the encrypted traffic according to the metadata information to obtain a plurality of session flow records, wherein each session flow record corresponds to a session; a calculation module configured to calculate statistical behavior features of the session flow records; a determination module configured to determine source objects and destination objects corresponding to the session flow records according to the metadata information and an address mapping relationship in the cloud-native environment; an acquisition module configured to acquire historical access behavior features of the source objects and historical access time features of the destination objects; and a detection module configured to input the statistical behavior features, the historical access behavior features and the historical access time features into a preset threat detection model to perform threat detection.

[0018] In another aspect, to achieve the above object, the present application further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above method.

[0019] In another aspect, to achieve the above object, the present application further provides a computer readable storage medium, which stores a computer program, wherein the computer program is executed by a processor to implement the steps of the above method.

[0020] The application provides a cloud-native encrypted traffic threat detection method, device, equipment and storage medium. First, the encrypted traffic passing through the node is collected on the traffic processing node in the cloud-native environment, and the collected encrypted traffic is protocol-analyzed to extract metadata information. Then, the data packets are session-divided based on the metadata information, the dispersed encrypted data packets are aggregated into a plurality of session flow records, and the statistical behavior characteristics of the traffic data are calculated from the session dimension. Subsequently, the cloud-native running objects corresponding to the session flow records are associated to determine the source object and the destination object of the session. On this basis, the historical access behavior characteristics of the source object in the historical time window and the historical access time characteristics of the destination object in the time dimension are respectively constructed by searching the historical session flow records. Finally, the statistical behavior characteristics, the historical access behavior characteristics and the historical access time characteristics are input into a preset threat detection model to determine whether the current session flow record has a threat. Through the application, the running entity mapping in the cloud-native environment and the historical behavior and time pattern characteristics are further introduced on the basis of the network metadata information of the encrypted traffic, the historical access habits of the source object and the historical access time pattern of the destination object are combined with the encrypted traffic behavior, and a more fine-grained behavior baseline and abnormal pattern can be described without decrypting all the traffic. The session statistical behavior characteristics, the source object historical access behavior characteristics and the destination object historical access time characteristics are jointly modeled in the same threat detection model, and the model learns the deviation relationship of the current session behavior relative to the source object behavior baseline and the destination object time baseline. When observed from any feature dimension, the current session may only present a slight anomaly or even normal behavior, but when the source-side access range change, the destination-side access time deviation and the timing behavior of the session itself are considered in the joint feature space, the combined anomaly can be amplified, so that the hidden horizontal movement, low-frequency data leakage and other attack behaviors can be identified. At the same time, during the business peak period or the regular maintenance window, although the session statistical behavior characteristics may present a pattern similar to scanning or burst traffic, after being combined with the source object historical behavior and the destination object normal access time window, the behavior can be identified as normal business fluctuation, effectively reducing the false positive rate, thereby improving the identification ability of the threats in the encrypted traffic and improving the accuracy of the encrypted traffic threat detection in the cloud-native environment. BRIEF DESCRIPTION OF DRAWINGS

[0021] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The detailed description is made with reference to the accompanying drawings. Figure 1 A flowchart of a cloud-native encrypted traffic threat detection method provided for Embodiment One of the application; Figure 2 A block diagram of the cloud-native encrypted traffic threat detection device provided for the second embodiment of the present application is shown in the figure. Figure 3 A hardware structure diagram of the computer device provided for the third embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0022] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and do not limit the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of the present application.

[0023] Embodiment One The embodiment of the present application provides a cloud-native encrypted traffic threat detection method. Through the method, the encrypted traffic in the cloud-native environment is modeled and analyzed without decryption, and the running context in the cloud-native environment is combined for threat detection, thereby improving the threat detection accuracy for encrypted traffic. Specifically, Figure 1 A flowchart of the cloud-native encrypted traffic threat detection method provided for the first embodiment of the present application is shown in the figure. Figure 1 As shown in the figure, the cloud-native encrypted traffic threat detection method provided by the embodiment includes the following steps S101 to S107.

[0024] Step S101: Collecting encrypted traffic of a traffic processing node in a cloud-native environment.

[0025] In this step, the cloud-native environment can be a Kubernetes-based container cluster environment, and a plurality of types of traffic processing nodes are deployed in the cloud-native environment, such as a Kubernetes worker node (Worker Node), a gateway node, a service mesh sidecar node (Service Mesh Sidecar), an ingress gateway (Ingress Gateway), a container, a Pod, etc. The above traffic processing nodes undertake business, traffic forwarding, external traffic access or proxy forwarding functions in the service mesh.

[0026] Optionally, in a cloud-native environment, a traffic collection module is deployed on a traffic processing node for collecting network packets passing through the traffic processing node, and real-time collection of encrypted network traffic containing TCP, UDP and other protocols between nodes. The collection range includes but is not limited to: inbound or outbound traffic of each business container on the node, traffic forwarded by the service mesh agent node, encrypted traffic received or sent by the node-level network card, etc. Since applications in cloud-native environments widely use TLS, mTLS, IPSec and other methods for encrypted transmission, this embodiment limits the collection target to encrypted traffic, that is, the protocol identifier is HTTPS, TLS, gRPC over TLS, or the data packet transmits ciphertext on the specified port.

[0027] Through the above collection operation, the encrypted traffic raw data packet of each traffic processing node in the cloud-native environment is obtained, providing basic data for subsequent analysis of metadata information and session division.

[0028] Optionally, during the collection process, the module has adaptive characteristics and can automatically adjust collection parameters such as sampling rate, data buffer size, etc. according to the dynamic changes of cloud-native environment resources, ensuring that complete and accurate traffic data can still be efficiently collected in the case of limited resources.

[0029] Optionally, by combining cloud-native resource monitoring interfaces (such as Kubernetes Metrics API, cAdvisor, NodeExporter, etc.) with local lightweight monitoring agents, real-time collection of resource usage information of nodes and containers is realized, such as CPU, memory, network bandwidth, I / O, etc. The collection module compares these resource parameters with the preset threshold according to the set dynamic scheduling algorithm, and automatically adjusts the sampling rate, buffer size, number of concurrent threads, reporting frequency and other collection parameters, realizing resource-aware adaptive traffic collection.

[0030] Optionally, the parameter adjustment details are as follows: The Resource Monitor submodule built-in the traffic collection module obtains the resource status of the cloud-native environment through two types of ways. Through the Kubernetes Metrics API, real-time resource indicators of nodes and containers are obtained, including CPU occupancy, memory usage, Pod network I / O, container quantity, Pod restart times, etc. Alternatively, by calling the / proc file system or eBPF monitoring hook, underlying resource usage and network performance data are obtained, including network card queue length, packet loss rate, delay, system load, CPU core utilization.

[0031] Among them, the CPU utilization reflects the current processing capacity of the system; the memory occupancy rate indicates the available cache space of the system; the network throughput indicates the network bandwidth load level; the packet loss rate represents the collection performance and network pressure; the number of containers and scheduling events reflect the node load fluctuation and cloud-native resource change.

[0032] The Adaptive Controller 6 in the module evaluates the above parameters periodically, and adjusts the collection parameters according to the threshold model or the dynamic weight model. The adjustment logic supports two modes: a static threshold mode based on preset resource thresholds, such as reducing the sampling rate when CPU > 80%; and a dynamic weight mode that dynamically determines the adjustment amplitude by weighting and averaging the change trends of multiple indicators. All parameter adjustments take effect immediately and are verified by an internal feedback loop to ensure that they do not cause collection interruptions.

[0033] Optionally, when multiple traffic collection modules are deployed in the same cluster, resource load information is shared through a lightweight coordination protocol to achieve cross-module collection load balancing.

[0034] Optionally, a centralized processing module is set up to preprocess the collected encrypted traffic data using the distributed computing resources of the cloud-native environment.

[0035] Step S102: Analyzing encrypted traffic to obtain metadata information.

[0036] In this step, the metadata information is used to describe the basic properties of the encrypted traffic at the network layer and the transport layer and part of the observable behavior characteristics, which includes but is not limited to timestamp, source IP address, destination IP address, source port number, destination port number, protocol type, packet size, etc.

[0037] Specifically, the collected encrypted traffic packets are protocol-analyzed, at least the header analysis of the IP layer and the transport layer (such as TCP, UDP) is completed, and the timestamp, five-tuple (source IP, destination IP, source port, destination port, and protocol type field) and packet length of each packet are extracted. Optionally, TCP flag bits, handshake state flags, connection direction, etc. are also extracted to assist subsequent session division and behavior characteristic calculation. In this step, the metadata information does not involve decryption of the encrypted payload, and only the packet header and connection attributes can complete the subsequent session-level modeling.

[0038] Step S103: Dividing the packets of the encrypted traffic into session flow records according to the metadata information.

[0039] Each session flow record corresponds to a session.

[0040] In this step, the session flow record is used to represent a set of packets of an end-to-end network session in its entire life cycle. Optionally, the packets are grouped and session partitioned based on the five-tuple recorded in the metadata information, for example, using the five-tuple information as the session identifier; or in a bidirectional session scenario, the source / destination IP, source / destination port pair and protocol type are merged into one bidirectional session.

[0041] Specifically, a session state table is maintained in the traffic collection module or the upstream processing module. When a new three-way handshake or the first data packet is detected, a new session entry is created; if the five-tuple of the subsequently arrived data packet matches an existing session, the data packet is included in the session flow record; when connection closure, timeout or long-time no data transmission is detected, the session is marked as ended and the session flow record is output. In the above manner, the scattered data packets are reorganized into a plurality of session flow records, each of which corresponds to a complete or quasi-complete network session, facilitating subsequent calculation of statistical behavior features and association with cloud native context according to the session dimension.

[0042] Step S104: Calculate the statistical behavior features of the session flow record.

[0043] In this step, the statistical behavior features are used to depict the timing behavior and data characteristics of the encrypted traffic from the session level, so as to be subsequently used as one of the input features of the threat detection model.

[0044] Optionally, in one embodiment, for each session flow record, based on all the data packets contained in the session, the following behavior features are calculated, including but not limited to: Packet length sequence, that is, the length of each data packet is recorded in the order of arrival time to form a sequence or statistical quantities are calculated based on the sequence, such as maximum value, minimum value, mean value or variance, etc., which are used to finely depict the size variation of each data packet in the session, and can reflect patterns such as fixed-length heartbeat and long data block upload; Adjacent data packet time interval, that is, the time difference between adjacent data packets in the session is calculated to obtain a time interval sequence or related statistical quantities, which are used to represent the rhythm characteristics of the session communication, and are helpful for identifying periodic scanning and burst data transmission; Flow duration, that is, obtained by the difference between the first packet timestamp and the last packet timestamp of the session, reflecting the length of the session life cycle, which assists in distinguishing between short connection probe and long connection tunnel behavior; Traffic direction ratio, that is, the ratio of the number or byte amount of data packets in the session from the source object to the destination object to the number or byte amount from the destination object to the source object, which is used to judge whether the session is dominated by one-way data push or there are more interactive request responses; Packet number, that is, the total number of data packets contained in the session, which is used to reflect the session size and interaction complexity.

[0045] These statistical behavior features are organized into feature vectors in a fixed format and input into subsequent threat detection models for identifying abnormal communication patterns, such as traffic surges, long connection heartbeat abnormalities, or one-way large traffic, etc.

[0046] Step S105: According to the metadata information and the address mapping relationship in the cloud-native environment, the source object and the destination object corresponding to the session flow record are determined.

[0047] In this step, the address mapping relationship in the cloud-native environment is used to establish a mapping between the network perspective and the cloud-native running perspective, and the cloud-native running object corresponding to the IP or port is parsed out, so that the threat detection no longer stays in the IP or port dimension, but falls on the cloud-native entities such as Pod, container, Service, node, etc.

[0048] Specifically, the address mapping relationship in the cloud-native environment is maintained by the resource management component, such as Kubernetes API Server, kubelet, CNI plug-in, Service discovery component, Sidecar agent, etc., which can provide the corresponding relationship between Pod IP, Service ClusterIP / NodePort, host node IP, container instance, etc. and cloud-native objects.

[0049] The analysis module can periodically synchronize and cache these mapping relationships, such as the mapping relationship between Pod IP and Pod identification, Namespace, label, the mapping relationship between Service IP or end and Service identification, the mapping relationship between node IP and node name, etc. When the session flow record is obtained, the matching entry is found from the above address mapping relationship according to the source IP, source port, destination IP, destination port and protocol type. If the source IP corresponds to a certain Pod IP or container node IP, the cloud-native entity is confirmed as the source object; if the destination IP corresponds to a certain Service, Pod or node, the corresponding cloud-native entity is confirmed as the destination object. If there are Service forwarding, Sidecar agent and other scenarios, further determination can be made according to the flow direction and port number to select the source or destination object in the business perspective, for example, taking the Service as the destination object and the Pod or container as the source object. In any case, the source object and the destination object are both communication participants of the traffic in the cloud-native environment.

[0050] In this way, a set of explicit source objects and destination objects are determined for each session flow record, so that the subsequent historical behavior statistics and time pattern analysis can be bound to specific cloud-native workloads.

[0051] Step S106: Obtain the historical access behavior features of the source object and the historical access time features of the destination object.

[0052] In this step, the historical access behavior feature is used to describe the access habits and access range of the source object within a certain historical time window, and the historical access time feature is used to describe the normal access mode of the destination object in the time dimension. Optionally, an index of historical session flow records is maintained in the background, and each session flow record is associated with its corresponding source object and destination object.

[0053] On this basis, optionally, in an embodiment, the source object includes a source Pod, a source container and / or a source node. For the source object, within a preset historical time window, such as the past hours, days or a configurable period of time, historical session flow records with the source object as the source are retrieved, and the access behavior feature is counted. Further optionally, the access behavior feature includes the number of historical sessions, the types of access destination objects, the types of access ports, the number of access failures, whether there is an abnormal access mode flag, etc., wherein the types of access destination objects include accessed Services, destination Pods or containers, the number of historical access failures includes connection establishment failures, reset times or abnormal closing times, etc., and the abnormal access mode includes scanning behavior of accessing a large number of different destination objects or ports in a short time, forming the historical access behavior feature of the source object.

[0054] Optionally, in an embodiment, the destination object includes a destination Service, a destination Pod, a destination container and / or a destination node. For the destination object, within the same historical time window, historical session flow records with the destination object as the destination are retrieved, historical access events are aggregated according to a preset time granularity, such as hours, weekdays or non-weekdays, time periods within a day, etc., the number of accesses in different time periods is counted, the access time distribution of the destination object is constructed, and the normal access time window with significantly higher access volume than the baseline is identified on the access time distribution, such as the access volume from 9:00 to 18:00 on weekdays is significantly higher than other periods, and there is almost no access in the early morning period. The access time distribution and its corresponding normal time window constitute the historical access time feature of the destination object, which is used to represent the normal use habits of the destination object in the time dimension.

[0055] Through the above processing, the statistical behavior characteristics of the session flow record are refined, covering multiple dimensions such as packet length change, time interval, directionality and scale, and through specific index design and statistics on the historical access behavior characteristics of the source object and the historical access time characteristics of the destination object, the access range, failure condition and abnormal behavior of the source object, and the normal access time mode of the destination object are quantitatively expressed. On the one hand, it is beneficial to identify whether the source object has behavior changes such as expansion of access range and abnormal increase of access failure rate, and on the other hand, it is beneficial to identify whether the destination object is accessed at an abnormal time period, thereby providing a context-rich behavior baseline for the threat detection model. The specific feature settings of the three aspects can simultaneously reflect the current session behavior characteristics, the deviation from the historical behavior baseline of the relative source object, and the deviation from the normal access time habit of the relative destination object, which is beneficial to identify complex abnormal scenarios such as a large number of accesses at non-working hours and abnormal connections that have never accessed a sensitive destination object before.

[0056] Step S107: inputting the statistical behavior characteristics, the historical access behavior characteristics and the historical access time characteristics into a preset threat detection model for threat detection.

[0057] In this step, the threat detection model is used to judge whether the current session has potential threats by comprehensively considering the features of the above-mentioned multiple dimensions. Optionally, the model is a classification model based on supervised learning, such as gradient boosting tree, deep neural network, etc., or the model is an anomaly detection model based on unsupervised learning or semi-supervised learning, such as clustering model, auto-encoder, anomaly scoring model based on probability distribution, etc., and the present application does not limit this.

[0058] Specifically, for each session flow record, the statistical behavior characteristics obtained in step S104, the source object historical access behavior characteristics obtained in step S106 and the historical access time characteristics of the destination object are spliced into a feature vector, which is input into a preset threat detection model, and a threat score or a threat category label is output by the model calculation. For example, the output includes categories such as normal, suspicious scanning behavior, abnormal lateral movement and abnormal data leakage, or the output is a numerical risk score. Optionally, a threshold judgment and alarm strategy is set after the model output, and when the risk score of a certain session exceeds a preset threshold, it is marked as a high-risk session, an alarm event is generated and pushed to a security operation platform for further analysis and disposal by security personnel.

[0059] In the cloud-native encrypted traffic threat detection method provided in this embodiment, firstly, encrypted traffic passing through the traffic processing node in the cloud-native environment is collected, and the collected encrypted traffic is parsed to extract metadata information; then, based on the metadata information, the data packets are divided into sessions, and the scattered encrypted data packets are aggregated into several session flow records, and statistical behavioral characteristics of the traffic data are calculated from the session dimension; subsequently, the cloud-native running objects corresponding to the session flow records are associated to determine the source object and the destination object of the session; based on this, by retrieving historical session flow records, historical access behavior characteristics of the source object within the historical time window and historical access time characteristics of the destination object in the time dimension are constructed respectively; finally, the above statistical behavioral characteristics, historical access behavior characteristics, and historical access time characteristics are input into a preset threat detection model to determine whether there is a threat in the current session flow record. The cloud-native encrypted traffic threat detection method provided in this embodiment introduces runtime entity mappings and historical behavior and time pattern features from the cloud-native environment on top of the basic network metadata information of encrypted traffic. It combines encrypted traffic behavior with the historical access habits of the source object and the historical access time patterns of the destination object. Without decrypting all traffic, it can characterize a more granular behavioral baseline and anomaly patterns through feature combination. Session statistical behavior features, historical access behavior features of the source object, and historical access time features of the destination object are jointly modeled in the same threat detection model. The model learns the deviation of the current session behavior from the source object's behavioral baseline and the destination object's time baseline. When observed from any single feature dimension, the current session may only show slight anomalies or even appear normal. However, when considering changes in the source-side access range, deviations in the destination-side access time, and the temporal behavior of the session itself in the joint feature space, this combined anomaly can be amplified, thereby identifying covert lateral movement, low-frequency data leakage, and other attack behaviors. Meanwhile, during peak business periods or routine maintenance windows, although session statistics behavior characteristics may present patterns similar to scanning or sudden traffic, when combined with the historical behavior of the source object and the normal access time window of the destination object, such behavior can be identified as normal business fluctuations, effectively reducing the false alarm rate, thereby improving the ability to identify threats in encrypted traffic and enhancing the accuracy of encrypted traffic threat detection in cloud-native environments.

[0060] Optionally, in one embodiment, the threat detection method for cloud-native encrypted traffic further includes: determining the service type, data type, external exposure, and operation permissions of the target Service; performing a weighted calculation based on the service type, data type, external exposure, and operation permissions to obtain the service sensitivity level corresponding to the target Service; wherein, the threat detection step includes: inputting statistical behavior characteristics, historical access behavior characteristics, historical access time characteristics, and service sensitivity level into a preset threat detection model for threat detection.

[0061] Specifically, before performing threat detection, the service sensitivity level information of the target Service is further introduced, and the service sensitivity level, along with the aforementioned characteristics, is input into the threat detection model. First, the business type, data type, external exposure, and operation permissions of the target Service are determined. The business type indicates whether the Service is a core transaction service, internal management control service, or general query service; the data type indicates whether the service primarily processes sensitive data, such as user personal information, financial data, or confidential business configurations; external exposure distinguishes whether the Service provides access through a public network exit or external interface; and operation permissions reflect whether the service interface involves high-risk operations, such as configuration changes, batch deletion, fund transfers, and authorization management.

[0062] After obtaining the aforementioned attributes, each attribute is weighted according to preset weighting rules. For example, services exposed to the external network, containing sensitive data, and with high-risk operation permissions are assigned higher weights to calculate the service sensitivity level of that service. This service sensitivity level can be represented as multiple levels or a numerical sensitivity score. Therefore, when performing threat detection, statistical behavioral characteristics, historical access behavior characteristics, historical access time characteristics, and the service sensitivity level are input into the preset threat detection model, enabling the model to consider the importance and sensitivity of the target service itself while assessing the anomaly level of the current session.

[0063] The cloud-native encrypted traffic threat detection method provided in this embodiment not only judges based on traffic behavior and historical baselines, but also adjusts the risk assessment according to the importance of the target service itself. For sessions with slightly abnormal access patterns but whose target is a low-sensitivity internal service, their risk level can be appropriately reduced; while when similar abnormal behavior points to a highly sensitive service exposed to the external network, it can be identified as a high-risk session and given priority for alerting. Through this superimposed mechanism, the detection results are closer to the actual business risks, helping security operations personnel to prioritize the handling of potential attacks that have a greater impact on critical business and sensitive data, thereby improving overall threat response efficiency and resource utilization efficiency.

[0064] Optionally, in one embodiment, the step of collecting encrypted traffic from a traffic processing node in a cloud-native environment includes: starting a traffic acquisition module in the traffic processing node when it starts up; attaching the traffic acquisition module to the network interface of the traffic processing node during the initialization phase of the traffic processing node; capturing data packets passing through the network interface in kernel mode through the traffic acquisition module; transmitting the data packets captured in kernel mode to a shared ring buffer in user mode; and reading data packets in batches from the shared ring buffer through a user-mode thread to obtain encrypted traffic.

[0065] Specifically, when a traffic processing node starts, a traffic acquisition module is launched within that node. This module can be deployed as a Sidecar container co-located with the service container, or as a DaemonSet process running on a worker node. During the traffic processing node initialization phase, the traffic acquisition module is attached to the node's network interface, for example, via kernel mechanisms such as AF_PACKET, XDP, or eBPF to a specified network interface card (NIC) or virtual NIC. The traffic acquisition module captures network packets passing through this network interface in kernel mode, reducing the performance overhead caused by user-mode context switching. The network packets captured in kernel mode are written to a user-mode accessible shared circular buffer. User-mode threads then read packets in batches from the shared circular buffer, performing basic filtering and traffic splitting, and extracting the traffic corresponding to encryption protocols as encrypted traffic.

[0066] Optionally, the traffic acquisition module is lightweighted and optimized with multi-layer data acquisition channels based on the characteristics of the cloud-native operating environment. It mainly includes the following functional units: A kernel-level fast capture unit, based on eBPF or AF_XDP technology, is directly mounted to the network card driver layer in kernel mode to achieve zero-copy packet capture. It supports multi-core parallel capture and user-space buffer separation, reducing the overhead of switching between kernel and user space.

[0067] The data buffering and batch transmission unit uses a ring-shaped shared memory structure to store captured data packets and transmits them in batches to improve throughput. It supports dynamic adjustment of buffer size and sampling rate, automatically optimizing based on node resource load.

[0068] A lightweight protocol identification and formatting unit performs basic protocol identification of data packets at the acquisition end, extracting metadata such as timestamps, source / destination IPs, ports, and protocol types. It achieves rapid encapsulation and reporting through a parallel asynchronous mechanism, avoiding blocking of the main acquisition thread.

[0069] The resource adaptive control unit monitors CPU, memory, and bandwidth usage in real time, and automatically adjusts parameters such as sampling rate, cache size, and number of concurrent threads based on system load. This unit communicates with the Kubernetes API Server through a lightweight agent to dynamically adapt to Pod scheduling and migration.

[0070] The process of encrypted traffic acquisition based on the above traffic acquisition module is described as follows: When the node starts, the module is deployed in the cloud-native traffic processing node as a Sidecar or DaemonSet. During the initialization phase, the module is mounted to the specified network interface via an eBPF program to achieve high-speed kernel-mode packet capture. In the real-time acquisition phase, the data packets captured in kernel mode are directly transmitted to user mode through the AF_XDP channel, without the need for kernel buffer copying. User-mode threads read data packets in batches from the shared ring buffer, extract metadata, format them, and output the processing results to downstream applications synchronously or asynchronously. Dynamic resource adjustment involves obtaining the resource status parameters of the traffic processing node, including CPU utilization, memory usage, network throughput, packet loss rate, number of containers, and / or container scheduling events. The adjustment strategy for the traffic acquisition parameters of the traffic acquisition module is determined based on the changing trends of these resource status parameters. These parameters include sampling rate, buffer size, number of concurrent acquisition threads, and / or data reporting frequency. The acquisition module periodically checks the resource status parameters and automatically adjusts the acquisition parameters to maintain node stability. When node resources recover, the acquisition parameters automatically recover, ensuring data integrity.

[0071] The cloud-native encrypted traffic threat detection method provided in this embodiment defines the acquisition implementation path as kernel-mode capture, shared ring buffer transfer, and user-mode batch reading on the traffic processing node. By employing kernel-mode capture and user-mode batch processing, the overhead of capturing each packet can be significantly reduced, mitigating the performance impact on business processes. By deploying the acquisition module on the cloud-native traffic processing node, it can automatically scale and schedule with the cluster, achieving a good integration of acquisition capabilities and cloud-native infrastructure. This ensures that the encrypted traffic data required for threat detection can be acquired stably and with low overhead, improving the overall feasibility and scalability of the solution.

[0072] Optionally, in one embodiment, the threat detection method for cloud-native encrypted traffic further includes: monitoring Pod lifecycle events scheduled to traffic processing nodes in the cloud-native environment; counting the number of Pod lifecycle events within a preset time window; and reducing the sampling rate of the traffic acquisition module and / or extending the data reporting time interval of the traffic acquisition module when the number of Pod lifecycle events reaches a preset threshold.

[0073] Specifically, the system monitors Pod lifecycle events scheduled to traffic processing nodes in a cloud-native environment. These Pod lifecycle events include add, delete, and eviction. Within a preset time window, the system counts the number of these Pod lifecycle events to obtain the total number of Pod lifecycle events related to the traffic processing node within that time window. When the count of Pod lifecycle events reaches or exceeds a preset threshold, the node is considered to be in a state of resource change or load fluctuation. At this time, the system automatically reduces the sampling rate of the traffic acquisition module deployed on the traffic processing node and / or extends the data reporting interval of the traffic acquisition module to reduce the resource consumption of the acquisition module on the node. The preset time window can be configured according to business needs, such as tens of seconds or several minutes, and the preset threshold can be set according to the node's processing capacity and scheduling frequency.

[0074] The cloud-native encrypted traffic threat detection method provided in this embodiment monitors Pod lifecycle events scheduled to traffic processing nodes and adaptively adjusts collection parameters based on the number of events. This allows the collection module to perceive the dynamic characteristics of the cloud-native environment: when a large number of Pods are created, deleted, or evicted on a node in a short period of time, it usually means that the node is in a state of scaling up or down, fault migration, or high load fluctuation. At this time, reducing the sampling rate or extending the reporting interval can effectively prevent the collection module from further increasing the node load or even triggering an avalanche effect during sensitive periods of the system. Thus, while ensuring the quality of collected data, it dynamically balances node resources and collection accuracy. In specific environments where cloud-native resources fluctuate or large-scale scheduling events occur, it improves the stability and availability of large-scale cloud-native clusters.

[0075] Optionally, in one embodiment, when a legitimate key management system exists and the business allows for the decryption of a portion of encrypted traffic within a controlled scope, the cloud-native encrypted traffic threat detection method further includes: obtaining a key from the key management system that matches the metadata information; using the key to decrypt session stream records; and recording the decryption process parameters and decryption results of the decrypted session stream records. The threat detection step includes: inputting statistical behavioral characteristics, historical access behavioral characteristics, historical access time characteristics, decryption process parameters, and decryption results into a preset threat detection model for threat detection.

[0076] Specifically, a key matching the metadata information is obtained from the key management system. Matching criteria include the certificate identifier corresponding to the destination IP or port, the SNI used in the session, and the certificate fingerprint. The obtained key is used to decrypt the corresponding session stream record, obtaining the decrypted plaintext payload or partial plaintext features. During decryption, parameters are recorded, including the key version used, whether decryption was successful, the reason for failure, decryption time, and the proportion of data decrypted. The decryption result is also recorded, including the obtained plaintext or the failed decryption. Then, statistical behavioral characteristics, historical access behavioral characteristics, historical access time characteristics, decryption process parameters, and the decryption result are all input into a pre-defined threat detection model for threat detection.

[0077] The cloud-native encrypted traffic threat detection method provided in this embodiment targets scenarios where encrypted traffic needs to be decrypted or can be decrypted. By linking with a key management system, it decrypts session stream records, resolving the problem of chaotic key management in existing technologies and improving decryption efficiency. The decryption process and results are input as additional features into the threat detection model. For traffic that can be legally decrypted, introducing the decryption results helps discover malicious payloads and illegal plaintext data hidden in the encrypted tunnel. Furthermore, even if not all traffic can be decrypted, the success rate and failure modes during the decryption process can carry security semantics, such as abnormal key usage behavior and abnormal decryption failure rates. Combined with existing detection methods based on metadata and cloud-native context, it can further improve the ability to identify complex threats and abuse of encrypted channels.

[0078] Optionally, in one embodiment, a multi-threaded parallel decryption processing technique is adopted. Based on the amount of traffic data and resource load, a resource-aware load balancing algorithm is used to dynamically allocate the number of decryption threads, so as to improve decryption efficiency while ensuring system stability.

[0079] Optionally, in one embodiment, the threat detection method for cloud-native encrypted traffic further includes: acquiring key lifecycle change events, wherein the key lifecycle change events include generation events, update events, rotation events and / or revocation events; and maintaining keys in the key management system based on the key lifecycle change events.

[0080] Specifically, by real-time monitoring of key management service interface calls, configuration change events, and the in-memory key cache area in the cloud-native environment, combined with event subscription and lightweight probe mechanisms, the system achieves automatic discovery and synchronous updates of newly generated or updated key information. By monitoring key lifecycle change events, the system maintains the keys in the key management system, including adding newly generated key entries, updating key version and validity information, marking old keys as expired or rotated, and updating the status of revoked keys to unavailable, ensuring that the key status in the key management system is synchronized with the actual operating environment. In actual operation, decryption attempts and decryption process parameters are recorded based on the latest key status to avoid using expired or revoked keys. Simultaneously, frequent key rotations and abnormal revocation behaviors are monitored to provide a basis for subsequent security analysis.

[0081] The cloud-native encrypted traffic threat detection method provided in this embodiment manages key lifecycle change events to ensure that the key information used in the threat detection process is up-to-date, valid, and compliant with security policies, thereby avoiding a large number of decryption failures caused by the use of expired keys and maintaining the stability of the decryption-assisted detection link.

[0082] Optionally, a multi-layered monitoring mechanism can be used to obtain real-time information on key lifecycle changes, including new generation, update, rotation, or revocation events. This is primarily achieved through three technical means: KMS / Key Service event monitoring. Real-time notifications of key creation, update, and rotation events are received through event subscriptions or Webhook interfaces provided by the cloud-native Key Management Service (KMS). Configuration and Secret file monitoring. In container or Pod environments, changes to Kubernetes Secrets, ConfigMaps, or local configuration files are monitored, and key changes are detected through version hashes, inotify, or the Kubernetes Watch API. Runtime probes or cache verification. Lightweight probes are deployed alongside the traffic parsing or key usage modules to periodically check the key cache status in memory, monitor changes to key handles or references, and trigger synchronization or refresh operations for unknown or expired keys. All newly discovered or updated key information is uniformly updated to the key management cache table, allowing the traffic collection and parsing modules to access the latest key information instantly for decryption attempts.

[0083] Optionally, in one embodiment, when a threat detection model issues a threat alert, an automated threat response mechanism in the cloud-native environment is immediately activated. Depending on the severity and type of the threat, different response strategies are executed, such as isolating infected containers or Pods, blocking the transmission path of malicious traffic, and restricting access to related IP addresses or services. Simultaneously, it collaborates with other security components in the cloud-native environment, such as intrusion prevention systems, security information and event management systems, to share threat information, achieving coordinated overall security protection and improving the cloud-native environment's ability to respond to security threats.

[0084] Example 2 Corresponding to Embodiment 1 above, Embodiment 2 of the present invention provides a threat detection device for cloud-native encrypted traffic. The technical features and corresponding technical effects can be referred to Embodiment 1 above, and will not be repeated in this embodiment. Figure 3 This is a block diagram of the cloud-native encrypted traffic threat detection device provided in Embodiment 2 of the present invention, as shown below. Figure 3 As shown, the cloud-native encrypted traffic threat detection device includes a collection module 201, a parsing module 202, a processing module 203, a calculation module 204, a determination module 205, an acquisition module 206, and a detection module 207.

[0085] The system comprises: a collection module 201 for collecting encrypted traffic from traffic processing nodes in a cloud-native environment; a parsing module 202 for parsing the encrypted traffic to obtain metadata information; a processing module 203 for dividing the encrypted traffic data packets into sessions based on the metadata information to obtain several session flow records, wherein each session flow record corresponds to one session; a calculation module 204 for calculating the statistical behavior characteristics of the session flow records; a determination module 205 for determining the source object and destination object corresponding to the session flow record based on the metadata information and the address mapping relationship in the cloud-native environment; an acquisition module 206 for acquiring the historical access behavior characteristics of the source object and the historical access time characteristics of the destination object; and a detection module 207 for inputting the statistical behavior characteristics, the historical access behavior characteristics, and the historical access time characteristics into a preset threat detection model for threat detection.

[0086] Optionally, in one embodiment, when the calculation module calculates the statistical behavioral characteristics of the session flow record, the specific steps performed include: calculating the packet length sequence, adjacent data packet time interval, flow duration, flow direction ratio, and / or data packet number corresponding to the session flow record.

[0087] Optionally, in one embodiment, the source object includes a source Pod, a source container, and / or a source node. When the acquisition module acquires the historical access behavior characteristics of the source object, the specific steps it performs include: within a preset historical time window, based on the historical session stream records corresponding to the source object, statistically analyzing the access behavior characteristics of the source object within the historical time window, wherein the historical access behavior characteristics include the number of historical sessions, the number of access failures, the type of access destination object, and / or the type of access port.

[0088] Optionally, in one embodiment, the target object includes a target Service, a target Pod, a target container, and / or a target node. When the acquisition module acquires the historical access time characteristics of the target object, the specific steps performed include: within the historical time window, based on the historical session stream records corresponding to the target object, aggregating access events according to a preset time granularity, counting the number of accesses to the target object in different time periods, constructing the access time distribution of the target object, and determining the normal access time window of the target object from the access time distribution, and using the access time distribution and the access time window as the historical access time characteristics.

[0089] Optionally, in one embodiment, the cloud-native encrypted traffic threat detection device further includes: a second determining module, used to determine the service type, data type, external exposure, and operation permissions of the target Service; a second calculating module, used to perform weighted calculations based on the service type, data type, external exposure, and operation permissions to obtain the service sensitivity level corresponding to the target Service; wherein, the detection module is further used to input the statistical behavior characteristics, the historical access behavior characteristics, the historical access time characteristics, and the service sensitivity level into a preset threat detection model for threat detection.

[0090] Optionally, in one embodiment, the acquisition module includes: a startup unit, configured to start the traffic acquisition module in the traffic processing node when the traffic processing node starts; a mounting unit, configured to mount the traffic acquisition module to the network interface of the traffic processing node during the initialization phase of the traffic processing node; a capture unit, configured to capture data packets passing through the network interface in kernel mode through the traffic acquisition module; a transmission unit, configured to transmit the data packets captured in kernel mode to a shared ring buffer in user mode; and a reading unit, configured to read the data packets in batches from the shared ring buffer through a user-mode thread to obtain the encrypted traffic.

[0091] Optionally, in one embodiment, the cloud-native encrypted traffic threat detection device further includes: a monitoring module for monitoring Pod lifecycle events scheduled to the traffic processing node in the cloud-native environment; a statistics module for counting the number of Pod lifecycle events within a preset time window; and an adjustment module for reducing the sampling rate of the traffic acquisition module and / or extending the data reporting time interval of the traffic acquisition module when the number of Pod lifecycle events reaches a preset threshold.

[0092] Optionally, in one embodiment, the cloud-native encrypted traffic threat detection device further includes: a second acquisition module, used to acquire a key matching the metadata information from the key management system; a decryption module, used to decrypt the session stream record using the key; and a recording module, used to record the decryption process parameters and decryption results of decrypting the session stream record; wherein the detection module is further used to input the statistical behavior characteristics, the historical access behavior characteristics, the historical access time characteristics, the decryption process parameters, and the decryption results into a preset threat detection model for threat detection.

[0093] Optionally, in one embodiment, the cloud-native encrypted traffic threat detection device further includes: a third acquisition module, configured to acquire key lifecycle change events, wherein the key lifecycle change events include generation events, update events, rotation events, and / or revocation events; and a management module, configured to maintain keys in the key management system based on the key lifecycle change events.

[0094] Example 3 This embodiment also provides a computer device, such as a smartphone, tablet computer, laptop computer, desktop computer, rack server, blade server, tower server, or cabinet server (including a standalone server or a server cluster composed of multiple servers), etc., capable of executing programs. Figure 3 As shown, the computer device 01 in this embodiment includes, but is not limited to, a memory 012 and a processor 011 that can be interconnected via a system bus, such as... Figure 3 As shown. It should be noted that, Figure 3 Only a computer device 01 with component memory 012 and processor 011 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0095] In this embodiment, the memory 012 (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 012 may be an internal storage unit of the computer device 01, such as the hard disk or memory of the computer device 01. In other embodiments, the memory 012 may also be an external storage device of the computer device 01, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 01. Of course, the memory 012 may include both the internal storage unit and its external storage device of the computer device 01. In this embodiment, the memory 012 is typically used to store the operating system and various reference software installed on the computer device 01, such as the program code of the cloud-native encrypted traffic threat detection device in Embodiment 2. In addition, memory 012 can also be used to temporarily store various types of data that have been output or will be output.

[0096] In some embodiments, processor 011 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. Processor 011 is typically used to control the overall operation of computer device 01. In this embodiment, processor 011 is used to run program code stored in memory 012 or process data, such as a threat detection method for cloud-native encrypted traffic.

[0097] Example 4 This embodiment also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, server, app reference store, etc., which stores computer programs. When the program is executed by a processor, it implements corresponding functions. The computer-readable storage medium of this embodiment is used to store a threat detection device for cloud-native encrypted traffic. When executed by a processor, it implements the threat detection method for cloud-native encrypted traffic of Embodiment 1.

[0098] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0099] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0101] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A threat detection method for cloud-native encrypted traffic, characterized in that, include: Collect encrypted traffic from traffic processing nodes in a cloud-native environment; The encrypted traffic is parsed to obtain metadata information; Based on the metadata information, the encrypted traffic data packets are divided into sessions to obtain several session stream records, wherein each session stream record corresponds to one session; Calculate the statistical behavioral characteristics of the session stream records; Based on the metadata information and the address mapping relationship in the cloud-native environment, determine the source object and destination object corresponding to the session stream record; Obtain the historical access behavior characteristics of the source object and the historical access time characteristics of the destination object; and The statistical behavior features, the historical access behavior features, and the historical access time features are input into a preset threat detection model for threat detection.

2. The threat detection method for cloud-native encrypted traffic according to claim 1, characterized in that, The steps for calculating the statistical behavioral characteristics of the session flow record include: calculating the packet length sequence, adjacent packet time interval, flow duration, flow direction ratio, and / or packet number corresponding to the session flow record; The source object includes a source Pod, a source container, and / or a source node. The step of obtaining the historical access behavior characteristics of the source object includes: within a preset historical time window, based on the historical session stream records corresponding to the source object, statistically analyzing the access behavior characteristics of the source object within the historical time window, wherein the historical access behavior characteristics include the number of historical sessions, the number of access failures, the type of access destination object, and / or the type of access port. The target object includes a target Service, a target Pod, a target container, and / or a target node. The step of obtaining the historical access time characteristics of the target object includes: within the historical time window, based on the historical session stream records corresponding to the target object, aggregating access events according to a preset time granularity, counting the number of accesses to the target object in different time periods, constructing the access time distribution of the target object, and determining the normal access time window of the target object from the access time distribution, and using the access time distribution and the access time window as the historical access time characteristics.

3. The threat detection method for cloud-native encrypted traffic according to claim 2, characterized in that, The method further includes: determining the business type, data type, external exposure, and operation permissions of the target Service; and performing a weighted calculation based on the business type, data type, external exposure, and operation permissions to obtain the service sensitivity level corresponding to the target Service. The threat detection steps include: inputting the statistical behavioral characteristics, the historical access behavior characteristics, the historical access time characteristics, and the service sensitivity level into a preset threat detection model for threat detection.

4. The threat detection method for cloud-native encrypted traffic according to claim 1, characterized in that, The steps for collecting encrypted traffic from traffic processing nodes in a cloud-native environment include: When the traffic processing node starts, the traffic acquisition module is started in the traffic processing node; During the initialization phase of the traffic processing node, the traffic acquisition module is attached to the network interface of the traffic processing node. The traffic acquisition module captures data packets passing through the network interface in kernel mode; The data packets captured in kernel mode are transferred to a shared circular buffer in user mode; and The encrypted traffic is obtained by reading the data packets in batches from the shared circular buffer using a user-mode thread.

5. The threat detection method for cloud-native encrypted traffic according to claim 4, characterized in that, Also includes: Monitor Pod lifecycle events scheduled to the traffic processing node in the cloud-native environment; Count the number of Pod lifecycle events within a preset time window; When the number of Pod lifecycle events reaches a preset threshold, the sampling rate of the traffic acquisition module is reduced and / or the data reporting time interval of the traffic acquisition module is extended.

6. The threat detection method for cloud-native encrypted traffic according to claim 1, characterized in that, The method further includes: obtaining a key that matches the metadata information from the key management system; decrypting the session stream record using the key; and recording the decryption process parameters and decryption result of the session stream record. The threat detection steps include: inputting the statistical behavior features, the historical access behavior features, the historical access time features, the decryption process parameters, and the decryption results into a preset threat detection model for threat detection.

7. The threat detection method for cloud-native encrypted traffic according to claim 6, characterized in that, Also includes: Acquire key lifecycle change events, wherein the key lifecycle change events include generation events, update events, rotation events and / or revocation events; as well as Maintain the keys in the key management system based on the key lifecycle change events.

8. A threat detection method for cloud-native encrypted traffic, characterized in that, include: The acquisition module is used to collect encrypted traffic from traffic processing nodes in a cloud-native environment. The parsing module is used to parse the encrypted traffic to obtain metadata information; The processing module is used to divide the encrypted traffic data packets into sessions based on the metadata information to obtain several session stream records, wherein each session stream record corresponds to one session; The calculation module is used to calculate the statistical behavioral characteristics of the session stream records; The determination module is used to determine the source object and destination object corresponding to the session stream record based on the metadata information and the address mapping relationship in the cloud-native environment; The acquisition module is used to acquire the historical access behavior characteristics of the source object and the historical access time characteristics of the destination object; and The detection module is used to input the statistical behavior features, the historical access behavior features, and the historical access time features into a preset threat detection model for threat detection.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images