Micro-service node identification method and apparatus, communication device, and storage medium

By constructing a finite state graph of microservices and comparing adjacent differences, abnormal service nodes are identified, solving the problem of attack surface detection in cloud-native microservice architecture and improving the system's security and attack surface identification capabilities.

CN119483989BActive Publication Date: 2025-12-12CHINA TELECOM CORP LTD TECHNOLOGY INNOVATION CENTER +1
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202311011078.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-08-10
Publication Date
2025-12-12
Estimated Expiration
2043-08-10

AI Technical Summary

Technical Problem

The lack of effective technical solutions for detecting the attack surface in cloud-native microservice architectures leads to an expansion of the attack surface, making it difficult to identify and prevent potential security threats.

Method used

By constructing a finite state graph of microservices based on tracing logs, comparing the differences between adjacent finite state graphs, identifying abnormal service nodes, generating security alerts, and detecting potential attack surfaces in the microservice system.

Benefits of technology

It enables the identification of abnormal service nodes and the determination of attack surfaces in microservice systems, thereby improving the security of microservice systems and timely detecting abnormal behavior of unknown or shadow service nodes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119483989B_ABST
    Figure CN119483989B_ABST
Patent Text Reader

Abstract

The application relates to a micro-service node identification method and device, communication equipment, a storage medium, a chip and a computer program product. The method comprises the following steps: constructing a finite state diagram of a micro-service based on a tracking log; and comparing the differences between adjacent finite state diagrams to identify an abnormal service node. According to the method, the abnormal service node can be identified in multiple micro-service nodes according to multiple tracking logs, and then the attack surface possibly existing in the micro-service system can be determined according to the calling relationship of the abnormal service node, so that the security of the micro-service system can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security, and in particular to a micro-service node identification method and device, a communication device, a storage medium, a chip and a computer program product. BACKGROUND

[0002] With the development of cloud native technology, a micro-service architecture appears, and the cloud native micro-service architecture can split a single application into a group of independent services, each of which has processing logic and communicates with each other through API (Application Programming Interface).

[0003] In the cloud native micro-service architecture, each micro-service can be independently deployed to realize rapid iteration and flexible expansion, and the advantages of the cloud native micro-service architecture are elasticity and agility. Therefore, under the cloud environment, the cloud native micro-service architecture gradually becomes the mainstream cloud native DevOps (combination of development and operation) architecture.

[0004] However, the micro-service architecture, in addition to the advantages of elasticity and agility, also brings a sharp expansion of the attack surface. The independent deployment of each service means an increase in potential attack vectors, and the frequent communication between services can also be used by attackers as an attack path. In the existing scheme, there is still no technical solution to detect the attack surface in the cloud native micro-service architecture. SUMMARY

[0005] The embodiments of the present application provide a micro-service node identification method, device, communication device, storage medium, chip and computer program product, which can detect possible attack surfaces in a micro-service system and improve the security of the micro-service system.

[0006] A micro-service node identification method, the method comprising:

[0007] Based on the tracking log, a finite state diagram of the micro-service is constructed;

[0008] The differences between adjacent finite state diagrams are compared to identify abnormal service nodes.

[0009] In one of the embodiments, after the abnormal service nodes are identified, the method further comprises:

[0010] According to the abnormal service nodes, security alarm information is generated.

[0011] In one of the embodiments, the adjacent finite state diagrams include a finite state diagram of a t-1 time window and a finite state diagram of a t time window.

[0012] In one embodiment, comparing the differences between adjacent finite state graphs to identify anomalous service nodes includes:

[0013] By comparing the differences between adjacent finite state graphs, new microservice nodes are identified, and if the new microservice nodes are stable, they are identified as abnormal service nodes.

[0014] In one embodiment, the abnormal service node includes a shadow service node and an unknown service node.

[0015] In one embodiment, the step of comparing the differences between adjacent finite state graphs to determine the newly added microservice node, and identifying the newly added microservice node as an abnormal service node if the newly added microservice node is stable, further includes:

[0016] When the number of requests and / or responses to the newly added microservice node exceeds a preset threshold, the newly added microservice node is determined to be stable.

[0017] In one embodiment, constructing a finite state graph of the microservices based on tracing logs includes:

[0018] Collect trace logs from microservices, determine the trace chain data of the trace logs, and delete abnormal data in the trace chain data;

[0019] In the request and / or response data of each microservice node in the tracing chain data, requests and / or responses other than the final request and / or response data are deleted to obtain the target tracing chain data;

[0020] Based on the target tracing chain data, construct a finite state graph for the microservice.

[0021] In one embodiment, constructing a finite state graph of the microservice based on the target tracing chain data includes:

[0022] For each target tracing chain data, traverse each service call pair of the target tracing chain data in chronological order. If there is no identifier for any microservice node in the finite state graph, then create the identifier for the microservice node.

[0023] If there is no call relationship identifier for any of the service call pairs in the finite state diagram, create a call relationship identifier for the service call pairs and set the attribute value of the call relationship identifier for the service call pairs to 1;

[0024] If any of the service call pairs has a call relationship identifier in the finite state graph, the attribute value of the call relationship identifier of the service call pair is incremented by 1.

[0025] In one of the embodiments, the abnormal service node comprises a calling abnormal service node, and the method further comprises:

[0026] For any of the microservice nodes in the finite state diagram, when the microservice node is not the new 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 taken as the calling abnormal service node.

[0027] In one of the embodiments, the method further comprises:

[0028] According to the calling relationship between the abnormal service node and each microservice node, the microservice node called by the abnormal service node is determined.

[0029] According to the node type of the microservice node called by the abnormal service node, the attack dimension corresponding to the abnormal service node is determined.

[0030] A microservice node identification device, the device comprises:

[0031] A construction module configured to construct a finite state diagram of a microservice based on a tracking log.

[0032] An identification module configured to compare the difference between adjacent finite state diagrams to identify an abnormal service node.

[0033] In one of the embodiments, the device further comprises:

[0034] A generation module configured to generate security alert information according to the abnormal service node.

[0035] In one of the embodiments, the adjacent finite state diagrams comprise a finite state diagram of a (t-1)th time window and a finite state diagram of a (t)th time window.

[0036] In one of the embodiments, the identification module is specifically configured to:

[0037] Compare the difference between adjacent finite state diagrams to determine a new microservice node, and determine the new microservice node as an abnormal service node when the new microservice node is stable.

[0038] In one of the embodiments, the abnormal service node comprises a shadow service node and an unknown service node.

[0039] In one of the embodiments, the device further comprises:

[0040] The first determining module is configured to determine that the added micro-service node is stable when the number of requests and / or responses of the added micro-service node is higher than a preset threshold.

[0041] In one of the embodiments, the constructing module is specifically configured to:

[0042] collecting trace logs of the micro-service, and determining trace chain data of the trace logs, and deleting abnormal data in the trace chain data;

[0043] and deleting, in the request and / or response data of each micro-service node of the trace chain data, requests and / or responses other than the final request and / or response data, to obtain target trace chain data;

[0044] constructing a finite state diagram of the micro-service according to the target trace chain data.

[0045] In one of the embodiments, the constructing module is specifically configured to:

[0046] for each target trace chain data, traversing each service call pair of the target trace chain data in time sequence, and if there is no identifier of any micro-service node in the finite state diagram, creating the identifier of the micro-service node;

[0047] if there is no call relationship identifier of any service call pair in the finite state diagram, creating the call relationship identifier of the service call pair, and setting the attribute value of the call relationship identifier of the service call pair to 1;

[0048] if there is any call relationship identifier of the service call pair in the finite state diagram, incrementing the attribute value of the call relationship identifier of the service call pair by 1.

[0049] In one of the embodiments, the abnormal service node includes an abnormal calling service node, and the device further includes:

[0050] The second determining module is configured to, for any micro-service node in the finite state diagram, take the micro-service node as the abnormal calling service node when the micro-service node is not the added micro-service node, and the number of requests and / or responses of the micro-service node is less than or equal to the preset threshold.

[0051] In one of the embodiments, the device further includes:

[0052] The third determining module is configured to determine the micro-service node called by the abnormal service node according to the call relationship between the abnormal service node and each micro-service node.

[0053] A fourth determining module is configured to determine an attack dimension corresponding to the abnormal service node according to a node type of the micro-service node called by the abnormal service node.

[0054] A communication device comprises a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0055] Based on the tracking log, a finite state diagram of the micro-service is constructed;

[0056] The differences between adjacent finite state diagrams are compared to identify an abnormal service node.

[0057] A computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the following steps:

[0058] Based on the tracking log, a finite state diagram of the micro-service is constructed;

[0059] The differences between adjacent finite state diagrams are compared to identify an abnormal service node.

[0060] A chip comprises programmable logic circuit and / or program instructions, and when the chip is running, it can execute the micro-service node identification method provided by the embodiments of the present application, which can be:

[0061] Based on the tracking log, a finite state diagram of the micro-service is constructed;

[0062] The differences between adjacent finite state diagrams are compared to identify an abnormal service node.

[0063] A computer program product comprises a computer program, characterized in that the computer program is executed by a processor to implement the micro-service node identification method provided by the embodiments of the present application, which can be:

[0064] Based on the tracking log, a finite state diagram of the micro-service is constructed;

[0065] The differences between adjacent finite state diagrams are compared to identify an abnormal service node.

[0066] The above micro-service node identification method, device, communication device, storage medium, chip and computer program product are based on the tracking log, and a finite state diagram of the micro-service is constructed; the differences between adjacent finite state diagrams are compared to identify an abnormal service node. By using the method, the abnormal service node can be identified in multiple micro-service nodes according to multiple tracking logs, and then the attack surface that may exist in the micro-service system can be determined according to the calling relationship of the abnormal service node, and the security of the micro-service system can be improved. BRIEF DESCRIPTION OF DRAWINGS

[0067] Figure 1 A flowchart of a method for identifying microservice nodes in an embodiment;

[0068] Figure 2 A schematic diagram of adjacent finite state diagrams in an embodiment;

[0069] Figure 3 A flowchart of a method for obtaining target tracking chain data in an embodiment;

[0070] Figure 4 A schematic diagram of the calling 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 a tracking chain data in an embodiment;

[0072] Figure 6 A flowchart of a method for constructing a finite state diagram in an embodiment;

[0073] Figure 7 A schematic diagram of a finite state diagram in the k-1th round in an embodiment;

[0074] Figure 8 A schematic diagram of a finite state diagram in the kth round in an embodiment;

[0075] Figure 9 A schematic diagram of a finite state diagram in which there is an abnormal service node in an embodiment;

[0076] Figure 10 A flowchart of a method for determining the attack dimension corresponding to an abnormal service node in an embodiment;

[0077] Figure 11 A structural block diagram of a microservice node identification apparatus in an embodiment. DETAILED DESCRIPTION

[0078] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be 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.

[0079] It should be noted that the beneficial effects or technical problems solved by the embodiments of the present application are not limited to this, but also other implicit or related problems, which can be referred to the description of the following embodiments.

[0080] In a microservice architecture system, it is a key task to track service requests due to the cross-service calling feature. Currently, the mainstream of the industry adopts a distributed call chain tracking technology to generate a unique Trace Id (Identity document) for each request in a log. The Trace Id is passed in each request / call of the microservice, and relevant logs are output. Finally, a log collection tool is used to aggregate local logs to a platform to query the complete service call chain of each request.

[0081] The technical solutions of the present application and how the technical solutions solve the above technical problems will be 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 described again in some embodiments. The embodiments of the present application will be described below with reference to the accompanying drawings.

[0082] In one embodiment, as shown in Figure 1 A microservice node identification method is provided. In this embodiment, the method is applied to a server for illustration. It should 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 implemented through the interaction of the terminal and the server. The terminal communicates with the server through a network. The terminal can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, etc. The server can be implemented by a stand-alone server or a server cluster composed of multiple servers.

[0083] In this embodiment, the method includes the following steps:

[0084] Step 102, constructing a finite state diagram of the microservice based on the trace log.

[0085] The trace log is generated by the distributed call chain tracking technology for each request in the microservice architecture system. The Trace Id is passed in each request / call of the service, and the trace log corresponding to the unique Trace Id is output. Through the log collection tool, the trace logs can be aggregated to the platform. The server can query the complete service call chain of each request on the platform. The finite state diagram is used to represent whether the running state of the microservice architecture system is a stable state (i.e., steady state). The finite state diagram of each time window accurately maps the microservice nodes that run stably in the time window and the behavior state (calling relationship) between the microservice nodes. The finite state diagram includes the identification of the microservice nodes and the calling relationship identification of the service call pairs between the microservice nodes.

[0086] The micro-service node in stable operation can be marked as a normally operating service node / asset. The application embodiments do not limit the acquisition of the tracking logs of the micro-service system.

[0087] In the application embodiments, the server determines the time window corresponding to each tracking log by using a sliding time window based on the time when each tracking log of the micro-service is generated.

[0088] For example, the server takes three natural days as one time window, takes January 1 to January 3 as time window 1, takes January 2 to January 4 as time window 2, takes January 3 to January 5 as time window 3, takes the tracking logs generated from January 1 to January 3 as the tracking logs of time window 1, takes the tracking logs generated from January 2 to January 4 as the tracking logs of time window 2, and takes the tracking logs generated from January 3 to January 5 as the tracking logs of time window 3.

[0089] Then, the server constructs the finite state diagram of the micro-service in each time window based on the tracking logs in the time window.

[0090] In step 104, the differences between the adjacent finite state diagrams are compared to identify the abnormal service node.

[0091] The differences between the adjacent finite state diagrams can include the differences in the micro-service node identifiers and the differences in the attribute values of the call relationship identifiers between the micro-service nodes.

[0092] In the application embodiments, the server determines a plurality of adjacent finite state diagrams based on the finite state diagrams of a plurality of time windows. For example, the adjacent finite state diagrams can be the finite state diagram of time window 1 and the finite state diagram of time window 2.

[0093] Then, the server determines the differences in the micro-service node identifiers and the differences in the attribute values of the call relationship identifiers between the micro-service nodes of the adjacent finite state diagrams.

[0094] In the above micro-service node identification method, the finite state diagram of the micro-service is constructed based on the tracking logs, and the differences between the adjacent finite state diagrams are compared to identify the abnormal service node. According to the method, the abnormal service node can be identified in a plurality of micro-service nodes based on a plurality of tracking logs, and the attack surface that can exist in the micro-service system can be determined based on the call relationship of the abnormal service node, thereby improving the security of the micro-service system.

[0095] In one embodiment, after step 102, the method further includes:

[0096] According to the abnormal service node, security alarm information is generated.

[0097] The abnormal service node includes an unknown service node, a shadow service node, and a calling abnormal service node. The unknown service node and the shadow service node are unknown service nodes that cannot be known in a system of a microservice architecture. The calling abnormal service node is a microservice node whose request and / or response times are significantly lower or significantly higher than a preset threshold of the request and / or response times of the microservice node.

[0098] In the embodiment of the application, the server generates the security alarm information containing the identifier of the abnormal service node according to the identifier of the abnormal service node. For example, when the abnormal service node is the microservice node A, the security alarm information generated by the server is “microservice node A may be a shadow service node, please check”.

[0099] In the embodiment of the application, the specific content of the security alarm information is not limited.

[0100] In the embodiment, the server can generate the security alarm information containing the identifier of the abnormal service node based on the identifier of the abnormal service node, so that the technical personnel can know the abnormal service node existing in a time window, and perform abnormal positioning and security risk investigation of the microservice system according to the time window in which the abnormal service node is located, thereby facilitating the determination of the attack surface that may exist in the microservice system.

[0101] In one embodiment, the adjacent finite state diagrams include a finite state diagram of a t-1 time window and a finite state diagram of a t time window.

[0102] In the embodiment of the application, the server can obtain the finite state diagrams of a plurality of sliding time windows, wherein the adjacent finite state diagrams are the finite state diagram of the t-1 time window and the finite state diagram of the t time window. For example, as shown in FIG. 1, the finite state diagram of the time window T1 and the finite state diagram of the time window T2 are adjacent finite state diagrams. Figure 2

[0103] It can be understood that, since it is necessary to compare the adjacent finite state diagrams 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 diagram of the time window and the finite state diagram of the previous time window of the time window should be adopted, and the difference between the finite state diagram of the time window and the finite state diagram of the previous time window of the time window is compared to determine the abnormal service node in the time window.

[0104] ​In this embodiment, since the server can obtain the finite state diagram of multiple sliding time windows, by comparing the finite state diagram of the tth time window and the finite state diagram of the (t-1)th time window, the generation time of the abnormal service node in the tth time window compared with the (t-1)th time window can be determined according to the time period corresponding to the tth time window and the time period corresponding to the (t-1)th time window.

[0105] For example, the time period corresponding to the tth 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, and the server can determine that the generation time of the abnormal service node in the tth time window is January 6. Thus, the effect of tracing the generation time of the abnormal service node is achieved, which facilitates subsequent technical personnel to locate the abnormality of the microservice system and investigate the security risks according to the generation time of the abnormal service node, and determine the attack surface that may exist in the microservice system.

[0106] In one embodiment, step 104 comprises:

[0107] The difference between the adjacent finite state diagrams is compared to determine the newly added microservice node, and the newly added microservice node is determined as the abnormal service node when the newly added microservice node is stable.

[0108] In the embodiments of the present application, the server compares the difference between the adjacent finite state diagrams, specifically, the server compares the finite state diagram of the time window t with the finite state diagram of the time window t-1 to determine whether there is a difference in the microservice node.

[0109] For example, the server determines that the identifier of a certain microservice node exists in the finite state diagram of the time window t, and does not exist in the finite state diagram of the time window t-1, then the server determines that the microservice node is a newly added microservice node in the time period corresponding to the time window t.

[0110] The server determines whether the calling relationship of the newly added microservice node is stable, and the newly added microservice node is determined as the abnormal service node when the calling relationship of the newly added microservice node is stable.

[0111] It can be understood that the appearance of a newly added microservice node in a certain time window can represent that the microservice node is not within the management range of the microservice architecture system, and in the case that the newly added microservice node can provide stable services, it can represent that a microservice node not within the management range is providing stable services, i.e., the microservice node has generated stable requests and / or responses with other microservice nodes multiple times. In this case, the server determines that the microservice node is an unknown service node or a shadow service node in the time window.

[0112] In the embodiment, the server can discover abnormal behaviors of the newly added microservice node in time, and determine that the newly added microservice node is an unknown service node or a shadow service node when the calling relationship of the newly added microservice node is stable. The effect of detecting unknown service nodes or shadow service nodes in the microservice system is achieved.

[0113] In one embodiment, the abnormal service node includes a shadow service node and an unknown service node.

[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 the 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 higher than the preset threshold indicates that the microservice node provides stable service, that is, the microservice node is stable.

[0117] In the embodiment, the server can 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 the 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 can be determined by a technician in actual application, and can also be obtained by weighted average based on the number of requests and / or responses of each microservice node in multiple time windows.

[0119] It can be understood that since each microservice node can be used to implement different functions in the system, the stable calling condition of each microservice node can correspond to different numbers of requests and / or responses, and therefore each microservice node has a corresponding preset threshold. The specific acquisition method of the preset threshold is not limited in the embodiment.

[0120] In the embodiment, the server can determine whether the microservice node is stable according to the preset threshold, so as to facilitate the server to determine the abnormal service node according to whether the newly added microservice node is stable.

[0121] In one embodiment, as shown in Figure 3 , step 102 includes:

[0122] Step 302: Collecting the trace log of the microservice, determining the trace chain data of the trace log, and deleting the abnormal data in the trace chain data.

[0123] The abnormal data refers to the data of the request and / or response failure of each microservice node in the trace chain data.

[0124] In this embodiment of the application, the server collects trace logs of microservices (systems with microservice architecture), and for each trace log, determines the request and / or response data of each microservice node in the trace log, and determines the trace chain data of the trace log as the trace log trace chain data.

[0125] Because the call chain tracing data marks failed or abnormal service requests with a status code as "error," the server can identify data marked with an "error" status code in the tracing data as abnormal data.

[0126] For each tracking chain, the server deletes any abnormal data within that tracking chain.

[0127] Step 304: In the request and / or response data of each microservice node of the tracing chain data, delete the requests and / or responses except for the final request and / or response data to obtain the target tracing chain data.

[0128] In this embodiment of the application, after deleting 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 given tracking chain data.

[0129] For example, refer to Figure 4 As shown, in a trace chain of 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, namely t1, t2 and t3, that is, the number of calls between microservice node S1 and microservice node S2 is 3.

[0130] The server determines the generation time of request and / or response data between any two microservice nodes in the tracing chain data, retains the request and / or response data with the latest generation time, and deletes the other request and / or response data, so that only one request and / or response data is retained between any two microservice nodes in the tracing chain data, thus obtaining the target tracing chain data corresponding to the tracing chain data.

[0131] For example, refer to Figure 5As shown, in one tracking chain data, there are three requests and / or responses of microservice node S1 and microservice node S2, respectively, t1, t2 and t3, and the generation time of the 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] In step 306, a finite state diagram of the microservice is constructed according to the target tracking chain data.

[0133] In the embodiment of the application, the server constructs a finite state diagram of the microservice according to the identifier of each microservice node and the request and / or response data of each microservice node in the plurality of target tracking chain data.

[0134] In the embodiment, the server can perform data preprocessing on each tracking chain data to obtain the target tracking chain data, thereby facilitating subsequent construction of the finite state diagram of the microservice according to the target tracking chain data.

[0135] In one embodiment, as shown in Figure 6 Step 102 includes:

[0136] In step 602, for each target tracking chain data, each service call pair of the target tracking chain data is traversed in time sequence, and if the identifier of any microservice node does not exist in the finite state diagram, the identifier of the microservice node is created.

[0137] Each service call pair includes two microservice nodes and the request and / or response data between the two microservice nodes.

[0138] In the embodiment of the application, for each target tracking chain data, each service call pair (i.e., request and / or response) of the target tracking chain data is traversed in time sequence from early to late according to the generation time of each service call pair. If the identifier of any microservice node in any service call pair does not exist in the finite state diagram, the server creates the identifier of the microservice node in the finite state diagram, until the identifiers of the microservice nodes in all target tracking chain data are created.

[0139] In step 604, if the call relationship identifier of any service call pair does not exist in the finite state diagram, the call relationship identifier of the service call pair is created, and the attribute value of the call relationship identifier of the service call pair is set to 1.

[0140] The call relationship identifier of the service call pair is an edge of the service call pair, and the call relationship identifier of the service call pair can refer to Figure 7As shown, the curve between S0 and S1 is the invocation relationship identifier of the service invocation pair of the microservice node S0 and the microservice node S1 (i.e., the edge of the service invocation pair).

[0141] In the embodiment of the present application, the server determines, for each target trace chain data, whether the invocation relationship identifiers of the service invocation pairs of the target trace chain data all exist in the finite state graph. If any one of the invocation relationship identifiers of the service invocation pairs does not exist in the finite state graph, the server creates the invocation relationship identifier of the service invocation pair and sets the attribute value of the invocation relationship identifier of the service invocation pair to 1. Until all the invocation relationship identifiers of the service invocation pairs in the target trace chain data exist in the finite state graph.

[0142] In step 606, if any one of the invocation relationship identifiers of the service invocation pairs exists in the finite state graph, the server increments the attribute value of the invocation relationship identifier of the service invocation pair by 1.

[0143] In the embodiment of the present application, when the server determines that all the invocation relationship identifiers of the service invocation pairs in the target trace chain data exist in the finite state graph, the server determines, for each target trace chain data, whether the invocation relationship identifiers of the service invocation pairs in the target trace chain data exist in the finite state graph. In the case where any one of the invocation relationship identifiers of the service invocation pairs in the target trace chain data exists in the finite state graph, the server increments the attribute value of the invocation relationship identifier of the service invocation pair by 1.

[0144] Specifically, for the method of constructing the finite state graph of the microservice, refer to Figure 7 and Figure 8 As shown, Figure 7 is the (k-1)th round of the finite state graph, Figure 8 is the kth round of the finite state graph, which can refer to the following steps:

[0145] In step 5061, the server acquires an initial finite state graph.

[0146] Since the finite state graph is not started to be constructed according to the target trace chain data, the initial finite state graph does not contain the identifier of any microservice node and the invocation relationship identifier of any service invocation pair.

[0147] In step 5062, the server determines the processing round of constructing the finite state graph according to the number of the target trace chain data in the target time window t.

[0148] Exemplarily, in the case where the number of the target trace chain data is 10, the server determines that the processing round of constructing the finite state graph is 10 rounds.

[0149] Step 5063: During the processing of the kth round, the server updates the finite state graph of the (k-1)th round based on the identifiers of each microservice node and each service call pair in the data of the kth target tracing chain, and obtains the finite state graph of the kth round.

[0150] Step 50631: The server determines the microservice nodes and service call pairs included in the k-th target tracing chain data, and determines whether the identifiers of each microservice node in the k-th target tracing chain data exist in the (k-1)-th round finite state graph.

[0151] Step 50632: If the server does not have an identifier for any microservice node in the target tracing chain data in the (k-1)th round finite state graph, it creates an identifier for that microservice node in the (k-1)th round finite state graph.

[0152] Step 50633: When the server has the identifiers of all microservice nodes corresponding to the k-th target tracing chain data in the (k-1)-th round finite state graph, it determines whether there is a call relationship identifier for the service call pair of the k-th target tracing chain data in the (k-1)-th round finite state graph.

[0153] Step 50634: When the server has a call relationship identifier for any service call pair in the k-1 round finite state graph, it increments the attribute value of the call relationship identifier of that service call pair in the k-1 round finite state graph by 1.

[0154] Step 50635: In the (k-1)th round finite state graph, if the call relationship identifier of any service call pair of the kth target tracing chain data does not exist in the (k-1)th round finite state graph, the server creates the call relationship identifier of the service call pair in the (k-1)th round finite state graph and sets the attribute value of the call relationship identifier to 1, thus completing the kth round processing and obtaining the kth round finite state graph.

[0155] Step 5064: After processing the data of the kth target tracking chain, if k is less than the number of target tracking chain data, proceed to the (k+1)th round of processing until k equals the number of target tracking chain data, thus completing the construction of the finite state diagram of the target time window t; where k is a positive integer, and when k is 1, the finite state diagram of the (k-1)th round is the initial finite state diagram.

[0156] Among them, reference Figure 9 As shown, microservice node S is an abnormal service node.

[0157] In this embodiment, the server can create a finite state diagram of the microservice according to the plurality of target tracking chain data and the number of target tracking chain data, so as to facilitate the server to determine the state of each microservice node in the current time window according to the finite state diagram of the microservice, and further determine the abnormal service node, thereby realizing the detection of the abnormal service node of the microservice.

[0158] In one embodiment, the abnormal service node includes a calling 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 calling abnormal service node.

[0160] In this embodiment, the server can determine that the microservice node is a microservice node within the management range 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, and 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 regards the microservice node as a calling abnormal service node.

[0163] In this embodiment, the server can determine whether the microservice node is a calling abnormal node without being 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 calling abnormal node.

[0164] In one embodiment, as shown in Figure 10 the method further includes:

[0165] In step 1002, the microservice node called by the abnormal service node is determined according to the calling relationship between the abnormal service node and each microservice node.

[0166] In this embodiment, the abnormal service node is an unknown service node or a shadow service node, and the server can determine the microservice node called by the abnormal service node according to the identifier of the abnormal service node and the calling relationship (i.e., the request and / or response data of the abnormal service node) between the abnormal service node and each microservice node in the finite state diagram of the current time window.

[0167] Exemplarily, with reference to Figure 9 As shown in the figure, the server determines, according to the identification S of the abnormal service node, the micro service node called by the abnormal service node as the micro service node S4 in the finite state diagram of the current time window.

[0168] In step 1004, the attack dimension corresponding to the abnormal service node is determined according to the node type of the micro service node called by the abnormal service node.

[0169] The node type of the micro service node includes an internal micro service node and an external micro service node; the internal micro service node is a micro service node related to a system internal function of the micro service structure, and the internal function can include but is not limited to a payment function, an asset access function, and the like; the external micro service node is a micro service node related to a system external function of the micro service structure, and the external function can include but is not limited to a message notification function and the like. The attack dimension includes an internal attack and an external attack, and is used to represent a possible attack surface.

[0170] Since the unknown service node and the shadow service node are abnormal service nodes not within the management range, the unknown service node and the shadow service node can be abnormal service nodes accessed by an attacker, and the attacker can attack the micro service system according to the abnormal service node.

[0171] In the embodiment of the application, the server can determine the attack dimension corresponding to the abnormal service node according to the node type of the micro service node called by the abnormal service node.

[0172] Specifically, in the case where the node type of the micro service node called by the abnormal service node is an internal micro service node, the server determines that the attack dimension corresponding to the unknown service node or the shadow service node is an internal attack; in the case where the node type of the micro service node called by the abnormal service node is an external micro service 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 alarm information according to the type of the abnormal service node, the attack dimension of the abnormal service node, and the node identification of the abnormal service node. Exemplarily, the security alarm information can be "micro service node A can be a shadow service node, involving an internal attack, please check".

[0174] The specific content of the security alarm information is not limited in the embodiment of the application.

[0175] In the embodiment, the server can determine the attack surface existing in the micro service system according to the shadow service node and the micro service node called by the abnormal service node, facilitate the subsequent technical personnel to detect and maintain the security of the micro service system, and thus improve the security of the micro service system.

[0176] It should be understood that although Figures 1-10 The steps in the flowchart of FIG. 10 are not necessarily performed in the order indicated by the arrows. Unless specifically stated, the order of execution of the steps is not strictly limited, and the steps can be executed in other orders. Moreover, Figures 1-10 At least part of the steps in FIG. 10 can include multiple steps or multiple stages, which are not necessarily performed at the same time, but can be performed at different times, and the order of execution of the steps or stages is not necessarily sequential, but can be alternately or alternately executed with at least part of other steps or steps or stages in other steps.

[0177] In one embodiment, as shown in FIG. 11, a microservice node identification apparatus 1100 is provided, comprising a construction module 1102 and an identification module 1104, wherein: Figure 11 The construction module 1102 is configured to construct a finite state diagram of a microservice based on a trace log.

[0178] The identification module 1104 is configured to compare the differences between adjacent finite state diagrams to identify an abnormal service node.

[0179] The microservice node identification apparatus provided by the embodiments of the present disclosure can construct a finite state diagram of a microservice based on a trace log, compare the differences between adjacent finite state diagrams, and identify an abnormal service node. According to a plurality of trace logs, an abnormal service node can be identified in a plurality of microservice nodes, and then according to the call relationship of the abnormal service node, an attack surface that may exist in the microservice system can be determined, and the security of the microservice system can be improved.

[0180] In one embodiment, the apparatus further comprises:

[0181] The generation module is configured to generate security alarm information according to the abnormal service node.

[0182] In one embodiment, the adjacent finite state diagrams include a finite state diagram of a (t-1) th time window and a finite state diagram of a (t) th time window.

[0183] In one embodiment, the identification module 1104 is specifically configured to:

[0184] Compare the differences between adjacent finite state diagrams to determine a new microservice node, and in the case that the new microservice node is stable, determine the new microservice node as an abnormal service node.

[0185]

[0186] ​In an embodiment, the abnormal service node includes a shadow service node and an unknown service node.

[0187] In an embodiment, the apparatus further includes:

[0188] The first determining module is configured to determine that the newly added micro service node is stable when the number of requests and / or responses of the newly added micro service node is higher than a preset threshold.

[0189] In an embodiment, the constructing module 1102 is specifically configured to:

[0190] collect trace logs of micro services, and determine trace chain data of the trace logs, and delete abnormal data in the trace chain data;

[0191] and delete requests and / or responses except for final request and / or response data in request and / or response data of each micro service node of the trace chain data, to obtain target trace chain data;

[0192] construct a finite state diagram of micro services according to the target trace chain data.

[0193] In an embodiment, the constructing module 1102 is specifically configured to:

[0194] for each target trace chain data, traverse each service call pair of the target trace chain data in time sequence, and if an identifier of any micro service node does not exist in the finite state diagram, create the identifier of the micro service node;

[0195] if a call relationship identifier of any service call pair does not exist in the finite state diagram, create the call relationship identifier of the service call pair, and set an attribute value of the call relationship identifier of the service call pair to 1;

[0196] if the call relationship identifier of any service call pair exists in the finite state diagram, increment the attribute value of the call relationship identifier of the service call pair by 1.

[0197] In an embodiment, the abnormal service node includes a call abnormal service node, and the apparatus further includes:

[0198] The second determining module is configured to, for any micro service node in the finite state diagram, take the micro service node as the call abnormal service node when the micro service node is not the newly added micro service node, and the number of requests and / or responses of the micro service node is less than or equal to the preset threshold.

[0199] In an embodiment, the apparatus further includes:

[0200] a third determining module configured to determine a micro-service node called by the abnormal service node according to a calling relationship between the abnormal service node and each micro-service node;

[0201] a fourth determining module configured to determine an attack dimension corresponding to the abnormal service node according to a node type of the micro-service node called by the abnormal service node.

[0202] The specific limitations of the micro-service node identification apparatus can refer to the limitations of the micro-service node identification method described above, and will not be repeated here. Each module in the above micro-service node identification apparatus can be realized by software, hardware, and a combination thereof, in whole or in part. The above modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in the form of software, so as to call and execute the operations corresponding to each module by the processor.

[0203] In one embodiment, a communication device is provided, comprising a memory and a processor, the memory storing a computer program, and the processor implementing the following steps when executing the computer program:

[0204] constructing a finite state diagram of a micro-service based on the tracking log;

[0205] comparing the differences between adjacent finite state diagrams to identify an abnormal service node.

[0206] In one embodiment, the processor further implements the following steps when executing the computer program:

[0207] generating security alarm information according to the abnormal service node.

[0208] In one embodiment, the adjacent finite state diagrams include a finite state diagram of a t-1 time window and a finite state diagram of a t time window.

[0209] In one embodiment, the processor further implements the following steps when executing the computer program:

[0210] comparing the differences between adjacent finite state diagrams to determine a new micro-service node, and determining the new micro-service node as an abnormal service node in a case where the new micro-service node is stable.

[0211] In one embodiment, the abnormal service node includes a shadow service node and an unknown service node.

[0212] In one embodiment, the processor further implements the following steps when executing the computer program:

[0213] determining that the new micro-service node is stable when the number of requests and / or responses of the new micro-service node is higher than a preset threshold.

[0214] In one embodiment, the processor, when executing the computer program, also implements the following steps:

[0215] Collecting trace logs of microservices, and determining trace chain data of the trace logs, and deleting abnormal data in the trace chain data;

[0216] And in the request and / or response data of each microservice node of the trace chain data, deleting the request and / or response except the final request and / or response data to obtain target trace chain data;

[0217] According to the target trace chain data, constructing a finite state diagram of microservices.

[0218] In one embodiment, the processor, when executing the computer program, also implements the following steps:

[0219] For each target trace chain data, traversing each service call pair of the target trace chain data in time sequence, if the identity of any microservice node does not exist in the finite state diagram, creating the identity of the microservice node;

[0220] If the call relationship identity of any service call pair does not exist in the finite state diagram, creating the call relationship identity of the service call pair, and setting the attribute value of the call relationship identity of the service call pair to 1;

[0221] If the call relationship identity of any service call pair exists in the finite state diagram, incrementing the attribute value of the call relationship identity of the service call pair by 1.

[0222] In one embodiment, the processor, when executing the computer program, also implements the following steps:

[0223] For any microservice node in the finite state diagram, if 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, regarding the microservice node as the call abnormal service node.

[0224] In one embodiment, the processor, when executing the computer program, also implements the following steps:

[0225] According to the call relationship between the abnormal service node and each microservice node, determining the microservice node called by the abnormal service node;

[0226] According to the node type of the microservice node called by the abnormal service node, determining the attack dimension corresponding to the abnormal service node.

[0227] In one embodiment, a computer readable storage medium is provided, having stored thereon a computer program which, when executed by a processor, implements the following steps:

[0228] Based on the tracking logs, a limited state diagram of the microservice is constructed;

[0229] The differences between adjacent limited state diagrams are compared to identify an abnormal service node.

[0230] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0231] According to the abnormal service node, security alarm information is generated.

[0232] In one embodiment, the adjacent limited state diagrams include a limited state diagram of a t-1 time window and a limited state diagram of a t time window.

[0233] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0234] The differences between adjacent limited state diagrams are compared to determine a new microservice node, and in the case where the new microservice node is stable, the new microservice node is determined as an abnormal service node.

[0235] In one embodiment, the abnormal service node includes a shadow service node and an unknown service node.

[0236] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0237] When the number of requests and / or responses of the new microservice node is higher than a preset threshold, it is determined that the new microservice node is stable.

[0238] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0239] Tracking logs of microservices are collected, and tracking chain data of the tracking logs are determined, and abnormal data in the tracking chain data are deleted;

[0240] And in the request and / or response data of each microservice node of the tracking chain data, requests and / or responses other than the final request and / or response data are deleted to obtain target tracking chain data;

[0241] According to the target tracking chain data, a limited state diagram of the microservice is constructed.

[0242] In one embodiment, the computer program, when executed by the processor, further implements the following steps:

[0243] For each target tracking chain data, the target tracking chain data is traversed in time sequence for each service call pair, and if there is no identifier of any microservice node in the finite state diagram, the identifier of the microservice node is created;

[0244] If there is no calling relationship identifier of any service call pair in the finite state diagram, the calling relationship identifier of the service call pair is created, and the attribute value of the calling relationship identifier of the service call pair is set to 1.

[0245] If there is any calling relationship identifier of the service call pair in the finite state diagram, the attribute value of the calling relationship identifier of the service call pair is incremented by 1.

[0246] In one embodiment, the computer program is further implemented when executed by the processor to implement the following steps:

[0247] For any microservice node in the finite state diagram, if 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 taken as the calling abnormal service node.

[0248] In one embodiment, the computer program is further implemented when executed by the processor to implement the following steps:

[0249] According to the calling relationship between the abnormal service node and each microservice node, the microservice node called by the abnormal service node is determined.

[0250] According to the node type of the microservice node called by the abnormal service node, the attack dimension corresponding to the abnormal service node is determined.

[0251] Embodiments of the present application also provide a chip including a programmable logic circuit and / or program instructions, which can execute the steps in the above method embodiments when the chip is running.

[0252] Embodiments of the present application also provide a computer program product including instructions, which, when running on a computer, causes the computer to execute the steps in the above method embodiments.

[0253] Those skilled 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. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, storage, database or other medium used in the embodiments provided in the present 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. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0254] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, but as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0255] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent. It should be pointed out that for those skilled in the art, without departing from the concept of the present application, some modifications and improvements can be made, which are all within the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A method for identifying microservice nodes, characterized in that, The method comprises: constructing a finite state diagram of microservices based on a tracking log; comparing differences between adjacent finite state diagrams to identify an abnormal service node; wherein the constructing a finite state diagram of microservices based on a tracking log comprises: collecting tracking logs of microservices, determining tracking chain data of the tracking logs, deleting abnormal data in the tracking chain data, and deleting requests and / or responses other than final requests and / or responses in request and / or response data of each microservice node in the tracking chain data to obtain target tracking chain data; for each target tracking chain data, traversing each service call pair of the target tracking chain data in chronological order, creating an identifier of a microservice node if the identifier does not exist in a finite state diagram; if an invocation relationship identifier of any service call pair does not exist in the finite state diagram, creating the invocation relationship identifier of the service call pair and setting an attribute value of the invocation relationship identifier to 1; if the invocation relationship identifier of any service call pair exists in the finite state diagram, incrementing the attribute value of the invocation relationship identifier of the service call pair by 1; the comparing differences between adjacent finite state diagrams to identify an abnormal service node comprises: comparing differences between adjacent finite state diagrams, determining an added microservice node, and determining the added microservice node as an abnormal service node if the added microservice node is stable. The method further comprises:

2. The method of claim 1, wherein, generating security alert information according to the abnormal service node. The adjacent finite state diagrams comprise a finite state diagram of a t-1 time window and a finite state diagram of a t time window.

3. The method of claim 1, wherein, The abnormal service node comprises a shadow service node and an unknown service node.

4. The method of claim 1, wherein, The comparing differences between adjacent finite state diagrams to determine an added microservice node and determining the added microservice node as an abnormal service node if the added microservice node is stable further comprises:

5. The method of claim 1, wherein, determining that the added microservice node is stable if the number of requests and / or responses of the added microservice node is higher than a preset threshold. The abnormal service node comprises a call abnormal service node, and the method further comprises:

6. The method of claim 5, wherein, for any microservice node in the finite state diagram, if the microservice node is not the added microservice node and the number of requests and / or responses of the microservice node is less than or equal to the preset threshold, regarding the microservice node as the call abnormal service node. The method further comprises:

7. The method of claim 1, wherein, determining a microservice node called by the abnormal service node according to an invocation relationship between the abnormal service node and each microservice node; determining an attack dimension corresponding to the abnormal service node according to a node type of the microservice node called by the abnormal service node. The apparatus comprises: 8.A micro-service node identification apparatus, characterized by, a construction module configured to construct a finite state diagram of microservices based on a tracking log; a determination module configured to compare differences between adjacent finite state diagrams to identify an abnormal service node. ​ The construction module is specifically configured to collect tracking logs of micro services, determine tracking chain data of the tracking logs, and delete abnormal data in the tracking chain data. In addition, in the request and / or response data of each micro service node of the tracking chain data, the request and / or response data except the final request and / or response data are deleted to obtain target tracking chain data. For each target tracking chain data, each service call pair of the target tracking chain data is traversed in time sequence. If the identifier of any micro service node does not exist in the finite state diagram, the identifier of the micro service node is created. If the calling relationship identifier of any service call pair does not exist in the finite state diagram, the calling relationship identifier of the service call pair is created, and the attribute value of the calling relationship identifier of the service call pair is set to 1. If the calling relationship identifier of any service call pair exists in the finite state diagram, the attribute value of the calling relationship identifier of the service call pair is incremented by 1.

9. A communication device comprising a memory and a processor, the memory storing a computer program, characterized in that, The determination module is specifically configured to compare the differences between adjacent finite state diagrams, determine a newly added micro service node, and determine the newly added micro service node as an abnormal service node when the newly added micro service node is stable.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 7.

11. A chip, characterized by The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 7.

12. A computer program product comprising a computer program, characterized in that, The chip includes a programmable logic circuit and / or program instructions, and when the chip is running, the steps of the method in any one of claims 1 to 7 are implemented. The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 7.

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