---
title: "数据脱敏管控实践 - 开发者中心 ODC V4.4.2 | OceanBase 文档中心"
description: 数据脱敏管控实践 背景信息 在数据库协同开发领域，敏感数据管控对于企业和用户都至关重要。近年来，随着数据安全法、个人信息保护法等法律法规的颁布实施，国家和社会对于隐私数据安全的重视程度不断提升；操作审计和隐私数据保护变得愈加重要，已成为数据库协同开发工具选型的关键考量指标。 隐私数据通常包括用户的身份证号、手机号、家…
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*lqS5SYzz_YEAAAAAAAAAAAAADiGDAQ/original) 开发者中心 ODCV 4.4.2

# 数据脱敏管控实践

更新时间：2026-05-23 13:41:42

[编辑](https://github.com/oceanbase/odc-doc/edit/V4.4.2/zh-CN/1250.interactive-tutorial/800.data-masking-control-practices.md)  

## 背景信息

在数据库协同开发领域，敏感数据管控对于企业和用户都至关重要。近年来，随着数据安全法、个人信息保护法等法律法规的颁布实施，国家和社会对于隐私数据安全的重视程度不断提升；操作审计和隐私数据保护变得愈加重要，已成为数据库协同开发工具选型的关键考量指标。

隐私数据通常包括用户的身份证号、手机号、家庭住址等敏感信息，这是不可或缺的保障业务正常运行的基础数据。为了确保用户数据不会泄漏，必须严格限制对业务库的访问。然而，完全限制访问也可能导致协作效率下降，这是一个令人担忧的问题。因此，在面对企业级的数据库开发场景时，我们需要认真思考：如何以安全合规的方式积极预防内部数据泄漏风险，以确保用户的隐私数据得到最严格的保护？本文将针对隐私数据保护及安全合规，分享 ODC 的设计思考和解决方案。

## 场景描述

企业在进行运维、开发和数据分析等工作时，通常需要执行数据库查询操作。这些数据库中可能存在业务需要且无法剥离的敏感数据，而直接查询这些数据可能引发隐私泄露风险。同时，过于严格限制访问又可能导致工作效率低下的问题。在这种情况下，数据脱敏技术可以发挥作用，它可以在 SQL 查询、数据导出等数据出库的场景中对敏感数据进行脱敏处理再进行输出，以既保证数据库可访问性，又不暴露隐私数据。

让我们通过一个直观的例子来说明：假设在数据库中存在一个名为"student"的表，记录了所有学生的基本信息。现在，我们需要统计学生的年龄，但又不希望透露学生的住址、联系方式等敏感信息。在这种情况下，执行 SQL 查询后，"student"表的结果应该如下所示。这种数据脱敏技术不仅确保了高效灵活的工作流程，还在任何时候都能最大程度地保护敏感信息的隐私安全。

![1](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-1.png)

ODC 将敏感数据的保护放在首要位置，为企业提供了可信赖的全场景敏感数据保护，确保用户的数据安全合规。访问数据库通常是获取敏感数据的主要途径，甚至在某些情况下可能是唯一途径。如果能够在数据库查询阶段对敏感数据进行脱敏处理，这就成为数据交互的第一道防线，最大程度地保障数据的安全。

同时，通过数据隐私保护能力，安全管理员可以根据需要配置敏感数据规则和脱敏算法，确保敏感数据的绝对安全。即便是数据库管理员（DBA）和开发人员，经过配置后也无法直接接触敏感数据，从而极大地降低了数据泄露的风险。这种严格的数据隐私保护机制，使得企业的敏感信息在任何时候都能得到最大程度的保护。

在 ODC 的数据库协作开发流程中，用户无法直接访问数据库做数据查询。要想查看数据，只能通过以下方式：

1. 在数据库对象管理页查看表数据。
 2. 提交导出工单，将数据导出到文件后进行查看。
 3. 提交数据库变更工单，在变更任务中执行 SELECT 语句，然后查看执行结果集。
 4. 在 SQL 窗口执行 SELECT 语句，查看结果集。

对于方式 1 和 2，实现数据脱敏相对容易。因为我们已经清楚地知道用户正在访问哪些库表列，只需要将敏感列进行脱敏处理即可。但是在方式 3 和 4 中，用户可以输入各种复杂的 SQL 查询，很难准确识别用户到底在查哪些数据，这是为什么动态脱敏比静态脱敏更具挑战的原因。

值得一提的是，ODC 的数据脱敏覆盖了所有数据出库场景，并且支持 OceanBase 数据库所有类型的 SQL 语法。无论 MySQL 兼容模式 和 Oracle 兼容模式，ODC 都可以提供数据脱敏解决方案。

以下我们通过一个实际的业务场景，体验如何使用 ODC 实现全场景敏感数据防护。

## 技术背景

首先了解一些与 ODC 相关的关键术语，为了方便理解，本文先约定以下术语：

- 敏感列：数据库表中，存储敏感数据的列。
 - 脱敏算法：用于对敏感数据进行脱敏处理的算法。
 - 识别规则：用于标记数据库的某一列为敏感列的匹配条件，ODC 可以将符合规则的列自动识别敏感列。

## 技术架构

接下来我们将聚焦功能特性，从产品设计层面介绍 ODC 数据脱敏的实现原理。如果你对技术细节感兴趣，欢迎访问 [ODC 的开源社区](https://github.com/oceanbase/odc)。携手共建 ODC 开源宇宙。

要实现数据脱敏，关键要解决两个问题：

- 如何知道数据库中的哪些列是敏感数据？
 - 对敏感数据采用什么方式进行脱敏处理？

为了解决第一个问题，我们引入了敏感列的概念：将数据库中存储敏感数据的物理列标记为敏感列，在数据出库时，所有涉及敏感列的数据都会被视为敏感数据。至于第二个问题，我们提供了 21 种不同的数据脱敏算法，包括全脱敏和半脱敏方式，覆盖了中/英文姓名、手机号、邮箱、证件号码、地址、车牌号、IP 等常见敏感数据类型。

### 领域模型

ODC 是多组织架构的，并且在 V4.2.0 开始引入了基于项目的管控模式：不同组织间的资源和数据完全隔离，同一组织内的多个项目可以共享同一个数据源。因此，为实现数据脱敏，我们做了下图所示的产品设计：

![12](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-12.png)

### 脱敏算法

同一组织共用同一套脱敏算法，允许项目内所有成员查看脱敏算法、测试脱敏效果。蚂蚁集团在隐私计算和敏感数据保护方面一直处于国内第一梯队。因此，我们参考了蚂蚁集团的脱敏规范，提供了以下 21 种脱敏算法，能覆盖绝大部分应用场景。

![13](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-13.png)

### 敏感数据管理

事实上，数据的敏感与否是与具体存储的内容相关的，往往只有项目内成员才知悉到底哪些列是需要脱敏的。因此，我们把敏感数据（即敏感列）放在项目级别，由项目管理员或 DBA 负责管理。为了保证脱敏结果符合预期，避免误判，用户可以主动将需要脱敏的数据列添加为敏感列。通过手动添加敏感列，依次选择敏感列所属的数据源、数据库、表和列然后添加即可。如果数据源中需要脱敏处理的列有很多，我们推荐使用自动扫描的方式。只需要根据敏感列所处的位置和基本属性，创建合适的识别规则，然后发起一个自动扫描任务即可。

为了最大程度满足用户的需求，ODC 支持三种方式配置敏感列的识别规则，分别是：

- 路径：就是根据敏感列所处的库、表、列来匹配。这种方式最为简单粗暴，能满足用户的大部分需求。
 - 正则：基于正则表达式，根据库名、表名、列名和列备注来匹配。这种方式适用于敏感列分布在多个数据库，且需要批量添加的场景。
 - 脚本：基于 Groovy 脚本匹配。这种方式非常灵活，可以实现大范围筛选，也可以实现特别细粒度的定制化匹配规则，非常推荐用户使用这种方法。只需花五分钟的时间熟悉 Groovy 语法，就可以愉快地 coding 识别规则。

举例来说，你希望将某个数据源下所有名为 email 的列设为敏感列，那只需要编写以下脚本识别规则：

![14](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-14.png)

然后使用它来扫描即可（只需要三步）：

![15](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-15.png)

## 业务场景案例

### 准备验证数据

1. 在开始验证之前，首先使用 ODC 创建了两张数据表：数据表 1（employee_info）和数据表 2（employee_salary）。

   ```sql
   CREATE TABLE test.employee_info (
   id int NOT NULL COMMENT '员工 ID',
   name varchar(32) NULL COMMENT '员工姓名',
   email varchar(64) NULL COMMENT '员工邮箱',
   address varchar(128) NULL COMMENT '员工住址',
   CONSTRAINT pk_id PRIMARY KEY (id)
   ) DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_general_ci;

   CREATE TABLE test.employee_salary (
   id int NOT NULL COMMENT '员工 ID',
   salary float(10) NULL COMMENT '员工工资',
   CONSTRAINT pk_id PRIMARY KEY (id)
   ) DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_general_ci;

   ```
 2. 插入了模拟数据，以下是原始表数据的示例。

   #### 说明

   以下数据仅为模拟，不包含真实用户信息。

   ![2](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-2.png)
 3. 将需要进行脱敏处理的列添加到敏感列列表中。鉴于展示的数据列较少，我们采用手动添加的方式进行配置：

   ![3](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-3.png)

### 场景验证

接下来，让我们探讨在各种数据出库场景下，ODC 如何更好地帮助用户进行数据脱敏处理。

#### 场景一：白屏查看表数据，敏感字段脱敏后再展示

![4](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-4.png)

可以看到，在在数据库对象树查看表 employee_info 的数据时，可以注意到表中的敏感列数据已经经过脱敏处理。

#### 场景二：将数据导出到文件，敏感数据被脱敏处理

接下来，我们尝试将包含敏感列的表导出为 CSV 文件。

![5](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-5.png)

查看导出的 CSV 文件内容，可以发现发现敏感列同样已被脱敏处理：

![6](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-6.png)

#### 场景三：执行 SELECT 查询，任何 SQL 语法都无法绕过数据脱敏

正如前面提到的，动态数据脱敏的核心挑战在于在各种复杂 SQL 语法下准确识别敏感列。下面我们逐步探讨 ODC 动态数据脱敏对 SQL 语法的支持水平。

首先是一个简单的单表查询：

![7](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-7.png)

正如大家看到的，作为敏感数据的 email 列和 address 列被成功脱敏。接下来，我们测试了一些内置函数、CASE WHEN 以及 JOIN 和 UNION 查询：

![8](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-8.png)

这些查询对于 ODC 动态数据脱敏来也可以覆盖处理。结果集的三列均已成功脱敏，让我们逐一分析原因：首先，id 列并非敏感数据，但因与其进行 UNION 运算的 address 列是敏感数据，导致结果集的 case_id 列需要脱敏；同样地，name 列并非敏感列，因为使用了 CONCAT() 函数将其与 salary 列进行了拼接，导致 concat(t1.name, '-', salary) 列也需要脱敏；最后，email 列和 name 列合并的结果自然也是需要脱敏的。

我们进一步测试了多层嵌套子查询：

![9](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-9.png)

同样的，可以看到，对于 FROM 子句和 SELECT 子句中出现的子查询，无论是关联子查询还是非关联子查询，ODC 都能够正确应对。

虽然我们已经能够处理绝大多数 SQL 查询，但 ODC 并不满足于此。ODC 还支持对递归和非递归 CTE 的语法支持，并且能处理递归 CTE 中出现的敏感列传递：

![10](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-10.png)

上面的例子中，你可能会好奇为什么 cte_id 列也被脱敏了？这是因为 Recursive CTE 的敏感数据“传染”问题：在第一次递归中，CONCAT(cte_email, cte_name) 运算导致 cte_name 列包含了敏感数据，即 cte_name 列变成了敏感列；而在第二次递归中， CONCAT(cte_name, cte_id) 运算使 cte_id 列也被“感染”上敏感数据。因此，最终的结果是，ODC 对结果集的三列均作了脱敏处理。

#### 其它场景

数据库变更与 SQL 窗口查询在本质上没有太大区别，都是执行 SQL 语句并输出结果。因此，在 SQL 窗口中支持的动态数据脱敏能力同样适用于数据库变更工单。

对于存储过程、程序包、触发器和自定义函数，我们目前尚未找到合适的方案来动态拦截它们对敏感数据的访问。但这并不会影响敏感数据管控的有效性。因为上述 4 种数据库对象访问敏感数据的前提是首先创建它们，而 ODC V4.2.0 已经将这些数据库对象的 CREATE 权限和 PL 的调试与执行权限都纳入了管控（如下图所示 SQL 窗口规范），没有相应权限的用户将无法执行这些“危险”操作。因此，ODC 的敏感数据管控能力在各方面都形成了完备的闭环。

![11](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/odc/433/1250.interactive-tutorial/data-masking-control-practices-11.png)

 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线