Micro-service security access method, system and device and storage medium
By introducing a secure access system for authentication and control nodes, authentication and defense nodes and proxy modules into the microservice architecture, the problem of zero trust technology complexity in the microservice architecture is solved, automated security upgrades and dynamic authentication rules management are realized, and security defense efficiency is improved.
Patent Information
- Application Number
- CN202311771458.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-20
- Publication Date
- 2025-06-20
AI Technical Summary
The introduction of zero-trust technology in the microservice architecture is relatively complex, especially in terms of security upgrades of transmission links, the implementation of systematic authentication rules and the implementation of dynamic defense mechanisms.
A microservice secure access system is adopted, including authentication control nodes, authentication defense nodes and proxy modules. The proxy module is injected into multiple services, implementing single-port dual-protocol functions, and automatically and safely upgrade through the full-link upgrade mode. The authentication control node generates authentication policy information based on the trust level data and call relationship. The proxy module performs security authentication in the security authentication mode, and reports illegal access requests to the authentication defense node for policy updates.
It reduces the complexity of introducing zero-trust technology into the microservice architecture, realizes lossless security upgrades of traffic, automated management and authentication rules, and enhances the identification and defense efficiency of illegal access requests.
Smart Images

Figure CN120185841A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, and in particular, to a microservice security access method, system, device, and storage medium. Background Art
[0002] The microservice architecture is a software development architecture pattern that divides an application into a set of small services, each service running 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 externally.
[0003] To ensure the security of microservices, it is desirable to introduce zero-trust technology into the microservice architecture. Zero trust is a new generation of network security protection concept that defaults to distrusting any object inside and outside the network. A secure access foundation needs to be built based on identity authentication and authorization between any objects to ensure link security, device security, and access control security.
[0004] However, the microservice architecture itself has a certain degree of complexity, and the complexity of introducing zero-trust security in 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. Summary of the Invention
[0005] Multiple aspects of this application provide a microservice security access method, device, system, and storage medium to reduce the complexity faced in introducing zero-trust technology into the microservice architecture and simplify the implementation of zero trust in the microservice architecture.
[0006] An embodiment of the present application provides a microservice secure access system, including: an authentication control node, an authentication defense node, and a proxy module. The proxy module is injected into multiple services and shares the service port of its affiliated service; the proxy module in any service is used to perform full-link security upgrade on the any service according to the protocol type and access direction of the access request received and sent by the service port of the any service in the full-link upgrade mode, and enter the security authentication mode when the full-link upgrade completion condition is met; and, in the security authentication mode, perform security authentication on the access request received by the service port of the 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 for updating the authentication policy information; the authentication control node is used to generate the authentication policy information of the any service according to the trustworthiness data and call relationship information of the any service, and issue it to the proxy module in the 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 and synchronize it to the proxy module in the at least one service when the illegal access request meets the authentication defense condition.
[0007] An embodiment of the present application also provides a microservice secure access method, which is applicable to the proxy module injected into any service. The proxy module shares the service port of the any service, and includes: in the full-link upgrade mode, perform full-link security upgrade on the any service according to the protocol type and access direction of the access request received and sent by the service port of the any service, and enter the security authentication mode when the full-link upgrade completion condition is met; in the security authentication mode, perform security authentication on the access request received by the service port of the 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 for the authentication defense node to update the authentication policy information; wherein, the authentication policy information is generated according to the trustworthiness data and call relationship information of the any service.
[0008] An embodiment of the present application also provides a microservice secure access method, which is applicable to the authentication control node, and includes: obtaining the trustworthiness data and call relationship information of any service, the any service is injected with a proxy module, and the proxy module shares the service port of the any service; generating the authentication policy information of the any service according to the trustworthiness data and call relationship information of the any service; issuing the authentication policy information of the any service to the proxy module in the any service for the proxy module to perform security authentication on the access request received by the service port in the security authentication mode.
[0009] An embodiment of the present application further provides an electronic device, including: 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-mentioned method.
[0010] An embodiment of the present application 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-mentioned method.
[0011] In the embodiment of the present application, the single-port dual-protocol function is implemented by injecting a proxy module into each service. The proxy module realizes the automatic security upgrade of the link, avoiding 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 call relationship and distributes 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 ability of the system, and improves 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, not only solving the problem of introducing the zero-trust technology in the microservice architecture, but also combining the single-port dual-protocol, automatic generation and automatic update of authentication rules, greatly reducing the complexity faced by introducing the zero-trust technology in the microservice architecture and simplifying the implementation of zero trust in the microservice architecture. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:
[0013] Figure 1 is a schematic structural diagram of a microservice security access system provided by an exemplary embodiment of the present application;
[0014] Figure 2 is a schematic diagram of the process of full-link security upgrade provided by an exemplary embodiment of the present application;
[0015] Figure 3 is a schematic diagram of the process of two-way identity authentication between any service and other services as a request receiving end or a request sending end provided by another exemplary embodiment of the present application;
[0016] Figure 4a is a schematic diagram of the initial topological relationship of service calls in a microservice architecture provided by another exemplary embodiment of the present application;
[0017] Figure 4bA schematic diagram of the topological relationship of service calls after updating the authentication policy information in a microservice architecture provided by another exemplary embodiment of the present application;
[0018] Figure 4c A schematic diagram of the initial topological relationship of service calls for adding service L in a microservice architecture provided by another exemplary embodiment of the present application;
[0019] Figure 4d A schematic diagram of the topological relationship of service calls after updating the authentication policy information for adding service L in a microservice architecture provided by another exemplary embodiment of the present application;
[0020] Figure 5 A schematic diagram of the process flow of a microservice security access method provided by another exemplary embodiment of the present application;
[0021] Figure 6 A schematic diagram of the process flow of a microservice security access method provided by another exemplary embodiment of the present application;
[0022] Figure 7 A schematic diagram of the structure of a microservice security access device provided by an exemplary embodiment of the present application;
[0023] Figure 8 A schematic diagram of the structure of another microservice security access device provided by an exemplary embodiment of the present application;
[0024] Figure 9 A schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present application;
[0025] Figure 10 A schematic diagram of the structure of another electronic device provided by another exemplary embodiment of the present application. Detailed implementation manners
[0026] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be clearly and completely described below in conjunction with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.
[0027] 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 for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or reject.
[0028] Since the microservice architecture itself has a certain degree of complexity, the complexity of introducing zero-trust security in the microservice architecture will also increase exponentially, especially when the scale of the microservice architecture is relatively large. Among them, introducing zero-trust security in the microservice architecture is relatively complex, which is mainly reflected in the following aspects:
[0029] First, the upgrade issue of the transmission link: The basic ability 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 call protocol between services, as an example, if zero-trust technology is to be introduced in the microservice architecture, all call links between services need to be set to the Hypertext Transfer Protocol Secure (HTTPS). In the embodiments of this application, the authentication method adopted by HTTPS is not limited. For example, it can adopt but is not limited to: the mutual Transport Layer Security (mTLS) method.
[0030] How to safely upgrade all call links between services in the microservice architecture is a major technical problem. An ideal implementation method is for the user to stop all services, upgrade the HTTP ports of all services to HTTPS ports, and then restart all services to complete the upgrade of the transmission link. However, shutting down all services is not realistic because it will cause the entire microservice architecture to be completely inoperable for a certain period of time. A more practical implementation method is to sequentially connect the services in the microservice architecture to the zero-trust function and gradually upgrade the security of the call links between services, but this will cause new problems. If, in the call link where Service A calls Service B, the service port of Service B has been upgraded to the HTTPS port, and the service port of Service A has not been connected to the zero-trust function yet, at this time, Service A still uses the HTTP protocol to call Service B, and then Service B will report an error and cannot provide services to Service A, resulting in traffic loss. Therefore, in the solution of sequentially connecting services to the zero-trust function, how to gradually and safely upgrade all services without traffic loss to meet the zero-trust requirements is a major technical challenge.
[0031] Second, the implementation issue of the systematic authentication rules: Zero Trust also requires secure authentication of access requests. This means that when introducing Zero Trust into a microservices architecture, when Service A accesses Service B, Service B is required to perform secure authentication on Service A, and Service A can only call Service B after passing the secure authentication of Service B. This requires configuring a complete set of authentication rules that meet the requirements of Zero Trust in the microservices call architecture. Due to the complexity of the microservices architecture itself, it brings complexity to the configuration and management of authentication rules. Therefore, how to automatically implement a complete set of systematic authentication rules according to the characteristics of the microservices architecture to meet the requirements of Zero Trust is another major technical challenge.
[0032] Third, the dynamic defense issue of secure authentication: Zero Trust requires continuous authentication and authorization. In traditional solutions, static authentication rules are generally used to passively defend against security risks, and usually do not adaptively defend or counter malicious calls. For the relatively complex microservices architecture, in order to further ensure the security of the microservices architecture, it is necessary to provide a technical means to continuously collect and analyze the trust level of the current service and its environment for adaptive active defense or counterattack without affecting the efficient operation of the microservices architecture. This is another major technical challenge faced when introducing Zero Trust into the microservices architecture.
[0033] After the above analysis and continuous research, the inventors of this application provided a microservices secure access system, which includes an authentication control node, an authentication defense node, and a proxy module. These components cooperate with each other, not only solving the implementation problem of Zero Trust technology in the microservices architecture, but also reducing the complexity of implementing Zero Trust technology in the microservices architecture.
[0034] Among them, the proxy module is injected into each service as a functional module in the service, and shares the original service port of its affiliated service to achieve the function of single port and dual protocols. With the help of this proxy module in the full-link upgrade mode, according to the protocol type and access direction of the access request of the service port, the services in the microservices architecture are securely upgraded, and the full-link upgrade completion condition is set to allow the proxy module to achieve automated secure upgrade of the link without manual intervention, avoiding traffic loss during the upgrade process.
[0035] Furthermore, a secure authentication mode is set. When the full-link upgrade is completed, it automatically enters the secure authentication mode. In the secure authentication mode, the proxy module cooperates with the authentication control node and the authentication defense node. The authentication control node generates authentication policy information based on the trust level data and call relationship of the service and sends it to the proxy module, and performs secure authentication on the access request of the service according to the authentication policy information sent by the authentication control node to implement systematic authentication rules.
[0036] On the other hand, the proxy module reports the illegal access requests that fail authentication to the authentication and defense node. The authentication and defense node updates the authentication policy information of relevant services and synchronizes it to the proxy modules in relevant services, so as to achieve active defense and counterattack on the basis of the passive defense of the proxy module according to the authentication policy information.
[0037] The following will, with reference to the accompanying drawings, elaborate on the technical solutions provided by various embodiments of the present application.
[0038] Figure 1 It is a schematic structural diagram of a microservice security access system provided by an exemplary embodiment of the present application. As Figure 1 shown, the system 10 includes: an authentication and defense node 11, an authentication control node 12, and a proxy module 13 (agent). For the sake of simplicity and convenience of description, in some descriptions, the "proxy module" can be abbreviated as "agent".
[0039] 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 a complete application function externally. Of course, services between different applications may also need to work together. Further, 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 application do not limit the deployment environment of the service, and the service can be deployed in various environments. For example, it can be deployed in an ECS (Elastic Compute Service) environment or in a Kubernetes (K8s) environment.
[0040] In the embodiments of the present application, the agent, as a functional module of the service, can be pre-injected into each service in the microservice architecture to upgrade the security of the transmission link for these services. These services can come from the same application or different applications. In the embodiments of the present application, the description is carried out with services as the basis, and the specific ones injected with the agent can be instances of the service. In addition, because the agent belongs to the functional module of the service, it can share the service port of its affiliated service. With the link upgrade ability of the agent, the function of supporting dual protocols on a single port can be realized, which is simply referred to as single-port dual protocol. Here, the single-port dual protocol means that the same service port can support both the non-secure transmission protocol before link upgrade and the secure transmission protocol after link upgrade. In this way, the support for two transmission protocols is realized 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 service port switching. In the embodiments of the present application, the process of injecting the agent into the service can be simply referred to as mounting the agent on the service.
[0041] In the embodiments of the present application, there is no limitation on the implementation means of mounting the agent to the service. In an optional embodiment, bytecode technology can be adopted to add the bytecode of the agent to the bytecode file of the service during the service startup process, so as to achieve the purpose of mounting the agent to the service. Further optionally, the microservice architecture is deployed using Kubernetes (K8s) technology. In this K8s environment, the agent is deployed by means of the init container mechanism before the application container (the container carrying the application process) runs. Among them, the init container is a special container used to start before the application container starts and complete the preset conditions required by the application program. During the initialization process, the bytecode of the agent is downloaded to the init container, so that the bytecode of the agent can be accessed and loaded during the startup and running process of the application container, realizing the mounting of the agent to the service. In this embodiment, there is no limitation on the time of injecting the agent into each service, which can be flexibly determined according to the startup time of each service. In addition, since the agent mounting is completed during the startup process of the application container, there is no need to restart the application container, and the service will not be interrupted due to the mounting of the agent, which is beneficial to ensuring the service quality.
[0042] 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, the agent is responsible for completing the security upgrade of the call link between services in the full-link upgrade mode. After the link security upgrade is completed, it automatically enters the security authentication mode, and in the security authentication mode, it is responsible for performing security authentication on the access requests to its affiliated service. Further, 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 the authentication policy information to the agent, and the authentication defense node is responsible for collecting the illegal access requests reported by the agent and updating the authentication policy information according to the illegal access requests to achieve the active defense and counterattack of security authentication. The functions of the agent, the authentication control node, and the authentication defense node will be introduced below in combination with the working processes of the agent in the two modes. It should be noted that for the agent in any service, its functions and working principles are the same or detailed. Therefore, in the following embodiments, the agent in any service will be taken as an example for description.
[0043] Inject the proxy module during the startup process of any service. The proxy module in any service starts with the startup of that service. After startup, it first enters the full-link upgrade mode. In the full-link upgrade mode, based on the characteristic that the proxy module can share the service port of any service it belongs to, it can intercept the access requests sent and received on that service port, and can perform full-link security upgrades on any service according to the protocol type and access direction of the access requests sent and received on the service port of any service. Among them, the full-link upgrade mode is defined from the perspective of the entire system, and refers to the working mode of upgrading 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 that any service when other services call that any service, and also includes the transmission link between that any service and other services when that any service calls other services. Of course, the transmission link can also be called the call link.
[0044] Among them, according to the upgrade situation of the services 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 upgrade or the protocol type after upgrade. For example, it may be an HTTP request or an HTTPS request; correspondingly, the protocol type of the access request that any service hopes to send through its service port may also be the protocol type before upgrade or the protocol type after upgrade. For example, it may be an HTTP request or an HTTPS request. Among them, HTTP belongs to an insecure transmission protocol, and HTTPS belongs to a secure transmission protocol. And HTTP and HTTPS are only examples of insecure transmission protocols and secure transmission protocols, and do not limit this application. 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 in-direction and the out-direction. The in-direction refers to the request direction flowing into the service port, and the access request sent by other services to that any service belongs to the access request in the in-direction. The out-direction refers to the request direction flowing out of the service port, and the access request sent by that any service to other services belongs to the access request in the out-direction. For the proxy module in any service, it can perform full-link security upgrades on any service according to the protocol type and access direction of the access request.
[0045] Furthermore, in the embodiments of the present application, the complete condition for full-link upgrade can be configured for the proxy module in any service to identify by itself whether the full-link security upgrade of any service is completed. When it is determined that the complete condition for full-link upgrade is met, it means that the transmission protocols used in each call link associated with the any service have been upgraded. At this time, the security authentication mode can be automatically entered. In the embodiments of the present application, the complete condition for full-link upgrade is not limited and can be flexibly set according to application requirements, as long as the proxy module can identify by itself whether the full-link security upgrade of any service is completed according to this condition. It should be noted 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 will directly release all received access requests by default.
[0046] After the full-link upgrade is completed, the security authentication mode is entered. In the security authentication mode, the proxy module of any service is mainly used to perform security authentication on the access requests received at the service port of any service according to the authentication policy information sent by the authentication control node, and report the illegal access requests that fail the security authentication to the authentication defense node for updating the authentication policy information. Correspondingly, the authentication control node is used to generate the 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 and synchronize it to the proxy module in the at least one service when the illegal access request meets the authentication defense condition.
[0047] As Figure 1 shown, in the embodiments of the present application, the single-port dual-protocol function is implemented by injecting a proxy module into each service ( Figure 1 taking Service A, Service B, and Service C as examples for illustration). The proxy module realizes the automatic security upgrade of the link and avoids traffic loss during the upgrade process; moreover, the authentication control node automatically generates the authentication policy information of each service according to the trust data and 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 ability of the system, and improves 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, not only solving the problem of introducing zero-trust technology in the microservice architecture, but also greatly reducing the complexity faced in introducing zero-trust technology in the microservice architecture by combining single-port dual-protocol, automatic generation, and automatic update of authentication rules, and simplifying the implementation of zero-trust in the microservice architecture.
[0048] Figure 2Schematic diagram of the process for full - link security upgrade provided by an exemplary embodiment of this application. In this embodiment, it is assumed that the HTTP protocol is used for calls between services before the introduction of zero - trust technology, and the HTTPS protocol needs to be upgraded for calls between services after the introduction of zero - trust technology. At the same time, it is assumed that the mutual TLS (mTLS) is used as the authentication method for the HTTPS protocol on the transmission link. In this scenario, the proxy module in the service needs to upgrade the various call links where its affiliated service is located from plain - text transmission to mTLS transmission. The protocol types and authentication methods mentioned in the above or following embodiments are only examples and do not limit this application.
[0049] In this embodiment, the microservice architecture includes multiple services. These services can receive access requests sent by clients outside the microservice architecture, access requests sent by other services within the microservice architecture, and may also send access requests to other services in the microservice architecture. Among them, the access requests sent by the client can be forwarded to the corresponding service through the gateway device. Before the introduction of zero - trust technology, it is default that non - secure transmission protocols, such as HTTP, are used between services or between the client and the service. As Figure 2 shown, it is the initial state before upgrading the transmission link between services. In Figure 2 , service A, service B, and service C are shown. And service A includes instances deployed on two computing nodes, denoted as instance 1 and instance 2 of service A respectively. Service B includes instances deployed on different computing nodes, denoted as instance 1 and instance 2 of service B respectively. Service C includes an instance deployed on one computing node, denoted as instance 1 of service C. Here, the number of services and the number of instances included in the service are both examples and do not constitute a limitation to the technical solution of this application. Further, as Figure 2 shown, the call links between instances of different services A, B, and C and between the gateway device and the instances of service A all use the HTTP protocol.
[0050] With the startup of each service, an agent will be injected during the startup process of each service. The agent shares the service port of its affiliated service, and with the startup of the service, it defaults to enter the full - link upgrade mode and perform security upgrades on the call links of its affiliated service in the full - link upgrade mode.
[0051] In the full-link upgrade mode, the agent in any service intercepts the access requests received and sent on the service port of its affiliated service. Optionally, the above access requests can come from a client outside the microservice architecture or be call requests between other services within the microservice architecture. These other services can belong to the same or different applications as any of the above services, and there is no limitation in this regard. Taking any service as an example, the agent in this any service can not only intercept the access requests received on the service port but also intercept the access requests sent from the service port. Specifically, it can be distinguished whether the access request is received on the service port or sent from the service port according to the access direction of the intercepted access request.
[0052] When the access direction of the intercepted access request is the inbound direction, that is, when the access request received on the service port is intercepted, the agent can parse the intercepted access request to obtain the value of the protocol field. For different protocol types, the values of the protocol fields will be different. Therefore, the protocol type of the access request can be identified through the value of the protocol field. For example, when the value of the protocol field meets the first value condition, it is determined that the protocol type of the intercepted access request is a secure protocol type; when the value of the protocol field meets the second value condition, it is determined that the protocol type of the intercepted access request is a non-secure protocol type. In Figure 2 the illustrated embodiment, taking HTTPS as the secure protocol type and HTTP as 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 3 bytes of the access request and determining whether these 3 bytes meet the condition that the first byte is 22 and the second byte is less than 3, or the first byte is 22, the second byte is equal to 3, and the third byte is equal to 0. If it meets the condition, it is determined that the access request is an HTTPS request; otherwise, it is determined that the access request is an HTTP request. Among them, the condition that the first byte is 22 and the second byte is less than 3, or the first byte is 22, the second byte is equal to 3, and the third byte is equal to 0 belongs to the first value condition, and other situations belong to the second value condition.
[0053] Further, when an access request received by the service port is intercepted and the protocol type of the access request is a secure protocol type, such as HTTPS, it indicates 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 control node, and based on the digital certificate of any service, upgrade the security of the transmission link between any service and other services acting as the request sender. This security upgrade process mainly refers to the process of substituting for the identity authentication between any service and other services acting as the request sender and obtaining the key used to decrypt the access request from other services acting as the request sender during this process, and then decrypting the access request using this key and providing it to any service. In the embodiments of the present application, the methods for encrypting and decrypting the access request are not limited, and it can be a symmetric encryption method or an asymmetric encryption method. Correspondingly, the keys used for encryption and decryption will also be different, which is not limited herein, and all embodiments of the present application support this. Correspondingly, when an access request received by the 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.
[0054] When the access direction of the intercepted access request is the outbound direction, that is, when an access request that the service port needs to send out is intercepted, the agent can determine whether other services acting as the request receiver have completed the link upgrade. When other services acting as the request receiver have completed the link upgrade, the proxy module can obtain the digital certificate of any service from the authentication control node, and based on the digital certificate of any service, upgrade the security of the transmission link between any service and other services acting as the request receiver. This security upgrade process mainly refers to the process of substituting for the identity authentication between any service and other services acting as the request sender and encrypting the access request during this process and providing the key used to decrypt the access request to other services acting as the request receiver for other services to decrypt the access request and then report it to the corresponding service. Correspondingly, when an access request that the service port needs to send out is intercepted and other services acting as the request receiver have not completed the link upgrade, the proxy module in any service can directly send the access request to other services acting as the request receiver.
[0055] Further, the system provided by the present application may further include: a service registry. The service registry is used to provide identity registration services for each service in the microservice architecture. Specifically, it can receive an identity registration request initiated by any service, generate and maintain the service detail information of any service according to the identity registration request; and dynamically update the service detail information of any service according to the status change of any service. Among them, the service detail information of any service includes the identity metadata of any service and the information on whether the link upgrade has been completed.
[0056] Optionally, the proxy module can obtain the service detail information of a certain service from the service registry, and determine whether a certain service has completed the link upgrade (whether it has completed the link upgrade can be simply referred to as whether it has accessed zero trust) according to the service detail information. For example, obtain the service detail information of other services as the request receiving end from the service registry, and the service detail information includes whether other services as the request receiving end have completed the link upgrade; according to the service detail information, determine whether other services as the request receiving end have completed the link upgrade.
[0057] Optionally, the authentication control node can also obtain the identity metadata corresponding to any service from the service registry, generate a digital certificate for any service according to the identity metadata corresponding to any service, and issue the digital certificate of any service to the proxy module in any service according to the request of the proxy module.
[0058] In this embodiment, for the proxy module in any service, when any service initiates an access request to other services, it can actively judge the link upgrade situation of the subsequent service and drive itself to perform link upgrade when the subsequent service has completed the link upgrade. Similarly, when receiving an access request sent by other services, it can also actively identify the protocol type of the received access request and drive itself to perform link upgrade when the received access request is of a secure protocol type, realizing two-way driven link upgrade. Preferably, the upgrade process of the entire link can be gradually upgraded forward from the end of the scheduling link, but it is not limited to this, and the call links of multiple services can also be upgraded in parallel to accelerate the service upgrade process.
[0059] Continue to refer to Figure 2 , 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, it can pull the digital certificate of Service B from the authentication control node and perform a security authentication (including encryption of the access request) with Instance 1 of Service C according to the digital certificate. At this time, Instance 1 of Service B completes 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 judge the protocol type of the access request. When it is identified that the protocol type is HTTPS, since Instance 1 of Service C has completed the link upgrade, it can perform a security authentication (including decryption of the access request) with Instance 1 of Service B according to its digital certificate.
[0060] Further, assume that after the instance 1 of Service B completes the link upgrade, the instance 1 of Service A needs to access the instance 1 of Service B. At this time, the proxy module in the instance 1 of Service A can intercept the access request and identify whether the instance 1 of Service B has completed the link upgrade. If it is identified that the instance 1 of Service B has completed the link upgrade, the digital certificate of Service A can be pulled from the authentication control node, and security authentication (including encryption of the access request) can be performed with the instance 1 of Service B based on this digital certificate. At this time, the instance 1 of Service A completes the link upgrade. For the instance 1 of Service B, when receiving the access request sent by the instance 1 of Service A, its proxy module can determine the protocol type of the access request. When it is identified that the protocol type is HTTPS, since the instance 1 of Service B has completed the link upgrade, security authentication (including decryption of the access request) can be performed with the instance 1 of Service A based on its digital certificate.
[0061] Further, when the instance 2 of Service A needs to access the instance 2 of Service B, since the instance 2 of Service B has not yet undergone a link upgrade, at this time, the proxy module in the instance 2 of Service A can intercept the access request and identify whether the instance 2 of Service B has completed the link upgrade. If it is identified that the instance 2 of Service B has not completed the link upgrade, the access request, such as an HTTP request, can be directly sent to the instance 2 of Service B. For the instance 2 of Service B, when receiving the access request sent by the 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 report to the instance 2 of Service B, and the instance 2 of Service B can directly process the access request.
[0062] Furthermore, during the process of link upgrade for 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 this 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, when receiving the access request sent by Instance 2 of Service A, its proxy module can determine the protocol type of this 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 can directly process this access request. Thus, it can be seen that the service port of the same service can process both HTTP requests and HTTPS requests, achieving lossless traffic switching. That is to say, in the full-link upgrade mode, for a service that has completed the link upgrade, it will support single-port dual-protocols (i.e., support both HTTP and HTTPS protocols). In this way, for a certain service that has completed the link upgrade, when an instance of other services calls an instance of this service, if it perceives that the instance of this service has completed the link upgrade, it will use the HTTPS protocol to call this service; if it does not perceive that the instance of this service has completed the link upgrade, it will use the HTTP protocol to call this service. Whether it is an HTTPS access request or an HTTP access request, since this service supports single-port dual-protocols and can process both types of access requests, traffic loss is avoided, achieving lossless traffic upgrade.
[0063] As time goes by, the call links between services are continuously upgraded, and the intermediate state of link security upgrade as shown in Figure 2 can be obtained. Instance 1 of Service C has completed the link upgrade, and some instances of Services A and B have completed the upgrade. In Figure 2 , the shaded instances are the ones that have completed the upgrade.
[0064] As shown in Figure 2 , Instance 1 of Service C first completes the link upgrade. At this time, a certain instance in Service B (such as Instance 1) takes the lead in perceiving that Service C has completed the link upgrade when requesting services from Instance 1 of Service C, and then drives itself to complete the link upgrade. Further, Instance 1 of Service A takes the lead in perceiving that Instance 1 of Service B has completed the link upgrade when requesting services from Instance 1 of Service B, and then drives itself to complete the link upgrade, and so on, until all links are completed with the upgrade to obtain the final state of link upgrade as shown in Figure 2 . At this time, the call methods between all instances have been switched to the HTTPS security protocol.
[0065] It should be noted that after the security upgrade is completed across the entire link, the proxy modules in each service will intercept access requests of non-secure protocol types (such as HTTP requests) sent by their respective services, upgrade the intercepted access requests to secure protocol type access requests (such as HTTPS requests), and then complete the secure transmission process with the peer using the authentication method supported by the secure transmission protocol.
[0066] Here it is explained that in the above or below embodiments, "the service completes the link upgrade" and "the service accesses zero trust" are different expressions of the same meaning. In this embodiment, the proxy module will intercept the call of this service to subsequent services, and determine whether the subsequent services access zero trust. When the subsequent services have accessed zero trust, the transmission link will be upgraded for security and two-way authentication will be completed based on digital certificates. When the subsequent services do not access zero trust services, the requests sent will remain of non-secure protocol type.
[0067] In an optional embodiment, when the proxy module in any of the above services upgrades the security of the transmission link between any service and other services acting as the request receiving end or request sending end according to the digital certificate of any service, two-way authentication is performed between any service and other services acting as the request receiving end or request sending end according to the digital certificate of any service. When both-way authentication passes, it is determined that the security upgrade of the transmission link between any service and other services acting as the request receiving end or request sending end is completed.
[0068] As Figure 3 shown, it is a schematic diagram of the process of two-way authentication between any service and other services acting as the request receiving end or request sending end, taking the HTTPS protocol as an example. Among them, any service can be specifically implemented as the client or server in the figure, and other services can be implemented as the peer of any service, that is, 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 digital certificate of the server to the client; the client verifies whether the digital certificate of the server is legal, and when the verification passes, sends the digital certificate of the client to the server; the server verifies whether the digital certificate of the client is legal, and when the digital certificate of the client passes the verification, the two parties shake hands successfully. When the two-way authentication is successful, the client and the server perform data transmission through an encrypted TLS connection, and the data transmission process is not shown in the figure.
[0069] In the embodiments of the present application, in order to facilitate the proxy module to identify whether the full link in the microservice architecture has been upgraded, the full link upgrade completion condition is set, and the full link upgrade completion condition is not limited. In an optional embodiment, the active time threshold K1 and the lazy time threshold K2 can be set, and the active time threshold K1 and the lazy time threshold K2 are used as a specific implementation of the full link upgrade completion condition. The active time threshold K1 refers to a recent period of time, for example, it can be the recent 3 seconds, the recent 10 seconds, etc.; the lazy time threshold K2 is a relatively long period of time after a certain time point, for example, 30 minutes, 1 hour, etc. after a certain time point. Relatively speaking, the lazy 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 access requests of non-secure protocol types received and sent by the service port of any service within the set active time threshold K1; in the case where this number is less than the first number threshold, this 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 access requests of non-secure protocol types received within the recent K1 time, if this number is small (that is, less than the first number threshold), it indicates 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 that the set lazy time threshold K2 has arrived, it is determined that the full link upgrade completion condition is met. In this case, enough time K2 is given for each service to have sufficient time to complete the link upgrade, and after the time K2 arrives, it is considered that any service has completed the link upgrade. Among them, the start time of the lazy time threshold K2 is the time when the proxy module in any service receives the lazy time threshold K2, that is, the proxy module starts timing the lazy time threshold K2 since it receives the lazy time threshold K2. Optionally, after determining that the full link upgrade condition is met, the proxy module of any service will enter a mode of rejecting access requests of non-secure protocol types, and this mode can also be called the security authentication mode. In this security authentication mode, when the proxy module determines that the type of the intercepted access request is a non-secure protocol type, it directly rejects the access request.
[0070] In an optional embodiment, the authentication control node can provide an external control interface, which can be a web page, a command window, or an application page, without limitation. Based on this, the setting of the active time threshold and the lazy time threshold can be completed by the micro-service system administrator or the system operator through the control interface provided by the authentication control node. Among them, the setting of the active time threshold and the lazy time threshold can be flexibly set according to the requirements of different services. The active time threshold and the lazy time threshold corresponding to different services can be different or the same, and this application does not make any limitations. Based on this, the authentication control node is also used to obtain the active time threshold and the lazy time threshold set by the user for any service in response to the time setting operation on the control interface; and send the active time threshold and the lazy time threshold to the proxy module in any service. The user here can be, but is not limited to, the system administrator or the operator.
[0071] 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 the service from the perspective of an observer, and report the trust data and call relationship of the service to the authentication control node for the authentication control node to generate the authentication policy information of the service according to the trust data and call relationship of the service; after the authentication control node generates the authentication policy information of the service, it will send the authentication policy information to the proxy module in any service for the proxy module to perform security authentication on the access request to the service according to the authentication policy information, realizing a systematic authentication rule generation method. At this time, the authentication policy information can be regarded as the initial authentication policy information. With the appearance of illegal access requests, 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 for updating the authentication policy information when it is found that the trust data and / or call relationship of any service has changed.
[0072] In the embodiment of this application, the implementation manner of the proxy module for obtaining the trust data of any service is not limited. In an optional embodiment, when obtaining the trust data of any service, the proxy module can obtain the multi-dimensional credibility influence parameters and the target service set corresponding to the service, and the target service set includes information about other services that request to call the service; and generate the trust data according to the multi-dimensional credibility influence parameters and the target service set. The credibility influence parameter refers to a parameter that affects the credibility of any service, which can include multiple dimensions, and specific examples can be found in the following embodiments; among them, the information about other services that request to call the service will also affect the credibility of the service.
[0073] In the embodiments of the present application, the implementation manner of the trust degree data is not limited, and any data form that can represent the trust situation or security of any service is applicable to the embodiments of the present application. Optionally, one implementation of the trust degree data includes a trust index and a trust threshold. Based on this, according to multi-dimensional credibility influence parameters and a target service set, trust degree data is generated, including: generating a trust index for any service according to the multi-dimensional credibility influence parameters, where the trust index is used to represent the trust degree 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 indices of each service in the target service set, and the trust threshold is used to reflect the trust degree condition that any service should meet when allowing other services to access it.
[0074] Further optionally, when generating a trust index for any service according to the multi-dimensional credibility influence parameters, trust value calculations can be performed respectively according to the multi-dimensional credibility influence parameters to obtain multi-dimensional trust values; and the multi-dimensional trust values are weighted and summed according to the weights corresponding to the multi-dimensional credibility influence parameters to obtain the trust index of any service. Exemplarily, the multi-dimensional credibility influence parameters mentioned in the above embodiments include but are not limited to: the set of deployment environments where any service is located, the set of service environments where it is located, and the incoming traffic rate and outgoing traffic rate of any service. The set of deployment environments includes at least one deployment environment, and the deployment environment 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 levels of different deployment environments are different, and different deployment environments have different security water levels; the set of service environments includes at least one service environment, and the service environment refers to the application environment where the service is located, or the scope of the service, and may 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 multiple e-commerce applications, or in a wealth management application and a video application, etc. These e-commerce applications, wealth management applications, or video applications are the service environments of the payment service. The security levels of different service environments are different, and different service environments have different security water levels. The incoming traffic rate and outgoing traffic rate can be obtained by a service agent of any service monitoring the traffic of the service port. Optionally, the incoming traffic rate and outgoing traffic rate are the average traffic within 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:
[0075]
[0076] In the above formula, α, β, γ, δ, ε are the weights of the preset various credibility influence parameters, which can also be called variable coefficients, SafeWater iis the security water level of the deployment environment i or the service environment i, BusinessZoneSet x is the set of service environments where service x is located, DeployZoneSet x is the set of deployment environments where service x is located, InflowRate x is the inflow rate of service x, OutflowRate x is the outflow 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 indices of each service in the target service set, a reference trust index can be generated based on the trust indices of each service in the target service set, the difference between the reference trust index and the trust index of any service can be calculated, and this difference can be used as the trust threshold of any service. This means that when a certain service accesses this any service, the difference between the trust index of this certain service and the trust index of this any service should be greater than or equal to the trust threshold of this any service, which indicates that a certain service is trustworthy and secure for this any service, so a certain service can be allowed to access this any service. The reference trust index can be the minimum value or the average value or the weighted sum value of the trust indices of each service in the target service set, and there is no limitation on this. Optionally, in the case of using the minimum value of the trust indices of each service in the target service set as the reference trust index, the way to generate the trust threshold (threshold) of service x can be expressed by the following formula:
[0078]
[0079] In the above formula, InFlowSet x is the target service set that calls service x, and the agent will record which services call service x to form the target service set corresponding to this service x, cert i 、cert x are the trust indices of service i and service x respectively, and the trust indices of service i and service x can be calculated through the above trust index calculation formula.
[0080] In the above embodiment, taking the trust degree data including the trust index and the trust threshold as an example, the process of obtaining the trust index and the trust threshold is exemplarily described, but the implementation manner of the trust degree data is not limited to this. For example, the trust degree data can also only contain the trust index, or only contain the trust threshold, or can also contain other forms of data. Among them, for the case of only containing the trust index, when the trust index of other services is greater than the trust index of this any service, it indicates that other services are trustworthy for this any service, and other services can be allowed to access this any service.
[0081] In an alternative embodiment, when obtaining the call relationship information of any service, the proxy module of any service may intercept the access requests sent and received by the service port of any service, and determine the call relationship information of any service according to the intercepted access requests and their access directions. Optionally, the call relationship information mainly refers to the information of other services that call any service. Of course, it may also include the information of other services called by any service.
[0082] In this embodiment, when obtaining the trustworthiness data and call relationship information of any service, the proxy module of any service may report them to the authentication and control node. The authentication and control node may generate the authentication policy information of any service according to the trustworthiness data and call relationship information of any service. In an alternative embodiment, when generating the authentication policy information of any service according to the trustworthiness data and call relationship information of any service, the authentication and control node obtains the trustworthiness data of each service in the target service set according to the call relationship information of any service. The above target service set includes the information of other services that request to call any service; from the target service set, obtain the first service whose trustworthiness data is greater than the trustworthiness data of any service; since the trustworthiness data of the first service is greater than the trustworthiness data of any service, it indicates that the first service is safe and trustworthy relative to any service. Therefore, an authentication policy information allowing the first service to access any service may be generated for any service.
[0083] It should be noted here that depending on the different implementations of the trustworthiness data of any service, the implementation manner of the authentication and control node for obtaining the first service whose trustworthiness data is greater than the trustworthiness data of any service and generating the authentication policy information allowing the first service to access any service will also be different. The following is an example: Optionally, when the trustworthiness data is implemented as a trust index, obtain the service whose trust index is greater than the trust index of any service from the target service set as the first service, and generate the authentication policy information allowing the first service to access any service. In another alternative embodiment, the trustworthiness data includes a trust index and a trust threshold, then obtain the 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 from the target service set as the first service, and generate the authentication policy information allowing the first service to access any service.
[0084] In the embodiments of the present application, the authentication policy information can be implemented in the form of a whitelist and / or a blacklist. Optionally, when the authentication policy information is implemented as a whitelist, the authentication policy information of any service includes information about other services allowed to call the any service, and only the services included in the whitelist have the permission to call the any service. When the authentication policy information is implemented as a blacklist, the authentication policy information of any service includes information about other services prohibited from calling the any service, and the services in the blacklist are prohibited from accessing the any service. Correspondingly, the services not in the blacklist have the permission to call the any service. Of course, the authentication policy information can be implemented as both a whitelist and a blacklist at the same time. The whitelist stores information about other services allowed to access the any service, and the blacklist stores information about other services not allowed to access the any service.
[0085] As Figure 4a shown, there are call relationships among services A-K. Specifically, the proxy modules in services A-K respectively report the trust index, trust threshold, and call relationship of their respective services to the authentication control node; the authentication control node generates respective authentication policy information for services A-K according to the trust index, trust threshold, and call relationship of services A-K respectively, and distributes the respective authentication policy information of services A-K to the proxy modules in services A-K respectively; the call topology relationship among services A-K can be obtained according to the respective authentication policy information of services A-K, that is, service K allows service A to call, service H allows service E to call, service F allows services B and C to call, service I allows service F to call; service G allows service D to call, service J allows services E and G to call, and service K allows services E and F to call. In Figure 4a it, a solid line with an arrow represents the call relationship between two services, and the service pointed to by the arrow allows the other service connected by the solid line to call it. After obtaining the authentication policy information, the proxy modules in services A-K enter the automatic authentication mode and will perform security authentication on the access requests received by their respective services according to their respective authentication policy information. Taking the authentication policy information implemented as a whitelist as an example, the proxy modules in services A-K can determine whether the sender of the access request is in the whitelist. If it is in the whitelist, the access request will be reported to the application to which it belongs; if it is not in the whitelist, the access request will be regarded as an illegal access request and the access request will be rejected.
[0086] Continuing from the foregoing embodiments, when the multi-dimensional credibility influence parameters corresponding to any service change and / or the services in the target service set change, the trustworthiness data of any service will be affected. When the multi-dimensional credibility influence parameters include several dimensions such as the deployment environment set where the any service is located, the service environment set where it is located, and the incoming traffic rate and outgoing traffic rate of the any service, a change in any dimension may cause the trustworthiness data to change. The situations where the services in the target service set change include at least one of the following: adding other services that hope to call the any service, deleting other services that already have the permission to call the any service. Based on this, the proxy module in any service is further configured to monitor whether the multi-dimensional credibility influence parameters corresponding to any service change and / or whether the services in the target service set change, and when it is monitored that the multi-dimensional credibility influence parameters corresponding to any service change and / or the services in the target service set change, update the trustworthiness data of any service and report it to the authentication and control node. Among them, the method of updating the trustworthiness data of any service is the same as the method of generating the trustworthiness data in the above embodiments, and the method shown by the above formula can be referred to. The difference is that the data participating in the calculation will be different. Correspondingly, the authentication and control node is further configured to: receive the updated trustworthiness data of any service reported by the proxy module in any service, and send the updated trustworthiness data of any service to the proxy modules in other services called by the any service, so that the proxy modules in other services can perform security authentication on the any service according to the updated trustworthiness data of the any service when the any service accesses other services.
[0087] Similarly, for the case where the trustworthiness data of other services that have the permission to call any service changes, for the sake of easy description and distinction, taking the second service as an example, the second service is first an other service that has the permission to call any service, is located in the authentication whitelist of any service, and the trustworthiness data of the second service has changed. The authentication control node will obtain the updated trustworthiness data of the second service reported by the proxy module in the second service, and will send the updated trustworthiness data of the second service to each service (including the any service) that the second service needs to call. Correspondingly, the proxy module of any service is also used to: receive the updated trustworthiness data of the second service that calls the any service sent by the authentication control node, and the second service is a subset of the first service. Further, the proxy module in any service is also used to: when intercepting an access request from the second service at 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 located in the whitelist, so the second service can pass the first security authentication based on the whitelist, but since the trustworthiness data of the second service has changed compared with before, in order to ensure the security of any service, when the second service passes the first security authentication, according to the trustworthiness data of any service and the updated trustworthiness data of the second service, perform a second security authentication on the second service. For example, it can be determined whether the updated trustworthiness data of the second service is greater than the trustworthiness data of any service, or it can be determined whether the updated trustworthiness data of the second service is greater than the trustworthiness 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 passes the second security authentication, otherwise, it is determined that the second service fails the second security authentication.
[0088] In an optional embodiment, the proxy module in any service is also used to: when the second service fails the second security authentication, report the access request from the second service to the authentication defense node for updating the authentication policy information; the authentication defense node is also used to: according to the access request from the second service reported by the proxy module in any service, update the authentication policy information of any service 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. Taking the whitelist as an example, the second service can be removed from the whitelist of any service, and the updated whitelist is 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 can synchronize the updated whitelist to the proxy module in any service through the authentication control node.
[0089] In one example, due to changes in the deployment environment of a certain service, its trustworthiness data changes, 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. For example Figure 4a and Figure 4b As shown, assume that Service A (equivalent to the second service in the above embodiment) was originally deployed in cluster i1 of K8s, and subsequently Service A was migrated from cluster i1 to cluster i2. Due to the change in the deployment environment, the trustworthiness data of Service A changes. In this case, the proxy module in Service A will recalculate the trustworthiness data of Service A according to the new deployment environment, and report the changed trustworthiness data to the authentication control node. In Figure 4a the dotted line from Service A to the authentication control node represents the process by which the proxy module in Service A reports the updated trustworthiness data of Service A to the authentication control node. For the authentication control node, it will synchronize the updated trustworthiness data of Service A to the proxy modules in each service called by Service A. In Figure 4a take Service E as an example. As shown in Figure 4a the dotted line from the authentication control node to Service A represents the process by which the authentication control node synchronizes the updated trustworthiness data of Service A to the proxy module in Service E.
[0090] Furthermore, when the proxy module in Service E intercepts an 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 determine whether the trustworthiness data of Service A is greater than the trustworthiness data of Service E or determine whether the trustworthiness data of Service A is greater than the trustworthiness 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 Service A to call. Otherwise, it rejects the call of Service A. Further, as shown in Figure 4b the solid line with "×" represents 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 for updating the authentication policy information, as shown by the dotted line from Service E to the authentication defense node in Figure 4b ; the authentication defense node updates the authentication policy information of Service E according to 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 Figure 4b ; at this time, the service call topology relationship between Service A - K has changed compared to that shown in Figure 4a as shown, see Figure 4b and the access permission from Service A to Service E is deleted.
[0091] In the above embodiment, in order to distinguish the functions of the authentication defense node and the authentication control node, the authentication defense node and the authentication control node are implemented as two different nodes, but it is not limited to this. In an optional embodiment, for the convenience of management, the authentication defense node and the authentication control node can be implemented as one node, which has all the functions of the authentication defense node and the authentication control node.
[0092] In another example, for any service, a new service that calls any service is added, thereby triggering the proxy module, the authentication defense node and the authentication management node to automatically update the authentication policy information of any service. Figure 4c As shown in the figure, 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 permission of service G and service K. The authentication policy information is used as the whitelist, that is, the whitelist of service G and service K does 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. Figure 4c The solid line with “×” in the figure will report the access request to the authentication defense node, such as Figure 4c As shown in the figure, the dotted line pointing from service G and service K to the authentication defense node; the authentication defense node determines whether the newly added service L has the authority to call service G and service K based on the trust data of service L, the trust data of 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. So far, after the addition of service L, the calling topology relationship between services is relative to Figure 4c As shown, changes have occurred, such as Figure 4d As shown, the calling relationship between service L, service G and service K is added.
[0093] In the embodiments of the present application, in order to facilitate the implementation of active authentication defense, authentication defense conditions are set, but the specific implementation methods of the authentication defense conditions are not limited. Any conditions that can enable the authentication defense node to automatically determine whether to update the relevant authentication policy information are applicable to the embodiments of the present application. In an alternative embodiment, an interception time threshold K3, a defense function activation count threshold M1, and a defense function deactivation count 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 count threshold M1 is the count threshold of illegal access requests that determines whether to activate the active authentication defense function. The defense function deactivation count threshold M2 is the count threshold of illegal access requests that determines whether to deactivate the active authentication defense function. Relatively speaking, the defense function deactivation count threshold M2 is less than the defense function activation count threshold M1. The authentication defense conditions can be generated using the interception time threshold K3, the defense function activation count threshold M1, and the defense function deactivation count threshold M2. 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 count threshold M1, the authentication defense mode is activated. For example, if the authentication defense node discovers that there are M1 access requests from the same IP among the illegal access requests within the K3 time, and this IP has been continuously attempting to access a certain or certain services and has been rejected by these services, it can be determined that there is a security risk for this IP. The authentication defense node can identify this IP as a malicious IP and update the authentication policy information for all services to prohibit the above IP from accessing any service, and synchronize the updated authentication policy information to the proxy modules in each service, so that the proxy modules in each service reject access requests from this 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 continuously 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 deactivation count threshold M2, this means that the network threat has decreased, and the authentication defense mode is exited, regarding the active authentication defense function.
[0094] It should be noted here that regarding how to actively defend against these illegal access requests when the illegal access requests meet the authentication defense conditions, it can be flexibly implemented according to application requirements or system security requirements. In the above embodiments, the example of prohibiting all services from accessing the access requests of this IP when it is monitored that the illegal access requests meet the authentication defense conditions is only one example of active defense and is not limited thereto.
[0095] In the embodiments of the present application, with the help of the proxy module, each service realizes the function of a single port with dual protocols, which provides conditions for realizing lossless traffic upgrade to zero trust in the microservices architecture. In addition, a new HTTPS port different from the original HTTP port can also be newly opened, and then the traffic is gradually migrated from the HTTP port to the HTTPS port. After all the traffic is switched to the HTTPS port, the HTTP port is closed. One reason is that it occupies new port resources, and the other reason is that when there is hard coding in the microservice pointing to the original HTTP port, the code also needs to be modified to point to the new HTTPS port. Compared with the solution of newly opening an HTTPS port, the embodiments of the present application adopt the method of a single port with dual protocols, which saves port resources and can also avoid the problem of application code modification brought by newly opening a port, reducing the complexity of the migration process from the HTTP port to the HTTPS port.
[0096] In addition, in the embodiments of the present application, the full-link upgrade completion condition is set to allow the proxy module to realize the automatic security upgrade of the link, without the user caring about the upgrade process, and the automation of the upgrade process is realized. Compared with the method of manually judging whether the upgrade is completed, the efficiency is higher.
[0097] Furthermore, compared with manually configuring a complete set of authentication rules that meet the zero-trust requirements, in the embodiments of the present application, the proxy module dynamically observes the trust degree data and call degree relationship of any service, and can actively trigger the update of the authentication policy information when changes are found; and, with the appearance of illegal access requests, the authentication policy information can be automatically updated, realizing the active defense and counterattack of security authentication, which can reduce the complexity of authentication rule configuration and management.
[0098] Figure 5 It is a schematic flow chart of the microservice security access method provided by an exemplary embodiment of the present application; it is applicable to the proxy module injected into any service, and the proxy module shares the service port of the any service. For the relevant descriptions of the proxy module and the service, reference can be made to the foregoing system embodiments, which will not be elaborated here. As Figure 5 shown, the method includes:
[0099] S51: In the full-link upgrade mode, according to the protocol type and access direction of the access requests received and sent by the service port of any service, perform full-link security upgrade on any service, and enter the security authentication mode when the full-link upgrade completion condition is met;
[0100] S52: In the security authentication mode, according to the authentication policy information issued by the authentication control node, perform security authentication on the access requests received by the service port of any service, and report the illegal access requests that fail the security authentication to the authentication defense node for the authentication defense node to update the authentication policy information.
[0101] In an optional embodiment, according to the protocol type and access direction of the access requests received and sent through the service port of any service, perform a full-link security upgrade on any service, including: in the full-link upgrade mode, intercept the access requests received and sent through the service port of any service; when the access direction of the intercepted access request is the incoming direction and its protocol type is a security protocol type, obtain the digital certificate of any service from the authentication control node, and according to the digital certificate of any service, perform a security upgrade on the transmission link between any service and other services acting as the request sender; when the access direction of the intercepted access request is the outgoing direction and other services acting as the request receiver have completed the link upgrade, obtain the digital certificate of any service from the authentication control node, and according to the digital certificate of any service, perform a security upgrade on the transmission link between any service and other services acting as the request receiver.
[0102] In an optional embodiment, determining that the full-link upgrade completion condition is met includes: monitoring the number of access requests received and sent through the service port of any service within a set active time threshold; when the number is less than the first number threshold, determining that the full-link upgrade completion condition is met; and / or, when it is monitored that the set idle time threshold has arrived, determining that the full-link upgrade completion condition is met. The proxy module in any service starts timing the idle time threshold since it receives the idle time threshold, and the idle time threshold is greater than the active time threshold.
[0103] In an optional embodiment, the method provided in this embodiment further includes: generating the trust degree data of any service according to the multi-dimensional credibility influence parameters corresponding to any service and the target service set, where the target service set includes information about other services that request to invoke the any service; determining the call relationship information of any service according to the access requests received and sent through the service port of any service and their access directions; reporting the trust degree data and call relationship information of any service to the authentication control node for the authentication control node to generate the authentication policy information of any service.
[0104] In an optional embodiment, generating the trust degree data of any service according to the multi-dimensional credibility influence parameters and the target service set includes: generating the trust index of any service according to the multi-dimensional credibility influence parameters, and obtaining the trust indexes of each service in the target service set; generating the trust threshold of any service according to the trust index of any service and the trust indexes of each service in the target service set.
[0105] In an optional embodiment, generating a trust index for any service according to multi-dimensional credibility influence parameters includes: calculating trust values respectively according to the multi-dimensional credibility influence parameters to obtain multi-dimensional trust values; performing weighted summation on the multi-dimensional trust values according to the weights corresponding to the multi-dimensional credibility influence parameters to obtain the trust index of any service.
[0106] In an optional embodiment, the method provided in this embodiment further includes: updating the trust degree data of any service when the multi-dimensional credibility influence parameters corresponding to any service change and / or the services in the target service set change; reporting the updated trust degree data of any service to the authentication and control node for the authentication and control node to send down to the proxy module in other services called by any service.
[0107] In an optional embodiment, the method provided in this embodiment further includes: receiving the updated trust degree data of the second service that calls any service sent down by the authentication and control node, where the second service is another service that has the permission 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 according to the authentication policy information of any service; when the second service passes the first security authentication, performing a second security authentication on the second service according to the trust degree data of any service and the updated trust degree data of the second service.
[0108] In an optional embodiment, when the second service fails the second security authentication, the above method further includes: reporting the access request from the second service to the authentication defense node for updating 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.
[0109] Figure 6 It is a schematic flowchart of the microservice security access method provided in an exemplary embodiment of this application. This method is applied to the authentication and control node. For the relevant description of the authentication and control node, reference can be made to the foregoing system embodiment, which will not be elaborated here. As Figure 6 shown, this method includes:
[0110] S61: Obtain the trust degree data and call relationship information of any service. A proxy module is injected into any service, and the proxy module shares the service port of any service;
[0111] S62: Generate the authentication policy information of any service according to the trust degree data and call relationship information of any service;
[0112] S63: Send down the authentication policy information of any service to the proxy module in any service for the proxy module to perform security authentication on the access requests received at the service port in the security authentication mode.
[0113] In an optional embodiment, authentication policy information for any service is generated according to the trustworthiness data and call relationship information of any service, including: obtaining the trustworthiness data of other services of each service in the target service set according to the call relationship information of any service, where the target service set includes information about other services that request to call any service; obtaining, from the target service set, a first service whose trustworthiness data is greater than the trustworthiness data of any service; and generating, for any service, authentication policy information that allows the first service to access any service.
[0114] It should be noted that the execution subject of each step of the method provided in the above embodiment can be the same device, or the method can also be executed by different devices as the execution subject. For example, the execution subject of steps 51 to 52 can be device A; or, the execution subject of steps 51 and 52 can be device A, and the execution subject of step 52 can be device B; and so on.
[0115] In addition, in some processes described in the above embodiments and the accompanying drawings, a plurality of operations appear in a specific order. However, it should be clearly understood that these operations can be executed not in the order in which they appear in this document or in parallel. The operation numbers such as 51, 52, etc. are only used to distinguish different operations, and the numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and these operations can be executed in sequence or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequence, nor do they limit that "first" and "second" are of different types.
[0116] Figure 7 This is a schematic structural diagram of a microservice security access device provided for an exemplary embodiment of the present application. As Figure 7 shown, the device 700 includes: an upgrade module 701 and an authentication module 702, where:
[0117] The upgrade module 701 is configured to perform full-link security upgrade on any service according to the protocol type and access direction of the access request received and sent by the service port of any service in the full-link upgrade mode, and enter the security authentication mode when the full-link upgrade completion condition is met;
[0118] The authentication module 702 is used to perform security authentication on the access requests received at the service port of any service according to the authentication policy information sent by the authentication control node in the security authentication mode, and report the illegal access requests that fail the security authentication to the authentication defense node for the authentication defense node to update the authentication policy information; wherein, the authentication policy information is generated according to the trust degree data and call relationship information of any service.
[0119] Further optionally, when the upgrade module 701 performs full-link security upgrade on any service according to the protocol type and access direction of the access requests received and sent at the service port of any service, it is specifically used for: intercepting the access requests received and sent at the service port of any service in the full-link upgrade mode; when the access direction of the intercepted access request is the incoming direction and its protocol type is the security protocol type, obtaining the digital certificate of any service from the authentication control node, and performing 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 outgoing direction and other services as the request receiver have completed the link upgrade, obtaining the digital certificate of any service from the authentication control node, and performing security upgrade on the transmission link between any service and other services as the request receiver according to the digital certificate of any service.
[0120] Further optionally, when the upgrade module 701 determines that the full-link upgrade completion condition is met, it is specifically used for: monitoring the number of access requests received and sent at the service port of any service within the set active time threshold; determining that the full-link upgrade completion condition is met when the number is less than the first number threshold; and / or, determining that the full-link upgrade completion condition is met after monitoring that the set lazy time threshold arrives, the proxy module in any service starts timing for the lazy time threshold since it receives the lazy time threshold, and the lazy time threshold is greater than the active time threshold.
[0121] Further optionally, the authentication module 702 is also used for: generating the trust degree data of any service according to the multi-dimensional credibility influence parameters corresponding to any service and the target service set, where the target service set includes information of other services that request to call any service; determining the call relationship information of any service according to the access requests received and sent at the service port of any service and their access directions; reporting the trust degree data and call relationship information of any service to the authentication control node for the authentication control node to generate the authentication policy information of any service.
[0122] Further optionally, when generating the trustworthiness data of any service according to the multi-dimensional credibility influence parameters and the target service set, the authentication module 702 is specifically configured to: generate a trust index of any service according to the multi-dimensional credibility influence parameters, and obtain the trust indexes of each service in the target service set; generate a trust threshold of any service according to the trust index of any service and the trust indexes of each service in the target service set.
[0123] Further optionally, when generating the trust index of any service according to the multi-dimensional credibility influence parameters, the authentication module 702 is specifically configured to: calculate trust values respectively according to the multi-dimensional credibility influence parameters to obtain multi-dimensional trust values; perform weighted summation on the multi-dimensional trust values according to the weights corresponding to the multi-dimensional credibility influence parameters to obtain the trust index of any service.
[0124] Further optionally, the authentication module 702 is further configured to: update the trustworthiness data of any service when the multi-dimensional credibility influence parameters corresponding to any service change and / or the services in the target service set change; report the updated trustworthiness 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.
[0125] Further optionally, the authentication module 702 is further configured to: receive the updated trustworthiness data of the second service that calls any service sent by the authentication control node, where the second service is other services that have the permission to access any service; and when an access request from the 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; when the second service passes the first security authentication, perform a second security authentication on the second service according to the trustworthiness data of any service and the updated trustworthiness data of the second service.
[0126] Further optionally, when the second service fails the second security authentication, the authentication module 702 is further configured to: report the access request from the second service to the authentication defense node for updating 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.
[0127] Figure 8 This is a schematic structural diagram of another microservice security access device provided by an exemplary embodiment of the present application. As Figure 8As shown, the device 800 includes: an acquisition module 801, a generation module 802, and a sending module 803, where:
[0128] The acquisition module 801 is configured to acquire trustworthiness data and call relationship information of any service. The any service is injected with an agent module, and the agent module shares the service port of the any service.
[0129] The generation module 802 is configured to generate authentication policy information of the any service according to the trustworthiness data and call relationship information of the any service.
[0130] The sending module 803 is configured to send the authentication policy information of the any service to the agent module in the any service, so that the agent module performs security authentication on the access request received at the service port in the security authentication mode.
[0131] Further optionally, when generating the authentication policy information of the any service according to the trustworthiness data and call relationship information of the any service, the generation module 802 is specifically configured to: acquire the trustworthiness data of other services of each service in the target service set according to the call relationship information of the any service, where the target service set includes information of other services that request to call the any service; acquire a first service in the target service set whose trustworthiness data is greater than the trustworthiness data of the any service; and generate, for the any service, authentication policy information that allows the first service to access the any service.
[0132] Figure 9 The structural schematic diagram of an electronic device provided by an exemplary embodiment of the present application. As Figure 9 shown, the device includes: one or more memories 901 and one or more processors 902.
[0133] The 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 these data include instructions for any application program or method for operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc.
[0134] The memory 901 can be implemented by any type of volatile or non-volatile storage 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, a magnetic disk, or an optical disc.
[0135] A processor 902, coupled to a memory 901, is configured to execute a computer program in the memory 901 for: in the full-link upgrade mode, perform a full-link security upgrade on any service according to the protocol type and access direction of access requests received and sent by the service port of the any service, and enter the security authentication mode when the full-link upgrade completion condition is met; in the security authentication mode, perform security authentication on access requests received by the service port of the any service according to the authentication policy information sent by the authentication control node, and report illegal access requests that fail the security authentication to the authentication defense node for updating the authentication policy information; wherein, the authentication policy information is generated according to the trust degree data and call relationship information of the any service.
[0136] In an optional embodiment, when the processor 902 performs a full-link security upgrade on any service according to the protocol type and access direction of access requests received and sent by the service port of the any service, it is specifically configured to: in the full-link upgrade mode, intercept access requests received and sent by the service port of the any service; when the access direction of the intercepted access request is the incoming direction and its protocol type is a security protocol type, obtain the digital certificate of the any service from the authentication control node, and perform a security upgrade on the transmission link between the any service and other services as the request sender according to the digital certificate of the any service; when the access direction of the intercepted access request is the outgoing direction and other services as the request receiver have completed link upgrade, obtain the digital certificate of the any service from the authentication control node, and perform a security upgrade on the transmission link between the any service and other services as the request receiver according to the digital certificate of the any service.
[0137] In an optional embodiment, when the processor 902 determines that the full-link upgrade completion condition is met, it is specifically configured to: monitor the number of access requests received and sent by the service port of the any service within a set active time threshold; determine that the full-link upgrade completion condition is met when the number is less than the first number threshold; and / or, determine that the full-link upgrade completion condition is met after monitoring that a set idle time threshold arrives, a proxy module in the any service starts timing the idle time threshold since receiving the idle time threshold, and the idle time threshold is greater than the active time threshold.
[0138] In an alternative embodiment, the processor 902 is further configured to: generate trustworthiness data for any one of the services according to the multi-dimensional trustworthiness influence parameters corresponding to the any one of the services and the target service set, where the target service set includes information about other services that request to invoke the any one of the services; determine the call relationship information of the any one of the services according to the access requests received and sent by the service port of the any one of the services and their access directions; and report the trustworthiness data and the call relationship information of the any one of the services to the authentication and control node for the authentication and control node to generate the authentication policy information for the any one of the services.
[0139] In an alternative embodiment, when generating the trustworthiness data for any one of the services according to the multi-dimensional trustworthiness influence parameters and the target service set, the processor 902 is specifically configured to: generate a trust index for the any one of the services according to the multi-dimensional trustworthiness influence parameters, and obtain the trust indices of the services in the target service set; and generate a trust threshold for the any one of the services according to the trust index of the any one of the services and the trust indices of the services in the target service set.
[0140] In an alternative embodiment, when generating the trust index for any one of the services according to the multi-dimensional trustworthiness influence parameters, the processor 902 is specifically configured to: perform trust value calculations respectively according to the multi-dimensional trustworthiness influence parameters to obtain multi-dimensional trust values; and perform weighted summation on the multi-dimensional trust values according to the weights corresponding to the multi-dimensional trustworthiness influence parameters to obtain the trust index of the any one of the services.
[0141] In an alternative embodiment, the processor 902 is further configured to: update the trustworthiness data of any one of the services when the multi-dimensional trustworthiness influence parameters corresponding to the any one of the services change and / or the services in the target service set change;
[0142] Report the updated trustworthiness data of the any one of the services to the authentication and control node for the authentication and control node to send it to the proxy module in other services invoked by the any one of the services.
[0143] In an alternative embodiment, the processor 902 is further configured to: receive the updated trustworthiness data of a second service that invokes the any one of the services sent by the authentication and control node, where the second service is another service that has the permission to access the any one of the services; and when intercepting an access request from the second service at the service port of the any one of the services, perform a first security authentication on the second service according to the authentication policy information of the any one of the services; and when the second service passes the first security authentication, perform a secondary security authentication on the second service according to the trustworthiness data of the any one of the services and the updated trustworthiness data of the second service.
[0144] In an optional embodiment, when the second service fails the secondary security authentication, the processor 902 is further configured to: report the access request from the second service to the authentication and defense node for updating 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.
[0145] The detailed implementation manners and beneficial effects of the steps in the method of this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated herein.
[0146] Further, as Figure 9 shown, the electronic device further includes: a power supply component 903 and other components. Figure 9 Only some components are schematically shown in Figure 9 and it does not mean that the electronic device only includes
[0147] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, it can implement the steps executable by the electronic device in the above method embodiment.
[0148] Figure 10 It is a schematic structural diagram of another electronic device provided for another exemplary embodiment of the present application. As Figure 10 shown, the device includes: one or more memories 1001 and one or more processors 1002.
[0149] The 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 these data include instructions for any application program or method for operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc.
[0150] The memory 1001 can be implemented by any type of volatile or non-volatile storage 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.
[0151] A processor 1002, coupled to a memory 1001, is configured to execute a computer program in the memory 1001 for: obtaining trustworthiness data and call relationship information of any service, where the any service is injected with an agent module, and the agent module shares a service port of the any service; generating authentication policy information of the any service according to the trustworthiness data and call relationship information of the any service; and sending the authentication policy information of the any service to the agent module in the any service for the agent module to perform security authentication on an access request received at the service port in a security authentication mode.
[0152] In an optional embodiment, when generating the authentication policy information of the any service according to the trustworthiness data and call relationship information of the any service, the processor 1002 is specifically configured to: obtain trustworthiness data of other services of each service in a target service set according to the call relationship information of the any service, where the target service set includes information of other services that request to call the any service; obtain a first service in the target service set whose trustworthiness data is greater than the trustworthiness data of the any service; and generate, for the any service, authentication policy information that allows the first service to access the any service.
[0153] Further, as Figure 10 shown, the electronic device further includes: a power supply component 1004, a display 1005, an audio component 1006, and other components. Figure 10 Only some components are schematically shown, and it does not mean that the electronic device only includes Figure 10 the components shown. It should be noted that Figure 10 the components within the dashed box are optional components, not mandatory components, and can be determined according to the product form of the electronic device. The electronic device in 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 can also be a server device such as a conventional server, a cloud server, or a server array. If the electronic device in this embodiment is implemented as a terminal device such as a desktop computer, a laptop computer, or a smart phone, it may include Figure 10 the components within the dashed box; if the electronic device in this embodiment is implemented as a server device such as a conventional server, a cloud server, or a server array, it may not include Figure 10 the components within the dashed box.
[0154] Correspondingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, it can implement the steps executable by the electronic device in the above method embodiments.
[0155] The detailed implementation manners and beneficial effects of the steps in the method of this embodiment have been described in detail in the foregoing embodiments, and will not be elaborated herein.
[0156] The above-mentioned memory can be implemented by any type of volatile or non-volatile storage 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.
[0157] The above-mentioned communication component is configured to facilitate communication between the device where the communication component is located and other devices in a wired or wireless manner. The device where the communication component is located can access a wireless network based on communication standards, 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 further 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 Wide Band (UWB) technology, Bluetooth (BT) technology and other technologies.
[0158] The above-mentioned display includes a screen, and the screen can include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from users. The touch panel includes one or more touch sensors to sense touches, swipes and gestures on the touch panel. The touch sensors can not only sense the boundaries of touch or swipe actions, but also detect the duration and pressure associated with the touch or swipe operations.
[0159] The above power supply component provides power for various components of the device where the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device where the power supply component is located.
[0160] The above audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC). When the device where the audio component is located is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive external audio signals. The received audio signals can be further stored in a memory or transmitted via a communication component. In some embodiments, the audio component further includes a speaker for outputting audio signals.
[0161] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, compact disc read-only memory (CD-ROM), optical memory, etc.) that contain computer-usable program code.
[0162] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.
[0163] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.
[0164] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide for implementing the process Figure 1 one process or multiple processes and / or blocks Figure 1 steps for the functions specified in one block or multiple blocks.
[0165] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), an input / output interface, a network interface, and a memory.
[0166] The memory may include non-permanent memory in the form of computer-readable media, random access memory (Random Access Memory, RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
[0167] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can store information by any method or technology. The 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 (Phase-change Random Access Memory, PRAM), static random access memory (SRAM), dynamic random access memory (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 (Digital Video Disc, DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible 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.
[0168] It should also be noted that the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising the element.
[0169] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and changes can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.
Claims
1. A microservice security access system, characterized in that, Including: An authentication control node, an authentication defense node, and a proxy module. The proxy module is injected into multiple services and shares the service ports of its affiliated services; The proxy module in any service is used to perform full-link security upgrades on the any service according to the protocol type and access direction of the access requests received and sent through the service port of the any service in the full-link upgrade mode, and enter the security authentication mode when the full-link upgrade completion condition is met; And In the security authentication mode, perform security authentication on the access requests received by the service port of the any service according to the authentication policy information issued by the authentication control node, and report the illegal access requests that fail the security authentication to the authentication defense node for updating the authentication policy information; The authentication control node is used to generate the authentication policy information of the any service according to the trust degree data and call relationship information of the any service, and issue it to the proxy module in the 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 and synchronize it to the proxy module in the at least one service when the illegal access request meets the authentication defense condition.
2. The system according to claim 1, characterized in that, The proxy module in the any service is specifically used for: In the full-link upgrade mode, intercept the access requests received and sent through the service port of the any service; When the access direction of the intercepted access request is the incoming direction and its protocol type is the security protocol type, obtain the digital certificate of the any service from the authentication control node, and perform a security upgrade on the transmission link between the any service and other services as the request sender according to the digital certificate of the any service; When the access direction of the intercepted access request is the outgoing direction and the other services as the request receiver have completed link upgrades, obtain the digital certificate of the any service from the authentication control node, and perform a security upgrade on the transmission link between the any service and other services as the request receiver according to the digital certificate of the any service.
3. The system according to claim 1, characterized in that, The proxy module in the any service is also used for: Generate the trust degree data of the any service according to the multi-dimensional credibility influence parameters corresponding to the any service and the target service set, where the target service set includes information about other services that request to call the any service; Determine the call relationship information of the any service according to the access requests received and sent through the service port of the any service and their access directions; Report the trust degree data and call relationship information of the any service to the authentication control node for the authentication control node to generate the authentication policy information of the any service.
4. The system according to claim 3, characterized in that, The proxy module in the any service is also used for: when the multi-dimensional credibility influence parameters corresponding to the any service change and / or the services in the target service set change, update the trust degree data of the any service and report it to the authentication control node; The authentication control node is also used for: issuing the updated trust degree data of the any service to the proxy module in other services called by the any service; Or, The proxy module in any of the services is further configured to: receive the updated trustworthiness data of a second service sent by the authentication control node, where the second service is another service that has the permission to access any of the services; and when an access request from the second service is intercepted at the service port of any of the services, perform a first security authentication on the second service according to the authentication policy information of any of the services; In the case where the second service passes the first security authentication, perform a second security authentication on the second service according to the trustworthiness data of any of the services and the updated trustworthiness data of the second service.
5. A microservice security access method, characterized in that, Applicable to a proxy module injected into any of the services, where the proxy module shares the service port of any of the services, the method includes: In the full-link upgrade mode, perform a full-link security upgrade on any of the services according to the protocol type and access direction of the access requests received and sent by the service port of any of the services, and enter the security authentication mode when the full-link upgrade completion condition is met; In the security authentication mode, perform security authentication on the access requests received at the service port of any of the services according to the authentication policy information sent by the authentication control node, and report the illegal access requests that fail the security authentication to the authentication defense node for the authentication defense node to update the authentication policy information; wherein the authentication policy information is generated according to the trustworthiness data and call relationship information of any of the services.
6. The method according to claim 5, characterized in that, Performing a full-link security upgrade on any of the services according to the protocol type and access direction of the access requests received and sent by the service port of any of the services includes: In the full-link upgrade mode, intercept the access requests received and sent by the service port of any of the services; When the access direction of the intercepted access request is the incoming direction and its protocol type is a security protocol type, obtain the digital certificate of any of the services from the authentication control node, and perform a security upgrade on the transmission link between any of the services and other services as the request sender according to the digital certificate of any of the services; When the access direction of the intercepted access request is the outgoing direction and the other service as the request receiver has completed the link upgrade, obtain the digital certificate of any of the services from the authentication control node, and perform a security upgrade on the transmission link between any of the services and other services as the request receiver according to the digital certificate of any of the services.
7. The method according to claim 5, characterized in that, Determining that the full-link upgrade completion condition is met includes: Monitoring the number of access requests received and sent by the service port of any of the services within a set active time threshold; in the case where the number is less than the first number threshold, determine that the full-link upgrade completion condition is met; and / or After monitoring that the set lazy time threshold arrives, determine that the full-link upgrade completion condition is met, where the proxy module in any of the services starts timing the lazy time threshold since it receives the lazy time threshold, and the lazy time threshold is greater than the active time threshold.
8. The method according to claim 5, characterized in that, Further includes: Generate the trustworthiness data of any one of the services according to the multi-dimensional trustworthiness influence parameters corresponding to the any one of the services and the target service set, where the target service set includes information of other services that request to call the any one of the services; Determine the call relationship information of any one of the services according to the access requests received and sent by the service port of the any one of the services and their access directions; Report the trustworthiness data and call relationship information of any one of the services to the authentication and control node for the authentication and control node to generate the authentication policy information of any one of the services.
9. The method according to claim 8, wherein, Generating the trustworthiness data of any one of the services according to the multi-dimensional trustworthiness influence parameters and the target service set includes: Generate the trust index of any one of the services according to the multi-dimensional trustworthiness influence parameters, and obtain the trust indices of each service in the target service set; Generate the trust threshold of any one of the services according to the trust index of any one of the services and the trust indices of each service in the target service set.
10. The method according to claim 9, wherein, Generating the trust index of any one of the services according to the multi-dimensional trustworthiness influence parameters includes: Perform trust value calculations respectively according to the multi-dimensional trustworthiness influence parameters to obtain multi-dimensional trust values; Perform weighted summation on the multi-dimensional trust values according to the weights corresponding to the multi-dimensional trustworthiness influence parameters to obtain the trust index of any one of the services.
11. The method according to claim 8, wherein, Further includes: Update the trustworthiness data of any one of the services when the multi-dimensional trustworthiness influence parameters corresponding to any one of the services change and / or the services in the target service set change; Report the updated trustworthiness data of any one of the services to the authentication and control node for the authentication and control node to send to the proxy module in other services called by any one of the services.
12. The method according to claim 11, wherein, The method further includes: Receive the updated trustworthiness data of a second service that calls any one of the services sent by the authentication and control node, where the second service is another service that has the right to access any one of the services; and When an access request from the second service is intercepted from the service port of any one of the services, perform a first security authentication on the second service according to the authentication policy information of any one of the services; When the second service passes the first security authentication, perform a second security authentication on the second service according to the trustworthiness data of any one of the services and the updated trustworthiness data of the second service.
13. The method according to claim 12, wherein, When the second service fails the second security authentication, the method includes: Report the access request from the second service to the authentication defense node for updating the authentication policy information, to prohibit the second service from accessing any one of the services and synchronize the updated authentication policy information of any one of the services to the proxy module in any one of the services.
14. A microservice security access method, wherein, Applicable to an authentication and control node, the method includes: Obtain the trustworthiness data and call relationship information of any one of the services, where any one of the services is injected with a proxy module, and the proxy module shares the service port of any one of the services; Generate the authentication policy information of any one of the services according to the trustworthiness data and call relationship information of any one of the services; Send the authentication policy information of any of the services to the proxy module in any of the services, so that the proxy module can perform security authentication on the access requests received at the service port in the security authentication mode.
15. The method according to claim 14, wherein, Generate the authentication policy information of any of the services according to the trust degree data and call relationship information of any of the services, including: According to the call relationship information of any of the services, obtain the trust degree data of other services of each service in the target service set, where the target service set includes information on other services that request to call any of the services; From the target service set, obtain the first service whose trust degree data is greater than the trust degree data of any of the services; For any of the services, generate authentication policy information that allows the first service to access any of the services.
16. An electronic device, wherein, Including: 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 method described in 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 the processor, it causes the processor to be able to implement the steps in the method described in any one of claims 5-13 and claims 14-15.