我有一个独特的问题要解决。我有一个遗留的Java应用程序，该应用程序连接到Oracle RDBMS。应用程序中散布着各种各样的查询和DML-插入，更新，删除，当然还有选择项。它使用JBC（Preparedstatement），尽管最近添加的一个小程序使用JPA。
我需要在应用程序/数据库中添加保护层/逻辑，如果有任何用户（甚至可能是DBA或OS根用户）试图绕过应用程序修改数据（更新，插入或删除），我们可以将操作标识为审核的一部分。
审计追踪似乎是这里的事，除了我们甚至不能信任操作系统的root用户，因此具有DBA和root访问权限的人可以轻松地修改数据并在审计追踪中删除其痕迹。
我曾考虑在敏感表上实施循环加密类型的算法，以便在应用程序执行的每个DML上都引入一个加密/哈希，并且它是增量式的，因此，通过使用申请。
理论上，似乎可行，除了它可能变得棘手，因为在每个DML之后，我们可能都需要重新计算许多后续记录的哈希/校验和，这可能会使应用程序/数据库超负荷。
这是可行的解决方案吗？
您是对的，计算每个更新的数据行的哈希将对系统造成负担。您是否还要在将更改提交到数据库之前验证哈希，以确保在应用程序外部未进行任何更改？这甚至会增加开销，并为您的应用程序提供更多自定义代码。这也不会帮助您确定谁修改了数据，或仅在应用程序外部对其进行了修改。使用数据库触发器是行不通的，因为它们很容易被禁用并且无法修改调用它们的同一表（您需要一个单独的哈希表，其中要包含每个表中每个数据行的条目监控）。审计仍然是您最好的方法，因为它不需要对您的应用程序或数据架构进行任何修改。
根据所使用的Oracle版本，您可以在审计方面有两个选择。如果您使用的是12c或更高版本，则可以使用Unified Auditing，它具有自己的一组权限和角色以允许职责分离（即，普通DBA与安全管理员）。即使在较旧的版本中，您也可以在实际的审计跟踪表上放置更新/删除审计，以便任何修改数据的尝试本身都会留下指纹。
最后，您可以使用Splunk，Elastic Search，syslog或Oracle的Database Audit Vault之类的工具或其他文件监视解决方案，将您的审计记录集中到数据库创建的另一个系统中，从而使DBA无法访问它们或本地系统管理员。首先，这将需要您的DBA和/或sysadmin进行一些配置工作，但是对于保护审核数据有很大帮助。
所有这些，迟早您要have信任两个人：sys admin和DBA。如果您不能信任他们，那么您将面临深重的麻烦。
Oracle 20c具有blockchain tables。当前仅在Oracle的云中提供版本20c，但可能会在几个月内在内部使用。