Server system, instance creation method and cloud management platform

Abstract

Disclosed are a server system based on public cloud technology, an instance creation method and a cloud management platform, belonging to the technical field of cloud services. The server system comprises a first server and a second server, between which connection channels are established. A first service module and a first security module are provided in a first instance of the first server; a second service module and a second security module are provided in a second instance of the second server; the first service module is configured to send an access request for the second service module, the access request being used for requesting the second service module to provide a second tenant service; the first security module is configured to acquire the access request, encrypt the access request, and send the encrypted access request to the connection channel; and the second security module is configured to acquire the encrypted access request from the connection channel, decrypt the encrypted access request, and send the decrypted access request to the second service module. The present application implements end-to-end encryption protection of access requests.

Description

Server system, instance creation methods, and cloud management platform

[0001] This application claims priority to Chinese Patent Application No. 202411895889.4, filed on December 20, 2024, entitled "Server System, Instance Creation Method and Cloud Management Platform", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of cloud service technology, and in particular to a server system, instance creation method and cloud management platform based on public cloud technology. Background Technology

[0003] Data security has become an increasingly important concern for users. For example, end-to-end encryption protection of sensitive user data has become a new security baseline in the era of generative AI. End-to-end encryption protection technology emphasizes minimizing the exposure of sensitive data.

[0004] In the current service architecture, after a client initiates an access request to the server, the request is typically sent to the server via a Secure Sockets Layer (SSL) connection and a service frontend. The access request is encrypted during transmission over the SSL connection. Upon reaching the service frontend, the frontend performs decryption and authentication checks before sending the processed request back to the server. The server then processes the request and returns a response to the frontend. The frontend then uses the SSL connection to send the response back to the client.

[0005] However, this service architecture cannot meet the goal of end-to-end encryption protection of data, resulting in poor security of transmitted data. Summary of the Invention

[0006] This application provides a server system, instance creation method, and cloud management platform based on public cloud technology. This application implements end-to-end encrypted protection for access requests between a first instance and a second instance. The technical solution provided by this application is as follows:

[0007] Firstly, this application provides a server system based on public cloud technology. The server system includes a first server and a second server. The first server runs a first instance. The second server runs a second instance. A connection channel is established between the first server and the second server. The first instance includes a first business module and a first security module. The first business module provides services for a first tenant. The second instance includes a second business module and a second security module. The second business module provides services for a second tenant. The first business module also sends an access request to the second business module, requesting the second business module to provide services for the second tenant. The first security module receives the access request, encrypts it, and sends the encrypted access request to the connection channel. The second security module receives the encrypted access request from the connection channel, decrypts it, and sends the decrypted access request to the second business module.

[0008] Since both the first business module and the first security module are located in the first instance, and the first security module is used to encrypt access requests, the access requests are already encrypted when they are sent from the first instance. Similarly, both the second business module and the second security module are located in the second instance, and the second security module is used to decrypt access requests, ensuring that the access requests remain encrypted before being received by the second instance. In this way, access requests remain encrypted throughout their transmission between the first and second instances, thus achieving end-to-end encryption protection for access requests between the first and second instances.

[0009] In one possible implementation, the second business module is further configured to generate an access response to the access request and send the access response; the second security module is further configured to obtain the access response, encrypt the access response, and send the encrypted access response to the connection channel; the first security module is further configured to obtain the encrypted access response from the connection channel, decrypt the encrypted access response, and send the decrypted access response to the first business module.

[0010] In this way, since both the second service module and the second security module are located in the second instance, and the second security module is used to encrypt the access response, the access response is already encrypted when it is sent from the second instance. Similarly, both the first service module and the first security module are located in the first instance, and the first security module is used to decrypt the access response, ensuring that the access response remains encrypted before being received by the first instance. Thus, the access response remains encrypted throughout its transmission between the first and second instances, thereby achieving end-to-end encryption protection for the access response between the first and second instances.

[0011] In one possible implementation, the first business module sends an access request to the second business module, including: the first business module sending an access request to the second business module. The first security module receives the access request, including: the first security module intercepting the access request. As described above, this implementation does not require changing the forwarding logic of the first business module in the service architecture. Thus, by setting the first security module in the first instance and the second security module in the second instance, no modification to the sending and receiving logic of the first instance is needed, nor is any redesign or application modification of the first business module required to achieve end-to-end encrypted transmission of access requests between the first and second instances. If the first instance is an application instance used to implement cloud services for a tenant, end-to-end encrypted transmission of access requests between the user's application instance and the second instance can be achieved without modifying the tenant's application instance. This feature also makes the solution highly compatible with instances, making it easy to implement on existing instances and ensuring the applicability of the solution.

[0012] Alternatively, the first business module sends an access request to the second business module, including: the first business module sending the access request to the first security module. The first security module receiving the access request includes: the first security module receiving the access request from the first business module.

[0013] In one possible implementation, the second business module sends an access response, including: the second business module sending an access response to the first business module. The second security module obtains the access response, including: the access response intercepted by the second security module.

[0014] As described above, this implementation scheme does not require changes to the forwarding logic of the second business module in the service architecture. Thus, by setting a second security module in the second instance and a first security module in the first instance, no modifications to the sending and receiving logic of the second instance, nor any redesign or application modification of the second business module, are needed to achieve end-to-end encrypted transmission of access responses between the first and second instances. If the second instance is an application instance used to implement a tenant's cloud service, end-to-end encrypted transmission of access responses between the user's application instance and the first instance can be achieved without modifying the tenant's application instance. This feature also makes the scheme highly compatible with instances, allowing for easy implementation on existing instances and ensuring the applicability of the scheme.

[0015] Alternatively, the second service module sends an access response, including: the second service module sending an access response to the second security module. The second security module receives the access response, including: the second security module receiving the access response from the second service module.

[0016] In one possible implementation, the server system includes multiple second servers. The server system also includes a service frontend. Connection channels include a first connection channel and a second connection channel. The service frontend connects to the first server via the first connection channel and connects to the multiple second servers via the second connection channels. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to a target second business module via the second connection channel. The target second business module is located in a second instance of the target second server, which is one of the multiple second servers. A target second security module is used to intercept encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to the target second business module. The target second security module is located in a second instance of the target second server.

[0017] Similarly, the target second security module is also used to obtain the access response generated by the target second business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via the second connection channel. The service frontend is also used to obtain the encrypted access response from the second connection channel and send the encrypted access response to the first business module via the first connection channel. The first security module is also used to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the first business module.

[0018] As described above, this implementation scheme does not require changing the forwarding logic of the service frontend in the service architecture. Therefore, by setting the first security module in the first instance and the second security module in the second instance, end-to-end encrypted transmission of access requests and responses between the first and second instances can be achieved without modifying the service frontend's send / receive logic or redesigning and developing the service frontend.

[0019] In one possible implementation, the server system includes multiple second servers and a service frontend. The connection channels include a first connection channel and a second connection channel. The service frontend connects to the first server via the first connection channel and to the multiple second servers via the second connection channel. The service frontend retrieves encrypted access requests from the first connection channel and sends the encrypted access requests to a target second security module via the second connection channel. The target second security module is located in a second instance of the target second server, which is one of the multiple second servers. The target second security module receives encrypted access requests from the second connection channel, decrypts the encrypted access requests, and sends decrypted access requests to a target second business module, which is located in a second instance of the target second server.

[0020] Similarly, the target second security module is also used to obtain the access response generated by the target second business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via the second connection channel. The service frontend is also used to receive the encrypted access response from the second connection channel and send the encrypted access response to the first security module via the first connection channel. The first security module is also used to receive the encrypted access response via the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the first business module.

[0021] In one possible implementation, the first instance further includes a first trusted module, which provides a trusted operating environment for the first service module and the first security module. And / or, the second instance further includes a second trusted module, which provides a trusted operating environment for the second service module and the second security module. By providing a trusted operating environment through the first and second trusted modules, the authenticity of identities in network communication can be ensured, thereby guaranteeing secure communication.

[0022] In this application, to ensure the authenticity of identities during network communication, the first security module may optionally verify the identity of the second security module before sending an encrypted access request to the connection channel. In one possible implementation, the first security module is further configured to obtain the service node information of the second security module, and if the service node information of the second security module is valid, send an encrypted access request to the connection channel.

[0023] In one possible implementation, the server system further includes a third server. The third server contains a processing module that maintains the verification information for the first and second security modules. The first security module also retrieves the verification information for the second security module from the processing module and, if the verification method indicated by the verification information determines that the service node information of the second security module is valid, sends an encrypted access request to the connection channel.

[0024] Secondly, this application provides an access method for a server system based on public cloud technology. The server system includes a first server and a second server. The first server runs a first instance. The second server runs a second instance. A connection channel is established between the first server and the second server. The first instance includes a first business module and a first security module. The first business module provides services for a first tenant. The second instance includes a second business module and a second security module. The second business module provides services for a second tenant. The method includes: the first business module sending an access request to the second business module, the access request requesting the second business module to provide services for a second tenant to the first business module; the first security module obtaining the access request, encrypting the access request, and sending the encrypted access request to the connection channel; and the second security module obtaining the encrypted access request from the connection channel, decrypting the encrypted access request, and sending the decrypted access request to the second business module.

[0025] In one possible implementation, the method further includes: a second business module generating an access response to the access request and sending the access response; a second security module obtaining the access response, encrypting the access response, and sending the encrypted access response to the connection channel; and a first security module obtaining the encrypted access response from the connection channel, decrypting the encrypted access response, and sending the decrypted access response to the first business module.

[0026] In one possible implementation, the first business module sends an access request to the second business module, including: the first business module sending the access request to the second business module. Correspondingly, the first security module receives the access request, including: the first security module intercepting the access request.

[0027] Alternatively, the first business module may send an access request to the second business module, including: the first business module sending the access request to the first security module. Correspondingly, the first security module receives the access request, including: the first security module receiving the access request from the first business module.

[0028] In one possible implementation, the second business module sends an access response, including sending the access response to the first business module. Correspondingly, the second security module obtains the access response, including intercepting the access response.

[0029] Alternatively, the second service module sends an access response, including: the second service module sending an access response to the second security module. Correspondingly, the second security module receives the access response, including: the second security module receiving the access response from the second service module.

[0030] In one possible implementation, the server system includes multiple second servers. The server system also includes a service frontend. Connection channels include a first connection channel and a second connection channel. The service frontend connects to the first server via the first connection channel. The service frontend connects to multiple second servers via the second connection channel. The method further includes: the service frontend obtaining an encrypted access request from the first connection channel and sending the encrypted access request to a target second business module via the second connection channel. The target second business module is located in a second instance of a target second server, which is one of multiple second servers. A target second security module intercepts the encrypted access request from the second connection channel, decrypts the encrypted access request, and sends the decrypted access request to the target second business module. The target second security module is located in a second instance of the target second server.

[0031] In one possible implementation, the method further includes: a target second security module obtaining an access response generated by a target second business module based on an access request, encrypting the access response, and sending the encrypted access response to a service frontend via a second connection channel. The service frontend obtains the encrypted access response from the second connection channel and sends the encrypted access response to a first business module via a first connection channel. The first security module intercepts the encrypted access response from the first connection channel, decrypts the encrypted access response, and sends the decrypted access response to the first business module.

[0032] In one possible implementation, the server system includes multiple second servers. The server system also includes a service frontend. Connection channels include a first connection channel and a second connection channel. The service frontend connects to a first server via the first connection channel. The service frontend connects to multiple second servers via the second connection channel. The method further includes: the service frontend obtaining an encrypted access request from the first connection channel and sending the encrypted access request to a target second security module via the second connection channel. The target second security module is located in a second instance of a target second server, which is one of multiple second servers. The target second security module receives the encrypted access request from the second connection channel, decrypts the encrypted access request, and sends the decrypted access request to a target second business module, which is located in a second instance of the target second server.

[0033] In one possible implementation, the method further includes: the target second security module obtaining the access response generated by the target second business module based on the access request, encrypting the access response, and sending the encrypted access response to the service frontend via a second connection channel. The service frontend receives the encrypted access response from the second connection channel and sends the encrypted access response to the first security module via a first connection channel. The first security module receives the encrypted access response via the first connection channel, decrypts the encrypted access response, and sends the decrypted access response to the first business module.

[0034] In one possible implementation, the first instance further includes a first trusted module. The first trusted module provides a trusted operating environment for the first business module and the first security module. The method also includes: verifying the trusted operating environment and generating a key pair. And / or, the second instance further includes a second trusted module, which provides a trusted operating environment for the second business module and the second security module. The method also includes: verifying the trusted operating environment and generating a key pair.

[0035] In one possible implementation, the method further includes: a first security module obtaining service node information of a second security module. Correspondingly, the first security module sends an encrypted access request to the connection channel, including: the first security module sending the encrypted access request to the connection channel if the service node information of the second security module is valid.

[0036] In one possible implementation, the server system further includes a third server. The third server has a processing module. The processing module maintains the verification information of the first security module and the second security module. The method further includes: the first security module obtaining the verification information of the second security module from the processing module. Correspondingly, the first security module sends an encrypted access request to the connection channel, including: if the first security module determines that the service node information of the second security module is valid based on the verification method indicated by the verification information, the first security module sends the encrypted access request to the connection channel.

[0037] Thirdly, this application provides a method for creating instances based on public cloud technology. This method is applied to a cloud management platform. The cloud management platform is used to manage infrastructure. The infrastructure includes multiple servers. The method includes: obtaining an instance creation request input by a tenant, the instance creation request carrying the specifications of the target instance to be created and indicating an image file of the target instance; selecting a target server from multiple servers that can provide the specifications; creating a target business module of the target instance on the target server based on the image file, and creating a target security module of the target instance on the target server; deploying the target business module and the target security module in one instance to obtain the target instance, the target business module being used to provide target tenant services; wherein, the target business module is also used to send access requests to other business modules, the access requests being used to request other business modules to provide other tenant services to the target business module, the other business modules being deployed in other instances running on other servers, the other servers being servers other than the target server among multiple servers; the target security module being used to obtain the access request, encrypt the access request, and send the encrypted access request to the connection channel between the target server and other servers; the other security modules being used to obtain the encrypted access request from the connection channel, decrypt the encrypted access request, and send the decrypted access request to the other business modules.

[0038] In one possible implementation, other business modules are also used to generate and send access responses to the access requests. Other security modules are also used to obtain the access response, encrypt it, and send the encrypted access response to the connection channel. The target security module is also used to obtain the encrypted access response from the connection channel, decrypt it, and send the decrypted access response to the target business module.

[0039] In one possible implementation, the target business module sends an access request to another business module, including: the target business module sending the access request to the other business module. Correspondingly, the target security module receives the access request, including: the target security module intercepting the access request.

[0040] Alternatively, the target business module may send an access request to another business module, including: the target business module sending an access request to the target security module. Correspondingly, the target security module receives the access request, including: the target security module receiving the access request from the target business module.

[0041] In one possible implementation, other business modules send access responses, including sending access responses to the target business module. Correspondingly, other security modules obtain access responses, including intercepted access responses.

[0042] Alternatively, other business modules may send access responses, including sending access responses to other security modules. Correspondingly, other security modules may receive access responses, including receiving access responses from other business modules.

[0043] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend via the first connection channel. The service frontend connects to multiple other servers via the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target business modules via the second connection channel. These other target business modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. Correspondingly, a security module is used to intercept the encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to the other target business modules. This security module is located in other instances of the other target servers.

[0044] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to obtain the encrypted access response from the second connection channel and send the encrypted access response to the target business module via a first connection channel. The target security module is further configured to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0045] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend through the first connection channel, and the service frontend connects to multiple other servers through the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target security modules via the second connection channel. These other target security modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. Correspondingly, these other target security modules are used to receive encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to other target business modules, which are also located in other instances of the other target servers.

[0046] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to receive the encrypted access response from the second connection channel and send the encrypted access response to the target security module via a first connection channel. The target security module is further configured to receive the encrypted access response via the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0047] In one possible implementation, the method further includes: creating a target trusted module for a target instance on the target server, deploying the target trusted module in the target instance, and using the target trusted module to provide a trusted operating environment for the target business module and the target security module.

[0048] In one possible implementation, the target security module is also used to obtain service node information of other security modules, and if the service node information of other security modules is valid, to send an encrypted access request to the connection channel.

[0049] In one possible implementation, the target security module is also used to obtain verification information of other security modules from the processing module of the third server, and if the service node information of other security modules is determined to be valid based on the verification method indicated by the verification information, the target security module sends an encrypted access request to the connection channel. The processing module is used to maintain the verification information of the target security module and other security modules.

[0050] Fourthly, this application provides a cloud management platform. The cloud management platform is used to manage infrastructure. The infrastructure includes multiple servers. The cloud management platform includes: an acquisition unit for acquiring an instance creation request input by a tenant, the instance creation request carrying the specifications of the target instance to be created, and indicating an image file of the target instance; a selection unit for selecting a target server from multiple servers that can provide the specifications; and a creation unit for creating a target business module of the target instance on the target server based on the image file, and creating a target security module of the target instance on the target server, deploying the target business module and the target security module in one instance to obtain the target instance, the target business module being used to provide services to the target tenant. The target business module is also used to send access requests to other business modules. These access requests are used to request other business modules to provide other tenant services to the target business module. The other business modules are deployed in other instances running on other servers, which are servers other than the target server among multiple servers. The target security module is used to obtain the access requests, encrypt the access requests, and send the encrypted access requests to the connection channel between the target server and other servers. Other security modules are used to obtain the encrypted access requests from the connection channel, decrypt the encrypted access requests, and send the decrypted access requests to other business modules.

[0051] In one possible implementation, other business modules are also used to generate and send access responses to the access requests. Other security modules are also used to obtain the access response, encrypt it, and send the encrypted access response to the connection channel. The target security module is also used to obtain the encrypted access response from the connection channel, decrypt it, and send the decrypted access response to the target business module.

[0052] In one possible implementation, the target business module sends an access request to another business module, including: the target business module sending the access request to the other business module. Correspondingly, the target security module receives the access request, including: the target security module intercepting the access request.

[0053] Alternatively, the target business module may send access requests to other business modules, including: the target business module sending access requests to the target security module. The target security module may then receive the access requests from the target business module.

[0054] In one possible implementation, other business modules send access responses, including sending access responses to the target business module. Correspondingly, other security modules obtain access responses, including intercepted access responses.

[0055] Alternatively, other business modules may send access responses, including sending access responses to other security modules. Correspondingly, other security modules may receive access responses, including receiving access responses from other business modules.

[0056] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend through the first connection channel, and the service frontend connects to multiple other servers through the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target business modules based on the second connection channel. These other target business modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. Correspondingly, a security module is used to intercept the encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to the other target business modules. This security module is also located in other instances of the other target servers.

[0057] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to obtain the encrypted access response from the second connection channel and send the encrypted access response to the target business module via a first connection channel. The target security module is further configured to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0058] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend through the first connection channel, and the service frontend connects to multiple other servers through the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target security modules based on the second connection channel. These other target security modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. The other target security modules are used to receive encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to other target business modules, which are also located in other instances of the other target servers.

[0059] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to receive the encrypted access response from the second connection channel and send the encrypted access response to the target security module via a first connection channel. The target security module is further configured to receive the encrypted access response via the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0060] In one possible implementation, the creation unit is also used to create a target trusted module for a target instance on the target server, and to deploy the target trusted module on the target instance. The target trusted module is used to provide a trusted operating environment for the target business module and the target security module.

[0061] In one possible implementation, the target security module is also used to obtain service node information of other security modules, and if the service node information of other security modules is valid, to send an encrypted access request to the connection channel.

[0062] In one possible implementation, the target security module is also used to obtain verification information of other security modules from the processing module of the third server, and if the service node information of other security modules is determined to be valid based on the verification method indicated by the verification information, the target security module sends an encrypted access request to the connection channel. The processing module is used to maintain the verification information of the target security module and other security modules.

[0063] Fifthly, this application provides a computing device including a memory and a processor, the memory storing program instructions, and the processor executing the program instructions to implement the methods provided in the first aspect of this application and any of its possible implementations.

[0064] In a sixth aspect, this application provides a computing device cluster, including multiple computing devices, each computing device including multiple processors and multiple memories, the multiple memories storing program instructions, and the multiple processors executing the program instructions, so that the computing device cluster implements the method provided in the first aspect of this application and any possible implementation thereof.

[0065] In a seventh aspect, this application provides a computer-readable storage medium that is a non-volatile computer-readable storage medium, the computer-readable storage medium including program instructions that, when executed on a computing device cluster, cause the computing device cluster to implement the methods provided in the first aspect of this application and any of its possible implementations.

[0066] Eighthly, this application provides a computer program product containing instructions that, when run on a computer, cause the computer to implement the methods provided in the first aspect of this application and any of its possible implementations. Attached Figure Description

[0067] Figure 1 is a structural diagram of an implementation scenario of a server system based on public cloud technology provided in an embodiment of this application;

[0068] Figure 2 is a schematic diagram of the deployment of basic resources in a data center according to an embodiment of this application;

[0069] Figure 3 is a schematic diagram of the structure of a server system based on public cloud technology provided in an embodiment of this application;

[0070] Figure 4 is a schematic diagram of the access process of a server system based on public cloud technology provided in an embodiment of this application;

[0071] Figure 5 is a schematic diagram of another server system based on public cloud technology provided in an embodiment of this application;

[0072] Figure 6 is a schematic diagram of an API of a third server provided in an embodiment of this application;

[0073] Figure 7 is a schematic diagram of the access process of another server system based on public cloud technology provided in an embodiment of this application;

[0074] Figure 8 is a flowchart of an access method for a server system based on public cloud technology provided in an embodiment of this application;

[0075] Figure 9 is a flowchart of an instance creation method based on public cloud technology provided in an embodiment of this application;

[0076] Figure 10 is a schematic diagram of a cloud management platform provided in an embodiment of this application;

[0077] Figure 11 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0078] Figure 12 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0079] Figure 13 is a schematic diagram of another computing device cluster provided in an embodiment of this application. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0081] To facilitate understanding, the technologies and background involved in the embodiments of this application will be introduced below.

[0082] Cloud computing is a type of distributed computing that refers to a network that centrally manages and schedules a large number of computing and storage resources to provide on-demand services to users. These computing and storage resources are provided through clusters of computing devices located in data centers. Furthermore, cloud computing can provide users with various types of services, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Infrastructure as a Service provides virtual machines or other resources as a service to tenants. Platform as a Service provides a development platform as a service to tenants. Software as a Service provides applications (Apps) as a service to customers.

[0083] An Internet Data Center (IDC) is a facility and related service system that provides operation and maintenance for equipment that centrally collects, stores, processes, and transmits data, based on the Internet. Conceptually, it can be understood as a public, commercial Internet "server room," and it is also a professional IT service and a crucial infrastructure for the IT industry. IDC is not only a service concept but also a network concept; it constitutes part of the network infrastructure resources, like backbone networks and access networks, providing high-end data delivery and high-speed access services. Generally, a tenant's on-premises IDC can be understood as their physical server room, where the tenant utilizes existing Internet communication lines and bandwidth resources to establish a standardized, telecommunications-grade server room environment to provide comprehensive services such as server hosting, leasing, and related value-added services. A cloud data center is an Internet data center deployed using the infrastructure resources owned by cloud vendors.

[0084] A resource pool is a collection of various hardware and software resources involved in a cloud data center. Typically, resources in a resource pool can be categorized by type, such as computing resources, storage resources, and network resources.

[0085] A physical machine (PM) is the physical resource used to host virtualization technology. It is also called a physical server. Typically, a physical machine is used to deploy virtual instances. A physical machine has multiple physical devices. For example, a physical server has physical devices such as processors and memory. Multiple virtual instances can be deployed on a single physical machine, sharing the machine's physical resources. Depending on the use case, multiple virtual instances deployed on a single physical machine can belong to the same tenant or to different tenants.

[0086] Virtualization is a resource management technology. Virtualization abstracts and transforms various physical resources of a host, such as computing, network, and storage resources, breaking down the indivisible barriers between the host's physical structures. This allows tenants to utilize these resources in a better way than the original configuration. Resources obtained through virtualization are called virtualized resources, and virtualized resources are not limited by the existing physical resource deployment methods, geographical location, or physical configuration.

[0087] Virtualized resources are typically provided to tenants in the form of virtual instances. Virtual instances utilize the host's hardware resources and run on the host's operating system (OS). Applications run within the virtual instance to implement the tenant's business logic. The host's hardware resources can be allocated to one or more tenants at the virtual instance level. Different virtual instances are isolated from each other, allowing tenants to use physical resources conveniently and flexibly while maintaining security and isolation, and significantly improving the utilization of physical resources. Typically, virtual instances can be virtual machines, containers, or independent processes (such as functions). Virtual instances can also be called Elastic Compute Service (ECS) or Elastic Instances (different cloud service providers may use different names).

[0088] A virtual machine (VM) is a complete computer system with full hardware system functionality, simulated using virtualization technology and running in a completely isolated environment. A subset of the instructions in a VM can be processed on the host machine, while other instructions can be executed in a simulated manner. A VM is also called a virtual server. A VM can be viewed as a collection of virtual devices, which possess full hardware system functionality and run in a completely isolated environment. Virtual devices are created by virtualizing physical devices that can share resources. For example, a virtual processor, created by virtualizing a processor, is a virtual device. Similarly, a training card, created by virtualizing a field-programmable gate array (FPGA), is also a virtual device. For instance, the VM in this application can be a kernel-based virtual machine (KVM). Any task that can be performed on a server can also be performed in a VM. When creating a virtual machine on a server, a portion of the physical machine's hard drive and memory capacity is used as the virtual machine's hard drive and memory capacity. Each virtual machine has its own independent hard drive and operating system, and virtual machine tenants can operate the virtual machine as if it were a server. The runtime environments (such as virtual machine applications, operating systems, and virtual hardware) in different virtual machines are completely isolated, and communication between different virtual machines requires the virtual machine manager to forward network packets.

[0089] Containers utilize the namespace and cgroup technologies supported by the Linux kernel to isolate application processes and their dependencies (the runtime environment's bins / libs, specifically all files required to run the application) within an independent runtime environment. Containers provide a lightweight virtual runtime environment. Containers are created by packaging all the code, libraries, and dependencies of a tenant's application into an image. When the image is executed, it runs in a virtual runtime environment. At this point, the container is a runtime instance of the image, similar to a lightweight sandbox, which can be started, stopped, and deleted. The infrastructure for containers can be server hardware or virtual machines in the cloud (i.e., containers can also be deployed within virtual machines). The operating system uses the Linux kernel and supports namespaces and cgroups. Namespaces are used to isolate processes, while cgroups are used to allocate process resources, specifically virtual processors and memory allocated to the process. The container engine, similar to a virtual machine manager, runs within the operating system and is used to manage containers. Compared to virtual machines, which come with their own operating system, containers do not have an operating system. Instead, containers run as processes within the host machine's operating system. As a result, containers start up faster than virtual machines, making them particularly suitable for lightweight applications. Furthermore, a single host machine can run thousands of containers (processes) simultaneously.

[0090] Resource pooling refers to integrating various computing and storage resources into a unified resource pool for unified dynamic allocation and management. Resource pooling enables high resource sharing, improves resource utilization, simplifies resource management, and provides users with flexible on-demand allocation services.

[0091] Secure Socket Layer Termination (SSL Termination), also known as SSL Offload, is the process of decrypting SSL-encrypted traffic. It works by intercepting encrypted traffic before it reaches the application server, and then decrypting and analyzing the traffic on a dedicated node (such as an application load balancer) or a dedicated SSL termination device.

[0092] Key negotiation: Two or more entities jointly establish a session key through a key negotiation protocol, without relying on a third party. Classified by interaction method, it is generally divided into interactive key negotiation and non-interactive key negotiation.

[0093] A trusted execution environment (TEE) defines the characteristics of an execution environment by measuring hardware, firmware, system software, and applications, and can provide documentation proving these characteristics.

[0094] An attestation is a digitally signed document calculated by a root of trust (such as a CPU) for the identity and metrics of a trusted operating environment, and provides a publicly verifiable method for the signed document.

[0095] Data security has become an increasingly important concern for users. For example, end-to-end encryption protection of sensitive user data has become a new security baseline in the era of generative AI. End-to-end encryption protection technology emphasizes minimizing the exposure of sensitive data.

[0096] In the current service architecture, after a client initiates an access request to the server, the request is transmitted to the server via a transport link. To ensure data security, the transport link encrypts the access request. When the access request reaches the server, the server decrypts it. After receiving the access request, the server responds and then transmits the response back to the client via the transport link. The transport link can use a Secure Sockets Layer (SSL) connection. In public cloud application scenarios, servers are typically infrastructure managed by a cloud management platform, and the services they provide are usually cloud services deployed on the public cloud. These cloud services can be provided by the server itself or implemented through instances deployed on the server.

[0097] With the increasing demands for high performance and scalability in modern web service architectures, functionality that was originally provided by a single server can now be implemented across multiple servers, with service front-ends set up for each. In this scenario, client access requests typically begin at the service front-end. Upon receiving the server request, the service front-end forwards the request to one of the servers based on a pre-defined strategy. For example, the service front-end might use rules based on path, identity, or load balancing to forward the request. The server receiving the request then returns a service response to the service front-end, which in turn returns the response to the client. In this context, the decryption of the access request is usually also offloaded to the service front-end. Furthermore, the service front-end can perform operations such as access validity checks, including authentication, permission checks, and access control. Depending on the rules used by the service front-end to forward access requests, its implementation can take various forms. For example, it can be implemented as a load balancer, an application programming interface gateway (API Gateway), or a secure socket layer termination (SSL Termination).

[0098] However, this service architecture fails to meet the goal of end-to-end data encryption protection, resulting in poor data security. For example, in the above architecture, since the server is the one that truly needs to process sensitive user data, to achieve end-to-end encryption, it is necessary to: (1) ensure that no other node besides the server can obtain the client's sensitive data; and (2) ensure that the server uses verifiable isolated computing technology to guarantee that sensitive data will not be leaked. However, in the end-to-end link of handling access requests and responses in the above service architecture, the service front end can obtain plaintext access requests and responses, and may even persist access requests and responses based on some application requirements. For example, persisting access requests and responses to relevant data lakes. This obviously does not meet the principle of minimizing the exposure of sensitive data, therefore the current service architecture cannot meet the goal of end-to-end data encryption protection.

[0099] In view of this, embodiments of this application provide a server system, instance creation method, and cloud management platform based on public cloud technology. The server system includes a first server and a second server. The first server runs a first instance. The second server runs a second instance. A connection channel is established between the first server and the second server. The first instance includes a first business module and a first security module. The first business module provides services for a first tenant. The second instance includes a second business module and a second security module. The second business module provides services for a second tenant. The first business module also sends an access request to the second business module, requesting the second business module to provide services for the second tenant. The first security module obtains the access request, encrypts the access request, and sends the encrypted access request to the connection channel. The second security module obtains the encrypted access request from the connection channel, decrypts the encrypted access request, and sends the decrypted access request to the second business module.

[0100] Since both the first business module and the first security module are located in the first instance, and the first security module is used to encrypt access requests, the access requests are already encrypted when they are sent from the first instance. Similarly, both the second business module and the second security module are located in the second instance, and the second security module is used to decrypt access requests, ensuring that the access requests remain encrypted before being received by the second instance. In this way, access requests remain encrypted throughout their transmission between the first and second instances, thus achieving end-to-end encryption protection for access requests between the first and second instances.

[0101] This article provides a detailed introduction to the technical solution of this application from multiple perspectives, including implementation scenarios, methods and processes, hardware devices, and software devices.

[0102] The following are examples illustrating the implementation scenarios of the embodiments of this application.

[0103] Figure 1 is a structural diagram illustrating an implementation scenario involving a server system, instance creation method, and cloud management platform based on public cloud technology, as provided in this application embodiment. As shown in Figure 1, the implementation scenario includes: a data center 1 and a client 2. Data center 1 and client 2 can establish a communication connection via a network. Optionally, this network can be the Internet or other networks; this application embodiment does not limit the specific network. Tenants can interact with data center 1 through client 2. For example, a tenant can send cloud service requests and other information to data center 1 through client 2. Data center 1 responds based on the information sent by client 2.

[0104] Data center 1 houses a large amount of infrastructure owned by a cloud service provider, such as computing resources, storage resources, and network resources. For example, computing resources can be computing devices (such as servers) capable of providing computing power. As shown in Figure 1, data center 1 includes a cloud management platform and infrastructure (not shown in Figure 1). The cloud management platform and infrastructure are connected via an internal data center network. The cloud management platform manages the infrastructure. The infrastructure provides public cloud services. The infrastructure includes multiple servers. Cloud services are optionally deployed on the servers. Cloud services are implemented by running virtual instances, hence also referred to as virtual instances deployed on servers to implement tenant services. Tenants can send cloud service requests and related information to the server through their client 2. The server can process the cloud service requests and related information and provide cloud services to the tenant based on the processed cloud service requests and related information. For example, the cloud management platform can manage the cloud resources owned by the cloud management platform through the public cloud technology-based server system, instance creation method, and cloud management platform provided in this application embodiment, in order to provide cloud services to tenants.

[0105] It should be noted that Figure 1 is an example of an implementation scenario, and this application can also be applied to other implementation scenarios. For example, the implementation scenario may include multiple data centers, and the cloud management platform may connect to each of the multiple data centers. In this case, the cloud management platform is used to manage the infrastructure deployed in the multiple data centers.

[0106] The cloud management platform can be logically divided into: tenant console, compute management service, network management service, storage management service, authentication service, and image management service. The tenant console provides a user interface or application programming interface (API) for interaction with tenants. The compute management service manages servers running virtual instances and bare metal servers. The network management service manages network services (such as gateways and firewalls). The storage management service manages storage services (such as data bucket services). The authentication service manages tenant accounts and passwords. The image management service manages virtual instance images.

[0107] In the implementation scenario shown in Figure 1, a data center contains multiple servers. The servers consist of a hardware layer and a software layer. The hardware layer comprises the standard server configuration, including hardware devices such as processors, memory, network interface cards (NICs), disks, and buses. The software layer includes the operating system installed and running on the server. The operating system relative to the virtual machine can be called the host operating system. The host operating system runs a virtual machine manager (also known as a hypervisor). The virtual machine manager's role is to implement compute virtualization, network virtualization, and storage virtualization for the virtual machines, and to manage the virtual machines.

[0108] The virtual machine manager runs a cloud management platform client. This client receives control plane commands from the cloud management platform, creates virtual instances on the server based on these commands, and manages the virtual instances throughout their lifecycle. For example, the client can monitor the hardware resource usage of the server in real time and report it to the cloud management platform. When the cloud management platform confirms that a virtual instance needs to be created on a specific server, it sends a virtual instance creation command to the client on that server. Upon receiving the command, the client creates the virtual instance on that server. In this way, tenants can create, manage, log in to, and operate virtual instances within the data center through the cloud management platform.

[0109] Servers can run virtual machines of different specifications. Virtual machine specifications are categorized as: general-purpose computing, memory-optimized, ultra-large memory, etc., with specific specifications under each type. After a tenant selects a virtual machine specification, the cloud management platform selects a server in the data center that supports that specification and ensures sufficient idle hardware resources on that server. Then, it creates and configures the virtual machine with that specification on that server. Configuring servers through the cloud management platform allows for the analysis and planning of server hardware resources. Based on the server's hardware performance, it plans the corresponding computing products for the physical hardware, such as planning virtual machines of different specifications, to meet the diverse needs of different tenants. Furthermore, differentiated pricing strategies can be implemented based on the performance differences of virtual machines of different specifications. For example, high-performance virtual instances can be sold at a higher price, while ordinary performance virtual instances can be sold at a lower price, allowing tenants to purchase virtual instances as needed.

[0110] In one implementation, as shown in Figure 2, the location of basic resources in a data center can be described by cloud resource deployment regions (regions) and availability zones (AZs). Tenants can choose to deploy cloud services based on resources in specific regions and AZs. Regions are defined based on geographical location and network latency. Using the same resource pool within the same region can be understood as sharing public services such as elastic computing, block storage, object storage, virtual private cloud (VPC) networks, elastic internet protocol (EIP) addresses, and images. Regions are divided into general regions and dedicated regions. General regions refer to regions that provide general cloud services to public tenants. Dedicated regions refer to dedicated regions that host the same type of business or provide business services to specific tenants. A region typically includes multiple AZs. Multiple AZs within a region are connected via high-speed fiber optic cables to meet the needs of tenants building high-availability systems across AZs. An AZ is a collection of one or more data centers as shown in Figure 2. Computing, network, and storage resources within an AZ are logically divided into multiple clusters.

[0111] Tenants can send instructions to the cloud management platform through their client 2 to create, manage, log in to, and operate virtual instances on the server, and use the cloud services provided by these virtual instances. For example, the cloud management platform can provide an access interface. This interface can be provided either as a user interface or an API. Tenants can operate their client to remotely access the access interface to register a cloud account and password on the cloud management platform, and then log in using these accounts and passwords. The cloud management platform can also authenticate the cloud account and password. After successful authentication, the tenant can further select and purchase a virtual instance with specific specifications (processor, memory, disk) on the cloud management platform. After the tenant successfully purchases the virtual instance, the cloud management platform provides the tenant with a remote login account and password for the purchased virtual instance. The tenant can use the remote login account and password to remotely log in to the virtual instance on their client, install and run their application within the virtual instance, and use the application to implement their business operations.

[0112] Client 2 can be selected from computers, personal computers, laptops, mobile phones, smartphones, tablets, cloud servers, portable mobile terminals, multimedia players, e-book readers, wearable devices, smart home appliances, artificial intelligence devices, smart wearable devices, smart in-vehicle devices, or Internet of Things devices, etc.

[0113] In one implementation, the instance creation method based on public cloud technology provided in this application embodiment can be implemented by running an executable program on a computing device in data center 1. Optionally, the instance creation method based on public cloud technology provided in this application embodiment can be applied to a server managed by a cloud management platform. The server can implement the instance creation method based on public cloud technology provided in this application embodiment by running the executable program. Furthermore, the executable program implementing the instance creation method based on public cloud technology can optionally be presented in the form of an application installation package. After the server installs the application installation package, it can implement the instance creation method based on public cloud technology provided in this application embodiment by running the executable program therein.

[0114] It should be understood that the above content is an exemplary description of the implementation scenarios of the server system, instance creation method, and cloud management platform based on public cloud technology provided in the embodiments of this application, and does not constitute a limitation on the implementation scenarios of the server system, instance creation method, and cloud management platform based on public cloud technology. Those skilled in the art will understand that, as business needs change, the implementation scenarios can be adjusted according to application requirements, and the embodiments of this application do not specifically limit them. Furthermore, when the server system, instance creation method, and cloud management platform based on public cloud technology provided in the embodiments of this application are applied to other scenarios, the executable program of the method can also be presented in the form of an application installation package or in other ways, and the embodiments of this application do not list them all.

[0115] The architecture and implementation principle of the server system based on public cloud technology provided in this application embodiment will be described below. As shown in Figure 3, the server system includes a first server and a second server. The first server runs a first instance. The second server runs a second instance. A connection channel is established between the first server and the second server. Optionally, the connection channel can be an SSL connection. The first instance is equipped with a first business module and a first security module. The first business module is used to provide services for a first tenant. The second instance is equipped with a second business module and a second security module. The second business module is used to provide services for a second tenant.

[0116] As shown in Figure 4, during the process of transmitting access requests between the first instance and the second instance, the respective roles of the first business module, the first security module, and the second security module are as follows:

[0117] The first business module is used to send access requests to the second business module. The access requests are used to request the second business module to provide the second tenant service to the first business module. For example, after generating the access request for the second business module, the first business module first encapsulates the access request and then sends the encapsulated access request.

[0118] The first security module is used to acquire access requests, encrypt access requests, and send the encrypted access requests to the connection channel. For example, after acquiring an encapsulated access request from the first business module, the first security module first decapsulates the access request, then encrypts the access request, then recapsulates the encrypted access request, and finally sends the encrypted access request to the connection channel.

[0119] The second security module is used to obtain encrypted access requests from the connection channel, decrypt the encrypted access requests, and send the decrypted access requests to the second service module. For example, after obtaining the encrypted and encapsulated access requests from the connection channel, the second security module first decapsulates the access requests, then decrypts the encrypted access requests, then recapsulates the decrypted access requests, and finally sends the decrypted access requests to the second service module.

[0120] In this way, since both the first business module and the first security module are located in the first instance, and the first security module is used to encrypt the access request, the access request is already encrypted when it is sent from the first instance. Similarly, both the second business module and the second security module are located in the second instance, and the second security module is used to decrypt the access request, ensuring that the access request remains encrypted before being received by the second instance. Thus, the access request remains encrypted throughout its transmission between the first and second instances, thereby achieving end-to-end encryption protection for the access request between the first and second instances.

[0121] After receiving the access request, the second business module generates an access response. As shown in Figure 4, during the transmission of the access response between the first and second instances, the respective roles of the second business module, the first security module, and the second security module are as follows:

[0122] The second business module is also used to generate and send access responses to access requests. For example, after generating the access response, the second business module first encapsulates the access response and then sends the encapsulated access response.

[0123] The second security module is also used to acquire access responses, encrypt access responses, and send encrypted access responses to the connection channel. For example, after acquiring the encapsulated access response from the second business module, the second security module first decapsulates the access response, then encrypts the access response, then recapsulates the encrypted access response, and then sends the encrypted access response to the connection channel.

[0124] The first security module is also used to obtain an encrypted access response from the connection channel, decrypt the encrypted access response, and send the decrypted access response to the second service module. For example, after obtaining the encrypted and encapsulated access response from the connection channel, the second security module first decapsulates the access response, then decrypts the encrypted access response, then recapsulates the decrypted access response, and then sends the decrypted access response to the second service module.

[0125] In this way, since both the second service module and the second security module are located in the second instance, and the second security module is used to encrypt the access response, the access response is already encrypted when it is sent from the second instance. Similarly, both the first service module and the first security module are located in the first instance, and the first security module is used to decrypt the access response, ensuring that the access response remains encrypted before being received by the first instance. Thus, the access response remains encrypted throughout its transmission between the first and second instances, thereby achieving end-to-end encryption protection for the access response between the first and second instances.

[0126] In one possible implementation, the first security module can be deployed in the first instance along with the first business module, using methods such as an intermediate forwarding service, a sidecar mode, a proxy, or a software development kit (SDK). Similarly, the second security module can be deployed in the second instance along with the second business module, using methods such as an intermediate forwarding service, a sidecar mode, a proxy, or an SDK.

[0127] In the above process, the implementation method of encrypting access requests and decrypting access responses by the first security module can be determined according to application requirements. Similarly, the implementation method of encrypting access responses and decrypting access requests by the first security module can be determined according to application requirements. A possible implementation scheme is provided below:

[0128] The first security module encrypts the access request by using the public key of the recipient of the access request to obtain an encrypted access request. For example, if the recipient of the access request is the second security module, and assuming the second security module's public key is pkR, the first security module's encryption process is as follows:

[0129] 1. The first security module calls the encapsulation function Encap, taking pkR as input to Encap, to obtain the shared secret shared_secret between the first security module and the second business module, and the temporary public key enc of the first security module. This process can be represented as: shared_secret,enc = Encap(pkR), and its implementation principle can be found in the RFC9180 standard.

[0130] 2. The first security module uses shared_secret to encrypt the access request, obtaining the ciphertext.

[0131] 3. The first security module concatenates its temporary public key `enc` with the ciphertext `ciphertext` to obtain the encrypted access request `encrypted-message`. This process can be represented as: `encrypted-message = ...` <enc> || <ciphertext>.

[0132] The second security module decrypts encrypted access requests by using the recipient's private key to obtain the decrypted access request. For example, if the recipient of the access request is the second security module, and its private key is skR, the process of decrypting the encrypted access request by the second security module is as follows:

[0133] 1. The second security module parses the encrypted access request encrypted-message to obtain the temporary public key enc and ciphertext of the first security module.

[0134] 2. The second security module calls the decapsulation function Decap, taking the temporary public key enc and the private key skR of the second business module as inputs to Decap, to obtain the shared secret shared_secret between the first security module and the second business module. This process can be represented as: shared_secret = Decap(enc, skR), and its implementation principle can be found in the RFC 9180 standard.

[0135] 3. The second security module uses shared_secret to decrypt the ciphertext to obtain the plaintext message, which is the decrypted access request.

[0136] The second security module encrypts the access response by using a shared secret (shared_secret) between the first security module and the second business module. For example, the first security module encrypts the access response by using the shared secret (shared_secret) to obtain ciphertext, which is the encrypted access response. The shared secret (shared_secret) is obtained by the second security module from the context.

[0137] The first security module decrypts the encrypted access response by using a shared secret (shared_secret) between the first security module and the second business module. For example, the process involves using the shared secret to decrypt the encrypted access response, obtaining the plaintext message, which is the decrypted access response. The shared secret (shared_secret) is obtained by the second security module from the context.

[0138] It should be noted that the above-mentioned implementation method of encrypting access requests and decrypting access responses by the first security module is only one example in this application and is not intended to limit the corresponding implementation method. The corresponding implementation method can be determined based on application requirements, and this application embodiment will not provide examples of each one.

[0139] Optionally, as shown in Figures 4 and 5, the server system includes multiple second servers. The server system also includes a service frontend. In this case, the connection channels include a first connection channel and a second connection channel. The service frontend connects to the first server through the first connection channel and connects to the multiple second servers through the second connection channels. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to the second connection channel, so that the access requests can be transmitted to the target second business module. The target second business module is located in a second instance of the target second server, and the target second server can be selected by the service frontend from among the multiple second servers based on a specified strategy. For example, the service frontend selects the target second server from among the multiple servers based on rules such as path, identity, or load balancing. Similarly, the service frontend is also used to obtain encrypted access responses from the second connection channels and send encrypted access responses to the first connection channel, so that the encrypted access responses can be transmitted to the first business module. It can be seen from this that when the server system includes a service frontend, the service frontend acts as an intermediary between the first server and the multiple second servers, used to transmit information that needs to be transmitted between the first server and the multiple second servers.

[0140] In addition to acting as a transmission intermediary between the first server and multiple servers, the service frontend can also perform other operations. For example, when the first connection channel is implemented via SSL, access requests and responses are encrypted during the SSL connection process. The service frontend can also decrypt these encrypted access requests and responses. Furthermore, the service frontend can perform operations such as access legitimacy checks. For example, it can perform authentication, permission checks, and access control. The operations that the service frontend can perform can be configured based on application requirements, and this application embodiment does not impose specific limitations on them.

[0141] In this application, there are multiple ways to implement the first security module in obtaining access requests and responses. Similarly, there are multiple ways to implement the second security module in obtaining access requests and responses. The following examples, using the forwarding logic in the existing service architecture without changing it, illustrate the implementation methods of the first and second security modules in obtaining access requests and responses.

[0142] In the first scenario, without altering the forwarding logic of the first business module in the service architecture, the first business module sends an access request to the second business module, including: the first business module sending an access request to the second business module. Correspondingly, the first security module acquires the access request, including: the first security module intercepting the access request. In this case, the recipient of the access request is the second business module. If the first security module is not deployed on the first server, after the first business module sends the access request, the request will be routed to the second business module according to the specified routing strategy. When the first security module is deployed on the first server, because the first security module can intercept access requests, after the first business module sends the access request, the request can be intercepted by the first security module and cannot be routed to the second business module according to the original route; instead, it is transmitted to the second business module via the first security module. In one possible implementation, the first security module may acquire the access request through a hook function or similar method to achieve the purpose of intercepting the access request. It should be understood that the first security module can also intercept access requests through other methods, which will not be exemplified in this embodiment.

[0143] As described above, this implementation scheme does not require changing the forwarding logic of the first business module in the service architecture. Thus, by setting the first security module in the first instance and the second security module in the second instance, no modification to the sending and receiving logic of the first instance is needed, nor is any redesign or application modification of the first business module required. End-to-end encrypted transmission of access requests between the first and second instances can be achieved. If the first instance is an application instance used to implement the tenant's cloud services, end-to-end encrypted transmission of access requests between the user's application instance and the second instance can be achieved without modifying the tenant's application instance. This feature also makes the scheme highly compatible with instances, allowing for easy implementation on existing instances and ensuring the applicability of the scheme.

[0144] In the second scenario, when the forwarding logic of the first business module in the service architecture is changed, the first business module sends an access request to the second business module, including: the first business module sending the access request to the first security module. Correspondingly, the first security module obtains the access request, including: the first security module receiving the access request from the first business module. In this case, the recipient of the access request is the first security module. After the first business module sends the access request, the access request is routed to the first security module, enabling the first security module to obtain the access request.

[0145] As described above, this implementation scheme can also achieve end-to-end encrypted transmission of access requests between the first instance and the second instance. However, it requires changes to the forwarding logic of the first business module, which may have some impact on the implementation of the first business module. For example, it may affect the security capability upgrade of the first business module.

[0146] In the third scenario, without altering the forwarding logic of the second business module within the service architecture, the second business module sends an access response, including sending an access response to the first business module. Correspondingly, the second security module acquires the access response, including intercepting the access response. In this case, the recipient of the access response is the first business module. If the second server does not have a second security module deployed, the access response will be routed to the first business module according to the specified routing policy after the second business module sends it. When the second server has a second security module deployed, because the second security module can intercept the access response, the access response sent by the second business module can be intercepted by the first security module and cannot be routed to the first business module according to the original route; instead, it is transmitted to the first business module via the second security module. In one possible implementation, the second security module may acquire the access response through hook functions or other methods to achieve the purpose of intercepting the access response. It should be understood that the second security module can also intercept the access response through other methods, which will not be exemplified in this embodiment.

[0147] As described above, this implementation scheme does not require changes to the forwarding logic of the second business module in the service architecture. Thus, by setting a second security module in the second instance and a first security module in the first instance, no modifications to the sending and receiving logic of the second instance, nor any redesign or application modification of the second business module, are needed to achieve end-to-end encrypted transmission of access responses between the first and second instances. If the second instance is an application instance used to implement a tenant's cloud service, end-to-end encrypted transmission of access responses between the user's application instance and the first instance can be achieved without modifying the tenant's application instance. This feature also makes the scheme highly compatible with instances, allowing for easy implementation on existing instances and ensuring the applicability of the scheme.

[0148] In the fourth scenario, when the forwarding logic of the second business module in the service architecture is changed, the second business module sends an access response, including sending the access response to the second security module. Correspondingly, the second security module obtains the access response, including receiving the access response from the second business module. In this case, the recipient of the access response is the second security module. After the second business module sends the access response, the response is routed to the second security module, enabling the second security module to obtain the access response.

[0149] As described above, this implementation scheme can also achieve end-to-end encrypted transmission of access responses between the first and second instances. However, it requires changes to the forwarding logic of the second business module, which may have some impact on the implementation of the second business module. For example, it may affect the security capability upgrade of the second business module.

[0150] In the fifth scenario, where the server system includes a service frontend, and without altering the forwarding logic of the service frontend within the service architecture, the service frontend retrieves encrypted access requests from the first connection channel and sends these encrypted access requests to the target second business module via a second connection channel. The target second business module is located in a second instance of the target second server, which may be one of multiple second servers. Correspondingly, the target second security module intercepts the encrypted access requests from the second connection channel, decrypts them, and sends the decrypted access requests to the target second business module. This target second security module is also located in a second instance of the target second server. In this case, the recipient of the access requests sent by the service frontend is the second business module. If the second security module is not deployed on the second server, the access requests sent by the service frontend will be routed to the second business module according to a specified routing strategy. When the second security module is deployed on the second server, it can intercept access requests, preventing them from being routed to the second business module via the original route. Instead, the access requests are transmitted to the second business module via the second security module. In one possible implementation, the second security module may obtain access requests through methods such as hook functions to intercept access requests sent by the service frontend. It should be understood that the second security module can also intercept access requests through other methods, which will not be exemplified in this embodiment.

[0151] Similarly, the target second security module is also used to obtain the access response generated by the target second business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend based on the second connection channel. Correspondingly, the service frontend is also used to obtain the encrypted access response from the second connection channel and send the encrypted access response to the first business module based on the first connection channel. The first security module is also used to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the first business module. At this time, the recipient of the access response sent by the service frontend is the first business module. If the first security module is not deployed in the first server, after the service frontend sends the access response, the access response will be routed to the first business module according to the specified routing policy. When the first security module is deployed in the first server, because the first security module can intercept the access response, after the service frontend sends the access response, the access response can be intercepted by the first security module and cannot be routed to the first business module according to the original route; instead, it is transmitted to the first business module via the first security module. In one possible implementation, the first security module may obtain the access response through a hook function or similar method to intercept the access response sent by the service frontend. It should be understood that the first security module can also intercept the access response through other methods, which will not be listed in detail in this embodiment.

[0152] As described above, this implementation scheme does not require changing the forwarding logic of the service frontend in the service architecture. Therefore, by setting the first security module in the first instance and the second security module in the second instance, end-to-end encrypted transmission of access requests and responses between the first and second instances can be achieved without modifying the service frontend's send / receive logic or redesigning and developing the service frontend.

[0153] In the sixth scenario, when the server system includes a service frontend, and the forwarding logic of the service frontend in the service architecture is changed, the service frontend is used to obtain an encrypted access request from the first connection channel and send the encrypted access request to the target second security module via the second connection channel. The target second security module is located in a second instance of a target second server, which is one of multiple second servers. Correspondingly, the target second security module is used to receive the encrypted access request from the second connection channel, decrypt the encrypted access request, and send the decrypted access request to the target second business module, which is located in the second instance of the target second server. In this case, the recipient of the access request sent by the service frontend is the target second security module, and after the service frontend sends the access request, the access request will be routed to the target second security module.

[0154] Similarly, the target second security module is also used to obtain the access response generated by the target second business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via the second connection channel. Correspondingly, the service frontend is also used to receive the encrypted access response from the second connection channel and send the encrypted access response to the first security module via the first connection channel. The first security module is also used to receive the encrypted access response via the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the first business module. In this case, the recipient of the access response sent by the service frontend is the first security module, and after the service frontend sends the access response, the access response will be routed to the first security module.

[0155] As described above, this implementation scheme can also achieve end-to-end encrypted transmission of access responses between the first and second instances, but it requires changes to the forwarding logic of the service frontend, which may have some impact on the implementation of the service frontend. For example, it may affect the upgrade of the service frontend's security capabilities.

[0156] Furthermore, as shown in Figure 5, the first instance may optionally include a first trusted module, which provides a trusted operating environment for the first service module and the first security module. And / or, as shown in Figure 5, the second instance may optionally include a second trusted module, which provides a trusted operating environment for the second service module and the second security module. By providing a trusted operating environment through the first and second trusted modules, the authenticity of identities in network communication can be ensured, thereby guaranteeing secure communication.

[0157] To ensure the authenticity of identities in network communication, both the first and second trusted modules need to support public-key authentication protocols for end-to-end data encryption. In this application, the implementation of the first and second trusted modules can be determined according to application requirements. In one possible implementation, the first and second trusted modules are implemented through confidential computation. For example, when the first instance is a virtualized instance, the first server is equipped with hardware for implementing confidential computation, and the first trusted module is obtained by virtualizing this hardware. When the second instance is a virtualized instance, the second server is equipped with hardware for implementing confidential computation, and the second trusted module is obtained by virtualizing this hardware. For example, both the first and second trusted modules are implemented through a trusted execution environment (TEE). In another possible implementation, the second and second trusted modules are implemented through other non-confidential computation methods that can guarantee network information security. For example, both the first and second trusted modules support one or more of the following protocols: X.509 certificates, entity attestation tokens (EAT), open identity connect (OIDC), or instance metadata service (IMDS). This allows the server system of this application to achieve end-to-end encryption protection in scenarios supporting one or more of these protocols, effectively ensuring the applicability of the server system. For example, for existing cloud services, the end-to-end data encryption protection scheme of this application can be implemented by extending the cloud service to use methods such as X.509 and OIDC. It should be noted that the description of the implementation methods of the first and second trusted modules here is merely an example and is not intended to limit the implementation methods of the first and second trusted modules. Furthermore, the first business module, the second business module, and the service front-end in this application do not need to be aware of the first and second trusted modules and do not require any adaptive modifications.

[0158] In this application, to ensure the authenticity of identities during network communication, the first security module may optionally verify the identity of the second security module before sending an encrypted access request to the connection channel. In one possible implementation, the first security module is further configured to obtain the service node information of the second security module. If the service node information of the second security module is valid, it sends an encrypted access request to the connection channel; if the service node information of the second security module is invalid, it performs relevant error handling and does not send an encrypted access request to the connection channel.

[0159] The service node information of the second security module is used to verify the identity of the second security module. This service node information includes at least the identity information of the second instance where the second security module resides and public key proof information related to the public key of the second security module. The public key proof information may optionally include the public key of the second security module and / or a trusted proof document generated based on the public key of the second security module. Furthermore, to further ensure the trustworthiness of the service node information, the trusted proof document may also be generated based on information provided by the first security module. For example, the first security module may optionally send a service node information retrieval request to the second security module in advance, the request carrying a first parameter provided by the first security module. The trusted proof document is then generated based on the public key of the second security module and the first parameter provided by the first security module. This first parameter may be a one-time challenge number (nonce), which may be a random number generated by the first security module that can only be used once. The identity information of the second instance where the second security module resides may be the node identifier (nodeId) of the second instance. The public key of the second security module may be the public key pkR in a randomly generated valid key pair (skR, pkR), where skR is the private key. When a second trusted module is configured in the second instance, the key pair is generated based on a specified key generation method after the second security module verifies the trusted operating environment provided by the second trusted module. This application does not limit the key generation method. The verification of the trusted operating environment provided by the second trusted module by the second security module can be performed after the second security module starts.

[0160] For example, after the second security module starts, it verifies the trusted operating environment provided by the second trusted module in the second instance. After the verification is successful, it randomly generates a valid key pair, denoted as (skR, pkR), using a specified key generation method. Upon determining that the first business module needs to access the second business module, the first security module sends a service node information retrieval request to the second security module, such as a FetchPublicKeyEvidence request. This request carries the nonce generated by the first security module. Upon receiving this request, the second security module generates a valid trusted proof document (attestationDoc) based on the nonce and pkR, and then returns the service node information to the first security module. This service node information includes nodeId, pkR, and attestationDoc. Optionally, after obtaining the service node information, the first security module can cache the nodeId and pkR for later use. Furthermore, to ensure the validity of nodeId and pkR, the first security module can set a cache expiration time for nodeId and pkR. After the cache expires, nodeId and pkR need to be retrieved again.

[0161] It should be noted that the key pair for the second security module is not limited to being generated within the second instance; it can also be obtained through other means. For example, the key pair for the second security module may be generated by a third party deployed outside the second instance or second server, and provided to the second security module by the third party. For instance, the key pair for the second security module can be generated via a remote cloud service (such as a Key Management Service (KMS)) and obtained from the remote cloud service through authentication.

[0162] In one possible implementation, the trusted verification method used by the first security module to verify the service node information of the second security module may be pre-obtained by the first security module. For example, the first security module obtains the trusted verification method upon startup. This trusted verification method may be publicly available information, which the first security module can obtain upon startup or when it determines that the first business module needs to access the second business module.

[0163] Optionally, the server system of this application further includes a third server. The third server includes a processing module for maintaining the verification information of the first security module and the second security module. The verification information of the first security module indicates a trusted verification method for verifying the service node information of the first security module. The verification information of the second security module indicates a trusted verification method for verifying the service node information of the second security module. In this case, the first security module can obtain the trusted verification method for verifying the service node information of the second security module from the processing module. That is, the first security module is also used to obtain the verification information of the second security module from the processing module, and, if the service node information of the second security module is determined to be valid based on the verification method indicated by the verification information, sends an encrypted access request to the connection channel. The functions provided by the third server can be presented to users through a service public key management (SPKM) service. This SPKM service can optionally be a cloud service logically decoupled from existing public cloud functions, and the SPKM service can optionally be presented to users as a standalone cloud service or as an add-on service to other cloud services.

[0164] The verification information for either the first or second security module can be obtained by its administrator registering with the third server. For example, before deploying the second instance on the second server, the administrator of the second instance first publishes the services that the second instance can provide to the third server. When the second security module starts, it registers with the third server, and its administrator registers a trusted verification method for verifying the service node information of the second security module with the third server. Alternatively, if a service has multiple modules, each module needs to complete its registration independently.

[0165] In one possible implementation, the third server can provide at least two APIs. As shown in Figure 6, the third server provides two types of APIs. One type of API is the control plane API. For example, as shown in Figure 6, it can be called the PublishService API depending on its purpose, or it may have other names. The other type of API is the data plane API. For example, as shown in Figure 6, it can be called the FetchService API depending on its purpose, or it may have other names. The PublishService API is provided to the service administrator of the SPKM service, mainly for publishing services. The FetchService API is provided to both server-side and client-side applications. For example, as shown in Figure 4, it is provided to the first instance, mainly for fetching services.

[0166] As an example of using the control plane API, when the administrator of the second instance publishes a service to the SPKM service by calling the control plane API, they will send a publish request PublishService(service, howAttestNode) to the SPKM service. The SPKM service will generate a response indicating whether the verification was successful or failed based on the publish request.

[0167] Here, `service` indicates the name of the service to be published, typically represented by a service ID. `howAttestNode` indicates the trusted verification method used to verify the nodes implementing the service. It usually includes the verification method (method), trusted root certificate (rootCert), and verification policy (attestationPolicy) used to verify the service node information. The verification method is a set of verification specifications applicable to a series of trusted subjects that meet specified characteristics. The verification policy is the detailed specification that needs to be refined when verifying a specific trusted subject. For example, suppose the technical specification used to verify the service node information of the second security module is "ABC". "ABC" indicates that verifying the service node information of the second security module requires verifying the trusted baseline PCR value of the second security module. The trusted root certificate used is... <abc-attestation-root-ca-cert>The verification policy specifies that when verifying the service node information of the second security module, the PCR0 and PCR8 values ​​must be verified. The trusted proof document (attestationDoc) contains the actual values ​​of PCR0 and PCR8 for the second security module. When the administrator registers the service, they provide the standard values ​​of PCR0 and PCR8. Verification requires comparing the actual value of PCR0 with its standard value, and comparing the actual value of PCR8 with its standard value.

[0168] In one possible implementation, when an administrator publishes a service in the SPKM service, they can construct a request body for a trusted verification method. This request body carries the standard value of the PCR (Proof of Credential Analysis) to register the trusted verification method of the service with the SPKM service. Corresponding to the trusted verification method mentioned in the previous paragraph, assuming the service to be published is inferencing.sample.com, its trusted verification method request body could be:

[0169] Among them, 121212 is the standard value of PCR0, and 232323 is the standard value of PCR8.

[0170] As a usage example of the data plane API, when the first instance needs to obtain the trusted verification method of the second security module, it sends a service retrieval request `FetchService(service)` to the SPKM service, indicating the trusted verification method of the service provided by the second instance where the second security module resides. Based on this service retrieval request, the SPKM service sends a response `(service, howAttestNode)` back to the first instance. This response indicates the trusted verification method of the service provided by the second instance where the second security module resides. This trusted verification method is suitable for verifying the second security module, and it is the verification method registered for the service provided by the second instance. Here, `service` indicates the name of the service to be published, typically represented by the service ID. `howAttestNode` indicates the trusted verification method used to verify the node implementing the service.

[0171] It should be noted that the deployment of the SPKM service described above is not limited to deployment on a third-party server; other implementation methods are also possible. As an example, the SPKM service can also be deployed using existing servers within the service architecture. For instance, if a load balancer is also deployed in the service architecture, the SPKM service can be deployed on the load balancer. Another example is the deployment of the SPKM service using existing cloud services on a public cloud. For instance, if an Identity and Access Management (IAM) cloud service is already deployed on a public cloud, the SPKM service functionality can be deployed within the extended IAM cloud service. As yet another example, the SPKM service functionality can be implemented not only through the aforementioned dynamic interaction with the server but also through a local static configuration file, which contains the trusted verification methods for services registered with it.

[0172] The following example illustrates the implementation process of accessing the server system in this application. Figure 7 is a schematic diagram of this implementation process. As shown in Figure 7, the implementation process includes the following steps:

[0173] Step 1: After the first security module starts, it calls the FetchService API of the SPKM service to send a service retrieval request FetchService(service) to the SPKM service, instructing the second security module to retrieve the trusted verification method of the service provided by the second instance.

[0174] Step 2: The SPKM service sends a response (service, howAttestNode) to the first security module via the FetchService API. This response indicates the trusted verification method howAttestNode provided by the second instance where the second security module resides.

[0175] Step 3: The first security module sends a service node information retrieval request (FetchPublicKeyEvidence request) to the second security module. The service node information retrieval request carries the nonce generated by the first security module and the identifier of the first instance.

[0176] Step 4: After receiving the service node information retrieval request, the second security module looks up its own key pair (skR, pkR), and then generates a valid trusted proof document attestationDoc based on nonce and pkR to obtain the service node information of the second security module. The service node information includes: nodeId, pkR and attestationDoc.

[0177] Step 5: The second security module returns service node information to the first security module.

[0178] Step 6: The first security module verifies the validity of the service node information attestationDoc, nonce, and pkR using the trusted verification method howAttestNode provided by the second instance where the second security module resides, and adopts an appropriate strategy to cache (nodeId, pkR). After verifying the validity of attestationDoc, nonce, and pkR, proceed to step 7.

[0179] Step 7: The first business module sends an access request to the second business module.

[0180] Step 8: The first security module intercepts the access request.

[0181] Step 9: The first security module encrypts the access request.

[0182] Step 10: The first security module sends an encrypted access request to the second security module through the first connection channel, the service front-end, and the second connection channel.

[0183] Step 11: The second security module obtains the encrypted access request from the connection channel and parses the encrypted access request.

[0184] Step 12: The second security module decrypts the parsed encrypted access request.

[0185] Step 13: The second security module sends a decrypted access request to the second business module.

[0186] Step 14: The second business module generates an access response based on the access request and sends the access response.

[0187] Step 15: The second security module intercepts the access response and encrypts it.

[0188] Step 16: The second security module sends an encrypted access response to the first security module through the second connection channel, the service front-end, and the first connection channel.

[0189] Step 17: The first security module is also used to obtain the encrypted access response from the connection channel and decrypt the encrypted access response.

[0190] Step 18: The first security module sends a decrypted access response to the first business module.

[0191] As can be seen from the above, in the server system provided in this application, since both the first business module and the first security module are located in the first instance, and the first security module is used to encrypt the access request, the access request is already encrypted when it is sent from the first instance. Similarly, both the second business module and the second security module are located in the second instance, and the second security module is used to decrypt the access request, ensuring that the access request remains encrypted before being received by the second instance. In this way, the access request remains encrypted during transmission between the first instance and the second instance, thus achieving end-to-end encryption protection for the access request between the first instance and the second instance.

[0192] The following describes the implementation process of the access method for a server system based on public cloud technology, using the server system provided in this application embodiment as an example. The server system includes a first server and a second server. The first server runs a first instance. The second server runs a second instance. A connection channel is established between the first server and the second server. The first instance includes a first business module and a first security module. The first business module provides services for a first tenant. The second instance includes a second business module and a second security module. The second business module provides services for a second tenant. Figure 8 is a flowchart of an access method for a server system based on public cloud technology provided in this application embodiment. As shown in Figure 8, the implementation process includes the following steps.

[0193] Step 801: The first business module sends an access request to the second business module. The access request is used to request the second business module to provide the second tenant service to the first business module.

[0194] Step 802: The first security module obtains the access request, encrypts the access request, and sends the encrypted access request to the connection channel.

[0195] Step 803: The second security module obtains the encrypted access request from the connection channel, decrypts the encrypted access request, and sends the decrypted access request to the second service module.

[0196] In one possible implementation, the method further includes: a second business module generating an access response to the access request and sending the access response; a second security module obtaining the access response, encrypting the access response, and sending the encrypted access response to the connection channel; and a first security module obtaining the encrypted access response from the connection channel, decrypting the encrypted access response, and sending the decrypted access response to the first business module.

[0197] In one possible implementation, the first business module sends an access request to the second business module, including: the first business module sending the access request to the second business module. Correspondingly, the first security module receives the access request, including: the first security module intercepting the access request.

[0198] Alternatively, the first business module may send an access request to the second business module, including: the first business module sending the access request to the first security module. Correspondingly, the first security module receives the access request, including: the first security module receiving the access request from the first business module.

[0199] In one possible implementation, the second business module sends an access response, including sending the access response to the first business module. Correspondingly, the second security module obtains the access response, including intercepting the access response.

[0200] Alternatively, the second service module sends an access response, including: the second service module sending an access response to the second security module. Correspondingly, the second security module receives the access response, including: the second security module receiving the access response from the second service module.

[0201] In one possible implementation, the server system includes multiple second servers. The server system also includes a service frontend. Connection channels include a first connection channel and a second connection channel. The service frontend connects to the first server via the first connection channel. The service frontend connects to multiple second servers via the second connection channel. The method further includes: the service frontend obtaining an encrypted access request from the first connection channel and sending the encrypted access request to a target second business module via the second connection channel. The target second business module is located in a second instance of a target second server, which is one of multiple second servers. A target second security module intercepts the encrypted access request from the second connection channel, decrypts the encrypted access request, and sends the decrypted access request to the target second business module. The target second security module is located in a second instance of the target second server.

[0202] In one possible implementation, the method further includes: a target second security module obtaining an access response generated by a target second business module based on an access request, encrypting the access response, and sending the encrypted access response to a service frontend via a second connection channel. The service frontend obtains the encrypted access response from the second connection channel and sends the encrypted access response to a first business module via a first connection channel. The first security module intercepts the encrypted access response from the first connection channel, decrypts the encrypted access response, and sends the decrypted access response to the first business module.

[0203] In one possible implementation, the server system includes multiple second servers. The server system also includes a service frontend. Connection channels include a first connection channel and a second connection channel. The service frontend connects to a first server via the first connection channel. The service frontend connects to multiple second servers via the second connection channel. The method further includes: the service frontend obtaining an encrypted access request from the first connection channel and sending the encrypted access request to a target second security module via the second connection channel. The target second security module is located in a second instance of a target second server, which is one of multiple second servers. The target second security module receives the encrypted access request from the second connection channel, decrypts the encrypted access request, and sends the decrypted access request to a target second business module, which is located in a second instance of the target second server.

[0204] In one possible implementation, the method further includes: the target second security module obtaining the access response generated by the target second business module based on the access request, encrypting the access response, and sending the encrypted access response to the service frontend via a second connection channel. The service frontend receives the encrypted access response from the second connection channel and sends the encrypted access response to the first security module via a first connection channel. The first security module receives the encrypted access response via the first connection channel, decrypts the encrypted access response, and sends the decrypted access response to the first business module.

[0205] In one possible implementation, the first instance further includes a first trusted module. The first trusted module provides a trusted operating environment for the first business module and the first security module. The method also includes: verifying the trusted operating environment and generating a key pair. And / or, the second instance further includes a second trusted module, which provides a trusted operating environment for the second business module and the second security module. The method also includes: verifying the trusted operating environment and generating a key pair.

[0206] In one possible implementation, the method further includes: a first security module obtaining service node information of a second security module. Correspondingly, the first security module sends an encrypted access request to the connection channel, including: the first security module sending the encrypted access request to the connection channel if the service node information of the second security module is valid.

[0207] In one possible implementation, the server system further includes a third server. The third server has a processing module. The processing module maintains the verification information of the first security module and the second security module. The method further includes: the first security module obtaining the verification information of the second security module from the processing module. Correspondingly, the first security module sends an encrypted access request to the connection channel, including: if the first security module determines that the service node information of the second security module is valid based on the verification method indicated by the verification information, the first security module sends the encrypted access request to the connection channel.

[0208] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working principles and implementation processes of each process described above can be found in the corresponding content of the aforementioned server system embodiments, and will not be repeated here.

[0209] Corresponding to the aforementioned server system, this application also provides an instance creation method based on public cloud technology. This method is applied to a cloud management platform, which manages infrastructure, including multiple servers. The implementation process of this instance creation method based on public cloud technology is described below.

[0210] Figure 9 is a flowchart of an instance creation method based on public cloud technology provided in an embodiment of this application. As shown in Figure 9, the instance creation method based on public cloud technology includes the following steps:

[0211] Step 901: Obtain the instance creation request input by the tenant. The instance creation request carries the specifications of the target instance to be created and indicates the image file of the target instance.

[0212] When a tenant needs to create an instance based on infrastructure managed by the cloud management platform, they can perform a specified operation on their client to trigger an instance creation request. This allows the cloud management platform to create the instance for the tenant under the guidance of the instance creation request. In one possible implementation, the cloud management platform can provide an instance creation interface to the tenant, which the tenant can use to trigger an instance creation request. The instance creation request carries the specifications of the target instance to be created and indicates the image file of the target instance. For example, the instance creation request carries either the image file of the target instance or indication information about the image file of the target instance. After the tenant triggers the instance creation request, the cloud management platform can obtain the instance creation request through the instance creation interface, retrieve the specifications of the target instance to be created from the request, and determine the image file of the target instance.

[0213] For example, the instance creation interface is implemented through one or more of the following: an application programming interface (API), interactive templates, and a configuration interface. Interactive templates are provided by the cloud management platform to tenants to implement different functions. When a tenant needs to use a certain function, they can download the template to implement that function, add their relevant information to the template, and then send the template with the added tenant information back to the cloud management platform. After receiving the template with the added tenant information, the cloud management platform can obtain the function that the template needs to implement and customize the implementation of that function according to the tenant's information. The configuration interface refers to the interface through which tenants can operate to indicate the functions they need to implement.

[0214] Step 902: Select the target server from multiple servers that can provide the target instance specifications.

[0215] Once the cloud management platform obtains the specifications of the target instance to be created, it can select a server that can provide those specifications from the infrastructure to obtain the target server.

[0216] Step 903: Create a target service module for the target instance on the target server based on the image file, and create a target security module for the target instance on the target server. Deploy the target service module and the target security module in one instance to obtain the target instance. The target service module is used to provide target tenant services. The target service module is also used to send access requests to other service modules. The access requests are used to request other service modules to provide other tenant services to the target service module. The other service modules are deployed in other instances running on other servers. The other servers are servers other than the target server. The target security module is used to obtain the access requests, encrypt the access requests, and send the encrypted access requests to the connection channel between the target server and other servers. The other security modules are used to obtain the encrypted access requests from the connection channel, decrypt the encrypted access requests, and send the decrypted access requests to the other service modules.

[0217] After selecting a target server with the specifications required to provide the target instance in the infrastructure, the cloud management platform can create a target instance that conforms to those specifications on the target server. To ensure the target instance can provide services to tenants, the cloud management platform needs to create a target service module for the target instance on the target server based on the image file. To achieve end-to-end encrypted access between instances, the cloud management platform also needs to create a target security module for the target instance on the target server and deploy the target service module and target security module in a single instance, thus obtaining the target instance. The specifications of the created target instance must match the specifications of the target instance indicated in the instance creation request. For example, when the target instance specifications indicated in the instance creation request include multiple parameters (such as computing power, memory size, memory bus width, and memory bandwidth), the multiple parameters allocated by the cloud management platform to the created target instance correspond one-to-one with the multiple parameters indicated in the target instance specifications of the instance creation request, and any one of the multiple parameters allocated by the cloud management platform to the created target instance is equal to or slightly greater than the corresponding parameter indicated in the target instance specifications of the instance creation request.

[0218] In one possible implementation, other business modules are also used to generate and send access responses to the access requests. Other security modules are also used to obtain the access response, encrypt it, and send the encrypted access response to the connection channel. The target security module is also used to obtain the encrypted access response from the connection channel, decrypt it, and send the decrypted access response to the target business module.

[0219] In one possible implementation, the target business module sends an access request to another business module, including: the target business module sending the access request to the other business module. Correspondingly, the target security module receives the access request, including: the target security module intercepting the access request.

[0220] Alternatively, the target business module may send an access request to another business module, including: the target business module sending an access request to the target security module. Correspondingly, the target security module receives the access request, including: the target security module receiving the access request from the target business module.

[0221] In one possible implementation, other business modules send access responses, including sending access responses to the target business module. Correspondingly, other security modules obtain access responses, including intercepted access responses.

[0222] Alternatively, other business modules may send access responses, including sending access responses to other security modules. Correspondingly, other security modules may receive access responses, including receiving access responses from other business modules.

[0223] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend via the first connection channel. The service frontend connects to multiple other servers via the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target business modules via the second connection channel. These other target business modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. Correspondingly, a security module is used to intercept the encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to the other target business modules. This security module is located in other instances of the other target servers.

[0224] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to obtain the encrypted access response from the second connection channel and send the encrypted access response to the target business module via a first connection channel. The target security module is further configured to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0225] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend through the first connection channel, and the service frontend connects to multiple other servers through the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target security modules via the second connection channel. These other target security modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. Correspondingly, these other target security modules are used to receive encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to other target business modules, which are also located in other instances of the other target servers.

[0226] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to receive the encrypted access response from the second connection channel and send the encrypted access response to the target security module via a first connection channel. The target security module is further configured to receive the encrypted access response via the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0227] In one possible implementation, the method further includes: creating a target trusted module for a target instance on the target server, deploying the target trusted module in the target instance, and using the target trusted module to provide a trusted operating environment for the target business module and the target security module.

[0228] In one possible implementation, the target security module is also used to obtain service node information of other security modules, and if the service node information of other security modules is valid, to send an encrypted access request to the connection channel.

[0229] In one possible implementation, the target security module is also used to obtain verification information of other security modules from the processing module of the third server, and if the service node information of other security modules is determined to be valid based on the verification method indicated by the verification information, the target security module sends an encrypted access request to the connection channel. The processing module is used to maintain the verification information of the target security module and other security modules.

[0230] The above describes the instance creation method based on public cloud technology according to embodiments of this application. Corresponding to the above method, embodiments of this application also provide a cloud management platform. The cloud management platform is used to manage infrastructure. The infrastructure includes multiple servers. Figure 10 is a schematic diagram of the structure of a cloud management platform provided in an embodiment of this application. Based on the following components shown in Figure 10, the cloud management platform shown in Figure 10 can perform all or part of the operations shown in Figure 9 above. It should be understood that the device may include more additional components than the components shown or omit some of the components shown, and embodiments of this application do not limit this. As shown in Figure 10, the cloud management platform 10 may include:

[0231] The acquisition unit 101 is used to acquire the instance creation request input by the tenant. The instance creation request carries the specifications of the target instance to be created and indicates the image file of the target instance.

[0232] Selection unit 102 is used to select a target server that can provide the specifications from among multiple servers.

[0233] Creation unit 103 is used to create a target instance's target business module on the target server based on the image file, and to create a target instance's target security module on the target server. The target business module and target security module are deployed in one instance to obtain the target instance. The target business module is used to provide target tenant services. The target business module is also used to send access requests to other business modules, requesting these modules to provide other tenant services to the target business module. These other business modules are deployed in other instances running on other servers (excluding the target server). The target security module is used to obtain the access requests, encrypt them, and send the encrypted access requests to the connection channel between the target server and other servers. The other security modules are used to obtain the encrypted access requests from the connection channel, decrypt them, and send the decrypted access requests to the other business modules.

[0234] In one possible implementation, other business modules are also used to generate and send access responses to the access requests. Other security modules are also used to obtain the access response, encrypt it, and send the encrypted access response to the connection channel. The target security module is also used to obtain the encrypted access response from the connection channel, decrypt it, and send the decrypted access response to the target business module.

[0235] In one possible implementation, the target business module sends an access request to another business module, including: the target business module sending the access request to the other business module. Correspondingly, the target security module receives the access request, including: the target security module intercepting the access request.

[0236] Alternatively, the target business module may send access requests to other business modules, including: the target business module sending access requests to the target security module. The target security module may then receive the access requests from the target business module.

[0237] In one possible implementation, other business modules send access responses, including sending access responses to the target business module. Correspondingly, other security modules obtain access responses, including intercepted access responses.

[0238] Alternatively, other business modules may send access responses, including sending access responses to other security modules. Correspondingly, other security modules may receive access responses, including receiving access responses from other business modules.

[0239] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend through the first connection channel, and the service frontend connects to multiple other servers through the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target business modules based on the second connection channel. These other target business modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. Correspondingly, a security module is used to intercept the encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to the other target business modules. This security module is also located in other instances of the other target servers.

[0240] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to obtain the encrypted access response from the second connection channel and send the encrypted access response to the target business module via a first connection channel. The target security module is further configured to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0241] In one possible implementation, the connection channels include a first connection channel and a second connection channel. The target server connects to the service frontend through the first connection channel, and the service frontend connects to multiple other servers through the second connection channel. The service frontend is used to obtain encrypted access requests from the first connection channel and send encrypted access requests to other target security modules based on the second connection channel. These other target security modules are located in other instances of the other target servers, and the other target servers are one of multiple other servers. The other target security modules are used to receive encrypted access requests from the second connection channel, decrypt the encrypted access requests, and send decrypted access requests to other target business modules, which are also located in other instances of the other target servers.

[0242] In one possible implementation, the target security module is further configured to obtain the access response generated by the target business module based on the access request, encrypt the access response, and send the encrypted access response to the service frontend via a second connection channel. Correspondingly, the service frontend is further configured to receive the encrypted access response from the second connection channel and send the encrypted access response to the target security module via a first connection channel. The target security module is further configured to receive the encrypted access response via the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the target business module.

[0243] In one possible implementation, the creation unit is also used to create a target trusted module for a target instance on the target server, and to deploy the target trusted module on the target instance. The target trusted module is used to provide a trusted operating environment for the target business module and the target security module.

[0244] In one possible implementation, the target security module is also used to obtain service node information of other security modules, and if the service node information of other security modules is valid, to send an encrypted access request to the connection channel.

[0245] In one possible implementation, the target security module is also used to obtain verification information of other security modules from the processing module of the third server, and if the service node information of other security modules is determined to be valid based on the verification method indicated by the verification information, the target security module sends an encrypted access request to the connection channel. The processing module is used to maintain the verification information of the target security module and other security modules.

[0246] Here, the detailed working process of the acquisition unit 101, selection unit 102, and creation unit 103 is described in the preceding method embodiments. For example, the acquisition unit 101 acquires the instance creation request input by the tenant using the aforementioned step 901. The selection unit 102 selects a target server capable of providing the specifications from multiple servers using the aforementioned step 902. The creation unit 103 creates the target service module of the target instance on the target server based on the image file using the aforementioned step 903, and creates the target security module of the target instance on the target server. The target service module and the target security module are deployed in one instance to obtain the target instance. The target service module is used to provide services to the target tenant. The embodiments of this application will not be described again here.

[0247] The acquisition unit 101, selection unit 102, and creation unit 103 can all be implemented by software or by an executable program. For example, the implementation of the acquisition unit 101 will be described below. Similarly, the implementation of the selection unit 102 and creation unit 103 can refer to the implementation of the acquisition unit 101.

[0248] As an example of a software functional unit, the acquisition unit 101 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, the acquisition unit 101 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one cloud data center or multiple geographically proximate cloud data centers. Typically, a region may include multiple AZs.

[0249] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0250] As an example of a hardware functional unit, the acquisition unit 101 may include at least one computing device, such as a server. Alternatively, the acquisition unit 101 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0251] The multiple computing devices included in the acquisition unit 101 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the acquisition unit 101 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the acquisition unit 101 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0252] It should be noted that, in other embodiments, any one of the acquisition unit 101, selection unit 102, and creation unit 103 can be used to execute any step in the instance creation method based on public cloud technology. The steps implemented by the acquisition unit 101, selection unit 102, and creation unit 103 can be specified as needed. By implementing different steps in the instance creation method based on public cloud technology through the acquisition unit 101, selection unit 102, and creation unit 103, all functions of the cloud management platform can be realized.

[0253] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the various components described above can be referred to the corresponding contents in the foregoing embodiments, and will not be repeated here.

[0254] Furthermore, the order of steps in the server system and its access method, instance creation method, and cloud management platform based on public cloud technology provided in this application can be appropriately adjusted, and the steps can also be added or removed as needed. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0255] The following provides examples illustrating the basic hardware structures involved in the embodiments of this application.

[0256] This application also provides a computing device 1100. As shown in FIG11, the computing device 1100 includes: a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. The processor 1104, the memory 1106, and the communication interface 1108 communicate with each other via the bus 1102. The computing device 1100 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 1100.

[0257] Bus 1102 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 11, but this does not imply that there is only one bus or one type of bus. Bus 1102 can include pathways for transmitting information between various components of computing device 1100 (e.g., memory 1106, processor 1104, communication interface 1108).

[0258] The processor 1104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0259] The memory 1106 may include volatile memory, such as random access memory (RAM). The processor 1104 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0260] The memory 1106 stores executable program code, and the processor 1104 executes the executable program code to implement the functions of the aforementioned modules or units, thereby realizing a server system based on public cloud technology and its access methods, instance creation methods, and cloud management platform. That is, the memory 1106 stores instructions for executing the server system based on public cloud technology and its access methods, instance creation methods, and cloud management platform.

[0261] The communication interface 1108 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1100 and other devices or communication networks.

[0262] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0263] As shown in Figure 12, the computing device cluster includes at least one computing device 1100. The memory 1106 of one or more computing devices 1100 in the computing device cluster may store the same instructions for executing server systems based on public cloud technology, as well as their access methods, instance creation methods, and cloud management platforms.

[0264] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store partial instructions for executing server systems based on public cloud technology and their access methods, instance creation methods, and cloud management platforms. In other words, a combination of one or more computing devices 1100 can jointly execute instructions for executing server systems based on public cloud technology and their access methods, instance creation methods, and cloud management platforms.

[0265] It should be noted that the memory 1106 in different computing devices 1100 within the computing device cluster can store different instructions, which are used to execute certain functions of the cloud resource management device based on public cloud technology. That is, the instructions stored in the memory 1106 of different computing devices 1100 can implement the functions of one or more of the aforementioned modules or units.

[0266] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 13 illustrates one possible implementation. As shown in Figure 13, two computing devices, 1100A and 1100B, are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device.

[0267] It should be understood that the functions of computing device 1100A shown in Figure 13 can also be performed by multiple computing devices 1100. Similarly, the functions of computing device 1100B can also be performed by multiple computing devices 1100.

[0268] This application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to the connection method of the computing device clusters in Figures 12 and 13. The difference is that the memory 1106 in one or more computing devices 1100 in this computing device cluster can store the same instructions for executing server systems based on public cloud technology and their access methods, instance creation methods, and cloud management platforms.

[0269] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store partial instructions for executing server systems based on public cloud technology and their access methods, instance creation methods, and cloud management platforms. In other words, a combination of one or more computing devices 1100 can jointly execute instructions for executing server systems based on public cloud technology and their access methods, instance creation methods, and cloud management platforms.

[0270] This application also provides a computer program product containing instructions. The computer program product may be software or program products containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to execute a server system based on public cloud technology, its access method, instance creation method, and cloud management platform.

[0271] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a server system based on public cloud technology and its access methods, instance creation methods, and a cloud management platform, or instruct the computing device to execute a server system based on public cloud technology and its access methods, instance creation methods, and a cloud management platform.

[0272] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0273] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the raw data and executable code involved in this application were obtained with full authorization.

[0274] In the embodiments of this application, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The term "at least one" refers to one or more, and the term "multiple" refers to two or more, unless otherwise expressly defined.

[0275] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0276] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the concept and principles of this application should be included within the protection scope of this application. < / ciphertext> < / enc>

Claims

1. A server system based on public cloud technology, characterized in that, The server system includes a first server and a second server. The first server runs a first instance, and the second server runs a second instance. A connection channel is established between the first server and the second server. The first instance includes a first business module and a first security module, wherein the first business module is used to provide services to the first tenant. The second instance includes a second business module and a second security module, the second business module being used to provide services for the second tenant; The first service module is further configured to send an access request to the second service module, the access request being used to request the second service module to provide the second tenant service to the first service module; The first security module is used to acquire the access request, encrypt the access request, and send the encrypted access request to the connection channel; The second security module is used to obtain the encrypted access request from the connection channel, decrypt the encrypted access request, and send the decrypted access request to the second service module.

2. The server system according to claim 1, characterized in that, The second business module is also used to generate an access response to the access request and send the access response; The second security module is also used to acquire the access response, encrypt the access response, and send the encrypted access response to the connection channel; The first security module is further configured to obtain the encrypted access response from the connection channel, decrypt the encrypted access response, and send the decrypted access response to the first service module.

3. The server system according to claim 1 or 2, characterized in that, The first service module sends an access request to the second service module, including: The first business module sends an access request to the second business module; The first security module obtains the access request, including: The first security module intercepts the access request.

4. The server system according to claim 2, characterized in that, The second service module sends the access response, including: The second service module sends the access response to the first service module; The second security module obtains the access response, including: The access response is intercepted by the second security module.

5. The server system according to any one of claims 1 to 4, characterized in that, The server system includes multiple second servers, and the server system further includes a service front-end. The connection channel includes a first connection channel and a second connection channel. The service front-end is connected to the first server through the first connection channel, and the service front-end is connected to the multiple second servers through the second connection channel. The service front end is used to obtain the encrypted access request from the first connection channel and send the encrypted access request to the target second business module based on the second connection channel. The target second business module is set in a second instance of the target second server, and the target second server is one of the plurality of second servers. The target second security module is used to intercept the encrypted access request from the second connection channel, decrypt the encrypted access request, and send the decrypted access request to the target second service module. The target second security module is set in the second instance of the target second server.

6. The server system according to claim 5, characterized in that, The target second security module is also used to obtain the access response generated by the target second business module based on the access request, encrypt the access response, and send the encrypted access response to the service front end based on the second connection channel; The service front end is also used to obtain the encrypted access response from the second connection channel and send the encrypted access response to the first business module based on the first connection channel; The first security module is further configured to intercept the encrypted access response from the first connection channel, decrypt the encrypted access response, and send the decrypted access response to the first service module.

7. The server system according to any one of claims 1 to 6, characterized in that, The first instance also includes a first trusted module, which provides a trusted operating environment for the first business module and the first security module. And / or, the second instance also includes a second trusted module, which provides a trusted operating environment for the second business module and the second security module.

8. The server system according to any one of claims 1 to 7, characterized in that, The first security module is also used to obtain the service node information of the second security module, and if the service node information of the second security module is valid, to send the encrypted access request to the connection channel.

9. The server system according to claim 8, characterized in that, The server system also includes a third server; The third server is equipped with a processing module, which is used to maintain the verification information of the first security module and the second security module; The first security module is further configured to obtain the verification information of the second security module from the processing module, and, if the service node information of the second security module is determined to be valid based on the verification method indicated by the verification information, send the encrypted access request to the connection channel.

10. A method for creating instances based on public cloud technology, characterized in that, The method is applied to a cloud management platform, which manages infrastructure, including multiple servers. The method includes: Obtain an instance creation request input by a tenant, the instance creation request carrying the specifications of the target instance to be created, and the instance creation request indicating the image file of the target instance; Select the target server from the plurality of servers that can provide the specified specifications; On the target server, a target service module of the target instance is created based on the image file, and a target security module of the target instance is created on the target server. The target service module and the target security module are deployed in one instance to obtain the target instance. The target service module is used to provide target tenant services. The target business module is further configured to send access requests to other business modules. The access requests are used to request the other business modules to provide other tenant services to the target business module. The other business modules are deployed in other instances running on other servers. The other servers are servers other than the target server among the plurality of servers. The target security module is used to obtain the access request, encrypt the access request, and send the encrypted access request to the connection channel between the target server and the other servers. The other security modules are used to obtain the encrypted access request from the connection channel, decrypt the encrypted access request, and send the decrypted access request to the other service modules.

11. The method according to claim 10, characterized in that, The other business modules are also used to generate an access response to the access request and send the access response; The other security modules are also used to obtain the access response, encrypt the access response, and send the encrypted access response to the connection channel; The target security module is also used to obtain the encrypted access response from the connection channel, decrypt the encrypted access response, and send the decrypted access response to the target service module.

12. The method according to claim 10 or 11, characterized in that, The method further includes: A target trusted module is created on the target server for the target instance, and the target trusted module is deployed in the target instance. The target trusted module is used to provide a trusted operating environment for the target business module and the target security module.

13. A cloud management platform, characterized in that, The cloud management platform is used to manage infrastructure, which includes multiple servers. The cloud management platform includes: The acquisition unit is used to acquire an instance creation request input by a tenant, wherein the instance creation request carries the specifications of the target instance to be created and indicates the image file of the target instance; The selection unit is used to select a target server among the plurality of servers that can provide the specified specifications. A creation unit is used to create a target business module of the target instance on the target server based on the image file, and to create a target security module of the target instance on the target server. The target business module and the target security module are deployed in one instance to obtain the target instance. The target business module is used to provide target tenant services. The target business module is further configured to send access requests to other business modules. The access requests are used to request the other business modules to provide other tenant services to the target business module. The other business modules are deployed in other instances running on other servers. The other servers are servers other than the target server among the plurality of servers. The target security module is used to obtain the access request, encrypt the access request, and send the encrypted access request to the connection channel between the target server and the other servers. The other security modules are used to obtain the encrypted access request from the connection channel, decrypt the encrypted access request, and send the decrypted access request to the other service modules.

14. The cloud management platform according to claim 13, characterized in that, The other business modules are also used to generate an access response to the access request and send the access response; The other security modules are also used to obtain the access response, encrypt the access response, and send the encrypted access response to the connection channel; The target security module is also used to obtain the encrypted access response from the connection channel, decrypt the encrypted access response, and send the decrypted access response to the target service module.

15. The cloud management platform according to claim 13 or 14, characterized in that, The creation unit is further configured to create a target trusted module for the target instance on the target server, and deploy the target trusted module in the target instance. The target trusted module is used to provide a trusted operating environment for the target business module and the target security module.

16. A computing device, characterized in that, The device includes a processor and a memory, the memory storing program instructions, and the processor executing the program instructions to enable the computing device to implement a server in any one of the server systems described in claims 1 to 9.

17. A computing device cluster, characterized in that, The system includes multiple computing devices, each comprising multiple processors and multiple memories, wherein program instructions are stored in the multiple memories, and the multiple processors execute the program instructions, thereby enabling the cluster of computing devices to implement the server system according to any one of claims 1 to 9.

18. A computer-readable storage medium, characterized in that, Includes program instructions that, when executed on a computing device, cause the computing device to implement the server in any one of claims 1 to 9.

19. A computer program product containing instructions, characterized in that, When the instructions are executed by the computing device, the computing device enables the computing device to implement the server in any one of the server systems of claims 1 to 9.

Images