Method and device for identifying sensitive fields in SQL (Structured Query Language) statement and electronic equipment

Abstract

The invention relates to a method and a device for identifying sensitive fields in SQL (Structured Query Language) statements and electronic equipment. The method comprises the following steps: analyzing an SQL statement to extract all fields in the SQL statement; performing sensitive identification on each field of the SQL statement by utilizing a semantic analysis model and a preset rule base to obtain a corresponding first identification result and a second identification result; under the condition that the first recognition result or the second recognition result of the target field is the sensitive field, the target field is determined to be the sensitive field, and the target field is any field in the SQL statement; and according to the field type of the target field and the query scene, selecting one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field. The technical problems that manual labeling is prone to omission, a desensitization strategy is fixed, and sensitive fields cannot be automatically recognized and dynamically protected according to scenes are solved.

Description

Technical Field

[0001] This application relates to the field of database security and privacy protection, and in particular to a method, apparatus, and electronic device for identifying sensitive fields in SQL statements. Background Technology

[0002] With the development of information technology, databases have become the data storage infrastructure for core business systems across various industries, widely used to store various types of data such as user information, transaction records, contract content, and employee information. A large amount of this data involves personal privacy information, such as ID card numbers, mobile phone numbers, and bank card numbers; it also includes sensitive enterprise-level data, such as employee salaries, cooperation agreement terms, and business operation indicators. As data security compliance requirements continue to increase, how to effectively protect sensitive data while ensuring business availability has become a crucial technical challenge in the database field.

[0003] Current mainstream privacy protection methods typically anonymize sensitive fields during the query results stage, such as replacing the middle part of a phone number with asterisks. However, traditional anonymization schemes generally rely on manual configuration of sensitive fields, usually done by developers or database administrators marking sensitive fields in table structures, comments, or extended attributes. In actual business scenarios, this approach is not only labor-intensive but also prone to errors due to omitted fields, business changes, or the complexity of cross-table joins, leading to the risk of data leakage as sensitive fields are not correctly identified.

[0004] Furthermore, existing data masking solutions often employ fixed strategies, applying a "one-size-fits-all" approach to all query scenarios, failing to dynamically adjust protection levels based on visitor identity, business context, or field type. For example, internal operations personnel might only require weak data masking in report queries, while external interfaces require strict encryption. The lack of context-based dynamic privacy policy selection makes it difficult for traditional solutions to simultaneously meet both flexibility and security requirements. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for identifying sensitive fields in SQL statements, in order to solve the technical problem that manual annotation is prone to omissions and that the desensitization strategy is fixed, making it impossible to automatically identify sensitive fields and dynamically protect them according to the scenario.

[0006] Firstly, this application provides a method for identifying sensitive fields in an SQL statement, comprising: parsing the SQL statement to extract all fields in the SQL statement; using a semantic analysis model and a preset rule base to perform sensitivity identification on each field of the SQL statement, obtaining corresponding first identification results and second identification results; determining the target field as a sensitive field if the first identification result or the second identification result of the target field is a sensitive field, wherein the target field is any field in the SQL statement; and selecting one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field according to the field type and query scenario of the target field.

[0007] Secondly, this application provides a device for identifying sensitive fields in an SQL statement, comprising: an extraction module for parsing the SQL statement to extract all fields in the SQL statement; an identification module for using a semantic analysis model and a preset rule base to perform sensitivity identification on each field of the SQL statement to obtain a corresponding first identification result and a second identification result; a determination module for determining the target field as a sensitive field if the first identification result or the second identification result of the target field is a sensitive field, wherein the target field is any field in the SQL statement; and a processing module for selecting one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field according to the field type and query scenario of the target field.

[0008] As an optional example, the extraction module includes: an analysis unit for performing lexical and syntactic analysis on the SQL statement to convert it into an abstract syntax tree; and an extraction unit for extracting all field information involved in the SQL statement from the abstract syntax tree to obtain all fields in the SQL statement, wherein the field information includes query fields, condition fields, grouping fields, sorting fields, function fields, and subquery fields.

[0009] As an optional example, the above identification module includes: a first processing unit, used to determine the unprocessed field as the current field, and to perform the following processing on the current field: inputting the above SQL statement and the above current field into the above semantic analysis model, so that the above semantic analysis model performs a sensitivity judgment on the above current field according to the contextual semantics of the above current field, and outputs the above first identification result.

[0010] As an optional example, the first processing unit is further configured to perform semantic analysis on the field name of the current field to determine whether the current field belongs to a sensitive field type, and if the current field belongs to a sensitive field type, output the first identification result as a sensitive field; perform semantic analysis on the value of the current field used in the conditional expression to determine whether the current field is a sensitive field under a specific query condition, and if the current field is a sensitive field under a specific query condition, output the first identification result as a sensitive field; and perform semantic analysis on the comment information of the current field in the table or field definition to determine whether the data represented by the current field has sensitive attributes, and if the data represented by the current field has sensitive attributes, output the first identification result as a sensitive field.

[0011] As an optional example, the above identification module includes: a second processing unit, used to determine the unprocessed field as the current field, and to perform the following processing on the current field: according to the field name of the current field, to match it in the preset rule library to determine whether the current field belongs to a manually specified sensitive field category; when the field name matches any sensitive field category in the preset rule library, to output the second identification result as a sensitive field.

[0012] As an optional example, the above processing module includes: a determining unit, used to determine the privacy protection level of the target field based on the field type and query scenario of the target field; and a third processing unit, used to select one or more privacy policies from the preset privacy policy set to perform privacy processing on the target field based on the privacy protection level, wherein the preset privacy policy set includes a full hiding policy, a partial hiding policy, an encryption policy, and an access blocking policy.

[0013] Thirdly, this application provides a storage medium storing a computer program, wherein the computer program is executed by a processor to perform the method for identifying sensitive fields in the aforementioned SQL statement.

[0014] Fourthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the method for identifying sensitive fields in the SQL statement described above through the computer program.

[0015] The technical solutions provided in this application have the following advantages compared with the prior art: This application employs a method of parsing SQL statements to extract all fields; using a semantic analysis model and a preset rule base, sensitivity identification is performed on each field of the SQL statement to obtain corresponding first and second identification results; if either the first or second identification result of the target field indicates it is a sensitive field, then the target field is determined to be a sensitive field, wherein the target field can be any field in the SQL statement; based on the field type and query scenario of the target field, one or more privacy policies are selected from a preset privacy policy set to perform privacy processing on the target field. Because this method involves parsing the SQL statement to extract all fields and using a semantic analysis model and a preset rule base to perform dual sensitivity identification on each field, the sensitive attributes of any field in the SQL can be accurately determined. After identifying the sensitive field, a privacy policy is dynamically selected from the preset privacy policy set based on the field type and query scenario to perform differentiated privacy processing on the sensitive field. This enables the automatic identification of sensitive fields without manual annotation and allows for flexible adjustment of protection levels based on access context. This reduces configuration costs and significantly improves the accuracy and security of sensitive data protection. It also solves the technical problems of easy omissions in manual annotation and fixed desensitization strategies, which prevent the automatic identification of sensitive fields and dynamic protection according to scenarios. Attached Figure Description

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

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

[0018] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0019] Figure 1 This is a flowchart of an optional method for identifying sensitive fields in an SQL statement according to an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an optional SQL statement sensitive field identification device according to an embodiment of this application; Figure 3This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0022] According to a first aspect of the embodiments of this application, a method for identifying sensitive fields in SQL statements is provided, optionally, as follows: Figure 1 As shown, the above method includes: S102, parse the SQL statement to extract all fields from the SQL statement; S104: Using a semantic analysis model and a preset rule base, sensitivity identification is performed on each field of the SQL statement to obtain the corresponding first identification result and second identification result. S106, if the first or second identification result of the target field is a sensitive field, determine the target field as a sensitive field, wherein the target field is any field in the SQL statement; S108, based on the field type of the target field and the query scenario, select one or more privacy policies from the preset privacy policy set to perform privacy processing on the target field.

[0023] Optionally, this embodiment provides a method for identifying sensitive fields in SQL statements, aiming to solve problems in existing technologies such as reliance on manual annotation of sensitive fields, easy omissions, incomplete identification in cross-table join scenarios, and lack of context-based dynamic privacy protection capabilities. By combining SQL statement structure parsing, semantic understanding, and rule base matching, automated identification and dynamic privacy processing of sensitive fields are achieved. Specifically, firstly, the input SQL statement is parsed, converting it into an abstract syntactic structure and extracting all field information involved in the SQL, including query fields, condition fields, sorting fields, and join fields. Through parsing, a complete set of fields can be obtained, and the data table to which it belongs, the logical relationships between fields, and the content of conditional expressions can be extracted, thereby ensuring that the subsequent identification process covers all fields that may be involved in the SQL.

[0024] After field extraction, each field undergoes sensitivity identification using a semantic analysis model and a pre-defined rule base. The semantic analysis model is trained on a large number of business fields, data semantics, and query scenarios. Through semantic vector analysis of field names, conditional expressions, contextual statements, and comment content, it can automatically infer whether a field contains sensitive meanings. For example, sensitive attributes of a field can be inferred from the field names "phone" and "id_number," or from the presence of sensitive words such as "confidential" or "encrypted" in conditional expressions. Simultaneously, the semantic model can identify implicit semantics in field comments or table structure definitions. For instance, when the field name is "base," its comment "social security base" indicates that it belongs to the category of salary-related sensitive information.

[0025] In parallel with the semantic analysis model, a pre-defined rule base is also used to identify fields. The rule base contains manually maintained sensitive field keywords and sensitive category mapping tables, covering common sensitive attributes such as ID card numbers, mobile phone numbers, bank card numbers, home addresses, salaries, and contract terms. If a field name or field context matches a keyword in the rule base, a corresponding secondary identification result is generated. This dual identification mechanism of semantic model and rule base significantly improves the accuracy and coverage of sensitive field identification, avoiding blind spots caused by non-standard field naming, the use of abbreviations, or cross-table joins.

[0026] After obtaining the first and second identification results for each field, it is determined whether any identification result of the target field is a sensitive field. If so, the field is confirmed as a sensitive field. Therefore, it can adapt to various SQL types, including simple queries, nested queries, join queries, multi-table JOIN queries, aggregate queries, and other complex structures, ensuring the comprehensiveness of the sensitivity identification process.

[0027] After identifying sensitive fields, the system further selects one or more privacy protection methods from a preset privacy policy set based on the field type (such as ID card number, mobile phone number, salary amount, etc.) and the query scenario (such as requesting user role, usage scenario, access source), and dynamically processes the target fields for privacy. The privacy policy set may include different strategies such as partial anonymization, complete anonymization, encryption conversion, access restriction, and field replacement. For example, for internal report queries, a partially anonymized mobile phone number (such as "138****5678") can be displayed, while for external interfaces or unauthorized user access, full encryption or direct blocking of query requests can be used. In addition, audit information can be recorded during the policy selection process to facilitate post-event tracking and security compliance checks.

[0028] Through the above steps, this embodiment realizes a complete chain from SQL field parsing and sensitivity identification to dynamic privacy processing, ensuring that sensitive data is flexibly, accurately, and controllably protected in different business scenarios.

[0029] Optionally, this embodiment eliminates the need for manual maintenance of sensitive field configurations. By combining semantic analysis with a rule base, it achieves automatic identification of sensitive fields in SQL, significantly reducing configuration costs and the risk of omissions. It supports dynamic privacy policy selection based on access scenarios, making sensitive data protection more flexible and granular, and can simultaneously meet internal operational needs and strict security compliance requirements. It is applicable to various SQL scenarios and complex query structures, and has the advantages of strong versatility, good scalability, and high identification accuracy.

[0030] As an optional example, the SQL statement is parsed to extract all fields, including: Perform lexical and syntactic analysis on SQL statements to transform them into an abstract syntax tree; Extract all field information involved in the SQL statement from the abstract syntax tree to obtain all fields in the SQL statement. The field information includes query fields, condition fields, grouping fields, sorting fields, function fields, and subquery fields.

[0031] Optionally, in this embodiment, the SQL statement is first subjected to structured parsing to ensure that the subsequent sensitive field identification process has a complete and accurate foundation of field input. Specifically, the parsing of the SQL statement includes steps such as lexical analysis, syntax analysis, and abstract syntax tree construction. First, lexical analysis is performed on the input SQL string, breaking the statement down into basic syntactic units such as keywords, identifiers, operators, and constant values, and generating corresponding lexical symbol sequences. Subsequently, syntax analysis is performed on the lexical symbol sequences, identifying its structural hierarchy according to the syntactic rules of the SQL statement, including SELECT clauses, WHERE conditions, GROUP BY grouping, ORDER BY sorting, and subquery structures, thereby constructing an abstract syntax tree that can fully express the SQL semantics.

[0032] Abstract Syntax Trees (ABSTs), as a structured representation of SQL statements, describe the hierarchical relationships and semantic connections between elements in an SQL statement in a node-based manner. After construction, the ABST is traversed to extract all field information involved in the SQL statement. Field extraction covers various syntactic locations in the SQL, including query fields, condition fields, grouping fields, sorting fields, function fields, and fields appearing in subqueries. For statements containing function calls (such as COUNT, MAX, SUBSTR, etc.), the field parameters inside the function are parsed as function fields and recorded. For nested subquery structures, fields are recursively extracted from the subquery's ABST to ensure complete field extraction. Furthermore, when multi-table JOIN queries are involved, the table prefix before the field is identified to obtain precise information about the table to which the field belongs.

[0033] The above parsing process constructs a complete set of fields for the SQL statement, forming the foundational input data for subsequent sensitive field identification. This field set covers explicit fields, conditional fields, implicit fields, and subquery fields in the SQL statement, effectively avoiding field omissions caused by complex SQL structures, deep field nesting, or function encapsulation. This field parsing method ensures the comprehensiveness and accuracy of field input before sensitive field identification, providing structured support for sensitive field identification in complex business query scenarios, thereby significantly improving the reliability and coverage of automatic identification.

[0034] As an optional example, using a semantic analysis model and a pre-defined rule base, sensitivity identification is performed on each field of the SQL statement, yielding the corresponding first and second identification results, including: The unprocessed field is identified as the current field, and the following processing is performed on the current field: Input the SQL statement and the current field into the semantic analysis model so that the semantic analysis model can make a sensitivity judgment on the current field based on the contextual semantics of the current field and output the first recognition result.

[0035] Optionally, in this embodiment, after completing the full parsing of the SQL fields, it is necessary to identify sensitive attributes for each field to determine whether privacy protection processing is required during the query process. A dual-channel identification mechanism combining a semantic analysis model and a preset rule base is used to accurately determine field sensitivity, significantly improving automatic identification capabilities and coverage. Specifically, unprocessed fields in the field list are first identified as the current fields, and semantic analysis is performed on each current field to generate the first identification result. During semantic analysis, the entire SQL statement and the current field are used as input and fed into a pre-trained semantic analysis model. This model is built on a large-scale business corpus and can semantically understand the context of field names, clauses containing fields, related conditional expressions, table structures, or field comments. For example, when the field name is "phone", "id_number", or "salary", the model can identify that it has sensitive attributes through the semantic tags of the field; when keywords such as "confidential", "authorization", or "certificate" appear in the SQL condition statement, the model can infer that the field may contain sensitive information based on the context in which the field is located; for cases where the field name is not intuitive but contains sensitive meaning, such as the field base indicating that it belongs to the salary category through the annotation "social security base", the semantic model can also make a sensitive judgment by learning the semantics of the annotation.

[0036] Furthermore, the semantic analysis model can also understand how fields are used within the SQL structure. For example, in the query "SELECT * FROM contract WHERE info LIKE '%confidential%'", although the field "info" does not have obvious sensitive characteristics in its name, the model can determine from the semantic association of the condition expression that it involves sensitive business content, thus classifying it as a sensitive field. Through comprehensive analysis of field names, condition values, comment information, and contextual structure, the model ultimately outputs the first identification result for the current field, used to mark whether the field has sensitive attributes.

[0037] The first identification result possesses strong semantic inference capabilities, enabling it to identify implicitly sensitive fields in scenarios such as non-standard field naming, lack of keywords, use of abbreviations, or ambiguous semantic references, providing an intelligent foundation for automated sensitive field identification. In subsequent processes, this result will be used together with the second identification result obtained by matching the rule base to ultimately determine the sensitive fields. The generation process of the first identification result, implemented through a semantic analysis model, significantly improves the accuracy and coverage of sensitive field identification under complex SQL structures, enabling the system to adapt to complex business scenarios such as multi-table joins, nested subqueries, and dynamic field naming, laying a technical foundation for accurate privacy protection.

[0038] As an optional example, the SQL statement and the current field are input into the semantic analysis model, so that the semantic analysis model can perform a sensitivity judgment on the current field based on the contextual semantics of the current field, and output the first recognition result, including: Perform semantic analysis on the field name of the current field to determine whether the current field belongs to a sensitive field type, and if the current field is determined to be a sensitive field type, output the first identification result as a sensitive field; Perform semantic analysis on the value of the current field in the conditional expression to determine whether the current field is a sensitive field under a specific query condition, and if the current field is determined to be a sensitive field under a specific query condition, output the first identification result as a sensitive field; Perform semantic analysis on the annotation information of the current field in the table or field definition to determine whether the data represented by the current field has sensitive attributes. If the data represented by the current field is determined to have sensitive attributes, output the first identification result as a sensitive field.

[0039] Optionally, in this embodiment, the field sensitivity assessment implemented through a semantic analysis model is a crucial step in the entire recognition process. This step involves inputting the entire SQL statement and the current field into an input vector, which is then fed into the semantic analysis model. This allows the model to perform a multi-dimensional, deep semantic comprehensive assessment of the sensitive attributes of the current field based on contextual understanding, ultimately outputting the first recognition result. Specifically, the semantic analysis model assesses the current field from three aspects: field name semantics, conditional expression semantics, and table structure comment semantics, thereby significantly improving the accuracy and coverage of sensitive field identification.

[0040] First, the model performs semantic analysis on the field name of the current field. Field names typically directly reflect the data type or business meaning of the field; for example, field names like "phone," "id_number," "card_no," and "salary" have obvious sensitive attributes. The semantic analysis model analyzes the word vector representation of the field name, combining semantic similarity and domain knowledge graph mechanisms to determine whether the field belongs to a common sensitive field type. If the model determines that the current field name has sensitive features, it directly marks the first identification result as a sensitive field.

[0041] Secondly, the model performs semantic analysis on the values ​​of the current field used in the conditional expression. Some fields may not have obvious sensitive characteristics in their field names, such as "info," "detail," and "content," which are relatively abstract. However, the content they appear in in the query conditions may have implicit sensitive meanings. For example, when the SQL statement contains "WHERE info LIKE '%confidential%'" or "WHERE remark LIKE '%ID card%'," the model can infer that the field involves sensitive data by understanding the semantics of the condition values, and therefore identify it as a sensitive field. Through this context-based semantic inference, implicit sensitive fields that cannot be discovered by traditional field name matching methods can be identified.

[0042] Finally, the model performs semantic analysis on the annotation information in the table structure or field definitions. In actual business scenarios, the field names of some fields may not directly reflect their sensitive meaning, such as the ambiguous names of fields like "base," "code," and "value." However, developers usually explain the purpose of the fields through annotations. For example, "base--social security base" indicates that the field is related to the salary structure and is considered sensitive information. The semantic analysis model can extract the natural language content from the annotations, determine whether the field carries sensitive data through semantic understanding, and output the first identification result as a sensitive field when it is determined to have sensitive attributes.

[0043] In summary, through multi-dimensional analysis of field names, condition values, and annotation semantics, the semantic analysis model can accurately identify explicit and implicit sensitive fields, providing intelligent, comprehensive, and robust technical support for automated sensitive field identification.

[0044] As an optional example, using a semantic analysis model and a pre-defined rule base, sensitivity identification is performed on each field of the SQL statement, yielding the corresponding first and second identification results, including: The unprocessed field is identified as the current field, and the following processing is performed on the current field: Based on the field name of the current field, a match is performed in the preset rule base to determine whether the current field belongs to the manually specified sensitive field category; When a field name matches any sensitive field category in the preset rule base, the second identification result is output as a sensitive field.

[0045] Optionally, in this embodiment, during the rule matching process, a matching judgment is performed in a preset rule base based on the field name. This rule base pre-stores sensitive field categories defined by manual compilation, experience accumulation, or industry compliance requirements, such as name, mobile phone number, ID number, transaction account, and location information. When the current field name matches any sensitive category in the rule base, the second identification result is directly output as the sensitive field. Because the rule base has deterministic and stable coverage characteristics, it can effectively identify sensitive fields with standardized naming conventions or industry-wide commonality. Finally, through comprehensive analysis of the first identification result (semantic model judgment) and the second identification result (rule base matching), high-precision identification of sensitive fields in SQL can be achieved. This embodiment combines the advantages of deep semantic understanding capabilities and rule determinism, enabling the identification of semantically implicit and vaguely named fields while ensuring complete coverage of explicitly sensitive fields.

[0046] As an optional example, depending on the field type of the target field and the query scenario, selecting one or more privacy policies from a preset set of privacy policies to perform privacy processing on the target field includes: Determine the privacy protection level of the target field based on its field type and the query scenario; Based on the privacy protection level, one or more privacy policies are selected from a set of preset privacy policies to perform privacy processing on the target field. The set of preset privacy policies includes full hiding policy, partial hiding policy, encryption policy and access blocking policy.

[0047] Optionally, in database secure access and data anonymization, different types of data fields often have varying degrees of sensitivity and protection requirements under different business scenarios. Therefore, to achieve fine-grained, scenario-based data privacy protection, this embodiment proposes a method for dynamically selecting and processing privacy strategies based on field type and query scenario. This method can adaptively process the target field after completing sensitivity identification in the SQL field, ensuring that sensitive data receives protection commensurate with its risk level under various access scenarios.

[0048] First, based on the target field's field type (e.g., string, numeric, date, structured ID, etc.) and the current SQL query scenario (e.g., display query, statistical query, business calculation query, or internal management query, etc.), the sensitivity of the target field is comprehensively assessed to determine its corresponding privacy protection level. Protection levels can be categorized according to different companies' privacy frameworks, such as low sensitivity, medium sensitivity, high sensitivity, and extremely high sensitivity. The field type determines the data schema and de-identification space for the field, while the query scenario determines whether the original value of the field must be displayed in the current access, thus forming a dynamic sensitivity analysis result.

[0049] After determining the privacy protection level of the target field, one or more privacy policies will be automatically selected from a preset privacy policy set to process the target field according to that level. The preset privacy policy set includes: a full-hiding policy that makes the field content completely invisible (e.g., replacing all with symbols or null values); a partial-hiding policy that retains some information and hides key content (e.g., displaying the first three and last four digits of a phone number, and anonymizing the middle part); an encryption policy that performs encryption transformation on the field (e.g., symmetric encryption, irreversible hashing); and an access blocking policy that directly blocks the output of results for high-risk access. Different policy combinations can be selected according to different levels; for example, a partial-hiding policy can be used for medium-sensitivity fields, an encryption policy can be used for high-sensitivity fields, and an access blocking policy can be directly applied to extremely high-sensitivity fields in unauthorized scenarios.

[0050] Through the aforementioned type- and scenario-based strategy selection mechanism, data anonymization no longer uses fixed templates but possesses dynamic decision-making capabilities, achieving refined privacy protection through "on-demand display." This not only ensures that sensitive data remains secure during transmission and use but also maximizes business availability, thereby enhancing data security and business flexibility.

[0051] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0052] According to another aspect of the embodiments of this application, a device for identifying sensitive fields in SQL statements is also provided, such as... Figure 2 As shown, it includes: Extraction module 202 is used to parse the SQL statement to extract all fields in the SQL statement; The identification module 204 is used to perform sensitivity identification on each field of the SQL statement using a semantic analysis model and a preset rule base, and obtain the corresponding first identification result and second identification result. The determination module 206 is used to determine that the target field is a sensitive field if the first identification result or the second identification result of the target field is a sensitive field, wherein the target field is any field in the SQL statement; The processing module 208 is used to select one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field based on the field type of the target field and the query scenario.

[0053] It should be noted that the extraction module 202 in this embodiment can be used to execute step S102 in this application embodiment, the identification module 204 in this embodiment can be used to execute step S104 in this application embodiment, the determination module 206 in this embodiment can be used to execute step S106 in this application embodiment, and the processing module 208 in this embodiment can be used to execute step S108 in this application embodiment.

[0054] As an optional example, the extraction module includes: The analysis unit is used to perform lexical and syntactic analysis on SQL statements to transform them into an abstract syntax tree; The extraction unit is used to extract all field information involved in the SQL statement from the abstract syntax tree, obtaining all fields in the SQL statement. The field information includes query fields, condition fields, grouping fields, sorting fields, function fields, and subquery fields.

[0055] As an optional example, the recognition module includes: The first processing unit is used to identify the unprocessed field as the current field and perform the following processing on the current field: Input the SQL statement and the current field into the semantic analysis model so that the semantic analysis model can make a sensitivity judgment on the current field based on the contextual semantics of the current field and output the first recognition result.

[0056] As an optional example, the first processing unit is also used to perform semantic analysis on the field name of the current field to determine whether the current field belongs to a sensitive field type, and if the current field is determined to be a sensitive field type, output the first identification result as a sensitive field; Perform semantic analysis on the value of the current field in the conditional expression to determine whether the current field is a sensitive field under a specific query condition, and if the current field is determined to be a sensitive field under a specific query condition, output the first identification result as a sensitive field; Perform semantic analysis on the annotation information of the current field in the table or field definition to determine whether the data represented by the current field has sensitive attributes. If the data represented by the current field is determined to have sensitive attributes, output the first identification result as a sensitive field.

[0057] As an optional example, the recognition module includes: The second processing unit is used to identify the unprocessed field as the current field and perform the following processing on the current field: Based on the field name of the current field, a match is performed in the preset rule base to determine whether the current field belongs to the manually specified sensitive field category; When a field name matches any sensitive field category in the preset rule base, the second identification result is output as a sensitive field.

[0058] As an optional example, the processing module includes: The determination unit is used to determine the privacy protection level of the target field based on the field type and query scenario. The third processing unit is used to select one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field according to the privacy protection level. The preset privacy policy set includes a full hiding policy, a partial hiding policy, an encryption policy, and an access blocking policy.

[0059] For other examples of this embodiment, please refer to the examples above, which will not be repeated here.

[0060] Figure 3 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 3 As shown, it includes a processor 302, a communication interface 304, a memory 306, and a communication bus 308. The processor 302, communication interface 304, and memory 306 communicate with each other via the communication bus 308. Memory 306 is used to store computer programs; When processor 302 executes a computer program stored in memory 306, it performs the following steps: Parse the SQL statement to extract all fields from it; Using a semantic analysis model and a pre-defined rule base, sensitivity identification is performed on each field of the SQL statement to obtain the corresponding first and second identification results. If the first or second identification result of the target field is a sensitive field, the target field is determined to be a sensitive field, where the target field is any field in the SQL statement; Based on the target field's field type and the query scenario, select one or more privacy policies from a preset set of privacy policies to perform privacy processing on the target field.

[0061] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0062] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0063] As an example, the memory 306 described above may include, but is not limited to, the extraction module 202, the identification module 204, the determination module 206, and the processing module 208 in the device for identifying sensitive fields in the SQL statement described above. Furthermore, it may include, but is not limited to, other module units in the device for identifying sensitive fields in the SQL statement described above, which will not be elaborated upon in this example.

[0064] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0065] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0066] Those skilled in the art will understand that Figure 3The structure shown is for illustrative purposes only. The device that implements the method for identifying sensitive fields in the above SQL statement can be a terminal device, such as a smartphone (e.g., Android phone, iOS phone), tablet computer, PDA, mobile Internet Devices (MID), PAD, etc. Figure 3 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 3 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 3 The different configurations shown.

[0067] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, ROM, RAM, disk or optical disk, etc.

[0068] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which, when executed by a processor, performs the steps in the method for identifying sensitive fields in the above-described SQL statement.

[0069] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0070] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0071] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0072] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0073] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

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

[0075] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0076] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for identifying sensitive fields in SQL statements, characterized in that, include: The SQL statement is parsed to extract all fields from it. Using a semantic analysis model and a preset rule base, sensitivity identification is performed on each field of the SQL statement to obtain the corresponding first identification result and second identification result. If the first or second identification result of the target field is a sensitive field, the target field is determined to be a sensitive field, wherein the target field is any field in the SQL statement; Based on the field type of the target field and the query scenario, one or more privacy policies are selected from a preset set of privacy policies to perform privacy processing on the target field.

2. The method according to claim 1, characterized in that, The SQL statement is parsed to extract all fields, including: The SQL statement is subjected to lexical and syntactic analysis to transform it into an abstract syntax tree; Extract all field information involved in the SQL statement from the abstract syntax tree to obtain all fields in the SQL statement, wherein the field information includes query fields, condition fields, grouping fields, sorting fields, function fields, and subquery fields.

3. The method according to claim 1, characterized in that, Using a semantic analysis model and a preset rule base, sensitivity identification is performed on each field of the SQL statement to obtain the corresponding first identification result and second identification result, including: The unprocessed field is identified as the current field, and the following processing is performed on the current field: The SQL statement and the current field are input into the semantic analysis model, so that the semantic analysis model can make a sensitivity judgment on the current field based on the contextual semantics of the current field and output the first recognition result.

4. The method according to claim 3, characterized in that, The SQL statement and the current field are input into the semantic analysis model, so that the semantic analysis model performs a sensitivity judgment on the current field based on the contextual semantics of the current field, and outputs the first recognition result, including: Semantic analysis is performed on the field name of the current field to determine whether the current field belongs to a sensitive field type. If the current field is determined to be a sensitive field type, the first identification result is output as a sensitive field. Semantic analysis is performed on the value of the current field in the conditional expression to determine whether the current field is a sensitive field under a specific query condition. If the current field is determined to be a sensitive field under a specific query condition, the first identification result is output as a sensitive field. Semantic analysis is performed on the annotation information of the current field in the table or field definition to determine whether the data represented by the current field has sensitive attributes. If the data represented by the current field is determined to have sensitive attributes, the first identification result is output as a sensitive field.

5. The method according to claim 1, characterized in that, Using a semantic analysis model and a preset rule base, sensitivity identification is performed on each field of the SQL statement to obtain the corresponding first identification result and second identification result, including: The unprocessed field is identified as the current field, and the following processing is performed on the current field: Based on the field name of the current field, a match is performed in the preset rule base to determine whether the current field belongs to a manually specified sensitive field category; When the field name matches any sensitive field category in the preset rule base, the second identification result is output as a sensitive field.

6. The method according to any one of claims 1 to 5, characterized in that, Based on the field type of the target field and the query scenario, selecting one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field includes: The privacy protection level of the target field is determined based on the field type and query scenario. Based on the privacy protection level, one or more privacy policies are selected from the preset privacy policy set to perform privacy processing on the target field, wherein the preset privacy policy set includes a full hiding policy, a partial hiding policy, an encryption policy, and an access blocking policy.

7. A device for identifying sensitive fields in an SQL statement, characterized in that, include: The extraction module is used to parse the SQL statement to extract all fields from the SQL statement; The identification module is used to perform sensitivity identification on each field of the SQL statement using a semantic analysis model and a preset rule base, and obtain the corresponding first identification result and second identification result. The determination module is used to determine that the target field is a sensitive field if the first identification result or the second identification result of the target field is a sensitive field, wherein the target field is any field in the SQL statement; The processing module is used to select one or more privacy policies from a preset privacy policy set to perform privacy processing on the target field based on the field type and query scenario of the target field.

8. The apparatus according to claim 7, characterized in that, The extraction module includes: The analysis unit is used to perform lexical and syntactic analysis on the SQL statement to convert it into an abstract syntax tree; The extraction unit is used to extract all field information involved in the SQL statement from the abstract syntax tree, thereby obtaining all fields in the SQL statement. The field information includes query fields, condition fields, grouping fields, sorting fields, function fields, and subquery fields.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method described in any one of claims 1 to 6.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 6 through the computer program.

Images