我必须为大型数据库表提供数据完整性。因此，如果一个狡猾的管理员手动更改表（而不是通过UI），我希望能够检测到它。
我的想法是为每条记录设置HMAC，并在用户通过UI更改表时计算表的增量HMAC：
优点：
缺点：
有更好的方法吗？
答案 0 :(得分：4)
我发现这种方法存在许多问题：
如果您的sysdba可以访问所有数据，那么是什么阻止他们搞乱HMAC？例如：他们将上个月对表格的所有更改还原。然后他们从上个月撤回了HMAC。在这种情况下，数据完整性是“保留”吗？
是什么阻止他们破坏应用程序以破坏HMAC？例如：如果他们无权访问该应用程序，他们会更改用户的密码，并以该用户访问应用程序以查看记录。
即使你可以让它发挥作用，它有什么用呢？假设您发现HMAC不匹配。现在谁你有责任吗？管理员？一个用户？数据损坏？
更好的解决方案是使用审核。您可以在Oracle上设置各种审核，并将审核保存在某处，即使dba无法触及。此外，使用审计还有一个巨大的优势：您可以知道谁改变了什么。有了你的计划，你就不可能知道。
您甚至可以设置FGA (fine-grained auditing)，以便它只审核特定列，并且还知道更改前后的值，这是标准审核无法实现的。
答案 1 :(得分：2)
第一个问题是你不相信你的管理员。如果是这样，他们为什么还在那里？管理员需要prod数据库的完全权限，因此他们必须值得信赖。
如果问题是关于谁进行了更改，偶尔会有争议，那么请设置带触发器的审计表。值得信赖的管理员不会绕过触发器（即使他们可以）。只有管理员才能拥有对审计表的删除权限。
审计表是大多数企业系统的要求。如果您没有通过strored proc设置权限，很可能许多内部用户拥有直接影响数据库所需的权限，这使人们更容易进行欺诈行为。它可能不是影响数据的管理员。确保记录有关进行更改的用户以及记录更改的时间和信息。
SQL Server还可以审核数据库的结构更改。我不知道Oracle是否做得好，但这也是审计的一个方便。
答案 2 :(得分：0)
您的解决方案是否可以使用触发器？如果是这样，您可以Write Managed Triggers using C#，并为此代码添加所需的逻辑。
答案 3 :(得分：0)
这种“诚信”的方法并不是真正的诚信方法 - 这更像是安全拼凑。
因此，首先尝试用更好的安全模型来实现相同的目标。
如果您的方案，您必须计算，存储和检查HMAC。如果检查失败，则必须升级。
如果您正确设置安全性（几乎总是可能没有管理员需要对您的表进行直接写访问） - 那么您不必检查。
将尽可能多的业务逻辑移动到数据库将允许您创建可能是更改数据的唯一接口的存储过程，因此在这种情况下，您将保证完整性。