在大众眼中，数据库审计系统是数据安全领域的入门级产品。到处都是大工厂，大街小巷。
然而，在我看来，你只说对了一半。数据库审计是入门产品，是高级产品，也许是终极产品。
即使是最小的客户也敢拿它当垫脚石，即使不考虑其他保护措施，也要有所交代，有所追溯；大客户视数据库审计为试金石。数据库审核做的不好的厂商，其他防护产品的用户也不会有心情去调查；超大用户视数据库审计为杀手锏。可以作为风险监控和态势感知的预警机，也可以作为事件溯源和找责免责的最佳武器。
而且，随着海量数据日志的指数级增长，对数据库审计的处理规模、存储效率和查询分析性能的挑战将是前所未有的。......
因此，经过近20年的发展，数据库审计作为数据安全的门槛级别，已经是生生不息，在技术路线和产品定位上不断创新，从未停止，至今仍在继续。....
严肃地说，数据库审计系统的主要工作模式是完整地记录和监控数据库访问行为。一般采用bypass部署模式，通过镜像或探针收集所有数据库的访问流量，基于数据库协议和SQL语法及语义分析技术记录数据库的所有访问和操作行为，包括但不限于访问行为的来源信息、行为过程信息和结果信息，如访问数据的用户。运营、对象、结果有价值吗？当然啦！有四个原因:
1.法律合规
无论是国家法律还是标准，平等保险还是行业级安全标准，对使用数据库审计都有明确的要求，数据库审计是所有网络运营商必须建设的基础能力之一。
2.掌握流程
数据库作为数据资产的存储载体，其重要性不言而喻。对于这么重要的对象，需要知道谁在用，怎么用，什么时候用，用在哪里，用了什么基本信息。这些基本信息几乎是我们判断是否存在泄密、是否需要调整安全政策、是否需要问责的唯一支撑。审计系统的作用就是回答这些问题。可以说，没有数据库审计，数据安全的管理和建设将举步维艰。
3.风险警告
核心数据资产所在的数据库一定是最常被恶意者入侵的领地。它面临多种威胁，包括必须防止的外部入侵威胁和内部恶意行为。作为管理者，我们必须希望在数据库受到威胁时，能够尽快得到风险信息。如何实现？靠人力24小时监控数据库的所有访问行为几乎是不可能的。因此，借助工具，引入数据库审计产品是一种成熟的做法。数据库不仅可以识别风险，还可以发出警报，方便管理者和运维工程师及时处理风险。建立数据库审计系统。只要有针对数据库的恶意操作，无论是外部的还是内部的，数据库审计都能第一时间识别并报警，让管理者第一时间处理，可以有效减少甚至避免损失。因此，数据库审计是数据安全保护的必要环节。
4.事后追根溯源
道高一尺魔高一丈。已知的风险可以通过内置的规则和模型第一时间通知；而对于特别复杂的风险模型或新的安全攻击手段引发的安全事件，风险预警可能不及时或不能完全处理。这个时候，出了问题就需要回到源头。溯源的前提必须是基于完整的数据库访问日志，准确记录所有访问元素完整的SQL日志，这样数据库审计系统才能成为数据库溯源的小能手。
当然，几乎所有优秀产品的开发都是以用户需求为驱动，以技术环境为支撑，数据库审计也不例外。从最初的解决方案到智能分析，数据库审计至少经历了四代。可以说每一代产品的发展史就是用户需求的进化史。
第一代:解决有无的问题。
2003年前后的用户需求
无法专门审核数据库活动。
在过去的3-5年里，网络安全在中国发展迅速。除了网络防火墙、IPS等边界防护产品，网络审计系统也出现在旁路技术领域。用户现阶段关心的是数据库端是否有专门的旁路产品，可以记录访问行为的全量并给出风险提示。
众所周知，在Oracle、MySQL、SQLServer等大型数据库产品中。，都有自己的审计服务模块，有完整准确的记录SQL日志的能力。但是，数据库本身的审计受到其自身管理系统的限制。DBA用户可以根据需要随时停止审计服务，甚至在做坏事的时候停止审计，或者手动删除日志消除痕迹，不符合安全审计的第三方独立性原则；再加上自身和数据库服务器的本地部署，往往会消耗30%以上的性能。
面对这种需求，2003年左右，第一代国产数据库审计产品诞生了。其主要功能是监控数据库活动，变黑盒为白盒，变未知为已知，解决用户对数据库安全管理的焦虑。
这一代数据库审计产品其实就是简单的由网络审计转型而来。基于正则表达式匹配的数据库流量包审计技术可以解决这一问题，但它不能全面准确地审计数据库操作，尤其是复杂而长的语句，更不用说执行结果元素的信息了。
对于数据库审计，正则表达式是一种简单的通用字符串匹配方法，通常用于简单场景下的指定字符匹配。一旦面对超长、多层嵌套、多表关联等复杂的SQL语句，使用正则表达式很容易导致误识别或漏识别，更难以有效区分不同数据库品牌带来的差异。
第一代审计产品给人的总体印象是有记录基本SQL语句的能力，复杂类的操作往往不被审计。无法实现准确报警，无效报警和误报警频繁发生。第一代回顾整体生活状况:合规用户勉强使用，苛求用户不轻易使用。
第一次代数复习总成绩:●●◎χ；
第一代厂商数量:3家左右。
正是这种限制推动了数字产品的不断进化。
第二代:精度要求
2009年前后的用户需求
审核能不能更准确，不添乱？
第一代数据库审计投放市场并经过测试，各种性能问题逐渐暴露出来。产品服务商打补丁改进，使得产品日益成熟稳定。
但是产品稳定了，用户群也在扩大，审计日志不准确的问题也逐渐显露出来。漏审计、假审计、误报、误报警对于家长来说是常见的，导致用户基于审计日志对数据库活动做出错误的判断，从而误导安全事件的跟踪、追查和响应。
甚至有些评价，如果追责的时候有虚惊一场，把运营商A做的坏事审计成b做的坏事，不被审计总比不被审计好。其实不准的副作用太大了。
随着用户的不断反馈，产品厂商逐渐意识到第一代数据库审计在原理上存在一些缺陷，仅靠修修补补无法从根本上解决，必须推翻和重建产品设计。
2009年左右，厂商推出了第二代数据库审计系统，放弃了对第一代架构的重新设计，采用了基于数据库协议语法和语义的解析技术。这种解析技术采用精确的“翻译”方式，不受SQL语句长度或复杂度等因素的限制。能够准确定义每一条SQL语句，理解其真实含义，从而实现准确审计和报警。
让我们举一个例子来比较两个代数系统的区别:
假设用户设置规则是:查询表B的SQL操作定义为风险操作，第一代系统的正则表达式配置规则的思想是语句包含select和B的关键字，第二代系统是基于数据库协议的语法和语义:语句操作的最终执行意味着查询，动作表对象是表B，这时数据库收到一个访问请求:delete from a where a . rowid > from B where a . SnO = B . SnO)
如果通过正则表达式匹配SQL:发现语句包含select和B关键字，误判为有风险的操作——报警；通过语法和语义解析后，了解到该语句是一个删除操作，删除数据的条件是rowid大于某个值，并且该值是通过嵌套的sql查询语句得到的，因此准确判断为无风险操作——不会报警。
从上面的例子可以直观的看出两代审计产品的差距。第二代数据库审计技术帮助用户真正掌握完整准确的数据库活动。为数据库层违法恶意事件的准确判断、溯源和责任追究提供证据支持，避免误判。
随着第二代数据库审计系统的逐渐成熟，吸引了越来越多的用户，特别是等级保护的推广，引起了数据库审计产品的小热潮。但是，这个时候用户只愿意买，也敢买。真正使用的效果如何，事件能否快速追溯，突发事件的调查能否快速完成，没人太关注。因为这个时候高端场景没有出现，金融、电信等业务量大的企业用户还是没有出现。
第二代审计产品给人的整体印象是复杂的操作也能分析记录，准确率大大提高。但是，他们倾向于政府客户或中小企业。这些客户对等级保护政策的要求较高，对性能的要求往往不会太高。
二代回顾整体生存状况:合规用户大幅增加，需求用户基本愿意购买，高端用户暂时被忽视。
第二次代数复习总成绩:●●●◎
二代厂商数量:10家左右。
第三代:人类高质量要求的出现
2014年前后的用户需求
可以审计更多更久吗？
随着用户数据库访问规模的逐渐增大，审计系统单位时间所需的入库量迅速增加，存储的日志量也相应增加。这时候数据库审计记录的日志就可以用“海量”日志来形容了，在海量日志中高效检索就成了极大的挑战。此时，用户和厂商所面临的第二代数据库审计系统的性能瓶颈，已经无法支撑大型和超大型业务系统的审计需求。
尤其是高端行业，随着国家和政府对网络安全的重视，特别要求金融等关键基础信息行业在安全领域鼓励国产自主，给予国产安全软件最大的门槛开放。这彻底打开了数据库审计高性能演进的枷锁。但是，刚刚接触了这些高端行业的国内厂商，发现金融等高端用户并不在乎数据库审计，而是以5到10倍于国内品牌的价格，购买了国际上成熟的imperva等昂贵到离谱的数据库审计产品。
至此，国内数据库审计产品开始在性能上追逐国际大牌。一个是三年左右。直到2017年，在大银行、保险公司的重要业务系统中，真正能形成案例的只有国内厂商。
在突破高性能的阶段，国内厂商面临的实际挑战是相当大的。高性能意味着高仓储性能:二代审计产品的仓储性能只能达到10000 SQL/s左右，在持续高压的业务下延迟往往是几十分钟。但此时高端场景需求已经达到5-10万左右。查询要求高:二代审计产品的查询性能只能达到十亿日志，对应的查询速度为分钟，而此时高端场景的查询性能往往是十亿日志秒。一两个数量级的整体差异。存储效率:原来二代审计产品的单机存储容量一般是10亿日志，现在要提高到100亿日志。甚至在网络安全法颁布后，180天的日志存储容量一度让很多厂商的产品和RD的工程师泪流满面。...
最后，借助全文检索技术、列存储数据库技术、多进程并发等技术，一批优秀厂商得以完成高性能产品的突破。
在此期间，第三代数据库审计厂商确实经历了巨大的技术挑战。大浪淘沙，胜者为王败者为寇。在这期间，试生产厂家的数量增长最快，留下来的往往都是精品。
但近年来，数据规模的膨胀速度难以想象，用户不再满足于一台设备，只能审计几个数据库，而是几十个甚至几个数据库。到目前为止，很多高端用户的仓储需求已经提升到20万/秒的量级。单个审计设备的日志存量已经达到了数千亿的需求。
我不能再谈论它了。估计很多程序员坐不住了，想试试。
第三代审计产品给人的整体印象是性能大幅提升，已经可以满足政府、企业、教育、医疗等行业众多用户的海量日志检索性能需求。然而，在更高端的场景下，满足需求的高质量产品仍然不多见。第三代回顾整体生存状况:合规用户大幅增加，需求用户也大幅增加。有些厂商甚至依靠一款优秀的数码评论产品来解决生存问题。
第三代数复习总成绩:●●●●○
第三代厂商数量:30家左右。
第四代:智能需求2017年左右的用户需求能有什么带“今日头条”的智能数码产品就“审计”而言，第三代数据库审计系统基本够用。随着数据库审计成为保障数据安全的“刚需”，它扮演着越来越重要的角色。另外，随着数据资产的爆炸式增长，数据安全事件的几何级增长，用户必然对其提出更高的要求。用户的需求在近几年进一步升级:可托管数据库品牌的类型越来越多，从早期的国际主流Oracle到国内第三的数据库，甚至半结构化数据库和大数据等。可以自动识别数据库类型，而不是手动指定数据库IP和类型吗？因为有些用户经常使用几百个数据库，几千个数据库，甚至不知道账号数据库策略是否能给出智能配置建议，而不是完全打开关闭。很难知道用户有很多数据库，买了很多数据库审计设备，但审计的核心目标毕竟是敏感数据的行为。况且用户自己也不知道哪些数据库里有什么样的敏感数据，所以不接地气，浪费资源，也无法给出准确的指导。
这时候第三代产品的缺点是:第一，对数据库类型的支持非常被动，往往被用户牵着鼻子走；其次，它缺乏自动识别数据库类型的能力。很多数据库需要逐一指定IP和数据库类型，不仅不准确，还容易出现人工错误，害死客户或者厂家自己。第三，缺乏通过基线学习智能推送策略给用户的能力；第四，与敏感数据的位置没有真正的结合。
2017年，第四代数据库审计系统逐步开始研发，重点研发“智能发现”、“主动推送”等智能技术。第四代数采用机器自学习、基线自管理和数据分析技术。通过机器自学习、集群访问来源、操作行为特征和资产信息，全面掌握每个被访问数据库的基本情况，有效建立基线，形成高密度可信边界。当访问源发生变化或者访问源的操作行为发生变化时，可以自动伸缩基线，使用通用的轻量级策略轻松建立保护圈。劳动参与度大大降低，安全策略可以执行，核心功能如下:
资产梳理:对网络中的数据资产进行彻底梳理，形成数据台账；
评分:导入评分策略，对排序后的数据进行评分；
主动推送:通过掌握数据位置、数据级别、数据流向等信息，自动分析风险，主动推送防护策略建议，降低使用难度，提高安全效果；
发现数据库结构变化被持续监控，与安全保护策略形成联动调整。一旦保护目标的结构发生变化，保护策略也会随之变化，确保保护的针对性和保护效果始终处于正确的基线。
第四代审计产品给人的总体印象是聪明、智能，从手工劳动变成了真正的高科技。
第四代考察整体生活状况:生活体面，在苛刻的用户面前赢得尊重，量大价高。
第四代数考查总分:●●●●
第四代厂商数量:10家左右。
未来之路或者成为数据安全的神经网络联系人。技术的发展是无止境的，对安全的需求也是无止境的。只要威胁在进化，技术在创新，防御手段就需要进化甚至平衡。近年来，越来越多的用户不仅满足于对执行操作的精确审计，还将结果集的数据保存下来，以备日后取证和追溯。......
最近听说某银行单个业务系统的日志吞吐量已经达到30万/秒。......
还听说某保险公司的数据库数量已经超过3000个。......
还听说有些高端场景需要几千亿日志才能在几分钟内响应。.....
我们的大胆猜测是，在不久的将来，第四代数据库审计产品除了自身高智能、高性能的气质外，还可能成为数据安全集中管控和安全大数据分析的神经网络触点。核心安全能力全部交给平台产品统一调度、防御和分析，数据库审计作为数据和行为采集端，形成“树”和“根”的强关联结构。
此时，审计将不再是一个独立的系统，独立工作，而是为平台提供数据输入。这样可以结合KAFkA、FLUME、ELK等先进的大数据分析和流分析技术，真正解决数据规模非常大的日志利用问题，这也可能是未来数据安全的发展方向之一。我们拭目以待。随着用户需求的提升，也希望数据安全爱好者能够不断打破边界，向技术更深层次迈进。
