Multi-source heterogeneous report permission automatic analysis method, computer device and storage medium

Abstract

The application relates to a multi-source heterogeneous report permission automatic analysis method, a computer device and a storage medium. The method comprises the following steps: constructing a plurality of permission entries according to the permission constraints of a target user in each dimension, and then generating a permission vector; performing multi-level conflict arbitration on the vector to obtain an arbitrated vector; generating an abstract syntax tree based on the arbitration result; and obtaining permission management code through target adapter compilation of each report to execute management. The application automatically calculates the maximum permission by using a permission vector model and a multi-level conflict arbitration algorithm, replaces manual judgment, and generates an abstract syntax tree through syntax analysis of the arbitrated vector, and the abstract syntax tree is compiled into corresponding code by an adapter, so that once a strategy is described, multiple reports are automatically implemented.

Description

Technical Field

[0001] This application relates to the fields of business intelligence (BI reporting), data security and system integration, and in particular to a method for automatic parsing of permissions for multi-source heterogeneous reports, computer equipment and storage media. Background Technology

[0002] In business intelligence (BI) reporting and data analytics applications, it's common for enterprises to use multiple reporting tools simultaneously. Especially with the development of domestic BI software, replacing traditional foreign BI tools with domestic ones is a growing trend, and the parallel operation and iteration of multiple reporting tools is an inevitable stage in this process. However, to ensure consistent reporting permissions across different reporting tools, manual configuration is currently the primary method, requiring significant manpower investment in both development and maintenance. In large enterprises, facing complex permission systems with multiple business segments, multiple tenants, and multiple levels, the investment costs are even greater, and the effectiveness is difficult to guarantee. Summary of the Invention

[0003] Therefore, it is necessary to provide a method, computer equipment, and storage media for automatically resolving permissions of multi-source heterogeneous reports, addressing the technical problem of inconsistent report permissions developed by various reporting tools.

[0004] The first aspect of this invention provides a method for automatic resolution of permissions in multi-source heterogeneous reports, comprising the following steps: Based on the target user's permission constraints in each dimension, construct multiple permission entries for the target user; Based on the multiple permission entries of the target user, construct the permission vector of the target user; Conflict resolution is performed on the permission vector of the target user to obtain the resolved permission vector; Based on the permission vector after the ruling, an abstract syntax tree is generated; Based on the abstract syntax tree, the permission management code for each report in the multi-source heterogeneous reports is compiled using the target adapter corresponding to each report. Based on the permission management code of the corresponding report, permission management for the corresponding report is implemented.

[0005] A second aspect of the present invention provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the first aspect of the present invention.

[0006] A third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect of the present invention.

[0007] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention constructs a multi-level conflict resolution algorithm based on a permission vector model. First, user permissions are modeled as permission vectors. Then, the multi-level conflict resolution algorithm automatically calculates the final permissions, replacing manual judgment. Finally, the conflict-resolved permission vectors are parsed to generate an abstract syntax tree, which is then compiled by the target adapter into the permission management code for the corresponding report, enabling a single policy description to automatically apply to multiple reports. Attached Figure Description

[0008] Figure 1 A flowchart illustrating an automatic permission resolution method for multi-source heterogeneous reports provided in an embodiment of the present invention; Figure 2 A schematic diagram of the MLCR conflict resolution process provided in an embodiment of the present invention; Figure 3 A schematic diagram of the conflict prediction process provided in an embodiment of the present invention; Figure 4 A schematic diagram of the ALPCO hierarchical optimization process provided in an embodiment of the present invention; Figure 5 A schematic diagram of the UPL compilation process provided in an embodiment of the present invention; Figure 6 A schematic diagram of the verification and auditing process provided in this embodiment of the invention; Figure 7 A flowchart illustrating runtime behavior auditing provided for embodiments of the present invention; Detailed Implementation To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0009] Among existing access control technologies, Power BI relies on DAX expressions to achieve row-level security (RLS), FineReport controls data scope by embedding the ${fr_username} parameter in SQL scripts, and FineBI uses a combination of SQL filtering and API system parameter injection. These three tools maintain independent access control configurations, are syntactically incompatible, and operate differently.

[0010] Enterprise-level permission systems already have well-established practices. RBAC (Role-Based Access Control) binds permissions to roles rather than users, while ABAC (Attribute-Based Access Control) introduces dynamic conditions such as user attributes and environment attributes. In multi-tenant architectures, three-tiered permission isolation between tenants, organizations, and users has become a standard design for SaaS systems.

[0011] Existing unified access control technologies for multiple platforms have the following problems: (1) The permission syntax of various reporting tools is incompatible with each other, and there is no unified description method. Power BI's RLS requires writing DAX formulas (such as [Region] IN {"East China","South China"}&&USERNAME() IN VALUES(UserMap[UserName])), FineReport requires SQL fragments (such as WHERE region IN ('East China','South China') AND ${fr_username} IN (...)), and FineBI requires configuring SQL filtering and API parameter mapping at the same time. When the permission policy changes, the operation and maintenance personnel must manually modify it in each tool, which is inefficient and easy to miss a tool, resulting in inconsistent permissions.

[0012] (2) Existing access control is limited to the data source level and lacks unified integration at the report operation level. A user may have the right to view the data in a report, but should not be able to export or share it. The configuration methods for such operation permissions are completely different in Power BI and FineBI, and cannot be automatically generated from the same policy description.

[0013] (3) The lack of a temporal permission management mechanism in scenarios involving concurrent positions and temporary work groups (risk control audit, marketing guidance group, etc.). The audit department draws personnel from various regions to form temporary work groups to carry out audit work in other locations. During the work period, members of the work group need cross-regional data permissions, but their original permissions in their original regions are not affected. The superposition of the two sets of permissions creates temporal conflicts: the work group's permissions cannot be automatically revoked and the permission code cannot be recompiled after they expire; the effective scope of the work group's permissions and the original region's permissions cannot be automatically calculated by the algorithm; and the expanded scope of the concurrent position's permissions cannot be automatically identified and marked. The current practice can only manually create temporary roles and set expiration times, and after expiration, it relies on manual revoke and manual recompilation, which has a high risk of omission.

[0014] (4) Conflicts arise from the overlapping of multiple levels of permissions, and there is a lack of a systematic adjudication mechanism. Taking real estate companies as an example, the intersection of permissions for a user at the organizational project level (developer → East China region → Shanghai company → project A → phase A1) and product level (first-level product type (residential / commercial / public building / parking space) → second-level product type (flat residential / villa / duplex...) → third-level product type (high-rise / mid-rise / ...)) needs to be precisely calculated; when parent-level authorization and child-level restrictions conflict within the same dimension, clear priority rules are also needed. Current practices rely on manual judgment, which has a high error rate.

[0015] (5) The scope of impact cannot be predicted when permissions are changed. After modifying the permissions of a role, the operation and maintenance personnel lack the tools to know in advance which downstream users will be affected, whether the permissions will be expanded or reduced, and whether new conflicts will be introduced. They can only investigate afterward.

[0016] (6) During the compilation of permission code, there is a lack of a hierarchical code generation optimization mechanism based on the sparsity of permission distribution. The enterprise-level permission system is a multi-level tree structure (sector → region → regional company → project → phase → building), and the granularity of user authorization uses different levels. There are two strategies when compiling into RLS filtering code: one is to flatten all levels of permissions to the leaf node level, and eliminate the dimension table association by using single-column filtering. However, after flattening high-level users (such as region level), the number of permission values ​​explodes, and the user-permission mapping table expands rapidly. The other is to maintain the original granularity of each level to avoid the expansion of the mapping table. However, multi-level filtering conditions need to associate dimension tables, and when there are multiple dimensions, "OR conditions" need to be concatenated, which may cause the query optimizer to generate inefficient execution plans. The existing solution adopts a fixed strategy for compilation, does not analyze the sparsity characteristics of permission distribution, and cannot automatically select the optimal code generation level according to the actual data distribution, resulting in a serious drop in query performance in scenarios with a large number of users or high cardinality dimensions.

[0017] (7) Sensitive reports lack a mechanism for overlaying operational constraints during compilation and automatic detection of unauthorized operations. Sensitive information such as financial statements and operating data requires different operational constraints to be applied according to the sensitivity level. However, the existing permission system does not have a means to dynamically overlay sensitivity constraints with permission codes during the compilation stage. Operational constraints corresponding to different sensitivity levels can only be implemented by manually configuring them one by one in each tool. When the compiled permission code encounters an operation request that does not conform to the sensitivity constraint rules, the system cannot automatically identify and issue an alarm. There is also no mechanism for batch modification of operational constraint rules and automatic recompilation to all target tools during special periods (such as the annual report window).

[0018] (8) After the permission code is compiled and generated, there is a lack of an automatic deployment and verification mechanism from the compilation output to the permission configuration of various reporting tools. Power BI provides a REST API to support programmatic RLS role creation, updating and member management, but FineReport and FineBI do not provide a formal API interface for permission management. Their permission configuration can only be changed through direct database writing or internal HTTP interface. Existing solutions do not address how to automatically write the compiled permission code to each target tool, how to verify that the permission code is actually effective after writing, and how to roll back when deployment fails. In addition, different deployment strategies should be adopted for permission changes of different risk levels (automatic push for low risk, waiting for confirmation for high risk), but the existing system adopts the same strategy for all changes. Either all deployments are automatic, resulting in a lack of review checkpoints for high-risk changes, or all are manually intervened, thus losing the value of automation.

[0019] (9) After the permission code is deployed and takes effect, there is a lack of runtime user behavior auditing and unauthorized access tracing mechanisms. The existing solution's verification and auditing only stays at the compilation and deployment stages, verifying "whether the permission code is correctly compiled and deployed", but cannot verify "whether the user's actual behavior is compliant". The user operation logs of various reporting tools have different formats and are stored in a scattered manner, making it impossible to unify and normalize them for cross-tool behavior analysis; it is impossible to automatically compare the data range actually accessed by users with the authorization range required by the business, and unauthorized behavior can only be discovered by manual post-event spot checks; permission configuration drift - administrators directly modify permissions, which cannot be automatically detected. The compliance framework requires data access behavior to be traceable, and the existing solution cannot meet this requirement.

[0020] To address the aforementioned technical problems, the first embodiment of the present invention provides a method for automatic resolution of permissions in multi-source heterogeneous reports, such as... Figure 1 As shown, it includes the following steps: Based on the target user's permission constraints in each dimension, construct multiple permission entries for the target user; Based on the multiple permission entries of the target user, construct the permission vector of the target user; Conflict resolution is performed on the permission vector of the target user to obtain the resolved permission vector; Based on the permission vector after the ruling, an abstract syntax tree is generated; Based on the abstract syntax tree, the permission management code for each report in the multi-source heterogeneous reports is compiled using the target adapter corresponding to each report. Based on the permission management code of the corresponding report, permission management for the corresponding report is implemented.

[0021] This embodiment utilizes the Unified Permission Language (UPL) and a multi-target compiler. It designs a policy description language, UPL, for BI report permissions, unifying data dimension permissions, operational permissions, and conflict resolution rules into a structured policy description. An Abstract Syntax Tree (AST) is generated through syntax parsing, and then the target adapter compiles the AST into Power BI's DAX RLS expressions, FineReport's SQL filtering scripts, and FineBI's SQL+API parameter combinations. A single policy description automatically takes effect in three locations. Furthermore, it employs a Multi-Level Conflict Resolution (MLCR) algorithm based on a permission vector model. Each user's permissions across multiple dimensions are modeled as a permission vector P(u) = {D1, D2, ..., D...}. nThe algorithm defines five conflict types (vertical conflict, horizontal conflict, cross-dimensional conflict, data-operation conflict, and temporal role overlay conflict) and their corresponding adjudication rules (Child Priority Rule (CPR); Deny Priority Rule (DPR); Strict Intersection Rule (SIR); Operation Limit Rule (OLR); and Temporal Overlay Rule (TOR)). The algorithm automatically calculates the final authority, replacing manual judgment.

[0022] In a specific embodiment, the Unified Permission Policy Language (UPL) defines a unified permission policy language description, ensuring that each UPL policy file contains a unique version declaration and policy declaration. Dimension declarations define the hierarchical structure of the permission model, rule definitions describe permission granting conditions, adjudication definitions describe conflict handling strategies, sensitivity definitions control report operation permissions, and verification definitions provide compile-time verification rules. All these rules are uniformly expressed as a structured policy description.

[0023] After lexical and syntactic analysis, the UPL policy file generates the AST node structure shown in Table 1.

[0024] Table 1

[0025] Define the data structure for the permission entry (PermissionEntry) as shown in Table 2.

[0026] Table 2

[0027] In the table, each permission entry describes a user's authorization or denial information for a specific dimension. `scope` uses path encoding, naturally supporting hierarchical relationships ("East China" includes "East China / Shanghai"). `source` distinguishes between explicit authorization and inherited authorization. `operations` uses bitmasks to simultaneously express data permissions and operational permissions. `roleTag` indicates whether the permission originates from a permanent role, temporary role, or concurrent role; temporary roles include `validFrom` and `validUntil` to form a time window, after which permissions are automatically revoked. `ReportSensitivity` independently defines the report's sensitivity level and operational constraint rules, decoupled from permission entries, and dynamically overlaid during the compilation phase.

[0028] Meanwhile, introduce a time window field and a role source tag for permission entries. During the permission vector construction phase, exclude temporary permission entries that exceed the valid time window through a temporal filtering algorithm; when the allowed scope of temporary permission entries expands after performing a union operation with the allowed scope of permanent permissions, identify two types of risks, namely organization (including cross-tenant) expansion and sensitive access, through dimension path comparison and sensitive report set matching, and generate risk markers; after a temporary permission entry exceeds the valid time window, trigger the permission recompilation process for affected users, and synchronously deploy the updated permission code to all target report tools without manual intervention, facilitating subsequent implementation of temporal permission filtering and automatic recovery recompilation mechanisms.

[0029] In a further embodiment, construct a permission vector for the target user based on multiple permission entries of the target user, including: Select a first set of permission entries with dimension d i from the multiple permission entries of the target user, where d i represents the i-th dimension, i = 1, 2, ..., n, and n is the total number of dimensions; In the first set of permission entries, retain the permission entries with roleTag being a permanent role (roleTag = PERMANENT), and the permission entries with roleTag being a temporary role or a concurrent role (roleTag = TEMPORARY or CONCURRENT) and the effective time less than or equal to the current time and less than or equal to the expiration time (validFrom ≤ now ≤ validUntil) to obtain a second set of permission entries; if validUntil < now, mark the entry as expired and trigger the recovery process; Sort the permission entries in the second set of permission entries in ascending order according to the hierarchical depth, and in descending order according to the priority weight within the same level to obtain the sorted second set of permission entries; Traverse the sorted second set of permission entries, add the scope of the permission entries with mode being ALLOW (mode = ALLOW) and not covered by a deeper level DENY to the allow set allowSet, add other permission entries to the deny set denySet, and add the permission entries with roleTag being a temporary role or a concurrent role (roleTag not being PERMANENT) in the sorted second set of permission entries to the temporary permission set tempSet; The permission vector of the target user is: P(u) = {D1(u), D2(u), ..., D n (u), O(u)} In the formula, P(u) represents the permission vector of the target user u; D1(u), D2(u), ..., D n (u) represents the dimension permissions of the 1st, 2nd, ..., nth dimensions, respectively. The dimension permissions include the effective allowed range, the denied range, and the source of temporary permissions. The effective allowed range is the coverage of the allowed set minus the coverage of the denied set, i.e., allowSet minus denySet. The denied range is the denied set denySet. The source of temporary permissions is the temporary permission set tempSet, where tempSet separately records the scope source of temporary permissions for subsequent TOR adjudication to distinguish the overlapping range of permanent and temporary permissions. O(u) represents the set of operation permissions, calculated as the intersection of the operation permissions in all dimensions. O(u) =D 1 .operations ∩ D 2 .operations ∩ ... ∩ D n .operations .

[0030] In a further embodiment, the present invention categorizes permission conflicts into five types, each with its own independent adjudication rules. These conflict adjudication rules include vertical conflict adjudication, horizontal conflict adjudication, cross-dimensional conflict adjudication, data-operation conflict adjudication, and temporal role superposition conflict adjudication, wherein: The vertical conflict resolution refers to a conflict arising between the authorization of a parent node and the rejection of a child node within the same dimension and the same set of paths. For example, in the organizational dimension, the "East China" node grants ALLOW, but the "East China / Shanghai / Project A" node is marked DENY (Project A is classified). The resolution rule for the vertical conflict resolution is the child priority rule (CPR), which includes: explicit settings by the child override settings by the parent; if the child has no explicit settings, it inherits the settings of the parent. Specifically, when the source of a child entry is EXPLICIT, the resolution result takes the mode value of the child; when the source of a child entry is not EXPLICIT, the resolution result takes the mode value of the parent. The horizontal conflict resolution refers to the conflict between permission entries from different path sets within the same dimension and level. For example, a user may simultaneously belong to the "East China Regional Manager" role (ALLOW East China) and the "Project A Risk Control Restriction" role (DENY Project A). The two entries are located in different branches but have overlapping scopes. The resolution rule for the horizontal conflict resolution is the Denial Priority Rule (DPR), which includes: when there is a conflict between allowing ALLOW and denying DENY permissions at the same level, the denial of DENY permission takes precedence. That is, if there is any entry with a mode of DENY in the same level's entry set, the resolution result is DENY; otherwise, it is ALLOW. The cross-dimensional conflict resolution requires that permission constraints from different dimensions be simultaneously satisfied, forming an intersection relationship. For example, the organization dimension allows viewing of all projects in East China, while the product dimension restricts viewing only residential projects. The effective scope = East China ∩ Residential. The resolution rule for the cross-dimensional conflict resolution is the Strict Intersection Rule (SIR), which includes: data access must pass checks across all dimensions, and strict intersections are taken between dimensions. The specific calculation process is as follows: using the allowed scope of the first dimension as the initial effective scope, the intersection of each dimension is taken: effectiveScope = D_1.allowSet ∩D_2.allowSet ∩ …∩ D_n.allowSet The data-operation conflict resolution refers to a situation where data dimension permissions allow viewing certain data, but operation permissions have not been granted for the corresponding operations. For example, a user's data scope may include data from the East China region, but the operation permissions lack the EXPORT flag. The resolution rule for the data-operation conflict resolution is the Operation Constraint Data Rule (OLR), which includes: operation permissions constrain the scope of data permissions. Even if the data is visible, unauthorized operations cannot be executed. The resolution results include: the viewable scope equals the valid data scope; the exportable scope equals the valid data scope when the operation bitmask contains EXPORT, otherwise it is an empty set; the shareable scope equals the valid data scope when the operation bitmask contains SHARE, otherwise it is an empty set. The temporal role overlap conflict adjudication involves a user simultaneously holding both permanent and temporary role permissions. The temporary permissions overlap with the permanent permissions within a time window, resulting in cross-regional or cross-dimensional permission expansion. For example, auditor Li Si is permanently stationed in the East China region and has East China data permissions (permanent role PERMANENT). He is seconded to the "Guangzhou Region A Project Audit Team" and obtains Guangzhou / A Project data permissions (temporary role TEMPORARY, 2026-05-01 to 2026-06-30). After the two sets of permissions overlap, Li Si can access East China and Guangzhou A Project data simultaneously during his work period, resulting in cross-regional expansion compared to permanent permissions. The adjudication rule for the temporal role overlap conflict adjudication is the Temporal Overlap Adjudication Rule (TOR), which includes: for temporary permission entries filtered by temporality, performing a set union operation between their allowed range and the allowed range of permanent permissions, calculating the expanded portion, automatically identifying risk markers, and triggering automatic recycling and recompilation upon expiration. The specific adjudication process involves checking three conditions sequentially: Condition 1: Time Validity Validation. Temporary permissions must be valid within the specified time window. Filter temporary entries that satisfy `validFrom` ≤ `now` ≤ `validUntil` as active temporary entries. If no active temporary entry is found, revert to the permanent permission scope.

[0031] Condition 2: Authorization chain verification. Temporary permissions must have an approval record. Traverse active temporary entries; for entries lacking an approval record, mark them as UNAUTHORIZED temporary permissions and exclude the entry, while generating an unauthorized access warning (missing approval record).

[0032] Condition 3: Reasonableness Prediction. The scope of temporary permission expansion must be pre-judged. Perform a set union operation on the permanent permission scope and the temporary permission scope to obtain the overlapping scope, expandedScope. Calculate the expanded portion, expansionPart = expandedScope - permanentScope. If the expanded portion is not empty, further checks are performed: if the expanded portion involves cross-organizational dimensions, mark it as a CROSS_ORG_EXPANSION risk and generate a pre-judgment alert; if the expanded portion involves sensitive reports, mark it as a SENSITIVE_ACCESS risk and trigger a sensitivity classification decision.

[0033] Automatic expiration and recycling. For active temporary entries, check the expiration distance. If validUntil - now is less than the warning threshold (e.g., 7 days), mark it as an EXPIRING risk and generate an expiration warning. The final decision includes: the effective range (the union of the permanent and temporary ranges), the permanent portion, the temporary portion, and a list of triggered risk markers.

[0034] In a further embodiment, report sensitivity constraints are also introduced as a compile-time overlay constraint layer for operation permissions, including: If the user's operation permissions do not include EXPORT, then the request will be rejected directly. Retrieve the sensitivity configuration of the report, including report identifier, sensitivity level, export constraints, sharing constraints, and a list of special periods. The sensitivity levels are L1, L2, and L3 from high to low. Check each item according to its sensitivity level: For L1 level data: Highest sensitivity, locked during special periods, requires approval under normal circumstances, and sharing is prohibited. Examples include annual report data, salary data, and investment and financing data. If the operation permission is EXPORT, first check if the current time is during a special period. If so, reject the export and mark it as "L1 sensitive data locked during a special period." If it is not during a special period, check if the export constraint is NEED_APPROVAL. If so, verify if there is an approval record. If there is no approval record, generate an unauthorized export warning and reject the export. If the operation permission is SHARE, reject the export directly. For Level L2: Moderately sensitive, export and sharing require approval, such as regional operating data, project cost data, etc.; if the operation permission is EXPORT and the export constraint is NEED_APPROVAL, verify whether there is an approval record. If there is no approval record, generate an unauthorized export alarm and reject the export; if the operation permission is SHARE and the sharing constraint is NEED_APPROVAL, verify whether there is an approval record. If there is no approval record, generate an unauthorized sharing alarm and reject the sharing. If all the above checks pass, the operation is permitted.

[0035] In this embodiment, ordinary reports are defined as L3, allowing export and sharing without requiring inspection. Examples include: basic data on projects / phases / buildings / rooms, project progress, etc.

[0036] This embodiment also includes a one-click locking mechanism for special periods: When an emergency lockout is triggered, the system executes the following steps: It iterates through all reports with a sensitivity level equal to the specified level, adding a special period record (including lockout name, effective time, expiration time, and lockout operation set) to each report. Then, it retrieves the set of all users authorized to access reports at that level, re-executes the MLCR ruling for each user, recompiles the permission code into each target tool, and generates an emergency lockout notification. After the lockout takes effect, exporting L1 sensitive reports is completely prohibited during the special period without requiring modification of any user's permission entries. The lockout occurs at the sensitivity constraint layer, not the permission entry layer. Sensitivity constraints are dynamically added to the permission code during the compilation phase, achieving decoupling control between the constraint layer and the entry layer. The lockout is automatically lifted upon expiration, and the permission code is automatically recompiled and restored.

[0037] The dynamic overlay of sensitivity constraints and batch recompilation mechanism for emergency policies in this embodiment, during the permission code compilation stage, reads the corresponding operation constraint rules according to the pre-configured sensitivity level of the report and dynamically overlays the operation constraints into the compiled permission code, decoupling the sensitivity constraint layer from the permission entry layer. When the compiled permission code is executed, if an operation request is detected to be inconsistent with the sensitivity constraint rules, an alarm is generated. When an emergency policy is triggered, the system traverses the report set corresponding to the specified sensitivity level, batch modifies the operation constraint rules, identifies the affected user set, re-executes conflict resolution and permission code compilation for each user, synchronously deploys the updated permission code to all target reporting tools, and sets an automatic release time. After the expiration time, the original constraint rules are restored and recompiled and deployed.

[0038] In a further embodiment, conflict resolution is performed on the permission vector of the target user to obtain the resolved permission vector, such as... Figure 2 As shown, it includes: For each dimension, first use the child priority rule to make a vertical conflict decision, and then use the rejection priority rule to make a vertical conflict decision. The strict intersection rule is invoked to adjudicate cross-dimensional conflicts. The strict intersection of the valid allowed ranges of all dimensions is taken, and then the rejected ranges of all dimensions are removed. Invoke the operation constraint data rules to adjudicate data-operation conflicts; If the target user has permission entries for roleTag as either a temporary role or a concurrent role, invoke the temporal overlay adjudication rule to adjudicate temporal role overlay conflicts; The tags need to undergo sensitivity checks, and the actual decisions are made one by one according to the reports during the compilation stage.

[0039] In a further embodiment, before constructing the permission vector of the target user, when a permission change request is received, conflict prediction is performed, including: Based on the permission change request, identify the set of users affected by the permission change; For each affected user, conflict resolution is performed using both the permission entries before and after the change, resulting in the resolutions before and after the change, and the difference between the resolutions before and after the change is calculated. If the difference includes permission expansion, it is marked as an EXPANSION risk; if the expansion involves cross-organizational dimensions, it is upgraded to a CROSS_ORG_EXPANSION risk; if the expansion involves L1 / L2 sensitive reports, it is upgraded to a SENSITIVE_ACCESS risk; if the difference includes permission reduction, it is marked as a CONTRACTION risk; if the difference introduces new conflicts, it is marked as a CONFLICT risk. Scan for permission entries that are about to expire within a preset number of days, mark them as EXPIRING risk, calculate the scope of permissions after expiration, and generate an expiration warning; Based on the differences and risk markers, an impact difference report is generated and sorted according to risk level.

[0040] In a further embodiment, a conflict prediction and verification audit mechanism is also provided. Before the permission change takes effect, the impact of the change is simulated through a permission dependency graph. After the permission calculation is completed, leakage detection, consistency verification, and audit tracing are performed to ensure that the permission code compiled to different tools produces equivalent effects. Specifically, before constructing the permission vector of the target user, when a permission change request is received, conflict prediction is performed, such as... Figure 3 As shown, it includes: Based on the permission change request, identify the set of users affected by the permission change; For each affected user, conflict resolution is performed using both the permission entries before and after the change, resulting in the resolutions before and after the change, and the difference between the resolutions before and after the change is calculated. If the difference includes permission expansion, it is marked as an EXPANSION risk; if the expansion involves cross-organizational dimensions, it is upgraded to a CROSS_ORG_EXPANSION risk (high priority); if the expansion involves L1 / L2 sensitive reports, it is upgraded to a SENSITIVE_ACCESS risk (high priority); if the difference includes permission reduction, it is marked as a CONTRACTION risk; if the difference introduces new conflicts, it is marked as a CONFLICT risk. Scan permission entries that are about to expire within a preset number of days, mark them as EXPIRING risk, calculate the scope of permissions after expiration, and generate an expiration warning. In this embodiment, the preset number of days can be 7 days. Based on the aforementioned differences and risk markers, an impact difference report is generated and sorted by risk level. In the impact difference report, the EXPANSION risk marks data security-sensitive scenarios (expansion of permissions may mean data leakage), the CONTRACTION risk marks business-impact scenarios (reduction of permissions may prevent users from working normally), and the CONFLICT risk marks complex scenarios requiring manual confirmation. CROSS_ORG_EXPANSION and SENSITIVE_ACCESS are two high-priority EXPANSION risks; the former indicates cross-organizational permission expansion, and the latter indicates expansion of sensitive data access, requiring higher-level approval. The EXPIRING risk indicates that temporary permissions are about to expire, reminding operations personnel to arrange permission handover or renewal in advance.

[0041] In a further embodiment, before compiling the permission management code for the corresponding report, the method further includes running the ALPCO algorithm on each dimension to determine the optimal code generation target level and code generation strategy for each dimension, such as... Figure 4 As shown, it includes: Based on all permission entries of all users, construct a permission distribution profile, including the number of deduplicated values ​​at the k-th level of dimension, the average fan-out value at the k-th level, the highest authorization level of the user in dimension d, sparsity, the total number of rows expanded to the candidate target level for all users, the maximum number of permission values ​​expanded to the candidate target level for a single user, and the average number of weight restrictions expanded to the candidate target level for all users. In this embodiment, the input consists of the target dimension to be analyzed (such as the organizational project hierarchy dimension) carrying a complete hierarchical structure definition, all valid permission entries after permission adjudication (excluding expired temporary entries), and the current set of all users for whom permission codes need to be generated. The output is a permission distribution profile, where: First, iterate through each level Lk (k=1,2,...,n) of the target dimension and calculate sequentially: ValueCount[k]: Directly counts the number of unique nodes in the hierarchy Lk. Taking the organizational project hierarchy as an example, if the hierarchy is defined as "segment → region → regional company → project → phase", then valueCount[1] is the total number of segments, valueCount[2] is the total number of regions, etc. This value directly affects the calculation of subsequent association costs. The more values ​​there are, the larger the lookup table will be during the JOIN operation. Average fanout (avgFanout[k]): For each value v in the hierarchy Lk, the FanOut function is called to calculate how many leaf nodes (i.e., phase-level nodes) v covers downwards, and then the average fanout of all values ​​is calculated. For example, the "Region" hierarchy has 5 values ​​(East China / South China / North China / Central and Western China / Bay Area), covering 180 / 150 / 120 / 90 / 60 projects respectively, then avgFanout[1] = (180+150+120+90+60) / 5 = 120. The average fanout reflects the "granularity" of the hierarchy. The larger the fanout, the coarser the hierarchy. Then, for each user u, determine its highest authorization level on dimension d, which is the deepest path-encoded level among the permission entries u possesses on that dimension. For example, if a user's permission entries include "East China Region" (L2 level, depth = 2) and "Project A" (L4 level, depth = 4), then the highest authorization level is L4 (project level). All users are then split into corresponding levels according to this rule, resulting in userCount[k]. If a large number of users' highest authorization levels are already at a finer granularity (such as project level or phase level), then selecting these fine-grained levels as the target level will not lead to additional precision loss. Conversely, if a large number of users are concentrated at a higher level (such as region level), then the mapping expansion problem caused by flattening needs to be considered. Finally, a permission coverage matrix is ​​constructed and its sparsity is calculated. Specifically, a two-dimensional binary matrix PCM is constructed first, with dimensions |U|×|L| (number of users × number of leaf nodes). The assignment rules for matrix elements are as follows: PCM[u][l] = 1 if user u has permission to access leaf node l through any permission entry (after MLCR adjudication). = 0 otherwise The specific construction method is as follows: For each user u, perform the FlattenToLeaf operation on all valid permission entries in its permission vector P(u) with respect to dimension d, that is, expand the authorization scope of any level down the dimension tree to the leaf node level to obtain a leaf node set leafSet; then set PCM[u][l]=1 for each leaf l in the set.

[0042] After the matrix is ​​constructed, the number of non-zero elements, nnz (PCM), is calculated, and then the sparsity is obtained. Sparsity = 1 - nnz(PCM) / (|U| × |L|) The threshold criteria for sparsity are shown in Table 3.

[0043] Table 3

[0044] For each possible candidate target level Lk (k ranges from 1 to n), simulate expanding the permissions of all users in this dimension to level Lk, and statistically analyze the following three metrics: `totalMappingRows[k]`: The total number of rows after all users are expanded to level `Lk`. This is an estimated size of the mapping table (such as `UserPhaseMap` in Power BI). It is calculated by performing `FlattenToLevel(P(u),Lk)` on each user `u` to obtain the size of the set of permission values ​​for `u` at level `Lk`, and then summing this value across all users.

[0045] `maxFanoutPerUser[k]`: The maximum number of permission values ​​a single user can have when expanded to `Lk`. This value determines the maximum length of the parameter list in the generated IN clause; an excessively large value will affect the parsing efficiency of SQL / DAX expressions and the quality of the execution plan.

[0046] avgFanoutPerUser[k]: The average number of permission values ​​for all users after expanding to Lk. Reflects the overall "expansion ratio".

[0047] Based on the permission distribution profile, data warehouse pattern information, and target database engine type, the total cost of the candidate target level is obtained; This embodiment utilizes an engine-aware cost model to calculate a quantified "total cost" value for each candidate target level Lk, enabling code generation schemes at different levels to be compared on the same scale. It's called "engine-aware" because the model needs to select different cost coefficients and calculation formulas based on the actual type of the target database engine when estimating costs: column-oriented engines (such as StarRocks, ClickHouse, Doris, etc.) or row-oriented engines (such as MySQL, PostgreSQL, Oracle, SQL Server, etc.). The execution characteristics of the same permission distributed across different database engines differ significantly. Column-oriented engines have highly optimized execution paths for bitmap filtering and IN clauses, but are highly sensitive to JOIN operations; row-oriented engines rely on B+ tree indexes, and the number of parameters in the IN clause directly affects index lookup efficiency. If the cost model does not consider these differences, the selected "optimal level" may perform well on one engine but worse on another.

[0048] The total cost (TotalCost(Lk)) is composed of the linear superposition of four sub-cost components: TotalCost(Lk) = C_filter(Lk) + C_join(Lk) + C_storage(Lk) + C_precision(Lk) In the formula, C_filter(Lk) represents the filtering cost, which physically means the overhead of the IN clause / bitmap filtering generated after flattening during query execution. Its weight comes from the number of rows in the mapping table × the maximum fan-out of a single user; C_join(Lk) represents the join cost, which physically means the additional overhead of JOINing dimension tables when the target level is coarser than the fact table granularity. Its weight comes from the difference in level depth × engine type; C_storage(Lk) represents the storage cost, which physically means the storage and maintenance overhead of the user-permission mapping table. Its weight comes from the total number of rows in the mapping table; C_precision(Lk) represents the precision loss cost, which physically means the overhead of additional filtering conditions when the target level is coarser than the user authorization level. Its weight comes from the number of fine-grained users forced to be downgraded. Specifically: (I) Detailed Explanation of Filtering Costs: The filtering cost reflects the performance impact of encoding user permission scopes into IN clauses (expressions in SQL / DAX such as column IN(v1, v2, ..., vn)) during query execution. This is the most complex of the four components because its calculation varies depending on the engine type.

[0049] Columnar Engine Mode (engine = COLUMNAR): The column-oriented storage engine uses columnar storage and vectorized execution. It processes the IN clause by constructing a bitmap: first, the values ​​in the IN list are converted into hash sets; then, the target column is scanned, and a hash lookup is performed on each value to determine whether to retain it. Therefore, the filtering cost primarily depends on the total number of rows in the mapping table (i.e., the total number of parameter values ​​in all user IN clauses).

[0050] The basic formula is: c_filter = α_c × totalRows / 1000 Where α_c is the columnar storage filtering cost coefficient (empirical value is 1.0), and totalRows is profile.totalMappingRows[k]. Dividing by 1000 is to unify the unit to the "thousand rows" level.

[0051] When the number of flattened permission values ​​for a single user exceeds the security threshold (default 500), additional penalties are applied: c_filter += penalty coefficient (η) × (maxPerUser - 500) / 100 The empirical value for the penalty coefficient η is 2.0. The reason for introducing the penalty is that while columnar storage engines excel at handling bitmap filtering of large datasets, when a single user's IN clause parameters are too numerous (e.g., a regional user covering 180 periods), three problems arise: (a) the DAX / SQL expression string becomes too long, potentially exceeding the tool's syntax limits; (b) the CPU and memory overhead of building large bitmaps at runtime is not negligible; and (c) the query optimizer may degenerate into an inefficient execution plan due to excessively large IN clauses. The penalty term quantifies the impact of such "extremely high fan-out users" into the cost.

[0052] Row-based engine mode (engine = ROW): The row-based storage engine relies on B+ tree indexes for data location. The IN clause is typically executed by performing an index lookup for each value in the list and then merging the result sets. Therefore, the filtering cost is closely related to the distribution of the number of parameters for each user.

[0053] The row-based storage model uses a piecewise function for modeling. For each user u, let the number of flattened permission values ​​be fc_u. Then, the filtering cost for this user is calculated in the following segments: For each user u: fc_u = FlattenToLevel(P(u), Lk) If fc_u ≤ 100: / / Small IN list, efficient index lookup c_filter += α_r × fc_u × log2(fc_u) Otherwise, if fc_u ≤ 1000: / / Medium IN list, index lookup efficiency degrades c_filter += α_r × fc_u × log2(fc_u) × 1.5 Otherwise: / / Large IN list, approximate full table scan c_filter += α_r × fc_u × fc_u / 1000 c_filter = Σc_filter / |U| / / Take the average value of all users Where α_r is the row storage filtering cost coefficient (empirical value is 0.8). The design logic of the three-segment broken line is as follows: • fc_u ≤ 100: Small IN list. The time complexity of each B+ tree index lookup is O(log N). The total lookup cost of fc_u values is approximately O(fc_u × log N).

[0054] • 100 < fc_u ≤ 1000: Medium IN list. The database optimizer may adjust the execution strategy. In some scenarios, it no longer uses pure index lookup but turns to index range scan + filtering, and the efficiency drops by about 50%. Therefore, a degradation factor of 1.5 is multiplied.

[0055] • fc_u > 1000: Large IN list. At this time, the IN clause is already close to the cost of a full table scan, and a large number of random I / Os cause the cache hit rate to drop sharply. The formula switches to the quadratic growth mode fc_u² / 1000 to simulate the cost characteristics of a full table scan.

[0056] (2) Detailed explanation of the association cost: The association cost occurs in the following situation: When the target level Lk is coarser than the fact table granularity grainLevel, the column names at the Lk level are used in the generated RLS code, but the fact table may not directly contain this column. If "regional level" (L2) is selected as the target level, a condition of WHERE region_id IN (...) will appear in the RLS code, but during execution, it needs to be JOINed to the fact table through the dimension table link of region_id → company_id → project_id → phase_id.

[0057] joinCount = grainLevel depth - Lk depth Special case handling: If the schema information shows that the fact table itself already contains columns at the Lk level (common in star schemas where the fact table redundantly stores high-level dimension columns to avoid too many JOINs), then joinCount is set to zero, and the join cost is zero.

[0058] Association cost in columnar storage engine mode: c_join = β_c × joinCount × (1 + valueCount[k] / 10000) β_c is the column-oriented join cost coefficient (empirical value is 5.0). valueCount[k] is the number of duplicate values ​​at the Lk level. A higher value means a larger dimension table and a higher JOIN cost.

[0059] Association cost in line-of-sight engine mode: c_join = β_r × joinCount × (factTableRowCount / 1000000) β_r is the row-store join cost coefficient (empirical value is 3.0). The JOIN performance of the row-store engine is highly dependent on the amount of data in the fact table, so the total number of rows in the fact table (in millions of rows) is used as the scaling factor.

[0060] (III) Detailed Explanation of Storage Costs: Storage cost is measured by the resource consumption of the user-permission mapping table itself. c_storage = γ × totalRows / 10000 γ is the storage cost coefficient (empirical value is 1.0). The mapping table needs to be persistently stored in the database (such as the UserPhaseMap table in Power BI) and frequently updated with changes in permissions, so the storage and maintenance costs cannot be ignored.

[0061] (iv) Detailed explanation of the cost of accuracy loss: The cost of precision loss measures the "additional complexity that must be accepted due to the selection of a coarser target level".

[0062] When the depth of the target hierarchy Lk is k, all users with authorization hierarchy depths j > k will face a precision loss problem. For example, a user's authorization scope is precise to "A1, A2, and A3 of Project A" (Level L5, 3 phase values). If the target hierarchy is selected as "Project Level" (L4), these 3 phases can only be represented as "Project A" (1 project value). Superficially, the number of parameters decreases, but in reality, the constraint information that "this user does not have permission to access other phases of Project A" is lost. To compensate for this precision gap, additional AND NOT conditions must be added to the RLS code to exclude unauthorized phases, leading to increased code complexity and runtime overhead.

[0063] The calculation method is as follows: c_precision = Σ_{j>k} (δ × profile.userCount[j] ×profile.avgFanoutPerUser[j]) Iterate through all levels Lj that are finer than the target level Lk (i.e., levels with depth j > k), multiply the number of affected users in that level by the average fan-out of these users, and then multiply by the accuracy loss coefficient δ (empirical value is 0.1), and sum them up to obtain the total accuracy loss cost.

[0064] There are natural constraints among the four cost components: C_filter vs. C_join: Selecting a finer target level increases C_filter but decreases C_join; selecting a coarser target level decreases C_filter but increases C_join.

[0065] C_filter vs. C_precision: Choosing a coarser target level decreases C_filter but increases C_precision; choosing a finer target level increases C_filter but decreases C_precision.

[0066] C_storage: Always positively correlated with C_filter, playing an auxiliary adjustment role.

[0067] ALPCO's optimal level selection is precisely about finding the balance point with the minimum total cost among these sets of contradictions.

[0068] The reference values ​​for the coefficients are shown in Table 4. These are for reference only and need to be calibrated according to the target engine and data distribution during actual deployment. For example, this project uses the StarRocks database, and the database nodes will be adjusted according to actual usage, which will also affect the relevant coefficients. In actual use, the relevant coefficients will be corrected based on the performance of historical query logs.

[0069] Table 4

[0070] Select the target level with the minimum total cost from all candidate target levels as the optimal code generation target level; In this embodiment, all levels not exceeding the granularity of the fact table are selected as candidate levels. For each candidate level Lk, the engine-aware cost model is invoked to calculate its total cost, and the level with the smallest total cost among all candidate levels is selected as the optimal code generation target level. The code generation strategy is determined based on the optimal code generation target level, specifically as follows: If the maximum fanout of the candidate level (maxFanout) is less than or equal to the safety threshold, and optimal.mappingRows is less than or equal to the mapping table safety threshold, then the strategy is FLATTEN (full flattening to the optimal level). If the maximum fanout of the candidate layer (maxFanout) is greater than the safety threshold, but the average fanout of the candidate layer (avgFanoutPerUser) is less than or equal to the safety threshold, then the strategy is HYBRID (hybrid strategy). When the strategy is HYBRID, users are divided into a flattened group and a hierarchical group: (1) User grouping. For each user u, calculate the number of flattened permission values ​​fc = |FlattenToLevel(P(u), optimalLevel)| at the optimal level. If fc ≤ the security threshold, then u is assigned to the flattened group; otherwise, it is assigned to the level-preserving group.

[0071] (2) Flattening group processing. For each user u in the flattening group, expand its permission scope to the optimalLevel level, generate the permission value set of that level, and construct the flattening mapping table.

[0072] (3) Hierarchical Preservation Group Processing. For each user u in the hierarchical preservation group, determine its natural authorization level naturalLevel on dimension d, preserve the original permission range on this level, and construct a hierarchical preservation mapping table.

[0073] (4) Hybrid compilation. Flattening mappings and hierarchy-preserving mappings are compiled into the RLS code for the target tool; Otherwise, the strategy is HIERARCHICAL (hierarchy preservation).

[0074] In an optional embodiment, upon receiving a permission change request, the permission distribution profile is reconstructed to obtain new permission features. The difference between the sparsity of the new profile and the sparsity of the old profile is calculated. If the absolute value of the difference exceeds a threshold (e.g., 0.05), the optimal level selection is re-executed. If the newly selected optimal level is different from the currently used level, a policy change suggestion is generated and the permission code of the affected users is recompiled. Finally, the new profile replaces the old profile and serves as the benchmark for the next comparison.

[0075] In a further embodiment, the permission management code for each report in the multi-source heterogeneous reports is compiled using the target adapter corresponding to that report, such as... Figure 5 As shown, it includes: During UPL compilation, permission code is generated for each dimension using the target hierarchy and strategy determined by ALPCO, rather than mechanically converting the original hierarchy path into filtering conditions. The compiler selects the corresponding code template based on the strategy type (flattening, hierarchy preservation, hybrid) output by ALPCO.

[0076] In a specific implementation, the code is compiled to three target reporting tools according to unified UPL declaration rules, automatically generating deployable code. Taking user u as an example, the project hierarchy is organized according to the strategy output by ALPCO, using regional hierarchical permissions. A unified AST description and compiled code snippet example are as follows: Compile to Power BI DAX RLS: Input AST dimension nodes: {……DIMENSION="region", SCOPE={"East China","South China"},……} Output DAX: [region] IN {"East China","South China"} &&USERNAME() IN SELECTCOLUMNS( FILTER(UserRegionMap, [region] IN {"East China","South China"}), [userName] )…… Compile to FineReport SQL: Input: Same as above AST nodes Output SQL: WHERE region IN ('East China', 'South China') AND ${fr_username} IN ( SELECT user_name FROM user_region_map WHERE region IN ('East China', 'South China') )…… Compile to FineBI SQL+API: Input: Same as above AST nodes Output SQL: WHERE region IN ('East China', 'South China')…… Output API parameters: { "finebi_auth_region": ["East China","South China"]}…… The above example only shows one dimension of the DimensionNode in the POLICY declaration. Information such as multiple rules (including GRANT, DENY and temporary roles), RESOLVE adjudication definition, SENSITIVITY sensitivity constraints (including special periods) and VERIFY validation configuration will be concatenated according to the code format corresponding to the reporting tool.

[0077] The semantic equivalence of the three is guaranteed by the consistency check of the verification and auditing module.

[0078] In a further embodiment, the system also includes verification audit rules, performing five verifications after the permission calculation is complete, such as... Figure 6 As shown: Verification 1: Leakage Detection. For each user u and each target tool t, verify whether the actual effect of the permission code compiled to t is a subset of the MLCR(u) adjudication result. If the actual effect exceeds the adjudication result, report a leakage alert.

[0079] Verification 2: Consistency Verification. For each user u, extract the logical predicates from the three compilation results (Power BI, FineReport, and FineBI) and verify whether the three predicates are semantically equivalent. If they are not equivalent, report a consistency alert. Specifically, construct a set of test queries for each user (covering boundary values ​​for each dimension), filter them using the permission code compiled to different tools, and compare the filtering results to see if they are the same.

[0080] Verification 3: Sensitivity Compliance Verification. For each report r that each user u has access to, obtain its sensitivity configuration and execute an unauthorized operation ruling for each sensitive operation (EXPORT, SHARE). If the ruling result is DENY, verify that the permission code compiled into each tool has actually blocked the operation. If it has not been blocked, report a sensitivity compliance alert. Specifically, construct unauthorized operation test cases for L1 and L2 sensitive reports (e.g., users without approval records attempting to export), and verify whether the compiled permission code correctly blocks the unauthorized operation.

[0081] Verification 4: Temporary Permission Expiration and Revocation Verification. Scan all expired permission entries to confirm that they were excluded during the temporal filtering phase and that the permission code for affected users has been recompiled. If any expired entries remain unrevoked, report an expired permission residue alarm, indicating a malfunction in the timed revoke mechanism.

[0082] Verification 5: Audit Trail. Record timestamps, changes, affected users, conflict resolution results, sensitivity verification results, and verification results, and write them to the audit log.

[0083] In a further embodiment, based on the risk markers in the conflict prediction results, a risk classification is performed on the compiled permission code changes to determine the deployment strategy. For each user u's compilation result, the highest risk marker for u in the prediction report is obtained and processed according to the following rules: Risk marked as NONE or CONTRACTION (low risk): Only permissions are reduced, deployment is automatically pushed, and a post-event notification is generated (permissions have been reduced).

[0084] Risk marked as EXPANSION (medium risk): Expanded permissions but not involving cross-organizational or sensitive data, automatic push deployment but notification afterward (permissions have been expanded, please confirm).

[0085] Risks marked as CROSS_ORG_EXPANSION or SENSITIVE_ACCESS (high risk) indicate cross-organizational expansion or expansion of sensitive data access. An alert notification is generated, awaiting manual confirmation. Deployment is executed only after confirmation; otherwise, it is marked as rejected and deployment is not performed.

[0086] Risk marked as EMERGENCY (emergency policy trigger): Forced deployment, generating emergency notification (forced deployment completed, post-event audit).

[0087] In a further embodiment, deployment adaptation and verification steps are also included: The deployment adapter encapsulates the deployment interface differences of various reporting tools and writes the compiled output permission code into the target tool. The deployment process is as follows: Backup before deployment. Back up the current permission configuration of user u in the target tool.

[0088] Deployment is distributed based on tool type.

[0089] For Power BI: Update the DAX filter expression and member list for a role via the REST API (PUT / groups / {groupId} / datasets / {datasetId} / roles / {roleId}).

[0090] For FineReport: Write permission configuration tables such as fr_role and fr_authority, and call the internal HTTP interface to trigger permission cache refresh.

[0091] For FineBI: Write to the FineBI permission configuration table, call the internal HTTP interface to trigger permission cache refresh, and output API parameter configuration to the FineBI parameter file.

[0092] Deployment verification. Verification consists of two steps: Verification: Read back the permission configuration of each tool and compare it with the compilation output. If they are inconsistent, the verification fails.

[0093] Functionality verification: Execute the test query set on each tool using user u's identity, and compare the filtered results with the expected results. If they do not match, the verification fails.

[0094] (4) Rollback mechanism. If the verification result is FAILED, restore the permission configuration of the target tool from the backup and generate a deployment failure alarm.

[0095] In further embodiments, a runtime behavior auditing step is also included, such as... Figure 7 As shown: After the permission code is deployed and takes effect, the runtime behavior auditing module collects user operation logs from various reporting tools, compares them with the authorization scope of the MLCR ruling, and automatically detects unauthorized behavior.

[0096] First, a unified user operation log model UOL is established, and its data structure is shown in Table 5.

[0097] Table 5

[0098] The log collection adapter collects operation logs according to tool type and maps them to UOL format: For Power BI: Call the Office 365 Activity API to obtain ActivityEvents within a specified time range, filter the operation types as ViewReport, ExportReport, ShareReport, and UpdateGroup, map the operation types (ViewReport→VIEW, ExportReport→EXPORT, ShareReport→SHARE), extract the report identifier from the Activity Log, and infer the accessScope by associating it with the permission scope.

[0099] For FineReport: Query the fr_log table to retrieve operation records within a specified time range, filter operation types as view, export, print, and share, map operation types (view→VIEW, export→EXPORT, print→EXPORT, share→SHARE), and infer accessScope from SQL execution logs or report-permission mapping.

[0100] For FineBI: Query the finebi_operation_log table to retrieve operation records within a specified time range, filter the operation types as VIEW_DASHBOARD, EXPORT_DATA, and SHARE, map the operation types (VIEW_DASHBOARD→VIEW, EXPORT_DATA→EXPORT, SHARE→SHARE), and infer the accessScope from the query SQL and API parameters.

[0101] Behavioral compliance analysis performs six types of violation detection on the operation logs of a user set within a specified time range: Rule 1: Unauthorized Operation. If the log records that a user performed an EXPORT operation but the user's operation permission 'O' does not include EXPORT, then it is marked as an unauthorized operation. The same applies to the SHARE operation.

[0102] Rule 2: Data scope exceeding authority. If there is a difference between the accessScope recorded in the log and the effectiveScope of the authorization decision (i.e., accessScope - effectiveScope is not empty), it is marked as data scope exceeding authority, and the record is out of scope.

[0103] Rule 3: Sensitivity Constraint Exceeding Authority. Retrieve the sensitivity configuration of the report corresponding to the log and execute an unauthorized operation ruling for the operation. If the ruling result is DENY but the log shows that the operation has been executed, mark it as sensitivity exceeding authority and record the sensitivity level.

[0104] Rule 4: Temporary Permission Abuse. If a user's permission risk flag includes CROSS_ORG_EXPANSION, calculate the user's operation frequency during the temporary permission validity period and compare it with the baseline daily average operation frequency during the permanent permission period. If the operation frequency during the temporary permission period exceeds a threshold multiple (e.g., 3 times) of the permanent daily average frequency, it is marked as temporary permission abuse, and the frequency ratio is recorded.

[0105] Rule 5: Permission Configuration Drift Detection. For each tool, read back the permission configuration of the sampled user set and compare it with the most recent compilation output. If they are inconsistent, mark it as permission drift and record a description of the difference.

[0106] Rule 6: Abnormal Behavior Pattern Detection. For each user, the frequency, range, and distribution of their operations within the analysis timeframe are statistically analyzed as recent behavioral characteristics and compared with the historical baseline (last 30 days). If the deviation exceeds a threshold, it is marked as abnormal behavior, and a description of the deviation is recorded.

[0107] The final output includes the total number of violations, violation details, and compliance rate (compliance rate = 1 - number of violations / total number of operations).

[0108] Event-triggered auditing: Event-driven auditing is automatically triggered after the permission change deployment is completed: The system retrieves the set of affected users, waits for the log collection window (30 minutes after deployment), collects the operation logs of affected users, and performs compliance analysis. If a violation is detected, an unauthorized access report is generated and an alert is sent.

[0109] Log collection strategy: Log collection strategies are determined based on report sensitivity levels: L1 level reports use full collection (FULL_COLLECTION), collecting all operation logs; L2 level reports use selective collection (FOCUSED_COLLECTION), collecting export and sharing operations; L3 level reports use sampling collection (SAMPLED_COLLECTION). Upon permission change, the system automatically upgrades to full collection, which continues for 24 hours.

[0110] A second embodiment of the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the first embodiment of the present invention.

[0111] A third embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps described in the first embodiment of the present invention.

[0112] The processor mentioned above is the processor in the computer device described in the above embodiments. The computer-readable storage medium may be a computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0113] In this embodiment, the module can be implemented in software so that it can be executed by various types of processors. For example, an identified executable code module may include one or more physical or logical blocks of computer instructions, which may be constructed as objects, procedures, or functions. Nevertheless, the executable code of the identified module does not need to be physically located together, but may include different instructions stored in different bits, which, when logically combined, constitute the module and achieve the module's intended purpose.

[0114] Through the above description of the implementation methods, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, disk, optical disk) and includes several instructions for executing the methods described in the various embodiments of this application.

[0115] The exemplary embodiments described above are with reference to the accompanying drawings. Many different forms and embodiments are feasible without departing from the spirit and teachings of this application. Therefore, this application should not be construed as limiting the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided to make this application complete and convey the scope of this application to those skilled in the art. In these drawings, component dimensions and relative dimensions may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, unless clearly indicated otherwise, the singular forms “a,” “an,” and “the” are intended to include all such forms. It will be further understood that the terms “comprising” and / or “including”, when used in this specification, indicate the presence of the stated features, integers, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components, and / or groups thereof. Unless otherwise indicated, when stated, a range of values ​​includes the upper and lower limits of the range and any subranges in between.

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

Claims

1. A method for automatic resolution of permissions in multi-source heterogeneous reports, characterized in that, Includes the following steps: Based on the target user's permission constraints in each dimension, construct multiple permission entries for the target user; Based on the multiple permission entries of the target user, construct the permission vector of the target user; Conflict resolution is performed on the permission vector of the target user to obtain the resolved permission vector; Based on the permission vector after the ruling, an abstract syntax tree is generated; Based on the abstract syntax tree, the permission management code for each report in the multi-source heterogeneous reports is compiled using the target adapter corresponding to each report. Based on the permission management code of the corresponding report, implement permission management for the corresponding report; The conflict resolution includes vertical conflict resolution, horizontal conflict resolution, cross-dimensional conflict resolution, data-operation conflict resolution, and temporal role superposition conflict resolution, wherein: The vertical conflict resolution is a conflict arising between the authorization of a parent node and the rejection of a child node within the same path set in the same dimension. The resolution rule for the vertical conflict resolution is the child priority rule, which includes: explicit settings of the child node override settings of the parent node; if the child node has no explicit settings, it inherits the settings of the parent node. The horizontal conflict resolution refers to the conflict between permission entries of different path sets within the same dimension and level. The resolution rule for the horizontal conflict resolution is the denial priority rule, which includes: when there is a conflict between allow and deny permissions at the same level, the denial permission takes precedence. The cross-dimensional conflict resolution requires that the permission constraints of different dimensions be satisfied simultaneously to form an intersection relationship. The resolution rule of the cross-dimensional conflict resolution is a strict intersection rule, including: data access must pass the checks of all dimensions, and the dimensions take a strict intersection. The data-operation conflict resolution refers to a situation where data dimension permissions allow viewing certain data, but operation permissions have not been granted for the corresponding operations. The resolution rules for the data-operation conflict resolution are operation-constrained data rules, including: operation permissions constrain the scope of data permissions, so that even if the data is visible, unauthorized operations cannot be executed. The temporal role overlap conflict resolution is for users who simultaneously hold permanent role permissions and temporary role permissions. Temporary permissions overlap with permanent permissions within a time window, resulting in cross-regional or cross-dimensional permission expansion. The resolution rules for the temporal role overlap conflict resolution are temporal overlap resolution rules, including: for temporary permission entries that pass the temporal filter, performing a set union operation on their allowed range and the allowed range of permanent permissions, calculating the expanded part and automatically identifying risk markers, and triggering automatic recycling and recompilation after expiration; The conflict resolution is performed on the permission vector of the target user to obtain the resolved permission vector, including: For each dimension, first use the child priority rule to adjudicate vertical conflicts, and then use the rejection priority rule to adjudicate horizontal conflicts. The strict intersection rule is invoked to adjudicate cross-dimensional conflicts. The strict intersection of the valid allowed ranges of all dimensions is taken, and then the rejected ranges of all dimensions are removed. Invoke the operation constraint data rules to adjudicate data-operation conflicts; If the target user has permission entries with the roleTag set to temporary or concurrent roles, the temporal overlay adjudication rule is invoked to adjudicate temporal role overlay conflicts.

2. The method for automatic resolution of permissions in multi-source heterogeneous reports according to claim 1, characterized in that, The permission entries include dimension name, path set, mode, hierarchy depth, source, priority weight, operation bitmask, roleTag, effective time, and expiration time, where: The dimension name indicates the dimension to which the permission entry belongs; The set of paths represents the scope of authorization; The mode represents permission information, including either allow or deny; The hierarchy depth represents the path depth; The source indicates explicit authorization or inherited authorization; The priority weight represents the basis for prioritizing permission items at the same level; The operation bitmask represents data permissions and operation permissions, including VIEW, USE, EXPORT, and SHARE; The roleTag indicates whether the permission originates from a permanent role, a temporary role, or a part-time role. When the permission originates from a temporary role, the effective time and expiration time are set.

3. The method for automatic resolution of permissions in multi-source heterogeneous reports according to claim 2, characterized in that, Based on the multiple permission entries of the target user, construct the target user's permission vector, including: Filter out items with dimension d from multiple permission entries of the target user. i The first set of permission entries, where d i Let i represent the i-th dimension, where i = 1, 2, ..., n, and n is the total number of dimensions. In the first set of permission entries, retain the permission entries with roleTag as permanent role, and the permission entries with roleTag as temporary role or concurrent role and whose effective time is less than or equal to the current time and less than or equal to the expiration time, to obtain the second set of permission entries; The permission entries of the second permission entry set are sorted in ascending order according to the level depth, and in descending order according to the priority weight within the same level, to obtain the sorted second permission entry set; Iterate through the sorted second set of permission entries, add permission entries with mode set to allowed and not covered by deeper levels of denial to the allowed set, add other permission entries to the denial set, and add permission entries with roleTag set to temporary role or concurrent role to the temporary permission set. The target user's permission vector is: P(u) = {D1(u), D2(u), ..., D n (in), O(in)} In the formula, P(u) represents the permission vector of the target user u; D1(u), D2(u), ..., D n (u) represents the dimension permissions of the 1st dimension, the 2nd dimension, ..., the nth dimension, respectively. The dimension permissions include the effective allowed range, the denied range and the temporary permission source. The effective allowed range is the coverage of the allowed set minus the denied set. The denied range is the denied set. The temporary permission source is the temporary permission set. O(u) represents the operation permission set, which is calculated as the intersection of the operation permissions in all dimensions.

4. The method for automatic resolution of permissions in multi-source heterogeneous reports according to claim 3, characterized in that, The data-operation conflict resolution results include: the viewable range equals the valid data range; the exportable range equals the valid data range when the operation bitmask contains EXPORT, otherwise it is an empty set; the shareable range equals the valid data range when the operation bitmask contains SHARE, otherwise it is an empty set.

5. The method for automatic resolution of permissions in multi-source heterogeneous reports according to claim 4, characterized in that, Before constructing the permission vector for the target user, when a permission change request is received, conflict prediction is performed, including: Based on the permission change request, identify the set of users affected by the permission change; For each affected user, conflict resolution is performed using both the permission entries before and after the change, resulting in the resolutions before and after the change, and the difference between the resolutions before and after the change is calculated. If the difference includes permission expansion, it is marked as an EXPANSION risk; if the expansion involves cross-organizational dimensions, it is upgraded to a CROSS_ORG_EXPANSION risk; if the expansion involves L1 / L2 sensitive reports, it is upgraded to a SENSITIVE_ACCESS risk; if the difference includes permission reduction, it is marked as a CONTRACTION risk; if the difference introduces new conflicts, it is marked as a CONFLICT risk. Scan for permission entries that are about to expire within a preset number of days, mark them as EXPIRING risk, calculate the scope of permissions after expiration, and generate an expiration warning; Based on the differences and risk markers, an impact difference report is generated and sorted according to risk level.

6. The method for automatic resolution of permissions in multi-source heterogeneous reports according to claim 5, characterized in that, Before compiling the permission management code for the corresponding report, the process also includes determining the optimal code generation target level and code generation strategy for each dimension, including: Based on all permission entries of all users, construct a permission distribution profile, including the number of deduplicated values ​​at the k-th level of dimension, the average fan-out value at the k-th level, the highest authorization level of the user in dimension d, sparsity, the total number of rows expanded to the candidate target level for all users, the maximum number of permission values ​​expanded to the candidate target level for a single user, and the average number of weight restrictions expanded to the candidate target level for all users. Based on the permission distribution profile, data warehouse pattern information, and target database engine type, the total cost of the candidate target level is obtained; Select the target level with the minimum total cost from all candidate target levels as the optimal code generation target level; The code generation strategy is determined based on the optimal code generation target level.

7. The method for automatic resolution of permissions in multi-source heterogeneous reports according to claim 6, characterized in that, This also includes performing runtime behavior auditing after the permission management code is deployed and takes effect, comparing it with the authorization scope of the conflict resolution, and detecting unauthorized behavior, including: Collect user operation logs separately and map them to a preset format; Perform the following violation checks on the user operation logs of a user set within a specified time range: Unauthorized operation: If the user operation log records that the user performed the first operation, but the user's operation permission O does not include the first operation, then it is marked as unauthorized operation. Data scope exceeding authority: If there is a difference between the accessScope recorded in the user operation log and the effectiveScope of the permission decision, it is marked as data scope exceeding authority, and the record is out of scope; Sensitivity Constraint Exceeding Authority: Obtain the sensitivity configuration of the report corresponding to the user operation log, perform an unauthorized operation adjudication on the operation, and if the adjudication result is DENY but the log shows that the operation has been executed, mark it as sensitivity exceeding authority and record the sensitivity level; Temporary permission abuse: If the user permission risk flag includes CROSS_ORG_EXPANSION, the operation frequency of the user during the validity period of the temporary permission is counted and compared with the baseline of the daily average number of operations during the permanent permission period. If the operation frequency during the temporary permission period exceeds the threshold multiple of the daily average frequency during the permanent permission period, it is marked as temporary permission abuse, and the frequency ratio is recorded. Permission configuration drift detection: For each tool, read back its permission configuration for a sampled user set and compare it with the most recent compilation output. If they are inconsistent, mark it as permission drift and record the description of the difference. Abnormal behavior pattern detection: For each user, the frequency of their operations, the range of data, and the distribution of operation types within the analysis time range are statistically analyzed as recent behavioral characteristics. These are compared with the historical baseline. If the deviation exceeds the threshold, it is marked as abnormal behavior, and the deviation description is recorded. Output the total number of violations, violation details, and compliance rate.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images