SOA安全性基礎知識:測試SOA安全性

　　本系列討論面向服務的體系結構（Service-Oriented Architecture，SOA）安全性實現路線圖。“SOA安全性基礎知識”系列包括三個部分，本文是其中的最後一個部分，將提供用於測試SOA安全性的規則。瞭解組織中用於構建最佳SOA安全性所需要的工具和知識。

　　在召集團隊並開發新的SOA以後，現在是測試其安全性的時候了。測試使您可以瞭解遠景是否與對成功的承諾保持一致。

　　測試應該分成兩個階段進行：生產前測試 和生產測試。生產前測試是允許對任何新的應用程式或硬體解決方案進行任何外部訪問之前的最後步驟。此測試旨在模擬生產環境，不僅應該測試安全性，而且還應該測試負載、流程和功能。

　　生產前環境和生產環境之間通常存在微妙的區別——例如，硬體、作業系統配置和防火牆設定。因此，在生產測試期間，要重新檢查在生產前做出的安全性改進。

　　預先為測試做規劃

　　通過確定必須測試哪些元件以及如何最好地測試那些元件來開始您的測試。非管理使用者是否可以獲得管理許可權？是否要對沒有許可權的使用者隱藏私有資料？常見的黑客指令碼是否能夠找到被忽視的漏洞？結構化查詢語言（Structured Query Language，SQL）注入是否失敗？確保擺脫思維的束縛，並考慮惡意使用者可能採用來滲透安全層的任何工具。通過考慮內部和外部專案的安全性，您可以同時在兩個測試階段中實現最大的測試覆蓋面。

　　對所做的測試和測試時間做文件記錄。對測試做計劃安排對於避免測試人員和開發人員彼此干擾是非常重要的。測試會破壞應用程式，因此務必瞭解是哪些測試導致了破壞。此外，您可能需要在下班後執行某些測試，因此找到恰當的人員也是非常重要的。

　　您在本系列的 第1部分 組建了自己團隊。從該團隊選擇最適合幫助進行安全性測試的成員。測試團隊通常在構建階段基本形成，此時人們自然地協作處理新SOA的功能、支援和使用方面。確保在形成這些團隊時，在各個團隊中引入安全專家。

　　還要考慮引入中立方以在測試期間提供幫助。這些測試人員可以是不參與最終SOA設計的精選使用者或開發人員。這樣的測試人員通常可以提供有關功能工作狀況和安全性是否工作正常的中肯意見。在早期階段徵求外部安全專業人員的意見還可以引入大量的資訊。這些專業人員專門處理安全問題，能夠提供不同尋常的建議來保護資料避免未經授權的訪問。專業的安全公司通常也提供了不同的專門研究，例如網路、應用程式和硬體，這些專門研究能夠擴充您的當前人員的知識。這些團體通常擁有直接的供應商支援，因而通常能夠提供不容易通過其他途徑找到的高階資訊。

　　在組建測試團隊以後分配測試。向團隊成員傳達他們應該如何執行測試以及預期會得到什麼結果。在顯示“事前和事後”結果的書面檢查清單中記錄具有已知答案的問題。測試人員不僅要以正確的順序執行任務，而且還要確定結果是否符合開發人員的預期。應用程式提供了某個結果並不意味著該結果是正確的。例如，如果新的 SOA 是客戶訂單系統的一部分，則要檢查數學運算。裝運費和稅款是否計算正確？

　　設定標準

　　安全性測試應該同時遵守程式設計和行業標準。諸如Payment Card Industry (PCI)和Health Insurance Portability and Accountability Act (HIPAA)等行業遵從性標準具有關於如何處理資料的特定規則。

　　設定生產前環境

　　在將更改投入生產應用之前，始終考慮使用專用的生產前環境來測試更改。生產前環境應該與生產系統儘可能密切地匹配。這在測試負載和安全性時會變得非常關鍵。有時，細微差別也是非常關鍵的，例如同時在兩個環境中使用相同版本的Linux?。

　　例如，假設所構建的新SOA應用程式將使用IBM? WebSphere?。測試和生產系統都已安裝和更新最新版本的WebSphere。然而，生產環境使用SUSE Linux，而測試環境載入的是Red Hat Linux。雖然兩種Linux版本之間的區別非常小，但新應用程式的元件補丁安裝方式會有所不同，從而導致在投入生產環境後失敗而無法正常工作。

　　企業在生產前環境中使用較舊的伺服器，在生產環境中使用更好、更快的伺服器，這種情況並不鮮見。此決策出於經濟考慮是有意義的，但是在測試負載和速度變化如何影響安全性時，這種做法將會導致問題。

　　當生產環境使用具有大量記憶體的多處理器硬體，而測試環境硬體使用單處理器並且僅有1GB記憶體時，此問題會進一步惡化。應該保持使用同一代的處理器和相同的記憶體容量並標準化硬體供應商，從而簡化這個問題。實現硬體標準化可以提供在兩個環境中使用相似驅動程式和元件的優點。

使用虛擬環境

　　考慮使用載入有生產伺服器備份的虛擬伺服器來建立生產前環境。在諸如Vmware等虛擬化產品中擁有生產環境的精確副本可以簡化伺服器設定。如果特定的測試破壞了伺服器，測試人員可以通過載入伺服器的克隆副本來重新建立該伺服器。

　　事故處理

　　在對外部世界實現SOA之前，應該決定您將如何處理安全漏洞。假設您某一天發現游標不受控制地移動，或者發現使用者資料的打包檔案被移動到FTP伺服器。您是否會立即拔掉插頭？是否會報警？是否會搭乘開往百慕大的第一個航班？

　　擁有確定和周密的計劃會減少安全入侵所帶來的一些恐慌。至少，安全漏洞響應計劃應該包括聯絡人列表、初始響應團隊和基本指示。聯絡人列表應該包括技術專家以及重要相關者，例如公司總裁。

　　基本指示告訴工作人員首先應該如何做，並確定用於保留證據的最佳方法。這些指示還應該包括執行任務的正確順序——例如，首先應該拔掉插頭還是應該給資訊長(CIO)打電話？

　　響應團隊應該包括資訊科技(IT)專家和重要的管理人員。管理人員可以是其他部門的聯絡點，用以解釋系統停止的原因。他們還可以穩定形勢，因為有關漏洞的訊息可能會導致恐慌。例如，管理人員可以警告客戶服務部門網站已關閉，以便他們知道預期會有更多的電話呼叫。管理人員還可以構造客戶服務代理人用於應付客戶的措辭，以防止驚嚇著客戶。

　　此外，還要考慮使用一個外部法律團隊作為響應團隊的一部分，以幫助確定賠償金額。外部供應商將具有比在職員工“更冷靜的頭腦”，並且還可以引入執法級別的法律工具。

　　實現後的測試

　　完成生產前測試並將應用程式轉移到生產伺服器並不表示測試的結束。生產測試是對您的SOA的最終考驗。請記住，將在其中執行測試的環境與生產環境不可避免地存在細微的差別：當您正在構建SOA時，當前環境是一個活動的有機體。諸如防火牆配置、伺服器修補程式和反病毒更新等次要更改都會影響生產前的安全性。

　　要在將SOA轉移到生產環境之前執行的最合適安全測試之一是滲透測試。滲透測試從外部考驗SOA應用程式，以嘗試破壞安全性。這些測試最適合留給認證正義黑客（Certified Ethical Hacker，CEH）去執行：他們擁有竭盡全力地潛入組織內部所需要的工具和知識。CEH使用攻擊方法來利用不當的作業系統修補程式安裝或錯誤的應用程式程式碼。

　　滲透測試通常至少執行兩次。第一輪測試查詢安全錯誤，並向SOA團隊報告。第二輪以及後續的測試將在已糾正第一輪測試中發現的缺陷之後執行。讓CEH執行“盲”滲透測試可以揭示有關SOA的大量資訊。在這樣的測試期間，在CEH嘗試攻擊系統之前，應該為其提供有關基礎設施的最少資訊。通過這種方式，CEH可以獲取外部攻擊者在嘗試滲透環境之前需要了解的實際場景。人們以為內部人員的考慮已天衣無縫，但是這些測試可以帶來一些令人驚訝的結果。

　　總結

　　在您可能希望匆忙實現新的SOA時，請不要在安全方面走任何捷徑。通過依賴SOA的基本原理，您可以避免資料被洩露。即使在將SOA交付使用之後，仍要繼續使用以下安全措施：

　　·在SOA開發小組的基礎上組建安全團隊。
　　·開發測試並提供預期結果。
　　·在獨立於生產的環境中測試改進功能。
　　·建立並維護安全標準。
　　·在推出SOA之前執行滲透測試，並在之後定期使用滲透測試。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-406905/，如需轉載，請註明出處，否則將追究法律責任。