SOA的安全議題

 

如同一般系統,SOA也有中央控制權限,除了使用者權限之外,還包含整個服務提供過程中的訊息安全,其複雜度遠較一般單一系統複雜許多,需要特別闢一個段落來說明,分開討論如下,

 

1.      使用者權限

一般系統都會有自己的中央權限來進行單一系統,SOA也不例外,但SOA是統整各服務協同運作之用,它必須有一致的權限控制能力,同時又需要相容於其他系統,特別是已存在系統(Legacy System),將大幅的提高設計上的難度,涉及到的工作如下。

 

(1)    使用者資料整合

首先,就是使用者資料的整合,如果使用者資料無法整合,將無法進行有效的帳號管理,實務上,最常見或較正規的解法就是透過LDAP或資料庫來進行整合帳號整合。但在某些特殊場合,我們也會透過建立關連的方式來維護使用者帳號的一致性,不過這類方式的優點是易於實行,但缺點也是顯而易見,系統將會是疊床架物而難以維護,如果使用者願意接受,仍以統整在LDAP或資料庫中為優先推薦。

 

(2)    認證

一般的單一系統很少將認證與授權分開來討論,事實上他們是兩個動作,簡單的說認證是認定誰是誰,授權則是說明誰可以做什麼。這在跨系統服務中很重要,因為一般我們常採用單一認證及分系統授權的運作機制,如果觀念不正確或設計系統時不分開來,其結果就是糾纏在一起的單一簽入系統(SSO),未來將難以或無法維護。常見的認證方式有已下幾種。

 

第一種 帳密認證

也是最常見的處理方式,透過帳密來進行認證。

第二種 憑證認證

這類方式更為嚴謹,後臺往往需要整合認證伺服器與LDAP(多數使用LDAP,其實資料庫也可以做到),來進行使用者真實身份認證與系統帳號的關連檢核

                        第三種    網域伺服器整合

有些系統本身則是透過網域伺服器進行網路資源整合,如微軟的Windows Server 2003,其背後的運作原理則是透過Active Directory(AD)來進行管理,而AD其實也是遵循LDAP標準所開發的商業產品,在整合上類似LDAP的帳號整理原理,不過,為了要活用Domain Controller所發出的Token,在整合上要利用微軟所製定的函式庫會較為方便

 

(3)    授權

SSO的實作方式有很多的方法,這塊領域其實也已經有很多偉人走在前面了,大多情況下我們只要追隨就可以了,最常被運用的原理就是Kerobos所提倡的方式,簡單的說明如下

 

(1)   Client輸入帳密

(2)   Server端驗證帳密(或憑證),若驗證通過,就產生一張有時限的Token1

(3)   Server端將Token1發給Client

(4)   Client取得Token1後進入特定服務,並遞交Token1給服務

(5)   服務端將Token 1轉交給原發行端,確認Token1 是否合法

(6)   原發行端驗證Token1後,認定合法,透過發出Token2通知服務端該使用者合法身份

 

至於服務端該怎麼決定授權的範圍,在實作上有三種作法,

第一種作法

採用中央集權式的作法,由驗證端在Token2告之服務端其使用者權限

                        第二種作法

採用分權式作法,在Token2上面沒有告之服務授權的範圍,僅說明使用者身份為何,由服務自行授權

                        第三種作法

混合式做法,採用分層授權的作法,驗證端決定是否可以使用此服務,而服務端再決定其更細的功能項目。

 

理論上,第一種作法是最好的作法,因為只須要維持一份的資料就可以了,但實務上,第二及第三種作法反而最常被採用,因為常常需要整合的是已存在的Legacy System,其多半都有自身的權限設計了,如果採用第一種的作法就需要修改所有系統的權限設定,容易造成系統風險與成本的提高,有時甚至造成原系統維護者的抗議,惹來政治上的風暴。

 

Token 1的存續時間

另一個重要議題是,Token1的存續時間,剛剛已經提到,Token2必需由Token1驗證後產生,理論上,只要有Token1我們就可以完成單一簽入的任務,但基於安全的考量,Token1往往是有時限的,並且用過一次就丟了,在這種情況下,Token1的存續時間就很重要,在設計上,建議是在每一頁Page_Load的時候,都通知驗證端拉長Token 1的有效期限,不過,這樣的作法有時候會受到來自於已存系統維護者的反彈,因為他們修改幅度會變大,有時折衷的作法就是拉長預設的Token1存續時間,並且在首頁登入時通知驗證端再加長認定時間就可以了,例如每次30min,但相反的,安全的風險也加大了。

 

重要觀念說明: 代登入不等於單一登入

另一個容易被混淆的觀念是代登入與單一登入的差別,何為單一登入在前面已經說明了,那麼為什麼代登入不等於單一登入? 舉一個簡單的例子說明

 

(1)   使用者登入入口網後,系統將使用者帳號儲存愛Session

(2)   使用點選其他網站服務,系統將儲存在Session中帳號送出

(3)   新點選的網站,收到使用者的帳號,進行權限驗證

(4)   驗證無誤後,進入該網站服務

 

看起來很類似單一登入,但我們將(2)拿出來仔細檢驗,就會發現其實這是透過AP的程式碼來達成的,像是用接力棒的方式來完成代登入,也就是說,同樣的運作設計需要分散在每一個可能的程式段落,在系統維護上將會造成極大的困擾,除此之外,如果透過 我的最愛等方式直接跳頁,很可能無法達成單一登入的效果。

 

2.      訊息傳遞安全

說完了使用者權限的安全,SOA跟一般系統相比,另一重要的議題就是,訊息傳遞安全,一般來說我們會分兩個層級的安全角度來看

(1)    網路層級

由於網路上的封包傳遞是類似在透明通道的方式進行,為了提高安全其中的一種方式,就是將訊息包在不透明的容器中,然後在透明的通道中行進,這裡指的不透明的容器,就是指網路封包的加密加簽,例如HTTPS/FTPS就是最常採用的一種方式,這類方式的好處是,由於訊息封包包在網路封包內,所以,不需要經由AP去完成,只需要在網路層進行安全加密就可以了,讓程式本身專心執行業務需求,而不要再去處理瑣碎的系統安全問題。

(2)    訊息層級

訊息層級,則是針對傳遞內容本身進行加密加簽的作業,其好處是,具有不可否認性及唯一性的優點,不過,此類作法往往涉及到非對稱式加密技巧,所需的開發成本較高,並且在加解密的過程中,容易衍生效能問題,除非是重要的電子公文,一般不會主動使用此方式進行。

 

在經驗上,如果是Intranet的內部服務串聯,除了登入時會使用HTTPS來確定帳密的安全外,在訊息的傳遞上,顯少會刻意去強調內部訊息的傳遞安全性。不過,若資料有向外傳遞的必要性,例如電子公文,則通常會透過訊息層級加密加簽的方式,以確認該電子文件的唯一性與不可否認性。

 

3.      服務使用安全

這裡所提的服務指的是網路上的各式服務,但並非所有人都可以使用所有的服務,例如,一般使用者可能就無法取得公司財務系統內的資料。這在設計上,就需要在服務的利用項目上進行安全控管,在實務上也有三種的方式來進行

(1)    AP層級

此類方式,衍生自現行許多系統的作法,最簡單作法是透過設定IP address的方式來決定,什麼服務可以被什麼外部系統所呼叫,這類方式的好處是易於實作,但安全性則遠不如下述的另兩種方式,適用在內部系統的服務整合。

(2)    User 層級

在傳遞的資料中,存有使用者的帳號資料(例如Token1),而使用者資料可在ESB或被呼叫的服務中進行使用者權限的檢查,確認該使用者是否有權使用特定的服務。

(3)    資料 層級

這類做法是透過加密加簽的方式來確定資料與使用者的正確性,屬於最嚴謹的認定方式,但過去的經驗是覺得雖然嚴謹但是效能不好,比較適用到有對外服務的重要資料,如政府具有法律效力的電子公文。

創作者介紹

Min's Web Life: 談網路產業研究與生活閒聊

miin1130 發表在 痞客邦 PIXNET 留言(0) 人氣()