Micro-service node identification method and device, communication equipment and storage medium
By building a finite state diagram of microservices and comparing differences, identifying abnormal service nodes, the problem of insufficient attack surface detection in the cloud-native microservice architecture is solved, and the security of the microservice system is improved.
Patent Information
- Application Number
- CN202311011078.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-08-10
- Publication Date
- 2025-02-18
- Estimated Expiration
- 2043-08-10
AI Technical Summary
Due to its elasticity and agility, cloud-native microservice architecture has brought about a sharp expansion of the attack surface, and the existing technology lacks effective detection methods.
By constructing a finite state graph of microservices based on the trace log, comparing the differences between adjacent finite state graphs, identifying abnormal service nodes, and thus determining the possible attack surface in the microservice system.
This method can effectively identify abnormal service nodes in the microservice system, improve the security of the microservice system, and enhance the detection ability of potential attack surfaces.
Smart Images

Figure CN119483989A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of network security technology, and in particular to a microservice node identification method, apparatus, communication equipment, storage medium, chip and computer program product. Background Art
[0002] With the development of cloud-native technology, microservice architecture has emerged. Cloud-native microservice architecture can decompose a single application into a group of independent services, each with its own processing logic, and communicate with each other through API (Application Programming Interface) calls.
[0003] In the cloud-native microservices architecture, each microservice can be deployed independently to achieve rapid iteration and flexible expansion. Its advantages lie in elasticity and agility. Therefore, in the cloud environment, the cloud-native microservices architecture has gradually become the mainstream cloud-native DevOps (a combination of development and operation and maintenance) architecture.
[0004] However, in addition to the advantages of elasticity and agility, the microservice architecture also brings about a sharp expansion of the attack surface. The independent deployment of each service means an increase in potential attack vectors, and frequent communication between services may also be used by attackers as an attack path. Among the existing solutions, there is still no technical solution to detect the attack surface in the cloud-native microservice architecture. Summary of the invention
[0005] The embodiments of the present application provide a microservice node identification method, apparatus, communication device, storage medium, chip, and computer program product, which can detect possible attack surfaces in a microservice system and improve the security of the microservice system.
[0006] A microservice node identification method, the method comprising:
[0007] Build a finite state graph of microservices based on tracking logs;
[0008] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0009] In one embodiment, after identifying the abnormal service node, the method further includes:
[0010] Generate security warning information based on the abnormal service node.
[0011] In one of the embodiments, the adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
[0012] In one embodiment, comparing the differences between adjacent finite state graphs to identify abnormal service nodes includes:
[0013] The differences between adjacent finite state graphs are compared to determine a newly added microservice node, and when the newly added microservice node is stable, the newly added microservice node is determined as an abnormal service node.
[0014] In one of the embodiments, the abnormal service nodes include shadow service nodes and unknown service nodes.
[0015] In one embodiment, the comparing the differences between adjacent finite state graphs to determine a newly added microservice node, and determining the newly added microservice node as an abnormal service node when the newly added microservice node is stable, further includes:
[0016] When the number of requests and / or responses of the newly added microservice node is higher than a preset threshold, it is determined that the newly added microservice node is stable.
[0017] In one embodiment, constructing a finite state graph of a microservice based on a tracking log includes:
[0018] Collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data;
[0019] And in the request and / or response data of each microservice node of the tracking chain data, the request and / or response except the final request and / or response data is deleted to obtain the target tracking chain data;
[0020] A finite state graph of the microservice is constructed based on the target tracking chain data.
[0021] In one embodiment, constructing a finite state graph of a microservice according to the target tracking chain data includes:
[0022] For each of the target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order, and if the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node;
[0023] If the call relationship identifier of any of the service call pairs does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1;
[0024] If any calling relationship identifier of the service calling pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service calling pair is incremented by 1.
[0025] In one of the embodiments, the abnormal service node includes calling an abnormal service node, and the method further includes:
[0026] For any of the microservice nodes in the finite state diagram, when the microservice node is not the newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold, the microservice node is used as the call abnormal service node.
[0027] In one embodiment, the method further comprises:
[0028] Determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node;
[0029] According to the node type of the microservice node called by the abnormal service node, an attack dimension corresponding to the abnormal service node is determined.
[0030] A microservice node identification device, the device comprising:
[0031] Building modules for building finite state graphs of microservices based on trace logs;
[0032] The identification module is used to compare the differences between adjacent finite state graphs and identify abnormal service nodes.
[0033] In one embodiment, the device further comprises:
[0034] A generating module is used to generate security warning information according to the abnormal service node.
[0035] In one of the embodiments, the adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
[0036] In one embodiment, the identification module is specifically used for:
[0037] The differences between adjacent finite state graphs are compared to determine a newly added microservice node, and when the newly added microservice node is stable, the newly added microservice node is determined as an abnormal service node.
[0038] In one of the embodiments, the abnormal service nodes include shadow service nodes and unknown service nodes.
[0039] In one embodiment, the device further comprises:
[0040] The first determination module is used to determine that the newly added microservice node is stable when the number of requests and / or responses of the newly added microservice node is higher than a preset threshold.
[0041] In one embodiment, the building block is specifically used for:
[0042] Collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data;
[0043] And in the request and / or response data of each microservice node of the tracking chain data, the request and / or response except the final request and / or response data is deleted to obtain the target tracking chain data;
[0044] A finite state graph of the microservice is constructed based on the target tracking chain data.
[0045] In one embodiment, the building block is specifically used for:
[0046] For each of the target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order, and if the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node;
[0047] If the call relationship identifier of any of the service call pairs does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1;
[0048] If any calling relationship identifier of the service calling pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service calling pair is incremented by 1.
[0049] In one of the embodiments, the abnormal service node includes a calling abnormal service node, and the device further includes:
[0050] The second determination module is used to, for any of the microservice nodes in the finite state diagram, use the microservice node as the call abnormal service node when the microservice node is not the newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold.
[0051] In one embodiment, the device further comprises:
[0052] A third determination module is used to determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node;
[0053] The fourth determination module is used to determine the attack dimension corresponding to the abnormal service node according to the node type of the microservice node called by the abnormal service node.
[0054] A communication device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:
[0055] Build a finite state graph of microservices based on tracking logs;
[0056] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0057] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the following steps:
[0058] Build a finite state graph of microservices based on tracking logs;
[0059] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0060] A chip, the chip including a programmable logic circuit and / or a program instruction, when the chip is running, can execute the microservice node identification method provided in the embodiment of the present application, the method can be:
[0061] Build a finite state graph of microservices based on tracking logs;
[0062] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0063] A computer program product includes a computer program, wherein when the computer program is executed by a processor, the microservice node identification method provided in the embodiment of the present application is implemented, and the method can be:
[0064] Build a finite state graph of microservices based on tracking logs;
[0065] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0066] The above-mentioned microservice node identification method, device, communication device, storage medium, chip and computer program product construct a finite state graph of microservices based on tracking logs; compare the differences between adjacent finite state graphs to identify abnormal service nodes. By adopting this method, it is possible to identify abnormal service nodes among multiple microservice nodes based on multiple tracking logs, and then determine the possible attack surface in the microservice system based on the call relationship of the abnormal service node, which can improve the security of the microservice system. BRIEF DESCRIPTION OF THE DRAWINGS
[0067] Figure 1 A schematic diagram of a process of identifying a microservice node in an embodiment;
[0068] Figure 2 is a schematic diagram of adjacent finite state graphs in one embodiment;
[0069] Figure 3 A schematic diagram of a process for obtaining target tracking chain data in one embodiment;
[0070] Figure 4 A schematic diagram of a call relationship between microservice nodes in a tracking chain data in an embodiment;
[0071] Figure 5 A schematic diagram of target tracking chain data corresponding to tracking chain data in one embodiment;
[0072] Figure 6 A schematic diagram of a process of constructing a finite state diagram in one embodiment;
[0073] Figure 7 is a schematic diagram of a finite state graph of the k-1th round in one embodiment;
[0074] Figure 8 is a schematic diagram of a k-th round finite state graph in one embodiment;
[0075] Fig. 9 is a schematic diagram of a finite state diagram of an abnormal service node in one embodiment;
[0076] Fig.10 A schematic diagram of a process for determining an attack dimension corresponding to an abnormal service node in an embodiment;
[0077] Fig.11 FIG. 4 is a structural block diagram of a microservice node identification device in an embodiment. DETAILED DESCRIPTION
[0078] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0079] It should be noted that the beneficial effects brought about by the embodiments of the present application or the technical problems solved are not limited to this one, but may also include other implicit or related problems. For details, please refer to the description of the following embodiments.
[0080] In a microservice architecture system, tracking service requests becomes a critical task due to the cross-service call characteristics. The current industry mainstream adopts distributed call chain tracking technology to generate a unique trace ID (Identity document) in the log for each request. The trace ID will be passed on every request / call of the microservice, output related logs, and finally use the log collection tool to aggregate the local logs to the platform to query the complete service call chain of each request.
[0081] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.
[0082] In one embodiment, Figure 1 As shown, a microservice node identification method is provided. This embodiment uses the method applied to a server as an example. It can be understood that the method can also be applied to a terminal, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. Among them, the terminal communicates with the server through a network. Among them, the terminal can be but is not limited to various personal computers, laptops, smart phones, tablet computers, etc. The server can be implemented as an independent server or a server cluster consisting of multiple servers.
[0083] In this embodiment, the method includes the following steps:
[0084] Step 102: construct a finite state graph of the microservice based on the tracking log.
[0085] Among them, the tracking log generates a unique tracking (Trace) ID (Identity document, unique identifier) in the log for each request in the system of the microservice architecture through distributed call chain tracking technology. The tracking ID will be transmitted at each request / call of the service, and the tracking log corresponding to the unique tracking ID will be output. Each tracking log can be aggregated to the platform through the log collection tool. The server can query the complete service call chain of each request on the platform. The finite state diagram is used to characterize whether the operating state of the system of the microservice architecture is a stable state (i.e., steady state). The finite state diagram of each time window accurately maps the microservice nodes of the system that are stably running within the time window, and the behavioral states (call relationships) between the microservice nodes. The finite state diagram contains the identifiers of the microservice nodes and the call relationship identifiers of the service call pairs between the microservice nodes.
[0086] Among them, the microservice node that is running stably can be confirmed and marked as a service node / asset that is running normally. The embodiment of the present application does not specifically limit the method for obtaining each tracking log of the microservice system.
[0087] In the embodiment of the present application, the server uses a sliding time window to determine the time window corresponding to each tracking log based on the time when each tracking log of the microservice is generated.
[0088] Exemplarily, the server uses three natural days as a time window, January 1 to January 3 as time window 1, January 2 to January 4 as time window 2, January 3 to January 5 as time window 3, and uses the tracking logs generated from January 1 to January 3 as the tracking logs of time window 1, the tracking logs generated from January 2 to January 4 as the tracking logs of time window 2, and the tracking logs generated from January 3 to January 5 as the tracking logs of time window 3.
[0089] Then, the server constructs a finite state graph of the microservices in each time window based on the tracking logs in the time window.
[0090] Step 104: compare differences between adjacent finite state graphs to identify abnormal service nodes.
[0091] The differences between adjacent finite state graphs may include differences in microservice node identifiers and differences in attribute values of call relationship identifiers between microservice nodes.
[0092] In the embodiment of the present application, the server determines multiple adjacent finite state graphs according to the finite state graphs of multiple time windows. Exemplarily, the adjacent finite state graphs may be the finite state graph of time window 1 and the finite state graph of time window 2.
[0093] Then, the server determines the difference between the microservice node identifiers of adjacent finite state graphs and the difference between the attribute values of the call relationship identifiers between the microservice nodes.
[0094] In the above-mentioned microservice node identification method, a finite state graph of the microservice is constructed based on the tracking log; the differences of adjacent finite state graphs are compared to identify abnormal service nodes. By adopting this method, it is possible to identify abnormal service nodes among multiple microservice nodes based on multiple tracking logs, and then determine the possible attack surface in the microservice system based on the call relationship of the abnormal service node, which can improve the security of the microservice system.
[0095] In one embodiment, after step 102, the method further includes:
[0096] Generate security warning information based on abnormal service nodes.
[0097] Among them, abnormal service nodes include unknown service nodes, shadow service nodes and call abnormal service nodes. In a system with a microservice architecture, unknown service nodes and shadow service nodes are unknown service nodes whose sources cannot be known. In a system with a microservice architecture, the number of requests and / or responses of a microservice node is significantly lower or significantly higher than the preset threshold of the number of requests and / or responses of the microservice node.
[0098] In the embodiment of the present application, the server generates a security warning message including the identification of the abnormal service node according to the identification of the abnormal service node. For example, when the abnormal service node is microservice node A, the security warning message generated by the server is "microservice node A may be a shadow service node, please check".
[0099] Among them, the embodiments of the present application do not specifically limit the specific content of the security warning information.
[0100] In this embodiment, the server can generate security warning information containing the identification of the abnormal service node based on the identification of the abnormal service node, so that the technical personnel can know the abnormal service node existing within a certain time window, and locate the abnormality and check the security risks of the microservice system according to the time window where the abnormal service node is located, so as to facilitate the subsequent determination of the possible attack surface in the microservice system.
[0101] In one embodiment, the adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
[0102] In the embodiment of the present application, the server may obtain finite state graphs of multiple sliding time windows, wherein adjacent finite state graphs are the finite state graph of the t-1th time window and the finite state graph of the tth time window. Figure 2 As shown, the finite state graph of the time window T1 and the finite state graph of the time window T2 are adjacent finite state graphs.
[0103] It can be understood that since it is necessary to compare adjacent finite state graphs in order to determine the abnormal service node in a certain time window, when it is necessary to determine the abnormal service node in a certain time window, the finite state graph of the time window and the finite state graph of the previous time window of the time window should be taken, and the abnormal service node in the time window is determined by comparing the difference between the finite state graph of the time window and the finite state graph of the previous time window of the time window.
[0104] In this embodiment, since the server can obtain the finite state graphs of multiple sliding time windows, by comparing the finite state graph of the tth time window with the finite state graph of the t-1th time window, it is possible to determine the time when the abnormal service node in the tth time window is generated compared to the t-1th time window based on the time period corresponding to the tth time window and the time period corresponding to the t-1th time window.
[0105] For example, the time period corresponding to the t-th time window is from January 3 to January 6, and the time period corresponding to the t-1-th time window is from January 2 to January 5. The server can determine that the generation time of the abnormal service node in the t-th time window is January 6. This achieves the effect of tracing the generation time of the abnormal service node, making it easier for subsequent technicians to locate the abnormalities and troubleshoot security risks of the microservice system based on the generation time of the abnormal service node, and determine the possible attack surface in the microservice system.
[0106] In one embodiment, step 104 includes:
[0107] The differences between adjacent finite state graphs are compared to determine the newly added microservice nodes, and when the newly added microservice nodes are stable, the newly added microservice nodes are determined as abnormal service nodes.
[0108] In an embodiment of the present application, the server compares the differences between adjacent finite state graphs. Specifically, the server compares the finite state graph of time window t and the finite state graph of time window t-1 to determine whether there is a difference in microservice nodes.
[0109] Exemplarily, the server determines that the identifier of a microservice node exists in the finite state graph of time window t and does not exist in the finite state graph of time window t-1, then the server determines that the microservice node is a new microservice node in the time period corresponding to time window t.
[0110] The server determines whether the calling relationship of the newly added microservice node is stable. If the calling relationship of the newly added microservice node is stable, the server regards the newly added microservice node as an abnormal service node.
[0111] It is understandable that the appearance of a new microservice node in a certain time window can indicate that the microservice node is not within the management scope of the microservice architecture system. If the new microservice node can provide stable services, it can indicate that a microservice node that is not within the management scope is providing stable services, that is, the microservice node has generated stable requests and / or responses with other microservice nodes many times. In this case, the server determines that the microservice node is an unknown service node or a shadow service node within the time window.
[0112] In this embodiment, the server can promptly discover the abnormal behavior of the newly added microservice node, and when the calling relationship of the newly added microservice node is stable, determine that the newly added microservice node is an unknown service node or a shadow service node, thereby achieving the effect of detecting unknown service nodes or shadow service nodes in the microservice system.
[0113] In one embodiment, abnormal service nodes include shadow service nodes and unknown service nodes.
[0114] In one embodiment, the method further includes:
[0115] When the number of requests and / or responses of the newly added microservice node is higher than a preset threshold, it is determined that the newly added microservice node is stable.
[0116] The number of requests and / or responses of the microservice node being higher than a preset threshold indicates that the microservice node provides stable services, that is, the microservice node is stable.
[0117] In an embodiment of the present application, the server may obtain the number of requests and / or responses of the newly added microservice node, and determine whether the number of requests and / or responses of the newly added microservice node is higher than a preset threshold. When the number of requests and / or responses of the newly added microservice node is higher than the preset threshold, the server determines that the newly added microservice node is stable.
[0118] The preset threshold may be determined by a technician in actual application, or may be obtained by weighted averaging the number of requests and / or responses of each microservice node of the server based on multiple time windows.
[0119] It is understandable that, since each microservice node may be used to implement different functions in the system, the stable call of each microservice node may correspond to different numbers of requests and / or responses, and therefore, each microservice node has a corresponding preset threshold. The specific method for obtaining the preset threshold is not limited in the embodiment of the present application.
[0120] In this embodiment, the server can determine whether the microservice node is stable according to a preset threshold, so that the subsequent server can determine the abnormal service node according to whether the newly added microservice node is stable.
[0121] In one embodiment, Figure 3 As shown, step 102 includes:
[0122] Step 302: collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data.
[0123] Among them, abnormal data refers to the data of request and / or response failure of each microservice node in the tracking chain data.
[0124] In an embodiment of the present application, the server collects tracking logs of microservices (systems with microservice architecture), determines the request and / or response data of each microservice node in the tracking log for each tracking log, and determines the request and / or response data of each microservice node in the tracking log as the tracking chain data of the tracking log.
[0125] Since the call chain tracking data will mark the response status code (status_code) of the request service response failure or abnormal data as error in the call chain tracking data, the server can determine the data with the response status code marked as error in the tracking chain data as abnormal data in the tracking chain data.
[0126] The server deletes the abnormal data in each tracking chain data.
[0127] Step 304: Delete the requests and / or responses except the final request and / or response data from the request and / or response data of each microservice node in the tracking chain data to obtain the target tracking chain data.
[0128] In the embodiment of the present application, after deleting the abnormal data in the tracking chain data, the server determines the number of calls between any two microservice nodes in the tracking chain data for any tracking chain data.
[0129] For example, refer to Figure 4 As shown, in a tracking chain data, there is one request and response t0 between microservice node S0 and microservice node S1, that is, the number of calls between microservice node S0 and microservice node S1 is 1; there are three requests and responses between microservice node S1 and microservice node S2, which are t1, t2 and t3 respectively, that is, the number of calls between microservice node S1 and microservice node S2 is 3.
[0130] The server determines the generation time of the request and / or response data between any two microservice nodes in the tracking chain data, retains the request and / or response data with the latest generation time, and deletes other request and / or response data, so that in the tracking chain data, only one request and / or response data is retained between any two microservice nodes, and the target tracking chain data corresponding to the tracking chain data is obtained.
[0131] For example, refer to Figure 5As shown, in a tracking chain data, there are three requests and / or responses between microservice node S1 and microservice node S2, namely t1, t2 and t3, and when the generation time of request and / or response data t3 is the latest, the server retains the request and / or response data t3, deletes the request and / or response data t1 and t2, and obtains the target tracking chain data corresponding to the tracking chain data.
[0132] Step 306: construct a finite state graph of the microservice based on the target tracking chain data.
[0133] In an embodiment of the present application, the server constructs a finite state graph of the microservice according to the identifier of each microservice node in the multiple target tracking chain data and the request and / or response data of each microservice node.
[0134] In this embodiment, the server can perform data preprocessing on each tracking chain data to obtain target tracking chain data, which is convenient for subsequently constructing a finite state graph of the microservice according to the target tracking chain data.
[0135] In one embodiment, Figure 6 As shown, step 102 includes:
[0136] Step 602: for each target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order. If the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node.
[0137] A service call pair includes two microservice nodes and request and / or response data between the two microservice nodes.
[0138] In the embodiment of the present application, for each target tracking chain data, the server traverses each service call pair (i.e., request and / or response) of the target tracking chain data in order from early to late according to the generation time of each service call pair (i.e., request and / or response) of the target tracking chain data. If the identifier of any microservice node in any service call pair does not exist in the finite state graph, the server creates the identifier of the microservice node in the finite state graph until the identifiers of the microservice nodes in all target tracking chain data are created.
[0139] Step 604: If the call relationship identifier of any service call pair does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1.
[0140] The call relationship identifier of the service call pair is the edge of the service call pair. The call relationship identifier of the service call pair can refer to Figure 7As shown, the curve between S0 and S1 is the call relationship identifier of the service call pair from microservice node S0 to microservice node S1 (that is, the edge of the service call pair).
[0141] In the embodiment of the present application, the server determines whether the call relationship identifiers of the service call pairs of each target tracking chain data exist in the finite state graph. If the call relationship identifier of any service call pair does not exist in the finite state graph, the server creates a call relationship identifier for the service call pair and sets the attribute value of the call relationship identifier of the service call pair to 1. Until the call relationship identifiers of the service call pairs in all target tracking chain data exist in the finite state graph.
[0142] Step 606: If there is a call relationship identifier of any service call pair in the finite state diagram, the attribute value of the call relationship identifier of the service call pair is incremented by 1.
[0143] In an embodiment of the present application, when the server has call relationship identifiers of all service call pairs in the target tracking chain data in the finite state graph, for each target tracking chain data, it determines whether there are call relationship identifiers of each service call pair in the target tracking chain data in the finite state graph. If there is a call relationship identifier of any service call pair in the target tracking chain data in the finite state graph, the attribute value of the call relationship identifier of the service call pair is incremented by 1.
[0144] Specifically, for the method of constructing a finite state graph of microservices, refer to Figure 7 and Figure 8 As shown, Figure 7 is the k-1th round finite state graph, Figure 8 For the k-th round finite state diagram, please refer to the following steps:
[0145] Step 5061: The server obtains an initial finite state graph.
[0146] Among them, since the finite state graph has not started to be constructed according to the target tracking chain data, the initial finite state graph does not contain the identifier of any microservice node and the call relationship identifier of any service call pair.
[0147] Step 5062: The server determines the processing rounds for constructing the finite state graph according to the number of target tracking chain data in the target time window t.
[0148] Exemplarily, when the number of target tracking chain data is 10, the server determines that the number of processing rounds for constructing the finite state graph is 10 rounds.
[0149] Step 5063: During the k-th round of processing, the server updates the k-1-th round of finite state graph according to the identifiers of each microservice node and each service call pair in the k-th target tracking chain data to obtain the k-th round of finite state graph.
[0150] Step 50631, the server determines the microservice nodes and service call pairs included in the k-th target tracking chain data, and determines whether the identifiers of the microservice nodes in the k-th target tracking chain data exist in the k-1-th round finite state graph.
[0151] Step 50632: When the server does not have the identifier of any microservice node in the kth target tracking chain data in the k-1th round finite state graph, the server creates the identifier of the microservice node in the k-1th round finite state graph.
[0152] Step 50633, when the server has the identifiers of all microservice nodes corresponding to the k-th target tracking chain data in the k-1-th round finite state graph, it determines whether there is a call relationship identifier of the service call pair of the k-th target tracking chain data in the k-1-th round finite state graph.
[0153] Step 50634, when there is a call relationship identifier of any service call pair of the k-th target tracking chain data in the k-1-th round finite state diagram, the server increments the attribute value of the call relationship identifier of the service call pair in the k-1-th round finite state diagram by 1.
[0154] Step 50635, when the call relationship identifier of any service call pair of the k-th target tracking chain data does not exist in the k-1 round finite state diagram, the server creates a call relationship identifier of the service call pair in the k-1 round finite state diagram, and sets the attribute value of the call relationship identifier to 1, completing the k-th round of processing and obtaining the k-th round finite state diagram.
[0155] Step 5064, after completing the processing of the kth target tracking chain data, when k is less than the number of target tracking chain data, enter the k+1th round of processing until k is equal to the number of target tracking chain data, and complete the construction of the finite state graph of the target time window t; wherein k is a positive integer, and when k is 1, the k-1th round of finite state graph is the initial finite state graph.
[0156] Among them, refer to Fig. 9 As shown, the microservice node S is an abnormal service node.
[0157] In this embodiment, the server can create a finite state graph of the microservice based on multiple target tracking chain data and the number of target tracking chain data, so that the subsequent server can determine the state of each microservice node in the current time window according to the finite state graph of the microservice, and then determine the abnormal service node, thereby realizing the detection of abnormal service nodes of the microservice.
[0158] In one embodiment, the abnormal service node includes calling an abnormal service node, and the method further includes:
[0159] For any microservice node in the finite state diagram, when the microservice node is not a newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to a preset threshold, the microservice node is regarded as a call abnormal service node.
[0160] In the embodiment of the present application, for any microservice node in the finite state graph, the server can determine that the microservice node is a microservice node within the management scope when the microservice node is not a newly added microservice node.
[0161] The server determines whether the number of requests and / or responses of the microservice node is greater than a preset threshold. When the number of requests and / or responses of the microservice node is greater than the preset threshold, the server determines that the microservice node is a microservice node that normally provides stable services.
[0162] When the number of requests and / or responses of the microservice node is less than or equal to a preset threshold, the server can determine that the microservice node fails to provide stable services, and the server uses the microservice node as a call abnormal service node.
[0163] In this embodiment, the server can determine whether the microservice node is a call abnormal node when the microservice node is not a newly added microservice node, so that the technician can determine the problem existing in the microservice system according to the security alarm information corresponding to the call abnormal node.
[0164] In one embodiment, Fig.10 As shown, the above method also includes:
[0165] Step 1002: Determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node.
[0166] In an embodiment of the present application, the abnormal service node is an unknown service node or a shadow service node. The server can determine the microservice node called by the abnormal service node based on the identification of the abnormal service node and the calling relationship between the abnormal service node and each microservice node (i.e., the request and / or response data of the abnormal service node) in the finite state diagram of the current time window.
[0167] For example, refer to Fig. 9 As shown, in the finite state diagram of the current time window, the server determines that the microservice node called by the abnormal service node is microservice node S4 according to the identifier S of the abnormal service node.
[0168] Step 1004: Determine the attack dimension corresponding to the abnormal service node according to the node type of the microservice node called by the abnormal service node.
[0169] Among them, the node types of microservice nodes include internal microservice nodes and external microservice nodes; internal microservice nodes are microservice nodes related to the internal functions of the system of the microservice structure, and the internal functions may include but are not limited to payment functions, asset access functions and other functions; external microservice nodes are microservice nodes related to the external functions of the system of the microservice structure, and the external functions may include but are not limited to message notification functions and other functions. The attack dimension includes internal attacks and external attacks, which are used to characterize the possible attack surface.
[0170] Since unknown service nodes and shadow service nodes are abnormal service nodes that are not within the management scope, they may be abnormal service nodes accessed by the attacker, and the attacker may attack the microservice system based on the abnormal service nodes.
[0171] In an embodiment of the present application, the server can determine the attack dimension corresponding to the abnormal service node according to the node type of the microservice node called by the abnormal service node.
[0172] Specifically, when the node type of the microservice node called by the abnormal service node is an internal microservice node, the server determines that the attack dimension corresponding to the unknown service node or the shadow service node is an internal attack; when the node type of the microservice node called by the abnormal service node is an external microservice node, the server determines that the attack dimension corresponding to the unknown service node or the shadow service node is an external attack.
[0173] The server generates a security warning message according to the type of abnormal service node, the attack dimension of the abnormal service node and the node identifier of the abnormal service node. For example, the security warning message may be "microservice node A may be a shadow service node, involving internal attacks, please check".
[0174] Among them, the embodiments of the present application do not specifically limit the specific content of the security warning information.
[0175] In this embodiment, the server can determine the attack surface existing in the microservice system based on the microservice nodes called by the shadow service nodes and the abnormal service nodes, which facilitates subsequent technical personnel to perform security detection and maintenance on the microservice system, thereby improving the security of the microservice system.
[0176] It should be understood that although Figure 1-10 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 1-10 At least part of the steps may include multiple steps or multiple stages. These steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed in turn or alternately with other steps or at least part of the steps or stages in other steps.
[0177] In one embodiment, Fig.11 As shown, a microservice node identification device 1100 is provided, including: a construction module 1102 and an identification module 1104, wherein:
[0178] The construction module 1102 is used to construct a finite state graph of the microservice based on the tracking log.
[0179] The identification module 1104 is used to compare the differences between adjacent finite state graphs and identify abnormal service nodes.
[0180] The microservice node identification device provided by the embodiment of the present disclosure is used to construct a finite state graph of microservices based on tracking logs; and to compare the differences between adjacent finite state graphs to identify abnormal service nodes. The abnormal service node can be identified from multiple microservice nodes based on multiple tracking logs, and then the possible attack surface in the microservice system can be determined based on the call relationship of the abnormal service node, which can improve the security of the microservice system.
[0181] In one embodiment, the apparatus further comprises:
[0182] A generating module is used to generate security warning information according to the abnormal service node.
[0183] In one embodiment, the adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
[0184] In one embodiment, the identification module 1104 is specifically used for:
[0185] The differences between adjacent finite state graphs are compared to determine a newly added microservice node, and when the newly added microservice node is stable, the newly added microservice node is determined as an abnormal service node.
[0186] In one embodiment, the abnormal service nodes include shadow service nodes and unknown service nodes.
[0187] In one embodiment, the apparatus further comprises:
[0188] The first determination module is used to determine that the newly added microservice node is stable when the number of requests and / or responses of the newly added microservice node is higher than a preset threshold.
[0189] In one embodiment, the construction module 1102 is specifically used to:
[0190] Collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data;
[0191] And in the request and / or response data of each microservice node of the tracking chain data, the request and / or response except the final request and / or response data is deleted to obtain the target tracking chain data;
[0192] A finite state graph of the microservice is constructed based on the target tracking chain data.
[0193] In one embodiment, the construction module 1102 is specifically used to:
[0194] For each of the target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order, and if the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node;
[0195] If the call relationship identifier of any of the service call pairs does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1;
[0196] If any calling relationship identifier of the service calling pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service calling pair is incremented by 1.
[0197] In one embodiment, the abnormal service node includes a calling abnormal service node, and the device further includes:
[0198] The second determination module is used to, for any of the microservice nodes in the finite state diagram, use the microservice node as the call abnormal service node when the microservice node is not the newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold.
[0199] In one embodiment, the apparatus further comprises:
[0200] A third determination module is used to determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node;
[0201] The fourth determination module is used to determine the attack dimension corresponding to the abnormal service node according to the node type of the microservice node called by the abnormal service node.
[0202] For the specific definition of the microservice node identification device, please refer to the definition of the microservice node identification method above, which will not be repeated here. Each module in the above-mentioned microservice node identification device can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.
[0203] In one embodiment, a communication device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:
[0204] Build a finite state graph of microservices based on tracking logs;
[0205] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0206] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0207] Generate security warning information based on the abnormal service node.
[0208] In one embodiment, the adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
[0209] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0210] The differences between adjacent finite state graphs are compared to determine a newly added microservice node, and when the newly added microservice node is stable, the newly added microservice node is determined as an abnormal service node.
[0211] In one embodiment, the abnormal service nodes include shadow service nodes and unknown service nodes.
[0212] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0213] When the number of requests and / or responses of the newly added microservice node is higher than a preset threshold, it is determined that the newly added microservice node is stable.
[0214] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0215] Collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data;
[0216] And in the request and / or response data of each microservice node of the tracking chain data, the request and / or response except the final request and / or response data is deleted to obtain the target tracking chain data;
[0217] A finite state graph of the microservice is constructed based on the target tracking chain data.
[0218] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0219] For each of the target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order, and if the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node;
[0220] If the call relationship identifier of any of the service call pairs does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1;
[0221] If any calling relationship identifier of the service calling pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service calling pair is incremented by 1.
[0222] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0223] For any of the microservice nodes in the finite state diagram, when the microservice node is not the newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold, the microservice node is used as the call abnormal service node.
[0224] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:
[0225] Determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node;
[0226] According to the node type of the microservice node called by the abnormal service node, an attack dimension corresponding to the abnormal service node is determined.
[0227] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:
[0228] Build a finite state graph of microservices based on tracking logs;
[0229] The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
[0230] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0231] Generate security warning information based on the abnormal service node.
[0232] In one embodiment, the adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
[0233] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0234] The differences between adjacent finite state graphs are compared to determine a newly added microservice node, and when the newly added microservice node is stable, the newly added microservice node is determined as an abnormal service node.
[0235] In one embodiment, the abnormal service nodes include shadow service nodes and unknown service nodes.
[0236] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0237] When the number of requests and / or responses of the newly added microservice node is higher than a preset threshold, it is determined that the newly added microservice node is stable.
[0238] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0239] Collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data;
[0240] And in the request and / or response data of each microservice node of the tracking chain data, the request and / or response except the final request and / or response data is deleted to obtain the target tracking chain data;
[0241] A finite state graph of the microservice is constructed based on the target tracking chain data.
[0242] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0243] For each of the target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order, and if the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node;
[0244] If the call relationship identifier of any of the service call pairs does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1;
[0245] If any calling relationship identifier of the service calling pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service calling pair is incremented by 1.
[0246] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0247] For any of the microservice nodes in the finite state diagram, when the microservice node is not the newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold, the microservice node is used as the call abnormal service node.
[0248] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:
[0249] Determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node;
[0250] According to the node type of the microservice node called by the abnormal service node, an attack dimension corresponding to the abnormal service node is determined.
[0251] An embodiment of the present application further provides a chip, which includes a programmable logic circuit and / or program instructions, and when the chip is running, it can execute the steps in the above-mentioned method embodiments.
[0252] The embodiments of the present application also provide a computer program product including instructions, which, when executed on a computer, enables the computer to execute the steps in the above-mentioned method embodiments.
[0253] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).
[0254] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0255] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.
Claims
1. A microservice node identification method, characterized in that: The method comprises: Build a finite state graph of microservices based on tracking logs; The differences between adjacent finite state graphs are compared to identify abnormal service nodes.
2. The method according to claim 1, characterized in that After the abnormal service node is identified, the method further includes: Generate security warning information based on the abnormal service node.
3. The method according to claim 1, characterized in that The adjacent finite state graphs include a finite state graph of a t-1th time window and a finite state graph of a tth time window.
4. The method according to any one of claims 1 to 3, characterized in that: The comparing differences between adjacent finite state graphs to identify abnormal service nodes includes: The differences between adjacent finite state graphs are compared to determine a newly added microservice node, and when the newly added microservice node is stable, the newly added microservice node is determined as an abnormal service node.
5. The method according to claim 4, characterized in that The abnormal service nodes include shadow service nodes and unknown service nodes.
6. The method according to claim 4, characterized in that The comparing the differences between the adjacent finite state graphs to determine the newly added microservice node, and determining the newly added microservice node as an abnormal service node when the newly added microservice node is stable, further includes: When the number of requests and / or responses of the newly added microservice node is higher than a preset threshold, it is determined that the newly added microservice node is stable.
7. The method according to claim 1, characterized in that The finite state graph of microservices is constructed based on the tracking log, including: Collect the tracking logs of the microservices, determine the tracking chain data of the tracking logs, and delete the abnormal data in the tracking chain data; And in the request and / or response data of each microservice node of the tracking chain data, the request and / or response except the final request and / or response data is deleted to obtain the target tracking chain data; A finite state graph of the microservice is constructed based on the target tracking chain data.
8. The method according to claim 7, characterized in that The step of constructing a finite state graph of a microservice according to the target tracking chain data includes: For each of the target tracking chain data, traverse each service call pair of the target tracking chain data in chronological order, and if the identifier of any microservice node does not exist in the finite state graph, create the identifier of the microservice node; If the call relationship identifier of any of the service call pairs does not exist in the finite state diagram, create a call relationship identifier of the service call pair, and set the attribute value of the call relationship identifier of the service call pair to 1; If any calling relationship identifier of the service calling pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service calling pair is incremented by 1.
9. The method according to claim 4, characterized in that The abnormal service node includes calling an abnormal service node, and the method further includes: For any of the microservice nodes in the finite state diagram, when the microservice node is not the newly added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold, the microservice node is used as the call abnormal service node.
10. The method according to claim 1, characterized in that The method further comprises: Determine the microservice node called by the abnormal service node according to the calling relationship between the abnormal service node and each microservice node; According to the node type of the microservice node called by the abnormal service node, an attack dimension corresponding to the abnormal service node is determined.
11. A microservice node identification device, characterized in that: The device comprises: Building modules for building finite state graphs of microservices based on trace logs; The determination module is used to compare the differences between adjacent finite state graphs and identify abnormal service nodes.
12. A communication device, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 10 are implemented.
13. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.
14. A chip, characterized in that: The chip comprises a programmable logic circuit and / or program instructions, and the steps of the method according to any one of claims 1 to 10 are implemented when the chip is executed.
15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.
Citation Information
Patent Citations
Wireless city data sharing method and system based on SAAS application
CN110661780A
Microservice abnormal root cause positioning method and device
CN115333921A
Micro-service full-link tracking method, device and system and medium
CN115629940A
Log sampling method, related device and system
CN115994072A
Controlling data communication between microservices
US20200162380A1