本文將會對雲端的安全議題做一概覽性的介紹,因為雲端運算會涉及的安全議題多且廣,所以無法太細部的介紹,如果對某些議題有興趣,可參考相關的資訊安全書籍。
雲端上的安全性(Cloud Security)在近年來雲端運算進入主流市場後就不斷的被提出討論,想見這個議題的重要性,雖然各大雲端供應商都有提出確保服務可用性的SLA,但卻沒有明確的提出雲端上執行應用程式與資料儲存的安全保障(即便有提出最佳範例或配套措施),但是他們都宣稱已經盡力使用開放式的協定來保護雲端運算的平台,簡單的說,安全性的球就被丟到開發人員手上了,然而雲端運算的安全性應該是雲端平台供應商和開發人員要共同努力的,甚至是雲端運算的整個產業鍊(由硬體、網路、平台、軟體以及安全協定等等)都要一起努力,才能將雲端運算的安全顧慮降到最低。
早在雲端運算剛開始浮現的2008年七月,國外的IT研究機構Gartner就發表了一份關於雲端運算的安全風險,包含七大安全議題:
- 特權使用者的管理(Privileged User Access):在雲端供應商的資料中心內,除了平台內的中控系統的自治功能以外,仍然需要一小部份的人力(進行監控、硬體管理與故障硬體替換等自治系統無法做到的事情)來管理資料中心內所有的硬體設備,這些人力通常都會持有系統的特權(最高權限)帳戶,這些帳戶因為對系統擁有絕對的權力,所以在使用上必須經過嚴格的管制(例如合理的授權或不賦與權責以外的權力)。。
- 遵守法規(Regulatory Compliance):分為雲端供應商與用戶兩個部份,雲端供應商在建設資料中心時應符合當地的法規,而用戶也要負起使用雲端供應商資源時應該要遵守的法規,例如著作權、隱私權與個人資料保護等相關法規。
- 資料所在的位置(Data Location):與前一個議題很像,因為資料中心是分散在全球各地,當資料中心是在一個隱私權規定或是輸出規定嚴格的國家時,則資料與服務的供應要依當地法規的規定為主,若是在禁止輸出資料到他國的國家中建置資料中心時,則該資料中心可能就只能服務當地的用戶。
- 資料的隔離(Data Segregation):雲端供應商幾乎都會使用多租戶技術(Multi-tenancy Technologies)將資源依用戶需求切割給用戶使用,若運算資源與資料的隔離性太差或是有漏洞時,可能會有資料外洩的顧慮發生。
- 回復能力(Recovery):這是雲端供應商所重視的特性,所有的SLA(服務水準合約)都會制訂最低的服務可用水準,雲端供應商所設計的架構基本上都要符合SLA水準,但仍然無法確保100%服務不中斷,服務有可能會因為天災的因素而被迫中斷,例如2003年發生的美東大停電或是2006年台灣恆春大地震發生的海纜被震斷的事件,都有中斷服務的可能。而在事件發生時,將服務在短時間內回復的能力就是雲端供應商要持續重視的。
- 支援調查的能力(Investigation Support):雲端供應商的資源被許多的用戶所租用,由於無法保證所有的用戶都是善良的(即使99.999..%的用戶都是善良使用者),雲端供應商應該要有充份的記錄或是資源可支援當事件發生時的後續追踪或調查。
- 永續的使用性(Long-Term Viability):雲端供應商提供海量的服務給用戶,但無法保證雲端供應商會永續存在(即便現在有能力提供雲端服務的供應商都是國際大廠),當雲端供應商無力提供服務時,是否可以平順的轉移或是將資料完整的交還給用戶,對用戶來說就十分重要了。
因此雲端運算的安全議題絕不是止於某些範圍,舉凡硬體、系統軟體、平台、應用軟體、網路、開發乃至於人,都可列入雲端運算的安全議題之內,所以筆者會以Top-down的方式大略介紹目前各界為雲端運算安全所做的努力。
最頂層是我們平常看到的Internet代表圖:雲,它代表者在裡面是非常複雜的網路與基礎建設的部署架構,一般我們所說的雲端運算就是由這些複雜的基礎建設供應的,而雲端運算供應商之間當然也會相互連結,如果雲端應用是涵蓋整個產業的話,甚至會有產業的社群聯盟雲(Community Cloud)的情況出現,為了要能夠在不同的雲之間(例如Windows Azure、Amazon EC2或Google App Engine等)可以進行安全的通訊與資料交換,各產業會在不同的平台主要供應商的協助下制訂不同的安全性交換協定,而各雲端供應商基本上都會合作並制訂雲端服務的基本規範。以安全性規範來說,2008年由ISACA(國際電腦稽核協會)發起,二十餘間廠商參與,創設了雲端運算安全聯盟(Cloud Security Alliance; CSA),隨後各主要的雲端供應商(硬體、平台與資訊安全等)也加入了這個聯盟,為制訂與維護雲端運算的安全協定而努力。CSA將雲端運算劃分為十一個專業知識領域。
CSA在成立以後,制訂了像是雲端平台的關鍵區(Key Areas of Focus)安全指南、應用程式安全設計等白皮書,而在2010年3月份,CSA發表了雲端運算的七大安全威脅。
除了由CSA制訂的雲端安全標準以外,主要會利用IT進行資訊流通的產業都會制訂資訊交換的標準,例如HIPAA或Rosetta Net或ebXML等標準,這些標準都會包含像是利用SSL或VPN傳輸、憑證應用與加解密等工作,這些都是在資訊流通時保障資訊安全的主要技術。
在基礎建設(Infrastructure)層次,可以分為資料中心的安全管制、硬體及網路幾個面向來看。雲端供應商在資料中心內,都會在重要的地方設置人員識別系統,配合智慧卡與門禁系統(Identity System)管制人員進出,自治系統內也會記錄人員的操作,以確保人員的作業沒有影響到資料中心與雲端平台的運作,伺服器的實體安全會透過門禁系統以及機櫃鎖來管制。資料中心內伺服器運行的溫度也是雲端供應商所重視的,維持資料中心內的溫度不過熱,可保障伺服器不會因為過熱而當機,冷房系統(Cooling System)就是資料中心的必備設施,而在可降溫的河畔邊建設資料中心,利用水冷的方式降溫也是雲端供應商的冷却方式之一,透過水冷或氣冷方式降溫,伺服器可以在維持一定的溫度以下,可以防止熱當或不穩定的現象。
為了維持資料中心的運作以保障雲端供應商的SLA規範,一個服務應用程式通常都會切割成數份儲存到不同VLAN的虛擬機器內,除非VLAN核心的網路硬體故障,否則要同時讓三個VLAN故障的機率很低,況且資料中心內的網路節點都會以HA的要求來設計,通常都是Redundant Deployment(重覆配置)的作法。維運人員在大多數的情況下都不會自己執行伺服器上的系統管理工作,舉凡是修補檔(Patches)部署或是系統設定等大部份系統管理的工作,自治系統都會自動執行,以確保不會因為人員管理失當而產生資訊安全的風險。即便要授與暫時的管理權限,也會按照資料中心內的管理規則來控制權限的授予,以管制人員實際在伺服器上執行工作的行為。網路的部份對內以VLAN來分割及預防廣播風暴,而對外以限制開放通訊埠的方式管制,而阻斷服務攻擊(Denied of Service)以及其衍生的分散式阻絕服務攻擊(Distributed Denied of Service)一向是主機商的大敵,雲端供應商也不例外,目前大多數的服務供應商都是利用切斷異常流量方式(如將被攻擊的主機所在的網段切斷或是直接將主機中斷)讓阻斷服務攻擊不致於影響所有的用戶。
平台層(Platform)的部份則是集中在作業系統維運、安全傳輸、存取控制與資料保全等方向探討,這些在很多系統管理的書中都有提,筆者就不多加探討,但其中比較需要提醒的是,提供PaaS服務的雲端供應商,多半不提供備份服務(Backup Service),這點不論您是使用哪一家的雲端PaaS平台服務,可能都要自行處理這個部份,資料是企業的命脈所在,備份是IT每天必要的工作之一,當您的應用程式上到雲端後,可以思考在企業內額外放置一台伺服器,每天進行資料庫的同步化,或是在雲端中多放置處理備份的程式,以確保資料是有備份的,勤備份對企業來說也是個無形的保障。
軟體層(Software)則是將目光轉移到開發人員身上,如果開發人員寫出的軟體有安全漏洞,那就算基礎建設和平台再怎麼安全都沒用,因此運行在雲端供應商的PaaS平台服務上的軟體安全,是軟體開發人員的責任,除了由平台所提供的基礎安全性外,開發人員應該要以資訊安全為首要考量,並且參考由雲端供應商提供或是一般資訊安全的最佳實務指南(Best Practices)來設計應用程式,也可以進一步參考安全性軟體開發生命週期(Security Software Development Lifecycle)與資訊安全組織所制訂的資訊安全指南來設計,確保應用程式不會被駭客攻擊而造成資料被破壞或外洩,尤其是要以多租戶技術開發的應用程式,更要確保資料存取不會被未授權的使用者存取。請務必記住一件事,想要靠開發資訊應用服務來賺錢的話,客戶的資料隱私務必要擺在第一位,同時不要信任使用者所輸入的資料都會照您的預期,這樣至少可以讓您的應用程式不會因為使用者輸入的惡意指令而發生問題。像是OWASP公布的十大Web安全漏洞的SQL Injection就是許多開發人員會犯的安全漏洞之一,但只要維持良好的習慣,這些漏洞基本上很難找上門。
最後,雲端運算的資訊安全,需要整個產業鏈的每一個角色的合作,才有可能將安全做到最好,否則只要有一個環節出錯,整個安全的機制有可能會立即崩潰,導致不可收拾的嚴重後果。
Reference:
https://cloudsecurityalliance.org/
https://www.owasp.org/index.php/Main_Page
http://msdn.microsoft.com/en-us/library/windowsazure/ff934690.aspx