Database field-level transparent encryption method, device, equipment, storage medium and product

Abstract

The application discloses a database field-level transparent encryption method and device, equipment, storage medium and product, and relates to the technical field of information security. The method comprises the following steps: a key acquisition request is sent to a remote key server by an application client to acquire a field encryption key; when the field encryption key is not successfully acquired by a remote key loader, a local emergency key is acquired by calling a local key loader through a composite key loader; the local emergency key acquired by the composite key loader is determined as a current effective key; when a write operation is performed on a database field, a corresponding field processing component is called according to pre-configured encryption configuration information, and the data to be written into the database field is encrypted by the field processing component by using the current effective key. The application realizes database field-level transparent encryption and key centralized management, guarantees business continuity through remote priority and local degradation, improves data and key security, and reduces business access transformation cost.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a database field-level transparent encryption method, apparatus, device, storage medium, and product. Background Technology

[0002] In recent years, with the advancement of science and technology and the continuous development of computer technology, information security has received increasing attention. Databases typically store sensitive data such as identity information, account information, and contact information. Once a database is subjected to unauthorized access, sensitive data stored in plaintext can be easily obtained directly. Therefore, encrypting sensitive fields before writing data to the database and decrypting the corresponding fields after reading the data has become an important technical means of protecting database security.

[0003] Existing database encryption technologies mainly include application-layer encryption, database-layer encryption, middleware encryption, and persistence-layer framework encryption. These technologies primarily rely on hard-coded keys or decentralized key management methods, which cannot meet the stringent requirements of the financial industry for centralized key control, compliance with national cryptographic algorithms, and high availability assurance.

[0004] In existing solutions for field encryption based on persistence layer frameworks such as MyBatis, encryption keys are typically configured in application code or application configuration files and are stored and used separately by different applications. As the number of applications and encrypted fields increases, keys are easily scattered, making unified key updates, state management, and rotation difficult to implement.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a database field-level transparent encryption method, apparatus, device, storage medium, and product, which aims to solve the problem of decentralized key management.

[0007] To achieve the above objectives, this application proposes a database field-level transparent encryption method, the method comprising: When loading the key used for database field encryption, the composite key loader calls the remote key loader to send a key retrieval request to the remote key server to obtain the field encryption key; When the remote key loader fails to obtain the field encryption key, the local key loader is invoked by the composite key loader to obtain the local emergency key. The local emergency key obtained by the composite key loader is determined as the currently valid key; When performing a write operation on the database field, the corresponding field processing component is invoked according to the pre-configured encryption configuration information. The field processing component then uses the currently valid key to encrypt the data to be written to the database field.

[0008] In one embodiment, the step of loading the key for database field encryption by calling the remote key loader through the composite key loader to send a key acquisition request to the remote key server to obtain the field encryption key includes the following steps: When loading the key used for encrypting database fields, a key retrieval request carrying application identity information and request signature is generated; The remote key loader sends a key acquisition request to the remote key server, and the remote key server verifies the application identity information, the request signature, access permissions, and anti-replay attack measures. The encrypted field encryption key is received by the remote key server after successful verification.

[0009] In one embodiment, the remote key server includes an authentication and authorization center, a key management engine, and a key store: the step of sending a key acquisition request to the remote key server through the remote key loader, and having the remote key server verify the application identity information, the request signature, access permissions, and replay attack prevention includes: The remote key loader sends a key acquisition request to the remote key server, which then verifies the application identity information, the request signature, the access permissions, and replay attack prevention through the authentication and authorization center. The remote key server determines the initial field encryption key corresponding to the application client based on the key acquisition request through the key management engine, obtains the key ciphertext corresponding to the initial field encryption key from the key library, decrypts the key ciphertext to obtain the decrypted initial field encryption key, and encrypts the decrypted initial field encryption key using the SM2 public key corresponding to the application client to obtain the encrypted field encryption key.

[0010] In one embodiment, after the step of obtaining the field encryption key from the remote key server by calling the remote key loader through the composite key loader when loading the key for database field encryption, the method further includes: When the remote key loader successfully obtains the field encryption key, it decrypts the received encrypted field encryption key using the SM2 private key corresponding to the SM2 public key of the application client to obtain the decrypted field encryption key.

[0011] In one embodiment, the step of obtaining the local emergency key by calling the local key loader through the composite key loader includes: The local key loader is invoked to read the local emergency key pre-configured in the local configuration file of the application client, and the read local emergency key is returned to the composite key loader.

[0012] In one embodiment, after the step of determining the local emergency key obtained by the composite key loader as the currently valid key, the method further includes: The currently valid key is memory obfuscated, and the memory obfuscated currently valid key is stored in the local memory of the application client.

[0013] In one embodiment, before the step of performing a write operation or a read operation on the database field, the method further includes: The encryption configuration information is pre-configured to establish the association between the database fields to be encrypted and the corresponding field processing components.

[0014] In one embodiment, the step of performing a write operation on the database field includes: When performing a write operation on the database field, the field processing component corresponding to the database field is invoked according to the association relationship; The field processing component uses the currently valid key to perform encryption processing on the data to be written into the database field, thereby obtaining ciphertext data. The encrypted data is used as the write data for the database field, and a database write operation is performed.

[0015] In one embodiment, the step of performing a read operation on the database field includes: Execute a database query to obtain query results containing data from the database fields; When mapping the query results, the field processing component corresponding to the database field is called according to the association relationship; The field processing component uses the currently valid key to decrypt the data read from the database field and sets the decrypted plaintext data into the corresponding attribute of the business object.

[0016] In one embodiment, the step of performing a read operation on the database field further includes performing compatibility processing on the data of the database field, specifically including: When decryption of data read from the database field fails by calling the field processing component, the data read from the database field is set into the corresponding attribute of the business object to ensure compatibility with unencrypted historical plaintext data in the database.

[0017] In one embodiment, the step of sending a key acquisition request to the remote key server by invoking the remote key loader through the composite key loader further includes a key rotation operation, specifically including: Receive key update notification sent by the remote key server; In response to the key update notification, the rotated field encryption key is obtained through the remote key loader, and the rotated field encryption key is determined as the new currently valid key.

[0018] In one embodiment, the method is applied to a remote key server, and the method includes: Receive key retrieval requests sent by the application client through the composite key loader to the remote key loader when loading the key used for database field encryption; According to the key acquisition request, a field encryption key is sent to the application client. If the application client fails to acquire the field encryption key from the remote key loader, it uses the composite key loader to call the local key loader to obtain a local emergency key. The local emergency key obtained by the composite key loader is determined as the current valid key. When performing a write operation on the database field, the corresponding field processing component is called according to the pre-configured encryption configuration information. The field processing component uses the current valid key to encrypt the data to be written to the database field.

[0019] In one embodiment, the remote key server includes an authentication and authorization center, a key management engine, and a key store; the step of sending a field encryption key to the application client according to the key acquisition request includes: The authentication and authorization center performs anti-replay verification on the application identity information carried in the key acquisition request, the request signature, the access permissions, and the key acquisition request itself. After successful verification, the key management engine determines the initial field encryption key corresponding to the application client based on the key acquisition request, obtains the key ciphertext corresponding to the initial field encryption key from the key library, decrypts the key ciphertext to obtain the decrypted initial field encryption key, and encrypts the decrypted initial field encryption key using the SM2 public key corresponding to the application client to obtain the encrypted field encryption key. Send the encrypted field encryption key to the application client.

[0020] In one embodiment, before the step of receiving the key acquisition request sent by the application client through the composite key loader to the remote key loader when loading the key for database field encryption, the method further includes: Maintain the status information of the encryption key for the field; When the field encryption key is rotated, the remote key server generates or enables the rotated field encryption key and updates the key status information corresponding to the field encryption key; Send a key update notification to the application client so that the application client responds to the key update notification by sending a key acquisition request; The system receives a key acquisition request from the application client in response to the key update notification, and determines the rotated field encryption key as the target field encryption key that is currently in a valid state based on the updated key status information.

[0021] In one embodiment, the step of sending the field encryption key to the application client according to the key acquisition request further includes: The ciphertext of the key formed by the encryption key of the target field encrypted using the SM4 algorithm is stored in the key store.

[0022] Furthermore, to achieve the above objectives, this application also proposes a database field-level transparent encryption device, which is installed on the application client and includes: The request sending module is used to send a key retrieval request to the remote key server through the composite key loader when loading the key used for database field encryption, so as to obtain the field encryption key; The key loading module is used to obtain a local emergency key by calling the local key loader through the composite key loader when the remote key loader fails to obtain the field encryption key. The valid key determination module is used to determine the key obtained by the composite key loader as the current valid key; The transparent encryption module is used to call the corresponding field processing component according to the pre-configured encryption configuration information when performing a write operation on the database field. The field processing component uses the currently valid key to encrypt the data to be written to the database field.

[0023] Furthermore, to achieve the above objectives, this application also proposes a database field-level transparent encryption device, wherein the device is located on a remote server, and the device includes: The request receiving module is used to receive key retrieval requests sent by the application client through the composite key loader calling the remote key loader when loading the key used for database field encryption; The key distribution module is used to send a field encryption key to the application client according to the key acquisition request. When the application client fails to acquire the field encryption key from the remote key loader, it uses the composite key loader to call a local key loader to obtain a local emergency key. The local emergency key obtained by the composite key loader is then determined as the currently valid key. When performing a write operation on the database field, the module calls the corresponding field processing component according to pre-configured encryption configuration information, and the field processing component uses the currently valid key to encrypt the data to be written to the database field.

[0024] Furthermore, to achieve the above objectives, this application also proposes a database field-level transparent encryption device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the database field-level transparent encryption method described above.

[0025] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the database field-level transparent encryption method described above.

[0026] 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 a database field-level transparent encryption method as described above.

[0027] One or more technical solutions proposed in this application have at least the following technical effects: when loading a key for encrypting a database field, a composite key loader calls a remote key loader to send a key acquisition request to a remote key server to obtain the field encryption key; when the remote key loader fails to obtain the field encryption key, the composite key loader calls a local key loader to obtain a local emergency key; the local emergency key obtained by the composite key loader is determined as the currently valid key; when performing a write operation on the database field, the corresponding field processing component is called according to the pre-configured encryption configuration information, and the field processing component uses the currently valid key to encrypt the data to be written to the database field.

[0028] Compared to existing technologies that require direct invocation of encryption algorithms within business code, this application's technical solution obtains the key for database field encryption through a composite key loader. When the remote key loader fails to obtain the field encryption key, a local key loader is invoked to obtain a local emergency key. This ensures that the key for database field encryption can still be obtained even when remote key retrieval fails, thereby reducing the impact of remote key server anomalies on database field encryption processing and improving the availability and continuity of encryption processing. Furthermore, the key obtained by the composite key loader is designated as the currently valid key, enabling subsequent field encryption processing to be performed based on a unified currently valid key. This masks the differences in the acquisition sources of the remote key and the local emergency key, avoiding the need to set separate encryption processing logic for different key sources and improving the consistency of field encryption processing before and after key switching. Simultaneously, when performing write or read operations on database fields, the corresponding field processing component is invoked based on pre-configured encryption configuration information. The field processing component then automatically performs field encryption or decryption using the currently valid key, separating field encryption processing from business processing logic and reducing code intrusion and processing differences caused by repeatedly setting encryption logic in business code. Therefore, this application forms a continuous processing mechanism of "abnormal key retrieval switching - unified use of the current valid key - automatic field-level encryption", which maintains the encryption processing of database fields in the event of abnormal remote key retrieval, while improving the consistency of encryption processing under different key acquisition states and the convenience of business systems to access encryption functions. Attached Figure Description

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

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

[0031] Figure 1 This is a flowchart illustrating the first embodiment of the database field-level transparent encryption method in this application. Figure 2 This is a diagram illustrating the overall architecture of the database field-level transparent encryption system in this application. Figure 3 This is a sequence diagram for obtaining the remote field encryption key in this application; Figure 4 Flowchart for writing encryption and reading decryption of database fields in this application; Figure 5 This is a flowchart of the key rotation process according to the second embodiment of this application; Figure 6 This is a flowchart illustrating the historical plaintext compatibility processing of the third embodiment of this application; Figure 7 This is a flowchart illustrating Embodiment 4 of the database field-level transparent encryption method in this application. Figure 8 This is a structural diagram of the database field-level transparent encryption device applied to the application client in this application; Figure 9 This is a structural diagram of the database field-level transparent encryption device applied to a remote server in this application; Figure 10 This is a diagram of the database field-level transparent encrypted storage medium structure for this application.

[0032] 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

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

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

[0035] The main solution of this application embodiment is as follows: When loading a key for database field encryption, a composite key loader calls a remote key loader to send a key acquisition request to a remote key server to obtain the field encryption key; if the remote key loader fails to obtain the field encryption key, the composite key loader calls a local key loader to obtain a local emergency key; the local emergency key obtained by the composite key loader is determined as the currently valid key; when performing a write operation on the database field, the corresponding field processing component is called according to the pre-configured encryption configuration information, and the field processing component uses the currently valid key to encrypt the data to be written to the database field. This technical solution coordinates the remote key loader and the local key loader for loading the field encryption key through a composite key loader. When the remote key loader fails to obtain the field encryption key, it can automatically switch to the local key loader to obtain the local emergency key and determine the local emergency key as the currently valid key. Therefore, even in cases where the remote key server is unreachable, network communication is abnormal, or key request processing is abnormal, a usable key can still be provided for database field encryption processing, reducing the risk that abnormal remote key retrieval will prevent the database field from being written or read normally.

[0036] Meanwhile, when performing write or read operations on database fields, the corresponding field processing component is called according to the pre-established association between the database field and the field processing component. The field processing component then uses the currently valid key to perform field encryption or decryption, thereby setting the database field encryption logic in the data persistence process. This eliminates the need for business processing logic to set up encryption or decryption calls for each field to be encrypted, achieving transparent encryption at the database field level.

[0037] Furthermore, assuming the remote key loader can successfully obtain the field encryption key, the remote key server can determine the legitimacy of the current key acquisition request through application authentication, request signature verification, access permission verification, and anti-replay verification. It then retrieves the corresponding field encryption key from the key store, performs transmission protection on the field encryption key, and sends it to the application client. The application client obtains the field encryption key through the corresponding decryption method and entrusts it to the unified key manager for management. Thus, centralized management and secure distribution of field encryption keys can be achieved when the remote key is available, while local emergency keys can maintain continuous execution of field encryption processing in the event of remote key retrieval failure.

[0038] This application's embodiments take into account that, for business systems that need to encrypt sensitive fields in the database, if the key used for field encryption relies on a single remote acquisition method, then if the remote key server experiences network anomalies, service anomalies, or other situations that cause key acquisition failure, the application client may not be able to obtain the key required to perform database field encryption, thereby affecting the normal writing or reading of database fields. Furthermore, if keys from different sources correspond to different encryption processing logic, then when switching between the remote key and the local emergency key, the subsequent field encryption process also needs to be adjusted according to the key source, increasing the coupling between the key acquisition process and the field processing process. Additionally, if the database field encryption operation is directly set in the business processing logic, different business functions need to call the encryption interface or decryption interface separately, which not only increases the amount of business code modification but also easily reduces the consistency of database field encryption processing due to differences in the processing logic used by different business functions.

[0039] Based on this, this application provides a transparent encryption scheme at the database field level. A composite key loader prioritizes calling a remote key loader to obtain the field encryption key from a remote key server. If remote key retrieval fails, a local key loader is called to obtain a local emergency key, thus forming a key loading mechanism that combines remote key acquisition and local emergency key acquisition. Furthermore, by pre-configuring the association between database fields and field processing components, the corresponding field processing component is automatically invoked when performing database field write or read operations, achieving automatic encryption or decryption of database fields. This improves the availability of field encryption key acquisition while reducing the intrusion of field encryption functionality into business processing logic.

[0040] 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, system, or apparatus capable of implementing the above functions. The following description uses a database field-level transparent encryption system as an example to illustrate this embodiment and the subsequent embodiments.

[0041] Based on this, embodiments of this application provide a database field-level transparent encryption method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the database field-level transparent encryption method of this application.

[0042] In this embodiment, the database field-level transparent encryption method includes steps S10 to S40. The following provides a detailed explanation of each step.

[0043] like Figure 1 As shown, the first embodiment of this application proposes a database field-level transparent encryption method, the method comprising: In step S10, when loading the key used for database field encryption, the composite key loader calls the remote key loader to send a key retrieval request to the remote key server to obtain the field encryption key.

[0044] The technical solution of this embodiment can solve the problems of scattered key management and interruption of database read and write processes due to network anomalies in existing technical solutions.

[0045] In this embodiment, the field encryption key is a key used to perform encryption or decryption processing on a predetermined database field. The database field can be a sensitive field that needs to be encrypted and protected in a business application, such as identity information field, account information field, contact information field, or other business fields that need to be encrypted and protected. This embodiment does not specifically limit this.

[0046] The composite key loader is a key loading component set up in the application client to coordinate different key loading methods. The composite key loader includes a remote key loader and a local key loader.

[0047] The remote key loader is used to communicate with the remote key server and send a key acquisition request to the remote key server to obtain the field encryption key distributed by the remote key server; the local key loader is used to obtain a pre-configured local emergency key from the application client when the remote key loader fails to obtain the field encryption key.

[0048] Specifically, when the application client needs to load a key for encrypting database fields, the composite key loader first invokes the remote key loader. The remote key loader sends a key retrieval request to the remote key server. In response to the key retrieval request, the remote key server determines the field encryption key corresponding to the application client and sends the field encryption key to the application client in a transmission-protected format.

[0049] In one feasible implementation, the process of obtaining the field encryption key from the remote key server by calling the remote key loader through the composite key loader in step S10 can further include steps S101 to S103: Step S101: When loading the key used for database field encryption, a key acquisition request carrying application identity information and request signature is generated. In some embodiments of this application, the application identity information is used to identify the application client currently requesting the encryption key of the field, so that the remote key server can determine the application client corresponding to the current key acquisition request based on the application identity information.

[0050] The request signature is used by the remote key server to verify the legitimacy and integrity of the key acquisition request. The application client can generate a corresponding request signature based on the pre-configured signature information and the request content in the key acquisition request, and carry the request signature and application identity information in the key acquisition request.

[0051] Step S102: The remote key loader sends the key acquisition request to the remote key server. The remote key server verifies the application identity information, the request signature, and the access permissions, and performs anti-replay verification on the key acquisition request. Specifically, after receiving the key acquisition request, the remote key server can verify the key acquisition request through the authentication and authorization center.

[0052] Specifically, verifying the application identity information is used to determine whether the application client initiating the current key acquisition request is a legitimate application client; verifying the request signature is used to determine whether the key acquisition request originates from the corresponding application client and whether the request content has been illegally modified during transmission; verifying access permissions is used to determine whether the application client has the permission to obtain the encryption key for the corresponding field; and the anti-replay verification is used to identify key acquisition requests that have already been used or key acquisition requests that have been illegally submitted repeatedly.

[0053] If all the above verifications pass, the remote key server performs the determination and distribution of the field encryption key; if at least one verification fails, the remote key server may refuse the current key acquisition request.

[0054] Step S103: Receive the encrypted field encryption key sent by the remote key server after successful verification; In one specific implementation, such as Figure 2 As shown, the remote key server includes an authentication and authorization center, a key management engine, and a key store.

[0055] The remote key server verifies the application's identity information, request signature, access permissions, and key acquisition request to prevent replay attacks through the authentication and authorization center. After successful verification, the key management engine determines the initial field encryption key corresponding to the application client based on the key acquisition request.

[0056] The initial field encryption key refers to the field encryption key determined by the remote key server based on the application client's identity and key management information, which has not yet been protected by SM2 encryption for this network transmission.

[0057] The remote key server retrieves the ciphertext corresponding to the initial field encryption key from the key library based on the key information corresponding to the initial field encryption key, and decrypts the ciphertext to obtain the decrypted initial field encryption key.

[0058] Furthermore, the remote key server uses the SM2 public key corresponding to the application client to encrypt the decrypted initial field encryption key to obtain the encrypted field encryption key, and sends the encrypted field encryption key to the application client.

[0059] In one feasible implementation, such as Figure 3 As shown, after the remote key loader successfully receives the encrypted field encryption key, the application client uses the SM2 private key corresponding to the SM2 public key to decrypt the received encrypted field encryption key and obtain the decrypted field encryption key.

[0060] The encryption key obtained from decryption can be managed by a unified key manager for use in subsequent database field encryption or decryption operations.

[0061] In this embodiment, the application client does not need to receive the plaintext field encryption key directly from the remote key server. Instead, the remote key server uses the SM2 public key corresponding to the application client to encrypt the field encryption key to be transmitted, and the application client uses the corresponding SM2 private key to decrypt it, thereby reducing the risk of leakage of the field encryption key during network transmission.

[0062] Step S20: When the remote key loader fails to obtain the field encryption key, the local key loader is invoked by the composite key loader to obtain the local emergency key.

[0063] Specifically, when the remote key loader fails to obtain the field encryption key due to network communication abnormalities, unreachable remote key server, request timeout, request verification failure, service processing abnormalities, or other reasons, the composite key loader calls the local key loader.

[0064] The local key loader reads the local configuration file pre-configured in the application client, obtains the local emergency key from the local configuration file, and returns the read local emergency key to the composite key loader.

[0065] The local emergency key is used to provide a key for the application client to continue performing database field encryption or decryption when the remote field encryption key is not successfully obtained.

[0066] Therefore, when the remote key server is available, the application client can obtain the field encryption key distributed by the remote key server through the remote key loader; when the remote key server is unavailable or the remote key loader fails to obtain the field encryption key, the composite key loader can switch to the local key loader to obtain the local emergency key, thereby reducing the impact of a single remote key retrieval method on the availability of field encryption processing.

[0067] Step S30: Determine the local emergency key obtained by the composite key loader as the currently valid key.

[0068] In this embodiment, the currently valid key is the key that the application client is currently using to encrypt or decrypt database fields.

[0069] After the remote key loader fails to obtain the field encryption key and the local key loader successfully reads the local emergency key, the application client determines the local emergency key as the current valid key and can hand over the current valid key to the unified key manager for management.

[0070] The unified key manager provides the field encryption keys that are currently available to subsequent field processing components, so that the field processing components do not need to directly know whether the key used comes from a remote key server or a local configuration file.

[0071] In one feasible implementation, after determining the local emergency key as the current valid key, the current valid key can be memory obfuscated, and the memory obfuscated current valid key can be saved in the local memory of the application client.

[0072] The memory obfuscation process is used to reduce the risk that the currently valid key will exist in the application client's runtime memory in plaintext form for an extended period of time.

[0073] When it is necessary to perform database field encryption or decryption operations, the managed currently valid key can be obtained through the unified key manager and provided to the corresponding field processing component.

[0074] It should be noted that if the remote key loader successfully obtains the field encryption key, the application client can hand over the field encryption key obtained by decrypting the SM2 private key to the unified key manager for management, and use it as the key for database field encryption processing under normal remote key retrieval conditions; while step S30 mainly describes the process of determining the local emergency key when remote key retrieval fails.

[0075] Step S40: When performing a write operation on the database field, the corresponding field processing component is called according to the pre-configured encryption configuration information, and the data to be written to the database field is encrypted by the field processing component using the currently valid key.

[0076] In this embodiment, the encryption configuration information is used to establish the association between the database field to be encrypted and the corresponding field processing component.

[0077] Before performing database field write or read operations, the encryption configuration information can be pre-configured to determine the database fields that need to be encrypted and the corresponding field processing components.

[0078] In a preferred embodiment, such as Figure 4 As shown, the field processing component is a custom TypeHandler based on the MyBatis framework.

[0079] You can configure a custom TypeHandler for the database fields that need to be encrypted using MyBatis' Mapper XML file and / or annotations set on the properties of business objects, thereby establishing the association between the database fields to be encrypted and the custom TypeHandler.

[0080] When MyBatis performs write or read operations on the corresponding database fields, it automatically calls the corresponding custom TypeHandler based on the relationship.

[0081] Therefore, business processing code does not need to explicitly call the encryption or decryption interface for each sensitive field to complete field encryption or decryption during the MyBatis data persistence process.

[0082] In one feasible implementation, the process of writing the database field includes: When performing a write operation on a database field, the field processing component corresponding to the database field is invoked according to the pre-established association relationship; The field processing component uses the currently valid key to encrypt the data to be written into the database field, resulting in ciphertext data. The encrypted data is used as the write data for the database field, and a database write operation is performed.

[0083] Specifically, the business layer passes the business object containing the plaintext data of the database fields to the MyBatis persistence layer, and MyBatis calls the setNonNullParameter method of the corresponding custom TypeHandler when setting the database field parameters.

[0084] The custom TypeHandler obtains the currently valid key through the unified key manager and calls the field encryptor to perform encryption processing on the plaintext data to be written to the database field.

[0085] In a preferred embodiment, the field encryptor is an SM4 encryptor, which uses the currently valid key to perform SM4 encryption on the plaintext data to be written to the database field to obtain ciphertext data.

[0086] A custom TypeHandler sets the encrypted data to the parameter position in the PreparedStatement corresponding to the database field. MyBatis then executes the database write statement, thereby writing the encrypted data into the database.

[0087] In one feasible implementation, the process of reading the database field includes: Execute a database query to obtain query results containing the data of the database fields; When mapping the query results, the field processing component corresponding to the database field is called according to the association relationship; The field processing component uses the currently valid key to decrypt the data read from the database field and sets the decrypted plaintext data into the corresponding attribute of the business object.

[0088] Specifically, when MyBatis executes a database query operation and obtains a result set containing data from the database fields to be processed, during the process of mapping the result set to a business object, it determines the custom TypeHandler corresponding to the database field based on the pre-configured encrypted configuration information and calls the getNullableResult method of the custom TypeHandler.

[0089] The custom TypeHandler obtains the currently valid key through the unified key manager and calls the field encryptor to decrypt the data read from the database field.

[0090] In a preferred embodiment, the field encryptor is an SM4 encryptor, which performs SM4 decryption on the data read from the database field using the currently valid key.

[0091] After successful decryption, the custom TypeHandler returns the decrypted plaintext data to MyBatis, which then sets the plaintext data into the corresponding property of the business object.

[0092] Furthermore, to ensure compatibility with historical plaintext data already stored in the database before enabling the database field-level encryption function, in one feasible implementation, the database field reading process may also include compatibility processing.

[0093] When the decryption of data read from a database field fails through the field processing component, the data read from the database field is directly set into the corresponding attribute of the business object to ensure compatibility with unencrypted historical plaintext data in the database.

[0094] Specifically, during the transition phase after the database field-level encryption function is enabled, the same database field may contain both historical plaintext data written before the field encryption function was enabled and ciphertext data written after the field encryption function was enabled.

[0095] After obtaining the data to be processed, the field processing component attempts to decrypt it using the currently valid key. If decryption is successful, the obtained plaintext data is mapped to the business object; if decryption fails, the mapping of the database query results is not interrupted due to the decryption failure, but the original data read from the database field is set into the corresponding attribute of the business object.

[0096] For newly written or subsequently updated data in the database, the aforementioned database field writing process is still followed. The data is encrypted by the field processing component before it is actually written to the database, so that as the database data is added and updated, the historical plaintext data in the database fields gradually transitions to ciphertext data.

[0097] Therefore, this embodiment can achieve compatible reading of historical plaintext data and newly written ciphertext data without having to complete the encryption and conversion of all historical data at once.

[0098] like Figure 5 As shown, the second embodiment of this application proposes a database field-level transparent encryption method. Based on the first embodiment described above, this embodiment further explains the rotation process of the field encryption key. Content that is the same as or similar to the first embodiment can be referred to the foregoing description, and will not be repeated here.

[0099] The key rotation process in this embodiment includes: Step S501: Receive a key update notification sent by a remote key server.

[0100] The remote key server can manage the lifecycle of field encryption keys. When a field encryption key is rotated, the remote key server generates a new field encryption key or activates a pre-generated rotated field encryption key and sends a key update notification to the corresponding application client.

[0101] Step S502: In response to the key update notification, obtain the rotated field encryption key through the remote key loader.

[0102] Specifically, after receiving the key update notification, the application client invokes the remote key loader through the composite key loader. The remote key loader then resends the key retrieval request to the remote key server. The remote key server determines the rotated field encryption key to be distributed to the application client based on the updated key status and returns the rotated field encryption key to the application client.

[0103] The authentication, request signature verification, access permission verification, anti-replay verification, and SM2 encrypted transmission process of the rotated field encryption key can be performed by referring to the method of remotely obtaining the field encryption key in the first embodiment.

[0104] Step S503: Determine the rotated field encryption key as the new currently valid key.

[0105] After obtaining the rotated field encryption key, the application client can hand over the rotated field encryption key to the unified key manager for management, and use it as the new currently valid key for subsequent database field encryption processing.

[0106] Subsequently, when performing subsequent write or read operations on the database field, the field processing component obtains the currently valid key after rotation through the unified key manager, and uses the currently valid key to perform field encryption or field decryption.

[0107] Therefore, by sending a key update notification through a remote key server and triggering the application client to reacquire the field encryption key, the database field encryption key can be dynamically updated without modifying the business processing code, thus improving the convenience of field encryption key lifecycle management.

[0108] like Figure 6 As shown, the third embodiment of this application proposes a database field-level transparent encryption method. This embodiment, based on the first or second embodiment described above, further explains the compatibility processing of historical plaintext data during the database field reading process. Content that is the same as or similar to the first or second embodiment described above can be referred to the foregoing description and will not be repeated here.

[0109] Before the database field-level encryption function is enabled, historical business data may have already been stored in the database. This historical business data is stored in plaintext without field encryption processing.

[0110] After the database field-level encryption function is enabled, the data newly written or updated to the database field is encrypted by the field processing component before being written to the database, and stored in ciphertext form, following the field writing process in the first embodiment.

[0111] Therefore, during the transition phase after the database field-level encryption function is enabled, historical plaintext data and ciphertext data may coexist in the same database field.

[0112] The compatibility processing procedure includes: Step S601: Obtain the data to be processed from the database field.

[0113] The application client executes a database query, and when MyBatis maps the query results, it calls the custom TypeHandler corresponding to the database field, which then retrieves the data to be processed.

[0114] Step S602: Decrypt the data to be processed using the currently valid key through the field processing component.

[0115] The custom TypeHandler obtains the currently valid key through the unified key manager and calls the SM4 encryptor to attempt to perform SM4 decryption on the data to be processed.

[0116] Step S603: When the data to be processed is successfully decrypted, the decrypted plaintext data is set to the corresponding attribute of the business object.

[0117] Step S604: When the decryption of the data to be processed fails, the data to be processed read from the database field is directly set into the corresponding attribute of the business object.

[0118] Therefore, for ciphertext data written after the database field-level encryption function is enabled, the field processing component can use the currently valid key to perform decryption and return plaintext data to the business layer; for historical plaintext data that existed before the database field-level encryption function was enabled, the original field data can be directly returned to the business layer when decryption fails, so that historical plaintext data and ciphertext data can share the same database field reading process.

[0119] Furthermore, for newly written or updated data in the database, field encryption is still performed by the field processing component before the actual database write. Therefore, as historical data is continuously updated or rewritten, the proportion of ciphertext data in the database fields can be gradually increased, achieving a gradual migration of historical plaintext data to ciphertext data.

[0120] like Figure 7 As shown, the fourth embodiment of this application proposes a database field-level transparent encryption method. This embodiment describes the authentication, acquisition, and secure distribution process of the field encryption key from the remote key server side.

[0121] In this embodiment, the database field-level transparent encryption method is applied to a remote key server, and the method includes steps S701 to S702.

[0122] Step S701: Receive the key retrieval request sent by the application client through the composite key loader calling the remote key loader when loading the key used for database field encryption.

[0123] In this embodiment, the remote key server is used to provide field encryption key management and distribution services to one or more application clients.

[0124] The application client is equipped with a composite key loader, which includes a remote key loader and a local key loader.

[0125] When the application client needs to load a key for encrypting database fields, the composite key loader calls the remote key loader, which then sends a key retrieval request to the remote key server.

[0126] The key acquisition request can carry application identity information and request signature.

[0127] In one feasible implementation, the remote key server can receive key retrieval requests sent by the remote key loader via a RESTful API.

[0128] Step S702: Send the field encryption key to the application client according to the key acquisition request.

[0129] Specifically, a remote key server includes an authentication and authorization center, a key management engine, and a key store.

[0130] Upon receiving a key acquisition request, the authentication and authorization center verifies the application identity information, request signature, and corresponding access permissions carried in the key acquisition request, and performs anti-replay verification on the key acquisition request.

[0131] After successful verification, the key management engine determines the initial field encryption key corresponding to the application client based on the key acquisition request.

[0132] The remote key server retrieves the ciphertext corresponding to the initial field encryption key from the key store based on the key information corresponding to the initial field encryption key.

[0133] The key ciphertext is the ciphertext data formed by encrypting the field encryption key using the SM4 algorithm. Therefore, the field encryption key is stored in ciphertext form in the key library, rather than being stored permanently in plaintext form.

[0134] After obtaining the key ciphertext, the remote key server decrypts the key ciphertext to obtain the decrypted initial field encryption key.

[0135] Furthermore, the remote key server determines the SM2 public key corresponding to the application client based on the application identity information of the application client, and uses the SM2 public key to encrypt the decrypted initial field encryption key to obtain the encrypted field encryption key.

[0136] The remote key server sends the encryption key of the encrypted field to the application client.

[0137] After receiving the encrypted field encryption key, the remote key loader in the application client uses the SM2 private key corresponding to the SM2 public key to perform decryption to obtain the field encryption key.

[0138] Therefore, the field encryption key is statically stored and protected in the key store using the ciphertext generated by the SM4 algorithm. When the remote key server distributes the key to the application client, the field encryption key to be transmitted is encrypted using the SM2 public key corresponding to the application client, thereby protecting both the storage process and the network transmission process of the field encryption key.

[0139] When the application client's remote key loader fails to obtain the encryption key for the field, the application client calls the local key loader through the composite key loader to obtain the local emergency key, and determines the local emergency key as the currently valid key.

[0140] After obtaining the current valid key, when the application client performs write or read operations on a database field, it calls the corresponding field processing component according to the pre-configured encryption configuration information. The field processing component then uses the current valid key to perform database field encryption or decryption.

[0141] It should be noted that the remote key server itself does not directly perform write encryption or read decryption operations on database fields of the application client. It is mainly responsible for the authentication, acquisition, management and secure distribution of field encryption keys, providing field encryption keys for the application client to perform transparent encryption at the database field level.

[0142] In one feasible implementation, before the remote key server sends the field encryption key to the application client according to the key acquisition request, the key store pre-stores the key ciphertext formed by encrypting the field encryption key using the SM4 algorithm.

[0143] In other words, the key store contains the ciphertext of the key corresponding to the field encryption key. When the remote key server needs to distribute the field encryption key to the application client, it determines the corresponding field encryption key based on the key acquisition request, retrieves the corresponding ciphertext from the key store, decrypts the ciphertext, and then uses the SM2 public key to encrypt the decrypted field encryption key for transmission.

[0144] The above method can form a secure distribution chain for field encryption keys: "SM4 key ciphertext storage - server-side decryption to obtain field encryption keys - SM2 public key encrypted transmission - client-side SM2 private key decryption".

[0145] The fifth embodiment of this application proposes a database field-level transparent encryption method, and further explains the rotation process of field encryption keys from the remote key server side.

[0146] The key rotation process includes: Step S801: Maintain the status information of the field encryption key.

[0147] The remote key server maintains the status information corresponding to the encryption keys for different fields through the key management engine, so as to represent the current usage status of the field encryption keys.

[0148] Step S802: When the field encryption key is rotated, generate or enable the rotated field encryption key and update the corresponding key status information.

[0149] When the preset key rotation conditions are met, the remote key server generates a new field encryption key, or enables the pre-generated rotated field encryption key, and updates the corresponding key status information.

[0150] Step S803: Send a key update notification to the application client.

[0151] After completing the field encryption key rotation and status update, the remote key server sends a key update notification to the corresponding application client, so that the application client responds to the key update notification and resends the key acquisition request through the remote key loader.

[0152] Step S804: Receive the key acquisition request sent by the application client in response to the key update notification, and determine the rotated field encryption key as the target field encryption key that is currently in a valid state based on the updated key status information.

[0153] The remote key server can perform identity verification, request signature verification, access permission verification, and anti-replay verification on the re-received key acquisition request according to the request verification method in the fourth embodiment.

[0154] After successful verification, the remote key server determines the rotated field encryption key based on the updated key status information and uses it as the target field encryption key to be distributed to the application client.

[0155] Subsequently, following the secure distribution method of the field encryption key in the fourth embodiment, the key ciphertext corresponding to the target field encryption key can be obtained from the key store, the key ciphertext can be decrypted, the decrypted target field encryption key can be encrypted using the SM2 public key corresponding to the application client, and the encrypted field encryption key can be sent to the application client.

[0156] After receiving the rotated field encryption key, the application client decrypts it accordingly and uses the rotated field encryption key as the new currently valid key for subsequent database field write or read operations.

[0157] Therefore, after the field encryption key is rotated, the remote key server can use key status management and key update notification to enable the application client to obtain the rotated field encryption key again, thereby realizing the dynamic update of the field encryption key.

[0158] Please refer to Figure 8 This application also provides a database field-level transparent encryption device, which is applied to an application client. The database field-level transparent encryption device includes: The request sending module 10 is used to send a key acquisition request to the remote key server through the composite key loader when loading the key for database field encryption, so as to obtain the field encryption key; Key loading module 20 is used to call local key loader to obtain local emergency key through composite key loader when the remote key loader fails to obtain the field encryption key; The valid key determination module 30 is used to determine the key obtained by the composite key loader as the current valid key; The transparent encryption module 40 is used to call the corresponding field processing component according to the pre-configured encryption configuration information when performing write or read operations on the database field. The field processing component uses the currently valid key to encrypt the data to be written to the database field, or to decrypt the data read from the database field.

[0159] Please refer to Figure 9 This application also provides a database field transparent encryption device, which is applied to a remote server, and the database field-level transparent encryption method includes: The request receiving module 100 is used to receive a key acquisition request sent by the application client when loading the key for database field encryption by calling the remote key loader through the composite key loader; The key distribution module 200 is used to send a field encryption key to the application client according to the key acquisition request.

[0160] When the remote key loader fails to obtain the field encryption key, the application client calls the local key loader through the composite key loader to obtain the local emergency key and determines the local emergency key as the current valid key. When performing write or read operations on the database field, the application client calls the corresponding field processing component according to the pre-configured encryption configuration information. The field processing component uses the current valid key to encrypt the data to be written to the database field or to decrypt the data read from the database field.

[0161] In one feasible implementation, the key distribution module can also be used to verify the application identity information, request signature, and access permissions carried in the key acquisition request through the authentication and authorization center, and perform anti-replay verification on the key acquisition request; after the verification is successful, the key management engine determines the field encryption key corresponding to the application client according to the key acquisition request, obtains the corresponding key ciphertext from the key library, decrypts the key ciphertext, and encrypts the decrypted field encryption key using the SM2 public key corresponding to the application client before sending it to the application client.

[0162] The specific execution process of each module can be referred to in the above embodiment of the transparent encryption method for database field level on the remote key server side, and will not be repeated here.

[0163] The database field-level transparent encryption device provided in this application adopts the database field-level transparent encryption method in the above embodiments. It can maintain database field encryption processing through a local emergency key when the remote field encryption key is not successfully obtained, and perform automatic field-level encryption or decryption through a pre-configured field processing component, thereby improving the availability of database field encryption processing and reducing the direct dependence of business code on field encryption logic.

[0164] This application provides a database field-level transparent encryption 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 database field-level transparent encryption method in the first embodiment described above.

[0165] The following is for reference. Figure 10 This document illustrates a structural diagram of a database field-level transparent encryption device suitable for implementing embodiments of this application. The database field-level transparent encryption device in these embodiments 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), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 10 The database field-level transparent encryption device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0166] like Figure 10As shown, the database field-level transparent encryption device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory 1002 or a program loaded from storage device 1003 into random access memory 1004. Random access memory 1004 also stores various programs and data required for the operation of the device. The processing unit 1001, read-only memory 1002, and random access memory 1004 are interconnected via bus 1005. Input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to input / output interface 1006: input devices 1007 including, for example, touch screens, 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 database field-level transparent encryption device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show database field-level transparent encryption 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.

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

[0168] The database field-level transparent encryption device provided in this application, employing the database field-level transparent encryption method described in the above embodiments, can solve the technical problems of scattered key management and interruption of database read / write processes due to network anomalies. Compared with the prior art, the beneficial effects of the database field-level transparent encryption device provided in this application are the same as those of the database field-level transparent encryption method provided in the above embodiments, and other technical features in this database field-level transparent encryption device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0171] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the database field-level transparent encryption method in the above embodiments.

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

[0173] The aforementioned computer-readable storage medium may be included in a database field-level transparent encryption device; or it may exist independently and not be assembled into a database field-level transparent encryption device.

[0174] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a database field-level transparent encryption device, cause the database field-level transparent encryption device to: send a key acquisition request to a remote key server and receive a field encryption key returned by the remote key server in response to the key acquisition request; The key used for encrypting database fields is obtained through the composite key loader, and the obtained key is determined as the current valid key through the unified key manager; When performing write or read operations on the database field, the corresponding field processing component is invoked according to the pre-configured encryption configuration information to encrypt the data to be written to the database field or to decrypt the data read from the database field.

[0175] 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).

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

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

[0178] 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 database field-level transparent encryption method. This solves the technical problems of scattered key management and interruption of database read / write processes due to network anomalies. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the database field-level transparent encryption method provided in the above embodiments, and will not be repeated here.

[0179] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the database field-level transparent encryption method described above.

[0180] The computer program product provided in this application can solve the technical problems of scattered key management and interruption of database read / write processes due to network anomalies. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the database field-level transparent encryption method provided in the above embodiments, and will not be repeated here.

[0181] 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 database field-level transparent encryption method, characterized in that, The method is applied to an application client, and the method includes: When loading the key used for database field encryption, the composite key loader calls the remote key loader to send a key retrieval request to the remote key server to obtain the field encryption key; When the remote key loader fails to obtain the field encryption key, the local key loader is invoked by the composite key loader to obtain the local emergency key. The local emergency key obtained by the composite key loader is determined as the currently valid key; When performing a write operation on the database field, the corresponding field processing component is invoked according to the pre-configured encryption configuration information. The field processing component then uses the currently valid key to encrypt the data to be written to the database field.

2. The database field-level transparent encryption method as described in claim 1, characterized in that, When loading the key used for database field encryption, the process of using a composite key loader to call a remote key loader to send a key retrieval request to a remote key server to obtain the field encryption key includes the following steps: When loading the key used for encrypting database fields, a key retrieval request carrying application identity information and request signature is generated; The remote key loader sends a key acquisition request to the remote key server, and the remote key server verifies the application identity information, the request signature, access permissions, and anti-replay attack measures. The encrypted field encryption key is received by the remote key server after successful verification.

3. The database field-level transparent encryption method as described in claim 2, characterized in that, The remote key server includes an authentication and authorization center, a key management engine, and a key store. The step of sending a key acquisition request to the remote key server through the remote key loader, and having the remote key server verify the application identity information, the request signature, access permissions, and replay attack prevention includes: The remote key loader sends a key acquisition request to the remote key server, which then verifies the application identity information, the request signature, the access permissions, and replay attack prevention through the authentication and authorization center. The remote key server determines the initial field encryption key corresponding to the application client based on the key acquisition request through the key management engine, obtains the key ciphertext corresponding to the initial field encryption key from the key library, decrypts the key ciphertext to obtain the decrypted initial field encryption key, and encrypts the decrypted initial field encryption key using the SM2 public key corresponding to the application client to obtain the encrypted field encryption key.

4. The database field-level transparent encryption method as described in claim 2, characterized in that, After the step of obtaining the field encryption key from the remote key server by calling the remote key loader through the composite key loader when loading the key for database field encryption, the method further includes: When the remote key loader successfully obtains the field encryption key, it decrypts the received encrypted field encryption key using the SM2 private key corresponding to the SM2 public key of the application client to obtain the decrypted field encryption key.

5. The database field-level transparent encryption method as described in claim 1, characterized in that, The step of obtaining the local emergency key by calling the local key loader through the composite key loader includes: The local key loader is invoked to read the local emergency key pre-configured in the local configuration file of the application client, and the read local emergency key is returned to the composite key loader.

6. The database field-level transparent encryption method as described in claim 1, characterized in that, After the step of determining the local emergency key obtained by the composite key loader as the currently valid key, the method further includes: The currently valid key is memory obfuscated, and the memory obfuscated currently valid key is stored in the local memory of the application client.

7. The database field-level transparent encryption method as described in claim 1, characterized in that, Before the step of performing a write operation on the database field, the method further includes: The encryption configuration information is pre-configured to establish the association between the database fields to be encrypted and the corresponding field processing components.

8. The database field-level transparent encryption method as described in claim 7, characterized in that, The steps for performing a write operation on the database field include: When performing a write operation on the database field, the field processing component corresponding to the database field is invoked according to the association relationship; The field processing component uses the currently valid key to perform encryption processing on the data to be written into the database field, thereby obtaining ciphertext data. The encrypted data is used as the write data for the database field, and a database write operation is performed.

9. The database field-level transparent encryption method as described in claim 8, characterized in that, After the step of performing a write operation on the database field, the method further includes: Execute a database query to obtain query results containing data from the database fields; When mapping the query results, the field processing component corresponding to the database field is called according to the association relationship; The field processing component uses the currently valid key to decrypt the data read from the database field and sets the decrypted plaintext data into the corresponding attribute of the business object.

10. The database field-level transparent encryption method as described in claim 9, characterized in that, The step of reading from the database field further includes compatibility processing of the data in the database field, specifically including: When decryption of data read from the database field fails by calling the field processing component, the data read from the database field is set into the corresponding attribute of the business object to ensure compatibility with unencrypted historical plaintext data in the database.

11. The database field-level transparent encryption method as described in claim 1, characterized in that, The step of sending a key acquisition request to the remote key server by invoking the remote key loader through the composite key loader also includes a key rotation operation, specifically including: Receive key update notification sent by the remote key server; In response to the key update notification, the rotated field encryption key is obtained through the remote key loader, and the rotated field encryption key is determined as the new currently valid key.

12. A database field-level transparent encryption method, characterized in that, The method is applied to a remote key server, and the method includes: Receive key retrieval requests sent by the application client through the composite key loader to the remote key loader when loading the key used for database field encryption; According to the key acquisition request, a field encryption key is sent to the application client. If the remote key loader fails to acquire the field encryption key, the application client uses the composite key loader to call a local key loader to obtain a local emergency key. The local emergency key obtained by the composite key loader is then determined as the currently valid key. When performing write or read operations on the database field, the corresponding field processing component is called according to pre-configured encryption configuration information. The field processing component uses the currently valid key to encrypt the data to be written to the database field or to decrypt the data read from the database field.

13. The database field-level transparent encryption method as described in claim 12, characterized in that, The remote key server includes an authentication and authorization center, a key management engine, and a key store. The step of sending the field encryption key to the application client based on the key acquisition request includes: The authentication and authorization center performs anti-replay verification on the application identity information, request signature, access permissions, and key acquisition request carried in the key acquisition request. After successful verification, the key management engine determines the initial field encryption key corresponding to the application client based on the key acquisition request, obtains the key ciphertext corresponding to the initial field encryption key from the key library, decrypts the key ciphertext to obtain the decrypted initial field encryption key, and encrypts the decrypted initial field encryption key using the SM2 public key corresponding to the application client to obtain the encrypted field encryption key. Send the encrypted field encryption key to the application client.

14. The database field-level transparent encryption method as described in claim 12, characterized in that, Before the step of the receiving application client calling the key retrieval request sent by the remote key loader through the composite key loader when loading the key for database field encryption, the method further includes: Maintain the status information of the encryption key for the field; When the field encryption key is rotated, the remote key server generates or enables the rotated field encryption key and updates the key status information corresponding to the field encryption key; Send a key update notification to the application client so that the application client responds to the key update notification by sending a key acquisition request; The system receives a key acquisition request from the application client in response to the key update notification, and determines the rotated field encryption key as the field encryption key that is currently in a valid state based on the updated key status information.

15. The database field-level transparent encryption method as described in claim 13, characterized in that, Before the step of sending the field encryption key to the application client according to the key acquisition request, the method further includes: The ciphertext of the key formed by the encryption key of the field encrypted using the SM4 algorithm is stored in the key store.

16. A database field-level transparent encryption device, characterized in that, The device is installed in the application client, and the device includes: The request sending module is used to send a key retrieval request to the remote key server through the composite key loader when loading the key used for database field encryption, so as to obtain the field encryption key; The key loading module is used to obtain a local emergency key by calling the local key loader through the composite key loader when the remote key loader fails to obtain the field encryption key. The valid key determination module is used to determine the key obtained by the composite key loader as the current valid key; The transparent encryption module is used to call the corresponding field processing component according to the pre-configured encryption configuration information when performing a write operation on the database field. The field processing component uses the currently valid key to encrypt the data to be written to the database field.

17. A database field-level transparent encryption device, characterized in that, The device is located on a remote key server, and the device includes: The request receiving module is used to receive key retrieval requests sent by the application client through the composite key loader calling the remote key loader when loading the key used for database field encryption; The key distribution module is used to send a field encryption key to the application client according to the key acquisition request. When the application client fails to acquire the field encryption key from the remote key loader, it uses the composite key loader to call a local key loader to obtain a local emergency key. The local emergency key obtained by the composite key loader is then determined as the currently valid key. When performing a write operation on the database field, the module calls the corresponding field processing component according to pre-configured encryption configuration information, and the field processing component uses the currently valid key to encrypt the data to be written to the database field.

18. A database field-level transparent encryption 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 database field-level transparent encryption method as described in any one of claims 1 to 15.

19. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the database field-level transparent encryption method as described in any one of claims 1 to 15.

20. 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 database field-level transparent encryption method as described in any one of claims 1 to 15.

Images