我必须为大型数据库表提供数据完整性。因此，如果狡猾的管理员手动更改表（而不是通过 UI），我希望能够检测到它。
我的想法是为每条记录设置 HMAC，并在用户通过 UI 更改表时计算表的增量 HMAC：
优点：
缺点：
有更好的方法吗？
我发现这种方法存在许多问题：
如果您的 sysdba 可以访问所有数据，那么是什么阻止它们与 HMAC 混淆？例如：他们恢复上个月对表格所做的所有更改。然后他们从上个月收回了 HMAC。在这种情况下是否“保留”了数据完整性？
是什么阻止他们颠覆应用程序来弄乱 HMAC？例如：如果他们无权访问应用程序，他们会更改用户的密码，并以该用户身份访问应用程序以弄乱记录。
即使你可以让它工作，它有什么好处？假设您发现 HMAC 不匹配。现在你要对谁负责？管理员？用户？数据损坏？
更好的解决方案是使用审计。您可以在 Oracle 上设置各种审计，并将审计保存在 dba 无法触及的地方。此外，使用审计还有一个巨大的优势：您可以知道谁更改了什么。用你的方案，你不可能知道。
您甚至可以设置FGA（细粒度审计），以便它只审计特定列并且还知道更改之前和之后的值是什么，这是标准审计无法实现的。
参考：配置和管理审计
那么第一个问题是你不信任你的管理员。如果有，为什么他们还在那里？管理员需要对 prod 数据库的完全权限，因此他们必须值得信赖。
如果问题是偶尔会出现关于谁进行更改的争议，那么设置带有触发器的审计表。值得信赖的管理员不会绕过触发器（即使他们可以）。只有管理员才应该拥有审计表的删除权限。
审计表是大多数企业系统的要求。如果您没有通过存储过程设置权限，很可能许多内部用户拥有直接影响数据库所需的权限，这使得人们更容易进行欺诈。影响数据的可能根本不是管理员。确保记录有关进行更改的用户的信息以及更改的时间以及记录更改。
SQL Server 还可以审计对数据库的结构更改。我不知道 Oracle 是否也这样做，但这也是一个方便审计的事情。
这种“完整性”方法并不是真正的完整性方法——这更像是安全拼凑。
因此，首先尝试使用更好的安全模型来完成同样的任务。
在您的情况下，您必须计算、存储和检查 HMAC。如果检查失败，您必须升级。
如果您正确设置了安全性（几乎总是有可能没有管理员需要对您的表进行直接写访问） - 那么您不必检查。
将尽可能多的业务逻辑移至数据库将允许您创建可能是更改数据的唯一接口的存储过程，因此在这种情况下，您将获得完整性保证。
触发器是否适用于您的解决方案？如果是这样，您可以使用 C# 编写托管触发器，并为此代码添加您想要的任何逻辑。