Cloud data cross-domain collaborative storage method and system

Abstract

The invention relates to the technical field of digital information transmission, and discloses a cloud data cross-domain collaborative storage method and system, and the method comprises the steps: compiling a prohibited transmission strategy into an illegal behavior feature vector set, calculating the logic difference between a behavior feature vector and an illegal vector during a cross-domain request, and generating a compliance proof, according to the method, a traditional pre-established trust channel is replaced by a behavior characteristic self-certification mechanism, so that the compliance of the data stream is autonomously certified in the transmission process, meanwhile, viral synchronization of the strategy is realized by means of the version identifier, the openness is ensured and the strategy consistency is maintained in dynamic scenes such as emergency response, and the method has the advantages of high reliability, high reliability and the like. And the problems of centralized approval delay and single-point fault are solved.

Description

Technical Field

[0001] The present invention relates to a cloud data cross-domain collaborative storage method and system, belonging to the technical field of digital information transmission. Background Art

[0002] In the field of digital information transmission technology, cross-domain collaborative storage of cloud data requires relying on pre-built trust channels to achieve secure transmission. For example, static security connections are pre-established through centralized gateways or tunnels, and permission verification is performed through centralized policy services. Although this model is widely adopted, it has fundamental limitations: it binds dynamic compliance decisions to static network facilities, making it difficult for the system to adapt to real-time policy changes and network environment fluctuations in cross-domain scenarios.

[0003] Taking smart city emergency response as an example, when multiple government cloud domains, such as transportation, meteorology, and power grids, need to collaborate on emergency data in real time, existing technologies face three core contradictions: 1. Emergency requests often require dynamic cross-domain permissions, while traditional pre-approval processes trigger online approvals from multiple departments, delaying critical decisions; 2. Extreme environments can easily lead to node failures, and static tunnels lack adaptive routing capabilities, resulting in interrupted collaborative links; 3. Social resource nodes, such as temporarily requisitioned cameras, require limited collaboration, but centralized architectures cannot support temporary, incomplete trust relationships. The industry has attempted to mitigate these issues by strengthening the policy enforcement layer or optimizing encryption protocols, but this has further increased system complexity and failed to address the inherent flaw of decoupling compliance verification from data transmission. Summary of the Invention

[0004] The present invention provides a cloud data cross-domain collaborative storage method and system, the main purpose of which is to solve the problems of existing cross-domain data transmission mechanisms that rely on pre-built static trust channels, resulting in delayed dynamic compliance verification, poor network adaptability and insufficient temporary trust support.

[0005] To achieve the above objectives, the present invention provides a method for cross-domain collaborative storage of cloud data, comprising the following steps: Step a: Based on one or more defined prohibitive transmission policies, compile and generate a set of violation behavior feature vectors, where each vector in the set of violation behavior feature vectors encodes a violation pattern; Step b: upon receiving a cross-domain data transmission request for cloud data, generating an instantaneous behavior feature vector based on the parameters of the request; performing an exclusive-OR operation to calculate the logical difference between the instantaneous behavior feature vector and each violation feature vector in the set of violation feature vectors, thereby obtaining a set of non-zero residual vectors; Step c: generating an instantaneous compliance residual proof based on a set of non-zero residual vectors and a random number, where the instantaneous compliance residual proof is a hash digest obtained by performing a cascade hash operation on the set of non-zero residual vectors and the random number; In step d, based on the verification result of the instantaneous compliance residual proof, decide whether to allow cross-domain data transmission. If the verification passes, the transmission is allowed; otherwise, the transmission is rejected.

[0006] Preferably, in step a, after the compilation of the violation feature vector set is completed, it is compressed and distributed to relevant terminal nodes.

[0007] Preferably, in step b, if the instantaneous behavior feature vector completely matches any violation behavior feature vector in the violation behavior feature vector set, the cross-domain data transmission request is terminated locally.

[0008] Preferably, the violation feature vector set has a version identifier, and the hash operation input of the instantaneous compliance residual proof generated in step c also includes the version identifier.

[0009] Preferably, when the verification of the instantaneous compliance residual proof fails due to inconsistent version identifiers, a violation feature vector set update process is triggered between communication nodes. The update process includes: the node with a lower version requests the latest violation feature vector set from the node with a higher version, and performs digital signature verification on the received violation feature vector set.

[0010] Preferably, it also includes: after step d, multiple network nodes build a point-to-point data routing path based on the instantaneous compliance residual proofs exchanged and verified by each other, by judging the distance, bandwidth, and load factors between nodes, and the construction of the routing path is achieved through autonomous negotiation between nodes.

[0011] Preferably, cross-domain data transmission is carried out in the form of a session, and the first request of the session strictly follows steps b and c to generate a baseline instantaneous compliance residual proof, which is cached by both communicating parties; for each subsequent request in the session, a difference vector is generated based on the difference between its instantaneous behavior feature vector and the baseline instantaneous behavior feature vector, and a residual calculation is performed. The residual calculation result is cascaded hashed with the previous verified instantaneous compliance residual proof and a random number to generate a new incremental instantaneous compliance residual proof, and the incremental instantaneous compliance residual proof forms a cryptographic link with the previous verified instantaneous compliance residual proof.

[0012] Preferably, the method further comprises: after step b, calculating a compliance residual pattern entropy for quantifying the compliance risk of the request based on the frequency distribution of each residual vector in a set of non-zero residual vectors. ,in, , represents the frequency of occurrence of a residual vector in a set of non-zero residual vectors, Represents the type of a residual vector.

[0013] Preferably, the cross-domain data transmission is routed to the isolated analysis environment based on the calculation result of the compliance residual pattern entropy, and the cross-domain data transmission is rate-limited based on the calculation result of the compliance residual pattern entropy.

[0014] A cloud data cross-domain collaborative storage system is characterized by comprising: a policy compilation module for compiling and generating a set of violation behavior feature vectors based on one or more defined prohibitive transmission policies, wherein each vector in the set of violation behavior feature vectors encodes a violation pattern; a request processing module for, upon receiving a cross-domain data transmission request initiated for cloud data, generating an instantaneous behavior feature vector according to the parameters of the request, and performing an exclusive-OR operation to calculate the logical difference between the instantaneous behavior feature vector and each violation behavior feature vector in the set of violation behavior feature vectors to obtain a set of non-zero residual vectors; a proof generation module for generating an instantaneous compliance residual proof based on a set of non-zero residual vectors and a random number, wherein the instantaneous compliance residual proof is a hash summary obtained by performing a cascade hash operation on a set of non-zero residual vectors and a random number; and a transmission decision module for deciding whether to allow cross-domain data transmission based on the verification result of the instantaneous compliance residual proof, wherein the transmission is allowed if the verification passes, and the transmission is rejected if the verification fails.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. Through the dynamic compilation of a set of violation feature vectors and an instantaneous residual proof mechanism, data streams carry verifiable compliance credentials during transmission. This transforms traditional cross-domain transmission that relies on pre-built trust channels into a process where compliance is independently proven by data behavior characteristics. When an edge node initiates a request, the locally calculated logical difference verifies the distance between its behavior and the prohibited rule through bit operations, and the fixed-length proof generated by the cascade hash allows any intermediate node to instantly verify without the need for a policy server, fundamentally avoiding the delay bottleneck and single point failure risk of centralized approval.

[0016] 2. When a node fails proof verification due to a policy version discrepancy, this event automatically triggers point-to-point vector set synchronization. Policy updates no longer rely on central push. Instead, they leverage business data streams to drive lower-version nodes to proactively pull the latest rules. This mechanism allows policy synchronization traffic to be naturally dispersed to business links when the network encounters emergency policy changes such as zero-day vulnerabilities, avoiding update storms while ensuring that all active nodes are always at the latest security baseline.

[0017] 3. For high-frequency continuous request scenarios, the baseline proof generated by the first request forms a cryptographic link with the incremental proof of subsequent requests in the session. Subsequent requests only need to calculate the difference component of the behavioral feature vector and generate a micro residual. The compliance of the previous proof is inherited through chain hashing. This mechanism transforms the computing overhead from a fixed cost to a dynamic cost that fluctuates with the business change rate. In scenarios with isomorphic requests such as continuous reporting by industrial equipment, the computing load of edge devices can be reduced by an order of magnitude, and the chain structure simultaneously ensures the operational integrity of the data flow in the time dimension.

[0018] 4. By periodically generating detective proofs through predefined virtual behavior feature vectors, communication nodes can actively verify the logical status of the link during periods when there is no business data transmission. When the node returns a valid proof to the health check request, it not only confirms the connectivity of the physical link, but also verifies the online status and version consistency of the peer policy engine. This design of reusing security mechanisms as operation and maintenance probes upgrades the traditional heartbeat packets that can only detect physical layer survival to continuous diagnosis of the transmission logic layer, and can detect hidden faults such as policy drift or man-in-the-middle attacks during the silent period. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a flow chart of the cloud data cross-domain collaborative storage method of the present invention; Figure 2 This is a comparison chart of network delay performance of the present invention; Figure 3 This is a flow chart of the generation and processing of the prohibitive transmission strategy of the present invention.

[0020] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0021] To enable those skilled in the art to better understand the technical solutions presented in the present invention, the present invention discloses a cloud data cross-domain collaborative storage method and system, whose overall architecture is logically mainly composed of a policy compilation module, a request processing module, a proof generation module and a transmission decision module operating in collaboration. Its core data flow starts with the policy compilation module converting a human-readable prohibitive transmission policy into a machine-executable set of violation behavior feature vectors. Then, upon receiving a cross-domain data transmission request, the request processing module generates an instantaneous behavior feature vector in real time and performs a high-speed logical comparison with the aforementioned violation vector set. The comparison result is then encapsulated by the proof generation module into a cryptographic certificate with self-certification capabilities. Finally, the transmission decision module makes an accurate release or blocking decision on the corresponding data transmission based on the verification result of the certificate.

[0022] In the specific execution process, in order to effectively deal with the common problems of dynamic compliance verification delay and insufficient network adaptability in existing technologies due to over-reliance on pre-built static trust channels in multi-domain collaborative scenarios such as smart city emergency response, the solution of the present invention is configured to first deeply analyze one or more prohibitive transmission policies by the policy compilation module; in this procedure, each abstract policy rule, such as prohibiting the transmission of sensitive data exceeding the quota from the medical database in domain A to the research institute in domain B during a specific period of time, will be deterministically parsed and encoded into a fixed-length binary vector, and the preset bit segments of this vector are strictly mapped to various key parameters of the request, such as source IP address range, target IP address range, user identity role, etc. , data type identification, data size threshold and even timestamp interval, etc., for any parameter value that meets the prohibition condition, its corresponding bit segment in the vector is set to logic 1, otherwise it is 0. In this way, each violation feature vector becomes an accurate digital portrait of a specific violation pattern; furthermore, in order to significantly improve the distribution efficiency and storage economy of the terminal node, the violation feature vector set will be efficiently compressed using standard algorithms such as run-length encoding or dictionary compression after complete compilation, and then distributed to the relevant terminal nodes through a secure channel for local deployment. This process precompiles the upper-level compliance requirements into underlying structured data that can support high-speed bit operations, so that subsequent data streams can achieve autonomous compliance certification during transmission. It has laid a solid foundation for the fundamental avoidance of the delay bottleneck inherent in the traditional centralized approval model. When any node in the network captures a cross-domain data transmission request initiated for cloud data, in order to achieve instant local verification of the compliance of the request, the request processing module will strictly follow the structural paradigm and encoding rules that are completely consistent with the violation behavior feature vector, and generate an instantaneous behavior feature vector based on the real-time parameters of the request; immediately thereafter, the system performs a batch XOR operation locally, and performs a logical difference calculation on this instantaneous behavior feature vector and each vector in the locally stored violation behavior feature vector set one by one; the deterministic judgment procedure here is that if the result of any one of the batch operations is an all-zero vector, it is clearly indicated that If the result of all XOR operations is non-zero, it proves that the behavior of the current request completely matches a preset prohibition pattern. The system will then determine that the request is an explicit violation and immediately terminate the subsequent processing of the cross-domain data transmission request locally without any external negotiation. Conversely, if the results of all XOR operations are non-zero, it proves that the behavior of the request does not directly violate any known prohibition rules. The system will then hand over the entire set of non-zero residual vectors generated to the proof generation module. Considering that security policies need to continuously evolve to cope with emerging new threats in dynamic collaborative tasks, the policy compilation module will attach a strictly unidirectionally increasing integer or high-precision timestamp as a version identifier when generating the violation behavior feature vector set. This identifier will also be distributed along with the vector set.Accordingly, upon receiving the set of non-zero residual vectors, the proof generation module first obtains a high-entropy random number from a hardware random number generator. It then deterministically concatenates this random number, the set of non-zero residual vectors, and the aforementioned version identifier. Using this concatenated long binary sequence as the sole input, it performs a standard cryptographic hash function operation, such as SHA-256. The result, a fixed-length hash digest, constitutes the instantaneous residual proof of compliance for the request. This design generates a compact and unforgeable proof that not only cryptographically binds the logical distance between the request and all known rule sets but, more importantly, embeds the policy version snapshot information, allowing any receiving node to efficiently verify the compliance and timeliness of the data stream without having access to the full policy context.

[0023] After receiving the data stream with the instant compliance residual proof, the transmission decision module follows a set of strict automated closed-loop procedures for verification and decision-making. The procedures are designed to eliminate the security shortcomings or coordination barriers that may be caused by inconsistent policy versions of each node in the distributed network. The verification node first separates the received proof from the data stream itself, and then retrieves the set of violation feature vectors stored locally, and combines the real-time parameters of the data stream and the local policy version identifier to repeat the aforementioned proof generation process completely independently. If the hash summary calculated locally and the proof attached to the data stream can achieve bit-level accuracy, the verification is passed and the transmission is released without delay. Otherwise, the verification is successful. Failure and rejection of transmission; It should be noted that when the root cause of the verification failure is traced back to the inconsistency of the version identifiers of the communicating parties, the event will deterministically trigger a built-in policy synchronization subroutine. This subroutine stipulates that the node holding the lower version of the policy must automatically initiate a request to the peer node holding the higher version to pull the latest set of violation feature vectors. After receiving the new vector set, the node must first perform strict cryptographic verification on the attached digital signature. Only after confirming that its source is credible and the content is complete and not tampered with, is it allowed to replace the local outdated policy version. This point-to-point adaptive policy update mechanism driven by business data flow The system enables security policies to be self-propagated and synchronized in active communication links in a timely and efficient manner, thereby maintaining a high degree of consistency in the security baseline of the entire cross-domain network while continuously ensuring the openness of the system. Furthermore, in order to fine-tune the computing power consumption in high-frequency continuous request scenarios, such as the continuous data reporting of sensor arrays in the industrial Internet of Things, the system abstracts such transmissions into a session with a lifecycle for management; the initial request of the session will strictly follow the aforementioned complete steps to generate a benchmark instantaneous compliance residual proof. Once the benchmark proof is verified, it will be cached by both communicating parties as the trust anchor point of the session; for each request within the lifecycle of this session, For a subsequent request, the system no longer constructs a complete instantaneous behavior feature vector. Instead, it calculates the difference between the behavior feature vector and the previously verified request, generating a more streamlined difference vector. The system then performs residual calculations on this difference vector. The system then concatenates the residual result with the hash value of the previously verified instantaneous compliance residual proof and a newly generated random number to generate a new incremental instantaneous compliance residual proof. Because the input for each incremental proof includes the output of the previous proof, this constructs a logically and cryptographically unalterable hash chain between all proofs in the session.This design cleverly transforms computational costs from a fixed overhead related to the size of the policy set to a dynamic overhead that is positively correlated with the rate of change of the business data flow. In scenarios where homogeneous requests predominate, this can reduce the computational load on edge devices by more than an order of magnitude. Furthermore, through chain-like synchronization, the logical coherence and non-repudiation of data operations throughout the session are ensured.

[0024] In addition, in order to achieve the evolution from the traditional binary judgment of compliance or violation to more flexible and refined risk quantification and adaptive routing control, the system also deeply integrates a real-time risk assessment mechanism based on information entropy; after the request processing module generates a set of non-zero residual vectors, but before generating the final cryptographic proof, the system will insert a statistical analysis link, that is, calculate the distribution pattern of this set of residual vectors to obtain a compliance residual pattern entropy used to quantify the compliance risk of the current request. , its calculation formula is strictly defined as , here, represents a specific mode or type of residual vector, and It refers to the frequency of this type of residual vector in the entire set of non-zero residual vectors generated by the current request; an extremely low entropy value close to zero usually means that the pattern of the residual vector is highly uniform and repetitive. This statistical anomaly is very likely to indicate an automated attack behavior aimed at detecting the boundaries of a specific policy; for this reason, the system presets a dynamically adjustable compliance entropy lower limit threshold, and the initial calibration procedure for this threshold is as follows: in the initial stage of system deployment, the combined residual pattern entropy generated by normal business traffic over a period of time is collected, and the fifth percentile of its overall statistical distribution is taken as the initial reference value of the security baseline; when a new request calculates the entropy of When the value is lower than this threshold, the transmission decision module will no longer perform the default release operation, but will automatically trigger the preset high-risk response plan. Its specific measures include but are not limited to: immediately routing the cross-domain data transmission to an isolated analysis environment equipped with deep packet inspection and sandbox behavior analysis tools for further review, or directly imposing strict dynamic rate limits on the data transmission session; by introducing this mechanism, the system can not only effectively defend against known and well-defined violations, but also has the ability to proactively identify and intelligently control potential unknown threats that exhibit statistical anomalies, thereby significantly improving the in-depth defense level of the overall architecture.

[0025] The violation feature vector is composed of a 256-bit fixed-length binary string. Its field division and mapping rules are loaded by the system preset template file during the initialization configuration phase. The template file is organized in a field-by-field bit mask mode. Each field is mapped one-to-one with the parameters in the actual transmission request through a set of clearly defined value ranges. Bits 0 to 31 are used to represent the source IP address segment, which is encoded by truncating the prefix length matching bit after parsing the source address in CIDR format. Bits 32 to 63 are used for the target IP address segment, which is mapped in the same way as the source address. Bits 64 to 79 are used for port number field encoding, which uses interval segmentation based on 16-bit integers and binary mapping of the segment numbers. Bits 80 to 111 represent the user identity field, which converts the user identifier into a 12-bit fixed code through a table lookup method. Bits 112 to 143 are data type and confidentiality level encoding fields, which are divided into three levels. The level coding structure is used to express the sensitivity level and business classification. Bits 144 to 175 are used to indicate the time period segment that the request timestamp falls into. The segment is obtained by dividing a day into several fixed intervals and mapping them with numbers. Bits 176 to 223 are the data size field, which uses logarithmic quantization and segmented encoding to generate a bit mask. Bits 224 to 255 are reserved for expressing the policy version, session status or subsequent extension fields. Each violation behavior feature vector is generated by the policy parser according to the above field segments based on the policy source text. All mask rules, field offsets and mapping relationships involved in the generation process are defined by fixed templates in the configuration file and their integrity check values are calculated by the verification tool before deployment for consistency verification; the compliance residual pattern entropy used to quantify the compliance risk of cross-domain requests takes a set of non-zero residual vectors as input, where each residual vector is abstracted as a discrete pattern category type. The category is determined by hash mapping based on the high-frequency bit segment in the 256-bit vector. During the initialization phase, the system records the residual vector sequence set generated by real requests within 48 consecutive hours without business intrusion. , for each of these patterns Count its frequency , and calculate the entropy value , sort the entropy value sequence obtained by the statistical process and extract the 5th percentile as the initial threshold This threshold is fixed in the system configuration and serves as the benchmark reference value for all subsequent requests. When the entropy value generated by any subsequent request is lower than When a high-risk candidate is found, the system marks the request as a high-risk candidate and triggers the isolation analysis process, which includes importing the data stream mirror into the sandbox analysis engine and suspending the main path transmission process. At the same time, the trigger event will start local logging and perform sliding window statistical analysis on the residual pattern sequence in the last hour. If three consecutive triggers fall into the same residual pattern main category, the system will automatically update the category to a silent threat candidate pattern through the local marking mechanism and push it to the policy analysis module to generate additional restriction rules. The frequency statistics, sliding window length, category mapping, entropy function definition and threshold selection involved in the whole process are strictly fixed by the system initialization parameters and business debugging logs and cannot be changed.

[0026] The policy compilation and routing cost measurement procedures of the present invention are as follows: all prohibitive transmission policies are first converted into disjunctive normal form, in which each minimum term containing only logical AND generates an independent 256-bit violation behavior feature vector; in this vector, the IP address field is filled with its network prefix according to the CIDR notation in the policy and the remaining bits are filled with all 1 bits as wildcards; discrete value fields such as user identity and data confidentiality are converted by table lookup based on the entity coding mapping table loaded during system initialization; continuous value fields such as data size and timestamp are mapped to corresponding interval codes based on the preset logarithmic segmentation quantization table and time slice coding table; at the same time, the cost measurement value of the point-to-point data routing path is The weight coefficient in and The business profile configured during node initialization is uniquely determined, where the delay-sensitive profile setting , computing resource-constrained portrait setting , while the balanced portrait sets ; Compliance residual pattern entropy used to quantify the compliance risk of a request Alarm threshold The calibration process follows an offline, statistics-based automated calibration procedure. The input of the procedure is a compliant residual pattern entropy sample dataset recorded during the baseline learning period, which only contains normal business requests. The process first calculates the complete statistical distribution of the dataset and sets the initial threshold to the fifth percentile of the dataset. Then, during a supervision and debugging period containing known attack samples, if the false alarm rate generated by the current threshold is higher than the preset upper limit of 0.5%, the threshold is lowered by one percentile. If the false alarm rate of known attacks is higher than the preset upper limit of 0.1%, the threshold is raised by one percentile. This iterative adjustment is carried out until the false alarm rate and the false alarm rate are both lower than their respective upper limits. At that time, the final threshold formed will be solidified and used as the benchmark reference value for all subsequent requests.

[0027] Example 1: In a specific city-level emergency response deployment, a large-scale toxic gas leak occurred in a chemical park. The emergency command center needed to immediately integrate data from multiple units belonging to different government cloud domains, such as transportation, environmental protection, meteorology, medical care, and fire protection, to carry out emergency evacuation, demarcate the scope of pollution, conduct atmospheric diffusion modeling, and guide medical treatment. The fundamental challenge of this scenario is that there are no pre-established dedicated data transmission channels and authorization policies between the various units for such sudden, cross-domain, and large-scale events. If the traditional process of online step-by-step approval and offline configuration of network firewalls and virtual private network tunnels is followed, it will inevitably result in decision-making and execution delays of several hours. In emergency rescue where every second counts, such delays are directly related to the loss of life and property. At the same time, temporarily opening network ports in an emergency state provides a penetration window for potential network attacks, which can easily lead to secondary disasters such as tampering or leakage of critical data.

[0028] Under this working condition, the technical solution of the present invention is activated. When the mobile monitoring vehicle deployed by the environmental protection department at the scene of the accident, as a temporary network node, attempts to upload real-time toxic gas concentration data to the traffic command center belonging to another cloud domain for the first time, the request is intercepted at the boundary node of the traffic domain. The node does not reject it due to the lack of a preset static trust relationship, but requires that the data stream must carry a valid instantaneous compliance residual certificate; at this time, on the terminal of the mobile monitoring vehicle, the request processing module immediately generates an instantaneous behavior feature vector based on the parameters of this transmission, and performs a logical difference operation with the emergency response violation feature vector set with the latest version identification that was urgently compiled and distributed to the entire network by the command center after the accident. Given that the request belongs to compliant emergency data, its instantaneous behavior feature vector The quantity does not match all known violation patterns, thus generating a set of non-zero residual vectors; the design of this mechanism avoids the inherent contradiction between openness and security in emergency scenarios. The initiation of data transmission no longer depends on the pre-establishment of a static secure channel, achieving extreme agility at the business level, and security is implemented through strict verification of the unforgeable cryptographic proof carried by each data stream, so that the system architecture itself avoids the traditional trust paradox. Furthermore, the deep value of this solution lies in the inherent synergy and efficiency formed between its multiple technical features. In the above scenario, the proof generation module generates an instantaneous compliance residual proof based on the set of non-zero residual vectors, allowing data to be transmitted across domains. However, the system does not stop there, and simultaneously starts a process based on the compliance residual pattern entropy. risk assessment mechanism; at this time, if a potential attacker attempts to exploit the permission window during the emergency period and send a large number of exploratory requests with similar structures and slightly deviating from the compliance policy to find system vulnerabilities, although these requests can also generate non-zero residual vectors and pass the primary compliance check, the residual vector patterns they generate will show extremely low entropy values due to their high repetitiveness and purposefulness; the system's built-in risk assessment logic, by continuously calculating and monitoring the entropy values of the session, can capture such abnormal signals from the statistical level and calculate the low entropy values. The value is used as a high-risk indicator, which automatically triggers the decision to route the suspicious session to an isolated analysis environment. Here, the instantaneous compliance residual proof mechanism provides high-quality, standardized input for the calculation of compliance residual pattern entropy, namely a set of non-zero residual vectors, which in turn provides the former with a key layer of in-depth defense based on statistical behavior patterns, ensuring that while opening dynamic permissions, it can effectively resist advanced persistent threats that exploit this openness. The combination of the two technical features makes the overall security capabilities of the system surpass the linear superposition of their independent operations.

[0029] Ultimately, this technical solution demonstrates significant architectural differences by redefining the problem itself. Traditional solutions focus on solving the nearly unsolvable engineering challenge of pre-building and managing thousands of potential secure channels between different entities in certain emergency scenarios. This invention, however, transforms the problem into how to enable any piece of data to autonomously and reliably prove its compliance when transmitted over any channel. By separating security attributes and trust relationships from the static network infrastructure and embedding them as inherent, dynamically verifiable properties of the data stream itself, the original channel management challenge is effectively circumvented under the new technical paradigm. As a result, emergency response can establish a cross-departmental, secure and reliable data lifeline within minutes, and the command center can obtain panoramic information about the accident scene in near real time to make scientific decisions, providing technical support for minimizing accident damage. Its design philosophy is that trust should not be a static assignment of network physical or logical topology, but a dynamic, self-verified result of every data behavior.

[0030] Example 2: This example aims to test the construction of a platform aimed at reproducing a typical industrial Internet of Things cross-domain data collection scenario. The platform consists of an edge device node, a gateway node and a central policy server. The edge device node uses a resource-constrained embedded computing unit, and the gateway node and the central policy server are deployed on standard server hardware. The three are interconnected through a local area network that can precisely control network latency. The key parameter in the experiment is the size of the set of violation feature vectors. Its setting needs to be balanced between the sophistication of the security policy and the computing load of the edge node. Given that a medium-sized industrial partition usually involves hundreds of independent access control rules, in order to ensure effective coverage of the security policy, this experiment sets the set to contain 1024 independent violation feature vectors. Another key parameter is the effective duration of the session. Its setting is based on the consideration between computing efficiency and the frequency of security re-authentication. Based on the procedures that industrial monitoring data usually require minute-level status confirmation, this experiment sets the session duration to 60 seconds to verify the efficiency gain of the incremental proof mechanism within this time window.

[0031] The experiment was conducted in two phases. The first phase was the control group, which adopted a traditional centralized verification model. Under this model, the edge device node continuously sent 1KB of simulated data to the gateway node at a frequency of 100 packets per second. After receiving each packet, the gateway node must forward its metadata to the central policy server for permission verification. Data processing is completed only after receiving the approval receipt from the central server. The second phase was the verification group of the solution of the present invention. The edge device and the gateway node ran the technical solution of the present invention and adopted exactly the same packet sending frequency and data size. In this phase, the first packet in the session triggered the generation of the baseline instantaneous compliance residual proof, while subsequent packets in the session adopted the incremental instantaneous compliance residual proof mechanism. The experimental process recorded the end-to-end delay from the edge device to the gateway node confirming receipt and verification, as well as the real-time CPU occupancy rate of the edge device and gateway node. By injecting different fixed delays into the test network, the impact of network conditions on the performance of the two solutions was further observed. The core data is shown in Table 1.

[0032] Table 1: Performance comparison data under different verification mechanisms

[0033] As shown in Table 1, under the centralized verification model, the average end-to-end latency exhibits a strong linear correlation with the network injection delay. When the network delay is 100ms, single-packet verification takes over 200ms. In contrast, the incremental instantaneous compliance residual proof in the present invention maintains an end-to-end latency consistently below 1ms and is largely unaffected by network injection delay. This performance is due to the fact that the verification process of the incremental proof is a purely local computational task. It transforms the verification logic of the traditional model, which relies on network round trips, into a local hash comparison, thus circumventing the constraints of network latency. The data also reveals the computational cost structure of this solution. Generating the first-packet baseline proof causes a significant CPU usage spike at the edge, exceeding 25%. This is the initial computational overhead of establishing the session trust anchor. However, during the remainder of the session, the CPU usage for generating the incremental proof drops to around 3.5%, demonstrating the effectiveness of the session mechanism in amortizing computational costs.

[0034] Example 3: This example combines Figures 1 to 3 , a cloud data cross-domain collaborative storage method and system are illustrated with drawings, such as Figure 1 As shown in the figure, the process includes the entire process from policy management to data transmission. First, when defining and generating a transmission policy, the policy administrator will compile the prohibitive transmission rules through the policy compilation module, and generate corresponding violation behavior feature vector sets based on these rules. These vector sets will be processed by the compression module to generate data sets that can be used later. Next, the distribution server is responsible for distributing these processed data to each terminal node, such as terminal node A, terminal node B and terminal node C. After each terminal node receives the data, terminal node A will establish a secure channel and exchange and verify data with terminal node B and terminal node C to ensure the compliance of the transmission process. At the same time, the terminal node will also store the data locally for verification, and ensure that the data transmission does not violate the established rules through verification steps.

[0035] like Figure 2As shown in the figure, the horizontal axis represents the network injection delay (ms) and the vertical axis represents the average transmission delay (ms). As can be seen from the figure, with the increase of network injection delay, the average transmission delay of centralized verification shows a significant increasing trend. In particular, when the network injection delay is high, the delay value rises rapidly, up to nearly 300ms. Under the scheme of the present invention, the transmission delay of the two verification methods - the first packet benchmark proof of the present invention and the session incremental proof of the present invention always remains at a low level and is almost unaffected by the network injection delay. Specifically, the delay of centralized verification increases linearly with the increase of network injection delay, especially when the network injection delay is 100ms, the delay increase is obvious. In contrast, the average delay of the first packet benchmark proof of the present invention and the session incremental proof of the present invention changes less. Even under higher network injection delays, the average delay is always controlled below 10ms. The delay performance of the session incremental proof of the present invention is the best, showing extremely low average transmission delay under different network delay conditions.

[0036] like Figure 3 As shown, first, the prohibitive transmission policy is parsed by the policy parser, and then enters the parameter type identification link, which distinguishes according to the type of parameter. First, the IP bit segment code is generated according to the source / destination address, and then the user identity will generate the role identification code, and the data type will generate the type level code. Based on this information, the corresponding 256-bit vector is generated. The generated vector will be further processed by the policy parser and enter the step of generating a 256-bit vector, and then enter the stage of executing the behavior feature vector set. Finally, after compression and distribution, the policy will be sent to the relevant nodes in a compressed format for application.

[0037] Example 4: In a deployment that requires establishing a cross-domain, real-time, high-security transaction data exchange network between multiple independent financial institutions, the challenge is to meet the complex and dynamically evolving prohibitive transmission policies issued by regulatory agencies, and to achieve performance optimization and fault self-healing of data routing under the premise of a decentralized network operation and management center. This requires the technical solution of the present invention to have clear policy encoding procedures, risk threshold adaptive calibration methods, and distributed routing negotiation mechanisms.

[0038] To achieve this function, the internal data structure of the violation behavior feature vector and the instantaneous behavior feature vector, which serve as policy carriers, needs to be defined in the initial stage of system deployment. In a specific configuration, the vector is set to a 256-bit fixed-length binary string, which is divided into multiple logical fields. Bits 0-127 are used to encode the source and target IPv6 addresses, bits 128-159 are used to encode the source and target port numbers, bits 160-191 are used to encode the user identity, bits 192-223 are used to encode the data type and confidentiality level, and bits 224-227 are used to encode the source and target port numbers. Bits 4-255 are used to encode timestamps and session status. Based on this structural definition, the policy compilation module follows a set of conversion procedures to convert human-readable prohibitive transmission policies into binary violation feature vectors. For a risk control rule that prohibits trader A from initiating a single derivative transaction request exceeding RMB 1 million to any counterparty institution with a rating lower than AA- between 17:00 and 9:00 the next day Beijing time, the compilation module first converts the trader A, the list of rating institutions below AA-, the derivative transaction type, Logical objects such as amounts greater than 1 million are converted into binary values such as specific IP address segments, user identity codes, and data type codes by consulting the system's built-in entity identity and address mapping table. These values are then used as bit masks to set the corresponding bits of the corresponding fields in the violation feature vector to 1. Continuous values such as time ranges are converted into discrete timestamp interval codes. For any such wildcards, all bits of the corresponding fields are set to 1. In this way, each logical rule is compiled field by field into a binary violation pattern that can be machine-operated on. The specific policy vectorization procedure is to decompose the human-readable prohibitive policy using disjunctive normal form, converting complex rules containing logical ORs into multiple independent minimal terms containing only logical ANDs, each of which generates an independent violation feature vector. For field codes within the vector, continuous values such as data size are quantized using logarithmic segmentation, and timestamps are discretized and mapped according to the preset time slice width, thus converting all judgment conditions into binary bit operations. When constructing a point-to-point data routing path, its cost metric value is used. The weight coefficient in and It is determined by the business profile configuration of the node, where is the normalized value of the node's current CPU load, The normalized value of the network round-trip delay between it and the source node of the routing request. The system administrator specifies a business profile for it when the node is initialized. For example, the delay-sensitive profile will be automatically set , while the computing resource-constrained profile will automatically set , so that routing decisions are made based on a set of preset, deterministic rules; compliance residual pattern entropy is used to quantify the compliance risk of requests Alarm threshold The calibration process follows an offline, statistically based calibration process. The input of this process is a sample data set of compliance residual pattern entropy generated by all normal business transactions recorded by the system during a baseline learning period. The process first calculates the complete statistical distribution of the data set and sets the initial alarm threshold Set to the fifth percentile of the data set; then, during a preset supervision and debugging period, the system records all events with entropy values below the threshold as alarms to be reviewed. If the alarm false alarm rate during this period is higher than a configurable upper limit, the alarm threshold It will be lowered to the next percentile. If a missed alarm occurs where a known attack does not trigger an alarm, the threshold will be raised to a preset safety margin below the entropy value of the attack. This iterative process terminates after the supervision and debugging period. The final threshold formed at that time will be solidified and an automated response strategy will be enabled, thereby ensuring that the threshold is a direct product of the statistical characteristics of the network's own behavior.

[0039] In addition, to achieve the function of building a point-to-point data routing path, this solution adopts a distributed routing negotiation protocol based on cost metric. When node A needs to send a large data block to node D, and the instantaneous compliance residual proof carried by its first data packet has been verified by neighboring nodes B and C, node A broadcasts a routing request packet containing the final target D identifier and a unique session ID to B and C; after receiving the request, nodes B and C each calculate a routing cost metric value. , and its calculation procedure is ,in is the current CPU load percentage of the node, The network round trip delay between it and the source node of the routing request broadcast, and It is a system-preset normalization coefficient used to adjust the weight of computing cost and network cost; nodes B and C then attach their own node identification and calculated cost metric to the received routing request packet. , and continues to forward it to its verified compliance neighbor nodes until the route request packet finally reaches the target node D; within the set short time window, the target node D may receive multiple route requests from different paths with cumulative costs. It will choose the path with the lowest cumulative cost and return a route confirmation packet along the original path. After receiving the confirmation, all nodes on the path establish a temporary data transmission channel to serve the session.

[0040] Example 5: To ensure the continued health of the network and the real-time effectiveness of policies, this embodiment uses a logical link status diagnostic procedure based on exploratory proofs during the operation and maintenance phase. Each node in the network is configured to automatically generate and broadcast a exploratory proof to all known neighboring nodes according to a system-preset period. The proof is generated from a virtual behavior feature vector, a special vector that is pre-set in the set of violation behavior feature vectors during the compilation phase. The data type field within the vector is set to a reserved code specifically for network diagnosis. The node periodically uses this virtual vector as input to execute the process of generating an instantaneous compliance residual proof and sends the generated proof. After receiving the exploratory proof, the neighboring node verifies it. Passing the verification not only indicates the connectivity of the physical network, but also confirms that the policy engine of the sending node is online and active and that the set of violation behavior feature vectors it holds is consistent with the receiving node's version. If a node fails to receive a valid exploratory proof from a neighboring node within three consecutive periods, the node will be marked as logically faulty, triggering an alarm or route replanning in the upper-layer application.

[0041] In addition, to ensure the root security of the entire trust system, any new node must execute a set of offline pre-configuration and identity injection procedures before being incorporated into the network. In a physically isolated secure environment, a unified configuration and signature issuing authority generates a unique public-private key pair for the node to be connected to the network, and signs the node's public key together with its identity information with the issuing authority's root private key to form the node's device identity certificate; subsequently, the device identity certificate, the issuing authority's root public key and the node's private key are written together into an anti-tampering security module on the node's hardware; when the node is actually deployed and running in the future, when receiving any new violation feature vector set update, it will first use the preset and unchangeable issuing authority root public key in its security module to verify the legitimacy of the update package's digital signature. Only when the verification is passed can it be proved that the policy update comes from a trusted issuing authority, thereby ensuring the secure closed loop of the entire policy distribution and update chain.

[0042] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0043] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A cloud data cross-domain collaborative storage method, characterized in that: The method comprises the following steps: Step a: Based on one or more defined prohibitive transmission policies, compile and generate a set of violation behavior feature vectors, where each vector in the set of violation behavior feature vectors encodes a violation pattern; Step b: upon receiving a cross-domain data transmission request for cloud data, generating an instantaneous behavior feature vector based on the parameters of the request; performing an exclusive-OR operation to calculate the logical difference between the instantaneous behavior feature vector and each violation feature vector in the set of violation feature vectors, thereby obtaining a set of non-zero residual vectors; Step c: generating an instantaneous compliance residual proof based on a set of non-zero residual vectors and a random number, where the instantaneous compliance residual proof is a hash digest obtained by performing a cascade hash operation on the set of non-zero residual vectors and the random number; In step d, based on the verification result of the instantaneous compliance residual proof, decide whether to allow cross-domain data transmission. If the verification passes, the transmission is allowed; otherwise, the transmission is rejected.

2. A cloud data cross-domain collaborative storage method according to claim 1, characterized in that: In step a, after the violation feature vector set is compiled, it is compressed and distributed to the relevant terminal nodes.

3. A cloud data cross-domain collaborative storage method according to claim 1, characterized in that: In step b, if the instantaneous behavior feature vector completely matches any violation behavior feature vector in the violation behavior feature vector set, the cross-domain data transmission request is terminated locally.

4. A cloud data cross-domain collaborative storage method according to claim 1, characterized in that: The set of violation feature vectors has a version identifier, and the hash operation input of the instantaneous compliance residual proof generated in step c also contains the version identifier.

5. A cloud data cross-domain collaborative storage method according to claim 4, characterized in that: When the verification of the instantaneous compliance residual proof fails due to inconsistent version identifiers, the violation feature vector set update process between the communication nodes is triggered. The update process includes: the node with a lower version requests the latest violation feature vector set from the node with a higher version, and digital signature verification is performed on the received violation feature vector set.

6. A cloud data cross-domain collaborative storage method according to claim 1, characterized in that: Also includes: After step d, multiple network nodes build a point-to-point data routing path based on the instantaneous compliance residual proofs exchanged and verified by each other, by judging the distance, bandwidth, and load factors between nodes. The construction of the routing path is achieved through autonomous negotiation between nodes.

7. A cloud data cross-domain collaborative storage method according to claim 1, characterized in that: Cross-domain data transmission is carried out in the form of a session. The first request of the session strictly follows steps b and c to generate a baseline instantaneous compliance residual proof, which is cached by both communicating parties. For each subsequent request in the session, a difference vector is generated based on the difference between its instantaneous behavior feature vector and the baseline instantaneous behavior feature vector, and a residual calculation is performed. The residual calculation result is cascaded hashed with the previous verified instantaneous compliance residual proof and a random number to generate a new incremental instantaneous compliance residual proof. The incremental instantaneous compliance residual proof forms a cryptographic link with the previous verified instantaneous compliance residual proof.

8. A cloud data cross-domain collaborative storage method according to claim 1, characterized in that: Also includes: After step b, a compliance residual pattern entropy is calculated based on the frequency distribution of each residual vector in a set of non-zero residual vectors to quantify the compliance risk of the request. ,in, , represents the frequency of occurrence of a residual vector in a set of non-zero residual vectors, Represents the type of a residual vector.

9. A cloud data cross-domain collaborative storage method according to claim 8, characterized in that: Based on the calculation results of the compliance residual pattern entropy, cross-domain data transmission is routed to the isolated analysis environment, and based on the calculation results of the compliance residual pattern entropy, the rate of cross-domain data transmission is limited.

10. A cloud data cross-domain collaborative storage system, characterized in that: The system comprises: a policy compilation module, configured to compile and generate a set of violation behavior feature vectors based on one or more defined prohibitive transmission policies, wherein each vector of the set of violation behavior feature vectors encodes a violation pattern; a request processing module, configured to, upon receiving a cross-domain data transmission request for cloud data, generate an instantaneous behavior feature vector based on the request parameters, perform an exclusive-OR operation, and calculate the logical difference between the instantaneous behavior feature vector and each violation feature vector in the set of violation feature vectors to obtain a set of non-zero residual vectors; a proof generation module for generating an instantaneous compliance residual proof based on a set of non-zero residual vectors and a random number, wherein the instantaneous compliance residual proof is a hash digest obtained by performing a cascade hash operation on the set of non-zero residual vectors and the random number; A transmission decision module is used to decide whether to allow cross-domain data transmission based on the verification results of the instantaneous compliance residual proof. If the verification passes, the transmission is released; if the verification fails, the transmission is rejected.

Images