兩位一體：論信息化中的應用安全和數據庫安全

2013-12-20 10:56:17 電力信息化　點擊量：評論 (0)

　　應用安全和數據庫的安全就像是拼圖中的拼圖塊，它們雖然不同，卻彼此之間需要對方，缺少任何一個，都不能形成一個安全整體。如果其中一方出現安全隱患就會令整個安全防御徹底失效，如WEB應用程序存在SQL注入

　　應用安全和數據庫的安全就像是拼圖中的拼圖塊，它們雖然不同，卻彼此之間需要對方，缺少任何一個，都不能形成一個安全整體。如果其中一方出現安全隱患就會令整個安全防御徹底失效，如WEB應用程序存在SQL注入的時候，就會對整個系統和數據庫產生更大的影響。為了減小攻擊范圍，開發人員和數據庫管理員必須明晰他們在這個過程中的角色，共同工作，以避免WEB應用暴露任何敏感數據庫。

　　如今，許多行業用戶將大量有價值的客戶數據存儲于在線數據庫，通過網絡應用與外界交互。不論是通信、金融、電子政務、電子商務抑或是小小的個人博客，前端應用程序和后臺數據庫都不可避免地結合在我們現在的模型中，任何一個都不可離開另一個而單獨存在。

　　但是由于那些應用程序在設計時是允許任何人、從任何地方登陸進入訪問，因而也成為了通往隱藏在深處的重要數據的橋梁。比如在去年十二月，國內最大的程序員社區網站CSDN就遭到了黑客從WEB應用層的攻擊，使得包含用戶密碼的數據庫泄密。

　　那么如何才能使這個模型更安全呢?安恒信息專家將為您做詳細的解讀：使模型更安全的解決方法是讓應用程序作為人與數據互動的唯一接口，應用程序界面是機器與數據互動的唯一接口。如果不是這樣，那么數據交互就有可能不能被充分控制好，這將會是一個非常基本的潛在漏洞。即使訪問方式定義明確，實際上應用程序依然有無數種方式令防護數據庫失敗，最終導致整個系統被黑客竊取或破壞。

　　安恒信息專家表示，安全管理人員和開發人員經常忽視或者錯誤地理解數據庫，常僅僅關注于保護網絡應用程序不受風險的威脅--比如說跨站腳本攻擊或者注入攻擊，而忘記了留意數據庫本身的安全隱患。很明顯，用戶需要有專門的工具和策略來幫助網絡應用程序開發人員保護后臺數據庫的安全性，而數據庫開發人員必須確保他們的網絡接口盡可能地安全。

　　同時安恒信息專家還指出，現在大多數用戶都是憑感覺在運行數據庫安全。絕大多數用戶根本沒有監控他們的數據庫。更令人不安的是，大多數用戶甚至不知道他們的重要數據的位置，很多管理員在調查中承認他們并不能肯定數據庫中包含著重要信息。

　　在多數情況下，關鍵點在于網絡應用程序本身對于攻擊者而言沒什么價值，他們只是利用應用程序作為竊取或破壞數據的一種手段，第一個防范措施便是確保不僅僅是數據庫管理員了解重要數據在哪里存放、如何訪問到，以及面臨的實際威脅。我們通常將數據庫看作是一個黑盒子，只向需要的人和應用程序提供訪問的方法，當選取、更新或者插入操作成功后，人們會忘記還有一些事情會發生，所以說團隊合作是關鍵，必須要把應用安全和數據安全做到兩位一體。

我們所面臨的網絡威脅
　　數據庫除了有與生俱來的安全隱患以外，當應用程序訪問數據庫時，還要考慮到更多的威脅。數據庫打補丁、權限管理和連接管理都是典型的數據庫安全防范措施，常見的由網絡應用程序引發的安全威脅有SQL注入式攻擊，XSS跨站攻擊、不安全的會話處理和權限升級、目錄遍歷漏洞和敏感信息泄露等漏洞。我們會深入挖掘每一種模型，但是考慮到這些風險的存在，我們最重要的是盡可能少的給予特權，通過監控輸入數據和建立安全連接來加強讀取方式的安全性，同時還要限制數據庫服務器對外暴露的機率。SQL注入、跨站腳本漏洞、目錄遍歷漏洞、敏感信息泄露等漏洞

　　SQL注入攻擊SQL注入漏洞的產生原因是網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，導致應用程序存在安全隱患。SQL注入漏洞攻擊的就是利用現有應用程序沒有對用戶輸入數據的合法性進行判斷，將惡意的SQL命令注入到后臺數據庫引擎執行的黑客攻擊手段。

　　XSS跨站攻擊跨站腳本攻擊簡稱為XSS又叫CSS 是指服務器端的CGI程序沒有對用戶提交的變量中的HTML代碼進行有效的過濾或轉換，允許攻擊者往WEB頁面里插入對終端用戶造成影響或損失的HTML代碼。

　　未驗證輸入web請求信息在被Web應用使用之前都是未驗證的，攻擊者能夠利用其中的弱點攻擊服務器;攻擊者通過偽造HTTP請求的各個部分，例如URL，查詢字符串，頭，cookies，表單域，隱藏域等繞過站點的安全機制。這些常見的偽造輸入攻擊通常包括：強制瀏覽，命令插入，跨站腳本，緩沖區溢出，格式化字符串，SQL注入，cookie中毒，隱藏域操作等等。
網絡釣魚網絡釣魚是通過大量發送聲稱來自于銀行或其他知名機構的欺騙性垃圾郵件，意圖引誘收信人給出敏感信息(如用戶名、口令、帳號 ID 、 ATM PIN 碼或信用卡詳細信息)的一種攻擊方式。最典型的網絡釣魚攻擊將收信人引誘到一個通過精心設計與目標組織的網站非常相似的釣魚網站上，并獲取收信人在此網站上輸入的個人敏感信息，通常這個攻擊過程不會讓受害者警覺。這些個人信息對黑客們具有非常大的吸引力，因為這些信息使得他們可以假冒受害者進行欺詐性金融交易，從而獲得經濟利益。受害者經常遭受顯著的經濟損失或全部個人信息被竊取并用于犯罪的目的。
通過應用程序造成隱私泄漏個人或團體的信息被其他不應獲得者獲取。如攻擊者通過入侵大型網絡社區、交友網站、免費郵箱等網絡應用程序獲取數據庫用戶信息，并利用獲取到的個人用戶信息進行欺騙獲取更多的利益。

我們需要共同協作
　　安全問題不是某個個人的職責，關鍵需要團隊的協作。這對于應用程序的安全問題來說更是如此，信息安全人員、開發人員、系統和數據庫管理員都包括在內，這就是團隊協作。除非你所在的單位已經擁有了一個成熟的安全環境，而且已經使用安全類庫來處理數據庫調用和數據驗證，在數據庫和應用程序之間有一層數據訪問層，并確保所有的數據庫權限都受到了嚴格的限制，在這種情況下應當讓所有團隊成員參與并且了解高層次的應用程序。通過共同協作，所有人都可以了解到這些安全威脅，隨后可以共同想出更好的解決方案來應對。所有參與網絡應用和數據庫開發維護管理的人員都應該對目前存在的安全威脅有一個充分的認識和理解，這是非常重要的。我們必須要確保所有人員都理解應用程序的所有技術通信原理和數據流，了解數據從哪里來，如何到那里去的，以及數據是否和多個應用程序進行通信。這就是關于數據庫保護的第一層措施。

　　數據庫保護的第二層措施是安全架構。安全設計的基礎有時候也被稱作為安全架構，也就是說當我們以安全的方式設計數據庫環境時，應減少安全威脅。如果攻擊者無法直接訪問數據庫，這樣就降低了他們攻擊的靈活性。我們為攻擊者提供的活動空間越大，他們就越容易得手。同樣的，從相反的角度來看，我們就需要在后續做更多的工作，也就是說你必須確保對數據庫的訪問僅限于在需要的情況下進行系統訪問，而且所有的訪問都經過認證和加密的，而且不能影響到會話池。保證網絡和系統設計的安全將會對保護數據庫大有幫助，添加了數據庫訪問路徑的限制能夠大大地降低風險。

　　數據庫保護的第三層措施是威脅建模。確定威脅的過程被稱為是威脅建模，過去威脅建模是用在應用程序安全方面，用于確定應用程序的最高風險，這樣安全人員就可以重點關注在這一領域。這個概念開始延用到安全的其它領域中。應注意的是這不是一個新的理念，實際上保險行業已經采用此理念有數百年的歷史了，我們互聯網行業只是最近幾年才吸納這一理念，并開始就此主題發表了許多文章。

　　威脅建模包括將那些了解此應用程序的人以及相關領域的專家召集在一起，大家共同理解應用程序的不同部分、功能性和固有的威脅。花一定的時間來全面理解此應用程序以及相關的威脅，可以定制出相對應的保護和測試方案，可以節省時間或者在有限的時間和預算范圍內最大程度地降低威脅。威脅建模對于安全人員來說可以提供一種很好的手段來掌握全局、分解風險區域并與各小組單獨協作，確保保護措施落到實處。

　　在對多個應用程序或開發項目進行威脅建模時，應作好記錄，找到應用程序的共通性。這些共通性可以用于審查內部數據庫訪問標準、授權訪問以及優化訪問過程。

　　在編寫策略時應當涵蓋常見情況，并且明確地為開發人員和數據庫管理人員提供指導，確保人人手中都有一份參考資料。一旦這些步驟執行到位后，可以開始從基礎做起向數據庫環境添加安全措施。

　　雖然各個系統環境都不相同，但是數據庫配置對于保護數據是最為重要的部分之一，應當實現的常見配置有：
1.應當有恰當的人員維護和更新用戶名單，其中這些用戶可以訪問受管理的應用服務環境中數據庫。
2.系統管理員和其他相關的IT人員應該有充分的知識、技能并理解所有的關鍵的數據庫安全要求。
3. 當部署數據庫到受管服務環境中時，應該采用行業領先的配置標準和配套的內部文檔。
4. 對于數據庫功能不需要的默認用戶帳戶，應該鎖定或是做過期處理。
5. 對于所有仍在使用中的默認用戶帳戶，應該主動地變更密碼以采用強密碼措施。
6. 應該給數據庫內的管理員帳戶分配不同的密碼，這些帳戶不應使用共享密碼或組密碼。
7. 措施要到位，用于保護數據字典以及描述數據庫中所有對象的支持性元數據。
8. 對于任何訪問數據庫的基于主機的認證措施，應當有足夠的適當的過程來確保這種訪問類型的整體安全。
9. 數據庫監控應到位，由能夠根據需要對相關的人員進行告警的工具組成。
10. 保證數據庫應用了所有相關的和關鍵的安全補丁。
我們需要保護重要的數據

　　“一定要保護好數據庫的重要數據”，因為數據庫對于IT行業來說就好像是保管金銀珠寶的保險庫。如果保險庫不安全，財寶就很容易失竊，那主人就不會開心。

　　保護數據庫服務器的方式有網絡分段、系統分離，并將數據庫服務器放置在一層或多層保護網的后面。

　　有許多新的技術，包括數據庫活動監控軟件、數據丟失防護(DLP)、將數據庫分割，放到依據數據分類或風險模型的系統中，還有確保低安全性的應用程序無法訪問到高安全程度的數據庫等。

　　根據訪問權限和賬號，如果有多個部門的用戶因同一事件需要登陸進入同一應用程序,應該采取保護措施，以確保一個部門的人員無法訪問另一個部門的數據。這可以在數據庫層面上完成,方法是讓各個部門分別創建各自的數據庫或桌面;這樣的話可以實現數據分離，而且可以使用不同的數據庫賬號來加以保護。應用程序可以使用單一賬號用于非認證請求服務，比如說用戶登錄;一旦發生此類情況，應用程序可以將數據庫賬號切換至同用戶部門相關聯的另一個賬號。在設定許可權限時要防止通用賬戶訪問任何公司數據。

　　除此之外，部門A的數據庫賬號不能訪問部門B的數據。這樣就阻止了攻擊者越過公司的安全防線并擴大其接觸范圍。在進行應用程序數據庫賬號轉換時必須非常小心，因為攻擊者可能通過SQL注入攻擊來迫使應用程序改變其連接。在某些單位，開發人員會寫下他們自己的SQL查詢命令，而對于其它一些單位，查詢命令是由數據庫管理員來編寫和優化，然后再提供給開發者。

　　在最安全的環境下，這些查詢命令由數據庫管理員編寫和執行，作為存儲過程。存儲過程是由應用程序執行的預定義語句。這樣就使得SQL注入攻擊更加難于得到利用。在這種特殊情況下，如果沒有存儲過程的話，攻擊者可能已經作為管理員登錄進入此應用程序并且取得此數據庫完全控制權，而且只需要得到管理員用戶名稱即可實現。

　　同時還需要建立敏感數據的安全邊界。通過采取相應的技術措施，為用戶的各種數據庫建立一個關于數據的安全邊界。我們可以將數據庫服務器置于標準的網絡防火墻后面，并限制訪問，以確保我們了解什么系統能夠訪問你的數據庫，從而降低風險。但是千萬不要以為簡單的配備一些防火墻就可以防范這些安全威脅，可能還會有其他我們未發現的未知風險存在!

　　安全人員在開發新的安全數據安全模型時，安全人員應該進行測試，以確保他們提供了需要的保護級別，并且沒有引入新風險。最后關于實現數據基于策略的自動管理問題，它包括數據的分類、備份、遷移、刪除等，實現全面的數據存儲管理自動化，這樣不但減少了人為出錯的可能性，也提高了數據庫的安全性和可用性。使用一套優質的解決方案按照標準的規范進行設計和部署，提供充分的靈活性、擴展性和安全性，滿足數據庫安全保管方面當前和今后的法規要求。

回到源頭，WEB安全刻不容緩
　　最小權限原則、保護數據庫連接、分段服務器和網絡、安全驗證、安全邊界和數據庫安全配置對保護數據很有用處，但是這些不會解決攻擊者所有的攻擊企圖。從廣義上講，數據庫的安全首先依賴于網絡系統。網絡系統的安全是數據庫安全的第一道屏障，外部入侵首先就是從入侵網絡系統開始的。所以現在需要關注最普遍存在的威脅;WEB應用安全。

　　由于某些開發人員犯了非常低級的編程錯誤，比如：應用ID只能被應用使用，而不能被單獨的用戶或是其它進程使用。但是開發人員不這么做，他們給予了應用程序更多的數據訪問權限。這就類似于醫生因沒有洗手而傳播了傳染病，從而導致各種漏洞的出現。

　　我們必須接受已經存在的應用缺陷和漏洞。通過發揮數據庫管理員的安全職責去阻止因為應用缺陷和漏洞所造成的不良后果。比如如果開發人員不重視應用與數據交互的安全性，堅持最小權限原則，數據庫管理員則有權在這場互動中占取主動，不給開發人員全權委托，數據庫管理員可以不允許那么多的交互被授權;為了阻止黑客的滲透攻擊從不可避免的網絡程序應用漏洞中占便宜，數據庫管理員也有權進行其他有效的安全控制。并且數據庫管理員應對數據庫進行加密保護，如密碼不能使用明文保存;對所有應用層和數據層通信的審計監控將有助于快速識別和解決問題以及準確的判斷任何安全事件的范圍，直到實現安全風險最小化的目標。

　　假如出現數據外泄事件(如2011年年底的CSDN等網站的用戶數據信息泄密事件)，責任也不止是在數據庫管理員身上，開發人員也需要共同承擔責任。其中一個非常重要的方面，開發人員能做的就是在用戶能輸入的地方最好過濾危險字符，這樣可以防止黑客通過諸如SQL注入攻擊獲取到數據庫的敏感信息。目前在各類行業網站上，各種WEB應用漏洞隨處可見，可以被黑客們檢測到(他們一般會用軟件同時掃描數千個網站)。

　　開發人員在完成一套新的應用程序后應使用安全檢測工具對其進行反復白盒測試，有條件的情況下可以請信息安全人員模擬黑客進行黑盒滲透測試，盡可能的發現應用程序的弱點并進行修補。如果想實現更完整的解決方案，更多有關的保護數據和數據庫是應當實施源代碼分析。這是一項冗長的處理過程，可以請安全服務提供商用專業的源碼審計軟件對應用程序代碼進行詳細的分析處理，這些工具會直接查找出更精確的缺陷結果。

　　同時應該與開發商或者安全廠商合作并確保能提供安全解決方案，這對于任何致力于部署網絡應用數據庫正常安全訪問的用戶都至關重要，WEB應用安全測試對于確保數據庫的安全性有至關重要的作用。

一款好的工具可以有助于加快進度并且提供更好的檢測結果和解決方案，以提供應用程序更好的的安全性，關鍵是進行反復評估以確保管理工作正常，對結果實施驗證并加固，確保風險一經發現立即補救，并保證管理人員能夠了解到相關問題的存在。

　　黑盒測試黑盒測試是一種把軟件產品當成是一個黑箱的測試技術，這個黑箱有入口和出口，測試過程中只需要了解黑箱的輸入和輸出結果，不需要了解黑箱里面具體是怎樣操作的。這當然很好，因為測試人員不用費神去理解軟件里面的具體構成和原理，測試人員只需要像用戶一樣看待軟件產品就行了。

　　例如，銀行轉賬系統提供給用戶轉賬的功能，則測試人員在使用黑盒測試方法時，不需要知道轉賬的具體實現代碼是怎樣工作的，只需要把自己當成用戶，模擬盡可能多的轉賬情況來檢查這個軟件系統能否按要求正常實現轉賬功能即可。

　　如果只像用戶使用和操作軟件一樣去測試軟件黑盒測試可能存在一定的風險。例如，某個安全性要求比較高的軟件系統，開發人員在設計程序時考慮到記錄系統日志的必要性，把軟件運行過程中的很多信息都記錄到了客戶端的系統日志中，甚至把客戶端連接服務器端的數據庫連接請求字符串也記錄到了系統日志中，像下面的一段字符串：
"Data Source=192.168.100.99;Initial Catalog=AcoDB;User ID=sa;PassWord=123456;

　　那么按照黑盒測試的觀點，這是程序內部的行為，用戶不會直接操作數據庫的連接行為，因此檢查系統日志方面的測試是不會做的。這明顯構成了一個Bug，尤其是對于安全性要求高的軟件系統，因為它暴露了后臺數據庫賬號信息。

　　有人把黑盒測試比喻成中醫，做黑盒測試的測試人員應該像一位老中醫一樣，通過“望、聞、問、切”的方法，來判斷程序是否“有病”。這比單純的操作黑箱的方式進了一步，這種比喻給測試人員一個啟示，不要只是簡單地看和聽，還要積極地去問，積極地去發現、搜索相關的信息。應該綜合應用中醫看病的各種“技術”和理念來達到找出軟件“病癥”的目的，具體作法如下：
“望”，觀察軟件的行為是否正常;
“聞”，檢查輸出的結果是否正確;
“問”，輸入各種信息，結合“望”、“聞”來觀察軟件的響應程度;
“切”，像中醫一樣給軟件“把脈”，敲擊一下軟件的某些“關節”。

　　白盒測試如果把黑盒測試比喻成中醫看病，那么白盒測試無疑就是西醫看病了。測試人員采用各種儀器和設備對軟件進行檢測，甚至把軟件擺上手術臺解剖來看個究竟。白盒測試是一種以理解軟件內部結構和程序運行方式為基礎的軟件測試技術，通常需要跟蹤一個輸入經過了哪些處理，這些處理方式是否正確。

　　在很多測試人員，尤其是初級測試人員看來，白盒測試是一種只有非常了解程序代碼的高級測試人員才能做的測試。熟悉代碼結構和功能實現的過程當然對測試有很大的幫助，但是從黑盒測試與白盒測試的區別可以看出，有些白盒測試是不需要測試人員懂得每一行程序代碼的。

　　如果把軟件看成一個黑箱，那么白盒測試的關鍵是給測試人員戴上一副X光透視眼鏡，測試人員通過這副X光透視眼鏡可以看清楚輸入到黑箱中的數據是怎樣流轉的。

　　一些測試工具就像醫院的檢測儀器一樣，可以幫助了解程序的內部運轉過程。例如，對于一個與SQL Server數據庫連接的軟件系統，可以簡單地把程序的作用理解為：把用戶輸入的數據通過SQL命令請求后臺數據庫，數據庫把請求的數據返回給程序的界面層展示給用戶。可以把SQL Server自帶的工具事件探查器當成是一個檢查SQL數據傳輸的精密儀器，它可以記錄軟件客戶端與服務器數據庫之間交互的一舉一動，從而讓測試人員可以洞悉軟件究竟做了哪些動作。

　　在測試過程中，應該綜合應用黑盒測試方法和白盒測試方法，按需要采用不同的技術組合。不要用黑盒測試方法和白盒測試方法來劃分自己屬于哪一類測試人員，一名優秀的測試人員應該懂得各種各樣的測試技術和查找Bug的手段。

　　最后我們談談新的防火墻問題。到目前為止，我們都是側重于預防措施。但在現實世界中，我們不可能總是改編程序和環境，所以我們必須采用其他技術措施。這就是為什么會產生新的防火墻。

　　防火墻用于應用程序或者監控流量的運行監控，也可以在執行運行時進行分析。防火墻可以找出攻擊，并阻止嘗試或修改的要求，來確保WEB服務器和數據庫服務器的安全運行。

　　目前不光有WEB應用防火墻和網絡防火墻能防范攻擊者透過應用層和網絡層的攻擊;“數據庫防火墻”也于這兩年在不斷的數據庫泄密事件中出現在公眾的視線里，國內稱之為“數據庫審計”產品，這些產品能給數據庫提供實時的網絡存儲與訪問的安全。

　　任何一個好的數據庫安全策略都應包括監控和審計，以確保保護對象正常運行，并且運行在正確的位置上，這也是個非常耗時的過程。由于缺乏時間和工具，大多數用戶對于數據庫配置的檢查往往也僅是抽查而已。

　　這里還需要指出的是目前多數人認為“數據庫審計”等同于數據庫安全，事實上，數據庫安全遠遠不是數據庫審計可以搞定的，數據庫審計只是數據庫安全的一個很小的方面，之所以有時候對等起來，一方面是由于市場宣傳導致的誤導，另一方面的確是這個部分的問題比較容易產品化/工具化，技術實現相對比較成熟。數據庫安全應該包括：數據庫資產管理、數據庫配置加固、職責分離、特權用戶控制、數據庫弱點掃描和補丁管理、數據庫加密、數據庫審計。

　　最后，我們還是回到應用程序的安全以及與數據庫之間的相互作用問題上。即我們必須要考慮到的問題是應用程序的安全以及與數據庫之間的相互作用，尤其是對于當今流行的高度動態的和互動的網絡應用程序而言。理解數據庫與應用程序和系統環境之間的作用可以更加提升數據的安全性。

　　有問題是客觀情況，其實我們需要的不是過多的責難，而是不斷改進問題本身，當我們被迫把安全做的簡單時，我們就被迫直接面對真正的問題。當我們不能用表面的裝飾交差時，我們就不得不做好真正的本質部分。希望本文可以讓讀者了解到一系列管理和風險降低方面的策略，不論你是否愿意配置數據庫防火墻、進行源代碼審記或者嚴格地控制數據庫管理系統，其目的都是相同的：做好應用安全和數據安全的兩位一體，保護好重要數據。