把SQL Server放入保险箱

　　安全模式简介

　　从系统结构上来讲SQL Server有两种安全模式。

　　第一种是“仅Windows”模式，这种模式只允许拥有受信任的Windows NT账户的用户登录，是SQL Server默认的安全模式，也是较安全的选项，用户登录SQL Server的前提是该用户使用Windows NT的域账户登录Windows操作系统。

　　另一种是“SQL与Windows用户身份验证”模式，是在SQL Server中建立登录用户，所有基于Windows操作系统的用户只要使用这个SQL账户就可以实现标准的SQL登录。这种模式安全性相对而言较差一些，容易被恶意入侵者使用暴力破解sa账户，而且也容易遭受注入式攻击，但是管理简单，目前很有市场。

　　虽然第一种模式安全性高一些，但是什么事情都是相对的，因为使用Windows身份验证时，所有的用户信息和密码都存储在系统目录中的SAM文件中，只要搞到并破解了SAM文件，那么也就没有安全可言了。使用SQL身份验证时，所有的密码信息也会以某种方式存储在注册表和日志文件中。其实漏洞肯定是存在的，只是有没有被发现而已，应对这种无奈的现实，只能尽量打好补丁，提高警惕，减少出现已知漏洞的可能。

　　登录与用户的概念

　　很多人对SQL Server两种基本安全级别“登录”和“用户”的概念不够清晰，甚至把它们混为一谈。其实这是两个不同的概念。

　　登录是指允许用户访问服务器并拥有服务器级别权限的账户，属于系统级别，权限的大小取决于系统赋予该登录账户的权限级别，如sa账户，它是sysadmin级别，那么使用sa登录就可以取得数据库系统的最高权限。用户属于数据库级别，拥有对数据库及其单独对象的访问权限，可以精确到表、行、字段等。

　　在系统验证时，它们之间的根本区别在于，当Windows用户登录数据库服务器时，SQL Server验证的是登录，当用户登入数据库系统后，访问数据库及其对象时，SQL Server验证的是用户。登录账户可以没有具体的数据库对象访问权限，但是具备数据库访问权限的用户必定是使用登录账户登录的。

　　另外，SQL Server的安全性并不仅仅是SQL Server的问题，还需要联合Windows的安全性考虑，互相配合，才能使安全性发挥的最好。

　　为了减少权限管理的复杂度，笔者建议采用“仅Windows”安全模型，在Windows NT创建三个用户组，一组用于SQL管理员，一组具有读写数据库权限，第三组只有查询权限，再把相应的账号指派给对应组，然后在SQL Server中创建三个组，并指派给相应的NT组。

　　注意：如果某个NT账户指派给某个组，而该组又被指派给SQL Server，那么用户必须先注销系统，重新以指派的Windows账户登录后，才能获得该组的权限。在NT系统中采用安全策略，确保用户每个月都要更改一次密码，并保证密码的复杂度。这样做的好处是可以把SQL用户管理的工作合并到域控制器中，可以减少管理的成本，避免双方可能存在的用户密码不一致的现象。

　　放入“保险箱”

　　以上所述主要是从用户管理的安全角度来分析的，下面来深入了解SQL Server的权限管理的精髓，以便提高并完善我们的安全手段。SQL Server的权限模型不太好理解，尤其是使用细粒度的列级别权限时就更加复杂。权限安全的执行操作有三种类型：授予、拒绝、撤销。

　　授予：就是允许用户具有访问某个对象的权限。

　　拒绝：就是阻止用户访问某对象。

　　撤销：既不授予也不拒绝，但是不具有访问权限，是一种系统隐含的默认的模式，新创建的账户基本上都是赋予撤销权限。

　　SQL Server的授予权限基本上都是叠加的(类似于“与”算法操作)。例如，A表有a,b,c,d四个列，Perter被授予访问其中的a,b,c三列，另外他还是Power组的成员，Power组有访问A表的所有列的权限，那么Perter也具有访问d列的权限。对于拒绝访问来说，它的原则就是“非”算法操作，例如，Peter属于Power组，该组具有访问A表所有列的权限，但是Peter被拒绝访问该表，根据“非”算法，那么他就不能访问A表。如果Power组可以访问A表的其中d列，Perter被拒绝访问该列，那么Peter也不能看到这一列的数据。但是有一个例外，如果Peter属于sysadmin成员，那么所有的规则都不起作用，因为sysadmin具有最高权限，可以访问数据库任意对象。

　　拒绝访问有一定的复杂度和负面影响，此类操作会造成一连串的关联效果。对于具有权限继承这类复杂关系的情况，拒绝操作的结果可能会比较复杂，所以采用撤销权限是一种明智的选择，累加安全性比起“非”操作更能容易地预见结果。例如Peter用户具有创建用户的权限，并且他创建了不少用户，下级用户继承了Peter账户的很多权限，现在Peter要离职了，他的账户不能再拥有数据库访问权限，但是他创建的下级用户权限不变，如果采用拒绝权限操作，那么他的下级用户访问数据库时可能会出现各种问题。然而如果采用撤销权限操作，那么他的下级用户则不受影响。

　　权限继承的核心是使用GRANT的WITH GRANT命令选项使用户能够访问某对象，并且允许该用户授权其他用户访问该对象。例如使用WITH GRANT选项授予Peter访问A对象的权限：

　　GRANT EXECUTE ON 对象A To Peter WITH GRANT OPTION

　　那么Peter就会具有使用GRANT的命令向其他人授予访问对象A的权限。如果撤销了Peter访问对象A的权限，那么他的下级用户依然可以访问对象A，除非使用撤销命令时加上CASCAD参数：

　　REVOKE EXECUTE ON 对象A To Peter CASADE

　　权限定义数据存放在数据库的Syspermissions表中，如果想知道某个用户具有哪些权限，不必去管理器中逐个查看，可以查询Sysprotects表，其中的ProtectType列存放GRANT权限值，通常用204、205表示默认和授予，206表示拒绝权限。如果执行了REVOKE操作，那么此表中就不会存在关于该对象的权限记录。如果想查询Peter用户对A对象的权限设置，可以运行语句：

　　SELECT * FROM (SELECT OBJECT_NAME(id) AS 对象名, USER_NAME(uid) AS 用户名, ProtectType, Action, USER_NAME(Grantor) AS 所有者 FROM sysprotects WHERE id = Object_id('A')) DERIVEDTBL WHERE (用户名 = 'peter')

　　就可以看到查询结果如表1所示。

　　SQL Server的权限模型当然不能少了角色应用，SQL Server角色分为服务器角色和数据库角色。角色为权限管理提供了高效的手段，简化了权限设置的工作量和复杂度。我们只需设置角色的权限，然后把相应的用户或组加入到角色中就可以使用户取得与角色一样的权限。

　　我们必须经常查看Public角色。某个用户被授予访问数据库的权限后，这个用户就会被系统放到Public角色中，并且不能从该角色中删除，而且此用户将继承Public的所有权限。最好不要更改Public角色的权限，因为如果授予系统默认外的某对象权限的话，将会无法显式的授予用户访问该对象的权限。如果拒绝Public的权限，那么所有的用户权限都被拒绝，当然sysadmin角色的成员除外。

　　注意：要经常检查Guest账户的权限，看他有没有被授予访问数据库的权限。很多黑客都会打Guest账户。