大型数据库表的数据完整性答案

【问题标题】：Data integrity for a large database table大型数据库表的数据完整性
【发布时间】：2011-09-13 09:00:47
【问题描述】：

我必须为大型数据库表提供数据完整性。因此，如果狡猾的管理员手动更改表（不是通过 UI），我希望能够检测到它。

我的想法是为每条记录设置 HMAC，并在用户通过 UI 更改表时计算表的增量 HMAC：

优点：

缺点：

有没有更好的方法？

【问题讨论】：

【解决方案1】：

我发现这种方法存在许多问题：

如果您的 sysdba 可以访问所有数据，那么是什么阻止它们与 HMAC 混淆？例如：他们恢复上个月对表格所做的所有更改。然后他们从上个月收回了 HMAC。在这种情况下是否“保留”了数据完整性？
是什么阻止了他们破坏应用程序来弄乱 HMAC？ eg：如果他们无权访问应用程序，他们会更改用户的密码，并以该用户的身份访问应用程序以弄乱记录。
即使你可以让它工作，它有什么好处？假设您发现 HMAC 不匹配。现在谁你要负责？管理员？用户？数据损坏？

更好的解决方案是使用审计。您可以在 Oracle 上设置各种审计，并将审计保存在 dba 无法触及的地方。此外，使用审计还有一个巨大的优势：您可以知道谁更改了什么。用你的方案，你不可能知道。

您甚至可以设置FGA (fine-grained auditing)，使其仅审核特定列，并知道更改前后的值是什么，这是标准审核无法实现的。

【讨论】：

【解决方案2】：

第一个问题是您不信任您的管理员。如果有，为什么他们还在那里？管理员需要对 prod 数据库的完全权限，因此他们必须值得信赖。

如果问题是偶尔会出现关于谁进行更改的争议，请设置带有触发器的审计表。值得信赖的管理员不会绕过触发器（即使他们可以）。只有管理员才应该拥有审计表的删除权限。

审计表是大多数企业系统的要求。如果您没有通过存储过程设置权限，很可能许多内部用户拥有直接影响数据库所需的权限，这使得人们更容易进行欺诈。影响数据的可能根本不是管理员。确保记录有关进行更改的用户以及更改时间以及记录更改的信息。

SQL Server 还可以审计对数据库的结构更改。我不知道 Oracle 是否也这样做，但这也是一个方便审计的事情。

【讨论】：

【解决方案3】：

触发器是否适用于您的解决方案？如果是这样，您可以Write Managed Triggers using C#，并为此代码添加您想要的任何逻辑。

【讨论】：

【解决方案4】：

这种“完整性”方法并不是真正的完整性方法 - 这更像是安全补丁。

因此，首先尝试使用更好的安全模型来完成同样的任务。

在您的情况下，您必须计算、存储和检查 HMAC。如果检查失败，您必须升级。

如果您正确设置了您的安全性（几乎总是有可能没有管理员需要对您的表进行直接写访问） - 那么您就不必检查了。

将尽可能多的业务逻辑移至数据库将允许您创建可能是更改数据的唯一接口的存储过程，因此在这种情况下您将获得完整性保证。

【讨论】：