Encryption communication method, verification method and related device for cloud security protection

Abstract

An encrypted communication method, verification method, and related equipment for cloud security protection are provided. The method involves receiving first data from a first unit through a second unit and encrypting the first data based on a first encryption module. This allows the first unit to be unaware of the specific encryption and decryption process, thereby reducing the intrusion of encryption and decryption logic into business code and the cost of business transformation, and achieving low-intrusion or even seamless encrypted communication with upper-layer protocols.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an encrypted communication method, verification method, and related equipment for cloud security protection. Background Technology

[0002] In internet business scenarios, data typically flows between multiple business services and their dependencies, thus requiring appropriate data protection mechanisms to ensure the security of data transmission and processing. Related technologies often involve integrating encryption / decryption software development kits (SDKs) into different business services and their dependencies, a method that significantly intrudes on the business code. Summary of the Invention

[0003] This paper proposes an encrypted communication method, verification method, and related equipment for cloud security protection, which can solve or partially solve the above problems to a certain extent.

[0004] In a first aspect, an encrypted communication method for cloud security protection is provided, the method comprising: storing business information in a first unit, the business information indicating information for processing business data; transmitting first data in a second unit, the first data originating from the first unit and obtained based on the business data; wherein the second unit includes a first encryption module, and transmitting the first data comprises: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

[0005] Secondly, a verification method for cloud security protection is provided, applied to remote authentication services, comprising: receiving a deployment resource set and a mirror address set from a deployment unit, wherein the deployment resource set and the mirror address set are deployment information required by the deployment unit to deploy multiple first units; the first unit is used to store business information and send first data to a second unit; the business information indicates information for processing the business data, wherein the first data is obtained based on the business data; the second unit is used to transmit the first data; and generating a verification report for the multiple first units based on the deployment resource set, the mirror address set, and the policy file set; wherein the policy file set is created based on the deployment resource set.

[0006] Thirdly, a cloud server is provided, comprising: a first unit for storing business information, the business information indicating information for processing business data; a second unit for transmitting first data, the first data originating from the first unit and obtained based on the business data; wherein the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

[0007] Fourthly, a client is provided, comprising: a first unit for storing business information, the business information indicating information for processing business data; a second unit for transmitting first data, the first data originating from the first unit and obtained based on the business data; wherein the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

[0008] Fifthly, a remote verification service is provided, comprising: a receiving module, configured to receive a deployment resource set and a mirror address set from a deployment unit, wherein the deployment resource set and the mirror address set are deployment information required by the deployment unit to deploy multiple first units; the first unit is configured to store business information and send first data to a second unit; the business information indicates information for processing the business data, wherein the first data is obtained based on the business data; the second unit is configured to transmit the first data; and a verification module, configured to generate a verification report for the multiple first units based on the deployment resource set, the mirror address set, and a policy file set; wherein the policy file set is created based on the deployment resource set.

[0009] In a sixth aspect, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the encrypted communication method for cloud security protection or the verification method for cloud security protection.

[0010] In a seventh aspect, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium storing computer instructions, the computer instructions being used to cause a computer to execute the encrypted communication method for cloud security protection or the verification method for cloud security protection.

[0011] The aforementioned encrypted communication method, verification method, and related equipment for cloud security protection receive first data from the first unit through the second unit and encrypt the first data based on the first encryption module. This allows the first unit to be unaware of the specific encryption and decryption process, thereby reducing the intrusion of encryption and decryption logic into business code and the cost of business transformation, and achieving low-intrusion or even imperceptible encrypted communication with upper-layer protocols. Attached Figure Description

[0012] To more clearly illustrate the technical solution, the accompanying drawings used are briefly introduced below. Obviously, the drawings described below are merely some exemplary cases. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0013] Figure 1 This is a schematic diagram illustrating a scenario for an encrypted communication method used for cloud security protection.

[0014] Figure 2 This is a flowchart illustrating an encrypted communication method for cloud security protection. Figure 3a This is a deployment diagram of the first and second units in the edge-side seamless encryption / decryption SDK mode; Figure 3b This is a schematic diagram of the deployment of the first and second units in the protocol layer mode; Figure 3c This is a schematic diagram illustrating the deployment of the first and second units in the cloud-side seamless encryption / decryption SDK mode. Figure 3d This is a schematic diagram illustrating the deployment of the first and second units under the local encryption / decryption proxy mode. Figure 4a This is a schematic diagram illustrating the official SDK processing for the client in related technologies; Figure 4b A schematic diagram of the official SDK processing for integrating the seamless encryption / decryption SDK mode into the client; Figure 5 A flowchart illustrating the data encryption and decryption process for the proxy node, the first unit, and the second unit; Figure 6 This is a schematic diagram of the protocol layer structure; Figure 7 A diagram illustrating encrypted paths between different business containers; Figure 8 A diagram illustrating encrypted paths between different cloud servers; Figure 9 This is a flowchart illustrating a verification method for cloud security protection. Figure 10 A timing diagram for batch remote authentication of microservices; Figure 11 This is a schematic diagram of the electronic device. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages clearer, the following detailed explanation is provided in conjunction with the specific circumstances and with reference to the accompanying drawings.

[0016] It should be noted that, unless otherwise defined, the technical or scientific terms used should have the common meaning understood by a person with general skills in the field. The use of terms such as "first," "second," and similar terms does not indicate any order, quantity, or importance, but is merely used to distinguish different components. Terms such as "including" or "contains" mean that the element or object preceding the word covers the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0017] It is understood that before using the technical solutions in each scenario described in this manual, the user will be informed of the type, scope of use, and usage scenarios of the personal information involved through appropriate means, and the user's authorization will be obtained.

[0018] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to choose, based on the prompt message, whether to provide personal information to the software or hardware such as the electronic device, application program, server, or storage medium performing the operation of the technical solution described in this specification.

[0019] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0020] It is understood that the above notification and user authorization process is merely illustrative and does not constitute a limitation on the implementation method of this specification. Other methods that comply with relevant laws and regulations may also be applied to the implementation method of this specification.

[0021] In internet business scenarios, a complete service system typically includes multiple microservices. These microservices can interact via Hypertext Transfer Protocol (HTTP), Remote Procedure Call (RPC), message queues, and other methods. Furthermore, during business processing, they may interact with infrastructure services such as storage services, logging services, monitoring services, message queue services, configuration management services, and caching services, or with services provided by other business containers and cloud servers. Therefore, data not only flows between the client and the cloud server, but also continuously between business containers and infrastructure services within the cloud server, and between different cloud servers. To ensure the security of data transmission and processing across edge-to-cloud, cloud-within-the-cloud, and cloud-to-cloud pathways, a unified and continuous data protection mechanism is needed for these data flow processes.

[0022] In related technologies, secure communication is typically achieved by integrating encryption / decryption SDKs into the caller, server, or client side. For example, an encryption / decryption SDK can be integrated on the client or client side to protect the first hop communication from the client to the cloud; alternatively, when a business service accesses services provided by different infrastructure services, other business containers, or other cloud servers, the corresponding encryption / decryption SDK can be integrated to achieve confidential communication on specific links. These methods can improve data security in certain communication links to a certain extent.

[0023] However, in complex microservice architectures, the number of business services is large, and the dependency chains are complex. Different business services and different dependency chains usually need to integrate and adapt encryption / decryption SDKs separately. This approach easily leads to coupling of encryption / decryption logic with business code, increasing the amount of business modification and access costs. At the same time, the access methods of different chains are not uniform, and subsequent algorithm upgrades, key management, policy adjustments, and version maintenance also need to be handled separately in multiple business services or dependency chains, resulting in high maintenance costs. Therefore, existing edge-to-cloud, cloud-within-the-cloud, and cloud-to-cloud secure communication solutions are difficult to achieve low-intrusion or even imperceptible encrypted communication of upper-layer business protocols in complex microservice systems, and it is also difficult to form a unified and transparent end-to-end data protection capability.

[0024] On the other hand, to ensure the trustworthiness of the operating environment carrying business services, related technologies can also employ remote verification mechanisms to perform trusted verification of confidential services or workloads. Existing remote verification mechanisms typically generate verification policies and obtain remote verification results on a per-instance basis for a single confidential service or a single workload. This approach can meet basic verification requirements in scenarios with a small number of services.

[0025] However, in large-scale cloud-native systems, business services may include workloads of various resource types, such as stateless workloads (Deployments), stateful workloads (StatefulSets), and daemon sets (DaemonSets). Deployments can be used to deploy and manage stateless applications, StatefulSets can be used to deploy and manage stateful applications, and DaemonSets can be used to run a background daemon on each node of the cluster. Each type of workload may contain multiple instances. If we still configure proof policies and perform remote proofs separately for each service instance or workload, it can easily lead to problems such as policy fragmentation, management complexity, and low verification efficiency, making it difficult to support unified trusted verification and centralized management in complex microservice systems.

[0026] Therefore, in cloud-native microservice scenarios, how to reduce business code intrusion and access maintenance costs, how to achieve unified, transparent, and encrypted communication between the end-to-cloud, within the cloud, and on the cloud-to-cloud link, and how to perform unified, efficient, and centralized trusted verification and management of large-scale microservice workloads have become urgent technical problems to be solved.

[0027] refer to Figure 1 This diagram illustrates an application scenario for the encrypted communication method provided for cloud security protection. The application scenario may include a client 101 and a cloud server 102. The client 101 and the cloud server 102 can establish a connection via a wired or wireless communication network to achieve interactive processes such as data request, data upload, data download, and return of business processing results. The aforementioned communication network may include the Internet, mobile communication networks, local area networks, private networks, or combinations thereof, and is not limited thereto.

[0028] Client 101 can run on a terminal device. Terminal devices include, but are not limited to, desktop computers, mobile phones, laptops, media players, smart wearable devices, personal digital assistants (PDAs), or other electronic devices capable of performing the aforementioned functions. Cloud server 102 can be a standalone physical server, a server cluster or distributed system based on multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0029] Cloud server 102 can be used to provide data transmission and business processing services to client 101. Client 101 can generate data to be transmitted in response to user data upload, download, synchronization, or business processing operations. To ensure the security of the data to be transmitted during transmission, in one implementation, client 101 can encrypt the data to be transmitted and send the encrypted data to cloud server 102 through the communication network; in another implementation, client 101 can also send the data to be transmitted to a proxy node, where the proxy node encrypts the data and sends the encrypted data to cloud server 102. The proxy node can be a forwarding node, gateway node, edge node, or other node with data encryption and forwarding capabilities deployed between client 101 and cloud server 102.

[0030] After receiving encrypted data to be transmitted, cloud server 102 can decrypt it and then parse, verify, store, forward, or process the decrypted data to obtain the corresponding processing result. Cloud server 102 can also encrypt the processing result and return it to client 101, or return the encrypted processing result to client 101 through a proxy node. After receiving the data returned by cloud server 102, client 101 can decrypt the returned data; if the returned data is transmitted through a proxy node, it can also decrypt or forward the returned data through the proxy node. Client 101 can display the data transmission result to the user, or perform operations such as page updates, file saving, status synchronization, and business feedback based on the returned data, thereby achieving secure data interaction and business collaboration between client 101 and cloud server 102.

[0031] In some scenarios, cloud server 102 may include a Trusted Execution Environment (TEE) and an untrusted execution environment. The trusted execution environment can be a secure operating environment within cloud server 102 that provides hardware-level and / or system-level isolation protection. It can isolate and protect the code, data, and execution processes running within it, reducing the risk of the host operating system, other applications, or unauthorized entities accessing, tampering with, or disclosing relevant business data.

[0032] Business containers can be deployed within a Trusted Execution Environment (TEE). A business container can be a containerized runtime instance deployed on cloud server 102, used to host and run specific business programs, algorithm models, or business logic modules to provide corresponding business capabilities to client 101 or other services. Business containers can also be used to provide microservices. Microservices can be service units divided according to business functions, capable of independent deployment and operation, and communicating with other services through interfaces, such as data processing services, identity authentication services, business computing services, model inference services, and file processing services. By deploying business containers in a TEE, they can achieve higher operational security and trustworthiness when processing data, core business logic, or important computing tasks.

[0033] Infrastructure services can be deployed in an untrusted execution environment. These services can provide auxiliary capabilities such as storage services, logging services, monitoring services, message queue services, configuration management services, and caching services. Infrastructure services can be implemented through containers, processes, components, or cloud service instances, and can work in conjunction with business containers in the trusted execution environment to perform operations such as data storage, runtime logging, status monitoring, message forwarding, service scheduling, and configuration retrieval. Client 101 can interact with business containers in the trusted execution environment via a communication network to obtain microservices provided by the business containers; it can also interact with infrastructure services in the untrusted execution environment to obtain storage, logging, configuration, querying, or other auxiliary services.

[0034] During the aforementioned interactions, data transmitted between client 101 and the business container, between client 101 and the infrastructure service, and between the business container and the infrastructure service can all be transmitted in encrypted form. For data that needs to be processed within the trusted execution environment, it can be decrypted and processed upon entering the trusted execution environment and encrypted before leaving, thereby reducing the risk of plaintext data being exposed in the untrusted execution environment. Furthermore, a secure data transmission link can be established between client 101, the business container in the trusted execution environment, and the infrastructure service in the untrusted execution environment.

[0035] In some scenarios, data transmission can also occur between different cloud servers. Cloud servers can establish connections through wired or wireless communication networks, dedicated networks, virtual private cloud networks, or other secure communication links to achieve cross-server data interaction and business collaboration. For example, ... Figure 1As shown, when a business container in cloud server A needs to call a microservice provided by cloud server B, cloud server A can encrypt the business request, pending data, or intermediate processing results, and send the encrypted data to cloud server B. After receiving the encrypted data, cloud server B can decrypt it and process, store, verify, forward, or analyze the decrypted data through its business container or infrastructure service to obtain the processing result. Cloud server B can also encrypt the processing result and return it to cloud server A. After receiving the processing result, cloud server A can decrypt it and continue executing subsequent business processes, or return the final result to client 101.

[0036] In other scenarios, multiple cloud servers can form a server cluster or distributed system. In this scenario, the cloud servers can transmit user request data, business processing data, status synchronization data, cached data, log data, configuration data, model parameters, database backup data, etc., to achieve functions such as load balancing, distributed computing, data synchronization, failover, service expansion, and cross-regional deployment. To ensure the security of data flow within the cluster or distributed system, the data transmitted between the cloud servers can also be protected using encryption methods, thereby reducing the risk of data theft, tampering, or forgery during cross-server transmission.

[0037] The provided encrypted communication method for cloud security protection can cover the data transmission process between client 101 and cloud server 102, between business containers and infrastructure services within cloud server 102, between trusted execution environments and untrusted execution environments, and between different cloud servers. This enables data to be transmitted in encrypted form in each transmission link and to be decrypted and processed in a protected environment or authorized entity, thereby improving the security, reliability, and trustworthiness of data transmission and business processing.

[0038] The following is combined with Figure 1 The application scenarios are described to illustrate the encrypted communication method for cloud security protection according to exemplary embodiments.

[0039] like Figure 2 As shown, an encrypted communication method for cloud security protection is provided, which may include: S1A. In the first unit, business information is stored, which indicates information for processing business data; the second unit transmits first data, which comes from the first unit and is obtained based on the business data; wherein, the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

[0040] The first unit can be a unit used to process business data. Business data can be client request data, request data sent by the first unit, intermediate data during cloud service processing, or other data that needs to be transmitted in the cloud environment.

[0041] The first data obtained based on business data can be the business data itself, or data obtained after processing the business data. There are no restrictions on the format of the first data; it can take the form of messages, data packets, streaming data, structured data, or unstructured data. The first data can also take the form of HTTP messages, remote procedure call messages, message queue messages, database access requests, or other business protocol data, without limitation.

[0042] The second unit can be a unit used to transmit first data from the first unit. The second unit includes a first encryption module. When the second unit transmits the first data, the second unit can call the first encryption module to encrypt the first data and obtain a first encryption result. The first encryption module can perform encryption operations based on preset encryption algorithms, keys, certificates, or session information, etc.

[0043] After obtaining the first encryption result, the second unit sends the first encryption result. The first encryption result can be sent to a client, cloud server, business container, protocol layer, proxy node, server, or other recipient.

[0044] The first unit is responsible for storing business information and processing business data, while the second unit is responsible for encrypting and transmitting the first data from the first unit. This makes the transmission of business data in the cloud environment more secure and facilitates the reuse of encrypted communication capabilities in different deployment scenarios.

[0045] By receiving the first data from the first unit through the second unit and encrypting the first data based on the first encryption module, the first unit does not need to be aware of the specific encryption and decryption process, thereby reducing the intrusion of encryption and decryption logic into business code and the cost of business transformation, and realizing low-intrusion or even imperceptible encrypted communication to the upper layer protocol.

[0046] In some cases, the deployment methods of the second unit and the first unit may include at least one of the following: Deployment Method A (which can be simply referred to as the client-side seamless encryption / decryption SDK mode): For example... Figure 3a As shown, the first unit and the second unit can be deployed on the first client.

[0047] Deployment method B (which can be simply referred to as local encryption / decryption proxy mode): such as Figure 3dAs shown, the second unit may include a proxy node, the first unit may be deployed on the second client and / or cloud server, the proxy node may be used to receive first data, the first data may come from the first unit, the proxy node may forward the first data, wherein forwarding the first data may include: encrypting the first data based on the first encryption module to obtain the first encryption result, and sending the first encryption result.

[0048] Deployment method C (which can be simply referred to as protocol layer-based mode): such as Figure 3b As shown, the first unit can be deployed on the first business container of the cloud server, and the second unit can be deployed at the protocol layer. The protocol layer can be used to transmit data to the first business container.

[0049] Deployment method D (which can be simply referred to as cloud-side seamless encryption / decryption SDK mode): such as Figure 3c As shown, the first unit and the second unit can be deployed on a cloud server as a second business container.

[0050] The first client and the second client can be the same client or different clients, and the first business container and the second business container can be the same business container or different business containers.

[0051] Regarding deployment method A and deployment method D: In some cases, such as Figure 4a and Figure 4b As shown, compared to related technologies, the seamless encryption / decryption SDK mode, when the client-side application or business container allows for minor access modifications, can leverage the pluggable and expandable capabilities of the communication client or transmission components in the SDK to encapsulate the encryption and decryption modules into the SDK data transmission component. Therefore, the business layer can maintain its original business call interfaces and methods without rewriting the business request logic, thus achieving seamless encryption and decryption of upper-layer business protocols.

[0052] In the seamless encryption / decryption SDK mode, the key is not to redefine a set of business call interfaces, but to reuse the communication client extension points and / or transmission component extension points already provided by the official SDK, embedding secure communication capabilities into the original transmission link. In this way, the business layer can continue to use the original SDK calling method, while security processing such as encryption, decryption, key negotiation, message encapsulation, and / or response parsing can be completed through the extended data transmission components.

[0053] In some cases, a data transmission component can be understood as a secure communication client. This secure communication client can be derived by extending the request sending and response receiving processes of the default communication client.

[0054] During the integration process, when initializing the official SDK, in addition to passing the original SDK configuration information, you can also specify this secure communication client as a new request sending component. SDK configuration information can include business access configuration information, API call configuration information, authentication configuration information, and / or communication configuration information. In this way, client-side applications or business containers can minimize the amount of modification required for business integration by using the secure communication client to push encryption and decryption capabilities down to the transport layer without changing the original business call chain.

[0055] Both deployment method A and deployment method D integrate a seamless encryption / decryption mode. The difference is that deployment method A integrates the seamless encryption / decryption mode into the client, while deployment method D integrates the seamless encryption / decryption mode into the business container in the cloud server.

[0056] Regarding deployment method B: In some cases, within the local encryption / decryption proxy mode, when the client application does not expect to modify its business code or wants to reduce the amount of business code modification, an encryption / decryption proxy component can be deployed locally. The proxy node can be located between the client application and the cloud service, and can be used to proxy network traffic sent by the client application, encrypt the first data sent to the cloud server, and decrypt the response data returned from the cloud server.

[0057] A proxy node can act as a transparent security gateway between the client application and the cloud server. The client application no longer needs to directly configure the real request address of the cloud server; instead, it can configure the access address of the local proxy node as the request entry point. The proxy node is pre-configured with the real cloud server address and forwarding rules.

[0058] In some cases, a proxy node may include an authentication module, a multi-protocol identification module, and a data encryption / decryption module: The authentication and authorization module can be used to authenticate and verify the caller's identity and permissions. It can integrate signature verification, token verification, device identity verification, and timestamp and / or random number verification mechanisms to verify the legitimacy of the caller's identity. Furthermore, the module can generate signature information when forwarding requests, enabling the receiver to verify the legitimacy of the request source based on the signature information and reducing the risk of replay attacks.

[0059] The multi-protocol identification module can be used to identify and process different types of network protocols. Communication protocols may include at least one of HTTP, Hypertext Transfer Protocol Secure (HTTPS), and Remote Procedure Call. In large model inference scenarios, the multi-protocol identification module can also identify and process Server-Sent Events (SSE) streaming protocols to adapt to communication modes such as normal requests, bidirectional calls, and streaming returns.

[0060] The data encryption / decryption module can be used to perform encryption and / or decryption processing on data transmitted via the proxy node. Specifically, the data encryption module can be used to encrypt the first data sent to the proxy node and decrypt the response data returned by the receiver.

[0061] In some cases, such as Figure 5 As shown, the sender uses the local encryption / decryption proxy address as the access point and sends the first data to the proxy node. Based on the above modules, the proxy node's transmission of the first data may include: determining the corresponding receiver address according to the multi-protocol identification module and local forwarding configuration; calling the authentication and authorization module to verify the end-side identity, access permissions, and anti-replay information such as timestamps and random numbers; calling the data encryption / decryption module to encrypt the first data according to the security policy to obtain the first encryption result; calling the authentication and authorization module to generate a signature, token, or other authentication information for the receiver; and forwarding the authentication information and the first encryption result to the configured receiver address.

[0062] In some cases, after sending the first encrypted result, the process may include: parsing the receiver's response data to obtain a response protocol; the receiver receiving the first encrypted result; restoring the session context according to the response protocol; parsing the session context to obtain the sender's address and key negotiation method; decrypting the response data according to the key negotiation method to obtain decrypted response data; and sending the decrypted response data according to the sender's address.

[0063] In the case where the application sends the first data, the receiver is the cloud server and the sender is the application address.

[0064] Response protocols can be used to characterize the protocol type used in response data, such as HTTP, Remote Procedure Call, Message Queuing, custom transport protocols, or other business communication protocols. Response protocols can carry or associate information such as session identifiers, request identifiers, link identifiers, algorithm identifiers, or key versions.

[0065] The proxy node can restore the session context according to the response protocol. The session context can be context information established when sending the first encrypted result, used to record the sender, receiver, communication link, encryption / decryption strategy, key negotiation result, or protocol encapsulation information corresponding to this data interaction. The proxy node can look up and restore the corresponding session context from the local cache or context management module based on the session identifier, request identifier, or link identifier in the response protocol.

[0066] After restoring the session context, the proxy node can parse the session context to obtain the sender's address and the encryption / decryption negotiation method. The key negotiation method can be the key negotiation process used when obtaining the first encryption result. Optionally, after restoring the session context, the authentication and authorization module of the proxy node can also verify the signature or legality of the recipient's response data.

[0067] The proxy node can decrypt the response data according to the encryption / decryption negotiation method to obtain decrypted response data. For example, the proxy node can determine the decryption key based on the key negotiation result in the session context, and use the decryption key to decrypt the ciphertext part of the response data to obtain the plaintext response content returned by the recipient. The decrypted response data may include business processing results, query results, call results, or other response content.

[0068] After receiving the decrypted response data, the proxy node can forward it to the corresponding sender based on the sender's address. The sender can then obtain the service response returned by the receiver without being aware of the encryption, protocol parsing, context recovery, and decryption processes performed on the response data during the connection.

[0069] In this way, the proxy node completes the decryption and return of response data according to the encryption / decryption negotiation method in the session context. This ensures that the encryption / decryption strategies of request data and response data in the same session are consistent, avoids the risk of plaintext exposure in the response link, and further reduces the client's awareness of the encryption / decryption process and session management details, thus achieving bidirectional transparent end-to-end encrypted communication.

[0070] In some cases, secure encrypted transmission of the first hop from the device side to the cloud side can be achieved through the device-side seamless encryption / decryption SDK mode and the local encryption / decryption proxy mode.

[0071] Regarding deployment method C: When cloud-based microservices call external microservices, storage systems, message middleware, or logging systems, they can achieve unified and transparent protocol processing through a bypass-deployed protocol layer. For example, the protocol layer could be a Sidecar component. This protocol layer can be deployed on the business container side to uniformly handle inbound and outbound communication within the business container.

[0072] like Figure 6 As shown, the protocol layer may include, in addition to a data encryption / decryption module, a protocol parsing module, a policy routing module, a key management module, a ciphertext forwarding module, and an observability module, or one or more of these.

[0073] The protocol parsing module can be located on the ingress and / or egress sides of the business container. It is used to uniformly receive requests to be sent and responses to be returned, and to perform protocol parsing on the requests and responses, so as to shield the business container from direct awareness of the underlying security processing.

[0074] The policy routing module can be used to identify the current access scenario based on metadata such as target service, protocol header, port, resource type and / or sensitivity level, and determine the encryption / decryption module to be loaded and the processing strategy based on the current access scenario.

[0075] The key management module can be used to select the corresponding session key or data key for scenarios such as cross-service transmission, data storage on disk, and message delivery, and to perform key caching and / or key rotation processing.

[0076] The data encryption / decryption module can be used to perform encryption and signature processing on request data when sending a request, and to perform signature verification and decryption processing on response data when receiving a response.

[0077] The encrypted forwarding module can be used to forward the processed request to the target system according to the original protocol semantics after completing the security processing, and maintain connection reuse, timeout control and / or retry processing in the response return path.

[0078] The observable module can be used to monitor the operational status of the protocol layer, providing anomaly detection and status awareness capabilities when anomalies occur in the protocol layer or the communication links it processes.

[0079] In some cases, the first data is obtained by encrypting the decryption source data by the first unit. Before transmitting the first data, the process may include: receiving the source data and decrypting the source data based on the first decryption module to obtain the decrypted source data.

[0080] The source data can be encrypted data from clients, proxy nodes, protocol layers, other business containers, infrastructure services, or other cloud servers. The source data is decrypted using the first decryption module to obtain the decrypted source data.

[0081] After obtaining the decrypted source data, the second unit can send the decrypted source data to the first unit, so that the first unit can perform business processing based on the decrypted source data and generate the first data.

[0082] In some cases, before the second unit transmits the first data, the process may further include: identifying the access scenario corresponding to the first data based on the metadata of the first data to obtain the target scenario; and matching the target scenario to obtain the first encryption module.

[0083] After receiving the first data, the second unit can perform protocol parsing on the first data to obtain its metadata. The metadata may include information such as the target service, protocol header, port, resource type, and sensitivity level.

[0084] Based on the metadata, the access scenario corresponding to the first data can be identified, thus obtaining the target scenario. Different access scenarios can correspond to different first encryption modules. The target scenario can be used to characterize the flow or processing purpose of the first data in the business system, such as cross-service transmission scenarios, data persistence to disk scenarios, message delivery scenarios, cache access scenarios, log writing scenarios, etc. The first encryption module or first decryption module corresponding to different target scenarios may be different.

[0085] The first unit does not require the integration of separate encryption and decryption modules for different communication links. It can match the corresponding encryption and decryption modules based on the data's metadata, enabling data from different business scenarios to adopt appropriate encryption processing methods, thereby improving the flexibility of encryption strategy configuration and unified management capabilities.

[0086] In some cases, the metadata of the first data can be the same as that of the source data. That is, after the first data is processed by the first unit, it still carries the metadata of the source data. Therefore, after receiving the first data, the second unit can continue to determine the first encryption module based on the same metadata, and use the first encryption module to encrypt the first data, and then send the first encryption result.

[0087] In this way, the second unit can complete the decryption process before the data enters the first unit, and continue to perform encryption processing based on the same metadata after the first unit outputs the first data, thus maintaining the consistency of encryption and decryption strategies in the same business chain. The first unit does not need to be aware of the specific decryption method of the source data or the specific encryption method of the first data, improving the security of data processing and transmission.

[0088] In some cases, before the second unit transmits the first data, the process may include: identifying the access scenario corresponding to the first data based on the metadata of the first data to obtain the target scenario; matching the target scenario to obtain policy information; using the policy information to determine whether the receiver has deployed a protocol layer; the receiver using the policy information to receive the first encryption result; determining the receiver as a protocol layer if the policy information indicates that the receiver has deployed a protocol layer; and determining the receiver as a business container if the policy information indicates that the receiver has not deployed a protocol layer.

[0089] When the policy information instructs the receiver to deploy the protocol layer, the second unit, after encrypting the first data based on the first encryption module to obtain the first encryption result, can send the first encryption result to the receiver's protocol layer.

[0090] If the policy information indicates that the recipient has not deployed a protocol layer, the second unit can send the first encryption result to the second unit of the recipient's business container after obtaining the first encryption result.

[0091] For example, such as Figure 7 As shown, protocol layer a can obtain policy information from the first data sent by service container a. This policy information indicates that the receiver has deployed both protocol layer b and a second unit within service container b. Based on this policy information, the protocol layer can determine that the receiver is protocol layer b.

[0092] In some cases, the encryption path can also be selected by comprehensively analyzing the deployment methods of both the initiator and the receiver: When the initiator has deployed a protocol layer, the receiver has deployed a protocol layer, or the receiver has not deployed a protocol layer but has integrated a seamless encryption / decryption SDK mode, communication prioritizes authentication, encryption, forwarding, and decryption based on the protocol layer, and the business service itself does not need to be aware of the security processing details.

[0093] When the initiator is unable to deploy the protocol layer, it can proactively integrate a seamless encryption / decryption SDK to establish a secure communication link according to the protocol and key negotiation method required by the recipient.

[0094] The aforementioned direct encryption / decryption SDK mode based on protocol layer modules or cloud-side seamless encryption / decryption is not limited to a single call, but can be extended along the call chain from 1 hop to N hops, such as... Figure 8 As shown: Each hop can continue to select the protocol layer or integrate the cloud-side seamless encryption / decryption SDK according to the receiver's access method, so as to achieve unified secure communication in complex microservice links.

[0095] In this way, the second unit can identify the target scenario based on the metadata of the first data and determine the matching policy information based on the target scenario. By determining whether the receiver has deployed a protocol layer through the policy information, the first encryption result can be received and processed first if the receiver has a protocol layer. If the receiver has not deployed a protocol layer, the data can be sent directly to the second unit in the business container. This allows for compatibility with different deployment models, reduces the transformation cost when business systems access end-to-end encryption capabilities, and improves the flexibility and adaptability of the encrypted communication scheme.

[0096] In some cases, before the second unit transmits the first data, the process may include: receiving second data from the first unit, encrypting the second data using a second encryption module to obtain encrypted second data; sending the encrypted second data to the infrastructure service; receiving a second encryption result from the infrastructure service, decrypting the second encryption result using a second decryption module to obtain a processing result; and using the processing result to determine the first data. The second unit and the first unit are deployed in a trusted execution environment, while the infrastructure service is deployed in an untrusted execution environment.

[0097] The second data can be data that the first unit needs to submit to the infrastructure service for processing before generating the first data, such as data to be written to disk, database query requests, cache access requests, log write data, or other data that needs to be processed by the infrastructure service.

[0098] The second unit can determine the second encryption module based on the metadata of the second data, and encrypt the second data based on the second encryption module to obtain encrypted second data. The second encryption module can be matched with the target scenario corresponding to the second data.

[0099] The second unit can send encrypted second data to the infrastructure service. The infrastructure service may include storage service, database service, log service, monitoring service, message queue service, or other services that support business operations. The infrastructure service can perform corresponding processing based on the encrypted second data and return a second encryption result. The second encryption result can be data obtained by the infrastructure service sequentially decrypting, processing, and encrypting the encrypted second data.

[0100] After receiving the second encrypted result from the infrastructure service, the second unit can decrypt the second encrypted result based on the second decryption module to obtain the processing result. The second decryption module can also be matched with the target scenario corresponding to the second data, that is, the second encryption module and the second decryption module can use the same encryption and decryption strategy.

[0101] The processing result can be sent to the first unit, which can then generate the first data based on the result. For example, the first unit can generate business response data based on database query results.

[0102] The second unit and the first unit can be deployed in a trusted execution environment, while the infrastructure service does not belong to this trusted execution environment. Therefore, when the first unit accesses the infrastructure service outside the trusted execution environment, the second unit can encrypt the second data before the data leaves the trusted execution environment, and decrypt the data returned by the infrastructure service after it enters the trusted execution environment, making it difficult for the infrastructure service outside the trusted execution environment to directly obtain the plaintext data.

[0103] By employing the above method, encrypted data transmission can be maintained during the process of the first unit calling external infrastructure services, reducing the risk of plaintext data being exposed to untrusted execution environments. Meanwhile, encryption and decryption are completed by the second unit, eliminating the need for the first unit to integrate separate encryption and decryption modules for different infrastructure services, thus reducing business code intrusion and maintenance costs.

[0104] In some cases, encrypting the first data based on the first encryption module to obtain the first encryption result includes: determining an encryption key according to a key negotiation method, wherein the key negotiation method is determined based on the first encryption module; and encrypting the first data based on the encryption key to obtain the first encryption result.

[0105] The key negotiation method can be used to determine the encryption key for encrypting the first data between the second unit and the receiver. The key negotiation method can include certificate-based key negotiation methods, pre-shared key-based key negotiation methods, temporary key exchange-based key negotiation methods, session context-based key derivation methods, or other methods capable of determining the encryption key; there is no limitation on this. The receiver can be a client, cloud server, business container, infrastructure service, proxy node, protocol layer, or other second unit.

[0106] After determining the encryption key, the second unit can encrypt the first data according to the encryption key to obtain the first encryption result.

[0107] In this way, the second unit can determine the encryption key based on the key negotiation method in the first encryption / decryption module before encrypting the first data, enabling different metadata to use matching key determination methods. This avoids the security risks associated with long-term reuse of fixed keys, improving the security of encrypted data transmission. Furthermore, it encapsulates the key negotiation logic within the first encryption / decryption module, reducing the first unit's awareness of key management and encryption details, and lowering the cost of business system access and maintenance.

[0108] In some cases, the method further includes: identifying the access scenario corresponding to the first data based on the metadata of the first data to obtain the target scenario; and matching based on the target scenario to determine the key negotiation method of the first encryption module.

[0109] In this scenario, the encrypted communication method for cloud security protection may include: identifying the access scenario corresponding to the first data based on the metadata of the first data to obtain the target scenario; matching the target scenario to determine the key negotiation method of the first encryption module; determining the encryption key based on the key negotiation method; encrypting the first data based on the encryption key to obtain the first encryption result; and sending the first encryption result.

[0110] In some cases, encrypted communication methods for cloud security protection may include: the first unit is created by the deployment unit based on the deployment resources and the image address; the deployment unit is used to send the deployment resources and the image address to the remote authentication service so that the remote authentication service can generate a batch verification report for the first unit based on the deployment resources, the image address and the policy file; the policy file is created by the remote authentication service based on the deployment resources.

[0111] like Figure 9 As shown, based on the same inventive concept, a verification method for cloud security protection is also provided, applied to remote verification services, and may include: S1B: Receives a deployment resource set and a mirror address set from the deployment unit. The deployment resource set and mirror address set are deployment information required by the deployment unit to deploy multiple first units. The first unit is used to store business information and send first data to the second unit. The business information indicates information for processing business data. The first data is obtained based on the business data. The second unit is used to transmit the first data.

[0112] S2B generates multiple verification reports for the first unit based on the set of deployment resources, the set of image addresses, and the set of policy files; the set of policy files is created based on the set of deployment resources.

[0113] A deployment unit can be used to deploy multiple first units within a Trusted Execution Environment (TEE), where these first units belong to the same resource type. For example, a deployment unit can serve a confidential container service located in a TEE environment. A deployment resource set and an image address set can be the deployment information required for a deployment unit to deploy multiple first units. The deployment resource set can include multiple deployment resources, which may include Deployments, StatefulSets, DaemonSets, or other information describing how the first unit is deployed. The image address set can include multiple image addresses, which may refer to network paths used to identify application templates. One image address can correspond one-to-one with a first unit. A first unit can run on multiple deployment resources, and one image address can pull multiple deployment resources, thus creating multiple identical first units. A deployment resource can run first units from different image addresses.

[0114] The policy file can be used to describe the trusted conditions that the first unit should meet, such as allowed image digests, allowed image repositories, allowed resource types, environment variables, node selection conditions, trusted execution environment types, or other verification rules.

[0115] After receiving the set of deployment resources and the set of image addresses, the remote verification service can match and verify each deployment resource and image address with the corresponding policy file to determine whether each first unit meets the preset trust conditions.

[0116] After verification is complete, the remote verification service can generate multiple verification reports for the first unit. Each verification report may include the first unit identifier, deployment resource identifier, image address, policy file identifier, and verification result. The verification result can be used to indicate whether the corresponding first unit has passed trusted verification.

[0117] In this way, the remote verification service can perform unified verification on multiple first units based on the set of deployment resources and image addresses provided by the deployment unit, and generate corresponding verification reports. Compared with configuring and executing remote verification separately for each business instance, the above method can support batch and centralized trusted verification of multiple first units, reduce the management costs caused by decentralized policy configuration, and improve verification efficiency and trusted management capabilities in large-scale cloud-native business scenarios.

[0118] like Figure 10 A sequence diagram detailing the process of batch remote verification for microservices may include: Step one: Users can submit a deployment request to the deployment unit. The deployment request is used to request the deployment of an instance. The deployment request may include resource items and image addresses.

[0119] Step two: The deployment unit can parse the installation package corresponding to the deployment instance according to the deployment request to obtain the deployment resource set.

[0120] Step 3: The deployment unit can traverse the deployment resource set and write the mapping relationship between deployment instances, resource items and image addresses into the database.

[0121] Step four: The deployment unit creates a first unit for the deployment instance and stores the service record of the first unit in the database. The service record of the first unit can be used to associate the deployment resource set corresponding to the first unit.

[0122] Step 5: The deployment unit can request the remote certification service to generate a policy file for the first unit; the policy file can be used to cover all deployment resources in the deployment resource set.

[0123] Step Six: The remote certification service can return the creation result of the policy file to the deployment unit.

[0124] Step 7: Users can initiate batch remote certification requests for deployment instances to the remote certification service.

[0125] Step 8: The remote certification service queries the deployment unit for the first unit and the set of deployment resources corresponding to the deployment instance based on the batch remote certification requests.

[0126] Step 9: The deployment unit reads from the database the set of deployment resources and the set of image addresses that are mapped to the first unit, based on the first unit. Step 10: The deployment unit can return the deployment resource set and the image address set to the remote authentication service.

[0127] Step 11: The remote verification service can traverse the deployed resources, obtain the verification report and image baseline corresponding to the deployed resources, and verify the deployed resources according to the policy file; return a batch verification report to the user; wherein, the batch verification report includes the overall verification conclusion of the first unit and the sub-verification results of the resource deployment.

[0128] In summary, the above methods provide both a seamless encryption / decryption SDK mode and a local encryption / decryption proxy mode based on the intrusion tolerance of the end-side application, enabling transparent encryption of the first-hop communication on the end-side under a unified security policy. The transparent protocol layer design, oriented towards multi-protocol and multi-cloud service scenarios, abstracts the protocol layer into a unified protocol layer capable of loading multiple types of encryption / decryption capabilities to adapt to different links such as business service calls, storage access, message middleware transmission, and log reporting.

[0129] A dual-mode seamless encrypted communication application mechanism for heterogeneous cloud communication objects: While retaining the unified and transparent processing of protocol layer design, cloud-to-cloud communication is divided into two modes based on whether the initiator has the conditions to deploy the protocol layer. First, when the initiator can support the protocol layer, the initiator uniformly completes authentication, encryption, forwarding, and packet decryption through the protocol layer, and establishes secure communication with the receiver that has deployed the protocol layer or integrated the seamless encryption / decryption SDK. Second, when the initiator cannot deploy the protocol layer, the initiator actively integrates the seamless encryption / decryption SDK and establishes a secure communication link according to the protocol and key negotiation method required by the receiver. Both modes can be further extended from the first hop to the Nth hop to realize continuous seamless encrypted communication in complex call chains.

[0130] The batch remote verification mechanism for microservice orchestration results can map the first unit to a virtual deployment unit object, generate a unified verification strategy by aggregating the image addresses of multiple sub-services, and output an aggregated report containing the verification results of each sub-service, thereby reducing the verification complexity of multi-component architecture.

[0131] By providing two access modes—a seamless encryption / decryption SDK and a local proxy—on the client side, and offering transparent protocol-layer proxy capabilities on the cloud side, the modification costs required for business systems to achieve confidential link transmission can be reduced, improving the efficiency of solution implementation. By introducing a unified mechanism for protocol-based identification, scenario-based key selection, and path-based encryption / decryption in the client-cloud and cloud-to-cloud links, transmission link security can be ensured without exposing plaintext data, and compatibility with various call paths such as microservices, storage, messaging, and logs can be maintained. By dividing cloud-to-cloud communication into two communication modes—protocol-layer based and seamless encryption / decryption SDK-based—based on whether the initiator supports the protocol layer, different initiation conditions and receiver access forms can be accommodated while retaining the core protocol layer design. This reduces the requirement for unified modification of business systems and allows seamless encrypted communication capabilities to smoothly extend from the first hop to the Nth hop, thereby improving the flexibility and security of implementation in complex cross-cloud call chains.

[0132] By aggregating multiple microservice instances into a unified remote proof object for the first unit, the number of proof strategy configurations can be significantly reduced, and the complexity of obtaining and verifying reports one by one in multi-component scenarios can be lowered.

[0133] It should be noted that the encrypted communication and verification methods used for cloud security can be executed by a single device, such as a computer or server, or they can be applied in a distributed scenario where multiple devices cooperate to complete the process. In such a distributed scenario, one of these devices may execute only one or more steps of the method, and the multiple devices will interact with each other to complete the described process.

[0134] It should be noted that the above descriptions cover some scenarios of the method. Other scenarios fall within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than those described above, and the desired result can still be achieved. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some cases, multitasking and parallel processing are possible or may be advantageous.

[0135] Based on the same inventive concept, a cloud server is also provided, corresponding to the methods in any of the above situations.

[0136] The cloud server may include: The first unit is used to store business information, which indicates information for processing business data; The second unit is used to transmit first data, which comes from the first unit and is obtained based on the business data; wherein, the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

[0137] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing a cloud server device, the functions of each module can be implemented in one or more software and / or hardware.

[0138] The apparatus described above is used to implement the corresponding encrypted communication method for cloud security protection in any of the aforementioned situations, and has the beneficial effects of the corresponding method situations, which will not be elaborated here.

[0139] Based on the same inventive concept, a client-side application is also provided, corresponding to the methods in any of the above scenarios.

[0140] The client may include: The first unit is used to store business information, which indicates information for processing business data; The second unit is used to transmit first data, which comes from the first unit and is obtained based on the business data; wherein, the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

[0141] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing the client device, the functions of each module can be implemented in one or more software and / or hardware.

[0142] The apparatus described above is used to implement the corresponding encrypted communication method for cloud security protection in any of the aforementioned situations, and has the beneficial effects of the corresponding method situations, which will not be elaborated here.

[0143] Based on the same inventive concept, a remote verification service is also provided, corresponding to the methods in any of the above situations.

[0144] Remote authentication services may include: The receiving module can be used to receive the deployment resource set and the image address set from the deployment unit. The deployment resource set and the image address set are the deployment information required by the deployment unit to deploy multiple first units. The first unit is used to store business information and send first data to the second unit. The business information indicates information for processing business data. The first data is obtained based on the business data. The second unit is used to transmit the first data.

[0145] The verification module can be used to generate multiple verification reports for the first unit based on the set of deployment resources, the set of image addresses, and the set of policy files; the set of policy files is created based on the set of deployment resources.

[0146] For ease of description, the above device is described in terms of its functions, divided into various modules. Of course, when implementing a remote authentication service device, the functions of each module can be implemented in one or more software and / or hardware.

[0147] The apparatus described above is used to implement the corresponding verification method for cloud security protection in any of the aforementioned scenarios, and has the beneficial effects of the corresponding method scenarios, which will not be elaborated here.

[0148] Based on the same inventive concept, corresponding to any of the above methods, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the encrypted communication method and verification method for cloud security protection described in any of the above scenarios.

[0149] Figure 11 A more specific hardware structure diagram of an electronic device is shown, which may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0150] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in this specification.

[0151] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other application programs. When the technical solution provided in this specification is implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0152] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0153] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0154] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0155] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the scenario described in this specification, and not necessarily all the components shown in the figures.

[0156] The electronic devices described above are used to implement the corresponding encrypted communication method and verification method for cloud security protection in any of the aforementioned scenarios, and have the beneficial effects of the corresponding method scenarios, which will not be elaborated here.

[0157] Based on the same inventive concept, corresponding to any of the above methods, a non-transitory computer-readable storage medium is also provided, wherein the non-transitory computer-readable storage medium stores computer instructions, the computer instructions being used to cause the computer to execute the encrypted communication method and verification method for cloud security protection as described in any of the above scenarios.

[0158] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0159] The computer instructions stored in the storage medium described above are used to cause the computer to execute the encrypted communication method and verification method for cloud security protection as described in any of the above scenarios, and have the beneficial effects of the corresponding method scenarios, which will not be elaborated here.

[0160] Those skilled in the art should understand that the discussion of any of the above situations is merely exemplary and is not intended to imply that the scope (including the claims) is limited to these examples; the technical features in the various situations or different situations above can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the above situations, which are not provided in the details for the sake of brevity.

[0161] Furthermore, to simplify the description and discussion, and to avoid obscuring the above-described circumstances, the well-known power / ground connections to the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. Additionally, the apparatus may be shown in block diagram form to avoid obscuring the above-described circumstances, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the above-described circumstances will be implemented (i.e., these details should be entirely within the understanding of those skilled in the art). Where specific details (e.g., circuitry) are set forth to describe exemplary embodiments, it will be apparent to those skilled in the art that implementation may be carried out without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0162] Although several scenarios have been described, many substitutions, modifications, and variations of these scenarios will be apparent to those skilled in the art based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the scenarios discussed.

[0163] This is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the foregoing should be included within the scope of protection of this situation.

Claims

1. An encrypted communication method for cloud security protection, comprising: The first unit stores business information, which indicates information for processing business data; The second unit transmits first data, which comes from the first unit and is obtained based on the service data. The second unit includes a first encryption module, and the transmission of the first data includes: The first data is encrypted using the first encryption module to obtain a first encryption result; Send the first encrypted result.

2. The method of claim 1, further comprising at least one of the following: The first unit and the second unit are deployed on the first client; or, The first unit is deployed in a first service container on a cloud server, and the second unit is deployed at the protocol layer, which is used to transmit data from the first service container; or... The first unit and the second unit are deployed in a second service container on a cloud server; or, The second unit includes a proxy node. The first unit is deployed on a second client and / or a cloud server. The proxy node is used to receive first data, which originates from the first unit. The proxy node forwards the first data. The forwarding of the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result, and sending the first encryption result.

3. The method according to claim 1, wherein the first data is obtained by the first unit encrypting the decryption source data, and the method further includes: Receive source data, and decrypt the source data based on the first decryption module to obtain the decrypted source data.

4. The method according to claim 1, further comprising, before the second unit transmits the first data: Based on the metadata of the first data, the access scenario corresponding to the first data is identified to obtain the target scenario; The first encryption module is obtained by matching the target scenario.

5. The method according to claim 1, further comprising, before the second unit transmits the first data: Based on the metadata of the first data, the access scenario corresponding to the first data is identified to obtain the target scenario; Based on the target scenario, matching is performed to obtain strategy information; The policy information is used to determine whether the receiver deploys a protocol layer; the receiver is used to receive the first encryption result. If the policy information instructs the receiver to deploy a protocol layer, the receiver is identified as a protocol layer. If the policy information indicates that the receiver has not deployed a protocol layer, the receiver is determined to be a service container.

6. The method according to claim 1, further comprising, before the second unit transmits the first data: Receive second data from the first unit, encrypt the second data based on the second encryption module, and obtain encrypted second data; Send the encrypted second data to the infrastructure service; The system receives a second encryption result from the infrastructure service, decrypts the second encryption result based on the second decryption module, and obtains a processing result; the processing result is used to determine the first data. The second unit and the first unit are deployed in a trusted execution environment; The infrastructure services are deployed in an untrusted execution environment.

7. The method according to claim 1, wherein encrypting the first data based on the first encryption module to obtain a first encryption result includes: Determine the encryption key according to the key negotiation method; The key negotiation method is determined based on the first encryption module; The first data is encrypted using the encryption key to obtain a first encryption result.

8. The method according to claim 2, wherein the second unit includes a proxy node and the first unit is deployed on a second client and / or a cloud server, after sending the first encryption result, the method further includes: The response data from the receiver is parsed to obtain the response protocol; The receiver is used to receive the first encryption result; The session context is restored according to the response protocol. Parse the session context to obtain the sender's address and key negotiation method; The response data is decrypted according to the key negotiation method to obtain decrypted response data; The decryption response data is sent according to the sender address.

9. The method according to claim 1, further comprising: The first unit is created by the deployment unit based on the deployment resources and image address; The deployment unit is used to send the deployment resources and the mirror address to the remote verification service, so that the remote verification service can generate a verification report of the first unit based on the deployment resources, the mirror address and the policy file; The policy file is created by the remote authentication service based on the deployment resources.

10. A verification method for cloud security protection, applied to remote authentication services, comprising: The system receives a deployment resource set and a mirror address set from a deployment unit. The deployment resource set and the mirror address set are deployment information required by the deployment unit to deploy multiple first units. The first unit is used to store business information and send first data to the second unit. The business information indicates information for processing business data, and the first data is obtained based on the business data. The second unit is used to transmit the first data. Verification reports for the plurality of first units are generated based on the deployment resource set, the image address set, and the policy file set; the policy file set is created based on the deployment resource set.

11. A cloud server, comprising: The first unit is used to store business information, which indicates information for processing business data; The second unit is used to transmit first data, which comes from the first unit and is obtained based on the business data; wherein, the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

12. A client, comprising: The first unit is used to store business information, which indicates information for processing business data; The second unit is used to transmit first data, which comes from the first unit and is obtained based on the business data; wherein, the second unit includes a first encryption module, and transmitting the first data includes: encrypting the first data based on the first encryption module to obtain a first encryption result; and sending the first encryption result.

13. A remote authentication service, comprising: A receiving module is configured to receive a deployment resource set and a mirror address set from a deployment unit, wherein the deployment resource set and the mirror address set are deployment information required by the deployment unit to deploy multiple first units; the first unit is configured to store business information and send first data to a second unit; the business information indicates information for processing business data, and the first data is obtained based on the business data; the second unit is configured to transmit the first data. The verification module is used to generate verification reports for the plurality of first units based on the deployment resource set, the image address set, and the policy file set; the policy file set is created based on the deployment resource set.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 10.

15. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 10.

Images