数据库变更是日常开发和运维里绕不开的活。为了降低线上环境出故障的风险，通常会配合工单系统来发布变更，这样流程可控，也能减少低级错误。市面上能选的工具不少，有开源的，也有商业化的。这次我挑了四款比较常见的：Yearning、Archery、Bytebase，还有 CloudDM，从工单场景出发做了一轮体验和横向对比，给大家一些参考。

测评方法​

不同工具的功能侧重点不一样，如果各方面都测，反而看不出差别。所以我主要关注最常见的两个场景：业务上线和数据订正。测试用的版本主要是社区版/免费版。

业务上线​

功能上线通常包括两部分：程序包和数据库脚本。程序包这块一般由 CI/CD 流程接管，这里不展开。数据库变更脚本经常包括一条或多条需要执行的 SQL 语句，以 DDL 为主。在这个场景下，我准备了两个测试点：

• DDL 需要符合一定的规则；
• 工单里可以处理 DDL/DML 混合语句。

-- 添加表
create table biz_model (
  id             bigint NOT NULL AUTO_INCREMENT,
  created_time   datetime  COMMENT 'Creation timestamp',
  updated_time   datetime  COMMENT 'Last update timestamp',
  content        varchar(50)  NOT NULL COMMENT 'biz body',
  PRIMARY KEY (id)
);

-- 初始化数据
insert into biz_model (id, created_time, updated_time, content) 
values (1, '2025-05-30 14:02:39', '2025-05-30 14:02:39', '... content1 ...' );

insert into biz_model (id, created_time, updated_time, content) 
values (2, '2025-05-30 14:02:39', '2025-05-30 14:02:39', '... content2 ...' );

insert into biz_model (id, created_time, updated_time, content) 
values (5275, '2025-05-30 14:02:39', '2025-05-30 14:02:39', '... content3 ...' );

-- 修改老表
alter table admin_user
  add biz_id varchar(50)  NOT NULL COMMENT 'biz id';

数据订正​

数据订正也比较常见，有时候是有 bug，有时候是运维需要。重点是生产库不能停，在持续写入的情况下修改数据有一定概率会失败。因此在这个场景中，我准备了三个测试点：

• 订正需要修复的数据
• 出于某些原因，数据订正语句可能会报错
• 批量化更新大量数据

-- 修复一条数据
update biz_model set content = 'abc' where id = 1;

-- 修复一条数据（模拟 SQL 报错）
update biz_model set content = null where id = 5275;

-- 批量更新数据
update admin_user set biz_id = 0 where created_time > '2025-01-01';

对比一览​

先上对比表，直接看测试体验的结果：

下面来具体聊聊每款产品的使用体验，主要围绕 工单递交、SQL 审核、审批流程与工单执行 这几个环节展开。

CloudDM​

在 CloudDM 中，对数据库的操作分成三类：数据查询、CI/CD 和 工单。默认情况下，查询控制台只能执行查询语句，DDL/DML 需要通过工单才能执行。如果需要，也可以修改环境策略，让它成为一个 SQL 客户端。

创建工单​

CloudDM 创建工单时，允许 DDL/DML 在同一个工单中混合使用。子账号如果在可视化操作过程中没有对应权限，系统会帮助用户快速创建对应的工单，方便继续走流程。

通过修改环境策略，CloudDM 可以禁止环境中数据源的工单功能，在只提供查询的环境中，可以更好地保证数据库的安全。

SQL 审核​

CloudDM 内置了 60 多条规则，并且基本适用于支持的 18 种数据源。比较极客的是，CloudDM 的所有规则全部使用特定的 DSL 语言来编写，并且支持自定义新的规则。这意味着除了内置规则之外，还可以根据自己特殊需要使用 DSL 编写个性化规则，免去二次开发的烦恼。

工单创建时，CloudDM 会自动检查 SQL，并明显地提示检查结果，标出问题 SQL 所在行。有多条语句的情况下，定位问题很快，改起来也方便。

在对工单进行 SQL 审核时，CloudDM 提供了两个安全级别。如果 SQL 命中了等级较高的 阻塞 级，就不能创建工单，只有 提示 级时可以选择强制递交工单。

审批流程​

CloudDM 有一个内置简易审批程序，可以提供审批的基本功能，也可以对接 钉钉、飞书、企业微信作为外部审批流程引擎，完成复杂的审批流程。

工单执行​

CloudDM 支持以事务方式执行工单，并提供 手动、立即、定时 三种执行模式。选择“已手动完成”意味着 DBA 可以自行处理工单，而不是完全交给系统。这在面对大型数据库或复杂 SQL 时更灵活，可以降低 DBMS 系统带来的不确定性。

CloudDM 支持工单调试功能，在“数据订正”场景里，即使遇到预设的报错，也可以人工介入处理，再继续执行后续 SQL，而不是简单地中断执行。

小结​

亮点

• UI 交互和权限控制结合得不错，操作体验顺滑，也有安全管控措施。
• SQL 审核可以精确定位问题语句所在行，方便排错。
• 审批可以对接钉钉、飞书、企业微信，适合团队协作。
• 工单执行方式灵活（立即 / 定时 / 手动），还能选事务模式。
• 支持工单调试，执行的时候碰到错误 SQL 可以人工介入后继续执行。

不足

• 在工单递交时没有整合查询计划信息。
• 回滚 SQL 需要手动补充，不够自动化。

Bytebase​

Bytebase 在产品上有 SQL 编辑器、工单 两种模式。SQL 编辑器可以执行 SQL 语句，而工单用于管控变更发布。Bytebase 的设计中，数据库变更主要依托于 Git 的 CI/CD，同时也提供了页面递交工单。通过页面递交工单的入口在 CI/CD 中通过创建变更计划来实现，分为 Schema 变更、数据变更 两类。

创建工单​

Bytebase 有两种创建工单的方式，一种基于可视化 UI 交互，另一种是纯 SQL 递交。通过 SQL 递交工单时 Bytebase 支持混合 DDL/DML 语句。

在 Bytebase 创建工单时，SQL 审核默认是非必须环节，即便工单中包含严重的 SQL 错误也可以正常递交工单。因此建议在安全策略中启用 “禁止提交包含错误告警的工单” 选项，防止不符合规范的 SQL 被递交。

SQL 审核​

Bytebase 内置了 111 条审核规则，其中部分可以在不同数据源之间共用，用户可以在 7 种数据源下配置它们。

Bytebase 在递交工单时可以手动对 SQL 进行检查，需要先 “运行检查”，再点击“检查结果图标”，方可查看检查结果，结果中会显示问题 SQL 所在行。

需要注意的是，Bytebase 在进行 SQL 检测时使用自身存储的元信息数据。若在产品之外执行了 DDL 语句，会导致其内部存储的元信息和真实数据库不一致，这种不一致会进一步影响 Bytebase 功能可用性，例如 SQL 在检测环节出现幻觉。

审批流程​

Bytebase 不支持外部流程引擎，但可以在内部定义审批流程。另外社区版不支持审批功能，需要购买企业版以解锁该功能。

工单执行​

Bytebase 提供了 立即、定时 两种工单执行方式，虽然没有明确提示，但在实际体验过程中发现 Bytebase 在执行工单 SQL 时会默认启用事务。当工单失败，整个变更会被回滚，由于 DDL 回滚操作需要数据库的支持，因此用户需要谨慎对待 DDL/DML 混合情况的工单。

Bytebase 不支持工单调试，并默认以事务方式执行。这意味着在我们设计的 “数据订正” 场景中，报错出现后，需要手动将原始工单进行拆分处理。

Bytebase 支持同一个工单的 SQL 同时在多个数据库作为执行目标，这个功能可以避免在多环境中递交多个工单。

小结​

亮点

• 工单模式和编辑器模式分工明确，更聚焦不同场景下的需求。
• 可视化生成 SQL 并提交工单，可以降低写错 SQL 的概率。
• 审核结果能精准定位问题 SQL 行，方便排查。
• 可以将多个数据库作为目标，简化多环境发布流程。

不足

• 产品会存储数据库元信息，当多种工具结合运维数据库时容易出现问题。
• 社区版本不支持审批功能，并且产品不支持对接钉钉、飞书等外部审批引擎。
• 工单不能调试，在数据订正场景中遇到错误后需要手动拆分工单。

Archery​

Archery 是开源免费的数据库审核工具，它对数据库的操作分为 SQL 查询 和 SQL 上线，并且包含一定的 数据库运维 能力。查询控制台只支持查询类语句，并且不支持查看数据库对象。所有 DDL、DML 语句都需要通过工单才能执行。

创建工单​

在 Archery 中工单递交允许 DDL/DML 混合使用。

SQL 审核​

在提交工单时，Archery 会清晰地提示 SQL 审核结果，并在支持的情况下会将查询计划及每条 SQL 语句集合在一起展示。若 SQL 命中高等级的 Error 规则，工单将无法递交；而命中 Warning 级规则时，系统会提示，但仍可继续递交工单。

受限于 goInception 的数据源支持，Archery 在 SQL 审核上仅支持 MySQL、Oracle 和 MongoDB，审核规则数量有限且不支持自定义配置。

审批流程​

Archery 无法接入外部流程引擎，但可以通过内部特有的方式定义基于权限组的简单审批流程，工单会在不同权限组之间流转，用户可以加入特定权限组参与审批。

工单执行​

Archery 在工单执行时提供“手动完成”选项，允许 DBA 自己处理工单，而不是完全依赖系统。对于大型数据库或复杂 SQL，这提供了更灵活的操作方式，能有效降低 DBMS 系统带来的不确定性。（该功能默认关闭，需要手动开启）

Archery 不能调试工单，也不具备事务模式，这意味着在处理强一致性的“数据订正”工单时，DBA 需要格外谨慎。在 “数据订正” 场景中，预先设置的报错场景触发后，Archery 需要创建新的工单来进行后续处理。

受限于 goInception 的数据源支持，对于 MySQL、Oracle、MongoDB 以外的数据源，Archery 会将工单内容当作一条语句交给数据库处理。

小结​

亮点

• 全部功能开源且免费，在遵守开源协议的前提下可以自由定制。
• 在工单中可以混合使用 DDL/DML，在变更发布需要初始化数据的时候会方便很多。
• SQL 审核结果中整合了查询计划，有助于识别潜在风险 SQL。

不足

• 受限于 goInception 组件，完整功能只支持 MySQL、Oracle 和 MongoDB。不能配置审核规则，也无法在控制台查看完整的规则列表。
• 工单无法调试，数据订正场景中出现错误时，只能创建新工单来继续处理剩余 SQL，操作不够顺畅。

Yearning​

在 Yearning 中，对数据库的操作都通过工单来实现，包括数据库的查询。

创建工单​

Yearning 默认限制每个 DDL 工单只能包含一条语句，需要在规则中将这个限制改为允许执行多条 DDL，否则实际使用中会比较麻烦。

Yearning 不支持 DDL/DML 语句混合，需要把它们拆成单独的工单分别执行。虽然在需要混合语句的情况下，这种限制会带来一定的不便，但在不同的场景下，拆分或者合并都有各自合理的依据。

需要格外注意的是，Yearning 工单递交时 “是否回滚” 这个选项的真正动作是生成回滚语句，而不是工单以事务方式执行在遇到错误后自动回滚事务。

SQL 审核​

Yearning 内置 46 条审核规则，其中大部分针对 DDL。目前不支持自定义规则。你可以通过创建 SQL 规范或在全局模式中启用已有规则。

启用 SQL 规则校验后，Yearning 在提交工单时会对 SQL 进行检查，只有通过审核的 SQL 才能提交。

在 Yearning 中，SQL 规范是绑定在数据源上的，如果同一个环境中多个数据源想使用相同的规则，就需要为每个数据源进行单独设置。

审批流程​

Yearning 不支持外部流程引擎，但可以通过内置流程引擎进行简单节点定义。

工单执行​

在“数据订正”场景中，Yearning 能在预设的报错语句处成功中止执行。但它不支持报错后的后续处理，如果是一批需要一对一更新的数据，遇到报错后只能新建工单来继续执行剩余 SQL。

小结​

亮点

• 上手门槛很低，基本不需要看文档，仅凭探索就可以上手操作，这一点非常棒。
• 产品非常聚焦，以工单驱动，没有多余复杂的功能，上手体验很轻松。

不足

• 相比其他几款产品，功能比较单一。
• 和其他产品一样，缺少工单调试功能，在数据订正出错时只能再建一个工单处理剩余部分。

总结​

这四款 SQL 审核工具在功能和体验上各有优缺点，总体来说：

• 服务支持：所有产品都有免费的社区版本可用，同时 CloudDM、Bytebase 背后有商业公司支撑，提供长期的更新与支持保障。
• 查询控制台：在查询控制台简单体验中，CloudDM、Bytebase 用户体验较为友好，可以很好适配开发环境和生产环境的实际需求。
• 数据源支持：除 Yearning 外所有产品都支持多种数据源。
• 开放性：Archery、Yearning、Bytebase 有开源版本可供选择，但功能限制较多，CloudDM 虽然不开源，但开放的功能是最全面的。
• 工单处理：CloudDM、Archery 允许在平台中标记工单已完成，DBA 可以根据工单内容，自己手动处理 SQL，这个设计给了 DBA 更大的灵活空间来应对一些特殊数据库。
• 回滚：CloudDM 可选是否开启事务；Bytebase 不能选择但默认为事务模式；Archery、Yearning 提供了生成逆向 SQL 的能力。

接下来，我还会继续体验测试其他 SQL 审核工具并分享出来，欢迎持续关注。

CloudDM 个人版是一款数据库数据管理客户端工具，支持 StarRocks 可视化建表，创建表时可选择分桶、配置数据模型。目前版本持续更新，在修改 StarRocks 表结构方面进一步优化，大幅提升 StarRocks 表结构设计效率。当前 CloudDM 支持：

• 可视化设计表
• 查看索引
• 筛选查看外部表

下面依次展示如何修改表结构、查看索引及区分外部表。

如何修改表结构​

使用 CloudDM，添加完 StarRocks 数据源之后，右键需要修改的表，点击 设计表。

修改表名​

在结构设计器中选择 基本信息，可直接修改表名。

修改字段​

在结构设计器中选择 列，然后选择一个存在的列，在右侧可以配置列的信息。

添加字段​

在结构设计器中选择 列，然后点击 增加 按钮新建一个列，在右侧可以配置列的信息。

修改列名​

CloudDM 个人版会识别 StarRocks 版本，对于 StarRocks 3.3 以上版本，允许修改列名。

如何查看索引​

右键需要查看索引的表，点击 设计表，即可查看索引信息。

区分外部表​

可单独筛选查看外部表。

总结​

本文我们介绍了如何使用 CloudDM 可视化设计 StarRocks 表，以及区分外部表。感兴趣的话，欢迎试用。

数据库数据管控平台在维护企业数据安全、数据库规范方面不可或缺，这一点毋庸置疑。但在实际使用数据库数据管理系统时，常常面临一个问题：工单审批流程集中在数据管理系统，然而并非所有员工都使用这个系统，导致审批困难、效率低下。当然，可以强制相关员工加入该系统，但这会增加时间及管理成本，并非最佳的解决方法。

实际上，大多数企业都有自己的协同办公系统，如钉钉、飞书等主流平台。这些平台集成了各类日常办公操作，如考勤、审批等，大大提升了办公效率。将企业 OA 系统接入数据库数据管理系统，既无需员工额外下载一个软件，又方便办公事务的集中管理，是简化工单审批流程的必行之道。

CloudDM 接入 OA 系统​

CloudDM 是一款全自研数据库数据管控平台，专注企业组织数据安全。为提升用户体验，CloudDM 最近支持接入钉钉、飞书和企业微信三款 OA 系统，实现了 OA 系统与 CloudDM 的无缝衔接，让工单审批流程更加简便高效。

通常，将 OA 系统接入数据库数据管理软件，会出现各种各样的问题，如：

• 网络出错，导致回调消息丢失，状态不同步。
• 调用接口失败，但是无法定位问题根源。
• 付费 API 过量使用，导致不必要的花费。

CloudDM 作为一款专为企业级用户设计的数据库数据管控软件，充分考虑了上述问题，并从用户的角度出发，设置了各种解决方案：

CloudDM 第三方审批流程特点​

CloudDM 的第三方审批流程有两大特点：一致性、便捷性。

一致性: 无论是通过 CloudDM 内置的审批流程还是整合其他 OA 系统，用户的操作体验都是统一的，几乎感觉不到不同审批系统间的差异，极大地提升了操作的流畅性和效率。

便捷性: 用户只需进行简单的配置，即可在任一平台上发起审批流程。CloudDM 与外部 OA 系统都将实时同步最新的审批状态。用户无需在不同系统间切换，在一个平台上即可掌握审批进度。

如何接入外部 OA 系统​

钉钉​

请参考 接入钉钉审批，完成相关配置。配置成功后，可实现 CloudDM 与钉钉的无缝衔接。

• 流程同步：CloudDM 与钉钉的审批页面实时同步审批流最新状态。

• 快速跳转：在 CloudDM 点击 钉钉审批即可直接跳转到钉钉对应的审批单，方便用户进行催单等操作。

飞书​

请参考 接入飞书审批，完成相关配置。配置成功后，可实现 CloudDM 与飞书的无缝衔接。

• 流程同步:CloudDM 与飞书的审批页面实时同步审批流最新状态。

• 快速跳转：在 CloudDM 点击 飞书审批即可直接跳转到飞书对应的审批单，方便用户进行催单等操作。

企业微信​

请参考 接入企业微信，完成相关配置。配置成功后，可实现 CloudDM 与企业微信的无缝衔接。

• 流程同步：CloudDM 与企业微信的审批页面实时同步审批流最新状态。

总结​

使用数据库数据管理工具 CloudDM，轻松衔接企业 OA 系统审批流程，节约时间及管理成本，显著提升团队的开发协作效率。如果您对此感兴趣，欢迎免费体验产品。

对于任何一款数据库管理工具，SQL 审核都占据重要地位，因为它直接关系到数据库的安全性和业务稳定性。通过 SQL 审核，可以有效发现并纠正 SQL 编写不当的问题，从而避免可能引发的数据库故障，如性能下降或数据泄露等严重后果‌。

CloudDM 是 ClouGence 公司推出的面向团队使用的数据库管理工具，支持云上、云下、多云多环境。目前支持 15 种数据源。未来更多数据源将逐步开放。对于 SQL 审核，CloudDM 提供了 59 个内置规则，并且 97% 以上规则同时适用于多种数据源。

CloudDM SQL 审核架构特点​

CloudDM 的 SQL 审核架构具有三大特点：统一性、开放性、自由性。

统一性，是指技术架构层面 CloudDM 会通过 SQL 解析器将 SQL 的特征抽取为特定的审核数据模型。无论何种数据源都遵循同一个原则并使用相同的审核数据模型。这样做有两个好处：

• 最大化减少技术实现差异，保证 SQL 审核功能的稳定性。
• 后续自定义规则时，降低学习门槛。

开放性，是指 CloudDM 中的所有规则，包括内置的众多规则，无一例外，全部通过其特有的 Rule Script 脚本来编写实现，并且所有内置规则的脚本全部 免费、开源。

CloudDM 不会藏有任何黑魔法。得益于 CloudDM 强大的 Rule Script 脚本引擎及统一的模型架构，所有规则都以高度透明的形式呈现出来。

自由性，是指用户可以利用 Rule Script 脚本自由编写符合自己需要的 SQL 规则，并将其应用到不同环境中。当内置规则不满足需求时，用户可以在此基础上自由改写。也正是由于所有内置规则的脚本全部 免费、开源，用户才可以自由扩展、定制和改进。

SQL 审核架构全新升级​

CloudDM 的 SQL 审核引擎架构在 Rule Script 脚本引擎 和 审核数据模型 方面都做出了重大升级：

脚本引擎​

上一代 SQL 审核架构的脚本引擎参考了 BASIC 语言并面向规则脚本开发而设计，脚本语言支持如下能力：

• 程序逻辑控制：多条语句顺序执行、IF 条件分支、ELSEIF 多条件分支。
• 丰富的表达式运算符：算数运算、比较运算、位运算、逻辑运算、匹配运算（CloudDM 特有）。
• 通用的类型系统：布尔、数值、字符串、时间、空值、集合、键值对。
• 表达式运算：一元、二元、三元 表达式计算，还可以通过括号进行表达式提权。
• 属性访问：可以通过 “.” 对多层对象进行属性访问，并且支持对数组下标、键值下标的访问。
• 可以完整地表示 JSON 格式数据。
• 支持隐式类型转换及通过 CAST 进行强制类型转换。
• 可以调用自定义函数并传递参数。

新一代 SQL 审核架构对 复杂编程场景 进行了更深入的支持，具体如下：

• 新增定义并使用 变量 的能力：通过变量可以在较为复杂的 SQL 检查程序中有效地提升代码结构。
• 丰富表达式运算：支持 自增(++)、自减(--) 运算。
• 增强表达式处理能力：对 空值 的情况做了更深入的兼容和处理。
• 重构类型跟踪机制，在新的机制下有效解决了对象访问中因类型跟踪异常导致的报错问题。

审核数据模型​

上一代 SQL 审核架构的审核数据模型中，SQL 语句和审核数据模型之间呈现 “一对一” 的关系：

• 从 SQL 解析器出发，一条 SQL 语句归属于一种类型。
• 一种类型的 SQL 对应一个数据模型。
• 在此基础上支持多种 SQL 语句，覆盖了 DDL、DML 中绝大部分情况。

新一代 SQL 审核架构中，SQL 语句和审核数据模型之间的 “一对一” 关系升级为 “一对多” 关系。

上一代模型架构在处理复杂语句时会出现特征抽取不够完整的问题。虽然丰富模型属性可以解决此类问题，但这会破坏 统一性 原则，并且增加学习门槛。例如 “INSERT ... SELECT” 语句，在上一代架构中将其识别为 INSERT。部分 SELECT 的特征只能作为更加离散的几个特征属性值。如果通过增加属性来解决 SELECT 语句特征提取的问题，势必会造成数据模型之间的混乱。

新架构中使用 “一对多” 关系，可以将这类语句有效地解释为多个结果，解决了部分特征无法抽取的问题，甚至面对更为复杂的查询也可轻松应对。

同时新架构对于不同数据源可进行差异化的处理。例如 MySQL 表上独特的 engine 属性只会出现在 MySQL 专用模型上，不会影响通用表模型。

全新架构在未来的优势​

新架构在模型结构化上更进一步，呈现更加清晰的数据结构。有了清晰的结构化数据将会带来诸多好处，例如：

• 未来可以有机会为用户提供 Rule Script 语言 IDE 环境，并提供更加智能的代码编写补全能力。
• 在未来基于模型的差异化可以使核心模型更加稳定，在产品迭代中使产品运行更加稳定。

使用 CloudDM SQL 审核​

1. 请参考官方文档 进行安装。
2. 添加好数据源之后，点击 查询设置 > 安全规范 > 新建规范，新建一个安全规范。

新建的规范默认会启用所有内置规则，用户可以根据需要自由选择和配置。

3. 点击 查询设置 > 查询配置，切换到环境选项卡。可以在启用安全规范时绑定新建的 安全规范。

4. 点击 数据查询，进入查询控制台，执行 SQL 语句，例如：“select * from tb_mysql_types limit 20;”。CloudDM 可以对其语句进行检测，并做出相应的提示。

5. 点击 查询设置 > 安全规范置 > 具体规范，在具体规范中搜索 “查询语句中的空条件” 可以找到这个规则。如果不需要这个规则，可以选择下面两种方式关闭这个规则。
   • 点击 禁用。
   • 设置规则属性中的 allow 配置为 true（没有关闭规则，只是规则上允许空条件）。

总结​

CloudDM 的 SQL 审核架构延续统一性、开放性、自由性的特点，在此基础上进行了重大技术升级，适配复杂编程场景及查询需求。如果您感觉本文有所收获，欢迎注册试用。

在数字化的今天，数据脱敏已成为保护数据隐私的重要手段。在《大数据时代，数据脱敏助力企业信息安全》一文中，我们介绍了数据脱敏的重要性，以及 CloudDM 数据脱敏的实现方式。本文将手把手教你如何使用 CloudDM 以多种方式实现数据脱敏。

数据脱敏方案概览​

在数据脱敏之前，用户首先需要明确，对于不同类型的敏感数据，采取不同的脱敏方案。CloudDM 支持对值和整行数据脱敏，满足用户不同的脱敏需求。

• 列脱敏：针对手机号等单个敏感数据，可整列脱敏。

• 数据识别脱敏：当数据符合某种条件时，脱敏该数据。

• 整行脱敏：针对安全级别较高的数据，可进行整行脱敏。

前提条件​

用户的角色需要拥有 安全规则/规范管理、查询配置管理 权限，若无该权限，可参考 授权管理 进行授权。

• 安全规则/规范管理：管理规则规范。
• 查询配置管理：环境绑定安全规范。

操作步骤​

选择脱敏规则​

1. 登录 CloudDM 平台。在上方导航栏点击 查询设置 > 安全规则，选择 脱敏规则 页签。
2. 寻找需要使用的规则，详细内容可点击 详情 查看。

创建安全规范​

1. 在上方导航栏点击 查询设置 > 安全规范。
2. 页面右上角点击 新建规范。

3. 输入规范名称后，点击 确认。

配置脱敏规则​

1. 选择一个安全规范，在操作栏点击 详情。

2. 启用对应的脱敏规则。

3. 配置规则。每个规则都可以设置其脱敏方式、参数以及生效范围。

   i. 点击操作栏中的 设置，配置脱敏方式：

   • 值：对于符合条件的数据，只脱敏该字段中的数据。

   • 整行：对于符合条件的数据，脱敏整行数据。

     ii. 在 值 一栏配置参数：设置脱敏规则参数，如下图则为设置需要脱敏的手机号号段。

     iii. 点击操作栏中的 范围。在范围配置页面右上角，点击 新建范围。生效范围支持多种匹配机制，并且能够精确到列级别。用户可以根据自己的业务需求，灵活配置规则的适用范围。

环境绑定规范​

1. 在上方导航栏点击 查询设置 > 查询配置
2. 选择 环境 页签。

3. 在 安全规范 一栏中点击按钮，并选择需要绑定的安全规范。

效果展示​

总结​

使用 CloudDM 数据库数据管理工具，轻松实现数据脱敏，为数据安全提供保障。如果感兴趣的话，欢迎免费试用。

大数据时代，数据已成为许多企业的重要资产与发展基石。然而，由于没有恰当的保护措施，企业内部员工泄漏数据的情况频频发生。有数据显示，在数据泄露事件中有 80% 为企业内部人员所为，快递、酒店、银行、房产中介、教育培训等各行各业无一幸免。这对数据库的使用管理提出了更高的要求。团队开发使用数据库时如何加强数据安全和隐私保护呢？数据脱敏提供了一种数据安全防护的新范式。

什么是数据脱敏​

数据脱敏（Data Masking）是一种安全技术，用于保护敏感数据免遭未经授权的访问和泄露。它通过隐藏、加密、替换或修改存储在数据库、文件或其他存储系统中的敏感信息，降低数据的敏感度。数据脱敏有助于在开发、测试、培训或数据分析等环境中使用真实数据的副本，而不暴露实际的个人信息或商业秘密。

业内常用的数据脱敏主要有两种实现方式：

• 指定列脱敏
• 数据识别脱敏

指定列脱敏 是指用户设置需要脱敏的列，对整列的数据进行脱敏。这种方式只需要配置需要数据脱敏的表和字段，配置较为简单，但需要对每张表逐一配置，当表数量较大时容易遗漏个别表。

数据识别脱敏 是指用户配置脱敏规则，对查询出的数据进行分析，针对符合规则的数据进行脱敏。根据脱敏规则识别数据，灵活性更高，省去了遗漏敏感数据的烦恼，但开发脱敏规则有一定难度，且算法稳定性和脱敏性能难以保证。

CloudDM 数据脱敏​

CloudDM 是一款全自研数据库数据管控平台，专注企业组织数据安全。针对大数据时代，数据隐私保护难的痛点问题，CloudDM 开发出了一套灵活、友好的数据脱敏解决方案——Rule Script 引擎。

CloudDM 自研的 Rule Script 引擎会自动识别出数据所在的库表、字段名称、数据内容等信息，通过 Rule Script 的 domain 对象进行校验，便可根据自身需求脱敏数据。

目前，Rule Script 内置了 5 种常用脱敏规则，用户无需花费大量时间开发规则脚本，即使是非专业开发人员也可以轻松实现 指定列脱敏 和 数据识别脱敏。脱敏时还可以根据具体需要决定是脱敏 整行数据 还是脱敏 单个值。此外，针对特殊的业务需求，用户还可以自己编写脱敏规则，配置脱敏方式，即可对需要脱敏的内容脱敏。

CloudDM 脱敏引擎的优势​

• 自动化：基于脱敏规则，对表中数据进行解析、判断与脱敏。全程自动化，无需人为操作干预，脱敏过程无感知。
• 可拓展性：用户可以根据自身业务需求识别敏感数据，并灵活配置脱敏规则。产品中内置了常见的脱敏规则，可满足大部分业务的脱敏需求。此外，用户可自定义脱敏规则。
• 灵活性：用户可根据数据的敏感程度及业务具体需求，选择整行数据脱敏或值脱敏。
• 可用性：数据库内原始敏感数据参与数据识别，仅在结果返回时才进行脱敏处理。

如何使用数据脱敏​

1. 梳理敏感数据：对于不同的业务内容、业务群体，敏感数据的定义会有所差别，因此，数据脱敏前，首先需要根据实际业务场景和安全维度，识别并梳理敏感数据。例如，在物流系统中，作为用户，敏感字段包括手机号、订单信息、收货地址等；在支付系统中，作为用户，敏感字段可能还涉支付订单、银行卡信息等。
2. 确定脱敏方式：不同的数据可以采用不同的脱敏方式。对于特定的敏感字段，如手机号、地址等字段，可采取指定列脱敏的方式。而针对一些敏感内容，如档案系统中的工作单位等信息，可采用数据识别脱敏的方式。此外，对于安全级别高的数据可以进行整行脱敏，即对整条数据进行脱敏，确保信息绝对安全。对于手机号等单个敏感数据可以采用值脱敏，通过隐藏关键部分来保护个人隐私。
3. 编写脱敏规则：明确上述信息后，可选择相应的内置脱敏规则，或根据需求自行编写脱敏规则，并配置生效。

自定义规则

启用规则

脱敏方式

生效范围

规则生效

总结​

使用 CloudDM 数据库数据管理工具，轻松实现数据脱敏，为数据安全提供保障。如果感兴趣的话，欢迎免费试用。

在团队协作开发过程中，开发人员想法、习惯各异，使用数据库时常常导致表结构不统一。如果长期使用不规范的表结构，可能会导致数据分析困难、执行速度下降、数据可视化困难等多种后果。‌这些问题普遍带有 滞后性、隐蔽性 的特点，解决这些问题时又容易产生更多连带风险。因此，规范化的表结构设计对于业务发展至关重要。

表结构不规范的影响​

数据分析困难​

表结构不规范，将会大大增加数据分析师处理数据时的难度。例如，相同含义字段名称不统一，又缺乏相应的元信息备注，导致后续分析数据时，还需要消耗大量时间梳理数据关系。

【场景 1】根据以下购物系统的订单表做数据分析：

CREATE TABLE  (
  ...
  cost DECIMAL(15, 2) ,
  ...
);

当我们尝试进行数据分析时，会发现 cost 字段没有设置禁止为空，也没有任何注释。开发人员在编写代码时，对于支付金额为 0 的订单可能会设置为 null 或 0。当我们发现一个订单的 cost 为 null 或者 0 时，可能是顾客使用优惠卷/红包后，支付金额为 0，或是赠品订单。而由于没有注释，在数据分析时难以对该字段的数据进行准确分析。

执行速度下降​

不合理的表结构设计可能导致数据库查询执行速度下降。例如，某些查询语句的执行计划看似相同，但由于表结构的不合理设计，实际执行效果相差很大，导致查询速度变慢，而这个问题往往在数据量变大之后才会凸显出来。

【场景 2】 以下 SaaS 系统的 user 表记录了用户信息，所有用户都关联到一个主账号上。

CREATE TABLE sales_data (
  id INT AUTO_INCREMENT PRIMARY KEY,
  ...
  parent_id varchar(64) 
  ...
);

在团队管理中，当查询当前团队的成员时，需要使用 parent_id 作为过滤条件去查询。因为 parent_id 没有设置索引，在查询时需要进行全表扫描，导致执行速度大幅下降。

数据可视化困难​

原本不为空的字段列，由于缺少表结构约束，导致意外录入脏数据，进而在数据可视化结果呈现上产生误导，甚至还会影响用户对数据的准确理解。‌最直接的问题就是 “空字符串” 和 “空值” 之间的差别难以有效界定。

【场景 3】根据以下记账软件的开支表分析收支情况。

CREATE TABLE expenditure (
  ...
  price  decimal not null,
  type ENUM('IN','OUT') NULL
  ...
);

当我们想对本年的收支情况进行分析时，因为该表 type 字段粒度太大，只能分析支出和收入两种类型，若想更加细致地分析在某些方面的支出，则无能为力了。

从上述例子中可以看出，数据库结构不规范，会对开发和数据分析形成重重阻碍。如果在创建表时就注意规范表结构，就可以有效避免上述情况的发生。

解决方案​

本文提供以下方案，供读者参考比较。

1. 关键字匹配：直接使用关键字对 DDL 语句进行判断。

• 优点：实现简单。
• 缺点：很容易通过各种方式绕开。

2. SQL 审核：普通用户执行 DDL 语句时需要提交给审核人员审核，通过后再由审核人员执行。

• 优点：审核人员可以浏览到所有 SQL，进行统一把控。
• 缺点：不同审核人员风格不同，并且审核人员一般是团队中的领导者，需要付出额外的精力。人工审核，也有概率漏过一些不符合标准的 DDL。

3. SQL 审核平台：通过 SQL 审核平台的校验规则，加上审核人员的最终把控，对将要执行的 SQL 进行高效监管，并且有历史记录查询、回滚 SQL 等多种功能满足团队需求。

• 优点：通过脚本校验 SQL，用户只需开启脚本便可检查 SQL 是否满足规范。审核人员只需要检查 SQL 是否符合业务需求即可。此外还有其他功能满足用户各种需求。
• 缺点：SQL 解析复杂，实现难度大。大部分平台只有常用规则，但无法自定义规则，无法满足用户个性化的需求。

推荐方案​

根据上述的方案比较，不难看出 SQL 审核平台 是比较便捷安全的方案，校验准确，省时省力，并且可以满足多样的需求。国产自研的数据库数据管控工具 CloudDM Team 便是一个合适的选择。

CloudDM Team 采用了全新的自研 Rule Script 引擎。通过 Rule Script 强大的编程能力，CloudDM Team 的所有内置规则全部实现了脚本化。此外，用户能够根据自己的需求自定义规则。

内置规则

自定义规则

规则生效

总结​

使用 CloudDM 这样的数据库数据管理工具，轻松实现良好的数据库结构规范，为团队开发协作提质增效。

面临的问题​

在开发过程中避免不了需要访问数据库数据，尤其在团队协作中对于数据库数据的访问会更加频繁。

通常团队成员在管理员或者 DBA 在准备好数据源之后，就可以凭借数据库的账号和密码访问数据库中的数据了。

也正是从这一刻开始，这个团队访问数据库中的数据时就会面临诸多问题，本文枚举其中几个比较典型的问题：

• 团队成员在设计数据库表结构容易产生随意性，导致数据库结构规范不统一。
• 容易忽略账号和权限的管控，导致数据库访问缺失权限控制。
• 数据库的变更的发布在需要多个团队成员通过流程化的方式相互协作，如果协作过程不顺畅则会降低团队效率。

问题的严重性​

如果这些问题没有被妥善处理好都会产生哪些影响呢？接下来我们举几个案例。

数据库结构规范不统一​

‌表结构不规范会导致多种后果，包括数据分析困难、执行速度下降、以及数据可视化困难。‌这些问题普遍带有 滞后性、隐蔽性 特点，当解决这些问题时又容易产生更多连带风险。

• 数据分析困难‌：表结构不规范可能导致数据分析师在处理数据时遇到困难。例如，相同含义字段名称不统一，又缺乏相应的元信息备注。导致后续分析数据时还需要消耗大量时间精力对数据关系进行梳理。
• 执行速度下降‌：不合理的表结构设计可能导致数据库查询执行速度下降。例如，某些查询语句的执行计划看似相同，但由于表结构的不合理设计，实际执行效果相差很大导致查询速度变慢。而这个问题往往在数据量变大之后才会凸显出来。
• 数据可视化困难‌：原本不为空的字段列由于表结构约束缺失导致脏数据被意外录入，进而在数据可视化结果呈现上产生误导，甚至还会影响用户对数据的准确理解。‌最直观的问题就是 “空字符串” 和 “空值” 之间的差别难以被有效界定。

综上所述，表结构不规范产生的不仅会增加数据分析的难度，降低数据库查询的执行速度，还会影响数据可视化的效果和质量。因此，规范化的表结构设计对于业务演进至关重要。

数据库访问缺失权限控制​

数据库访问缺失权限控制的危害会比较严重，主要体现在以下几个方面：

• 敏感数据泄露更显：由于数据库访问权限的缺失容易让未经授权的用户访问到敏感数据。如，用户个人信息、财务数据等‌。当这些具有高度敏感性的数据被泄漏出去后，会造成更大的灾害。例如，被不法分子用于诈骗。以及错失优质商业机会等。
• 数据篡改风险‌：攻击者可能通过越权访问修改数据库中的数据，通过篡改数据谋取私利或者对整个业务运行造成严重影响。如，修改账户余额，删库跑路等‌。
• 法律责任与声誉损害‌：由于缺乏权限控制导致用户敏感数据被泄露进而个人隐私被侵犯‌。企业可能临法律责任，同时企业的声誉也将受损。

综上所述，数据库访问缺失权限控制会带来更加严重安全风险和法律后果。所以团队中对于数据库数据的访问必须实施严格的访问控制和权限管理‌，以避免法律风险以及声誉影响。

协作过程不顺畅​

协作过程不顺畅最主要的影响是团队效率，主要包括：

• 系统稳定性受损‌：协作不畅可能导致数据库变更过程中出现错误或遗漏，进而影响系统的稳定性和可靠性，增加系统崩溃的风险‌。
• ‌数据安全性问题‌：协作不顺畅还可能引发数据安全性问题，如数据丢失或泄露，对组织造成重大损失‌。
• ‌团队资源浪费‌：不顺畅的协作可能导致不必要的重复工作或错误操作，浪费人力和时间资源‌。

综上所述，数据库变更协作不顺畅会对系统稳定性、‌数据安全性、团队资源利用等多方面造成不良影响。进而使团队的效率变得更加底下。

解决问题的手段​

这些问题在业内通常有着比较明确的解决思路，核心思想是通过团队化的工具将数据库的访问集中到统一平台上进行。并通过统一平台达成如下几个关键控制手段：

• 通过SQL规则校验，拒绝不合理的数据库结构变更。从而保证数据库规范。
• 集中权限控制，方便一目了然的管理和控制。
• 避免直接连接数据库，保护数据库账号。
• 对查询结果进行脱敏保护，从而避免避免数据隐私及法律风险。
• 通过工单流程提升团队协作效率。
• 通过企业统一认证，让团队的账号管理变得更加轻松和简单。

目前能够提供上述问题解决方案的产品有很多这里就不再展开。

CloudDM Team 作为全新的企业级数据库数据访问工具，在团队使用场景中做了更加细致和深入的思考。自然也包含上述问题。

规则校验​

使用脚本化方式实现 SQL 规则校验是一个比较常见的方法，常见的方案中有两种技术路线。

• 使用已有语言 Java、JavaScript、Lua、Groovy 作为规则引擎。
• 使用具有较高限制的自研 DSL 作为规则引擎。

使用已有语言通常会面临两个问题：

• 程序如何接入？
• 安全如何控制？

在采用通用编程语言作为规则引擎后，安全控制是最难以解决的。这是由于通用编程语言通常是面向更加广泛而又复杂的场景，需要提供更加灵活和底层的 API 作为保障。比如不受限制的访问网络、文件等资源。

如果采用通用编程语言作为引擎，虽然可以快速满足需求并节省开发成本。但需要在安全控制上做更加深入的控制，本文列出一些用于思考：

• 网络：通常 SQL 规则脚本中是用来承担逻辑判断并不需要网络通信，因此网络能力通常是不必要的。
• 文件：理由同上
• CPU/内存：这两类资源具有高度相似性，都是难以被控制。例如：规则脚本出现一个死循环，通常作为脚本宿主程序是无法主动干预的。
• 调动外部程序：这和网络、文件、比较相像。原则上规则脚本的执行是不能调用外部程序的。
• 其它技术组件导致的安全漏洞：常见的如 OGNL 表达式的越权访问。

如果采用使用场景更加明确的自研 DSL 作为规则引擎，通常不会出现上述问题。因此普遍情况下只要技术投入成本可以接受都会选择此类技术方案，其主要优点是在于可控性较高。

CloudDM Team 采用了全新的自研 Rule Script 引擎，并通过 Rule Script 强大的编程能力使得 CloudDM Team 的所有内置规则实现了全部脚本化。这包括 SQL 规则和脱敏规则。下面这张图向大家展示了基于 Rule Script 的在 CloudDM Team 中的样貌。

SQL 查询规则展示

查询规则展示

权限控制​

使用团队化的工具将数据库的访问集中到统一平台，天然的好处是可以避免直接连接数据库以保护数据库账号。而在权限控制方面，一个团队化的数据库访问工具必然会面临来自两个新维度上的要求：

• 功能上的权限控制
• 资源上的权限控制

在工程实践过程中权限系统的设计会受到诸多因素的影响，比较常见的权限控制模型和特点有：

• IBAC/ACL，基于身份的访问控制。核心思想是为资源制定一个 策略列表，当访问资源时通过策略列表来保护资源的访问。
• RBAC，基于角色的访问控制。模型核心定义了 用户、角色、权限 三个元素，在软件产品的功能控制中具有较为普遍的应用，它是一个静态模型。
• PBAC，基于策略的访问控制，相比较 RBAC 模型而言 PBAC 动态基于规则和策略动态确定访问权限。它属于动态模型。
• ABAC，基于属性的访问控制，模型重点在于对属性的策略化运用。角色、策略、身份 在 ABAC 模型中都是属性中的一种，ABAC 和 PBAC 某种程度上来看比较相似。而 ABAC 最大的弊端就是在于它的复杂性，在落地 ABAC 时某些情况下甚至需要借助 XACML 语言脚本来实现权限控制。

为了方便理解我们以 “资源是否具备某个权限的访问权限” 为典型内在需求。以 用户、角色、策略 为支点，对已知的权限模型做一个梳理可以做如下总结：

• 当选择 策略、权限、用户 三角关系作为权限访问控制三要素时，便是 ACL/IBAC 模型。
  • 当某个资源被访问只需要执行一遍策略规则即可得到权限，这便是最简单的 ACL（Access Control Lists）
  • 将用户/资源 进行 标识符 归类，在利用 ACL 对 标识 的用户资源进行访问控制，这便是 IBAC（Identity-Based Access Control）
• 使用 角色、用户、权限 三角关系作为权限访问控制三要素便是最常见的 RBAC 模型。
  • RBAC（Role-Based Access Control）是一种基于静态状态下的权限控制模型，同时也是用途最为广泛的权限控制模型。
  • RBAC 的运用非常考验角色的设计者，角色的粒度过细容易造成特权泛滥。粒度过粗又会导致拆分角色而造成角色爆炸。
• 使用 策略、权限 关系时便是 PBAC 模型，该模型的最大特点是着重基于策略的访问控制。
  • PBAC（Policy-Based Access Control）它通过定义策略来管理访问控制，这些策略可以根据需要进行定制。
  • 动态的访问控制是 PBAC 模型的核心关键，在实施 PBAC 时往往需要附带 审计 记录以方便事后查阅。
• ABAC（Attribute-Based Access Control） 它基于属性进行访问控制。在模型中访问决策不仅基于用户角色。
  • ABAC 访问控制机制根据主体属性、对象属性、环境参数、操作、策略对该请求进行授权验证，具有更高的灵活性。
  • ABAC 在一定程度上和 PBAC 具有相似性。
  • 在 ABAC 看来 RBAC 中的角色、IBAC 中的标识符都是一种属性。
  • 在 ABAC 模型体系中有很多实现或者标准比如：XACML、NGAC、LBAC。

在实际工程实践中可以选用的权限控制模型可能还会更多。具体如何选择需要基于客观因素来决定，不能一概而论那种模型更好。而在具体落地过程中往往参考上述标准模型也会产生更多的变种和新特性。

CloudDM Team 在实践权限控制的过程中采用了多种模型结合方式：

• 通过 RBAC 模型作为功能权限的访问控制。因此 CloudDM Team 可以定义角色、用户，并且可以为不同角色绑定权限。
• 通过 IBAC 对具体数据库资源进行访问控制。目前支持对实例级资源进行细粒度 ACL 控制。

工单流程​

在使用团队化数据库访问工具时工单流程是一个比较常见的场景，一个典型的用户场景是：

• 开发递交了 SQL 发布流程。
• DBA/管理员或各层级管理人员会执行流程审批。
• 在流程通过后完成最终 SQL 的执行。

在专业的领域中一般由 OA 系统可以完成上述动作。而在 OA 出现之前，办公室解决流程化问题往往是填写各种申请表。然后在各级领导/负责人、部门之间流转这些申请单。对于数据库变更的审核往往更加难以管理通常交给更加专业的 DBA 负责数据库的变更操作。

一个 OA 系统面临的主要问题是如何方便的定义表单以及流转表单。所以在技术上 OA 系统通常包括如下核心技术：

• 表单设计器
• 工作流引擎
• 用户/组织管理

表单系统主要解决的问题是表单的设计以及表单数据的存储/提取。在早年一个很好的可视化 HTML 设计器可以解决大部分问题，而如今已经有更多可用的方案可以被选择。

• 表单系统的最大难度是在于提供可供交互的类 HTML 设计器，并允许终端用户自由的设计表单的样式。这些用户往往对于计算机原理了解并不深入。
• 早年比较常见的方案是基于 Eclipse 开发一个工作流设计平台，其核心原理是对 Eclipse Web Developer Tools 的二次开发提供表单设计器。
• OA 系统将表单设计器产生的数据进行存储，在需要时按照设计器设计的样式重新展现并填充具体数据。

流程引擎，解决的主要问题是提供一个统一的模式让企业可以设计自己的流程。

• 在流程设计中比较典型的场景有：加签、会签、顺序流程、子流程、并行流程等。
• 在工作流领域也存在很多成熟的解决方案如：Activiti、Flowable、jBPM 本文不在详细展开。

CloudDM Team 在工单流程的设计上简化了技术负担，其核心只关注审批的 发起 和审批结果。让外部 OA 系统以更加专业的角度来负责工单流转工作，这样做可以获得以下好处：

• 专业的事情专业系统来负责，减轻技术负担、提升整个系统稳定性。
• 可以接入用户已有 OA 系统，从而和用户的 IT 系统结合更加紧密。

总结

本文提出了团队使用数据库面临的问题以及问题的后果，介绍了行业中解决问题的常用手段，及 CloudDM Team 在众多产品中的独特优势。如果您感觉本文有所收获，欢迎注册试用。