针对聪明管理员的SQL Server数据库安全？

我想保护存储在一个表中的事件，该表与其他表有关系。 事件通过windows服务插入，即连接到硬件并从硬件读取

事件表中有PK、日期和时间以及3个不同的值

问题是每个管理员都可以登录并插入/更新/删除此表中的数据，例如使用sql management studio。我创建触发器是为了防止更新和删除，所以如果管理员不知道触发器，他就无法更改数据，但如果他知道触发器，他可以轻松地禁用触发器并做任何他想做的事情

所以经过长时间的思考，我有一个想法，向表中添加新的列（字段），并在该字段中存储类似校验和的内容，该校验和将基于其他值进行计算。该校验和将在insert/update语句中生成。 如果有人手动插入/更新某些内容，我就会知道，因为如果我使用校验和检查数据，就会出现不匹配

我的问题是，如果你有类似的问题，你如何解决？ 校验和使用什么算法？如何防止delete语句（我知道PK中有空数字，但这还不够）

---

我使用的是SQL Server 2005。

通过隐蔽性实现安全是个坏主意。如果有计算校验和的公式，有人可以手工计算

---

如果您不能信任您的DB管理员，那么您会遇到更大的问题。

尝试锁定表上的权限可能会更有效。通过校验和，恶意用户似乎可以欺骗它，或者插入看似有效的数据

---

最终，即使管理员没有删除权限，他们也可以授予自己访问权限，更改为不拒绝删除，删除行，然后恢复权限，然后撤销其访问权限以进行权限更改

如果您正在审核，那么当他们给自己访问权限时，您就会解雇他们

---

就有效的防篡改校验和而言，可以使用公钥/私钥签名。这意味着，如果签名与消息匹配，那么除了记录中说创建/修改了记录的人之外，没有人可以这样做。任何人都可以使用自己的密钥更改和签名记录，但不能以其他人的身份进行更改和签名。

我只想指出，如果您担心人们修改数据，您也应该担心他们修改校验和

---

您不能简单地对该数据库的某些权限进行密码保护吗？

应用程序计算校验和的想法很好。我建议您研究消息身份验证码（MAC），以获得更安全的方法

简单地说，一些MAC算法（HMAC）使用哈希函数，并将密钥作为哈希输入的一部分。因此，即使管理员知道所使用的哈希函数，他也无法复制哈希，因为他不知道所有的输入

此外，在您的情况下，序列号应该是散列输入的一部分，以防止删除整个条目

---

理想情况下，应该使用SHA-2系列中的强加密哈希函数。MD5有已知的漏洞，在SHA-1中怀疑存在类似的问题。

管理员可以撤消您在服务器级别执行的任何操作。这就是它的角色定义，你无法阻止它

在SQL 2008中，您可以使用X事件请求对所述SQL server进行审核，请参阅。这是符合CC的解决方案，具有防篡改功能。这意味着管理员可以停止审核并执行其恶意操作，但审核的停止会被记录下来

在SQL 2005中，推荐的审核解决方案是使用。正确部署后，这可以使篡改变得明显。您将使用触发器和约束阻止数据更改，并审核DDL更改。如果管理员更改触发器，则在审核中可见。如果管理员停止审核，这在审核中也可见

您是否计划将此作为针对流氓管理员的一次性操作，或作为添加到产品中的功能？在应用程序周期内，使用数字签名对所有应用程序数据进行签名可能会非常昂贵。您还必须设计一个安全方案，以显示记录未被删除，包括最后的记录（即，标识列中没有简单的间隙）。您可以在应用程序中计算、签名结果，并在每次更新后存储每个表的签名值。也就是说，这将减慢应用程序的速度，因为基本上您将序列化每个操作。对于单行cheksums/hash，您必须计算应用程序中的整个签名，这可能需要应用程序尚未具有的值（即，要分配给insert的标识列值）。你想走多远？如果管理员掌握了你的应用程序并监视你的哈希值，以什么顺序进行哈希，那么一个简单的哈希值可能会被破坏（这很容易实现）。然后他可以重新计算相同的散列。HMAC要求您在应用程序中存储一个秘密，这对于一个决心坚定的黑客来说基本上是不可能的。这些担心似乎有些过分，但如果这是一个你出售的应用程序，那么一个黑客就可以破解你的哈希序列或hmac机密。谷歌最终会确保其他人都知道这件事

---

我的观点是，如果你试图通过技术来阻止管理员，你将面临一场失败的战斗。管理员是您信任的人，如果在您的案例中这一点被打破，那么问题在于信任，而不是技术。

由于管理员有权在您的SQL Server上执行所有操作，我建议您采用一种审计解决方案。在这种情况下，数据库或SQL Server实例上发生的一切都将被捕获并保存在存储库中。如果有权限的人（如管理员）修改或删除存储库中的已审核数据，则会报告该数据

就是这样一个解决方案，它有一个内置的整数