提要 在SQL Server 2005內運行.NET框架代碼是一件令人激動的事情還是一種威脅？本系列文章將全面探討這類SQLCLR代碼的安全問題，以便開發人員和DBA都能夠有所借鑒。
一、引言
編寫運行於宿主在任何環境下的CLR中的.NET代碼的主要優點之一是代碼存取安全（CAS）。
CAS提供了一種基於代碼的而不是基於用戶的認證模式以預防各種代碼的入侵問題。但是，這種安全模式如何與SQL Server 2005自己的新的增強的安全特征共存呢？默認情況下，你的.NET代碼是比較安全的；但是，這兩種安全模式很容易發生沖突而且容易給你帶來一些問題。在本篇中，我們將簡短地分析CAS幕後有關概念和在SQL Server 2005中新引入的一些安全特征；然後，在後面的幾篇中分析如何實現在利用SQL Server所提供的高級可編程特征的同時，使這兩種系統協同工作。
好消息是，為了實現SQL Server所提供的安全系統和通用語言運行時刻庫協同工作，微軟已經提供了一定的工具來實現代碼控制。但是，也存在許多有趣的問題！
能夠用C#，VB或任何其它.NET語言編寫存儲過程及其它代碼模塊一直被長期期待，而這正是SQL Server 2005最激動人心的特征之一。開發人員和DBA最終都能夠沖破存在於擴展存儲過程的Transact-SQL（T-SQL）和C++中的羁絆，而用一種真正的具有高度生產力的語言編寫數據庫代碼！
同時，在數據庫服務器的內存空間中運行.NET代碼的前景嚇壞了某些人，尤其是一些負責保護數據完整性並且確保這些服務器晝夜運行的DBA們。運行一些開發人員的代碼（能夠完全存取.NET框架和Win32 API）的想法導致許多DBA堅持認為，對運行於服務器中的這樣的代碼進行維護根本超出他們的能力之外。
通過在會議上進行演講並進行大量培訓活動，以及我向同學和客戶提問"是否在服務器上的.NET代碼嚇壞了他們及其原因"。最終得到下面一些典型的備受關注的問題：
· 含糊的安全問題。其中大多數與當前正在出現的攻擊問題相關；但是，顯然，對有哪些新內容還不理解更為關注。
· 需要學習一種全新的技能來評定是否代碼是安全的。
· 在數據和代碼之間存在很多的模糊性，特別是對於使用.NET代碼創建用戶定義的類型這種新的能力。
· 還有另一種方式能夠實現代碼與服務器的"混合"，盡管OLE自動化（SP_OS*）和命令外殼系統(xp_cmdshell)存儲過程一直可用來讓人們運行外部代碼。
事實上，在SQL Server 2005中的.NET框架代碼，經常被稱作是SQLCLR代碼，因為它是基於.NET通用語言運行時刻庫（CLR）。其實，它僅僅是另一種存在和運行於SQL Server內部的代碼模塊而已。它是新東西，而且很酷，但是也仍只是代碼；但決不是T-SQL（仍然是首選的數據存取編碼實現方式）的插件代替品；而是，SQLCLR代碼為復雜的數據庫應用程序開創了全新的可能性。遲早大多數的DBA都會使用它並且將不得不做出最後的決定-是否讓它駐於數據庫中。
在本文中，我將探討人們對於SQLCLR代碼最關心的一個問題之一：其安全性如何？實際上，我將故意模糊兩種重要概念-安全性和可靠性。安全性意味著保持數據的安全，而可靠性意味著保持SQL Server的安全；可靠性經常被與安全性相混淆。因此，盡管我主要討論安全問題，但是我還要涉及到一定的可靠性問題。
我將假定，你熟悉在SQL Server 2005編寫.NET代碼的優點和基本知識。概括來說，包括下面這些內容：
· 程序集，作為打包、發布和版本管理的單元
· .NET代碼存取安全基礎
· SQL Server 2005的新的安全特征
換句話說，本文並不是一篇有關於SQLCLR代碼的入門性文章。
