本文主要是介绍某头部证券公司决策：为什么首选 CloudQuery 数据库管控平台？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
作者介绍：董美科，国内头部证券公司 DBA，从业经验 10 多年，早年工作在外企数据库相关服务工作，现在主要负责数据库架构设计和运维平台开发维护，擅长数据库性能调优、故障诊断。
本文是 CQ 用户说直播内容的整理，董美科将从用户视角，结合 CQ 在该证券公司的实际应用为大家分享《面对多元化数据库管控，如何实现降本增效》。
- 证券公司的业务背景及痛点
- 数据库管控产品选型过程，为什么会选择 CQ？
- CQ 在证券公司的使用情况
- 使用CQ 考虑的问题未来规划
标题业务痛点及需求
我所在的部门主要负责 IT 基础组建运维。随着技术的不断演进，涉及到的数据库种类不断增多，目前需要对十几种数据库进行管控，包括 MySQL、Oracle、达梦、Db2、SQLServer、TDSQL、OceanBase、Redis…对于数据库的安全管理，也变成了一件非常麻烦的事情。
图片
痛点一：在证券行业，大家基本上都认为安全审计是无法实现的一个问题。我们经常会遇到监管、审计等要求。传统的做法是通过旁路或数据库自带的审计功能，但实现起来效果很差，对性能的影响也非常大。
痛点二：放眼整个部门，所有的数据库客户端是五花八门的，有开源版、企业版。并且平时也需要去教别人这些客户端如何使用，耗费的时间成本非常大。
痛点三：在测试环境中涉及的人员比较负责，除了自己部门的测试人员，还会涉及到外来人员。而一般的安全和运维权限管控比较低，这也很容易造成数据泄露风险。
产品选型
项目目标
回到我们项目的目标来看，对数据库的运维及安全审计，需要做到事前进行严格的权限管控；事中进行全流程行为追踪，违规行为发生时能够及时告警；事故发生后能够精确溯源。同时也需要通过产品自带的数据库管理工具或者第三方开源客户端，来替代日常运维中使用的 Navicat、PL/SQL Dev、WinSQL 等工具，规避使用破解软件的版权风险和节约成本。
项目产品调研
基于上述痛点，我们踏上了数据库管控工具的选型之路。在选型初期首要考虑的是以下两点，一、需要统一的接入口进行数据库安全管控。二、需要方便大家的使用习惯，无需投入过多的时间在新工具的学习和使用上。
在证券行业行为审计、数据库审计的应用规模和范围较小，参考价值不大。所以在前期调研及选型过程中，我们也花费了大量的时间和经历进行产品了解。在进行了多方调研后，我将接触到的产品分为以下四类：
一、产品依赖于 dbeaver 等工具（严重依赖第三方开源）
二、一种类似开发使用报表工具（工具界面复杂操作复杂，不适合运维使用）
三、基于开源解释引擎开发的工具（对于 SQL 支持不好 对于稍微特别的 SQL 就需要改代码，改的代价也会非常高）这个产品体验也不是很好，经常莫名其妙的会出现一些错误。
四、自主研发的解释器（这种类型工具，第一步就需要把 SQL 解析出来，进行权限管控，相对来说比较值得信赖）
随着调研的深入，我们也更加聚焦了所需要的功能。比如该产品必须具备数据库安全管控和审计的功能。同时，为了保证研发人员的工作效率，并满足其使用习惯，操作界面也需要和现有的工具兼容。
产品功能点考察
我们在进行产品选型过程中，需要考察的产品功能点有：用户管理、认证、授权，数据库的连接及连接权限，数据库操作管理，数据操作权限，权限提升流程，行为审计，数据保护。
- 平台支持、平台安全部署及自监控能力是首要考察功能点。现阶段我司使用的数据库，包括 OceanBase、TDSQL、ClickHouse …都需要数据库管控平台进行支持。这也是最基本的一个需求。
- 关于用户认证授权，需要考虑到该产品是否有能力和公司现有的统一认证平台进行对接，并且需要操作方便，不需要通过二次开发来实现。
- 关于连接权限，需要考虑从数据库接入该管控平台到使用，是否支持不同的人员有对应的权限来查询和使用数据库。这也需要根据公司已有的架构进行配置。
- 关于数据操作管理，DML、DLL 的基本操作、shell 窗口、危险动作的拦截等，都是需要考虑的基本功能。
- 关于权限控制，需要从宏观整个库的权限到表、列的权限，来判断能否通过该产品进行有效控制。
- 关于提权流程，所有的提权操作需要在产品内部实现，无需跳转到其他第三方平台。同时需要审批全流程记录，并能看到大家对应的权限。
- 关于审计，用户操作了哪个数据库、详细的操作动作都需要有准确的记录。
- 关于数据保护，需要对敏感的数据及信息进行脱敏或水印处理，同时需要对数据拷贝功能进行权限管控。
产品的关键问题
在产品选型过程中，我们发现市面上很多产品都对外宣称有上述功能，但在实际测试过程中，会多或少都会有部分功能缺失。仅凭产品功能点，无法快速找到满足要求的产品。
如何在这个基础上选出一个值得信赖的产品呢？我们进行了兼容性测试、安全性控制的测试，结合项目落地难度和客户端体验，进行了全方位考核。
以 DB2 数据库为例，我们对其进行了兼容性测试，主要考核点 SQL 解析、某些特定写法是否支持、数据库存储过程中是否可以方便编译，以及相应的行业兼容性案例…其中，行业案例也是我们在做兼容性方案时很看重的点，如果行业案例越多，也可以证明该工具受到的考验越多，也就更值得信赖。除此之外，平台对大表的处理也能体现出产品的能力。
此外，工具的安全性也是我们考察的重点。这也是我们在进行产品选型时能直接看到高低之分的地方。比如增加数据库源后数据库连接数，连接数约多，效果越差；当客户端关闭后是否还有连接留在数据库，如果有链接 在数据库上认为是有危害的；是否有超时控制等。
我们也通过这些测试，将产品按照兼容性测试以及 SQL 解析进行了分组对比。整体看下来 CloudQuery 非常符合我们的选择标准。此外，我们还考察了 CloudQuery 的服务团队、保障能力，以及公司资质等。综合对比下来最终选择了CloudQuery 。
CloudQuery 的应用
目前在我们公司中，使用 CloudQuery 的人数已经超过了 100 人。通过 CloudQuery 用来管控的数据库类型包括：Db2 、MySQL、Oracle、SQLServer、达梦、OceaBase 、TDSQL。此外在 CloudQuery 的技术支持下，也极大缩短了项目周期。具体的实现价值：
1.满足国产数据库统一管控需要。
2.实现大批量数据库统一纳管，提高管控与操作效率。
3.分组授权帮助管理员实现高效批量权限赋予和更新。
4.权限看板：直观、清晰的看到不同用户所具备的权限，更加方便的进行权限管控
由于现在数据泄漏的风险越来越大，为了保证测试环境的安全性。就需要用到 CloudQuery 中的脱敏扫描功能，我们会对测试环境的所有库进行扫描，一旦发现未脱敏的数据，就需要对应系统的管理人员去审核，这也是一个高频使用的功能。
CQ 脱敏扫描
为了让更多的用户快速了解并使用 CloudQuery ，我们会对权限的控制、导出，以及复制粘贴的权限默认打开。同时也会做对应的安全管控。
在生产环境中也会有权限的控制，只有系统的管理者才会有使用权限，非所属系统的人如想要进行操作，需要进行提权，才能拿到对应权限，并且会对你需要操作的功能进行细粒度的审批，比如对哪个数据库做读写，进行哪些读写等。
以上就是 CloudQuery 在我们公司内部的落地情况。
最后再分享一下 CloudQuery 项目落地的时候，我进行的思考：
1、安全控制和使用便利的矛盾
初始配置，权限设置，公司权限控制到什么粒度？通过分组管控和批量授权进行完成。
2、统一管理和工具多样性的需求
新的工具如何让人信服？可以很好的兼容已有的工具的功能，同时怎么改变团队同学已有的习惯？
CloudQuery 官网：https://www.cloudquery.clubCloudQuery
文档：https://bintools.yuque.com/org-wiki-bintools-xniowl/do4ums
这篇关于某头部证券公司决策：为什么首选 CloudQuery 数据库管控平台？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
