The Security Settings and Others tab in DataStudio lets you control data security and development governance for a workspace. This topic explains how to configure the five settings on this tab: data masking, code and log isolation, commit/deploy impact prompts, forcible code review, and forcible smoke testing.
Prerequisites
Before you begin, make sure you have:
-
Access to the DataWorks console
Go to the Security Settings and Others tab
-
Log on to the DataWorks console. In the left-side navigation pane, choose Data Modeling and Development > DataStudio. Select the desired workspace from the drop-down list and click Go to DataStudio.
-
At the bottom of the left-side navigation pane of the DataStudio page, click the
icon to go to the Settings page. -
On the Settings page, click the Security Settings and Others tab.
Enable data masking
Scope: This setting applies only to the current workspace.
DataWorks includes built-in data masking rules. When data masking is enabled, query results that match a built-in rule are automatically masked before they are displayed — underlying data is not affected (dynamic data masking). If the built-in rules do not cover your requirements, create a custom data masking rule in Data Security Guard and apply it to query results.
If data masking is disabled, sensitive information in query results may be exposed. Because this setting is workspace-scoped, enabling it for one workspace does not protect query results in other workspaces. For example, if masking is enabled for Workspace A but not Workspace B, a member of Workspace B who has permission to query tables in Workspace A will see plaintext data when querying from Workspace B.
To enable data masking, turn on Mask Data in Page Query Results in the Data Security section. The setting takes effect immediately.
Built-in data masking rules
| Data type | Masking rule | Before masking | After masking |
|---|---|---|---|
| ID card number | Only the first and last digits of a 15-digit or 18-digit ID card number are shown. All other digits are replaced with asterisks (*). |
111222190002309999 |
1*************9 |
| Mobile phone number | Only the first seven digits of a Chinese mainland mobile phone number are shown. The last four digits are replaced with asterisks (*). |
13900001234 |
1390000**** |
| Email address | If the local part (before @) has three or more characters, the first three are shown and the rest are replaced with *. If the local part has fewer than three characters, all characters are shown followed by three *. |
username@example.com / a@example.net |
use***@example.com / a***@example.net |
| Bank card number | Only the last four digits of a credit or deposit card number are shown. All other digits are replaced with asterisks (*). |
6888 8888 8888 8888 / 4666 6666 6666 6666 |
**** **** **** 8888 / **** **** **** 6666 |
| IP or MAC address | Only the first section of an IP address or a media access control (MAC) address is shown. All other sections are replaced with asterisks (*). |
192.168.0.1 / 01-80-C2-00-00-00 |
192.***.*.* / 01-**-**-**-**-** |
| License plate number | Only the region information and the last three characters of the license plate number are shown. All other characters are replaced with asterisks (*). |
(provincial abbrev) A 666666 / (provincial abbrev) A 888888 |
(provincial abbrev) A***666 / (provincial abbrev) A***888 |
Enable code and log isolation
After code and log isolation is enabled, users who are not members of the workspace cannot view the code or run logs of any node in the workspace. To grant a user access, the workspace administrator must add that user's account to the workspace as a member. For more information, see Manage permissions on workspace-level services.
Enable the commit/deploy impact prompt
After this prompt is enabled, DataStudio displays the baseline a node belongs to whenever you commit or deploy that node. This helps you assess whether the change will affect other nodes associated with the same baseline before you proceed.
Enable forcible code review
Forcible code review ensures that node code committed by developers cannot be deployed until it passes a code review. This protects production stability by requiring human sign-off before changes take effect, and lets you control review scope by baseline priority so that high-priority nodes receive closer scrutiny.
To enable forcible code review, configure the following parameters in the Code Review section of the Security Settings and Others tab.
| Parameter | Description |
|---|---|
| Code reviewers | Specifies who reviews node code after a commit. Any Developer Role: all users assigned the Development role in the workspace are eligible; the developer selects a specific reviewer at commit time. Specify development role users: a specific user is pre-set as the default code reviewer for the workspace. |
| Baseline scopes for code review | Determines which nodes require code review when committed. Select Non-baseline tasks to apply code review to newly created nodes. Select one or more baseline task levels to apply code review to nodes belonging to baselines at those priority levels. A higher baseline task level value indicates a higher priority, and baseline nodes have higher priority than non-baseline nodes. For more information about baselines, see Overview. |
For more information about the code review workflow, see Code review.
Enable forcible smoke testing
Forcible smoke testing requires nodes to pass smoke testing before they can be deployed. This catches configuration errors and logic problems early, reducing the risk of broken nodes reaching production.
To enable forcible smoke testing, turn on the switch in the Smoke Testing section of the Security Settings and Others tab.
After this feature is enabled:
-
If smoke testing has not been run on a node, or if it has run but failed, Check Failed is shown in the Status column on the Create Deploy Task page, and the node cannot be deployed.
-
To deploy a node that failed smoke testing in a special scenario, go to the Create Deploy Task page and, as the workspace administrator, manually set the smoke testing status to successful. The node can then be deployed.
For more information about deploying nodes, see Deploy nodes.