数据库审计数据采集方案调研

2021-11-18 22:05:06

前言

在互联网，云计算，大数据快速发展的背景下，数据的规模也有了前所未有的增长，数据库在企业数据中几乎占有着核心地位。同时SQL注入，敏感操作，不规范使用等问题也一直伴随着数据库的使用，数据库安全也一直的数据库管理的重要工作，主要包括数据库漏扫，数据库加密，数据库防火墙，数据库脱敏，数据库安全审计等领域，本文将从数据库审计角度来介绍数据库审计的概念及审计数据的采集方案。

数据库审计是什么

先来看下百科对数据库审计的描述：

数据库审计（简称DBAudit）以安全事件为中心，以全面审计和精确审计为基础，实时记录网络上的数据库活动，对数据库操作进行细粒度审计的合规性管理，对数据库遭受到的风险行为进行实时告警。它通过对用户访问数据库行为的记录、分析和汇报，来帮助用户事后生成合规报告、事故追根溯源，同时通过大数据搜索技术提供高效查询审计报告，定位事件原因，以便日后查询、分析、过滤，实现加强内外部数据库网络行为的监控与审计，提高数据资产安全。

从描述可以看出来，数据库的审计是从安全角度出发，通过记录数据库的活动，发现数据库中潜在或者正在发生的危险，并进行实时的告警，同时还可以生成各类审计报告，定位事件根因。

一个数据库审计系统的工作流程可以概括为审计数据采集，审计报告生成，监控与告警，事后分析/故障定位等。下文主要调研审计过程的前半段，采集部分的技术。

数据库要审计什么

在审计中，经常会用到5W1H分析法，基本可以概括需要数据库审计的内容：

Who：数据库的使用者和访问者，甚至可以关联到业务系统中用户
Where：数据库的客户端信息，服务端信息，行为从哪个地方来，访问了哪个数据库。
When：访问数据库行为的时间
What：访问时操作对象是哪个表，哪行数据，返回了哪些数据，耗时多久。
How：执行的SQL语句或者其他命令，覆盖DDL，DML，Query，登录等活动。
Why：通过分析SQL语句，对于有危险的SQL及时分辨出来，了解访问动机。

一些审计的例子：

敏感信息泄露：比如用户姓名手机号等信息，通过对SQL的分析，识别返回结果中的敏感信息，及时告警。
业务人员误操作：可能在业务系统中使用了不规范的SQL，权限滥用等。
SQL注入：需要对SQL语句进行注入识别，并且找出是哪些用户在注入。

数据库审计采集实现方案

数据库审计通过对数据库的运行活动进行采集，然后进行风险分析，生成审计报告，告警通知等，审计数据的获取有多种方案，接下来主要对审计数据的采集方案进行调研。主要包括插件方案和旁路方案，每种方案各有优劣。总体而言，旁路方案比较适合作为成熟的数据库审计方案。

插件方案

插件是指在数据库中增加使用使用审计插件，往往需要依赖数据库本身的支持，例如对于MySQL为例，MySQL企业版提供了审计插件，社区版没有直接提供审计插件，插件列表如下：

MySQL Enterprice Audit Plugin（企业版）
Percona Audit Plugin（三方插件）
MariaDB Audit Plugin（三方插件）
McAfee MySQL Audit Plugin（三方插件）

一些云厂商内部也集成了三方插件，例如AWS RDS和京东云RDS都使用了MariaDB Audit Plugin，由此可以看出审计插件还是一定的市场。

优点

数据库原生支持，插件一般比较成熟，格式规整，利于分析。
实现简单，不需要过多的开发量，开箱即用。

挑战

数据库支持不全，比如社区版MySQL，不提供原生审计插件，需要自行安装，版本兼容性及维护等是一个挑战
由于插件是运行在数据库服务器进程中，对数据库性能会产生一定影响。
插件的安装一般由数据库管理员安装，并非审计人员可控，未起到职责分离的作用。
每种数据库的插件需要单独部署，在对多种数据库进行审计时，维护成本较高。

除了插件之外，还会有一些数据库内置方法来进行审计：

General Log：MySQL中开启General Log，会对MySQL的所有查询更新操作进行记录；可以对General Log进行分析，缺点是数据量访问量大的情况下，General Log会快速膨胀，并对数据库性能产生影响。
Binlog+init_connect：通过binlog来记录对数据库的操作信息，但是没有记录用户的登录信息，借助init_connect可以记录每个连接创建时的信息，结合两个信息可以进行数据库审计，缺点是binlog不会记录select信息，审计内容会产生一部分缺失，不能作为完整的审计方案。