Data security constraint method, system and program product based on embedding of permission attributes
Patent Information
- Application Number
- CN202611102417.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-23
- Publication Date
- 2026-09-25
AI Technical Summary
现有方案将权限规则与语义模型分离维护，权限规则变更需要修改策略引擎配置或SQL生成逻辑，语义模型和权限规则难以保持一致性，新增数据模型时需要同时维护模型定义和权限规则，导致维护成本高、一致性难以保障
[0018]有益效果：本发明通过将权限规则作为语义模型维度定义的元数据属性嵌入，实现了权限逻辑与语义模型的一体化，在权限属性变更时只需修改模型定义，无需维护独立的策略引擎或修改SQL生成逻辑，显著降低了权限管理的复杂度和维护成本；支持RBAC+ABAC混合模型，并支持模型级权限、字段级权限和行权限的多层级控制，可实现精细化权限控制，能够灵活适应不同的权限管理需求；通过差异化越权处理，能有效平衡安全性和可用性；通过AOP注解实现声明式权限控制，解耦权限与业务，提高了系统的可维护性和可扩展性；通过多模型联合查询权限统一机制，实现了跨模型查询时权限的统一传播和继承，有效解决了多模型联合查询场景下的权限冲突问题。
Smart Images
Figure CN122818329A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data security technology, specifically relating to data security constraint methods, systems, and program products based on permission attribute embedding. Background Technology
[0002] With the development of large language model technology, NL2SQL technology (an artificial intelligence technology that automatically converts natural language into structured query language) has been widely used in business intelligence, data analysis, and other fields. Users can query databases by asking questions in natural language, greatly improving the convenience and efficiency of data access. Data security constraints are a key technology for ensuring the security of data access.
[0003] Existing data security constraint schemes mainly include the following: 1. Independent policy engine mode: Permission rules are maintained in an independent policy engine, and permission control conditions are injected into the policy engine after SQL is generated. 2. RBAC (Role-Based Access Control): Data access permissions are controlled through role mapping. 3. ABAC (Attribute-Based Access Control): Permissions are dynamically determined based on user attributes, resource attributes, and environment attributes. 4. SQL rewriting mode: SQL is rewritten before execution, adding permission control conditions (such as adding a WHERE clause).
[0004] However, existing data security constraint technologies still have the following shortcomings: 1. Separation of permission logic and semantic model. Existing solutions maintain permission rules and semantic models separately. Changes to permission rules require modifications to the strategy engine configuration or SQL generation logic. It is difficult to maintain consistency between the semantic model and permission rules. When adding a new data model, both the model definition and permission rules need to be maintained simultaneously, resulting in high maintenance costs and difficulty in ensuring consistency.
[0005] 2. Inability to handle complex privilege escalation scenarios in NL2SQL. Existing solutions struggle to handle various privilege escalation scenarios in NL2SQL, including: user access to a semantic model without permission; user access to a sensitive field but not a specific sensitive field; user access to a row filter that results in an empty row filter result due to no data access; user access to some fields but lacks permission to query fields where the user has no access rights; and aggregated sensitive data where the user lacks permission to access detailed data but aggregation may leak sensitive information.
[0006] 3. Complex permission control for multi-model joint queries. Issues such as how permission rules are inherited between different models, how permission conflicts are handled, and the lack of a unified permission propagation mechanism have not yet been effectively resolved when querying across models. Summary of the Invention
[0007] The purpose of this invention is to provide a data security constraint method, system, and program product based on permission attribute embedding, in order to solve the above-mentioned problems existing in the prior art.
[0008] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a data security constraint method based on permission attribute embedding is provided, including: Embed corresponding permission attributes in the semantic model of each dimension; Receive user query requests and obtain user identity information, which includes user roles and user attributes; By querying user roles using role-based access control methods, the set of RBAC permissions corresponding to user roles is obtained. By parsing user attributes using attribute-based access control methods, the set of ABAC permissions corresponding to user attributes is obtained. Merge the RBAC permission set and the ABAC permission set to obtain the user permission decision result; Based on the user permission decision results and the permission attributes embedded in the semantic models of each dimension, model-level permission checks, field-level permission checks and row-level permission filtering are performed on user query requests to obtain the corresponding permission check results. The query task is executed based on the permission check results to obtain the corresponding query results; The query results are returned to the user, and the user's query request, user identity information, and permission check results are recorded in the permission audit log.
[0009] In one possible design, the permission attributes include role visibility, permission level, row filtering rules, and a list of sensitive fields.
[0010] In one possible design, based on the user permission decision results and the permission attributes embedded in the semantic models of each dimension, the user query request is subjected to model-level permission checks, field-level permission checks, and row-level permission filtering to obtain the corresponding permission check results, including: Determine the accessed semantic model corresponding to the user's query request, as well as the permission attributes embedded in the accessed semantic model; Based on the user permission decision results, a model-level permission check is performed on the user query request to determine whether the user's role permissions are within the visible scope of the accessed semantic model. If the user's role permissions are not within the visible scope of the accessed semantic model, the permission check result is that the user does not have permission to access the model; otherwise... Perform field-level permission checks on user query requests to determine whether they contain sensitive fields from the sensitive field list. If they do, de-identify the corresponding sensitive fields in the user query request to obtain a filtered request; otherwise, directly use the user query request as a filtered request. Based on the row filtering rules embedded in the accessed semantic model, row filtering conditions are constructed using the user permission decision results. The row filtering conditions are then used to perform row-level permission filtering on the filtering requests, resulting in controlled query requests as permission check results.
[0011] In one possible design, the query task performed based on the permission check result to obtain the corresponding query result includes: When the permission check results include a model that the user does not have permission to access, the corresponding unauthorized access model prompt information is generated as a query result.
[0012] In one possible design, the query task performed based on the permission check result to obtain the corresponding query result includes: When the permission check result includes a controlled query request, the controlled query request is intercepted and the SQL is rewritten based on the AOP annotation permission interception method. This generates SQL with permission filtering and executes the SQL with permission filtering to obtain the corresponding query result.
[0013] In one possible design, the desensitization process includes masking or nulling sensitive fields.
[0014] In one possible design, when a user query request contains multiple accessed semantic models, the intersection of the permission attributes of the multiple accessed semantic models is taken using the prohibition priority principle to obtain the cross-model joint permission attribute, or the master model is selected from the multiple accessed semantic models, the permission attribute of the master model is used as the cross-model joint permission attribute, and the permission attributes of each accessed semantic model are replaced with the cross-model joint permission attribute.
[0015] Secondly, a data security constraint system based on permission attribute embedding is provided, including an attribute embedding unit, a request receiving unit, a permission parsing unit, a permission combination unit, a permission checking unit, a query execution unit, and a feedback recording unit, wherein: The attribute embedding unit is used to embed the corresponding permission attributes in the semantic model of each dimension. The request receiving unit is used to receive user query requests and obtain user identity information, which includes user roles and user attributes. The permission parsing unit is used to query user roles through role-based access control methods to obtain the RBAC permission set corresponding to the user roles, and to parse user attributes through attribute-based access control methods to obtain the ABAC permission set corresponding to the user attributes. The permission combination unit is used to merge the RBAC permission set and the ABAC permission set to obtain the user permission decision result. The permission checking unit is used to perform model-level permission checks, field-level permission checks, and row-level permission filtering on user query requests based on user permission decision results and permission attributes embedded in the semantic models of each dimension, and to obtain the corresponding permission check results. The query execution unit is used to execute query tasks based on the permission check results and obtain the corresponding query results. The feedback recording unit is used to send the query results back to the user and record the user's query request, user identity information, and permission check results in the permission audit log.
[0016] Thirdly, a data security constraint system based on permission attribute embedding is provided, including: Memory, used to store instructions; A processor is configured to read instructions stored in the memory and execute the method described in any one of the first aspects above, according to the instructions.
[0017] Fourthly, a computer-readable storage medium is provided, on which instructions are stored, which, when executed on a computer, cause the computer to perform any of the methods described in the first aspect. A computer program product is also provided, which, when executed on a computer, performs any of the methods described in the first aspect.
[0018] Beneficial effects: This invention integrates permission logic with the semantic model by embedding permission rules as metadata attributes defined in the semantic model dimension. When permission attributes change, only the model definition needs to be modified, without maintaining an independent strategy engine or modifying the SQL generation logic, significantly reducing the complexity and maintenance cost of permission management. It supports a hybrid RBAC+ABAC model and multi-level control of model-level, field-level, and row-level permissions, enabling fine-grained permission control and flexibly adapting to different permission management needs. Through differentiated privilege escalation handling, it effectively balances security and availability. Declarative permission control is implemented through AOP annotations, decoupling permissions from business logic and improving system maintainability and scalability. Through a unified permission mechanism for multi-model joint queries, it achieves unified propagation and inheritance of permissions during cross-model queries, effectively solving the permission conflict problem in multi-model joint query scenarios. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1 This is a schematic diagram of the steps in the method of Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the system configuration in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram of the system configuration in Embodiment 3 of the present invention. Detailed Implementation
[0021] It should be noted that the descriptions of these embodiments are intended to aid in understanding the invention and do not constitute a limitation thereof. The specific structural and functional details disclosed herein are merely for describing exemplary embodiments of the invention. However, the invention may be embodied in many alternative forms and should not be construed as being limited to the embodiments described herein.
[0022] It should be understood that, unless otherwise explicitly specified and limited, the corresponding terms should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in the embodiments according to the specific circumstances.
[0023] Specific details are provided in the following description to provide a complete understanding of the exemplary embodiments. However, those skilled in the art will understand that the exemplary embodiments can be implemented without these specific details. For example, apparatus may be shown in block diagrams to avoid obscuring the examples with unnecessary details. In other embodiments, well-known processes, structures, and techniques may be omitted with non-essential details to avoid obscuring the embodiments.
[0024] Example 1: This embodiment provides a data security constraint method based on permission attribute embedding, which can be applied to corresponding data servers, such as... Figure 1 As shown, the method includes the following steps: S1. Embed the corresponding permission attributes in the semantic model of each dimension.
[0025] In practice, when defining each queried semantic model dimension, the corresponding permission attributes can be embedded as metadata attributes into its dimension definition. Permission attributes include: visibleRange (role visibility range): Defines which roles have permission to access this dimension; permissionLevel: Defines the security level for this dimension, including public, internal, confidential, and top secret; rowFilter (row filtering rule): Defines the filtering condition expression for row-level permissions; sensitiveFields (sensitive field list): Defines the sensitive fields that require column-level access control.
[0026] S2. Receive user query requests and obtain user identity information, which includes user roles and user attributes.
[0027] In practice, it can receive user query requests transmitted from the user terminal and obtain user identity information, including user ID, user role and user attributes (such as department, region, job level, etc.).
[0028] S3. Query the user role using the role-based access control method to obtain the RBAC permission set corresponding to the user role. Then, parse the user attribute using the attribute-based access control method to obtain the ABAC permission set corresponding to the user attribute.
[0029] In practice, the user role can be queried using the role-based access control (RBAC) method (role permission matrix query) to determine the RBAC permission set corresponding to the user role; the user attribute can be parsed using the attribute-based access control (ABAC) method (evaluating user attribute conditions and solving attribute expressions) to obtain the ABAC permission set corresponding to the user attribute.
[0030] S4. Merge the RBAC permission set and the ABAC permission set to obtain the user permission decision result.
[0031] In practice, after processing by RBAC and ABAC, the RBAC permission set and the ABAC permission set can be merged (by taking the union) to obtain the user permission decision result.
[0032] S5. Based on the user permission decision results and the permission attributes embedded in the semantic models of each dimension, perform model-level permission checks, field-level permission checks, and row-level permission filtering on user query requests to obtain the corresponding permission check results.
[0033] In practice, the semantic model of the accessed dimension corresponding to the user query request and the permission attributes embedded in the accessed semantic model can be determined first. Then, based on the user permission decision result, a model-level permission check is performed on the user query request to determine whether the user's role permissions are within the role visibility range of the accessed semantic model. If the user's role permissions are not within the role visibility range of the accessed semantic model, the permission check result is that the user has no right to access the model. Otherwise, a field-level permission check is performed on the user query request to determine whether it contains sensitive fields from the sensitive field list. If it does, the corresponding sensitive fields in the user query request are de-identified (masked or nulled) to obtain a filtered request. Otherwise, the user query request is directly used as a filtered request. Then, based on the row filtering rules embedded in the accessed semantic model, row filtering conditions are constructed using the user permission decision result, and row-level permission filtering is performed on the filtered request using the row filtering conditions to obtain a controlled query request as the permission check result.
[0034] Field-level permission checks can also examine the access permissions of each field involved in a user's query request (e.g., checking for access permissions to sensitive fields, and whether the user's role is within the field's visibleRange). If it is determined that some fields lack permissions, dynamic pruning can be performed, returning only the fields with permissions. Additionally, sensitive data aggregation queries can be performed on the fields involved in the user's query request. If certain fields aggregate to form sensitive data, it is determined that aggregated sensitive data exists, and the aggregation operation can be restricted or the display downgraded (e.g., only the range is displayed).
[0035] S6. Execute the query task based on the permission check results to obtain the corresponding query results.
[0036] In practice, when the permission check result includes a model that the user is not authorized to access, a corresponding "unauthorized access" message is generated as the query result. When the permission check result includes a controlled query request, the controlled query request is intercepted using AOP annotation-based permission interception methods (marking methods requiring permission control with the `@S2DataPermission` annotation, intercepting method calls via AOP aspects, executing permission filtering logic, and preserving business logic) and SQL rewriting (using an SQL parsing tool to convert the controlled query request into a structured query statement (SQL), and rewriting the SQL), generating SQL with permission filtering, and executing the SQL with permission filtering to obtain the corresponding query result.
[0037] S7. Return the query results to the user and record the user's query request, user identity information, and permission check results in the permission audit log.
[0038] In practice, the final query results can be fed back to the user. At the same time, the user query requests, user identity information and permission check results generated throughout the query process can be recorded in the permission audit log for subsequent traceability management.
[0039] To further illustrate the principle of multi-level access control, this embodiment provides corresponding application examples: Example 1: For model-level access control: User: Regular Salesperson (Role: Regular Employee); Query request: "Query financial sensitive data"; Permission check: 1. Query target semantic model: financial data model; 2. Check visibleRange: ["Finance Manager", "Finance Supervisor"]; 3. User role: Regular employee; 4. Judgment result: The user's role permissions are not in the visibleRange, and they do not have permission to access the service; Processing result: HTTP status code: 403 Forbidden; Error message: "You do not have permission to access this data model. Please contact the administrator to request access." Audit logs: Record user attempts to access the system without authorization.
[0040] Example 2: Field-level access control (sensitive field masking): User: Regional Manager (Role: Regional Manager); Search: "Search customer information"; Permission check: 1. Users have permission to access the customer information model; 2. Check the fields involved in the query: customer name, customer phone number, customer address, and purchase amount; 3. Check sensitive fields: Customer phone number and customer address are sensitive fields; 4. The user role "Regional Manager" is not in the visibleRange of the sensitive fields; Processing result: Customer Name: Displayed Normally; Customer phone number: Anonymized display (e.g., 138**1234); Customer address: Anonymized display (e.g., Beijing, ** District); Purchase amount: Displayed normally.
[0041] Example 3: Filtering based on row-level permissions: User: North China Regional Manager (Role: Regional Manager, Department: North China Region); Search: "Search nationwide sales data"; Permission check: 1. Users have permission to access the sales data model; 2. Row filtering rule: ${user.dept} IN (range); 3. User Department: North China Region; 4. Generate row filter condition: WHERE region = 'North China'; Processing result: Original SQL: SELECT * FROM sales; SQL after access control: SQL SELECT * FROM sales WHERE region='North China' `; Results returned: Only sales data for the North China region is returned.
[0042] Example 4: Handling permissions for multi-model joint queries: Scenario: The query involves both the sales model and the inventory model; User permissions: Has sales model access (can view data for North China region); Has access to the inventory model (can view nationwide data); Access control: 1. Sales model row filtering: WHERE region = 'North China'; 2. Inventory model row filtering: None (can view nationwide); 3. Joint query permission: Find the intersection (most stringent permission); 4. Final row filter: WHERE region = 'North China'; Processing result: Sales data: Only North China region is displayed; Inventory data: Only North China region is displayed (access reduced).
[0043] This embodiment embeds permission rules as metadata attributes defined in the semantic model dimension, achieving the integration of permission logic and the semantic model. When permission attributes change, only the model definition needs to be modified, without maintaining an independent strategy engine or modifying the SQL generation logic, significantly reducing the complexity and maintenance cost of permission management. It supports a hybrid RBAC+ABAC model and multi-level control of model-level permissions, field-level permissions, and row permissions, enabling fine-grained permission control and flexibly adapting to different permission management needs. Through differentiated privilege escalation handling, it effectively balances security and availability. Declarative permission control is implemented through AOP annotations, decoupling permissions from business logic and improving the maintainability and scalability of the system. Through a unified permission mechanism for multi-model joint queries, it achieves unified propagation and inheritance of permissions during cross-model queries, effectively solving the permission conflict problem in multi-model joint query scenarios.
[0044] Example 2: This embodiment provides a data security constraint system based on permission attribute embedding, such as Figure 2 As shown, it includes an attribute embedding unit, a request receiving unit, a permission parsing unit, a permission combination unit, a permission checking unit, a query execution unit, and a feedback recording unit, wherein: The attribute embedding unit is used to embed the corresponding permission attributes in the semantic model of each dimension. The request receiving unit is used to receive user query requests and obtain user identity information, which includes user roles and user attributes. The permission parsing unit is used to query user roles through role-based access control methods to obtain the RBAC permission set corresponding to the user roles, and to parse user attributes through attribute-based access control methods to obtain the ABAC permission set corresponding to the user attributes. The permission combination unit is used to merge the RBAC permission set and the ABAC permission set to obtain the user permission decision result. The permission checking unit is used to perform model-level permission checks, field-level permission checks, and row-level permission filtering on user query requests based on user permission decision results and permission attributes embedded in the semantic models of each dimension, and to obtain the corresponding permission check results. The query execution unit is used to execute query tasks based on the permission check results and obtain the corresponding query results. The feedback recording unit is used to send the query results back to the user and record the user's query request, user identity information, and permission check results in the permission audit log.
[0045] Example 3: This embodiment provides a data security constraint system based on permission attribute embedding, such as Figure 3 As shown, at the hardware level, it includes: The data interface is used to establish data communication between the processor and external data terminals; Memory, used to store instructions; The processor is configured to read instructions stored in the memory and execute the data security constraint method based on permission attribute embedding in Embodiment 1 according to the instructions.
[0046] Optionally, the system also includes an internal bus, through which the processor, memory, and data interface can be interconnected. This internal bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc.
[0047] The memory may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory. The processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0048] Example 4: This embodiment provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the data security constraint method based on permission attribute embedding in Embodiment 1. The computer-readable storage medium refers to a data storage medium, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or Memory Sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
[0049] This embodiment also provides a computer program product that, when run on a computer, executes the data security constraint method based on permission attribute embedding in Embodiment 1. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
[0050] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A data security constraint method based on permission attribute embedding, characterized in that, include: Embed corresponding permission attributes in the semantic model of each dimension; Receive user query requests and obtain user identity information, which includes user roles and user attributes; By querying user roles using role-based access control methods, the set of RBAC permissions corresponding to user roles is obtained. By parsing user attributes using attribute-based access control methods, the set of ABAC permissions corresponding to user attributes is obtained. Merge the RBAC permission set and the ABAC permission set to obtain the user permission decision result; Based on the user permission decision results and the permission attributes embedded in the semantic models of each dimension, model-level permission checks, field-level permission checks and row-level permission filtering are performed on user query requests to obtain the corresponding permission check results. The query task is executed based on the permission check results to obtain the corresponding query results; The query results are returned to the user, and the user's query request, user identity information, and permission check results are recorded in the permission audit log.
2. The data security constraint method based on permission attribute embedding according to claim 1, characterized in that, The permission attributes include the role visibility scope, permission level, row filtering rules, and sensitive field list.
3. The data security constraint method based on permission attribute embedding according to claim 2, characterized in that, Based on the user permission decision results and the permission attributes embedded in the semantic models of each dimension, the user query request is subjected to model-level permission checks, field-level permission checks, and row-level permission filtering to obtain the corresponding permission check results, including: Determine the accessed semantic model corresponding to the user's query request, as well as the permission attributes embedded in the accessed semantic model; Based on the user permission decision results, a model-level permission check is performed on the user query request to determine whether the user's role permissions are within the visible scope of the accessed semantic model. If the user's role permissions are not within the visible scope of the accessed semantic model, the permission check result is that the user does not have permission to access the model; otherwise... Perform field-level permission checks on user query requests to determine whether they contain sensitive fields from the sensitive field list. If they do, de-identify the corresponding sensitive fields in the user query request to obtain a filtered request; otherwise, directly use the user query request as a filtered request. Based on the row filtering rules embedded in the accessed semantic model, row filtering conditions are constructed using the user permission decision results. The row filtering conditions are then used to perform row-level permission filtering on the filtering requests, resulting in controlled query requests as permission check results.
4. The data security constraint method based on permission attribute embedding according to claim 3, characterized in that, The query task is executed based on the permission check results to obtain the corresponding query results, including: When the permission check results include a model that the user does not have permission to access, the corresponding unauthorized access model prompt information is generated as a query result.
5. The data security constraint method based on permission attribute embedding according to claim 3, characterized in that, The query task is executed based on the permission check results to obtain the corresponding query results, including: When the permission check result includes a controlled query request, the controlled query request is intercepted and the SQL is rewritten based on the AOP annotation permission interception method. This generates SQL with permission filtering and executes the SQL with permission filtering to obtain the corresponding query result.
6. The data security constraint method based on permission attribute embedding according to claim 3, characterized in that, The desensitization process includes masking or nulling sensitive fields.
7. The data security constraint method based on permission attribute embedding according to claim 3, characterized in that, When a user query request contains multiple accessed semantic models, the intersection of the permission attributes of the multiple accessed semantic models is taken according to the prohibition priority principle to obtain the cross-model joint permission attribute, or the master model is selected from the multiple accessed semantic models, the permission attribute of the master model is used as the cross-model joint permission attribute, and the permission attributes of each accessed semantic model are replaced with the cross-model joint permission attribute.
8. A data security constraint system based on permission attribute embedding, characterized in that, It includes an attribute embedding unit, a request receiving unit, a permission parsing unit, a permission combination unit, a permission checking unit, a query execution unit, and a feedback recording unit, wherein: The attribute embedding unit is used to embed the corresponding permission attributes in the semantic model of each dimension. The request receiving unit is used to receive user query requests and obtain user identity information, which includes user roles and user attributes. The permission parsing unit is used to query user roles through role-based access control methods to obtain the RBAC permission set corresponding to the user roles, and to parse user attributes through attribute-based access control methods to obtain the ABAC permission set corresponding to the user attributes. The permission combination unit is used to merge the RBAC permission set and the ABAC permission set to obtain the user permission decision result. The permission checking unit is used to perform model-level permission checks, field-level permission checks, and row-level permission filtering on user query requests based on user permission decision results and permission attributes embedded in the semantic models of each dimension, and to obtain the corresponding permission check results. The query execution unit is used to execute query tasks based on the permission check results and obtain the corresponding query results. The feedback recording unit is used to send the query results back to the user and record the user's query request, user identity information, and permission check results in the permission audit log.
9. A data security constraint system based on permission attribute embedding, characterized in that, include: Memory, used to store instructions; A processor is configured to read instructions stored in the memory and execute the data security constraint method based on permission attribute embedding as described in any one of claims 1-7 according to the instructions.
10. A computer program product, characterized in that, When the computer program product is run on a computer, the data security constraint method based on permission attribute embedding as described in any one of claims 1-7 is executed.