2.4 雲端服務風險
2.4.2 雲端服務高等級風險
而本研究強調要針對「雲端的高等級風險」因此要特別探討。首 先是雲端安全聯盟(CSA)以「雲端運算關鍵區域安全指導綱要(Security Guidance for Critical Areas in Cloud Computing)」為基礎,所提出的七項
「雲端建置需要考慮的首要威脅(Top Threats To Cloud Computing)」
(CSA, 2010):
一.濫用與惡意使用雲端服務:IaaS和PaaS服務商提供使用者資源無限 的假象,而且要取得使用帳號非常容易,甚至有些服務商讓使用者連 身份資料都不必留就可以免費使用服務。這使令資源可能被濫用,甚 至是被用來為暴力破解程式、或殭屍網路提供強大運算資源。
二.安全的使用介面與API:雲端通常都透過網際網路提供服務,所以透 過API和使用介面就能控制實際資源,而不需物理接觸。因此使用介面 與API的安全就變得比過去更重要了。
三.惡意的內部員工:縱使所有駭客都難以入侵的資訊系統,如果碰到 內部員工監守自盜同樣沒轍。更糟糕的是惡意員工平常就看起來和一 般員工沒兩樣。
四.虛擬化技術問題:為了彈性應用資源、方便管理,IaaS服務商通常 會使用虛擬化技術。而在同一台機器上的資源可以分租給不同使用者,
但畢竟是住在同一棟樓,有心人仍有可能騷擾隔壁鄰居,稱做多租貸 (multi-tenant)問題。
五.資料遺失或外洩:因為雲端上的交易(讀寫)次數增加,當然也增加 資料可能會錯誤的風險,資料放在雲端上有可能會變得更危險。
六.帳號或服務被駭:帳號或服務被駭並不是個新風險,密碼通常會被 重複使用,而且只需要帳號和密碼就可以在遠端取得完全控制。以網 路為基礎的模式也不安全,駭客可能在服務商與客戶端間攔截封包,
再回傳假訊息讓系統不知道已經被竊聽或控制。
七.未知風險輪廓:雲端其中一個好處是可以減少軟硬體擁有權,並專 心於核心業務,但也可能過於專注核心業務而忽略資訊安全管理。軟 體版本、程式碼更新、資安政策實行、系統弱點輪廓、入侵嘗試、資 安機制設計、誰在分享你的資訊、網路入侵紀錄……等,所有細節都
是很重要的。也許你的系統正在被駭害而不自知。
另 外 開 放 網 頁 應 用 程 式 安 全 組 織 (Open Web Application Project,OWASP)在 2012 年提出的雲端十大安全風險 (Cloud Top 10 Security Risks)則是較新的雲端風險因子辨識文件。OWASP 每年都在全 球各地舉辦應用程式安全研討會(AppSec Conference)並發表許多重要 資訊安全趨勢,是資訊開發人員在資訊安全方面重要的參考。OWASP 的雲端十大安全風險分別是以下十項:
T1.責任與資料擁有權(Accountability and Data Ownership) T2.使用者身份識別的整合(User Identity Federation)
T3.法規適用性(Regulatory Compliance)
T4.業務持續運作與彈性(Business Continuity and Resiliency)
T5.用戶隱私與資料再利用(User Privacy and Secondary Usage of Data) T6.服務與資料整合(Service and Data Integration)
T7.多租賃與實體資源安全(Multi Tenancy and Physical Security) T8.事件分析與鑑識(Incidence Analysis and Forensic Support) T9.基礎設施安全(Infrastructure Security)
T10.非開發環境揭露(Non Production Environment Exposure)
同樣有將雲端服務風險分級,但完整度及詳細度更高的是歐盟資 訊安全組織ENISA提出的雲端服務風險評估報告(Cloud Computing Security Risk Assessment, CCSRA),連CSA的雲端服務風險指導綱要也 有引用這份報告。
ENISA提出的雲端服務風險評估報告(Cloud Computing Security Risk Assessment, CCSRA)參考了IDC、PCI DSS、NIST、ISO/IEC27001、
ISA……等組織提出之報告標準及專家學者意見,整理出35項風險(包 含政策與組織風險、技術風險、法律風險、非針對雲端的風險)、53項 弱點(Vulnerabilities)、23項可能受影響資產(Assest),又以其中九項風險 被評為高風險(High)等級(ENISA, 2009):
九項高等級風險如下:
一.R1.套牢(Lock-in):只支援很少的工具、程序、資料格式及服務介面 來保證資料、應用程式或服務的可攜性。這會讓客戶很難把資料或服 務從某一雲端服務商遷移到另一個服務商或者是遷回公司內部環境。
這使得服務從屬於某一特定雲端服務商,尤其是資料可攜性不被當成
基本原則時。
二.R2.失去對資料和系統控制權(Loss of Governance):在使用雲端架構 時,客戶一定要割讓控制權給雲端服務提供商,一定數量的雲端服務 服務商會負擔安全議題。同時一部份的雲端服務商可能不會在服務水 準協議(SLAs)中提供如此服務,因此在安全防禦間留下一個落差。
三.R3.承諾風險(COMPLIANCE RISKS):如果雲端提供者不能提供他 們自己承認的證據,或是不允許顧客對他們做稽核。這可能暗示有些 承諾在公開雲架構無法被達成,當顧客遷移到雲上時會造成導致風 險。
四.R9.隔離失效(ISOLATION FAILURE):這是虛擬化技術導入後所產 生的問題,雖然並非每片雲都有使用到虛擬化技術,但雲端和虛擬化 技術卻常 常伴隨著一起出 現。多重租貸 (multi-tenancy)與 分享資源 (shared resources)被定義為雲端運算的特性之ㄧ。這個風險種類包含在 不同承租者間儲存體、記憶體路由器、甚至商譽隔絕的失敗 (例如:承 租者 A 透過同伺服器上的承租者 B 當作跳板進行攻擊)。 然而也有人 認為在這樣的隔絕機制下,攻擊者會較在傳統作業系統上進行攻擊更 難。
五.R10.惡意的內部員工(MALICIOUS INSIDER) :雖然通常比較少見,
但內部員工有可能造成大深遠的傷害。雲端架構必須要依靠一些可靠 的角色,這些人具有非常高的風險。例如說雲端提供商的管理員、及 安全服務提供者。
六.R21.做為證物或電子蒐證(SUBPOENA AND E-DISCOVERY):在法 院強制執行或者公民提起訴訟的事件中查封實體硬體。資料集中儲存 在資料中心並共用實體硬體意味著會有更多客戶暴露他們的資料在這 項風險下。
七.R22.行政區的風險(RISK FROM CHANGES OF JURISDICTION):客 戶資料可能被儲存在多個行政區域,其中一些可能具有高風險。如果 資料中心是在高風險國家(例如:某些缺乏法律規則、且有未知法律觀 點和執行的國家,有獨裁警察的國家不會尊重國際協議,網站可能被 當地政府授權突襲,資料和系統會被迫暴露或充公)。
八.R23.資料保護處理風險(DATA PROTECTION):雲端運算造成好幾項 資料保護風險。在一些狀況下,雲端客戶(身為資料控制者)可能很難有
效確認雲端提供者的資料處理實際狀況,也很難確認這些資料是否被 合法處理。這個問題在多重資料傳輸(multiple transfers)狀況下被加重,
例如:聯盟雲(federated clouds)。另一方面,有些雲端提供商確實提供 他們所承載資料處理過程的資訊,有些也提供他們資料處理、安全活 動和資料控制的認證。例如:SAS70 認證。
九.R.26 網路管理風險(NETWORK MANAGEMENT):瀏覽器問題、網 路壅塞、連接錯誤、非最佳化使用
與此九項風險相關之安全弱點(29 項):
一.V1.粗略的授權認證與計費系統(AAA vulnerabilities)
一個粗劣的授權與計費系統可能會讓未授權的資源存取便容易,
資源濫用與安全事件將會變得很普遍。除此之外,自從公司應用程式 暴露在網際網路上開始,雲端模式就會讓針對密碼認證系統的攻擊(例 如利用木馬程式竊取公司密碼)變得更有衝擊性。
二.V5.虛擬化弱點(Hypervisor vulnerabilities):虛擬化層級的攻擊非常具 有吸引力。虛擬機器事實上可以完全控制實體資源,所以這個層級的 弱點相當關鍵。虛擬機器可能反客為主(guest to host escape)控制實體機 器。另一個狀況是駭客可能從一個虛擬機器跳躍控制(VM hopping)另外 一個虛擬機器。
三.V6.使用者間缺乏實體資源的獨立(Lack of resource isolation)
四.V7.使用者間缺乏商譽的獨立(Lack of reputational isolation ):一個客 戶的活動,有可能影響到其他客戶的商譽。
五.V10.不能在加密狀態下處理資料(Impossibility of processing data in encrypted form)
六.V13.缺乏技術標準與標準解決方案(Lack of standard technologies and solutions):意味著使用者可能會被套牢,也無法使用外部資訊安全管 理工具。
七.V14.沒有原始碼託管協議(No source escrow agreement):企業把開發 系統的工作外包時,如果發現錯誤需要自行改寫時必須取得合法授權。
缺乏這份原始碼託管協議,意味著如果 PaaS 或 SaaS 服務商破產時,
顧客將無法自行修改系統。
八.V16.沒有控制漏洞評估程序(No control on vulnerability assessment process):意味著把基礎架構弄安全的責任就交到客戶手上了。
九 .V17. 可 能 在 內 部 或 雲 端 網 路 上 發 生 的 掃 瞄 (Possibility that internal/cloud network probing will occur):一個使用者可能會在另外一 個使用者的內部網路或雲端網路做漏洞掃描。
十.V18.使用者可能會對鄰居的資源做偵測(Possibility that co-residence checks will be performed)
十一.V21.合約沒有寫清楚責任歸屬(Synchronizing responsibilities or contractual obligations external to cloud):許多使用者沒有察覺到服務中 的某些責任屬於自己,甚至像是加密檔案,這些都是要在合約中講清 楚的。
十 二 .V22. 跨 雲 端 應 用 程 式 隱 含 相 依 關 係 (Cross-cloud applications creating hidden dependency):服務供應鏈中存在隱藏的相依關係(雲內 和外的相依),當第三方開發商(轉包商或客戶的公司)擴充服務系統時,
IaaS 或 PaaS 雲端服務商的架構不支援。
十三.V23.服務水平協議條款可能會在不同利害關係人間產生互斥 (SLA clauses with conflicting promises to different stakeholders):服務水 平協議(SLA)條款可能也會和其他服務商承諾或條款產生互斥。
十四.V25.雲端服務商無法藉由稽核或認證給予客戶任何保證(Audit or certification not available to customers)
十五.V26.認證計畫不適合雲端架構(Certification schemes not adapted to cloud infrastructures)
十六.V29.資料被儲存在多個司法行政區,但在這件事上缺乏透明度 (Storage of data in multiple jurisdictions and lack of transparency about THIS)
十 七 .V30. 缺 少 該 資 料 儲 存 所 在 司 法 行 政 區 的 相 關 資 訊 (Lack of information on jurisdictions)
十八.V31.使用者條款缺乏完整性與透明度(Lack of completeness and transparency in terms of use)
十九.V34.雲端服務提供商組織裡的角色與責任定義不明確(Unclear roles and responsibilities)
二十.V35.雲端服務提供組織裡角色職責實行不確實 (Poor enforcement of role definitions):可能創造某一個權力過大的管理角色。
二十一.V36.相關當事人知道太多非必要的細節(Need-to-know principle
not applied):相關當事人只需要知道原則而不是太多非必要細節。
二 十 二 .V37. 不 充 分 的 技 術 實 體 安 全 (Inadequate physical security procedures):例如 RFID 的資安問題、或沒有電磁保護避免竊聽
二十三.V38.人為設定錯誤(Misconfiguration):不適當的應用程式安全設 定、僵化程序、人為失誤、未受訓練的管理員。
二十三.V38.人為設定錯誤(Misconfiguration):不適當的應用程式安全設 定、僵化程序、人為失誤、未受訓練的管理員。