計(jì)算機(jī)外文翻譯--數(shù)據(jù)庫(kù)安全

1、<p><b>　　英文譯文</b></p><p><b>　　數(shù)據(jù)庫(kù)安全</b></p><p>　　Paul Morrison</p><p><b>　　America</b></p><p><b>　　PART 1</b></p

2、><p>　　“為什么要確保數(shù)據(jù)庫(kù)服務(wù)安全呢？任何人都不能訪問-這是一個(gè)非軍事區(qū)的保護(hù)防火墻”，當(dāng)我們被建議使用一個(gè)帶有安全檢查機(jī)制的裝置時(shí)，這是通常的反應(yīng)。事實(shí)上，在防護(hù)一個(gè)組織的信息方面，數(shù)據(jù)庫(kù)的安全是至高無上的，因?yàn)樗赡軙?huì)間接接觸比我們意識(shí)到的更廣泛的用戶。</p><p>　　這是兩篇研究數(shù)據(jù)庫(kù)安全文章中的第一篇。在這篇文章中我們將討論一般數(shù)據(jù)庫(kù)安全概念和和比較普遍的問題。在下篇文章

3、，我們將把焦點(diǎn)放在特定的Microsoft SQL和Oracle的安全關(guān)注上。</p><p>　　近來數(shù)據(jù)庫(kù)安全已成為一個(gè)熱門話題。隨著越來越多的人關(guān)注計(jì)算機(jī)安全，我們發(fā)現(xiàn)，防火墻和網(wǎng)絡(luò)服務(wù)器比以前都更加安全化了（雖然這并不等于說現(xiàn)在不再有許多不安全的網(wǎng)絡(luò)存在）。因此，重點(diǎn)是加大對(duì)技術(shù)的考慮力度，譬如以更細(xì)膩的審查態(tài)度對(duì)待數(shù)據(jù)庫(kù)。</p><p><b>　　◆ 一般安全意識(shí)&

4、lt;/b></p><p>　　在我們討論有關(guān)數(shù)據(jù)庫(kù)安全問題之前，確保底層操作系統(tǒng)和支撐技術(shù)的安全是審慎而且必要的。如果一個(gè)vanilla操作系統(tǒng)無法為數(shù)據(jù)庫(kù)提供一個(gè)穩(wěn)妥可靠的安全基礎(chǔ)，花費(fèi)太多努力去確保數(shù)據(jù)庫(kù)安全是不值得的。當(dāng)安裝操作系統(tǒng)時(shí)，有許多好的文獻(xiàn)資料可以參考。</p><p>　　經(jīng)常遇到的一個(gè)普遍問題，就是作為網(wǎng)絡(luò)服務(wù)器托管Internet(or Intranet)的

5、同一服務(wù)器上數(shù)據(jù)庫(kù)的應(yīng)用。雖然這可能節(jié)省的購(gòu)買一個(gè)單獨(dú)的服務(wù)器費(fèi)用，但這嚴(yán)重影響了安全問題。如果這是確定的，當(dāng)數(shù)據(jù)庫(kù)開放地連接到互聯(lián)網(wǎng)這種情況被證實(shí)了。最近的一個(gè)例子，我記得是一個(gè)Apache網(wǎng)絡(luò)服務(wù)器系統(tǒng)服務(wù)組織在互聯(lián)網(wǎng)上提供的，與Oracle數(shù)據(jù)庫(kù)在互聯(lián)網(wǎng)上提供有關(guān)端口1521。在調(diào)查這個(gè)問題時(shí)進(jìn)一步被發(fā)現(xiàn)，訪問該Oracle服務(wù)器是沒有服務(wù)器加以制止之類的保護(hù)措施的（包括缺乏密碼）。從互聯(lián)網(wǎng)發(fā)展前景看，這個(gè)數(shù)據(jù)庫(kù)是不被推崇的，但默

6、認(rèn)設(shè)置的使用以及粗糙的安全措施，使服務(wù)器更加脆弱。</p><p>　　上面提到的問題并不是嚴(yán)格地?cái)?shù)據(jù)庫(kù)問題，還可以被歸類為構(gòu)建機(jī)制和防火墻保護(hù)問題，但最終它確是數(shù)據(jù)庫(kù)，這是毫不妥協(xié)的。安全方面的考慮從面向網(wǎng)絡(luò)的各部分來看而被迫作出的。你不能依靠任何他人或任何別的事以保護(hù)你的數(shù)據(jù)庫(kù)安全。</p><p>　　◆ 由于SQL和Oracle開發(fā)的漏洞給攻擊工具一個(gè)得以使用的空間。</p&

7、gt;<p>　　我在最近為客戶做的一項(xiàng)安全評(píng)估中偶然發(fā)現(xiàn)一個(gè)數(shù)據(jù)庫(kù)安全方面的有趣的是。我們正在進(jìn)行對(duì)使用一個(gè)數(shù)據(jù)庫(kù)后端（SQL）以存放客戶端的細(xì)節(jié)的企業(yè)內(nèi)部應(yīng)用軟件的測(cè)試。安全審查過程進(jìn)展順利，訪問控制基于Windows 認(rèn)證。只有通過認(rèn)證的Windows用戶能夠看到屬于他們的數(shù)據(jù)。這個(gè)應(yīng)用軟件本身好像對(duì)輸入要求進(jìn)行處理，拒絕直接進(jìn)入資料庫(kù)的所有嘗試。</p><p>　　之后我們?cè)诠ぷ鞯霓k公室偶

8、然發(fā)現(xiàn)一個(gè)該應(yīng)用軟件的備份。這個(gè)媒體裝有SQL數(shù)據(jù)庫(kù)的備份，這是我們重新存儲(chǔ)到筆記本電腦上的。所有安全控制均到那些原先并未恢復(fù)數(shù)據(jù)庫(kù)的位置上，而且我們能夠在適當(dāng)?shù)奈恢脽o任何限制地瀏覽完整的數(shù)據(jù)庫(kù)，以保護(hù)敏感的數(shù)據(jù)。這可能像是一種妥協(xié)的系統(tǒng)安全的方式，但確實(shí)是重要的。往往并不是采取直接的方法攻擊一個(gè)目標(biāo)，并且最終結(jié)果是相同的;系統(tǒng)妥協(xié)。數(shù)據(jù)庫(kù)備份可以存儲(chǔ)在服務(wù)器上，從而有利于間接地訪問數(shù)據(jù)。</p><p>　　以

9、上問題有一個(gè)簡(jiǎn)單的辦法來解決。在SQL 2000可以為備份設(shè)定使用密碼保護(hù)。如果備份使用了密碼保護(hù)，當(dāng)創(chuàng)建密碼時(shí)就必須使用密碼。這是一種有效而且不太復(fù)雜的方法阻止備份數(shù)據(jù)的簡(jiǎn)單捕獲。然而這意味著密碼必須記??！</p><p><b>　　◆ 當(dāng)前趨勢(shì)</b></p><p>　　在IT安全方面有許多當(dāng)前趨勢(shì)，這些中的不少都與數(shù)據(jù)庫(kù)安全聯(lián)系起來。數(shù)據(jù)庫(kù)安全方面的焦點(diǎn)正吸

10、引著攻擊者的注意力。由于SQL和Oracle開發(fā)的漏洞給攻擊工具一個(gè)得以使用的空間。這些工具的出現(xiàn)提高了賭注，我們已經(jīng)看到，攻擊主要是針對(duì)服務(wù)器暴露到互聯(lián)網(wǎng)的特定數(shù)據(jù)庫(kù)端口。</p><p>　　貫穿安全業(yè)的一個(gè)普遍問題是應(yīng)用軟件安全，特別是定制的Web應(yīng)用程序。隨著Web應(yīng)用程序的功能變得越來越復(fù)雜，它帶來了應(yīng)用程序編碼方面的安全漏洞的更大的潛在威脅。為了滿足應(yīng)用軟件的功能性要求，后端數(shù)據(jù)存儲(chǔ)通常被用來安排網(wǎng)頁(yè)

11、內(nèi)容的格式。這就需要更復(fù)雜的后端數(shù)據(jù)編碼。開發(fā)者使用不同風(fēng)格的代碼開發(fā)，其中一部分沒有安全意識(shí)，這也許是開發(fā)錯(cuò)誤的源頭。</p><p>　　SQL注入就是當(dāng)前IT安全業(yè)的一個(gè)熱門話題。隨著愈來愈多的以期縮短時(shí)間的開發(fā)數(shù)據(jù)庫(kù)的方式和手段的出現(xiàn)，目前在技術(shù)安全論壇中，爭(zhēng)論是很平常的。SQL注入是一個(gè)容易讓人誤導(dǎo)的術(shù)語，因?yàn)樵摳拍钜策m用于其他的數(shù)據(jù)庫(kù)，包括Oracle，DB2和Sybase系統(tǒng)。</p>

12、<p>　　◆ 什么是SQL注入？</p><p>　　SQL注入的是軟件開發(fā)人員所不希望出現(xiàn)的與資料庫(kù)使用代碼或指令發(fā)送手段的交流方法。這是發(fā)現(xiàn)在Web應(yīng)用軟件最常見的形式。任何用戶輸入應(yīng)用軟件所不允許的內(nèi)容是攻擊的一個(gè)常見來源。</p><p>　　在座很多朋友已經(jīng)看到了當(dāng)訪問網(wǎng)站時(shí)通常的錯(cuò)誤消息框，而且往往顯示用戶輸入沒有得到正確處理。一旦出現(xiàn)這種類型的錯(cuò)誤，攻擊者將把焦

13、點(diǎn)放在更具體的輸入字符串上。具體的與安全有關(guān)的編碼技術(shù)在使用組織時(shí)應(yīng)加入編碼標(biāo)準(zhǔn)。 由于這種類型的脆弱性所造成的損害，可以很深刻的，盡管這會(huì)取決于該應(yīng)用軟件與數(shù)據(jù)庫(kù)關(guān)聯(lián)的特權(quán)級(jí)別。如果該軟件以管理者類型權(quán)限訪問數(shù)據(jù)，然后惡意運(yùn)行命令也會(huì)是這一級(jí)別的訪問權(quán)限，此時(shí)系統(tǒng)妥協(xié)是不可避免的。還有這個(gè)問題類似于操作系統(tǒng)的安全規(guī)則，在那里，項(xiàng)目應(yīng)該以最低的權(quán)限運(yùn)行，而且這是必要的。如果是正常的用戶訪問，然后啟用這個(gè)限制。</p>&

14、lt;p>　　同樣的問題，SQL的安全也不完全是一個(gè)數(shù)據(jù)庫(kù)的問題。特定的數(shù)據(jù)庫(kù)命令或要求，不應(yīng)該允許通過應(yīng)用層。這是可以通過"安全碼"的方式加以預(yù)防的。這是一個(gè)場(chǎng)外話題，但應(yīng)該被應(yīng)用的一些基本步驟的詳細(xì)設(shè)計(jì)是有必要的。</p><p>　　第一步，在獲取任何申請(qǐng)時(shí)須驗(yàn)證和控制用戶輸入?？赡艿那闆r下，嚴(yán)格的類型應(yīng)被設(shè)定以控制具體數(shù)據(jù)（例如，期望得到數(shù)值數(shù)據(jù)，字符串類型數(shù)據(jù)等），并在可能實(shí)現(xiàn)

15、的情況下，如果數(shù)據(jù)是以字符型為基礎(chǔ)的，需要禁止特定的非字母數(shù)字字符。如果這是不能實(shí)現(xiàn)的，應(yīng)該做出爭(zhēng)取使用替代字符的考慮（例如，使用單引號(hào)，這在 SQL命令中時(shí)通常被使用的）。</p><p>　　在使用您的組織時(shí)具體的與安全有關(guān)的編碼技術(shù)應(yīng)加入編碼標(biāo)準(zhǔn)。如果所有開發(fā)商都使用相同的基線標(biāo)準(zhǔn)，特定具體的安全措施，這將大大減少SQL注入妥協(xié)的風(fēng)險(xiǎn)。</p><p>　　能夠使用的另一種簡(jiǎn)單的方法

16、，是清除數(shù)據(jù)庫(kù)中不再需要的所有程序。這些限制了數(shù)據(jù)庫(kù)中不再需要的或者多于過剩的被惡意利用的程度。這類似于消除操作系統(tǒng)內(nèi)不需要的服務(wù)程序，是一種常見的安全實(shí)踐。</p><p><b>　　◆ 總結(jié)</b></p><p>　　總之，我已做出的以上的大多數(shù)觀點(diǎn)是安全概念的一般意識(shí)，并沒有具體到某個(gè)數(shù)據(jù)庫(kù)。然而，所有這些確實(shí)應(yīng)用于數(shù)據(jù)庫(kù)，而且如果這些基本的安全措施被應(yīng)用，

17、你的數(shù)據(jù)庫(kù)安全屬性將大大改善。在下一篇關(guān)于數(shù)據(jù)庫(kù)的安全的文章中，將側(cè)重于具體的SQL和Oracle安全問題，有為DBAs和開發(fā)商提供的詳細(xì)例子和意見。</p><p><b>　　PART 2</b></p><p>　　這是第二篇文章，審查了數(shù)據(jù)庫(kù)的安全。在上篇文章我們討論了一般數(shù)據(jù)庫(kù)安全概念和共同面臨的問題。在這篇文章我們將集中于特定的Microsoft SQL和

18、Oracle的安全問題，同樣重要的是緩解這些問題的解決方案。</p><p>　　數(shù)據(jù)庫(kù)安全與一般IT安全問題有許多相似之處，都有一些簡(jiǎn)單的安全措施和步驟，容易實(shí)施，從而大大提高安全性。雖然這些看起來像普通常識(shí)，但是令人驚訝的是，我們都看到有多少次，常見的安全措施沒有落實(shí)以至于造成的安全風(fēng)險(xiǎn)。</p><p>　　◆ 用戶賬戶和密碼安全</p><p>　　在IT安

19、全方面的一個(gè)首要基本規(guī)則，便是“確保你有一個(gè)可靠的密碼”。在此聲明，我已假定首先一個(gè)密碼已被設(shè)定，雖然這種情況往往并非如此。在去年的文章中，我略微談到了關(guān)于一般安全意識(shí)的問題，但我認(rèn)為再次強(qiáng)調(diào)這個(gè)問題是有必要的，而且至關(guān)重要。就像操作系統(tǒng)，人們關(guān)注的焦點(diǎn)是內(nèi)部數(shù)據(jù)庫(kù)的賬號(hào)安全，其目的在于管理賬戶。在SQL內(nèi)，這將成為SA賬號(hào)，在Oracle內(nèi)，這可以是SYSDBA或者是Oracle賬戶。</p><p>　　SQ

20、L SA服務(wù)賬戶將“SA”作為密碼，這是很常見的，或者更糟糕的是一個(gè)空白密碼，這同樣很普遍。這類密碼連最基本的安全規(guī)則都懶于限制。用戶在自己的域賬戶上將不允許有一個(gè)空白密碼，所以為什么寶貴的系統(tǒng)資源，例如數(shù)據(jù)庫(kù)容許被毫無保障。舉例來說，一個(gè)空白的“SA”密碼，使含有客戶端軟件任何用戶（如微軟的查詢分析器或企業(yè)經(jīng)理人去“管理”SQL Server和數(shù)據(jù)庫(kù)）。</p><p>　　數(shù)據(jù)庫(kù)被用來作為Web應(yīng)用軟件的后端

21、，缺乏密碼控制，將導(dǎo)致敏感資料的全盤妥協(xié)。隨著系統(tǒng)級(jí)訪問數(shù)據(jù)庫(kù)，使得不僅要執(zhí)行查詢到數(shù)據(jù)庫(kù)，創(chuàng)建/修改/刪除表等，而且也要執(zhí)行被稱為存儲(chǔ)程序的內(nèi)容。</p><p>　　摘自：保羅·莫里森. 數(shù)據(jù)庫(kù)安全. 薩姆斯出版社出版，2002</p><p><b>　　附:英文原文</b></p><p>　　Database Securit

22、y</p><p>　　Paul Morrison</p><p><b>　　America</b></p><p><b>　　PART 1</b></p><p>　　“Why do I need to secure my database server? No one can access

23、it — it’s 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 orga

24、nizations information, as it may be indirectly exposed to a wider audience than realized.</p><p>　　This is the first of two articles that will examine database security. In this article we will discuss gener

25、al database security concepts and common problems. In the next article we will focus on specific Microsoft SQL and Oracle security concerns.</p><p>　　Database security has become a hot topic in recent t

26、imes. 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

27、large number of insecure networks out there). As such, the focus is expanding to consider technologies such as databases with a more critical eye.</p><p>　　◆ Common sense security</p><p>　　Befor

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

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

30、loyed when installing various operating systems.</p><p>　　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) faci

31、ng 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 t

32、o the Internet. One recent example I can recall is an Apache Web server serving an organizations Internet offering, with an Oracle </p><p>　　The points mentioned above are not strictly database issues, and c

33、ould 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 can

34、not rely on someone or something else within your organization protecting your database from exposure.</p><p>　　◆ Attack tools are now available for exploiting weaknesses in SQL and Oracle</p><p&g

35、t;　　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) t

36、o 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 itsel

37、f seemed to be handling input requests, rejecting all attempts </p><p>　　There is a simple solution to the problem identified above. SQL 2000 can be configured to use password protection for backups. If t

38、he 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 th

39、e password must be remembered!</p><p>　　◆ Current trends</p><p>　　There are a number of current trends in IT security, with a number of these being linked to database security.</p><

40、p>　　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 an

41、d we have seen focused attacks against specific data- base ports on servers exposed to the Internet.</p><p>　　One common theme running through the security industry is the focus on application security,

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

43、 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 d</p><p>　　SQL injectio

44、n 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 ti

45、me. SQL injection is a misleading term, as the concept applies to other databases, including Oracle, DB2 and Sybase.</p><p>　　◆ What is SQL Injection?</p><p>　　SQL Injection is simply the method

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

47、pplication is a common source of attack. One simple example of mishandling of user input is highlighted in Figure 1.</p><p>　　Many of you will have seen this common error message when accessing web sites, an

48、d 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.</p><p>　　Specific security-related coding tec

49、hniques 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 relatio

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

51、 is analogous to operati</p><p>　　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 </p><p>　　ap

52、plication layer. This can be prevented by employing a “secure coding” approach.</p><p>　　Again this is veering off-topic, but it is worth detailing a few basic steps that should be employed.</p><p

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

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

55、single quotes, which are commonly used in SQL commands).</p><p>　　Specific security-related coding techniques should be added to coding standard in use within your organization. If all developers are using t

56、he same baseline standards, with specific security measures, this will reduce the risk of SQL injection compromises.</p><p>　　Another simple method that can be employed is to remove all procedures within th

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

58、 common security practice.</p><p><b>　　◆ Overall</b></p><p>　　In conclusion, most of the points I have made above are common sense security concepts, and are not specific to databas

59、es. 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.</p><p><b>　　PART 2</b></p>

60、<p>　　The next article ondatabase security will focus on specific SQL and Oracle security problems, with detailed examples and advice for DBA and developers.</p><p>　　There are a lot of similarities b

61、etween 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, i

62、t is surprising how many times we have seen that common security measures are not implemented and so cause a security exposure. </p><p>　　◆User account and password security</p><p>　　One of the

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

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

65、ll be the SA account and within Oracle it may be </p><p>　　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 bre

66、aks 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 allowe

67、d to be left unprotected. For instance, a blank ‘SA’ password will enable any user with client software (i.e. Microsoft query analys</p><p>　　With databases being used as the back end to Web applications, th

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