SQL Server 2008安全概述(二)

1、4. 授权在验证之后，该考虑验证过的登陆可以做些什么了。在这个领域，SQL Server 2008和SQL Server 2005比之前的版本更加灵活。现在的权限更加细粒度了，因此你可以授予所要求的专门的权限，而不是授权给具有一个固定角色的成员，这很可能会承载比它所需的权限更多的权限。你现在具有更多的要保护的实体，你可以对它们分配更细粒度的权限。除了加强用户数据的保护，关于一个细粒度的要保护的结构信息和元数据现在只可用于具有权限访问这要保护的信息的主体。此完，还可以使用一个机制创建定制权限集合，这个机制允许一个人定义安全上下文，存储过程可以运行在这个上下文之下。此外，SQL Agent 使用灵

2、活的代理scheme 来允许工作步骤运行和访问所要求的资源。所有这些特性使得SQL Server更加复杂但是更加安全。4.1 细粒度权限SQL Server 2008和SQL Server 2005在许多方面比之前的版本更加安全，其中之一就是改进的细粒度权限。之前，一个管理员需要给一个在固定的服务器角色或固定的数据库角色中的用户成员授予权限，以执行特定的操作，但是通常情况是，这些角色具有比执行这些简单工作所需的权限多很多的权限。这个最小权限的原则要求一个用户只有要做这个工作的最少的权限，所以分配给用户广泛的角色以执行很少的工作违反了这个原则。固定服务器和数据库角色的集合从SQL Server

3、2000以来没有怎么改变，所以你仍然可以在用户或应用程序要求所有或大部分定义的权限时利用这些预定义的权限集。可能最大的改变就是添加了一个public服务器角色。然而，最小权限的原则要求你不使用一个不是正好适用于这个原则做这个工作所需要的角色。尽管它要求更多的工作来发现和指派某原则所需的权限，但是它可以生成一个更加安全的数据库环境。4.2 主体和可得到的在SQL Server 2008中，一个主体是任何单独的、可以要求访问受保护的资源并可被授予权限来访问它的个体、组或过程。在SQL Server的之前版本中，你可以定义一个Windows中的主体或者你将它基于一个SQL Server登陆而不和Wi

4、ndows主体关联。下面的列表显示了SQL Server 2008主体的层次，不包括固定服务器和数据库角色，以及你可以怎样匹配登陆和数据库用户来保护对象。这个主体的影响范围取决于它的定义的范围，因此一个Windows级别的主体比一个SQL Server级别的主体范围更广。每一个数据库用户会自动地属于固定的公共(public)角色。Windows级别主体· Windows域登陆· Windows本地登陆· Windows组SQL Server级别主体· SQL Server登陆· 与一个Windows 登陆相匹配的SQL Server登陆

5、3; 与一个证书相匹配的SQL Server登陆· 与一个非对称密钥相匹配的SQL Server登陆数据库级别的主体· 数据库用户· 与一个SQL Server登陆相匹配的数据库用户· 与一个Windows 登陆相匹配的数据库用户· 与一个证书相匹配的数据库用户· 与一个非对称密钥相匹配的数据库用户· 数据库角色· 应用程序角色· 公共角色授权的另一个部分是你可以通过授予或拒绝授予权限来保护的对象。图4列出了SQL Server 2008中可保护的对象的层次。在服务器级别，你可以保护网络终端来控制通信路线

6、进出服务器，还有数据库、绑定和角色以及登陆。在数据库和schema级别，事实上你可以创建的每一个对象都是可得到的，包括那些存在于schema之中的。图 4在SQL Server 2008中的可得到的对象的层次4.3 角色和权限要想知道在SQL Server中可用的权限的数目，你可以调用fn_builtin_permissions系统功能：以下是引用片段：SELECT * FROM sys.fn_builtin_permissions(default)这些是SQL Server 2005中的新的权限类型：· CONTROL。 授予所有者想要的权限，这些权限可以有效地对这个对象授予所有定

7、义的权限，并且所有对象在它的范围内，包括授予其它受权人任何权限的能力。CONTROL SERVER授予等价于sysadmin的权限。· ALTER。授予权限来修改可得到的对象的任何属性，除了修改所属关系。固定地授予权限给相同范围内的ALTER、CREATE或 DROP 可得到的对象。例如，授予一个数据库上的ALTER权限，包括修改它的表。· ALTER ANY <可得到的对象>。 授予权限以修改可得到的指定类型的对象。例如，授予ALTER ANY ASSEMBLY允许修改数据库中的任何.NET 集合，而在服务器级别授予ALTER ANY LOGIN 使得用户修改

8、任何在服务器上的登陆。· IMPERSONATE ON <登陆或用户>。 授予权限来模拟特定的用户或登陆。你在本篇文章的后面可以看到，这个权限对于为存储过程转换执行上下文是很必要的。你在一个批处理中进行模拟也需要这个权限。· TAKE OWNERSHIP。 授予权限给受权人以使用可得到的所有权，使用ALTER AUTHORIZATION语句。SQL Server 2008仍然使用类似的GRANT、DENY和REVOKE scheme来指派或拒绝给一个主体授予对一个可得到的对象的权限。现在ANT 语句涵盖了所有新的权限选项，例如授予的范围和是否主体可以授予这个权限

9、给其它主体。SQL Server 不允许数据库交叉权限。为了授予这样的权限，你要在每一个数据库中创建一个复制的用户，并单独的给每一个数据库用户指派这个权限。如同SQL Server 之前的版本一样，激活一个应用程序角色会在这个角色活动的期限内挂起其它的权限。然而，在SQL Server 2008和SQL Server 2005中，你具有卸载应用程序角色的能力。SQL Server 2000和之后版本的另一个不同之处是，当激活一个应用程序角色时，这个角色还会挂起任何服务器权限，包括public。例如，如果你授予VIEW ANY DEFINITION给public，应用程序不会受益于它。这是当在一

10、个应用程序角色上下文中访问服务器级别的元数据时值得注意的。注意 这个新的首选的应用程序角色选择将使用代码模块中的执行上下文。要获得更多的信息，请查看本文中的执行上下文一节。授予一个特殊的权限可以传递其它暗含的权限。例如在一个schema 上的ALTER 权限暗含了更细粒度和较低级别的权限。图5显示了ALTER SCHEMA暗含的权限。图 5： ALTER SCHEMA 所暗含的权限层次当你考虑可用的主体的数目和类型、服务器和一个典型的数据库中的可得到的对象的数目、可用的权限和隐藏的以及暗含的权限的数目时，“在SQL Server 2008中的细粒度权限是怎样的”就立刻清楚了。现在创建一个数据库

11、要求更细致地分析它的安全需求和谨慎地控制在所有对象上的权限。然而，这个分析是很值得的，在SQL Server 2008中使用这些功能会使得数据库更安全。4.4 元数据安全细粒度权限scheme 的一个好处是SQL Server保护元数据和数据。在SQL Server 2005之前，一个用户对数据库的任何访问都会看到数据库中的所有对象的元数据，无论这个用户是否可以访问其中的数据或执行存储过程。SQL Server 2008检查主体在数据库中具有的权限，并仅当这个主体是所有人或他具有这个对象的一些权限时才可以显示这个对象的元数据。还有一个VIEW DEFINITION 权限可以授予查看元数据信息的

12、权限，它甚至不需要这个对象的其它权限。这个保护扩展到因用户没有权限所做的访问或更新对象的操作所返回的错误信息。不只是承认确实有一个表叫做Address ，还给攻击者一个信息说她被跟踪了，SQL Server返回一个具有选择可能性的错误信息。例如，如果一个用户没有对数据库中的任何对象的权限，他试图删除Address表，那么SQL Server 会显示下面的错误信息：以下是引用片段：Msg 3701, Level 14, State 20, Line 1 Cannot drop the table 'Address', because it does not exist or yo

13、u do not have permission.在这种方式下，攻击者不能确定一个Address表是否真的存在。然而，调试这个问题的人仍然只需要探究有限的可能性。4.5 SQL Server Agent代理在SQL Server 2008中的授权模型的一个最好的例子就是SQL Server Agent。你可以定义许多常常与Windows登陆关联的凭证，链接到具有必要的权限的用户以执行一个或多个SQL Server Agent步骤。然后一个SQL Server Agent 代理会使用一个工作步骤链接这个凭证来提供必要的权限。这为下面的最小权限的主体提供了一个细粒度的方法：授予一个工作步骤所需的权

14、限，除此以外没有其它权限。你可以创建任何数目的代理，将它们的每一个同一个或多个SQL Server Agent子系统关联起来。这是对SQL Server 2000中的所有强大的代理帐户的完全约束，它使得用户可以在任何SQL Server Agent子系统中创建工作步骤。注意 当你对一个SQL Server 2000服务器进行升级的时候，会创建一个单独的代理账户，所有的子系统会被分配到这个单独的代理账户上以便现有的工作可以继续运行。在升级之后，创建凭证和代理账户来实现一组更加安全的、更细粒度的代理来保护服务器资源。图6显示了管理套件中的对象资源管理器和一列SQL Server Agent中可用的

15、子系统。每一个子系统可以有与它关联的一个或多个代理，它们授予这个工作步骤所需的适当的权限。这个scheme的一个例外是Transact-SQL子系统以模块所有者的权限来执行，这和在SQL Server 2000中是一样的。图 6： 你可以将之与代理相关联的SQL Server Agent子系统在一个新安装的SQL Server 之上，只有System Administrator 角色具有维护SQL Server Agent 工作的权限，管理套件资源管理器中的管理面板只对sysadmins开放。SQL Server 2008具有一些其它的、你可以用来授予多级权限的角色。你可以将用户分配到SQLA

16、gentUser、SQLAgentReaderRole或SQLAgentOperator 角色，其中的每一个授予逐渐增长的权限级别来创建、管理和运行工作，或是MaintenanceUser 角色，它具有SQLAgentUser的所有的权限和创建维护计划的能力。sysadmin 角色的成员当然可以在任何子系统中做任何他们想要做的。为了授权给任何其他的用户以使用子系统，要求至少创建一个代理帐户，它可以授权给一个或多个子系统。图7显示一个代理帐户MyProxy怎样被分配到多个主体上，这里是一个用户和一个角色。这个代理帐户使用一个凭证，这个凭证将它链接到一个帐户，通常是一个域帐户，它要具有操作系统执行

17、子系统所要求的所有任务所必需的权限。每一个代理可以有一个或多个相关联的子系统，这些子系统授予主体以运行这些子系统的能力。图 7：用于多个子系统的SQL Server Agent代理帐户下面的代码显示了执行图7所示的scheme所必需的Transact-SQL代码。它一开始创建了一个凭证，一个提供了对具有执行子系统中想要的活动的权限的操作系统帐户的链接的数据库对象。然后它添加一个代理帐户MyProxy，这只是一个用于凭证的友好名称。然后，它将这个代理分派到两个首要角色上，在这里是一个SQL Server登陆和一个定制角色。最后它将这个代理和四个SQL Server Agent子系统的每一个相关联

18、。以下是引用片段：CREATE CREDENTIAL MyCredential WITH IDENTITY = 'MyDOMAINuser1'GOmsdb.sp_add_proxy proxy_name = 'MyProxy',     credential_name = 'MyCredential'GOmsdb.sp_grant_login_to_proxy login_name = 'MyLogin',     proxy_name = 'MyProxy

19、9;GOmsdb.sp_grant_login_to_proxy login_name = 'MyRole',     proxy_name = 'MyProxy'GOsp_grant_proxy_to_subsystem proxy_name = 'MyProxy',     subsystem_name = 'ActiveScripting'GOsp_grant_proxy_to_subsystem proxy_name = 'MyProxy', &#

20、160;   subsystem_name = 'CmdExec'GOsp_grant_proxy_to_subsystem proxy_name = 'MyProxy',     subsystem_name = 'ANALYSISQUERY'GOsp_grant_proxy_to_subsystem proxy_name = 'MyProxy',     subsystem_name = 'DTS'GOSQL Server管理套件提

21、供了对创建凭证和代理的充分支持，如图8所示。它创建了与之前的代码相同的代理。图 8：在SQL Server管理套件中的一个新的SQL Server Agent代理一个代理不是操作系统中围绕安全的一个方式。如果和代理一起使用的凭证没有在Windows中的权限，例如写到网络上的一个目录中，那么代理也没有这个权限。你还可以使用一个代理来授予有限的执行权限给xp_cmdshell ，因为它是攻击者所喜爱的一个工具，一旦他们危及一个SQL Server计算机他们就能扩展他们在网络中的范围。这个代理提供了这个保护，因为即使主体具有在网络上的无限的权限，例如域管理员，但是通过代理执行的任何命令只具有凭证帐户

22、所具有的有限的权限。4.6 执行上下文SQL Server 很久以来就支持所有权链接作为一个确保管理员和应用程序开发人员对访问数据库的入口检查其权限而不是对所有访问的对象的权限进行检查的概念。只要调用模块(存储过程或函数)或者视图的用户具有对这个模块的执行权限，或者具有对视图的选择权限，并且这个模块或视图的所有人是访问对象的所有人(一个所有权链)，那么就不会检查对基本对象具有的权限，而调用者会得到请求的数据。如果所有权链接由于代码的所有者不拥有引用的对象的原因而被破坏了，那么SQL Server将对调用者的安全上下文检查权限。如果调用者具有访问这个对象的权限，那么SQL Server 返回数据

23、。如果她没有，那么SQL Server 将报错。所有权链接有一些局限性;它只适用于数据操作而不适用于动态SQL。进一步的，如果你穿过所有权限定访问对象，所有权链接就不可用。因此，这个预先的权限检查行为只能用于特定的情况。SQL Server 2008具有使用一个执行上下文标识模块的能力，这样在模块中的语句就可以作为与调用用户相反的特殊用户来执行。这个方式，当调用用户仍然需要权限来执行模块时，SQL Server为模块内的语句对模块的执行上下文检查权限。你可以使用这个行动来克服所有权链接的一些缺点，因为它适用于模块内的所有语句。管理员如果想执行预先的权限检查的话可以使用执行上下文来完成这个工作。

24、现在当你定义用户定义的功能(除了在线的值为表的情况)，存储过程和触发器时你可以使用EXECUTE AS 条件来指定SQL Server 使用哪个用户的权限来验证对由以下过程引用的对象和数据的访问：以下是引用片段：CREATE PROCEDURE GetData(Table varchar(40) WITH EXECUTE AS 'User1'SQL Server 提供了四个EXECUTE AS选项。· EXECUTE AS CALLER 指定了在模块的调用者的安全上下文中执行的代码;没有发生身份模拟。调用者必须具有对所有引用的对象的访问权限。然而，SQL Server

25、 只检查对所有权断链的权限，所以如果这个代码的所有者还拥有后台的对象，那么只会检查模块的执行权限。这是向后兼容性的默认执行上下文。· EXECUTE AS 'user_name' 指定了代码执行在指定用户的安全上下文下。如果你不想依赖于所有权链那么这是一个很好的选择。相反，你创建一个具有必要权限的用户来允许这个代码和创建定制的权限集合。· EXECUTE AS SELF 是一个缩写符号，用于指定要创建或修改这个模块的用户的安全上下文。SQL Server 在内部保存和这个模块相关联的实际的用户名称，而不是“SELF”。· EXECUTE AS OW

26、NER 指定这个安全上下文是模块执行时的模块当前所有者的安全上下文。如果这个模块没有所有者，那么使用所包含的schema的所有者的上下文。当你想能够改变这个模块的所有者而不改变模块本身的时候这是一个很好的选择。只要用户上下文使用EXECUTE AS选项进行变更，那么模块的创建者或更改者必须具有对指定的用户的IMPERSONATE权限。你不能从数据库中删除指定的用户，除非你将所有模块的执行上下文更改为其它的用户。4.7 用户/schema分离SQL Server 2000没有schema的概念，而在ANSI SQL-99规范中将schema定义为一个数据库对象的集合，由形成了对象的一个单独的命名

27、空间的一个单独的主体所有。Schema是数据库对象的一个容器，例如表、视图、存储过程、函数、类型和触发器。它在.NET框架中更多的是作为一个命名空间函数，而XML是一种组织对象的方式，以便数据库可以重用对象名称，例如允许dbo.Customer和Fred.Customer存在于一个单独的数据库中，并将对象分类到不同的所有者下面。注意你将需要使用目录视图例如sys.database_sys.principals、sys.schemas, sys.objects等等。因为老的sysobjects系统表不支持schemas，因此不能支持U/S分离。此外，老的目录视图是不被支持的，所以它们在SQL S

28、erver的未来版本中将被删除。图9的上面部分显示了SQL Server 2000中schemas是怎样工作的。当一个管理员在数据库中创建一个用户Alice 时，SQL Server 会自动地创建一个隐藏在用户Alice之后的schema Alice。如果Alice 登陆到一个运行SQL Server而他没有所有权的服务器上创建Table1，那么表的实际名称是Alice.Table1。Alice 创建的其它对象也是一样，例如Alice.StoredProcedure1和Alice.View1。如果Alice 是一个数据库所有人或者是sysadmin ，那么她创建的对象将是dbo schema的

29、一部分。尽管我们习惯说dbo拥有对象，但是它其实是一回事。图 9：在SQL Server 2000和2008中的用户/schema/对象在SQL Server 2000 中当你需要改变对象的所有权时就会遇到用户和schemas的统一问题，例如当Alice离开公司而Lucinda接替了Alice的工作。那么一个系统管理员需要将Alice所拥有的所有对象的所有权改变为Lucinda的。一个更大的问题是在Lucinda具有了表的所有权之后你需要将所有涉及到Alice.Table1的Transact-SQL或客户端应用程序代码改变为Lucinda.Table1。这取决于Alice所拥有的对象的数目和有

30、多少应用程序中内嵌了这个名字;这是一个很大的消耗。Microsoft很久以前就建议内置的dbo用户拥有所有的数据库对象来解决这些问题。更改一个数据库所有权比更改许多对象和客户端应用程序要容易得多。注意 不要被SQL Server 2000的CREATE SCHEMA语句混淆。这只是一个创建特定用户所拥有的表和视图和授权的简便方法。你可以使用这个语句来命名一个schema的所有者但是不能命名这个schema。因为要改变所有权的问题，SQL Server仍然不能将所有者链接到schema上。SQL Server 2008通过将用户和schema分离开来从而解决了这个问题并实现了SQL-99 sch

31、ema，如图9的下面部分所示。当你使用新的CREATE USER DDL创建一个新的用户Alice，SQL Server不再自动地创建具有相同名称的schema。相反地，你必须显式创建一个schema并将它的所有权分配给一个用户。因为显示的所有数据库对象现在包含在Schema1 schema中，这是Alice一开始拥有的，因此通过简单地更改schema的所有权给Lucinda来更改所有的schema对象的所有权就很简单了。每一个用户还可以拥有一个分配给它的默认的schema，因此SQL Server假定在默认的schema中，所有对象按名称引用而没有按schema引用。在图9的下面部分，如果A

32、lice将Schema1作为她的默认schema，那么她可以将这个表作为Schema1.Table1或简单地作为Table1。用户Carol可能没有一个默认的与她的用户名关联的schema，她需要将这个表作为Schema1.Table1。任何没有定义默认schema的用户默认的schema是dbo。在SQL Server 2008中完全标准的对象名称具有一个四部分组成的结构，这与SQL Server之前版本中的类似：server.database.schema.object如同在之前版本中的一样，如果对象是在代码运行的同一台服务器上那么你可以省略服务器名称。如果连接打开了同一个数据库那么你可以忽略数据库名称。而如果它是当前用户默认的schema或者是dbo所拥有的，那么你可以忽略schema 名称，因为那是当SQL S