安全的數據庫連接。 DAL .net架構最佳實踐

Question

我們有幾個應用程序安裝在通過Intranet與數據庫交互的幾個部門中。用戶傾向於使用弱密碼或將商店登錄/密碼寫在一張紙上，每個人都可以看到它們。我很擔心登錄/密碼泄漏&想要最小化後果。通過從Intranet訪問隱藏數據庫服務器來最小化數據庫服務器攻擊面也是一個好主意。

我想中介數據訪問服務方法爲基礎的安全性。它似乎比基於表或基於連接的數據庫服務器更靈活。這種方法還允許從公共Intranet隱藏數據庫服務器。

你會建議什麼樣的.NET技術和最佳實踐的？

謝謝你提前！

Answer 1

根據用戶對數據庫的訪問類型，你可能會尋找一個顯著一場艱苦的戰鬥。你開始對中介分層額外的安全性之前，通過採取長期在深入瞭解您允許用戶使用自己的憑據做什麼開始：

1. 用戶是否需要數據庫機器上的用戶帳戶？如果可能，刪除它們
2. 用戶是否授予最小權限訪問權限？使用您認爲合適的任何機制儘可能多地刪除用戶[exec]權利。我在最後看到的一件事是存儲了實際具有適當的執行權限的procs，並且用戶只對proc具有exec權限。
3. 您是否刪除了用戶權限來運行任何表更改命令？包括運行系統存儲過程的能力。這可以大幅減少事故（意外和惡意）
4. 用戶是否可以直接訪問原始業務數據？如果這樣考慮將訪問權限移入視圖，並在表格上自行刪除和刪除用戶權限。它也解決了一些維護難題
5. 你有審計嗎？表級別或自定義。

如果你覺得你有一個堅實的設計，那麼你可以開始尋找包裝你的數據庫在一個經紀人/外觀訪問。請注意，這在性能，部署和安全性方面可能很昂貴，並且不是一件容易的事情。關於模式的一些建議是：

1. 尋找到一個服務代理：WSO2例如，他們有其他可以用來隱藏關鍵業務應用程序（雖然其本意是要發佈對它們的訪問）提供緩存和代理服務。它可能會減少你的攻擊面，但配置和管理很容易超過那裏的任何收益。
2. 您可以推出自己的經紀商服務（基於WCF或類似的），以確保您充分考慮到負載和預計的增長，但如果您真的想要這樣做並非不可能或甚至無法實現並有時間正確地設計出來。

Answer 2

我不認爲有必要通過將其移動到外部網絡，以確保數據庫。相反，您可以通過限制帳戶本身的權限來解決這些問題。數據訪問不應該是用戶特定的，而應該利用系統帳戶以及在Web或應用配置文件中配置的加密連接字符串。

用戶認證和授權應與數據庫訪問分開處理。

系統DB帳戶本身應該只有權限執行操作系統所需的任務。這意味着只允許訪問應用程序執行的過程，並且可能讀取通過LINQ to SQL讀取的任何表或視圖的訪問權限。