前言
在2010年初，文茜的世界財經周報專訪了工研院雲端運算中心主任，談到了台灣雲端運算及貨櫃型電腦的發展，這是我在電視新聞上看到最完整有關雲端運算發展的報導。訪談中闕主任提到，台灣有硬體研發製造的優勢，除了較保守的進可攻退可守的雲端運算發展的一條路(雲端硬體)外，希望台灣不只是有「退可守」的心態，真的有一天能發展出幾個很厲害的雲端軟體公司。節目中亦報導了鴻海董事長郭台銘及廣達電腦董事長林百里對雲端運算發展的企圖心。

雲端運算架構框架
在討論雲端運算的安全課題之前，我們還是先來看看甚麼是雲端運算(Cloud Computing)。Cloud Computing一般來說可以廣義的描述成使用一堆服務、應用程式、網路、運算、儲存及基礎架構的資源讓消費端或提供者可以視需要增加或減少甚至停止資源的使用，提供隨需運算(on-demand computing)的供給與消費模式。如果要用更系統化的方式來描述Cloud的組成，我採用NIST對Cloud Computing的定義: Cloud有五個必要的特色、三種雲端服務模式與四種雲端部署模式述，如圖一所示。這五個特色可以用來對比與區別出與傳統的運算模式的不同處。

1. On-demand self-service

使用者可以不需藉助service providers，根據自身需要自動地增加或減少運算資源，也就是隨需運算(on-demand computing)。例如provisioning你的伺服器運作時間及儲存容量大小等。可以把它看成是Utility Computing的服務模式，就是pay-as-you-go，用多少付多少的意思，跟你在付水電費的情形差不多意思。

1. Broad and high-speed network access

Service的provisioning可從網路連線進行，並且可以允許從不同的clients端存取，例如手機、筆記型電腦與PDA等，通常是使用瀏覽器。

1. Resource pooling

資源多人共享(multi-tenancy)，視需要對資源(physical或virtual)做動態的配置。對所配置的資源的所在處，消費端僅可以有某種程度的的控制。例如，因為法規遵從的原因使消費端想知道資料儲存在已知的某地或某data center裏。

1. Rapid elasticity

網路、儲存及運算的資源可以快速且彈性的配置，包括在共享的虛擬架構中對資源的動態配置，例如暫時不需多餘運算的使用者資源可供需要較多運算資源的使用者使用。

1. Measured services

服務及資源必須可以被monitored及reported，提供資源使用的最佳化。

圖一 - NIST雲端虛擬模型

Cloud的三個基本的service models又稱SPI model，分別為Software as a Service (SaaS)、Platform as a Service (PaaS)及Infrastructure as a Service (IaaS)。SaaS是由providers提供雲端上的軟體應用程式供consumer使用，consumer使用如web browser存取這些資源，但consumer對這些軟體應用程式並無控制權，他們是由providers負責管理與設定。PaaS讓consumer可以使用provider的API開發自己的應用程式並部署在provider的cloud上，除開發的應用程式外，consumer亦無法對cloud裏的運算資源如網路、作業系統、儲存設備及Infrastructure等有直接的控制權。IaaS使consumer可以利用諸如瀏覽器等來provision自己的網路或儲存等運算資源及部署開發的系統在cloud上，甚至可以管理轄下的防火牆設定。

Cloud的四個部署模式為私有雲(private cloud)、公共雲(public cloud)、社群雲(community cloud)及混合雲(hybrid cloud)。Public cloud是由service providers經營並提供給public使用，Private cloud是企業自己經營管理而且其雲端設備通常是在企業端(on-premises)，但也可在service provider端(off-premises), 例如企業的private cloud可以經由IPSec VPN與Amazon AWS的VPC(Virtual Private Cloud)相連接，如圖二所示。

圖二-Amazon AWS VPC

Community cloud則是具相同商業型式、相同安全需求或相同法規遵循需求的許多單位所共同組成。Hybrid cloud則是混合以上三種clouds型態，有高度的資料與應用服務的可攜性，並可支援cloud的load balance與互通。了解SPI的Delivery model對了解cloud的安全風險有非常大的幫助，因為不同的service model與deployment model對consumer與service provider都有不同層次的影響。就cloud的框架而言，IaaS是cloud的其他model的基礎，PaaS架構在IaaS上而SaaS架構上PaaS上，因此簡言之，它們之間的安全風險存在一些trade-off關係，例如說SaaS的security主要是由service provider負責，PaaS對consumer來說必須自行負責一些安全風險問題而IaaS則是由consumer負責絕大部份的安全風險問題。以Amazon AWS的EC2來說，service provider必須負責的security control包括實體安全及Hypervisor安全等，而consumer必須負責的security control則包括作業系統、應用程式及資料的安全; 而Salesforce.com的CRM SaaS service則由service provider負責絕大多數的security controls。

雲端運算安全問題的深入探討
傳統的IT環境有比較明確的網路邊界但對cloud來說這個界限是很虛擬的，當企業把運算資源移到cloud時(特別是public cloud)因為運算資源移到cloud裏，所以資安風險的問題就必須由雙方依據所採用的service model來分擔資安權責; cloud中敏感的資料(如財務資料或個人資料)要如何保護? 由誰保護? 相關的法規遵循問題如何在從傳統的IT標準如ISO/IEC 27001的ISMS或ITIL的service level重新的mapping到cloud的環境中? Provider的資安治理是否對consumer而言是夠公開的?

我們可以從三種角度來談cloud的資安風險問題。首先是從cloud的三個組成層面來討論: 雲端硬體、平台與服務。這可以從三個對應的層次來探討: Network level、Host level及Application level。Cloud中的network level的威脅與傳統IT並無太大的不同，除了在虛擬化環境中是以虛擬的security domain來代替實體的security zone的概念，因為資源是分享而不是獨佔的概念。Host level則是因為virtual servers(VM)的概念必須強調在Hypervisor上的安全問題。Application level的安全威脅則是與傳統IT一樣無太大不同。第二是從cloud的SPI來談討不同service model對企業或個人的資安風險帶來的問題，而談這樣的資安問題是以我們之前提過的trade-off方式來對資安風險做權責的分擔，如表一所示。

表一

IaaS顧名思義因為consumer對resources有最大的控制權，所以consumer必須擔負最多的security controls與security processes。PaaS與SaaS次之。而SaaS因為是由provider來做大部分的資源的控制，所以consumer端只須負責自身特別是與瀏覽器有關的資安風險問題。第三個角度可以針對Private cloud與Public cloud的不同，其在資安管理中所扮演角色有所不同，如下所示，將service models導入到Private及Public cloud後，consumer與provider要負的資安權責就表二所示，其實很容易理解。現有的一些標準如ISO/IEC 27001及ITIL中有關security的ISMS的guideline及service level也可應用在cloud的資安管理流程中，諸如Availability管理、Access control、VPC的管理(Vulnerability、Patch and Configuration management)、事件緊急處理、電腦犯罪鑑識程序及logging、主機及網路的monitoring與auditing等等都可運用來進行cloud的資安治理(security governance)。表二就是對對以上所提的幾個在ISO/TEC 27001的security control的guideline來描述雲端安全。

表二

Cloud與傳統的IT安全問題其中一個不同點在於cloud其中一個吸引人目光的特點在於滿足規模經濟的成本效益並必須可以提供滿足廣大消費者的需求，而要將安全問題整合進這種架構虛擬及動態資源的cloud裏的確是一個比傳統IT安全更艱困些的課題。如前所述，了解各種service model及deployment model間對安全風險的衝擊是管理cloud安全風險很重要的一環; 而雲端資安治理的範疇大致上是分為兩類: 管理面及操作面的domain。管理面的domain大都跟cloud的policy及大的安全策略有關，而操作面的domain則大都跟技術的安全層面有關。操作面的domain我剛已經強調過，但雲端資安治理在管理面必須更關注以下風險問題，因為資安風險管理的最上層就是企業組織策略性的Policy。

1. 資安治理與風險管理

有效管理與量測雲端資安風險的範疇必須遵循一個良好的資安治理流程，包括了鑑別與建構良好的組織架構，從而形成一個具有PDCA特性般的資安管理計劃，，資安治理的持續性，受監控性，符合成本效益及達成企業商業目標的能力。尤其當企業IT環境從傳統IT轉移到cloud時，因為cloud的特性，傳統的風險評估方法未必適用在cloud環境，有幾點必須加以考量:

1.  
   1. Consumer因為缺乏對實體IT環境的控制，SLA(Service Level Agreement)及一些contract的問題就比傳統IT方式需要更多的關注。
   2. 因為cloud的on-demand provision跟multi-tenancy特性，傳統的稽核手段可能需要修正，例如，service provider可能不允許你對他的網路進行弱點掃瞄(Vulnerability scan)及滲透測試(Penetration test)。Service provider也可能限制有關你對網路及Log的monitor方式與程度。如果你企業的資安管理計劃必須要使用這些傳統IT稽核與監控的方法，你可能需與service provider就這部份進行討論與contract，必要時可當成選擇cloud服務供應商的依據。

1.  
   1. 所有轉移到cloud的重要的商業功能必須重新做資安風險評鑑，包括資產的鑑別與資產價值，威脅與弱點分析及對資產造成的衝擊等。

1.  
   1. Consumer與service provider的風險評鑑方法儘可能的取得一致，可以真實客觀的對資產，弱點與威脅及衝擊衡量出實際的風險。

1. 資料揭露與法律問題

Consumer與service provider雙方必須了解彼此的責任與角色，包括訴訟或證據提供等問題。服務供應商也必須確保資料在移動時資料保管(Data custody)的責任與有效性。另外，有關contract的中斷或結束關於資料的銷毀與保存或移轉問題也必須加以考量。Consumer在面對法規遵循的問題時最好是與service provider訂定contract，提供或限定明確的資料儲存位置以滿足法規規範需求。

1. 法規遵循與稽核

之前提過的cloud的特性再加上多數法規是在cloud之前設計出來的，都使得consumer對於法規遵循問題變的更複雜些; 當企業把資料從傳統的IT環境移到cloud後，部份牽涉的商業流程或Policy及Procedure都可能要重新檢視與變更或重做風險評鑑等。除了不同service model有不同的安全考量與權責外，consumer也應與企業的法規部門討論是否必須在與service provider的contract中明定諸如data retention，incident response及logging及monitoring等特定的requirement，包括部份法規明定但無法在cloud中達成的部份要特別釐清。例如歐盟(Europe Union)對電子病歷資料的儲存地點就有明確的在地理上的限制。

1. 資料安全生命週期

今天在文章講的各種security的風險與考量其實說穿了不就是要以保護cloud中的data為最重要嗎? 在cloud中談data security就必須全面的從資料的產生(creation)、儲存(store)、使用(use)、歸檔(archive)及銷毀(destroy)來考量。資料產生必須對資料分類分級(Classification)，根據security policy賦與access rights，資料儲存必須考慮到儲存地點，有嚴格的存取控制與數位版權管理(DRM)甚至到加密的需求; 資料在傳輸(data in transit)或使用時也須考慮到存取控制與數位版權管理及必要的monitoring及logging。存取資料的應用程式亦須保護，包括安全的開發應用程式與其他應用程式安全的控制措施。因為cloud的multi-tenancy特性，資料的共享須考慮到DLP問題甚至是DBMS的推論與聚合攻擊(inference and aggregation)。資料歸檔與備份則須考量加密與儲存媒體的安全，亦包括data custody的合規與適法性; 資料在使用完畢的銷毀與資料剩餘(data remanance)問題有必須清楚的在contract或SLA中載明如發生資料被竊或毀損時的歸責問題。

1. Web 2.0資料安全保護策略

除應用軟體架構與SDLC外，必須再考慮從以下幾個應用安全面向來探討: 未經驗證的輸入(Unvalidated Input)——沒有對輸入資料進行檢查，這是一種常見的coding錯誤。未經驗證的輸入是造成大多數Web應用程式安全漏洞的根本原因。 最近出現的有關SOAP的attacks就是利用XML中的CDATA來崁入類似XSS攻擊的資料而造成對目標主機的非授權存取或甚至至DoS攻擊。XML Attacks中所謂的Coercive Parsing就是利用XML Parser在剖析XML文件時被刻意設計的Meta Tag搞混，造成為迴圈產生DoS攻擊的效應。存取控制不完善(Broken Access Control)——允許輸入某些token可能會使一個攻擊繞過這些授權認證控制機制。用於認證及授權用戶的各種限制條件被不適當地使用。攻擊者可以利用這些漏洞存取其它用戶的帳戶，偷看敏感文件或者使用非經授權的功能。認證和會話管理不完善(Broken Authentication and Session Management)——設計強大的存取控制還不夠。還必須要可以安全地管理密碼、會話期間的token、帳戶資訊和任何其它可能為攻擊者提供足夠訊息的管道，從而破壞安全控制的資訊。跨站攻擊弱點 （XSS）(Cross-Site Script Flaws)——XSS是一個常見的攻擊。一旦一個攻擊script被植入到一個伺服器網頁或其它經常被存取的Web resource中，它會在存取這個網站資源的Client端電腦中執行。理所當然會危及到用戶端設備的安全。緩衝區溢位(Buffer Overflow)——在使用低階語言，如C語言時，程式開發者的一個常見錯誤就可能引起緩衝區溢出。如沒有檢查輸入邊界來保護分配的記憶體空間。 在某些情況下，攻擊者往往能控制一個程式進而取得程式的執行權限。這些程式元件可能包括CGI程式、程式庫、驅動程序和網路應用等伺服器元件。注入錯誤(Injection Flaw)——不針對使用者輸入做過濾可能造成對資料庫或系統文件的未授權存取。Command Injection跟XML中的XPath Injection及XQuery Injection也是屬於這類攻擊。錯誤訊息處理不當(Improper Error Handling)——正常情況下，發生錯誤時應該提供錯誤訊息通知用戶。但是提供過多訊息可能幫助攻擊者track一個攻擊目標例如database的tables及database connections。以SOAP來說，Web services的response訊息可能會洩露出server端所使用的Parser，一旦此parser有弱點被公佈，攻擊者便獲得更多可利用來攻擊的管道。不安全的儲存(Insecure Storage)——對密碼、帳戶資訊和其它與應用程式session data及cookie有關的資訊進行加密是最好的方法，否則極易被駭客利用來收集或竄改重要變數及資訊。拒絕服務(Denial of Service)——如同網路的拒絕服務（DoS）一樣，應用程式的DoS是指未授權用戶或非法使用應用程式資源，造成授權用戶無法工作。XML document先天就具有nesting的特性，因此容易被利用來做DoS攻擊。一些DOM-based的XML Parser因為須把整個XML的architecture放進stack中做parsing，因此oversized的XML document更容易被駭客利用來做DoS攻擊。設定管理不當(Insecure Configuration Management)——設定管理不當可能讓駭客有可趁之機，有效地設定管理能夠對Web應用程式和主機(包括應用程式伺服器，網頁伺服器及資料庫等)進行加固(Hardening)。再以Web services為例，Web services的WDSL是負責如何使用所有服務的定義及介面，設定不當會引起資訊被揭露而被駭客利用來進行攻擊。下圖是NIST的SDLC闡明在開發階段的因應策略。

1. 可攜性與互通性: 目前並沒有關於cloud Interoperability的標準被遵循，所以consumer在選擇cloud providers時需特別把有關營運中斷或服務中斷甚至包括資料及架構轉移難易度的情況考量進去。

Amazon AWS在Security的著墨
Amazon AWS旨在提供一個高可用度及高彈性的雲端運算平台供使用者開發多樣的雲端應用程式與系統並保證使用者在此雲端平台上的資料可以達成資料上AIC上的保護 - 即資料的機密性(Confidentiality)、資料的完整性(Integrity)及資料的可用性(Availability)。底下我藉由Amazon AWS的security process來闡述一下Amazon AWS在security上的措施如何保護雲端使用者的安全。

1. 安全認證

Amazon AWS通過SAS70(Statement on Auditing Standard No.70)的Type II稽核，SAS70是一個廣泛使用在服務供應商或單位(service organization)的稽核的標準，表示服務供應商與單位對於資安控制措施與目標(security control activities and objectives)達到安全的標準。

1. 安全設計原則

Amazon AWS的系統開發是依照SDLC的安全開發流程並結果程式碼靜態分析技術確保系統設計的安全，除依照威脅分析模型進行風險評鑑外，亦經由專業的滲透測試驗證與review。

1. 實體安全

Amazon的data center的實際地點所在並未公開，實體安全包括門禁、監視系統與雙因素驗證等，凡是有機會接觸到內部設備或客戶資料的人員都必須經過縝密的身份驗證。所有存取及進出記錄都有logging並接受定期稽核。

1. 備份

儲存在Amazon AWS中的資料(例如Amazon S3及Amazon SimpleDB與EBS等)皆有備份在不同data center以確保資料運作的高可靠性。Amazon EC2的Availability Zone可對EC2上的instance及data提供redundancy。

1. 網路安全

Amazon AWS的網路安全可提供對DDoS、MITM及IP Spoofing等的保護，網路架構及網路層的安全是由設計Amazon網路書店等級的網路安全專家所設計。Amazon的AMI instance不管是進行管理設定或連線時都有視情況使用SSL及SSH與憑證做加密與認證方面的保護。

1. 針對客戶端所需自己負責的安全性問題，Amazon AWS的security guide也提供一些best practice與hardening的建議給客戶對所管理的主機系統做防護。例如要求所以的OS的instance必須符合最低的baseline要求，必須修補漏洞，關掉不必要的服務，制定密碼政策，安裝Host IPS及防毒軟體，使用檔案加密及加密的連線，啟動稽核機制，不安裝不必要的套件，刪掉不必要的帳號，使用log server收集所有設備存去記錄等等。

1. Amazon EC2提供為因應虛擬化平台的防火牆功能給客戶根據需求設定存取規則，預設是deny all並由客戶經由API自行管理。在虛擬化世界是使用security domain來取代傳統IT的實體security zone概念，security domain可以以group來設定存取規則並使用如以往以IP及Port來限定外對內或虛擬環境下的存取。

結論
企業在思考從傳統IT環境或data center轉移到雲端運算前必須先考慮自身是否合適雲端運算的導入，尤其是對於導入雲端運算所衍生的資安風險問題。導入雲端運算架構亦需考慮包括資安治理，資安政策與法規遵循等的問題; 尤其是將傳統IT環境轉移到public cloud時除了要了解提供services的provider的安全策略及安全風險的權責外，對於必須由自身負責的安全風險問題也要全盤考量。所謂security is not an one-size-fits-all solution，經由正確且有效的風險評鑑過程分析後對風險進行mitigation，建立符合成本效益的資安控制措施及策略目標才能完全的治理cloud所帶來的安全風險。

參考資料
http://csrc.nist.gov/groups/SNS/cloud-computing/
http://www.cloudsecurityalliance.org
http://aws.amazon.com

(作者現任職於麟瑞科技)