用于安全的 Oracle 增量校验和加密

Question

我有一个独特的问题要解决。 我有一个连接到 Oracle RDBMS 的遗留 Java 应用程序。应用程序中散布着各种查询和 DML——插入、更新、删除，当然还有选择。它使用 JBC (Preparedstatement)，不过最近添加的一个 lodule 使用 JPA。

我需要向应用程序/数据库添加保护层/逻辑，从而如果任何用户（甚至可能是 DBA 或操作系统 root 用户）试图绕过应用程序修改数据（更新、插入或删除） ，我们能够将操作识别为审计的一部分。

审计跟踪似乎是这里的首选，除了我们甚至不能信任操作系统 root 用户，因此拥有 DBA 和 root 访问权限的人可以轻松修改数据并在审计跟踪中删除它的踪迹。

我正在考虑在敏感表上实现一种循环加密算法，这样在应用程序执行的每个 DML 中，都会引入一个加密/哈希，并且它是增量的，以便通过使用审计轻松捕获任何更改应用程序。

理论上，这似乎是可行的，只是它可能会变得棘手，因为在每次 DML 之后，我们可能需要重新计算许多后续记录的哈希/校验和，这可能会使应用程序/数据库负担过重。

这是一个可行的解决方案吗？

Answer 1

您是对的，计算每个更新的数据行的哈希值会给系统带来负担。您是否还要在将更改提交到数据库之前验证该哈希以确保在应用程序之外没有任何更改？这甚至会产生更多开销，并且为您的应用程序提供更多自定义代码。它也无法帮助您识别谁修改了数据，或者何时修改了数据，只是它已在应用程序之外进行了更新。使用数据库触发器是行不通的，因为它们很容易被禁用并且无法修改调用它们的同一个表（您需要一个单独的哈希表，其中包含您想要的每个表中的每一行数据的条目监视器）。审核仍然是您的最佳选择，因为它不需要对您的应用或数据架构进行任何修改。

根据您使用的 Oracle 版本，您有几个关于审计的选项。如果您使用的是 12c 或更高版本，则可以使用统一审计，它有自己的一组权限和角色以允许职责分离（即来自安全管理员的普通 DBA）。即使在旧版本中，您也可以对实际的审计跟踪表进行更新/删除审计，这样任何修改数据的尝试都会留下指纹。

最后，您可以使用 Splunk、Elastic Search、syslog 或 Oracle 的 Database Audit Vault 或其他一些文件监控解决方案等工具将您的审计记录集中到另一个系统，因为它们是由数据库创建的 - 使他们无法访问DBA 或本地系统管理员。这将需要您的 DBA 和/或系统管理员首先进行配置，但对于保护您的审计数据大有帮助。

说了这么多，迟早你会不得不信任两个人：系统管理员和 DBA。如果你不能信任他们，那么你就陷入了深深的麻烦之中。

Answer 2

Oracle 20c 有blockchain tables。 20c 版目前仅在 Oracle 的云中提供，但可能会在几个月后在本地提供。