SQL Server 2005 安全性增强

       数据安全是企业级应用极为重要的保证，数据库安全更是数据安全中的重中之重。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外围应用配置器“

       

    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用户和应用程序角色都可以使用帐号安全性策略，包括密码策略和帐户锁定策略。

　　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类似。       

　　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 端点”对象进行通信。

          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：选择具体的登录名，右键属性，打开用户登录属性配置界面

        

                2：在用户登录属性配置界面，选中"安全对象"，添加具体的安全对象.

                3:　在添加对象弹出框选择“添加特定类型对象”

                    

                 4：在对象类型弹出框选择“端点”
                 5：选择端点后，会列出当前所有的通信协议端点，并可以针对具体的端点授权该登录用户是否可以访问。

                   

 

三：授权增强-理解架构
    在SQL Server 2000中，授权级别基于三级模型，分别是服务器级别、数据库级别以及对象级别。在SQL Server 2005中，权限控制粒度细化，新增了架构级别的权限分配,实现了用户与架构的分离。模型细化成四级：分别是服务器级别，数据库级别、架构级别和对象级别。

    要正确理解架构这个概念，需要对比一下SQL Server 2000中所有权概念。
    对于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的访问对象方式就无法使用，必须手动去修改相应的访问代码。

　为解决这种问题，在SQL Server 2005中，新增了架构对象，架构不隐式等效于数据库用户,而是将用户与架构的分离。MS对架构的解释是架构是数据库对象组织的名称空间，我们可以将架构理解成是存放安全对象的容器。SQL Server 2005中的所有安全对象都必须指定存放的具体架构。任何用户都必须指定存放其所拥有对象的架构，如果不指定，默认存放的架构是dbo。同时架构本身也是安全对象，可以针对架构进行授权。
　在SQL Server 2005中，对于安全对象的完整的访问方式是:
    服务器名.数据库名.架构名.对象名。

   下面以一个实际的演示来更好的说明架构的概念。
　 1：在Manager Studio中新建一个基于SQL登录的登录名：DBUser
  　2：新建一个数据库SchemaDemo
      3：SchemaDemo数据库中新建用户DBUser,并选择对应的登录名是刚才创建的DBUser,并取消强制密码策略，其它设置不变。
　 4：在SchemaDemo数据库中授权DBUser用户拥有创建表权限。
           方法是右击数据库Schema的属性选择权限，添加了DBUser用户，并给该用户赋予Create Table的权限

           

       5：授权完成后，查看一下DBUser用户的基本属性：
　　　默认架构是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，也就是架构名.表名的格式。

        

          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网站等相关资料。

 

本文出自 “我儿子真帅!” 博客，转载请与作者联系！