保护SQL服务器的安全-用户识别问题

　　在我们关于SQL服务器安全系列的这文章里，我们的目标是向你提供安全安装SQL服务器所需要的工具和信心，这样的话，你有价值的数据就会受到保护，避免无意或者有意的破坏或者窃取。在本文里，我们会深入一些基础的概念，在保护数据库安全的时候，你需要利用下面这些概念：登录、用户、角色，以及组。确定谁在请求访问数据或者SQL服务器里其他信息等看上去很简单的过程，都需要用到所有这些概念。

　　登录

　　登录规定了哪些用户能够连接到安装好的SQL服务器上——这不是某个特定的数据库，而是而是整个服务器。登录有两种不同的形式：

　　Windows集成的登录，它会授权特定的Windows用户或者组使用它们的Windows信任书进行连接。

　　SQL服务器登录，它会授权用户使用由SQL服务器保存的用户名和密码进行连接。

　　你应该使用哪一种？

　　Windows集成登录肯定要比SQL服务器登录更加高效和更方便，因为用户只需要登录一次——在网络这一层。单独登录到服务器是没有必要的，因为SQL服务器会自动地处理（在后台）Windows登录，从而允许到服务器的访问。只有在服务器运行在Windows NT或者2000上的时候，对Windows登录的支持才有效；安装在Windows 98上的服务器必须要依赖SQL服务器登录。如果你正在运行Windows 2000，而且最终需要支持原有的应用程序，那么就要记住，SQL服务器登录只有在混合模式下才可用。

　　设计上的考虑

　　在设计自己数据库的时候，你需要考虑登录的方法——而且要在你真正开始保证最终产品的安全之前。你应该知道服务器使用的是哪种授权方式。那些还在Window 98上使用服务器的人可能现在就要考虑升级，如果安全是一个很重要的问题的话；那样的话，他们就可以使用Windows集成的安全（策略）。

　　另外一个设计问题是知道谁拥有访问权，他们能够访问什么数据，以及他们是否能够对对象和数据进行更改。你不用真的列出其名字；你只需要利用工具有效地帮助用户就行了。最后，你应该使用系统的存储过程来管理安全。SQL服务器提供了两种存储过程，用于登录的管理：

　　◆sp_addlogi——在使用SQL服务器验证保护你服务器安全的时候要使用这个存储过程。具体的说，这个存储过程会创建一个新的SQL服务器登录，它允许用户使用SQL服务器验证连接到SQL服务器的实例上。

　　◆sp_grantlogin——这个存储过程允许Windows 2000的用户或者组帐号使用Windows验证连接到微软的SQL服务器上。

　　只有sysadmin或者securityadmin固有服务器角色的成员能够执行这两个存储过程。

　　什么是系统存储过程？

　　系统存储过程是一个内置的存储过程，它能够帮助你管理服务器。你可以在MSDN库里找到一长串的系统存储过程。SQL服务器文献在线囊括了每个系统存储过程的所有句法细节和使用示例。

　　用户

　　登录属于服务器，而用户则属于数据库。用户ID会识别特定数据库的特定用户。而且，用户对于数据库来说是专门的——也就是说，Northwind数据库里Fred这个用户同公共数据库里Fred那个用户是不同的，尽管这两个Fred可能和同一个登录相关联。

　　当你在数据库里创建一个用户的时候，你就将一个特定的登录同这个用户关联起来了。对于这个数据库而言，登录具有这个用户的权限。尽管登录所用的ID不需要和用户ID相同，但是在通常情况下，如果你保持这样的惯例，那么事情就会更少让人糊涂。如果登录在数据库里没有相关联的用户，那么用户能够通过特殊的来宾用户帐号连接到该数据库。

　　特殊用户

　　所有的用户都不是数据库里的常住人口，而且不能保证用户帐号就是他们自己的。在希望用户临时访问数据库的时候，你可以使用来宾用户帐号，它可以不使用常规的用户帐号而登录访问服务器。来宾用户的登录必须拥有访问数据库的权限，而且数据库必须设有来宾用户帐号。一旦进了数据库，来宾用户会被限制到只能进行来宾用户帐号所指定的活动。但是，来宾用户帐号在一个刚刚创建的数据库里不是缺省就存在的；（数据库的）所有者或者系统管理员必须创建这样一个帐号。

　　除了来宾用户，你还需要考虑数据库的所有者（DBO）。他是创建数据库的用户。数据库的所有者或者系统管理员必须赋予（其他人）权限，才能让他们在数据库创建其它的对象。

　　为了向数据库里添加数据，你要运行sp_grantdbaccess。这个存储过程会在数据库里创建一个和指定登录相对应的用户。只有sysadmin固有服务器角色、db_accessadmin角色，以及db_owner固有服务器角色的成员才能够执行sp_grantdbaccess。

　　角色

　　角色让你将用户集中到一起，以利于更简单的管理。就像用户一样，角色也是数据库的对象。例如，你可以在自己的采购数据库里定义一个“销售”角色，并让所有的产品所有销售人员都成为这个角色的成员。如果你随后赋予这个“销售”角色许可，那么这些许可会自动地应用于该角色的所有成员上。此外，一个用户可以是多个角色的成员。

　　有三种类型的角色：

　　◆公共——这个角色会为所有的用户设置缺省的基本许可，所有的用户都会被分配公共角色。

　　◆服务器——服务器角色适用于整个服务器。

　　◆数据库——这些角色适用于专门的数据库。

　　服务器和数据库角色都有预先定义的类别，我们把它们列在表格A里。


表格 A

 

　　角色的分配

　　有一些系统存储过程是用于向数据库添加角色和成员的。使用sp_addrole可以在数据库里创建一个新的角色。然后，运行sp_addrolemember向角色添加用户帐号。你不能创建固有的服务器角色；你只能够在服务器这一层添加角色。只有sysadmin固有服务器角色、db_securityadmin角色，以及db_owner固有数据库角色的成员才能够执行sp_addrole或者sp_addrolemember。

　　组

　　组向你提供了批量管理安全的第二种方式，而不需要一个用户一个用户地来管理。在SQL服务器里并不存在组。它们由操作系统来维护。组的使用可以让你把SQL服务器的安全策略和整个企业的安全策略绑在一起。

　　例如，如果你有一个叫做“销售”的Windows 2000组，它包含着你所有的销售人员，你可以在SQL服务器里专门为这个组创建一个Windows登录。这个“销售”组的任何成员都会作为指定的登录连接到SQL数据库上（除非他们有自己单独的优先登录）。你可以进一步将这个登录同任何数据库里的用户相关联，然后赋予该用户许可。组的任何成员都会在他们使用数据库的时候获得指定的许可。

　　管理策略

　　用户管理的主要目标是双重的。首先，你希望确保只有那些能够获得数据的用户是真正需要使用数据的人。其次，你应该尽力将用于用户管理的精力降到最小。繁杂的策略要比直接的策略更少被人采用，否则就会导致安全的极大破坏。下面是你在用户管理中可以采纳的一些简单指导方针：

　　在可能的情况下，尽量使用Windows集成安全。这会降低密码维护和用户创建所要的花费精力。它还会让SQL服务器将登录信息传递给已连接的服务器，这在分布式数据库里很重要。

　　在可能的情况下，尽量在聚合这一层管理安全。不应该为每个必须访问你数据的单个人创建用户，而应该创建像“销售”或者DataEntryUsers这样的角色。然后你就可以通过添加和删除角色的用户来控制访问，同时向角色分配许可。另外，你也可以在Windows层管理组成员，并向代表整个Windows组的用户分配许可。

　　来宾用户很危险，因为它会给你服务器上每个的登录都赋予访问数据库的权限。不要在数据库里创建来宾用户，除非它要对所有的人都开放。

　　基本内容

　　本篇文章里所讨论的概念都是实现你SQL服务器安全的基本要素，它们一点也不简单。理解每个登录的工作方式离你确定自己整个（安全）策略还有很长的路要走。