本文主要是介绍某头部证券公司决策:为什么首选 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 数据库管控平台?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!