数据库安全外文翻译

数据库安全

“为什么要确保数据库服务安全呢？任何人都不能访问-这是一个非军事区的保护防火墙”，当我们被建议使用一个带有安全检查机制的装置时，这是通常的反应。事实上，在防护一个组织的信息方面，数据库的安全是至高无上的，因为它可能会间接接触比我们意识到的更广泛的用户。

这是两篇研究数据库安全文章中的第一篇。在这篇文章中我们将讨论一般数据库安全概念和和比较普遍的问题。在下篇文章，我们将把焦点放在特定的Microsoft SQL和Oracle的安全关注上。

近来数据库安全已成为一个热门话题。随着越来越多的人关注计算机安全，我们发现，防火墙和网络服务器比以前都更加安全化了（虽然这并不等于说现在不再有许多不安全的网络存在）。因此，重点是加大对技术的考虑力度，譬如以更细腻的审查态度对待数据库。

◆一般安全意识

在我们讨论有关数据库安全问题之前，确保底层操作系统和支撑技术的安全是审慎而且必要的。如果一个vanilla操作系统无法为数据库提供一个稳妥可靠的安全基础，花费太多努力去确保数据库安全是不值得的。当安装操作系统时，有许多好的文献资料可以参考。

经常遇到的一个普遍问题，就是作为网络服务器托管Internet(or Intranet)的同一服务器上数据库的应用。虽然这可能节省的购买一个单独的服务器费用，但这严重影响了安全问题。如果这是确定的，当数据库开放地连接到互联网这种情况被证实了。最近的一个例子，我记得是一个Apache网络服务器系统服务组织在互联网上提供的，与Oracle数据库在互联网上提供有关端口1521。在调查这个问题时进一步被发现，访问该Oracle服务器是没有服务器加以制止之类的保护措施的（包括缺乏密码）。从互联网发展前景看，这个数据库是不被推崇的，但默认设置的使用以及粗糙的安全措施，使服务器更加脆弱。

上面提到的问题并不是严格地数据库问题，还可以被归类为构建机制和防火墙保护问题，但最终它确是数据库，这是毫不妥协的。安全方面的考虑从面向网络的各部分来看而被迫作出的。你不能依靠任何他人或任何别的事以保护你的数据库安全。

◆由于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注入妥协的风险。

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

◆总结

总之，我已做出的以上的大多数观点是安全概念的一般意识，并没有具体到某个数据库。然而，所有这些确实应用于数据库，而且如果这些基本的安全措施被应用，你的数据库安全属性将大大改善。在下一篇关于数据库的安全的文章中，将侧重于具体的SQL和Oracle安全问题，有为DBAs和开发商提供的详细例子和意见。

在上面，我们讨论了一般数据库安全概念和共同面临的问题。在这篇文章我们将集中于特定的Microsoft SQL和Oracle的安全问题，同样重要的是缓解这些问题的解决方案。

数据库安全与一般IT安全问题有许多相似之处，都有一些简单的安全措施和步骤，容易实施，从而大大提高安全性。虽然这些看起来像普通常识，但是令人惊讶的是，我们都看到有多少次，常见的安全措施没有落实以至于造成的安全风险。

◆用户账户和密码安全

在IT安全方面的一个首要基本规则，便是“确保你有一个可靠的密码”。在此声明，我已假定首先一个密码已被设定，虽然这种情况往往并非如此。在去年的文章中，我略微谈到了关于一般安全意识的问题，但我认为再次强调这个问题是有必要的，而且至关重要。就像操作系统，人们关注的焦点是内部数据库的账号安全，其目的在于管理账户。在SQL内，这将成为SA账号，在Oracle内，这可以是SYSDBA或者是Oracle账户。

SQL SA服务账户将“SA”作为密码，这是很常见的，或者更糟糕的是一个空白密码，这同样很普遍。这类密码连最基本的安全规则都懒于限制。用户在自己的域账户上将不允许有一个空白密码，所以为什么宝贵的系统资源，例如数据库容许被毫无保障。举例来说，一个空白的“SA”密码，使含有客户端软件任何用