緩解企業對公有雲安全擔憂十個簡單辦法

對OpSource——我們不提亞馬遜Web服務(AWS)、Rackspace、Terremark和其他企業——來說，這個答案就是2層VLAN。 在OpSource案例中，使用者使用VPN用戶端或站到站VPN隧道連接到雲中。 這種做法讓公有雲成為私有雲的延伸，從而使其成為一種安全的混合雲。

美國國家公路交通安全管理局(NHTSA)在2009年時花費了30天時間建設並測試了為總統奧巴馬的《協助消費者回收暨節約法案》所構建的基礎設施，NHTSA的答案是來自Layer 7科技公司的CloudSpan CloudConnect閘道。 這種服務允許NHTSA將其伺服器放置在公有雲中，並加以適當的安全控制。 結果是，這個被消費者稱為「舊車換現金」的法案讓超過69萬的美國人領到了貨幣補貼，可以用舊車換輛更新、更清潔、更安全的新車。

具有VPN功能的公有雲和附加的安全層，如CloudSpan，還只是眾多解決公有雲安全問題的其中兩例而已。 每個個案都有自己的長處和短處，缺陷中有成本、複雜性、性能和延遲開銷等。

組織可以優化這些解決公有雲安全的方法，這要依據某個應用到底是不是要徑任務，以及如何保證該應用所需的資料安全而定。 下面是十個強化公有雲安全以支援企業級應用的方法。

1、為公有雲選擇合適的應用

有些企業，包括大多數新創企業，一開始都會為其所有應用採用公有雲服務，包括要徑任務應用及其相關資料。 例如快速成長的社交媒體網站Pinterest就使用了150個AWS實例，所存儲的資料目前已超過了400TB，這樣一個新創企業就把自己的所有應用都放在了公有雲上。

然而，公有雲並不適合於所有組織，也並不適合於一個組織內的所有應用。 一般來說，適合於公有雲的企業應用都沒有很嚴格的安全要求。 在網站、應用開發、測試、線上產品目錄和產品文檔等案例中，大多數雲服務提供者(CSP)所提供的預設安全足以應付此類應用的安全需求。

2、如有必要，評估並強化安全

CSP所提供的公有雲安全可以說千差萬別。 因此在評估CSP時務必注意這一點。 ISO/IEC 27000標準系列提供了系統研究資訊安全風險、重視各類威脅、漏洞及其影響的各種準則，用於設計和實施一套全面的資訊安全控制系統，採用可確保準則遵照執行的管理流程。

正考慮將敏感應用及其資料移轉到公有雲的組織需要根據這些標準來評估和比較不同CSP的安全措施。 如有必要，在組織內部私有雲所使用的安全措施也可擴展到其公有雲實例中。 如上所述，諸如CloudSpan等公司的產品允許組織在私有和公有雲實例上強制執行相同標準的資訊和應用安全性原則。

3、確認並使用適當的協力廠商審計服務

在考慮安全合規性時，組織不能簡單地相信CSP的宣傳。 協力廠商審計服務可以審計CSP的流程及相關程式，看他們是否符合安全標準，是否一致等，並可將它們與CSP對客戶的承諾進行對照。 SAS 70 Type II標準規定了此類審計至少需要延續6個月甚至更長時間。 將一些應用遷移到公有雲中，並在一定延長期內對其加以審計，可以為組織提供一定的適應期，以便企業能更自信地將更多敏感應用及相關資料移轉到公有雲中。

4、增加身份驗證層

大多數CSP都會為公有雲實例提供良好的身份驗證服務，但是像SaaS安全廠商CloudPassage的產品Halo NetSec還額外增加了一個身份驗證層。 這裡你需要權衡，是需要更好的公有雲安全還是需要降低可能增加的網路延遲成本、可能帶來的性能退化以及額外增加的故障點。

5、考慮附加安全對集成的影響

大多數領先CSP提供的預設安全已經相當強大。 在其上再增加公有雲安全措施可能會影響到整體的應用性能，同時還會讓認證和接入管理工作變得更複雜。 如果企業的要徑任務應用需要與其他業務應用集成的話，那麼這些考慮因素就更加重要了，因為最終使用者不喜歡應用在他們需要的時候急忙打不開。

6、把安全條款放在SLA的最前面

在運行私有雲時，你會有一些工具讓你知道何時以及何地可能發生安全洩露。 但是一個CSP的客戶如何才能不斷獲知此類安全洩露事件呢?

CSP所提供的公有雲安全保障不是最好的，除非在簽約時寫成書面的SLA條款，除非透明監控和報表功能對雲客戶來說是可用的。 CSP自擬的合同在這方面可能毫無用處。

7、堅持透明的安全流程

在SLA中對透明和可檢驗的安全流程、程式以及實踐的要求遠遠超出了對潛在的資料洩露風險的要求。 在企業租借託管伺服器時，至少還有一個物理的場所在，你還可以看見放置物理伺服器的機櫃。 而在公有雲中，你卻無法準確地知道企業雲實例的物理行蹤，你所有可依賴的只有CSP為你提供的資訊。 這也是為什麼透明是如此重要的原因。

8、簡化日誌和監控

仔細考量CSP雲實例的監控和日誌是確保公有雲安全的另一個關鍵。 在簽署SLA之前，比較一下各家CSP的日誌和監控實踐，或許能揭示出各家CSP所提供的安全措施之間的細微差別。

9、加密

你可以使用自己的加密方法，而不使用CSP所提供的方法。 雖然CSP會對資訊加密之後再發送到公共互聯網上，存儲在公有雲中，但CSP還要發送加密金鑰。 這可能會讓組織感覺不放心，因為金鑰有可能會在發送途中落入惡意分子手中。

有不少可安裝產品或SaaS廠商都可以連線進行這類加密。 這樣做時，只有客戶和協力廠商廠商指導金鑰，CSP則無法獲知。

10、採用多家、冗余的CSP分散風險

從多家廠商購買連接資料中心的高頻寬，是一種常見的做法，這是因為企業希望將風險在多家供應商之間分散。 如果一家CSP宕機，其他廠商依然可以正常運行。 目前，有不少雲組態工具都已集成在了領先CSP的服務中。

企業可以按需自動啟動多個CSP的附加的伺服器實例，有些網站如Pinterest(下午和傍晚)和Netflix(週末)可以在峰值期間提供此類實例。 在此處，如果CPU使用率達到某個閥值，附加的實例便會啟動，而當使用率下降時，實例便會關閉。

在啟動附加實例時，採用迴圈方式使用不同CSP的實例是很合理的。 例如，第一個實例使用AWS的，第二個使用Rackspace的，第三個使用OpSource...... 等等。 如果採用這種方式，那麼6月29日發生的AWS服務中斷事件就不會對組織的應用造成不利影響了。

權衡公有雲的安全與性能

雖然安全是很多組織在使用公有雲作為IaaS時的首要關注問題，但是也有不少方法可以有效地解決這一問題。 最簡單的方法就是只將最不敏感的應用和資料移轉到公有雲中。

如果組織決定把要徑任務應用遷移到雲中，則需要在CSP所提供的安全措施之外再增加一些安全措施。 不過在增加公有雲安全層時總是需要進行一番權衡的，因為這樣做有可能增加故障點或導致應用運行得更慢。 在安全和性能之間尋找恰當的平衡點可能是困難的，但努力實現這種平衡則會讓組織感到安心。