工研院資通所 鍾勝民、王子夏

雲端服務已協助數以萬計的公司降低IT基礎建設的成本，並達到前所未見的靈活性、可用性及可擴展性。在這樣的誘因下，許多企業員工被默許bring your own clouds （BYOC）到企業中。但資料外流一直是企業的營運風險之一，BYOC可能帶來的危機不容小覷。按Ponemon Institute的報告[1]，造成資料外流的主因中，47%是惡意攻擊；這樣的高比例將因雲端服務的「資料外放」本質而加劇。面對這般攻擊，您該做且能做什麼？

多層次防禦架構

近年來除了美國政府與Yahoo等被駭事件中上億個資外洩，今年七月瑞典總理亦承認二年來政府將數以百萬計的公民個資外存於遠在捷克一個管理失當的外包儲存空間[2]，導致詳盡個資長期暴露於高風險環境中，為傳奇資安錯事（legend security fuckups）再添一樁。雖然這麼多的傳奇天天上演，但其實演的都是老梗的金庫竊盜案。

的確，對於駭客而言，雲端系統無疑就是一個充滿誘惑的自動化無人金庫，系統內部所擁有的大量機密資料則是駭客想取得的財物，也是他們冒著風險闖入的最大動力。傳統具有防火牆、身分認證等防禦的雲端系統不過是裝有「自動身分辨識」的門禁，駭客總能像「不可能任務」一樣繞過或偽裝闖入，之後便用各種新奇的工具破壞金庫、搬走財物，甚至加裝工具於金庫以備他們日後的「不時之需」。

圖 1　雲端資安多層次防禦架構

面對這般老梗，工研院資通所團隊認為有必要為故事加料，改變故事結局。我們提出「多層次防禦架構」，讓雲端服務業者如圖一所示進行縱深聯防。簡單來說，在假設駭客突破防火牆的自動身分辨識門禁下，「應用程式白名單技術」就像在整座金庫安裝科幻電影中的「動力消除器」：儘管駭客進入，「規範之外」的工具將喪失動力。因此即便駭客能攜帶工具突破門禁，也沒有動力破壞金庫。

沒有動力，若駭客能像湯姆․克魯斯（Tom Cruise）有一雙神手，那又如何？「輕量化虛擬機技術」這時就發揮作用。此技術猶如將金庫切割為多個子金庫並進行隔離，即便駭客利用「神手」破壞金庫，也僅能夠取得一子金庫內之部分財物；正當駭客詫異財物如此之少時，虛擬機技術已透過異常偵測診斷，逐步加強I/O封鎖，最終將駭客的可活動範圍完全隔離。

最後，這故事的精彩大結局是當駭客細看「財物」的那一刻，嚇！怎麼全是匯票，那是擁有匯票印鑑之財物持有者才能兑現的。沒錯，我們希望這故事的讀後感是—早知如此，駭客就不該冒著曝光危險而光顧金庫了。

如果您還滿意這樣的故事結局，建議您繼續往下一探這故事中的精彩技術。

應用程式白名單技術

根據賽門鐵克2017年網路安全威脅報告指出[3]，多數資訊管理人員認為自家企業內採用的雲端應用數量為40種，但實際調查結果指出其數量逼近1,000種，代表在大部分的企業組織中，有近960種可能的攻擊入侵點隱藏在管理者監控的死角當中。因此，為了確實掌握系統上所有運行之應用服務，我們需要一個主動式與持續式的安全防護機制。

如故事中提到，「應用程式白名單技術」就像是在整座金庫安裝「動力消除器」，假使駭客有足夠能力突破防火牆的自動身分辨識門禁，他們的新奇工具不但會因「不在規範內」而喪失動力，更會觸發警報；沒有動力的工具是難以破壞金庫取得內部資料的，更何況警報將導致系統更進一步的防禦。

技術上，本團隊所開發之白名單防禦技術透過主動進行安全應用程式執行的控管機制，將系統中「規範內合法」的執行程序預先紀錄於一白名單當中，不在名單上的程序將不會被CPU執行－猶如失去動力。以令人聞風色變之勒索軟體（Ransomware）為例，即便雲端系統被植入該軟體，仍可透過白名單防禦技術阻止程式執行，避免雲端服務資料遭惡意加密。白名單基礎檢測上已施行多年，然而工研院資通所團隊聚焦突破進階描述語言（Scripting）攻擊及行為式（Behavior）白名單管控等機制，針對作業系統中所有可執行的物件進行阻擋，範圍包含：二進位執行檔、動態連結程式庫檔、驅動程式以及腳本語言的執行進行檢測辨識，任何白名單外之程序皆無法於雲端服務系統上執行。

圖 2　雲端資安應用程式白名單防禦技術

此白名單防禦技術在系統上能提供兩種層級的部署檢測方法，第一種為在作業系統核心驅動程式中進行檢測，在效能上目前已能做到判斷時間達到50us以內的檢測效能，記憶體視檔案多寡而定也僅需要4～8MB。其二為統一在虛擬機監視器中對客體作業系統進行白名單檢測，此技術在實作上除本身白名單防禦外，將建置保護機制，能夠攔截除錯相關的系統呼叫、卸載指定驅動程式等行為以確保白名單防禦機制能夠正常運作，避免遭到惡意軟體關閉進而失去防護效能。

輕量化虛擬機技術

故事中所提到的「神手」，是指駭客在工具失去動力後，改用金庫內的原有設備去攻擊金庫。這時「輕量化虛擬機技術」就派上用場，此技術猶如將金庫進行切割為多個獨立運作的子金庫，即便駭客利用「神手」闖入金庫，也僅能夠取得某一子金庫內之部分財物。

技術上，子金庫就是一個個的虛擬機，彼此獨立，對內對外的資源存取皆可單獨控管而不影響其它虛擬機，因此可控制並隔離入侵損害範圍。當部署於各虛擬機之偵測機制發現異常，便立即進一步封鎖I/O隔離可能的威脅，避免其它虛擬機遭入侵。由於虛擬機技術可對於各種服務進行隔離保護，因此直接地增加整體雲端服務系統的攻擊承受力。

更進一步來說，本技術經由對各虛擬機的系統呼叫（System call）進行研析，觀察出虛擬機是否有不當行為甚至遭受入侵，並且可以同時透過使用者行為分析、機器學習與智能優化機制進行自動化建模、規則設定、異常診斷以及入侵威脅偵測，當系統判斷虛擬機行為異常時，則會主動將該虛擬機進行隔離，搭配沙箱診斷（Sandbox）解析異常肇因，確實掌握雲端服務系統與資料流相關應用資訊，避免機密資訊檔案遭分享外流而企業組織與雲端服務業者卻一無所悉。

而在虛擬機的架構下，本技術更可結合前述之白名單防禦技術，在虛擬機監視器中透過接收作業系統的硬體行為得知是否開機完成，並利用此時機，對客體作業系統進行系統服務的呼叫攔截與保護，令客體作業系統在執行任何程序的開始時間點進行白名單檢測。此技術的優點在於惡意軟體無法得知作業系統是否有此保護機制的存在，並且能夠在極低運算成本條件下完成防禦建置，達到輕量化虛擬機防禦部署，目前此技術在效能上已能在microsecond等級以內完成，並且已完成Linux驅動層級檢測與阻擋之單元測試，整合應用程式白名單服務架構至選定執行平台，包含Linux x86/64與Linux ARM系統核心層級與虛擬機層級白名單實現。

EDP－密文空間處理技術

上述二技術假設金庫管理人「有能力」落實防禦技術，以將損害降到最小；但若遭遇大師級駭客，或金庫管理人監守自盜，那即使只有一份機密資料的外洩都可能損失億萬！

事實上，基於對雲端業者之戒心以及對駭客的「敬畏」，資安專家對資料外放的忠告不外乎是「加密再上傳」[4]；但眾所皆知，加密後資料不但難以管理、無法操作，就連最基本的檢索功能都喪失。這樣的矛盾，本故事精彩大結局以「密文空間處理技術－EDP」予以解決。

技術上來說，有別於傳統加密法（如AES、RSA等）不具雲端運算可能性，EDP的重點正在於賦予加密後文件（簡稱密文）的可用性；它是密碼學的應用，其效果常令人嘖嘖稱奇。以EDP的「極品」為例[5]，當使用者要求雲端伺服器計算（如3+5），而伺服器回傳答案（8）後，伺服器竟不知道計算過程中的輸入值、中間值及輸出值，換句話說，伺服器可以蒙著眼算對答案；相同的邏輯讓故事中的金庫管理人一樣能對匯票進行金融作業，但沒有匯票持有人的印鑑，財物無法兌現。

當然，也許不是每個人都有上述如匯票金融般的外包運算力需求，但您總有須把特定匯票取回的時刻。傳統的加密就好比無法管理的匯票－金庫管理人只能把全數匯票交還持有人，讓持有人逐一查看哪張是他要的；但當匯票數以萬計，相信沒有人有這般閒功夫。這時，EDP的「逸品」－Searchable Encryption就是最好的管理工具。

顧名思義，Searchable Encryption（SE）是一種「密文可被搜尋加密法」—使用者持金鑰以SE將機密檔案加密後上傳雲端，確保駭客甚至雲端業者無法窺視內容；但在需要時，使用者又得以向雲端服務取回具有某特質（property）的加密檔案，並以原金鑰解密。SE最常見的特質為「具有某關鍵字」，支援這種特質的SE又稱為Privacy-Preserving Keyword Query，其模型可由下圖定義。

第一個「密文可被檢索的加密法」[6]問世後不久，便有學者發現不妥，因傳統的加密法之所以安全，是因其密文彼此間難以分辨（Indistinguishability），但「密文可被搜尋」卻意謂密文可被分辨，安全度自然有疑慮。為此，一種被稱為Index-based SE較廣被認同。的確，檢索不一定要犧牲密文的安全性，使用者只要將足以描述機密資料的關鍵字事先製作成index，再連同（AES加密後之）密文上傳雲端服務即可；當須取回具某關鍵字之密文時，只要將該關鍵字所對應之trapdoor上傳雲端，責承雲端伺服器逐一比對index。Trapdoor可被視為檢索關鍵字（querying word）的「安全替身」，由於trapdoor與對應之index有著「結構性」的關聯，而index又各自與密文對應，因此雲端伺服器可按結構搜尋到正確的index，並如下圖模型般間接地取回含有該關鍵字的密文。

圖 5　Index-based SE 模型

直覺上來說，「間接」檢索將安全性由密文本身轉移到index和trapdoor，而index及trapdoor又只隱含精煉過的關鍵字，安全度較易掌握。的確，現今學術界已有不少SE已證明其index和trapdoor可類比AES般安全；但可惜，多數這類學術成果須大改雲端資料庫演算法，不但實務上常窒礙難行，其效率也是問題，更別提是否支援方便好用的「萬用字元」等進階工具。

國際領導廠商SE解決方案

根據Gartner的預測，雲端資安市場在2020年將成為一塊75.1億美金的大餅[7]，為了分食大餅，雲端資安領導廠商（如CipherCloud、BitGlass及SkyHigh等）除了透過扮演公信第三方（Trusted 3rd Party）開「雲端後門」[8]為企業落實資安政策外，亦紛紛提出各家的SE專利方案，想從根本的加密上解決問題。但根據資通所團隊的研究，許多廠商為了搶得先機，往往略過密碼學嚴謹的論證，以浮華的市場用詞包裝其「看似安全」的index和trapdoor。這類解決方案也許在效能勝過學界，但卻容易遭受頻率分析[9]攻擊。事實上，許多SE專利解決方案能防君子，卻無法阻擋有心人士的分析。

資通所SE解決方案

有鑑於上述學界及業界的優缺點，工研院資通所團隊開發的SE不但易於套用在現行的資料庫系統，其速度幾近明文檢索，再加上支援萬用字元，使用上貼近一般使用者習慣，相當適合布署於各類雲端服務。在安全性上，資通所的SE能將關鍵字所屬語言中的原生頻率[10]徹底打亂。以英文聖經為例，資通所的SE可將每一個單字的index字元打亂到近似雜訊般的均勻分布（uniform distribution），而由於trapdoor的字元分布與index完全相同，不論是以全關鍵字或是採用萬用字元進行檢索，有心人士皆無法從中抽離出原生頻率。反觀CipherCloud的SE，在反覆使用隱含萬用字元之trapdoors下，破綻愈發明顯，有心人最終可完全還原英文字母之原生頻率並從中取得編碼簿（codebook），完全破解該SE所產生的所有indices及trapdoors。

圖 6　ITRI與CipherCloud之index可分析出之頻率分布圖

安全的最後一哩路

雲端以強大優勢滲透人類的生活，就像過去人們離不開網路，今後藉由行動聯網人們也再也離不開雲端。伴隨著使用者對於雲端服務的高度依賴，集中擁有機密資料的雲端服務系統已成為駭客眼中誘人的金庫，一般傳統資安作法也在雲端服務資料外放本質下儼然不足。因此，工研院資通所團隊提出一多層次防禦架構：在防火牆被穿透的假設下，第一層的白名單防禦技術惡意程式失去動力，第二層的輕量化虛擬機技術能隔離I/O封鎖入侵行為，最後，即使駭客（透過職務等管道）完全控制雲端系統，最後一層的EDP也將讓駭客看得到、吃不到，空著肚子離開。這樣的多層次防禦架構假設各等級的駭客能力，確實築起防火牆內那資安的最後一哩路。

參考文獻

（2017） Cost of Data Breach Study. [Online]. Available: http://info.resilientsystems.com/hubfs/IBM_Resilient_Branded_Content/White_Papers/2017_Global_CODB_Report_Final.pdf

[2] （2017） Sweden Leaks the Personal Information of Millions of Its Own Citizens. [Online]. Available: https://gizmodo.com/sweden-leaks-the-personal-information-of-millions-of-it-1797208092

[3] （2017） Symantec Internet Security Threat Report. [Online]. Available: https://www.symantec.com/security-center/threat-report

[4] 吳元熙 （2014）, “駭怕雲端空間文件上傳最好再加密”, [Online]. Available: https://news.tvbs.com.tw/local/545178

[5] Fully-Homomorphic Encryption, [Online]. Available: https://en.wikipedia.org/wiki/Homomorphic_encryption

[6] Song, D. X., Wagner, D., & Perrig, A. （2000）. Practical techniques for searches on encrypted data. In 2000 IEEE Symposium on Security and Privacy （pp. 44-55）.

[7] Cloud Access Security Brokers Market worth 7.51 Billion USD by 2020, [Online]. Available: http://www.marketsandmarkets.com/PressReleases/cloud-access-security-brokers.asp

[8] （2016）API-based Solution, [Online]. Available: https://blog.cloudsecurityalliance.org/2016/08/11/api-vs-proxy-get-best-protection-casb/

[9] Frequency Analysis, [Online]. Available: https://en.wikipedia.org/wiki/Frequency_analysis

[10] Letter frequency, [Online]. Available: https://en.wikipedia.org/wiki/Letter_frequency