防止SQL数据库中的数据欺诈和删除

时间:2016-11-16 22:40:06

标签: sql sql-server security fraud-prevention

我们为许多客户安装了一个应用程序。我们正在尝试收集将来发送给我们的信息。我们希望确保我们能够检测是否有任何数据被修改以及是否有任何数据被删除。

为防止数据被修改,我们当前对表行进行哈希处理,并使用数据发送哈希值。但是,我们正在努力检测数据是否已被删除。例如,如果我们在表中插入10条记录并散列每一行,则用户将无法修改记录而不会检测到它,但如果它们删除了所有记录,那么我们就无法将其与初始安装区分开来。

约束:

  • 客户端将拥有DB的管理员角色
  • 应用程序和数据库将位于DMZ后面,无法连接外部服务
  • 客户端将能够分析任何sql命令,并能够复制我们所做的任何初始设置。 (为了清除它们客户端也可以删除/重新创建表格)
  • 虽然客户端可以删除数据和表,但是在审计过程中,如果删除或删除了一些数据和表,这对我们来说是显而易见的,因为它们应该总是在积累数据,缺少数据或截断的数据会很突出。我们希望能够检测剩余表格中的删除和欺诈行为。
  • 我们假设客户端无法撤消我们的代码库或自己散列/加密数据
  • 客户将每月向我们发送所有收集的数据,系统将由我们每年审核一次。
  • 还要考虑他们的客户端可以将数据库的备份或VM的快照备份为“良好”状态,然后如果他们想要销毁数据则回滚到“良好”状态。我们不希望直接检测到vm快照或数据库备份回滚。

到目前为止,我们唯一的解决方案是加密安装日期(可以修改)和实例名称。然后每分钟“递增”加密数据。当我们向系统添加数据时,我们对数据行进行散列并将哈希值粘贴在加密数据中。然后继续“递增”数据。然后,当发送月度数据时,我们将能够看到他们是否正在删除数据并将数据库回滚到安装后,因为加密值不会有任何增量或者会有不属于的额外哈希值任何数据。

由于

2 个答案:

答案 0 :(得分:2)

你有没有看过Event Sourcing?如果性能足够好,那么这可以用于一次写入媒体作为辅助存储。这样即使对数据库或操作系统管理员也可以保证交易的完整性。我不确定使用真正的一次性媒体进行事件采购是否可行,并且仍能保持合理的性能。

答案 1 :(得分:1)

假设我们在您的代码中有一个md5()或类似的函数,并且您希望控制对表“table1”的“id”字段的修改。你可以这样做:

accumulatedIds = "secretkey-only-in-your-program";
for every record "record" in the table "table1"
  accumulatedIds = accumulatedIds + "." + record.id;

update hash_control set hash = md5(accumulatedIds) where table = "table1";

每次授权更改表“table1”的信息后。没有人注意到,没有人可以从这个系统中做出改变。

如果某人更改了某些ID,您会注意到因为哈希值不一样。

如果有人想要重新创建你的桌子,除非他重新创建完全相同的信息,否则他不能再次制作哈希,因为他不知道“只有密钥 - 在你的计划。”

如果有人删除记录,也可以发现它,因为“accumulationIds”不匹配。如果有人添加记录,则同样适用。

用户可以删除表hash_control下的记录,但是如果没有“secretkey ...”,他就无法正确重建哈希信息,所以你也会注意到。

我错过了什么?