防止审计表篡改答案

【问题标题】：Prevent audit table tampering防止审计表篡改
【发布时间】：2011-06-13 01:18:53
【问题描述】：

我们的数据库中有审计表。此表的记录是使用触发器完成的。

目前，没有什么可以阻止用户登录数据库服务器、从管理工作室打开表和更改审计表中的数据。

有哪些可能的机制可以防止（或至少检测）审计数据篡改？

我正在考虑在审计表中添加一列，该列应包含一些根据在该行中输入的值计算的哈希值。但是，由于审计是使用触发器完成的，恶意用户可以打开任何触发器并查看计算此哈希的逻辑。

编辑：

我还不够清楚。应用程序用户无权访问数据库。我指的是像 DB admin 这样的用户，对数据库具有适当的权限。不过，如果这个数据库管理员登录并有权修改审计表，我希望至少有一些机制来检测这种篡改。

【问题讨论】：

不给恶意用户对该表的写入权限怎么样？或者，如果您偏执，请将日志发送到很少有人可以访问的另一台计算机，而不是使用数据库中的表。
只需限制权限，以便只有某些登录名具有对该表的插入/更新/删除权限。
如果他们以系统管理员身份显式或隐式登录（例如以管理员身份登录 Windows），则只能使用 Management Studio 绕过权限。强大的 SQL 安全性取决于良好的网络安全习惯。

【解决方案1】：

没有什么可以阻止通过 SQL 管理器访问您的数据库的人更改内容。不过，您可以使其防篡改。

基本上你需要使用HMACs，它们是键控哈希。不幸的是，这导致您需要密钥管理以确保密钥保持机密，这在触发器中可能是不可能的。我们使用加密服务来提供密钥管理，但这是通过代码访问的。

您还需要考虑用户删除记录而不是更改其内容的能力。我们最终得到了两个 HMAC，一个使用记录的内容计算（使对记录的更改明显），第二个使用当前记录 HMAC 和上一行中的 HMAC 来使任何行删除篡改明显。

然后您需要担心删除第一条或最后一条 x 记录。为此，我们使用始终具有相同内容的尾部和标题记录，如果不存在，则表的顶部或底部已被删除。头部的组合 HMAC 使用它之后的记录而不是之前的记录（因为之前没有记录）。

当然，如果您要删除旧记录来管理存储的数据量，您需要一种机制来在删除后添加新的标头记录。

【讨论】：

这在我看来很复杂但几乎是防弹的概念:)。您是通过代码还是通过触发器进行审计？我假设您正在从代码中进行审核。如果你这样做了，那么没有什么可以阻止用户更改您正在从代码审计的某个表中的数据，这将不会在您的审计表中留下任何证据，对吧？
我们从代码审计。它不能从服务器上运行的代码（即我们编写的代码）更改，尽管如果攻击者能够在服务器上运行任意代码并了解如何访问加密服务等，他们可以将他们喜欢的内容写入审计表。当然，如果攻击者拥有对服务器的这种级别的访问权限并花时间在审核表上乱搞，他们将浪费宝贵的机会从我们那里窃取数据......
是的，确实:)。谢谢你的回答，很有帮助。
"没有什么可以阻止通过 SQL 管理器访问您的数据库的人更改内容。"仅当他们以系统管理员身份登录 SQL Management Studio 时才适用。虽然这是典型的，但不是必需的。如果他们的登录拒绝他们访问该对象，则通过 SQL Management Studio 进行连接不会给他们额外的访问权限。
很好的答案，谢谢。谁能澄清如何计算第一行的哈希？

【解决方案2】：

这里有一些可能性：

您无法阻止或检测具有 sysadmin (sa) 权限的人的篡改。如果您不信任您的系统管理员，您可能会遇到比这个特定问题更严重的问题。
很难防止或检测域或本地管理员的篡改。这样的人可以在单用户模式下重新启动 SQL Server，并使用 SQL 以系统管理员的身份获得访问权限。
要检测数据库所有者 (dbo) 的篡改，您可以在SQL Server 2008 中使用Server Audit，或者在SQL Server 的早期版本中使用服务器端SQL Trace。
您可以通过限制其他用户对相关触发器和审计表的权限来防止他们篡改。

【讨论】：

【解决方案3】：

您可以启用更改跟踪，这样您就有了一种“审计表上的审计”。

如果您的基础架构得到妥善管理，我猜用户没有 sa 权限，他们使用 Management Studio 查看使用其 Windows 帐户登录的数据库，在这种情况下，您可以在该审计表上设置安全性，只有 sa 和其他管理帐户将能够更改内容，但不能更改普通用户/开发者帐户。

希望这会有所帮助。

【讨论】：

【解决方案4】：

您所描述的问题可能表明您的系统架构中存在更严重的问题。通常，用户甚至不应该直接访问运行数据库的机器。

您可能需要考虑一种架构，其中数据库机器与您的业务逻辑机器分离，并且只有它们可以访问。

如果您的用户决定尝试不通过您的客户端访问您的服务器，那么他们所能做的就是访问您决定公开的定义明确的 Web 服务。

没有理由让用户能够访问数据库机器，或者拥有允许写入数据库的帐户的凭据。您似乎担心篡改审计信息。如何阻止恶意用户删除表或篡改功能数据？

【讨论】：

【解决方案5】：

将审计数据分离到自己的架构中，然后设置权限，使您关注的用户无权访问该架构。
使用完全独立的数据库，甚至可以在不同的机器上。

我经常看到某种发布/订阅模型用于从关系数据库发布审计数据，然后将该审计数据异步写入审计存储。

也许您可以让触发器将审计数据写入队列。然后，您可以安排一个每隔几分钟运行一次的计划作业，以从队列中获取审核数据并将其写入您的审核存储。

【讨论】：