保险行业实践 | 从0-1数据库安全平台建设

导语：面对多元化的数据库种类、各异的功能、跨客户端管控效率不高等痛点，该如何选择一款既能支持统一接入口，又能保证数据源安全，实现高效的数据操作的工具？国内某大型保险公司作为实践者，将从业务背景及痛点、产品选型及产品定制、使用 CloudQuery（本文简称“CQ”） 中遇到的问题、未来和 CQ 合作的规划四个方面分享其选型过程及思考。

作者简介：王珂，现就职于某大型保险管理公司，担任 DBA 的职位，主要负责 PolarDB 国产化数据库、开源数据库、数据库安全管控平台项目，以及数据库知识运维使用相关项目的工作。

业务背景及痛点

在当前的技术环境中，我们面临着数据管理和处理的重大挑战。随着技术的迅速发展，各种多元化的数据库产品应运而生，它们不仅类型众多，而且形式各异，国产化数据库千余套，开源数据库百余套，还有一些像 Oracle、MySQL 这些传统的数据库。这些数据库产品有着各自的优势和特点，能够满足不同的业务需求。

然而，对我们保险行业来说，技术进步的同时也带来了两个很棘手的问题：

1、缺乏统一的数据库操作客户端

2、权限管控不好控制，敏感操作监控及安全审计相对匮乏

缺乏统一的数据库操作客户端

目前国产化数据库客户端种类繁多，功能各异。比如：PolarDB 我们会使用 Polar Stack， OceanBase 会使用 OCP，以及达梦会有自己的管理工具界面，这些数据库涉及到的版权较多。

同时，跨客户端管控效率并不高。以我目前正在管理的 PolarDB 数据库为例，百余套数据库分布在十多个 Polar Stack 集群上，对于每个数据库的操作要在对应 Stack 集群服务器上输入数据库访问的IP及端口。这也就意味着，如果我要运维 10 套数据库，就要登陆 10 个 IP 及端口，并且还要跨不同的服务器集群，这样的操作管控效率不是很高。

对于开源数据库来说，目前的开源数据库大多都是采用第三方管控的客户端，这种第三方管控的客户端很难达到公司规定的安全管控标准。

权限管控

权限管控主要是体现在敏感操作监控，以及安全审计内容相对匮乏。

面对上述两种相对棘手的问题，我们需要建设统一安全接入口，进行权限分配，实现高效的数据操作，针对全流程进行安全审计。下面就来和大家展开聊聊不同的需求有哪些问题需要解决。

• 统一安全接入口 >> 所有数据通过统一的平台进行接入，使内部人员连接数据库的方式标准化，便于后续的集中管控。
• 权限分配 >> 判断使用用户的职能与应用场景，结合数据库资源重要程度对用户进行初始的细粒度权限分配，避免高权限滥用导致违规行为及信息泄漏风险。
• 数据操作 >> 希望内置功能均能贴合行业应用场景，提高运维效率，提供数据脱敏、数据导出等功能。
• 行为审计 >> 希望是全周期、覆盖广的审计。根据审计结果报表，可总览数据执行及安全情况，帮助内部人员知悉整体的执行安全态势。

产品选型及产品定制

基于上述的痛点及需求，我们需要选择一款数据库安全管控平台，在做了一定的市场调研后，最终集中在两款产品上。

为了接纳更多的数据库类型，尤其是能够符合定制的国产化数据库类型的标准，并且需要提供稳定的服务来支持我们面对新型数据库可能遇到的问题。基于这些需求，最终我们选择了 CloudQuery ，并在 2021年-2022年使用了 CloudQuery 2.3 企业版作为第一个项目周期。

这个项目涉及的数据库类型包括：Ocenbase、PolarDB、达梦、mongodb、mysql、redis、postgreSQL、Oracle。采用集群的方式进行部署，预估在公司内部有千余个用户进行使用，接入的数据库数量也达到了 1000+ 。

在和 CloudQuery 描述了我们的需求后，CloudQuery 也提供了相应的解决方案，对于缺少统一的客户端这一需求，CloudQuery 的解决方案是平台内置自研的数据库统一操作客户端，能够接纳多种数据库。

对于数据库的操作不好做权限管控，无法监控敏感行为这一问题，实现了统一的数据库用户与权限管理，对数据库操作进行统一权限管控、安全审计、行为监控告警。

出于对权限全局把控、用户唯一接入的标准，以及目前十家公司需要的底层数据库的国产化需求，我们也定制化了一些内容像全局权限视图、用户中心对接、平台底层数据库更换为 PolarDB、行为监控告警、跨 schema 数据大批导出......目前这一套内容已经上线，并在公司多个部门进行应用。

总体来说，这套定制化产品的上线满足了国产数据化统一管控的需求。同时实现了大批量数据库统一纳管，提高管控与操作效率。

下图为上文提到的定制化产品在我们公司的使用方式的详细介绍：

使用 CQ 遇到的问题

我们的项目周期集中在 2022 年，在这个项目过程中，也遇到了一些使用上的问题，我把问题简单归纳为三大类：

1）项目初期各数据库驱动适配问题，尤其像 OBPD 这种国产化数据库驱动适配的问题。

2）功能问题，比如 CQ 对不同数据库内置特殊函数的支持、全局权限视图、批量导出功能的设计，以及审计页面的不断完善，像增加 SQL 执行的监控、用户高频率监控。

3）性能问题，比如 OceanBase、MongoDB 执行效率、对工作台集群的稳定性影响，还有 OceanBase 流式数据库的替换提升使用体验。

虽然在上线初期会存在一些问题，但是一个新产品也是需要和我们的生产环境不断磨合，通过实际应用中遇到的问题，再去对产品进行优化，才能发现并且打造成一个适合我们的产品，在整个项目进行过程中，CQ 也给予我们极大的支持，最终让 CQ 能够更好提供稳定且多元化的数据库管控支持。

浅谈 CQ 2.4 使用体验

7月初，CQ 2.4正式发版，我也第一时间进行了试用，在这里谈谈我的使用体验，大致上讲，CQ 2.4 的功能更加丰富了，在很多方面也更符合我们生产业务的需求，下面简单举例：

1. 从支持的数据库类型上来看，2.4 完成了和 GaussDB 的适配，这也是我们在使用 2.3 版本所期待的。
2. 从数据库操作权限上来看，CQ 在“资源管理”模块增加了对 schema 的过滤功能，这对于安全审计员来说，可以在授权之前将数据库自带的，对业务用户授权无用的 schema 进行筛选，这对授权来说更加清晰简洁。
3. 授权管理的改动也较大，CQ 2.4 将各类数据库划分成小的类别，每一类数据库下会有 N 个数据库链接的子集，这样就可以实现该类别自定义权限统一定义并授权。

   

   
   从上图可以发现，权限区分的更细，可以根据自己的需求定制化唯一的权限标准。
4. 从安全管控功能来看，2.4 版本对于安全管控更加重视。从下图可以看出数据脱敏、数据保护、审计都被设立成了独立的功能模块，而且每个模块下面的功能更加丰富细致，更能符合安全管控的标准。同时还支持文本导入，结果集的可编辑、可复制，数据库从原库到目标库的备份，以及审计细项的监控关联权限的展现。

   

   

未来规划

下半年，我们将逐步完成新旧版本的替换，在版本稳定后，也会和 CQ 共同制定数据迁移方案。先完成部分生产环境的迁移，当生产环境使用稳定后，会将 2.3 上所有的数据库链接进行替换，正式切换成 2.4。

除此之外，也会继续完善功能需求，修复使用过程中新增的问题，这里也希望能够通过和 CQ 的配合，来提高项目的进展和效率，最后也希望 CQ 这个产品能够发展的更好，为更多用户提供强有力的支撑。