如何解决数据流通过程中【责任追溯】这一难题？

前言：本文由 CQ 社区用户“木头人”分享，其所在的公司专注为政府机构和国有企业服务，对数据安全要求极高。面临公司规模扩大、数据库分散、机密数据管控、数据流通追溯等挑战，他将分享如何在保障数据安全和合规性下，高效处理敏感信息和多样化的数据库管理。

    业务场景

我们公司是一家专注于科技领域的企业，主要为政府机构和国有企业提供服务。由于行业的独特性，我们在数据库安全管理方面的要求相对于民营企业和私人企业更为严格。除了必须符合数据安全控制和等保等方面的合规性要求外，在我们公司中还有一个进行数据交易的核心产品，这要求我们对公司存储的数据以及数据流转过程进行非常精细的管控。

现阶段我们公司在数据库管理上面临着一系列挑战，从公司规模和数据库分散到安全与权限管控、数据流通的追溯和责任追踪，再到多样化的数据库类型和管理工具......下面我将围绕这些方面的问题展开讨论，分享我们在解决这些挑战时的经验和做法。

    核心业务的几大痛点

我们公司拥有较多的开发人员，人数超过一百。由于公司人员众多且数据库分散，传统的账号管理方式变得繁琐，每个人都需要创建不同权限的账号。这不仅增加了管理工作和运营成本，还对安全性产生了影响。同时，我们的数据库结构相对分散。包括公司内的开发库、测试库，以及客户端的开发库、测试库和生产库，还有一部分存储在云上或政府内部。

这种分散性给权限管控带来了挑战，尤其是在人员繁杂的情况下，传统的账号管理方式增加了管理成本和运营负担。

公司在处理数据交易产品和敏感信息方面也面临诸多困扰。我们有时候需要将客户的生产库导入到我们的测试库中，来进行模拟仿真工作，以此找出业务上的故障，并同步进行分析。而客户生产环境的库它的信息比较敏感，尤其是国企、政企的数据，在这之中会存在很多用户的隐私数据，包括人名、身份证号码、手机号......

对于处理机密数据，特别是来自客户的生产库，需要更为谨慎。随着个人信息保护法的实施，对于泄露隐私数据的惩罚力度增大，公司必须更加谨慎处理这些敏感信息，以避免潜在的法律责任。

在整个数据流通过程中，公司面临着追溯责任的难题。传统的方式我们只能通过权限来控制每个人能拿到什么数据，但我们无法防止某些恶意行为。这可能就会导致在开发过程中出现一些问题，例如过度授权导致的开发库被封掉，而找不到具体操作人员。解决这一问题需要更加智能的追溯和责任追踪机制。

公司管理的数据库类型非常多样化，包括 Oracle、SQLServer、MySQL、PG、国产的达梦、人大金仓......二十余种。我们之前用过 Navicat 进行管控，但是 Navicat 的覆盖种类较少，只能支持一些常规的数据库。这就导致开发人员需要安装大量的数据库的开发工具来进行管控，这无疑增加了工作的复杂度。我们需要寻找更为综合的管理工具，以提高工作效率和降低复杂性。

在选型的初期，我们进行了广泛的产品测试，涵盖了商业产品和开源产品等多个方面。然而，许多产品的功能未能满足我们的需求。经过一段时间的仔细测试，我们最终决定以【脱敏功能】为主，来选择一款可以免费使用的产品，来确保数据安全。在这个过程中，我们通过搜索引擎发现了CloudQuery（简称“CQ”），并首先对其脱敏功能进行了测试和使用。

我们在产品选型过程中主要出于以下 6 点考虑：

• 集成性：在同类的产品中，我们很少能找到可以同时集成数据库网关和数据库脱敏两个功能的产品，而我们的实际业务中需要同时使用这两项功能。

• 权限分离：我们希望实现类似堡垒机一样的功能，将人、权限、密码这三种不同元素强分离。这样一来，每个人能够获得特定权限，但并不了解其他人的密码，从而实现对依赖的弱化。这种方法在人员变动时能够快速进行权限调整，比如小明在 A 项目中赋予的权限，当他完成 A 项目进入到 B 项目后，A 项目的权限会被回收重新赋予 B 项目权限。

• 审计功能：我们追求整个出库流程的可追溯性，包括导入导出、更新和删除等操作都需要有迹可循，责任可追踪。此外根据等保要求，我们需要保留 180 天的操作日志。

• 对开发人员友好：我们希望该产品对开发人员来说相对友好，减少对其使用习惯的影响。通过简单的培训，开发人员能够快速掌握和使用该工具。

• 数据库类型支持：上文提到了我们的数据库类较多，所以我们希望该产品具备丰富的数据库类型支持能力。

• 流程管控：针对一些危险的数据库操作，比如执行危险语句 Drop、Truncate、Delete..... 我们希望有实施审批流程，确保领导审批后才能执行，以减少数据生产中的风险。

结合以上六点考虑，CQ 满足了我们的基本需求。在使用 CQ 的过程中，我首先感受到的是他们的开放，在产品使用上遇到的问题会有专业的人在技术交流群第一时间解答，此外，CQ 也非常鼓励我们提产品反馈和建议，还会对收到的问题进行记录，定期在群里进行反馈。下面再来讲讲 CQ 在我们公司的一个使用情况。

目前项目处于测试阶段，验证系统是否能满足业务日常的关键需求，包含适用性和稳定性。总体测试效果还比较满意，能够达到预期目标。

上文中也提到了我们在前期测试过程比较关注「数据脱敏」这一功能，下面我将围绕这一功能进行简单介绍一下我的测试/使用情况。

关于脱敏功能，我们主要关注对人个信息脱敏的情况，我们添加了三 种主流的的数据源（包括 Oracle）进行测试。

数据脱敏的规则使用的是系统自带的规则，目前没有自定义规则的需求，但这个功能可以通过正则表达式来匹配是个比较人性化的需求。

测试过程我们主要使用动态脱敏为主，开启了全部的脱敏规则 ，数据返回时所有符合规则的敏感数据都可以达到数据动态脱敏的需求，甚至有一些类似的数据都被脱敏了。静态脱敏目前没有业务需求，还没有进行测试。

使用 CQ 一段时间了，对于 CQ 的功能有一些期望，希望能够更加完善。以下是根据我们业务的使用场景提出的一些建议，希望这些建议能够帮助 CQ 变得更好。

建议一：在社区版本中开放 AD 域和 Open ldap 对接功能，用户导入默认禁用，限制激活的用户数量或并发数。

建议二：导出 Excel 增加编辑锁定功能，添加只能查看不能修改配置，随机生成一个强密码进行保护，用户可以在导出时启用或不启用这个功能。

建议三：把权限控制方式优化一下，目前 CQ 是根据数据对象划分谁有权限。可以将权限设置改为根据用户划分权限，定义每个用户的权限规则，限制每个用户拥有的什么样的权限。

欢迎大家进入 CQ 官网进行验：https://www.cloudquery.club。如果在产品功能或使用上有什么问题，欢迎大家进行反馈，一起加入到 CQ 的建设中来！