A Micro-service Architecture Internal Threat Audit Method Based on Regular Behavior Trees

Abstract

The present invention discloses a method for auditing internal threats in a microservices architecture based on a regular behavior tree, belonging to the technical field of microservices architecture security. Aiming at the existing microservices architecture that mostly adopts security protection technologies at the interaction boundary between users and application systems and cannot meet the security protection requirements of the microservices architecture under internal threats, a scheme for auditing internal threats in the microservices architecture is disclosed. This scheme proposes a behavior specification represented by a regular behavior tree for the inter-service call behavior in the microservices architecture, uses the service call link tracing technology to trace the inter-service call behavior tree, and can judge whether there are internal threats inside the microservices architecture through the audit of the inter-service call behavior. This audit scheme makes up for the existing microservices security protection technology and improves the security protection ability of the microservices architecture in the internal threat scenario.

Description

Technical Field

[0001] The present invention belongs to the technical field of microservice architecture security, and particularly relates to a method for auditing internal threats in a microservice architecture based on a regular behavior tree. Background Art

[0002] With the development of Internet technology and the increasing complexity of Internet application systems, the microservice architecture has currently been widely used in the development and deployment of large enterprise business application systems. Compared with the monolithic architecture used in traditional Internet application system development, the microservice architecture is decoupled in the development architecture and is more suitable for the development, deployment, and maintenance of large Internet applications. The microservice architecture transfers the complexity of the application system from within the business logic to the call dependencies between services. It splits the entire application system into a large number of independently developed and deployed services. The internal logic of each service is simple and easy to develop. Each service exposes one or more interfaces for other services or users to call. Services communicate through a computer network, and the services cooperate to provide users with complete business functions. Although the microservice architecture greatly improves the efficiency of application system development, the characteristic of decentralized internal services brings new security risks to the application system. Under the monolithic architecture, the main defense is against the attack behavior of external malicious users on the application system, and it is generally difficult for attackers to intervene in the communication between internal functional modules of the monolithic architecture application system. In the current microservice architecture, the security protection of the application system still focuses on the security threats from external users to the application system, and generally implements security protection at the boundary of the application system. However, within the microservice architecture, services usually trust each other. Once an attacker obtains a certain service node and tampers with its business logic, the attacker can further attack other service nodes through this service node, ultimately threatening or causing losses to the entire application system. The existing security defense technologies against external attacks by malicious users in the microservice architecture cannot meet the new security requirements for defending internal threats in the microservice architecture. Therefore, how to resist internal threats is an important issue faced in the microservice architecture. Summary of the Invention

[0003] In response to the internal threat security requirements in the microservice architecture and in order to identify abnormal call behaviors between services, the present invention proposes a method for auditing internal threats in a microservice architecture based on a regular behavior tree.

[0004] The technical solution adopted by the present invention is a method for auditing internal threats in a microservice architecture based on a regular behavior tree, and its features are as follows:

[0005] This method first analyzes the service source code corresponding to all service call interfaces in the application system to construct a regular behavior tree, then deploys a link tracing log governance system during the operation of the application system, then obtains the call behavior tree by tracing the link tracing logs, and finally matches the constructed call behavior tree with the regular behavior tree to verify whether the call behavior tree is an abnormal behavior.

[0006] The micro-service architecture internal threat auditing method based on the regular behavior tree includes three modules: a regular behavior tree construction module, a call behavior tree tracing module, and a behavior tree regular matching module, as well as the interaction implementation between the modules. The specific steps are as follows:

[0007] Step 1: The regular behavior tree construction module defines the normal call behavior specification for the call behavior between services in the micro-service architecture. When the service is developed and deployed online, this module defines regular nodes for each service interface based on the analysis of the service source code. The regular nodes describe the regular specifications that the service process's call sequence of other service interfaces should meet, including four basic sequences: empty sequence, sequential sequence, loop sequence, and exclusive sequence, and are stored with the service name as the keyword. The regular nodes define the sub-service nodes and their call sequence regular specifications for each service node, and construct a regular behavior tree reflecting the normal operation of the application system from top to bottom. The regular behavior tree constructed by this module is stored in the database as the call behavior matching template in Step 3 and is retrieved and used by the behavior tree regular matching module in Step 3.

[0008] Step 2: The call behavior tree tracing module extracts the call situation of service nodes and traces to obtain the actual call behavior tree composed of the service call link during the dynamic operation of the micro-service architecture. The call behavior tree describes the call relationship between services under a complete business oriented to users and is an ordered tree. During the operation of the application system, this module first records the call information of all service processes in the micro-service architecture by deploying a log governance system with link tracing function, and then obtains the specific call behavior between services by scraping the log information. In this module, the information of each service process being called is collected, and the call behavior tree is constructed from bottom to top by the tracing method. For each service process node, the sequence of its downward calls to other services is constructed. The call behavior tree constructed by this module is passed to the behavior tree regular matching module as the matching object in Step 3 to determine whether the current call behavior tree is a normal behavior in Step 3.

[0009] Step 3: The Behavior Tree Regular Matching Module receives the constructed call behavior tree from Step 2 and completes the verification of the call behavior tree in this module to identify abnormal call behaviors. In this module, traverse each behavior node in the call behavior tree. The behavior node contains the specific call sequence for calling the underlying service. For each call sequence, query the corresponding regular node according to its service name, match the current node with the regular node, and obtain the detection result of the current behavior tree. Since each service may provide multiple interfaces and the regular nodes are extracted by service name, the above matching process may match multiple regular nodes. If the result of multiple matches is successful at least once, it is considered that the current node is successfully matched. When the traversal of all nodes in the call behavior tree is completed, if all nodes have been matched, it indicates that the current call behavior tree is normal; otherwise, the current call behavior is an abnormal behavior, and there may be malicious service nodes with internal threats. Alarms need to be sent to these service instances, and further manual investigation of specific malicious nodes is required.

[0010] Compared with the existing security technologies for microservice architecture, the present invention has the following advantages:

[0011] Firstly, in terms of the threat model, the existing security technologies mainly prevent malicious users from attacking the microservice architecture application system from the external network, while the present invention believes that attackers may launch attacks on the application system from the internal service nodes of the microservice architecture by tampering with deployed service instances, narrowing the trust domain of the microservice architecture. Secondly, in terms of behavior modeling, a tree structure based on chained calls is adopted to model the complex call behaviors in the microservice architecture. Finally, in terms of the auditing method, the matching technology of regular expressions is introduced to standardize the sequence relationship of service nodes calling other services, and the call behaviors between services are restricted according to program characteristics. The present invention makes a supplement to the existing security technologies in the auditing stage of the microservice architecture, narrows the security defense boundary of the microservice architecture, refines the security protection granularity of the microservice architecture, meets stronger security requirements, and effectively guarantees higher security of the microservice architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 Deployment topology diagram of the internal threat auditing method for microservice architecture.

[0013] Figure 2 Architecture diagram of the internal threat auditing method for microservice architecture.

[0014] Figure 3 Example diagram of regular behavior tree and call behavior tree taking the book list query service as an example. DETAILED IMPLEMENTATION MANNER

[0015] The present invention will be further described in conjunction with the accompanying drawings and specific implementation manners.

[0016] Figure 1 This is the topology diagram for the specific deployment of this method. The three modules of this method are deployed in the behavior modeling server and the behavior auditing server. The regular behavior tree construction module is included in the behavior modeling server, and the call behavior tree tracing module and the behavior tree regular matching module are included in the behavior auditing server. The specific process of the internal threat auditing solution invented by this method is as follows:

[0017] Step 1: Analyze the service source code and construct regular behavior nodes.

[0018] Step 1.1: When each service is deployed online after coding, analyze the corresponding source code of each interface provided by the service for constructing regular behavior nodes next. When analyzing the service source code, first locate the commands in the code that call the interfaces of other services, and then determine the logical relationships of the code context. The relationships of the call commands in the code logic mainly include three types: sequential logic, loop logic, and branch logic.

[0019] Step 1.2: The three logical relationships of the call commands in the above service source code can determine the request sequence for the service process to call other services. The corresponding request sequences include four basic sequences: sequential sequence, loop sequence, branch sequence, and empty sequence. And the basic sequences can be combined and nested according to the source code relationships. These sequence patterns can be represented by the corresponding rules of regular expressions, and these regular expressions are recorded with the service name as the keyword to obtain regular nodes.

[0020] Step 2: Store the regular behavior tree. The obtained regular nodes are recorded with the service name as the keyword, and the regular sequences in the regular nodes use the service name as the matching element. Each regular node is stored in the database with the service name as the keyword. The regular sequences in the regular nodes point to the child nodes of the node, forming a regular behavior tree constructed from top to bottom. The regular behavior tree is a static behavior tree, which is constructed when the service is deployed online and updated when the service is updated.

[0021] Step 3: Collect service - to - service call logs. Deploy a log governance system with link - tracing capabilities in the microservices architecture to record the call behavior of services when they are invoked in the application system. Link - tracing technology can pass tracing information from top to bottom in the service call chain. When each service process is invoked, the log governance system assigns an identification ID (SpanID) to the currently started service process, and passes down tracing information from the upper - layer service: the current link identification ID (Trace ID) and the identification ID of the upper - layer service process (ParentID). In a service process, the above - mentioned SpanID, TraceID, ParentID, the current service name (ServiceName), and process time information are recorded. In particular, the TraceID of the root service node of the service call is the same as its SpanID and the ParentID is empty.

[0022] Step 4: Store service - to - service call logs. The log governance system stores the logs containing the above - mentioned SpanID, TraceID, ParentID, ServiceName, and service process time information in the log server, and these data will be used for tracing the call behavior tree in Step 5.

[0023] Step 5: Fetch logs and trace the call behavior tree.

[0024] Step 5.1: The audit server regularly fetches the log information stored by the log governance system from the log database, extracts the corresponding service name, SpanID, TraceID, ParentID, service name, and process time information of each service process, and constructs these information into node objects of the call behavior tree.

[0025] Step 5.2: Group the above - fetched log information objects by TraceID, that is, service processes with the same TraceID are nodes in the same call behavior tree. Steps 5.3 and 5.4 are executed in each TraceID group.

[0026] Step 5.3: Initialize an empty call sequence for each node.

[0027] Step 5.4: Traverse all behavior nodes except the root node, trace up to its parent node according to the ParentID, and insert the current service name into the call sequence of the parent node in chronological order. Finally, the sequence of each service process node invoking the lower - layer service interface is obtained.

[0028] Step 5.5: Steps 5.3 and 5.4 construct the call behavior tree corresponding to the TraceID by tracing up, and this call behavior tree is used as the matching object in Step 6.

[0029] Step 6: Extract regular nodes to match the call behavior sequence. Traverse all the behavior nodes of the call behavior tree obtained in Step 5. For each behavior node, extract the corresponding regular node from the regular behavior tree stored in Step 2 according to its service name, and match the call sequence in the behavior node with the regular sequence in the extracted regular node. If there is a regular sequence that matches the call sequence successfully, the current behavior node is normal; otherwise, the current behavior node is abnormal. If there is an abnormal behavior node in a certain call behavior tree, the service corresponding to the abnormal behavior node in that call behavior tree should be taken offline, an alarm should be issued to other services in the call behavior tree, and further manual auditing should be carried out.

[0030] Figure 2 This is the architecture diagram of the internal threat auditing scheme for the microservice architecture to which the present invention belongs. Three modules, namely, a regular behavior tree construction module, a call behavior tree tracing module, and a behavior tree regular matching module, are added on the basis of the microservice architecture application system. The specific steps are as follows:

[0031] Step 1: First, the regular behavior tree construction module extracts waiter code from the microservice architecture application system, then analyzes the business code corresponding to each service interface to obtain call regular sequences, then constructs regular nodes from the regular sequences of the same service, and finally stores all the regular nodes with the service name as the keyword to obtain the regular behavior tree.

[0032] Step 2: First, deploy a log governance system with link tracing function in the microservice architecture, then capture link tracing logs, and then construct call behavior nodes by tracing the call behavior between services, and finally obtain a complete call behavior tree.

[0033] Step 3: After the behavior tree regular matching module obtains the call behavior tree in Step 2, first traverse the behavior nodes and extract the call behavior sequence, then for each call behavior node, extract the regular node of the regular behavior tree in Step 1 according to its service name, and finally match the call behavior sequence with the regular sequence to obtain the audit result of the current node

[0034] Figure 3 This is a specific example of the regular behavior tree and the call behavior tree described in the present invention. Taking the service of a user querying the list of borrowed books in a library management system as an example, the figure describes the regular behavior tree corresponding to this business and the call behavior tree extracted during the service execution process. The specific steps are as follows:

[0035] Step 1: By analyzing the call relationship of services in the relevant business logic code, four services, namely, the book list query service, the user service, the borrowing service, and the book service, can be obtained and the corresponding regular behavior tree can be constructed. The regular behavior tree is represented in a top-down form.

[0036] Step 1.1: The book list query service is the root service called by the user. When the user calls this service, it provides the user's borrowing book list for the user, including one borrowing user information and several book information. If the user has no borrowing record, the book list is empty. In this service, the user service and the borrowing service are called in sequence, and the regular sequence can be obtained as (user service)(borrowing service), that is, the call behavior sequence of the book list query service must strictly start with the user service and the borrowing service, otherwise the matching fails.

[0037] Step 1.2: The user service is called by the book list query service to provide user information for the book list query service. The user service does not call other service interfaces, so its regular sequence is empty, that is, this service cannot call other services, otherwise the matching fails.

[0038] Step 1.3: The borrowing service is called by the book list query service to provide the list of book information borrowed by the user to the book list query service. This service calls the book service in a loop, so its regular sequence is (book service)*, that is, this service can call the book service any number of times. If this service calls any other service except the book service, the matching fails.

[0039] Step 1.4: The book service is called by the borrowing service to provide specific book information for the borrowing service. This service does not call other services, so its regular sequence is empty, that is, this service cannot call other services, otherwise the matching fails.

[0040] Step 2: Through tracing, the call behavior tree as shown in the figure can be obtained. The nodes of the call behavior tree are service processes, which are represented in a bottom-up form.

[0041] Step 2.1: The user service is called once, and its parent node is the book list query service. Through tracing, the call sequence of the user service is empty, which matches the regular sequence in Step 1.2 successfully.

[0042] Step 2.2: The book service is called multiple times, and its parent node is the borrowing service. Through tracing, the call sequence of each book service is empty, which matches the regular sequence in Step 1.4 successfully.

[0043] Step 2.3: The borrowing service is called once, and its parent node is the book list query service. Through tracing, the call sequence of the borrowing service is multiple book services, which matches the regular sequence in Step 1.3 successfully.

[0044] Step 2.4: The book list query service is called once, and this node is the root node. Through tracing, the call sequence of the book list query service is (user service)(borrowing service), which matches the regular sequence in Step 1.1 successfully.

[0045] Step 3: Match the call behavior tree in Step 2 with the regular behavior tree in Step 1 to obtain the audit result: The call behavior tree in Step 2 is successfully matched and is a normal behavior tree.

Claims

1. A method for auditing internal threats in a microservices architecture based on a regular behavior tree, characterized in that, It is implemented by three modules, namely the regular behavior tree construction module, the call behavior tree tracing module, and the behavior tree regular matching module, as well as the data interaction between the modules. The steps are as follows: Step 1: The regular behavior tree construction module analyzes the service source code deployed in the microservice architecture, and constructs a call behavior regular sequence based on the relative logic of the commands for calling other services in the source code; the call regular sequences corresponding to all interfaces provided in each service constitute the regular behavior nodes of the service, and the regular nodes of all services are constructed in a top-down manner to obtain the regular behavior tree of the application system; The regular behavior tree constructed in this module is stored in the database and extracted by the behavior tree regular matching module in Step 3, which is the audit specification for normal call behaviors; Step 2: The call behavior tree tracing module periodically captures the link tracing logs during the operation of the microservice architecture, traces upward along the call link with the service process as the node, and sorts the call sequences of each behavior node according to the log time information to finally obtain the call behavior tree; The call behavior tree traced in this module is passed to the behavior tree regular matching module in Step 3 to determine whether the current behavior is an abnormal behavior; Step 3: The behavior tree regular matching module receives the call behavior tree traced in Step 2 and matches it with the regular behavior tree constructed in Step 1 to verify whether the call behavior tree is a normal behavior tree, that is, to audit whether there is an internal threat.

2. The method for auditing internal threats in a microservices architecture based on a regular behavior tree according to claim 1, wherein, Step 3.1: Traverse all nodes in the call behavior tree and execute Steps 3.2 to 3.3; Step 3.2: Extract the regular behavior node corresponding to the service name of the current call behavior node in the regular behavior tree constructed in Step 1, and the regular behavior sequence in the regular behavior node is used as the normal behavior matching template; Step 3.3: Match the call sequence in the current call behavior node with the regular behavior sequence extracted in Step 3.

1. If there is a regular behavior sequence that matches the current call sequence successfully, the current call behavior node is a normal behavior node; otherwise, the current behavior node is an abnormal behavior node; Step 3.4: When all nodes in the current call behavior tree have been traversed and all behavior nodes are normal behavior nodes, it is considered that the current call behavior tree is a normal behavior tree; otherwise, the current behavior tree is an abnormal behavior tree; If the call behavior tree is an abnormal behavior tree, the audit result is that there is an internal threat. Alarms are sent to all service instances in the abnormal behavior tree, and the service instances corresponding to the abnormal behavior nodes should be taken offline as soon as possible.

Images