Micro-service Security Control Method, Device, Equipment and Computer-readable Storage Medium

Abstract

The present application provides a microservice security control method, apparatus, device, and computer-readable storage medium. The method includes: receiving a call request sent by a client security proxy, where the call request includes a server microservice identifier requested to be called by the client; obtaining a client security certificate and verifying the client security certificate to obtain a verification result; when the verification result is successful based on the verification result, obtaining a client microservice identifier based on the client security certificate; obtaining an access control list of the server microservice, and when it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the access control list, performing business processing on the call request to obtain a processing result; and sending the processing result to the client security proxy. Through the present application, identity can be verified through certificates to improve the communication security between microservices.

Description

Technical Field

[0001] This application relates to network technologies, and in particular, to a microservice security method, apparatus, device, and computer-readable storage medium. Background Art

[0002] In a software architecture of the "microservice" type, a business function is implemented as an independent microservice. In terms of deployment form, microservices are deployed as independent running units in the form of processes or containers, and these running units can be started, stopped, and upgraded independently, and can be horizontally scaled. After adopting the microservice architecture, the method calls within the process in the same application become remote network calls between microservice processes. In a network call, the client and the server are different entities in the network, and data will pass through various different nodes in the network, posing security risks such as identity forgery, data sniffing, and data tampering.

[0003] In a traditional software deployment model, software is deployed in an enterprise's data center. The network security architecture isolates a trusted internal security area through boundary security products such as firewalls, WAFs, and IPSs outside the data center. This structure focuses on defending the boundary, blocking security risks outside, and assuming that the network within this area is secure and the running software has no risk of being maliciously attacked.

[0004] With the popularization of cloud computing, more and more enterprise software has been migrated to public clouds, or a hybrid deployment architecture of public clouds and private clouds has been adopted. In the cloud mode, enterprise data becomes dispersed, and the data access method also becomes diversified. For example, a part of an enterprise's applications is in the local office building, a part is in the cloud, and employees, partners, and customers located in different places access the applications through various devices. In this case, the traditional boundary-based security architecture is no longer effective.

[0005] In an edge computing scenario, by sinking some parts of the software system that have little computing power but are sensitive to the user's latency experience to edge computing nodes, the response speed of the terminal can be greatly accelerated, and the user experience can be improved. However, there are also huge challenges in security between edge nodes and the cloud. There are a large number of edge nodes. If the security of the applications deployed in them cannot be guaranteed, it will pose a huge threat to the core business deployed in the cloud. Summary of the Invention

[0006] Embodiments of this application provide a microservice security control method, apparatus, and computer-readable storage medium, which can improve the communication security between microservices.

[0007] The technical solution of the embodiments of this application is implemented as follows:

[0008] Embodiments of this application provide a microservice security control method, including:

[0009] Receive a call request sent by the client security proxy, where the call request includes the server microservice identifier requested by the client to call;

[0010] Obtain the client security certificate and verify the client security certificate to obtain a verification result;

[0011] When the verification result is successful based on the verification, obtain the client microservice identifier based on the client security certificate;

[0012] Obtain the access control list of the server microservice. When it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the access control list, perform business processing based on the call request to obtain a processing result;

[0013] Send the processing result to the client security proxy.

[0014] An embodiment of the present application provides a microservice security control method, including:

[0015] When it is monitored that the microservice code library is updated, perform code construction based on the microservice source code in the microservice code library;

[0016] When the code construction is successful, scan and analyze each microservice source code to obtain the call relationship between each microservice;

[0017] Generate a first call relationship graph based on the call relationships between the microservices;

[0018] Send the first call relationship graph to the security control center so that the security control center determines the access control list of each microservice based on the first call relationship graph.

[0019] An embodiment of the present application provides a microservice security control device, including:

[0020] A first receiving module for receiving a call request sent by the client security proxy, where the call request includes the server microservice identifier requested by the client to call;

[0021] A first obtaining module for obtaining the client security certificate and verifying the client security certificate to obtain a verification result;

[0022] A second obtaining module for obtaining the client microservice identifier based on the client security certificate when the verification result is successful based on the verification;

[0023] A third acquisition module, configured to acquire an access control list of a server-side microservice. When it is determined that the client-side microservice depends on the server-side microservice based on the client-side microservice identifier and the access control list, business processing is performed based on the call request to obtain a processing result;

[0024] A first sending module, configured to send the processing result to the client security proxy.

[0025] In some embodiments, the apparatus further includes:

[0026] A third sending module, configured to send a certificate acquisition request to a security control center, where the certificate acquisition request includes its own public key and a microservice identifier;

[0027] A second receiving module, configured to receive a server-side certificate returned by the security control center, where the server-side certificate is signed using the private key of the security control center.

[0028] In some embodiments, the third acquisition module is further configured to:

[0029] Send an access list acquisition request to the security control center;

[0030] Receive an access control list sent by the security control center, where the access control list includes a first microservice identifier set on which the server-side microservice depends and a second microservice identifier set that depends on the server-side microservice.

[0031] In some embodiments, the apparatus further includes:

[0032] A second determination module, configured to determine whether the client-side microservice identifier exists in the second microservice identifier set;

[0033] A third determination module, configured to determine that the client-side microservice depends on the server-side microservice when the client-side microservice identifier exists in the second microservice identifier set.

[0034] In some embodiments, the apparatus further includes:

[0035] A fourth acquisition module, configured to acquire service call information within a preset duration, where the service call information includes calling the server-side microservice and other microservices called by the server-side microservice;

[0036] A fourth sending module, configured to send the service call information to a call analysis server, so that the call analysis server generates a second call relationship graph based on the service call information.

[0037] An embodiment of the present application provides a microservice security control apparatus, including:

[0038] A building module for code building based on the microservice source code in the microservice code library when it is detected that the microservice code library has been updated;

[0039] A scanning and analysis module for scanning and analyzing each microservice source code to obtain the call relationships between the microservices when the code building is successful;

[0040] A first generation module for generating a first call relationship graph based on the call relationships between the microservices;

[0041] A second sending module for sending the first call relationship graph to a security control center so that the security control center determines the access control list of each microservice based on the first call relationship graph.

[0042] In some embodiments, the apparatus further includes:

[0043] A fifth acquisition module for acquiring service call information sent by each security agent;

[0044] A second generation module for generating a second call relationship graph based on the service call information;

[0045] A verification module for verifying each call relationship in the second call relationship graph using a preset security policy to obtain the verification results of each call relationship;

[0046] A first update module for updating the second call relationship graph to obtain an updated second call relationship graph when it is determined that there is a call relationship with a verification result of failed verification.

[0047] In some embodiments, the apparatus further includes:

[0048] A fifth sending module for sending the updated second call relationship graph to a security control center so that the security control center updates the access control list of each microservice based on the updated second call relationship graph; or,

[0049] A second update module for updating the first call relationship graph to obtain an updated first call relationship graph when it is determined that there is a call relationship with a verification result of failed verification;

[0050] A sixth sending module for sending the updated first call relationship graph to a security control center so that the security control center updates the access control list of each microservice based on the updated first call relationship graph.

[0051] In some embodiments, the first generation module is further configured to:

[0052] Based on the call relationships between the respective microservices, determine whether there are circular calls between the microservices;

[0053] When there are no circular calls, generate a first call relationship graph based on the call relationships between the respective microservices.

[0054] In some embodiments, the apparatus further includes:

[0055] A first output module, configured to output a first warning message when it is determined that there are circular calls, where the first warning message is used to prompt a check of the microservice code logic;

[0056] An update monitoring module, configured to monitor whether the microservice code library has been updated.

[0057] In some embodiments, the second update module is further configured to:

[0058] When it is determined that there is a call relationship with a verification result of verification failed, output a second warning message, where the second warning message at least includes the call relationship information with verification failed;

[0059] Receive an update operation for the call relationship with verification failed;

[0060] In response to the update operation, update the second call relationship graph to obtain an updated second call relationship graph; or,

[0061] When it is determined that there is a call relationship with a verification result of verification failed, delete the call relationship with verification failed from the second call relationship graph to obtain an updated second call relationship graph.

[0062] An embodiment of the present application provides a microservice security control device, including:

[0063] A memory, configured to store executable instructions;

[0064] A processor, configured to implement the method provided by the embodiment of the present application when executing the executable instructions stored in the memory.

[0065] An embodiment of the present application provides a computer-readable storage medium, storing executable instructions, which are used to cause a processor to implement the method provided by the embodiment of the present application when executed.

[0066] The embodiment of the present application has the following beneficial effects:

[0067] After receiving the call request sent by the client security proxy, obtain the client security certificate, verify the client security certificate, and obtain a verification result, where the call request includes the server microservice identifier requested by the client to call; when the verification result is successful based on the verification, obtain the client microservice identifier based on the client security certificate; obtain the access control list of the server microservice, and when it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the access control list, perform business processing based on the call request to obtain a processing result; finally, send the processing result to the client security proxy. In the embodiments of the present application, after obtaining the call request, first verify the security certificate of the other party to determine whether the identity is legal, and then, in the case of a legal identity, further determine whether the client microservice depends on the server microservice through the access control list, and then perform business processing based on the call request, so as to ensure the security of microservice communication in a zero-trust microservice system. Description of the Drawings

[0068] Figure 1 is a schematic diagram of the network architecture of the microservice security control system 100 provided by the embodiments of the present application;

[0069] Figure 2 is a schematic diagram of the structure of the microservice server 400 provided by the embodiments of the present application;

[0070] Figure 3 is a schematic diagram of an implementation process of the microservice security control method provided by the embodiments of the present application;

[0071] Figure 4 is another schematic diagram of an implementation process of the microservice security control method provided by the embodiments of the present application;

[0072] Figure 5A is a schematic diagram of an implementation process of the microservice security control method provided by the embodiments of the present application;

[0073] Figure 5B is a schematic diagram of the first call relationship diagram provided by the embodiments of the present application;

[0074] Figure 5C is a schematic diagram of the second call relationship diagram and the updated second call relationship diagram provided by the embodiments of the present application;

[0075] Figure 6 is a schematic diagram of yet another implementation process of the microservice security control method provided by the embodiments of the present application;

[0076] Figure 7 is a schematic diagram of the static analysis implementation process of the call relationship diagram in the development state provided by the embodiments of the present application;

[0077] Figure 8 It is a schematic diagram of the implementation process of the initialization / updating process of the security proxy in the running state provided by the embodiments of the present application;

[0078] Figure 9 It is a schematic diagram of the access between microservices in the running state provided by the embodiments of the present application;

[0079] Figure 10 It is a schematic diagram of the implementation process of remote calls and security authentication between microservices in the running state provided by the embodiments of the present application;

[0080] Figure 11 It is a schematic diagram of the dynamic analysis process of the call relationship diagram in the running state provided by the embodiments of the present application;

[0081] Figure 12 It is a schematic diagram of the implementation process of analyzing the call relationship by using an expert knowledge base provided by the embodiments of the present application. Detailed implementation manners

[0082] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be construed as limiting the present application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present application.

[0083] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments. However, it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0084] In the following description, the terms "first\second\third" are only used to distinguish similar objects and do not represent a specific order for the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence when allowed, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein.

[0085] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0086] Before further elaborating on the embodiments of the present application, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following explanations.

[0087] 1) Microservices is an architectural and organizational approach to software development, where the software consists of small, independent services that communicate via well-defined APIs. These services are the responsibility of individual small, independent teams. The microservices architecture makes applications easier to scale and develop more quickly, thus accelerating innovation and shortening the time to market for new features.

[0088] 2) A security proxy is typically an intermediate server that allows client computers or end-users to access network resources through various encryption methods. When the proxy receives a request from the client, it uses filtering rules to verify the request and route it correctly to the appropriate application or server.

[0089] 3) Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve the computing, storage, processing, and sharing of data.

[0090] 4) A private cloud creates cloud infrastructure and software and hardware resources within a firewall for departments within an organization or enterprise to share the resources in the data center. To create a private cloud, in addition to hardware resources, there is generally cloud device (IaaS, Infrastructure as a Service) software.

[0091] Private cloud computing also consists of three levels: cloud hardware, cloud platform, and cloud services. The difference is that the cloud hardware is the user's own personal computer or server, rather than the data center of a cloud computing vendor. Cloud computing vendors build data centers to provide public cloud services to millions of users, so they need to have hundreds of thousands or even millions of servers. For private cloud computing, it only serves friends and family for individuals, and only serves the employees, customers, and suppliers of the enterprise for enterprises. Therefore, an individual's or enterprise's own personal computer or server is sufficient to provide cloud services.

[0092] 5) A public cloud typically refers to a cloud that can be used provided by a third-party provider. A public cloud can generally be accessed via the Internet and may be free or low-cost. The core attribute of a public cloud is shared resource services. There are many instances of this cloud that can provide services throughout the open public network today.

[0093] 6) The hybrid cloud combines the public cloud and the private cloud and is the main model and development direction of cloud computing in recent years. The private cloud is mainly for enterprise users. Due to security considerations, enterprises are more willing to store data in the private cloud, but at the same time, they also hope to obtain the computing resources of the public cloud. In this case, the hybrid cloud is increasingly adopted. It mixes and matches the public cloud and the private cloud to achieve the best results. This personalized solution achieves the goal of saving money and ensuring security.

[0094] To better understand the microservice security control method provided by the embodiments of the present application, first, the microservice security control method and its existing drawbacks in the related art will be described.

[0095] To address the current security challenges of microservices, by default, no one, device, or system inside or outside the network should be trusted. That is, the network environment in which the system operates is considered "zero trust", and identity authentication and encrypted transmission are required to ensure the security of access between applications.

[0096] A common way to solve identity authentication and encrypted transmission is to adopt a certificate mechanism. When two entities in the network access each other, they first verify each other's identity through certificates, and then negotiate a one-time key for encrypted transmission. If this method is used to implement secure communication in a zero-trust network in microservice applications, code for service authentication and communication encryption needs to be added to the business code of the microservices.

[0097] I. Transformation cost: A large number of existing microservices need to be transformed, and the code needs to be modified to add logic related to authentication and encryption. Moreover, since the security-related code invades the business logic, it increases the maintenance difficulty of the microservice code and the operation and maintenance costs of microservice instance upgrades and expansions.

[0098] II. Policy solidification: The mutual communication between microservices forms a mesh communication model, but not every microservice needs to communicate with any other microservice. A microservice usually only needs to access a specific few microservices with which it has a business relationship. This network access relationship will change with the changes in the system and business. However, managing this access relationship in business microservices will lead to policy solidification and is difficult to adjust.

[0099] Based on this, the embodiments of the present application provide a microservice security method, apparatus, device, and computer-readable storage medium, which can achieve secure communication of the microservice system under a zero-trust network. The following describes an exemplary application of the microservice security control device provided by the embodiments of the present application. The device provided by the embodiments of the present application can be implemented as various types of user terminals such as laptop computers, tablet computers, desktop computers, set-top boxes, and mobile devices (e.g., mobile phones, portable music players, personal digital assistants, dedicated messaging devices, portable game devices), or can be implemented as a server. Hereinafter, the exemplary application when the device is implemented as a server will be described.

[0100] Refer to Figure 1 , Figure 1 which is a schematic diagram of the network architecture of the microservice security control system 100 provided by the embodiments of the present application. As Figure 1 shown, the network architecture includes: a microservice client 200, a security control center 300, a microservice server 400, and a call analysis server 500. Among them, the microservice client 200, the security control center 300, and the microservice server 400 are respectively connected to each other in pairs through a network ( Figure 1 not shown), and the security control center 300 and the call analysis server 500 are also connected through a network. In the embodiments of the present application, the network can be a wide area network, a local area network, or a combination of the two.

[0101] Security agents are respectively installed in the microservice client 200 and the microservice server 400. The security agents respectively obtain their own security certificates from the security control center 300, and the security control center 300 will obtain the access control list of the microservices from the call analysis server 500 and distribute it to each security agent. When a call request is sent or received in the microservice client 200 and the microservice server 400, it will be intercepted by its own security agent, and the security certificate of the other party will be obtained to verify the identity of the other party. In addition, it is also necessary to verify the microservices to be called or called through the access control list distributed by the security control center 300. Only when the identity of the other party is legal and the microservices to be called or called meet the call relationship, the call request will be forwarded to the microservice client 200 or the microservice server 400 to ensure the communication security between the microservice client 200 and the microservice server 400.

[0102] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool, be used on demand, and is flexible and convenient. Cloud computing technology will become an important support. The background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture websites, and more portal websites. With the high development and application of the Internet industry, in the future, each item may have its own identification mark and needs to be transmitted to the background system for logical processing. Data at different levels will be processed separately, and various industry data requires the support of a powerful system background, which can only be achieved through cloud computing.

[0103] In some embodiments, the microservice server 400 and the call analysis server 500 can be independent physical servers, or a server cluster or distributed system composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms. The microservice server 400 can be a smartphone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto. The terminal and the server can be directly or indirectly connected through wired or wireless communication methods, and no limitation is made in the embodiments of the present invention.

[0104] See Figure 2 , Figure 2 is a schematic structural diagram of the microservice server 400 provided by the embodiments of the present application. Figure 2 The microservice server 400 shown includes: at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. Each component in the microservice server 400 is coupled together through a bus system 440. It can be understood that the bus system 440 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clear illustration, in Figure 2 all kinds of buses are labeled as the bus system 440.

[0105] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0106] The user interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons, and controls.

[0107] The memory 450 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard disk drives, optical disk drives, etc. The memory 450 optionally includes one or more storage devices that are physically remote from the processor 410.

[0108] The memory 450 includes volatile memory or non-volatile memory, and may also include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), and the volatile memory can be random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0109] In some embodiments, the memory 450 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which are described below by way of example.

[0110] The operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and handling hardware-based tasks;

[0111] The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420. Exemplary network interfaces 420 include: Bluetooth, Wi-Fi (Wireless Fidelity), and USB (Universal Serial Bus), etc.;

[0112] The presentation module 453 is used to enable the presentation of information (such as a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with the user interface 430 (such as a display screen, speaker, etc.);

[0113] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one of the one or more input devices 432.

[0114] In some embodiments, the apparatus provided by the embodiments of the present application may be implemented in software. Figure 2 Shown in the memory 450 is a microservice security control apparatus 455, which may be software in the form of a program, a plug-in, etc., and includes the following software modules: a first receiving module 4551, a first obtaining module 4552, a second obtaining module 4553, a third obtaining module 4554, and a first sending module 4555. These modules are logical, and thus can be arbitrarily combined or further split according to the functions implemented.

[0115] The functions of each module will be described below.

[0116] In other embodiments, the apparatus provided by the embodiments of the present application may be implemented in hardware. As an example, the apparatus provided by the embodiments of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the microservice security control method provided by the embodiments of the present application. For example, a processor in the form of a hardware decoding processor may employ one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), or other electronic components.

[0117] The microservice security control method provided by the embodiments of the present application will be described in conjunction with the exemplary applications and implementations of the microservice server provided by the embodiments of the present application.

[0118] See Figure 3 , Figure 3 is a schematic diagram of an implementation process of the microservice security control method provided by the embodiments of the present application. This method is applied to the server side. The following will describe the microservice security control method in conjunction with the Figure 3 steps shown.

[0119] Step S101, receive a call request sent by a client security proxy.

[0120] In an embodiment of the present application, security agents are installed on the client and the server respectively. That is to say, the security agent and the microservice are deployed in the same client device, which can be a physical device or a virtual machine. The microservice and the security agent communicate through localhost (local loopback address), and the communication data between the two does not enter the network. Therefore, the communication between the microservice and the security agent is secure and does not require authentication and encryption. When the microservice on the client sends a call request to the server, the client security agent intercepts the call request. The call request includes the server microservice identifier requested by the client to call. The client security agent determines whether the server microservice is a service relied on by the client microservice based on the server microservice identifier. When the server microservice requested to be called is a service relied on by the client microservice, the call request is sent to the server.

[0121] In an embodiment of the present application, a security agent is also installed in the server. Therefore, when step S101 is implemented, it is the server security agent that obtains, or intercepts, the call request.

[0122] Step S102: Obtain the client security certificate and verify the client security certificate to obtain a verification result.

[0123] In actual implementation, step S102 is executed by the server security agent. The server security agent can send a request message for obtaining the security certificate to the client security agent after receiving the call request. After receiving the request message, the client security agent sends its own security certificate to the server security agent. In some embodiments, the client security certificate can also be carried in the call request sent by the client security agent to the server security agent.

[0124] After obtaining the client certificate, the server security agent uses the root certificate pre-obtained from the security control center to verify the legitimacy of the client certificate to obtain a verification result.

[0125] Step S103: When the verification result is a successful verification based on the verification result, obtain the client microservice identifier based on the client security certificate.

[0126] The client security certificate can include the client microservice identifier to facilitate subsequent verification processes based on the client microservice identifier.

[0127] Step S104: Obtain the access control list of the server microservice. When it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the access control list, perform business processing on the call request to obtain a processing result.

[0128] When implementing the acquisition of the access control list of the server-side microservice, an access list acquisition request can be first sent to the security control center. After receiving the access list acquisition request sent by the server-side, the security control center acquires the identifier of the server-side, and based on the identifier of the server-side, acquires the access control list corresponding to the server-side, and then sends the access control list to the server-side. At this time, the server-side receives the access control list sent by the security control center, and the access control list includes the first microservice identifier set on which the server-side microservice depends and the second microservice identifier set that depends on the server-side microservice.

[0129] The services on which the server-side microservice depends, that is, the services that the server-side microservice can call, that is, the identifiers of the microservices that the server-side microservice can call included in the first microservice identifier set; the microservices that depend on the server-side microservice are also other services that can call the server-side microservice, that is, what is included in the second microservice identifier set is the microservice identifier that can call the server-side microservice. Therefore, when implementing, to determine whether the client-side microservice depends on the server-side microservice, it can be by judging whether the client-side microservice identifier is in the second microservice identifier set. When the client-side microservice identifier is in the second microservice identifier set, it indicates that the client-side microservice depends on the server-side microservice. At this time, the server-side security proxy sends the call request to the server-side microservice so that the server-side microservice performs corresponding business processing based on the call request to obtain the processing result.

[0130] Step S105: Send the processing result to the client-side security proxy.

[0131] When implementing step S105, it can be that after obtaining the processing result, the server-side microservice carries the processing result in the call response and sends it out. At this time, the call response carrying the processing result will be intercepted by the server-side security proxy. The interception methods include but are not limited to: destination address rewriting based on IPTables (DNAT, Network Address Translation), resolving the server-side address to the security proxy through the Domain Name System (DNS), specifying the security proxy address in the client-side microservice, etc. The server-side security proxy will determine whether the client-side microservice corresponding to the sent processing result is an external service that depends on the local microservice through the access control list. If so, it sends the processing result to the client-side security proxy; if not, it will not send the processing result to the client-side security proxy, thus ensuring the security of communication between microservices.

[0132] In the microservice security control method provided by the embodiments of this application, after receiving a call request sent by a client security proxy, obtain the client security certificate, and verify the client security certificate to obtain a verification result, where the call request includes the server microservice identifier requested by the client to call; when the verification result is successful based on the verification, obtain the client microservice identifier based on the client security certificate; obtain the access control list of the server microservice, and when it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the access control list, perform business processing based on the call request to obtain a processing result; finally, send the processing result to the client security proxy. In the embodiments of this application, after obtaining the call request, first verify the security certificate of the other party to determine whether the identity is legal, and then, in the case of a legal identity, further determine whether the client microservice depends on the server microservice through the access control list, and then perform business processing based on the call request, so as to ensure the security of microservice communication in a zero-trust microservice system.

[0133] In some embodiments, before step S101, the server also needs to obtain its own security certificate through the following steps:

[0134] Step S001, send a certificate acquisition request to the security control center.

[0135] The certificate acquisition request includes its own public key and microservice identifier; after receiving the certificate acquisition request, the security control center parses the certificate acquisition request to obtain the server's public key and microservice identifier, and then the security control center generates a service identity certificate according to the certificate acquisition request, signs it with its own private key, and returns it to the server security proxy.

[0136] Step S002, receive the server certificate returned by the security control center.

[0137] The server certificate is signed using the private key of the security control center. After receiving the server certificate, the server security proxy stores it in the local storage space.

[0138] Through the above steps S001 to S002, the server security proxy can obtain its own security certificate from the security control center, so as to perform identity verification through the security certificate when communicating with the client microservice.

[0139] It should be noted that the above steps S001 to S002 are the implementation process for the server security proxy to obtain its own security certificate. The process for the client security proxy to obtain the security certificate is similar and can refer to the above implementation process.

[0140] Based on the foregoing embodiments, an embodiment of the present application further provides a microservice security control method, which is applied to a client and a server. Figure 4 It is another schematic flowchart of the microservice security control method provided by the embodiment of the present application. As Figure 4 shown, the process includes:

[0141] Step S401, the client security proxy obtains a call request sent to the server.

[0142] Based on its own operation requirements, the client microservice issues a call request to call the server microservice. The client security proxy intercepts the call request to perform a legitimacy verification on the call request, where the legitimacy verification includes verification of the server identity and verification of the call relationship between the server microservice requested to be called and its own microservice. The call request includes the identifier of the server microservice requested to be called.

[0143] Step S402, the client security proxy determines whether the microservice requested to be called is a service it depends on.

[0144] In implementation, the client security proxy will pre-obtain a client access control list from the security control center. The client access control list includes a third microservice identifier set and a fourth microservice identifier set. Among them, the third microservice identifier set includes the identifiers of other external services that the client microservice can call, that is, the identifiers of the microservices that the client microservice depends on. The fourth microservice identifier set includes the identifiers of other external services that can call the client microservice, that is, the identifiers of the microservices that depend on the client microservice.

[0145] When implementing step S402, it can be determined whether the identifier of the server microservice requested to be called exists in the third microservice identifier set. If the identifier of the server microservice requested to be called exists in the third microservice identifier set, it is determined that the microservice requested to be called is a service it depends on, and at this time, step S404 is entered; if the identifier of the microservice requested to be called does not exist in the third microservice identifier set, it means that the microservice requested to be called is not a service it depends on, and at this time, step S403 is entered.

[0146] In some embodiments, before step S402, the client security proxy may also execute steps S411 and S412, that is, obtain the server security certificate and verify the server security certificate to obtain a verification result; when the verification result is successful verification, then step S402 is entered; when the verification result is verification failure, then step S403 is entered.

[0147] Step S403, the client security proxy outputs a prompt message indicating that the call request sending fails.

[0148] If it is determined that the microservice called by the request is not a service on which it depends, it indicates that the verification of the call relationship fails. At this time, the client security proxy will not send the call request to the server, but output a prompt message indicating that the call request sending fails. The prompt message may include the reason for the failure, so that the user can timely learn the reason for the failure and take targeted solutions.

[0149] Step S404, the client security proxy sends a call request to the server.

[0150] The call request sent by the client security proxy to the server will first be intercepted by the server security proxy, that is, the server security proxy receives the call request.

[0151] Step S405, the server security proxy obtains the client security certificate and verifies the client security certificate to obtain a verification result.

[0152] The client security certificate may be carried in the call request. In some embodiments, if the client security certificate is not carried in the call request, then the server security proxy will send a certificate acquisition request to the client security proxy to obtain the client security certificate.

[0153] When verifying the client security certificate, in implementation, the server security proxy may verify the client security certificate through the root certificate of the pre-obtained security control center to obtain the verification result.

[0154] Step S406, the server security proxy determines whether the verification result is successful verification.

[0155] When the verification result is verification failure, go to step S407; when the verification result is successful verification, go to step S408.

[0156] Step S407, the server security proxy sends a notification message indicating call failure to the client security proxy.

[0157] The notification message may carry the reason for the call failure, which may be that the client authentication fails or the call relationship verification fails.

[0158] Step S408, the server security proxy obtains the client microservice identifier based on the client security certificate.

[0159] Step S409, the server security proxy obtains the access control list of the server microservice.

[0160] The access control list can be obtained by the server security proxy from the security control center in advance, or can be obtained from the security control center after receiving the call request. The access control list includes a first microservice identifier set on which the server microservice depends and a second microservice identifier set that depends on the server microservice.

[0161] Step S410, the server security proxy determines whether the client microservice identifier exists in the second microservice identifier set.

[0162] When the client microservice identifier exists in the second microservice identifier set, it is determined that the client microservice depends on the server microservice, and at this time, step S411 is entered. When the client microservice identifier does not exist in the second microservice identifier set, step S407 is entered.

[0163] Step S411, the server microservice performs business processing based on the call request to obtain a processing result.

[0164] Step S412, the server sends the processing result to the client security proxy.

[0165] Step S413, after receiving the processing result, the client security proxy obtains the server security certificate and verifies the server security certificate to obtain a verification result.

[0166] The server security certificate can be sent to the client security proxy together with the processing result. If the server security certificate is not sent to the client security proxy together with the processing result, then the client security proxy can send a certificate acquisition request to the server security proxy to obtain the server security certificate, and verify the server security certificate based on the root certificate of the security control center to obtain a verification result.

[0167] Step S414, the client security proxy determines whether the verification result is verification successful.

[0168] When the verification result is verification successful, step S415 is entered; when the verification result is verification failed, step S419 is entered.

[0169] Step S415, the client security proxy obtains the server microservice identifier based on the client security certificate.

[0170] Step S416, the client obtains the access control list of the client microservice.

[0171] The access control list of the client microservice includes a third microservice identifier set and a fourth microservice identifier set. Among them, the third microservice identifier set includes the identifiers of other external services that the client microservice can call, that is, the identifiers of the microservices on which the client microservice depends. The fourth microservice identifier set includes the identifiers of other external services that can call the client microservice, that is, the identifiers of the microservices that depend on the client microservice.

[0172] Step S417: The client determines whether the server microservice is a service on which it depends based on the server microservice identifier.

[0173] When implementing step S417, it can be to determine whether the server microservice identifier exists in the third microservice identifier set. If the identifier of the server microservice requested to be called exists in the third microservice identifier set, it is determined that the microservice requested to be called is a service on which it depends, and at this time, step S418 is entered; if the server microservice identifier does not exist in the third microservice identifier set, it means that the microservice requested to be called is not a service on which it depends, and at this time, step S419 is entered.

[0174] Step S418: The client security proxy sends the processing result to the client microservice.

[0175] After receiving the processing result, the client microservice performs subsequent processing based on the processing result.

[0176] Step S419: The client security proxy discards the processing result.

[0177] When the client security proxy discards the processing result, it can be to delete the processing result. In some embodiments, after discarding the processing result, the client security proxy can also send a notification message to the client microservice to notify the client microservice that the processing result acquisition fails, and the client microservice determines whether to send a call request again.

[0178] In the microservice security control method provided in the embodiments of the present application, when a client microservice needs to call a server microservice, it sends a call request to the server. The call request is first intercepted by the client security proxy, and the call relationship verification of the server microservice is performed. When the call relationship is legal, the client security proxy sends the call request. The call request sent to the server will be intercepted by the server security proxy, and the identity verification and call relationship verification of the client microservice will be performed. Only when both the identity and the call relationship are verified, the call request will be transmitted to the server microservice through the local return address, so that the server microservice can perform business processing on the call request to obtain a processing result, and then send the processing result to the client. After receiving the processing result, the client security proxy performs similar identity verification and call relationship verification. When both the identity and the call relationship are verified, the processing result is transmitted to the client microservice. In this way, both the client and the server will perform call relationship and identity verification after receiving the call information, so as to ensure communication security in a zero-trust network environment.

[0179] In some embodiments, both the client security proxy and the server security proxy can perform the following steps:

[0180] Step S301, obtain service call information.

[0181] Here, when steps S301 and S302 are implemented by the server security proxy, the service call information includes the call to the server microservice and other microservices called by the server microservice; when steps S301 and S302 are implemented by the client security proxy, the service call information includes the call to the client microservice and other microservices called by the client microservice.

[0182] Step S302, send the service call information to the call analysis server, so that the call analysis server generates a second call relationship graph based on the service call information.

[0183] When sending the service call information to the call analysis server, it can be sent to the call analysis server in real time every time the service call information is obtained, or it can be sent to the call analysis server at regular intervals for the service call information within this period of time, so that the call analysis server generates a dynamic second call relationship graph based on the service call information.

[0184] Based on the foregoing embodiments, the embodiments of the present application further provide a microservice security control method, which is applied to Figure 1 the network architecture shown in Figure 5A This is a schematic implementation flow diagram of the microservice security control method provided in the embodiments of the present application, as shown in Figure 5AAs shown in the figure, the process includes:

[0185] Step S501, when the analysis server detects an update to the microservice code library, code construction is performed based on the microservice source code in the microservice code library.

[0186] Here, an update to the microservice code library can be the addition of new microservice source code, the deletion of existing microservice source code, or the modification of existing microservice source code. Code construction for the microservice source program can include code static checking, code compilation, unit testing, integration testing, etc. During the code construction process for the microservice source program, if one of the links fails, the code construction fails, and the analysis server will send the reason for the construction failure to the code library or the development terminal; when all links are successfully executed, the code construction is successful, and then step S502 is executed.

[0187] Step S502, when the code construction is successful, the analysis server scans and analyzes each microservice source code to obtain the call relationships between the microservices.

[0188] When implementing step S502, the analysis server can analyze the statements regarding remote method calls in the microservice source code to obtain the call relationships between the microservices.

[0189] For example, there are five microservices, namely microservice A, microservice B, microservice C, microservice D, and microservice E. The call relationships between these five microservices are that microservice C calls microservice A, microservice A calls microservice D, microservice D calls microservice B, and microservice B calls microservice E.

[0190] Step S503, the analysis server generates a first call relationship diagram based on the call relationships between the microservices.

[0191] When generating the first call relationship diagram based on the call relationships between the microservices, the arrow can point to the called microservice. Continuing with the above example, according to the call relationships that microservice C calls microservice A, microservice A calls microservice D, microservice D calls microservice B, and microservice B calls microservice E, generate Figure 5B the first call relationship diagram shown.

[0192] Step S504, the analysis server sends the first call relationship diagram to the security control center.

[0193] Step S505, the security control center determines the access control list for each microservice based on the first call relationship diagram.

[0194] At implementation, the microservice identifiers that each microservice can call and the microservice identifiers that call each microservice can be determined through the first call relationship graph. Taking microservice B as an example, the set of microservice identifiers that microservice B can call includes: microservice E, and the set of microservice identifiers that can call microservice B includes: microservice D.

[0195] Step S506, the client and server of the microservice send a certificate acquisition request to the security control center.

[0196] At implementation, the client and server do not send the certificate acquisition request to the security control center simultaneously. Based on the actual execution conditions of the client and server, a suitable timing can be determined to send the certificate acquisition request to the security control center.

[0197] Step S507, the security control center generates security certificates for the client and server of the microservice based on the certificate acquisition request.

[0198] After obtaining the certificate acquisition request, the security control center generates the corresponding security certificate, signs it using its own private key, and returns it to the security proxy of the client or server.

[0199] Step S508, the security control center sends the security certificates to the client and server of the microservice respectively.

[0200] Step S509, the client obtains the call request sent to the server.

[0201] Here, when the client microservice needs to call the server microservice during execution, a call request is sent. This call request will be intercepted by the client security proxy. That is, in step S509, it can be the client security proxy that obtains the call request sent by the client microservice to the server.

[0202] Step S510, the client security proxy determines whether the microservice requested to be called is a service it depends on.

[0203] Here, when the microservice requested to be called is a service it depends on, it proceeds to step S511. In some embodiments, when the microservice requested to be called is not a service it depends on, the client does not send a call request to the server, and the process ends at this time. This processing branch Figure 5A is not shown.

[0204] Step S511, the client security proxy sends a call request to the server.

[0205] Step S512, the server obtains the client security certificate and verifies the client security certificate to obtain a verification result.

[0206] In implementation, after the client security proxy sends a call request to the server, the server security proxy intercepts the call request first, obtains the client security certificate, and then verifies the client security certificate through the root certificate of the security control center to obtain a verification result.

[0207] Step S513, the server determines whether the verification result is verification success.

[0208] In implementation, it can be the server security proxy that determines whether the verification result is verification success. Among them, when the verification result is verification success, it enters step S514; when the verification result is verification failure, it enters step S517.

[0209] Step S514, the server security proxy obtains the client microservice identifier based on the client security certificate.

[0210] Step S515, the server security proxy obtains the access control list of the server microservice. When it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the access control list, business processing is performed based on the call request to obtain a processing result.

[0211] In some embodiments, when it is determined that the client microservice does not depend on the server microservice based on the client microservice identifier and the access control list, step S517 is executed.

[0212] Step S516, the server sends the processing result to the client security proxy.

[0213] In some embodiments, after step S516, S413 to step S419 can be executed.

[0214] Step S517, the server returns a notification message of call failure to the client.

[0215] In some embodiments, the notification message may further include the reason for call failure. For example, it can be that the call relationship verification fails, or it can be that the authentication fails.

[0216] Step S518, the client and server of the microservice respectively send service call information to the call analysis server.

[0217] Here, the client and server can send it to the call analysis server in real time every time a service call relationship is obtained. In some embodiments, it can also be that service call information obtained during a certain period is sent to the call analysis server at intervals.

[0218] Step S519, the call analysis server generates a second call relationship graph based on the service call information.

[0219] Continuing with the above example, assume that the service call information obtained by invoking the analysis service is as follows: microservice A invokes microservice D, microservice D invokes microservice B, and microservice B invokes microservice E. Then, at this time, a second call relationship graph G531 as shown in Figure 5C is generated.

[0220] In the embodiments of the present application, the process of generating the first call relationship graph by statically analyzing the microservice source code is completed by the call analysis server, and the process of generating the dynamic second call relationship graph by actual service call information is also completed. In some embodiments, the static call analysis process can also be completed by one server, and the dynamic call analysis process can be completed by another server.

[0221] Step S520, the scheduling analysis server uses a preset security policy to verify each call relationship in the second call relationship graph, and obtains the verification results of each call relationship.

[0222] In actual implementation, the preset security policy in the expert knowledge base is used to verify each call relationship in the second call relationship graph. This security policy can be pre-built into the system or input by an expert through the user interface. The conditions for security policy judgment can include the attributes of any service.

[0223] When using the security policy to verify each call relationship in the second call relationship graph in sequence, the verification result of each call relationship will be obtained. Continuing with the above example, for example, the verification result of the call relationship where microservice A invokes microservice D is verification passed, the verification result of the call relationship where microservice D invokes microservice B is verification failed, and the verification result of the call relationship where microservice B invokes microservice E is verification passed.

[0224] Step S521, when it is determined that there is a call relationship with a verification result of verification failed, the scheduling analysis server updates the second call relationship graph to obtain an updated second call relationship graph.

[0225] When the call analysis server updates the second call relationship graph based on the verification results of each call relationship, it can automatically delete the call relationships with verification failed, so as to obtain an updated second call relationship graph. Continuing with the above example, according to the verification results obtained in step S520, the Figure 5C shown second call relationship graph G531 is updated to obtain an updated second call relationship graph G532.

[0226] Step S522, the scheduling analysis server sends the updated second call relationship graph to the security control center, so that the security control center updates the access control list of each microservice based on the updated second call relationship graph.

[0227] In some embodiments, after receiving the updated second call relationship graph, the security control center updates the first call relationship graph based on the second call relationship graph to obtain an updated first call relationship graph, and updates the access control list of each microservice based on the updated first call relationship graph.

[0228] In the microservice security control method provided by the embodiments of the present application, the call analysis server performs static scanning and analysis on the microservice source code in the code library to obtain a static first call relationship graph, and then sends the first call relationship graph to the security control center. The security control center determines the access control list of each microservice based on the first call relationship graph. The client and the server will apply to the security control center for their own security certificates. After the security control center generates the security certificates of the client and the server, it sends them to the client and the server, and issues the access control list of each microservice. When the client microservice needs to call the server microservice, before sending out the call request, the client security proxy performs call relationship verification. After the verification passes, the call request is sent to the server. The server performs client identity verification and call relationship verification, and after both verifications pass, it performs business processing based on the call request and returns the processing result to the client. In this way, the security of communication between the client and the server microservices can be achieved. After that, the client and the server will send service call information to the call analysis server. The call analysis server determines a dynamic second call relationship graph based on the actual service call information, and verifies each call relationship in the second call relationship graph based on the security policy. If there is a call relationship that fails the verification, the second call relationship graph is updated, and the updated second call relationship graph is sent to the security control center, so that the security control center updates the access control list of each microservice based on the updated second call relationship graph, thereby ensuring that the call relationship reflected in the access control list is not only in line with the code logic, but also meets the security policy, further improving communication security.

[0229] In some embodiments, after step S520, the following steps may also be executed:

[0230] Step S521’, when it is determined that there is a call relationship with a verification result of failed verification, update the first call relationship graph to obtain an updated first call relationship graph.

[0231] Since the actual service call information between the client and the server is obtained under the restriction of the access control list generated based on the first call relationship graph, and the second call relationship graph can also be considered as a sub-graph of the first call relationship graph, the call relationships existing in the second call relationship graph must exist in the first call relationship graph. Therefore, when implementing step S521’, it can be to delete the call relationships with the verification result of “verification failed” in the first call relationship graph to obtain the updated first call relationship graph.

[0232] Step S522’, send the updated first call relationship graph to the security control center so that the security control center can update the access control lists of each microservice based on the updated first call relationship graph.

[0233] In step S522’, the updated first call relationship graph is directly sent to the security control center. The security control center can update the access control list through the updated first call relationship graph, thereby ensuring the security of the corresponding call relationships in the access control list and further ensuring the communication security between microservices.

[0234] In some embodiments, the above step S503 “The call analysis server generates a first call relationship graph based on the call relationships between the microservices” can be implemented through the following steps:

[0235] Step S5031, the call analysis service determines whether there are circular calls between the microservices based on the call relationships between the microservices.

[0236] When there are no circular calls between the microservices, step S5032 is executed. In some embodiments, when it is determined that there are circular calls, a first warning message is output, and the first warning message is used to prompt for microservice code logic inspection; then it is monitored whether the microservice code library has been updated, and when it is monitored that the microservice code library has been updated, it is transferred to step S501.

[0237] Step S5032, the call analysis server generates a first call relationship graph based on the call relationships between the microservices.

[0238] Since when executing step S5032, it is executed on the premise that there are no circular calls between the microservices, the first call relationship graph obtained at this time is a directed acyclic graph.

[0239] In some embodiments, the above step S521 “When it is determined that there is a call relationship with a verification result of verification failed, the scheduling analysis server updates the second call relationship graph to obtain an updated second call relationship graph” has two implementation methods: automatic update and manual update.

[0240] When it is a manual update, it is implemented through the following steps:

[0241] Step S5201A, when it is determined that there is a call relationship with a verification result of failed verification, output a second warning message.

[0242] This second warning message includes at least the call relationship information with failed verification.

[0243] Step S5202A, receive an update operation for the call relationship with failed verification.

[0244] This update operation can be an operation to delete the call relationship with failed verification, or it can be to change the call relationship.

[0245] Step S5203A, in response to the update operation, update the second call relationship graph to obtain an updated second call relationship graph.

[0246] When it is an automatic update of the second call relationship graph, it is implemented through the following steps:

[0247] Step S5201B, when it is determined that there is a call relationship with a verification result of failed verification, delete the call relationship with failed verification from the second call relationship graph to obtain an updated second call relationship graph.

[0248] That is to say, automatically updating the second call relationship graph means directly deleting the call relationship with failed verification to obtain an updated second call relationship graph, and then sending the updated second call relationship graph to the security control center. The security control center updates the access control list of each microservice based on the updated second call relationship graph to ensure the accuracy of the access control list.

[0249] Next, an exemplary application of the embodiments of the present application in an actual application scenario will be described.

[0250] Since the cloudified microservice deployment brings security challenges in the zero-trust network, and the traditional identity authentication and encryption solutions have some defects. To solve this problem, a security control method for a microservice system under a zero-trust network is provided in the embodiments of the present application.

[0251] When this method is implemented, as Figure 6 shown, it includes two parts: a development state 601 and a running state 602. The development state includes microservice source code 6011, a service call relationship static analyzer 6012, and a static dependency relationship graph 6013. The running state 602 includes a security control center 6021, a security proxy 6022, a service call relationship dynamic analyzer 6023, an expert knowledge base 6024, and microservices 6025.

[0252] As Figure 6As shown, in the development state 601 part, the microservice source code 6011 is the input for analyzing the call relationship, that is, the microservice source code 6011 is input into the service call relationship static analyzer 6012, and the static dependency relationship graph 6013 is output.

[0253] Among them, the microservice source code 6011 can be written in various different programming languages, including but not limited to JAVA, Golang, Python, C, etc. The service call relationship static analyzer 6012 scans the input source code, finds the call statements related to remote calls, and analyzes the call relationship between each microservice based on the call statements. Under normal circumstances, the call relationship should be a directed acyclic graph. If a cycle occurs in the analyzed call relationship (that is, the static dependency relationship graph 6013 is a directed cyclic graph), the developer needs to be reminded to check the logic of the microservice source code 6011, modify the business logic, or reasonably split the microservice to avoid cycles. The service call relationship static analyzer 6012 can be deployed in the continuous build process. After the developer submits the code, it will trigger the execution of the service call relationship analyzer to automatically generate the static dependency relationship graph 6013 and add the static dependency relationship graph 6013 to the version package.

[0254] In the running state 602 part, the security control center 6021 mainly includes two functions: First, generate an access list for each microservice instance according to the static dependency relationship graph 6013 of the microservice. Only other microservices that depend on this microservice are included in the access list. Second, issue a security certificate for each microservice. The security certificate can adopt the x.509 standard, which contains the identity information and public key of the microservice.

[0255] In the embodiment of this application, a security proxy 6022 is deployed on the host where the microservice 6025 instance is located (it can also adopt deployment methods such as virtual machines or Kubernetes Pods, as long as the proxy and the microservice can access each other through localhost). The security proxy 6022 intercepts the outgoing requests of the microservice to the outside and the incoming requests from the outside to this microservice, and performs identity authentication and communication encryption on the inter-service access. Due to the method of proxy intercepting requests, the processing of identity authentication and communication encryption is transparent to the microservice process, and no changes need to be made to the business code of the microservice.

[0256] The call relationship graph obtained by static analysis is only a service call relationship reflected by the code. Due to code failures, this call relationship may be incorrect or incomplete. At the same time, some service access policies may be dynamically adjusted according to the running environment during runtime. Therefore, a dynamic service call relationship analyzer 6023 is also included during runtime. The security proxy 6022 sends all service call information generated during the running process, including successful calls and calls blocked by the security proxy, to the dynamic service call relationship analyzer 6023 to dynamically analyze the call relationship between microservices. Then, the expert knowledge base 6024 further analyzes the obtained call relationship and issues corresponding security warnings according to the analysis results to notify the operation and maintenance personnel for handling and manually update the service dependency graph; or the expert knowledge base 6024 can automatically update the service dependency graph according to the analysis results; then the security control center regenerates the access list for each microservice instance according to the updated service dependency graph and distributes it to the security proxy.

[0257] That is to say, in the development state, a service relationship dependency analyzer (service call static relationship analyzer) is used to analyze the source code of each microservice in the same software system to generate a call relationship graph between microservices. In the running state, the call relationship graph is input into the security control center. The security control center generates an access control list for each running microservice instance according to the call relationship, and distributes this access list and the security certificate of the microservice to the security proxy of the microservice together. Requests initiated and received by the microservice externally will be intercepted by the security proxy, and the security proxy controls the access between microservices.

[0258] Figure 7 It is a schematic diagram of the implementation process of the static analysis of the call relationship graph in the development state provided by the embodiment of the present application. As Figure 7 shown, this process includes:

[0259] Step S701, the developer submits the microservice source code to the code repository.

[0260] Here, the code repository is a server for storing project source code, and source code management software such as Git and SVN can be used.

[0261] Step S702, trigger the code continuous build process.

[0262] The build server detects changes in the code in the code repository. When the code is submitted, the code build process will be triggered. The process can include but is not limited to the following actions: code static check, code compilation, unit test, integration test, etc.

[0263] Step S703, determine whether the build is successful.

[0264] Here, if the build is successful, proceed to step S704; if the build is not successful, end the process. In the embodiments of the present application, determining whether the build is successful can be to determine that all the execution actions in step S702 are executed successfully. When all the execution actions are executed successfully, it is determined that the build is successful; when there is an action that is not executed successfully, it is determined that the build fails.

[0265] Step S704, analyze the service call relationship.

[0266] When implementing step S704, it can be achieved by analyzing and scanning the source code, analyzing the statements regarding remote method calls in the source code to construct a call relationship graph.

[0267] Step S705, determine whether there is a circular call.

[0268] Here, if there is no circular call, proceed to step S706; if there is a circular call, end the process.

[0269] Step S706, use the build result to create a version package.

[0270] When implementing, add the call relationship graph generated in step S704 to the version package for use in the running state.

[0271] Figure 8 It is a schematic diagram of the implementation process for the initialization / updating process of the security proxy in the running state provided by the embodiments of the present application. As Figure 8 shown, this process includes:

[0272] Step S801, the security proxy requests the identity certificate of its proxy service from the certificate center in the security control center.

[0273] The security proxy needs to carry the public key and the identity information of the service, such as the service name, in the request.

[0274] Step S802, the certificate center generates the service identity certificate according to the request of the security proxy, signs it with its own private key, and returns it to the security proxy.

[0275] Step S803, the security proxy requests the authorization list from the policy center in the security control center.

[0276] The authorization list includes two parts: which other services can be accessed by the local service, and which other services can access the local service.

[0277] Step S804, the policy center analyzes the dependency graph, and finds other services that the service depends on, and other services that depend on this service, according to the dependency graph.

[0278] Step S805: The policy center generates an authorization list and returns it to the security proxy.

[0279] It should be noted that in steps S801 to S805, the communication between the security proxy and the security control center must be authenticated and encrypted to prevent a third party from forging the identities of the two communication parties or stealing information during the communication process. A common way to implement authentication and encryption is to pre-set a security certificate for the security control center and the security proxy respectively. The security proxy needs to verify the identity of the other party during the communication establishment process with the certificate center and encrypt the data during the communication process.

[0280] Figure 9 This is a schematic diagram of the access between running microservices provided by an embodiment of the present application. As Figure 9 shown, the microservice and the security proxy are deployed on a local host (or virtual machine, Linux network space, and similar network isolation mechanisms). The microservice and the security proxy communicate through the localhost (local loopback address), and the data packet does not enter the network. Therefore, the communication between the microservice and the security proxy is secure and does not require authentication and encryption. The mutual access between different microservices is carried out through the security proxy. At the client 901, the security proxy intercepts the outgoing call of the client microservice and initiates a request to the server-side microservice on behalf of the microservice; at the server-side 902, the security proxy intercepts the incoming call sent to the server-side, and after performing a security verification, forwards the request to the server-side.

[0281] Figure 10 This is a schematic diagram of the implementation process of remote calls and security authentication between microservices in the running state provided by an embodiment of the present application. As Figure 10 shown, the process includes:

[0282] Step 1001: The client microservice initiates a call request to the server-side microservice.

[0283] The data packet of the call request carries the identifier of the server-side microservice, such as the service name passed through the HTTP header.

[0284] Step S1002: The client security proxy intercepts the call request.

[0285] There are various ways to implement the interception, including but not limited to: DNAT (Destination Network Address Translation) based on IPTables, resolving the server-side address to the security proxy through DNS (Domain Name System), specifying the security proxy address in the client microservice, etc.

[0286] Step S1003: The client security proxy determines whether the microservice belongs to an external service on which the local microservice depends.

[0287] Here, the client security proxy parses the name of the server-side microservice from the request and determines whether this microservice belongs to an external service on which the local microservice depends. If it does not belong to the service on which the local microservice depends, it is determined that the access is illegal, and the process ends at this time; if this microservice belongs to an external service on which the local microservice depends, it proceeds to step S1004.

[0288] Step S1004, the client security proxy initiates a call request to the server-side microservice.

[0289] Step S1005, the server-side microservice intercepts the call request.

[0290] There are various implementation methods for interception, including but not limited to: DNAT (Destination Network Address Translation) based on IPTables, resolving the server-side address to the security proxy through DNS (Domain Name System), specifying the security proxy address in the client microservice, and so on.

[0291] Step S1006, the security proxies of both sides of the call exchange their security certificates with each other.

[0292] In implementation, after obtaining the security certificate of the other party, the root certificate of the security control center is used to perform a legality check on the security certificate. If the check fails, the process ends; otherwise, it proceeds to step S1007.

[0293] Step S1007, the server-side security proxy obtains the name of the client microservice from the client certificate and determines whether this microservice is an external service that depends on the local microservice.

[0294] If the client microservice does not depend on the local service, it is an illegal access, and the process ends; otherwise, it proceeds to step S1008.

[0295] Step S1008, the server-side security proxy forwards the request to the server-side microservice for business processing.

[0296] After the server-side performs business processing to obtain the processing result, the processing result is returned to the client microservice according to the reverse process.

[0297] The following combines Figure 11 to illustrate the dynamic analysis process of the call relationship diagram in the running state. As Figure 11 shown, this process includes:

[0298] Step S1101, the security proxy reports the call information of the microservice during operation to the call relationship dynamic analyzer.

[0299] Step S1102, the service call relationship dynamic analyzer aggregates the call information reported by the security proxy to generate a dynamic call relationship diagram of the system.

[0300] Step S1103, analyze the call relationship graph using an expert knowledge base.

[0301] Step S1104, update the legal call relationship dependency graph output by the expert knowledge base analysis to the security control center.

[0302] Step S1105, the security control center adopts Figure 6 the process in

[0303] In some embodiments, the above step S1103 can be implemented by steps S11031 to S11035 as shown in Figure 12 , and the following steps are described in conjunction with Figure 12 .

[0304] Step S11031, take out the next one from the dynamic call relationships to be analyzed for analysis.

[0305] Step S11032, determine whether the call relationship conforms to the security policy.

[0306] When implementing step S11032, the rules in the expert knowledge base can be used for judgment. These rules can be pre-built or input by experts through the user interface. The conditions for rule judgment can include the attributes of any service. For example, an expert rule based on the deployment cluster of a service is as follows: Services in the test cluster are not allowed to access services in the production environment.

[0307] If the call relationship conforms to the security policy, go to step S11034; otherwise, go to step S11033.

[0308] Step S11033, if it is determined that the security policy is not met, issue a security warning to notify the operation and maintenance personnel for handling, and manually update the service dependency graph; or the expert knowledge base can automatically update the service dependency graph according to the analysis results.

[0309] Step S11034, determine whether there are still call relationships to be analyzed.

[0310] If there are call relationships to be analyzed, go to step S11031; otherwise, go to step S11035.

[0311] Step S11035, generate a legal call relationship dependency graph.

[0312] Here, service calls that do not conform to the security policy are removed from the generated call relationship dependency graph. After obtaining the legal call relationship dependency graph, the security control center regenerates the access list for each microservice instance according to the updated legal call relationship dependency graph and distributes it to the security proxy.

[0313] The security control method based on microservices provided by the embodiments of the present application can be applied to microservice systems in traditional data centers, microservice systems on public clouds, and of course, can also be applied to microservice systems on hybrid cloud architectures. This security control method uses a service relationship dependency analyzer to analyze the source code of each microservice in the same software system, generating a call relationship graph between microservices. In the running state, the call relationship graph is input into the security control center, and the security control center generates an access control list for each running microservice instance according to the call relationship, and distributes this access control list and the security certificate of the microservice to the security proxy of the microservice. When requests initiated and received by the microservice are intercepted by the security proxy, the security proxy performs security control on the access between microservices; in this way, service identity authentication and secure communication in a "zero trust" network can be achieved without intrusion into the microservice application, which not only has high security but also has no coupling with the application, and there is no need to transform the existing microservices.

[0314] Next, continue to describe the exemplary structure of the microservice security control device 455 provided by the embodiments of the present application as software modules. In some embodiments, as Figure 2 shown, the software modules in the microservice security control device 455 stored in the memory 440 may include:

[0315] A first receiving module 4551, configured to receive a call request sent by a client security proxy, where the call request includes an identifier of a server-side microservice requested to be called by the client;

[0316] A first obtaining module 4552, configured to obtain a client security certificate and verify the client security certificate to obtain a verification result;

[0317] A second obtaining module 4553, configured to, when the verification result is successful based on the verification result, obtain a client microservice identifier based on the client security certificate;

[0318] A third obtaining module 4554, configured to obtain an access control list of the server-side microservice, and when it is determined that the client microservice depends on the server-side microservice based on the client microservice identifier and the access control list, perform service processing based on the call request to obtain a processing result;

[0319] A first sending module 4555, configured to send the processing result to the client security proxy.

[0320] In some embodiments, the apparatus further comprises:

[0321] A third sending module, configured to send a certificate acquisition request to a security control center, where the certificate acquisition request includes its own public key and a microservice identifier;

[0322] A second receiving module, configured to receive the server certificate returned by the security control center, where the server certificate is signed using the private key of the security control center.

[0323] In some embodiments, the third acquisition module is further configured to:

[0324] Send an access list acquisition request to the security control center;

[0325] Receive the access control list sent by the security control center, where the access control list includes a first microservice identifier set on which the server microservice depends and a second microservice identifier set that depends on the server microservice.

[0326] In some embodiments, the apparatus further comprises:

[0327] A second determination module, configured to determine whether the client microservice identifier exists in the second microservice identifier set;

[0328] A third determination module, configured to determine that the client microservice depends on the server microservice when the client microservice identifier exists in the second microservice identifier set.

[0329] In some embodiments, the apparatus further comprises:

[0330] A fourth acquisition module, configured to acquire service call information within a preset duration, where the service call information includes calling the server microservice and other microservices called by the server microservice;

[0331] A fourth sending module, configured to send the service call information to a call analysis server, so that the call analysis server generates a second call relationship graph based on the service call information.

[0332] It should be noted here that: The description of the above embodiments of the microservice security control apparatus is similar to the above method description and has the same beneficial effects as the method embodiments. For the technical details not disclosed in the embodiments of the microservice security control apparatus of the present application, those skilled in the art may refer to the description of the method embodiments of the present application for understanding.

[0333] The embodiments of the present application further provide a microservice security control device, which is stored in the storage memory of the call analysis server. The software modules in the microservice security control device may include:

[0334] A construction module, configured to perform code construction based on the microservice source code in the microservice code library when it is monitored that the microservice code library is updated;

[0335] A scanning and analysis module, configured to perform scanning and analysis on each microservice source code to obtain the call relationships between the microservices when the code construction is successful;

[0336] A first generation module, configured to generate a first call relationship graph based on the call relationships between the microservices;

[0337] A second sending module, configured to send the first call relationship graph to the security control center, so that the security control center determines the access control list of each microservice based on the first call relationship graph.

[0338] In some embodiments, the device further includes:

[0339] A fifth acquisition module, configured to acquire the service call information sent by each security proxy;

[0340] A second generation module, configured to generate a second call relationship graph based on the service call information;

[0341] A verification module, configured to verify each call relationship in the second call relationship graph by using a preset security policy to obtain the verification result of each call relationship;

[0342] A first update module, configured to update the second call relationship graph to obtain an updated second call relationship graph when it is determined that there is a call relationship with a verification result of failed verification;

[0343] In some embodiments, the device further includes:

[0344] A fifth sending module, configured to send the updated second call relationship graph to the security control center, so that the security control center updates the access control list of each microservice based on the updated second call relationship graph; or,

[0345] A second update module, configured to update the first call relationship graph to obtain an updated first call relationship graph when it is determined that there is a call relationship with a verification result of failed verification;

[0346] A sixth sending module, configured to send the updated first call relationship graph to the security control center, so that the security control center updates the access control list of each microservice based on the updated first call relationship graph.

[0347] In some embodiments, the first generation module is further configured to:

[0348] Based on the call relationships between the respective microservices, determine whether there are circular calls between the respective microservices;

[0349] When there are no circular calls, generate a first call relationship graph based on the call relationships between the respective microservices.

[0350] In some embodiments, the apparatus further includes:

[0351] A first output module, configured to output a first warning message when it is determined that there are circular calls, where the first warning message is used to prompt a check of the microservice code logic;

[0352] An update monitoring module, configured to monitor whether the microservice code library has been updated.

[0353] In some embodiments, the second update module is further configured to:

[0354] When it is determined that there are call relationships with a verification result of failed verification, output a second warning message, where the second warning message at least includes the call relationship information with failed verification;

[0355] Receive an update operation for the call relationship with failed verification;

[0356] In response to the update operation, update the second call relationship graph to obtain an updated second call relationship graph; or,

[0357] When it is determined that there are call relationships with a verification result of failed verification, delete the call relationships with failed verification from the second call relationship graph to obtain an updated second call relationship graph.

[0358] It should be noted here that: The description of the above embodiments of the microservice security control device is similar to the above method description and has the same beneficial effects as the method embodiments. For the technical details not disclosed in the embodiments of the microservice security control device of the present application, those skilled in the art may refer to the description of the method embodiments of the present application for understanding.

[0359] An embodiment of the present application provides a computer program product or a computer program, where the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the microservice security control method described above in the embodiments of the present application.

[0360] An embodiment of the present application provides a computer-readable storage medium storing executable instructions, where the executable instructions, when executed by a processor, cause the processor to execute the method provided by the embodiment of the present application. For example, as Figure 3 , Figure 4 , Figure 5A shown in the method.

[0361] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or it may be various devices including one or any combination of the above memories.

[0362] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0363] As an example, the executable instructions may or may not correspond to a file in the file system, and may be stored as part of a file that stores other programs or data. For example, they may be stored in one or more scripts in a Hyper Text Markup Language (HTML) document, stored in a single file dedicated to the program in question, or stored in multiple cooperating files (e.g., files that store one or more modules, subroutines, or code portions).

[0364] As an example, the executable instructions may be deployed to execute on one computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network.

[0365] As described above, the above are only embodiments of the present application and are not intended to limit the protection scope of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A microservice security control method, characterized in that, Including: Receiving a call request sent by a client security proxy, where the call request includes a server microservice identifier requested by the client to call; The call request is a request that has passed the call relationship verification by the client security proxy; Obtaining a client security certificate and verifying the client security certificate to obtain a verification result; When the verification result is successful verification, obtaining a client microservice identifier based on the client security certificate; Sending an access list acquisition request to a security control center; Receiving the access control list sent by the security control center, where the access control list includes a first microservice identifier set on which the server microservice depends and a second microservice identifier set that depends on the server microservice. When it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the second microservice identifier set in the access control list, performing business processing on the call request to obtain a processing result; Sending the processing result to the client security proxy.

2. The method according to claim 1, wherein The method further includes: Sending a certificate acquisition request to the security control center, where the certificate acquisition request includes its own public key and microservice identifier; Receiving the server security certificate returned by the security control center, where the server security certificate is signed using the private key of the security control center.

3. The method according to claim 1, characterized in that, The method further includes: Determining whether the client microservice identifier exists in the second microservice identifier set; When the client microservice identifier exists in the second microservice identifier set, determining that the client microservice depends on the server microservice.

4. The method according to any one of claims 1 to 3, characterized in that The method further includes: Obtaining service call information, where the service call information includes calling the server microservice and other microservices called by the server microservice; Sending the service call information to a call analysis server so that the call analysis server generates a second call relationship graph based on the service call information.

5. A microservice security control method, characterized in that, The method includes: When it is monitored that the microservice code library is updated, performing code construction based on the microservice source code in the microservice code library; When the code construction is successful, scanning and analyzing each microservice source code to obtain the call relationship between each microservice; Generating a first call relationship graph based on the call relationship between each microservice; Sending the first call relationship graph to the security control center so that the security control center determines the access control list for each microservice based on the first call relationship graph, and when receiving an access list acquisition request sent by the server, sending the access control list corresponding to the server microservice to the server; the access control list corresponding to the server microservice includes a first microservice identifier set on which the server microservice depends and a second microservice identifier set that depends on the server microservice, so that when the server determines that the client microservice depends on the server microservice based on the client microservice identifier and the second microservice identifier set, performing business processing based on the call request.

6. The method according to claim 5, characterized in that, The method further includes: Obtaining service call information sent by each security proxy; Generate a second call relationship graph based on the service call information; Verify each call relationship in the second call relationship graph using a preset security policy to obtain the verification result of each call relationship; When it is determined that there is a call relationship with a verification result of failed verification, update the second call relationship graph to obtain an updated second call relationship graph.

7. The method according to claim 6, characterized in that The method further includes: Send the updated second call relationship graph to the security control center so that the security control center updates the access control list of each microservice based on the updated second call relationship graph; or, When it is determined that there is a call relationship with a verification result of failed verification, update the first call relationship graph to obtain an updated first call relationship graph; Send the updated first call relationship graph to the security control center so that the security control center updates the access control list of each microservice based on the updated first call relationship graph.

8. The method according to claim 5, characterized in that The generating a first call relationship graph based on the call relationships between the microservices includes: Based on the call relationships between the microservices, determine whether there is a circular call between the microservices; When there is no circular call, generate a first call relationship graph based on the call relationships between the microservices.

9. The method according to claim 8, wherein The method further includes: When it is determined that there is a circular call, output a first warning message for prompting a microservice code logic check; Monitor whether the microservice code library has been updated.

10. The method according to claim 6, wherein The when it is determined that there is a call relationship with a verification result of failed verification, update the second call relationship graph to obtain an updated second call relationship graph includes: When it is determined that there is a call relationship with a verification result of failed verification, output a second warning message, where the second warning message at least includes the call relationship information with failed verification; Receive an update operation for the call relationship with failed verification; In response to the update operation, update the second call relationship graph to obtain an updated second call relationship graph; or, When it is determined that there is a call relationship with a verification result of failed verification, delete the call relationship with failed verification from the second call relationship graph to obtain an updated second call relationship graph.

11. A microservice security control device, characterized in that, Includes: A first receiving module for receiving a call request sent by a client security proxy, where the call request includes an identifier of a server-side microservice requested to be called by the client; The call request is a request that has passed the call relationship verification by the client security proxy; A first obtaining module for obtaining a client security certificate and verifying the client security certificate to obtain a verification result; A second obtaining module for, when the verification result is successful verification, obtaining a client microservice identifier based on the client security certificate; A third obtaining module for sending an access list obtaining request to the security control center; Receive the access control list sent by the security control center. The access control list includes a first microservice identifier set on which the server microservice depends and a second microservice identifier set that depends on the server microservice. When it is determined that the client microservice depends on the server microservice based on the client microservice identifier and the second microservice identifier set in the access control list, perform business processing based on the call request to obtain a processing result; A first sending module, configured to send the processing result to the client security proxy.

12. A microservice security control device, characterized in that, Comprising: A construction module, configured to perform code construction based on the microservice source code in the microservice code library when it is detected that the microservice code library is updated; A scanning and analysis module, configured to perform scanning and analysis on each microservice source code to obtain the call relationships between the microservices when the code construction is successful; A first generation module, configured to generate a first call relationship graph based on the call relationships between the microservices; A second sending module, configured to send the first call relationship graph to the security control center, so that the security control center determines the access control list of each microservice based on the first call relationship graph, and when receiving an access list acquisition request sent by the server, send the access control list corresponding to the server microservice to the server; The access control list corresponding to the server microservice includes a first microservice identifier set on which the server microservice depends and a second microservice identifier set that depends on the server microservice, so that when the server determines that the client microservice depends on the server microservice based on the client microservice identifier and the second microservice identifier set, perform business processing based on the call request.

13. A microservice security control device, characterized in that, Comprising: A memory, configured to store executable instructions; A processor, configured to implement the method according to any one of claims 1 to 4 or any one of claims 5 to 10 when executing the executable instructions stored in the memory.

14. A computer-readable storage medium, characterized in that, Stored with executable instructions, configured to implement the method according to any one of claims 1 to 4 or any one of claims 5 to 10 when being executed by a processor.

15. A computer program product, comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer executable instructions are executed by a processor, the method according to any one of claims 1 to 4 or any one of claims 5 to 10 is implemented.

Images