A method and system for dynamic deployment of internet of things applications based on a zero trust architecture

Abstract

This invention relates to the field of computer software deployment and information security technology, and discloses a method and system for dynamic deployment of IoT applications based on a zero-trust architecture. By receiving IoT application deployment requests and parsing the application identifier and target deployment object, the system collects the access trust status of the target deployment object during the deployment task access phase. This status is then encapsulated into an access trust status snapshot based on field values, collection time, and effective window, and a deployment token bound to this snapshot is generated. At key execution nodes before application package distribution, installation, configuration injection, or activation, the execution trust status is re-collected. The execution trust status is compared with the access trust status snapshot to obtain a difference determination result, and based on this, control actions such as continuing deployment, pausing reassessment, regenerating snapshots and tokens, stopping deployment, and abnormal rollback cleanup are executed. This reduces the risk of untrusted deployment caused by delayed use of access trust judgment.

Description

Technical Field

[0001] This invention belongs to the field of computer software deployment and information security technology, specifically relating to a method and system for dynamic deployment of Internet of Things applications based on a zero-trust architecture. Background Technology

[0002] As the collaborative deployment of IoT terminal devices, edge computing nodes, and cloud management platforms becomes increasingly common, IoT applications typically require remote distribution, updates, migration, or redeployment based on device access status, changes in business scenarios, and the capacity of edge nodes. In such deployments, there are strong correlations between application packages, target devices, edge nodes, operating environments, and access permissions. The deployment process not only needs to ensure successful application installation and startup but also that the target devices or edge nodes still meet the corresponding security and operational requirements during the deployment execution phase. In a distributed, dynamic, and heterogeneous IoT networking environment, the state of deployed objects may change at different points in time, thus posing corresponding engineering requirements for deployment control logic.

[0003] Existing technologies typically deploy IoT applications following this process: First, upon receiving a deployment request, the deployment platform or orchestration service authenticates the requester and the target object, for example, based on device certificates, unique device identifiers, account permissions, or access tokens. Second, it verifies the integrity and legitimacy of the application package to be deployed, for example, based on digital signatures, hash values, or version identifiers. Third, it checks the resource status of the target terminal device or edge node, such as checking CPU usage, memory availability, storage space, and network connectivity, to determine if the target terminal device or edge node meets the deployment requirements. Fourth, after successful verification, the deployment agent or container orchestration component distributes the application package to the target object and sequentially completes installation, configuration injection, and service startup operations. Fifth, after deployment, the target object reports the deployment result to the deployment platform through logs, task status codes, or heartbeat information, and access control policies restrict the range of resources that the application can access after deployment.

[0004] On the one hand, the results of identity verification, application package verification, and resource status verification generated during the deployment task initiation phase of the aforementioned existing technologies are usually used as static bases for the entire subsequent deployment execution process. In scenarios such as deployment task queuing, cross-gateway forwarding, and time intervals between application installation and activation, state changes can occur between the deployment task initiation time and the actual execution time. On the other hand, the feedback loop of existing technologies usually focuses on whether the deployment task is successfully executed. However, before the application is actually delivered, installed, or activated, the current state of the target object is usually not re-compared. When the target object experiences changes in device certificate status, firmware or runtime environment updates, security policy version changes, network location switching, or rapid changes in runtime load after access verification, the deployment system usually continues to execute based on the delayed access judgment results. This could lead to the possibility that the application is deployed to a target object that no longer meets the trust conditions, affecting the controllability of the deployment results. Furthermore, existing solutions typically handle deployment anomalies by logging the failure, displaying an error message, or performing a simple retry. They lack systematic cleanup and rollback processes for intermediate artifacts generated during deployment, such as temporary credentials, temporary configurations, application files that have been distributed but not yet activated, and temporary access permissions granted. In scenarios where deployment is aborted due to state misalignment, deployment object switching, expired deployment tokens, or revoked security policy versions, residual permissions, configuration caches, application files, and subsequent duplicate deployment conflicts may occur, impacting the overall trustworthiness of the deployment system.

[0005] In summary, during the dynamic deployment of IoT applications, there is a time misalignment between the trusted judgment results formed during the deployment task initiation phase and the current trusted state of the target device or edge node when the application is actually delivered, installed, and activated. This causes the deployment control to continuously execute the deployment based on the outdated trusted judgment results. Summary of the Invention

[0006] To solve the above-mentioned technical problems, the present invention is achieved through the following technical solution: Firstly, a dynamic deployment method for IoT applications based on a zero-trust architecture is proposed, including the following steps: Receive and parse deployment requests from IoT applications to obtain application identifiers and target deployment objects; During the deployment task access phase, the access trust status of the target deployment object is collected; The access trusted state is structured and encapsulated according to field values, collection time, and valid window, and a snapshot summary value is generated to obtain an access trusted state snapshot; a deployment token is generated and bound to the access trusted state snapshot; the deployment token includes application identifier, target deployment object identifier, snapshot summary value, and token valid window; At at least one critical execution node before application package distribution, installation, configuration injection taking effect, and activation, and at least before activation, the current trusted state of the target deployment object is re-collected to obtain the execution trusted state. The execution trusted state is compared with the admission trusted state snapshot to obtain the difference determination result; the difference determination result is one of the following: no difference, slight difference, re-evaluable difference, and blocking difference; Based on the difference determination result, the corresponding deployment control actions are executed: when the difference determination result is no difference, deployment continues; when the difference determination result is a slight difference, deployment is paused and a policy reassessment is triggered, and the decision to continue or stop deployment is made based on the result of the policy reassessment; when the difference determination result is a reassessable difference, the access trust status of the target deployment object is re-collected, and an access trust status snapshot and deployment token are regenerated; when the difference determination result is a blocking difference, deployment is stopped and an abnormal rollback and cleanup are performed.

[0007] Secondly, a dynamic deployment system for IoT applications based on a zero-trust architecture is proposed, including: The deployment request receiving module is used to receive deployment requests from IoT applications; The target object parsing module, connected to the deployment request receiving module, is used to parse the deployment request to obtain the application identifier and the target deployment object; The access trust status acquisition module is connected to the target object parsing module and is used to collect the access trust status of the target deployment object during the deployment task access phase. The access trust status includes a first type of trust field and a second type of trust field. The first type of trust field includes at least one of the following: device identity status, device certificate status, security policy version, and target object risk level. The second type of trust field includes at least one of the following: node running load, network location, firmware version, and running environment version. The access trust status snapshot generation module is connected to the access trust status acquisition module. It is used to encapsulate the access trust status in a structured way according to field values, acquisition time and effective window and generate snapshot summary values ​​to obtain access trust status snapshots. The deployment token generation module is connected to the admission trusted state snapshot generation module and is used to generate deployment tokens that are bound to the admission trusted state snapshot. The deployment token includes the application identifier, the identifier of the target deployment object, the snapshot digest value, and the token validity window. The application deployment execution module, connected to the deployment token generation module, is used to perform application package distribution, installation, configuration injection, and activation. The trusted state verification module is connected to the application deployment execution module. It is used to re-collect the current trusted state of the target deployment object at at least one of the key execution nodes before the application package is distributed, before installation, before configuration injection takes effect, and before activation, and at least before activation, to obtain the execution trusted state. The state difference determination module is connected to the admission trusted state snapshot generation module and the execution trusted state verification module, respectively. It is used to compare the execution trusted state with the admission trusted state snapshot to obtain the difference determination result. The abnormal rollback and cleanup module is used to delete inactive application package files on the target deployment object, revoke deployment tokens, reclaim temporary access permissions obtained by the target deployment object during the deployment process, and clean up temporary configuration cache when the deployment is stopped. The deployment control decision module is connected to the state difference judgment module, application deployment execution module, anomaly rollback and cleanup module, access trusted state acquisition module, access trusted state snapshot generation module, and deployment token generation module, respectively. It is used to control the application deployment execution module to continue deployment or suspend deployment and trigger policy re-evaluation based on the difference judgment result, or to control the access trusted state acquisition module, access trusted state snapshot generation module, and deployment token generation module to regenerate the access trusted state snapshot and deployment token, or to control the application deployment execution module to stop deployment and call the anomaly rollback and cleanup module to perform anomaly rollback and cleanup.

[0008] Compared with existing technologies, this invention has the following advantages and beneficial effects: By collecting the access trust status of the target deployment object during the deployment access phase and encapsulating it into an access trust status snapshot containing field values, collection time, effective window, and snapshot summary value, the access judgment in the IoT application deployment process is no longer just a one-time verification conclusion, but forms a storable, traceable, and comparable state benchmark. Based on this, the deployment token is bound to the application identifier, the target deployment object identifier, and the snapshot summary value, and the applicable duration of this state benchmark is limited by the token's effective window. This establishes a clear correspondence between the deployment task, the target deployment object, and the access trust status, preventing access judgments from being incorrectly used for other deployment objects or unconditionally continued after deployment delays. After entering the execution phase, such as application package distribution, installation, configuration injection, or activation, the system re-collects the execution trust status of the target deployment object and compares it with the access trust status snapshot, thereby identifying changes in identity, policy, operating environment, or risk status that occur after access but before actual execution. Based on the comparison results, the state differences are further categorized into no difference, slight difference, reassessable difference, and blocking difference. Corresponding actions are taken: continue deployment, pause deployment and trigger policy reassessment, regenerate the access trust state snapshot and deployment token, or stop deployment and trigger anomaly rollback and cleanup. This transforms deployment control from "using the access results" to "dynamically adjusting based on the current trust state at the execution stage." This reduces the risk of IoT applications being deployed to targets that no longer meet the trust conditions. In the event of blocking, failure, or rollback, cleaning up incomplete or inactive application package files, revoking deployment tokens, recovering temporary access permissions, and clearing temporary configuration caches further reduces permission residues, configuration residues, and duplicate deployment conflicts, improving the security, controllability, and closed-loop consistency of the dynamic deployment process. Attached Figure Description

[0009] The accompanying drawings, which are included to provide a further understanding of embodiments of the invention and form part of this application, do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the overall structure of the IoT application dynamic deployment system based on zero-trust architecture provided in Embodiment 1 of the present invention.

[0010] Figure 2 This is a timing diagram of the process for performing trusted state verification and state difference determination provided in Embodiment 1 of the present invention.

[0011] The attached diagram shows the markings and corresponding component names: 10-Deployment Request Receiving Module; 20-Target Object Parsing Module; 30-Admission Trusted State Acquisition Module; 40-Admission Trusted State Snapshot Generation Module; 50-Deployment Token Generation Module; 60-Application Deployment Execution Module; 70-Execution Trusted State Verification Module; 80-State Difference Judgment Module; 90-Deployment Control Decision Module; 100-Abnormal Rollback and Cleanup Module; 110-Policy Management Module; 120-Audit Log Module; 210-Target Terminal Device; 220-Edge Node; 230-Gateway Node; 310-Admission Trusted State; 320-Admission Trusted State Snapshot; 330-Deployment Token; 340-Execution Trusted State; 350-Difference Judgment Result; 360-Deployment Control Action; 370-Audit Log. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. The illustrative embodiments and descriptions of this invention are for illustrative purposes only and are not intended to limit the invention. The embodiments described below are some, but not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0013] In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that these specific details are not necessary to practice the invention. In other embodiments, well-known structures, materials, or methods are not specifically described to avoid obscuring the invention. Unless otherwise specified, the materials, instruments, and reagents used in the following embodiments are commercially available. Unless otherwise specified, the techniques used in the embodiments are conventional methods well known to those skilled in the art.

[0014] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0015] Example 1: In the dynamic deployment scenario of IoT applications, the trust judgment result formed during the deployment task initiation phase may be misaligned with the current trust status of the target deployment object when the application is actually distributed, installed, and activated. That is, there is a time sequence misalignment between "trust at the time of admission" and "trust at the time of execution", which causes the deployment control to continue to execute the deployment based on the already lagging trust judgment result.

[0016] To address the aforementioned technical issues, this embodiment provides a dynamic deployment system for IoT applications based on a zero-trust architecture. The system introduces a comprehensive technical path within the zero-trust architecture during the dynamic deployment of IoT applications, encompassing "two-stage trusted state acquisition, state snapshot binding, execution phase verification, difference-based deployment control, and anomaly-closed-loop rollback." This expands the previously one-time trusted judgment during the deployment admission phase to two stages of trusted state acquisition and comparison. The results of state difference judgments are mapped to deployment control actions, enabling the deployment system to make control decisions commensurate with the degree of difference based on the current trusted state when executing deployment actions. Here, zero-trust architecture refers to a security control framework that does not default to trusting any device, node, network location, or deployment request during IoT application deployment, but instead verifies and controls based on identity, state, policy, and context. IoT applications refer to software applications, service instances, or application components deployed on IoT terminal devices, edge nodes, gateway nodes, or platform sides to perform data acquisition, data processing, device control, protocol conversion, or edge computing tasks. Dynamic deployment refers to the process by which IoT applications are distributed, installed, configured, activated, migrated, updated, or rolled back based on device state, node state, policy changes, or business triggering conditions.

[0017] Based on the above overall technical path, the dynamic deployment system for IoT applications based on a zero-trust architecture includes: Figure 1 The system includes a deployment request receiving module 10, a target object parsing module 20, an access trusted state acquisition module 30, an access trusted state snapshot generation module 40, a deployment token generation module 50, an application deployment execution module 60, an execution trusted state verification module 70, a state difference judgment module 80, a deployment control decision module 90, an anomaly rollback and cleanup module 100, a policy management module 110, and an audit log module 120. Furthermore, the IoT application dynamic deployment system based on a zero-trust architecture interacts with the target terminal device 210, edge node 220, and gateway node 230 through corresponding communication interfaces to execute the deployment of IoT applications.

[0018] Continue to refer to Figure 1In the data flow direction, the deployment request receiving module 10 and the target object parsing module 20 are serially connected. The output of the target object parsing module 20 is sent to the admission trusted state acquisition module 30 and the policy management module 110, respectively. The admission trusted state 310 output by the admission trusted state acquisition module 30 is sent to the admission trusted state snapshot generation module 40. The admission trusted state snapshot 320 output by the admission trusted state snapshot generation module 40 is sent to the deployment token generation module 50 and the state difference determination module 80. The deployment token 330 output by the deployment token generation module 50 is sent to the application deployment execution module 60. The application deployment... At key execution nodes, the execution module 60 triggers the execution trusted state verification module 70. The execution trusted state 340 output by the execution trusted state verification module 70 is sent to the state difference judgment module 80. The difference judgment result 350 output by the state difference judgment module 80 is sent to the deployment control decision module 90. The deployment control decision module 90 outputs deployment control action 360 based on the difference judgment result 350, as a reverse control over the application deployment execution module 60, the access trusted state acquisition module 30, the access trusted state snapshot generation module 40, the deployment token generation module 50, and the exception rollback and cleanup module 100. In the control flow direction, the policy management module 110 provides rules to the admission trusted state acquisition module 30, the execution trusted state verification module 70, the state difference judgment module 80, and the deployment control decision module 90, respectively; the audit record module 120 is connected to the deployment request receiving module 10, the admission trusted state snapshot generation module 40, the execution trusted state verification module 70, the state difference judgment module 80, the deployment control decision module 90, and the abnormal rollback and cleanup module 100, and records the audit record 370 throughout the entire lifecycle.

[0019] 1. Deployment request receiving module 10 The deployment request receiving module 10 is used to receive deployment requests from IoT applications. The deployment request includes: application identifier, application version, target node identifier, target device identifier, deployment type, expected execution time, deployment policy identifier, and request initiator identifier. In one embodiment, the deployment request receiving module 10 is an interface unit for an operations and maintenance platform, orchestration service, or edge management platform; in another embodiment, the deployment request receiving module 10 is a message queue-based deployment request subscription unit.

[0020] The deployment request receiving module 10 is serially connected to the target object parsing module 20. After receiving the deployment request, the module 10 transmits the deployment request to the target object parsing module 20.

[0021] In this embodiment, the deployment request receiving module 10 is set up to standardize external deployment requirements into inputs that can be used by subsequent modules.

[0022] 2. Target Object Parsing Module 20 The target object parsing module 20 is connected to the deployment request receiving module 10 and is used to parse the deployment request to obtain the application identifier and the target deployment object. The target deployment object refers to the terminal device, edge node, gateway node, edge cluster, or container runtime environment in the edge cluster that is intended to host the IoT application, including: terminal device, edge node, gateway node, or container runtime environment in the edge cluster.

[0023] The target object resolution module 20 identifies the object type and network region of the target deployment object by comparing the target node identifier, target device identifier, and registered asset list. The target object resolution module 20 outputs the resolution results to the access trust status acquisition module 30, which collects the access trust status 310. Simultaneously, the target object resolution module 20 outputs the resolution results to the policy management module 110, which retrieves the deployment policy matching the current deployment task. The resolution results include: application identifier, the object type and network region of the target deployment object, and the network region of the target deployment object.

[0024] In this embodiment, the target object parsing module 20 is set up to map the field information in the deployment request to the specific target deployment object and policy context, so that subsequent modules can perform subsequent actions based on the clear object type and policy context.

[0025] 3. Access Trust Status Acquisition Module 30 The access trust status acquisition module 30 is connected to the target object parsing module 20 and is used to acquire the access trust status 310 of the target deployment object during the deployment task access phase. The access trust status 310 refers to the status of the target deployment object acquired during the deployment task initiation or access phase, used to determine whether the target deployment object meets the basic conditions for accepting the deployment task. It includes: a first type of trust field and a second type of trust field. The first type of trust field reflects the trust attributes of the target deployment object at the identity, credentials, and security policy levels, including at least one of: device identity status, device certificate status, security policy version, and target object risk level. The second type of trust field reflects the dynamic attributes of the target deployment object at the runtime level, including at least one of: node runtime load, network location, firmware version, and runtime environment version. The first and second types of trust fields together constitute a multi-dimensional basis for access trust judgment.

[0026] The access trusted state acquisition module 30 is implemented collaboratively by two or more of the following: device status acquisition agent, edge node monitoring agent, security context interface, identity authentication interface, and policy query interface. Specifically, device identity status and device certificate status can be obtained through the identity authentication interface and certificate service; security policy version and target object risk level can be obtained from the policy management module 110 through the policy query interface; node operating load can be obtained by the edge node monitoring agent based on runtime indicators such as CPU usage, memory usage, and storage usage; network location can be obtained from the reported network domain, subnet, or geographical region through the network management interface or the target deployment object; firmware version and runtime environment version can be obtained by the device status acquisition agent reading the runtime environment metadata of the target deployment object. The access trusted state acquisition module 30 outputs the acquired access trusted state 310 to the access trusted state snapshot generation module 40.

[0027] It should be noted that this system also performs admission rule judgments on the fields of the admission trusted state 310. Specifically, if any field in the admission trusted state 310 fails the corresponding admission rule, the deployment process terminates; otherwise, the system continues to generate an admission trusted state snapshot. The admission rule judgments include: field consistency judgment, which determines whether the field corresponding to the execution trusted state is consistent with the field corresponding to the admission trusted state snapshot; time validity judgment, which determines whether the current time falls within the valid window of the deployment token; policy version consistency judgment, which determines whether the policy version in the execution phase is consistent with the policy version in the admission phase. If they are inconsistent, the system further determines whether it is a compatible update; risk level change judgment, which determines whether the risk level of the target deployment object in the execution phase exceeds the maximum value allowed by the policy; and comprehensive classification of difference levels, which classifies the difference judgment result 350 into one of the following categories based on the above four judgment results: no difference, slight difference, reassessable difference, and blocking difference.

[0028] 4. Admission Trusted State Snapshot Generation Module 40 The access trusted state snapshot generation module 40 is connected to the access trusted state acquisition module 30. It is used to structurally encapsulate the access trusted state 310 according to field values, acquisition time, and effective window, and generate a snapshot digest value based on these fields, resulting in the access trusted state snapshot 320. The access trusted state snapshot 320 refers to the state record formed after the access trusted state is encapsulated by fielding, temporalization, and digestion. It is used to compare with the acquired execution trusted state during the execution phase. It includes: target object identifier, application identifier, device identity status, device certificate status, node operating load, network location, firmware version, operating environment version, security policy version, target object risk level, acquisition time, effective window, and snapshot digest value. The execution trusted state refers to the current state of the target deployed object, which is re-acquired during the actual application delivery, installation, configuration injection, or activation phases. The snapshot digest value is a fixed-length verification value obtained by digesting and encoding the set of fields involved in the encapsulation in the access trusted state snapshot 320. The snapshot digest value is used to characterize the overall state of the field content of the access trusted state snapshot 320 at the time of its generation, and is used to verify whether the access trusted state snapshot 320 has experienced field missingness, field value changes, order disturbances, or illegal tampering during the generation, execution phase review, and auditing of the deployment token 330. The snapshot digest value itself is not used to restore the specific field content in the access trusted state, but rather serves as an integrity identifier and binding identifier for the access trusted state snapshot 320.

[0029] Specifically, the structured encapsulation organizes each trusted field into field name-field value pairs, along with the collection time for each field. The effective window is provided by the policy management module 110, which constrains the applicable time range of the access trusted state snapshot 320. The snapshot digest value is obtained by performing calculations on the structured encapsulated field set using conventional cryptographic digest algorithms in the field, with the specific digest algorithm used meeting the integrity verification requirements. Specifically, when generating the snapshot digest value, the access trusted state snapshot generation module 40 first standardizes and arranges the fields such as target object identifier, application identifier, device identity status, device certificate status, node operating load, network location, firmware version, operating environment version, security policy version, target object risk level, collection time, and effective window according to a preset field order, and encodes the arranged field names, field values, and field separators into data to be digested. Subsequently, a conventional cryptographic digest algorithm in the field is used to perform a digest operation on the data to be digested to obtain the snapshot digest value. The cryptographic digest algorithm can be a one-way digest algorithm that meets the integrity verification requirements, such as SM3, SHA-256, or other digest algorithms with collision resistance. Since the improvement of this invention focuses on the binding between the admission trusted state snapshot and the deployment token and the state verification control during the execution phase, rather than the specific digest algorithm itself, the specific type of digest algorithm used is not limited.

[0030] The access trusted state snapshot 320 is output to the deployment token generation module 50 and the state difference determination module 80.

[0031] The admission trusted state snapshot 320 is obtained through the admission trusted state snapshot generation module 40. The purpose is to transform the instantaneous admission verification conclusion into a state record that can be saved, compared, traced, and verified in integrity, so that subsequent stages can compare the admission trusted state snapshot 320 with the trusted state of the execution stage.

[0032] 5. Deployment Token Generation Module 50 The deployment token generation module 50 is connected to the access trust state snapshot generation module 40 and is used to generate a deployment token 330 bound to the access trust state snapshot 320. The deployment token 330 is an execution credential generated by the deployment token generation module, bound to the access trust state snapshot, and used to prove the binding relationship between the deployment task, the target deployment object, and the access trust judgment during the deployment execution phase. It includes: application identifier, target deployment object identifier, snapshot digest value, and token validity window. The token validity window refers to the time range within which the deployment token is allowed to be used to execute deployment; after this range, the system will no longer directly execute the deployment, but will instead re-collect the access trust state or regenerate the deployment token. The token validity window is uniformly managed by the policy management module 110 according to the application risk level, target object type, network environment, and deployment policy. For example, the token validity window corresponding to high-risk applications or high-privilege applications is shorter than that of ordinary applications; the token validity window corresponding to deployment scenarios with unstable network environments is shorter than that of stable scenarios; the specific value is configured in the range of minutes to hours according to risk level, and the specific value is determined by the deployment policy.

[0033] In addition, deployment token 330 also includes token generation time and policy version identifier.

[0034] The deployment token generation module 50 achieves a strong binding between the deployment task, the target deployment object, and the admission trusted state snapshot 320 by embedding the snapshot digest value into the deployment token 330. It restricts the applicable time range of the deployment token 330 through a token validity window, ensuring that the deployment token 330 can only be used to execute subsequent deployment actions within the defined validity window. The deployment token generation module 50 can be a standalone token service or a token unit integrated into the deployment controller. The generated deployment token 330 is output to the application deployment execution module 60.

[0035] The purpose of setting the deployment token 330 by the deployment token generation module 50 is to achieve a strong binding between the "deployment task, target deployment object, and access trust status snapshot" by embedding the snapshot digest value into the token; and to reduce the possibility that the access trust judgment will still be used after a long delay by constraining the applicable time range of the deployment token 330 through the token validity window.

[0036] 6. Application Deployment and Execution Module 60 The application deployment execution module 60 is connected to the deployment token generation module 50 and is used to perform application package distribution, installation, configuration injection and activation, as well as application package retrieval, signature verification, service startup and running status reporting, according to the control results of the deployment control decision module 90. The application deployment execution module 60 is implemented by at least one of the following: deployment agent, container orchestration component, edge node application manager or terminal application installation service.

[0037] At key execution nodes—before application package distribution, installation, configuration injection, and activation—the application deployment execution module 60 triggers the execution trust status verification module 70 to perform execution trust status verification. Specifically, the application deployment execution module 60 generates an execution node trigger signal at the entry point of each key execution node, and the execution node trigger signal is sent to the execution trust status verification module 70. After receiving the execution node trigger signal, the execution trust status verification module 70 re-collects the current trust status of the target deployment object.

[0038] It should be noted that: 1. Before the application package is distributed refers to the moment when the application deployment execution module 60 is about to transmit the application package to the target deployment object but has not yet actually transmitted it; before installation refers to the moment when the application package has been distributed but has not yet started installation on the target deployment object; before configuration injection takes effect refers to the moment when the application installation has been completed but the configuration items have not yet been injected into the runtime environment; before activation refers to the moment when configuration injection has been completed but the application has not yet started and entered the runtime state. 2. The application deployment execution module 60 is the actual execution entity corresponding to the four execution actions of application package distribution, installation, configuration injection, and activation during system execution. The subsequent actions of the application deployment execution module 60 are controlled by the deployment control decision module 90 based on the difference judgment result 350. Specifically, the application deployment execution module 60 receives "continue deployment", "pause deployment", or "stop deployment" instructions from the deployment control decision module 90. When it receives the "continue deployment" instruction, it enters the next execution action that has not yet been completed in the application package distribution, installation, configuration injection, or activation. When it receives the "pause deployment" instruction, it suspends the current execution action and waits for policy re-evaluation or a new deployment token. When it receives the "stop deployment" instruction, it terminates the subsequent execution action and hands it over to the exception rollback and cleanup module 100 for exception rollback and cleanup.

[0039] 7. Execute the trusted status verification module 70 The execution trusted state verification module 70 is connected to the application deployment execution module 60. It is used to re-collect the current trusted state of the target deployment object at at least one key execution node before application package distribution, installation, configuration injection taking effect and activation, and at least before activation, to form an execution trusted state 340. The field composition in the execution trusted state 340 corresponds to the field composition in the admission trusted state 310, so as to perform a field consistency comparison with the admission trusted state snapshot 320.

[0040] It should be noted that in the dynamic deployment scenario of IoT applications, application activation indicates that the target deployment object will enter the running state. The trust status of the target deployment object at this moment is more sensitive than that of other execution nodes. Therefore, in this embodiment, a verification is performed at least once before application activation to avoid the application being started in an untrusted environment after the state change.

[0041] The execution trusted state verification module 70 outputs the generated execution trusted state 340 to the state difference determination module 80.

[0042] 8. Status Difference Determination Module 80 The state difference determination module 80 is connected to the admission trusted state snapshot generation module 40 and the execution trusted state verification module 70, respectively, and is used to compare the execution trusted state 340 with the admission trusted state snapshot 320 to obtain the difference determination result 350.

[0043] The state difference determination module 80 compares the execution trusted state 340 with the admission trusted state snapshot 320 based on field consistency, time validity, policy version consistency, and risk level change. Specifically, field consistency determination checks whether the corresponding field values ​​in the execution trusted state 340 and the admission trusted state snapshot 320 are consistent. Specifically, it checks whether the execution trusted state 340 and the admission trusted state snapshot 320 are consistent in at least two of the following: target object identity, network location, runtime load, firmware version, runtime environment version, security policy version, certificate status, risk level, and token validity window. Time validity determination checks whether the current time falls within the token validity window of the deployment token 330. Policy version consistency determination checks whether the policy version in the execution phase is consistent with the policy version in the admission phase; if inconsistent, it further checks whether it is a compatible update. Risk level change determination checks whether the risk level of the target deployment object in the execution phase exceeds the maximum value allowed by the policy.

[0044] Based on the above judgment results, the status difference judgment module 80 classifies the difference judgment result 350 into one of the following: no difference, slight difference, reassessable difference, and blocking difference. Specifically: when all field consistency comparison items are consistent, the time is valid, the policy version is consistent, and the risk level remains unchanged, it is judged as no difference; when a dynamically running field (such as node running load) in the field consistency comparison items changes but does not exceed the policy limit, it is judged as a slight difference; when the policy version undergoes a compatible update or the risk level changes within the allowable range, it is judged as a reassessable difference; when the target object identity is inconsistent, the device certificate is invalid, the security policy version is revoked, the network location exceeds the allowable range, or the risk level exceeds the policy limit, it is judged as a blocking difference.

[0045] Policy restrictions refer to a set of conditions determined by the policy management module 110 based on application risk level, target object type, network environment, and deployment policy, used to constrain whether the target deployment object is allowed to continue executing deployment tasks. These conditions include at least one of the following: node operating load threshold, risk level threshold, network location allowable range, device identity consistency requirements, device certificate validity requirements, security policy version requirements, deployment token validity window, and mapping rules between difference levels and deployment control actions. The node operating load threshold refers to the maximum percentage of operating load allowed for the target deployment object during the deployment execution phase. Node operating load is comprehensively evaluated based on indicators such as CPU usage, memory usage, and storage usage. When the collected operating load exceeds the policy restriction, it enters the blocking difference branch; when it approaches the node operating load threshold but does not exceed it, it enters the slight difference or reassessable difference branch. The principle for setting the node operating load threshold can be configured differently according to application type and node type. Furthermore, the technical meaning of the network location allowable range is the network domain, subnet, or geographical area that the target deployment object is allowed to be in during the deployment execution phase. In one implementation, the network location allowable range is determined by the allowed network domain, subnet, or geographical area in the deployment policy. The principles for setting the allowed network location range can be configured differently based on the tenant and application type.

[0046] The state difference determination module 80 outputs the difference determination result 350 to the deployment control decision module 90.

[0047] 9. Deploy the control decision module 90 The deployment control decision module 90 is connected to the state difference judgment module 80, the application deployment execution module 60, the anomaly rollback and cleanup module 100, the admission trusted state acquisition module 30, the admission trusted state snapshot generation module 40, and the deployment token generation module 50, respectively. It is used to execute corresponding deployment control actions 360 based on the difference judgment result 350. The deployment control action 360 is one of the following: continue deployment, pause deployment and trigger policy reassessment, regenerate the admission trusted state snapshot and deployment token, or stop deployment and trigger anomaly rollback and cleanup.

[0048] (1) When the difference determination result 350 is no difference, the deployment control decision module 90 controls the application deployment execution module 60 to continue deployment. Specifically, the deployment control decision module 90 outputs the "continue deployment" instruction to the application deployment execution module 60, and the application deployment execution module 60 enters the next execution action that has not yet been completed in the application package distribution, installation, configuration injection or activation; if all execution actions have been completed, the deployment task ends.

[0049] (2) When the difference determination result 350 is a minor difference, the deployment control decision module 90 controls the application deployment execution module 60 to pause deployment and trigger a policy reassessment. The policy reassessment is completed collaboratively by the deployment control decision module 90 and the policy management module 110. Specifically: the deployment control decision module 90 submits the difference determination result 350, the current execution trust status 340, and the admission trust status snapshot 320 to the policy management module 110. The policy management module 110 determines whether deployment is still allowed for the minor difference based on the current policy. If the policy reassessment result allows deployment, the deployment control decision module 90 controls the application deployment execution module 60 to continue deployment; if the policy reassessment result does not allow deployment, the deployment control decision module 90 controls the application deployment execution module 60 to stop deployment and calls the exception rollback and cleanup module 100 to perform exception rollback and cleanup.

[0050] (3) Determine whether to continue or stop deployment based on the results of the strategy reassessment. Specifically: when the difference determination result 350 is a reassessable difference, the deployment control decision module 90 controls the access trust status acquisition module 30 to re-acquire the access trust status of the target deployment object, controls the access trust status snapshot generation module 40 to regenerate the access trust status snapshot 320, and controls the deployment token generation module 50 to regenerate the deployment token 330; the new access trust status snapshot 320 and the new deployment token 330 replace the original access trust status snapshot and the original deployment token, and the deployment process re-enters the application deployment execution process based on the new access trust status snapshot 320 and the new deployment token 330.

[0051] (4) When the difference determination result 350 is a blocking difference, the deployment control decision module 90 controls the application deployment execution module 60 to stop deployment and calls the abnormal rollback and cleanup module 100 to perform abnormal rollback and cleanup.

[0052] 10. Abnormal rollback and cleanup module 100 The exception rollback and cleanup module 100 is used to perform exception rollback and cleanup when deployment is stopped. Exemplary exception rollback and cleanup include: deleting application package files that are not fully installed or activated on the target deployment object, revoking the deployment token 330, revoking temporary access permissions acquired by the target deployment object during deployment, cleaning up temporary configuration cache on the target deployment object, and recording the exception reason in the audit log 370.

[0053] Specifically, the exception rollback and cleanup module 100 deletes application package files that are not fully installed or activated on the target deployment object to prevent residual application files from being misused or exploited by external parties; revokes the deployment token 330 to prevent the deployment token from being used again for other deployment tasks; reclaims temporary access permissions obtained by the target deployment object during the deployment process to prevent permission residues; cleans up the temporary configuration cache on the target deployment object to prevent configuration residues from interfering with subsequent deployments; and records the reason for the exception in the audit log 370.

[0054] The exception rollback and cleanup module 100 issues application file cleanup instructions to the target deployment object through the deployment agent, revokes the deployment token 330 through the credential management interface, revoks granted temporary access permissions through the access control policy interface, cleans up the temporary configuration cache through the runtime environment management interface, and records the reason for the exception through the audit logging module 120. Furthermore, after completing the exception rollback and cleanup actions, the exception rollback and cleanup module 100 reports the exception type to the deployment control decision module 90 through the policy management module 110 to support subsequent policy reassessment.

[0055] 11. Strategy Management Module 110 The policy management module 110 is connected to the access trust status acquisition module 30, the execution trust status verification module 70, the status difference determination module 80, and the deployment control decision module 90, respectively. It is used to provide access rules to the access trust status acquisition module 30, verification rules to the execution trust status verification module 70, difference determination rules to the status difference determination module 80, and deployment control rules to the deployment control decision module 90.

[0056] The admission rules specify the fields, order, and accuracy for data collection in the trusted state 310. The verification rules specify the selection of key execution nodes, the scope of verification fields, and the handling of verification failures. The difference determination rules specify field consistency comparison items, threshold determination logic, difference level classification conditions, and policy version compatibility judgment logic. The deployment control rules specify the mapping relationship between difference levels and deployment control actions, the specific range of the token validity window, and the specific value of the risk level threshold. The risk level threshold is the maximum allowed risk level of the target deployment object at its current risk level. In one implementation, the risk level threshold corresponds to the maximum allowed target object risk level in the deployment strategy; when the risk level of the target deployment object exceeds this threshold, the difference blocking branch is entered. The principle for setting the risk level threshold can be configured differently according to application sensitivity.

[0057] 12. Audit Log Module 120 The audit log module 120 is connected to the deployment request receiving module 10, the access trusted state snapshot generation module 40, the execution trusted state review module 70, the state difference judgment module 80, the deployment control decision module 90, and the abnormal rollback and cleanup module 100, respectively. It is used to record deployment requests, access trusted state snapshots 320, execution trusted states 340, difference judgment results 350, deployment control actions 360, and operation times to form audit logs 370.

[0058] The audit logging module 120 is a log service, audit database, or immutable log component. The specific implementation of the audit logging module 120 is determined by meeting the audit traceability requirements. The audit logs 370 are read by the policy management module 110 to support subsequent policy reassessment and deployment rule adjustments.

[0059] 13. Module Deployment Mode In this embodiment, the functional modules of the system are deployed in a centralized manner. In this centralized deployment, each module, as a functional unit within the deployment controller, is centrally deployed in a central deployment controller or a multi-replica deployment controller cluster. Data and control flows between modules are completed through local function calls or inter-process communication. This centralized deployment is suitable for IoT deployment scenarios with strong centralized management requirements.

[0060] 14. Overall System Execution Flow The overall process of collaborative execution of various functional modules in this embodiment includes steps 1 to 7.

[0061] Step 1: Receive the deployment request from the IoT application and parse it to obtain the application identifier and target deployment object from the deployment request. This step is executed collaboratively by the deployment request receiving module 10 and the target object parsing module 20, and the output is the application identifier and target deployment object information, which is then passed to Step 2.

[0062] Step 2: During the deployment task admission phase, the admission trust status of the target deployment object is collected. This step is executed by the admission trust status collection module 30, and the output is the collected admission trust status 310, which is then passed to Step 3. In Step 2, the system also performs admission rule judgment on the fields of the collected admission trust status 310. If any field fails the corresponding admission rule, the deployment process terminates in the admission phase; otherwise, it continues to Step 3.

[0063] Step 3: The access trust status is structured and encapsulated according to field values, collection time, and effective window, and a snapshot summary value is generated to obtain an access trust status snapshot; and a deployment token bound to the access trust status snapshot is generated. This step is executed collaboratively by the access trust status snapshot generation module 40 and the deployment token generation module 50, and the output is the access trust status snapshot 320 and the deployment token 330, which are then passed to step 4.

[0064] Step 4: Re-collect the current trusted state of the target deployment object at at least one of the key execution nodes before application package distribution, installation, configuration injection taking effect, and activation to obtain the execution trusted state. This re-collection is performed at least once before activation. This step is triggered by the execution trusted state verification module 70 at the key execution node of the application deployment execution module 60, and the output is the execution trusted state 340, which is then passed to step 5.

[0065] Step 5: Compare the execution trusted state with the admission trusted state snapshot to obtain the difference determination result. This step is executed by the state difference determination module 80, and the output is the difference determination result 350, which is then passed to step 6. The difference determination result 350 is categorized into one of the following: no difference, slight difference, re-evaluable difference, and blocking difference.

[0066] Step 6: Execute the corresponding deployment control action based on the difference determination result. This step is executed by the deployment control decision module 90. If the difference determination result 350 indicates no difference, the application deployment execution module 60 continues deployment. If the difference determination result 350 indicates a slight difference, deployment is paused and a policy reassessment is triggered. The decision to continue or stop deployment is made based on the policy reassessment result. If the difference determination result 350 indicates a reassessable difference, the access trust state acquisition module 30, the access trust state snapshot generation module 40, and the deployment token generation module 50 regenerate the access trust state snapshot 320 and the deployment token 330. If the difference determination result 350 indicates a blocking difference, the application deployment execution module 60 stops deployment and calls the exception rollback and cleanup module 100 to perform exception rollback and cleanup.

[0067] Step 7: Perform an exception rollback and cleanup when deployment is blocked, fails, or rolled back. This step is performed by the exception rollback and cleanup module 100, which includes deleting application package files that are not fully installed or activated on the target deployment object, revoking the deployment token 330, revoking temporary access permissions obtained by the target deployment object during the deployment process, cleaning up the temporary configuration cache on the target deployment object, and recording the reason for the exception in the audit log 370.

[0068] Furthermore, during the execution of steps 1 to 6, the audit log module 120 continuously records audit information, including deployment requests, access trust status snapshots 320, execution trust status 340, difference determination results 350, deployment control actions 360, and operation times. The recorded audit logs 370 can serve as evidence of deployment traceability and as a data basis for subsequent strategy reassessment.

[0069] Example 2: This example provides an optimized implementation of a dynamic deployment system for IoT applications based on a zero-trust architecture. The overall structure and module connection relationships of the system in this example are the same as in Example 1, such as... Figure 1 As shown, the system comprises a deployment request receiving module 10, a target object parsing module 20, an access trusted state acquisition module 30, an access trusted state snapshot generation module 40, a deployment token generation module 50, an application deployment execution module 60, an execution trusted state verification module 70, a state difference determination module 80, a deployment control decision module 90, an anomaly rollback and cleanup module 100, a policy management module 110, and an audit log module 120. The difference between this embodiment and Embodiment 1 is that the access trusted state acquisition module 30, deployment token generation module 50, execution trusted state verification module 70, state difference determination module 80, deployment control decision module 90, and policy management module 110 adopt corresponding optimized implementation methods based on the basic implementation method of Embodiment 1; the implementation methods of the deployment request receiving module 10, target object parsing module 20, access trusted state snapshot generation module 40, application deployment execution module 60, anomaly rollback and cleanup module 100, and audit log module 120 are the same as in Embodiment 1.

[0070] The following section provides a concentrated description of the six modules implemented using optimized methods in this embodiment.

[0071] 1. Access Trust Status Acquisition Module 30 As an optimization of the access trust status acquisition module 30 in Embodiment 1, the access trust status acquisition module 30 in this embodiment, based on the basic acquisition logic of Embodiment 1, further differentiates the acquisition fields according to the application risk level corresponding to the application identifier. Specifically: for low-risk applications, i.e., when the application risk level does not reach the preset risk level threshold, the access trust status acquisition module 30 mainly acquires the device identity status, network location, and security policy version fields; for high-risk applications, i.e., when the application risk level reaches the preset risk level threshold, the access trust status acquisition module 30 further acquires the runtime environment integrity, firmware version, risk level, and peripheral connection status fields. Among them, the runtime environment integrity field is obtained through runtime environment measurement methods; the peripheral connection status field is used to reflect the type and connection status of the peripherals currently connected to the target deployment object, so as to avoid the application being deployed on the target deployment object with unauthorized peripherals. The application risk level is carried by the deployment policy identifier or derived by the policy management module 110 according to the mapping between the application type and the access resource type.

[0072] Through the above-mentioned differentiated field configuration, the access trust status acquisition module 30 can adjust the acquisition accuracy according to the application risk level, avoid over-acquiring of low-risk applications, and at the same time ensure the acquisition coverage of high-risk applications.

[0073] 2. Deployment Token Generation Module 50 As an optimization of the deployment token generation module 50 in Embodiment 1, the deployment token generation module 50 in this embodiment, based on the token generation logic of Embodiment 1, sets explicit overdue processing logic for the token validity window of the deployment token 330. Specifically, before the application deployment execution module 60 works, the deployment token generation module 50 and the deployment control decision module 90 jointly determine whether the current time is within the token validity window of the deployment token 330; when the current time exceeds the token validity window, the deployment token generation module 50 suspends the output of the deployment token 330 to the application deployment execution module 60, and then the admission trusted state acquisition module 30 re-acquires the admission trusted state, the admission trusted state snapshot generation module 40 regenerates the admission trusted state snapshot, and the deployment token generation module 50 regenerates the deployment token.

[0074] Through the above optimization of deployment token expiration handling, this optimized implementation avoids using expired deployment tokens 330 when deployment tasks are queued for too long. The optimized implementation of the deployment token generation module 50 corresponds to determining whether the current time is within the token validity window before executing application deployment; if the current time exceeds the token validity window, the deployment token is no longer used.

[0075] 3. Execute the trusted status verification module 70 As an optimization of the trusted state verification module 70 in Embodiment 1, the trusted state verification module 70 in this embodiment, based on the principle of "performing a re-collection at least once before activation" in Embodiment 1, can also perform re-collection before application package distribution, installation, configuration injection taking effect, and activation when the application risk level corresponding to the application identifier reaches a preset risk level threshold, to obtain the trusted state 340 corresponding to each key execution node. The state difference determination module 80 performs state difference determination on each trusted state 340 to obtain multiple corresponding difference determination results 350; the deployment control decision module 90 performs deployment control decisions on each difference determination result 350.

[0076] like Figure 2 As shown, on the timeline t1 to t8, t1 corresponds to the admission phase data collection, t2 corresponds to snapshot generation and token issuance, t3 corresponds to pre-application package delivery review, t4 corresponds to pre-installation review, t5 corresponds to pre-configuration injection review, t6 corresponds to pre-activation review, t7 corresponds to difference determination and deployment control action execution, and t8 corresponds to exception rollback and cleanup. In this preferred embodiment, if the difference determination result 350 at any key execution node is classified as a blocking difference, the deployment control decision module 90 directly controls the application deployment execution module 60 to stop subsequent deployments to prevent subsequent execution actions from occurring on target deployment objects that no longer meet the trust conditions.

[0077] By implementing the preferred embodiment of the trusted state verification module 70, the system's detection accuracy for state changes can be further improved, making it suitable for deployment scenarios targeting high-risk or high-privilege applications.

[0078] 4. Status Difference Determination Module 80 As an optimization of the state difference determination module 80 in Embodiment 1, the state difference determination module 80 in this embodiment further implements the difference determination logic through a rule table, building upon the difference determination logic in Embodiment 1. The input items of the rule table are the field consistency comparison result, the time validity comparison result, the strategy version consistency comparison result, and the risk level change; the output item of the rule table is the classification result of the difference determination result 350.

[0079] The specific entries in the rule table can be managed in a versioned manner by the policy management module 110, and support hot updates or require updates by policy administrators with corresponding permissions. Implementing the difference determination logic through the rule table method facilitates the upgrading, expansion, or adjustment of the difference determination rules without modifying the internal code of the state difference determination module 80.

[0080] 5. Deploy control decision module 90 As an optimization of the deployment control decision module 90 in Embodiment 1, the deployment control decision module 90 in this embodiment, above the four deployment control branches in Embodiment 1, further implements the mapping between the difference judgment result 350 and the deployment control action 360 through a rule table. The input items of the rule table include difference type and difference level, and the output items include continue deployment, re-evaluate, pause deployment, block deployment, rollback cleanup, or target object switch.

[0081] For example, the rule table may contain the following entries: "Target object identity mismatch → Block deployment + rollback cleanup", "Device certificate expired → Block deployment + rollback cleanup", "Security policy version revoked → Block deployment", "Network location exceeds allowed range → Block deployment", "Runtime load increases but does not exceed policy limit → Trigger reassessment and continue deployment", "Policy version undergoes compatible update → Trigger reassessment and regenerate snapshot and token based on new policy".

[0082] The specific entries in the rule table are versioned by the policy management module 110, and support hot updates or require updates by policy administrators with the appropriate permissions. Implementing difference-action mapping through rule tables facilitates upgrading, expanding, or adjusting deployment control rules without modifying the internal code of the deployment control decision module 90. It also allows for the use of different rule tables for different application risk levels and different target object types.

[0083] 6. Strategy Management Module 110 As an optimization of the policy management module 110 in Embodiment 1, the policy management module 110 in this embodiment, based on the basic rule provision capability of Embodiment 1, is further used for version management of the difference determination rule table and the difference-action mapping rule table. Version management includes adding, modifying, canceling, and rolling back rule table entries, and supports hot updates or requires updates by policy administrators with corresponding permissions. This optimized implementation supports the optimized implementation of the state difference determination module 80 and the optimized implementation of the deployment control decision module 90, enabling both rule tables in this embodiment to be upgraded, expanded, and rolled back without affecting online deployment tasks.

[0084] It should be noted that the implementation methods of the deployment request receiving module 10, target object parsing module 20, admission trusted state snapshot generation module 40, application deployment execution module 60, exception rollback and cleanup module 100, and audit log module 120 in this embodiment are the same as those in Embodiment 1, and will not be repeated here. The module deployment form of this embodiment adopts the same centralized deployment form as in Embodiment 1.

[0085] 7. Overall System Execution Flow The overall process of collaborative execution of various functional modules in this embodiment includes steps 1 to 7.

[0086] Step 1: The deployment request receiving module 10 receives the deployment request of the IoT application, and the target object parsing module 20 parses the application identifier and target deployment object in the deployment request. The implementation method of this step is the same as that of Example 1, and the output is the application identifier and target deployment object information, which is then passed to Step 2.

[0087] Step 2: The access trust status acquisition module 30 acquires the access trust status of the target deployment object during the deployment task access phase. This step is performed by the access trust status acquisition module 30 according to the optimized implementation method of "differentiated field configuration based on application risk level" in this embodiment: when the application risk level corresponding to the application identifier does not reach the preset risk level threshold, it mainly acquires the device identity status, network location, and security policy version fields; when the application risk level reaches the preset risk level threshold, it further acquires the runtime environment integrity, firmware version, target object risk level, runtime environment version, and peripheral connection status fields. The access trust status 310 is output to the access trust status snapshot generation module 40.

[0088] Step 3: The access trusted state snapshot generation module 40 structurally encapsulates the access trusted state 310 according to field values, collection time, and valid window, and generates a snapshot summary value to obtain the access trusted state snapshot 320. The generation method of the access trusted state snapshot 320 in this step is the same as in Example 1. Subsequently, the deployment token generation module 50 generates a deployment token 330 bound to the access trusted state snapshot 320 according to the optimized implementation method of "deployment token expiration processing" in this example.

[0089] Furthermore, before executing step 4, the deployment token generation module 50 and the deployment control decision module 90 jointly determine whether the current time is within the valid window of the deployment token 330; when the current time exceeds the valid window, the deployment token 330 is stopped from being used and the process returns to step 2.

[0090] Step 4: The execution trusted state verification module 70 re-collects the current trusted state of the target deployment object on the key execution nodes according to the optimized implementation method of "multi-key node verification" in this embodiment. Specifically, when the application risk level corresponding to the application identifier reaches the preset risk level threshold, re-collection is performed before application package distribution, installation, configuration injection taking effect, and activation to obtain multiple corresponding execution trusted states 340; when the application risk level does not reach the preset risk level threshold, re-collection is performed at least once before activation to obtain execution trusted states 340. Each execution trusted state 340 is output to the state difference determination module 80.

[0091] Step 5: The state difference determination module 80 compares the execution trusted state 340 with the admission trusted state snapshot 320 according to the optimized implementation method of "difference determination based on rule table" in this embodiment, and obtains the difference determination result 350. The difference determination logic is implemented through a rule table, which is version-managed by the policy management module 110. In a multi-key node review scenario, the state difference determination module 80 performs this step for each execution trusted state 340, and obtains multiple corresponding difference determination results 350.

[0092] Step 6: The deployment control decision module 90 executes the corresponding deployment control action 360 based on the difference determination result 350 according to the optimized implementation method of "difference-action mapping based on rule table" in this embodiment. The difference-action mapping is implemented through a rule table, which is version-managed by the policy management module 110. Specifically, the deployment control decision module 90 outputs the corresponding actions among continue deployment, re-evaluation, pause deployment, block deployment, and rollback cleanup based on the difference type and difference level input items in the rule table. In the scenario of multi-key node review, the deployment control decision module 90 executes this step for each difference determination result 350. If the difference determination result 350 at any key execution node is classified as a blocking difference, the deployment control decision module 90 directly controls the application deployment execution module 60 to stop subsequent deployments.

[0093] Step 7: When deployment is blocked, fails, or rolls back, the abnormal rollback and cleanup module 100 performs abnormal rollback and cleanup; the implementation method of this step is the same as in Example 1.

[0094] Furthermore, during the execution of steps 1 to 6, the audit logging module 120 continuously records audit information; the audit information includes deployment requests, access trust status snapshots 320, execution trust status 340, difference determination results 350, deployment control actions 360, and operation times. In multi-key-node review scenarios, multiple execution trust statuses 340, multiple difference determination results 350, and multiple deployment control actions 360 are all recorded separately according to their corresponding key execution nodes.

[0095] Through the above execution process, this embodiment retains the basic technical path of embodiment 1 while realizing the adjustment of collection accuracy based on application risk level, explicit handling of token expiration, detection of state changes of multiple key nodes, versionable difference judgment rules and versionable difference-action mapping, thereby improving the overall adaptability of this system to differentiated deployment scenarios and strategy evolution scenarios.

[0096] Example 3: This example provides a modified implementation of an IoT application dynamic deployment system based on a zero-trust architecture. The overall structure and module connection relationships of the system in this example are the same as in Example 1, such as... Figure 1As shown, the system comprises a deployment request receiving module 10, a target object parsing module 20, an access trusted state acquisition module 30, an access trusted state snapshot generation module 40, a deployment token generation module 50, an application deployment execution module 60, an execution trusted state verification module 70, a state difference determination module 80, a deployment control decision module 90, an anomaly rollback and cleanup module 100, a policy management module 110, and an audit log module 120. The difference between this embodiment and Embodiment 1 is that the access trusted state snapshot generation module 40, the execution trusted state verification module 70, the deployment control decision module 90, and the policy management module 110 adopt corresponding modified implementations based on the basic implementation of Embodiment 1; the implementation methods of the deployment request receiving module 10, the target object parsing module 20, the access trusted state acquisition module 30, the deployment token generation module 50, the application deployment execution module 60, the state difference determination module 80, the anomaly rollback and cleanup module 100, and the audit log module 120 are the same as in Embodiment 1; the module deployment form of this embodiment adopts a decoupled deployment form based on a message bus in terms of physical deployment.

[0097] 1. Admission Trusted State Snapshot Generation Module 40 As a variation of the access trusted state snapshot generation module 40 in Embodiment 1, this embodiment, after generating the access trusted state snapshot 320, synchronizes the access trusted state snapshot 320 to the local cache of the edge node 220 where the target deployment object is located, so that the local cache of the edge node 220 stores a copy of the access trusted state snapshot 320. When the network connection between the edge node 220 and the central deployment controller is interrupted, the copy serves as a local comparison benchmark for trusted state verification and difference determination during the execution phase. The lifecycle of the copy is consistent with the effective window of the access trusted state snapshot 320; after the effective window expires, it is cleaned up locally by the edge node 220. This modified implementation is used in conjunction with the "edge local cache verification" modified implementation of the execution trusted state verification module 70, as detailed in the corresponding description of the execution trusted state verification module 70.

[0098] Through the modified implementation of synchronizing the access trusted state snapshot to the local cache of the edge node, this embodiment provides a comparable local benchmark for the edge node 220 to complete the execution phase review and difference determination locally in weak network or network outage scenarios.

[0099] 2. Execute the trusted status verification module 70 As a variation of the trusted state verification module 70 in Embodiment 1, the trusted state verification module 70 in this embodiment is used in conjunction with a variation of the "snapshot synchronization to edge node local cache" in the admission trusted state snapshot generation module 40. The admission trusted state snapshot 320 is synchronously stored between the central deployment controller and the edge node 220, so that a copy of the admission trusted state snapshot 320 is stored in the local cache of the edge node 220.

[0100] When the network connection between the target deployment object and the central deployment controller is interrupted, the local deployment agent on edge node 220 triggers the execution trusted state verification module 70 to collect the current trusted state of the target deployment object, obtaining the execution trusted state 340. The local deployment agent compares the execution trusted state 340 with the admission trusted state snapshot 320 in the local cache to obtain a local difference determination result. The local deployment agent executes local continue deployment, pause deployment, or stop deployment control actions based on the local difference determination result. For the re-evaluable difference branch involving "regenerating the admission trusted state snapshot and deployment token", this modified implementation does not execute it at edge node 220, but instead the deployment task is sent back to the central deployment controller for unified processing after the network is restored, to ensure the uniformity of deployment token generation.

[0101] After the network connection is restored, the edge node 220 sends the local difference determination result and deployment control action 360 back to the audit record module 120 of the central deployment controller to complete the backfilling of the audit record, which is then recorded by the audit record module 120.

[0102] Through the modified implementation of the trusted state verification module 70 described above, this system can maintain the verification and difference determination capabilities during the deployment process even in weak network or network outage scenarios, thus preventing the edge node 220 from losing the means to verify the current trusted state when the network is interrupted.

[0103] 3. Deploy control decision module 90 As a variation of the deployment control decision module 90 in Embodiment 1, the deployment control decision module 90 in this embodiment, in addition to the four deployment control branches in Embodiment 1, introduces a modified branch for target object switching deployment in the case where "the difference determination result 350 is a re-evaluable difference and the node operating load or network location collected during the execution phase no longer meets the deployment policy". In this case, the deployment control decision module 90 no longer relies solely on the original target deployment object to regenerate the access trusted state snapshot and deployment token, but instead, based on the candidate node list provided by the policy management module 110, switches the IoT application to other target deployment objects that meet the trusted conditions, and re-invokes the access trusted state acquisition module 30, access trusted state snapshot generation module 40, deployment token generation module 50, application deployment execution module 60, execution trusted state verification module 70, and state difference determination module 80 for the new target deployment object.

[0104] Specifically, the deployment control decision module 90 initiates a candidate node query request to the policy management module 110. The policy management module 110 returns a list of candidate nodes based on the application risk level, application type, and target object type preference. The deployment control decision module 90 selects the first node in the candidate node list that meets the deployment policy as the new target deployment object and initiates an access trust status collection request to the access trust status collection module 30 for the new target deployment object. The access trust status collection module 30, the access trust status snapshot generation module 40, and the deployment token generation module 50 re-execute the access trust status collection, snapshot generation, and token issuance on the new target deployment object. The execution trust status verification module 70 and the status difference judgment module 80 re-execute the execution trust status collection and difference judgment on the new target deployment object.

[0105] By using a modified implementation of the deployment control decision module 90, deployment tasks can be transferred to other target deployment objects that meet the trust conditions, reducing the possibility of deployment tasks failing due to the uncontrollable state of a single target object. This is particularly suitable for load balancing scenarios and scenarios where the target node state is unstable.

[0106] 4. Strategy Management Module 110 As a variation of the strategy management module 110 in Embodiment 1, the strategy management module 110 in this embodiment, in addition to providing basic rules in Embodiment 1, further maintains a list of candidate nodes corresponding to the target object type, application risk level, and application type. When the deployment control decision module 90 initiates a candidate node query request, the strategy management module 110 returns a list of candidate nodes based on the application risk level, application type, and target object type preference, serving as the basis for target object switching deployment. This modified implementation supports the "target object switching deployment" modified implementation of the deployment control decision module 90.

[0107] It should be noted that the implementation methods of the deployment request receiving module 10, target object parsing module 20, access trust status acquisition module 30, deployment token generation module 50, application deployment execution module 60, status difference judgment module 80, abnormal rollback and cleanup module 100 and audit record module 120 in this embodiment are the same as those in embodiment 1, and will not be repeated here.

[0108] 5. Module Deployment Mode As a variation of the "centralized deployment mode" in Example 1, this example adopts a decoupled deployment mode based on a message bus. In this modified deployment mode, each functional module is deployed in a decoupled manner based on a message bus. In one implementation, the message bus is implemented as an MQTToverTLS-based message bus; in another, it is implemented as a gRPC-based remote procedure call framework; and in yet another, it is implemented as a message queue or edge management bus. The modules exchange structured messages through a publish-subscribe mechanism. In one implementation, the structured message includes a deployment request, an admission trusted state snapshot summary, an execution trusted state, a difference determination result, and deployment control instructions.

[0109] The message bus-based decoupled deployment model is suitable for multi-tenant, cross-domain, or multi-edge cluster collaborative deployment scenarios. It facilitates the deployment of some modules in this embodiment to edge nodes 220, gateway nodes 230, or edge clusters, thereby shortening the deployment execution chain or meeting localization compliance requirements. This modified deployment model works in conjunction with the modified implementation methods of access trusted state snapshot synchronization, edge local cache verification, and target object switching deployment in this embodiment, enabling the system in this embodiment to adapt to distributed, dynamic, and heterogeneous IoT networking environments at both the physical deployment level and the functional module implementation level.

[0110] 6. Overall System Execution Flow The overall process of collaborative execution of various functional modules in this embodiment includes steps S1 to S7. The following uses the same step sequence as in Embodiment 1 as a framework to illustrate the position and role of each modified module in this process.

[0111] Step S1: The deployment request receiving module 10 receives the deployment request from the IoT application, and the target object parsing module 20 parses the application identifier and target deployment object in the deployment request; the implementation method of this step is the same as in Embodiment 1. In the decoupled deployment mode based on the message bus, the deployment request receiving module 10 receives the deployment request by subscribing to the corresponding deployment request topic on the bus, and publishes the parsed application identifier and target deployment object information to the access trust status acquisition module 30 and the policy management module 110 through the bus.

[0112] Step S2 involves the Admission Trust Status Acquisition Module 30 acquiring the admission trust status of the target deployment object during the deployment task admission phase; the implementation method of this step is the same as in Example 1. The admission trust status 310 is published to the admission trust status snapshot generation module 40 via the bus.

[0113] In step S3, the access trusted state snapshot generation module 40, following a modified implementation of the "snapshot synchronization to edge node local cache" method in this embodiment, structurally encapsulates the access trusted state 310 according to field values, collection time, and effective window, and generates a snapshot summary value to obtain the access trusted state snapshot 320. After generating the access trusted state snapshot 320, the access trusted state snapshot generation module 40 synchronizes the access trusted state snapshot 320 to the local cache of the edge node 220 where the target deployment object is located. Subsequently, the deployment token generation module 50 generates a deployment token 330 bound to the access trusted state snapshot 320; the deployment token generation implementation method in this part is the same as in embodiment one.

[0114] Step S4: The execution trusted state verification module 70 re-collects the current trusted state of the target deployment object on the key execution node to obtain the execution trusted state 340, and performs the re-collection at least once before activation. This step is performed in the same way as in Embodiment 1 when the network connection between the central deployment controller and the edge node 220 is normal. When the network connection between the central deployment controller and the edge node 220 is interrupted, it is performed according to the modified implementation method of "edge local cache verification" in this embodiment: the local deployment agent on the edge node 220 triggers the execution trusted state verification module 70 to collect the current trusted state of the target deployment object to obtain the execution trusted state 340.

[0115] Step S5: Compare the execution trusted state 340 with the admission trusted state snapshot 320 to obtain a difference determination result 350. Under normal network connectivity conditions, this step is performed by the state difference determination module 80 in the same manner as in Embodiment 1; under network connectivity interruption conditions, this step is performed by the local deployment agent on the edge node 220 based on the admission trusted state snapshot 320 in the local cache and the collected execution trusted state 340 at the edge node 220 to obtain a local difference determination result.

[0116] Step S6: Execute the corresponding deployment control action 360 based on the difference determination result 350. Under normal network connectivity, this step is executed by the deployment control decision module 90 according to the modified implementation of "target object switching deployment" in this embodiment: When the difference determination result 350 is no difference, slight difference, or blocking difference, the corresponding branches of "continue deployment", "pause deployment and trigger policy reassessment" or "stop deployment and trigger abnormal rollback and cleanup" in Embodiment 1 are executed respectively; when the difference determination result 350 is a reassessable difference and the node operating load or network location collected during the execution phase still meets the deployment policy, the deployment control decision module 90 controls the regeneration of the admission trusted state snapshot and deployment token; when the difference determination result 350 is a reassessable difference and the node operating load or network location collected during the execution phase no longer meets the deployment policy, the deployment control decision module 90 switches the IoT application to other target deployment objects that meet the trusted conditions based on the candidate node list maintained by the policy management module 110, and re-executes the process of steps S2 to S5 for the new target deployment object. In the event of a network connection interruption, this step involves the local deployment agent on edge node 220 performing local control actions such as continuing deployment, pausing deployment, or stopping deployment based on the local difference determination results. For re-evaluable difference branches involving the regeneration of admission trusted state snapshots and deployment tokens, the deployment task will send them back to the central deployment controller for unified processing after the network is restored.

[0117] Step S7: When deployment is blocked, fails, or rolls back, the abnormal rollback and cleanup module 100 performs abnormal rollback and cleanup; the implementation method of this step is the same as in Example 1.

[0118] Furthermore, during the execution of steps S1 to S6, the audit logging module 120 continuously records audit information, including deployment requests, access trusted state snapshots 320, execution trusted state 340, difference determination results 350, deployment control actions 360, and operation times. When network connectivity is restored after an interruption, the edge node 220 sends the local difference determination results and local deployment control actions back to the audit logging module 120 to complete the backfilling of audit records.

[0119] Through the above execution process, this embodiment retains the basic technical path of embodiment 1 while realizing the local storage of the access trusted state snapshot on the edge node, local review and difference determination in weak network or network outage scenarios, target object switching deployment under re-evaluable differences, and module decoupling deployment based on message bus. As a result, the overall adaptability of this system to network unstable scenarios, load balancing requirements scenarios, and multi-edge cluster collaboration scenarios is improved.

[0120] Example 3: Based on the system provided in Example 1 and the method provided in Example 2, this example provides a computer device that executes the method described in Example 2 or any other method that may involve the method described in Example 2. The device includes a memory, a processor, and a transceiver connected in sequence. The memory stores a computer program, the transceiver sends and receives messages, and the processor reads the computer program and executes the method described in Example 2 or any other method that may involve the method described in Example 2. Specifically, the memory may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or last-in-first-out (FILO) memory, etc.; the processor may include, but is not limited to, a microprocessor of the STM32F105 series. Furthermore, the computer device may also include, but is not limited to, a power module, a display screen, and other necessary components.

[0121] The working process, working details and technical effects of the aforementioned computer device provided in this embodiment can be found in the method described in Embodiment 1 or any method that may involve the method described in Embodiment 1, and will not be repeated here.

[0122] Example 4: This example provides a computer-readable storage medium that stores instructions that include the method described in Example 2 or any method that may involve the method described in Example 2. Specifically, the computer-readable storage medium stores instructions that, when executed on a computer, perform the method described in Example 1 or any method that may involve the method described in Example 1. The computer-readable storage medium refers to a data storage medium, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or Memory Sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0123] The working process, working details and technical effects of the aforementioned computer-readable storage medium provided in this embodiment can be found in the method described in Embodiment 1 or any method that may be related to Embodiment 1, and will not be repeated here.

[0124] Example 5: This example provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method described in Example 1 or any method that may involve the method described in Example 2. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0125] It should be understood that the terms "system," "device," "unit," and / or "module" as used in this specification are a method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other words can achieve the same purpose, they may be replaced by other expressions.

[0126] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0127] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0128] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings are merely for illustrative purposes to aid those skilled in the art and are not intended to limit the scope of the invention. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in proportions, or adjustments to size, without affecting the effectiveness and purpose of the invention, should still fall within the scope of the disclosed technical content. Furthermore, terms such as "upper," "lower," "left," "right," and "middle" used in this specification are merely for clarity and not intended to limit the scope of the invention. Changes or adjustments to their relative relationships, without substantially altering the technical content, should also be considered within the scope of the invention.

Claims

1. A method for dynamically deploying an Internet of Things application based on a zero-trust architecture, characterized in that, include: S1 receives and parses the deployment request of the IoT application to obtain the application identifier and target deployment object in the deployment request; S2, during the deployment task admission phase, collect the admission trust status of the target deployment object; The access trust status includes: a first type of trust field and a second type of trust field; the first type of trust field includes at least one of the following: device identity status, device certificate status, security policy version, and target object risk level; the second type of trust field includes at least one of the following: node operating load, network location, firmware version, and operating environment version. S3, the access trusted state is structured and encapsulated according to field values, collection time and valid window, and a snapshot summary value is generated to obtain the access trusted state snapshot; a deployment token is generated bound to the access trusted state snapshot; the deployment token includes: application identifier, target deployment object identifier, snapshot summary value and token valid window; S4. Re-collect the current trusted state of the target deployment object at at least one of the key execution nodes before the application package is distributed, before installation, before configuration injection takes effect, and before activation, to obtain the execution trusted state, and perform re-collection at least once before activation; S5, compare the execution trusted state with the admission trusted state snapshot to obtain the difference determination result; S6. Execute the corresponding deployment control action based on the difference determination result. The deployment control action is one of the following: continue deployment, pause deployment and trigger policy reassessment, regenerate access trust state snapshot and deployment token, or stop deployment and trigger abnormal rollback and cleanup.

2. The method of claim 1, wherein, The difference determination result is one of the following: no difference, slight difference, reassessable difference, and blocking difference; the difference determination result is determined based on the field consistency, time validity, policy version consistency, and risk level changes between the execution trusted state and the admission trusted state snapshot.

3. The method of claim 2, wherein S6 include: If the difference determination result is no difference, control continues to deploy; If the difference determination result is a slight difference, the deployment is paused and a strategy reassessment is triggered. The decision to continue or stop the deployment is made based on the result of the strategy reassessment. When the difference determination result is a re-evaluable difference, the access trust status of the target deployment object is re-collected, and the access trust status snapshot and deployment token are regenerated. If the difference determination result is a blocking difference, stop the deployment and trigger an abnormal rollback and cleanup.

4. The method of claim 2, wherein, Field consistency comparison includes: performing a field consistency comparison between the execution trusted state and the admission trusted state snapshot on at least two of the following: target object identity, network location, runtime load, firmware version, runtime environment version, security policy version, certificate status, risk level, and token validity window, and obtaining the difference determination result.

5. The method of claim 1, wherein, Before executing S4, the following steps are also included: Determine if the current time is within the valid token window; if the current time is outside the valid token window, stop using the deployment token and return to execute S2.

6. The method of claim 1, wherein, Triggering anomaly rollback and cleanup includes: deleting application package files that are not fully installed or activated on the target deployment object, revoking the deployment token, reclaiming temporary access permissions obtained by the target deployment object during the deployment process, clearing the temporary configuration cache on the target deployment object, and recording the cause of the anomaly in the audit log.

7. The method for dynamic deployment of IoT applications based on a zero-trust architecture according to claim 1, characterized in that, It also includes the following steps: Record audit information during the execution of S1 to S6; Audit information includes: deployment requests, access trusted state snapshots, execution trusted states, discrepancy determination results, deployment control actions, and operation times.

8. The method for dynamic deployment of IoT applications based on a zero-trust architecture according to claim 1, characterized in that, S2 also includes: collection fields for determining the access trust status based on the application risk level corresponding to the application identifier; when the application risk level reaches the preset risk level threshold, the collection fields include: firmware version, runtime environment version, target object risk level, runtime environment integrity, and peripheral connection status.

9. The method for dynamic deployment of IoT applications based on a zero-trust architecture according to claim 1, characterized in that, S4 includes: when the application risk level corresponding to the application identifier reaches the preset risk level threshold, re-collection is performed before the application package is distributed, before installation, before configuration injection takes effect, and before activation to obtain multiple corresponding execution trust states; and S5 and S6 are performed for each execution trust state respectively.

10. The method for dynamic deployment of IoT applications based on a zero-trust architecture according to claim 1, characterized in that, S4 also includes: synchronizing the admission trusted state snapshot to the local cache of the edge node where the target deployment object is located; when the network connection between the target deployment object and the central deployment controller is interrupted, the edge node executes S5 based on the admission trusted state snapshot in the local cache, and executes local continue deployment, pause deployment or stop deployment control actions according to the difference determination result; after the network connection is restored, the edge node sends the difference determination result and deployment control actions back to the central deployment controller.

11. A dynamic deployment system for IoT applications based on a zero-trust architecture, characterized in that, include: Deployment request receiving module (10) is used to receive deployment requests from IoT applications; The target object parsing module (20) is connected to the deployment request receiving module (10) and is used to parse the deployment request to obtain the application identifier and the target deployment object; The access trust status acquisition module (30) is connected to the target object parsing module (20) and is used to collect the access trust status (310) of the target deployment object during the access phase of the deployment task. The access trust status (310) includes a first type of trust field and a second type of trust field. The first type of trust field includes at least one of the following: device identity status, device certificate status, security policy version and target object risk level. The second type of trust field includes at least one of the following: node running load, network location, firmware version and running environment version. The access trust status snapshot generation module (40) is connected to the access trust status acquisition module (30) and is used to encapsulate the access trust status (310) in a structured manner according to field values, acquisition time and effective window and generate a snapshot summary value to obtain the access trust status snapshot (320). The deployment token generation module (50) is connected to the admission trusted state snapshot generation module (40) and is used to generate a deployment token (330) bound to the admission trusted state snapshot (320). The deployment token (330) includes an application identifier, an identifier of the target deployment object, a snapshot digest value, and a token validity window. The application deployment execution module (60) is connected to the deployment token generation module (50) and is used to perform application package distribution, installation, configuration injection and activation; The trusted state verification module (70) is connected to the application deployment execution module (60) and is used to re-collect the current trusted state of the target deployment object at at least one key execution node before the application package is distributed, before installation, before configuration injection takes effect and before activation, and at least before activation, to obtain the trusted state of the execution (340). The state difference determination module (80) is connected to the admission trusted state snapshot generation module (40) and the execution trusted state verification module (70) respectively, and is used to compare the execution trusted state (340) with the admission trusted state snapshot (320) to obtain the difference determination result (350). An abnormal rollback and cleanup module (100) is used to delete inactive application package files on the target deployment object, revoke deployment tokens (330), reclaim temporary access permissions obtained by the target deployment object during the deployment process, and clean up temporary configuration cache when the deployment is stopped. The deployment control decision module (90) is connected to the state difference judgment module (80), the application deployment execution module (60), the abnormal rollback and cleanup module (100), the access trusted state acquisition module (30), the access trusted state snapshot generation module (40), and the deployment token generation module (50), respectively. It is used to control the application deployment execution module (60) to continue deployment or trigger policy re-evaluation after pausing deployment based on the difference judgment result (350), or to control the access trusted state acquisition module (30), the access trusted state snapshot generation module (40), and the deployment token generation module (50) to regenerate the access trusted state snapshot (320) and the deployment token (330), or to control the application deployment execution module (60) to stop deployment and call the abnormal rollback and cleanup module (100) to perform abnormal rollback and cleanup.

12. The IoT application dynamic deployment system based on a zero-trust architecture according to claim 11, characterized in that, The difference determination result (350) is one of the following: no difference, slight difference, reassessable difference, and blocking difference; The deployment control decision module (90) is specifically used to: control the application deployment execution module (60) to continue deployment when the difference determination result (350) is no difference; control the application deployment execution module (60) to pause deployment and trigger policy reassessment when the difference determination result (350) is a slight difference, and determine whether to continue deployment or stop deployment based on the result of policy reassessment; control the access trusted state acquisition module (30), access trusted state snapshot generation module (40) and deployment token generation module (50) to regenerate access trusted state snapshot (320) and deployment token (330) when the difference determination result (350) is a reassessable difference; and control the application deployment execution module (60) to stop deployment and call the abnormal rollback and cleanup module (100) when the difference determination result (350) is a blocking difference.

13. The IoT application dynamic deployment system based on a zero-trust architecture according to claim 11, characterized in that, It also includes a policy management module (110); the policy management module (110) is connected to the access trusted state acquisition module (30), the execution trusted state verification module (70), the state difference determination module (80) and the deployment control decision module (90) respectively, and is used to provide access rules to the access trusted state acquisition module (30), verification rules to the execution trusted state verification module (70), difference determination rules to the state difference determination module (80), and deployment control rules to the deployment control decision module (90).

14. The IoT application dynamic deployment system based on a zero-trust architecture according to claim 11, characterized in that, It also includes an audit log module (120), which is connected to the deployment request receiving module (10), the access trusted state snapshot generation module (40), the execution trusted state review module (70), the state difference judgment module (80), the deployment control decision module (90), and the abnormal rollback and cleanup module (100), respectively, and is used to record the deployment request, the access trusted state snapshot (320), the execution trusted state (340), the difference judgment result (350), the control actions and operation time of the deployment control decision module (90).

Images