数据库 外文翻译 外文文献 英文文献 数据库安全.doc

《数据库 外文翻译 外文文献 英文文献 数据库安全.doc》由会员分享，可在线阅读，更多相关《数据库 外文翻译 外文文献 英文文献 数据库安全.doc（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Database Security“Why do I need to secure my database server? No one can access it its in a DMZ protected 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 organiza

2、tions 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

3、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 sti

4、ll 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 securityBefore we discuss the issues relating to database security it is prudent to high- light the necessity to secure the underlying

5、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 t

6、hat 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

7、 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

8、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 carel

9、ess 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 part

10、s 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 OracleI came across one interesting aspect of database security recently while carrying ou

11、t 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

12、 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, wh

13、ich 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

14、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

15、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

16、 backup data. It does however mean that the password must be remembered! Current trendsThere 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 a

17、vailable 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,

18、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 us

19、ed 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 t

20、he 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 Syb

21、ase. 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 comm

22、on 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

23、 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 th

24、e 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

25、 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 preven

26、ted 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 specif

27、ic 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 ar

28、e 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 si

29、mple 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 se

30、curity practice. OverallIn 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 improv

31、ed.The next article ondatabase 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 (a

32、nd 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 securityOne of the basic first princip

33、als 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

34、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

35、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 instan

36、ce, 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 inf

37、ormation. 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. 数据库平安“为什么要确保数据库效劳平安呢？任何人都不能访问-这是一个非军事区的保护防火墙，当我们被建议使用一个带有平安检查机制的装置时，这是通常的反响。事实上，在防护一个组织的信息方面，数据库的

38、平安是至高无上的，因为它可能会间接接触比我们意识到的更广泛的用户。这是两篇研究数据库平安文章中的第一篇。在这篇文章中我们将讨论一般数据库平安概念和和比拟普遍的问题。在下篇文章，我们将把焦点放在特定的Microsoft SQL和Oracle的平安关注上。近来数据库平安已成为一个热门话题。随着越来越多的人关注计算机平安，我们发现，防火墙和网络效劳器比以前都更加平安化了虽然这并不等于说现在不再有许多不平安的网络存在。因此，重点是加大对技术的考虑力度，譬如以更细腻的审查态度对待数据库。 一般平安意识在我们讨论有关数据库平安问题之前，确保底层操作系统和支撑技术的平安是审慎而且必要的。如果一个vanill

39、a操作系统无法为数据库提供一个稳妥可靠的平安根底，花费太多努力去确保数据库平安是不值得的。当安装操作系统时，有许多好的文献资料可以参考。经常遇到的一个普遍问题，就是作为网络效劳器托管Internet(or Intranet)的同一效劳器上数据库的应用。虽然这可能节省的购置一个单独的效劳器费用，但这严重影响了平安问题。如果这是确定的，当数据库开放地连接到互联网这种情况被证实了。最近的一个例子，我记得是一个Apache网络效劳器系统效劳组织在互联网上提供的，与Oracle数据库在互联网上提供有关端口1521。在调查这个问题时进一步被发现，访问该Oracle效劳器是没有效劳器加以制止之类的保护措施的

40、包括缺乏密码。从互联网开展前景看，这个数据库是不被推崇的，但默认设置的使用以及粗糙的平安措施，使效劳器更加脆弱。上面提到的问题并不是严格地数据库问题，还可以被归类为构建机制和防火墙保护问题，但最终它确是数据库，这是毫不妥协的。平安方面的考虑从面向网络的各局部来看而被迫作出的。你不能依靠任何他人或任何别的事以保护你的数据库平安。 由于SQL和Oracle开发的漏洞给攻击工具一个得以使用的空间。我在最近为客户做的一项平安评估中偶然发现一个数据库平安方面的有趣的是。我们正在进行对使用一个数据库后端SQL以存放客户端的细节的企业内部应用软件的测试。平安审查过程进展顺利，访问控制基于Windows 认证

41、。只有通过认证的Windows用户能够看到属于他们的数据。这个应用软件本身好似对输入要求进行处理，拒绝直接进入资料库的所有尝试。之后我们在工作的办公室偶然发现一个该应用软件的备份。这个媒体装有SQL数据库的备份，这是我们重新存储到笔记本电脑上的。所有平安控制均到那些原先并未恢复数据库的位置上，而且我们能够在适当的位置无任何限制地浏览完整的数据库，以保护敏感的数据。这可能像是一种妥协的系统平安的方式，但确实是重要的。往往并不是采取直接的方法攻击一个目标，并且最终结果是相同的;系统妥协。数据库备份可以存储在效劳器上，从而有利于间接地访问数据。以上问题有一个简单的方法来解决。在SQL 2000可以为

42、备份设定使用密码保护。如果备份使用了密码保护，当创立密码时就必须使用密码。这是一种有效而且不太复杂的方法阻止备份数据的简单捕获。然而这意味着密码必须记住！ 当前趋势在IT平安方面有许多当前趋势，这些中的不少都与数据库平安联系起来。数据库平安方面的焦点正吸引着攻击者的注意力。由于SQL和Oracle开发的漏洞给攻击工具一个得以使用的空间。这些工具的出现提高了赌注，我们已经看到，攻击主要是针对效劳器暴露到互联网的特定数据库端口。贯穿平安业的一个普遍问题是应用软件平安，特别是定制的Web应用程序。随着Web应用程序的功能变得越来越复杂，它带来了应用程序编码方面的平安漏洞的更大的潜在威胁。为了满足应用

43、软件的功能性要求，后端数据存储通常被用来安排网页内容的格式。这就需要更复杂的后端数据编码。开发者使用不同风格的代码开发，其中一局部没有平安意识，这也许是开发错误的源头。SQL注入就是当前IT平安业的一个热门话题。随着愈来愈多的以期缩短时间的开发数据库的方式和手段的出现，目前在技术平安论坛中，争论是很平常的。SQL注入是一个容易让人误导的术语，因为该概念也适用于其他的数据库，包括Oracle，DB2和Sybase系统。 什么是SQL注入？SQL注入的是软件开发人员所不希望出现的与资料库使用代码或指令发送手段的交流方法。这是发现在Web应用软件最常见的形式。任何用户输入应用软件所不允许的内容是攻击

44、的一个常见来源。在座很多朋友已经看到了当访问网站时通常的错误消息框，而且往往显示用户输入没有得到正确处理。一旦出现这种类型的错误，攻击者将把焦点放在更具体的输入字符串上。具体的与平安有关的编码技术在使用组织时应参加编码标准。 由于这种类型的脆弱性所造成的损害，可以很深刻的，尽管这会取决于该应用软件与数据库关联的特权级别。如果该软件以管理者类型权限访问数据，然后恶意运行命令也会是这一级别的访问权限，此时系统妥协是不可防止的。还有这个问题类似于操作系统的平安规那么，在那里，工程应该以最低的权限运行，而且这是必要的。如果是正常的用户访问，然后启用这个限制。同样的问题，SQL的平安也不完全是一个数据库

45、的问题。特定的数据库命令或要求，不应该允许通过应用层。这是可以通过平安码的方式加以预防的。这是一个场外话题，但应该被应用的一些根本步骤的详细设计是有必要的。第一步，在获取任何申请时须验证和控制用户输入。可能的情况下，严格的类型应被设定以控制具体数据例如，期望得到数值数据，字符串类型数据等，并在可能实现的情况下，如果数据是以字符型为根底的，需要禁止特定的非字母数字字符。如果这是不能实现的，应该做出争取使用替代字符的考虑例如，使用单引号，这在 SQL命令中时通常被使用的。在使用您的组织时具体的与平安有关的编码技术应参加编码标准。如果所有开发商都使用相同的基线标准，特定具体的平安措施，这将大大减少S

46、QL注入妥协的风险。能够使用的另一种简单的方法，是去除数据库中不再需要的所有程序。这些限制了数据库中不再需要的或者多于过剩的被恶意利用的程度。这类似于消除操作系统内不需要的效劳程序，是一种常见的平安实践。 总结总之，我已做出的以上的大多数观点是平安概念的一般意识，并没有具体到某个数据库。然而，所有这些确实应用于数据库，而且如果这些根本的平安措施被应用，你的数据库平安属性将大大改善。在下一篇关于数据库的平安的文章中，将侧重于具体的SQL和Oracle平安问题，有为DBAs和开发商提供的详细例子和意见。在上面，我们讨论了一般数据库平安概念和共同面临的问题。在这篇文章我们将集中于特定的Microso

47、ft SQL和Oracle的平安问题，同样重要的是缓解这些问题的解决方案。数据库平安与一般IT平安问题有许多相似之处，都有一些简单的平安措施和步骤，容易实施，从而大大提高平安性。虽然这些看起来像普通常识，但是令人惊讶的是，我们都看到有多少次，常见的平安措施没有落实以至于造成的平安风险。 用户账户和密码平安在IT平安方面的一个首要根本规那么，便是“确保你有一个可靠的密码。在此声明，我已假定首先一个密码已被设定，虽然这种情况往往并非如此。在去年的文章中，我略微谈到了关于一般平安意识的问题，但我认为再次强调这个问题是有必要的，而且至关重要。就像操作系统，人们关注的焦点是内部数据库的账号平安，其目的在

48、于管理账户。在SQL内，这将成为SA账号，在Oracle内，这可以是SYSDBA或者是Oracle账户。SQL SA效劳账户将“SA作为密码，这是很常见的，或者更糟糕的是一个空白密码，这同样很普遍。这类密码连最根本的平安规那么都懒于限制。用户在自己的域账户上将不允许有一个空白密码，所以为什么珍贵的系统资源，例如数据库容许被毫无保障。举例来说，一个空白的“SA密码，使含有客户端软件任何用户如微软的查询分析器或企业经理人去“管理SQL Server和数据库。数据库被用来作为Web应用软件的后端，缺乏密码控制，将导致敏感资料的全盘妥协。随着系统级访问数据库，使得不仅要执行查询到数据库，创立/修改/删除表等，而且也要执行被称为存储程序的内容。