大众眼里，数据库审计系统已是数据安全领域的入门级产品。 大厂小厂皆有、大街小巷遍地。然而本人认为，大家只说对了一半，数据库审计既是入门产品，也是进阶产品，没准儿也是终极产品。

再小的客户也敢用它作为敲门砖，纵使其他防护手段都不考虑，也要出了事有交代、可追查；大客户则将数据库审计看做试金石，数据库审计都做不好的厂商，其他防护类产品用户也将没有心情考察；超大用户则将数据库审计看做杀手锏，它既可以作为风险监控、态势感知的预警机，也可以作为事件溯源、追责免责的不二利器。

况且，随着海量数据日志的年化指数级暴增，对数据库审计的处理规模、存储效能、查询分析性能挑战也将前所未有......因此，作为数据安全门槛级的数据库审计，历经近20年的发展，生生不息、层出不穷，技术路线和产品定位不断革新，从未停止，且仍在继续....

一本正经的说，数据库审计系统主要的工作模式对数据库访问行为进行完整的记录和监控，一般采用旁路部署方式，通过镜像或探针的方式采集所有数据库的访问流量，并基于数据库协议和SQL语法、语义的解析技术，记录下数据库的所有访问和操作行为，包括不限于访问行为的来源信息、行为过程信息、结果信息，如访问数据的用户（IP、账号、时间），操作（增、删、改、查）、对象（表、字段）、结果(成功与否、耗时、结果集）等等。

因此 ，数据库审计就像是数据库世界里的摄像头，不影响数据库的任何正常工作，还能记录下所有对数据库的访问行为，可用于事发后溯源或追查取证；也可以融入特定的分析规则和模型，在触发可疑风险的第一时间告警通知，让用户得以最大化挽回损失。

以今天的市场眼光看，数据库审计(以下简称"数审")是不是很有价值？当然！原因有四：

1、合法合规

无论是国家级的法律或标准，还是等保以及行业级的安全标准都对使用数据库审计有明确要求，所有网络运营者必须建设的基础能力之一。

2、掌握过程

数据库作为数据资产的存储载体，其重要性无需赘述。如此重要的对象，必须要掌握谁在用、怎么用、何时用、何地用、用了哪些基础信息。这些基础信息几乎是我们判断是否出现泄密事件、是否需要调整安全策略、是否要追责定则的唯一支撑。数据库审计系统发挥的作用就是回答以上这些追问。可以说，如果没有数据库审计，数据安全的管理和建设将举步维艰、寸步难行。

3、风险预警

核心数据资产所在的数据库，必定是恶意人员最频繁入侵的领地，它面临多重威胁，既有外部入侵威胁，又不得不防范层出不穷的内部恶意行为。身为管理者，一定希望在数据库受到威胁时能够第一时间获取风险信息。如何实现？靠人工24小时监控数据库的一切访问行为几乎难以实现，因此，借助工具的力量，引入数据库审计产品才是成熟的做法。数据库审计不仅备识别风险的能力，而且还可以发出告警，方便管理者和运维工程师及时处理风险。建立数据库审计体系，无论是外部还是内部只要出现了针对数据库的恶意操作，数据库审计就能够第一时间识别到并发出告警，让管理者第一时间进行处理，能够有效降低甚至避免损失。所以，数据库审计对于数据安全防护来说是必要一环。

4、事后溯源

道高一尺、魔高一丈。已知风险可以通过内置规则和模型，第一时间进行告警通知；但对于特别复杂的风险模型或新型安全攻击方法造成的安全事件，风险预警未必来得及或未必能全部处理。这时候，就需要出了事情，进行倒追溯源。溯源的前提一定是建立在完整的数据库访问日志的基础上，全量的、访问要素齐全的、准确的记录所有SQL日志，让数据库审计系统成为数据库溯源小能手。

当然，几乎所有优秀产品的发展都是由用户需求驱动和技术环境支撑的，数据库审计也不例外。从最初解决有无逐步发展到智能分析，数据库审计历经至少四代演进，可以说每一代产品的发展史就是用户的需求进化史。

第一代：解决有无|2003年前后用户需求-能不能专门审计数据库活动

此前的3-5年，网络安全在国内迅速发展。除了网络防火墙、IPS等边界防护产品，在旁路技术领域，网络审计系统已经崭露头脚。

用户此阶段的关注点在于：数据库端能不能有一类专门的旁路产品，能做到全量的访问行为记录，还能风险告警。

众所周知，在Oracle、MySQL、SQLServer等大型数据库产品中，均自带了审计服务模块，具备完整准确的记录SQL日志能力。然而、数据库自身的审计受限于自身的管理体系，DBA用户可根据需要随时停掉审计服务，干坏事时甚至可以不审计，或人工删除日志消除痕迹，不符合安全审计的第三方独立性原则；加之自身与数据库服务器本地部署，往往消耗30%以上性能。

面对这个需求，2003年左右国内第一代数据库审计产品诞生，主要功能设计为针对数据库活动行为的监控，变黑盒为白盒，变未知为已知，解决用户的数据库安全管理焦虑。

实际上，这一代的数据库审计产品是由网络审计简单变形而来，针对数据库的流量包进行基于正则表达式匹配的审计技术，解决的是有无问题，但无法对数据库操作全量、精准的审计，特别是复杂语句超长语句等等，更谈不上执行的结果类要素信息。

对于数据库审计来说，正则表达式是一种简易的通用字符串匹配方法，通常用于简单场景下对指定字符的匹配。一旦面对超长、多层嵌套、多表关联等复杂的SQL语句，使用正则表达式很容易造成误识别或漏识别，更无法有效区别数据库品牌不同导致的差异。正是这样的局限性，推动了数审产品的继续进化。

第二代：准确性需求|2009年前后用户需求-能否审计得更准一点、不添乱

第一代数据库审计推向市场并接受检验，各种性能问题逐渐暴露，产品服务提供商修修补补进行完善，使得产品日渐成熟稳定。

但产品稳定了，用户群同时也不断扩大，审计日志不准确的问题也逐渐显露出来，漏审、误审、漏报、误报现象成了家长便饭常见，导致用户基于审计日志所作的对数据库活动的判断常常是错的，从而误导了对安全事件的追踪、溯源和响应。

甚至某些评价，如果追查责任时误报，把操作者A干的坏事，审计成B干的。那与其这样，宁可审计不到。实际上，就是不准确的副作用太大了。

随着用户不断反馈，产品厂商逐渐意识到第一代数据库审计存在原理缺陷，仅靠修修补补无法从根本上解决问题，产品的设计必须推翻重建。

2009年前后，厂商推出第二代数据库审计系统，摒弃第一代架构重新设计，采用了基于数据库协议的语法、语义的解析技术。此种解析技术采用准确“翻译”的方式，不受限于SQL语句的长度或复杂度等因素，能够精确定义每一条SQL语句，准确理解其真正的含义，从而实现精准审计和告警。

让我们举例对比两代数审系统的差距：

假设用户设置规则为：对B表进行查询的SQL操作定义为风险操作，第一代系统的正则表达式配置规则思路是：语句中包含select、b关键字。第二代系统基于数据库协议的语法、语义的解析技术思路：语句操作的最终执行意思是查询（select），且作用表对象为b表。这时候，数据库接收到一条访问请求：DELETE FROM a WHERE a.rowid > (SELECT MIN(b.rowid) FROM b WHERE a.sno=b.sno)

若通过正则表达式匹配SQL后：发现该语句中包括select和b关键字，误判其为风险操作——进行告警；若通过语法、语义解析后：理解该语句为一个删除操作（delete），删除数据的条件是rowid大于某个值，而该值是通过嵌套的sql查询语句获得，因而准确判定其为非风险操作——不予告警。

从上述例子中可以直观的看到两代审计产品的差距，第二代数据库审计技术帮助用户真正掌握了完整且准确的数据库活动。为数据库层出现的违规、恶意事件提供了准确的判断、溯源和定责的证据支撑，避免了误判。

随着第二代数据库审计系统，逐渐成熟，揽住了越来越多的用户，特别是等级保护的助推，让数据库审计产品掀起一股小热潮。 然而这时候的用户只是愿意买、敢于买。真正的使用的效果如何，出了事件能不能快速溯源、能不能快速完成突发事件的排查并未有人太去关注。因为高端场景此时并未出现，金融、电信等业务量较大的企业用户仍未登场。

第三代：人类高质量要求登场|2014年前后用户需求-能否审计得更多、更久一点

随着用户数据库访问规模的逐步增加，需要审计系统单位时间内执行的入库量迅速增多，存储日志量也相应增加，此时，数据库审计记录的日志可以用“海量”日志来形容，在海量日志中高效检索就成为极大挑战。此时，摆在了用户和厂商面前的第二代数据库审计系统开始出现性能瓶颈问题，已经完全无法支撑对大型和超大型业务系统的审计需求。

尤其是高端行业，随着国家和政府对网络安全重视，特别要求金融等关键基础信息行业在安全领域鼓励国产自主，给予国产安全软件以最大的门槛开放度。这就给数据库审计的高性能演进彻底打开了枷锁。 然而，刚刚接触这些高端行业的国产厂商，发现，金融等高端用户其实不是不care数据库审计，而是早早就重金买了国际上成熟的imperva等贵的离谱的数据库审计产品，价格是国产品牌的5倍到10倍左右。

至此，国产数据库审计产品拉开了性能上追逐国际大牌的序幕。一做就是三年左右。直到2017年，才有国产厂商真正能在大银行、大保险公司的重要业务系统上形成案例。

在突破高性能阶段，实际摆在国内厂商面前的挑战是相当之大的。高性能意味着：(1)入库性能高：二代审计产品的入库性能往往只能达到1万条SQL/秒左右，且持续高压的业务下，延迟往往在几十分钟。 但此时高端场景的需求已经达到5-10万左右。（2）查询要求高：二代审计产品的查询性能往往只能达到亿级日志量，分钟级查询相应速度，而此时的高端场景查询性能往往是10亿级日志秒。 整整差了一到两个数量级。 (3) 存储效能: 原本二代审计产品的单机存储能力一般在10亿条日志，现在要提高到100亿日志，甚至网络安全法出了之后，180天的日志存储量一度让很多厂商的产品及研发工程师们泪崩...

最终，凭借全文检索技术、列存储数据库技术、多进程并发等技术，若干优秀的厂商，还是得以完成了高性能产品的突破。

第三代的数据库审计厂商，在此期间，真正经历了巨大的技术挑战。大浪淘沙，成王败寇。 此时期的数审厂商数量增加最快，留下来的往往是精品。

然而，近几年数据规模的膨胀速度快的令人难以想象，用户也不再满足于一个设备，只能审计几个数据库，而是几十个、甚至几个数据库。时至今日很多高端用户的入库量需求已经提至20万/秒的量级。单一审计设备的日志存量达到了千亿的需求。

不能再讲，估计很多程序员已经坐不住，想跃跃欲试了。

第四代：智能化需求|2017年前后用户需求-能否有“今日头条”款的聪明数审产品

单纯做“审计”来说，第三代数据库审计系统已经基本够用，随着数据库审计成为保障数据安全的“刚需”，其扮演的角色越来越重，加之数据资产暴增和数据安全事件几何级增长，用户必然对其提出更高要求。

用户需求这几年间进一步升级：(1) 管理的数据库品牌类型能否越来越多，早期的国际主流Oracle等老三家、到国产数据库老三家、甚至半结构化数据库、大数据等。（2）能否自动识别数据库类型，而非人工指定数据库IP和类型，因为有的用户动辄几百个库，上千个库，实在连自己都不清楚台账 (3) 数据库的策略能否给出智能的配置建议，而非全开全关，难以掌握 (4) 用户有很多数据库，买了很多数据库审计设备，但审计的核心目标毕竟是敏感数据的行为，况且用户自己都不清楚哪些库中有什么样的敏感数据，所以很不接地气，浪费资源还不能精准指导。

此时第三代产品的不足表现为：第一，对数据库类型的支持非常被动，往往被用户牵着走；第二，欠缺自动化识别数据库类型的能力，众多数据库需要一一指定IP和数据库类型，非但不准确还易手工出错、不是累死客户就是累死厂商自己； 第三，缺少通过基线学习智能地给用户推送策略的能力；第四，没有真正的与敏感数据的定位相结合。

2017年，第四代数据库审计系统逐渐开始研发，主攻“智能发现”、“主动推送”等智能技术方向。第四代数审采用机器自学习、基线自管理以及数据分析技术。通过机器自学，聚类访问来源、操作行为特征、资产信息，全面掌握每个数据库被访问的基础情况，有效建立基线，形成高密度可信边界。当访问来源发生变化或访问来源的操作行为发生变化时，自动伸缩基线，同时辅以通用型的轻量级策略，轻松建立防护圈。人工参与极大降低，安全策略可落地，核心功能如下：

资产梳理：深入梳理网络中的数据资产，形成数据台账；

分级打标：导入分级策略，对梳理出的数据进行分级打标；

主动推送：通过对数据位置、数据级别及数据流动等信息的掌握，自动分析风险并主动推送防护策略建议，降低使用难度，提高安全效果；

智能发现：持续监视数据库结构变化，与安全防护策略形成联动调整，一旦防护目标出现结构变化，防护策略会跟随变化，确保防护的针对性及防护效果始终处于正确基线。

未来的路-或成为数据安全的神经网络触点

技术的发展是无止境的，对安全的需求也没有尽头。只要威胁在演变，技术在革新，防御手段就需不断进化以至平衡。

近年越来越多的用户已经不仅仅满足对执行操作的精准审计，还要对结果集的数据进行保存用于日后取证追溯......

近日听闻某银行单一业务系统的日志吞吐量已达30万/秒量级......

又听说某保险公司的数据库数量已突破3000个......

还耳闻某些高端场景的数审分析能力要求是千亿级日志，分钟内响应.....

我们大胆的猜测，也许不久之后，第四代数据库审计产品，除了自身要具备高智能、高性能的气质之外，还可能成为数据安全集中管控和安全大数据分析的神经网络触点，所有安全防护核心能力交由平台型产品进行统一调度、防御和分析，而数据库审计作为数据和行为的采集端，形成“树”和“根”的强关联结构。

此时审计将不再是独立系统，不再独立工作，而是为平台提供数据的输入。这样更能与KAFkA、FLUME、ELK等先进的大数据分析和流式处理等分析技术结合，真正解决超大数据规模的日志利用问题，这可能也是未来的数据安全的发展方向之一，我们拭目以待。随着用户需求提升，也祝愿数据安全爱好者们能不断打破边界，大踏步朝技术更深处走去。

如若转载，请注明原文地址