A blockchain encryption proxy method based on HTTP and FTP protocols

Abstract

The application relates to the field of network communication and data security processing, in particular to a blockchain encryption proxy method based on HTTP and FTP protocols.The method comprises the following steps: receiving a data request based on a protocol proxy engine, performing protocol identification, executing direction extraction and request feature extraction, obtaining a first request feature result; performing identity authentication and authorized access, real-time calling of public and private keys and address mapping processing with key relationship, obtaining a first mapping processing result; performing sending or uploading chain processing and query or downloading chain processing, obtaining a first bidirectional processing result; performing audit management, blockchain recording or verification, rule engine verification and mapping relationship updating processing, obtaining an updated mapping processing result; through pre-access strategy, public and private key calling, bidirectional out-of-order execution chain and blockchain audit, the application realizes efficient fusion of data access and encryption proxy, and significantly improves the security, traceability and dynamic adaptation capability of cross-protocol data transmission.

Description

Technical Field

[0001] This invention relates to the field of network communication and data security processing, and in particular to a blockchain encryption proxy method based on HTTP and FTP protocols. Background Technology

[0002] In the field of network communication and data security processing, existing solutions for data request processing based on HTTP and FTP protocols typically revolve around a data access module, a data transformation and cleaning module, a data encryption and desensitization module, and a blockchain layer. These solutions suffer from limitations such as a disconnect between access policies and data requests, a disconnect between public and private key calls and application interface modules, and a disconnect between the target server address and FTP directory mapping and the processing chain. Existing methods often send data requests to the data access module or data transformation and cleaning module first, and then perform authentication, authorization, encryption, and blockchain recording separately. This can easily lead to inconsistencies in the processing order, scattered correspondences between processed objects, and fragmented storage of operation logs.

[0003] In scenarios involving data requests, uploads, queries, and downloads under HTTP, HTTPS, or FTP protocols, existing solutions are prone to issues such as the same third-party application using the same processing path in different execution directions, and a lack of unified association between file paths, directories, data formats, user attributes, and role permissions. This makes it difficult to meet the requirement for stable implementation of data requests, uploads, queries, and downloads. In existing business processes, service interfaces, API interfaces, and external network systems often maintain their own access control and encryption relationships. Data format conversion, field naming, encryption, private key decryption, timestamp verification, and digital signature verification are often performed in different stages. This results in numerous synchronous modifications to the processing chain when business interfaces, directories, or target server addresses change, leading to a heavy manual maintenance burden during data transmission and processing.

[0004] For the joint processing of the first request feature result, the first access policy result, the first key identification result, and the first mapping processing result, existing technologies generally distribute identity authentication, authorized access, real-time public and private key invocation, target server address mapping, FTP directory mapping, format unification, encryption processing, query and download return, and blockchain layer recording or verification in different processing locations. This makes it difficult to form a consistent process in HTTP, HTTPS, or FTP protocol application scenarios, from data request entry, access policy matching, key identification organization, mapping processing, sending data request or upload, query or download, return to the requester, to operation log update. This results in a loose connection between the processing links of sending data request, upload, query, and download, and a scattered correspondence between data hash, timestamp, digital signature, and operation log. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a blockchain encrypted proxy method based on HTTP and FTP protocols, comprising:

[0006] S100: The protocol proxy engine receives the data request, performs protocol identification processing, execution direction extraction processing, and request feature extraction processing, and obtains the first request feature result;

[0007] The protocol proxy engine receives data requests, including those initiated by third-party applications, service interfaces, API interfaces, or external network systems.

[0008] S200. Based on the first request feature result, perform identity authentication and authorized access processing, real-time public and private key invocation processing, and address mapping processing with key relationship to obtain the first mapping processing result;

[0009] S300. Based on the first mapping processing result, perform sending or uploading chain processing and querying or downloading chain processing to obtain the first bidirectional processing result.

[0010] S400. Based on the first bidirectional processing result, perform audit management processing, blockchain recording or verification processing, rule engine verification processing, and mapping relationship update processing to obtain the updated mapping processing result.

[0011] Furthermore, the processes of protocol identification, execution direction extraction, and request feature extraction include:

[0012] The protocol identification process includes: segmenting and organizing the data request, comparing the interface format of HTTP, HTTPS or FTP protocols, writing the corresponding protocol into the protocol identifier area, performing boundary checks on empty data requests, missing protocol identifiers, service interface mismatches or unknown external network system sources, and incorporating abnormal states into the first data request result.

[0013] The execution direction extraction process includes: reading the protocol type and service interface correspondence in the first data request result, and determining that the data request belongs to one of query, send data request, upload or download, wherein query and send data request correspond to HTTP or HTTPS protocol, and upload and download correspond to FTP protocol;

[0014] The request feature extraction process includes: extracting application interface modules, file paths, and directories according to the execution direction, identifying the data format as JSON, XML, or a file, then organizing user attributes, role permissions, and authorized access status, and associating and merging the above content as the first request feature result.

[0015] Furthermore, the identity authentication and authorization access process includes:

[0016] The identity authentication and authorization access processing includes: the authentication management interface reads user attributes and aligns them with role permissions to generate an identity authentication status; the authentication and authorization module organizes access policies according to the identity authentication status, role permissions, and authorization access status, and generates a first access policy result bound to the execution direction; the execution direction is one of querying, sending data requests, uploading, or downloading, and different directions enter different access policy paths.

[0017] Furthermore, the process of real-time public / private key invocation includes:

[0018] The real-time public / private key invocation process includes: the public / private key management interface organizes the token mechanism according to the first access policy result; when the execution direction is query or download, it extracts the private key invocation relationship; when the execution direction is send data request or upload, it extracts the public key invocation relationship; then it invokes the public key or private key in real time, and synchronously reads the key generation, key backup, key recovery and key rotation records, and organizes them into a first key identification result containing key number, invocation status, version status and rotation status.

[0019] Furthermore, the process of address mapping with key relationships includes:

[0020] The address mapping process with key relationships includes: the data access module reads the public key call relationship or private key call relationship in the first key identification result; when the execution direction is to send a data request, the application interface module, service interface and target server address are mapped and the public key call relationship is merged; when the execution direction is to query, the service interface and target server address are mapped and the private key call relationship is merged; when the execution direction is to upload, the application interface module, file path and FTP directory are mapped and the public key call relationship is merged; when the execution direction is to download, the directory and FTP directory are mapped and the private key call relationship is merged, thus obtaining the first mapping processing result.

[0021] Furthermore, the process of sending or uploading the chain includes:

[0022] The sending or uploading chain processing includes: a data conversion and cleaning module first unifies the node order of XML data format, the field order of JSON data format, and the directory and file path order of files; then, it unifies the field names of different fields of the same business content in different interfaces to generate unified field naming records; after the format unification and field naming unification are completed, the data encryption and desensitization module performs encryption, data hashing, and digital signature based on the public key call relationship in the first key identification result; when the execution direction is to send a data request, it sends the data to the target server address through the service interface or API interface; when the execution direction is to upload, it performs upload processing through the FTP directory to obtain the first sending and uploading result.

[0023] Furthermore, the process of querying or downloading the chain includes:

[0024] The query or download chain processing includes: after receiving the first upload result, the protocol proxy engine queries the target server address when the corresponding data request is returned, and downloads the corresponding file receipt or directory read trigger content to the FTP directory; the data encryption and desensitization module first decrypts the returned or downloaded content using a private key, and then verifies the timestamp and digital signature; after verification, the data conversion and cleaning module reads the field hierarchy, directory correspondence, and file path records formed in S310, restores them to the data format required by the caller, and obtains the first bidirectional processing result.

[0025] Furthermore, the audit management process includes:

[0026] The audit management process includes: the audit management interface reads the execution direction from the first bidirectional processing result, organizes it according to the query chain, data request chain, upload chain or download chain, and calls the first access policy result formed in S210 to realign with the execution direction, application interface module, target server address, service interface, API interface or FTP directory in the first bidirectional processing result, and associates the data hash, timestamp, digital signature, operation log and processing result to form the first proxy control chain result.

[0027] Furthermore, the process of blockchain recording or verification includes:

[0028] The blockchain recording or verification process includes: the blockchain storage interface extracting data hash, timestamp, digital signature and processing result summary from the result of the first agent control chain, packaging and sending it to the blockchain layer for recording, or reading existing records from the blockchain layer and comparing them with the current result.

[0029] Furthermore, the rule engine's validation and mapping update processes include:

[0030] The rule engine verification process includes: after receiving the status returned by the blockchain layer, the rule engine verifies the correspondence between the access policy and the application interface module, target server address, service interface, API interface or FTP directory. If they are inconsistent, the current access policy is marked as an access policy to be updated and the effective time is calculated.

[0031] The mapping update process includes: the audit management interface sends the effective time, verification status, and access policy changes to the data access module; the data access module reorganizes the mapping relationship between the application interface module and the target server address, or reorganizes the mapping relationship between the directory and the FTP directory, and writes the changes to the operation log to obtain the updated mapping processing result.

[0032] The key innovations of this invention include:

[0033] (1) Based on the first request feature result, the authentication management interface identity authentication and authentication authorization module authorization access processing are performed first to obtain the first access policy result; then, based on the first access policy result, the token mechanism is organized and the public key and private key are called in real time to obtain the first key identification result; then, based on the first key identification result, the data access module, application interface module, target server address, service interface, API interface and FTP directory mapping processing are performed to obtain the first mapping processing result, thereby organizing the access policy, key identification and mapping processing in the same link.

[0034] (2) Based on the first data to be processed, first perform format unification and field naming unification processing, then perform encryption, format preservation encryption, data hashing, digital signature and data request or upload processing to obtain the first send and upload result, so that the data request chain and upload chain revolve around the unified data object.

[0035] (3) Based on the first upload result, the first bidirectional processing result is obtained in the order of query, download, private key decryption, timestamp verification, digital signature verification and format recovery. The first bidirectional processing result is then audited and processed by the management interface access strategy, data hash, timestamp, digital signature, operation log and processing result. Then, the blockchain layer records or verifies, the rule engine verifies, the effective time is sorted, and the application interface module mapping relationship, FTP directory mapping relationship and operation log are updated to form a continuous organization of the proxy control chain and the update chain.

[0036] The following are its main beneficial effects:

[0037] (1) In view of the problems in the existing schemes that the access policy is disconnected from the data request, the public key and private key call is disconnected from the application interface module, and the target server address and FTP directory mapping is disconnected from the processing link, the present invention incorporates the first access policy result, the first key identification result and the first mapping processing result into the same processing link in sequence, so that sending data requests, uploading, querying and downloading have corresponding access constraints, key constraints and mapping constraints before entering the data conversion and cleaning process, and the correspondence between the application interface module, the target server address, the service interface, the API interface and the FTP directory remains consistent during the operation.

[0038] (2) In view of the problem that data format conversion, field naming and encryption are scattered in different stages in the existing solution, the present invention first unifies the format and field naming of the first data to be processed, and then performs encryption, format preservation encryption, data hashing and digital signature processing, so that the data sending request chain and the upload chain are executed around the unified data object. The XML, JSON and files are processed in the same processing framework before entering the data sending request or upload processing.

[0039] (3) In view of the problem that the query chain and download chain are separated from the sending chain and upload chain in the existing scheme, the present invention organizes query, download, private key decryption, timestamp verification, digital signature verification and format recovery in the same return chain in a fixed order, so that there is a clear correspondence between the first sending and uploading result and the first bidirectional processing result. The format recovery is based on the preceding data hash, digital signature and timestamp verification, and the data content returned to the requester is linked with the preceding sending or uploading content.

[0040] (4) In view of the problems of segmented storage of operation logs, scattered correspondence between data hash, timestamp and digital signature in the existing scheme, the present invention organizes and processes the access strategy, data hash, timestamp, digital signature, operation log and processing result of the first bidirectional processing result through audit management interface, and then enters the blockchain layer for recording or verification processing, so that the access strategy, data hash, timestamp, digital signature, operation log and processing result are continuously called and organized in the same proxy control chain.

[0041] (5) In response to the problem that the processing link is modified a lot after the business interface is adjusted, the directory is adjusted or the target server address is changed in the existing solution, the present invention continues to perform rule engine verification, effective time sorting and application interface module mapping relationship, FTP directory mapping relationship and operation log update processing after recording or verification at the blockchain layer, so that the updated access policy result and the updated mapping processing result are connected, and the updated mapping relationship and operation log can be directly called when subsequent data requests come in. Attached Figure Description

[0042] Figure 1 A flowchart illustrating a blockchain encrypted proxy method based on HTTP and FTP protocols provided in this application embodiment;

[0043] Figure 2 This is a structural block diagram of a blockchain encrypted proxy method based on HTTP and FTP protocols, provided in an embodiment of this application. Detailed Implementation

[0044] Example 1: Refer to Figure 1This is a flowchart illustrating a blockchain encryption proxy method based on HTTP and FTP protocols provided in an embodiment of the present invention. The process may include at least steps S100-S400:

[0045] S100: The protocol proxy engine receives the data request, performs protocol identification processing, execution direction extraction processing, and request feature extraction processing, and obtains the first request feature result;

[0046] S200. Based on the first request feature result, perform identity authentication and authorized access processing, real-time public and private key invocation processing, and address mapping processing with key relationship to obtain the first mapping processing result;

[0047] S300. Based on the first mapping processing result, perform sending or uploading chain processing and querying or downloading chain processing to obtain the first bidirectional processing result.

[0048] S400. Based on the first bidirectional processing result, perform audit management processing, blockchain recording or verification processing, rule engine verification processing, and mapping relationship update processing to obtain the updated mapping processing result.

[0049] Step S100 includes at least steps S110-S130:

[0050] S110: Obtain data requests initiated by third-party applications, service interfaces, API (Application Programming Interface) interfaces, or external network systems, perform HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), or FTP (File Transfer Protocol) protocol identification and processing, and obtain the first data request result.

[0051] The protocol proxy engine receives data requests from third-party applications, service interfaces, APIs (Application Programming Interfaces), or external network systems.

[0052] Specifically, the protocol proxy engine in the platform's audit layer continuously receives data streams from third-party applications, service interfaces, API interfaces, or external network systems. The third-party applications are those that initiate queries, send data requests, upload, or download data.

[0053] The service interface is the interface unit for receiving or forwarding data requests. The API interface is the interface unit that enters the platform audit layer when called externally.

[0054] The external network system refers to the request source outside the platform's internal network.

[0055] After receiving the data request, the protocol proxy engine first segments and organizes the data request, and then compares the access methods corresponding to the service interface, API interface and external network system.

[0056] When the access method matches the interface format of HTTP, HTTPS, or FTP protocols, the protocol proxy engine writes the corresponding protocol into the protocol identifier area of ​​the current data request. HTTP corresponds to normal data transmission scenarios, HTTPS to data transmission scenarios with a secure TLS / SSL protocol transmission channel, and FTP to directory, file path, and upload / download scenarios. During protocol identification and processing, boundary checks are also performed on abnormal requests.

[0057] Boundary checks include empty data requests, missing protocol identifiers, service interface mismatches, and unknown external network system origins. When any of these situations occur, the protocol proxy engine writes the abnormal status to the operation log and includes the abnormal status along with the current data request in the first data request result.

[0058] Furthermore, the first data request result includes the identified protocol type, data request source, service interface correspondence, and current operation log index.

[0059] After the above processing, the obtained data is recorded as the first data request result. The first data request result is used as the input of "first data request result" in S120 and continues to be passed to S200 along the main step link for subsequent authentication management interface and authentication authorization module to receive the request basis call.

[0060] S120. Based on the first data request result, perform the execution direction extraction processing corresponding to querying, sending data requests, uploading or downloading to obtain the first dynamic parsing result.

[0061] Specifically, the protocol proxy engine reads the protocol type and service interface correspondence in the first data request result, and determines which execution direction the data request belongs to among query, send data request, upload or download, based on the access method of the current data request.

[0062] The query refers to the processing direction in which a third-party application or external network system requests data from the target server address.

[0063] The "send data request" refers to the process of a third-party application or external network system submitting data to the target server address via a service interface or API interface. The "upload" refers to the process of writing a file to a directory via the FTP protocol.

[0064] The download refers to the process of retrieving files from a directory via the FTP protocol.

[0065] During operation, when the result of the first data request corresponds to the HTTP or HTTPS protocol, and the current service interface is retrieving data from the target server address, the protocol proxy engine marks the execution direction as query; when the result of the first data request corresponds to the HTTP or HTTPS protocol, and the current service interface is submitting data to the target server address, the protocol proxy engine marks the execution direction as send data request; when the result of the first data request corresponds to the FTP protocol, and the data stream points to directory writing, the protocol proxy engine marks the execution direction as upload; when the result of the first data request corresponds to the FTP protocol, and the data stream points to directory reading, the protocol proxy engine marks the execution direction as download.

[0066] Furthermore, when extracting the execution direction, the protocol proxy engine simultaneously checks whether the current data request and protocol type are consistent. If an HTTP protocol is identified but a directory read relationship appears, or an FTP protocol is identified but a service interface submission relationship appears, the inconsistent state is written to the operation log, and the original protocol identifier is retained for subsequent authentication management interface and audit management interface to call.

[0067] After the execution direction extraction process, the protocol proxy engine organizes the protocol type, execution direction, data request source, and abnormal status into a first dynamic parsing result. This first dynamic parsing result serves as the input to the "first dynamic parsing result" in S130, and also as the basis for direction determination before the generation of the first access policy result in S200.

[0068] S130. Based on the first dynamic parsing result, perform application interface module, file path, directory, data format, user attributes, role permissions and authorized access status extraction processing to obtain the first request feature result.

[0069] Specifically, the protocol proxy engine automatically parses the first dynamic parsing result using template configuration.

[0070] The application interface module is the interface module that establishes a communication relationship between the platform audit layer and the target server address, service interface, or API interface. The file path is the path information of the corresponding file under the FTP protocol.

[0071] The directory is the directory information used for uploading or downloading under the FTP protocol. The data format is JSON, XML, or a file corresponding to the current data request.

[0072] The user attributes are the identity attributes corresponding to third-party applications or external network systems in the authentication management interface.

[0073] The role permissions refer to the hierarchical control information of role permissions in the permission management module. The authorized access status refers to the authorization access result of the authentication and authorization module for third-party applications.

[0074] The protocol proxy engine first extracts the application interface module, file path, and directory based on the execution direction, and then identifies the data format based on the data content format carried in the data request. When the data content presents a JSON structure, it is recorded as JSON; when the data content presents an XML structure, it is recorded as XML; when the data content corresponds to a directory read / write object, it is recorded as a file.

[0075] Subsequently, the protocol proxy engine organizes user attributes, role permissions, and authorized access status from the access relationships corresponding to third-party applications, service interfaces, API interfaces, or external network systems, and associates and merges the user attributes, role permissions, and authorized access status with application interface modules, file paths, directories, and data formats.

[0076] Understandably, if the execution direction is querying or sending a data request, the application interface module, data format, user attributes, and role permissions are the main extraction items, while the file path and directory are retained as empty path identifiers; if the execution direction is uploading or downloading, the file path, directory, data format, and authorized access status are the main extraction items, and the application interface module is retained synchronously.

[0077] Furthermore, the protocol proxy engine performs logical consistency checks on missing items. If there are missing application interface modules, missing directories, missing role permissions, or unregistered authorized access statuses, the missing items are written to the operation log, and their original correspondence is preserved for continued use by the authentication management interface's identity authentication and authorization module's authorized access processing in S210.

[0078] After the above extraction and processing, the application interface module, file path, directory, data format, user attributes, role permissions, and authorized access status are organized into the first request feature result.

[0079] The first request feature result is used as the input of "first request feature result" in S210 and is passed along the subsequent links to the corresponding processing procedures in S200, S300 and S400.

[0080] In summary, the technical effect of this step is as follows: By placing the protocol proxy engine at the front end of the platform's audit layer, data requests are first identified in terms of protocol and execution direction, and then request features are extracted, forming a front-end parsing chain centered around the data request. This front-end parsing chain incorporates application interface modules, file paths, directories, data formats, user attributes, role permissions, and authorized access status into the same request feature result. Subsequent access policy matching, public / private key management interface calls, and data transformation and cleaning processes all directly read the same set of fields.

[0081] Step S200 includes at least steps S210-S230:

[0082] S210. Obtain the first request feature result, perform identity authentication of the authentication management interface and authorization access processing of the authentication authorization module, and obtain the first access strategy result.

[0083] Specifically, the first request feature result comes from S130. The first request feature result already includes the application interface module, file path, directory, data format, user attributes, role permissions and authorized access status. Therefore, this step will not extract the protocol type and execution direction again, but will directly send the first request feature result to the authentication management interface and authentication authorization module in the platform audit layer.

[0084] The authentication management interface is a unit within the platform audit layer that receives authentication requests, reads user attributes, and outputs authentication status. The authentication authorization module is a processing unit within the platform audit layer that receives role permissions, authorization access status, and application interface module relationships, and outputs access policies. During runtime, the authentication management interface first reads the user attributes.

[0085] The user attributes include the identity identifier, access source, and historical authorized access status corresponding to third-party applications, service interfaces, APIs (Application Programming Interfaces), or external network systems. Then, the authentication management interface aligns these user attributes with the defined role permissions.

[0086] The role permissions refer to the hierarchical control of permissions corresponding to the four execution directions of querying, sending data requests, uploading, and downloading in the permission management module. After alignment, the authentication management interface generates an identity authentication status and sends the identity authentication status, along with the application interface module and the data format, to the authentication and authorization module.

[0087] Furthermore, the authentication and authorization module processes authorization access based on identity authentication status, role permissions, and authorization access status. Authorization access processing is not simply a matter of passing or failing; rather, it is organized according to the execution direction.

[0088] When the execution direction is query, the authentication and authorization module organizes the access policy corresponding to the query; when the execution direction is sending a data request, the authentication and authorization module organizes the access policy corresponding to sending the data request; when the execution direction is upload or download, the authentication and authorization module also reads the file path and directory correspondence and writes the directory range into the access policy.

[0089] Understandably, in the scenario of HTTP protocol query initiated by the service interface, the authentication and authorization module associates the role permissions corresponding to the service interface with the access range of the target server address; in the scenario of FTP protocol upload initiated by the external network system, the authentication and authorization module associates the authorized access status with the FTP directory access range.

[0090] If issues arise such as missing user attributes, inconsistencies between role permissions and execution direction, unregistered authorization access status, or mismatch between application interface modules and role permissions, the authentication management interface will write the abnormal status to the operation log. The authentication and authorization module will then retain the original first request characteristic result and generate a restricted access policy. This ensures that subsequent real-time calls to public and private keys will not deviate from the current user attributes and role permissions.

[0091] After the identity authentication and authorization access processing, the platform audit layer outputs the first access policy result and uses the first access policy result as the input of "first access policy result" in S220. At the same time, the first access policy result also provides the data conversion and cleaning module and data encryption and desensitization module in S300 with the basis for access boundary invocation.

[0092] S220. Based on the result of the first access policy, perform token mechanism processing, real-time public key and private key invocation processing, and obtain the first key identification result.

[0093] Specifically, after the result of the first access policy is used as the input for this step, the authentication and authorization module in the platform audit layer first breaks down and organizes the execution direction, application interface module, data format and directory range in the access policy, and then the public and private key management interface executes the real-time call processing of public and private keys.

[0094] The Token mechanism is a token management mechanism within the authentication and authorization module that corresponds to the authorized access status. Its content includes the token source, token validity status, the application interface module corresponding to the token, and the execution direction corresponding to the token. In this step, the Token mechanism does not independently form an access control conclusion, but rather serves as a condition for organizing the public and private keys before real-time invocation.

[0095] Specifically, when the result of the first access policy corresponds to a query or download, the authentication and authorization module extracts the token mechanism and execution direction from the result of the first access policy, and writes the execution direction and the private key call relationship into the current call record; when the result of the first access policy corresponds to a data request or upload, the authentication and authorization module extracts the token mechanism and application interface module from the result of the first access policy, and writes the application interface module and the public key call relationship into the current call record.

[0096] Subsequently, the public / private key management interface receives the aforementioned call records and performs real-time calls to the public and private keys.

[0097] The public / private key management interface is an interface unit used to organize and invoke public keys, private keys, key generation, key backup, key recovery, and key rotation. The public key is the key resource used for encryption processing in public key encryption.

[0098] The private key is the key resource used for decryption in private key decryption. Real-time invocation means that the public-private key management interface does not pre-determine the output public and private keys, but instead, after the current first access strategy result is received, it instantly extracts the currently available public or private key based on the execution direction, data format, and application interface module.

[0099] Furthermore, the public-private key management interface also synchronously reads key generation records, key backup records, key recovery records, and key rotation records, and organizes the records consistent with the current execution direction into key version relationships.

[0100] In a specific engineering embodiment, when a third-party application initiates a data sending request in JSON format via an API interface, the authentication and authorization module first organizes the token mechanism, and the public and private key management interface then retrieves the public key call record and key rotation record corresponding to the API interface; when an external network system initiates a download via the FTP protocol, the authentication and authorization module organizes the directory range and token mechanism, and the public and private key management interface then retrieves the corresponding private key call record and key recovery record.

[0101] If a public key is missing, a private key is missing, the token mechanism fails, the key rotation record is not updated, or the key recovery record is incomplete during the real-time call, the public and private key management interface will write the abnormal status to the operation log and mark the current call result as a restricted key call status.

[0102] After the above processing, the public key, private key, key version, key rotation result, and current call status are uniformly organized into a first key identifier result. The first key identifier result serves as the input to "first key identifier result" in S230, and corresponds to the encryption, private key decryption, data hashing, and digital signature call relationships in subsequent S320 and S330, respectively.

[0103] S230. Based on the first key identification result, perform mapping processing on the data access module, application interface module, target server address, service interface, API interface and FTP directory to obtain the first mapping processing result.

[0104] Specifically, after the first key identification result enters this step, it is received by the data access module, which reads the execution direction correspondence, public key call relationship, private key call relationship, and key version relationship. The data access module is a unit used to organize the application interface module, target server address, service interface, API interface, and FTP directory into the same access relationship.

[0105] The mapping process is not a simple address binding, but rather it maps the key call relationships already determined in the aforementioned first key identification result to the application interface module, target server address, service interface, API interface, and FTP directory one by one.

[0106] Specifically, when the execution direction is to send a data request, the data access module reads the application interface module and the service interface, maps them to the target server address, and then merges the mapping relationship with the public key call relationship; when the execution direction is to query, the data access module reads the service interface and the target server address, and merges the mapping relationship with the private key call relationship; when the execution direction is to upload, the data access module reads the application interface module, the file path, and the FTP directory, and merges the mapping relationship with the public key call relationship; when the execution direction is to download, the data access module reads the directory and the FTP directory, and merges the mapping relationship with the private key call relationship.

[0107] Furthermore, the service interface is the interface location where the current data request enters or exits, the target server address is the actual data transmission location corresponding to the service interface or API interface, and the FTP directory is the directory location in the upload or download scenario. During mapping processing, the data access module also checks whether there is an existing correspondence between the application interface module and the target server address, checks whether the FTP directory and the directory are consistent, and writes the check results to the operation log.

[0108] Understandably, in one real-world scenario, a third-party application initiates a data request in XML format via a service interface. The data access module first reads the public key call relationship from the first key identification result, and then maps this public key call relationship to the current application interface module, the service interface, and the target server address to form a data request mapping path. In another real-world scenario, an external network system initiates a file download via the FTP protocol. The data access module first reads the private key call relationship from the first key identification result, and then maps this private key call relationship to the file path, directory, and FTP directory to form a download mapping path.

[0109] If an application interface module is missing, the target server address is not registered, the service interface is mismatched, the API interface is mismatched, or the FTP directory does not exist during the mapping process, the data access module will write the abnormal status to the operation log and retain the existing mapping part for the subsequent data conversion and cleaning module to continue processing according to the restricted path.

[0110] After mapping processing, the platform audit layer obtains the first mapping processing result. This first mapping processing result includes the correspondence between application interface modules, target server addresses, service interfaces, API interfaces, and FTP directories, as well as their matching key call relationships. This first mapping processing result serves as the input to "First Mapping Processing Result" in S310 and crosses over to S300 for processing by the XML / JSON parsing library, conversion between structured and unstructured data, and subsequent data request, upload, query, and download calls.

[0111] In summary, this step incorporates the results of the first access policy and the first key identification into the mapping process, creating a processing sequence of "first authentication and authorization, then real-time retrieval of the public and private keys, and finally mapping of the application interface module to the target server address or FTP directory." Compared to existing technologies that perform data access first and then permission and key processing, this step ensures that subsequent data access modules, data conversion and cleaning modules, and data encryption and desensitization modules all operate along the same mapping relationship, reducing the fragmentation of paths between querying, sending data requests, uploading, and downloading.

[0112] In one specific embodiment, the authentication management interface in the S210 platform audit layer first receives a first request feature result from S130. This first request feature result includes the application interface module, file path, directory, data format, user attributes, role permissions, and authorized access status. The authentication management interface first reads the user attributes, which include the identity identifier, access source, and historical authorized access status corresponding to the third-party application, service interface, API interface, or external network system. Subsequently, the authentication management interface aligns the user attributes with role permissions. Role permissions are the hierarchical control content corresponding to the four execution directions of query, send data request, upload, and download in the permission management module. After alignment, the authentication management interface generates an identity authentication status and sends the identity authentication status, along with the application interface module and data format, to the authentication authorization module.

[0113] The authentication and authorization module processes access authorization based on identity authentication status, role permissions, and authorized access status. This processing doesn't simply determine pass or fail; instead, it organizes access policies according to the execution direction. To quantify the priority of access policies under different execution directions, formula ① is introduced to calculate the policy weight vector. Formula ① integrates the historical authorized access status in user attributes, the hierarchical values ​​in role permissions, and the constraint coefficient of the current execution direction to generate a policy weight value bound to the execution direction, thereby determining which type of access path (query, send data request, upload, or download) the request should enter.

[0114] Formula①

[0115]

[0116] Variable and symbol definition:

[0117] Strategy weights, range of values , indicating the current execution direction The strength of the access policy is calculated using formula ①, and serves as the core basis for the authentication and authorization module to generate the access policy.

[0118] : Execution direction label, with a value of one of the following: "Query", "Send Data Request", "Upload", or "Download". Obtained from the execution direction extraction process in S120;

[0119] : Summation symbol, indicating summation of... Three items added together;

[0120] : Sum index, retrieve value These correspond to the identity authentication status respectively. Role permissions ), Authorized access status ( );

[0121] Direction coefficient, range of values From the direction of execution Decision. When With the The value is 1 if the item is relevant, otherwise it is 0. This is preset by the authentication and authorization module according to the direction rules.

[0122] The normalization coefficient for role permissions is read from the system configuration table and satisfies... The specific value is preset by the system administrator;

[0123] : Role permission level values, extracted from the role permission data source. To query permission values, To send data request permission value, For upload and download permission values, the value range is [value range]. ;

[0124] The normalization coefficient for authorized access status is read from the system configuration table and compared with... They jointly satisfy the normalization constraint;

[0125] : Quantified value of authorized access status, extracted from the authorized access status data source. For interface-level authorization (value 0 or 1). Grant directory-level permissions (0 or 1). For application-level authorization (0 or 1);

[0126] The normalization coefficient for the number of historical anomalies is read from the system configuration table and compared with... They jointly satisfy the normalization constraint;

[0127] The number of anomalies in the historical authorized access status is counted from the historical authorized access status records in the user attributes. The unit is times, and the value range is non-negative integers.

[0128] Data Source → Metrics → Variables: Extract historical authorized access status from user attributes based on the first request feature results; the cumulative number of anomalies is recorded as follows. The hierarchical values ​​of role permissions extracted from the first request feature results are denoted as follows: The three-bit flag bits extracted from the authorized access status from the first request feature result are mapped to the following: Formula ① This serves as the core basis for generating the access policy in this step.

[0129] Simple numerical example: Input: Execution direction is "Send data request", then ; ; ; ; ; ; .but Output a dimensionless weight value of 5.5.

[0130] The authentication and authorization module obtains the result according to formula ①. The access strategies are then organized according to the execution direction. If... If the value exceeds a preset threshold (e.g., 4.0), a complete access policy is generated; otherwise, a restricted access policy is generated. When the execution direction is query, the authentication and authorization module organizes the access policy corresponding to the query, associating the role permissions corresponding to the service interface with the access range of the target server address; when the execution direction is sending a data request, it organizes the access policy corresponding to sending the data request; when the execution direction is upload or download, it also reads the file path and directory correspondence and writes the directory range into the access policy. If there are situations such as missing user attributes, inconsistent role permissions with the execution direction, unregistered authorization access status, or mismatch between the application interface module and role permissions, the authentication management interface writes the abnormal status into the operation log, and the authentication and authorization module retains the original first request feature result and generates a restricted access policy. After the above processing, the platform audit layer outputs the first access policy result. This first access policy result serves as the input to S220 and provides the access boundary call basis to the data conversion and cleaning module and the data encryption and desensitization module in S300.

[0131] This section summarizes the technical effects: By using formula ①, this section quantifies and integrates user attributes, role permissions, authorized access status, and execution direction to generate policy weights bound to the direction. This achieves pre-processing of access policies, allowing different execution directions to enter different processing paths, thus avoiding the inefficiency and security risks of unified access control followed by unified processing in existing technologies.

[0132] Furthermore, the S220 public / private key management interface receives the first access policy result from S210. This first access policy result includes the execution direction, application interface module, data format, directory range, and policy weight. The authentication and authorization module first breaks down and organizes the execution direction, application interface module, data format, and directory scope in the access policy. Then, the public and private key management interface performs real-time public and private key invocation processing. The token mechanism serves as a condition for organizing the public and private keys before real-time invocation, and its content includes the token source, token validity status, the application interface module corresponding to the token, and the execution direction corresponding to the token.

[0133] When the result of the first access policy corresponds to a query or download, the authentication and authorization module extracts the token mechanism and execution direction, and writes the execution direction and private key call relationship into the current call record. When it corresponds to sending a data request or uploading, it extracts the token mechanism and application interface module, and writes the application interface module and public key call relationship into the current call record. Subsequently, the public and private key management interface receives the aforementioned call records and performs real-time public and private key calls. Real-time calling means that the public and private key management interface does not pre-fix the output of public and private keys, but instead extracts the currently available public or private key immediately after the current first access policy result enters, based on the execution direction, data format, and application interface module.

[0134] To quantify the degree of key matching in real-time calls, formula ② is introduced to calculate the key call confidence. Formula ② incorporates the policy weights. The system integrates the token validity status, the version difference in the key rotation record, and the key availability under the current execution direction to output a call confidence score, which is used to determine whether the public or private key of the current call meets the security requirements.

[0135] Formula②

[0136]

[0137] Variable and symbol definition:

[0138] : Key retrieval confidence level, value range The closer the value is to 1, the more reliable the current public or private key call. This is calculated using formula ②.

[0139] The policy weights obtained from formula ① take a range of values. (Normalization was applied during actual calculations);

[0140] : The preset maximum weight is 10 (system configuration constant).

[0141] The validity status of the token is extracted by the token mechanism; it is 1 when valid and 0 when invalid.

[0142] The absolute difference between the current key version and the latest rotation version is extracted from the key rotation record. The unit is times, and the value range is non-negative integers.

[0143] : Maximum allowed version difference, with a value of 5 (system configuration constant);

[0144] The key availability flag under the execution direction is determined by the public / private key management interface based on real-time call records; it is set to 1 when available and 0 when unavailable.

[0145] The minus sign and parentheses: indicate minus .

[0146] Data source → Indicators → Variables: Output from formula ① Substitute; extract the valid state using the Token mechanism and record it as... The difference between the current key version and the latest version is extracted from the key rotation record and recorded as follows: The result is determined in real time by the public / private key management interface. .

[0147] Simple numerical example: Input: , Then the first term is 0.55; ; , Then the third item is ; .calculate If the output confidence level is 0.33, which is lower than the threshold of 0.6, then the restricted key access state is triggered.

[0148] The public / private key management interface synchronously reads key generation records, key backup records, key recovery records, and key rotation records, and organizes the records consistent with the current execution direction into key version relationships. If a public key is missing, a private key is missing, the token mechanism fails, the key rotation record is not updated, or the key recovery record is incomplete during real-time calls, the public / private key management interface writes the abnormal state to the operation log and marks the current call result as a restricted key call state. After the above processing, the public key, private key, key version, key rotation result, and current call state are uniformly organized into a first key identifier result. This first key identifier result serves as the input to S230 and corresponds to the encryption, private key decryption, data hashing, and digital signature call relationships in subsequent S320 and S330, respectively.

[0149] This section summarizes the technical effects: By using formula ②, this section integrates policy weight, token validity, and key version difference into a call confidence score, achieving dynamic quantitative evaluation of real-time public and private key calls. This ensures that key calls are not statically configured but are matched instantly with the policy results, enhancing the security and flexibility of key management.

[0150] Furthermore, the S230 data access module receives the first key identification result from S220. This first key identification result includes the execution direction correspondence, public key call relationship, private key call relationship, key version relationship, and call confidence level. The data access module organizes the application interface module, target server address, service interface, API interface, and FTP directory into a single access relationship. The mapping process is not a simple address binding, but rather it maps the key call relationships already determined in the first key identification result to the application interface module, target server address, service interface, API interface, and FTP directory one-to-one.

[0151] When the execution direction is to send a data request, the data access module reads the application interface module and the service interface, maps them to the target server address, and then merges this mapping with the public key call relationship. When the execution direction is to query, it reads the service interface and the target server address, and merges this mapping with the private key call relationship. When the execution direction is to upload, it reads the application interface module, the file path, and the FTP directory, and merges this mapping with the public key call relationship. When the execution direction is to download, it reads the directory and the FTP directory, and merges this mapping with the private key call relationship. During the mapping process, the data access module also checks whether there is an existing mapping between the application interface module and the target server address, and checks whether the FTP directory and the target directory are consistent, and writes the check results to the operation log.

[0152] To quantify the reliability of the mapping path, formula ③ is introduced to calculate the overall matching degree of the mapping path. Formula ③ will call the confidence score. Consistency of existing correspondences in address mapping Directory consistency and key version relationship Perform weighted fusion and output the mapping path matching degree to determine whether to adopt the current mapping path or downgrade to a restricted path.

[0153] Formula③

[0154]

[0155] Variable and symbol definition:

[0156] : Mapping path matching degree, value range A higher value indicates a more reliable mapping path. This is calculated using formula ③.

[0157] Weighting coefficients, satisfying This value is preset by the system. Example of a specific value: ;

[0158] The confidence score for key retrieval obtained from formula ② has a range of values. ;

[0159] The consistency of the existing correspondence between the application interface module and the target server address is obtained by the data access module checking historical mapping records; a value of 1 is used if consistent and 0 is used if inconsistent.

[0160] The consistency between the FTP directory and the requested directory is checked by the data access module; a value of 1 is assigned if they are consistent, and 0 is assigned if they are inconsistent.

[0161] : Key version relationship matching degree, obtained by normalizing the key version relationship in the first key identification result, with a value of Specific calculation method: ,in Due to version differences, The maximum allowed version difference (taken as 5);

[0162] plus sign : Addition operation, representing the weighted sum of four terms.

[0163] Data source → Indicators → Variables: Output from formula ② Substitute; the data access module checks the mapping record between the application interface module and the target server address to obtain... The data access module checks the FTP directory against the requested directory to obtain the data. ; obtained from the key version relationship (such as version difference inverse normalization) in the first key identification result. .

[0164] Simple numerical example: Input: , , , Weight .but If the output matching degree is 0.692, which is higher than the threshold of 0.5, then the complete mapping path will be used.

[0165] Engineering Example: A third-party application initiates a data transmission request in XML format via a service interface. The data access module first reads the public key call relationship from the first key identification result, then reads the application interface module "api_gateway" and the service interface "soap_service", and calculates the mapping path matching degree using formula ③. If the value exceeds the threshold, the public key call relationship is mapped to the target server address "https: / / target.backend.com / xml", forming a data request mapping path. Simultaneously, the data access module performs a historical query on the existing mapping relationship between the application interface module and the target server address, finding a corresponding record. FTP directories are not involved. The default value is 1. After the mapping is completed, the mapping path is written to the operation log, and the first mapping processing result is generated.

[0166] If an application interface module is missing, the target server address is not registered, the service interface is mismatched, the API interface is mismatched, or the FTP directory does not exist during the mapping process, the data access module writes the abnormal status to the operation log and retains the existing mapping portion for the subsequent data conversion and cleaning module to continue processing according to the restricted path. After mapping processing, the platform audit layer obtains the first mapping processing result. This first mapping processing result includes the correspondence between application interface modules, target server addresses, service interfaces, API interfaces, and FTP directories, as well as the matching key call relationships. This result serves as the input to S310, crosses the main step to enter S300, and is used by the XML / JSON parsing library for processing, structured and unstructured data conversion, and subsequent data request, upload, query, and download calls.

[0167] This section summarizes the technical effects: By using formula ③, this section integrates call confidence, address consistency, directory consistency, and key version relationship into a mapping path matching degree, achieving quantitative evaluation of address mapping with key call relationships. Different execution directions correspond to different mapping chain structures (send / query / upload / download), allowing the mapping to simultaneously determine the route, key, and execution direction, unlike the pure address routing mapping method in existing technologies.

[0168] Step S300 includes at least steps S310-S330:

[0169] S310. Obtain the first mapping processing result, perform XML (Extensible Markup Language) / JSON (JavaScript Object Notation) parsing library processing, and perform inter-conversion processing between structured data and unstructured data to obtain the first data to be processed.

[0170] Specifically, the first mapping processing result comes from S230. The first mapping processing result already includes the correspondence between the application interface module, the target server address, the service interface, the API interface and the FTP directory, as well as the public key call relationship, private key call relationship, directory relationship and operation log relationship bound to it. Therefore, in this step, the data conversion and cleaning module directly receives the first mapping processing result and enters the corresponding data conversion path around the current execution direction.

[0171] The data conversion and cleaning module is a processing unit between the platform audit layer and the data access module. It consists of an XML / JSON parsing library, a format unification processing area, a field naming unification processing area, and a file path processing area.

[0172] The XML / JSON parsing library is used to read the field structure, hierarchical relationships, and directory correspondences in XML or JSON data formats. The structured data is data content with fixed fields, fixed hierarchies, or fixed directory relationships.

[0173] The unstructured data refers to data that does not have fixed field names, does not have a unified hierarchy, or is directly entered as file content.

[0174] During runtime, the data conversion and cleaning module first reads the data format from the first mapping processing result. When the data format is XML, the XML / JSON parsing library reads the tag content, node relationships, and node positions in node order, and maps the node positions to the application interface module, target server address, or FTP directory.

[0175] When the data format is JSON, the XML / JSON parsing library reads the key-value pairs, field levels, and field names in field order, and maps the field levels to service interfaces, API interfaces, or directories. When the data format is a file, the data transformation and cleaning module does not directly expand all fields of the file content. Instead, it first reads the file path, directory, and source of the file content, and then classifies the file content into unstructured data paths.

[0176] Furthermore, the data transformation and cleaning module determines the conversion method based on the current execution direction. When the current execution direction corresponds to sending a data request, structured data retains its structured data path, with only field hierarchy and field names being processed. When the current execution direction corresponds to uploading, file path and directory are prioritized, and the file content is processed into the unstructured data path before uploading. When the current execution direction corresponds to querying or downloading, the XML / JSON parsing library first establishes the location to read the returned content, and then converts the returned content into the required structured data path for subsequent formats.

[0177] In an engineering implementation scenario, a third-party application sends a data request in JSON format to the target server address via an API interface. The data conversion and cleaning module first reads the API interface correspondence from the first mapping processing result, and then the XML / JSON parsing library extracts the JSON field names, field levels, and field order, and organizes the correspondence of the same field name in different application interface modules into a unified record.

[0178] In another engineering implementation scenario, the external network system processes file downloads via the FTP protocol. The data conversion and cleaning module first reads the FTP directory and file path, then assigns the file content in the directory to the unstructured data path, and simultaneously creates a corresponding directory record for subsequent format recovery. If an XML node is missing, a JSON field is missing, a file path is missing, the directory is inconsistent, or the target server address is inconsistent with the application interface module, the data conversion and cleaning module writes the abnormal status to the operation log, retains the existing parsing results and conversion results, and continues to output.

[0179] After processing by the XML / JSON parsing library and the conversion between structured and unstructured data, the resulting data is recorded as the first data to be processed. This first data to be processed serves as the input for "first data to be processed" in S320. Furthermore, the field hierarchy, directory correspondence, and file path records within this first data to be processed will be retrieved again during the format restoration process in S330.

[0180] S320. Based on the first data to be processed, perform format unification, field naming unification, encryption, format preservation encryption, data hashing, digital signature, and data request or upload processing to obtain the first upload result.

[0181] Specifically, after the first data to be processed enters this step, it is processed collaboratively by the data conversion and cleaning module and the data encryption and desensitization module. The format unification involves organizing the content of XML, JSON, and files into the same processing order, ensuring consistency in the read location when calling service interfaces, API interfaces, and FTP directories. The field naming unification involves unifying the different field names for the same business content across different application interface modules, service interfaces, or API interfaces into a single field name.

[0182] The encryption is performed on the current first data to be processed according to the public key call relationship in the first key identification result, using the corresponding processing path of public key encryption, AES encryption algorithm, 3DES encryption algorithm, RSA encryption algorithm, or ECC encryption algorithm. The format-preserving encryption is performed on data content that needs to retain its original field arrangement and original directory position after the field naming is unified. The data hash is calculated by using the SHA-256 hash function to calculate the hash value corresponding to the content to be sent or uploaded. The digital signature is generated by mapping the current data hash to the public key call relationship or digital certificate.

[0183] During runtime, the data transformation and cleaning module first performs format unification according to the application interface module and the data format. XML data is formatted in a unified node order after unification. JSON data is formatted in a unified field order. Files are formatted in a unified directory order and a unified file path order.

[0184] Subsequently, the unified field naming processing area compares the XML node names, JSON field names, and file directory names, and organizes the different names of the same business content in different interfaces into a unified field naming record.

[0185] After completing the above processing, the data encryption and desensitization module receives the unified data content and reads the first key identification result output by S220.

[0186] If the current execution direction corresponds to sending a data request, the unified structured data will be encrypted, hashed, and digitally signed first, and then the data request will be sent to the target server address via the service interface or API interface. If the current execution direction corresponds to uploading, the unified file content will be encrypted to preserve its format, hashed, and digitally signed first, and then the upload process will be performed via the FTP directory.

[0187] Understandably, in HTTP or HTTPS scenarios, sending a data request is not limited to submitting the data body; it also includes writing the interface parameters, field naming records, and data hashes before the query into the service interface call content. In FTP scenarios, the upload process not only writes the file content but also simultaneously writes the directory mapping, file path mapping, and digital signature records.

[0188] Furthermore, this step also handles abnormal situations. In cases of failure to unify field naming, missing data hashes, missing digital signature records, unresponsive target server addresses, unavailable service interfaces, unavailable API interfaces, or unwritable FTP directories, the data encryption and desensitization module and the data access module will write the abnormal status, current hash value, and current digital signature status to the operation log, and output the current processing result according to the restricted sending or restricted upload status.

[0189] In a real-world engineering scenario, a third-party application sends a data request in XML format to the target server address via HTTPS. The data conversion and cleaning module first organizes the XML node order into a unified node order, then organizes the node names into a unified field naming. After that, the data encryption and desensitization module performs public key encryption based on the first key identification result, generates a hash value and a digital signature, and sends the data request through the service interface.

[0190] In another practical engineering scenario, when an external network system uploads files via an FTP directory, the data conversion and cleaning module first sorts the directory order and file path order, and then the data encryption and desensitization module performs format preservation encryption, data hashing and digital signature, before writing the files to the FTP directory.

[0191] After the above processing, the content generated by the data request or upload process is recorded as the first upload result. The first upload result serves as the input for "first upload result" in S330, and its hash value, digital signature record, and operation log record will also be processed by the audit management interface in S400 across the main steps.

[0192] S330. Based on the first upload result, perform query, download, private key decryption, timestamp verification, digital signature verification and format recovery processing to obtain the first bidirectional processing result.

[0193] Specifically, after the first upload result is sent as input for this step, the protocol proxy engine, data encryption and desensitization module, and data conversion and cleaning module work together in the current execution direction. The query is a processing action initiated by the service interface or API interface to read the returned content from the target server address. The download is a processing action initiated by the FTP directory to read the file content from the file path.

[0194] The private key decryption is performed by the data encryption and desensitization module based on the private key call relationship in the first key identification result, decrypting the returned or downloaded content using the private key. The timestamp verification compares the timestamp in the returned content with the time record in the current operation log. The digital signature verification compares the digital signature in the returned content with the aforementioned data hash and digital certificate records.

[0195] The format restoration is achieved by the data conversion and cleaning module restoring the content, which has been decrypted by the private key, verified by the timestamp, and verified by the digital signature, into the data format required by the caller.

[0196] During runtime, when the first upload result corresponds to the returned content after sending a data request, the protocol proxy engine first queries the target server address, reads the returned content, and then hands it over to the data encryption and desensitization module to perform private key decryption. Then, it verifies the timestamp and digital signature in the returned content. After verification, the data conversion and cleaning module performs format restoration according to XML data format, JSON data format, or file path record.

[0197] When the first upload result corresponds to the file receipt or directory read trigger content, the protocol proxy engine first downloads the file to the FTP directory, then sends the downloaded content to the data encryption and desensitization module for private key decryption and digital signature verification. After that, the data conversion and cleaning module performs format restoration according to the file path, directory order, and field naming records.

[0198] Furthermore, format restoration is not simply restoring the original content, but rather reading the field hierarchy, directory correspondence, and file path records formed in S310, and restoring them to the data format required by the requester while satisfying the correspondence between the current application interface module and service interface.

[0199] If the currently returned content corresponds to JSON data format, the data conversion and cleaning module restores the JSON structure according to the unified field names; if the currently returned content corresponds to XML data format, the XML structure is restored according to the unified node order; if the currently returned content corresponds to a file, the file content association is restored according to the directory order and file path.

[0200] In terms of exception handling, if the query returns no content, the download has no directory content, the private key call fails, the timestamp verification is inconsistent, the digital signature verification is inconsistent, or a field is missing during the format recovery process, the protocol proxy engine writes the exception status to the operation log, the data encryption and desensitization module retains the current verification status, the data conversion and cleaning module retains the current format recovery status, and writes the status along with the returned content into the first bidirectional processing result.

[0201] In a complete engineering implementation scenario, a third-party application initiates a JSON data format query through a service interface. The S320 has already completed sending the data request, data hashing, and digital signature processing. In this step, the protocol proxy engine reads the returned content from the target server address, the data encryption and desensitization module performs decryption using a private key, and then performs verification based on the timestamp and digital signature. Finally, the data conversion and cleaning module restores the JSON structure according to the unified field names and returns it to the requester.

[0202] In another complete engineering implementation scenario, the external network system initiates a download via the FTP directory. The protocol proxy engine reads the file content from the FTP directory, the data encryption and desensitization module performs private key decryption and digital signature verification, and the data conversion and cleaning module performs format restoration according to the directory order and file path, and returns the restored file content to the requester.

[0203] After the aforementioned query, download, private key decryption, timestamp verification, digital signature verification, and format restoration processes, the resulting data is recorded as the first bidirectional processing result. This first bidirectional processing result serves as the input to the "first bidirectional processing result" in S410 and is used by the audit management interface in S400 for access policies, data hashing, timestamps, digital signatures, operation logs, and processing result organization.

[0204] In summary, this step integrates querying and downloading into the return chain, placing private key decryption, timestamp verification, digital signature verification, and format restoration in the same processing order, forming a reverse processing chain corresponding to the data request or upload. Compared to existing technologies that only perform unified encryption on the transmission chain, this step incorporates the returned content, downloaded content, and format restoration into the same bidirectional execution process. The platform audit layer, data encryption and desensitization module, and data conversion and cleaning module operate continuously around the same initial upload result and the same initial bidirectional processing result.

[0205] Step S400 includes at least steps S410-S430:

[0206] S410. Obtain the first bidirectional processing result, and perform audit management interface access policy, data hash, timestamp, digital signature, operation log and processing result sorting and processing to obtain the first agent control chain result.

[0207] Specifically, the first bidirectional processing result comes from S330. The first bidirectional processing result already includes the returned content after querying, downloading, private key decryption, timestamp verification, digital signature verification, and format restoration. At the same time, it retains the operation logs corresponding to the data request result, upload result, query result, download result, and return requester result. Therefore, this step is directly received by the audit management interface in the platform audit layer.

[0208] The audit management interface is an interface unit in the platform's audit layer used to organize, associate, and write access policies, data hashes, timestamps, digital signatures, operation logs, and processing results into the control chain record.

[0209] The access policy is not regenerated in this step. Instead, the first access policy result formed in S210 is invoked and realigned with the correspondences of execution direction, application interface module, target server address, service interface, API interface, and FTP directory in the first bidirectional processing result. The data hash is the hash value record formed in S320. The timestamp includes the time records of each processing node for querying, sending data requests, uploading, downloading, and returning to the requester.

[0210] The digital signature includes a digital signature record formed before sending a data request and a verification status record after querying or downloading to complete digital signature verification.

[0211] The operation log includes processing traces formed during protocol identification, execution direction extraction, identity authentication, authorized access, real-time public and private key invocation, mapping, XML / JSON parsing library processing, structured and unstructured data conversion, format unification, field naming unification, encryption, format preservation encryption, querying, downloading, and format recovery. The processing results include at least one of the following: data request sending result, upload result, query result, download result, and result returned to the requester.

[0212] During runtime, the audit management interface first reads the execution direction from the first bidirectional processing result and organizes it into query chains, data request chains, upload chains, and download chains. When the execution direction is query, the audit management interface first retrieves the corresponding first access policy result, then retrieves the data hash, timestamp, digital signature verification status, and operation log during the query process, and writes them into the query organization area.

[0213] When the execution direction is to send a data request, the audit management interface first retrieves the access policy corresponding to the data request, then retrieves the digital signature, hash value, and target server address mapping before sending the data request, and writes them into the data request processing area. When the execution direction is to upload or download, the audit management interface further reads the FTP directory, file path, and directory mapping, and puts the directory processing trace, timestamp, and digital signature status into the directory processing area.

[0214] Furthermore, the audit management interface also verifies whether the access policy is consistent with the current processing result. For example, if the first access policy result only allows queries, but the first bidirectional processing result shows an upload result, the inconsistent state is written to the operation log, and an exception marker is added to the current processing result; if the digital signature verification has been completed but the timestamp record is missing, the missing state is written to the operation log, and the existing hash value and digital signature record are retained.

[0215] Understandably, in one practical engineering embodiment, after a third-party application initiates a JSON data format query through the service interface and obtains the returned requester result, the audit management interface will compile the first access policy result, hash value, timestamp, digital signature verification status, operation log, and returned requester result corresponding to the query into the same compilation record; in another practical engineering embodiment, after an external network system downloads a file through an FTP directory and completes the format restoration, the audit management interface will compile the FTP directory, file path, download result, timestamp, digital signature verification status, and operation log into the same directory compilation record.

[0216] After the above processing, the audit management interface associates the access policy, data hash, timestamp, digital signature, operation log and processing result according to the execution direction to form the first proxy control chain result, and uses the first proxy control chain result as the input of "first proxy control chain result" in S420. At the same time, the first proxy control chain result also serves as the basic call content for subsequent blockchain layer recording or verification and rule engine verification.

[0217] S420. Based on the result of the first agent control chain, perform blockchain layer recording or verification, rule engine verification and effective time sorting to obtain the updated access policy result.

[0218] Specifically, after the result of the first agent control chain enters this step, it is jointly executed by the blockchain layer, the blockchain storage interface, the audit management interface, and the rule engine.

[0219] The blockchain layer is a distributed ledger recording layer connected to the platform audit layer. The blockchain storage interface is an interface unit used to submit data hashes, timestamps, digital signatures, operation logs, and processing results from the first agent control chain to the blockchain layer. The rule engine is a processing unit that verifies the correspondence between access policies, application interface modules, target server addresses, service interfaces, API interfaces, and FTP directories.

[0220] The effective time is a record of the time when the updated access policy result is processed for subsequent calls. During runtime, the audit management interface first extracts the data hash, timestamp, digital signature, and processing result digest from the first agent control chain result, and then executes blockchain layer recording or verification through the blockchain storage interface. When executing blockchain layer recording, the blockchain storage interface packages the data hash, timestamp, digital signature, and processing result digest into record content according to the current execution direction, and sends it along with the operation log index to the blockchain layer.

[0221] When performing blockchain layer verification, the blockchain layer reads the corresponding data hash, timestamp, and digital signature record from the existing distributed ledger and compares it with the record in the current first agent control chain result. If the comparison is consistent, the consistent status is returned to the audit management interface; if the comparison is inconsistent, the inconsistent status is written to the operation log and sent to the rule engine.

[0222] Furthermore, after receiving the status return from the blockchain layer, the rule engine does not simply determine whether the record passes or fails, but continues to verify the correspondence between the access policy and the application interface module, target server address, service interface, API interface, and FTP directory. If the processing result in the current first proxy control chain is inconsistent with the original access policy, the rule engine writes this inconsistent state into the verification record and marks the current access policy as an access policy to be updated; if the current processing result is consistent with the original access policy, the rule engine retains the existing access policy and writes it into the stable state record.

[0223] Subsequently, the audit management interface compiles the effective time based on the verification records output by the rules engine. This effective time is not an independently generated arbitrary time, but rather corresponds to the timestamp in the current operation log and the record time returned by the blockchain layer.

[0224] Specifically, when the rules engine outputs the status of the access policy to be updated, the audit management interface reorganizes the current blockchain layer record completion time into a new effective time; when the rules engine outputs a stable status, the audit management interface reorganizes the current blockchain layer verification completion time into a continuous effective time.

[0225] Understandably, in actual engineering implementation, if a third-party application sends a data request via the API interface, and the blockchain layer verifies that the target server address corresponding to the current processing result has changed, the rule engine marks the target server address correspondence as pending update, and the audit management interface organizes the record time corresponding to the change into a new effective time. If an external network system downloads a file via an FTP directory, and the blockchain layer verifies that the current FTP directory and access policy are consistent, the rule engine retains the existing access policy and organizes the current verification time into a continuously effective time.

[0226] After being recorded or verified by the blockchain layer, validated by the rule engine, and processed by the effective time, the resulting data is recorded as the updated access policy result. This updated access policy result serves as the input to "Updated Access Policy Result" in S430, and also provides an updated basis for invocation to the authentication management interface's identity authentication and authorization module's access authorization processing in S210.

[0227] S430. Based on the updated access policy results, update the application interface module mapping relationship, FTP directory mapping relationship and operation log to obtain the updated mapping processing results.

[0228] Specifically, after the updated access policy result enters this step, the update process is jointly performed by the audit management interface, the data access module, and the application interface module.

[0229] The application interface module mapping relationship is the correspondence between the application interface module and the target server address, service interface, and API interface.

[0230] The FTP directory mapping relationship is the correspondence between directories, file paths, and FTP directories. The operation log update process involves writing the current blockchain layer record or verification status, rule engine verification status, effective time, and updated access policy result into the operation log and replacing the original corresponding index. During runtime, the audit management interface first reads the effective time, verification status, and access policy changes from the updated access policy result, and then sends it to the data access module. The data access module determines, based on the access policy changes, whether to update the application interface module mapping relationship, the FTP directory mapping relationship, or both.

[0231] When the access scope of the service interface or API interface corresponding to the updated content changes, the data access module reorganizes the mapping relationships between the application interface module, target server address, service interface, and API interface, and retains the original mapping relationships as historical mapping records. When the upload or download directory range corresponding to the updated content changes, the data access module reorganizes the mapping relationships between the directory, file path, and FTP directory, and retains the original directory mapping relationships as historical directory records. Furthermore, the audit management interface writes the blockchain layer record status, rule engine verification status, effective time, changes in application interface module mapping relationships, changes in FTP directory mapping relationships, and the current processing results involved in this update process into the operation log.

[0232] Understandably, if the updated access policy results show that the target server address of a certain API interface has changed, the data access module will replace the new target server address with the mapping address of the current application interface module after the effective time arrives, and write the old address and replacement time into the operation log; if the updated access policy results show that a certain FTP directory has been adjusted, the data access module will write the new FTP directory relationship into the current directory mapping relationship after the effective time arrives, and write the original directory, the current directory and the corresponding file path into the operation log.

[0233] Furthermore, to maintain the continuous operation of this method, the updated mapping processing result will not remain in this step, but will be reread by the platform audit layer when a new data request arrives, and will be called by the data access module, application interface module, target server address, service interface, API interface and FTP directory mapping processing in S230, and will serve as the basis for updating the input before the formation of the first mapping processing result in S310.

[0234] If, during the update process, issues arise such as the inability to replace application interface module mappings, FTP directory mappings, effective time conflicts, or operation log writing failures, the audit management interface retains the original mappings, writes the abnormal status and the current updated access policy result into the operation log, and outputs the updatable portion. The data generated after the application interface module mapping, FTP directory mapping, and operation log updates is recorded as the updated mapping processing result. This updated mapping processing result serves as the update basis for the S230 mapping processing call when subsequent data requests enter the platform audit layer. Furthermore, the operation log continuously connects the blockchain layer record or verification, rule engine verification, and mapping update to the next query, data request, upload, or download processing chain.

[0235] In summary, this step directly embeds the updated access policy results, recorded or verified at the blockchain layer, into the application interface module mapping and FTP directory mapping relationships. This ensures that changes in access policies and mapping relationships are transmitted within the same processing chain. Compared to the existing technology's separation of recording and mapping, this step continuously connects the blockchain layer, rule engine, data access module, and operation logs, forming a traceable and updatable closed-loop proxy control chain.

[0236] Example 2: Figure 2 This diagram illustrates a structural block diagram of a blockchain encrypted proxy method based on HTTP and FTP protocols according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0237] The protocol proxy engine module 01 receives data requests initiated by third-party applications, service interfaces, application programming interfaces (APIs), or external network systems. It identifies the data requests using Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTP), or File Transfer Protocol (LTP), extracts the execution direction corresponding to querying, sending data requests, uploading, or downloading, and extracts the application interface module, file path, directory, data format, user attributes, role permissions, and authorized access status. Specifically, upon receiving a data request from a third-party application, service interface, API, or external network system, the module first establishes a current request session based on the access source, and then reads the protocol field, interface field, and directory field from the current request session. The module identifies HTTP, HTTP, and LTP, and writes incomplete requests, empty directory requests, and requests with missing interface fields to the operation log. After protocol identification, the module extracts the execution direction corresponding to querying, sending data requests, uploading, or downloading based on the request content, and then extracts the application interface module, file path, directory, data format, user attributes, role permissions, and authorized access status from the current request session. The data format includes structured data, unstructured data, data content corresponding to Extensible Markup Language (XML), and object representation. The protocol proxy engine module organizes the protocol identification result, execution direction extraction result, and request feature extraction result into a first request feature result, and provides this first request feature result to the authentication management interface module as authentication input. Simultaneously, it provides the execution direction and application interface module to the authentication authorization module for subsequent authorization access calls, and retains the current operation log for the audit management interface and blockchain layer module to read.

[0238] The authentication management interface module 02 is used to receive the user attributes, role permissions, and authorized access status, perform identity authentication, and output the authentication result. Specifically, the authentication management interface module receives the first request feature result output by the protocol proxy engine module, reads the user attributes, role permissions, and authorized access status from it, and establishes an authentication context according to the current execution direction. The authentication management interface module compares the access source, directory relationship, and application interface module relationship in the user attributes, verifies the query permission, data request sending permission, upload permission, and download permission in the role permissions, and organizes the registered status and abnormal status in the authorized access status. During the identity authentication process, the authentication management interface module writes unregistered user attributes, inconsistent role permissions, and missing authorized access status into the operation log and retains the current request session. The authentication management interface module records the authentication conclusion formed by identity authentication as the identity authentication result, sends the identity authentication result to the authentication authorization module as authorized access input, and simultaneously passes the authentication status index to the audit management interface and blockchain layer module for subsequent recording or verification calls.

[0239] The authentication and authorization module 03 receives the authentication result, the execution direction, and the application interface module. It then uses a token mechanism to authorize access, generates an access policy, and sends the access policy to the public / private key management interface module, the data access module, the audit management interface, and the blockchain layer module. Specifically, the authentication and authorization module receives the authentication result from the authentication management interface module and the execution direction and application interface module from the protocol proxy engine module. It then reads the token mechanism corresponding to the current request session. The token mechanism includes the token source, token status, and the relationship between the token and the corresponding application interface module. The authentication and authorization module processes the authentication result according to the execution direction. When the execution direction is query, the authentication and authorization module generates a query access policy. When the execution direction is sending a data request, the authentication and authorization module generates a data request access policy. When the execution direction is upload or download, the authentication and authorization module incorporates the directory, file path, and authorized access status into the processing, generating an upload access policy or a download access policy. The authentication and authorization module writes the status of token invalidation, application interface module mismatch, and authorized access scope exceeding the limit into the operation log. The authentication and authorization module records the processed policy results as an access policy, and sends the access policy to the public and private key management interface module as key call input, to the data access module as mapping processing input, and to the audit management interface and blockchain layer module as recording or verification input.

[0240] The public-private key management interface module 04 is used to receive the access policy, perform real-time public and private key calls, key generation, key backup, key recovery, and key rotation, and output a key identifier. Specifically, the public-private key management interface module receives the access policy from the authentication and authorization module and reads the corresponding public key call relationship or private key call relationship according to the execution direction and application interface module. The public-private key management interface module organizes private key call records in the query and download paths, organizes public key call records in the data request and upload paths, and reads the historical records corresponding to key generation, key backup, key recovery, and key rotation. The public-private key management interface module writes the key missing state, key rotation incomplete state, and key recovery incomplete state into the operation log, and binds the current call state with the access policy. The public-private key management interface module organizes the public key call result, private key call result, key rotation result, and current call state into a key identifier, outputs the key identifier to the data access module as the input for mapping processing, and provides the key identifier to the data encryption and desensitization module for subsequent encryption, private key decryption, timestamp verification, and digital signature verification calls.

[0241] Data access module 05 is used to receive the key identifier and the application interface module, map the target server address, service interface, application programming interface, and file transfer directory, and output the mapping processing result. Specifically, the data access module receives the key identifier from the public / private key management interface module, and receives the application interface module, execution direction, file path, and directory from the authentication and authorization module and the protocol proxy engine module. The data access module establishes a mapping processing path according to the current execution direction. When the execution direction is to send a data request, the data access module establishes a correspondence between the application interface module, service interface, and target server address, and writes the public key call relationship. When the execution direction is to query, the data access module establishes a correspondence between the service interface and target server address, and writes the private key call relationship. When the execution direction is to upload, the data access module establishes a correspondence between the application interface module, file path, and file transfer directory, and writes the public key call relationship. When the execution direction is to download, the data access module establishes a correspondence between the directory, file path, and file transfer directory, and writes the private key call relationship. The data access module writes the target server address missing status, service interface mismatch status, application programming interface missing status, and file transfer directory mismatch status into the operation log, and retains the current mapping path. The data access module organizes the mapped interface relationships, directory relationships, and key call relationships into a mapping processing result, outputs the mapping processing result to the data conversion and cleaning module as input for generating data to be processed, and simultaneously provides the mapping index and current operation log to the audit management interface and the blockchain layer module.

[0242] The data conversion and cleaning module 06 receives the mapping processing results, performs parsing library processing, converts between structured and unstructured data, unifies formats, unifies field naming, and restores formats, outputting the data to be processed and the restored data. Specifically, the data conversion and cleaning module receives the mapping processing results from the data access module and first selects the parsing library processing path according to the data format and execution direction. The parsing library processing performs field reading, hierarchical reading, and path reading for data content corresponding to Extensible Markup Language and Object Representation. The data conversion and cleaning module performs mutual conversion between structured and unstructured data, unifies formats and unifies field naming for data content that needs to be transmitted through service interfaces and application programming interfaces, and organizes directory order and file paths for data content that needs to be processed through file transfer directories. In the return link, the data conversion and cleaning module receives decrypted data from the data encryption and desensitization module, restores the format of the current data content, and restores it to the restored data according to the original mapping relationship. The data conversion and cleaning module writes field missing status, hierarchical mismatch status, directory conflict status, and format restoration abnormal status into the operation log. The data conversion and cleaning module records the data content formed by the sending chain and the uploading chain as data to be processed, and sends the data to be processed to the data encryption and desensitization module as input for encryption, data hashing, and digital signature; it records the data content formed by the query chain and the download chain as restored data, and sends the restored data to the protocol proxy engine module for the requester to call, and at the same time provides the audit management interface and the blockchain layer module with unified format records, unified field naming records, and format restoration records.

[0243] The data encryption and desensitization module 07 receives the key identifier and the data to be processed, performs encryption, format-preserving encryption, data hashing, digital signature, private key decryption, timestamp verification, and digital signature verification, and cooperates with the protocol proxy engine module to complete data sending requests, uploading, querying, and downloading. Specifically, the data encryption and desensitization module receives the key identifier from the public / private key management interface module and the data to be processed from the data conversion and cleaning module, and processes them according to the sending chain, uploading chain, querying chain, and downloading chain respectively. In the sending chain, the data encryption and desensitization module performs encryption, format-preserving encryption, data hashing, and digital signature on the data to be processed, and hands over the processed data sending request content to the protocol proxy engine module, which then completes the data sending request through the target server address, service interface, or application programming interface. In the uploading chain, the data encryption and desensitization module performs format-preserving encryption, data hashing, and digital signature on the data to be processed, and then hands over the processed upload content to the protocol proxy engine module, which then completes the upload through the file transfer directory. In the query chain and download chain, after the protocol proxy engine module reads the returned content from the target server address or file transfer directory, it hands the reading result over to the data encryption and desensitization module. The data encryption and desensitization module performs private key decryption, timestamp verification, and digital signature verification, and sends the verified data content to the data conversion and cleaning module for format restoration. The data encryption and desensitization module writes hash inconsistency, digital signature abnormality, private key call abnormality, and timestamp abnormality into its operation log. The data encryption and desensitization module provides the processing results formed by the sending chain and upload chain to the protocol proxy engine module, provides the verification results formed by the query chain and download chain to the data conversion and cleaning module, and provides the data hash, timestamp, digital signature, and current processing result to the audit management interface and the blockchain layer module.

[0244] The audit management interface and blockchain layer module 08 is used to receive the access policy, data hash, timestamp, digital signature, operation log, and processing result, and to perform recording or verification, rule engine verification, effective time organization, and application interface module mapping relationship, file transfer directory mapping relationship, and operation log update. Specifically, the audit management interface and blockchain layer module receives the access policy from the authentication and authorization module, the data hash, timestamp, digital signature, and processing result from the data encryption and desensitization module, and the operation log from the protocol proxy engine module, the authentication management interface module, the public / private key management interface module, the data access module, and the data transformation and cleaning module. The audit management interface and blockchain layer module first organizes the access policy, data hash, timestamp, digital signature, operation log, and processing result according to the execution direction, and then executes the recording or verification through the blockchain layer. In the recording state, the audit management interface and blockchain layer module writes the data hash, timestamp, digital signature, processing result summary, and operation log index into the blockchain layer. In the verification state, the audit management interface and blockchain layer module reads existing records from the blockchain layer and compares them with the current record. After receiving the record status or verification status, the rule engine verifies the access policy, application interface module mapping relationship, and file transfer directory mapping relationship, and submits the verification result to the effective time processing path. The audit management interface and blockchain layer module, based on the verification result and effective time, update the application interface module mapping relationship and file transfer directory mapping relationship that need to be changed, and update the corresponding operation logs. The audit management interface and blockchain layer module send the updated access policy to the authentication and authorization module for subsequent request sessions to use; send the updated application interface module mapping relationship and file transfer directory mapping relationship to the data access module for subsequent mapping processing to use; and send the updated operation log index to the protocol proxy engine module to maintain the continuity between the next request session and the current record status.

Claims

1. A blockchain encrypted proxy method based on HTTP and FTP protocols, characterized in that, include: S100: Obtain the data request received by the protocol proxy engine, perform protocol identification processing, execution direction extraction processing and request feature extraction processing, and obtain the first request feature result; The data requests received by the protocol proxy engine include data requests initiated by third-party applications, service interfaces, or external network systems. S200. Based on the first request feature result, perform identity authentication and authorized access processing, real-time public / private key retrieval processing, and address mapping processing with key relationships to obtain the first mapping processing result; specifically including: S210. Obtain the first request feature result, perform identity authentication of the authentication management interface and authorization access processing of the authentication authorization module, and obtain the first access strategy result; S220. Based on the result of the first access policy, perform token mechanism sorting, real-time public key and private key invocation processing to obtain the first key identification result; S230. Based on the first key identification result, perform mapping processing on the data access module, application interface module, target server address, service interface and FTP directory to obtain the first mapping processing result; S300. Based on the first mapping processing result, perform sending or uploading chain processing and querying or downloading chain processing to obtain a first bidirectional processing result; specifically including: S310. Obtain the first mapping processing result, perform XML / JSON parsing library processing, and convert between structured and unstructured data to obtain the first data to be processed; S320. Based on the first data to be processed, perform format unification, field naming unification, encryption, data hashing, digital signature, and data request or upload processing to obtain the first upload result. S330. Based on the first upload result, perform query, download, private key decryption, timestamp verification, digital signature verification and format recovery processing to obtain the first bidirectional processing result; S400. Based on the first bidirectional processing result, perform audit management processing, blockchain recording or verification processing, rule engine verification processing, and mapping relationship update processing to obtain the updated mapping processing result; specifically including: S410. Obtain the first bidirectional processing result, and perform audit management interface access policy, data hash, timestamp, digital signature, operation log and processing result processing to obtain the first agent control chain result; S420. Based on the result of the first agent control chain, perform blockchain layer recording or verification, rule engine verification and effective time sorting to obtain the updated access policy result. S430. Based on the updated access policy results, update the application interface module mapping relationship, FTP directory mapping relationship and operation log to obtain the updated mapping processing results.

2. The method according to claim 1, characterized in that, The processes of protocol identification, execution direction extraction, and request feature extraction include: The protocol identification process includes: segmenting and organizing the data request, comparing the interface format of HTTP, HTTPS or FTP protocols, writing the corresponding protocol into the protocol identifier area, performing boundary checks on empty data requests, missing protocol identifiers, service interface mismatches or unknown external network system sources, and incorporating abnormal states into the first data request result. The execution direction extraction process includes: reading the protocol type and service interface correspondence in the first data request result, and determining that the data request belongs to one of query, send data request, upload or download, wherein query and send data request correspond to HTTP or HTTPS protocol, and upload and download correspond to FTP protocol; The request feature extraction process includes: extracting application interface modules, file paths, and directories according to the execution direction, identifying the data format as JSON or XML, organizing user attributes, role permissions, and authorized access status, and then associating and merging the above content as the first request feature result.

3. The method according to claim 2, characterized in that, The process of identity authentication and authorization access includes: The authentication management interface reads user attributes and aligns them with role permissions to generate an identity authentication status. The authentication and authorization module organizes access policies according to the identity authentication status, role permissions, and authorized access status, and generates a first access policy result bound to the execution direction. The execution direction is one of querying, sending data requests, uploading, or downloading, and different directions enter different access policy paths.

4. The method according to claim 3, characterized in that, The process of real-time public / private key access includes: The public and private key management interface organizes the token mechanism based on the results of the first access policy. When the execution direction is query or download, the private key call relationship is extracted. When the execution direction is sending data request or uploading, the public key call relationship is extracted. Then, the public key or private key is called in real time, and the key generation, key backup, key recovery and key rotation records are read synchronously and organized into the first key identification result containing key number, call status, version status and rotation status.

5. The method according to claim 4, characterized in that, The process of address mapping with key relationships includes: The data access module reads the public key call relationship or private key call relationship from the first key identification result; When the execution direction is to send a data request, the application interface module, service interface and target server address are mapped to each other, and then the mapping is merged with the public key call relationship; When the execution direction is a query, a correspondence is established between the service interface and the target server address, and this correspondence is merged with the private key call relationship. When the execution direction is upload, a correspondence is established between the application interface module, file path and FTP directory, and this correspondence is merged with the public key call relationship; When the execution direction is download, a correspondence is established between the directory and the FTP directory. This correspondence is then merged with the private key call relationship to obtain the first mapping processing result.

6. The method according to claim 5, characterized in that, The process of sending or uploading a chain includes: The data conversion and cleaning module first unifies the node order of XML data, the field order of JSON data, and the directory and file path order of files. Then, it unifies the field names of different fields with the same business content in different interfaces, generating unified field naming records. After the format and field naming are unified, the data encryption and desensitization module performs encryption, data hashing, and digital signature based on the public key call relationship in the first key identification result. When the execution direction is to send a data request, it sends the data to the target server address through the service interface. When the execution direction is to upload, it performs upload processing through the FTP directory to obtain the first upload result.

7. The method according to claim 6, characterized in that, The process of querying or downloading a chain includes: After receiving the first upload result, the protocol proxy engine queries the target server address when the corresponding data request is returned, and downloads the corresponding uploaded file receipt or directory read trigger content to the FTP directory. The data encryption and desensitization module first decrypts the returned or downloaded content using the private key, and then verifies the timestamp and digital signature. After verification, the data conversion and cleaning module reads the field hierarchy, directory correspondence, and file path records formed in S310, restores the data to the format required by the caller, and obtains the first bidirectional processing result.

8. The method according to claim 7, characterized in that, The audit management process includes: The audit management interface reads the execution direction from the first bidirectional processing result, organizes it according to the query chain, data request chain, upload chain, or download chain, and calls the first access policy result formed in S210 to realign with the execution direction, application interface module, target server address, service interface, or FTP directory in the first bidirectional processing result. It then associates the data hash, timestamp, digital signature, operation log, and processing result to form the first agent control chain result.

9. The method according to claim 8, characterized in that, The process of blockchain recording or verification includes: The blockchain storage interface extracts data hashes, timestamps, digital signatures, and processing result summaries from the results of the first agent control chain, packages them, and sends them to the blockchain layer for recording, or reads existing records from the blockchain layer and compares them with the current results.

10. The method according to claim 1, characterized in that, The process of rule engine validation and mapping update includes: The rule engine verification process includes: after receiving the status returned by the blockchain layer, the rule engine verifies the correspondence between the access policy and the application interface module, the target server address, the service interface or FTP directory. If they are inconsistent, the current access policy is marked as an access policy to be updated and the effective time is calculated. The mapping update process includes: the audit management interface sends the effective time, verification status, and access policy changes to the data access module; the data access module reorganizes the mapping relationship between the application interface module and the target server address, or reorganizes the mapping relationship between the directory and the FTP directory, and writes the changes to the operation log to obtain the updated mapping processing result.

Images