第十三周翻译(Stairway to SQL Server Security Level 3: Principals and Securables)

SQL Server 安全级别3的阶梯: 管理员和安全性

该系列是阶梯系列的一部分:SQL Server Security的阶梯。

SQL Server提供了保护服务器和数据免受当今复杂攻击所需的一切。但是在您能够有效地使用这些安全特性之前,您需要了解您所面临的威胁和一些基本的安全概念。第一个阶梯级别提供了一个基础,这样您就可以充分利用SQL Server中的安全特性,而不必将时间浪费在无法保护数据免受特定威胁的特性上。

 通常,通过将对象的权限分配给主体,可以在SQLServer中实现用户和对象的安全性。但是什么是SQL Server主体呢?它得到了什么许可?在这个阶梯级别中,您将了解可以通过权限授权的各种主体,以执行操作并访问SQL Server实例中的可保护对象。SQL Server中一组重要的主体是角色,您将了解角色如何使管理安全性比将单个用户作为唯一类型的主体更容易。您还将了解SQL Server中可安全使用的对象,并将其设置为了解下一层的权限。

 授权

 级别2的身份验证只是访问数据库服务器中的所有优点的一部分。身份验证有点像护照,可以证明你是谁,但没有签证——你需要签证才能进入这个国家,在这个国家四处走动。在这个级别中,您将了解授权以及它如何作为提供对数据库对象访问的签证。

 主体是可以访问SQL服务器或其数据库中的一个或多个可保护对象的用户或进程。可使用的对象(或仅可实现的)是受保护的资源,只有特定的人员或进程可以查看或更改,例如表中的数据。权限使主体能够获得可获得的特定类型的访问权限。

 继续这个护照类比,校长是护照的持有者,护照上有照片的人。最安全的是校长想要访问的国家,而许可则是跨越国家边境并享受访问的签证。

 主体

 在安全性上下文中,主体是任何用户(人类类型)、用户组(在SQL Server中称为角色)或运行在进程中的代码,该进程可以请求对可保护对象的访问,并授予或拒绝对该对象的访问权。所有Windows和SQL Server登录都是主体,以及它们在数据库中映射到的用户。下面的列表显示了SQL Server中大多数更重要的主体的层次结构,从服务器范围的主体到SQL Server实例的权限,再到数据库级的主体:

 windows级别主体

 Windows域登录

Windows组

Windows本地登录

SQL服务器级主体

SQL Server登录

将SQL Server登录映射到证书。

SQL Server登录映射到Windows登录。

SQL Server登录映射到非对称密钥

数据库级的主体

应用程序角色

数据库的作用

数据库用户

数据库用户映射到证书

数据库用户映射到Windows登录。

数据库用户映射到非对称密钥

公共角色

 理解这个层次结构很重要,因为主体的范围部分地决定了授予它的权限的范围。例如,数据库用户只能在该数据库的上下文中授予其权限。SQL server级主体可以在整个服务器上具有权限,而Windows级主体可以具有超出SQL server范围的权限,可以扩展到Windows的本地实例和整个网络。

请注意,在前面的列表中,主体可以是登录(或用户)和角色。SQL Server中的角色类似于Windows组。拥有角色成员资格的用户继承分配给角色的权限。角色使安全管理更容易,因为您不需要为单个用户管理复杂的权限集。SQL Server支持以下几种角色:

固定服务器角色:用于执行服务器级任务的SQL server内置角色。

用户定义的服务器角色:您创建的自定义服务器角色,分配服务器级别的权限,并分配登录,以便它们继承服务器对象的权限。

固定数据库角色:用于执行数据库任务和分配基本权限的内置角色。

用户定义的数据库角色:您创建的自定义数据库角色,为其分配权限,然后向其添加用户,以便用户继承数据库对象上的权限。

 

您可以将用户分配到多个角色。角色也可以是嵌套的,但是不要太过分——如果你的嵌套方案太复杂了,你就会受到性能的惩罚,而且它会使维护和故障排除成为一场噩梦。

固定服务器角色

固定服务器角色是SQL server中的内置角色,您不能以任何方式更改它们——您只能向它们添加登录。它们只存在于服务器级,用于执行管理任务。这里列出了SQL server中的固定服务器角色,括号中列出了实际的角色名:

系统管理员(sysadmin):在SQL Server实例中执行任何活动。这个角色包含所有其他的角色—一旦用户是sysadmin的成员,他们就不需要任何其他角色。sysadmin的成员可以做任何他们想做的事情,所以最好将成员限制在那些需要的人,并且可以信任他们拥有无限制的访问权限。

批量插入管理员(bulkadmin):执行批量插入语句以快速将数据导入数据库。

数据库创建者(dbcreator):创建和修改数据库。

磁盘管理员(diskadmin):管理存储数据库的各种磁盘文件。

流程管理员(processadmin):管理在SQL Server中运行的进程。

服务器管理员(服务器管理员):配置服务器范围的设置。尽管名称与系统管理员相似,但serveradmin是一个非常不同的、非常有限的角色。

安装管理员(setupadmin):安装复制和管理扩展过程。

安全管理员(securityadmin):管理服务器的登录。

固定服务器角色提供了灵活性和安全性,允许您将服务器任务划分为多个部分。换句话说,如果某人只需要创建数据库,那么您不必让他成为系统管理员。相反,让它们成为dbcreator的成员,它们拥有所需的所有权限。

您可以使用Management Studio或Transact-SQL将登录名分配给一个固定的服务器角色。要使用ManagementStudio,请执行以下步骤:

提示:

这段阶梯第2层的代码创建了Topaz登录。如果您没有创建登录,可以运行该代码来创建它,或者使用第2级中讨论的技术创建您自己的登录。如果您执行后者,请根据需要调整使用该登录的步骤。

 

1. 展开Management Studio中的Object Explorer的安全性部分,以显示登录的列表。

2. 右键单击Topaz登录并从弹出菜单中选择Properties。

3. 在“登录属性”对话框中,选择“服务器角色”页面。这将列出所有可用的服务器角色,并使用一个复选框来添加登录。注意,Topaz和所有登录者一样,已经是公共角色的成员。

4. 为dbcreator和diskadmin角色分配登录。图3.1显示了登录Topaz的对话框。


    5.单击OK保存更改。

或者,您可以使用对象资源管理器中的安全节点下的服务器角色节点添加登录到角色。将Topaz添加到securityadmin服务器角色:

    1.在对象资源管理器的安全节点下展开服务器角色节点。

    2.右键单击Object Explorer中的securityadmin服务器角色并选择Properties。这将打开“服务器角色属性”对话框。

    3.单击对话框右下方的Add按钮,将打开Select Logins对话框。您可以输入Topaz并单击 Names,或者单击Browse按钮以获取登录列表。输入黄玉后,对话框如图3.2所示。

    4.单击OK将Topaz添加到服务器角色。服务器角色属性对话框如图3.3所示。


    5.单击OK保存更改。

 另一种向服务器角色添加登录的方法是使用Transact-SQL,方法是使用sp_addsrvrolemember系统存储过程。以下代码将现有的登录Topaz添加到sysadmin角色:

  1. 在对象资源管理器中 展开安全节点下的服务器角色节点。
  2. 在对象资源管理器中 右键单击securityadmin服务器角色,然后选择“ 属性”。这将打开“服务器角色属性”对话框。
  3. 点击对话框右下角的Add按钮,打开Select Logins对话框。您可以键入Topaz并单击检查名称,或者单击浏览按钮以获取登录列表。一旦你输入Topaz,对话框如图3.2所示。

  1. 点击OK将Topaz添加到服务器角色。服务器角色属性对话框如图3.3所示。


  1. 点击确定保存更改。

另一种通过使用sp_addsrvrolemember系统存储过程在Transact-SQL中添加登录到服务器角色的方法。以下代码将现有的登录Topaz添加到sysadmin角色:


 例3.1:向服务器角色添加登录的代码。

 通过运行两个存储过程,sp_helpsrvrole和sp_helpsrvrolemember,您可以找到关于固定服务器角色的信息。如果您将服务器角色的有效名称传递给sp_helpsrvrole,它将显示该角色的描述;否则,它将显示所有服务器角色。图3.4显示了在Management Studio中执行的两个系统存储过程,以显示securityadmin角色及其当前成员的描述。


 用户定义的服务器角色

 SQL Server 2012中等待已久的安全特性是用户定义的服务器角色。SQL Server长期以来都有灵活的用户定义数据库角色用于数据库级别的权限(您将在稍后的级别中了解这一点),但是使用自定义服务器角色,您最终可以通过服务器级别的权限获得粒度化的数据库角色。

 在旧版本的SQL Server中,向用户授予某种权限的唯一方法是将它们分配到一个内置的固定服务器角色,这个角色通常有太多的权限。让每个人都成为系统管理员是一种可怕但又常见的实践,尤其是有问题的,因为您无法否认系统管理员的任何事情。这在很大程度上违背了特权最小的原则,但通常是一种实际的需要。SQL Server 2005和后来的SQL Server都更细粒度了,允许您为用户分配任何特定的服务器级权限,但缺乏将这些权限分组到服务器角色的能力。

 SQL Server 2012通过支持用户定义的服务器角色解决了这个问题。创建一个新的服务器角色就像使用CREATE server角色语句一样简单:


 例3.2:创建新服务器角色的代码。

 然后您可以授予和拒绝角色任何您想要的服务器级权限。下面的代码将控制服务器权限授予新的角色——类似于授予sysadmin特权——然后拒绝一些权限来限制服务器角色成员的特权。这是一种非常灵活的方式,可以授予属于组特定权限的用户。


例3.3:添加和拒绝服务器角色权限的代码。

 为了测试这个角色,清单3-4中的代码创建了一个与Windows组,dba,在名为Marathon的机器上的登录,并将新的登录添加到有限dba角色中。

 提示:

在运行此代码之前,dba组必须在Windows的本地实例上存在。您可以进入控制面板的计算机管理applet创建它,扩展系统工具和本地用户和组节点,并将其添加到组节点。同时,将机器名从Marathon更改为本地机器。


 例3.4:创建登录并将其添加到服务器角色的代码。

 然后,清单3.5中的代码创建一个SQL服务器登录卡罗尔,在SQL Server实例中没有任何权限。然后代码在carol的安全上下文中尝试各种需要服务器级权限的操作:创建另一个登录、查看系统信息,并创建另一个服务器角色。所有这些操作都失败了,您可以在图3.5中看到,因为carol principal没有执行这些操作的权限。


 例3.5:创建一个登录和测试的代码,看看它是否具有特定的权限。

 提示:

此代码不检查SQL Server实例中是否存在现有的carol登录。如果存在,则创建登录语句将失败。在这种情况下,跳过这个语句。


 接下来,代码将carol添加到新的LimitedDBA用户定义的服务器角色中,并再次尝试执行相同的操作。如图3.6所示,这一次carol能够获得系统信息(SELECT action),因为该权限是通过CONTROL SERVER权限授予的。但是carol仍然不能创建登录或服务器角色,因为这些权限被LimitedDBA角色显式地拒绝。


例3.6:代码再次测试服务器角色的成员是否具有特定的权限。


 为了查看可以授予和拒绝服务器角色的所有可用服务器级权限,执行以下代码。图3.7显示了结果。


 例3.7:查看所有可用服务器级权限的代码。


您可以创建用户定义的服务器角色来授予用户和组一组非常特定的权限,这些权限是他们需要完成工作的,而不是更多。这要比SQL Server的早期版本灵活得多,使用SQL Server 2012,安全管理要容易得多,更容易的管理必然意味着更安全的服务器。

 固定数据库角色

 固定的数据库角色存在于数据库级别,而不是服务器级别,并且仅在该数据库中控制授权。每个数据库都有自己的固定数据库角色集合,因此可以分别配置每个数据库中的角色。固定的数据库角色类似于固定的服务器角色,因为它们不能被删除、修改或更改,但是您可以将数据库用户和用户定义的角色添加为成员。固定的数据库角色是:

       db_accessadmin:可以在数据库中添加或删除Windows登录和组和SQL Server登录。

db_backupoperator:可以备份数据库。

db_datareader:可以从数据库中的所有用户表中查看任何数据。

db_datawriter:可以在数据库中的所有用户表中添加、更改或删除数据。

db_ddladmin:可以在数据库中添加、修改或删除对象。(DDL表示数据定义语言,即对数据库进行结构性更改的Transact-SQL命令的集合。)

db_denydatareader:无法查看数据库中的任何数据。

db_denydatawriter:不能更改数据库中的任何数据。

db_owner:可以执行所有数据库角色的活动以及维护和配置活动。这个角色包含所有其他角色,因此它本质上是这个数据库的管理员。

db_securityadmin:可以管理数据库中的角色成员关系、语句和对象权限。

 固定的数据库角色可以简化数据库中的权限分配。例如,假设您希望允许用户访问一个特定的数据库,但只支持它。您不希望用户能够读取数据,只需备份数据即可。通过使用户成为db_backupoperator和db_denydatareader角色的成员,您可以轻松地实现这一点。使用sp_helprole和sp_helprolemember系统存储过程来查看关于数据库角色的信息。

 公共角色和访客用户

 有几个特殊的原则需要提及。您不太可能以任何有意义的方式使用这些主体,但它们确实会影响安全性,因此您需要知道它们是什么。

 公共角色是一个特殊的服务器角色,不能被删除。每个数据库用户都属于这个公共角色,所以不需要为它分配用户、组或角色。每个SQL Server数据库都包含公共角色,包括master、msdb、tempdb和model。但是,您可以根据安全需要授予或限制公共角色的权限。关于public角色,需要记住的重要一点是,您授予给public的权限可以应用到所有数据库用户。

 提示:

通常,您希望限制您授予公共角色的权限,因为向每个人授予权限很少导致安全数据库。

 guest用户存在于每个数据库中,包括像master和model这样的系统数据库。作为用户,它继承公共角色的权限。当没有将服务器登录映射到特定数据库中的用户时,它将发挥作用。默认情况下,访客用户没有权限,但是您可以授予访问数据库对象和在数据库中执行操作的权限。正如您可能期望的那样,这是一件非常危险的事情,在为数据库服务器设计良好的安全方案中很少需要这样做,您应该避免为该用户分配权限。虽然不能删除该用户,但是应该使用清单3.8中的代码撤销其连接权限,从而在用户数据库中禁用该用户。


 例3.8:在用户数据库中通过撤销其连接权限来禁用来宾用户的代码。

 提示:

不要禁用系统数据库中的来宾用户,这会导致您不想处理的问题!这些数据库需要客户用户提供各种功能。

 dbo用户和模式

 dbo是每个数据库中映射到sysadmin固定服务器角色的特殊用户帐户。这意味着,如果您是sysadmin角色的成员,并在任何数据库中创建对象,那么该对象的所有者将是dbo,而不是您。您不能删除dbo用户,它只映射到sysadmin,而不是数据库所有者(db_owner)。这可能令人困惑,因为dbo用户实际上与db_owner角色没有任何关系。

 每个数据库都有一个dbo用户拥有的dbo模式,并且是dbo用户的默认模式。因此,当您以sysadmin访问数据库并创建对象而不指定模式时,它的两部分名称将是dbo.objectname。如果没有指定模式名,那么dbo模式也是任何其他用户访问数据时的辅助默认模式。如果用户joe试图访问一个名为sales的表,SQL Server将首先检查用户joe的默认模式中是否有一个sales表,如果没有,它将检查dbo模式中是否有一个sales表。只有当两种模式中都不存在sales时,才会产生无法找到对象的错误。最佳实践是始终为访问的每个对象指定模式名。

 用户定义的数据库角色

数据库角色并不局限于预定义的滚动,您可以创建自己的角色。用户可以定义两种类型的数据库角色:

标准角色:使用此角色简化对用户组的权限分配。您可以嵌套固定的数据库角色或其他用户定义的角色,并将用户分配给角色,在这种情况下,他们继承角色的权限。

应用程序角色:应用程序使用这个角色来允许应用程序或连接登录到数据库并通过提供角色名和密码来激活应用程序角色。您不能向应用程序角色添加您对其他角色的处理方式,并且一旦激活,应用程序角色的权限将应用于连接的持续时间。用户可能拥有的任何单独权限都将被挂起,并且只检查应用程序角色的权限。

提示:

您可以向一个固定的数据库角色添加用户定义的角色,就像向一个固定的数据库角色添加用户一样:通过固定的数据库角色的属性对话框。

 可获得的对象

 可保护对象是可以控制访问的受保护资源。通常它是一个物理的东西,或者至少像一个数字对象一样是物理的东西!但是,安全也可以是操作,即对数据库或SQL Server实例进行某种更改的能力。例如,管理员可以授予主体获取对象所有权的能力。授予此权限不会立即改变对象的所有权;它只是让校长有能力在将来的某个时候做这件事。

 图3.8显示了SQL Server实例中的大多数可保护对象。服务器级安全对象具有最广泛的范围,包括所有SQLServer,包括影响主体对所有数据库进行更改的能力的权限。数据库范围包含特定数据库中的所有对象,比如用于管理用户和创建加密密钥的对象。模式作用域包括模式中的所有对象——本质上是数据库的数据结构,包括表及其数据。数据库可以包含许多模式,每个模式都可以包含完整的数据库对象集的子集。使模式强大的是,您可以在模式上分配和拒绝权限,并且这些权限适用于模式所包含的所有对象。

 

重要的是要理解,在服务器级授予权限通常意味着在更小的范围内授予权限。例如,授予数据库级权限可能意味着主体对一个或所有数据库模式中的对象具有隐含的权限。

 总结

 在SQL Server安全性的阶梯中,您了解了授权的第一部分、SQL Server及其数据库实例中可用的主体和可保护对象。在下一个级别中,您将了解权限,当授予可保护对象上的主体时,该权限会授予或剥夺主体对该对象进行某些操作的能力。有了这种理解,您将能够有效地利用SQL Server中的身份验证和授权的粒度特性,在允许授权用户和流程完成其工作的同时,对数据库资产保持严格的控制。


猜你喜欢

转载自blog.csdn.net/MonGo17/article/details/80554972