在改进SQL Server
系列所实现的安全机制的过程中
Microsoft建立了一种既灵活又强大的安全管理机制
它能够对用户访问SQL Server服务器系统和数据库的安全进行全面地管理
按照本文介绍的步骤
你可以为SQL Server
（或
）构造出一个灵活的
可管理的安全策略
而且它的安全性经得起考验
一验证方法选择
本文对验证（authentication）和授权（authorization）这两个概念作不同的解释验证是指检验用户的身份标识授权是指允许用户做些什么在本文的讨论中验证过程在用户登录SQL Server的时候出现授权过程在用户试图访问数据或执行命令的时候出现
构造安全策略的第一个步骤是确定SQL Server用哪种方式验证用户SQL Server的验证是把一组帐户密码与Master数据库Sysxlogins表中的一个清单进行匹配Windows NT/的验证是请求域控制器检查用户身份的合法性
一般地如果服务器可以访问域控制器我们应该使用Windows NT/验证域控制器可以是WinK服务器也可以是NT服务器无论在哪种情况下SQL Server都接收到一个访问标记（Access Token）访问标记是在验证过程中构造出来的一个特殊列表其中包含了用户的SID（安全标识号）以及一系列用户所在组的SID正如本文后面所介绍的SQL Server以这些SID为基础授予访问权限注意操作系统如何构造访问标记并不重要SQL Server只使用访问标记中的SID也就是说不论你使用SQL Server SQL Server WinK还是NT进行验证都无关紧要结果都一样
如果使用SQL Server验证的登录它最大的好处是很容易通过Enterprise Manager实现最大的缺点在于SQL Server验证的登录只对特定的服务器有效也就是说在一个多服务器的环境中管理比较困难使用SQL Server进行验证的第二个重要的缺点是对于每一个数据库我们必须分别地为它管理权限如果某个用户对两个数据库有相同的权限要求我们必须手工设置两个数据库的权限或者编写脚本设置权限如果用户数量较少比如个以下而且这些用户的权限变化不是很频繁SQL Server验证的登录或许适用但是在几乎所有的其他情况下（有一些例外情况例如直接管理安全问题的应用）这种登录方式的管理负担将超过它的优点
二Web环境中的验证
即使最好的安全策略也常常在一种情形前屈服这种情形就是在Web应用中使用SQL Server的数据在这种情形下进行验证的典型方法是把一组SQL Server登录名称和密码嵌入到Web服务器上运行的程序比如ASP页面或者CGI脚本然后由Web服务器负责验证用户应用程序则使用它自己的登录帐户（或者是系统管理员sa帐户或者为了方便起见使用Sysadmin服务器角色中的登录帐户）为用户访问数据
这种安排有几个缺点其中最重要的包括它不具备对用户在服务器上的活动进行审核的能力完全依赖于Web应用程序实现用户验证当SQL Server需要限定用户权限时不同的用户之间不易区别如果你使用的是IIS 或者IIS 你可以用四种方法验证用户
第一种方法是为每一个网站和每一个虚拟目录创建一个匿名用户的NT帐户此后所有应用程序登录SQL Server时都使用该安全环境我们可以通过授予NT匿名帐户合适的权限改进审核和验证功能
第二种方法是让所有网站使用Basic验证此时只有当用户在对话框中输入了合法的帐户和密码IIS才会允许他们访问页面IIS依靠一个NT安全数据库实现登录身份验证NT安全数据库既可以在本地服务器上也可以在域控制器上当用户运行一个访问SQL Server数据库的程序或者脚本时IIS把用户为了浏览页面而提供的身份信息发送给服务器如果你使用这种方法应该记住在通常情况下浏览器与服务器之间的密码传送一般是不加密的对于那些使用Basic验证而安全又很重要的网站你必须实现SSL（Secure Sockets Layer安全套接字层）
在客户端只使用IE IE IE 浏览器的情况下你可以使用第三种验证方法你可以在Web网站上和虚拟目录上都启用NT验证IE会把用户登录计算机的身份信息发送给IIS当该用户试图登录SQL Server时IIS就使用这些登录信息使用这种简化的方法时我们可以在一个远程网站的域上对用户身份进行验证（该远程网站登录到一个与运行着Web服务器的域有着信任关系的域）
最后如果用户都有个人数字证书你可以把那些证书映射到本地域的NT帐户上个人数字证书与服务器数字证书以同样的技术为基础它证明用户身份标识的合法性所以可以取代NT的Challenge/Response（质询/回应）验证算法Netscape和IE都自动在每一个页面请求中把证书信息发送给IISIIS提供了一个让管理员把证书映射到NT帐户的工具因此我们可以用数字证书取代通常的提供帐户名字和密码的登录过程
由此可见通过NT帐户验证用户时我们可以使用多种实现方法即使当用户通过IIS跨越Internet连接SQL Server时选择仍旧存在因此你应该把NT验证作为首选的用户身份验证办法
三设置全局组
构造安全策略的下一个步骤是确定用户应该属于什么组通常每一个组织或应用程序的用户都可以按照他们对数据的特定访问要求分成许多类别例如会计应用软件的用户一般包括数据输入操作员数据输入管理员报表编写员会计师审计员财务经理等每一组用户都有不同的数据库访问要求
控制数据访问权限最简单的方法是对于每一组用户分别地为它创建一个满足该组用户权限要求的域内全局有效的组我们既可以为每一个应用分别创建组也可以创建适用于整个企业的涵盖广泛用户类别的组然而如果你想要能够精确地了解组成员可以做些什么为每一个应用程序分别创建组是一种较好的选择例如在前面的会计系统中我们应该创建Data Entry OperatorsAccounting Data Entry Managers等组请记住为了简化管理最好为组取一个能够明确表示出作用的名字
除了面向特定应用程序的组之外我们还需要几个基本组基本组的成员负责管理服务器按照习惯我们可以创建下面这些基本组SQL Server AdministratorsSQL Server UsersSQL Server Denied UsersSQL Server DB CreatorsSQL Server Security OperatorsSQL Server Database Security OperatorsSQL 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数据库上进行而不是在面向特定应用的数据库上进行
四允许数据库访问
在数据库内部与迄今为止我们对登录验证的处理方式不同我们可以把权限分配给角色而不是直接把它们分配给全局组这种能力使得我们能够轻松地在安全策略中使用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 OperatorsAccounting Data Entry Managers之类的角色由于会计数据库中的角色与帐务处理任务有关你可能想要缩短这些角色的名字然而如果角色名字与全局组的名字配套你可以减少混乱能够更方便地判断出哪些组属于特定的角色
创建好角色之后就可以分配权限在这个过程中我们只需用到标准的GRANTREVOKE和DENY命令但应该注意DENY权限这个权限优先于所有其他权限如果用户是任意具有DENY权限的角色或者组的成员SQL Server将拒绝用户访问对象
接下来我们就可以加入所有SQL Server验证的登录用户定义的数据库角色可以包含SQL Server登录以及NT全局组本地组个人帐户这是它最宝贵的特点之一用户定义的数据库角色可以作为各种登录的通用容器我们使用用户定义角色而不是直接把权限分配给全局组的主要原因就在于此
由于内建的角色一般适用于整个数据库而不是单独的对象因此这里建议你只使用两个内建的数据库角色即db_securityadmin和db_owner其他内建数据库角色例如db_datareader它授予对数据库里面所有对象的SELECT权限虽然你可以用db_datareader角色授予SELECT权限然后有选择地对个别用户或组拒绝SELECT权限但使用这种方法时你可能忘记为某些用户或者对象设置权限一种更简单更直接而且不容易出现错误的方法是为这些特殊的用户创建一个用户定义的角色然后只把那些用户访问对象所需要的权限授予这个用户定义的角色
六简化安全管理
SQL Server验证的登录不仅能够方便地实现而且与NT验证的登录相比它更容易编写到应用程序里但是如果用户的数量超过或者服务器数量在一个以上或者每个用户都可以访问一个以上的数据库或者数据库有多个管理员SQL Server验证的登录不容易管理由于SQL Server没有显示用户有效权限的工具要记忆每个用户具有哪些权限以及他们为何要得到这些权限就更加困难即使对于一个数据库管理员还要担负其他责任的小型系统简化安全策略也有助于减轻问题的复杂程度因此首选的方法应该是使用NT验证的登录然后通过一些精心选择的全局组和数据库角色管理数据库访问
下面是一些简化安全策略的经验规则
·用户通过SQL Server Users组获得服务器访问通过DB_Name Users组获得数据库访问
·用户通过加入全局组获得权限而全局组通过加入角色获得权限角色直接拥有数据库里的权限
·需要多种权限的用户通过加入多个全局组的方式获得权限
只要规划得恰当你能够在域控制器上完成所有的访问和权限维护工作使得服务器反映出你在域控制器上进行的各种设置调整虽然实际应用中情况可能有所变化但本文介绍的基本措施仍旧适用它们能够帮助你构造出很容易管理的安全策略
