数据库安全文献翻译.doc

数据库安全文献翻译

黄河科技学院毕业设计（文献翻译）

第 2页英文译文

数据库安全

Paul Morrison

America

PART 1

“为什么要确保数据库服务安全呢？任何人都不能访问-这是一个非军事区的保护防火墙”，当我们被建议使用一个带有安全检查机制的装置时，这是通常的反应。事实

上，在防护一个组织的信息方面，数据库的安全是至高无上的，因为它可能会间接接触

比我们意识到的更广泛的用户。

这是两篇研究数据库安全文章中的第一篇。在这篇文章中我们将讨论一般数据库安全

概念和和比较普遍的问题。在下篇文章，我们将把焦点放在特定的 Microsoft SQL 和Oracle 的安全关注上。

近来数据库安全已成为一个热门话题。随着越来越多的人关注计算机安全，我们发现，防火墙和网络服务器比以前都更加安全化了（虽然这并不等于说现在不再有许多不安

全的网络存在）。因此，重点是加大对技术的考虑力度，譬如以更细腻的审查态度对待数据库。

◆ 一般安全意识

在我们讨论有关数据库安全问题之前，确保底层操作系统和支撑技术的安全是审

慎而且必要的。如果一个 vanilla 操作系统无法为数据库提供一个稳妥可靠的安全基础，

花费太多努力去确保数据库安全是不值得的。当安装操作系统时，有许多好的文献资料可以参考。

经常遇到的一个普遍问题，就是作为网络服务器托管Internet(or Intranet) 的同一服务器上数据库的应用。虽然这可能节省的购买一个单独的服务器费用，但这严重影响了安全问题。如果这是确定的，当数据库开放地连接到互联网这种情况被证实了。最近的

一个例子，我记得是一个Apache网络服务器系统服务组织在互联网上提供的，与Oracle 数据库在互联网上提供有关端口 1521。在调查这个问题时进一步被发现，访问该 Oracle 服务器是没有服务器加以制止之类的保护措施的（包括缺乏密码）。从互联网发展前景

黄河科技学院毕业设计（文献翻译）第3页

看，这个数据库是不被推崇的，但默认设置的使用以及粗糙的安全措施，使服务器更加

脆弱。

上面提到的问题并不是严格地数据库问题，还可以被归类为构建机制和防火墙保护

问题，但最终它确是数据库，这是毫不妥协的。安全方面的考虑从面向网络的各部分来

看而被迫作出的。你不能依靠任何他人或任何别的事以保护你的数据库安全。◆由于

SQL 和 Oracle 开发的漏洞给攻击工具一个得以使用的空间。

我在最近为客户做的一项安全评估中偶然发现一个数据库安全方面的有趣的是。我们正在进行对使用一个数据库后端（SQL）以存放客户端的细节的企业内部应用软件的

测试。安全审查过程进展顺利，访问控制基于 Windows 认证。只有通过认证的 Windows 用户能够看到属于他们的数据。这个应用软件本身好像对输入要求进行处理，拒绝直接进入资料库的所有尝试。

之后我们在工作的办公室偶然发现一个该应用软件的备份。这个媒体装有SQL 数据库的备份，这是我们重新存储到笔记本电脑上的。所有安全控制均到那些原先并未恢

复数据库的位置上，而且我们能够在适当的位置无任何限制地浏览完整的数据库，以保护敏感的数据。这可能像是一种妥协的系统安全的方式，但确实是重要的。往往并不是

采取直接的方法攻击一个目标，并且最终结果是相同的;系统妥协。数据库备份可以存

储在服务器上，从而有利于间接地访问数据。

以上问题有一个简单的办法来解决。在 SQL 2000 可以为备份设定使用密码保护。如

果备份使用了密码保护，当创建密码时就必须使用密码。这是一种有效而且不太复杂的

方法阻止备份数据的简单捕获。然而这意味着密码必须记住！◆ 当前趋势在 IT 安全方面有许多当前趋势，这些中的不少都与数据库安全联系起来。数据库

安全方面的焦点正吸引着攻击者的注意力。由于 SQL 和 Oracle 开发的漏洞给攻击工具

一个得以使用的空间。这些工具的出现提高了赌注，我们已经看到，攻击主要是针对服务器暴露到互联网的特定数据库端口。

贯穿安全业的一个普遍问题是应用软件安全，特别是定制的Web 应用程序。随着

Web 应用程序的功能变得越来越复杂，它带来了应用程序编码方面的安全漏洞的更大

的潜在威胁。为了满足应用软件的功能性要求，后端数据存储通常被用来安排网页内容

的格式。这就需要更复杂的后端数据编码。开发者使用不同风格的代码开发，其中一部

分没有安全意识，这也许是开发错误的源头。

SQL 注入就是当前IT 安全业的一个热门话题。随着愈来愈多的以期缩短时间的开

发数据库的方式和手段的出现，目前在技术安全论坛中，争论是很平常的。SQL 注入是一个容易让人误导的术语，因为该概念也适用于其他的数据库，包括Oracle，DB2 和Sybase系统。

◆什么是 SQL 注入？

SQL 注入的是软件开发人员所不希望出现的与资料库使用代码或指令发送手段的交

流方法。这是发现在 Web 应用软件最常见的形式。任何用户输入应用软件所不允许的内

容是攻击的一个常见来源。

在座很多朋友已经看到了当访问网站时通常的错误消息框，而且往往显示用户输入没有得到正确处理。一旦出现这种类型的错误，攻击者将把焦点放在更具体的输入字符串上。具体的与安全有关的编码技术在使用组织时应加入编码标准。

由于这种类型的脆弱性所造成的损害，可以很深刻的，尽管这会取决于该应用软件与数

据库关联的特权级别。如果该软件以管理者类型权限访问数据，然后恶意运行命令也会

是这一级别的访问权限，此时系统妥协是不可避免的。还有这个问题类似于操作系统的

安全规则，在那里，项目应该以最低的权限运行，而且这是必要的。如果是正常的用户访问，然后启用这个限制。

同样的问题， SQL 的安全也不完全是一个数据库的问题。特定的数据库命令或要

求，不应该允许通过应用层。这是可以通过 " 安全码 " 的方式加以预防的。这是一个场外话题，但应该被应用的一些基本步骤的详细设计是有必要的。

第一步，在获取任何申请时须验证和控制用户输入。可能的情况下，严格的类型应被

设定以控制具体数据（例如，期望得到数值数据，字符串类型数据等），并在可能实现的

情况下，如果数据是以字符型为基础的，需要禁止特定的非字母数字字符。如果这

是不能实现的，应该做出争取使用替代字符的考虑（例如，使用单引号，这在 SQL 命令中时通常被使用的）。

在使用您的组织时具体的与安全有关的编码技术应加入编码标准。如果所有开发商都使用相同的基线标准，特定具体的安全措施，这将大大减少SQL 注入妥协的风险。

能够使用的另一种简单的方法，是清除数据库中不再需要的所有程序。这些限制了数据库中不再需要的或者多于过剩的被恶意利用的程度。这类似于消除操作系统内不需