雲端架構喊了幾年，目前看到的多是伺服器虛擬化的商業模式，以及將軟體搬上網路後，用掛羊頭賣狗肉的方式搭了雲端便車，除了Google、Facebook等超級網路原生大廠之外，少有廠商能從雲端API層層疊疊地架起可大可久的服務，僅能以大廠的服務為基礎，試著產出讓人眼睛一亮之外的應用，到底是怎麼回事？ 究竟是路途上不大平安，還是路途遙遠，難以一步登雲？
嚴格來說，應該兩者都有，怎麼說呢？目前在談的都是IaaS、PaaS、SaaS，至於各層如何分工合作，讓應用的最後一哩，也就是使用者的設備，能夠把雲端服務視為一個整體，卻是不願意太仔細去追究，好像只要把現行架構直接搬上雲端，從此就能高枕無憂，服務不中斷，效能無限大，費用省翻天，從此過著幸福快樂的生活，可惜的是，業者首先要面臨的就是安全問題，當安全有疑慮的時候，企業不會把重要資料放到雲端，自然大部分雲端的好處就變成了可望而不可及。
再來還有雲架構的問題，既然雲端服務談的是服務，而且是不同組織間的服務，於是必須是鬆散連結，也就必然會成為服務導向架構(SOA)，對目前的應用軟體來說，連共用元件都未必能做得好，要改成共用服務的架構，還要能公開接受巨量使用的檢驗，整個打掉重建恐怕比較快，不然，要求廠商把應用中的服務抽出，放到雲端給所有人使用，讓別人開發替代產品，豈不是為人作嫁?!
況且，應用軟體廠商萬一發現一些個人工作室利用雲端API建立小APP，就可以輕易取代許多大應用，自己的處境越來越像是數位音樂革命或是數位版權革命的著作權擁有者，對那些重金佈建雲端機房的廠商而言，大概就不會有甚麼合作的興趣了。
在雲端環境下，伺服器被虛擬化，許多使用者的平台聚集在相同機器上，讓來自三教九流、五湖四海的使用者全都聚集在相同的硬體設備上，同時也提供了駭客新的練兵場，以各種手段突破虛擬機器到實體機器，然後藉此攻擊另一台虛擬機器，在這種情形下，針對網路層面的防護方式效果有限，傳統方法諸如利用防火牆架構非戰區DMZ，也防護不了此類針對雲端架構本質的攻擊，更糟的是，實體機器上的任何側錄行為，虛擬機器根本無從發現，自然也無法抵禦。
第一部：PKI最適合雲端應用 兼顧加密與不可否認性
即便是建立了縱深防禦、端點安全，應用軟體仍然必須自求多福。於是，選用合適的資安中介軟體是必需的。不可置喙地，資安中介軟體中以公開金鑰基礎建設(PKI, Public Key Infrastructure)的資安等級最高，也最符合雲端架構，其乃透過由私鑰與公鑰組成的線上安全機制，可確保網路上金流及資訊流的隱密，資料安全性及身分不可否認性，當企業或是雲端服務的提供者在選擇資安中介軟體時，PKI架構應屬首選。
PKI能夠在隱密或公共環境中，提供可信任並且有效率的金鑰及認證管理，其功能包括了對數據加密所得的私密性(Confidentiality)、利用電子簽章而產生的不可否認性(non-repudiation)和資料數據一致性(Integrity)的驗明，以及對認證用的金鑰、金鑰持有人、應用程式、認證服務、與進入控制提供驗證，與動態密碼(OTP)或是生物辨識技術相比較，PKI的功能面及架構安全性更適合雲端應用。
對於PKI的組成成員，例如CA的原始設計就具有IaaS特性，可以採用公有雲的服務，又如RA(Registration Authority)適合建在私雲環境，於是應用程式介面(API)必須要適用於原有開發環境，例如：COM(ASP、ASP.NET、VB、VB.Net、C#、PHP)、Java Class(JSP、PHP)、DLL library(C)等；也必須要能支援原有作業平台，例如：ActiveX COM、Library(win32)、Library(IBM AIX、Sun Solaris)、Java class等，同時，私雲環境要能以http或https通訊協定連結CA或VA服務進行驗證，或是使用OCSP通訊協定，當然，原有的資料庫也一定要能夠支援如：MSSQL、MySQL、Oracle、DB2等語法。
PKI架構最適合雲端應用還有另外一個原因，就是能夠在Device端提供硬體保護，並且有行之多年的標準介面，也就是CAPI及PKCS#11等，透過標準介面可以使用多樣化的硬體或服務，如高資智慧貼片、Secure MicroSD在Device端、或是基於HSM的金鑰使用服務(KMS)架設在私雲，而PKI的互通性，許多通行已久的標準可以滿足不同需求，包含W3C XML signature、IETF S/MIME、RSA PKCS#7 等規範。
使用PKI須具備的基本知識多數可由中介軟體服務，使用者只需持續關心演算法安全的最低金鑰長度，對稱式演算法如：DES、3DES、IDEA、RC4、AES，非對稱式演算法，如：RSA、DSA、EC，以確保不易遭到破解，如此一來，即使駭客有心要破解，也必須超過人類壽命年限！
第二部：杜絕未經授權存取的檔案加密器
有了合適的中介軟體之後，接著應思考雲端安全架構，哪些是必須保護的資料與檔案等，如果放在雲端，一個方便的加密保護服務勢必要存在，例如NAS這種已經普遍存在於企業的檔案儲存設備，圖1為網路儲存設備加密器的運作示意圖。
圖1、網路儲存設備加密器
資料來源：捷而思提供，2012/10。
但是，在有授權管理檔案的企業，通常能夠最直接、有最多機會接觸所有第一手機敏資料的，其實不見得是部門主管或是企業老闆，反而，系統管理者或是資訊部門中高階幹部倒是因為職務上的需要，可以無意或有意地管理到本來跟他們無關的檔案資料。
尤其放在雲端的企業資料外洩風險非常高，即便架設在私雲，也很難逃過駭客攻擊，更不要說內部的粗心人士以及有心人士，特別是個資法正式上路、個人資料保護意識抬頭的現今，機敏資料外洩的代價極大，如果在檔案進入NAS前，能夠先經過加密處理，讓檔案的管理與使用都直接隸屬檔案的產生者，或說，有解密金鑰的持有者，如此一來，才能真正確保企業機敏檔案的安全。
在個資法要求下，企業對檔案管理與資訊安全的要求一定要達到以下幾個目的：
- 以檔案方式儲存分享、交換個資與機敏資料時，要做好保護；
- 防範網路竊取資料或被不相干同仁盜走；
- 即使被系統管理者取得檔案或從備份硬碟盜拷時，資料也無法解密。
而雲端系統或是網路的儲存加密器必須有的功能，更應該要能夠做到：
- 管理實體檔案的人與加密金鑰管理者必須分開；
- 硬碟內全部檔案皆以個別不同之隨機密鑰加密；
- 只有合法授權的人可取得密鑰以解密檔案；
- 檔案保密器隨插即用，使用者不必安裝軟體；
- 確保Portal所存放的檔案完全加密。
第三部：安全晶片滿足行動裝置所有安全需求
對於應用軟體，若是在公有雲上執行有安全疑慮，像是安控相關程式碼外流，流程被分析破解的風險，或是系統因為還在開發中、潛在漏洞較多，就要考慮將其服務執行於私有雲，若是最終產生了一個公私混合雲的架構，資料的生命週期就需要被妥善分析，若是在 Device 端執行資安機制有安全疑慮，就必須導入利用硬體進行資安保護的解決方案，例如上述所提將安全晶片嵌入在終端裝置的安全MicroSD相關應用。
之所以在這裡以這樣的解決方案來舉例，最主要是行動裝置已經成為全球90%以上人類隨身之必備物品，假如能夠將資安解決方案植入行動裝置，隨時隨地進行資安應用，才能與雲端架構各項服務或應用的終極目的完全吻合。
上述文章也提到，可以將資安等級最高的PKI安全晶片，附隨在Secure MicroSD或是高資智慧貼片之類的硬體中，而這樣的晶片有什麼特殊需求或功能呢？一定的安全認證是必需的，確保內部金鑰不會輕易外洩，從美國國安局所發表的資料中，讓我們了解這樣的晶片至少要符合CC EAL 5+認證的規範，就如同2011年6月中國銀行宣布全面換裝PBOC v2.0晶片金融卡，而在行動支付上也利用CUPMobile智能SD卡，在遠距離支付採用的是PBOC 2.0 CPUMobile 4G/8G智能SD卡；而在近程支付(NFC)則採用QPBOC 2.0 CPUMobile 4G/8G智能SD卡等等。
使用這樣的安全晶片可以同時提供Android手機安全電子郵件、行動簽核、數位簽章以及電子書數位版權管理平台等等服務，為了避免多個不同的雲端服務在一個行動裝置上串接一大堆硬體，唯有在支持標準化通訊的雲端跟終端，雲端應用程式才有可能良好的服務使用者。
總而言之，得先有雲端安全架構，使用者才能安心，服務才可能全面雲端化。不知道是不是擔心若是普羅大眾發現雲端不會一下子降臨，大家就失去興趣了，所以關於安全架構這個前提，多是避而不提，於是只能期待殺手應用的出現，然而，螳螂捕蟬黃雀在後，本來的殺手應用總是會發現雲端安全問題悄悄降臨，將應用範圍牢牢限制住了。
現在，該是我們面對現實的時候了，Secure in Design是通往雲端應用唯一的路，只要有安全，所有應用都能是雲端的殺手應用。
本文作者現任職於捷而思。如您對本文有任何感想，歡迎來信交流：isnews@newera.messefrankfurt.com。