A file security ferry method and system

Abstract

The application discloses a file security ferry method, which comprises the following steps: S1, a ferry agent server is arranged in an isolated domain of an internal network, and a control server is arranged outside the isolated domain; S2, the control server stores a ferry task uploaded by a user; S3, the ferry agent server periodically sends an outbound request to the control server to obtain the corresponding ferry task from the control server; S4, when the to-be-executed ferry task indicates that a transmission file is obtained from the isolated domain, the process is switched to step S5; and S5, the ferry agent server sends the corresponding transmission file obtained from the isolated domain to the control server according to the ferry task. The application obtains the task through the outbound request in the isolated domain to perform the file transmission, thereby improving the security and controllability of file exchange in the network isolation environment.

Description

Technical Field

[0001] This invention relates to the field of data security, and in particular to a method and system for securely transferring files. Background Technology

[0002] In enterprises with data security and compliance requirements, internal networks are typically divided into several isolated domains, with physical or logical isolation implemented between them. For example, R&D networks are isolated from office networks to prevent uncontrolled outflow of sensitive data and block the inflow of external risks. However, there is an objective need for cross-isolated file transfer in business operations. Existing file transfer methods include: authorized personnel manually copying files between terminals in different isolated domains using removable storage media such as USB flash drives or external hard drives; deploying dedicated devices such as one-way network gateways or optical gateways between two isolated domains to achieve one-way data transfer through a one-way physical link; and deploying file transfer relay servers such as FTP servers and email servers at the network boundary, where the source domain uploads files to the relay server, and the target domain then downloads them from the relay server.

[0003] In the aforementioned solutions, copying mobile storage media relies on manual operation, which is inefficient and difficult to control. Using a one-way gateway only supports data transmission in a fixed direction, lacking flexibility. Solutions using relay servers typically require opening inbound ports on the network boundary firewall of the isolated domain to receive external connections. This exposes the internal systems of the isolated domain to the reach of the external network. If the opened ports have security vulnerabilities or the firewall policies are improperly configured, the isolated domain is at risk of being scanned and attacked from the outside. These problems render existing technologies inadequate in terms of isolated domain boundary security, file delivery reliability, and large file transfer efficiency. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention discloses a secure file transfer method applied to an internal network. A transfer proxy server is set up within an isolated domain of the internal network, and a management server is set up outside the isolated domain. The isolated domain rejects inbound requests initiated by the management server. The management server creates and saves corresponding transfer tasks based on user-uploaded transfer requests. The secure file transfer method includes: Step S1, the transfer proxy server periodically sends outbound requests to the management server to obtain the corresponding transfer task from the management server; Step S2, when the transfer task to be executed indicates obtaining a file for transfer from the isolated domain, proceed to Step S3; Step S3, the transfer proxy server obtains the corresponding file for transfer from the isolated domain according to the transfer task and sends it to the management server.

[0005] Preferably, the internal network is configured with multiple isolation domains, and each isolation domain is configured with a transfer agent server. The transfer task is created using the following steps: Step A1, the management server receives the transfer application uploaded by the user; the transfer application includes the file identifier of the file to be transferred and the corresponding isolation domain; Step A2, the management server matches the corresponding approval path based on the transfer application to create an approval process; Step A3, the management server sends the transfer application to the corresponding approver according to the approval process, and after the transfer application is approved, proceeds to Step A4; Step A4, the management server creates the corresponding transfer task based on the transfer application and saves it.

[0006] Preferably, in step S2, when the ferry task to be executed indicates uploading the corresponding transfer file to the isolation domain, the following steps are performed: the ferry proxy server downloads the transfer file uploaded by the user and associated with the ferry application from the management server based on the ferry task, saves the downloaded transfer file in the isolation domain according to the preset landing directory rules, and then exits.

[0007] Preferably, the management server allows multiple ferry tasks to be stored simultaneously, and constructs a task order for the ferry tasks according to a preset sorting rule; each ferry task includes a corresponding execution status; step S1 includes: step S11, the ferry proxy server constructs a message authentication code based on a preset encoding method and the current timestamp, and constructs the outbound request based on the message authentication code; step S12, the ferry proxy server periodically sends the outbound request to the management server; step S13, the management server receives the outbound request, and determines whether the outbound request is valid based on the message authentication code and the timestamp: if yes, proceed to step S14; if no, the management server refuses to send the ferry task to the ferry proxy server, and then exits until it receives the next outbound request; step S14, the management server returns the task order of the ferry tasks to the ferry proxy server; step S15, the ferry proxy server obtains a ferry task with an execution status of pending execution based on the task order.

[0008] Preferably, the ferry proxy server segments the transmission file obtained from the isolation domain into fragments and sends the fragments to the management server; each fragment has a corresponding transmission status; after receiving each fragment, the management server sets the transmission status of the received fragment to "completed" and saves the fragment and the corresponding transmission status; during the transmission of the fragments, when the ferry proxy server and the management server reconnect after a disconnection, the ferry proxy server queries the management server for the transmission status of the fragments and skips the fragments that have been completed to transmit other fragments.

[0009] Preferably, after executing step S3, the process proceeds to step S4 to deliver the transmitted file to the user; step S4 includes: step S41, where the management server matches the file content in the transmitted file with preset information rules, and determines the risk level of the transmitted file based on the matching result; step S42, where the management server manages the transmitted file according to the risk level; the risk level includes a first risk level, a second risk level, and a third risk level; when the transmitted file is at the first risk level, the management server determines that the transmitted file has not passed the security check, does not deliver the transmitted file to the user, and sends blocking information generated based on the matching result to the user; when the transmitted file is at the second risk level, the management server determines that the transmitted file has passed the security check, delivers the transmitted file to the user, and sends alarm information generated based on the matching result to the user; when the transmitted file is at the third risk level, the management server determines that the transmitted file has passed the security check, delivers the transmitted file to the user, and retains the corresponding delivery record in the management server.

[0010] Preferably, after the user receives the blocking information, the appeal process is executed using the following steps: Step B1, the management server receives the appeal request uploaded by the user; Step B2, the management server designates a corresponding handler and sends the appeal request to the handler for processing, and after the appeal request is processed, proceeds to Step B3; Step B3, the management server receives the processing result returned by the handler and operates according to the processing result: when the processing result indicates success, the management server determines that the transmitted file has passed the security check and delivers the transmitted file to the user; when the processing result indicates failure, the management server determines that the transmitted file has failed the security check, does not deliver the transmitted file to the user, and sends the corresponding ferry failure information to the user.

[0011] Preferably, the delivery method of the control server for the transmitted files includes any one of direct delivery, restricted delivery, and encrypted delivery. When using direct delivery, the control server provides the user with a download link for the transmitted files through a preset browser. When using restricted delivery, the control server generates a corresponding access credential based on a preset storage directory and sends the access credential to the user, allowing the user to access the storage directory containing the transmitted files and download them. The access credential includes at least the allowed access period, the maximum allowed number of downloads, the maximum allowed number of simultaneous download sessions, and the access directory name. When using encrypted delivery, the control server connects to an external server based on a preset key, transmits the transmitted files to the corresponding server, and notifies the user of the access address of the external server. The user then accesses the corresponding server and downloads the transmitted files according to the access address.

[0012] This invention discloses a secure file transfer system applied to an internal network, employing the secure file transfer method described above. The system includes: a transfer proxy server, located within an isolated domain of the internal network; and a management server, located outside the isolated domain, used to create and save corresponding transfer tasks based on user-uploaded transfer requests. The transfer proxy server includes: a task acquisition module, used to periodically send outbound requests to the management server to acquire the corresponding transfer task from the management server; and a file transfer module, connected to the task acquisition module, used to acquire the corresponding transfer file from the isolated domain and send it to the management server when the pending transfer task indicates that a file needs to be transferred from the isolated domain.

[0013] Preferably, the internal network is configured with multiple isolation domains, and each isolation domain is configured with a ferry proxy server; the management server includes: a receiving module for receiving ferry applications uploaded by users; an approval creation module connected to the receiving module for matching the corresponding approval path based on the ferry application to create an approval process; an approval sending module connected to the approval creation module for sending the ferry application to the corresponding approver according to the approval process; and a task creation module connected to the approval sending module for creating and saving the corresponding ferry task based on the ferry application after the ferry application is approved.

[0014] The present invention can achieve the following beneficial effects: by having the transfer agent server in the isolation domain actively send outbound requests to the management server outside the isolation domain to obtain transfer tasks, the risk of files being damaged or tampered with during transmission without being detected is reduced, and the security and delivery controllability of file exchange in the network isolation environment are improved. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the secure file transfer method of the present invention. Figure 2 This is a schematic diagram of the process for creating a ferry task in this invention; Figure 3 This is a schematic diagram of the process of receiving a ferry task in this invention; Figure 4 This is a schematic diagram of the process for performing security verification on transmitted files in this invention; Figure 5 This is a flowchart illustrating the appeal process in this invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0017] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0018] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0019] This invention discloses a secure file transfer method applied to an internal network. A transfer proxy server is set up within an isolated domain of the internal network, and a control server is set up outside the isolated domain. The isolated domain rejects inbound requests initiated by the control server. The control server creates and saves corresponding transfer tasks based on user-uploaded transfer requests. Figure 1 As shown, the file secure transfer method includes: Step S1, the transfer agent server periodically sends outbound requests to the management server to obtain the corresponding transfer task from the management server; Step S2, when the transfer task to be executed indicates that the file to be transferred is obtained from the isolation domain, the process proceeds to Step S3; Step S3, the transfer agent server obtains the corresponding file to be transferred from the isolation domain according to the transfer task and then sends it to the management server.

[0020] Specifically, an isolated domain refers to a high-security network area that is physically or logically isolated from other network areas, such as an enterprise's R&D network. A transfer proxy server is deployed within the isolated domain, while a management server is deployed outside the domain. The transfer proxy server, a program or device deployed within the isolated domain, is responsible for reading, packaging, and transmitting files within the domain. The management server, deployed outside the isolated domain, is responsible for managing transfer tasks, verifying file receipts, and delivering files to users.

[0021] Firewalls and other boundary protection devices are installed at the network boundary of the isolated domain. These boundary protection devices are configured to keep the inbound ports of the isolated domain closed to reject inbound requests initiated by the management server outside the isolated domain, while allowing outbound requests sent by the transfer proxy server inside the isolated domain.

[0022] Specifically, devices outside the isolation domain, such as the management server, attach a corresponding inbound request identifier when initiating requests to the isolation domain. Similarly, transit proxy servers inside the isolation domain attach a corresponding outbound request identifier when initiating outbound requests to the management server. The boundary protection device allows data carrying outbound request identifiers to pass through but rejects any data carrying inbound request identifiers. When the transit proxy server retrieves a file from the management server and returns it, it attaches an outbound request identifier to the corresponding file to allow its transfer into the isolation domain. This communication method eliminates the need for the isolation domain to open ports at its boundary for external access, thereby reducing the isolation domain's exposure to external scanning and attacks.

[0023] The management server internally stores transfer tasks. A transfer task is task data that instructs the transfer agent server to perform a file transfer operation. The transfer task includes information about the file to be transferred from the isolation domain, such as the file's storage path and file name within the isolation domain. Transfer tasks can be uploaded to the management server by users, or automatically created by the management server after approving a user's transfer request.

[0024] Furthermore, the ferry proxy server periodically sends outbound requests to the management server at preset time intervals to inquire whether there are any ferry tasks it needs to execute. This time interval can be configured according to actual needs, for example, it can be set to send once every 10 seconds. After receiving the outbound request, the management server checks whether there are any pending ferry tasks belonging to that ferry proxy server. When there are pending ferry tasks, the management server returns the ferry task to the ferry proxy server, and the ferry proxy server receives the corresponding ferry task from the management server. If there are no pending ferry tasks, the management server returns an empty response, and the ferry proxy server waits for the next period to send the request again.

[0025] After receiving a transfer task, the transfer proxy server processes it, including parsing the task content and determining the file to be transferred. Then, the transfer proxy server retrieves the corresponding file from storage within the isolation domain, divides the file into multiple fragments, and splits large files into smaller data blocks for sequential transfer. Each fragment is then sent to the management server via an outbound request for transmission control and error recovery in case of transmission problems. During the fragment reception process, the management server can verify each fragment; only fragments that pass verification are stored.

[0026] Upon receiving a transmitted file, the management server verifies it. Verification may include checking file integrity, such as verifying whether the file has been damaged or tampered with during transmission, or security checks on the file content, such as detecting whether the file contains sensitive information. Files that pass security verification are delivered to the user by the management server; files that fail verification are not delivered.

[0027] Furthermore, the management server can also record operation logs for the entire file transfer process, including task creation, file transfer, verification results, and delivery status, to facilitate subsequent auditing and traceability. Users can access the management server through a client, which can be a browser, to submit transfer requests, upload files, and download files.

[0028] In a preferred embodiment of the present invention, multiple isolation domains are configured in the internal network, and each isolation domain is configured with a transfer proxy server; such as Figure 2 As shown, the following steps are used to create a transfer task: Step A1, the management server receives the transfer application uploaded by the user; the transfer application includes the file identifier of the file to be transferred and the corresponding isolation domain; Step A2, the management server matches the corresponding approval path based on the transfer application to create an approval process; Step A3, the management server sends the transfer application to the corresponding approver according to the approval process, and after the transfer application is approved, proceeds to Step A4; Step A4, the management server creates the corresponding transfer task based on the transfer application and saves it.

[0029] Specifically, users upload a transfer request to the management server via a client. The transfer request includes the file to be transferred and the corresponding isolation domain. In scenarios where files are transferred from within to outside the isolation domain, the transfer request can include identifying information such as the storage path of the file within the isolation domain. The transfer proxy server then uses this path to locate and retrieve the file within the isolation domain. In scenarios where files are transferred from outside to within the isolation domain, users can upload the file to the management server along with the transfer request.

[0030] Furthermore, after receiving a shuttle application, the management server matches the corresponding approval path based on the information carried in the application to create an approval process. The approval path is pre-configured in the management server, which can match the corresponding approval path based on information such as the isolation domain, shuttle direction, and applicant's department in the application, thereby determining the approval process the application should undergo. The approval process consists of one or more approval nodes, each corresponding to an approver or an approval role group. When an approval node is configured as a role group, the node is considered approved if any approver in that role group completes the approval. The approver is the person responsible for approving the shuttle application; the user can specify the approver when submitting the application, or the management server can automatically determine the approver according to preset rules.

[0031] In one embodiment, the management server prioritizes matching department approval paths based on a combination of three conditions: isolation domain, applicant department, and transfer direction. If no matching department approval path is found, the server rolls back and uses the preset default approval process.

[0032] Furthermore, the management server sends the transfer application to the approver sequentially according to the approval nodes determined in the approval process. Upon receiving the application, the approver approves it, and the management server continuously monitors the progress of the approval process, awaiting the result. If the approval process involves multiple nodes, the management server sends the application level by level, proceeding to the next node only after the previous node has approved it. If any approval node rejects the application, the transfer application is rejected, and the management server notifies the user that the approval has failed and does not create a transfer task.

[0033] In one embodiment, approval can also be carried out in a third-party approval system. The management server listens for approval status change events in the third-party approval system through a long connection. When an approval is detected, a transfer task is automatically created without the need for manual secondary registration.

[0034] After a ferry application is approved, the management server creates and saves a corresponding ferry task based on the application. The ferry task includes information about the transferred files and the target user. Once created, the task is in a pending state, waiting for an outbound request from the ferry proxy server. This automatic task creation after approval avoids the need for manual re-registration and task initiation in the transmission system, improving efficiency and ensuring data consistency between approval information and the transmission task.

[0035] In a preferred embodiment of the present invention, in step S2, when the ferry task to be executed indicates that the corresponding transfer file is uploaded to the isolation domain, the following steps are performed: the ferry agent server downloads the transfer file uploaded by the user and associated with the ferry application from the management server based on the ferry task, saves the downloaded transfer file in the isolation domain according to the preset landing directory rules, and then exits.

[0036] Specifically, the ferry proxy server periodically sends outbound requests to the management server to retrieve ferry tasks. After retrieving the corresponding ferry task, it obtains the transfer file from the isolation domain and sends it in fragments to the management server. The management server then verifies the file and delivers it to the user before exiting.

[0037] When a pending transfer task indicates uploading a corresponding file to an isolated domain, the file needs to be transferred from outside the isolated domain to inside. The content of the transfer task is to upload the file to the isolated domain. The user first uploads the file to the management server. After approval, the management server sets the transfer task to pending execution. Once the transfer proxy server retrieves the task, it downloads the corresponding file from the management server based on the transfer task. The download is also completed through an outbound request initiated by the transfer proxy server; the isolated domain still does not need to open inbound ports. After the download is complete, the transfer proxy server saves the downloaded file within the isolated domain according to preset destination directory rules. Destination directory rules specify the storage path of the file within the isolated domain. These rules can dynamically populate the path using variables from the application information, such as generating a storage path based on the security domain name and the uploading user. They can also completely preserve the directory structure at the time of upload. The system exits after the file is saved.

[0038] In one embodiment, when a user uploads a file to the management server via a browser, the browser segments the file and uploads each segment sequentially. Large files can use smaller segment sizes; for example, a 2GB file might use 8MB segments, while other files might use 32MB segments. A checksum is calculated for each segment during upload, and browser-side resume functionality is supported. After the proxy server downloads the file and writes it to the isolation domain, it can calculate a digest for the downloaded file and compare it with the digest recorded during upload. Only if the digest matches is the transmission confirmed successful, thus achieving end-to-end integrity verification.

[0039] In a preferred embodiment of the present invention, the management server allows multiple ferry tasks to be stored simultaneously, and the task order of the ferry tasks is constructed according to a preset sorting rule; each ferry task includes a corresponding execution status; such as Figure 3As shown, step S1 includes: Step S11, the ferry proxy server constructs a message authentication code based on a preset encoding method and the current timestamp, and constructs an outbound request based on the message authentication code; Step S12, the ferry proxy server periodically sends outbound requests to the management server; Step S13, the management server receives the outbound request and determines whether the outbound request is valid based on the message authentication code and timestamp: if yes, proceed to step S14; if no, the management server refuses to send the ferry task to the ferry proxy server and then exits until it receives the next outbound request; Step S14, the management server returns the task order of the ferry task to the ferry proxy server; Step S15, the ferry proxy server obtains a ferry task with an execution status of pending execution based on the task order.

[0040] Specifically, the preset encoding method includes using a preset signature algorithm to construct a message authentication code from a preset proxy key, a preset request method, a preset request path, the current timestamp, and the corresponding request digest. The proxy key is a unique key obtained by each ferry proxy server when registering with the management server; different ferry proxy servers have different proxy keys. The request method refers to the HTTP (Hypertext Transfer Protocol) method used in this outbound request, such as GET or POST; the request path refers to the Uniform Resource Locator path accessed; the timestamp is the current time when the ferry proxy server generated the request; the request digest is the hash value calculated from the request body, taking a preset fixed value when the request body is empty. The message authentication code is authentication information calculated based on the proxy key after concatenating the above information, used by the management server to verify the legitimacy of the request.

[0041] In one embodiment, the signature algorithm uses HMAC-SHA256, and the message authentication code is calculated as HMAC-SHA256(proxy key, request method + newline character + request path + newline character + timestamp + newline character + request digest).

[0042] Furthermore, the ferry proxy server periodically sends outbound requests to the management server, each request carrying a message authentication code and a timestamp. Upon receiving an outbound request, the management server determines whether the following conditions are met simultaneously: the signature algorithm is valid (the management server can recognize and support the signature algorithm and use it to verify the message authentication code); the proxy key has not been revoked (the proxy key held by the ferry proxy server sending the request is valid; administrators can revoke the key when an anomaly is detected, and a revoked proxy server will be unable to obtain tasks); and the difference between the timestamp and the management server's current time does not exceed a preset tolerance threshold. This tolerance threshold is used to prevent replay attacks; for example, it is set to 300 seconds, meaning requests with a timestamp difference exceeding 300 seconds will be rejected. If any of the above conditions are not met, the management server refuses to send the ferry task to the ferry proxy server, the request ends, and the ferry proxy server waits for the next outbound request.

[0043] When all the above conditions are met, the management server returns the corresponding ferry task to the ferry agent server, which then obtains the current task list. The execution status of a ferry task includes pending, executing, and completed. The ferry agent server selects a ferry task with a pending execution status based on task order to receive. To prevent multiple ferry agents or multiple polling attempts from repeatedly receiving the same task, when a ferry agent server receives a task, the management server only changes its execution status to executing and returns a success message if the task is still pending; if the task has already been received by another ferry agent server, the reception fails, and the ferry agent server continues to receive the next pending task in the task order. A ferry agent server executes only one task at a time, receiving the next task only after the current task is completed, i.e., executing the tasks it receives serially. Once the file transfer is complete, the management server changes the execution status of the corresponding ferry task to completed.

[0044] Completed transfer tasks are stored on the management server for users to query the corresponding transferred files. The management server periodically cleans up completed transfer tasks that have been stored for a preset period, such as those that have been stored for more than a month.

[0045] In addition to pending, executing, and completed states, the execution status of ferry tasks can also include more granular states such as packaging, transmitting, blocked, canceled, rejected, and expired. The management server maintains a set of legal state transitions, allowing ferry tasks to change state only according to legal paths defined in this set; state transition requests not belonging to this set will be rejected. For tasks already in a final state such as completed, the management server ignores subsequently received state change requests. For example, if a failure report due to network latency arrives after the task has been completed, the management server will not incorrectly change the completed task to a failed state, thus ensuring state consistency in asynchronous scenarios.

[0046] In a preferred embodiment of the present invention, the ferry proxy server segments the transmission file obtained from the isolation domain into fragments and sends the fragments to the management server; each fragment has a corresponding transmission status; after each fragment is received, the management server sets the transmission status of the received fragment to "completed" and saves the fragment and the corresponding transmission status; during the transmission of fragments, when the ferry proxy server and the management server reconnect after a disconnection, the ferry proxy server queries the management server for the transmission status of the fragments, skips the fragments that have been completed, and transmits other fragments.

[0047] Specifically, the management server maintains the transmission status for each fragment, including completed and incomplete status. After the ferry proxy server sends a fragment to the management server, the management server receives and acknowledges the fragment, sets the transmission status of successfully received fragments to completed, and keeps the transmission status of fragments that have not yet been received as incomplete.

[0048] When a disconnection and reconnection occurs during the transmission of fragments, such as when a network interruption causes the transmission to pause and then resume, the ferry proxy server queries the management server for the transmission status of each fragment. It skips fragments whose transmission status is completed and only continues to transmit fragments that are not yet completed, without having to retransmit the entire transmission file. This achieves breakpoint resumption, saving bandwidth and transmission time.

[0049] Furthermore, the transmission status of each fragment is persistently recorded by the management server. The management server maintains a fragment metadata table, which records information such as the ferry task identifier, relative file path, fragment sequence number, offset, fragment size, checksum, and transmission status of each fragment. Before or during transmission resumption, the ferry proxy server queries the management server for the transmission status of each fragment and then decides which fragments to transmit based on this information. Even if the ferry proxy server experiences a failure and restarts, it can still obtain information on completed fragments from the management server after reconnecting to it and correctly resume transmission.

[0050] Furthermore, the ferry proxy server adaptively determines the fragmentation scheme based on the file size when packaging files. For example, files larger than 1GB are split into 256MB fragments, while smaller files can be transmitted as a whole. Each fragment carries a checksum when sent, preferably calculated using MD5 (Message-Digest Algorithm 5). The management server incrementally calculates the checksum in a streaming manner while receiving fragmented data. After receiving the data, it compares the calculated checksum with the checksum carried by the fragment. Only if they match is the fragmented data written to disk. During disk writing, a temporary file is first written, and after successful verification, it is atomically renamed to the official file, and the transmission status of the fragment is set to "completed". If the checksums do not match, the ferry proxy server is required to retransmit the fragment.

[0051] The management server can also query whether a historical file with the same summary already exists based on the overall summary of the transmitted file. If it does, the historical file is reused directly, and the transfer proxy server does not need to upload fragments again, thus achieving deduplication and instant transmission and saving transmission resources.

[0052] In a preferred embodiment of the present invention, after executing step S3, the process proceeds to step S4 to deliver the transferred file to the user; as... Figure 4 As shown, step S4 includes: Step S41, the control server matches the file content in the transmitted file with the preset information rules, and determines the risk level of the transmitted file based on the matching result; Step S42, the control server controls the transmitted file according to the risk level; the risk levels include a first risk level, a second risk level, and a third risk level; when the transmitted file is at the first risk level, the control server determines that the transmitted file has not passed the security verification, does not deliver the transmitted file to the user, and sends the user blocking information generated based on the matching result; when the transmitted file is at the second risk level, the control server determines that the transmitted file has passed the security verification, delivers the transmitted file to the user, and sends the user alarm information generated based on the matching result; when the transmitted file is at the third risk level, the control server determines that the transmitted file has passed the security verification, delivers the transmitted file to the user, and retains the corresponding delivery record in the control server.

[0053] Specifically, the control server matches the content of files in the transmitted files against preset information rules, and determines the risk level of the transmitted files based on the matching results. Information rules are pre-configured matching rules used to identify sensitive information, such as using regular expressions to match patterns of sensitive information like ID card numbers, mobile phone numbers, bank card numbers, email addresses, and application programming interface keys. The control server can also set restrictions on file types and file sizes. When a transmitted file contains a compressed file, the control server automatically decompresses it after recognizing it, and recursively performs content matching on the decompressed internal files; for multi-level nested compressed files, it decompresses and checks each level, and cleans up the temporary decompression directory after the checks are completed. The control server can also identify password-protected encrypted compressed files and process them accordingly.

[0054] Furthermore, the control server manages the transmitted files based on risk levels. Risk levels include a first risk level, a second risk level, and a third risk level, corresponding to high risk, medium risk, and low risk, respectively. The control server selects the highest risk level among all matching rules as the risk level of the transmitted file.

[0055] When a transmitted file is at the first risk level, the control server determines that the transmitted file has failed the security check, does not deliver the transmitted file to the user, and sends the user blocking information generated based on the matching results. The blocking information may include the type of rule that was hit, the location of the hit, etc., so that the user can understand the reason for the blocking.

[0056] When a transmitted file is classified as being at the second risk level, the management server determines that the transmitted file has passed the security verification and delivers the transmitted file to the user. At the same time, it sends an alarm message generated based on the matching results to the user, reminding the user that there is content in the file that requires attention.

[0057] When a transmitted file is at the third risk level, the management server determines that the transmitted file has passed the security verification, delivers the transmitted file to the user, and retains the corresponding delivery record in the management server. The record may include the detection time, hit rules, and file information, which can be reviewed by subsequent audits.

[0058] In a preferred embodiment of the present invention, after the user receives the blocking information, such as Figure 5As shown, the appeal process is executed using the following steps: Step B1, the management server receives the appeal request uploaded by the user; Step B2, the management server assigns a corresponding handler and sends the appeal request to the handler for processing, and after the appeal request is processed, proceeds to Step B3; Step B3, the management server receives the processing result returned by the handler and operates according to the processing result: when the processing result indicates success, the management server determines that the transmitted file has passed the security check and delivers the transmitted file to the user; when the processing result indicates failure, the management server determines that the transmitted file has failed the security check, does not deliver the transmitted file to the user, and sends the corresponding transfer failure information to the user.

[0059] Specifically, after receiving the blocking information, if a user believes that the transmission of the file has a legitimate business reason, they can send an appeal request to the control server. The appeal request can include the reasons for the appeal and relevant explanatory materials.

[0060] Furthermore, the control server receives and processes appeal requests, determines the corresponding appeal content based on the request, that is, extracts the reasons and explanations submitted by the user, and assigns a corresponding person to handle the appeal. The person handling the appeal can be a person responsible for compliance review or a member of a role group. The control server then sends the appeal content to the person handling the appeal for processing.

[0061] After the appeal request is processed, the management server receives the processing result from the processor and takes corresponding actions based on the result. When the processing result indicates success, the management server determines that the transmitted file has passed the security check and delivers the transmitted file to the user. When the processing result indicates failure, the management server determines that the transmitted file has failed the security check and sends the corresponding transfer failure information to the user.

[0062] Furthermore, the control server has pre-configured compliance role groups. Appeal requests are sent to these groups, and approval by any member within the group is considered a successful appeal, without the need to designate a specific handler. In one implementation, for files located in trusted paths pre-configured on the control server, or for transfer tasks marked as exempt by approval, the control server can grant exemptions during content detection, omitting sensitive information matching.

[0063] In a preferred embodiment of the present invention, the delivery method of the control server for the transmitted file includes any one of direct delivery, restricted delivery, and encrypted delivery. When using direct delivery, the control server provides the user with a download link for the transmitted file through a pre-defined browser. When using restricted delivery, the control server generates a corresponding access credential based on the storage directory of the transmitted file, sends the access credential to the user, and allows the user to access the storage directory containing the transmitted file and download the transmitted file. The access credential includes at least the allowed access period, the maximum allowed number of downloads, the maximum allowed number of simultaneous download sessions, and the access directory name. When using encrypted delivery, the control server connects to an external server based on a pre-defined key, transmits the transmitted file to the corresponding server, and notifies the user of the access address of the external server. The user then accesses the corresponding server according to the access address and downloads the transmitted file.

[0064] Specifically, the delivery method for files transmitted by the control server includes any one of direct delivery, restricted delivery, and encrypted delivery. Administrators can configure which delivery method to use based on security requirements and business scenarios.

[0065] When using direct delivery, the management server provides users with a download link for the transferred files via their browser. After logging into the management server, users can directly click the download link in the task list to download the files. This method is simple and direct, and suitable for scenarios with relatively low security requirements.

[0066] When using restricted delivery, the control server generates corresponding access credentials based on the directory where the transferred files are stored and sends these credentials to the user. The access credentials include at least the allowed access period, maximum allowed download count, maximum allowed concurrent download sessions, and the access directory name. The allowed access period defines the validity time of the credentials, for example, 7 days, after which the credentials automatically expire. The maximum allowed download count limits the total number of files that can be downloaded using this credential. The maximum allowed concurrent download sessions limits the number of concurrent connections established using this credential at the same time, preventing multiple users from using the credential simultaneously if it is leaked.

[0067] In addition, the management server also includes a credential name and a credential password. The credential name and password are temporary usernames and passwords randomly generated by the system, and are not the user's system account password. After obtaining access credentials, the user connects to the management server using the credential name and password via a file transfer protocol, and accesses and downloads files within the directory where the transferred files are stored.

[0068] In one embodiment, the management server restricts user access to the storage directory corresponding to the download task, preventing users from browsing other directories. This achieves directory-level access isolation through a virtual file system. The management server can also monitor current download sessions in real time and forcibly disconnect abnormal sessions.

[0069] When using encrypted delivery, the control server encrypts the file before transmitting it to an external server and sends the server's access password to the user. The user accesses the server using this password and downloads the encrypted file. The server is an external file storage server independent of the control server. The file is stored in encrypted form on the server, and the user decrypts it using the corresponding key after downloading to obtain the original file. This method is suitable for scenarios where files need to be delivered to an external third-party server. In one implementation, the control server transmits the encrypted file to the server according to a configurable failure retry strategy, such as using an incremental backoff method, where the waiting time for each retry increases progressively. The server access password used for transmission is stored in encrypted form on the control server, and the encryption key is derived from the control server's server key, avoiding plaintext storage of the password.

[0070] This invention discloses a secure file transfer system applied to an internal network. Employing the aforementioned secure file transfer method, it includes: a transfer proxy server, located within an isolated domain of the internal network; and a management server, located outside the isolated domain of the internal network, used to create and save corresponding transfer tasks based on user-uploaded transfer requests. The transfer proxy server includes: a task acquisition module, used to periodically send outbound requests to the management server to obtain corresponding transfer tasks from the management server; and a file transfer module, connected to the task acquisition module, used to obtain the corresponding transfer file from the isolated domain and send it to the management server when a pending transfer task indicates that a file needs to be transferred from the isolated domain.

[0071] In a preferred embodiment of the present invention, multiple isolation domains are set up in the internal network, and each isolation domain is equipped with a ferry proxy server; the management server includes: a receiving module for receiving ferry applications uploaded by users; an approval creation module connected to the receiving module for matching the corresponding approval path based on the ferry application to create an approval process; an approval sending module connected to the approval creation module for sending the ferry application to the corresponding approver according to the approval process; and a task creation module connected to the approval sending module for creating and saving the corresponding ferry task based on the ferry application after the ferry application is approved.

[0072] A complete embodiment is now provided to help those skilled in the art understand the method for implementing secure file transfer in this invention: A company's internal network includes a research and development (R&D) network and an office network. The R&D network is an isolated domain, and it is isolated from the office network by a firewall that does not open any inbound ports. A transfer proxy server is deployed within the R&D network, and a management server is deployed within the office network. R&D personnel need to export a batch of source code files from the R&D network to the office network. The R&D personnel access the management server through a browser, submit a transfer request, specifying the source isolated domain as the R&D network, the transfer direction as from within the isolated domain to outside the isolated domain, the storage path of the files to be exported within the R&D network, and the approver. The management server matches routing rules based on the isolated domain, applicant department, and transfer direction in the request, determines the approval process, and sends the transfer request to the approvers level by level according to the approval process. After all approvals are granted, the management server automatically creates a transfer task to be executed.

[0073] Every 10 seconds, a ferry proxy server deployed within the R&D network proactively initiates an outbound HTTPS request to the management server. Each request carries a message authentication code and a timestamp. The message authentication code is calculated using the HMAC-SHA256 algorithm, concatenating the proxy key, request method, request path, timestamp, and request digest. The management server verifies the correctness of the message authentication code, whether the proxy key has been revoked, and whether the difference between the timestamp and the server time is within 300 seconds. Upon successful verification, it returns a list of pending tasks belonging to that ferry proxy server. The ferry proxy server selects a pending task according to the task order and accepts it. The management server updates the task status from pending to executing through a condition update operation to ensure that the same task is not accepted repeatedly. After accepting a task, the ferry proxy server scans the files under the specified path and generates a transmission plan. Files larger than 1GB are fragmented into 256MB chunks, while the remaining files are transmitted as a whole. An MD5 checksum is calculated for each chunk, and each chunk is uploaded to the management server via an outbound request. The control server receives fragments in a streaming manner and incrementally calculates checksums. If the checksum matches the value carried on the fragment, the fragment is atomically renamed and written to disk. If the network is interrupted during transmission, the transfer agent server queries the control server for fragment completion status after recovery, skips completed fragments, and only continues transmitting incomplete fragments.

[0074] After all files are written to disk, the control server performs content security checks on the files. For text files, it matches them against preset rules for sensitive information such as ID card numbers, mobile phone numbers, bank card numbers, email addresses, and keys. For compressed files such as ZIP archives, they are automatically decompressed to a temporary directory, and internal files are recursively checked, with multi-layered nested compressed files checked layer by layer. After the checks are completed, the highest risk level is taken into account. If high-risk sensitive information such as ID card numbers is detected, the control server blocks delivery and sends a blocking message to the user; if only medium-risk rules are matched, an alarm is generated but delivery proceeds normally; if only low-risk rules are matched, the detection results are recorded and delivery proceeds normally.

[0075] For blocked tasks, users can file an appeal, which will be sent to the compliance role group for review by its members. If the appeal is approved, the block will be lifted and the necessary documents will be delivered; otherwise, the user will be notified that the transfer failed.

[0076] For files that pass the inspection, the control server delivers them in a controlled manner. Users can download them directly through a browser; alternatively, the system generates a temporary credential valid for 7 days, which users can use with a randomly generated credential name and password to download within a specified directory via a file transfer protocol. The system limits the number of concurrent sessions and downloads and can forcibly disconnect suspicious sessions; alternatively, the system can encrypt the file and push it to an external server, sending the access password to the user for download. The entire process is logged by the control server, and stored files and temporary credentials are automatically deleted after the retention period expires.

[0077] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A secure file transfer method, applied to an internal network, characterized in that, A ferry proxy server is set up within the isolation domain of the internal network, and a management and control server is set up outside the isolation domain of the internal network. The isolation domain rejects inbound requests initiated by the management and control server to the isolation domain. The management server creates and saves the corresponding ferry task based on the ferry application uploaded by the user. The file secure transfer method includes: step S1, whereby the transfer agent server periodically sends outbound requests to the management server to obtain the corresponding transfer task from the management server; Step S2: When the ferry task to be executed indicates that a file is to be transferred from the isolation domain, proceed to step S3; Step S3: The ferry proxy server obtains the corresponding file from the isolation domain according to the ferry task and sends it to the management server.

2. The document secure transfer method according to claim 1, characterized in that, The internal network is configured with multiple isolation domains, and each isolation domain is configured with a ferry proxy server. The ferry task is created using the following steps: Step A1, the management server receives the ferry application uploaded by the user; the ferry application includes the file identifier of the file to be transferred and the corresponding isolation domain. Step A2: The management server matches the corresponding approval path based on the ferry application to create an approval process; Step A3: The management server sends the ferry application to the corresponding approver according to the approval process, and proceeds to step A4 after the ferry application is approved; Step A4: The management server creates and saves the corresponding ferry task based on the ferry application.

3. The document secure transfer method according to claim 1, characterized in that, In step S2, when the ferry task to be executed indicates that the corresponding transfer file is uploaded to the isolation domain, the following steps are performed: the ferry proxy server downloads the transfer file uploaded by the user and associated with the ferry application from the management server based on the ferry task, saves the downloaded transfer file in the isolation domain according to the preset landing directory rules, and then exits.

4. The document secure transfer method according to claim 1, characterized in that, The management server allows multiple ferry tasks to be stored simultaneously and constructs a task order for the ferry tasks according to a preset sorting rule; each ferry task includes a corresponding execution status; step S1 includes: step S11, the ferry proxy server constructs a message authentication code based on a preset encoding method and the current timestamp, and constructs the outbound request based on the message authentication code; step S12, the ferry proxy server periodically sends the outbound request to the management server; step S13, the management server receives the outbound request and determines whether the outbound request is valid based on the message authentication code and the timestamp: if yes, proceed to step S14; if no, the management server refuses to send the ferry task to the ferry proxy server and then exits until it receives the next outbound request; step S14, the management server returns the task order of the ferry tasks to the ferry proxy server; step S15, the ferry proxy server obtains a ferry task with an execution status of pending execution based on the task order.

5. The document secure transfer method according to claim 1, characterized in that, The ferry proxy server will fragment the transmission files obtained from the isolation domain and send the fragments to the management server; each fragment has a corresponding transmission status. After each received fragment, the management server sets the transmission status of the received fragment to "completed" and saves the fragment and the corresponding transmission status. During the transmission of the fragments, when the ferry proxy server and the management server reconnect after a disconnection, the ferry proxy server queries the management server for the transmission status of the fragments and skips the fragments that have been transmitted to transmit other fragments.

6. The document secure transfer method according to claim 1, characterized in that, After executing step S3, the process proceeds to step S4 to deliver the transmitted file to the user. Step S4 includes: step S41, where the management server matches the file content in the transmitted file with preset information rules and determines the risk level of the transmitted file based on the matching result; step S42, where the management server manages the transmitted file according to the risk level; the risk level includes a first risk level, a second risk level, and a third risk level; when the transmitted file is at the first risk level, the management server determines that the transmitted file has not passed security verification, does not deliver the transmitted file to the user, and sends blocking information generated based on the matching result to the user; when the transmitted file is at the second risk level, the management server determines that the transmitted file has passed security verification, delivers the transmitted file to the user, and sends alarm information generated based on the matching result to the user; when the transmitted file is at the third risk level, the management server determines that the transmitted file has passed security verification, delivers the transmitted file to the user, and retains the corresponding delivery record in the management server.

7. The document secure transfer method according to claim 6, characterized in that, After the user receives the blocking information, the appeal process is executed using the following steps: Step B1, the management server receives the appeal request uploaded by the user; Step B2, the management server designates a corresponding handler and sends the appeal request to the handler for processing, and after the appeal request is processed, proceeds to Step B3. Step B3: The management server receives the processing result returned by the processor and performs the following operations based on the processing result: when the processing result indicates success, the management server determines that the transmitted file has passed the security check and delivers the transmitted file to the user; when the processing result indicates failure, the management server determines that the transmitted file has failed the security check, does not deliver the transmitted file to the user, and sends the corresponding ferry failure information to the user.

8. The document secure transfer method according to claim 6, characterized in that, The control server delivers the transferred files using any one of the following methods: direct delivery, restricted delivery, and encrypted delivery. When using direct delivery, the control server provides the user with a download link for the transferred file through a pre-defined browser. When using restricted delivery, the control server generates a corresponding access credential based on a pre-defined storage directory and sends the access credential to the user, allowing the user to access the storage directory containing the transferred file and download it. The access credential includes at least the allowed access period, the maximum allowed number of downloads, the maximum allowed number of simultaneous download sessions, and the access directory name. When using encrypted delivery, the control server connects to an external server based on a pre-defined key, transmits the transferred file to the corresponding server, and notifies the user of the external server's access address. The user then accesses the corresponding server and downloads the transferred file based on the access address.

9. A secure file transfer system, applied to an internal network, characterized in that, The file secure transfer method according to any one of claims 1-8 includes: a transfer proxy server, the transfer proxy server being set within an isolation domain of the internal network; and a management server, the management server being set outside the isolation domain of the internal network, used to create and save corresponding transfer tasks based on user-uploaded transfer requests; the transfer proxy server includes: a task acquisition module, used to periodically send outbound requests to the management server to acquire the corresponding transfer task from the management server; and a file transfer module, connected to the task acquisition module, used to acquire the corresponding transfer file from the isolation domain and send it to the management server when the transfer task to be executed indicates that a file to be transferred is to be acquired from the isolation domain.

10. The document secure transfer system according to claim 9, characterized in that, The internal network is configured with multiple isolation domains, and each isolation domain is configured with a ferry proxy server. The management server includes: a receiving module for receiving user-uploaded ferry applications; an approval creation module connected to the receiving module for matching the corresponding approval path based on the ferry application to create an approval process; an approval sending module connected to the approval creation module for sending the ferry application to the corresponding approver according to the approval process; and a task creation module connected to the approval sending module for creating and saving the corresponding ferry task based on the ferry application after it has been approved.

Images