A method and system for cross-domain collaborative cloud data storage

Abstract

This invention relates to the field of digital information transmission technology and discloses a cloud data cross-domain collaborative storage method and system, comprising: compiling a prohibited transmission policy into a set of violation behavior feature vectors; calculating the logical difference between the behavior feature vectors and the violation vectors to generate a compliance certificate when making a cross-domain request; and controlling data transmission based on the certificate verification result. This invention replaces the traditional pre-built trust channel with a behavior feature self-certification mechanism, enabling the data stream to autonomously prove its compliance during transmission. At the same time, it achieves viral synchronization of the policy with the help of version identifiers, ensuring both openness and policy consistency in dynamic scenarios such as emergency response, and solving the problems of centralized approval delays and single points of failure.

Description

Technical Field

[0001] This invention relates to a cloud data cross-domain collaborative storage method and system, belonging to the field of digital information transmission technology. Background Technology

[0002] In the field of digital information transmission technology, cross-domain collaborative storage of cloud data needs to rely on pre-built trusted channels to achieve secure transmission. For example, a static secure connection is pre-established through a centralized gateway or tunnel, and permission verification is performed by a centralized policy service. Although this model is widely used, it has a fundamental limitation: it binds dynamic compliance decisions to static network infrastructure, 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 grid, need to coordinate emergency data in real time, existing technologies face three core contradictions: 1. Emergency requests often require dynamic combination of cross-domain permissions, while traditional pre-approval processes require online approval from multiple departments, causing delays in critical decisions; 2. Extreme environments can easily lead to node failures, and static tunnels lack adaptive routing capabilities, causing disruptions to the collaborative link; 3. Social resource nodes, such as those temporarily requisitioning cameras, need limited participation in the collaboration, but centralized architectures cannot support temporary and incomplete trust relationships. Industry attempts to alleviate these problems by strengthening the policy execution layer or optimizing encryption protocols have further exacerbated system complexity and failed to eradicate the fundamental flaw of decoupling compliance verification from data transmission. Summary of the Invention

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

[0005] To achieve the above objectives, the present invention provides a cloud data cross-domain collaborative storage method, comprising the following steps:

[0006] Step a: Based on one or more defined prohibited 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;

[0007] Step b: When a cross-domain data transmission request for cloud data is received, an instantaneous behavior feature vector is generated based on the parameters of the request; an XOR operation is performed 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, resulting in a set of non-zero residual vectors.

[0008] Step c: Based on a set of non-zero residual vectors and a random number, generate an instantaneous compliance residual proof. The instantaneous compliance residual proof is a hash digest obtained by performing a concatenated hash operation on a set of non-zero residual vectors and a random number.

[0009] Step d: Based on the verification result of the instantaneous compliance residual proof, decide whether to allow cross-domain data transfer. If the verification passes, the transfer is allowed; if the verification fails, the transfer is rejected.

[0010] Preferably, in step a, the set of feature vectors of violations is compressed and distributed to relevant terminal nodes after compilation.

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

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

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

[0014] Preferably, the method further includes: after step d, multiple network nodes construct point-to-point data routing paths by judging the distance, bandwidth, and load factors between nodes based on the instantaneous compliance residual proofs exchanged and verified by each other. The construction of the routing paths is achieved through autonomous negotiation between the nodes.

[0015] Preferably, cross-domain data transmission is conducted in the form of a session. The first request in 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 behavioral feature vector and the baseline instantaneous behavioral feature vector, and residual calculation is performed. The result of the residual calculation is concatenated with the previously 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 previously verified instantaneous compliance residual proof.

[0016] Preferably, the method further includes: after step b, calculating a compliance residual pattern entropy for quantifying the compliance risk of a request, based on the frequency distribution of each residual vector in a set of non-zero residual vectors. ,in, , This represents the frequency of occurrence of a particular residual vector within a set of non-zero residual vectors. This indicates the type of a certain residual vector.

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

[0018] A cloud data cross-domain collaborative storage system, characterized by comprising: a policy compilation module, used to compile and generate a set of violation behavior feature vectors based on one or more defined prohibited transmission policies, each vector in the set encoding a violation pattern; a request processing module, used to, upon receiving a cross-domain data transmission request initiated for cloud data, generate an instantaneous behavior feature vector based on the request parameters, and perform an XOR operation to calculate the logical difference between the instantaneous behavior feature vector and each violation behavior feature vector in the set, obtaining a set of non-zero residual vectors; a proof generation module, used to generate an instantaneous compliance residual proof based on a set of non-zero residual vectors and a random number, the instantaneous compliance residual proof being a hash digest obtained by concatenated hashing of a set of non-zero residual vectors and a random number; and a transmission decision module, used to decide whether to allow cross-domain data transmission based on the verification result of the instantaneous compliance residual proof, allowing transmission if verification passes and rejecting transmission if verification fails.

[0019] Compared with the prior art, the beneficial effects of the present invention are:

[0020] 1. Through the dynamic compilation of the feature vector set of violation behavior and the instantaneous residual proof mechanism, the data stream carries verifiable compliance credentials during transmission. This transforms the traditional cross-domain transmission that relies on pre-built trust channels into a process in which data behavior features autonomously prove their compliance. When an edge node initiates a request, the locally calculated logical difference verifies the distance between its behavior and the prohibited rules through bitwise operations. The fixed-length proof generated by cascaded hashing allows any intermediate node to instantly verify without a policy server, fundamentally avoiding the latency bottleneck and single point of failure risk of centralized approval.

[0021] 2. When a node fails to verify proof due to policy version differences, the event automatically triggers point-to-point vector set synchronization. Policy updates no longer rely on central push, but instead use business data flow to drive lower version nodes to actively pull the new rules. This mechanism ensures that when the network encounters emergency policy changes such as zero-day vulnerabilities, policy synchronization traffic is naturally distributed to the business link, which avoids update storms and ensures that all active nodes are always at the latest security baseline.

[0022] 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 components of the behavioral feature vector and generate micro residuals. The compliance of the previous proof is inherited through chained hashing. This mechanism transforms the computational cost from a fixed cost to a dynamic cost that fluctuates with the rate of business change. In the scenario of continuous reporting of isomorphic requests by industrial equipment, the computational load of edge devices can be reduced by an order of magnitude, and the chained structure synchronously ensures the operational integrity of the data stream in the time dimension.

[0023] 4. By periodically generating probing proofs through predefined virtual behavior feature vectors, communication nodes can proactively verify the logical state of the link during periods of no business data transmission. When a node returns a valid proof to a health check request, it confirms both the physical link connectivity and verifies the online status and version consistency of the peer's policy engine. This design, which reuses security mechanisms as operation and maintenance probes, upgrades the traditional heartbeat packets that can only detect physical layer liveness to continuous diagnosis of the transmission logic layer, enabling the detection of hidden faults such as policy drift or man-in-the-middle attacks during quiet periods. Attached Figure Description

[0024] Figure 1 This is a flowchart of the cloud data cross-domain collaborative storage method of the present invention;

[0025] Figure 2 This is a comparison chart of network latency performance of the present invention;

[0026] Figure 3 This is a flowchart illustrating the generation and processing of the prohibited transmission strategy of this invention.

[0027] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0028] To enable those skilled in the art to better understand the technical solutions presented in this invention, this invention discloses a cloud data cross-domain collaborative storage method and system. Logically, its overall architecture mainly consists of a policy compilation module, a request processing module, a proof generation module, and a transmission decision module working together. The core data flow begins with the policy compilation module converting human-readable prohibited transmission policies into a set of machine-executable violation behavior feature vectors. Upon receiving a cross-domain data transmission request, the request processing module generates instantaneous behavior feature vectors 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 self-proving cryptographic credential. Finally, the transmission decision module makes a precise decision to allow or block the corresponding data transmission based on the verification result of this credential.

[0029] In the specific execution process, to effectively address the problems of delayed dynamic compliance verification and insufficient network adaptability commonly found 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 present invention's solution is configured such that the policy compilation module first deeply parses one or more prohibited transmission policies. In this process, each abstract policy rule, such as prohibiting the transmission of sensitive data exceeding the quota from a medical database in domain A to a research institution in domain B during a specific time period, is deterministically parsed and encoded into a fixed-length binary vector. The preset bit segments of this vector are strictly mapped to various key parameters of the request, such as the source IP address range, the target IP address range, and the user's identity role. The data type identifier, data size threshold, and even timestamp range are all parameters that meet the prohibition conditions. For each parameter value, the corresponding bit segment in the vector is set to logic 1, and vice versa. Thus, each violation feature vector becomes a precise digital profile of a specific violation pattern. Furthermore, to significantly improve distribution efficiency and the storage economy of terminal nodes, this set of violation feature vectors, after complete compilation, will be efficiently compressed using standard algorithms such as run-length encoding or dictionary compression, and then distributed to relevant terminal nodes for local deployment via secure channels. This process pre-compiles upper-layer compliance requirements into underlying structured data that supports high-speed bit operations, providing a self-certification mechanism for compliance during subsequent data transmission. This lays a solid foundation, fundamentally avoiding the inherent latency bottleneck of traditional centralized approval models. When any node in the network captures a cross-domain data transfer request for cloud data, to achieve instantaneous local verification of the request's compliance, the request processing module strictly follows the structural paradigm and encoding rules completely consistent with the violation behavior feature vector, generating an instantaneous behavior feature vector based on the real-time parameters of the request. Subsequently, the system performs a batch XOR operation locally, calculating the logical difference between this instantaneous behavior feature vector and each vector in the locally stored set of violation behavior feature vectors. The deterministic judgment procedure here is that if the result of any one of the batch operations is a vector of all zeros, then it is explicitly specified that... If the behavior of the current request completely matches a preset prohibition mode, the system will determine that the request is an explicit violation and immediately terminate the subsequent processing of the cross-domain data transfer request locally without any external negotiation. Conversely, if the result of all XOR operations is non-zero, it proves that the behavior of the request does not directly violate any known prohibition rules, and the system will transfer the entire set of non-zero residual vectors generated therefrom to the proof generation module. Considering that in dynamic collaborative tasks, security policies need to continuously evolve to deal with emerging new threats, the policy compilation module will attach a strictly unidirectionally increasing integer or high-precision timestamp as a version identifier when generating the set of violation behavior feature vectors. 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 the hardware random number generator. Then, it concatenates this random number, the set of non-zero residual vectors, and the aforementioned version identifier in a deterministic order. 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 compliance residual proof of the request. Through this design, a compact and unforgeable proof is generated. It not only cryptographically binds the logical distance between the request and all known rule sets, but more importantly, it embeds the policy's version snapshot information, enabling any receiving node to efficiently verify the compliance and timeliness of the data stream without possessing the complete policy context.

[0030] After receiving a data stream with an instantaneous compliance residual proof, the transmission decision module follows a rigorous automated closed-loop procedure for verification and decision-making. This procedure aims to mitigate security vulnerabilities or coordination obstacles that may arise from inconsistent policy versions among nodes in a distributed network. The verification node first separates the received proof from the data stream itself, then retrieves a locally stored set of violation behavior feature vectors. Combining this with the real-time parameters of the data stream and the local policy version identifier, it independently repeats the entire proof generation process. If the locally calculated hash digest and the proof attached to the data stream achieve a bit-level precise match, the verification passes, and transmission is allowed without delay; otherwise, verification fails. The transmission fails and is rejected. It's important to note that when the root cause of the verification failure is traced back to a mismatch in version identifiers between the communicating parties, this event will deterministically trigger a built-in policy synchronization subroutine. This subroutine mandates that nodes holding lower-version policies must automatically request the latest set of violation feature vectors from peer nodes holding higher versions. Upon receiving the new vector set, the node must first perform rigorous cryptographic verification on its accompanying digital signature. Only after confirming its credible origin and tamper-proof content is it allowed to replace its local outdated policy version. This point-to-point adaptive policy update mechanism, driven by business data flow, is crucial. This mechanism enables security policies to propagate and synchronize efficiently and promptly within active communication links. This ensures continuous system openness while maintaining a high degree of consistency across the entire cross-domain network on a security baseline. Furthermore, to finely adapt to the computational consumption of high-frequency continuous requests, such as the continuous data reporting from sensor arrays in the Industrial Internet of Things (IIoT), the system abstracts such transmissions into a session with a lifecycle for management. The initial request of this session strictly follows the aforementioned complete steps to generate a baseline instantaneous compliance residual proof. Once verified, this baseline proof is jointly cached by both communicating parties as the trust anchor of the session. For each request within the lifecycle of this session… In a subsequent request, the system no longer constructs a complete transient behavior feature vector. Instead, it calculates the difference between the current vector and the behavior feature vector of the previous verified request, generating a more concise difference vector. The system then performs residual calculations only on this difference vector. Subsequently, the system concatenates the residual result of this calculation with the hash value of the previously successfully verified transient compliance residual proof and a newly generated random number to generate a new incremental transient compliance residual proof. Since the input to each incremental proof includes the output of the previous proof, a logically and cryptographically immutable hash chain is constructed among all proofs within the session.This design cleverly transforms computational costs from a fixed overhead related to the size of the policy set into a dynamic overhead positively correlated with the rate of change of business data flow. In scenarios dominated by homogeneous requests, it can reduce the computational load on edge devices by more than an order of magnitude, and the chained structure synchronously ensures the logical consistency and non-repudiation of data operations throughout the entire session.

[0031] Furthermore, to evolve from the traditional binary judgment of compliance or non-compliance to a 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 inserts a statistical analysis step. This involves calculating the distribution pattern of these residual vectors to derive a compliance residual pattern entropy used to quantify the compliance risk of the current request. Its calculation formula is strictly defined as Here, This represents a specific pattern or type of residual vector, while This refers to the frequency of this type of residual vector among all non-zero residual vectors generated by the current request; an extremely low entropy value approaching zero usually means that the residual vector pattern exhibits a high degree of homogeneity and repetition. This statistical anomaly is highly likely to indicate an automated attack behavior aimed at probing the boundaries of a specific strategy; therefore, the system presets a dynamically adjustable compliance entropy lower limit threshold. The initial calibration procedure for this threshold is as follows: In the initial stage of system deployment, the compliance 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 for the security baseline; when a new request calculates When the value falls below this threshold, the transmission decision module will no longer execute the default allow operation, but will automatically trigger a preset high-risk response plan. Specific measures include, but are not limited to: immediately routing the cross-domain data transmission to an isolated analysis environment configured 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 manage potential unknown threats that exhibit statistical anomalies, thereby significantly improving the overall architecture's defense-in-depth level.

[0032] The violation behavior feature vector consists of a 256-bit fixed-length binary string. Its field division and mapping rules are loaded from a system-preset template file during the initialization configuration phase. This template file is organized using a field-by-field bitmask pattern. Each field establishes a one-to-one mapping relationship with parameters in the actual transmission request through a set of clearly defined value ranges. Bits 0 to 31 represent the source IP address segment, encoded by truncating the prefix length matching bits after CIDR format parsing of the source address. Bits 32 to 63 represent the target IP address segment, mapped in the same way as the source address. Bits 64 to 79 are used for the port number field encoding, using 16-bit integer interval segmentation and binary mapping of segment numbers. Bits 80 to 111 represent the user identity field, converting the user identifier into a 12-bit fixed code using a lookup table method. Bits 112 to 143 are the data type and security level encoding fields, using a three-level classification... The hierarchical encoding structure expresses sensitivity levels and business classifications. Bits 144 to 175 represent the time period segment to which the request timestamp falls. This segment is derived 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 bitmask. Bits 224 to 255 are reserved for expressing policy version, session state, or subsequent extended fields. Each violation behavior feature vector is generated sequentially by the policy parser according to the above fields based on the policy source text. All masking rules, field offsets, and mapping relationships involved in the generation process are defined by fixed templates in the configuration file, and their integrity verification values ​​are calculated by a 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. This category is determined by hash mapping based on the most frequently set bit segments in the 256-bit vector. During the initialization phase, the system records a set of residual vector sequences generated by real requests over a continuous 48-hour period under no-service intrusion conditions. For each of these patterns Statistical analysis of its frequency of occurrence And calculate the entropy value. After sorting the entropy sequence obtained from the statistical process, the 5th percentile is extracted as the initial threshold. This threshold is embedded in the system configuration and serves as a benchmark for all subsequent requests. If the entropy value generated by any subsequent request is lower than this threshold, the system will take action. When the system detects a request, it marks it as a high-risk candidate and triggers an isolation analysis process. This process includes importing the data stream mirror into the sandbox analysis engine and pausing the main path transmission process. Simultaneously, the triggering event will start local logging and perform sliding window statistical analysis on the residual pattern sequence in the most recent 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 a local marking mechanism and push it to the policy parsing module to generate additional restriction rules. Throughout the process, the frequency statistics, sliding window length, category mapping, entropy function definition, and threshold selection are all strictly fixed by the system initialization parameters and business debugging logs and cannot be changed.

[0033] The policy compilation and routing cost measurement procedure of this invention is as follows: All prohibited transmission policies are first converted into disjunctive normal form, where each minterm containing only logical AND generates an independent 256-bit violation feature vector; in this vector, the IP address field is filled with its network prefix according to the CIDR representation in the policy and the remaining bits are filled with all 1 bits as wildcards; discrete value fields such as user identity and data security level are transformed by looking up the entity encoding mapping table loaded during system initialization; continuous value fields such as data size and timestamp are mapped to the corresponding interval codes according to the preset logarithmic segmented quantization table and time slice encoding table; simultaneously, the cost measurement value of the point-to-point data routing path is... Weighting coefficients in and The business profile configured during node initialization is uniquely determined, with latency-sensitive profiles being set. Setting up a profile with limited computing resources A balanced profile, on the other hand, sets... Entropy of the compliance residual model used to quantify compliance risk of requests alarm threshold The calibration process follows an offline, statistically based automated calibration procedure. The input to this procedure is a compliant residual pattern entropy sample dataset recorded during the baseline learning period, containing only normal business requests. The process first calculates the complete statistical distribution of the dataset and sets the initial threshold as the fifth percentile of the dataset. Then, during a supervised debugging period containing known attack samples, if the false positive 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 negative rate for known attacks is higher than the preset upper limit of 0.1%, the threshold is raised by one percentile. This iterative adjustment continues until both the false positive rate and the false negative rate are lower than their respective upper limits. The final threshold formed at this point will be fixed and used as the benchmark comparison reference value for all subsequent requests.

[0034] Example 1: In a specific city-level emergency response deployment, a large-scale toxic gas leak occurred in a chemical industrial park. The emergency command center needed to immediately coordinate 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, delineate the pollution range, conduct atmospheric diffusion modeling, and guide medical treatment. The fundamental challenge in this scenario is that the various units have not pre-established dedicated data transmission channels and authorization strategies for such sudden, cross-domain, and large-scale events. If the traditional process of online hierarchical approval and offline configuration of network firewalls and virtual private network tunnels is followed, several hours of decision-making and execution delays will inevitably occur. In the race against time for emergency rescue, such delays are directly related to the loss of life and property. At the same time, temporarily opening network ports in an emergency provides a penetration window for potential network attacks, which can easily lead to secondary disasters such as tampering or leakage of critical data.

[0035] Under these conditions, the technical solution of this invention is activated. When a mobile monitoring vehicle deployed by the environmental protection department at the accident site, acting as a temporary network node, attempts to upload real-time toxic gas concentration data to a traffic command center belonging to another cloud domain for the first time, the request is intercepted at the boundary node of the traffic domain. This node does not reject the request due to the lack of a pre-defined static trust relationship, but instead requires the data stream to 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 behavioral feature vector based on the parameters of this transmission, and performs a logical difference operation with the emergency response violation behavior feature vector set with the latest version identifier, which was urgently compiled and distributed across the network by the command center after the accident. Given that the request belongs to compliant emergency data, its instantaneous behavioral features are... The quantity does not match any known violation patterns, thus generating a set of non-zero residual vectors. This mechanism avoids the inherent contradiction between openness and security in emergency scenarios. Data transmission no longer relies on the pre-establishment of static secure channels, achieving extreme agility at the business level. Security is ensured through rigorous verification of the unforgeable cryptographic proof carried by each data stream, thereby avoiding the traditional trust paradox in the system architecture itself. Furthermore, the deeper 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 this set of non-zero residual vectors, enabling cross-domain data transmission. The system does not stop there, but also initiates a parallel process based on the entropy of the compliance residual pattern. The system's risk assessment mechanism is in place. At this point, if a lurking attacker attempts to exploit the privilege window during an emergency by sending a large number of probing requests with similar structures that slightly deviate from compliance policies to find system vulnerabilities, although these requests can also generate non-zero residual vectors and pass basic compliance checks, the residual vector patterns they generate will exhibit extremely low entropy values ​​due to their high repetition and purposefulness. The system's built-in risk assessment logic, by continuously calculating and monitoring the session's entropy value, can capture this statistically abnormal signal and convert the calculated low entropy value into an extremely low value. The value serves as a high-risk indicator, automatically triggering 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. In turn, the latter provides the former with a crucial layer of defense in depth 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 these two technical features makes the overall security capability of the system surpass the linear superposition of their independent operation.

[0036] Ultimately, this technical solution redefines the problem itself, demonstrating a significant difference at the architectural level. Traditional solutions focus on solving the near-unsolvable engineering challenge of how to pre-build and manage thousands of potential secure channels between different entities in certain emergency scenarios. In contrast, this invention transforms the problem into how any data can autonomously and reliably prove its compliance when transmitted on any channel. By decoupling security attributes and trust relationships from the static network infrastructure and embedding them as inherent, dynamically verifiable attributes of the data flow itself, the original channel management challenges are effectively avoided under the new technical paradigm. Emergency response can thus establish a cross-departmental, secure, and reliable data lifeline within minutes, and the command center can obtain near-real-time panoramic information of the accident scene to make scientific decisions, thereby providing technical support for minimizing accident damage. Its design philosophy is that trust should not be a static assignment of the network's physical or logical topology, but rather a dynamic self-verification result of every data action.

[0037] Example 2: This example aims to replicate a typical cross-domain data acquisition scenario in the Industrial Internet of Things (IIoT). The platform consists of an edge device node, a gateway node, and a central policy server. The edge device node uses resource-constrained embedded computing units, while the gateway node and central policy server are deployed on standard server hardware. The three are interconnected through a local area network (LAN) with precisely controllable network latency. A key parameter in the experiment is the size of the set of violation behavior feature vectors. This setting requires a trade-off between the granularity of the security policy and the computational load of the edge node. Given that a medium-sized industrial partition typically involves hundreds of independent access control rules, this experiment sets the set to contain 1024 independent violation behavior feature vectors to ensure effective coverage of the security policy. Another key parameter is the effective session duration. This setting considers the balance between computational efficiency and the frequency of security re-authentication. Based on the requirement for minute-level status confirmation for industrial monitoring data, this experiment sets the session duration to 60 seconds to test the efficiency gain of the incremental proof mechanism within this time window.

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

[0039] Table 1: Performance Comparison Data for Different Verification Mechanisms

[0040]

[0041] As shown in Table 1, under the centralized verification model, the average end-to-end latency and network injection latency exhibit a strong linear correlation. When the network latency is 100ms, the verification time for a single packet exceeds 200ms. In contrast, the incremental instantaneous compliance residual proof in this invention maintains an end-to-end latency of less than 1ms and is largely unaffected by network injection latency. This performance is due to the fact that the incremental proof verification process is a purely local computation task. It transforms the traditional model's verification logic, which relies on network round trips, into a single local hash comparison, thereby circumventing the constraints of network latency. At the same time, the data also reveals the computational cost structure of this scheme. The generation of the first packet benchmark proof causes a significant CPU utilization spike at the edge, exceeding 25%. This is the initial computational overhead incurred in building the session trust anchor. However, during the rest of the session, the CPU utilization for generating incremental proofs drops back to around 3.5%. This phenomenon confirms the effectiveness of the session mechanism in amortizing computational costs.

[0042] Example 3: This example combines Figures 1 to 3 This document provides a diagram illustrating a cross-domain collaborative cloud data storage method and system. Figure 1 As shown, this process includes the entire process from policy management to data transmission. First, when defining and generating transmission policies, the policy administrator compiles the prohibited transmission rules through the policy compilation module and generates corresponding sets of violation behavior feature vectors based on these rules. These vector sets are then processed by the compression module to generate a data set that can be used subsequently. Next, the distribution server is responsible for distributing this processed data to various terminal nodes, such as terminal node A, terminal node B, and terminal node C. After each terminal node receives the data, terminal node A establishes a secure channel and ensures the compliance of the transmission process by exchanging and verifying data with terminal nodes B and C. At the same time, the terminal nodes also store data locally for verification and ensure that the data transmission does not violate the established rules through the verification steps.

[0043] like Figure 2As shown in the figure, the horizontal axis represents network injection delay (ms), and the vertical axis represents average transmission delay (ms). It can be seen from the figure that as the network injection delay increases, the average transmission delay of centralized verification shows a significant increasing trend, especially when the network injection delay is high, the delay value rises rapidly, reaching a maximum of nearly 300ms. However, under the scheme of this invention, the transmission delay of both the first-packet benchmark proof and the session incremental proof verification methods of this invention 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 at a network injection delay of 100ms, where the delay increase is significant. In contrast, the average delay of the first-packet benchmark proof and the session incremental proof verification methods of this invention changes less, and even under high network injection delay, the average delay is always controlled below 10ms. The session incremental proof verification method of this invention exhibits the best delay performance, showing extremely low average transmission delay under different network delay conditions.

[0044] like Figure 3 As shown, the prohibited transmission policy is first parsed by the policy parser, and then enters the parameter type identification stage. This stage distinguishes parameters based on their type. First, an IP segment code is generated based on the source / destination address. Then, a role identifier code is generated for the user identity, and a type level code is generated for the data type. Based on this information, a corresponding 256-bit vector is generated. The generated vector is further processed by the policy parser to enter the 256-bit vector generation step, and then enters the execution behavior feature vector set stage. Finally, after compression and distribution, the policy is sent to the relevant nodes in compressed format for application.

[0045] Example 4: In a deployment that requires establishing a cross-domain, real-time, and highly secure transaction data exchange network among multiple independent financial institutions, the challenge is to meet the complex and dynamically evolving prohibition policies issued by regulatory agencies, and to achieve optimal data routing performance and fault self-healing without a centralized network operation and management center. This requires the technical solution of the present invention to have a clear policy coding procedure, an adaptive risk threshold calibration method, and a distributed routing negotiation mechanism.

[0046] To achieve this functionality, the initial deployment phase of the system requires defining the internal data structure of the violation behavior feature vector and the instantaneous behavior feature vector, which serve as the policy carriers. In a specific configuration, this vector is set as a fixed-length 256-bit binary string, internally divided into multiple logical fields. Bits 0-127 are used to encode the source and destination IPv6 addresses, bits 128-159 are used to encode the source and destination port numbers, bits 160-191 are used to encode the user identification, bits 192-223 are used to encode the data type and security level, and bits 22... Bits 4-255 are used to encode timestamps and session states. Based on this structure definition, the strategy compilation module follows a set of conversion procedures to transform human-readable prohibition 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 with any counterparty institution rated below AA- between 17:00 Beijing time and 9:00 the next day, the compilation module first converts the following information into a binary vector: trader A, a list of institutions rated below AA-, derivative transaction type, etc. Logical objects with amounts exceeding 1 million are converted into binary values ​​such as specific IP address ranges, user identification codes, and data type codes by consulting the system's built-in entity identity and address mapping table. These values ​​are then used as bitmasks, setting the corresponding bits of the violation behavior feature vector to 1. For continuous values ​​such as time ranges, they are converted into discrete timestamp interval codes. For any wildcard, all bits of the corresponding field are set to 1. In this way, each logical rule is compiled field by field into a machine-manageable binary violation pattern. The specific policy vectorization procedure decomposes human-readable prohibition policies using disjunctive normal form, transforming complex rules containing logical OR into a set of multiple independent minterms containing only logical AND. Each minterm generates an independent violation behavior feature vector. For the field codes within the vector, continuous values ​​such as data size are quantized using logarithmic segmentation, while timestamps are discretized according to a preset time slice width, thus converting all judgment conditions into binary bit operations. When constructing point-to-point data routing paths, the cost metric is... Weighting coefficients in and This is determined by the node's business profile configuration, where This is the normalized value of the node's current CPU load. To determine the normalized value of the network round-trip delay between the node and the source node of the routing request, the system administrator assigns a business profile to the node during node initialization. For example, a latency-sensitive profile will be automatically set. The resource-constrained profile will be automatically set. This allows routing decisions to be made based on a pre-defined, deterministic set of rules; compliance residual pattern entropy is used to quantify request compliance risks. alarm threshold Its calibration process follows an offline, statistically based calibration procedure. The input to this procedure is a sample dataset of compliance residual pattern entropy generated by all normal business transactions recorded by the system during a baseline learning period. The procedure first calculates the complete statistical distribution of this dataset and sets the initial alarm threshold. The threshold is set to the fifth percentile of the dataset. Subsequently, during a pre-defined supervised debugging period, the system records all events with entropy values ​​below this threshold as alarms awaiting review. If the false alarm rate during this period exceeds a configurable upper limit, the alarm threshold is adjusted. The threshold will be lowered to the next percentile. If a known attack fails to trigger an alarm, the threshold will be raised to a preset safety margin below the attack entropy value. This iterative process will terminate after the monitoring and debugging period ends. 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 network's own behavioral statistical characteristics.

[0047] Furthermore, to achieve the function of constructing point-to-point data routing paths, this scheme adopts a distributed routing negotiation protocol based on cost metrics. 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 destination 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. Its calculation procedure is as follows ,in This represents the current CPU load percentage of the node. The network round-trip delay between it and the source node of the route request broadcast. and The system uses pre-defined standardized coefficients to adjust the weights of computational and network costs; nodes B and C then append their own node identifiers and calculated cost metrics to the received routing request packets. It continues to forward the route request packet to its verified and compliant neighbor nodes until the route request packet finally arrives at the target node D. Within a set short time window, the target node D may receive multiple route requests from different paths, each containing accumulated costs. It will select the path with the lowest accumulated cost and return a route confirmation packet along that path. Once all nodes on that path receive the confirmation, a temporary data transmission channel is established to serve the session.

[0048] Example 5: To ensure the continuous health of the network and the real-time effectiveness of policies, this example employs a logical link state diagnostic procedure based on probe proof during the operation and maintenance phase. Each node in the network is configured to automatically generate and broadcast a probe proof to all its known neighbor nodes according to a system-preset cycle. The source of this proof is a virtual behavior feature vector, which is a special vector pre-placed in the set of violation behavior feature vectors during the compilation phase. Its internal data type field is set to a reserved code specifically for network diagnosis. The node periodically uses this virtual vector as input to execute the instantaneous compliance residual proof generation process and sends out the generated proof. After receiving this probe 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 its set of violation behavior feature vectors is consistent with the receiver's version. If a valid probe proof is not received from a neighboring node within three consecutive cycles, the node will be marked as a logical fault state, triggering an alarm or route replanning in the upper-layer application.

[0049] Furthermore, to ensure the root security of the entire trust system, any new node must execute an offline pre-configuration and identity injection procedure before joining 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 join the network. The node's public key, along with its identity information, is signed 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 into a tamper-proof security module on the node's hardware. When the node is actually deployed and running in the future, upon receiving any new update of the violation behavior feature vector set, it will first use the pre-installed, immutable issuing authority root public key in its security module to verify the legality of the digital signature of the update packet. Only if the verification is successful can it be proven that the policy update originated from a trusted issuing authority, thereby ensuring a secure closed loop for the entire policy distribution and update chain.

[0050] 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.

[0051] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for cross-domain collaborative storage of cloud data, characterized in that, The method includes the following steps: Step a: Based on one or more defined prohibited 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: When a cross-domain data transmission request for cloud data is received, an instantaneous behavior feature vector is generated based on the parameters of the request; an XOR operation is performed 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, resulting in a set of non-zero residual vectors. Step c: Based on a set of non-zero residual vectors and a random number, generate an instantaneous compliance residual proof. The instantaneous compliance residual proof is a hash digest obtained by performing a concatenated hash operation on a set of non-zero residual vectors and a random number. Step d: Based on the verification result of the instantaneous compliance residual proof, decide whether to allow cross-domain data transfer. If the verification passes, the transfer is allowed; if the verification fails, the transfer is rejected.

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

3. The 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 one of the violation behavior feature vectors in the set of violation behavior feature vectors, then the cross-domain data transmission request is terminated locally.

4. The cloud data cross-domain collaborative storage method according to claim 1, characterized in that, The set of feature vectors of violations 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 transient compliance residual proof fails due to version inconsistency, the process of updating the set of violation behavior feature vectors between communication nodes is triggered. The update process includes: the node with the lower version requests the latest set of violation behavior feature vectors from the node with the higher version, and performs digital signature verification on the received set of violation behavior feature vectors.

6. The cloud data cross-domain collaborative storage method according to claim 1, characterized in that, Also includes: After step d, multiple network nodes construct point-to-point data routing paths based on the instantaneous compliance residual proofs exchanged and verified with each other, by judging the distance, bandwidth, and load factors between nodes. The construction of the routing paths 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 conducted in the form of sessions. The first request in 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 behavioral feature vector and the baseline instantaneous behavioral feature vector, and residual calculation is performed. The result of the residual calculation is concatenated with the previously 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 previously verified instantaneous compliance residual proof.

8. The cloud data cross-domain collaborative storage method according to claim 1, characterized in that, Also includes: Following step b, based on the frequency distribution of each residual vector in a set of non-zero residual vectors, a compliance residual pattern entropy is calculated to quantify the compliance risk of the request. ,in, , This represents the frequency of occurrence of a particular residual vector within a set of non-zero residual vectors. This indicates the type of a certain 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 the rate of cross-domain data transmission is limited based on the calculation results of the compliance residual pattern entropy.

10. A cloud data cross-domain collaborative storage system, characterized in that, The system includes: A policy compilation module is used to compile a set of violation behavior feature vectors based on one or more defined prohibited transmission policies, where each vector in the set of violation behavior feature vectors encodes a violation pattern; A request processing module is used to generate an instantaneous behavior feature vector based on the parameters of the request when a cross-domain data transfer request for cloud data is received, and to perform an XOR 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, so as to obtain a set of non-zero residual vectors. A proof generation module is used to generate an instantaneous compliance residual proof based on a set of non-zero residual vectors and a random number. The instantaneous compliance residual proof is a hash digest obtained by performing a concatenated hash operation on a set of non-zero residual vectors and a random number. A transmission decision module is used to determine whether to allow cross-domain data transmission based on the verification result of the instantaneous compliance residual proof. If the verification passes, the transmission is allowed; if the verification fails, the transmission is rejected.

Images