分析SQLServer2005SQLCLR代码安全性

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

二、安全宿主SQLCLR代码

随着SQLCLR代码的引进，SQL Server 2005现在支撑两种完整不同的运行时刻环境：好的旧的可靠的T-SQL和新的正在发展中的SQLCLR。在过往的几年中，T-SQL随着SQL Server版本的不断升级而不断发展，并且与存储在一个数据库中的数据和对象紧密集成到一起，也与SQL Server中的安全系统良好地集成。相比之下，SQLCLR代码，在内部应用了一种由CLR所供给的完整不同的安全系统，这是一种"温热的"、安全的环境。在此环境下，代码的运行不是基于运行它的用户的安全资格而是基于代码本身的安全资格。同时，SQLCLR代码必需在数据库和服务器的安全范畴内履行；然而，这两种安全系统是基本不同的。如今，微软的SQL Sever开发小组已经研究出一种方法使得这二者共存并能够协同工作。

能够在另外一个利用程序中可靠地安全地宿主CLR是.NET框架2.0的一种新特点。这种宿主环境及其SQL Server实现，正是使得这两种安全系统和平共处的"机密"所在，由于宿主（在此是SQL Server）能够很大程度地把持运行的代码。这意味着，从一种安全角度来看，托管SQLCLR代码不被答应存取没有授权给它的数据库对象。该代码必需运行于用户会话的SQL Server安全高低文中，而且需要应用相干的与T-SQL代码雷同的允许权来激活它。

留心底线是，在一个数据库中，SQLCLR代码不能做比在雷同的安全高低文中等价的T-SQL代码模块更多的事情。

当设计怎样宿主CLR时，微软具有三个重要的设计目标：

·CLR及运行于其中的代码不能让步于SQL Server的安全性和稳固性。

·SQLCLR代码必需遵守SQL Server认证和授权规矩。这在必定程度上意味着，它要运行于用户会话的安全高低文中。

·系统治理员必需能够把持对把持系统资源的存取。这意味着，必需存在一种安全的方法来从SQL Server过程中存取机器资源。

这些目标的最明显的表现之一是，默认情况下，CLR集成是封闭的。假如你想在一个数据库中运行.NET代码，那么一个系统治理员必需把它打开。打开它的T-SQL代码需要应用sp_configure：

sp_configure 'clr enabled'，1
GO
RECONFIGURE
GO

当然，你还可以应用新的与SQL Server 2005一起安装的Su***ce Area配置工具来实现这一点，如图１所示。从Windows开端菜单下，选择"Microsoft SQL Server 2005→Configuration Tools→SQL Server Su***ce Area Configuration"，再选择"Su***ce Area Configuration for Features"，然后从列表下选择"CLR Integration"。

图1.Su***ce Area配置工具-该图展现了怎样应用Su***ce Area配置工具来启动SQLCLR。

因此，准确懂得开关CLR集成特点的含义是十分重要的；然而，它唯一影响的是，是否答应在存储过程、触发器、用户定义类型及用户定义函数中运行SQLCLR代码。假如它被禁用，那么，在该服务器实例中不会履行SQLCLR代码；假如它被启动，那么，任何CLR代码都可以履行（当然，假定用户拥有准确的履行权限）。假如它被禁用，它不会禁止你把SQLCLR程序集安装到数据库中。你可以安装所有你想应用的程序集（当然，假定你拥有这样做的属性允许权），但是它们在任何环境下都不会运行，直到你支撑CLR集成为止。

当SQLCLR代码履行时，它是在一个严格的安全环境中-这是一个既能保护把持系统资源又能保护SQL Server中的数据和对象的层。

图2.安全层：SQLCLR代码并非运行于一个安全真空中。

图2显示了这些安全层。把持系统强迫性应用它自己的把持-应用熟悉的用户和组模式以批准存取具有存取把持列表（ACL）的资源。在Windows中运行的每一个利用程序都需要运行于一个登录安全的高低文-它具有适当的允许权来进行资源存取。即使SQL Server也必需在这一框架内运作。