SQL-based dynamic desensitization method, apparatus and system, and readable storage medium
By using a SQL-based dynamic data masking method, the masking strategy for sensitive data is synchronized and metadata is refreshed, which solves the problem of sensitive data leakage in scenarios where data is frequently derived in big data dynamic masking solutions, thereby improving data security and stability.
Patent Information
- Application Number
- PCT/CN2025/107713
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-07-11
- Filing Date
- 2025-07-09
- Publication Date
- 2026-01-15
AI Technical Summary
Existing big data dynamic desensitization solutions have failed to effectively cover the problem of sensitive data leakage in scenarios with frequent data derivation, resulting in security risks for sensitive data in data derivation operations.
This paper provides a dynamic data masking method based on SQL. It receives SQL requests to migrate data and synchronizes the data masking strategy of sensitive data during the migration process, refreshes the metadata of the target list, and ensures that sensitive data is protected in derivative operations.
It effectively covers data derivation operations in mainstream business scenarios, avoids sensitive data leakage, improves data security and system stability, and ensures that sensitive data is always constrained by desensitization strategies during data migration and derivation.
Smart Images

Figure CN2025107713_15012026_PF_FP_ABST
Abstract
Description
A method, apparatus, system, and readable storage medium for dynamic data masking based on SQL.
[0001] This application claims priority to Chinese Patent Application No. 202410934793.8, filed on July 11, 2024, entitled "A Dynamic De-identification Method, Apparatus, System and Readable Storage Medium Based on SQL", the entire contents of which are incorporated herein by reference. Technical Field
[0002] This application relates to the field of sensitive data processing technology, and in particular to a dynamic desensitization method, apparatus, system, and readable storage medium based on SQL. Background Technology
[0003] Data privacy protection is one of the most important issues facing the era of big data. Open data sharing is the core of big data competition. With the continuous emergence of new technical architectures and big data support platforms, cloud-native technologies and lake warehouse architectures are reconstructing big data infrastructure. From accessing data lakes and data warehouses to cross-database and cross-domain sharing, stronger data security and data sharing capabilities are needed.
[0004] Data security in the open big data environment differs significantly from traditional data security, with changes in protection methods, protected objects, and the relationship between management and technology. Open big data applications aim for open data sharing, involve more diverse roles in data processing, and data flow is the norm. This places higher demands on data security protection, rendering traditional data security measures such as data encryption and static data masking no longer applicable.
[0005] Adopting privacy protection and dynamic data anonymization technology is an important means to promote the secure circulation and sharing of data and ensure the trustworthiness of big data services. However, current big data dynamic anonymization solutions do not take into account the problem of automatic anonymization strategies in scenarios where data is frequently derived, which can lead to the leakage of sensitive data. Furthermore, they do not cover data derivation operations in mainstream business scenarios (such as creating new tables and writing data, or writing data to existing tables). Therefore, they have significant limitations in practical applications.
[0006] Therefore, how to expand into real-world big data business scenarios, avoid sensitive data leakage, and improve data security are urgent issues that need to be addressed. Summary of the Invention
[0007] This application provides a dynamic data masking method, apparatus, system, and readable storage medium based on SQL. For scenarios involving frequent data derivation, the dynamic data masking apparatus migrates data between lists according to relevant SQL requests. When the migrated data includes sensitive data, the first data masking strategy for that sensitive data in the first list is synchronized to the second list according to synchronization rules. After successful synchronization, the metadata of the second list is refreshed, completing the derivation operation of the sensitive data and its corresponding data masking strategy. This effectively expands practical business scenarios, prevents sensitive data leakage, and improves data security.
[0008] Firstly, a dynamic data masking method based on SQL is provided. The method includes: receiving an SQL request for data migration; migrating data from a first list to a second list based on the SQL request; synchronizing a first data masking strategy for sensitive data in the first list to the second list according to a synchronization rule if the migrated data includes sensitive data; and refreshing the metadata of the second list after successful synchronization.
[0009] Implementing the embodiments of this application, in scenarios involving data migration, not only is the data-level migration completed, but when the migrated data contains sensitive data, the de-identification strategy corresponding to the sensitive data needs to be synchronized to the new list according to the set synchronization rules. After the de-identification strategy is successfully synchronized, the metadata of the new list is refreshed. This can cover data-derived operations in mainstream business scenarios, avoid sensitive data leakage, and improve data security.
[0010] Based on the first aspect, in a possible implementation, if the source and target of the data are determined to be in the same security zone based on the SQL request, the data is migrated from the first list to the second list. It should be understood that, to support high performance and data sharing capabilities in an open big data environment, data is stored in plaintext within the same security zone, and data can flow freely within the same security zone. Therefore, if the source and target of the data are determined to be in the same security zone, data migration can be performed directly.
[0011] Based on the first aspect, in a possible implementation, if it is determined from the SQL request that the source and target of the data are not in the same security zone, and the data includes sensitive data, the sensitive data is de-identified according to the first de-identification strategy; the de-identified data is then migrated from the first list to the second list. It should be understood that for cross-domain data transmission, this solution directly de-identifies the sensitive data that needs to be transmitted across domains, and then writes the de-identified data into a new list. This avoids sensitive data leakage and further improves data security.
[0012] Based on the first aspect, in a possible implementation scheme, when synchronizing the de-identification strategies, if the first list also includes a second de-identification strategy, and the data migrated to the second list includes sensitive data corresponding to the second de-identification strategy, then synchronization is determined to have failed; or, if the second list includes a third de-identification strategy, and the first de-identification strategy conflicts with the third de-identification strategy, then synchronization is determined to have failed; or, if the second list does not contain any de-identification strategies, then the first de-identification strategy is synchronized to the second list; or, if the second list includes a fourth de-identification strategy, and the first de-identification strategy is consistent with the fourth de-identification strategy, then the first de-identification strategy is synchronized to the second list or synchronization is directly determined to have succeeded. It should be understood that for various situations that may be encountered during strategy synchronization, this scheme standardizes the synchronization process by setting corresponding synchronization rules, ensuring that there is a corresponding synchronization scheme in each case. This can effectively avoid situations such as de-identification strategy conflicts, ensuring that the entire system can have normal business execution logic, and enabling the de-identification strategy to still constrain sensitive data after data migration, thereby improving the stability and reliability of the system.
[0013] Based on the first aspect, in a possible implementation, if synchronization fails, the de-identification policy corresponding to the sensitive data is reset to a mask display policy, which is used to enable masking when querying sensitive data; or, the SQL request is terminated, and an error message is returned. It should be understood that after synchronization failure, this solution forcibly resets the relevant de-identification policy to a mask display policy or directly terminates the SQL request, which can prevent sensitive data leakage and further improve data security.
[0014] Based on the first aspect, in a possible implementation, during the synchronization of the first de-identification policy to the second list, an administrator account is used to log in to the de-identification policy service. This administrator account has write permissions for de-identification policies, and the de-identification policy service is used to store these policies. If the first de-identification policy is not present in the de-identification policy service, it is written into the service. It should be understood that a de-identification policy only takes effect when written to the de-identification policy service. Therefore, this solution, by embedding an administrator account in the SQL engine and granting it write permissions, ensures that the first de-identification policy is synchronized to the second list. This ensures that sensitive data in the second list still has corresponding de-identification policies to protect it in subsequent business operations, preventing sensitive data leakage and improving data security.
[0015] Based on the first aspect, in a possible implementation, before writing the first de-identification strategy into the de-identification strategy service, the elements of all de-identification strategies in the de-identification strategy service are compared one by one with the elements of the first de-identification strategy. These elements include the content of the de-identification strategy, the field containing the sensitive data corresponding to the de-identification strategy, and the business object to which the sensitive data applies. It should be understood that the de-identification strategy service includes not only de-identification strategies written by the SQL engine but also original de-identification strategies pre-configured by the administrator. Therefore, this solution performs a comparison before writing the de-identification strategy and then determines whether to write it into the de-identification strategy service based on the comparison results. This reduces the storage resource consumption of the de-identification strategy service and improves resource utilization.
[0016] Based on the first aspect, in a possible implementation, when writing the first de-identification strategy into the de-identification strategy service, a derived identifier is added to the first de-identification strategy. This derived identifier is used to indicate that the first de-identification strategy is a derived de-identification strategy; the first de-identification strategy with the derived identifier is then written into the de-identification strategy service. It should be understood that the de-identification strategy service includes two types of de-identification strategies: the original de-identification strategy and the de-identification strategy written by the SQL engine. To distinguish between these two types of de-identification strategies, this solution adds a derived identifier, such as a prefix or suffix, to the written de-identification strategy. This allows for easy identification of which de-identification strategies are written by the SQL engine.
[0017] Based on the first aspect, in a possible implementation, an SQL request is received for deleting sensitive data; based on the SQL request, the sensitive data is deleted from a second list; and an administrator account logs into the de-identification policy service to delete a first de-identification policy with a derived identifier added to it. It should be understood that the migrated data and the de-identification policies written to the de-identification policy service are strongly correlated. When the migrated sensitive data is deleted, this solution uses an administrator account to log into the de-identification policy service and deletes the de-identification policies with derived identifiers associated with the sensitive data. This ensures that the execution logic of the entire system is not disrupted, business operations can be performed normally, and the continuous increase of de-identification policies in the de-identification policy service is avoided, reducing their consumption of storage resources and improving resource utilization.
[0018] Based on the first aspect, in a possible implementation, a new table statement or an insert statement is received. The new table statement is used to retrieve sensitive data from the first list and write it into a newly created second list; the insert statement is used to retrieve sensitive data from the first list and write it into the second list to be inserted. It should be understood that new table statements (e.g., CTAS statements) and insert statements (e.g., INSERT statements) are commonly used SQL table creation and insertion statements, involved in most business scenarios. This solution, by receiving and processing new table statements and insert statements, can cover data migration operations in mainstream business scenarios and effectively expand business scenarios.
[0019] Secondly, this application also provides a dynamic data masking device based on SQL, including a receiving module, a migration module, a synchronization module, and a refresh module. The receiving module is used to receive SQL requests for data migration; the migration module is used to migrate data from a first list to a second list based on the SQL request; the synchronization module is used to synchronize a first data masking strategy for sensitive data in the first list to the second list according to synchronization rules when the data being migrated includes sensitive data; and the refresh module is used to refresh the metadata of the second list after successful synchronization.
[0020] The aforementioned SQL-based dynamic data masking device may also include more or fewer units / modules, without specific limitations here. The SQL-based dynamic data masking device in the second aspect is specifically used to execute the method of any implementation scheme as described in the first aspect, as can be found in the preceding description, and will not be repeated here.
[0021] Thirdly, this application also provides a computing device cluster including at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method as described in any embodiment of the first aspect.
[0022] Fourthly, a SQL-based dynamic data masking system is provided, comprising the SQL-based dynamic data masking device of the second aspect described above, which is used to perform the method as described in any embodiment of the first aspect. In another possible design, the system may further include other devices that interact with the SQL-based dynamic data masking device provided in this application.
[0023] Fifthly, this application also provides a computer-readable storage medium including computer program instructions that, when executed by a cluster of computing devices (including at least one computing device), perform the method as described in any embodiment of the first aspect.
[0024] Sixthly, this application also provides a computer program product containing instructions. When the aforementioned instructions are executed by a cluster of computing devices (including at least one computing device), the cluster of computing devices causes the cluster of computing devices to perform the method as described in any embodiment of the first aspect. Attached Figure Description
[0025] Figure 1 is a schematic diagram of the structure of a dynamic de-identification system based on SQL provided in an embodiment of this application;
[0026] Figure 2 is a flowchart illustrating a dynamic de-identification method based on SQL provided in an embodiment of this application;
[0027] Figure 3 is a schematic diagram of data transmission provided in an embodiment of this application;
[0028] Figure 4 is a schematic diagram of a write desensitization strategy provided in an embodiment of this application;
[0029] Figure 5 is a schematic diagram of the structure of a dynamic de-identification device based on SQL provided in an embodiment of this application;
[0030] Figure 6 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;
[0031] Figure 7 is a schematic diagram of a computing device cluster provided in an embodiment of this application;
[0032] Figure 8 is a schematic diagram of a scenario in which two computing devices interact, as provided in an embodiment of this application. Detailed Implementation
[0033] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.
[0034] In the description of this application, terms such as "first" and "second" are used only to distinguish different objects, not to describe a specific order. Furthermore, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, "at least one" refers to one or more, and "multiple" refers to two or more. "One or more of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, and c can be single or multiple.
[0035] The terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.
[0036] In this application, the words "exemplary" or "for example" are used to indicate that something is an example, illustration, or illustration. Any embodiment or design described as "exemplary," "for example," or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of the words "exemplary," "for example," or "for example" is intended to present the relevant concepts in a specific manner.
[0037] It is understood that in this application, "when," "if," and "if" all refer to the device performing a corresponding action under certain objective circumstances, and are not time-limited, nor do they require the device to perform a judgment action when it is implemented, nor do they imply any other limitations. The device performing a corresponding action under certain objective circumstances includes: satisfying the objective circumstances, i.e., being able to perform the corresponding action; or satisfying both the objective circumstances and other circumstances, in order to perform the corresponding action.
[0038] In this application, "simultaneous" can be understood as "parallel", or at the same point in time, or within a period of time, or within the same cycle. The specific meaning can be understood in conjunction with the context.
[0039] In this application, the use of singular designations for elements is intended to represent "one or more" rather than "one and only one," unless otherwise specified.
[0040] It is understood that in the embodiments of this application, "B corresponding to A", "A and B correspond" or similar expressions indicate that B is associated with A, and B can be determined based on A. Determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.
[0041] Secondly, in order to facilitate understanding of the embodiments of this application, some terms and concepts involved in the embodiments of this application will be briefly introduced below.
[0042] Data derivation: The process of generating new datasets or variables by processing, calculating, and transforming raw data. These new datasets or variables can be used for more in-depth analysis, modeling, visualization, and other tasks.
[0043] Data lineage: In data processing, the relationship between the source and destination of each data element. It describes the transfer and transformation of data elements throughout the data flow, including data input, output, transformation, and processing. By understanding data lineage, we can trace the source and destination of data, understand the data processing process, and ensure data reliability and integrity.
[0044] Dynamic data anonymization: A data protection technology that dynamically anonymizes sensitive data as it is used, protecting its privacy and security without affecting its validity and usability. Data anonymization involves replacing, deleting, or encrypting key information within sensitive data to protect its privacy and security.
[0045] Structured Query Language (SQL) is a special-purpose programming language, a database query and programming language used to access, query, update, and manage relational database systems. It is also the file extension for database script files. SQL allows users to work at high-level data structures without requiring them to specify how data is stored or understand the specific data storage methods. Different database systems with completely different low-level structures can use the same SQL as an interface for data input and management.
[0046] SQL Engine: A core component of database management systems used for storing, processing, and protecting data, especially a core service in relational database management systems. It provides controlled access and fast transaction processing capabilities to meet the needs of demanding enterprise applications that process large volumes of data. Using the database engine, you can create relational databases for online transaction processing or online analytical processing (OLAP), including creating tables to store data and database objects (such as indexes, views, and stored procedures) for viewing, managing, and protecting data security.
[0047] In an open big data environment, higher demands are placed on data availability, data processing efficiency, and system scalability. This necessitates enhanced dynamic data anonymization capabilities that do not compromise business operations to improve data security. Data sharing is a typical characteristic of big data applications. A common big data analytics platform involves multiple SQL engines (such as Hive, Spark, and Hetu engines) sharing the same data (e.g., data from the same database) and anonymization strategy services. Different SQL engines correspond to different clients and users, and the anonymization strategy service stores the anonymization policies. In actual business execution, the SQL engine processes data in the database based on SQL requests sent by the client. If the SQL request involves sensitive data, the SQL engine dynamically anonymizes the sensitive data according to the relevant anonymization strategies during data processing, thereby completing the relevant business logic.
[0048] The above method can meet the data security requirements of most businesses. However, it has significant security vulnerabilities in certain business scenarios, especially those involving data derivatives. For example, the SQL engine receives a first SQL request from a client. This first SQL request writes data from list A in the database to list B. The data in list A is sensitive data for the client. The SQL engine executes the first SQL request, writing the data from list A to list B. Since lists A and B are in the same security zone (i.e., the same database), the data is stored in plaintext. The data in list A is identical to the data written to list B. That is, the SQL engine does not perform any data masking for sensitive data when writing data. After completing the data writing, the client sends a second SQL request to the SQL engine. This second SQL request retrieves data from list B. The SQL engine executes the second SQL request. Since there is no data masking policy for list B data relative to the client in the data masking policy service, the SQL engine directly returns the data from list B to the client. The returned data includes the sensitive data for the client. As can be seen, in the above business scenario, if the client directly sends an SQL request to the SQL engine to retrieve data from list A, the SQL engine will use a data masking strategy to mask the sensitive data when executing the SQL request, and then return the masked data to the client. In this case, the client will not be able to obtain the sensitive data. However, through the above method, the client gets rid of the constraints of the data masking strategy by data derivation (writing data from list A into list B), resulting in the leakage of sensitive data and seriously damaging data security.
[0049] Based on this, this application provides a dynamic data masking system 100 based on SQL, as shown in Figure 1. The system 100 includes multiple SQL engines, such as Hive engine 110, Spark engine 120, and Hetu engine 130, clients corresponding to these multiple SQL engines, such as Hive client 210, Spark client 220, and Hetu client 230, and a data masking policy service 310, such as Apache Ranger. The multiple clients and the multiple SQL engines, as well as the multiple SQL engines and the data masking policy service 310, are connected via a network. This network can be a carrier network or a network composed of optical cables and data transmission equipment; this application does not impose specific limitations. Each SQL engine deploys an intelligent SQL rewriting unit and a policy synchronization unit. For example, Hive engine 110 deploys an intelligent SQL rewriting unit 1110 and a policy synchronization unit 1120, Spark engine 120 deploys an intelligent SQL rewriting unit 1210 and a policy synchronization unit 1220, and Hetu engine 130 deploys an intelligent SQL rewriting unit 1310 and a policy synchronization unit 1320. The functions of various SQL engines are similar. Taking the interaction between Hive engine 110 and Hive client 210 as an example, the dynamic data masking process of this dynamic data masking system will be explained. Hive client 210 sends a data query SQL request to Hive engine 110. Hive engine 110 analyzes the SQL request. If it determines that the queried data includes sensitive data, Hive engine 110 accesses the data masking strategy service 310 through the interaction interface (e.g., application programming interface, API) provided by the data masking strategy service 310, finds the data masking strategy associated with the sensitive data, and then the intelligent SQL rewriting unit 1110 in Hive engine 110 performs data masking processing on the sensitive data based on the found data masking strategy to obtain the masked data, and returns the masked data to Hive client 210. Hive client 210 sends a data-derived SQL request to Hive engine 110, such as a SELECT statement to create a new table (CTAS) or an INSERT statement using the result set of a SELECT statement. Hive engine 110 analyzes the SQL request. If the analysis reveals that the data to be written to the newly created table includes sensitive data, or the data to be inserted into an existing table includes sensitive data, then after completing the data writing to the new table or insertion into the existing table, Hive engine 110 derives the de-identification strategy corresponding to the sensitive data and synchronizes it to the new table or the inserted table. That is, Hive engine 110 writes the de-identification strategy into de-identification strategy service 310 by calling the interface of de-identification strategy service 310.After the data masking strategy is synchronized, the new table or inserted table will also include the data masking strategy. In subsequent business processing, sensitive data in the new table or inserted table will be subject to the data masking strategy, thereby ensuring that sensitive data will not be leaked.
[0050] As can be seen, the SQL-based dynamic data masking system provided in this application can automatically generate data masking strategies corresponding to sensitive data in data-derived business scenarios. This ensures that sensitive data still has the corresponding data masking strategy after being derived, such as being written into a new list or inserted into another list, thereby eliminating the vulnerability of sensitive data leakage and further improving data security while ensuring that business operations are not compromised.
[0051] It should be understood that Figure 1 above illustrates the logical connection relationship between the client, SQL engine, and masking strategy service. The multiple clients, multiple SQL engines, and masking strategy service can reside on the same physical device or on different physical devices. When they reside on multiple different physical devices, these devices can be located in the same rack. For example, as shown in Figure 1, Hive engine 110 and Spark engine 120 are located on the same server, and masking strategy service 310 is located on another server. These two servers are located in the same rack and are connected through a switching node within the rack. When the multiple components reside on the same physical device, their interaction can be achieved through a switching chip within the physical device or through a different switching device.
[0052] It should also be understood that Figure 1 above only illustrates an example of the topology of the SQL-based dynamic data masking system provided in this application, and should not be construed as a specific limitation. The dynamic data masking system can also have other topologies. For example, the dynamic data masking system can include more or fewer SQL engines or clients. The connection relationships between the clients and SQL engines, and between the SQL engines and the data masking strategy service, are merely examples and should not be construed as specific limitations. Other connection relationships can also exist between the clients and SQL engines, and the embodiments of this application do not impose specific limitations.
[0053] The following section, in conjunction with the aforementioned SQL-based dynamic data masking system and accompanying drawings, details the dynamic data masking method based on the system. Figure 2 is a flowchart illustrating an SQL-based dynamic data masking method provided in an embodiment of this application.
[0054] S101: The SQL engine receives SQL requests, which are used to migrate data.
[0055] Specifically, SQL requests are generated by the client, which directly faces users and business logic. Each user's needs differ, leading to different business processes requiring execution. To achieve normalization and improve processing performance, the client uses a common standard language (SQL) to convert various received business requests into SQL requests and submits the corresponding SQL statements to the SQL engine. The SQL engine then translates these SQL requests into an understandable and executable background task. The SQL engine is middleware situated between the application and the operating system. SQL clients can be various types of applications, such as mobile banking apps and office software.
[0056] It should be noted that different SQL engines correspond to different clients, and different clients are targeted at different customers. However, different SQL engines can share the same data and comply with the same data security standards. In other words, the data (such as data in the same database) and the data masking strategy (the data masking strategy included in the data masking strategy service) are global in nature. Different SQL engines process, transfer, and transform the data based on the same database and data masking strategy service to meet the business needs of different users.
[0057] Furthermore, after receiving an SQL request from the client, the SQL engine does not immediately execute the SQL request. Instead, it further analyzes the SQL request to determine whether it involves data derivation or migration. Optionally, the SQL engine checks whether the SQL statement in the SQL request conforms to the syntax of a CTAS or INSERT statement. If it does, the SQL engine determines that the SQL request is for data migration; if it does not, the SQL request does not involve data migration and is executed directly.
[0058] S102: The SQL engine migrates data from the first list to the second list based on SQL requests.
[0059] Specifically, after determining that the received SQL request is for data migration, the SQL engine queries the data that needs to be migrated, and then migrates the data from the first list to the second list.
[0060] It should be understood that during the data migration process, the SQL engine may process or transform the data in the first list retrieved based on the SQL request, and then migrate the processed or transformed data to the second list. That is, the data in the first list before migration and the data in the second list after migration are not strictly identical. They may differ in form or value, but they are related. The data in the second list can be restored to the data in the first list through the corresponding reverse operation.
[0061] It should be noted that the first and second lists are stored in a directory and have corresponding storage paths. When the SQL engine performs this step, it only completes the storage and copying of the data, but does not refresh the table metadata of the second list. That is, the SQL engine cannot query the newly migrated data in the second list.
[0062] In one implementation, during the data migration process based on the SQL request, the SQL engine analyzes the source and target of the data based on the table names contained in the SQL request. The source refers to the location where the data is stored, and the target refers to the location after the data migration. The SQL engine then combines the security zone division rules to further determine whether the source and target of the data are in the same security zone.
[0063] It should be understood that the division of security zones is a conceptual division, which can be flexibly divided and set according to actual business needs and other factors. For example, different data lakes can be divided into different security zones, or different databases can be divided into different security zones, or some data warehouses can be divided into the same security zone and some data warehouses can be divided into another security zone. This application does not limit this.
[0064] Furthermore, when the SQL engine determines that the source and destination of the data are in the same security zone, it migrates the data from the first list to the second list; when the SQL engine determines that the source and destination of the data are not in the same security zone, i.e. the data needs to be transmitted across security boundaries, the SQL engine needs to complete the data migration according to the pre-set security policy.
[0065] It's worth noting that, to improve system scalability and data sharing capabilities, all data (including sensitive and non-sensitive data) is stored in plaintext within the same secure area and can flow freely within that area. Therefore, to enhance data security, appropriate security policies can be set. For example, for cross-domain data transfers that do not involve sensitive data, the SQL engine directly performs data queries and writes. If cross-domain data transfers involve sensitive data, the SQL engine calls the masking policy service interface to find the associated masking policy, performs masking processing on the sensitive data according to that policy, and then writes the masked data to another secure area.
[0066] For example, see Figure 3, which is a schematic diagram of data transmission provided in an embodiment of this application. As shown in Figure 3, the SQL engine connects upwards to components such as a business intelligence (BI) platform and an application (APP). The BI platform is a visual data analysis tool (such as a webpage) that can be used to configure the address of the SQL engine. The APP is used to instruct the SQL engine to perform relevant operations and processing on the data in the data lake. The SQL engine connects downwards to two data lakes, namely data lake 1 and data lake 2. The SQL engine can communicate and interact with data lake 1 and data lake 2 simultaneously and has the ability to query and write data across different data lakes. Data lake 1 has two storage blocks, namely storage block 1 and storage block 2, and data lake 2 has storage block 3. The data stored in storage block 1 is: salary 15000. This data is sensitive data, and its corresponding desensitization strategy is strategy 1. If the SQL engine receives an SQL request and needs to write the data in storage block 1 to storage block 2, since the SQL engine determines that both storage block 1 and storage block 2 are located in data lake 1, it directly writes the data to storage block 2, and the data in storage block 2 also follows the de-identification strategy 1. That is, the data written to storage block 2 is still: salary 15000. If the SQL engine receives an SQL request and needs to write the data in storage block 1 to storage block 3, when the SQL engine determines that storage block 1 and storage block 3 are located in different data lakes and do not belong to the same security area, and the data needs to be transmitted across the security boundary, the SQL engine, after retrieving the data from storage block 1, performs de-identification processing on the data according to de-identification strategy 1, for example, by hiding it. The processed data is: salary ***, and then the de-identified data is written to storage block 3. That is, the data written to storage block 3 is: salary ***.
[0067] As can be seen, in the scenario of cross-domain data transmission, the SQL engine performs security management through the set security policies. If it finds that the cross-domain transmitted data involves sensitive data, it will immediately de-identify it, which can prevent the leakage of sensitive data and further improve data security.
[0068] S103: The SQL engine determines whether the migrated data includes sensitive data. If it does not include sensitive data, proceed to step S107; if it includes sensitive data, proceed to step S104.
[0069] Specifically, during the data migration process, the SQL engine needs to identify whether the data to be migrated includes sensitive data. Based on the different identification results, the SQL engine will perform different subsequent operations.
[0070] Optionally, the identification and judgment of sensitive data can be based on regular expressions or other methods, and this application does not limit this.
[0071] S104: The SQL engine synchronizes the first de-identification policy for sensitive data in the first list to the second list according to the synchronization rules.
[0072] Specifically, since the data is stored in plaintext within the same security zone, if only the sensitive data in the first list is migrated to the second list, then only the sensitive data in the first list will be subject to the constraints and protection of the first de-identification strategy, thus preventing data leakage. However, the sensitive data in the second list will not be subject to the restrictions of the first de-identification strategy, posing a risk of leakage. Therefore, it is necessary to synchronize the first de-identification strategy to the second list according to the synchronization rules, thereby mitigating security vulnerabilities and improving data security.
[0073] In one implementation, if the first list also includes a second de-identification strategy, and the data migrated to the second list includes sensitive data corresponding to the second de-identification strategy, then synchronization is determined to have failed; or, if the second list includes a third de-identification strategy, and the first de-identification strategy conflicts with the third de-identification strategy, then synchronization is determined to have failed; or, if the second list does not contain a de-identification strategy, then the first de-identification strategy is synchronized to the second list; or, if the second list includes a fourth de-identification strategy, and the first de-identification strategy is consistent with the fourth de-identification strategy, then the first de-identification strategy is synchronized to the second list or synchronization is directly determined to have succeeded.
[0074] Specifically, the first list may contain multiple fields, and more than one field may contain sensitive data. For example, if the first field contains sensitive data, the corresponding desensitization strategy is the first desensitization strategy. If the third field also contains sensitive data, the corresponding desensitization strategy is the second desensitization strategy. When the SQL engine executes an SQL request to migrate data, it may not only migrate the data of one field, but also merge the data of multiple fields before migrating them and writing the merged data into a field in the second list. For example, if the current SQL request writes the first field and the third field from the first list into the first field of the second list, when the SQL engine executes this SQL request, because the first desensitization strategy corresponding to the first field and the second desensitization strategy corresponding to the third field conflict, the SQL engine will determine that the synchronization has failed, that is, it is impossible to form a unified desensitization strategy that effectively constrains the first field in the second list. Alternatively, if the current SQL request is to migrate the data of the first field in the first list to the first field in the second list, and the first field in the second list already has a third desensitization strategy, and the first desensitization strategy conflicts with the third desensitization strategy, then when the SQL engine executes the SQL request, it will also be unable to form a unified desensitization strategy that effectively constrains all the data of the first field in the migrated second list, and thus the synchronization will be deemed to have failed.
[0075] Furthermore, if the current SQL request is a CTAS statement, such as `creattable table2 as select * from table1…`, the SQL engine executes this statement to create a new table named `table2`, then retrieves the data from `table1` and writes it into `table2`. Since the second table is newly created and does not have a masking strategy, the SQL engine can directly synchronize the first masking strategy to the newly created second table. Alternatively, if the current SQL request is an INSERT statement, such as `insertintotable table2 select * from table1…`, the SQL engine executes this statement to retrieve the data from `table1` and write it into `table2`. Assuming the second table already has a fourth masking strategy, but the first masking strategy is consistent with the fourth, the SQL engine can either synchronize the first masking strategy to the second table or directly determine that the synchronization is successful, i.e., directly use the fourth masking strategy to uniformly mask all data in the migrated second table.
[0076] In another implementation, the SQL engine logs into the de-identification policy service using an administrator account. If the first de-identification policy is not present in the de-identification policy service, the first de-identification policy is written into the de-identification policy service.
[0077] Specifically, the masking strategies in the masking strategy service are for all SQL engines and users. Therefore, when the SQL engine performs masking strategy synchronization, it can only be considered a true synchronization success if it writes the masking strategy that meets the synchronization rules into the masking strategy service. In other words, the masking strategy written by the SQL engine can take effect and provide security protection for the migrated data.
[0078] Furthermore, the SQL engine has a built-in administrator account (such as the Ranger administrator account), which is granted write permissions for the de-identification policy. When the SQL engine needs to synchronize the policy, it calls the interface of the de-identification policy service and writes the new de-identification policy into the de-identification policy service as an administrator through the interface.
[0079] For example, refer to Figure 4, which is a schematic diagram of writing a de-identification strategy according to an embodiment of this application. As shown in Figure 4, each SQL client calls the interface of the corresponding SQL engine through its associated business account to perform business interaction. For example, the Hive client interacts with the Hive engine through business account 1, and the Spark client interacts with the Spark engine through business account 2. Each SQL engine has a built-in administrator account; for example, the Hive engine has a built-in administrator account A, and the Spark engine has a built-in administrator account B. The permissions granted to the administrator accounts of each SQL engine can be consistent, all granting the permission to write the de-identification strategy to the de-identification strategy service. When the SQL engine detects the need to synchronize the de-identification strategy during the execution of an SQL request, for example, the Hive engine calls interface 1 of the de-identification strategy service through administrator account A to write the de-identification strategy that needs to be synchronized into the de-identification strategy service.
[0080] In another implementation, the SQL engine compares the elements of all de-identification strategies in the de-identification strategy service with the elements of the first de-identification strategy one by one. If all elements match completely, the de-identification strategies are determined to be the same.
[0081] Specifically, the administrator pre-configures masking policies in the masking policy service. These policies are configured for all SQL engines and users. Therefore, when an SQL engine writes a new masking policy to the masking policy service, it needs to determine whether the new masking policy already exists. During this determination, the SQL engine compares each element of all masking policies in the masking policy service with the elements of the first masking policy to be written. The elements of a masking policy include the specific content of the policy, the field containing the corresponding sensitive data, and the business objects to which the sensitive data applies (e.g., Zhang San, Li Si, etc.). This comparison means that each item in the elements is compared one by one. Only if all elements are completely identical are the two masking policies considered the same; if even one element is different, the two masking policies are considered different. The SQL engine only writes the first masking policy to the masking policy service if it determines that there is no masking policy identical to the one to be written. This method reduces the storage resource consumption of the masking policy service and improves resource utilization.
[0082] In another implementation, the SQL engine adds a derivative identifier to the first desensitization strategy. This derivative identifier is used to indicate that the first desensitization strategy is a derivative desensitization strategy, and the first desensitization strategy with the added derivative identifier is written to the desensitization strategy service.
[0083] Specifically, in order to distinguish between the original desensitization strategy in the desensitization strategy service and the new desensitization strategy written through the SQL engine, the SQL engine can add derivative identifiers to the desensitization strategy to be written each time a desensitization strategy is written, thereby distinguishing between the two types of desensitization strategies.
[0084] S105: The SQL engine determines whether the synchronization was successful. If the synchronization fails, proceed to step S106. If the synchronization is successful, proceed to step S107.
[0085] Specifically, the SQL engine synchronizes the de-identification strategy according to the above synchronization rules. If the synchronization rules are met, the SQL engine determines that the synchronization is successful and writes the de-identification strategy into the de-identification strategy service using the built-in administrator account. If the synchronization rules are not met, the synchronization is determined to have failed.
[0086] S106: The SQL engine resets the masking policy to a mask display policy.
[0087] Specifically, when the above-mentioned policy conflict occurs, the SQL engine determines that the synchronization has failed. At this time, the SQL engine will forcibly reset the de-identification policy to the mask display policy. That is, when the SQL engine executes a subsequent SQL request, if the SQL request involves querying sensitive data in the second list, the SQL engine will turn on the mask, so that the sensitive data cannot be queried and displayed normally. In this way, sensitive data leakage is avoided and data security is guaranteed.
[0088] Optionally, after determining that synchronization has failed, the SQL engine can directly terminate the execution of the current SQL request and return an error message to the client to prompt the user to re-enter the correct SQL request, thereby reducing the consumption of SQL engine resources and improving the processing efficiency of the SQL engine.
[0089] S107: The SQL engine refreshes the metadata of the second list.
[0090] Specifically, in order to ensure that the SQL engine can query the migrated data normally, the metadata of the second list needs to be refreshed. After the refresh, the SQL engine can perform normal business processing on the data in the second list according to the received SQL request.
[0091] In one implementation, the SQL engine receives an SQL request for deleting sensitive data, deletes the sensitive data from a second list based on the SQL request, and logs into the de-identification policy service using an administrator account to delete the first de-identification policy with the added derivative identifier from the de-identification policy service.
[0092] Specifically, when it is necessary to delete previously migrated sensitive data, the SQL engine not only needs to complete the deletion at the data level, but also needs to delete the de-identification policy synchronized for the sensitive data. The SQL engine can log in to the de-identification policy service through the built-in administrator account and find the de-identification policy that was previously written and added with the derivative identifier.
[0093] It is understandable that by using the above methods, not only can the execution logic of the entire system be guaranteed to remain intact and the business operations be executed normally, but the continuous increase of de-identification strategies in the de-identification strategy service can also be avoided, reducing the storage resource consumption of the de-identification strategy service and improving resource utilization.
[0094] In summary, the SQL-based dynamic data masking method provided in this application embodiment not only performs data-level migration when the SQL engine executes SQL requests for data migration, but also, when the migrated data includes sensitive data, writes the corresponding data masking policies to the data masking policy service through the built-in administrator account, thereby synchronizing the data masking policies to the new list, and then refreshing the metadata of the new list. This can effectively expand actual business scenarios, avoid sensitive data leakage, and improve data security.
[0095] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the above-described solutions of the embodiments of this application, a dynamic desensitization device for performing the method of FIG2 is described below.
[0096] Please refer to Figure 5, which is a schematic diagram of the structure of a dynamic desensitization device 500 provided in an embodiment of this application, including a receiving module 510, a migration module 520, a synchronization module 530, and a refresh module 540.
[0097] The receiving module 510 is used to receive SQL requests for data migration.
[0098] Migration module 520 is used to migrate data from the first list to the second list based on SQL requests;
[0099] The synchronization module 530 is used to synchronize the first desensitization strategy for sensitive data in the first list to the second list according to the synchronization rules when the data being migrated includes sensitive data.
[0100] The refresh module 540 is used to refresh the metadata of the second list after successful synchronization.
[0101] Optionally, the migration module 520 is specifically used to migrate data from the first list to the second list when the source of the data and the target of the data to be written are determined to be in the same security zone based on the SQL request.
[0102] Optionally, the synchronization module 530 is specifically used to: determine synchronization failure if the first list also includes a second de-identification strategy, and the data migrated to the second list includes sensitive data corresponding to the second de-identification strategy; or, determine synchronization failure if the second list includes a third de-identification strategy, and the first de-identification strategy conflicts with the third de-identification strategy; or, determine synchronization failure if the second list does not contain a de-identification strategy; or, determine synchronization failure if the second list does not contain a de-identification strategy, and the first de-identification strategy is consistent with the fourth de-identification strategy; or, determine synchronization failure if the second list includes a fourth de-identification strategy, and the first de-identification strategy is consistent with the fourth de-identification strategy.
[0103] Optionally, the dynamic desensitization device 500 also includes a policy reset module. The policy reset module is used to reset the desensitization policy corresponding to the sensitive data to a mask display policy when synchronization fails. The mask display policy is used to open the mask when querying sensitive data; or, terminate the execution of the SQL request and return an error message.
[0104] Optionally, the synchronization module 530 is specifically used for: logging into the de-identification policy service using an administrator account, which has write permissions for de-identification policies, and storing de-identification policies in the de-identification policy service; and writing the first de-identification policy into the de-identification policy service if the first de-identification policy is not present in the de-identification policy stored in the de-identification policy service.
[0105] Optionally, the dynamic desensitization device 500 also includes a comparison module, which compares the elements of all desensitization strategies in the desensitization strategy service with the elements of the first desensitization strategy one by one. The elements include the content of the desensitization strategy, the field where the sensitive data corresponding to the desensitization strategy is located, and the business object to which the sensitive data applies; if the elements match completely, it is determined that the desensitization strategies are the same.
[0106] Optionally, the synchronization module 530 is also used to add a derivative identifier to the first desensitization strategy, the derivative identifier being used to indicate that the first desensitization strategy is a derivative desensitization strategy; and to write the first desensitization strategy with the added derivative identifier into the desensitization strategy service.
[0107] Optionally, the dynamic desensitization device 500 also includes a deletion module and a receiving module 510, which is also used to receive an SQL request for deleting sensitive data. The deletion module is used to delete sensitive data from the second list based on the SQL request; and to log in to the desensitization policy service using an administrator account and delete the first desensitization policy with the added derivative identifier from the desensitization policy service.
[0108] Optionally, the receiving module 510 is specifically used to receive a new table statement or an insert statement. The new table statement is used to query sensitive data from the first list and write it into a newly created second list; the insert statement is used to query sensitive data from the first list and write it into the second list to be inserted.
[0109] It should be noted that the receiving module 510, migration module 520, synchronization module 530, and refresh module 540 described above can be implemented in software, in hardware, or in a combination of both. For example, the implementation of synchronization module 530 will be described below. Similarly, the implementation of the other modules can be referenced to the implementation of synchronization module 530.
[0110] As an example of a software functional unit, the synchronization module 530 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the synchronization module 530 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.
[0111] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.
[0112] As an example of a hardware functional unit, the synchronization module 530 may include at least one computing device, such as a server. Alternatively, the synchronization module 530 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.
[0113] The multiple computing devices included in the synchronization module 530 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the synchronization module 530 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the synchronization module 530 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.
[0114] In other embodiments, the receiving module 510, migration module 520, synchronization module 530 and refresh module 540 can all be used to execute any step of the method of the embodiment of FIG2. The steps that each of these modules is responsible for implementing can be specified as needed. Through them, different steps of FIG2 are implemented to realize all the functions of the dynamic desensitization device 500.
[0115] It should also be noted that the dynamic desensitization device 500 described above is used to execute the method of the embodiment in Figure 2. Please refer to the relevant description in Figure 2 for details, which will not be repeated here. The dynamic desensitization device 500 in Figure 5 is only an example of the above-described division of functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the dynamic desensitization device 500 can be divided into other different functional modules to complete all or part of the functions described above.
[0116] Please refer to Figure 6, which illustrates a computing device 600 provided in an embodiment of this application. The device includes a bus 602, a processor 604, a memory 606, and a communication interface 608. The processor 604, memory 606, and communication interface 608 communicate via the bus 602. The computing device 600 may be a server, terminal device, etc., and this embodiment does not specifically limit its functionality. Furthermore, this embodiment does not limit the number of processors and memories in the computing device 600.
[0117] Bus 602 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 6, but this does not imply that there is only one bus or one type of bus. Bus 602 can include pathways for transmitting information between various components of computing device 600 (e.g., memory 606, processor 604, communication interface 608).
[0118] Processor 604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).
[0119] Memory 606 may include volatile memory, such as random access memory (RAM). Processor 604 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0120] The memory 606 stores executable program code. The processor 604 executes the executable program code to implement the functions of the receiving module 510, the migration module 520, the synchronization module 530, and the refresh module 540 in FIG. 5, thereby realizing the dynamic desensitization method of the embodiment of FIG. 2 of this application. That is, the memory 606 stores instructions for executing the dynamic desensitization method.
[0121] The communication interface 608 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 600 and other devices or communication networks.
[0122] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.
[0123] As shown in Figure 7, the computing device cluster includes at least one computing device 600. The memory 606 of one or more computing devices 600 in the computing device cluster may store the same instructions for executing the method of Figure 2.
[0124] In some possible implementations, the memory 606 of one or more computing devices 600 in the computing device cluster may also store partial instructions for executing the method of FIG2. In other words, a combination of one or more computing devices 600 can jointly execute the instructions for the method of FIG2.
[0125] It should be noted that the memory 606 in different computing devices 600 in the computing device cluster can store different instructions, which are used to execute some functions of the dynamic desensitization device 500 in Figure 5. That is, the instructions stored in the memory 606 in different computing devices 600 can realize the functions of one or more modules in the receiving module 510, migration module 520, synchronization module 530 and refresh module 540 in Figure 5.
[0126] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 8 illustrates one possible implementation. As shown in Figure 8, two computing devices 600A and 600B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 606 in computing device 600A stores instructions for performing the functions of the receiving module 510. Simultaneously, the memory 606 in computing device 600B stores instructions for performing the functions of the migration module 520, the synchronization module 530, and the refresh module 540.
[0127] It should be understood that the function of computing device 600A shown in Figure 8 can also be performed by multiple computing devices 600. Similarly, the function of computing device 600B can also be performed by multiple computing devices 600.
[0128] This application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection method of the computing device cluster shown in FIG8. The difference is that the memory 606 of one or more computing devices 600 in this computing device cluster can store the same instructions for executing the method of FIG2 above.
[0129] In some possible implementations, the memory 606 of one or more computing devices 600 in the computing device cluster may also store partial instructions for executing the method of FIG2. In other words, a combination of one or more computing devices 600 can jointly execute instructions for executing the method of FIG2.
[0130] It should be noted that the memory 606 of different computing devices 600 in the computing device cluster can store different instructions for executing some functions of the dynamic de-identification system. That is, the instructions stored in the memory 606 of different computing devices 600 can implement the functions of one or more of the client device, the dynamic de-identification device, and the de-identification policy service device.
[0131] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct a cluster of computing devices (including at least one computing device) to perform the method of the embodiment of FIG2.
[0132] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform the method of the embodiment of FIG2.
[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.
Claims
1. A dynamic data masking method based on SQL, characterized in that, include: Receive an SQL request, which is used to migrate data; Based on the SQL request, the data is migrated from the first list to the second list; If the data being migrated includes sensitive data, the first de-identification strategy for the sensitive data in the first list is synchronized to the second list according to the synchronization rules; After successful synchronization, refresh the metadata of the second list.
2. The method as described in claim 1, characterized in that, The process of migrating the data from the first list to the second list based on the SQL request includes: If, based on the SQL request, it is determined that the source of the data and the target of the data to be written are in the same security zone, the data is migrated from the first list to the second list.
3. The method as described in claim 2, characterized in that, The method further includes: If, based on the SQL request, it is determined that the source of the data and the target of the data to be written are not in the same security zone, and the data includes sensitive data, the sensitive data is desensitized according to the first desensitization strategy. The anonymized data is moved from the first list to the second list.
4. The method according to any one of claims 1-3, characterized in that, The step of synchronizing the first desensitization strategy for the sensitive data in the first list to the second list according to the synchronization rules includes: If the first list also includes a second de-identification strategy, and the data migrated to the second list includes sensitive data corresponding to the second de-identification strategy, then the synchronization is determined to have failed. Alternatively, if the second list includes a third desensitization strategy, and the first desensitization strategy conflicts with the third desensitization strategy, then synchronization is determined to have failed. Alternatively, if the second list does not contain a de-identification strategy, then the first de-identification strategy will be synchronized to the second list; Alternatively, if the second list includes a fourth desensitization strategy, and the first desensitization strategy is consistent with the fourth desensitization strategy, then the first desensitization strategy is synchronized to the second list or the synchronization is directly determined to be successful.
5. The method as described in claim 4, characterized in that, The method further includes: If synchronization fails, the de-identification policy corresponding to the sensitive data is reset to the mask display policy, which is used to open the mask when querying the sensitive data. Alternatively, terminate the execution of the SQL request and return an error message.
6. The method as described in claim 4 or 5, characterized in that, The step of synchronizing the first desensitization strategy to the second list includes: Log in to the de-identification policy service using an administrator account. The administrator account has write permissions for the de-identification policy. The de-identification policy service is used to store the de-identification policy. If the first desensitization strategy is not present in the desensitization strategy service, the first desensitization strategy is written into the desensitization strategy service.
7. The method according to any one of claims 1-6, characterized in that, The receiving of SQL requests, which are used to migrate sensitive data, includes: The system receives either a create table statement or an insert statement. The create table statement is used to retrieve sensitive data from the first list and write it into a newly created second list. The insert statement is used to retrieve sensitive data from the first list and write it into the second list to be inserted.
8. The method as described in claim 6, characterized in that, Before writing the first de-identification policy into the de-identification policy service, the method further includes: The elements of all desensitization strategies in the desensitization strategy service are compared one by one with the elements of the first desensitization strategy. The elements include the content of the desensitization strategy, the field where the sensitive data corresponding to the desensitization strategy is located, and the business object to which the sensitive data applies. If the elements match completely, the desensitization strategies are considered to be the same.
9. The method as described in claim 6 or 8, characterized in that, The step of writing the first de-identification policy into the de-identification policy service includes: A derivative identifier is added to the first desensitization strategy, and the derivative identifier is used to indicate that the first desensitization strategy is a derivative desensitization strategy; Write the first desensitization strategy, which adds the derived identifier, into the desensitization strategy service.
10. The method as described in claim 9, characterized in that, The method further includes: Receive an SQL request, which is used to delete the sensitive data; Based on the SQL request, the sensitive data is removed from the second list; Log in to the desensitization policy service using the administrator account, and delete the first desensitization policy with added derivative identifiers from the desensitization policy service.
11. A dynamic data masking device based on SQL, characterized in that, include: A receiving module is used to receive SQL requests, which are used to migrate data; A migration module is used to migrate the data from a first list to a second list based on the SQL request; The synchronization module is used to synchronize the first desensitization strategy for the sensitive data in the first list to the second list according to the synchronization rules when the data being migrated includes sensitive data. The refresh module is used to refresh the metadata of the second list after successful synchronization.
12. The apparatus as claimed in claim 11, characterized in that, The migration module is specifically used for: If, based on the SQL request, it is determined that the source of the data and the target of the data to be written are in the same security zone, the data is migrated from the first list to the second list.
13. The apparatus as claimed in claim 12, characterized in that, The device also includes a desensitization module. The desensitization module is used to desensitize the sensitive data according to the first desensitization strategy when it is determined from the SQL request that the source end of the data and the target end to be written are not in the same security zone, and the data includes sensitive data. The migration module is also used to migrate the de-identified data from the first list to the second list.
14. The apparatus according to any one of claims 11-13, characterized in that, The synchronization module is specifically used for: If the first list also includes a second de-identification strategy, and the data migrated to the second list includes sensitive data corresponding to the second de-identification strategy, then the synchronization is determined to have failed. Alternatively, if the second list includes a third desensitization strategy, and the first desensitization strategy conflicts with the third desensitization strategy, then synchronization is determined to have failed. Alternatively, if the second list does not contain a de-identification strategy, then the first de-identification strategy will be synchronized to the second list; Alternatively, if the second list includes a fourth desensitization strategy, and the first desensitization strategy is consistent with the fourth desensitization strategy, then the first desensitization strategy is synchronized to the second list or the synchronization is directly determined to be successful.
15. The apparatus as claimed in claim 14, characterized in that, The device also includes a policy reset module. The policy reset module is used to reset the de-identification policy corresponding to the sensitive data to a mask display policy when synchronization fails. The mask display policy is used to open the mask when querying the sensitive data. Alternatively, terminate the execution of the SQL request and return an error message.
16. The apparatus as claimed in claim 14 or 15, characterized in that, The synchronization module is specifically used for: Log in to the de-identification policy service using an administrator account. The administrator account has write permissions for the de-identification policy. The de-identification policy service is used to store the de-identification policy. If the first desensitization strategy is not present in the desensitization strategy service, the first desensitization strategy is written into the desensitization strategy service.
17. The apparatus according to any one of claims 11-16, characterized in that, The receiving module is specifically used for: Receive a new table statement or an insert statement, wherein the new table statement is used to query sensitive data from the first list and write it into a newly created second list; The insert statement is used to retrieve sensitive data from the first list and write it into the second list to be inserted.
18. The apparatus as claimed in claim 16, characterized in that, The device also includes a comparison module. The comparison module is used to compare the elements of all desensitization strategies in the desensitization strategy service with the elements of the first desensitization strategy one by one. The elements include the content of the desensitization strategy, the field where the sensitive data corresponding to the desensitization strategy is located, and the business object to which the sensitive data applies. If the elements match completely, it is determined that the desensitization strategies are the same.
19. The apparatus as claimed in claim 16 or 18, characterized in that, The synchronization module is also used for: A derivative identifier is added to the first desensitization strategy, and the derivative identifier is used to indicate that the first desensitization strategy is a derivative desensitization strategy; Write the first desensitization strategy, which adds the derived identifier, into the desensitization strategy service.
20. The apparatus as claimed in claim 19, characterized in that, The device also includes a deletion module. The receiving module is also configured to receive an SQL request, the SQL request being used to delete the sensitive data; The deletion module is used to delete the sensitive data from the second list based on the SQL request; Log in to the desensitization policy service using the administrator account, and delete the first desensitization policy with added derivative identifiers from the desensitization policy service.
21. A computing device cluster, characterized in that, The system includes at least one computing device, each computing device including a processor and a memory, wherein the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-10.
22. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1-10.
23. A computer program product containing instructions, characterized in that, When the instruction is executed by a cluster of computer devices, the cluster of computer devices causes the cluster of computer devices to perform the method as described in any one of claims 1-10.
Citation Information
Patent Citations
Hive database dynamic desensitization system and implementation method
CN113343299A
Dynamic database sensitive information desensitization method and system
CN114626087A
Dynamic database sensitive information desensitization method
CN115964745A
Data synchronization and desensitization integration method and device, electronic equipment and storage medium
CN116881276A
Data management method and related system
WO2024040931A1