数据库审计技术进化

数据安全能力建设也紧紧围绕着数据这一关键要素的生存周期来展开，以此理念而诞生的DSMM框架逐渐成为主流建设规范。数据库作为数据的核心载体，其安全防护是重中之重，而数据库审计则是数据库安全防御体系的重要组成部分。本文将尝试从“以数据为中心”的角度来重新梳理数据库审计的技术进化方向。

数据库审计在gartner咨询机构2019年发布的安全产品超生存周期图谱中，与数据库加密等产品一起划到了成熟期产品里。作为一款指向性很强，基本不太容易走偏的安全产品，其发展路程经历了数据库日志审计、数据库流量审计、数据库业务审计与防护等多个阶段。在数据库安全防御矩阵中起到了核心角色作用，也是等保合规建设中的“基本款”。

数据库审计发展成熟，其作为单品已经完备而且基本满足客户需求，就如同20世纪初汤姆生说的，物理大厦已经建成，天空一片晴朗，只有那两朵乌云遮罩。在这两年的数据安全新的发展形势下，这两朵乌云逐渐放大、弥漫，我们从业人员已经不得不对其保持高度重视态度。

传统的数据库审计注重上行流量审计，关注用户做什么，怎么做。这不止是安全企业的实现思路问题，相关安全审计国标要求里也是大篇幅描述操作行为审计。在传统的网络安全中，注重操作的合规性，这可以理解，但是这一侧重点违背了以数据为中心的核心理念。我们以一个小偷入室偷窃为例子，备案重点记录小偷是否入室，用的什么工具，何时何地作案等行为，然后才关注小偷的作案金额数量。

如果基于数据安全的理念，备案应优先重点关注家里的物品是否损失，包括偷看，偷摸，偷盗，销毁等造成个人财产损失的资产信息。这种理念的差异会导致案情界定的不一致。对于数据库操作来说也是一样的，数据库审计可以轻易判断sql语句是否有危害，但是针对同一个操作语句，比如 “select * from AA;”，却缺乏判断依据，其本身从行为上看对数据库无害，但如果AA是存储用户帐号的表，那么执行这条语句就可能会引发一起敏感数据泄漏事故。

所以必须依靠查询的表对象和字段列表来判断，而这个偏业务的信息靠人工梳理，效率低且难以实现。在这种轻数据的设计思路下，难以发挥出数据库审计最佳的效果。

目前各家产品都实现了业务审计。所谓业务审计主要靠三层关联审计，从人-应用-数据库这三层的访问链路关联来进一步定位源访问信息。三层审计主要实现思路包括两大类。一种是基于web流量和数据库流量，从操作语句特征、访问时间戳等维度进行拟合。这种方式在并发量高的时候准确度低下，基本无法匹配上。另一种是基于agent方式，利用JAVA的特性，hook底层jdbc访问层，实现web信息和数据库信息的自动关联。通过将数据日志传输到数据库审计系统统一存储和展示。

这种实现方式精度高，基本无误报漏报，对于业务方也无需做网络改造和业务改造。但是需要在应用系统加载插件，共享一个进程，会带来一定的性能损耗和稳定性风险。用户对这一方法的接受度也不太高。所以目前虽然说三层关联，但是真正落地产生价值的并不多。

通过以上分析，我们总结了一些技术点，在数据安全时代，可以让数据库审计发挥更大的价值。

数据库审计下行流量带有大量的敏感信息。充分利用数据分类分级管理成果，建立一套成熟有效的更新机制，对访问敏感的数据库表、字段进行重点审计。建立一套依赖于AI能力的数据基线，从用户帐号、获取敏感数据量、执行时间段、流量等各个维度综合判断异常。由于现实中，存储能力有限，应该根据分类分级的字段列表，选择性的存储关键表、关键字段。

业务关联有利于提升整体的审计价值，追溯定位到真正的人。如前所述，两种主流实现方式都有自己的弊端。如果我们从数据自身出发，不再追求操作行为的一致性，那么问题似乎会好解决一些。比如：用户通过浏览器发起一个请求，返回了一串手机号列表，同时后台数据库也发生了一起查询事件，返回了一串手机号列表。通过判断二者数据的强关联性，自动将访问信息和数据库操作行为关联绑定，尽管二者在内部业务实现逻辑上是不一致的。不断的从二者返回数据中进行模式匹配，不再基于时间戳和访问特征的拟合，准确率会大大提高，真正的做到业务关联审计。

不管是自建大数据分析引擎、引入UEBA技术理念，进行用户行为分析，刻画用户画像还是将数据转发给第三方大数据分析平台，自身退化成流量探针，对于数据库审计来说，审计结果展示和利用智能化都不可避免。随着审计数据量的暴涨，传统的存储引擎不再适用，大数据分布式存储引擎正在大规模的引入。在数据安全背景下，数据库审计探针化、SDK化几乎不可避免。

数据库审计是一个成熟化很高的产品，短期内看不到具有挑战性的发展路线图。在数据安全治理背景下，需要主动适应，做一些改变，才能更好的发挥数据库安全价值。