混合雲之用戶身份認證、檔案授權及權責~雲端運算資安與互通性之基礎研究

科技部補助專題研究計畫成果報告

期末報告

混合雲之用戶身份認證、檔案授權及權責~雲端運算資安與互通

性之基礎研究

計 畫 類 別 ： 個別型計畫 計 畫 編 號 ： MOST 103-2221-E-004-014-執 行 期 間 ： 103年08月01日至104年07月31日 執 行 單 位 ： 國立政治大學資訊管理學系 計 畫 主 持 人 ： 姜國輝 計畫參與人員： 碩士班研究生-兼任助理人員：丁柏元 碩士班研究生-兼任助理人員：湯家哲 碩士班研究生-兼任助理人員：朱家棋 報 告 附 件 ： 出席國際會議研究心得報告及發表論文 處 理 方 式 ： 1.公開資訊：本計畫涉及專利或其他智慧財產權，1年後可公開查詢 2.「本研究」是否已有嚴重損及公共利益之發現：否 3.「本報告」是否建議提供政府單位施政參考：是，經濟部、財政部、衛福部

中　華　民　國　104　年　10　月　30　日

中 文 摘 要 ： 繼網際網路蓬勃發展後，吾人的工作與生活變得更為便利。雲端運 算問世之後，更多用戶將其做資料備份與發佈的平台。用戶常用雲 端的方案有以下三種：即公有雲(Public Cloud)、私有雲(Private Cloud)及混合雲(Hybrid Cloud)。使用公有雲將服務與資料儲存交 由雲端提供商託管，例如使用 Google Apps、G-mail，以減少企業 內部的成本。用戶亦可建置私有雲，以提供檔案備援與內部服務。 另外，用戶可結合公有雲與私有雲以構成混合雲，即使用公有雲儲 存敏感度不高之資料並將敏感度較高的資料存至私有雲或本地端。 如此地在混合雲環境混用數位資財的狀況下，本地端與雲端資料的 一致性成為關鍵性的問題。雖然，以長期的眼光看來，用戶使用雲 端運算可以獲利，然而不同地點之資料的一致性問題卻會讓用戶裹 足不前。其問題來自於兩方面： 首先是”資訊混亂”的問題，它源 自於不同地點的資料版本不一；其次的問體是”管理危機”，它肇 因於不可靠的資料存取。 本研究將探討用戶在使用混合雲時遇到的安全控管及互通性問題 ，即用戶帳號認證，存取權限管理以及用戶權責。本計畫將研究使 用開放標準 OpenID 與 O＇Auth 來進行對公有雲的帳號認證、檔案 存取授權及管控，以開發出一個跨本地端電腦或私有雲與公有雲帳 號與檔案內容權限之管理與權責同步系統。在本研究中，我們將將 結合多個主流公有雲平台(例如 Google App/GAE、Apple iCloud、 MS Azure、FaceBook 等)，以及 Hadoop 為本之私有雲平台、本地 端則包含多種作業系統之電腦主機，例如 Linux、Ms-Windowsc 和 OS X等。其間，用戶由任一本地端主機登入後，可以處理對應的雲 端之身分認證及獲得資料存取權。如此，本系統可解決在公有雲、 私有雲與本地端系統多重帳號的困擾以及組織人員由外部存取與內 部存取時的權限不足或檔案版本不同的問題。整體而言，我們將根 據 CMMI 來校驗系統的功能性、可靠性和一致性，以展現此一方法 的可用性與卓越性。 中 文 關 鍵 詞 ： 混合雲、單一登入，檔案同步服務、檔案權限管理、資訊安全 英 文 摘 要 ： With the benefit from public cloud, users are able to

utilize their business information in lower cost but higher efficiency. Integrity between local storages and the clouds is a critical issue which often messes up the users＇

digital assets in a hybrid cloud environment. The downside makes the users reluctant to embrace cloud technology, though they may benefit from it in the long-term. The drawback comes from two aspects: “the information chaos” and “the management crisis”. The chaos originates from the possibility of information inconsistency among replicas in different places. The managerial crisis lies in the non-trustable access to the digital assets.

This research aims to solve the Hybrid Cloud security control and interoperability issues such as Authentication as well as Access Right Authorization and consequent

Accountability. The research refers to the de facto open standards, viz. OpenID and O‘Auth to facilitate

Authentication, Access Right Authorization and

Accountability for the Hybrid Cloud environments. The mechanisms are implemented for a cross-platform which encompasses local hosts with different OS, the private cloud based on Hadoop, and the mainstream platforms as the public cloud scenario, such as Google Apps/GAE, Apple＇s iCloud, FaceBook etc. Users can launch the login from whatever a local host and then deal with Access Right Permissions on the respective clouds. Last but not least, we will validate, according to CMMI, the functionality, reliability and integrity of the solutions to show the superiority and applicability of our approach.

英 文 關 鍵 詞 ： Hybrid Cloud, Single-Sign-On, File Synchronization, File Access Right Management, Information Security

科技部補助專題研究計畫成果報告

（□期中進度報告/▓期末報告）

計畫名稱：

混合雲之用戶身份認證、檔案授權及權責~

雲端運算資安與互通性之基礎研究

計畫類別：▓個別型計畫 □整合型計畫

計畫編號：MOST - 103-2221-E-004 -014 –

執行期間： 2014 年 08 月 01 日至 2015 年 07 月 31 日

執行機構及系所：國立政治大學 資訊管理學系暨雲端運算與營運創新研究中心

計畫主持人：姜國輝

共同主持人：嚴漢偉

計畫參與人員：丁柏元、朱家棋、湯嘉哲

本計畫除繳交成果報告外，另含下列出國報告，共 _一__ 份：

□執行國際合作與移地研究心得報告

▓出席國際學術會議心得報告

期末報告處理方式：

1. 公開方式：

▓非列管計畫亦不具下列情形，立即公開查詢

□涉及專利或其他智慧財產權，□一年□二年後可公開查詢

2.「本研究」是否已有嚴重損及公共利益之發現：▓否 □是

3.「本報告」是否建議提供政府單位施政參考 □否 ▓是， （請列舉提供

之單位；本部不經審議，依勾選逕予轉送）

中文摘要

隨著網際網路的蓬勃發展、雲端運算的興起，各種公有雲端服務林立，企業 組織擁有更多不同的選擇與更經濟的解決方案，因此也願意投入更多花費在公有 雲上。其中，最重要的一項服務為檔案同步與分享服務(File Synchronization and Sharing, FSS)，其可為企業組織帶來生產力，但在無法完全信任公有雲端服務的 情況下，在檔案管理及服務上勢必會採用混合雲部署，私有雲端環境用來處理敏 感度較高的資料而敏感度較低的檔案及文件才會採用公有雲端服務。

本研究將探討在混合雲環境下會遇到的使用者多重帳號及身分，以及檔案一 致性的問題。我們提出一套整合不同雲端平台帳號之混合雲身分驗證的架構與方 法，其中整合支援 OpenID Connect 之身分驗證與授權機制的公有雲; 以 Keystone 作為身分驗證與授權機制的 OpenStack ; 以 Kerberos 作為身分驗證與授權機制的 Hadoop ; 其他有自己獨自帳號與權限管理的雲。在檔案同步上，設計出三次同 步訊息交換和兩階段同步的機制，並且架構出一個入口網站(Portal)服務，根據以 上設計架構，實作出一個在混合雲環境，跨本地端、公有雲與私有雲的雲端帳號 整合，檔案權限管理與同步之系統，最終可以解決在混合雲環境，不同雲端平台 多重帳號的困擾，並可以維持不同裝置和雲端之間檔案資料和權限一致性。本研 究最後針對實作出的系統進行測試，驗證本系統各元件模組的正確性和穩定性， 測試結果都是通過的；也針對公、私有雲端，測試檔案同步時間與帳號驗證時間， 衡量各種大小檔案同步與單一登入各雲端所需要花費的時間，驗證本系統的效能 和實用性。 關鍵字：混合雲、單一登入，檔案同步服務、檔案權限管理、資訊安全

英文摘要

With the benefit from public cloud, users are able to utilize their business information in lower cost but higher efficiency. Integrity between local storages and the clouds is a critical issue which often messes up the users’ digital assets in a hybrid cloud environment. The downside makes the users reluctant to embrace cloud technology, though they may benefit from it in the long-term. The drawback comes from two aspects: “the information chaos” and “the management crisis”. The chaos originates from the possibility of information inconsistency among replicas in different places. The managerial crisis lies in the non-trustable access to the digital assets.

This research aims to solve the Hybrid Cloud security control and interoperability issues such as Authentication as well as Access Right Authorization and consequent Accountability. The research refers to the de facto open standards, viz. OpenID and O‘Auth to facilitate Authentication, Access Right Authorization and Accountability for the Hybrid Cloud environments. The mechanisms are implemented for a cross-platform which encompasses local hosts with different OS, the private cloud based on Hadoop, and the mainstream platforms as the public cloud scenario, such as Google Apps/GAE, Apple’s iCloud, FaceBook etc. Users can launch the login from whatever a local host and then deal with Access Right Permissions on the respective clouds. Last but not least, we will validate, according to CMMI, the functionality, reliability and integrity of the solutions to show the superiority and applicability of our approach.

Keywords：Hybrid Cloud, Single-Sign-On, File Synchronization, File Access Right Management, Information Security

目錄

摘要 ... I 圖目錄 ... VI 表目錄 ... VIII 第一章、 前言 ... 錯誤! 尚未定義書籤。 1、 研究背景 ... 1 2、 研究動機 ... 2 3、 研究目的 ... 3 第二章、 文獻探討 ... 4 1、 雲端運算 ... 4 1.1 雲端運算的服務模式 ... 4 1.2 雲端運算的部署方式 ... 5 2、 身分管理 ... 7 2.1 背景與定義 ... 7 2.2 驗證 (Authentication) ... 10 2.3 授權(Authorization) ... 11 2.4 Accounting ... 13 3、 混合雲單一登入 ... 13 3.1 單一登入 ... 13 3.2 OpenID Connect ... 17 3.3 Keystone ... 21 3.4 Kerberos ... 22 4、 雲端儲存技術及其發展 ... 24 4.1 雲端儲存發展趨勢 ... 24 4.2 軟體定義儲存 ... 26 4.3 OpenStack Swift ... 28 4.4 雲端資料管理介面 ... 32 5、 檔案同步服務 ... 35

5.1 檔案同步服務模型 ... 35 5.2 檔案同步機制 ... 36 5.3 企業檔案同步與分享服務 ... 37 第三章、 研究方法：系統設計與架構 ... 39 1、 系統概述 ... 39 2、 系統架構 ... 40 2.1 系統元件說明 ... 41 3、 混合雲帳號整合 ... 44 3.1 一次性帳號對應 ... 44 3.2 階段式帳號對應 ... 46 3.3 帳號對應表 ... 49 4、 混合雲單一登入 ... 51 5、 帳號救援 ... 56 6、 檔案與資料夾同步 ... 57 6.1 檔案系統監控模組 ... 57 6.2 同步機制設計 ... 58 6.3 雲端檔案與資料夾異動偵測 ... 59 6.4 檔案清單一致性 ... 61 6.5 檔案與資料夾同步 API ... 63 7、 檔案權限管理 ... 64 7.1 權限與功能對應 ... 64 7.2 權限管理平台 ... 64 第四章、 研究成果：系統實作與測試 ... 65 1、 系統部署環境 ... 65 2、 系統實作 ... 66 2.1 資料加密傳輸 ... 66 2.2 混合雲帳號整合 ... 67 2.3 混合雲單一登入 ... 69

2.4 帳號救援 ... 78 2.5 檔案系統監控 ... 79 2.6 同步訊息交換 ... 80 2.7 檔案與資料夾同步 ... 81 2.8 檔案權限管理 ... 86 3、 系統測試 ... 87 3.1 測試範圍 ... 87 3.2 測試接受準則 ... 87 3.3 測試環境 ... 88 3.4 測試案例 ... 90 3.5 測試結果與分析 ... 95 第五章、 研究結論與建議 ... 100 1、 結論 ... 100 2、 研究貢獻 ... 102 3、 未來研究建議 ... 103 參考文獻 ... 104

圖目錄

圖 一：全球公有雲端服務花費(IDC, 2014)... 1

圖 二：雲端運算架構(引用自 NIST)... 4

圖 三：Isolated Model Diagram (Yuan Cao and Lin Yang, 2010) ... 8

圖 四：Centralized Model Diagram (Yuan Cao and Lin Yang, 2010) ... 8

圖 五：Federated Model Diagram (Yuan Cao and Lin Yang, 2010) ... 9

圖 六：CA 驗證流程 (尤淑芬、謝乙誠, 2009) ... 14

圖 七：UID 驗證流程 (尤淑芬、謝乙誠, 2009) ... 15

圖 八：雲端驗證方式 (Harry Katzan, Jr., 2010) ... 17

圖 九：OpenID Connect - Authorization Code Flow (OpenID Foundation 官網)19 圖 十：Keystone External Authentication 運作流程架構圖 ... 21

圖 十一：Kerberos 驗證流程圖 (IBM) ... 23

圖 十二：基於雲端的儲存演進(引用自 Tenaja Group) ... 25

圖 十三：儲存節點(引用自 SwiftStack 官方網站) ... 29

圖 十四：儲存節點、硬碟和 Partition 關係(引用自 SwiftStack 官方網站) ... 31

圖 十五：Cloud Storage Reference Model(引用自 CDMI v1.1.1) ... 33

圖 十六：兩種檔案同步服務的模型(Xianqiang, Bao, et al., 2011) ... 35

圖 十七：SyncViews 詳細同步流程(Xianqiang, Bao, et al., 2011) ... 36

圖 十八：使用案例圖 ... 39 圖 十九：系統部署圖 ... 40 圖 二十：一次性帳號對應之流程圖 ... 44 圖 二十一：一次性帳號對應示意圖 ... 46 圖 二十二：階段式帳號對應之流程圖 ... 47 圖 二十三：階段式帳號對應示意圖 ... 49 圖 二十四：帳號對應表(一次性帳號對應) ... 50 圖 二十五：帳號對應表與系統帳號目錄之關聯 ... 50 圖 二十六：單一登入機制流程圖 ... 51 圖 二十七：系統帳號驗證流程示意圖 ... 52 圖 二十八：各端已認領帳號驗證示意圖 ... 52 圖 二十九：帳號對應表(帳號驗證) ... 53 圖 三十：各雲端單一登入(帳號已認領) ... 54 圖 三十一：各雲端登入(帳號未認領) ... 55 圖 三十二：帳號對應表(各雲端單一登入) ... 55 圖 三十三：帳號救援流程圖 ... 56 圖 三十四：三次同步訊息溝通順序圖 ... 58 圖 三十五：兩階段同步順序圖 ... 59 圖 三十六：客戶端應用程式更新本地端順序圖 ... 60

圖 三十七：客戶端應用程式檢查雲端儲存順序圖 ... 61

圖 三十八：MongoDB 檔案清單 Files Collection 的 JSON 結構 ... 62

圖 三十九：系統部署環境圖 ... 65 圖 四十：一次性帳號對應之實作虛擬碼 ... 67 圖 四十一：階段式帳號對應之實作虛擬碼 ... 68 圖 四十二：帳號驗證實作之虛擬碼 ... 69 圖 四十三：手機驗證實作之虛擬碼 ... 71 圖 四十四：各雲端單一登入實作之虛擬碼 ... 72 圖 四十五：系統同步示意圖 ... 82 圖 四十六：不同雲端之個別平均登入時間 ... 95 圖 四十七：首次與再次登入系統之平均時間 ... 96 圖 四十八：本地端同步到伺服器端花費時間 ... 96 圖 四十九：伺服器端同步新增、修改到雲端花費時間 ... 97 圖 五十：伺服器端同步更名到雲端花費時間 ... 98 圖 五十一：伺服器端同步刪除到雲端花費時間 ... 99

表目錄

表 一：CA 與 UID 比較表 (尤淑芬、謝乙誠, 2009) ... 16 表 二：軟體定義儲存和傳統儲存陣列差異(本研究整理) ... 26 表 三：CDMI 物件 HTTP 操作(資料來源：CDMI v1.1.1) ... 33 表 四：CDMI 容器 HTTP 操作(資料來源：CDMI v1.1.1) ... 34 表 五：檔案系統監控事件 ... 57 表 六：檔案與資料夾同步 API 介面 ... 63 表 七：檔案權限和操作功能對應表 ... 64 表 八：OpenID Connect 提供商之驗證端點表 ... 73

表 九：OpenID Connect 驗證 URI 參數列表 ... 73

表 十：Selenium FireFox WebDriver API 列表 ... 75

表 十一：OpenID Connect 提供商之 Token 端點表 ... 75

表 十二：OpenID Connect Token URI 參數列表 ... 76

表 十三：RabbitMQ 客戶端實作參數 ... 80 表 十四：雲端服務套件與說明 ... 84 表 十五：伺服器端硬體規格表 ... 88 表 十六：本地端硬體規格表 ... 88 表 十七：伺服器端軟體規格表 ... 89 表 十八：本地端作業系統規格表 ... 89 表 十九：測試資料大小和類型 ... 89 表 二十：混合雲帳號整合測試案例 ... 90 表 二十一：混合雲單一登入測試案例 ... 91 表 二十二：檔案同步測試案例 ... 92 表 二十三：檔案權限管理測試案例 ... 93 表 二十四：測試案例結果 ... 95

第一章、 前言

1、 研究背景

雲端運算的發展為企業的資訊處理帶來更多不同的選擇與更經濟的方案，而 雲端運算可分為公有雲端服務與私有雲端服務兩大範疇。根據國際數據資訊 IDC (2014)的研究指出全球公有雲端服務的花費在 2014 年已達到 566 億美元， 並預期會在 2018 年達到 1270 億美元，這表示其五年的年複合成長率為 22.8%， 將是其餘 IT 市場成長率的 6 倍，而 SaaS 將在未來繼續佔據公有雲服務主要花費， 其在 2014 年佔據 70%(圖一)，這很大程度是因為客戶在雲端服務需求多是軟體 層面的。在未來公有雲端服務會被企業更廣泛使用，然而在使用公有雲端服務所 可能會遭遇的問題與企業較為相關，尤其是在資訊安全和服務可靠性上。 圖 一：全球公有雲端服務花費(IDC, 2014) 隨著公有雲端服務的發展，越來越多企業組織採用了不同的雲端解決方案，在眾 多公有雲端服務類型中最重要的一類服務則是檔案同步與分享服務(IDC, 2014)， 而企業要使用公有雲檔案同步與分享服務，不論是想做檔案資料異地備援或是想 要更快速方便取得應用，隨時隨地透過手機可以進行存取，在不能完全信任此類 SaaS 的公有雲端服務的情況下，企業組織在其檔案管理及服務上勢必會有內部 私有雲端環境，用來處理敏感度較高的資料，而敏感度較低的檔案及文件才會採

用公有雲端服務，此種私有雲端環境和公有雲端環境並行的模式為混合雲環境。 IDC FutureScape 報告預測在 2016 年以前將會有超過 65%的企業 IT 組織致力於 發展混合雲的技術，而國際研調機構 Gartner (2013)報告則指出到了 2017 年底將 會有高達 50%的企業採用混合雲的架構。

2、 研究動機

從不同的研究報告中可以看到，企業組織在未來勢必會需要採用混合雲架構， 然而使用於混合雲環境下使用檔案同步與分享服務可能為企業帶來生產力但也 可能為企業的檔案管理帶來混亂與危機和帳號管理帶來困難。 檔案管理混亂主要來自兩方面:「資訊混亂」與「管理風險」。資訊混亂來自 於企業內部私有雲檔案資料和公有雲檔案資料不一致的情況，造成認知錯亂與失 序，會產生資料一致性的問題。管理風險來自於企業內部私有雲檔案權限和公有 雲檔案權限之間缺乏一致性的對應關係，使企業擔憂自己的數位資產在公有雲端 上曝露在非預期的閱讀與編輯的風險。帳號管理困難則主要是因為當企業採用越 來越多雲端服務時，相對應的使用者帳號也會隨之增加，對用戶而言必須記來自 於多個不同雲端平台上的帳號密碼，並且需要管理不同雲端平台上的檔案資料。 本研究希冀能夠解決企業在使用檔案同步與分享服務於混合雲環境下運作 時，可能發生的三種運作模式，備份雲端資料、更新雲端資料、同步資料權限所 產生的資料一致性與權限一致性問題(翁雋傑, 2012)以及使用者在多個雲端平台 擁有多個帳號，和其管理上的困難，並同時能提供動態的檔案自動化備援功能。 為此，本研究實作出一個跨本地端、私有雲與公有雲的雲端帳號整合和檔案權限 管理與同步系統。透過實作的系統，讓使用者能夠彈性的整合多個雲端平台帳號， 並便利的透過單一介面來同步和管理不同雲端上的檔案資料和權限，系統可以確 保每一份同步到公有雲端的檔案也能夠在企業內部私有雲環境上有相對應的檔 案備份。

3、 研究目的

有別於私有雲和公有雲的部署模式，本研究所實作出的混合雲帳號整合、檔 案權限管理與同步系統主要針對企業研究混合雲的部署方式及其應用，並且能夠 解決企業在使用公有雲檔案同步與分享服務於混合雲部署方式下會發生的問題。 本研究將針對以下三個主題進行詳細的分析與探討： (1) 混合雲身分互通性及單一登入：為了解決企業內部帳號和雲端帳號過多的問 題，系統能讓使用者於系統註冊或使用者帳號管理介面進行多個公、私有雲端平 台帳號的認領(claim)，而系統則將這些帳號進行整合，來完成公、私有雲帳號的 對應。而根據此對應，當使用者使用任意已認領的雲端帳號來登入系統時，將同 時單一登入其他在系統上已認領之雲端平台，且能夠存取這些雲端平台上的資源， 確保同一位使用者不同雲端之間的互通性。 (2) 檔案一致性：分為資料一致性和權限一致性。在進行雲端資料備份與更新操 作時，系統要能夠確保本地端、公有雲端檔案和私有雲端檔案資料的一致性。而 在資料權限同步時，系統要能確保在公有雲端平台上檔案和私有雲內部檔案對於 企業內部身分和外部雲端之不同使用者身分的檔案存取權限的一致性，並且允許 檔案擁有者進行檔案權限控管。 (3) 雲端自動化備援：系統在同步檔案到公、私有雲端時，同時也能夠動態的自 動同步一份相同檔案到私有雲內部的環境上，作為一個備份。並且要能夠確保使 用者對於檔案的每一種操作，例如，新增、刪除、修改、更名，也都能夠自動的 同步到對應的備援檔案。

第二章、 文獻探討

1、 雲端運算

雲端運算是一種概念模式，依照使用者的需求透過網路去存取資源(如網路、 伺服器、儲存、應用程式、服務)，可以用最少的管理而達到快速的配置與發佈 (NIST, 2011)，美國國家標準與技術研究院提出的定義中也進一步的說明對於雲 端運算的五項重大特徵、三類服務模式、四種部署方式，如圖三，以下將針對雲 端運算不同的部署方式和服務模式及其應用進行探討。 圖 二：雲端運算架構(引用自 NIST)

1.1

雲端運算的服務模式

以服務模式來進行分類，雲端運算包含三個層次之服務：軟體即服務 (Software as a Service, SaaS)、平台即服務(Platform as a Service, PaaS)，以及基礎 設施即服務(Infrastructure as a Service, IaaS)，此三種層次之服務的運作敘述如 下。

( 1 ). 軟體即服務(SaaS)

體或應用提供有使用者介面可以讓用戶從不同客戶端裝置去使用，例如：瀏覽器， 甚至該服務可能也會提供程式 API 介面，允許開發者程式介接。由於服務是建 置在提供商的雲端基礎設施之上，消費者不需要去管理或控制相關硬體環境，只 需要處理限於自身的服務相關配置設定。

( 2 ). 平台即服務(PaaS)

提供雲端運算平台，允許用戶根據提供商所提供的 SDK 或工具去開發及客 製化自己的應用程式，並部署到該服務平台之上，用戶不需要去管理或控制底層 雲端基礎設施。而服務提供商也提供應用程式於平台上使用之硬體相關資源使用 率，並提供維運管理功能幫使用者進行監控及計費。

( 3 ). 基礎設施即服務(IaaS)

服務提供商以虛擬化的技術提供用戶運算資源、儲存資源以及網路資源，並 允許用戶可以部署和執行任意軟體，例如：作業系統、應用程式，而用戶可以動 態分配所使用的運算資源。IaaS 服務的雲端基礎設施的底層架構和實體伺服器則 由服務提供商來負責管理及維護。

1.2

雲端運算的部署方式

雲端運算依據其部署方式可以分為四種，分別是私有雲(Private Cloud)、社 群雲(Community Cloud)、公有雲(Public Cloud)及混合雲(Hybrid Cloud)，此四種 部署方式介紹如下。

( 1 ). 私有雲(Private Cloud)

建置雲端基礎設施專門為企業組織使用，可能是由該組織本身、第三方廠商 或者兩者共同在企業組織內部(On premise)或是外部(Off premise)進行部署。企業 組織建置私有雲環境而不採用公有雲的考量通常在於資料安全性和服務可靠性， 而因為私有雲的網路環境是使用企業內部網路(Intranet)以此來和外部網路環境 區隔，並且使用者多是具有企業組織內部身分的，安全性較能確保，另外私有雲

的部署方式企業組織也較能掌控雲端基礎設施架構，並能改善其服務可靠性和彈 性。

( 2 ). 社群雲(Community Cloud)

為共同專注在特定議題，例如：任務、安全需求、政策和合規性考量，的數 個特定組織所建置的雲端基礎設施，其可能是由社群內一個或多個組織來共同管 理，或是由第三方廠商來進行管理。

( 3 ). 公有雲(Public Cloud)

雲端基礎設施建置在服務提供商內部並為其所擁有，並且公開提供服務給一 般大眾，此服務提供商有可能是商業、學術或政府單位。公有雲端服務一般大多 並非為免費的，是否收費是由各服務提供商自行決定，而計費方式主要是根據所 使用的服務類型和用量。企業組織可以依據自身需求和考量來使用不同服務供應 商所提供的服務，例如：使用 SaaS 模式的檔案同步與分享服務。

( 4 ). 混合雲(Hybrid Cloud)

其雲端基礎設施主要是由兩個或兩個以上的雲(私有雲、社群雲或公有雲)所 組成並各別獨立存在，但是藉由標準或是專有技術來把不同雲聯繫再一起，使雲 之間的資料或是應用是具有可移植性的。企業組織使用混合雲雖然比完全使用公 有雲較為安全，而且建置成本比完全使用私有雲較為低，但是其公、私有雲之間 的安全控制，部署方式以及整體 IT 架構規劃上卻是更為複雜的。

2、 身分管理

2.1

背景與定義

身分管理可分為兩個面向，即身分驗證與與授權管理。其中，身分驗證其主 要為針對核發的數位憑證、帳號與密碼等進行驗證的過程。而身分授權管理其主 要為授予權限給已被認證核准之使用者的過程，以便其存取資源。(Peter, 2005) 在身分管理的運作機制中，主要包含以下三個核心角色及三個不同的運作模 式(Yuan Cao and Lin Yang, 2010)：

( 1 ). 核心角色

(1). 使用者(User) 使用 SP 提供之服務的使用者，而該使用者必須具有合法的身分識別才 能夠存取 SP 服務，且扮演 SP 與 IdP 之客戶端角色。 (2). 服務提供者(Service Provider, SP ; 以下簡稱 SP) 提供相關資源與服務給使用者來使用。

(3). 身分提供者(Identity Provider, IdP ; 以下簡稱 IdP)

提供使用者身分註冊與驗證，並儲存管理使用者相關註冊資訊，以及接 收處理來自 SP 端發出的使用者驗證請求。

( 2 ). 運作模式

(1). 獨立模式(Isolated Model) 服務提供者同時扮演 SP 與 IdP 的角色，即使用者身分註冊、配置、刪 除、驗證、授權，以及儲存管理使用者的資訊等，皆由其獨自完成(圖五)。 (Chadwick et al., 2009)。

圖 三：Isolated Model Diagram (Yuan Cao and Lin Yang, 2010) (2). 集中模式(Centralized Model) SP 與 IdP 各自扮演自己的角色，SP 的開發人員不必自行開發身分管理 的機制，透過介接 IdP 來達到身分管理的效果。此外在相同網域中，當不同 的 SP 皆介接到相同的 IdP 時，更可達到單一登入的機制，讓使用者在其中 一個 SP 完成登入認證後，在使用其他 SP 所提供的服務時，不必再次做登 入認證的動作(圖六)。而此模式存在的風險，當 IdP 受到惡意的攻擊時，例 如: Denial Of Service Attack(DoS)，導致其運作停擺，如此一來將會接連影響 到 SP 相關服務的運作。

(3). 聯盟模式(Federated Model) 聯盟(Federations)為一個或數個 SP(s)與 IdP(s)之間所建立的聯盟關係， 並制定一套共同的聯盟制度與規範(Chadwick et al., 2009)，例如: 規範使用 者相關資訊(使用者認證資訊、資源授權資訊…)之交換標準與格式(如: JSON、 SAML)，使 SP 與 IdP 之間能夠透過此標準交換使用者認證資訊，彼此建立 信任的關係，即 SP 能夠信任此 IdP 之身分驗證。 例如: 在跨網域(Across Domain)的環境中，有多個 SP 且皆有自己的一 套單一登入機制，並分別介接不同的 IdP 來對使用者進行身分認證，其中對 使用者來說其必須記取各個 SP 登入驗證的帳號與密碼，才能使用各個 SP 服務。此時若欲達到跨網域各個 SP 之間單一登入驗證的機制，則大家必須 建立聯盟的關係，各個 SP 必須共同信任來自不同 SP 所介接之 IdP 的身分 驗證，最後透過彼此間相互交換使用者認證資訊，來達到聯盟單一登入的機 制。如此一來，只要使用者選擇任一 SP 登入並完成驗證後，其他 SP 也將 一併完成認證(圖七)。

就身分與存取管理系統功能層面來看，其主要分為三個層面，分別是身分驗 證(Authentication)、授權(Authorization)、稽核(Accounting) (Alberto, 2008 ; RFC 2903, 2000)，以下的主題將逐一針對 AAA 進行探討。

2.2

驗證 (Authentication)

當使用者或其他應用程式發出登入系統的請求時，系統為了確認該使用者或 應用程式的身分是否合法，因此將採取身分驗證的流程。而以下的內容將分別針 對驗證不同的面向進行探討。目前常見的驗證方式可以分為以下不同的種類(花 俊傑, 2012 ; Sandhu and Samarati, 1996)：

(1). 你知道的(What you know)

帳號與密碼，為最常見的一種認證方式，根據使用者設定之帳號與密碼， 來進行身分驗證。

(2). 你擁有的(What you have)

- 電子憑證，又稱為數位憑證可從身分認證機構(Certificate Authority, CA)獲得，憑證內記載使用者的身分資料及公開的金鑰，使用者可以 憑著電子憑證向系統證明自己的身分。 - 智慧卡，一種內置集成電路的芯片，芯片中存有與用戶身份相關的數 據，登錄時必須將智慧卡插入專用的讀卡器讀取其中的信息，以驗證 用戶的身份。

- 手機驗證碼，系統透過手機簡訊的方式(Short Message Service ; SMS) 發送 N 位數的動態密碼，使用者透過輸入此動態密碼完成身分驗證。 - Token，儲存於相關電子裝置，例如: 桌上型電腦、筆記型電腦、行

動手持裝置等，以一段序列化字符串表示且具有時效性，其中包含使 用者等相關資料，常作為 HTTP 請求的一部分，發送到應用服務端作 為身分的識別。

(3). 你與生俱來的(What you are) 生物特徵，例如: 身體特徵方面的指紋、掌型、視網膜、虹膜等，行為 特徵方面的語音、簽名等，透過這些生物的特徵來進行身分認證。 (4). 其他 雙因素驗證（two-factor authentication），即將兩種驗證方式結合起來， 以進一步提升驗證的安全性，例如: 帳號密碼再加上手機驗證碼的方式。 綜合上述的認證方式，常見身分驗證解決方案像是 Kerberos、Public Key Infrastructure(PKI)、Pluggable Authentication Module(PAM)、Remote Authentication Dial In User Service(RADIUS)等。(Alberto, 2008 ; 陳璽丞)

2.3

授權(Authorization)

授予驗證通過的使用者能夠對資源進行存取與相關操作之權限。以下分別就 授權不同的面向進行探討。

( 1 ). 基本元素

其中授權包含了以下三個主要的元素：(Alberto, 2008 ; Sandhu and Samarati, 1994) (1). Subject(主體) 描述要求授權的主體，例如: 系統的使用者、群組、應用程式等。 (2). Right(權限) 描述主體要授權的動作，例如: 讀取、修改、刪除、開啟、執行等。 (3). Object(受體)或 Resourse(資源) 描述主體要授權的資源，例如: 檔案、應用程式、資料庫等。 由以上三個元素構成授權的行為，例如: 一個通過驗證的 Subject，其被授予 相關的 Right 去存取相關的 Object (Resourse)。

( 2 ). 授權機制

存取控制主要是用來限制一個使用者的活動行為、執行的相關操作，以確保 資訊系統的安全性。(Sandhu and Samarati, 1996) 而相關專題報告同時也指出「執 行存取控制的主要目的在於限制非法使用者進入系統的資料存取，也有效地管制 合法使用者對於合法的範圍內執行管理者所授予的職權，以確保分工授權、合作 維護，以維護資料的完整性」。(樊國楨; 陳祥輝; 蔡敦仁)

存取控制(Access Control)機制主要分為以下三種：(Sandhu and Samarati, 1994 and 1996)

(1). 自由裁決的存取控制 (Discretionary Access Control, DAC)

資源(Object)的擁有者(Subject)可以自行設定其資源的存取權限(Right)， 例如: 當任一使用者欲存取某一個檔案時，檔案的擁有者可以自行任意決定 該存取者的存取權限。此種方式在執行上的彈性非常大，可以不受系統管理 者的約束，但相對的也將造成在管理上安全性的問題。

(2). 強制的存取控制 (Mandatory Access Control, MAC)

由系統管理者來進行權限(Right)的設定與控管，其將主體(Subject)與資 源(Object)分別進行安全等級(Security Level)上的分類，其中針對主體進行分 級的原因在於避免主體疏忽將較機密的資訊給外流出來，而針對資源進行分 級的原因在於以防機密性資訊外洩的風險。

(3). 以角色為基礎的存取控制 (Role-Based Access Control, RBAC)

RBAC 的概念最早於 1992 年由 Ferraiolo 與 Kuhn 等學者提出，其不同於 以往 DAC、MAC 之存取控制機制將存取的權限設定在使用者身上，且針對 權限相關規範進行管理，而 RBAC 的概念是以角色(Role)作為存取控制的主 體，將使用者與權限區隔開來，並將資料的存取權限設定於角色上而非使用 者身上，透過對使用者以指定角色的方式達到授權的機制，讓使用者取得不 同的存取權限。

2.4

Accounting

記錄使用者操作系統、資源存取過程中的各項紀錄(包含 Who、When、Where、 What 等)，例如: 資源或服務使用的資訊等，根據這些使用的情形除了能夠予以 計費之外，也可進行相關的分析或稽核等工作。

3、 混合雲單一登入

本節將分別探討何謂單一登入、單一登入機制所涉及的三個主要角色、兩種 不同的驗證類型、相關實作採用的技術，以實現本研究之混合雲單一登入。

3.1

單一登入

單一登入(Single Sign-On, SSO)是指使用者只須以一組身分識別，例如: 帳號 與密碼，即可讓使用者登入、存取不同的系統而不用再次重新進行身分驗證，因 此對使用者來說，其不需要記取其它不同系統的帳號與密碼，解決多組帳號的困 擾。

( 1 ). 主要角色

(1). 使用者 (User) 存取系統或網站的使用者。 (2). 服務伺服器 (Service Server) 提供服務的系統或網站。 (3). 驗證伺服器 (Authentication Server) 對欲存取系統或網站的使用者進行身分驗證的角色。 (廖英彥, 2005)

( 2 ). 驗證類型

一般單一登入的身分驗證主要可分為兩種類型：(尤淑芬、謝乙誠, 2009) (1). CA (Centralized Authentication) 整合各系統(服務伺服器)統一向 CA 驗證伺服器來驗證使用者身分，各 系統本身並不作身分驗證的工作，而將身分驗證的工作轉移到單一登入的驗

證伺服器上。此類型又稱為代理模式(Proxy Model) (廖英彥, 2005)，其運作 流程圖如下: (圖六) 圖 六：CA 驗證流程 (尤淑芬、謝乙誠, 2009) 以下將依序介紹圖中各步驟之說明: (a). 使用者對服務伺服器提出服務請求，服務伺服器返回給使用者系統 登入介面，並要求使用者提供其身分資訊(Credentials，如: 帳號與密碼)， 而使用者於系統登入介面輸入帳號與密碼進行登入。 (b). 服務伺服器將 Credentials 轉送給驗證伺服器進行驗證。 (c). 驗證伺服器將驗證結果回傳給服務伺服器。 (d). 服務伺服器回傳登入驗證結果給使用者，並依據驗證結果決定是否 提供服務給使用者。

(2). UID (Unique Identifier)

使用者直接於驗證伺服器所提供的登入介面進行登入與驗證，因此使用 者的帳號與密碼不再透過服務伺服器轉送至驗證伺服器來進行驗證，另外驗 證伺服器利用一次性的 token 當作使用者身分的唯一識別(UID)，並在 token 中加入時戳變數，避免此 token 遭非法使用者盜用。此類型又稱為重導模式 (Inform Model) (廖英彥, 2005)，其運作流程圖如下: (圖七) 圖 七：UID 驗證流程 (尤淑芬、謝乙誠, 2009) 以下將依序介紹圖中各步驟之說明: (a). 使用者對服務伺服器提出服務請求，服務伺服器以 HTTP Redirect 的方式，將使用者導向驗證伺服器進行身分驗證，使用者於驗證伺服器 提供之登入介面，輸入帳號與密碼進行登入。 (b). 驗證伺服器發放 token 給通過驗證的使用者。 (c). 使用者傳送 token 給服務伺服器。

(d). 服務伺服器向驗證伺服器驗證此 token。 (e). 驗證伺服器將驗證結果回傳給服務伺服器。 (f). 服務伺服器回傳驗證結果給使用者，並依據驗證結果決定是否提供 服務給使用者。

( 3 ). 驗證類型之比較

CA 與 UID 兩者主要的差別，透過以下兩種面向加以分析說明：(尤淑芬、 謝乙誠, 2009) (1). 安全性 對 CA 而言，在服務伺服器轉送使用者帳號與密碼給驗證伺服器的過程 中，一定得透過安全傳輸的管道將資料加密作傳輸，以防止密碼在傳輸過程 中被竊取。若密碼不慎遭到竊取，在使用者更改密碼前，非法使用者皆可獲 得存取權限，因此安全性較低。 對 UID 而言，由於驗證伺服器頒發的 token 設有有效期間，因此一旦 token 不慎遭到竊取，只要 token 有效期間過後，非法使用者便無法獲得存 取權限，因此安全性較高。 (2). 複雜度 由於 UID 必須使用複雜的演算法與足夠的變數來產生 token，因此在複 雜度上比 CA 來的高。 表 一：CA 與 UID 比較表 (尤淑芬、謝乙誠, 2009)

( 4 ). 知名雲端商驗證方式

以目前知名的雲端提供商(如: Google 等)，其通常都會提供單一登入的驗證 方式，而此種方式驗證方式與上述(二) token 驗證的類型相似。這代表著使用者 必須透過雲端提供商所提供的登入介面登入至雲端平台後，(即上述(二)所提到的 使用者於驗證伺服器提供之登入介面進行登入)，才可使用相關雲端服務(如: Google Drive、Google Calendar 等)。接著，使用者便可透過登入雲端平台所獲得 的 token 來存取任一雲端服務，而不用再次輸入帳號與密碼，進而達到單一登入 的效果(圖八)。 (Harry Katzan, Jr., 2010)

圖 八：雲端驗證方式 (Harry Katzan, Jr., 2010)

3.2

OpenID Connect

( 1 ). 定義

OpenID Connect 為 OpenID Foundation (OIDF)所規範的一種以使用者為中心 (User Centric)及 OAuth 2.0 為基礎之身分驗證與權限授權的開放標準，提供友善 的 APIs 給客戶端(Client)來介接，讓客戶端藉由 OpenID Connect 機制來完成對使 用者(End-User)的身分驗證，以及透過 OAuth 2.0 標準取得使用者相關資源存取 權限的授權。

此外，OpenID Connect 也實現了單一登入的機制，對使用者而言，其只需擁 有一組 OpenID 的帳號密碼且經過驗證後，即可在任何支援 OpenID Connect 的網

站直接登入，並使用其服務。解決了以往使用者需分別記取不同網站的帳號密碼， 以及存取不同網站時，需一再輸入帳號密碼的問題。 以下將分別介紹 OpenID Connect 流程中所涉及的主要的角色，以及五種基 本元件之功能說明：

( 2 ). 主要角色

(1). 使用者 (End User)

又稱作 OAuth 2.0 Resource Owner，為存取網站或應用程式的使用者。 (2). 依賴方 (Relying Party ; RP)

又稱作 OAuth 2.0 Client，為提供服務的網站或應用程式等，其透過 OP 端來對使用者進行身分驗證，並取得使用者於 OP 端上的資源存取權或使用 者相關資訊等。

(3). OpenID 身分提供者 (OpenID Provider ; OP)

又稱作 OAuth 2.0 Authorization Server，為提供使用者註冊身分識別帳號， 以及提供 RP 端身分驗證與授權服務(如: 在使用者同意之下，授予 RP 端存 取使用者相關資源的權限)。

( 3 ). Authorization Code Flow

說 明 OpenID Connect 運 作 的 流 程 ， 以 OAuth 2.0 (RFC6749) 規 範 之 Authorization Code Flow 為例: (圖九)

圖 九：OpenID Connect - Authorization Code Flow (OpenID Foundation 官網) 以下將依序介紹圖中各步驟之說明:

A. Client 向 Authorization Server 提出驗證請求，並把 Resource Owner 的 User-Agent 導向 Authorization Endpoint 進行驗證。其中驗證請求將傳送 相關的參數(如: Client ID、Redirection URI、Scopes 等)。

B. Authorization Server 透過 User-Agent 來驗證 Resource Owner，並詢問 Resource Owner 是否授予 Client 相關資源存取權，即 Client 資源的宣告 (Scopes)，或者是駁回 Client 的存取申請。

C. 若 Resource Owner 同意授權後，Authorization Server 會把 User-Agent 導回先前指定的 Redirection URI，並夾帶 Authorization Code。

D. Client 向 Authorization Server 的 Token Endpoint 提出授權 Token 請求。 其中授權 Token 請求將傳送相關的參數(如: Client ID、Client Secret、 Redirection URI、Authorization Code 等)

E. Authorization Server 驗證 Client 之 Credentials(Client ID、Client Secret)， 以及 Authorization Code，並回傳授權 Token(Access Token)與可選的 Refresh Token。

而 Access Token 主要用來存取 Authorization Server 所提供的 API，以 Google 為例，當 Client 相關資源的宣告含有 Google Drive 資源時，Client 能以 Access Token 存取 Google Drive Endpoint，來對使用者雲端硬碟進行相關操作。另外， 由於 Access Token 具有時效性，一旦超過時效 Client 便無法進行 API 的呼叫，因 此可藉由 Refresh Token 再向 Authorization Server 重新換取新的 Access Token。

( 4 ). 安全性

以 Authorization Code Flow 為例，由於 Client 不直接向 End User 要求資源存 取許可，而是把 End User 導向 Authorization Server 要求許可，Authorization Server 在透過轉址來告訴 Client 授權許可碼(Authorization Code)，因此在轉址回去前， Authorization Server 會 先 驗 證 End User 並 取 得 授 權 ， 而 End User 只 向 Authorization Server 進行驗證，所以 Client 絕不會拿到 End User 的帳號與密碼， 增加了 End User 帳戶的安全性。

此外，當 End User 驗證完後，Authorization Server 並不會立即回傳授權 Token 給 Client，由於在返回的過程中皆會經過 User-Agent，為了避免惡意程式非法偷 竊 User-Agent 上的資訊，因此改以 Authorization Code 的方式讓 Client 再次向 Authorization Server 來換取授權 Token，更提高了安全性。

3.3

Keystone

( 1 ). 定義

Identity Service (code-named Keystone)在 OpenStack 架構中，負責提供身份驗 證與授權，其中授權的部分以角色為基礎作為資源存取的控制(RBAC)。而 OpenStack 其他元件透過 Keystone 來註冊服務存取位置(Endpoint)，並記錄在服 務註冊表(Service Catalog)中，作為各服務(如: Nova、Glance、Neutron 等)之間相 互調用之依據。此外，Keystone 也提供友善的 APIs(如: Identity API v2.0 or v3)給 客戶端(Client)來介接。

( 2 ). 外部驗證機制

Keystone 提供三種不同的驗證機制，例如: 根據使用者的帳號密碼來與 Identity Backend 進行驗證的 user/password 機制，或以 token 進行驗證的 token 驗 證機制，以及外部驗證機制(External Authentication)。而外部驗證的方式，主要 是透過其他第三方的身分驗證機制(如: OpenID Connect、Kerberos 等)來完成 Keystone 的驗證。 (OpenStack 官方文件) 實際的運作流程架構(如圖十)所示，藉由實作 Keystone 客製化之中間軟體， 作為第三方驗證與 Keystone 兩者之間溝通的橋樑，通過第三方驗證的使用者將 透過 REMOTE_USER 環境變數，讓 Keystone 得知此為合法使用者，進而完成 Keystone 驗證機制，並取得 OpenStack 服務的存取權(Token)，以及該使用者角色 資訊(Role)。

3.4

Kerberos

( 1 ). 定義

Kerberos 為美國麻省理工學院(MIT)雅典娜計畫所訂定的一種網路驗證通訊 協定，其主要被設計用於主從式架構中(Client-Server Model)，提供客戶端與伺服 器端進行相互的驗證，是一種集中式的身分驗證機制，也是常見單一登入的解決 方案。 (Wikipedia ; 教育部顧問室資通安全聯盟)

( 2 ). 主要角色

以下將分別介紹 Kerberos 驗證流程中所涉及的主要的角色: (1). 客戶端 (Client) 欲存取服務伺服器的使用者。 (2). 服務伺服器 (Service Server ; SS) 提供使用者服務的伺服器。(以 Hadoop 私有雲為例，服務伺服器可以是 NameNode)

(3). 驗證伺服器 (Authentication Server ; AS)

負責使用者的身分驗證，並簽發 TGT(Ticket Granting Ticket)給予驗證成 功的使用者。

(4). 票證簽發伺服器 (Ticket Granting Server ; TGS)

負責使用者服務存取的授權，即使用者以 AS 所簽發的 TGT 來向 TGS 請求欲獲得能夠存取服務伺服器的 SGT(Service Granting Ticket)。

綜合上述，其中 AS 與 TGS 通常由客戶端與服務伺服器端共同信賴之第三 方角色擔任，兩者又統稱 KDC (Key Distribution Centers)，提供票證(Tickets)授與 的服務。

( 3 ). Kerberos 驗證流程

要用來儲存客戶端以及服務伺服器端分別與 KDC 所分享的密鑰(Secret Key)，例 如: 儲存客戶端將其密碼透過單向函數之 DES 對稱式加密演算法所產生的密鑰。 另外，圖中的 Application Server 即意旨服務伺服器。 圖 十一：Kerberos 驗證流程圖 (IBM) 以下依序介紹圖中各步驟之說明(圖十一): (1). 客戶端向 AS 提出驗證請求，並以明文方式發送用戶 ID。 (2). AS 驗證該用戶 ID 為有效後，回傳 TGT 與 Key 給客戶端。 (3). 客戶端向 TGS 提出服務授權請求。 (4). TGS 驗證該 TGT 為有效後，回傳 SGT 給客戶端。 (5). 客戶端向服務伺服器提出服務存取請求。 (6). 服務伺服器開始提供服務給客戶端。

4、 雲端儲存技術及其發展

資料儲存的發展歷史從單一大型主機連接著硬碟，到和大型主機分離且擁有 獨立、專有的控制器的儲存系統。隨著時間發展，資料和應用越來越大，根據國 際數據公司 IDC (2013)的研究，全球的原始儲存器容量從 2012 年的 2,596 Exabytes (EB)到 2017 年時將升為 7,325 Exabytes (EB)，資料儲存增長速率比以往 都還要快，IDC 估計到了 2020 年全球資料儲存量將達到 35,840 Exabytes (EB)。 舊的儲存架構無法適應新的應用需求，資料儲存也有了新的發展，以下針對雲端 儲存和相關技術進行探討。

4.1

雲端儲存發展趨勢

雲端儲存或者是基於雲端的儲存，是從雲端運算概念上延伸和發展出來的一 種網路儲存的模式(Wikipedia, 2015;韦小凤, 2013)，其實際資料儲存分布在多台通 常是位在不同地點的伺服器上。有資料儲存需求的人或組織向雲端儲存提供商來 租賃或購買儲存空間，而提供商需確保儲存資料的可用性和可存取性。

Taneja Group 定義基於雲端的儲存(cloud-based storage)是儲存器在雲端上 (storage in the cloud)這個大領域之下的一個類別。儲存器在雲端上涵蓋了傳統的 託管儲存(hosted storage)，其包含提供從遠端或是在託管的環境下經由 FTP、 WebDAV、NFS/CIFS 或是 Block Protocols 來存取。而基於雲端的儲存則是託管 儲存技術的演進，其為儲存提供了更複雜的 API、命名空間(namespaces)、檔案 或資料的虛擬化和管理工具，圖六顯示基於雲端的儲存演進。

圖 十二：基於雲端的儲存演進(引用自 Tenaja Group) 雲端儲存已經成為未來儲存發展的一種趨勢，但隨著雲端儲存技術的發展， 各類搜尋、應用技術和雲端儲存相結合的應用，還須從安全性、可攜性以及資料 存取等角度進行改進。  安全性 從雲端運算誕生，安全性一直是企業的首要考慮問題之一。同樣在雲端儲存 方面，安全仍是首要考慮的問題。許多用戶對雲端儲存的安球要求甚至高於他們 自己的架構所能提供的安全水平。儘管如此，許多大型、可信賴的雲端儲存提供 商建置了比多數企業資料中心更安全的資料中心，提供的雲端儲存具有更少的安 全漏洞和更高的安全環節。  可攜性 一些用戶在託管儲存的時候還要考慮資料的可攜性。一些大型服務提供商所 提供的解決方案保證其資料可攜性媲美最好的傳統本地儲存。有的雲端儲存結合 了強大的可攜功能，可以將整個資料組傳送到你所選擇的任何媒介，甚至是專門 的儲存設備。  性能和可用性

過去一些託管儲存和遠端儲存總是存在著延遲時間過長的問題。同樣的，網 際網路本身的特性就嚴重威脅服務的可用性。隨著雲端儲存技術的不斷發展，各 廠商將持續努力實現容量最佳化和廣域網路(WAN)最佳化，已盡量減少資料傳輸 的延遲性。  資料存取 現有對雲端儲存的疑慮還在於：如果執行大規模資料請求或是資料復原操作， 那麼雲端儲存是否可以提供足夠的可存取性。在未來的技術條件之下，現有的廠 商可以加大量資料傳輸到任類型的媒介，可將資料直接傳送給企業，且速度之快 相當於複製、貼上操作。 雲端儲存不只是託管儲存更是一種服務，IBM (2009)提出資料儲存即服務 (data-Storage as a Service)，並以 Amazon S3、Nirvanix SDN 為例。現今，各類儲 存即服務(Storage as a Service, StaaS)提供商林立。而在使用上，使用者不論何時 何地，只要透過 Web 介面的應用程式，即可以透過網際網路存取資料，而有的 雲端儲存服務更允許你授權給其他使用者存取資料，讓個人的資料變成可以團隊 進行協同工作。

4.2

軟體定義儲存

軟體定義儲存(Software Defined Storage, SDS)是一種資料儲存方式，所有儲 存相關的控制作業都放置在相對於實體儲存硬體的外部軟體中。這個軟體不是作 為存放設備硬體的一部份，而是在一個伺服器上或者作為作業系統(OS)或 Hypervisor 的一部分(Wikipedia, 2015;吴迪, 2013)。軟體定義儲存和傳統儲存系統 陣列差異，如表二。 表 二：軟體定義儲存和傳統儲存陣列差異(本研究整理) 軟體定義儲存 傳統儲存陣列 標準化 儲存控制器功能可以運 行在任何類型的伺服器 不同廠商的不同儲存設 備，有各自獨立的儲存控

硬體上，且可以放置在任 何位置。 制器，且必須放置於特定 硬體上。 靈活度 通常可以透過 REST API 來進行操作。 透 過 命 令 列 介 面 (CLIs) 或是 SMI-S API。 可擴充性 節點可進行擴充，沒有實 際上數量的限制。 基於控制器設置，連接的 硬碟數量有限。 多租戶 多租戶架構，每個租戶獨 立的工作負載，甚至能自 動配置儲存。 為了確保系統的服務品 質，很可能每一臺儲存設 備只能讓特定應用程式 來存取。 整合性 可跨越 NAS、SAN、Flash 陣列、物件式儲存等不同 的儲存設備，做到儲存資 源的統籌使用。 有限的整合，例如：SAN 和 NAS 的整合設備。 利用軟體定義儲存，將存儲服務從底層的專利硬體中抽象出來，可以提升運 營效率，提供透明的資料移轉。由於降低了管理的複雜性，其可讓各種雲端應用 更高效運行，並可進行低成本的擴展。IDC 於 2013 年所做的對全球範圍軟體定 義存儲市場的分類調查表明，軟體定義儲存具備以下一些特徵：  軟體是其中的關鍵。它可在異構的、商品化硬體環境下運行，且可充分利用 組織現有的存儲基礎架構。  軟體定義儲存可提供全面的存儲服務。  軟體定義儲存可對來自不同地點的物理存儲容量，包括內部磁片、快閃記憶 體系統和外部存儲系統進行聯邦式管理，並很快可將這種管理擴大到各類雲 以及雲物件平台。  軟體定義儲存可利用統一的單一 API 進行程式設計，然後通過各類入口網

站進行管理。 軟體定義儲存看起來能夠幫助企業從傳統的儲存基礎設施，轉向一個更加靈 活、雲端化且是軟體定義的環境，並可以更有效率地進行管理，一旦正確部署了 軟體定義儲存，便可預期獲得以下效益：  自動選擇內部儲存資源和雲端儲存資源。  策略編排的儲存資源可最佳化性能，提高效率。  分析導向的軟體定義儲存和資源優化可滿足不可預測的業務需求。  使用開放的 API、工具，因此在跨混合雲環境中，可以很容易重複使用儲存。

4.3

OpenStack Swift

OpenStack 是一個開放原始碼的雲端運算管理平台專案，有幾個主要的元件 組合起來完成具體工作，而 Swift 則為其中的物件儲存(Object Storage)元件。有 別於傳統檔案系統，OpenStack Swift 就像 Amazon S3 一樣，是一個儲存，例如： 虛擬機映像檔、照片、email、備份和檔案與其他非結構化資料的分散式儲存系 統，並提供良好的可擴充性(Scalable)、冗餘性(Redundancy)和牢靠性(Durable)。 OpenStack Swift 可以安裝在一般的商用硬體上，這表示標準、低成本的伺服 器組件可以用來建置儲存系統。藉由 Swift 提供邏輯上的資料管理而不是廠商專 有的硬體，可以輕易的彈性部署、擴充儲存系統，這就是軟體定義儲存本質上所 定義的。

OpenStack Swift 由八個處理程序(Processes)和服務(Services)組成其架構，分 別為：Proxy Server、The Ring、Object Server、Container Server、Account Server、 Replicator、Updaters 和 Auditors，以下將以 Swift 功能面分別探討各元件。

( 1 ). 伺服器處理程序

Swift 的伺服器處理程序(Server Processes)包含 Proxy、Account、Container 和 Object。當一個節點上單獨執行 Proxy Server，則稱該節點為代理節點(Proxy Node)，而當一個節點上至少執行了 Account、Container 和 Object Server 三者其

中一項，則稱之為儲存節點(Storage Node)，如圖七所示，儲存節點上還會執行 其他服務以維持資料的一致性。

圖 十三：儲存節點(引用自 SwiftStack 官方網站)  Proxy Server

代理伺服器(Proxy Server)為 Swift 架構中對內的溝通橋梁，且是對外部的客 戶端溝通的唯一管道，在上面的所有訊息傳遞都是透過標準的 HTTP 動詞，例如： GET、PUT、POST 以及 DELETE。代理伺服器採用 shared-nothing 架構，表示其 一個部署的代理節點(Proxy Node)都是獨立、自給的，且它可以根據負載需求來 進行擴充，在一個 Swift 叢集之中應該至少要部署兩個代理節點，當其中一個出 問題，另一個可以接手。

 Account Server

帳號伺服器(Account Server)提供每一個帳號(Account)的 Metadata 和帳號內 的容器(Container)列表，其資料存在於 SQLite 資料庫中。

 Container Server

容器伺服器(Container Server)的主要工作為管理其 Metadata 和提供容器內所 擁有的物件(Object)列表。容器伺服器不知道物件的存放位置，只知道物件所屬 的容器，其資料存在於 SQLite 資料庫中。

 Object Server 物件伺服器(Object Server)提供了二進位大型物件(Blob)儲存服務，可以儲存、 檢索和刪除位於節點硬碟上的物件。物件是使用其包含 Partition 的路徑和操作的 時間戳記(Timestamp)在硬碟上存為二進位檔案，時間戳記可以讓物件伺服器儲 存該物件的多個版本，並找到最新版本。除此之外，物件的 Metadata 是存放在 檔案的延伸屬性(xattrs)，這樣的設計可以確保物件資料和 Metadata 儲存在一起。

( 2 ). 一致性處理程序

OpenStack Swift 是很 牢靠的，主要是因 為 一致性處理程序 (Consistency Processes)，其是用來處理故障，並且能夠找到和更正無論是資料損壞或是硬體 故障所引起的錯誤。一致性處理程序主要包含兩個服務 Auditors 和 Replicators， 這兩個服務會在儲存節點上執行以確保資料整合性和可用性。  Auditors 稽核器(Auditors)會在所有儲存節點上背景執行，帳號、容器和物件伺服器 皆會有相對應的稽核器服務，其會不斷掃瞄所在節點上整個硬碟內儲存資料的完 整性，確保沒有資料損壞。當錯誤發生稽核器會把損壞的資料移動到隔離區。  Replicators 複寫器(Replicators)會在所有儲存節點(Storage Node)上背景執行，帳號、容 器和物件伺服器皆會有相對應的複寫器服務，其會不斷檢查所在節點上的資料和 叢集內其他節點上對應的資料，如果其他節點上的資料是比較舊的或是遺失，則 複寫器會推送(Push)一份所在節點上的資料過去更新，而如果所在節點上的資料 是比較舊或是遺失，則不會從其他節點拉(Pull)一份資料過來。 複寫器也處理物件和容器的刪除，物件刪除藉由建立一個 0 位元組的且以.ts 為副檔名的墓碑檔案作為該檔案的最新版本，而複寫器會把該墓碑檔案推送到其 他節點也作為此檔案的最新版本，如此該物件就代表被整個系統所刪除。容器刪 除則藉由把該容器標記為已刪除，複寫器則會把這個版本推送到其他節點，如此

該容器就代表被整個系統所刪除。  Updaters

分為容器更新器(Container Updater)和物件更新器(Object Updater)，容器更新 器主要工作是確保帳號的容器列表是最新的，除此之外，還會更新存放在帳號的 Metadata，包含物件數量、容器數量和總共使用了多少位元組。物件更新器則是 作為一個備援機制，更新容器內的物件清單，該工作主要是由物件伺服器來執行， 當失敗時才會由物件更新器來執行確認物件清單並進行更新存放在容器的 Metadata 的物件數量和總共使用的位元組資料。

( 3 ). 資料存取

Swift 為了有效的跨叢集來存放資料，並可以快速存取，其資料存放模型如 圖八，其中一個儲存節點內可能會有很多個硬碟(Disk)，而 Partition 則是目錄的 概念，所以每一個硬碟內則會有多個 Partition。 圖 十四：儲存節點、硬碟和 Partition 關係(引用自 SwiftStack 官方網站) 帳號、容器和物件資料是分散存放在多個節點之上，當伺服器處理程序和一 致性處理程序需要對資料進行操作時，會利用資料的儲存位置，例如：(/account, /account/container, /account/container/object)向 對應的 Account Ring 、 Container Ring 和 Object Ring 來找到資料所在的位置。

 The Ring

雜湊(Hash)演算法所產生。Ring 存在於叢集內的每一個節點上，Ring 中每一個 Partition 在叢集中都預設有 3 個副本(Replica)，且 Ring 會維護其位置。

4.4

雲端資料管理介面

由於各家雲端儲存提供商的儲存系統標準不一，透過標準化的介面，即便各 家系統內部有不同的運作功能和標準，也能透過統一的介面進行溝通。儲存網路 產業協會(Storage Networking Industry Association, SNIA)是當前雲端儲存標準的 主要推動者，其主要致力於推廣儲存系統統一標準與 API 介面的開發作業。SNIA 在 2010 年 4 月正式發布雲端資料管理介面(Cloud Data Management Interface, CDMI) 1.0。

如圖九所示，該模型顯示了多種可以支援傳統和新的應用程式的雲端資料儲 存介面，這些介面都允許依照需求來提供從資源集區(Resource Pool)取出的儲存， 而相關的容量則是從儲存服務(Storage Services)提供的儲存容量來取得。資料服 務(Data Services)是根據其資料系統的 Metadata 來套用於各個物件上，而這些 Metadata 都是在各個物件的基礎之上或是專為多組由物件組成的容器(Container) 明確說明其資料的需求。其中 CDMI 是定義了應用程式使用新增、抓取、更新、 刪除(CRUD)雲端資料的功能介面，其功能還包含了管理用來存放資料的容器。 CDMI 介面也可以讓行政管理應用程式來管理容器、網域(Domain)、安全存 取(Security Access)和監控(Monitoring)記帳(Billing)資訊，即使該儲存功能是透過 傳統或是專有的協定。

圖 十五：Cloud Storage Reference Model(引用自 CDMI v1.1.1)

CDMI 是建置於 HTTP 的標準之上，所以允許使用 HTTP 的客戶端和 CDMI 伺服器進行溝通。這也使得 CDMI 的操作是可以和其他以 HTTP 為基礎的儲存 協定，例如：WebDAV、Amazon S3 和 OpenStack Swift，是同時並行的。

表 三、表 四為 CDMI 所規範的 HTTP 操作物件和容器的整理。 表 三：CDMI 物件 HTTP 操作(資料來源：CDMI v1.1.1) 操作說明 HTTP URI

建立資料物件 PUT <root URI>/<ContainerName>/<DataObjectName> 建立資料物件 POST <root URI>/<ContainerName>/

取得資料物件 GET <root URI>/<ContainerName>/<DataObjectName> 更新資料物件 PUT <root URI>/<ContainerName>/<DataObjectName>

刪除資料物件 DELETE <root URI>/<ContainerName>/<DataObjectName> 表 四：CDMI 容器 HTTP 操作(資料來源：CDMI v1.1.1)

操作說明 HTTP URI

建立容器物 件

PUT <root URI>/<ContainerName>/<NewContainerName>/

刪除容器物 件

5、 檔案同步服務

現代人在日常生活中有越來越多的各類型運算裝置，例如：工作上會使用筆 記型電腦、家裡有台桌上型電腦、而身邊則隨時有手機甚至平板。眾多不同的裝 置雖然讓我們在生活上管理個人資訊很方便，可是如果要在眾多裝置上去管理特 定檔案則是很困難的(Dearman and Pierce, 2008)。

5.1

檔案同步服務模型

由於要在眾多裝置上管理檔案是很困難的，所以對於檔案同步服務(File Synchronization Services, FSS)需求也隨之增加，此類型服務可以透過一個單一的 介面去管理所有裝置上的檔案，並能夠確保在各裝置上的資料版本是一致的。

圖 十六：兩種檔案同步服務的模型(Xianqiang, Bao, et al., 2011)

圖十是(Xianqiang, Bao, et al., 2011)歸納的檔案同步服務的兩種模型，檔案同 步服務通常會要使用者在需要進行檔案管理的裝置上安裝客戶端軟體，安裝完成 後會需要指定一個檔案同步目錄，而各裝置上的同步目錄都會對應到服務提供商 雲端儲存上的同一個空間，當同步目錄內的檔案發生異動(CRUD)操作，客戶端

軟體會把檔案自動同步到其他裝置上的同步目錄以確保檔案資料一致性。 檔案同步服務通常也會提供網頁介面，允許登入的使用者對雲端儲存伺服器 進行檔案上傳或下載檔案，而透過網頁進行上傳檔案的操作也會把檔案同步到其 他裝置上的同步目錄。

5.2

檔案同步機制

SyncViews 為(Xianqiang, Bao, et al., 2011)針對檔案同步服務提出的作法，其 在檔案同步運作上分為兩種更新操作(新增、更新、修改、刪除)，其分別為 Local Update、Remote Update 和兩種掃描操作，其分別為 Local Scan、Remote Scan。 Local Update 代表使用者在客戶端的同步目錄對檔案進行更新操作；Remote Update 代表伺服器上同步目錄裡面檔案的更新操作。Local Scan 代表已登入的客 戶端定期會去檢查是否有更新操作；Remote Scan 代表已登入的客戶端會定期去 檢查伺服器上的歷史性更新操作，確認是否有 Remote Update。

如圖十一，在 SyncViews 系統中使用者同步目錄內的所有檔案和資料夾的快 照被定義為一個 View，而同一位使用者可能會有多個不同裝置，因此也會有著 多個 View，例如_{𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉ℎ𝑜𝑜𝑜𝑜𝑜𝑜}和_{𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑤𝑤𝑜𝑜𝑤𝑤𝑤𝑤}，這些不同的 View 都會對應到伺服器端的 同一個 View，以維持不同裝置間檔案一致性。而 SyncViews 在伺服器端則包含 三個元件分別為 control-server、meta-server 和 storage server。其工作分配為 control-server 主要 負責 處理 從 客 戶端 傳 送過 來 的 請求， 和把更 新操作 傳 給 meta-server 儲存在 ChangeRecords 資料表以及把檔案儲存在 storage-server，除此 之外 meta-server 上還會有存有一份檔案相關資料，即是系統定義的 View，該資 料表名為 Snapshot。

5.3

企業檔案同步與分享服務

隨著雲端運算各種模式服務的發展，其中雲端檔案同步與分享服務，例如： Dropbox、Google Drive 等也越來越普及，此類型的服務亦被眾多企業組織所採 用，並在未來會逐漸的增長(IDC, 2014)，因此國際研調機構 Gartner (2014)也把此 類服務定名為企業檔案同步與分享(Enterprise File Synchronization and Sharing, EFSS)。EFSS 市場已漸漸成熟，各服務供應商基本除了檔案同步和分享之外， 有可能在移動性、安全性、行政與管理、後端伺服器整合、檔案內容處理、協同 合作、操作介面簡易性和易用性和雲端儲存這幾個面向提供不同程度的加值服務， 以此來做出差異化。 Gartner (2014)歸納出各供應商所提供的 EFSS 服務可以分為三種架構，如 下：  Cloud 企業組織的檔案是儲存在服務供應商的雲之上，其可以透過行動裝置進行存 取和分享。會偏好這種架構的企業組織通常是想以能夠在 IT 控制之下的企業級 替代方案取代員工的個人雲端服務，並且同時能夠保留使用者體驗和移動式協同 合作。

 On-premises 遠端存取、同步和分享元件是在企業內部部署，並整合了企業資料儲存庫， 而且不再額外進行檔案副本。對於資料儲存有嚴格規範的企業組織會偏好選擇此 種架構。  Hybrid 使用者和裝置的驗證、安全以及搜尋機制是由服務供應商的雲所實作且提供， 檔案和文件則保留在企業組織原有位置或是儲存在第三方的雲之上。企業組織不 需要在其他供應商的雲之上額外建立資料副本，以此來簡化行動裝置用戶經由雲 端存取組織資料，會偏好此種混合式架構。 而 EFSS 服務的類型則可以分為兩種，如下：  Destinations 企業組織購買該產品的主要目的就是為了此產品的檔案同步和分享功能。  Extensions 某種產品或應用，例如：協同合作、內容管理或儲存，在額外附加上檔案同 步和分享的功能。

第三章、 研究方法：系統設計與架構

1、 系統概述

為解決在混合雲環境下，會遇到的帳號整合以及檔案資料一致性和權限的問 題，本研究將實作出系統來整合使用者本地端以及公、私有雲端上的帳號、並進 行檔案同步與權限管理。使用本系統，使用者可以方便管理自己在多個不同本地 端，例如：家用桌上型電腦、公司筆記型電腦，以及私有雲，例如：OpenStack、 Hadoop，和公有雲端服務，例如：Google、Dropbox、Microsoft 和 Amazon 等的 檔案資料，並且能夠即時在不同雲端平台和裝置間進行檔案同步，以確保檔案資 料的一致性。使用者可以透過統一的入口來管理多個雲端平台上的檔案，並設定 存取權限，進行檔案分享。 圖 十八：使用案例圖

2、 系統架構

本系統架構設計考量了，使用者本地端、私有雲端以及公有雲端提供商的混 合雲環境，並可根據該架構來彈性擴充介接的私有雲和公有雲儲存服務，圖十九 為本系統之 UML 部署圖，詳細各元件功能描述以下分述。

2.1

系統元件說明

( 1 ). Client

系統中的客戶端(Client)端為 Linux 和 Windows 桌面應用程式，需要由使用 者自行安裝於本地端電腦上，程式啟動時會要求使用者以現有雲端帳號登入而不 需要註冊。登入成功後，系統會把相關使用者資料寫進 SQLite 資料庫，並在本 地端檔案系統新建一個系統專屬的監控資料夾，裡面會預設有目前已登入的雲端 服務資料夾。使用者可以再手動進行連結其他雲端服務，登入成功後同樣會在系 統專屬監控資料夾內建立連結的雲端服務資料夾，並啟用同步。 使用者在監控目錄內進行的檔案異動操作，例如：新增檔案、修改檔案、重 新命名檔案以及刪除檔案和資料夾異動操作，例如：新增資料夾、重新命名資料 夾、刪除資料夾，這些操作皆會被客戶端程式攔截並通知同步伺服器(Sync Server)， 以及進行後續的檔案同步工作。

( 2 ). Web Server

網站伺服器(Web Server)角色定位為系統的入口網站(Portal)，為系統提供了 單一驗證窗口和檔案同步以及管理，單一驗證窗口除了允許使用者以 OpenID 方 式登入外，也提供讓客戶端應用程式使用網頁介面進行登入。入口網站彙整了登 入使用者所有已連結雲端服務，並提供使用者進行和客戶端程式一樣的檔案同步 功能和額外的檔案下載功能。網站伺服器上也提供了檔案操作相關的 REST API， 允許有權限的第三方程式或用戶來介接。 在入口網站上，檔案管理服務讓使用者可以進行檔案分享功能，並且可以設 定檔案存取權限，例如：公開或是私人，透過由系統所提供的檔案存取網址，只 要得到該網址並符合權限的用戶就可以進行檔案下載。