Data Management:Sensitive Data Management Overview

Background information

The sensitive data protection feature helps you identify sensitive data assets. This prevents data misuse, protects your data assets, and helps you avoid data breaches that can cause business losses or fines. The following figure shows the structure of sensitive data protection.

Supported databases

• Relational databases:

  • MySQL series: RDS MySQL, PolarDB for MySQL, and other MySQL sources

  • SQL Server series: RDS SQL Server and other SQL Server sources

  • PostgreSQL series: RDS PostgreSQL, PolarDB for PostgreSQL, and other PostgreSQL sources

  • MariaDB series: RDS MariaDB and other MariaDB sources

  • PolarDB for PostgreSQL (Compatible with Oracle)

  • PolarDB Distributed Edition

  • OceanBase

  • Oracle

  • DB2

  • Dameng Database

  • Lindorm: Lindorm CQL and Lindorm SQL

  • OpenGauss

• Data warehouses:

  • AnalyticDB for MySQL

  • AnalyticDB for PostgreSQL

  • Data Lake Analytics (DLA)

  • ClickHouse

  • MaxCompute

  • Hologres

  • Hive

Notes

• The sensitive data protection feature works only for databases managed in DMS. It does not affect other endpoints, such as application programming interfaces (APIs).

• Using the sensitive data protection feature does not affect the data in your source database. For example, if you mask data in an RDS MySQL database that is managed in DMS, the masking is visible only in DMS. The data in your source database is not affected.

Features

• Provides a dashboard for sensitive data assets. This helps you centrally manage the distribution of your sensitive data.

• Automated data scanning.

  • You can customize the trigger period for data scans.

  • Automatically identifies and classifies sensitive data. This helps you promptly find and effectively manage sensitive data within your assets.

  • Provides built-in and custom classification templates to improve your fine-grained classification model. You can use the Principle of Least Privilege (PoLP) to manage sensitive data.

• Sensitive data masking management.

  • Offers flexible management of masking algorithms using built-in and custom options. This lets you configure different masking rules for different scenarios and fields. This helps you achieve granular access control and minimize the exposure of sensitive data.

  • Provides a staging environment for masking and identification rules.

  • Manage access to masked data by personnel and applications.

• Monitors the use of sensitive data, audits for anomalies, and provides alerts. This helps you trace abnormal usage and the source of data breaches.

Glossary

• Security level: Some fields, such as mobile phone numbers and ID card numbers, contain sensitive data. The values in these fields should not be displayed during routine data queries. Data is divided into three security levels based on its sensitivity:

  • Low: Corresponds to the original DMS classification of Internal. Field values at the low sensitivity level are displayed in plaintext. Data in Security Collaboration mode defaults to the low sensitivity level.

  • Medium: Corresponds to the original DMS classification of Sensitive. Field values at the medium sensitivity level are displayed after masking.

  • High: Corresponds to the original DMS classification of Confidential, with a higher sensitivity level than Medium. Field values at the high sensitivity level are displayed after masking.

  Note

  After you set a security level, data usage is affected as follows:

  • When you query data in the SQL Console, fields with medium or high sensitivity for which you do not have permission are displayed as asterisks (*) or in a custom format.

  • When you query, export, or change data, you must separately request permission for fields with medium or high sensitivity.

  • When you export or change data that involves fields with medium or high sensitivity, database administrators (DBAs) and administrators can set different approval flows.

• Identification rules: Includes built-in identification rules based on industries and regulations. You can also customize rules based on metadata and data content as needed.

• Data classification: You can classify data according to various acts and regulations and create custom data classifications.

  • Level 1 category: For example, personal information, corporate information, and location information.

  • Level 2 category: For example, mobile phone numbers, mailboxes, and bank cards.

• Masking algorithms: Supported masking algorithms include hashing, masking, replacement, transformation, and encryption. You can use the built-in algorithms to configure new masking rules.

• Masking policies: A masking policy is a set of masking rules configured for selected sensitive fields.

Workflow

1. Enable sensitive data protection

2. Attach a classification template to an instance

3. Configure a scan task

4. View the detected sensitive fields

5. Manage sensitive data

6. Audit sensitive data