| |
注意我们仍然没有授权任何组或帐户访问数据库。事实上，我们不能通过Enterprise Manager授权数据库访问，因为Enterprise Manager的用户界面只允许我们把数据库访问权限授予合法的登录帐户。SQL Server不要求NT帐户在我们把它设置为数据库角色的成员或分配对象权限之前能够访问数据库，但Enterprise Manager有这种限制。尽管如此，只要我们使用的是sp_addrolemember存储过程而不是Enterprise Manager，就可以在不授予域内NT帐户数据库访问权限的情况下为任意NT帐户分配权限。
到这里为止，对Model数据库的设置已经完成。但是，如果你的用户群体对企业范围内各个应用数据库有着类似的访问要求，你可以把下面这些操作移到Model数据库上进行，而不是在面向特定应用的数据库上进行。
四、允许数据库访问
在数据库内部，与迄今为止我们对登录验证的处理方式不同，我们可以把权限分配给角色而不是直接把它们分配给全局组。这种能力使得我们能够轻松地在安全策略中使用SQL Server验证的登录。即使你从来没有想要使用SQL Server登录帐户，本文仍旧建议分配权限给角色，因为这样你能够为未来可能出现的变化做好准备。
创建了数据库之后，我们可以用sp_grantdbaccess存储过程授权DB_Name Users组访问它。但应该注意的是，与sp_grantdbaccess对应的sp_denydbaccess存储过程并不存在，也就是说，你不能按照拒绝对服务器访问的方法拒绝对数据库的访问。如果要拒绝数据库访问，我们可以创建另外一个名为DB_Name Denied Users的全局组，授权它访问数据库，然后把它设置为db_denydatareader以及db_denydatawriter角色的成员。注意SQL语句权限的分配，这里的角色只限制对对象的访问，但不限制对DDL（Data Definition Language，数据定义语言）命令的访问。
正如对登录过程的处理，如果访问标记中的任意SID已经在Sysusers系统表登记，SQL将允许用户访问数据库。因此，我们既可以通过用户的个人NT帐户SID授权用户访问数据库，也可以通过用户所在的一个（或者多个）组的SID授权。为了简化管理，我们可以创建一个名为DB_Name Users的拥有数据库访问权限的全局组，同时不把访问权授予所有其他的组。这样，我们只需简单地在一个全局组中添加或者删除成员就可以增加或者减少数据库用户。
五、分配权限
实施安全策略的最后一个步骤是创建用户定义的数据库角色，然后分配权限。完成这个步骤最简单的方法是创建一些名字与全局组名字配套的角色。例如对于前面例子中的会计系统，我们可以创建Accounting Data Entry Operators、Accounting Data Entry Managers之类的角色。由于会计数据库中的角色与帐务处理任务有关，你可能想要缩短这些角色的名字。然而，如果角色名字与全局组的名字配套，你可以减少混乱，能够更方便地判断出哪些组属于特定的角色。
创建好角色之后就可以分配权限。在这个过程中，我们只需用到标准的GRANT、REVOKE和DENY命令。但应该注意DENY权限，这个权限优先于所有其他权限。如果用户是任意具有DENY权限的角色或者组的成员，SQL Server将拒绝用户访问对象。
接下来我们就可以加入所有SQL Server验证的登录。用户定义的数据库角色可以包含SQL Server登录以及NT全局组、本地组、个人帐户，这是它最宝贵的特点之一。用户定义的数据库角色可以作为各种登录的通用容器，我们使用用户定义角色而不是直接把权限分配给全局组的主要原因就在于此。
由于内建的角色一般适用于整个数据库而不是单独的对象，因此这里建议你只使用两个内建的数据库角色,，即db_securityadmin和db_owner。其他内建数据库角色，例如db_datareader，它授予对数据库里面所有对象的SELECT权限。虽然你可以用db_datareader角色授予SELECT权限，然后有选择地对个别用户或组拒绝SELECT权限，但使用这种方法时，你可能忘记为某些用户或者对象设置权限。一种更简单、更直接而且不容易出现错误的方法是为这些特殊的用户创建一个用户定义的角色，然后只把那些用户访问对象所需要的权限授予这个用户定义的角色。 |
| 【收藏】【打印】【进入论坛】 |
|
|
|
|
| |
|
|
|
