有效的审计途径

Question

我正在尝试为我的spring引导应用程序实现一个审计层，到目前为止我尝试了两种方法。

1)创建了一个具有字段user_name、table_name、column_name、old_value、new_value、uuid、event_type的审计表。

每当保存任何更改时，都要填充审核实体并保存它。

优势：

• quick
• easy要管理，因为只有一个审计表

跌落：

• 有时涉及太多从业务实体到审计实体
• 的映射，必须从db获取旧值才能填充审计实体
• 手动创建审计
• 可以是一个痛苦的

。

2)使用javers进行审计

优势：

• 自动创建和更新审计实体
• 管理
• 旧值检索的少表不需要

跌落：

• 所花费的时间太长，因为交易的规模很大，

基准测试

处理包含20列(字段)的表(实体)中的10行

使用方法1: 24328 ms => 24 s的时间

使用方法2的时间: 311292 ms => 311 s(近12次)

3)没有与Hibernate envers一起使用，因为创建的表数量很高

有谁能提出一个更好的审计意见与上述利弊。我们的目标是，

• 减少了管理
• 的表数，减少了
• 模块审计层的响应时间，这比手动

更自动化。

每个表中有10至25列。

Answer 1

正如您所说，创建审计跟踪的常用方法是应用程序端库，如envers或Javer。这些类链接到持久性库，它们将在数据表("createdBy“、"lastUpdated”等)中维护特定的列，并/或将早期的记录版本复制到某种形式的历史表中。

但是，这也有一些缺点：

作为OLTP事务的一部分，在历史表中写入记录的application

• support

• 会增加事务->中执行的语句的数量，这可能会导致大容量更新的响应时间更长，并且无法跟踪直接在数据库中执行的

。

按三个步骤更改数据捕获

upload

• Upload

1. 捕获更改数据
2. 将数据转换为目标数据库支持的格式--将数据转换为目标数据库

通过数据库触发器更改数据捕获

另一种技术是数据库触发器。无论是从应用程序还是数据库本身发出，它们都不会错过任何操作。Bulk语句也将被处理。基于触发器的CDC的另一个优点是应用程序始终不知道您已经添加了整个审计层。缺点是，在作为OLTP事务的一部分执行触发器时，仍然存在延迟增加的问题。

触发器的替代解决方案(这里是Postgresql)：使用WAL将数据库更改(已解码的WAL消息)从主服务器流到从服务器，并启用审核触发器来捕获对从服务器上复制的表的更改。

通过基于日志的方法更改数据捕获

当利用transaction log作为审计源并使用变更数据捕获来检索更改信息并将其发送到消息代理或基于持久日志的Apache Kafka中时，上述问题并不存在。通常被认为是更改数据捕获的高级方法，但并不是最简单的设置解决方案。

CDC进程异步运行，可以在不影响OLTP事务的情况下提取更改数据。

无论何时发生数据更改，都会将条目添加到事务日志中。

在大容量操作中，每个记录都会有一个日志条目更新或删除，因此可以为每个记录生成一个更改事件。

仍然存在的问题是CDC如何像执行数据更改的应用程序用户那样访问元数据、它们的IP地址、跟踪span或任何类型的correlationID。

一种方法是有一个单独的表来存储这些元数据。应用程序可以为每个事务存储一个带有特定transactionId的表中的记录。数据更改事件将包含链接到更改的transactionID，因此数据更改事件和元数据记录可以这样关联。

Answer 2

我会采取这样的做法：

1)低优先级后台线程中的审计

2)使用spring与注释分离BU和审计。

3)每次插入或更新实体时，都使用UID在NOSQL数据库文档中写入完整的jsonized对象；此外，旧值也没有用，因为您可以追溯运行简单查询的实体上的更改。

Answer 3

显然你没有正确地使用Javer，你的数字是不可靠的。也许您正在为每个提交创建新的Javer实例？

Javer的速度和审计工具一样快。Javer只需为更改的对象创建快照并将其插入DB。每个快照一个DB记录/文档。

因此，如果您更改了一个对象，通常Javer会执行一个DB read来获取它的前一个快照，并执行一个DB insert来编写新的快照。