2016-11-16 96 views
3

我们有一个应用程序安装在许多客户端的场所。我们正在努力收集将来发送给我们的信息。我们希望确保我们能够检测到我们的任何数据是否被修改以及是否有数据被删除。防止SQL数据库中的数据欺诈和删除

为了防止数据被修改,我们目前使用散列表行并将散列与数据一起发送。但是,我们正在努力检测数据是否已被删除。例如,如果我们在表中插入10条记录并散列每行,用户将无法修改记录,但是如果他们删除了所有记录,那么我们就无法将其与初始安装区分开来。

约束:

  • 客户有管理员角色DB
  • 应用程序和数据库将是后面的DMZ,将无法连接外部服务
  • 客户将能够配置文件的任何sql命令并能够复制我们所做的任何初始设置。 (以清除他们的客户也可以删除/重新创建表)
  • 虽然客户端可以删除数据和表,但是在审计过程中如果删除或删除对我们来说显而易见,那么他们应该始终在积累数据并且丢失数据或截断数据会很突出。我们希望能够在其余表格中检测到删除和欺诈行为。
  • 我们正在假设客户将无法逆转我们的代码库或散列/加密数据本身
  • 客户将向我们发送每月收集的所有数据,系统将由我们每年审核一次。
  • 还可以考虑他们的客户端可以将数据库的备份或虚拟机的快照恢复到“良好”状态,然后如果他们想销毁数据,则回滚到“良好”状态。我们不希望直接对vm快照或db备份进行任何检测。

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

感谢

回答

1

比方说,我们有一个MD5()或类似的功能在你的代码,你想保留表“表1”的“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,你会注意到,因为哈希将不会相同。

如果有人想重新创建表,除非他再现完全相同的信息,他woulnd't能够再次进行散列的,因为他不知道这个“秘密密钥只合你的 - 程序”。

如果有人删除了一条记录,它也可以被发现,因为“cumulativeIds”不匹配。如果有人添加一条记录,同样的情况也适用。

用户可以删除表hash_control下的记录,但是他不能在没有“secretkey ...”的情况下正确重构散列信息,因此您也会注意到这一点。

我在想什么?

+0

没有,因为如果他们放弃表格并重新创建它,那么数据将被清除,谢谢你的答案 –

+0

@DavidWork,我对答案做了重大改写。请检查出来。 –

+0

感谢您的更新。这绝对涵盖了我们希望检测的更多内容。我真正喜欢的一件事是,应用程序实际上可以删除记录并在hash_control表中重新创建散列,而不是仅执行软删除。我们也能够知道哪些/多少行被删除。 –

2

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

+0

事件采购可能是我们探索的一条路线。还有一些东西不会阻止,比如用户回滚说明他们认为有利于他们销毁/隐藏事件。或者,如果他们能够剔除事件并将系统置于不同的状态,这也会挫败目的,但我希望事件采购系统能够防止挑选樱桃或删除个人事件。似乎事件采购系统会阻止用户仅仅剔除事件采购系统必须解决许多我们现在正在尝试解决的相同问题 –

+0

@DavidWork这就是为什么我提到像一次写入媒体最简单情况下的DVD,在适当的时间间隔可以写入当前的事件快照。这样,没有人可以改变过去,最好的选择是摧毁媒体,但这是欺诈的证据。请注意,有专业级一次写入(WORM)介质。 –

+0

使用一次写入媒体肯定会帮助我们的情况。我与我们的团队讨论过我们是否可以使用基于WORM的媒体,但不幸的是,我们无法对客户强加基础设施要求。 –