A modular permission control method for data desensitization and hierarchical encryption

Abstract

This invention relates to the field of data security and intelligent access control technology, and discloses a modular access control method for data desensitization and hierarchical encryption. The method includes: performing field-level sensitivity identification on original data records using a rule engine and maintaining the flow state through an operational semantic probe to obtain a set of field-level annotations and three-dimensional dynamic tags; independently querying and outputting three sets of protection scheme suggestions through three policy modules: permissions, scenarios, and compliance; determining the final protection scheme by performing conflict resolution and constraint verification through a three-stage cascaded arbitration algorithm with compliance baseline constraints; desensitizing each field according to the scheme and completing field-level encryption using a DEK and KEK layered encapsulation architecture; reading data access behavior records, performing anomaly scoring and trajectory deviation detection through differentiated behavior baselines, and outputting a closed-loop policy feedback signal. This invention can achieve a dynamic balance between protection strength and data availability at the field granularity while meeting compliance constraints.

Description

Technical Field

[0001] This invention relates to the field of data security and intelligent access control technology, and more specifically, to a modular access control method for data desensitization and hierarchical encryption. Background Technology

[0002] Enterprise-level multi-organization collaborative office platforms need to share business data with different levels of sensitivity, such as personnel files, pay details, and organizational structures, among the group headquarters, regional branches, and external audit institutions. This requires hierarchical control at the field level for data desensitization and encryption protection during the cross-organizational data transfer process, and the compliance constraints vary under different transfer states.

[0003] Existing data access control schemes typically employ role-based static access policies or deny-override policies to synthesize logic, treating de-identification and encryption decisions as a unified operation for the entire record. When multiple policies from different sources are applied to the same data record simultaneously, existing schemes either directly override the output of lower-priority policies with a fixed priority or simply take the most stringent result among the policies as the final execution scheme, lacking the ability to perform differentiated arbitration based on compliance constraints at the field granularity.

[0004] The above approach leads to the following technical problems: When the multi-strategy output is encoded as a specific desensitization method rather than a binary allow or deny, the deny-override logic cannot make a reasonable choice among multiple encoded values. Simply taking the strictest encoding will cause the salary-related fields required for auditing to be overgeneralized, thus losing their statistical analysis value. At the same time, fixed weights cannot adapt to the dynamic combination of compliance constraints under different flow states such as internal storage, cross-system sharing, temporary state and destruction pending confirmation state, resulting in the inability to achieve a balance between protection strength and data availability at the field level. Summary of the Invention

[0005] This invention provides a modular access control method for data desensitization and hierarchical encryption, which solves the technical problem in related technologies that when multiple strategies are output as specific desensitization codes, it is impossible to achieve a dynamic balance between protection strength and data availability at the field granularity under compliance constraints.

[0006] This invention provides a modular access control method for data desensitization and hierarchical encryption, comprising the following steps:

[0007] S1 performs field-level sensitive identification and hierarchical labeling on the raw data records of the access platform through the rule engine, and maintains the flow status in real time through the operation of semantic probes to obtain a set of field-level labels and three-dimensional dynamic labels;

[0008] S2, when an access request arrives, based on the requester's identity credentials, field-level annotation set, and three-dimensional dynamic tags, the system independently queries the permission policy module, scenario policy module, and compliance policy module respectively, and outputs three sets of protection scheme suggestions;

[0009] S3 receives three sets of protection scheme suggestions, and uses a three-stage cascaded arbitration algorithm with compliance bottom line constraints to encode the de-identification method of each field, perform conflict resolution and constraint verification, and determine the final protection scheme for each field;

[0010] S4. According to the final protection scheme, the original field content of the target data record is desensitized field by field, and the DEK and KEK layered encapsulation architecture is used to complete the field-level encryption, generate a security data packet and encryption key encapsulation information, and the access log module records the transaction execution information as a data access behavior record.

[0011] S5 reads data access behavior records, performs anomaly scoring and trajectory deviation detection by establishing differentiated behavior baselines based on permission level and sensitivity level grouping, and outputs graded early warning results and closed-loop adjusted strategy feedback signals.

[0012] In a preferred embodiment, the operation semantic probe is deployed in the API gateway layer and the database operation proxy layer, and determines and updates the flow status of each data operation in sequence: when the operation target address hits the external organization system registration record in the system registry, the flow status is updated to the cross-system shared state.

[0013] When the operation is a temporary write containing a lifecycle field with a positive integer value, it is updated to the temporary state; when the operation is a physical delete or logical delete instruction, it is updated to the destruction pending confirmation state; if the operation is neither a temporary write containing a lifecycle field with a positive integer value nor a physical delete or logical delete instruction, the transition state is maintained as the internal storage state.

[0014] In a preferred embodiment, the permission policy module maps the requester role to a permission level, and determines the desensitization method code for each field according to the difference between the permission level and the sensitivity level of each field, and according to the preset mapping relationship between the difference and the desensitization method code; the scenario policy module queries the scenario policy table with the flow status as the key to obtain the desensitization method code that is uniformly applicable to all fields.

[0015] The compliance strategy module outputs a list of constraints. Each constraint carries the constraint direction and the applicable field type. Among them, the lower limit constraint stipulates that the code of the de-identification method shall not be lower than its constraint limit, and the upper limit constraint stipulates that the code of the de-identification method shall not be higher than its constraint limit.

[0016] In a preferred embodiment, the first stage of the three-stage cascaded arbitration algorithm retrieves the applicable hard constraints according to the field type to which each field belongs. The limit value of the lower limit constraint is recorded as the lower limit code value of the corresponding field, and the limit value of the upper limit constraint is recorded as the upper limit code value of the corresponding field. When the same field type is covered by multiple constraints in the same direction, the lower limit constraint takes the maximum value among the limits, and the upper limit constraint takes the minimum value among the limits.

[0017] When the lower limit code value of a certain field is greater than the upper limit code value, it is determined that there is a compliance constraint conflict in the corresponding field. The lower limit code value is taken as a temporary code and directly used as the final desensitization code for the corresponding field, and it will not proceed to the subsequent stages.

[0018] In a preferred embodiment, the second stage of the three-stage cascaded arbitration algorithm divides the fields into a first category with only unidirectional constraints, a second category with bidirectional constraints, and a third category without constraints according to constraint coverage; for the first category, the code with the majority weight in the permission policy suggestion code and the scenario policy suggestion code is selected as the candidate code according to the baseline weight, and the deviations of insufficient protection and availability loss are collected according to the constraint direction.

[0019] For the third category, first calculate the two stress indicators, which are equal to the sum of the corresponding deviations divided by the number of the first category fields of the corresponding constraint. When the number is zero, it is recorded as zero. When the protection insufficiency stress indicator exceeds the threshold while the availability loss stress indicator does not exceed the threshold, increase the weight component of the suggested code with the larger value to make the candidate code turn to the corresponding code. When the availability loss stress indicator exceeds the threshold while the protection insufficiency stress indicator does not exceed the threshold, symmetrically increase the weight component of the suggested code with the smaller value. When both stress indicators do not exceed or exceed the threshold at the same time, select according to the benchmark weight.

[0020] In a preferred embodiment, the third stage of the three-stage cascaded arbitration algorithm compares the candidate code with the constraint boundary of the field: if the candidate code is only subject to the lower limit constraint and is lower than the lower limit code value, it is adjusted to the lower limit code value; if the candidate code is only subject to the upper limit constraint and is higher than the upper limit code value, it is adjusted to the upper limit code value; if the candidate code is subject to both constraints, it is clamped between the lower limit code value and the upper limit code value to obtain the final desensitization method code for each field.

[0021] When the transfer status is "destroyed pending confirmation", the encryption method encoding of each field of the record is upgraded by one level, while the fields with the highest encryption strength remain unchanged.

[0022] In a preferred embodiment, the scenario strategy weights in the second stage are predicted in real time by the multilayer perceptron based on the request context. The predicted weights are only effective within the legal range defined by the lower limit encoding value and the upper limit encoding value determined in the first stage, and the constraint verification in the third stage is always maintained.

[0023] The ex-post cost is obtained by weighting and summing three types of signals from this method itself: compliance correction magnitude, availability loss indicator, and security exposure indicator, and the network parameters of the multilayer perceptron are updated based on this ex-post cost.

[0024] In a preferred embodiment, the desensitization method encoding corresponds to the original text output, format-preserving desensitization, partial deletion desensitization, or generalized desensitization processing, respectively; field data of the same sensitivity level are encrypted by the corresponding level DEK, which is then stored after being encrypted by the same level KEK, and users obtain KEKs of each level no higher than the corresponding permission level according to their permission level and decrypt them level by level.

[0025] When a user's permission level is downgraded, a new KEK is generated for the original permission level, and the corresponding DEK is re-encrypted before being distributed to users who still have the corresponding permission level. The data itself is not re-encrypted.

[0026] In a preferred embodiment, the differentiated behavior baseline is established using a combination of permission level and sensitivity level as the grouping dimension, and further subdivided according to the data source organization;

[0027] Standardized deviations are calculated for three statistical dimensions: daily access count, number of batch query records, and access time distribution. The standardized deviation is calculated by subtracting the mean of the corresponding dimension from the observed value and then dividing by the standard deviation of the corresponding dimension. Dimensions with a standard deviation of zero are not included, and their weights are distributed to other dimensions. The standardized deviations of each dimension are weighted and summed to obtain a comprehensive anomaly score. The corresponding level of graded warning is triggered according to the warning interval in which the comprehensive anomaly score falls.

[0028] In a preferred embodiment, the trajectory offset detection constructs a behavioral trajectory for each user based on three dimensions: the highest data sensitivity level of this visit, the number of field types, and the deviation of the visit time period. The directional trend is obtained by subtracting the mean of the first half from the mean of the second half of each dimension sequence. When two or more dimensions shift upwards simultaneously and the offset exceeds their respective minimum significant offset thresholds, a trajectory-level warning is triggered.

[0029] When the number of false alarms of type 1, which is categorized by the flow status, reaches the preset trigger threshold, a suggestion is made to the arbitration rule table to reduce the weight of the corresponding scenario strategy for the flow status, and the adjusted scenario strategy weight shall not be lower than the preset lower limit.

[0030] The beneficial effects of this invention are as follows:

[0031] By employing a three-stage cascaded arbitration algorithm with compliance bottom-line constraints, the first stage extracts the upper and lower compliance boundaries of each field and detects constraint conflicts. The second stage adjusts the decision weight of unconstrained fields in a directional manner based on the dual-path pressure indicators generated by the constrained fields. The third stage uses rigid constraints to ensure that the final desensitization encoding of each field does not exceed the compliance boundary. This allows different fields in the same data record to obtain differentiated protection schemes based on their respective sensitivity levels, field types, compliance constraints, and current flow status. Under the premise of meeting mandatory compliance requirements, the usability of data for business statistical analysis is preserved, avoiding the over-desensitization of all fields caused by simply adopting the strictest strategy.

[0032] By grouping permission levels, sensitivity levels, and data source institutions into differentiated behavioral baselines, and combining this with a trajectory deviation detection mechanism based on multi-dimensional directional collaborative expansion judgment, slow penetration behaviors that are rated normally in a single instance but continuously move towards high-risk directions are identified. Furthermore, the type-one false alarms generated by monitoring are aggregated according to their flow status and fed back to the scenario policy weights in the arbitration rule table, forming a complete closed loop from execution monitoring to decision parameter optimization. This enables the protection policy to continuously and adaptively adjust with changes in business access patterns without requiring security administrators to manually modify the weight configuration item by item. Attached Figure Description

[0033] Figure 1 This is a flowchart of a modular access control method for data desensitization and hierarchical encryption according to the present invention;

[0034] Figure 2 This is a flowchart of a modular access control method for data desensitization and hierarchical encryption according to the present invention. Detailed Implementation

[0035] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0036] At least one embodiment of the present invention discloses a modular access control method for data desensitization and hierarchical encryption, such as... Figures 1 to 2 As shown, it includes the following steps:

[0037] S1 performs field-level sensitive identification and hierarchical labeling on the raw data records of the access platform through the rule engine, and maintains the flow status in real time through the operation of semantic probes to obtain a set of field-level labels and three-dimensional dynamic labels;

[0038] The content acquired consists of raw data records collected from an enterprise-level multi-organization collaborative office platform. The output includes a set of field-level annotations for each record and a 3D dynamic tag for that record. The field-level annotation set contains two pieces of information for each field: its sensitivity level and field type category. Specifically, it includes:

[0039] Field-level sensitivity identification is performed by the rule engine. The rule engine has preset sensitivity identification rule sets corresponding to the types of business data fields. The rule sets are divided into three categories according to the data structure: structured data rules are applicable to fields in database tables with explicit column names and data type definitions; semi-structured data rules are applicable to nodes in business documents in XML or JSON format that have tag names but flexible content formats; and unstructured data rules are applicable to work records and notes in free text format. For structured data, the rule engine performs exact and fuzzy matching based on the field name and the preset sensitive field name library. If a match is found, it is directly labeled. For semi-structured data, the rule engine parses the tag structure and matches it with the sensitive path pattern library according to the tag path. For unstructured data, the rule engine calls the regular expression pattern library to scan the text content and identify sensitive segments that match patterns such as ID card number, mobile phone number, and name.

[0040] Sensitivity levels are divided into four levels: Level 1 is public, containing no information that can directly or indirectly identify an individual, such as employee ID or year of employment; Level 2 is general sensitivity, containing information indirectly related to an individual, such as department or office floor; Level 3 is confidential, containing core business information, such as salary details, performance evaluation results, and job transfer records; Level 4 is top secret, containing information that can directly identify an individual, such as employee name, ID number, and contact number. The rule engine assigns a corresponding level code to each field based on the sensitivity type it matches. Fields that do not match any rules are marked as Level 1 by default. While assigning sensitivity levels, the rule engine also labels each field with a field type category based on the sensitivity type it matches, such as identity, salary, organizational information, and general information. Fields that do not match any sensitivity type are classified as general information. The field type category and the field-by-field sensitivity level together constitute a field-level label set. The former is used for subsequent compliance constraints to match by field type and for behavior monitoring, while the latter is used for subsequent permission policies to calculate each field.

[0041] In one embodiment of the present invention, the construction of the three-dimensional dynamic label is performed after the field-level annotation is completed; the structure of the three-dimensional label includes three dimensions: the sensitivity level dimension takes the highest sensitivity level value of all fields in the record as the record-level summary level; the system source dimension records the unique registration identifier of the system where the data is currently located; the flow status dimension is maintained in real time by the operation semantic probe; the system source dimension is consumed in two downstream places: first, when the operation semantic probe executes the flow status judgment rule one, it compares the operation target address with the system source to identify cross-institutional operations; second, when the S5 behavior monitoring generates behavior records, it annotates the source institution of the data, so that the access behavior of the same user to data from different source institutions can be distinguished and statistically analyzed, avoiding cross-institutional data from being merged into the same baseline and diluting the abnormal signal;

[0042] Operational semantic probes are deployed in two locations: the API gateway layer, which intercepts all data operation requests entering and leaving the platform through standard interfaces; and the database operation proxy layer, which intercepts all read and write operations directly targeting data storage. The coverage of the two probe layers is complementary rather than overlapping. The API gateway layer probes cover all cross-system communication because cross-system communication must go through the gateway for routing and authentication. The database operation proxy layer probes cover all direct operations on data storage by internal systems because direct internal operations do not go through the gateway. For the very few operations that trigger both layers of probes simultaneously, event deduplication is used: each tag change event carries a unique transaction identifier for the operation. Before writing, the tag storage layer checks whether the transaction identifier already has a corresponding status update record. If it does, the duplicate event is discarded. When the two probe layers give different flow status judgment results for the same transaction, the judgment of the API gateway layer shall prevail because the gateway layer has complete request context information.

[0043] The probe determines and updates the flow status dimension value for each data operation according to the following rules in sequence: Rule 1: Check if the target address of the operation is registered as an external organization system in the system registry. If the target address matches an external system registration record, the flow status is updated to cross-system shared state. Rule 2: Check if the operation is a temporary write with an expiration time stamp, i.e., the operation instruction contains a lifecycle field with a positive integer value. If this is satisfied, the flow status is updated to temporary state. Rule 3: Check if the operation type is a physical deletion or logical deletion instruction. If this is satisfied, the flow status is updated to destruction pending confirmation state. Rule 4: If none of the above three rules are satisfied, the flow status remains in internal storage state. The system registry is maintained by the platform administrator and records the correspondence between each data interface endpoint and its affiliated organization. When a new organization connects, its interface address and organization identifier are added to the registry.

[0044] The output field-level annotation set and the 3D dynamic labels are written together into the label storage layer and associated with the original data records through data identifiers. This allows subsequent steps to quickly query information such as field sensitivity level, field type category, and record flow status each time an access request arrives. Each update of the flow status dimension simultaneously triggers a label change event written to the event queue, which is used in S3 as a trigger signal for strategy pre-computation.

[0045] S2, when an access request arrives, based on the requester's identity credentials, field-level annotation set, and three-dimensional dynamic tags, the system independently queries the permission policy module, scenario policy module, and compliance policy module respectively, and outputs three sets of protection scheme suggestions;

[0046] This step obtains two parts: First, the requester's identity credentials, including user identifier, role, department, and operation scenario identifier at the time of request initiation. The operation scenario identifier is a reserved field in the S2 main process and does not participate in the permission difference and scenario lookup calculation. It is only used as task context input in the preferred embodiment of online weight learning in the second stage of S3, to distinguish between tasks with opposite requirements, such as salary statistics audit and organizational compliance audit. Second, the field-level annotation set and three-dimensional dynamic tags generated in S1 for the target data record. The field-level annotation set provides the sensitivity level and field type category of each field, and the three-dimensional dynamic tags provide information such as the flow status of the record. The output consists of three protection scheme suggestions from different policy sources.

[0047] The query process of the permission policy module is as follows: The user role in the requester's identity credentials is mapped to a permission level value, which adopts a hierarchical system from level one to four, aligned with the four-level data sensitivity system. Then, the difference is calculated for each field in the target data record. The difference equals the user's permission level value minus the field's own sensitivity level value. A positive difference indicates that the permission is higher than the field's sensitivity; a difference of zero indicates that the permission just covers the field's sensitivity; and a negative difference indicates that the permission is insufficient to directly access the field. The permission policy module maintains a mapping table from difference to de-identification level: a difference greater than or equal to 1 is encoded as de-identification level 0 (no de-identification); a difference equal to 0 is encoded as de-identification level 1 (mild de-identification); a difference equal to -1 is encoded as de-identification level 2 (moderate de-identification); and a difference less than or equal to -2 is encoded as de-identification level 3 (heavy de-identification). The de-identification method code for each field is obtained by looking up the table. The code set constitutes the field-level desensitization scheme in the permission policy recommendations; both the encryption method encoding and the key level encoding are field-level parameters, determined according to the sensitivity level of each field; the encryption method encoding of a field takes the default encryption encoding corresponding to its sensitivity level: level 1 no encryption is 0, level 2 symmetric encryption is 1, level 3 high-strength symmetric encryption is 2, and level 4 mixed encryption is 3; the key level encoding of a field is equal to the sensitivity level value of that field; the reason for this design is that different fields in the same record have different sensitivity levels. If the entire record is encrypted with only a single highest-level key, legitimate users with lower permission levels who should have the right to view low-sensitivity fields will not be able to decrypt even low-sensitivity fields because they cannot obtain the high-level key, and the hierarchical access will lose its meaning. Therefore, encryption and keys must be implemented at the field level; the desensitization encoding, encryption encoding, and key encoding of each field together constitute the protection scheme of the permission policy recommendations;

[0048] In one embodiment of the present invention, the query process of the scenario strategy module is as follows: read the current value of the flow status dimension in the three-dimensional label of the target data, and use this value as the key to query the scenario strategy table; the scenario strategy table is a pre-configured table with the flow status as the key and the recommended protection parameters as the value, and its content is configured by the security administrator according to the business scenario requirements; the internal storage state corresponds to the desensitization method code 0, which means no additional desensitization; the cross-system shared state corresponds to the desensitization method code 3, which means the highest strength desensitization; the temporary state corresponds to the desensitization method code 2, which means medium to high strength desensitization; and the destruction pending confirmation state corresponds to the desensitization method code 3, which means full generalization processing; the table lookup results are combined into the protection scheme suggested by the scenario strategy, wherein the desensitization method code is a field-level parameter, that is, the same code value is uniformly applied to all fields; the encryption method code and key level code are not given separately by the scenario strategy, but follow the values ​​determined by each field according to its own sensitivity level in the permission strategy suggestion;

[0049] The query process of the compliance strategy module is as follows: It checks whether the target data's 3D labels carry industry compliance markers. These markers are automatically assigned by the platform based on the industry of the data source system during data access. The compliance strategy module maintains a mapping table from compliance markers to hard constraints. Each hard constraint consists of three fields: constraint type, constraint direction, and applicable field range. Constraint types include irreversible anonymization requirements and format preservation requirements. Constraint directions are divided into lower-limit and upper-limit types. Lower-limit constraints indicate that the anonymization code for this type of field must not be lower than a specified value to prevent insufficient protection, while upper-limit constraints indicate that the anonymization code for this type of field must not be higher than a specified value to prevent compromised data availability. The applicable field range specifies which field types the constraint applies to, such as only for identity fields or only for salary fields. The compliance module returns a list of constraints, with each constraint carrying a constraint direction marker and a code limit.

[0050] In the three sets of data mentioned above, the anonymization method encoding is a field-level output, meaning each field has its own encoded value. Similarly, the encryption method encoding and key level encoding are also field-level outputs, meaning each field has a value based on its own sensitivity level. S3's arbitration calculation only applies to the decision on the field-level anonymization encoding. The encryption encoding and key encoding are uniquely determined by the sensitivity level of the field itself, and there is no multi-policy conflict, so they do not participate in the arbitration. All three sets of data are simultaneously passed to S3 as input for the arbitration calculation.

[0051] S3 receives three sets of protection scheme suggestions, and uses a three-stage cascaded arbitration algorithm with compliance bottom line constraints to encode the de-identification method of each field, perform conflict resolution and constraint verification, and determine the final protection scheme for each field;

[0052] This step obtains the de-identification code set for each field in the permission policy suggestion output by S2, the unified de-identification code for each field in the scenario policy suggestion, the list of compliance constraints, and the field type label for each field; the output is the final de-identification method code for each field, which, together with the encryption method code and key level code determined by each field according to its own sensitivity level, constitutes the final protection scheme, which will drive the specific execution operation of S4; the field type label is used in the first stage to match the compliance constraints to the specific field according to the field type;

[0053] The conventional multi-strategy approach is the deny-override logic, which means that when any strategy gives a deny instruction, the final result is a denial. However, in this scenario, the output of each strategy is not a binary value of allow or deny, but a specific value encoded by multiple desensitization methods. The deny-override logic cannot make a choice among multiple specific values. Another conventional approach is to simply take the maximum value, i.e., the strictest strategy. However, this will cause all fields to be uniformly subjected to the highest intensity of desensitization, making salary fields lose their statistical analysis value and violating the compliance requirements for audit purposes.

[0054] In one embodiment of the present invention, the arbitration algorithm of this scheme is designed with a three-stage cascaded structure to address this difficulty;

[0055] The first phase involves compliance constraint extraction and conflict detection. Hard constraints are read one by one from the compliance constraint list. For each field in the target data record, a search is conducted to determine if a corresponding hard constraint applies to that field type. If so, the constraints are recorded according to their direction: for lower-limit constraints, the lower limit value specified in the hard constraint is recorded as the lower limit code value for that field; for upper-limit constraints, the upper limit value specified in the hard constraint is recorded as the upper limit code value for that field. If multiple hard constraints of the same field type are simultaneously covered by constraints in the same direction, the maximum value among the lower limits is used for lower-limit constraints, and the minimum value among the upper limits is used for upper-limit constraints. After completion, each field is checked to see if a valid interval exists between its lower limit code value and upper limit code value. If the lower limit value of a field is greater than its upper limit value, the constraint range is considered invalid. If there is no overlap, the field is determined to have a compliance constraint conflict. In this case, a conservative default strategy is applied to the field: the lower limit value is used as the temporary execution code, because lower limit constraints usually come from mandatory data protection regulations, and security compliance takes precedence over data availability. At the same time, the system sends a compliance conflict notification to the security administrator, requiring manual review of whether there are any configuration errors in the multiple constraints carried by the field. In actual business, a lower limit greater than the upper limit usually means that the two compliance rules are logically contradictory, requiring manual intervention to correct the compliance rule table. Before the manual review is completed, the field continues to execute the temporary code, that is, the field will no longer enter the second stage of weighted selection and the third stage of regular constraint verification, but will directly use the temporary code as its final de-identification method for encoding output; fields without conflicts will normally enter the second stage.

[0056] In the second stage, the constraint-aware hierarchical weighted selection is performed. The strategy engine maintains an arbitration rule table, which uses the flow status as the key and each key corresponds to a scenario priority weight vector. The weight vector contains two components: permission policy weight and scenario policy weight, the sum of which is 1. The strategy engine reads the current flow status value in the target data's 3D label and uses this value as the key to query the arbitration rule table to obtain the corresponding baseline weight vector.

[0057] Before performing weighted selection, this stage first divides each field into three categories based on the constraint coverage extracted in the first stage: the first category is fields covered by unidirectional constraints, that is, fields with only lower limit constraints or only upper limit constraints; the second category is fields covered by bidirectional constraints, that is, fields with both lower limit values ​​and upper limit values ​​and whose constraint ranges intersect; the third category is fields without constraint coverage, that is, fields that were not hit by any hard constraint conditions in the first stage.

[0058] For the first type of field, a conventional weighted selection is performed based on the baseline weight vector: the de-identified code value of the field in the permission policy suggestion and the de-identified code value of the field in the scenario policy suggestion are taken respectively. If the two are the same, the value is directly taken as the candidate code. If they are not the same, the code value corresponding to the larger weight component is taken as the candidate code. If the weights are equal, the larger code value is taken. After the selection is completed, the candidate code is immediately compared with the constraint boundary of the field and the deviation is collected according to the constraint direction. For fields with only lower limit constraints, if the candidate code is lower than the lower limit value, the absolute value of the difference between the candidate code and the lower limit value is used to count the insufficient protection deviation. Otherwise, the insufficient protection deviation of the field is recorded as 0. For fields with only upper limit constraints, if the candidate code is higher than the upper limit value, the absolute value of the difference between the candidate code and the upper limit value is used to count the availability loss deviation. Otherwise, the availability loss deviation of the field is recorded as 0.

[0059] For the second type of field, the range of options for weighted selection is constrained to the legal interval between the lower limit and the upper limit. If both the permission policy suggestion code and the scenario policy suggestion code fall within the legal interval, the selection is based on the baseline weight. If only one falls within the interval, the code value within the interval is directly taken. If both are outside the interval, a weighted average is calculated on the permission suggestion code and the scenario suggestion code according to the baseline weight to obtain a weighted median value. The boundary value that is closer to the weighted median value between the lower limit and the upper limit of the legal interval is taken as the candidate code.

[0060] For the third type of fields, before performing weighted selection, calculate the two constraint pressure indices separately. The inadequate protection pressure index equals the sum of the inadequate protection deviations of all first-type fields divided by the number of first-type fields with lower limit constraints. It reflects the tension level of the overall strategy recommendation being too low, approaching or exceeding the protection bottom line. The availability loss pressure index equals the sum of the availability loss deviations of all first-type fields divided by the number of first-type fields with upper limit constraints. It reflects the tension level of the overall strategy recommendation being too high and the threat data availability upper limit. When the number of first-type fields corresponding to a certain path is zero, the pressure index for that path is directly... Record it as 0 without division to avoid the problem of undefined calculation when the corresponding constraint field is not present in this request; the two indicators are compared with their respective pressure thresholds to drive fine-tuning in opposite directions; if the protection insufficiency pressure indicator exceeds its threshold while the availability loss pressure indicator does not exceed the threshold, it indicates that the overall request is biased towards protection insufficiency. At this time, each third type field is adjusted in a more conservative direction: compare the permission policy suggestion code and the scenario policy suggestion code of the field, increase the weight component corresponding to the policy with the higher code value by one adjustment increment, and decrease the other component by the same increment to keep the sum of the two components still the same. The increment should be 1. The increased weight component should gain a majority advantage in the weighted selection after adjustment, thus shifting the weighted selection of that field to the higher suggested encoding value. If the two suggested encodings for that field are the same, no adjustment is needed. If the availability loss pressure index exceeds its threshold while the protection insufficiency pressure index does not, it indicates that the overall request is biased towards over-identification. In this case, for each third-category field, increase the weight component corresponding to the strategy that gives the lower encoding value by the same increment, and decrease the other component by the same increment, so that the weighted selection of that field shifts to the lower suggested encoding value, i.e., biased selection. To maintain data availability, the field should be adjusted towards a more lenient approach. If the suggested codes for both paths are the same, no adjustment is needed. The reason for determining the target to be increased is based on the level of the suggested codes rather than the size of the weight components themselves. Weighted selection follows the suggested value of the one with the larger weight. Simply increasing the already majority component will not change the selection result. Only by increasing the weight of the path that gives the target direction code and making it gain a majority advantage can the selection result be truly pushed in the expected direction. If neither of the two indicators exceeds the threshold or both exceed the threshold simultaneously, the third type of field will directly use the benchmark weight vector to perform regular weighted selection, with the same logic as the first type of field.

[0061] The third stage is constraint verification. The candidate output code for each field is compared with the constraint code obtained in the first stage. For fields with only lower bound constraints: if the candidate output code is greater than or equal to the lower bound code value, the verification passes, and the final output code becomes the candidate value; if the candidate output code is less than the lower bound code value, the final output code is adjusted to the lower bound code value. For fields with only upper bound constraints: if the candidate output code is less than or equal to the upper bound code value, the verification passes, and the final output code becomes the candidate value; if the candidate output code is greater than the upper bound code value, the final output code is adjusted to the upper bound code value. For fields subject to both lower and upper bound constraints with overlapping constraint ranges: if the candidate output code falls within the valid interval between the lower and upper bound values, the candidate value is directly taken. If the candidate output code is lower than the lower limit, it is adjusted to the lower limit; if the candidate output code is higher than the upper limit, it is adjusted to the upper limit. After all fields are verified, the final desensitization method codes of each field are summarized into a field-level desensitization scheme. The encryption method code and key level code of each field do not go through the above arbitration process, but directly use the values ​​determined by the sensitivity level of the field itself in S2. The encryption method code is the default encryption code corresponding to the sensitivity level of the field, and the key level code is equal to the sensitivity level value of the field. If the current circulation status is the destruction pending confirmation status, the encryption method code of each field in the record is increased by one level based on the original value. If the original value of a field is already the highest code 3, it remains unchanged. The final desensitization code of each field, together with the encryption code and key code of each field, constitutes the final protection scheme output.

[0062] In one embodiment of the present invention, a constrained online learning weight mechanism is also provided, the post-hoc cost signal on which is partially derived from the internal generation of steps S4 and S5 described below; the aforementioned fixed weight vector uses the flow state as the unique index, but in actual business, requests under the same flow state can vary greatly; for example, in the same cross-system shared state, an external auditing firm may initiate both a payroll statistics audit and an organizational compliance audit. The former values ​​the availability of the payroll field most and hardly cares about the department, while the latter, on the contrary, needs the precise values ​​of the department and position most; the single weight found by the flow state alone cannot distinguish between these two types of tasks. As a result, either the department field required by the organizational compliance audit is overgeneralized, causing the other party to repeatedly retrieve data, or the weight is relaxed for availability, leaving the field protection of the other type of request insufficient; more troublesome is that whether a desensitization is appropriate often can only be known after the data is sent out, the feedback is naturally delayed, and the security administrator's manual adjustment of weights can never keep up with business changes, which is the specific problem that fixed weights cannot solve;

[0063] The overall idea of ​​this embodiment is to change the fixed configuration of the scenario strategy weights in the second stage of S3 to be predicted in real time by a small multilayer perceptron based on the request context. The predicted weights only take effect within the legal range defined by the compliance upper and lower limits in the first stage, and the upper and lower limit constraints in the third stage are always in effect. In other words, no matter what weights the model outputs during the learning and exploration period, the final encoding will be constrained by the compliance upper and lower limits and will never exceed the compliance bottom line. This constrained exploration method directly solves the special contradiction that compliance is a legal requirement and the learning process is not allowed to cross the line. It ensures that the model only optimizes data availability within the legal range and will not cause compliance violations due to exploration.

[0064] The model's input is a context feature vector, with each item sourced as follows: The flow status is represented by a one-hot encoding with four values, taken from the flow status dimension of the S1 3D label; the field type is represented by a one-hot encoding, distinguishing between identity, salary, organizational information, and general information types, taken from the field type annotations in S1; the field's sensitivity level and the requester's permission level are each represented by a normalized value; the permission policy's suggested encoding for the field and the scenario policy's suggested encoding for the field are each represented by a normalized value; the field's constraint coverage is represented by a one-hot encoding, distinguishing between unconstrained, lower-limit-only, upper-limit-only, and bidirectional constraints; the operation scenario identifier in the request credential is embedded and mapped into a low-dimensional vector to distinguish between different tasks such as salary statistics audit and organizational compliance audit; in addition, two values ​​are included: the repeat request rate for the same field type within the requester's near window and the compliance correction rate for the field type within the near window. The former reflects historical availability satisfaction, and the latter reflects historical over-strictness.

[0065] The model employs a multilayer perceptron with two hidden layers. The data flow between layers is as follows: the input layer receives the aforementioned feature vector; the first hidden layer is a fully connected layer with 32 neurons (for example, 32 in this embodiment), which performs a linear transformation on the input and then passes it through a linear rectified activation function to obtain the first layer output; the second hidden layer is a fully connected layer with 16 neurons (for example, 16 in this embodiment), which performs another linear transformation on the first layer output and then passes it through a linear rectified activation function to obtain the second layer output; the output layer is a single-neuron fully connected layer, which performs a linear transformation on the second layer output and then compresses it to 0 to 1 using a sigmoid activation function. Between these values, the output value is the predicted scenario policy weight, and the permission policy weight is equal to 1 minus this value. Linear rectified activation and S-shaped activation are both conventional methods, used here to introduce nonlinearity in weight prediction. The reason for using a two-layer nonlinear structure instead of a nonlinear model is that the reasonable value of the weight depends on the product interaction of the field type, the flow state, and the task identifier. For example, organizational information fields should have a low weight when encountering organizational compliance audit tasks in a cross-system shared state, but a high weight when encountering salary statistics audit tasks. This interaction relationship cannot be expressed by a linear model and must be fitted with nonlinearity of the hidden layer.

[0066] During inference, the weights obtained from the output layer are used as the scene policy weights for that field in the second stage of S3 and fed into the weighted selection. The remaining classification, dual-path pressure adjustment, and third-stage clamping processes remain unchanged. To enable the model to learn continuously, a limited perturbation is applied to the predicted weights within the legal range with a small exploration probability during operation. The contextual features, the weights actually used, and the cost observed afterward are recorded as a training sample. The exploration probability and the upper limit of the perturbation amplitude are both set to small default values ​​to ensure the stability of the online service.

[0067] The post-event cost is used to measure the quality of this weight selection. Its calculation method is specifically designed for this scenario and is equal to the sum of three signals from the system itself multiplied by their respective trade-off coefficients. The first type of signal is the compliance correction magnitude, which is the absolute value of the difference between the candidate code and the final code after being clamped when the candidate code of the field is clamped in the third stage. Its trade-off coefficient is recorded as the compliance coefficient. The second type of signal is the availability loss indicator, which is 1 when the same requester makes another request for the same field type within a preset time window and 0 otherwise. Its trade-off coefficient is recorded as the availability coefficient. The third type of signal is the security exposure indicator, which is 1 when S5 determines the access to be confirmed as abnormal and 0 otherwise. Its trade-off coefficient is recorded as the security coefficient. The compliance coefficient, availability coefficient, and security coefficient are configured by the security administrator according to the business's emphasis on compliance, availability, and security. The more valued a certain type of signal is, the larger its coefficient value will be.

[0068] It should be further noted that all three types of signals mentioned above are generated internally within each step of this method; these signals do not exist outside the system. The compliance correction magnitude comes from the clamping action in the third stage of S3, which simultaneously characterizes the degree to which the soft selection deviates from the compliance boundary. Being clamped by the upper limit indicates excessive desensitization, while being clamped by the lower limit indicates insufficient protection. The availability loss indicator comes from the statistics of the same requester's data retrieval behavior on the S2 and S4 links. Repeated data retrieval usually means that the previous excessive desensitization caused the data to be unavailable. The security exposure indicator comes from the anomaly judgment in S5. Confirming the anomaly indicates that the current desensitization was too low, resulting in exposure. It is this design, which bases the cost entirely on the system's internally generated signals, that makes the learning mechanism tightly bound to the architecture of this method rather than simply transferring a general model. The time window length can be a relatively scarce default value related to the repeated data retrieval behavior; for example, in this embodiment, it is defaulted to 24 hours.

[0069] The training process treats weight selection as a stochastic policy that takes contextual features as input and scene policy weights as actions, with the goal of minimizing the long-term average ex post cost. After each update cycle, the network parameters are updated offline using the samples accumulated in that cycle according to the policy gradient. The update direction is to reduce the probability of high-cost actions and increase the probability of low-cost actions. The near-window average cost is introduced as a baseline to reduce update fluctuations, and a small default learning rate is used. The updated network is first run in parallel with the original parameters in a grayscale manner. Once it is confirmed that the average cost does not increase, it will officially take over weight prediction.

[0070] As a simplified form of this embodiment, in the cold start phase where the model has not accumulated enough samples, statistical weights based on historical adoption rates can be used as initial weights. That is, the proportion of permission policy suggestions and scenario policy suggestions that have not been corrected by the third stage in the past period under each flow state can be used as the initial weight allocation. After the samples have accumulated to a certain scale, the online prediction of the multilayer perceptron can be switched. The online learning weights are naturally connected with the closed loop of S5. The type 1 false alarms and confirmation anomalies classified by S5 are the source of the aforementioned ex-post costs. The weight reduction rules originally triggered by the accumulation of type 1 false alarms can be used as a special case prior of this mechanism. Regardless of whether statistical weights or online prediction weights are used, the two core designs of the three-stage cascade arbitration structure and compliance bottom line constraint remain unchanged. The only difference is that the source of the weights in the second stage is static configuration, historical statistics, or online learning.

[0071] For data in a proactive push-type flow, where the platform actively pushes data to external systems, the tag change event queue in S1 will issue an event notification when the flow status is updated. The strategy engine listens to this queue, and upon receiving a notification that the flow status is about to change to a cross-system shared state, it immediately performs the above three-stage arbitration calculation with the target state as input and caches the calculation result in the strategy cache layer. When subsequent access requests arrive, the strategy engine directly reads the pre-calculated result from the cache without real-time calculation, eliminating the protection vacuum window caused by strategy calculation delay. For passive pull-type flow, where external systems actively pull data and it is unpredictable before the request arrives, the strategy engine temporarily implements a strict temporary protection scheme for the request before the arbitration calculation is completed: fields with lower limit constraints take their lower limit value, and all other fields, i.e., unconstrained fields and fields with only upper limit constraints, take the highest desensitization code 3, ensuring that over-desensitization is preferable to exposure during the temporary stage. After the arbitration calculation is completed, the protection result is updated to the final scheme of the arbitration output.

[0072] S4. According to the final protection scheme, the original field content of the target data record is desensitized field by field, and the DEK and KEK layered encapsulation architecture is used to complete the field-level encryption, generate a security data packet and encryption key encapsulation information, and the access log module records the transaction execution information as a data access behavior record.

[0073] The content obtained in this step is the final protection scheme output by S3, namely the desensitization encoding of each field and the encryption encoding and key level encoding of each field determined according to its own sensitivity level, together with the original field content of the target data record; the output is a secure data packet after field-level desensitization and encryption processing, as well as the encryption key encapsulation information corresponding to the data packet;

[0074] The desensitization execution module reads the desensitization method codes of each field in the final protection scheme and calls the corresponding desensitization processing function for each field. The correspondence between the desensitization method codes and the desensitization processing functions is as follows: Code 0 corresponds to no desensitization, i.e., original text output; Code 1 corresponds to format-preserving desensitization, which preserves the structural format of the field value but replaces some characters with mask characters, such as keeping the first 3 and last 4 digits of the ID number and replacing the rest with asterisks; Code 2 corresponds to partial deletion desensitization, which deletes sensitive subfields in the field value and replaces them with placeholders, such as deleting the specific amount in the salary details but retaining the salary grade range; Code 3 corresponds to generalization desensitization, which generalizes the field value to the higher-level concept of its category, such as generalizing the specific job title to the job category. The desensitization execution follows the principle of field independence, and the desensitization processing of each field does not interfere with each other. The desensitization result of one field does not affect the processing of other fields.

[0075] The encryption execution module reads the encryption method code and key level code of each field in the final protection scheme, determines the encryption algorithm type and key strength parameters for each field, and encrypts fields with the same sensitivity level together. The correspondence between encryption method codes and encryption algorithms is as follows: code 0 corresponds to no encryption, i.e., plaintext transmission; code 1 corresponds to a symmetric encryption algorithm with a 128-bit key length; code 2 corresponds to a symmetric encryption algorithm with a 256-bit key length; code 3 corresponds to a hybrid scheme of asymmetric and symmetric encryption, where the symmetric key is encrypted first using an asymmetric algorithm and then the data body is encrypted using the symmetric key. Since the encryption code of each field in the same record is determined by its own sensitivity level, multiple encryption strengths may exist in a single record. For example, identity fields may use hybrid encryption while organizational information fields may use symmetric encryption, and they do not affect each other.

[0076] In one embodiment of the present invention, the key management layer adopts a layered encapsulation architecture of data encryption key DEK and key encryption key KEK. Field data of the same sensitivity level is encrypted by the DEK corresponding to that level. The DEK is not directly distributed to the user, but is encrypted by the KEK corresponding to that sensitivity level and stored in the key storage layer. Each sensitivity level corresponds to an independent KEK. When a user requests decryption, they obtain all KEKs corresponding to each sensitivity level that is not higher than their permission level according to their permission level, use the KEK to decrypt to obtain the DEK of the corresponding level, and then use the DEK to decrypt the data body of the corresponding level field. High-sensitivity fields that are not covered by permissions cannot be decrypted because the corresponding level KEK cannot be obtained. This is the key to field-level encryption supporting hierarchical access.

[0077] When the access control module detects a user's access level being downgraded, it executes the following key expiration process: The access control module sends a key revocation command containing the user's identifier and the original access level to the key control module; upon receiving the revocation command, the key control module generates a new KEK for the original access level and re-encrypts all DEKs for that level using the new KEK; since the data size of the DEK is much smaller than the data body, the computational cost of this operation is manageable; the key control module distributes the new KEK through a secure channel to all users who still hold that level of access; the downgraded user, because their access record has been updated to a lower level, cannot obtain a new higher-level KEK through authentication, and therefore loses the ability to decrypt higher-level data; throughout the entire process, the encryption state of the data body remains unchanged, the DEK is not replaced, only the KEK is updated, therefore, there is no need to re-encrypt the data, and other legitimate users can continue to decrypt normally after obtaining the new KEK;

[0078] As an alternative and extended implementation of the aforementioned permission downgrade event-driven KEK update, a preventative key update based on access anomaly scoring can be superimposed on top of this: when the monitoring results in S5 below show that a user's comprehensive anomaly score is close to but has not reached the warning threshold multiple times, indicating that the user is in a gray area, the key management module proactively generates a new KEK for the user's permission group and gradually replaces the old KEK, completing the preventative key update before the permission is officially downgraded; this alternative method is suitable for scenarios with higher security requirements and can provide an additional security buffer when the permission management process is relatively lagging; this method is completely consistent with the main solution in the core design of the DEK and KEK layered encapsulation architecture, the only difference being that the triggering condition for KEK updates is expanded from a single permission change event to a dual triggering source of permission change events and anomaly score warnings;

[0079] For data in the pending destruction state, when the key management layer receives a decryption request for the data, it first checks the current value of the flow state dimension in the data's three-dimensional tag. If the flow state is pending destruction, the key management layer rejects the decryption request and returns a status code indicating that the data is in the pending destruction state and cannot be decrypted. This control logic is independent of the arbitration process of S3 and is a direct response of the execution layer to a special flow state. It is automatically released after the tag storage layer confirms that the flow state has returned to normal or the destruction operation has been revoked. It should be noted that this control and the third stage of S3's processing of increasing the encryption method of the pending destruction field by one level together constitute a two-layer protection in depth for this state: the former is a real-time interception in the access state, which directly blocks the decryption channel when the data is requested to be accessed; the latter is a static reinforcement in the retention state. Even if the record is later restored to access due to the destruction being revoked, its ciphertext strength in storage has been increased. The two operate at different times and are therefore not redundant.

[0080] For data sharing and transmission across systems, a transmission channel encryption layer is added after field-level encryption. The key for this layer of encryption is temporarily generated by the sender and receiver through a key negotiation protocol and is only valid within the current transmission session. The key is automatically destroyed after the transmission is completed.

[0081] Once the de-identification and encryption operations are completed, and the security data packet is generated and delivered, the processing chain of this data access transaction is closed. At this point, the access log module writes the entire execution information of this transaction into the behavior log storage layer to form a data access behavior record. The record includes the request initiation time, requesting user ID, user permission level, sensitivity level of the target data, source organization ID of the target data, the data flow status during this access, the set of field types involved in this access, the amount of data accessed, the access operation type, and the de-identification and encryption encoding of each field actually executed. This data access behavior record serves as a follow-up output after the closure of this step and is used by subsequent behavior monitoring steps.

[0082] S5 reads data access behavior records, performs abnormal scoring and trajectory deviation detection by establishing differentiated behavior baselines based on permission level and sensitivity level combination groups, and outputs graded early warning results and closed-loop adjusted strategy feedback signals;

[0083] This step obtains data access behavior records written to the behavior log storage layer by the access log module after S4 closure. Each data access behavior record includes the request initiation time, requesting user ID, user permission level, sensitivity level of the target data, source organization ID of the target data, data flow status during this access, set of field types involved in this access, data volume of this access, access operation type, and de-identification and encryption codes of each field actually executed in this access. The output includes anomaly scoring results, early warning notifications, and updated detection parameters after closed-loop adjustment.

[0084] The behavioral baseline is established using a grouped statistical approach. The combination of user permission level and target data sensitivity level serves as the basic grouping dimension, and this combination is further subdivided according to the data source institution. Specifically, the combination of user permission level, target data sensitivity level, and data source institution identifier is used as the grouping key, establishing an independent behavioral baseline for each group. The purpose of subdividing by data source institution is to implement the design intent of the system source dimension in S1, preventing the access behavior of the same user to data from different source institutions from being merged into the same baseline, thus diluting abnormal signals. This allows access from different institutions to be measured against their own normal patterns for deviation measurement. The behavioral baseline for each group includes distribution parameters for multiple statistical indicators: the mean and standard deviation of daily access counts, the mean and standard deviation of the number of records in a single batch query, and the access time distribution, i.e., the access frequency distribution vector statistically analyzed by hour. The baseline data is maintained using a sliding window, with the statistical window length set to cover a complete business scheduling cycle. For example, in this embodiment, the default value for the statistical window is 30 calendar days, which can cover a complete attendance cycle and monthly business statistical cycle for the enterprise. The statistical parameters within the window are recalculated after each update cycle. For example, in this embodiment, the default value for the update cycle is 1 calendar day.

[0085] The anomaly score calculation process when a new access behavior arrives is as follows: First, determine the grouping key for this access, which is the combination of the user's permission level, the sensitivity level of the target data, and the source organization identifier of the data. Then, read the distribution parameters of this group from the baseline storage layer. Next, calculate the standardized deviation value for each statistical dimension. Specifically, subtract the mean of that dimension from the observed value of this access, and divide the difference by the standard deviation of that dimension in that group to obtain the standardized deviation value. If the standard deviation of a dimension is 0, meaning there is no variation in that dimension, then that dimension does not participate in the weighted summation, and its weight is proportionally allocated to other dimensions. Finally, sum the standardized deviation values ​​of each dimension according to the preset dimension weights to obtain the comprehensive anomaly score. The dimension weights reflect the contribution of each statistical dimension to the anomaly determination. The initial weights are configured by the security administrator based on business characteristics and can be dynamically fine-tuned through a closed-loop adjustment mechanism.

[0086] The tiered early warning rules are as follows: No warning is triggered if the overall anomaly score falls within the first interval (0 to the first warning threshold); a low-level warning is triggered if it falls within the second interval (from the first to the second warning threshold), and the security administrator is notified via an internal system message; a medium-level warning is triggered if it falls within the third interval (from the second to the third warning threshold), and a notification is pushed through instant messaging channels, requiring the administrator to handle the situation within a specified time; a high-level warning is triggered if it falls within the fourth interval (exceeding the third warning threshold), and the system automatically and temporarily freezes the user's data access permissions while simultaneously sending emergency notifications to multiple security personnel.

[0087] In one embodiment of the present invention, in addition to the above-mentioned abnormal scoring based on a single visit, this step also includes a trajectory deviation detection mechanism oriented towards behavioral sequences, used to identify slow penetration behavior where the single score is normal but multiple consecutive visits show a directional expansion trend; specifically, an attacker who has obtained a legitimate account may control the daily access volume and operation type within the normal range so that the single score does not exceed the limit, but their behavior shows a trend of continuously moving towards higher sensitivity levels, wider field ranges, and more unconventional time periods on a multi-day scale; the core feature of this attack mode is not a large single deviation, but a continuous small step-by-step movement in multiple dimensions towards high-risk directions;

[0088] The behavior trajectory is constructed as follows: a sliding window is maintained for each user, which contains a sequence of behavioral features of the user's most recent consecutive visits; each visit is extracted into three feature dimensions: the highest data sensitivity level involved in this visit, the number of field types involved in this visit, and the time period deviation between the time period of this visit and the user's most frequent historical time period; the three dimensions of each visit in the window are arranged in chronological order to form the user's current behavior trajectory.

[0089] The trajectory offset detection process consists of two steps. The first step calculates the directional trend of each dimension: for each dimension's sequence value within the window, calculate its monotonic change trend over time. Specifically, subtract the mean of the first half from the mean of the second half of the sequence within the window. A positive difference indicates an upward offset (moving towards a higher risk direction), a negative difference indicates a downward offset (moving towards a lower risk direction), and a difference close to zero indicates no significant trend. The second step detects directional coherence: count the number of dimensions in the upward offset direction. If two or more dimensions are simultaneously in an upward offset and their offsets all exceed their respective minimum significant offset thresholds, then... The system determines that the user's behavior trajectory shows directional coordinated expansion. Even if the comprehensive anomaly score of each of the user's most recent individual visits does not trigger an alert, the system will still trigger a trajectory-level intermediate alert for the user and notify the security administrator for manual review. It should be noted that the standardized deviation calculation and the trend judgment of the second half minus the first half are both conventional statistical methods. The focus of this step is not on these single-point statistics, but on using multi-dimensional directional coordinated expansion as a criterion for slow penetration, and the closed loop formed by feeding back the false alarms and confirmed anomaly signals generated by monitoring to the S3 decision parameters. These two points are the design closely tied to this scenario.

[0090] The closed-loop adjustment mechanism is executed as follows: After each alert is generated, the security administrator handles it and records the results. The results are divided into two categories: confirmed anomaly indicates that the access was indeed unauthorized or violated regulations, while false alarm indicates that the access was a normal business activity but was incorrectly alerted. False alarms are categorized into three types: Type 1: Threshold too strict, meaning the detection threshold for this group is set too low, causing frequent alerts for normal business activities; Type 2: Baseline shift, meaning the normal business patterns of this user group have undergone a systematic change, causing the baseline data to no longer reflect the current true normal pattern; Type 3: Specific time period, meaning the false alarm occurred within a specific time period and the normal access pattern during that period differs systematically from the usual pattern.

[0091] Based on the different types of false alarm causes, parameter adjustments are performed in the corresponding directions. For type 1, the warning thresholds of the group are finely adjusted upwards by the default adjustment step size. For example, in this embodiment, the default value of the threshold adjustment step size is the 5th to 10th percentile of the current threshold. For type 2, the baseline of the group is recalculated, the statistical window cutoff time is updated to the current time, and the distribution parameters are recalculated based on the data in the new window. For type 3, an independent time-specific baseline is established for this special period, and the time-specific baseline is used to replace the regular baseline for deviation calculation during this period. Each parameter adjustment must meet the over-adjustment constraint, and the single adjustment range shall not exceed the default upper limit of the current parameter value. After each adjustment, an observation period is entered, which covers a complete weekly work cycle and includes both working days and non-working days access modes. For example, in this embodiment, the default value of the observation period is 7 calendar days. During the observation period, the system calculates the score simultaneously with the new parameters and the old parameters. If the false alarm rate under the new parameters exceeds the default false alarm tolerance threshold, it will automatically revert to the old parameters. For example, in this embodiment, the default value of the false alarm tolerance threshold is 5%.

[0092] The output of the closed-loop adjustment includes two parts: first, the updated detection parameters, including the warning thresholds, baseline distribution parameters, and dimension weights for each group, which are directly written into the baseline storage layer for subsequent anomaly scoring calculations; second, the policy feedback signal. Since the arbitration rule table of S3 stores the scenario policy weights with the flow status as the key, in order to ensure that the feedback signal can accurately locate the weight item to be adjusted, the policy feedback signal also uses the flow status as the aggregation dimension. The flow status it is based on is taken from the flow status field written into the behavior record in S4. Its triggering condition is: within an observation window of the same length as the behavior baseline statistics window, the type-one false alarms of each triggered corresponding group threshold adjustment operation are collected according to the flow status marked in the behavior record. When the accumulated type-one false alarm count of visits in the same flow status reaches the default trigger threshold, the closed-loop module determines that... The scenario strategy weight corresponding to the transition state may be too high; for example, in this embodiment, the default value of the strategy feedback trigger threshold is 3 false alarms of type 1 within the same observation window for the same transition state; after triggering, the closed-loop module sends a weight fine-tuning suggestion to the arbitration rule table of S3, suggesting that the scenario strategy weight component corresponding to the transition state be appropriately reduced; the fine-tuning step size is the default proportion of the current scenario strategy weight value, and the scenario strategy weight value after fine-tuning shall not be lower than the default lower limit to prevent the decision influence of the scenario strategy from being excessively weakened; for example, in this embodiment, the default value of the weight fine-tuning step size is 5% of the current weight value, and the default value of the weight lower limit is 0.2; after receiving the suggestion, the arbitration rule table fine-tunes the weight value according to this step size; this feedback path enables the detection result of S5 to influence the decision parameters of S3 in reverse, forming a complete closed loop from execution monitoring to decision optimization.

[0093] In one embodiment of the present invention, it is applied to a scenario of cross-organizational sharing of personnel files in a corporate group; the platform connects the group headquarters, 3 regional branches and 2 external audit institutions; as shown in Table 1, the following is the field structure and sensitivity level labeling results of a typical employee personnel file record;

[0094] Table 1. Examples of Sensitivity Level Labeling for Fields in Employee Personnel File Records

[0095]

[0096] The three-dimensional dynamic tags of this record are: the sensitivity level dimension is level four, which is the highest value of the field; the system source dimension is HQ01, which is the registration identifier of the group headquarters; and the circulation status dimension is initially internal storage state.

[0097] When the record is triggered to perform a cross-organization sharing operation, i.e., when the platform pushes it to an external auditing organization, the operation semantic probe of the API gateway layer detects that the target address A002, i.e. the registration identifier of the auditing organization, is registered as an external organization in the system registry, triggering the flow status dimension to be updated from the internal storage state to the cross-system sharing state, and at the same time writing a tag change event to the event queue;

[0098] At this time, a data analyst with a level 2 access permission from an external auditing agency requests access to the record through a shared interface; the S2 query process is as follows: the permission policy module obtains the desensitization code for each field by mapping the difference: for identity type, the difference 2 minus 4 equals -2, which is encoded as 3; for salary type, the difference 2 minus 3 equals -1, which is encoded as 2; for organizational information type, the difference 0 is encoded as 1; and for general information type, the difference 1 is encoded as 0. The encryption method of each field is determined according to its own sensitivity level: level 4 mixed encryption 3, level 3 high-strength symmetric encryption 2, level 2 symmetric encryption 1, and level 1 no encryption 0. The key level code is equal to its own sensitivity level. The scenario policy module obtains the unified desensitization code 3 for each field by looking up the table in the cross-system shared state. The compliance policy module obtains two constraints based on the audit compliance mark: the lower limit value of identity type is 3, which is not lower than the generalization processing strength, belonging to the lower limit type; the upper limit value of salary type is 1, which is not higher than the format preservation strength to preserve the salary level coding structure, belonging to the upper limit type.

[0099] The S3 arbitration process is as follows: First stage: extract constraints: employee name and ID number belong to the identity category, with a lower limit of 3; salary grade and performance appraisal belong to the compensation category, with a lower limit of 1; department and employee ID have no compliance constraints; there are no conflicts where the lower limit is greater than the upper limit for any field;

[0100] The second stage involves classification and stratified selection; employee name and ID number are the first category (lower limit type), salary level and performance appraisal are the first category (upper limit type), and department and employee number are the third category (unconstrained); the cross-system shared state baseline weight is 0.3 for permissions and 0.7 for scenarios; the first category weighted selection and deviation aggregation: the suggested permissions and scenarios for employee name and ID number are both 3, candidate 3 is not lower than the lower limit of 3, and the deviation for insufficient protection is 0; the suggested permissions for salary level and performance appraisal are 2 and the suggested scenarios are 3, the scenario weight of 0.7 is larger, so candidate 3 is selected, candidate 3 is higher than the upper limit of 1, and the deviation for availability loss is 3 minus 1, which is 2; two stress indicators: the stress for insufficient protection is (0 plus 0) divided by 2 equals 0, and the stress for availability loss is (2 plus 2) divided by 2. Assuming 2 equals 2; the default pressure thresholds for both paths are 1.0. Pressure 2 results in an availability loss exceeding the threshold, while pressure 0, indicating insufficient protection, does not exceed the threshold. This request is generally biased towards excessive desensitization. Adjustments are made to the third category fields towards a more lenient approach: for each third category field, the strategy corresponding to the path with the lower encoding value will have its weight increased by a default increment of 0.25. In this example, the lower encodings for the two third category fields, "Department" and "Employee ID," both come from the permission policy. Therefore, the permission weight is adjusted from 0.3 to 0.55, and the scenario weight from 0.7 to 0.45. After the adjustment, the permission policy gains a majority advantage in weighted selection. The suggested permissions for "Department" are 1, and for "Scenario" are 3. After the adjustment, the larger permission weight of 0.55 makes candidate 1. The suggested permissions for "Employee ID" are 0, and for "Scenario" are 3, making candidate 0.

[0101] Phase 3 constraint verification: For employee name and ID number, the 3 candidates are not lower than the lower limit of 3, and the final code is 3; for salary grade and performance appraisal, the 3 candidates are higher than the upper limit of 1, triggering a downward adjustment, and the final code is 1; for department candidate 1 and employee number candidate 0, there are no constraints, and this is the final code.

[0102] As shown in Table 2, the final protection execution results for each field are as follows;

[0103] Table 2. Execution results of the final protection scheme for each field

[0104]

[0105] This result demonstrates the core value of the arbitration mechanism: the compliance baseline for identity-related fields aligns with the recommended strategy, resulting in the direct execution of the highest-strength generalization; although salary-related fields were recommended to be encoded as 3 by both the permission and scenario strategies, the upper limit constraint pulled them back to the format preservation level of 1, maintaining the usability of salary data for audit analysis; the department field originally had no compliance constraints, but the usability loss pressure triggered by the upper limit constraint on salary-related fields indicated that the overall request had an over-sensitization tendency, so the arbitration mechanism pulled the unconstrained fields back towards a more lenient direction, ultimately executing 1 instead of 3; this is precisely the unique feature of the dual-pressure mechanism compared to the simple strictest strategy: compliance signals not only constrain the directly covered fields, but also indirectly correct the over-sensitization tendency of unconstrained fields;

[0106] In the S5 behavior monitoring phase, the data source organization accessed by this analyst was HQ01. Its grouping key was a combination of permission level 2, sensitivity level 4, and source organization HQ01. The baseline of this group over the past 30 calendar days showed an average of 45 accesses per day and a standard deviation of 12. When the number of accesses reached 92 on a certain day, the standardized deviation was (92 - 45) divided by 12, which equaled 3.9, falling into the second warning interval and triggering a low-level warning. After review by the security administrator, it was determined to be a false alarm. Since that day was the concentrated analysis period before the quarterly audit report deadline, it was classified as a special period of type three. The system establishes a special baseline for the quarterly audit deadline period.

[0107] On the other hand, this invention is also applied to the scenario of personnel query in branch offices of the same enterprise group collaborative platform; the personnel manager of a certain regional branch office has a level three access level and needs to check the three fields of ID number, performance evaluation and department in the employee file to verify the rationality of the annual promotion recommendation list; the record flow status is internal storage state, and since the branch office has been registered in the system registry as a permanent access party, access does not trigger cross-system shared state switching; this embodiment uses the same set of default parameters as the previous embodiment, and the pressure threshold for both channels is 1.0;

[0108] The S2 query results are as follows: The permission strategy module calculates the difference: the ID number level 4 difference is 3 minus 4, which equals -1, code 2; the performance evaluation level 3 difference is 0, code 1; the department level 2 difference is 1, code 0; the encryption method of each field is encoded according to its own sensitivity level: ID number mixed encryption 3, performance evaluation high-strength symmetric encryption 2, department symmetric encryption 1; the key level code is equal to its respective sensitivity level; the scenario strategy module looks up the table in the internal storage state to get a unified desensitization code of 0, meaning no additional desensitization; the compliance strategy module gets two constraints based on the HR management compliance mark: the identity category has a lower limit value of 3, which means that even if there is internal access, the identifier must be irreversibly removed, which is a lower limit type; the salary category has a lower limit value of 1, which means that it is not lower than the format preservation strength to prevent the original performance details from being leaked, which is a lower limit type.

[0109] The S3 arbitration process is as follows: In the first stage, constraints are extracted: the minimum threshold for ID number is 3, the minimum threshold for performance evaluation is 1, and there are no compliance constraints covering the department. There are no conflicts where the minimum threshold exceeds the maximum threshold for any field. In the second stage, the internal storage baseline weights are 0.7 for permissions and 0.3 for scenarios. ID number and performance evaluation are the first type of minimum threshold type, while the department is the third type of unconstrained type. For the first type of weighted selection: ID number permission suggestion 2 and scenario suggestion 0 are inconsistent; the permission weight 0.7 is larger, so candidate 2 is selected. Candidate 2 is lower than the minimum threshold of 3, and the deviation for insufficient protection is 3 minus 2, which equals 1. For performance evaluation permission suggestion 1 and scenario suggestion 0, candidate 1 is selected. Candidate 1 is not lower than the minimum threshold of 1, and the deviation is 0. For the two pressure indicators: the pressure for insufficient protection is (1 plus 0) divided by 2 equals 0.5. Since there are no upper limit constraints in this case, the availability loss pressure is recorded as 0. Neither of the two types exceeds the threshold of 1.0. For the third type of field, conventional selection is used; the department permission suggestion 0 and scenario suggestion 0 are consistent, so candidate 0 is selected.

[0110] The third stage of constraint verification: Candidate 2 of the ID number is lower than the lower limit 3, triggering an upward adjustment, and the final code is adjusted to 3; Candidate 1 of the performance evaluation is not lower than the lower limit 1, and the final code is 1; Candidate 0 of the department with no constraints is the final code; This example also shows the configuration logic that the weight of the permission policy is greater than the weight of the scenario policy in the internal storage state: the data has not left the platform's jurisdiction and the scenario risk is low, so the permission policy is suggested to have a higher decision weight. Finally, the performance evaluation execution format is retained and desensitized, which retains the evaluation level and assessment cycle for the human resources manager to verify the rationality of the promotion, while covering the specific comments and scoring details;

[0111] This embodiment is complementary to the previous one: the former encountered upper limit constraints and exceeded the threshold of availability loss pressure in the cross-system shared state, pulling the unconstrained fields back towards a more relaxed direction and imposing downward adjustment on the salary fields in the third stage; this embodiment encountered lower limit constraints and did not exceed the threshold of insufficient protection in the internal storage state, so the unconstrained fields followed the conventional selection, and the third stage imposed upward adjustment on ID numbers below the lower limit; the two embodiments together cover the two directions of dual-path pressure and the upward and downward adjustment in the third stage, demonstrating that no matter whether the strategy recommendation is too high or too low, the compliance bottom line is always rigidly guaranteed through the third stage.

[0112] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A modular access control method for data anonymization and hierarchical encryption, characterized in that, Includes the following steps: S1 performs field-level sensitive identification and hierarchical labeling on the raw data records of the access platform through the rule engine, and maintains the flow status in real time through the operation of semantic probes to obtain a set of field-level labels and three-dimensional dynamic labels; S2, when an access request arrives, based on the requester's identity credentials, field-level annotation set, and three-dimensional dynamic tags, the system independently queries the permission policy module, scenario policy module, and compliance policy module respectively, and outputs three sets of protection scheme suggestions; S3 receives three sets of protection scheme suggestions, and uses a three-stage cascaded arbitration algorithm with compliance bottom line constraints to encode the de-identification method of each field, perform conflict resolution and constraint verification, and determine the final protection scheme for each field; S4. According to the final protection scheme, the original field content of the target data record is desensitized field by field, and the DEK and KEK layered encapsulation architecture is used to complete the field-level encryption, generate a security data packet and encryption key encapsulation information, and the access log module records the transaction execution information as a data access behavior record. S5 reads data access behavior records, performs anomaly scoring and trajectory deviation detection by establishing differentiated behavior baselines based on permission level and sensitivity level grouping, and outputs graded early warning results and closed-loop adjusted strategy feedback signals.

2. The modular access control method for data desensitization and hierarchical encryption according to claim 1, characterized in that, The operation semantic probe is deployed in the API gateway layer and the database operation proxy layer, and determines and updates the flow status of each data operation in sequence: when the operation target address hits the external organization system registration record in the system registry, the flow status is updated to the cross-system shared state. When the operation is a temporary write containing a lifecycle field with a positive integer value, it is updated to the temporary state; when the operation is a physical delete or logical delete instruction, it is updated to the destruction pending confirmation state; if the operation is neither a temporary write containing a lifecycle field with a positive integer value nor a physical delete or logical delete instruction, the transition state is maintained as the internal storage state.

3. The modular access control method for data desensitization and hierarchical encryption according to claim 1, characterized in that, The permission strategy module maps the requester role to the permission level, and determines the desensitization method code for each field according to the difference between the permission level and the sensitivity level of each field, and according to the preset mapping relationship between the difference and the desensitization method code; the scenario strategy module queries the scenario strategy table with the flow status as the key to obtain the desensitization method code that is uniformly applicable to all fields. The compliance strategy module outputs a list of constraints. Each constraint carries the constraint direction and the applicable field type. Among them, the lower limit constraint stipulates that the code of the de-identification method shall not be lower than its constraint limit, and the upper limit constraint stipulates that the code of the de-identification method shall not be higher than its constraint limit.

4. The modular access control method for data desensitization and hierarchical encryption according to claim 1, characterized in that, The first stage of the three-stage cascaded arbitration algorithm retrieves the applicable hard constraints according to the field type to which each field belongs. The limit value of the lower limit constraint is recorded as the lower limit code value of the corresponding field, and the limit value of the upper limit constraint is recorded as the upper limit code value of the corresponding field. When the same field type is covered by multiple constraints in the same direction, the lower limit constraint takes the maximum value among the limits, and the upper limit constraint takes the minimum value among the limits. When the lower limit code value of a certain field is greater than the upper limit code value, it is determined that there is a compliance constraint conflict in the corresponding field. The lower limit code value is taken as a temporary code and directly used as the final desensitization code for the corresponding field, and it will not proceed to the subsequent stages.

5. A modular access control method for data desensitization and hierarchical encryption according to claim 4, characterized in that, The second stage of the three-stage cascaded arbitration algorithm divides the fields into three categories based on constraint coverage: a first category subject to only unidirectional constraints, a second category subject to bidirectional constraints, and a third category without constraints. For the first category, the code with the majority weight between the permission policy suggestion code and the scenario policy suggestion code is selected as the candidate code based on the baseline weight. Furthermore, the deviations from insufficient protection and the deviations from usability loss are aggregated according to the constraint direction. For the third category, first calculate the two stress indicators, which are equal to the sum of the corresponding deviations divided by the number of the first category fields of the corresponding constraint. When the number is zero, it is recorded as zero. When the protection insufficiency stress indicator exceeds the threshold while the availability loss stress indicator does not exceed the threshold, increase the weight component of the suggested code with the larger value to make the candidate code turn to the corresponding code. When the availability loss stress indicator exceeds the threshold while the protection insufficiency stress indicator does not exceed the threshold, symmetrically increase the weight component of the suggested code with the smaller value. When both stress indicators do not exceed or exceed the threshold at the same time, select according to the benchmark weight.

6. A modular access control method for data desensitization and hierarchical encryption according to claim 5, characterized in that, The third stage of the three-stage cascaded arbitration algorithm compares the candidate code with the constraint boundary of the field: if the candidate code is only subject to the lower limit constraint and is lower than the lower limit code value, it is adjusted to the lower limit code value; if the candidate code is only subject to the upper limit constraint and is higher than the upper limit code value, it is adjusted to the upper limit code value; if the candidate code is subject to both constraints, it is clamped between the lower limit code value and the upper limit code value to obtain the final desensitization method code for each field. When the transfer status is "destroyed pending confirmation", the encryption method encoding of each field of the record is upgraded by one level, while the fields with the highest encryption strength remain unchanged.

7. A modular access control method for data desensitization and hierarchical encryption according to claim 5, characterized in that, The scenario strategy weights in the second stage are predicted in real time by the multilayer perceptron based on the request context. The predicted weights are only effective within the legal range defined by the lower limit encoding value and the upper limit encoding value determined in the first stage. The constraint verification in the third stage is always maintained. The ex-post cost is obtained by weighting and summing three types of signals from this method itself: compliance correction magnitude, availability loss indicator, and security exposure indicator, and the network parameters of the multilayer perceptron are updated based on this ex-post cost.

8. The modular access control method for data desensitization and hierarchical encryption according to claim 1, characterized in that, The desensitization methods are encoded to correspond to the original text output, format-preserving desensitization, partial deletion desensitization, or generalized desensitization processing, respectively. Field data of the same sensitivity level are encrypted by the corresponding level DEK, which is then encrypted by the same level KEK and stored. Users obtain KEKs of each level no higher than the corresponding permission level according to their permission level and decrypt them level by level. When a user's permission level is downgraded, a new KEK is generated for the original permission level, and the corresponding DEK is re-encrypted before being distributed to users who still have the corresponding permission level. The data itself is not re-encrypted.

9. A modular access control method for data desensitization and hierarchical encryption according to claim 1, characterized in that, The differentiated behavior baseline is established using a combination of permission level and sensitivity level as the grouping dimension, and is further subdivided according to the data source institution; Standardized deviations are calculated for three statistical dimensions: daily access count, number of batch query records, and access time distribution. The standardized deviation is calculated by subtracting the mean of the corresponding dimension from the observed value and then dividing by the standard deviation of the corresponding dimension. Dimensions with a standard deviation of zero are not included, and their weights are distributed to other dimensions. The standardized deviations of each dimension are weighted and summed to obtain a comprehensive anomaly score. The corresponding level of graded warning is triggered according to the warning interval in which the comprehensive anomaly score falls.

10. A modular access control method for data desensitization and hierarchical encryption according to claim 9, characterized in that, The trajectory offset detection constructs a behavioral trajectory for each user based on three dimensions: the highest data sensitivity level of this visit, the number of field types, and the deviation of the visit time period. The directional trend is obtained by subtracting the mean of the first half from the mean of the second half of each dimension sequence. When two or more dimensions shift upwards at the same time and the offset exceeds their respective minimum significant offset thresholds, a trajectory-level warning is triggered. When the number of false alarms of type 1, which is categorized by the flow status, reaches the preset trigger threshold, a suggestion is made to the arbitration rule table to reduce the weight of the corresponding scenario strategy for the flow status, and the adjusted scenario strategy weight shall not be lower than the preset lower limit.

Images