在网格上审计数据库第 2 部分：部署后观察

在本系列的上一篇文章中，我谈到了我们如何收集这个项目的需求、我们如何决定使用什么工具以及如何规划部署以避免服务中断。 正如所承诺的那样，这篇后续文章的重点是部署后的观察以及哪些因素使这对我们来说是一个成功的故事。

准备好的语句和命令类过滤

我们对该项目的初始设计旨在利用 percona 插件中的一项功能，该功能可让您过滤发出的事件，以使用包含的命令列表或排除的命令列表来限制我们实际需要审核的范围。

该功能依赖于插件标记每个检测到的 sql 命令，该类基于 mysql 固有的列表，并从那里在输出层中决定检测到的命令类是否应该被抑制或发出。

因此，我们编写了初始蓝图以利用audit_log_exclude_commands功能来排除任何不会导致写入或更改行数据的 sql 命令。 我们选择排除列表是因为我们认为包含列表存在丢失任何范围内命令类的风险，并且可能成为我们的审计日志中存在空白的原因。

然而，在我们测试的第一个集群上，我们看到所有被审计的命令都被归类为错误，尽管很明显这些语句运行成功并且在更改数据的情况下也成功执行了该操作。 我们还看到，所有查询都被发送到集中式系统日志服务器，而不管该排除列表似乎与该错误分类相关。

这意味着我们在 elasticsearch 中存储的事件比我们实际需要的要多得多，这肯定会影响我们及时分析和检测错误行为的能力。 通过与安全团队的合作，我们决定通过他们的错误跟踪器将问题通知 Percona，但还将基于命令的过滤下移到中央 syslog 层。

就像工程中的所有事情一样，这里的权衡是通过 DB 网络层发送更多数据，并使集中式 syslog 层中的过滤更加复杂，作为回报，我们的弹性搜索扩展需求更易于管理，数据库端的配置更简单。

表现

这个项目中最重要的决定之一是决定使用 rsyslog 工具来捕获这些日志并将其发送到集中式 syslog 服务器。

但没有什么是没有优点和缺点的。

这一决定意味着单独系统的正常运行时间和中间网络堆栈的可靠性对于提供我们需要的 SLA 以使我们的审计团队对该审计解决方案充满信心变得至关重要。

对于那些不愿意做出妥协并需要在数据库堆栈中保持审计日志持久性的责任的人，我建议在审计插件中使用FILE处理程序，然后使用本地 logstash 获取日志并将它们转发到他们的分析系统选择。

后一种选择意味着更多的磁盘 IOP 从数据库进程中消耗并被审计插件和 logstash 占用，这意味着您必须在数据库表文件、操作日志和审计之间仔细平衡实例上的磁盘空间插件日志。 权衡你的选择完全取决于哪个更容易被企业操作/接受，但你仍然有选择。

在我们的案例中，rsyslog 的选择被证明对我们繁忙的数据库影响最小，峰值约为 5400 个事务/秒，在正常操作期间，我们发现对性能没有影响。 审计插件一直在运行，在不影响数据库性能的情况下发送其事件。 这一切都是因为我们选择了一种避免在数据库端使用基于磁盘的操作的架构。

过去的决定得到回报

当我们开始这个项目时，我们首先担心的问题之一是它对性能的影响。 范围内的一个数据库集群经历了非常繁忙的时间，它的应用程序对延迟很敏感，因此我们需要确保跟踪每秒事务数、磁盘和 CPU 利用率等性能指标，以便在部署插件后比较数字和看看惩罚是什么。

看到我们在正常操作中没有受到太多处罚，真是令人惊喜。 如前所述，因为我们决定使用 SYSLOG 处理程序，这意味着我们通常不需要使用任何本地磁盘容量来跟踪这些审计事件。

但我们也不想仅根据“正常运行”时间进行计划。

我们还需要知道，当 rsyslog 需要回退到本地假脱机文件时，这些事件不会复合到影响更关键数据库集群的服务中断中。 通过在生产环境的密切监视下测试 rsyslog 假脱机行为，我们意识到过去几年在功能上对我们的数据库进行分片的工作使我们获得了计划外的好处，即大量磁盘 IOP 容量来吸收诸如 rsyslog 假脱机到磁盘然后需要重新发送之类的事件所有这些事件。

我们肯定注意到这些事件期间磁盘利用率的增加，但它从未使数据库实例进入临界状态或影响面向客户的活动。

权衡取舍

就像软件工程中的所有事情一样，总是需要权衡取舍。 在这个项目中，我们考虑了一种更可靠且丢失日志的可能性较小的日志传递方法。 这将涉及将日志写入磁盘，然后使用类似 logstash 的东西来摄取并将它们发送到分析目的地以供安全团队使用。

但这将意味着数据库端的大量磁盘 IOP 消耗，我们知道这可能会影响面向客户调用这些数据库的服务质量。

我们决定通过在 rsyslog 中使用弹性日志记录、使用合理大小的假脱机以及使用 TCP 将事件发送到我们的日志监控堆栈来充分满足我们的业务需求。 就像生活中的一切一样，没有什么是永恒的。 我们知道，未来可能需要重新审视这一决定。

最后

这个项目虽然包含六个集群和大量实例，但在一个季度内就完成了，而 DB ops 团队仍在继续保持快速增长的业务。 如果没有 DBE 和安全团队之间的密切合作，并且没有强大的产品管理来保持范围有限和已知，以确保我们所有人都将目光投向使我们的业务更加安全的最终目标，这一切就不可能发生。