A data exchange method and device, electronic equipment and storage medium

Abstract

This invention discloses a data exchange method, apparatus, electronic device, and storage medium. The method determines the source domain type of a target user's first work order query request; if the source domain type of the first work order query request is a cloud terminal security domain, it verifies the status of the file transfer request work order corresponding to the first work order query request and the target user's identity. Upon successful verification, it opens an operable interface for the target user; in response to the target user's file upload instruction, it uploads the target file to a temporary storage area; if the source domain type of the file upload instruction is a cloud terminal security domain; in response to the target user's file download instruction, it performs a file download operation to obtain the target user's required data and transmits the required data to the target user's terminal to achieve cross-domain data exchange; if the source domain type of the file download instruction is a physical terminal non-security domain. This invention improves the security of cross-domain data transmission.

Description

Technical Field

[0001] This invention relates to the field of computer operation and maintenance technology, and in particular to a data exchange method, apparatus, electronic device and storage medium. Background Technology

[0002] In the field of enterprise information security management, physical or network isolation between cloud terminals (VDI, Virtual Desktop Infrastructure) and physical terminals is a common practice for protecting core data assets. Under this architecture, users complete their daily work in the VDI environment, with data always residing on the data center side. Physical terminals only receive image streams and do not directly access business data. However, in actual business operations, there is a need to compliantly transfer work outputs (such as analysis reports, operation and maintenance logs, configuration export files, etc.) from the VDI environment to physical terminals. For example, employees may need to review materials or submit deliverables to external partners in an offline environment.

[0003] Currently, cross-domain data transfer primarily relies on the following technical solutions: 1. Physical media mapping: Establishing a direct data transfer channel between the VDI session and the physical terminal through USB redirection or clipboard mapping. 2. General file sharing: Deploying FTP (File Transfer Protocol) or SMB (Server Message Block) file sharing servers, allowing users to upload files in the VDI environment and download them on the physical terminal. 3. Uncontrolled alternatives: When formal channels are restricted, employees resort to shadow IT methods such as personal cloud storage, instant messaging attachment transfer, or email forwarding for data transfer. Existing cross-domain data transfer technologies lack high data security. Summary of the Invention

[0004] This invention provides a data exchange method, apparatus, electronic device, and storage medium to improve the security of cross-domain data transmission.

[0005] According to one aspect of the present invention, a data exchange method is provided, the method comprising:

[0006] In response to a first work order query request from a target user, the source domain type of the first work order query request is determined; the first work order query request is initiated based on the work order identifier of a file transfer request work order, which is generated by the target user through the ITSM system;

[0007] If the source domain type of the first work order query request is cloud terminal security domain, the status of the file transfer application work order and the identity of the target user are verified. If the verification is successful, the operation interface that can be executed is opened to the target user.

[0008] In response to the file upload command from the target user, the target file is uploaded to the temporary storage area; the file upload command is initiated by the target user based on the operation interface of the executable operation, and the source domain type of the file upload command is the cloud terminal security domain;

[0009] In response to the target user's file download instruction, if the file download instruction passes verification, a file download operation is performed to obtain the target user's required data, and the required data is transmitted to the target user's terminal to achieve cross-domain data exchange; the source domain type of the file download instruction is a physical terminal non-secure domain.

[0010] According to another aspect of the present invention, a data exchange apparatus is provided, the apparatus comprising:

[0011] The domain type determination module is used to determine the source domain type of the first work order query request in response to the first work order query request of the target user; the first work order query request is initiated based on the work order identifier of the file transfer request work order, which is generated by the target user through the ITSM system;

[0012] The executable operation interface opening module is used to verify the status of the file transfer application work order and the identity of the target user when the source domain type of the first work order query request is a cloud terminal security domain. If the verification is successful, the executable operation interface is opened to the target user.

[0013] The file upload module is used to respond to the file upload command of the target user and upload the target file to the temporary storage area; the file upload command is initiated by the target user based on the operation interface of the executable operation, and the source domain type of the file upload command is the cloud terminal security domain;

[0014] The file download module is used to respond to the file download command of the target user. If the file download command passes the verification, it performs a file download operation to obtain the target user's required data and transmits the required data to the target user's terminal to realize cross-domain data exchange. The source domain type of the file download command is a physical terminal non-secure domain.

[0015] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the data exchange method described in any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the data exchange method described in any embodiment of the present invention.

[0020] The technical solution of this invention utilizes a secure data exchange gateway to respond to a target user's first work order query request and determine the source domain type of the first work order query request. The first work order query request is initiated based on the work order identifier of a file transfer request work order, which is generated by the target user through the ITSM system. If the source domain type of the first work order query request is a cloud terminal security domain, the status of the file transfer request work order and the identity of the target user are verified. If the verification is successful, an executable operation interface is opened for the target user. In response to the target user's file upload instruction, the target file is uploaded to a temporary storage area. The file upload instruction is initiated by the target user based on the executable operation interface, and the source domain type of the file upload instruction is a cloud terminal security domain. In response to the target user's file download instruction, if the file download instruction passes verification, a file download operation is performed to obtain the target user's required data, and the required data is transmitted to the target user's terminal to achieve cross-domain data exchange. The source domain type of the file download instruction is a physical terminal non-security domain. By binding data transmission behavior to work order status and identifying the request source domain, this solution addresses the problem of low data security in existing cross-domain data transmission technologies and improves the security of cross-domain data transmission.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1a A flowchart of a data exchange method provided in an embodiment of the present invention;

[0024] Figure 1b This embodiment provides a data exchange flowchart for a scenario where employees retrieve files across domains.

[0025] Figure 1c This embodiment provides a data exchange flowchart for an auditor's read-only audit scenario;

[0026] Figure 1d This embodiment provides a data exchange flowchart for an auditor's data access scenario;

[0027] Figure 2 This is a schematic diagram of the structure of a data exchange device provided in an embodiment of the present invention;

[0028] Figure 3 This is a schematic diagram of the structure of an electronic device that implements the data exchange method of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Figure 1aThis is a flowchart illustrating a data exchange method provided in an embodiment of the present invention. This embodiment is applicable to data exchange in cross-isolation domain scenarios. The method can be executed by a data exchange device, which can be implemented in hardware and / or software. The data exchange device can be configured in a server integrated with a data exchange system. The data exchange system may include a secure data exchange gateway, a temporary storage area, an archive area, and an ITSM system.

[0032] The secure data exchange gateway serves as an intermediary proxy service deployed between the secure domain of a cloud terminal and the non-secure domain of a physical terminal, acting as the sole entry point for all cross-domain file transfer operations. The secure data exchange gateway may include a cross-domain environment awareness module, a permission decision module, and a file access verification module.

[0033] The staging area can be deployed in the DMZ (Demilitarized Zone), which is a high-performance, short-term storage that can be accessed by both cloud terminal security domains and physical terminal non-security domains.

[0034] The archive area can be deployed within a high-security domain. Network layer ACL rules only allow access from cloud terminal security domains, security audit terminal domains, and write channels to the temporary storage area, while denying all requests from physical terminal non-security domains and the public network.

[0035] An ITSM system can be an enterprise IT service management platform that manages the entire lifecycle of workload orders, including application, approval, execution, and closure.

[0036] Data exchange systems can also include enterprise authentication services, such as SSO (Single Sign-On) authentication services, which provide unified user authentication capabilities. Users accessing the secure data exchange gateway from cloud terminal security domains, physical terminal non-security domains, or security audit terminal domains must complete identity verification through the authentication service.

[0037] like Figure 1a As shown, the data exchange method includes:

[0038] S110. In response to the first work order query request from the target user, determine the source domain type of the first work order query request; the first work order query request is initiated based on the work order identifier of the file transfer request work order, which is generated by the target user through the ITSM system.

[0039] The file transfer request work order in this embodiment can be generated in scenarios where employees retrieve (download / transfer) files across domains.

[0040] In this embodiment, the target user can submit a file transfer request ticket through the ITSM system. The initial status of this ticket can be set to "pending upload," indicating that it is waiting for the applicant to upload the target file. For example, the data structure of a file transfer request ticket can be as follows:

[0041] {

[0042] "ticket_id (ticket identifier)": "FT20260205001",

[0043] "ticket_type": "FILE_TRANSFER",

[0044] "applicant_id": "emp_10086",

[0045] "applicant_name": "Zhang San",

[0046] "approver_id (approver identifier)": "emp_20001",

[0047] "transfer_direction": "VDI_TO_PHYSICAL",

[0048] "file_purpose": "Submit the monthly operations and maintenance analysis report to the offline review environment",

[0049] "requested_download_expiry (requested download expiry time)": "24h",

[0050] "max_file_size_mb (maximum file size in MB)": 2048,

[0051] "status (work order status)": "Pending upload",

[0052] "created_at (work order creation time)": "2026-02-05T09:00:00Z",

[0053] "approved_at (work order approval time)": null,

[0054] "expired_at (work order expiration time)": null

[0055] }

[0056] Furthermore, the target user can access the web interface of the secure data exchange gateway through a browser within the cloud terminal security domain. On this web interface, the target user can enter the work order identifier (e.g., FT20260205001) of a file transfer work order to query the work order status from the ITSM system. The secure data exchange gateway can respond to this work order query request from the target user to determine the source domain type of the query request.

[0057] In one optional implementation, in response to a first work order query request from a target user, determining the source domain type of the first work order query request may include: extracting the source Internet Protocol (IP) address from the first work order query request and matching the source IP address with each address range in a pre-configured network domain mapping table to determine the source domain type of the first work order query request; or, extracting the source terminal identifier from the first work order query request and determining the source domain type of the first work order query request based on the source terminal identifier; or, extracting the request header identifier from the first work order query request and determining the source domain type of the first work order query request based on the request header identifier.

[0058] The pre-configured network domain mapping table may include the mapping relationship between IP address ranges and network domain types. In this embodiment, the pre-configured network domain mapping table may include a cloud terminal security domain mapping table, a physical terminal non-security domain mapping table, and a security audit terminal domain mapping table.

[0059] For example, the mapping table of cloud terminal security domains can be as follows:

[0060] {

[0061] "zone_id (domain identifier)": "ZONE_VDI",

[0062] "zone_type": "SECURE",

[0063] "cidr_ranges (address range)": ["10.100.0.0 / 16", "10.101.0.0 / 16"],

[0064] "allowed_operations": ["UPLOAD", "PREVIEW"],

[0065] "description": "Cloud Terminal Security Domain"

[0066] }

[0067] The mapping table for non-security domains of physical terminals can be as follows:

[0068] {

[0069] "zone_id": "ZONE_PHYSICAL",

[0070] "zone_type": "NON_SECURE",

[0071] "cidr_ranges": ["172.16.0.0 / 12", "192.168.0.0 / 16"],

[0072] "allowed_operations": ["DOWNLOAD"],

[0073] "description": "Physical terminal not in a secure domain"

[0074] }

[0075] The mapping table for security audit endpoint domains can be as follows:

[0076] {

[0077] "zone_id": "ZONE_AUDIT",

[0078] "zone_type": "SECURE_AUDIT",

[0079] "cidr_ranges": ["10.200.0.0 / 24"],

[0080] "allowed_operations": ["PREVIEW", "AUDIT_DOWNLOAD"],

[0081] Description: Security Audit Terminal Domain

[0082] }

[0083] In one scenario, this embodiment can extract the source IP address of the first work order query request and match it with address segments in a pre-configured network domain mapping table. If the source IP address falls within the address segment range of a certain network domain, it can be determined that the first work order query request originates from the corresponding network domain type, and the set of allowed operations under that domain type is taken as the executable permissions corresponding to the first work order query request. If the source IP address does not match any pre-configured address segment, it can be determined that the first work order query request originates from an unidentified network domain, and all operations of the first work order query request are rejected. For example, if the source IP address extracted by the secure data exchange gateway is `10.100.5.23`, and this IP address matches the `10.100.0.0 / 16` address segment in the network domain mapping table, it can be determined that it originates from the cloud terminal security domain, and the allowed set of operations is upload and preview.

[0084] In another scenario, this embodiment can distinguish between cloud terminals, physical terminals, and security audit terminals by collecting the hardware feature code (e.g., motherboard serial number, TPM chip ID) of the source terminal of the first work order query request.

[0085] In another scenario, this embodiment can inject a custom HTTP (Hypertext Transfer Protocol) header identifier (e.g., `X-Security-Zone: VDI`) into the traffic passing through the egress gateways of different domains. Then, the secure data exchange gateway can parse the request header from the first work order query request to complete the domain determination.

[0086] S120. If the source domain type of the first work order query request is cloud terminal security domain, verify the status of the file transfer application work order and the identity of the target user. If the verification is successful, open the operation interface for the target user to perform the operation.

[0087] In this embodiment, the secure data exchange gateway can query the ITSM system for the current status of file transfer request tickets via an API (Application Programming Interface). Specifically, if the request ticket does not exist, the gateway returns a "Request ticket does not exist" result; if the ticket status is not "pending upload," it returns a "Ticket status does not allow upload" result.

[0088] This embodiment can also perform identity authentication for the target user. Specifically, the secure data exchange gateway can notify the enterprise authentication service to verify whether the user identifier of the target user matches the work order applicant corresponding to the first work order query request. If they do not match, the result of "identity mismatch" is returned.

[0089] If the first work order query request returns a result indicating that the work order exists, the work order status is "pending upload," and the user's identity verification is consistent, the secure data exchange gateway can enable the file upload and file preview interface allowed by the cloud terminal security domain for the target user.

[0090] S130. In response to the target user's file upload command, upload the target file to the temporary storage area; the file upload command is initiated by the target user based on the executable operation interface, and the source domain type of the file upload command is the cloud terminal security domain.

[0091] In this embodiment, the target user can continue to select a target file to upload on the file upload interface based on the cloud terminal security domain. The secure data exchange gateway can respond to the file upload instruction by encrypting the target file, calculating its hash value, and then uploading it to the temporary storage area.

[0092] Optionally, after uploading the target file to the temporary storage area, the process may further include: performing file access verification on the target file; the file access verification includes file format verification and file size verification; if any verification fails, the target file in the temporary storage area is marked for cleanup; if the file access verification passes, a file metadata digest is generated for the target file, and the file metadata digest is sent back to the ITSM system to update the status of the file transfer request work order to pending approval, and trigger the operation of real-time monitoring of the approval status of the file transfer request work order.

[0093] In this embodiment, after the target file is uploaded to the temporary storage area, it still needs to undergo two levels of access verification (file format verification and file size verification).

[0094] The first layer is format verification: The data exchange system compares the MIME type (Multipurpose Internet Mail Extensions) of the target file with pre-configured allowed transmission types (such as `application / pdf`, `text / csv`, `application / zip`, `image / png`, `image / jpeg`, `application / vnd.ms-excel`, and `application / vnd.openxmlformats-officedocument.*`, etc., office document formats) and pre-configured prohibited transmission types (such as `application / x-executable`, `application / x-msdownload`, `application / x-sh`, `application / java-archive`, etc., executable file formats). If the target file type is in the prohibited type list or not in the allowed type list, the target file can be rejected and marked as "delete immediately" in the temporary storage area.

[0095] The second layer is file size verification: the actual number of bytes in the target file is compared with the maximum file size declared in the file transfer request form, and the target file is rejected if the limit is exceeded.

[0096] For example, if a user uploads a 5MB PDF file: the first verification confirms that `application / pdf` is among the allowed transfer types and not among the prohibited transfer types, then the first verification passes; the second verification confirms that 5MB does not exceed the 2048MB limit declared in the work order, then the second verification passes. In other words, the file access verification passes.

[0097] Furthermore, after the access verification of the target file passes in this embodiment, a file metadata digest can be generated for the target file using a secure data exchange gateway. This file metadata digest is then sent back to the ITSM system. Based on this file metadata digest, the ITSM system can automatically update the status of the file transfer work order from "pending upload" to "pending approval" and automatically transfer the work order to the applicant's superior (i.e., the approver's) to-do list. The approver can view the file metadata digest (filename, type, size, etc.) in the work order details, but the approver cannot view or download the original target file.

[0098] For example, the data structure for a file metadata digest can be as follows:

[0099] {

[0100] "file_id (File Identifier)": "f_a1b2c3d4e5",

[0101] "ticket_id (Work Order Identifier)": "FT20260205001",

[0102] "original_filename (Original File Name)": "运维月报_202601.pdf",

[0103] "mime_type (File Format)": "application / pdf",

[0104] "file_size_bytes (File Size)": 5242880,

[0105] "sha256_hash (File Hash Value)": "e3b0c44298fc1c149af...",

[0106] "upload_user_id (Uploader Identifier)": "emp_10086",

[0107] "upload_source_zone (Upload Source Zone)": "ZONE_VDI",

[0108] "upload_timestamp (Upload Timestamp)": "2026-02-05T09:10:00Z",

[0109] "admission_check_result (Admission Check Result)": "Passed",

[0110] "admission_check_details (Admission Check Details)": {

[0111] "format_whitelist (Format Whitelist Check)": "Passed",

[0112] "size_limit (Size Limit Check)": "Passed"

[0113] },

[0114] "staging_path (Staging Path)": " / staging / a1b2c3... / 运维月报_202601.pdf.enc",

[0115] "archive_path (Archive Path)": null,

[0116] "status (file status)": "Staged"

[0117] }

[0118] Furthermore, in this embodiment, after a file transfer request work order is in a "pending approval" state, the secure data exchange gateway can be controlled to continuously monitor the approval status of that work order. The specific monitoring method can be as follows:

[0119] After the approver clicks "Approve" or "Reject", the ITSM system pushes a work order status change event to the secure data exchange gateway through a pre-configured Webhook.

[0120] The secure data exchange gateway actively calls the ITSM work order status query interface every 60 seconds to obtain the current status of the work order, as a compensation mechanism when the Webhook is lost.

[0121] Subscribe to ITSM ticket status change events through a message broker (such as Kafka or RabbitMQ);

[0122] The CDC (Change Data Capture) mechanism can obtain work order status flow information by listening to change events in the ITSM database.

[0123] S140. In response to the target user's file download instruction, if the file download instruction passes verification, execute the file download operation to obtain the target user's required data, and transmit the required data to the target user's terminal to achieve cross-domain data exchange; the source domain type of the file download instruction is a physical terminal non-secure domain.

[0124] In one optional implementation, in response to a file download instruction from a target user, if the file download instruction passes verification, a file download operation is performed to obtain the target user's required data, and the required data is transmitted to the target user's terminal to achieve cross-domain data exchange. This may include: if the status of a file transfer request ticket is approved, generating a transfer permission token for the target user and updating the status of the file transfer request ticket to pending download; the transfer permission token includes a token validity period, which is calculated based on the ticket approval time and the download time limit in the ticket; in response to a file download instruction from the target user, performing multiple verifications on the file download instruction, and if the verification passes, reading the target file from the temporary storage area and transmitting the target file to the target user's physical terminal to achieve cross-domain data exchange; the source domain type of the file download instruction is a non-secure domain of the physical terminal.

[0125] In this embodiment, after the status of the file transfer request ticket is changed to "approved", a corresponding transfer permission token can be generated for the target user, and then the target user can use the transfer permission token to download the target file across domains.

[0126] Specifically, the secure data exchange gateway can obtain the file transfer work order details and approval time from the ITSM system. Starting from the approval time, it adds the request download time (e.g., 24 hours) in the work order details to obtain the endpoint, forming an absolute time window. This generates a transfer permission token, sets its initial state to "activated," and updates the file transfer request status to "pending download." This embodiment can also notify the applicant via email or in-system message to complete the download within the validity period. It should be noted that the security domain authorized by the transfer permission token can be fixed to the physical terminal's non-security domain, meaning that the transfer permission token can only be used in the physical terminal's non-security domain. Even if the token is held, a download operation cannot be triggered in the cloud terminal's security domain. The absolute time window in the transfer permission token uses an absolute timestamp fixation strategy; the secure data exchange gateway only needs to compare the current time to determine whether the transfer permission token is valid. For example, the following is a data structure for a transfer permission token provided in this embodiment:

[0127] {

[0128] "token_id": "tk_x9y8z7w6",

[0129] "ticket_id (ticket identifier)": "FT20260205001",

[0130] "file_id (file identifier)": "f_a1b2c3d4e5",

[0131] "authorized_user_id (authorizer identifier)": "emp_10086",

[0132] "authorized_zone": "ZONE_PHYSICAL",

[0133] "file_sha256 (file hash value)": "e3b0c44298fc1c149af...",

[0134] "valid_from (token effective time)": "2026-02-05T10:15:00Z",

[0135] "valid_until (token expiration time)": "2026-02-06T10:15:00Z",

[0136] "max_download_count (maximum number of downloads)": 1,

[0137] "current_download_count" (current download count): 0,

[0138] "mtls_client_cert_fingerprint (client certificate fingerprint)": null,

[0139] "status (token status)": "Active"

[0140] }

[0141] Furthermore, target users can initiate downloads from non-secure domains on physical terminals. Specifically, target users can access the secure data exchange gateway through a non-secure domain on their physical terminals, and enter the work order identifier of the file transfer request and the token identifier of the transfer permission token to initiate a download. After receiving the file download instruction, the secure data exchange gateway can perform multiple verifications to ensure the compliance of the download operation.

[0142] Specifically, multi-layered verification can include verification of the command source domain, verification of the validity of the transmission permission token, verification of the target user's identity, verification of the validity of the physical terminal certificate, and verification of the file transfer request status. The first layer is verification of the source domain of the file download command: confirming that the command originates from a non-secure domain of the physical terminal; if the source is a secure domain or an unidentified domain of the cloud terminal, the download command is rejected. The second layer is verification of the token validity: querying the transmission permission token to confirm that the token exists, its status is "active," the current time is between the token's effective and expiration times, and the current download count has not reached the maximum download limit; if any of these conditions are not met, the download command is rejected. The third layer is verification of user identity consistency: the secure data exchange gateway extracts the authenticated user identifier from the file download command's authentication information and compares it with the authorized user identifier recorded in the transmission permission token; the two must be completely identical, otherwise the file download command is rejected. The fourth layer is mTLS certificate verification: The secure data exchange gateway verifies the validity of the client certificate carried in the file download command and calculates the SHA-256 fingerprint of the client certificate's public key. If the token is being downloaded for the first time (the certificate fingerprint field is empty), the current certificate fingerprint is written to the token and locked. If the token already contains a recorded certificate fingerprint, the current certificate fingerprint is compared with the recorded value. If they do not match, the file download command is rejected to prevent the token from being reused on different terminals. The fifth layer is real-time verification of the file transfer request status: The secure data exchange gateway calls the ITSM interface in real time to query the current status of the associated file transfer request, confirming that the request is still in the "pending download" state. If the request is revoked or rejected after the token is generated, the file download command is rejected even if the token itself is still valid.

[0143] For example, Zhang San initiates a download command from a physical terminal (IP address `172.16.5.88`): The first verification confirms that the IP belongs to a non-security domain of the physical terminal, passing; the second verification confirms that the token status is "activated", the current time is within the validity period, and the download count is 0, passing; the third verification confirms that the current SSO login user ID `emp_10086` matches the token authorizer, passing; the fourth verification verifies that the client's mTLS certificate is valid and bound to a fingerprint, passing; the fifth verification checks the ITSM in real time to confirm that the work order status is still "pending download", passing.

[0144] Furthermore, if the above multiple verifications pass, the secure data exchange gateway can read the encrypted target file from the temporary storage area, decrypt it, and transmit it to the target user's physical terminal, thereby realizing cross-domain exchange of the target file.

[0145] Based on the above optional implementation methods, the data exchange method of this embodiment may further include updating the status of the transmission permission token to consumed and updating the status of the file transmission request work order to downloaded; reading a file copy of the target file from the temporary storage area, storing the file copy in the archive area according to a preset storage strategy, and updating the status of the file transmission request work order to archived; the preset storage strategy includes a locking strategy and a retention period; and marking the target file in the temporary storage area as to be delayed for deletion according to a preset delay period.

[0146] In this embodiment, after the file download is complete, the download count of the transfer permission token can be incremented to 1, and the token's status can be updated to "consumed," meaning the token cannot be used again. The status of the file transfer request ticket can also be updated to "downloaded."

[0147] After the file download is complete, the data exchange system in this embodiment can also perform file archiving for the target file. A copy of the target file is read from the temporary storage area and copied to the archive area via an internal write channel. The archive path is isolated by the work order identifier, and a locking policy (e.g., WORM locking policy) is enabled during writing. The retention period can be set to 180 days. After archiving is complete, the archive path and file status (archived) in the file metadata digest can also be updated. The work order status can also be advanced from "downloaded" to "archived" via API.

[0148] This embodiment can also mark the corresponding target files in the temporary storage area as delayed deletions according to a preset delay period (e.g., 24 hours).

[0149] Optionally, this embodiment can also record a complete file transfer log. The file transfer log can include full information such as event type, work order identifier, file identifier, file hash value, uploading user and its security domain and time, downloading user and its security domain and time, download terminal certificate fingerprint, archive path, and archive retention deadline. The scheduled cleanup task in the temporary storage area scans once per hour and performs physical deletion (overwrite and delete) on files that have been marked and have exceeded the 24-hour delay period. After deletion, a cleanup log can be recorded.

[0150] To enable those skilled in the art to better understand the data exchange methods in the above-described scenario of employees retrieving files across domains, Figure 1b This embodiment provides a data exchange flowchart for a scenario where employees retrieve files across domains.

[0151] The technical solution of this embodiment adopts the technical means of binding data transmission behavior with work order status and identifying the request source domain, which solves the problem of low data security in existing cross-domain data transmission technology and improves the security of cross-domain data transmission.

[0152] Optionally, the data exchange method in this embodiment may further include: generating an audit session token when the audit application work order is detected to be in an approved state; determining the source domain type of the second work order query request in response to the auditor's second work order query request; initiating the second work order query request based on the work order identifier of the audit application work order; verifying the audit session token, the auditor's identity, and the audit file specified in the audit application work order when the source domain type of the second work order query request is a security audit terminal domain; if the verification passes, reading the audit file from the archive area for file rendering, and transmitting the file rendering result to the auditor's client to realize file auditing; and clearing the rendering result to terminate the audit session when the audit session token expires.

[0153] The audit request work order in this embodiment can be generated in a read-only audit scenario (viewing only, not downloading). In this scenario, files in the archive area can be viewed online without retrieving them, ensuring that audit data is visible but not accessible. For example, the data structure of the audit request work order can be as follows:

[0154] {

[0155] "ticket_id": "AU20260205001",

[0156] "ticket_type": "AUDIT_VIEW_ONLY",

[0157] "applicant_id": "auditor_3001",

[0158] "applicant_name": "Li Si",

[0159] "approver_id": "audit_mgr_001",

[0160] "audit_reason": "Quarterly compliance review of file transfer records for January 2026",

[0161] "target_file_ids (audit file identifiers)": ["f_a1b2c3d4e5", "f_b2c3d4e5f6"],

[0162] "requested_view_duration (Request to view the expiration date)": "4h",

[0163] "status": "Pending approval",

[0164] "created_at": "2026-02-05T14:00:00Z"

[0165] }

[0166] It should be noted that the `target_file_ids` in this audit request ticket can be derived from the file metadata index synchronized between the ITSM system and the secure data exchange gateway. ITSM only displays a summary of the file metadata, and auditors can select the file entries to be audited based on the metadata. The ticket does not contain the original files.

[0167] Furthermore, in this embodiment, the audit application work order can be routed to the approver for approval. After the secure data exchange gateway detects that the status of the audit application work order has changed to "approved", it can generate an audit session token for the auditor. This token can be bound to the work order identifier of the audit application work order, the auditor's user identifier, the authorized security domain (which can be fixed to the secure audit terminal domain), the allowed operations (fixed to preview only, excluding downloading or copying to the temporary storage area), the audit file list, and the effective time window (starting from the approval time and adding the viewing duration requested in the audit application work order as the end). The token's initial state is set to "activated".

[0168] The auditor logs into the secure data exchange gateway from the security audit terminal domain and enters the work order identifier of the audit request work order to query the work order. In response to the second work order query request, if the source domain type is determined to be the security audit terminal domain, the secure data exchange gateway can further perform verification operations on the audit session token, the auditor's identity, and the audit file specified in the audit request work order.

[0169] If all verifications pass, the secure data exchange gateway can read audit files from the archive without copying any copies to the staging area. Audit files can be rendered on the gateway's server (e.g., rendering a PDF as an image stream or a CSV as an HTML table), and the rendered visual content can be transmitted to the auditor's browser. The rendering output can also enable the following security controls: disabling text selection in the browser, disabling right-click menu operations, and overlaying a dynamic watermark (containing the auditor's identifier and the current timestamp) on the preview screen to prevent the source from being untraceable after a screenshot.

[0170] When the audit session token expires, the gateway can automatically terminate the preview session, clear the server-side rendering cache, and record the audit session log.

[0171] To enable those skilled in the art to better understand data exchange methods in read-only audit scenarios, Figure 1c This embodiment provides a data exchange flowchart for an auditor's read-only audit scenario.

[0172] Optionally, the data exchange method in this embodiment further includes: when the audit download work order is detected to be in an approved state, reading file copies of each audit file from the archive area and storing the file copies of each audit file in a temporary storage area; generating an audit download token and updating the status of the audit download work order to pending download; responding to the auditor's audit file download request, performing multiple verifications on the audit file download request; the multiple verifications include request source domain verification, audit download token validity verification, auditor identity verification, security audit terminal certificate validity verification, and audit download work order status verification; if the multiple verifications pass, downloading the audit file from the temporary storage area for auditing; and marking the file copies of each audit file in the temporary storage area as pending deletion.

[0173] The audit download work order in this embodiment can be generated in scenarios where auditors need to access (download audit documents). This scenario is suitable for situations where auditors need to perform in-depth analysis of documents (e.g., use professional forensic tools for inspection) and cannot complete the audit judgment solely through online preview. The core difference from the auditor's read-only audit scenario is that: files in the archive area need to be temporarily copied to the temporary storage area for download, thus requiring a higher level of approval process.

[0174] First, auditors can initiate an audit download ticket in the ITSM system. An example of the data structure for this audit download ticket is as follows:

[0175] {

[0176] "ticket_id": "AD20260205001",

[0177] "ticket_type": "AUDIT_DOWNLOAD",

[0178] "applicant_id": "auditor_3001",

[0179] "approver_id": "audit_mgr_001",

[0180] "audit_reason": "Forensic analysis of suspected illegally transmitted files",

[0181] "target_file_ids": ["f_a1b2c3d4e5"],

[0182] "requested_download_expiry": "2h",

[0183] "status": "Pending approval",

[0184] "created_at": "2026-02-05T16:00:00Z"

[0185] }

[0186] When creating a work order, the ITSM system can query the metadata index of archived files through the read-only API of the secure data exchange gateway. Auditors then select the specific audit files to be retrieved based on the metadata directory tree in the work order form. The work order only contains a list of file identifiers, not the original files.

[0187] Furthermore, after the audit download work order is approved, the secure data exchange gateway can sequentially perform the following processing on each audit file in the audit download work order: read the file content from the archive area in read-only mode; copy the file to an independent directory isolated by the work order identifier of the audit download work order in the temporary storage area, and enable AES-256 encryption on the copied file; at the same time, mark its source as "archive area copy", the work order identifier of the original file transfer work order, the work order identifier of the current audit download work order, and the automatic deletion time (approval time + download time of work order application) in the metadata of the file in the temporary storage area.

[0188] After all audit files have been copied, the secure data exchange gateway can generate an audit download token. The token's data structure can be the same as the aforementioned transmission permission token, but the authorized security domain is the secure audit terminal domain, not the physical terminal's non-secure domain. This means auditors can only download audit copies from the secure audit terminal domain. The audit download work order's status will then be updated to "Pending Download".

[0189] When an auditor initiates an audit file download request from a security audit terminal, the gateway performs the same multi-factor verification as in the scenario where an employee retrieves (downloads / transfers) a file across domains (verification of the instruction's source domain, verification of the validity of the audit download token, verification of the auditor's identity, verification of the validity of the security audit terminal certificate, and verification of the audit download work order status).

[0190] If multiple verifications pass, the audit file is downloaded from the staging area for auditing, thereby immediately marking the audit copy in the staging area as pending deletion. The scheduled cleanup task will perform physical deletion within 2 hours after marking (the 2-hour delay here is shorter than the 24-hour delay in the scenario of employees retrieving files across domains, because the audit copy has a higher security sensitivity).

[0191] This embodiment can also record audit logs (complete access links), including audit download work order identifier, original transmission request work order identifier, audit file identifier, auditor identity and security domain, download terminal certificate fingerprint, download time, creation and deletion time of temporary storage copy, archive source file path, and other full information.

[0192] To enable those skilled in the art to better understand the data exchange methods in auditor access scenarios, Figure 1d This embodiment provides a data exchange flowchart for an auditor's access scenario.

[0193] Optionally, the data exchange method in this embodiment may further include: when the target work order is detected to be in an invalid state, querying the associated token, associated audit session, and associated file in the temporary storage area corresponding to the target work order; marking the associated token as invalid, terminating the associated audit session, and marking the associated file in the temporary storage area as to be deleted immediately.

[0194] In this embodiment, throughout the entire lifecycle of scenarios such as employees retrieving files across domains, auditors performing read-only audits, and audit access, when an ITSM work order (such as a file transfer request work order, an audit request work order, or an audit download work order) undergoes an abnormal status change (rejection, cancellation, etc.), the secure data exchange gateway can perform coordinated processing.

[0195] When the gateway detects that the work order status has changed to "rejected", "cancelled", or "abnormally terminated", it can perform the following four operations:

[0196] First, immediately invalidate all associated tokens. The gateway queries the token storage for all tokens associated with this work order (including transmission permission tokens, audit session tokens, audit download tokens, etc.) and updates their status to "revoked".

[0197] Second, terminate all associated audit sessions. The gateway queries the session storage for all audit sessions associated with the work order, updates their status to "terminated," and sends a session interruption notification to the corresponding auditor.

[0198] Third, mark the files associated with the temporary storage area as to be cleaned immediately. The gateway queries all files in the temporary storage area associated with the work order and marks them as to be deleted immediately (with a delay period of 0), which is different from the 24-hour (or 2-hour) delayed cleanup under the normal process.

[0199] Fourth, record abnormal termination audit logs. The log content includes the work order identifier, termination reason (rejection / cancellation / abnormal termination), list of revoked token identifiers, list of terminated audit session identifiers, list of cleaned temporary files path, and processing timestamp, etc.

[0200] This linkage mechanism ensures that changes to work order status can be transmitted to file transfer permissions, audit sessions, and temporary files within seconds, eliminating the risk of data leakage after work order cancellation.

[0201] Optionally, the data exchange method of this embodiment may further include: immediately physically deleting files marked for immediate deletion in the temporary storage area; physically deleting files marked for delayed deletion in the temporary storage area that have exceeded the delay period; and forcibly physically deleting files in the temporary storage area that have exceeded the storage period limit.

[0202] In this embodiment, the secure data exchange gateway can maintain the state transition of each file throughout its entire lifecycle, ensuring that the storage location and accessibility of the file are controlled at any given time.

[0203] The file lifecycle state machine performs a scheduled cleanup task in the staging area every hour, and determines whether all files in the staging area need to be cleaned up based on the following three rules:

[0204] Rule 1: Files marked for immediate deletion (due to abnormal termination of work order or failure of access verification) shall be physically deleted immediately.

[0205] Rule 2: Files marked for delayed deletion that have exceeded the delay period will be physically deleted.

[0206] Rule 3, the fallback rule, stipulates that files stored in the staging area for more than the storage period limit (e.g., 72 hours) will be physically deleted regardless of their current status to prevent any missed files from remaining in the staging area for an extended period.

[0207] All physical deletion operations can be performed by overwriting and then deleting, and an audit log should be recorded and cleaned up after deletion.

[0208] In this embodiment, the archive cleanup can be automatically executed by the storage service's locking policy: for example, after an object has been created for 180 days, the file lock is automatically released, the storage service performs physical deletion, and the deletion event is notified to the gateway via callback to record the audit log.

[0209] Figure 2 This is a schematic diagram of a data exchange device provided in an embodiment of the present invention. It is integrated into a data exchange system, which also includes a secure data exchange gateway, a temporary storage area, an archiving area, and an Information Technology Service Management (ITSM) system. Figure 2 As shown, the device includes: a domain type determination module 210, an executable operation interface opening module 220, a file upload module 230, and a file download module 240. Wherein:

[0210] Domain type determination module 210 is used to determine the source domain type of the first work order query request in response to the first work order query request from the target user using the secure data exchange gateway; the first work order query request is initiated based on the work order identifier of the file transfer request work order, which is generated by the target user through the ITSM system;

[0211] The executable operation interface opening module 220 is used to verify the status of the file transfer application work order and the identity of the target user when the source domain type of the first work order query request is a cloud terminal security domain. If the verification is successful, the executable operation interface is opened to the target user.

[0212] The file upload module 230 is used to respond to the file upload command of the target user and upload the target file to the temporary storage area; the file upload command is initiated by the target user based on the operation interface of the executable operation, and the source domain type of the file upload command is the cloud terminal security domain;

[0213] The file download module 240 is used to respond to the file download instruction of the target user, and if the file download instruction passes the verification, to perform a file download operation to obtain the target user's required data, and to transmit the required data to the target user's terminal to realize cross-domain data exchange; the source domain type of the file download instruction is a physical terminal non-secure domain.

[0214] The technical solution of this embodiment adopts the technical means of binding data transmission behavior with work order status and identifying the request source domain, which solves the problem of low data security in existing cross-domain data transmission technology and improves the security of cross-domain data transmission.

[0215] Optionally, the domain type determination module 210 can be used for:

[0216] Extract the source Internet Protocol (IP) address from the first work order query request, and match the source IP address with each address range in the pre-configured network domain mapping table to determine the source domain type of the first work order query request; or,

[0217] Extract the source terminal identifier from the first work order query request, and determine the source domain type of the first work order query request based on the source terminal identifier; or

[0218] Extract the request header identifier from the first work order query request, and determine the source domain type of the first work order query request based on the request header identifier.

[0219] Optionally, the data exchange device further includes a file access verification module, used for:

[0220] The target file is subjected to file access verification; the file access verification includes file format verification and file size verification;

[0221] If any check fails during the file access verification, the target file in the temporary storage area will be marked as cleaned.

[0222] If the file access verification passes, a file metadata digest is generated for the target file, and the file metadata digest is sent back to the ITSM system to update the status of the file transfer application to pending approval, and trigger the operation of real-time monitoring of the approval status of the file transfer application.

[0223] Optional, file download module 240, specifically can be used for:

[0224] If the file transfer request ticket is in the approved state, after generating a transfer permission token for the target user, the status of the file transfer request ticket is updated to pending download; the transfer permission token includes a token validity period, which is calculated based on the ticket approval time and the download time limit in the ticket.

[0225] In response to the file download command from the target user, the file download command is subjected to multiple verifications. If the verifications pass, the target file is read from the temporary storage area and transmitted to the target user's physical terminal, thereby realizing cross-domain data exchange. The multiple verifications include command source domain verification, transmission permission token validity verification, target user identity verification, physical terminal certificate validity verification, and file transmission request work order status verification. The source domain type of the file download command is a non-secure domain of the physical terminal.

[0226] Optionally, the data exchange device further includes a file archiving processing module, used for:

[0227] Update the status of the transmission permission token to consumed and update the status of the file transmission request ticket to downloaded;

[0228] A file copy of the target file is read from the temporary storage area, the file copy is stored in the archive area according to a preset storage strategy, and the status of the file transfer request work order is updated to archived; the preset storage strategy includes a locking strategy and a retention period.

[0229] The target file in the temporary storage area is marked as delayed for deletion according to a preset delay period.

[0230] Optionally, the data exchange device further includes an audit preview module, used for:

[0231] When an audit request work order is detected to be in an approved state, an audit session token is generated.

[0232] In response to the auditor's second work order query request, determine the source domain type of the second work order query request; the second work order query request is initiated based on the work order identifier of the audit application work order;

[0233] If the source domain type of the second work order query request is a security audit terminal domain, the audit session token, the auditor's identity, and the audit file specified in the audit application work order are verified.

[0234] If the verification passes, the audit file is read from the archive area for file rendering, and the file rendering result is transmitted to the auditor's client to achieve file auditing;

[0235] If the audit session token expires, clear the rendering result to terminate the audit session.

[0236] Optionally, the data exchange device further includes an audit file download module, used for:

[0237] If the audit download work order is detected to be in an approved state, read the file copy of each audit file from the archive area and store the file copy of each audit file in the temporary storage area;

[0238] Generate an audit download token and update the status of the audit download work order to "pending download";

[0239] In response to an auditor's request to download audit documents, the request is subject to multiple verifications. These multiple verifications include verification of the request source domain, verification of the validity of the audit download token, verification of the auditor's identity, verification of the validity of the security audit terminal certificate, and verification of the audit download work order status.

[0240] If the multiple verifications pass, the audit file is downloaded from the temporary storage area for auditing.

[0241] Mark the file copies of each audit file in the temporary storage area as pending deletion.

[0242] Optionally, the data exchange device further includes a work order linkage control module, used for:

[0243] If the target work order is detected to be in an invalid state, query the associated token, associated audit session, and associated file in the temporary storage area corresponding to the target work order;

[0244] The associated token is marked as invalid, the associated audit session is terminated, and the associated files in the temporary storage area are marked as to be deleted immediately.

[0245] Optionally, the data exchange device further includes a temporary storage file management module, used for:

[0246] Files marked for immediate deletion in the temporary storage area will be physically deleted immediately.

[0247] For files in the temporary storage area that are marked for delayed deletion and whose delay period has expired, perform physical deletion.

[0248] Forced physical deletion is performed on files in the temporary storage area that have exceeded the storage period limit.

[0249] The data exchange apparatus provided in the embodiments of the present invention can execute the data exchange method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0250] Figure 3 A schematic diagram of an electronic device 300 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers or various forms of mobile devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0251] like Figure 3 As shown, the electronic device 300 includes at least one processor 301 and a memory, such as a read-only memory (ROM) 302 or a random access memory (RAM) 303, communicatively connected to the at least one processor 301. The memory stores computer programs executable by the at least one processor. The processor 301 can perform various appropriate actions and processes based on the computer program stored in the ROM 302 or loaded into the RAM 303 from storage unit 308. The RAM 303 can also store various programs and data required for the operation of the electronic device 300. The processor 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0252] Multiple components in electronic device 300 are connected to I / O interface 305, including: input unit 306, such as keyboard, mouse, etc.; output unit 307, such as various types of displays, speakers, etc.; storage unit 308, such as disk, optical disk, etc.; and communication unit 309, such as network card, modem, wireless transceiver, etc. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0253] Processor 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 301 performs the various methods and processes described above, such as data exchange methods.

[0254] In some embodiments, the data exchange method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 308. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 300 via ROM 302 and / or communication unit 309. When the computer program is loaded into RAM 303 and executed by processor 301, one or more steps of the data exchange method described above may be performed. Alternatively, in other embodiments, processor 301 may be configured to perform the data exchange method by any other suitable means (e.g., by means of firmware).

[0255] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0256] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0257] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0258] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0259] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0260] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0261] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0262] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A data exchange method applied to a data exchange system, the data exchange system comprising a secure data exchange gateway, a temporary storage area, an archiving area, and an Information Technology Service Management (ITSM) system, characterized in that, include: The secure data exchange gateway is used to respond to the first work order query request from the target user and determine the source domain type of the first work order query request. The first work order query request is initiated based on the work order identifier of the file transfer request work order, which is generated by the target user through the ITSM system; If the source domain type of the first work order query request is cloud terminal security domain, the status of the file transfer application work order and the identity of the target user are verified. If the verification is successful, the operation interface that can be executed is opened to the target user. In response to the file upload command from the target user, the target file is uploaded to the temporary storage area; the file upload command is initiated by the target user based on the operation interface of the executable operation, and the source domain type of the file upload command is the cloud terminal security domain; In response to the target user's file download instruction, if the file download instruction passes verification, a file download operation is performed to obtain the target user's required data, and the required data is transmitted to the target user's terminal to achieve cross-domain data exchange; the source domain type of the file download instruction is a physical terminal non-secure domain.

2. The method according to claim 1, characterized in that, In response to a first work order query request from a target user, the source domain type of the first work order query request is determined, including: Extract the source Internet Protocol (IP) address from the first work order query request, and match the source IP address with each address range in the pre-configured network domain mapping table to determine the source domain type of the first work order query request; or, Extract the source terminal identifier from the first work order query request, and determine the source domain type of the first work order query request based on the source terminal identifier; or Extract the request header identifier from the first work order query request, and determine the source domain type of the first work order query request based on the request header identifier.

3. The method according to claim 1, characterized in that, After uploading the target file to the temporary storage area, the process also includes: The target file is subjected to file access verification; the file access verification includes file format verification and file size verification; If any check fails during the file access verification, the target file in the temporary storage area will be marked as cleaned. If the file access verification passes, a file metadata digest is generated for the target file, and the file metadata digest is sent back to the ITSM system to update the status of the file transfer application to pending approval, and trigger the operation of real-time monitoring of the approval status of the file transfer application.

4. The method according to claim 1, characterized in that, In response to the target user's file download instruction, if the file download instruction passes verification, a file download operation is performed to obtain the target user's required data, and the required data is transmitted to the target user's terminal to achieve cross-domain data exchange, including: If the file transfer request ticket is in the approved state, after generating a transfer permission token for the target user, the status of the file transfer request ticket is updated to pending download; the transfer permission token includes a token validity period, which is calculated based on the ticket approval time and the download time limit in the ticket. In response to the file download command from the target user, the file download command is subjected to multiple verifications. If the verifications pass, the target file is read from the temporary storage area and transmitted to the target user's physical terminal, thereby realizing cross-domain data exchange. The multiple verifications include command source domain verification, transmission permission token validity verification, target user identity verification, physical terminal certificate validity verification, and file transmission request work order status verification. The source domain type of the file download command is a non-secure domain of the physical terminal.

5. The method according to claim 4, characterized in that, Also includes: Update the status of the transmission permission token to consumed and update the status of the file transmission request ticket to downloaded; A file copy of the target file is read from the temporary storage area, the file copy is stored in the archive area according to a preset storage strategy, and the status of the file transfer request work order is updated to archived; the preset storage strategy includes a locking strategy and a retention period. The target file in the temporary storage area is marked as delayed for deletion according to a preset delay period.

6. The method according to claim 1, characterized in that, Also includes: When an audit request work order is detected to be in an approved state, an audit session token is generated. In response to the auditor's second work order query request, determine the source domain type of the second work order query request; The second work order query request is initiated based on the work order identifier of the audit application work order; If the source domain type of the second work order query request is a security audit terminal domain, the audit session token, the auditor's identity, and the audit file specified in the audit application work order are verified. If the verification passes, the audit file is read from the archive area for file rendering, and the file rendering result is transmitted to the auditor's client to achieve file auditing; If the audit session token expires, clear the rendering result to terminate the audit session.

7. The method according to claim 1, characterized in that, Also includes: If the audit download work order is detected to be in an approved state, read the file copy of each audit file from the archive area and store the file copy of each audit file in the temporary storage area; Generate an audit download token and update the status of the audit download work order to "pending download"; In response to an auditor's request to download audit documents, the request is subject to multiple verifications. These multiple verifications include verification of the request source domain, verification of the validity of the audit download token, verification of the auditor's identity, verification of the validity of the security audit terminal certificate, and verification of the audit download work order status. If the multiple verifications pass, the audit file is downloaded from the temporary storage area for auditing. Mark the file copies of each audit file in the temporary storage area as pending deletion.

8. The method according to any one of claims 1-7, characterized in that, Also includes: If the target work order is detected to be in an invalid state, query the associated token, associated audit session, and associated file in the temporary storage area corresponding to the target work order; The associated token is marked as invalid, the associated audit session is terminated, and the associated files in the temporary storage area are marked as to be deleted immediately.

9. The method according to claim 1, characterized in that, Also includes: Files marked for immediate deletion in the temporary storage area will be physically deleted immediately. For files in the temporary storage area that are marked for delayed deletion and whose delay period has expired, perform physical deletion. Forced physical deletion is performed on files in the temporary storage area that have exceeded the storage period limit.

10. A data exchange device integrated into a data exchange system, the data exchange system comprising a secure data exchange gateway, a temporary storage area, an archiving area, and an information technology service management (ITSM) system, characterized in that, include: The domain type determination module is used to determine the source domain type of the first work order query request in response to the first work order query request from the target user using the secure data exchange gateway. The first work order query request is initiated based on the work order identifier of the file transfer request work order, which is generated by the target user through the ITSM system; The executable operation interface opening module is used to verify the status of the file transfer application work order and the identity of the target user when the source domain type of the first work order query request is a cloud terminal security domain. If the verification is successful, the executable operation interface is opened to the target user. The file upload module is used to respond to the file upload command of the target user and upload the target file to the temporary storage area; the file upload command is initiated by the target user based on the operation interface of the executable operation, and the source domain type of the file upload command is the cloud terminal security domain; The file download module is used to respond to the file download command of the target user. If the file download command passes the verification, it performs a file download operation to obtain the target user's required data and transmits the required data to the target user's terminal to realize cross-domain data exchange. The source domain type of the file download command is a physical terminal non-secure domain.

11. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a data exchange method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute a data exchange method according to any one of claims 1-9.

Images