上一篇提到了设置SQL安全的一些基本方法，这里重点研究如何规划权限设置。
过去不重视SQL中的权限设置，一般都是用sa或dbo进行连接。以为在前端程序中已经有了权限设置，sql就没有重视权限设置了。现在想来确实不好，如果我们能在sql中规划好权限，无疑也是对前台程序安全的加固，这样就算黑客已经拿到了用户名、密码，也不至于对系统数据造成大的破坏。
按理说，应该在系统开发时就使用用一个低权限的角色来进行开发，这样可以保证系统安全。如果开发中实在有代码无法实现，再设法提高权限、或设置不同的角色。而过去，我都是全部使用dbo开发，开发工作完成后再把权限降低，而这样可能某些代码无法执行了，又要重新去设置权限或程序。
同一个系统中不同模块权限可能也不尽相同，应该有3个级别的权限：1、只有select权限用于只读页面（db_datareader）；2、拥有UPDATE、delete、insert的权限，用于一般的后台管理和需要修改数据的地方（db_datawriter）；3、SP的执行权：我没有找到固定角色可以完成这项工作，只能自己创建一个角色，手工设置其权限可以执行某些（不一定是全部）存储过程。
还有一个权限，一般情况下用不到，但还是有个别程序需要有 CREATE TABLE、DROP TABLE的权限，这个权限可以选择数据库-属性-权限，选择“创建表”，我还没有找到更好的方法，有介绍说这是属于“语句权限”（如 CREATE DATABASE）适用于语句自身，而不适用于数据库中定义的特定对象，是不是可以临时在程序中Grant ？
有必要自己设置SQL权限吗？以下文字摘自网络：
“攻击者一但确认了网站存在SQLINJECTION漏洞，肯定有一步操作步骤就是测试网站的SQL SERVER使用者具有多大的权限。一般都会借助selectIS_SRVROLEMEMBER('sysadmin')，或者select IS_MEMBER('db_owner')，再或者用user= 0(让字符和数字进行比较，SQLSERVER就会提示了错误信息，从该信息中即可知道一些敏感信息)等语句进行测试。在当前，如果网站的数据库使用者用的是SA权限，再加上确认了WEB所处在的绝对路径，那么就宣告了你的网站的OVER。db_owner权限也一样，如果确认了绝对路径，那么有50％的机会能给你的机器中上WEB方式的木马。所以这儿我们确认了一点，我们必须要创建自已的权限，让攻击者找不着下嘴的地方。”
附SQL内置权限
db_accessadmin 可以添加或删除用户 ID。
db_securityadmin 可以管理全部权限、对象所有权、角色和角色成员资格。
db_ddladmin 可以发出 ALL DDL，但不能发出 GRANT、REVOKE 或 DENY 语句。
db_backupoperator 可以发出 DBCC、CHECKPOINT 和 BACKUP 语句。
db_datareader 可以选择数据库内任何用户表中的所有数据。
db_datawriter 可以更改数据库内任何用户表中的所有数据。
db_denydatareader 不能选择数据库内任何用户表中的任何数据。
db_denydatawriter 不能更改数据库内任何用户表中的任何数据。
在这儿把新建的数据库角色的权限配置好，比如需要使用哪个表、视图、存储过程等。然后把Db_owner 和 db_securityadmin、db_backupoperator取消，不给攻击者BACKUP DATABASE和create TABLE的机会，一但攻击者具有这两个权限，那么你的网站就还处在十分危险的状态。
还有注意一下，在创建数据库账号时，千万不能对服务器角色进行选择。
例如xp_cmdshell屏蔽的方法为：sp_dropextendedproc
'xp_cmdshell'，如果需要的话，再用sp_addextendedproc 'xp_cmdshell',
'xpsql70.dll'进行恢复。如果你不知道xp_cmdshell使用的是哪个.dll文件的话，可以使用sp_helpextendedproc
xp_cmdshell来查看xp_cmdshell使用的是哪个动态联接库。
将xp_cmdshell屏蔽后，我们还需要做的步骤是将xpsql70.dll文件进行改名或删除，以防止获得SA的攻击者将它进行恢复。
