SOA改變資安Game Rule

服務導向架構(SOA, Service-Oriented Architecture)已改變了資訊安全的遊戲法則。它所標榜的策略目標－互通性、整合性、服務虛擬化及再用性，更需要利用特別不同的方式，才能保障這個服務架構的安全。
其中，互通性和整合性代表企業提供的服務，乃基於他們為服務用戶和服務提供者所帶來的加值效用(例如，從Web上將登機證列印下來)，而非使用傳統IT技術倉儲(IT silo)的觀點（像是封閉的CRM或ERP系統）。另外，虛擬化在Web服務的背景當中，服務在被呼叫使用的當時，與提供來源點位置其實是無關緊要的，如此一來，商業合作夥伴便可以是身在東京，印度或是芝加哥，他們均能於同一商業程序下，一起合作運行。再者，商業邏輯的再用性，是更多可靠且發揮成本效益之平台的誕生，免除每個專案都必須重頭來過的窘態，同樣地，這點也適用於「安全服務再用」上。
有句話是這麼說的：「安全必定是企業在前方的引路人。」－在SOA架構下尤是如此！而克服這種商業限制的認知，則在於服務屬「受託代理」的性質。
不過，這個問題會在什麼情況下發生？因為安全服務主要需來自於設計，發展以及營運各方的支援，所以它必須鎖定在高風險或高商業加值觀點下審視。但是，要經過充份足夠的時間，其特徵才會在企業之中浮現出來，此時，安全的統御能力才可協助訂出最符合成本效益，並達成安全共享服務再用的安全投資。就這觀點，安全便跳脫以往稽核者的角色，並成為擁護商業的服務建立者！
以下，就讓我們來審視，扮演安全供應的角色，在21世紀安全服務架構下，找出對應的關鍵守則。


與最終能作安全決策者成為夥伴
這門常被疏忽的課題，在SOA管理架構下著實顯得重要。所以，IT安全特色會是建構在商業，軟體發展(包含委外)和顧客之間的夥伴關係上，若是安全愈早被考量到，那麼當系統佈署之際，愈多可能的安全需求機制也就接著會被實現出來，而非只是事後的修修補補。



找出藏於企業當中的風險
在任何整合作業下，均會潛藏技術性和商業性的風險－何況是以SOA複合多次所得到之架構，這亦是關乎跨商業邏輯、地理位置和技術界限之間的服務平台與流程互通等問題。
從這兒我們還可以找出企業的優勢：在顧客與夥伴的整合中間，商業利益和風險更易於用風險管理的辭彙被量化出來，原因是，它們均與商業應用服務連結在一塊兒，而非與IT架構有所牽連。最後，請將貴企業安全預算的每一分錢，放在該投資的事情身上，使其符合企業期待。



用科學數據量化風險
風險常與數字有所關聯，所以，我們應隨著時間，量化一切我們所作的，還有整理出所量測的程序數據。另外，將SOA本身便具有分散和異質的特性考慮進去，用風險矩陣一統安全事務，可以給安全小組一個客觀的方式「看見」系統的安全形態，並能輔助企業最後把關的人作出有利之決策。



於系統發展之初，便注意安全
安全不應只扮演稽核者的角色，而是要當自己是系統設計發展中的一份子。所以，請早些兒將安全納入考量，並置安全於SOA軟體發展週期之內。從歷史的角度來說，軟體發展者會視安全為一種阻礙，所以，讓安全服務再用這事提早發生，並能順利達到節約成本與時間的目的。
比方說，若以瀏覽器端實作SAML單一簽入(SSO)的機制，那麼，這事便能一舉跨越多個應用軟體界限，並獲得更好，更快，更廉價的身分驗證服務。
透過威脅模式(threat-modeling)服務建構所得來的專業知識，能夠為之後的專案定義出恰當的安全需求，並能協助提供安全保護，以及執行上線前的安全測試。


站在中心點，客觀看待安全問題
當SOA跨出企業的邊際界限，把資料送離企業境外處理時，IT安全就必須要投向分散式的安全架構。
不過，該架構的問題是，如何在分散式端點上，不斷地強化其安全政策，並居中扮演你無法持續控制或稽核的協調角色？
這些問題尚包含遠端分部辦公室，從家中連進公司辦公的員工，還有委外開發與商業活動相關的程序。所以，因服務所發展出來的安全架構，像是身分認證、授權及稽核，也都必須順應此項新法則的潮流。



安全地傳遞訊息文件
SOA是以XML訊息文件導向所組成的系統，在傳統的IT安全裡頭，伺服主機會以提出請求的方式來認證並授權用戶端；然而，在SOA整合性架構下，訊息文件會包含服務提供者相關的資訊－而採用單一集權的伺服主機模式－向用戶執行認證及授權作業。因此，安全架構必須要能反應出此點，從許多IT安全組織觀點而言，這是心態上最大需要調整的地方。
此外，該模型尚需IT安全能快速地跟上協同合作的商業行為，只因為它對於實際硬體所產生之界限依賴較少，並且也較少稽核每個中介代理端點。文件訊息可經由加密，數位簽章和內容驗證等方式，受到保護，非關它們是否在阿姆斯特丹，雪梨或者是羅馬等地。
專注企業安全於訊息安全機制再用的設計與實現，像是簽章及加密，就能靠開放性標準－諸如WS-Secutiry和SAML－獲取平台間訊息廣泛地交換互通。因為此類平台不難開發，所以一些特製工具－如XML安全閘道，亦已經有相關方案。



實作聯邦身分管理機制
因為數位身分極具特殊情境(context-specific)的性質，於是SOA充滿高度分散的認證方式，便造就了資料供輸與存取的挑戰。不會有系統一一詢問有關於你特定身分的每件事，反倒是，利用另外宣告身分識別的服務，再透過額外信賴的服務來評估這些資料。
所以，當想過此事之後，你就會明瞭其實最要緊的就是清楚企業目前在資料供給，身分存取管理和聯邦系統方面，其能力和界限為何？
幸運地是， 聯邦身分管理(federated identity)所採行的，是SOA最基本的法則－即將遞送身分視為是一種服務，並擴展企業身分辨識管理系統所能掌控的觸角。
而我們的挑戰，則是藉由建立足以代表身分和服務(交換身分宣告，還有身分驗證、授權和稽核三者結果)的schema，促使聯邦身分管理採行服務要求者和提供者之間的驗證案例。因此，這塊商機乃出自於顧客和夥伴之間，不斷提升兩者整合的成果。



保護登錄服務滴水不漏
登錄服務包含了一些有價資訊，例如data schema、服務介面，還必須經由存取控制被妥善保護的安全政策資訊。
就理想狀況而言，它們應該受到最高等級的保護，像是OS kernel的層級。因此，登錄服務其實就是安全政策與安全機制的metadata，在系統設計階段所描述，以及在runtime時被執行的地方。



強化中介軟體安全
中介軟體(middleware application)均設計「藏身」在防火牆之中，與外界是獨立分開來的。而SOA的整合性需求則更放諸更多的信任在中介軟體身上。而它們的功能通常被當成是分散架構下的資訊集中地，同時，也匯聚了企業各項服務和資料在內，並且還連結至部份關鍵性系統上。所以，這項新角色動態地改變了自身的安全需求，並且我們是有必要對安全架構再作一次審視。
事實上，重點就是確保遞送訊息有足夠安全權限被繞送到網路裡頭，並要限制存取裡頭的資料。在這兒，我們可以把整件事比擬成：信封袋中的信(XML訊息)需要正確地址和郵資，但是要防止郵局辦事員(中介軟體)讀取信裡頭的內容。
Gunnar Peterson目前身為Arctec Group的總經理，該公司主要提供IT架構方面的服務。