CN110941628A - Data isolation implementation method based on SQL statement interception and analysis technology - Google Patents

Abstract

The patent relates to different data isolation methods required under business functions, in particular to a data isolation implementation method based on an SQL statement interception and analysis technology. A data isolation implementation method based on SQL statement interception and analysis technology is provided, and merging strategies are divided into four types: replacement, addition, overlay, customization. The data isolation requirement of a specific or exceptional scene is met, and the data safety and convenience effects are provided.

Description

Data isolation implementation method based on SQL statement interception and analysis technology

Technical Field

The patent relates to different data isolation methods required under business functions, in particular to a data isolation implementation method based on an SQL statement interception and analysis technology.

Background

At present, data isolation strategies are generally defined only in a data view angle, and for data isolation requirements of specific or exceptional scenes, such as the same system user, when different data isolation strategies are needed under different business functions, effective support cannot be achieved, and a developer needs to customize the data isolation strategies. The data isolation policy does not support flexible extension and customization, and is often only directed to specific business fields. The definition of the personal related data does not meet the actual requirements of the business, and only the data created or modified by the user can be supported.

Disclosure of Invention

In view of the above technical problems, an object of the present invention is to provide a data isolation implementation method based on an SQL statement interception and parsing technique, so as to meet the data isolation requirements of specific or exceptional scenarios and provide data security and convenience effects.

The specific technical scheme of this patent is as follows:

a data isolation implementation method based on SQL statement interception and analysis technology is characterized in that:

the merging strategy is divided into four categories: replacement, addition, overlay, customization;

and (3) replacing: forbidding the isolation rule of data authorization, and completely using the isolation rule defined by DACO;

additionally: on the basis of the data authority based on the service data, data authority control is added; namely: data authority based on service data AND data authority;

covering: when the data authorities of the two mechanisms conflict, the authority in the DACO is used for replacing the data authority based on the service data;

self-defining: the data access controller does not perform any processing, and the data authority is completely handed to the service code to be automatically controlled;

the data authority technology is realized as follows:

1. the method comprises the steps of injecting an SQL interceptor into a data source to intercept access requests of all databases;

2. analyzing the syntax of the intercepted SQL;

3. acquiring data authority according to the accessed target table/view, the current user information and the service operation URL;

4. removing inaccessible columns in the SQL statement according to the data authority;

5. generating WHERE query condition clause according to data authority, and merging the clause to the original sentence according to merging rules

In the query condition of SQL statement;

6. generating a new SQL statement and submitting for execution;

the data isolator mainly comprises the following core steps:

1. SQL interceptor for intercepting SQL access to all databases

2. The SQL processor: is responsible for analyzing SQL sentences and processing SQL according to data authority rules

3. Data access log: the system is responsible for recording data access information (SQL statements, conditions, execution time, executors and the like) and recording data access which is not in compliance.

Data isolation, which is to authorize data accessible by a user, i.e. to control which data (visible data range) a user can view and which attributes of data (visible data content), is specifically performed by: an organization-based authorization policy; it sets up the authorization policy mainly according to the organizational structure, its applicable scene: checking order data of the unit; checking the event data of the department and the subordinate department; checking equipment account information of a designated department; only the person of a certain unit can be checked; only the person of the unit can be selected; these scenarios are all related to the organization to which the data belongs;

the data isolation method comprises the following steps: the following fields are added uniformly in all database tables: the method comprises the steps of creating a person ID, modifying a person ID, a department ID to which the creating person belongs, a unit ID to which the creating person belongs, and an organization ID to which the creating person belongs, and recording the information when data are stored; in the SQL processor, analyzing a conditional rule expression, creating a query expression according to a department ID, a unit ID and an organization ID, and automatically adding the query expression into a query condition; an authorization policy based on the business data attribute; the mechanism is to set an authorization policy according to some attributes of the service data, such as: checking the equipment account with the security level not higher than that of the current user; checking the equipment account with secret level as secret level; checking the equipment account stored in the area A; a device viewing the storage class; these scenarios are only related to the service attributes of the service data; an authorization strategy based on operation history records, which mainly realizes the isolation of relevant data of the user;

self-related data, the framework is defined as follows: data that has participated in the process (i.e., any operation has been done in the process, including the task to be done having been viewed); data which is added, deleted and changed to the service data group; the strategy is mainly to realize that the relevant data can be checked, no matter whether the data is authorized by data rights in other authorization strategies; the strategy is the default data authority of the user, and no additional configuration is needed; the row isolation rule is in a union relation with the row isolation rules of other data authorities, and the column data authority isolation rule is in an intersection relation; the specific method comprises the following steps: for all the service data needing to realize the data authority, a table is required to be added to record a process participation log and a service data operation log; unifying table naming rules of the appointed recording logs; operation log table naming rules: service data table name + "_ OPLOGS"; the process participates in the naming rule of the log table: service data table name + "_ WFLOGS"; recording log information according to rules; the processing implementation mechanism is as follows: intercepting SQL sentences of all UPDATE, INSERT and DELETE operations in an SQL access controller, acquiring a target table name after analysis, searching whether a log table exists or not through a naming rule, and automatically filtering operator information if the log table exists; the data isolator automatically generates WHERE query conditions and combines the WHERE query conditions into the original query conditions. The processing logic is as follows: in the data access controller, for the main table of the SELECT operation, it is determined whether a log table EXISTS, if so, an EXISTS query condition is automatically added, and the condition and other constraint isolation conditions are in an OR relationship, that is: own correlation isolation rule OR (other isolation condition 1 AND other isolation condition 2);

for authorization of data isolation, the framework provides two authorization methods:

a data authority authorization model based on the business data object; the model takes a data object as an authorized resource, and essentially takes a database table, a view and a table column as resources for authority management; this model provides authorization of the following data rights; authorization management of the data table provides addition, deletion, check and modification rights; the authorization management of the data row is realized by configuring a query condition; data column: having read permission, controlling whether the data item can be viewed; view: only the rights of the query.

Data isolation

Data isolation is the authorization of data accessible to a user, i.e. the control of which data a user can view (visible data range), and which attributes of the data (visible data content).

The framework supports the following data authorization policies:

organization based authorization policy

It sets up the authorization policy mainly according to the organizational structure, its applicable scene:

view order data of this unit

Viewing event data of local department and subordinate department

Viewing equipment account information for a given department

People who can only look at a certain unit

Persons who can only select this unit

These scenarios are all related to the organization to which the data belongs.

The implementation mechanism is as follows:

the following fields are added uniformly in all database tables: creator ID, modifier ID, creator department ID, creator unit ID, creator organization ID, and recording the above information during data storage

In SQL processor, the conditional rule expression is analyzed, and the query expression is created according to department ID, unit ID and organization ID and added to the query condition automatically

Authorization policy based on business data attribute

The mechanism is to set an authorization policy according to some attributes of the service data, such as:

equipment account for checking secret level not higher than current user secret level

Equipment account for checking secret level as secret level

Check equipment account stored in area A

Device for viewing storage classes

These scenarios are only related to the service attributes of the service data

Authorization policy based on operation history, which mainly implements isolation of own related data

The framework is defined as follows, so-called self-related data:

data participated in the process (i.e. any operation was done in the process, including the task to be done was viewed)

Data for adding, deleting and modifying service data group

The policy is primarily one in which the implementation can view its own relevant data, whether or not the data is granted data rights within other authorization policies.

The strategy is the data authority which the user has by default, and additional configuration is not needed. It is in union relationship with the row isolation rules of other data permissions and in intersection relationship with the column data permission isolation rules.

The implementation mechanism of the strategy is as follows:

for all the service data needing to realize the data authority, a table is added to record a process participation log and a service data operation log

Table naming rules for unifying appointment logging

Operation log table naming rules: [ business data table name ] + "_ OPLOGS"

The process participates in the naming rule of the log table: [ business data table name ] + "_ WFLOGS"

Recording log information according to rules

The processing implementation mechanism is as follows: intercepting SQL sentences for operating all UPDATE, INSERT and DELETE in an SQL access controller, obtaining a target table name after analysis, searching whether a log table exists or not through a naming rule, and automatically filtering operator information if the log table exists.

The data isolator automatically generates WHERE query conditions and combines the WHERE query conditions into the original query conditions. The processing logic is as follows: in the data access controller, for the main table of the SELECT operation, it is determined whether a log table EXISTS, if so, an EXISTS query condition is automatically added, and the condition and other constraint isolation conditions are in an OR relationship, that is: self-correlation isolation rule OR (other isolation conditions 1 AND other isolation conditions 2)

For authorization of data isolation, the framework provides two authorization mechanisms:

data authority authorization model based on business data object

The model takes a data object as an authorized resource, and the essence of the model is that a database table, a view and a table column are taken as resources to carry out authority management.

This model provides authorization of data rights as follows

The authorization management of the data table provides the authority of addition, deletion, check and modification,

authorization management of data rows is realized by configuring query conditions

Data column: having read permission, controlling whether data items can be viewed

View: permission only for queries

Wherein the model represents: the user has the authority of adding and deleting the order master table, can view the data meeting the query condition 1, can view the data of three fields of the column 1, the column 2 and the column 3 of the order master table, and can view the data of the order detail meeting the query condition 2

A WHERE clause with a query condition supporting standard SQL grammar; the method supports the use of AND AND OR combination query conditions; support using built-in variable and built-in regular expression and function in query condition

Function-based data authority authorization model

We look at the following scenario: a user belongs to department A, but is responsible for the operation and maintenance work of equipment of two departments, namely department A and department B, so that the user obtains the data authority of the equipment data of the two departments through an authorization mechanism based on business data; but it is responsible for the maintenance of the account of the equipment in the department, and in the scene of the maintenance of the account information in the department, it should only maintain the equipment in the department and cannot check the equipment data in the department B.

Considering another scenario, from the authorization mechanism of the service data, a user does not have the data authority of the operation and maintenance engineer, but in some system functions, the user needs to be able to select the operation and maintenance engineer.

Through the above scenarios, we find that the data authority model based on the business data cannot provide an effective isolation policy for some data isolation scenarios, because the data authorization policies are closely related to the business usage scenarios.

Therefore, it is necessary to design a data authority authorization mechanism so that it can set an authorization policy according to a specific service scenario to supplement the deficiency of the service data-based authorization policy.

In addition, the two data authority authorization scenarios do not exist in isolation with each other, and there is an association relationship between them:

conflict exists between data authorization strategy based on business scene and authorization strategy based on business data

The data authorization strategy based on the service scene is a supplement to the authorization strategy based on the service data

Therefore, the framework needs to consider how to handle the relationship between the two authorization policies when designing the two authorization policies.

The realization idea is as follows:

since the data authorization policy is related to a specific business operation scene, from the system perspective, the data authorization policy is inherently closely related to the authorization of the URL resource. When authorizing these URLs, we consider the true full meaning expressed by their authorization to be: authorization allows a user to perform certain operations on certain data.

In order to realize a data authority control mechanism based on a specific service scene, the framework performs authority extension on the URL, and the implementation mode is as follows: associating DACO (data access control object) on URL, and realizing authorization of data authority through DACO mechanism; its authority as a URL is granted to the user through the functional role hierarchy along with the functional authority.

The meaning of the model expression is: the role has access rights to resources and data rights to operational data.

Merging strategy design:

the merging strategy is divided into four categories: replacement, addition, overlay, customization;

and (3) replacing: quarantine rules with data authorization disabled, full use of quarantine rules defined by DACO

Additionally: on the basis of data authority based on service data, data authority control is added

Namely: data authority based on service data AND DACO data authority

Covering: substitution of rights in DACO when there is a conflict between the data rights of the two mechanisms

Data authority of service data

Self-defining: the data access controller does not do any processing, and the data authority is completely handed over by the service code

To control

Technical implementation of data rights:

interception of all database access requests is realized by injecting SQL interceptor in data source

Syntax parsing of intercepted SQL

Obtaining data authority according to accessed target list/view, current user information and service operation URL

Removing inaccessible columns in SQL statements according to data permissions

Generating WHERE query condition clause according to data authority, and merging the clause to the original sentence according to merging rules

In query conditions of SQL statement

Generate new SQL statements and submit executions

The data isolator mainly has the following core functions:

SQL interceptor for intercepting SQL access to all databases

The SQL processor: is responsible for analyzing SQL sentences and processing SQL according to data authority rules

Data access log: the system is responsible for recording data access information (SQL statements, conditions, execution time, executors and the like) and recording data access which is not in compliance.

Drawings

FIG. 1 is a diagram of a rights model.

Fig. 2 is a diagram of an authorization model.

Fig. 3 is a schematic diagram of a logic structure.

Detailed Description

This patent is further described below in conjunction with specific embodiments.

A data isolation implementation method based on SQL statement interception and analysis technology is characterized in that:

the merging strategy is divided into four categories: replacement, addition, overlay, customization;

and (3) replacing: forbidding the isolation rule of data authorization, and completely using the isolation rule defined by DACO;

additionally: on the basis of the data authority based on the service data, data authority control is added; namely: data authority based on service data AND data authority;

covering: when the data authorities of the two mechanisms conflict, the authority in the DACO is used for replacing the data authority based on the service data;

self-defining: the data access controller does not perform any processing, and the data authority is completely handed to the service code to be automatically controlled;

the data authority technology is realized as follows:

7. the method comprises the steps of injecting an SQL interceptor into a data source to intercept access requests of all databases;

8. analyzing the syntax of the intercepted SQL;

9. acquiring data authority according to the accessed target table/view, the current user information and the service operation URL;

10. removing inaccessible columns in the SQL statement according to the data authority;

11. generating WHERE query condition clause according to data authority, and merging the clause to the original sentence according to merging rules

In the query condition of SQL statement;

12. generating a new SQL statement and submitting for execution;

the data isolator mainly comprises the following core steps:

4. SQL interceptor for intercepting SQL access to all databases

5. The SQL processor: is responsible for analyzing SQL sentences and processing SQL according to data authority rules

6. Data access log: the system is responsible for recording data access information (SQL statements, conditions, execution time, executors and the like) and recording data access which is not in compliance.

Data isolation, which is to authorize data accessible by a user, i.e. to control which data (visible data range) a user can view and which attributes of data (visible data content), is specifically performed by: an organization-based authorization policy; it sets up the authorization policy mainly according to the organizational structure, its applicable scene: checking order data of the unit; checking the event data of the department and the subordinate department; checking equipment account information of a designated department; only the person of a certain unit can be checked; only the person of the unit can be selected; these scenarios are all related to the organization to which the data belongs;

the data isolation method comprises the following steps: the following fields are added uniformly in all database tables: the method comprises the steps of creating a person ID, modifying a person ID, a department ID to which the creating person belongs, a unit ID to which the creating person belongs, and an organization ID to which the creating person belongs, and recording the information when data are stored; in the SQL processor, analyzing a conditional rule expression, creating a query expression according to a department ID, a unit ID and an organization ID, and automatically adding the query expression into a query condition; an authorization policy based on the business data attribute; the mechanism is to set an authorization policy according to some attributes of the service data, such as: checking the equipment account with the security level not higher than that of the current user; checking the equipment account with secret level as secret level; checking the equipment account stored in the area A; a device viewing the storage class; these scenarios are only related to the service attributes of the service data; an authorization strategy based on operation history records, which mainly realizes the isolation of relevant data of the user;

self-related data, the framework is defined as follows: data that has participated in the process (i.e., any operation has been done in the process, including the task to be done having been viewed); data which is added, deleted and changed to the service data group; the strategy is mainly to realize that the relevant data can be checked, no matter whether the data is authorized by data rights in other authorization strategies; the strategy is the default data authority of the user, and no additional configuration is needed; the row isolation rule is in a union relation with the row isolation rules of other data authorities, and the column data authority isolation rule is in an intersection relation; the specific method comprises the following steps: for all the service data needing to realize the data authority, a table is required to be added to record a process participation log and a service data operation log; unifying table naming rules of the appointed recording logs; operation log table naming rules: service data table name + "_ OPLOGS"; the process participates in the naming rule of the log table: service data table name + "_ WFLOGS"; recording log information according to rules; the processing implementation mechanism is as follows: intercepting SQL sentences of all UPDATE, INSERT and DELETE operations in an SQL access controller, acquiring a target table name after analysis, searching whether a log table exists or not through a naming rule, and automatically filtering operator information if the log table exists; the data isolator automatically generates WHERE query conditions and combines the WHERE query conditions into the original query conditions. The processing logic is as follows: in the data access controller, for the main table of the SELECT operation, it is determined whether a log table EXISTS, if so, an EXISTS query condition is automatically added, and the condition and other constraint isolation conditions are in an OR relationship, that is: own correlation isolation rule OR (other isolation condition 1 AND other isolation condition 2);

for authorization of data isolation, the framework provides two authorization methods:

a data authority authorization model based on the business data object; the model takes a data object as an authorized resource, and essentially takes a database table, a view and a table column as resources for authority management; this model provides authorization of the following data rights; authorization management of the data table provides addition, deletion, check and modification rights; the authorization management of the data row is realized by configuring a query condition; data column: having read permission, controlling whether the data item can be viewed; view: only the rights of the query.

Data isolation

Data isolation is the authorization of data accessible to a user, i.e. the control of which data a user can view (visible data range), and which attributes of the data (visible data content).

The framework supports the following data authorization policies:

organization based authorization policy

It sets up the authorization policy mainly according to the organizational structure, its applicable scene:

view order data of this unit

Viewing event data of local department and subordinate department

Viewing equipment account information for a given department

People who can only look at a certain unit

Persons who can only select this unit

These scenarios are all related to the organization to which the data belongs.

The implementation mechanism is as follows:

the following fields are added uniformly in all database tables: creator ID, modifier ID, creator department ID, creator unit ID, creator organization ID, and recording the above information during data storage

In SQL processor, the conditional rule expression is analyzed, and the query expression is created according to department ID, unit ID and organization ID and added to the query condition automatically

Authorization policy based on business data attribute

The mechanism is to set an authorization policy according to some attributes of the service data, such as:

equipment account for checking secret level not higher than current user secret level

Equipment account for checking secret level as secret level

Check equipment account stored in area A

Device for viewing storage classes

These scenarios are only related to the service attributes of the service data

Authorization policy based on operation history, which mainly implements isolation of own related data

The framework is defined as follows, so-called self-related data:

data participated in the process (i.e. any operation was done in the process, including the task to be done was viewed)

Data for adding, deleting and modifying service data group

The policy is primarily one in which the implementation can view its own relevant data, whether or not the data is granted data rights within other authorization policies.

The strategy is the data authority which the user has by default, and additional configuration is not needed. It is in union relationship with the row isolation rules of other data permissions and in intersection relationship with the column data permission isolation rules.

The implementation mechanism of the strategy is as follows:

for all the service data needing to realize the data authority, a table is added to record a process participation log and a service data operation log

Table naming rules for unifying appointment logging

Operation log table naming rules: [ business data table name ] + "_ OPLOGS"

The process participates in the naming rule of the log table: [ business data table name ] + "_ WFLOGS"

Recording log information according to rules

The processing implementation mechanism is as follows: intercepting SQL sentences for operating all UPDATE, INSERT and DELETE in an SQL access controller, obtaining a target table name after analysis, searching whether a log table exists or not through a naming rule, and automatically filtering operator information if the log table exists.

The data isolator automatically generates WHERE query conditions and combines the WHERE query conditions into the original query conditions. The processing logic is as follows: in the data access controller, for the main table of the SELECT operation, it is determined whether a log table EXISTS, if so, an EXISTS query condition is automatically added, and the condition and other constraint isolation conditions are in an OR relationship, that is: self-correlation isolation rule OR (other isolation conditions 1 AND other isolation conditions 2)

For authorization of data isolation, the framework provides two authorization mechanisms:

data authority authorization model based on business data object

The model takes a data object as an authorized resource, and the essence of the model is that a database table, a view and a table column are taken as resources to carry out authority management.

This model provides authorization of data rights as follows

The authorization management of the data table provides the authority of addition, deletion, check and modification,

authorization management of data rows is realized by configuring query conditions

Data column: having read permission, controlling whether data items can be viewed

View: permission only for queries

Wherein the model represents: the user has the authority of adding and deleting the order master table, can view the data meeting the query condition 1, can view the data of three fields of the column 1, the column 2 and the column 3 of the order master table, and can view the data of the order detail meeting the query condition 2

A WHERE clause with a query condition supporting standard SQL grammar; the method supports the use of AND AND OR combination query conditions; support using built-in variable and built-in regular expression and function in query condition

Function-based data authority authorization model

We look at the following scenario: a user belongs to department A, but is responsible for the operation and maintenance work of equipment of two departments, namely department A and department B, so that the user obtains the data authority of the equipment data of the two departments through an authorization mechanism based on business data; but it is responsible for the maintenance of the account of the equipment in the department, and in the scene of the maintenance of the account information in the department, it should only maintain the equipment in the department and cannot check the equipment data in the department B.

Considering another scenario, from the authorization mechanism of the service data, a user does not have the data authority of the operation and maintenance engineer, but in some system functions, the user needs to be able to select the operation and maintenance engineer.

Through the above scenarios, we find that the data authority model based on the business data cannot provide an effective isolation policy for some data isolation scenarios, because the data authorization policies are closely related to the business usage scenarios.

Therefore, it is necessary to design a data authority authorization mechanism so that it can set an authorization policy according to a specific service scenario to supplement the deficiency of the service data-based authorization policy.

In addition, the two data authority authorization scenarios do not exist in isolation with each other, and there is an association relationship between them:

conflict exists between data authorization strategy based on business scene and authorization strategy based on business data

The data authorization strategy based on the service scene is a supplement to the authorization strategy based on the service data

Therefore, the framework needs to consider how to handle the relationship between the two authorization policies when designing the two authorization policies.

The realization idea is as follows:

since the data authorization policy is related to a specific business operation scene, from the system perspective, the data authorization policy is inherently closely related to the authorization of the URL resource. When authorizing these URLs, we consider the true full meaning expressed by their authorization to be: authorization allows a user to perform certain operations on certain data.

In order to realize a data authority control mechanism based on a specific service scene, the framework performs authority extension on the URL, and the implementation mode is as follows: associating DACO (data access control object) on URL, and realizing authorization of data authority through DACO mechanism; its authority as a URL is granted to the user through the functional role hierarchy along with the functional authority.

The meaning of the model expression is: the role has access rights to resources and data rights to operational data.

Merging strategy design:

the merging strategy is divided into four categories: replacement, addition, overlay, customization;

and (3) replacing: quarantine rules with data authorization disabled, full use of quarantine rules defined by DACO

Additionally: on the basis of data authority based on service data, data authority control is added

Namely: data authority based on service data AND DACO data authority

Covering: substitution of rights in DACO when there is a conflict between the data rights of the two mechanisms

Data authority of service data

Self-defining: the data access controller does not do any processing, and the data authority is completely handed over by the service code

To control

Technical implementation of data rights:

interception of all database access requests is realized by injecting SQL interceptor in data source

Syntax parsing of intercepted SQL

Obtaining data authority according to accessed target list/view, current user information and service operation URL

Removing inaccessible columns in SQL statements according to data permissions

Generating WHERE query condition clause according to data authority, and merging the clause to the original sentence according to merging rules

In query conditions of SQL statement

Generate new SQL statements and submit executions

The data isolator mainly has the following core functions:

SQL interceptor for intercepting SQL access to all databases

The SQL processor: is responsible for analyzing SQL sentences and processing SQL according to data authority rules

Data access log: the system is responsible for recording data access information (SQL statements, conditions, execution time, executors and the like) and recording data access which is not in compliance.

Claims (1)

1. A data isolation implementation method based on SQL statement interception and analysis technology is characterized in that: the merging strategy is divided into four categories: replacement, addition, overlay, customization;

and (3) replacing: forbidding the isolation rule of data authorization, and completely using the isolation rule defined by DACO;

additionally: on the basis of the data authority based on the service data, data authority control is added; namely: data authority based on service data AND data authority;

covering: when the data authorities of the two mechanisms conflict, the authority in the DACO is used for replacing the data authority based on the service data;

self-defining: the data access controller does not perform any processing, and the data authority is completely handed to the service code to be automatically controlled;

the technical implementation steps of the data authority are as follows:

1, intercepting all database access requests by injecting an SQL interceptor into a data source;

2, carrying out syntax analysis on the intercepted SQL;

3, acquiring data authority according to the accessed target table/view, the current user information and the service operation URL;

4-according to the data authority, removing the inaccessible columns in the SQL statement;

5-generating WHERE query condition clause according to data authority, and merging the clause to the original according to merging rules

In the query condition of SQL statement;

6, generating a new SQL statement and submitting for execution;

the data isolator mainly comprises the following core steps:

1-SQL interceptor for intercepting SQL accessed by all databases

2-SQL processor: is responsible for analyzing SQL sentences and processing SQL according to data authority rules

3-data access log: the system is responsible for recording data access information (SQL statements, conditions, execution time, executors and the like) and recording data access which is not in compliance;

data isolation, which is to authorize data accessible by a user, i.e. to control which data (visible data range) a user can view and which attributes of data (visible data content), is specifically performed by: an organization-based authorization policy; it sets up the authorization policy mainly according to the organizational structure, its applicable scene: checking order data of the unit; checking the event data of the department and the subordinate department; checking equipment account information of a designated department; only the person of a certain unit can be checked; only the person of the unit can be selected; these scenarios are all related to the organization to which the data belongs;

the data isolation method comprises the following steps: the following fields are added uniformly in all database tables: the method comprises the steps of creating a person ID, modifying a person ID, a department ID to which the creating person belongs, a unit ID to which the creating person belongs, and an organization ID to which the creating person belongs, and recording the information when data are stored; in the SQL processor, analyzing a conditional rule expression, creating a query expression according to a department ID, a unit ID and an organization ID, and automatically adding the query expression into a query condition; an authorization policy based on the business data attribute; the mechanism is to set an authorization policy according to some attributes of the service data, such as: checking the equipment account with the security level not higher than that of the current user; checking the equipment account with secret level as secret level; checking the equipment account stored in the area A; a device viewing the storage class; these scenarios are only related to the service attributes of the service data; an authorization strategy based on operation history records, which mainly realizes the isolation of relevant data of the user;

self-related data, the framework is defined as follows: data that has participated in the process (i.e., any operation has been done in the process, including the task to be done having been viewed); data which is added, deleted and changed to the service data group; the strategy is mainly to realize that the relevant data can be checked, no matter whether the data is authorized by data rights in other authorization strategies; the strategy is the default data authority of the user, and no additional configuration is needed; the row isolation rule is in a union relation with the row isolation rules of other data authorities, and the column data authority isolation rule is in an intersection relation; the specific method comprises the following steps: for all the service data needing to realize the data authority, a table is required to be added to record a process participation log and a service data operation log; unifying table naming rules of the appointed recording logs; operation log table naming rules: service data table name + "_ OPLOGS"; the process participates in the naming rule of the log table: service data table name + "_ WFLOGS"; recording log information according to rules; the processing implementation mechanism is as follows: intercepting SQL sentences of all UPDATE, INSERT and DELETE operations in an SQL access controller, acquiring a target table name after analysis, searching whether a log table exists or not through a naming rule, and automatically filtering operator information if the log table exists; the data isolator automatically generates a WHERE query condition and combines the WHERE query condition with the original query condition; the processing logic is as follows: in the data access controller, for the main table of the SELECT operation, it is determined whether a log table EXISTS, if so, an EXISTS query condition is automatically added, and the condition and other constraint isolation conditions are in an OR relationship, that is: own correlation isolation rule OR (other isolation condition 1 AND other isolation condition 2);

for authorization of data isolation, the framework provides two authorization methods:

a data authority authorization model based on the business data object; the model takes a data object as an authorized resource, and essentially takes a database table, a view and a table column as resources for authority management; this model provides authorization of the following data rights; authorization management of the data table provides addition, deletion, check and modification rights; the authorization management of the data row is realized by configuring a query condition; data column: having read permission, controlling whether the data item can be viewed; view: only the rights of the query.

Images