安全管理 #

用户管理 #

SphereEx-DBPlusEngine 提供多种用户，以供不同平台及场景使用。

角色管理 #

SphereEx-DBPlusEngine 提供多种角色，以供不同平台及场景使用。

认证登录 #

下面说明特指 SphereEx-DBPlusEngine 用户。

基本概念 #

SphereEx-DBPlusEngine 拥有严格的登录认证机制，只有经过身份认证的用户才可以成功建立连接。为保障用户数据和分布式配置信息的安全，SphereEx-DBPlusEngine 提供了用户认证的功能，且该功能不可关闭，否则，未经认证的客户端连接将被拒绝。当前，SphereEx-DBPlusEngine 已经支持了多种用户认证协议，包括：

• MySQL 客户端：mysql_native_password、mysql_clear_password
• PostgreSQL 客户端：MD5、password
• openGauss 客户端：scram‑sha‑256、MD5

同时，为方便企业用户进行统一身份管理，SphereEx-DBPlusEngine 也提供了 LDAP（Lightweight Directory Access Protocol）认证方式，LDAP 认证已支持 MySQL 和 PostgreSQL 客户端。实际上，用户在使用 SphereEx-DBPlusEngine 时不需要考虑选择何种协议，协议的协商过程是在 SphereEx-DBPlusEngine 与客户端之间自动完成的。当使用 MySQL 客户端时，默认使用 mysql_native_password。仅当用户需要进行 LDAP 认证时，SphereEx-DBPlusEngine 会要求客户端切换为 mysql_clear_password 协议进行通信。当使用 PostgreSQL 客户端时，默认使用 MD5。仅当用户需要进行 LDAP 认证时，SphereEx-DBPlusEngine 会要求客户端切换为 password 协议进行通信。

密码认证 #

默认情况下，SphereEx-DBPlusEngine 使用密码认证方式，登录用户需提供正确的用户名和密码。

特别的，由于 Proxy 支持多种数据库协议（如 MySQL、PostgreSQL 等），当用户应用不同的数据库客户端时，Proxy 能够自动适配密码通信协议，在复杂场景下为用户提供一致的安全体验。

主机限制 #

除了提供密码认证登录外，还可以为 SphereEx-DBPlusEngine 的用户限制登录主机地址，以提高安全等级。如：

‑ !AUTHORITY
users:
  ‑ user: root@127.0.0.1
    password: root

以上配置指定了 root 用户只能从 127.0.0.1 这个地址访问 Proxy，从其他地址登录时，即使密码正确也将被拒绝。

LDAP 认证 #

为方便企业用户进行统一认证管理，SphereEx-DBPlusEngine 也提供了 LDAP（Lightweight Directory Access Protocol）认证方式，LDAP 认证现已支持 MySQL 和 PostgreSQL 客户端。同时，SphereEx-DBPlusEngine 允许用户以非常灵活的方式来接入 LDAP，例如：

• 可以配置为默认使用 LDAP，这样所有用户都通过 LDAP 认证；
• 支持为用户配置 auth 属性，指定用户使用密码或 LDAP 认证，各个用户可以使用不同方式；
• 各个用户可以使用不同的 LDAP 认证器，即对接不同的 LDAP 服务；
• 支持为用户指定 DN 模板，满足复杂场景的需要；
• 支持 LDAPS 协议，可进一步提升安全等级。

权限管理 #

定义 #

SphereEx-DBPlusEngine 为数据库提供了分布式协作的能力，同时将一部分数据库特性抽象到了上层，进行统一管理，以降低用户的使用难度，同时提高运行效率。权限控制，就是其中的一项能力。将权限控制交由 SphereEx-DBPlusEngine 统一管理，至少有以下几方面的好处：‑避免接入异构资源时为用户带来困惑，无需担心该使用哪种方言进行管理；‑使用逻辑库和逻辑表进行授权管理，与下层真实库表隔离，更便于用户理解；‑避免数据库资源变化导致的授权信息不一致，不会产生信息同步的消耗。于是，为了让权限控制更易用，SphereEx-DBPlusEngine 团队倾心打造了全新的权限控制体系。

概念 #

• 用户

用户（user）是 SphereEx-DBPlusEngine 的使用者。

• 初始用户

初始用户是指在 SphereEx-DBPlusEngine 启动前，通过配置文件设定的用户。

• 普通用户

与初始用户相对应，普通用户是在 SphereEx-DBPlusEngine 运行过程中被动态创建的用户。

• 角色

角色（role），是被命名的、一定数量的权限的集合。以角色为基础的权限控制，能够简化对用户的权限管理过程。

• 权限

权限（privilege）是指用户对特定目标执行操作的权力。

• DistSQL

DistSQL（Distributed SQL）是 DBPlusEngine 特有的操作语言，在 DBPlusEngine 将权限控制能力进行抽象统一之后，提供了专有的 DistSQL 语法，方便管理员对用户和权限的管理维护。

• DML

数据操纵语言，包含 INSERT、SELECT、UPDATE 和 DELETE 语句。

• DDL

数据定义语言，包含 CREATE、ALTER、DROP 和 TRUNCATE 语句。

对系统影响 #

• 细粒度权限管理

可精确控制授予每个用户的库级、表级、列级的操作权限。

• 统一的交互语言

使用 SphereEx-DBPlusEngine 特有的 DistSQL 进行用户和权限管理，无论存储节点选择 MySQL、PostgreSQL、OpenGauss 还是 Oracle，都可以进行无差别权限控制。

• 权限管控实时生效

对用户或授权的变更实时生效，无需重启 SphereEx-DBPlusEngine 。

• 授权信息在集群中自动同步

变更用户和授权信息，集群中其他计算节点也能实时收到该变化，完成用户的授权更新，管理员无需在多个节点进行重复操作，方便集群管理

原理 #

• 权限存储

在 SphereEx-DBPlusEngine 的体系架构中，计算节点（DBPlusEngine‑Proxy）是无状态的，并不提供数据存储能力，因此，用户账户及授权信息都将存储在治理中心。同时，借助治理中心的能力，能够将信息实时分发给集群中的多个计算节点，这将大大减少用户在使用集群时的维护成本，提供管理效率。另一方面，由于提供了统一的权限管理机制，对于接收到的原生 DCL 语句，SphereEx-DBPlusEngine 不再转发到下层存储节点，而将会给出不支持的提示信息。用户须使用 SphereEx-DBPlusEngine 提供的 DistSQL 进行账户和授权的管理。

• 权限提供者

SphereEx-DBPlusEngine 使用可插拔架构进行功能的组织和扩展。其中，权限引擎为用户提供了多种不同的权限提供者

说明： 权限提供者由管理员在 SphereEx-DBPlusEngine 启动前指定。

• 鉴权流程

在 SphereEx-DBPlusEngine 中，权限按照自顶向下的顺序逐级校验，当用户拥有上层权限时，不再向下进行检查，以保证鉴权效率。 例如：

• 若用户拥有全局的 SELECT 权限，则在进行 SELECT 操作时，无需检查该用户是否拥有目标库表的 SELECT 授权；
• 若用户拥有库级别的 INSERT 权限，则在进行 INSERT 操作时，无需检查该用户是否拥有目标表的 INSERT 授权。 以此类推。

例如：

• 若用户拥有全局的 SELECT 权限，则在进行 SELECT操作时，无需检查该用户是否拥有目标库表的 SELECT 授权；
• 若用户拥有库级别的 INSERT 权限，则在进行 INSERT 操作时，无需检查该用户是否拥有目标表的 INSERT 授权。以此类推。

权限分级 #

全局权限 #

全局权限，是指用户获得的授权不区分目标对象，用户可对任意的逻辑库、逻辑表执行对应操作。 例如，以下指令将全局的 INSERT、SELECT、UPDATE 和 DELETE 权限赋予用户‘sharding’@‘%’，则该用户能够对任何逻辑库中的表执行 DML 操作。以下两个语句等效：

GRANT DIST INSERT,SELECT,UPDATE,DELETE TO 'sharding'@'%';
GRANT DIST INSERT,SELECT,UPDATE,DELETE TO sharding;

需要注意的是，全局权限包含两项特殊权限：CREATE_USER 和 SUPER。

其中，获得 CREATE_USER 授权的用户，可执行以下操作：

SUPER 代表的是数据库系统的最高权限，默认情况下，SphereEx-DBPlusEngine 启动前配置的初始用户拥有 SUPER 授权。

对象权限 #

对象权限，指授予的权限受作用范围限制，用户不可在授权范围之外执行相应操作。

对象权限的作用范围可以是所有逻辑库，也可以指定单个或多个逻辑库及库中的表和列。

例如，以下指令将逻辑库 sharding_db 中 t_order 表的所有权限授予用户 ‘sharding’@‘%’，此后该用户可以对 sharding_db.t_order 表执行操作。但若无额外授权，该用户不能操作 sharding_db 中的其它表。

sql> GRANT DIST ALL ON sharding_db.t_order TO sharding;

DistSQL清单（权限相关） #

完整的权限管理 DistSQL 清单请参考DistSQL 用户管理

说明：

• 为用户和角色「授权/撤销授权」的语法一致，将 ‘user’@‘host’ 替换为 role 即可；
• REVOKE DIST ALL 会同时撤销赋予给用户的所有角色。

使用案例：权限配置初始化 #

• 适用场景

权限引擎根据 global.yaml 中配置的权限规则来执行系统的初始化工作。

• 数据规划
  • users 用于指定初始用户，如这里将 root@% 设置为初始用户；
  • privilege 中的 type 用于指定选用的服务提供者， 如这里配置了企业级的权限提供者 Enterprise。
• 注意事项
  • 初始用户默认具备 SUPER 权限。
  • 若通过 DistSQL 对初始用户显示赋予非 SUPER 权限，则该初始用户将失去 SUPER 授权。
  • 需再次赋予 SUPER 授权，需要使用 GRANT DIST SUPER TO user 语句。
• 操作步骤

配置格式如下：

authority:
  users:
    - user: root@%
      password: root
    - user: sharding
      password: sharding
  privilege:
    type: Enterprise

使用案例：不使用角色管理 #

• 适用场景

某应用系统为开发和运维人员提供了不同级别的 SphereEx-DBPlusEngine 账户，其中开发人员仅可以执行 DML 指令，运维人员则可以执行 DML + DDL 指令，另有一个 root 用户作为最高管理者。

• 数据规划

全部账号需求如下：

其中，root 用户为初始用户。

• 操作步骤

1. 依次创建各个开发和运维用户，密码根据实际情况进行设置。

‑‑ 不限制登录主机，省略 host 配置

sql> CREATE DIST USER zhangsan IDENTIFIED BY '123456';
sql> CREATE DIST USER wangwu IDENTIFIED BY '123456';
sql> CREATE DIST USER develop_test IDENTIFIED BY '123456';
sql> CREATE DIST USER operator_1 IDENTIFIED BY '123456';
sql> CREATE DIST USER operator_2 IDENTIFIED BY '123456';

2. 为开发用户授权。

sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE TO zhangsan;
sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE TO wangwu;
sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE TO develop_test;

3. 为运维用户授权。

sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE,CREATE,ALTER,DROP,TRUNCATE TO operator_1;
sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE,CREATE,ALTER,DROP,TRUNCATE TO operator_2;

4. 若需新增开发用户，则重复以下两步。

• 新建用户

sql> CREATE DIST USER new_developer IDENTIFIED BY '123456';

• 授权

sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE TO new_developer;

5. 若需新增运维用户，则重复以下两步。

• 新建用户

sql> CREATE DIST USER new_operator IDENTIFIED BY '123456';

• 授权

sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE,CREATE,ALTER,DROP,TRUNCATE TO new_operator;

使用案例：使用角色管理 #

• 适用场景

某应用系统为开发和运维人员提供了不同级别的 SphereEx-DBPlusEngine 账户，其中开发人员仅可以执行 DML 指令，运维人员则可以执行 DML + DDL 指令，另有一个 root 用户作为最高管理者。

• 数据规划

全部账号需求如下：

• 操作步骤

1. 依次创建各个开发和运维用户，密码根据实际情况进行设置。

不限制登录主机，省略 host 配置

sql> CREATE DIST USER zhangsan IDENTIFIED BY '123456';
sql> CREATE DIST USER wangwu IDENTIFIED BY '123456';
sql> CREATE DIST USER develop_test IDENTIFIED BY '123456';
sql> CREATE DIST USER operator_1 IDENTIFIED BY '123456';
sql> CREATE DIST USER operator_2 IDENTIFIED BY '123456';

2. 创建两个角色，develop_dml 和 operate_ddl。

sql> CREATE DIST ROLE develop_dml;
sql> CREATE DIST ROLE operate_ddl;

3. 为角色授权。

sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE TO develop_dml;
sql> GRANT DIST INSERT,SELECT,UPDATE,DELETE,CREATE,ALTER,DROP,TRUNCATE TO operate_ddl;

4. 将开发角色赋予用户，这样用户就具有了角色所拥有的权限。

sql> GRANT DIST develop_dml TO zhangsan;
sql> GRANT DIST develop_dml TO wangwu;
sql> GRANT DIST develop_dml TO develop_test;

5. 为运维角色赋予用户。

sql> GRANT DIST operate_ddl TO operator_1;
sql> GRANT DIST operate_ddl TO operator_2;

6. 若需新增开发用户，则重复以下两步。

‑‑ 新建用户

sql> CREATE DIST USER new_developer IDENTIFIED BY '123456';

‑‑ 授权

sql> GRANT DIST develop_dml TO new_developer;

7. 若需新增运维用户，则重复以下两步。

‑‑ 新建用户

sql> CREATE DIST USER new_operator IDENTIFIED BY '123456';

‑‑ 授权

sql> GRANT DIST operate_ddl TO new_operator;

DistSQL 权限控制 #

DistSQL，作为 SphereEx-DBPlusEngine 支持的一种扩展 SQL。SphereEx-DBPlusEngine 也提供对应的权限控制。

权限分级 #

DistSQL 权限的分级与标准数据库权限类似，同样拥有全局权限、库级对象权限、表级对象权限。目前 DistSQL 不存在列级操作，因此权限分级中也没有列级权限。DistSQL 权限的授权项相较于标准的数据库权限种类更多。DistSQL 权限授权项由操作 + 操作对象组成，其组合方式如下。

除了上述表格中展示的授权项，还提供 RDL、RQL、RAL 以及 RUL 语法类型作为授权项。

全局权限 #

全局权限，是指用户获得的授权不区分目标对象，用户可对任意的逻辑库、逻辑表执行对应操作。

例如，以下指令将全局的 SHOW SHARDING 权限赋予用户 ‘sharding’@‘%’，则该用户能够对任何逻辑库中的分片规则执行 SHOW 操作。

sql> GRANT DIST SHOW SHARDING TO 'sharding'@'%';

另外，因为 DistSQL 授权项较多，对于一次授予多个授权项时，可以使用语法类型作为授权项。例如，以下指令将所有操作对象全局的 SHOW 权限赋予用户 ‘sharding’@‘%’，则该用户能够对任何逻辑库中的任何操作对象执行 SHOW 操作。

sql> GRANT DIST RQL SHARDING TO 'sharding'@'%';

对象权限 #

对象权限，指授予的权限受作用范围限制，用户不可在授权范围之外执行相应操作。对象权限的作用范围可以是所有逻辑库，也可以指定单个或多个逻辑库及库中的表。例如，以下指令将逻辑库 sharding_db 中分片规则 t_order 的创建和修改权限授予用户‘sharding’@‘%’，此后该用户可以对 sharding_db.t_order 规则执行创建和修改操作。但若无额外授权，该用户不能操作 sharding_db 中的其它规则。

sql> GRANT DIST CREATE SHARDING, ALTER SHARDING ON sharding_db.t_order TO 'sharding'@'%';

管理安全 #

在 SphereEx-DBPlusEngine 中，用户能够通过 DistSQL 执行多种维度的管理操作，包括但不限于：

• Proxy 配置管理，如事务类型、日志开关等；
• 逻辑库管理；
• 存储资源管理；
• 数据分片规则管理；
• 读写分离规则管理；
• 加解密规则管理；
• 数据库发现规则管理；
• 影子库规则管理；
• 元数据查看等。

由于 DistSQL 功能强大，数据库管理员可为不同用户分配不同的 DistSQL 权限，以实现 SphereEx-DBPlusEngine 管理安全。例如：

sql> GRANT DIST SHOW SHARDING ON sharding_db.* TO 'sharding'@'%';

通过以上授权语句，将逻辑库 sharding_db 中的“查看分片规则”的权限授予 ‘sharding@%’，则该用户能够在 sharding_db 中执行 SHOW SHARDING TABLE RULES 、SHOW SHARDING BINDING TABLE RULES 等 SHARDING 相关的 RQL，但无法执行其他未授权的 DistSQL。

例如‘sharding@%’用户此时执行 CREATE SHARDING TABLE RULE 语句，将会得到异常提示：

Access denied for operation [CREATE] of subject sharding_db.table_name:SHARDING.]

若要向 ‘sharding@%’ 用户授予所有 DistSQL 权限，可以通过如下方式：

sql> GRANT DIST RDL,RQL,RAL ON sharding_db.* TO 'sharding'@'%';

访问安全 #

数据访问安全，是企业级数据库必备的能力之一。SphereEx-DBPlusEngine 作为分布式数据库集群的入口，为用户提供了全面的访问控制能力。与传统集中式数据库或单协议数据库不同，SphereEx-DBPlusEngine 拥有管理多类型底层数据库和对接多协议客户端的能力，在进行访问控制时就会面临诸多挑战：

• 不同数据库类型拥有不同的逻辑概念；
• 不同数据库类型使用不同的方言；
• 不同数据库提供了不同的存储结构。

为了给用户提供一致的安全体验，SphereEx-DBPlusEngine 屏蔽了底层数据库的差异，提供统一易用的安全体系，具有如下特点：

• 细粒度权限管理：支持库级、表级、列级访问控制；
• 统一的交互语言：使用 DistSQL 进行用户和权限的管理，适用于不同的数据库协议；
• 存储独立：权限的信息保存在 DBPlusEngine 的治理中心，不依赖于底层数据库；
• 实时生效：对用户和权限的管控实时生效，无需重启或手动刷新。

例如，若管理员向 ‘sharding@%’ 授予 sharding_db 中 t_order 表的查询和写入权限，可以执行这样的 DistSQL：

sql> GRANT DIST SELECT, INSERT ON sharding_db.t_order TO ‘sharding’@'%';

操作完成之后，‘sharding@%’ 用户立即获得相应授权。若用户执行未授权的操作，如 DELETE，将会收到拒绝提示：

sql> DELETE FROM sharding_db.t_order WHERE id = 1;
Access denied for operation [DELETE] of subject sharding_db.t_order]

• SSL说明

目前 SphereEx-DBPlusEngine 尚不支持 SSL 的访问方式。如果后端数据库启用 SSL 访问，可在 SphereEx-DBPlusEngine 中配置后端使用 SSL 方式连接。

存储安全 #

近年来，数据安全和隐私保护越来越受到重视。而数据加密是有效地解决上述问题的手段之一。

• 磁盘加密

磁盘采用的块级别加密技术，例如 AWS 的 EBS，阿里云的 ECS 等都支持磁盘加密。这种加密最大的好处在于，它对操作系统是透明的。性能在加密后较加密前有所降低，根据上层应用的不同性能下降幅度各异。

• 文件加密

通过堆叠在其它文件系统之上（如 Ext2, Ext3, ReiserFS, JFS 等），为应用程序提供透明、动态、高效和安全的加密功能。典型的是用于加密指定的目录。需要关注的是这种加密方式可能会产生较大的性能损失。

• 数据库加密-TDE

透明数据加密 TDE，是数据库提供的一种加密技术，即对数据文件执行实时 I/O 加密和解密。数据在写入磁盘之前进行加密，从磁盘读入内存时进行解密。TDE 不会增加数据文件的大小，开发人员无需更改任何应用程序。其对应密钥管理也是由数据库提供的API或组件实现，应用透明。在某些场景下磁盘或系统无法对用户开放（如云环境）的条件下，这种方式就比较适合。

• 数据库加密-三方加固

数据库加密还有种方式是采用对数据库进行三方加固的方式，即将第三方专业数据库加密厂商的产品内置在数据库之中，提供透明数据加密能力。所谓透明是指，用户应用系统不需要做改造即可使用，且具有权限的用户看到的是明文数据，完全无感。此外，还可以增强原有数据库的安全能力，如提供三权分立、脱敏展示等。

• 应用层加密

应用层加密，可以说是一种终极方案，其可保证在数据到达数据库之前，就已经做了数据加密，可实时保护用户敏感数据。这里关键需要提供应用透明性，保证应用无需改造或仅需少量改造。这种方式完全由用户自己控制，无需信任任何三方厂商提供的数据安全保障，得到充分的自由度和灵活性。例如可以跨多数据库提供统一安全加密策略等。

SphereEx-DBPlusEngine 提供的数据加密能力是属于应用层加密。但与传统的应用加密不同，SphereEx-DBPlusEngine 提供无感的加密能力。对于前端用户而言，只需考虑对数据库的访问，无需关注加密细节。具体参见数据加密

使用安全 #

脱敏使用 #

随着《网络安全法》的颁布施行，对个人隐私数据的保护已经上升到法律层面。传统的应用系统普遍缺少对个人隐私数据的保护措施。数据脱敏，可实现在不需要对生产数据库中的数据进行任何改变的情况下，依据用户定义的脱敏规则，对生产数据库返回的数据进行专门的加密、遮盖和替换，确保生产环境的敏感数据能够得到保护。在真实业务场景中，相关业务开发团队则往往需要根据脱敏需求，自行实现并维护一套脱敏功能，而脱敏功能往往是耦合在各个业务逻辑中，不同的业务系统难以复用，而当脱敏场景发生改变时，自行维护的脱敏功能往往又面临着重构或修改的风险。根据业界对脱敏的需求及业务改造痛点，提供了一套完整、安全、透明化、低改造成本的数据脱敏整合解决方案，是 SphereEx-DBPlusEngine 数据脱敏模块的主要设计目标。

实现原理：通过对用户查询的 SQL 进行解析，并依据用户提供的脱敏规则对 SQL 执行结果进行装饰，从而实现对原文数据进行脱敏。具体参见数据脱敏

安全审计 #

全量审计日志，是指开启该功能后，系统将记录所有执行的 SQL 语句，并包含语句对应的数据库、用户、访问地址，访问耗时等信息，便于企业进行审计操作。

参数解释 #

general_query_log：全量审计日志仅有一个参数，值为 true 时启用全量日志，值为 false 时停用该功能。

前提条件 #

与“慢查询日志”功能相似，全量审计日志的实现也是基于 Agent 的，因此该功能仅适用于 SphereEx-DBPlusEngine 且启用 Agent 的场景。

配置示例 #

全量审计日志是基于 Agent 的功能，因此以下配置位于 agent.yaml 中：

plugins:
 Logging:
  props:
   # Whether to enable general query log.
   general_query_log: false
   # Whether to enable slow query log.
   #slow_query_log: true
   # Long query threshold, in 

其中，general_query_log 配置为 false，表示不启用全量日志。当需要启用全量日志时，将 general_query_log 配置 true，并重新启动 SphereEx-DBPlusEngine。

全量审计日志格式 #

db: {database} user: {user} host: {host} query_time: {query time} {sql}

• db：数据库名称；
• user：当前连接中使用的用户名称；
• host：客户端访问地址；
• query_time：SQL 执行耗时，单位为 ms；
• sql：客户端发送的 SQL 语句。

全量审计日志示例 #

[INFO ] 2022-07-01 00:00:00.000 [ShardingSphere-Command-0] GENERAL-QUERY - db: sharding_db user: root host: 127.0.0.1 query_time: 145
CREATE TABLE `t_order` (
  `order_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `status` varchar(50) COLLATE utf8mb4_bin DEFAULT NULL,
  PRIMARY KEY (`order_id`)
)