SQL Server 2008的元数据安全

SQL Server 2008 仔细检查数据库中主体所拥有的各种权限，仅当主体具有所有者身份或拥有对象的某些权限时，才会显示该对象的元数据。还有一种 VIEW DEFINITION 权限，即使没有该对象的其他权限，利用它也能查看元数据信息。 　　细粒度权限架构的一个优点就是 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 中的方式相同。

新安装了 SQL Server 之后，只有 System Administrator 角色有权维护 SQL Server Agent工作，而且只有 sysadmins 能够使用 Management Studio Object Explorer 中的管理窗格。SQL Server 2008 允许用户利用其它一些角色授予各种级别的权限。可以分配用户 SQLAgentUser、SQLAgentReaderRole 或 SQLAgentOperator 角色，其中每一个角色都会分配级别逐渐提高的权限，以创建、管理及运行工作，也可分配 MaintenanceUser 角色，它拥有 SQLAgentUser 的所有权限，还能创建维护计划。

　　当然，sysadmin 角色的成员可以在任何子系统中随意执行任何操作。要授予其他任何用户使用子系统到权限，需要创建至少一个代理帐户，这可授予访问一个或多个子系统的权利。图7显示了如何将代理帐户 MyPRoxy 分配多个主体，这里包括一位用户和一个角色。代理帐户使用凭证，将其链接到帐户，通常是链接到域帐户，并且拥有在操作系统中执行各种任务的权限，这些权限也是子系统所必需的。每个代理都拥有一个或多个与之相关的子系统，它们使主体能够运行这些子系统。

　　下列代码就是实施图7所示架构所需的 Transact-SQL 代码。首先创建凭证和一个数据库对象，后者将提供操作系统帐户链接，该帐户有权在子系统中执行所需动作。然后它添加 MyProxy 代理帐户，该帐户其实只是凭证的友好名称。接着，它将代理分配两个主体，就是 SQL Server 登录和定制角色。最后，它使代理与4个 SQL Server Agent 子系统相关联。

　　 CREATE CREDENTIAL MyCredential WITH IDENTITY = MyDOMAINuser1
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所示。这将创建与上一段代码相同的代理。

　　代理不只是操作系统中杜绝安全问题的一种方式。如果与代理一起使用的凭证没有 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 的未来版本中它们将被删除。

　　顶端就是 SQL Server 2000中的架构工作原理。当管理员在数据库中创建 Alice 用户时， SQL Server 将自动创