科技云報道原創。

　　隨著云計算技術的進一步成熟，Serverless已成為引領云計算下一個十年的技術熱點。

　　Serverless能夠幫助開發者無需關注服務器、按照實際使用付費且可以享受服務自動彈性伸縮，將更多的精力放到業務邏輯本身。據Gartner預測，2025年將有50%以上的全球企業采用Serverless架構。

　　盡管采用Serverless已成為大勢所趨，但Serverless框架是否真的安全?有人認為，使用Serverless云服務相當于把基礎架構托管給了云服務商，一切云服務安全都由云服務商來負責，采用Serverless甚至會比現有的基礎云服務更安全。

　　事實真的如此嗎?

　　Serverless面臨的安全風險

　　Serverless面臨的主要挑戰是云服務商只負責云的安全性，而不是云中的安全性。這意味著Serverless應用程序不僅仍然面臨傳統應用程序面臨的風險和漏洞，例如：跨站點腳本、訪問控制中斷、數據庫注入、敏感數據泄露、不安全的反序列化等，而且還面臨著Serverless架構特有的安全挑戰。

　　風險一：增加攻擊面

　　Serverless函數使用來自各種事件源的輸入數據，包括 HTTP API、云存儲、IoT設備連接和隊列。這大大增加了攻擊面，因為其中一些部分可能包含不受信任的消息格式，標準應用程序層保護可能無法正確檢查這些格式。如果暴露了用于獲取輸入數據(例如協議、向量和函數)的連接鏈接，則可以將其用作攻擊點。

　　風險二：安全配置錯誤

　　由于云服務提供商提供的設置和功能配置不安全，Serverless應用程序容易受到網絡攻擊。

　　例如，DoS攻擊經常發生在Serverless應用程序中，這是由于函數和主機之間的超時設置配置錯誤，其中低并發限制用作對應用程序的攻擊點。攻擊者還可以通過插入函數調用來利用函數鏈接，其中他們延長函數事件的執行時間比預期更長，從而允許DoW攻擊并增加Serverless函數的成本。

　　此外，使用公共存儲庫(如GitHub和S3存儲桶)中未受保護的功能也會由于敏感數據泄露而造成DoW攻擊。這是因為攻擊者利用公開的函數，其中包含代碼中硬編碼的未受保護的機密和密鑰。

　　風險三：身份驗證中斷

　　Serverless應用程序是無狀態的，在其體系結構中使用微服務會使獨立函數的移動部分面臨身份驗證失敗的風險。

　　例如，如果在具有數百個Serverless函數的應用程序中僅對一個函數的身份驗證處理不當，則會影響應用程序的其余部分。攻擊者可以專注于一個功能，通過不同的方法訪問系統，如自動暴力破解等。

　　風險四：特權過大功能的威脅

　　Serverless生態系統依賴于許多獨立的函數，每個函數都有自己的角色和權限。職能之間的大量交互有時可能導致職能在其權利上享有過多的特權。例如，不斷訪問數據庫并更新其他函數的功能可能是一個巨大的風險，因為它對參與者可見。

　　風險五：使用已知漏洞的組件

　　Serverless應用程序通常使用JavaScript(或TypeScript)或Python語言。Python或 JavaScript的開發人員通常使用大量第三方組件來完成不同的任務。這些組件可能存在漏洞，使用它們會使Serverless應用程序容易受到攻擊。

　　保護Serverless安全性的最佳實踐

　　當然，面對Serverless面臨的安全風險，企業可以采用多種Serverless應用程序安全最佳實踐，其中包括：

　　不要僅僅依賴WAF保護

　　擁有WAF很重要，但它不應該是保護Serverless應用程序的唯一防線。如果僅依靠WAF保護，安全性可能會有很大的漏洞。

　　因為WAF只能檢查HTTP流量，這意味著WAF只會保護API網關觸發的函數，它不會針對其他事件觸發器類型提供保護。如果函數從不同的事件源觸發，比如：通知(物聯網、短信和電子郵件;代碼修改;數據庫更改;流數據處理;云存儲事件等，則WAF無濟于事。

　　使用自定義函數權限

　　事實上，Serverless應用程序中超過90%的權限已被過度許可。盡管在考慮Serverless應用功能級別時，設置權限可能會令人望而生畏，但不應使用一刀切的方法。一個常見的Serverless安全錯誤是設置更寬松且功能更大的策略，未能最小化單個權限和功能角色會使攻擊面大于應有的范圍。

　　DevSecOps團隊必須與編寫函數的開發人員坐下來，查看每個函數的用途并創建適當的函數級別權限。確定每個函數的用途后，可以為每個函數創建合適的權限策略和唯一角色。慶幸的是，整個過程可以使用各種自動化工具來助力。

　　進行代碼審核

　　Black Duck Software調查了企業中常用的1000個應用程序，發現其中96%都使用了開源軟件。研究人員還發現，60%的軟件都包含安全漏洞，其中一些漏洞已經存在了四年以上。這使得代碼所有權和真實性成為一項嚴重的安全風險。

　　隨著開源軟件的盛行，單個Serverless函數可能包含來自不同外部源的數千行代碼。因此，想要提高Serverless的安全性，執行代碼安全審計至關重要。

　　保持對CI/CD的控制

　　代碼漏洞可以通過嚴格的CI/CD來緩解，即使它聽起來很難。

　　攻擊者可能會通過各種方式溜進來，甚至會在不被發現的情況下潛入企業內部造成嚴重破壞。若要確保不會發生這種情況，必須創建一個策略和策略，以便在生成期間執行代碼分析，然后再上線，并確保每個函數都已通過CI/CD。

　　通過AI密切關注所有攻擊指標

　　每天只有幾百個函數都可以在日志中生成數十億個事件，因此很難確定哪些事件是重要的。即使熟悉Serverless應用特有的攻擊模式，也不可能掃描所有攻擊模式，這就是為什么必須使用AI工具來增加Serverless的安全性、效率和可見性。

　　使函數超時

　　所有函數都應具有嚴格的運行時配置文件，但通常不直觀地創建適當的Serverless函數超時。函數的最長持續時間可以特定于該函數。DevSecOps 團隊需要考慮配置的超時與實際超時。大多數開發人員將超時設置為允許的最大值，因為未使用的時間不會產生額外的費用。

　　但是，這種方法可能會產生巨大的安全風險，因為如果攻擊者成功注入代碼，他們就有更多的時間來造成損害。較短的超時意味著它們可以更頻繁地攻擊，這被稱為“土撥鼠日”攻擊，但它也使攻擊更加明顯。因此，作為Serverless安全性最佳做法，是必須使函數超時。

　　減少對第三方的依賴

　　開發人員通常從第三方派生組件，最好檢查其來源是否可靠以及它們所引用的鏈接是否安全，采取此預防措施可避免意外漏洞，務必檢查開源平臺中使用的組件的最新版本。

　　大多數開發人員更喜歡在現代應用中使用開源組件，這使得檢測任何問題或跟蹤代碼中的漏洞變得更加困難。最好使用最新版本并及時獲得更新，并提前做好準備。

　　為此，可以定期檢查開發論壇上的更新，使用自動依賴項工具，并避免使用依賴項過多的第三方軟件。

　　處理憑證

　　建議將敏感數據存儲在安全的位置，并使其可訪問性極其有限，必須特別注意API密鑰等憑據。同時，應將環境變量設置為運行時間評估設置，然后在配置文件中部署時間。

　　最好的方法是定期輪換密鑰，即使被黑客入侵，可以確保切斷對黑客的訪問。每個組件、開發人員和項目都必須具有單獨的密鑰，并加密敏感數據和環境變量。

　　保護軟件開發生命周期

　　軟件開發生命周期定義了構建應用程序、在整個生命周期中對其進行管理以及簡化開發過程。但是，不安全的應用程序可能會帶來巨大的業務風險。易受攻擊的應用程序可能會導致個人數據丟失，并對企業業務聲譽造成無法彌補的損害。

　　在開發階段集成安全性可確保授權并確保Serverless應用程序的正常工作，它還涉及不斷審查弱點條件，并確保應用程序與安全實踐集成。

　　地理考慮

　　開發人員應記住，在部署應用模塊時，某些地理注意事項可能會對Serverless安全性產生負面影響。從不同地理位置部署的代碼可能會產生與代碼相關的問題。例如，紐約的開發人員將使用US-East-1時區，而來自亞洲的開發人員將在部署設置中使用完全不同的時區。

　　結語

　　毫無疑問，新機遇伴隨著獨特的挑戰。Serverless架構引入了一種新的應用程序開發范例，但是企業在處理應用程序基礎結構時，也必須承擔額外的安全責任。

　　因此，在采用Serverless時，需要更謹慎和明智地嘗試安全應用程序最佳實踐。