Sensitive data encryption storage method, device, equipment and product

Abstract

The application discloses a sensitive data encryption storage method, device and equipment and product, relates to the technical field of data encryption, and comprises the following steps: performing white list configuration on an original data field to obtain a to-be-encrypted field list and a lifecycle state of the to-be-encrypted field list; selecting an encryption strategy according to the to-be-encrypted field list to obtain the encryption strategy, and performing syntax tree analysis and rewriting on an original SQL query statement according to the encryption strategy to obtain a rewritten SQL statement; performing data migration on the to-be-encrypted field list through an encryption lifecycle state machine according to the rewritten SQL statement and the lifecycle state of the to-be-encrypted field list to obtain a migrated ciphertext field; decrypting and desensitizing the ciphertext field to obtain a desensitization value, and writing the desensitization value into an original field corresponding to the original data field through the encryption strategy to obtain an encryption storage result.

Description

Technical Field

[0001] This application relates to the field of data encryption technology, and in particular to methods, apparatus, devices and products for encrypting and storing sensitive data. Background Technology

[0002] Currently, the encryption and storage of sensitive data mainly adopts the solution of explicitly calling the encryption and decryption interface at the application layer, or by relying on the database's built-in functions. To compensate for the lack of ciphertext query capabilities, the industry has introduced blind index technology, which uses the hash value of an additional storage field to assist in equivalent retrieval. In terms of data migration, some solutions adopt a dual-write mode, writing plaintext and ciphertext simultaneously during the transition period. The de-identification operation is usually performed at the application presentation layer, while the plaintext data is still retained in the database. The encryption strategy is relatively fixed, and different business scenarios often share the same encryption logic. When migrating large-scale data, traditional pagination queries (LIMIT OFFSET) are commonly used for batch processing.

[0003] However, the existing technical solutions mentioned above are fragmented in function, lack a unified fault tolerance and retry mechanism, and cannot be compatible with mixed queries after encryption failure. As a result, during processes such as canary releases and data migration, it is difficult to ensure business continuity, query integrity and data security at the same time. In particular, they cannot meet the core requirements of high reliability scenarios such as finance for smooth migration without downtime, flexible strategy adaptation and efficient processing of large-scale data.

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

[0005] The main purpose of this application is to provide a method, apparatus, device and product for encrypting and storing sensitive data, which aims to solve the technical problems of existing data encryption technologies having fragmented functions and lacking fault tolerance mechanisms, and being unable to simultaneously guarantee business continuity, query integrity and data security.

[0006] To achieve the above objectives, this application proposes a method for encrypting and storing sensitive data, the method comprising: Configure a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted; An encryption strategy is selected based on the list of fields to be encrypted, and the original SQL query statement is parsed and rewritten according to the encryption strategy to obtain the rewritten SQL statement. Based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, the data of the list of fields to be encrypted is migrated through the encryption lifecycle state machine to obtain the ciphertext fields after migration is completed. The encrypted field is decrypted and de-identified to obtain a de-identified value, and the de-identified value is written into the original field corresponding to the original data field through the encryption strategy to obtain the encrypted storage result.

[0007] In one embodiment, the step of configuring a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted includes: Receive a whitelist configuration instruction, parse the whitelist configuration instruction to obtain the table name to be encrypted and the field name to be encrypted, and generate a whitelist configuration entry based on the table name to be encrypted and the field name to be encrypted. The original data fields are filtered according to the whitelist configuration entries to obtain a list of fields to be encrypted; Periodically allocate the list of fields to be encrypted to obtain the lifecycle status of the list of fields to be encrypted.

[0008] In one embodiment, the step of selecting an encryption strategy based on the list of fields to be encrypted to obtain an encryption strategy includes: Based on the list of fields to be encrypted, read the original field names and final field names of several fields to be encrypted from the encryption configuration table to obtain the field name mapping relationship; Determine whether the original field name and the final field name are the same based on the field name mapping relationship; If they are the same, then the encryption strategy is determined to be a single-field encryption strategy; If they are different, then the encryption strategy is determined to be a two-field encryption strategy.

[0009] In one embodiment, the step of parsing and rewriting the original SQL query statement according to the encryption strategy to obtain the rewritten SQL statement includes: The original SQL query statement is parsed into an abstract syntax tree by the SQL parser, resulting in the syntax tree structure; According to the encryption strategy, the query field nodes and condition expression nodes in the syntax tree structure are traversed to obtain the set of condition nodes to be rewritten. The set of condition nodes to be rewritten is rewritten according to the encryption strategy to obtain the rewritten SQL statement.

[0010] In one embodiment, the step of performing data migration on the list of fields to be encrypted using an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, to obtain the migrated ciphertext fields, includes: The new field corresponding to the original data field is based on the lifecycle status of the list of fields to be encrypted; By using the dual-write mode, new data is written to both the new field and the original field corresponding to the original data field, thus obtaining a dual-write state. Based on the dual-write status and the rewritten SQL statement, the existing data is read through cursor pagination, and the existing data is encrypted and then written into the new field; After the write operation is complete, switch the query status to read new fields to obtain the switched status. When the switching status is "switching complete", the dual-write mode is stopped, and the ciphertext field with the migration completed is obtained.

[0011] In one embodiment, the step of writing new data into both the new field and the original field corresponding to the original data field through a dual-write mode to obtain a dual-write state includes: The newly added data is encrypted to obtain encrypted data, and the execution result of the encryption operation is monitored to obtain encryption status feedback; If the encryption status feedback indicates successful encryption, then the encrypted data is written into the new field, and the plaintext of the newly added data is written into the original field to obtain the writing result; If the encryption status feedback indicates encryption failure, the field that failed to encrypt will be retried for encryption. When the number of retry encryption attempts reaches the retry threshold, the plaintext of the new data will be written into the original field, and the new data will be marked as unencrypted, thus obtaining a downgraded write result. A dual-write status identifier is generated based on the write result or the downgrade write result, and the dual-write status is obtained.

[0012] In one embodiment, the steps of decrypting and de-identifying the ciphertext field to obtain a de-identified value, and writing the de-identified value into the original field corresponding to the original data field using the encryption strategy to obtain the encrypted storage result include: The ciphertext field is read to obtain the corresponding ciphertext data, and the ciphertext data is decrypted using a decryption algorithm to obtain plaintext data; The plaintext data is de-identified to obtain de-identified values; The de-identified value is written into the original field corresponding to the original data field to obtain the encrypted storage result.

[0013] Furthermore, to achieve the above objectives, this application also proposes a sensitive data encryption storage device, which includes: The configuration module is used to configure a whitelist for the raw data fields, and obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted; The rewriting module is used to select an encryption strategy based on the list of fields to be encrypted, obtain an encryption strategy, and perform syntax tree parsing and rewriting on the original SQL query statement according to the encryption strategy to obtain the rewritten SQL statement. The migration module is used to migrate the data of the list of fields to be encrypted through an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, so as to obtain the ciphertext fields after migration is completed. An encryption module is used to decrypt and de-identify the ciphertext field to obtain a de-identified value, and write the de-identified value into the original field corresponding to the original data field through the encryption strategy to obtain an encrypted storage result.

[0014] In addition, to achieve the above objectives, this application also proposes a sensitive data encryption storage 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 sensitive data encryption storage method described above.

[0015] 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 sensitive data encryption storage method described above.

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

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application proposes a method, apparatus, device, and product for encrypting and storing sensitive data. The method involves configuring a whitelist of original data fields to obtain a list of fields to be encrypted and their lifecycle states; selecting an encryption strategy based on the list of fields to be encrypted to obtain an encryption strategy; parsing and rewriting the original SQL query statement using the encryption strategy to obtain a rewritten SQL statement; performing data migration on the list of fields to be encrypted using an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle states of the list of fields to be encrypted to obtain ciphertext fields that have completed the migration; decrypting and desensitizing the ciphertext fields to obtain desensitized values; and writing the desensitized values ​​into the original fields corresponding to the original data fields using the encryption strategy to obtain the encrypted storage result. Therefore, by linking whitelist configuration with encryption strategy selection, flexible adaptation on demand is achieved, breaking the limitations of functional fragmentation. Subsequently, through SQL syntax tree parsing and rewriting, the encrypted fields can still be queried normally, ensuring query integrity. Next, data migration is driven by an encryption lifecycle state machine, providing fault tolerance for the migration process and ensuring business continuity. Finally, by decrypting the ciphertext and writing it back to the original fields, the database layer no longer exposes the real plaintext, fundamentally ensuring data security. This solves the problem that existing data encryption technologies have fragmented functions and lack fault tolerance mechanisms, making it impossible to simultaneously ensure business continuity, query integrity, and data security, and improves the efficiency of encrypted storage of sensitive data. Attached Figure Description

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

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

[0020] Figure 1 This is a flowchart illustrating an embodiment of the sensitive data encryption and storage method of this application. Figure 2 This is a schematic diagram of the overall system architecture involved in the sensitive data encryption and storage method of this application; Figure 3 A schematic diagram illustrating the whitelist configuration involved in the sensitive data encryption and storage method of this application; Figure 4 The diagram illustrates the method for encrypting and storing sensitive data in this application, which involves encryption using a whitelist. Figure 5This is a flowchart illustrating Embodiment 2 of the method for encrypting and storing sensitive data in this application. Figure 6 This diagram illustrates the encryption lifecycle states involved in the sensitive data encryption storage method of this application. Figure 7 A schematic diagram illustrating the five-stage encryption involved in the sensitive data encryption storage method of this application; Figure 8 A simplified flowchart illustrating the sensitive data encryption and storage method provided in Embodiment 2 of this application; Figure 9 This is a schematic diagram of the module structure of the sensitive data encryption storage device according to an embodiment of this application; Figure 10 This is a schematic diagram of the device structure of the hardware operating environment involved in the sensitive data encryption and storage method in the embodiments of this application.

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

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

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

[0024] The main solution of this application embodiment is as follows: receiving a whitelist configuration instruction, parsing the whitelist configuration instruction to obtain the table name to be encrypted and the field name to be encrypted, and generating whitelist configuration entries based on the table name to be encrypted and the field name to be encrypted; filtering the original data fields according to the whitelist configuration entries to obtain a list of fields to be encrypted; periodically allocating the list of fields to be encrypted to obtain the lifecycle status of the list of fields to be encrypted. The original SQL query statement is parsed into an abstract syntax tree by an SQL parser to obtain a syntax tree structure; the query field nodes and condition expression nodes in the syntax tree structure are traversed according to the encryption strategy to obtain a set of condition nodes to be rewritten; the set of condition nodes to be rewritten is rewritten according to the encryption strategy to obtain the rewritten SQL statement. Based on the lifecycle status of the list of fields to be encrypted, a new field corresponding to the original data field is obtained; new data is written to the new field and the original field corresponding to the original data field through a dual-write mode, resulting in a dual-write state; according to the dual-write state and the rewritten SQL statement, existing data is read through cursor pagination, and the existing data is encrypted and written to the new field; after writing is completed, the query state is switched to read the new field, resulting in a switching state; when the switching state is complete, the dual-write mode is stopped, and the ciphertext field with migration completed is obtained. The newly added data is encrypted to obtain encrypted data, and the execution result of the encryption operation is monitored to obtain encryption status feedback. If the encryption status feedback indicates successful encryption, the encrypted data is written to the new field, and the plaintext of the newly added data is written to the original field to obtain a writing result. If the encryption status feedback indicates encryption failure, the field that failed to encrypt is retried for encryption. When the number of retry attempts reaches the retry threshold, the plaintext of the newly added data is written to the original field, and the newly added data is marked as unencrypted to obtain a downgraded writing result. A double-write status identifier is generated based on the writing result or the downgraded writing result to obtain a double-write status. The ciphertext field is read to obtain the corresponding ciphertext data, and the ciphertext data is decrypted using a decryption algorithm to obtain plaintext data. The plaintext data is desensitized to obtain a desensitized value. The desensitized value is written to the original field corresponding to the original data field to obtain an encrypted storage result. This solves the problem that existing data encryption technologies are fragmented in function and lack fault tolerance mechanisms, making it impossible to simultaneously guarantee business continuity, query integrity, and data security. It enables encrypted storage of sensitive data and improves the efficiency of encrypted storage of sensitive data.Based on the solution of this invention, addressing the real-world lack of a unified fault tolerance and retry mechanism, and the inability to accommodate mixed queries after encryption failures, which makes it difficult to simultaneously guarantee business continuity, query integrity, and data security during gray-scale releases and data migrations, especially failing to meet the core requirements of high-reliability scenarios such as finance for smooth migration without downtime, flexible strategy adaptation, and efficient processing of large-scale data, thus resulting in low efficiency, this invention designs a sensitive data encryption storage method. The effectiveness of the sensitive data encryption storage method of this invention is verified when encrypting and storing sensitive data. Finally, the efficiency of sensitive data encryption storage using the method of this invention is significantly improved.

[0025] In this embodiment, for ease of description, the following description uses a sensitive data encryption storage device as the execution subject.

[0026] Due to the limitations of existing sensitive data encryption storage technologies, the efficiency of sensitive data encryption storage needs to be improved. One issue is functional fragmentation, where different stages are implemented using various technologies such as application-layer calls, database functions, blind indexes, and dual writes, lacking unified coordination. This leads to increased complexity and decreased efficiency in sensitive data encryption storage. Another issue is the lack of fault tolerance mechanisms. After encryption failure, mixed queries cannot be compatible, and there are no retry or degradation strategies, which can compromise business continuity and query integrity. Furthermore, there is the issue of rigid strategies. Different business scenarios often share the same encryption logic, making it difficult to flexibly adapt to diverse needs. This also affects the applicability and efficiency of sensitive data encryption storage. Therefore, current sensitive data encryption storage also faces challenges in ensuring business continuity. Since high-reliability scenarios such as finance have strict requirements for smooth migration without downtime, flexible strategy adaptation, and efficient processing of large-scale data, efficiency will decrease if existing technologies lack unified fault tolerance mechanisms and adaptive strategies.

[0027] This application provides a solution that achieves flexible on-demand adaptation by linking whitelist configuration with encryption strategy selection, breaking the limitations of functional fragmentation. Subsequently, through SQL syntax tree parsing and rewriting, the encrypted fields can still be queried normally, ensuring query integrity. Next, data migration is driven by an encryption lifecycle state machine, providing fault tolerance for the migration process and ensuring business continuity. Finally, by decrypting the ciphertext and writing it back to the original fields, the database layer no longer exposes the real plaintext, fundamentally ensuring data security. This solves the problems of existing data encryption technologies having fragmented functions and lacking fault tolerance mechanisms, which cannot simultaneously guarantee business continuity, query integrity, and data security, and improves the efficiency of encrypted storage of sensitive data.

[0028] Based on this, embodiments of this application provide a method for encrypting and storing sensitive data, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the sensitive data encryption and storage method of this application.

[0029] In this embodiment, the sensitive data encryption and storage method includes steps S01 to S04: Step S01: Configure a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted. Before the implementation of this embodiment, it should be clear that the existing technical solutions are functionally fragmented, lack a unified fault tolerance and retry mechanism, and cannot be compatible with mixed queries after encryption failure. As a result, during gray-scale releases, data migrations, and other processes, it is difficult to ensure business continuity, query integrity, and data security at the same time. In particular, it cannot meet the core requirements of high-reliability scenarios such as finance for smooth migration without downtime, flexible strategy adaptation, and efficient processing of large-scale data.

[0030] Therefore, in order to solve the above problems, this embodiment adopts the following... Figure 2 The overall architecture shown adopts a non-intrusive transparent encryption architecture, relying on the MyBatis-Plus interceptor, configuration center, state machine management, and batch data processing service to work together. The overall architecture includes an SQL syntax tree rewriting interception module, an adaptive encryption strategy module, an encryption lifecycle state machine module, a data processing and desensitization execution module, a whitelist fine-grained control module, and a visualization monitoring module. Each module is decoupled from each other and works together.

[0031] The architecture is divided into a front-end interaction layer, a business logic layer, an encryption processing layer, and a data storage layer from top to bottom. The front-end is only responsible for routine business operations and does not need to be aware of the encryption logic. The business layer relies on the configuration center to dynamically load whitelists and encryption policies. The encryption processing layer completes the entire process of SQL rewriting, encryption and decryption, data migration, and de-identification. The storage layer distinguishes between plaintext, ciphertext, and de-identified data for layered storage. At the same time, it combines the national cryptographic SM4 encryption algorithm, the TypeHandler automatic encryption and decryption mechanism, and the batch concurrent processing mechanism to achieve full lifecycle encrypted storage management of financial-grade sensitive data. No business code needs to be modified throughout the process, which is perfectly adapted to 24 / 7 uninterrupted business operation scenarios.

[0032] During system operation, the system first receives the whitelist operation instructions configured in the background, automatically parses the preset database table information and field information in the instructions, filters out the original sensitive data fields in the system that need to be encrypted and controlled, removes system configuration tables, non-sensitive business fields and other content that does not need to be encrypted, and finally summarizes them into a standardized list of fields to be encrypted.

[0033] At the same time, by combining business migration planning, data security level, and canary release rhythm, a corresponding life cycle running state is independently assigned to each field to be encrypted, providing basic data support for subsequent differentiated encryption, smooth data migration, and state flow management.

[0034] Step S02: Select an encryption strategy based on the list of fields to be encrypted to obtain an encryption strategy, and perform syntax tree parsing and rewriting on the original SQL query statement according to the encryption strategy to obtain the rewritten SQL statement. Based on the generated list of fields to be encrypted, the field mapping data stored in the backend encryption configuration table is retrieved, and the original name of the corresponding field is matched with the final name of the encrypted storage. The single-field or dual-field encryption storage scheme is automatically determined based on whether the field names are consistent.

[0035] After determining the storage scheme, the original SQL query statements executed by the business system are intercepted. The statements are then broken down into standardized abstract syntax trees using professional SQL parsing tools. The query field nodes and condition operation nodes in the syntax tree are traversed layer by layer to accurately locate the syntax nodes of all related sensitive fields. The syntax nodes are rewritten and reconstructed according to the corresponding encryption strategy to output new SQL statements that are adapted to encrypted queries and compatible with mixed plaintext scenarios, ensuring seamless connection of business query logic before and after encryption.

[0036] Step S03: Based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, perform data migration on the list of fields to be encrypted through the encryption lifecycle state machine to obtain the ciphertext fields after migration is completed. Based on the preset field lifecycle states and the rewritten standard SQL statements, the full data migration is driven by a self-developed five-stage encrypted lifecycle state machine.

[0037] First, create a new encrypted field based on the field status, then enable the dual-write operation mode of the old and new fields to process new business data and existing system data simultaneously.

[0038] For hundreds of millions of existing data, the traditional LIMIT OFFSET pagination method is abandoned. Instead, a primary key cursor pagination mechanism is used to read data in batches with precision. The read plaintext data is then encrypted and written into a new field.

[0039] After the full migration and encryption of existing data is completed, the database query data source is automatically switched to the new encrypted field. After verifying data integrity and business stability, the dual-write mode is turned off, and finally the encrypted migration of all fields to be encrypted is completed, realizing the encrypted storage of all sensitive data.

[0040] Step S04: Decrypt and de-identify the ciphertext field to obtain a de-identified value, and write the de-identified value into the original field corresponding to the original data field through the encryption strategy to obtain the encrypted storage result.

[0041] After the data migration is completed, the system reads the encrypted data stored in the new field of the database in batches, and decrypts the encrypted data using the preset national cryptographic SM4 decryption algorithm to restore the complete plaintext sensitive data.

[0042] For the decrypted plaintext data, irreversible desensitization processing is performed at the storage layer. The conventional desensitization rule is to retain the first character and replace the remaining characters with asterisks to generate compliant desensitized values.

[0043] Finally, the processed desensitized values ​​are written back to the original data fields in batches, completely replacing the original plaintext data in the database. This ensures that only the desensitized data and encrypted ciphertext are stored at the database level, with no original plaintext remaining. This builds a strong data security defense line from the storage layer and completes the entire closed-loop process of encrypted storage of sensitive data.

[0044] By linking whitelist configuration with encryption strategy selection, flexible adaptation on demand is achieved, breaking the limitations of functional fragmentation. Subsequently, through SQL syntax tree parsing and rewriting, the encrypted fields can still be queried normally, ensuring query integrity. Next, data migration is driven by an encryption lifecycle state machine, providing fault tolerance for the migration process and ensuring business continuity. Finally, by decrypting the ciphertext and writing it back to the original fields, the database layer no longer exposes the real plaintext, fundamentally ensuring data security.

[0045] Specifically, step S01 above, which involves configuring a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted, includes: Step S011: Receive whitelist configuration instruction, parse the whitelist configuration instruction to obtain the table name to be encrypted and the field name to be encrypted, and generate whitelist configuration entries based on the table name to be encrypted and the field name to be encrypted. Step S012: Filter the original data fields according to the whitelist configuration entries to obtain a list of fields to be encrypted; Step S013: Periodically allocate the list of fields to be encrypted to obtain the lifecycle status of the list of fields to be encrypted.

[0046] The complete implementation logic of whitelist configuration is as follows: Figure 3 As shown, it operates using a standardized process of "command parsing - entry generation - field filtering - status assignment", supports dynamic updates of the configuration center, and takes effect without restarting the application.

[0047] The system monitors whitelist configuration commands pushed by the backend operations and maintenance terminal in real time, accurately parses the core configuration information contained in the commands, such as the target database table name, specific sensitive field names, encryption priority, and grayscale range. Based on the parsed table name and field name, it generates a unique whitelist configuration entry. Each entry is independently bound to a single data table field, achieving fine-grained control at the field level. After generating the configuration entries, the system traverses all original data fields in the business database, comparing and matching the original database field information with the whitelist entries one by one. It accurately filters out all sensitive fields that need to be included in encryption control, automatically filters basic system configuration fields, non-sensitive business fields, and deprecated or invalid fields, and summarizes them to generate a structured, batch-manageable list of fields to be encrypted.

[0048] After completing the field filtering, based on the financial business canary release requirements, data migration progress, and business security level, each sensitive field in the list is independently assigned an initial lifecycle state, which is initialized to state N by default. At the same time, the corresponding tenant canary permissions, encryption priority, retry strategy, and batch processing parameters are bound, providing precise field-dimensional configuration support for subsequent full-process encryption control, state transition, and fault tolerance processing, and completely solving the shortcomings of traditional solutions that have global unified configuration and cannot be finely controlled.

[0049] More specifically, step S02 above, which involves selecting an encryption strategy based on the list of fields to be encrypted, includes the following steps: Step S021: Based on the list of fields to be encrypted, read the original field names and final field names of several fields to be encrypted in the encryption configuration table to obtain the field name mapping relationship; Step S022: Determine whether the original field name and the final field name are the same based on the field name mapping relationship; Step S023: If they are the same, then the encryption strategy is determined to be a single-field encryption strategy; Step S024: If they are not the same, then the encryption strategy is determined to be a two-field encryption strategy.

[0050] The entire process of adaptive selection of encryption strategies is fully automated, requiring no manual intervention for strategy switching, and can accurately adapt to the differentiated security and performance requirements of different business scenarios.

[0051] After the system loads the filtered list of fields to be encrypted, it actively reads the field configuration data pre-entered in the encryption configuration table, accurately matches the original field name old_field_name and the final stored field name new_field_name corresponding to each sensitive field, constructs a complete field name mapping relationship, and clarifies the corresponding association logic between the old and new fields.

[0052] The system automatically compares the consistency of the two field names based on this mapping relationship, using this as the core basis for policy determination. No additional policy identifier configuration is required, making the configuration simple and less prone to errors.

[0053] When the original field name and the final field name are exactly the same, the system automatically determines that the single-field encryption strategy is suitable and directly overwrites the encrypted ciphertext in the original field without adding a new database field. This saves database storage resources to the greatest extent and reduces system operation and maintenance costs. This strategy is mainly suitable for business scenarios that do not require ciphertext query and are sensitive to storage costs, such as log statistics and report display.

[0054] When the original field name and the final field name are inconsistent, the system automatically adapts to the dual-field encryption strategy. The original field is retained to store plaintext data during the transition period and the final de-identified data. At the same time, a dedicated field is created to store the encrypted ciphertext. Through the dual-field separate storage mode, smooth data migration and query capability compatibility are achieved. This strategy is mainly adapted to financial business scenarios with extremely high requirements for business continuity, data query integrity and security, such as core fund transactions and user core information storage, achieving a balance between security and business availability.

[0055] Further, step S02 above, which involves parsing and rewriting the original SQL query statement according to the encryption strategy to obtain the rewritten SQL statement, includes: Step S025: The original SQL query statement is parsed into an abstract syntax tree by the SQL parser to obtain the syntax tree structure; Step S026: Traverse the query field nodes and condition expression nodes in the syntax tree structure according to the encryption strategy to obtain a set of condition nodes to be rewritten. Step S027: Rewrite the set of condition nodes to be rewritten according to the encryption strategy to obtain the rewritten SQL statement.

[0056] In this embodiment, the SQL syntax tree parsing and statement rewriting are implemented entirely through the MyBatis-Plus interceptor mechanism, which is completely non-intrusive to business code and adapts to all database operation statements executed through MyBatis, with wide coverage and strong compatibility.

[0057] Interception is performed before the SQL statement is executed. A pre-verification process is first executed, including: filtering special data tables that do not require encryption, such as system configuration tables, and directly allowing the corresponding SQL statement to be executed. At the same time, the validity of the current user session context is verified to ensure that the encryption operation is executed within a valid business session.

[0058] After successful verification, it is determined whether the current SQL matches the encrypted table list, and the corresponding set of fields to be encrypted is filtered out. Then, the JSQLParser parsing tool is called to decompose the complete original SQL statement into a standardized abstract syntax tree, and a clear syntax tree hierarchical structure is sorted out to accurately distinguish various syntax units such as query field nodes, condition expression nodes, logical operation nodes, and nested parentheses nodes.

[0059] Subsequently, based on the established single / double field encryption storage scheme, a full recursive traversal of the syntax tree structure is performed to accurately locate all query nodes and condition operation nodes associated with sensitive fields to be encrypted, and to summarize them into a complete set of condition nodes to be rewritten. The traversal process supports a maximum recursion depth of 50 levels, which can effectively avoid stack overflow problems caused by malicious SQL statements and ensure the stability of system operation.

[0060] For the nodes to be rewritten in the summary, the system performs differentiated syntax rewriting operations. For SELECT query field nodes, the original sensitive fields are replaced with encrypted new fields, and the original field aliases are bound to ensure that the business field mapping remains unchanged.

[0061] For the WHERE condition node, various expressions are processed differently. Equality conditions are rewritten as OR combinations of plaintext and ciphertext, and IN multi-value conditions are decomposed into multiple sets of nested OR conditions. Complex nested expressions such as AND, OR, parentheses, and NOT are recursively processed to ensure that the rewritten SQL statement can be compatible with both plaintext and ciphertext mixed data queries. This completely solves the problems of missing data queries and query failures during the encryption transition period, and finally generates a brand-new executable SQL statement with standard syntax, complete logic, and adaptability to encryption scenarios.

[0062] The overall encryption implementation process combined with the whitelist mechanism is as follows: Figure 4 As shown, the entire process achieves "controllable configuration, adaptive strategy, standardized process, and traceable status" field-level encryption control, perfectly adapting to the uninterrupted business scenarios of financial systems.

[0063] After the system starts the encryption process, it first relies on the whitelist mechanism of tables and fields to complete the permission and status verification. Encryption is only performed on fields that are in the whitelist and are in an encryptable state. Regular business fields outside the whitelist are allowed to pass directly without any encryption processing to avoid invalid calculations.

[0064] At the same time, it combines the real-time lifecycle status of fields to achieve fine-grained management. For fields in the N, OLD initialization and dual-write transition period, only data synchronization and preprocessing operations are performed, and formal encryption and de-identification writing are not performed. For fields in the NEW, Y, and B states, encryption migration, de-identification write-back, and rollback repair operations are performed normally.

[0065] After the whitelist verification is passed, the system automatically matches the encryption strategy of the corresponding field, distinguishes between single-field and dual-field scenarios to start a differentiated encryption process, and synchronously completes the adaptive rewriting of SQL statements to ensure that business queries are not affected by encryption operations.

[0066] During the data writing phase, automatic encryption and decryption are achieved using the MyBatis TypeHandler mechanism. The system is configured with two types of dedicated processors to adapt to different scenarios: (1) DecryptSensitiveHandler is used for regular business query scenarios. It automatically decrypts the ciphertext fields in the query results into plaintext and returns them to the business layer.

[0067] (2) DecryptAndEncryptSensitiveHandler is used for batch data processing scenarios. While reading and decrypting data, it automatically encrypts the data being written. All encrypted ciphertext is marked with the unified prefix ENC_. The system can accurately identify the encryption status of fields through this prefix. When encrypting existing data, only plaintext data that does not start with ENC_ is encrypted to avoid duplicate encryption. When querying and rewriting, plaintext and ciphertext are distinguished by prefix identification to ensure the accuracy of mixed query logic. When desensitizing data, only encrypted data with the ENC_ prefix is ​​decrypted and desensitized to avoid invalid calculations. At the same time, the configuration center supports dynamic modification of whitelist status, encryption strategy, batch parameters, and retry threshold at runtime. It takes effect in real time without restarting the application and can flexibly adapt to tenant-level gray release requirements to achieve gradual switching of core transaction business, avoid system stability risks brought about by overall upgrades, and ensure that the entire process is seamless, without downtime or data loss.

[0068] This embodiment, through the above scheme, specifically obtains a list of fields to be encrypted and their lifecycle states by configuring a whitelist of the original data fields; selects an encryption strategy based on the list of fields to be encrypted to obtain an encryption strategy; and performs syntax tree parsing and rewriting on the original SQL query statement according to the encryption strategy to obtain a rewritten SQL statement; performs data migration on the list of fields to be encrypted through an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle states of the list of fields to be encrypted to obtain a ciphertext field after migration; decrypts and de-identifies the ciphertext field to obtain a de-identified value; and writes the de-identified value into the original field corresponding to the original data field according to the encryption strategy to obtain an encrypted storage result. Therefore, by linking whitelist configuration with encryption strategy selection, flexible adaptation on demand is achieved, breaking the limitations of functional fragmentation. Subsequently, through SQL syntax tree parsing and rewriting, the encrypted fields can still be queried normally, ensuring query integrity. Next, data migration is driven by an encryption lifecycle state machine, providing fault tolerance for the migration process and ensuring business continuity. Finally, by decrypting the ciphertext and writing it back to the original fields, the database layer no longer exposes the real plaintext, fundamentally ensuring data security. This solves the problem that existing data encryption technologies have fragmented functions and lack fault tolerance mechanisms, making it impossible to simultaneously ensure business continuity, query integrity, and data security, and improves the efficiency of encrypted storage of sensitive data.

[0069] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 In step S03, the sensitive data encryption storage method further includes steps S031-S035: Based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, the method performs data migration on the list of fields to be encrypted using an encryption lifecycle state machine to obtain the migrated ciphertext fields. Step S031: Based on the lifecycle status of the list of fields to be encrypted, a new field corresponding to the original data field is obtained; Step S032: Write the new data into the new field and the original field corresponding to the original data field in the dual-write mode to obtain the dual-write state; Step S033: Based on the dual-write state and the rewritten SQL statement, read the existing data through cursor pagination, encrypt the existing data, and write it into the new field. Step S034: After writing is complete, switch the query status to read new fields to obtain the switched status; Step S035: When the switching state is "switching complete", stop the dual-write mode and obtain the ciphertext field after migration is complete.

[0070] The complete data migration process throughout the entire lifecycle relies on a five-stage state machine, combined with cursor pagination batch processing and multi-threaded concurrency mechanisms to achieve efficient and smooth migration of hundreds of millions of existing data, without any downtime and supporting fault tolerance and safe rollback.

[0071] Based on the current lifecycle status of each field, an encrypted new field matching the original field attributes is automatically created in the database. After the field initialization is completed, the dual-write operation mode of the old and new fields is immediately started. All new business data will be synchronously written to the original field and the new field to ensure bidirectional data synchronization during the transition period.

[0072] After the dual-write mode is running stably, the system reads the existing data in batches according to the rewritten SQL statement using the primary key cursor pagination mechanism. This eliminates the performance defects of traditional LIMIT OFFSET pagination, accurately locates data batches through primary key comparison, and achieves no performance degradation in deep pagination scenarios. It also supports composite primary keys to adapt to various complex data tables.

[0073] For each batch of existing plaintext data read, the system calls the national cryptographic SM4 encryption algorithm to complete the encryption process, generating standard ciphertext data with the ENC_ identifier, and then writes it in batches to the corresponding new fields. For ultra-large table partitioning scenarios such as detailed tables for agency inventions, the system automatically traverses all enterprise partitions with suffixes 00-99, independently enables dedicated data processing services, achieves accurate migration of partitioned data, and avoids congestion in large table data processing.

[0074] After the full data migration is completed, the system automatically switches the database query data source, changing the business query logic from reading the original plaintext fields to reading the new encrypted fields, and completing the query status switch verification.

[0075] After confirming that the switching state is completely stable, the data query is complete, and the business operation is normal, the system automatically shuts down the dual-write operation mode, terminates the synchronization logic of the old and new fields, and finally completes the ciphertext migration of all fields to be encrypted, obtaining complete and stable ciphertext field data.

[0076] The entire migration process adopts the UPDATE JOIN batch update strategy, and uses UNION ALL to construct virtual tables to achieve single SQL batch updates, which greatly reduces the number of database interactions. At the same time, it sets a single batch processing volume of 200 rows and 10 threads to execute concurrently. CountDownLatch is used to implement batch synchronization control to avoid database connection exhaustion and greatly improve the efficiency of large-scale data migration.

[0077] Specifically, step S032 above, which involves writing the new data into both the new field and the original field corresponding to the original data field in a dual-write mode to obtain the dual-write state, includes: Step S0321: Encrypt the newly added data to obtain encrypted data, and monitor the execution result of the encryption operation to obtain encryption status feedback; Step S0322: If the encryption status feedback indicates successful encryption, then the encrypted data is written into the new field, and the plaintext of the newly added data is written into the original field to obtain the writing result; Step S0323: If the encryption status feedback indicates encryption failure, then the field that failed to encrypt is retried for encryption. When the number of retry encryption attempts reaches the retry threshold, the plaintext of the new data is written into the original field, and the new data is marked as unencrypted, thus obtaining the downgraded writing result. Step S0324: If the encryption status feedback indicates encryption failure, then the field that failed to encrypt is retried for encryption. When the number of retry encryption attempts reaches the retry threshold, the plaintext of the new data is written into the original field, and the new data is marked as unencrypted, thus obtaining the downgraded writing result. The dual-write mode operates with a complete encryption fault tolerance, retry and degradation mechanism, which can completely solve the problems of data loss and business interruption caused by encryption failure, and ensure the data integrity of high-reliability financial transaction scenarios.

[0078] The system automatically performs encryption operations on all newly written data for all business operations, monitors the execution results of each encryption operation in real time, and generates accurate encryption status feedback data.

[0079] When the encryption operation is successfully executed and the ciphertext is generated and valid, the system will accurately write the encrypted ciphertext data with the ENC_ prefix into the new encrypted field, and at the same time write the original plaintext data into the original field of the database, completing the synchronous retention of dual-field data during the transition period, ensuring query compatibility and data integrity.

[0080] When an encryption operation fails or ciphertext generation fails, the system immediately initiates an automatic retry mechanism, repeatedly performs encryption operations, and counts the number of retries in real time. When the number of retries reaches the system's preset threshold, the retry process is terminated, and a downgraded write strategy is triggered.

[0081] In the downgraded state, the system directly writes the original plaintext of the newly added data into the original field, and at the same time marks the abnormal data as unencrypted, which facilitates subsequent batch screening and re-encryption, avoiding the problem of data not being able to be stored or transaction interruption caused by encryption anomalies.

[0082] Based on the success, failure, and degradation processing results of each data write, a corresponding dual-write status identifier is automatically generated, and the dual-write running status of the field is updated in real time. This provides accurate status basis for subsequent state machine transitions, data verification, and gray-scale switching, ensuring continuous business operation and zero data loss throughout the process.

[0083] This embodiment also includes an AtomicBoolean failure marking mechanism. If any batch of data processing fails, the overall task status is immediately marked, and subsequent invalid processing is interrupted in time to avoid batch data anomalies. The task execution time window can be set through the configuration center to avoid peak business periods and ensure the overall stability of the system.

[0084] Each encryption configuration item has an independent function switch, which is off by default. In production environments, it needs to be manually configured to be turned on, so as to avoid accidental triggering of unexpected data encryption and desensitization processes from the configuration level.

[0085] Further, step S04 above, which involves decrypting and desensitizing the ciphertext field to obtain a desensitized value, and then writing the desensitized value into the original field corresponding to the original data field using the encryption strategy to obtain the encrypted storage result, includes: Step S041: Read the ciphertext field to obtain the corresponding ciphertext data, and decrypt the ciphertext data using a decryption algorithm to obtain plaintext data; Step S042: De-identify the plaintext data to obtain a de-identified value; Step S043: Write the desensitized value into the original field corresponding to the original data field to obtain the encrypted storage result.

[0086] After all sensitive data has been encrypted and migrated and stably stored in the new encrypted fields, the system automatically initiates a deep desensitization and data write-back process at the storage layer to complete the security purification of the original fields and eliminate the risk of plaintext leakage from the database.

[0087] Prioritize traversing all migrated ciphertext fields, batch read ciphertext data carrying the ENC_ standard prefix within the fields, accurately identify valid encrypted data, and avoid misprocessing of unencrypted plaintext data.

[0088] For the compliant encrypted data that is read, the national cryptographic SM4 decryption algorithm paired with the encryption algorithm is called to perform batch decryption operations, stripping the encrypted identifier and encryption key, accurately restoring the complete and true plaintext content of sensitive data, ensuring that the decrypted data is completely consistent with the original business data, with no data loss or content tampering.

[0089] After the plaintext is restored, the system performs irreversible standardized desensitization processing. For different types of financial sensitive data such as mobile phone numbers, ID card numbers, bank card numbers, and customer names, a unified and compliant desensitization rule is adopted. The key first and last identification characters of the fields are retained, and all other privacy characters are replaced with asterisks as placeholders. Irreversible and unrecoverable compliant desensitized values ​​are generated to eliminate the risk of privacy information leakage.

[0090] The entire desensitization process is completed at the server-side storage layer, which differs from traditional front-end presentation layer desensitization and can eliminate the risk of plaintext storage from the database layer.

[0091] After generating compliant de-identified values, the system uses a batch update mechanism to write the de-identified values ​​back to the corresponding original data fields one by one, completely replacing the original plaintext data in the database. This ultimately achieves a two-layer secure storage structure where the original fields only retain de-identified data and the newly added fields retain encrypted ciphertext, forming a complete closed-loop encrypted storage result for sensitive data. This ensures both business display and query needs and achieves financial-grade data security compliance protection.

[0092] The complete state system of the cryptographic lifecycle of this application is as follows: Figure 6 , Figure 7 As shown, a five-stage state machine (N, OLD, NEW, Y, B) is used to achieve closed-loop management of the entire lifecycle of sensitive fields. Each state has a clear responsibility and a clear flow logic, supporting smooth migration without downtime and safe rollback in case of anomalies, and is suitable for 24 / 7 uninterrupted business scenarios in the financial industry.

[0093] The initial state N is uninitialized. At this time, the system has only completed the whitelist configuration, has not created any new encrypted fields, and has not started any encryption process. When the system has created the new encrypted fields and is ready to start data synchronization, the state changes from N to OLD, and officially enters the dual-write transition period. During this stage, the new and old fields are written to the data synchronously, and business queries are compatible with plaintext and ciphertext.

[0094] Once the full database data encryption migration is complete and the data verification is successful, the status changes from OLD to NEW, and the system query logic officially switches to reading the encrypted data of the new field, completing the core steps of the encryption migration.

[0095] Once the NEW state is running stably and there is no abnormal data, the state transitions to Y, indicating that the entire encrypted migration process is completely completed. The system stops the dual-write mode, retains only the encrypted storage of the new fields, and simultaneously starts the deep desensitization process of the storage layer to perform irreversible desensitization and write-back on the original fields.

[0096] If data anomalies, business failures, or configuration errors occur during any phase of operation, the system can manually or automatically trigger a state transition to rollback processing state B, entering secure rollback mode. In state B, the system suspends all encryption and desensitization operations, decrypts the ciphertext of the new field to restore it to plaintext, and rewrites it back to the original field to complete data repair. After the rollback process ends and the data stabilizes, the state automatically returns to OLD dual-write state, ensuring that the system can restart the encryption migration process.

[0097] The entire state transition mechanism has no downtime, and abnormal scenarios can be accurately rolled back with zero data loss, completely solving the shortcomings of traditional encrypted migration solutions such as inability to roll back, downtime for maintenance, and high data risk.

[0098] In addition, this embodiment is also equipped with a visual monitoring module, which displays the progress of the entire encrypted data migration process through a dedicated visual menu. It presents the lifecycle status of each field, the proportion of existing data migration, the progress of data anonymization, the number of abnormal data entries, and other core indicators in real time. Operation and maintenance personnel can intuitively grasp the overall progress of the encrypted migration, promptly discover and locate abnormal issues, and further improve the operation and maintenance management efficiency of large-scale data encryption migration.

[0099] This embodiment, through the above scheme, specifically uses a new field corresponding to the original data field based on the lifecycle state of the list of fields to be encrypted; it writes the new data into the new field and the original field corresponding to the original data field using a dual-write mode, thus obtaining a dual-write state; based on the dual-write state and the rewritten SQL statement, it reads the existing data through cursor pagination, encrypts the existing data, and writes it into the new field; after the writing is completed, it switches the query state to read the new field, thus obtaining a switching state; when the switching state is complete, it stops the dual-write mode, thus obtaining the ciphertext field after migration is complete. Therefore, by linking whitelist configuration with encryption strategy selection, flexible adaptation on demand is achieved, breaking the limitations of functional fragmentation. Subsequently, through SQL syntax tree parsing and rewriting, the encrypted fields can still be queried normally, ensuring query integrity. Next, data migration is driven by an encryption lifecycle state machine, providing fault tolerance for the migration process and ensuring business continuity. Finally, by decrypting the ciphertext and writing it back to the original fields, the database layer no longer exposes the real plaintext, fundamentally ensuring data security. This solves the problem that existing data encryption technologies have fragmented functions and lack fault tolerance mechanisms, making it impossible to simultaneously ensure business continuity, query integrity, and data security, and improves the efficiency of encrypted storage of sensitive data.

[0100] For example, to help understand the implementation process of the sensitive data encryption and storage method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 8 , Figure 8A simplified flowchart of a method for encrypting and storing sensitive data is provided, specifically: This embodiment integrates the entire chain of capabilities, including configuration, strategy, rewriting, migration, desensitization, and fault tolerance, to form a standardized, highly reliable, and implementable encrypted storage closed-loop process.

[0101] After the system starts up, it first completes the filtering of sensitive fields and the initialization of lifecycle status through the whitelist fine-grained configuration function, accurately locking the target fields that need to be encrypted and controlled, and achieving precise field-level control.

[0102] The system then automatically reads the configuration parameters, adaptively matches the single-field or double-field encryption strategy, and synchronously triggers SQL syntax tree parsing and intelligent rewriting to complete the encryption adaptation of business query statements, ensuring that the encrypted business query function is fully available.

[0103] After the strategy and SQL are adapted, the entire data processing is driven by a five-stage lifecycle state machine. Operations such as new field creation, dual-write data synchronization, cursor pagination existing data encryption migration, query state switching, and dual-write mode shutdown are completed in sequence to achieve full data encrypted migration.

[0104] After the migration is completed, the system automatically performs encrypted decryption, irreversible desensitization, and original field write-back operations to complete deep desensitization of the storage layer and eliminate the risk of plaintext leakage in the database.

[0105] The entire operation process is fully automated, equipped with encrypted retry, degradation fault tolerance, anomaly rollback, concurrency control, and batch management mechanisms. It also supports tenant-level canary release, dynamic configuration updates, and visualized monitoring of migration progress. It can efficiently process hundreds of millions of existing data, fully meeting the core requirements of the financial industry for national cryptographic compliance, non-stop migration, high security, and high availability. It completely solves the various defects of traditional technical solutions, such as fragmented functions, lack of fault tolerance, poor query compatibility, high transformation costs, and high migration risks.

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

[0107] This application also provides a sensitive data encryption storage device; please refer to [reference needed]. Figure 9 The sensitive data encryption storage device includes: Configuration module 10 is used to configure a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted. The rewriting module 20 is used to select an encryption strategy based on the list of fields to be encrypted, obtain an encryption strategy, and perform syntax tree parsing and rewriting on the original SQL query statement according to the encryption strategy to obtain a rewritten SQL statement. The migration module 30 is used to migrate the data of the list of fields to be encrypted through an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, so as to obtain the ciphertext fields after migration is completed. The encryption module 40 is used to decrypt and de-identify the ciphertext field to obtain a de-identified value, and write the de-identified value into the original field corresponding to the original data field through the encryption strategy to obtain an encrypted storage result.

[0108] The sensitive data encryption storage device provided in this application, employing the sensitive data encryption storage method in the above embodiments, can solve the technical problems of existing data encryption technologies being functionally fragmented and lacking fault tolerance mechanisms, thus failing to simultaneously guarantee business continuity, query integrity, and data security. Compared with the prior art, the beneficial effects of the sensitive data encryption storage device provided in this application are the same as those of the sensitive data encryption storage method provided in the above embodiments, and other technical features in the sensitive data encryption storage device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0109] This application provides a sensitive data encryption storage 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, and the instructions are executed by the at least one processor to enable the at least one processor to perform the sensitive data encryption storage method in the first embodiment described above.

[0110] The following is for reference. Figure 10 This document illustrates a structural diagram of a sensitive data encryption storage device suitable for implementing embodiments of this application. The sensitive data encryption storage 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 sensitive data encryption storage 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.

[0111] like Figure 10 As shown, the sensitive data encryption storage 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 the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the sensitive data encryption storage device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the sensitive data encryption storage device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show sensitive data encryption storage 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.

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

[0113] The sensitive data encryption storage device provided in this application, employing the sensitive data encryption storage method in the above embodiments, can solve the technical problems of existing data encryption technologies being functionally fragmented and lacking fault tolerance mechanisms, thus failing to simultaneously guarantee business continuity, query integrity, and data security. Compared with the prior art, the beneficial effects of the sensitive data encryption storage device provided in this application are the same as those of the sensitive data encryption storage method provided in the above embodiments, and other technical features in this sensitive data encryption storage device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0116] 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 sensitive data encryption storage method in the above embodiments.

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

[0118] The aforementioned computer-readable storage medium may be included in a sensitive data encryption storage device; or it may exist independently and not assembled into a sensitive data encryption storage device.

[0119] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the sensitive data encryption storage device, the sensitive data encryption storage device performs the following actions: Configures a whitelist for the original data fields to obtain a list of fields to be encrypted and their lifecycle states; selects an encryption strategy based on the list of fields to be encrypted to obtain an encryption strategy; performs syntax tree parsing and rewrites the original SQL query statement according to the encryption strategy to obtain a rewritten SQL statement; performs data migration on the list of fields to be encrypted using an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle states of the list of fields to be encrypted to obtain a migrated ciphertext field; decrypts and de-identifies the ciphertext field to obtain a de-identified value; and writes the de-identified value into the original field corresponding to the original data field using the encryption strategy to obtain an encrypted storage result.

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

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

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

[0123] 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 sensitive data encryption storage method. This solves the technical problems of existing data encryption technologies, such as fragmented functions, lack of fault tolerance mechanisms, and inability to simultaneously guarantee business continuity, query integrity, and data security. 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 sensitive data encryption storage method provided in the above embodiments, and will not be repeated here.

[0124] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the sensitive data encryption and storage method described above.

[0125] The computer program product provided in this application can solve the technical problems of existing data encryption technologies, such as fragmented functions and lack of fault tolerance mechanisms, which cannot simultaneously guarantee business continuity, query integrity, and data security. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the sensitive data encryption and storage method provided in the above embodiments, and will not be repeated here.

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

Claims

1. A method for encrypting and storing sensitive data, characterized in that, The method for encrypting and storing sensitive data includes: Configure a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted; An encryption strategy is selected based on the list of fields to be encrypted, and the original SQL query statement is parsed and rewritten according to the encryption strategy to obtain the rewritten SQL statement. Based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, the data of the list of fields to be encrypted is migrated through the encryption lifecycle state machine to obtain the ciphertext fields after migration is completed. The encrypted field is decrypted and de-identified to obtain a de-identified value, and the de-identified value is written into the original field corresponding to the original data field through the encryption strategy to obtain the encrypted storage result.

2. The method for encrypting and storing sensitive data as described in claim 1, characterized in that, The step of configuring a whitelist for the original data fields to obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted includes: Receive a whitelist configuration instruction, parse the whitelist configuration instruction to obtain the table name to be encrypted and the field name to be encrypted, and generate a whitelist configuration entry based on the table name to be encrypted and the field name to be encrypted. The original data fields are filtered according to the whitelist configuration entries to obtain a list of fields to be encrypted; Periodically allocate the list of fields to be encrypted to obtain the lifecycle status of the list of fields to be encrypted.

3. The method for encrypting and storing sensitive data as described in claim 1, characterized in that, The step of selecting an encryption strategy based on the list of fields to be encrypted to obtain the encryption strategy includes: Based on the list of fields to be encrypted, read the original field names and final field names of several fields to be encrypted from the encryption configuration table to obtain the field name mapping relationship; Determine whether the original field name and the final field name are the same based on the field name mapping relationship; If they are the same, then the encryption strategy is determined to be a single-field encryption strategy; If they are different, then the encryption strategy is determined to be a two-field encryption strategy.

4. The method for encrypting and storing sensitive data as described in claim 1, characterized in that, The steps of parsing and rewriting the original SQL query statement according to the encryption strategy to obtain the rewritten SQL statement include: The original SQL query statement is parsed into an abstract syntax tree by the SQL parser, resulting in the syntax tree structure; According to the encryption strategy, the query field nodes and condition expression nodes in the syntax tree structure are traversed to obtain the set of condition nodes to be rewritten. The set of condition nodes to be rewritten is rewritten according to the encryption strategy to obtain the rewritten SQL statement.

5. The method for encrypting and storing sensitive data as described in claim 1, characterized in that, The step of performing data migration on the list of fields to be encrypted using an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, to obtain the migrated ciphertext fields, includes: The new field corresponding to the original data field is based on the lifecycle status of the list of fields to be encrypted; By using the dual-write mode, new data is written to both the new field and the original field corresponding to the original data field, thus obtaining a dual-write state. Based on the dual-write status and the rewritten SQL statement, the existing data is read through cursor pagination, and the existing data is encrypted and then written into the new field; After the write operation is complete, switch the query status to read new fields to obtain the switched status. When the switching status is "switching complete", the dual-write mode is stopped, and the ciphertext field with the migration completed is obtained.

6. The method for encrypting and storing sensitive data as described in claim 5, characterized in that, The step of writing new data into the new field and the original field corresponding to the original data field through dual-write mode to obtain the dual-write state includes: The newly added data is encrypted to obtain encrypted data, and the execution result of the encryption operation is monitored to obtain encryption status feedback; If the encryption status feedback indicates successful encryption, then the encrypted data is written into the new field, and the plaintext of the newly added data is written into the original field to obtain the writing result; If the encryption status feedback indicates encryption failure, the field that failed to encrypt will be retried for encryption. When the number of retry encryption attempts reaches the retry threshold, the plaintext of the new data will be written into the original field, and the new data will be marked as unencrypted, thus obtaining a downgraded write result. A dual-write status identifier is generated based on the write result or the downgrade write result, and the dual-write status is obtained.

7. The method for encrypting and storing sensitive data as described in claim 1, characterized in that, The steps of decrypting and de-identifying the ciphertext field to obtain a de-identified value, and writing the de-identified value into the original field corresponding to the original data field using the encryption strategy to obtain the encrypted storage result include: The ciphertext field is read to obtain the corresponding ciphertext data, and the ciphertext data is decrypted using a decryption algorithm to obtain plaintext data; The plaintext data is de-identified to obtain de-identified values; The de-identified value is written into the original field corresponding to the original data field to obtain the encrypted storage result.

8. A sensitive data encryption storage device, characterized in that, The sensitive data encryption storage device includes: The configuration module is used to configure a whitelist for the raw data fields, and obtain a list of fields to be encrypted and the lifecycle status of the list of fields to be encrypted; The rewriting module is used to select an encryption strategy based on the list of fields to be encrypted, obtain an encryption strategy, and perform syntax tree parsing and rewriting on the original SQL query statement according to the encryption strategy to obtain the rewritten SQL statement. The migration module is used to migrate the data of the list of fields to be encrypted through an encryption lifecycle state machine based on the rewritten SQL statement and the lifecycle state of the list of fields to be encrypted, so as to obtain the ciphertext fields after migration is completed. An encryption module is used to decrypt and de-identify the ciphertext field to obtain a de-identified value, and write the de-identified value into the original field corresponding to the original data field through the encryption strategy to obtain an encrypted storage result.

9. A sensitive data encryption storage 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 sensitive data encryption storage method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the sensitive data encryption storage method as described in any one of claims 1 to 7.

Images