数据库安全外文翻译

数据库安全

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

这是两篇研究数据库安全文章中的第一篇。在这篇文章中我们将讨论一般数据库安全概念和和比较普遍的问题。在下篇文章，我们将把焦点放在特定的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”密码，使含有客户端软件任何用

户（如微软的查询分析器或企业经理人去“管理”SQL Server和数据库）。

数据库被用来作为Web应用软件的后端，缺乏密码控制，将导致敏感资料的全盘妥协。随着系统级访问数据库，使得不仅要执行查询到数据库，创建/修改/删除表等，而且也要执行被称为存储程序的内容。

Database Security

“Why do I need to secure my database server? No one can access it —it’s in a DMZ protecte d by the firewall!” This is often the response when it is recommended that such devices are included within a security health check. In fact, database security is paramount in defending an organizations information, as it may be indirectly exposed to a wider audience than realized.

This is the first of two articles that will examine database security. In this article we will discuss general database security concepts and common problems. In the next article we will focus on specific Microsoft SQL and Oracle security concerns.

Database security has become a hot topic in recent times. With more and more people becoming increasingly concerned with computer security, we are finding that firewalls and Web servers are being secured more than ever(though this does not mean that there are not still a large number of insecure networks out there). As such, the focus is expanding to consider technologies such as databases with a more critical eye.

◆Common sense security

Before we discuss the issues relating to database security it is prudent to high- light the necessity to secure the underlying operating system and supporting technologies. It is not worth spending a lot of effort securing a database if a vanilla operating system is failing to provide a secure basis for the hardening of the data- base. There are a large number of excellent documents in the public domain detailing measures that should be employed when installing various operating systems.

One common problem that is often encountered is the existence of a database on the same server as a web server hosting an Internet (or Intranet) facing application. Whilst this may save the cost of purchasing a separate server, it does seriously affect the security of the solution. Where this is identified, it is often the case that the database is openly connected to the Internet. One recent example I can recall is an Apache Web server serving an organizations Internet offering, with an Oracle database available on the Internet on port 1521. When investigating this issue further it was discovered that access to the Oracle server was not protected (including lack of passwords), which allowed the server to be stopped. The database was not required from an Internet facing perspective, but the use of default settings and careless security measures rendered the server vulnerable.

The points mentioned above are not strictly database issues, and could be classified as architectural and firewall protection issues also, but ultimately it is the database that is compromised. Security considerations have to be made from all parts of a public facing net- work. You cannot rely on someone or something else within your organization protecting your database

from exposure.

◆ Attack tools are now available for exploiting weaknesses in SQL and Oracle

I came across one interesting aspect of database security recently while carrying out a security review for a client. We were performing a test against an intranet application, which used a database back end (SQL) to store client details. The security review was proceeding well, with access controls being based on Windows authentication. Only authenticated Windows users were able to see data belonging to them. The application itself seemed to be handling input requests, rejecting all attempts to access the data- base directly.We then happened to come across a backup of the application in the office in which we were working. This media contained a backup of the SQL database, which we restored onto our laptop. All security controls which were in place originally were not restored with the database and we were able to browse the complete database, with no restrictions in place to protect the sensitive data. This may seem like a contrived way of compromising the security of the system, but does highlight an important point. It is often not the direct approach that is taken to attack a target, and ultimately the endpoint is the same; system compromise. A backup copy of the database may be stored on the server, and thus facilitates access to the data indirectly.

There is a simple solution to the problem identified above. SQL 2000 can be configured to use password protection for backups. If the backup is created with password protection, this password must be used when restoring the password. This is an effective and uncomplicated method of stopping simple capture of backup data. It does however mean that the password must be remembered!

◆Curr ent tr ends

There are a number of current trends in IT security, with a number of these being linked to database security.

The focus on database security is now attracting the attention of the attackers. Attack tools are now available for exploiting weaknesses in SQL and Oracle. The emergence of these tools has raised the stakes and we have seen focused attacks against specific data- base ports on servers exposed to the Internet.

One common theme running through the security industry is the focus on application security, and in particular bespoke Web applications. With he functionality of Web applications becoming more and more complex, it brings the potential for more security weaknesses in bespoke application code. In order to fulfill the functionality of applications, the backend data stores are commonly being used to format the content of Web pages. This requires more complex coding at the application end. With developers using different styles in code development, some of which are not as security conscious as

other, this can be the source of exploitable errors.

SQL injection is one such hot topic within the IT security industry at the moment. Discussions are now commonplace among technical security forums, with more and more ways and means of exploiting databases coming to light all the time. SQL injection is a misleading term, as the concept applies to other databases, including Oracle, DB2 and Sybase.

◆ What is SQL Injection?

SQL Injection is simply the method of communication with a database using code or commands sent via a method or application not intended by the developer. The most common form of this is found in Web applications. Any user input that is handled by the application is a common source of attack. One simple example of mishandling of user input is highlighted in Figure 1. Many of you will have seen this common error message when accessing web sites, and often indicates that the user input has not been correctly handled. On getting this type of error, an attacker will focus in with more specific input strings.

Specific security-related coding techniques should be added to coding standard in use within your organization. The damage done by this type of vulnerability can be far reaching, though this depends on the level of privileges the application has in relation to the database.If the application is accessing data with full administrator type privileges, then maliciously run commands will also pick up this level of access, and system compromise is inevitable. Again this issue is analogous to operating system security principles, where programs should only be run with the minimum of permissions that is required. If normal user access is acceptable, then apply this restriction.

Again the problem of SQL security is not totally a database issue. Specific database command or requests should not be allowed to pass through the

application layer. This can be prevented by employing a “secure coding” approach.

Again this is veering off-topic, but it is worth detailing a few basic steps that should be employed.

The first step in securing any application should be the validation and control of user input. Strict typing should be used where possible to control specific data (e.g. if numeric data is expected), and where string based data is required, specific non alphanumeric characters should be prohibited where possible. Where this cannot be performed, consideration should be made to try and substitute characters (for example the use of single quotes, which are commonly used in SQL commands).

Specific security-related coding techniques should be added to coding

standard in use within your organization. If all developers are using the same baseline standards, with specific security measures, this will reduce the risk of SQL injection compromises.

Another simple method that can be employed is to remove all procedures within the database that are not required. This restricts the extent that unwanted or superfluous aspects of the database could be maliciously used. This is analogous to removing unwanted services on an operating system, which is common security practice.

◆ Overall

In conclusion, most of the points I have made above are common sense security concepts, and are not specific to databases. However all of these points DO apply to databases and if these basic security measures are employed, the security of your database will be greatly improved.

The next article on database security will focus on specific SQL and Oracle security problems, with detailed examples and advice for DBAs and developers.

There are a lot of similarities between database security and general IT security, with generic simple security steps and measures that can be (and should be) easily implemented to dramatically improve security. While these may seem like common sense, it is surprising how many times we have seen that common security measures are not implemented and so cause a security exposure.

◆User account and password security

One of the basic first principals in IT security is “make sure you have a good password”. Within this statement I have assumed that a password is set in the first place, though this is often not the case. I touched on common sense security in my last article, but I think it is important to highlight this again. As with operating systems, the focus of attention within database account security is aimed at administration accounts. Within SQL this will be the SA account and within Oracle it may be the SYSDBA or ORACLE account.

It is very common for SQL SA accounts to have a password of ‘SA’ or even worse a blank password, which is just as common. This password laziness breaks the most basic security principals, and should be stamped down on. Users would not be allowed to have a blank password on their own domain account, so why should valuable system resources such as databases be allowed to be left unprotected. For instance, a blank ‘SA’ password will enable any user with client software (i.e. Microsoft query analyser or enterprise manager to ‘manage’ the SQL server and databases).

With databases being used as the back end to Web applications, the lack of password control can result in a total compromise of sensitive information. With system level access to the database it is possible not only to execute queries into the database, create/modify/delete tables etc, but also to execute what are known as Stored Procedures.