Non-bypassable cloud computer infrastructure control system and method
Patent Information
- Application Number
- CN202611284454.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-24
- Publication Date
- 2026-10-23
AI Technical Summary
[0006]本申请的目的是提供一种不可旁路的云计算机基础设施控制系统和方法,旨在解决现有技术中云计算机基础设施控制分散、易被旁路、执行过程缺乏可靠性保障的技术问题
1.通过设置作为唯一控制决策中心的管理控制平台,以及在执行前必须验证合法控制关系的分布式执行组件,从系统架构上确保了所有基础设施状态变更均受集中管控,杜绝了旁路操作,从而提升了系统的一致性和安全性。
Smart Images

Figure FT_1 
Figure FT_2 
Figure FT_3
Abstract
Description
Technical Field
[0001] This invention belongs to the field of cloud computing technology, specifically relating to a non-bypassable cloud computer infrastructure control system and method. Background Technology
[0002] In modern cloud computing infrastructure, there are numerous distributed control interfaces, such as those used to manage virtual machines, networks, storage, and sessions. If administrators, automation scripts, or third-party applications can bypass a unified management platform and directly call these interfaces, it will lead to inconsistencies between the system state maintained by the management platform and the actual state of the infrastructure, creating management and audit vulnerabilities and introducing security risks.
[0003] Existing security solutions, such as access control based on zero-trust gateways, mainly perform authentication and traffic access at the network access layer, but cannot solve the problem of legitimate users or scripts that have entered the network making bypass calls to distributed infrastructure interfaces.
[0004] Furthermore, even if the source of the control command is verified, there are still many challenges: First, during the transmission and interpretation of the command, factors such as object aliases and parameter substitution may cause the semantics of the operation to deviate from the original intent of authorization; second, due to network latency or system retry mechanisms, the same command may be delivered and executed multiple times, causing errors such as duplicate creation or deletion of resources; finally, after the operation is executed, if no definite success or failure acknowledgment is received due to network interruption or component failure, the system will be in an uncertain state, and blindly replaying the operation may lead to irreversible damage.
[0005] Therefore, existing technologies urgently need to address the technical problems of decentralized control, susceptibility to bypass, and lack of reliability guarantees in the execution process of cloud computing infrastructure. Specifically, how to ensure that all state changes are strictly controlled by the central management platform and guarantee the consistency of operational intentions, the uniqueness of execution, and the robustness of the system under abnormal conditions. Summary of the Invention
[0006] The purpose of this application is to provide a non-bypassable cloud computing infrastructure control system and method, aiming to solve the technical problems of decentralized control, easy bypassing, and lack of reliability guarantee in the execution process of cloud computing infrastructure in the prior art.
[0007] To achieve the above objectives, this application provides the following solution: In a first aspect, this application provides a non-bypassable cloud computing infrastructure control system, including: a management control platform and at least one execution component distributed on at least one of the terminal side, the isolation device side, and the computing side; The management and control platform is used to: receive and respond to a request containing a requested state change; obtain object relationship information and state information related to the target infrastructure object and the requested state change; determine the target control execution function, the target infrastructure object, and the action to be executed based on the object relationship information and state information; establish a legitimate control relationship and form a control requirement that includes at least the target control execution function, the target infrastructure object identifier, the action to be executed, and associated information; the associated information is used to enable the control requirement to correspond to the execution result. The at least one execution component together provides control execution functions and business processing functions for handling display and input interaction information, wherein the control execution functions and the business processing functions are logically separate. The target control execution function is configured to: verify whether the control request belongs to the legitimate control relationship before changing the state of the target infrastructure object; control requests that fail verification are not executed; execute the verified control requests and return an execution result containing the associated information; The business processing function is used to process display and input interaction information after the legal control relationship is established, and is not used as a direct entry point for infrastructure status changes; The management and control platform is also used to confirm or update the status of the target infrastructure object based on the associated information corresponding to the control requirements and the execution results, and to decide on subsequent actions based on the execution results.
[0008] Secondly, this application provides a non-bypassable cloud computing infrastructure control method, which is executed by a system including a management control platform and one or more execution components, the method comprising: The management and control platform receives a request containing the requested state change, obtains object relationship information and state information related to the target infrastructure object and the requested state change, determines the target control execution function, the target infrastructure object and the action to be executed based on the information, establishes a legitimate control relationship, and forms a control requirement that includes at least the target control execution function, the target infrastructure object, the action to be executed and the associated information. Before changing the state of the target infrastructure object, the corresponding target control execution function in one or more execution components verifies whether the control request belongs to the legal control relationship. Control requests that fail verification are not executed. The verified control requests are executed, and an execution result containing the associated information is returned. The control execution function provided by the execution component is separate from the business processing function logic used to process display and input interaction information. The business processing function processes display and input interaction information after the legal control relationship is established, and does not serve as a direct call entry point for infrastructure status changes. The management and control platform confirms or updates the status of the target infrastructure object based on the associated information corresponding to the control requirements and the execution results, and decides on subsequent actions based on the execution results.
[0009] Thirdly, this application provides a management and control platform for a non-bypassable cloud computing infrastructure control system. The management and control platform includes a processor and a memory, the memory storing a computer program. When the computer program is executed by the processor, it implements: Receive a request containing the requested state change, and obtain object relationship information and state information related to the target infrastructure object and the requested state change. Based on the information, determine the target control execution function, the target infrastructure object and the action to be executed, establish a legitimate control relationship, and form a control requirement that includes at least the target control execution function, the target infrastructure object, the action to be executed and related information. Receive an execution result containing the aforementioned associated information; Based on the associated information corresponding to the control requirements and the execution results, the status of the target infrastructure object is confirmed or updated, and subsequent actions are determined based on the execution results.
[0010] According to the specific embodiments provided in this application, the following technical effects are disclosed: 1. By setting up a management control platform as the sole control and decision-making center, and a distributed execution component that must verify legitimate control relationships before execution, the system architecture ensures that all infrastructure state changes are centrally managed, eliminating bypass operations and thus improving system consistency and security.
[0011] 2. By logically separating the control execution function from the business processing function, strict security control is achieved while preventing massive business data flows from passing through the management platform, thus ensuring that business performance is not affected.
[0012] 3. By using corresponding related information in control requirements and execution results, the entire operation process can be tracked, confirmed, and followed up, forming a complete control loop that facilitates auditing and anomaly recovery.
[0013] 4. By introducing a request-commitment mechanism, the authorized intent is compared with the actual operation before execution. This effectively prevents "legal but non-compliant" operations caused by tampering or ambiguity in the transmission or interpretation of the request, ensuring consistency between authorization and execution.Figure 1 To the point of being responsive.
[0014] 5. By introducing a single-execution identifier and an exclusive acquisition of execution qualification mechanism, atomic operations ensure that an authorized operation can only be successfully executed once, solving the problem of repeated execution caused by network retries, concurrent requests, etc., and avoiding errors such as repeated creation or deletion of resources.
[0015] 6. By introducing three-branch fault handling rules, especially the locking and reconciliation mechanism for uncertain execution results, the system avoids blindly replaying high-risk operations under abnormal conditions, significantly enhancing the system's robustness and fault recovery capabilities. Attached Figure Description
[0016] 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 of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a schematic diagram illustrating the relationship between the DMS management platform and the terminal side, the isolation device side, and the computing side execution components in one embodiment of this application.
[0018] Figure 2 This is a flowchart of DMS decision-making, distributed execution, feedback correlation, and state update in one embodiment of this application.
[0019] Figure 3 This is a schematic diagram illustrating the data relationship between control requirements, associated information, and corresponding execution results in one embodiment of this application.
[0020] Figure 4 This is a schematic diagram of the data object relationships of an advanced security mechanism in one embodiment of this application.
[0021] Figure 5 This is a schematic diagram of the system state and security boundary in one embodiment of this application. Detailed Implementation
[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0023] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0024] This invention provides a non-bypassable cloud computing infrastructure control system and method, aiming to solve the technical problems of decentralized control, susceptibility to bypass calls, and lack of reliability guarantees in the execution process of existing cloud infrastructure. In existing technologies, administrators, automated scripts, or third-party applications can bypass a unified management platform and directly call infrastructure interfaces scattered across various locations. This leads to inconsistencies between the system state maintained by the management platform and the actual state of the infrastructure, creating blind spots in management and auditing, and introducing security risks. This invention constructs a closed-loop control system with a management control platform as the sole decision-making center and distributed execution components as execution touchpoints, ensuring that all changes to the infrastructure state are under strict and unified control.
[0025] The non-bypassable cloud computing infrastructure control system provided by the present invention specifically includes: a management control platform and at least one execution component distributed on at least one of the terminal side, the isolation device side, and the computing side.
[0026] The management and control platform is used to: receive and respond to requests containing requested state changes; obtain object relationship information and state information related to the target infrastructure object and the requested state change; determine the target control execution function, the target infrastructure object, and the action to be executed based on the object relationship information and state information; establish a legitimate control relationship and form a control requirement that includes at least the target control execution function, the target infrastructure object identifier, the action to be executed, and the associated information. The associated information is used to ensure that the control requirement and the execution result can be determined to correspond.
[0027] These at least one execution component collectively provide control execution functions as well as business processing functions for handling display and input interaction information, with the control execution functions and business processing functions logically separated.
[0028] The target control execution function is configured to: verify whether the control requirement belongs to a legitimate control relationship before changing the state of the target infrastructure object; control requirements that fail verification will not be executed; execute the verified control requirements and return the execution result containing related information.
[0029] The business processing function is used to process display and input interaction information after a legitimate control relationship is established, and is not used as a direct entry point for infrastructure status changes.
[0030] The management and control platform is also used to confirm or update the status of target infrastructure objects based on the corresponding control requirements and execution results according to the associated information, and to decide on subsequent actions based on the execution results.
[0031] Specifically, the management control platform is responsible for receiving requests containing requested state changes and making decisions based on comprehensive object relationship and state information. This decision-making process includes determining which target control execution function should perform the action, which target infrastructure object should be operated, and what specific action should be taken. Based on this decision, the management control platform establishes a verifiable and legitimate control relationship and forms a structured control requirement. This control requirement is the carrier for subsequent precise control; it contains all the key information required for execution, such as the target control execution function (or its identifier), the target infrastructure object (or its identifier), the action to be performed, the associated information for closed-loop tracking, and the information for verifying the legitimacy of the control requirement. In this way, the management control platform transforms abstract control intentions into specific, executable, and verifiable instructions, ensuring the authority and uniqueness of control from the source.
[0032] One or more execution components act as the final executors of control commands, distributed across various layers of the cloud infrastructure, such as the endpoint side, the isolation device side, and the compute side. A key characteristic of these execution components is their binary separation of functions: the logical separation of control execution functions and business processing functions. The control execution function is the only legitimate entry point for changing the infrastructure state; it strictly enforces control requirements from the management control platform. The business processing function, on the other hand, handles routine display and input interactions and does not have the ability to directly change the infrastructure state. This design ensures the seriousness of control while avoiding interference from massive amounts of business data on the control plane. Before executing any operation that might change the infrastructure state, the target control execution function must fulfill a crucial responsibility: based on the verification information contained in the control requirement, it must rigorously verify whether the control requirement originates from a legitimate control relationship. Any control requirement that fails verification will be rejected, effectively preventing unauthorized bypass operations.
[0033] To achieve a complete closed-loop control process, after executing a verified control request, the target control execution function returns an execution result containing associated information. This associated information acts like a unique transaction ID, enabling the management control platform to accurately match issued control requests with received execution results. Based on this correspondence, the management control platform can reliably confirm or update the actual status of the target infrastructure object and determine subsequent handling strategies based on whether the execution result is successful, failed, or uncertain—such as continuing to the next step, performing compensatory operations, or escalating the problem to manual handling. This closed-loop mechanism solves the inconsistency in status caused by the lack of tracking of execution results in some control modes, achieving refined management of the entire lifecycle of infrastructure operations.
[0034] In some embodiments, the management control platform is further configured to: process requests based on deterministic normalization rules to form request commitments, and include the request commitments in control requirements; the target control execution function is further configured to: verify whether the actions to be executed contained in the control requirements are consistent with the request commitments before executing the control requirements.
[0035] Specifically, to ensure complete consistency between the semantics of the operation during authorization and the semantics of the final execution, and to prevent execution deviations caused by parameter tampering or ambiguous interpretations, a "request commitment" mechanism is introduced in some embodiments. When forming a control requirement, the management control platform first processes the original request based on a set of deterministic normalization rules, such as standardizing field order, parsing object aliases, and expanding default values, to form a normalized request. Then, a request commitment is calculated based on this normalized request and included in the control requirement. Correspondingly, before execution, the target control execution function must also process the actual actions it receives using the same normalization rules, calculate the actual request commitment, and verify its consistency with the request commitment included in the control requirement. Only when both are completely consistent can it be proven that the semantics of the operation have not been tampered with, and only then is the operation allowed to continue. This mechanism enhances the integrity and consistency of control instructions during transmission and interpretation.
[0036] In some embodiments, the control requirement includes a single execution identifier; the target control execution function is further configured to exclusively acquire execution eligibility with an atomic operation based on the single execution identifier before generating an external state change of the infrastructure.
[0037] Specifically, to address the issue of duplicate execution caused by network retries, repeated user clicks, or concurrent system processing, some embodiments introduce a "single-execution identifier" and an "exclusive execution qualification" mechanism. A globally unique single-execution identifier is included in the control requirement. Before any actual, irreversible external state change occurs, the target control execution function must exclusively acquire execution qualification based on this single-execution identifier through an atomic operation (such as a database "compare-and-swap" or distributed lock). Once an execution instance successfully acquires the qualification, its status is marked as "occupied." Any other concurrent requests holding the same single-execution identifier will fail when attempting to acquire the qualification because it is already occupied, thus preventing execution. In this way, it is ensured that an authorization operation, regardless of how many times it is submitted, will ultimately only be successfully executed once, guaranteeing the idempotency of the operation.
[0038] In some embodiments, the control requirements include the expected prior state or state version of the target infrastructure object; the target control execution function is further configured to: before execution, check whether the current state of the target infrastructure object meets the expected prior state and whether its current version meets the state version.
[0039] Specifically, to avoid performing operations on outdated system states, control requirements can also include the expected prior state or version of the target infrastructure object. Before execution, the target control execution function must first query the current actual state or version of the target infrastructure object and verify whether it meets the expected prior state or version in the control requirements. For example, an operation to "start a virtual machine" should have the expected prior state as "stopped". If, during execution, the current state of the virtual machine is found to be "running" or "faulty", it indicates that the situation has changed, the original instruction is no longer applicable, and execution will be aborted. This prior state verification effectively prevents erroneous operations caused by state delays or information asymmetry.
[0040] In some embodiments, the control requires binding fault handling rules, which distinguish between three boundary cases: "no external change has occurred", "an indivisible step has begun", and "the result is uncertain" due to execution timeout or return of a specific status code. The rules stipulate that when the result is uncertain, the operation should be locked and reconciled, rather than automatically replayed.
[0041] Specifically, to address the issue of uncertain execution results in complex distributed environments, some embodiments introduce a sophisticated fault handling mechanism. Control requirements can be bound to a fault handling rule that clearly distinguishes three different execution boundary conditions. The first is "no external changes," meaning the operation fails before or in an early stage of execution, and it can be confirmed that it has no impact on the system. The second is "an indivisible step has begun," meaning the operation has entered a stage where it cannot be safely interrupted. The third is "uncertain result," a typical scenario where the execution component issues a command to the underlying controller but fails to receive a definite response due to network interruption or controller non-response. For this uncertain result situation, the rule stipulates that the system must lock and reconcile the operation, rather than simply performing automatic replay. Locking means that the execution qualification of the operation is set to "pending confirmation," preventing any subsequent operations. Reconciliation is performed by the management control platform after recovery, using multiple channels (such as querying the underlying controller's logs and checking the actual status of the object) to ultimately determine the true result of the operation and complete the state closure loop accordingly. This mechanism greatly enhances the robustness of the system, avoiding serious errors or irreversible changes in the system state that may result from blindly retrying under uncertain conditions.
[0042] In some embodiments, when the management control platform is disconnected, the execution component is configured to refuse to execute any control requests that are not generated by the management control platform.
[0043] Specifically, when the execution component loses connection to the management control platform, it enters a "security failover" mode. In this mode, the execution component refuses to execute any legitimate control requests not pre-defined by the management control platform. This means the system will not accept any new state change requests, thus preventing any uncontrolled operations during the disconnection period. However, for services already established and in a normal state before the disconnection (such as an ongoing remote desktop session), their data flow can continue, ensuring business continuity. This design ensures system security in extreme situations while also considering user experience.
[0044] This invention also provides a non-bypassable cloud computing infrastructure control method, which is executed by the aforementioned non-bypassable cloud computing infrastructure control system, and specifically includes: The management and control platform receives a request containing the requested state change, obtains object relationship information and state information related to the target infrastructure object and the requested state change, determines the target control execution function, the target infrastructure object and the action to be executed based on the information, establishes a legitimate control relationship, and forms a control requirement that includes at least the target control execution function, the target infrastructure object, the action to be executed and the associated information. The corresponding target control execution function in one or more execution components verifies whether the control requirement belongs to a legal control relationship before changing the state of the target infrastructure object. Control requirements that fail verification are not executed; the verified control requirements are executed, and the execution result containing related information is returned. Among them, the control execution function provided by the execution component is separate from the business processing function logic used to handle display and input interaction information. The business processing function handles display and input interaction information after the legal control relationship is established, and does not serve as a direct call entry point for infrastructure status changes. The management and control platform confirms or updates the status of the target infrastructure object based on the corresponding control requirements and execution results according to the associated information, and decides on subsequent actions based on the execution results.
[0045] Specifically, the method first involves the management control platform receiving a request containing the requested state change, and obtaining object relationship information and state information related to the target infrastructure object and the requested state change. Based on this information, it determines the target control execution function, the target infrastructure object, and the action to be executed, establishes a legitimate control relationship, and forms a control requirement containing all necessary information. Subsequently, the corresponding target control execution function performs the following steps: before changing the state of the target infrastructure object, it strictly verifies whether the control requirement belongs to a legitimate control relationship and rejects control requirements that fail verification; for verified control requirements, it executes them and returns an execution result containing associated information. Finally, the management control platform verifies the control requirement based on the received execution result and associated information, confirms or updates the state of the target infrastructure object, and decides on subsequent actions. Throughout the process, the business processing functions used to handle display and input interaction information are logically separated from the control execution functions and are not used as direct entry points for state changes, ensuring the separation of control flow and business flow and helping to maintain the performance of the business flow.
[0046] In some embodiments, the method further includes the steps of forming and verifying a request commitment. Specifically, when the management control platform forms a control requirement, it processes the request based on deterministic normalization rules to form a request commitment, and includes the request commitment in the control requirement. Accordingly, before the target control execution function executes the control requirement, a verification step is added to verify whether the actions to be executed contained in the control requirement are consistent with the request commitment, thereby ensuring the consistency between authorization semantics and execution semantics.
[0047] In some embodiments, the method further includes a step of acquiring exclusive execution eligibility. Specifically, the control requirement may include a single-execution identifier. Before any external state change occurs in the infrastructure, the target control execution function exclusively acquires execution eligibility in an atomic manner based on this single-execution identifier, thereby effectively preventing concurrent duplicate execution.
[0048] In some embodiments, the method further includes a step of verifying the preceding state. Specifically, the control requirement may contain the expected preceding state or state version of the target infrastructure object. Before execution, the target control execution function first verifies whether the current state or version of the target infrastructure object meets the expectation, and only continues execution if it does.
[0049] In some embodiments, the method may further include the step of binding and executing a fault handling rule. When the control requirements are formulated, a fault handling rule is bound to them, distinguishing between three boundary cases: "no external change has occurred," "an indivisible step has begun," and "the outcome is uncertain." This rule specifically stipulates that when the outcome is uncertain, the operation must be locked and reconciled, rather than automatically replayed.
[0050] Furthermore, the method defines the behavior in the event of a disconnection. When the management control platform becomes disconnected, the execution components refuse to execute any control requests not originating from the management control platform, thereby ensuring the system's security boundaries.
[0051] It should be noted that this method is executed by the aforementioned non-bypassable cloud computing infrastructure control system; therefore, for a detailed description of this method, please refer to the aforementioned detailed description of the cloud computing infrastructure control system.
[0052] This invention also provides a management and control platform, which can be a physical device or a virtualized device, including a processor and a memory, wherein the memory stores a computer program. When the processor executes the program, it can perform all the functions performed by the management and control platform in the aforementioned method, including receiving requests, establishing legitimate control relationships, forming control requirements, receiving execution results, and confirming or updating the status based on associated information and deciding on subsequent actions.
[0053] The following exemplary embodiment will provide a more detailed description of the non-bypassable cloud computing infrastructure control system provided by the present invention.
[0054] In one exemplary embodiment, the cloud computing infrastructure control system includes a management control platform (DMS management platform 400) serving as a centralized decision-making center and the sole control source, and multiple distributed execution components. These execution components can be distributed on the terminal side (e.g., terminal-side execution component 910), the isolated device side (e.g., isolated device-side execution component 920), and the computing side (e.g., computing-side execution component 930). The management control platform is responsible for generating control requirements and distributing them to the corresponding execution components through a secure control link. After execution, the execution components feed back their status to the management control platform by associating the execution results, forming a complete control loop. The cloud computing infrastructure control system also has business processing functions, handling requests from external callers. However, any bypass requests attempting to directly change the infrastructure state will be rejected by the execution components, reflecting the "non-bypass" characteristic of this invention.
[0055] In a specific implementation, the management and control platform can contain multiple logical modules that work collaboratively. For example, it may include an identity management module, a terminal management module, an instance management module, an auditing module, a policy and decision-making module, a control requirement management module, and a status management module. The policy and decision-making module, based on comprehensive information obtained from other modules (such as user identity, terminal trust status, instance ownership, resource quotas, etc.), decides whether to approve an operation request. The control requirement management module is responsible for translating this decision into a structured, verifiable control requirement and managing its lifecycle, including sending, tracking, and revocation. The status management module accurately updates the system state model maintained by the platform based on the execution results returned by the execution components, ensuring that it remains consistent with the actual state of the infrastructure.
[0056] like Figure 2 As shown, a typical general control flow is as follows: In step S101, the management control platform receives a request, which may come from a user interface, an automation script, or a third-party system, intended to change the state of an infrastructure object.
[0057] In step S102, the strategy and decision module of the management control platform makes a decision and establishes a legitimate control relationship.
[0058] In step S103, the control request management module generates and sends a control request containing associated information.
[0059] In step S104, the target execution component (e.g., the computation-side execution component 930) receives the control request, first verifies its legality, executes the specified action after the verification is successful, and returns an execution result that also contains the associated information.
[0060] In step S105, the management and control platform receives the execution result, matches it with the original request through the associated information, thereby confirming or updating the status of the object and deciding on subsequent actions.
[0061] like Figure 3 As shown, this process forms a data closed loop, in which legitimate control relationships, control requirements, and execution results are verified through correlation, ultimately triggering status confirmation and subsequent handling.
[0062] To address the potential inconsistency between authorization semantics and execution semantics, this embodiment introduces a "request commitment" mechanism. For example... Figure 4As shown, an enhanced control requirement, namely the authorization operation encapsulation, can contain a request commitment C100. This request commitment C100 is a summary value calculated by the management control platform for a normalized request. When the execution component receives an actual operation request, it must process the request using the same normalization rules, calculate the actual commitment value, and compare it with the request commitment C100 carried in the authorization operation encapsulation. Only when the two are completely consistent can it be proven that the semantics of the operation have not been tampered with. For example, a request with an authorization of "read-only" mount, if maliciously tampered with to "read-write," will inevitably have a different calculated commitment value than the original value, thus being detected and blocked before execution.
[0063] Furthermore, to prevent operational errors caused by concurrent or repeated deliveries, this embodiment introduces a "single execution identifier" and an "exclusive execution qualification" mechanism. For example... Figure 4 As shown, the authorization operation encapsulation also includes a single-execution identifier X100. Before the execution component calls the underlying controller to generate an actual external state change, it must use this single-execution identifier X100 to acquire an exclusive execution qualification Q100. This acquisition process is an atomic operation, ensuring that at any given time, only one execution instance can successfully acquire the qualification for the same single-execution identifier X100. For example, if a user repeatedly clicks the "delete" button due to network congestion, resulting in two identical deletion requests arriving concurrently, only one request will successfully acquire the execution qualification Q100 and execute the deletion operation. The other request will be aborted due to failure to acquire the qualification, thus effectively avoiding the error of performing a deletion operation on an already deleted object again.
[0064] Furthermore, to avoid performing operations on outdated system states, the authorization operation encapsulation can also include the expected prior state or version V31 of the target object, such as... Figure 4 As shown. Before execution, the execution component must verify whether the current state of the target object meets this expectation. For example, if an authorization operation was issued when the virtual machine version was V31, and execution finds that the virtual machine version has changed to V32, it means that the virtual machine state may have been changed by other operations during this period, and the original authorization operation may no longer be applicable. Therefore, the execution will be aborted. This ensures that all operations are executed based on the latest, expected system state.
[0065] To enhance system robustness, particularly in handling situations with uncertain execution results, this embodiment employs sophisticated fault handling rules. When the execution result is uncertain (e.g., due to network timeout or receiving an ambiguous error code), the system does not simply retry but enters a dedicated "three-branch fault handling logic." The core idea of this logic is "locking and reconciliation." First, the execution qualification Q100 of the operation is locked in a "pending confirmation" state to prevent any further operations. Then, after the system recovers, the reconciliation component of the management control platform uses various methods (such as querying the logs of the underlying controller and directly checking the actual status of the object) to finally determine the true result of the operation. After confirming the actual execution status of the operation, the final state closure is completed. Although this mechanism is more complex than simple timeout retries, it avoids serious errors or irreversible changes in system state that may result from blindly retrying in an uncertain state, such as repeatedly creating computing resources or repeatedly executing payment operations.
[0066] like Figure 5 As shown, this embodiment also defines a security boundary when the management control platform is disconnected. When the system transitions from the "DMS normal operation" state to the "DMS disconnection" state due to a control link interruption, all execution components immediately activate the security boundary policy. This means they will refuse to execute any new, unauthorized control requests. However, for legitimate sessions established before the disconnection, their business data streams can continue to be transmitted, ensuring business continuity. When DMS is restored, the system enters a "reconciliation process" to check for any inconsistencies in state during the disconnection period. Only after reconciliation is completed does the system return to the "DMS normal operation" state. This design ensures security in extreme situations while reducing the impact on normal business operations.
[0067] In a complex scenario, suppose an administrator needs to perform a high-risk operation: delete a core virtual machine in a production environment.
[0068] First, the administrator submits a deletion request to the management control platform. After verifying the administrator's identity and permissions, the platform approves the request. At this point, the platform does not directly issue a simple deletion command, but instead creates an authorized operation encapsulation. This encapsulation first contains a request commitment calculated based on the operation "delete virtual machine VM-01"; second, it contains the expected preconditions for the operation, such as the expected preconditions or version V31 being "shutdown"; third, it contains a globally unique single-execution identifier; and finally, it is bound to the aforementioned three-branch fault handling rules.
[0069] The authorized operation encapsulation is sent to the compute-side execution component. Upon receipt, the execution component begins a series of rigorous "pre-execution" verifications: First, it verifies the signature and integrity of the encapsulation itself; second, it compares the actual received deletion request with the request commitment in the encapsulation to ensure that the operation semantics have not been tampered with; third, it queries and verifies the current state of virtual machine VM-01 to confirm that it is indeed "shut down" and its version is V31. After all these verifications pass, before calling the underlying virtualization interface to execute the deletion operation, the execution component atomically acquires exclusive execution eligibility using a single-execution identifier. Only after successfully acquiring eligibility does it issue the deletion command.
[0070] Suppose that after the execution component issues a delete command to the underlying virtualization platform, the network suddenly interrupts, causing the execution component to fail to receive any return results. At this time, the execution component does not know whether the virtual machine has been successfully deleted. According to the bound fault handling rules, it will immediately set the execution eligibility status of the operation to "pending confirmation," report an indeterminate status event, and then remain silent without retrying. Later, when the reconciliation component of the management control platform runs, it will discover this "pending confirmation" operation. The reconciliation component will directly query the underlying virtualization platform and find that the virtual machine VM-01 no longer exists. Therefore, the reconciliation component confirms the final result of the operation as "successful" and updates the execution eligibility status to "consumed," thus completing the closed loop of the entire operation. Through the synergistic effect of this series of mechanisms, this invention ensures that even high-risk operations can be executed securely, reliably, and uniquely in complex distributed and unreliable network environments.
[0071] The technical solution of this invention can be widely applied to cloud computing environments with high requirements for security, stability, and auditability, especially private clouds, hybrid clouds, and cloud platforms in key industries such as finance and government. By implementing this invention, a trusted cloud infrastructure control plane can be built, ensuring that all infrastructure state changes originate from legitimate authorization, the execution process is precise and controllable, and the execution results are clear and traceable, thereby improving the overall governance level and security capabilities of the cloud platform. Furthermore, by separating control execution functions from business processing functions, this invention helps maintain the performance of upper-layer business applications while achieving control. For example, in a Virtual Desktop Infrastructure (VDI) scenario, the establishment of user sessions, resource adjustments, and snapshot creation must all be performed through the control loop of this invention. Once a session is established, real-time data streams such as the user's mouse, keyboard, and video can be efficiently transmitted within the established secure channel without going through the management control platform, thus ensuring low-latency transmission of user session data.
[0072] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0073] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A non-bypassable cloud computing infrastructure control system, characterized in that, include: The management and control platform and at least one execution component distributed on at least one of the terminal side, the isolation device side, and the computing side; The management and control platform is used to: receive and respond to a request containing a requested state change; obtain object relationship information and state information related to the target infrastructure object and the requested state change; determine the target control execution function, the target infrastructure object, and the action to be executed based on the object relationship information and state information; establish a legitimate control relationship and form a control requirement that includes at least the target control execution function, the target infrastructure object identifier, the action to be executed, and associated information; the associated information is used to enable the control requirement to correspond to the execution result. The at least one execution component together provides control execution functions and business processing functions for handling display and input interaction information, wherein the control execution functions and the business processing functions are logically separate. The target control execution function is configured to: verify whether the control request belongs to the legitimate control relationship before changing the state of the target infrastructure object; control requests that fail verification are not executed; execute the verified control requests and return an execution result containing the associated information; The business processing function is used to process display and input interaction information after the legal control relationship is established, and is not used as a direct entry point for infrastructure status changes; The management and control platform is also used to confirm or update the status of the target infrastructure object based on the associated information corresponding to the control requirements and the execution results, and to decide on subsequent actions based on the execution results.
2. The non-bypassable cloud computing infrastructure control system according to claim 1, characterized in that, The management and control platform is also used to: process the request based on deterministic normalization rules to form a request commitment, and include the request commitment in the control requirements; The target control execution function is further configured to: verify whether the action to be executed contained in the control request is consistent with the request commitment before executing the control request.
3. The non-bypassable cloud computing infrastructure control system according to claim 1, characterized in that, The control requirement includes a single execution identifier; The target control execution function is also configured to exclusively acquire execution eligibility using atomic operations based on the single execution identifier before generating external state changes in the infrastructure.
4. The non-bypassable cloud computing infrastructure control system according to claim 1, characterized in that, The control requirements include the expected prior state or state version of the target infrastructure object; The target control execution function is further configured to: before execution, check whether the current state of the target infrastructure object meets the expected prerequisite state and whether its current version meets the state version.
5. The non-bypassable cloud computing infrastructure control system according to claim 1, characterized in that, The control requirements are bound to fault handling rules, which distinguish between three boundary cases: "no external change has occurred", "indivisible steps have started", and "uncertain result" caused by execution timeout or return of a specific status code. The rules stipulate that when the result is uncertain, the operation should be locked and reconciled instead of automatically replaying.
6. The non-bypassable cloud computing infrastructure control system according to claim 1, characterized in that, When the management and control platform is disconnected, the execution component is configured to refuse to execute any control requests that do not originate from the management and control platform.
7. A non-bypassable cloud computing infrastructure control method, characterized in that, The method is executed by a system including a management control platform and one or more execution components, the method comprising: The management and control platform receives a request containing the requested state change, obtains object relationship information and state information related to the target infrastructure object and the requested state change, determines the target control execution function, the target infrastructure object and the action to be executed based on the information, establishes a legitimate control relationship, and forms a control requirement that includes at least the target control execution function, the target infrastructure object, the action to be executed and the associated information. Before changing the state of the target infrastructure object, the corresponding target control execution function in one or more execution components verifies whether the control request belongs to the legal control relationship. Control requests that fail verification are not executed. The verified control requests are executed, and an execution result containing the associated information is returned. The control execution function provided by the execution component is separate from the business processing function logic used to process display and input interaction information. The business processing function processes display and input interaction information after the legal control relationship is established, and does not serve as a direct call entry point for infrastructure status changes. The management and control platform confirms or updates the status of the target infrastructure object based on the associated information corresponding to the control requirements and the execution results, and decides on subsequent actions based on the execution results.
8. A management and control platform for a non-bypassable cloud computing infrastructure control system, characterized in that, The management and control platform includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the following: Receive a request containing the requested state change, and obtain object relationship information and state information related to the target infrastructure object and the requested state change. Based on the information, determine the target control execution function, the target infrastructure object and the action to be executed, establish a legitimate control relationship, and form a control requirement that includes at least the target control execution function, the target infrastructure object, the action to be executed and related information. Receive an execution result containing the aforementioned associated information; Based on the associated information corresponding to the control requirements and the execution results, the status of the target infrastructure object is confirmed or updated, and subsequent actions are determined based on the execution results.