图1：SQL Server的认证机制

    如上图，SQL Server认证同时提供SQL Server本地账号与Windows继承认证两种方式，以往在企业环境中相信读者可以通过配置活动目录的密码策略来控制诸如下面一些策略：

 （1）是否采用强密码

  （2）密码长度

  （3）密码过期时间

  （4）验证错误锁定次数

 （5） 账号是否Enable

    而在SQL Server 以往的版本中本地账号上这些控制似乎很弱。在SQL Server 2005中，所有的Login不仅可以通过“用户名/密码”方式进行认证，还可以通过证书方式进行，这对于具有异构操作系统平台的企业CA环境而言，提供了最为便捷的方式。对于Login Policy的配置可以通过内值函数LOGINPROPERTY获得，了解相关的配置策略信息。

图2：配置Login的密码策略

代码示例1：通过LOGINPROPERTY获得Login的安全策略

LOGINPROPERTY ( 'login_name' ,
        { 'IsLocked' | 'IsExpired' | 'IsMustChange'
            |'BadPasswordCount' | 'BadPasswordTime' 
            | 'HistoryLength' | 'LockoutTime'
          | 'PasswordLastSetTime' | 'PasswordHash' } )

示例1．确认用户是否需要修改密码：
SELECT LOGINPROPERTY('WillisJO', 'IsMustChange');
GO

示例2：确认Login是否已经被锁定：
SELECT LOGINPROPERTY('SamirK', 'IsLocked');
GO

图3：配置Principal、Securable与Securable的关系

    在明确上文分层的Principal和分层的Securable之后，相信读者自然而然会发现其实在SQL Server 2005的设计中，权限（Permission）本身也是具有层次性的，可以用DCL语言（GRANT、DENY、REVOKE）来管理与配置它们。下图是一个完整的SQL Server 2005Principal、Securable和Permission的层次嵌套关系：

图4：Principal、Securable和Permission层次嵌套关系

在Management Studio中的配置界面如下：

图5：配置Principal对Securable访问权限的过程

  借助CLR控制.Net Assembly的执行过程

    如上文所说，SQL Server 2005继承了CLR，同时也就将CLR对于.Net Assembly的控制集成到了他的安全体系之中，目的是要确保功能强大的.Net代码不至于伤害到SQL Server或者是他的运行环境。默认情况下SQL Server 2005提供了Safe（安全访问SQL Server内部数据）、External_Aclearcase/" target="_blank" >ccess（以托管方式可以访问SQL Server内部或部分外部资源）和Unsafe（非托管方式，可以直接访问系统平台接口和本地Windows 32 API）三个代码执行范围等级。通过对.Net Assembly配置执行范围等级，可以粗略的控制代码访问范围。不过笔者更建议读者通过配置.Net Framework Configuration完成，这样做的主要好处是一方面可以很容易的通过域策略将配置好的模版作分发，对于整个企业运行环境进行集中管理有很大好处。

    “看我七十二变的”的上下文定义特性

    相信以往信息上线的时候，数据库应用开发人员与数据库管理人员可能会因为应用需要过多的执行能力发生争执，作为数据库管理员（DBA）一般都是按照最小化原则配置访问权限，并且希望应用的执行账号（企业应用中常常会采用代理账号访问数据库）尽量限制在其自己的Schema内部，尤其不要访问注册表、活动目录、媒体资料库等敏感的系统资源。但是，应用规模大了难免出现个别特例，万般无奈之下数据库管理员只得为应用的账号配置一个BUILDIN / Administrators或者Domain Admins级别的权限。这样，如果一旦出现代码注入等问题的时候，威胁的不仅仅是数据库本身，甚至是下层的Windows运行环境。

    SQL Server 2005的Executing Context提供了“七十二变”的办法，可以为调用链中的某个执行步骤配置不同的用户身份，这样即便出现个别系统敏感访问的时候，也只需要为这些步骤配置单独的执行账号。