Data element delivery invocation method, apparatus and computer program product

Abstract

The application discloses a data element delivery calling method, equipment and computer program product, relates to the technical field of network security, and the method comprises the following steps: acquiring a data element delivery calling request sent by a calling party, and performing permission verification on the calling party based on a preset permission model; under the condition that the calling party passes the permission verification, performing desensitization calling on mixed encrypted data elements in a preset encrypted database according to the data element delivery calling request; inputting index data generated in the desensitization calling into a preset abnormality identification model to identify calling abnormal behaviors, and performing abnormal response adjustment on the desensitization calling based on the calling abnormal behaviors. The storage, transmission and calling whole process of the data element delivery calling are covered, and the data element calling security and real-time flexibility are comprehensively improved in the whole life cycle.

Description

Technical Field

[0001] This application relates to the field of cybersecurity technology, and in particular to methods, devices and computer program products for delivering and invoking data elements. Background Technology

[0002] Mainstream data element invocation schemes only ensure security during transmission, but cannot monitor the storage status of data elements or the invocation process. This results in the problem of secure transmission but uncontrolled usage. Because security is only ensured during transmission, there are blind spots in protection, leading to a lack of early warning capabilities for abnormal behavior during data element invocation. Furthermore, mainstream data element invocation schemes typically use static permission control, restricting the scope of data element invocation through a preset user permission list. Permission configuration relies on manual operation and cannot be dynamically adjusted, resulting in insufficient invocation flexibility.

[0003] Therefore, how to comprehensively improve the security and real-time flexibility of data element calls has become a technical problem that this application urgently needs to solve. Summary of the Invention

[0004] The main purpose of this application is to provide a data element delivery and invocation method, device, and computer program product, which aims to solve the technical problem of how to comprehensively improve the security and real-time flexibility of data element invocation.

[0005] To achieve the above objectives, this application proposes a method for delivering and invoking data elements, the method comprising: Obtain the data element delivery request sent by the caller, and verify the caller's permissions based on a preset permission model; Under the condition that the caller's permission verification is passed, the data element delivered in the data element call request is used to de-identify the data element in the pre-encrypted database and call it. The indicator data generated during the de-identified call is input into a preset anomaly identification model to identify abnormal call behavior, and the de-identified call is adjusted to make abnormal response based on the abnormal call behavior.

[0006] In one embodiment, before the step of obtaining the data element delivery call request sent by the caller and verifying the caller's permissions based on a preset permission model, the method further includes: Add a unique identifier and data fingerprint to the data element; A symmetric encryption algorithm is used to encrypt the content of the data element with the added unique identifier and data fingerprint; The key of the symmetric encryption algorithm is encrypted using an asymmetric encryption algorithm to obtain a hybrid encrypted data element; Establish a dedicated transmission channel according to the preset transmission control protocol; The hybrid encrypted data elements are stored in the encrypted database through the dedicated transmission channel, and the encrypted database is encrypted in real time using transparent data encryption.

[0007] In one embodiment, the step of verifying the caller's permissions based on a preset permission model includes: The current invocation scenario is determined based on the data element delivery invocation request; Invoke the permission model and adjust the permission rules corresponding to the current invocation scenario based on the permission model; The caller is subjected to multi-factor permission verification by combining the adjusted permission rules and the preset permission attribute dimensions of the permission model; If the multi-factor permission verification passes, then the following step is executed: de-identify and call the data element in the encrypted database according to the data element delivery call request.

[0008] In one embodiment, the step of de-identifying and calling a hybrid encrypted data element in a pre-set encrypted database according to the data element delivery call request includes: Based on the data element delivery call request, the data element to be called is determined, and the sensitive fields in the data element to be called are located according to the preset sensitive data rules; The sensitive fields in the data element to be invoked are replaced with virtual values ​​of the same format to obtain the desensitized data element; The de-identified data element is retrieved from the encrypted database according to the data element delivery request.

[0009] In one embodiment, the step of inputting the indicator data generated during the de-identified call into a preset anomaly identification model to identify abnormal call behavior, and adjusting the abnormal response of the de-identified call based on the abnormal call behavior, includes: The pre-built streaming computing framework is invoked to collect the indicator data generated during the de-identified call; The indicator data is input into the anomaly identification model, and the anomaly identification model is used to match the indicator data with the normal behavior baseline in terms of time-series features to identify abnormal calling behavior. Based on the abnormal call behavior, a multi-level exception response mechanism is triggered, and the anomaly response to the de-identified call is adjusted according to the multi-level exception response mechanism.

[0010] In one embodiment, the step of adjusting the abnormal response to the de-identified call according to the multi-level abnormal response mechanism includes: If the multi-level anomaly response mechanism is a preset level one response, a potential risk warning is generated and sent to the visual operation interface in a visual form. If the multi-level exception response mechanism is a preset level 2 response, then the de-identified call permission in the permission model is frozen to suspend the de-identified call; If the multi-level exception response mechanism is a preset three-level response, then the de-identification call will be interrupted.

[0011] In one embodiment, the step of inputting the indicator data generated during the de-identified call into a preset anomaly detection model to identify abnormal call behavior further includes: Deploy a distributed cluster to build a streaming computing framework; Historical normal behavior data is collected based on the streaming computing framework, and the historical normal behavior data covers the entire lifecycle of data elements; A training dataset for the model is constructed based on the aforementioned historical normal behavior data; The Long Short-Term Memory (LSTM) network model is trained using the model training dataset to establish a baseline for normal behavior, and an anomaly detection model is constructed based on the LSM network model with the baseline for normal behavior.

[0012] In one embodiment, the step of adjusting the abnormal response of the de-identified call based on the abnormal call behavior further includes: Generate a full lifecycle operation log for the data element and store the full lifecycle operation log in the log database in the form of blockchain evidence storage; Obtain log query requests through the multidimensional log query interface; The full lifecycle operation log is retrieved from the log database according to the log query request. A compliance traceability report is generated based on the full lifecycle operation logs.

[0013] In addition, to achieve the above objectives, this application also proposes a data element delivery and invocation device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data element delivery and invocation method as described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the data element delivery and invocation method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: First, permission verification, based on a pre-defined model, ensures the legitimacy of the calling entity. This model can be adjusted and is not limited to a fixed permission list. De-identified calls reduce the risk of sensitive data exposure during the call process, strengthening security protection during the call phase. Second, an encrypted database is used to store hybrid encrypted data components. Hybrid encryption and encrypted storage construct a security barrier for data transmission and storage, ensuring both static and dynamic security of data components. Furthermore, an anomaly detection model quickly identifies anomalies by comparing call metrics with normal baselines in real time. Based on abnormal call behavior, it adjusts the de-identified call response accordingly, achieving both real-time risk blocking to enhance security and flexible response based on the scenario, thus enhancing real-time adaptability. In summary, this application comprehensively improves the security and real-time flexibility of data component calls throughout their entire lifecycle by covering all key stages of the data component delivery and call process, including transmission, storage, and invocation. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating the first embodiment of the data element delivery and invocation method of this application; Figure 2 A flowchart illustrating the second embodiment of the data element delivery and invocation method of this application; Figure 3 A flowchart illustrating the sixth embodiment of the data element delivery and invocation method of this application; Figure 4 A flowchart illustrating the seventh embodiment of the data element delivery and invocation method of this application; Figure 5 A simplified flowchart illustrating a data element delivery and invocation method is provided. Figure 6 This is a schematic diagram of the module structure of the data element delivery and invocation device according to an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the data element delivery and invocation method in this application embodiment.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of this application embodiment is: to obtain the data element delivery call request sent by the caller, and to verify the caller's permissions based on a preset permission model; under the condition that the caller's permissions are verified, to perform de-identified call on the mixed encrypted data element in the preset encrypted database according to the data element delivery call request; to input the indicator data generated in the de-identified call into a preset anomaly identification model to identify abnormal call behavior, and to adjust the abnormal response of the de-identified call based on the abnormal call behavior.

[0023] In this embodiment, for ease of description, the following description will focus on the data element delivery and invocation system as the execution subject.

[0024] This application's embodiments take into account the following: Mainstream data element invocation schemes only ensure security during transmission, but cannot monitor the storage status and invocation process of data elements. This results in the problem of secure transmission but uncontrolled use. Because security is only ensured during transmission, there are blind spots in protection, leading to a lack of early warning capabilities for abnormal behavior during data element invocation. Furthermore, mainstream data element invocation schemes typically employ static permission control, limiting the scope of data element invocation through a preset user permission list. Permission configuration relies on manual operation and cannot be dynamically adjusted, resulting in insufficient invocation flexibility.

[0025] Therefore, this application provides a solution where: firstly, permission verification, based on a pre-defined model, ensures the legitimacy of the calling entity. This model can be adjusted and is not limited to a fixed permission list. Secondly, de-identified calls reduce the risk of sensitive data exposure during the call process, strengthening security protection during the call phase. Thirdly, an encrypted database is used to store hybrid encrypted data components. Hybrid encryption and encrypted storage construct a security barrier for data transmission and storage, ensuring the static and dynamic security of data components. Furthermore, an anomaly detection model quickly identifies anomalies by comparing call metrics with normal baselines in real time. Based on the abnormal call behavior, the de-identified call is adjusted to respond to anomalies, achieving both real-time risk blocking to improve security and flexible response based on the scenario to enhance real-time adaptability. In summary, this application, by covering the key stages of the entire data component delivery and call process—transmission, storage, and call—combines these aspects to comprehensively improve the security and real-time flexibility of data component calls throughout their entire lifecycle.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or data element delivery and invocation system capable of performing the above functions. The following description uses a data element delivery and invocation system as an example to illustrate this embodiment and the subsequent embodiments.

[0027] Based on this, embodiments of this application provide a method for delivering and invoking data elements, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the data element delivery and invocation method of this application.

[0028] In this embodiment, the data element delivery and invocation method includes steps S10 to S30: Step S10: Obtain the data element delivery call request sent by the caller, and verify the caller's permissions based on a preset permission model; It should be noted that, in the embodiments of this application, the calling party refers to the subject that requests to use the data element; the data element delivery calling request refers to the request initiated by the calling party to obtain or use the data element; the preset permission model refers to the model that is set in advance to determine whether the calling party has permission to access the data element, such as the ABAC (Attribute-Based Access Control) model, etc.

[0029] By using a pre-defined permission model for verification, the legitimacy of the caller's identity and the scope of their permissions can be accurately determined, thereby improving the security of the data element calling process.

[0030] Specifically, the system receives a data element delivery request from the caller and extracts attributes such as the caller's identity information (e.g., company name, department, position), the call scenario (e.g., daily business, emergency handling), and the data element type. Then, based on a pre-defined ABAC permission model, the system matches the extracted attributes with preset permission rules to verify whether the caller has the corresponding call permissions.

[0031] In one possible implementation, the pre-defined permission model can adopt a hybrid model of RBAC (Role-Based Access Control) and ABAC, which adds attribute judgment on the basis of role presets. It is suitable for enterprises with clear role division and changing scenarios, and can still achieve dynamic permission management.

[0032] Step S20: Under the condition that the caller's permission verification is passed, the data element in the preset encrypted database is de-identified and called according to the data element delivery call request; It should be noted that, in the embodiments of this application, de-identified calling refers to a calling method that processes sensitive fields to avoid leakage of original data when calling data elements.

[0033] Over-identified calls can meet the business needs of the caller while avoiding the exposure of sensitive data, thus balancing the relationship between data use and security protection.

[0034] Additionally, it should be noted that the system employs a hybrid encryption method to process each newly created data element: the SM4 symmetric encryption algorithm is used to encrypt the content of the data element, and then the RSA asymmetric encryption algorithm is used to encrypt the SM4 key to prevent key leakage. Afterward, the encrypted data element is stored in an encrypted database. This database uses transparent data encryption technology to encrypt the database file in real time, and a storage access whitelist is set up to allow only authorized servers to access the storage address, further restricting unauthorized access.

[0035] In one possible implementation, the symmetric encryption algorithm in the hybrid encryption method can be replaced with the AES-256 algorithm (Advanced Encryption Standard 256-bit Algorithm), and the asymmetric encryption algorithm can be replaced with the ECC algorithm (Elliptic curve cryptography). Both alternative algorithms can achieve data encryption, and the only difference is in encryption efficiency and key length, without affecting the overall security protection effect.

[0036] By combining hybrid encryption and transparent data encryption, we can ensure the security of storage after data transmission and avoid data exposure caused by the leakage of physical database files, thereby filling the protection blind spot in the storage process.

[0037] Specifically, after the caller's permissions are verified, the system retrieves the corresponding encrypted data element from the encrypted database and decrypts it based on the data element identifier in the data element delivery call request. Then, the decrypted data element is anonymized, for example, sensitive fields (such as user ID number and bank card number) are replaced with virtual values. The anonymized data is then returned to the caller, while the call result and the scope of data usage are recorded.

[0038] In one possible implementation, the de-identified call can adopt a dynamic de-identification strategy, which determines the degree of de-identification based on the caller's permission level. For example, users with high-level permissions can obtain partially de-identified data, while users with ordinary permissions can obtain fully de-identified data.

[0039] Step S30: Input the indicator data generated in the de-identified call into a preset anomaly identification model to identify abnormal call behavior, and adjust the abnormal response of the de-identified call based on the abnormal call behavior.

[0040] It should be noted that, in the embodiments of this application, the indicator data refers to the monitorable data generated during the de-identification call process, such as call frequency, data flow direction, operation behavior, etc.; the pre-set anomaly identification model refers to the pre-trained model used to identify abnormal behavior, such as the LSTM model (Long Short-Term Memory Model); abnormal call behavior refers to call behavior that deviates from the normal behavior baseline; and abnormal response adjustment refers to the countermeasures taken for the identified abnormal behavior.

[0041] By identifying abnormal behavior through anomaly detection models, anomalies can be quickly discovered. Then, through response and adjustment measures, unauthorized calls can be blocked in real time, reducing losses.

[0042] Specifically, the system collects indicator data during the anonymized call process, including call frequency (number of calls per minute), data flow (caller IP address, region), and operational behavior (read, modify, copy). This indicator data is then input into a pre-set LSTM anomaly detection model and compared with a pre-established baseline of normal behavior within the LSTM anomaly detection model. When the indicator data deviates from the baseline by more than a preset threshold (e.g., call frequency exceeding the normal range by 2 times) or abnormal behavior occurs (e.g., unauthorized IP call), the model identifies it as an abnormal call behavior and triggers a three-level response mechanism: Level 1 anomalies send a warning SMS to the administrator; Level 2 anomalies temporarily freeze call permissions; Level 3 anomalies immediately interrupt data transmission and lock the relevant account.

[0043] In one possible implementation, the anomaly detection model can be replaced by an isolated forest model, which is more efficient in training scenarios with small sample data and is suitable for scenarios with low data element call frequency, while still achieving the function of anomaly behavior detection.

[0044] This embodiment provides a method for delivering and invoking data components. Permission verification, based on a pre-defined model, ensures the legitimacy of the calling entity. This model can be adjusted and is not limited to a fixed permission list. De-identified invoking reduces the risk of sensitive data exposure during the invoking process, strengthening security protection during the invoking phase. Secondly, an encrypted database is used to store hybrid encrypted data components. Hybrid encryption and encrypted storage construct a security barrier for data transmission and storage, ensuring both static and dynamic security of the data components. Furthermore, an anomaly detection model quickly identifies anomalies by comparing invoking metrics with a normal baseline in real time. Based on the abnormal invoking behavior, the de-identified invoking is adjusted to improve the anomaly response, achieving both real-time risk blocking to enhance security and flexible response based on the scenario, thus enhancing real-time adaptability. In summary, this application, by covering the key stages of the entire data component delivery and invoking process—transmission, storage, and invoking—comprehensively improves the security and real-time flexibility of data component invoking throughout its entire lifecycle.

[0045] Based on the first embodiment of this application, a second embodiment of this application is proposed. In the second embodiment of this application, content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter.

[0046] Based on this, please refer to Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the data element delivery and invocation method of this application.

[0047] In this embodiment, as Figure 2 As shown, before step S10, which involves obtaining the data element delivery request sent by the caller and verifying the caller's permissions based on a preset permission model, steps S11 to S15 may be included: Step S11: Add a unique identifier and data fingerprint to the data element; A unique identifier is a string used to uniquely identify a data element; a data fingerprint is a string generated by a hash algorithm that represents the uniqueness of the content of a data element.

[0048] By adding a unique identifier, each data element has a unique identity, which facilitates tracking during subsequent transmission, storage, and retrieval stages; data fingerprints can quickly verify whether the content of the data element has been modified, ensuring the authenticity of the data.

[0049] Specifically, when a data element is generated, the system automatically calls a UUID (Universally Unique Identifier) ​​generator to generate a unique identifier and binds it to the data element. At the same time, a hash algorithm is used to calculate the original content of the data element to obtain a data fingerprint. The unique identifier and the data fingerprint are stored in the metadata area of ​​the data element and associated with the content of the data element.

[0050] In one possible implementation, the unique identifier can be generated by combining the generating entity information of the data element (such as the generator ID) and the timestamp to further enhance uniqueness.

[0051] Step S12: Encrypt the data element with the added unique identifier and data fingerprint using a symmetric encryption algorithm; Symmetric encryption algorithms are characterized by high encryption efficiency and are suitable for encrypting large amounts of data elements, ensuring a balance between efficiency and security in data transmission and storage. Therefore, symmetric encryption algorithms are used to encrypt the content of data elements.

[0052] Specifically, the system calls the security encryption module, selects the SM4 symmetric encryption algorithm, and uses a randomly generated SM4 key to encrypt the content of the data element that has been given a unique identifier and data fingerprint, generating an encrypted content data block. The key is temporarily stored in the system's security key store.

[0053] In one possible implementation, the symmetric encryption algorithm can be AES-256, and the key can be rotated periodically, such as generating a new key every 24 hours, to further reduce the risk of key leakage; at the same time, a checksum can be added to the encrypted content data block to verify the data integrity during transmission.

[0054] Step S13: Encrypt the key of the symmetric encryption algorithm using an asymmetric encryption algorithm to obtain the hybrid encrypted data element; To address the risk of symmetric encryption key leakage during transmission, asymmetric encryption is used to protect the symmetric key. This combines the efficiency of symmetric encryption with the security of asymmetric encryption to achieve secure encryption of data elements.

[0055] Specifically, the system uses the public key of the RSA asymmetric encryption algorithm to encrypt the key of the symmetric encryption algorithm to generate an encrypted key block; then the encrypted content data block and the encrypted key block are combined to obtain a hybrid encrypted data element, and the two are associated through metadata.

[0056] In one possible implementation, the asymmetric encryption algorithm can be the ECC algorithm. ECC has a shorter key length but higher security, making it suitable for resource-constrained scenarios, such as mobile devices transmitting data elements. At the same time, a timestamp can be added to the encrypted key block to ensure the timeliness of the key.

[0057] Step S14: Establish a dedicated transmission channel according to the preset transmission control protocol; It should be noted that, in the embodiments of this application, the preset transmission control protocol refers to a pre-set protocol (such as the TCP protocol) used to regulate data transmission; the dedicated transmission channel refers to a network channel specifically used for transmitting hybrid encrypted data elements, blocking unauthorized port access.

[0058] By establishing a dedicated transmission channel, other unrelated data transmissions are isolated, reducing security risks during transmission and ensuring that the encrypted data elements are successfully transmitted to the target storage location.

[0059] Specifically, the system calls the network module to create a dedicated transmission channel based on preset TCP protocol parameters, sets an access whitelist for the channel, and only allows authorized sender and receiver IP addresses to access the channel, while blocking access requests from non-preset ports to prevent access from illegal ports.

[0060] Step S15: The hybrid encrypted data element is stored in the encrypted database through the dedicated transmission channel, and the encrypted database is encrypted in real time using transparent data encryption.

[0061] Transparent data encryption technology automatically encrypts database files during storage and decrypts them during retrieval, making them transparent to the application layer. This ensures security without affecting efficiency.

[0062] Specifically, the system sends the hybrid encrypted data elements to the encrypted database server through a dedicated transmission channel; the encrypted database uses transparent data encryption technology to encrypt the physical files of the database (such as data files and log files) in real time; at the same time, it sets access permissions for the database, allowing only authorized application accounts to access the database, further restricting unauthorized access.

[0063] In one possible implementation, the encrypted database can employ a distributed storage architecture, where the hybrid encrypted data elements are sharded and stored on multiple nodes, with each node applying transparent data encryption to further improve storage security and reliability; or the database can be backed up periodically, and the backup files can also be transparently encrypted to prevent backup file leakage.

[0064] In this embodiment, a unique identifier and data fingerprint are added to each data element to ensure traceability and content integrity throughout its entire lifecycle. A hybrid encryption scheme is adopted, using symmetric encryption to ensure content encryption efficiency and asymmetric encryption to protect key security. A dedicated transmission channel is established to isolate unauthorized access. The hybrid-encrypted data element is stored in a transparent encrypted database through this dedicated channel to prevent storage file leakage. This fills the protection blind spots in the encryption, transmission, and storage stages of data elements, ensuring the security, integrity, and compliance of data elements during transmission and storage.

[0065] Based on the first and / or second embodiments of this application, a third embodiment of this application is proposed. In this third embodiment, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0066] In this embodiment, step S10, which verifies the caller's permissions based on a preset permission model, may include steps S21 to S24: Step S21: Determine the current invocation scenario based on the data element delivery invocation request; Identify the current invocation scenario to ensure that permission adjustments are highly matched with the actual invocation scenario, thereby improving the flexibility and accuracy of permission control and avoiding the risk of business disruption or data leakage caused by redundant or insufficient permissions.

[0067] Specifically, the system extracts scenario-related parameters from the data element delivery call request, including the call time (whether it is during working hours on weekdays), the reason for the call (such as "emergency risk investigation" in the text label), and the department to which the caller belongs (such as the risk control department or the operations department). Then, these parameters are matched with a preset scenario classification library (including categories such as daily business, emergency handling, and audit query) to determine the specific type of the current call scenario.

[0068] Step S22: Invoke the permission model and adjust the permission rules corresponding to the current invocation scenario based on the permission model; By dynamically adjusting permission rules based on the current scenario, the problem of static permissions being unable to adapt to changes in the scenario is solved, thereby allowing permission rules to change flexibly with the scenario and improving the adaptability of permission control and business support capabilities.

[0069] Specifically, the system calls the permission model and retrieves the basic permission rules corresponding to the current call scenario from the model. Then, it adjusts the rule parameters according to the urgency of the scenario or business needs. For example, in an emergency scenario, the call frequency limit is increased from 5 times per minute to 20 times, or access to more sensitive fields is allowed. The adjusted rules take effect temporarily and only apply to this call process.

[0070] In one possible implementation, a priority for permission adjustment can be set for each scenario. For example, emergency scenarios have a higher priority than routine scenarios. When multiple scenario conditions overlap, the highest priority adjustment rule is executed to ensure the rationality of permission adjustment and business continuity.

[0071] Step S23: Perform multi-factor permission verification on the caller by combining the adjusted permission rules and the preset permission attribute dimensions of the permission model; The preset permission attribute dimensions of the permission model refer to the verification dimensions pre-set in the model (such as caller identity, data element type, time range); multi-factor permission verification refers to permission checks that combine multiple attribute dimensions.

[0072] Multi-dimensional verification ensures the legitimacy of the caller's permissions, improves the accuracy of permission verification, effectively prevents unauthorized calls, and safeguards the access security of data components.

[0073] Specifically, the system obtains preset permission attribute dimensions (such as caller identity, call scenario, data element type, and time range) from the permission model; collects corresponding attribute information of the caller (such as identity as a risk control department employee, scenario as emergency handling, and data element type as sensitive data); and verifies each dimension in conjunction with the adjusted permission rules (such as checking whether the identity is in the authorization list and whether the scenario matches the rules); if all dimensions pass the verification, it is determined that the multi-factor verification has passed.

[0074] In one possible implementation, dynamic token verification can be introduced as an additional dimension. The caller needs to provide a dynamic token generated based on a timestamp, and the system verifies the token's validity, further enhancing the security of the verification.

[0075] Step S24: If the multi-factor permission verification passes, then proceed to step: De-identify and call the data element in the encrypted database according to the data element delivery call request.

[0076] Once the multi-factor authentication is successful, the system retrieves the corresponding encrypted data element from the encrypted database based on the data element identifier in the request; performs de-identification processing on the data element; returns the de-identified data to the caller and records the call log, i.e., executes the subsequent steps: de-identifying and calling the data element in the encrypted database according to the data element delivery call request.

[0077] In one possible implementation, the degree of data masking can be adjusted according to the user's access level. For example, users with high access can obtain partially masked data, while ordinary users can obtain fully masked data, thus improving the flexibility of data masking.

[0078] In this embodiment, the current invocation scenario is determined to provide a precise basis for dynamic adjustment of permissions; the corresponding rules are adjusted based on the scenario-based invocation permission model to adapt to the needs of different business scenarios; permission verification is performed by combining the adjusted rules with multi-dimensional attributes to improve verification accuracy; after successful verification, de-identified invocation is executed to ensure secure data use. This achieves scenario-based dynamic adaptation of permissions, meeting the business support needs of different scenarios such as emergency response and daily operations, while preventing permission abuse and data leakage, thus enhancing the flexibility and security of permission management.

[0079] Based on the above embodiments of this application, a fourth embodiment of this application is proposed. In this fourth embodiment, content that is the same as or similar to that in the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0080] In this embodiment, under the condition that the caller's permission verification is passed, step S20, which involves de-identifying and calling a hybrid encrypted data element in a pre-encrypted database according to the data element delivery call request, may include steps S31 to S33: Step S31: Determine the data element to be invoked based on the data element delivery invocation request, and locate the sensitive fields in the data element to be invoked according to the preset sensitive data rules; The system first parses the component identifier in the data component delivery call request and matches the corresponding data component to be called from the encrypted database; then it loads the preset sensitive data rules, traverses all fields of the data component to be called, compares the field content with the sensitive information features in the rules, and marks the sensitive fields that meet the rules.

[0081] In one possible implementation, the preset sensitive data rules can be dynamically updated in conjunction with a machine learning model. The system periodically analyzes the identification of sensitive data in the call logs and automatically supplements any uncovered sensitive field rules, thereby improving the accuracy and comprehensiveness of sensitive field location.

[0082] Step S32: Replace the sensitive fields in the data element to be called with virtual values ​​of the same format to obtain the desensitized data element; A dummy value with the same format refers to a substitute value that has the same format as the original content of the sensitive field but has no practical meaning.

[0083] The system iterates through the marked sensitive fields in the data element to be called, and generates corresponding virtual values ​​according to the original format of each sensitive field. For example, the mobile phone number field generates an 11-digit random number, and the ID card number field generates an 18-digit virtual number that conforms to the verification rules. Then, the original content of the sensitive fields is replaced with the generated virtual values, while the content of other non-sensitive fields of the data element remains unchanged, thus obtaining the desensitized data element.

[0084] Step S33: Retrieve the de-identified data element from the encrypted database according to the data element delivery call request.

[0085] The system verifies whether the caller's permissions are valid. If the verification is successful, the system returns the de-identified data element to the caller in a specified format according to the parameters in the data element delivery call request. At the same time, the system records the call log, including the call time, the caller's identity, the de-identified data element identifier, and other information for subsequent auditing and tracing.

[0086] In this embodiment, the component to be invoked is determined based on the invocation request, and sensitive fields are accurately located, providing a targeted objective for subsequent data masking. Sensitive fields are replaced with consistent virtual values, protecting user privacy and corporate secrets while maintaining the structural integrity of the data component, ensuring that the caller's business processes are not affected. The masked component is then invoked to complete delivery, enabling secure data use. This overall solution effectively fills the gap in sensitive data protection during the invocation process in existing technologies.

[0087] Based on the above embodiments of this application, a fifth embodiment of this application is proposed. In this fifth embodiment, content that is the same as or similar to that in the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0088] In this embodiment, step S30, which involves inputting the indicator data generated during the de-identified call into a preset anomaly identification model to identify abnormal call behavior and adjusting the abnormal response of the de-identified call based on the abnormal call behavior, may include steps S41 to S43: Step S41: Call the pre-built streaming computing framework to collect the indicator data generated during the de-identification call; A pre-built streaming computing framework refers to a Flink computing architecture that is pre-deployed for real-time processing of continuous data streams.

[0089] By calling a pre-built streaming computing framework, key data during the anonymization process can be obtained in real time, providing basic support for subsequent anomaly identification. This solves the problem of high latency in traditional offline data collection, ensures the timeliness of anomaly identification, and avoids the failure to detect abnormal behavior in a timely manner due to data lag.

[0090] Specifically, the system calls a pre-built streaming computing framework. The framework collects corresponding indicator data from various nodes, including the initiation of the de-identified call, the data transmission, and the result return, through preset collection rules, including specifying the type of indicator to be collected and the collection frequency. After collection, the framework organizes the data into a structured format according to the time series and stores it in a temporary data buffer for subsequent steps to read and use.

[0091] Step S42: Input the indicator data into the anomaly identification model, and use the anomaly identification model to perform time-series feature matching between the indicator data and the normal behavior baseline to identify abnormal calling behavior; Time-series feature matching refers to comparing real-time indicator data with the characteristics of the normal behavior baseline in chronological order; abnormal call behavior refers to de-identified call operations that deviate from the normal behavior baseline, such as ultra-high frequency calls and abnormal IP calls.

[0092] It can identify abnormal behavior in de-identified calls in real time, solving the problem that traditional post-event auditing cannot detect anomalies in a timely manner, realizing real-time detection of abnormal behavior, and preventing data leakage or abuse.

[0093] The system inputs the collected indicator data into the anomaly identification model. The model first extracts time-series features from the indicator data, such as the trend of call frequency changes and response time fluctuations. Then, the model matches the extracted features with the features of the normal behavior baseline and calculates the deviation. When the deviation exceeds the preset threshold, the model outputs the result and type of the abnormal call behavior.

[0094] In one possible implementation, an attention mechanism is added during temporal feature matching, allowing the model to focus on feature dimensions that deviate significantly, thereby improving the accuracy of anomaly detection.

[0095] Step S43: Trigger a multi-level exception response mechanism based on the abnormal call behavior, and adjust the abnormal response of the de-identified call according to the multi-level exception response mechanism.

[0096] A multi-level anomaly response mechanism refers to a pre-defined response level based on the severity of the anomaly; anomaly response adjustment refers to the handling measures taken for de-identified calls based on the response level.

[0097] By taking appropriate response measures based on the severity of the anomaly, we can solve the problem that traditional single response methods cannot adapt to different anomaly scenarios, achieve accurate response, avoid over-response affecting business, and prevent under-response from causing further losses.

[0098] Specifically, the system matches the corresponding multi-level exception response mechanism level based on the severity of the identified abnormal call behavior, such as the degree of deviation and the type of exception; then it executes the response measures corresponding to the level to adjust the status of the de-identified call.

[0099] In one possible implementation, an automatic escalation mechanism for abnormal behavior is added. When the same abnormal behavior occurs repeatedly within a preset time, the response level is automatically upgraded. For example, if a level 1 abnormality occurs 3 times, it is upgraded to level 2.

[0100] In one feasible implementation, step S43 may include steps S431 to S433: Step S431: If the multi-level anomaly response mechanism is a preset level 1 response, a potential risk warning is generated and the potential risk warning is sent to the visual operation interface in a visual form. The preset Level 1 response refers to the mildest response level in the multi-level anomaly response mechanism; potential risk alerts refer to reminder messages generated for minor anomalies; visualization refers to displaying information in an intuitive way, such as using charts and pop-ups; and the visual operation interface refers to a web-based dashboard for administrators to operate and monitor.

[0101] After the system determines that a preset level 1 response has been triggered, it generates a potential risk warning that includes the anomaly type, occurrence time, and relevant indicator data. The warning is then converted into a visual format and sent to the warning notification bar of the visual operation interface.

[0102] Step S432: If the multi-level exception response mechanism is a preset level 2 response, then freeze the de-identification call permission in the permission model to suspend the de-identification call; The preset level 2 response refers to the moderate severity response level in the multi-level anomaly response mechanism; pausing the de-identification call means temporarily stopping the current de-identification call operation.

[0103] After the system determines that a preset level 2 response has been triggered, it uses the access permission model to find the corresponding de-identification call permission entry and sets its status to "frozen". Then, it prevents the caller from continuing to initiate de-identification calls, suspends the currently ongoing de-identification call operation, and records the freezing time and reason.

[0104] Step S433: If the multi-level exception response mechanism is a preset three-level response, then the desensitization call is interrupted.

[0105] The preset three-level response refers to the most severe response level in the multi-level abnormal response mechanism; interrupting the de-identification call means immediately stopping the current de-identification call operation and disconnecting the data transmission channel.

[0106] After the system determines that a preset level 3 response has been triggered, it sends an interrupt command to the de-identification call execution module. Upon receiving the command, the execution module disconnects the data transmission connection, terminates data processing and return operations, releases relevant system resources, and records detailed interrupt information.

[0107] In this embodiment, a streaming computing framework is used to collect call indicator data in real time, providing timely and comprehensive basis for anomaly identification. The LSTM anomaly identification model is used to match the indicator data with the normal behavior baseline in time, accurately identifying risky behaviors such as ultra-high frequency calls and abnormal IPs, solving the problem of high latency in offline auditing. A three-level response mechanism (early warning, freezing permissions, interrupting calls) is triggered, and the handling measures are dynamically adjusted according to the severity of the anomaly, which avoids excessive response affecting business and can block major risks in real time.

[0108] Based on the above embodiments of this application, a sixth embodiment of this application is proposed. In the sixth embodiment of this application, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0109] Based on this, please refer to Figure 3 , Figure 3 This is a flowchart illustrating the sixth embodiment of the data element delivery and invocation method of this application.

[0110] In this embodiment, as Figure 3 As shown, before step S30, which involves inputting the indicator data generated during the de-identified call into a preset anomaly detection model to identify abnormal call behavior, steps S01 to S04 are also included: Step S01: Deploy a distributed cluster to build a streaming computing framework; A distributed cluster refers to a collaborative computing system composed of multiple independent computer nodes connected via a network. A streaming computing framework refers to a software architecture used for real-time processing of continuous data streams.

[0111] The system selects the Kubernetes distributed cluster deployment solution, installs the Flink streaming computing framework in the cluster, configures the number of nodes, resource allocation, and data transmission protocol, and completes the framework initialization and startup. Kubernetes is an open-source container orchestration platform.

[0112] In one possible implementation, the system incorporates a dynamic cluster node expansion mechanism, which automatically adjusts the number of nodes based on real-time data traffic to improve resource utilization.

[0113] Step S02: Collect historical normal behavior data based on the streaming computing framework, the historical normal behavior data covering the entire lifecycle of data elements; Historical normal behavior data refers to the operation records of data elements that conform to normal business rules throughout their entire lifecycle; the entire lifecycle of a data element refers to the process from the generation to the destruction of the data element, including five stages: generation, transmission, storage, retrieval, and destruction.

[0114] The system connects to the log systems of each lifecycle stage of the data element through the data source access module of the streaming computing framework, sets collection rules, such as collecting once per minute, and collects and stores the normal behavior data of each stage in real time into the distributed database.

[0115] In one possible implementation, the system incorporates a data cleaning and preprocessing step to automatically filter duplicate records and erroneous data, thereby improving data quality.

[0116] Step S03: Construct a model training dataset based on the historical normal behavior data; The system preprocesses historical normal behavior data: unstructured logs are converted into JSON format, features such as call frequency and response time are extracted, and 70% is divided into a training set and 30% into a validation set to form a model training dataset.

[0117] Step S04: Use the model training dataset to train a long short-term memory network model to establish a normal behavior baseline, and construct an anomaly recognition model based on the long short-term memory network model with the normal behavior baseline.

[0118] The system inputs the training dataset into the Long Short-Term Memory network model, sets the learning rate and the number of iterations, and trains the model to learn the temporal features of normal behavior based on the learning rate and the number of iterations. When the training error reaches the threshold, the training stops, and the feature set output by the model is the baseline of normal behavior. An anomaly recognition model is then built based on this baseline.

[0119] In one possible implementation, the system incorporates an early stopping mechanism to prevent overfitting, stopping training when the validation set error fails to decrease for several consecutive rounds.

[0120] In this embodiment, a distributed cluster is deployed to build a streaming computing framework, providing underlying support for real-time data acquisition and efficient processing. Based on this framework, historical normal behavior data covering the entire lifecycle of data elements is collected to ensure the comprehensiveness and representativeness of training data. A model training dataset is constructed to train an LSTM model to establish a baseline of normal behavior and form an anomaly recognition model. This solves the problems of weak anomaly recognition data foundation and insufficient model accuracy in mainstream solutions, achieving full lifecycle security protection and second-level anomaly response.

[0121] Based on the above embodiments of this application, a seventh embodiment of this application is proposed. In this seventh embodiment, content that is the same as or similar to the above embodiments can be referred to the above description, and will not be repeated hereafter.

[0122] Based on this, please refer to Figure 4 , Figure 4 This is a flowchart illustrating the seventh embodiment of the data element delivery and invocation method of this application.

[0123] In this embodiment, as Figure 4 As shown, after step S30 of adjusting the abnormal response of the de-identified call based on the abnormal call behavior, steps S40 to S70 are further included: Step S40: Generate the full lifecycle operation log of the data element, and store the full lifecycle operation log in the log database in the form of blockchain evidence storage; The system automatically triggers log generation at each stage of the data element's lifecycle: generation, transmission, storage, retrieval, and destruction. Each log entry contains information such as the operation subject (e.g., account, IP address), operation time, operation type (e.g., generation, transmission), and operation result (e.g., success, failure). Subsequently, the system converts the logs into a blockchain-compatible structured format and writes them to blockchain nodes through smart contracts. Simultaneously, the logs are stored synchronously in the log database, achieving dual storage protection.

[0124] In one possible implementation, a digital signature of the operating entity can be added when generating the log to ensure the authenticity of the log source. The log with the digital signature is then stored on the blockchain to further enhance the credibility of the log.

[0125] Step S50: Obtain a log query request through the multidimensional log query interface; The system provides a multi-dimensional log query interface based on RESTful architecture (Representational State Transfer Architecture). The interface supports query parameters including data element ID, operation time range, operation subject account, operation type, and exception flag. Administrators can pass query parameters that meet the format requirements through this interface. The system receives and parses the request and extracts key query conditions.

[0126] Step S60: Retrieve the full lifecycle operation log from the log database according to the log query request; The system generates a corresponding database query statement based on the parameters in the parsed log query request, and then retrieves the full lifecycle operation logs that meet the conditions from the log database. After the retrieval is completed, the system sorts the log results in chronological order and returns them to the requester.

[0127] Step S70: Generate a compliance traceability report based on the full lifecycle operation log.

[0128] The system extracts key information from the entire lifecycle operation log, including basic information of data elements, operation records at each stage, and abnormal operation records; then it generates a compliance traceability report according to the preset compliance report template.

[0129] In this embodiment, by generating a full lifecycle operation log of the data element and storing it on the blockchain to ensure its immutability, and by combining a multi-dimensional query interface to quickly obtain the target log, a compliance traceability report is finally generated. This collaboratively achieves full traceability of data element operations, reliable logs, and compliance audit support, providing a reliable compliance basis and traceability capability for the secure delivery and use of data elements.

[0130] In one possible implementation, step A40 is included after step S30: Step A40 involves physically deleting obsolete data elements using a multiple-write method.

[0131] The multiple overwrite method refers to the operation of repeatedly overwriting the storage area where the discarded data element is located using random data or specific pattern data, with the aim of completely erasing the original data traces.

[0132] Specifically, the system first identifies the storage location corresponding to the abandoned data element, then uses a preset overwrite mode to overwrite the storage location multiple times; finally, it performs a physical deletion operation, which includes low-level disk formatting, hardware-level data erasure, etc., and deletes all associated logs and identification information of the abandoned data element to ensure that the data cannot be recovered.

[0133] For example, to help understand the implementation flow of the data element delivery and invocation method described in the above embodiments of this application, please refer to... Figure 5 , Figure 5 A simplified flowchart illustrating a data element delivery and invocation method is provided, such as... Figure 5 As shown, specifically, this application covers security protection for five stages: data element generation, transmission, storage, retrieval, and destruction. Generation phase: A unique identifier and data fingerprint are automatically added to newly created data elements, and the generation time and generation subject information are recorded to ensure that the data elements are traceable.

[0134] During the transmission phase: A hybrid encryption scheme of "symmetric encryption + asymmetric encryption" is adopted. The SM4 algorithm is used to encrypt the content of the data element, and the RSA algorithm is used to encrypt the SM4 key to avoid key leakage during transmission and data cracking. At the same time, a dedicated transmission channel is established through the TCP protocol to block unauthorized port access.

[0135] Storage phase: Data elements are stored in an encrypted database. Transparent data encryption technology is used to encrypt the database file in real time, so that even if the physical database file is stolen, the data content cannot be decrypted. At the same time, a storage access whitelist is set to allow only authorized servers to access the storage address.

[0136] Invocation Phase: After the caller initiates a request, the access control model based on ABAC attributes checks the caller's identity, scenario (e.g., routine / emergency), and component type (public / sensitive) to determine whether authorization is granted. Furthermore, the permission model can automatically adjust permissions as the invocation scenario changes, and lower the permission level in case of abnormal behavior.

[0137] If the caller's permissions are verified, the data element is de-identified before being called to avoid leakage of the original data; after the call, the call result and the scope of data use are automatically recorded.

[0138] During the data masking process, real-time monitoring and anomaly warning are achieved based on the Flink streaming computing framework and LSTM anomaly detection model. Four core metrics are collected: data element delivery speed, call frequency, data flow direction, and operational behavior. These metrics are then analyzed in real-time using the streaming computing engine. Anomalies are identified using a baseline of normal behavior established in the LSTM anomaly detection model. Upon anomaly identification, a three-level response mechanism is triggered to immediately adjust the data masking process.

[0139] Destruction phase: The "multiple overwrites + physical deletion" method is used to completely destroy the discarded data elements, and at the same time delete all associated logs and identification information to prevent data remnants from being recovered.

[0140] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data element delivery and invocation method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0141] This application also provides a data element delivery and retrieval device; please refer to... Figure 6 The data element delivery and invocation device includes: The permission verification module 10 is used to obtain the data element delivery call request sent by the caller and perform permission verification on the caller based on a preset permission model. The de-identification invocation module 20 is used to de-identify and invoke the mixed encrypted data element in the preset encrypted database according to the data element delivery invocation request, provided that the invocation party's permission verification is passed; The anomaly monitoring module 30 inputs the indicator data generated during the de-identified call into a preset anomaly identification model to identify abnormal call behavior, and adjusts the abnormal response of the de-identified call based on the abnormal call behavior.

[0142] The data element delivery and invocation apparatus provided in this application, employing the data element delivery and invocation method described in the above embodiments, can solve the technical problem of data element delivery and invocation. Compared with the prior art, the beneficial effects of the data element delivery and invocation apparatus provided in this application are the same as those of the data element delivery and invocation method described in the above embodiments, and other technical features in the data element delivery and invocation apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0143] This application provides a data element delivery and invocation device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the data element delivery and invocation method in Embodiment 1 above.

[0144] The following is for reference. Figure 7This document illustrates a structural diagram of a data element delivery and retrieval device suitable for implementing embodiments of this application. The data element delivery and retrieval device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The data element delivery and calling device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0145] like Figure 7 As shown, the data element delivery and retrieval device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the data element delivery and retrieval device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the data element delivery calling device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows data element delivery calling devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0146] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0147] The data element delivery and invocation device provided in this application, employing the data element delivery and invocation method described in the above embodiments, can solve the technical problem of data element delivery and invocation. Compared with the prior art, the beneficial effects of the data element delivery and invocation device provided in this application are the same as those of the data element delivery and invocation method described in the above embodiments, and other technical features of the data element delivery and invocation device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0148] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0149] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0150] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data element delivery invocation method described in the above embodiments.

[0151] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0152] The aforementioned computer-readable storage medium may be included in the data element delivery and invocation device; or it may exist independently and not assembled into the data element delivery and invocation device.

[0153] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the data element delivery calling device, the data element delivery calling device performs the following: obtains a data element delivery calling request sent by the caller; verifies the caller's permissions based on a preset permission model; under the condition that the caller's permissions are verified, performs de-identified calling on the hybrid encrypted data element in the preset encrypted database according to the data element delivery calling request; inputs the indicator data generated in the de-identified calling into a preset anomaly identification model to identify abnormal calling behavior, and adjusts the abnormal response of the de-identified calling based on the abnormal calling behavior.

[0154] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0156] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0157] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data element delivery and invocation method, thereby solving the technical problem of data element delivery and invocation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the data element delivery and invocation method provided in the above embodiments, and will not be repeated here.

[0158] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data element delivery invocation method described above.

[0159] The computer program product provided in this application can solve the technical problem of data element delivery and invocation. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the data element delivery and invocation method provided in the above embodiments, and will not be repeated here.

[0160] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for delivering and invoking data components, characterized in that, The data element delivery and invocation method includes: Obtain the data element delivery request sent by the caller, and verify the caller's permissions based on a preset permission model; Under the condition that the caller's permission verification is passed, the data element delivered in the data element call request is used to de-identify the data element in the pre-encrypted database and call it. The indicator data generated during the de-identified call is input into a preset anomaly identification model to identify abnormal call behavior, and the de-identified call is adjusted to make abnormal response based on the abnormal call behavior.

2. The data element delivery and invocation method as described in claim 1, characterized in that, Before the step of obtaining the data element delivery request sent by the caller and verifying the caller's permissions based on a preset permission model, the following steps are also included: Add a unique identifier and data fingerprint to the data element; A symmetric encryption algorithm is used to encrypt the content of the data element with the added unique identifier and data fingerprint; The key of the symmetric encryption algorithm is encrypted using an asymmetric encryption algorithm to obtain a hybrid encrypted data element; Establish a dedicated transmission channel according to the preset transmission control protocol; The hybrid encrypted data elements are stored in the encrypted database through the dedicated transmission channel, and the encrypted database is encrypted in real time using transparent data encryption.

3. The data element delivery and invocation method as described in claim 1, characterized in that, The step of verifying the caller's permissions based on a pre-defined permission model includes: The current invocation scenario is determined based on the data element delivery invocation request; Invoke the permission model and adjust the permission rules corresponding to the current invocation scenario based on the permission model; The caller is subjected to multi-factor permission verification by combining the adjusted permission rules and the preset permission attribute dimensions of the permission model; If the multi-factor permission verification passes, then the following step is executed: de-identify and call the data element in the encrypted database according to the data element delivery call request.

4. The data element delivery and invocation method as described in claim 1, characterized in that, The step of de-identifying and calling the hybrid encrypted data element in the pre-set encrypted database according to the data element delivery call request includes: Based on the data element delivery call request, the data element to be called is determined, and the sensitive fields in the data element to be called are located according to the preset sensitive data rules; The sensitive fields in the data element to be invoked are replaced with virtual values ​​of the same format to obtain the desensitized data element; The de-identified data element is retrieved from the encrypted database according to the data element delivery request.

5. The data element delivery and invocation method as described in claim 1, characterized in that, The step of inputting the indicator data generated during the de-identified call into a preset anomaly identification model to identify abnormal call behavior, and adjusting the abnormal response of the de-identified call based on the abnormal call behavior, includes: The pre-built streaming computing framework is invoked to collect the indicator data generated during the de-identified call; The indicator data is input into the anomaly identification model, and the anomaly identification model is used to match the indicator data with the normal behavior baseline in terms of time-series features to identify abnormal calling behavior. Based on the abnormal call behavior, a multi-level exception response mechanism is triggered, and the anomaly response to the de-identified call is adjusted according to the multi-level exception response mechanism.

6. The data element delivery and invocation method as described in claim 5, characterized in that, The step of adjusting the anomaly response of the de-identified call according to the multi-level anomaly response mechanism includes: If the multi-level anomaly response mechanism is a preset level one response, a potential risk warning is generated and sent to the visual operation interface in a visual form. If the multi-level exception response mechanism is a preset level 2 response, then the de-identification call permission in the permission model is frozen to suspend the de-identification call; If the multi-level exception response mechanism is a preset three-level response, then the de-identification call will be interrupted.

7. The data element delivery and invocation method as described in claim 5, characterized in that, Before the step of inputting the indicator data generated in the de-identified call into a preset anomaly identification model to identify abnormal call behavior, the method further includes: Deploy a distributed cluster to build a streaming computing framework; Historical normal behavior data is collected based on the streaming computing framework, and the historical normal behavior data covers the entire lifecycle of data elements; A training dataset for the model is constructed based on the aforementioned historical normal behavior data; The Long Short-Term Memory (LSTM) network model is trained using the model training dataset to establish a baseline for normal behavior, and an anomaly detection model is constructed based on the LTM network model with the baseline for normal behavior.

8. The data element delivery and invocation method as described in claim 1, characterized in that, Following the step of adjusting the abnormal response to the de-identified call based on the abnormal call behavior, the method further includes: Generate a full lifecycle operation log for the data element and store the full lifecycle operation log in the log database in the form of blockchain evidence storage; Obtain log query requests through the multidimensional log query interface; The full lifecycle operation log is retrieved from the log database according to the log query request. A compliance traceability report is generated based on the full lifecycle operation logs.

9. A data element delivery and retrieval device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data element delivery invocation method as claimed in any one of claims 1 to 8.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the data element delivery invocation method as described in any one of claims 1 to 8.

Images