無服務器應用部署在雲平台上，被設計為僅使用任務所需的計算資源。它們隻在需要時出現，任務結束後即消失。如果你希望最大限度地提高性能，同時将雲環境中的開銷降到最低，那麼它們是非常棒的選擇。雖然無服務器應用具有體積小、速度快且壽命短的特點，但是它們也給安全團隊帶來了新的挑戰。
目前，網絡安全行業的主要精力仍是全力應對小巧且易于部署的容器所帶來的安全挑戰。由于許多容器可以在單個虛拟機中運行，彼此間相隔離，所以它們比以前的應用部署選項更加便宜且更加靈活。
容器與無服務器應用（也被稱為雲函數）或是亞馬遜Lambda函數沒有什麼關系。亞馬遜和IBM于2014年發布了首個雲函數計算服務，随後谷歌和微軟在2016年也推出了自己的相應服務。與容器相比，雲函數更小、更輕，甚至壽命也更短。這導緻安全團隊也更難以确保它們的安全。
至少在容器中還能安裝主要應用和一些安全軟件，如日志記錄或惡意軟件保護工具。但是在雲函數中隻有一個函數，不能安裝其他東西。我們隻能在雲端運行幾行代碼。與任何新技術一樣，無服務器應用的安全性也是在事後才被考慮到。許多開發人員盲目地認為基礎設施提供商會确保雲函數的安全。
風險不明且缺乏相關的專業知識
EastwindNetworks首席安全和戰略官RobertHuber指出，目前缺乏無服務器安全專業知識的不僅僅是企業開發團隊，整個行業也是如此。他說：“很少有網絡安全專業人員能夠從技術層面理解微服務和雲計算。更令人不安的是，大多數組織機構沒有專門的網絡專業人員，而通常這些網絡專業人員都具備可降低環境中風險的必備技能。現在又出現了無服務器應用。”
Huber還指出，關于這一新技術所面臨的全部網絡風險，目前還沒有可靠信息，而來自安全廠商的支持也是非常不成熟的。因此企業在考慮無服務器的投資回報率時應當保持謹慎。
雖然安全軟件商邁克菲稱，無服務器架構可以将某些操作的成本降低十倍，但是這一評估是在全面了解安全風險之前做出的。邁克菲也指出，無服務器應用的靈活計費模式本身就是一種安全風險。因為應用會很自然地根據流量進行擴展和計費，所以分布式拒絕服務（DDoS）攻擊會觸及這一重要問題。
可快速大規模部署的小型函數在數量上正變得越來越多，并且會在網絡中彼此通信，這也導緻攻擊面變得越來越大，這就成了一個嚴重的問題。邁克菲認為，無服務器應用将成為2018年新五大威脅之一。
無服務器安全陷阱
決定冒險的企業應該留意潛在的盲點。AquaSecurity的聯合創始人兼首席技術官AmirJerbi說：“我們看到了一個巨大的教育差距，尤其是對那些剛剛開始嘗試這一新技術的公司而言。”
借助無服務器基礎設施架構，雲服務提供商可以處理所有的環境安全問題。客戶隻需帶上他們的應用程序。這乍一聽似乎無服務器是安全領域向前邁出的一大步，但企業需要了解基礎設施提供商負責的範圍，以及如何充分利用所有的安全功能，例如人員如何被授權在他們的付費賬戶中啟用新的函數以及可以對哪些東西進行監控。
Jerbi表示：“他們需要了解如何限制訪問，能夠獲得哪些原生工具，以及自己缺少什麼。總體而言，由于轉向無服務器函數，網絡安全應該會得到改善，因為基礎設施提供商可以完全控制環境，并且可以為用戶提供大量安全保護。你自己的團隊不再需要知道如何處理它們。”
雲提供商将強化環境，确保所有東西都是最新和最安全的版本，以及所有補丁均已被打上。倫敦數字自動化信息公司Eggplant的首席技術官AntonyEdwards說：“無服務器幾乎消除了目前入侵的主要渠道——未打補丁的服務器。這些服務器正在使用具有已知漏洞的二進制文件，因為它們沒有對相關漏洞進行最新的安全更新。目前大多數情況下，絕大多數的成功入侵都與已知漏洞有關。”
極大的靈活性帶來了巨大的責任
無服務器應用或雲函數可以在極短的時間内出現和消失，應用可以平穩且經濟高效地擴展。Edwards說，它們非常适合那些圍繞微服務構建起來的應用。不幸的是，它們也為企圖濫用這些應用的攻擊者提供了更多的機會。
由于開發人員不需要擔心底層基礎架構，因此他們會在沒有傳統安全審查流程的情況下快速推出應用，這導緻應用本身可能會出現更多漏洞。由于無服務器應用是小型的獨立函數，所以攻擊者有更多機會嘗試提升權限或利用未妥善管理的應用程序相關性。此外，攻擊者還可以利用竊取的證書獲得數據的訪問權。
開發人員應确保數據庫訪問有嚴格的限制措施。Edwards說：“要避免人人都能訪問你的數據庫，甚至是讀取訪問權限，取而代之的是隻将訪問權限給予最需要它們的人和系統。”
另一方面，無服務器應用允許更為精細的管理，因此開發人員可以更為精準地定制訪問控制權。雲安全公司EdgewiseNetworks的聯合創始人兼首席執行官PeterSmith認為，如何管理是開發人員轉向無服務器應用時遇到的最大挑戰。他說：“控制這些服務之間的相互訪問是一項重大挑戰，需要一種新的訪問管理模式。”
這個問題的影響範圍有多大呢？答案是相當大。據無服務器安全公司PureSec在4月份發布的報告顯示，21%的開源無服務器項目至少有一個嚴重漏洞或配置錯誤，6%存在諸如在公開訪問位置存放API密鑰的問題。該公司認為，目前存在的五大主要問題是數據注入、認證失效、不安全配置、權限過高和監控不足。
這對人類來說可能是一個極大的挑戰，以至于根本無法處理。這時可能需要大規模利用人工智能（AI）進行處理。Smith說：“新的方法可以通過使用機器學習分析無服務器組件相關性來限制攻擊面，以及通過自動生成最低網絡控制來降低風險。”以采用自動化和可擴展的方式實現隻在可信的組件之間進行必要的訪問。
除了信任，還需要驗證
所有主要的雲提供商現在都有無服務器産品。其中，如亞馬遜的AWSLambda函數、微軟的Azure函數，谷歌和IBM的CloudFunctions。
盡管産品衆多，但是用戶無法一直準确地知道底層基礎設施架構是什麼，它是如何工作的，以及如何确保安全。在某種程度上，這是廠商故意為之。如果公衆能夠訪問這些信息，那麼對于黑客來說也是如此。這也意味着企業必須要對許多東西采取信任的态度。
KudelskiSecurity解決方案架構主管BoLane稱，理論上，無服務器函數運行在孤立的環境中，但是它們仍然是與多個客戶共享的硬件和計算環境。另外，客戶不能在該環境中安裝自己的安全工具，這就造成了嚴重的限制。Lane問道：“你如何監視函數中的輸入和輸出？你如何監控正在進行的惡意活動？你需要在本地環境或虛拟機上部署許多工具，但是又無法部署這些工具。企業客戶需要了解基礎設施提供商能夠提供哪些工具。”
另一種選擇是使用像ApacheOpenWhisk這樣的平台創建自己的無服務器環境。事實上，這是IBM雲函數解決方案BluemixOpenWhisk所基于的平台。其他的選項還包括Fission、IronFunctions和Gestalt。
企業也可以從内部監控函數的性能。例如，專注于應用層的安全廠商FairWarning的創始人兼首席執行官KurtLong說：“我們會在應用内部設置審計函數。如果是自研應用程序，那麼它們會有審計跟蹤。”
所有的基本要素仍然适用，不管應用如何部署。他說：“在無服務器應用中，仍然有數據需要保護，仍然有業務功能需要實現，人們也必須要訪問服務。有些事情不會改變。”
從應用首次構建時就開始建立安全性比任何時候都更加重要。紅帽JBoss的工程副總裁兼首席技術官MarkLittle表示：“安全性不應該在應用開發完成後才考慮。”然而，在實踐中，目前還沒有關于基礎設施漏洞的具體信息，也不清楚應用安全性随着向無服務器應用的過渡會變得更好還是更糟。Little說：“函數即服務目前正在被過度炒作。“開發人員對使用它們很感興趣。對于開發人員不斷嘗試這一新技術或是在生産中使用它們，我們還沒有什麼很好的意見。”
據SumoLogic去年秋季對1500名運行雲應用的客戶展開的調查顯示，使用AWSLamdba的人數已經從2016年的12%增長至了2017年的23%，翻了近一倍。
以後的增長率可能會出現大幅增長。據Cloudability稱，AWSLambda上無服務器函數的增長率由2017年第一季度的100%激增到了第四季度的667%。它們将很快成為一個非常龐大且攻擊目标豐富的環境。
本文作者MariaKorolov在過去20年内長期關注新興技術和新興市場。
原文網址
https://www.csoonline/article/3277965/cloudsecurity/cloud-functionspresent-new-securitychallenges.html