2016-11-16 65 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的媒體,但不幸的是,我們無法對客戶強加基礎設施要求。 –