云函數帶來新的安全挑戰

陳琳華

云函數或無服務器應用具有體積小、速度快和壽命短等特點。但我們該如何確保它們的安全呢？

無服務器應用部署在云平臺上，被設計為僅使用任務所需的計算資源。它們只在需要時出現，任務結束后即消失。如果你希望最大限度地提高性能，同時將云環境中的開銷降到最低，那么它們是非常棒的選擇。雖然無服務器應用具有體積小、速度快且壽命短的特點，但是它們也給安全團隊帶來了新的挑戰。

目前，網絡安全行業的主要精力仍是全力應對小巧且易于部署的容器所帶來的安全挑戰。由于許多容器可以在單個虛擬機中運行，彼此間相隔離，所以它們比以前的應用部署選項更加便宜且更加靈活。

容器與無服務器應用（也被稱為云函數）或是亞馬遜Lambda函數沒有什么關系。亞馬遜和IBM于2014年發布了首個云函數計算服務，隨后谷歌和微軟在2016年也推出了自己的相應服務。與容器相比，云函數更小、更輕，甚至壽命也更短。這導致安全團隊也更難以確保它們的安全。

至少在容器中還能安裝主要應用和一些安全軟件，如日志記錄或惡意軟件保護工具。但是在云函數中只有一個函數，不能安裝其他東西。我們只能在云端運行幾行代碼。與任何新技術一樣，無服務器應用的安全性也是在事后才被考慮到。許多開發人員盲目地認為基礎設施提供商會確保云函數的安全。

風險不明且缺乏相關的專業知識

Eastwind Networks首席安全和戰略官Robert Huber指出，目前缺乏無服務器安全專業知識的不僅僅是企業開發團隊，整個行業也是如此。他說：“很少有網絡安全專業人員能夠從技術層面理解微服務和云計算。更令人不安的是，大多數組織機構沒有專門的網絡專業人員，而通常這些網絡專業人員都具備可降低環境中風險的必備技能。現在又出現了無服務器應用。”

Huber還指出，關于這一新技術所面臨的全部網絡風險，目前還沒有可靠信息，而來自安全廠商的支持也是非常不成熟的。因此企業在考慮無服務器的投資回報率時應當保持謹慎。

雖然安全軟件商邁克菲稱，無服務器架構可以將某些操作的成本降低十倍，但是這一評估是在全面了解安全風險之前做出的。邁克菲也指出，無服務器應用的靈活計費模式本身就是一種安全風險。因為應用會很自然地根據流量進行擴展和計費，所以分布式拒絕服務（DDoS）攻擊會觸及這一重要問題。

可快速大規模部署的小型函數在數量上正變得越來越多，并且會在網絡中彼此通信，這也導致攻擊面變得越來越大，這就成了一個嚴重的問題。邁克菲認為，無服務器應用將成為2018年新五大威脅之一。

無服務器安全陷阱

決定冒險的企業應該留意潛在的盲點。Aqua Security的聯合創始人兼首席技術官Amir Jerbi說：“我們看到了一個巨大的教育差距，尤其是對那些剛剛開始嘗試這一新技術的公司而言。”

借助無服務器基礎設施架構，云服務提供商可以處理所有的環境安全問題。客戶只需帶上他們的應用程序。這乍一聽似乎無服務器是安全領域向前邁出的一大步，但企業需要了解基礎設施提供商負責的范圍，以及如何充分利用所有的安全功能，例如人員如何被授權在他們的付費賬戶中啟用新的函數以及可以對哪些東西進行監控。

Jerbi表示：“他們需要了解如何限制訪問，能夠獲得哪些原生工具，以及自己缺少什么。總體而言，由于轉向無服務器函數，網絡安全應該會得到改善，因為基礎設施提供商可以完全控制環境，并且可以為用戶提供大量安全保護。你自己的團隊不再需要知道如何處理它們。”

云提供商將強化環境，確保所有東西都是最新和最安全的版本，以及所有補丁均已被打上。倫敦數字自動化信息公司Eggplant的首席技術官Antony Edwards說：“無服務器幾乎消除了目前入侵的主要渠道——未打補丁的服務器。這些服務器正在使用具有已知漏洞的二進制文件，因為它們沒有對相關漏洞進行最新的安全更新。目前大多數情況下，絕大多數的成功入侵都與已知漏洞有關。”

極大的靈活性帶來了巨大的責任

無服務器應用或云函數可以在極短的時間內出現和消失，應用可以平穩且經濟高效地擴展。Edwards說，它們非常適合那些圍繞微服務構建起來的應用。不幸的是，它們也為企圖濫用這些應用的攻擊者提供了更多的機會。

由于開發人員不需要擔心底層基礎架構，因此他們會在沒有傳統安全審查流程的情況下快速推出應用，這導致應用本身可能會出現更多漏洞。由于無服務器應用是小型的獨立函數，所以攻擊者有更多機會嘗試提升權限或利用未妥善管理的應用程序相關性。此外，攻擊者還可以利用竊取的證書獲得數據的訪問權。

開發人員應確保數據庫訪問有嚴格的限制措施。Edwards說：“要避免人人都能訪問你的數據庫，甚至是讀取訪問權限，取而代之的是只將訪問權限給予最需要它們的人和系統。”

另一方面，無服務器應用允許更為精細的管理，因此開發人員可以更為精準地定制訪問控制權。云安全公司Edgewise Networks的聯合創始人兼首席執行官Peter Smith認為，如何管理是開發人員轉向無服務器應用時遇到的最大挑戰。他說：“控制這些服務之間的相互訪問是一項重大挑戰，需要一種新的訪問管理模式。”

這個問題的影響范圍有多大呢？答案是相當大。據無服務器安全公司PureSec在4月份發布的報告顯示，21%的開源無服務器項目至少有一個嚴重漏洞或配置錯誤，6%存在諸如在公開訪問位置存放API密鑰的問題。該公司認為，目前存在的五大主要問題是數據注入、認證失效、不安全配置、權限過高和監控不足。

這對人類來說可能是一個極大的挑戰，以至于根本無法處理。這時可能需要大規模利用人工智能（AI）進行處理。Smith說：“新的方法可以通過使用機器學習分析無服務器組件相關性來限制攻擊面，以及通過自動生成最低網絡控制來降低風險。”以采用自動化和可擴展的方式實現只在可信的組件之間進行必要的訪問。

除了信任，還需要驗證

所有主要的云提供商現在都有無服務器產品。其中，如亞馬遜的AWS Lambda函數、微軟的Azure函數，谷歌和IBM的Cloud Functions。

盡管產品眾多，但是用戶無法一直準確地知道底層基礎設施架構是什么，它是如何工作的，以及如何確保安全。在某種程度上，這是廠商故意為之。如果公眾能夠訪問這些信息，那么對于黑客來說也是如此。這也意味著企業必須要對許多東西采取信任的態度。

Kudelski Security解決方案架構主管Bo Lane稱，理論上，無服務器函數運行在孤立的環境中，但是它們仍然是與多個客戶共享的硬件和計算環境。另外，客戶不能在該環境中安裝自己的安全工具，這就造成了嚴重的限制。Lane問道：“你如何監視函數中的輸入和輸出？你如何監控正在進行的惡意活動？你需要在本地環境或虛擬機上部署許多工具，但是又無法部署這些工具。企業客戶需要了解基礎設施提供商能夠提供哪些工具。”

另一種選擇是使用像Apache OpenWhisk這樣的平臺創建自己的無服務器環境。事實上，這是IBM云函數解決方案 Bluemix OpenWhisk所基于的平臺。其他的選項還包括Fission、IronFunctions和Gestalt。

企業也可以從內部監控函數的性能。例如，專注于應用層的安全廠商FairWarning的創始人兼首席執行官Kurt Long說：“我們會在應用內部設置審計函數。如果是自研應用程序，那么它們會有審計跟蹤。”

所有的基本要素仍然適用，不管應用如何部署。他說：“在無服務器應用中，仍然有數據需要保護，仍然有業務功能需要實現，人們也必須要訪問服務。有些事情不會改變。”

從應用首次構建時就開始建立安全性比任何時候都更加重要。紅帽JBoss的工程副總裁兼首席技術官Mark Little表示：“安全性不應該在應用開發完成后才考慮。”然而，在實踐中，目前還沒有關于基礎設施漏洞的具體信息，也不清楚應用安全性隨著向無服務器應用的過渡會變得更好還是更糟。Little說：“函數即服務目前正在被過度炒作。“開發人員對使用它們很感興趣。對于開發人員不斷嘗試這一新技術或是在生產中使用它們，我們還沒有什么很好的意見。”

據Sumo Logic去年秋季對1500名運行云應用的客戶展開的調查顯示，使用AWS Lamdba的人數已經從2016年的12%增長至了2017年的23%，翻了近一倍。

以后的增長率可能會出現大幅增長。據Cloudability稱，AWS Lambda上無服務器函數的增長率由2017年第一季度的100%激增到了第四季度的667%。它們將很快成為一個非常龐大且攻擊目標豐富的環境。

本文作者Maria Korolov在過去20年內長期關注新興技術和新興市場。

原文網址

https：//www.csoonline.com/article/3277965/cloud-security/cloud-functions-present-new-security-challenges.html