打造SQLServer2000的安全策略

微软建立了灵活强大的安全管理机制，可以全面管理用户访问SQL Server服务器系统和数据库的安全。按照本文介绍的步骤，可以为SQL Server 7.0(或2000)构建一个灵活的、可管理的安全策略，其安全性是经得起考验的。

一、核查方法的选择

本文对认证和授权这两个概念给出了不同的解释。认证是指检查用户的身份；授权是指允许用户做什么。在本讨论中，身份验证过程发生在用户登录到SQL Server时，授权过程发生在用户尝试访问数据或执行命令时。

构建安全策略的第一步是确定SQL Server对用户进行身份验证的方式。SQL Server的验证是将一组帐户和密码与Master数据库的Sysxlogins表中的列表进行匹配。Windows NT/2000身份验证是请求域控制器检查用户身份的合法性。一般来说，如果服务器可以访问域控制器，我们应该使用Windows NT/2000身份验证。域控制器可以是Win2K服务器或NT服务器。在任何情况下，SQL Server都会收到一个访问令牌。访问标签是在认证过程中构造的一个特殊列表，它包含用户的SID(安全标识号)和用户所属组的一系列SID。如本文后面所述，SQL Server根据这些sid授予访问权限。注意，操作系统如何构造访问标记并不重要。SQL Server仅使用访问标记中的SID。也就是说，用SQL Server 2000、SQL Server 7.0、Win2K还是NT进行身份验证都无所谓，结果都是一样的。

如果使用SQL Server认证的登录，其优点是易于通过企业管理器实现，缺点是SQL Server认证的登录只对特定服务器有效，即在多服务器环境下难以管理。使用SQL Server进行身份验证的第二个重要缺点是，对于每个数据库，我们必须单独管理它的权限。如果一个用户对两个数据库有相同的权限要求，我们必须手动设置两个数据库的权限，或者编写脚本来设置权限。如果用户数量很少，例如少于25个，并且这些用户的权限不经常更改，则由SQL Server验证的登录可能适用。然而，在几乎所有其他情况下(除了一些例外，如直接管理安全问题的应用程序)，这种登录模式的管理负担将超过其优势。

第二，网络环境下的验证

即使是SQL Server的安全策略，也总是在一种情况前屈服，那就是SQL Server的数据被用在Web应用中。在这种情况下，典型的验证方法是将一组SQL Server登录名和密码嵌入到运行在Web服务器上的程序中，如ASP页面或CGI脚本；然后，Web服务器负责对用户进行身份验证，应用程序使用自己的登录帐户(为了方便起见，可以是系统管理员sa帐户，也可以是Sysadmin服务器角色中的登录帐户)来访问用户的数据。

这种安排有几个缺点，最重要的包括:不具备审核用户在服务器上活动的能力，完全依赖Web应用实现用户认证。当SQL Server需要限制不同用户权限的用户时，不容易区分。如果您使用的是IIS 5.0或IIS 4.0，可以通过四种方式对用户进行身份验证。第一种方法是为每个网站和每个虚拟目录创建一个匿名用户的NT帐户。从那时起，所有应用程序在登录到SQL Server时都将使用此安全环境。我们可以通过向NT匿名帐户授予适当的权限来改进审计和验证功能。

第二种方法是让所有网站都使用基本认证。此时，只有当用户在对话框中输入有效的帐户和密码时，IIS才会允许用户访问该页。IIS依靠NT安全数据库来实现登录身份验证，NT安全数据库可以在本地服务器上，也可以在域控制器上。当用户运行访问SQL Server数据库的程序或脚本时，IIS会将用户提供的用于浏览页面的标识信息发送到服务器。如果使用这种方法，应该记住浏览器和服务器之间的密码传输一般是不加密的。对于那些使用基本认证，安全重要的网站，你必须实现SSL(安全套接字层)。

当客户端只使用IE 5.0、IE 4.0和IE 3.0浏览器时，可以使用第三种认证方式。您可以在网站和虚拟目录上启用NT身份验证。IE会将登录计算机的用户的身份信息发送到IIS，当用户尝试登录SQL Server时，IIS会使用这些登录信息。通过这种简化的方法，我们可以在远程网站的域中验证用户的身份(远程网站登录到与运行web服务器的域有信任关系的域)。

最后，如果所有用户都有个人数字证书，您可以将这些证书映射到本地的NT帐户。个人证书基于与服务器数字证书相同的技术，证明用户身份的合法性，因此可以替代NT的挑战/响应验证算法。Netscape和IE会在每个页面请求中自动向IIS发送证书信息。IIS为管理员提供了一个将证书映射到NT帐户的工具。因此，我们可以用数字证书代替通常的提供帐户名和密码的登录过程。

因此，在通过NT帐户对用户进行身份验证时，我们可以使用多种实现方法。即使用户通过IIS通过Internet连接到SQL Server，这种选择仍然存在。因此，您应该将NT身份验证作为首选的用户身份验证方法。

三。设置全局组

构建安全策略的下一步是确定用户应该属于哪个组。一般来说，每个组织或应用程序的用户都可以根据他们对数据的特定访问要求分为许多类别。例如，会计应用软件的用户一般包括:数据输入操作员、数据输入管理员、报告撰写员、会计师、审计师、财务经理等。每组用户都有不同的数据库访问需求。

控制数据访问权限最简单的方法是为每组用户创建一个全局有效的组，该组符合该组用户权限的要求。我们可以为每个应用程序单独创建组，或者我们可以创建适用于整个企业并涵盖广泛用户类别的组。但是，如果您想确切知道组成员可以做什么，为每个应用程序创建组是更好的选择。比如以前的会计系统，要创建数据录入操作员、会计数据录入管理员等组。记住，为了简化管理，给组起一个能清楚表明其角色的名字
除了特定于应用程序的组，我们还需要几个基本组。基本组的成员负责管理服务器。根据自定义，我们可以创建以下基本组:SQL Server管理员、SQL Server用户、SQL Server拒绝用户、SQL Server DB创建者、SQL Server安全操作员、服务器数据库安全操作员、SQL Server开发人员和DB_Name用户(其中DB_Name是服务器上数据库的名称)。当然，如果有必要，你也可以创建其他组。

创建全局组后，我们可以授予它们访问SQL Server的权限。首先，为SQL Server用户创建一个NT验证的登录名，并授予它登录权限。将Master数据库设置为其默认数据库，但不要授予它访问任何其他数据库的权限，也不要将此登录帐户设置为任何服务器角色的成员。然后对SQL Server拒绝的用户重复此过程，但这次拒绝登录访问。在SQL Server中，拒绝权限总是优先。创建这两个组后，我们有一个方便的方法来允许或拒绝用户访问服务器。

当授权没有在Sysxlogins系统表中直接注册的组时，我们不能使用Enterpris Managr，因为Enterprise Manager只允许我们从现有登录名列表中进行选择，而不是从域中所有组的列表中进行选择。若要访问所有组，请打开查询分析器，然后使用系统存储过程sp_addsrvrolemember和sp_addrolemember进行授权。

对于每组操作服务器，我们可以使用sp_addsrvrolemember存储过程将每个登录添加到适当的服务器角色:SQL Server管理员成为Sysadmins角色的成员，SQL Server DB创建者成为Dbcreator角色的成员，SQL Server安全操作员成为Securityadmin角色的成员。请注意，sp_addsrvrolemember存储过程的第一个参数需要帐户的完整路径。比如BigCo域的JoeS应该是bigco\joes(如果要使用本地账号，路径应该是server_name\joes)。

要创建存在于所有新数据库中的用户，可以修改Model数据库。为了简化工作，SQL Server会自动将对Model数据库的所有更改复制到新数据库中。只要正确使用模型数据库，我们不需要定制每个新创建的数据库。此外，我们可以使用sp_addrolemember存储过程将SQL Server安全操作员添加到db_securityadmin，将SQL Server开发人员添加到db_owner角色。

请注意，我们仍然没有授权任何组或帐户访问数据库。事实上，我们不能通过企业管理器授权数据库访问，因为企业管理器的用户界面只允许我们将数据库访问权授予合法的登录帐户。在我们将nt帐户设置为数据库角色的成员或分配对象权限之前，SQL Server不要求NT帐户能够访问数据库，但Enterprise Manager有此限制。但是，只要我们使用sp_addrolemember存储过程而不是企业管理器，我们就可以向任何nt帐户分配权限，而不授予对域中NT帐户数据库的访问权限。

至此，模型数据库的建立已经完成。但是，如果您的用户组对企业中的各种应用程序数据库有类似的访问要求，您可以将以下操作移到Model数据库，而不是特定应用程序的数据库。

四。允许数据库访问

在数据库内部，与我们迄今为止处理登录验证的方式不同，我们可以将权限分配给角色，而不是直接将它们分配给全局组。这种能力使我们可以很容易地在我们的安全策略中使用SQL Server身份验证登录。即使您从来不想使用SQL Server登录，本文仍然建议为角色分配权限，因为这样您就可以为将来可能发生的变化做好准备。

创建数据库后，我们可以使用sp _ grantdbaccess存储过程授权DB_Name用户组访问它。但是需要注意的是，sp _ grantdbaccess对应的sp_denydbACCESS存储过程是不存在的，也就是说，你不能像拒绝访问服务器一样拒绝访问数据库。要拒绝数据库访问，我们可以创建另一个名为DB_Name Denied Users的全局组，授权它访问数据库，然后将其设置为db_denydatareader和db_denydatawriter角色的成员。注意SQL语句权限的分配。这里的角色只限制对对象的访问，而不是DDL(数据定义语言)命令。

与登录过程一样，如果已经在Sysusers系统表中注册了access标记中的任何SID，SQL将允许用户访问数据库。因此，我们可以授权用户通过他们的个人NT帐户SID，或者通过他们所属的一个(或多个)组的SID来访问数据库。为了简化管理，我们可以创建一个名为DB_Name Users的具有数据库访问权限的全局组，但不授予所有其他组访问权限。这样，我们可以简单地通过在全局组中添加或删除成员来增加或减少数据库用户。

五.转让当局

实现安全策略的最后一步是创建用户定义的数据库角色，然后分配权限。完成这一步最简单的方法是创建一些名称与全局组名称相匹配的角色。例如，对于前面示例中的会计系统，我们可以创建会计数据输入操作员和会计数据输入管理员等角色。由于会计数据库中的角色与会计任务相关，您可能希望缩短这些角色的名称。但是，如果角色的名称与全局组的名称匹配，则可以减少混淆，并更容易确定哪些组属于特定的角色。

一旦创建了角色，就可以分配权限。在这个过程中，我们只需要使用标准的授权、撤销和拒绝命令。但是您应该注意DENY权限，它优先于所有其他权限。如果用户是任何具有拒绝权限的角色或组的成员，SQL Server将拒绝用户访问该对象。

接下来，我们可以加入所有经过SQL Server验证的登录。用户定义的数据库角色可以包括SQL Server登录、NT全局组、本地组和个人帐户，这是它最有价值的特性之一。用户定义的数据库角色可用作各种登录的通用容器。这是我们使用用户定义的角色而不是直接给全局组分配权限的主要原因。

由于内置角色通常适用于整个数据库，而不是单个对象，因此建议您只使用两个内置数据库角色，即db_securityadmin和db_owner。其他内置数据库角色(如db_datareader)向数据库中的所有对象授予SELECT权限。虽然您可以使用db_datareader角色授予select权限，然后有选择地拒绝单个用户或组的SELECT权限，但使用此方法时，您可能会忘记为某些用户或对象设置权限。一种更简单、更直接且不易出错的方法是为这些特殊用户创建一个自定义角色，然后只授予这些用户访问该自定义角色的对象所需的权限。

六。简化安全管理

SQL Server验证的登录不仅容易实现，而且比nt验证的登录更容易写入应用程序。但是，如果用户数量超过25个，或者服务器数量超过一个，或者每个用户可以访问多个数据库，或者数据库有多个管理员，那么SQL Server验证的登录就不好管理了。因为SQL Server没有显示用户有效权限的工具，所以更难记住每个用户拥有哪些权限以及为什么要获得这些权限。即使对于数据库管理员有其他职责的小型系统，简化安全策略也有助于降低问题的复杂性。因此，首选方法应该是使用NT身份验证登录，然后通过一些精心选择的全局组和数据库角色来管理数据库访问。

下面是一些简化安全策略的经验法则:

用户通过SQL Server用户组获得服务器访问权限，通过DB_Name用户组获得数据库访问权限。

用户通过加入全局组获得权限，全局组通过加入角色获得权限，角色直接拥有数据库中的权限。

需要多个权限的用户通过加入多个全局组来获得权限。

只要规划得当，就可以在域控制器上完成所有的访问和权限维护工作，让服务器反映出您在域控制器上所做的各种设置。尽管在实际应用中情况可能会发生变化，但本文中介绍的基本措施仍然适用，它们可以帮助您构建易于管理的安全策略。