点击上方蓝字关注我们
互联网时代，各行各业的业务创新层出不穷。不同业务所产生的数据结构和特征也大相径庭，这也催生了各种眼花缭乱的新型存储方案，比如列式数据库（Cassandra、HBase），键值数据库（Redis），文档数据库（MongoDB），图数据库（Neo4J）等等。但对于很多传统的核心业务来说，关系型数据库依然是存储数据的首选。并且，受业务系统开发商、成本、政策等因素的影响，企业的IT架构中往往会出现多种数据库产品并存的局面。常见的有Oracle、SQL Server、DB2、Informix等国外商业产品，还有达梦、人大金仓、TiDB、Oceanbase等国产商业产品，也有MariaDB、PostgreSQL等开源产品。如此复杂的数据库环境给企业带来了极大的管理维护成本，同时也增加了数据库访问过程中的安全隐患。
接下来，我们尝试还原一下访问关系型数据库的场景。
访问数据库的实体
首先，需要访问数据库的实体一般可以分为两大类，一类是应用程序，一类是个人用户。应用程序根据架构不同，又可以分为C/S和B/S两种。
C/S架构应用
即Client/Server，这种架构由来已久，传统行业中的许多业务系统依旧采用它。
对于这类系统，每个用户的电脑上都需要安装一个客户端，并且要在其登录界面或者配置文件中写入数据库的连接信息（很多时候采用明文的形式），每个客户端都要直接连接数据库。在这种架构下，用户可以很轻松地获得甚至直接拥有这些连接信息。他们通过一些传统的第三方客户端工具（比如PL/SQL、Toad、Navicat等）就可以直接连接数据库访问数据。因此，这种场景下，数据安全隐患其实很大。
B/S架构应用
即Browser/Server，这种架构相对较新。它与C/S架构的区别在于，用户无需安装客户端，通过浏览器就可以使用业务功能。
这种架构下，需要直接连接数据库的只有后台的应用服务器。普通用户不会直接接触数据库的连接信息。当然，采用B/S架构的应用在设计之初也要考虑更多的安全问题，防止应用本身存在安全漏洞。这种架构在升级维护方面成本较低，且没有跨平台的兼容性问题。云趣科技刚刚发布的QueryX产品就采用了这种架构，还有大家熟悉的各种云上的产品也是。
个人用户
除了应用程序之外，个人用户直接访问数据库的场景也很普遍。通常，他们会使用各种C/S架构的第三方客户端工具来访问数据库。比如PL/SQL、SQL Developer、Toad、Navicat、DBeaver、DataGrip等。这类工具使用广泛，它们支持的数据库种类通常都很丰富，功能也都很强大，比如PL/SQL一直被Oracle DBA奉为神器，其在PL/SQL语言调试方面优势明显。但是，它们在数据安全方面的相关功能是缺失的。
接下来，我们会聚焦在个人用户访问数据库的场景之上（受篇幅所限，应用程序访问数据库的安全问题不在本文讨论范围），分析一下现状和痛点。
在很多企业中，个人用户在访问数据库时面临的问题有：
数据库的种类和数量繁多：Oracle、MySQL、DB2、SQL Server、Informix、达梦、人大金仓、TiDB、OceanBase、OpenGauss，使用两种以上且数量超过100套的是常态 直接访问数据库的人也很繁杂，通常有四种：除了DBA之外，通常还有应用开发&测试人员、业务人员和第三方运维人员。他们职责不同，具备的数据库技能也不同 只能通过传统的C/S架构客户端工具去连接数据库
如果我们把个人用户访问数据库的过程划分为事前、事中、事后三个环节，那上述三个问题叠加之后，就会给每个环节都带来安全隐患。
访问控制需要通过账号以及权限来实现。传统模式下，账号和权限全部下沉在各个数据库中。如果1个用户需要分别访问100套数据库中的部分表，那就必须为该用户创建100个账号，并且要在这100套数据库中分别定义其允许访问的表。这对于企业中稀缺的DBA来说，无疑是巨大的工作量。
更糟糕的是，异构数据库之间的账号权限体系不尽相同。比如Oracle中的user同时具有schema的含义，是数据库对象的owner，而SQL Server和MySQL中的user则没有这样的含义，数据库对象就属于某个数据库。这样的差异导致DBA给用户在异构数据库环境下创建账号和授权时的成本极高。并且，一旦有
人事变动，权限的变更、账号的回收等维护工作更是雪上加霜。
此外，数据库中针对表和列的权限控制也很繁琐，需要通过SQL语句来实现，且无法满足一些实际的场景。比如管理员希望某个人员只能临时访问某个库中某个表的某几列，到期之后权限自动收回。这在传统的客户端工具中很难实现。
访问数据库的人员技能参差不齐，比如DBA可以写出质量较高的SQL语句，但研发&测试人员通常只会使用基本的SQL语句来实现数据的CRUD操作，他们并不关心SQL的书写规范以及性能优劣。这就导致访问数据库的过程中，误操作时有发生。比如全表更新/删除，针对大表的全表查询等。再加上无法做到精细化管控，所以漏洞多，恶意操作的空间大。删除、篡改、访问敏感数据等，这些都可能会引起严重后果。
一个数据库账号多人共用的情况非常常见，传统的数据库客户端工具也缺乏完善的用户行为审计日志。此外，当数据从客户端工具中导出之后，其在流转过程中也缺乏保护和溯源的能力。这些又导致了事后审计追责很困难。虽然堡垒机产品存在已久，但它更多是针对操作系统和命令行操作的审计，对于图形化操作一般只能通过录屏的方式来记录，不便于恶意行为的检索。
防止自身利益受损
数据安全问题老生常谈，但各行各业的数据安全事故依然时有发生。
【金融】2018年四大行都曾发生数据泄露事故而受到中国人行的处罚
【政府】2019年某省政府部门数据泄露至海外，影响中美贸易谈判
【制造业】2020年某知名企业使用了带有木马的PL/SQL developer客户端工具，导致数据泄露被黑客勒索
【互联网】2020年微盟员工因对公司不满，恶意删除数据，导致市值蒸发超10亿
【企业】2021年链家员工因不满工作调动删库跑路，花费18万恢复数据
可以看到，数据安全事故一旦发生，轻则遭受经济损失，重则关系到企业甚至国家的存亡。因此，仅仅从企业或者政府的自身利益出发，也有必要做好数据库的安全管控工作，尽可能地降低数据存储、获取、处理、使用等各个环节的安全风险。
近年来，由于国际形势日益复杂，国家安全上升到了一个前所未有的高度。因此国家也出台了一系列和企业、政府信息系统（包括数据库系统）安全相关的法律法规：
2017年6月1日实施的《网络安全法》
2019年公安部发布了等保2.0的一系列标准
2021年9月1日实施的《数据安全法》
正在制定中的《个人信息保护法》
我们对这些文件进行了深入的解读，其中《网络安全法》的 第二十一条规定：
国家实行网络安全等级保护制度。网络运营者应当按照网络安全等级保护制度的要求，履行安全保护的义务。保障网络免受干扰、破坏或者未经授权的访问，防止网络数据泄露或者被窃取、篡改。
第二十五条规定：
网络运营者应当制定网络安全事件应急预案，及时处置系统漏洞、计算机病毒、网络攻击、网络侵入等安全风险；在发生危害网络安全的事件时，立即启动应急预案，采取相应的补救措施，并按照规定向有关主管部门报告。
第五十九条规定：
网络运营者不履行本法第二十一条、第二十五条规定的网络安全保护义务的，由有关主管部门责令改正，给予警告；拒不改正或者导致危害网络安全等后果的，处一万元以上十万元以下罚款，对直接负责的主管人员处五元以上五万元以下罚款。
根据上述条款，我们可以得出的结论是，等级保护已经成为法律制度，不做等保就是违法。而数据库系统通常是最核心的信息系统，做好安全管控措施是合法合规的基础。
经过了几个月的研发和测试，云趣科技于2021年9月28日发布了全新的数据库安全管控平台QueryX v4.0.0版本，它为异构数据库环境下的数据访问提供了一种全新的解决方案。我们将在下一篇文章中详细介绍其功能特性，敬请期待!
作者：森叔
简介：云趣科技产品负责人
出品：云趣科技
云趣 ，等您关注
