设置安全的SQL Server

■ 甘肃 左振辉 陆世炜

编者按：SQL Server数据库被广泛使用，近年来不断爆出因SQL Server数据库而造成的数据泄露，因此SQL Server的安全配置值得每一个管理员高度重视。本文针对SQL Server数据库的一系列安全配置进行了介绍。

Microsoft公司的SQL Server是一种广泛使用的数据库，很多网站和企业内部信息化平台都是基于SQL Server的，但是有些管理员还没有把数据库的安全性和系统的安全性等同起来，多数管理员认为只要把网络和操作系统的安全做好了，那么所有的应用程序也就安全了。

大多数系统管理员对数据库不熟悉，而数据库管理员又对安全问题关心太少，这就使数据库的安全问题更加严俊了。而且数据库系统中存在的安全漏洞和不当的配置通常会造成严重的后果，并且都难以发现。

数据库应用程序通常同操作系统的最高管理员密切相关。广泛的SQL Server数据库又是属于“端口”型的数据库，这就表示任何人都能够用分析工具试图连接到数据库上，从而绕过操作系统的安全机制，进而闯入系统破坏和窃取数据资料，甚至破坏整个系统。

下面就关于SQL Server数据库的安全配置以及一些相关的安全和使用上的问题进介绍。

在进行SQL Server数据库安全配置之前，需要先完成三个基本的安全配置。

1.对操作系统进行安全配置，保证操作系统处于安全状态。

2.对要使用的数据库软件（程序）进行必要的安全审核，如ASP、PHP等脚本。这是很多基于数据库的Web应用常出现的安全隐患。对于脚本主要是一个过滤问题，需要过滤一些类似于“，”、“‘”、“；”、“@”、“/”等的字符，防止破坏者构造恶意的语句进行注入。

3.安装SQL Server后要打上最新的补丁。

做完上述三个基本的配置之后，下来讨论SQL Server的安全配置。

使用安全的密码策略和帐号策略，减少过多的权限

密码是安全的第一步。很多数据库账号的密码过于简单，容易被入侵者获取，并以此入侵数据库。对于sa更应注意，同时不要让sa账号的密码写于应用程序或者脚本中。管理员应养成定期修改密码的好习惯，应该定期检查是否有不符合密码要求的帐号。

例如，使用以下SQL语句：

Use master

Select name,password from syslogins where password is null

由于SQL Server不能更改sa用户名称，也不能删除这个超级用户，所以必须对这个账号进行最强的保护。当然包括使用一个安全性极高的密码，最好不要在数据库应用中使用sa账号。

激活审核数据库事件日志

审核数据库登录事件的“失败和成功”，在实例属性中选择“安全性”，将其中的审核级别选定为全部，这样在数据库系统和操作系统安全性日志里面就详细记录了所有账号的登录事件。

应定期查看SQL Server日志，检查是否有可疑的登录事件发生，或者使用如下的DOS命令：

Findstr /c:”登录”d:microsoft SQL serverMSSQLLOG*.*

清除危险的扩展存储过程

对存储过程进行大手术，并且对账号调用扩展存储过程的权限要慎重。其实在多数应用中根本用不到多少系统的存储过程，而SQL Server这么多系统存储过程只是用来适应广大用户需求的。所以可以删除不必要的存储过程。因为有些系统的存储过程很容易被人利用，来提升权限或者进行破坏。

xp_cmdshell是进入操作系统的最佳捷径，是数据库留给操作系统的一个大后门，是危险性最高的存储过程，其可以执行操作系统的任何指令。如果不需要扩展存储过程xp_cmdshell，最好使用下面的SQL语句将其去掉。

use master

sp_dropextendedproc‘xp_cmdshell’

如果需要这个过程，可以使用下面的SQL语句将其恢复过来。

sp_addextendedproc‘xp_cmdshell’,’xpsql70.dll’

同理可以去掉其他不需要的存储过程。

例如OLE自动存储过程会造成管理器中的某些特征不能使用，这些过程包括：

sp_OACreate；

sp_OADestroy

sp_OAGetErrorInfo；

sp_OAGetProperty；

sp_OASetProperty；

sp_OAMethod；

以及sp_OAStop。

又如注册表访问存储过程甚至能够读出操作系统管理员的密码来，这些过程包括：

Xp_regaddmultistring Xp_regdeletekey Xp_regdeletevalue

Xp_regenumvalues Xp_regread Xp_regremovemultistring

Xp_regwrite。

在与工作相关的存储过程上设置严格的权限

SQL Server代理服务允许对以后执行的和在重建基础上的工作的创建。遗憾的是，默认情况下，甚至最低级的用户也允许有这个能力。

恶意的用户会创建一个过程来不断地提交无限量的工作。并在他选择的任何时间执行它们。这可能意味着重大的拒绝服务风险，也意味着明显的过渡权限的情况。建议对public角色删除execute权限，这样低权限的用户不能发布工作。如下的过程位于MSDB数据库中，应在安装后立即对他们采取措施以确保安全。

sp_add_job

sp_add_jobstep

sp_add_jobserver

sp_start_job

使用协议加密

SQL Server 2000使用的Tabular Data Stream协议来进行网络数据交换，如果不加密的话，所有的网络传输都是明文的，包括密码、数据库内容等等。这是一个很大的安全威胁，能被人在网络中截获到他们需要的东西，包括数据库帐号和密码。

所以，在条件容许情况下，最好使用SSL来加密协议，当然，你需要一个证书来支持。

拒绝来自1434端口的探测

SQL Server默认情况下使用1433端口监听，很多人都说SQL Server配置的时候要把这个端口改变，这样别人就不能很容易地知道使用的什么端口了。

可惜，通过微软未公开的1434端口的UDP探测可以很容易知道SQL Server使用的什么TCP/IP端口了。不过微软还是考虑到了这个问题，毕竟公开而且开放的端口会引起不必要的麻烦。

在实例属性中选择TCP/IP协议的属性。选择隐藏SQL Server实例。如果隐藏了SQL Server实例，则将禁止对试图枚举网络上现有的SQL Server实例的客户端所发出的广播作出响应。这样，别人就不能用1434来探测你的TCP/IP端口了（除非用Port Scan）。

此外，还可以使用IPSec过滤拒绝掉1434端口的UDP通讯，尽可能地隐藏SQL Server。

更改默认的TCP/IP端口1433

请在上一步配置的基础上，更改原默认的1433端口。在实例属性中选择网络配置中的TCP/IP协议的属性，将TCP/IP使用的默认端口变为其他端口。

对网络连接进行IP限制

SQL Server 2000数据库系统本身没有提供网络连接的安全解决办法，但是Windows 2000提供了这样的安全机制，使用操作系统自己的IPSec可以实现IP数据包的安全性。请对IP连接进行限制，只保证自己的IP能够访问，也拒绝其他IP进行的端口连接，把来自网络上的安全威胁进行有效的控制。