SQL Server 2008的安全设置技巧方法详解
服务器身份验证
MSSQL Server 2008的身份验证模式有两种：一种是Windows 身份验证模式, 另一种是SQL Server和Windows身份验证模式(即混合模式)。对大多数数据库服务器来说，有SQL Server身份验证就足够了，只可惜目前的服务器身份验证模式里没有这个选项，所以我们只能选择同时带有SQL Server和Windows身份验证的模式(混合模式)。但这样就带来了两个问题：
1、混合模式里包含了Windows身份验证这个我们所不需要的模式，即设置上的冗余性。程序的安全性是与冗余性成反比的。
2、所谓Windows身份验证，实际上就是通过当前Windows管理员帐户（通常为Administrator）的登录凭据来登录MSSQL Server。使用Windows身份验证，会增加Administrator密码被盗的风险。
为解决以上两个问题，我们需要限制混合模式里的Windows身份验证。方法如下：
打开Microsoft SQL Server Management Studio，点击安全性->登录名，将Administrator对应的登录名删除即可。
SQL Server服务的运行身份
默认情况下，SQL Server服务是以本地系统的身份运行的。也就是说，SQL Server服务进程对系统拥有一切操作的权限，这是很不安全的。因此，我们需要将SQL Server服务的运行身份修改为普通用户：
1、新建一个普通用户，如mssqluser，将此用户加入以下两组：
SQLServerMSSQLUser
SQLServerSQLAgentUser
2、授予C盘mssqluser用户的读取权限，D、E等其他分区mssqluser用户的修改权限，mssql安装目录（如D:/Program Files/Microsoft SQL Server），数据库文件存放目录（如D:/mssqldata）mssqluser用户的完全控制权限。
3、将SQL Full-text Filter Daemon Launcher (MSSQLSERVER) SQL Server (MSSQLSERVER)服务的登录修改为mssqluser用户，然后重启这两个服务。
sa密码的安全性
很多数据库服务器管理员都会发现，总有人会乐此不疲地去破解sa密码。因此，将sa密码BT化就变成不可或缺的一步设置。另外，我们可以将sa重命名为sa1,sa2,sa3...之类的用户，这样可以进一步提高sa密码的安全性。修改之后，不要忘了更新有使用sa密码的管理程序
sqlserver安装性无疑是最重要的，不仅导致网站上SQL注入很严重，而且还可能危及服务器控制权
下面为各位自己安装了sql软件的朋友介绍常见的安全设置
修改SA用户名：
1：打开查询分析器，登陆进去（呵呵，随便你用什么帐号进去，不过可一定要在master数据库中有db_owner的权限）输入
| 代码如下 | 复制代码 |
|
sp_configure 'allow updates', 1 go RECONFIGURE WITH OVERRIDE go 然后再运行以下代码 update sysxlogins set name='你要改成的名字' where sid=0x01 update sysxlogins set sid=0xE765555BD44F054F89CD0076A06EA823 where name='你要改成的名字'
sp_configure 'allow updates', 0 go RECONFIGURE WITH OVERRIDE go |
|
然后，你查看一下SQL SERVER的角色，就会发现SA的用户名，已经改为你的新名子了。
1、修改1433端口，至于如何修改sql的端口
点击“开始-程序-Microsoft SQL Server-服务器网络实用工具”
在“启用的协议”中选中“TCP/IP”，点击“属性”：
输入新的默认端口号，点击“确定”：
点击“确定”。
修改在网站的数据库连接IP中填写 localhost,端口号 即可正常连接
2、不允许外部企业管理器或者其他工具连接1433端口
在本地安全策略中设置不允许非服务器上的IP连接SQL数据库，请将附件中的规则导入到本地安全策略中，指派即可
本安全策略为虚拟主机空间商必备策略，经过考验（修改后1433端口后SQL封锁无效，但还是可以大大增加服务器安全性）
3、卸载SQL的不安全组件
Xp_cmdshell(这个肯定首当其冲，不用说了)、Xp_regaddmultistring、Xp_regdeletekey、Xp_regdeletevalue、Xp_regenumvalues、Xp_regread、Xp_regwrite、Xp_regremovemultistring
在SQL查询器中输入命令卸载：删除xp_dirtree，命令是sp_dropextendedproc 'xp_dirtree'
4、权限设置
首先在计算机管理中新建一个隶属于users组的普通用户用来作为MSSQL的运行用户。
其次数据库应该单独安装在一个非C盘，非网站目录盘中，（假设您的数据安装在E:/Program Files/Microsoft SQL Server/）
Ｅ盘的根目录（Ｅ:/）需要以下权限：
“administrators ”的全部权限
“System ”的全部权限
“SQL的运行用户设置“读取”和“读取和运行”两个权限，并且在高级里设置为(只应用在当前文件夹)
数据库的安装目录（E:/Program Files/Microsoft SQL Server/）需要以下权限：
“administrators ”的全部权限
“System ”的全部权限
“SQL的运行用户 ”的全部权限
数据库用普通权限运行办法
企业管理器 — local — 点击右键查看“属性”，切换至“安全性”
经过上述设置好SQL基本可以保持在一个很好的安全状态，另外网站的安全也一定要做好，否则通过其他途径入侵了也枉然
建议自有服务器用户安装N点或者西部数码安全助手，便于网站安全
最后还给大家加一些安全常识
1、使用安全的密码策略
我们把密码策略摆在所有安全设置的第一步，请注意，非常多数据库帐号的密码过于简单，这跟系统密码过于简单是个道理。对于sa更应该注意，同时不要让sa帐号的密码写于应用程式或脚本中。健壮的密码是安全的第一步！
SQL Server2000安装的时候，如果是使用混合模式，那么就需要输入sa的密码，除非你确认必须使用空密码。这比以前的版本有所改进。
同时养成定期修改密码的好习惯。数据库管理员应该定期查看是否有不符合密码需求的帐号。比如使用下面的SQL语句：
| 代码如下 | 复制代码 |
| Use master Select name,Password from syslogins where password is null |
|
2、使用安全的帐号策略。
由于SQL Server不能更改sa用户名称，也不能删除这个终极用户，所以，我们必须对这个帐号进行最强的保护，当然，包括使用一个非常强壮的密码，最佳不要在数据库应用中使用sa帐号，只有当没有其他方法登录到 SQL Server 实例（例如，当其他系统管理员不可用或忘记了密码）时才使用 sa。建议数据库管理员新建立一个拥有和sa相同权限的终极用户来管理数据库。安全的帐号策略还包括不要让管理员权限的帐号泛滥。
SQL Server的认证模式有视窗系统身份认证和混合身份认证两种。如果数据库管理员不希望操作系统管理员来通过操作系统登陆来接触数据库的话，能在帐号管理中把系统帐号“BUILTIN＼Administrators”删除。不过这样做的结果是一旦sa帐号忘记密码的话，就没有办法来恢复了。
非常多主机使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配帐号，并赋予仅仅能够满足应用需求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public帐号能够select就能了。
3、加强数据库日志的记录。
审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统日志里面，就周详记录了所有帐号的登录事件。
请定期查看SQL Server日志检查是否有可疑的登录事件发生，或使用DOS命令。
| 代码如下 | 复制代码 |
|
findstr /C:"登录" d:＼Microsoft SQL Server＼MSSQL＼LOG＼*.* |
|
4、管理扩展存储过程
对存储过程进行大手术，并且对帐号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQL Server的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能非常容易地被人利用起来提升权限或进行破坏。
如果你不必扩展存储过程xp_cmdshell请把他去掉。使用这个SQL语句：
| 代码如下 | 复制代码 |
| use master sp_dropextendedproc ’xp_cmdshell’ |
|
xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门。如果你需要这个存储过程，请用这个语句也能恢复过来。
| 代码如下 | 复制代码 |
| sp_addextendedproc ’xp_cmdshell’, ’xpsql70.dll’ | |
如果你不必请丢弃OLE自动存储过程（会造成管理器中的某些特征不能使用），这些过程包括如下：
| 代码如下 | 复制代码 |
|
Sp_OACreate Sp_OADestroy Sp_OAGetErrorInfo Sp_OAGetProperty |
|
去掉不必的注册表访问的存储过程，注册表存储过程甚至能够读出操作系统管理员的密码来，如下：
| 代码如下 | 复制代码 |
|
Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue Xp_regenumvalues |
|
更有一些其他的扩展存储过程，你也最佳检查检查。
在处理存储过程的时候，请确认一下，避免造成对数据库或应用程式的伤害。
5、使用协议加密
SQL Server 2000使用的Tabular Data Stream协议来进行网络数据交换，如果不加密的话，所有的网络传输都是明文的，包括密码、数据库内容等等，这是个非常大的安全威胁。能被人在网络中截获到他们需要的东西，包括数据库帐号和密码。所以，在条件容许情况下，最佳使用SSL来加密协议，当然，你需要一个证书来支持。
6、不要让人随便探测到你的TCP/IP端口
默认情况下，SQL Server使用1433端口监听，非常多人都说SQL Server设置的时候要把这个端口改动，这样别人就不能非常容易地知道使用的什么端口了。可惜，通过微软未公开的1434端口的UDP探测能非常容易知道SQL Server使用的什么TCP/IP端口了。
不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server 实例。如果隐藏了 SQL Server 实例，则将禁止对试图枚举网络上现有的 SQL Server 实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测你的TCP/IP端口了（除非用Port Scan）。
7、修改TCP/IP使用的端口
请在上一步设置的基础上，更改原默认的1433端口。在实例属性中选择网络设置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口。
8、拒绝来自1434端口的探测
由于1434端口探测没有限制，能够被别人探测到一些数据库信息，而且还可能遭到DOS攻击让数据库服务器的CPU负荷增大，所以对视窗系统 2000操作系统来说，在IPSec过滤拒绝掉1434端口的UDP通讯，能尽可能地隐藏你的SQL Server。
9、对网络连接进行IP限制
SQL Server 2000数据库系统本身没有提供网络连接的安全解决办法，不过视窗系统 2000提供了这样的安全机制。使用操作系统自己的IPSec能实现IP数据包的安全性。请对IP连接进行限制，只确保自己的IP能够访问，也拒绝其他IP进行的端口连接，把来自网络上的安全威胁进行有效的控制。
