Interface management method and related equipment
By drawing the interface call relationship diagram of the application and identifying boundaries, the API call security and traffic control challenges caused by the complexity of microservices in cloud applications are solved, and the application's security risk monitoring and traffic control are realized, providing a foundation for API governance.
Patent Information
- Application Number
- CN202410129034.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-11-02
- Filing Date
- 2024-01-30
- Publication Date
- 2025-05-06
AI Technical Summary
With the development of cloud applications, more and more microservices are available in applications, and API calls are becoming more and more complex, resulting in application-level API call traffic posing huge challenges to application security and traffic control. It is difficult for existing technology to effectively identify and manage interface calls with security risks.
Through the interface call records of multiple microservices, the interface call relationship diagram of the application in the running state is drawn, and the application boundaries are drawn based on the application's microservice registration information, and the interface calls that break through the application's boundaries are identified to realize the application's security risk monitoring and traffic control.
It realizes security risk monitoring and flow control of applications, ensures application security, and provides a foundation for API security governance and flow control governance.
Smart Images

Figure CN119938064A_ABST
Abstract
Description
[0001] This application claims the priority of the Chinese patent application filed with the State Intellectual Property Office on November 2, 2023, with application number 202311456090.0 and invention name “An interface management method and related equipment”, all contents of which are incorporated by reference in this application. Technical Field
[0002] The present application relates to the field of computer technology, and in particular to an interface management method, an application control system, a computing device cluster, a computer-readable storage medium, and a computer program product. Background Art
[0003] Application Programming Interface (API) refers to a series of special rules and requirements provided by programs to ensure mutual communication. With the continuous development of cloud applications, applications can not only provide open interfaces (open API) to other applications or users, but also provide APIs within the application so that different modules of the application can make API calls. For example, in an application based on a microservice architecture, microservices can also make calls through APIs.
[0004] As more and more microservices are added to an application, API calls become more and more complex. For example, API calls can include API calls between microservices of an application and API calls between applications. Among them, API calls between applications can also be divided into applications calling APIs outside the application, or external applications calling APIs within the application.
[0005] Application-level API call traffic poses great challenges to application security and traffic control. For example, API calls in the form of Elephant Flow can affect the normal operation of application services. The industry urgently needs to provide an interface management method to ensure application security or to effectively control application traffic. Summary of the invention
[0006] The present application provides an interface management method, which uses the interface call records of multiple microservices to draw an interface call relationship diagram of the application in the running state, and draws the boundary of the application in combination with the microservice registration information of the application, thereby identifying the interface calls that break through the boundary of the application, realizing the security risk monitoring of the application, ensuring the security of the application, and effectively controlling the flow of the application, providing a basis for the security governance and flow control governance of the API. The present application also provides an application control system, a computing device cluster, a computer-readable storage medium, and a computer program product corresponding to the above-mentioned interface management method.
[0007] In the first aspect, the present application provides an interface management method. The method can be executed by an application control system. The application control system is used to identify risks of interface calls to assist in security management and traffic management. The application control system can be a software system, which can be an independent software system, or integrated into other software systems in the form of plug-ins, functional modules, applets, etc. The software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system to execute the interface management method of the present application. In some examples, the application control system can also be a hardware system, such as a computing device cluster with an interface management function, which executes the interface management method of the present application when the computing device cluster is running.
[0008] Specifically, the application control system can obtain the interface call records of multiple microservices in the application, and the interface call records include the interface calls provided by the microservices to the internal application and / or the interface calls provided by the microservices to the external application. The application control system can draw the interface call relationship diagram of the application in the running state based on the interface call records of multiple microservices. Then, the application control system can draw the boundary of the application in the interface call relationship diagram based on the microservice registration information of the application. Among them, the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center. When there are interface calls that break through the boundaries of the application in the interface call records, the application control system displays the interface calls that have security risks to the user (such as abnormal calls, unreasonable API calls). Among them, the interface calls that have security risks include interface calls that break through the boundaries of the application.
[0009] This method aggregates application-level interface call records and uses them to draw application-level interface call relationships. It defines the application boundary in combination with the application's microservice registration information. In this way, it can identify unsafe application-level traffic (i.e., traffic with security risks), such as interface calls that break through the application boundary. The unsafe traffic is displayed in the form of a view. On the one hand, it can remind developers to rectify unreasonable interface call relationships. On the other hand, the identified interface calls can be used to monitor whether there are uncontrollable elephant flows, whether there are frequent mouse flows that can trigger denial of service, and whether there are externally exposed interfaces without access control. In this way, effective traffic control can be performed on the application, providing a basis for security governance and flow control governance of application interfaces.
[0010] In some possible implementations, the application may also include an application gateway. The application gateway is a middleware for managing and routing microservice requests. The application gateway acts as an entry point in the microservice architecture, for receiving requests from clients (e.g., other applications) and routing the requests to appropriate microservices. In specific implementations, the application control system may also obtain the interface call records of the application gateway, and the interface call records of the application gateway include the interface calls of the microservices inside the application by the application gateway. Accordingly, when drawing the interface call relationship diagram, the application control system may draw the interface call relationship diagram of the application in the running state according to the interface call records of multiple microservices and the interface call records of the application gateway. The application control system may draw the boundary of the application in the running state in the interface call relationship diagram according to the microservice registration information of the application and the registration information of the application gateway. Among them, the boundary of the application surrounds the microservices and the application gateway registered by the application in the registration center. The application control system may show the interface calls that break through the boundaries of the application and do not pass through the application gateway to the user.
[0011] For applications that include application gateways, the application gateway can also be regarded as a microservice. When drawing the interface call relationship diagram, it can also be drawn according to the interface call records of the application gateway. When drawing the boundary of the application, it can be drawn in combination with the microservice registration information of the application and the registration information of the application gateway. Based on the above interface call relationship diagram and boundary, interface calls that directly break through the boundary of the application without passing through the application gateway can be accurately identified, such as non-compliant calls from outside to inside or from inside to outside without passing through the application gateway, to provide assistance for application security governance or flow control governance.
[0012] In some possible implementations, the application control system can aggregate the interface call records of multiple microservices in the acquired application, and then analyze the aggregated interface call records to form a relational call record. Among them, the relational call record can be a record of the interface call relationship in the form of a relational data table. By performing the above processing on the interface call records, the application control system can reduce the difficulty of drawing the interface call relationship diagram and improve the drawing efficiency. Furthermore, when the application includes an application gateway, the application control system can aggregate the call records of the application gateway with the interface call records of the microservices, thereby drawing an interface call relationship diagram including the application gateway. In this way, a more comprehensive and accurate interface call relationship diagram can be drawn.
[0013] In some possible implementations, the application control system may also obtain static analysis results of the source code of the application, wherein the static analysis results include static call relationships of the microservices of the application. The application control system may analyze the interface call relationship graph and the static call relationship of the application in the running state, and obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship. Accordingly, interface calls with security risks include interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship.
[0014] The method analyzes the static call relationship obtained by static analysis of the application source code and the interface call relationship diagram of the application in the running state, for example, by performing a comparative analysis, thereby discovering unsafe interface calls that do not exist in the static call relationship but exist in the interface call relationship diagram in the running state, thereby providing richer information for the security management and flow control management of the application.
[0015] In some possible implementations, the application control system can also draw a static interface call relationship graph of the application based on the static call relationship of the application's microservices. Accordingly, the application control system can analyze the interface call relationship graph of the application in the running state and the interface call relationship graph of the application in the static state. Among them, the application control system can use a graph processing algorithm to analyze the interface call relationship graph of the application in the running state and the interface call relationship graph of the application in the static state, so as to quickly obtain abnormal calls that do not exist in the static call relationship but exist in the interface call relationship graph of the running state. This method combines dynamic and static analysis (dynamic analysis and static analysis) to identify interface calls with security risks in the application, thereby ensuring the security of the application.
[0016] In some possible implementations, the application control system can draw the static interface call relationship diagram of the application in the interface call relationship diagram of the application in the running state according to the static call relationship of the microservices of the application. Specifically, for any interface call relationship in the static call relationship, the application control system can check whether the interface call relationship diagram in the running state includes the edge corresponding to the interface call relationship. If so, reuse the edge; if not, draw the edge corresponding to the interface call relationship in the interface call relationship diagram in the running state. To facilitate distinction, the application control system can use different styles to draw the edges corresponding to the static call relationships.
[0017] This method can facilitate users to view abnormal or unreasonable interface calls by drawing a static interface call relationship diagram and a running interface call relationship diagram on the same relationship diagram, and provide a reference for developers to rectify unreasonable call relationships.
[0018] In some possible implementations, the application control system can also display the call information of the interface call to the user, and the call information includes at least one of the call source, call method, call path or call parameter. This method can provide developers with richer information to rectify unreasonable call relationships by displaying detailed information such as the call source, call method, call path or call parameter when displaying the interface call.
[0019] In some possible implementations, the application control system can also display interface calls that pose security risks to the user through a target style. The target style is different from the display style of compliant interface calls. The style may include at least one of the color, line type, or thickness of the edge that characterizes the interface call relationship. In specific implementations, the application control system can display compliant interface calls and non-compliant interface calls in different colors or different line types. For example, the boundary of an application can be displayed by a red dotted line, and accordingly, for interface calls that directly break through the boundary of an application without passing through an application gateway, the application control system can display the interface call to the user through a red line (for example, implemented in red), and for interface calls that pass through an application gateway or interface calls within an application, the application control system can display the interface call to the user through a green line.
[0020] By displaying interface calls with security risks in the above target style, users can quickly locate security risks and make targeted corrections, thereby improving the efficiency of application security governance or flow control governance and enhancing governance effectiveness.
[0021] In some possible implementations, the application control system can also send warning information to the user for interface calls that pose security risks. The warning information can be text information, voice information, or flashing indicator lights or buzzer vibrations. This method can proactively warn developers of interface calls that pose security risks, thereby reminding developers to promptly rectify interface calls that pose security risks and ensure the security and reliability of the application.
[0022] In a second aspect, the present application provides an application control system. The system comprises:
[0023] A record acquisition module, used to acquire interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservice to an interface provided inside the application and / or calls by the microservice to an interface provided outside the application;
[0024] A call relationship drawing module, used to draw an interface call relationship diagram of the application in a running state according to the interface call records of the multiple microservices;
[0025] A boundary drawing module, used to draw the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center;
[0026] The call relationship display module is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records, and the interface calls with security risks include interface calls that break through the boundaries of the application.
[0027] In some possible implementations, the application further includes an application gateway, and the record acquisition module is further used to:
[0028] Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the application gateway calling a microservice within the application;
[0029] The calling relationship drawing module is specifically used for:
[0030] Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway;
[0031] The boundary drawing module is specifically used for:
[0032] According to the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservice registered by the application in the registration center and the application gateway;
[0033] The call relationship display module is specifically used for:
[0034] Interface calls that break through the boundaries of the application and do not pass through the application gateway are displayed to the user.
[0035] In some possible implementations, the system further includes:
[0036] A static analysis module, used to obtain a static analysis result of the source code of the application, wherein the static analysis result includes a static call relationship of microservices of the application;
[0037] A call relationship analysis module, used to analyze the interface call relationship graph of the application in the running state and the static call relationship, and obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship;
[0038] The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.
[0039] In some possible implementations, the call relationship drawing module is further used to:
[0040] Draw a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application;
[0041] The call relationship analysis module is specifically used for:
[0042] An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.
[0043] In some possible implementations, the calling relationship drawing module specifically:
[0044] According to the static calling relationship of the microservices of the application, a static interface calling relationship graph of the application is drawn in the interface calling relationship graph of the application in the running state.
[0045] In some possible implementations, the call relationship display module is further used to:
[0046] The calling information of the interface call is displayed to the user, wherein the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.
[0047] In some possible implementations, the call relationship display module is specifically used to:
[0048] Interface calls with security risks are displayed to users through a target style, where the target style is different from a display style of compliant interface calls.
[0049] In some possible implementations, the system further includes:
[0050] The alarm module is used to send alarm information to the user when the interface with security risks is called.
[0051] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is used to execute instructions stored in the at least one memory, so that the computing device or the computing device cluster executes the interface management method as described in the first aspect or any implementation of the first aspect.
[0052] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, wherein the instructions instruct a computing device or a computing device cluster to execute the interface management method described in the first aspect or any one of the implementations of the first aspect.
[0053] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computing device or a computing device cluster, enables the computing device or the computing device cluster to execute the interface management method described in the first aspect or any one of the implementations of the first aspect.
[0054] Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS
[0055] In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings required for use in the embodiments are briefly introduced below.
[0056] Figure 1 A schematic diagram of the interface call relationship in a solution provided by this application;
[0057] Figure 2 A schematic diagram of the architecture of an application control system provided for this application;
[0058] Figure 3 A schematic diagram showing call information of an interface call provided by this application;
[0059] Figure 4 A flowchart of an interface management method provided for this application;
[0060] Figure 5 A schematic diagram of the call information of the interface call of each microservice in the application provided by the present application;
[0061] Figure 6 An interface call relationship diagram of a drawing application in running state provided by this application;
[0062] Figure 7 A flowchart of an interface management method provided for this application;
[0063] Figure 8 A schematic diagram provided for this application showing an interface call with security risks;
[0064] Fig. 9 A schematic diagram of an application scenario of an interface management method provided in this application;
[0065] Fig.10 A schematic diagram showing call information of an interface call provided by this application;
[0066] Fig.11 A schematic diagram of the structure of a computing device provided for this application;
[0067] Fig.12 A schematic diagram of the structure of a computing device cluster provided for this application;
[0068] Fig.13 A schematic diagram of the structure of another computing device cluster provided for this application;
[0069] Fig.14 A schematic diagram of the structure of another computing device cluster provided in this application. DETAILED DESCRIPTION
[0070] The terms "first" and "second" in the embodiments of the present application are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.
[0071] First, some technical terms involved in the embodiments of the present application are introduced.
[0072] An application programming interface (API) is a computing interface that defines the interaction between multiple computer programs, as well as the types of calls or requests that can be made, how to make calls or requests, the data format that should be used, the conventions that should be followed, etc. APIs can also provide extension mechanisms so that users can extend the functionality to varying degrees in various ways. An API can be completely customized for a component, or it can be designed based on industry standards to ensure interoperability.
[0073] API allows application developers to call a set of routine functions without having to consider the underlying source code or understand the details of its internal working mechanism. Therefore, more and more developers choose to develop applications based on API. According to the permissions opened by developers for API, API can be divided into internal API and open API. Among them, internal API provides interface calls within the application, and open API provides interface calls outside the application.
[0074] The API call can be completed by sending a request to the API server address, such as a Hypertext Transfer Protocol Secure (HTTPS) GET or POST request, and adding corresponding request parameters to the request according to the interface instructions. The API server can also return the processing result according to the processing status of the request.
[0075] Application gateways, such as API Gateway (APIG), are tools for API management and service governance that integrate configuration publishing, environment management, access authentication, user authentication, access control, and other functions. Using API gateways to host APIs, you can manage services efficiently, securely, and at low cost. As a single entry point for requests, API gateways can assign requests to the corresponding services, then collect the results and pass them to the requester.
[0076] API Gateway can implement access control and flow control of open APIs at the application level. However, API Gateway mainly manages open APIs, not the calling relationships between microservices within the application. It is only responsible for interface calls through API Gateway, and cannot identify and manage APIs that are not exposed through API Gateway. Therefore, in the face of the huge challenges that application-level API call traffic brings to application security and flow control, it is difficult for API Gateway to identify interface calls with security risks, and it is also difficult to ensure the security of the application or to effectively control the flow of the application.
[0077] In view of this, the present application provides an interface management method. The method can be executed by an application control system. The application control system, also known as the application control center, is a tool for risk identification of interface calls and assisting in security management and traffic management. Specifically, the application control system can be a software system, which can be an independent software system, or integrated into other software in the form of a plug-in, etc. The software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system, thereby executing the interface management method of the present application. In some examples, the application control system can also be a hardware system, such as a computing device cluster with an interface management function, which executes the interface management method of the present application when the computing device cluster is running.
[0078] Specifically, the application control system can obtain the interface call records of multiple microservices in the application, and the interface call records include the interface calls provided by the microservices to the internal application and / or the interface calls provided by the microservices to the external application. The application control system can draw the interface call relationship diagram of the application in the running state based on the interface call records of the multiple microservices. Then, the application control system can draw the boundary of the application in the interface call relationship diagram based on the microservice registration information of the application. Among them, the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center. When there are interface calls that break through the boundaries of the application in the interface call records, the application control system displays the interface calls with security risks to the user. Interface calls with security risks include interface calls that break through the boundaries of the application.
[0079] This method uses the interface call records of multiple microservices to draw an interface call relationship diagram of the application in operation, and draws the application boundary in combination with the application's microservice registration information, thereby identifying interface calls that break through the application boundary, realizing application security risk monitoring, ensuring the security of the application, and effectively controlling the flow of the application, providing a basis for API security governance and flow control governance.
[0080] In order to make the technical solution of the present application clearer and easier to understand, the application control system of the present application is introduced below with reference to the accompanying drawings.
[0081] A solution often includes multiple applications, each of which can be deployed in a multi-node mode. Accordingly, a large number of nodes, such as tens of thousands of nodes, can be deployed in a network space. Figure 1 As shown, multiple applications of a solution can be deployed in a virtual private cloud (VPC) in a multi-node deployment mode. The application control system mainly realizes the drawing or depiction of application-level API call relationships, including API calls within the application or API calls between applications (also called cross-application API calls), as well as the drawing of application boundaries. The application control system can identify interface calls with security risks based on the application's interface call relationships in the running state and the application's boundaries to ensure that the API is not abused. In addition, the application control system can send alarm information for API calls with security risks. Furthermore, the application control system can also provide alarm reasons (such as reasons for non-compliant API calls) to provide a basis for API security governance and flow control governance. In addition, based on the above-mentioned API call relationships, access control between microservices within the application and access control between applications can also be implemented.
[0082] For ease of description, the architecture of the application control system is explained below by drawing an interface call relationship diagram and boundary drawing for one of the applications.
[0083] See also Figure 2 The schematic diagram of the architecture of an application control system is shown, and the application control system 200 is used to draw the interface call relationship and boundary of an application, such as service A, in the running state, and then identify interface calls that break through the boundary of the application and other interface calls that have security risks. Among them, the application control system 200 includes a record acquisition module 202, a call relationship drawing module 204, a boundary drawing module 206, and a call relationship display module 208.
[0084] The record acquisition module 202 is used to obtain the interface call records of multiple microservices in the application. Among them, the interface call record includes the microservice calling the interface provided inside the application and / or the microservice calling the interface provided outside the application. The microservice of the application can record the log of the API that calls the microservice, which is also called the API call log. The API call log includes the microservice calling the internal API and / or the microservice calling the external API. The microservice can report the API call log to the application control system 200, and accordingly, the record acquisition module 202 can obtain the API call log reported by multiple microservices in the application, thereby obtaining the interface call records of multiple microservices. Furthermore, when the application also includes an application gateway, the record acquisition module 202 can also obtain the API call log reported by the application gateway, thereby obtaining the interface call record of the application gateway. Figure 2 As an example, multiple micro services of service A, such as micro services A to micro services F, and the application gateway of service A report API call logs to the application control system 200 respectively.
[0085] The call relationship drawing module 204 is used to draw the interface call relationship diagram of the application in the running state according to the interface call records of multiple microservices. When the application includes an application gateway, the call relationship drawing module 204 can draw the interface call relationship diagram of the application in the running state according to the interface call records of multiple microservices and the interface call records of the application gateway. Among them, before drawing the interface call relationship diagram, the interface call records can be aggregated first, and then the aggregated interface call records, such as all interface call records, are analyzed to obtain relational call records. Accordingly, the call relationship drawing module 204 can draw the interface call relationship diagram of the application in the running state according to the relational call records.
[0086] The boundary drawing module 206 is used to draw the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application. The registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center. When the application includes an application gateway, the boundary drawing module 206 also draws the boundary of the application in combination with the registration information of the application gateway. In this case, the boundary of the application also includes the application gateway. Still taking service A as an example, the boundary of service A can surround microservice A to microservice A and the application gateway of service A.
[0087] The call relationship display module 208 is used to display the interface calls with security risks to the user when there are interface calls that break through the application boundary in the interface call record. The interface calls with security risks include interface calls that break through the application boundary. When the application includes an application gateway, the interface calls with security risks may be calls that break through the application boundary without passing through the application gateway. Figure 2 As shown in the example, service B (service B) directly calls microservice C of service A without passing through the application gateway of service A, service C (service C) directly calls microservice E of service A without passing through the application gateway of service A, and service D (service D) directly calls microservice B of service A without passing through the application gateway of service A. The call relationship display module 208 can show the user the above-mentioned interface calls that do not pass through the application gateway of service A and directly break through the boundary of service A.
[0088] The call relationship display module 208 can display the interface calls with security risks to the user through a target style. The target style can be different from the display style of the compliant interface calls. In some examples, compliant interface calls, such as interface calls within the application, can be displayed with green lines, and interface calls with security risks can be displayed with red lines.
[0089] Furthermore, the call relationship display module 208 can also display the call information of the interface call. The call information may include at least one of the call source, call method, call path or call parameter. The call source refers to the service or microservice that calls the interface provided by the microservice. The call method may include but is not limited to POST or GET. The call path (path) can be represented by a Uniform Resource Locator (URL). The call parameter can be an interface parameter. Figure 3 As shown, the call relationship display module 208 can display the call relationship between multiple microservices in the application, the boundary of the application, the external call without passing through the gateway, the external call through the gateway, and the call information of each interface call. Among them, the call information displayed by the call relationship display module 208 can be referred to Figure 3The code configuration includes the calling path (recorded as path), calling method (recorded as method), interface name (recorded as name), request type (recorded as type) and URL.
[0090] In some possible implementations, the application control system 200 may also include an alarm module 209. The alarm module 209 is used to send alarm information to the user for interface calls that have security risks. In this way, the user can manage the API in a timely manner based on the alarm information, thereby providing a basis for API security governance and flow control governance.
[0091] Based on the aforementioned application control system 200, the present application provides an interface management method. The interface management method of the present application is introduced below in conjunction with the accompanying drawings.
[0092] See also Figure 4 A flowchart of an interface management method is shown, the method comprising the following steps:
[0093] S402: The application control system 200 obtains interface call records of multiple microservices in the application.
[0094] The interface call record includes the microservice calling the interface provided inside the application and / or the microservice calling the interface provided outside the application. Specifically, the microservice in the application can record the call log of the API provided by the microservice, and the call log can be used as the interface call record of the microservice. Multiple microservices in the application can report their own recorded call logs to the application control system 200, so that the application control system 200 can obtain the interface call records of multiple microservices in the application.
[0095] In some possible implementations, the application may also include an application gateway. The application gateway may also be called by other applications, such as other services or microservices in other services, to call microservices within the application. Similar to the microservices in the application, the application gateway may record the call log of the API provided by the application gateway, and the call log may serve as the interface call record of the application gateway. The application gateway may report the interface call record of the application gateway to the application control system 200. Accordingly, the application control system 200 may not only obtain the interface call records of multiple microservices in the application, but may also include the interface call record of the application gateway.
[0096] S404: The application control system 200 draws an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices.
[0097] Specifically, the application control system 200 aggregates the interface call records of multiple microservices, wherein, when the application includes an application gateway, the application control system 200 can aggregate the interface call records of multiple microservices and the interface call records of the application gateway. The application control system 200 can analyze the aggregated interface call records to obtain relational call records. The relational call records can be interface call records organized by relational data. Relational data can be data represented by a relational model. Then, the application control system 200 can draw an interface call relationship diagram of the application in the running state according to the relational call records.
[0098] When drawing an interface call diagram, such as Figure 5 As shown, the application control system 200 can draw the call information of the interface call of each microservice in the application according to the relational call record. Figure 2 The example of the calling information of the interface calls of each microservice of service A illustrates that the application control system 200 can draw the calling information of the interface calls of microservice A to microservice F respectively.
[0099] The call information of each microservice interface call is as follows:
[0100] Service:service name
[0101] Request: {
[0102] Type: http|grpc|tcp
[0103] url:
[0104] path:
[0105] method:
[0106] port:
[0107] }
[0108] Among them, path can indicate the calling path, method can indicate the calling method, service name can be the service name of the calling source, used to indicate the calling source, port can indicate the port number, and port can be a parameter in the calling parameters.
[0109] The application control system 200 can draw an interface call relationship diagram of the application in the running state according to the call information of the interface call of each microservice. In specific implementation, the application control system 200 can draw an interface call relationship diagram of the application in the running state according to the call information of the interface call drawn for each microservice, such as Figure 6 shown.
[0110] S406. The application control system 200 draws the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application.
[0111] The registration information indicates the microservices registered by the application in the registration center. In specific implementation, the registration information may include the identifier of the microservice registered by the application in the registration center, such as the microservice name. The boundary of the application surrounds the microservices registered by the application in the registration center. Further, when the application includes an application gateway, the application control system 200 can also obtain the registration information of the application gateway in the registration center. The registration information may include the identifier of the application gateway, such as the name of the application gateway, or the Internet Protocol (IP) address. The application control system 200 can draw the boundary of the application in the interface call relationship diagram based on the microservice registration information and the registration information of the application gateway, and the boundary surrounds the microservices and application gateway registered by the application.
[0112] S408. When there are interface calls that break through the application boundary in the interface call record, the application control system 200 displays the interface calls that have security risks to the user.
[0113] Specifically, the application control system 200 can identify whether there are interface calls that break through the boundaries of the application in the interface call record based on the interface call relationship diagram and the boundaries of the application. For example, the application control system 200 can or the call source in the call information of the microservice. When the call source is a service or microservice outside the boundary of the application, specifically a service or microservice outside the microservice registered by the application, it means that the interface call breaks through the boundary of the application, and there are interface calls that break through the boundary of the application in the interface call record, and the application has security risks. Accordingly, the application control system 200 can display interface calls with security risks to the user. Among them, interface calls with security risks include interface calls that break through the boundaries of the application.
[0114] In some possible implementations, the application control system 200 can display interface calls that pose security risks to users through a target style. The target style is different from the display style of compliant interface calls. Compliant interface calls may include interface calls within the application, or interface calls to microservices within the application through an application gateway, and interface calls that pose security risks include interface calls to microservices from outside the application, such as interface calls to microservices within the application that do not pass through an application gateway. In specific implementations, the display styles of the target style and compliant interface calls may be different colors, or different line types, or lines of different thicknesses. For example, the target style may be a red connecting line, and the display style of the compliant interface call may be a green connecting line.
[0115] The application control system 200 may also display the call information of the interface call to the user. The call information includes at least one of the call source, the call method, the call path, or the call parameter. The application control system 200 may display the call information for the interface call with security risks, or the application control system 200 may display the call information for all interface calls of the application. For example, the application control system 200 may display the call information of all interface calls in the interface call relationship diagram.
[0116] Based on the above description, this application provides an interface management method. This method uses the interface call records of multiple microservices to draw the interface call relationship diagram of the application in the running state, and draws the boundary of the application in combination with the microservice registration information of the application, and then identifies the interface calls that break through the boundary of the application, realizes the security risk monitoring of the application, can ensure the security of the application, and effectively control the flow of the application, providing a basis for the security governance and flow control governance of the API.
[0117] Figure 4 The embodiments mainly identify interface calls that pose security risks from a compliance perspective. In some possible implementations, the application control system 200 may also combine static analysis technology to identify interface calls that pose security risks, such as interface calls that exist in the running state but are not defined in the source code.
[0118] See also Figure 7 A flowchart of an interface management method is shown, the method comprising the following steps:
[0119] S702: The application control system 200 obtains a static analysis result of the source code of the application.
[0120] Static analysis, also known as program static analysis, refers to a code analysis technology that scans program code (such as source code) through lexical analysis, syntax analysis, control flow, data flow analysis and other technologies without running the code to verify whether the code meets indicators such as standardization, security, reliability, and maintainability.
[0121] In a specific implementation, the application control system 200 may obtain the source code of the application, and then perform static analysis on the source code to obtain a static analysis result. The static analysis result may include a static call relationship of the microservices of the application. The static call relationship may be a call relationship of the microservices obtained by statically analyzing the source code, specifically a call relationship of the microservices defined in the source code of the application. Furthermore, when the application includes an application gateway, the static call relationship may also include a call relationship of the application gateway calling the microservice.
[0122] S704: The application control system 200 analyzes the interface call relationship graph and the static call relationship of the application in the running state, and obtains the interface calls that exist in the interface call relationship graph in the running state but do not exist in the static call relationship.
[0123] Specifically, the application control system 200 can draw an interface call relationship diagram of the application in a static state based on the static call relationship of the microservices of the application. Among them, the application control system 200 can draw an interface call relationship diagram of the application in a static state in a similar manner to drawing an interface call relationship diagram of the running state. For example, the application control system 200 can draw the interface call relationship of each microservice based on the call information of the static call relationship, and then draw an interface call relationship diagram of the application in a static state based on the interface call relationship of each microservice. Accordingly, the application control system 200 can analyze the interface call relationship diagram of the application in the running state and the interface call relationship diagram of the application in the static state to obtain interface calls that exist in the interface call relationship diagram of the running state and do not exist in the static call relationship.
[0124] In some possible implementations, the application control system 200 can draw an interface call relationship graph of the application in the static state in the interface call relationship graph of the application in the running state according to the static call relationship of the microservices of the application. In this way, it is helpful for the application control system 200 to compare the interface call relationship graph of the application in the running state with the interface call relationship graph of the application in the static state, and obtain the interface calls that exist in the interface call relationship graph of the running state but do not exist in the static interface call relationship graph.
[0125] Accordingly, the interface calls with security risks may include interface calls that exist in the interface call relationship graph in the running state but do not exist in the static call relationship.
[0126] When explanation is needed, Figure 7 The illustrated embodiment can be used with Figure 4 For example, the application control system 200 can be combined with Figure 4 Based on the embodiment shown, S702 and S704 are further executed. Accordingly, when the application control system 200 executes S608 to display the interface calls with security risks, it can not only display the interface calls that break through the application boundary, but also display the interface calls that exist in the interface call relationship diagram of the running state and do not exist in the static call relationship. Figure 8 As shown, still taking service A as an example, service A includes microservice F calling microservice C in the interface call relationship diagram in the running state. This interface call does not exist in the static call relationship of service A. The application control system 200 can display the interface call through a target style, such as a red connecting line or a bold connecting line.
[0127] In some possible implementations, the application control system 200 can also send warning information to the user for interface calls that pose security risks. The application control system 200 can send warning information to the user in different ways. For example, the warning information can be different types of signals. In some examples, the application control system 200 can send warning information to the user in the form of a pop-up window for interface calls that pose security risks. In other examples, the application control system 200 can also send warning information to the user by vibration or flashing of a prompt light.
[0128] Next, the interface management method of the present application is introduced in conjunction with a specific application scenario.
[0129] See also Fig. 9 The application scenario diagram of an interface management method shown in the figure can be applied to a microservice hosting platform, which includes an application control center, which is used as an important capability carrier for application-level API governance to implement the functions of the aforementioned application control platform 200. For example, the application control center is used to draw, warn and display all API call relationships, application boundaries, and illegal call relationships of the application. The method specifically includes the following steps:
[0130] Step 1: Each microservice hosted by the microservice hosting platform records a call log of the API that calls the microservice.
[0131] The call log can include the microservice's calls to internal APIs (internal APIs) and the microservice's calls to external APIs (open APIs). Fig. 9 As shown, the microservices of the application may include Sermant, which is an agentless service mesh based on Java bytecode enhancement technology. It uses Java bytecode enhancement technology to provide service governance functions for host applications to solve service governance problems in large-scale microservice architectures. In this embodiment, Sermant can record the call log of the API that calls the microservice, and Sermant can report the call log of the API of the microservice to the application control center. The call log can be a record of the interface call of the microservice.
[0132] In some possible implementations, the application also includes an application gateway. The application gateway can also record the call log of calling the application gateway and report the call log of calling the application gateway to the application control center. In this way, the application control center can obtain the interface call record of the microservice and the interface call record of the application gateway.
[0133] Step 2: The application control center aggregates the interface call records of each microservice and application gateway.
[0134] Specifically, the application control center can aggregate the interface call records of each microservice and application gateway through clustering, so as to obtain all interface call records of the application in the running state.
[0135] Step 3: The application control center analyzes all interface call records to form relational call records.
[0136] Specifically, the application control center may perform relationship analysis based on the interface call records, thereby forming a relational call record.
[0137] Step 4: The application control center obtains the microservice registration information of the application and the registration information of the application gateway from the registration center.
[0138] The microservice registration information may include the identifier of the microservice registered by the application in the registration center, such as the microservice name. The registration information of the application gateway may include the identifier of the application gateway registered by the application in the registration center, such as the name or IP address of the application gateway.
[0139] It should be noted that step 4 can be executed in parallel with step 1, step 2, and step 3, or can be executed sequentially in a set order, and the embodiment of the present application does not limit this.
[0140] Step 5: The application control center draws an interface call relationship diagram of the application in the running state according to the relational call records.
[0141] The interface call relationship diagram includes the call information of all interface calls of the application. The application control center can draw the call information of the interface calls of each microservice in the application according to the relational call records, and then draw the interface call relationship diagram of the application in the running state according to the call information of the interface calls of each microservice.
[0142] Step 6: The application control center combines the microservice registration information of the application, draws the application boundary in the interface call relationship diagram, and displays the interface calls that have security risks.
[0143] The microservice registration information includes the identifier of the registered microservice. The application control center can combine the identifier of the microservice registered by the application and draw a boundary for surrounding the microservice registered by the application in the registration center in the interface call relationship diagram. The application control center can use a target style, such as a red connecting line, to display interface calls with security risks, such as interface calls that break through the boundaries of the application.
[0144] Furthermore, the application control center can also diagnose the security of the application boundary. For example, if there are interface calls that break through the application boundary in the interface call records of the application in the running state, it means that there is a security risk in the application boundary.
[0145] Step 7: The application control center issues an alert for interface calls that pose security risks.
[0146] The application control center can identify unsafe traffic at the application level, such as interface calls that pose security risks, and display them in the form of views, reminding developers to rectify unreasonable (such as non-compliant) interface calls to assist in security management and traffic management. For example, the application control center can identify interface calls that break through the boundaries of the application without passing through the application gateway. The above-mentioned boundary-breaking interface calls identified by the application control center can be used to monitor whether there are uncontrollable elephant flows, whether there are frequent calls that can trigger a denial of service. Mouse flows, and whether there are externally exposed interfaces without access control. In this way, it can provide assistance for application security management and traffic management.
[0147] In some possible implementations, the application control center can also perform static analysis on the source code of the application to obtain a static interface call relationship. The application control center can draw a static interface call relationship graph based on the static interface call relationship. Accordingly, the application control center can compare the interface call relationship graph in the running state (actual call relationship) with the static interface call relationship graph (call relationship defined in the source code) to find interface calls with security risks, such as unsafe interface calls.
[0148] like Fig.10 As shown, when the application control center draws an interface call relationship diagram, such as a running interface call relationship diagram and a static interface call relationship diagram, it can not only draw the interface calls between microservices, but also draw the call information of the interface calls. The call information can be as follows:
[0149] 'service': service name
[0150] 'version': service version
[0151] 'request':[{'type':'http'|'grpc'|'tcp'
[0152] 'url': url|host name
[0153] 'path': only for 'http' and 'grpc'
[0154] 'method': only for 'http'
[0155] 'port': only for 'tcp'}]
[0156] This method achieves auxiliary security governance and traffic governance by drawing all import and export API call relationships of the application and displaying specific call information, drawing the boundaries of the application, and displaying interface calls with security risks in the interface call relationship diagram, and issuing alarms for interface calls with security risks.
[0157] Based on the above interface management method, the present application also provides an application control system. Figure 2 As shown, the application control system 200 includes:
[0158] A record acquisition module 202 is used to acquire interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservice to an interface provided inside the application and / or calls by the microservice to an interface provided outside the application;
[0159] A call relationship drawing module 204 is used to draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices;
[0160] A boundary drawing module 206 is used to draw the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center;
[0161] The call relationship display module 208 is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records. The interface calls with security risks include interface calls that break through the boundaries of the application.
[0162] Exemplarily, the record acquisition module 202 , the call relationship drawing module 204 , the boundary drawing module 206 , and the call relationship display module 208 may be implemented by hardware or by software.
[0163] Among them, when implemented by software, the record acquisition module 202, the call relationship drawing module 204, the boundary drawing module 206, and the call relationship display module 208 can be applications running on a computing device. Taking the call relationship drawing module 204 as an example, the application can be a computing engine. The application can also be provided to users in the form of virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, and container services. Among them, the VM service can be a service that virtualizes a virtual machine (VM) resource pool on multiple physical hosts through virtualization technology to provide VMs for users to use on demand. The BMS service is a service that virtualizes a BMS resource pool on multiple physical hosts to provide BMS for users to use on demand. The container service is a service that virtualizes a container resource pool on multiple physical hosts to provide containers for users to use on demand. VM is a simulated virtual computer, that is, a logical computer. BMS is a high-performance computing service that can be elastically scalable, and its computing performance is no different from that of a traditional physical machine, and it has the characteristics of secure physical isolation. Container is a kernel virtualization technology that can provide lightweight virtualization to achieve the purpose of isolating user space, processes and resources. It should be understood that the VM service, BMS service and container service in the above virtualization services are only used as specific examples. In actual applications, virtualization services can also be other lightweight or heavyweight virtualization services, which are not specifically limited here.
[0164] When implemented by hardware, the record acquisition module 202, the call relationship drawing module 204, the boundary drawing module 206, and the call relationship display module 208 may include at least one computing device, such as a server, etc. Alternatively, the record acquisition module 202, the call relationship drawing module 204, the boundary drawing module 206, and the call relationship display module 208 may also be implemented by using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0165] In some possible implementations, the application further includes an application gateway, and the record acquisition module 202 is further used to:
[0166] Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the application gateway calling a microservice within the application;
[0167] The calling relationship drawing module 204 is specifically used for:
[0168] Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway;
[0169] The boundary drawing module 206 is specifically used for:
[0170] According to the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservice registered by the application in the registration center and the application gateway;
[0171] The calling relationship display module 208 is specifically used for:
[0172] Interface calls that break through the boundaries of the application and do not pass through the application gateway are displayed to the user.
[0173] In some possible implementations, the application control system 200 further includes:
[0174] A static analysis module, used to obtain a static analysis result of the source code of the application, wherein the static analysis result includes a static call relationship of microservices of the application;
[0175] A call relationship analysis module, used to analyze the interface call relationship graph of the application in the running state and the static call relationship, and obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship;
[0176] The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.
[0177] Among them, the static analysis module and the call relationship analysis module are Figure 2 Similar to the aforementioned record acquisition module 202, call relationship drawing module 204, boundary drawing module 206, and call relationship display module 208, the static analysis module and the call relationship analysis module can be implemented by software or hardware.
[0178] In some possible implementations, the call relationship drawing module 204 is further used to:
[0179] Draw a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application;
[0180] The call relationship analysis module is specifically used for:
[0181] An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.
[0182] In some possible implementations, the calling relationship drawing module 204 specifically:
[0183] According to the static calling relationship of the microservices of the application, a static interface calling relationship graph of the application is drawn in the interface calling relationship graph of the application in the running state.
[0184] In some possible implementations, the call relationship display module 208 is further used to:
[0185] The calling information of the interface call is displayed to the user, wherein the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.
[0186] In some possible implementations, the call relationship display module 208 is specifically used to:
[0187] Interface calls with security risks are displayed to users through a target style, where the target style is different from a display style of compliant interface calls.
[0188] In some possible implementations, the application control system 200 further includes:
[0189] The warning module 209 is used to send a warning message to the user for calling the interface with security risks.
[0190] The present application also provides a computing device 1100. Fig.11 As shown, the computing device 1100 includes: a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. The processor 1104, the memory 1106, and the communication interface 1108 communicate through the bus 1102. The computing device 1100 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 1100.
[0191] The bus 1102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.11 The bus 1102 may include a path for transmitting information between various components of the computing device 1100 (eg, the memory 1106, the processor 1104, and the communication interface 1108).
[0192] The processor 1104 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).
[0193] The memory 1106 may include a volatile memory, such as a random access memory (RAM). The memory 1106 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD) or a solid state drive (SSD). The memory 1106 stores executable program code, and the processor 1104 executes the executable program code to implement the aforementioned interface management method. Specifically, the memory 1106 stores instructions for the application control system 200 to execute the interface management method.
[0194] The communication interface 1108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1100 and other devices or a communication network.
[0195] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.
[0196] like Fig.12 As shown, the computing device cluster includes at least one computing device 1100. The memory 1106 in one or more computing devices 1100 in the computing device cluster may store the same application control system 200 for executing the interface management method.
[0197] In some possible implementations, one or more computing devices 1100 in the computing device cluster may also be used to execute some instructions of the application control system 200 for executing the interface management method. In other words, a combination of one or more computing devices 1100 may jointly execute instructions of the application control system 200 for executing the interface management method.
[0198] It should be noted that the memory 1106 in different computing devices 1100 in the computing device cluster may store different instructions for executing partial functions of the application control system 200 .
[0199] Fig.13 A possible implementation is shown. Fig.13 As shown, two computing devices 1100A and 1100B are connected via a communication interface 1108. The memory in the computing device 1100A stores instructions for executing the functions of the record acquisition module 202 and the call relationship display module 208. The memory in the computing device 1100B stores instructions for executing the functions of the call relationship drawing module 204 and the boundary drawing module 206. In other words, the memories 1106 of the computing devices 1100A and 1100B jointly store instructions for the application control system 200 to execute the interface management method. Further, the memory in the computing device 1100A stores instructions for executing the functions of the alarm module 209, and the memory in the computing device 1100B stores instructions for executing the functions of the static analysis module and the call relationship analysis module.
[0200] Fig.13 The connection mode between the computing device clusters shown may be considered to be that the interface management method provided by the present application requires a lot of computing power to perform call relationship drawing and boundary drawing. Therefore, it is considered to hand over the functions implemented by the call relationship drawing module 204 and the boundary drawing module 206 to the computing device 1100B for execution.
[0201] It should be understood that Fig.13 The functions of the computing device 1100A shown in FIG. 1100A may also be completed by multiple computing devices 1100. Similarly, the functions of the computing device 1100B may also be completed by multiple computing devices 1100.
[0202] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.14 A possible implementation is shown. Fig.14 As shown, two computing devices 1100C and 1100D are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1106 in the computing device 1100C stores instructions for executing the functions of the record acquisition module 202 and the call relationship display module 208. At the same time, the memory 1106 in the computing device 1100D stores instructions for executing the functions of the call relationship drawing module 204 and the boundary drawing module 206.
[0203] Fig.14 The connection method between the computing device clusters shown can be considered to be that the interface management method provided in this application requires a lot of computing power to draw call relationships and boundaries, so it is considered to hand over the functions implemented by the call relationship drawing module 204 and the boundary drawing module 206 to the computing device 1100D for execution.
[0204] It should be understood that Fig.14 The functions of the computing device 1100C shown in FIG. 1100A may also be completed by multiple computing devices 1100. Similarly, the functions of the computing device 1100D may also be completed by multiple computing devices 1100.
[0205] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by the computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned application to the application control system 200 for executing the interface management method.
[0206] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the above-mentioned interface management method.
[0207] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present invention.
Claims
1. An interface management method, characterized in that: The method comprises: Obtaining interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservice to an interface provided inside the application and / or calls by the microservice to an interface provided outside the application; Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices; According to the microservice registration information of the application, drawing the boundary of the application in the interface call relationship diagram, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center; When there are interface calls that break through the boundary of the application in the interface call record, interface calls with security risks are displayed to the user, and the interface calls with security risks include interface calls that break through the boundary of the application.
2. The method according to claim 1, characterized in that: The application further includes an application gateway, and the method further includes: Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the application gateway calling a microservice within the application; Drawing an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices includes: Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway; Drawing the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application includes: According to the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservice registered by the application in the registration center and the application gateway; The step of displaying the interface calls that have security risks to the user includes: Interface calls that break through the boundaries of the application and do not pass through the application gateway are displayed to the user.
3. The method according to claim 1 or 2, characterized in that: The method further comprises: Obtaining a static analysis result of the source code of the application, wherein the static analysis result includes a static call relationship of microservices of the application; Analyze the interface call relationship graph of the application in the running state and the static call relationship to obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship; The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.
4. The method according to claim 3, characterized in that: The method further comprises: Draw a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application; The analyzing the interface call relationship graph and the static call relationship of the application in the running state includes: An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.
5. The method according to claim 4, characterized in that Drawing a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application includes: According to the static calling relationship of the microservices of the application, a static interface calling relationship graph of the application is drawn in the interface calling relationship graph of the application in the running state.
6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The calling information of the interface call is displayed to the user, wherein the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.
7. The method according to any one of claims 1 to 6, characterized in that: The step of displaying the interface calls that have security risks to the user includes: Interface calls with security risks are displayed to users through a target style, where the target style is different from a display style of compliant interface calls.
8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: For the interface call with security risks, a warning message is sent to the user.
9. An application control system, characterized in that: The system comprises: A record acquisition module, used to acquire interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservice to an interface provided inside the application and / or calls by the microservice to an interface provided outside the application; A call relationship drawing module, used to draw an interface call relationship diagram of the application in a running state according to the interface call records of the multiple microservices; A boundary drawing module, used to draw the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center; The call relationship display module is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records, and the interface calls with security risks include interface calls that break through the boundaries of the application.
10. The system according to claim 9, characterized in that The application further includes an application gateway, and the record acquisition module is further used for: Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the application gateway calling a microservice within the application; The calling relationship drawing module is specifically used for: Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway; The boundary drawing module is specifically used for: According to the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservice registered by the application in the registration center and the application gateway; The calling relationship display module is specifically used for: Interface calls that break through the boundaries of the application and do not pass through the application gateway are displayed to the user.
11. The system according to claim 9 or 10, characterized in that: The system further comprises: A static analysis module, used to obtain a static analysis result of the source code of the application, wherein the static analysis result includes a static call relationship of microservices of the application; A call relationship analysis module, used to analyze the interface call relationship graph of the application in the running state and the static call relationship, and obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship; The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.
12. The system according to claim 11, characterized in that The call relationship drawing module is also used for: Draw a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application; The call relationship analysis module is specifically used for: An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.
13. The system according to claim 12, characterized in that The calling relationship drawing module specifically: According to the static calling relationship of the microservices of the application, a static interface calling relationship graph of the application is drawn in the interface calling relationship graph of the application in the running state.
14. The system according to any one of claims 9 to 13, characterized in that The call relationship display module is also used for: The calling information of the interface call is displayed to the user, wherein the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.
15. The system according to any one of claims 9 to 14, characterized in that The calling relationship display module is specifically used for: Interface calls with security risks are displayed to users through a target style, where the target style is different from a display style of compliant interface calls.
16. The system according to any one of claims 9 to 15, characterized in that The system further comprises: The alarm module is used to send an alarm message to the user when the interface with security risks is called.
17. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the interface management method as described in any one of claims 1 to 8.
18. A computer-readable storage medium, characterized in that: Comprising computer-readable instructions; the computer-readable instructions are used to implement the interface management method according to any one of claims 1 to 8.
19. A computer program product, characterized in that Comprising computer-readable instructions; the computer-readable instructions are used to implement the interface management method according to any one of claims 1 to 8.
Citation Information
Cited By
Interface management method and related device
EP4790549A1
Interface management method and related device
WO2025091832A1