分享：如何给 DBA 减负？

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

本文来自OceanBase社区分享，仅限交流探讨。原作者肖杨，OceanBase 软件开发工程师。

---

研发、数据分析师及运维内部人员有数据查询、数据订正等需求，若无管控平台，只能通过授予账号的形式，来授权这些用户直接访问数据库，一般会按类型建几个不同级别权限的账号给对应的同学使用，这会导致以下问题：

1. 一个账号对应的使用人很多，无法精准定位请求人，同时只能依靠账号权限来限制用户行为，无法对请求进行流程上（经审批人审核）的约束；

2. 同时受访问的数据库的稳定性无法得到保障，若有访问权限的用户执行了高消耗的 SQL ，很可能导致数据被打挂；

3. 账号权限调整繁琐，若要限制某个用户访问，需要修改用户密码，然后再知会除限制人外的其它人修改信息。

从这些问题中我们发现，在企业级开发场景中，需要将数据库的访问权限纳入管控，以免造成数据泄露、丢失、滥用等问题。这时就需要一款具备权限管理和安全协同能力的数据库开发工具，帮助 DBA 在完成管控任务的同时，尽可能降低运维成本。

OceanBase 开发者中心（ODC）作为 OceanBase 数据库官方配套的开发平台，自 V3.2.0 版本引入权限模型以来，提供了公共资源的全生命周期权限管理能力，现已迭代至 V4.1.0 版本。为了帮助大家更顺畅地使用 ODC，以及遇到问题时能够更快速地解决，本文将以数据库的访问控制为例，分享 ODC 数据库访问权限管理背后的设计思考和基本原理，解答上述问题。

案例分析：如何给 DBA 减负？

首先来看一个真实案例：某互联网公司电商业务的开发环境共有 OceanBase 数据库 250 套，需要分配给 3 个业务部门使用，要求每个部门的数据库相互之间不可见。公司电商业务线拥有约 200 名研发人员，但仅有 1 个由 3 人组成的 DBA 团队，并且处于业务上升期，频繁有新员工加入和部门间人事调动。

在大多数企业级场景下，研发人员数量远大于 DBA，如何给 DBA 减负是个亟需解决的问题：

问题一： 黑屏操作很繁琐，为了保证数据库安全可控，不能将连接账密直接给研发同学，该如何管理呢？

问题二： 研发人员太多管不过来，不如让各部门 Leader 自己管，如何优雅地下放权限？全公司用一套系统，怎么保证部门间的资源隔离？

问题三： 新员工加入到研发团队，每次都要手动给他/她授权，如何解放 DBA 的双手？

ODC 如何解决这些问题

我们来看使用 ODC 怎么解决上述问题，只需以下关键三点：

资源权限管理

ODC 提供了公共资源权限管理功能。 具备管理权限的用户登录 ODC 后，可以进入公共资源管控台后，进行数据库资源权限的分配和管控。

例如针对上述客户案例，可以进行如下配置：新建角色 department_A_RD 并为其分配生产库 A 的只读权限和研发库 A 的读写权限，然后将角色 department_A_RD 授予隶属部门 A 的研发人员。那么，部门 A 的研发人员登录 ODC 后将自动获得相应数据库的访问权限。

灵活配置权限

ODC 提供两种授权方式供用户灵活选择：一是通过创建角色，配置角色拥有的权限，然后将角色授予用户，来让用户获得角色拥有的相应权限；二是直接以公共连接为单位，管理用户的访问权限。

通过角色间接管理用户权限的方法适用于批量管理的场景。例如，需要让部门 A 的所有研发人员都拥有生产库 A 的只读权限，就可以通过创建角色配置生产库 A 的只读访问权限，并将该角色授予部门 A 的研发人员来实现。对于一些定制化场景，例如需要给部门 A 中的特定几名员工授予 高危数据库 的访问权限，就可以直接在 ODC 管控台中，将这几名员工的账号添加到可访问高危数据库的用户列表中，而不需要额外创建角色。

ODC V4.1.0 版本还支持为角色配置资源管理权限和系统操作权限。通过该功能，可以将部分低危数据库的管理权限下放给部门管理员，降低 DBA 的工作负担。

自动授权规则

基于上述功能，ODC 已经能够解决规模用户的数据库访问权限管理问题。为了进一步减少人工干预、节省人力成本，ODC V4.1.0 推出了自动授权功能。该功能允许用户使用文本表达式配置授权规则，实现通用化场景下的自动授权操作。

例如，要让部门 A 的新员工首次登录 ODC 后自动获得部门 A 研发人员的权限和高危数据库的可申请权限，可配置图示自动授权规则：

ODC 解决问题的背后逻辑

通过上面的例子，我们不难发现，ODC 解决问题背后的逻辑涉及两方面，一方面是权限模型，另一方面是权限框架。

权限模型

ODC 采用基于角色的访问控制（Role-Based Access Control, RBAC）和基于属性的访问控制（Attribute-Based Access Control, ABAC）并存的权限模型，如下图所示。基于 RBAC 模型，ODC 可以实现用户权限的批量操作和统一管理；基于 ABAC 模型，ODC 可以跳过角色直接将权限授予用户，适用于细粒度的访问控制。两种权限模型互不干扰：在对用户操作进行鉴权时，会同时从这两条线路计算用户权限，只要任意一条通过即通过鉴权。

权限框架

权限框架主要完成两个任务：一是对权限本身进行抽象和管理；二是为鉴权提供接口和实现。

权限的抽象

权限可以抽象为对资源的行为。在 ODC 中，我们使用资源表达式对资源其进行表述，其采用层级化思想，结构为：${ResourceType}:${ResourceId}[/${ResourceType}:${ResourceId}/...]。例如，对于 ID 为 1 的公共连接，用 ODC_CONNECTION:1表示；对于 ID 为 1 的资源组中的所有公共连接，可以用 ODC_RESOURCE_GROUP:1/CONNECTION:*表示。

ODC 用户可获得的数据库权限包括访问权限和管理权限。其中，访问权限包括可申请、只读和读写；管理权限包括仅查看、可编辑、可管理、可新建。使用行为描述符的组合来对资源的权限进行表述，具体如下：

不同的行为之间可能存在隐含关系。例如，若用户拥有公共连接的读写（connect）权限，就自然应该有该公共连接的仅查看（read）和可申请（apply）权限。ODC 通过二进制掩码的位运算实现不同行为间隐含关系的判断：若行为 1 的掩码与行为 2 的掩码进行 按位与（&） 操作后等于行为 2 的掩码，则说明行为 2 隐含了行为 1。

鉴权流程

用户要想对数据库等公共资源进行访问和管理，都需要发起 API 调用请求，获取返回值。API 调用本质上是调用 ODC 后端的方法。因此，鉴权的时机可以放在方法调用前和执行结果返回前，具体鉴权流程如下图所示：

鉴权的逻辑可以简要概括为：获取当前的用户信息，然后从元数据库中查询用户直接拥有的权限和通过关联角色而获得的权限，接着将用户已有的权限（acquiredPrivilege）和执行方法所需的权限（requiredPrivilege）进行比对，如果 acquiredPrivilege 隐含了 requiredPrivilege，则通过鉴权；否则鉴权不通过，程序抛出异常。

小结

管控协同在企业开发场景下实属刚需。本文以数据库的访问控制为例，向您介绍了 ODC 在权限管理上的产品形态和实现原理，由于内容不涉及太多技术细节，大家有相关疑问可以在评论区展开讨论。事实上，ODC 的管控协同能力才刚刚崭露头角，未来，我们将支持库、表、敏感列等更细粒度的权限管理，并提供更易用的团队协同交互体验，敬请期待！

欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/