A trusted data space construction method, device and medium based on Eclipse EDC

Abstract

The application discloses a trusted data space construction method and device based on Eclipse EDC, and a medium, and relates to the technical field of data security. The method comprises the following steps: deploying a local connector to scan a data source and obtain to-be-processed data; using an NLP algorithm to classify the data according to sensitivity, identify sensitive fields and corresponding levels; according to the classification result, selecting a corresponding calculation strategy for processing to form to-be-transmitted data; desensitizing the data through a regular expression and synchronizing the result to the cloud to generate an ODRL strategy; converting the ODRL strategy into WASM bytecode instructions according to a preset rule; and finally injecting a monitoring hook into the local connector and relying on the WASM instructions to perform real-time monitoring on the calling behavior, so as to construct a trusted data space. The application classifies the sensitivity by the above method, converts the standardized ODRL strategy into WASM bytecode, injects a monitoring hook for real-time monitoring, ensures the compliance of data use, and reduces the risk of data leakage.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security technology, and particularly relates to a trusted data space construction method based on Eclipse EDC, equipment and medium. BACKGROUND

[0002] In the field of distributed computing and data security, as a key carrier for realizing the circulation of data elements, the trusted data space directly affects the security and efficiency of data sharing. However, the existing technology has significant defects in data sovereignty protection, cross-domain collaboration, contract execution, privacy computing deployment, and the balance between availability and sovereignty, as follows:

[0003] In cross-domain data collaboration, the existing scheme relies on manual matching and negotiation strategies, which is inefficient and significantly increases the time and labor costs of cross-domain collaboration. Meanwhile, contract execution lacks technical enforcement, and the existing trusted data space can only implement API-level access control and cannot forcibly prevent data leakage caused by terminal users through physical operations such as screen capture and copying. In terms of privacy computing, the existing EDC framework only supports basic data transmission and lacks deep integration with TEE (Trusted Execution Environment) and federated learning, resulting in the need to deploy privacy computing separately from the data space, which increases the technical application cost and threshold.

[0004] Therefore, how to realize privacy computing according to data sensitivity and automatic cross-domain strategy conversion based on the Eclipse EDC framework has become a problem to be solved. SUMMARY

[0005] The embodiments of the present application provide a trusted data space construction method based on Eclipse EDC, equipment and medium, to solve the technical problem of how to realize privacy computing according to data sensitivity and automatic cross-domain strategy conversion based on the Eclipse EDC framework.

[0006] In a first aspect, the embodiments of the present application provide a trusted data space construction method based on Eclipse EDC, which comprises the following steps: deploying a local connector, and scanning a data source through the local connector to obtain to-be-processed data; performing sensitivity classification on the to-be-processed data based on an NLP algorithm to obtain sensitive fields and a data sensitivity classification result; performing calculation on the to-be-processed data based on a data sensitivity classification result and a data calculation strategy corresponding to the data sensitivity classification result to obtain to-be-transmitted data; performing desensitization on the to-be-transmitted data based on a regular expression to obtain desensitized data, and synchronizing the desensitized data to a cloud service platform to generate an ODRL policy; converting the ODRL policy into WASM bytecode instructions based on a preset conversion rule; injecting a monitoring hook into the local connector, and performing real-time monitoring on the calling behavior of the local connector based on the WASM bytecode instructions to construct a trusted data space.

[0007] In an implementation manner of the present application, the local connector and the cloud service platform are deployed, and the data source is scanned through the local connector to obtain the to-be-processed data, specifically including: loading the connection parameters of the data source, and establishing a connection channel between the local connector and the data source to deploy the local connector; wherein the data source includes an internal database, a file system and / or an API service; the data source is scanned based on a preset scanning strategy, and structured meta-information in the data source is extracted to obtain the to-be-processed data.

[0008] In an implementation manner of the present application, based on the data sensitivity classification result, the data calculation strategy corresponding to the data sensitivity is selected to calculate the to-be-processed data, specifically including: if the data sensitivity is low sensitivity, a query rewriting module is called to directly query the low sensitivity data and to desensitize the query result; if the data sensitivity is medium sensitivity, a trusted execution environment is dispatched, and secure calculation is performed in an encrypted environment; if the data sensitivity is high sensitivity, federated machine learning is started, and calculation is completed by the local connector, and only the calculation process is shared.

[0009] In an implementation manner of the present application, the to-be-processed data is desensitized based on the regular expression to obtain the desensitized data, specifically including: based on the sensitivity classification result, a regular expression rule corresponding to the sensitive field is called, and the sensitive field is subjected to mask desensitization and / or replacement desensitization; a user's custom desensitization rule is accepted, and the sensitive field not covered by the regular expression rule is subjected to supplementary desensitization processing to obtain the desensitized data.

[0010] In an implementation manner of the present application, the desensitized data is synchronized to the cloud service platform to generate the ODRL policy, specifically including: establishing a secure communication channel between the local connector and the cloud service platform, and verifying the identity by using a two-way authentication mechanism; performing block encryption processing on the desensitized data to obtain an encrypted data packet, and uploading the encrypted data packet to the cloud directory service module; parsing the encrypted data packet in the cloud directory service module to obtain parsed metadata information, and verifying the data integrity and source authenticity of the parsed metadata information; generating the ODRL policy containing data usage terms based on the parsed metadata information.

[0011] In an implementation manner of the present application, the ODRL policy is converted into WASM bytecode instructions based on preset conversion rules, specifically including: parsing the ODRL policy, and extracting the operation subject, action type and resource object in the ODRL policy to obtain a triple relationship; matching the triple relationship with the preset conversion rules to generate WASM bytecode instructions corresponding to the triple relationship; wherein the preset conversion rules are obtained from an industry compliance rule knowledge base and a national data infrastructure API.

[0012] In an implementation manner of the present application, a monitoring hook is injected in the local connector, and the calling behavior of the local connector is monitored in real time based on the WASM bytecode instructions to build a trusted data space, specifically including: parsing the behavior constraint conditions in the WASM bytecode instructions to generate operating system level monitoring rules corresponding to the WASM bytecode instructions; deploying the monitoring hook in the operating system kernel layer of the local connector, and establishing a mapping relationship between the monitoring hook and the monitoring rules; when a calling behavior that violates the monitoring rules is detected, triggering a security interrupt mechanism to terminate the calling behavior, and generating an encrypted violation evidence data packet to build a trusted data space.

[0013] In an implementation manner of the present application, after the trusted data space is built, the method further includes: responding to the life cycle constraint conditions in the WASM bytecode instructions, and triggering an expiration destruction mechanism; synchronously updating the state marker of the cloud directory service module, and removing the corresponding data index; generating a destruction proof file containing an operation hash value, and performing audit evidence on the destruction proof file.

[0014] In a second aspect, the embodiments of the present application also provide a trusted data space construction device based on Eclipse EDC, comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: deploy a local connector, and scan a data source through the local connector to obtain to-be-processed data; based on an NLP algorithm, classify sensitivity of the to-be-processed data to obtain a sensitive field and a data sensitivity classification result; based on the data sensitivity classification result, select a data calculation strategy corresponding to the data sensitivity classification result to calculate the to-be-processed data to obtain to-be-transmitted data; based on a regular expression, desensitize the to-be-transmitted data to obtain desensitized data, and synchronize the desensitized data to a cloud service platform to generate an ODRL policy; based on a preset conversion rule, convert the ODRL policy into WASM bytecode instructions; inject a monitoring hook into the local connector, and based on the WASM bytecode instructions, monitor a calling behavior of the local connector in real time to construct a trusted data space.

[0015] In a third aspect, the embodiments of the present application also provide a nonvolatile computer storage medium for constructing a trusted data space based on Eclipse EDC, which stores computer executable instructions configured to: deploy a local connector, and scan a data source through the local connector to obtain to-be-processed data; based on an NLP algorithm, classify sensitivity of the to-be-processed data to obtain a sensitive field and a data sensitivity classification result; based on the data sensitivity classification result, select a data calculation strategy corresponding to the data sensitivity classification result to calculate the to-be-processed data to obtain to-be-transmitted data; based on a regular expression, desensitize the to-be-transmitted data to obtain desensitized data, and synchronize the desensitized data to a cloud service platform to generate an ODRL policy; based on a preset conversion rule, convert the ODRL policy into WASM bytecode instructions; inject a monitoring hook into the local connector, and based on the WASM bytecode instructions, monitor a calling behavior of the local connector in real time to construct a trusted data space.

[0016] The Eclipse EDC-based trusted data space construction method, device and medium provided by the embodiment of the application have the following beneficial effects: the pre-computed sensitivity classification is realized through an NLP algorithm, low-sensitive data is directly processed, medium-sensitive data is calculated through TEE, and high-sensitive data is calculated through federated learning, a gradient protection system is formed, and performance loss caused by excessive encryption is avoided; a double-engine of regular expressions and custom rules covers common sensitive patterns and supports user extension of special field rules, high-precision desensitization is realized; the cloud service platform automatically generates an ODRL policy conforming to a standard according to the metadata of desensitized data, converts the text policy into executable code through a conversion rule driven by an industry compliance rule knowledge base, records evidence of violation through a monitoring hook, and supports post-audit and responsibility identification. BRIEF DESCRIPTION OF DRAWINGS

[0017] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and serve to explain the principles of the application, and do not limit the application. In the drawings:

[0018] Figure 1 A flowchart of an Eclipse EDC-based trusted data space construction method is provided for the embodiment of the application.

[0019] Figure 2 An internal structure schematic diagram of an Eclipse EDC-based trusted data space construction device is provided for the embodiment of the application. DETAILED DESCRIPTION

[0020] To make the objectives, technical solutions and advantages of the application clearer, the technical solutions of the application will be described below in detail with reference to the embodiments of the application and the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the application, but not all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the application.

[0021] The Eclipse EDC-based trusted data space construction method, device and medium provided by the embodiment of the application are used to solve the technical problem of how to realize privacy calculation according to data sensitivity and automatic cross-domain policy conversion based on the Eclipse EDC framework.

[0022] The technical solutions of the embodiments of the application will be described in detail below with reference to the accompanying drawings.

[0023] Figure 1 A flowchart of an Eclipse EDC-based trusted data space construction method is provided for the embodiment of the application. As shown in FIG. 1, the method comprises the following steps.Figure 1 As shown, the application embodiment provides a trusted data space construction method based on Eclipse EDC, which specifically comprises the following steps:

[0024] Step 10: Deploy the local connector and scan the data source through the local connector to obtain the data to be processed.

[0025] As an optional embodiment, the local connector is deployed with the cloud service platform, and the data source is scanned through the local connector to obtain the data to be processed, which can specifically include: step 101: loading the connection parameters of the data source, and establishing the connection channel between the local connector and the data source to deploy the local connector.

[0026] In this step, first, the connection parameters of the data source are loaded, wherein the data source includes internal database, file system and API service, etc., and the connection parameters include access address, port number, authentication information (such as account password, key, etc.) and other key configurations, which ensure that the local connector can access the data source legally and safely; then, based on these parameters, the local connector establishes a stable connection channel with the data source through the corresponding communication protocol (such as JDBC / ODBC protocol for database, file transfer protocol for file system, HTTP / HTTPS protocol for API service, etc.), thereby completing the deployment of the local connector on the user side.

[0027] Step 102: Based on the preset scanning strategy, the data source is scanned, and the structured meta-information in the data source is extracted to obtain the data to be processed.

[0028] In this step, first, the local connector will perform the scanning operation according to the preset scanning strategy, which can include scanning range (such as specified database table, file directory, API interface), scanning frequency (such as real-time scanning, timing scanning), scanning depth (such as only scanning the surface structure, deeply nested structure) and other rules to efficiently and orderly cover the target data source; during the scanning process, the structured meta-information in the data source is extracted, which is the key data describing the data organization form, including the table structure in the database (such as the association relationship between fields), the name of each field, the data type corresponding to the field (such as string, numerical value, date, etc.), etc.; through the above scanning and extracting operation, the structured meta-information obtained finally is used as the data to be processed for subsequent data processing, which provides a basis for subsequent sensitivity classification, desensitization and other operations.

[0029] Step 20: Based on the NLP algorithm, the sensitivity classification is performed on the data to be processed to obtain the sensitive field and the data sensitivity classification result.

[0030] In this step, the NLP algorithm identifies entities, semantic features and contextual associations in the text through the trained model, and marks them as potential sensitive fields. At the same time, combined with the pre-set sensitive information classification standards such as personal information PII, personal health information PHI, and business secrets, these fields are subdivided and classified. On the basis of identifying sensitive fields, further according to the factors such as the leakage risk and the associated impact of the fields, the data sensitivity level is determined through the semantic weight analysis of the NLP algorithm, and finally the data sensitivity classification results are formed, for example, the fields containing personal biological characteristics and core business data will be judged as high sensitivity; the fields containing indirect personal identification and general business data may be classified as medium sensitivity; and the general information fields not involving privacy or business secrets are classified as low sensitivity. This process does not require manual intervention, and through the automatic processing of the NLP algorithm, it not only guarantees the efficiency of classification, but also improves the accuracy of sensitive information identification in complex semantic scenarios, providing accurate basis for subsequent desensitization processing, calculation path selection and other operations.

[0031] Step 30: Based on the data sensitivity classification result, a data calculation strategy corresponding to the data sensitivity classification result is selected to calculate the to-be-processed data to obtain the to-be-transmitted data.

[0032] As an optional embodiment, based on the data sensitivity classification result, a data calculation strategy corresponding to the data sensitivity is selected to calculate the to-be-processed data, which can specifically include: step 301: if the data sensitivity is low, a query rewriting module is called to directly query the low-sensitive data and perform desensitization processing on the query result.

[0033] In this step, for low-sensitive data, efficient data use is achieved by calling the query rewriting module, which can adaptively adjust the query request initiated by the user to ensure that the query operation meets the pre-set rules; then, the low-sensitive data stored locally is directly queried, and after obtaining the original query result, desensitization rules (such as partial field masking, format conversion, etc.) are automatically applied to remove or blur the possible slight sensitive information, and finally the desensitized result is returned to the user, which improves the use efficiency while ensuring the basic safety of the data.

[0034] Step 302: If the data sensitivity is medium, a trusted execution environment is scheduled, and secure calculation is performed in an encrypted environment.

[0035] In this step, when the medium sensitive data needs to be used, the trusted execution environment (TEE) is scheduled, which is a hardware isolation-based secure area that can provide an independent encrypted running space; the data is loaded into the encrypted environment, and all computing operations are completed in the TEE to ensure that the original data is not leaked outside the environment, and the computing process is protected at the hardware level to avoid malicious interception or tampering, and finally only the encrypted processed computing result is output, realizing the safe use of medium sensitive data.

[0036] Step 303: If the data sensitivity is high, start federated machine learning and complete the calculation in the local connector, and only share the calculation process.

[0037] In this step, for high sensitive data, the federated machine learning mode is adopted, which allows multiple parties to cooperate to complete the computing task without sharing the original data; the high sensitive data is always left in the local connector, and the relevant calculation is completed locally, and the participants only need to encrypt and share the intermediate results (not the original data) generated in the calculation process, and the global calculation goal is achieved by aggregating these intermediate results, which fundamentally eliminates the risk of high sensitive original data out of the domain, while meeting the computing needs of multiple parties.

[0038] Step 40: Based on the regular expression, the data to be transmitted is desensitized to obtain desensitized data, and the desensitized data is synchronized to the cloud service platform to generate the ODRL policy.

[0039] As an optional embodiment, based on the regular expression, the data to be processed is desensitized to obtain desensitized data, and the desensitized data is synchronized to the cloud service platform to generate the ODRL policy, which can specifically include: step 401: based on the sensitivity classification result, calling the regular expression rule corresponding to the sensitive field, and performing mask desensitization and / or replacement desensitization on the sensitive field.

[0040] In this step, first, according to the sensitivity classification result obtained by the NLP algorithm before, the sensitive field to be processed is located; then, according to the type of the sensitive field, the corresponding preset regular expression rule is automatically called, which is a pattern matching logic designed for a specific sensitive field format and can accurately identify the sensitive content in the field; after completing the sensitive field identification, the mask desensitization or replacement desensitization method is applied, wherein the mask desensitization hides the sensitive information by retaining part of the characters and masking the rest of the characters, which maintains the data format characteristics and avoids complete information leakage; the replacement desensitization replaces the original sensitive content with fictitious but consistent information, ensuring that the data still has certain usability in the use scenario. The two methods can be used alone or in combination according to the characteristics of the sensitive field, and finally form desensitized data that meets the safety requirements, laying a foundation for subsequent data synchronization and circulation.

[0041] Step 402: Accept the user's custom desensitization rules, and supplement the desensitization processing of sensitive fields not covered by regular expression rules to obtain desensitized data.

[0042] In this step, due to differences in data types and business needs of different users, some sensitive fields may not be recognized by general regular expression rules due to special formats or unique scenarios. At this time, users are allowed to upload custom desensitization rules, such as specific Python scripts, etc. These custom rules can achieve targeted desensitization based on user definitions of sensitive fields, such as fragment replacement for specific enterprise internal numbers or semantic-level fuzzing of implicit sensitive information in unstructured text. After loading user-defined rules, supplementary desensitization is performed on sensitive fields not covered by regular expressions, ensuring that all sensitive information is properly handled. Through the combination of preset rules and custom rules, both universality and efficiency of desensitization processing are guaranteed, and personalized needs are also considered, ultimately forming desensitized data that comprehensively covers and meets user's actual scenarios, providing complete protection for subsequent data security circulation.

[0043] Step 403: Establish a secure communication channel between the local connector and the cloud service platform, and use a two-way authentication mechanism to verify identity.

[0044] In this step, first, the local connector and the cloud service platform establish a secure communication channel through encryption protocols such as TLS / SSL, and perform real-time encryption processing on the transmitted data to prevent eavesdropping, tampering, or forgery during transmission, ensuring the confidentiality and integrity of the data transmission link. On this basis, a two-way authentication mechanism is started to verify the identity of both parties. The local connector submits its digital certificate to the cloud service platform, which verifies the validity of the certificate to confirm the legal identity of the local connector. At the same time, the cloud service platform also provides its digital certificate to the local connector, which confirms the authenticity of the cloud service platform through the same verification logic. Through this two-way verification, both parties can ensure the legality of the communication object, avoiding malicious nodes pretending to be connectors or cloud platforms for illegal access, and blocking security risks caused by identity fraud from the source, providing a trusted communication foundation for subsequent data synchronization, policy interaction, and other operations.

[0045] Step 404: Block encryption processing is performed on the desensitized data to obtain an encrypted data packet, and the encrypted data packet is uploaded to the cloud directory service module.

[0046] In this step, first, the desensitization data is divided into blocks according to the preset rules. The size of each block of data after splitting is uniform and independent, which facilitates subsequent parallel encryption processing to improve efficiency, and reduces the risk of single data leakage affecting the scope during transmission or storage. For each part of the data after splitting, a symmetric encryption algorithm (such as AES) is used for encryption processing, and an independent encryption key is generated for each block of data. At the same time, these keys are encrypted twice (i.e., key encryption key, KEK), forming a complete encrypted data packet. Each data packet contains encrypted data blocks, corresponding key information, and data block indexes. After encryption, the encrypted data packets are sequentially uploaded to the cloud directory service module through the previously established secure communication channel. The integrity of the data packets is also verified in real time during the upload process to ensure that the data has not been tampered with after being transmitted to the cloud. Through the combination of block encryption and secure upload, the desensitized data can be prevented from being illegally parsed during cloud storage or transmission, and the structured management of encrypted data can be realized through the directory service module, providing a basis for subsequent metadata analysis and policy generation.

[0047] Step 405: In the cloud directory service module, the encrypted data packet is parsed to obtain the parsed metadata information, and the data integrity and source authenticity of the parsed metadata information are verified.

[0048] In this step, first, the cloud directory service module receives the encrypted data packet and calls the corresponding decryption program to perform layered decryption on the encrypted data packet using the pre-shared key system. The key encryption key used to protect the data block key is decrypted first, and then each data block is decrypted using the decrypted key. Finally, the metadata information contained in the data packet, such as data structure, field attribute, and desensitization identifier, is extracted. These metadata are key information that describes the characteristics of the data and do not contain the original data content. After obtaining the parsed metadata information, a dual verification mechanism is started. On the one hand, the consistency of the hash value attached to the data packet with the hash value calculated after parsing the metadata is verified to ensure the integrity of the data during transmission and parsing. On the other hand, the digital signature embedded in the metadata is checked to confirm whether the source of the metadata is the authenticated local connector, ensuring the authenticity of the source. Through integrity and authenticity verification, the cloud directory service module can ensure that the metadata processed is accurate and reliable, providing a reliable basis for generating ODRL policies based on metadata in the future.

[0049] Step 406: Based on the parsed metadata information, an ODRL policy containing data usage terms is generated.

[0050] In this step, based on the metadata information parsed by the cloud service platform, the key features related to data use are extracted, including data type, sensitivity level, field attribute, and desensitization identification, etc. These features directly determine the scope and restrictions of data use; on the basis of extracting key features, according to industry compliance requirements, data sovereignty agreement and user-defined rules, these features are mapped to specific data use clauses, and these clauses are finally encapsulated as ODRL (Open Digital Rights Language) policies conforming to the Eclipse EDC framework specification. The policy explicitly defines the data use subject, allowed operation type, constraint condition and violation handling rule in a standardized structured format, providing a unified semantic basis and operation basis for subsequent policy execution and monitoring. Through this process, the metadata information is transformed into rights rules with legal binding force and technical executability, ensuring that the data always meets the preset safety and compliance requirements in circulation.

[0051] Step 50: Convert the ODRL policy into WASM bytecode instructions based on the preset conversion rules.

[0052] As an optional embodiment, the ODRL policy is converted into WASM bytecode instructions based on the preset conversion rules, which can specifically include: step 501: parsing the ODRL policy and extracting the operation subject, action type and resource object in the ODRL policy to obtain a triple relationship.

[0053] In this step, the structured document of the ODRL policy is parsed and analyzed by the policy parsing engine to identify various elements defined therein. The operation subject refers to the entity authorized or restricted to use the data, the action type refers to the specific data operation allowed or prohibited, and the resource object refers to the data subject to the policy constraints. By parsing, the three core elements are associated to form a triple relationship of "operation subject-action type-resource object". This triple relationship converts the abstract rights and constraints in the ODRL policy into specific and explicit association logic, providing a structured mapping basis for converting the policy into WASM bytecode instructions in the future, ensuring that each rule in the policy can be accurately converted into executable monitoring and control instructions.

[0054] Step 502: Match the triple relationship with the preset conversion rules to generate WASM bytecode instructions corresponding to the triple relationship.

[0055] In this step, the preset conversion rule library is called, which is a mapping system constructed based on industry compliance standards, technical specifications and safety requirements, and contains the corresponding logic of various elements in the triple relationship and the WASM instruction set, for example, the "query" action corresponds to the data read interception instruction, the "high sensitive resource" corresponds to the encryption verification instruction, and the "specific subject" corresponds to the identity verification instruction; In the matching process, the extracted triple is compared with the entries in the rule library one by one, and the corresponding conversion rule is located according to the specific content of the triple, for example, when the triple is "enterprise A-transmission-medium sensitive data", it is matched to the rule corresponding to "transmission action + medium sensitive resource", and the WASM bytecode instruction containing identity secondary verification, transmission encryption, log recording and other functions is generated; If the triple involves prohibited provisions, such as "unauthorized subject-modification-high sensitive data", it will match the rules related to interception and blocking, and generate the corresponding prohibited execution instruction; Through this accurate matching, the abstract policy constraints are converted into WASM bytecode that can be directly executed in the local connector runtime environment, ensuring that each right and restriction in the ODRL policy can be strictly enforced through technical means, providing bottom-level instruction support for real-time monitoring and control of data operations.

[0056] Step 60: Injecting a monitoring hook in the local connector, and based on the WASM bytecode instruction, real-time monitoring of the calling behavior of the local connector is performed to build a trusted data space.

[0057] As an optional embodiment, injecting a monitoring hook in the local connector, and based on the WASM bytecode instruction, real-time monitoring of the calling behavior of the local connector is performed to build a trusted data space, which can specifically include: step 601: parsing the behavior constraint conditions in the WASM bytecode instruction to generate operating system level monitoring rules corresponding to the WASM bytecode instruction.

[0058] In this step, the WASM bytecode instruction is first reverse analyzed to extract the behavior constraint conditions contained therein, which are derived from the rights and restrictions in the ODRL policy, and specifically manifested as the permission boundary of the operation subject, the access range of the resource object, and the allowed or prohibited rules of the action type; After extracting the constraint conditions, these logics are converted into monitoring rules that can be recognized by the operating system kernel, which directly act on the kernel layer of the local connector and can accurately intercept various system calls such as file reading and writing, network transmission, process creation, etc., ensuring that each constraint condition can be enforced by the underlying system mechanism; Through this conversion, the abstract constraints in the WASM bytecode instruction are materialized into monitoring logics that the operating system can directly respond to, laying a technical foundation for subsequent real-time monitoring through the monitoring hook.

[0059] Step 602: Deploy monitoring hooks in the operating system kernel layer of the local connector, and establish a mapping relationship between the monitoring hooks and the monitoring rules.

[0060] In this step, monitoring hooks are implanted in the operating system kernel layer where the local connector runs. These hooks are a piece of program code embedded in the kernel function that can capture kernel-level key operation events in real time, such as data read-write requests, network transmission instructions, process interaction behaviors, etc. It is equivalent to setting "sensors" at the bottom layer to ensure that all data-related operations can be sensed immediately. Then, a mapping relationship between the monitoring hooks and the previously generated operating system-level monitoring rules is established, i.e., it is clear which monitoring rules each monitoring hook corresponds to, and which rule verification logic should be triggered when the hook captures a specific operation event. For example, the hook responsible for capturing "file reading" events will be mapped with "high-sensitive data reading permission verification", "access time period limitation" and other rules; the hook responsible for capturing "network sending" events will be associated with "data transmission subject authentication", "transmission encryption verification" and other rules. Through this mapping, when data operations occur at the kernel layer, the monitoring hook can immediately call the corresponding monitoring rule for legality judgment, realizing seamless connection of "event capture-rule verification", and providing bottom-layer technical support for subsequent real-time monitoring and violation blocking.

[0061] Step 603: When a call behavior that violates the monitoring rules is detected, trigger the security interruption mechanism to terminate the call behavior and generate encrypted violation evidence data packets to build a trusted data space.

[0062] In this step, when the monitoring hook of the local connector captures a data call behavior, it will perform real-time verification according to the mapped monitoring rules. Once it finds that the call behavior violates the rules, it will immediately trigger the security interruption mechanism, which sends an interruption signal to the operating system kernel to forcibly terminate the current violation call process and prevent the violation operation from continuing to execute, thereby cutting off the path of data leakage or abuse from a technical perspective. At the same time of terminating the violation behavior, it automatically collects key information related to the violation event, including the identity of the call subject, the type and timestamp of the violation operation, the information of the resource object involved, etc. After integrating these information, it is encrypted using asymmetric encryption algorithm to generate tamper-proof violation evidence data packets. These data packets are stored synchronously in the local connector and the cloud service platform, serving as the basis for subsequent responsibility tracing and providing original materials for compliance audit. Through immediate blocking and evidence solidification of violation behavior, a complete closed loop of "monitoring-identification-response-recording" is formed, ensuring that data operations are always within the preset rules, and ultimately providing solid security guarantee for the construction of trusted data space.

[0063] Step 604: Respond to the life cycle constraint conditions in the WASM bytecode instructions and trigger the expiration destruction mechanism.

[0064] In this step, the life cycle constraints embedded in the WASM bytecode instructions are continuously monitored, which are derived from the data usage period specified in the ODRL policy and have been transformed into instruction logic that can be recognized by the local connector runtime environment. When the data usage triggers the life cycle constraints are detected, the expiration destruction mechanism is automatically started. The mechanism first locates the target data, including the original data copy stored locally, temporary data in the cache, and related metadata records; then, through multiple rounds of overwriting disk sectors, clearing memory cache, deleting index entries, and other operations, it completely removes the physical storage traces of the data. If equipped with a TPM or other hardware security module, it will also call hardware-level erasure instructions to ensure that the data cannot be recovered; at the same time, key information of the destruction process, such as destruction time, execution node, operation log, etc. will be encrypted and recorded and synchronized to the cloud, generating an unalterable destruction certificate as proof of data life cycle closed-loop management. Through the response to the life cycle constraints and the execution of the expiration destruction mechanism, the data is controllable from generation, use to extinction, avoiding the risk of leakage caused by long-term retention, and further strengthening the data sovereignty protection capability of the trusted data space.

[0065] Step 605: Synchronize the state marker of the cloud directory service module and remove the corresponding data index; generate a destruction proof file containing the operation hash value and store the destruction proof file for audit.

[0066] In this step, after the local data is destroyed, a state synchronization instruction is sent to the cloud directory service module to update the state marker of the data from "available" to "destroyed", clearly identifying the current state of the data; at the same time, the index information related to the data in the cloud directory is deleted, including data storage path, access permission record, associated metadata link, etc., so that the cloud cannot locate or access the destroyed data through indexing, cutting off any subsequent operation request for the data from the directory level, ensuring the real-time unity of the cloud and local data state; after completing the data destruction and state synchronization, a destruction proof file is automatically generated, which contains key information of the destruction operation such as destruction time, operation subject, data identifier, destruction method, etc. At the same time, these information is encrypted by hash algorithm to generate a unique operation hash value embedded in the file, ensuring that the file content cannot be tampered with; then, the destruction proof file is uploaded to the trusted third-party audit system for storage, using the credibility of the audit system to permanently save the destruction record for subsequent supervision inspection, compliance audit or dispute tracing, forming a complete closed loop of data full life cycle management.

[0067] The above is a method embodiment of the present application. Based on the same inventive concept, the embodiments of the present application also provide a trusted data space construction device based on Eclipse EDC, the structure of which is shown in Figure 2

[0068] Figure 2 A trusted data space construction device based on Eclipse EDC provided by the embodiments of the present application is shown in Figure 2 The device comprises:

[0069] at least one processor 201;

[0070] and a memory 202 in communication connection with the at least one processor;

[0071] The memory 202 stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor 201 to enable the at least one processor 201 to: deploy a local connector and scan a data source through the local connector to obtain to-be-processed data; based on an NLP algorithm, classify the to-be-processed data in terms of sensitivity to obtain sensitive fields and a data sensitivity classification result; based on the data sensitivity classification result, select a data calculation strategy corresponding to the data sensitivity classification result to calculate the to-be-processed data to obtain to-be-transmitted data; based on a regular expression, desensitize the to-be-transmitted data to obtain desensitized data, and synchronize the desensitized data to a cloud service platform to generate an ODRL policy; based on a preset conversion rule, convert the ODRL policy into WASM bytecode instructions; inject a monitoring hook into the local connector, and based on the WASM bytecode instructions, monitor the calling behavior of the local connector in real time to construct a trusted data space.

[0072] Some embodiments of the present application provide a corresponding Figure 1 ​The application discloses a nonvolatile computer storage medium based on Eclipse EDC trusted data space construction, which stores computer executable instructions, and the computer executable instructions are configured to: deploy a local connector, and scan a data source through the local connector to obtain to-be-processed data; based on an NLP algorithm, the to-be-processed data is classified in sensitivity to obtain a sensitive field and a data sensitivity classification result; based on the data sensitivity classification result, a data computing strategy corresponding to the data sensitivity classification result is selected to compute the to-be-processed data, so as to obtain to-be-transmitted data; based on a regular expression, the to-be-transmitted data is desensitized to obtain desensitized data, and the desensitized data is synchronized to a cloud service platform to generate an ODRL strategy; based on a preset conversion rule, the ODRL strategy is converted into WASM bytecode instructions; a monitoring hook is injected into the local connector, and based on the WASM bytecode instructions, a calling behavior of the local connector is monitored in real time to construct a trusted data space.

Claims

1. A method for constructing a trusted data space based on Eclipse EDC, characterized in that, The method includes: Deploy a local connector and scan the data source through the local connector to obtain the data to be processed; wherein, the data to be processed includes table structure, field names and data types; Based on NLP algorithms, the data to be processed is classified for sensitivity to obtain sensitive fields and data sensitivity classification results. Based on the data sensitivity classification results, a data calculation strategy corresponding to the data sensitivity classification results is selected to calculate the data to be processed, so as to obtain the data to be transmitted; wherein, the data sensitivity classification results include low sensitivity, medium sensitivity and high sensitivity; Based on regular expressions, the data to be transmitted is de-identified to obtain de-identified data, and the de-identified data is synchronized to the cloud service platform to generate an ODRL policy; wherein, the ODRL policy is a standardized policy expression form under the Eclipse EDC framework; Based on preset conversion rules, the ODRL strategy is converted into WASM bytecode instructions; wherein, the WASM bytecode instructions are used to respond to data operation events in the local connector; A monitoring hook is injected into the local connector, and the calling behavior of the local connector is monitored in real time based on the WASM bytecode instructions to construct the trusted data space; wherein, the monitoring hook is used to intercept calling behaviors prohibited by the WASM bytecode instructions; The anonymized data is synchronized to the cloud service platform to generate an ODRL policy, specifically including: Establish a secure communication channel between the local connector and the cloud service platform, and use a two-way authentication mechanism to verify identity; The de-identified data is processed by block encryption to obtain an encrypted data packet, and the encrypted data packet is uploaded to the cloud directory service module; The encrypted data packet is parsed in the cloud directory service module to obtain the parsed metadata information, and the data integrity and source authenticity of the parsed metadata information are verified. Based on the parsed metadata information, an ODRL policy containing data usage terms is generated; Based on preset conversion rules, the ODRL strategy is converted into WASM bytecode instructions, specifically including: The ODRL strategy is parsed, and the operation subject, action type, and resource object in the ODRL strategy are extracted to obtain the triplet relationship; The triple relationship is matched with a preset conversion rule to generate a WASM bytecode instruction corresponding to the triple relationship; wherein the preset conversion rule is obtained from an industry compliance rule knowledge base and a national data infrastructure API. Based on the data sensitivity classification results, a data calculation strategy corresponding to the data sensitivity is selected to calculate the data to be processed, specifically including: If the data sensitivity is low, the query rewrite module is invoked to directly query the low-sensitivity data and desensitize the query results; If the data sensitivity is medium sensitive, a trusted execution environment is scheduled, and secure computation is performed in an encrypted environment; If the data sensitivity is high, federated machine learning is initiated, and the computation is completed in the local connector, sharing only the computation process.

2. The trusted data space construction method based on Eclipse EDC according to claim 1, characterized in that, A monitoring hook is injected into the local connector, and the calling behavior of the local connector is monitored in real time based on the WASM bytecode instructions to construct the trusted data space, specifically including: The behavioral constraints in the WASM bytecode instructions are parsed to generate operating system-level monitoring rules corresponding to the WASM bytecode instructions; Deploy monitoring hooks at the operating system kernel layer of the local connector and establish a mapping relationship between the monitoring hooks and the monitoring rules; When a call behavior that violates the monitoring rules is detected, a security interruption mechanism is triggered to terminate the call behavior and generate an encrypted violation evidence data packet to construct the trusted data space.

3. The trusted data space construction method based on Eclipse EDC according to claim 1, characterized in that, Deploy a local connector and a cloud service platform, and scan the data source through the local connector to obtain the data to be processed, specifically including: Load the connection parameters of the data source and establish a connection channel between the local connector and the data source to deploy the local connector; wherein, the data source includes an internal database, a file system and / or an API service; Based on a preset scanning strategy, the data source is scanned, and structured metadata is extracted from the data source to obtain the data to be processed.

4. The trusted data space construction method based on Eclipse EDC according to claim 1, characterized in that, Based on regular expressions, the data to be processed is de-identified to obtain de-identified data, specifically including: Based on the sensitivity classification results, the regular expression rules corresponding to the sensitive fields are invoked, and the sensitive fields are masked and / or replaced for desensitization. Accept user-defined desensitization rules and perform supplementary desensitization processing on the sensitive fields not covered by the regular expression rules to obtain desensitized data.

5. The trusted data space construction method based on Eclipse EDC according to claim 1, characterized in that, After constructing the trusted data space, the method further includes: Responding to the lifecycle constraints in the WASM bytecode instructions and triggering the expiration and destruction mechanism; Synchronously update the status flags of the cloud directory service module and remove the corresponding data indexes; Generate a destruction proof file containing the operation hash value, and audit and preserve the destruction proof file.

6. A trusted data space construction device based on Eclipse EDC, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform a method as described in any one of claims 1-5.

7. A non-volatile computer storage medium constructed based on the trusted data space of Eclipse EDC, storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement a method as described in any one of claims 1-5.

Images