阿里二面：如何快速构建SQL数据库的审计系统？

本文要点

审计日志系统 有很多应用场景，而不仅仅是存储用于审计目的的数据。 除 了合规性和安全性的目的之外，它还能够被市场营销团队使用，以便于锁定目标用户，也可以用来生成重要的告警。

数据库内置的审计日志功能可能并不够用，要处理所有的用户场景，它肯定不是理想的方式。

目前，有很多的开源工具 ，如Maxwell’s Daemons、Debezium，它们能够以最少的基础设施和时间需求支持这些需求。

Maxwell’s daemons 能够读取 SQL bin 日志并发送事件到各种生产者，比如Kafka、Amazon Kinesis、SQS、Rabbit MQ等。

SQL 数据库生成的 bin 日志必须是基于 ROW 的格式，这样才能使整个环境运行起来。

假设你正在使用关系型数据来维护事务性数据并且你需要存储某些数据的审计跟踪信息，而这些数据本身是以表的形式存在的。如果你像大多数开发人员那样，那么最终所采用的方案可能如下所示：

1. 使用数据库的审计日志功能

大多数数据库都提供了插件来支持审计日志。这些插件可以很容易地安装和配置，以便于记录数据。但是，这种方式存在如下的问题：

1. 完整的审计日志插件一般只有企业级版本才提供。社区版可能会缺失这样的插件。以 MySQL 为例，审计日志插件只有企业版中才能使用。值得一提的是，MySQL 社区版的用户依然可以安装来自 MariaDB 或 Percona 的其他审计日志组件以绕过这个限制。
2. 数据库级别的审计日志会导致数据库服务器 10-20%的额外负载，正如该文和该文所讨论的。通常，对于高负载的系统，我们可能想要仅对较慢的查询启用审计日志，而不是针对所有的查询。
3. 审计日志会写入到日志文件中，数据不易于搜索。为了实现数据分析和审计的目的，我们可能想要审计数据能够遵循可搜索的格式。
4. 大量的审计归档文件会消耗非常重要的数据库存储，因为它们存储在与数据库相同的服务器上。

2. 使用应用程序来负责审计日志

要实现这一点，你可以采用如下的方案之一：

a.在更新现有的数据之前，复制现有的数据到另外一个表中，然后再更新当前表中的数据。

b.为数据添加一个版本号，然后每次更新都会插入一条已递增版本号的数据。

c.写入到两个数据库表中，其中一张表包含最新的数据，另外一张表包含审计跟踪信息。

作为设计可扩展系统的一项原则，我们必须要避免多次写入相同的数据，因为这不仅会降低系统的性能，还会引发各种数据不同步的问题。

那么企业为什么需要审计数据呢？

在开始介绍审计日志系统的架构之前，我们首先看一下各种组织对审计日志系统的一些需求。

1. 合规性和审计：审计人员需要从他们的角度出发，以有意义和相关的方式获取数据。数据库审计日志适用于 DBA 团队，但并不适合审计人员。
2. 对于任何大型软件来说，一个最基本的需求就是能够在遇到安全漏洞的时候生成重要的告警。审计日志可以用来实现这一点。
3. 你必须回答各种问题，比如谁访问了数据，数据在此之前的状态是什么，在更新的时候都修改了哪些内容以及内部用户是否滥用了权限等等。
4. 还有很重要的一点需要注意，因为审计跟踪信息能够有助于识别渗透者，这能够强化对“内部人员”的威