All Products
Search

This Product

    DataWorks:Data masking

    Document Center

    DataWorks:Data masking

    Last Updated:Oct 09, 2026

    Data masking is a key data security measure. DataWorks supports multiple methods, including static data masking, dynamic data masking, and engine-level masking, to protect sensitive data in various scenarios. By configuring specific masking rules and masking policies, you can apply precise masking to sensitive data and ensure its security during processes such as data development and analysis.

    Introduction

    Data masking protects sensitive data during its use and transfer and prevents unauthorized exposure. It applies masking or transformation algorithms to sensitive data, identified based on data classification and grading, to ensure secure data presentation in various scenarios.

    1. Static desensitization

      • Purpose: Permanently replaces and masks sensitive data when it is written from a source to a destination. The destination stores the masked data, permanently replacing the original data.

      • Use cases: Primarily used for real-time synchronization tasks in DataWorks Data Integration. For example, you can mask real user data from a production database and then synchronize it to a development or test environment for developers to use securely.

      • Features:

        • Physical replacement: The replacement is permanent, providing a high level of security.

        • Data watermark: Supports embedding an invisible digital watermark during the masking process. If a data leak occurs, you can use the watermark to trace the source of the leak.

    2. Dynamic desensitization

      • Purpose: Masks sensitive data in real time based on preset policies when users query or access the data. The physically stored original data remains unchanged. Different users see different results when accessing the same data.

      • Use cases: Used to control data visibility for different user roles in a production environment. For example, when a customer service representative queries a user table, a phone number is displayed as "138****1234", whereas their supervisor can see the complete phone number.

      • Features:

        • On-demand masking: Does not alter the original data, offering high flexibility and balancing data security with business usability.

        • Multi-layered protection:

          • Application-level masking: The policy takes effect only when data is accessed through specific DataWorks modules.

          • Engine-level masking (MaxCompute/Hologres): The policy is enforced at the database engine layer. It takes effect regardless of the access tool and has the highest priority.

    Core configuration: For both static and dynamic data masking, you create masking rules. A rule specifies a Desensitization mode, such as hashing, masking, or replacement, for a specific Data Type, such as 'phone number'. For dynamic data masking, you also configure a Desensitization strategy to define who triggers these rules and under what conditions.

    Limitations

    • Applicable users: This feature is available to DataWorks Professional Edition or Enterprise Edition users who have enabled the new version of data security in Security Center.

    • Supported regions: China (Hangzhou), China (Shanghai), China (Beijing), China (Zhangjiakou), China (Ulanqab), China (Shenzhen), China (Chengdu), China (Hong Kong), Japan (Tokyo), Singapore, and Indonesia (Jakarta).

    • Supported compute engines: MaxCompute and Hologres.

    Prerequisites

    • The account used to log on to DataWorks must have one of the following permissions or roles:

      • An account granted the AliyunDataWorksFullAccess policy.

      • An account assigned the DataWorks tenant security administrator role.

      • An account assigned the DataWorks tenant administrator role.

    • Complete the tasks in the New user guide.

    Accessing the data masking page

    1. Log on to the DataWorks console. In the target region, click Data Governance > Security Center in the left-side navigation pane. On the page that appears, click Go to Security Center.

    2. In the left-side navigation pane, choose Sensitive Data Protection > Data desensitization.

    Page structure

    The Data Masking page provides five first-level tabs at the top, each corresponding to a different masking scenario. Under each first-level tab, different second-level sub-tabs are mounted based on the scenario. Enter the appropriate tab for your masking scenario before starting the configuration.

    First-level tab

    Second-level sub-tab

    Applicable scenario

    Dynamic Data Masking

    Rule / Masking Policy / Workspace Management

    DataWorks application-level masking (Data Studio, DataAnalysis, Data Map).

    Static Data Masking

    Rule list (no inner sub-tab)

    DataWorks Data Integration real-time synchronization tasks.

    MaxCompute Engine Masking

    Rule / Masking Policy

    Enforced masking at the MaxCompute engine layer.

    Hologres Engine Masking

    Rule / Masking Policy

    Enforced masking at the Hologres engine layer.

    Ranger Engine Masking

    Rule / Masking Policy

    Engine-level masking for data sources managed by Ranger, such as EMR Hive and StarRocks.
    Note

    The Workspace Management sub-tab is available only under the Dynamic Data Masking first-level tab. Other masking scenarios do not require per-workspace enable/disable. The actual supported masking scenarios are subject to the page display.

    Dynamic data masking policies

    Add a desensitization rule

    Important

    DataWorks industry templates provide predefined masking rules for common data types. If you want to create your own masking rules, you must first disable the predefined rules for the relevant data types in the industry templates.

    1. On the Data Masking page, click the Dynamic desensitization tab to go to the settings page.

    2. On the Dynamic Data Masking tab, click the Rules tab.

    3. In the upper-left corner, click New Rule and configure the following parameters.

      Field

      Description

      Data Type

      The data type to which the rule applies.

      Desensitization mode

      The method for masking this data type during user access.

      Note

      Enter sample data in the Raw data field to verify that the Data after desensitization output is correct.

      Apply to desensitization strategy

      The scope to which the masking rule applies, including the User Scope, feature scope, and data scope.

    4. Click Confirm to save the masking rule.

    Add a masking policy

    1. Click the Dynamic desensitization tab, and then go to the Desensitization strategy tab.

    2. In the upper-left corner, click New Policy to configure the policy.

      • Configuration Effective Conditions.

        A masking policy takes effect when its effective conditions are met. The following table describes the parameters.

        Parameter

        Description

        Policy name

        The name of the masking policy.

        User Scope

        Specifies whether the policy applies to all users or only specific users.

        DataWorks function

        The policy takes effect when sensitive data is accessed through specified DataWorks features: Data Map, Data analysis, or Data development.

        Covered Items

        The masking rule takes effect when a user accesses sensitive data in the specified projects or databases.

        Data Type

        The masking rule takes effect when a user accesses the specified sensitive data types. The rule can include one or more sensitive data types.

        Important

        A masking rule for this data type must be configured and enabled first.

      • Configuration Exception conditions (whitelist).

        A policy is bypassed if the following exception conditions are met. The following table describes the parameters.

        Parameter

        Description

        Data Type

        The data types to exclude from this policy. Masking is not performed on data of these types.

        Note

        A masking rule must be configured and enabled for the data type.

        Important

        The data types selectable in the whitelist are limited to those already selected in the data types field of the effective conditions in the main policy form. To whitelist a new data type, first select it in the main policy form's data types field, and then return here to add it to the whitelist.

        Whitelisted users

        RAM users or user groups who are exempt from the policy. Masking is not performed when these users access the specified data types.

        Effective Time Range

        The period during which the exception (whitelist) is active. You can configure a specific Time period or set it to Permanent.

    3. To adjust policy priority, click More and select Move Up or Move Down in the Operation column. This changes the order in which policies are matched.

      Note

      Matching order takes effect only in the dynamic data masking scenario. Policies for MaxCompute / Hologres / Ranger engine masking and static masking are independent of each other and do not have a matching order. Therefore, the Move Up / Move Down operations are available only in the policy list of dynamic data masking.

    Verify Policy (match preview)

    The Verify Policy button is located on the toolbar of the Masking Policy sub-tab under the Dynamic Data Masking tab (provided only for the dynamic data masking scenario). It simulates policy matching for a specified user accessing a specified data type through a specified DataWorks feature under a specified project, without actually accessing the data. Use it before going online to verify whether the matching order meets expectations.

    1. On the toolbar of the Masking Policy sub-tab, click Verify Policy to open the Verify Policy dialog box.

    2. In the dialog box, configure the following parameters:

      • User to Verify: the RAM user for the simulated access (required).

      • DataWorks Feature: the feature entry point that the simulated user uses (required).

      • Data Type: the data type accessed by the simulated user (required).

      • Project: the project in which the simulated access occurs (optional).

      • Specified Time: the time point of the simulated access (optional, used to validate the whitelist time window).

    3. Click Verify. The system returns the name of the matched policy, the masking algorithm, and the status of the data watermark switch. If no policy matches, a red prompt No masking policy matched is displayed.

    Note

    Verify Policy only simulates the matching process and does not actually read data.

    Manage masking rules and policies

    On the Rule sub-tab or the Masking Policy sub-tab, you can edit, enable, disable, or delete individual entries. When you delete a rule that is referenced by a masking policy, the system enters a two-phase Force Delete confirmation flow.

    Important

    Force Delete a rule: When you delete a rule referenced by a masking policy, the system displays a Force Delete secondary confirmation dialog box that lists the affected masking policies. After you confirm, the references to that data type in these masking policies are unbound, and the corresponding whitelist entries are also deleted. Confirm the impact scope before you proceed.

    Enable dynamic data masking

    Important

    For data types with masking rules configured in an enabled workspace, DataWorks evaluates masking policies sequentially and applies the first one that matches. The workspace-level master switch is provided only for the dynamic data masking scenario; other masking scenarios do not require per-workspace enable/disable.

    You must enable dynamic data masking for the workspace. Once enabled, the policies take effect in Data Studio and DataAnalysis.

    1. On the Dynamic desensitization tab, click the Workspace management tab.

    2. On the Workspace management tab, you can Open or disable a single workspace in the Status column. You can also select multiple workspaces and click Batch open or Batch Disable in the lower-left corner.

      • After you toggle the status of a single workspace or in batch, the system displays a secondary confirmation prompt: The status change takes effect within 5 minutes. The actual delay is subject to the backend policy delivery.

    Engine desensitization

    Engine-level masking refers to masking that is enforced at the database engine layer. It has higher priority than dynamic data masking and covers all access paths, including database clients outside DataWorks. When both engine-level masking and dynamic data masking are configured for the same data type, the result of engine-level masking prevails. Engine-level masking currently supports three scenarios: MaxCompute, Hologres, and Ranger. The overall configuration flow (add rule, add policy, configure exceptions) is similar to that in Dynamic data masking policies. The following sections describe only the differentiated fields and constraints for each scenario.

    Common constraints

    • Engine-level masking does not distinguish DataWorks access entries. Therefore, the DataWorks Feature field (Data Map / DataAnalysis / Data Studio) is not displayed in the policy form.

    • User permission pre-check: For the three engine masking scenarios (MaxCompute / Hologres / Ranger), if the policy specifies a User Scope or adds users to the whitelist, the system verifies whether these users have access to the selected Coverage Project before saving the policy. If any user-project combinations have insufficient permissions, the system displays a rejection list and blocks the save. Grant the missing permissions to the relevant users in Data Access Control or in the project authorization of the corresponding engine, and then try again. This pre-check is not performed for the dynamic data masking or static data masking scenarios.

    MaxCompute engine masking

    MaxCompute engine masking targets sensitive data in MaxCompute projects. The engine enforces masked results on the SQL execution path.

    Field

    Description

    Coverage Project

    Required. Select the MaxCompute project in which the policy takes effect.

    User Scope

    Supports All users or Specific users. When you select specific users, a user permission pre-check is triggered before saving.

    List filters

    The list filters for MaxCompute engine masking policies slightly differ from those for dynamic data masking. For example, the Coverage Project filter is not displayed as an independent filter.

    Hologres engine masking

    Hologres engine masking targets sensitive data in specified databases under Hologres instances. The Hologres engine enforces masking on query results.

    Field

    Description

    Coverage Scope

    A configuration item unique to the Hologres engine. You must configure a Hologres instance, database, data source, and resource group, and pass the Connectivity Test.

    Important

    You must configure at least one Hologres database that passes connectivity verification before you can submit the policy. Otherwise, the system prompts Configure at least one Hologres database that passes connectivity verification.

    User Scope

    Hologres engine masking does not support selecting individual users. The policy applies to all users within the coverage scope. Use the whitelist to specify exceptional users.

    Ranger engine masking

    Ranger engine masking applies to data sources managed by Ranger, such as EMR Hive and StarRocks. Ranger enforces masking at the engine layer, ensuring that masked results are returned when the data source is accessed through any client.

    Field

    Description

    Data Source Type

    Required. Select the Ranger data source type to manage, such as EMR Hive or StarRocks.

    Cluster / Instance

    Required. Select the specific cluster or instance to which the data source belongs. The user drop-down range in the subsequent whitelist is related to the selected cluster.

    Connectivity Test

    Required. On the selected cluster, click the Verify Connectivity button to verify the reachability between DataWorks and the Ranger cluster.

    Important

    You must pass the Ranger cluster connectivity test before you can save the policy. If the test fails, the Save button is disabled.

    Ranger Audit

    Optional. When enabled, Ranger records audit logs for masking hits, facilitating subsequent compliance traceability.

    User Scope

    Ranger engine masking supports only All users. The Select Users option is disabled. To exclude specific users, configure them in the whitelist.

    Whitelist Users

    The user drop-down range in the whitelist is associated with the selected Ranger cluster and displays only accounts that are mapped under that cluster.

    Static desensitization

    Static data masking physically replaces sensitive data at the destination, permanently overwriting the original data.

    Important

    Static masking rules apply only to real-time synchronization tasks in DataWorks Data Integration where this feature is configured. The feature is enabled by default but can be disabled.

    1. On the Data Masking page, click the Static desensitization tab to go to the list of static masking rules.

    2. In the upper-left corner, click New Rule to configure a static masking rule. The following table describes the key parameters.

      Parameter

      Description

      Data Type

      Select the data type to which you want to apply the masking rule, such as "Phone Number". You can select an existing type or create a new one.

      Desensitization rule name

      Specify a clear and descriptive name for the rule.

      Desensitization mode

      Select a masking method, such as Masking desensitization, Hash Desensitization, or Custom Paohenge transformation.

      • Masking desensitization: Precisely define the character ranges to mask or preserve. For example, for Left to right, mask characters 1 to 2, and do not mask characters 3 to 4.

      • Hash Desensitization: Set a salt value to increase the security of the hash.

      • Custom Paohenge transformation: Set the feature value and the character set for replacement.

      Data watermark

      If enabled, the system embeds an invisible watermark into the data during the masking operation. This watermark helps trace the source of sensitive data. For more information, see Data Traceability.

      Note

      The Data Watermark switch is displayed and available only when the Masking Method is Hash or Format-Preserving Encryption (FPConvert). Other masking methods (mask, replace, transform, random shuffle, data encryption, and so on) do not support watermark embedding.

      Enabled

      Select Enable Now or Not Enabled. Only enabled rules take effect in relevant synchronization tasks.

      Effect Verification

      Use the verification tool to check the masking effect. Enter sample data in the Raw data box, click Verify now, and verify that the Data after desensitization is correct.

    3. Click Confirm to save the rule.