提要 在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代码的入门性文章。

 1/2    1 2 下一页 尾页