Microservice secure access method and system, device, and storage medium

Abstract

Embodiments of the present invention provide a microservice secure access method and system, a device, and a storage medium. In the embodiments of the present invention, proxy modules are injected into services to achieve a single-port dual-protocol function, and automatic secure upgrade of links is implemented by the proxy modules, thereby avoiding traffic loss during upgrade; an authorization control node automatically generates authorization policy information of each service on the basis of trust level data and a call relationship and issues the authorization policy information to the corresponding proxy module, thereby avoiding manual configuration of authorization rules and establishing systematic authorization rules; and furthermore, an authorization defense node collects and analyzes an illegitimate access request and adaptively adjusts the authorization policy information, thereby implementing an active defense capability of a system, and improving the recognition and defense efficiency of the illegitimate access request.

Description

Microservice secure access method, system, device and storage medium Technical Field

[0001] The present disclosure relates to the field of cloud computing technology, and in particular to a microservice secure access method, system, device, and storage medium. Background Art

[0002] Microservice Architecture is a software development architecture model that divides an application into a group of small services. Each service runs in an independent process. The services communicate with each other using lightweight communication mechanisms, coordinate and cooperate with each other, and provide complete application functions to the outside world.

[0003] To ensure the security of microservices, we hope to introduce zero-trust technology into the microservices architecture. Zero trust is a new generation of network security protection concept. It defaults to distrusting any object inside or outside the network. All objects must establish a secure access foundation based on identity authentication and authorization to ensure link security, device security, and access control security.

[0004] However, the microservice architecture itself has a certain degree of complexity. The complexity of introducing zero-trust security into the microservice architecture will increase exponentially. There is an urgent need for a solution to reduce the complexity of implementing zero-trust technology in the microservice architecture.

[0005] Summary of the Invention

[0006] Various aspects of the present disclosure provide a microservices secure access method, device, system, and storage medium to reduce the complexity of introducing zero-trust technology into a microservices architecture and simplify the implementation of zero-trust in a microservices architecture.

[0007] An embodiment of the present disclosure provides a microservice security access system, comprising: an authentication control node, an authentication defense node, and a proxy module, wherein the proxy module is injected into multiple services and shares the service port of the service to which it belongs; the proxy module in any service is configured to perform a full-link security upgrade for the service in a full-link upgrade mode based on the protocol type and access direction of the access requests sent and received by the service port of the service, and enter a security authentication mode when a full-link upgrade completion condition is met; and, in the security authentication mode, perform security authentication on access requests received by the service port of the service in accordance with authentication policy information issued by the authentication control node, and report illegal access requests that fail security authentication to the authentication defense node for updating the authentication policy information; the authentication control node is configured to generate authentication policy information for the service in accordance with the trust data and call relationship information of the service, and issue the information to the proxy module in the service; the authentication defense node is configured to update the authentication policy information of at least one service related to the illegal access request when the illegal access request meets the authentication defense condition, and synchronize the information to the proxy module in the at least one service.

[0008] The disclosed embodiment also provides a microservice security access method, which is applicable to a proxy module injected into any service, and the proxy module shares the service port of any service, including: in a full-link upgrade mode, performing a full-link security upgrade on any service according to the protocol type and access direction of the access request sent and received by the service port of any service, and entering a security authentication mode when the full-link upgrade completion condition is met; in a security authentication mode, performing a security authentication on the access request received by the service port of any service according to the authentication policy information issued by the authentication control node, and reporting the illegal access request that fails the security authentication to the authentication defense node so that the authentication defense node can update the authentication policy information; wherein, the authentication policy information is generated based on the trust data and call relationship information of any service.

[0009] The disclosed embodiment also provides a microservice security access method applicable to an authentication and control node, including: obtaining the trust data and call relationship information of any service, wherein the any service is injected into a proxy module, and the proxy module shares the service port of the any service; generating authentication policy information of the any service based on the trust data and call relationship information of the any service; and sending the authentication policy information of the any service to the proxy module in the any service, so that the proxy module can perform security authentication on the access request received by the service port in a security authentication mode.

[0010] An embodiment of the present disclosure further provides an electronic device, comprising: a memory and a processor; the memory is used to store a computer program, and the processor is coupled to the memory and is used to execute the computer program to implement the steps in the above method.

[0011] An embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above method.

[0012] In the disclosed embodiment, the single-port dual-protocol function is realized by injecting a proxy module into each service, and the proxy module realizes the automatic security upgrade of the link to avoid traffic loss during the upgrade process; and the authentication control node automatically generates the authentication policy information of each service according to the trust data and the call relationship and sends it to the proxy module, thereby avoiding manual configuration of the authentication rules and forming a systematic authentication rule; further, the authentication defense node collects and analyzes illegal access requests, and adaptively adjusts the authentication policy information to realize the active defense capability of the system, thereby improving the recognition and defense efficiency of illegal access requests. The proxy module, the authentication control node and the authentication defense node cooperate with each other, which not only solves the problem of introducing zero-trust technology in the microservice architecture, but also combines the single-port dual-protocol and automatic generation and update of authentication rules, greatly reducing the complexity of introducing zero-trust technology in the microservice architecture and simplifying the implementation of zero-trust in the microservice architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The exemplary embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0014] FIG1 is a schematic diagram of the structure of a microservice secure access system provided by an exemplary embodiment of the present disclosure;

[0015] FIG2 is a schematic diagram of a process of full-link security upgrade provided by an exemplary embodiment of the present disclosure;

[0016] FIG3 is a schematic diagram of a process of performing two-way identity authentication between any service provided by another exemplary embodiment of the present disclosure and another service serving as a request receiving end or a request sending end;

[0017] FIG4a is a schematic diagram of an initial topological relationship of service calls in a microservice architecture provided by another exemplary embodiment of the present disclosure;

[0018] FIG4 b is a schematic diagram of a topological relationship of service calls after authentication policy information is updated in a microservice architecture provided by another exemplary embodiment of the present disclosure;

[0019] FIG4c is a schematic diagram of an initial topological relationship of a service call of a newly added service L in a microservice architecture provided by another exemplary embodiment of the present disclosure;

[0020] FIG4 d is a schematic diagram of a topological relationship of service calls after a newly added service L updates authentication policy information in a microservice architecture provided by another exemplary embodiment of the present disclosure;

[0021] FIG5 is a flowchart of a microservice secure access method provided by another exemplary embodiment of the present disclosure;

[0022] FIG6 is a flowchart of a microservice secure access method provided by another exemplary embodiment of the present disclosure;

[0023] FIG7 is a schematic structural diagram of a microservice security access device provided by an exemplary embodiment of the present disclosure;

[0024] FIG8 is a schematic structural diagram of another microservice security access device provided by an exemplary embodiment of the present disclosure;

[0025] FIG9 is a schematic structural diagram of an electronic device provided by an exemplary embodiment of the present disclosure;

[0026] FIG10 is a schematic structural diagram of another electronic device provided by yet another exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0027] To make the objectives, technical solutions, and advantages of the present disclosure more clear, the technical solutions of the present disclosure will be clearly and completely described below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present disclosure.

[0028] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0029] Because microservice architectures are inherently complex, the complexity of introducing zero-trust security into a microservice architecture increases exponentially, especially when the microservice architecture scales up. The complexity of introducing zero-trust security into a microservice architecture is particularly complex, primarily in the following aspects:

[0030] First, the issue of upgrading the transmission link: The basic capability of zero trust is to upgrade each call link in the microservice architecture from insecure plaintext transmission to relatively secure ciphertext transmission. Taking the Hypertext Transfer Protocol (HTTP), the calling protocol between services, as an example, if you want to introduce zero trust technology in the microservice architecture, you need to set the call link between all services to Hypertext Transfer Protocol Secure (HTTPS). In the embodiment of the present disclosure, the authentication method used by HTTPS is not limited. For example, the mutual Transport Layer Security (mTLS) method can be used, but is not limited to it.

[0031] How to securely upgrade the call paths between all services in a microservices architecture is a major technical challenge. An ideal approach would be to shut down all services, upgrade their HTTP ports to HTTPS, and then restart all services to complete the transmission link upgrade. However, shutting down all services is impractical, as this would render the entire microservices architecture inoperable for a period of time. A more practical approach would be to sequentially integrate services within the microservices architecture with zero-trust capabilities, gradually upgrading the security of the call paths between services. However, this introduces new challenges. If, in a call path from service A to service B, service B's service port has been upgraded to HTTPS, but service A's port has not yet been integrated with zero-trust capabilities, and service A continues to call service B using HTTP, service B will report an error and be unable to provide service A, resulting in traffic loss. Therefore, in a solution where services are sequentially integrated with zero-trust capabilities, how to incrementally upgrade the security of all services to meet zero-trust requirements without losing traffic is a major technical challenge.

[0032] Second, there's the issue of implementing systematic authentication rules: Zero Trust also requires secure authentication of access requests. This means that when zero trust is introduced into a microservices architecture, when service A accesses service B, service B must authenticate service A, and service A can only call service B after passing service B's security authentication. This requires configuring a complete set of authentication rules within the microservices call architecture that meet zero trust requirements. The inherent complexity of microservices architectures complicates the configuration and management of authentication rules. Therefore, automatically implementing a comprehensive set of systematic authentication rules based on the unique characteristics of microservices architectures to meet zero trust requirements is another major technical challenge.

[0033] Third, there's the issue of dynamic defense in security authentication: Zero trust requires continuous authentication and authorization. Traditional solutions typically employ static authentication rules to passively defend against security risks, often without adaptive defense or countermeasures against malicious calls. To further ensure the security of relatively complex microservices architectures, it's necessary to provide a technical means to continuously collect and analyze the level of trust between current services and their environments, while maintaining their efficient operation, so as to adaptively implement proactive defense or countermeasures. This presents another major technical challenge in introducing zero trust into microservices architectures.

[0034] After the above analysis and continuous research, the inventors of the present disclosure provide a microservice security access system, which includes an authentication control node, an authentication defense node and an agent module. These components work together to not only solve the implementation problem of zero-trust technology in the microservice architecture, but also reduce the complexity of implementing zero-trust technology in the microservice architecture.

[0035] Among them, the proxy module is injected into each service as a functional module in the service, and shares the original service port of the service to which it belongs, realizing the function of single-port dual-protocol. With the help of the proxy module, in the full-link upgrade mode, the services in the microservice architecture are securely upgraded according to the protocol type and access direction of the access request of the service port, and the full-link upgrade completion conditions are set, allowing the proxy module to realize automatic security upgrade of the link without manual intervention, avoiding traffic loss during the upgrade process.

[0036] Furthermore, a secure authentication mode is set up, automatically entering secure authentication mode upon completion of the full-link upgrade. In secure authentication mode, the proxy module collaborates with the authentication control node and the authentication defense node. The authentication control node generates authentication policy information based on the service's trust data and call relationships and sends it to the proxy module. The proxy module then securely authenticates service access requests based on the authentication policy information sent by the authentication control node, implementing systematic authentication rules.

[0037] On the other hand, the proxy module reports the illegal access requests that fail to pass authentication to the authentication defense node, which updates the authentication policy information of the relevant services and synchronizes it to the proxy module in the relevant services. On the basis of the passive defense of the proxy module according to the authentication policy information, active defense and counterattack are implemented.

[0038] The technical solutions provided by various embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0039] Figure 1 is a schematic diagram of the structure of a microservice secure access system provided by an exemplary embodiment of the present disclosure. As shown in Figure 1, the system 10 includes an authentication defense node 11, an authentication control node 12, and an agent module 13. For simplicity and ease of description, the "agent module" may be referred to as "agent" in some descriptions.

[0040] In a microservice architecture, the same application may be split into multiple services, and different services of the same application coordinate and cooperate with each other to provide complete application functions to the outside world. Of course, services between different applications may also need to work together. Furthermore, each service can be deployed on one or more computing nodes, and the same service deployed on different computing nodes can be called different instances of the service, and these instances provide exactly the same service. In addition, the embodiments of the present disclosure do not limit the deployment environment of the service. The service can be deployed in a variety of environments, for example, it can be deployed in an ECS (Elastic Compute Service) environment, or it can be deployed in a Kubernetes (K8s) environment.

[0041] In the embodiment of the present disclosure, the agent as a functional module of the service can be pre-injected into each service in the microservice architecture to perform a security upgrade of the transmission link for these services. These services can come from the same application or from different applications. The embodiment of the present disclosure is described in terms of services, and the specific instance of the service to be injected into the agent can be injected. In addition, because the agent belongs to the functional module of the service, it can share the service port of the service to which it belongs. With the help of the link upgrade capability of the agent, the function of a single port supporting dual protocols at the same time can be realized, which is referred to as single-port dual-protocol. The single-port dual-protocol here means that the same service port can support both the non-secure transmission protocol before the link upgrade and the secure transmission protocol after the link upgrade. In this way, support for two transmission protocols is achieved on the same service port. During the link security upgrade process, there is no need to switch the service port, which can avoid traffic loss caused by switching the service port. In the embodiment of the present disclosure, the process of injecting the agent into the service can be referred to as mounting the agent on the service.

[0042] In the disclosed embodiments, the implementation method for mounting the agent on the service is not limited. In an optional embodiment, bytecode technology can be used to add the agent's bytecode to the service's bytecode file during the service startup process to achieve the purpose of mounting the agent on the service. Further optionally, the microservice architecture is deployed using Kubernetes (K8s) technology. In this K8s environment, the agent is deployed before the application container (the container that carries the application process) runs by using the initialization container mechanism. The initialization container is a special container that is started before the application container is started to complete the pre-conditions required by the application. During the initialization process, the agent's bytecode is downloaded to the initialization container. In this way, the agent's bytecode can be accessed and loaded during the application container startup process, thereby achieving the agent's mounting on the service. In this embodiment, the time for injecting the agent into each service is not limited and can be flexibly determined according to the startup time of each service. In addition, since the agent is mounted during the application container startup process, there is no need to restart the application container, and the service will not be interrupted due to mounting the agent, which is conducive to ensuring service quality.

[0043] In this embodiment, the agent has two working modes, one is the full-link upgrade mode, and the other is the security authentication mode. These two modes are also the two working stages of the agent. Among them, in the full-link upgrade mode, the agent is responsible for completing the security upgrade of the call link between services. After completing the link security upgrade, it automatically enters the security authentication mode. In the security authentication mode, it is responsible for performing security authentication on access requests to the service to which it belongs. Furthermore, during the security authentication process, the agent cooperates with the authentication control node and the authentication defense node. The authentication control node is responsible for providing authentication policy information to the agent, and the authentication defense node is responsible for collecting illegal access requests reported by the agent and updating the authentication policy information based on the illegal access requests to achieve active defense and counterattack of security authentication. The following is an introduction to the functions of the agent, authentication control node, and authentication defense node in combination with the working process of the agent in the two modes. It should be noted that the functions and working principles of the agent in any service are the same or detailed, so in the following embodiments, the agent in any service is used as an example for explanation.

[0044] The proxy module is injected during the startup process of any service. The proxy module in any service is started when any service is started. After startup, it first enters the full-link upgrade mode. In the full-link upgrade mode, the proxy module can intercept the access requests sent and received on the service port of any service it belongs to based on its ability to share the service port of any service. It can also perform a full-link security upgrade for any service based on the protocol type and access direction of the access requests sent and received by the service port of any service. Among them, the full-link upgrade mode is defined from the perspective of the entire system. It refers to a working mode that upgrades the call link between any two services with a call relationship from an insecure transmission protocol to a secure transmission protocol. For the proxy module in any service, it is necessary to complete the security upgrade of the call link where any service is located, that is, the process of upgrading the transmission protocol used by any service on any call link from an insecure transmission protocol to a secure transmission protocol. The call link where any service is located includes the transmission link between other services and any service when other services call the service, and also includes the transmission link between any service and other services when the service calls other services. Of course, the transmission link can also be called a call link.

[0045] Among them, according to the upgrade of the service on the call link, the protocol type of the access request received by any service on its service port may be the protocol type before the upgrade or the protocol type after the upgrade, for example, it may be an HTTP request or an HTTPS request; accordingly, the protocol type of the access request that any service hopes to send through its service port may also be the protocol type before the upgrade or the protocol type after the upgrade, for example, it may be an HTTP request or an HTTPS request. Among them, HTTP is a non-secure transmission protocol, HTTPS is a secure transmission protocol, and HTTP and HTTPS are only examples of non-secure transmission protocols and secure transmission protocols, and do not constitute a limitation of this disclosure. In addition, the access direction of the access request refers to the transmission direction of the access request relative to the service port, including the inbound direction and the outbound direction. The inbound direction refers to the direction of the request flowing into the service port. The access request sent by other services to any service belongs to the inbound direction access request. The outbound direction refers to the direction of the request flowing out of the service port. The access request sent by any service to other services belongs to the outbound direction access request. For the proxy module in any service, the full-link security upgrade of any service can be performed based on the protocol type and access direction of the access request.

[0046] Furthermore, in the embodiment of the present disclosure, a full-link upgrade completion condition can be configured to allow the proxy module in any service to self-identify whether the full-link security upgrade of any service is completed. When it is determined that the full-link upgrade completion condition is met, it means that the transmission protocols used by each call link associated with any service have completed the upgrade. At this time, the security authentication mode can be automatically entered. In the embodiment of the present disclosure, the full-link upgrade completion condition is not limited and can be flexibly set according to application requirements. It is sufficient as long as the proxy module can self-identify whether the full-link security upgrade of any service is completed based on the condition. It is explained here that in the full-link upgrade mode, since there is no authentication policy information, the proxy module will not perform security authentication on the received access requests, and all received access requests will be directly released by default.

[0047] After the full-link upgrade is completed, it enters the security authentication mode. In the security authentication mode, the proxy module of any service is mainly used to perform security authentication on the access request received by the service port of any service according to the authentication policy information issued by the authentication control node, and report the illegal access request that fails the security authentication to the authentication defense node to update the authentication policy information. Correspondingly, the authentication control node is used to generate the authentication policy information of any service based on the trust data and call relationship information of any service, and issue it to the proxy module in any service. The authentication defense node is used to update the authentication policy information of at least one service related to the illegal access request when the illegal access request meets the authentication defense conditions, and synchronize it to the proxy module in the at least one service.

[0048] As shown in Figure 1, in the embodiment of the present disclosure, the single-port dual-protocol function is realized by injecting a proxy module into each service (service A, service B, and service C are illustrated as examples in Figure 1), and the proxy module realizes the automatic security upgrade of the link to avoid traffic loss during the upgrade process; and the authentication control node automatically generates the authentication policy information of each service based on the trust data and the call relationship and sends it to the proxy module, avoiding manual configuration of authentication rules and forming a systematic authentication rule; further, the authentication defense node collects and analyzes illegal access requests, adaptively adjusts the authentication policy information, realizes the active defense capability of the system, and improves the recognition and defense efficiency of illegal access requests. The proxy module, authentication control node, and authentication defense node cooperate with each other, which not only solves the problem of introducing zero-trust technology in the microservice architecture, but also combines single-port dual-protocol, automatic generation and automatic update of authentication rules, greatly reducing the complexity faced by introducing zero-trust technology in the microservice architecture and simplifying the implementation of zero-trust in the microservice architecture.

[0049] Figure 2 is a schematic diagram of the process of full-link security upgrade provided by an exemplary embodiment of the present disclosure. In this embodiment, it is assumed that the HTTP protocol was called between services before the introduction of zero-trust technology, and after the introduction of zero-trust technology, the services need to be upgraded to the HTTPS protocol. At the same time, it is assumed that the identity authentication method used by the HTTPS protocol on the transmission link is mTLS. In this scenario, the proxy module in the service needs to upgrade the various call links of the service to which it belongs from plaintext transmission to mTLS transmission. The protocol types and identity authentication methods mentioned in the above or following embodiments are only examples and do not limit the present disclosure.

[0050] In this embodiment, the microservices architecture includes multiple services. These services can receive access requests from clients outside the microservices architecture, receive access requests from other services within the microservices architecture, and may also issue access requests to other services within the microservices architecture. Access requests issued by clients can be forwarded to the corresponding services via a gateway device. Before the introduction of zero-trust technology, non-secure transmission protocols, such as HTTP, were used between services or between clients and services by default. Figure 2 shows the initial state before upgrading the transmission links between services. Figure 2 shows services A, B, and C. Service A includes instances deployed on two computing nodes, denoted as Service A Instance 1 and Service A Instance 2, respectively. Service B includes instances deployed on different computing nodes, denoted as Service B Instance 1 and Service B Instance 2, respectively. Service C includes an instance deployed on a single computing node, denoted as Service C Instance 1. The number of services and the number of instances contained in these services are examples and do not constitute a limitation of the disclosed technical solution. Furthermore, as shown in Figure 2, the call links between instances of services A, B, and C, as well as between the gateway device and the instance of service A, all use the HTTP protocol.

[0051] As each service starts, the agent will be injected during the startup process of each service. The agent shares the service port of the service to which it belongs. In addition, as the service starts, the agent enters the full-link upgrade mode by default and performs a security upgrade on the call link of the service to which it belongs in the full-link upgrade mode.

[0052] In the full-link upgrade mode, the agent in any service intercepts access requests sent and received on the service port of the service to which it belongs. Optionally, the above access request can come from a client outside the microservice architecture, or it can be a call request between other services within the microservice architecture. The other services here can belong to the same or different applications as any of the above services, and there is no limitation on this. Taking any service as an example, the agent in any service can not only intercept access requests received by the service port, but also intercept access requests issued by the service port. Specifically, it can distinguish whether it is an access request received by the service port or an access request issued by the service port based on the access direction of the intercepted access request.

[0053] If the access direction of the intercepted access request is inbound, that is, if the access request is received by the service port, the agent can parse the intercepted access request to obtain the value of the protocol field. The value of the protocol field will vary depending on the protocol type, so the protocol type of the access request can be identified based on the value of the protocol field. For example, when the value of the protocol field meets the first value condition, the protocol type of the intercepted access request is determined to be a secure protocol type; when the value of the protocol field meets the second value condition, the protocol type of the intercepted access request is determined to be a non-secure protocol type. In the embodiment shown in Figure 2, HTTPS is the secure protocol type and HTTP is the non-secure protocol type. The method for identifying whether the protocol type of the access request is HTTP or HTTPS includes: reading the first three bytes of the access request and determining whether the three bytes satisfy the following conditions: the first byte is 22 and the second byte is less than 3, or the first byte is 22, the second byte is 3, and the third byte is 0. If so, the access request is determined to be an HTTPS request; otherwise, the access request is determined to be an HTTP request. Among them, the first byte is 22 and the second byte is less than 3, or the first byte is 22 and the second byte is equal to 3 and the third byte is equal to 0 belongs to the first value condition, and other cases belong to the second value condition.

[0054] Furthermore, when an access request received by a service port is intercepted and the protocol type of the access request is a secure protocol type, such as HTTPS, it means that the service sending the access request has completed the link security upgrade. Therefore, the proxy module can obtain the digital certificate of any service from the authentication and control node, and based on the digital certificate of any service, perform a security upgrade on the transmission link between any service and other services that are the request senders. The security upgrade process mainly refers to the process of completing identity authentication between any service and other services that are the request senders and obtaining the key used to decrypt the access request from other services that are the request senders in the process, and then using the key to decrypt the access request and provide it to any service. In the embodiments of the present disclosure, the method of encrypting and decrypting the access request is not limited. It can be a symmetric encryption method or an asymmetric encryption method. Accordingly, the keys used for encryption and decryption will also be different. There is no limitation on this, and the embodiments of the present disclosure support both. Accordingly, when an access request received by a service port is intercepted and the protocol type of the access request is a non-secure protocol type, such as HTTP, the proxy module in any service can directly report the access request to any service.

[0055] When the access direction of the intercepted access request is outbound, that is, when the access request that needs to be sent by the service port is intercepted, the agent can determine whether the other services that are the request receiving end have completed the link upgrade. When the other services that are the request receiving end have completed the link upgrade, the agent module can obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and the other services that are the request receiving end based on the digital certificate of any service. The security upgrade process mainly refers to the process of completing identity authentication between any service and the other services that are the request sending end, encrypting the access request in the process, and providing the key used to decrypt the access request to the other services that are the request receiving end so that the other services can decrypt the access request and report it to the corresponding service. Accordingly, when the access request that needs to be sent by the service port is intercepted, and the other services that are the request receiving end have not completed the link upgrade, the agent module in any service can directly send the access request to the other services that are the request receiving end.

[0056] Furthermore, the system provided by the present disclosure may also include a service registration center. The service registration center is used to provide identity registration services for each service in the microservice architecture. Specifically, the service registration center can receive identity registration requests initiated by any service, generate and maintain service details for each service based on the identity registration requests, and dynamically update the service details for each service based on changes in the status of each service. The service details for each service include the identity metadata of the service and information on whether the link upgrade has been completed.

[0057] Optionally, the proxy module can obtain service details information of a certain service from the service registration center, and determine whether the link upgrade has been completed for a certain service based on the service details information (whether the link upgrade has been completed can be simply referred to as whether zero trust is connected). For example, service details information of other services that serve as request receiving ends are obtained from the service registration center, and the service details information includes information on whether the other services that serve as request receiving ends have completed the link upgrade; based on the service details information, determine whether the other services that serve as request receiving ends have completed the link upgrade.

[0058] Optionally, the authentication and control node can also obtain the identity metadata corresponding to any service from the service registration center, generate a digital certificate for any service based on the identity metadata corresponding to any service, and send the digital certificate of any service to the proxy module in any service according to the request of the proxy module.

[0059] In this embodiment, for the proxy module in any service, when any service initiates an access request to another service, it can proactively determine the link upgrade status of the subsequent service and drive itself to upgrade the link if the subsequent service has completed the link upgrade. Similarly, when receiving an access request from another service, it can also proactively identify the protocol type of the received access request and drive itself to upgrade the link if the received access request is of a secure protocol type, thereby achieving a bidirectional link upgrade. Preferably, the full link upgrade process can be gradually upgraded from the end of the scheduling link forward, but is not limited to this. The call links of multiple services can also be upgraded in parallel to speed up the service upgrade process.

[0060] Continuing with reference to FIG2 , assuming that instance 1 of service C has completed the link upgrade in advance, when instance 1 of service B accesses instance 1 of service C, the proxy module in instance 1 of service B can intercept the access request and identify whether instance 1 of service C has completed the link upgrade. When it is identified that instance 1 of service C has completed the link upgrade, the digital certificate of service B can be pulled from the authentication and control node, and security authentication (including encryption of the access request) can be performed with instance 1 of service C based on the digital certificate. At this point, instance 1 of service B has completed the link upgrade. For instance 1 of service C, when receiving the access request sent by instance 1 of service B, its proxy module can determine the protocol type of the access request. When it identifies that the protocol type is HTTPS, since instance 1 of service C has completed the link upgrade, security authentication (including decryption of the access request) can be performed with instance 1 of service B based on its digital certificate.

[0061] Furthermore, assuming that after instance 1 of service B completes the link upgrade, instance 1 of service A needs to access instance 1 of service B. At this time, the proxy module in instance 1 of service A can intercept the access request and identify whether instance 1 of service B has completed the link upgrade. When it is identified that instance 1 of service B has completed the link upgrade, it can pull the digital certificate of service A from the authentication and control node, and perform security authentication (including encryption of the access request) with instance 1 of service B based on the digital certificate. At this time, instance 1 of service A completes the link upgrade. For instance 1 of service B, when receiving the access request sent by instance 1 of service A, its proxy module can determine the protocol type of the access request. When it identifies that the protocol type is HTTPS, since instance 1 of service B has completed the link upgrade, it can perform security authentication (including decryption of the access request) with instance 1 of service A based on its digital certificate.

[0062] Furthermore, if instance 2 of service A needs to access instance 2 of service B, since instance 2 of service B has not yet completed the link upgrade, the proxy module in instance 2 of service A can intercept the access request and identify whether instance 2 of service B has completed the link upgrade. If it is determined that instance 2 of service B has not completed the link upgrade, the proxy module can directly send the access request, such as an HTTP request, to instance 2 of service B. For instance 2 of service B, upon receiving the access request sent by instance 2 of service A, its proxy module can determine the protocol type of the access request. If it is determined that the protocol type is HTTP, it can report it to instance 2 of service B, which will then directly process the access request.

[0063] Furthermore, during the link upgrade process of instance 1 of service B, instance 2 of service A needs to access instance 1 of service B. In this case, the proxy module in instance 2 of service A can intercept the access request and identify whether instance 1 of service B has completed the link upgrade. If it is identified that instance 1 of service B has not completed the link upgrade, the access request, such as an HTTP request, can be directly sent to instance 1 of service B. For instance 1 of service B, upon receiving the access request sent by instance 2 of service A, its proxy module can determine the protocol type of the access request. When it is identified that the protocol type is HTTP, it can directly report to instance 1 of service B, and instance 1 of service B will directly process the access request. It can be seen from this that the service port of the same service can process both HTTP requests and HTTPS requests, thereby achieving lossless switching of traffic. That is to say, in the full-link upgrade mode, for services that have completed the link upgrade, single-port dual protocols will be supported (that is, both HTTP and HTTPS protocols will be supported). In this way, for a service that has completed the link upgrade, when instances of other services call instances of this service, if they perceive that the instance of this service has completed the link upgrade, they will use the HTTPS protocol to call the service; if they do not perceive that the instance of this service has completed the link upgrade, they will use the HTTP protocol to call the service. Regardless of whether it is an HTTPS access request or an HTTP access request, since the service supports single-port dual protocols, it can process both types of access requests, avoiding traffic loss and achieving lossless traffic upgrade.

[0064] As time goes by, the call links between services are continuously upgraded, resulting in the intermediate state of link security upgrade as shown in Figure 2. Instance 1 of service C has completed the link upgrade, while instances of services A and B have partially completed the upgrade. The shaded instances in Figure 2 are the instances that have completed the upgrade.

[0065] As shown in Figure 2, instance 1 of service C completes the link upgrade first. At this point, an instance of service B (e.g., instance 1) first senses that service C has completed the link upgrade when requesting service from instance 1 of service C, and then drives itself to complete the link upgrade. Furthermore, instance 1 of service A first senses that instance 1 of service B has completed the link upgrade when requesting service from instance 1 of service B, and then drives itself to complete the link upgrade. This continues in this manner until all links have completed the upgrade, resulting in the final state of the link upgrade shown in Figure 2. At this point, the calling method between all instances has switched to the HTTPS security protocol.

[0066] It should be noted that after the security upgrade of the entire link is completed, the proxy module in each service will intercept the access requests of non-secure protocol types (such as HTTP requests) issued by the service to which it belongs, and upgrade the intercepted access requests to access requests of secure protocol types (such as HTTPS requests), and then use the identity authentication method supported by the secure transmission protocol to complete the secure transmission process with the other end.

[0067] It should be noted that in the above and following embodiments, "service completes link upgrade" and "service accesses Zero Trust" are different expressions of the same meaning. In this embodiment, the proxy module will intercept the service's call to the subsequent service and determine whether the subsequent service has accessed Zero Trust. If the subsequent service has accessed Zero Trust, the transmission link will be upgraded to a secure state and two-way authentication will be completed based on digital certificates. If the subsequent service has not accessed Zero Trust, the request will remain as a non-secure protocol type.

[0068] In an optional embodiment, when the proxy module in any of the above-mentioned services performs a security upgrade on the transmission link between any service and other services serving as request receivers or request senders based on the digital certificate of any service, it performs a two-way identity authentication on any service and other services serving as request receivers or request senders based on the digital certificate of any service. When both the two-way identity authentication are passed, it is determined that the security upgrade of the transmission link between any service and other services serving as request receivers or request senders is completed.

[0069] As shown in Figure 3, it is a schematic diagram of the process of two-way identity authentication between any service and other services as request receivers or request senders, using the HTTPS protocol as an example, wherein any service can be specifically implemented as the client or server in the figure, and other services can be implemented as the counterpart of any service, i.e., the server or client. The proxy module in the client upgrades the intercepted access request to an HTTPS request, and initiates an HTTPS connection establishment request to the server. The server responds to the HTTPS connection establishment request and returns the server's digital certificate to the client; the client verifies whether the server's digital certificate is legal, and if the verification passes, sends the client's digital certificate to the server; the server verifies whether the client's digital certificate is legal, and if the client's digital certificate passes the verification, the two parties successfully shake hands. When the two-way identity authentication is successful, the client and server transmit data through an encrypted TLS connection. The data transmission process is not shown in the figure.

[0070] In the embodiment of the present disclosure, in order to facilitate the proxy module to self-identify whether the full link in the microservice architecture has completed the upgrade, a full-link upgrade completion condition is set, and the full-link upgrade completion condition is not limited. In an optional embodiment, an active time threshold K1 and an inert time threshold K2 can be set, and the active time threshold K1 and the inert time threshold K2 are used as a specific implementation of the full-link upgrade completion condition. The active time threshold K1 refers to the most recent period of time, such as the last 3 seconds, the last 10 seconds, etc.; the inert time threshold K2 is a longer period of time starting from a certain time point, such as 30 minutes, 1 hour, etc. starting from a certain time point. Relatively speaking, the inert time threshold K2 is greater than the active time threshold K1. Based on this, the proxy module is also used to monitor the number of non-security protocol type access requests sent and received by the service port of any service within the set active time threshold K1; when the number is less than the first number threshold, it means that any service has basically completed the upgrade operation, and it is determined that the full link upgrade completion condition is met, that is, by obtaining the number of non-security protocol type access requests received within the last K1 time, if the number is small (that is, less than the first number threshold), it means that any service has basically completed the upgrade operation, and it can be considered that the full link upgrade completion condition is met; and / or, after monitoring the arrival of the set inert time threshold K2, it is determined that the full link upgrade completion condition is met. In this case, sufficient time K2 is given for each service to have sufficient time to complete the link upgrade. After time K2 arrives, it is considered that any service has completed the link upgrade. Among them, the start time of the inert time threshold K2 is the time when the proxy module in any service receives the inert time threshold K2, that is, the proxy module starts timing the inert time threshold K2 from the time it receives the inert time threshold K2. Optionally, after determining that the full-link upgrade conditions are met, the proxy module of any service will enter a mode of rejecting access requests of non-secure protocol types. This mode can also be called a security authentication mode. In this security authentication mode, if the proxy module determines that the type of the intercepted access request is a non-secure protocol type, it will directly reject the access request.

[0071] In an optional embodiment, the authentication control node can provide a control interface to the outside world, and the control interface can be a web page, a command window or an application page, and there is no limitation on this. Based on this, the setting of the active time threshold and the inert time threshold can be completed by the microservice system manager or the system operation and maintenance personnel through the control interface provided by the authentication control node. Among them, the setting of the active time threshold and the inert time threshold can be flexibly set according to the needs of different services. The active time threshold and the inert time threshold corresponding to different services can be different or the same, and the present disclosure does not limit this. Based on this, the authentication control node is also used to respond to the time setting operation on the control interface, obtain the active time threshold and the inert time threshold set by the user for any service; and send the active time threshold and the inert time threshold to the agent module in any service. The users here can be but are not limited to: system managers or operation and maintenance personnel.

[0072] After the full-link upgrade is completed, the proxy module enters the security authentication mode. In the security authentication mode, the proxy module in any service will first obtain the trust data and call relationship of any service from the perspective of an observer, and report the trust data and call relationship of any service to the authentication control node, so that the authentication control node can generate the authentication policy information of any service based on the trust data and call relationship of any service; after the authentication control node generates the authentication policy information of any service, it will send the authentication policy information to the proxy module in any service, so that the proxy module can perform security authentication on the access request to any service based on the authentication policy information, thereby realizing a systematic authentication rule generation method. At this time, the authentication policy information can be considered as the initial authentication policy information. As illegal access requests appear, the authentication defense node will dynamically update the authentication policy information. In addition, the proxy module will dynamically observe the trust data and call relationship of any service, and report to the authentication control node or the authentication defense node to update the authentication policy information when it finds that the trust data and / or call relationship of any service have changed.

[0073] In the embodiments disclosed herein, the manner in which the proxy module obtains the trust data of any service is not limited. In an optional embodiment, when obtaining the trust data of any service, the proxy module may obtain the multi-dimensional trust impact parameters and target service set corresponding to the service, the target service set including information about other services requesting to call the service; and generate trust data based on the multi-dimensional trust impact parameters and target service set. The trust impact parameters refer to parameters that affect the trustworthiness of any service and may include multiple dimensions. For details, please refer to the examples in the following embodiments; and the information about other services requesting to call the service may also affect the trustworthiness of the service.

[0074] In the embodiments of the present disclosure, the implementation method of the trust data is not limited, and any data form that can characterize the trustworthiness or security of any service is applicable to the embodiments of the present disclosure. Optionally, an implementation of the trust data includes a trust index and a trust threshold. Based on this, trust data is generated according to multi-dimensional trust influence parameters and a target service set, including: generating a trust index for any service according to multi-dimensional trust influence parameters, wherein the trust index is used to characterize the degree of trust of any service, the higher the trust index, the more trustworthy any service is, and each service has its own trust index; and generating a trust threshold for any service according to the trust index of any service and the trust index of each service in the target service set, wherein the trust threshold is used to reflect the trust conditions that any service should meet when allowing other services to access it.

[0075] Further optionally, when generating the trust index of any service based on the multi-dimensional credibility influence parameters, the trust values ​​can be calculated separately according to the multi-dimensional credibility influence parameters to obtain the multi-dimensional trust values; and the multi-dimensional trust values ​​can be weighted and summed according to the weights corresponding to the multi-dimensional credibility influence parameters to obtain the trust index of any service. For example, the multi-dimensional credibility influencing parameters mentioned in the above embodiment include but are not limited to: the deployment environment set where any service is located, the service environment set where it is located, and the inbound and outbound traffic rates of any service, wherein the deployment environment set includes at least one deployment environment, which refers to the environment where the service may be deployed (such as an ECS environment, a physical machine, or a K8s cluster, etc.). The security of different deployment environments is different, and different deployment environments have different safety levels; the service environment set includes at least one service environment, which refers to the application environment where the service is located, or refers to the scope of the service, and can include information such as the attributes of the service and the type of the application environment. For example, a payment service can be deployed in a variety of e-commerce applications, or in financial applications and video applications, etc. These e-commerce applications, financial applications, or video applications are the service environments of the payment service. The security of different service environments is different, and different service environments have different safety levels. The inbound and outbound traffic rates can be obtained by monitoring the traffic of the service port through the agent of any service. Optionally, the inbound and outbound traffic rates are the average traffic values ​​over a period of time. Based on this, the generation method of the trust index (cert) of service x can be expressed by the following formula:

[0076] In the above formula, α, β, γ, δ, and ε are the weights of the preset credibility influencing parameters, which can also be called variable coefficients. i BusinessZoneSet is the safety level of deployment environment i or service environment i.x DeployZoneSet is the service environment set where service x is located. x InflowRate is the deployment environment set where service x is located. x is the inflow rate of service x, OutflowRate x is the outgoing traffic rate of service x.

[0077] Further optionally, when generating the trust threshold of any service based on the trust index of any service and the trust index of each service in the target service set, a reference trust index can be generated based on the trust index of each service in the target service set, and the difference between the reference trust index and the trust index of any service can be calculated, and the difference can be used as the trust threshold of any service. This means that when a certain service accesses any service, the difference between the trust index of the certain service and the trust index of the certain service must be greater than or equal to the trust threshold of the certain service, which indicates that a certain service is trustworthy and safe for the certain service, and therefore a certain service can be allowed to access the certain service. The reference trust index can be the minimum value, average value or weighted sum value of the trust indexes of the various services in the target service set, and there is no limitation on this. Optionally, when the minimum value of the trust indexes of the various services in the target service set is used as the reference trust index, the method of generating the trust threshold (threshold) of service x can be expressed by the following formula:

[0078] In the above formula, InFlowSet x For the target service set that calls service x, the agent will record which services call service x to form the target service set corresponding to service x, cert i ,cert x are the trust indexes of service i and service x respectively. The trust indexes of service i and service x can be calculated using the above trust index calculation formula.

[0079] In the above embodiment, the process of obtaining the trust index and trust threshold is illustrated by taking the trust data including the trust index and trust threshold as an example, but the implementation of the trust data is not limited to this. For example, the trust data may include only the trust index, or only the trust threshold, or other forms of data. In the case of including only the trust index, if the trust index of the other service is greater than the trust index of the service, it indicates that the other service is trustworthy to the service, and the other service may be allowed to access the service.

[0080] In an optional embodiment, when obtaining the call relationship information of a service, the proxy module of any service may intercept access requests sent or received by the service port of any service and determine the call relationship information of any service based on the intercepted access requests and their access directions. Optionally, the call relationship information primarily refers to information about other services that call the service, but may also include information about other services called by the service.

[0081] In this embodiment, when the proxy module of any service obtains the trust data and call relationship information of any service, it can report it to the authentication control node. The authentication control node can generate authentication policy information of any service based on the trust data and call relationship information of any service. In an optional embodiment, when the authentication control node generates the authentication policy information of any service based on the trust data and call relationship information of any service, it obtains the trust data of each service in the target service set based on the call relationship information of any service, and the above-mentioned target service set includes information of other services requesting to call any service; obtains the first service whose trust data is greater than the trust data of any service from the target service set; since the trust data of the first service is greater than the trust data of any service, it means that the first service is safe and trustworthy relative to any service, and therefore, authentication policy information allowing the first service to access any service can be generated for any service.

[0082] It is explained here that, depending on the different implementations of the trust data of any service, the authentication control node will also have different implementation methods for obtaining a first service whose trust data is greater than the trust data of any service and generating authentication policy information that allows the first service to access any service. The following example illustrates: Optionally, in the case where the trust data is implemented as a trust index, a service whose trust index is greater than the trust index of any service is obtained from the target service set as the first service, and authentication policy information that allows the first service to access any service is generated. In another optional embodiment, the trust data includes a trust index and a trust threshold, then a service whose trust index is greater than the trust index of any service and the difference between the trust index and the trust index of any service is greater than or equal to the trust threshold is obtained from the target service set as the first service, and authentication policy information that allows the first service to access any service is generated.

[0083] In an embodiment of the present disclosure, the authentication policy information can be implemented in the form of a whitelist and / or a blacklist. Optionally, in the case where the authentication policy information is implemented as a whitelist, the authentication policy information of any service includes information of other services that are allowed to call any of the services, and only the services included in the whitelist have the authority to call any of the services. In the case where the authentication policy information is implemented as a blacklist, the authentication policy information of any service includes information of other services that are prohibited from calling any of the services, and the services in the blacklist are prohibited from accessing any of the services, and accordingly, the services that are not in the blacklist have the authority to call any of the services. Of course, the authentication policy information can be implemented as both a whitelist and a blacklist, with the whitelist storing information of other services that are allowed to access any of the services, and the blacklist storing information of other services that are not allowed to access any of the services.

[0084] As shown in Figure 4a, a calling relationship exists between services AK. Specifically, the proxy modules in each service AK report the trust index, trust threshold, and calling relationship of each service to the authentication control node. Based on the trust index, trust threshold, and calling relationship of each service AK, the authentication control node generates authentication policy information for each service AK and distributes it to the proxy modules in each service AK. Based on the authentication policy information of each service AK, the calling topology between the service AKs can be derived: service K allows service A to call, service H allows service E to call, service F allows services B and C to call, and service I allows service F to call; service G allows service D to call, service J allows service E and service G to call, and service K allows service E and service F to call. In Figure 4a, the calling relationship between two services is represented by a solid line with an arrow, and the service pointed to by the arrow allows the other service connected by the solid line to call it. After receiving the authentication policy information, the proxy modules in the service AK enter automatic authentication mode and perform security authentication on access requests received by their respective services based on their respective authentication policy information. Taking the implementation of authentication policy information as a whitelist as an example, the proxy module in the service AK can determine whether the sender of the access request is on the whitelist. If it is on the whitelist, the access request will be reported to the application to which it belongs; if it is not on the whitelist, the access request will be regarded as an illegal access request and rejected.

[0085] Continuing from the above embodiment, when the multi-dimensional credibility influencing parameters corresponding to any service change and / or the services in the target service set change, the trust data of any service will be affected. When the multi-dimensional credibility influencing parameters include the deployment environment set where the any service is located, the service environment set where the any service is located, and the inbound and outbound traffic rates of the any service, changes in any dimension may cause the trust data to change. The situation where the services in the target service set change includes at least one of the following: adding other services that want to call any service, deleting other services that already have the authority to call any service. Based on this, the proxy module in any service is also used to monitor whether the multi-dimensional credibility influencing parameters corresponding to any service have changed and / or whether the services in the target service set have changed, and when it is monitored that the multi-dimensional credibility influencing parameters corresponding to any service have changed and / or the services in the target service set have changed, the trust data of any service is updated and reported to the authentication control node. Among them, the method of updating the trust data of any service is the same as the method of generating the trust data in the above embodiment, which can be seen in the method illustrated in the above formula. The difference is that the data involved in the calculation will be different. Correspondingly, the authentication and control node is also used to: receive the updated trust data of any service reported by the proxy module in any service, and send the updated trust data of any service to the proxy modules in other services called by any service, so that the proxy modules in other services can perform security authentication on any service based on the updated trust data of any service when any service accesses other services.

[0086] Similarly, for the case where the trust data of other services that have the authority to call any service changes, for the convenience of description and distinction, taking the second service as an example, the second service is first of all another service that has the authority to call any service, and is located in the authentication whitelist of any service, and the trust data of the second service has changed, the authentication control node will obtain the updated trust data of the second service reported by the proxy module in the second service, and will send the updated trust data of the second service to each service that the second service needs to call (including any of the services mentioned above). Accordingly, the proxy module of any service is also used to receive the updated trust data of the second service that calls any of the services mentioned above, which is sent by the authentication control node. The second service is a subset of the first service. Furthermore, the proxy module in any service is also used to: when an access request from a second service is intercepted from the service port of any service, perform a first security authentication on the second service according to the authentication policy information of any service; taking the whitelist as an example, at this time the second service is still in the whitelist, so the second service can pass the first security authentication based on the whitelist, but because the trust data of the second service has changed compared to before, in order to ensure the security of any service, if the second service passes the first security authentication, perform a second security authentication on the second service according to the trust data of any service and the updated trust data of the second service. For example, it can be determined whether the updated trust data of the second service is greater than the trust data of any service, or whether the updated trust data of the second service is greater than the trust data of any service and exceeds a certain threshold (such as a trust threshold). If the judgment result is yes, it is determined that the second service has passed the second security authentication, otherwise, it is determined that the second service has not passed the second security authentication.

[0087] In an optional embodiment, the proxy module in any service is also used to: when the above-mentioned second service fails to pass the secondary security authentication, report the access request from the second service to the authentication defense node to update the authentication policy information; the authentication defense node is also used to: based on the access request from the second service reported by the proxy module in any service, update the authentication policy information of the any service to prohibit the second service from accessing the any service, and synchronize the updated authentication policy information of the any service to the proxy module in any service. Taking the whitelist as an example, the second service can be removed from the whitelist of any service, and the updated whitelist can be synchronized to the proxy module in any service. Optionally, the authentication defense node can directly synchronize the updated whitelist to the proxy module in any service, or it can synchronize the updated whitelist to the proxy module in any service through the authentication control node.

[0088] In one example, a service's trust data changes due to a change in the deployment environment, thereby triggering the proxy module, authentication defense node, and authentication management node to automatically update the authentication policy information of another service called by the service. As shown in Figures 4a and 4b, assume that service A (equivalent to the second service in the above embodiment) was originally deployed in the i1 cluster of K8s. Subsequently, service A is migrated from cluster i1 to cluster i2. Due to the change in the deployment environment, the trust data of service A changes. In this case, the proxy module in service A will recalculate the trust data of service A based on the new deployment environment and report the changed trust data to the authentication control node. In Figure 4a, the dotted line from service A to the authentication control node represents the process of the proxy module in service A reporting the updated trust data of service A to the authentication control node. For the authentication and control node, the updated trust data of service A will be synchronized to the proxy modules in each service called by service A. Taking service E as an example in Figure 4a, the dotted line from the authentication and control node to service A in Figure 4a represents the process of the authentication and control node synchronizing the updated trust data of service A to the proxy module in service E.

[0089] Furthermore, when the proxy module in service E intercepts the access request from service A to call service E, the proxy module in service E performs the first security authentication on service A according to the authentication policy information. After service A passes the first security authentication, it continues to judge whether the trust data of service A is greater than the trust data of service E or whether the trust data of service A is greater than the trust data of service E and exceeds a certain threshold. If the judgment result is yes, the proxy module in service E reports the access request of service A to service E, and service E allows the call of service A. Otherwise, the call of service A is rejected. Furthermore, as shown in FIG4b , the solid line with an “×” indicates that service E rejects the call of service A. In this case, the proxy module in service E reports the access request from service A to the authentication defense node to update the authentication policy information, as shown by the dotted line from service E to the authentication defense node in FIG4b ; the authentication defense node updates the authentication policy information of service E based on the access request reported by the proxy module in service E to prohibit service A from accessing service E, and synchronizes the updated authentication policy information to the proxy module in service E, as shown by the dotted line from the authentication defense node to service E in FIG4b ; at this time, the service call topology relationship between services AK has changed relative to that shown in FIG4a . Referring to FIG4b , the access permission of service A to service E is deleted.

[0090] In the above embodiment, the authentication defense node and the authentication control node are implemented as two different nodes to differentiate their functions, but this is not a limitation. In an alternative embodiment, for ease of management, the authentication defense node and the authentication control node can be implemented as a single node, which has all the functions of both nodes.

[0091] In another example, for any service, due to the addition of a new service that calls any of the services, the proxy module, the authentication defense node, and the authentication management node are triggered to automatically update the authentication policy information of any of the services. Continuing with the embodiment shown in Figure 4a, as shown in Figure 4c, a new service L is added to the microservice architecture. When service L wants to call service G and service K, because service L does not exist originally, it does not have the calling authority of service G and service K. The authentication policy information is used as a whitelist, that is, the whitelists of service G and service K do not include service L. Therefore, when service L initiates an access request to service G or service K, the proxy module in service G or service K determines that the access request from service L is an illegal access request based on the authentication policy information, and rejects the call of service L, as shown by the solid line with "×" in Figure 4c, and reports the access request to the authentication defense node, as shown by the dotted line from service G and service K to the authentication defense node in Figure 4c; the authentication defense node determines that the access request from service L is an illegal access request based on the authentication policy information, and rejects the call of service L, as shown by the solid line with "×" in Figure 4c. The trust data of service L and the trust data of service G and service K are used to determine whether the newly added service L has the authority to call service G and service K. Optionally, when the trust data of service L is greater than the trust data of service G or is greater than and exceeds a certain threshold, it is determined that service L has the authority to call service G. Similarly, service L has the authority to call service K, so the authentication policy information of service G and service K is updated, for example, service L is added to the whitelist of service G and service K, and the updated authentication policy information of service G and service K is sent to the proxy modules in service G and service K respectively. At this point, after the addition of service L, the calling topology relationship between services has changed compared with that shown in Figure 4c. As shown in Figure 4d, the calling relationship between service L, service G and service K is added.

[0092] In the embodiment of the present disclosure, in order to facilitate the implementation of active authentication defense, authentication defense conditions are set, but the specific implementation method of the authentication defense conditions is not limited. Any condition that allows the authentication defense node to automatically determine whether to update the relevant authentication policy information is applicable to the embodiment of the present disclosure. In an optional embodiment, an interception time threshold K3, a defense function activation number threshold M1, and a defense function deactivation number threshold M2 can be set. The interception time threshold K3 is a recent period of time, such as the last 10 minutes, the last 15 minutes, etc. The defense function activation number threshold M1 is the number threshold of illegal access requests that determines whether to activate the active authentication defense function. The defense function deactivation number threshold M2 is the number threshold of illegal access requests that determines whether to deactivate the active authentication defense function. Relatively speaking, the defense function deactivation number threshold M2 is less than the defense function activation number threshold M1. The interception time threshold K3, the defense function activation number threshold M1, and the defense function deactivation number threshold M2 can be used to generate the authentication defense conditions. Based on this, the authentication defense node is also used to monitor the number of illegal access requests received within the set interception time threshold K3; if it is monitored that the number of illegal access requests received within the interception time threshold K3 is greater than the set defense function activation threshold M1, the authentication defense mode is turned on. For example, the authentication defense node finds that there are M1 access requests from the same IP in the illegal access requests within the K3 time. The IP has been trying to access one or some services and has been rejected by these services. It can be determined that there is a security risk for the IP. The authentication defense node can identify the IP as a malicious IP and update the authentication policy for all services. The updated authentication policy information is updated to prohibit the above IP from accessing any service, and the proxy module in each service is synchronized to enable the proxy module in each service to reject the access request from the IP address based on the updated authentication policy information to ensure service security; in the authentication defense mode, the number of illegal access requests received within the interception time threshold K3 can also be monitored. If it is monitored that the number of illegal access requests received within the interception time threshold (K3) is less than the set defense function shutdown number threshold M2, this means that the network threat has been reduced, and the authentication defense mode is exited. Regarding the active authentication defense function.

[0093] This section describes how to proactively defend against illegal access requests when they meet authentication and defense conditions. This can be flexibly implemented based on application requirements or system security requirements. In the above embodiment, prohibiting all services from accessing the IP address when an illegal access request meets the authentication and defense conditions is merely an example of proactive defense and is not intended to be limiting.

[0094] In the embodiment of the present disclosure, with the help of the proxy module, each service realizes the function of single port dual protocol, which provides the conditions for realizing zero trust with lossless upgrade of traffic in the microservice architecture. In addition, it is also possible to open a new HTTPS port that is different from the original HTTP port, and then gradually migrate the traffic from the HTTP port to the HTTPS port. After all traffic is switched to the HTTPS port, the HTTP port is closed. First, it occupies new port resources, and second, when there is hard coding pointing to the original HTTP port in the microservice, these codes need to be modified to point to the new HTTPS port. Compared with the solution of opening a new HTTPS port, the embodiment of the present disclosure adopts the method of single port dual protocol, which saves port resources, avoids the problem of application code modification caused by the newly opened port, and reduces the complexity of the migration process from the HTTP port to the HTTPS port.

[0095] In addition, in the disclosed embodiment, the full link upgrade completion condition is set to allow the agent module to automatically and securely upgrade the link without the user having to worry about the upgrade process, thus automating the upgrade process. Compared with the manual method of determining whether the upgrade is complete, it is more efficient.

[0096] Furthermore, compared to manually configuring a complete set of authentication rules that meet zero-trust requirements, in the embodiment of the present disclosure, the proxy module dynamically observes the trust data and call relationship of any service, and can actively trigger the update of authentication policy information when changes are found; and with the emergence of illegal access requests, the authentication policy information can be automatically updated to achieve active defense and counterattack of security authentication, which can reduce the complexity of authentication rule configuration and management.

[0097] Figure 5 is a flow chart of a method for securely accessing microservices provided by an exemplary embodiment of the present disclosure; the method is applicable to a proxy module injected into any service, and the proxy module shares the service port of any service. For the description of the proxy module and the service, please refer to the aforementioned system embodiment and will not be repeated here. As shown in Figure 5, the method includes:

[0098] S51: In the full-link upgrade mode, a full-link security upgrade is performed on any service based on the protocol type and access direction of the access request sent and received by the service port of any service, and the security authentication mode is entered when the full-link upgrade completion conditions are met;

[0099] S52: In the security authentication mode, according to the authentication policy information issued by the authentication control node, security authentication is performed on the access request received by the service port of any service, and the illegal access request that fails the security authentication is reported to the authentication defense node for the authentication defense node to update the authentication policy information.

[0100] In an optional embodiment, a full-link security upgrade is performed on any service based on the protocol type and access direction of the access requests sent and received by the service port of any service, including: in the full-link upgrade mode, intercepting the access requests sent and received by the service port of any service; when the access direction of the intercepted access request is the inbound direction and its protocol type is a security protocol type, obtaining the digital certificate of any service from the authentication and control node, and performing a security upgrade on the transmission link between any service and other services that serve as request senders based on the digital certificate of any service; when the access direction of the intercepted access request is the outbound direction and other services that serve as request receivers have completed the link upgrade, obtaining the digital certificate of any service from the authentication and control node, and performing a security upgrade on the transmission link between any service and other services that serve as request receivers based on the digital certificate of any service.

[0101] In an optional embodiment, determining whether the full-link upgrade completion conditions are met includes: monitoring the number of access requests sent and received by the service port of any service within a set active time threshold; when the number is less than a first number threshold, determining that the full-link upgrade completion conditions are met; and / or, after monitoring that a set inertia time threshold is reached, determining that the full-link upgrade completion conditions are met, the agent module in any service starts timing the inertia time threshold from the time the inertia time threshold is received, and the inertia time threshold is greater than the active time threshold.

[0102] In an optional embodiment, the method provided in this embodiment also includes: generating trust data of any service based on the multi-dimensional credibility impact parameters corresponding to any service and the target service set, the target service set including information of other services requesting to call any service; determining the calling relationship information of any service based on the access requests sent and received by the service port of any service and its access direction; reporting the trust data and calling relationship information of any service to the authentication control node so that the authentication control node can generate authentication policy information for any service.

[0103] In an optional embodiment, trust data of any service is generated based on multi-dimensional credibility influencing parameters and a target service set, including: generating a trust index of any service based on multi-dimensional credibility influencing parameters, and obtaining the trust index of each service in the target service set; generating a trust threshold of any service based on the trust index of any service and the trust index of each service in the target service set.

[0104] In an optional embodiment, a trust index of any service is generated based on multi-dimensional credibility influencing parameters, including: calculating trust values ​​according to the multi-dimensional credibility influencing parameters respectively to obtain multi-dimensional trust values; and performing weighted summation of the multi-dimensional trust values ​​according to the weights corresponding to the multi-dimensional credibility influencing parameters to obtain the trust index of any service.

[0105] In an optional embodiment, the method provided in this embodiment also includes: updating the trust data of any service when the multi-dimensional credibility influencing parameters corresponding to any service change and / or the services in the target service set change; reporting the updated trust data of any service to the authentication and control node for the authentication and control node to send to the proxy modules in other services called by any service.

[0106] In an optional embodiment, the method provided in this embodiment also includes: receiving updated trust data of a second service that calls any service, issued by the authentication control node, where the second service is other services that have the authority to access any service; and, when an access request from the second service is intercepted from the service port of any service, performing a first security authentication on the second service based on the authentication policy information of any service; if the second service passes the first security authentication, performing a second security authentication on the second service based on the trust data of any service and the updated trust data of the second service.

[0107] In an optional embodiment, when the second service fails the secondary security authentication, the above method further includes: reporting the access request from the second service to the authentication defense node to update the authentication policy information to prohibit the second service from accessing any service and synchronizing the updated authentication policy information of any service to the proxy module in any service.

[0108] FIG6 is a flow chart of a method for secure access to microservices provided by an exemplary embodiment of the present disclosure. This method is applied to an authentication and control node. For a description of the authentication and control node, please refer to the aforementioned system embodiment and will not be repeated here. As shown in FIG6 , the method includes:

[0109] S61: Obtain the trust data and call relationship information of any service, inject a proxy module into any service, and the proxy module shares the service port of any service;

[0110] S62: Generate authentication policy information for any service based on the trust data and call relationship information of any service;

[0111] S63: Send the authentication policy information of any service to the proxy module in any service, so that the proxy module can perform security authentication on the access request received by the service port in the security authentication mode.

[0112] In an optional embodiment, authentication policy information for any service is generated based on the trust data and calling relationship information of any service, including: obtaining the trust data of other services of each service in the target service set based on the calling relationship information of any service, the target service set including information of other services requesting to call any service; obtaining the first service whose trust data is greater than the trust data of any service from the target service set; and generating, for any service, authentication policy information that allows the first service to access any service.

[0113] It should be noted that the execution entity of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 51 to 52 can be device A; for another example, the execution entity of steps 51 and 52 can be device A, and the execution entity of step 52 can be device B; and so on.

[0114] In addition, some of the processes described in the above embodiments and the accompanying drawings include multiple operations that appear in a specific order, but it should be clearly understood that these operations may not be executed in the order in which they appear in this article or may be executed in parallel. The sequence numbers of the operations, such as 51, 52, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0115] FIG7 is a schematic diagram of the structure of a microservice security access device provided by an exemplary embodiment of the present disclosure. As shown in FIG7 , the device 700 includes: an upgrade module 701 and an authentication module 702, wherein:

[0116] Upgrade module 701, used to perform a full-link security upgrade on any service in full-link upgrade mode according to the protocol type and access direction of the access request sent and received by the service port of any service, and enter the security authentication mode when the full-link upgrade completion condition is met;

[0117] Authentication module 702 is used to perform security authentication on access requests received by the service port of any service in a security authentication mode based on the authentication policy information issued by the authentication control node, and report illegal access requests that fail security authentication to the authentication defense node so that the authentication defense node can update the authentication policy information; wherein, the authentication policy information is generated based on the trust data and call relationship information of any service.

[0118] Further optionally, when performing a full-link security upgrade on any service based on the protocol type and access direction of the access requests sent and received by the service port of any service, the upgrade module 701 is specifically used to: intercept the access requests sent and received by the service port of any service in the full-link upgrade mode; when the access direction of the intercepted access request is the inbound direction and its protocol type is a security protocol type, obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and other services that serve as request senders based on the digital certificate of any service; when the access direction of the intercepted access request is the outbound direction and the other services that serve as request receivers have completed the link upgrade, obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and other services that serve as request receivers based on the digital certificate of any service.

[0119] Further optionally, when determining that the full-link upgrade completion conditions are met, the upgrade module 701 is specifically used to: monitor the number of access requests sent and received by the service port of any service within a set active time threshold; when the number is less than a first number threshold, determine that the full-link upgrade completion conditions are met; and / or, after monitoring that a set inertia time threshold is reached, determine that the full-link upgrade completion conditions are met, and the agent module in any service starts timing the inertia time threshold from the time the inertia time threshold is received, and the inertia time threshold is greater than the active time threshold.

[0120] Further optionally, the authentication module 702 is also used to: generate trust data of any service based on the multi-dimensional credibility impact parameters and target service set corresponding to any service, wherein the target service set includes information of other services requesting to call any service; determine the calling relationship information of any service based on the access requests sent and received by the service port of any service and its access direction; and report the trust data and calling relationship information of any service to the authentication control node so that the authentication control node can generate authentication policy information for any service.

[0121] Further optionally, when the authentication module 702 generates the trust data of any service based on the multi-dimensional credibility influencing parameters and the target service set, it is specifically used to: generate a trust index of any service based on the multi-dimensional credibility influencing parameters, and obtain the trust index of each service in the target service set; generate a trust threshold of any service based on the trust index of any service and the trust index of each service in the target service set.

[0122] Further optionally, when the authentication module 702 generates the trust index of any service based on the multi-dimensional credibility influencing parameters, it is specifically used to: calculate the trust values ​​according to the multi-dimensional credibility influencing parameters respectively to obtain the multi-dimensional trust values; and perform weighted summation of the multi-dimensional trust values ​​according to the weights corresponding to the multi-dimensional credibility influencing parameters to obtain the trust index of any service.

[0123] Further optionally, the authentication module 702 is also used to: update the trust data of any service when the multi-dimensional credibility influencing parameters corresponding to any service change and / or the services in the target service set change; report the updated trust data of any service to the authentication control node for the authentication control node to send to the proxy module in other services called by any service.

[0124] Further optionally, the authentication module 702 is also used to: receive updated trust data of a second service that calls any of the services, issued by the authentication control node, where the second service is another service that has the authority to access any of the services; and when an access request from the second service is intercepted from the service port of any of the services, perform an initial security authentication on the second service according to the authentication policy information of any of the services; if the second service passes the initial security authentication, perform a secondary security authentication on the second service according to the trust data of any of the services and the updated trust data of the second service.

[0125] Further optionally, when the second service fails to pass the secondary security authentication, the authentication module 702 is also used to: report the access request from the second service to the authentication defense node to update the authentication policy information, so as to prohibit the second service from accessing any service and synchronize the updated authentication policy information of any service to the proxy module in any service.

[0126] FIG8 is a schematic diagram of the structure of another microservice security access device provided by an exemplary embodiment of the present disclosure. As shown in FIG8 , the device 800 includes: an acquisition module 801, a generation module 802, and a sending module 803, wherein:

[0127] An acquisition module 801 is used to acquire the trust data and call relationship information of any service, wherein the service is injected into a proxy module, and the proxy module shares the service port of the service;

[0128] A generating module 802, configured to generate authentication policy information of any service according to the trust data and call relationship information of any service;

[0129] The sending module 803 is used to send the authentication policy information of any service to the proxy module in any service, so that the proxy module can perform security authentication on the access request received by the service port in a security authentication mode.

[0130] Further optionally, when the generation module 802 generates the authentication policy information of any service based on the trust data and calling relationship information of any service, it is specifically used to: obtain the trust data of other services of each service in the target service set based on the calling relationship information of any service, and the target service set includes information of other services requesting to call any service; obtain the first service from the target service set whose trust data is greater than the trust data of any service; and generate, for any service, authentication policy information that allows the first service to access any service.

[0131] FIG9 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present disclosure. As shown in FIG9 , the device includes: one or more memories 901 and one or more processors 902 .

[0132] Memory 901 is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, etc.

[0133] The memory 901 can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0134] Processor 902 is coupled to memory 901 and is used to execute the computer program in memory 901, so as to: in a full-link upgrade mode, perform a full-link security upgrade on any service according to the protocol type and access direction of the access request sent and received by the service port of any service, and enter a security authentication mode when the full-link upgrade completion condition is met; in a security authentication mode, perform security authentication on the access request received by the service port of any service according to the authentication policy information issued by the authentication control node, and report the illegal access request that fails the security authentication to the authentication defense node so that the authentication defense node can update the authentication policy information; wherein, the authentication policy information is generated based on the trust data and call relationship information of any service.

[0135] In an optional embodiment, when the processor 902 performs a full-link security upgrade on any service based on the protocol type and access direction of the access request sent and received by the service port of any service, it is specifically used to: intercept the access request sent and received by the service port of any service in the full-link upgrade mode; when the access direction of the intercepted access request is the inbound direction and its protocol type is a security protocol type, obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and other services that serve as request senders based on the digital certificate of any service; when the access direction of the intercepted access request is the outbound direction and the other services that serve as request receivers have completed the link upgrade, obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and other services that serve as request receivers based on the digital certificate of any service.

[0136] In an optional embodiment, when determining that the full-link upgrade completion conditions are met, the processor 902 is specifically used to: monitor the number of access requests sent and received by the service port of any of the services within a set active time threshold; when the number is less than a first number threshold, determine that the full-link upgrade completion conditions are met; and / or, after monitoring that a set inertia time threshold is reached, determine that the full-link upgrade completion conditions are met, and the agent module in any of the services starts timing the inertia time threshold from the time the inertia time threshold is received, and the inertia time threshold is greater than the active time threshold.

[0137] In an optional embodiment, the processor 902 is also used to: generate trust data of any service based on the multi-dimensional credibility impact parameters and target service set corresponding to any service, wherein the target service set includes information of other services requesting to call any service; determine the calling relationship information of any service based on the access requests sent and received by the service port of any service and its access direction; and report the trust data and calling relationship information of any service to the authentication control node so that the authentication control node can generate authentication policy information for any service.

[0138] In an optional embodiment, when the processor 902 generates the trust data of any service based on the multi-dimensional credibility influencing parameters and the target service set, it is specifically used to: generate a trust index of any service based on the multi-dimensional credibility influencing parameters, and obtain the trust index of each service in the target service set; generate a trust threshold of any service based on the trust index of any service and the trust index of each service in the target service set.

[0139] In an optional embodiment, when the processor 902 generates the trust index of any of the services based on the multi-dimensional credibility influencing parameters, it is specifically used to: calculate the trust values ​​according to the multi-dimensional credibility influencing parameters respectively to obtain the multi-dimensional trust values; and perform weighted summation of the multi-dimensional trust values ​​according to the weights corresponding to the multi-dimensional credibility influencing parameters to obtain the trust index of any of the services.

[0140] In an optional embodiment, the processor 902 is further configured to: update the trust data of any service when the multi-dimensional credibility influencing parameters corresponding to the any service change and / or the services in the target service set change;

[0141] The updated trust data of any service is reported to the authentication control node, so that the authentication control node sends it to the proxy modules in other services called by any service.

[0142] In an optional embodiment, the processor 902 is also used to: receive updated trust data of a second service that calls any of the services, issued by the authentication control node, where the second service is another service that has permission to access any of the services; and, when an access request from the second service is intercepted from the service port of any of the services, perform a first security authentication on the second service based on the authentication policy information of any of the services; if the second service passes the first security authentication, perform a second security authentication on the second service based on the trust data of any of the services and the updated trust data of the second service.

[0143] In an optional embodiment, when the second service fails to pass the secondary security authentication, the processor 902 is further used to: report the access request from the second service to the authentication defense node to update the authentication policy information, so as to prohibit the second service from accessing any service and synchronize the updated authentication policy information of any service to the proxy module in any service.

[0144] The detailed implementation and beneficial effects of each step in the method of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated here.

[0145] Furthermore, as shown in Figure 9 , the electronic device further includes other components such as a power supply component 903. Figure 9 only schematically illustrates some components, which does not mean that the electronic device only includes the components shown in Figure 9 .

[0146] Accordingly, an embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps that can be executed by the electronic device in the above method embodiment.

[0147] FIG10 is a schematic diagram of the structure of another electronic device provided by another exemplary embodiment of the present disclosure. As shown in FIG10 , the device includes: one or more memories 1001 and one or more processors 1002 .

[0148] Memory 1001 is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, etc.

[0149] Memory 1001 can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0150] Processor 1002 is coupled to memory 1001 and is used to execute a computer program in memory 1001, so as to: obtain trust data and call relationship information of any service, wherein any service is injected into a proxy module, and the proxy module shares a service port of any service; generate authentication policy information of any service based on the trust data and call relationship information of any service; and send the authentication policy information of any service to the proxy module in any service, so that the proxy module can perform security authentication on access requests received by the service port in a security authentication mode.

[0151] In an optional embodiment, when the processor 1002 generates authentication policy information for any service based on the trust data and calling relationship information of any service, it is specifically used to: obtain the trust data of other services of each service in the target service set based on the calling relationship information of any service, and the target service set includes information of other services requesting to call any service; obtain a first service from the target service set whose trust data is greater than the trust data of any service; and generate, for any service, authentication policy information that allows the first service to access any service.

[0152] Furthermore, as shown in Figure 10, the electronic device also includes other components such as a power supply component 1004, a display 1005 and an audio component 1006. Figure 10 only schematically shows some components, which does not mean that the electronic device only includes the components shown in Figure 10. It should be noted that the components in the dotted box in Figure 10 are optional components, not mandatory components, and the specific details may depend on the product form of the electronic device. The electronic device of this embodiment can be implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone or an IOT device, or it can be a server-side device such as a conventional server, a cloud server or a server array. If the electronic device of this embodiment is implemented as a terminal device such as a desktop computer, a laptop computer, a smart phone, etc., it may include the components in the dotted box in Figure 10; if the electronic device of this embodiment is implemented as a server-side device such as a conventional server, a cloud server or a server array, it may not include the components in the dotted box in Figure 10.

[0153] Accordingly, an embodiment of the present disclosure further provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps that can be executed by the electronic device in the above method embodiment.

[0154] The detailed implementation and beneficial effects of each step in the method of this embodiment have been described in detail in the aforementioned embodiments and will not be elaborated here.

[0155] The above-mentioned memory can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0156] The above-mentioned communication component is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G and other mobile communication networks, or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0157] The above-mentioned display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor can not only sense the boundary of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0158] The power supply assembly provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located.

[0159] The above-mentioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), and when the device where the audio component is located is in an operating mode, such as call mode, recording mode, and voice recognition mode, the microphone is configured to receive external audio signals. The received audio signal can be further stored in a memory or sent via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0160] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0161] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0162] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0163] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0164] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0165] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0166] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0167] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0168] The above are merely examples of the present disclosure and are not intended to limit the present disclosure. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present disclosure are intended to be included within the scope of the claims of the present disclosure.

Claims

1. A microservice security access system, comprising: An authentication control node, an authentication defense node, and a proxy module, wherein the proxy module is injected into multiple services and shares the service port of the service to which it belongs; The proxy module in any service is configured to perform a full-link security upgrade on any service in the full-link upgrade mode according to the protocol type and access direction of the access request sent and received by the service port of any service, and enter the security authentication mode when the full-link upgrade completion condition is met; as well as In the security authentication mode, according to the authentication policy information issued by the authentication control node, security authentication is performed on the access request received by the service port of any service, and the illegal access request that fails the security authentication is reported to the authentication defense node for updating the authentication policy information; The authentication control node is used to generate authentication policy information of any service according to the trust data and call relationship information of any service, and send it to the proxy module in any service; The authentication defense node is used to update the authentication policy information of at least one service related to the illegal access request when the illegal access request meets the authentication defense condition, and synchronize it to the proxy module in the at least one service.

2. The system according to claim 1, wherein: The proxy module in any of the services is specifically used for: In the full-link upgrade mode, intercept access requests sent and received by the service port of any of the services; When the access direction of the intercepted access request is inbound and the protocol type is a secure protocol type, obtain the digital certificate of any service from the authentication control node, and perform a security upgrade on the transmission link between any service and other services as request senders according to the digital certificate of any service; When the access direction of the intercepted access request is outbound and the other service serving as the request receiving end has completed the link upgrade, the digital certificate of any service is obtained from the authentication and control node, and based on the digital certificate of any service, the transmission link between any service and the other service serving as the request receiving end is securely upgraded.

3. The system according to claim 1, wherein: The proxy module in any of the services is also used to: Generate trust data of any service according to the multi-dimensional credibility impact parameters corresponding to any service and a target service set, wherein the target service set includes information of other services requesting to call any service; Determine the call relationship information of any service according to the access request sent and received by the service port of any service and its access direction; Report the trust data and call relationship information of any service to the authentication control node so that the authentication control node can generate authentication policy information for any service.

4. The system according to claim 3, wherein: The proxy module in any of the services is further used to: update the trust data of any of the services and report to the authentication control node when the multi-dimensional credibility influencing parameters corresponding to any of the services change and / or the services in the target service set change; The authentication control node is further used to: send the updated trust data of any service to the proxy module in other services called by any service; or, The proxy module in any of the services is further used to: receive updated trust data of a second service sent by the authentication control node, where the second service is another service that has the authority to access any of the services; and when an access request from the second service is intercepted from the service port of any of the services, performing a first security authentication on the second service according to the authentication policy information of any of the services; In the case that the second service passes the initial security authentication, a secondary security authentication is performed on the second service according to the trust data of any one of the services and the updated trust data of the second service.

5. A microservice security access method, applicable to a proxy module injected into any service, wherein the proxy module shares a service port of any service, the method comprising: In the full-link upgrade mode, according to the protocol type and access direction of the access request sent and received by the service port of any service, a full-link security upgrade is performed on any service, and the security authentication mode is entered when the full-link upgrade completion conditions are met; In the security authentication mode, according to the authentication policy information issued by the authentication control node, the access request received by the service port of any service is securely authenticated, and the illegal access request that fails the security authentication is reported to the authentication defense node for the authentication defense node to update the authentication policy information; The authentication policy information is generated based on the trust data and calling relationship information of any service.

6. The method according to claim 5, wherein: According to the protocol type and access direction of the access request sent and received by the service port of any service, a full-link security upgrade is performed on any service, including: In the full-link upgrade mode, intercept access requests sent and received by the service port of any of the services; When the access direction of the intercepted access request is inbound and the protocol type is a secure protocol type, obtain the digital certificate of any service from the authentication control node, and perform a security upgrade on the transmission link between any service and other services as request senders according to the digital certificate of any service; When the access direction of the intercepted access request is outbound and the other service serving as the request receiving end has completed the link upgrade, the digital certificate of any service is obtained from the authentication and control node, and based on the digital certificate of any service, the transmission link between any service and the other service serving as the request receiving end is securely upgraded.

7. The method according to claim 5, wherein: Confirm that the full-link upgrade completion conditions are met, including: Monitoring the number of access requests sent and received by the service port of any service within a set active time threshold; and determining that a full-link upgrade completion condition is met when the number is less than a first number threshold; and / or After monitoring that the set inertia time threshold has been reached, it is determined that the full link upgrade completion condition is met, and the proxy module in any of the services starts timing the inertia time threshold from the time the inertia time threshold is received, and the inertia time threshold is greater than the active time threshold.

8. The method according to claim 5, wherein: Also includes: Generate any one of the services according to the multi-dimensional credibility impact parameters and target service set corresponding to the service Trust data of services, the target service set including information of other services requesting to call any of the services; Determine the call relationship information of any service according to the access request sent and received by the service port of any service and its access direction; The trust data and call relationship information of any service are reported to the authentication control node, so that the authentication control node generates authentication policy information of any service.

9. The method according to claim 8, wherein: Generate the trust data of any one of the services according to the multi-dimensional credibility influencing parameters and the target service set, including: Generate a trust index of any one of the services according to the multi-dimensional credibility influencing parameters, and obtain the trust index of each service in the target service set; A trust threshold of any service is generated according to the trust index of any service and the trust index of each service in the target service set.

10. The method according to claim 9, wherein: Generating a trust index of any of the services according to the multi-dimensional credibility influencing parameters includes: Calculating the trust values ​​according to the multi-dimensional credibility influencing parameters to obtain the multi-dimensional trust values; According to the weights corresponding to the multi-dimensional credibility influencing parameters, the multi-dimensional trust values ​​are weighted and summed to obtain the trust index of any one of the services.

11. The method according to claim 8, wherein: Also includes: When the multi-dimensional credibility influencing parameters corresponding to any of the services change and / or the services in the target service set change, updating the credibility data of any of the services; The updated trust data of any service is reported to the authentication control node, so that the authentication control node sends it to the proxy modules in other services called by any service.

12. The method according to claim 11, wherein: The method further comprises: receiving updated trust data of a second service that calls any of the services, issued by the authentication control node, where the second service is another service that has the authority to access any of the services; and When an access request from the second service is intercepted from the service port of any of the services, performing a first security authentication on the second service according to the authentication policy information of any of the services; In the case that the second service passes the initial security authentication, a secondary security authentication is performed on the second service according to the trust data of any one of the services and the updated trust data of the second service.

13. The method according to claim 12, wherein: When the second service fails the secondary security authentication, the method includes: The access request from the second service is reported to the authentication defense node to update the authentication policy information, so as to prohibit the second service from accessing any of the services and synchronize the updated authentication policy information of any of the services to the proxy module in any of the services.

14. A microservice secure access method, applicable to an authentication control node, the method comprising: Acquire trust data and call relationship information of any service, wherein any service is injected into a proxy module, and the proxy module shares a service port of any service; Generate authentication policy information for any service based on the trust data and call relationship information of any service; The authentication policy information of any one of the services is sent to the proxy module in any one of the services, so that the proxy module can perform security authentication on the access request received by the service port in a security authentication mode.

15. The method according to claim 14, wherein: Generate authentication policy information of any service according to the trust data and call relationship information of any service, including: According to the calling relationship information of any service, obtaining the trust data of other services of each service in the target service set, wherein the target service set includes the information of other services requesting to call any service; Acquire, from the target service set, a first service whose trust data is greater than the trust data of any of the services; For any of the services, authentication policy information is generated to allow the first service to access any of the services.

16. An electronic device, comprising: Memory and processor; The memory is used to store a computer program, and the processor is coupled to the memory and is used to execute the computer program to implement the steps in the method of any one of claims 5-13 and claims 14-15.

17. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor is enabled to implement the steps of the method according to any one of claims 5 to 13 and claims 14 to 15.

18. A microservice security access device, comprising: An upgrade module is used to perform a full-link security upgrade on any service in a full-link upgrade mode according to the protocol type and access direction of the access request sent and received by the service port of any service, and enter a security authentication mode when the full-link upgrade completion conditions are met; The authentication module is used to perform security authentication on access requests received by the service port of any service in a security authentication mode according to the authentication policy information issued by the authentication control node, and report illegal access requests that fail the security authentication to the authentication defense node so that the authentication defense node can update the authentication policy information; wherein the authentication policy information is generated based on the trust data and call relationship information of any service.

19. According to the microservice security access device according to claim 18, the upgrade module is also used to intercept access requests sent and received by the service port of any service in the full-link upgrade mode; when the access direction of the intercepted access request is the inbound direction and its protocol type is the security protocol type, obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and other services as the request sender according to the digital certificate of any service; when the access direction of the intercepted access request is the outbound direction and the other services as the request receiver have completed the link upgrade, obtain the digital certificate of any service from the authentication and control node, and perform a security upgrade on the transmission link between any service and other services as the request receiver according to the digital certificate of any service.

20. A microservice security access device, applicable to an authentication control node, comprising: An acquisition module, used to acquire the trust data and call relationship information of any service, wherein the any service is injected into the proxy module, and the proxy module shares the service port of the any service; A generation module, used to generate authentication policy information of any service according to the trust data and call relationship information of any service; The sending module is used to send the authentication policy information of any service to the proxy module in any service, so that the proxy module can perform security authentication on the access request received by the service port in the security authentication mode.

Images