Overview
Column-level permission control is implemented based on masking policies: you can create a masking policy in the Data Security menu, define different masking methods by user group (for example, administrators see plaintext, customer service sees the middle 4 digits masked, and developers see the last 4 digits), and associate the policy with sensitive fields on the Catalog table details page. When any user reads the field through query paths such as SQL, Notebook, or dashboards, the corresponding masked result is returned based on the user group to which the user belongs.
Tip
The column-level permission control described in this section is essentially field-level data protection based on masking policies. It controls what different users see when querying the same field, rather than access control over whether a user can query a column. To limit users' query permissions on tables and fields themselves, see the Asset ACL section in Members and Permission Management. Prerequisites
Before you start this operation, make sure the following prerequisites are met:
You have activated the DataBuddy service and completed workspace initialization.
Create a masking policy: The current account can log in to the workspace.
To bind a masking policy to a field: the current account must have the Owner or Manage permission on the Table in the Catalog where the target table resides (for permission semantics, see Members and Permission Management). The user group information has been created in the workspace.
Use Limits
Limit | Description |
Applicable Scope | A masking policy is shared across all catalogs within the current tenant + current region. |
Field Binding Relationship | A field can be bound to only one masking policy at a time. |
User Group Coverage | Masking methods take effect by user group. User groups not configured in the policy return plaintext when this field is queried. |
Masking Method Scope | Currently, system built-in masking methods are provided, and custom methods are not supported yet. |
Operation Steps
DMask consists of two steps: first create a masking policy in the Data Security menu, and then associate the policy with fields on the target table details page.
Step 1: Go to the Data Security Management Page
2. Switch to the target region and Workspace at the top.
3. Choose Data Governance > Data Security in the left sidebar.
4. By default, you are directed to the Masking Policies list page, where you can filter existing policies by policy name in the search box.
Step 2: Create a Desensitization Policy
1. In the upper-right corner of the masking policy list page, click + Create Policy.
2. Fill in the Basic Information in the creation drawer that appears:
Policy Name: Required.
Description: Optional. It is recommended to describe the business purpose of the policy.
Associated Sensitive Tag: Optional. After association, when AI identifies a field with this tag, it automatically matches this masking policy. If not associated, manual binding is maintained.
1. In the Masking Method section, configure different masking methods for different user groups:
User Group: Select the user group to which this rule applies from the drop-down list. Multiple selections are supported.
Masking Method: Select a built-in masking method from the drop-down list.
You can continue adding combinations of user groups and masking methods by clicking the + Add button at the bottom of the list.
1. After filling in all the information, click OK to save the policy and return to the policy list.
Note:
For user groups not configured in the masking policy, plaintext is still returned when this field is queried. Explicitly cover all user groups that need to be controlled in the policy.
Step 3: Bind a Policy to a Field on the Table Details Page
1. Select Data Catalog in the left sidebar.
2. Go to the details page of the target Catalog → Schema → target table, and switch to the Overview Tab.
3. Select the fields that need to be masked in the field list to enter field editing mode.
4. In the Masking Policy field, select a created masking policy from the drop-down list.
If no suitable policy is available in the list, click + Create Policy in the drop-down list to open a creation drawer on the current page and create a policy. After the policy is created, you are automatically returned to the selection.
1. Save the field configuration.
Step 4: View and Maintain Bound Desensitization Policies in Table Details
1. In the field list on the table details page, the name of the currently bound masking policy is displayed for each field.
2. Click a policy name to go to the policy details page, where you can view the policy name, description, and masking method for each user group.
Step 5: Manage Desensitization Policies
Return to the Data Security > Masking Policies list page:
Operation | Description |
View. | View user group and masking method details in the policy details. |
Editing an alarm policy | Modify the policy name, description, associated sensitive tags, and user group and masking method combinations. After modification, queries take effect immediately based on the new policy. |
Deleting an alarm policy | Delete the policy. After deletion, fields associated with the policy lose masking protection, and all users get plaintext when querying them. |
Parameter Description
Creating a Desensitization Policy
Parameter | Description | Required | Default Value |
Policy Name | Unique name of the masking policy, used for identification in the policy list and field binding dropdown. | Yes | - |
Description | Text description of the policy, up to 512 characters. | No | - |
Associate Sensitive Tag | After a sensitive tag is selected, fields identified by AI as having the tag are automatically matched to this masking policy. If no tag is associated, manual binding mode is retained. | No | Not associated (manual association) |
User group | Select the user groups for which the current masking method takes effect. Multiple selections are supported. | Yes | - |
Masking Method | Select a built-in masking method. Multiple rules can be combined for different user groups within the same policy. | Yes | - |
Binding a Desensitization Policy to a Field
Parameter | Description | Required | Default Value |
Masking policy | Select a created masking policy in the field editing panel on the table details page. | No | Not Bound (Returns Plaintext) |
Verification Result
After the operation is completed, you can confirm in the following ways:
1. In the Data Security > Masking Policies list, you can see the newly created policy with the associated user group, creator, and creation time displayed correctly.
2. On the Catalog table details page, the corresponding masking policy name is displayed for the target field.
3. Use accounts that belong to different user groups to execute the SELECT statement in Studio to query this field. The results are returned based on the masking method corresponding to each user group, while user groups outside the policy coverage return plaintext.
FAQs
Q: What happens to fields bound to a desensitization policy after the policy is deleted?
A: After a policy is deleted, fields associated with the policy lose masking protection, and all users see plaintext when querying these fields. Before deleting a policy, unbind it on the table details page and confirm that no business is affected.
Q: What is returned when a user group not configured in the policy queries a field?
A: Returns the actual plaintext value of the field. A masking policy takes effect only for user groups explicitly listed in the policy. To protect other user groups, add the corresponding user groups and masking methods to the policy.
Q: How do I configure a field so that different user groups see different results?
A: In the same masking policy, add a record of "user group, masking method" for each user group. You do not need to create multiple policies for the same field, and each field can be bound to only one policy.
Q: What should I do if a sub-account does not have permission to grant permissions to others?
As shown in the figure, after a sub-account is granted the grant permission, a no-permission message appears when it attempts to grant permissions to other users:
At this point, the administrator can go to the metadata view, click Data Catalog in the navigation bar, click the settings button on the right side of Catalog, select the metadata lake, click the + Grant button in the upper-right corner of the page, and grant Admin to the sub-account:
Then have the sub-account try the operation again.
References