简介 保护开发 SQL Server 的安全 以最低权限帐户身份进行开发 遵照保护 T-SQL 的最佳方法 了解具有独特安全考虑事项的 T-SQL 命令 小结 参考资料

简介

关于如何以安全的方式部署 sql server，存在大量很好的信息源。但是，这些资源的目标用户通常都是那些对已经开发好的应用程序执行保护任务的数据库管理员。另外，还有很多内容讨论了如何编写安全的 .NET 和 ASP.NET 代码，其中包括访问 SQL Server 的 .NET 代码。然而，很多这样的资源关注的是在应用服务器上运行的数据访问代码，而不是在 SQL Server 中执行的 Transact-SQL (T-SQL) 代码。本专栏则将注意力投射到如何开发在 SQL Server 上安全运行的 T-SQL 代码。 www.iTbulo.comsXXIepA

返回页首

保护开发 SQL Server 的安全

开发安全 T-SQL 的第一步是保护开发 SQL Server 的安全。为什么要想方设法地锁定一个不保存真实数据的 SQL Server 实例，而从不将它展示给最终用户呢？这是因为，这样会强制您编写更安全的 T-SQL，并且当将您的应用程序部署到生产中时，也会更加容易地保护该应用程序。下面是几个具体的步骤，采用这些步骤您就可以快速保护开发服务器： www.iTbulo.comsXXIepA

•

在开发或测试 SQL Server 中，至少应该有一个正在运行的、最新的 Service Pack 和 SQL 安全修补程序，这样才能确保您的客户能够在此 SQL Server 版本上成功运行您的应用程序。 www.iTbulo.comsXXIepA

•

默认情况下，SQL Server 2000 Service Pack 3a 会禁用称为“交叉数据库所有权链接”的不安全功能。在开发服务器上安装 SP3 时，如果让该 Service Pack 禁用“交叉数据库所有权链接”，则有助于验证您正在基于安全的服务器配置编写 T-SQL 代码。 www.iTbulo.comsXXIepA

•

找出开发 SQL Server 上常见的安全配置问题的一种简便方法是针对该服务器运行 Microsoft Baseline Security Analyzer。除了这种方法之外，还可以利用本专栏“参考资料”部分列出的资源；这些资源提供了一些附加步骤，可帮助您保护开发 SQL Server 的安全。 www.iTbulo.comsXXIepA

通常情况下，保护开发服务器安全的最佳方法，就好似它正在生产环境中运行那样对它进行保护。您离这个目标越接近，那么就可以越自信于您开发的代码可以在一个安全的生产环境中正常运行。 www.iTbulo.comsXXIepA

返回页首

以最低权限帐户身份进行开发

在开发过程中，大家都着迷于使用具有 sysadmin 或 dbo SQL Server 权限的帐户，直到部署之前才转换为一个权限更低的帐户。使用这种方法存在着一个问题：将设计人员的权限集还原为最低的所需权限集与在开发应用程序过程中编写这些权限集相比，前者要困难得多。 www.iTbulo.comsXXIepA

鉴于部署应用程序之前您要决定可以取消哪些权限，所以请不要使用 SQL sysadmin 帐户开发 T-SQL 代码。如果使用 SQL sysadmin 帐户，可能会造成这样的结果，即应用程序会以比所需权限更多的特权帐户运行。因此，开发时请改为使用具有最低权限的帐户。 www.iTbulo.comsXXIepA

使用这样的帐户进行开发时，您会逐渐地升高授予的特定权限，以 EXEC（执行）一些必需的存储过程、从某些表进行 SELECT（选择）等。请编写这些 GRANT 语句，以便可以将同样的最低权限轻松部署到生产环境中，而不会出现任何基于猜测的操作。 www.iTbulo.comsXXIepA

这种理念同样适用于测试。执行临时测试以及结构更加复杂的测试时，所使用帐户拥有的权限集和用户权限应该与在生产环境中所使用帐户拥有的权限集和用户权限完全相同。 www.iTbulo.comsXXIepA

在开发过程中使用最低权限帐户的另一个优点在于，您可以避免不小心编写出需要危险权限或过高权限的代码。例如，假设您需要在 T-SQL 中与第三方 COM 组件进行交互。为此，一种方法是发送一个 SQL 批处理命令，它直接调用 sp_OACreate 和 sp_OAMethod 来操纵该 COM 对象。在应用程序使用 sysadmin 帐户连接 SQL Server 的开发环境中，上述方法效果很好。但是，当您尝试将已经开发完成的应用程序准备用于生产部署时，您就会发现如果使用权限较低的帐户，那么该方法不会奏效。为了让该应用程序能够使用非 sysadmin 帐户在生产环境中正常运行，您必须针对 sp_OACreate 显式授予 EXECUTE 权限。请考虑一下，如果某个用户最终找到了一个方法，可以使用该应用程序登录执行任意代码，并利用此权限针对 SQL Server 实例化一个类似 Scripting.FileSystemObject 的 COM 对象，将会产生怎样的安全隐患？ www.iTbulo.comsXXIepA

返回页首

遵照保护 T-SQL 的最佳方法

防御一系列称为“SQL 注入式”的安全漏洞是至关重要的。通常情况下，您会使用多层防护来抵御 SQL 注入式攻击： www.iTbulo.comsXXIepA

•

执行用户提供输入的验证（例如，强制数据类型和最大字符串长度）。 www.iTbulo.comsXXIepA

•

转义对数据库引擎可能具有特殊意义的字符序列。在 T-SQL 中，注入式攻击中最常用的两个字符串为单引号字符 (') 和注释字符序列 (--)。 www.iTbulo.comsXXIepA

•

在 T-SQL 语句中，请不要将用户提供的值进行内联。请改为使用预处理语句和参数化。 www.iTbulo.comsXXIepA

SQL 注入式攻击在其他一些地方有详细的说明，所以在此我就不花大量时间来讨论这个问题的细节了。但是要强调一点，SQL 注入式问题并不只限于在应用层构建的 T-SQL 查询。只要执行一个部分由用户提供值构建的 T-SQL 查询，就可能会发生 SQL 注入式问题。这就是说，一个在内部构建查询字符串、并通过 EXEC() 命令或 sp_executesql 存储过程执行该查询的存储过程也可能会受到攻击。请参阅“参考资料&rdqu