Data access control method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a data access control method and device, equipment, a storage medium and a program product, and relates to the field of financial science and technology. According to the method, each asset table in data assets is pre-registered according to a plurality of pre-divided logic isolation units, an isolated asset list is generated, then a data access request issued by a target user is responded, and if a target asset table exists in the isolated asset list, the data access request is sent to the target user based on the role and the service attribute of the target user. According to the method and the device, the data access request is subjected to permission decision making according to the preset access control strategy, the access control instruction is generated, and the access result of the target user is obtained from the isolation asset list based on the access control instruction, so that the technical effect of dynamically adjusting the access permission based on roles and service attributes is realized; and the access control strategies comprise table-level, row-level, column-level and other granularity access control strategies, so that multi-department fine granularity data authority management requirements under different service scenes are met.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of financial technology, and in particular to a data access control method and device, equipment, storage medium and program product. BACKGROUND

[0002] With the expansion of enterprise data assets, the access requirements of different departments, business units and business teams for data are increasingly complex, for example: the finance department needs to access financial statement data, the risk control department needs to call customer credit data, and the marketing department needs to analyze customer behavior data, and these data are often distributed in different databases, clusters or business systems.

[0003] Traditional data permission management methods, such as role-based access control, require manual resetting of hundreds of permissions when employees are transferred across departments, which is difficult to meet the dynamic adjustment requirements and is inefficient and prone to errors. In this method, when resetting the permissions of an employee, all old roles bound to the employee need to be identified and removed from the employee's permission configuration, and then a new post role is added to the employee's permission configuration. This process is a batch operation, providing a more convenient data management method.

[0004] Therefore, the prior art has the technical problem of insufficient dynamic adjustment capability and inability to meet the flexible and fine-grained data permission management requirements of multiple departments and multiple business scenarios in an enterprise. SUMMARY

[0005] The present application provides a data access control method, device, equipment, storage medium and program product to solve the technical problem of insufficient dynamic adjustment capability and inability to meet the flexible and fine-grained data permission management requirements of multiple departments and multiple business scenarios in an enterprise.

[0006] In a first aspect, the present application provides a data access control method, comprising:

[0007] According to the pre-divided multiple logical isolation units, pre-registering each asset table in the data assets to generate an isolated asset list;

[0008] In response to a data access request issued by a target user, if the target asset table accessed by the data access request exists in the isolated asset list, then based on the role and business attribute of the target user and the pre-set access control policy, the data access request is subjected to permission decision to generate an access control instruction;

[0009] Based on the access control instruction, the access result of the target user is obtained from the isolated asset list.

[0010] In one possible implementation, based on the access control instruction, the access result of the target user is obtained from the isolated asset list, comprising:

[0011] Based on the table-level access permissions in the access control directives, and the mapping relationship between the user group and the asset table group to which the target user belongs in the isolated asset list, determine the target asset table that the target user is allowed to access;

[0012] Based on the row-level isolation rules in the access control directives, filter the data rows in the target asset table that the target user can access;

[0013] Based on the data rows accessible to the target user, generate access results.

[0014] In one possible implementation, based on the data rows accessible to the target user, the access result is generated, including:

[0015] Based on the column-level desensitization rules in the access control directive, sensitive fields in the data rows accessible to the target user are desensitized to obtain the access results.

[0016] In one possible implementation, based on the target user's role and business attributes, as well as a preset access control policy, permission decisions are made for data access requests, and access control instructions are generated, including:

[0017] Obtain the target user's role and business attributes;

[0018] Input the target user's role and business attributes into the access control policy to make multi-dimensional permission decisions and determine the table-level access permission, row-level isolation rules and column-level de-identification rules corresponding to the target user;

[0019] Based on the table-level access permissions, row-level isolation rules, and column-level data masking rules corresponding to the target user, access control instructions are generated.

[0020] In one possible implementation, based on multiple pre-defined logical isolation units, each asset table in the data asset is pre-registered to generate an isolated asset list, including:

[0021] The asset tables in the data assets are classified according to business scenarios, and logical isolation units are assigned to multiple asset table groups.

[0022] Users are divided into multiple user groups based on their identity and business information;

[0023] Based on the permissions and business scope of the roles associated with each user group, determine the first mapping relationship between the user group and the asset table group, and the second mapping relationship between the user group and the asset table group.

[0024] Based on the first mapping relationship, the second mapping relationship, and the logical isolation units corresponding to multiple asset table groups, an isolated asset list is generated.

[0025] In one possible implementation, after obtaining the target user's access result from the list of isolated assets based on access control instructions, the method further includes:

[0026] Collect and record the access information of the target user during this visit, form an access log, and store it;

[0027] Periodically extract the permission configuration status of each user from the stored access logs to obtain the historical permission configuration of each user;

[0028] Compare each user's historical permission configuration with the current permission configuration corresponding to the isolated asset list to identify permission configurations that have not taken effect;

[0029] Clean up any ineffective permission configurations;

[0030] Based on the cleanup results, update the access control policy.

[0031] Secondly, this application provides a data access control device, comprising:

[0032] The registration module is used to pre-register each asset table in the data asset according to multiple pre-divided logical isolation units, and generate an isolated asset list;

[0033] The decision module is used to respond to data access requests issued by target users. If the target asset table accessed by the data access request exists in the isolated asset list, the module will make permission decisions on the data access request based on the target user's role and business attributes, as well as the preset access control policy, and generate access control instructions.

[0034] The access module is used to obtain the access results of the target user from the list of isolated assets based on access control instructions.

[0035] In one possible implementation, the above-mentioned apparatus further includes: a determining module, a filtering module, and a generating module;

[0036] The determination module is used to determine the target asset tables that the target user is allowed to access based on the table-level access permissions in the access control instructions and the mapping relationship between the user group and the asset table group to which the target user belongs in the isolated asset list.

[0037] The filtering module is used to filter the data rows that the target user can access in the target asset table according to the row-level isolation rules in the access control instructions;

[0038] The generation module is used to generate access results based on the data rows accessible to the target user.

[0039] In one possible implementation, the above-mentioned device further includes: a processing module;

[0040] The processing module is used to perform desensitization processing on sensitive fields in the data rows accessible to the target user according to the column-level desensitization rules in the access control instructions, and obtain the access results.

[0041] In one possible implementation, the above-mentioned apparatus further includes: an acquisition module;

[0042] The acquisition module is used to acquire the target user's role and business attributes;

[0043] The decision module is specifically used to input the target user's role and business attributes into the access control policy, perform multi-dimensional permission decisions, and determine the table-level access permission, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

[0044] The generation module is also used to generate access control instructions based on the table-level access permissions, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

[0045] In one possible implementation, the above-mentioned device further includes: a partitioning module;

[0046] The processing module is also used to classify the asset table products in the data assets according to business scenarios and allocate logical isolation units to multiple asset table groups;

[0047] The segmentation module is used to divide users into multiple user groups based on their identity information and business information;

[0048] The determination module is also used to determine the first mapping relationship between user groups and asset table groups, and the second mapping relationship between user groups and asset table groups, based on the permissions and business scope of the roles associated with each user group.

[0049] The generation module is also used to generate an isolated asset list based on the first mapping relationship, the second mapping relationship, and the logical isolation units corresponding to multiple asset table groups.

[0050] In one possible implementation, the above-mentioned device further includes: a data acquisition module, an extraction module, an identification module, and an update module;

[0051] The data collection module is used to collect and record the access information of the target user during this visit, form an access log, and store it.

[0052] The extraction module is used to periodically extract the permission configuration status of each user from the stored access logs to obtain the historical permission configuration of each user.

[0053] The identification module is used to compare the historical permission configurations of each user with the current permission configurations corresponding to the isolated asset list, and to identify permission configurations that have not taken effect.

[0054] The processing module is also used to clean up ineffective permission configurations;

[0055] The update module is used to update access control policies based on the cleanup results.

[0056] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0057] The aforementioned memory stores instructions executed by the computer;

[0058] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0059] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0060] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0061] This application provides a data access control method, apparatus, device, storage medium, and program product. The method pre-registers asset tables within a data asset based on pre-divided logical isolation units to generate an isolated asset list. In response to data access requests from target users, if the target asset table exists in the isolated asset list, the method makes permission decisions based on the target user's role and business attributes, as well as preset access control policies, generating an access control instruction. Based on this instruction, the method retrieves the target user's access result from the isolated asset list. The preset access control policies include table-level, row-level, and column-level access control policies. This method combines the target user's role, business attributes, and multi-level access control policies to determine the target user's access permissions, achieving the technical effect of dynamically adjusting access permissions based on roles and business attributes. Furthermore, the three-tiered access control policies (table-level, row-level, and column-level) support fine-grained data permission management needs across different business scenarios and multiple departments. Attached Figure Description

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

[0063] Figure 1 A flowchart illustrating the data access control method provided in the embodiments of this application. Figure 1 ;

[0064] Figure 2 A flowchart illustrating the data access control method provided in the embodiments of this application. Figure 2 ;

[0065] Figure 3 A schematic diagram of the data access control device provided in this application;

[0066] Figure 4 A schematic diagram of the structure of the electronic device provided in this application.

[0067] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0068] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0069] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0070] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0071] It should be noted that the data access control methods, devices, equipment, storage media, and program products provided in this application can be used in the field of fintech, or in any field other than fintech. The application fields of the data access control methods, devices, equipment, storage media, and program products in this application are not limited.

[0072] First, let me explain the terms used in this application:

[0073] SQL (Structured Query Language) is a database language with multiple functions such as data manipulation and data definition.

[0074] The specific application scenario of this application is data access and permission management in multi-department and multi-business scenarios within an enterprise or organization. As the scale of enterprise data assets expands, the data access needs of different departments, business units and business teams become increasingly complex. For example, the finance department needs to access financial statement data, the risk control department needs to access customer credit data, and the marketing department needs to analyze customer behavior data. This data is often distributed in different databases, clusters or business systems.

[0075] Traditional data access control methods, such as role-based access control, require manually resetting hundreds of permissions when employees move between departments. They cannot dynamically adjust data access permissions based on changes in user role, access time, and access location, and are inefficient and prone to errors. This new method, however, identifies all old roles bound to the employee when resetting permissions, removes all old roles from the employee's permission configuration, and then adds the new role to the employee's permission configuration. This process is a batch operation, providing a simpler data management method.

[0076] However, enterprises have increasingly stringent requirements for data security, necessitating fine-grained access control at the row and field levels to prevent the leakage of sensitive information. For example, banks need to ensure that users of different branches can only access customer data within their local area, or to perform differentiated anonymization processing on fields such as ID numbers and account information.

[0077] Existing technologies suffer from insufficient dynamic adjustment capabilities and cannot meet the technical needs of enterprises for flexible and fine-grained data access control across multiple departments and business scenarios.

[0078] The data access control method provided in this application responds to data access requests issued by target users. Based on the target user's role and business attributes, as well as preset access control policies, it makes permission decisions on the data access requests, generates access control instructions, and obtains the target user's access results from the isolated asset list based on these instructions. The preset access control policies include table-level, row-level, and column-level access control policies, achieving the technical effect of dynamically adjusting access permissions based on roles and business attributes. Furthermore, it supports fine-grained data permission management needs across different business scenarios and multiple departments.

[0079] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0080] Figure 1 A flowchart illustrating the data access control method provided in the embodiments of this application. Figure 1 .like Figure 1 As shown, the method includes:

[0081] S101. Based on the pre-divided multiple logical isolation units, perform pre-registration processing on each asset table in the data assets to generate an isolated asset list.

[0082] In this context, a logical isolation unit refers to a unit that logically isolates data assets by tenant (such as department or business unit). This logical isolation unit is used, for example, to enable independent management of data assets across different branches of a bank. For instance, in a banking scenario, independent logical isolation units are pre-established for branches in region A and region B.

[0083] Specifically, a logical isolation unit is allocated for each tenant, and data assets to be registered are determined from the tenant's data assets based on business needs. These data assets are then registered in the tenant's logical isolation unit, and access control policies are preset for each data asset to be registered, resulting in an isolated asset list. These data assets include, but are not limited to: asset clusters, asset libraries, and asset tables.

[0084] This method isolates data assets by tenant through a pre-registration mechanism of logical isolation units, avoiding cross-tenant data leakage and significantly reducing maintenance costs.

[0085] S102. In response to a data access request issued by the target user, if the target asset table accessed by the data access request exists in the isolated asset list, then based on the target user's role and business attributes, as well as the preset access control policy, the access permission decision is made for the data access request, and an access control instruction is generated.

[0086] Data access requests include, but are not limited to: the target asset table, user attributes, and SQL request statements. Access control policies include, but are not limited to: table-level access control policies, row-level access control policies, and column-level access control policies. Table-level access control policies are used to restrict user access permissions to the asset table through user group-table group mapping; row-level access control policies are used to filter data rows in the asset table that users do not have access to; and column-level access control policies use de-identification functions to de-identify fields in the asset table.

[0087] For the target table in the SQL request statement of the data access request, obtain the metadata of the target table. The metadata contains the access control policy of the target table, which includes at least one of the table-level access control policy, row-level access control policy and column-level access control policy.

[0088] By combining the target user's role and business attributes with preset access control policies, permission decisions are made to determine the target user's access permissions to the target query table and the target query data in the data access request. For example, when the access control policies include table-level, row-level, and column-level access control policies, permission decisions are made for the data access request in the order of table-level, row-level, and column-level, based on the target user's role and business attributes, and in conjunction with the table-level, row-level, and column-level access control policies. This determines the target user's access permissions at the table, row, and column levels, and then the data access request is modified based on these access permissions to obtain access control instructions.

[0089] Furthermore, the settings for table-level access control policies, row-level access control policies, and column-level access control policies are explained:

[0090] (a) Table-level access control policy

[0091] For any given tenant among multiple tenants, determine at least one classification dimension according to business needs, and divide the multiple users within that tenant into multiple user groups based on this at least one classification dimension. Each user group corresponds to a different classification category. Classification dimensions can be, for example, user roles and business attributes, and classification categories can be, for example, auditor groups, modeling competition participants groups, and the first project group. For instance, classifying multiple users based on job roles could result in user groups such as a data analyst group and a finance group.

[0092] Furthermore, for multiple asset tables within each logically isolated unit, target classification dimensions are determined according to business needs, and these asset tables are divided into multiple asset table groups based on these target classification dimensions. Each asset table group corresponds to a different classification category. Examples of classification categories include: Human Resources and Credit Investigation. The task is to establish a mapping relationship between each asset table group and a user group, and store this mapping relationship in the isolated asset list. User groups can then view the asset tables within the mapped asset table groups.

[0093] After obtaining multiple asset table groups and multiple user groups, a mapping relationship is established between the asset table groups and user groups according to business needs and / or security management rules. This mapping relationship is then stored in an isolated asset list to determine whether a target user has access rights to the target access table when executing table-level access control policies.

[0094] Additionally, when generating asset table groups, a table group category identifier is generated for each asset table group, and this identifier is added to the metadata of the asset table belonging to the corresponding asset table group. Asset table groups can be, for example, financial table groups and customer information table groups.

[0095] It should be noted that an asset table belongs to only one asset table group. If an asset table does not carry a table group identifier, only the creator of the asset table (i.e., the tenant corresponding to the logical isolation unit) can view the asset table. Furthermore, an asset table group contains at least one asset table. A user can be in multiple user groups, and a user group includes multiple users.

[0096] (ii) Row-level access control policy

[0097] Row-level access control policies include: general isolation policies and complex isolation policies.

[0098] I. General Isolation Strategy

[0099] Multiple isolation types are created, and an isolation type identifier is set for each isolation type. Each isolation type is associated with an isolation table. This isolation table is used to store the mapping relationship between user groups and isolation fields, and this mapping relationship is used to indicate whether user groups have access permissions to the corresponding isolation fields.

[0100] Furthermore, the aforementioned isolation type identifier is added to the metadata of the asset table to which each isolation field in the isolation table belongs. When accessing the asset table, the isolation table can be invoked based on the isolation type identifier in the asset table metadata to confirm the user's row-level access permissions. Isolation fields can be, for example, host area code and phone number location code, and user groups can be, for example, Nanjing branch group and Beijing branch group.

[0101] II. Complex Isolation Strategies

[0102] Multiple isolation policies are configured to dynamically filter data rows based on these policies. Each isolation policy is a template containing a main table placeholder, attribute label placeholders, and at least one secondary table. In the aforementioned table-level access control policies, users belong to at least one user group. The category of each user group is the attribute label for the users within that group. Each user is associated with at least one attribute label, which could be, for example, a label for the Nanchang branch or a label for the Shanghai branch.

[0103] In the aforementioned isolation templates, at least one of the sub-tables is set up based on the asset table necessary for business access. Each asset table corresponds to at least one isolation template. The sub-tables are modified by relevant personnel based on changes in business data, or changes are driven by updates to the sub-tables and / or increases / decreases in the data sources of the main table involved in the template.

[0104] (iii) Column-level access control policy

[0105] Column-level access control policies include standard masking policies, classification and hierarchical masking policies, and association masking policies.

[0106] I. Standard Desensitization Strategies

[0107] For any given tenant across multiple tenants, based on data security management standards and data supervision requirements, the users within that tenant are divided into multiple sensitive groups. These sensitive groups include: Category 1 sensitive group, Category 2 sensitive group, and special user group. Furthermore, sensitive type identifiers are set for fields requiring de-identification, such as sensitive types for mobile phone numbers and names. Further, a mapping relationship is established between sensitive groups and field sensitive type identifiers, and a sensitive function is assigned to each mapping relationship. This ensures that users in different user groups receive different data results when accessing the same type of sensitive field.

[0108] II. Classification and Grading Desensitization Strategies

[0109] The fields to be anonymized are categorized and graded to obtain category and grade identifiers, which include: the field's category identifier and its sensitivity level identifier. For example, business data is a first-level category, and account information is a second-level category. Different anonymization functions correspond to sensitive fields with different categories and grades. For example, sensitive fields with a category grade of three or higher correspond to a full anonymization function, while sensitive fields with a category grade of two correspond to a partial anonymization function.

[0110] Optionally, each level corresponds to at least one category of sensitive fields. Based on business needs, separate desensitization functions are set for specific sensitive fields. For example, the five-level category corresponds to fields such as ID number, address, name, and account number. Different desensitization functions are set for different fields according to business needs.

[0111] III. Association-based desensitization strategies

[0112] Extract sensitive field identifiers containing sensitive fields from the asset table, and construct a sensitive data table using multiple sensitive field identifiers. Additionally, configure associated desensitization strategy identifiers in the metadata of sensitive fields in the asset table to invoke the corresponding associated desensitization strategy and perform desensitization processing on the data corresponding to that sensitive field.

[0113] Set association-based data masking strategies for masked fields. These strategies include, but are not limited to: association-based data masking strategy identifiers, association conditions, masked fields, and corresponding masking functions. The association conditions indicate the correspondence between the asset table, fields within the asset table, and sensitive fields / data tables. For example, the association condition `Customer Information Table.Customer Number = First Type Customer Number Table.First Type Customer Number` indicates that when the target query table is the Customer Information Table, the corresponding sensitive data table is the First Type Customer Number Table.

[0114] Furthermore, based on the sensitive fields in the aforementioned desensitization strategy, the data to be desensitized corresponding to the first type of customer ID is determined. The aforementioned desensitization function is used to indicate the desensitization method for the desensitized fields. Examples of the data to be desensitized corresponding to the first type of customer ID include: address, employer, and personal profile.

[0115] Based on the above explanation of table-level, row-level, and column-level access control policies, the specific access control policy corresponding to a target user is determined by the target user's user role and business attributes. When the target user's user role and business attributes change, the corresponding access control policy changes. Therefore, this method achieves dynamic adjustment of access control policies.

[0116] S103. Based on access control instructions, obtain the access results of the target user from the list of isolated assets.

[0117] The access control directives include, but are not limited to, at least one of table-level access control policies, row-level access control policies, and column-level access control policies, as well as the target query table identifier and the target data field.

[0118] Execute access control instructions, determine the cluster and database to which the target query table belongs from the isolated asset list based on the target query table identifier in the access control instructions, perform hierarchical permission control based on the access control policy, and output the access results corresponding to the target data fields.

[0119] For example, if the target user has permission to access the target query table, filter rows in the target data fields that the target user does not have access to, and / or perform desensitization processing on sensitive fields that the target user does not have access to, to obtain the access results.

[0120] The data access control method provided in this embodiment pre-registers each asset table in the data asset according to multiple pre-divided logical isolation units to generate an isolated asset list. Then, in response to a data access request from a target user, if the target asset table accessed by the data access request exists in the isolated asset list, the method makes permission decisions based on the target user's role and business attributes, as well as preset access control policies, generates an access control instruction, and obtains the target user's access result from the isolated asset list based on the access control instruction. The preset access control policies include table-level, row-level, and column-level access control policies. This method combines the target user's role, business attributes, and multi-level access control policies to determine the target user's access permissions, achieving the technical effect of dynamically adjusting access permissions based on roles and business attributes. Furthermore, the three-layer access control policy from table-level to row-level to column-level supports the fine-grained data permission management needs of multiple departments in different business scenarios.

[0121] Figure 2 A flowchart illustrating the data access control method provided in the embodiments of this application. Figure 2 ,like Figure 1 As shown, in this embodiment... Figure 3 Based on the embodiments, a possible data access control method is described in detail, the method including:

[0122] S201. Classify the asset tables in the data assets according to business scenarios, and allocate logical isolation units to multiple asset table groups.

[0123] These business scenarios include, but are not limited to: risk control scenarios, credit scenarios, customer relationship management and financial management scenarios.

[0124] For any tenant among multiple tenants, the tenant's multiple asset tables are categorized according to business scenarios to obtain multiple asset table groups. Logical isolation units are then assigned to these asset table groups, and the multiple asset tables are registered to these logical isolation units. For example, asset tables in Department 1 are categorized according to business scenarios to obtain multiple asset table groups. Logical isolation units are then assigned to these asset table groups, and the multiple asset tables of Department 1 are registered to these logical isolation units. The registered information includes, but is not limited to, the cluster and database to which the asset table belongs.

[0125] Understandably, each asset table represents a specific business scenario.

[0126] This method stores each asset table in the asset table group in a logically isolated unit, pre-plans the table assets that tenants can access, and reduces the data security risks caused by unauthorized access.

[0127] S202. Based on the user's identity information, business attributes, and associated roles, the user is divided into multiple user groups.

[0128] Among them, identity information includes, for example, the user's department; business attributes include, for example, the jurisdiction and the products or projects the user is responsible for; business attributes include, for example, the jurisdiction, the scope of responsibilities and the products or projects the user is responsible for; and the user's associated roles include, for example, junior teller, senior approver, risk controller, etc.

[0129] Specifically, users are divided into multiple user groups based on their identity information and associated roles. Each user group corresponds to at least one category. These categories could be, for example, First Project, Account Manager Department, Senior Auditor, Credit Approval Department, or Risk Control Department.

[0130] S203. Based on the permissions and business scope of the roles associated with each user group, determine the first mapping relationship between the user group and the asset table group, and the second mapping relationship between the user group and the asset table group.

[0131] Multiple users are divided into multiple user groups based on their associated roles. Each user group corresponds to a different role. Based on the permissions associated with that role, a first mapping relationship is established between the user groups and the asset table group.

[0132] Multiple users are divided into multiple user groups based on their identity information and business attributes. Each user group corresponds to a different category, such as different departments and different business types. Based on the business scope of different departments and the business scope corresponding to different business types, the asset tables that each user group has access to are determined, and a second mapping relationship between user groups and asset table groups is established.

[0133] For example, the first mapping relationship mentioned above is such as senior approver and loan application form, and the second mapping relationship mentioned above is such as risk control department and risk report.

[0134] S204. Based on the first mapping relationship, the second mapping relationship, and the logical isolation units corresponding to multiple asset table groups, generate an isolated asset list.

[0135] Based on the first mapping relationship, the second mapping relationship, and the logical isolation unit that stores information from multiple asset tables, an isolated asset list is generated.

[0136] In this method, when a user within each tenant performs a data query, the system will only search the isolated asset list corresponding to that tenant, thus ensuring data security.

[0137] For example, the isolated asset list includes: an asset cluster field, an asset library field, an asset table field, and a user group field corresponding to the asset table. By dividing users within a tenant, M user groups are obtained. By dividing data assets according to business scenarios, N asset table groups are obtained. As described in step S203 above, a mapping relationship is established between asset table groups and user groups. In this mapping relationship, each user in a user group has access to multiple asset tables within the asset table group. The aforementioned user groups include, but are not limited to: an auditor group and a modeling competition participant group. Asset table group categories include, but are not limited to: special personnel information table category, credit category, and human resources category. Here, M and N are positive integers.

[0138] Understandably, based on the mapping relationship between user groups and asset table groups, the mapping relationship between users and tables is determined, and this mapping relationship is stored in the isolated asset list.

[0139] S205. In response to a data access request issued by the target user, if the target asset table accessed by the data access request exists in the isolated asset list, obtain the target user's role and business attributes.

[0140] Upon receiving a data access request from a target user, the system searches the list of isolated assets corresponding to the tenant to which the target user belongs to determine whether the target asset table exists in the isolated asset table. If it does, the system makes an access control decision on the data access request based on the access control policy. If not, the system determines that the target user does not have access rights to the aforementioned target asset table.

[0141] If the target asset table is confirmed to exist in the isolated asset list, the target user's metadata is obtained based on the target user identifier in the data access request. This metadata includes multiple user attributes, including roles and business attributes. The target user identifier can, for example, be used to register a CNC system account for the target user. The aforementioned metadata can, for example, be stored in a user database.

[0142] S206. Input the target user's role and business attributes into the access control policy, make multi-dimensional permission decisions, and determine the table-level access permission, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

[0143] The access control policies include: table-level access control policies, row-level access control policies, and column-level access control policies. As explained in step S102 above, row-level access control policies include two isolation methods, and column-level access control policies include three types of data masking.

[0144] First, based on the target user's role and business attributes, determine at least one target user group to which the target user belongs from the isolated asset list, and then determine the table-level access permission, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

[0145] (a) Determine table-level access permissions

[0146] Identify at least one asset table group that has a mapping relationship with at least one target user group. Determine whether the target asset table exists among multiple asset tables in the at least one asset table group, and generate a table-level access permission based on the determination result. For example, if the target asset table exists among the multiple asset tables, a first table-level access permission is generated, which indicates that access is allowed and includes a first table-level access permission identifier. Furthermore, if the target asset table does not exist among the multiple asset tables, a second table-level access permission is generated, which indicates that access is not allowed and includes a second table-level access permission identifier.

[0147] (ii) Determine row-level isolation rules

[0148] Based on the row-level isolation identifier in the metadata of the target asset table, determine the corresponding row-level access control policy.

[0149] Optionally, when the above row-level isolation identifier is an isolation type identifier, a general isolation strategy is used to make row-level permission decisions.

[0150] Specifically, the isolation table corresponding to the isolation type identifier mentioned above is invoked. Based on the user group corresponding to the target user, at least one isolation field corresponding to the user group is determined from the isolation table, and the data corresponding to the isolation field is retrieved from the target asset table. Then, based on the isolation field mentioned above and its corresponding data in the target asset table, row-level isolation rules are generated.

[0151] For example, if the isolation field is `branch_code`, and the data corresponding to this isolation field found in the target asset table is `SH`, then the generated row-level isolation rule would be: `branch_code = 'SH'`, where `SH` is the code corresponding to the Shanghai branch.

[0152] Optionally, when the isolation identifier includes at least one isolation template identifier, at least one isolation template associated with the target asset table is invoked, and the main table placeholder in the isolation template is replaced with the target asset table name from the data access request. Furthermore, the isolation label placeholder in the isolation template is replaced with the user attributes of the target user, resulting in a row-level isolation rule. The user attributes include, but are not limited to, the user's associated role and business attributes. An isolation label placeholder, for example, is {USER_GROUPS}, where USER_GROUPS represents a placeholder for the user's department field.

[0153] For example, the data access request is parsed to obtain parsed data, which includes: the target asset table name is t_customer_info, and the main table placeholder in the isolation template can be, for example, {MAIN_TABLE}. After identifying the placeholder, the target query table, i.e. the name of the target asset table, is obtained from the above parsed data and replaced with the main table placeholder.

[0154] (iii) Determine column-level isolation rules

[0155] The data access request includes at least one target query field. The corresponding column-level isolation strategy is determined based on the column-level isolation identifier in the metadata of each target query field.

[0156] Optionally, if the column-level isolation identifier of the target query field is a field sensitivity type identifier, the isolation table corresponding to that field sensitivity type identifier is called. In this isolation table, the sensitive field corresponding to the target user group to which the target user belongs is the aforementioned target query field. The desensitization function corresponding to the aforementioned target user group and the sensitive field is determined, and this desensitization function is the column-level isolation rule.

[0157] Optionally, if the column-level isolation identifier of the target query field is a classification / level identifier, then the corresponding classification / level table is called according to the field identifier of the target query field, and the sensitive function corresponding to the above classification / level identifier in the classification / level table is determined. This desensitization function is the column-level isolation rule.

[0158] Optionally, if the column-level isolation identifier of the target query field is a related desensitization strategy identifier, the corresponding related desensitization strategy is called based on the related desensitization strategy. Based on the sensitive data table and sensitive field in the related conditions of the related desensitization strategy, as well as the desensitization function corresponding to each sensitive field, a column-level isolation rule is generated.

[0159] Understandably, de-identification functions include, but are not limited to: keyword replacement functions, partial character hiding functions, full character replacement functions, and encryption functions. For example, an encryption function can be an AES symmetric encryption function; for instance, using this function to encrypt a customer's address would result in ciphertext FJUIhuJ000Q2.

[0160] S207. Generate access control instructions based on the table-level access permission, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

[0161] Based on table-level access permissions, row-level isolation rules, and column-level data masking rules, data access requests are rewritten to obtain access control instructions.

[0162] For example, a data access request might be: SELECT cust_id, cust_name FROM t_customer_info. If the row-level isolation rule is WHERE branch_code = 'SH', then based on this rule, the data access request can be rewritten as: SELECT cust_id, cust_name FROM t_customer_info WHERE branch_code = 'SH'.

[0163] S208. Based on the table-level access permissions in the access control directives and the mapping relationship between the user group and the asset table group to which the target user belongs in the isolated asset list, determine the target asset table that the target user is allowed to access.

[0164] In this context, the table-level access permission in the access control directive indicates that the target user has the right to access the target asset table. The isolated asset list stores the target asset list. Based on the mapping relationship between the user group to which the target user belongs and the asset table group, the specific target asset table is determined from the asset table group, and the storage path of the target asset table registered in the isolated asset list is obtained. This storage path includes the database and cluster to which the target asset table belongs, and then the target asset table that the target user is allowed to access is determined based on the storage path.

[0165] S209. Based on the row-level isolation rules in the access control directive, filter the data rows that the target user can access in the target asset table.

[0166] A row-level isolation rule determined based on a general isolation strategy is as follows: `SELECT * FROM main_table WHERE number_location IN (SELECT isolation_field FROM Nanchang_branch_isolation_table)`. According to the `SELECT isolation_field FROM Nanchang_branch_isolation_table`, at least one isolation field accessible to the target user is retrieved from the Nanchang_branch_isolation_table table. Executing the above statement filters the number's location based on this at least one isolation field. If the number's location exists in this at least one isolation field, the corresponding data row is retrieved from the main table, and the query result is returned. This rule ensures that target users belonging to the Nanchang branch can only see records from the Nanchang branch.

[0167] Row-level isolation rules determined by complex isolation strategies dynamically calculate the data rows accessible to users by associating the main table and the sub-table. The sub-table provides the data necessary for the query process. For example, if the target asset table is a customer information table, and the query target includes the customer's risk level, then the sub-table needs to be associated with the risk report table.

[0168] S210. Generate access results based on the data rows accessible to the target user.

[0169] Based on the column-level desensitization rules in the access control directive, sensitive fields in the data rows accessible to the target user are desensitized to obtain the access results.

[0170] Optionally, after obtaining the access results, this document provides a method for identifying and cleaning up ineffective permission configurations by analyzing the logs. This method achieves a closed loop for security auditing and policy management. The method includes: collecting and recording the access information of the target user's current access, forming and storing access logs; periodically extracting the permission configuration status of each user from the stored access logs to obtain the historical permission configurations of each user; comparing the historical permission configurations of each user with the current permission configurations corresponding to the isolated asset list to identify ineffective permission configurations; cleaning up ineffective permission configurations; and updating the access control policy based on the cleaning results.

[0171] The access information includes, but is not limited to: user identification, target asset table information, access time, access terminal address, access channel, permission decision basis, row-level filtering rules, column-level anonymization rules, access results and operation behaviors, such as querying, exporting, copying, etc.

[0172] Specifically, situations such as failure to simultaneously delete the mapping relationship associated with the original role after a user role change, failure to cancel the permissions of the original user group after a user is transferred / leaves the company, and failure to unbind the original access permission after adjusting the isolation unit of the asset table all cause inconsistencies between historical permission configurations and current permission configurations. Therefore, historical permission configurations are identified as effective permission configurations and removed.

[0173] This method automates and intelligently manages permissions by analyzing logs and comparing and cleaning up ineffective permission configurations, and avoids the problems of lag and omissions that exist in manual auditing.

[0174] The data access control method provided in this embodiment reduces the data security risks caused by unauthorized access by classifying asset tables in data assets according to business scenarios and allocating logical isolation units to multiple asset table groups.

[0175] Furthermore, based on user identity information, business attributes, and associated roles, users are divided into multiple user groups. A first mapping relationship between user groups and asset table groups, and a second mapping relationship between user groups and asset tables are determined according to the permissions and business scope of the associated roles in each user group. Then, based on the first and second mapping relationships, the various asset tables obtained from the classification, and their assigned logical isolation units, an isolated asset list is generated. This method, through the mapping relationship between user groups and asset table groups, allows new users to be automatically added to the corresponding user group, thus automatically inheriting all permissions corresponding to that user group. Therefore, this method achieves automated and dynamic adjustment of permissions, improving the efficiency of permission association.

[0176] Furthermore, in response to a data access request from a target user, if the target asset table requested by the data access request exists in the isolated asset list, the target user's role and business attributes are obtained and input into the access control policy for multi-dimensional permission decisions. This determines the target user's corresponding table-level access permission, row-level isolation rules, and column-level masking rules. Based on these rules, an access control instruction is generated. Subsequently, based on the table-level access permission in the access control instruction and the mapping relationship between the target user's user group and asset table group in the isolated asset list, the target asset table that the target user is allowed to access is determined. According to the row-level isolation rules in the access control instruction, the data rows in the target asset table that the target user can access are filtered, and finally, based on these accessible data rows, an access result is generated.

[0177] This method combines user attributes, business scenarios, and access control policies to dynamically adjust permission decisions. For example, when senior executives are transferred across departments, there's no need to manually reset permissions; simply updating the user attributes is sufficient to apply the new access control policies. Furthermore, table-level access control policies restrict which asset tables a user has access to through user group-table group mappings, row-level access control policies dynamically filter data rows through isolation strategies to adapt to complex scenarios, and column-level access control policies achieve differentiated data masking based on the masking functions corresponding to sensitive fields. This method significantly improves the flexibility and real-time performance of permission management while ensuring data security, adapting to the complex needs of enterprises with multiple departments and business scenarios.

[0178] Figure 3 A schematic diagram of the data access control device provided in this application. Figure 4 As shown, the data access control device 30 provided in this embodiment is applied to a participating party, and the device includes:

[0179] The registration module 301 is used to pre-register each asset table in the data asset according to multiple pre-divided logical isolation units, and generate an isolated asset list;

[0180] The decision module 302 is used to respond to data access requests issued by the target user. If the target asset table accessed by the data access request exists in the isolated asset list, the module makes permission decisions on the data access request based on the target user's role and business attributes, as well as the preset access control policy, and generates access control instructions.

[0181] Access module 303 is used to obtain the access results of the target user from the list of isolated assets based on access control instructions.

[0182] In one possible implementation, the above-mentioned apparatus further includes: a determining module 304, a filtering module 305, and a generating module 306;

[0183] The determination module 304 is used to determine the target asset table that the target user is allowed to access based on the table-level access permissions in the access control instructions and the mapping relationship between the user group and the asset table group to which the target user belongs in the isolated asset list.

[0184] The filtering module 305 is used to filter the data rows that the target user can access in the target asset table according to the row-level isolation rules in the access control instructions;

[0185] The generation module 306 is used to generate access results based on the data rows accessible to the target user.

[0186] In one possible implementation, the above-mentioned device further includes: a processing module 307;

[0187] The processing module 307 is used to perform desensitization processing on sensitive fields in the data rows accessible to the target user according to the column-level desensitization rules in the access control instructions, and obtain the access result.

[0188] In one possible implementation, the above-mentioned device further includes: an acquisition module 308;

[0189] Module 308 is used to obtain the target user's role and business attributes;

[0190] Decision module 302 is specifically used to input the target user's role and business attributes into the access control policy, make multi-dimensional permission decisions, and determine the table-level access permission, row-level isolation rules and column-level de-identification rules corresponding to the target user;

[0191] The generation module 306 is also used to generate access control instructions based on the table-level access permission, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

[0192] In one possible implementation, the above-mentioned device further includes: a dividing module 309;

[0193] Processing module 307 is also used to classify asset table products in data assets according to business scenarios and allocate logical isolation units to multiple asset table groups;

[0194] The segmentation module 309 is used to divide users into multiple user groups based on their identity information and business information;

[0195] The determination module 304 is also used to determine the first mapping relationship between user groups and asset table groups, and the second mapping relationship between user groups and asset table groups, based on the permissions and business scope of the roles associated with each user group.

[0196] The generation module 306 is also used to generate an isolated asset list based on the first mapping relationship, the second mapping relationship, and the logical isolation units corresponding to multiple asset table groups.

[0197] In one possible implementation, the above-mentioned device further includes: a data acquisition module 310, an extraction module 311, an identification module 312, and an update module 313;

[0198] The acquisition module 310 is used to collect and record the access information of the target user during this visit, form an access log and store it;

[0199] Extraction module 311 is used to periodically extract the permission configuration status of each user from the stored access logs to obtain the historical permission configuration of each user;

[0200] The identification module 312 is used to compare the historical permission configurations of each user with the current permission configurations corresponding to the isolated asset list, and to identify permission configurations that have not taken effect.

[0201] Processing module 307 is also used to clean up ineffective permission configurations;

[0202] Update module 313 is used to update access control policies based on the cleanup results.

[0203] The data access control device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0204] Figure 4 A schematic diagram of the structure of the electronic device provided in this application. ​ As shown, the electronic device 40 provided in this embodiment includes at least one processor 401 and a memory 402. Optionally, the device 40 further includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0205] In a specific implementation, at least one processor 401 executes computer execution instructions stored in memory 402, causing at least one processor 401 to perform the above-described method.

[0206] The specific implementation process of processor 401 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0207] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0208] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0209] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0210] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0211] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0212] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0213] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0214] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0216] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0217] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0218] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

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

[0220] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0221] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0222] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0223] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0224] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0225] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0226] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0227] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data access control method, characterized in that, include: Based on multiple pre-defined logical isolation units, the asset tables in the data assets are pre-registered to generate an isolated asset list; In response to a data access request issued by a target user, if the target asset table accessed by the data access request exists in the isolated asset list, then based on the target user's role and business attributes, as well as the preset access control policy, an access control instruction is generated for the data access request. Based on the access control instructions, the access result of the target user is obtained from the list of isolated assets.

2. The method according to claim 1, characterized in that, The step of obtaining the access result of the target user from the list of isolated assets based on the access control instructions includes: Based on the table-level access permission in the access control instruction, and the mapping relationship between the user group and the asset table group to which the target user belongs in the isolated asset list, the target asset table that the target user is allowed to access is determined; Based on the row-level isolation rules in the access control instructions, filter the data rows in the target asset table that the target user can access; The access result is generated based on the data rows accessible to the target user.

3. The method according to claim 2, characterized in that, The process of generating the access result based on the data rows accessible to the target user includes: According to the column-level desensitization rules in the access control instructions, the sensitive fields in the data rows accessible to the target user are desensitized to obtain the access result.

4. The method according to claim 3, characterized in that, The step of making permission decisions on the data access request based on the target user's role and business attributes, as well as a preset access control policy, and generating access control instructions includes: Obtain the target user's role and business attributes; The target user's role and business attributes are input into the access control policy to make multi-dimensional permission decisions and determine the table-level access permission, row-level isolation rule, and column-level de-identification rule corresponding to the target user. The access control instruction is generated based on the table-level access permission, row-level isolation rules, and column-level de-identification rules corresponding to the target user.

5. The method according to claim 1, characterized in that, The process of pre-registering each asset table in the data assets based on multiple pre-divided logical isolation units to generate an isolated asset list includes: The asset tables in the data assets are classified according to business scenarios, and the logical isolation units are assigned to multiple asset table groups. Users are divided into multiple user groups based on their identity and business information; Based on the permissions and business scope of the roles associated with each user group, determine the first mapping relationship between the user group and the asset table group, and the second mapping relationship between the user group and the asset table group. Based on the first mapping relationship, the second mapping relationship, and the logical isolation units corresponding to multiple asset table groups, the isolated asset list is generated.

6. The method according to any one of claims 1-5, characterized in that, After obtaining the access result of the target user from the list of isolated assets based on the access control instructions, the method further includes: Collect and record the access information of the target user during this visit, form an access log, and store it; Periodically extract the permission configuration status of each user from the stored access logs to obtain the historical permission configuration of each user; Compare each user's historical permission configuration with the current permission configuration corresponding to the isolated asset list to identify permission configurations that have not taken effect; Clean up any ineffective permission configurations; Based on the cleanup results, update the access control policy.

7. A data access control device, characterized in that, include: The registration module is used to pre-register each asset table in the data asset according to multiple pre-divided logical isolation units, and generate an isolated asset list; The decision module is used to respond to data access requests issued by target users. If the target asset table accessed by the data access request exists in the isolated asset list, then based on the target user's role and business attributes, as well as the preset access control policy, the module makes permission decisions on the data access request and generates access control instructions. The access module is used to obtain the access result of the target user from the list of isolated assets based on the access control instructions.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images