面向数据库管理员的SQL Server 2008安全性概述

核心提示：执行上下文一直以来，SQL Server 都支持所有权链的概念，面向数据库管理员的SQL Server 2008安全性概述(10)，它可确保管理员和应用程序开发人员能够在数据库的入口点提前检查权限，而不是用来提供所有被访问对象的权限，Carol 用户可能没有与其名字关联的默认架构，必须将该表命名为 Schema1.Ta

执行上下文

一直以来，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 的未来版本中它们将被删除。

需要修改对象的所有权时，例如 Alice 离开公司而 Lucinda 接手了 Alice 的工作，此时SQL Server 2000 中用户和架构的融合会产生一个问题。系统管理员必须将 Alice 拥有的所有对象的所有者改为Lucinda。更成问题的是，则 Lucinda 拥有了表的所有权后，还必须将任何引用 Alice.Table1 的Transact-SQL 或客户端应用程序代码改为引用 Lucinda.Table1。根据 Alice 拥有的对象数量以及内部嵌有该名称的应用程序数量，这可能是一项繁重的工作。Microsoft 公司一直建议内置的 dbo 用户要拥有所有的数据库对象，以避免产生这些问题。与修改许多对象和客户端应用程序相比，修改数据库的所有权要容易得多。

注意：不要被 SQLServer2000 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 作为默认架构。