2016-03-11 58 views
2

我加入了一家基本上銷售一個網絡應用程序的小公司。 Web應用程序中的數據非常敏感,所有數據都是現場級加密的。應用程序使用ASP.NET Web API 2(C#)編寫,並帶有html/javascript front和SQL-Server。爲多個客戶組合數據庫 - 好主意?

目前,他們有大約50個客戶端,而應用程序的體系結構是每個客戶端都有自己的數據庫。它們都被部署到它們自己的IIS虛擬目錄中,然後指向它自己的DB。代碼在所有客戶端中完全相同。

業主告訴我,這是全部由安全設計。然而,這是一個絕對痛苦的管理,他們只能得到更多的客戶。

我建議將它全部組合到一個數據庫中,然後在主表上添加一個字段來標識數據屬於哪個客戶端。從這裏我可以過濾/加入該領域。

業主不喜歡這樣做,因爲它引入了一個風險:如果存在劣質代碼,一個客戶端可能能夠看到另一個客戶端數據。這顯然不能在多個數據庫中發生,因爲連接字符串不會跨越到不同的數據庫。

有沒有任何可能的方法來解決這個問題?我建議覆蓋授權類來阻止未經授權的用戶訪問信息,但這並不能解決整個「錯誤代碼」問題。

有什麼我可以做的,還是我堅持維護一大堆數據庫?

回答

3

當前設置也存在風險。如果有人在網站上混合數據庫連接字符串會怎麼樣?你將不得不確定哪個更危險。

如果您決定保留單獨的數據庫,聽起來像您需要投資自動化來幫助管理它們。我們使用數據庫項目來控制數據庫架構/腳本和MSDeploy,以將部署自動化到所有數據庫。也許這會增加你對多個數據庫的痛苦。

http://dotnetcatch.com/2016/02/10/deploying-a-database-project-with-msdeploy/

+0

單獨的數據庫還有助於與雲中的數據庫即服務進行隔離。自動化也是這個世界的關鍵。 –

+0

連接字符串是從虛擬目錄派生的,因爲數據庫名稱(初始目錄)與虛擬目錄中使用的相同。我們嘗試儘可能自動化(使用Web部署,更新等進行部署),但當出現問題時仍然很痛苦,目前我們只有50個客戶端,無法想象它是在500還是5000) – user3129594

3

我不認爲這裏是一個正確的或錯誤的答案在這裏,它是真正達到給定的公司(或它的所有者)的風險偏好。

連接字符串指向錯誤的數據庫似乎不太可能比編寫意外(或故意)從單個數據庫中提取其他公司數據的代碼。

單獨的數據庫體系結構除了安全性外,還提供了一個比共享數據庫更大的優勢:這是數據的恢復。如果您只需要恢復單個客戶端的數據,單獨的數據庫設計允許您以不影響其他客戶的方式執行此操作。在共享數據庫的情況下,任何恢復過程都會影響其他客戶端的服務。

在單獨的數據庫和共享數據庫之間可能存在一箇中間地帶:獨立的模式。如果您使用這種方法,單獨的模式仍然保持一定程度的分離,但您需要管理的數據庫實例少得多,因此服務可以更好地擴展。

MSDN上有一篇關於所有3個選項的文章:Multi-Tenant Data Architecture。 artice描述了所有3種場景的優缺點。

但是,請記住,所有這一切都取決於貴公司的主觀風險偏好!

+0

奇妙的文章。真的有幫助。您在數據恢復方面100%正確,在處理單個數據庫備份文件和加密表格時要容易得多。我忘記上面提到的一個問題是,我們目前每個客戶端都有用戶,如果用戶有權訪問應用的不同實例(因爲他們將有多個登錄名),但是我認爲這是不起作用的可以通過將用戶移動到共享數據庫並覆蓋授權類來解決。附:感謝修改上面的標籤。 – user3129594

相關問題