All Products
Search
Document Center

:Configure settings on the Security Settings and Others tab

Last Updated:Oct 11, 2023

DataWorks supports various settings for data development. On the Security Settings and Others tab in DataStudio, you can enable the data masking feature to mask sensitive information in query results, enable code and log isolation, enable the forcible code review feature and specify one or more code reviewers to control the code quality of your nodes, and enable the forcible smoke testing feature to ensure that your nodes can run as expected. This topic describes how to configure settings on the Security Settings and Others tab in DataStudio.

Limits

The data masking feature takes effect only for the current workspace. If you want to mask sensitive information in query results in all workspaces, you must separately enable the data masking feature for each workspace.

Note

For example, you enable the data masking feature for Workspace A and do not enable the feature for Workspace B. If a member in Workspace B is granted the permissions to query tables in Workspace A, data in the tables is displayed in plaintext when the member queries the tables from Workspace B.

Go to the Security Settings and Others tab

  1. Log on to the DataWorks console. In the left-side navigation pane, choose Data Modeling and Development > DataStudio. On the page that appears, select the desired workspace from the drop-down list and click Go to DataStudio.

  2. In the lower-part of the left-side navigation pane of the DataStudio page, click the 设置 icon to go to the Settings page.

  3. On the Settings page, click the Security Settings and Others tab.

    On the Security Settings and Others tab, you can perform the following operations:

Enable the data masking feature

  • Description

    DataWorks provides built-in data masking rules. After you enable the data masking feature, if the results returned for a query in DataWorks hit one of the built-in data masking rules, DataWorks masks sensitive information in the query results based on the rule. If the built-in data masking rules cannot meet your requirements for masking query results, you must create a custom data masking rule in Data Security Guard and use the rule to mask sensitive information in the query results. For more information about Data Security Guard, see Overview.

    Note

    Data masking in DataStudio is dynamic data masking, which does not affect underlying data.

  • Configuration of the feature

    To enable the data masking feature, you must turn on Mask Data in Page Query Results in the Data Security section of the Security Settings and Others tab. The data masking feature immediately takes effect after you turn on the switch.

    Note
    • If you do not enable the data masking feature, sensitive information may be leaked.

    • The data masking feature takes effect only for the current workspace.

  • Built-in data masking rules

    The following table describes the built-in data masking rules provided by DataWorks.

    Type

    Data masking rule

    Data before masking

    Data after masking

    ID card number

    Only the first and last digits of a 15-digit or 18-digit ID card number are displayed in plaintext. All other digits are displayed as asterisks (*).

    111222190002309999

    1*************9

    Mobile phone number

    Only the first seven digits in a mobile phone number in the Chinese mainland are displayed in plaintext. The last four digits are displayed as asterisks (*).

    13900001234

    1390000****

    Email address

    • If the number of characters that precede the at sign (@) is greater than or equal to three, the first three characters are displayed in plaintext, and all the other characters that precede the at sign (@) are displayed as asterisks (*).

    • If the number of characters that precede the at sign (@) is less than three, all the characters are displayed in plaintext and three asterisks (*) are added before the at sign (@).

    • username@example.com

    • a@example.net

    • use***@example.com

    • a***@example.net

    Bank card number

    Only the last four digits of a credit card number or deposit card number are displayed in plaintext. All other digits are displayed as 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 displayed in plaintext. All the other sections are displayed as 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 displayed in plaintext. All the other characters are displayed as asterisks (*).

    • (One-character provincial abbreviation) A 666666

    • (One-character provincial abbreviation) A 888888

    • (One-character provincial abbreviation) A***666

    • (One-character provincial abbreviation) A***888

Enable code and log isolation

After code and log isolation is enabled for the current workspace, you have no permissions to view the code and run logs of nodes in the workspace if you are not a member of the workspace. If you want to view the code and run logs, you must contact and ask the workspace administrator to add the account that you use to the workspace as a member. For more information, see Manage permissions on workspace-level services.

Enable the prompt feature that displays impacts of committing or deploying nodes

After you enable the prompt feature for a workspace, the system displays the baseline to which a node in the workspace belongs when you commit or deploy the node. This can help you determine whether the change operation performed on the node affects the running of other nodes that are associated with the baseline.

Enable the forcible code review feature

  • Description

    You can enable the forcible code review feature only for workspaces. After you enable the forcible code review feature for a workspace, the node code that is committed by developers in the workspace can be deployed only after the node code passes the code review. You can control the priorities of baselines on which the forcible code review feature takes effect. This helps control the code quality of nodes that are associated with baselines with high priorities. This way, these nodes can run as expected and do not block other nodes.

  • Configuration of the feature

    You can enable the forcible code review feature in the Code Review section of the Security Settings and Others tab.

    Parameter

    Description

    Code reviewers

    The code reviewers who review code after you commit a node.

    • Any Developer Role: If you select this option, all users who are assigned the Development role in the current workspace are available for code review when you commit nodes. When you commit nodes, you must select a specific user to review the node code.

    • Specify development role users: If you select this option, you must specify a specific user as the code reviewer in this step. By default, the specified user is the code reviewer for nodes in the current workspace.

    Baseline scopes for code review

    The nodes whose code must be reviewed when the nodes are committed.

    You can determine the nodes on which you want to perform code review based on the priority of the baseline to which the nodes belong.

    • If you set this parameter to Non-baseline tasks, code review is performed on newly created nodes in the current workspace.

    • If you set this parameter to baseline tasks of one or more specific levels, code review is performed on the nodes that belong to the baselines of specific priorities in the current workspace.

    • A larger value of the baseline task level indicates a higher priority. Nodes in a baseline have a higher priority than the priority of nodes that are not in a baseline.

    For more information about how to control the priorities of nodes by using a baseline, see Overview.

For more information about code review, see Code review.

Enable the forcible smoke testing feature

You can enable the forcible smoke testing feature in the Smoke Testing section of the Security Settings and Others tab. After you enable the forcible smoke testing feature for a workspace, nodes in the workspace can be deployed only after the nodes pass smoke testing.

Note

  • After you enable the forcible smoke testing feature for a workspace, if smoke testing is not performed on a node in the workspace or smoke testing is performed on the node but fails, Check Failed is displayed in the Status column of the node in the table that is displayed on the Create Deploy Task page. In this case, the node cannot be deployed.

  • If you want to deploy a node that fails smoke testing in the workspace in a special scenario, you must go to the Create Deploy Task page, and set the status of the smoke testing for the node to successful as the workspace administrator. Then, you can deploy the node.

For more information about how to deploy a node, see Deploy nodes.