导言

随着越来越多的网络相互连接，安全性也变得日益重要。公司的资产必须受到保护，尤其是数据库，它们存储着公司的宝贵信息。安全是数据引擎的关键特性之一，保护企业免受各种威胁。Microsoft® SQL Server™ 2008 安全特性的宗旨是使其更加安全，且使数据保护人员能够更方便地使用和理解安全。
在过去几年中，世界各地的人们对于安全的、基于计算机的系统有了更深刻的理解。Microsoft 在此过程中一直处于前沿，而 SQL Server 就是落实这种理解的首批产品之一。它实现了重要的“最少特权”原则，因此不必授予用户超出工作所需的权限。它提供了深层次的防御工具，可以采取措施防御最危险黑客的攻击。
关于Microsoft 首创的Trustworthy Computing技术，已经有了很多文献和讨论，它可指导公司的所有软件开发。有关更多信息，请参阅 Trustworthy Computing 网站：（http://www.microsoft.com/mscorp/twc/default.mspx）。
该首创技术的4个核心组件为：
·         Secure by design。作为抵御黑客及保护数据的基础，软件需要进行安全设计。
·         Secure by default。系统管理员不必操心新安装的安全，默认设置即可保证。
·         Secure in deployment。软件自身应能更新最新的安全补丁，并能协助维护。
·         Communications。交流最佳实践和不断发展的威胁信息，以使管理员能够主动地保护系统。
这些指导准则在 SQL Server 2008 中均得到了体现，它提供了保护数据库所需的所有工具。
本文介绍了系统和数据库管理员需要掌握的最重要的安全特性。首先介绍如何安全地安装和配置 SQL Server 2008。它讨论了验证和授权特性，这些特性用以控制对服务器的访问，并规定用户一旦通过验证就可以执行的操作。最后介绍管理员需要理解的数据库安全特性，以便为数据库以及访问这些数据库的应用程序提供安全的环境。

安全配置

要安全地安装 SQL Server，必须有一个安全的环境。对于运行 SQL Server 2008 的服务器，其外部安全要求没有太多改变。需要保护服务器的物理安全，并要定期备份数据，如果联网，还须将其放到一个或多个防火墙后面，避免在运行其他服务器应用程序的计算机上安装 SQL Server，且要尽可能减少必要的网络协议数量。要在 Microsoft Windows Server® 2003 或 Microsoft Windows Server® 2008 计算机上安装 SQL Server，以使它能充分利用操作系统级的安全保护措施。此外，最安全的方案就是安装到一个或多个NTFS分区上。
有了安全的环境，接下来最关键的就是安全地安装 SQL Server 2008。安装程序执行所有的常规安装任务，其自带的 System Configuration Checker 将通知用户可能导致问题的任何不足之处。默认情况下，安装 SQL Server 2008 并不能启用所有特性。而是只安装核心组件以及常用特性。生产环境中可能用不到的其他特性默认是关闭的。可以使用该产品支持的工具启用所需特性。
这些都是 Trustworthy Computing 技术中 secure by default 特性的一部分。这表示在安装时，SQL Server 2008 可利用默认的安全设置集实现开箱即用的安全性。基本数据库服务器不需要的特性并未被安装，目的是为了减少外围应用。由于默认情形下并未在所有系统中启用所有特性，因此在安装系统镜像时引入了异质性。这一点限制了启用易受潜在攻击的特性的系统数量，因此有助于防御大规模攻击或蠕虫病毒。

Windows Update

在企业中部署SQL Server 之后，就能发现新的威胁和漏洞。Windows Update 旨在确保及时下载并应用能够显著减少特定安全问题的补丁。可以利用 Windows Update 自动应用 SQL Server 2008 补丁，并减少由于已知的软件漏洞所导致的威胁。在大多数企业环境中，应使用 Windows Server Update Service（WSUS）管理补丁在组织内部的分发和更新。

外围应用配置

SQL Server 2008 具有大量特性，其中有许多在安装时处于禁用状态。例如，CLR 集成、数据库镜像、调试、Service Broker 以及邮件功能虽被安装，但未运行且不可用，除非显式地启用或对其进行配置。该设计与 SQL Server “默认保证安全”思路的“减少外围应用”原则保持一致，可以减小攻击表面。如果特性不可用或未被启用，攻击者就不能利用它。
这样做的代价就是，要花些时间搜寻启用特性的所有 Transact-SQL 语句。即使发现sp_configure system 存储过程可以满足很多需要，仍须编写并不直观的如下代码：
sp_configure 'show advanced options', 1
reconfigure with override
sp_configure 'clr enabled', 1
由于配置选项过多，编写此类代码很耗时间，尤其是在组织中部署了多个SQL Server 实例时更是如此。SQL Server 2008 带有基于策略的管理技术，名为Declarative Management Framework （声明管理框架，DMF）。DMF 提供了大量的配置 facet，其中的每一个都定义了一组相关的配置设置或属性。可以利用这些 facet 创建一些为配置选项指定所需设置的“条件”，并将这些条件作为“策略”应用给企业中的 SQL Server 实例。
SQL Server 2008 自带的一个 facet 就是 Surface Area，可以利用该 facet 定义用以控制各种SQL Server 2008 特性状态的策略。通过创建为服务器定义所需外围应用设置的策略，可以方便地在组织中所有的 SQL Server 上配置最小的外围应用，并减小恶意攻击的可能性。

验证

在数据和服务器都需要保护，而且不想承受如今互联网上常见的无情攻击之际，Microsoft 开发了 SQL Server 2000。基本的验证问题依然存在：您是谁？您如何证明自己的身份？但是，SQL Server 2008 提供了更健壮的验证特性，对服务器的安全便捷有着更好的支持，放行好人并阻止坏人。
SQL Server Authentication 利用包含用户 id 和口令的简单连接字符串，为基于非 Windows的客户端或应用程序提供了验证机制。这种登录易于使用，很受应用程序开发人员的欢迎，它的安全性不如 Windows 验证机制，因此在验证机制中不推荐使用。
SQL Server 2008 改进了 SQL Server Authentication 选项。首先，默认情形下它利用 SQL 生成的证书支持通道的加密。管理员不必获取或安装有效的 SLL 证书，以确保 SQL 凭证流经的通道是安全的。由于 SQL Server 2008 自动生成这些证书，因此在传送登录数据包时，默认情形下它将自动加密通道。如果客户端使用 SQL Server 2005 或更新版本，即可使用该特性。
注意：SQL Server 生成的本地证书可保护被动的中间人攻击，其中的攻击者会嗅探网络。要更有效地系统免受被动中间人攻击，应部署并使用客户端也信任的证书。
SQL Server 2008 进一步增强了 SQL Server Authentication，因为在与 Windows 2003 服务器或更新版本一起使用时，默认情形下数据库引擎将利用Windows Group Policy 检查 SQL 登录的口令复杂度、口令过期日以及帐户锁定状态。这表示可以对 SQL Server 帐户强行应用 Windows 口令策略。

口令策略强制

有了 SQL Server 2008，口令策略强制特性被内置到服务器中。作为 Windows Server 2003 NetAPI32库的一部分，SQL Server 利用NetValidatePasswordPolicy() API 根据Windows 的口令强度、过期日和帐户锁定状态策略，在验证以及口令设置、重置期间验证口令的有效性。表3列出来构成该策略的各种设置。
 
表3  Windows Server 2003 口令策略组件

类别	名称	注释
口令策略	强行应用口令历史记录	防止用户重用旧口令，如交替使用两个口令。
	最短的口令长度
	口令必须满足复杂度要求	参见下文。
	利用可逆加密存储口令	允许在 Windows 中检索口令。绝对不要启用该选项，除非应用程序的要求优先于安全口令的要求。（该策略不适用于 SQL Server。）
口令过期日	口令的最长存在时间
	口令的最短存在时间
帐户锁定策略	帐户锁定持续时间	帐户锁定的持续时间（以分钟计）。当锁定阈值>0时，Windows 将启用该策略。
	帐户锁定阈值	不成功登录尝试的最大次数。
	时间到后即可重置帐户锁定计数器	多久之后 Windows 将重置不成功尝试的计数器。当锁定阈值>0时，Windows 将启用该选项。

 
如未运行 Windows Server 2003 或更新版本，SQL Server 仍利用简单的检查方法，强行应用口令强度，以阻止以下口令：
·         Null 或空口令
·         与计算机或登录名相同
·         Password、admin、administrator、sa、sysadmin 等口令
相同的复杂度标准被应用给在 SQL Server 中创建及使用的所有口令，包括 sa 登录的口令、应用程序角色、用于加密的数据库主密钥以及对称加密密钥。
SQL Server 默认情形下总会检查口令策略，但利用 CREATE LOGIN 或 ALTER LOGIN 语句，可取消对个别登录的强行应用，代码如下：
CREATE LOGIN bob WITH PASSWORD = 'S%V7Vlv3c9Es8',
    CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF
CHECK_EXPIRATION 使用 Windows Server 2003 策略的“口令最大和最小年龄”部分，而CHECK_POLICY 使用其他的策略设置。
管理设置还允许启用或关闭口令策略检查、启用或关闭口令过期检查，并在用户第一次登录时强行修改口令。CREATE LOGIN  中的 MUST_CHANGE 选项强行让用户修改下次登录时的口令。在客户端，它允许在登录时修改口令。所有新型客户端数据访问技术都支持该特性，包括 OLE DB 和ADO.NET 以及客户端工具，如 Management Studio。
如果用户的不成功登录次数过多，超出了口令策略允许的尝试次数，SQL Server 将根据 Windows 策略中的设置锁定该帐户。管理员可利用 ALTER LOGIN 语句取消锁定该帐户：
ALTER LOGIN alice WITH PASSWORD = '3x1Tq#PO^YIAz' UNLOCK

端点验证

SQL Server 2008 支持传统的二进制 Tabular Data Stream（表格数据流），客户端利用该数据流通过HTTP 访问数据，也可通过 HTTP 访问本地 XML Web 服务。允许通过 HTTP 进行访问的主要好处就是，任何理解 Web 服务协议的客户端软件和开发工具都可访问存储在 SQL Server 中的数据。这表示 SQL Server 2008 可以提供独立的 Web 服务方法，它也是Service Oriented Architecture（面向服务的体系结构，SOA）中的一个完整端点。
将 SQL Server 2008 用作 Web 服务主机需要两步通用操作，每一步都有很多变化：定义存储过程和用户定义的函数，以提供 Web 服务方法；定义 HTTP 端点，以通过 HTTP 接收方法调用，并将其转给适当的过程。本文主要介绍其中涉及到安全问题。有关配置及使用 HTTP 端点的详情，请参阅 SQL Server Books Online 中的 CREATE ENDPOINT（Transact-SQL）部分。
由于默认情形下 SQL Server 中的 XML Web 服务使用 HTTP 和80端口，因此大多数防火墙都允许流量通过。但是，不受保护的端点其实是潜在的攻击载体，必须对其施加保护，因此 SQL Server 提供了强大的验证和授权机制。默认情形下，SQL Server 没有任何端点，用户必须拥有高级权限，以创建、更改及启用 HTTP 端点。
SQL Server 2008 提供了五种不同的验证类型，与 IIS 用于网站验证的方法类似。
·         Basic 验证
基本验证是 HTTP 1.1 协议的一部分，它以base-64编码的明文传送登录凭证。凭证必须映射到 Windows 登录，然后 SQL Server 利用该凭证授权给对数据库资源的访问。如果使用 Basic 验证，就无法将 PORTS 自变量设为 CLEAR，反之必须将其设为 SSL，并通过 SSL 利用数字证书加密与客户端软件的通信。
·         Digest 验证
Digest 验证也是 HTTP 1.1 的一部分。在将凭证发送给服务器之前，它利用 MD5 对凭证进行杂散化，这样就无法通过电线发送它们，即使采用加密形式也是如此。凭证必须映射到有效的 Windows 域帐户，且不能使用本地的用户帐户。
·         NTLM 验证
NTLM 使用的是挑战响应协议，该协议最初是在Microsoft Windows NT® 中最先得到应用的，自此之后得到了 Windows 所有版本客户端和服务器的支持。当客户端和服务器都使用 Windows 系统时，它提供了安全验证机制，而且需要有效的域帐户。
·         Kerberos 验证
Kerberos 验证是 Windows 2000 及更新版本才有的特性，它以许多操作系统中都有的行业标准协议为基础。它允许执行相互验证，其中客户端和服务器都有理由相信对方的身份，并提供高级别的验证形式。为利用 Windows Server 2003 中的 Kerberos 特性，必须通过 HTTP.sys 以及作为 Windows Support Toos 一部分的 SetSPN.exe 实用工具，注册 Kerberos Service Principal Name（Kerberos 服务主体名，SPN）。
·         Integrated 验证
Integrated 验证提供了最好的 NTLM 和 Kerberos 验证。服务器将使用其中的一种验证类型并输入客户端请求，允许执行客户端支持的最安全验证，同时使旧版 Windows 也能使用该服务。可在 Windows 2003 中配置 Http.sys，使之与客户端协商要采用的协议。
用于端点的验证方法是通过 CREATE 或 ALTER ENDPOINT 语句的 AUTHENTICATION 属性设置的。例如，下列代码将创建利用 Kerberos 执行验证的端点：
CREATE ENDPOINT myEndpoint
STATE=STARTED
    AS HTTP (PATH = '/MyHttpEndpoint',
    AUTHENTICATION = (KERBEROS),
    PORTS = (CLEAR),
    SITE = 'MySqlServer')
FOR SOAP (WSDL = DEFAULT,
    DATABASE = 'myDB',
    NAMESPACE = 'http://example.com/MySqlServer/myDB/WebService')
SQL Server 2008 支持侦听 HTTP 和用户定义的 TCP 端口的端点。也可对请求进行各种格式化：SOAP、Transact-SQL、Service Broker 专用格式以及数据库镜像专用格式。使用 SOA 时，可利用 WS-Security 标题验证 SQL Server 登录。
Microsoft 已实现了 Web Service 端点验证，以支持各种协议和规范，本文只介绍其中几种。需要显式地启用验证选项，并确保客户端能够提供必要的凭证类型。一旦 SQL Server 完成对客户端的验证，就可以为登录有权访问的资源授权，如下节所述。

授权

验证完成后，就该考虑已验证登录可以执行的操作了。在这个方面，SQL Server 2008 和 SQL Server 2005 比旧版更灵活。权限的粒度更细，这样即可授予必要的特定权限，而不是授予固定角色的成员，以免其权限超出需要。现在有了更多的实体和安全实体，因此可为其分配粒度更细的权限。
除了增强对用户数据的保护，与特定安全实体有关的结构信息和元数据现在只能供拥有访问该安全实体权限的主体使用。
进一步而言，可以利用某种机制创建定制的权限集，该机制允许定义可运行存储过程的安全上下文。此外，SQL Agent 利用灵活地代理方案允许工作步骤运行以及访问必要的资源。所有这些特性都使得 SQL Server 更加灵活、更加安全。

细粒度权限

SQL Server 2008 和 SQL Server 2005 比旧版安全的诸多方面之一就是改进了权限的粒度。以前，管理员必须授予用户固定服务器角色或固定数据库角色的成员，以执行特定的操作，但这些角色的权限通常会远远超出简单任务的需要。“最少特权”的原则要求用户只能拥有完成工作所需的最低权限，因此为达到小目标而分配用户高级角色就违背了该原则。
从 SQL Server 2000开始，固定服务器和数据库角色集已发生了巨大变化，当用户或应用程序需要所有或大多数已定义的权限时，仍可利用这些预定义的权限。或许最大的变化就是添加了 public 服务器角色。但是，“最少特权”的原则要求用户不能使用无法恰好提供主体完成工作所需权限的角色。虽然为发现及分配主体所需权限需要更多工作，但这会带来更加安全的数据库环境。

主体和安全实体

在 SQL Server 2008中，“主体”就是可以访问受保护资源且能获得访问资源所需权限的任何个人、组或流程。与旧版 SQL Server 一样，可以在 Windows 中定义主体，也可将没有对应 Windows 主体的 SQL Server 登录作为其基础。下面的列表显示了 SQL Server 2008主体的层次结构，但不包括固定服务器和数据库角色，还显示了将登录和数据库用户映射为安全对象的方法。主体的影响范围取决于它的定义范围，这样 Windows 级别的主体就比 SQL Server 级别的主体拥有更大的影响范围，而后者的影响范围又大于数据库级别的主体。每个数据库用户都会自动隶属于固定的 public 角色。
Windows 级别的主体
·         Windows 域登录
·         Windows 本地登录
·         Windows 组
SQL Server 级别的主体
·         SQL Server登录
·         映射为 Windows 登录的 SQL Server 登录
·         映射为证书的 SQL Server 登录
·         映射为不对称密钥的 SQL Server 登录
数据库级别的主体
·         数据库用户
·         映射为 SQL Server 登录的数据库用户
·         映射为 Windows 登录的数据库用户
·         映射为证书的数据库用户
·         映射为不对称密钥的数据库用户
·         数据库角色
·         应用程序角色
·         公共角色
 
授权的另一部分就是可用以保护权限授予操作或拒绝授予操作的对象。图4列出了SQL Server 2008 中安全实体对象的层次结构。在服务器级别，可以保护网络端点，以控制进出服务器的通信通道，以及数据库、绑定角色和登录。在数据库和架构级别，用户创建的每一个对象都被当作安全主体，包括那些驻留在架构中的对象。



图4：SQL Server 2008中的安全实体对象层次结构

角色和权限

要了解可在 SQL Server 中可用的权限数量，可以调用 fn_builtin_permissions 系统函数：
SELECT * FROM sys.fn_builtin_permissions(default)
下面是 SQL Server 2005 中的新权限类型：
·         CONTROL。授予与所有者类似的权限，可有效地将所有已定义的权限授予对象及其范围内的所有对象，包括能够授予其他被授予者任何权限。CONTROL SERVER 相当于授予 sysadmin 特权。
·         ALTER。授予权限以更改安全实体对象的任何属性，但修改所有权除外。从本质上讲，它将为同一范围内的 ALTER、CREATE 或 DROP 安全实体对象授予权限。例如，为数据库授予 ALTER 权限就可以修改它的表。
·         ALTER ANY <安全实体对象>。授予权限以修改指定类型的任何安全实体对象。例如，授予 ALTER ANY ASSEMBLY 就可以修改数据库中的任何 .NET 程序集，而在服务器级别授予 ALTER ANY LOGIN，则用户将可修改该服务器上的任何登录。
·         IMPERSONATE ON <登录或用户>。 授予权限以扮演特定用户或登录。本章稍后将讲到，该权限是为存储过程切换执行上下文所必需的。在以批处理方式执行扮演时也需要该权限。
·         TAKE OWNERSHIP。授予权限以保证获得对安全实体的所有权，使用的是 ALTER AUTHORIZATION 语句。
SQL Server 2008 仍然使用大家熟悉的 GRANT、DENY 和 REVOKE 架构，将安全实体对象的权限分配或拒绝分配主体。GRANT 语句现在提供了所有的新权限选项，如授予范围以及主体是否能够向其他主体授予权限等。SQL Server 不允许使用跨数据库权限。要授予此类权限，要在每个数据库中创建复制用户，并分别为各个数据库的用户分配该权限。
与旧版 SQL Server 类似，激活应用程序角色时，其他权限在角色激活期间内都会被暂时取消。然后，在 SQL Server 2008 和 SQL Server 2005中，可以取消设置应用程序角色。SQL Server 2000 与新版本之间的另一个区别就是，在激活应用程序角色时，角色也会暂时取消任何服务器特权，包括 public。例如，如为 public 授予 VIEW ANY DEFINITION，则应用程序角色将不会允许使用该权限。在应用程序角色上下文中访问服务器级元数据时，这一点最明显。
注释   应用程序角色的新首选替代方法就是在代码模块中使用执行上下文。有关更多信息，请参阅本文的“执行上下文”部分。i
授予特定权限隐含地可以传送其他权限的权利。例如，架构的 ALTER 权限“涵盖”更细的粒度和低级权限，这些都是隐式定义的。图5为 ALTER SCHEMA 的隐含权限。请参阅 SQL Server Books Online 上的“Covering/Implied Permissions (Database Engine)”，以了解ImplyingPermissions 用户定义函数的 Transact-SQL 代码，该函数从sys.fn_builtin_permissions  目录视图中收集层次结构列表，并识别层次结构中每种权限的深度。在主数据库中添加 ImplyingPermissions 后，执行该语句将产生图5的结果，传入对象和权限类型：
SELECT * FROM master.dbo.ImplyingPermissions('schema', 'alter')
ORDER BY height, rank
这是浏览 SQL Server 2008 权限层次结构的理想方法。
 

图5：ALTER SCHEMA 的隐含权限层次结构
考虑可用的主体数量和类型、服务器和典型数据库中的安全实体对象数量，以及可用权限、涵盖权限、隐含权限的数量时，会很容易发现 SQL Server 2008中的权限的粒度非常细。创建数据库需要对其安全需要进行更详细的分析，并谨慎控制所有对象的权限。不过，这种分析工作是值得做的，使用SQL Server 2008中的这些功能会使数据库更加安全。

元数据安全

细粒度权限架构的一个优点就是 SQL Server不仅保护元数据，也保护数据。在 SQL Server 2005之前，能够访问数据库的用户可以看到数据库中所有对象的元数据，无论该用户是否可以访问其中的数据或是否能够执行存储过程。
SQL Server 2008 仔细检查数据库中主体所拥有的各种权限，仅当主体具有所有者身份或拥有对象的某些权限时，才会显示该对象的元数据。还有一种 VIEW DEFINITION 权限，即使没有该对象的其他权限，利用它也能查看元数据信息。
这种保护扩展到了某些操作返回的出错消息，这些操作试图访问或更新用户无权访问的对象。SQL Server  不会确认确实存在一份名为 Address 的表，使攻击者确信自己的方向是正确的，而是返回提示各种可能性的出错消息。例如，如果用户无权访问数据库中的对象，并且试图访问 Address 表，则 SQL Server 将显示下列出错消息：
Msg 3701, Level 14, State 20, Line 1
Cannot drop the table 'Address', because it does not exist or you do not have permission.
通过这种方式，攻击者无法确认是否真的存在 Address 表。但是，通过排查问题，仍然有很小的攻击可能性。

SQL Server Agent 代理

关于 SQL Server 2008 中的授权模型，一个最佳示例就是 SQL Server Agent。可以定义往往与 Windows 登录相关的各种凭证，且它们将链接到具有必要权限以执行一个或多个 SQL Server Agent 步骤的用户。然后，SQL Server Agent 代理将凭证与工作步骤链接到一起，以提供必要的权限。
这就以颗粒方式实现了“最少特权”原则：只授予工作步骤必要的权限，仅此而已。可以随意创建代理，并使其与一个或多个 SQL Server Agent 子系统相关联。这与 SQL Server 2000中的全能式代理帐户截然不同，后者允许用户在 SQL Server Agent 的任何子系统中创建工作步骤。
注释   在 SQL Server 2000中升级服务器时，将创建单代理帐户，而且所有的子系统都将被分配这个单代理帐户，以使现有的工作继续运行。升级完成后，将创建凭证和代理帐户，通过实施更安全、粒度更细的代理集，以保护服务器资源。
图6为 Management Studio 中的 Object Explorer，它显示了 SQL Server Agent 中可用的子系统列表。每个子系统都可以拥有一个或多个与之相关的代理，以为工作步骤分配适当的权限。该架构有一个例外，即 Transact-SQL 子系统需要在模块所有者的权限下执行，这与 SQL Server 2000 中的方式相同。
 

图6：可与代理相关联的 SQL Server Agent 子系统
新安装了 SQL Server 之后，只有 System Administrator 角色有权维护 SQL Server Agent工作，而且只有 sysadmins  能够使用 Management Studio Object Explorer 中的管理窗格。SQL Server 2008 允许用户利用其它一些角色授予各种级别的权限。可以分配用户 SQLAgentUser、SQLAgentReaderRole 或 SQLAgentOperator 角色，其中每一个角色都会分配级别逐渐提高的权限，以创建、管理及运行工作，也可分配 MaintenanceUser 角色，它拥有 SQLAgentUser 的所有权限，还能创建维护计划。
当然，sysadmin 角色的成员可以在任何子系统中随意执行任何操作。要授予其他任何用户使用子系统到权限，需要创建至少一个代理帐户，这可授予访问一个或多个子系统的权利。图7显示了如何将代理帐户 MyProxy 分配多个主体，这里包括一位用户和一个角色。代理帐户使用凭证，将其链接到帐户，通常是链接到域帐户，并且拥有在操作系统中执行各种任务的权限，这些权限也是子系统所必需的。每个代理都拥有一个或多个与之相关的子系统，它们使主体能够运行这些子系统。
 

图7：用于各种子系统的 SQL Server Agent 代理帐户
下列代码就是实施图7所示架构所需的 Transact-SQL 代码。首先创建凭证和一个数据库对象，后者将提供操作系统帐户链接，该帐户有权在子系统中执行所需动作。然后它添加 MyProxy 代理帐户，该帐户其实只是凭证的友好名称。接着，它将代理分配两个主体，就是 SQL Server 登录和定制角色。最后，它使代理与4个 SQL Server Agent 子系统相关联。.
CREATE CREDENTIAL MyCredential WITH IDENTITY = 'MyDOMAIN\user1'
GO
msdb..sp_add_proxy @proxy_name = 'MyProxy',
    @credential_name = 'MyCredential'
GO
msdb..sp_grant_login_to_proxy @login_name = 'MyLogin',
    @proxy_name = 'MyProxy'
GO
msdb..sp_grant_login_to_proxy @login_name = 'MyRole',
    @proxy_name = 'MyProxy'
GO
 
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
    @subsystem_name = 'ActiveScripting'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
    @subsystem_name = 'CmdExec'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
    @subsystem_name = 'ANALYSISQUERY'
GO
sp_grant_proxy_to_subsystem @proxy_name = 'MyProxy',
    @subsystem_name = 'DTS'
GO
SQL Server Management Studio 完全支持凭证和代理的创建，如图8所示。这将创建与上一段代码相同的代理。
 

图8：SQL Server Management Studio 中的SQL Server Agent 新代理
代理不只是操作系统中杜绝安全问题的一种方式。如果与代理一起使用的凭证没有 Windows 权限，如通过网络写入目录的权限，则该代理也不会有此权限。也可利用代理为xp_cmdshell 授予有限的执行权限，因为它是黑客最喜欢利用的工具，只要他们能够成功威胁到 SQL Server 计算机的安全，就会进一步利用该工具将其威胁范围扩展到网络空间。代理提供了该领域的保护机制，因为纵使主体在网络上不受任何限制，例如域管理员主体，通过代理执行的任何命令也只拥有凭证帐户的有限权限。

执行上下文

一直以来，SQL Server 都支持所有权链的概念，它可确保管理员和应用程序开发人员能够在数据库的入口点提前检查权限，而不是用来提供所有被访问对象的权限。只要调用模块（存储过程或函数）或视图的用户拥有模块的执行权限或视图的选择权限，而且模块或视图的所有者曾是被访问对象的所有者（所有权链），则不会检查基本对象的任何权限，而且调用者将收到请求的数据。
假如因为代码的所有者没有被引用对象的所有权，而导致所有权链被打断，SQL Server 将按照调用者的安全上下文检查权限。如果调用者拥有访问对象的权限，SQL Server 将返回数据。如果没有此权限，SQL Server 将提示出错。
所有权链有一些局限性：它只适用于数据操作，而不适用于动态 SQL。而且，如要跨越所有权边界访问对象，就不可能实现所有权链。因此，权限提前检查行为只适用于某些场合。
SQL Server 2008 能够利用执行上下文标记模块，这样模块中的语句即可供与调用用户并列的特殊用户执行。通过这种方式，调用用户仍然需要模块的执行权限，而SQL Server 将按照模块的执行上下文检查模块中语句的权限。可以利用此行为客服所有权链的某些缺陷，因为它适用于模块中的所有语句。想要执行权限提前检查的管理员可以利用执行上下文达到这一目的。
在定义用户定义函数（除了内联的表值）、存储过程和触发器时，可以利用 EXECUTE AS 子句指定SQL Server 要使用哪个用户的权限验证对对象以及过程引用数据的访问：
CREATE PROCEDURE GetData(@Table varchar(40))
    WITH EXECUTE AS 'User1'
SQL Server 2008 提供了4种 EXECUTE AS 选项。
·         EXECUTE AS CALLER 指定代码在模块调用者的安全上下文中执行。不会出现假冒的现象。调用者必须拥有所有被引用对象的访问权限。但是，SQL Server 只检查被打断的所有权链的权限，假如代码的所有者也拥有基本对象的所有权，则只检查该模块的执行权限。这就是向后兼容性的默认执行上下文。
·         EXECUTE AS 'user_name'  指定代码在指定用户的安全上下文中执行。如果不想使用所有权链，这就是一个不错的选项。否则，可以创建拥有运行代码以及创建定制权限集所需权限的用户。
·         EXECUTE AS SELF 是一个快捷符号，用于为创建或更改模块的用户指定安全上下文。在内部，SQL Server 将保存与模块关联的实际用户名，而不是保存“SELF”。
·         EXECUTE AS OWNER 指定安全上下文就是模块执行时模块当前所有者的安全上下文。如果模块没有所有者，则将使用包含架构所有者的上下文。如想修改模块的所有者，而且不想修改模块本身，这就是一个绝佳选项。
利用 EXECUTE AS 选项更改用户上下文时，模块的创建者和更改者必须拥有指定用户的IMPERSONATE 权限。不能从数据库中删除指定用户，除非将所有模块的执行上下文更改为其他用户。

用户/架构分离

SQL Server 2000 没有架构的概念，而 ANSI SQL-99 规范将架构定义为单个主体所拥有的所有数据库对象集合，而且该主体形成了对象的一个命名空间。架构就是数据库对象的容器（如表、视图、存储过程、函数、类型和触发器等）。它的功能与.NTE Framework 和 XML 中的命名空间函数非常类似，该函数可将对象进行分组，以便数据库能够重用对象名称，如允许在一个数据库中同时存在 dbo.Customer 和 Fred.Customer，也可对不同所有者的对象进行分组。
注意：需要用到目录视图，如 sys.database_sys.principals、sys.schemas 和sys.objects 等。原因在于 sysobjects 旧系统表不支持架构，因此不支持U/S分离。此外，不赞成使用旧目录视图，在 SQL Server 的未来版本中它们将被删除。
图9的顶端就是 SQL Server 2000中的架构工作原理。当管理员在数据库中创建 Alice 用户时， SQL Server 将自动创建 Alice 架构，它隐藏于 Alice 用户后面。如果 Alice 登录了正在运行 SQL Server 但没有数据库所有权的服务器，而且创建了表1，则该表单实际名称为 Alice.Table1。这也适用于 Alice 创建的其他对象，如 Alice.StoredProcedure1 和 Alice.View1。如果 Alice 是数据库所有者或 sysadmin，她创建的对象将成为 dbo 架构的一部分。虽然我们习惯说 dbo 拥有对象，但这是同一码事。
 

图9：SQL Server 2000 and 2008中的用户/架构/对象
需要修改对象的所有权时，例如 Alice 离开公司而 Lucinda 接手了 Alice 的工作，此时SQL Server 2000 中用户和架构的融合会产生一个问题。系统管理员必须将 Alice 拥有的所有对象的所有者改为Lucinda。更成问题的是，则 Lucinda 拥有了表的所有权后，还必须将任何引用 Alice.Table1 的Transact-SQL 或客户端应用程序代码改为引用 Lucinda.Table1。根据 Alice 拥有的对象数量以及内部嵌有该名称的应用程序数量，这可能是一项繁重的工作。Microsoft 公司一直建议内置的 dbo 用户要拥有所有的数据库对象，以避免产生这些问题。与修改许多对象和客户端应用程序相比，修改数据库的所有权要容易得多。
注意：不要被 SQL Server 2000 CREATE SCHEMA 语句迷惑。它只是一种简单的方法，用以创建特殊用户拥有的表和视图，以及授予权限。可以利用该语句命名架构的所有者，但不能命名架构。SQL Server 仍不可避免地将所有者链接到架构，这要面对修改所有权带来的所有问题。
SQL Server 2008 通过分离用户和架构克服了这些问题，并实施了 SQL-99 架构，如图9底部所示。利用新增的 CREATE USER DDL 创建 Alice 新用户时，SQL Server 不再自动创建使用相同名称的架构。反之，必须显式创建架构，并将其所有权分配用户。由于图示的所有的数据库对象都包含于 Schema1 架构中，就是 Alice 最初拥有的架构，因此只须将架构的所有者改为 Lucinda，就可以方便地修改所有架构对象的所有权。每位用户也都被分配默认架构，这样 SQL Server 将假定没有架构引用且按照名称引用的任何对象都位于默认架构中。在图9的底部，如果 Alice 使用 Schema1 作为默认架构，她就可将该表命名为 Schema1.Table1 或Table1。Carol 用户可能没有与其名字关联的默认架构，必须将该表命名为 Schema1.Table1。没有默认预定义架构的任何用户都使用 dbo 作为默认架构。
在 SQL Server 2008 中，完全合格的对象名称由4部分组成，这与旧版SQL Server 中的对象名称类似：
server.database.schema.object
与旧版类似，如果对象所在服务器与运行代码的服务器同名，则可忽略服务器名称。如果连接打开了同名数据库，则可忽略数据库名称。如果使用当前用户的默认架构或架构为 dbo 所拥有，则可忽略架构名称，因为这是 SQL Server 尝试消除对象名称歧义时最后用过的架构。
可以利用 CREATE USER 语句而非 sp_adduser 语句创建新用户。此系统存储过程仍然是为了实现向后兼容性，但已进行了少许修改，以遵循用户与架构分离的新原则。sp_adduser 创建的架构与新用户名或应用程序角色同名，并将该架构作为用户的默认架构，这与 SQL Server 2000 的行为类似，但提供了分离的架构。
注意：使用 ALTER AUTHORIZATION 语句时，可能会产生这种情况：“您”拥有“我的”架构中的表（或反之）。这个问题具有重大的隐含意义。例如，谁拥有该表的触发器，您还是我？底部的代码行可以设计得非常巧妙，以发现架构范围对象或类型的真正所有者。有两种方式可以避开此问题：
·         利用 OBJECTPROPERTY（id,”OwnerId”）发现对象的真正所有者。
·         利用 TYPEPROPERTY（type,”OwnerId”）发现类型的真正所有者。
SQL Server 2008 利用同义词帮助减少击键次数。可以利用两部分、三部分或四部分完整对象名为任何对象创建同义词。SQL Server 使用同义词访问已定义的对象。在下列代码中，“History”同义词表示在AdventureWorks 数据库中指定的 schema.table。SELECT 语句返回EmployeeDepartmentHistory 表的内容。
USE AdventureWorks
GO
 
CREATE SYNONYM History FOR HumanResources.EmployeeDepartmentHistory
 
SELECT * FROM History
注意：如果其他人准备使用同义词，则管理员或所有者必须为其授予权限。针对视图、表或表值函数，可对同义词应用GRANT SELECT。针对过程或标量函数，可对同义词应用 GRANT EXECUTE，诸如此类。
也可通过以下代码，为完整的四部分名称定义“History”同义词：
CREATE SYNONYM History
    FOR MyServer.AdventureWorks.HumanResources.EmployeeDepartmentHistory
假设当前的用户拥有使用同义词的权限以及读取表的权限，则使用类似的四部分全名即可在其他数据库上下文中使用同义词：
USE pubs
SELECT * FROM AdventureWorks..History
还要注意，如果不提供架构名称作为新同义词名称的一部分，它将成为默认架构的一部分。

加密和密钥管理

服务器级安全可能是系统管理员最关心的问题，而对于数据库来说，所有操作都是在生产环境中完成的。。在大多数情况下，数据库管理员会将数据库细节的问题留给数据库开发人员处理，只要开发人员在环境的限制内工作。SQL Server 2008提供了大量确保数据库安全的功能。

数据加密

SQL Server 2000 及其早期版本不支持加密存储在数据库中的数据。为什么需要加密存储在安全性良好的数据库（位于安全地嵌套在最新的防火墙之后的安全服务器上）中的数据？这是因为一个重要的、叫做 defense in depth 的旧安全规范。Defense in depth 的意味着分层防御，即使攻击者成功打破了最外层防御，他们仍然需要突破一层接一层的防御才能获得成功。在数据库中，这意味着攻击者通过了防火墙和从服务器到数据库的 Windows 安全以后，仍然需要进行一些恶劣的、野蛮的和强制的黑客攻击来解码您的数据。另外，在如今这个立法保护数据和隐私的大环境中，数据需要加强保护。
SQL Server 2008 使用对称密钥、非对称密钥和数字证书，为各种类型的数据加密提供了丰富的支持。最出色的是，它为您管理密钥，而密钥管理是迄今为止加密中最难的部分。保密是一件很难的事情。
管理员可能至少需要管理图10所示层次结构中的上级密钥。数据库管理员需要理解服务器级的服务主密钥和数据库级的数据库主密钥。每一个密钥都保护其子密钥，子密钥又保护其子密钥，从树形结构图依次向下。密码保护对称密钥或证书时例外，这是 SQL Server 使用户管理自己的密钥，以及负责保密密钥的方法。

图 10：SQL Server 2008 中的加密密钥层次结构
注意：Microsoft 不推荐直接使用证书或非对称密钥加密数据。非对称密钥加密的速度很慢，并且使用此机制保护的数据量有限（这取决于密钥模数的大小）。可以使用密码，而不是数据库主密钥保护证书和非对称密钥。
服务主密钥是一个规定 SQL Server 中所有密钥和证书的密钥。它是 SQL Server 在安装期间自动创建的对称密钥。显然，它是一个至关重要的密钥，因为如果此密钥泄露了，那么攻击者最终将解码服务中由 SQL Server 管理的每个密钥。Windows 中的数据保护 API (Data Protection API, DPAPI) 保护服务主密钥。
SQL Server 为您管理服务主密钥。虽然您可以对其执行维护任务，将其转存到一个文件中，重新生成它，以及从文件中将其还原。不过，大多数情况下，无需对密钥做任何更改。备份服务主密钥以防止密钥损坏对于管理员来说是明智的选择。
在数据库范围内，数据库主密钥是数据库中所有密钥、证书和数据的根加密对象。每个数据库都有惟一的主密钥；尝试创建第二个密钥时，会出现错误提示。必须在使用前通过 CREATE MASTER KEY Transact-SQL 语句和用户提供的密码创建一个数据库主密钥：
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'EOhnDGS6!7JKv'
SQL Server 使用由密码和服务主密钥派生出来的三重 DES 密钥加密密钥。第一个副本存储在数据库中，第二个存储在主数据库中。由于服务主密钥保护数据库主密钥，因此可能在需要时由SQL Server 自动加密数据库主密钥。最终应用程序或用户无需使用密码显式打开主密钥，这是层次结构保护密钥的主要优势。
分离一个存在现有主密钥的数据库，并将其移动到另一个服务器上是一个难题。问题在于新服务器的服务主密钥与旧服务器的服务主密钥不同。因此，服务器不能自动解密数据库主密钥。可以通过使用加密密码打开数据库主密钥，然后使用 ALTER MASTER KEY 语句以新的服务主密钥对其加密的方法避开这个问题。否则，总是需要显式打开数据库主密钥以后才能使用。
如果存在数据库主密钥，那么开发人员就可以使用它创建三种类型中的任何一种密钥，具体取决于加密所需求的类型：
·         非对称密钥，使用公钥/私钥对进行公钥加密
·         对称密钥，用于在同一个密钥分别加密和解密数据的方面共享秘密
·         证书，实质上用于包装公钥
由于所有加密选项及其已经深层集成于服务器和数据库中，因此现在加密是将防御的最终层添加到数据的可行方法。然而，需明智使用工具，因为加密给服务器增加了大量的处理开销。

透明数据加密

在 SQL Server 2005 中，可以使用数据库引擎加密功能，通过编写自定义 Transact-SQL 加密数据库中的数据。SQL Server 2008 引入了透明的数据加密，改进了这种状况。
透明数据加密在数据库级执行所有加密操作，这消除了应用程序开发人员创建自定义代码来加密和解密数据的需要。数据在写入磁盘时被加密，在从磁盘读取时解密。通过使用 SQL Server 透明地管理加密和解密，就可以在不改变现有应用程序的情况下确保数据库中业务数据的安全，如图 11 所示。

图 11：透明数据加密
数据库加密密钥（Database Encryption Key，DEK）用于执行加密和解密操作，该DEK存储在数据库启动记录中，以便在恢复过程中使用。可以使用服务主密钥（Service Master Key）或硬件安全模块（Hardware Security Module，HSM）保护 DEK。HSM 通常是 USB 设备或智能卡，因为不易被盗或丢失。

扩展的密钥管理

随着法规遵从性需求的不断增长以及对数据隐私的整体关注，越来越多的组织将加密用作提供深层防御解决方案的手段。随着组织越来越多地使用加密和密钥来保护数据，密钥管理也变得更加复杂。一些高安全性数据库要使用数千个密钥，并且必须部署一个系统来存储、注销和重新生成这些密钥。而且，应该将这些密钥与数据分开存储以增强安全性。
SQL Server 2008 为第三方供应商的使用公开了加密功能。这些解决方案可以与 SQL Server 2005 和 SQL Server 2008 数据库无缝地一起工作并提供了企业级专用密钥管理。这将密钥管理工作负载从 SQL Server 转移到了专用密钥管理系统。
SQL Server 2008 中扩展的密钥管理还支持使用 HSM 提供密钥与数据的物理分离。

代码模块签名

在 SQL Server 中提供加密的一个好处就是它提供了使用证书对代码模块（存储过程、函数、触发器和事件通知）进行数字签名的能力。这提供了对数据库表和其他对象访问的更细粒度的控制。像加密数据一样，您使用证书中的私钥签名代码。其结果是在该经过签名的代码模块中使用的表只能通过该代码访问并且不允许在代码模块之外。换句话说，只能使用已经用于签名该模块的证书获得对该表的访问。
对于存储过程而言，效果也是一样的。例如，如果有完整的所有权链，您可以谨慎控制哪些用户获得该过程的 EXECUTE 权限，并且可以拒绝他们对基础表的直接访问。但这在过程的所有权链被破坏或执行动态 SQL 时不起作用，此时要求执行该过程的用户拥有对基础表的权限。实现同样效果的另一种方式是使用 EXECUTE AS，但这改变了过程执行的安全上下文。这可能不是理想的情况，例如，需要在表中记录实际使该过程运行的用户时（没有要求将用户名作为过程的参数）。
签名代码模块的另一个好处就是防止对代码模块作出未经授权的更改。像其他经过数字签名的文档一样，在代码改变时，证书将失效。代码不在证书上下文中执行，因此任何被提供了证书访问权限的对象都将不可访问。
要继续访问它们，需要创建一个证书，将该证书与新用户关联并使用该证书签名过程。授予该用户执行该存储过程必要的任何权限。实质上，已经将该用户作为次级身份标识添加到了存储过程安全上下文中。然后，授予需要执行该过程的任何用户或角色执行权限。以下代码展示了这些步骤。假设您想要签名 mySchema.GetSecretStuff 过程，并且所有引用的对象已经存在于数据库中：
CREATE CERTIFICATE certCodeSigning
    ENCRYPTION BY PASSWORD = 'cJI%V4!axnJXfLC'
    WITH SUBJECT = 'Code signing certificate'
GO
 
-- Sign the stored procedure
ADD SIGNATURE TO mySchema.GetSecretStuff BY CERTIFICATE certCodeSigning
    WITH PASSWORD = 'cJI%V4!axnJXfLC'
GO
 
-- Map a user to the certificate
CREATE USER certUser FOR CERTIFICATE certCodeSigning
GO
 
--Assign SELECT permissions to new certUser
GRANT SELECT ON SocialSecurity TO certUser
GO
 
-- Grant execute permission to the user who will run the code
GRANT EXECUTE ON mySchema.GetSecretStuff TO ProcedureUser
GO
现在只有明确授予对该存储过程具有 EXECUTE 权限的用户能够访问该表的数据。

SQL Server 2008中的审核

任何安全解决方案的一个重要组成部分就是出于可说明性和法规遵从性的考虑而进行审核的能力。SQL Server 2008包含很多特性，使审核活动成为可能。

所有动作审核

SQL Server 2008通过Audit对象提供审核支持，这使管理员能够捕获数据库服务器中的活动并将其存储在日志中。使用SQL Server 2008，您可以将审核信息存储在以下目标中：
·         文件
·         Windows应用程序日志
·         Windows安全日志
要写入Windows安全日志，必须将SQL Server服务配置为作为Local System、Local Service、Network Service或拥有SeAuditPrivilege权限且不是交互用户的域帐户运行。
要创建Audit对象，必须使用CREATE SERVER AUDIT语句。该语句定义Audit对象并将其与目标关联。用于配置Audit对象的特定选项取决于审核目标。例如，以下Transact-SQL代码创建了两个Audit对象；一个将活动记录到文件，另一个将活动记录到 Windows应用程序日志。
CREATE SERVER AUDIT HIPAA_File_Audit
    TO FILE ( FILEPATH=’\\SQLPROD_1\Audit\’ );
 
CREATE SERVER AUDIT HIPAA_AppLog_Audit
    TO APPLICATION_LOG
    WITH ( QUEUE_DELAY = 500,  ON_FAILURE = SHUTDOWN);
注意当记录到文件目标时，文件名没有在 CREATE SERVER AUDIT 语句中指定。审核文件名采用 AuditName_AuditGUID_nn_TS.sqlaudit 的形式，其中 AuditName 是 Audit 对象的名称，AuditGUID 是与该 Audit 对象相关的惟一标识符，nn 是用于分区文件集的分区号，而 TS 是时间戳的值。例如，通过前面的代码样例创建的 HIPAA_FILE_Audit Audit 对象可以生成一个与以下名称类似的日志文件：
HIPAA_File_Audit_{95A481F8-DEF3-40ad-B3C6-126B68257223}_00_29384.sqlaudit
可以使用 QUEUE_DELAY 审核选项实现出于性能原因的异步审核，可以使用 ON_FAILURE 选项确定无法向目标写入审核信息时采取的操作。在前面展示的 HIPAA_AppLog_Audit 示例中，ON_FAILURE选项被配置为在无法写入日志时关闭 SQL Serve r实例；在这种情况下，执行CREATE SERVER AUDIT 语句的用户必须拥有 SHUTDOWN 权限。
在创建 Audit 对象之后，可以通过使用 CREATE SERVER AUDIT SPECIFICATION 和 CREATE DATABASE AUDIT SPECIFICATION 语句对其添加事件。CREATE SERVER AUDIT SPECIFICATION 向 Audit 添加服务器级的操作组（即可以在服务器级发生的预定义的相关操作集合）。例如，以下代码将 FAILED_LOGIN_GROUP 操作组（它记录了失败的登录尝试）添加到HIPAA_File_Audit Audit。
CREATE SERVER AUDIT SPECIFICATION Failed_Login_Spec
FOR SERVER AUDIT HIPAA_File_Audit
    ADD (FAILED_LOGIN_GROUP);
CREATE DATABASE AUDIT SPECIFICATION 语句向 Audit 添加数据库级的操作组和单个数据库事件。添加单个操作使您能根据对象筛选记录的操作以及操作涉及的用户。例如，以下代码样例向HIPAA_AppLog_Audit Audit 添加了 DATABASE_OBJECT_CHANGE_GROUP 操作组（它记录数据库中的任何 CREATE、ALTER 或 DROP 操作）以及在 Sales 架构中由 SalesUser 或 SalesAdmin 用户对对象执行的 INSERT、UPDATE 或 DELETE 语句。
CREATE DATABASE AUDIT SPECIFICATION Sales_Audit_Spec
FOR SERVER AUDIT HIPAA_AppLog_Audit
    ADD (DATABASE_OBJECT_CHANGE_GROUP),
    ADD (INSERT, UPDATE, DELETE
         ON Schema::Sales
         BY SalesUser, SalesAdmin);
Audit 对象提供了一个可管理的审核框架，该框架使定义应记录的事件和事件应存储的位置变得很容易。SQL Server 添加的这个功能帮助您实现综合的审核解决方案以确保数据库的安全并满足法规遵从性的要求。

DDL触发器

DDL 触发器是在 SQL Server 2005 中引入的。与表中数据发生变化时执行 Transact-SQL 代码的DML 触发器不同，DDL 触发器在表结构 发生变化时激活。这是跟踪和审核数据库架构的结构性变化的极佳方式。
这些触发器的语法与 DML 触发器的类似。DDL 触发器是 AFTER 触发器，为了响应 DDL 语言事件而激活；它们不会为了响应执行类似 DDL 操作的系统存储过程而激活。它们是完全事务性的，因此您可以 ROLLBACK 一个 DDL 变更。您可以在 DDL 触发器中运行 Transact-SQL 或者 CLR代码。 DDL 触发器还支持类似其他模块的 EXECUTE AS 子句。 
SQL Server 将关于触发器事件的信息作为非类型化的 XML 提供。可以通过称为 EVENTDATA()的能够发出 XML 数据的新内置功能获得这些信息。可以使用 XQuery 表达式解析 EVENTDATA() XML 以发现事件属性，如架构名称、目标对象名称、用户名，以及导致触发器最先激活的整个Transact-SQL DDL语句。例如，请参见 SQL Server Books Online 中的 EVENTDATA (Transact-SQL)。数据库级 DDL 触发器由数据库或更低级别的 DDL 语言事件激活。例如，CREATE_TABLE、 ALTER_USER等等。服务器级 DDL 触发器由服务器级的 DDL 语言事件激活，例如 CREATE_DATABASE、ALTER_LOGIN 等等。为了管理方便，您可以使用事件组，比如 DDL_TABLE_EVENTS，来简称所有 CREATE_TABLE、ALTER_TABLE 和 DROP_TABLE 事件。各种 DDL 事件组和事件类型及其相关 XML EVENTDATA()在SQL Server Books Online 上均有记述。
与 DML 触发器名称不同（它是架构范围的），DDL 触发器是数据库范围或服务器范围的。
使用此目录视图发现 DML 触发器和数据库级 DDL 触发器的触发器元数据：
SELECT * FROM sys.triggers ;
GO
如果 parent_class_desc 列中存在 'DATABASE' 的值，那么它就是 DDL 触发器，并通过数据库本身确定名称范围。Transact-SQL 触发器的代码体可以在 sys.sql_modules 目录视图中找到，并且可以将它连接到 sys.triggers 的object_id 列中。 关于 CLR 触发器的元数据可以在 sys.assembly_modules 目录视图中找到，同样可以连接到 sys.triggers 的 object_id 列中。
使用此目录视图发现服务器范围的 DDL 触发器的元数据：
SELECT * FROM sys.server_triggers ;
GO
Transact-SQL 服务器级别的触发器的代码体可以在 sys.server_sql_modules 目录视图中找到，可以将它连接到 sys.server_triggers 的 object_id 列上。关于一个 CLR 服务器级别的触发器的元数据可以在 sys.server_assembly_modules 目录视图中找到，同样可以将它连接到 sys.server_triggers 的 object_id 列上。
 
　　可以使用 DDL 触发器来捕捉和审核数据库中的 DDL 活动。创建一个带有非类型化的 XML 列的审核表。为 DDL 事件或您感兴趣的事件组创建一个 EXECUTE AS SELF DDL 触发器。这个DDL 触发器的代码体可以简单地将 EVENTDATA() XML 插入到审核表中。
 
　　DDL 触发器的另一个有趣的使用是由 CREATE_USER 事件激活然后添加代码到自动权限管理。例如，假设您想让所有的数据库用户获得一个对存储过程 P1、P2 和 P3 的 GRANT EXECUTE 权限。DDL 触发器可以从 EVENTDATA() XML 中提取用户名称，动态地生成一个语句，像 ‘GRANT EXECUTE ON P1 TO someuser’，然后对它执行EXEC()。

结束语

　　SQL Server 2008 提供了丰富的安全特性，用于保护数据和网络资源。它的安装更轻松、更安全，除了最基本的特性之外，其他特性都不是默认安装的，即便安装了也处于未启用的状态。SQL Server提供了丰富的服务器配置工具，特别值得关注的就是 SQL Server Surface Area Configuration Tool，它的身份验证特性得到了增强， SQL Server 更加紧密地与Windows身份验证相集成，并保护弱口令或陈旧的口令。有了细粒度授权、SQL Server Agent 代理和执行上下文，在经过验证之后，授权和控制用户可以采取的操作将更加灵活。元数据也更加安全，因为系统元数据视图仅返回关于用户有权以某种形式使用的对象的信息。在数据库级别，加密提供了最后一道安全防线，而用户与架构的分离使得用户的管理更加轻松。
 
获取更多信息：
http://www.microsoft.com/sql
http://www.microsoft.com/sql/technologies/security/default.mspx
 
本文对您有帮助吗？请告诉我们您的感受。如果从1（差）到5（极好）的分值中进行选择，您认为本文应该打几分？原因是什么？例如：
·         您是否认为由于提供了很好的例子、精美的屏幕截图、清晰的文字描述或其他原因而应该给它高分？
·         您是否认为由于用例不当、屏幕截图模糊、文字描述含混不清而应该给它低分？
您的意见有助于我们改善所发布白皮书的质量。提交意见。