企業(yè)必須對數(shù)據(jù)庫進行評估來確定某些功能是否真的必要，以及禁用那些不需要的功能來減少攻擊面。此外，企業(yè)必須對默認設置或者較弱的登錄憑證時刻保持警惕，必須部署完善的特權和身份驗證措施，最重要的是，企業(yè)需要定期修復補丁。

在所發(fā)現(xiàn)的漏洞中，有將近一半的漏洞或直接或間接地與數(shù)據(jù)庫環(huán)境內不適當?shù)难a丁修復管理有關。這是很恐怖的概念：在前三個月補丁修復周期內，只有38%的管理員修復企業(yè)的Oracle數(shù)據(jù)庫，并且只有三分之一的管理員花費一年或者更長時間進行修復。

1. 默認、空白和強度弱的用戶名或者密碼

在一個企業(yè)中，跟蹤數(shù)百或者甚至數(shù)千個數(shù)據(jù)庫可能是很艱巨的任務，但是刪除默認、空白以及強度弱的登錄憑證將是完善數(shù)據(jù)庫安全非常重要的第一個步驟。攻擊者們總是將注意力放在這些默認帳戶上，必要的時候就能派上用場。

2. SQL注入攻擊

SQL注入攻擊是黑客對數(shù)據(jù)庫進行攻擊的常用手段之一。隨著B/S模式應用開發(fā)的發(fā)展，使用這種模式編寫應用程序的程序員也越來越多，但是由于程序員的水平及經驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數(shù)據(jù)的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段數(shù)據(jù)庫查詢代碼，根據(jù)程序返回的結果，獲得某些他想得知的數(shù)據(jù)，這就是所謂的SQL Injection，即SQL注入。

如果企業(yè)數(shù)據(jù)庫平臺無法對輸入內容進行審查，攻擊者將能夠執(zhí)行SQL注入攻擊，就像在web攻擊中所做的那樣，SQL注入攻擊最終將允許攻擊者提升權限，并且獲取對更廣泛功能的訪問權限。很多供應商發(fā)布了修復程序來避免這些問題，但是如果DBMS仍然未打補丁，這些修復程序也幫不了企業(yè)管理者。

3.廣泛的用戶和組特權

企業(yè)必須確保沒有將特權給那些不必要的用戶。安全專家建議，只有將用戶設置為組或者角色的一部分，然后通過這些角色來管理權限，這樣將比向用戶分配直接權利要更加易于管理。

4.啟用不必要的數(shù)據(jù)庫功能

每個數(shù)據(jù)庫安裝都會附帶各種類型各種大小的功能，并且大部分都不會被企業(yè)所使用。數(shù)據(jù)庫安全意味著減少攻擊面，企業(yè)需要審查這些數(shù)據(jù)庫功能，找出不必要或者不使用的功能，然后禁用或者卸載它們。這不僅能夠降低通過這些載體發(fā)動的零日攻擊的風險，而且能夠簡化補丁修復管理，因為這些不必要的功能也需要進行補丁修復。

5.糟糕的配置管理

同樣地，數(shù)據(jù)庫有很多不同的配置可供選擇，正確合適的配置將能夠幫助數(shù)據(jù)庫管理員提高數(shù)據(jù)庫性能和加強數(shù)據(jù)庫功能。企業(yè)需要找出不安全的配置(默認情況下為啟用狀態(tài)或者為了方便數(shù)據(jù)庫管理員或者應用程序開發(fā)人員而開啟的)，然后重新進行配置。

6.緩沖區(qū)溢出

另一個攻擊者喜歡的漏洞就是緩沖區(qū)溢出漏洞，這個漏洞是這樣被利用的，即大量輸入比應用程序預期更多的字符，例如向請求SSN的輸入框增加100個字符。數(shù)據(jù)庫供應商都在積極努力地修復這個漏洞，以避免發(fā)生這樣的攻擊，這也是為什么補丁修復如此重要的另一個原因。

7. 特權升級

同樣的，數(shù)據(jù)庫常常出現(xiàn)這樣的漏洞，允許攻擊者對鮮為人知或者低權限帳號進行權限升級，然后獲取管理員權限。例如，攻擊者可能誤用sysdba下運行的一個函數(shù)。由于這些漏洞還沒有被發(fā)現(xiàn)，管理員需要即使更新和修復補丁來防止這種漏洞被利用。

8.拒絕服務攻擊

拒絕服務攻擊即攻擊者想辦法讓目標機器停止提供服務，是黑客常用的攻擊手段之。其實對網(wǎng)絡帶寬進行的消耗性攻擊只是拒絕服務攻擊的一小部分，只要能夠對目標造成麻煩，使某些服務被暫停甚至主機死機，都屬于拒絕服務攻擊。拒絕服務攻擊問題也一直得不到合理的解決，究其原因是因為這是由于網(wǎng)絡協(xié)議本身的安全缺陷造成的，從而拒絕服務攻擊也成為了攻擊者的終極手法。攻擊者進行拒絕服務攻擊，實際上讓服務器實現(xiàn)兩種效果：一是迫使服務器的緩沖區(qū)滿，不接收新的請求;二是使用IP欺騙，迫使服務器把合法用戶的連接復位，影響合法用戶的連接

SQL Slammer是關于攻擊者如何利用DBMS漏洞來通過大量流量攻破數(shù)據(jù)庫服務器的非常具有啟發(fā)意義的例子，而更具啟發(fā)性的是，當在2003年Slammer淪陷后，已經出現(xiàn)了解決這個漏洞的補丁修復程序，然而，即使在七年后的今天，SQL Slammer仍然在作惡多端，攻擊那些未修復的服務器。

9.未修復數(shù)據(jù)庫與未加密重要數(shù)據(jù)(靜態(tài)或者動態(tài)狀態(tài))

這一點可能與上述漏洞有些重復，但是這值得再次重復。很多數(shù)據(jù)庫管理員并沒有及時修復補丁，因為他們害怕補丁修復程序將會破壞他們的數(shù)據(jù)庫。但是現(xiàn)在，被攻擊的風險比安裝可能會破壞數(shù)據(jù)庫的補丁要高得多，而這在五年前可能并不是這樣，但是供應商現(xiàn)在已經更加嚴格的進行測試