本文分析数据库国产化后的一个重要使用场景问题，即国产数据库的访问权限管控该如何设计才能做到在确保数据安全可靠的前提下又能尽可能方便用户使用。

问题背景

数据库访问权限属于运维权力的一部分，权力跟责任总是要匹配的。有权力但不履行责任或者疲于履行责任，都属于权责失衡的表现。

数据库权限的责任包含：

• 1. 数据存储安全。具体指服务器或网络故障后数据存储数据不丢，数据读写服务能快速恢复。
• 2. 数据读写路径安全。具体指所有数据库的访问路径都安全，除了应用程序外还有其他数据库客户端访问、数据库主机访问等。避免重要数据被非法访问、篡改、导出泄露等。
• 3. 数据库运行性能良好。数据库读写性能符合业务需求，避免不正确的数据库读写方式给数据库性能或安全带来影响。

对于责任 1 是运维的本职工作，受到领导的高度重视。通常都不会有问题，如果有问题那运维负责人必定是第一责任人被问责。

对于责任 2 和 3 ，也跟运维工作有关，实际执行效果在不同客户里不尽相同，反映了企业的科技力量建设成熟度。本文就是就这两点展开论述。

传统数据库的权限管控思想

传统数据库运维下，数据库的访问都是通过堡垒机控制访问终端。访问终端包括 SSH 终端（有 Putty、XSHELL、Mabaxterm、SecureCRT、Remote Desktop 等）和数据库客户端终端（SQL Navicat、PLSQL Developer、DBeaver 等）。

堡垒机是访问的重要关卡。一般堡垒机账户到个人，也有的为了简单在多个人之间共用账户。堡垒机针对 SSH 终端有文字审计功能，针对图形化客户端有截屏审计。如果知道某个时间段有非法访问或操作，就事后查看堡垒机的审计记录。如果线索很少，基本上就是大海捞针。

SSH 终端也不是本文重点，就不展开说。数据库客户端终端通常是已经绑定了某个数据库的某个账户。每一个使用这个数据库客户端终端的都是使用同一个账户读写数据库。控制这一个账户的权限就能控制数据库的读写风险。此外，少数人如果有 SSH 终端权限，也可以直接在命令行下使用账户读写数据库。这个数据库账户可能是给到人的，也可能是共用的。

以上这个设计在安全上有一定的防护作用，但也有问题。问题包括：

• 1. 共用数据库账户，非法操作单凭终端的审计日志无法确定是哪个人操作，还需要结合堡垒机的登录使用日志联合确定。
• 2. 数据库用户很多，这样的数据库客户端连接需要配置很多，每个连接的用户权限都需要在数据库上配置并确保安全。通常账户的安全使用守则遵循 NEED TO KNOWN 原则（仅限知悉必要信息）。但是不同人的需求不一定相同，共用账户最终导致这个账户在数据库上的权限对于部分人是过大的。
• 3. 这个机制对于有合法访问权限的人的非法访问和操作数据起不到防护作用。有合法访问权限是指有堡垒机登录权限以及这个数据库客户端入口访问权限，有非法访问和操作是指有些数据很敏感，应限制能访问的人。这个能访问的人的集合实际上是能访问堡垒机以及数据库客户端的人集合的子集。这个设计实际上却做不到。
• 4. 当非法数据访问和操作东窗事发后（如篡改数据、删库跑路），回过头来查询堡垒机审计记录，即使能找到责任人都已经于事无补。如果事情没有暴露，很可能都没人知道或者关心是否有非法访问数据问题。有些行业里数据泄露问题（被拖库）很严重，这个访问路径有漏洞就是其中一个关键原因（另外一个泄露渠道是从应用出去的，那也是名义上的合法访问路径）。

堡垒机的管理权限在运维，权力在运维这边，出问题追责时，运维自然也难以豁免。于是一种极端的做法就是严格管控有堡垒机访问权限的人，对于非运维人员不允许或者尽可能少的访问生产环境堡垒机里的数据库终端或数据库客户端。至于这些人为什么要访问数据库，有什么需求就跟运维没有关系了。或者就直接说业务研发人员没有需求访问生产数据库。直接从源头上消灭这个问题。在管理学上，这叫“懒政”。

这种管理思想属于“收”或“堵”。业务应用在线上运行，应用出功能问题或者性能问题时，不可避免的就要访问数据库进行排查。如果把这个正常的需求给堵死了，虽然运维一方的安全问题风险是降低了，但业务研发方却会非常难受。站企业总体利益角度来说，这是有损的。

另外一种管理思想是“放”。把权限放出去。不同应用的数据库从服务器上就彼此隔离（很多是虚拟机）。每个业务应用的数据库的虚拟机访问权限（SSH 终端或者数据库客户端终端）权限都给到应用负责人。应用自己用，出问题自己负责（运维只负责最基础的数据库部署、监控、主备高可用、备份等）。放权，也释放一些不必要的责任。这个做法也有它的好处，组织运行效率更高，但是缺点也很明显。问题还是可能出了，只是跟运维无关。这就是敏感数据泄露的一个常见原因。

网络流量旁路产品

传统数据库安全产品里还有一类特殊的产品，在网络层面通过对数据库流量抓包来监控或拦截非法访问或操作。这个设计符合安全逻辑，也不跟其他堡垒机或数据库客户端产品、或者应用冲突，也很常用。这个方案本质上是一个网络流量监控方案（就跟我们都知道的那个防火墙设计一样）。为了能将报文内容跟实际数据库库表联系上，产品的使用还需要配置数据库实例信息。

实际部署使用的时候，对网络流量抓包对网络性能会有影响。所以这类产品会做一个旁路设计，会将数据库流量复制一份经过这个产品所在服务器网卡，然后进行分析。这就是旁路网络流量。如何确保无损。生活中我们遭遇过在某些偏僻地方贵重物品失窃或者发生交通事故，当要调监控的时候得到的答复是“真不巧，这几天的监控数据没有或者这个监控已经坏了很长时间”。旁路流量就可能有这个问题。它只能证明事件记录存在过，但是不能证明事件记录不存在过。当数据库规模很大的时候，要做到网络流量旁路，硬件上也要做相应的投入。这个投入随着业务的发展可能会出现“后劲不足”的地步。

流量旁路安全产品要解释报文内容必须跟数据库实例配合使用。它也不能阻止其他数据库访问通道。（所以产品受欢迎）。 它还会存在有些数据库的流量并不在监控范畴内。当然，它最大的问题依然是只能监控不能管控。技术上是能管控拦截，但没有人敢这么用，因为会降低数据库读写性能，引起其他人和应用的抵制。

有没有一种既能收拢权限保障数据安全又能方便用户使用的方案或产品？传统数据库的运维思想、生态产品都已经固化，不大可能会变革了。这种方案或产品只可能出现在国产数据库大兴的时代了。

国产数据库的权限管控思想

应用研发人员在国产数据库项目中的困难

数据库国产化，绝不仅仅是换个数据库那么简单。上下游的应用和相关人员都会受到影响。特别是应用研发人员，在数据库国产化项目中会非常被动。

具体体现在：

• 对国产数据库功能原理不熟悉，使用经常报错，沟通解决成本很高。

这些用法可能在传统数据库里用了很多次都没问题，到国产数据库下就有问题。虽然有些应用研发也很有探索精神，但国产数据库通常文档欠缺或质量不高，网上相关案例文章经验分享也很少，应用研发人员可以参考或者寻求帮助的途径非常有限。在有些客户项目里，很可能运维人员对国产数据库也是一知半解的情况，出现问题沟通效率非常低。此时就依赖国产数据库厂商原厂支持。

支持客户是原厂售后的职责，但是让客户满意却是可遇不可求的事情。因为客户非常多，每个客户的问题也非常多，大量问题涌来，原厂支持人员的支持力度很难跟上。态度好的，按部就班；客户第一的，疲于奔命。

• 国产数据库访问受限，主动探索排查问题能力受限。

如果是一个成熟的数据库，应用研发只要增删改查，都不会有问题。偶尔就是大批量数据查询和修改有些性能问题。但国产数据库虽然号称兼容传统数据库（MySQL、ORACLE 或 PostgreSQL），但深入使用又会发现还是有些不一样的地方。这个细节不一样是合理的，特别对于那些是完全自主研发的国产数据库，它只是功能接口兼容传统数据库，其底层原理完全是自主设计跟传统数据库的底层原理很可能完全不同。

所以深入使用国产数据库时，是需要结合应用和数据库的特点去重新设计优化的。把老的设计跑在新的国产数据库上，有问题是难免的。有些应用研发也能认识到这点，只是难度在于数据库的访问受限，导致有些时候没办法自主研究，不得不去找运维沟通，或者找厂商沟通。这就又回到第一个现象里。这个受限通常是在生产环境。

当然设计优化更应该是在开发测试环境就要解决的。开发测试环境数据库访问限制会少很多，很多时候都是直接给到客户端直接连接数据库权限。

这个客户端往往是传统的数据库客户端。如 SQL Navicat、DBeaver、MySQLBench 之类。这些传统的客户端强在数据库开发设计（如表结构设计、存储过程设计等），弱在问题诊断能力。曾经有款很好的传统数据库客户端 Toad（支持 MySQL/ORACLE/SQLServer/DB2等），内嵌了很多数据库诊断脚本和文档，可惜后来也没落了。其他客户端虽然没有多少诊断能力，并不妨碍应用研发分析数据库问题，因为传统数据库的生态很完善，很多问题在网上都有解决方案。而回到国产数据库则相反。还是同样的客户端，同样的用法，但是数据库会有新的问题，很多时候研发都想不明白到底是什么问题。关于这类项目经验说到具体的国产数据库，那说一天也未必能说得完，以后再另起一篇文章分析。

所以，国产数据库开发难问题，一部分跟国产数据库权限管控有关，一部分跟数据库产品功能成熟度和生态有关。

国产数据库的数据安全问题和应对

传统数据库换做国产数据库，可能应用也改造或者替换了。除此之外，人还是那些人。但从数据安全分析角度看，数据库国产化，不过就是“旧瓶装新酒”，面临的数据安全挑战一样没少，甚至更严峻。

国产数据库特别是分布式数据库，由于单机能力相比传统数据库单机能力要差一些，所以在规模上就远超传统数据库服务器规模。另外一个重要原因是互联网业务的发展促进数据规模和访问流量的高速增长。多方面因素使得运维人员现在要管控的国产数据库更多了。如果还是堡垒机加数据库客户端那种管理方式，其隐藏的安全风险可能会被进一步放大（窟窿更多了）。权力还是在运维手上没什么变化，责任风险更大了。权责不匹配，久而久之，总会出问题。

不过有些国产数据库出自互联网大厂，在内部的时候造就积累了这类问题的应对经验，很值得外部企业借鉴。蚂蚁集团自主研发的分布式数据库 OceanBase 以及其生态产品就是一个很好的学习例子。

OceanBase 基本占据了蚂蚁业务里关系数据库绝大部分市场，同时也进军了阿里集团原属于分布式 MySQL 数据库的业务板块（如高德、饿了吗业务等）。OceanBase 在蚂蚁和阿里集团的集群规模可以说非常庞大，其面临的数据安全挑战也就更大。

OceanBase 数据库的生态产品里有一款客户端产品 ODC，全名 OceanBase 开发者中心。最初目的就是降低 OceanBase 开发者使用门槛（这个开发者也包括蚂蚁内部用户），提升用户使用体验。翻译成大白话就是 OceanBase 早期出来的时候运维人员和开发人员都抱怨太难用了。即使是到现在，还有些客户在抱怨这点。其中有一部分原因还是传统的数据库安全管控方案。不过这里我们只说 OceanBase 产品自身的问题。

OceanBase 也从来没有回避过这些问题，而是积极的通过产品迭代去不断解决这类问题。如今在大部分客户的心智里，OceanBase 的运维平台 OCP 和开发者中心 ODC 是当之无愧的最好用的国产数据库生态产品。当然迭代快的另外一个问题就是解决老问题的同时可能引入新问题。这点瑕不掩瑜，是否升级客户自己抉择。OceanBase 产品研发团队也不回避这个问题，继续迭代 

ODC 是如何解决前面提到的易用性和安全问题呢？ 简单总结如下：

• 1. ODC 里包含传统数据库客户端基础功能。如图形化创建和查看数据库对象能力（表/视图/函数/存储过程/触发器等等）、SQL 窗口邓丽。
• 2. ODC 的 SQL 窗口除了能执行 SQL，还能引导看执行计划（解析执行计划/实际执行计划），有 SQL 执行画像（解释 SQL 执行性能中的关键数据，对性能诊断有帮助）
• 3. ODC 里引入了任务流和工单机制，支持数据库变更需求。变更工单会有流程审批机制、定时执行机制、回滚机制。
• 4. ODC 支持数据安全需求。能对数据分级分类进行定义，查询触发敏感数据能自动拦截，并提示发起工单审批。目的合法的访问敏感数据通过工单审批解决。所有在 ODC 里发起的查询都在 ODC 里有审计记录可以查询。对于危险的 SQL 会给出风险提示，并按最高风险级别应对（发起工单审批）。工单里还可以附带数据操作对应的备份回滚机制，审批人员检查这个正确性。
• 5. ODC 里的账户都属于 ODC 的平台账户，不是数据库里的账户。ODC 管理数据库实例使用一个专用的高权限数据库账户，用户操作的权限管控都在 ODC 里做。可以简单理解为 ODC 就是 OceanBase 的数据库堡垒机。

ODC 的数据安全应对思路就是通过堡垒机封堵其他数据库访问通道，所有人包括运维人员对数据库的读写访问都通过 ODC 。当然运维任务主要还是在 OCP 里完成，以及部分运维人员要登录数据库主机，这些访问权限就通过堡垒机控制，收敛到只有少数运维人员自己可以操作。

ODC 确实能降低 OceanBase 的使用门槛，且将数据库权限下放给业务研发人员又控制住了数据安全风险，是权责匹配的一个好的实现案例。有关 ODC 的详细介绍可以参考文末另外一篇文章。

ODC 是 OceanBase 的数据库堡垒机，这句话基本是对的。目前看 ODC 的发展也开始支持 ORACLE 、MySQL 和 PostgreSQL 的部分功能。ODC 能做这个的原理也是探索目标数据库的功能原理去适配实现相应 ODC 场景。

有些企业客户使用了多个国产数据库，比如说达梦、OceanBase、TiDB、TDSQL、GaussDB。ODC 就支持不了这么多了。且不论 OceanBase 团队会不会支持其他国产数据库，其他数据库厂商肯定不乐意支持 ODC 。

其他数据库厂商也解决不了这个通用性问题。

云趣的数据库安全管控产品 QueryX 的权限管控思想

所以，国产数据库的数据安全问题的解决方案就最可能在第三方数据库生态公司落地实现。下面介绍的就是浙江云趣公司的数据库安全管控产品 QueryX 。

简单的总结，QueryX 功能包含：

• 1. 支持常见的传统数据库（ORACLE/MySQL/PostgreSQL/SQLServer/MongoDB/Informix）、老牌国产数据库（达梦/金仓/Gbase）、新兴的分布式数据库（OceanBase/TiDB/TDSQL/PolarDB-X/GaussDB/TDSQL/GoldenDB 等）。
• 2. 功能包含数据库对象图形化查看和变更、SQL执行窗口、工单流程系统、数据分级分类定义和权限管控。
• 3. 安全管控的核心思想也是将 QueryX 的平台账户关联到具体的用户（人），QueryX 跟数据库只有一个高权限账户，所有权限管控在 QueryX 内部实现。支持三权分立、查导分离。

QueryX 的安全管控也需要堡垒机封堵其他数据库读写渠道，同时也不能监控业务的操作记录。业务应用是合法的数据库访问途径，应用内部的数据安全风险问题必须通过应用自身的日志、权限管控和审计功能去解决。这点在某些行业里（如银行、证券）里显得尤为必要。

下面举一个使用场景例子。

某城市银行的很多应用都是外部开发商提供。外包开发人员过千人，每周的数据库变更任务成百上千。数据库涉及到 MySQL、TiDB、OceanBase。 这些数据库变更就是通过 QueryX 的工单系统去完成。平时的数据问题排查、数据导出，更是涉及到很多数据库。运维人员自身肯定没法一一管控到。借助于 QueryX，运维人员维护好实例后，还维护好对应的应用方负责人，有些工单审批也让应用负责人从业务层面参与把关，运维人员做最基础的检查。然后工单的执行由平台在自定义的时间（通常是晚上低峰期）去执行。这样两个运维人员就可以支持好几千人的研发团队的数据库需求。

有关 QueryX 的详细介绍可以参考文末链接。

总结

最后，不得不补充一句，以上讨论的始终是技术层面的解决方案。国产数据库的数据安全关键还是相关责任人的思想。说通俗一点就是要有责任心，同时又要有为其他人提供更好服务的意愿，那么再搭配好的产品就是如虎添翼。否则，数据库国产化，旧瓶装新酒，继续沿用老的运维方式，只会让国产化之路更加坎坷或者充满风险。

此外，数据库权限的收与放还影响业务研发人员的数据库使用体验。特别是国产数据库，研发人员也是要从头学习，缺乏必要的权限也就限制了研发主动分析解决问题的能力。问题是会客观存在，并且会不断放大。问题最终会传递到运维端。解决问题效率低下对企业整体利益也是有损的。