https://newera17031.activehosted.com/index.php?action=social&chash=ba1b3eba322eab5d895aa3023fe78b9c.2767&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=ba1b3eba322eab5d895aa3023fe78b9c.2767&nosocial=1

觀點

Web Service建置與營運上的安全問題

2005 / 09 / 05
王婉伶
Web Service建置與營運上的安全問題

「美美!我們的網頁被放入木馬程式了!」當公司的MIS接獲這樣的消息,如臨大敵般,首先針對該網頁所在伺服器進行掃毒,果然『中獎』了!後來,在經由專家的指導告知,當務之急是找出還有沒有其他電腦受害,MIS花了許多的時間掃瞄了全公司上上下下加起來共五、六十部的個人電腦及伺服器,幸運的是並無禍及其它!

在處理的過程中,找出了被駭的原因,原來是網頁在撰寫之初便有漏洞,而且也知道該漏洞,但因公司未有原始程式碼,而當初的開發人員沒有時間對該程式加以修改,以致於才會造成這次事件的發生!經由這次事件公司很快的修改了程式碼的漏洞,並在該伺服器安裝上個人防火牆及IIS Lock等防護機制。專家並建議必須將中毒前與中毒後的log一行行做比對,以得知駭客究竟動了什麼手腳!方能完整地確保整個後端應用程式的安全。

看到上述的事件,web services提供者一定心有戚戚焉!網路活動的活絡,讓web services更加的蓬勃發展,舉凡網路銀行、電子商務等服務越來越普及,但隨之而來的攻擊事件及安全事件也日益增多。安全事件的發生,除了使用者蒙受損失外,其實最大的受害者當屬web services的提供者,然而究竟具備怎樣條件的網頁服務才是值得使用者信賴的?web services的提供者又該注意那些安全細節?

web services開發安全注意要項
●從管理面著手
應用程式開發前、開發中到最後驗收的階段,web services提供者在管理面上應該要注意那些項目?

進行應用程式開發通常區分為自行開發及委外開發,安永管理顧問公司企業風險管理部專案經理李永強表示,當我們要委外開發時,在開發之前,通常服務提供者會先進行招標,而在招標委外的應用程式開發商時必須注意:
1.廠商資格──如,程式開發商是否為合法的公司、是否具備有相關的程式開發經驗及是否有相關的認證資格(如CMMI)。
2.通過安全驗證──如,程式開發商是否有通過任何安全驗證(如BS7799)。
3.對於開發小組資格的要求──例如,1.開發小組必須具備有專業認證資格(如,CISP等);2.如果委託單位為政府機構,可能會要求開發小組內不得有大陸地區人士;3.開發小組最近一年的流動率(如流動率不大於25%),但如果開發小組為第一次組成,就無法適用此條件;4.簽訂保密條款或契約。

而委託商在委外開發web services應用程式之前,對於承接的廠商資格及開發人員的資格應做好事先的篩選及規範,如此就能避免一些委託商無法掌控的問題。且在開發前,委託商可以要求開發商在開發階段做好開發的風險評估及開發風險確認,第二要做衝擊分析及規畫反應措施,即若發生狀況或衝擊時立即有應變的措施;第三則是對於所有的程式進行預計效能的設定;其他諸如,是否能提出開發的管控機制、確認是否與委託商的安控機制是否一致等。針對開發人員,必須確認其是否能熟悉委託商的開發規範,最後,開發人員對於其專案系統、網路架構環境也要有足夠的了解。

●開發中至驗收階段
開發中階段,應對於整個程式碼開發的過程非常重視,其中包含原始碼的保存、設計及版本控制(如CVS)等,都要有適當的管控措施。另外,對於測試的資料要做隔離的控管,這部份便和安控機制有關,譬如,真實的資料在何種情況下可能拿來做測試,而測試之前必須把一些機敏性的資料欄位刪除,但是,最理想的方式還是虛擬測試資料是非利用真實資料。第三,要確認及管控相關程式開發人員不得將所開發的程式碼帶離開發區;有些程式開發員習慣會將程式碼帶回家撰寫,或利用遠端登錄的方式來撰寫,如此對於程式碼的安全性會難以管控。

另外,還有關於專案的評估規畫,在不同的時程要擬定不同的評估計畫,要能把每個階段的弱點及遭遇的風險鑑別出來,再訂出一些相對應的應變措施。

上面所提到是在開發中階段必須要注意的項目,而對自行開發的廠商來說,同樣可以適用,而且更容易被要求,不論是單位約聘人員,或是委外駐點人員,理論上會比委外人員更容易規範,因為這些人員已將一些對委外人員較難以約束的部份去除,例如,BS7799要求開發人員的開發環境,建議最好是一實體隔離的環境,以避免原始碼在開發環境中被洩露出去。而這一部份從委外的角度來看,除非能時常對委外廠商做稽核,即定時或不定時的到委外廠商去看其開發環境,否則還是有掌控上的困難。

最後的驗收階段,基本上也是依照當初所訂定的要求,如,一開始對廠商人員資格的要求,及對於開發前、開發中的評估工作,即之前人員評估及風險評估都遵照規畫,驗收時,完全根據之前所提之要求及契約條款來做覆核及驗證。

●從技術面來看
關於技術面,牽扯到委託商是否具備有能力執行,李永強建議,一般而言,對於自行開發的廠商來說,能在一開始便對其開發人員做安全教育訓練,其中包含安全指導方針概念的建立,在開發的過程中就能避免很多不必要的問題,而安全指導方針包含項目如,輸出有效性的確認、失敗安全的確認,即當網頁連結時,若連結不上會出現404的錯誤訊息網頁,而此網頁可能會透露出該網站的相關設定,其實理論上該錯誤訊息應該將其導流到統一的頁面(如web services提供者自行設計的錯誤頁面),避免一些重要的訊息藉由該錯誤頁面流出。另外,對於相關使用元件的管控、特殊權限的管控及區隔,都要在規畫設計時,希望程式設計師都應該要注意到。

李永強認為,從網頁設計的角度來看,一般來說要處理的面向很多,除了安全指導方針外,開發人員應具備有一般常識及概念,如果開發人員不具備有安全概念,則難保其開發出來的應用程式會沒有問題。

除了以上的問題,還要注意架構的安全性,此部份往往牽扯到網路架構及作業系統的安全性,因為web services是架構在網路中的某台伺服器中運行,倘若作業系統的安全性管控不夠嚴謹,則架設在上頭的應用程式當然會有安全上的疑慮,而網路架構同樣也會面臨相同的情況。其它諸如身份認證的機制,身份認證的種類包含數位憑證、SSL傳輸加密機制、實體的身份認證(Smart Card、晶片卡)到最近的生物辨示技術等。

當資安事件發生時
李永強表示,現階段來看,當資安事件發生時,處理的第一步最好是立即將有問題伺服器施行實體隔離措施,但web Services提供者必須謹慎考量,服務中斷所造成的衝擊組織是否可以承受?如,當web services遭受到攻擊,經評估後可能得花1~2個小時來恢復正常,此時組織就必須評估出,暫停服務之後所帶來的影響及損失組織可否承擔。

另外還有一種情形是組織知道自己的web services出現問題,但卻又無法掌握問題在那?如,應用程式本身先天不良,在開發之初便有漏洞,因此這就必須要去修改程式本身的問題,這樣的事件在開始之初實很難估算出復原的時間。

然而,倘若發生透過本網站去攻擊其他網站或IP的跳板式攻擊時,此時除非本身有辦法察覺出被利用的漏洞為何,否則很難應變,除非能在問題發生時立刻將其從實體網路上移開,然而這樣的作法對於現在的電子商務來說並不聰明,因為電子商務所標榜的就7X24的服務,如果讓使用者無法使用該服務,可能會錯認該網站停止服務了而造成企業損失。


對使用者的安全叮嚀
去年底某銀行爆發一網路釣魚事件,駭客先寄出一封假郵件通知用戶更新帳號密碼,並附上連結到一與該銀行相似之網頁,誘騙用戶上網登錄帳號密碼,以取得用戶個人資料,事後該銀行雖已追查出來源,但已有不少客戶蒙受損失。

像這樣的網路釣魚事件越來越多,且手法也日趨複雜,在此建議使用者在收到這樣的郵件時,若無法確認其資訊正確與否,切記不要直接點選該信中所附的URL,應自行開新網頁重新打上該銀行的網址進行連結,另外,也不要輕信搜尋引擎搜尋出來的結果,很有可能也是冒名的假網頁。

另外,當使用者在進行網路交易服務時,可點選網頁右下角「鎖」的小圖示,可出現該網站的經由安全認證授權相關資訊,確定該網站與被授權的網站為同一個。

若使用者無法避免的要使用網頁服務時,李永強建議,使用者應該對自己的資產做好風險評鑑,在填寫個人資料時自認重要不可外洩的儘量不要登錄,例如地址可填寫公司地址;儘量不填寫家裏電話號碼,以手機號碼代替等。

結論
網路是一開放的環境,除非不使用web services,否則很難避免安全事件的發生,然而許多web services的問題都是來自於後端應用程式的問題,因此若要減少安全事件的發生,就要從根本做起。

目前對於程式開發的安全性及成熟度有一些認證機制,然而走安全性的程式開發商很少,多半著重在軟體成熟度上,如CMMI的驗證,對於程式開發的過程都有嚴謹的規範,其主要是確認程式的完整度及邏輯性是沒有問題的,但仍無法完整的涵蓋到所有的安全範圍。

所以除了開發人員必須具備有資安意識外,web services提供者也要執行最嚴謹的管控措施,以確保應用程式的安全性。再配合上其他外部的安全防護措施(如,防火牆、IDS、IPS等),方能提供使用者安心的web services環境。