嘉哲的翻譯／寫作作品集

對於雲端安全管理的討論，就如同黑與白的辨證一樣，大多認為公眾雲是不安全的，而私有雲是安全的，這樣的論述太過簡化，同時容易讓使用任何一種雲端環境的公司暴露在危險中

在一次又一次不斷的調查之後顯示，安全問題是公共雲端運算的潛在使用者最大的顧慮。以下就是一個實例，在2010 年四月所進行的調查中，結果顯示 45%的受訪者認為雲端運算的風險遠高於它的效益。在組合國際(CA)和資訊管理研究機構Ponemon Institute共同進行的一項調查中，也發現了類似的意見。但他們也發現實行雲端計畫之後，則會減輕這些顧慮。同時其他相似的調查結果也持續不斷的發表，顯示對安全問題的不信任感一直存在著。

當然，大部份有關雲端運算的顧慮都指向公眾雲這個變數。全世界的資訊從業人員對雲端服務供應商(Cloud Service Provider, CSP)也持續提出相同的問題。例如，這個星期我在台灣，並同時對台灣雲端產業協會(Taiwan Cloud SIG) 發表演講。這場演講有250位以上的專業人士參加，同時可以預料得到的，對我提出的第一個問題就是「公眾雲夠安全嗎?我是不是應該使用私有雲來避免任何安全問題？」如此看來，似乎各地的使用者都感覺公眾雲服務供應商是不值得信任的。

        然而，如果就界定雲端安全的討論為「公眾雲是不安全的，私有雲是安全的」的二分法，也是過度簡化的區分方式。簡化問題會造成兩個大謊言（或者更寬容地說，是兩個基本的誤解），這兩個謊言都來自於這個新運算模式，讓安全產品和管理行為產生了劇烈的改變所致。

雲端安全謊言 No. 1

首先最大的謊言，就定義上來說，私有雲的安全性較高，是因為它設置在公司內部自有的資料中心裡。這個誤解來自於雲端運算包含了兩個和傳統運算環境不同的重要差異：虛擬化和變動化。

雲端運算技術基礎的第一個差異是因管理程式(hypervisor)存在而產生，這個程式具有將運算作業(和伴隨而來的安全威脅)利用傳統安全工具，如檢查網路流量，在查出不合適或惡意封包後進行隔離的效果。因為虛擬主機就設置在同一部伺服器上，所以虛擬主機可以透過內部流量和管理程式充分溝通，封包也可以從一部主機傳送至另一部主機上，不需要接觸到實體網路，而實體網路通常安裝了用以檢查網路流量的安全管理程式，無法檢查到內部傳送的資料。

其中關鍵的是，這個方式意味著如果其中一部虛擬主機受到入侵，那這部主機就可能傳送具危險性的資料至另一部主機上，完全不受所有相關傳統保護措施的保護限制。換句話說，一個危險的應用程式可以傳送攻擊至另一部主機，而公司的安全防護機制完全沒有上場表現的機會。這樣的情況，只因公司的應用程式位於私有雲中，無法保護自己，使自己免於這種安全威脅。

當然，也許會有人指出這個問題來自於虛擬化作業的弱點，和雲端運算一點關係也沒有。這樣的觀察論述也算正確。雲端運算代表著虛擬化和自動化的結合，同時在自動化這個第二個因素，也有另一個私有雲的缺點正逐漸蔓延。

雲端運算的應用從自動化作業中，得到了快速和彈性等好處─它具備回應應用程式情況改變的能力，可以快速地移動虛擬主機，並且連結另一部虛擬主機，管理隨時變化的流量模式。這個作法表示新機器上線之後，不需任何人為互動，在幾分鐘之後就可以上線。這也代表著任何必要的軟體安裝作業或變定都必須自動化，因此當新機器加入現有應用環境時，可立即當作運算資源加以運用。

同時這也表示任何所需的安全軟體必須不需人力操控，可以自動進行安裝並完成設定作業。但是不幸的是，許多公司依賴資訊安全人員或系統管理師去手動安裝或設定必要的安全元件─通常會在機器的軟體元件安裝和設定之後，做為設定的第二個步驟。

換句話說，許多公司將安全管理作業和雲端環境所需要的安全管理混淆了。大家理所當然地認為私有雲是安全的，其實是不正確的想法。除非你可以將安全管理與基礎建設作業和自動化軟體安裝作業結合在一起，否則您的系統會有安全漏洞。

除此之外，讓這些流程結合在一起也是很重要的。否則，您將會面臨程式的自動化作業超出安全管理作業的範圍 ，這樣就不是好現象了。當然，任誰都不想去解釋為什麼原本認為安全的私有雲，最後會因為雲端運算環境的自動化特性無法延伸到所有軟體架構，而造成安全漏洞的情況。

所以，第一個有關雲端運算的最大謊言是私有雲本質上是安全的。那麼第二個謊言呢？

雲端安全謊言No.2

雲端安全的第二個謊言是對於公眾雲的安全假設，特別指公眾雲的安全管理僅依靠CSP來達成。在服務供應商業界中，實際的安全管理責任是由供應商和使用者共同負責的，供應商的安全責任範圍在於基礎建設連線到應用程式與主機環境之間的介接點，同時使用者的安全責任範圍在於介接點之後的作業環境，尤其重要的是在應用程式內部的安全管理。

沒有任何供應商會因為環境的安全介面無法適當設定應用程式，或無法採取適當應用程式層級的安全預警作法，導致使用者產生資訊安全風險的情況，而負起相關的責任。

我在此舉出一個實例。我們過去經服務的某家公司將他們的核心應用程式放在Amazon Web Service(AMZN)上。很不幸的，這家公司並沒有針對使用AWS服務安全機制採取當的安全管理行為，也沒有在應用程式的設計上供簡單的安全防護功能。

事實上，Amazon提供的是虛擬主機水準的防火牆（稱為Security Group），這個防火牆可以讓封包傳送至特定的通訊埠。對於Security Group的最佳作業方式是加以分割，所以使用者可以設定非常詳細的通信埠供每部虛擬主機使用。這個作法可以確保特定的資料流量流入專屬特定的電腦中。舉例來說，網路伺服器虛擬主機設定通信埠Port 80 讓資料傳入機器中，而資料庫虛擬主機則不允許設定通信埠Port 80傳送資料至機器上。這個作法可以避免外部利用網路資料流量對資料庫主機（包含重要的應用程式資料）的攻擊。

為了建構安全的使用環境，使用者必須適當地使用Security Group 功能。但這家公司並沒有這麼做。它對所有主機只使用一組Security Group來管理所有的頻寬，這表示不同種類的主機會暴露在傳送至任何電腦的不同資料下。很明顯地，這是一個很糟糕的AWS資訊安全機制使用實例。

就企業的應用本身來說，這家公司做了很差勁的安全管理示範。除了沒有針對不同種類的主機分割程式碼之外，它還將所有應用程式碼安裝在同一部機器上，這表示同一部主機除了接收公司網站的資料流量之外，同時主機也在執行含有專屬演算法的程式。

這個情境顯示了一個重要的事實：如果公司假設將所有的資訊安全管理責任都丟給CSP(即如同在這個案例中的Amazon Web Service)，那表示公司對安全管理的態度極度疏忽，因為它並未採取重要的步驟，來積極管理CSP不應該負責的安全問題。這也是前面所闡述共同的資訊安全管理責任─供應商和使用者雙方必須往前一步，在他們可控管的範圍內進行安全管理，如果沒有這樣做的話，這樣的應用就不會是安全的。甚至如果CSP在它控制範圍內，將所有雲端應用安全作業都正確執行，但如果業主無法適切負起其安全管理責任，這樣的應用也會變得不安全。

我曾經參加一場會議，在會中與資訊安全從業人員討論有關公共CSP的安全管理問題，這些從業人員拒絕承認自己公司在運算環境中的安全管理責任，並且堅持將所有的安全問題丟回給CSP，認為這些問題是CSP的責任。

坦白說，這樣的魯莾的舉措讓我感到震驚，也反映了這些從業人員拒絕擔負起必要的工作，讓公共CSP為主的應用作業盡可能地安全可靠。這樣的態度就視同將所有的資訊安全管理責任都推給CSP，對於在CSP環境中所執行的應用程式的安全問題，自己完全沒有責任，甚至連他們的公司也沒有責任。我們對這些從業人大力倡導私有雲的態度也完全不覺得奇怪，因為他們認為私有雲本身的內在安全性高出公眾雲太多。

但是目前業界的實際情況，則是愈來愈多的企業開始在公眾CSP環境中進行雲端應用。安全群組的功能是非常重要的，它可以確保公司以盡可能安全的方式，採取每一個步驟來執行雲端應用，並且這也表示在此概念之下，公司本身必須採取任何必要的方法來確保系統安全。

所以，這樣看來，資訊安全是雲端運算的重要命脈。過去，它經常被視為是私有雲本質上的優點，同時也被視為是公眾雲端運算的基本缺陷。事實上，真正的情況遠比這些論述模糊難辨。如果就直接斷言假設公眾雲端運算環境有安全缺陷，而不想辦法解決問題，這樣似乎是不負責任的作法，同時這樣也表示我們不需要再研究解決安全問題的技術和方法。

管理和設定不良的私有雲運算環境是很脆弱的，然而管理和設定良好的公眾雲端也可以達到很好的安全防護效果。如果只是將這些情況二分為黑與白，只是過份簡化事實，而且也破壞了對相關事實的討論。　

在兩種運算環境中，最有建設性的作法是了解在有限的時間、預算和風險承受度之下，公司應該採取何種行動，盡可能地達成運算環境的安全性。資訊安全絕對不可能是黑與白的二分法問題，但在特定的運算環境和應用上，卻很可能是如同灰階的程度差別問題。若無法了解這個差別，就可能會破壞對此議題的了解，同時也會無法確保公司資訊基本建設達到最有效率與成本效益最高的目的。