Data transmission and storage method, device, equipment, medium and product of ERP system

Abstract

This application provides a data transmission and storage method, apparatus, device, medium, and product for an ERP system. It relates to the field of information security technology. The method includes: in response to data transmission between departments, encrypting the data to be transmitted based on the transmission key corresponding to the data sender to generate an encrypted transmission file; the transmission key is generated based on the transmission key corresponding to the data sender's immediate superior role and the data sender's role attributes; in response to the existence of data to be stored, generating a first protection key and a second protection key based on the storage key corresponding to the data storage provider; the storage key is generated based on the storage key corresponding to the data storage provider's immediate superior role and the data storage provider's role attributes; and generating an encrypted storage file using a preset cryptographic algorithm based on the first and second protection keys. This application significantly improves the data security of enterprise ERP systems through a role-based key derivation mechanism and a full lifecycle management strategy.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a data transmission and storage method, apparatus, equipment, medium and product for an ERP system. Background Technology

[0002] In large group enterprises operating across regions and departments, the need for collaborative operations among multiple branches is becoming increasingly prominent. Branches in different regions or business lines often deploy independent ERP subsystems, requiring frequent data interaction and sharing. For example, subsidiaries report financial data to headquarters, and headquarters distributes supplier information to subordinate units to support business decisions. The complex organizational structure and frequent dynamic adjustments of such enterprises place stringent requirements on the security of data transmission and storage, as well as the adaptability of access control in the ERP system.

[0003] Currently, some solutions have been developed for secure data transmission in ERP systems. The core of these solutions is to dynamically generate an independent key for each piece of data to be transmitted through an encryption center. The sender uses this key to encrypt the data before transmission, and the receiver obtains the corresponding key from the key center to complete the decryption. Data transmission between departments or subordinate units and headquarters often relies on pre-distributed shared keys, combined with asymmetric encryption algorithms to achieve encrypted transmission. Some solutions also standardize the key application and usage process through the collaboration of a unified gateway and encryption center.

[0004] However, the relevant technologies lack encryption protection for stored data, making it difficult to cover the security needs of the entire data lifecycle; the generation and distribution of keys cannot naturally adapt to the dynamic changes in organizational structure, resulting in a disconnect between access control and business needs. Summary of the Invention

[0005] The data transmission and storage methods, apparatus, devices, media, and products for ERP systems provided in this application are intended to address the problems of inadequate storage security and disconnected access control.

[0006] In a first aspect, embodiments of this application provide a data transmission and storage method for an ERP system, the method comprising:

[0007] In response to data transmission between departments, the data to be transmitted is encrypted based on the transmission key corresponding to the data sender to generate an encrypted transmission file. The transmission key is generated based on the transmission key corresponding to the direct superior role of the data sender and the role attribute of the data sender.

[0008] In response to the existence of data to be stored, a first protection key and a second protection key are generated based on the storage key corresponding to the data storage provider. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attribute of the data storage provider.

[0009] An encrypted storage file is generated using a preset cryptographic algorithm based on the first protection key and the second protection key.

[0010] In one possible implementation, encrypting the data to be transmitted based on the transmission key corresponding to the data sender to generate an encrypted transmission file includes:

[0011] If the data sender is a superior role and the data receiver is a subordinate role, a shared transmission key is generated based on the transmission key corresponding to the data sender and the role attribute corresponding to the data receiver. The data to be transmitted is then encrypted using the shared transmission key so that it can be decrypted based on the transmission key corresponding to the data receiver.

[0012] If the data sender is a subordinate role and the data receiver is a superior role, the data to be transmitted is encrypted using the transmission key corresponding to the data sender, so that it can be decrypted using the transmission key corresponding to the data receiver.

[0013] In one possible implementation, the encrypted storage file further includes an identity tag, which includes the data storage provider's role code, department code, and a preset cryptographic algorithm identifier. After generating the encrypted storage file using the preset cryptographic algorithm based on the first and second protection keys, the process further includes:

[0014] If the data acquisition party is of the same level as the data storage party, then a first protection key and a second protection key are generated based on the identity tag and the storage key corresponding to the data acquisition party, so as to decrypt the encrypted storage file using the first protection key and the second protection key;

[0015] If the data acquisition party is the superior role of the data storage party, then the storage key corresponding to the data storage party is generated in reverse based on the identity tag, and a first protection key and a second protection key are generated based on the storage key corresponding to the data storage party, so as to decrypt the encrypted storage file using the first protection key and the second protection key.

[0016] In one possible implementation, it also includes:

[0017] In response to data sharing across departments, a temporary data sharing key is generated based on the data collaboration key and the role information to be shared. The data collaboration key is generated based on the root key using a preset key derivation function and is only owned by the highest-level manager of each department.

[0018] The data to be shared is encrypted using the temporary data sharing key, and then decrypted based on the temporary data sharing key and the role attributes of the data recipient, including department code, role code, and registration time.

[0019] In one possible implementation, it also includes:

[0020] In response to the expiration of the validity period of the target role's transmission key and storage key, the transmission key and storage key are updated based on the transmission key and storage key corresponding to the target role's direct superior role and the target role's role attributes.

[0021] If the target role has a corresponding subordinate role, then the transmission key and storage key of each subordinate role are updated synchronously.

[0022] The target role's historical encrypted storage files are re-encrypted based on the updated storage key.

[0023] In one possible implementation, the data to be stored is dynamically updated data, and the method further includes:

[0024] In response to an update event of the data to be stored, the first protection key and the second protection key are regenerated based on the storage key and role attributes of the data storage provider and the update identifier;

[0025] The first protection key, the second protection key, and the update identifier before and after the update are associated and stored as a historical key, so that the data update trajectory can be viewed based on the historical key.

[0026] Secondly, embodiments of this application provide a data transmission and storage device for an ERP system, comprising:

[0027] The encryption module is used to encrypt the data to be transmitted based on the transmission key corresponding to the data sender in response to data transmission between the same departments, so as to generate an encrypted transmission file. The transmission key is generated based on the transmission key corresponding to the direct superior role of the data sender and the role attribute of the data sender.

[0028] The generation module is used to generate a first protection key and a second protection key based on the storage key corresponding to the data storage provider in response to the existence of data to be stored. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attribute of the data storage provider.

[0029] The generation module is further configured to generate an encrypted storage file based on the first protection key and the second protection key using a preset cryptographic algorithm.

[0030] Thirdly, embodiments of this application provide a data transmission and storage device for an ERP system, including: a memory and a processor;

[0031] The memory stores computer-executed instructions;

[0032] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0033] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0034] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0035] The data transmission and storage methods, apparatus, devices, media, and products for the ERP system provided in this application generate transmission keys based on the transmission keys corresponding to the direct superior role of the data sender and the role attributes of the data sender. This increases the complexity of the keys, making them more difficult to crack. The introduction of the direct superior role key links key generation to the hierarchical relationship in the organizational structure, further improving the security and orderliness of key management. Data senders with different roles have different permissions and responsibilities within the organization. By combining role attributes to generate transmission keys, it can be ensured that only roles with the corresponding permissions can generate the correct keys for data transmission, thereby better adapting to the organization's internal permission management requirements and preventing unauthorized access and transmission of data. By encrypting data using the transmission key, the original data is converted into ciphertext. Even if the data is intercepted during transmission, attackers cannot obtain the true content of the data because they do not have the correct decryption key, thus effectively protecting the confidentiality and integrity of the data. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attributes of the data storage provider, ensuring that the storage key of each data storage provider is unique and closely related to the organizational structure and role permissions. The first and second protection keys generated on this basis also inherit this uniqueness and security, providing multi-layered protection for data storage, further reducing the risk of key cracking, and greatly improving data storage security. By embedding access control policies into the keys themselves and the encrypted data format, a user's ability to decrypt data does not depend on real-time queries from external permission systems, but rather on whether their key matches the target set when encrypting the data. This achieves efficient, offline verifiable, fine-grained access control. Attached Figure Description

[0036] 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.

[0037] Figure 1 An application scenario diagram of a data transmission and storage method for an ERP system provided in this application;

[0038] Figure 2 A flowchart illustrating a data transmission and storage method for an ERP system provided in an embodiment of this application;

[0039] Figure 3 A flowchart illustrating a data transmission and storage method for an ERP system provided in another embodiment of this application;

[0040] Figure 4 A schematic diagram of the structure of a data transmission and storage device for an ERP system provided in an embodiment of this application;

[0041] Figure 5 This is a schematic diagram of the structure of the data transmission and storage device of an ERP system provided in an embodiment of this application.

[0042] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0044] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0045] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0046] In large group enterprises with cross-regional and cross-departmental layouts, the demand for collaborative office work among branches continues to grow. Due to differences in business scenarios and regional characteristics, branches in different regions and business lines often deploy independent ERP subsystems, requiring frequent data interaction and sharing. For example, subsidiaries report financial summary data to the group headquarters, and the headquarters distributes supplier resources to subordinate units to ensure the efficient implementation of business decisions. These enterprises have complex organizational structures and frequent dynamic adjustments such as personnel changes and role adjustments, which place extremely high demands on the data transmission and storage security and access control adaptability of ERP systems. Currently, there are corresponding solutions for secure data transmission in ERP systems. The core is to dynamically generate a unique key for each piece of data to be transmitted through an encryption center. The sender encrypts the data with this key before initiating transmission, and the receiver can complete decryption by obtaining the corresponding key from the key center. For data transmission between departments or subordinate units and headquarters, encryption is often achieved by pre-distributing shared keys combined with asymmetric encryption algorithms. Some solutions also rely on the collaboration between a unified gateway and an encryption center to standardize the key application and usage process. However, existing technologies still have significant shortcomings: on the one hand, they lack encryption protection for statically stored data, making it difficult to achieve full-lifecycle security coverage for data; on the other hand, the management processes such as key generation and distribution are not adapted to the dynamic changes in the enterprise's organizational structure, resulting in a disconnect between access control and actual business needs, and failing to meet the enterprise's refined security management requirements.

[0047] Therefore, when facing technical problems in existing technologies, to achieve data security throughout its entire lifecycle, a first protection key and a second protection key are derived from the data storage provider's exclusive storage key. These keys respectively ensure data confidentiality and integrity. An encrypted storage file is then generated using a preset cryptographic algorithm to fill the gaps in storage security. Addressing the disconnect between key management and organizational structure, key derivation rules are designed using the company's natural role hierarchy. Both transmission and storage keys are generated based on the corresponding keys of the direct superior role, combined with the user's own role attributes. This naturally binds key permissions to role hierarchy, enabling superiors to control subordinate keys and allowing permissions to automatically adapt as roles change. To further improve data transmission security and permission adaptation, data is directly encrypted using the data sender's transmission key. Because this transmission key originates from the superior's key and the user's own role attributes, the receiver's key shares the same origin and can be directly decrypted, ensuring both transmission security and conforming to the hierarchical permission relationships within departments.

[0048] Figure 1 This is an application scenario diagram illustrating the data transmission and storage method of the ERP system provided in this application, such as... Figure 1 As shown in the diagram, the scenario corresponding to the data transmission and storage method of the ERP system provided in this application includes: a terminal device 101 and a server 102. The data transmission and storage device of the ERP system can be integrated into the server 102.

[0049] Understandably, during ERP system initialization, a permanent root key K is generated. Based on the permanent root key, corresponding transmission and storage keys are generated for the highest-level managers of each department. The highest-level managers of each department then generate corresponding transmission and storage keys for their subordinate roles in turn, for subsequent data transmission and storage.

[0050] Specifically, when a user initiates a data transmission request or data storage request through terminal device 101, server 102, upon receiving the request, encrypts the data to be transmitted based on the transmission key corresponding to the data sender, if data transmission exists between departments, to generate an encrypted transmission file. If data storage is required, server 102 generates a first protection key and a second protection key based on the storage key corresponding to the data storage provider, and then uses a preset cryptographic algorithm to generate an encrypted storage file based on the first and second protection keys.

[0051] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0052] Figure 2 This is a flowchart illustrating a data transmission and storage method for an ERP system provided in an embodiment of this application, as shown below. Figure 2 As shown, the execution entity in this embodiment is the data transmission and storage device of the ERP system. This device can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc, or through a physical device integrating or installing the relevant computer program, such as a chip or a data transmission and storage device for the ERP system. The data transmission and storage device of the ERP system can be a server, a server cluster, etc. The data transmission and storage method of the ERP system provided in this embodiment includes the following steps:

[0053] S201. In response to data transmission between departments, the data to be transmitted is encrypted based on the transmission key corresponding to the data sender to generate an encrypted transmission file. The transmission key is generated based on the transmission key corresponding to the data sender's direct superior role and the role attribute of the data sender.

[0054] The transmission key is a security key used for encryption / decryption in the data transmission process. It is strongly bound to the user role and generated through a secure key derivation algorithm, such as HMAC-SHA256.

[0055] Among them, role attributes refer to the core information that distinguishes user identity and permissions, including but not limited to role name, such as purchasing manager, sales clerk; role code, department name / code, registration time, etc.

[0056] Among them, the direct superior role refers to the superior position to which the user directly belongs in the enterprise's organizational structure. For example, the direct superior of the purchasing clerk is the purchasing supervisor, and the direct superior of the purchasing supervisor is the purchasing director.

[0057] Specifically, when two roles within the same department need to exchange data, such as a purchasing clerk transmitting purchase orders to the purchasing manager or a sales manager reporting performance data to the sales director, after the data sender initiates a transmission request, the sender's identity is first verified, including account login status and role permission validity. If the verification is successful, the pre-assigned transmission key for that sender is retrieved. Using a preset symmetric encryption algorithm, such as AES-256, the obtained sender's transmission key is used to encrypt the plaintext data to be transmitted, converting readable plaintext into ciphertext that cannot be directly deciphered. After encryption, the ciphertext data is packaged to generate a standard-format encrypted transmission file, automatically appending the sender's role attribute identifiers, such as role code and department code, to facilitate subsequent decryption and verification by the receiver. Subsequently, the encrypted transmission file is sent to the receiver via a secure network channel, such as a TLS encrypted channel.

[0058] S202. In response to the existence of data to be stored, a first protection key and a second protection key are generated based on the storage key corresponding to the data storage provider. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attribute of the data storage provider.

[0059] Among them, the storage key refers to the core security key used in the data storage process. It is strongly bound to the user role and generated through a secure key derivation algorithm, such as HMAC-SM3.

[0060] The first protection key is a special key derived from the storage key, used to ensure the confidentiality of the stored data.

[0061] The second protection key is a special key derived from the storage key, used to ensure the integrity of the stored data.

[0062] Among them, the data storage party refers to the person who initiates the data storage operation, such as the purchasing clerk who enters purchase data or the financial specialist who summarizes financial data.

[0063] Specifically, when a data storage provider completes business data entry, such as purchase order information or sales statistics, and initiates a data storage request to store the data on a local server or in a cloud database, the provider's identity is first verified. This includes verifying account login status, role permission validity, and whether the storage operation is within the authorized scope. After successful verification, the provider's pre-assigned storage key is retrieved. Using a preset security algorithm and based on the provider's storage key, along with the provider's role attributes and data storage protection-specific identifier, a first protection key and a second protection key are derived.

[0064] S203. An encrypted storage file is generated using a preset cryptographic algorithm based on the first protection key and the second protection key.

[0065] Among them, the preset cryptographic algorithm refers to the pre-configured standardized security encryption algorithm that takes into account both data confidentiality and integrity protection, such as symmetric encryption algorithm and hash verification algorithm.

[0066] Optionally, first confirm the preset cryptographic algorithm that is compatible with the current storage scenario, such as AES-256 symmetric encryption algorithm for confidentiality protection and HMAC-SHA256 hash algorithm for integrity verification, and then retrieve the generated first protection key and second protection key to ensure that the key matches the algorithm type.

[0067] Specifically, the original business data is encrypted using a first protection key combined with a symmetric encryption algorithm. During encryption, readable plaintext data is converted into unordered ciphertext. Using a second protection key, a hash verification algorithm is applied to the original plaintext data to generate a unique integrity verification identifier, such as a fixed-length hash value. The encrypted ciphertext data, the integrity verification identifier, and key metadata, including the data storage provider's role code, department code, the preset cryptographic algorithm identifier, and the storage key identifier, are then packaged together to form a standardized encrypted storage file, which is ultimately stored at the target location.

[0068] The data transmission and storage method for the ERP system provided in this application generates transmission keys based on the transmission key corresponding to the direct superior role of the data sender and the role attributes of the data sender. This increases the complexity of the keys, making them more difficult to crack. The introduction of the direct superior role key links key generation to the hierarchical relationships within the organizational structure, further improving the security and orderliness of key management. Data senders with different roles have different permissions and responsibilities within the organization. By combining role attributes to generate transmission keys, it can be ensured that only roles with the corresponding permissions can generate the correct keys for data transmission, thus better adapting to the organization's internal permission management requirements and preventing unauthorized access and transmission of data. By encrypting data using the transmission key, the original data is converted into ciphertext. Even if the data is intercepted during transmission, attackers cannot obtain the true content of the data because they do not have the correct decryption key, effectively protecting the confidentiality and integrity of the data. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attributes of the data storage provider, ensuring that the storage key of each data storage provider is unique and closely related to the organizational structure and role permissions. The first and second protection keys generated on this basis also inherit this uniqueness and security, providing multi-layered protection for data storage, further reducing the risk of key cracking, and greatly improving data storage security. By embedding access control policies into the keys themselves and the encrypted data format, a user's ability to decrypt data does not depend on real-time queries from external permission systems, but rather on whether their key matches the target set when encrypting the data. This achieves efficient, offline verifiable, fine-grained access control.

[0069] As an optional implementation, based on the above embodiments, the data to be transmitted is encrypted using the transmission key corresponding to the data sender to generate an encrypted transmission file, including:

[0070] If the data sender is a superior role and the data receiver is a subordinate role, a shared transmission key is generated based on the transmission key corresponding to the data sender and the role attribute corresponding to the data receiver. The data to be transmitted is then encrypted using the shared transmission key so that it can be decrypted using the transmission key corresponding to the data receiver.

[0071] If the data sender is a subordinate role and the data receiver is a superior role, the data to be transmitted is encrypted using the transmission key corresponding to the data sender, so that it can be decrypted using the transmission key corresponding to the data receiver.

[0072] Among them, the shared transmission key refers to the temporary collaborative key generated for the transmission scenario from the upper level to the lower level. It is derived from the upper level transmission key and the lower level role attributes and is only suitable for this data interaction between the upper and lower levels.

[0073] Specifically, when a superior role, such as a purchasing manager, initiates a data transmission request to their direct subordinate, such as a purchasing clerk, the process first verifies the superior role's identity and the scope of their data transmission permissions, while simultaneously obtaining the complete role attributes of the receiving subordinate role. Then, a secure key derivation algorithm is invoked, using the superior role's own transmission key as a base and combining it with the receiving subordinate's role attributes to generate a unique shared transmission key. This key inherits the superior's key's permissions and is strongly bound to the subordinate role's attributes, making it suitable only for this specific superior-subordinate transmission scenario. Next, a preset symmetric encryption algorithm is invoked, using the generated shared transmission key to encrypt the plaintext data to be transmitted, converting readable data into ciphertext that cannot be directly deciphered. The encrypted ciphertext data, along with key metadata such as the algorithm identifier and the superior role's code, is packaged to generate an encrypted transmission file, which is then sent to the subordinate role via a TLS encrypted channel. Upon receiving the file, the subordinate role can directly decrypt it using their own transmission key. Because the subordinate's transmission key is derived from the superior's and shares the same origin as the shared transmission key, they have mutual decryption capabilities.

[0074] Furthermore, when a lower-level role, such as a purchasing clerk, initiates a data transmission request to its immediate superior, such as a purchasing manager, the system first verifies the lower-level role's login status and the authorized scope of the transmission operation. It then retrieves the pre-assigned transmission key and preset symmetric encryption algorithm for that lower-level role. Using the lower-level role's transmission key, it encrypts the reported plaintext data, converting it into ciphertext. The ciphertext data, along with metadata such as the lower-level role's code, department code, and algorithm identifier, is packaged into an encrypted transmission file and sent to the superior role via a secure channel. Upon receiving the file, the superior role can directly decrypt it using its own transmission key. Because the superior is the deriver of the lower-level key, its key has the authority to decrypt all encrypted data from its immediate subordinates, eliminating the need to generate a new key.

[0075] The data transmission and storage method for the ERP system provided in this application combines the uniqueness and specificity of the shared transmission key generated by the data sender's transmission key and the receiver's role attributes, reducing the risk of being cracked and ensuring data security. Generating different keys based on the subordinate's role attributes allows for fine-grained control over data access. Superiors can selectively encrypt transmissions based on subordinate permissions, ensuring that they only access authorized content. This approach aligns with organizational management models, allowing superiors to flexibly generate keys for secure data distribution and facilitating monitoring and management. When a subordinate transmits data to a superior, it directly encrypts it using its own transmission key. Superiors can easily decrypt data from different subordinates using their own keys. Centralized key management allows superiors to better control data transmission security.

[0076] As an optional implementation, based on the above embodiments, the encrypted storage file further includes an identity tag, which includes the data storage provider's role code, department code, and preset cryptographic algorithm identifier. After generating the encrypted storage file using the preset cryptographic algorithm based on the first protection key and the second protection key, it further includes:

[0077] If the data acquisition party is at the same level as the data storage party, a first protection key and a second protection key are generated based on the identity tag and the storage key corresponding to the data acquisition party, and the encrypted storage file is decrypted using the first protection key and the second protection key;

[0078] If the data acquisition party is the superior role of the data storage party, then the storage key corresponding to the data storage party is generated in reverse based on the identity tag, and a first protection key and a second protection key are generated based on the storage key corresponding to the data storage party, so as to decrypt the encrypted storage file using the first protection key and the second protection key.

[0079] Among them, the identity tag refers to the set of plaintext metadata embedded in the encrypted storage file, including the role code of the data storage party, such as purchasing clerk-001, department code, such as purchasing department-01, and preset password algorithm identifier.

[0080] The data acquisition party refers to the role that initiates the request to read the encrypted storage file, such as other procurement clerks or procurement managers who need to access procurement data.

[0081] Among them, the same level role refers to the role that is at the same level as the data storage provider in the enterprise's organizational structure, such as purchasing clerk A and purchasing clerk B in the same department, whose storage keys are derived from the same superior.

[0082] Specifically, the data acquirer is a party with the same role level as the storage party. First, the acquirer's identity is verified, and an identity tag is extracted from the encrypted storage file to confirm that the acquirer and storage party are of the same role level. Then, the data acquirer's own storage key is retrieved and, combined with the role code, department code, and preset cryptographic algorithm identifier from the identity tag, a first protection key and a second protection key are generated according to the same key derivation rules as the storage party. Because storage keys for the same role level share the same origin and role attributes, the two generated protection keys perfectly match the key used by the storage party during encryption. The first protection key is used, combined with the preset encryption algorithm indicated in the identity tag, to decrypt the ciphertext data in the encrypted storage file, restoring the plaintext data. Then, the second protection key is used, combined with a preset hash verification algorithm, to perform an integrity check on the decrypted plaintext data. After confirming that the data has not been tampered with, the plaintext data is returned to the data acquirer.

[0083] Furthermore, when the data acquirer is a superior, their identity is verified, and the identity tag in the encrypted storage file is extracted to confirm that the acquirer is the direct superior of the storage provider. The superior's storage key is then retrieved, combined with the storage provider's role code and department code from the identity tag, and the superior key is inverted and the subordinate role attribute is added to generate a storage key completely identical to the data storage provider's. Based on the inverted storage key, and combined with the preset cryptographic algorithm identifier in the identity tag, the corresponding first and second protection keys are generated according to the derivation rules used by the storage provider during encryption.

[0084] The data transmission and storage method for the ERP system provided in this application embodiment accurately identifies the identity information of the data storage provider through the role and department codes in the identity tag. During decryption, only the data acquisition party matching the storage provider's role and department can correctly generate a protection key based on this information, effectively preventing unauthorized users from obtaining data and significantly raising the security threshold for data access. When peer roles acquire data, a protection key is generated based on the identity tag and the data acquisition party's storage key for decryption. This facilitates peer access to data within their authorized limits while ensuring legitimacy through key verification, achieving flexible and secure sharing. Data acquisition by higher-level roles is handled specially: a storage party key is generated in reverse from the identity tag, and then a protection key is generated for decryption. This conforms to hierarchical management logic, meets the higher-level permission requirements, and ensures compliant and secure access.

[0085] As an optional implementation, based on the above embodiments, it further includes:

[0086] In response to data sharing across departments, a temporary data sharing key is generated based on the data collaboration key and the role information to be shared. The data collaboration key is generated based on the root key using a preset key derivation function and is only possessed by the highest-level manager of each department.

[0087] The data to be shared is encrypted using a temporary data sharing key, and then decrypted based on the temporary data sharing key and the role attributes of the data recipient. The role attributes include department code, role code, and registration time.

[0088] Among them, the Data Collaboration Key (DCK) is the basic key for cross-departmental data sharing. It is generated by the group's super administrator based on the permanent root key through a preset key derivation function and is only open to the highest-level managers of each department.

[0089] Among them, the role information to be shared refers to the core identity information of all roles participating in cross-departmental data sharing, including the department code, role code, and registration time of the data provider / receiver.

[0090] Among them, the temporary data sharing key (DSK) is a one-time key generated for a single cross-departmental data sharing. It is derived from the data collaboration key and the role information to be shared, and is only applicable to this sharing scenario. Its validity period is bound to the sharing task and expires after use.

[0091] The root key (K) is the permanent core key held by the super administrator during the system initialization phase, and it is the ultimate source of all levels of keys.

[0092] Among them, the Preset Key Derivation Function (KDF) refers to a pre-configured security algorithm, such as HMAC-SHA256 or HMAC-SM3, used to derive a data collaboration key from the root key or a temporary data sharing key from the data collaboration key.

[0093] Specifically, when data sharing needs arise between different departments, such as the sales department needing to access inventory data from the inventory department, the data requester, such as the sales manager, submits a sharing application to their department's highest-level manager, such as the sales director, specifying the data type to be shared, the recipient / provider role information, and the sharing validity period. After the requester's department's highest-level manager approves the application, it is synchronized to the data provider's department's highest-level manager, such as the inventory director. Once both parties confirm the sharing request is compliant, the cross-departmental key generation process is triggered. The Data Collaboration Key (DCK) and a preset key derivation function are retrieved. Based on the DCK, complete information about the roles to be shared is input to generate a temporary data sharing key (DSK) specifically adapted to this cross-departmental sharing. This key is strongly bound to the department, role, and time of this sharing, ensuring that it can only be used by the designated role and cannot be reused in other cross-departmental scenarios. The department's highest-level manager distributes the generated temporary data sharing key to all participating roles in this sharing through an encrypted channel, attaching metadata such as the key's validity period and corresponding data type during the distribution process.

[0094] Furthermore, the data provider, such as the inventory manager, retrieves a temporary data sharing key and uses a preset symmetric encryption algorithm to encrypt the plaintext data to be shared, converting the readable data into ciphertext. The encrypted ciphertext data is then transmitted to the data receiver via a secure channel. After obtaining the ciphertext, the receiver retrieves the locally stored temporary data sharing key, performs key matching and verification based on its own role attributes, and uses this key to decrypt the ciphertext data, restoring it to readable plaintext data.

[0095] Optionally, after decryption is completed, the system will automatically trigger a key validity period verification. If the sharing task is completed or the validity period expires, the temporary data sharing keys of all participating roles will be immediately cancelled to prevent key abuse.

[0096] Optionally, if the key is leaked or lost during its validity period, the old key should be cancelled in a timely manner and a new key should be generated.

[0097] Optionally, blockchain smart contracts can be introduced to automate the distribution process of shared keys (DSKs). For example, when the sales department requests inventory data, the smart contract verifies its authorization conditions, such as department code and role level, automatically derives the DSK, and securely transmits it to the target department without manual intervention. Cross-departmental sharing rules, such as authorization conditions and key derivation parameters, are encoded into the blockchain contract. The DSK is distributed to the target department via an encrypted channel, and the transmission log is recorded on the blockchain to ensure traceability. When sharing permissions change, the smart contract automatically updates the DSK derivation rules to ensure the shared key is consistent with the latest authorization status. This improves the automation and security of cross-departmental data sharing, reducing errors and delays caused by manual operations.

[0098] The data transmission and storage method for the ERP system provided in this application embodiment uses a data collaboration key derived from the root key, which is possessed only by the highest-level manager of each department. This controls the scope of key propagation from the source and reduces the risk of key leakage. Decryption requires combining the temporary data sharing key and the data recipient's role attributes; this multi-factor verification increases the difficulty of cracking. Only personnel with specific role attributes can decrypt the data, preventing unauthorized access and misuse. Temporary data sharing keys are generated for cross-departmental data sharing scenarios, allowing for flexible creation and use based on the sharing needs of different departments. When different departments share data at different times and in different business scenarios, suitable temporary keys can be quickly generated to meet diverse business needs.

[0099] As an optional implementation, based on the above embodiments, it further includes:

[0100] In response to the expiration of the target role's transmission key and storage key, update the target role's transmission key and storage key based on the target role's direct superior role and the target role's role attributes.

[0101] If the target role has a corresponding subordinate role, then the transmission key and storage key of each subordinate role will be updated synchronously.

[0102] The target role's historical encrypted storage files are re-encrypted based on the updated storage key.

[0103] The target role refers to a specific role whose transmission / storage key has expired or whose key needs to be updated due to role adjustment, key leakage, or other reasons.

[0104] The key validity period refers to the period during which the key is used, set by the system administrator / direct supervisor during the role registration phase. The key will automatically expire after this period.

[0105] Among them, historical encrypted storage files refer to all business data files that the target role encrypted and stored using a protection key derived from the old storage key before the key was updated.

[0106] Specifically, the system monitors the validity periods of all roles' transmission and storage keys in real time. When it detects that a target role's key is about to expire or has already expired, it automatically triggers a key update process. Simultaneously, it sends a key update reminder to the target role's immediate superior role. Upon receiving the update trigger instruction, the target role's immediate superior role uses its own currently valid transmission and storage keys, combined with the target role's complete role attributes, to generate new transmission and storage keys for the target role using a preset key derivation algorithm. The new keys are then distributed to the target role's key management module, completing the switch between old and new keys, and the new keys take effect immediately. Simultaneously, the old keys are securely archived and marked as invalid, prohibiting their use for new data transmission and storage operations.

[0107] Furthermore, the organizational structure information is retrieved to identify all direct subordinate roles of the target role. For example, if the target role is the purchasing manager, its subordinate is the purchasing clerk. The newly generated transmission / storage key is used, combined with the role attributes of each subordinate role, and according to the rule of deriving subordinate keys from superior keys, new transmission and storage keys are generated in batches for each subordinate role. The generated new keys are then distributed to each subordinate role through an encrypted channel to complete the key switch, while the old keys of each subordinate role are archived.

[0108] Furthermore, based on the target role's identity identifier, all historical encrypted storage files encrypted with the old storage key for that role are retrieved, forming a list of files to be processed. The archived old storage key is used to derive the corresponding old first protection key and old second protection key, which are then used to decrypt the historical encrypted storage files, restoring them to plaintext data. Using the target role's new storage key, new first and second protection keys are derived, and the decrypted plaintext data is re-encrypted using a preset cryptographic algorithm, generating a new encrypted storage file; simultaneously, the identity tag in the file is updated, replacing the original historical file to complete the storage process.

[0109] The data transmission and storage method for the ERP system provided in this application effectively limits the usage time of keys by periodically updating them, greatly reducing the risk of long-term data theft or tampering. Simultaneously, generating new keys based on the direct superior key and the target role attributes increases the complexity and randomness of key generation, further enhancing key security. Re-encrypting the target role's historical encrypted storage files ensures that historical data remains secure even after the old key expires. If the target role has subordinate roles, the keys of each subordinate role are updated synchronously, ensuring the continuity and consistency of the key system throughout the organization. This avoids security vulnerabilities caused by outdated keys in some roles, ensuring the security of data transmission and storage between different roles.

[0110] As an optional implementation, based on the above embodiments, the data to be stored is dynamically updated data, and the method further includes:

[0111] In response to an update event of the data to be stored, the first protection key and the second protection key are regenerated based on the storage key and role attributes of the data storage provider and the update identifier;

[0112] The first protection key, the second protection key, and the update identifier before and after the update are associated and stored as a historical key, so that the data update trajectory can be viewed based on the historical key.

[0113] Dynamically updated data refers to business data that is not stored once and then remains unchanged, but is continuously modified and supplemented as business processes progress, such as real-time inventory data, incomplete purchase orders, and dynamically updated sales performance reports.

[0114] Update events refer to operations that trigger data updates, including data content modification and data supplementation.

[0115] The update identifier refers to the characteristic information used to uniquely mark a single data update, including the update timestamp, the update operator's role code, and a summary of the update content.

[0116] Among them, the historical key refers to the key set formed by associating and storing the first / second protection key before and after each data update with the corresponding update identifier.

[0117] Specifically, when a data storage provider, such as an inventory administrator, performs update operations such as modifying or supplementing dynamically updated data, such as real-time inventory quantities, an update event is confirmed. The provider retrieves its currently valid storage key and complete role attributes, and generates a unique update identifier for this update. Then, using the same security algorithm as the initial key generation, and based on the storage provider's storage key, combined with role attributes and the update identifier, new first and second protection keys are generated. The newly generated first protection key is used to encrypt the updated plaintext data, generating ciphertext; simultaneously, the new second protection key is used to generate a data integrity verification identifier. The ciphertext, verification identifier, and an identity tag containing the update identifier are packaged together to form a new version of the encrypted storage file, which is then overwritten or appended to the original data location.

[0118] Furthermore, the old first / second protection keys used before this update, the newly generated first / second protection keys after the update, and the unique update identifier for this update are extracted to form a complete set of associated data. This associated data is stored in a dedicated historical key repository. Access to the historical key repository is only granted to the direct superior or auditing roles of the data storage provider. During storage, the repository's role code and data identifier are appended to ensure accurate location of all updated version keys for a specific piece of data.

[0119] Optionally, when it is necessary to view the data update trajectory, all related records of the target data can be retrieved based on the target data's identifier, such as inventory code or storage party role code. The data update sequence can be traced chronologically using the timestamp, operator, and update content summary in the update identifier. To view the specific data content of a particular version, the first / second protection key corresponding to that version can be used to decrypt the encrypted storage file of that version, fully restoring the data state after the update and achieving end-to-end traceability from key to data version.

[0120] The data transmission and storage method for the ERP system provided in this application embodiment involves dynamically updating the data to be stored. Each update regenerates a first protection key and a second protection key based on the data storage provider's storage key, role attributes, and update identifier. This ensures that the keys are closely linked to the data's update status, guaranteeing that each updated data receives new, adapted key protection and effectively preventing security risks caused by unchanging keys over long periods. The first and second protection keys, along with the update identifier before and after the update, are stored as a historical key, providing a detailed record of each data update. By viewing the historical key, it is possible to clearly understand when, by which role, and what type of update operation was performed, achieving complete tracking of the data update trajectory.

[0121] Figure 3A flowchart illustrating a data transmission and storage method for an ERP system according to another embodiment of this application is shown below. Figure 3 As shown, the data transmission and storage method of the ERP system provided in this embodiment includes the following steps:

[0122] S301. In response to the existence of data to be stored, a first protection key and a second protection key are generated based on the storage key corresponding to the data storage provider. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attribute of the data storage provider.

[0123] S302. An encrypted storage file is generated based on the first protection key and the second protection key using a preset cryptographic algorithm. The encrypted storage file includes an identity tag, which includes the role code, department code, and preset cryptographic algorithm identifier of the data storage party.

[0124] S303. If the data acquisition party is of the same level as the data storage party, a first protection key and a second protection key are generated based on the identity tag and the storage key corresponding to the data acquisition party, so as to decrypt the encrypted storage file using the first protection key and the second protection key.

[0125] S304. If the data acquisition party is the superior role of the data storage party, then the storage key corresponding to the data storage party is generated in reverse based on the identity tag.

[0126] S305. Generate a first protection key and a second protection key based on the storage key corresponding to the data storage provider, and use the first protection key and the second protection key to decrypt the encrypted storage file.

[0127] It should be noted that the execution order of S303 and S304-S305 is not important.

[0128] In this embodiment, the implementation method and technical effect of S301-S305 are similar to the implementation method of the corresponding solution in the above embodiments, and will not be repeated here.

[0129] Figure 4 This is a schematic diagram of the data transmission and storage device of the ERP system provided in this application, as shown below. Figure 4 As shown, the data transmission and storage device 40 of the ERP system provided in this embodiment includes an encryption module 41 and a generation module 42.

[0130] The encryption module 41 is used to encrypt the data to be transmitted based on the transmission key corresponding to the data sender in response to data transmission between the same departments, so as to generate an encrypted transmission file. The transmission key is generated based on the transmission key corresponding to the direct superior role of the data sender and the role attribute of the data sender. The generation module 42 is used to generate a first protection key and a second protection key based on the storage key corresponding to the data storage party in response to the existence of data to be stored. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage party and the role attribute of the data storage party. The generation module 42 is also used to generate an encrypted storage file based on the first protection key and the second protection key using a preset cryptographic algorithm.

[0131] The data transmission and storage device of the ERP system provided in this embodiment can execute... Figure 2 The implementation principles and technical effects of the methods shown are similar, and will not be repeated here.

[0132] Optionally, when the encryption module 41 encrypts the data to be transmitted based on the transmission key corresponding to the data sender to generate an encrypted transmission file, it is specifically used as follows: if the data sender is a superior role and the data receiver is a subordinate role, a shared transmission key is generated based on the transmission key corresponding to the data sender and the role attribute corresponding to the data receiver, and the shared transmission key is used to encrypt the data to be transmitted so that it can be decrypted based on the transmission key corresponding to the data receiver; if the data sender is a subordinate role and the data receiver is a superior role, the transmission key corresponding to the data sender is used to encrypt the data to be transmitted so that it can be decrypted based on the transmission key corresponding to the data receiver.

[0133] Optionally, the generation module 42 is further configured to, if the data acquisition party is at the same level as the data storage party, generate a first protection key and a second protection key based on the identity tag and the storage key corresponding to the data acquisition party, so as to decrypt the encrypted storage file using the first protection key and the second protection key; if the data acquisition party is the superior party of the data storage party, generate the storage key corresponding to the data storage party based on the identity tag, and generate a first protection key and a second protection key based on the storage key corresponding to the data storage party, so as to decrypt the encrypted storage file using the first protection key and the second protection key.

[0134] Optionally, the generation module 42 is also used to generate a temporary data sharing key based on the data collaboration key and the role information to be shared in response to data sharing between departments. The data collaboration key is generated based on the root key using a preset key derivation function and is only possessed by the highest-level manager of each department. The encryption module 41 is also used to encrypt the data to be shared according to the temporary data sharing key so that it can be decrypted based on the temporary data sharing key and the role attributes of the data recipient. The role attributes include department code, role code, and registration time.

[0135] Optionally, the data transmission and storage device of the ERP system provided in this embodiment further includes an update module.

[0136] Correspondingly, the update module is used to update the transmission key and storage key of the target role based on the transmission key and storage key of the target role's direct superior role and the role attribute of the target role when the validity period of the target role's transmission key and storage key expires; if the target role has corresponding subordinate roles, the transmission key and storage key of each subordinate role are updated synchronously; the encryption module 41 is also used to re-encrypt the target role's historical encrypted storage files based on the updated storage key.

[0137] Optionally, the data transmission and storage device of the ERP system provided in this embodiment further includes a storage module.

[0138] Correspondingly, the data to be stored is dynamically updated data. The generation module 42 is also used to regenerate the first protection key and the second protection key based on the storage key and role attributes of the data storage party and the update identifier in response to the update event of the data to be stored. The storage module is used to associate and store the first protection key, the second protection key and the update identifier before and after the update as a historical key, so that the data update trajectory can be viewed according to the historical key.

[0139] Figure 5 This is a schematic diagram of the data transmission and storage devices for the ERP system provided in this application. Figure 5 As shown, the data transmission and storage device 50 of the ERP system provided in this embodiment includes a processor 51 and a memory 52. ​​The processor 51 and the memory 52 are connected via a bus and communicate with each other.

[0140] In the specific implementation process, the processor 51 executes the computer execution instructions stored in the memory 52, causing the processor 51 to perform the above-described method.

[0141] The specific implementation process of processor 51 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0142] In the above embodiments, it should be understood that the processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0143] The memory 52 may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0144] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0145] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0146] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0147] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0148] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0149] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0150] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0151] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0152] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0153] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0154] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A data transmission and storage method for an ERP system, characterized in that, The method includes: In response to data transmission between departments, the data to be transmitted is encrypted based on the transmission key corresponding to the data sender to generate an encrypted transmission file. The transmission key is generated based on the transmission key corresponding to the direct superior role of the data sender and the role attribute of the data sender. In response to the existence of data to be stored, a first protection key and a second protection key are generated based on the storage key corresponding to the data storage provider. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attribute of the data storage provider. An encrypted storage file is generated using a preset cryptographic algorithm based on the first protection key and the second protection key.

2. The method according to claim 1, characterized in that, The step of encrypting the data to be transmitted based on the transmission key corresponding to the data sender to generate an encrypted transmission file includes: If the data sender is a superior role and the data receiver is a subordinate role, a shared transmission key is generated based on the transmission key corresponding to the data sender and the role attribute corresponding to the data receiver. The data to be transmitted is then encrypted using the shared transmission key so that it can be decrypted based on the transmission key corresponding to the data receiver. If the data sender is a subordinate role and the data receiver is a superior role, the data to be transmitted is encrypted using the transmission key corresponding to the data sender, so that it can be decrypted using the transmission key corresponding to the data receiver.

3. The method according to claim 1, characterized in that, The encrypted storage file also includes an identity tag, which includes the data storage provider's role code, department code, and a preset cryptographic algorithm identifier. After generating the encrypted storage file using the preset cryptographic algorithm based on the first protection key and the second protection key, the process further includes: If the data acquisition party is of the same level as the data storage party, then a first protection key and a second protection key are generated based on the identity tag and the storage key corresponding to the data acquisition party, so as to decrypt the encrypted storage file using the first protection key and the second protection key; If the data acquisition party is the superior role of the data storage party, then the storage key corresponding to the data storage party is generated in reverse based on the identity tag, and a first protection key and a second protection key are generated based on the storage key corresponding to the data storage party, so as to decrypt the encrypted storage file using the first protection key and the second protection key.

4. The method according to claim 1, characterized in that, Also includes: In response to data sharing across departments, a temporary data sharing key is generated based on the data collaboration key and the role information to be shared. The data collaboration key is generated based on the root key using a preset key derivation function and is only owned by the highest-level manager of each department. The data to be shared is encrypted using the temporary data sharing key, and then decrypted based on the temporary data sharing key and the role attributes of the data recipient, including department code, role code, and registration time.

5. The method according to claim 1, characterized in that, Also includes: In response to the expiration of the validity period of the target role's transmission key and storage key, the transmission key and storage key are updated based on the transmission key and storage key corresponding to the target role's direct superior role and the target role's role attributes. If the target role has a corresponding subordinate role, then the transmission key and storage key of each subordinate role are updated synchronously. The target role's historical encrypted storage files are re-encrypted based on the updated storage key.

6. The method according to claim 1, characterized in that, The data to be stored is dynamically updated data, and the method further includes: In response to an update event of the data to be stored, the first protection key and the second protection key are regenerated based on the storage key and role attributes of the data storage provider and the update identifier; The first protection key, the second protection key, and the update identifier before and after the update are associated and stored as a historical key, so that the data update trajectory can be viewed based on the historical key.

7. A data transmission and storage device for an ERP system, characterized in that, include: The encryption module is used to encrypt the data to be transmitted based on the transmission key corresponding to the data sender in response to data transmission between the same departments, so as to generate an encrypted transmission file. The transmission key is generated based on the transmission key corresponding to the direct superior role of the data sender and the role attribute of the data sender. The generation module is used to generate a first protection key and a second protection key based on the storage key corresponding to the data storage provider in response to the existence of data to be stored. The storage key is generated based on the storage key corresponding to the direct superior role of the data storage provider and the role attribute of the data storage provider. The generation module is further configured to generate an encrypted storage file based on the first protection key and the second protection key using a preset cryptographic algorithm.

8. A data transmission and storage device for an ERP system, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images