兩位一體：專家論應用安全和數據庫安全
應用安全和數據庫的安全就像是拼圖中的拼圖塊，它們雖然不同，卻彼此之間需要對方，缺少任何一個，都不能形成一個安全整體。如果其中一方出現安全隱患就會令整個安全防御徹底失效，如WEB應用程序存在SQL注入的時候，就會對整個系統和數據庫產生更大的影響。為了減小攻擊范圍，開發人員和數據庫管理員必須明晰他們在這個過程中的角色，共同工作，以避免WEB應用暴露任何敏感數據庫。
如今，許多行業用戶將大量有價值的客戶數據存儲于在線數據庫，通過網絡應用與外界交互。不論是通信、金融、電子政務、電子商務抑或是小小的個人博客，前端應用程序和后臺數據庫都不可避免地結合在我們現在的模型中，任何一個都不可離開另一個而單獨存在。
但是由于那些應用程序在設計時是允許任何人、從任何地方登陸進入訪問，因而也成為了通往隱藏在深處的重要數據的橋梁。比如在去年十二月，國內最大的程序員社區網站CSDN就遭到了黑客從WEB應用層的攻擊，使得包含用戶密碼的數據庫泄密。
那么如何才能使這個模型更安全呢？安恒信息專家將為您做詳細的解讀：使模型更安全的解決方法是讓應用程序作為人與數據互動的唯一接口，應用程序界面是機器與數據互動的唯一接口。如果不是這樣，那么數據交互就有可能不能被充分控制好，這將會是一個非常基本的潛在漏洞。即使訪問方式定義明確，實際上應用程序依然有無數種方式令防護數據庫失敗，最終導致整個系統被黑客竊取或破壞。
安恒信息專家表示，安全管理人員和開發人員經常忽視或者錯誤地理解數據庫，常僅僅關注于保護網絡應用程序不受風險的威脅--比如說跨站腳本攻擊或者注入攻擊，而忘記了留意數據庫本身的安全隱患。很明顯，用戶需要有專門的工具和策略來幫助網絡應用程序開發人員保護后臺數據庫的安全性，而數據庫開發人員必須確保他們的網絡接口盡可能地安全。
同時安恒信息專家還指出，現在大多數用戶都是憑感覺在運行數據庫安全。絕大多數用戶根本沒有監控他們的數據庫。更令人不安的是，大多數用戶甚至不知道他們的重要數據的位置，很多管理員在調查中承認他們并不能肯定數據庫中包含著重要信息。
在多數情況下，關鍵點在于網絡應用程序本身對于攻擊者而言沒什么價值，他們只是利用應用程序作為竊取或破壞數據的一種手段，第一個防范措施便是確保不僅僅是數據庫管理員了解重要數據在哪里存放、如何訪問到，以及面臨的實際威脅。我們通常將數據庫看作是一個黑盒子，只向需要的人和應用程序提供訪問的方法，當選取、更新或者插入操作成功后，人們會忘記還有一些事情會發生，所以說團隊合作是關鍵，必須要把應用安全和數據安全做到兩位一體。
我們所面臨的網絡威脅
數據庫除了有與生俱來的安全隱患以外，當應用程序訪問數據庫時，還要考慮到更多的威脅。數據庫打補丁、權限管理和連接管理都是典型的數據庫安全防范措施，常見的由網絡應用程序引發的安全威脅有SQL注入式攻擊，XSS跨站攻擊、不安全的會話處理和權限升級、目錄遍歷漏洞和敏感信息泄露等漏洞。我們會深入挖掘每一種模型，但是考慮到這些風險的存在，我們最重要的是盡可能少的給予特權，通過監控輸入數據和建立安全連接來加強讀取方式的安全性，同時還要限制數據庫服務器對外暴露的機率。SQL注入、跨站腳本漏洞、目錄遍歷漏洞、敏感信息泄露等漏洞
我們需要共同協作
安全問題不是某個個人的職責，關鍵需要團隊的協作。這對于應用程序的安全問題來說更是如此，信息安全人員、開發人員、系統和數據庫管理員都包括在內，這就是團隊協作。除非你所在的單位已經擁有了一個成熟的安全環境，而且已經使用安全類庫來處理數據庫調用和數據驗證，在數據庫和應用程序之間有一層數據訪問層，并確保所有的數據庫權限都受到了嚴格的限制，在這種情況下應當讓所有團隊成員參與并且了解高層次的應用程序。通過共同協作，所有人都可以了解到這些安全威脅，隨后可以共同想出更好的解決方案來應對。所有參與網絡應用和數據庫開發維護管理的人員都應該對目前存在的安全威脅有一個充分的認識和理解，這是非常重要的。我們必須要確保所有人員都理解應用程序的所有技術通信原理和數據流，了解數據從哪里來，如何到那里去的，以及數據是否和多個應用程序進行通信。這就是關于數據庫保護的第一層措施。
數據庫保護的第二層措施是安全架構。安全設計的基礎有時候也被稱作為安全架構，也就是說當我們以安全的方式設計數據庫環境時，應減少安全威脅。如果攻擊者無法直接訪問數據庫，這樣就降低了他們攻擊的靈活性。我們為攻擊者提供的活動空間越大，他們就越容易得手。同樣的，從相反的角度來看，我們就需要在后續做更多的工作，也就是說你必須確保對數據庫的訪問僅限于在需要的情況下進行系統訪問，而且所有的訪問都經過認證和加密的，而且不能影響到會話池。保證網絡和系統設計的安全將會對保護數據庫大有幫助，添加了數據庫訪問路徑的限制能夠大大地降低風險。
數據庫保護的第三層措施是威脅建模。確定威脅的過程被稱為是威脅建模，過去威脅建模是用在應用程序安全方面，用于確定應用程序的最高風險，這樣安全人員就可以重點關注在這一領域。這個概念開始延用到安全的其它領域中。應注意的是這不是一個新的理念，實際上保險行業已經采用此理念有數百年的歷史了，我們互聯網行業只是最近幾年才吸納這一理念，并開始就此主題發表了許多文章。
威脅建模包括將那些了解此應用程序的人以及相關領域的專家召集在一起，大家共同理解應用程序的不同部分、功能性和固有的威脅。花一定的時間來全面理解此應用程序以及相關的威脅，可以定制出相對應的保護和測試方案，可以節省時間或者在有限的時間和預算范圍內最大程度地降低威脅。威脅建模對于安全人員來說可以提供一種很好的手段來掌握全局、分解風險區域并與各小組單獨協作，確保保護措施落到實處。
在對多個應用程序或開發項目進行威脅建模時，應作好記錄，找到應用程序的共通性。這些共通性可以用于審查內部數據庫訪問標準、授權訪問以及優化訪問過程。
在編寫策略時應當涵蓋常見情況，并且明確地為開發人員和數據庫管理人員提供指導，確保人人手中都有一份參考資料。一旦這些步驟執行到位后，可以開始從基礎做起向數據庫環境添加安全措施。
雖然各個系統環境都不相同，但是數據庫配置對于保護數據是最為重要的部分之一，應當實現的常見配置有：
我們需要保護重要的數據
“一定要保護好數據庫的重要數據”，因為數據庫對于IT行業來說就好像是保管金銀珠寶的保險庫。如果保險庫不安全，財寶就很容易失竊，那主人就不會開心。
保護數據庫服務器的方式有網絡分段、系統分離，并將數據庫服務器放置在一層或多層保護網的后面。
有許多新的技術，包括數據庫活動監控軟件、數據丟失防護（DLP）、將數據庫分割，放到依據數據分類或風險模型的系統中，還有確保低安全性的應用程序無法訪問到高安全程度的數據庫等。
根據訪問權限和賬號，如果有多個部門的用戶因同一事件需要登陸進入同一應用程序,應該采取保護措施，以確保一個部門的人員無法訪問另一個部門的數據。這可以在數據庫層面上完成,方法是讓各個部門分別創建各自的數據庫或桌面；這樣的話可以實現數據分離，而且可以使用不同的數據庫賬號來加以保護。應用程序可以使用單一賬號用于非認證請求服務，比如說用戶登錄；一旦發生此類情況，應用程序可以將數據庫賬號切換至同用戶部門相關聯的另一個賬號。在設定許可權限時要防止通用賬戶訪問任何公司數據。
除此之外，部門A的數據庫賬號不能訪問部門B的數據。這樣就阻止了攻擊者越過公司的安全防線并擴大其接觸范圍。在進行應用程序數據庫賬號轉換時必須非常小心，因為攻擊者可能通過SQL注入攻擊來迫使應用程序改變其連接。在某些單位，開發人員會寫下他們自己的SQL查詢命令，而對于其它一些單位，查詢命令是由數據庫管理員來編寫和優化，然后再提供給開發者。
在最安全的環境下，這些查詢命令由數據庫管理員編寫和執行，作為存儲過程。存儲過程是由應用程序執行的預定義語句。這樣就使得SQL注入攻擊更加難于得到利用。在這種特殊情況下，如果沒有存儲過程的話，攻擊者可能已經作為管理員登錄進入此應用程序并且取得此數據庫完全控制權，而且只需要得到管理員用戶名稱即可實現。
同時還需要建立敏感數據的安全邊界。通過采取相應的技術措施，為用戶的各種數據庫建立一個關于數據的安全邊界。我們可以將數據庫服務器置于標準的網絡防火墻后面，并限制訪問，以確保我們了解什么系統能夠訪問你的數據庫，從而降低風險。但是千萬不要以為簡單的配備一些防火墻就可以防范這些安全威脅，可能還會有其他我們未發現的未知風險存在！
安全人員在開發新的安全數據安全模型時，安全人員應該進行測試，以確保他們提供了需要的保護級別，并且沒有引入新風險。最后關于實現數據基于策略的自動管理問題，它包括數據的分類、備份、遷移、刪除等，實現全面的數據存儲管理自動化，這樣不但減少了人為出錯的可能性，也提高了數據庫的安全性和可用性。使用一套優質的解決方案按照標準的規范進行設計和部署，提供充分的靈活性、擴展性和安全性，滿足數據庫安全保管方面當前和今后的法規要求。
回到源頭，WEB安全刻不容緩
最小權限原則、保護數據庫連接、分段服務器和網絡、安全驗證、安全邊界和數據庫安全配置對保護數據很有用處，但是這些不會解決攻擊者所有的攻擊企圖。從廣義上講，數據庫的安全首先依賴于網絡系統。網絡系統的安全是數據庫安全的第一道屏障，外部入侵首先就是從入侵網絡系統開始的。所以現在需要關注最普遍存在的威脅；WEB應用安全。
由于某些開發人員犯了非常低級的編程錯誤，比如：應用ID只能被應用使用，而不能被單獨的用戶或是其它進程使用。但是開發人員不這么做，他們給予了應用程序更多的數據訪問權限。這就類似于醫生因沒有洗手而傳播了傳染病，從而導致各種漏洞的出現。
我們必須接受已經存在的應用缺陷和漏洞。通過發揮數據庫管理員的安全職責去阻止因為應用缺陷和漏洞所造成的不良后果。比如如果開發人員不重視應用與數據交互的安全性，堅持最小權限原則，數據庫管理員則有權在這場互動中占取主動，不給開發人員全權委托，數據庫管理員可以不允許那么多的交互被授權；為了阻止黑客的滲透攻擊從不可避免的網絡程序應用漏洞中占便宜，數據庫管理員也有權進行其他有效的安全控制。并且數據庫管理員應對數據庫進行加密保護，如密碼不能使用明文保存；對所有應用層和數據層通信的審計監控將有助于快速識別和解決問題以及準確地判斷任何安全事件的范圍，直到實現安全風險最小化的目標。
假如出現數據外泄事件（如2011年年底的CSDN等網站的用戶數據信息泄密事件），責任也不止是在數據庫管理員身上，開發人員也需要共同承擔責任。其中一個非常重要的方面，開發人員能做的就是在用戶能輸入的地方最好過濾危險字符，這樣可以防止黑客通過諸如SQL注入攻擊獲取到數據庫的敏感信息。目前在各類行業網站上，各種WEB應用漏洞隨處可見，可以被黑客們檢測到（他們一般會用軟件同時掃描數千個網站）。
開發人員在完成一套新的應用程序后應使用安全檢測工具對其進行反復白盒測試，有條件的情況下可以請信息安全人員模擬黑客進行黑盒滲透測試，盡可能的發現應用程序的弱點并進行修補。如果想實現更完整的解決方案，更多有關的保護數據和數據庫是應當實施源代碼分析。這是一項冗長的處理過程，可以請安全服務提供商用專業的源碼審計軟件對應用程序代碼進行詳細的分析處理，這些工具會直接查找出更精確的缺陷結果。
同時應該與開發商或者安全廠商合作并確保能提供安全解決方案，這對于任何致力于部署網絡應用數據庫正常安全訪問的用戶都至關重要，WEB應用安全測試對于確保數據庫的安全性有至關重要的作用。
一款好的工具可以有助于加快進度并且提供更好的檢測結果和解決方案，以提供應用程序更好的的安全性，關鍵是進行反復評估以確保管理工作正常，對結果實施驗證并加固，確保風險一經發現立即補救，并保證管理人員能夠了解到相關問題的存在。
最后我們談談新的防火墻問題。到目前為止，我們都是側重于預防措施。但在現實世界中，我們不可能總是改編程序和環境，所以我們必須采用其他技術措施。這就是為什么會產生新的防火墻。
防火墻用于應用程序或者監控流量的運行監控，也可以在執行運行時進行分析。防火墻可以找出攻擊，并阻止嘗試或修改的要求，來確保WEB服務器和數據庫服務器的安全運行。
目前不光有WEB應用防火墻和網絡防火墻能防范攻擊者透過應用層和網絡層的攻擊；“數據庫防火墻”也于這兩年在不斷的數據庫泄密事件中出現在公眾的視線里，國內稱之為“數據庫審計”產品，這些產品能給數據庫提供實時的網絡存儲與訪問的安全。
任何一個好的數據庫安全策略都應包括監控和審計，以確保保護對象正常運行，并且運行在正確的位置上，這也是個非常耗時的過程。由于缺乏時間和工具，大多數用戶對于數據庫配置的檢查往往也僅是抽查而已。
這里還需要指出的是目前多數人認為“數據庫審計”等同于數據庫安全，事實上，數據庫安全遠遠不是數據庫審計可以搞定的，數據庫審計只是數據庫安全的一個很小的方面，之所以有時候對等起來，一方面是由于市場宣傳導致的誤導，另一方面的確是這個部分的問題比較容易產品化/工具化，技術實現相對比較成熟。數據庫安全應該包括：數據庫資產管理、數據庫配置加固、職責分離、特權用戶控制、數據庫弱點掃描和補丁管理、數據庫加密、數據庫審計。
最后，我們還是回到應用程序的安全以及與數據庫之間的相互作用問題上。即我們必須要考慮到的問題是應用程序的安全以及與數據庫之間的相互作用，尤其是對于當今流行的高度動態的和互動的網絡應用程序而言。理解數據庫與應用程序和系統環境之間的作用可以更加提升數據的安全性。
有問題是客觀情況，其實我們需要的不是過多的責難，而是不斷改進問題本身，當我們被迫把安全做的簡單時，我們就被迫直接面對真正的問題。當我們不能用表面的裝飾交差時，我們就不得不做好真正的本質部分。希望本文可以讓讀者了解到一系列管理和風險降低方面的策略，不論你是否愿意配置數據庫防火墻、進行源代碼審記或者嚴格地控制數據庫管理系統，其目的都是相同的：做好應用安全和數據安全的兩位一體，保護好重要數據。
【編輯推薦】
