前言研发、数据分析师及运维内部人员有数据查问、数据勘误等需要。若无管控平台，则只能通过授予账号的模式来受权这些用户间接拜访数据库。个别会按类型建几个不同级别权限的账号给对应的同学应用，这会导致以下问题：因为一个账号对应的应用人很多，无奈精准的定位申请人；同时只能依附账号权限来限度用户行为，无奈对申请进行流程上（经审批人审核）的束缚；同时受拜访的数据库的稳定性也无奈失去保障，若有拜访权限的用户执行了高耗费的 SQL 很有可能会导致数据被打挂；账号权限调整繁琐，若要限度某个用户拜访，则须要批改用户明码，而后再知会出限度人外的其它人批改信息。从这些问题中咱们可能发现，在企业级开发场景中，须要将数据库的拜访权限纳入管控，免得造成数据泄露、失落、滥用等问题。这时就须要一款具备权限治理和平安协同能力的数据库开发工具，帮忙 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 的管控协同能力才刚刚锋芒毕露。将来，咱们将反对库、表、敏感列等更细粒度的权限治理，并提供更易用的团队协同交互体验，敬请期待！