如何安全過渡到公共雲
經過長時間的實驗，龍頭企業正在認真考慮大規模採用公共雲。在過去幾年中，很多公司已經改變了IT戰略，將越來越多的應用程式和資料轉移到公共雲基礎設施和平臺上。然而，公共雲的使用顛覆了很多公司多年來積累的傳統網路安全模型。因此，隨著公司漸漸利用公共雲，它們需要大力發展網路安全方面的實踐，從而以這樣的方式使用公共雲——既能保護關鍵資料又能充分利用這些服務所帶來的速度和敏捷性。
雖然迄今為止公共雲的採用仍然受到限制，但未來的前景卻大不同。在我們研究的公司中，只有40%的公司在公共雲平臺上的工作負載超過10%;相比之下，80%的公司計劃在三年內在公共雲平臺上的工作負載將達到10%，或計劃將雲滲透率提高一倍。我們將這些公司稱為“立志使用雲端的公司”。這些公司得出的結論是，公共云為很多工作負載和實施方案帶來了更多的技術靈活性和更簡單的擴充套件。在某些情況下，使用公共雲還可以降低IT運營成本。因此，公司正在雲中構建新的應用程式和分析功能，並逐漸將現有的工作負載和技術棧遷移到公共雲平臺上。
儘管公共雲平臺有諸多好處，但人們對公共雲的網路安全性一直心存擔憂，這阻礙了公司向雲端遷移的步伐。在我們對2016年的雲採用的研究中，高管們將安全性視為雲遷移的主要障礙之一，其它障礙包括對變革進行管理的複雜性，為雲的採用制定引人注目的業務案例的難度。
有趣的是，我們對首席資訊保安官(CISO)進行的研究表明，他們的目光變得更長遠了，不再侷限於“雲安全嗎?”這樣的問題。在很多情況下，他們承認，雲服務提供商(CSP)的安全資源遠勝一籌，他們如今的疑問是如何安全地使用雲服務，因為他們很多現有的安全實踐和架構在雲端不見得會更高效。如果某些本地控制元件(例如安全日誌記錄)沒有重新配置，這些控制元件就不太可能適用於公共雲平臺。採用公共雲還有可能放大某些型別的風險。雲服務為開發人員提供的速度和靈活性也可以(在沒有適當的配置治理的情況下)用來建立不受保護的環境，很多公司都發現了這樣的事實，這讓它們十分尷尬。
簡而言之，公司需要採取主動、系統的方法，使網路安全功能可以適應公共雲。多年來我們一直在雲端計算網路安全計劃上與大型組織展開合作，並與網路安全領導者進行交流，我們相信，以下四種做法有助於公司制定一致、高效的公共雲網絡安全性方面的方法：
• 開發以云為中心的網路安全模型：如何在雲中管理邊界;在多大程度上為應用程式重新設計架構，使風險承受能力和現有的應用程式架構、可用資源和整體雲戰略保持一致，公司必須為此做出選擇。
• 為公共雲重新設計一整套網路安全控制元件：對每個單獨的控制元件而言，公司都要確定應該由誰來提供控制元件，要達到怎樣的嚴格程度。
• 與提供商的做法相比較，明確網路安全的內部責任：公共雲需要一個共享的安全模型，提供商及其客戶各自負責特定的功能。公司必須瞭解這種責任分配的做法(這與傳統的外包安排有很大的不同)並相應地對內部流程進行重新設計。
• 將開發運維應用於網路安全：如果開發人員可以在短短几秒內啟動伺服器，但必須等待兩週的時間才能讓安全團隊認同配置，這會削弱公共的雲靈活性所帶來的價值。公司必須通過API為開發人員提供高度自動化的安全服務，就像他們為基礎架構服務所做的那樣。
開發以云為中心的網路安全模型
對一家初涉公共雲的公司來說，使用內部部署的系統已有的控制元件來構建公共雲網絡安全模型，這種做法是很誘人。但這可能會引發問題，因為內部部署的控制元件在沒有進行重新配置的情況下不太可能適用於公共雲平臺。即使在重新配置之後，這些控制元件也無法在所有工作負載和雲平臺上提供可見性和保護。由於認識到這些侷限性，這些立志使用雲端的公司正在對一系列安全策略和架構進行試驗，有一些原型已經問世了。
最有效的方法是根據兩個因素對公司的網路安全模型進行重新評估：如何定義網路邊界以及是否需要針對公共雲來更改應用程式架構。邊界的定義決定了雲網絡安全模型的拓撲和邊界。與應用程式架構有關的選擇可以對應用程式中的安全控制元件的結合起指導作用。這兩個關鍵選擇也會相互影響。例如，公司可以做出這樣的選擇——通過新增安全功能來使應用程式具有更高的安全性，這些功能可以在處理資料時最大限度地減少敏感資料的洩露，並且不會對應用於已知環境的安全控制元件做出任何臆斷。
為周邊的安全性選擇一個模型
在這些立志使用雲端的公司中，以下三種周邊設計模型脫穎而出：
• 回傳：通過內部部署的網路對流量進行回傳或路由，半數立志使用雲端的公司就是這麼管理周邊安全性的。該模型吸引了需要在內部使用大部分雲工作負載的公司，並希望就工作負載的遷移做出特定的選擇，使其符合它們所擁有的架構。在雲安全方面經驗不足的公司也可以從回傳中受益，因為這使它們可以繼續使用已然熟悉的本地安全工具。但回傳也許不會長盛不衰：立志使用雲端的公司中只有11%的公司表示，它們可能會在三年後使用這種模式。
• 預設採用雲服務提供商提供的控制元件。我們研究的立志使用雲端的公司中有36%的公司做出了這樣的選擇。使用雲服務提供商的安全控制元件的成本可能比使用其它任何一個周邊模型的成本都要低，但這卻使保護多雲環境變得更加複雜。對規模更大、更復雜的組織來說，使用雲服務提供商提供的控制元件似乎是一種臨時措施：立志使用雲端的公司中有27%的公司表示，它們將在三年內使用此模型(比如今的比率下降了36%)。
• 清理：清理涉及到對“虛擬邊界”的設計並從各種外部提供商提供的解決方案開發雲特有的控制元件。立志使用雲端的公司中大約有15%的公司使用這種方法，這種方法使公司能夠應用它們能找到的最佳外圍安全解決方案，並根據需要進行切換。由於不斷變化的解決方案會產生技術需求，因此公司通常會在擁有足夠的內部網路安全專業方面的知識來選擇供應商並整合其解決方案時進行清理。儘管這些工作可以減緩工作負載遷移到雲中的速度，但是清理工作似乎正在增加，立志使用雲端的公司中大約有47%的公司表示，它們將在三年內使用雲特有的控制元件。儘管清理的成本和複雜性很高，但組織還是選擇了這種方法，以便它們可以支援多雲環境，並在需求發展時能更輕鬆地替換點解決方案(point solution)。
我們研究了眾多立志使用雲端的公司，發現回傳是最受這些公司青睞的周邊安全模型。然而，企業正在轉向虛擬周邊模型，這些模型通過清理來開發周邊模型。清理是目前管理周邊安全性最不受歡迎的做法，但越來越多的高管表示，他們將在未來三年內使用清理，而不是其它模型。
決定是否為應用程式重新設計應用程式的架構
另一個選擇是定義公司的雲網絡安全方面的立場：通過重寫程式碼或改變應用程式的架構(或兩者都做)來重新構建公共雲中的應用程式。我們採訪的高管中只有27%的人表示他們的公司會這樣做。這樣做的好處是可以相容所有的雲服務提供商(例如容器架構)、有更強的安全性(使用雜湊檢測篡改檢測，記憶體釋放以及呼叫之間的資料流加密)，優越的效能(例如，通過允許水平擴充套件)公共雲，更低的運營成本(因為應用級別的安全保護減少了公司選擇最佳安全解決方案的需求)。但是，重新設計雲應用程式的架構可能會降低公司的遷移率。因此，在我們的調查中，絕大多數企業(78%)都在遷移應用程式而不是對公共雲的架構進行重新設計。
周邊安全設計的選擇(以及是否使應用程式適配公共雲的選擇)為雲網絡安全建立了六個原型。我們的經驗表明，只要有五個主要標準，企業就能知道其對整體雲網絡安全模型所做的決策：公共雲安全性方面的有效性、希望達到的雲遷移率、支付額外安全成本的意願、實施新安全計劃的所要具備的專業知識、以及企業希望從安全架構中獲得的靈活性。
為公共雲應用程式重新設計架構可提高安全性，但這可能會降低遷移速度。回傳則可以將公司已經熟悉的現有控制元件擴充套件到公共雲。使用預設的雲服務提供商的控制元件是最簡單且最具成本效益的方法。清理控制元件需要大量安全性方面的專業知識，但它能為多個雲提供靈活性和支援。組織可以使用這些標準來選擇最佳方法。也就是說，公司不需要將相同的原型應用到整個公共雲配置檔案。對具有不同要求的應用程式來說，使用不同的原型是可能的，甚至是有利的：為了核心事務系統來能夠實現更快的遷移和熟悉的控制，同時使用雲服務提供商提供的安全控制元件來降低成本，加快部署面向新客戶的應用程式。
重新設計公共雲的全套網路安全控制元件
一旦企業確認了安全原型(或一系列原型，每個原型與具有類似安全要求的一系列工作負載相匹配)，它們就可以設計和實施網路安全控制元件。公司正在嘗試各種控制元件設計，鑑於進展速度，網路安全管理人員預計，在未來三年，這些控制元件會發生相當大的變化，這是可以理解的。網路安全控制元件可以分為八個領域，組織必須將這些領域結合起來考慮。以下是八個控制元件領域，以及來自我們的研究的觀察結果。
• 身份和訪問管理：基於雲的應用程式和資料的身份和訪問管理解決方案正逐漸轉移到雲端。60%的受訪者表示，他們現在使用本地的身份和訪問管理解決方案，但只有一半的人希望在三年內使用本地的身份和訪問管理解決方案。那時有60%的受訪者預計，他們的企業將依賴第三方身份和訪問管理服務，這些服務支援多個公共雲環境，並將內部和公共雲資源的身份和訪問管理控制元件統一起來。
• 資料：在活動和靜止的情況下對雲資料加密的做法很快就會成為標準。立志使用雲端的公司中有84%的公司有望在三年內對儲存在雲中的資料進行加密。最終，首席資訊保安官(CISO)也希望有更多實用的機制來加密記憶體中的資料。然而，受訪者有不同的方法來管理雲工作負載的加密金鑰：33%的人更傾向於讓雲服務提供商來管理金鑰，28%的人更傾向於將其保留在內部，11%的人更傾向於讓第三方管理金鑰。
• 外圍：企業正朝著“虛擬外圍”模式發展。目前，大約40%的企業通過本地部署的資料中心對流量進行路由，使用某種形式的虛擬專用網路(VPN)或使用本地部署的工作負載和公共雲負載之間的連結性，以此來作為訪問公共雲平臺上的應用程式或資料的唯一方式。但49%的受訪者表示，他們希望公司在未來三年內使用第三方的外圍控制元件。向這些周邊控制元件模型的過渡往往涉及到這樣的做法——憑藉一系列服務來開發清理設計，例如安全性Web閘道器、Web應用程式防火牆以第三方提供的網路監視機制，這些機制支援多重雲。
• 應用程式：大多數受訪者(84%)為基於雲的應用程式定義了安全配置標準，並依賴雲服務提供商來實現這些標準。但85%的受訪者表示，由於工作負載遷移到雲端，他們的公司可能會促進更多的開發治理。這種治理很可能是軟治理，只有20%的企業使用應用程式的安全性工具或模板。
• 運營監控。56%的企業依靠當前的安全資訊和事件管理(SIEM)工具來監控雲應用。這使它們可以統覽內部部署的工作負載和雲工作負載。另有30%的企業使用雲服務提供商提供的其它本地監控工具或從雲服務提供商那裡獲取日誌，以使用專門的資料分析解決方案生成洞察。由於雲服務提供商可以提供豐富的監控資料，因此組織必須與它們協作，選擇能夠提供統覽內部部署的工作負載和公共雲工作負載的解決方案。
• 伺服器端端點：受訪者對雲服務提供商提供的伺服器端的安全性充滿信心：51%的受訪者表示，他們對伺服器端的端點的雲服務提供商提供的安全性高度適應。很多公司(特別是那些安全程式不太複雜的公司)認為，雲服務提供商能夠洞悉並控制它們的伺服器群，這比公司內部做效果更好。
• 使用者端點：將工作負載遷移到雲往往需要更改使用者裝置的控制元件，這主要是為了防止資料丟失以及防禦病毒和惡意軟體。70%的受訪者表示，如果使用公共雲基礎架構，他們的企業就必須更換使用者的端點控制元件。
• 監管治理：大多數網路安全計劃受資料保護法規(如歐盟通用資料保護法規)，資料的位置、主權以及個人身份資訊的管轄。金融機構和醫療組織也受制於行業特定的法規。與我們交談的高管中有50%的人表示，他們希望雲服務提供商共同負責法規的合規。
在選擇控制元件時，組織應結合這八大領域並構建全面的網路安全架構，而不是採用零散的方法。公司可以根據威脅情景和所需的安全級別設計控制元件，然後應用合適的安全性模型原型(例如回傳或清理)來確定最佳的安全控制元件及其範圍。公司還可以與雲服務提供商合作，以確定要使用哪些控制元件以及從第三方採購哪些控制元件。最後，公司必須對可以標準化和自動化的控制元件進行篩選並確定其優先順序，並在敏捷迭代中實現這些控制元件。
與提供商的工作相比，明確了網路安全的內部責任
當企業將應用程式和資料遷移到公共雲時，它們必須依靠雲服務提供商和第三方提供商進行某些安全控制——但它們不應該指望這些提供商提供所有必要的控制元件。除非公司和雲服務提供商明確劃分了公共雲環境中網路安全性方面的所有責任，否則有些責任可能會落空。這使公司不得不做出這樣的舉動——讓雲服務提供商提供統覽安全運營模型以及隨著這些模型發生變化的及時更新，從而開發並清楚地理解雲服務提供商所提供的控制元件。(雲服務提供商以不同的方式組織網路安全責任模型，並採取各種方法來共享這些模型，因此每種情況都要小心處理。)這樣，公司就可以設計和配置在多重雲環境中執行良好並能與各種工具、處理模型和運營模型很好地整合的控制元件。
根據我們的經驗和研究，我們發現企業可以從整個網路安全生命週期(從設計到實施和持續運營)中與雲服務提供商合作中獲益。然而，四個主要領域成為公司與其雲服務提供商之間合作的首要任務。
• 控制元件和程式的透明度：公司應該讓雲服務提供商對安全控制元件、程式和所有的洩密事件提供最大限度的可見性。公司還需要了解每個雲服務提供商進行安全審計和滲透測試的能力。
• 法規合規性方面的支援：公司應要求雲服務提供商提供這樣的詳細說明——與監管合規性有關的保證，並詢問他們如何及時瞭解每個行業的監管變化，並相應地更新合規機制。
• 整合的運營監測和響應：在以支援集中安全管理的方式整合安全資訊和事件管理(SIEM)工具時，公司可能必須與雲服務提供商合作。公司必須要求雲服務提供商持續為其提供全面的報告，洞察和威脅警報。公司可以將洞察傳授給雲服務提供商，幫助它們為所有租戶開發新功能。公司還必須確保雲服務提供商以公司可以使用內部部署分析工具處理的格式使日誌隨時可用。
• 多雲的雲身份和訪問管理(IAM)功能。公司應該堅持要求雲服務提供商提供原生的多因素身份驗證(native multifactor authentication)。使用身份即服務(IDaaS)或本地身份和訪問管理解決方案的人必須與雲服務提供商合作才能正確地將它們整合起來，以便它們可以為多個公共雲環境提供足夠的支援。公司還應該讓他們的雲服務提供商共享雲身份和訪問管理的路線圖，以便它們可以計劃利用行為認證和基於角色的訪問等功能。
將開發運維應用於網路安全
開發運維是一種越來越流行的整合開發和IT運營的方法，這種方法支援持續交付新的軟體功能，這在某種程度上是通過為開發人員提供訪問運營服務的API來實現的。Secure DevOps(有時稱為“SecDevOps”或“持續的安全性”)將安全評估、安全控制元件的實施以及安全技術的部署與開發運維方法整合在一起，很多團隊已經採用了這樣的方法遷移到雲中。只要在整個開發週期內對安全服務進行自動化並通過API提供安全服務就可以實現整合。
Secure DevOps用縮短部署時間和降低風險的方式增強了雲的所有類別的安全控制元件。例如，有些公司的政策要求對所有資料進行分類。但是，當資料只能手動分類時，必要的付出會增加部署計劃的時間。通過安全的開發運維，強制資料分類變得更加實用，因為所有資料都會根據預設的規則接收預設的分類。因為有了這樣的改進以及由安全的開發運維根據預設的規則提供的分類，組織可以降低公共雲環境中的違規風險，同時減少或消除在儲存資料之前手動對資料進行分類所造成的延遲。
採用安全的開發運維方法要求公司培養一種文化，在這種文化中，安全性是每個軟體專案的關鍵要素，也是每個開發人員工作的特點。很多開發人員需要接受額外的安全培訓，從而在公共雲遷移期間和遷移之後提供有效的支援。培訓還有助於開發人員瞭解自己所使用的工具的安全功能，以便他們可以更好地利用現有的安全性API和編排技術並建立新的技術。
公司應該簡化安全治理程式，以確保這些程式不會給開發人員造成延誤。隨著公司對安全控制元件進行自動化，它們可以使控制元件對開發人員完全可見。這樣，開發人員就可以獨立檢查控制元件是否在後臺正常工作，而不是延遲工作去諮詢安全專家。自動化審計安全機制的過程也大有裨益。例如，為了符合策略，公司可以要求每天晚上對這個程式碼進行自動掃描，並將安全元件的構建時(build-time)檢查整合到應用程式中。
為了實施安全的開發運維，公司還改變了IT運營模式，因此安全實施成為雲開發和部署過程的一部分。在這樣的運營模式中，經過適當培訓的開發團隊就是安全團隊;無需外部參與即可獲得合適的安全性方面的專業知識。在開發團隊中注入安全性方面的專業知識可以消除雲部署過程中的延遲，同時使開發團隊以快於傳統安全模型所允許的速度進行迭代。
公司如何著手加強雲中的網路安全
我們描述的構建公共雲網絡安全計劃的四種做法應該能使公司更好地利用公共雲平臺。然而，設定程式可能是一項複雜的任務，因為公司有多個雲工作負載，雲服務提供商、內部部署的功能和私有云功能、位置、法規要求和安全要求。這個由十個步驟構成的工作計劃將幫助公司在設計、開發和實施公共雲網絡安全計劃時協調一致。
11. 確定要遷移到公共雲的工作負載。例如，很多組織一開始就選擇將面向客戶的應用程式或分析工作負載遷移到公共雲，同時將核心事務系統保留在本地。然後，它們就可以確定所遷移的工作負載的安全要求。
12. 至少要找到一家能夠滿足工作負載安全要求的雲服務提供商。公司可以為不同的工作負載選擇多個提供商，但這些選擇應該與公司整體的雲戰略的目標一致。
13. 根據遷移的簡易性、安全狀況、成本因素和內部的專業知識為每個工作負載分配安全原型。例如，公司可以重新設計應用程式的架構並使用預設的雲服務提供商控制元件來實現面向客戶的工作負載，並在不重新設計架構的情況下提升和轉移內部核心事務的應用程式，同時對資料訪問進行回傳。
14. 對於每個工作負載，請確認安全性級別，從而實施八個控制元件中的每一個控制元件。例如，公司應確定身份和訪問管理是否僅需要單因素身份驗證(single-factor authentication)，需要多因素身份驗證(multifactor authentication)，還是需要更高階的方法(如行為身份驗證)。
15. 確定每個工作負載的八個控制元件分別要使用哪些解決方案。鑑於針對每個工作負載所確定的雲服務提供商(或雲服務提供商)的功能，公司可以確定是使用現有的本地安全解決方案、雲服務提供商提供的解決方案還是第三方解決方案。
16. 實施必要的控制元件並將其整合到現有的解決方案。這要求公司充分了解雲服務提供商的安全功能和安全執行流程。雲服務提供商需要對產品的這些方面保持透明。
17. 就每個控制元件是否可以標準化和自動化形成一個看法。這包括分析整套控制元件並做出決策——哪些控制元件在整個組織中實現標準化，哪些控制元件實現自動化。
18. 人們可以根據公司遷移的應用程式以及公司指定的安全模型來確定控制元件的優先順序。
19. 實現控制和治理模型。對於可以標準化但不能自動化的控制元件，公司可以開發查驗清單(checklist)，就如何遵循這些清單對開發人員進行培訓。對於可以標準化和自動化的控制元件，公司可以使用安全的開發運維方法來建立自動化例程，以實現控制元件並實施標準化。
20. 利用在第一波實施過程中獲得的經驗來選擇要實施的下一組控制。借鑑這一經驗也將有助於改進一系列後續控制元件的實施過程。
公司正在將更多應用程式從內部部署的資料中心和私有云平臺穩步轉移到公共雲平臺，這些平臺在很多情況下都能帶來卓越的成本效益、靈活性和速度。但只有在公司維護應用程式和資料的安全性時，公共雲的遷移才能順利進行——有些公司正在努力做到這一點。
我們的經驗和研究表明，只要用對方法，公共雲網絡安全是可以實現的。公司只要開發以云為中心的網路安全模型，在八個安全領域設計強大的控制元件，明確雲服務提供商的職責，以及使用安全的開發運維，這樣它們就有更大的把握將工作負載轉移到公共雲中，從而保護最關鍵的資訊資產。