機遇與隱患并存 您企業(yè)的SOA架構是否安全

申請免費試用、咨詢電話：400-8352-114

面向服務架構(SOA,service-oriented architecture)為公司進行跨部門、跨系統(tǒng)以及跨企業(yè)整合創(chuàng)造了巨大的機遇，整合可以幫助公司簡化業(yè)務流程、提高上市速度，共享數(shù)據(jù)和服務，并且能夠讓公司對商業(yè)變化更快地做出反應。

舉例來說，正確的SOA架構可以將電子商務網(wǎng)站毫無痕跡地與該網(wǎng)站的供應商、分銷商、信用卡公司以及消費者整合在一起，這樣的話，當消費者發(fā)出訂單時，系統(tǒng)就能夠在無需請求用戶或者系統(tǒng)的情況下將信息即時向各相關方面發(fā)布。

SOA同樣還可以通過抽取某些業(yè)務流程、服務或者數(shù)據(jù)點來幫助公司重新恢復他們的遺留系統(tǒng)，而不需要丟棄或者取代那些系統(tǒng)。公司在建設新的系統(tǒng)時可以將新系統(tǒng)與舊系統(tǒng)進行無縫整合，那樣就可以降低公司的投資成本。

對于終端用戶來說，這的確是好消息。但是對于安全部門的工作人員來說，卻是他們最大的噩夢。

公司整合的負面影響

雖然正如上文所述，一體化整合存在很多好處，但同時也會給安全、隱私以及合規(guī)帶來巨大的安全風險，對于能夠輕易與其他服務整合的服務(兩者都在防火墻后面或者防火墻外部)，這兩種服務必須是可以被發(fā)現(xiàn)的以及易于轉換的。

為此，很多SOA部署都使用了Web服務，web服務使用的是WSDL(Web服務描述語言)，這種語言能夠描述如何行使該服務。 UDDI(統(tǒng)一描述、發(fā)現(xiàn)和集成)是web服務中常用的一個標準，它能夠允許服務被發(fā)現(xiàn)以及檢索。

SOA中經(jīng)常使用的另外兩個重要標準就是XML和SOAP(簡單對象訪問協(xié)議)，XML是一種自我描述格式，它包含了信息的清晰的文本描述，而SOAP是用于交換基于XML信息的協(xié)議并且也能提供重要信息的清晰的描述。

然而，盡管這些標準能夠幫助公司更加方便地進行服務整合，但是如果適當?shù)陌踩胧]有到位，就必然讓黑客有機可乘。

很多舊系統(tǒng)并沒有設計為能夠接觸到其他系統(tǒng)，尤其是防火墻外的系統(tǒng)。現(xiàn)在有了SOA，就使黑客能夠進入他們以前不能訪問的系統(tǒng)和數(shù)據(jù)，這還得歸功于SOA的發(fā)現(xiàn)以及自我描述特性。

公司內(nèi)部面臨的挑戰(zhàn)

我采訪過很多架構師、供應商、培訓人員和安全專家，問過他們這樣一個簡單的問題: 在部署SOA的時候你認為存在的最大安全風險是什么?我將收到的答案歸類為以下幾部分:

· 對于公司內(nèi)部巨大的安全風險缺乏意識或認識

· 在各服務間、各系統(tǒng)間以及企業(yè)間普及使用授權證書

· 監(jiān)控、審計和執(zhí)行政策的能力

缺乏安全風險意識或認識

軟件構架師(EA)必須接受適當?shù)呐嘤杹砀玫乩斫釹OA部署，從而鑒定安全風險級別。很多SOA部署是由軟件構架師團隊從技術的角度來驅動的。如果架構師們對于安全風險問題沒有足夠的意識，那么他們就不知道該如何部署安全措施來保護服務，同樣他們也不會知道什么時候需要調(diào)動安全和審計專家。

安全部署應該建立在前期，而不是事后才考慮的問題。向每個服務部署安全措施會對每個服務的性能和可維護性造成一定的負擔，安全措施應該作為核心服務來部署，這樣安全措施就能進行集中管理和維護。此外，管理層必須明白存在的安全風險，并提供適當?shù)闹С趾唾Y金來有效地保障企業(yè)的安全。

普及使用授權證書

很多服務都是“無頭的”，這就是說這些服務與用戶界面沒有關系。這些服務被其他服務啟用并且啟用其他服務，啟用服務必須通過授權認證以便正給系統(tǒng)的流動從開始到技術都不被中斷。使問題更具挑戰(zhàn)性的是，一條簡單的信息可能包含多個服務客戶的XML數(shù)據(jù)。例如，我們繼續(xù)使用電子商務網(wǎng)站的例子，客戶的一條請求可以觸發(fā)包含XML數(shù)據(jù)的信息，XML數(shù)據(jù)是有關供應商、分銷商和信用卡公司的數(shù)據(jù)，而且每部分有不同的安全要求。只有信用卡公司能夠訪問信用卡信息(應該加密為PCI兼容)，供應商需要知道那些產(chǎn)品被運出存活區(qū)，而分銷商需要知道產(chǎn)品和送貨地址等信息。

從這個例子中你會發(fā)現(xiàn)過去單純使用SSL是遠遠不夠的。在這個例子中，同樣的訊息被發(fā)送給不同的三個公司而不需要他們各自登錄。很多公司都采用的是WS-*標準(WS-安全, WS-信任, WS- 聯(lián)合, WS-政策, 等等.)來解決存在的安全風險。

最佳解決方法包括XML加密，使用公鑰和/或者令牌以及一個政策驅動辦法來解決相對于硬編碼的安全問題。

但是當我們執(zhí)行這些最佳解決方法的時候事情會變得更加復雜，XML加密可能導致系統(tǒng)性能退化，這就帶來對XML工具/加速器的需要。政策驅動安全增加了公司對更新、維護和審計安全政策工具的需要，這就將我們引入了下一部分的內(nèi)容。

審計、監(jiān)控和執(zhí)行政策

那些回答了我問題的人都強調(diào)了對所有服務實行端到端監(jiān)控和審計的重要性，這是我們在討論向架構中部署適當?shù)陌踩胧r需要考慮的一個重要問題，我們可以通過另外一件事來證明這一點。

架構師在將安全措施作為一項服務來部署時，需要從審計和監(jiān)管的角度來考慮需求問題。我們有SOX,HIPAA,PCI和很多其他規(guī)章制度，有時候這些規(guī)章會直接與另外的規(guī)章相沖突。

舉例來說，SOX需要我們存儲所有有關金融交易的信息，而PCI則指出我們不能存儲信用卡號碼，然而同時我們需要將信用卡信息通過金融指示。要想做到這一點，我們可以使用各種的加密法和其他安全措施來幫助公司實行審計，為了通過這些審計，我們必須根據(jù)每項服務的請求來記錄信息的正確級別，以此來提供一種方法向不同的審計師和監(jiān)管機構證明我們是在遵守他們的準則，僅僅一次壞的交易就可能使一次審計失敗。

還存在的一個巨大挑戰(zhàn)是，外部服務客戶使用某些服務的方式是被認為不合適的。服務性消費必須加以主動監(jiān)控來查明那些破壞安全政策的不恰當?shù)姆帐褂檬录?，這樣就能在發(fā)生災難性后果之前快速的部署解決方案。在解決方案產(chǎn)生之前，我們必須確保我們在正確的時間向正確的客戶發(fā)送了正確的數(shù)據(jù)。

我們能做什么?

我想到有兩種方法可以幫助減輕這些安全風險。首先是提高認識。公司應該加大培訓的力度來培訓每一個人，而不只是對開發(fā)人員培訓。管理層需要一個高層次的培訓，而架構師、安全專家、審計師、開發(fā)人員、測試師、業(yè)務分析師、系統(tǒng)管理員、網(wǎng)絡工程師和其他人則應該根據(jù)他們各自的需求進行培訓。

第二點就是，安全是每一個人的責任，而不僅僅是軟件架構師或者安全架構師的責任，整個公司應該承擔起保護公司安全的責任。我強烈推薦公司可以雇傭一名有經(jīng)驗的SOA安全專家或者聘用一名安全顧問，在公司內(nèi)部的安全部門傳播安全知識。

此外，我強烈推薦Ramarao Kanneganti 和Prasad Chodavarapu合著的《Enterprise SOA》以及《SOA Security》這兩本書。來自Progress Software的Dan Foody給我們帶來了很多有關從安全角度SOA帶來的挑戰(zhàn)的生動有趣的例子，他采用造訪白宮的比喻來解釋SOA需要解決的不同級別的安全問題。

造訪白宮的第一個安全級別是進入白宮，在這個安全級別中，會有一名警衛(wèi)來檢查你的身份，讓你通過一個金屬探測器并且使用X光來檢查你的物品。進入白宮里面后，你會發(fā)現(xiàn)第二個安全級別：白宮里面每個門前面的保安人員。在你進入那些門時你需要提供其他必要信息，但是這里就不再會使用金屬探測器和X光機器了，因為你已經(jīng)經(jīng)過檢查了。在第三個安全級別中，你的向導會將你領入白宮內(nèi)某個特定區(qū)域，在這個區(qū)域你不能隨意的散步，并且你正在被你所看不見的眼睛所監(jiān)視著。

這是一個很好的例子，讓我們認識到保護SOA必要的安全級別，不幸的是，很多公司只是在大門口配備了幾個保安人員。（IT專家網(wǎng)）