SQL Server安全管理【转载自中国网管联盟】

版本 1.0， 2005年6月


目录
1. 文档信息及版本 3
2. 数据库安全概述 4
3. 数据库基础安全 4
3.1. 物理安全 4
3.2. 安装补丁 5
3.3. 过滤数据库端口 5
3.4. 服务器信任关系 6
4. 数据库安全配置 6
4.1. 采用NTFS文件分区 6
4.2. 选择安全的验证模式 7
4.3. 访问权限控制 7
4.4. 选择安全的网络协议 8
4.5. 使用安全的密码策略 8
4.6. 许可连接 9
4.7. 基础库的访问控制 9
4.8. 管理扩展存储过程 9
4.9. 取消邮件功能 13
4.10. 管理动态链接库文件 13
4.11. 脚本写入的权限控制 13
4.12. 数据库过滤 14
5. 数据库日常安全性管理 14
5.1. 查看活动的进程信息 14
5.2. 查看数据库日志记录 15
5.3. SQL Server 最佳实践分析工具的使用 15


1. 文档信息及版本
一般信息 细节
名称 SQL Server 安全管理
状态 已完成
版本 1.0
作者 Eric
贡献者 Eric


版本 时间 姓名 注解
1.0 2005-6-11 Eric


2. 数据库安全概述
目前，网络上的各种应用系统越来越多，很多应用都采用了后台挂接数据库的方式，而现在网上大多数的黑客攻击行为基本上都是针对各种类型的数据库而展开的，可见数据库的安全与否直接关系到你的应用系统的安全，或者是你服务器的安危。数据库的安全的确是个很大、涉及面很广，但是又是非常重要的话题，相信未来几年的时间里，网上的黑客攻击行为都是针对数据库安全为主的。因为数据库的实际应用是有非常多的类型，比如：MySQL、SQL Server、Infomix、Sybase、Oracle、DB2等，我们将把MS SQL Server作为主要说明的对象。
为了实现数据库的安全防护，我们必须确定两部分安全：
第一， 操作系统的安全性考虑，因为数据库的安全，很大程度上也是依赖操作系统的安全（关于系统安全性的内容，请参照系统安全相关的说明文档）。
第二， 数据库系统自身的安全配置


3. 数据库基础安全
3.1. 物理安全
把数据库服务器保存在安全的地方并隔离起来，同时也应该考虑为机房上安全门禁系统

3.2. 安装补丁
不管是什么数据库系统，在我们成功安装了数据库系统以后，我们都应该在第一时间就给数据库打上最新的补丁，比如：SQL Server安装完成以后，我们就应该立即为其打上SP3的补丁（目前，微软已经推出了SQL Server的SP4，请对SP4经过测试后，再行安装），这是数据库管理员应该具有的最基本的安全常识。
 SQL Server版本检查
使用 SQL Server Version Checker 1.0检查目前运行的SQL Server的当前版本以及SQL Server相关补丁的安装情况。
3.3. 过滤数据库端口
首先，不管我们的网络结构以及各种应用系统如何分布和搭配的，我们都需要保证至少在数据库服务器的外部要接入一道防火墙，尽可能避免用户直接登录数据库服务器，因为数据库服务器无疑是我们所有应用系统中的核心部分，它存储了应用系统的交换数据，对我们的重要性是不言而喻的。
 首先，我们可以使用防火墙过滤掉该数据库对外开放的端口，比如：SQL Server的默认访问端口是1433、MySQL的默认访问端口是3306，禁止一切从外部直接访问内部数据库的行为发生，这是确保数据库安全的基础。
 对于SQL Server来说，我们可以在实例属性中选择TCP/IP协议的属性。选择隐藏 SQL Server 实例。如果隐藏了 SQL Server 实例，则将禁止对试图枚举网络上现有的 SQL Server 实例的客户端所发出的广播作出响应。这样，别人就不能用1433来探测你的TCP/IP端口了。
 对于Windows 2000操作系统来说，我们也可以使用IPSec过滤拒绝掉1434端口的UDP通讯，从而尽可能地隐藏你的SQL Server
3.4. 服务器信任关系
服务器彼此间的信任关系，对于数据库服务器而言也是非常重要的，即使你的前台应用服务器的安全性已经做到足够的高了，但是，你仍然需要提高警惕，你不能把你最重要的数据的安全性寄托在一道防线上，打个比方，如果黑客通过利用各种应用系统的漏洞攻陷了你的前台应用服务器，而你的数据库服务器对于该被攻陷的应用服务器的访问是完全信任的，那么你的数据库服务器很快就会离你而去。
简单点说，不管其他和数据库服务器有业务关联或数据关联的服务器的安全性做的如何的高，不管外部链接是否能直接访问内部数据库服务器中的内容，你的数据库服务器都应该做独立的安全防护。这一点是非常重要的，也是我们特别需要明确的！

4. 数据库安全配置
这些安全配置其实非常的简单，只需要稍微花点时间配置一下即可，但是Internet很多的数据库服务器的管理员都没有太多的关注这些方面。我们随便用数据库扫描工具就能扫出一大堆的SA空密码的机器，就算是初级水平的黑客也能把你的数据库删的干干净净。
4.1. 采用NTFS文件分区
确保所有的SQL服务器的数据和系统文件都安装再NTFS分区上并配置相应的ACL，我们强烈推荐采用NTFS，因为可以充分利用Windows系统中NTFS文件分区的安全性。NTFS文件系统可以将每个用户允许读写的文件限制在磁盘目录或磁盘目录下的任何一个文件夹。
4.2. 选择安全的验证模式
SQL Server提供两种不同概念的验证模式，分别是：Windows验证模式和混合验证模式。这是两种不同级别的安全验证模式。
Windows验证模式主要是以系统的帐号验证策略作为基础的，其安全性依赖于系统的安全性，所以要保证采用Windows验证模式的数据库的安全性，前提条件必须也要保证Windows的帐户策略有足够的安全。而混合验证模式则是以SQL Server自身的验证机制为基础的，其安全性并不能得到很好的保证。所以我们强烈推荐大家使用Windows验证模式。

4.3. 访问权限控制
 由于SQL Server不能更改Sa用户名称，也不能删除这个超级用户，所以，我们必须对这个帐号进行最强的保护，当然，包括使用一个非常强壮的密码，最好不要在数据库应用中使用sa帐号，只有当没有其它方法登录到 SQL Server 实例（例如，当其它系统管理员不可用或忘记了密码）时才使用 Sa。建议数据库管理员新建立一个拥有与Sa一样权限的超级用户来管理数据库。安全的帐号策略还包括不要让管理员权限的帐号泛滥。 很多服务器使用数据库应用只是用来做查询、修改等简单功能的，请根据实际需要分配帐号，并赋予仅仅能够满足应用要求和需要的权限。比如，只要查询功能的，那么就使用一个简单的public帐号能够select就可以了。
 如果有人需要直接登录SQL服务器，确保只给最低的权限而避免出现不必要的意外
 避免使用管理员和本地系统帐号来运行SQL服务器，应该使用权限比较低的帐号来启动SQL服务
 该帐号应该遵循最低权限的原则，因为这样可以大大降低服务器被完全破坏的危险性
 如果是通过Enterprise Manager来做这样的设置，那么相关文件的ACL、注册表及用户权限都会被自动设定而不需要管理员手工逐项添加

4.4. 选择安全的网络协议
确保选择合适的SQL服务器的网络协议来最大限度的保证安全
 删除所有不需要的网络协议
 由于Microsoft从SQL 2000开始就推行TCP/IP作为Net-Lib的主要选择，所以现在的问题其实是要不要选择SSL来连接SQL服务器
4.5. 使用安全的密码策略
即使我们采用更为安全可靠的Windows验证模式，我们对数据库访问帐号的密码是否安全也不能不关心，因为上面我们已经提到，SQL Server中的Sa帐号不管你采用何种验证模式，它都是存在的，所以我们必须要对Sa施以更强壮的密码保护。同时，我们更加应该注意，不要让Sa帐号的密码写于应用程序或者脚本中。这也是现在网络中很多跨站攻击利用的手段之一，数据库管理员应该定期查看是否有不符合密码策略要求的帐号。
 检查所有使用空白密码登录数据库的用户，详细语句如下：
Use master
Select name, Password from syslogins where password is null order bye name
 把Guest用户从数据库中删除掉以禁止非法用户连接数据库
 备注：Master和Tempdb数据库都需要用到Guest帐户
4.6. 许可连接
对连接数据库的最大连接数以及连接方式和连接来源的IP等，根据实际应用的情况，都必须要做出相应的限制。
 审计所有用户的数据连接使用记录
 管理员可以在Enterprise Manager里做相应设置，也可以在查询分析器（Query Analyzer）里运行下面命令：
Xp_instance_regwrite N’HKEY_LOCAL_MACHINE’
N’SOFTWARE\Microsoft\MSSQL Server\MSSQLServer’,N’Auditlevel
REG_DWORD,3

4.7. 基础库的访问控制
作为整个数据库的基础库，（比如：SQL Server中的Master库）我们应该严格控制能够访问基础库的数据库帐号以及这些帐号所具有的访问权限，因为通过对该基础库的访问，可以进行很多OS级的操作，这不管是对数据库还是操作系统，都是不能允许的。

4.8. 管理扩展存储过程
我们必须要加强对系统级存储过程和扩展存储过程的权限控制，其实在多数应用中根本用不到多少系统的存储过程，而数据库所拥有的这么多系统存储过程只是用来适应广大用户需求的，所以请删除不必要的存储过程，因为有些系统的存储过程能很容易地被人利用起来提升权限或进行破坏。针对有安全隐患的存储过程，这里做个简单的归纳，比如：
 扩展存储过程Xp_Cmdshell
如果你不需要使用Xp_Cmdshell扩展存储过程，请一定要删除或者在数据库中Drop掉，因为这个扩展存储过程在给你带来很多强大的功能的便利之外，也给你带来了巨大的风险
 OLE自动存储过程
OlE自动存储过程会记录相关的一些数据库信息，也会带来一定的安全风险，建议丢弃OLE自动存储过程（丢弃后，可能会造成管理器中的某些特征不能使用）。
 注册表访问存储过程
必须要去掉一些不需要的注册表访问存储过程，这些存储过程甚至能够通过访问注册表的相关键值读出操作系统管理员的密码
 经常检查所有非“Sa”用户使用存储过程（Stored Procedure）和扩展存储过程（Extended Stored Procedures）的权限，比如可以使用下列SQL语句来列出所有可以被Public组调用的的存储过程和扩展存储过程
Use master
Select sysobjects.name From sysobjects,sysprotects Where sysprotects.uid=0
AND xtype IN (‘X’, ‘P’) AND sysobjects.id=sysprotects.id Order by name



 对一些可能导致安全威胁的存储过程和扩展存储过程确保只有管理员可以访问和使用。这类的存储过程有很多，当管理员需要对SQL服务器做安全强化时，建议先在做测试的开发服务器上调试后再应用到真正的服务器上，详细如下：
 丢弃不需要的OLE自动存储过程，当然Enterprise Manager中的某些特征也会不能使用，这些过程包括如下：
Sp_OACreate
Sp_OADestroy
Sp_OAGetErrorInfo
Sp_OAGetProperty
Sp_OAMethod
Sp_OASetProperty
Sp_OAStop


 去掉不需要的注册表访问过程，如下：
Xp_regaddmultistring
Xp_regdeletekey
Xp_regdeletevalue
Xp_regenumvalues
Xp_regread
Xp_regremovemultistring
Xp_regwrite


 去掉其他系统存储过程，如果你认为你觉得你还有威胁，当然
要小心Drop这些过程，你可以在测试机器上测试，保证你正常的
系统能完成工作，这些过程包括：
Sp_bindsession Sp_cursor Sp_cursorclose
Sp_cursorfetch Sp_cursoropen Sp_cursoroption
Sp_getbindtoken Sp_GetMBCSCharLen Sp_IsMBCSLeadByte
Sp_replcmds Sp_replcounters Sp_repldone
Sp_replflush Sp_replstatus Sp_sdidebug
Sp_repltrans Sp_sdidebug Xp_availablemedia
Xp_cmdshell Xp_deletemail Xp_dirtree
Xp_dropwebtask Xp_dsninfo Xp_enumdsn
Xp_enumerrorlogs Xp_enumgroups Xp_enumqueuedtasks
Xp_eventlog Xp_findnextmsg Xp_fixeddrives
Xp_getfiledetails Xp_getnetname Xp_grantlogin
Xp_logevent Xp_loginconfig Xp_logininfo
Xp_makewebtask Xp_msver Xp_perfend
Xp_perfmonitor Xp_perfsample Xp_perfstart
Xp_readerrorlog Xp_readmail Xp_revokelogin
Xp_runwebtask Xp_schedulersignal Xp_sendmail
Xp_servicecontrol Xp_snmp_getstate Xp_snmp_raisetrap
Xp_sprintf Xp_sqlinventory Xp_sqlregister
Xp_sqltrace Xp_sscanf Xp_startmail
Xp_stopmail Xp_subdirs Xp_unc_to_drive


 定期检查Mster..Sp_helpstartup，避免木马存储过程的存在
 确保没有任何人能在这里设立后门，一旦发现这样的木马程序的存在，用Sp_unmakestartup对其进行删除
 定期检查Master..Sp_password避免木马程序的存在
 管理员应当经常把该应用的脚本和干净安装后的默认脚本做比较来进行鉴定，如果你需要修改默认脚本，那么请保存一个修改后的副本作为参照
 检查所有不需要“Sa”权限可以访问的存储过程和扩展存储过程
Use master
Select sysobjects.name
From sysobjects,sysprotects
Where sysprotects.uid = 0
AND xtype IN ('X','P')
AND sysobjects.id = sysprotects.id
Order by name

备注：在处理存储过程的前，请一定要经过仔细确认，避免对数据库或者应用程序造成影响。

4.9. 取消邮件功能
除非必须使用，否则请禁止SQL服务器的邮件功能，SQL Server的邮件功能可能会为攻击者制造发布木马、病毒和DOS攻击的机会
4.10. 管理动态链接库文件
上面我们讨论的各种有安全隐患的扩展存储过程，都是通过各种动态链接库文件来实现对数据库以及系统或者注册表的访问动作的。因此，我们仅仅对存储过程多了相关的限制并不是解决问题的所有手段，我们必须对涉及这些存储过程的动态链接库文件进行处理。比如：Xp_Cmdshell对应的动态链接库文件就是Xplog70.dll。
其实，如果仅仅只是应用，而不涉及后期开发的话，建议直接删除这些动态链接库文件。
相关的动态链接库文件有：Xplog70.dll、Xpweb.dll、Xpsql70.dll、Xpstar.dll

4.11. 脚本写入的权限控制
在加强了上述安全手段的同时，我们同样要做好脚本写入和执行的权限的控制，避免恶意人员通过写入特殊的脚本来重建存储过程，或者直接通过特殊的脚本来执行系统命令。

4.12. 数据库过滤
这是数据库安全管理中最为重要，也是与我们的应用系统结合的最为紧密的一层防护手段，我们必须要提防不怀好意的人通过构造一些特殊的或者是变形的数据库查询请求提交给数据库，返回其可以利用的信息或结果。大体上可以分为两个部分来实施：
第一， 可以在应用系统开发的过程中，在程序代码中对经过特殊构造的具有某些恶意的数据库查询请求进行过滤
第二， 开发程序时尽量使用存储过程和视图（SQL Views）而避免用户直接连接并使用数据表中的数据
第三， 对数据库加载脚本也可以做相关的安全配置，从而过滤某些经过变形的恶意数据库查询请求。

5. 数据库日常安全性管理
5.1. 启动备份策略
定期对业务系统的数据进行备份
5.2. 数据库压缩和收缩
定期对数据库进行数据压缩，减少数据库的数据冗余状况，提高数据库有效利用率；定期对数据库进行收缩，减少日志容量，提高数据库访问效率，降低数据库发生故障的可能性。
5.3. 查看活动的进程信息
要定时对数据库中活动的进程信息进行查看，这样可以掌握数据库某一时刻的被访问情况，、访问的帐号，来源，以及正在数据库中进行的活动内容等等，方便我们更好的管理数据库，提高其整体安全性。

5.4. 查看数据库日志记录
通过定时对数据库的日志文件进行检查，我们可以掌握数据库的基本运行状态。同时对这些日志记录的分析，可以了解数据库系统是否有非正常的动作发生，从而为我们的安全管理提供帮助。
 为数据操作失败和登录失败的事件设置警报
数据库的所有错误信息都保存再Master..sysmessages表中，管理员应当定期审核其中的记录，对于所有严重度（Severity）超过14的记录可以考虑设置警报并通过邮件或短信及时通知管理员
5.5. SQL Server 最佳实践分析工具的使用
通过使用SBPA（SQL Best Practices Analyzer）可以快速的检查和分析客户当前数据库的各项安全性配置，并提供详细的分析报告