Hardware-trust-based dynamic access control method and system for cloud server cluster

Abstract

The application discloses a cloud server cluster dynamic access control method and system based on hardware trust, relates to the technical field of cloud computing security, and comprises the following steps: a management and control center is established corresponding to a cloud server cluster, and a trusted cluster pool is established based on the management and control center; the cloud server cluster is monitored in real time based on the management and control center, and each cloud server of the cloud server cluster and the trusted cluster pool is dynamically adjusted based on the monitoring result; a cluster gateway is established, when an access request from outside reaches the cluster gateway, the cluster gateway accesses the access request to a target cloud server in the trusted cluster pool, and the target cloud server processes the access request. The application can ensure that the access request is always scheduled to a trusted and load-healthy cloud server for operation, and can also trigger a subsequent migration process when the target cloud server is maliciously attacked during operation, thereby ensuring the continuity and security of the access request operation.

Description

Technical Field

[0001] This invention relates to the field of cloud computing security technology, specifically to a dynamic access control method and system for cloud server clusters based on hardware trust. Background Technology

[0002] With the rapid development of cloud computing technology, cloud server clusters are widely used in various business systems, with a large number of business access requests running on various cloud servers within the cluster. Most existing cloud cluster access control solutions implement access permission management at the software level, relying on software certificates and access control lists to complete scheduling and authorization.

[0003] Software-level trust mechanisms are vulnerable to operating system vulnerabilities and malicious intrusions. Once a cloud server is maliciously compromised, the trust credentials and access policies at the software level can be tampered with or bypassed, compromising the trustworthiness of the cloud server nodes themselves. Some solutions introduce TPM hardware trust roots, but most only achieve simple trusted node access and lack comprehensive dynamic closed-loop management mechanisms.

[0004] The existing technology has the following shortcomings when applied: 1. It is inconvenient to dynamically adjust the cluster's trusted node pool based on the real-time hardware trust status during cloud server operation, and the compromised cloud server may still accept business access requests. 2. External access request scheduling lacks joint judgment of trusted status and load status, which can easily lead to the scheduling of business to untrusted or overloaded cloud servers. 3. When the cloud server carrying the business is maliciously compromised, access requests and related runtime files are easily stolen or tampered with during the migration and transmission process. Furthermore, if an intermediate node is compromised during the migration, the migration process will fail directly, making it difficult to balance the security protection of the cloud server cluster with the continuity of business operations. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for dynamic access control of cloud server clusters based on hardware trust, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a dynamic access control method for cloud server clusters based on hardware trust, comprising the following steps: Establish a management and control center for the corresponding cloud server cluster, and build a trusted cluster pool based on the management and control center; The control center performs real-time monitoring of the cloud server cluster and dynamically adjusts each cloud server in the cloud server cluster and trusted cluster pool based on the monitoring results. Establish a cluster gateway. When an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server in the trusted cluster pool, and the target cloud server will process the access request. If a malicious attack is detected on the target cloud server while the access request is running on the target cloud server, the relevant running files and running status data corresponding to the access request will be isolated. After the isolation is completed, a migration channel will be established between the target cloud server and the migration target cloud server. Based on the migration channel, the relevant running files and running status data corresponding to the access request will be migrated to the migration target cloud server.

[0007] In a preferred embodiment, the steps of establishing a management and control center for the corresponding cloud server cluster and establishing a trusted cluster pool based on the management and control center include: Establish a management and control center for the corresponding cloud server cluster, and bind a unique number to each cloud server in the cloud server cluster; By using hardware roots of trust deployed on each cloud server to obtain the metrics of each cloud server in the cloud server cluster in real time, cloud servers whose metrics meet the preset trust standards are added to the trusted cluster pool.

[0008] In a preferred embodiment, the step of real-time monitoring of the cloud server cluster based on the control center, and dynamic adjustment of each cloud server in the cloud server cluster and trusted cluster pool based on the monitoring results, includes: The monitoring results are obtained by acquiring the measurement values ​​of each cloud server in the cloud server cluster and trusted cluster pool from the control center and comparing the measurement values ​​of each cloud server with the preset trusted standards. Based on the monitoring results, when the metric value of a cloud server in the trusted cluster pool deviates from the preset trusted standard, it is removed from the trusted cluster pool; when the metric value of a cloud server that previously did not meet the preset trusted standard meets the preset trusted standard, it is added back to the trusted cluster pool.

[0009] In a preferred embodiment, the establishment of a cluster gateway involves the following steps: when an external access request arrives at the cluster gateway, the cluster gateway connects the access request to the target cloud server within the trusted cluster pool, and the target cloud server processes the access request. Establish a cluster gateway for the corresponding cloud server cluster and trusted cluster pool. The cluster gateway is used to receive access requests from the outside world. When an external access request arrives at the cluster gateway, the cluster gateway parses the access request, determines the corresponding target cloud server based on the target service identifier carried in the access request, and determines the metric value and load status of the target cloud server. If the target cloud server is located in the trusted cluster pool and its load status meets the requirements, the access request will be scheduled to the target cloud server. If the target cloud server is not in the trusted cluster pool or its load status does not meet the requirements, the access request will be scheduled to other cloud servers in the trusted cluster pool that meet the requirements as the target cloud server. Access requests are processed based on the target cloud server they are accessing until completion, or a migration process is triggered when the target cloud server is detected to have been maliciously compromised.

[0010] In a preferred embodiment, if a malicious attack on the target cloud server is detected while the access request is running on the target cloud server, the relevant running files and running status data corresponding to the access request are isolated. After isolation, a migration channel is established between the target cloud server and the migration target cloud server. The step of migrating the relevant running files and running status data corresponding to the access request to the migration target cloud server based on the migration channel includes: During the execution of the access request on the target cloud server, the control center monitors the target cloud server's metrics in real time through the hardware root of trust deployed on the target cloud server. When the target cloud server's metrics deviate from the preset trust standard, it is determined that the target cloud server has been maliciously attacked. The control center sends a pause scheduling command to the cluster gateway, causing the cluster gateway to stop scheduling new access requests to the target cloud server. The control center locates maliciously compromised files on the target cloud server based on file-level integrity monitoring, isolates the maliciously compromised files at the file level, suspends the processes corresponding to the access requests currently running on the target cloud server, saves the relevant running files and running status data of the access requests, and packages the relevant running files and running status data of the access requests into a migration data package. The relevant running files are clean versions of the maliciously compromised files obtained from the trusted file library maintained by the control center. The control center selects cloud servers from the trusted cluster pool that provide the same services as the target cloud server, whose metrics meet the preset trusted standards, and whose load status meets the standards as candidate cloud servers for migration. Then, it selects one of the candidate cloud servers as the target cloud server for migration according to the minimum load priority strategy. The control center establishes a migration channel between the target cloud server and the migration target cloud server, sends the data packets to be migrated to the migration target cloud server through the migration channel, loads the data packets to be migrated in the migration target cloud server and resumes operation in the migration target cloud server, and disconnects the migration channel between the target cloud server and the migration target cloud server after the control center confirms that the migration is completed.

[0011] In a preferred embodiment, the step of establishing a migration channel between the control center and the target cloud server to be migrated, and sending the data packet to be migrated to the target cloud server through the migration channel, includes: Obtain the metric values ​​of each cloud server in the cloud server cluster, and map each cloud server in the cloud server cluster to a preset virtual image layer constructed based on the physical and logical topology relationship of each cloud server to obtain multiple image nodes. Using the target cloud server as the sending node and the target cloud server to be migrated as the receiving node, the cloud servers corresponding to other image nodes in the virtual image layer that are physically reachable and logically connected on the jump path between the sending node and the receiving node, and whose metric values ​​meet the preset trust standards, are identified as intermediate nodes. A migration channel is established based on the sending node, multiple intermediate nodes, and the receiving node. An escape packet is configured for the data packets to be migrated. The escape packet includes an outer container, an inner container, and a backup container. The inner container is used to carry the data packets to be migrated, the outer container is used to interface with the intermediate node to which the data packets are to be migrated, and the backup container is used to replace the outer container in connecting to the next intermediate node after the inner container and the outer container are disconnected. The sending node transmits the data packet to be migrated based on the migration channel. The data packet to be migrated is redirected based on the metric values ​​of each mirror node in the virtual image layer until it is redirected to the target cloud server.

[0012] In a preferred embodiment, the step of redirecting the data packet to be migrated based on the metric values ​​of each mirror node within the virtual mirror layer until it is redirected to the target cloud server includes: When the metric values ​​of two adjacent mirror nodes in the virtual mirror layer reach the preset trust standard, a jump path is established between them. If the metric value deviates from the preset trust standard, no jump path is established between adjacent mirror nodes. A real-time topology graph is constructed based on multiple jump paths in the virtual mirror layer. Mirror nodes are connected to corresponding intermediate nodes, and intermediate nodes synchronously perceive whether there is a jump path between them and adjacent mirror nodes based on the corresponding mirror nodes. The data packet to be migrated jumps along the jump path corresponding to the shortest topological distance between the sending node and the receiving node until it reaches the target cloud server. When the data packet to be migrated jumps to an intermediate node, it connects with the intermediate node through the outer container of the escape packet. The inner container carries the data packet to be migrated. When the metric value of the mirror node corresponding to the intermediate node deviates from the preset trust standard and it is determined that the intermediate node has been maliciously compromised, the outer container does not disconnect from the intermediate node, the inner container disconnects from the outer container, and the inner container, carrying the data packet to be migrated and the backup container, jumps to the next intermediate node based on the real-time topology map. The backup container reconnects with the next intermediate node until it reaches the target cloud server.

[0013] This invention also provides a hardware-trust-based dynamic access control system for cloud server clusters, including: The module is used to establish a control center for the corresponding cloud server cluster and to establish a trusted cluster pool based on the control center. The monitoring and adjustment module is used to monitor the cloud server cluster in real time based on the control center, and to dynamically adjust each cloud server in the cloud server cluster and the trusted cluster pool based on the monitoring results. The access module is used to establish a cluster gateway. When an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server in the trusted cluster pool, and the target cloud server will process the access request. The data migration module is used to isolate the relevant running files and running status data corresponding to the access request if the target cloud server is detected to be maliciously compromised while the access request is running on the target cloud server. After the isolation is completed, a migration channel is established between the target cloud server and the migration target cloud server. Based on the migration channel, the relevant running files and running status data corresponding to the access request are migrated to the migration target cloud server.

[0014] The technical effects and advantages provided by the present invention in the above technical solution are as follows: This invention generates a metric value through the hardware trust root of each cloud server as the basis for trust judgment, and establishes a trusted cluster pool. It can guarantee the basic trust capability of the cluster business carrying nodes from the hardware level. Through the dynamic adjustment of each cloud server in the trusted cluster pool, it can ensure that only the currently trusted cloud server can accept the access request, realize the dynamism and security of cluster access control, and also ensure that the access request is always scheduled to a trusted and resource-sufficient node. 2. This invention, upon determining that the target cloud server has been compromised, first suspends the business process and saves the running state. It then isolates the compromised files at the file level and uses clean versions of files from a trusted file library to package and generate a data packet to be migrated. This prevents malicious code from spreading to the target cloud server during migration, ensuring the security of the migration data itself. Based on the physical and logical topology of each node, a virtual mirror layer and a real-time topology graph are constructed. Jump paths are only established between mirror nodes that meet the metric standards, ensuring that the data packet to be migrated only jumps between trusted nodes, avoiding the risk of theft and tampering caused by the data packet passing through untrusted intermediate nodes. Through the coordinated operation of the outer, inner, and backup storage units of the escape packet, when an intermediate node is compromised during migration, the inner storage unit carries the data packet to be migrated away from the risky node and relies on the backup storage unit to reconnect with the next intermediate node; the outer storage unit continues to maintain the connection with the compromised node to confuse the attacker, so the migration will not be interrupted due to the compromise of the intermediate node, thus improving the attack resistance and transmission continuity of the migration process; the target cloud server for migration is selected according to the minimum load priority strategy to ensure that the business has sufficient operating resources after migration; after the migration is completed, the target server resumes operation and cuts off the migration channel to take over the abnormal business and ensure that access requests are not interrupted. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0016] Figure 1 This is a flowchart of the method of the present invention.

[0017] Figure 2 This is a system block diagram of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1, please refer to Figure 1 As shown in this embodiment, the dynamic access control method for cloud server clusters based on hardware trust includes the following steps: Establish a management and control center for the corresponding cloud server cluster, and build a trusted cluster pool based on the management and control center; The control center performs real-time monitoring of the cloud server cluster and dynamically adjusts each cloud server in the cloud server cluster and trusted cluster pool based on the monitoring results. Establish a cluster gateway. When an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server in the trusted cluster pool, and the target cloud server will process the access request. If a malicious attack is detected on the target cloud server while the access request is running on the target cloud server, the relevant running files and running status data corresponding to the access request will be isolated. After the isolation is completed, a migration channel will be established between the target cloud server and the migration target cloud server. Based on the migration channel, the relevant running files and running status data corresponding to the access request will be migrated to the migration target cloud server.

[0020] In one embodiment, the steps of establishing a management and control center for the corresponding cloud server cluster and establishing a trusted cluster pool based on the management and control center include: Establish a management and control center for the corresponding cloud server cluster, and bind a unique number to each cloud server in the cloud server cluster; By using hardware roots of trust deployed on each cloud server to obtain the metrics of each cloud server in the cloud server cluster in real time, cloud servers whose metrics meet the preset trust standards are added to the trusted cluster pool.

[0021] It should be noted that the control center is deployed on one or more management nodes in the cloud server cluster, serving as the control plane for trusted management and dynamic decision-making within the cluster. Each cloud server in the cluster is assigned a unique number (e.g., a globally unique identifier, or an identifier composed of a serial number and address), and this unique number is bound to the corresponding cloud server and registered with the control center for subsequent node location, path calculation, and migration target determination. Each cloud server has a built-in hardware root of trust (e.g., a TPM / TCM trusted chip), which stores non-exportable platform identity keys and endorsement keys. The control center obtains the metrics of each cloud server in real time. These metrics characterize the integrity status of the corresponding cloud server platform, such as the integrity metric digest (PCR value) corresponding to firmware, bootloader, operating system kernel, and critical configurations. A preset trust standard can be a preset trust threshold. When the metric matches the trust threshold, the corresponding cloud server is deemed trustworthy and added to the trusted cluster pool. Furthermore, through trusted metrics based on the hardware root of trust, it is ensured from the source that all cloud servers entering the trusted cluster pool are hardware-trusted nodes, providing a trust foundation for subsequent dynamic access control within the cluster.

[0022] In one embodiment, the step of real-time monitoring of the cloud server cluster by the management and control center, and dynamic adjustment of each cloud server in the cloud server cluster and trusted cluster pool based on the monitoring results, includes: The monitoring results are obtained by acquiring the measurement values ​​of each cloud server in the cloud server cluster and trusted cluster pool from the control center and comparing the measurement values ​​of each cloud server with the preset trusted standards. Based on the monitoring results, when the metric value of a cloud server in the trusted cluster pool deviates from the preset trusted standard, it is removed from the trusted cluster pool; when the metric value of a cloud server that previously did not meet the preset trusted standard meets the preset trusted standard, it is added back to the trusted cluster pool.

[0023] It should be noted that the control center can periodically (e.g., every preset monitoring cycle or preset monitoring duration) obtain metric values ​​through the hardware trust root of each cloud server and compare the obtained metric values ​​with preset trust standards: when the metric value is consistent with the preset trust standard, the monitoring result indicates that the corresponding cloud server is trustworthy; when the metric value deviates from the preset trust standard, the monitoring result indicates that the corresponding cloud server is untrustworthy; when the metric value of a cloud server in the trusted cluster pool deviates from the preset trust standard, the control center removes the cloud server from the trusted cluster pool and simultaneously revokes its cluster access credentials and restricts its external interaction to prevent untrustworthy nodes (cloud servers that do not meet the preset trust standard) from continuing to carry access requests; when the metric value of a cloud server that previously did not meet the preset trust standard (i.e., was previously removed) recovers to the preset trust standard, the control center re-verifies its trust, and after the verification is passed, it is re-added to the trusted cluster pool to restore its qualification to accept access requests; thus, through the above dynamic adjustment, the members in the trusted cluster pool are dynamically updated with the real-time trust status of each cloud server, ensuring that only the currently trusted cloud server can accept access requests, realizing the dynamism and security of cluster access control.

[0024] In one embodiment, the establishment of a cluster gateway involves the following steps: when an external access request arrives at the cluster gateway, the cluster gateway connects the access request to the target cloud server within the trusted cluster pool, and the target cloud server processes the access request. Establish a cluster gateway for the corresponding cloud server cluster and trusted cluster pool. The cluster gateway is used to receive access requests from the outside world. When an external access request arrives at the cluster gateway, the cluster gateway parses the access request, determines the corresponding target cloud server based on the target service identifier carried in the access request, and determines the metric value and load status of the target cloud server. If the target cloud server is located in the trusted cluster pool and its load status meets the requirements, the access request will be scheduled to the target cloud server. If the target cloud server is not in the trusted cluster pool or its load status does not meet the requirements, the access request will be scheduled to other cloud servers in the trusted cluster pool that meet the requirements as the target cloud server. Access requests are processed based on the target cloud server they are accessing until completion, or a migration process is triggered when the target cloud server is detected to have been maliciously compromised.

[0025] It should be noted that the cluster gateway can be deployed at the entry point of the cloud server cluster, serving as a unified entry point and scheduling node for external access requests entering the cluster. When an external access request arrives at the cluster gateway, the gateway parses the target service identifier (such as the Uniform Resource Identifier or service name of the target service) carried in the access request, and determines the target cloud server corresponding to the access request based on the mapping relationship between the target service identifier and cloud servers. The cluster gateway further queries the management and control center for the metric values ​​and load status of the target cloud server, where the load status represents the resource utilization of the target cloud server (e.g., CPU). The load status is considered acceptable if the corresponding resource utilization is below a preset load threshold (e.g., utilization rate, memory usage rate, bandwidth usage rate, etc.). If the target cloud server is located in a trusted cluster pool and its load status is acceptable, the access request is scheduled to that target cloud server, which is then used to process the access request. If the target cloud server is not in the trusted cluster pool (i.e., currently untrusted) or its load status is unacceptable, another cloud server providing the same service and with an acceptable load status is selected from the trusted cluster pool as the target cloud server, thus ensuring that the access request is always scheduled to run on a trusted and healthy cloud server. The access request is processed based on the target cloud server until processing is complete, or if the target cloud server is detected to be maliciously compromised during operation, the subsequent migration process is triggered to ensure the continuity and security of the access request operation.

[0026] In one embodiment, if a malicious attack on the target cloud server is detected while the access request is running on the target cloud server, the relevant running files and running status data corresponding to the access request are isolated. After isolation is completed, a migration channel is established between the target cloud server and the migration target cloud server. The step of migrating the relevant running files and running status data corresponding to the access request to the migration target cloud server based on the migration channel includes: During the execution of the access request on the target cloud server, the control center monitors the target cloud server's metrics in real time through the hardware root of trust deployed on the target cloud server. When the target cloud server's metrics deviate from the preset trust standard, it is determined that the target cloud server has been maliciously attacked. The control center sends a pause scheduling command to the cluster gateway, causing the cluster gateway to stop scheduling new access requests to the target cloud server. The control center locates maliciously compromised files on the target cloud server based on file-level integrity monitoring, isolates the maliciously compromised files at the file level, suspends the processes corresponding to the access requests currently running on the target cloud server, saves the relevant running files and running status data of the access requests, and packages the relevant running files and running status data of the access requests into a migration data package. The relevant running files are clean versions of the maliciously compromised files obtained from the trusted file library maintained by the control center. The control center selects cloud servers from the trusted cluster pool that provide the same services as the target cloud server, whose metrics meet the preset trusted standards, and whose load status meets the standards as candidate cloud servers for migration. Then, it selects one of the candidate cloud servers as the target cloud server for migration according to the minimum load priority strategy. The control center establishes a migration channel between the target cloud server and the migration target cloud server, sends the data packets to be migrated to the migration target cloud server through the migration channel, loads the data packets to be migrated in the migration target cloud server and resumes operation in the migration target cloud server, and disconnects the migration channel between the target cloud server and the migration target cloud server after the control center confirms that the migration is completed.

[0027] In one embodiment, the step of establishing a migration channel between the control center and the target cloud server to be migrated, and sending the data packet to be migrated to the target cloud server through the migration channel, includes: Obtain the metric values ​​of each cloud server in the cloud server cluster, and map each cloud server in the cloud server cluster to a preset virtual image layer constructed based on the physical and logical topology relationship of each cloud server to obtain multiple image nodes. Using the target cloud server as the sending node and the target cloud server to be migrated as the receiving node, the cloud servers corresponding to other image nodes in the virtual image layer that are physically reachable and logically connected on the jump path between the sending node and the receiving node, and whose metric values ​​meet the preset trust standards, are identified as intermediate nodes. A migration channel is established based on the sending node, multiple intermediate nodes, and the receiving node. An escape packet is configured for the data packets to be migrated. The escape packet includes an outer container, an inner container, and a backup container. The inner container is used to carry the data packets to be migrated, the outer container is used to interface with the intermediate node to which the data packets are to be migrated, and the backup container is used to replace the outer container in connecting to the next intermediate node after the inner container and the outer container are disconnected. The sending node transmits the data packet to be migrated based on the migration channel. The data packet to be migrated is redirected based on the metric values ​​of each mirror node in the virtual image layer until it is redirected to the target cloud server.

[0028] In one embodiment, the step of redirecting the data packet to be migrated based on the metric values ​​of each mirror node within the virtual mirror layer until it is redirected to the target cloud server includes: When the metric values ​​of two adjacent mirror nodes in the virtual mirror layer reach the preset trust standard, a jump path is established between them. If the metric value deviates from the preset trust standard, no jump path is established between adjacent mirror nodes. A real-time topology graph is constructed based on multiple jump paths in the virtual mirror layer. Mirror nodes are connected to corresponding intermediate nodes, and intermediate nodes synchronously perceive whether there is a jump path between them and adjacent mirror nodes based on the corresponding mirror nodes. The data packet to be migrated jumps along the jump path corresponding to the shortest topological distance between the sending node and the receiving node until it reaches the target cloud server. When the data packet to be migrated jumps to an intermediate node, it connects with the intermediate node through the outer container of the escape packet. The inner container carries the data packet to be migrated. When the metric value of the mirror node corresponding to the intermediate node deviates from the preset trust standard and it is determined that the intermediate node has been maliciously compromised, the outer container does not disconnect from the intermediate node, the inner container disconnects from the outer container, and the inner container, carrying the data packet to be migrated and the backup container, jumps to the next intermediate node based on the real-time topology map. The backup container reconnects with the next intermediate node until it reaches the target cloud server.

[0029] It should be noted that while the access request is running on the target cloud server, the control center continuously monitors its metrics in real time through the hardware root of trust of the target cloud server. For example, when the metric of the target cloud server is inconsistent with the preset trust standard, it is determined that the target cloud server has been maliciously compromised (such as firmware tampering or kernel injection of malicious code). The control center then sends a pause scheduling command to the cluster gateway, causing the cluster gateway to stop scheduling new access requests to the target cloud server and prevent more access requests from entering the compromised node. The control center uses file-level integrity monitoring (e.g., maintaining hash values ​​for critical files and periodically verifying and comparing them) to locate maliciously compromised files on the target cloud server. It then implements file-level isolation for these files, prohibiting them from being read, written, or executed through file system access control policies. Simultaneously, it suspends the processes corresponding to the access requests currently running on the target cloud server, saving the context information and runtime status data of the access requests (e.g., process status, memory snapshots, session information), and packages this information into a migration data package. Since the maliciously compromised files may be contaminated, a clean version of the compromised file is retrieved from the trusted file library maintained by the control center and included in the migration data package. This prevents the infected file from being carried over to the target cloud server during migration, ensuring the migration data package is clean and usable. The control center selects cloud servers from the trusted cluster pool that provide the same services as the target cloud server, whose metrics meet the preset trust standards, and whose load status meets the standards as candidate migration cloud servers. Then, according to the minimum load priority strategy (e.g., selecting the candidate migration cloud server with the lowest current resource utilization), it selects one of the candidate migration cloud servers as the migration target cloud server, thereby ensuring that the migration target cloud server is both trustworthy and capable of undertaking business. The control center obtains the measurement values ​​of each cloud server in the cloud server cluster and maps each cloud server in the cluster to a preset virtual image layer constructed based on the physical and logical topology relationships of each cloud server, resulting in multiple image nodes. For example, cloud servers S1, S2, S3, and S4 are mapped to image nodes M1, M2, M3, and M4, respectively. With the target cloud server as the sending node and the migration target cloud server as the receiving node, the cloud servers corresponding to other image nodes in the virtual image layer that are physically reachable and logically connected on the jump path between the sending node and the receiving node, and whose measurement values ​​meet the preset trust criteria, are identified as intermediate nodes. A migration channel is established based on the sending node, multiple intermediate nodes, and the receiving node, thereby avoiding migration data passing through untrusted or irrelevant nodes and reducing the contact surface of the migration process.

[0030] An escape packet is configured for the data packets to be migrated. The escape packet includes an outer container, an inner container, and a backup container. The inner container carries the data packets to be migrated, the outer container interfaces with the intermediate nodes it reaches, and the backup container replaces the outer container in connecting to the next intermediate node after the inner and outer containers disconnect. The escape packet, as the carrier of the data packets to be migrated, protects the data packets during the jump process and performs controlled interfaces with each intermediate node. When the metric values ​​of two adjacent mirror nodes in the virtual mirror layer reach a preset trust standard, a jump path is established between them. If the metric value deviates from the preset trust standard, no jump path is established between adjacent mirror nodes. A real-time topology graph is constructed based on multiple jump paths in the virtual mirror layer. Mirror nodes are connected to their corresponding intermediate nodes, and intermediate nodes synchronously perceive whether a jump path exists between themselves and their adjacent mirror nodes based on the corresponding mirror node. Furthermore, the jump paths in the real-time topology graph dynamically change with the metric values ​​of each mirror node; only adjacent nodes with metric values ​​meeting the standard have a jumpable path. The data packet to be migrated hops along the shortest topological distance between the sending and receiving nodes until it reaches the target cloud server. When the data packet reaches an intermediate node, it connects with that intermediate node via the outer container of the escape packet, while the inner container carries the data packet. If the metric of the mirror node corresponding to that intermediate node deviates from the preset trust standard, indicating that the intermediate node has been maliciously compromised, the outer container does not disconnect from the intermediate node (e.g., the outer container maintains a connection with the original intermediate node to mislead the attacker), the inner container disconnects from the outer container, and the inner container, carrying the data packet to be migrated and a backup container, hops to the next intermediate node based on the real-time topology map. The backup container reconnects with the next intermediate node until it reaches the target cloud server. After the data packet to be migrated is sent to the target cloud server via the migration channel, it is loaded and resumes operation on the target cloud server. After the control center confirms the migration is complete, the migration channel between the target cloud server and the target cloud server is disconnected, completing the migration of the access request.

[0031] Furthermore, once the target cloud server is determined to be compromised, the business processes are suspended and the running state is saved. The compromised files are isolated at the file level, and clean versions of the files from a trusted file library are used to package and generate a data package to be migrated. This prevents malicious code from spreading to the target cloud server during the migration, ensuring the security of the migration data itself. A virtual mirror layer and a real-time topology map are constructed based on the physical and logical topology of each node. Jump paths are only established between mirror nodes that meet the measurement standards. The data package to be migrated only jumps between trusted nodes (cloud servers that meet the preset trust standards), avoiding theft caused by the migration data package passing through untrusted intermediate nodes. To mitigate the risk of data tampering, the system utilizes a coordinated approach involving an outer, inner, and backup repository to escape the data packet. If an intermediate node is compromised during migration, the inner repository carries the data packet to be migrated away from the compromised node and reconnects with the next intermediate node via the backup repository. The outer repository maintains its connection with the compromised node to confuse attackers, ensuring the migration is not interrupted by the compromise of intermediate nodes and enhancing the attack resistance and transmission continuity of the migration process. A minimum load priority strategy is used to select the target cloud server for migration, ensuring sufficient operational resources for the business after migration. After migration, the system resumes operation on the target server and disconnects the migration channel, taking over abnormal business operations and ensuring uninterrupted access requests. It should also be noted that the process of determining the shortest topology path is as follows: Based on the real-time topology map, the control center uses a breadth-first search (BFS) algorithm to traverse all available jump paths, starting from the sending node and ending at the receiving node; it counts the number of mirror nodes traversed by each path and determines the path with the fewest nodes as the shortest topology path; if multiple shortest paths with the same number of nodes exist, one of them is randomly selected as the path used for this migration; the calculation process of the metric is as follows: the metric is generated by the cloud server's built-in hardware root of trust (TPM): during server startup and operation, the hardware root of trust performs hash calculations on the BIOS, firmware, kernel, and critical system configurations in sequence, and iteratively stores the hash result of each step into the PCR register of the TPM. The final output value of the PCR register is the metric of the cloud server; the trust standard is the baseline PCR value (baseline metric) of the server under normal conditions collected in advance. If the real-time metric is completely consistent with the pre-stored baseline metric, it is determined that the preset trust standard has been met; if the real-time metric is not equal to the baseline metric, it is determined that there is a deviation. The process of obtaining cloud server load is as follows: Each cloud server is equipped with a monitoring agent, which periodically collects load indicators such as CPU utilization, memory usage, and network bandwidth usage of the corresponding cloud server and reports them to the management and control center. The management and control center integrates the reported load indicators to obtain the load status of the corresponding cloud server and compares the load status with a preset load threshold. When the load status is lower than the preset load threshold, the cloud server is determined to meet the load status standard. When selecting the target cloud server for migration, the management and control center sorts the candidate cloud servers for migration from smallest to largest load status and selects the one with the smallest load status as the target cloud server for migration. That is, the target cloud server for migration is determined according to the minimum load priority strategy. The escape package is a lightweight virtual machine (or a migration unit composed of multiple lightweight virtual machines). Internally, it runs three virtual sub-units in virtualization isolation: an outer container, an inner container, and a backup container (these three are connected sequentially; the backup container is only activated when the outer container is disconnected, and remains dormant at other times). Each of these is either an independent virtual machine or a virtual sub-unit within the same virtual machine (such as a container-level isolation unit). They are connected to each other via virtual switches / virtual channels within the escape package, and each connection can be independently controlled for connection and disconnection. During the connection process, the outer container is configured with a virtual network interface, which establishes a virtual network connection with the network interface of the intermediate node, such as VXLAN or a Geneve overlay tunnel. This connection is used for the transmission of the data packets to be migrated between the escape package and the intermediate node and can be maintained or disconnected independently. The outer container and the inner container are connected via a virtual channel within the escape package, such as an internal virtual network interface, a virtio channel, or a shared memory channel. Under normal circumstances, this channel is connected, and the outer container acts as a network proxy to transmit data to the inner container. This internal channel can be disconnected independently of the external connection, thus achieving the escape. The inner and backup warehouses are connected through an internal standby channel. Normally, the backup warehouse is in a dormant state. When the inner warehouse triggers a disconnection, the backup warehouse is activated. The backup warehouse obtains docking information through the standby channel and takes over the docking function of the original outer warehouse, establishing a new external connection with the next intermediate node. During the disconnection process, when an intermediate node is determined to be maliciously compromised, the outer warehouse continues to maintain its connection with the compromised intermediate node without disconnecting, acting as bait to mislead the attacker into believing that the data is still on that node. At the same time, the inner warehouse cuts off the internal virtual channel between itself and the outer warehouse, completely isolating the data packet to be migrated from the outer warehouse and the compromised node. Subsequently, the inner warehouse carries the data packet to be migrated and activates the backup warehouse. The two initiate a new connection to the next intermediate node in the real-time topology graph through another virtual network interface of the escape packet. After the backup warehouse is activated, it assumes the function of the original outer warehouse, establishes an external connection with the next intermediate node, and the inner warehouse continues to carry the data and completes the subsequent jump through the backup warehouse.

[0032] The process by which an intermediate node synchronously perceives whether there is a jump path between itself and its neighboring mirror nodes based on its corresponding mirror node means that the intermediate node learns in real time whether the jump path between itself and its neighboring mirror nodes is available through its corresponding mirror node. In other words, the intermediate node needs to know whether it can jump to the neighboring node and whether the neighboring node can jump to itself. The principle is that each mirror node maintains its current metric status, i.e., whether it meets the standard or deviates from it. This status is obtained by comparing the real-time metric value of the corresponding cloud server's hardware root of trust with a preset trust standard. A status synchronization channel is set up within the virtual image layer, such as a publish-subscribe mechanism or a status broadcast bus. When the metric status of any mirror node changes, the mirror node immediately broadcasts its status change to all adjacent mirror nodes through the status synchronization channel. After receiving the status change notification, adjacent mirror nodes update the status of the jump path they maintain locally according to the metric status of both parties. If both meet the standard, a jump path is established; if either deviates, the existing jump path is not established or is disconnected. Adjacent mirror nodes can also periodically send each other heartbeat messages carrying their own metric status as a backup. When the heartbeat times out or a deviation heartbeat is received, the jump path is determined to be unusable. Intermediate nodes obtain the jump path status maintained by the corresponding mirror nodes in real time through the internal status synchronization interface with the corresponding mirror nodes, such as a virtual bus, shared memory, or internal message channel, thereby synchronously sensing whether a jump path exists between them and adjacent mirror nodes. In short, mirror nodes communicate with each other. To determine its own trustworthiness, intermediate nodes listen to the reports from their corresponding mirror nodes, thus knowing in real time which adjacent nodes can be hopped to and which cannot. Furthermore, in the real-time topology graph construction and dynamic update phase, the establishment and disconnection of jump paths depend on the state synchronization between mirror nodes. Synchronization awareness is the foundation of real-time topology graph dynamic updates, and the existence of each jump edge in the topology graph is determined by the results of synchronization awareness. In the jump decision phase for data packets to be migrated, when a data packet jumps along the shortest topology path, intermediate nodes use synchronization awareness to determine which adjacent jump paths are currently available, deciding whether the data packet can jump to the next node. If the path is unavailable, it is not forwarded in that direction. In the path reselection phase after an abnormal exit, when an intermediate node is compromised and the internal storage carries the data packet out, it is necessary to reselect the next intermediate node based on the real-time topology graph. Synchronization awareness ensures the real-time accuracy of the reselection path, avoiding reselection to a compromised node. In the shortest topology path determination phase, when the breadth-first search algorithm traverses available jump paths, the determination of available paths depends on the results of synchronization awareness; only jump paths determined to exist by synchronization awareness are included in the breadth-first search scope.

[0033] Example 2, please refer to Figure 2 As shown in this embodiment, the cloud server cluster dynamic access control system based on hardware trust includes: The module is used to establish a control center for the corresponding cloud server cluster and to establish a trusted cluster pool based on the control center. The monitoring and adjustment module is used to monitor the cloud server cluster in real time based on the control center, and to dynamically adjust each cloud server in the cloud server cluster and the trusted cluster pool based on the monitoring results. The access module is used to establish a cluster gateway. When an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server in the trusted cluster pool, and the target cloud server will process the access request. The data migration module is used to isolate the relevant running files and running status data corresponding to the access request if the target cloud server is detected to be maliciously compromised while the access request is running on the target cloud server. After the isolation is completed, a migration channel is established between the target cloud server and the migration target cloud server. Based on the migration channel, the relevant running files and running status data corresponding to the access request are migrated to the migration target cloud server.

[0034] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions 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 scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A dynamic access control method for cloud server clusters based on hardware trust, characterized in that, Includes the following steps: Establish a management and control center for the corresponding cloud server cluster, and build a trusted cluster pool based on the management and control center; The control center performs real-time monitoring of the cloud server cluster and dynamically adjusts each cloud server in the cloud server cluster and trusted cluster pool based on the monitoring results. Establish a cluster gateway. When an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server in the trusted cluster pool, and the target cloud server will process the access request. If a malicious attack is detected on the target cloud server while the access request is running on the target cloud server, the relevant running files and running status data corresponding to the access request will be isolated. After the isolation is completed, a migration channel will be established between the target cloud server and the migration target cloud server. Based on the migration channel, the relevant running files and running status data corresponding to the access request will be migrated to the migration target cloud server.

2. The dynamic access control method for cloud server clusters based on hardware trust according to claim 1, characterized in that, The steps of establishing a management and control center for the corresponding cloud server cluster and establishing a trusted cluster pool based on the management and control center include: Establish a management and control center for the corresponding cloud server cluster, and bind a unique number to each cloud server in the cloud server cluster; By using hardware roots of trust deployed on each cloud server to obtain the metrics of each cloud server in the cloud server cluster in real time, cloud servers whose metrics meet the preset trust standards are added to the trusted cluster pool.

3. The dynamic access control method for cloud server clusters based on hardware trust according to claim 1, characterized in that, The steps of real-time monitoring of the cloud server cluster by the control center and dynamic adjustment of each cloud server in the cloud server cluster and trusted cluster pool based on the monitoring results include: The monitoring results are obtained by acquiring the measurement values ​​of each cloud server in the cloud server cluster and trusted cluster pool from the control center and comparing the measurement values ​​of each cloud server with the preset trusted standards. Based on the monitoring results, when the metric value of a cloud server in the trusted cluster pool deviates from the preset trusted standard, it is removed from the trusted cluster pool; when the metric value of a cloud server that previously did not meet the preset trusted standard meets the preset trusted standard, it is added back to the trusted cluster pool.

4. The dynamic access control method for cloud server clusters based on hardware trust according to claim 1, characterized in that, The establishment of the cluster gateway involves the following steps: when an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server within the trusted cluster pool. The target cloud server will then process the access request. Establish a cluster gateway for the corresponding cloud server cluster and trusted cluster pool. The cluster gateway is used to receive access requests from the outside world. When an external access request arrives at the cluster gateway, the cluster gateway parses the access request, determines the corresponding target cloud server based on the target service identifier carried in the access request, and determines the metric value and load status of the target cloud server. If the target cloud server is located in the trusted cluster pool and its load status meets the requirements, the access request will be scheduled to the target cloud server. If the target cloud server is not in the trusted cluster pool or its load status does not meet the requirements, the access request will be scheduled to other cloud servers in the trusted cluster pool that meet the requirements as the target cloud server. Access requests are processed based on the target cloud server they are accessing until completion, or a migration process is triggered when the target cloud server is detected to have been maliciously compromised.

5. The dynamic access control method for cloud server clusters based on hardware trust according to claim 1, characterized in that, If, during the execution of the access request on the target cloud server, it is detected that the target cloud server has been maliciously compromised, the relevant running files and running status data corresponding to the access request are isolated. After isolation is completed, a migration channel is established between the target cloud server and the migration target cloud server. The steps of migrating the relevant running files and running status data corresponding to the access request to the migration target cloud server based on the migration channel include: During the execution of the access request on the target cloud server, the control center monitors the target cloud server's metrics in real time through the hardware root of trust deployed on the target cloud server. When the target cloud server's metrics deviate from the preset trust standard, it is determined that the target cloud server has been maliciously attacked. The control center sends a pause scheduling command to the cluster gateway, causing the cluster gateway to stop scheduling new access requests to the target cloud server. The control center locates maliciously compromised files on the target cloud server based on file-level integrity monitoring, isolates the maliciously compromised files at the file level, suspends the processes corresponding to the access requests currently running on the target cloud server, saves the relevant running files and running status data of the access requests, and packages the relevant running files and running status data of the access requests into a migration data package. The relevant running files are clean versions of the maliciously compromised files obtained from the trusted file library maintained by the control center. The control center selects cloud servers from the trusted cluster pool that provide the same services as the target cloud server, whose metrics meet the preset trusted standards, and whose load status meets the standards as candidate cloud servers for migration. Then, it selects one of the candidate cloud servers as the target cloud server for migration according to the minimum load priority strategy. The control center establishes a migration channel between the target cloud server and the migration target cloud server, sends the data packets to be migrated to the migration target cloud server through the migration channel, loads the data packets to be migrated in the migration target cloud server and resumes operation in the migration target cloud server, and disconnects the migration channel between the target cloud server and the migration target cloud server after the control center confirms that the migration is completed.

6. The dynamic access control method for cloud server clusters based on hardware trust according to claim 1, characterized in that, The steps of establishing a migration channel between the control center and the target cloud server and sending the data packet to be migrated to the target cloud server through the migration channel include: Obtain the metric values ​​of each cloud server in the cloud server cluster, and map each cloud server in the cloud server cluster to a preset virtual image layer constructed based on the physical and logical topology relationship of each cloud server to obtain multiple image nodes. Using the target cloud server as the sending node and the target cloud server to be migrated as the receiving node, the cloud servers corresponding to other image nodes in the virtual image layer that are physically reachable and logically connected on the jump path between the sending node and the receiving node, and whose metric values ​​meet the preset trust standards, are identified as intermediate nodes. A migration channel is established based on the sending node, multiple intermediate nodes, and the receiving node. An escape packet is configured for the data packets to be migrated. The escape packet includes an outer container, an inner container, and a backup container. The inner container is used to carry the data packets to be migrated, the outer container is used to interface with the intermediate node to which the data packets are to be migrated, and the backup container is used to replace the outer container in connecting to the next intermediate node after the inner container and the outer container are disconnected. The sending node transmits the data packet to be migrated based on the migration channel. The data packet to be migrated is redirected based on the metric values ​​of each mirror node in the virtual image layer until it is redirected to the target cloud server.

7. The dynamic access control method for cloud server clusters based on hardware trust according to claim 6, characterized in that, The steps for redirecting the data packet to be migrated based on the metric values ​​of each mirror node within the virtual image layer until it reaches the target cloud server include: When the metric values ​​of two adjacent mirror nodes in the virtual mirror layer reach the preset trust standard, a jump path is established between them. If the metric value deviates from the preset trust standard, no jump path is established between adjacent mirror nodes. A real-time topology graph is constructed based on multiple jump paths in the virtual mirror layer. Mirror nodes are connected to corresponding intermediate nodes, and intermediate nodes synchronously perceive whether there is a jump path between them and adjacent mirror nodes based on the corresponding mirror nodes. The data packet to be migrated jumps along the jump path corresponding to the shortest topological distance between the sending node and the receiving node until it reaches the target cloud server. When the data packet to be migrated jumps to an intermediate node, it connects with the intermediate node through the outer container of the escape packet. The inner container carries the data packet to be migrated. When the metric value of the mirror node corresponding to the intermediate node deviates from the preset trust standard and it is determined that the intermediate node has been maliciously compromised, the outer container does not disconnect from the intermediate node, the inner container disconnects from the outer container, and the inner container, carrying the data packet to be migrated and the backup container, jumps to the next intermediate node based on the real-time topology map. The backup container reconnects with the next intermediate node until it reaches the target cloud server.

8. A hardware-trust-based dynamic access control system for cloud server clusters, used to implement the hardware-trust-based dynamic access control method for cloud server clusters as described in any one of claims 1-7, characterized in that, include: The module is used to establish a control center for the corresponding cloud server cluster and to establish a trusted cluster pool based on the control center. The monitoring and adjustment module is used to monitor the cloud server cluster in real time based on the control center, and to dynamically adjust each cloud server in the cloud server cluster and the trusted cluster pool based on the monitoring results. The access module is used to establish a cluster gateway. When an external access request arrives at the cluster gateway, the cluster gateway will connect the access request to the target cloud server in the trusted cluster pool, and the target cloud server will process the access request. The data migration module is used to isolate the relevant running files and running status data corresponding to the access request if the target cloud server is detected to be maliciously compromised while the access request is running on the target cloud server. After the isolation is completed, a migration channel is established between the target cloud server and the migration target cloud server. Based on the migration channel, the relevant running files and running status data corresponding to the access request are migrated to the migration target cloud server.

Images