Data flow circulation whole life cycle security management method and device

Abstract

This invention provides a method and apparatus for secure management of the entire lifecycle of data circulation. The method includes: receiving a circulation request for a data product; invoking a parameterized strategy template corresponding to the current data product's circulation request, wherein the parameterized strategy template includes contract strategy atomic components corresponding to the entire lifecycle of the data product, each contract strategy atomic component corresponding to an indivisible contract strategy; parsing the data product's circulation request to obtain product metadata and consumption intent; injecting the product metadata and consumption intent as parameters into the parameterized strategy template to obtain a digital contract; and executing the signed digital contract in response to receiving it. This application achieves closed-loop governance of self-arrangement of contract strategies and self-execution of digital contracts, reducing the professional threshold and time cost of contract drafting, and ensuring the logical self-consistency of the final digital contract rules.

Description

Technical Field

[0001] This invention relates to the field of data circulation, and in particular to a method and apparatus for the full lifecycle security management of data circulation. Background Technology

[0002] With data being recognized as the fifth major factor of production, its circulation and transaction scale has continued to expand. However, frequent data breaches and misuse incidents have severely hampered the healthy development of the industry.

[0003] Currently, the circulation and trading of data elements in the market generally adopts a single-point, manual processing method, which not only has limited coverage but also has high maintenance costs, resulting in low operational efficiency in the entire data circulation field. Although the rise of digital contract technology has improved the security of the circulation process to some extent, there are still significant shortcomings in terms of the breadth of business process coverage, automation level, and execution depth.

[0004] Therefore, there is an urgent need in this field for a data circulation full lifecycle security management method to solve the problems of fragmented and inefficient data circulation security control. Summary of the Invention

[0005] Firstly, addressing the problems existing in the prior art, this invention provides a method for secure management of the entire lifecycle of data circulation, reducing the professional threshold and time cost of contract drafting, and improving the accuracy of strategy matching. The method includes:

[0006] Receive requests for the circulation of data products;

[0007] Invoke the parameterized strategy template corresponding to the circulation request of the current data product, wherein the parameterized strategy template includes contract strategy atomic components corresponding to the entire life cycle of the data product, and each contract strategy atomic component corresponds to an indivisible contract strategy;

[0008] The data product circulation request is analyzed to obtain product metadata and consumption intent;

[0009] The product metadata and consumption intent are injected as parameters into the parameterized strategy template to obtain a digital contract;

[0010] Upon receiving a signed digital contract, the signed digital contract is executed.

[0011] According to the data circulation lifecycle security management method provided by the present invention, before receiving a data product circulation request, the method further includes:

[0012] Construct parameterized strategy templates for all data products; wherein, for each data product, the process of constructing the parameterized strategy template includes:

[0013] The contract strategy for the data product is determined based on the entire lifecycle of the data product.

[0014] The contract strategy is encapsulated as an atomic component of the contract strategy;

[0015] The parameterized strategy template is constructed based on the atomic components of the contract strategy.

[0016] The data circulation lifecycle security management method provided by this invention:

[0017] The data product circulation request includes: target product identifier and consumption description information;

[0018] The steps of parsing the circulation request of the data product to obtain product metadata and consumption intention include:

[0019] The circulation request of the data product is parsed to obtain the target product identifier and consumption description information;

[0020] The product metadata is determined based on the target product identifier, and the consumption intention is obtained by semantic parsing the consumption description information.

[0021] According to the data circulation lifecycle security management method provided by the present invention, the step of semantically parsing the consumption description information to obtain the consumption intent includes:

[0022] The consumption intent is obtained by semantic parsing the consumption description information using an intent description model. The consumption intent includes one or more of the following: consumption purpose information, usage method information, update cycle information, and usage scope information.

[0023] According to the data circulation lifecycle security management method provided by the present invention, the step of injecting the product metadata and consumption intention as parameters into the parameterized strategy template to obtain a digital contract includes:

[0024] Based on the contract strategy atomic components in the parameterized strategy template, a list of contract rules for the entire lifecycle of the data product is obtained;

[0025] The product metadata and consumption intent are assigned to the contract rule list to obtain a set of contract strategies;

[0026] A digital contract is obtained based on the set of contract strategies.

[0027] According to the data circulation lifecycle security management method provided by the present invention, before obtaining the contract rule list for the entire lifecycle of the data product, the method further includes:

[0028] The strategy conflict analyzer is used to process conflicting contract strategy atomic components according to the priority of the contract strategy.

[0029] According to the data circulation lifecycle security management method provided by the present invention, in response to receiving a signed digital contract, the method further includes:

[0030] A hash operation is performed on the signed digital contract, the contract strategy set corresponding to the signed digital contract, the digital signature, and the trusted timestamp, and the hash value obtained from the operation is fixed on the blockchain;

[0031] The hash value obtained from the above operation is maintained using a split ledger.

[0032] According to the data circulation lifecycle security management method provided by the present invention, before executing the signed digital contract, the method further includes:

[0033] Perform syntax validation on the aforementioned set of contract strategies;

[0034] If the syntax verification result is passed, the set of contract strategies corresponding to the signed digital contract is executed in the order of the entire lifecycle of the data product.

[0035] According to the data circulation lifecycle security management method provided by the present invention, the steps of executing the contract strategy set corresponding to the signed digital contract in the order of the data product's lifecycle include:

[0036] The first monitoring channel is used to monitor whether the execution behavior of the signed digital contract exceeds the contract policy;

[0037] Furthermore, the second monitoring channel is used to monitor whether the execution behavior of the signed digital contract exceeds the behavior baseline.

[0038] Secondly, the present invention also provides a data circulation lifecycle security management device, the device comprising:

[0039] The request receiving unit is configured to receive requests for the flow of data products.

[0040] The template invocation unit is configured to invoke the parameterized strategy template corresponding to the circulation request of the current data product. The parameterized strategy template includes contract strategy atomic components corresponding to the entire lifecycle of the data product, and each contract strategy atomic component corresponds to an indivisible contract strategy.

[0041] The request parsing unit is configured to parse the circulation request of the data product to obtain product metadata and consumption intent;

[0042] The contract generation unit is configured to inject the product metadata and consumption intention as parameters into the parameterized strategy template to obtain a digital contract;

[0043] A contract execution unit is configured to execute a signed digital contract in response to receiving such a contract.

[0044] The data circulation lifecycle security management method provided in this application parses the circulation requests of data products to obtain product metadata and consumption intentions. The product metadata and consumption intentions are then injected as parameters into the parameterized strategy template of the pre-configured contract strategy atomic components corresponding to the entire lifecycle of the data product to obtain a digital contract. This achieves closed-loop governance of self-arrangement of contract strategies and self-execution of digital contracts, reduces the professional threshold and time cost of contract drafting, eliminates the semantic gap between data usage intentions and rules, improves the accuracy of matching data products with contract strategies, avoids omissions and deviations caused by manual matching, and ensures the logical self-consistency of the final digital contract rules. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating the data circulation lifecycle security management method provided by the present invention;

[0047] Figure 2 This is a schematic diagram illustrating an application scenario of the data circulation full lifecycle security management method provided by the present invention;

[0048] Figure 3 This is a schematic diagram of the process for constructing a parameterized strategy template provided by the present invention;

[0049] Figure 4 This is a schematic diagram of the process for obtaining product metadata and consumer intent provided by the present invention.

[0050] Figure 5 This is a schematic diagram of the process provided by the present invention for injecting parameters into a parameterized strategy template to obtain a digital contract.

[0051] Figure 6 This is a schematic diagram of the data circulation lifecycle security management device provided by the present invention. Detailed Implementation

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

[0053] To better understand this application, the terms and related background information used in this application will be explained first.

[0054] Trusted Data Space is a secure and controllable data circulation infrastructure and governance framework that aims to enable different entities to achieve cross-organizational, cross-industry, and cross-regional data sharing and circulation under the premise that "data is available but not visible, and data is controllable and measurable".

[0055] Data products refer to data forms that have been processed, have clear use cases and compliance boundaries, and can be provided for circulation or services. Direct circulation of raw data is risky and difficult to price. However, packaging data into "products" clarifies rights boundaries, quality standards, and application scenarios, thereby lowering the barriers to circulation and improving transaction efficiency. Data holders, through secure access to a trusted data space, clean, de-identify, and model their raw data within the trusted data space, forming standardized data products. Those with needs can then "call" these listed data products within the space, ensuring that the data is "usable but not visible."

[0056] The entire lifecycle of data circulation refers to the complete process that a data product goes through from its creation to its destruction, including data collection, data storage, data processing, data circulation, data use, and data destruction. The specific stages may vary slightly depending on the type of product.

[0057] Digital contracts, encompassing a set of contractual strategies in data circulation, are digital protocol systems used to clarify the rights and obligations of data suppliers, consumers, and platforms, and to ensure execution and evidence preservation through technological means. They are typically parsed and executed by a contract execution engine, which transforms abstract security requirements into executable technical rules.

[0058] Contractual strategy refers to the declaration and control logic of data processing rules, permission constraints and obligations that data products should follow throughout a specific data circulation lifecycle. It is a set of rules that constrain data usage behavior in data circulation. It is embedded in the circulation link in the form of digital contracts to ensure that data is used in accordance with the agreed conditions.

[0059] Product metadata describes the inherent characteristics and attributes of a data product, such as its properties, structure, source, format, update cycle, and data category. It serves as the "identity card" and "instruction manual" for data products, enabling both suppliers and consumers to quickly understand, discover, and evaluate them.

[0060] A policy domain can be understood as a policy classification boundary defined according to a specific stage or control dimension of data flow. It is used to group policy rules or atomic components with the same control objectives and similar contextual attributes into a logical group for unified management. These include: transmission domain, storage domain, usage domain, and destruction domain.

[0061] A strategy instance is a set of directly executable strategy rules generated by injecting specific parameters into a parameterized contract strategy template.

[0062] In the first aspect, this application provides a method for secure management of the entire lifecycle of data circulation, which can be applied to, for example... Figure 2 The digital circulation platform shown aims to facilitate data circulation, such as purchasing data products within a trusted data space, in conjunction with... Figure 1 and Figure 2 As shown, the method includes steps 110-150:

[0063] Step 110: Receive a data product circulation request;

[0064] Specifically, the data product circulation request in this application refers to a request message sent by the requester to the data circulation platform to request the circulation processing of a certain data product, including the target product identifier initiated by the data demander for purchase. The target product identifier can be understood as information used to uniquely identify the data product, and its form can be one or more of the following: product number, resource locator, and data product hash value.

[0065] Step 120: Invoke the parameterized strategy template corresponding to the current data product circulation request;

[0066] Specifically, in the field of data product management, the constraints on data ownership, security levels, access control, and usage restrictions vary significantly across different stages of the data product's lifecycle, from creation and circulation to use and destruction. Omitting any stage can easily pose risks to the entire data circulation process. Therefore, this application, when determining the strategy template, does not only target a single stage of data circulation but rather the entire lifecycle of the data product during circulation. After receiving a data product circulation request, a pre-configured parameterized strategy template corresponding to the target product identifier in the data product circulation request is invoked. This parameterized strategy template includes contract strategy atomic components corresponding to the entire lifecycle of the data product, with each contract strategy atomic component corresponding to one contract strategy.

[0067] The entire lifecycle of a data product serves as the triggering condition and basis for determining contract strategies, enabling dynamic binding of these strategies to specific stages of the data product. For example, when a data product is identified as being in the "data circulation" stage, a contract strategy corresponding to that stage, including transmission encryption requirements and usage scope restrictions, will be determined.

[0068] A contract strategy atomic component can be understood as the smallest, indivisible, and independently functional unit of logic formed by encapsulating the indivisible contract strategy determined throughout the entire data circulation lifecycle. This atomic component packages the specific stage constraints, action rules, and parameter interfaces as standard building blocks for constructing higher-level strategy templates. For example, the "physical destruction of storage media" strategy corresponding to the "data destruction" stage can be encapsulated as a contract strategy atomic component, which receives parameters such as the destruction method and execution time.

[0069] A parameterized strategy template can be understood as a combination of one or more atomic components of a contract strategy, which adapts to different data products and strategy frameworks in different scenarios by exposing configurable parameters. The parameterized strategy template defines the structure and logic of the strategy, and in practical applications, it generates an instantiated contract strategy for a specific data product by injecting specific parameter values. For example, a "data sharing control" parameterized strategy template consists of three atomic components: "authentication," "usage limit," and "log retention." The template parameters include "authentication level," "maximum number of uses," and "retention period."

[0070] In a preferred embodiment, since the contract strategies of different data products often contain repetitive or similar control logic, corresponding parameterized strategy templates can be pre-configured for all listed data products. This means constructing parameterized strategy templates for all data products so that the pre-configured templates can be directly invoked after receiving a data product circulation request. For each data product, the process of constructing its parameterized strategy template includes steps 310-330:

[0071] Step 310: Determine the contract strategy for the data product based on the entire lifecycle stages of the data product;

[0072] Specifically, the process involves acquiring the metadata of all listed data products and parsing it to determine the current lifecycle stage identifier and attribute information of the data product. This lifecycle stage identifier can be preset as one of the enumerated values ​​such as collection, storage, processing, circulation, use, or destruction. Then, using the parsed lifecycle stage identifier as the query key, a set of candidate contract strategy rules that are associated with the lifecycle stage identifier is matched against a pre-defined strategy library. The strategy library stores the mapping relationship between stage identifiers and contract strategy rules. The matching contract strategy rules can be combined with the attribute information of the data product that influences strategy selection, such as data sensitivity level and data volume. Finally, the specific content of the contract strategy to be adopted by the data product at the current stage is determined from the set of candidate contract strategy rules. This contract strategy includes the strategy subject, control actions, and constraints.

[0073] Step 320: Encapsulate the contract strategy into an atomic component of the contract strategy;

[0074] Specifically, the determined contract strategy content is combined with a predefined atomic component encapsulation interface specification to generate contract strategy atomic components. The encapsulation interface specification includes standardized input and output parameter definitions. Simultaneously, a unique component identifier is assigned to each contract strategy atomic component, and variable elements such as the strategy domain, time threshold, maximum number of uses, and allowed operation types are extracted as configurable parameters for the component. Fixed control logic is compiled into the component's execution body, thus forming a contract strategy atomic component that can be independently managed and invoked. For example, for a "use-and-burn" contract strategy, after abstracting it into a contract strategy atomic component, the input parameter is "Trigger condition: 30 minutes after the data user uses the data," the output parameter is "Judgment result and obligation, determining whether more than 30 minutes have passed," the strategy domain is "Subject: Data processing environment of the data user, Resources: Original dataset, derived data, intermediate cache files, Environment: Data destruction stage," the allowed operation type is "Data deletion," and the constraint parameter is "Verification method: If the data user's last active time exceeds 30 minutes, the hash of the destroyed data must be returned."

[0075] In addition, each contract strategy atomic component is bound to one or more data flow stage tags to form a full lifecycle strategy matrix. For example, "force Transport Layer Security (TLS) encrypted transmission" is associated with the data transmission stage, "access time window" is associated with the usage stage, and "use-and-burn" is associated with the end-of-use stage, so that the strategy can be automatically matched and associated according to the flow path of the circulating target during strategy orchestration.

[0076] Step 330: Construct a parameterized strategy template based on the contract strategy atomic components;

[0077] Specifically, upon receiving a template construction instruction or according to preset template generation rules, one or more contract strategy atomic components are selected from the component library. Then, based on the logical relationships between the selected contract strategy atomic components, they are combined and arranged to expose the configurable parameters of each component as a template-level parameter set, forming a parameterized strategy template. Finally, the parameterized strategy template is stored in the template library, and a template identifier and version information are assigned to the template.

[0078] Furthermore, the parameterized policy template in this application is a flexibly configurable policy template. The same parameterized policy template can be used to generate policy instances adapted to different security levels, compliance requirements, or consumption scenarios by injecting different actual parameter values. Inheritance and combination are supported between parameterized policy templates, reducing redundant definitions and improving reusability through a "base template plus mixed-in policy fragments" approach.

[0079] In a preferred implementation, this application can also dynamically update the constructed parameterized strategy template. When the definition of the entire lifecycle of a data product changes, or new compliance requirements arise, the contract strategy is redefined and the corresponding contract strategy atomic components are updated. The updated contract strategy atomic components are then automatically synchronized to the parameterized strategy templates that reference these components, thereby achieving version iteration control of the template and ensuring that all strategy instances using the template can achieve consistent strategy adjustments through template updates.

[0080] The above approach links the contract strategy of data products with all stages of their lifecycle, enabling the contract strategy to accurately match the actual management needs of data products at different evolutionary stages. This eliminates the disconnect between strategy and actual processes caused by static configuration, improving the accuracy and automation level of the strategy. By encapsulating the contract strategy into atomic components and combining these components into parameterized strategy templates, fine-grained decomposition and high-level reuse of contract strategies are achieved. Parameterized strategy templates transform the configuration of strategies for different data products from repetitive manual writing to template-based parameter injection, significantly reducing redundant configuration work, improving strategy configuration efficiency, and ensuring the consistency and maintainability of strategy rules for similar data products throughout their lifecycle.

[0081] Step 130: Analyze the data product circulation request to obtain product metadata and consumption intent;

[0082] Specifically, in this application, consumption intent can be understood as a clear statement by the data requester regarding the purpose, method, and scenario of using the data product. It serves as a bridge between "data supply" and "data demand," and is the fundamental basis for data authorization and compliance management. For example, consumption intent includes structured parameters such as "consumption purpose is to build a recommendation model," "update cycle is daily," and "use scope is internal environment." Product metadata provides basic information about the data product. For example, product metadata may include data field names, data types, production time, update frequency, data capacity, and the business domain to which it belongs. By parsing the data product circulation request, product metadata and consumption intent can be obtained, both of which serve as parameters to be injected into the parameterized strategy template in subsequent steps.

[0083] In a preferred embodiment, the data product circulation request includes not only the target product identifier but also consumption description information to describe the consumption or usage demand for the data product. This consumption description information can be natural language text, semi-structured text, or a combination thereof. For example, the consumption description information in a data product circulation request might be "User activity data that needs to be updated daily, used to build a recommendation model, for internal use only." The process of parsing the data product circulation request to obtain product metadata and consumption intent includes steps 410-420:

[0084] Step 410: Parse the data product circulation request to obtain the target product identifier and consumption description information;

[0085] Specifically, the target product identifier and consumption description information can be extracted from the circulation request of the data product. The extraction method can be to parse the preset fields in the circulation request message to obtain the target product identifier field value and the consumption description information field value.

[0086] Step 420: Determine product metadata based on the target product identifier, and perform semantic parsing on the consumption description information to obtain the consumption intent;

[0087] Specifically, a query request is initiated to the product metadata storage unit using the target product identifier as the query key. The product metadata storage unit pre-stores the mapping relationship between the target product identifier and product metadata. After retrieving the product metadata corresponding to the target product identifier, the system receives the corresponding product metadata returned by the metadata storage unit.

[0088] Furthermore, the data circulation platform establishes an intent description model, covering intent parsing aspects such as data usage purpose, environmental constraints, data timeliness, and delivery form control. For example, data usage purpose includes model training, dataset download, and application programming interface (API) secondary development. Environmental constraints include data sandboxes, privacy computing, and Trusted Execution Environments (TEEs). Data timeliness includes time windows and usage frequency. Delivery form control includes whether downloading is allowed and whether mandatory anonymization is required. Consumption description information is input into the intent description model for word segmentation, part-of-speech tagging, named entity recognition, and dependency parsing. This identifies entities appearing in the consumption description information and their semantic relationships, and classifies intents based on entities and semantic relationships to generate structured consumption intents. The resulting consumption intent includes one or more of the following: consumption purpose information, usage method information, update cycle information, and usage scope information.

[0089] In a preferred implementation, the consumer description information can be preprocessed before semantic parsing. Preprocessing includes removing stop words, restoring the full names of abbreviations or shorthand terms, and completing omitted subjects or objects. The preprocessed consumer description information is then input into the semantic parsing model to improve the accuracy of semantic parsing. Furthermore, after obtaining the consumer intent, the consumer intent and product metadata can be written together into a parsing log. This log can be used to incrementally train or adjust the parameters of the semantic parsing model based on historical parsing records, continuously optimizing the accuracy of consumer intent recognition.

[0090] In addition, after determining the product metadata based on the target product identifier, the integrity of the product metadata can be verified. When the platform determines that key fields are missing in the product metadata, it can obtain supplementary metadata from the data product registration system or the data product metadata management platform and merge the supplementary metadata into the product metadata to ensure the integrity of the product metadata.

[0091] The aforementioned process of simultaneously extracting target product identifiers and consumption description information enables the collaborative acquisition of both data product information and consumption demand information during a single circulation request parsing. This solves the problem of the disconnect between product metadata determination and consumption intent parsing in existing technologies, improving the completeness and processing efficiency of data product circulation request parsing. Furthermore, by performing semantic parsing on consumption description information rather than simple keyword matching, it can accurately understand the natural language requirements within the consumption description information, outputting structured consumption intent. This overcomes the problem of low parsing accuracy under complex semantics and omitted expressions, thereby improving the accuracy and automation level of subsequent data product circulation matching.

[0092] Step 140: Inject product metadata and consumption intent as parameters into the parameterized strategy template to obtain a digital contract;

[0093] Specifically, in the circulation of data products, a digital contract ultimately needs to be generated for the data product to constrain its usage scope, update cycle, and access permissions. After constructing a parameterized strategy template, in response to the circulation request of the data product, the exposed parameter set is extracted from the parameterized strategy template. Based on the product metadata and consumption intent parsed from the circulation request of the data product, the parameters are assigned values ​​to realize the strategy instantiation of the data product and generate an executable digital contract bound to the data product.

[0094] In a preferred embodiment, the process of injecting parameters into a parameterized strategy template to obtain a digital contract includes steps 510-530:

[0095] Step 510: Obtain the list of contract rules for the entire lifecycle of the data product based on the contract strategy atomic components in the parameterized strategy template;

[0096] Specifically, as mentioned above, the parameterized strategy template includes one or more contract strategy atomic components. Each contract strategy atomic component has a component identifier, parameter definition, rule triggering condition, and corresponding data product lifecycle stage identifier. In response to data product circulation requests, the matched parameterized strategy template is parsed, all contract strategy atomic components within the template are traversed, and information such as the component identifier, parameter definition, rule triggering condition, and data product lifecycle stage identifier for each contract strategy atomic component is extracted. Based on the extraction results, a list of contract rules for the entire data product lifecycle is generated. This list of contract rules contains multiple contract rule entries, each corresponding to a contract strategy atomic component, and the contract rule entries identify the parameter items that require parameter values ​​to be injected.

[0097] Step 520: Assign product metadata and consumption intent to the contract rule list to obtain a set of contract strategies;

[0098] Specifically, product metadata and consumption intent are assigned to the contract rule list. Then, based on the data fields in the product metadata and the demand parameters in the consumption intent, each contract rule entry in the list is matched against its parameter items. Matching methods include mapping between parameter item names and product metadata field names, and matching between semantic tags of parameter items and intent tags in the consumption intent. Next, the matched field values ​​from the product metadata are written to the corresponding parameter items in the contract rule entries, and the matched intent parameter values ​​from the consumption intent are written to their corresponding parameter items, completing the assignment of values ​​to each contract rule in the list. After assignment, the contract rule list is transformed into a contract strategy set. Each contract strategy entry in the contract strategy set corresponds to at least one stage in the entire lifecycle of the data product and has specific parameter values.

[0099] Step 530: Obtain the digital contract based on the set of contract strategies;

[0100] Specifically, the various contract strategy entries in the contract strategy set are assembled according to a preset digital contract structure, and the strategy entries in the contract strategy set are arranged into contract terms, contract attachments, or machine-readable execution rules. The assembled digital contract corresponds to a unique contract identifier, and the association between the digital contract and product metadata, consumption intent, and parameterized strategy template is recorded.

[0101] By extracting atomic components of contract strategies from the parameterized strategy template, and automatically generating a list of contract rules for the entire lifecycle of the data product, the method of automatically assigning product metadata and consumption intent as parameters to the contract rule list to form a set of contract strategies, and then generating digital contracts based on this set of contract strategies, solves the problems of low efficiency and error-proneness caused by manually filling in contract terms. Since parameter injection is based on the matching relationship between parameter definitions in the parameterized strategy template and product metadata and consumption intent, it improves the accuracy of parameter assignment and the consistency of digital contract generation, reduces parameter omissions or mismatches, and ensures the matching degree between the digital contract and the rules of the entire lifecycle of the data product and specific consumption needs.

[0102] Furthermore, during the construction of the data product lifecycle strategy template, the parameterized strategy template may contain multiple contract strategy atomic components. These different components may set contradictory or mutually exclusive rules for the same or related stages in the data product lifecycle. For example, one component might require "data storage period not exceeding 7 days," while another requires "data storage period of 30 days." If conflicts between these components are not identified and addressed, they may be directly expanded into contradictory rule entries in the contract rule list, resulting in a digital contract with rule conflicts that cannot be reliably executed. Therefore, in a better implementation, before obtaining the contract rule list for the entire data product lifecycle, a strategy conflict analyzer should be used to process conflicting contract strategy atomic components according to the priority of the contract strategies.

[0103] The strategy conflict analyzer can be understood as a functional logic module used to identify rule conflicts between atomic components of a contract strategy and to resolve conflicts according to the conflict handling strategy. In this application, the strategy conflict analyzer is used to handle conflicting atomic components of the contract strategy according to the priority of the contract strategy. For example, the strategy conflict analyzer can compare the parameter ranges and triggering conditions of multiple atomic components of the same contract strategy throughout the entire lifecycle of the same data product. When it detects that "allowed access times of 10 times" and "allowed access times of unlimited times" both exist in the "data usage" stage, it determines that there is a conflict between the two atomic components of the contract strategy.

[0104] When handling contract conflicts, the strategy conflict analyzer first groups all acquired contract strategy atomic components based on the identifiers of all stages in the data product lifecycle. Contract strategy atomic components with the same data product lifecycle stage identifier are grouped into the same analysis group. Simultaneously, it identifies potential conflicting constraints among contract strategy atomic components spanning different stages of the data product lifecycle. Then, within each analysis group, conflict detection is performed on any two or more contract strategy atomic components. Conflict detection methods include comparing the parameter names, parameter value ranges, triggering conditions, and action types of each contract strategy atomic component. When at least two contract strategy atomic components are detected to have mutually exclusive values ​​on the same parameter item, irreconcilable overlap in parameter value ranges, opposite triggering conditions, or mutually exclusive action types, they are identified as conflicting contract strategy atomic components.

[0105] If conflicting contract strategy atomic components are identified, the strategy conflict analyzer extracts the priority of each contract strategy corresponding to the conflicting atomic components. This priority can be understood as a level identifier used to determine the processing order and retention criteria when a conflict occurs. It can be pre-configured in the contract strategy atomic components of the parameterized strategy template, or dynamically calculated based on factors such as the sensitivity level of the data product, the entire lifecycle of the data product, and constraints in the consumption intent. For example, contract strategies corresponding to legally mandated compliance requirements have a higher priority than those corresponding to commercial agreements. The contract strategies are sorted from highest to lowest priority, retaining the conflicting contract strategy atomic components with the highest priority, and marking the conflicting contract strategy atomic components with lower priority as conflict resolution targets. Conflict resolution targets can be removed from the set of contract strategy atomic components to be expanded, or, when the conflict is only due to overlapping parameter value ranges, the strategy conflict analyzer shrinks the parameter value range of the conflict resolution target to a range that does not conflict with the parameter value range of the retained target. After the above processing, the contract rule list for the entire lifecycle of the data product no longer contains rule contradictions between conflicting contract strategy atomic components.

[0106] Step 150: In response to receiving the signed digital contract, execute the signed digital contract;

[0107] Specifically, after the digital contract is reviewed and confirmed by the data provider and the platform operator, both the data provider and the data user, based on their respective identity credentials, digitally sign the digital contract and its embedded set of contract strategies, forming a two-way authenticated signing certificate. This signed digital contract is then sent to the data circulation platform for execution.

[0108] In the preferred implementation, after a digital contract is signed, the full text of the contract, the set of strategies, the digital signatures of both parties, and the trusted timestamps are stored in the trusted contract storage layer using hash anchoring and distributed ledger technology. This ensures that the stored content is immutable and independently verifiable, providing a solid technical foundation for subsequent contract execution and dispute arbitration.

[0109] Upon receiving a signed digital contract, the data circulation platform obtains the signed digital contract, its corresponding contract strategy set, digital signature, and trusted timestamp. It then concatenates these elements in a preset order to form data to be hashed. This data can be understood as the input data for performing a hash operation. Next, a hash operation is performed on the data to be hashed to obtain the hash value. The hash operation can use algorithms such as SHA-256 or SM3. The hash value is then sent to the blockchain network as on-chain data, requesting its inclusion. The blockchain network, based on the on-chain request, writes the hash value into a new block and connects the new block to the existing blockchain, thus fixing the hash value on the blockchain.

[0110] Simultaneously, a shared ledger is used to jointly maintain the calculated hash value. The data circulation platform writes the calculated hash value into its own node's copy of the shared ledger and synchronizes it to the copies of other participating nodes based on a pre-defined consensus mechanism. Each participating node's copy of the shared ledger stores the same calculated hash value, and any modification to the calculated hash value by any participating node requires consensus verification, thus jointly maintaining the calculated hash value.

[0111] Furthermore, when performing hash operations on the data to be hashed, it is preferable to generate a hash salt value. The hash salt value is a random number appended to the data to be hashed. The hash salt value and the data to be hashed are combined according to a preset method, and then a hash operation is performed to obtain the hash value. The hash salt value and the hash value are then associated and stored in the ledger. During subsequent verification, the hash value is recalculated using the hash salt value and the data to be verified, and compared with the hash value obtained in the ledger to improve collision prevention capabilities.

[0112] Regarding the execution of digital contracts, the parameterized strategy templates may introduce issues such as formatting errors, missing fields, conditional expressions that do not meet syntax requirements, and illegal action type values ​​during generation, combination, and conflict resolution, resulting in syntactic defects in the contract strategy set itself. Therefore, in a preferred embodiment, this application also performs syntax validation on the contract strategy set. If the syntax validation result is successful, the contract strategy set corresponding to the signed digital contract is executed sequentially throughout the entire lifecycle of the data product.

[0113] The syntax validation includes checking the structural integrity of each contract strategy entry in the contract strategy set, the data types of fields, the matching relationship between operators and parentheses in the conditional expression, the value of action type, and the format of parameter values, to determine whether the contract strategy set conforms to preset syntax rules. For example, it checks whether the parameter value corresponding to the contract strategy entry "allowed access count" is an integer type, whether the operands on both sides of the operator in the conditional expression exist, and whether the action type belongs to the preset action type enumeration range.

[0114] If the syntax check passes, the contract strategy entries in the contract strategy set are sorted according to the entire lifecycle sequence of the data product. The contract strategy set corresponding to the signed digital contract is then executed according to the contract strategy execution sequence, following the entire lifecycle sequence of the data product. If the execution of the current contract strategy entry fails, the contract strategy execution sequence can be paused, failure information recorded, an alarm notification issued, or the executed contract strategy entry rolled back. The execution of the next contract strategy entry or the termination of the signed digital contract execution is determined based on the failure handling result.

[0115] Furthermore, when executing the contract strategy set corresponding to the signed digital contract in the order of the entire lifecycle of the data product, it is also necessary to monitor its execution behavior. In a preferred embodiment, this application sets up two monitoring channels that are independent of each other in terms of monitoring basis, monitoring logic, and running process. These two monitoring channels do not share monitoring judgment results and do not depend on the monitoring status of the other. They monitor the execution behavior of the digital contract separately for the contract strategy and the behavior baseline. For example, the two independent monitoring channels run in two independent processes in the data circulation platform and obtain execution behavior data from different data interfaces.

[0116] First, the execution behavior of signed digital contracts is monitored through a primary monitoring channel to ensure it does not exceed the contract policy. This monitoring channel consists of a strategy execution engine and a data access control point within the contract execution engine, employing a separate architecture for the strategy decision point and the strategy execution point. The strategy execution engine is responsible for calculating access decisions, determining in real-time whether to allow or deny a specific data access request. The data access control point intercepts each data access request, initiates an authorization call to the strategy execution engine, and awaits the engine's decision. Based on the engine's decision, it then confirms whether to allow the current data access request. If the execution behavior is determined to exceed the contract policy, the delivery of the current data product can be directly terminated. Simultaneously, all operation logs are recorded on the blockchain to ensure auditability and traceability.

[0117] Simultaneously, a second monitoring channel is used to monitor whether the execution behavior of signed digital contracts exceeds the behavioral baseline. The behavioral baseline refers to a "normal behavior pattern" established from historical behavioral data through machine learning or statistical analysis. The second monitoring channel continuously accesses data access audit logs via a log subscription interface, continuously accesses network traffic mirroring via a network traffic mirroring acquisition interface, and continuously accesses data outgoing events via an event reporting interface. The accessed data access audit logs, network traffic mirroring, and data outgoing events are normalized. Normalization includes extracting session ID, behavior subject, behavior type, behavior parameters, behavior time, target object, transmitted data volume, and outgoing target address. A real-time monitoring engine is built using the normalized multi-source behavioral data. The real-time monitoring engine evaluates the behavioral baseline of each execution behavior in real time, reads the behavioral baseline corresponding to the current execution behavior from the behavioral baseline storage, and calculates the deviation based on the behavioral feature value of the current execution behavior and the behavioral baseline. Simultaneously, the real-time monitoring engine matches the current execution behavior against preset rules to determine whether the current execution behavior hits a rule. Once the deviation exceeds a threshold or a rule is hit, the real-time monitoring engine generates an alarm event and attaches a snapshot of behavioral evidence.

[0118] The two independent monitoring channels described above can independently monitor the same execution behavior from the dimensions of contract strategy compliance and behavioral baseline compliance, respectively. Any violation detected by either monitoring channel will trigger anomaly handling, improving the comprehensiveness of monitoring. The two independent monitoring channels are independent in their operation process and monitoring logic, avoiding single-point failures that could lead to overall monitoring failure, enhancing the reliability and bypass resistance of monitoring, and ensuring the secure and controllable execution of digital contracts.

[0119] The data circulation lifecycle security management method provided in this application parses the circulation requests of data products to obtain product metadata and consumption intentions. The product metadata and consumption intentions are then injected as parameters into the parameterized strategy template of the pre-configured contract strategy atomic components corresponding to the entire lifecycle of the data product to obtain a digital contract. This achieves closed-loop governance of self-arrangement of contract strategies and self-execution of digital contracts, reduces the professional threshold and time cost of contract drafting, eliminates the semantic gap between data usage intentions and rules, improves the accuracy of matching data products with contract strategies, avoids omissions and deviations caused by manual matching, and ensures the logical self-consistency of the final digital contract rules.

[0120] In a second aspect, this application also provides a data circulation lifecycle security management device. The data circulation lifecycle security management device provided by this invention will be described below, and the data circulation lifecycle security management device described below can be referred to in correspondence with the data circulation lifecycle security management method described above. Figure 6This is a structural diagram of the data circulation lifecycle security management device provided by the present invention, as shown below. Figure 6 As shown, the device includes:

[0121] The request receiving unit 610 is configured to receive the circulation request of the data product.

[0122] Template invocation unit 620 is configured to invoke a parameterized strategy template corresponding to the circulation request of the current data product. The parameterized strategy template includes contract strategy atomic components corresponding to the entire lifecycle of the data product, and each contract strategy atomic component corresponds to an indivisible contract strategy.

[0123] The request parsing unit 630 is configured to parse the circulation request of the data product to obtain product metadata and consumption intent.

[0124] The contract generation unit 640 is configured to inject the product metadata and consumption intention as parameters into the parameterized strategy template to obtain a digital contract;

[0125] Contract execution unit 650 is configured to execute the signed digital contract in response to receiving the signed digital contract.

[0126] The data circulation lifecycle security management device provided in this application parses the circulation requests of data products to obtain product metadata and consumption intentions. It then injects the product metadata and consumption intentions as parameters into a pre-configured parameterized strategy template corresponding to the atomic components of the contract strategy throughout the data product's lifecycle to obtain a digital contract. This achieves closed-loop governance of self-arrangement of contract strategies and self-execution of digital contracts, reduces the professional threshold and time cost of contract drafting, eliminates the semantic gap between data usage intentions and rules, improves the accuracy of matching data products with contract strategies, avoids omissions and deviations caused by manual matching, and ensures the logical self-consistency of the final digital contract rules.

[0127] Other preferred embodiments, specific implementations, technical problems that can be solved, and technical effects that can be achieved by the above-mentioned data circulation full lifecycle security management device all correspond to the data circulation full lifecycle security management method, and will not be repeated here.

[0128] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0130] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for data circulation lifecycle security management, characterized in that, The method includes: Receive requests for the circulation of data products; Invoke the parameterized strategy template corresponding to the circulation request of the current data product, wherein the parameterized strategy template includes contract strategy atomic components corresponding to the entire life cycle of the data product, and each contract strategy atomic component corresponds to an indivisible contract strategy; The data product circulation request is analyzed to obtain product metadata and consumption intent; The product metadata and consumption intent are injected as parameters into the parameterized strategy template to obtain a digital contract; Upon receiving a signed digital contract, the signed digital contract is executed.

2. The method according to claim 1, characterized in that, Before receiving a data product circulation request, the method further includes: Construct parameterized strategy templates for all data products; wherein, for each data product, the process of constructing the parameterized strategy template includes: The contract strategy for the data product is determined based on the entire lifecycle of the data product. The contract strategy is encapsulated as an atomic component of the contract strategy; The parameterized strategy template is constructed based on the atomic components of the contract strategy.

3. The method according to claim 1, characterized in that: The data product circulation request includes: target product identifier and consumption description information; The steps of parsing the circulation request of the data product to obtain product metadata and consumption intention include: The circulation request of the data product is parsed to obtain the target product identifier and consumption description information; The product metadata is determined based on the target product identifier, and the consumption intention is obtained by semantic parsing the consumption description information.

4. The method according to claim 3, characterized in that, The step of semantically parsing the consumption description information to obtain the consumption intention includes: The consumption intent is obtained by semantic parsing the consumption description information using an intent description model. The consumption intent includes one or more of the following: consumption purpose information, usage method information, update cycle information, and usage scope information.

5. The method according to claim 1, characterized in that, The steps of injecting the product metadata and consumption intent as parameters into the parameterized strategy template to obtain a digital contract include: Based on the contract strategy atomic components in the parameterized strategy template, a list of contract rules for the entire lifecycle of the data product is obtained; The product metadata and consumption intent are assigned to the contract rule list to obtain a set of contract strategies; A digital contract is obtained based on the set of contract strategies.

6. The method according to claim 5, characterized in that, Before obtaining the list of contract rules for the entire lifecycle of the data product, the method further includes: The strategy conflict analyzer is used to process conflicting contract strategy atomic components according to the priority of the contract strategy.

7. The method according to claim 5, characterized in that, In response to receiving the signed digital contract, the method further includes: A hash operation is performed on the signed digital contract, the contract strategy set corresponding to the signed digital contract, the digital signature, and the trusted timestamp, and the hash value obtained from the operation is fixed on the blockchain; The hash value obtained from the above operation is maintained using a split ledger.

8. The method according to claim 1, characterized in that, Before executing the signed digital contract, the method further includes: Perform syntax validation on the aforementioned set of contract strategies; If the syntax verification result is passed, the set of contract strategies corresponding to the signed digital contract is executed in the order of the entire lifecycle of the data product.

9. The method according to claim 8, characterized in that, The steps of executing the set of contract strategies corresponding to the signed digital contract in the order of the entire lifecycle of the data product include: The first monitoring channel is used to monitor whether the execution behavior of the signed digital contract exceeds the contract policy; Furthermore, the second monitoring channel is used to monitor whether the execution behavior of the signed digital contract exceeds the behavior baseline.

10. A data circulation full lifecycle security management device, characterized in that, The device includes: The request receiving unit is configured to receive requests for the flow of data products. The template invocation unit is configured to invoke the parameterized strategy template corresponding to the circulation request of the current data product. The parameterized strategy template includes contract strategy atomic components corresponding to the entire lifecycle of the data product, and each contract strategy atomic component corresponds to an indivisible contract strategy. The request parsing unit is configured to parse the circulation request of the data product to obtain product metadata and consumption intent; The contract generation unit is configured to inject the product metadata and consumption intention as parameters into the parameterized strategy template to obtain a digital contract; A contract execution unit is configured to execute a signed digital contract in response to receiving such a contract.

Images