Data desensitization and access control method based on data consanguinity and sensitivity identification

Abstract

The invention relates to the technical field of network security, and discloses a data desensitization and access control method based on data consanguinity and sensitivity identification, which comprises the following steps of: constructing a data consanguinity graph for describing derivation, circulation and dependency relationships among fields; identifying a sensitivity level of each field based on a field consanguinity context provided by the graph; in response to a data access request of a user, dynamically generating an access control strategy for the target field in combination with a service scene, a user role and the sensitivity level of the target field, the strategy specifying access permission, access denial or access after desensitization; and executing the strategy through a data interceptor deployed in a data access key layer, releasing and shielding the data or outputting the data after real-time desensitization by calling a specified algorithm. According to the invention, accurate identification and dynamic and consistent fine-grained access control of the sensitivity of the network data are realized, and the security protection capability of the network data is improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically a data desensitization and access control method based on data lineage and sensitivity identification. Background Technology

[0002] In the field of network data security, ensuring the secure sharing and controlled use of sensitive data in complex network environments and diverse business scenarios is a key challenge. Current common network data anonymization and access control technologies largely rely on static sensitive data identifiers and pre-configured fixed policy rules. This approach is ill-suited to the reality of continuous data flow and frequent changes in network environments. For derivative data that flows between systems through network interfaces and undergoes complex processing, its sensitivity is difficult to accurately assess and continuously track, leading to lagging and inaccurate security policies. Furthermore, static policies cannot be dynamically adjusted based on real-time network access request contexts (such as request source, business scenario, and user role), easily resulting in over-allocation of permissions or insufficient access control. In addition, the lack of a global perspective on the data flow path in the network leads to inconsistent security policies for the same data entity across different network nodes, creating security vulnerabilities and affecting the efficiency of cross-business data collaboration. Therefore, there is an urgent need for a network data security technology that can understand the inherent relationships and flow patterns of network data and implement precise, dynamic, and consistent security management accordingly. Summary of the Invention

[0003] The purpose of this application is to provide a data desensitization and access control method based on data lineage and sensitivity identification, so as to solve the technical problems mentioned in the background art.

[0004] To achieve the above objectives, this application discloses the following technical solution: a data desensitization and access control method based on data lineage and sensitivity identification, comprising the following steps: Construct a data lineage graph, which is used to describe the derivation, flow, and dependency relationships between fields in a data entity; Based on the kinship context of the fields provided by the data kinship diagram, the sensitivity level of each field in the data kinship diagram is identified; In response to a user's data access request, an access control policy is dynamically generated for the target field based on the business scenario, user role, and sensitivity level of the target field to be accessed. The access control policy specifies whether to allow access, deny access, or allow access after de-identification using a specified de-identification algorithm for the target field. The access control policy is executed by a data interceptor deployed in the database driver layer, application programming interface gateway layer, or application data access layer: if the access control policy allows access, the original data of the target field is allowed; if the access control policy denies access, the data of the target field is blocked; if the access control policy requires access after de-identification, the data interceptor calls the specified de-identification algorithm to perform real-time calculation and replacement of the data content of the target field.

[0005] Optionally, constructing the data lineage diagram includes: The system analyzes application scripts, task logs, and database operation statements in the data processing system to explore and record data flow and data transformation logic at the field level in order to generate and update the data lineage diagram.

[0006] Optionally, the sensitivity level of the field identified based on the data lineage diagram includes: For a derived field in the data lineage graph, trace its lineage back to one or more original fields from which it originated; The sensitivity level of the original field is obtained, and the sensitivity level of the derived field is determined by combining the data transformation logic recorded in the lineage link.

[0007] Optionally, the data lineage diagram also records the data transformation functions that the fields undergo during the transfer process; The determination of the sensitivity level of the derived field includes: lowering the sensitivity level of the derived field based on the irreversibility of the data transformation function.

[0008] Optionally, determining the sensitivity level of the derived field by combining the data transformation logic recorded in the bloodline link includes: If the data transformation logic is an aggregation calculation or statistical operation on multiple native field values, then it is determined that the sensitivity level of the derived field is lower than the highest sensitivity level of the native field it depends on. If the data transformation logic is a direct mapping of a highly sensitive native field or a concatenation operation containing its key information, then it is determined that the derived field inherits or retains the sensitivity level of the highly sensitive native field.

[0009] Optionally, the method further includes: Based on historical access records and the data lineage diagram, analyze the access patterns of different user roles to the set of fields with derivative relationships; Based on the access pattern, the sensitivity level determination result for derived fields in the field set is dynamically calibrated.

[0010] Optionally, the dynamically generated access control policy includes: Query the data lineage graph to obtain the lineage context of the target field; The business scenario, user role, sensitivity level of target field and its lineage context are taken as input, and the access control policy containing specific control actions and parameters is output by calculating through preset policy rules.

[0011] Optionally, when the control action calculated and output by the preset strategy rules is to access the target field after desensitization, the lineage context is used to determine whether there are other related fields that originate from the same original data entity as the target field; if so, a desensitization algorithm with logical correlation is configured for the target field and the other related fields.

[0012] Optionally, the dynamically generated access control policy further includes: Based on the data lineage diagram, analyze the complete data flow path corresponding to the data access request for the target field; The potential risk level of the access request is assessed based on the number and sensitivity level of upstream sensitive data entities involved in the complete data flow path. Based on the potential risk level, the access control policy for the calculated output is enhanced or downgraded.

[0013] Optionally, the method further includes: Collect audit logs of the data interceptor's execution of access control policies; Based on the audit logs, optimize the method for determining the impact of data transformation logic on the sensitivity level of each field in the data lineage diagram, or optimize the dynamic generation logic of the access control policy.

[0014] Beneficial Effects: This application's data desensitization and access control method based on data lineage and sensitivity identification constructs a cross-network system data lineage graph, enabling analysis of data flow and derivation paths between network nodes. Sensitivity identification based on this networked lineage context accurately assesses the sensitivity status of data at each stage of network flow, particularly derived data. By integrating the contextual information of network access requests with the dynamic sensitivity of fields, precise access control and desensitization policies are generated in real time and executed by data interceptors deployed at key network nodes, achieving an upgrade of network security policies from static configuration to intelligent dynamic response. This method improves the coverage and accuracy of sensitive data identification in the network environment, strengthens continuous security protection for data throughout the entire network flow chain, and effectively reduces the risk of data leakage due to policy oversights by ensuring policy consistency across network nodes, while maintaining data availability in networked services. Attached Figure Description

[0015] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating the data desensitization and access control method based on data lineage and sensitivity identification provided in this application embodiment. Detailed Implementation

[0017] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0018] In current network data security practices, the protection of sensitive data primarily relies on two fundamental technologies: data anonymization and access control. A typical technical approach involves data administrators or security operations personnel manually labeling specific fields in the database with static sensitive tags, such as "Personal Sensitive Information (PII)," based on the data's content characteristics (e.g., whether field names contain keywords like "ID card" or "phone number"). Simultaneously, a set of fixed access control rules is predefined around these static tags, combined with user roles (e.g., "data analyst" or "customer service personnel"), for example, "Allow data analysts to access the anonymized PII field." This technical model was adequate in early application environments characterized by networking and low data mobility.

[0019] However, as enterprises deepen their digital transformation, data flows, is shared, and processed at high frequency between networked business systems, highlighting the limitations of the aforementioned static technical model. These limitations manifest in three main ways: First, at the level of sensitive data identification, static labeling cannot trace or adapt to the dynamic derivation process of data. In a network environment, raw sensitive data (such as user ID numbers) serves as input and, through a series of cross-system ETL jobs, API calls, or analytical models, generates a large number of derived data fields. For example, ID numbers may be used to generate aggregated statistical fields such as age segments and geographical distribution, or they may be combined with other fields to form new business identifiers. Existing static labeling methods can only cover the initial, known sensitive fields. For these derived fields that have evolved in the data flow network and whose semantics and form have changed, their sensitivity is difficult to identify automatically and accurately. Security administrators often face a dilemma: either overprotect, treating all derived fields as highly sensitive, thus compromising data utility; or underprotect, omitting truly sensitive derived fields and creating security blind spots.

[0020] Secondly, regarding the adaptability of access control policies, statically pre-defined rules cannot fully respond to dynamically changing network access contexts. The security sensitivity of a specific data access request depends not only on the data itself and the user's role, but also on the specific business scenario and network access path in which the request occurs. For example, the access permission requirements for the same customer mobile phone number data may differ depending on whether the user is using internal business reporting or external data collaboration. Existing static rule systems lack the ability to perceive and integrate such real-time, fine-grained contexts, leading to lagging and rigid policy adjustments. This results in either overly broad authorization when strict control is needed, or overly strict restrictions when flexible use is required.

[0021] Finally, regarding the consistency of security strategies, due to the lack of a global lineage perspective on data throughout the entire network flow path, anonymization and access control strategies for the same data often operate independently and fragmentedly across different business systems or network nodes. For example, the "customer mobile phone number field" in the core user system might be configured with partial anonymization, while the "customer contact information field" derived from this field and synchronized to the downstream marketing system might be configured with completely different and unrelated anonymization algorithms. This inconsistency not only risks indirect information leakage due to more lenient downstream policies, compromising the overall security defenses, but also prevents the anonymized data from being effectively correlated in networked joint analysis, thus damaging the business value of the data.

[0022] This embodiment addresses one or more of the above-mentioned technical problems by providing a new network data security technology that can break through the static perspective, gain insight into the inherent connections in the networked flow of data, and thereby achieve intelligent sensitivity identification and dynamic coordination of security strategies to meet the challenges mentioned above.

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present application. Secondly, in this document, the term "including" is intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements, but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0024] This embodiment presents a data desensitization and access control method based on data lineage and sensitivity identification, such as... Figure 1 As shown, the method includes the following steps in sequence: S1 - Construct a data lineage diagram, which is used to describe the derivation, flow, and dependency relationships between fields in a data entity.

[0025] S2 - Based on the field lineage context provided by the data lineage diagram, identify the sensitivity level of each field in the data lineage diagram.

[0026] S3 responds to user data access requests by dynamically generating access control policies for target fields based on the business scenario, user role, and sensitivity level of the target field requested. The access control policy specifies whether to allow access, deny access, or allow access after de-identification using a specified de-identification algorithm for the target field.

[0027] S4 enforces access control policies through data interceptors deployed in the database driver layer, application programming interface gateway layer, or application data access layer: if the access control policy allows access, the original data of the target field is allowed; if the access control policy denies access, the data of the target field is blocked; if the access control policy requires access after de-identification, the data interceptor calls the specified de-identification algorithm to perform real-time calculation and replacement of the data content of the target field.

[0028] Specifically, a data lineage graph is a directed graph structure where nodes represent specific fields in data entities (such as tables, views, and files), and directed edges represent data flow and derivative relationships between fields. Data lineage graphs can be constructed by parsing metadata such as SQL logs, ETL task configurations, and API call chains.

[0029] Field lineage context refers to the position of the target field in the graph, its upstream source field set, and the sequence of data transformation operations that connect these fields.

[0030] The process of identifying sensitivity levels is as follows: First, the original fields (i.e., fields without upstream sources) are identified. This can be done by matching the field name, annotations, or sample data with a pre-set sensitive keyword database to assign an initial sensitivity level (such as high, medium, low, or non-sensitive). For derived fields, their identification needs to be combined with the sensitivity of their upstream fields and the transformation logic.

[0031] Business scenarios can be extracted from the URL path of the access request, HTTP header information, or application context, such as "data analysis," "external audit," or "customer service."

[0032] User roles are obtained from user authentication tokens or session information.

[0033] Dynamically generated access control policies refer to the process of calculating a decision on each target field in a data access request in real time based on the aforementioned multi-dimensional information.

[0034] A data interceptor is a software middleware injected into the critical path of data access. For example, in the database driver layer, it can be a proxy driver that implements the JDBC or ODBC interface specification; in the application programming interface gateway layer, it can be an HTTP request / response filter or plugin. When the data query results are returned from the database, or the API is preparing to respond, the data interceptor intervenes and, based on the access control policy generated in real time for each field, performs real-time transformations on the data, such as allowing access, replacing null values ​​with empty / null values, or calling the corresponding de-identification algorithm function (e.g., hashing, masking, generalization), before outputting the data.

[0035] Furthermore, it should be noted that any data collected and processed during the implementation of this method must be done under the premise of obtaining explicit authorization from the relevant data subject or on other legal grounds as stipulated by laws and regulations.

[0036] Based on the above, constructing a global data lineage graph provides a foundation for understanding the source and destination of data within the network. Sensitivity identification based on lineage transforms risk assessment of derived data from isolated guesses into evidence-based inferences. Combining dynamically identified sensitivities with real-time access context to generate policies, and executing these policies through low-level interceptors, achieves synchronization between security policies and data flow. This enables network security protection to shift from a predictive model based on fixed rules to a real-time response model based on contextual intelligence. This further enhances the ability to discover and control sensitive information in network flows, especially in derived data, achieving fine-grained, scenario-based dynamic access control and ensuring the synchronization of policy execution and data access.

[0037] Traditional data lineage discovery often relies on manual annotation or simple data dependency analysis, making it difficult to automate and accurately obtain detailed flow and transformation logic at the field level. This results in a lineage diagram that is not refined enough to support subsequent accurate sensitivity determination. As an optional implementation method in this embodiment, constructing a data lineage diagram includes: The system analyzes application scripts, task logs, and database operation statements in the data processing system to explore and record data flow and data transformation logic at the field level in order to generate and update data lineage diagrams.

[0038] Specifically, this step is accomplished using automated tools.

[0039] Parsing application scripts refers to performing static syntax analysis on stored procedures, ETL job scripts (such as transformation definitions in Informatica, DataStage, and Kettle), and data processing code in Spark or Flink to extract the mapping relationships between source and target table fields and the function transformation logic.

[0040] Parsing task logs refers to collecting and analyzing the execution logs generated during the execution of the above-mentioned jobs, and capturing the actual read and write records of data tables and fields.

[0041] Parsing database operation statements refers to monitoring and parsing the SQL statements (such as SELECT, INSERT, CREATE TABLE AS SELECT, etc.) sent to the database by the application. The SQL parser decomposes them into an abstract syntax tree, thereby identifying the projection, association, aggregation and other relationships between fields.

[0042] Exploration and logging refers to associating and integrating the above analysis results to form a unified metadata repository. For example, by analyzing an SQL statement like "CREATE TABLE user_summary AS SELECT user_id,SUBSTR(id_card,1,6) AS region_code,COUNT(order_id) FROM ... GROUP BY ...", we can establish the relationship that the "user_summary.region_code" field originates from the first 6 characters of the "id_card" field in the source table, and the "user_summary.order_count" field is obtained by aggregating the counts of "order_id". These relationships are persistently stored in a graph database or relational database, forming a queryable and traversable data lineage graph, and are continuously updated with the execution of new scripts and the generation of logs.

[0043] Based on the above, the automated collection and intelligent parsing of multi-source heterogeneous metadata replaces the high-cost and inefficient manual data lineage analysis. It accurately depicts the complete field-level transformation path of data from source to end in the networked processing flow. This provides indispensable, high-quality foundational data for achieving sensitivity propagation judgment and policy consistency control based on precise transformation logic.

[0044] Static sensitivity labeling cannot handle data derivation issues. When a field is generated from other fields through calculation, its sensitivity needs to be scientifically inferred based on the source data and calculation method; otherwise, misjudgment will occur. As an optional implementation method in this embodiment, the sensitivity level of a field identified based on a data lineage diagram includes: For a derived field in a data lineage graph, trace its lineage back to one or more original fields from which it originated; Obtain the sensitivity level of the original field and, in conjunction with the data transformation logic recorded in the lineage chain, determine the sensitivity level of the derived field.

[0045] Specifically, the identification process begins with a derived field to be determined (such as "Average Regional Income" in a report). In this step, a reverse breadth-first or depth-first traversal is performed by traversing the incoming edges of this field in the data lineage graph until all nodes with no more incoming edges are found; these nodes are the original fields (such as "Annual Personal Income" and "Regional Residence" in the original data table). The sensitivity levels of these original fields have already been assigned during the initial scan (e.g., "Annual Personal Income" is "High Sensitivity," and "Regional Residence" is "Low Sensitivity"). Combining this with the data transformation logic recorded in the lineage chain refers to analyzing all operations recorded along the path from the original field to the derived field. For example, the transformation logic might be recorded as: "AVG(Annual Personal Income) GROUP BY Regional Residence." The core of the determination logic lies in evaluating the "dilution" or "concentration" effect of this transformation on the original information entropy. A feasible determination method can be quantified using a comprehensive formula: Set derived field sensitivity By what it depends Sensitivity of each native field (Can be quantified into numerical values, such as high = 3, medium = 2, low = 1, non = 0, and) for The first of the original fields Sensitivity of each native field ) and its transformation function Jointly determined. Define the influence factor of the transformation function. This value (between 0 and 1, where 1 represents complete retention of sensitive information) is used to characterize the degree to which the transformation weakens the confidentiality of the information. It can be calculated as: , in, The function represents the highest sensitivity among all source raw fields, because the most sensitive information component determines the lower limit of security requirements for the entire derived data. Impact Factor The assignment rules are based on the type of the conversion logic. According to the calculated... The numerical values ​​are mapped back to levels such as "high," "medium," "low," and "non-sensitive." In practical applications, the impact factor... The specific value can be preset by expert experience or obtained by training historical labeled data through machine learning models. This application does not limit this.

[0046] Based on the above, this method simulates the propagation and attenuation effects of sensitive information during data processing. By tracing the lineage back to the source, the traceability of risk assessment is ensured; by quantitatively analyzing the impact of transformation logic, objectivity and interpretability of the judgment are achieved. Furthermore, it can automatically and accurately classify the sensitivity of massive, dynamically generated derivative data, solving the core pain point that static methods cannot cover derivative data, and providing precise input for subsequent dynamic strategy generation.

[0047] In determining the sensitivity of derived data, quantifying the specific impact of transformation logic on sensitivity requires more refined and operable rules, especially for irreversible data transformation operations, where the degree of risk reduction should be clearly demonstrated. As a further optional implementation method in this embodiment, the data lineage graph also records the data transformation functions that fields undergo during the flow process; Determining the sensitivity level of derived fields includes: lowering the sensitivity level of derived fields based on the irreversibility of the data transformation function.

[0048] Specifically, data transformation functions refer to the specific operations recorded in the lineage chain, such as HASH(), MD5(), AES_ENCRYPT(), SUBSTR(), ROUND(), AVG(), etc.

[0049] Irreversibility refers to the difficulty of reversing the original input data from the output of a data transformation function. This can be achieved by querying a predefined list that records the classification and irreversibility weights of transformation functions. This is achieved through a mapping table. For example: ①Irreversible Close to 0): Secure cryptographic hash functions (such as SHA-256) and encryption functions using unknown keys. These functions are virtually impossible to reverse engineer, posing an extremely low risk of information leakage.

[0050] ②Medium irreversible / weakening ( Approximately 0.2-0.5): masking (such as SUBSTR(id_card,1,6)), rounding, and date generalization to year and month. These functions lose some information, making reverse engineering difficult but not impossible.

[0051] ③ Reversible or information-preserving ( Approaching 1): Direct mapping (such as CAST(income AS DOUBLE)), field renaming, and row-level filtering. These operations do not change the sensitive nature of the data.

[0052] In practical applications, irreversible weights The specific values ​​assigned can be adjusted according to industry safety standards and practices, and the embodiments in this application do not limit this. Based on this, the aforementioned impact factors It can be directly associated or partially based on this irreversible weight. Perform calculations. One way is to... Set as ,Right now When the transition function is strongly irreversible, According to the formula , This will approach 0, thus lowering the sensitivity level. For links involving multiple transformation operations, each step can be taken... The product of values, or based on the most critical ( The step of minimizing the value is used to determine the overall irreversible impact.

[0053] Based on the above, this approach introduces the concept of "irreversibility" from cryptography and information theory into data security grading, providing an objective and calculable technical dimension for sensitivity assessment. This allows for more refined sensitivity assessment. For example, for a hashed ID number field, its sensitivity can be automatically adjusted from "high" to "low" or "non-sensitive," thus allowing the secure use of the derived data in more business scenarios and releasing data value while ensuring security.

[0054] It is necessary to clarify the qualitative rules governing the impact of common data transformation logic (such as aggregation and concatenation) on sensitivity, so that the automatic judgment process has a clear and reasonable basis and avoids arbitrariness. As a further optional implementation method of this embodiment, the sensitivity level of derived fields is determined by combining the data transformation logic recorded in the lineage chain, including: If the data transformation logic is an aggregation calculation or statistical operation on the values ​​of multiple native fields, then the sensitivity level of the derived field is determined to be lower than the highest sensitivity level of the native field it depends on. If the data transformation logic is a direct mapping of the highly sensitive native field or a concatenation operation containing its key information, then the derived field is determined to inherit or maintain the sensitivity level of the highly sensitive native field.

[0055] Specifically, aggregation calculations or statistical operations include, but are not limited to, operations such as SUM(), AVG(), COUNT(), MAX(), MIN(), and STDDEV() applied to a set of data. The essence of these operations is to extract group characteristics from individual data, losing information strongly correlated with specific individuals, thus diluting sensitive information. For example, aggregating "department average salary" from the "individual salary" field of thousands of employees cannot infer the salary of any specific employee; its sensitivity should be lower than that of "individual salary".

[0056] Within the framework of the aforementioned "sensitivity level identification of fields based on data lineage diagrams" and the data transformation functions that record fields undergo during the process of data transfer, this corresponds to assigning a smaller sensitivity level to aggregation functions. or value.

[0057] Direct mapping refers to the transfer of fields without any substantial transformation, such as A=B.

[0058] Operations that concatenate key information, such as combining `name` and `id_card` into `full_info`, or combining specific bits of `id_card` with other fields, completely preserve or reassemble the original highly sensitive information, thus not reducing the risk. When making judgments, derived fields should inherit the sensitivity level of their source's original highly sensitive field. This rule can be integrated into... In the calculation formula, for aggregation operations, Take the smaller value (e.g., 0.1); for direct mapping or key concatenation, The value is 1.

[0059] Based on the above, domain knowledge (aggregation reduces risk, mapping maintains risk) is formalized into specific, automatically executable judgment rules. This provides clear, consistent, and security-aware sensitivity propagation guidelines for the two most common data transformation scenarios, ensuring the rationality and acceptability of the automatic judgment output and reducing misjudgments.

[0060] Initial sensitivity assessment rules may not fully cover all complex scenarios, requiring a mechanism to provide feedback and optimization based on actual network access behavior data, making the assessment results more aligned with business realities and security posture. As a further optional implementation of this embodiment, the method also includes: Based on historical access records and data lineage diagrams, we analyze the access patterns of different user roles to sets of fields with derivative relationships. Based on the access pattern, dynamically calibrate the sensitivity level determination results for derived fields in the field set.

[0061] Specifically, this method continuously collects and stores audit logs generated by the data interceptor. The logs include the time of each access, user role, target field, executed strategy (allow / deny / de-identify), and contextual information. Simultaneously, it utilizes a data lineage graph to construct a set of fields with derivative relationships (e.g., a native field and all its direct and indirect derived fields).

[0062] An analysis process can be performed periodically (e.g., daily). This analysis, tailored to each user role (e.g., "Data Analyst," "Auditor"), tracks the frequency of access to each field within a given set of fields, the number of times access was denied, and the strength of the anonymization algorithm when access was successful. Access patterns might reveal that a derived field automatically classified as "moderately sensitive" is almost never directly accessed by the "Data Analyst" role, while they frequently access its aggregated, less sensitive parent fields, potentially indicating that the current classification is too lenient. Conversely, if a field classified as "lowly sensitive" is frequently accessed and often accompanied by strong anonymization, it might suggest that the current classification is too strict.

[0063] The calibration process can be performed based on a pre-defined heuristic rule or a lightweight feedback model. For example, a calibration factor can be defined. Initially set to 1. For a given derived field, if its access denial rate exceeds a certain threshold... Then increase its sensitivity ( If a high percentage of users are allowed weak desensitization or direct access without any security incidents, then reducing its sensitivity may be considered. Ultimately, the sensitivity of this derived field after calibration. ,in This is the original judgment result. The calibrated result will serve as the basis for policy generation for a subsequent period. In practical applications, the threshold... Sum of coefficients , This can be set by the security administrator according to their risk preferences; however, this embodiment does not limit this setting.

[0064] Based on the above, a feedback loop based on actual access behavior combines theoretical inference with practical verification. This enables sensitivity identification to continuously learn and adaptively optimize, gradually approaching the judgment criteria that best suit the organization's specific business model and security requirements, thus improving the practicality and accuracy of the entire method.

[0065] Efficiently and organically integrating multi-dimensional information such as business scenarios, user roles, dynamic sensitivity, and lineage context to output a clear and executable access control decision requires a well-defined computational framework. As an optional implementation method in this embodiment, dynamically generating access control policies includes: Query the bloodline graph to obtain the bloodline context of the target field; The system takes business scenarios, user roles, sensitivity levels of target fields, and their lineage context as input, calculates them using preset policy rules, and outputs access control policies that include specific control actions and parameters.

[0066] Specifically, when a data access request arrives, the target field is first parsed. The data lineage graph is queried, and the obtained lineage context includes not only its upstream source but also its downstream derived fields (optional) and other related fields from the same source. The pre-defined policy rules can be a set of "condition-action rules," a decision tree, a decision table, or a trained lightweight classification model. The core of the calculation process is mapping multi-dimensional input features to a discrete decision space (allow, deny, anonymize) and corresponding parameters (such as anonymization algorithm identifiers). An innovative policy calculation method can be designed as a multi-factor weighted decision function. Let the decision value be... It is determined by the following factors: ①Scenario risk coefficient Based on the pre-set business scenario (e.g., "high external audit risk"), Large; "Internal development and testing have low risk." Small).

[0067] ② Character Trust Based on user role presets (e.g., "Security Administrator, high trust level"), Large; "Low trust level among outsourced personnel," Small).

[0068] ③ Field sensitivity This refers to the quantified value of the sensitivity level of the target field.

[0069] ④ Bloodline risk enhancement factor : Based on lineage context calculations, for example, if a target field has a large number of downstream derived fields that are widely used, the impact of leakage is significant. The value increases.

[0070] The decision value can then be calculated as follows: , in, The weighting coefficients for each factor reflect the organization's emphasis on different risk dimensions. This method presets two thresholds. and ( ).like If so, the output will be "Access allowed; if..." If so, the output will be "Access denied; if..." The output will be "Access after desensitization, and according to..." The range in which the value falls is then used to select a corresponding desensitization algorithm (such as strong desensitization or weak desensitization). The specific control action is "allow," "deny," or "desensitize"; the parameter is the identifier of the selected desensitization algorithm. In practical applications, the weights and thresholds can be adjusted through the security policy configuration console, and this application embodiment does not limit this.

[0071] Based on the above, multi-source and heterogeneous contextual information is uniformly quantified and fused through a configurable computational model to form a comprehensive risk / trust assessment score, which is then used to make hierarchical decisions. This enables the intelligent, dynamic, and refined generation of access control policies, flexibly responding to various complex network access scenarios and ensuring the accuracy of security control.

[0072] When deciding to anonymize data, if completely independent and unrelated anonymization methods are used for different fields derived from the same data source, the anonymized data may lose its correlation, failing to support cross-field correlation analysis and impairing data availability in networked services. As a further optional implementation of this embodiment, when the control action calculated and output through preset policy rules is to access the data after anonymization, the system determines, based on the lineage context, whether there are other related fields originating from the same original data entity as the target field; if so, an anonymization algorithm with logical correlation is configured for the target field and other related fields.

[0073] Specifically, when generating a de-identification strategy for a target field, the strategy engine uses the acquired lineage context to find other fields in the data lineage graph that share the same "root native field" as the current target field. For example, if the target field is `report.customer_region` (customer region, derived from the first 6 digits of the ID card number), the lineage graph reveals that within the same business line, there is also a field called `marketing.masked_id` (masked ID card number, retaining the last 4 digits). Both fields originate from the same original ID card number field. These two fields are "other related fields originating from the same native data entity." Configuring a de-identification algorithm with logical relationships refers to selecting a set of mathematically or logically coordinated de-identification methods for these related fields, ensuring that the de-identified data still maintains the relationships required by the business. For example, to support the analysis of customer counts by region, it is necessary to ensure that customer_region and masked_id from the same ID card can still be correctly associated after de-identification. One implementation is to use "consistent de-identification" or "associative de-identification" technology, which can generate a unique, irreversible token for this common original data entity (such as the original ID card number), such as T=HASH_K(id_card), where HASH_K is a hash function with a salt value. Then, for the customer_region field, the de-identification algorithm is SUBSTR(T,1,6) (although a substring of T is used here to replace the region code, this is only an example and may require mapping in practice); for the masked_id field, the de-identification algorithm is CONCAT('*****',SUBSTR(T,-4,4)). In this way, although the original data is de-identified, the two de-identified fields derived from the same T can still maintain consistency in subsequent association analysis. In practical applications, more complex association de-identification can also be achieved using cryptographic primitives such as homomorphic encryption and deterministic encryption, which are not limited in this embodiment.

[0074] Based on the above, the data lineage is expanded from a simple risk tracing chain to a coordinating link ensuring the consistency of data utility. At the anonymization decision point, not only individual fields are considered, but also their "siblings" in the lineage network, and their anonymization methods are coordinated. Thus, while strictly implementing data anonymization requirements, the business availability and analytical value of data are maintained after it flows across networked systems and scenarios, resolving the contradiction between security and utilization.

[0075] The sensitivity of a single target field may not fully reflect the overall risk of an access request, especially when the access indirectly touches a large amount of sensitive upstream data through an API or complex query. In such cases, a risk assessment from a more macro-level access path perspective is needed. As a further optional implementation of this embodiment, dynamically generating access control policies also includes: Based on the data lineage diagram, analyze the complete data flow path corresponding to the data access request for the target field; Assess the potential risk level of access requests based on the number and sensitivity level of upstream sensitive data entities involved in the complete data flow path; Based on the potential risk level, the access control policy for the computation output is enhanced or downgraded.

[0076] Specifically, when a request is made to access a target field (which may be a highly summarized field), the data lineage graph is not only searched for its direct source, but also recursively expanded upstream until all the most upstream original data entities (such as tables and files) are found, and sensitive entities within them are marked. Analyzing the complete data flow path means identifying all possible data flow and processing paths from these sensitive source data entities to the target field. Assessing the potential risk level. When doing so, the following factors can be considered: the total number of sensitive source entities touched. The average sensitivity metric of these entities And the complexity of the path (such as the number of systems traversed). An exemplary risk assessment formula can be designed as follows: , The logarithmic function is used here to prevent the risk value from inflating excessively when the number of entities involved is too large. Ensure when hour .get Then, it can be used as a new factor in the decision function, or directly used to adjust the initial strategy. For example, let the initial strategy decision value (through...) )for Final decision value ,in This is a path risk adjustment factor. If... Very high, which may lead to decision value The risk level is raised from the original "desensitization zone" to the "rejection zone," thus strengthening the policy (i.e., making it more stringent). Conversely, for access from highly trusted internal systems with clear pathways, the risk value may be appropriately lowered, resulting in a more lenient policy. In practical applications, risk assessment formulas and adjustment coefficients... It can be customized according to the organization's security audit requirements, but this application does not limit this.

[0077] Based on the above, by conducting in-depth risk assessment of access paths, the security of a single field is extended to the security of the entire data access chain. Even accessing seemingly harmless aggregated data may be linked to massive amounts of original sensitive data, thus requiring a reassessment of the risk. This effectively identifies and prevents data probing behaviors that attempt to obtain original sensitive data indirectly or through other means, enhancing the depth and proactivity of network data security protection.

[0078] Dynamically generated strategies and sensitivity determination rules need to be continuously optimized to adapt to changing business models, new data assets, and potential new threats. As an optional implementation of this embodiment, the method further includes: Collect audit logs of data interceptors executing access control policies; Based on audit logs, optimize the method for determining the impact of data transformation logic on the sensitivity level of each field in the data lineage diagram, or optimize the dynamic generation logic of access control policies.

[0079] Specifically, establish a centralized audit log library to record all data access events, their context, and policy execution results.

[0080] The optimization process is an offline, periodic data analysis task. It involves optimizing the way data transformation logic is judged within the sensitivity level: examining cases where the sensitivity assessment result (e.g., "highly sensitive") deviates significantly from subsequent actual access patterns. For example, a derived field judged as highly sensitive might be frequently accessed by numerous roles for months without triggering any security alerts. Engineers can review the transformation logic of this field (e.g., AVG() aggregation) and consider adjusting the irreversible weights corresponding to this type of transformation logic mentioned above. or impact factor This makes it more in line with actual risks.

[0081] Optimize the dynamic generation logic of access control policies: statistics in different The distribution of policy decisions (allow / deny / de-identify) under the combined approach is analyzed and correlated with historical security events (if any). For example, it was found that for a "medium-sensitive field," in an "external display" scenario, the current policy has a 10% probability of being "allow," but a data mis-distribution event has occurred in this scenario. Therefore, it is recommended to adjust the weights of the aforementioned decision function. (Scenario risk weight) or threshold This combination leads to a more stringent policy (complete anonymization or partial rejection). Optimization suggestions can be submitted to a security administrator for review before application, or they can be applied automatically after simulation testing in a sandbox environment.

[0082] Based on the above, a complete feedback loop was constructed, from policy execution to effect evaluation and rule optimization. The large amount of real-world data generated during operation drives the iteration and improvement of the core security model. This ensures that the entire data anonymization and access control mechanism can keep pace with the times, possess self-learning and adaptive capabilities, maintain its effectiveness and accuracy in the long term, and reduce policy maintenance costs and mismatch risks in long-term operation.

[0083] In the embodiments provided in this application, it should be understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, code, or any suitable combination thereof. For hardware implementation, the processor may be implemented in one or more of the following: application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to implement the functions described herein, or combinations thereof. For software implementation, some or all of the processes of the embodiments may be performed by a computer program instructing the associated hardware. During implementation, the program may be stored in a computer-readable storage medium or transmitted as one or more instructions or code on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media may be any available medium accessible to a computer. Computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code having the form of instructions or data structures and accessible to a computer.

[0084] Finally, it should be noted that the above are merely preferred embodiments of this application and are not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A data desensitization and access control method based on data blood relationship and sensitivity identification, characterized in that, Includes the following steps: Construct a data lineage graph, which is used to describe the derivation, flow, and dependency relationships between fields in a data entity; Based on the kinship context of the fields provided by the data kinship diagram, the sensitivity level of each field in the data kinship diagram is identified; In response to a user's data access request, an access control policy is dynamically generated for the target field based on the business scenario, user role, and sensitivity level of the target field to be accessed. The access control policy specifies whether to allow access, deny access, or allow access after de-identification using a specified de-identification algorithm for the target field. The access control policy is executed by a data interceptor deployed in the database driver layer, application programming interface gateway layer, or application data access layer: if the access control policy allows access, the original data of the target field is allowed; if the access control policy denies access, the data of the target field is blocked; if the access control policy requires access after de-identification, the data interceptor calls the specified de-identification algorithm to perform real-time calculation and replacement of the data content of the target field.

2. The data desensitization and access control method based on data blood relationship and sensitivity identification according to claim 1, characterized in that, The construction of the data lineage diagram includes: The system analyzes application scripts, task logs, and database operation statements in the data processing system to explore and record data flow and data transformation logic at the field level in order to generate and update the data lineage diagram. 3.The data desensitization and access control method based on data blood relationship and sensitivity identification according to claim 1, characterized in that, The sensitivity levels of the fields identified based on the data lineage diagram include: For a derived field in the data lineage graph, trace its lineage back to one or more original fields from which it originated; The sensitivity level of the original field is obtained, and the sensitivity level of the derived field is determined by combining the data transformation logic recorded in the lineage link.

4. The data desensitization and access control method based on data blood relationship and sensitivity identification according to claim 2 or 3, characterized in that, The data lineage diagram also records the data transformation functions that the fields undergo during the transfer process; The determination of the sensitivity level of the derived field includes: lowering the sensitivity level of the derived field based on the irreversibility of the data transformation function.

5. The data desensitization and access control method based on data blood relationship and sensitivity identification according to claim 3, characterized in that, The determination of the sensitivity level of the derived field based on the data transformation logic recorded in the bloodline link includes: If the data transformation logic is an aggregation calculation or statistical operation on multiple native field values, then it is determined that the sensitivity level of the derived field is lower than the highest sensitivity level of the native field it depends on. If the data transformation logic is a direct mapping of a highly sensitive native field or a concatenation operation containing its key information, then it is determined that the derived field inherits or retains the sensitivity level of the highly sensitive native field.

6. The data desensitization and access control method based on data lineage and sensitivity identification according to claim 3, characterized in that, The method also includes: Based on historical access records and the data lineage diagram, analyze the access patterns of different user roles to the set of fields with derivative relationships; Based on the access pattern, the sensitivity level determination result for derived fields in the field set is dynamically calibrated.

7. The data desensitization and access control method based on data lineage and sensitivity identification according to claim 1, characterized in that, The dynamically generated access control policy includes: Query the data lineage graph to obtain the lineage context of the target field; The business scenario, user role, sensitivity level of target field and its lineage context are taken as input, and the access control policy containing specific control actions and parameters is output by calculating through preset policy rules.

8. The data desensitization and access control method based on data lineage and sensitivity identification according to claim 7, characterized in that, When the control action calculated and output by the preset strategy rules is to access the target field after de-identification, the system determines whether there are other related fields that originate from the same original data entity as the target field based on the lineage context. If so, a de-identification algorithm with logical correlation is configured for the target field and the other related fields.

9. The data desensitization and access control method based on data lineage and sensitivity identification according to claim 7, characterized in that, The dynamically generated access control policy also includes: Based on the data lineage diagram, analyze the complete data flow path corresponding to the data access request for the target field; The potential risk level of the access request is assessed based on the number and sensitivity level of upstream sensitive data entities involved in the complete data flow path. Based on the potential risk level, the access control policy for the calculated output is enhanced or downgraded.

10. The data desensitization and access control method based on data lineage and sensitivity identification according to claim 1, characterized in that, The method also includes: Collect audit logs of the data interceptor's execution of access control policies; Based on the audit logs, optimize the method for determining the impact of data transformation logic on the sensitivity level of each field in the data lineage diagram, or optimize the dynamic generation logic of the access control policy.

Images