使用實體框架的行級安全

Question

我一直在考慮如何使用實體框架來實現行級安全。這個想法是有一個數據庫不可知的手段，將提供方法來限制來自ObjectContext的行。

我的一些初步想法涉及到修改由EDMGEN工具創建的部分類，並提供了一些有限的支持。用戶仍然可以通過使用自己的eSQL語句和QueryObject來解決這個問題。

我一直在尋找一種全面的解決方案，它將存在於數據庫提供者之上，以便它將保持不可知論的狀態。

Answer 1

當然你可以做到。要做的重要事情是阻止直接訪問對象上下文（阻止用戶構建自己的ObjectQuery），而是爲客戶提供一個更窄的網關，以便訪問和更改實體。我們用Entity Repository pattern來做。你可以找到一個example implementation of this pattern for the entity framework in this blog post。同樣，關鍵是阻止訪問對象上下文。請注意，對象上下文類是部分的。因此，您應該能夠防止「未經授權」的實例化方式，即在存儲庫程序集之外。

但是，有一些細微的考慮。如果您通過存儲庫模式對某個實體類型實施行級視圖安全性，那麼您必須考慮客戶機可以訪問相同實體的其他方式。例如，通過導航關係。您可能需要將這些關係中的某些關係設爲私有，您可以在模型中執行這些關係。您還可以選擇specifying a custom query或用於加載/保存實體的存儲過程。存儲過程通常是DB服務器特定的，但SQL可以用通用方式編寫。

儘管我不同意這不能用Entity Framework來完成，但我同意「在數據庫服務器上執行它」的意見，因爲您應該實施defense in depth。

Answer 2

您添加安全性的地方實際上取決於您試圖阻止的人。

例如，如果您正在保護網站，那麼在上下文級別添加過濾就足夠了，因爲這種情況下的「用戶」位於網站上。他們別無選擇，只能通過您的上下文，因爲您會完全針對上下文編寫應用程序。

就你而言，聽起來像你試圖抵禦的「用戶」是開發者。這比較困難。如果開發人員無法修改數據庫本身，則必須將安全性置於數據庫級別。不會有大量的eSQL訪問能夠繞過數據庫說「不」。

Answer 3

根據定義，您試圖達到的目標是不可能的。

如果安全性不是由底層數據庫應用程序（SQL Server，Oracle，或其他）明確處理的，那麼像SQL Management Studio這樣的標準工具就會超越它。

您可以做的最好的事情是僅當應用程序的用戶通過其他機制無法訪問數據庫時才強制執行行級安全性。

Answer 4

您可能會發現這篇文章有用：

http://msdn.microsoft.com/en-us/magazine/ff898427.aspx

「拒絕向實體框架表訪問，而不會引起兵變」

Answer 5

我找到了一種方法使用的是Postgres這樣做，並稱爲擴展Veil。它實際上適用於所有操作（選擇，更新，刪除，插入）並驗證WHERE子句中的權限使用Views。但面紗只是增加了數學，有效地管理內存中的權限信息，而不是每次都查詢它。因此，對於Veil，雖然您直接連接到DBMS，但您只有授予您的行級訪問權限。

我在某些方面用面紗修改了我的風格，例如，我開始使用Triggers而不是Views來應用權限限制。

我建議你學習這個解決方案，並嘗試在這裏應用它的邏輯。

即：你做了一個select * from table查詢，你得到你想要的（行級說話）。