数据安全是企业级应用极为重要的保证，数据库安全更是数据安全中的重中之重。Win2003是微软第一个“缺省安全”产品，缺省情况下整个服务器是被锁定的，必须手动去激活一些你想要使用的服务。与Win2003一样，SQL Server 2005也是微软提供的第一个“缺省安全”的数据库系统，缺省安装情况下，安装程序为每个安装选项选择恰当的配置，使得一个新的SQL Server 2005安装结束时，默认处于一个安全的状态。虽然从总体安全模型上比较，SQL Server 2000与SQL Server 2005的安全机制是类似的，都是基于认证，授权与审核（SQL Server安全机制请参见文章：[url]http://alligator.blog.51cto.com/36993/111389[/url]）。但SQL Server 2005在访问控制，身份验证，加密以及权限粒度控制等多方面，都比SQL Server 2000有了长足的进步！本文就SQL Server 2005默认的安全配置选项，身份验证以及授权增强（Schema）等方面做相应的阐述，其它安全性增强，请参考SQL联机从书或MS网站。
一：安全配置增强
2002年1月，微软公司提出了“可信赖计算”计划，旨在提高安全性、私密性、可靠性和业务完整性。SQL Server 2005中引入一些安全改进和新的安全特性，以适应“可信赖计算”。在缺省安装情况下，SQL Server 2005默认将只会启用少数核心功能和服务，并且每个安装选项都选择恰当的配置，使得SQL Server 2005安装完成后，拥有一个最小的“攻击表面”。在SQL Server 2005中默认被禁用的服务和组件包括：.NET框架、Service Broker网络连接组件、分析服务的HTTP连接组件。其他一些服务，例如SQL Server代理、全文检索、新的数据转换（DTS）服务，被设置为手动启动。
同时SQL Server 2005提供了“外围应用配置器”工具，以更好的方便系统管理员对SQL Server进行安全的表面配置。我们通过实际的界面来认识和了解相关的设置和功能。
1：打开外围应用配置器工具。选择“所有程序”->"Microsoft SQL Server 2005"->"配置工具"->"SQL Server外围应用配置器“
2002年1月，微软公司提出了“可信赖计算”计划，旨在提高安全性、私密性、可靠性和业务完整性。SQL Server 2005中引入一些安全改进和新的安全特性，以适应“可信赖计算”。在缺省安装情况下，SQL Server 2005默认将只会启用少数核心功能和服务，并且每个安装选项都选择恰当的配置，使得SQL Server 2005安装完成后，拥有一个最小的“攻击表面”。在SQL Server 2005中默认被禁用的服务和组件包括：.NET框架、Service Broker网络连接组件、分析服务的HTTP连接组件。其他一些服务，例如SQL Server代理、全文检索、新的数据转换（DTS）服务，被设置为手动启动。
同时SQL Server 2005提供了“外围应用配置器”工具，以更好的方便系统管理员对SQL Server进行安全的表面配置。我们通过实际的界面来认识和了解相关的设置和功能。
1：打开外围应用配置器工具。选择“所有程序”->"Microsoft SQL Server 2005"->"配置工具"->"SQL Server外围应用配置器“
2：在打开的SQL Server外围应用配置器界面中，可以看到“外围应用配置器”工具将安全配置分为两种类型，分别是：基于功能的表面安全配置和基于服务和连接的表面安全配置。
其中：“功能的外围应用置器”应于启用或禁用数据库引擎、Analysis Services 和 Reporting Services 的功能。“服务和连接的外围应用配置器”应于启用或禁用 Windows 服务和远程连接。
3：选择具体的应用配置器，在应用配置器配置界面中，我们可以看到默认情况下，SQL Server 2005只开启了必须的服务和功能。同时我们可以在配置界面根据自己实际的需求，开启或关闭具体的服务和功能，查看和修改现有的安全配置选项，这里就不过多说明。
二：身份验证增强
SQL Server 2005在身份验证方面的增强主要有以下几个方面：
1：基于win2003操作系统上的帐号安全性策略。
在SQL Server 2000中，基于SQL登录的帐号是直接在SQL Server 2000中设置，无法使用安全策略,比如密码强度，过期时间等等。SQL Server 2005中改变了这种现状，在Windows Server 2003或以后的操作系统版本中,SQL Server 2005可以实现
强制登录帐户密码符合本地操作系统的密码策略，SQL Server用户和应用程序角色都可以使用帐号安全性策略，包括密码策略和帐户锁定策略。
SQL Server 2005在身份验证方面的增强主要有以下几个方面：
1：基于win2003操作系统上的帐号安全性策略。
在SQL Server 2000中，基于SQL登录的帐号是直接在SQL Server 2000中设置，无法使用安全策略,比如密码强度，过期时间等等。SQL Server 2005中改变了这种现状，在Windows Server 2003或以后的操作系统版本中,SQL Server 2005可以实现
强制登录帐户密码符合本地操作系统的密码策略，SQL Server用户和应用程序角色都可以使用帐号安全性策略，包括密码策略和帐户锁定策略。
2：基于其它操作系统上的标准SQL登录增强
在SQL Server 2000中，基于标准SQL登录的帐号在连接验证时，默认是使用明文方式在网络上传输验证凭证，存在验证凭证在网络上被捕获的可能性，带来安全隐患。为避免这种安全隐患，MS建议在SQL Server 2000中使用SSL加密通道进行身份验证。
SQL Server 2005默认对这种现状进行增强，对于标准的SQL登录,验证通道自动使用SQL Server服务器生成的证书进行加密，整个过程是透明的，不需要用户预先配置SSL证书。但这种增强仅适合于客户机与服务器都是SQL Server 2005，对于非SQL Server 2005客户机连接时，验证方式与SQL Server 2000类似。
在SQL Server 2000中，基于标准SQL登录的帐号在连接验证时，默认是使用明文方式在网络上传输验证凭证，存在验证凭证在网络上被捕获的可能性，带来安全隐患。为避免这种安全隐患，MS建议在SQL Server 2000中使用SSL加密通道进行身份验证。
SQL Server 2005默认对这种现状进行增强，对于标准的SQL登录,验证通道自动使用SQL Server服务器生成的证书进行加密，整个过程是透明的，不需要用户预先配置SSL证书。但这种增强仅适合于客户机与服务器都是SQL Server 2005，对于非SQL Server 2005客户机连接时，验证方式与SQL Server 2000类似。
3：基于端点的访问控制
不论是SQL Server 2000还是SQL Server 2005,都支持多种协议通信，默认提供的通信协议有如下四种：Shared Memory、Named Pipes、Tcp/IP、VIA,在SQL Server中对于实际的通信过程中，并不是直接配置通信协议，，MS对通信协议进行了进一步的封装，SQL Server 2000中，封装成Net Library，并支持配置参数配置,实现协议通信。SQL Server 2005中封装成SNI协议层,但SNI并不支持用户直接配置，而是通过“TDS 端点”对象进行通信。
不论是SQL Server 2000还是SQL Server 2005,都支持多种协议通信，默认提供的通信协议有如下四种：Shared Memory、Named Pipes、Tcp/IP、VIA,在SQL Server中对于实际的通信过程中，并不是直接配置通信协议，，MS对通信协议进行了进一步的封装，SQL Server 2000中，封装成Net Library，并支持配置参数配置,实现协议通信。SQL Server 2005中封装成SNI协议层,但SNI并不支持用户直接配置，而是通过“TDS 端点”对象进行通信。
TDS 端点是表示 SQL Server 与客户端之间通信点的SQL Server对象。SQL Server自动为SQL Server支持的四个协议分别创建一个端点。 我们可以这样来理解TDS端点：TDS端点实际是与通信协议相关，在实际的SQL Server 2005环境中中启用了什么样的通信协议，就有什么样的端点。
SQL Server 2005中，端点对象的具体位置如下：
在SQL Server 2000中，一旦启用了哪种通信协议，那么所有的登录名都可以通过该协议去连接SQL Server服务器,SQL Server 2005增强了基于端点的访问控制，针对具体的通信协议，可以授权不同的登录帐户是否可以连接。
具体的配置方法如下：
1：选择具体的登录名，右键属性，打开用户登录属性配置界面
具体的配置方法如下：
1：选择具体的登录名，右键属性，打开用户登录属性配置界面
2：在用户登录属性配置界面，选中"安全对象"，添加具体的安全对象.
3: 在添加对象弹出框选择“添加特定类型对象”
4：在对象类型弹出框选择“端点”
5：选择端点后，会列出当前所有的通信协议端点，并可以针对具体的端点授权该登录用户是否可以访问。
5：选择端点后，会列出当前所有的通信协议端点，并可以针对具体的端点授权该登录用户是否可以访问。
三：授权增强-理解架构
在SQL Server 2000中，授权级别基于三级模型，分别是服务器级别、数据库级别以及对象级别。在SQL Server 2005中，权限控制粒度细化，新增了架构级别的权限分配,实现了用户与架构的分离。模型细化成四级：分别是服务器级别，数据库级别、架构级别和对象级别。
在SQL Server 2000中，授权级别基于三级模型，分别是服务器级别、数据库级别以及对象级别。在SQL Server 2005中，权限控制粒度细化，新增了架构级别的权限分配,实现了用户与架构的分离。模型细化成四级：分别是服务器级别，数据库级别、架构级别和对象级别。
要正确理解架构这个概念，需要对比一下SQL Server 2000中所有权概念。
对于SQL Server 2000来说，所有权与创建用户是隐式绑定在一起的,一个对象的所有者就是对象创建者。
比如说User1创建了一个表tb_User1,那么这个表的所有者就是user1。
唯一的例外是dbo这个所有者，所有属于sysadmin角色中的用户创建的安全对象默认都是属于同一个所有者：dbo。
对于SQL Server 2000来说，所有权与创建用户是隐式绑定在一起的,一个对象的所有者就是对象创建者。
比如说User1创建了一个表tb_User1,那么这个表的所有者就是user1。
唯一的例外是dbo这个所有者，所有属于sysadmin角色中的用户创建的安全对象默认都是属于同一个所有者：dbo。
对于SQL Server 2000来说，完整的访问方式是：
服务器名.数据库名.所有者名.表名 (servername.databsename.owner.tablename).
如果是在同一个服务器和同一个数据库中，可以省略成：owner.tablename。
那么对于刚所说的表tb_user1,完整的访问方式应该是user1.tb_user1。
用户与所有者隐式绑定的方式会带来一些问题，考虑如下场景：
在一个实际应用程序中，大量使用到形如user1.tb_user1这样的访问对象方式。
某一天需要删除user1这个用户，但此时无法删除，系统会提示该用户拥有tb_user1这个表对象。可能的解决办法是将tb_user1表对象的所有者转移到其它用户后，再进行用户删除。但此时用户删除后，所有形如user1.tb_user1的访问对象方式就无法使用，必须手动去修改相应的访问代码。
服务器名.数据库名.所有者名.表名 (servername.databsename.owner.tablename).
如果是在同一个服务器和同一个数据库中，可以省略成：owner.tablename。
那么对于刚所说的表tb_user1,完整的访问方式应该是user1.tb_user1。
用户与所有者隐式绑定的方式会带来一些问题，考虑如下场景：
在一个实际应用程序中，大量使用到形如user1.tb_user1这样的访问对象方式。
某一天需要删除user1这个用户，但此时无法删除，系统会提示该用户拥有tb_user1这个表对象。可能的解决办法是将tb_user1表对象的所有者转移到其它用户后，再进行用户删除。但此时用户删除后，所有形如user1.tb_user1的访问对象方式就无法使用，必须手动去修改相应的访问代码。
为解决这种问题，在SQL Server 2005中，新增了架构对象，架构不隐式等效于数据库用户,而是将用户与架构的分离。MS对架构的解释是架构是数据库对象组织的名称空间，我们可以将架构理解成是存放安全对象的容器。SQL Server 2005中的所有安全对象都必须指定存放的具体架构。任何用户都必须指定存放其所拥有对象的架构，如果不指定，默认存放的架构是dbo。同时架构本身也是安全对象，可以针对架构进行授权。
在SQL Server 2005中，对于安全对象的完整的访问方式是:
服务器名.数据库名.架构名.对象名。
在SQL Server 2005中，对于安全对象的完整的访问方式是:
服务器名.数据库名.架构名.对象名。
下面以一个实际的演示来更好的说明架构的概念。
1：在Manager Studio中新建一个基于SQL登录的登录名：DBUser
2：新建一个数据库SchemaDemo
3：SchemaDemo数据库中新建用户DBUser,并选择对应的登录名是刚才创建的DBUser,并取消强制密码策略，其它设置不变。
4：在SchemaDemo数据库中授权DBUser用户拥有创建表权限。
方法是右击数据库Schema的属性选择权限，添加了DBUser用户，并给该用户赋予Create Table的权限
1：在Manager Studio中新建一个基于SQL登录的登录名：DBUser
2：新建一个数据库SchemaDemo
3：SchemaDemo数据库中新建用户DBUser,并选择对应的登录名是刚才创建的DBUser,并取消强制密码策略，其它设置不变。
4：在SchemaDemo数据库中授权DBUser用户拥有创建表权限。
方法是右击数据库Schema的属性选择权限，添加了DBUser用户，并给该用户赋予Create Table的权限
5：授权完成后，查看一下DBUser用户的基本属性：
默认架构是dbo,没有拥有的架构，也不属于任何数据库角色。
默认架构是dbo,没有拥有的架构，也不属于任何数据库角色。
6：用户创建完成后，以DBUser登录到SQL Server Manager Studio，在SchemaDemo数据库创建新表。
在弹出的对话框中忽略权限警告信息，按“确定”进入实际的建表，保存为
在弹出的对话框中忽略权限警告信息，按“确定”进入实际的建表，保存为
tb_User
7：在实际的保存过程中，我们会看到该表是无法保存，提示权限不够。
8：出现这种情况的原因是在创建DBUser用户时，没有指定该用户的默认架构。那么默认DBUser存放对象的架构是dbo,但实际上我们并没有授予DBUser用户在dbo架构存放对象的权限。解决的方法是授予DBUser向dbo架构存放对象的权限或者新建架构，并授予DBUser存放对象的权限。我们采用第2种方式继续演示。
9：新建架构db_SchemaDemo,架构所有者选择DBUser用户。
10：修改DBUser属性，指定DBUser默认架构为db_SchemaDemo。
11：再次以DBUser帐户登录，重复第6步操作，此时新建表tb_User成功,这时该表的名称是：db_SchemaDemo.tb_User，也就是架构名.表名的格式。
9：新建架构db_SchemaDemo,架构所有者选择DBUser用户。
10：修改DBUser属性，指定DBUser默认架构为db_SchemaDemo。
11：再次以DBUser帐户登录，重复第6步操作，此时新建表tb_User成功,这时该表的名称是：db_SchemaDemo.tb_User，也就是架构名.表名的格式。
12：至此，新建安全对象与架构的关系已经演示完毕，此时tb_user表的访问格式是db_SchemaDemo.tb_User。有兴趣的朋友可以试着将该架构的所有者转移给其它用户后，删除用户DBUser不会删除表tb_User,同时tb_User的访问方式仍然是db_Schema.tb_User。所以说，在SQL Server 2005中实现了架构与用户的分离。
四：SQL Server 2005安全性其它方面的增强
本文所阐述的安全性的增强只是整个SQL Server 2005安全性增强的一小部分，实际上在元数据保护，数据加密，审核，以及权限控制粒度等许多方面，SQL Server 2005都做了大量的改进。限于文章篇幅，本文不做太多阐述，请参考SQL联机从书或MS网站等相关资料。
本文所阐述的安全性的增强只是整个SQL Server 2005安全性增强的一小部分，实际上在元数据保护，数据加密，审核，以及权限控制粒度等许多方面，SQL Server 2005都做了大量的改进。限于文章篇幅，本文不做太多阐述，请参考SQL联机从书或MS网站等相关资料。
