對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所提供的安全措施之外再增加一些安全措施。不過在增加公有云安全層時總是需要進行一番權衡的，因為這樣做有可能增加故障點或導致應用運行得更慢。在安全和性能之間尋找恰當的平衡點可能是困難的，但努力實現這種平衡則會讓組織感到安心。
京公網安備 11010502049343號