Cross-network data security interaction method and system

Abstract

This invention relates to the field of data interaction, specifically to a cross-network data security interaction method and system, comprising: obtaining the sensitivity level of a field to be accessed in the directory information corresponding to a data access request; determining the permission level of the field to be accessed; if the permission level is greater than the sensitivity level, obtaining the utility weight and risk weight of the field to be accessed; if the utility weight is greater than or equal to the risk weight, determining that the field to be accessed is an open field; wherein, the encryption level of the open field is less than a preset level threshold, the open field is temporarily encrypted to obtain encrypted access data, and the encrypted access data is sent to the sending end. This invention, by determining that a field is an open field when the utility weight is greater than or equal to the risk weight, and by only temporarily or lightly encrypting data marked as open fields, rather than uniformly using high-strength encryption, significantly reduces the computational overhead and transmission latency of encryption and decryption.

Description

Technical Field

[0001] This invention relates to the field of data interaction technology, and in particular to a cross-network data security interaction method and system. Background Technology

[0002] In existing technical practices for secure cross-network data interaction, existing technologies generally use a uniform, preset encryption strength to process and transmit the data that is allowed to be output, such as applying the same algorithm and key length to encrypt the entire record or the entire data stream.

[0003] However, it cannot, while allowing access, further refine the dynamic allocation of security resources based on the business value (utility) and potential leakage risks of a field. This leads to two technical problems: First, for fields with high permission levels but significant actual business utility and relatively controllable sensitive risks, uniform strong encryption results in unnecessary computational and communication resource overhead, reducing the overall system throughput efficiency and business response agility; Second, the rigid strategy lacks adaptability and cannot achieve a dynamic balance based on real-time, quantitative assessment between ensuring a security baseline and promoting the efficient flow of data elements, thus restricting the actual effectiveness and economic benefits of cross-network data collaboration. Summary of the Invention

[0004] To address the aforementioned problems in the prior art, this invention provides a cross-network data security interaction method and system, which solves the problem in the prior art of processing and transmitting data with a uniform, preset encryption strength.

[0005] According to one aspect of the present invention, a cross-network data security interaction method is provided, applied at a verification end, the verification end being used to respond to a data access request from a sending end, the method comprising:

[0006] Obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request;

[0007] Determine the permission level of the field to be accessed;

[0008] If the permission level is greater than the sensitivity level, then obtain the utility weight and risk weight of the field to be accessed;

[0009] If the utility weight is greater than or equal to the risk weight, then the field to be accessed is determined to be an open field; wherein the encryption level of the open field is less than a preset level threshold.

[0010] The open field is temporarily encrypted to obtain encrypted access data;

[0011] The encrypted access data is sent to the sending end.

[0012] In one embodiment, temporarily encrypting the encrypted field to obtain encrypted access data includes:

[0013] If the utility weight is less than the risk weight, then the field to be accessed is determined to be an encrypted field; wherein the encryption level of the encrypted field is greater than the encryption level of the open field;

[0014] Generate a field mask based on the encrypted field and the open field;

[0015] Based on the field mask, filter the target access field from the fields to be accessed;

[0016] The target access field is temporarily encrypted to obtain encrypted access data.

[0017] In one embodiment, the sensitivity level of the field to be accessed in the directory information corresponding to the data access request includes:

[0018] Obtain entity information corresponding to the data access request, wherein the entity information includes a certificate chain, the certificate chain includes a first certificate and a second certificate, the first certificate is a certificate issued by the root node, and the second certificate is a certificate issued by the central node;

[0019] Based on the root node's public key, verify the first certificate to obtain the first verification result;

[0020] If the first verification result indicates that the first certificate has been successfully verified, then the public key of the central node is obtained based on the first certificate;

[0021] Based on the public key of the central node, the second certificate is verified to obtain a second verification result;

[0022] If the second verification result indicates that the second certificate verification was successful, then obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0023] In one embodiment, the sensitivity level of the field to be accessed in the directory information corresponding to the data access request includes:

[0024] Obtain the directory information corresponding to the data access request; wherein, the directory information includes the resource security level;

[0025] Obtain the role information from the entity information;

[0026] Based on the role information and certificate chain, the entity permission level of the sending end is determined;

[0027] If the entity's permission level is greater than or equal to the resource security level, then obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0028] In one embodiment, temporarily encrypting the open field to obtain encrypted access data includes:

[0029] Obtain additional authentication data; wherein, the additional authentication data represents the necessary fields for verification by the sending end;

[0030] The encrypted access data is constructed based on the field data encryption key, the open field, and additional authentication data.

[0031] In one embodiment, constructing encrypted access data based on the field data encryption key, using the open field and additional authentication data, includes:

[0032] Based on the field data encryption key, the open field and the additional authentication data are authenticated and encrypted to obtain encrypted ciphertext;

[0033] Based on the public key of the sending end, the encryption key of the field data is wrapped to obtain a key envelope;

[0034] Construct the correspondence between the key envelope and the encrypted ciphertext to obtain the encrypted access data.

[0035] In one embodiment, the method for generating the field data encryption key includes:

[0036] Obtain the temporary master key;

[0037] Obtain the directory information and session information corresponding to the data access request;

[0038] Obtain the sensitivity level and field identifier of the open field;

[0039] Based on the temporary master key, the directory information and session information corresponding to the data access request, the sensitivity level of the open field, and the field identifier, a field data encryption key is generated.

[0040] In one embodiment, temporarily encrypting the open field to obtain encrypted access data includes:

[0041] If there is a change event in the data source and the verification end is the central node, then a standardized message is constructed based on the open field, the entity information, directory information, and operation type corresponding to the data access request;

[0042] The target sender for the standardized message that satisfies the preset rules is determined; wherein the preset rules are constructed from preference predicates, and the preference predicates include region, industry and task priority, and each preset rule corresponds to a target sender;

[0043] Based on the target sender, a candidate set is constructed;

[0044] Based on the candidate set, the optimal sender corresponding to the standardized message is determined;

[0045] The standardized message and the optimal sender are temporarily encrypted to obtain the encrypted access data.

[0046] In one embodiment, determining the optimal sender for the standardized message based on the candidate set includes:

[0047] Obtain the historical queue length and link load corresponding to the target transmitter;

[0048] Based on the historical queuing length and the link load, predict the latency of the standardized message to the target sender;

[0049] Obtain the message priority of the standardized message;

[0050] Obtain the bearable priority of the target transmitter;

[0051] Based on the message priority and the bearable priority, obtain the priority value;

[0052] Based on the current message queue length and the preset queue length, obtain the shadow price of the target sender;

[0053] The score corresponding to the target sender is obtained based on the latency, the priority cost, and the shadow price.

[0054] Based on the score corresponding to the target sender, the optimal sender for the standardized message is determined.

[0055] According to another aspect of the present invention, a cross-network data security interaction system is provided, including a verification terminal, the verification terminal being used to respond to a data access request from a sending terminal, the system comprising:

[0056] The first acquisition module is used to acquire the sensitivity level of the field to be accessed in the directory information corresponding to the data access request;

[0057] The first determining module is used to determine the permission level of the field to be accessed;

[0058] The second acquisition module is used to acquire the utility weight and risk weight of the field to be accessed if the permission level is greater than the sensitivity level.

[0059] The second determining module is used to determine that the field to be accessed is an open field if the utility weight is greater than or equal to the risk weight; wherein the encryption level of the open field is less than a preset level threshold.

[0060] An encryption module is used to temporarily encrypt the open field to obtain encrypted access data;

[0061] The sending module is used to send the encrypted access data to the sending end.

[0062] The beneficial effects of this invention are reflected in the fact that it provides a cross-network data security interaction method, including: obtaining the sensitivity level of the field to be accessed in the directory information corresponding to the data access request; determining the permission level of the field to be accessed; if the permission level is greater than the sensitivity level, obtaining the utility weight and risk weight of the field to be accessed; if the utility weight is greater than or equal to the risk weight, determining that the field to be accessed is an open field; wherein the encryption level of the open field is less than a preset level threshold, the open field is temporarily encrypted to obtain encrypted access data, and the encrypted access data is sent to the sending end. This invention, based on the initial screening of field sensitivity and permission level, only allows a field to enter the subsequent evaluation stage when the permission level is higher than the sensitivity level. This mechanism ensures that only users with sufficient permissions can access sensitive fields, avoiding unauthorized access from the source. Further, a quantitative evaluation is performed by combining business utility weight and security risk weight. When the utility weight is greater than or equal to the risk weight, the field is determined to be an open field and is subject to lower-strength encryption or de-identification processing. This process incorporates business value and security risk into the same decision-making framework, achieving a dynamic balance between security and utility. Data marked as open fields are only temporarily or lightly encrypted, rather than uniformly using high-strength encryption, which significantly reduces the computational overhead and transmission latency of encryption and decryption. Attached Figure Description

[0063] Figure 1 This is a flowchart illustrating the cross-network data security interaction method provided by the present invention.

[0064] Figure 2 This is a flowchart illustrating a sensitivity level acquisition method provided in an exemplary embodiment of the present invention.

[0065] Figure 3 This is a flowchart illustrating the data acquisition method provided by the present invention.

[0066] Figure 4This is a schematic diagram of the structure of a cross-network data security interaction system provided by an example of the present invention.

[0067] Figure 5 This is a schematic diagram of the structure of another exemplary cross-network data security interaction system provided by the present invention.

[0068] Figure 6 This is a structural diagram of an electronic device provided in an exemplary embodiment of the present invention.

[0069] Reference numerals: 10 Electronic device; 11 Processor; 12 Memory; 13 Input device; 14 Output device. Detailed Implementation

[0070] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0071] Example 1: Figure 1 This is a flowchart illustrating the cross-network data security interaction method provided by the present invention. Figure 1 As shown, the cross-network data security interaction method is applied to the verification end, which is used to respond to the data access request from the sending end. The cross-network data security interaction method includes:

[0072] S110: Obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0073] In this embodiment of the invention, the directory information corresponding to the data access request is represented as a quadruple. ,in Used as a unique identifier for directory entries; A tag set includes geographic tags, industry tags, business types, and field sensitivity. The tag set is used to express geographic, industry and business boundaries, as well as field-level sensitivity. For resource security level, To be classified as "non-confidential" internal Restricted confidential The security level partial order set defined by "highly confidential" (partial order is used to support cross-domain mapping and uplink operations); The directory version number is a monotonically increasing number.

[0074] Specifically, each field to be accessed in the directory information corresponds to a sensitivity level. The sensitivity level indicates the degree of harm caused by information leakage. When the sensitivity level is high, the encryption / de-identification strength of the field needs to be increased to reduce the risk of leakage. That is, when the sensitivity level is high, the field should not be transmitted to the sender in a readable form in the current context, but should be subject to stronger protection. When the sensitivity level is low, the field is transmitted in plaintext or with weaker protection.

[0075] Before obtaining the sensitivity level of the fields to be accessed in the target information corresponding to the data access request, the verification end also needs to verify whether the sender's entity information, directory information, and session information meet the minimum necessary constraints. The minimum necessary constraints are context compliance predicates used to check whether the context environment of the sender's current access complies with the security policy. The minimum necessary constraints are a comprehensive judgment based on the simultaneous fulfillment of multiple sub-conditions.

[0076] The minimum necessary constraints may include the following sub-conditions: whether the geographical location or network area from which the sender initiated the request is within the geographical area permitted for access in the directory information; whether the industry or business line to which the sender belongs is authorized to access such directory information; whether the current time is within the specified time period for permitted access to directory information; and whether cross-network behavior, such as accessing the target information from the network domain of the entity information corresponding to the sender, is permitted by policy.

[0077] Furthermore, in addition to meeting the minimum necessary constraint, a security level constraint must also be met, meaning the sender's entity permission level must be greater than or equal to the resource security level corresponding to the directory information. In other words, when both the minimum necessary constraint and the security level constraint are satisfied, the verification end obtains all fields from the directory resources that match the directory information in the data access request. It then obtains the permission level and sensitivity level corresponding to each field. Fields with permission levels higher than their sensitivity levels are selected, and their encryption levels are determined.

[0078] S120: Determine the permission level of the field to be accessed.

[0079] In this embodiment of the invention, the verification end needs to determine the permission level of the field to be accessed, thereby determining which specific fields of sensitivity level the sending end can access.

[0080] S130: If the permission level is greater than the sensitivity level, then obtain the utility weight and risk weight of the field to be accessed.

[0081] In this embodiment of the invention, since methods based on fixed rules or purely manual judgment are difficult to adapt to dynamic and ever-changing business scenarios and security situations, the strategies are often either too strict (affecting business efficiency) or too lenient (increasing security risks). Therefore, while ensuring data security, it is also necessary to take into account the smoothness and effectiveness of business operations.

[0082] Specifically, when the permission level is greater than the sensitivity level, it means that the field to be accessed can be accessed by the sender, thus ensuring data transmission security. This accessible field is defined as an open field. The utility weight and risk weight of the open field are then obtained. The utility weight is derived from business statistics (such as the frequency of the field's use in historical business queries and its contribution to key business processes) or audit playback (such as the business value assessment generated after the field was successfully used). The higher the utility weight, the more important the field is to business operations. The risk weight is derived from the sensitivity distribution (the inherent sensitivity level of the field) and historical anonymization alerts (the frequency with which the field has been attempted to be accessed illegally or triggered security alerts in the past). The higher the risk weight, the greater the risk of leakage or misuse of the field.

[0083] This invention employs a risk trade-off coefficient to adjust the degree of risk aversion. A higher risk trade-off coefficient indicates a more conservative strategy, while a lower coefficient indicates a more open strategy.

[0084] Furthermore, the product of the risk weight and the risk trade-off coefficient is calculated to obtain the risk-adjusted value. The utility weight and the risk-adjusted value are compared. If the utility weight is greater than or equal to the risk-adjusted value, it is determined that the business benefits brought by the open field are sufficient to cover its estimated risk costs. Therefore, the open field will be processed with a lower level of protection in this interaction.

[0085] S140: If the utility weight is greater than or equal to the risk weight, then the field to be accessed is determined to be an open field, wherein the encryption level of the open field is less than a preset level threshold.

[0086] S150: Temporarily encrypt the open field to obtain encrypted access data.

[0087] S160: Send the encrypted access data to the sending end.

[0088] Example 2: In one example, S150 can be specifically implemented as follows: if the utility weight is less than the risk weight, then the field to be accessed is determined to be an encrypted field; wherein, the encryption level of the encrypted field is greater than the encryption level of the open field; a field mask is generated based on the encrypted field and the open field; a target access field is selected from the fields to be accessed based on the field mask; the target access field is temporarily encrypted to obtain encrypted access data.

[0089] In this embodiment of the invention, if the utility weight is less than the risk adjustment value, it is determined that the business benefits of opening this field are insufficient to offset its risk costs, and therefore this field will be subject to stronger protection.

[0090] To ensure the security and efficiency of cross-network data transmission, the verification end, based on the sender's authorization and real-time context, sets the following: when the utility weight is greater than or equal to the risk weight, access to the field is permitted, and encryption is performed using a temporary session key; the binary decision variable for this field is set to 1. When the utility weight is less than the risk weight, the content of this field is excluded from the current transmission payload and not transmitted to the sender; the binary decision variable for this field is set to 0. The values ​​of the binary decision variables for all fields constitute a binary field mask. The verification end only performs encryption and encapsulation operations on the fields marked as 1 in the mask. The hash value of this mask is written into the additional authentication data of the encrypted message for the sender to verify, ensuring that the decrypted field set completely conforms to the authorization decision made by the verification end based on the binary decision variables. This mechanism controls the scope of data exposure from the source, avoids the encryption and transmission overhead of invalid fields, and achieves end-to-end consistency between the policy and the transmission through cryptographic binding.

[0091] Example 3: Figure 2 This is a flowchart illustrating a sensitivity level acquisition method provided in an exemplary embodiment of the present invention. Figure 2 As shown, S110 may include:

[0092] S111: Obtain the entity information corresponding to the data access request, wherein the entity information includes a certificate chain, the certificate chain includes a first certificate and a second certificate, the first certificate is a certificate issued by the root node, and the second certificate is a certificate issued by the central node.

[0093] In this embodiment of the invention, the sending end sends its own entity information to the verification end, which verifies whether the sending end has permission to access the system using the certificate chain in the entity information. During the establishment of the interaction process, this invention sets the root node as the unique trust anchor, sends the certificate issued by the root node to the central node, and then sends the certificate issued by the central node to the branch nodes, thereby forming a hierarchical authorization relationship.

[0094] S112: Based on the public key of the root node, verify the first certificate to obtain the first verification result.

[0095] In this embodiment of the invention, each root node corresponds to a root key pair, which includes the root node's public key and private key. Each central node corresponds to a central node key pair, which includes the central node's public key and private key. Each central node also corresponds to a policy digest, which includes directory hierarchy, regional / industry boundaries, and minimum necessary constraints. The hash value of the central node's policy digest is calculated to obtain a hash fingerprint. .

[0096] Specifically, the first total hash fingerprint is calculated based on the public key and hash fingerprint of the central node. The first hash fingerprint is then digitally signed using the private key of the root node, thus obtaining the first certificate. When the verification end verifies the first certificate sent by the sender, it verifies whether the first certificate matches the first total hash fingerprint using the public key of the root node. If they match, the first certificate verification is successful, meaning the first certificate signature is correct.

[0097] Furthermore, in addition to verifying the first certificate, this invention also needs to verify the validity of the first certificate. The entity information may further include the issuance time and expiration time of the first certificate. If the current verification time falls within the interval between the issuance time and the expiration time, then the first certificate is determined to be still valid.

[0098] Furthermore, the root node constructs a revocation list for revoked certificates, sends the revocation list to the central node, and the central node then sends the revocation list to the branch nodes. If the verification end determines that the first certificate is not in the revocation list, that is, the first certificate does not match the revoked certificates in the revocation list, then the first certificate is determined to be valid.

[0099] In one embodiment, if the central node determines that the certificate of the target node has been revoked based on the revocation list, it generates revocation information. If the total delay time for the sub-node to receive the revocation information is greater than the preset total delay time, it determines the delay time corresponding to each node in the transmission path corresponding to the sub-node. If the delay time is greater than the preset delay time, it determines that the node with the delay time greater than the preset delay time is an abnormal node.

[0100] Finally, if the first certificate is successfully verified and its current verification time is within the interval between the issuance time and the expiration time, and the first certificate is not on the revocation list, then the first certificate is determined to be valid.

[0101] S113: If the first verification result indicates that the first certificate has been successfully verified, then obtain the public key of the central node based on the first certificate.

[0102] In this embodiment of the invention, after the first certificate is successfully verified, the public key of the central node in the first certificate is obtained. The second certificate is then verified using the public key of the central node.

[0103] S114: Based on the public key of the central node, verify the second certificate to obtain a second verification result.

[0104] In this embodiment of the invention, each sub-node corresponds to a sub-node key pair, which includes the sub-node's public key and private key. The policy digest of the sub-node is obtained, and its hash fingerprint is calculated. A second total hash fingerprint is calculated based on the public keys and hash fingerprints of the sub-nodes. The second hash fingerprint is then signed using the public key of the central node to obtain a second certificate.

[0105] Specifically, this invention parses the public key of the central node from the first certificate and verifies whether the second certificate matches the second total hash fingerprint. If they match, the second certificate is verified successfully, meaning the signature is correct.

[0106] Furthermore, since certificates have a time period, it is also necessary to obtain the issuance date and expiration date of the second certificate. If the current verification time of the second certificate falls within the range of its issuance date and expiration date, then the second certificate is determined to be valid.

[0107] Furthermore, the root node constructs a revocation list for the revoked certificates, and sends the revocation list to the central node, which then sends it to the branch nodes. If the verification end determines that the second certificate is not in the revocation list, i.e., the second certificate does not match any of the revoked certificates in the revocation list, then the second certificate is deemed valid.

[0108] Finally, if the second certificate is successfully verified and its current verification time is within the interval between the issuance time and the expiration time, and the second certificate is not on the revocation list, then the second certificate is deemed valid.

[0109] In addition to verifying the validity of the second certificate, this invention also needs to verify the consistency between the policy fingerprint of the central node and the policy fingerprint of the sub-nodes in the session. Specifically, if the first certificate is successfully verified and its current verification time is within the interval between its issuance time and expiration time, and the first certificate is not on the revocation list, and the second certificate is successfully verified and its current verification time is within the interval between its issuance time and expiration time, and the second certificate is not on the revocation list, and the policy fingerprint of the central node sent by the sending end is consistent with the hash fingerprint of the central node... The matching and sending of the policy fingerprint and hash fingerprint of the sub-nodes by the sender. If a match is found, the accessed data is retrieved.

[0110] Therefore, by constructing a hierarchical authorization link with the root node as the trust anchor, the central node as the governance carrier, and the sub-nodes as the domain access points, identity verification, permission level, policy version, and session validity are bound together through the same verifiable link, thereby solving the common problems of dispersed identity sources, inconsistent authorization boundaries, and delayed revocation and update propagation in cross-network collaboration.

[0111] S115: If the second verification result indicates that the second certificate verification is successful, then obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0112] Example 4: Figure 3 This is a flowchart illustrating the data acquisition method provided by the present invention. Figure 3 As shown, S115 may include:

[0113] S1151: Obtain the directory information corresponding to the data access request, wherein the directory information includes the resource security level.

[0114] S1152: Obtain the role information from the entity information.

[0115] S1153: Based on the role information and certificate chain, determine the entity permission level of the sending end.

[0116] In this embodiment of the invention, the entity permission level of the sending end is determined by the certificate chain and role information sent by the sending end. For example, the root node (R): the highest trust anchor, located in the public security network. The central node (C): in the government network, responsible for managing regional sub-nodes. Sub-nodes (D): regional sub-nodes (e.g., a municipal government sub-node), participating in data exchange. The partial order set of security levels: L={0,1,2,3,4}, where a larger number indicates a higher level of privilege (e.g., 0=non-confidential, 1=internal, 2=restricted, 3=confidential, 4=highly confidential).

[0117] When verifying the signature of the first certificate, the verifier will extract the hash fingerprint. Among them, hash fingerprint This includes the sequence number level of the central node, for example, L=3. When verifying the signature of the second certificate, the verifier extracts the hash fingerprint. Hash fingerprint This includes the permission levels of the sub-nodes, for example, L=2. The root node has a higher permission level than the central node, which in turn has a higher permission level than the sub-nodes, thus reflecting the hierarchical authorization principle. Therefore, the sender's permission level is the same as the sub-node's permission level.

[0118] In this embodiment of the invention, the permission level is also adjusted based on role information. For example, if the role information of the provincial center is Region A, then the default permission level is 4 (highly confidential).

[0119] S154: If the entity permission level is greater than or equal to the resource security level, then obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0120] In this embodiment of the invention, directory information corresponding to the data access request is obtained. This directory information includes resource security level, region / industry tags, and field-level sensitivity. The resource security level is used to verify whether the sending end can access the data. In other words, the resource security level is used as a benchmark to determine whether the sending end can access the data.

[0121] Therefore, when the entity's permission level is greater than or equal to the resource security level, it is determined that the sender can access the verifier, and the verifier can send access data to the sender.

[0122] Example 5: In one embodiment, S154 can be specifically implemented as follows: obtaining the session information of the sending end; if the entity information, the session information and the directory information respectively satisfy the minimum necessary constraint, then obtaining the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0123] In this embodiment of the invention, a minimum necessary constraint is defined, that is, a logical combination of multiple sub-conditions, including geographic matching, service type matching, and task whitelisting. Session information includes session context c. Geographic matching indicates that the physical or logical network area where the sending end is located must be permitted by the verifier's resource policy. For example, directory information r is a list of sensitive personnel in a border city, and its policy restricts access only to IP address ranges belonging to the city's public security bureau. Session context c includes the request source IP address. If the request source IP address belongs to a permitted IP address range in resource r, then the sending end is allowed to access the verifier.

[0124] In this context, "business type matching" indicates that the data access request is driven by a compliant business process. For example, if the directory information *r* is "A payment data," its policy stipulates that it can only be used for "A business" or "B business." The session context *c* includes the business type of this data call. If the business type of this data call belongs to "A business" or "B business," then the sender is allowed to access the verification end.

[0125] The task whitelist indicates that access from the sending end must be associated with a pre-approved, uniquely identified valid task. For example, if directory information r is a "major criminal case clue database," and session context c contains a task ID corresponding to a "special investigation task" created and authorized by a superior before the investigation begins. If the task ID belongs to the authorized task list in directory information r, and the department e belongs to the valid task whitelist in directory information r, then the sending end is allowed to access the verification end.

[0126] Example 6: In one embodiment, S150 can be specifically implemented as: obtaining additional authentication data; wherein, the additional authentication data represents the necessary fields for verification by the sending end; and constructing encrypted access data based on the field data encryption key, the open fields, and the additional authentication data.

[0127] In this embodiment of the invention, since encryption and traceability are only performed at the channel or file level, compliance boundaries are lost after data is stored across domains or copied, making it difficult to detect and hold accountable unauthorized use in a timely manner. Therefore, the field-level one-time data key (field data encryption key), the key envelope wrapped in the sender's public key, and the encryption and integrity protection with authentication are combined into one, and compliance context such as session token, policy version, directory entry identifier, and field set are written as additional authentication data into the ciphertext header; the ciphertext can only be decrypted under the authorized context bound to it. During the policy switching period, version bucketing and transition windows ensure that old sessions converge according to the old policy and new sessions use the new policy, avoiding mixing and directly solving the problem of uncontrolled storage while ensuring link security. This allows compliance constraints and audit semantics to accompany the ciphertext, and copying or transferring cannot take away the authorized context required for decryption, suppressing the spread of unauthorized use from the source; at the same time, it provides element-level replayable credentials for settlement and auditing. By binding cryptographic encapsulation with compliance metadata, an engineered path of ciphertext as rule is formed, which is different from existing solutions that only protect channels.

[0128] The attachment authentication data includes directory information identifiers, field identifiers, encrypted timestamps, session tokens, and policy version fingerprints.

[0129] Example 7: In one embodiment, S150 can be specifically implemented as follows: based on the field data encryption key, the open field and the additional authentication data are authenticated and encrypted to obtain encrypted ciphertext; based on the public key of the sending end, the field data encryption key is wrapped to obtain a key envelope; and a correspondence between the key envelope and the encrypted ciphertext is constructed to obtain encrypted access data.

[0130] In this embodiment of the invention, after receiving an authenticated session request, the sending end filters out the fields that are allowed to be output based on the directory semantics, performs preprocessing such as masking, generalization or setting to null on the highly sensitive fields according to predetermined rules and unifies the encoding format, and then generates a one-time data key for each field or field group.

[0131] Specifically, the open fields to be encrypted are determined through a field mask. Unmodifiable additional authentication data is identified, including directory entry identifiers, field identifiers, encryption timestamps, session tokens, and policy fingerprints. The open fields and additional authentication data are then authenticated and encrypted using the field data encryption key to obtain encrypted ciphertext. This authentication encryption can be performed using the AEAD encryption method. AEAD stands for Authenticated Encryption with Associated Data, meaning authentication encryption with associated data.

[0132] Example 8: In one embodiment, S150 can be specifically implemented as follows: obtaining a temporary master key; obtaining directory information and session information corresponding to the data access request; obtaining the sensitivity level and field identifier of the open field; and generating a field data encryption key based on the temporary master key, the directory information and session information corresponding to the data access request, the sensitivity level of the open field, and the field identifier.

[0133] In this embodiment of the invention, in order to ensure that the key is strongly bound to the business context, a tag-based key derivation method (KDF) is used to obtain the field data encryption key from the temporary master key that is valid in the current session.

[0134] Specifically, the data is concatenated sequentially according to the directory information, field identifier, session information, and sensitivity level of the field to be encrypted corresponding to the data access request. Based on the concatenated data and the temporary master key, the KDF algorithm is invoked to output a fixed-length field data encryption key. This invention can obtain field data encryption keys for different fields using the same temporary master key and different field contexts. KDF, short for Key Derivation Function, as the name suggests, has the core task of deriving one or more keys from one key (or password).

[0135] Example 9: In one embodiment, S150 can be specifically implemented as follows: If there is a change event in the data source and the verification end is the central node, then based on the open field, the entity information, directory information, and operation type corresponding to the data access request, a standardized message is constructed; the target sender that satisfies the preset rules of the standardized message is determined; wherein, the preset rules are constructed by preference predicates, and the preference predicates include region, industry, and task priority, and each preset rule corresponds to a target sender; a candidate set is constructed based on the target sender; the optimal sender corresponding to the standardized message is determined based on the candidate set; the standardized message and the optimal sender are temporarily encrypted to obtain encrypted access data.

[0136] In this embodiment of the invention, routing based on manual triggering or static scripts is prone to latency jitter, misdelivery, and alternation of old and new rules under high concurrency, link congestion, and policy switching windows. Therefore, events such as additions, changes, and deletions are monitored in the central domain, and dynamic routing is performed by comprehensively considering link load, version consistency, and business priority. When the directory or authorization policy is updated, a smooth transition is provided for existing sessions, and new sessions are forced to use the new rules. The target domain prioritizes nodes that have completed version alignment, avoiding rule jitter within a single session. This directly solves the problems of inaccurate, unstable, and untimely delivery. Messages arrive at the version-consistent and load-friendly target domain faster, mismatches and retransmissions are significantly reduced, and the end-to-end timeliness and stability of distribution and return are measurably improved. This technical solution is an improved application in the rule engine field, but it incorporates version awareness and adaptive transformation of the transition window to address version consistency and queue congestion across multiple domains and networks, and is specifically optimized for policy switching and multi-target fan-out scenarios.

[0137] Specifically, by selecting the optimal node, data distribution or backflow is ensured to be more secure, resource-efficient, and timely. The verification end listens for event streams from upstream data sources, including event types (data addition, update, and deletion). Each event is encapsulated into a structured standard message, binding entity information, session information, directory information, directory version fingerprint, event type (data addition, update, deletion), event timestamp, and field mask to obtain the standardized message.

[0138] This invention verifies whether the sender has permission to access directory information using an accessibility predicate. It also defines operational preferences using a distribution preference predicate, thereby identifying target nodes that meet these rules. These target nodes are then added to a candidate set. Finally, the optimal node with the lowest cost and that satisfies the capacity constraint is selected from the candidate set as the node for transmitting standardized messages.

[0139] In one embodiment, S150 may specifically be implemented as follows: obtaining the historical queuing length and link load corresponding to the target sender; predicting the latency of the standardized message to the target sender based on the historical queuing length and link load; obtaining the message priority of the standardized message; obtaining the carryable priority of the target sender; obtaining the priority cost based on the message priority and the carryable priority; obtaining the shadow price of the target sender based on the current message queue length and the preset queue length; obtaining the score corresponding to the target sender according to the latency, the priority cost, and the shadow price; and determining the optimal sender corresponding to the standardized message based on the score corresponding to the target sender.

[0140] In this embodiment of the invention, the latency of transmitting a standardized message to the target sender can be predicted by the historical queuing length and link load corresponding to the target sender. This latency is the delay incurred when the central node transmits the message to the target sender (target branch node). The message priority of the standardized message and the carry-on priority of the target sender are obtained. The carry-on priority represents the target sender's ability to process high-priority messages, i.e., what priority level of messages it is suitable to receive and process at the current moment. If the message priority of the standardized message is higher than the carry-on priority, it indicates that the target sender may be overloaded, have insufficient resources, or have poor link conditions, and cannot guarantee the fast response required for high-priority messages. Therefore, if it is determined that the message priority of the standardized message is higher than the carry-on priority, a penalty value (priority cost) is obtained to prevent high-priority messages from being routed to the target sender as much as possible.

[0141] Furthermore, this invention obtains the current message queue length and the desired queue length (preset queue length) of the target sender. The load status of the target sender can be determined by the length difference between the current message queue length and the desired queue length. If the load status is high, the shadow price increases. If the load status is low, the shadow price decreases. Specifically, the calculation method involves calculating the length difference multiplied by the learning rate, then obtaining the shadow price from the previous time step, and summing the shadow price from the previous time step with the length product to obtain the shadow price at the current time step.

[0142] The learning rate is an adjustable parameter greater than 0, which controls the sensitivity of the shadow price to changes in the queue.

[0143] Finally, the sum of the latency, the priority cost, and the shadow price is calculated as the score of the target transmitter. The target transmitter with a score less than a preset score threshold and less than or equal to the upper capacity bound corresponding to the target transmitter is selected as the optimal transmitter.

[0144] In this invention, due to the high bandwidth consumption and slow convergence caused by full data rollback and manual alignment, version flipping occurs during concurrent updates. Even if synchronization is completed, there is a lack of fine-grained transaction measurement and audit evidence, making long-term operation difficult. Therefore, when the data is stored in the sub-node database, a replayable lineage record is generated, marking the source, strategy, fields, time, and destination. Changes at the source end are broadcast by the center as differential patches, and the sub-nodes perform idempotent updates based on the directory version and lineage comparison. In the case of multiple centers concurrently, a time-priority and security-level-undiminished adjudication strategy is adopted. The transmission end simultaneously outputs an element-level exchange list, and periodic summaries realize bilateral reconciliation and fee settlement. The accounts can be traced back to specific encrypted text and lineage records, thereby directly solving the problems of "slow synchronization, inaccurate synchronization, and difficulty in accountability and settlement". This allows the consistency of the replica to converge within a controllable bandwidth and bounded time, and each update and compensation has a chain of evidence that can be replayed. Measurement and settlement transform "what was transmitted, how much was transmitted, and what is its value" into clear fees and audit evidence. This technology is a combination of two types of capabilities: one is cross-network adaptation of the existing differential synchronization approach and superimposition of compliance adjudication, and the other is close integration of element-level measurement and settlement audit with encrypted data and lineage, forming a closed loop oriented towards regulatory acceptance.

[0145] To trace the data interaction process, the relevant information for each data interaction is encapsulated into a permanently traceable and auditable credential. Specifically, when data is successfully transmitted from the root node S to the branch node D (passing through the central node C for forwarding or decision-making) and stored in the database, a lineage record is triggered, resulting in a lineage entry. The lineage entry includes the version number from the directory information, the policy fingerprint of the version corresponding to that version number, the root node's identifier and the sender's identifier, session information, field mask, session token, operation type, and event timestamp. Edges are added between the root node, central node, and branch nodes based on the actual data flow. For example, if data is sent from S, first to C, and then from C to D, then two edges are added: S→C and C→D. Each edge is accompanied by a corresponding lineage entry. When viewing the edge S→C, the details of the data exchange from S to C can be seen; when viewing the edge C→D, the details of the data exchange from C to D can be seen. In summary, a local lineage graph is constructed based on the root node, central node, branch nodes, and the corresponding edges.

[0146] Furthermore, the local genealogy graph is stored on separate nodes, and an index key is established to associate it with the lineage entries. The complete lineage entry can be queried through the index key. The index key can be constructed using entity information, version number, and the policy fingerprint corresponding to the version.

[0147] Furthermore, the central node monitors whether the root node has changed the directory information. When it detects that the version v of the directory information has changed from v to v+1, the central node constructs a broadcast message and sends it to the branch node D. It then retrieves the lineage entry corresponding to the directory information from the local lineage graph and obtains the local version identifier and its corresponding local policy fingerprint from the lineage entry. The broadcast message includes the minimum changeset, the change issuance time, the directory information, the changed version v+1 corresponding to the directory information, and the policy fingerprint corresponding to the changed version. The minimum changeset is generated by field-level differentials and includes column-level patches and shard set block splits. The minimum changeset represents the fields that can be viewed. If the local policy fingerprint corresponding to the local version is the same as the policy fingerprint corresponding to the changed version, then the local copy of the branch node is determined to be consistent with the local copy of the root node. If the local policy fingerprint corresponding to the local version is different from the policy fingerprint corresponding to the changed version, and the version of the branch node is less than the version of the source node, then the branch node applies patches sequentially based on the block-level order of the minimum changeset, ensuring that even if patches are replayed, duplicate writes will not occur (idempotency). After the patch is successfully written to the database, a compensation lineage entry is generated and written to the local genealogy for auditing and tracing. The compensation lineage entry clearly records which central node initiated the compensation, which fields and strategies were used for writing the patch, and which session token was used to execute it. After the compensation is completed, the sub-nodes generate a confirmation message and encapsulate the message back to the central node.

[0148] In one embodiment, supplementary receipt records corresponding to supplementary lineage entries are obtained. Each supplementary receipt record accurately records metadata such as directory information, fields, encrypted text, timestamps, and policy versions. At the central node, these original records are aggregated according to a preset period to generate a ternary statistic based on "number of entries - number of bytes - sensitivity weight," and the cost is calculated based on a linear rate model, where the directory category fee, byte rate, and sensitivity surcharge together constitute the settlement basis. The root node's sending ledger and the branch node's receiving ledger must remain balanced within the tolerance range. If a branch node automatically identifies abnormal entries such as expired tokens or inconsistent versions, it generates a discrepancy list and triggers compensation retransmission. Simultaneously, by constructing a time-series-based hash chain commitment, the key information of each exchange record is solidified into an immutable verification sequence, enabling any settlement entry to be accurately traced back to the corresponding encrypted transmission and lineage record. At the end of the period, a signed data packet containing the end-of-period hash commitment, rate snapshot, and adjustment list is generated as a legal credential for regulatory acceptance, ultimately forming a complete closed loop from data interaction to economic accounting.

[0149] Figure 4 This is a schematic diagram of the structure of a cross-network data security interaction system provided by an example of the present invention. Figure 4As shown, the cross-network data security interaction system includes: a first acquisition module, used to acquire the sensitivity level of the field to be accessed in the directory information corresponding to the data access request; a first determination module, used to determine the permission level of the field to be accessed; a second acquisition module, used to acquire the utility weight and risk weight of the field to be accessed if the permission level is greater than the sensitivity level; a second determination module, used to determine that the field to be accessed is an open field if the utility weight is greater than or equal to the risk weight; wherein the encryption level of the open field is less than a preset level threshold; an encryption module, used to temporarily encrypt the open field to obtain encrypted access data; and a sending module, used to send the encrypted access data to a sending end.

[0150] Figure 5 This is a schematic diagram of the structure of another exemplary cross-network data security interaction system provided by the present invention. For example... Figure 5 As shown, the encryption module may include: a determining unit, configured to determine the field to be accessed as an encrypted field if the utility weight is less than the risk weight; wherein the encryption level of the encrypted field is greater than the encryption level of the open field; a generating unit, configured to generate a field mask based on the encrypted field and the open field; a filtering unit, configured to filter target access fields from the fields to be accessed based on the field mask; and an encryption unit, configured to temporarily encrypt the target access field to obtain encrypted access data.

[0151] In one embodiment, the first acquisition module may be specifically configured to: acquire entity information corresponding to the data access request, wherein the entity information includes a certificate chain, the certificate chain includes a first certificate and a second certificate, the first certificate being a certificate issued by the root node, and the second certificate being a certificate issued by the central node; verify the first certificate based on the public key of the root node to obtain a first verification result; if the first verification result indicates that the first certificate has been successfully verified, then acquire the public key of the central node based on the first certificate; verify the second certificate based on the public key of the central node to obtain a second verification result; if the second verification result indicates that the second certificate has been successfully verified, then acquire the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0152] In one embodiment, the first acquisition module may be specifically configured to: acquire directory information corresponding to the data access request; wherein the directory information includes a resource security level; acquire role information in the entity information; determine the entity permission level of the sending end based on the role information and the certificate chain; if the entity permission level is greater than or equal to the resource security level, acquire the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

[0153] In one embodiment, the encryption module is configured to: obtain additional authentication data; wherein the additional authentication data represents the necessary fields for verification by the sending end; and construct encrypted access data based on the field data encryption key, the open fields, and the additional authentication data.

[0154] In one embodiment, the encryption module is configured to: perform authentication encryption on the open field and additional authentication data based on the field data encryption key to obtain encrypted ciphertext; wrap the field data encryption key based on the public key of the sending end to obtain a key envelope; and construct the correspondence between the key envelope and the encrypted ciphertext to obtain encrypted access data.

[0155] In one embodiment, the field data encryption key generation module includes: obtaining a temporary master key; obtaining directory information and session information corresponding to the data access request; obtaining the sensitivity level and field identifier of the open field; and generating a field data encryption key based on the temporary master key, the directory information and session information corresponding to the data access request, the sensitivity level of the open field, and the field identifier.

[0156] In one embodiment, the encryption module is configured as follows: if the data source has a change event and the verification end is a central node, then based on the open field, the entity information, directory information, and operation type corresponding to the data access request, a standardized message is constructed; the target sender that satisfies the standardized message according to preset rules is determined; wherein, the preset rules are constructed by preference predicates, and the preference predicates include region, industry, and task priority, and each preset rule corresponds to a target sender; a candidate set is constructed based on the target sender; the optimal sender corresponding to the standardized message is determined based on the candidate set; and the standardized message and the optimal sender are temporarily encrypted to obtain encrypted access data.

[0157] In one embodiment, the encryption module is configured to: obtain the historical queuing length and link load corresponding to the target sender; predict the latency of the standardized message to the target sender based on the historical queuing length and link load; obtain the message priority of the standardized message; obtain the carryable priority of the target sender; obtain the priority cost based on the message priority and the carryable priority; obtain the shadow price of the target sender based on the current message queue length and the preset queue length; obtain the score corresponding to the target sender according to the latency, the priority cost, and the shadow price; and determine the optimal sender corresponding to the standardized message based on the score corresponding to the target sender.

[0158] Figure 6 A block diagram of an electronic device according to an embodiment of this application is illustrated.

[0159] like Figure 6 As shown, the electronic device 10 includes one or more processors 11 and memory 12.

[0160] The processor 11 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 10 to perform desired functions.

[0161] The memory 12 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 11 may execute the program instructions to implement the cross-network data security interaction methods of the various embodiments of this application described above, and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0162] In one example, the electronic device 10 may also include an input device 13 and an output device 14, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).

[0163] When the electronic device 10 is a standalone device, the input device 13 can be a communication network connector for receiving the collected input signals from the first device and the second device.

[0164] In addition, the input device 13 may also include, for example, a keyboard, a mouse, etc.

[0165] The output device 14 can output various information to the outside, including determined distance information, direction information, etc. The output device 14 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0166] Of course, for the sake of simplicity, Figure 6 Only some of the components of the electronic device 10 relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device 10 may include any other suitable components depending on the specific application.

[0167] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0168] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0169] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for secure cross-network data interaction, characterized in that, Applied to a verification end, the verification end is used to respond to data access requests from the sending end, and the method includes: Obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request; Determine the permission level of the field to be accessed; If the permission level is greater than the sensitivity level, then obtain the utility weight of the business value indicator based on the field to be accessed and the risk weight of the security risk indicator based on the field to be accessed. If the utility weight is greater than or equal to the risk weight, then the field to be accessed is determined to be an open field; wherein the encryption level of the open field is less than a preset level threshold. Obtain additional authentication data; wherein, the additional authentication data represents the necessary fields for verification by the sending end; Based on the field data encryption key, the open field, and additional authentication data, the encrypted access data is constructed. If the utility weight is less than the risk weight, then the field to be accessed is determined to be an encrypted field; wherein the encryption level of the encrypted field is greater than the encryption level of the open field; Generate a field mask based on the encrypted field and the open field; Based on the field mask, filter the target access field from the fields to be accessed; The target access field is temporarily encrypted to obtain encrypted access data; The encrypted access data is sent to the sending end.

2. The cross-network data security interaction method according to claim 1, characterized in that, The sensitivity levels of the fields to be accessed in the directory information corresponding to the data access request include: Obtain entity information corresponding to the data access request, wherein the entity information includes a certificate chain, the certificate chain includes a first certificate and a second certificate, the first certificate is a certificate issued by the root node, and the second certificate is a certificate issued by the central node; Based on the root node's public key, verify the first certificate to obtain the first verification result; If the first verification result indicates that the first certificate has been successfully verified, then the public key of the central node is obtained based on the first certificate; Based on the public key of the central node, the second certificate is verified to obtain a second verification result; If the second verification result indicates that the second certificate verification was successful, then obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

3. The cross-network data security interaction method according to claim 2, characterized in that, The sensitivity levels of the fields to be accessed in the directory information corresponding to the data access request include: Obtain the directory information corresponding to the data access request; wherein, the directory information includes the resource security level; Obtain the role information from the entity information; Based on the role information and certificate chain, the entity permission level of the sending end is determined; If the entity's permission level is greater than or equal to the resource security level, then obtain the sensitivity level of the field to be accessed in the directory information corresponding to the data access request.

4. The cross-network data security interaction method according to claim 1, characterized in that, The method for constructing encrypted access data based on the field data encryption key, using the open field and additional authentication data, includes: Based on the field data encryption key, the open field and the additional authentication data are authenticated and encrypted to obtain encrypted ciphertext; Based on the public key of the sending end, the encryption key of the field data is wrapped to obtain a key envelope; Construct the correspondence between the key envelope and the encrypted ciphertext to obtain the encrypted access data.

5. The cross-network data security interaction method according to claim 1, characterized in that, The method for generating the encryption key for the field data includes: Obtain the temporary master key; Obtain the directory information and session information corresponding to the data access request; Obtain the sensitivity level and field identifier of the open field; Based on the temporary master key, the directory information and session information corresponding to the data access request, the sensitivity level of the open field, and the field identifier, a field data encryption key is generated.

6. The cross-network data security interaction method according to claim 1, characterized in that, The temporary encryption of the open field to obtain encrypted access data includes: If there is a change event in the data source and the verification end is the central node, then a standardized message is constructed based on the open field, the entity information, directory information, and operation type corresponding to the data access request; The target sender for the standardized message that satisfies the preset rules is determined; wherein the preset rules are constructed from preference predicates, and the preference predicates include region, industry and task priority, and each preset rule corresponds to a target sender; Based on the target sender, a candidate set is constructed; Based on the candidate set, the optimal sender corresponding to the standardized message is determined; The standardized message and the optimal sender are temporarily encrypted to obtain the encrypted access data.

7. The cross-network data security interaction method according to claim 6, characterized in that, The step of determining the optimal sender corresponding to the standardized message based on the candidate set includes: Obtain the historical queue length and link load corresponding to the target transmitter; Based on the historical queuing length and the link load, predict the latency of the standardized message to the target sender; Obtain the message priority of the standardized message; Obtain the bearable priority of the target transmitter; Based on the message priority and the bearable priority, obtain the priority value; Based on the current message queue length and the preset queue length, obtain the shadow price of the target sender; The score corresponding to the target sender is obtained based on the latency, the priority cost, and the shadow price. Based on the score corresponding to the target sender, the optimal sender for the standardized message is determined.

8. A cross-network data security interaction system, characterized in that, The system includes a verification terminal, which is used to respond to data access requests from the sending terminal. The first acquisition module is used to acquire the sensitivity level of the field to be accessed in the directory information corresponding to the data access request; The first determining module is used to determine the permission level of the field to be accessed; The second acquisition module is used to acquire, if the permission level is greater than the sensitivity level, the utility weight of the business value indicator based on the field to be accessed and the risk weight of the security risk indicator based on the field to be accessed. The second determining module is used to determine the field to be accessed as an open field if the utility weight is greater than or equal to the risk weight; wherein the encryption level of the open field is less than a preset level threshold; to obtain additional authentication data; wherein the additional authentication data represents the necessary fields for verification by the sending end; and to construct encrypted access data based on the field data encryption key, the open field, and the additional authentication data. An encryption module is configured to determine the field to be accessed as an encrypted field if the utility weight is less than the risk weight; wherein the encryption level of the encrypted field is greater than the encryption level of the open field; generate a field mask based on the encrypted field and the open field; filter target access fields from the fields to be accessed based on the field mask; and temporarily encrypt the target access fields to obtain encrypted access data. The sending module is used to send the encrypted access data to the sending end.

Images