openGauss data dynamic desensitization
Published: 2023-03-08 03:27:49

1.Analysis of the result set of common desensitization routes: Without rewriting the statement sent to the database, you need to know the data table structure in advance. After the database returns the result, judge which data in the collection needs to be desensitized according to the table structure, and rewrite the result data one by one.
Statement rewriting: Rewrite the statement containing the sensitive field query, and rewrite the sensitive field (table column) involved in the query by means of an outer nested function, so that the database returns a result set that does not contain sensitive data when running the query statement.
openGauss uses sentence rewriting to achieve data desensitization, which is an excellent desensitization solution in terms of performance and accuracy. Based on the idea of ​​sentence rewriting, after the query tree is obtained by query parsing, the target node (Node) of the query tree is identified according to the desensitization strategy defined by the user, and the desensitized node is rewritten to construct a "desensitized query tree", which is then handed over to the The database kernel executes and finally returns the desensitized data, and the performance loss of desensitized 100,000 sensitive data is less than 5%.
openGauss has defined a complete set of built-in security policy models from version 1.1.0. Based on this model, users can define resource tags to identify sensitive data, and define related security policy mechanisms for different resource tag categories and contents.

2. Built-in security policy
The dynamic data desensitization in openGauss is deployed together with the database in the form of a built-in security plugin, and the built-in security policy can be used without additional adaptation in business.
The parsing of SQL and the matching of the masking policy are handled by the openGauss security policy module, and the business can take effect after the masking policy is configured.
The Security Policy model refers to identifying and protecting user behavior by configuring a series of security policies, and provides the ability to protect sensitive data of users.
Resource Label is the basis of Security Policy, and its essence is a collection of database resources. By classifying database resources, these resources are put into various security policies for management.
The dynamic data desensitization feature is to use resource tags to identify sensitive data, and then match the desensitization strategy to realize the shielding of sensitive data.
Masking strategy content:
masking function (Masking Function), which refers to the method used by the masking strategy to mask the target field. At present, openGauss presets 7 masking methods: creditcardmasking, basicmailmasking, fullemailmasking, alldigitsmasking, shufflemasking , randommasking, and maskall are suitable for different desensitization scenarios.
The desensitization object (Resource Label) refers to the object set (LABEL) that is used when the desensitization policy takes effect. If the query target field exists in LABEL, the field will be desensitized according to the desensitization policy. OpenGauss dynamic data The desensitization feature supports desensitization of LABELs that only contain data columns.
Filter, which indicates the user scenario under which the desensitization policy takes effect, mainly involving USER (user name), APP (user login client name), and IP (the ip where the user is located). The data masking policy will take effect only when the querying user meets the threshold specified by Masking Filter.

3. Trigger desensitization strategy
When the system receives a query command, the security_plugin will intercept the query tree (Query) generated by semantic analysis in the parser, and first filter out the user scenarios that satisfy the user based on the user login information (username, client, IP) desensitization strategy. Since the desensitization policy is configured based on the resource label (only including the list), it is necessary to determine whether the target node of the query tree belongs to a certain resource label, and then match the identified resource label with the desensitization policy, according to the content of the policy Rewrite the target node of the query tree, and finally return the query tree to the parser.
Due to the built-in query tree desensitization method of the security_plugin module, data visitors will not perceive the process of rewriting the query tree by the built-in security policy, and access the data just like executing ordinary queries, while protecting data privacy.