SQL Server 2005SQL代码安全之权限(3)

一开始，这些规则也使我有点糊涂，但是，当我以后逐渐地越来越多地使用它们时，它们开始变得很重要了。对于规则1来说，因为一个SQL登录仅仅存在于SQL Server世界中，所以，如果它能存取操作系统资源的话，这将是一个巨大的安全漏洞。规则2也很重要，并且它允许模拟。规则3似乎有点严格，但是我怀疑SQL Server小组有点保守，因为上下文切换可能会是一场"管理恶梦"，并且他们仍然确信不会产生安全漏洞问题。

　　外部的存取规则甚至更复杂些。假定运行代码的登录已经成功"越过"上面列举的"重重封锁"，但是，为了存取外部的资源-正如你可能盼望的（并且也许希望），SQL Server并不自动地模拟当前执行上下文。代之的是，它使用SQL Server实例的服务帐户来存取资源。或者，你也可以显式地模拟上下文登录来存取资源。这样做需要使用SqlContext对象的WindowsIdentity属性来调用WindowsIdentity来实现实际的模拟。

　　列表1:在SQLCLR代码中使用模拟

try

{

　//模拟当前SQL安全上下文

　WindowsIdentity CallerIdentity = SqlContext.WindowsIdentity;

　if (CallerIdentity != null)

　{

　　OriginalContext = CallerIdentity.Impersonate();

　　//做一些保护操作

　}

}

catch

{

　//从存取问题中恢复

}

finally

{

　if (OriginalContext != null)

　　OriginalContext.Undo();

}

　　列表1向你展示如何在SQLCLR代码中使用模拟。WindowsImpersonationContext对象属于System.Security.Principal命名空间的一部分并且描述了在你模拟前的Windows用户安全上下文。SqlContext对象属于和SQL Server一起安装的Microsoft.SQL Server.Server命名空间的一部分并且提供在SQL Server主机和SQLCLR代码之间的一个钩子。在这种情况中，它使用WindowsIdentity属性来得到当前安全身份的一个令牌。这是Windows登录的安全上下文-该代码在这一登录下运行。该代码测试是否结果CallerIdentity为null，如果该代码在一种SQL登录下运行时它将为null。最后，它调用WindowsIdentity模拟来实现实际的模拟，并保存原始的上下文以用于当要求恢复到该上下文时。

　　必须理解，仅当执行需要保护的操作（例如打开一文件）时模拟才起作用。一旦它被打开，该代码就不再需要模拟。因此，一旦你完成保护的操作，即恢复回去。

　　最后，通过调用OriginalContext的Undo方法，代码块负责恢复到原始上下文。如果你在函数结束之前不进行恢复，那么SQL Server将引发一个异常。

　　对于模拟也存在一些限制。当该模拟起作用时，你就无法再使用SQL Server实例存取数据或对象。在你再次存取本地数据之前，你必须恢复模拟。这也意味着，进程内数据存取总是发生在会话的当前安全上下文中。

　　有趣的是，一个异步执行的UNSAFE程序集（也就是说，它能够创建线程并且异步地运行代码）永远不会允许进程内数据存取。其实，这并不是一个安全问题而显然是一个可靠性的问题。

　　三、 可信赖的数据库

　　在SAFE程序集和其它权限设置级别之间的另外一个区别是在SQL Server 2005测试期添加的。现在，你必须满足两个要求之一来创建EXTERNAL_ACCESS或UNSAFE程序集：

　　· 数据库所有者（dbo）必须拥有EXTERNAL ACCESS ASSEMBLY权限并且数据库必须拥有TRUSTWORTHY属性集。