雲端運算革命性改變了 IT 的世界，企業變得更容易部署基礎架構與應用程式，也更容易架設一些對外的服務。對許多企業來說，不必花費數百萬美元購置機房設備在企業內成立自己的資料中心，是個相當誘人的點子。此外，將資源移到雲端肯定是比較安全，對吧？雲端供應商必定會確保我們的資料和應用程式安全無虞，不讓駭客有任何機會。大錯特錯！我經常從許多客戶那邊聽到這種幻想，而且多到有點不太尋常。事實上，若是缺乏正確的組態設定與適當的雲端管理技能，並且正確落實良好的資安原則的話，雲端服務其實也會 (即使不一定更容易) 遭到攻擊。
共同分擔的安全責任
在進一步討論之前，我們要先說明一下雲端服務廠商與使用者之間共同分擔的安全責任。
當您在規劃要移轉至雲端之前，您必須知道哪些責任該由誰來承擔。如同上圖所示，雲端服務供應商需負責雲端基礎架構的安全以及機房安全。反之，客戶要負責的是自己的資料與工作負載的安全 (一路延伸到作業系統層次)，還有企業虛擬私有雲 (VPC) 內部網路的安全。
除此之外，還有一個相當重要的環節也掌握在客戶手中，那就是存取控管：誰可以存取什麼資源？這一點其實跟過去沒有太大不同，唯一的差別在於資料中心的機房安全變成由 CSP 來管，不過企業 (確切來說是 IT 和 IT 安全團隊) 還是必須能有效率地管制這些資源。
很多時候，這種共同分擔安全責任的模式卻經常被人們忽略，所以會假設企業的資源都安全無虞，這才衍生出各種混亂情況，偶而也擦槍走火。
好了，既然這共同分擔責任的模式大家已經了解，而客戶也必須負責保護好自己的資料和資源，那就讓我們來看看雲端經常遇到的一些常見問題。
Amazon S3
Amazon S3 是 Amazon Web Services 一項很棒的服務，廣泛用於儲存資料、架設靜態網站，或是提供應用程式所需的儲存。但 S3 儲存貯體 (bucket) 卻也經常成為駭客攻擊的主要目標，因為很多時候這些儲存貯體的組態都沒有設定正確。
2017 年曾發生一個案例，美國一家國防外包商 Booz Allen Hamilton 發生戰場影像遭竊以及一些敏感系統的管理員登入憑證被盜的事件。
同年還有另一起案例是某個不安全的 Amazon S3 儲存貯體外洩了 1.98 億美國選民的資料。當您在閱讀這段內容時，您很可能也是受害者之一。
另一個較近期的案例是雲端儲存供應商 Data Deposit Box 的某個 Amazon S3 儲存貯體發生資料外洩 (我在這裡雖然用了「外洩」一詞，但這些案例大多是因為組態設定不當而使得儲存貯體暴露在外，並非因為某個駭客利用了精密的技巧而駭入)。該廠商使用 Amazon S3 儲存貯體來提供儲存容量，但因為某個組態設定問題而導致超過 27 萬筆使用者的個人檔案及個人身分識別資訊 (PII) 外洩。
最後一個關於雲端儲存的議題牽涉到有多少企業正在使用 Amazon S3 來儲存客戶上傳給應用程式後續處理的資料。我們要問的是，如何知道被上傳的資料是惡性或良性？當我接觸過的客戶和 IT 同業越來越多，這問題也越常被提及。
API
API 很棒，API 可讓您透過程式設計的方式來跟應用程式及服務自動化互動。在雲端內，API 可讓系統管理員與服務互動，而且 API 其實也是所有雲端服務的基石，因為 API 讓不同的服務能彼此溝通。但如同這世界的任何事物一樣，這也開啟了一個危險的領域。
我們先從 API 閘道談起，這是雲端內一個可用來與後端應用程式通訊的共同機制。API 閘道本身就是一個可能被攻擊的目標，因為駭客可藉由操弄閘道來讓一些不當的流量通過。API 閘道當初的設計是為了能整合至應用程式內部，並非為了安全而設計。這表示就算未受信任的連線也能進入閘道，或許也能讀取不該看到的資料。同理，發送至閘道的 API 請求當中也可能暗藏惡意內容。
另一個可能影響您 API 閘道及其背後應用程式的攻擊是分散式阻斷服務 (DDOS) 攻擊。為了防範這類攻擊，最常見的方式就是採用網站應用程式防火牆 (WAF)。但問題是，WAF 無法防止低流量且慢速的 DDOS 攻擊，因為這些緩慢穩定的網路請求看起來就好像正常流量一樣。然而在 API 閘道端遏阻 DDOS 攻擊真正有效的方法之一，就是限制每個 API 方法 (method) 所允許的請求數量。
良好的 API 攻擊防範之道在於組態設定，禁止任何匿名的存取相當重要。同樣地，變更代碼 (token)、密碼及金鑰，也能減少有效登入憑證遭駭客利用的機會。最後，停用任何類型的明碼認證機制，還有強制使用 SSL/TLS 加密並採用多重認證，也是很有效的遏阻手段。
運算
少了運算資源，雲端服務就不算完整。這意味著企業會建立一些虛擬機器來執行各種應用程式和服務，但同樣也會多增加一個受攻擊面。同樣的，這也不是雲端服務供應商負責保護的範圍，完完全全是客戶自身的責任。
很多時候，當我在和客戶討論如何從企業內資料中心移轉至雲端時，我很常看到的一種方式就是「直接搬遷」。意思就是說，客戶會將他們資料中心內已經在執行的虛擬機器直接搬到雲端設備上執行。問題來了，這些虛擬機器在移轉之前，是否曾經做過什麼資安評估？這些虛擬機器的漏洞是否都確實修補？發現的資安缺失是否都已改善？根據我個人的經驗，答案都是否定的。所以，這些企業只是將問題從一個位置換到另一個位置。資安漏洞還是存在、還是可能遭到攻擊，尤其當伺服器暴露在外或者網路政策沒有設定妥當時更是如此。所以，在這個移轉過程中，我認為較好的作法是「先修正再搬遷」。
企業一旦建立了自己的雲端之後，最終還是會部署一些新的資源，所以很可能得開發新的虛擬機器映像或以舊的映像為基礎再加以修改。此時必須記住的最重要一點是，這些虛擬機器基本上等同於電腦。它們同樣也會遭到惡意程式攻擊，不論是否在雲端，所以同樣的一些資安措施仍有其必要，如：惡意程式防護、主機入侵防護 (IPS)、一致性監控，以及應用程式控管等等。
網路
雲端服務讓網路變得非常容易部署，也很容易分割子網路，甚至允許跨網路通訊。此外，您還可以封鎖某些可用來瀏覽網路以尋找資源的網路流量。此時就是「安全群組」派上用場的地方，但安全群組還是由「人」所建立，只要人都可能犯錯，因此還是有可能出現某個不該開放的連接埠，造成潛在的資安破口。從這角度來看，極為重要的就是要確切掌握運算資源的通訊對象及目的，這樣才能套用適當的資安措施。
所以，面對駭客，雲端真的就安全嗎？其實不會比較安全，除非企業確實負起自己的資安責任，並了解哪些是客戶的責任範圍，哪些是雲端廠商該負責的事。駭客與資安人員之間的武器大戰還是一如往常一樣，只是換了個戰場而已。
原文出處：Is Cloud Computing Any Safer From Malicious Hackers? 作者：Rob Maynard