构造安全策略的下一个步骤是确定用户应该属于什么组。通常,每一个组织或应用程序的用户都可以按照他们对数据的特定访问要求分成许多类别。例如,会 计应用软件的用户一般包括:数据输入操作员,数据输入管理员,报表编写员,会计师,审计员,财务经理等。每一组用户都有不同的数据库访问要求。控制数据访问权限最简单的方法是,对于每一组用户,分别地为它创建一个满足该组用户权限要求的、域内全局有效的组。我们既可以为每一个应用分别创建 组,也可以创建适用于整个企业的、涵盖广泛用户类别的组。然而,如果你想要能够精确地了解组成员可以做些什么,为每一个应用程序分别创建组是一种较好的选 择。例如,在前面的会计系统中,我们应该创建Data Entry Operators、Accounting Data Entry Managers等组。请记住,为了简化管理,最好为组取一个能够明确表示出作用的名字。
除了面向特定应用程序的组之外,我们还需要几个基本组。基本组的成员负责管理服务器。按照习惯,我们可以创建下面这些基本组:SQL Server Administrators,SQL Server Users,SQL Server Denied Users,SQL Server DB Creators,SQL Server Security Operators,SQL Server Database Security Operators,SQL Server Developers,以及 DB_Name Users(其中DB_Name是服务器上一个数据库的名字)。当然,如果必要的话,你还可以创建其他组。创建了全局组之后,接下来我们可以授予它们访问SQL Server的权限。首先为SQL Server Users创建一个NT验证的登录并授予它登录权限,把Master数据库设置为它的默认数据库,但不要授予它访问任何其他数据库的权限,也不要把这个登 录帐户设置为任何服务器角色的成员。接着再为SQL Server Denied Users重复这个过程,但这次要拒绝登录访问。在SQL Server中,拒绝权限始终优先。创建了这两个组之后,我们就有了一种允许或拒绝用户访问服务器的便捷方法。
为那些没有直接在Sysxlogins系统表里面登记的组授权时,我们不能使用Enterpris Managr,因为Enterprise Manager只允许我们从现有登录名字的列表选择,而不是域内所有组的列表。要访问所有的组,请打开Query Analyzer,然后用系统存储过程sp_addsrvrolemember以及sp_addrolemember进行授权。对于操作服务器的各个组,我们可以用sp_addsrvrolemember存储过程把各个登录加入到合适的服务器角色:SQL Server Administrators成为Sysadmins角色的成员,SQL Server DB Creators成为Dbcreator角色的成员,SQL Server Security Operators成为Securityadmin角色的成员。注意sp_addsrvrolemember存储过程的第一个参数要求是帐户的完整路径。 例如,BigCo域的JoeS应该是bigco/joes(如果你想用本地帐户,则路径应该是server_name/joes)。
要创建在所有新数据库中都存在的用户,你可以修改Model数据库。为了简化工作,SQL Server自动把所有对Model数据库的改动复制到新的数据库。只要正确运用Model数据库,我们无需定制每一个新创建的数据库。另外,我们可以用 sp_addrolemember存储过程把SQL Server Security Operators加入到db_securityadmin,把SQL Server Developers加入到db_owner角色。注意我们仍然没有授权任何组或帐户访问数据库。事实上,我们不能通过Enterprise Manager授权数据库访问,因为Enterprise Manager的用户界面只允许我们把数据库访问权限授予合法的登录帐户。SQL Server不要求NT帐户在我们把它设置为数据库角色的成员或分配对象权限之前能够访问数据库,但Enterprise Manager有这种限制。尽管如此,只要我们使用的是sp_addrolemember存储过程而不是Enterprise Manager,就可以在不授予域内NT帐户数据库访问权限的情况下为任意NT帐户分配权限。到这里为止,对Model数据库的设置已经完成。但是,如果你的用户群体对企业范围内各个应用数据库有着类似的访问要求,你可以把下面这些操作移到Model数据库上进行,而不是在面向特定应用的数据库上进行。
实施安全策略的最后一个步骤是创建用户定义的数据库角色,然后分配权限。完成这个步骤最简单的方法是创建一些名字与全局组名字配套的角色。例如对于 前面例子中的会计系统,我们可以创建Accounting Data Entry Operators、Accounting Data Entry Managers之类的角色。由于会计数据库中的角色与帐务处理任务有关,你可能想要缩短这些角色的名字。然而,如果角色名字与全局组的名字配套,你可以 减少混乱,能够更方便地判断出哪些组属于特定的角色。