雲端資安與隱私:企業風險應對之道
作者:Tim Mather、Shahed Lati、Subra Kumaraswam
出版日期:2012 年05 月 14 日
在本書中,你會學到在將資料託付至雲端時應注意的事項,以及要如何確保虛擬架構和網站應用程式的安全。IT人員、資訊安全與隱私從業人士、業務主管、服務供應商與投資人,都應閱讀本書,《雲端資安與隱私|企業風險應對之道》提供三位來自技術安全業界知名專家的實用建言。你可以在此找到現今仍廣泛缺乏的雲端運算安全資訊。
.檢視雲端資料安全與儲存的現況
.學習雲端服務的身份與存取管理(IAM)作法
.找出合用的安全管理架構與標準
.瞭解雲端隱私與傳統運算模型的比較
.學習雲端中的稽核與合規標準及架構
.認識「安全即服務」這種新的雲端安全面向
.學習雲端服務的身份與存取管理(IAM)作法
.找出合用的安全管理架構與標準
.瞭解雲端隱私與傳統運算模型的比較
.學習雲端中的稽核與合規標準及架構
.認識「安全即服務」這種新的雲端安全面向
作者簡介
Tim Mather
是RSA、EMC安全事業部的前副總裁與資訊策略長,以及Symantec的資訊安全長。
Subra Kumaraswamy
資訊系統安全認證專家,在昇陽電腦負責安全存取管理計畫。
Shahed Latif
是KPMG的專業顧問,負責美西地區的資訊防護與業務彈性業務。
「本書是一本重要著作,指引資訊技術人員追求對於『隨需運算』的信任。雲端勢將稱霸未來20年運算平台,需要負責雲端安全的人,必讀本書。」 —Jim Reavis,共同創始人兼執行總監,雲端安全聯盟
「隨著雲端運算的需求增加,安全與隱私會更為重要。本書分析了使用雲端運算時應考慮的的風險、趨勢與解決方案。任何嘗試引入雲端運算的人都應閱讀本書。」 —Izak Mutlu,資訊安全副總裁,Salesforce.com
「對於許多公司,引入雲端運算,是個必然的策略走向。平價運算、普遍的機動性,以及虛擬化技術帶來的優勢,創造出了更靈活的平台,以及更具成本效益的業務應用程式與IT架構。雲端引領著安全控制領域中廣泛、富創造性的應用發展,也在安全程序與管理方面提出了最佳作法的需求。本書為致力於建立雲端安全的人,提供了指引與協助,是雲端運算之旅的絕佳起點。」 —Jerry Archer,CISO,Intuit
「本書廣泛涵蓋了IT與資訊安全人員所需的詞彙與定義。本書也勾勒出基礎,讓IT與資訊安全人員可以有效合作,規劃與實作雲端運算服務。學習雲端運算安全與隱私問題時,本書為必讀。」 —David Hahn,SVP&Group資訊安全長,Wells Fargo Bank
「為瞭解雲端運算、為描述此類技術的相關安全問題,先前已有諸多嘗試。本書是最早深入探索雲端運算定義、探討現今引入此類技術時重大風險相關解決方案的著作之一。」 —David Thompson,Symante服務集團總裁,Symantec
「如今,分散式資訊的使用與管理已經成真。雲端運算為資訊使用的普及,提供了更經濟有效的暴政,但同時也放大了現有的風險,更導入了尚未發現、無從管理的新風險。本書適合每一位有興趣於瞭解雲端運算相關風險與回報,以及希望在新一波資訊管理革命中搶先擬定實用計畫的讀者。」 —Michelle Dennedy,昇陽電腦管理長,昇陽電腦
CH01|簡介 「注意間隙」
雲端運算的變革
雲端運算的變革
CH02|何謂雲端運算? 雲端運算定義
雲端運算的 SPI 架構
傳統軟體模型
雲端服務遞送模型
雲端部署模型
雲端演進的關鍵動力
永續性
雲端運算對使用者的衝擊
雲端的管理
在企業中引入雲端運算的障礙
雲端運算的 SPI 架構
傳統軟體模型
雲端服務遞送模型
雲端部署模型
雲端演進的關鍵動力
永續性
雲端運算對使用者的衝擊
雲端的管理
在企業中引入雲端運算的障礙
CH03|架構安全 架構安全:網路層
架構安全:主機層
架構安全:應用層
架構安全:主機層
架構安全:應用層
CH04|資料安全與儲存 資料安全的各方面
資料安全補救
供應商資料與其安全
資料安全補救
供應商資料與其安全
CH05|身份與存取管理 信任疆域與 IAM
為何要用 IAM?
IAM 的難題
IAM 定義
IAM 架構與作法
進入雲端的準備
雲端服務相關IAM標準與協定
雲端的 IAM 作法
雲端授權管理
合規管理的 IAM 支援
雲端服務供應商 IAM 作法
準則
為何要用 IAM?
IAM 的難題
IAM 定義
IAM 架構與作法
進入雲端的準備
雲端服務相關IAM標準與協定
雲端的 IAM 作法
雲端授權管理
合規管理的 IAM 支援
雲端服務供應商 IAM 作法
準則
CH06|雲端安全管理 安全管理標準
雲端安全管理
可用性管理
SaaS 可用性管理
PaaS 可用性管理
IaaS 可用性管理
存取控制
安全弱點、更新與設定管理
雲端安全管理
可用性管理
SaaS 可用性管理
PaaS 可用性管理
IaaS 可用性管理
存取控制
安全弱點、更新與設定管理
CH07|隱私 隱私是什麼?
資料生命週期是什麼?
雲端的主要隱私考量為何?
誰負責保護隱私?
雲端運算的隱私風險管理與合規變化
法律與條例的含意
美國法律與條例
國際法律條例
資料生命週期是什麼?
雲端的主要隱私考量為何?
誰負責保護隱私?
雲端運算的隱私風險管理與合規變化
法律與條例的含意
美國法律與條例
國際法律條例
CH08|稽核與合規 內部規則合規性
管理、風險與合規(GRC)
雲端運算的控制目標說明
CSP 特有控制目標補充
其他金鑰管理控制目標
CSP 使用者的控制考量
監管/外部合規
其他需求
雲端安全聯盟
雲端合規性稽核
管理、風險與合規(GRC)
雲端運算的控制目標說明
CSP 特有控制目標補充
其他金鑰管理控制目標
CSP 使用者的控制考量
監管/外部合規
其他需求
雲端安全聯盟
雲端合規性稽核
CH09|雲端服務供應商實例 Amazon Web Services
Google
微軟 Azure Servives Playform
Proofpoint
RightScale
Salesforce.com
Sun Open Cloud Platform
Workday
微軟 Azure Servives Playform
Proofpoint
RightScale
Salesforce.com
Sun Open Cloud Platform
Workday
CH10|安全即(雲端)服務 起源
現今的產品
現今的產品
CH11|雲端運算對企業 IT 角色的影響 為何雲端會受業務部門歡迎
使用 CSP 的潛在威脅
說明 IT 專業因雲端運算而起變化的案例
使用雲端運算時要考慮的管理要素
使用 CSP 的潛在威脅
說明 IT 專業因雲端運算而起變化的案例
使用雲端運算時要考慮的管理要素
CH12|結論與雲端的未來 分析師的預測
調查結果?
雲端運算安全
CSP 顧客的計畫準則
雲端運算安全的未來
調查結果?
雲端運算安全
CSP 顧客的計畫準則
雲端運算安全的未來
附錄A|SAS 70 報表內容範例
附錄B|SysTrust 報表內容範例
附錄C|雲端運算的開放安全架構
附錄B|SysTrust 報表內容範例
附錄C|雲端運算的開放安全架構
何謂雲端運算?
若回顧工業革命與其對於世界經濟的衝擊,你會發現,革命本身並非一夜之間突然出現,而是經歷了好幾波的浪潮。若你繼續看網際網路的演變,你會發現網際網路也是經由好幾波浪潮演變至今。雲端運算很有可能就是下一波浪潮。
雲端運算定義
我們對於雲端運算的定義,是基於五項屬性:多用戶(共用資源)、高擴充性、高彈性、隨需付費,以及自助式資源。
.多用戶(共用資源):先前的運算模型多採專用資源(例如,運算設備經常是單一用戶或物主所有),雲端運算的商業模式則是在網路層、主機層與應用層共用資源(例如,多位用戶共用相同的資源)。
.高擴充性:雖然企業組織的電腦系統可能成千上萬,雲端運算提供的能力足以擴展至成千上萬台電腦系統,以及大量的頻寬與儲存空間。
.高彈性:使用者可以視需求,隨時增減其運算資源,當不需要資源時,可以釋放資源給其他使用者。
.隨需付費:使用者僅為實際所需的資源付費,也僅在需要時付費。
.自助式資源:使用者自行啟用資源,如額外的系統(處理能力、軟體、儲存空間)與網路資源。
雲端運算的特性之一,在於資源的彈性運用。這項特性可讓用戶隨需求而增減運算資源,如圖2-1 所示。運算資源的需求底線固然重要,但預測未來的需求並不容易,尤其當需求隨時改變。雲端運算可以提供一種隨需求而分配IT 資源的方式,並找出需求尖峰。
雲端越來越受關注,因為雲端解決方案可讓使用者動用到超級電腦等級的能力,但花費僅需超級電腦的零頭。更重要的是,這些解決方案可以隨需求而動用;網路變成的雲端上的超級電腦,使用者在需要時,再付費使用即可。雲端運算利用了網際網路技術,使IT能力得以調整規模,以服務的型態供應給客戶。
雲端運算在市場上廣受注目,預料將高度成長,如圖2-2,其中標示出近來值得注意的雲端動向,以及雲端服務的預期收益。
雲端運算被預期為全球IT 消費的重要成長動力。事實上,根據IDC的資料,雲端服務的年複合成長率27%,預期在2012 年達到420 億美元。而自購IT 服務的消費額,年複合成長率預期為5%。
雲端運算的SPI架構
描述雲端運算服務的流通時,最常見的共識可以縮寫成「SPI」。這個縮寫是來自透過雲端提供的三種主要服務:軟體即服務(SaaS)、平台即服務(PaaS)與架構即服務(IaaS)。圖2-3是雲端的服務、用途與種類之間關係。雲端運算的相關技術
雲端運算其實算不上什麼新技術,因為它是由許多現存的技術組合而成。這些技術的成熟度不一,彼此關連或密或疏,而且彼此設計時並未考慮連貫性;然而,它們為雲端運算組合成了一個技術生態系統。處理器的新進展、虛擬化技術、磁碟儲存設備、寬頻網際網路,以及高速平價的伺服器,一同為雲端創造了更完美的解決方案。 若回顧工業革命與其對於世界經濟的衝擊,你會發現,革命本身並非一夜之間突然出現,而是經歷了好幾波的浪潮。若你繼續看網際網路的演變,你會發現網際網路也是經由好幾波浪潮演變至今。雲端運算很有可能就是下一波浪潮。
雲端運算定義
我們對於雲端運算的定義,是基於五項屬性:多用戶(共用資源)、高擴充性、高彈性、隨需付費,以及自助式資源。
.多用戶(共用資源):先前的運算模型多採專用資源(例如,運算設備經常是單一用戶或物主所有),雲端運算的商業模式則是在網路層、主機層與應用層共用資源(例如,多位用戶共用相同的資源)。
.高擴充性:雖然企業組織的電腦系統可能成千上萬,雲端運算提供的能力足以擴展至成千上萬台電腦系統,以及大量的頻寬與儲存空間。
.高彈性:使用者可以視需求,隨時增減其運算資源,當不需要資源時,可以釋放資源給其他使用者。
.隨需付費:使用者僅為實際所需的資源付費,也僅在需要時付費。
.自助式資源:使用者自行啟用資源,如額外的系統(處理能力、軟體、儲存空間)與網路資源。
雲端運算的特性之一,在於資源的彈性運用。這項特性可讓用戶隨需求而增減運算資源,如圖2-1 所示。運算資源的需求底線固然重要,但預測未來的需求並不容易,尤其當需求隨時改變。雲端運算可以提供一種隨需求而分配IT 資源的方式,並找出需求尖峰。
雲端越來越受關注,因為雲端解決方案可讓使用者動用到超級電腦等級的能力,但花費僅需超級電腦的零頭。更重要的是,這些解決方案可以隨需求而動用;網路變成的雲端上的超級電腦,使用者在需要時,再付費使用即可。雲端運算利用了網際網路技術,使IT能力得以調整規模,以服務的型態供應給客戶。
雲端運算在市場上廣受注目,預料將高度成長,如圖2-2,其中標示出近來值得注意的雲端動向,以及雲端服務的預期收益。
雲端運算被預期為全球IT 消費的重要成長動力。事實上,根據IDC的資料,雲端服務的年複合成長率27%,預期在2012 年達到420 億美元。而自購IT 服務的消費額,年複合成長率預期為5%。
雲端運算的SPI架構
描述雲端運算服務的流通時,最常見的共識可以縮寫成「SPI」。這個縮寫是來自透過雲端提供的三種主要服務:軟體即服務(SaaS)、平台即服務(PaaS)與架構即服務(IaaS)。圖2-3是雲端的服務、用途與種類之間關係。雲端運算的相關技術
雲端存取設備
近年來,雲端的存取設備迅速拓展。家用個人電腦、辦公用電腦、網路電腦、手機設備、各種手持設備,以及各種靜態設備(甚至包括電冰箱)都上網了。更有趣的是,iPhone的竄起與其App Store 軟體的蔓延,顯示了雲端存取的普及。存取普及,進而讓使用量增加、雲端服務隨之成長。例如,你現在可以透過iPhone使用Skype,讓這種點對點的網路應用更靠近用戶,而Salesforce.com也推出了一項應用,讓用戶可以從iPhone與其他各種設備存取其服務。
瀏覽器與瘦用戶端
各種不同類型設備的使用者,現在無論從哪裡載入瀏覽器,都可以存取應用程式與資訊。當然,瀏覽器越來越複雜。企業級應用程式,如SAP 與Oracle,都可以透過瀏覽器介面存取 ─ 以往必須從電腦桌面載入用戶端(這稱為「胖」用戶端)。大眾越來越熟悉瀏覽器功能、可以使用各種應用程式,使用上非常直覺化,不需要經過訓練或閱讀手冊。
高速寬頻連線
雲端最重要的元素之一是寬頻網路,它提供的各種元素連接方式,是30年前運算概念與現今的最重要差異。寬頻連線如今已廣泛普及,尤其在世界各地的都會區。近乎無孔不入的無線網路(如WiFi、手機、WiMAX)隨處可得,使得行動設備成為企業IT 資源與雲端的入口。
資料中心與伺服器農場
雲端服務需要大量的運算設備,需存放於資料中心與伺服器農場。這些資料中心與伺服器農場散佈各地,彼此之間可以透過內部網路連接,提供分散式運算與遞送服務的能力。
現今有許多範例證明了雲端運算效能的彈性與規模。例如,Google 連結了大量平價伺服器,提供驚人的彈性與效能。Amazon 的Elastic Compute Cloud(EC2)在資料中心提供了虛擬化功能,為各項接獲要求的服務建立大量虛擬實體。Salesforce.com 為大量客戶提供SaaS,將客戶區分成群組,確保規模與彈性。
儲存設備
儲存成本的降低,加上儲存設備的部署彈性,改變了資料儲存的生態。固定的直接存取儲存設備(direct access storage device,DASD)被儲存區域網路(storage area network,SAN)所取代,後者降低了成本,並讓企業級儲存的彈性大增。SAN軟體可管理儲存設備的整合工作,也可以隨需求在大量設備上配置儲存空間。
虛擬化技術
虛擬化是建構雲端運算的基礎技術平台,它也正在改變現代資料中心的面貌。「虛擬化」(virtualizaion)這個字彙,代表將運算資源(CPU、儲存設備、網路、記憶體、應用程式堆疊與資料庫)自應用程式與消費服務的使用者抽離。架構的抽離,顛覆了資源分配的民主概念,無論架構、應用程式或者資訊的分配,並且提供了將資源集中的能力,使任何獲得權限的人或事物都可以透過標準化的方法使用資源。 虛擬化技術提供了可改變規模、可讓所有用戶共用的資源平台,促成了多用戶的雲端商業模型。更重要的,在平台客戶眼中,他們的資源是自己專用的。從企業觀點來看,虛擬化可使資料中心更緊密,並改善了IT 運作效益。如今,大型企業已在資料中心以各種形式實作虛擬化技術,包括OS 虛擬化(VMware、Xen)、儲存虛擬化(NAS、SAN)、資料庫虛擬化,以及應用程式或軟體虛擬化(Apache Tomcat、JBoss、Oracle App Server、WebSphere)。
從公開雲端的觀點,依據雲端服務遞送模型(SPI)與架構,虛擬化似乎是在虛擬化服務各層的共用資源(如:OS、儲存、資料庫、應用程式)。
圖2-5是OS虛擬化與昇陽電腦所定義的虛擬化環境各層。使用此虛擬化的IaaS供應商包括Amazon(EC2)、ServePath(GoGrid)與Sun Cloud,使客戶得以在公開雲端執行各種作業系統的實體。圖2-5 中的虛擬化平台是Sun xVM hypervisor 管理環境,將共用硬體資源虛擬化,讓hypervisor 中的來客(guest)或虛擬伺服器作業系統(Linux、Solaris與Microsoft Windows)可以使用。hypervisor 本身是一個很小的應用程式,於實體機器硬體層頂端執行。它實作並管理虛擬CPU(vCPU)、虛擬記憶體(vMemory)、事件頻道(event channel)與常駐虛擬機器(VM)共用的記憶體。它也控制設備的I/O與記憶體存取。
Xen與sun xVM(以Xen 社群的成果作為基礎)類似,VM 稱之為主域(domain),在VMwaer 虛擬化產品中,則表示客用OS。在圖2-5 中,VM 分別標示為dom0、domU1、domU2 與domU3。dom0 是用於管理其他主域(domU1 等等)。VMware 使用類似的機制,稱為「服務主控台」(service console)。透過dom0 或服務主控台所做的管理,包括建立、銷毀、遷移、儲存或復原用戶主域。在用戶主域執行的作業系統,其特殊運作都是經由呼叫hypervisor而執行。
除了OS 與儲存虛擬化,SaaS 與PaaS 服務供應商也會實作軟體和資料庫虛擬化,以便客戶共用軟體應用堆疊和資料庫資源。例如,Salesforce.com 就有軟體堆疊與資料庫堆疊的虛擬化。在這種模型之中,所有客戶可共用遞送架構中的每一層。API
適當的應用程式介面(application programming interface,API)是雲端遞送模型(見圖2-6)。的另一個重要成因。API 讓用戶獲得雲端服務與資源的自給性與程式化控制能力。依據雲端服務遞送模型(SPI)的類型,API 可以表現出不同的型態,從簡單的URL 處理到進階的類SOA 程式模型。API 也有助於發揮雲端運算的潛力,將現有IT 管理程序與規則延伸至雲端服務時,可簡化工作。
IaaS 雲端服務供應商(CSP),如Amazon EC2、Sun Cloud 與GoGrid,他們提供的API可讓用戶建立與管理雲端資源,包括運算、儲存與網路元件。在此,API 的使用是透過HTTP,用到GET、POST、PUT 與DELETE 等要求,雖說大部分工作都僅需GET 與POST 即可達成。在某些狀況下,資源的表現是在JavaScript Object Notation(JSON)之中。例如,Sun Cloud API 當中的雲端規格包括有:
.套用至所有要求與反應的一般行為
.資源模型,描述用於要求與反應之中的JSON 資料結構
.可以送至雲端支援的要求,以及所預期的反應
所有 *aaS 開發者,都需要熟悉部署與管理 *aaS 平台軟體模型所需的API。SaaS服務通常不提供額外的API,僅提供基本輸入與輸出功能,針對使用HTTP與URI處理方法的瀏覽器或指令程式。
如今雲端顧客所面對的主要難題之一,每個CSP 都有專屬的API。結果,雲端應用程式在雲端上毫無可攜性,各雲端上的應用程式(甚至包括你的私密雲端)也很難互換使用。由於API為各雲端專屬的,規劃人員、開發人員與資料中心的人員,都必須熟悉各平台專屬的功能。
雖然雲端API 並無標準,各廠商與用戶社群仍致力於標準化。Universal Cloud Interface(UCI)就是這樣的成果,嘗試建立開放且標準化的雲端介面,使各種雲端API能夠統一。UCI 論壇宣稱其目標為建立單一程式聯絡點,即可透過統一的介面,完成整個架構堆疊以及開發中的雲端技術。在本書撰寫時,我們尚未聽聞有任何CPS 同心協力開發普及一致的跨雲端API ─ 也因此,跨雲端移植應用程式與共用資料一向是大工程。況且為了市佔率,CSP 傾向於把客戶關在自家的雲端之內。原應簡單的互換交流,也因而變得困難。
沒有留言:
張貼留言