保护SQL服务器的安全 用户识别问题（2）

角色的分配

有一些系统存储过程是用于向数据库添加角色和成员的。使用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服务器安全的基本要素，它们一点也不简单。理解每个登录的工作方式离你确定自己整个(安全)策略还有很长的路要走。