Secure data exchange method and system for closed system

Abstract

The invention provides a secure data exchange method and system for a closed system. The method comprises the following steps: acquiring a data request of a special data exchange client, performing security verification, if the security verification is passed, performing access permission level comparison, if the comparison is passed, executing data query operation to generate a to-be-exchanged data packet, splitting the to-be-exchanged data packet, encrypting the split to-be-exchanged data packet, generating a server traceability check code, and sending the server traceability check code to the special data exchange client; and the client generates a client traceability check code based on the received encrypted data block and the associated information, compares the client traceability check code with the server traceability check code, and decrypts to obtain plaintext data after the comparison is passed. According to the method, temporary permission fine management and abnormal behavior active monitoring can be provided at the same time, conversion from static protection to dynamic risk assessment and from fixed permission to intelligent permission regulation and control is achieved, the defects of a traditional scheme in the aspects of behavior recognition, permission control, data integrity guarantee and full-link monitoring are effectively overcome, and the method is suitable for popularization and application. And the security of data exchange of the closed system is improved.

Description

Technical Field

[0001] This application relates to the field of data security technology, and more specifically, to a method and system for secure data exchange in a closed system. Background Technology

[0002] Closed systems (such as internal systems in finance, healthcare, and government) typically store large amounts of sensitive data, and their secure exchange is directly related to personal privacy, corporate trade secrets, and even national information security. However, traditional data exchange solutions have several technical shortcomings: First, they rely on static verification mechanisms, mainly based on fixed identity authentication and permission checks, lacking continuous monitoring and risk assessment of user behavior. Once identity credentials are stolen, the system struggles to effectively identify anomalies, exacerbating the risk of data leakage. Second, access control is rudimentary, using preset static permission levels that cannot dynamically adjust permissions based on real-time security conditions and user behavior. This can lead to risks from excessive permissions or business inefficiency from insufficient permissions. Third, they lack end-to-end monitoring capabilities. Traditional solutions often focus on single-stage protection (such as identity verification or data transmission), failing to cover the entire chain from request initiation and permission verification to data generation and reception, making it difficult to identify cross-stage coordinated attacks. Fourth, emergency response mechanisms are inadequate, often falling into a dilemma of "complete denial" or "over-authorization" in emergency business scenarios, lacking a refined temporary permission management mechanism that balances security and efficiency. These shortcomings collectively result in existing systems being insufficiently protected against advanced cyber threats, leading to a high risk of data breaches. Summary of the Invention

[0003] The purpose of this application is to provide a method and system for secure data exchange in a closed system, achieving multi-layered and dynamic intelligent security protection for the closed system. Firstly, by verifying identity legitimacy and digital signatures, and integrating behavioral feature analysis and environmental security scoring, an upgrade from static verification to dynamic risk assessment is achieved. Secondly, behavioral and environmental risks are quantified into permission scores, dynamically determining access permission levels and intelligently comparing them with data sensitivity to achieve refined permission management. During the data exchange process, end-to-end data integrity and confidentiality are ensured through data splitting encryption, generating bidirectional traceability verification codes, and key fragmentation transmission. Simultaneously, a temporary permission mechanism based on templates and quantitative constraints is introduced to strictly control risks while ensuring urgent business operations. Finally, real-time monitoring and anomaly blocking of client outbound behavior form a proactive defense. This application can comprehensively achieve risk perception, controllable permissions, and traceable behavior throughout the entire data exchange process, effectively improving the data exchange security level of closed systems.

[0004] This application also provides a method for secure data exchange in a closed system, including the following steps:

[0005] Obtain data requests from dedicated data exchange clients and perform security verification;

[0006] If the security verification passes, the access permission level is compared. If the comparison passes, a data query operation is performed to generate the data packet to be exchanged and the original data encryption key.

[0007] The data packets to be exchanged are split, encrypted, and a server-side traceability verification code is generated.

[0008] The dedicated data exchange client generates a client-side traceability verification code based on the received encrypted data block and associated information, and compares it with the server-side traceability verification code. If the comparison is successful, the plaintext data is decrypted.

[0009] Optionally, in the closed system data secure exchange method described in this application, the step of obtaining the data request from the dedicated data exchange client and performing security verification includes:

[0010] Verify the legitimacy of the source identity of the data request and the validity of the digital signature;

[0011] If the verification passes, the behavioral characteristic data of the current data request is obtained, including request time, single request amount, request frequency, and operation sequence characteristic data.

[0012] The behavioral feature data is input into the pre-built user-business behavior baseline model for comparison to determine whether the current request deviates from the behavior baseline. If so, the verification code secondary verification process is triggered.

[0013] If not, obtain the environmental security score of the dedicated data exchange client, and determine whether the environmental security score is greater than the preset security threshold. If so, the verification is successful.

[0014] Optionally, in the closed system data secure exchange method described in this application, if the security verification passes, an access permission level comparison is performed; if the comparison passes, a data query operation is executed to generate the data packet to be exchanged and the original data encryption key, including:

[0015] Based on the comparison results of the user-business behavior baseline model, a baseline deviation score is generated.

[0016] The access score is calculated by weighting the environmental safety score and the baseline deviation score, and the access level is determined based on the access score.

[0017] Obtain the sensitivity level of the data to be queried, and compare the access permission level with the sensitivity level;

[0018] If the comparison passes, a data query operation is performed to generate the data packet to be exchanged, and the original data encryption key is generated.

[0019] Optionally, in the closed system data security exchange method described in this application, the step of encrypting the data packets to be exchanged after splitting them and generating a server-side traceability verification code includes:

[0020] The data packets to be exchanged are split into multiple data blocks, and each data block is encrypted separately using the original data encryption key to generate encrypted data blocks;

[0021] The hash value is calculated based on the ciphertext data of the encrypted data block, the dedicated data exchange client ID, and the timestamp to obtain the server-side traceability verification code corresponding to each data block;

[0022] Based on a preset secret sharing algorithm, the original data encryption key is split into a server key and a client key. The client key is then transmitted to a dedicated data exchange client, and a pickup notification is sent.

[0023] Optionally, in the closed system data security exchange method described in this application, the dedicated data exchange client generates a client traceability verification code based on the received encrypted data block and associated information, and compares it with the server traceability verification code. Upon successful comparison, the data is decrypted to obtain plaintext data, including:

[0024] After the client initiates a pickup connection request and the security verification is successful, it transmits the server-side traceability verification code, server-side key, timestamp, and all encrypted data blocks to the dedicated data exchange client.

[0025] The dedicated data exchange client calculates the hash value based on the ciphertext data of the encrypted data block, the client ID, and the timestamp to obtain the client traceability verification code corresponding to each data block;

[0026] The client-side traceability verification code is compared with the server-side traceability verification code. If the comparison is successful, the secret sharing algorithm is used to concatenate the server-side key and the client-side key and then decrypt all encrypted data blocks.

[0027] The decrypted data blocks are concatenated to generate plaintext data.

[0028] Optionally, the closed system data secure exchange method described in this application further includes:

[0029] Build a temporary permission template library that includes temporary permissions and corresponding scenario type identifiers;

[0030] Request temporary access, including scenario type identifier and associated emergency credentials;

[0031] The authenticity of the emergency credentials is verified. If the verification is successful, temporary permission data is generated from the preset temporary permission template library based on the scenario type identifier. This data includes specific business object data, allowed operation type data, validity period, allowed number of operations, and allowed operation data volume.

[0032] Optionally, the closed system data secure exchange method described in this application further includes:

[0033] Real-time monitoring of the usage status data of temporary permissions and related business event status data;

[0034] The usage status data includes the usage duration, idle duration, number of operations, and amount of data processed.

[0035] Determine whether the used duration is greater than or equal to the valid duration, whether the idle duration is greater than the preset idle duration threshold, whether the number of operations is greater than the allowed number of operations, and whether the amount of data operated is greater than the allowed amount of data operated.

[0036] Determine whether the status data of the associated business event matches the preset completion status data;

[0037] Determine if any of the above conditions are met. If so, automatically revoke temporary permissions and generate a full lifecycle audit report for temporary permissions.

[0038] Optionally, the closed system data secure exchange method described in this application further includes:

[0039] Real-time monitoring of the behavior data of dedicated data exchange clients, including target IP address, download outbound time interval, and percentage of outbound data volume;

[0040] Determine if the target IP address is in the predefined IP list; if not, execute blocking and alarm operations.

[0041] If so, determine whether the download outbound time interval is less than the preset time interval threshold; if so, execute blocking and alarm operations.

[0042] If not, determine whether the proportion of outbound data exceeds the preset abnormal proportion threshold;

[0043] If so, execute the blocking and alarm operations.

[0044] Secondly, this application provides a closed-system data security exchange system, comprising:

[0045] Front-end server system: Deployed at the boundary of a closed network, connecting to the public network via a VPN gateway;

[0046] Data exchange service module: runs on the front-end system and includes:

[0047] Request processing unit: Receives data requests from dedicated data exchange clients and performs security verification;

[0048] Data execution unit: Determines access permissions based on verification results, performs data queries and generates data packets to be exchanged after successful comparison;

[0049] Encryption Packaging Unit: This unit splits and encrypts data packets, generates traceability verification codes, and generates split encryption keys.

[0050] Notification Unit: Sends a pickup notification containing the client's key to the client;

[0051] Audit and verification module: Performs tiered audits based on data sensitivity and returns a release decision;

[0052] Dedicated data exchange client: Initiates encryption requests, verifies traceability codes and decrypts data, and receives pickup notifications and downloads data packets;

[0053] Temporary Permission Management Module: Used to handle the application, generation, monitoring, and revocation of temporary permissions;

[0054] Audit traceability module: Used to record and store complete logs, data copies and audit records of all data exchange transactions, and provides query and audit functions.

[0055] Optionally, in the closed system data security exchange system described in this application, the temporary access control module is used for:

[0056] Receive temporary permission requests and verify their authenticity. If the verification passes, generate temporary permission data by matching from the preset temporary permission template library based on the scenario type identifier.

[0057] The system monitors the usage status data of temporary permissions and related business event status data in real time, and determines whether the preset revoke conditions are met. If so, it automatically revokes the temporary permissions and synchronizes the revoke results to the audit and traceability module.

[0058] As described above, this application provides a method and system for secure data exchange in a closed system, achieving multi-layered and dynamic intelligent security protection for the closed system. First, by verifying identity legitimacy and digital signatures, and integrating behavioral feature analysis and environmental security scoring, it upgrades from static verification to dynamic risk assessment. Then, it quantifies behavioral and environmental risks into permission scores, dynamically determines access permission levels, and intelligently compares them with data sensitivity to achieve refined permission management. In the data exchange phase, it ensures end-to-end data integrity and confidentiality through split encryption, generation of bidirectional traceability verification codes, and key fragmentation transmission. Simultaneously, it introduces a temporary permission mechanism based on templates and quantitative constraints to strictly control risks while ensuring urgent business operations. Finally, it performs real-time monitoring and anomaly blocking of client outbound behavior, forming a proactive defense. This application can comprehensively achieve risk perception, permission controllability, and behavior traceability throughout the entire data exchange process, effectively improving the data exchange security level of closed systems.

[0059] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0060] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 A flowchart of a closed system data security exchange method provided in the embodiments of this application;

[0062] Figure 2 A flowchart illustrating the secure verification of data requests in a closed-system data security exchange method provided in this application embodiment;

[0063] Figure 3 A flowchart illustrating the process of encrypting and generating a server-side traceability verification code after splitting the data packets to be exchanged in the closed system data security exchange method provided in this application embodiment;

[0064] Figure 4 This is a system block diagram of a closed system data security exchange system provided in the embodiments of this application. Detailed Implementation

[0065] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0066] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0067] Please refer to Figure 1 , Figure 1 This is a flowchart of a closed-system data secure exchange method according to some embodiments of this application. This closed-system data secure exchange method is used in terminal devices, such as computers and mobile terminals. The closed-system data secure exchange method includes the following steps:

[0068] S11. Obtain the data request from the dedicated data exchange client and perform security verification;

[0069] S12. If the security verification passes, the access permission level is compared. If the comparison passes, the data query operation is performed to generate the data packet to be exchanged and the original data encryption key.

[0070] S13. After splitting the data packets to be exchanged, encrypt them and generate a server-side traceability verification code;

[0071] S14. The dedicated data exchange client generates a client traceability verification code based on the received encrypted data block and associated information, and compares it with the server traceability verification code. If the comparison is successful, the plaintext data is decrypted.

[0072] It should be noted that this application first upgrades from static verification to dynamic risk assessment by verifying identity legitimacy and digital signatures, and integrating behavioral feature analysis and environmental security scoring. Then, it quantifies behavioral and environmental risks into permission scores, dynamically determines access permission levels, and intelligently compares them with data sensitivity to achieve refined permission management. In the data exchange process, it ensures end-to-end data integrity and confidentiality through split encryption, generation of two-way traceability verification codes, and key fragmentation transmission. Simultaneously, it introduces a temporary permission mechanism based on templates and quantitative constraints to strictly control risks while ensuring urgent business operations. Finally, it performs real-time monitoring and anomaly blocking of client outbound behavior, forming a proactive defense. This application can comprehensively achieve risk perception, permission controllability, and behavior traceability throughout the entire data exchange process, effectively improving the data exchange security level of closed systems.

[0073] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating the secure verification of data requests in a closed system data security exchange method according to some embodiments of this application. According to embodiments of the present invention, obtaining data requests from dedicated data exchange clients and performing security verification includes:

[0074] S21. Verify the legitimacy of the source identity of the data request and the validity of the digital signature;

[0075] S22. If the verification passes, obtain the behavioral characteristic data of the current data request, including request time, single request amount, request frequency and operation sequence characteristic data;

[0076] S23. Input the behavioral feature data into the pre-built user-business behavior baseline model for comparison, and determine whether the current request deviates from the behavior baseline. If so, trigger the verification code secondary verification process.

[0077] S24. If not, obtain the environmental security score of the dedicated data exchange client, and determine whether the environmental security score is greater than the preset security threshold. If so, the verification is successful.

[0078] It should be noted that this application verifies the legitimacy of the source identity by verifying the client's digital certificate. Verifying the validity of the digital signature means obtaining the first hash value by decrypting the signature using the sender's public key, calculating the second hash value on the received request data, and determining the validity by comparing whether the first and second hash values ​​are consistent.

[0079] Based on historical data from a closed system, a user-business behavior baseline model is constructed (including the allowed time range for users to access specific business data, the threshold for the amount of data requested per request for specific business data, and the frequency threshold for users to access specific business data). The model includes: Time characteristics: comparing the current time of the data request with the "allowed time range" defined in the behavior baseline; Quantity characteristics: comparing the amount of data involved in the current data request with the "threshold for the amount of data requested per request" defined in the behavior baseline; Frequency characteristics: comparing the cumulative number of requests made by the current user to the same or similar business within a preset statistical time window with the "frequency threshold" defined in the behavior baseline; Operation sequence characteristics: whether the current request is abnormal in the user's continuous operation sequence. For example, if the user's usual operation sequence is "login to the system - query customer list - request detailed data of a customer," but the current user directly requests a large amount of core customer data after logging in, skipping intermediate steps, then the operation sequence characteristic deviates from the baseline. If the current request deviates from the behavior baseline, a verification code is sent to the user for secondary verification.

[0080] According to an embodiment of the present invention, if the security verification passes, an access permission level comparison is performed; if the comparison passes, a data query operation is executed to generate the data packet to be exchanged and the original data encryption key, including:

[0081] Based on the comparison results of the user-business behavior baseline model, a baseline deviation score is generated.

[0082] The access score is calculated by weighting the environmental safety score and the baseline deviation score, and the access level is determined based on the access score.

[0083] Obtain the sensitivity level of the data to be queried, and compare the access permission level with the sensitivity level;

[0084] If the comparison passes, a data query operation is performed to generate the data packet to be exchanged, and the original data encryption key is generated.

[0085] It should be noted that this application dynamically transforms static identity permissions into a "permission score" that integrates real-time behavioral trust and environmental security assessment, and uses this as the basis for access control, achieving a leap from simple identity verification to intelligent permission adjustment based on continuous risk assessment. Simultaneously, by comparing this dynamic permission level with the sensitivity of the data itself, the accurate execution of access control policies is ensured, effectively preventing the risk of leakage of highly sensitive data in low-trust scenarios. The baseline deviation score is calculated as follows: the original feature deviation of the current request in four dimensions—time, quantity, frequency, and operation sequence—is calculated respectively; then, the original feature deviation of each dimension is input into a preset scoring function (a piecewise function is used in this embodiment) to map it into a standardized feature deviation score. Subsequently, according to a preset weight allocation strategy, the feature deviation scores of the four dimensions are weighted and calculated to obtain a comprehensive baseline deviation score. The weight allocation strategy is dynamically set based on the security sensitivity of different businesses or the behavioral patterns of different user roles.

[0086] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating the process of encrypting and generating a server-side traceability verification code after splitting the data packets to be exchanged in a closed system data security exchange method according to some embodiments of this application. According to an embodiment of the present invention, the step of encrypting and generating a server-side traceability verification code after splitting the data packets to be exchanged includes:

[0087] S31. Divide the data packet to be exchanged into multiple data blocks, and encrypt each data block separately using the original data encryption key to generate encrypted data blocks.

[0088] S32. Calculate the hash value based on the ciphertext data of the encrypted data block, the dedicated data exchange client ID, and the timestamp to obtain the server-side traceability verification code corresponding to each data block;

[0089] S33. Based on the preset secret sharing algorithm, the original data encryption key is split into a server key and a client key, the client key is transmitted to a dedicated data exchange client and a pickup notification is sent.

[0090] It should be noted that this application splits data packets into data blocks, encrypts each data block separately, and generates a unique "traceability verification code" to enhance the security of data transmission. Simultaneously, the key is split into "server-side key fragment + client-side key fragment," and collaborative decryption is required under a secure connection. This achieves the goals of preventing single-point leakage (even if the server is compromised or the client is compromised, the attacker only obtains half of the key and cannot decrypt the data) and preventing static data leakage (even if data packets are intercepted during transmission or storage, the data remains secure due to the lack of the other half of the key).

[0091] According to an embodiment of the present invention, the dedicated data exchange client generates a client-side traceability verification code based on the received encrypted data block and associated information, and compares it with the server-side traceability verification code. Upon successful comparison, the data is decrypted to obtain plaintext data, including:

[0092] After the client initiates a pickup connection request and the security verification is successful, it transmits the server-side traceability verification code, server-side key, timestamp, and all encrypted data blocks to the dedicated data exchange client.

[0093] The dedicated data exchange client calculates the hash value based on the ciphertext data of the encrypted data block, the client ID, and the timestamp to obtain the client traceability verification code corresponding to each data block;

[0094] The client-side traceability verification code is compared with the server-side traceability verification code. If the comparison is successful, the secret sharing algorithm is used to concatenate the server-side key and the client-side key and then decrypt all encrypted data blocks.

[0095] The decrypted data blocks are concatenated to generate plaintext data.

[0096] It should be noted that after receiving all data blocks, the client recalculates and automatically verifies the traceability check codes of all data blocks to ensure that the data has not been tampered with, and at the same time verifies the integrity and authenticity of the data source.

[0097] According to an embodiment of the present invention, it further includes:

[0098] Build a temporary permission template library that includes temporary permissions and corresponding scenario type identifiers;

[0099] Request temporary access, including scenario type identifier and associated emergency credentials;

[0100] The authenticity of the emergency credentials is verified. If the verification is successful, temporary permission data is generated from the preset temporary permission template library based on the scenario type identifier. This data includes specific business object data, allowed operation type data, validity period, allowed number of operations, and allowed operation data volume.

[0101] It should be noted that the authenticity of the emergency credential is verified. This verification includes checking the validity of the digital signature, whether the issuing authority is on a predefined list of trusted organizations, the validity period of the credential, the device identifier requesting temporary permissions, and sending a verification code to the device. If the verification passes, temporary permission data is generated from a pre-defined temporary permission template library based on the scenario type identifier. Specific business objects include database tables, API interfaces, file directories, or specific data record IDs, and allowed operation types include readable, writable, modifiable, deletable, and downloadable data.

[0102] According to an embodiment of the present invention, it further includes:

[0103] Real-time monitoring of the usage status data of temporary permissions and related business event status data;

[0104] The usage status data includes the usage duration, idle duration, number of operations, and amount of data processed.

[0105] Determine whether the used duration is greater than or equal to the valid duration, whether the idle duration is greater than the preset idle duration threshold, whether the number of operations is greater than the allowed number of operations, and whether the amount of data operated is greater than the allowed amount of data operated.

[0106] Determine whether the status data of the associated business event matches the preset completion status data;

[0107] Determine if any of the above conditions are met. If so, automatically revoke temporary permissions and generate a full lifecycle audit report for temporary permissions.

[0108] It should be noted that the preset completion status data includes completed, resolved, or closed, etc. The temporary permission full lifecycle audit report includes permission application time and permission applicant information, scenario type identifier and associated emergency credential information, permission scope (specific business object data, allowed operation type data, effective duration, number of operations and operation data volume), all usage records (operated business objects and operation types, usage duration, number of uses, and amount of data operated), permission revocation time and triggering revocation conditions (e.g., usage duration exceeds the limit, idle time exceeds the threshold, number of uses reaches the limit, amount of data operated exceeds the limit, or associated business event status data meets the completion status), residual information clearing operation performed after permission revocation and its result.

[0109] According to an embodiment of the present invention, it further includes:

[0110] Real-time monitoring of the behavior data of dedicated data exchange clients, including target IP address, download outbound time interval, and percentage of outbound data volume;

[0111] Determine if the target IP address is in the predefined IP list; if not, execute blocking and alarm operations.

[0112] If so, determine whether the download outbound time interval is less than the preset time interval threshold; if so, execute blocking and alarm operations.

[0113] If not, determine whether the proportion of outbound data exceeds the preset abnormal proportion threshold;

[0114] If so, execute the blocking and alarm operations.

[0115] It should be noted that this application constructs a three-tiered progressive judgment logic of "trustworthy target - compliant behavior - reasonable volume" to accurately identify and block in real time automated data theft behavior disguised as normal requests initiated after a known malicious connection to an internal trusted node has been compromised. Specifically, the target IP address is the address transmitted outward by the dedicated data exchange client; determining the outbound download time interval aims to capture the automated attack characteristic of "immediate transfer after success"; and determining the outbound data volume ratio (the ratio of outgoing data to downloaded data) aims to identify behaviors where users may attempt to transfer most or all of the recently acquired data.

[0116] According to an embodiment of the present invention, it further includes:

[0117] Collect download log information of encrypted data blocks, including: client ID, download time and user operation record data;

[0118] The encrypted data block's ciphertext data, download log information, and server-side traceability verification code are associated to form a traceability data packet;

[0119] Write the traceability data packet into a private chain node within the closed system.

[0120] It should be noted that the user operation record data includes the operation type, operation duration, and a list of data block IDs. If a data leak occurs later, it can be traced back to "which client, which time, and which user" downloaded it, thus achieving "leakage can be located and responsibility can be traced".

[0121] Please refer to Figure 4 , Figure 4 This is a system block diagram of a closed-system data security exchange system according to some embodiments of this application. The present invention also discloses a closed-system data security exchange system, comprising:

[0122] Front-end server system: Deployed at the boundary of a closed network, connecting to the public network via a VPN gateway;

[0123] Data exchange service module: runs on the front-end system and includes:

[0124] Request processing unit: Receives data requests from dedicated data exchange clients and performs security verification;

[0125] Data execution unit: Determines access permissions based on verification results, performs data queries and generates data packets to be exchanged after successful comparison;

[0126] Encryption Packaging Unit: This unit splits and encrypts data packets, generates traceability verification codes, and generates split encryption keys.

[0127] Notification Unit: Sends a pickup notification containing the client's key to the client;

[0128] Audit and verification module: Performs tiered audits based on data sensitivity and returns a release decision;

[0129] Dedicated data exchange client: Initiates encryption requests, verifies traceability codes and decrypts data, and receives pickup notifications and downloads data packets;

[0130] Temporary Permission Management Module: Used to handle the application, generation, monitoring, and revocation of temporary permissions;

[0131] Audit traceability module: Used to record and store complete logs, data copies and audit records of all data exchange transactions, and provides query and audit functions.

[0132] It should be noted that this system achieves secure data interaction between the closed network and the public network through a layered deployment logic of "boundary isolation - core exchange - internal control". The front-end system, acting as a critical isolation hub, only allows directed connections to the VPN gateway, preventing direct access from the public network to the closed network. The various units of the data exchange service module form a closed-loop collaboration. The security verification result of the request processing unit directly determines whether the data execution unit initiates access to the internal data source. The traceability verification code and splitting key generated by the encryption and packaging unit are used for data integrity verification and client decryption authorization, respectively. The hierarchical review process of the audit and verification module can be flexibly configured according to actual business scenarios, ensuring that data exchange is both secure and compliant while maintaining efficiency. The data execution unit is deployed simultaneously at the closed network boundary and within the closed internal network. Units at the boundary handle lightweight, non-core data exchange (such as low-sensitivity configuration information), without needing to delve into the internal data source; they can complete the "query-return" process at the boundary layer. Internal units handle access to core data sources, requiring direct connection to the internal database to ensure the "business rationality" of data access. The audit and verification module is deployed in layers at the closed network boundary and within the closed internal network, building a dual audit defense line that is "from the outside in and from shallow to deep". The boundary module focuses on "basic security filtering at the technical level", quickly intercepting unencrypted, abnormally formatted, or malicious data to prevent external risks from penetrating to the core area, while reducing the ineffective load of internal audits. The internal module focuses on "deep compliance control at the business level", conducting hierarchical audits based on data sensitivity and verifying the rationality of data use in relation to specific business scenarios, ensuring compliance with internal standards and external regulations. The two work together to form a closed loop of "technical risk prevention + business compliance control", which not only solves the limitations of a single audit point, but also achieves full-link control of data exchange from security to compliance.

[0133] According to an embodiment of the present invention, the temporary permission management module is used for:

[0134] Receive temporary permission requests and verify their authenticity. If the verification passes, generate temporary permission data by matching from the preset temporary permission template library based on the scenario type identifier.

[0135] The system monitors the usage status data of temporary permissions and related business event status data in real time, and determines whether the preset revoke conditions are met. If so, it automatically revokes the temporary permissions and synchronizes the revoke results to the audit and traceability module.

[0136] It should be noted that the temporary permission management module is used to address the issues of "excessive granting of permissions" and "long-term retention risks" in emergency scenarios. The generated temporary permission data strictly follows the "minimum necessity principle," containing only business objects and operation scopes that match the emergency scenario, and the validity period of the permissions is bound to the reasonable duration of the emergency scenario. In the permission revocation process, in addition to monitoring overdue situations, the status of business events will also be synchronized. Once any revocation condition is met, permission cancellation will be triggered immediately and the temporary key cached on the client will be cleared. At the same time, the revocation record (including the triggering reason, operation time, etc.) will be synchronized to the audit and traceability module in real time, forming a complete permission lifecycle traceability chain.

[0137] This invention discloses a method and system for secure data exchange in a closed system, achieving multi-layered and dynamic intelligent security protection for the closed system. First, by verifying identity legitimacy and digital signatures, and integrating behavioral feature analysis and environmental security scoring, it upgrades from static verification to dynamic risk assessment. Then, it quantifies behavioral and environmental risks into permission scores, dynamically determines access permission levels, and intelligently compares them with data sensitivity to achieve refined permission management. In the data exchange process, it ensures end-to-end data integrity and confidentiality through split encryption, generation of bidirectional traceability verification codes, and key fragmentation transmission. Simultaneously, it introduces a temporary permission mechanism based on templates and quantitative constraints to strictly control risks while ensuring urgent business operations. Finally, it performs real-time monitoring and anomaly blocking of client outbound behavior, forming a proactive defense. This application can comprehensively achieve risk perception, permission controllability, and behavior traceability throughout the entire data exchange process, effectively improving the data exchange security level of closed systems.

[0138] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0139] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0140] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

Claims

1. A method for secure data exchange in a closed system, characterized in that, Includes the following steps: Obtain data requests from dedicated data exchange clients and perform security verification; If the security verification passes, the access permission level is compared. If the comparison passes, a data query operation is performed to generate the data packet to be exchanged and the original data encryption key. The data packets to be exchanged are split, encrypted, and a server-side traceability verification code is generated. The dedicated data exchange client generates a client-side traceability verification code based on the received encrypted data block and associated information, and compares it with the server-side traceability verification code. If the comparison is successful, the plaintext data is decrypted.

2. The closed system data secure exchange method according to claim 1, characterized in that, The process of obtaining data requests from a dedicated data exchange client and performing security verification includes: Verify the legitimacy of the source identity of the data request and the validity of the digital signature; If the verification passes, the behavioral characteristic data of the current data request is obtained, including request time, single request amount, request frequency, and operation sequence characteristic data. The behavioral feature data is input into the pre-built user-business behavior baseline model for comparison to determine whether the current request deviates from the behavior baseline. If so, the verification code secondary verification process is triggered. If not, obtain the environmental security score of the dedicated data exchange client, and determine whether the environmental security score is greater than the preset security threshold. If so, the verification is successful.

3. The closed system data secure exchange method according to claim 2, characterized in that, If the security verification passes, an access permission level comparison is performed. If the comparison passes, a data query operation is executed to generate the data packet to be exchanged and the original data encryption key, including: Based on the comparison results of the user-business behavior baseline model, a baseline deviation score is generated. The access score is calculated by weighting the environmental safety score and the baseline deviation score, and the access level is determined based on the access score. Obtain the sensitivity level of the data to be queried, and compare the access permission level with the sensitivity level; If the comparison passes, a data query operation is performed to generate the data packet to be exchanged, and the original data encryption key is generated.

4. The closed system data secure exchange method according to claim 1, characterized in that, The process of splitting and encrypting the data packets to be exchanged, and generating a server-side traceability verification code, includes: The data packets to be exchanged are split into multiple data blocks, and each data block is encrypted separately using the original data encryption key to generate encrypted data blocks; The hash value is calculated based on the ciphertext data of the encrypted data block, the dedicated data exchange client ID, and the timestamp to obtain the server-side traceability verification code corresponding to each data block; Based on a preset secret sharing algorithm, the original data encryption key is split into a server key and a client key. The client key is then transmitted to a dedicated data exchange client, and a pickup notification is sent.

5. The closed system data secure exchange method according to claim 4, characterized in that, The dedicated data exchange client generates a client-side traceability verification code based on the received encrypted data block and associated information, and compares it with the server-side traceability verification code. Upon successful comparison, the data is decrypted to obtain the plaintext data, including: After the client initiates a pickup connection request and the security verification is successful, it transmits the server-side traceability verification code, server-side key, timestamp, and all encrypted data blocks to the dedicated data exchange client. The dedicated data exchange client calculates the hash value based on the ciphertext data of the encrypted data block, the client ID, and the timestamp to obtain the client traceability verification code corresponding to each data block; The client-side traceability verification code is compared with the server-side traceability verification code. If the comparison is successful, the secret sharing algorithm is used to concatenate the server-side key and the client-side key and then decrypt all encrypted data blocks. The decrypted data blocks are concatenated to generate plaintext data.

6. The closed system data secure exchange method according to claim 1, characterized in that, Also includes: Build a temporary permission template library that includes temporary permissions and corresponding scenario type identifiers; Request temporary access, including scenario type identifier and associated emergency credentials; The authenticity of the emergency credentials is verified. If the verification is successful, temporary permission data is generated from the preset temporary permission template library based on the scenario type identifier. This data includes specific business object data, allowed operation type data, validity period, allowed number of operations, and allowed operation data volume.

7. The closed system data secure exchange method according to claim 6, characterized in that, Also includes: Real-time monitoring of the usage status data of temporary permissions and related business event status data; The usage status data includes the usage duration, idle duration, number of operations, and amount of data processed. Determine whether the used duration is greater than or equal to the valid duration, whether the idle duration is greater than the preset idle duration threshold, whether the number of operations is greater than the allowed number of operations, and whether the amount of data operated is greater than the allowed amount of data operated. Determine whether the status data of the associated business event matches the preset completion status data; Determine if any of the above conditions are met. If so, automatically revoke temporary permissions and generate a full lifecycle audit report for temporary permissions.

8. The closed system data secure exchange method according to claim 5, characterized in that, Also includes: Real-time monitoring of the behavior data of dedicated data exchange clients, including target IP address, download outbound time interval, and percentage of outbound data volume; Determine if the target IP address is in the predefined IP list; if not, execute blocking and alarm operations. If so, determine whether the download outbound time interval is less than the preset time interval threshold; if so, execute blocking and alarm operations. If not, determine whether the proportion of outbound data exceeds the preset abnormal proportion threshold; If so, execute the blocking and alarm operations.

9. A closed-system data security exchange system, characterized in that, include: Front-end server system: Deployed at the boundary of a closed network, connecting to the public network via a VPN gateway; Data exchange service module: runs on the front-end system and includes: Request processing unit: Receives data requests from dedicated data exchange clients and performs security verification; Data execution unit: Determines access permissions based on verification results, performs data queries and generates data packets to be exchanged after successful comparison; Encryption Packaging Unit: This unit splits and encrypts data packets, generates traceability verification codes, and generates split encryption keys. Notification Unit: Sends a pickup notification containing the client's key to the client; Audit and verification module: Performs tiered audits based on data sensitivity and returns a release decision; Dedicated data exchange client: Initiates encryption requests, verifies traceability codes and decrypts data, and receives pickup notifications and downloads data packets; Temporary Permission Management Module: Used to handle the application, generation, monitoring, and revocation of temporary permissions; Audit traceability module: Used to record and store complete logs, data copies and audit records of all data exchange transactions, and provides query and audit functions.

10. The closed-system data security exchange system according to claim 9, characterized in that, The temporary access management module is used for: Receive temporary permission requests and verify their authenticity. If the verification passes, generate temporary permission data by matching from the preset temporary permission template library based on the scenario type identifier. The system monitors the usage status data of temporary permissions and related business event status data in real time, and determines whether the preset revoke conditions are met. If so, it automatically revokes the temporary permissions and synchronizes the revoke results to the audit and traceability module.

Images