在SQL Server 2014中優化程序集所需的權限

Question

由於IT設置權限太低，我有程序集無法執行。我需要設置什麼權限來允許我的程序集運行？它是否必須是CONTROL？

Answer 1

如註釋所示，您不執行任何CLR程序集。它們與文件系統隔離，並保持與SQL Server中的任何其他類型的對象一樣。

事實上，這就是CLR對象如此巧妙的原因。它們作爲任何其他函數，過程，表格存在，您希望操作。

現在，由於您在此論壇上發佈了有關權限的信息，請從數據庫管理員的角度理解CLR是自定義的，因此固有不安全。這很不安全，因爲在一天結束時，您的專業知識和知識深度是一個限制因素，並且超出了SQL Server正常預期的操作範圍。

CLR權限的最大因素取決於它是否需要來自SQL Server的外部資源。從安全角度來看，它是UNSAFE，期間。 CLR安全

注

• 三個因素有三個政策，確定您的安全級別：MACHINE，USER和HOST政策。

  確定授予程序集的權限是在三個不同的地方所定義的安全策略：

  計算機策略：這是在機上運行在其上安裝SQL Server的所有託管代碼影響的政策。

  用戶策略：這是對由進程託管的託管代碼有效的策略。對於SQL Server，用戶策略特定於運行SQL Server服務的Windows帳戶。

  主機策略：這是CLR主機（在本例中爲SQL Server）設置的策略，對於在該主機中運行的託管代碼有效。

  CLR Integration Code Access Security

  這些是分開的，更多的一個可能是，爲什麼你被剝奪了特權。

  • CLR CAS不再支持

  CLR在.NET Framework，它不再支持作爲一個安全邊界使用代碼訪問安全（CAS）。

  clr enabled configuration | Microsoft Docs

  • 可用選項

  1）請訪問無論是對你的團隊反正沒有任何變化，忽略瞭如何安全性改變任何警告。

  2）確定CLR實際對系統有什麼風險後請求訪問。

  3）將您的CLR更改爲在適當的安全級別下運行，同時仍支持CAS。

  4）請在這裏你封裝此對象的需求從正規，不合格的用戶，從而滿足適當的帳戶運行，您無須經常帳戶訪問的替代品。

  • 解釋和可能導致

  第一個選擇就是懶惰的人做的。不要懶惰。從他們的角度做一些研究，學習和理解你需要的東西。無論如何，這也許是不可行的。

  第二個選擇是基本上是這樣的：閱讀和了解什麼文件說，這樣你可以在你需要更有說服力。這對於你的開發團隊來說肯定是他們閱讀文檔所必需的。請參閱帖子末尾的鏈接。

  第三種選擇可能不是可行的，但也許是兩個步驟後/談話的DBA，你可能會確定CLR是反正制服。唯一的問題是，在SQL Server 2017之後，所有CLR代碼將被視爲UNSAFE，因爲微軟正在爲通常的安全性提供支持。 因此，如果這不會造成阻塞問題，相應地計劃。

  第四個選項意味着你能得到DBA使用的是從實際運行腳本的LOGIN/USER獨立的服務帳戶/合格用戶。封裝的優勢在於獲得您想要的，並且仍然保持您需要的高標準安全性。兩個缺點取決於CLR和您的需求，以及DBA如何幫助您開發正確的代碼。

  無論你是一位經驗豐富的老將CLR還是一個新人，該文件是真正的瞭解你或不應該問你的最佳途徑。

  來源

  • Overview of CLR Integration | Microsoft Docs

  • Introduction to SQL Server CLR Integration | Microsoft Docs

  必須閱讀開發商

  • CLR Integration Security | Microsoft Docs

  • CLR Integration Code Access Security | Microsoft Docs