DocsICP FilingConsole
Documentation
Home Page AI-Native Database Service User Guide Agent Data Gateway Data protection

Data protection

Updated at:
Copy as MD
My Favorites

Data protection provides fine-grained visibility control over SQL queries executed through Agent Data Gateway, without modifying the data in your business databases. This topic describes the core concepts of field-level protection and row-level protection, and explains how to configure protection rules, grant permissions, and view protection results.

Overview

Data protection provides fine-grained control over the visibility of data returned by SQL queries executed through Agent Data Gateway, without modifying the data in your business databases. Agent Data Gateway provides the following two types of protection capabilities:

Capability

Protected object

How it takes effect

Behavior without permissions

Field-level protection

A specific field (column) in a table.

The field is automatically masked during queries.

A masked value is returned based on the configured masking algorithm (for example, 138****5678).

Row-level protection

A subset of data rows in a table.

A row filter condition is automatically injected during queries.

Unauthorized rows are automatically filtered out and are not visible in the query results.

The overall workflow consists of the following three steps:

  1. Configure protection rules (administrator): On the data protection page, configure a masking method for a field, or configure a row control rule for a table.

  2. Grant permissions (administrator): Grant permissions to users or agents that need to access plaintext values or protected rows.

  3. Automatic enforcement (user): When a user queries data through the gateway, the system automatically masks or filters the data based on the user's permissions. No additional action is required.

Supported database engines

Data protection supports the following database engines: MySQL, PolarDB MySQL, AnalyticDB for MySQL, Hologres, PostgreSQL, and PolarDB PostgreSQL.

Core concepts

Field-level protection

Field-level protection involves the following concepts:

  • Protected field: After a field is marked as protected, any user without permissions can view only the masked value when querying the field.

  • Masking algorithm without permissions: The masking algorithm applied to query results when a user does not have read permissions on the field. The default is full masking.

  • Masking algorithms available for authorization: The range of masking algorithms that the administrator allows to be authorized for the field. When granting permissions, you can select an algorithm only from this range. The default is plaintext.

Agent Data Gateway provides the following built-in masking algorithms:

Name

Effect

Example

Plaintext

No masking. The original value is returned.

13812345678 → 13812345678

Full masking

The value is fully masked and ****** is always returned.

13812345678 → ******; NULL → ******

Partial masking

The first 3 and last 4 characters are kept, and the middle characters are masked.

13812345678 → 138****5678

Row-level protection

Row control rules have two types. You can select only one type for a table.

Isolate by dimension (whitelist, all rows invisible by default)

Data is isolated based on field content. Permissions are assigned by using the values of a field (such as "department" or "region") as dimensions. A user can view only the data rows that correspond to the authorized values. All other rows are invisible.

Example: After you isolate the purchase orders table by the department field, a user granted row permissions for the Sales department can view only the purchase records where department = Sales, and cannot view records of other departments.

Protect by row (blacklist, all rows visible by default)

Protection is applied only to specific rows based on a condition. When an unauthorized user runs a query, these rows are automatically filtered out, and all other data remains visible.

Example: After you protect the rows where department = Finance in the purchase orders table, users in the Sales department cannot view the purchase records of the Finance department, but the records of other departments (such as Marketing and Legal) remain visible.

The following table compares the two types:

Item

Isolate by dimension

Protect by row

Control model

Whitelist.

Blacklist.

Default visibility for unauthorized users

All rows invisible.

All rows visible except protected rows.

Rule definition

A list of dimension fields (for example, ["dept"]).

A condition predicate for protected rows (for example, dept = 'Finance').

Authorization semantics

Grant specific dimension values (for example, dept ∈ {Sales}). The * wildcard is supported to grant access to all values.

Boolean access: After authorization, the user can view the protected rows.

Typical scenarios

Data isolation for multi-tenancy, by department, or by region.

Protection of a small number of highly sensitive rows.

Boundary between field-level and row-level protection

Field-level protection and row-level protection are two independent control capabilities that can be stacked. They solve different problems:

Dimension

Field-level protection

Row-level protection

Protected object

The value form of a field (whether the value in the same row is returned as plaintext or in masked form).

The visibility scope of rows (which rows appear in the result set).

How it takes effect

Masks protected fields. When a protected field enters the computation pipeline, the query is directly blocked.

Automatically injects a row filter condition into the query.

Authorization model

Field-level authorization: read (with a specified masking algorithm) or write.

Row-level authorization: read only.

Handling of write operations (DML)

Without field write authorization, write operations such as INSERT and UPDATE on protected fields are directly blocked.

No row-level blocking. Only a risk alert is provided.

Behavior without authorization

The row remains visible, but protected fields return masked values.

Unauthorized rows are entirely invisible (filtered out).

Prerequisites

  • Configuring protection rules and granting permissions require administrator permissions. For more information about user roles, see Manage users.

  • The database instance that you want to protect is registered as a data source in Agent Data Gateway.

Configure protection rules

Configure field-level protection

Field-level protection is used to configure a masking method for sensitive fields in a table. To configure field-level protection, go to Data Protection Center > Protected Object Management > Field-level tab. The following two views are supported:

  • Global list: Displays all protected fields marked under the current account. You can search by field keyword.

  • View by table: Locate a table, view all its fields, and mark or unmark the fields.

To add a field-level protection rule, perform the following steps:

  1. Log on to the AI-Native Database Service console.

  2. In the left-side navigation pane, click Agent Data Gateway to go to the Agent Gateway console.

  3. In the left-side navigation pane of the console, choose Data Protection Center > Protected Object Management, and click the Field-level tab.

  4. Click Add Field Setting.

  5. Select the database, table, and field in sequence.

  6. Configure the Masking algorithm without permissions (the default is full masking).

  7. Configure the Masking algorithms available for authorization (multiple selections allowed, the default is plaintext). This defines the range of algorithms that can be selected when granting permissions.

  8. Click Save. The rule takes effect immediately after it is saved. Query results of this field are masked for all users without permissions.

When you edit or remove a field-level protection rule:

  • Edit: If you narrow the range of Masking algorithms available for authorization, authorizations that fall outside the new range are automatically revoked in cascade, and authorizations within the range are retained.

  • Remove: When you remove field protection, all field-level permissions granted on the field are revoked in cascade, and the field is restored to a normal field (visible in plaintext).

Configure row-level protection

Row-level protection is used to configure visibility rules for data rows in a table. To configure row-level protection, go to Data Protection Center > Protected Object Management > Row-level tab. Both the global list and view-by-table views are supported. The list displays the rule name, instance, database, table, type (protect by row or isolate by dimension), and the controlled predicate or dimension field of each rule.

To add a row-level protection rule, perform the following steps:

  1. On the Protected Object Management page, click the Row-level tab, and then click Add Row Setting.

  2. Enter the Rule Name (must be unique).

  3. Select the database and table in sequence.

  4. Select the rule type:

    • Isolate by Dimension: Specify a dimension field (such as dept or region). After the rule is saved, the table is invisible to all unauthorized users by default. You must grant row-level permissions by dimension value to make rows visible.

    • Protect by Row: Enter the controlled condition. After the rule is saved, rows that match the condition are invisible to unauthorized users, and other rows are not affected.

  5. Click Save.

Important

You can select only one type of row rule for a table. If a Protect by Row rule already exists on a table, you cannot create an Isolate by Dimension rule on it, and vice versa.

Grant permissions

Grant field-level permissions

After field-level protection is configured, all user queries return masked values by default. An administrator must grant permissions to users or agents that need to view plaintext values.

  1. In the left-side navigation pane of the console, choose User Management > Permission Management.

  2. Click Add Authorization.

  3. For Authorization Scope, select Field.

  4. Select the database, table, and field in sequence (the field must be a marked protected field).

  5. Select the Permission Type:

    • Read (Query): You must also specify the masking algorithm to be used after authorization, which must be within the range of Masking algorithms available for authorization configured for the field.

    • Write (Modify): Allows write operations (DML such as INSERT and UPDATE) on the field. Write operations on protected fields performed by users without write authorization are directly blocked.

  6. Set the Validity Period (start and end time). The permission automatically expires after the period ends.

  7. Click Submit.

Grant row-level permissions

After a row control rule is created, use row-level authorization to control the range of rows visible to each user or agent.

Note

Row-level authorization supports only the Read (Query) permission type. Row-level protection takes effect only for queries. Write operations are not blocked at the row level; only a risk alert is provided.

  1. On the Permission Management page, click Add Authorization.

  2. For Authorization Scope, select Row.

  3. Select the Table: first select the database, and then select the table.

  4. Select the Row: from the drop-down list, select a row control rule configured on the table. The rule is displayed as rule name (database.table/type).

  5. For Permission Type, select Read (Query).

  6. Complete the configuration based on the rule type:

    • Protect by Row: The page displays the controlled condition of the rule (for example, WHERE tenant_id = 'tenant_a'). The condition is defined by the row control rule and cannot be modified during authorization. After authorization, the user can view the data rows that match the controlled condition.

    • Isolate by Dimension: Specify the authorized set of values for each dimension field (for example, dept ∈ {Sales, Marketing}).

  7. Set the Validity Period.

  8. Click Submit.

Protection results

Masking results

Take the customer_info table as an example. The phone field is protected (full masking without permissions; the range available for authorization is plaintext and partial masking). A user runs the following query:

SELECT name, phone FROM customer_info;

The following table describes the results returned under different permissions:

User permission status

phone value returned

Description

No field read authorization

******

The value is returned based on the field baseline Masking algorithm without permissions (full masking).

Authorized with sys_keep_prefix_suffix (partial masking)

138****5678

The value is returned based on the algorithm specified in the authorization (partial masking).

Authorized with sys_none (plaintext)

13812345678

The plaintext value is visible.

Authorization expired or revoked

******

The value falls back to the baseline masking algorithm.
Important

For a protected field that is still masked for the current user (including no authorization, authorization with only a masking algorithm such as partial masking, or expired authorization), the field is allowed only in the SELECT projection position and is returned as a masked value in the query results. Once the field enters the computation pipeline, the SQL statement is rejected.

Row filtering results

Protect-by-row results

Rule: The controlled condition on the purchase orders table is dept = 'Finance'. A user runs the following query:

SELECT * FROM purchase_orders;

User permission status

Execution result

Visible data

No row-level authorization

Injects WHERE NOT (dept = 'Finance')

All records except those of the Finance department.

Authorized with the rule

No filter condition is injected.

All records (including the Finance department).

Isolate-by-dimension results

Rule: The dimension field on the purchase orders table is dept. The following table describes the execution results under different permissions:

User permission status

Execution result

Visible data

No row-level authorization

Injects WHERE (1 = 0)

Empty result (all rows invisible).

Authorized with dept ∈ {Sales}

Injects WHERE (dept IN ('Sales'))

Only records of the Sales department.

Authorized with dept ∈ {Sales, Marketing}

Injects WHERE (dept IN ('Sales', 'Marketing'))

Records of the Sales and Marketing departments.

Authorized with dept = "*" (wildcard)

No filter condition is injected.

All records.
Previous：Manage identity sourcesNext：Data Agent